**** Installation Procedure ****
A machine already running Cedar 4.1 should upgrade to Cedar 4.2 with little problem. Although we recommend erasing your Client and Debugger volumes before installing, there is no unusual risk associated with using your current volumes if you follow the instructions below. If you must do things manually, be sure to install a new Germ, new Othello, and new Dorado microcode.
A machine running the prerelease of Cedar 4.2 needs the additional step of having the file named Cedar.version deleted from the disk before installing Cedar 4.2. Avoiding this step will cause trouble for you when PreCedar is erased. The recommended method, again, is to erase the Client and Debugger volumes.
For any user, to erase all files on your Client and Debugger volumes, boot the Othello volume, and type
erase Client
erase Debugger
confirming as necessary. Then you can execute the appropriate installation command file for your machine.
To install Cedar on a Dorado (whether or not you choose to erase volumes), boot the Othello volume, and type
@
[Indigo]<Cedar>Top>DoradoRelease.cm
To install Cedar on a Dolphin (whether or not you choose to erase volumes), boot the Othello volume, and type
@
[Indigo]<Cedar>Top>D0Release.cm
To install Cedar on a Dandelion, consult an expert.
As with previous releases, once the automatic installation procedure completes, you may then optionally acquire many potentially useful files by typing
BringOver /a CedarClientFat.df (Note: NOT /p)
to the UserExec or CommandTool. 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. Even users with lots of disk space may find the clutter irksome.
Once you have brought over all the desired files, you may wish to make a checkpoint, using the button (Checkpoint) at the top of the screen.
Before beginning to use this release, you should read the remaining sections of this message.
**** System components ****
The following is a complete list of the system components included in this release. Details about the relationship of each component to the previous release and pointers to documentation and DF files appear in the "Summary of Release Components" section, below.
The field after the package name indicates what has changed. It can take the following values:
new component is new for this release
old component is unchanged for this release (DF file is from cedar 4.1)
minor component only has minor bugs fixed and/or simple recompilation
major component has significant changes
gone component no longer exists
** Packages of general interest **
AMModel old In boot file
AMProcess old In boot file
AMTypes minor In boot file
Binder old
BootTool old
BravoToTioga minor
BugBane minor Partly in boot file (InterpreterPackage)
CedarReals old In boot file
CedarRoot minor In boot file
CedarScanner old In boot file
CedarSnapshot old In boot file
Chat old
CIFS old In boot file
ClientFileTool old
Clock old
CoFork old
Commander minor In boot file
Compiler old
Cypress minor
DateAndTime old In boot file
DebugTool minor
DFFiles minor
FileTool old
FileTransferCommands old
FlushUnneededTempFiles old
FootBall old
Forms !!!!!!
GrapevineUser old In boot file
Graphics old In boot file
IconRegistry new
IncludeChecker old
Init new installation command files
IntervalTimer old In boot file
InterpreterTool minor In boot file
IO minor In boot file
ListsAndAtoms old In boot file
Lupine old
Maintain old
Manual new
MCross old
Modeller minor
NewStuff minor
OnlineMergeSort old
PerfStats old
PlotPackage old
Poplar old
Print old
Pup old In boot file
Random old
ReadEvalPrint old In boot file
RedBlackTree old
RedBlackTreeRef old
Reminder old
Resource old In boot file
Rigging old In boot file
SafeStorage old In boot file
SampleTool old
Scaled old
Set old
SirPress old
Spell minor In boot file
Spy old
Squirrel major
STP old
Talker old
Tank old
Tioga minor In boot file
TIP minor In boot file
TSetter minor
UECP old
Unique old
UserExec minor
UserProfile minor In boot file
Viewers minor In boot file
ViewRec old
VTables minor
Walnut major
Watch old
Waterlily old
** Packages of special interest **
AlpineUse minor
AMEvents old In boot file
BasicHeads minor In boot file
BCD old
Booting old In boot file
BTree minor Replaces BTrees.df
BTrees old Obsolete. Use BTree.df for new stuff.
CIFSCommands old
ColorPackage old In boot file
Communication old In boot file
CompatibilityPackage old In boot file
D0Microcode old
DLionMicrocode old
DoradoMicrocode minor
Germ minor
IFSFile old
Inscript old In boot file
Lister old
Loader old In boot file
MakeBoot old
Othello minor Separate boot file
Packager old
PGS old
PilotKernel minor In boot file
Pupwatch old
RopeFile minor In boot file
RPCRuntime old In boot file
ScanZones minor
Sequin old
SpaceWatch old
SpecialTerminal old In boot file
STPServer old
TerminalMultiplex old In boot file
TTYIO old In boot file
UserCredentials old In boot file
UserCredentials old In boot file
VersionMap old In boot file
VersionMapBuilder minor
WorldVM old In boot file
**** Summary of Release Components ****
Note: In the descriptions that follow the DF file or files for a component are located on [Indigo]<Cedar>Top> unless otherwise specified. If the documentation file name is not a path, it is assumed to be accessible using the DF file name and BringOver, i.e.,
BringOver /o DocFileName DFFileName
In general, documentation is stored on
[Indigo]<Cedar>Documentation>ComponentName.tioga
but there are occasional exceptions. For brevity, we do not list Component.Press if Component.Tioga exists, and we do not include [Indigo]<Cedar>Documentation> in the file name if that is the prefix. If not specified, the host is assumed to be [Indigo].
Components are listed below only if there has been a change for this release. Unless otherwise indicated, questions about changes in individual components should be addressed to their implementors.
AlpineUser
DF files: AlpineUser.df
Documentation: see implementor
Implementor: Kolling
Minor bug fixes and some new commands in AlpineCmds. Contact the implementor if you are interested in using Alpine.
AMTypes
DF files: AMTypes.df
Documentation: see implementor
Implementor: Rovner
Minor bug fixes only.
BasicHeads
DF files:
<Cedar>Heads>BasicHeadsCommon.df
<Cedar>Heads>BasicHeadsD0.df
<Cedar>Heads>BasicHeadsDLion.df
<Cedar>Heads>BasicHeadsDorado.df
Documentation: See interfaces or see implementor
Implementor: Taft
Minor changes of interest only to Othello.
BravoToTioga
DF file: BravoToTioga.df
Documentation: see implementors
Implementors: Paxton, Plass, Mitchell
BravoToTioga converts bravo files to (roughly equivalent) tioga files. It is invoked from the UserExec by a command of the form:
BravoToTioga TiogaFile ← BravoFile1 BravoFile2 ... or
BravoToTioga ← BravoFile1 BravoFile2 ...
If the TiogaFile is omitted, the output file name will be the same as BravoFile1 except that it will have the extension ".tioga" instead of whatever extension (if any) BravoFile1 has. The output file is a concatenation of the converted Bravo input files.
The program attempts to map the paragraph and character looks in the Bravo files into equivalent Cedar.style node formats and character looks.
It does well on character looks such as bold, italic, superscript, subscript, underline, and the standard bravo fonts in the standard user.cm (from the Alto world, remember?).
It also does reasonably well at deducing node structure from Bravo indentation and has some simple heuristics for assigning node formats:
The default format is body.
If a paragraph looks like a section heading (i.e., begins with something like 5. or 2.3.1.) and has a look keep on it, it is given the head format.
If a paragraph has a look centered and a large ( >5") look keep, it is given the title format.
A paragraph with a look centered and not a large keep, is given the center format.
If a paragraph begins with a "(" and is indented with respect to a body paragraph, it is given the format item as is any paragraph following it with the same indentation and beginning with a "(".
The program does not do so well when character and paragraph looks interact. For example, in the Bravo world, section headings often have character looks as well (e.g., bold), while in the Tioga world, the format head determines a set of default character looks for that node. A converted Bravo section heading may have both the format head and character looks. It is up to the user to fix these sorts of things in the resultant Tioga file.
BTree
DF file: BTree.df
Documentation: BTree.tioga
Implementor: Taft
Minor interface changes required for FS.
BugBane
DF file: BugBane.df
Documentation: BugBane.tioga
Implementor: Atkinson
Mostly there have just been minor bug fixes. OctalCommands is now part of the InterpreterPackage, and is therefore in the boot file. See BugBane.tioga for a list of the commands. The only new interpreter feature is the ability to interpret v[tag], which forces overlaid variant record v to have the variant given by tag (a useful feature for debugging low-level stuff).
Commander
DF file: Commander.df
Documentation: Commander.mesa
Implementor: Rovner
Minor bug fixes only.
Cypress
DF file: Cypress.df
Documentation: <CedarDocs>Database>CypressDoc.press
Implementor: Cattell
Minor bug fixes only.
DebugTool
DF file: DebugTool.df
Documentation: see implementor
Implementor: Birrell
Minor bug fixes.
DFFiles
DF file: DFFiles.df
Documentation: DFFiles.tioga
Implementor: Schmidt, Atkinson
No functional changes were made. The 4.1 DFFiles software would sometimes exhaust Pilot's supply of large local frames (resulting in the message Out of VM for resident memory in CoCedar), so to reduce the size of local frames and reduce the number of GFIs used in the DFFiles software, the following changes were made:
Many uses of short STRING were replaced by LONG STRING, especially in SModel, BringOver, and VerifyDF. This required recompilation of the internal interfaces.
The UnsafeSTPs interfaces (UnsafeSTP, UnsafeSTPOps, UnsafeSTPRubicon) are now exported from the boot file, since BringOverPackage (which is in the boot files) now exports those interfaces. Therefore, UnsafeSTPs is no longer bound into any of the normal DFFiles programs, which makes them smaller.
DoradoMicrocode
DF file: DoradoMicrocode.df
Documentation: <DoradoDocs>DoradoBooting.press; see implementor
Implementor: Taft
An upward-compatible change required by the Cedar Nucleus.
Germ
DF file: GermDorado.df
Documentation: Pilot User's Handbook
Implementor: Taft
Rebuilt with current components.
IconRegistry
DF file: IconRegistry.df
Documentation: IconRegistry.mesa
Implementor: Teitelman
The purpose of this interface is to enable associating a name with an icon and allow client programs to obtain an IconFlavor for the corresponding icon without having to worry about which file the actual definition of the icon is stored in (and which icon index in that file). Furthermore, a cache is kept of the iconflavors that have already been created, so that the client can simply call IconRegistry.GetIcon each place that the corresponding icon flavor is desired without having to distinguish the first call from subsequent calls. This has the further advantage that if the definition for that icon is changed, or the icon is edited, the new representation will take effect.
Icons are defined either by including them in the local file RegisteredIcons.Catalogue, or in the user's profile using the key RegisteredIcons. Each entry is of the form form iconName: fileName index, where fileName can be a full path name. The definitons contained in RegisteredIcons.Catalogue and the user's profile will automatically be updated when the corresponding files are edited, or following a rollback. Only those entries that have been changed will be affected, i.e. unchanged iconflavors will be retained.
Icons can also be registered from programs via the procedure RegisterIcon.
The IconEditor has been modified so that it displays the registered name, if any, of the current icon. Icons can be registered by filling in the Name field and clicking the Register button. (This will also cause the definition for that icon to be written to the catalogue.) Whenever the IconEditor saves a file containing icon definitions, it invalidates the cache for all registered icons defined in that file. Thus, when you edit and save a registered icon using the IconEditor, the next call to IconRegistry.GetIcon will create a icon flavor corresponding to the newer version.
Init
DF file: Init.df
Documentation: Introduction
Implementor: Taft
The FormatNewPrivateD*.cm files have been modified to conform to the change in Othello's Format command. 10 passes of disk testing are now performed in order to do a thorough job of discovering bad spots; this takes somewhat longer than before (30 to 40 minutes).
InterpreterTool
DF file: InterpreterTool.df
Documentation: see implementor
Implementor: Rovner
Minor bug fixes only.
Manual
DF file: <CedarDocs>Manual>Manual.df
Documentation: Introduction & Donahue's Whiteboard Cedar
Implementor: Horning
Most of the inclusions of 3.5.2 software have been weeded out. The process of updating the contents continues. Catalog.tioga has been extensively updated.
Modeller
DF file: Modeller.df
Documentation: ModelRefMan.bravo, ModelRefMan.press
Implementor: Satterthwaite, Schmidt
Recompilation only for Modeller. DesignModel withdrawn.
NewStuff
DF file: NewStuff.df
Documentation: NewStuff.tioga
Implementor: Teitelman
Minor bug fixes only.
Othello
DF file: <Cedar>Othello>Othello.df
Documentation: Introduction, Pilot User's Handbook
Implementor: Taft
The Format command now asks for a number of passes, and writes and reads the entire disk using random data that number of times. This enables much more thorough testing and discovery of bad spots than was previously possible.
The Check command will also perform multiple passes if requested to.
PilotKernel
DF files:
<Cedar>Pilot>PilotKernel.df
<Cedar>Pilot>UtilityPilotKernel.df
Documentation: Pilot Programmer's Manual
Implementor: Levin
Two small but annoying bugs that could confuse CoCedar have been fixed.
RopeFile
DF file: RopeFile.df
Documentation: see implementor
Implementor: Atkinson
RopeFileImpl (not in the boot file) now supplies the command openHuge, which allows the user to open very large text or Tioga files, yet use little VM to do so. OpenHuge uses a file to provide the characters for a rope, rather than main storage. OpenHuge assumes that the opened file will not be changed within the range of characters used to backk the rope (using Tioga editing is OK, since it remanes the old file instead of overwriting it). If the file is overwritten, the system can be in a bad way, since Rope.Fetch may stop working for ropes extracted from the huge file.
ScanZones
DF file: ScanZones.df
Documentation: ScanZones.mesa
Implementor: Maxwell, Rovner
Added a facility for categorizing and reporting the garbage reclaimed according to its type.
Spell
DF file: Spell.df
Documentation: Spell.mesa
Implementor: Teitelman
Minor bug fixes only.
Squirrel
DF file: Squirrel.df
Documentation: SquirrelDoc.tioga
Implementor: Cattell (& Donahue, Maxwell, Willie-Sue)
This is the alpha release of the Squirrel package of database tools, previously for use only by database wizards. Most of the Squirrel facilities are now available to end users, for creating and examining databases for which no special database application code has been written or is worth writing specially (documentation, bibliographies, service directories). Squirrel is also intended for database application writers, for examining and repairing databases, and can be used to coordinate two or more database applications. The documentation is in two parts, aimed at the end users and database application writers respectively.
Tioga
DF file: Tioga.df
Documentation: TiogaDoc.tioga
Implementor: TiogaImplementors^.pa
No interface changes. Minor bugs fixed. SaveAllEdits will now generate a unique name for "No Name" viewers that have edits. Tioga now uses the Viewers bltContents protocol for faster screen repaints.
TSetter
DF file: TSetter.df
Documentation: TSetterDoc.tioga
Implementor: Beach, Plass
Minor bugs fixed.
Implemented marked nodes for running headers and footers. TSetter reacts to the Mark property and maintains a list of current marks for each page. Nodes with the Mark property will appear on the screen and can be editted normally. New page layout primitives used by BasicPrint.Style provide the means to extract selected marks.
BasicPrint.Style was overhauled to provide one-sided and two-sided page layout with running headers and footers, and to control page numbering. Cedar.Style was modified to resemble blue-and-white formats. Major changes: titles and abstracts are Helvetica family; leading for section headings; format body is now an indented paragraph. A new BlueAndWhite.Style provides the Tioga style for blue-and-white reports. See TSetterDoc.Tioga for more details.
Private style caveat: If a document uses a private style (read: not derived from the new Cedar.Style), the page numbers will be placed on top of formatted text. BasicPrint relies on a nonzero headerMargin supplied by the format root on the root node of the document. Either define an appropriate headerMargin or use (Cedar) AttachStyle in your private style. The StyleDef property on the root node is the preferred method of supplying private style rules.
Root node format caveat: If a document with Cedar style (or any style derived from it) does not have the format root, the page numbers will be placed on top of formatted text because headerMargin is still zero. Either remove the format from the root node or include an appropraite headerMargin definition in the StyleRule.
The new interface TSExtras.PrintSuppliedNodes provides a call-back procedure for printing collections of Tioga nodes or documents, e.g. Walnut message sets.
UserExec
DF file: UserExec.df
Documentation: UserExec.tioga
Implementor: Teitelman
Bug Fixes
UserExec no longer incorrectly reports {not loaded yet} for bcds that have registered command procs with commander.
New Features
The SetBreak, ListBreaks, and Source command now display in the corresponding work area: the name of the source viewer, the position within that viewer, and the corresponding line of text from the source.
Having walked the stack to a particular frame, you can later return to a frame by simply selecting in the event and clicking walkstack (assuming that you are still within the same action).
It is now possible to run remote files using the run command, e.g. run /indigo/cedar/... If you wish to load a program and call debugger before it is started, you can still use the /d switch, but it must be separated from the previous file by a space. You can also fetch remote files using the Fetch command described below.
If compiler.separateLogs is TRUE (the default), rather than producing a separate icon/viewer for each log, an errorLog menu button is posted in the source viewer, which can be used to open the corresponding error log. The button goes away following a successful compilation. The advantage of this scheme is that it halves the number of icons, and also eliminates the need for the user to visually search for the corresponding error log.
Whenever a mesa source file is saved, it is added to a list of files that need to be compiled that is maintained by the userexec. Similarly, whenever a compilation causes errors/warnings, the corresponding file is added to this list. A successful compilation will remove the file from this list. The icon used for a viewer onto one of these files differs from the normal document icon in that it has a black backdrop, so that you can readily see which files have to be compiled. The command CompileAll can be used to compile all files on this list.
New Commands
CompileBadGuys: Compiles those files whose most recent compilation caused errors or warnings. (CompileBadGuys{CTRL-X} will construct the corresponding command line, but not execute it, so that you can edit it, e.g. to remove certain files.)
CompileAll: Compiles everybody that needs to be compiled, i.e. all files that have been edited or whose compilation caused errors or warnings. (CompileAll{CTRL-X} will construct the corresponding command line, but not execute it, so that you can edit it, e.g. to remove certain files.)
ClearBreak: clears break points by number, e.g. clearbreak 3 5 7.
Fetch: Copies contents of remote file(s) to corresponding local file(s). Especially useful when somebody sends you the name of a remote file in a message.
CheckPoint: does a checkpoint.
RollBack: does a rollback.
BootCurrent: boots current volume.
Note: the previous three commands are useful in conjunction with compound commands, e.g. Bind mumble; rollback and the rollback won't happen if the bind fails. In the event that edits have been made but not saved, they will require confirmation.
UserProfile
DF file: UserProfile.df
Documentation: UserProfileDoc.tioga
Implementor: Teitelman
Minor changes to defaults only.
VersionMapBuilder
DF file: VersionMapBuilder.df
Documentation: see implementor
Implementor: Atkinson
Minor bug fixes only.
Viewers
DF file: Viewers.df
Documentation: ViewerDoc.tioga
Implementor: McGregor, Maxwell
No public interface changes. The keyboard command LeftShift-RightShift-Swat now invokes SaveAllEdits, which can help you save away edits in case of a system crash. John Maxwell has implemented the bltContents protocol for viewer classes, enabling faster screen repaints when viewers are rearranged.
VTables
DF file: VTables.df
Documentation: see implementor
Implementor: Atkinson
Minor bug fixes only.
Walnut
DF file: Walnut.df
Documentation: WalnutDoc.tioga
Implementor: Willie-Sue
To retrieve the necessary files for running Walnut, use
Bringover /a /p [Indigo]<Cedar>Top>Walnut.df
This will retrieve Walnut.bcd, WalnutSend.bcd, Cypress.bcd and AlpineUserImpls.bcd, so don't be surprised.
Walnut changes
(a) WalnutSend and Cypress are not bound into Walnut. When Walnut starts running, it checks for and loads WalnutSend, Cypress, and AlpineUserImpls (if the latter is needed!).
(b) Walnut will catch transaction abort from Alpine, and restart gracefully. If there is an uncaught signal during initialization, you can now safely abort the signal and Walnut will destroy itself.
(c) At checkpoint time, Walnut no longer destroys its viewers; they get rebuilt at rollback time; if any displayed messages or messages sets have been destroyed since the checkpoint, their viewers are destroyed. Note that when message set displayers get rebuilt, they are positioned at the beginning.
(d) You can execute WalnutScavenge from the exec or cmd while Walnut is running; it takes down any msg or msgset viewers but leaves the control window up. Executing WalnutScavenge or WalnutExpunge while Walnut is not running creates a typescript, so you can keep track of its progress; control does not return to the exec or cmd until the scavenge or expunge is finished.
(e) If you explicitly login to change users, or change your WalnutSegmentFile or WalnutLogFile by editting your profile, Walnut will force you to quit; you can then restart.
WalnutSend (6/02/83) changes
(a) Node structure in the headers will not confuse the parser.
(b) Right-clicking Send will close the viewer after it has checked for syntax errors or the need for a reply-to field; if you have DestroyAfterSend enabled, it will still work as well (right-clicking).
Caveats and known problems
When Walnut catches an abort from Alpine, the current action may or may not have been written on the log (this will get fixed), and hence may or may not get done after restart; subsequent actions will have been flushed.
If you use Alpine for your database and include Walnut in a checkpoint, you should run AlpineUserImpls first, then call Walnut.
Walnut Message viewers and Senders do not get reconstructed properly if you put them on desktops, or use the Clean button.
Occasionally, the text inserted by WalnutSend will be in bold; cause unknown and under investigation.
It is best to not scroll or thumb a message set displayer while it is being constructed; you can end up with large blank areas in the middle. Wait until the menu appears.
Suggestions
If you are using a public Dorado for reading mail, it is strongly urged that you name your walnut log file something other than Walnut.DBLog (the default); e.g.,
Walnut.WalnutLogFile: "YourName.WalnutDBLog"