Date: 1 Dec. 1982 11:18 pm PST (Wednesday)
Sender: Levin.PA
Subject: Cedar 3.5 release (part 1 of 2)
From: Release Master
To: CedarUsers↑, CedarImplementors↑
cc: CedarCoordinators↑
Reply-To: Levin
Cedar 3.5 is released.
Most major interfaces above the Pilot level have been recompiled, including IO,
Viewers and Tioga interfaces, and UserExec. Consequently, most client programs
will need to be rebuilt. The Compiler and Binder are unchanged from Cedar
3.4.1.
This release announcement differs somewhat in organization from previous
announcements. It consists of five parts:
Installation Procedure
Significant Changes in this Release
Known Problems
List of System Components
Summary of Release Component Changes since Cedar 3.4.1
This message contains the first three sections, which should be read and
understood before attempting to use this release. A subsequent message holds the
last two sections of the release announcement, which are quite long. These latter
sections can be treated as reference material and need not be read before
acquiring and using the release.
Installation Procedure
---------------------
This procedure assumes you have a machine with Cedar 3.4.1 installed. (Note to
alpha-testers of Cedar 3.5: this procedure works for you also. Don't attempt any
shortcuts.) Otherwise, refer to the "Setting Up Your Disk" section of
[Indigo]<Cedar>Documentation>Introduction.press
for further information. (Be sure you have the version corresponding to this
release.)
1) Get to Othello, either through the MesaNetExec or by booting your Othello
volume.
2) It is strongly recommended that you erase your Client volume before
installing Cedar 3.5. Doing so will improve performance (by eliminating
fragmentation) and failure to do so can result in peculiar failures at
unpredictable times, for which the only cure is erasing the volume. If
there are any files on the Client volume that you wish to save, save them
before proceeding. You may wish to use DFDisk (see documentation of
DFFiles component). To erase the Client volume, type Erase<CR> to
Othello. You will be prompted for the volume name, type Client<CR>.
Confirm as necessary.
3) Type @<CR> to Othello. You will be prompted for a command file
name. Type either
[Indigo]<Cedar>Top>DoradoRelease.cm or
[Indigo]<Cedar>Top>D0Release.cm
as appropriate. New boot files will be fetched for all volumes, as well as
new microcode and germ files.
4) On Dorados, Cedar will automatically be booted upon completion of the
command file. (Actually, the CoPilot volume will first be booted, after
which a physical volume boot will occur, causing Cedar to be booted. Be
patient.) On Dolphins, the Alto partition will be booted; hold down
the "P" key and press the boot button to boot Cedar.
5) During the installation dialogue, you will be asked if you wish to use a
personal DF file. If your personal DF file includes a personalized user
profile (many do), you should answer "No" to this question, since a profile
acceptable to Cedar 3.4.1 will almost certainly be unacceptable for Cedar 3.5.
There are significant changes in the options available through the user
profile (see below) that should be carefully considered. After installing
Cedar 3.5 with the default user profile but before making a checkpoint, you
can edit your personal profile suitably and the changes will be noticed
automatically.
As with previous releases, once the automatic installation procedure completes,
you may then optionally acquire lots of additional useful files by typing
BringOver /a CedarClientFat.df (Note: NOT /p)
to the UserExec. This will fetch the exported contents of most of the major
packages, whether released as part of the boot file or as separate BCDs. Users
with limited disk space probably shouldn't do this.
Once you have brought over all the desired files, you may wish to make a
checkpoint, using the button at the top of the screen.
Before beginning to use this release, you should read the remaining sections of
this message.
Significant Changes in this Release
----------------------------------
This section documents important changes in the user interface or major
components and briefly describes significant new components. The descriptions
here are incomplete and intended only to provide sufficient information to avoid
surprises and confusion. Users should consult the more complete descriptions in
the "Summary of Release Component Changes" section of this release
announcement.
1. Viewers and Tioga:
a) The "Grow" menu command is now a toggle, restoring the state of
previously opened viewers if clicked again after growing a viewer to the full
size of the column.
b) Clear, Get, GetImpl, PrevFile, and Save are no longer guarded.
c) "Unsaved" Documents Cache. It is not uncommon to forget to save the
contents of a viewer before destroying it or loading something else into it.
However this is not a disaster since Tioga holds onto "unsaved" documents so
you can reload them with edits preserved. The number of such documents that
Tioga will remember is set by a profile entry (UnsavedDocumentsCacheSize); the
default is four. Whenever there are unsaved documents, Tioga creates a special
viewer listing their names. Unsaved documents are put into the cache by
Destroy, Clear, Get, GetImpl, and PrevFile. They are not put in by Reset. If the
cache is already full when a new entry arrives, the oldest entry is discarded.
Whenever a file is needed for Get, GetImpl, or PrevFile, the cache is checked to
see if an unsaved version is available. "No Name" documents are not put into
the cache.
d) Automatic Mesa formatting via CTRL-M. During typein, it is now possible
to apply Mesa formatting without reselecting the recently-typed characters. If
CTRL-M and the current selection is a single character or less, the entire caret
node will be reformatted.
2. UserExec:
All Action area commands are now implemented by stuffing characters into the
executive. This means that everything you can do with buttons you can type,
and further means that there are no synchronization problems, i.e. you can click
set and then click proceed without waiting for the set to complete, because the
proceed won't happen until the set finishes. Feel free to button ahead all you
like. Note that it is still the case that clicking source or set break will grab your
input focus when the operation completes, so you can't, say, click "set" and then
start typing ahead. But you can click ahead all you want.
3. Editable typescripts:
Typescripts can now be edited as Tioga documents. (Actually, this is primarily
supported by enhancements to the IO package and interface.) You can adopt the
following simple rule for understanding how this works:
If the typein point is at the end of the typescript and there is a point selection,
then the program using the typescript will process the typein. Otherwise, Tioga
will process the typein and the program will not see it.
Users will probably notice this feature first in the UserExec typescripts. Here is
an example of how it might be used:
Suppose a user types the following to the UserExec
bringover userprofile io
and then realizes he has forgotten the /o switch, and wants to add .bcd after
userprofile. He simply points between "bringover" and "userprofile", types "/o",
yellow selects "userprofile" nearer to the right end, types ".bcd", hits the "next"
key, and types carriage return. This facility is also very useful in conjunction
with ESC (or redo ↑X), which will produce a previously typed line, but not
complete the input operation. The user can then quickly edit that line to insert
or remove characters and then complete the operation.
As a result of the typescript being editable, simply pointing at some place in the
typescript and starting to type will not have the same effect it used to: the
characters will be inserted at the place you selected. You must point at the end
of the typescript (or point anywhere and then use the "Next" key). For example,
in the UserExec typescript, typing "DEL" to cancel a partially-typed command
will only work if there is a point selection at the end of the typescript
(otherwise, it will simply delete the selected characters, if any). This may take a
little getting used to.
4. Walnut:
All Walnut actions are serialized, preventing previous anomalous behavior and
uncaught signals. Database commits run at background priority.
The Walnut control window has been re-arranged. NewForm appears in the
menu. Message Set buttons work differently: red-click deselects all and then
selects that one; blue-click "extends" the selection; control-blue deselects that
one. A Quit button has been added; the viewers' Destroy button does nothing.
Blue-clicking CloseAll makes the control window one-line high.
5. Checkpoints:
The checkpoint file is now a permanent file. This means that you can no longer
get rid of a checkpoint simply by booting. The approved way to do so is to
invoke CedarSnapshot.Delete from the interpreter. Booting the Booter volume
with the "S" switch will have the same effect.
6. IO interface:
The IO interface has been heavily edited using Tioga node structure so as to
provide documentation. IO.Comments and PF.Comments have been merged in.
Use level clipping to suppress detail when viewing it simply to jog your
memory.
7. Pilot interfaces:
PilotInterfaces now supplies a provisional "informational signal" mechanism. An
informational signal is just like a standard Mesa SIGNAL except that, if caught,
it must be RESUMEd or REJECTed, and if the signal propagates to the base of
the call stack, it is implicitly resumed instead of triggering an uncaught signal
action in the debugger. Note that a catch phrase for ANY also catches an
informational signal, which may not be what you had in mind. Consult the
description of the PilotKernel component for more details before attempting to use
this facility.
8. Runtime.df:
Runtime.df has been withdrawn and replaced by three new DF files:
a) SafeStorage.df replaces part of Runtime.df that exported the following
interfaces:
AtomsPrivate, RCMapOps, RTBases, RTLoader, RTOS, RTOSExtras, RTProcess,
RTRefCounts, RTStart, RTStorageAccounting, RTStorageOps, RTTypesBasic,
RTTypesBasicPrivate, RTZones, SafeStorage, UnsafeStorage
b) AMTypes.df replaces the part of Runtime.df that exported RTTypes and
related interfaces. It now exports the following interfaces:
AMBridge, AMTypes, RemoteRope, RTTCache, RTFiles,
RTSymbols, RTSymbolsPrivate, RTTBridge, RTTypes, RTTypesExtras,
RTTypesPrivate, RTTRemoteBridge, RTTypesRemotePrivate, SymbolTable
c) AMModel.df replaces the part of Runtime.df that exported
RTMiniModel.bcd, and now exports the following interfaces:
AMMiniModelPrivate, AMModel, AMModelBridge, AMModelLocation,
AMModelPrivate, RTMiniModel
Significant new packages:
9. NewStuffImpl:
This package comprises a collection of facilities that generally fall under the
category of creature comforts for Cedar: they are not essential, but they make life
more pleasant. These facilities are enabled by running NewStuffImpl.bcd, e.g. by
including "run newstuffimpl" in the CommandsFrom entry in your user profile.
They currently include (1) extensions to abbreviation expansion that enable the
construction of "fill-in forms" for various types, e.g. user types
Rope.Find{CTRL-E} producing Rope.Find[s1: ROPE, s2: ROPE, pos1: INT ←
0, case: BOOL ← TRUE]; (2) automatic creation/updating of date of last edit
comments at the front of a document; (3) automatic creation/updating of change
log entries at the end of a document (only works for documents that employ
node structure). NewStuffImpl.bcd is fetched to the local disk as part of the
automatic installation procedure. For more details, see
[Indigo]<Cedar>Documentation>NewStuff.tioga.
9. ViewRec is a package intended for quick and easy user interface construction.
Given a record, or the name of a DEFINITIONS module, it will construct a
Viewer on the components of that record that are simple enough (numbers,
ROPEs, enumerations, subranges of simple enough, records of simple enough
stuff, procedures that take simple enough stuff, or explicitly bound by the
client). The procedures may be invoked, and the data may be edited.
10. FlushUnneededTempFiles is a utility program that combs the disk for
orphaned temporary files and reclaims the disk space they occupy. These files
result from repeated rollbacks and can eventually consume many hundreds of
pages of disk space. It takes only a minute or so to execute, and thus is more
efficient of user time than booting, which accomplishes the same thing.
11. ScanZones is a utility for gathering and printing (on the file named
Storage.log) information about the utilization of collectible storage.
Known Problems
----------------
The following problem/glitch is known to exist in Cedar 3.5.
You will get an unbound imports message from the UserExec when you run
Print. This is because of some mail-file processing stuff that was removed from
the config a few releases back; don't worry about it. Don't try to use Print while
TSetter is sending something to the printer.
The Release Master