Date: 7 Oct. 1982 11:58 pm PDT (Thursday)
Sender: Levin.PA
Subject: Cedar 3.4 release (part 2 of 2)
From: Release Master
To: CedarUsers^, CedarImplementors^
cc: CedarCoordinators^
Reply-To: Levin


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 components whose names are preceded by an
asterisk can be ignored by the casual Cedar user.

*BasicHeads			*Changed*		Implementation in boot file
BBV				*Changed*		Implementation in boot file
*BCD				*New*
Binder			*Changed*
*BootClientFile
BravoToTioga		*Changed*
*BTrees			*Changed*
BugBane			*Changed*		Implementation in boot file
*CedarControl		*Changed*		Implementation in boot file
*CedarDB			*Changed*
CedarReals			*Changed*		Implementation in boot file
CedarSnapshot		*Changed*		Implementation in boot file
Chat				*Changed*
CIFS				*Changed*		Implementation in boot file
*CIFSCommands		*Changed*
CoFork			*Changed*
Clock				*Changed*
*ColorPackage		*Changed*		Implementation in boot file
*Communication		*Changed*		Implementation in boot file
*CompatibilityPackage	*Changed*		Implementation in boot file
Compiler			*Changed*
*CoPilot
*D0Microcode
DateAndTime		*Changed*		Implementation in boot file
DFFiles			*Changed*
*DLionMicrocode		*Newly Released*
*DoradoMicrocode		*Changed*
FileTool			*Changed*		Implementation in boot file
Forms				*New*
*Germ			*Changed*		Separate boot file
GrapevineUser		*Changed*		Implementation in boot file
Graphics			*Changed*		Implementation in boot file
*IFSFile			*Changed*
IncludeChecker		*Changed*
*Inscript			*Changed*		Implementation in boot file
IO				*Changed*		Implementation in boot file
*Lister			*Changed*
ListsAndAtoms		*Changed*		Implementation in boot file
*Loader			*Changed*		Implementation in boot file
Lupine			*Changed*
Maintain			*Changed*
*MakeBoot			*Changed*
MCross			*Changed*
*MesaScanner		*Changed*
Modeller			*Changed*
OnlineMergeSort		*Changed*
Othello			*Changed*		Separate boot file
*Packager			*Changed*
PerfStats			*Changed*	
*PGS				*Changed*	
*PilotKernel			*Changed*		Implementation in boot file
*Pine				*Changed*
PlotPackage			*Changed*
Poplar			*New*
PressPackage			*Changed*
PressScreen			*Changed*
Print				*Changed*
PriorityQueue		*Changed*
Pup				*Changed*		Implementation in boot file
*Pupwatch			*Changed*
Random			*Changed*
RedBlackTree		*Changed*
RedBlackTreeRef		*Changed*
Reminder			*New*
Rigging			*Changed*		Implementation in boot file
*RPCRuntime		*Changed*		Implementation in boot file
Runtime & RuntimeTypes	*Changed*		Implementation in boot file
SampleTool			*Newly Released*
*Sequin			*Changed*
Set				*Changed*
SirPress			*Changed*
Spy				*Changed*
Squirrel			*Newly Released*
STPServer			*Changed*
*TerminalMultiplex		*Changed*		Implementation in boot file
TJaMGraphics		*Changed*
TSetter			*Changed*
*TTYIO			*Changed*
UECP				*Changed*
Unique			*Changed*
UserCredentials		*New*		Implementation in boot file
UserExec			*Changed*		Implementation in boot file
*VersionMap		*Changed*		Implementation in boot file
Viewers & Tioga		*Changed*		Implementation in boot file
VTables			*Changed*
Walnut			*New*
WalnutSend			*Changed*
Watch			*Changed*
Waterlily			*Changed*
*WorldVM			*Changed*		Implementation in boot file


Summary of Release Components
-------------------------------

Note:  In the descriptions that follow, 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.press

but there are occasional exceptions.

BasicHeads
----------
DF files:
  [Indigo]<Cedar>Heads>BasicHeadsDorado.df
  [Indigo]<Cedar>Heads>BasicHeadsD0.df
  [Indigo]<Cedar>Heads>BasicHeadsDLion.df
  [Indigo]<Cedar>Heads>BasicHeadsCommon.df
Documentation:  see interfaces
Implementor:  Taft 

BasicHeadsDLion is a new submission: Dandelion heads which exactly parallel
the Dorado and Dolphin versions.

The heads now export a new interface, EthernetOneFaceExtras, which provides
multicast facilities needed by the Voice server.  The Dorado implementation is
the only one which actually works; the others are dummies.

BBV
----
DF file:  [Indigo]<Cedar>Top>BBV.df
Documentation:  BBV.doc
Implementor:  Atkinson 

Numerous minor changes, but not much user-level change.  BBV is now
declared to be temporary, until equivalent function is available through the
UserExec.  See BBV.doc for more information.

BCD
----
DF file:  [Indigo]<Cedar>Top>BCD.df
Documentation:  contact implementor
Implementor:  Satterthwaite 

This is a collection of shared low-level interfaces defining the formats of bcd
files, symbol tables and the like.  Most Cedar clients should use interfaces from
the Runtime and RuntimeTypes packages instead.

This component was formerly available as a sub-component of Compiler.df.  It is
now separately available, but is otherwise unchanged from the previous release,
except for recompilation.

Binder
------
DF file:  [Indigo]<Cedar>Top>Binder.df
Documentation:  see Mesa 5.0 Reference Manual and Mesa User's Handbook
Implementor:  Satterthwaite 

Minor bug fixes and recompilation only.

BootClientFile
-------------
DF file:  [Indigo]<Cedar>Top>BootClientFile.df
Documentation:  contact implementor
Implementor:  Levin 

Unchanged.

BravoToTioga
------------------
DF file:  [Indigo]<Cedar>Top>BravoToTioga.df
Documentation:  Converts Bravo formatted files to Tioga format.
Implementor:  Morris
Caretaker: Paxton

Recompilation only.

BTrees
------
DF file:  [Indigo]<Cedar>Top>BTrees.df
Documentation:  contact implementor
Implementor:  Levin 

Recompilation only.

BugBane
--------
DF file:  [Indigo]<Cedar>Top>BugBane.df
Documentation:  BugBane.doc, BugBane.shorts
Implementor:  Atkinson 

Numerous changes, particularly in transferring user interface functions to the
UserExec.  See BugBane.doc for more information.

CedarControl
------------
DF file:  [Indigo]<Cedar>Top>CedarControl.df
Documentation:  none
Implementor:  Levin 

The public interface CedarVersion has changed very slightly (the boolean
"debugging" is no longer available).  The semi-public interface CedarInitOps has
changed more significantly; most of the changes result from the introduction of
UserCredentials as an official package.  "Login" and "BypassNextLoginPrompt"
have been removed.  "Sleep" now takes an optional cursor to display. 
"SetTimeSlice" can be used to set the pseudo-scheduler's time-slicing interval. 
"longDialogue" replaces CedarVersion.debugging.  Other changes are noted in the
comments in the interface.

CedarDB
---------
DF file:  [Indigo]<Cedar>Top>CedarDB.df
Documentation:  Contact implementor
Implementor:  Cattell 

This release fixes the last bug in the B-tree package.

Cedar Reals
-----------
DF file:  [Indigo]<Cedar>Top>CedarReals.df
Documentation:  MesaFloat60.press
Implementor:  Stewart.pa 

All interfaces are CEDAR DEFINITIONS.  There is a new procedure,
Real.CompareREAL.  A bug in RealFns.Log was fixed.

CedarSnapshot
--------------
DF file:  [Indigo]<Cedar>Top>CedarSnapshot.df
Documentation:  see comments in CedarSnapshot.mesa
Implementor:  Levin 

Recompilation and bug fixes only.

