INTRODUCTION TO CEDAR
CEDAR 4.2
Introduction  to Cedar
Version 4.2

Abstract: This memo is a sort of operators' manual for acquiring and using Cedar. It explains the minimum you need to to know about most things, depending upon other documents for the full story.
This memo is probably out of date if it is in hardcopy form. It is intended to document Release 4.2 of Cedar, June 1983, but some sections still reflect earlier releases.
[If you are reading this document on-line, try using the Tioga Levels and Lines menus (if you can) to initially browse the top few levels of its structure before reading it straight through.]


XEROX			Xerox Corporation
				Palo Alto Research Center
				3333 Coyote Hill Road
				Palo Alto, California 94304
DRAFT  For Internal Xerox Use Only  DRAFT
Introduction to Cedar: Contents
0. Introduction
1. The Cedar World
1.0 Credentials
1.1 Screen Management and Input
1.2 User Exec
1.3 Files
1.4 User Profile
1.5 Walnut
1.6 Maintain
1.7 Setting up your disk
1.8 General Failure Modes
2. Programming in Cedar
2.1 Running programs
2.2 System Models
2.3 BugBane and CoPilot
3. References
3.1 General References
3.2 Cedar Language References
0. Introduction
Cedar has a small, close-knit user community and it is changing very fast. Much useful information is not written down or appears in informal messages. To learn about using the system you must take some lessons from someone; get them to show you how to start a D-machine, how to use the mouse, etc. To work effectively you must keep in touch with what is going on. If you are using Cedar put your name on the CedarUsers mailing list. (See the section 1.6 for instructions on how to do it.) If you would like to participate in or listen to design discussions, put your name on CedarDiscussion. If you are just generally interested in what is going on try CedarInterest. Questions and bug reports should be sent to CedarSupportcurrently John Maxwell. Questions about a particular section this memo can be addressed to the person(s) listed at the beginning of that section. Questions about specific packages and problems should be addressed to the maintainers listed in the Catalog, with copies to CedarSupport; but, if you're not sure whom to ask, the following people have a general knowledge of how to use the system: Atkinson, Brown, Morris, Levin, Maxwell, McGregor, Paxton, Rovner, Satterthwaite, Schmidt.
Typographical conventions employed herein:
Names of keys appear in capital letters in a small, alternate font; e.g., SHIFT, ESC, RETURN
Y is sometimes used for RETURN.
Things that are typed or displayed on the screen appear in an alternate font; e.g., compile foo
When we describe fancy interactions in which a system completes commands, what you actually type is underlined; e.g., OthelloDorado.eb 
1. The Cedar World
To use Cedar you must first find a Dorado or Dolphin.
Cedar will usually be found in its idle state, displaying the words "Type Key" in the cursor.  After pressing a key on the keyboard, you will be asked to supply your name and password.
To awaken a slumbering Dorado press its boot button three times and wait for something to appear on the screen (a minute or so).
To start Cedar on a wakened Dorado hold down the C (for Cedar) key and boot the machine by pressing the boot button three times.
To turn on a Dolphin press the start button on its maintenance panel and wait for something to appear on the screen (a couple of minutes).
To start Cedar on an awakened Dolphin hold down the P (for Pilot) key and boot the machine by pressing the boot button once.
If Cedar is properly installed on the machine the cursor will turn into a cedar tree, and you will be prompted for a name and password or just a password; if you don't know what to type, get help. If the version number at the top of the screen is larger than 4.2, check for a newer version of this memo. If it is smaller, get the new release using the instructions in section 1.7.2. If the screen says Othello. . ., typing Rollback or Boot Client may get you to Cedar. Otherwise, you have no Cedar world; consult section 1.7 on how to get your disk set up.
1.0 Credentials	Roy Levin
Cedar expects its user to be an individual registered with Grapevine. Whenever you enter the Cedar world, you will be asked to supply your Grapevine RName and password. Once you have been authenticated, Cedar will remember your credentials until you either (1) push the boot button, (2) boot a non-Cedar partition (e.g., an Alto partition), or (3) push the "Idle" button in the extreme upper right corner of the screen. If you are not registered with Grapevine, contact your local support staff.
The precise form in which Cedar asks for your credentials depends upon the way in which the credentials were originally installed. Public machines and some personal machines (at their owners' option) have "unprotected" disks, meaning that Cedar will permit any individual recognized by Grapevine to log in. Other personal machines, however, have "protected" disks, meaning that Cedar will only allow a specific individual to log in. To change from a protected disk to an unprotected one or vice versa, use Othello's "Install Credentials" command.
1.1 Screen Management and Input	Scott McGregor
The basis for screen management is the Viewer. In general, a viewer manifests itself as a rectangular area on the screen. Some viewers simply display text, others are virtual buttons that invoke procedures when clicked.  We use the verb click for positioning the mouse-controlled cursor and depressing and releasing a mouse button, usually the left one.  Middle-click means to depress the middle button, right-click means to depress the right button, etc.  In the past mouse buttons were imagined to be red (left), yellow (middle), and blue (right), so you will occasionally see that terminology.          

The large middle part of the screen is divided into two columns for displaying tools and documents.  Most tools and documents will initially appear as iconssmall pictures at the bottom of the screen.  You can open an icon (change it into a viewer) by middle-clicking it; shift-middle-clicking an icon (holding down the left SHIFT key while middle-clicking) makes it consume the whole column.  Left-clicking an icon selects it (makes it the recipient of type-in from the keyboard).  Icon keyboard commands include:

L      	Move the icon to the left column.
R     	Move the icon to the right column.
M      	Move the icon to the other column.
C         	Move the icon to the color display (assuming you have the hardware).
O      	Open the icon (like middle-clicking).
SHIFT-O	Open the icon full size (like shift-middle-clicking).
DEL    	Delete the icon.

Open viewers display a menu of commands across the top when you move the cursor into the caption (the black band at the top containing the name of the viewer). The commands are as follows:

Destroy  	Make the viewer disappear.
Adjust  	Change the size of the viewer or size of the column (see below).
Top     	Move the viewer to the top of the column.
<--     	Move the viewer to the left column.
-->     	Move the viewer to the right column.
Grow  	Close all other viewers in the column.
Close   	Make the viewer iconic.

Middle-clicking in the caption menu always invokes the Grow command, and right-clicking always invokes Close.  This allows you to invoke these frequently used operations without having to position the mouse with great accuracy.    
The height of a viewer in a column is computed from a set of hints, some determined by programs and some indicated by the user. The program which created the viewer can specify a desired height (such as in the EditTool and Watch viewers) or the program can request that the viewer receive a "fair share" of the available space (as in Tioga text viewers). The user may override these program hints by left-clicking the Adjust caption menu command, entering a mode where a new height hint may be specified with the mouse. Moving the cursor out of the original column changes the mode to allow the user to specify a new column height and width. At any time while in adjust mode, simultaneously depressing two mouse buttons cancels the adjust command.  
Some menu items and button will be displayed with a strikeout bar through the text. These are known as guarded commands, implying that that command, if inadvertantly triggered, might cause loss of your current state. To invoke a guarded command, left-click once to remove the guard and then again to trigger (within a few seconds or the guard will reappear).  
In order to type something into a viewer, you must first establish the input focus by left-clicking somewhere inside it. (If the viewer is a typescript viewer, i.e. one in which you and the system alternately insert characters, as opposed to a Tioga document, you should make sure that you left-click the mouse in the white space below the last character.) Left-clicking in a text area positions the blinking caret that indicates where your typed characters will appear. 
A sequence of text characters may be selected by left-clicking the first character and right-clicking the last; they will appear video reversed, i.e., white on black. Those characters then become the current selection which various buttons (e.g., Open) treat as an input parameter. Whatever you type replaces the current selection when it is video reversed. 
There are many other things to learn about selection described in the Tioga manual [G1]. Tioga is generally similar to Laurel [G2].  
Across the top of the screen is a small message area where various comments about the system's status and behavior will appear.  If the message is especially important, the message window will flash to call the your attention to it.  There are some buttons at the right end of the message area. Reading from right to left:  
Left-clicking Idle causes the screen to turn black and display a dancing "Type Key" cursor.  This is the preferred way of ending a session without actually leaving the Cedar world; various volatile structures will be made secure on the disk. If you subsequently hit a key, you will be asked to login, after which the screen will be restored to its state at the time that Idle was invoked.   
Left-clicking Clean deletes the icons for unedited documents when the icon area gets cluttered and puts the 25 most recently cleaned  documents in a cache called the MRU -- for Most Recently Used.  As new ones are added to a full cache, the oldest ones drop off of the bottom.  You can get a document back from the cache by clicking the button with its name.

Left-clicking the New button creates a new text viewer.  Typing a file name in the new viewer followed by a LF will load a file into it. 
Left-clicking the Open button creates a new text viewer for the file named by the current selection.  
No documentation is yet available on the Cmd button; it will be forthcoming in the Cedar catalog (release copy in [Indigo]<Cedar>Documentation>Catalog.tioga, fresh draft in [Indigo]<CedarDocs>Manual>Catalog.tioga).
You can boot any of your system volumes (e.g., Alto, Client, Othello) by left-clicking Boot to bring up a set of guarded buttons. 
The checkpoint facility allows you to save the effect of a long set-up computation such as the one that occurs after the installation of a new release.  Double-left-click the Checkpoint button at the top of the screen and wait for a while (about four minutes on a Dolphin).  Don't worry that the cursor won't move with the mouse.  Then, whenever you start your Cedar world or double-left-click the Rollback button, you will find yourself in this state.  It is important to understand that rolling back only restores the state of the virtual memory.  It does not undo changes made to files or the directory.  Thus you should create checkpoints only when the system is in a quiescent state with no open files; otherwise, strange things might happen after a rollback.  If you want to overwrite a bcd (either by compiling or file transfer) that was loaded prior to a checkpoint you should boot the Client volume and create a new checkpoint.  Don't make checkpoints on public Dorados unless you know how to restore the standard one when you are done.
1.2 User Exec	Warren Teitelman
Note: The following is summarized and extracted from the documentation of Cedar UserExec, [G14], which also appears as as a separate section of the Cedar Manual. For more complete discussion, and lots of examples, refer to this documentation, which can also be found on your disk as the file UserExec.tioga. 
General Comments
The Cedar executive is called the UserExec. It is an amalgam of the Alto Exec, a Cedar Language interpreter, and a debuggerbacked up by optional automatic error correction facilities similar to InterLisp's DWIM. For example, the UserExec can be used to load and run bcds, list, copy, rename, and delete files, evaluate Cedar Language expressions, catch breaks and signals, and display the state of a process that has been stopped by a break or signal.
The user interacts with a particular UserExec (you can have several around, even executing, at the same time) through a special viewer called a WorkArea. Each WorkArea has a name, typically a single letter, which is displayed as part of its caption. Each WorkArea also has a mode, which is either Executive or Interpreter, also displayed as part of its caption. To "talk" to a particular UserExec, simply establish the input focus by left-clicking in the bottom portion of the corresponding viewer, and then start typing.
Since the WorkArea is a viewer, all of the viewer facilities are available for manipulating the WorkArea (see section 1.1). In particular, it can be grown, adjusted, scrolled, moved, closed (the UserExec will continue running and/or outputting characters, you just won't see them until you reopen the viewer), opened, split, or even destroyed (which will abort any operation that is executing the next time it tries to do input or output). Furthermore, since the viewer views a Tioga typescript, all of the Tioga editing and selection mechanisms can be used with respect to the command line that you are composing: you can edit this line to your hearts content, and when you terminate the command, it will look exactly like you typed in the edited line.
New UserExecs and their corresponding WorkAreas can be created via the New menu button which appears in the first line of each UserExec menu. This works even when a particular WorkArea seems to have "died". Existing UserExecs can be destroyed via the Destroy Viewer menu button. If you destroy your only WorkArea, an Exec button is posted at the top of the screen which you can use to create new WorkAreas.  
Events
Each user interaction with a UserExec is called an event. At the start of each event, the user is prompted by & followed by the event number. The user then types in a command line consisting of the name of a registered command, followed by its arguments, if any, and terminated by Y, ?, CTRL-X, or ESC. The UserExec then performs the indicated operation, prints the result, and prompts the user for the next event. Typing DEL during the input of a command will abort the input, causing you to be reprompted. Left-clicking the Stop menu button (or typing CTRL-DEL) during the exeuction of an event will cause it to abort the current operation (but sometimes it takes a little while).
Terminating a command line with ? signifies a request for additional information. Specifically, ? by itself prints a list of commands currently registered, ? after a registered command prints a description of the command, and ? after a Cedar expression prints the type of (the value of) the expression. For example:
&4 walnut?
Walnut         Creates a viewer for sending or retrieving mail.
&5 _ 3.2?
is of type REAL
&6 _ Rope.Cat?	
is of type PROC [r1, r2, r3, r4, r5, r6: ROPE _ NIL] RETURNS [ROPE]; 
   returns the concatenation of up to six ropes (limit based on eval stack depth)
   BoundsFault occurs if the result gets too large
Terminating a command with CTRL-X means to "expand" the command, but not to execute it, i.e. e.g. perform * expansion. Terminating a command with ESC means to "complete" the command, as far as possible, but not to execute it. 
Registered Commands
The following are some of the more useful registered commands. More commands can be discovered through the use of ?. 
@     takes a file name as argument. Treat the contents of the named file as a command file, i.e. interpret the text as a sequence of commands. If {file} has no extension, look for a file of the form {file}.commands or {file}.cm. 
_	Treat the remainder of the input line as a mesa expression to be evaluated. Evaluate the expression and print its value. If the expression is terminated with ?, print the type of its value, rather than the value. If the expression is terminated with !, print the value showing the referents of all REFs and POINTERs to an unlimited depth. 
Note: many users prefer to do interpretation of expressions in Interpreter WorkAreas or Action WorkAreas (see below), in which case the _ is automatically provided at the beginning of each command line, and to use Executive WorkAreas for "executive" type of operations such as running programs and manipulating files.
Bind	Bind a list of configurations. See discussion of Compile menu button below.
Bringover	Retrieve files using a specified df file (see 1.3.2)
ChangeAreaMode	change an Executive WorkArea to an Interpreter WorkArea and vice versa.
Compile	Compile a list of modules.
Copy 	  Copy contents of one or more files to another. Syntax is Copy new _ old1 old2 ... oldn.
Date		Type today's date and time.
Delete	Delete a list of files.
Fetch	Copies remote file(s) to corresponding local file(s).
Help		Provide more complete explanation of UserExec in a separate viewer.
List		Print size and creation date for the indicated files.
ListByDates	Print size and creation date for the indicated files, sorted by create date.
Login	Supply user name and password.
Rename	Rename a file. Syntax is Rename new _ old.
Run		Load and Start the named programs.
SModel	Store files on remote servers using a specified df file. (see section 1.3.2)
TSetter	Create a typesetter viewer for specified server, and use it to print named documents
User		Type the name of the logged-in user.
Walnut	For sending or retrieving mail.
For convenience, a number of commonly used registered commands can also be invoked via menu buttons that appear in the first line of the menu of each WorkArea. If it isn't obvious what these menu buttons do, consult [G14].   
Interpreter WorkAreas
When typing to an Interpreter WorkArea, the user is always prompted with &nn _, where nn is the event number. What the user types following the _ is treated as an expression to be evaluated in the current context and default global context, if any, for the WorkArea. The value of the expression will be assigned to the variable whose name precedes the _, i.e. &nn. This value can be referenced in later expressions. As mentioned earlier, if ? is typed following an expression, the type of the expression, plus other explanatory information, is printed.
The following is taken from an actual session with an Interpreter WorkArea. The italicized text at the right is added commentary not printed by UserExec. 
&2 _ Rope.Cat["Ce", "dar"]Y	Note that Rope is the interface, not the implementation.
"Cedar"
&3 _ LIST[1, 3.2, &]Y	& evaluates to the previous result (&2 in this case.)
(^1, ^3.2, "Cedar")
&4 _ &3?		What type of list did the interpreter produce?
is of type LORA: TYPE = LIST OF REF ANY
&5 _ &3.first^?
is of type INT
&6 _ &3.rest.first^?
is of type REAL
&7 _ ListY	
default global context changed to: ListImpl
{globalFrame: ListImpl}
&8 _ Appendd[Reverse[&3],&3]]Y	Note that Reverse is now interpreted as List.Reverse.
Appendd -> Append ? Yes		Spelling correction.
("Cedar", ^3.2, ^1, ^1, ^3.2, "Cedar")
For more detailed information about exactly what subset of Cedar language expressions the interpreter can handle see section 2.3.
Action WorkAreas
Actions occur when a program raises a signal or error that is not caught or encounters a breakpoint. Whenever an action occurs, the corresponding process is stopped so that it can be examined, and control transfers to a different WorkArea called an Action WorkArea, or ActionArea for short. An ActionArea is an Interpreter WorkArea whose default context is the context of the action. The user can then walk the stack and evaluate expressions. The user can also choose to ignore the action for the time being and type some other command in a different WorkArea. If the user does not wish to pursue the cause of the action at all, the simplest way to make it "go away" is to left-click Abort. For complete discussion of Action Areas and ActionArea Commands, see [G14].
Using the History facility
Each WorkArea has associated with it a history of all of the events that have taken place in that WorkArea. The user can examine this history via the History registered command, reexecute a particular event or events using the Redo command, or substitute new parameters (text strings) into a particular event or events and then reexecute them via the Use command.
Confirmation
Occasionally the UserExec will attempt to correct an error: e.g. a misspelled file name, an invalid selector, syntax error, etc. In this situation, two new menu buttons, Yes and No, will be posted in the menu for the corresponding WorkArea. Depending on the settings in the user's profile (see UserProfile.doc), some errors will be corrected automatically, but in other cases, confirmation will be requested. When/if the user is asked to confirm (depending on the settings in the user's profile, some errors may be corrected automatically), the user can confirm using these buttons, or by typing Y or N. If the user has typed ahead before the need for confirmation was detected, the typeahead will be retained, and the user must confirm using the Yes and No buttons. 
1.3 Files
All of the material you are working on, including programs, is stored in files. Each different document you handle will be stored on its own file. The file system is somewhat complicated by the fact that it spans a network and developed in an evolutionary fashion.
1.3.1 Local and Remote Files	Ed Taft
A file on your local disk is identified by its name, which is a string of letters (upper and lower case can be used interchangeably), digits, and any of the punctuation characters +- . $. By convention, a simple file name has two parts, which are called the main name and the extension; they are separated by a period. For example, "Introduction.tioga" is a file name, with main name "Introduction" and extension "tioga". File names cannot include blanks, or any punctuation characters except the ones just mentioned.
It is important to name your files in some systematic way, using the main name to identify it, and the extension to tell what kind of file it is. Unless there is a good reason to do otherwise, it is best to use one of the standard extensions given below.
Here is a list of extensions commonly encountered:
.bcd   	Cedar object program
.config	system configuration, input to binder
.cm    	command file for the User Exec or other programs
.doc   	Tioga document (old convention)
.df    	list of dated files for use in moving files between machines
.mesa  	Cedar or Mesa source code
.model 	system model
.press 	Press-format file, suitable for printing
.tioga 	Tioga document
The system doesn't care whether you capitalize letters in file names or not (i.e., ALPHA, alpha, and aLpHa refer to the same file), but it is a good idea to use capitalization to make names more readable. This is especially useful when a name consists of more than one word, since blanks are not allowed in file names: e.g., TripReport or MasterList. A file name with the form X$ is taken to be an older, backup version of X. Many subsystems will save the previous version under such a name. 
File servers are large repositories for files. A file server's disk typically has hundreds of times the capacity of your local disk. Besides providing back-up for your local disk, they are the only reasonable places to put files you wish others to see or want to access yourself from different machines. The only reasonable way to do business is to keep your personal files backed up on a remote server. You should not rest easily unless the latest versions of all your important files are on a remote server somewhere.
In general, the name of file in network has the form
[Server]<directory>subDirectories>name.extension!version
This form is sometimes called the full path name. The server is the name of the machine. Indigo, Ivy, and MAXC are the local servers; the first two are instances of IFSthe interim file system. The directory is the name of a project or person. Each user who has an account on a file server has his own directory, named by his user name. Files within a directory may be organized into sub-directories (except on MAXC). For example, the file named
<Jones>Memos>ActivityReport.bravo!3
belongs in directory Jones, sub-directory Memos. You can have as many sub-directories as you wish within your own directory. You can even have sub-directories within sub-directories, to as many levels as you wish, subject to an overall limit of 99 characters in each file name. Subdirectories are entirely a naming convention based upon the use of the character >; there are no special operations for dealing with subdirectories. The name and extension serve the same purposes as on the local machine. When you put a file onto a file server, if there is already a file with the same name, the new file is added, with a version number one bigger than the old one. When you reference a file without specifying a version you get the one with the largest version number. As you can see, it is almost never necessary for you to specify a version number explicitly. (On MAXC, the character ; is used instead of ! to prefix a version number.) Each file in the system carries a create time: the time when the content of the file was created. This attribute serves as a server-independent version stamp. 
You can name a group of files by using file name patterns containing the magic character * which stands for any string of characters. For example, the pattern *.memo stands for all the files which have the extension "memo", and the pattern *.BWL* stands for all the files which have "BWL" as the first three characters of the extension. 
1.3.2 DF Files	Eric Schmidt
As soon as you find yourself dealing with multiple files, you should devise DF files to help you back up and retrieve them. A DF file is a human-readable file that describes a list of files with their create dates. The simplest way to create a DF file is to list all the files of interest in a file and apply the command SModel to it. For example, to create the DF file describing all the files mentioned in a previous version of this memo we created the file init.df with the following content:
Directory [indigo]<Cedar>init>
  Init.df                                   
  AltoSupport.cm
  Cedar.cm
  D0.cm
  D0Release2.5.1.cm
  Dorado.cm
  DoradoRelease2.5.1.cm
  RunPilot.bcd
