Narrative.tioga
Swinehart, June 25, 1985 11:19:35 am PDT

1. Title Slide (30 seconds)
Paper was in every way a joint effort of the three people listed here.
In turn, reports on the work of about 30 people over the past few years.
Most of you've seen or heard something about what Cedar's like to use -- either through demos or earlier publications.
We wanted to say something about how it was put together.
Our paper on the S of C includes an overview of the system which, given the page limit for the proceedings, reads like Readers Digest version of Encyclopedia Brittanica.
Decided better not attempt the Cliff's Notes version of the paper here.
2. Overview (60 seconds)
Intend to show you the Cedar family tree by way of reminding you what it's all about, and where it came from.
Will use a pictorial representation of the major components more as a way of showing you where things are and how connected together than what is in them.
Expand on structural theme by discussing how Cedar applications are generally constructed and modified to try new things.
Finish up with a real-life example drawn from some of the recent work that resulted in the version of Cedar that we brought with us.
3. The Cedar Family Tree (60 seconds)
Cedar and the XDE product that Dick Sweet has just told you about are both direct descendents of the series of systems depicted here: the original BCPL system for the Xerox Alto computer, the very similar Alto/Mesa system, then a successor Mesa system, called Pilot, that has formed the basis for many of our products.  We and the product developers alternately contributed improvements to the Pilot environment for a while.  After that the systems diverged.  XDE became become a product version of the Pilot system, while Cedar moved towards its goal of combining within one environment the efficiency, safety and other benefits of the strongly-typed Mesa language with the flexibility, programming convenience, and other benefits of interactive systems such as Interlisp and Smalltalk.  The Cedar language is a modest extension of the Mesa language; the Cedar system has by now been completely rewritten.
4. What Cedar has inherited (150 seconds) (90 actual)
All of the systems in Cedar's family tree (including Cedar) provide computing environments that are used for a variety of tasks both on personal workstations and on network servers that are built out of the same hardware.  All of them directly support our prototype office applications and they provide direct support for programming tasks: editing, debugging, and so on.  All of them are single-language systems built to run on single-address-space machines.  And they are all built on the concept that we call an open architecture: the operating system is essentially a library of procedures and functions in the host language, so that system routines and user procedures are called in a uniform manner.  The BCPL and Mesa-based systems share with Cedar the additional quality that the system libraries are carefully organized into layers, or divisions (what RES referred to as levels of abstraction).  Because of way components are loaded and initialized, components may not call procedures at higher levels.  However, they may invoke components at any lower level.  This (translucent interface) is, as we'll see, quite useful in an experimental environment. 
5. What's New about Cedar (120 seconds)
So what's new with Cedar? The most apparent addition for the new user is Cedar's automatic storage management.  References to most program-allocated data are garbage-collected when they are no longer needed, in the manner of Lisp or Smalltalk.   and the runtime representation for Cedar data types that is needed to allow the garbage collector to work.  
6. Whole House of Cards (60 seconds)
This picture (and one in paper) are derivatives of diagram used internally during development, known affectionately as Cedar "House of Cards".  Confident the originators of this notion never meant to imply that that the whole thing will collapse in a pile of rubble if you so much as breathe on it -- just opposite, in fact -- but intended to stress the dependencies of upper sections on those below.
Cedar's 4 major divisions, from bottom up in picture, are
Cedar virtual machine,
Low-level nucleus,
Vital user-level components known as Life-support, and
Open-ended set of applications.
As with any system, as you descend lower in the system, the components get harder to change, they affect larger numbers of other programs if you change them, and you have to know more about what you are doing to modify or replace them successfully.  The Cedar machine and Nucleus divisions are released as a unit called a boot file.  At system-initialization, life-support packages are added one by one, through a process that each user can customize if necessary.
In bit more detail,
7. Cedar Machine (30 seconds)
Cedar machine includes microcode supporting Cedar prog. lang. and support required to call procedures, raise and handle exceptions, and the like -- also device drivers.
8. Nucleus (90 seconds)
Nucleus contains components normally associated with operating system -- memory management (virtual memory and support for garbage-collected storage), file system, flexible I/O, access to keyboard and display, communications (still based on prototype protocol known as Pup protocols).
Everything, practically, can use both VM and SS, including file, streams, communications.  Very valuable.
9. Life Support (45 seconds)
Life Support division represents individual packages and tools needed to provide the basic set of document management and programming development features for Cedar user.
Standard set provided with system, although user can reconfigure to some extent.   Includes in addition to editor-based stuff described later, program development tools and simple Unix-like command interpreter.
10. Applications (30 seconds)
Applications not officially part of Cedar, of course, though we do support release methodology for widely-used ones.
11. Structure of a Cedar Application (120)
12. 2d part of same (120)
Before showing you some examples from the actual Cedar system, use simpler one to show how applications are structured:
[flesh out words -- point for this conference -- lang. features eliminate need for hardware and OS features to do this sort of thing.]
[In other words -- same sort of thing you'd do within your own programs -- system and lang make it reasonable to work this way w/system functions -- call it detour approach, indicate how it compensates for module replacement.  Show that if modificed package must export different interface, underlying Mesa config control can keep names spaces separated. ]

13. Cedar Graphics Example (120)
How does this work in real application -- will show you as example that will elaborate later to indicate how the detour approach works.
If you saw demo, this will be familiar -- Tioga is structured text editor that can manipulate galley-formatted text documents or in fact any text viewer.
Viewers are Cedar's means for dividing up the standard display screen; the viewers at the top-level tile the screen with the visible products of the variosu applications that are running.
Viewers can also be nested in order to combine rectangular regions of different types into coherent view -- for instance, the banners containing menu items are subviewers of this one.
There are standard classes of viewers -- text, tioga, illustrations, ...
One of the more unsung heroes of Cedar is the powerful device-independent graphics package, called the Imager. Discussion would fill a talk in itself, but support text, shapes, gray-scale images, w/arbitrary transformations and clipping.
Color, B/W, printer file, directly to printer.
Programs can use viewers without using the Imager, writing directly to the viewer's bit map, but virtually none do.  All standard viewers use Imager.
At bottom of display hierarchy is package called Terminal, gives appearance of several independent sets of B/W and color displays (w/private bit maps), kbd, mouse, which can be assigned to the real one one at a time.  Program that wishes to eschew Viewers and friends can get a separate terminal and have at it, w/or w/out assistance of Imager.
There exists similar hierarchy of keyboard input packages -- high-level event interpreter (TIP), low-level package that buffers keyboard actions (Inscript), and Terminal at bottom determining which VT's interrupt routine gets the kbd interrupt.
We've also included names of typical kernel interfaces -- IO, FS, and the like -- that are used by all these packages at all levels.
[Talk about Commander, Debugger, as cascaded applications?  Exhibits a kind of linkage analogous to Pipes, really -- Tioga feeds command input feeds interpreter, not through language path at all.]
The final example was handed to me on a platter, for which I am duly grateful.
We had been looking for heavyweight examples of Cedar as development environment when Doug Wyatt walked up to me and recounted the fun he had been having.  Since it made many of points here exactly, I decided to recount it to you.
Picture here represents Cedar as it is today.  Previous version was very similar, except that in place of box marked Imager was package called Cedar Graphics.
Imager is newer and much more wonderful (is device-independent, for instance), so its interfaces have changed.
Imager was thought to work pretty well, but needed substantially-revised Viewers, hence Tioga.
Unfortunately, source-level debuging tools require working versions of all these things.
In earlier days, we've had to use a remote-debugging facility, either by probing the test system over the network from a working system, or by examination of suspended memory-images on disk.
Occurred to Doug, correctly as it turned out, that combination of Cedar language features and capabilities of Terminal package would let him use the old versions of all these tings to debug the new ones.
Method was at least conceptually quite simple.
14. Replacing Cedar Graphics with Imager Example (180)
This picture shows the resulting development environment.
The screen at top left represents old, working system, including debugging and program editing tools.
Screen at top right represents new system under development, with its enhanced imaging capabilities.
Old and new screens are assigned to separate virtual terminals; user can switch between them manually.
Picture at lower left depicts old Cedar system, including obsolete Cedar Graphics package.
To produce the new environment, thos components that have changed -- Imager, Viewers, Tioga -- as well as copies of those that are not sufficiently reentrant to support both versions -- in this case, the input package -- are bundled into a single package, or configuration, so constructed that no conflicts arise with similarly-named programs in the remainder of the system.
The developer was able to load this configuraiton and connect it to the spare VT, using the debugging tools in the old development environment to call the appropriate procedures and control their progress.  As it began to run reasonably well, he could toggle the view and interact with it.  (Later on, in fact, as it shaped up, we're told he was able to turn things around so that the new stuff was loaded as the primary display software, while the older versions were packaged up and isolated in its own configuration, for use in a pinch.)  The features of the Cedar language inherited from Mesa, careful design of low-level components like Terminal, & absence of concern over the safe management of storage (as well as a huge, very fast personal machine to run all this on), Have combined to make this sort of thing possible, where in previous systems one would surely have encountered a show-stopping complication.
15. Summary (60)
In conclusion, take moment to look at the directions we expect to take Cedar ....  [I don't like this approach to conclusions, think instead there should be a summary of what makes Cedar relevant to the conference and different from its predecessors.]
By the way, there's another way to look at our systems, and that's to look only their names, rather than their functions.  If we take this view of Cedar, we can see that we've got ourselves into a good deal of trouble, metaphorically speaking.  Here's what I mean.
17. The Cedar Metafive (30)
You see, there's this sea of Pups, and this Dorado, which is apparently this kind of fish, and this Mesa here with this Cedar tree, and ... anyway, thank you very much, and are there any questions?

Notes:
10. Evolution of Cedar
So what's new?
You've seen XDE, one one hand, representing evolution from typeless C-like language through Pascal-like Mesa -- and ST &Interlisp systems on other.
A major goal of Cedar has been to achieve the convenience and safety of these latter systems in a compiled, strongly-typed language, and we believe we've largely succeeded in that.
[Need way here, and here only, to indicate ancestry.]
11. Cedar contributions to open arch.

Points
Language makes things possible w/out Hardware or hairy OS support
Addl type safety added to evolving set of opern architectures
W/out separate address spaces, module replacement, can do some interesting development.
In passing, influence of REF stuff in cleanliness.


�Ê
ý˜˜Icode˜(—J˜š
Ïi˜J˜FJ˜HJ˜vJ˜9J˜©
J˜G—š
�˜J˜mJ˜š
J˜yJ˜„
—
defaultš
Ïe%˜%L˜Š—š
�5˜5L˜Š	—š
�'˜'L˜â—˜$J˜�˜9J˜J˜J˜6J˜J˜Ð—˜š
�˜J˜¨
—š
�˜Jšœ�Ïbœ˜œJ˜i—š
�˜J˜ª
J˜Ò
—š
�˜J˜t———Jš�ž&˜*š�
Ðeiž˜J˜wJš
Ϡ
˜†
Jš
œä˜ä—J˜š ž˜ Jšœqžœ˜‡
J˜™
J˜»
J˜·
J˜HJ˜í
J˜.J˜•
J˜ØJ˜ô
J˜„
Jš
π
˜Ä
J˜NJ˜æ
J˜ž
J˜nJ˜^J˜XJ˜¾
J˜Ë
J˜.Jš ž2˜6J˜9J˜eJ˜dJ˜fJ˜ZJ˜öJ˜•Jš ž˜JšœSÏs¨
˜û
J˜ˆJš ž˜J˜Å
J˜—˜š
�˜J˜J˜“
J˜´
J˜5Jš
�%˜%J˜—˜J˜AJ˜=J˜W—J˜2J˜J˜——…—4(6+