perm filename MINUTE[DOC,AIL] blob
sn#081237 filedate 1974-01-17 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00012 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 SUMMARY OF SAIL IMPLEMENTATION WORKSHOP
C00003 00003 MINUTES
C00007 00004 2. Installation Reports
C00016 00005 3. Discussion.
C00020 00006 PROPOSED SAIL MAINTENANCE PROTOCOL
C00023 00007 2. File format.
C00031 00008 3. Communication Files.
C00037 00009 4. Getting Started
C00041 00010 EXAMPLES
C00047 00011 UNSETTLED ISSUES
C00049 00012 ATTENDEES
C00052 ENDMK
C⊗;
SUMMARY OF SAIL IMPLEMENTATION WORKSHOP
On August 24, 1973, representatives of installations which use the
SAIL language system (for the PDP-10) met at the Stanford Artificial
Intelligence Laboratory in Palo Alto, Ca., to consider matters of
common interest. Of particular importance were issues of
maintenance, communication, and operation under the TENEX operating
system.
The names and addresses of those who attended are included in an
appendix to this report.
Dan Swinehart
10 October, 1973
MINUTES
1. Recent Additions to SAIL
The meeting began with a brief summary of recent Stanford additions
to SAIL. They include:
Enhanced control structures, in the form of Processes, Events,
Interrupts, Procedure Variables; the storage (stack) structures
which support these features was briefly described.
Improvements in the LEAP facilities: typed datums, better print
names, Matching Procedures, and more flexible provisions for
binding Items to Itemvars (mostly in support of Matching
Procedures.)
Backtracking provisions, in the form of named Contexts, and
primitives for Remembering and Restoring variables using
Contexts.
Improved macro facilities, of which specifiable macro body
delimiters, conditional compilation, and access to variable
type information at compile time are most significant. Use of
some of the more complex facilities cause incorrect listings.
Error handling facilities. Currently available are additional
responses to the error (or Usererr) sequence, to allow switching
of error messages to a disk file (logging) for later perusal.
Current error handling is a hodge-podge, and we are planning to
make all error conditions more uniform, and to extend user
options with regard to errors (allowing interface with
interrupts or user-specified procedures).
Debugging facilities. Kurt VanLehn is designing a set of
debugging facilities for SAIL.
We also announced the availability of hard-copy SAIL manuals from the
Stanford Computer Science Dept. publication service. To order one or
more manuals (at about $3 each, I think), contact:
Stanford Computation Center
Polya Hall
Stanford University
Stanford, California, 94305
Attn: Publications
The manual is not yet available in LPT-ready form. We believe we can
create a fairly nice manual, with lower case and other 96-char. Ascii
characters, but without our super-special Stanford characters
(equivalence, "circle-times", double-arrow, etc.). Its availability
will be announced later, via the ANNOUNCEMENT mechanism described
below.
2. Installation Reports
We asked each representative to tell us about SAIL use at his site,
with emphasis on the modifications required to run at his
installation, and the kinds of things people there need, or would
like to see, in SAIL.
Bill Merriam reported on the work BBN has been doing to create a
SAIL system which could operate smoothly under TENEX. This work was
undertaken as part of a contract with JPL. Some of the agreed work
is done (predominantly TENEX-compatible runtime routines written by
R. Smith at IMSSS), and BBN is willing to see it through, although I
think it's safe to say their heart isn't in it. They would seem to
welcome suggestions for graceful withdrawal from the SAIL game.
Bob Smith from IMSSS (Inst. for Math. Studies in the Social
Sciences, at Stanford) described his TENEX-compatible SAIL runtime
routines, which BBN has included in their package. His routines
include routines (e.g., OPEN, LOOKUP, RENAME), which allow old
programs to run, although they use TENEX facilities directly, so
that the DEC-compatible facilities need not be present. He also
provides routines to use the TENEX features more directly. The
package is designed to allow smooth transition between the two
systems. The concensus is that this is a very nice design, and
requires little to be generally accepted as the SAIL TENEX runtimes.
Given the willingness of BBN to provide certain modifications to
TENEX, and some financial support, IMSSS is willing to finish the
TENEX conversion, and presumably to maintain it. The major
unfinished business is completion of a TENEX-oriented SAIL compiler.
John Metzger, from CASE, reported that the LOGOS project there is
writing a new set of LEAP facilities, which will allow storage and
inquiry into a massive data base (on the order of 2↑27 items (and
their datums!), a corresponding number of associations. They expect
to have a working program within six months.
Lee Erman reported that CMU is the first, and probably most
extensive, "expo" user of SAIL. Their speech system is truly
monstrous. CMU has converted the whole thing to a quite recent
version of SAIL, and did not find the conversion terribly difficult.
CMU makes heavy use of the conditional compilation facility, and of
an inter-job communication system of their own design. They would
like to see the merger of inter-job communication with the SAIL
process structure. Perhaps we can convince them to aid in the
design?
Other Carnegie facilities, which they suggest we consider including
in the standard SAIL, are:
The ability to add sharable routines to SAISEG segments.
Additional input modes (automatic lower to upper case conversion,
etc.)
User interrupt before String garbage collection or storage
allocation routines are called -- should be merged with the
Stanford interrupt structure.
A timing package, which works better if a reasonably fast clock
is available.
Lee reiterated a commonly-expressed need for "dynamically allocated
arrays", (or perhaps Algol W-like record structures), and for a SAIL
compiler which can generate PDP-11 code (C. Wilcox at Stanford is
working on that). He can offer very little manpower to help
implement any of these things.
Mike Dervage, representing the University of Utah, was chiefly
interested in the assurance that no matter what we do to SAIL, it
will still run on a standard DEC system, and will still operate
correctly under the DEC TENEX compatibility package -- since they
have one of each system. I believe he can rest easy.
Gary Knott, from NIH, represents a user community which uses SAIL
chiefly for numerical and graphical problems. He has a variety of
suggestions for improvements, including:
Optimizations.
Dynamic allocation (records, or equivalent).
Numerical routines to replace the current Fortran package.
Bob Sproull modified the Fortran routines to operate in the SAIL
environment, when he was at NIH. They use an interrupt structure
("on-conditions") which Bob also included in the SAIL runtime
environment, and the SAIL error message facilities, to provide a
much better integrated package. Gary would understandably like to
see equivalent facilities included in the standard release, because
he is anxious to install a newer SAIL than the one he has, but has
no manpower available to modify it. We intend to do something about
this before the next release.
John Wedel, speaking for JPL, would particularly benefit from a
fairly standard SAIL system, since his group uses SAIL under three
different operating systems (Stanford, ISI, and Cal Tech). He is
quite interested in a TENEX-compatible SAIL. He would also like to
see:
An efficient way to save entire leap environments.
Better numerical routines.
A reasonable interface to the TENEX IDDT.
A good SAIL maintenance procedure.
A mechanism for communicating useful packages among users in the
SAIL community.
3. Discussion.
The discussion which followed centered on Maintenance and
standardization issues. We quickly reached a concensus on several
issues:
a) Most of the users who have custom-tailored SAIL systems, or
who need frequent updates, have ready access to the ARPA
network. We can therefore concentrate our efforts on
convenient network-oriented file maintenance facilities. We
can limit DECUS releases to a tape sent bi-yearly, or
thereabouts. DECUS need no longer also publish SAIL manuals,
since they are now available in quantity from the Stanford
Computer Science Dept. The volume of non-network users will
probably be low enough that Stanford people can handle special
requests.
b) One major difficulty with obtaining a new SAIL system is that
of re-incorporating local features in the Stanford files. We
decided that we would maintain at Stanford a master copy of
SAIL sources, containing recent versions of ALL
installation-dependent features, using conditional assembly
macros to select a particular configuration. We will
provide communication mechanisms to help keep these files up
to date. Although we will not necessarily try to update
installation- dependent things when making changes, we will at
least try to inform the appropriate people when changes might
affect their code. This will be a lot easier when we can see
what that code is.
c) People at other sites need to be warned of impending changes,
both to be allowed a chance to protest or comment, and to be
able to know when the master files are going to change-- when
it is inadvisable to copy master files in order to make their
own modifications.
The following file maintenance protocol is a result of these
decisions. It is a preliminary attempt to design a manual system
which will make remote installation of new SAIL systems go much
smoother. Please let me know what you think of it. We will soon
implement this plan (or a modified version), and will ask that
affected installations take appropriate steps (see below) to provide
us with their installation-dependent code.
PROPOSED SAIL MAINTENANCE PROTOCOL
1. Master files maintained at Stanford (SU-AI).
We will maintain, on the file area [X,AIL], a master set of source
files, comprising:
a) The compiler.
b) The runtime routines (DEC systems, TENEX systems).
c) Auxiliary files -- PTRAN, RTRAN, PROFIL, etc. -- leaving out
some of the random programs (DIRMAK, etc.) included with
previous releases -- only those programs needed by users or
system maintainers.
d) Auxiliary processors, such as FAIL, CREF (block structured),
or DDT (block structured) -- or pointers to them (the master
versions for these programs are typically stored on other file
directories).
e) Documentation: TELLEM (maintenance manual), and citations to
a SAIL manual and a FAIL manual, contained on other file areas
at SU-AI. These will be in a single-column form suitable for
printing on any device which can handle 96-character Ascii.
Files in the first three categories will contain conditional
assembly/compilation macros, whose names will be mutually decided.
Changes to master files will be made only by "authorized personnel",
which currently means SU-AI people, or IMSSS person. They will
perform updates on behalf of other installations in response to
requests, as described below. We may limit the update frequency
(for the sake of stability), although this has not yet been
determined.
2. File format.
2a-- Installation-Dependent Facilities.
We will extend the conditional assembly and bug-indication notations
of the current SAIL files, and will attempt to use these notations
religiously. The former (conditional assembly) is more important,
because we want to maintain the integrity of installation-dependent
features. However, a well-maintained bug and feature indication
policy will make it a lot easier for people to see what has changed.
The remainder of this section sketches the proposed source file
notations.
The inclusion of each installation-dependent (or other optional)
facility will be controlled by a pair of macros (e.g., EXPO and
NOEXPO), which expand to conditional assembly statements. The
current SAIL files contain macros like this. We have placed
additional restrictions on their appearance (see TELLEM), so that
programs may be simply written to manipulate files which contain
them (see IFN below).
We should probably replace the EXPO/NOEXPO pair of macros with a set
of feature names, each controlling a different aspect of the
difference between Stanford's system and others. This has already
been done, to some extent, with [p,pn] specifications, etc., since
some sites have implemented the Stanford conventions. This is also
in line with our desire for mnemonically meaningful macro names.
The macro pairs will include the option for XLISTing non-included
features (turning off listing of these features during assembly), as
an option to the IFN-procedure below.
In some cases -- for instance, the TENEX runtimes -- entirely
disjoint files will be maintained for the different versions.
A single file, FILSPC, will contain the name, complete description,
and default setting for each conditional feature. It will include
the names of the installations which use each feature. It will also
include such specifications as the file names used for libraries and
START_CODE opcodes. This file should be modified at each
installation to configure that installation's system.
The IFN.SAI program is provided on [X,AIL], to allow any
installation to remove the conditional assembly from its copies of
the system, leaving only the installation's customized code. This
should make local files smaller and more readable, at the expense of
extra effort when next comparing to the master files. Use of this
facility is completely optional. Instructions for modification and
use of IFN will be included in its prologue.
2b -- Indication of Bugs and Features.
For the past three years, we have been giving each discovered bug a
unique, two-letter identifier. This tally has reached the
embarrassing figure of "OP" -- something over 400 entries. More
recently, we have begun including these identifiers in the source
code for each fix, in a specialized notation (whose details will be
included in TELLEM). Bugs in the code are denoted by comment lines
containing #bb#, where "bb" is the two-letter bug identifier. These
lines also identify the author of the change, and the date on which
it is made. (Edits specified by remote colleagues will bear their
identification, not those of the "editor".)
We will now begin including a similar notation for new SAIL
features, which have heretofore been inserted without any
indication. The format for features is similar to that for bugs,
except for the delimiter: %ff% will denote the feature denoted by
the two-letter identifier "ff".
An introductory page of each file, contained within comment
delimiters, will be reserved for "version information". For each
edit to a master file an entry will be made in this page denoting
the bug or feature for which the change was made, the author of the
change, and the date on which it was made. The editor we use
enforces this convention, and in addition assigns to each
independent edit a sequence (edit) number, which is part of a
"version number" for the file (standard DEC version number format,
if you're interested).
Each time the master files are updated, the major or minor version
number will be bumped. For instance, version 16-C might yield to
16-D, or 17 to 16-F (changes of the numerical component will
accompany major updates). A complete version number for the file
includes the sequential edit number, as: 16-E(132). Again, TELLEM
will contain details.
3. Communication Files.
In addition to the software sources and documentation files, we will
maintain a set of communication files. In them we will store lists
of bugs, features, requests, announcements, changes, and warnings
("coming soon..."). These files will be changed in response to
local needs, or to requests made via ARPANET or US mail. The
following lists our best guess about the files which will be needed:
BUGS Known bugs, listed by bug identifier (two-letter code). Each
entry, for solved bugs, will contain the file names containing
fixes for these bugs, the author of each fix, and the date. If
the fix pertains only to some configurations, that will be
appropriately documented.
FEATS Planned or installed features, listed by feature identifier.
Maintained in a fashion similar to BUGS. No entry will be made
here until the feature is completely designed, and has been
definitely scheduled for inclusion in SAIL.
CHANGES Changes to be made to master files-- fixes to bugs, new
features, etc. Some take the form of specified patches, some
are citations to files, remote (non-Stanford) or local. Each
also cites a bug or feature number. This file is organized by
individual change, and does not necessarily follow bug or
feature number order. It exists mostly for the benefit of
local people who actually do the master file maintenance.
REQUESTS This is an informal, running list of comments, requests,
complaints, suggestions, etc. Requests will be numbered for
reference. This file will be used for communication between
remotely located people, interested in common segments of the
system. This file will be used to generate features.
ANNOUNCEMENTS Before a set of changes is made to the master files, an
announcement will be placed in this file, detailing the change.
The lead time has not been settled, but will probably be on the
order of a week. Each announcement will also be mailed (via
ARPANET or US mail) to each installation. Another
announcement will be issued when the changes are actually
installed. Each announcement will be labelled by the version
number to which the system is being updated. It will include a
list of the features and bug fixes to be installed.
PACKAGES A list of programs, written in SAIL, which might be of
general interest. Each will contain a citation to the relevant
files. This file will only be maintained if anybody uses it.
LIES It is suggested that we also have a file to specify bugs in the
manual, and in other documentation. This would be similar in
format to the BUGS and FEATURES files.
Additions will be made to these files, in response to mailed
requests, hopefully on a "same-day" basis. It should not be
necessary to include in each message the file which should be
updated. Have we left anything out? Is there too much here? Do
you think we can keep up with this mess?
4. Getting Started
The initialization of the above procedures will be somewhat
difficult. First, we will have to do a few things to prepare for its
implementation:
a) Modify the on-line version of the manual, so that it is more
universally printable.
b) Expand the EXPO/NOEXPO pair into several feature-specific
pairs.
c) Replace special characters in all source files by more
universally printable characters.
d) Integrate the numerical routines (trig, log functions) into
the runtime structure of SAIL (including interrupt routine
interface).
e) Increase the speed of the SU-AI FTP, if possible -- it is
particularly slow.
Then we will collect installation-dependent features from other
sites:
UTAH, NIH, MIT, etc. -- those who haven't installed a new system
recently -- will do best to copy over all of [X,AIL] (after we
announce its readiness), add their special features, and send the
results of any changed files back, in the form of file citations.
We will not change anything on [X,AIL] during this interval, so
that comparison to locate the appropriate features will be fairly
easy. Each installation should include a list of its special
features, and their names.
CMU, JPL(?), CASE -- who have more recent installations -- could
try to make source compares, and send back only the
installation-dependent changes. They could revert to the previous
procedure if this proved too onerous.
It would be useful if those who plan major contributions could plan
to spend a week or so in Palo Alto, to help perform the merger. We
hope, however, that this is not a requisite.
Dates:
December 1, 1973. At this time, the communication files of the
previous pages should be on [X,AIL] and in good shape. The precise
formats and mechanisms for managing them should be completely
designed.
December 1, 1973 to January 31, 1974. This is our current plan for
the merger interval, during which time no changes will be made to
any but communication files on [X,AIL].
Just about any time. We will begin sending ANNOUNCEMENTS, and
filing them in the file of the same name, sometime between now and
December 1.
EXAMPLES
These examples are suggestions of formats to be used to record bugs,
features, announcements, etc., in the various files which need them.
Some are currently used, others are proposed new formats. All are
subject to change-- they are simply my suggestions.
1. Bug format in source files.
This is (approximately) the form currently used. We have not been
quite consistent enough in these to allow any machine-analysis of
these things. We do not intend to unless a need for it arises.
;;#CR# 6-21-72 DCS (2-4) Better TTY listing
; (bug id, date, author, 2d of 4, explanation)
;;#CR#
; (used to terminate a group of lines modified by bug CR).
or
;;#CR#2↓ 6-21-72 DCS (2-4) Better TTY listing
; (two lines changed, no terminating line is needed)
The sequence indication is not needed for a fix which can be done in
one group of lines, or in a couple of groups which are close
together. We have been known to reverse any or all of the above
fields.
2. Bug format on "history" page.
The first or second page of our source files are reserved for a
"history" of bugs and features. Along with some other junk, this
page contains a list of lines, resembling:
COMMENT ⊗
VERSION 17-1(25) 9-19-73 BY HJS FEAT %BN% ADD CVPS AND EVALREDEFINE
VERSION 17-1(24) 11-24-72 BY RHT BUG #KM# TYPO MESSED UP FIXUP ...
...
⊗
The version number follows DECs most recent (I think) format. In
its most general form, it is:
MMm-c(nn), where
MM is the major version number,
m is an optional minor version letter (we seldom use it),
c is a code identifying whether DEC, a software type, or
a lowly user made the edit, and
nn is an edit number, which begins at 1, and is bumped by 1
for every edit, independent of the other parts of the code.
We have an editor which maintains this page semi-automatically. Some
effort could be expended to put more bug/feature aids into our editor,
but none is currently planned.
3. Bug (feature) format in BUGS (FEATS) file.
#IV DRYROTS AT NOSY -- NON-EXTERNAL PROCEDURE
UNDECLARED FORWARD MESSAGE PROCEDURES SHOULD BE IGNORED
[GEN/29] RHT (9-22-72) OK JRL
Bug ID, description, and person who detected the bug (designed the
feature, entered when bug is discovered, or when feature has
been firmly specified.
Files (and page numbers) changed, date of fix, and initials of fixer
entered when the fix has been made and tested (in SOME set of files).
We may need yet another entry to specify when the fix makes its way
into [X,AIL], but that data is calculable from BUGS and ANNOUNCEMENTS.
4. Changes.
Changes will be entered as citations to (Stanford-local or Stanford-remote)
files, for large changes; SRCCOM-type indications for medium-sized changes;
or simple fix-specifications ("change the HRR after ABCDE: to HRRZ"). Each
should have some identification of the author and date of the change. The
CHANGES file should be organized by file, then by lexical order of change
within the file (as described above). I don't believe we need any more
formal format for this.
5. Other files.
These will probably be quite informally organized.
UNSETTLED ISSUES
1. Who will design and implement the merger of inter-job
communication with the SAIL process facilities?
2. Can we extend these methods to universally-used SAIL programs --
like PUB?
3. Should we have a protocol for removing bug indications from source
files after a certain interval (say two years)? This would help
keep the files from looking too cluttered (they will still look
pretty cluttered).
4. It has been suggested that there ought to be a way to denote changes
and features which fall under the general category of "cleanliness".
Examples are bad instruction sequences, poorly commented sections, etc.
We could just make these in [X,AIL] without any special markings, or
perhaps generate on "feature identifier" between each set of [X,AIL]
changes, which could denote all the cleanliness changes. Please comment.
ATTENDEES
Bill Merriam (@BBN)
Bolt Beranek and Newman, Inc.
Research Computer Center
50 Moulton Street
Cambridge, Massachusetts 02138
John Metzger (METZGER@CASE-10)
Case Western Reserve University (METZGER@CASE)
Computing and Information Sciences Div.
10900 Euclid Ave.
Cleveland, Ohio, 44106
Lee Erman (A610LE03@CMU-10A)
Computer Science Dept.
Carnegie Mellon University
Schenley Park
Pittsburgh, Pa., 15213
Robert Smith, Rainer Schultz
Institute for Mathematical Studies in the Social Sciences (IMSSS)
Ventura Hall
Stanford University
Stanford, Ca., 94305
John Wedel, Meir Weinstein (@USC-ISI,WEDEL, WEINSTEIN)
California Institute of Technology
Jet Propulsion Laboratory
4800 Oak Grove Drive
Pasadena, Ca., 91103
Gary Knott
Bldg 12A, Room 3053
National Institutes of Health
Bethesda, Md. 20014
Jerry Feldman, Kurt VanLehn, Jim Low, Hanan Samet,
Dan Swinehart, Russ Taylor (@SU-AI,JAF, KVL, JRL, HJS, DCS, RHT)
Stanford Artificial Intelligence Laboratory
c/o Polya Hall
Stanford University
Stanford, Ca., 94305
(415)321-2300 x4971
Mike Dervage (DERVAGE@UTAH-10)
University of Utah
Computer Science Dept.
Merrill Engineering Bldg.
Salt Lake City, Utah, 84112
Bob Sproull (SPROULL@XEROX-PARC)
Xerox Palo Alto Research Center
Porter Drive
Palo Alto, Ca.
Not present, but also receiving copies of this report:
Jim Goodwin (GOODWIN@BBN)
Alan Rosenfeld, Jim Calvin (@CASE,ROSY, CALVIN)
Donald Williams (WILLIAMS@USC-ISI)
Thomas W. Burtnett
Univ. of Illinois
Coordinated Science Lab.
Urbana, Il. 61801
Pitts Jarvis (PJ@MIT-AI)
Project MAC
Artificial Intelligence Laboratory
545 Technology Square
Cambridge, Mass., 02139
Louis Knapp
Computer Sciences
Syracuse Univ.
Syracuse, N.Y.