Directory [indigo]<Cedar>documentation>
  GettingStartedInCedar.memo
  GettingStartedInCedar.press
We then typed
SModel init
to the User Exec. This transfered all the files to the remote directories, including an updated version of init.df that contained the version numbers and create times of the files:
Directory [indigo]<Cedar>init>
  Init.df
  AltoSupport.cm!1		22-Mar-82  9:47:24 PST
  Cedar.cm!1		18-Mar-82 14:57:23 PST
  D0.cm!2    		22-Mar-82 10:38:37 PST
  D0Release2.5.1.cm!3    	22-Mar-82 10:55:02 PST
  Dorado.cm!3             	22-Mar-82 12:33:35 PST
  DoradoRelease2.5.1.cm!1	22-Mar-82 10:11:30 PST
  RunPilot.bcd!1		2-Feb-82 23:37:34 PST
Directory [indigo]<Cedar>documentation>
  GettingStartedInCedar.memo!1 	22-Mar-82 14:02:23 PST
  GettingStartedInCedar.press!1	22-Mar-82 14:03:11 PST
Once you have a DF file, you can use the BringOver and SModel programs to manage the movement of your system.
BringOver /a init
makes sure the local disk contains the proper versions of the files in init.df by retrieving new versions automatically (/a) if needed. You should use full path names to specify a DF file if you want the remote version to control things; e.g.
BringOver /a [Indigo]<Cedar>init>init
After making changes to files, you can use SModel to write out the new versions; it compares the create times on the local files with those in the DF file and transfers files when they differ. You can nest DF files if your package requires another package. All of this is a simplification; see [G3] for more information.  If you are providing a component of a Cedar release you must read [G4] to learn the proper way to use DF files for a Cedar release. You can learn a lot by looking at the DF files on [Indigo]<Cedar>Top>.
1.3.3 The File Tool	Larry Stewart
The File Toolits iconic form looks like a file cabinetis used for listing files on various machines and transferring them. Its topmost section provides various fields for you to type in things and a few mode buttons; left-click the field name and the cursor will move to its entry. The * notation can be used in the first three fields to designate groups of files.
Directory designates a remote server and subdirectories; e.g., [Indigo]<Cedar>Top>. The * notation can be used to designate multiple places. 
Filename(s) is a sequence of files to be transferred or listed; subdirectories may be included; e.g., Docs>Intro.press. Remote file names are derived by concatenating Directory with these names. The * notation can be used to designate multiple files. Entering @X will cause the contents of file X to be used.
Local refers to local file names. It can be used if you wish to rename a single file as it is being transferred. On a retrieve it names the destination file; on a store it names the source. The * notation can be used to designate multiple files. Entering @X will cause the contents of file X to be used.
DF File is the name of a DF file that fetch may be done through. See DFGet.
Connect Name and Password are needed for access to certain directories. You may omit the password when connecting to a directory belonging to a project of which you are a member.
Update is a button that sets the mode of operation so that a file will be moved only if a version of it already exists at the destination and has an earlier create date than the file to be moved.
Update>a does the same thing except the file will be moved even if it doesn't exist at the destination; most people prefer it.
ExportsOnly applies to fetches done through DF files. 
Verify sets the mode so that you must confirm each transfer by clicking buttons that will be presented to you in the middle section
The second section holds a set of buttons that represent commands.
Retrieve fetches the remote files given by the combination of Directory and Filename(s). If no local name is given the short form of the remote one is used.
Store moves files to a remote machine. If no Local entry is present it uses the Filename(s).
Local-List displays information about the local files.
Remote-List displays information (version, size, creation time) about the remote file.
List-Options brings up a set of buttons that change the things printed out by the List commands. Apply causes the new settings to take effect; Abort resets to the old settings.
Close shuts down the remote connection
DFGet retrieves the files listed in Filename(s) using a DF file to discover their full path names. Directory is prepended to DF File to define the full path name of the DF file itself.
DFGetBoth is the same as DFGet but fetches the .mesa and .bcd for each name listed in Filename(s).
Local-Delete deletes the local files; it must be armed. Warning: Unlike certain systems, once you have deleted a file, you cannot get it back. Proceed with caution.
Remote-Delete deletes the remote file; it must be armed.
The third section is an output typescript. The Stop button in the top-most menu can be used to abort transfers and lists in an orderly way.
1.3.4 Chat and File Space Management	Larry Stewart, Ed Taft
Sooner or latter you will run out of disk space on your IFS or MAXC directory. File space management activities not supported by the File Tool or DF files can be carried out by connecting to a file server with Chat. Chat uses a viewer to simulate a teletype computer terminal, and thereby enables you to talk directly to executive programs running in various server machines.
To initiate a conversation with the executive in a server type Chat server -l to the User Exec. If all goes well, you will see a message from the server's executive and @ at the left margin prompting you for type-in. If Chat has trouble getting connected, it will tell you its problem after trying for a few seconds. This usually means that the server is broken; you might try again in a few minutes. To redirect an existing Chat viewer to a sever type the server name into a window, select the name, and left-click Login.  If you left-click Connect rather than Login, you can login by hand: type
@Login (user) name (password) password
Whatever the server executive is doing, you can force it to stop by typing CTRL-C. On MAXC, you may have to type CTRL-C several times in quick succession to get it to stop.
When you are finished talking to the server Executive, type
@Logout
(or Quit if the server is an IFS). Then left-click Disconnect. If the file server is an IFS, you will be logged out automatically if you don't type anything for three minutes. This is because IFS can service only a small number of users (currently nine) at once; the automatic logout is intended to prevent IFS from being tied up by users who aren't doing anything useful. Simply closing a chat viewer does not shut down the connection unless you right-click the Close button.
You type commands to IFS and to MAXC in more-or-less the same way (except for those commands that have different names on the two systems); however, the responses from IFS and MAXC are usually somewhat different. You may type ? at any point to obtain a brief explanation of what you are expected to type in next. MAXC normally does not display the remainder of abbreviated commands; however, you can force it to do so by terminating fields you type in with ESC rather than space.
To delete all old versions of files (i.e., all but the highest-numbered version of each file), on IFS type
@Delete *,
@@Keep (# of versions) 1
@@Confirm (all deletes automatically)
@@ 
on MAXC type
@Delver
Delete oldest? Yes
Delete 2nd newest? Yes
File(s):  
It is a good idea to do this fairly frequently, since old versions of files can pile up and waste a lot of space. To find out how much space you are using on the file server, type
@DskStat
One IFS or MAXC page is equivalent to about four D-machine pages. You will notice that you also have a disk limit which is the maximum number of pages you are permitted to use on the file server at one time. If you exceed your disk limit, the server won't let you store any more files until you first delete some existing ones to get you below your disk limit. To get your limit changed, consult your local support staff.
You can direct your attention to some other directory by typing
@Connect (to directory) OtherDir (password) password
You may omit the password when connecting back to your own directory, or when connecting to a directory belonging to a project of which you are a member.
MAXC provides facilities for archiving files onto magnetic tape, where the cost of storing them is negligible. You can get an archived file back within one day. To archive one or several files, type
@Archive File file1 file2 . . .
(Note that the command name consists of the two words "Archive File"; after that you should type the names of the files you want to archive.) The files will be archived onto tape within a day or two. After this has been done, they will be deleted from the disk automatically, and you will get a message notifying you that the archiving has been done.
MAXC keeps track of your archived files in an archive directory which you can list exactly like your regular MAXC directory, using the Interrogate command rather than the Directory command; for example,
@Interrogate *.bravo
If the listing is of just one file, MAXC will ask you whether or not you want it retrieved from the tape. If you say Yes, the file will appear on your MAXC directory within a day, and you will get a message to that effect.
Because MAXC's disk capacity is fairly small relative to the number of users who have MAXC accounts, the disk occasionally becomes full and it becomes necessary for a forced archive to be performed in order to make some space available. In a forced archive, all files that haven't been referenced (retrieved, printed, or whatever) in the past 90 days are written onto tape and deleted. You will be notified when any of your files are archived for this reason, and the procedure for getting them back is the same as given above.
1.4 User Profile	Warren Teitelman
A number of components of Cedar permit the user to tailor Cedar's behavior along certain predefined dimensions via a mechanism called the user profile. Whenever you boot or rollback, your user profile is consulted to obtain the value for these parameters. This operation is performed by consulting a file whose name is <YourName>.profile, e.g., MBrown.Profile, or if no such file exists, User.Profile. The entries in this profile are of the form 
Key: Value
where, for any given key, the value is expected to be either TRUE/FALSE, a number, or a token (a sequence of characters delimited by SP, CR, TAB, COMMA, COLON, or SEMICOLON, or an arbitrary sequence of charcters delimited by quotes), or a sequence of tokens. Comments can appear at any point in the profile, and are ignored. 
More information may be found by examining UserProfile.doc, which lists all the currently available options.
1.5 Walnut	Rick Cattell
The program for reading and sending electronic mail in Cedar is called Walnut.  It uses the database management system as a repository for the messages.  The documentation for Walnut can be found in the file [Indigo]<WalnutDoc>HowToUseWalnut.press; a copy of this documentation appears as a later chapter of this manual. 
1.6 Maintain	Andrew Birrell
Various administrative tasks associated with mail, authentication and other uses of Grapevine can be performed with the Maintain command.  Bringover and RunAndCall Maintain.  Its interface is layered according to the complexity of the operations various people need to perform.  Many users will need only the level called "normal".  This allows you to inspect distribution lists, add or remove yourself from lists, and change your password.  When using Maintain, you must always specify names in full.  Thus, you must say "CSL^.pa", not "CSL^", and "Birrell.pa", not "Birrell".
To look at a distribution list (a "group" in Grapevine terminology), fill in the text field labelled "Group" and left-click the "Members" button in the first line labelled "Type".  The "Summary" button in that line will show you the access controls associated with that group (which control who may add or remove members).  To add yourself to a group, fill in the "Group" field and left-click "Self" in the line labelled "Add".  Similarly, you can remove yourself with the line labelled "Remove".  Not all groups allow you to add or remove yourself.  If you're not allowed to change the group, you should send a message to the owner of the group asking for the change.  For example, you would send a message to "Owner-CSL^.pa" to ask about "CSL^.pa".
For the sake of security, it is a good idea to change your password occasionally (say, once a year). To do this, make sure your name is in the text field labelled "Individual", fill in your new password in the line below, labelled "Argument", then left-click "Password" in the line labelled "Set".  Passwords should be at least six characters and unpronouncable.  If you have an account on MAXC you will need to change the password there via Chat, type
@Change Password (of directory) name (old password) xxx (new password) yyy
1.7 Setting up your disk	Eric Schmidt, Ed Taft
1.7.1 Getting to Othello
Othello is a general Pilot utility for setting up disks. There are variety of paths to Othello. On an arbitrary machine in an arbitrary state hold down BS, RETURN, and ' while booting (on a Dorado, push the boot button three times in quick succession). This places you in the Network Executive. The type-in conventions are simple: ? lists the possible commands, BS backspaces, DEL cancels the current line. To start up a program from the NetExec, simply type the name of that program followed by RETURN or ESC. In fact, you need only type enough of the name to distinguish it from all the others; we shall underline only that portion your need to type before the RETURN. You are currently on your way to Othello; type 
>MesaNetExec
placing you in the Mesa Network Executive which has similar typing conventions. From there type
>OthelloDorado.pb  
or
>OthelloD0.pb 	(For historical reasons Dolphins are sometimes called D0's.)
depending upon whether you are using a Dorado or Dolphin. If you are in the Cedar world already, you can simply boot Othello with the Boot button at the top of the screen.
When Othello starts, it will ask you to log in. You must supply your Grapevine registered name and correct password before Othello will permit you to do anything else.
Now that you are in Othello you can use the standard command files described below for initializing disks and getting releases. If you want to do non-standard things with Othello see section 4.8 of [G5].
Here are a few fine points about starting Othello:
When starting with a new disk which you plan to erase and format, you should say
>Switches: n 
to the Mesa Network Executive before starting Othello. This prevents Othello from attempting to put the existing file system on-line when it starts up. It also permits you to log in as yourself even if someone else's credentials are installed on the disk; however, all Othello will allow you to do is to erase the diskyou cannot examine the existing contents of someone else's disk by this means.
On a Dolphin, if you ever want to boot your Cedar system from Othello rather than the boot button, you must call for the Cedar microcode by typing
>SetVersions for germ and microcode
Germ: D0.eg 
Microcode: CedarD0.eb 
to the Mesa Network Executive before starting Othello.
1.7.2 Getting a New Release
The next section describes how to start with a brand new, unformatted disk. This section assumes you already have a Cedar world set up, are happy with the distribution of space among your volumes, but would like to upgrade your system to the latest release. (If you want to change the volume structure read pp. 40-41 of [G5].) If you have just set up your disk, there is no need to perform these operations.
First, you should perform some disk clean-up. There are two possible levels of clean-up: deleting all the old BCDs and symbols files or erasing the volumes. You should at least do the former if there is any chance that the new release introduces new versions of things. No end of confusion will result if old versions of BCD files get mixed in with the new things. Erasing a volume takes longer and requires that you evacuate and recover personal files, but it promotes compact files, clean directory structures, and other healthful things. The utility DFDisk [G3] is useful in figuring out what you need to save. To erase your Cedar Client volume, get into Othello and type
>Erase 
Logical Volume Name: Client 
Are you sure? [y or n]: y
Whether or not you erase, you can get latest release's boot files by typing
>@ 
Command file: [Indigo]<Cedar>top>DoradoRelease.cm
or
Command file: [Indigo]<Cedar>top>D0Release.cm
New microcode, germ, and boot files will be fetched. On a Dolphin you will be put back into the Alto world; boot while holding down P. On a Dorado you will be put directly into the Cedar world.
Getting a new release takes under two minutes, so only the most impatient people will want shortcuts for updating a single item like the microcode. They should read the command file to see how to do it.
1.7.3 Initializing a Disk
You should only do this step on your personal disk or machine; don't do this to a public machine's disk! This initial setup should work no matter whether your disk is blank, smashed, or already contains a working version of Cedar. Besides taking time, this initial setting up discards the record of bad pages each disk has, so you do not want to reformat your disk gratuitously. If you have a functioning Cedar world and just want to get a new release or clean up your disk, go back to subsection 1.7.2.
To initialize a Dorado that has a new, unformatted disk, type to Othello
>@
Command file: [Indigo]<Cedar>top>FormatNewPrivateDorado4.cm 
It is assumed that you have an Alto world on partition 5 of your disk. This command file will take the other four partitions of the Dorado's disk (1, 2, 3, and 4) and create four Pilot logical volumes: the Client volume for Cedar, the Debugger volume for CoCedar, the Othello volume for general utility, and the Booter volume for checkpoints. When the cedar tree cursor appears, go back to section 1.0. 
If for some reason, you want to recreate standard logical volumes on a disk that has already been formatted with partitions 1, 2, 3, and 4 dedicated to Cedar, use the command file [Indigo]<Cedar>Top>MakeDoradoDisk4.cm.  This command file is identical to FormatNewPrivateDorado4.cm except that the physical volume is not reformatted and your list of bad disk pages is kept.

For Dolphin users, some ground rules:
(1) Your Dolphin should have 768K words of real memory, indicated by 3072 appearing on the maintenance panel while you are in the Alto world. The hardware maintenance staff will add memory to your Dolphin upon request. Make sure you have the latest memory controller upgrade, too.
(2) You should dedicate 3/4 of your disk space to Cedar/Pilot. This assumes that you are using your Alto partition for just Bravo, SIL, and other nostalgia items. If you don't now have a small Alto disk partition, here is how to convert: FTP all personal files from your disk to some safe place, like a file server; CopyDisk from [Indigo]<BasicDisks>Mesa6-14.bfs to BFS1; finally, FTP your personal files back.
To initialize a Dolphin Cedar world, type to Othello:
>@
Command file: [Indigo]<Cedar>top>FormatNewPrivateD0.cm 
After about fifteen minutes, you should have an initialized Dolphin with 3/4 of its disk space dedicated to Cedar. You will have three volumes on your machine: the Client volume for Cedar programs, the Othello volume for general utility, and the Booter volume for checkpoints. Note that there is no Debugger on your disk. Use BugBane for common bugs and teledebugging for cases BugBane can't handle. A person with a Dorado will be happy to help you teledebug. 
After all this you will find yourself back in the Alto world. Boot the machine while holding down P, and you should be in the Cedar world, looking at the cedar tree. Go and read section 1.0.
If for some reason, you want to recreate standard logical volumes on a disk that has already been formatted with 3/4 of the disk dedicated to Cedar, use the command file [Indigo]<Cedar>Top>MakeD0Disk.cm.  This command file is identical to FormatNewPrivateD0.cm except that the physical volume is not reformatted and your list of bad disk pages is kept.
If you want to devote your entire Dorado disk to Cedar (and eliminate the Alto partition entirely) then use the command file [Indigo]<Cedar>top>FormatNewPrivateDorado5.cm.  This will destroy everything already on the disk, so be sure you have saved anything that you want preserved.
If you wish to configure your disk in other than the standard way (e.g., to use all of a disk for Cedar on a Dolphin), consult a wizard.
1.7.4 Other Othello commands
If you find that you use Othello a lot, you may want to set things up so that the default action upon booting the machine is to start Othello rather than to boot or roll back your Cedar Client world.  This enables you to get to Othello directly rather than via the long excursion through the MesaNetExec.  The procedure for setting things up this way is:
>Set Physical volume boot files
Logical volume name: Othello 
Set physical volume boot file from this logical volume? Yes
Set physical volume pilot microcode from this logical volume? Yes
Set physical volume germ from this logical volume? Yes
Are you sure? Yes 
>Set Debugger pointers
for debuggee logical volume: Othello 
for debugger logical volume: Debugger 
Are you sure? Yes
From Othello, you can roll back your Client world by saying "RollBack Client"; you can boot your Client world by saying "Boot Client" followed by two CRs; and you can go directly to the debugger either by typing CTRL-SWAT (the SWAT key is the unmarked one next to the right SHIFT key) or by saying "Boot Debugger" and specifying switches of "w".
1.8 General Failure Modes
You may have the misfortune to encounter a bug in the Cedar system that causes it to crash. There are various ways to recover from crashes.
If you seem to be stuck and the maintenance panel lights (on a Dorado they actually appear on the screen) say:
910:	This is displayed while booting or world-swapping and does not indicate a failure.
912:	Version mismatch between the germ and boot file. Consult an expert.
915:	Cedar tried to transfer control to a world-swap debugger, but there isn't one on your local disk. See section 2.3.
920:	This is displayed while booting or world-swapping and does not indicate a failure.
921:	An unrecoverable disk error occurred while booting or world-swapping. Try again; but if the problem persists you may need to rebuild your file system.
922:	An Etherboot of Othello or some other program timed out; try again.
923:	Something about your germ or boot file is wrong, try getting a new release of Cedar (per section 1.7.3)
933:	Something about your machine has changed since the Cedar checkpoint and/or Debugger image was installed on the disk.  Most likely either the disk pack was moved to another machine or the machine's Ethernet address was changed.  Boot the Debugger, boot the Client, and remake the checkpoint.
937:	Unable to get the time from the Ethernet, most likely due to Ethernet or time server failure, but possibly due to a hardware problem in your machine.  If repeated failures occur, consult a wizard.
957:	This is a symptom of a hardware problem on Dolphins. Notify the hardware maintainers.
960:	Wait for a while, possibly even 20 minutes. Your disk is being garbage-collected. Be patient; booting merely starts the process over again.
Anything less than 900 typically indicates a microcode or hardware problem. Maintenance panel codes less than 900 usually occur only on Dolphins. See [G6] for a list of Dolphin maintenance panel codes. On a Dorado, a hardware or microcode-detected error usually halts the machine; the usual manifestation is that the screen turns completely black or gray with diagonal stripes.  Maintenance panel codes above 900 but not in the above list are usually but not always due to hardware problems also.
If the maintenance panel says 990 (or, on a Dorado, no numbers are visible), but there is no response to keyboard or mouse input, you need to get control somehow. In general, there are several levels of fall-back to try. Starting from the least drastic:
0. Go to a world-swap debugger by typing CTRL-SWAT; the SWAT key is the unmarked one next to the right SHIFT key. You can look around and then resume without losing anything.  If your machine doesn't have a world-swap debugger installed, this may produce a maintenance panel code of 915, as described above.
1. Type CTRL-LEFTSHIFT-SWAT to get to a world-swap debugger "delicately".  As with the previous step, this can produce a maintenance panel code of 915.
2. Left-click a Stop button or type CTRL-DEL in a viewer. This will sometimes stop a run-away program and get the system behind the viewer to listen.
3. Perform a rollback (or boot if no checkpoint file exists) using either the Rollback button or the physical boot button. This loses whatever is in virtual memory and open files.
4a. On Dorados, boot by a three button boot, holding down C. This fetches new microcode from the net.
4b. On Dolphins, press the start button on the maintenance panel and then perform step 2. The main difference between a keyboard boot and a maintenance panel boot is that the former requires the disk to be spun up and the machine already to be in a fairly good state, whereas the latter will start the machine from an arbitrary state.
If the above methods fail to get your Cedar World up, there are problems with your file system.
5. There are various scavenging procedures available under Othello, described in [G5]: Check Drive, Scavenge, Physical Volume Scavenge, and DEScavenger. Get an expert to help you with these. These might recover the situation without much information loss.
6. Erase your client volume and get a new release, losing all non-backed up files. See section 1.7.3.
7. Initialize your disk and get a new release. See section 1.7.2.
2. Programming in Cedar
2.1 Running programs
You might try running the following example program:
DIRECTORY
IO USING [GetInt, PutF, CreateViewerStreams, int, STREAM],
UserExec USING [CommandProc, RegisterCommand]
;
Test: CEDAR PROGRAM IMPORTS IO, UserExec = BEGIN
in, out: IO.STREAM;
Compute: UserExec.CommandProc = BEGIN
i, j: INT;
out.PutF["Type me a couple of numbers: "];
i _ in.GetInt[];
j _ in.GetInt[];
out.PutF["The sum of %g and %g is %g.\n", IO.int[i], IO.int[j], IO.int[i+j]];
END;
[in, out] _ IO.CreateViewerStreams["Compute.Log"];
UserExec.RegisterCommand["Compute", Compute];
END.
To create this file left-click New, copy this text into the new file, and store the file as test.mesa (using the Files sub-menu). You then compile and run it with the following interaction:
&1 compile test
Loading Compiler.bcd. . .
Compiling: test . . . . . . no errors
End of compilation
&2 Run test
&3 Compute 
Now left-click anywhere inside the new viewer named Compute.Log, and type in two numbers, followed by a RETURN. 
2.2 System Models	Eric Schmidt, Ed Satterthwaite
As soon as you start dealing with a system of programs you should consider using a system model to describe and control them [G7]. There are two benefits: the modeller will figure out what you need to re-compile automatically, and it will replace modules in a running system so that you needn't always restart your program after fixing a bug. The following is a trivial system model whose only component is the test program from above.
-- Trivial.Model, 24-Jun-82 17:53:12 PDT
OPEN @BasicCedar.model;
Trivial: PROC [IOImpl: IO,
UserExecImpl: UserExec,
RopeImpl: Rope] RETURNS [] [
Bringover: TYPE == @Bringover.bcd;   -- detour to avoid parser bug 
Main: CONTROL == @Test.Mesa
]
The parameters of the procedure Trivial are implementations for the three interfaces IO, UserExec, and Rope. Those interfaces are types declared in the file BasicCedar.model. When you run this model the implementations will be supplied from already loaded programs.
To start the modeller type
run model
This will bring up the Modeller viewer. Type trivial in for ModelName and left-click StartModel to tell the modeller to read in and analyze the model. A series of messages to appear in the modeller's lower window, concluding with a line of dashes. Left-click Begin to start the program. This might cause Test.mesa to be compiled; you must give it permission to compile (remember to left-click inside the viewer first) by typing Y. The program will be loaded, the Compute.Log viewer will appear, and the command Compute can be invoked from the User Exec, as before. 
To change the program to behave differently edit Test.mesa to change the "+" to a "-" and "sum" to "difference". Save the file and left-click Continue in the Modeller menu. This will cause Test.mesa to be recompiled and reloaded. Invoke "Compute" from the User Exec again and try the new program. The modeller may be shut down in an orderly way by left-clicking StopModel.
Currently, BugBane (see 2.3) may get confused about which version of the module you are talking about. You should use the ResetCache button after each module replacement. 
2.3 BugBane	Russ Atkinson
BugBane provides the Cedar debugging facilities, which include a basic interpreter, primitives for controlling programs by setting breakpoints, proceeding from breakpoints, and other such services. These facilities are available to the user through the UserExec as described in section 1.2.  
Interpreter	
The interpreter has access to all names defined in the global frames of loaded programs (including types) plus all names in a special name space local to the interpreter. These special names all begin with &.  
The interpreter handles a subset of Cedar expressions. The following summary of the subset language is from the BugBane documentation [G8]:
constants          	fixed, REAL, Rope.ROPE, CHAR, BOOL, enumerated
simple variables	evaluated according to search rules below
x.y                  	x is a RECORD, REF or POINTER TO RECORD, global frame
x[y]           	x is a SEQUENCE or ARRAY, REF or POINTER TO SEQUENCE or ARRAY
P[args]          	P is a PROCEDURE taking given arguments
RT[args]         	a RECORD constructor where RT is a RECORD type
LIST[exprs]      	evaluates a list of expressions, producing a LIST OF REF ANY 
X _ Y          	X and Y are expressions
The interpreter handles expressions containing arithmetic and logical operators (such as + and OR), and conditional expressions (IF but not SELECT.) Sometimes it is necessary to write parentheses around an expression to prevent the interpreter from getting confused. In general, you must prefix a procedure name with the name of its interface or implementation module; e.g., Rope.Cat. However, if you evaluate an unadorned interface or implementation module name, e.g., List, unprefixed names on later lines are interpreted relative to that module.
In looking up a name, the interpreter
Checks to see if the name begins with &, and if so it binds to the named &-variable.
Otherwise, it searches the global default context, if any. The global default context can be set by interpreting an unadorned module as described above, or via the UserExec command SetContext.
Otherwise, it searches the current local context, if any. The local context is the sequence of local frames and associated global frames in the call stack of the stopped process. See discussion of Action Areas under section 1.2. 
If this fails, it searches the space of all interface names exported by loaded program modules. If multiple instances of the same program module have been loaded, only the most recent one will be seen. Also, the association of interfaces and programs works most of the time, but may fail.
If this fails, it tries to match the name with the name of a loaded program module (subject to the three restrictions just mentioned). This search will not find individual components such as variables contained in these global frames; such components must be qualified by the module name.
Since the name lookup process can take a long time, it runs for only a certain time, and then says that the name is undefined. If you know that a name in question would be found if it searched further, you should follow the name with !. This will cause the lookup process to try with all its might and all your time. However, you can always tell the lookup process to stop by typing CTRL-DEL or by left-clicking the Stop button in the Work Area menu.
CoPilot	
CoPilot is the backstop debugger for Cedar. See [G5] for a complete description. In the very near future, CoPilot will go away and be replaced by remote debugging in which the debugger is a full Cedar system. If you find yourself in a situation which seems to require knowledge of CoPilot, you probably should find a wizard.

3. References
In general, the following directories are worth browsing:
[Indigo]<Cedar>Documentation>* is the general repository for documentation.
[Indigo]<Cedar>Top>*.df will list pointers to things in the release
[Indigo]<APilot>* for Pilot stuff. There is a list mapping short file names to path names on Documentation>APilotFiles.txt
[Indigo]<Cedar>Documentation>Cedar3.5Xref.press, .txt is an inverted listing giving the DF file for every file in the release; it it helpful for finding things.
There are subdirectories of these directories depending on the package or subsystem involved. Use * liberally when in doubt.
3.1 General References
In the following assume the file is on [Indigo]<Cedar>Documentation> unless a full path name is explicitly given
[G1] Paxton, W., The Tioga Editor. In the Cedar Manual and TiogaDoc.press, .tioga.
The manual for the text editor and manuscript preparation system.
[G2] Brotz, D., Laurel Manual, CSL-81-6.
[G3] Schmidt, Eric, The DF Files Reference Manual, DFFilesRefMan.press.
[G4] Levin, Roy, Cedar Releases: Policies and Procedures, ReleaseProcedures.press/bravo
[G5] SDD, Pilot User's Handbook. On [Iris]<Pilot>Doc> PilotUsersHandbook.press.
You don't need all of it and it's a long document to print; borrow or obtain a hardcopy and look at pages 47-92 for Cascade documentation if you deal with CoPilot extensively.
[G6] Fiala, Ed, [Indigo]<D0Docs>MPCodes.*.
[G7] Schmidt, E. and Lampson, B., Cedar System Modelling Reference Manual, ModelRefMan.Press.
[G8] Atkinson, BugBane, [Indigo]<Cedar>BugBane>BugBane.doc, BBV.doc, BugBane.shorts, and BugBane.wish.
[G9] Horning, J. (ed.), The Cedar Catalog, In the Cedar Manual and Catalog.tioga/press.
A description of programs available for use and study.
[G10] Levin, The Release Messages, CedarRelease*.msg.
These messages describe the properties of each new release. They often contain vital pieces of information about known bugs and how to avoid them. Obviously, the information in older messages may be out of date.
[G11] Ornstein, Dorado User Rules, posted by sign-up sheets opposite CSL coffee room.
[G12] Ramshaw, The Alto/Dolphin/Dorado Briefing Blurb, [MAXC]<AltoDocs>BriefingBlurb.press. Describes (almost) everything there was to know about the basic CSL/ISL computer environment in 1981.
[G13] Lampson, B., Taft, E., Alto Users Handbook, November, 1978. The basic reference for using the Alto system.
[G14] Teitelman, W., Cedar UserExec, UserExec.tioga, .tioga.press
3.2 Cedar Language References
[L1] Mitchell, Maybury, and Sweet, Mesa 5.0 Manual, CSL-79-3, April, 1979. The Mesa documentation is fragmented across this and the next two references, so you need to be familiar with all three.
[L2] SDD, Mesa 6.0 Compiler Update, [Ivy]<Mesa>Doc>Compiler60.press.
[L3] Satterthwaite et al., Cedar Mesa 6T5, [Indigo]<CedarDocs>Lang>Cedar6T5.press. This is a detailed description of the Cedar language, assuming one knows Mesa. Some changes since this document are enumerated in a shorter document, Documentation>Cedar7T11.press.
[L4] Horning, J., Cedar Language Overview, Overview.tioga, .press; Lampson, B., Cedar Lanuguage Reference Manual, Grammar, and Summary, CLRM.press, CLRMGram.press, CLRMSafeGram.press, CLRMSumm.press; Mitchell, J., Annotated Cedar Examples, CedarExamples.tioga, .press.
[L5] Mitchell, J. Stylizing Cedar, cedarstyle.doc, .press, Cedar Style Sheet, stylesheet.sil, .press.

*Last edited	By Scott McGregor on October 12, 1982 9:57 am
					By Jim Horning on December 20, 1982 6:12 pm
					By Ed Taft on June 1, 1983 11:33 am
					By vanLeunen on June 6, 1983 10:55 pm
By	Jim Morris, Mark Brown, et al.

	
-- Test.mesa, last modified by Jim Morris July 8, 1982 12:31 pm
�ÊY–

"Cedar" style˜IblockšÏsœ.™9Kš�œ,™0Kš�œ$™(Kš�œ&™*K•MarkcenterHeaderš�œÏi™!K™Kš
œ
™
Kšœ
�œ
�œ�˜K–centerFooterš
�	˜	Ititleš
œ˜Isubtitleš
œ˜Iabstract˜NšÏb
œ¹
˜Ã
Nš
ϻ
˜ª
Nš
Ÿ¿
˜¿
K˜K˜Kš	ÏqœÏoœ¡œ¡œ¡˜qI	pagebreakš
Ñbox+˜+
contentsš
œ˜Pš
œ˜š
œ˜Pš
œ˜Pš
œ˜Pš
œ
˜
Pš
œ	˜	Pš
œ˜Pš
œ
˜
Pš
œ˜Pš
œ˜Pš
œ˜—š
œ˜Pš
œ˜Pš
œ˜Pš
œ˜—š
œ
˜
Pš
œ˜Pš
œ˜——
headš
œ˜Ibodyš
œ¹	˜¹	R˜*IitemšœJÐosÏm
œ£œ
˜|SšœT¡˜_SšœvÐoz	¡Ïz
˜‡
—	š
œ˜Rš
œ5˜5Sšœ#žœ‘
˜¸
Sš
œ€
˜€
Sšœ1£œM˜€
Sš
œŠ
˜Š
Sšœ4£œF˜|Ršœ’¡œ	¡œ¡œn˜¬	šœž
�	˜R˜ïR˜¢—	šœž
�˜.Rš
œ'Ïeœ‚
§œ7§œp§
œ%§œ*�‹
œ˜ß
š	œ—
§œ6§œn£œV§œ\˜ƒSš£
œ(˜)Sš£
œ(˜)Sš£
œ)˜*Sš£
œN˜OSš£
œ,˜-Sš£œ$£
œ˜=Sš£œ˜—
š
œ½
˜½
Sš¡œ˜$Sš¡œC˜ISš¡œ/˜2Sš¡œ)˜,Sš¡œ*˜-Sš¡œ)˜-Sš¡œ˜!—Ršœ7¡œ,¡œ{˜ç
Ršœ¢žœÅ˜íRšœgžœú
˜èRšœG§œÇ§œ9˜×RšœÈ
§œ¡œk˜æRš
œ…
˜…
Ršœ(§œ�˜ÄRšœ¡œõ˜‡Ršœ¡œç¡œV£œ˜ñRšœ¡œP˜fRšœ)¡œ}�
œ,˜Ö
RšœW¡œ'˜‚
Ršœ¯
¡
œÕ
¡œÿ˜•—	šœ
�˜Rš
œ´˜´	˜Rš
œÄ˜ÄRšœ“§œò
˜‰Rš
œñ˜ñRšœG¡œÍ
¦~œ˜˜—	˜Ršœ3žœá
¤
œ£œ£œy£œe¡œ£	œw˜ª
š	œ ¡
œ?¡
œ;¡
œE¡
œX˜»Rš
Ðbo¡
¥¡@¨¡
¥¡¨¡
¥ž
¡Í
˜Á—Ršœ£œq£œM˜â
—	˜
šœr¡
œ˜uSš¡
œÍ
¡	œ˜æ
š
œÕ˜ÕRš
œ½˜½—Sš¡œ2¡œ˜PSš¡	œ5˜>Sš¡œG˜VSš¡œ˜"Sš¡œ=¡œ
¡œ
˜_Sš¡œ˜!Sš¡œ˜Sš¡œ6˜;Sš¡œE˜ISš¡œ7˜;Sš¡œM˜XSš¡œ˜$Sš¡œ¡˜1Sš¡œ$˜'Sš¡œM˜SSš¡œU˜\Sš¡œ&˜*Sš¡œ ˜&—Rš
χ
˜á
—	š
œ˜RšœI¡œ˜¡œN¡
œn˜¨
š
œš
˜š
Rš¨¡¥Ðmz
ž9¡˜\Rš¨¡¥©
ž6¡˜_Rš¨¡¥¡ž.¡(˜`Rš¨¡¥¡˜Rš¨¡¥¡˜$Rš¨¡¥©
¡Ðio+œ
¡˜ORš
¨¡¥©
œ
ž5¥
¡¥
¡œž¡'˜©
—R˜�
—	š
œ˜Ršœ¬¡œ
�
œK˜þ—	˜Ršœ–
¡œF¡œx¡œ	˜ë—	˜Rš	œ¡�œˆ
�]œÐ
¡œ¡œ
˜ÿ——	š
œ	˜	RšœI§œº
˜ˆ	šœ�˜$Ršœ‚§	œ	§	œè
˜…R˜þ

˜2S˜S˜-S˜8S˜'S˜DS˜!S˜S˜0S˜—R˜ìRš§œû˜‡
˜4Iindent˜8—
šœ"§œ;�œ8�œØ
§œ
�œ˜½T˜#—Rš	œá�œ¡
œ¡
œ@§œr˜ÇRšœ1§œ˜˜Ñ—	šœ�˜
šœL§œ
§œ›˜ïTš
�™˜™—
˜
Tš
¡˜—
˜´
Tš
�ð˜ð—
˜mTš
¡˜—
˜ò
Tš
¡%˜%—Rš
œŒ˜Œ—	šœ�
˜!
š
œî˜îSš¡	œ„
˜�
Sš¡œù
¡œ.˜´Sš¡œú
¡œ.˜¯Sš¡œ>¡œ
˜KSš¡œ¡œ™
˜²
Sš¡œ½
˜Ã
Sš¡œv˜~Sš¡œ+˜6Sš¡œ}˜ƒ
—
˜BSš¡œ6¡	œ¡œE˜œ
Sš¡œ(¡œ*˜\Sš¡
œ,˜6Sš¡œK˜VSš¡œU¡œ)¡œ˜°
Sš¡œ!˜&Sš¡œ¡œ4¡	œ¡œ4˜¸
Sš¡	œ¡œ8¡œ
˜bSš¡œ,§	œc˜¤
Sš¡
œ+˜8—Ršœ/¡œX˜‹
—	šœ%�˜;Ršœ9�œ�œ´˜÷
šœ>¡œ\¡
œÚ¡œ¡œ
¡œ˜ÔTš¡
¥¡¥¡¥˜&—RšœK£œ�œ£œ4˜¬

˜;Tš¡
¥˜—Ršœ¡œ�œ¡
œ�œf�œq�œ™
¡œ˜ÜRšœ�œ	�œ…
�œ�œ.¡
œW�œŒ
£œ˜ßRšœc�œ˜jIquoteš¡
¥	¡¥
¡¥¡¥
¡"¥
¡¦
˜MRšœ�œ˜Uš¡
¥¡¥
¡¥
¡¥˜<
˜³
Tš¡
¥˜—Ršœ�œ�œX§
œ´˜¥
˜?Tš¡
¥¡¥¡¥˜4—R˜™

šœ
�œ§	œ 
˜Æ
Tš¡
¥¡˜—R˜Þ
šœ
�œ*§œ/�œY˜Ê
Tš¡
¥˜—Ršœ%�œp�œC˜Þ
Ršœ	�œK�œM§œÚ˜�——	šœ�˜!
šœŠ
§œ¨˜¾Tš
¡
˜
—Rš
œ…
Ïkœ«œ«œ«œ«œ«œ—
˜ÅR˜l—	šœ�˜Rš
œÁ˜Á—	šœ
�˜R˜ÁR˜î
šœ‡�œ:˜ÄTšœ
¥¡¥¡¥¡¥˜J——	šŸœ
�˜.	š
œ˜
šœ˜
£œ£œ¡
Ϣ
¡
œ£œ£œs£œ£œ˜
£œ1˜ÎTš¡
¥¡˜—
˜_Tš¡
¥	¡¥˜—
˜Tš¡
¥	¡›
 @
Ñmos
�<˜K—R˜«
R˜§
R˜Ë
R˜2
˜PTš¡
¥¡¥˜
—R˜�
˜’
Tš¡
¥¡)¥
¡¥˜G—R˜6—	š
œ˜R˜—
˜¢Tš¡
¥¡¥¡¥
˜>—
˜KTš¡
¥¡¥#˜5—
˜Tš¡¥˜-—Ršœ„
£œ:˜Á
R˜Ê
—	š
œ˜Rš§hœ�˜÷
˜HTš¡
¥¡¥.˜?—R˜“Ršœ´
¥%œ%¡œƒ
˜›S˜˜S˜š
˜5Tš¡
¥¡¥)˜:—R˜ÌRšœb£œY˜¾
Ršœª
¥ œ
¡œ"¡œ\˜àRšœ}¥-œp˜šRš
œˆ
˜ˆ
—	š
œ˜R˜âTš¡
¥¡/¥¡9¥
¡A¥
¡6¥
¡œ¦
œ¦œ.¦	œ¦
œ¦
œ˜ûRšœÔ
£	œ£œ*£œA˜Ù——	š
œ˜R˜‹

˜nS˜WS˜HS˜wS˜WS˜›
S˜HS˜lS˜§S˜É
S˜ZS˜�
—R˜ð
˜ý
Sšœ)£
œ£œ*£œÆ
˜³Sšœ£œ{˜—
Sšœ$£œi˜•
Sš
œ³
˜³
Sšœ:£œ(˜eS˜Î—
˜_S˜ÿ
S˜eSš
œA˜A———	š
œ˜	š
œ˜
˜4Iunitš
œ?™?š
«	˜	Icodeš«œ
«œ*«œ˜:Wšœ	«œ˜-Wš
œ
˜
—VšÏnœ«
œ
«œ«˜0Wšœ«œ
˜š®œ«˜%Wšœ«œ
˜
Wš
œ*˜*Wš
œ˜Wš
œ˜Wš
œM˜MWš«œ
˜—Wš
œ2˜2Wš
œ-˜-Wš«œ
˜—
šœ¡œO¡œG˜½
Tš
¨¡
¥
¡S¨¡
¥	¨¡
¥˜z—Ršœh£œ˜p—	šœ�˜0
š
œ³˜³Vš
œ(˜(Vš«œ˜š®œ«œ
˜Wš
œ˜Wšœ«œ˜Wšœ«œ4˜CWšœ«œ˜Wš
œ
˜
——R˜‰
˜Tš
¡	˜	—Rš	œ-¡œ!¡
œ¤
¡œ¤
£œ†
˜µRšœŽ
¡œÔ
¡	œ
˜ôRšœz¡
œ'˜«
—	šœ�
˜Rš
œ¤˜¤Qš
œ˜RšœÎ
¡
œ˜Ò

˜‹
Sš	œ«œ«œ«œ«œ˜BS˜:Sš	œ«œ«œ«œ
«	œ˜KSšœ«œ«œ«œ«œ
«œ«˜MSšœ«	œ˜9Sšœ«œ«œ˜@Sšœ?«œ
˜OSš
œ'˜'—Ršœ_«œ «œ«œå
¡œW¡œJ˜¤Rš
œ%˜%Sš
œT˜TSš
œÀ
˜À
Sš
ό
˜å
Sš
œ ˜ Sš
œ ˜ Ršœÿ£œ;˜Â	š
œ˜Rš¡
œÃ˜Ä—R˜——	š
Ÿ
˜
˜9S˜KS˜CS˜zS˜ 
—R˜|	š
œ˜Rš
œp˜pI	referencešœžœs˜”
Xšœž
œ˜(Xšœžœ˜GXš
œW˜WXšœ
žœà
˜ÿ
X˜*Xšœ"ž'œ˜]X˜fXšœžœe˜Ž
Xšœ
žœè
˜‰Xšœžœ4˜UXšœž&œ�œ…
˜Á
Xšœžœ@˜pX˜A—	š
œ˜Xšœ#žœ‘
˜Ã
Xšœ
žœ"˜DXšœžœžœÞ
˜‡Xšœžœ'ž6œPžœ˜ŒXšœžœžœ˜e———…—ùJÍ