Chat
----
DF file:  [Indigo]<Cedar>Top>Chat.df
Documentation:  Introduction to Cedar
Implementor:  Stewart.pa 

The -l switch (login) is now the default.

CIFS
----
DF file:  [indigo]<Cedar>Top>CIFS.df
Documentation:  [Indigo]<Cedar>Documentation>CIFSManual.(tioga press)
  see comments in (CIFS CIFSFeedback FileLookup).mesa
Implementor:  Schroeder 

The main interface, "CIFS", has been made SAFE and the TYPE of "FileObject"
made opaque.  Performance of opening files has been improved.  A salvager has
been added (boot Cedar with the "l" switch).  The new single packet file server
enquiry protocol is made available through the "FileLookup" interface.

CIFS Commands
------------------
DF file:  [Indigo]<Cedar>Top>CIFSCommands.df
Documentation:  [Indigo]<Cedar>Documentation>CIFSManual.(tioga press)
Implementor:  Schroeder.pa 

The "delete" command has been renamed "cifsdelete" and the "rename" command
has been renamed "cifsrename", to avoid name clashes with the executive.

DF file:  [Indigo]<Cedar>Top>Clock.df
Documentation:  none
Implementor:  Atkinson 

No significant changes to the implementation.  Clock is now a separate package.

CoFork
-------
DF file:  [Indigo]<Cedar>Top>CoFork.df
Documentation:  CoFork.doc, CoFork.press
Implementor:  Sturgis 

No implementation code changes, i.e. CoForkImpl is unchanged.  CoForkDemo has
been edited so that it compiles.  CoForkDemo has not been tested in 3.4 (or in
many previous releases).

ColorPackage
-------------
DF file:  [Indigo]<Cedar>Top>ColorPackage.df
Documentation:  See interfaces
Implementor:  Maureen Stone 

<Description of changes not available at press time.>

Communication
---------------
DF file:  [Indigo]<Cedar>Top>Communication.df
Documentation:  Pilot users manual
Maintainer:  Andrew Birrell 

Recompilation only (plus a bug fix private to RPCRuntime)

CompatibilityPackage
--------------------
DF file:  [Indigo]<Cedar>Top>CompatibilityPackage.df
Documentation:  none
Implementor:  Levin 

All interfaces have been recompiled without functional changes (in particular,
they remain unsafe), except NameAndPasswordOps, which is withdrawn.  See
UserCredentials for a replacement.

Compiler
--------
DF file:  [Indigo]<Cedar>Top>Compiler.df
Documentation: CLRM.press (Cedar Language Reference Manual, Version 3.2)
Implementor:  Satterthwaite 

The language and compiler have been extended in minor ways to bring the
reference manual and compiler into closer agreement and to remove anomalies
discovered while writing the reference manual.  All changes for 3.4 are
compatible extensions requiring no modifications to existing programs.  However,
you should consider using the new forms as you write or revise code, since
many of the old forms are anomalies that will eventually disappear.

TYPE ATTRIBUTES

If T is a type, then as discussed in the reference manual, the notation T.x
extracts the value with name x from the cluster associated with T.  These values
include various attributes associated with the type; the currently supported
attributes are listed below.  T must have the syntactic form
        n ( . n | [ e ] )...
where n is a name and e is an arbitrary expression (see the reference grammar).

1. Enumeration Literals

	T.id		== T[id]

where T is an enumeration type (or subrange thereof) and id names one of its
literals.

	Example: Color.red

2. Discriminated Variant Types

	T.id		== T[id]	== id T

where T is a variant record type and id names one of its variants.

	Example: Node.unary 

3. BuiltIn Attributes

	T.SIZE		== SIZE[T]
	T.FIRST, T.LAST	== FIRST[T], LAST[T]
	T.NIL			== NIL[T]
	T.CODE		== CODE[T]

	Examples: Color.FIRST, Chars[n].SIZE

OBJECT NOTATION

This has been extended to work with most of the unary builtIn operators, as
follows:

	v.ABS		== ABS[v]
	v.BASE		== BASE[v]
	v.LENGTH		== LENGTH[v]
	v.LONG		== LONG[v]
	v.PRED, v.SUCC	== PRED[v], SUCC[v]

	Examples: Vec.LENGTH, Color.FIRST.SUCC

ATOM TO ENUMERATION COERCIONS

There is an automatic coercion from an atom literal to an enumeration type T,
where the value is that element of T denoted by the print name of the atom.

	Example: c: Color _ $red

Note: Although this coercion only works with atom literals in contexts in which
the enumeration literals would themselves be acceptable, you should consider
using it to avoid the various subtleties associated with, e.g., red: Color _ blue.

EXPORTS & SHARES

A module automatically shares all the interfaces that it exports; no corresponding
entry in a SHARES clause is necessary.

DESCRIPTOR EXTENSION

If a type T has a DESCRIPTOR operation, the types POINTER TO T, LONG
POINTER TO T, and REF T do also (e.g., DESCRIPTOR now works on a pointer to
an array or to a sequence-containing record).

UNSPECIFIED IN CHECKED REGIONS

There is a safe coercion from any one-word type to type UNSPECIFIED and from
UNSPECIFIED to any non-RC type of that size.  There are similar safe coercions
 -from any type LONG T to LONG UNSPECIFIED, if there is a coercion from T to
UNSPECIFIED,
 -from any REF type to LONG UNSPECIFIED,
 -from LONG UNSPECIFIED to LONG T, if there is a coercion from UNSPECIFIED
to T.

Since these coercions are safe, they may be used in CHECKED regions.  They
compose properly with other coercions (e.g., from result record to its single
component) but are applied only in assignment-like constructs (_, record
construction and extraction, etc.).  Thus in CHECKED regions:

  (1) "wild-card" matching of UNSPECIFIED does not recur (e.g., you still
      can't assign PROC[INTEGER] to PROC[UNSPECIFIED] without a
      LOOPHOLE)

  (2) (LONG) UNSPECIFIED does not come equipped with generic operations
      (+, =, etc.) other than assignment (e.g., u+i remains an error).

Example:

  i: INTEGER;
  u: UNSPECIFIED;
  ii: LONG INTEGER;
  uu: LONG UNSPECIFIED;
  rr: REF ANY;
  c, d: CARDINAL;

  i _ u; u _ i;
  ii _ uu;  uu _ ii;
  uu _ rr;       -- rr _ uu remains unsafe
  c _ Inline.BITAND[c, d];	-- accepted (by composition)
  [c] _ Inline.BITAND[c, d];	-- accepted, but non-intuitive

Note: These changes were motivated by the current definitions of operations in
the Inline interface and the pervasive use of that interface.  They will probably
be withdrawn when we fix Inline; you should continue to avoid UNSPECIFIED
in new code.

******************
The following extension is mentioned for completeness only.  It is not yet
supported by the RT Type system.  Cedar programmers should avoid it until
corresponding runtime support is announced.
******************

VAR IN INTERFACES

Variables in interfaces can optionally be declared using the form
    v: VAR T
instead of
    v: T
Note that this convention clearly distinguishes between
    p: PROC		-- an interface procedure
and
    p: VAR PROC	-- an interface variable

Interfaces written according to the old convention continue to work in 3.4.

CoPilot
-------
DF file:  [Indigo]<Cedar>Top>CoPilotMaker.df
Documentation:  none
Implementor:  Atkinson 

Unchanged.

D0Microcode
------------
DF file:  [Indigo]<Cedar>Top>D0Microcode.df
Documentation:  none
Implementor:  Fiala 

Unchanged.

DateAndTime
-------------
DF file:  [Indigo]<Cedar>Top>DateAndTime.df
Documentation:  see comments in DateAndTime.mesa
Implementor:  Levin 

This interface is now safe.  Small enhancements, noted in the comments in the
interface, have been made.  For those requiring an unsafe version (long strings
instead of Ropes), [Indigo]<Cedar>Top>DateAndTimeUnsafe.df is also available.

