XEROX
PALO ALTO RESEARCH CENTER
Systems Science Laboratory
August 10, 1978
Draft Draft Draft Draft Draft Draft Draft Draft Draft Draft Draft Draft
ToSpruce Implementation Interest
FromDan Swinehart
SubjectSpruce Problems and Shortcomings
This document lists, under various general headings, the things I and others have identified as necessary to produce the "ideal" Spruce. Of course, not all these things will happen, but it is useful to define the entire space as an aid to decision making. Within each category, I have marked those entries that I deem crucial by numbering them in bold face; entries with italicized numbers I deem important but not so crucial. The rest would be nice -- numbers in small fonts indicate wishful thinking.
The following (Swinehart) log book entries contain useful design notes:
8-4-77Error reporting, report destination considerations.
RFS lecture on how Spruce imaging works
8-17-77Checklist of projects, some design details.
8-29-77(p2) A way to do the log file, suggested files involved.
10-23-77 Some ideas on buffer-ahead, w/marked files -- interim disk.
Programming Style (S)
S1.Nomenclature style should be consistent. Follow one of Simonyi’s styles, or something.
S2.Window/SpruceFile names should all be revised to something more reasonable and application-independent.
S3.Investigate and eliminate all "~~" comments throughout the system. Also, I9.
S4.There are places where statics and parameters are used wrong, redundantly, confusingly -- especially printDoc, pDoc, throughout both systems, but not exclusively.
Programming Improvements (cleanliness, robustness) (I)
I1.Use checkpoint mechanism to store and read back "page data" between interpretation and printing passes.
I2.Investigate switch to compacting storage allocator or to IFS-style VMEM/Overlay scheme -- probably not good idea.
I3.Investigate reassignment of some or all of installation responsibilities to Sprint. Spruce then more of an application-independent spooler. Would then probably parse stand-alone requests directly, etc. Problem: error reporting and recovery now requires additional work.
I4.SpruceSpool procedures should be reorganized and rethought. Interface to Post functions should be rethought. See also M1, M2.
I5.Spruce should not be done using OutLd at all (should be revived via counter-Junta). Sprint should be run as an InLd only after it suspends via OutLd for possible continuance.
I6.Find way to suspend Sprint, as now, and run entirely new copy of same in response to high-priority printing need. Could even happen half-through a printing run, w/ appropriate intermediate break page (hard!). Requires finding ways to allocate subfiles within band file. Also, U7.
I7Way to record print-time problems on break page (hard!). Or have extra "canned" break pages to print in addition to the major one. Also, U8.
I8.Read-Write access currently allowed to same file to implement band merge. Revise to use multiple subfiles, arranged backwards from other end. Also, P6.
I9.Investigate and eliminate all "~~" comments throughout the system. Also, S3.
I10.Offset in SPruceFile is P1-based; recover in V to R, R to V.
I11.Save only file maps for files not accessed via buffers?
I12.Many portions of system would submit well to object-oriented approach. Particularly SproullerQ and its maintenance. Would be a good way to approach I4, perhaps some of M1, M2.
I13.Sprint should respond to print request with a "busy, come back soon" abort -- precanned, like the status reply.
I14.Is there a way to do the left over table right?
I15.Do Pimlico, Puffin, Penguin, ..., engine queue control right.
Performance (P)
P1.Improvement of some sort in buffering for files. Current system does virtually no buffering.
P1-1. Overlap disk I/O with computing to achive disk buffering. The desire for this ideal prompted removal of old Spruce disk buffering. May require pre-allocation of fixed total # of disk buffers. Could also increase # of buffers filled each time.
P2.Implement "write without first reading" option for linearly written files.
P3.Use overlay facilities more fully in Sprint -- for system initialization activities, particularly. Alternatively, use overlay initialization routines where needed (much more wasteful of disk space, a little faster).
P4.After P3, analyze Sprint Interpret storage usage, make more robust and make better use of memory. Consider fixed-size, fixed-use blocks for "cacheable" functions. See also P1-1.
P5.xxxx Better Ether ear.
P6.Read-Write access currently allowed to same file to implement band merge. Revise to use multiple subfiles, arranged backwards from other end. Also, I8.
P7.Break up Press files into multiple runs to print bigger ones. On some printers, use more revolutions to print complicated pages. See also E7.
P8.Find contiguous M31 areas during installation -- when OS allows it.
P9.Extend ISF map in larger increments to increase speed. Find out why length hints for Spruce-created files are often not correct. Store each file’s map within the file for speedier installation -- use as hint, but should not often be wrong, since files do not change length.
P10.xxxx Write microcode to rotate 8-row groups to speed up Alto bit map printing.
P11.Write microcode for inner character show loop.
P12.Could checkpoint parts of DocG’s early, leave rest for spooler control -- would save muy space in spooler -- needed?
P13.Improve band merge pass -- use in-core buffer?
P14.Recognize rectangles.
P15.Use "Knox"-style display interface for installation.
Bugs (B)
B1.Inadequate reporting of font names, substituted font names, etc., in various error messages.
B2.Count-H timing bugs -- Sequoia control. General printer control loop. Current manifestations include occasional blank pages after complex pages, etc. -- needs one more serious pass on Dover control loop. R. Sweet has contributed one sample file, and I have another.
B3.It’s possible that "csiz" calculation in ShowInit() is too conservative -- doesn’t add initialization code to available space? Bears checking out.
B4.xxxx Jam laser on during power up sequence, verify polygon speed correct and stable before starting system; include power up sequence in initial spool queue; require manual power up for stand-alone use.
B5.Check to see if "Verbose" switch is still being turned off when the break page has accepted too many error messages.
B6.Version number prints in octal on Spruce status display.
B7.Remove 2↑14 word entity size restriction.
Printing Capabilities (C)
C1.Extend Press format (or use C2 method) to include "printed by" as well as "created by" information. Possibly to include bit map representation for special fonts, probably in device-dependent resolutions. Also extend (C2 not acceptable) to describe complexity of document, for use in optimizing processing.
C2.Extend EFTP communications protocol to include an extra "Print Request Directory", with its own distinctive password, in the trailing page. Press file, unchanged, would precede this trailer. Would supplant most C1 activities, allow additional print priority requests, etc. Some of these things could also be done with an extended command protocol. See also U2.
C3.Capability spooling. Various IFS spooling paradigms.
C4.Handle intensity requests using the ink well.
C5.Handle color requests correctly (Pimlico only).
C6.Print splines, objects, perhaps arbitrary bit maps at low Alto resolution.
C7.New Dover status signals.
C8.Get "official" word on uses of fields in serial #, machine id fields -- modify Spruce appropriately, broadcast the word. (Make Sequoia decision? Pimlico?)
C9."JDS" Spruce -- use XM to get many many fonts at once.
Communication with Users, User Control Facilities (U)
U1.After M1, add log file notion, for use by user interface -- longer history. Entire message/performance/error etc., posting should be integrated. Possibly using the "pDoc" structure as a focus. Also, M2.
U2.Extend EFTP protocol, server to user, to include with ACK a document number for subsequent use in status requests -- or use server socket # somehow, maintain correlation. Extend EARS protocol to provide additional global status, respond to document-specific requests, etc.
U3.Spooler user interface should bereplaced entirely -- by K. Knox type menu? Orbittest or D1Test or ... type menu?
U4.Sprint should always listen, at least a bit, to the keyboard, allowing an abort (equiv. to "suspend to receieve file", but turns off printing) so that interaction can take place.
U5.Spooler user interface facilities in support of:
reprint, change page #, change # copies, abort, reprioritize, release delayed document, etc. See also E2.
U6.Debugging facility allowing Spruce to latch to first host heard, or to be instructed to listen only to {net x, host y}.
U7.Find way to suspend Sprint, as now, and run entirely new copy of same in response to high-priority printing need. Could even happen half-through a printing run, w/ appropriate intermediate break page (hard!). Requires finding ways to allocate subfiles within band file. Also, I6.
U8.Way to record print-time problems on break page (hard!). Also, I7.
U9.xxxx (but more could be done) Revise print pass cursor use.
U10.Reprint of files other than most recent, directly from bands. See U7 for enabling implementation.
U11.Shouldn’t really allow stand-alone invocation of reprint without password or similar protection.
U12.Remote "telnet" style control and detailed status analysis of Server systems (should involve remote Swat as well!!!).
U13.More cross-system exchange of information? Version #’s, spooling or not, report status in LevReport. Revise version # stuff.
U14.Post sending host on break page, esp. when nothing more is known.
U15.Server status server (in clearinghouse?) reports status of printer while it’s down, etc.; helps negotiate printer choice....
U16.See above for extended EARS protocol ideas. Simpler first step: report more load and estimate information in EARS status report.
U17.Improved break page -- see S. Card. See also Spruce messages from S. Card. re: Empress.
Error Management (E)
E1.Need way to report error parameter information (strings, structures, values, etc.) more fully to spooler. Record in inMsg? in checkpoint file? Not clear. This level needs more work.
E2.User interface-invoked facilities for operator-assisted queue repair and scavenging. Or design a responsible queue-scavenging algorithm and build that. See also U5.
E3.Find a reasonable way to deal with Spruce errors, if there are any left.
E4.Find a way to deal with the few remaining SysErr calls -- mostly disk errors and storage management problems.
E5.More data-type-specific parameter codes in Spruce Error Messages -- approaching style of PutTemplate rather than Swat.
E6.Catch loops that return to same page of same file multiple times. Revise pagesPrinted decision in print program for Orbit timeouts, etc.; things that are not likely to get better, and that are document decpendent.
E7.Not all Press file format errors need to be document-fatal; some could just skip or truncate the current page, or terminate at the current position in current page, following with commented break page -- better all in all than the special method now used to create error break pages.
E8.Check for writing a read-only page.
E9.Watch-dog timer to restart if Spruce gets lost? In refresh microcode?
E10.Build restart facility? Dependent on completion of E2.
E11.Better reporting of file name/number information in error reports?
E12.Record higher stack-top than is true, trap overflow errors, for early warning when stack fails to be big enough.
E13.When Print returns with non-fatal report (was behind, etc.), should (ironically) swap false -- not true -- to report the problem, then come back and get the next file.
E14.Print code should dally until last opportunity to jam is past. Will delay progress a bit.
Measurement (M)
M1.Reimplement reporting (high-level, per-document information about what’s happening) and metering (low-level, performance-related stuff) code.
M2.After M1, add log file notion, for use by user interface -- longer history. Entire message/performance/error etc., posting should be integrated. Possibly using the "pDoc" structure as a focus. Also, U1.
M3.Neat way of recording amount of each context’s stack actually used, for use in tuning system stack needs.