<> <> Cedar 4.2 Release This release is primarily a "bug fix" release, although there are a significant number of new features as well. No public interfaces have changed since Cedar 4.1 (or 4.0), but a few private interfaces have changed. Users should read and follow the installation procedure (described below) carefully. **** Known Problems **** 1. If you use public Dorados and keep your mail on Alpine, you are strongly urged to read the Walnut message very carefully, in particular the part about using your login name as part of your mail log file name. The use of a common mail file name for multiple users has already caused problems in the alpha user community, and will surely plague those who ignore this warning. 2. Bringover will allow itself to be called concurrently from the FileTool and from the Bringover command. However, it will most likely fail in some unpredictable way if this is done. It is best to avoid FileTool usage of Bringover. 3. There are still a significant number of repainting bugs, particularly with viewers on color displays. Few of these bugs are especially harmful. **** 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]Top>DoradoRelease.cm To install Cedar on a Dolphin (whether or not you choose to erase volumes), boot the Othello volume, and type @ [Indigo]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. **** 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. Walnut no longer has its data base access (Cypress) or its Apine access (AlpineUserImpls) bound into it. Instead, it will load them as necessary. There are other significant changes to Walnut, so users should read the Walnut entry. 2. There is a new command, openHuge, that allows examination and editing of very large files (e.g., WalnutDB.log) without using very large amounts of virtual memory. See the RopeFile entry for details. 3. There is a new Germ, new Othello and new Dorado microcode. See the Init and Othello entries for more details. 4. There are some new packages, some of which simply encapsulate previously scattered material. See the new entries IconRegistry, Init, and Manual. **** 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]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]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]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: Heads>BasicHeadsCommon.df Heads>BasicHeadsD0.df Heads>BasicHeadsDLion.df 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: 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: 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. <> <> <> 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: 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: 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: Pilot>PilotKernel.df 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]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"