DFFiles
-------
DF file:  [Indigo]<Cedar>Top>DFFiles.DF
Documentation:  DFFilesRefMan.Press
Implementor:  Schmidt 

1) BringOver: new options
	/f	ignore all files on local disk ("force retrieve")
	/u	retrieve a file only if some version of that file is already on the
		disk (like FTP update mode).
	/b	retrieve only files that end in ".bcd", ".boot", ".signals", and ".press"
	/s	(inverse of /b) retrieve only files that do NOT end in ".bcd",
		".boot", ".signals", and ".press"
	/w	retrieve only "writeable" files, i.e. Directory or Exports entries, 
		not ReadOnly or Import entries
	/r	(inverse of /w) retrieve only "ReadOnly" files, i.e. Imported files
		and ReadOnly entries
   	(one or more of b,s,w,r are useful when converting to new releases when
		your local disk has the right source or object files, etc. and 
		you want some of the files listed in the DF file but not all.)

2) SModel: 
a) CameFrom-ReleaseAs flip:  lines like
	Directory XXX CameFrom YYY
    are automatically converted into
	Directory YYY ReleaseAs XXX
    Also, lines like
	Imports XXX Of date
  	CameFrom YYY
    are converted to
	Imports XXX Of date
    (note the date is not changed.)
    A new option /f can be given to Smodel:  /f prohibits the
    	CameFrom-ReleaseAs flip.

b) /p option:
    When given, all entries like
	Directory XXX ReleaseAs <Cedar>Pkg>
     are converted to
	Directory <PreCedar>Pkg> ReleaseAs <Cedar>Pkg>
     /v is also turned on if /p is given.
         If there were entries like Directory XXX ReleaseAs <Cedar>Pkg>
     where XXX was not a subdirectory of <PreCedar>, then the local copy
     of the DF file is not rewritten.
	
   The /p option is intended for one style of use:  when the implementor's
normal DF file points to files on project or personal directories instead of
<PreCedar>.  Programmers who keep their working copies of files on <PreCedar>
do not need to use the /p option.  
    Be careful about use of VerifyDF after an SModel /p has been run: 
VerifyDF should be given the DF file on <PreCedar>, instead of the local copy. 
VerifyDF will then try to retrieve the <PreCedar> version to the local disk, so
the local working copy must be saved and later restored after VerifyDF has been
run.

c) Confirmation:
	SModel now asks for confirmation before storing a file on a remote file
server.  You may reply "y" to store, "n" to skip, "q" to quit immediately, and "a"
to store this file and any subsequent ones without further confirmation.  The /a
option may be given to SModel to automatically store all files without asking for
confirmation.  (These answers and the /a switch are just like those in
BringOver.)

d) /v option: is up to 5 times faster than last release, since it uses the new
Taft-Schroeder file lookup protocol.

VerifyDF:
	When VerifyDF wants to retrieve a version of a DF file that differs from
the version on the local disk, VerifyDF asks "Ok to modify XXX of ... ".  Five
answers to this question are now accepted:
	"y"	yes: go ahead and retrieve the file, clobbering the local version
	"n"	no: do nothing and treat this DF file as though it did not exist
	"a"	all: like yes, but no more confirmation is asked
	"q"	quit: stop running VerifyDF altogether
	"l"	local: do not retrieve the remote DF file, but use the local 
		version of the DF file in its place.
A new "/a" option can be given to VerifyDF:  when given /a, VerifyDF
retrieves all DF files it needs without confirmation.  

VerifyDF uses the new file lookup protocol to look for DF files and is somewhat
faster.

DLionMicrocode
---------------
DF file:  [Indigo]<Cedar>Top>DLionMicrocode.df
Documentation:  See implementor
Implementor:  Sturgis 

This new component consists of two microcode files, SAx000Initial.db and
FixedMesa.db, which Dandelion users must install on their disk in order to run
Cedar.

DoradoMicrocode
------------------
DF file:  [Indigo]<Cedar>Top>DoradoMicrocode.df
Documentation:  [Indigo]<DoradoDocs>DoradoBooting.press
Implementor:  Taft 

This DF file simply captures the microcode which you are already running.  All
the bootable microcode (.eb) files are released to [Indigo]<Cedar>Top>.

FileTool
--------
DF file:  [Indigo]<Cedar>Top>FileTool.df
Documentation:  Introduction to Cedar
Implementor:  Stewart.pa 

Local delete of a file may raise "Insufficient permissions."  Sorry.
The command buttons take 2 seconds to repaint sometimes.
Bringover should interact better with the UserExec version.
Use Control-Del to stop DF operations, "Stop!" to halt others.

Forms
------
DF file:  [Indigo]<Cedar>Top>Forms.df
Documentation:  Internal
Implementor:  Horning 

This is the beginning of a collection of Tioga forms useful for the creation of
various kinds of documents within Cedar. SampleSheet.tioga contains examples of
all the principal Looks and Formats of Cedar.style. Form.memo approximates the
old Bravo memo.form.

Germ
-----
DF files:
   [Indigo]<Cedar>Top>GermDorado.df
   [Indigo]<Cedar>Top>GermD0.df
   [Indigo]<Cedar>Top>GermDLion.df
Documentation:  "Pilot User's Handbook"
Implementor:  Taft 

GermDLion is a new submission.  GermDorado and GermD0 are unchanged from
the previous release.

GrapevineUser
--------------
DF file:  [Indigo]<Cedar>Top>GrapevineUser.df
Documentation:  [Indigo]<Grapevine>Docs>Interface.press and the Cedar interfaces
Implementor:  Andrew Birrell 

Most procedures in the Cedar interfaces are now SAFE.  GVRetrieve.GetBlock,
GetChar, EndOf, and CharsAvail have been added to allow use of IO streams. 
Several facilities have been added to GVNames for use by Maintain.  Several
extra elements have been added to the enumerated type GVNames.NameType
(and NameInfoDefs.NameType), but clients don't need to handle them since they
cover cases that previously raised uncaught signals internally in the package.

Graphics
--------
DF file:  [Indigo]<Cedar>Top>Graphics.df
Documentation:  See comments in Graphics.mesa
Implementor:  Wyatt 

1) Most operations in Graphics and GraphicsOps are now SAFE, and most of the
implementation is in the checked subset.

2) Strokes with arbitrary widths, mitered corners, and various end caps are now
implemented. DrawPath has been renamed DrawStroke.

3) DrawText, TextBox, and TextWidth have moved from Graphics to GraphicsOps.
(These take REF READONLY TEXTs; Graphics has similar operations on ROPEs.)

4) Paths are handled differently:
	NewPath, a new operation, returns a Path object.
	MoveTo, LineTo, CurveTo, etc. operate on a Path, not on a Context.
	DrawArea, DrawStroke, and ClipArea take an explicit Path argument.
	Display contexts no longer maintain an implicit path.
See the following examples, notes, and caveats.

  OldTriangles: PROC[context: Graphics.Context] = { OPEN Graphics; -- Cedar 3.3
    MoveTo[context, 2, 1]; LineTo[context, 5, 1]; LineTo[context, 5, 5];
    DrawArea[context]; -- draw first triangle
    MoveTo[context, 2, 5]; LineTo[context, 3, 3]; LineTo[context, 1, 2];
    DrawArea[context]; -- draw second triangle
    };

  NewTriangles: PROC[context: Graphics.Context] = { OPEN Graphics; -- Cedar 3.4
    path: Path _ NewPath[3]; -- the 3 is an optional hint for expected path size
    MoveTo[path, 2, 1]; LineTo[path, 5, 1]; LineTo[path, 5, 5];
    DrawArea[context, path]; -- draw first triangle
    MoveTo[path, 2, 5]; LineTo[path, 3, 3]; LineTo[path, 1, 2];
    DrawArea[context, path]; -- draw second triangle
    };

