Swinehart, June 21, 1985 9:50:14 am PDT

Most of you've seen Cedar system -- demos, perhaps Teitelman talk or videotape.

We wanted to say something about how it was put together.

Cedar is ... Programming Environment .... Dorado ... Dandelion.

It is by now quite a large system (example -- size, effort).

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 not to attempt the X's Notes version of the paper here, although ...

... will name major divisions and components by way of introduction.

Instead, will touch on a couple of major points covered in 2d part of paper:

Will also mention some of the plans we have for Cedar in coming years. [that's a joke, folks]

This picture (and one in paper) are derivatives of diagram known affectionately as Cedar "House of Cards".

In early going, term might have referred both to dependencies of upper sections on those below and to tendency of entire structure to collapse in a rubble when low-level fails (or weakens).

As time has gone on have increased confidence that foundations are solid.

Cedar's 4 major divisions, from bottom up in picture, are

In bit more detail,

[4 minutes to here??]

Can learn a lot about how Cedar is put together from the H of C picture and an understanding of these attributes, which we've always referred to as an open arch. in former systems that were built more or less this way. [!]

[Repeat points from slide 8; needs fleshing out]

Can learn a lot about how Cedar is put together from the H of C picture and an understanding of these attributes, which we've always referred to as an open arch. in former systems that were built more or less this way. [!]

[Repeat points from slide 8; needs fleshing out]

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.

I want to emphasize the safety (thus reliability) aspect through some examples.

By safety are explicitly concerned with collapse into rubble of bits, destroying memeory-mgmt system and/or debugging tools. Let's see how Cedar's ancestors have dealt with a common programming method -- we'll look at object-style procedure invocations in BCPL, Mesa, and Cedar. [Eliminate this portion]

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. ]

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.

15. New/Old Viewers Example

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.

16. Future Directions for Cedar

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

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?

Points

In passing, influence of REF stuff in cleanliness.

Get following key words into talk