(Message May:36)
MessageName: (Message May:36)
SUBJECT: MULTI-LANGUAGE AND SPANISH CORRESPONDENCE
Date:    Sat, 9 May 87 11:30 N
From:    FRANKLIN%CGEUGE51.BITNET@wiscvm.wisc.EDU
To:      milne@ICSE.UCI.EDU
----------------------------------------

From:   UGUN2A::FRANKLIN     "S Franklin"  9-APR-1987 10:59
To:     JNET%"bork@UCI",FRANKLIN
Subj:   RE: IBM request

..

I'll use the term "module" to refer to a collection of activities.
Thus Electricity is a module with 8 (or is it 10) activities.
I don't recall if this is the terminology we have used before, but
it will do for now.

The basic idea is that we want each disk to have 2 subvolumes, one for
each of the 2 modules on the disk.  When the disk is first started a
very simple menu determines which module/subvolume is to be used,
we chain to a program which makes that subvolume the root volume
and then chains to that subvolume's system.startup.  Each subvolume
is a direct copy of the disk it replaces.  Thus, there is no need to
change any of the existing code.  Of course, we will still have to
test it and there's no point in going into the fact that that can
be a very time consuming process even if we don't encounter problems
(300 chainto's at 5-10 minutes per chainto is 25 to 50 hours per
configuration checked and we do have to test the minimum memory
configurations).

None of this is particularly clever and we need not be clever if the
disk capacity is sufficient to allow us to have 3 copies of system.pascal,
system.miscinfo, system.library and etc.charset (as necessary) on each
disk (one copy for the disk and one copy for each of the subvolumes).
What if we don't have that much room?  Well, what we really want is
the equivalent of the UNIX link ("ln") facility where a file appears
in several subdirectories possibly under different names.  Here's
how we can fake that in the UCSD p-system (the details I give are
overly specific to make it easier to follow than a more general
statement):
   We lay out a disk as follows
      SYSTEM.PME.86,
      MODULE_A.SVOL,   <-- directory only, 4 blocks
      MODULE_B.SVOL,   <-- directory only, 4 blocks
      SYSTEM.PASCAL, SYSTEM.MISCINFO, SYSTEM.LIBRARY, ...    <-- common files
      MODULE_A.STARTUP, MODULE_A.FILE1, MODULE_A.FILE2, ... <-- MODULE_A only
      MODULE_B.STARTUP, MODULE_B.FILE1, MODULE_B.FILE2, ... <-- MODULE_A only
The MODULE_A.SVOL and MODULE_B.SVOL are specially modified directories
each of which says it's subvolume extends to the *end* of the disk.
In the MODULE_A.SVOL, the common files appear under their real names
(e.g., SYSTEM.PASCAL is so named), but MODULE_A.STARTUP (the attract mode/
menu program for module A) is named SYSTEM.STARTUP and the module B files
need not appear at all!

-- sdf

----------------------------------------------------
From franklin Mon Apr 13 18:49:25 1987
To: bork@uci.bitnet
Subject: Translating SRS
...
The bitmap graphics tools Bertrand has been working on make it possible
*easily* to adapt existing ETC images files (you should see how easy it
is to edit the 53 block multiple image file from Electricity, everything
from different zoom factors in the X and Y direction to flipping bytes),
to import images from scanners and from MacPaint-like programs (he uses
an MS-DOS program called Picasso as a specific instance of such
programs), to tune them to different displays (wouldn't we like to have
SRS taking advantage of full Olivetti 640x400 point graphics or the
various (old and new) IBM graphics "standards"), to quickly display
them during dialog run-time, to integrate these bitmaps images with
curves, lines and points that are mathematically generated at run-time,
to vary the display position at run-time (each image can have multiple
reference points which are used both for positioning images on the
screen and for the mathematically generated objects mentioned above),
and get hard copies of bitmap displays.  Actually, I'm not being
entirely accurate in calling these images "bitmap."  Bertrand, handles
multi-plane images so "pixelmap" is closer to the target.

You can send electronic message reply to:  EARNMAIN@EB0UB011 in
the EARN/BITNET network.

King regards.
------------------------------------------------------------------------
That's the end of Jordi's message.
Best regards,  Miguel.

----------------------------------------
From:   UGUN2A::FRANKLIN     "S Franklin"  7-MAY-1987 19:27
To:     jnet%"Bork@UCIVMSA",FRANKLIN
Subj:   RE: Re: Chris Emerson

Alfred:
...
-- sdf
P.S. What do you think about the following approach to translation
cooperation:
   o Geneva creates
       a) language independent Pascal source files based on Irvine sources
      and
       b) corresponding keyed files in English
   o These files become the basis for Irvine and Geneva's maintenance
     of the programs.
   o Translations are based on compiled form of Pascal programs and
     unmuto a program which makes that subvolume the root volume
and then chains to that subvolume's system.startup.  Each subvolume
is a direct copy of the disk it replaces.  Thus, there is no need to
change any of the existing code.  Of course, we will still have to
test it and there's no point in going into the f