a) Close has gone away. DrawArea and ClipArea consider all trajectories in a
path to be closed. DrawStroke has an optional 'closed' argument which determines
whether trajectories are open-ended (the default) or closed. (You can delete old
calls of Close.)

b) MoveTo has an optional 'flush' argument; if flush is TRUE (the default),
MoveTo first discards the old content of the Path before recording the new point.
(This behavior is likely to be what you want unless you're constructing paths
with multiple trajectories. You can probably delete old calls of FlushPath.)

c) Points are no longer transformed one at a time as they are entered into
a path; instead, the entire path is transformed at once when it is used as an
argument to DrawStroke, DrawArea, or ClipArea. (This won't affect you unless
you called Translate, Scale, Rotate, etc. in the midst of building a path.)

d) Since MoveTo, LineTo, and CurveTo no longer operate on a Context, they
cannot affect the current position. Use SetCP to adjust the current position.

IFSFile
------
DF file:  [Indigo]<Cedar>Top>IFSFile.df
Documentation:  contact implementor
Implementor:  Levin 

Recompilation only.

IncludeChecker
---------------
DF file:  [Indigo]<Cedar>Top>IncludeChecker.df
Documentation:  none
Implementor:  Rovner 

Recompilation only.

Inscript
-------
DF file:  [indigo]<precedar>top>Inscript.df
Documentation: 
  InscriptImplAppendix.memo
  inscriptimplementation.memo
  InscriptImplementation.press
Implementor:  Maureen Stone, Dan Swinehart 

There is a new procedure, InsertAction, which allows you to simulate input
actions.  For reasons we won't go into, InsertAction can be found in the new
(temporary) interface InterminalExtra.

The keyboard watching process has been changed to take significantly less time
on each wakeup if the keys/mouse haven't changed.  This should produce a
substantial performance improvement on Dolphins, and should have no noticable
effect on Dorados.

All interfaces have been recompiled since 3.3.

IO, FileIO, ViewerIO, UserProfile
--------------------------------
DF file:  [Indigo]<Cedar>Top>IO.df, [Indigo]<Cedar>Top>TTYIO.df
Documentation:  see comments in interfaces
Implementor:  Warren Teitelman, Russ Atkinson, Mark Brown 

Changes To UserProfile:

UserProfile.String has gone away. For most applications, i.e. where you want to
get a single rope out of the profile, UserProfile.Token should be used instead. For
applications where the entire line is desired, use UserProfile.Line or
UserProfile.ListOfTokens.  (Unfortunately, the implementation of these three was
not completed, and both Token and Line do exactly what UserProfile.String used
to do, which is to return everything on the line. ListOfTokens is not yet
implemented.)
 
UserProfile.ProfileChangedProc has been changed  be of type  PROC [reason:
ProfileChange];
where ProfileChange: TYPE = {firstTime, rollBack, edit}; This permits
profileChangedProcs to distinguish the indicated three cases.

Comments can now appear in profiles anywhere  without causing any problems.
They are simply ignored. Trailing spaces are still a problem but will be fixed for
3.5.

Changes To IO and ViewerIO:

CreateTTYStreams no longer exists. Use IO.CreateViewerStreams, which calls
ViewerIO.CreateViewerStreams.  The 'in' value returned by CreateViewerStreams
is now an edited stream. If you used to do CreateEditedStream on top of the 'in'
value returned from CreateTTYStreams or CreateViewerStreams, you don't have to
(and shouldn't) anymore. If you really want to get at the underlying input
stream, you should call ViewerIO.CreateViewerStreams directly and specify
editedStream: FALSE. 

CreateFileStream no longer exists. Use FileIO.Open instead (see comments below
under changes to FileIO). Similarly the errors {FileNotFound, FileAlreadyExists,
IllegalFileName, WrongTransactionType, and CantUpdateTiogaFile} are no longer
defined in IO.

AttachTVPrintProc now takes an extra argument, canHandleRemote: BOOL which
defaults to FALSE. If TRUE, means that the tvprintproc should also be called for
remote TVs. (This is in preparation for 4.0).

Closing a stream will call Flush in the case that the stream does not explicitly
implement Close. (Implementors of streams that have a close operation should do
the flush inside of the close where appropriate).

PutF to a viewer stream recognizes %l as a change looks command. The
argument, a rope, is interpreted as a sequence of characters which are looks, e.g.
stream.PutF["This %l is %l a test", rope["i"], rope["b"]] will print "This " in the
current font, then do a look B and print "is " and then do a look i and print "a
test".

All tv and type printing in Cedar (i.e. both UserExec and BugBane) now go
through a single mechanism which has been considerably exercised and
debugged with respect to that provided in 3.3. All known bugs regarding
printing of tvs or ref anys have been fixed.

 
New procedures:

ViewerIO.GetViewerStream - returns the viewer if the stream is a viewer stream,
otherwise NIL.

IO.PutThisSignal - takes a signalTV and argsTV, which if defaulted to NIL,
means print the current signal. (This corresponds to what used to be
PrivateIO.PrintThisSignal).

IO.PutTV and IO.PutType - where you need to specify the depth and width for
printing. Note that stream.Put[tv[value] or type[value]] default tthe depth and
width arguments to reasonable values.

IO.SetUserAbort and IO.ResetUserAbort now defined and implemented for viewer
streams.



Changes to FileIO:

IO.CreateFileStream no longer exists; use FileIO.Open instead.  If you default the
Open parameters that CreateFileStream did not have, you'll get the same effect as
before, so in effect this is just a procedure name change.  Unfortunately, you
will have to IMPORT FileIO and Transaction (next time FileIO is recompiled, the
need to import Transaction will go away).

The default accessOption value to all procedures is now "read" (formerly
"write".)  I expect that most streams are opened for "read", and that the next most
popular accessOption is "overwrite", with "write" and "append" a distant third
and fourth.

All of the file stream creation procs now raise the following signal instead of
IO.Error:
  FileIO.OpenFailed: SIGNAL [why: OpenFailure, fileName: ROPE]
    RETURNS [retryFileName: ROPE]
  OpenFailure: TYPE = { fileNotFound, illegalFileName, fileAlreadyExists,
    cantUpdateTiogaFile, wrongTransactionType, unknownFileCapability,
notImplementedYet }

Resuming this signal is the same as calling FileIO.Open with whatever parms
were passed to the original stream creation call (except for the file name, of
course), and with all other Open parms assuming their default values.  So when
BugBane provides the ability to resume a signal with a value, you'll be able to
use it to continue from this common sort of error.  (I also invite someone to write
a procedure analogous to FileIO.Open that does interactive spelling correction
using the Spell package and FileIO).

Some procedure names have changed: HandleFromCapability ->
StreamFromCapability, CapabilityFromHandle -> CapabilityFromStream,
HandleFromLFH -> StreamFromLFH.

You may now read (NOT update or create) remote IFS files using a stream,
through CIFS.  If the fileName parm to FileIO.Open begins with '/, or begins
with '[ but the next seven characters are not "Juniper", then the name will be
passed to CIFS for opening.  Of the errors that may result, the file stream
implementation knows how to catch CIFS.Error[code: illegalFileName or
noSuchFile or noSuchHost], and reflect these as FileIO.OpenFailed.  All other
CIFS errors are passed through (this will improve someday).

FileIO.StreamFromOpenFile is a new procedure that takes a CIFS.OpenFile and
returns a (readonly) stream, in case you want to call CIFS.Open yourself (e.g. to
get access to the CIFS working directory mechanism).  The OpenFile under the
resulting stream is Closed when the stream is, so it should not be shared around
too freely.

FileIO.Open takes a new parameter, createLength: INT _ 5 *
Environment.bytesPerPage.  If Open has to create a file, it will allocate enough
pages to the file at create time to accomodate an eventual length of createLength
bytes.  It does NOT set the file length to createLength; the length of a newly
created file is 0 bytes, as before.

All file stream creation procs take a new parameter,
  streamBufferParms: RECORD [bufferSize: INT [2 .. 127], bufferSwapUnitSize:
INT [1 .. 32]]
This gives the caller control over the VM allocated by file streams for buffering
(request of Ken Pier.)  This parameter defaults to a reasonable value.  See
FileIO.mesa for details.

An implementation restriction on unsafe block operations has been removed:
values of block.startIndex and block.stopIndexPlusOne larger than 2^16 now work
correctly.  Negative values are still illegal.

The FileIO interface has been formatted using Tioga node structure and the
comment property (no more "--"s).  The interface should provide complete
documentation for file streams.  Bug reports and suggestions for improving the
file stream documentation are hereby invited.  One known deviation of the
documentation from reality: Open catches CIFS.Error[code: noSuchHost, ...], and
turns it into OpenFailed[openFailure: fileNotFound].


Changes to PrivateIO:   no longer exists.

Lister
-----
DF file:  [Indigo]<Cedar>Top>Lister.df
Documentation:  Lister.txt
Implementor:  Satterthwaite 

Cosmetic changes and recompilation only.

ListsAndAtoms
--------------
DF file:  [Indigo]<Cedar>Top>ListsAndAtoms.Df
Documentation:  see comments in Atom.mesa, List.mesa, RefTab.mesa or
  contact implementor
Implementor:  Teitelman 

List.CompareProc now has named arguments and returns an
Environment.comparison.

A Replace operation has been added to RefTab.

Loader
------
DF file:  [Indigo]<Cedar>Top>Loader.df
Documentation:  none
Implementor:  Rovner 

Recompilation only.

Lupine
-------
DF file:  [Indigo]<Cedar>Top>Lupine.df
Documentation:  LupineUsersGuide.press
Implementor:  Nelson (presently supported by Birrell) 

Recompilation only.

Maintain
---------
DF file:  [Indigo]<Cedar>Top>Maintain.df
Documentation:  [Indigo]<Grapevine>Docs>Maintain.press
Implementor:  Birrell 

Recompilation only.

MakeBoot
---------
DF file:  [Indigo]<Cedar>Top>MakeBoot.df
Documentation:  MakeBoot.press
Implementor:  Levin 

The maximum boot file size is now 64K pages, not 4K pages.
A new facility for altering fsi chaining in the allocation vector has been added.
The loadmap has been cleaned up and extended.
The documentation has been augmented somewhat.

MCross
-------
DF file:  [Indigo]<Cedar>Top>MCross.df
Documentation:  MCross.doc
Implementor:  Rovner 

Recompilation only.

MesaScanner
------------
DF file:  [Indigo]<Cedar>Top>MesaScanner.df
Documentation:  see MesaScanner.mesa
Implementor:  Atkinson 

No major changes.  Hex literals should now be acceptable, and a minor bug in
character constant scanning has been fixed.

Modeller
------------
DF file:  [Indigo]<Cedar>Top>Modeller.DF
Documentation:  ModelRefMan.Press and see Ed Satterthwaite or implementor
Implementor:  Schmidt 

If Begin or Compile are pushed without pushing StartModelling, the modeller is
given an automatic StartModelling.

OnlineMergeSort
----------------
DF file:  [Indigo]<Cedar>Top>OnlineMergeSort.df
Documentation:  ListSort.mesa, ListSort.press
Implementor:  MBrown 

Unchanged except for formatting.

Othello
-------
DF file:  [Indigo]<Cedar>Othello>Othello.df
Documentation:  "How to Use Cedar", "Pilot User's Handbook"
Implementor:  Taft 

1. Othello now conforms to the Cedar conventions for user credentials.  That is,
if you enter the Pilot/Cedar world by booting Othello, it will require you to log
in; and if the disk is protected, you may log in only as the disk's owner. 
Subsequently, your credentials will be remembered throughout your session,
even when switching among Cedar, Othello, Booter, and/or CoPilot.

2. If you boot Othello with the "n" switch, Othello will permit you to log in with
any valid credentials; but the commands available will be very restricted.  In
particular, the only commands that access the disk are Format and Create
Physical Volume.

3. The new command Install Credentials permits changing the credentials
installed on the disk or switching between the protected and unprotected states.

4. Command file processing has been somewhat cleaned up.  In particular:

  a) Any error causes a command file to be aborted.
  
  b) All requests for confirmation ("Are you sure?", "Are you really sure?", etc.)
