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 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.
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 ´, ?, 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. 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.
Help Provide more complete explanation of UserExec in a separate viewer.
List Print size and creation date for the indicated files.
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"]´ Note that Rope is the interface, not the implementation.
"Cedar"
&3 ← LIST[1, 3.2, &]´ & 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 LIST OF REF ANY
&5 ← &3.first^?
is of type INT
&6 ← &3.rest.first^?
is of type REAL
&7 ← List´
default interface changed to: List
{Interface: List}
&8 ← Appendd[Reverse[&3],&3]]´ 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 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.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.
2.1 Running programs
You might try running the following example program:
-- Test.mesa, last modified by Jim Morris July 8, 1982 12:31 pm
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 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 click anywhere inside the new viewer named Compute.Log, and type in two numbers, followed by a RETURN.
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 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.