are suppressed during command files.  Note, however, that Yes/No type questions
asking for information (e.g., "Set physical volume boot file from this logical
volume?") are still asked.

Nearly all existing Othello command files will need to be changed.

Packager
--------
DF file:  [Indigo]<Cedar>Top>Packager.df
Documentation:  contact implementor
Implementor:  Levin 

Recompilation and a tiny bug fix.

PerfStats
--------
DF file:  [Indigo]<Cedar>Top>PerfStats.df
Documentation:  PerfStats.mesa, PerfStats.press
Implementor:  MBrown 

Recompiled.

PGS
----
DF file:  [Indigo]<Cedar>PGS>PGS.df
Documentation:  contact implementor
Implementor:  Satterthwaite 

Recompilation only.

PilotKernel
----------
DF files:
  [Indigo]<Cedar>Top>PilotInterfaces.df
  [Indigo]<Cedar>Pilot>PilotKernel.df and UtilityPilotKernel.df
Documentation:  Pilot Programmer's Manual
Implementor:  Levin 

Selected procedures in popular Pilot interfaces have been made "safe", in the
Cedar sense.  A few convenience features have also been added.  In particular,
the following interfaces have changed (everything has been recompiled):

Environment
The type Comparison has been added.  See Inline for operations.

File
Most procedures are now SAFE.

Inline
Most procedures are now SAFE (COPY and LongCOPY are notable exceptions). 
CompareInt and CompareCard are (safe) procedures that perform three-way
comparisons and return Environment.Comparison.

MiscAlpha
The alpha byte values previously in CedarReals.Real are now included in this
interface.

Mopcodes
A new, upward compatible version that contains single-byte Cedar opcodes is
now available.

Process
A few operations have been made SAFE, e.g. Yield, Pause.  Users should be
aware that, at present, most operations involving variables of type PROCESS are
inherently unsafe; in particular, JOIN and Process.Detach are unsafe.  We may
someday have a safe construct analogous to Process.Detach[FORK Mumble[...]],
but for now, this is an unsafe construction.

Runtime
A few procedures here are now SAFE, e.g. GetBcdTime, GetBuildTime. 
BoundsFault and PointerFault are now ERRORs; they were formerly SIGNALs. 
ZeroDivisor and DivideCheck are now SAFE SIGNALs.  ControlFault and
UnboundProcedure remain unsafe SIGNALs.

Space
A number of the procedures in this interface are now SAFE.  However, the
major Space operations -- creation, deletion, mapping -- remain unsafe.

SpecialSpace
CreateAligned now takes an additional, optional parameter to permit finer control
of aligned allocation.

System
Nearly everything in this interface is now SAFE.

Transaction
The entire interface is now SAFE.

Volume
Nearly everything in this interface is now SAFE.  Note, however, that
GetLabelString isn't.

Pine
----
DF file:  [Indigo]<Cedar>Top>Pine.df
Documentation:  contact implementor
Implementor:  MBrown 

Recompiled.

PlotPackage
-----------
DF file:  [Indigo]<Cedar>Top>PlotPackage.df
Documentation:  see the interfaces
Implementor:  Rovner 

Recompilation only.

Poplar
------
DF file:  [Indigo]<Cedar>Top>Poplar.DF
Documentation:  Poplar.Press, EASPL.Press
Implementor:  Schmidt 

This is a new release component.  Note that Poplar is one of the SAFE-est Cedar
application programs.

PressScreen
-----------
DF file:  [Indigo]<Cedar>Top>PressScreen.df
Documentation:  See comments in PressScreen.df
Implementor:  Cattell, Teitelman 

This is probably the last release of PressScreen as such; it will be incorporated
into TSetter in the near future.  New feature (thanks to Warren): sends output to
ScreenN.press for N=1, 2, ... on successive uses of the PressScreen button.

Print, PressPackage
------------------
DF file:  [Indigo]<Cedar>Top>Print.df
Documentation:    Print.df
Implementor:  Plass 

No user-visible changes.

PriorityQueue
-------------
DF file:  [Indigo]<Cedar>Top>PriorityQueue.df
Documentation:  see PriorityQueue.mesa
Implementor:  Atkinson 

Recompilation only.

Pup
----
DF file:  [Indigo]<Cedar>Top>Pup.df
Documentation:  [Ivy]<Mesa>Doc>Pup.press
Maintainer:  Andrew Birrell 

Recompilation only

Pupwatch
---------
DF file:  [Indigo]<Cedar>Top>Pupwatch.df
Documentation:  [Indigo]<Grapevine>Pupwatch>Pupwatch.press
Implementor:  Birrell 

Recompilation only.

Random
-------
DF file:  [Indigo]<Cedar>Top>Random.df
Documentation:  Random.mesa, Random.press
Implementor:  MBrown 

Recompiled.  All implementations now initialize themselves (upon STARTing) by
calling Init with default parameters, so a simple application does not need to call
Init at all.

RedBlackTree
-------------
DF file:  [Indigo]<Cedar>Top>RedBlackTree.df
Documentation:  OrderedSymbolTable.mesa, OrderedSymbolTable.press
Implementor:  MBrown 

Now uses Environment.Comparison.

RedBlackTreeRef
----------------
DF file:  [Indigo]<Cedar>Top>RedBlackTreeRef.df
Documentation:  OrderedSymbolTableRef.mesa, OrderedSymbolTableRef.press
Implementor:  MBrown 

Now uses Environment.Comparison.

Reminder
---------
DF file:  [Indigo]<Cedar>Top>Reminder.df
Documentation:  See comment in Reminder.mesa
Implementor:  Rovner 

This is a simple program for managing a personal reminder calendar, in lieu of
the more complete facilities of Hickory, which is not yet released..

Rigging
-------
DF file:  [Indigo]<Cedar>Top>Rigging.df
Documentation:  Rigging
Implementor:  Atkinson 

No major change.  Rope.Compare returns Environment.Comparison.  New
operations are Rope.IsEmpty and RopeInline.IsEmpty.

RPC Runtime
-------------
DF file:  [Indigo]<Cedar>Top>RPCRuntime.df
Documentation:  LupineUsersGuide.press
Implementor:  Birrell 

Recompilation only.

Runtime and RuntimeTypes
---------------------------
DF file:  [Indigo]<Cedar>Top>Runtime.df
Documentation:  RTTypes.tioga and .press, Runtime.tioga and .press
Implementor:  Rovner 

The most visible changes are in the RTTypes stuff, and in RTTBridge:

RTTypes.Class now includes atom and rope, which have the following operations
in RTTypes:

   atom: TVToName, PropertyList
   rope: TVToName, Length, Fetch

and the following operations in RTTBridge:

   atom: TVForATOM, TVToATOM
   rope: TVForROPE

RTTypes.Class also includes basePointer and relativePointer, which have the
following operations in RTTypes:

   basePointer: IsOrdered, Range
   relativePointer: Referent, IsOrdered, Range, ReferentStatus

Other RTTypes changes:

Errors are treated differently; there is now one defined error ("RTTypes.Error")
which takes an enumerated "reason". See the interface.

Assign now does coercions.

New takes an optional tag argument for sequences and unions.

Some operations have been changed to deal with CARDINAL or INT rather than
Index, which is defined in RTBasic to be a NAT. Groan.

For union types, IndexToName now allows an index of 0, meaning to get the
name of the tag field of the union.

A new operation, TVToType, converts a TV for a Type into the Type.

Overlaid unions and computed unions and sequences are supported via
IsOverlaid and IsComputed, and via Loophole (see below).

A new operation, IsPacked, is applicable to array and sequence types.

Length was changed to return an INT rather than a TV for an INT.

Other RTTBridge changes:

New operations:

   BytePC gets the PrincOps.BytePC in a localFrame tv.
   IsStarted and IsCopied apply to globalFrame tv's.

   ENGINE ROOM GUYS:
      Loophole: PROC[tv: TypedVariable, type: Type, tag: TypedVariable _ NIL]
            RETURNS[TypedVariable];  -- tag used for overlaid and computed 

      OctalRead: PROC[tv: TypedVariable, offset: INT] RETURNS[CARDINAL];


SampleTool
-----------
DF file:  [Indigo]<Cedar>Documentation>SampleTool.df
Documentation:  self-documenting; see comments in SampleTool.mesa
Implementor:  McGregor 

The SampleTool is an example program for using Viewers, the Cedar window
package.

Sequin
------
DF file:  [Indigo]<Cedar>Top>Sequin.df
Documentation:  contact implementor
Implementor:  Levin 

Recompilation only.

Set
---
DF file:  [Indigo]<Cedar>Top>Set.df
Documentation:  Set.doc
Implementor:  Rovner 

Recompilation only.

SirPress
-------
DF file:  [Indigo]<Cedar>Top>SirPress.df
Documentation:    see comments in SirPress.mesa, PressPrinter.mesa
Implementor:  Plass 

No user-visible changes.

Spy
---
DF file:  [Indigo]<Cedar>Top>Spy.df
Documentation:  Spy.doc
Implementor:  Maxwell 

SpaceWatch is now a part of Spy.df (see implementor).

Squirrel
-------
DF file:  [Indigo]<Cedar>Top>Squirrel.df
Documentation:  See implementor(s)
Implementor:  Cattell, Haugeland, Maxwell 

Squirrel provides some database management functions in conjunction with
CedarDB.  This release is necessary only to enable the release of Walnut, which
depends upon that functionality; Squirrel is not currently being released for end
users other than database application builders.

STPServer
---------
DF file:  [Indigo]<Cedar>Top>STPServer.DF
Documentation:  see package catalog
Implementor:  Schmidt 

Recompilation only

TerminalMultiplex
------------------
DF file:  [Indigo]<Cedar>Top>TerminalMultiplex.df
Documentation:  see comments in TerminalMultiplex.mesa
Implementor:  Levin 

A mechanism for temporarily disabling control-swat and control-shift-swat has
been added.  Two new procedures have been included in this interface, and
CurrentTerminal has been altered to return the value of the "debugger lock
count".  The implementation has been adapted to work on Dandelions.

This facility, like the entire interface, is not for the average Cedar user. 
Furthermore, the interface remains unsafe.

TJaMGraphics
-------------
DF file:  [Indigo]<Cedar>Top>TJaMGraphics.df
Documentation:  See implementor
Implementor:  Maureen Stone 

<Description of changes not available at press time.>

TSetter
------
DF file:  [Indigo]<Cedar>Top>TSetter.df
Documentation:  See TiogaDoc.Tioga, TSViewer.mesa
Implementor:  Plass 

 The performance is improved, though still nothing to write home about.
 Printing remote press files now works.
 Either style of remote file name now works.
 Press files whose names end in "$" will be deleted after they are successfully
sent to a printer; there is a new button below the copies button that tells the
typesetter to make such temporary press file names. (Printing remote press whose
names end in "$" may get you onto shaky ground with CIFS.)
 The press files are now named by concatenating ".press" onto the tioga
document name; this is to avoid name conflicts between foo.mesa and foo.df, etc.

TTYIO 
------
DF file:  [Indigo]<Cedar>Top>TTYIO.Df
Documentation:  contact implementor
Implementor:  Warren Teitelman 

See description of IO.

UECP
-----
DF File: [Indigo]<Cedar>Top>UECP.df
Documentation:  see interface
Implementor: Stewart

Recompilation only.

Unique
-------
DF file:  [Indigo]<Cedar>Top>Unique.DF
Documentation:  Unique.Doc
Implementor:  Schmidt 

Internals completely rewritten to use Cedar ropes, lists, etc.  No user-visible
changes.

UserCredentials
--------------
DF file:  [Indigo]<Cedar>Top>UserCredentials.df
Documentation:  see comments in UserCredentials.mesa
Implementor:  Levin 

This is a new package that provides centralized management of the credentials
of the user at the terminal.  It replaces and extends the old NameAndPasswordOps
interface in CompatibilityPackage, which is no longer available.  Note that
UserCredentials is NOT part of CompatibilityPackage.df.  For those requiring an
unsafe version, [Indigo]<Cedar>Top>UserCredentialsUnsafe.df is also available.

UserExec
--------
DF file:  [Indigo]<Cedar>Top>UserExec.df
Documentation:  this message plus contact implementor
Implementor:  Warren Teitelman 

Major changes: Work Areas, Action Areas.

The user interacts with Cedar in special viewers called Work Areas. Each work
area has a name, consisting of a single letter (after 26, goes to two letters, etc.).
The name is part of the caption of the viewer. Each work area is either an
executive, or an interpreter. This also is part of the caption. You can convert a
work area from an interpreter to an executive or vice versa with the
ChangeAreaMode command. You can create new work areas via the New Menu
button. Clicking red creates a new work area of the same "flavor",  click blue to
get the opposite flavor, e.g. to create a new interpreter area from an executive
area, click new with the blue button. In interpreter areas, you are always
prompted with &n _. (You can erase the "_" to execute registered commands by
using ^A or ^W. This does not affect the next event, i.e. you will still be
prompted with &n _.) In executive areas, the prompt is simply &n (but you can
type _ if you want to interpret and expression in an executive area.)

Each work area has its own symbol table in which the value of its & variables,
if any, are kept. & variables from other work areas can be referenced by
explicitly including the work area name following &, e.g. &A24. Each work area
also has its own global default context. Thus if you type FooImpl to an
interpreter area, and go to some other interpreter area and type FieImpl, when
you return to the first area, its default context is still FooImpl.

Each work area has a menu including a Stop Compile Eval Redo Set and Clear
button. These are described later. Yes and No buttons will pop up when a
confirmation is (about to be) requested, and disappear afterwards. You can click
ahead yes or no. Clicking ahead no has the effect of stopping the attempted
correction (which is not as severe as clicking stop, which aborts the event as
well as the correction.)

Whenever an operation in a work area causes an action to occur, i.e. a break
point is taken or an uncaught signal is raised, the work area is suspended and
control transfers to a different work area called an Action Area. Action Areas are
basically Interpreter Areas except that they have as their default context the
context of the action. Action Areas have a second menu line containing the
buttons Proceed Abort Source WalkStack ThisFrame and ListBreaks (the latter
really belongs on the first line, but would not fit.) These are explained below.
When the action is proceeded or aborted, the action area becomes dormant, its
second menu line disappears, and control transfers back to the suspended work
area. You cannot type into a dormant action area, though you can reference its &
variables via the mechanism described above. The action area however stays
around (unless the user explicitly destroys it) so that it can be reused if another
action arises out of the same parent area.  Thus if you are proceeding from
breakpoint to breakpoint while debugging a particular operation, all of the
breakpoints will typically be taken in the same action area.

If the action arises out of "thin air", as opposed to arising from the result of some
operation initiated in a work area, the procedure followed is similar: a new action
area is spawned unless there is a dormant action area available, and control
transfers to this area.

The WalkStack menu button allows you to change the default context for
interpretering expressions in the action area. Clicking red walks one frame up the
stack, i.e. earlier in the call stack, clicking blue walks down, and clicking yellow
resets the context to what it was when the action occurred. (Note that these
buttons correspond to the Restart and Next/Prev buttons in BBV.)

The ThisFrame button displays the current frame. Clicking red displays just the
frame name, clicking yellow the name plus args, and blue, name, args, and vars.

Source displays the source location for the current frame. It is exactly the same as
the Source button in BBV.

The Clear break menu button on the first line will clear the break point
corresponding to the current action if the selection is in the action area,
otherwise will attempt to find a break point "close" to the selection and clear it.

Proceed and abort do the obvious. They differ from BBV in that they are
synchronized with typein, i.e. you can bug ahead proceed and abort. 

Aborting an action area that is suspended, i.e. an operation initiated in this
action area itself caused an action, is supposed to abort any children action areas.
However, some problems have been observed with this. It is probably best to
abort only active action areas and work your way back up the chain by hand
until these are fixed.

Destroying an action area automatically aborts the action. 

It is the intent of this arrangement that you should not have to use BBV (and
that it may go away in the next release). The only facilities currently available
through BBV that are not available through Action Areas are (a) break at entry
or exit, (b) one shot breaks, (c) turning breaks on and off, (d) displaying the
entire stack via a single operation. Note that it is no longer necessary to list
actions, or do a next action, since each active action has its own action area
associated with it. If you should have to use BBV, do NOT use the BBV proceed
or abort button as this can cause problems.


Miscellaneous changes:

The user profile entry CommandsFrom is now implemented. If you have such an
entry, the commands are executed as event number 1, and then the userexec is
scrolled so that the first event number you see will be &2.

All of the commands registered in RegisteredCommands.catalogue are now known
to the user exec. Those commands that are explicitly defined in the user's profile
will take precedence over those in RegisteredCommands.catalogue (i.e. can be
used to redefine those commands). Also, when the user types ?, only those
commands that are built in or registered in his profile will be displayed.
However, command? will display information about command if it is defined in
either the users profile or RegisteredCommands.catalogue. (Note that *? will show
you everything.) The purpose of this change is so that the implementor of a
package that depends on a particular command being registered, e.g. Lupine, does
not have to worry about whether or not that command is used by (and hence
registered) by a particular user.

New userprofile entry ShowStatistics. If TRUE, user executive prints time, words
allocated and page faults after each event.

When compiling several files, a summary consisting of those files with warnings
and those with errors is printed at the end of the computation. After editing
these files, you can recompile them by typing compile and then  selecting the
summary and stuffing it, or by simply selecting the summary and clicking the
compile menu button, which now accepts a list of files.

Invoking the compiler, either via command or button, on a collection of files will
cause any files that have been edited but not yet saved to be automatically
saved before the compilation starts.

There is now an eval menu button which evaluates a selection. It works whether
or not the corresponding work area is an interpreter area.

Redo and use when terminated with control-X cause the corresponding command
to be computed and displayed, but not executed. The user can then backspace to
edit the command, or type additional characters before typing CR to initiate the
command.

There is now a redo button in the menu. Select anywhere in an event and click
redo to redo the corresponding event. Clicking with blue button is the same as
redo^X, i.e. the corresponding command is computed but not executed.

Spelling correction is now enabled for loading No Name viewers. The message is
printed in the message window, and Yes No buttons are added to the viewer's
menu for confirmation. Clicking ahead No will stop the correction.

There are Set and Clear menu buttons for setting and clearing break points. Blue
Clicking Clear has the effect of clearing all break points. Clicking red will clear
the breakpoint closest to the selection when the selection is in a tioga document. 

VersionMap
-----------
DF file:  [Indigo]<Cedar>Top>VersionMap.df
Documentation:  see VersionMap.mesa
Implementor:  Atkinson 

No changes.

Viewers and Tioga
------------------
DF file:  [Indigo]<Cedar>Top>ViewersAndTioga.df
Documentation:  TiogaDoc.tioga
Implementor:  TiogaImplementors^.pa 


User-visible Tioga changes (See TiogaDoc.tioga for more information):

"Open"/"OpenImpl" and "Load"/"LoadImpl" have been replaced by
"Get"/"GetImpl".  "New"/"Empty" have been replaced by "Clear".  Cedar.style is
the default style (instead of Default.style).  Click the middle mouse button on
"Find"/"Word"/"Def"/"Search" to search first forwards, then backwards.  The
"YSelectFudge" user profile option (default=0) allows mouse pointing below text
in order to select.  After a Rollback, files loaded in Tioga viewers are
automatically reset.  Line clipping is no longer implemented.  ^M with a point
selection applies Cedar formatting to the entire node (especially useful if you use
node formatting for your source files).  ^K is now "make control character".  ^O
is now "make octal character".  "DoForEachFile" option in the EditTool performs
operations on each of a list of files.  Selections can now be extended into a split
viewer.  There are new user profile options for default file extensions. 

We encourage you to convert your source files to node structure.  To do this,
call TiogaMesa with a list of files (TiogaMesa is an exec command exported when
you run TiogaExecCommands).


User-visible Viewers changes (See Cedar introduction for more information):

Commands that apply to all viewers are now hidden in the viewer caption; move
the mouse over the caption to display the menu.  Clicking the middle mouse
button in a viewer caption is equivalent to "Grow", and clicking the right mouse
button is equivalent to "Close".  "Adjust" is a new menu command that sets a
height 'hint' for the window manager.  Closing a viewer destroys the user-set
hint.  If you move the cursor across a column boundary when doing an
"Adjust", then you will be able to adjust the column width and height
(replacing the old tab at the bottom of the screen).  The "Top" command moves a
viewer to the top of its column.  Both menus items as well as buttons can now be
"guarded" which means that they must be clicked once to remove the strikeout
bar and then again to actually invoke the command.  After at least twenty
minute without keyboard or mouse activity, Cedar will automatically go into the
"idle" state.  You can change the time period for auto-idle by setting the user
profile entry "AutoIdleTimeout".  Setting AutoIdleTimeout to zero will disable the
feature.


Client-visible Viewers changes:

Buttons	--	ButtonProcs are now FORKed by default.  The type of
ButtonProc (equal to Menu.MenuProc) has been changed to permit the client to
examine which mouse button invoked the button (red, yellow or blue) as well as
the state of the control and shift keys.  The parent viewer is now a REF ANY in
the ButtonProc, which means that clients must NARROW to get a
ViewerClasses.Viewer (sorry about that).  Buttons will appear with black letters
on grey background while the client ButtonProc is running.  Button
documentation is now a REF ANY which may either be a ROPE or a REF
ButtonProc.  The documentation will be displayed when a guarded button is
unguarded.

Menus	-- The Menus interface has been extensively re-written, allowing
guarded menu entries, and generally more flexible handling of the menu
contents.  The parent viewer is now a REF ANY in the MenuProc, which means
that clients must NARROW to get a ViewerClasses.Viewer (sorry about that). 
MenuProcs are now FORKed by default.  MenuProc has been changed to permit
the client to examine which mouse button invoked the menu entry (red, yellow
or blue) as well as the state of the control and shift keys.  Menu entries will
appear with black letters on grey background while the client MenuProc is
running.  Menu documentation is now a REF ANY which may either be a ROPE
or a REF MenuProc.  The documentation will be displayed when a guarded
menu entry is unguarded.  Clients who perform operations with dynamic and
multi-line menus should see me about changes in 3.4 and those planned for the
next release.  Note that the ViewerClasses.ViewerClass now has a slot for the
default menu.

MessageWindow	-- With the advent of guarded buttons and menu entries, I
would like to see clients make less use of MessageWindow.Confirm.  It is
inherently buggy and will be de-implemented in the near future.

TypeScript	-- TypeScript.BackSpace now takes a count for number of
characters to backspace (more efficient).  TypeScript.AddLooks and
TypeScript.ClearLooks are now available for clients wishing to display different
text appearances when writing messages to a typescript.

ViewerEvents	-- This is a new interface that lets a client monitor
operations on viewers.  Events that may be observed include when a viewer is
saved, initially edited, destroyed, opened, closed, moved, selected, and
deselected.  Since clients may no longer replace the Destroy menu command, this
is the preferred way to clean up client state when a viewer is destroyed.  Filters
will be forthcoming in Cedar 3.5, but for now, clients must distinguish the
viewers of interest from other viewers.

ViewerClasses	-- The ViewerRec menu field is now normally NIL (since
the viewer operations menu is provided by the ViewerManager) but will be
copied from the ViewerClass.menu during viewer creation.  There is now a
saveInProgress bit that indicates that the saveProc of a viewer has been called
but has not yet completed.  There are two new fields in the ViewerClass that, in
an upcoming release, will provide more information to the client about invalid
areas to paint.  They are unused for Cedar 3.4.

ViewerOps	--  OpenViewer has been renamed to OpenIcon and now has extra
parameters for whether or not to close other viewers in the column and whether
the new viewer should be added to the top or bottom of the column.  TopViewer
and BottomViewer allow viewers to be moved to the top or bottom of a column. 
MoveAboveViewer and MoveBelowViewer allow viewers to be positioned with
respect to other viewers in the column.  ResetPaintCache (private) has been
changed; see me if you use it.

ViewersSnapshot	-- CheckPoint now returns the outcome.

VirtualDesktops	-- There are now nine virtual desktops instead of sixteen.

WindowManager	-- With the advent of grey background for currently
executing buttons and menu entries, I would like to see clients make less use of
WindowManager.WaitCursor.  It should only be used for those operations which
really must block the input state and prevent the user from performing other
operations in the meanwhile.  It will probably become a PRIVATE interface in
the next release.

VTables
--------
DF file:  [Indigo]<Cedar>Top>VTables.df
Documentation:  see VTables.mesa
Implementor:  Atkinson 

Minor changes only.  GetEntryOffset & SetEntryOffset operations have been
added.

Walnut
-------
DF file:  [Indigo]<Cedar>Top>Walnut.df
Documentation:  [Indigo]<Cedar>Documentation>HowToUseWalnut.press
Implementor:  Haugeland, Cattell 

This is the first formal release of the Walnut mail system for Cedar.  Please read
the documentation and send a message to WalnutSupport^ before trying to use it.

CAVEAT: While a message set viewer is first displaying itself, do not try to
delete messages from it, or move messages into it; the message set itself will be
alright, but the screen updating can get deadlocked.

WalnutSend
------------
DF file:  [Indigo]<Cedar>Top>WalnutSend.df
Documentation:  Contact implementor
Implementor:  Haugeland 

A mail sending tool for Cedar.  No changes in this release.

Watch
------------------
DF file:  [Indigo]<Cedar>Top>Watch.df
Documentation:  none
Implementor:  Andrew Birrell 

This version of Watch is based primarily on Russ Atkinson's underground
version (plus Scott's bar graph code).  Notable change since 3.3 are display of
free VM pages and largest run of free VM pages.  These (and free MDS pages)
are calculated once per minute, but will be calculated immediately if you click
the "Sample" button.  Other numbers are sampled at a rate given after the
"Interval" button.  Clicking the "Interval" or "GC Interval" button with red (blue)
doubles (halves) the parameter associated with the button.  Note that Watch now
has its own DF file, and is no longer in ViewersAndTioga.df

Waterlily
------------------
DF file:  [Indigo]<Cedar>Top>Waterlily.df
Documentation:  via the "?" facility in the UserExec.
Implementor:  Kolling 

Waterlily now allows the specification of remote files as input files;  the "/" form
of remote spec is not accepted because it conflicts with the use of / for switches.

Help msg changed to document the fact that Comment nodes are not seen when
input files are specified to be Tioga format (the default format).

WorldVM
---------
DF file:  [Indigo]<Cedar>TeleDebug>WorldVM.df
Documentation:  none; interfaces are internal to RTTypes and BugBane
Implementor:  Birrell 

Recompilation only.



Unless otherwise indicated above, questions about changes in individual
components should be addressed to their implementors.


The Release Master