*start*
01115 00024 US 
Date: 11 Sept. 1980 10:29 am PDT (Thursday)
From: Horning
Subject: Selection indication, thumb line
To: Brotz
cc: LaurelImp^

Doug,

Now that there are more options, modes, etc. for selection, just putting a vertical
line across the thumb line at the start of the first selection isn't as informative as
desired.  E.g., I often wonder just what I DO have selected in the invisible parts
of the TOC.  Herewith some suggestions:

Beneath the TOC thumb line, place a (rotated and miniaturized) selection
triangle for EACH selected entry.  Consecutive selection might be indicated by
an extended "selection trapezoid.  Use the vertical bar to indicate the currently
displayed message.

Beneath the displayed message thumb line, use a dashed underline to indicate
the range of any active secondary selection in the displayed message.

Ditto for the Composed message, but also use a solid underline for the primary
selection (video reverse of the thumb line for Pending Delete!).  Use a caret to
indicate the typein point.  Get rid of the vertical bar, except as the cursor for
thumbing.

Jim H.

*start*
00685 00024 US 
Date: 24 Sept. 1980 11:51 am PDT (Wednesday)
From: Horning
Subject: Another Multimenu?
To: Brotz
cc: LaurelImp^

I keep hearing complaints of the form "DO/ESC, CANCEL, and MOVE almost
always do good things, but it's hard to predict what they will be, because the
buffers aren't visible."

How about a command that would bring up a multimenu line with brackets for
the deleted and inserted strings?  (And possibly even menu equivalents of
DO/ESC, CANCEL, and MOVE?)  Com-M isn't presently in use.

I sometimes wonder if COM-F and COM-S shouldn't be restricted to bringing up
the corresponding menus, rather than triggering the commands.  More modeless?

Jim H.

*start*
00383 00024 US 
Date: 21 Oct. 1980 3:00 pm PDT (Tuesday)
From: Horning
Subject: Copying entire messages
To: Brotz
cc: LaurelImp^

Doug,

Com+e, Shift+Select counts down a lot of free disk pages if the old Composed
Message was long.  How hard would it be to ensure that the same trick that is
used to avoid this on Get also works when the entire message is selected?

Jim H.

*start*
00545 00024 US 
Date: 11 Dec. 1980 9:28 pm PST (Thursday)
From: Stewart.PA
Subject: Laurel Audio
To: Brotz
cc: Swinehart, Stewart

[Ivy]<Audio>SA>SA.bcd now seems to more or less work, if you know where the
rocks are.  It will record and play 16 kilobit stuff fairly reliably either localy or
remote.  Playing at 64 kilobits almost always works.  Recording at 64 kilobits is
slightly chancy.

I added a command that turns off the display except for the date/time and free
disk region.

Probably a demo is indicated for you two...

	-Ly

*start*
00435 00024 US 
Date: 22 Dec. 1980 7:00 pm PST (Monday)
From: Horning.PA
Subject: Re: Laurel 6T28
In-reply-to: Your message of 22 Dec. 1980 5:21 pm PST (Monday)
To: Brotz
cc: Horning

Doug,

Have you considered making the line interval on continuous scrolling be a
function of the cursor position?  E.g., the scrolling could be at a rate (per two
seconds?) equal to the distance that would be jumped in discrete mode.

Jim H.

*start*
02308 00024 US 
Date: 7 Jan. 1981 9:53 am PST (Wednesday)
From: Lauer.PA
Subject: Re: Smooth scrolling
In-reply-to: Your message of 6 Jan. 1981 2:44 pm PST (Tuesday)
To: Brotz
cc: Lauer

Doug,

The simple answer is that a jump of one line at a time, n lines per second (for
some parameter n) produces smooth scrolling.  Once you have it, you will never
want to go back to Bravo scrolling or jumpy scrolling--it is a real winner.

Bob Ayers, Charles Irby, and others have worked out the smooth scrolling
problem fairly carefully for Star, and Ayers has written a memo.  There, it is
quite complicated because they only want to scroll a small window which is not
the full width of the screen (there is special hardware in the Dandelion to help
this, but we will not be able to implement the microcode, Pilot support, and Star
support to take advantage of it in the first release of Star).

I should think that smooth scrolling will be much simpler for Laurel because
your window is full width and you have the features of the Alto display
controller.  I believe that the strategy is something along the following lines:

	Maintain a bitmap somewhat larger than the window being scrolled (25%
	is the number that comes to mind).  This bitmap can be in two parts, one
	part being the bitmap for the window itself, and the other part being an
	"extension" which is allocated at the time the scrolling starts.  Treat this
	combined bitmap as a circular buffer for lines being displayed.

	Have two processes, a producer and a consumer.  The producer paints new
	lines into the undisplayed portion of the bitmap.  The consumer wakes up
	on every vertical retrace, checks a counter or clock, and (if it is time)
	trims one line off the top of the displayed portion and adds one line to the
	bottom.  This trimming is done by adjusting the pointers and counts in
	the DCB's for the two parts of the bitmap.  The line at the top is returned
	to the producer; if the line at the bottom is not ready, scrolling takes a
	hiccup and waits.

	When the user stops scrolling, you need to consolidate all of the displayed
	lines into your primary bitmap and throw away the extension.

If you are able to do this or something equivalent within the limitations of
Laurel, I think you will have a lot of friends.

/Hugh

*start*
00665 00024 US 
Date: 9 Jan. 1981 3:14 pm PST (Friday)
From: Schroeder.PA
Subject: AltoDir's idea of legal filenames
To: Brotz

---------------------------

Date: 9 Jan. 1981 2:18 pm PST (Friday)
From: Newman.ES
Subject: AltoDir's idea of legal filenames...
To: LaurelSupport.pa
Reply-To: Newman
cc: Newman

...doesn't quite match that of the Alto Operating system. For instance, it allowed
me to rename a file to the new name "@#", but could not delete that file once it
was created. The Executive and Neptune couldn't delete it either. The Tajo
FileTool was able to delete it, however.

/Ron

------------------------------------------------------------

*start*
03107 00024 US 
Date: 30 Jan. 1981 3:46 pm PST (Friday)
From: Swinehart.PA
Subject: unsolicited suggestions re: "scrolling" through mail file names and
 command confirmation
To: Brotz, LaurelSupport
Reply-To: Swinehart
cc: Swinehart

	A note about the (wonderful) new name cycling facilities:

-- would like to be able to scroll (at least a few files) backwards, to compensate
for overshoot.

-- cycling should begin with the file that's currently displayed.  If I'm
reviewing mail files, looking for a specific message, etc., I want to proceed
through all of them.  Similar argument for putting things away (move to).

-- ideally, would like cycling to be shorthand for scrolling through a window
containing the list of file names.  If that window could be made visible, one
could use selection to grab a particular file.  Ignore this comment.

	Note about confirmation:

It's seemed to me for some time that you missed a semantic simplification when it
comes to confirmation.  It goes as follows:

For many of your commands, Red proposes a command, awaiting (optional)
parameter change and confirmation (via Yellow or ESC) before carrying out the
command.  Blue both proposes and confirms the command, using the previous
parameter values, if any -- it's equivalent to Red, followed by Yellow or ESC.

Semantically simplified version:

Red "opens" any parameter brackets associated with the command, arms ESC to
mean "Blue me" (see below), and perhaps provokes a prompt request for
confirmation in the status area.

Blue performs the command over which it is invoked, using the current value of
any parameter -- same as now, but whether or not Red has recently been
invoked.  ESC has been armed to mean the same thing as "Blue applied to most
recent Red command".  Thus Blue picks up the notion of confirmation of Red
along with its current atomic behavior.

Any other mouse activity, or DEL, simply cancels the prompt, disables editing in
the brackets, and does what the mouse would do in that instance.  Now it's less
modeful.

Yellow could continue to mean Blue for a while, only after Red though, just to
allow people to change their ways.

No suggestion about the secondary confirmation requests when zapping old files
or tossing out undelivered messages -- current scheme's as good as any?

You may recognize this as a meander back towards the command/bracket
semantics of BravoX, which I like.  The new thing would be Red as an easier
way to edit the whole bracket field than BravoX provides.  If you also allowed
selection and editing within brackets, you'd just about have a superset of the
BravoX semantics again, except that the referent of ESC would sometimes be
ambiguous.

Side point:  what prompted me to think about this again was some combination of
playing with the new scrolling stuff, and my discovery that for some
bracket-parameter commands (e.g., Get, Put), ESC is the ONLY valid confirmation
character, whereas for others, either ESC or Yellow will do.  That reminded me of
the more general simplification, which would among other things cure the
problem with Get, and ...

*start*
00623 00024 US 
Date: 8 Feb. 1981 3:11 pm PST (Sunday)
From: Schroeder.PA
Subject: "Files" nits / wishes
To: Brotz

---------------------------

Date: 6 Feb. 1981 6:06 pm PST (Friday)
From: Hamilton.ES
Subject: "Files" nits / wishes
To: LaurelSupport.PA
cc: Hamilton

(1) It seems a little strange that, to ctrl-del out of deleting a series of files, you
have to type a <CR> in addition to the ctrl-del, when it's sitting there asking for
confirmation.

(2) It sure would be nice to have a "confirm all deletes automatically" feature a
la IFS.

--Bruce
------------------------------------------------------------

*start*
00569 00024 US 
Date: 10 Feb. 1981 3:26 pm PST (Tuesday)
From: schmidt.PA
Subject: MType under Laurel 6
To: Lyon, Baskett
Reply-To: schmidt
cc: Brotz

I've just gotten MType to run under Laurel 6T30.  Please try

	[Ivy]<cedarlib>mtype>mtype.laurel

and see if it works for you too-- I had to perform surgery to patch up space
leaks, etc. to avoid the ice pick.  (It asks you to give it the command line when
it starts up, e.g. if you typed in the Alto OS

	Mtype -g PROC x.mesa

you would type

	-g PROC x.mesa

when MType asks you for the arguments.)


	Eric

*start*
02777 00024 US 
Date: 23 Feb. 1981 4:08 pm PST (Monday)
From: Horning.PA
Subject: Still
To: Brotz


 I question whether it is necessary in the modeless editor to hang up waiting
for a Cancel on an illegal command.  The modal editor disaster of typing in
"edit" (or whatever) when intending an insertion just doesn't seem to be very
likely while holding down the Com key.

-------------------

Date: 24 Oct. 1980 10:05 am PDT (Friday)
From: Horning
Subject: Helpful Insight?

There is an analogy between selection in the line bar in units of lines and
selection within the text in units of characters.  It occurs to me that this goes a
bit further than just the 90-degree rotation of the cursor and the use of
Red/Yellow to select units/composites.

In particular, the "story" for point-and-type should be that to put the caret
between lines/paragraphs one simply points where one wants it to go, without
worrying about whether the underline goes before or after it.  This implies two
changes to the present scheme:
	-the caret CANNOT be tied to the line that is underlined, and must be
	able to follow a selected carriage return; and
	-"Balance beam" selection must work for Red in the line bar (i.e., the
	caret should move down a line several scan lines before the underline
	does).


 I would still like a set of caret movement operations that would avoid
the necessity of going to the mouse for small jumps.  I have seen the
error of my ways, and am willing to treat these as editing operations, rather than
commands.  I propose using Space with modifiers for this purpose.
-Control+Space will advance the caret over the next character (logically
equivalent to Shift+BS followed by re-typing the character).
-Com+Space will advance the caret over the next word.
-Shift added to either of the above will reverse the direction.
[I have no very strong opinion on which should be the default direction.]

Date: 29 Oct. 1980 6:20 pm PST (Wednesday)
From: Horning
Subject: The Disk, The Clock, and DEL

As I was watching my disk pages tick down one by one, and the displayed time
on the "clock" get farther and farther behind, I had leisure for the following
series of thoughts:

1) Why is it any easier to update the free disk page count than the clock?
[Actually, I presume that it isn't, it's just another routine's responsibility.]

2) Why couldn't the page count update routine also call the clock update
routine?
[After all, the cost of the update must be small compared to allocating or freeing
a disk page.]

3) Why couldn't this same routine also check for DEL-for-cancel?
[Most of the things I would like to cancel use up disk space--slowly but
inexorably.  Further, anything that uses the disk must ALREADY be prepared to
cope with involuntary cancellation.]

*start*
00668 00024 US 
Date: 24 Feb. 1981 12:38 pm PST (Tuesday)
From: Horning.PA
Subject: Name Completion
To: Brotz
cc: LaurelImp^

Doug,

Now that you have code to scan the file cache and directory for names matching
restricted patterns, how about doing so whenever the name in brackets doesn't
match any existing file name?  If the contents of the brackets is a prefix of a
single file, then extend the contents to the full name, otherwise don't (much like
the existing Alto Executive convention).

This would make long, meaningful names less burdensome, and help to alleviate
the problem of remembering what abbreviation has been chosen for a file name.

Jim H.

*start*
01470 00024 US 
Date: 26 Feb. 1981 1:30 pm PST (Thursday)
From: Levin.PA
Subject: Flexible mail stamps
To: Karlton
cc: Schroeder, Brotz, Levin

It appears that variable-sized stamps work in Laurel 6T31.  To permit graceful
future expansion, we would like to have some conventions for the format of the
variable part.  In particular, it should be a sequence of self-identifying entities,
thereby allowing multiple independent programs to manipulate it.  I propose the
following format:

Following the fixed part of the stamp (i.e., the initial 24 characters ending in a
CR), there is an optional variable part, which is present iff the second decimal
number in the fixed part exceeds 24.  The syntax of the variable part is as
follows:

variable-part ::= @ item-list @
item-list ::= <empty> | item-list item
item ::= byte-length space type space contents
byte-length ::= <5-character decimal number as in the fixed part>
type ::= <5-character decimal number as in the fixed part>
contents ::= <sequence of byte-length minus 4 characters>
space ::= <040C>

Semantics:

Types are assigned by a central authority (LaurelSupport).  The byte-length is
the total length of the item in bytes, including the 12 characters occupied by the
byte-count, type, and associate spaces.  Thus, a count of < 12 is illegal.  These
rules imply that the second count in the fixed part of the header can only
legally assume the values 24, 26 (variable part is "@@"), and >= 38.

Roy


*start*
00376 00024 US 
Date: 3 March 1981 11:47 am PST (Tuesday)
From: Levin.PA
Subject: Small correction to Flexible mail stamps semantics
To: Karlton, Brotz
Reply-To: Levin
cc: Schroeder, Levin

contents ::= <sequence of byte-length minus 4 characters>

is in the original.  It should be:

contents ::= <sequence of byte-length minus 12 characters>

Sorry.

Roy

*start*
00890 00024 US 
Date: 4 March 1981 11:25 am PST (Wednesday)
From: Schroeder.PA
Subject: Maybe parse header fort toc should accept only first field encountered.
To: Levin, Brotz

---------------------------

Date: 3 March 1981 9:52 pm PST (Tuesday)
From: Hamilton.ES
Subject: 6T31: Treatment of repeated header fields
To: LaurelSupport.PA
cc: Hamilton

Feel free to beat me up if you think this point is too minor to bother with, but
anyway, it's a minor annoyance to me:

I have had occasion to run either the "To:" or the "Subject:" field onto more than
one line.  It looks much cleaner to have multiple "To:"s or whatever, rather than
just letting it wrap.  Naturally, I put the most important item on the first line. 
However, Laurel's display in the header window is always based upon the
bottom-most line.

--Bruce
------------------------------------------------------------

*start*
00578 00024 US 
Date: 10 March 1981 5:50 pm PST (Tuesday)
From: Horning.PA
Subject: Re: Laurel 6T32--SearchMail
In-reply-to: Your message of 10 March 1981 4:26 pm PST (Tuesday)
To: Brotz
cc: Horning

Doug,

Is it true that marks aren't searched?  They don't seem to be, although that might
be useful.  It might be nice to have some way to specify a pattern for the
mark--you could prompt for it separately.  It might also be nice to (at least
optionally) mark the results of a search, so that this information would persist
even when the selection was changed.

Jim H.

*start*
00820 00024 US 
Date: 11 March 1981 10:00 am PST (Wednesday)
From: Horning.PA
Subject: 6T32 Forms
To: Brotz
cc: Horning

Doug,

"Wouldn't it be nice" if the New form, Answer, and Forward commands were
connected to New.form, Answer.form, and Forward.form (if present).

I realize that it's very little harder to Get{New} than to New form, but I've
become rather attached to the auto-New form on Deliver.  Similarly, it would be
convenient to have the automatic copying on Answer and Forward done into my
forms.  (Rather than substituting into fixed character positions, you could
substitute for the Nth placeholder.)

This will allow people to "personalize" for their own convenience such items as
whether to cc: themselves, how to "sign" messages, etc. (without introducing new
Laurel.profile options).

Jim H.

*start*
00408 00024 US 
Date: 11 March 1981 10:03 am PST (Wednesday)
From: Horning.PA
Subject: 6T32 SearchMail
To: Brotz
cc: Horning

Doug,

I suppose that it would be hard to make this Run command use the Find brackets
for its parameter?  This would stress the uniformity.

Also, I can imagine wanting to do Finds within the messages, using the same
pattern.  ShiftFind for the Displayed Message?

Jim H.

*start*
00902 00024 US 
Date: 12 March 1981 3:44 pm PST (Thursday)
From: Stewart.PA
Subject: Laurel 6T32 Audio
To: Horning,Swinehart,Rovner,Lyon,Pasco
cc: Brotz, Stewart

[Juniper]<DMS>Laurel>6>SA.laurel is the 6T32 version of the laurel audio
program.  It can play and record local and remote audio files when run on an
Alto II with Auburn hardware.

Run it and say p(lay) [Ivy]<Stewart>Temp>msg.adpcm.

D(isplay) is a hidden command that will turn off all but the upper laurel
window when audio files are being shuffled.  This aids performance.

Secondary selection works, naturally.

The type of audio file is determined by the filename extension:

.8bit			64,000 bits/second linear PCM
.ulaw, .u255		64,000 bits/second companded PCM (sounds better)
.12bit, .16bit		128,000 bits/second 12 bit linear PCM
			(too much to handle)
.adpcm, default	16,000 bits/second adaptively quantized DPCM

	-Larry

*start*
02579 00024 US 
Date: 14 March 1981 10:40 am PST (Saturday)
From: Schroeder.PA
Subject: Outstanding complaints and feature suggestions for Laurel 6
To: Brotz
cc: Levin, Birrell

I found these in my message file.

---------------------------

Date: 13 Feb. 1981 8:27 am PST (Friday)
From: Roberts.PA
Subject: overloaded mailboxes
To: LaurelSupport

Does Laurel 6 yet have a way to avoid crashing if the user gets too much mail? 
I.e., if I go away for a week and come back to find more than 300 messages, or
more than will fit on my disk, is Laurel smart enough to retrieve them for me in
batches that I can handle?

Terry


---------------------------

Date: 3 March 1981 10:51 am PST (Tuesday)
From: Hamilton.ES
Subject: 6T31: Timeout funnies
To: LaurelSupport.PA
cc: Hamilton

Laurel still wastes a lot of my time when my mail server is down.  For instance,
when I try to deliver, I quickly get the message "Can't contact any inbox
servers" in the message window up top, but then I have to wait half a minute
before I get the message "Type <esc> to continue, DEL to abort" down below,
even though I typed DEL long ago, which should have immediately aborted
delivery.  Similar (albeit less extreme) delays occur on startup.  Perhaps we could
at least add another Profile item to determine length of timeout?

--Bruce

---------------------------

Date: 5 March 1981 7:37 pm PST (Thursday)
From: Orr.PA
Subject: Unprintable TOCs
To: Brotz
Reply-To: Orr
cc: Schroeder, Levin, Birrell, Orr

The preceding was a mild form of guerrilla warfare, triggered by my frustration. 
My apologies.  However, I do have a problem, and any suggested fixes will be
greatly appreciated.  I am trying to start up on my thesis again, I have piles and
piles of mail files, and somehow I have to abstract TOCs in a useable form, i.e.,
so I can hold them in my hot little hands and see what's in which file, both to
cope with duplicates and to try to abstract patterns.  

Julian


---------------------------

Date: 6 March 1981 1:59 pm PST (Friday)
From: Hamilton.ES
Subject: Subject of Forwarded msgs
To: LaurelSupport.PA
cc: Hamilton

I vote for copying the Subject of the first forwarded msg into the Subject of the
new, composite msg when you bug Forward.  This is what I end up doing
manually nine times out of ten.

Leave off the "Re:", and leave the Subject in pending delete mode to satisfy
people who like the present state of things.

(Gee, if we stay in Alpha test much longer, I'm going to run out of ideas!)

--Bruce
------------------------------------------------------------

*start*
08538 00024 US 
Date: 17 March 1981 9:06 am PST (Tuesday)
From: Schroeder.PA
Subject: Collected wisdom from Laurel 6 testers
To: Brotz, Birrell, Levin, Taft
Reply-To: Schroeder
cc: Horning, Schroeder

Well, I invited comment -- so I shouldn't complain when I get it.  Here's a
summary.

++++++++++++++++++++

KUDOS

1) I love the modeless editor.  This goes without saying, since we designed much
the same interface into Star.  (However you really should get rid of the "balance
beam" method of placing the caret.  Always append.  Or at least make it an
option.  Very error prone. -- Dave Smith

2) I love the ability to EASILY copy existing text.  Just push the Shift key down
and select the text to copy.  Wonderful!  Much, much better than Bravo's or
Star's.  In fact, I'm going to try to get it into Star.  For the first time ever on the
Alto, it really is easier to copy from existing text than to type it. -- Dave Smith

3) I love type-over replacement.  A real time-saver.  This will probably not go
into Star (sigh) because it is just not compatible with Star's concepts.  But it sure
works well for you folks. -- Dave Smith

4) Overall, I really like the system - good work! -- Mike Trigoboff

5) I never encounter any bugs in the software you guys release so, in
desperation, I pass along this trivial observation.  (Appears below)  The care you
take in making your releases really frustrates us nit pickers.a -- Chuck Geschke

6) I've been meaning to tell you:  SearchMail is the greatest thing since sliced
bread!  Thanks! -- Bruce Hamilton
 

SUGGESTIONS/BUGS

1) I have written an itty-bitty program to change between white-on-black and
black-on-white  The program is available as [rain]<Hamilton>laurel>Flip.(mesa
laurel). -- Bruce Hamilton 

2) a brief set of rules for preparing programs for the RUN button. -- Bill
McKeeman

3) an understandable model of the button behavior.  Example: using the middle
button to attempt to expand the bottom window when the system has warned that
something is about to wipe it out.  And I think there are situations where each
of buttons 1, 2 and 3 mean DO IT. -- Bill McKeeman 

4) an "AutomaticUpdate" entry in the profile might be a good default for the
masses.  It seems to me that it is those least able to recover from the self-imposed
trouble of an out-of-date program that are most likely to procrastinate doing what
is necessary to keep an up-to-date version on their disk.  It would also keep a
good version on the public machines for which nobody in particular takes
responsibility. -- Bill McKeeman

5) a profile entry like "InitialBoundary" similar to "Boundary" which would
bring up Laurel with the specified window boundaries -- Bob Weissman

6) a Sort command (or subprogram) to sort a message file chronologically -- Bob
Weissman

7) I have the following lines in my user.cm:

	[LAUREL]
	Boundary: 0, 12, 19, 16
	Boundary: 1, 1, 0, 0
	Boundary: 2, 0, 1, 0
	Boundary: 3, 0, 0, 1
	Boundary: 8, 12, 35, 0
	Boundary: 9, 12, 0, 35

When I invoke COM+8 or COM+9, sometimes it leaves the upper window the
same size and sometimes it makes it a little smaller.  The latter seems to happen
most often when manual size adjustments via the control point are interspersed. 
Sometimes COM+0 does this too.  Am I missing something? -- Dave Smith

8) When I type BACKSPACE with the shift key held down, it deletes forward! 
This is very annoying because one of the most frequent times I make typos is
when I am typing an all uppercase word, like "BACKSPACE", which I do with
my little finger held on the Shift key.  Nice try, but that one just doesn't work. 
Please at least make it an option. -- Dave Smith

9) I find it a minor irritation with Laurel that my copies of my own messages get
flagged with a question mark when retrieved back from the Grapevine.  The
question mark flag should indicate those messages that I haven't yet read, NOT
just copies of my own messages coming back for record-keeping purposes.  In
fact, it would also be nice if copies of my own messages did not count as "new
mail" in my mailbox;  but that is less of an aggravation.    Would it be easy to
leave off the question mark on copies, at least as an option? -- Lyle Ramshaw

10) It would be nice if there could be such a thing as delayed delivery mail. 
That is, one could add message header fields, Delivery-Date and Delivery-Time,
which would permit one to schedule delivery up to, say, a year in the future. 
Such mail could also, perhaps, be cancelled no later than five minutes in
advance of the scheduled delivery time.  The effect of the Delivery Date and
Time is to cause the same effect as if the user had invoked Deliver at the stated
Date and Time.  What would this be useful for?  There are a number of
examples.  One could send out a batch of regularly scheduled announcements,
such as Forum announcements, at the beginning of each month, with delivery
delayed until the beginning of the week in question, and a reminder scheduled
for noon on the same day.  People could schedule reminders for themselves. --
Martin Haeberli

11) editing in brackets -- Mike Trigoboff

12) In SearchMail, could you provide something that just searched the header
field(s) chosen?  Like if I wanted to select all my msgs from LaurelSupport, or all
the msgs I sent, or all with a particular subject.  The search would run a lot
faster if it didn't have to needlessly search the body of each msg.  (The way it
works now is valuable too - this is a request for an additional capability.) --
Mike Trigoboff

13) while "Move to" does a "Delete" as a subcommand, it does not do a "Display
after Delete" when that is enabled.  It seems natural and desireable for it to do so.
-- Forest Baskett

14) PROBLEM WITH "Reply-To":  The sender and answerer both are required to
try think about the insoluble question of who will be interested in the responses
to the original message.  Then, they HAVE TO DO EDITING IN THE MOST
COMMON CASE, which is that everyone the message is sent to will be interested
in the answers, in which case either the sender or the answerer has to delete the
"Reply-To" line.  THIS IS BAD DESIGN.  The whole point of the ANSWER
command is that you should NOT have to do editing on the address in the most
common case!

ALTERNATIVE APPROACH  (Mild version):  Require confirmation when
REPLYING to a distribution list! (Don't we already do this? MDS)  This is
downright obvious.  The lack of this could actually be considered a logical bug
in the current Laurel.  It might even be worth requiring DOUBLE confirmation,
as does copydisk:  "Are you REALLY sure?"

ALTERNATIVE APPROACH  (Strong version):  The ANSWER command simply
does not copy distribution list expressions.  If the answerer wants to reply to a 
dl, he has to edit the dl expression back into the address.  I would favor this
approach. -- Joe Becker

15) In many situations, Laurel treats the middle mouse button as <esc> but not
for files or subsystem name completion in the bottom window.  I find it mildly
inconsistent. -- Chuck Geschke

16) (In the spirit of "last chance")  I like forward-delete a lot, but I
fumble-finger it more than any other feature, and the results can be modestly
devastating:  If I am typing a few capital letters, and want to backspace,  I'm
likely to forget to let go of the shift key.  If it's a single character, that's not too
bad.  If a single word, the greedy algorithm gobbles up the whole next word,
perhaps lines below.  Wouldn't normally be considered a problem, except that:
	1. UNDO doesn't work, since it would back up to before the current
		typein.
	2. Even if it worked, at full speed, I might type too far ahead for it to be
		useful.
I have no suggestions at all; is there anything anyone can think of to make this
less damaging? -- Dan Swinehart

17) I've recently written a couple of handy bcd's to run in Laurel, and I'm sure
the rest of the world will, too.  Do you plan to coordinate all this software, or
should there be a Laurel subdirectory of MesaLib, or should people just blast
msgs out to LaurelUsers^ when they've come up with something handy? --
Bruce Hamilton

18) Laurel 6T33 has a rather annoying habit of not putting the selection where I
bug if I don't leave the mouse in one place for a certain amount of time after
bugging.  Is this intentional? -- Olmstead

19) I just got oopsed several times because my disk filled up.  These are such
gross cases.  I think Laurel should peek ahead a bit more when it is snarfing up
files and such. -- Hal Murray 


*start*
00718 00024 US 
Date: 19 March 1981 11:52 am PST (Thursday)
From: Schroeder.PA
Subject: SearchMail Bug
To: Brotz

---------------------------

Date: 19 March 1981 9:37 am PST (Thursday)
From: Weissman.PA
Subject: SearchMail Bug
To: LaurelSupport
Reply-To: Weissman
cc: Weissman

I started up SearchMail under Laurel 6T33 and got the search string prompt. 
Then I decided I wanted to do a Mail file command first, so I just typed a CR to
SearchMail, figuring a null string would terminate it.  Instead, it entered an
infinite (or very long?) loop, flashing "Malformed search string" and ticking the
grandfather clock.  I had to swat out of Laurel.

------------------------------------------------------------

*start*
00633 00024 US 
Date: 19 March 1981 8:38 pm PST (Thursday)
From: Murray.PA
Subject: AccessList checking
To: LaurelImp^
Reply-To: Murray
cc: Redell, Murray

I use Grapevine to do access control in several places.  Now that I have figured
out what I wanted to do and split the code out into another module, I have
discovered that it's really quite simple.  Have you considered adding a routine of
that sort to one of your interfaces?  I called it ValidMemberOfGroup.

I'll give you a pointer to my code if you are interested, but I'd also be interested
to see if you came up with the same collection of return codes as I did.

*start*
00390 00024 US 
Date: 11 May 1981 1:55 pm PDT (Monday)
From: McKeeman.PA
Subject: (=) <=> [=] {=} "=" '='
To: Brotz

Doug,

In the grand and glorious future:

Considering my sloppy fingers and loose mind, can "COM )" mean "COM (", etc. 
There does not seem to be much to lose -- need not even be documented.  And
besides, who said ( was better than ) to indicate parenthesization?

*start*
01460 00024 US 
Date: 11 May 1981 11:55 am PDT (Monday)
From: KAPLAN.PA
Subject: Host in the reply-to field
To: Laurelsupport

Quite awhile ago I forwarded a complaint that I received from people at MIT, to
the effect that their mail programs were getting screwed up because my messages
to them did not have PARC specified as part of the reply-to field.  When they
used their answer commands, their mail systems thought that "Kaplan" was
supposed to be a name on their local machine.

Mike Schroeder, I believe, replied to my complaint and told me it was their
mailer's responsibility to append the host-name that a message comes from to the
user-name in the reply field.

I recently forwarded Mike's comments to my  MIT friends, they check with their
mail-system people, and they now assert that Parc is doing the wrong thing. 
Here is what they said:

---------------------------

Date: Thursday, 7 May 1981  23:15-EDT
From: Earl A. Killian <EAK at MIT-MC>
To:   HALVOR at MIT-ML
cc:   BUG-MAIL at MIT-MC, lfg.kris at MIT-SPEECH
Re:   Reply to

Kaplan and PARC's mail maintainers are completely and totally
wrong.  I'm surprized that they could be so misinformed.  The
only thing I can suggest is that they read RFC733.

------------------------------------------------------------

If Laurel is in fact doing the wrong thing for Arpanet mail, I hope it can be
fixed soon.  This has caused a fair amount of mail to be either delayed or lost.

--Ron

*start*
00780 00024 US 
Date: 31 March 1981 10:25 am PST (Tuesday)
From: Brotz.PA
Subject: AutoPilot
To: Barth, Suzuki
Reply-To: Brotz
cc: Schroeder, Birrell, Levin, Brotz

[Ivy]<Brotz>AutoPilot.mesa and [Ivy]<Brotz>AutoPilot.laurel implements a
program that continuously fetches new mail when it exists and processes that
mail.

In this program, processing is defined as displaying each message for 5 seconds
and if the message contains a header field labeled "FileUnder", then that message
is also moved to the file designated in the FileUnder field.

Simple modifications to the code can achieve other kinds of processing.  This
program is a model for several processing functions for Cholla.  It could easily be
modified to process CSL-Notebook submissions as well.

-- Doug

*start*
00764 00024 US 
Date: 2 April 1981 11:01 am PST (Thursday)
From: Barth.PA
Subject: Cholla Characters
To: Brotz

I think I mentioned rho before, any chance of getting it in?

---------------------------

Date: 26 March 1981 2:23 pm PST (Thursday)
From: Healy
Subject: Cholla Characters
To: Barth
cc:  Healy

Rick,

Having had a brief intro to Cholla and now being the proud owner of a
Cholladisc I shall be playing with it in the near future and will have some
inputs for you,  especially in regards to equipment status and perhaps a file for
each machine for maintenance logs etc.  The first thing I think we are lacking is
the Greek letter Rho, a standard abreviation for resistivity.

Clark

------------------------------------------------------------

*start*
00567 00024 US 
Date: 2 April 1981 11:18 am PST (Thursday)
From: Wobber.PA
Subject: Leaf CloseTransaction
To: Brotz
Reply-To: Wobber
cc: Wobber

I have implemented the Leaf CloseTransaction op and will be putting that
version of IFS up on Ibis shortly.  (I would think that it would be on Ivy soon
too.)  Can you generate a version of (Remote) Laurel that exercises this op in
normal use??  You are really the only current Leaf client for whom this op is
meaningful and useful ... (ie. the only one who keeps writeMode handles open
for long periods.) 

/Ted

*start*
02565 00024 US 
Date: 4 April 1981 8:15 am PST (Saturday)
From: Swinehart.PA
Subject: Laurel 6T36
To: Brotz
Reply-To: Swinehart
cc: Swinehart

(Haven't fetched it yet, as you can see)

[mood: friendly as usual]

I'm not sure this reversal plus patch is a step forward -- the automatic Reply-To
seemed like the most effective tool you were likely to have in the war against
nerds -- and people get real used to confirming things until they happen.  Did
people really find it difficult to delete the Reply-To line?  I suppose.

Assuming you intend to keep this approach, it brings up another issue -- the
confirmation thing, which inherently increases the temporal modefulness of the
system -- either you confirm or deny, but no other actions are available to you
at the time you're doing it.   The "blue button" approach overrides some
confirmation requests before they happen, but others remain.  (We've discussed
this sort of thing before)  Here's an alternative approach that remains modeless: 

When a situation requiring confirmation arises, blink and moan as now, and
ignore the request.  Then replace the original menu item with one or several
more powerful ones, possibly including one to forget the whole thing.  This
corresponds approximately to the current handling of Hardcopy.  Put the most
likely response at the position of the original, if it's not too dangerous, or put the
one that cancels under the original, if it is.  Now temporal modes have again
been translated into spatial ones, which (shall we pray) is wonderful.

A simpler thing to do is to more widely publicize the cycling capability of the
Get command through .form files, so I can make one with Reply-To in it in the
first place.

Here's something else, more or less related, that I've wanted to be easier -- it's
very specialized, but it happens all the time (you asked for it by diddling
features at this late date):  I'd like to have a keyboard command to delete
(probably by expanding the pending-delete selection?) the entire line containing
the current pending-delete selection.  This is where I don't want to cc the
message to anybody at all.  With this feature you could leave Reply-To in and
make it very easy to delete it.  There's probably a generalization of this feature,
with respect to other kinds of selections, that makes sense.  I know:  ctrl-NEXT. 
I can do it with the mouse but it takes a motion to the mouse,  motion of the
mouse to the line, and two clicks (three unless I'm clever) to get rid of the line.

User programming!  But ship it anyhow!

Dan

*start*
00522 00024 US 
Date: 4 April 1981 7:18 pm PST (Saturday)
From: Ayers.PA
Subject: Laurel Six banging on a Spruce server which is not spooling
To: LaurelSupport
Reply-To: Ayers
cc: Brotz, Murray

Today I observed Laurel Six trying to send a hardcopy to Rockhopper when I
had disabled spooling.

Laurel kept retrying so fast that Spruce was totally busy sending the "Spooling is
disabled please try again later" message and went for extended periods without
being able to print.

This is very bad citizenship.

Bob

*start*
00280 00024 US 
Date: 7 April 1981 11:53 am PST (Tuesday)
From: McKeeman.PA
Subject: Toggling Move to
To: Brotz

Doug,

It is a nit, but left-bugging "Move to" brings up the name of TOC file, and then
complains when you confirm it.  'Twould be better to skip it?

s/Bill

*start*
00512 00024 US 
Date: 8 April 1981 9:25 am PST (Wednesday)
From: Swinehart.PA
Subject: to {...} brackets in Copy
To: LaurelSupport, Brotz
cc: Swinehart

These brackets should probably supply as default a directory-stripped version of
the from field, rather than the last file name used in a previous copy command. 
I think that the from fields of Get and Copy should also be shared, but maybe
there's a reason you don't do that.  (I remember a kludge for turning a Get into a
Copy -- did that survive?)

*start*
00470 00024 US 
Date: 8 April 1981 6:27 pm PST (Wednesday)
From: Haeberli.PA
Subject: Files.laurel
To: LaurelSupport
Reply-To: Haeberli
cc: Haeberli

The rename command provided by Files.laurel has two faults:

a) It fails to effect the rename in the file's leader page; it only changes the
system directory.

b) if I (accidentaly) rename Foo Foo'  the command is accepted, the file is
renamed Foo', and I am ever thereafter unable to access that file.

Martin

*start*
00378 00024 US 
Date: 9 April 1981 7:32 pm PST (Thursday)
From: Murray.PA
Subject: Validity checking of Reply-To
To: Brotz
cc: Knutsen, Murray
Reply-To: nowhere.anyplace

I just replied to a message Dale had sent.  I guess he had typed in the Reply-To
field by hand since it was Kntusen rather than Knutsen.  You should consider
checking it before sending the message.

*start*
00747 00024 US 
Date: 13 April 1981 10:32 am PST (Monday)
From: Swinehart.PA
Subject: Thoughts for Laurel 7
To: LaurelSupport
cc: Brotz, Swinehart

This morning I wanted the "bc" (blind copy) feature.  It's OK with me if all bc
recipients see all bc names, or if each sees only his own -- it's not OK if bc
recipients do not see their names at all.  Private dl's are not really a substitute
for this mildly useful feature.

Suppose a message has arrived with a set of recipients in the to and cc fields,
but no "Reply to".  'Twould be nice to have a feature that would behave as if
there had been a standard "Reply to"  field.  The effect would be to replace the
cc field of the outgoing response message with just the respondent's name.

*start*
01180 00024 US 
Date: 13 April 1981 11:30 am PST (Monday)
From: Lauer.PA
Subject: Messages out of order are a real pain in the arse
To: LaurelSupport
Reply-To: Lauer
cc: Brotz, Birrell, Schroeder, Levin, Lauer, Redell

Thanks for the secondary mail box on Cabernet.  Now I can get urgent messages,
even though my primary mail box on Zinfandel is inaccessible.

On the other side of the coin, messages come way out of order now, and it is
somewhat of a pain to sort them and get the sequence of messages in a
conversation right.  For example, I just got back from vacation and retrieved
some 200 messages from the two servers.  I found early in the file a reply to a 
message very late in the file.  It took a me a long time to sort out who was
saying what to whom.

In retrospect, I hadn't realized that I subconsciously depend on the order of
receiving information as part of interpreting it, but I now realize that I do and
that others probably do also.  While I have been able to cope with nearby
messages being out of order (only a minor annoyance), it seems harder to cope
with out of order messages being very far apart in the file.

What are your thoughts?

/Hugh

*start*
05515 00024 US 
Date: 15 April 1981 5:21 pm PST (Wednesday)
From: McKeeman.PA
Subject: Here 'tis
To: Brotz

The hardcopy leading blanks problem on lines starting with 

The reader would be interested...
It would be better to merely...
---------------------------

Date: 15 April 1981 2:51 pm PST (Wednesday)
Subject: #212, Using Peephole Optimization on Intermediate Code
To: Wulf



Good title.

On the principle that the abstract should give the important results, rather than
tease one into looking for them, I suggest the following slight rewording,

ABSTRACT  We propose an intermediate code for compilers retargetable to most
scientific programming languages and most conventional computers.  We further
present an algorithm for local optimization of the intermediate code.  We
measured a saving of about 16% improvement (in instruction count) over
unoptimized code, at a cost of xx% increase in compile time.  This compares
favorably with several other more elaborate published schemes.

General Commentary.

It is readable.  The English is adequate.  It is wordy, using turgid prose where
tables would suffice (It also needs an adverb predator).   It contains too much
tutorial material.  Why repeat essentially the same examples and reasoning that
has graced this subliterature from the beginning of time?

While the authors could present the important material, essentially the
appendices, in a few pages, I do not believe they wish to do so.  The
unfortunate consequence is that a class or readers, those that are not going to
press on to the end, will never see the best part of the work.  I would put those
tables right there in the way so they have to be explicitly skipped over to be
avoided.

General Summary.  Publish it.

Now for a little bitching and moaning.

(pg 2) The dividing line between compiler and back-end is not clearly drawn.
Moreover the n-language, m-machine strategy gets somewhat more complicated
as n and m increase.  The reader would be interested in what class of languages,
and what class of machines fit into the n or m.  Lisp? Snobol? Prolog? -- A Lisp
machine?  A Turing machine?  Or perhaps it works only for dialects of Pascal
and single address machines.  On page 14 the claim of "many machines" needs
more precision.  

(pg 2)  The underlined emphasis is unstylish and also incorrect.  The most that
can be said is that there are good reasons to do optimizations on the intermediate
code.  Because, by working VERY hard, one could push more than is reasonable
into the intermediate code optimizer.  What can be said is that, if N is the
anticipated number of back-ends, it is worth putting things into the intermediate
code optimizer that are not (roughly speaking) N-times harder to do there.

(pg 3-9)  Only about 1/2 of this stuff is worth reading.  A diagram would be
better than all of section 2.   Most of us that care about the topic can figure out
what code sequences make sense for what languages.  The tricks about
conditionals do need to be emphaized, however.

(pg 4-7)  To repeat myself, his seems summarizable by saying that "it is more
efficient to put patterns in a table rather than in code".  By and large this is a
rehash of the concept of local optimization.  The paper will be stronger with a
much shorter section here.  I definitely get the impression it is written for
someone who understands nothing about optimization.  That is the wrong
audience.

(pg 7-9)  The implicit assumption is that it is time for which the optimization is
being done, and that perhaps space will come along with it.  That is not always
the case and deserves mention.  And, later, space is used as the measure of
success.

(pg 9)  "backs up" is a slightly unfortunate choice of words because might read
"backtracking" into it.  It is the pointer that is backed up so far as I can tell.

(pg 9-16)  Unredeeminly boring.  The authors might question whether this
material is worth including.  What is the point?  You are recapping the
reasoning that led to the results.  It is like finding the musings of a
mathematician in the middle of a proof.  A better approach is to key on the most
significant frequencies, and say where they came from.

(pg 16-17)  The first test is claimed to be "independent of both source language
and target machine".  Just so!  It is therefore an irrelevant measure.  Unless there
is evidence that it makes for a better result, there is no point in publishing the
figures.  A more homely example of this kind of reasoning is: "We knocked down
17% of all the straw men we set up."  There is no way to know if the ADI 0
improvement, for example, is an artifact of a dumb compiler that should never
have emitted it, or a substantive problem now resolved.  The subsequent
comments for PDP-11 code are better.  It would be better to merely present the
latter, and then point out that they do not differ much from figures derived from
EM-1 alone.

(pg 18)  The argument about INC makes no sense at all.  The substance of it is
that in a nice clean intermediate machine, we can depend on doing these things
without wierd side effects.  But then the code emitter will just have to undo the
work because its real INC instruction is in fact wierd, and does not have exactly
the same semantics as the intermediate INC.  A more serious consequence of this
nature is that constant folding might cause an interrupt at compile time that
should occur at run time.  How is this handled?



------------------------------------------------------------

*start*
00986 00024 US 
Date: 16 April 1981 2:35 pm PST (Thursday)
From: Horning.pa
Subject: Confirmation Consistency
To: Brotz
cc: LaurelImp^

Doug,

Right button (Blue) selection in 6T39 does indeed confirm the first set of brackets
for Copy.  However, for the other command with two sets of brackets
(Substitute), it confirms both.

For neither command is there a single action to confirm both sets of brackets
after a left button (Red) or Com+s activation.

I think you should strive for consistency here.  I have a slight operational
preference for Blue as "repeat the command with the same operands" (I do a fair
number of repeated substutions, changing only the selection in between), and a
slight explanatory preference for Blue as "Red followed by Yellow," so won't
scream loudly if either interpretation is picked (consistently).

Blue Get, etc., requires an additional confirmation if there is an undelivered
message, which is consistent with either interpretation.

Jim H.

*start*
00610 00024 US 
Date: 21 April 1981 10:48 am PST (Tuesday)
Sender: McKeeman.PA
Subject: Laurel Documentation
To: Brotz
From: McKeeman

For your pleasure.


					mouse
					 ........
					 ||
					 ||
					 ''''''''

		Left			Middle			Right
		Red			Yellow			Blue
		-----------------------------------------------------

		select			select				extend
		chr/line		word/para			selection


shift		select			select				extend
		chr/line		word/para			source
		as source		as source			selection


control	select			select				extend
		chr/line		word/para			deletion
		for deletion		for deletion			selection




*start*
00756 00024 US 
Date: 22 April 1981 12:39 pm PST (Wednesday)
Sender: McKeeman.PA
Subject: Laurel Matrix, forgot a line
To: Brotz, Burstall
From: McKeeman


				   mouse

				    L M R
				   \  |  /
					 ........
					 ::
					 ::
					 ''''''''

		Left			Middle			Right
		Red			Yellow			Blue
		-----------------------------------------------------

		select			select				extend
		chr/line		word/para			selection


shift		select			select				extend
		chr/line		word/para			source
		as source		as source			selection


control	select			select				extend
		chr/line		word/para			deletion
		for deletion		for deletion			selection


shift/		select			select				extend
control	chr/line		word/para			move
		for move		for move			selection



*start*
01833 00024 US 
Date: 23 April 1981 11:07 am PST (Thursday)
From: Brotz.PA
Subject: Re: Laurel.profile
In-reply-to: Your message of 23 April 1981 1:35 pm EST (Thursday)
To: SLAWECKI
cc: Brotz

Try this one.

Registry: PA
Hardcopy: Windfall
Editor: modeless
ErrorKeys: LaurelX
Font: 0 TimesRoman 10
Font: 5 Helvetica 12 B
Font: 6 TimesRoman 12 B
Font: 9 HyType 11
HardcopyForm: InternalMemo 25730 2540 3500 19050 0 T
 (Options
  (Caption 900 26670 5 T XEROX)
  (Caption 3500 26670 6 T "Network Mail")
  (Heading 3500 26670 0 F Subject 15875)
  (PageNumber 18415 26670 0 F)
 )
 (Rows
  (0 0 35 (Field 3500 10795 0 4 T F 3500 To "" T F T F)
    (Field 12065 19050 0 4 T F 12065 From "" T F T F) )
  (420 22220 35 (Field 3500 10795 0 4 T F 3500 Subject "" T F T F)
    (Field 12065 19050 0 4 T F 12065 Date "" T F T F) )
  (0 0 0 (Field 3500 19050 0 4 F F 4165 PrintForm "" F T T T) )
  (420 0 35 (OtherFields 3500 19050 0 4 T F 3500 420) )
  (1000 0 35 (Field 3500 19050 0 4 T F 3500 In-Reply-To "" F F T F) )
  (2000 0 35 (Body 3500 19050 0) )
  (420 0 35 (Field 3500 19050 0 4 F F 4165 c cc F F T T) )
 )
HardcopyForm: HyType 24730 2540 2500 20000 0 T
 (Options
  (Caption 2500 25670 9 T "Laurel HyType Message")
  (Heading 2500 25670 9 F Subject 15875)
  (PageNumber 18415 25670 9 F)
 )
 (Rows
  (0 0 106 (Field 2500 11000 9 9 T T 2500 To "" T F T F)
    (Field 11500 20000 9 9 T T 11500 From "" T F T F) )
  (420 22220 106 (Field 2500 11000 9 9 T T 2500 Subject "" T F T F)
    (Field 11500 20000 9 9 T T 11500 Date "" T F T F) )
  (0 0 0 (Field 2500 20000 9 9 F T 2500 PrintForm "" F T T T) )
  (420 0 106 (OtherFields 2500 20000 9 9 T T 2500 420) )
  (1000 0 106 (Field 2500 20000 9 9 T T 2500 In-Reply-To "" F F T F) )
  (2000 0 106 (Body 2500 20000 9) )
  (420 0 106 (Field 2500 20000 9 9 F T 3300 c cc F F T T) )
 )



*start*
00334 00024 US 
Date: 24 April 1981 3:58 pm PST (Friday)
From: Horning.pa
Subject: "delivered"
To: Brotz
cc: LaurelImp^

Doug,

Remember this message, which replaces Deliver in the menu after delivery?

It's kind of hard to see these days.  Maybe it should be put up AFTER the
automatic New form, rather than before?

Jim H.

*start*
00333 00024 US 
Date: 29 April 1981 10:38 am PDT (Wednesday)
From: Brotz.PA
Subject: Laurel font
To: Karlton
cc: LaurelImp^, Brotz

I have stored the complete Laurel font on [Ivy]<Brotz>Laurel10.al.  There are
some strangenesses in it, such as having visible blank, tab and CR at their Ascii
code positions + 200B.

-- Doug

*start*
00423 00024 US 
Date: 8 May 1981 11:35 am PDT (Friday)
From: Taft.PA
Subject: Spurious remote file name checking
To: LaurelSupport

If I do a Get of a remote file name containing a "*", Laurel complains "Get failed:
illegal name given".  What business does Laurel have "checking" a remote file
name?  Laurel should parse only the "[host]", and pass everything else on to the
server and let it do the checking.
	Ed

*start*
01469 00024 US 
Date: 8 May 1981 2:18 pm PDT (Friday)
From: Ramshaw.PA
Subject: Can one develop bilingual fingers?
To: CSL^
cc: Ramshaw
Reply-To: Ramshaw

Many people have pointed out over the years that the standard arrangement
of keys on a typewriter keyboard is a pretty poor choice;  note, for example,
that not a single letter of the word "typewriter" is a home key!  Various
efforts have been made over the years to design and propose alternatives.
All have been dismal failures in terms of popular acceptance.  

Despite this undeniable history, I got curious a while back about what it
would feel like to touch-type on a more logical keyboard.  Perhaps I could
learn to touch-type on a superior keyboard without losing my current skill
on the standard keyboard:  "bilingual fingers", so to speak.  So I wrote a
program that, when run from the bottom window of Laurel 6, reconfigures
the keyboard to approximate a Dvorak keyboard (I only permuted the bounding
box of the alphabet:  numbers and all special function keys are unchanged).

The program is on 
	[Ivy]<Ramshaw>Dvorak>Dvorak.laurel.
Running it once will turn your keyboard into a Dvorak one; and running it
again will put it back to normal.  The file
	[Ivy]<Ramshaw>Dvorak>Dvorak.Press
is a picture of the new arrangement of the keys, for use as a cheat sheet
during your first few hours of Dvorak'ing, should you be curious/foolish
enough to want to experiment with this along with me,

Lyle

*start*
00660 00024 US 
Date: 8 May 1981 5:28 pm PDT (Friday)
From: Daniels.PA
Subject: Re: Laurel 6 is released
To: Diplomacy^.ES, Diplomacy^.PA
Reply-To: Daniels

Now that Laurel 6 is officially here, you may wish to try the Hardcopy Form for
Diplomacy messages.  You can find it on
[Phylum]<Daniels>Diplomacy>LaurelProfileSlice.  To use it, simply include it in
your Laurel profile, then when you go to print Diplomacy messages, use
"Diplomacy" for the form (see the Laurel 6 manual for more details.)  Several of
us have been using it for quite some time, and it seems to be about right, but
feel free to change it to suit your own fancy.

			-- Andy. --

*start*
00676 00024 US 
Date: 12 May 1981 10:05 am PDT (Tuesday)
From: Schwartz.PA
Subject: SearchMail
To: LaurelSupport
cc: Schwartz

The released version of SearchMail puts a black box character on my screen
when I type ESC to terminate the search pattern.  I don't remember earlier
versions doing this.

Victor

SearchMail selects all messages in current mail file that contain the "pattern".

Special characters for use in the search pattern are:
   # = any char; * = any string; @ = any alpha; & =  alpha string;
   ! = any non-alpha; ~ =  non-alpha string; 'x = use "x"
ESC terminates the search pattern.

Type search pattern: Brodie
Messages containing pattern: 178


*start*
02776 00024 US 
Date: 12 May 1981 10:49 am PDT (Tuesday)
From: Pettit.PA
Subject: Wrong numbers in Laurel
To: Brotz
cc: Petit, Pettit

Doug, you said you expected to generate controversy over some of your opinions
on social behaviour expressed in the Laurel manual, and you were right.  While
I quite agree with all your comments on dl behavior, I must express my strong
disagreement with your advice on dealing with misaddressed messages.  As
someone with a mailbox which is occasionally confused with another, I feel
qualified to say that people in my situation would suffer from others adhering to
your standard.

For one thing, it is NOT all that presumptuous to suppose you know the mailbox
of the correct recipient.  People rapidly become very familiar with all the
mailboxes which can be confused with theirs.  Many times there is only one
possible confusee, as in my case.  But if a new Pettit variant came on the laurel
scene, I'm sure I would know his/her full name, organizational placement, and
general project area within hours of the first misaddressed message I received for
him/her.  Often messages start with a first name salutation, which is usually
enough to disambiguate them without reading the contents at all.  Other times,
the sender or other recipients are sufficient information.  In cases where it is
unclear who the intended recipient is, your advice is fine, but I contend that
those cases are mighty rare.

Secondly, while I agree with you that it is important that the sender find out
when a message was improperly addressed, a copy to the sender of the forwarded
message should be sufficient warning.

Thirdly, and most important, messages very often have time value.  And many
people only read their system mail once or twice a day.  Messages sent to the
wrong person have already incurred some delay.  If people were to return
misaddressed messages to the sender, they might very well incur an additional
day or two of delay.  If the sender (but not the intended recipient) is away on a
trip or home sick, the delay could be weeks, and an important message might not
get through on time.

Phil Petit rather frequently receives messages for me, usually from people who
know the correct spelling of my name but who simply mistyped it.  I appreciate
his forwarding them to me immediately, and hope he continues to do so.  I will
continue to forward those I receive for Phil to him.

	Teri Pettit

P.S.  As you like analogies, I would contend that most misaddressed laurel
messages are analogous to letters which arrive in the post for a former roommate,
whose new address you know.  In those cases, you do not mark out the address
and let the post office figure out what to do.  You substitute the new address and
mark Please Forward.


*start*
00354 00024 US 
Date: 12 May 1981 11:51 am PDT (Tuesday)
From: Petit.PA
Subject: Re: Wrong numbers in Laurel
In-reply-to: Pettit's message of 12 May 1981 10:49 am PDT (Tuesday)
To: Pettit
cc: Brotz, Petit

Yes, I certainly intend to continue forwarding any of your mail which I get, in
spite of what anyone tells me I should do instead.

--Phil

*start*
00422 00024 US 
Date: 12 May 1981 1:46 pm PDT (Tuesday)
From: Horning.pa
Subject: Laurel 6.1 Suggestion: Hardcopy - Printer, Form, Copies, etc.
To: Brotz
cc: Horning

Doug,

It would be nice if the submenu command brackets had the same "autoscrolling"
feature on Red as other brackets, so one could simply hold down Red to see the
choices.

Autoscrolling (or clicking Red on) Copies should just count up.

Jim H.

*start*
00340 00024 US 
Date: 12 May 1981 2:50 pm PDT (Tuesday)
From: Woods.PA
Subject: 
To: Brotz

I've haven't had time to do more than skim the Laurel 6 manual, but in doing so
I saw nothing about the various interesting characters available, and I think
they would have stood out enough to notice.  An oversight?

	-- Don.

*start*
00425 00024 US 
Date: 13 May 1981 3:03 pm PDT (Wednesday)
From: Brotz.PA
Subject: Re: Wrong numbers in Laurel
In-reply-to: Pettit's message of 12 May 1981 10:49 am PDT (Tuesday)
To: Pettit
cc: Brotz, Petit

I of course support any arrangements made between consenting adults.

Please let me know how your automatic forwarding arrangement works out on
the day that APettit (or APetit) joins the PA registry.

-- Doug

*start*
00500 00024 US 
Date: 13 May 1981 3:47 pm PDT (Wednesday)
From: Artibee.PA
Subject: Laurel 6 Bug
To: LaurelSupport
cc: Artibee

Pages 18 and 19 of the Laurel Manual tell me that a non-default Form used for
Hardcopy should apply only to the one particular invocation of the Hardcopy
command.  NOT SO!

If I invoke Hardcopy-red, use the Form Archive, then subsequently invoke
Hardcopy-blue, I STILL get Archive (not Blank as I expected).

Is this a bug in Hardcopy or the documentation?  /Mary
*start*
00376 00024 US 
Date: 5 March 1981 11:07 am PST (Thursday)
From: Weissman.PA
Subject: Sorting mail files
To: Brotz
Reply-To: Weissman
cc: Weissman

I'm interested in writing a utility to run under Laurel that would sort a mail file
by message date.  Can you tell me what files to look at to discover how to
interface to Laurel in reasonable ways?
Thanks much,
-- Bob

*start*
00601 00024 US 
Date: 15 May 1981 3:46 pm PDT (Friday)
From: Taft.PA
Subject: Re: maxc.. unknown error
In-reply-to: Your message of 15 May 1981 2:38 pm PDT (Friday)
To: Brotz
cc: Schroeder

Yes, it was the usual symptom of a Message.txt file's length getting out of sync
with its contents as a result of a Tenex crash (which occurred yesterday
morning).

Goddammit, I wish Laurel would report the error message reported by the server,
rather than inventing an error message with no information content.  The
message reported by the MTP server in this case is "Mailbox file is malformed".
	Ed

*start*
00553 00024 US 
Date: 15 May 1981 4:05 pm PDT (Friday)
From: Bergsteinsson.ES
Subject: DEL key
To: LaurelSupport.pa
cc: Bergsteinsson

A nit, but a suggestion never-the-less, for downstream Laurel releases.

When composing a message, a DEL key when no DEL key is expected gives the
error message "Unrecognized command.  Type DEL to Terminate command. 
Editor command keys: a, b, etc."  I then type DEL again to get Laurel to ignore
the first one.  Could you please screen DEL from this logic, and simply stay at
the editor command level?

Linda
*start*
00476 00024 US 
Date: 15 May 1981 4:13 pm PDT (Friday)
From: Mitchell.PA
Subject: A feature, bug, or tradition?
To: LaurelSupport.PA
cc: Mitchell

I just tried to Get the file [Juniper]<Mitchell>Ramload.mesa, but typed the
filename as "[Juniper]Ramload.mesa" because the Laurel manual said it would use
the directory <Mitchell>.  Juniper replied "No such file", so I tried again with the
full file name, which worked.  Is this a bug in Laurel or in the manual?

Jim 

*start*
00860 00024 US 
Date: 18 May 1981 1:21 pm PDT (Monday)
From: Birrell.pa
Subject: Laurel remarks
To: Brotz

---------------------------

Date: 18 May 1981 1:19 pm PDT (Monday)
From: Mason.ES
Subject: Re: Moving mailboxes
In-reply-to: Birrell.pa's message of 15 May 1981 12:55 pm PDT (Friday)
To: Birrell.pa
cc: Mason

Thank you for Laurel 6 and its manual (especially the very nice Modeless Editor
Command Summary). I liked the section on the role of courtesy in electronic mail
particularly.

I hereby volunteer to have my mailbox moved -- I am on net #10.

Only one question -- why make the NEXT key next-to-bottom-right blank on
the Alto II keyboard when the Tools environment uses next-to-bottom-Left
blank? In other respects the function keys seem to match in Laurel and Tools.

Mary


------------------------------------------------------------

*start*
00448 00024 US 
Date: 18 May 1981 5:12 pm PDT (Monday)
From: Eisenberg.ES
Subject: Laurel Hardcopy
To: LaurelSupport.PA
cc: Eisenberg

Is there any way to get a Press file on disk of a Laurel message?  Sometimes, we
want to include Laurel messages as reference material in a report, and it would
be nice to be able to get them in Press format without doing a lot of Bravo work. 
(Hardcopy to Filename would be a lovely option.)

-- Savita

*start*
01753 00024 US 
Date: 14 May 1981 10:30 am PDT (Thursday)
From: Brotz.PA
Subject: Laurel 6 HyType printing
In-reply-to: Your message of 14 May 1981 11:01 am EDT (Thursday)
To: SLAWECKI
cc: Brotz, Cowhig, McCaney

To print on the HyType, the Printer option in the hardcopy submenu (that's the
Printer, not the Form), must be set to the word Local.  When the Printer is Local,
if the Form brackets are empty, then the HyType hardcopy form is used, if the
Form brackets are non-empty, then the specified form is used.

You may specify Printer: Local in the profile if that is your default printer. 
(Printer: is a synonym for Hardcopy: in the profile.)  The hardcopy submenu
always overrides the profile.

The possibilities for rampant confusion thus abound.  The problem is that one
must specify two things when printing, the printer and the form.  I choose to
make the Printer dominant, i.e., when you choose Printer {Local}, then the
default hardcopy form changes to HyType, whereas when you choose the Printer
to be anything else, the default hardcopy form is the one listed in your profile. 
Just setting Form {HyType} without setting Printer {Local} will result in the
HyType form used on the Printer specified, which is likely to be a Spruce
printer (Penguin, Dover, etc.)

So, the profile settings should be

Printer: 
PreferredPrinter, Local or PenguinName
DefaultHardcopyForm: 
Preferred form for the Spruce printer

and the Form {} option should be left alone.  Then when printing on the Spuce
printer, the DefaultHardcopyForm from the profile is used, and when printing on
the Local (HyType) printer, the HyType form is used.

This is not explained too thoroughly in the Laurel manual, so you may want to
save this message.

-- Doug

*start*
05803 00024 US 
Date: 12 May 1981 12:16 pm PDT (Tuesday)
Sender: Brotz.PA
Subject: Laurel 6 is released
To: AllEOS^.eos, AllXRCC^.xrcc
From: Brotz.pa, Schroeder.pa, Levin.pa, Birrell.pa
cc: LaurelSupport.pa
Reply-To: LaurelSupport.pa

This message announces the release of "Laurel 6" to message system users in the
EOS and XRCC registries.  Users of all previous versions of Laurel, XLaurel,
and LaurelX should convert to Laurel 6 as soon as possible.  Previous versions
are no longer supported, and may stop working due to changes in the message
transport system.  Laurel 6 will run on all Alto configurations that could run
Laurel 5.1 or LaurelX and on all Dolphins and Dorados in Alto emulation mode.

If you encounter any problems with Laurel 6 please send a message to
LaurelSupport.PA.


UPDATING TO LAUREL 6

Laurel 6 is stored in the <Laurel> directory on the following file servers:

     RoseBowl -- In Pasadena, Net 40
     Aklak -- In Toronto, Net 33

To convert from an earlier version of Laurel to Laurel 6:

    1.  Pick the server nearest (in the Internet) to your customary workstation.
    2.  Retrieve (with FTP) the file "<Laurel>Laurel.cm" from that server.
    3.  Type "@Laurel.cm@ to the Alto executive.

If you are not a current user of Laurel, but wish to try Laurel 6, then follow the
same instructions, but use the command file "<Laurel>LaurelNewUser.cm".


FOR USERS OF Laurel 6T*'s

Some of you have been testing pre-release versions of Laurel 6 for us.  These are
identified by the herald "Laurel 6T*", for * IN [1..42].  It is important that you
also convert to the "official" released version of Laurel 6.  You should also make
sure that you have the most recent versions of the Runnable ".Laurel" files.  The
easiest way to be sure is to present the following command to the Alto executive:

     FTP server dir/c Laurel ret/c Laurel.run ret/u *.Laurel

where "server" is chosen as above.


FOR USERS OF LaurelX

LaurelX is an ASD-produced version of Laurel 5.1 that contains a BravoX-style
editor.  (Do not confuse this with XLaurel, which is a version of Laurel 5.1
designed to run on extended memory Altos.) To make the Laurel 6 editor similar
to the LaurelX editor, add the following line to your Laurel profile:

        Editor: modeless

and then restart Laurel 6.


DOCUMENTATION

Complete documentation for Laurel 6 exists as the file <Laurel>Laurel.press on
each of the above servers.  THIS MANUAL HAS 112 PAGES!  DON'T TRY TO
PRINT IT ON YOUR LOCAL PRINTER DURING NORMAL WORKING HOURS. 
We suggest that each organization arrange to reproduce hard copies of this
manual for local distribution.  Users should wait for an announcement from their
local support organization that copies of the manual are available.   The Laurel 6
user interface is generally upward compatible with previous versions of Laurel. 
Users of previous versions should have no trouble using Laurel 6. 

(The Laurel 6 manual comes in two parts, Laurel.press and LaurelScreen.press. 
Both should be printed and the second inserted after the table of contents in the
first.  The manual is laid out for two-sided printing.  A separate file containing
only the modeless editor summary at the end of the Laurel manual is also stored
on EditSummary.press.)


SUMMARY OF CHANGES

The facilities available in Laurel 5.1 and LaurelX have been merged in Laurel 6. 
Where features of those two systems were in conflict, there is usually a profile
option in Laurel 6 that chooses between them.  Laurel 6 also has a significant
number of changes and improvements over Laurel 5.1 and LaurelX.

The profile options Authenticate:, Herald:, HeraldFont:, Logo:, LogoFont:, Poll:,
and DisplayErrorPups: are no longer recognized by Laurel.  The Authenticate:
option has been subsumed by the Registry: entry in your profile.  The other
entries that deal with hardcopy options are subsumed by more general hardcopy
forms.

The arrangement of screen commands has been altered slightly from previous
versions of Laurel.  The Delete command has been moved next to the Display
command, with the Hardcopy command now placed at the right margin.  The
{brackets} for several commands, e.g., for Get and Put, are now located on a
second menu line that only becomes visible when you need it.  Just invoke
these commands in the normal way; their {brackets} will appear automatically.

The Laurel editor now comes in two flavors, modal and modeless.  The modal
editor is similar to the editor in Laurel 5.1; the modeless editor is similar to the
one in LaurelX.  A large number of new editor commands are available in either
editor.  By default, you get the modal editor.

A new kind of selection, called shifted selection, is an alternative to type-in,
whether you use the old-style editor or the newer modeless editor.  At any time
that Laurel expects type-in, you may hold down SHIFT, make a selection and
then lift up SHIFT.  The selection will be copied as though you had just typed
it, and you may continue type-in.

New screen commands, Copy and Run, are available.  Copy provides FTP-like
services for both local and remote files.  Run allows you to run various programs
while still in Laurel.  These programs exist as *.laurel files on the <Laurel>
directories.  By editing your Laurel profile (using Bravo or laurel) to include the
line

          RunPath: [server]<Laurel>

(where "server" is the one you chose from the list above), you will tell Laurel to
retrieve these programs when you first invoke them.  The program Chat.laurel,
for example, turns your bottom window into a Chat typescript.  To try it
(assuming that you've added "RunPath ... " to your profile and restarted Laurel),
invoke the "Run" command, enter the word Chat into its brackets, and connect or
login to your favorite server.

*start*
00481 00024 US 
Date: 8 May 1981 1:46 pm PDT (Friday)
From: Brotz.PA
Subject: Re: Laurel 6 release for Laurel 6T users
To: @Laurel6.dl
cc: Brotz
Reply-To: Brotz

The command line given in the release message for upating to Laurel 6 was in
error.

The correct command line is

FTP/-e server dir/c Laurel ret/u *.laurel

This will update all of your official *.laurel programs without distrubing any
unofficial ones that you may have.

Sorry for any inconvenience.

-- Doug

*start*
00245 00024 US 
Date: 19 May 1981 12:02 pm PDT (Tuesday)
To: Me
From: Me
Subject: Laurel 6 file size

Laurel 5.1 is 403 pages.  Laurel 6 is 569 pages.  Also, the laurel state file is a little bit bigger.  About 180 pages more in total.

*start*
02215 00024 US 
Date: 20 May 1981 11:27 am PDT (Wednesday)
From: Bergsteinsson.ES
Subject: Suggestions for Laurel Changes
To: LaurelSupport.pa
cc: Bergsteinsson

These are sort of a nit, but you might put them into the hopper of things to
consider if you are going to do another Laurel release.

The ESC in laurel (when Laurel is not waiting for an ESC to confirm some action
or signal the end of input) repeats the last editing command in the composition
window.  The following commands work the way one would expect.
	a - appends same text to current selection
	b - brackets current selection
	d - deletes current selection again
	i - inserts same text in from of current selection
	r - replaces current selection with same text
	t - inserts time stamp in from of current selection

The following commands work other than one would expect.
	e - executes last editing command according to rules above
		recommended action:  None (repeat of "e" is a NOP)
	f - executes last editing command according to rules above
		recommended action: Search forward from the current selection to
		find the next occurance of the text string
	s - replaces current selection with text which was selected at the end of
	    the last "s" command
		recommended action: re-execute substitute logic using the current
		selection and the same values for old and new text strings as were
		used on the "s" command just done
	u - undoes the last editing command
		recommended action: reject undo after e, f, s, g, and p, and leave
		processing of ESC after "u" as is.
	g - looks like the text insertion of a get acts as a repeatable command, but
		it is not redoing a Get using the current selection
		recommeded action: reject ESC after g
	p - executes last editing command according to rules above
		recommeded action: reject ESC after p

If the last command was rejected with an error message, reject the ESC, rather
than go back to a command which preceeded the operator error.

Of all these recommendations, the one which is the most useful would be to
repeat a Find.  (Ungrateful wench, aren't I - give me an inch and I want a
mile.  Oh well, at least you know we are out here using all these wonderful new
features.)

Linda
*start*
00503 00024 US 
Date: 19 May 1981 5:52 pm PDT (Tuesday)
From: Halbert.PA
Subject: bug when running out of disk space while hardcopying
To: LaurelSupport

I was hardcopying a long message, and ran out of disk space while Laurel was
generating the press file.  Instead of dying gracefully, Laurel did an OOPS and
asked me to report the following error to you:

signal 033601 in

(that's it; great, huh?).

Seems like it should just abort the hardcopy and tell the user to delete something.
--Dan

*start*
00213 00024 US 
Date: 19 May 1981 5:57 pm PDT (Tuesday)
From: Halbert.PA
Subject: previous message bug report
To: LaurelSupport

That's Laurel 6 I was telling you about.  Sorry I didn't say before. --Dan

*start*
00900 00024 US 
Date: 21 May 1981 10:03 am PDT (Thursday)
From: Ramshaw.PA
Subject: Laurel suggestion
To: Brotz
cc: Ramshaw

Doug, I request that some future Laurel have a feature that allows the turning
off of the Shift-backspace feature.  I am typing a long message of comments on
the Interpress standard at this point, and there are lots of times when I am
holding down the shift key and typing a long word  (such as ADDNEWID). 
When I make a mistake in typing, I naturally type backspace, and it does the
WRONG THING, eating up the following text instead.  Very annoying.  Of
course, there are other times when shift-backspace is quite convenient, so it
would be nice to keep the functionality---control-backspace maybe?  Mumble. 

(I could avoid this problem if I used shift-lock instead of actually holding down
the shift key, I guess.  Maybe I could train myself to do that...)

Lyle

*start*
00781 00024 US 
Date: 26 May 1981 1:00 pm PDT (Tuesday)
From: Kolling.PA
Subject: selection?
To: laurelSupport
cc: kolling

I (somehow) got the lowest window in a state where about half of its text was
always displayed as selected.  Typing "Everything" flipped the displayed
selection to the other half of the text.  I couldn't get the selection displayed to be
any less than this, although laurel seemed to recognize the points I wanted to
edit at, so I assume only the display function was wierd.  Is this some
phemomenon of the modeless editor?  I don't have modeless in my laurel.profile
and couldn't find anything that looked like this in pawing thru the laurel
manual.  Unfortunately I forgot and quit out of laurel when I couldn't find
anyone to look at it.

Karen

*start*
00365 00024 US 
Date: 26 May 1981 1:23 pm PDT (Tuesday)
From: Kolling.PA
Subject: Re: selection?
In-reply-to: Brotz's message of 26 May 1981 1:11 pm PDT (Tuesday)
To: Brotz
cc: Kolling, laurelSupport

what did you do just before the underline went haywire: I mistyped something
and got the unrec command message, but I don't know what it was that I typed.

*start*
00706 00024 US 
Date: 27 May 1981 4:00 pm PDT (Wednesday)
From: Taft.PA
Subject: Word select
To: LaurelSupport

I used the Tools editor intensively last week, and got into the habit of
double-clicking Red for word select.  I find that in Laurel, double-clicking Red
is much more difficult, and I cannot reliably select words that way.  My "Click"
timeout is set to the standard value, but I don't think that's the problem, since
the default timeout is quite long.  Is Laurel perhaps missing clicks if they are too
close together, or if I move the mouse very slightly between clicks?  (If I'm
moving the mouse, it's not by enough to select different characters on the first
and second clicks.)
	Ed

*start*
00443 00024 US 
Date: 28 May 1981 11:32 am PDT (Thursday)
From: vanMelle.PA
Subject: Laurel and microcode
To: Brotz

Being a Lisp user, it is possible I had the Lisp microcode running at the time,
though I thought I hadn't.  Further experimentation does reveal, however, that
Laurel runs when I boot the standard microcode and gets the trap I described
when I load the lisp microcode, so I guess that was the problem.  Thanks.

	Bill

*start*
00825 00024 US 
Date: 12 June 1981 5:22 pm EDT (Friday)
From: Slade.WBST
Subject: Too many messages
To: Laurelsupport.pa
cc: Slade

I keep seeing these dire warnings about what will happen to you if you don't
have enough space on your disk for all your Laurel messages when you issue
the New Mail command.  Since many people don't read their Laurel mail hourly
or even daily ( don't have an alto, on vacation etc.), this situation may all too
often arise even  if you still have a "lot" of space left on your disk.

Why not a limit on the number of messages that you get when you do a new
mail command, the rest to be done in following New Mail commands or a disk
space check (is this possible)? A laurel profile parameter covering the amount
(pages or messages)  would really be neat.

Mike Slade W114 8-222-4039



*start*
00814 00024 US 
Date: 1 June 1981 11:25 am PDT (Monday)
From: charnley.PA
Subject: Laurel 6 Feature
To: LaurelSupport.PA
cc: charnley

  I couldn't find any reference to it in the manual, or any good use for it, but
there is a peculiar mode which Laurel can get into where invoking a command
which requires typein won't allow typein.

  To enter the mode, start with a fresh Laurel, position the cursor at the left edge
pointing to the "End of Message" in the bottom window.  Then depress CTRL,
then click the left mouse button, then let up the key.  If done correctly, the
cursor in the bottom window should now look fuzzy, and commands like Mail
File with the left mouse button won't work.  The mode can be exited by placing
the cursor in the bottom window and clicking the left mouse button.

     don

*start*
00586 00024 US 
Date: 3 Aug. 1981 2:20 pm PDT (Monday)
From: Brotz.PA
Subject: Hermes and Leesburg
In-reply-to: Tanner's message of 3 Aug. 1981 12:07 pm PDT (Monday)
To: Tanner
cc: LaurelSupport

You can send a message via Xerox Hermes by sending a Laurel message to
<station code> @ XNET, where <station code> is the Hermes station code.  (Don't
type the angle brackets.)

There are many Altos in Leesburg, and they have their own message system
registry, LB.  Check with your correspondents and determine whether you can
send your message directly to someone there.

-- Doug

*start*
01890 00024 US 
Date: 23 June 1981 1:09 pm PDT (Tuesday)
From: Schroeder.PA
Subject: Distribution lists: directory and request form
To: AllPA^.pa, AllES^.es, AllWBST^.wbst
cc: Registrar.es, Registrar.pa, Registrar.wbst
Reply-To: Schroeder

This message announces a hardcopy directory of public distribution lists from the
es, pa, and wbst registries; and a Laurel form for requesting the creation of new
distribution lists.


DIRECTORY

The file <Laurel>DLMap.press, stored on [Erie], [Iris], [Isis], [Ivy], [Oly],
[Phylum], and [Rain], containes a printable listing of the publically available
distribution lists in the es, pa, and wbst registries.  This press file hardcopys on
~17 sides, and can be printed on your local press printer by chatting to the
nearest file server (in the bottom window of Laurel 6) and using the "press"
command.  You may find the listing a handy desk reference when trying to
discover which DL to send a message to.  It will also enable you to discover the
existence of DL you want to join.  A legend at the front of this directory
describes how to read it and gives some advice on the use and maintenance of
DL's.  The listing will be updated ~ once a week, and is a snapshot of the DL
structures in the Grapevine data base.


DL CREATION REQUEST FORM

The file <Laurel>DLRequest.form, stored  on the file servers mentioned above, is
a form for requesting the creation of a new DL.  The form is specialized for each
registry: "es" registry users should obtain it from [Isis], [Oly], or [Rain]; "pa"
users from [Iris], [Ivy], or [Phylum]; "wbst" registry users from [Erie].  To use
this form, "Get" it into the bottom window of Laurel 6 and fill it in as
instructed.  Then "Deliver" it.  The form contains a description of the meaning of
the vaious parameters associated with a DL.  Please use this form whenever
requesting the creation of a new DL.

*start*
01912 00024 US 
Date: 14 July 1981 5:30 pm EDT (Tuesday)
Sender: Axelrod.WBST
From: MCMail.WBST
Subject: Resumption of Monroe County Off-Net Mail Delivery Service
To: AllDLOS^.dlos, AllEOS^.eos, AllES^.ES, AllHENR^.henr, AllPA^.pa,
 AllWBST^.wbst, AllXRCC^.xrcc
cc: (Jim Ferro - CONC) MCMail, (Dave Lang - 102) MCMail
Reply-To: Axelrod

The Monroe County off-net mail delivery service, which had been inactive for
some time, has been resumed.  This service, provided by GSD Mail Services,
allows a Grapevine message, appropriately addressed, to be delivered in hardcopy
form to non-Grapevine addressees.  Similiar services exist in Palo Alto, El
Segundo, Pasadena and Dallas.

Mail to off-net Monroe County locations should be addressed as 

	(Name - location) MCMail.WBST

where "location" represents a valid Monroe county mail stop.  For example, to
send an off-net hardcopy to me in Building 128, address the message to
	(Art Axelrod - 128) MCMail.WBST.
In Laurel6, this format will print properly in either the "To:" field or the "cc:"
field.  Any number of MCMail locations may be included in a single message.

The information within the ( ) represents a "comment" field that will be printed
out when a message is hardcopied from Laurel, while the MCMail.WBST is the
Grapevine mailbox.

Mail Services personnel wil read the MCMail.WBST mailbox, and transmit
hardopies, daily.

Monroe County mail stops are usually buiding numbers.  These numbers have
the following significance:

	001 - 029 = Xerox Square.  Ex: 007 is the 7th floor of Xerox Square
	052 = Xerox Square Annex
	CONC = Xerox Square Concourse
	1xx, 2xx, 3xx = Buildings within the Webster Campus
	8xx = Other Xerox sites in Monroe County

For details, see the Intelnet Telephone directory.

The off-net services at other sites have proven quite successful.  Everyone is
invited to make full use of our service as well.

   Art Axelrod
*start*
01377 00024 US 
Date: 17 July 1981 11:03 am EDT (Friday)
Sender: Axelrod.WBST
From: MCMail.WBST
Subject: Off-Net Mail Services List
To: AllDLOS^.dlos, AllEOS^.eos, AllES^.ES, AllHENR^.henr, AllPA^.pa,
 AllWBST^.wbst, AllXRCC^.xrcc
cc: (Jim Ferro - CONC) MCMail.WBST, (Dave Lang - 102) MCMail, (Joe
 Alhanati)ESMail.es
Reply-To: Axelrod

This is follow up to our recent announcement concerning the resumption off-net
mail services in Monroe County.  Similiar services exist in El Segundo, Pasadena
and Dallas.  Contrary to our previous announcement, no such service currently
exists in Palo Alto.

Another correction:  Mail Services in Monroe County is administered by the Real
Estate Division, rather than General Services Division, as stated.

Grapevine users throughout the network are encouraged to use this service
freely whenever appropriate.  For any questions concerning delivery at specific
sites contact the individuals listed below.  

-------------------
			OFF-NET MAIL DELIVERY SERVICES

SITE		MAILBOX		CONTACT	MAILBOX		INTELNET

Monroe	MCMail.wbst	Art Axelrod	Axelrod.wbst		8*222-5811
County

El Segundo	ESMail.es		Joe Alhanati	(Joe Alhanati)	8*823-7554
							      ESMail.es

XEOS		EOSMail.eos		Ron Gechman Gechman.eos	8*844-2016

Dallas		DLOSMail.dlos	Bob Yost	Yost.dlos		8*723-6145

Stored On: [erie]<NetSupport>Off-NetMail.list
-------------------


*start*
01473 00024 US 
Date: 17 July 1981 9:44 am PDT (Friday)
Sender: Gechman.EOS
From: EosMail.EOS
Subject: XEOS Off-Net Mail Delivery Service
To: AllDLOS^.dlos, AllEOS^.eos, AllES^.ES, AllHENR^.henr, AllPA^.pa,
 AllWBST^.wbst, AllXRCC^.xrcc
Reply-To: Gechman.eos

Off-net mail delivery service at XEOS is now available.  This service allows
hardcopies of appropriately addressed Laurel messages to be delivered to
non-Laurel addressees.  Similiar services currently exist in El Segundo, Webester,
and Dallas.

Mail to off-net XEOS locations should be addressed as either:

	Name - location <EosMail.EOS>
or
	(Name - location) EosMail.EOS

where "location" represents an XEOS mail stop.  For example, to send an off-net
message to me at mail-stop 220, address the message to:

	Ron Gechman - 220 <EosMail.EOS>

In Laurel 6, this format will print properly in either the "To:" field or the "cc:"
field.  Any number of EosMail locations, separated by commas, may be included
in a single message.

The information before the < >  or within the ( ) is a "comment" field that is
printed when a message is hardcopied from Laurel while the EosMail is the
XEOS mailbox.

Publications Services personnel will read the EosMail mailbox each morning and
transmit hardcopies.

The off-net services at other sites have proven quite successful.  Everyone is
invited to make full use of our service as well.

   Ron Gechman
------------------------------------------------------------

*start*
00987 00024 US 
Date: 29 July 1981 5:44 pm PDT (Wednesday)
From: Brotz.PA
Subject: Re: problem with Copy
In-reply-to: Roberts' message of 29 July 1981 2:20 pm PDT (Wednesday)
To: Roberts
cc: Brotz, McGregor

Feature.  You can thank the Alto OS not keeping file types plus Maxc caring
about them.

Copy sends files to Maxc as binary files.  Laurel does not read through the entire
file to discover if it is text the way FTP does.

A text or binary file stored on Maxc is Copy'd to the Alto correctly, as Maxc
knows the type and the Alto doesn't care.

Put in Laurel stores on Maxc as a text file.

If your file is less than 64K characters and is text, then you can store it through
Laurel by Get'ting and Put'ting.  If the file is over 64K characters and is binary,
you can store it on Maxc with the Laurel Copy command.  If the file is text and
over 64K characters, then you have to use FTP.

Note that IFS's do not suffer from this disease, since they have Alto OS's.

-- Doug

*start*
00416 00024 US 
Mail-from: Arpanet host CMU-10A rcvd at 31-MAR-81 1824-PST
Date: 31 March 1981 2122-EST (Tuesday)
From: Xerox Alto
To: Brotz.PA at PARC-MAXC
Subject:  Re: Looking for Laurel directories
Sender: Ivor.Durham at CMU-10A (S200AL00)
In-Reply-To:  Brotz.PA's message of 31 Mar 81 20:12-EST
Message-Id: <31Mar81 212231 AL00@CMU-10A>

The Universities have <Laurel> directories on their IFSes.

Ivor
*start*
00331 00024 US 
Date: 1 June 1981 8:28 am PDT (Monday)
From: Swinehart.PA
Subject: Laurel for universities
To: Brotz
cc: Swinehart

Did we decide what to do?  Could I "release" the programs, and wait on the Blue
and White for the manuals?  Laurel 6 will work OK if the universities have the
latest IFS installed won't it?

*start*
01173 00024 US 
Date: 1 June 1981 9:26 am PDT (Monday)
From: Taft.PA
Subject: Read-only remote mail files?
To: Brotz
cc: Schroeder, Levin, Birrell, Taft

It occurred to me that using the Leaf remote mail file capability might be an
effective way to browse the CSL-notebook, whose summaries are kept in a mail
file on Ivy.  So I invoked MailFile on [Ivy]<CSL-notebook>Notebook-index.mail. 
It worked like a charm.

A while later, I began wondering where Laurel had put the TOC.  I hunted
around and finally found it -- on [Ivy]<CSL-Notebook> !  This worked only
because I am a wheel on Ivy and can create files anywhere.

So I continued the experiment by disabling my Ivy wheel status and trying
again.  This time, MailFile on [Ivy]<CSL-notebook>Notebook-index.mail yielded
the rather strange error message "Disk errors.  Get mail file failed."

It seems to me that if a remote mail file is read-only to me, and there isn't
already a TOC, Laurel should build the TOC either on my local disk or on my
own directory on the file server.  Also, it should delete the TOC when it is done,
since a private copy of a TOC for a shared mail file is not very interesting.
	Ed

*start*
01734 00024 US 
Date: 2 June 1981 11:39 am EDT (Tuesday)
From: SLAWECKI.PA
Subject: Re: Laurel installation
In-reply-to: Brotz's message of 1 June 1981 2:30 pm PDT (Monday)
To: Brotz
cc: Slawecki, McCaney

Doug, all went well with the users to whom I gave Laurel 6, which would be
about 50% of the population.  The rest will be upgraded when I have the new
release of BravoX for them.  Those using Laurel 6 are as enthusiastic about it as I
am.

The only problem that came up with at Corporate and that was that users there
go to LaurelX from Bravo without saving a document on the screen.  Then,
when one quit from LaurelX, one would be dropped back into Bravo with the
unsaved document on the screen.  However, Laurel 6 takes one back to the
Executive and the unsuspecting user loses the document.

I checked with Steve Glassman about this and he told me that Laurel 6 doesn't
support fast swapping.  This will not be a problem with the new software, and
with users having old software, I will have to remove the "Laurel" button from
the configfile.

I've been out of town, but I remember I had asked you about the default
Penguin printer hardcopy form.  The form that comes out is what Laurel seems
to call Internal Memo form.  The form I would like to make default is what
Laurel calls the Network Mail form (it more closely approximates the Memo forms
we use here).  I assumed I could change it somewhere in the profile, but I was
unsuccessful.  I seemed to have a hard time explaining what it is I wanted to do
- does that make more sense?

Also, could you direct me to someplace that would give me an overview of
Grapevine?  I'd like to know how/if it interacts with the file servers, etc.

Thanks as usual.

Connie   
*start*
01884 00024 US 
Date: 2 June 1981 10:03 am PDT (Tuesday)
From: Brotz.PA
Subject: Network mail form
To: Slawecki
cc: Brotz, McCaney

Connie:

Observe the following slice of Laurel.profile:

DefaultHardcopyForm: NetworkMail
Font: 4 Helvetica 8
Font: 5 Helvetica 12 B
HardcopyForm: NetworkMail 25730 2540 3500 19050 0 T
 (Options
  (Caption 900 26670 5 T XEROX)
  (Caption 3500 26670 5 T "Network Mail")
  (Heading 3500 26670 0 F Subject 15875)
  (PageNumber 18415 26670 0 F)
 )
 (Rows
  (0 0 35 (Field 3500 10795 0 4 T F 3500 To "" T F T F)
    (Field 12065 19050 0 4 T F 12065 From "" T F T F) )
  (420 22220 35 (Field 3500 10795 0 4 T F 3500 Subject "" T F T F)
    (Field 12065 19050 0 4 T F 12065 Date "" T F T F) )
  (0 0 0 (Field 3500 19050 0 4 F F 4165 PrintForm "" F T T T) )
  (420 0 35 (OtherFields 3500 19050 0 4 T F 3500 420) )
  (1000 0 35 (Field 3500 19050 0 4 T F 3500 In-Reply-To "" F F T F) )
  (2000 0 35 (Body 3500 19050 0) )
  (420 0 35 (Field 3500 19050 0 4 F F 4165 c cc F F T T) )
 )

This should be the hardcopy form you're looking for.  This form uses fonts 0, 4,
and 5.  Fonts 4 and 5 must be included in the profile if you want them to be
Helvetica 8 and 10.  The XEROX caption is given in Helvetica in this form.  If
you want to change its font to say Logo 12, then change the 5 to a 6 in the

  (Caption 900 26670 5 T XEROX)

entry, and include another font entry for Font 6, i.e., Font: 6 Logo 12

You may rename the form InternalMemo if you wish by changing the
NetworkMail word in the first line of the form to InternalMemo.  If you do so, be
sure to change (or eliminate) the DefaultHardcopyForm entry.

Re fast swapping to BravoX: It's true that Laurel 6 does not support this.  I have
been mentioning this in nearly every message regarding Laurel 6 as a
replacement for LaurelX.

Have you distributed copies of the Laurel manual yet?

-- Doug
*start*
01314 00024 US 
Date: 12 June 1981 11:30 am PDT (Friday)
From: Brotz.PA
Subject: WindowLetter form
To: Kierr
cc: Brotz

First the hardcopy form for the profile.  Substitute information where appropriate
to personalize your name and address.

HardcopyForm: WindowLetter 25000 2540 3150 19050 0 T
 (Options
  (Heading 2700 26750 0 F Heading 18000)
  (Caption 3800 26450 0 T "YourName")
  (Caption 3800 26000 0 T "First line of your address")
  (Caption 3800 25550 0 T "second line of your address")
  (Caption 3800 25100 0 T "third line of your address")
  (Caption 500 18400 0 T ".")
  (PageNumber 18415 26750 0 F)
 )
 (Rows
  (0 21900 35 (Body 2700 19050 0) )
  (0 0 0 (Field 0 0 0 0 F F 0 PrintForm "" F T F F) )
 )

Next, the form suitable for Get for your disk (call it WindowLetter.form)

Subject: 
ForLaurelTableOfContents
Heading: 
For2ndAndLaterPagesOfLetterDeleteIfNotWanted
PrintForm: WindowLetter
From: 
YourNetName
To: 
ForLaurelTableOfContents
Date: 
ForLaurelTableOfContents


AddresseeNameAndTitle

Organization

StreetAddress

CityAndState

Zip									
LetterDate



Dear 
Whoozit,


text

						Sincerely,


						
Signature
cc: 
InterestedParties

To use, Get WindowLetter, edit it, Run InsertMail, Hardcopy with the Form
brackets empty.

Try it, you'll like it.

-- Doug

*start*
00635 00024 US 
Date: 12 June 1981 5:35 pm PDT (Friday)
From: Mitchell.PA
Subject: A minor inconsistency
To: LaurelSupport.pa
cc: Mitchell

I have happened upon a minor inconsistency in the way that the
DisplayAfterDelete feature works. If the message following the currently selected
and displayed has a "?" but is deleted, and you delete the current message,
Laurel will automatically skip to the next undeleted message.  If, however, the
message following the current one does not have a "?" but is deleted, nothing
happens.  This is not quite what the description of DisplayAfterDelete on p.54 of
the manual implies.

Jim

*start*
00292 00024 US 
Date: 17 June 1981 12:39 pm PDT (Wednesday)
From: Weissman.pa
Subject: Laurel OOPS!
To: LaurelSupport
cc: Weissman

Laurel crashes with an OOPS when I try to install a profile with 10 fonts. 
Perhaps there's not enough storage allocated to hold 'em all or some such?

*start*
00434 00024 US 
Date: 19 June 1981 4:37 pm PDT (Friday)
From: Jenkins.PA
Subject: Request for a very important new Laurel form
To: Brotz
cc: Taft, Jenkins

Doug,

Ed Taft suggested the possibility of creating a new Laurel form which people
could use to place their sandwich order and which later could be printed on a
label to give to the delicatessen.  Please see me about it when you can spare the
time.

Thanks

Jeannette

*start*
00657 00024 US 
Date: 22 June 1981 2:18 pm PDT (Monday)
From: Thompson.PA
Subject: Feature please
To: Brotz
cc: Thompson

Doug-

This is one that I really would like.

When you do a Laurel/C it may return to the Alto Exec for a number of reasons,
only one of which is that you had no new mail. I would appreciate if the
message from the response window (You have new Mail, Mailbox empty at 2:05.,
Can't contact authentication server.) would be stuffed into Com.cm as 
"//Mailbox empty at 2:05."

In that way you have a little more inkling of what happened if you didn't
happen to be watching the screen at flash-by time.

Ur mst hmbl srvnt

Geoff


*start*
00708 00024 US 
Date: 24 June 1981 3:37 pm PDT (Wednesday)
From: kolling.PA
Subject: laurel programs
To: Brotz, Hilton
cc: Kolling

I don't know what your plans are for laurel programs, but since I find myself
living in laurel when I'm not programming (this is a nice little executive you
have here.....) here are some wishes:

A program to hardcopy from the lowest window and also by specifying a
filename.  (press and bravo formatting acceptable?)

In a more frivolous vein, an seminar reminder alarm clock that would in either x
minutes (hours) or at xx:xx flash the screen until any character was typed.  This
is useful when spending time reading, etc. and leaving the machine in laurel.

Karen

*start*
04854 00024 US 
Date: 26 June 1981 4:39 pm PDT (Friday)
From: McKeeman.PA
To: Brotz
Subject: hardcopy glitch

See the circled spot on the sheet in your clover box.


-----
Subject: Software Engineers - SPECTRUM
PrintForm: WangLetter
Heading: Software Engineers
From: McKeeman
To: Fagenbaum
Date: 26 June 1981 1:42 pm PDT (Friday)

Joel Fagenbaum
Associate Editor, SPECTRUM
IEEE, Inc.
345 East 47th Street
New York, NY 10017						26 June 1981




Dear Joel,

Jim Horning passed on to me the draft of your essay on Software Engineering.  
He knew that I would be interested because of my new role as Chairman of the
Faculty at the Wang Institute.  I am pleased to see the topic catching your
attention and grateful for the exposure it gives to our new programme.  I hope
you do not mind my giving you my reactions your article and some thoughts I
have had on the same subject.  It is intended to help you in your doubly
difficult task of documenting, as an outsider, something only beginning to be
understood by insiders.

I try to stay aware of the meaning of the title:  Engineer, "one who applies
ingenuity", and Software, which was a catchy way to say not-hardware, and
really signifies the information held in, and processed by, the hardware.

In contrast to the undifferentiated skill set of
		programming+hardware design+systems engineering
you postulated, we at WIGS have decided that a Software Engineer must be
firstly skilled in programming and also, but secondarily, know enough about
hardware, computer application areas, and managing people to produce high
quality systems of programs.  It is my personal conviction that what we will do is
better modelled by a medical school than an academic curriculum in Computer
Science.

A major difficulty faced by the software engineer is an unusual need for
breadth.  As you note, inexorably computers are going to be everywhere.  It is
not likely that a single Software Engineer is going to be a robotics expert,
proficient in business data processing, a network communications analyst, a
solver of integral equations and a VLSI designer.  We will, as do our medical
analogs, have specialties.  Our approach at WIGS is to define a core curriculum
around the universal skills we all need, and then differentiate with electives and
project courses to help our students develop one or more specialties. ( I will
arrange for a pile of material representing the present state of the curriculum to
be sent to you.)

Changing the subject, I quote from my recent letter to Harlan Mills, on the topic
of management skills for Software Engineers:

"One management problem arises in that complexity drives us to using teams.  No
matter what the tolerance for complexity some (perhaps remarkable) individual
has, (we know now that) there are much lower limits on the acceptable
complexity of the interactions within teams.  This has led to the anomaly of
systems that can be built well by one person, or many people, but by no size of
team in between.  It seems to me that the management curriculum must focus on
those techniques that we have found close the anomalous gap.  Of course,
complex systems are going to be built in any case; the measure of success of the
management techniques is the quality of the resulting product.

The problem is in a sense recursive; the production of automated management
tools is within our technical expertise.  We apply our own wares to our own
problems.  For example, I regard the cost models from TRW, and various
integration and testing tools as within the nascent management curriculum."

A characteristic of information systems which is well-known, but frequently
ignored is that, like buildings, one expects to change them over a period of time. 
An architect would not call adding a wing to his hospital "maintenance".  In the
analogous situation, we software engineers do.  The important thing is not, of
course, the words used, but the preparations made.  Making a system modifiable
is much harder than just making it work.

Valuing software is another dimly understood area where we must develop
expertise.  Software has cost to build, cost to replace, market value, rental value,
(perhaps) taxable assessed value, and so on.  Although we have a good deal of
tolerance now, in the longer run the software engineer must be able to make
closely reasoned economic decisions.

Well, I can obviously go on at length.  The details are not the point of my letter
to you.  Rather I hope to reinforce the seriousness with which we regard the task
of building the practice of Software Engineering.  It's short history is admirably
exposed by Professor Hoare in his Turing Lecture (see the February 81
Communications of the ACM).  I summarize it all by Thoreau's dictum
"Simplicity, simplicity, simplicity!".  




						Cordially,


						W. M. McKeeman



cc: WIGS
*start*
00989 00024 US 
Date: 29 June 1981 5:12 pm PDT (Monday)
From: Schroeder.PA
Subject: A real bug?
To: Brotz
cc: Schroeder

FileIn Use from CoreStreams when IntPress attempted to open a write stream on
Swatee.

---------------------------

Date: 29 June 1981 5:00 pm PDT (Monday)
From: Beeson.ES
Subject: Error Report
To: LaurelSupport.PA

I was "hardcopying" a rather long message with a form and a printer that were
different than what was in my Laurel.profile.

Laurel 6  Alto II XM (010#073#) with Ram only MDS: 00 Banks: 100000 code:
000051

Signal 033601 in CoreStreams
msg 000025, msg^                            

BackStop, 003550
Signaller, 000521
Signaller, 001102
CoreStreams, 002703
CoreStreams, 000256
IntPress, 002755
IntHardcopyCom, 002200
IntHardcopyCom, 000340
IntHardcopyCom, 001272
IntTrackMain, 001747
IntTrackMain, 001250
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000122
DebugNub, 000334

------------------------------------------------------------

*start*
01130 00024 US 
Date: 1 July 1981 1:41 pm PDT (Wednesday)
From: GWilliams.PA
To: Brotz
Subject: The "reply-to" field fill-in

Mail-from: Arpanet host SRI-KL rcvd at 1-JUL-81 1053-PDT
Date:  1 Jul 1981 1051-PDT
From: LARSON at SRI-KL
Subject: your message
To: GWilliams at PARC-MAXC

  I noticed that the headers to your message included a "reply-to:"
that did not include a site name.  I suspect that you did not intend
it to be this way, since some net sites would get confused and try to
reply to "GWilliams" as a local address at their site.  This is a
potentially serious problem, since you may not get mail that people
answer from other net sites.  Your "from:" was correct, so you could
actually eliminate the "reply-to:" and other mail programs will reply
to the "from:".
	Alan


Subject: Re: your message
In-reply-to: Your message of 1 Jul 1981 1051-PDT
To: LARSON at SRI-KL
cc: GWilliams

Yes, but unfortunately, my mail program requires me to add the reply-to: when
sending to distribution lists. The reply-to: is added for me. I can edit it  but
hadn't. I'll see if our mail people want to address this.

Glen

*start*
00606 00024 US 
Date: 7 July 1981 5:17 pm EDT (Tuesday)
Sender: MarkWilson.EOS
From: MarkWilson
Subject: Hardcopy Problem
To: LaurelSupport.PA
cc: MarkWilson

I have had this problem on and off for some time where I cannot hardcopy from
Laurel.  I get the message "Printer not responding" in Laurel and the message on
the printer server screen is "Receiver timed out".  I am running Laurel 6.0 but
this happened with 5.0 as well, though not as persistently.  Our printer server is
running Spruce 11.0 with a Penguin.

Putting and Empressing Laurel messages is no fun.  Do you have any
suggestions?
*start*
00418 00024 US 
Date: 9 July 1981 2:19 pm PDT (Thursday)
From: Lyon.PA
Subject: Re: Laurel 6 is released
In-reply-to: Brotz's message of 8 May 1981 1:03 pm PDT (Friday)
To: LaurelSupport

Here's a problem I encountered:

The blinking caret can not be at the end of a selection that ends with a return.
In particular, it is not possible to append a paragraph to a paragraph without
cleaning up the interfaces.

*start*
00853 00024 US 
Date: 12 July 1981 6:08 pm PDT (Sunday)
From: Taft.PA
Subject: Slight glitch in Answer
To: LaurelSupport

If a message contains an unqualified recipient name with trailing blanks, and
Answer needs to append a registry when constructing the reply form, the
trailing blanks appear between the name and the registry, as shown below.

This is of no practical consequence, since Deliver seems to be able to deal with
the resulting recipient name.  Just thought you'd be interested.....
	Ed

-------------------
Date: 12 July 1981 11:13 am PDT (Sunday)
From: Resnick.ES
Subject: OLY
To: Taft.PA, Murray.PA
cc: PSmith, EDSupport, PSDSupport , Resnick

Subject: Re: OLY
In-reply-to: Resnick.ES's message of 12 July 1981 11:13 am PDT (Sunday)
To: Resnick.ES
cc: Taft, Murray, PSmith.ES, EDSupport.ES, PSDSupport .ES
-------------------


*start*
01226 00024 US 
Date: 14 July 1981 11:02 am PDT (Tuesday)
From: Fikes.PA
Subject: 80 versus 72 character lines
To: laurelsupport.pa
cc: Fikes

What do you suggest regarding the following request.  I have also encountered
this problem when reading mail at home using msg.  If there is no facility in
laurel for adjusting margins (I couldn't find one mentioned in the manual), then
I would suggest adding one to the profile file.

richard

---------------------------

Mail-from: Arpanet host BBND rcvd at 13-JUL-81 1528-PDT
Date: 13 Jul 1981 1825-EDT
Sender: WOODS at BBND
Subject: Re: Role Decompositions
From: WOODS at BBND
To: Fikes at PARC-MAXC
Cc: klone-klub at ISIF, mark at ISIF, Woods
Message-ID: <[BBND]13-Jul-81 18:25:23.WOODS>
In-Reply-To: Your message of 9 Jul 1981 15:15 PDT


Rich,

I'll respond to the content of your message separately, but would
like to make the request here that for future messages you send
them out with a conventional 72 character per line format instead
of the 80 or whatever you use.  All of the messages I get from
PARC have to be extracted and reformatted before I can read them
on my local line printer.

-- Bill

------------------------------------------------------------

*start*
00349 00024 US 
Date: 16 July 1981 10:51 am PDT (Thursday)
From: Schroeder.PA
Subject: Bug in Laurel
To: Levin, Brotz

If the name in a "From" field is longer than 50 characters, then MailStampFormat
gets a StringBoundsFault when parsing the header.  The reason is that the parser
returns a recipient string longer than maxRecipientLength.

*start*
00478 00024 US 
Date: 16 JUL 1981 2246-PDT
From: RAMSHAW.PA
Subject: better idea for shift-backspace
To:   Brotz
cc:   Ramshaw

Doug, on second thought, how about this:  if the first key 
depressed after the shift key goes down is backspace, then delete
the character after the caret.  But if any other key goes down
in between, then assume that the user is typing in upper case, and
make a backspace act normally instead, deleting the character
before the caret?

Lyle
*start*
01734 00024 US 
Date: 20 July 1981 3:33 pm PDT (Monday)
From: Brotz.PA
Subject: Laurel HyType form
To: Burroughs.wbst, Baker.wbst
cc: Brotz

If you place the following text in your Laurel profile, then a HyType form
similar to the Xerox standard Internal Memo form (without the Xerox logo) can be
used for hardcopy.  Read on for further details.

Font: 9 HyType 11
HardcopyForm: HyType 24730 2540 2500 20000 0 T
 (Options
  (Caption 2500 25670 9 T "Laurel HyType Message")
  (Heading 2500 25670 9 F Subject 15875)
  (PageNumber 18415 25670 9 F)
 )
 (Rows
  (0 0 106 (Field 2500 11000 9 9 T T 2500 To "" T F T F)
    (Field 11500 20000 9 9 T T 11500 From "" T F T F) )
  (420 22220 106 (Field 2500 11000 9 9 T T 2500 Subject "" T F T F)
    (Field 11500 20000 9 9 T T 11500 Date "" T F T F) )
  (0 0 0 (Field 2500 20000 9 9 F T 2500 PrintForm "" F T T T) )
  (420 0 106 (OtherFields 2500 20000 9 9 T T 2500 420) )
  (1000 0 106 (Field 2500 20000 9 9 T T 2500 In-Reply-To "" F F T F) )
  (2000 0 106 (Body 2500 20000 9) )
  (420 0 106 (Field 2500 20000 9 9 F T 3300 c cc F F T T) )
 )

To print on the HyType, the Printer option in the hardcopy submenu (that's the
Printer, not the Form), must be set to the word Local.  When the Printer is Local,
if the Form brackets are empty, then the HyType hardcopy form is used, if the
Form brackets are non-empty, then the specified form is used.  This means just
set the Printer to Local, and the rest is defaulted.

HyType 11 refers to the RomanPS print wheel.  If you will be printing with a
different type wheel, set Font: 9 ...  accordingly (with either HyType 10 for
Elite, HyType 12 for Pica.)

To modify this form, use the rules given in the Laurel Manual, Appendix C.

-- Doug

*start*
00267 00024 US 
Date: 20 July 1981 5:07 pm PDT (Monday)
From: Barth.PA
Subject: Laurel feature
To: Brotz

When one starts editing a message after running Cholla the Laurel deliver
command gets painted onto the screen, overwriting the Cholla deliver command.

*start*
00682 00024 US 
Date: 5 Aug. 1981 11:20 am PDT (Wednesday)
From: Gifford.PA
Subject: Mode in Modeless Laurel
To: Brotz

Doug,

I was suprised to find that there was a mode in Laurel that confused me.  I
clicked "Hardcopy", and then changed the printer I wanted to print on.  Then I
decided not to hardcopy after all.  None of the other buttons on the screen would
respond until I aborted the Hardcopy.  Why can't "Cancel" be eliminiated?

On another topic, my little finger sometimes hits the button to the right of "BS". 
I almost passed out the first time I saw my 2000 character messsage disappear
when I only wanted to delete a single character.

A faithful fan,

Dave

*start*
01481 00024 US 
Date: 6 Aug. 1981 7:22 am PDT (Thursday)
From: RONFREEMAN.ES
Subject: Error Report(Last sentence corrected)
To: LaurelSupport.PA

I wanted to save part of a news item I had received over the net into a file I
have on taxes.  I "Moved" the entire message to a file I named junk.mail.  I then 
did a "Get" to put it into my lower window so I could delete all the extraneous
junk.  Then I did a "Put" and overwrote the existing junk.mail file.  I then tried
to call junk.mail in as a mail file so I could move it to my "Taxes" file.  It said it
couldn't retrieve it do to a header format error or some such thing. (I had deleted
the original header in my zeal to get rid of extraneous stuff)  I got it back into
my lower window and inserted a header including "Subject", "To", and "From"
information and again put it out as junk.mail.  Laurel didn't like it yet so I tried
to "Deliver" it to myself.  Said something about a syntax error in header but it
looked like all other headers to me.  So---I tried to "Forward" it to myself and
thats when it blew up!

Laurel 6  Alto II (055#204#) with Ram only MDS: 00 Banks: 100000 code: 000051

Signal 047201 in IntExceptions
msg 000001, msg^                            

BackStop, 003550
Signaller, 000521
IntExceptions, 000215
VirtTOC, 001101
VirtTOC, 001142
VirtTOC, 000457
IntEditCom, 000104
IntTrackMain, 001747
IntTrackMain, 001250
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000122
DebugNub, 000334

*start*
00405 00024 US 
Date: 10 Aug. 1981 2:51 pm PDT (Monday)
From: Ayers.PA
Subject: Laurel Deficiency
To: LaurelSupport

I tried to use Laurel to obtain the file
[Rain]<Nikora>ExternalSpecification>Fragment>UnifiedInterpress.bravo that Nikora
pointed me to.  Alas the "file name" field in the Laurel bottom window appears to
only accept strings that are eight characters shorter than that file name.

*start*
00753 00024 US 
Date: 10 Aug. 1981 5:56 pm PDT (Monday)
From: Brotz.PA
Subject: Laurel 6.1T5
To: Cholla^
cc: LaurelImp^, Brotz
Reply-To: Brotz

Laurel 6.1T5 is now on [Cherry]<Cholla>Laurel>Laurel.image  (no .run file.)

This is not for Alto I's (nor for the faint of heart).  No CR's on delivery, fast thumbing, much more wonderfulness.  .laurel programs that have become incompatible are now stored on [Cherry]<Cholla>Laurel>.

To set yourself up to send with CR's, put

DeliverWithCRs: TRUE

in your Laurel profile.  (Default: FALSE)

Rick: CreateCommandHouses is now exported through lmD (LaurelMenuDefs).  It takes two new arguments, allocateNode and AllocateString.  You should pass in Storage.Node and Storage.String for these.

-- Doug

*start*
00924 00024 US 
Date: 12 Aug. 1981 10:31 am PDT (Wednesday)
From: Swinehart.PA
Subject: Re: Flakey Laurel composition window suggestion
In-reply-to: Birrell's message of 11 Aug. 1981 1:46 pm PDT (Tuesday)
To: LaurelSupport
cc: Swinehart

(Just to close the loop, and only because it's been said that large piles of random
ideas fuel the flame of evolutionary creativity . . .)

I've tried NewFormAfterDeliverY: TRUE, and will probably leave it enabled, but
I've also fumblefingered my way into some undesirable states already (where I
managed to type something into the new form, eliminating the ability to use
CANCEL to get back.  Momentum, or inertia, or something.

Preferred algorithm: when Delivered=>Deliver after an edit, make it Redeliver
instead.  Same semantics as Deliver.  When <New form>, Answer, Forward are
performend, change it to Deliver.  And Laurel used to be such a clean,
uncluttered program!


*start*
00848 00024 US 
Date: 12 Aug. 1981 4:40 pm PDT (Wednesday)
From: Woods.PA
Subject: Bug in Files.laurel
To: LaurelSupport

A strange but minor bug has surfaced in Files.laurel under Laurel 6.  The
sequence of relevant events was:

(1) I used the "Move to" command to move a bunch of messages into a file called
"Go.moves115-139".

(2) I used "Run" to invoke "Files".

(3) I told Files to "ren Go.moves115-139 Go.moves115-142".

(4) I exited from Laurel and typed "filestat go.mo<esc>" to see how big the file
was.  The Alto exec completed the name as "go.moves115-142", as expected.

(5) The Filestat command claimed that the file name was "Go.moves115-139"!

Apparently the Rename command in Files.laurel doesn't change all the places
that the filename appears.  I don't know what programs, if any, might get
screwed up by this.

	-- Don.

*start*
00474 00024 US 
Date: 12 Aug. 1981 4:53 pm PDT (Wednesday)
From: Birrell.pa
Subject: Re: Bug in Files.laurel
In-reply-to: Woods' message of 12 Aug. 1981 4:40 pm PDT (Wednesday)
To: Woods
cc: LaurelSupport

Sounds like files.laurel does rename purely by changing the alto file directory. 
Filestat in the executive gives you the name from the leader page, which in
principle is the truth (and which the scavenger is at liberty to put back in the
directory).

Andrew

*start*
00193 00024 US 
Date: 14 Aug. 1981 12:04 pm PDT (Friday)
From: OLMSTEAD.PA
Subject: Dashes
To: LaurelSupport

Laurel's selection scheme thinks <word><control-x><word> is a single word.
*start*
00424 00024 US 
Date: 17 Aug. 1981 8:35 am PDT (Monday)
From: Schwartz.PA
Subject: SearchMail:  can't abort long search
To: LaurelSupport
cc: Schwartz

SearchMail does not respond to CTRL-DEL (or to any other abort request, as far
as I can determine).  Since searches take a long time, it would be VERY nice if I
could search until I find the message I want, then abort the remainder of the
search.

Thanx,  Victor

*start*
02076 00024 US 
Date: 19 Aug. 1981 12:00 pm PDT (Wednesday)
From: Brotz.PA
Subject: Ancient Laurel quarantine
To: IfsAdministrators^
cc: LaurelSupport
Reply-To: LaurelSupport

As one of the members of LaurelSupport, I have noticed that there are several
instances of old Laurel 5.1's cropping up around the Internet.

Typically, I discover this when a new user completes the Laurel training session
and sends in the last message.  The training files are different for Laurel 5.1 and
Laurel 6, and their last messages (the ones that say "Add me to LaurelUsers ... ")
are different.

The current training file is named Tutorial.mail.  The obsolete one was named
Help.mail.  The Help.mail's are cropping up from a variety of sources including:

1.  The <Laurel> directories on your IFS's.  There should be a Tutorial.mail, not
    a Help.mail on these directories.
2.  From Basic Disks (Basic Non-Programmer's Disk, etc.), including those stored
    on IFS's and those kept as standard initial disks in many locations.
3.  From "helpful" users' disks.  These helpers initiate a new user to Laurel with
    a "You probably would like this Help.mail file from my disk that I've been
    saving for years."

When Laurel 6 was released, the Laurel group took great pains to store the
Laurel files on each IFS consistently.  We did not update any Basic Disks at that
time, since they are controlled by individual administrators.  Since then, entropy
has been working its nefarious deeds.

Please examine any directories under your control to insure that Laurel 6, not
Laurel 5.1 is there.  The creation date for both Laurel.run and Laurel.image
should be 6-May-81.  Also make sure that Tutorial.mail is there, not Help.mail. 
Please do the same for any Basic Disks under your control.  I know for sure that
some ancient versions are on Phylum, in Henrietta, and in Webster.  There may
be others.  There is not much we can do about number 3. above, but they are
not the major source of the infestation.

Thank you for your help.

Yours in the battle against entropy,

-- Doug

*start*
01205 00024 US 
Date: 19 Aug. 1981 4:49 pm PDT (Wednesday)
From: McNown.PA
Subject: Error Report
To: LaurelSupport.PA

Hi, Guys (and perhaps Gals)...  I had called up Laurel and typed a 3 to get the
new message window.  I had created a two paragraph message to Mau with
copies to Miller.es and myself.  I had bugged deliver when i noticed that i had
no "er" on Miller.  I hit delete.  The "S" in subject was underscored.  I could not
accomplish an insert ahead of the ".es".  I thought that i was not in the basic
mode so hit an exc to free the underscore.  I got the Butterfly looking PS and the
message to bug yellow.  It gives you a warm feeling to know that there is a
group that cares about the malfunctions.  This is a great place to work.  


bob




Laurel 6  Alto II XM (060#045#) with 2K Rom XMcode using XM MDS: 00
Banks: 160000 code: 000051

Signal 047201 in IntExceptions
msg 000001, msg^                            

BackStop, 003550
Signaller, 000521
IntExceptions, 000215
VirtCM, 000751
VirtCM, 000560
EditorMain, 003514
EditorUndo, 000656
EditorMain, 000722
IntTrackMain, 000615
IntTrackEdit, 000310
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000122
DebugNub, 000334

*start*
04422 00024 US 
Date: 20 Aug. 1981 3:39 pm PDT (Thursday)
Sender: Brotz.pa
Subject: Alpha Test of Print.laurel
From: K. Pier & D. Brotz
To: LaurelUsers^
cc: LaurelSupport
Reply-To: Pier, LaurelSupport

Have you ever wanted to print a remote bravo or text file in two-up landscape
mode?  Do you like living dangerously?  If so, read on.

Ken Pier has modified the famous Murray-Johnsson-Ayers Print.bcd program so
that it can run in Laurel 6.  Some modifications were absolutely necessary, such
as making Print accept its commands via typein rather than from the command
line.  Others were highly desirable, such as making Print think that it didn't
own the entire machine.  We believe that most of the bugs are gone, however, it
only takes one ...

[Ivy]<Laurel>Print.laurel is the program.  If this initial release works smoothly,
we will store Print.laurel on other file servers as well.  Send your comments to
LaurelSupport.pa and/or Pier.pa.

Caution: Print.laurel will not print the current mail file.  To print that file,
invoke Mail file on some other mail file first.  If your machine has only one
bank of memory, good luck.  The rest of this message is taken from Ken Pier's
description of the program.

CAVEATS

Print is old and dirty code. I don't intend to improve or rework it any more.
Doug Brotz and I will entertain bug and feature reports, but no guarantees are expressed or implied.

If you print more than 127 printed pages, Print will barf. Also, under some
circumstances, having run Print you will not be able to run any more programs
without restarting Laurel. This is the motivation for the /~m feature, see below,
which reduces the likelihood of restarting.

Ken

----------------------------------------------------------------------------

[IVY]<Pier>LaurelPrint.doc				11 Aug. 1981

Print is a program to generate Press format files
and send them to your local printer.  It is handy for generating
code listings since it will print files in 2 column landscape mode.
[IVY]<Pier>Print.laurel is a version of this program that will run
in the Laurel composition window.


Command format:

Activate Print with the Laurel Run button. Type a command line terminated
by ESC. "<filename1> <filename2> <filename3>"  just prints the specified
files on the printer specified in the HARDCOPY section of your User.cm.
Multiple files are batched to be sent to the printer as long as the fonts
are the same.  If a file is already in Press format it will be sent directly
to the printer. Typing DEL and being patient will abort in midstream.

A <filename> may be a complete remote file name, in which case the file will be FTP'ed to your local disk (onto the file PRINT.TEMP$) and printed from there.  This local temporary file will be deleted after printing.

"Print /b ..."  Shifts to Bravo mode.  (There is no way to get out
of it.)  This processes only a subset of Bravo formatting (tabs, fonts and faces).
It uses the fonts specified in the BRAVO section of your User.cm.


Switches:

/a		Print headers on each page (default true; -a disables).

/z		Print trailers on each page (default true; -z disables).

<host>/h	Directs the output to <host>.

<output>/o	Creates a press file in <output> (defaulting .press).
		Disables transmission to printer.

<font>/f	Changes the font to <font> for the following files.  The
		default is Gacha8 in portrait; Gacha6 in landscape.

/c<n>		Sets number of copies to <n> (default 1).

/t<n>		Changes the tab stops to <n> spaces (default 8).

/l<n>		Landscape mode.  <n> is the number of columns (default 2).

/p<n>		Portrait mode.  <n> is the number of columns (default 1).

/s<n>		Number of sides.  <n> IN[0..2]; 0=> use printer default.

/m  		Messages. /-m or /~m turns off "progress" messages in the
                Laurel window. This is useful when large numbers of files
                are being Pressed.

The switches that don't need a string as an argument will also work in
local mode.  Local switches appearing after the argument is "used up"
are global.  Defaults are:  Gacha6/fl2s2c1azt8m

Examples:
	 Foo
	 Foo/l
	 /l Foo1 Foo2
	 /c3 Foo1 Foo2/l3 TimesRoman10BI/f Foo3/l
	 Foo1/p2 Foo2/b
         /-m Foo1 Foo2 Foo3 Foo4 Foo5 Foo6 Foo7 /m Foo8


Richard Johnsson wrote the front end, Bob Ayers wrote the Bravo formatter
and Hal Murray wrote the Presser. Ken Pier modified the program for the
Laurel environment.

KAP, 11 Aug. 1981 12:39 pm PDT 


*start*
00425 00024 US 
Date: 24 Aug. 1981 10:30 am PDT (Monday)
From: Brotz.PA
Subject: Laurel 6 release to customers
To: Redell
cc: Brotz

Rank Xerox is planning to release Laurel 6 to Swedish companies, ASEA and Volvo, in the near future.  I just heard of it last week.  Rank Xerox has requested the sources of the Laurel manual for translation into Swedish.

Do you foresee any problems with this?  Let's talk.

-- Doug

*start*
00684 00024 US 
Date: 24 Aug. 1981 12:00 pm PDT (Monday)
From: Redell.PA
Subject: Re: Laurel 6 release to customers
In-reply-to: Your message of 24 Aug. 1981 10:30 am PDT (Monday)
To: Brotz
cc: Redell

I talked with Liddle, and he agreed with our conclusion that it would be best to
avoid any references to Grapevine in the Swedish version of the Laurel
Manual.  He also said that he is trying very hard not give things like Laurel 6
to the US probe sites (e.g. Boeing), since we want to start weaning them from the
Alto world ASAP.  The corresponding decision in Sweden is really under RX's
control, and Liddle wasn't aware of their decision to send the Swedes Laurel 6.   

*start*
01094 00024 US 
Date: 27 Aug. 1981 12:12 pm PDT (Thursday)
From: MeansDD.ES
Subject: Laurel profile
To: LaurelSupport.PA
cc: EDSupport.ES, MeansDD

I am trying to put up a new profile.  When the following is my profile,
everything seems to be ok.

Registry: ES
Printer: THUD
PrintedBy: MEANS, Duff - x35436
RunPath: [Isis]<Laurel>
Background: black
Boundary: 0,12,19,16
Boundary: 1,1,0,0
Boundary: 2,0,1,0
Boundary: 3,0,0,1
Boundary: 4,1,1,0
Boundary: 5,0,1,1
Boundary: 6,1,0,1
Boundary: 7,12,19,16
Boundary: 8,12,19,16
Boundary: 9,12,19,16
Font: 0 TimesRoman 10
Font: 1 TimesRoman 8
Font: 2 TimesRoman 12 B
Font: 3 Logo 24

However, when I add the following section to my profile, Laurel trys to install
and then the cursor says "oops", and Laurel seems to just hang in limbo.

Font: 4 Math 10
Font: 5 Hippo 10
Font: 6 Helvetica 10
Font: 7 Helvetica 14
Font: 8 Helvetica 18
Font: 9 HelveticaD 24

Can you please tell me what I am doing wrong, and what restrictions there are
on fonts in Laurel.  I may at a later time wish to change some of these fonts
again.

Duff Means
8*823-5436


*start*
03222 00024 US 
Date: 28 Aug. 1981 3:37 pm PDT (Friday)
From: Brotz.PA
Subject: Re: Laurel 6 documentation
In-reply-to: Lundh's message of 21 Aug. 1981 4:06 pm (Friday)
To: Lundh
cc: Brotz, LaurelSupport, Bremander.WBST, Schroeder

The sources for the Laurel manual are available on Juniper.  You will need to log in as Guest, password guest to obtain them.

The Laurel Manual has many references to facilities available only to users in the Xerox Research Internet.  These include all references to Grapevine, to the Arpanet, to Maxc, to LaurelSupport.pa, and all mentions of Xerox internal registries.  I strongly suggest that you remove these parts of the manual when you translate it into Swedish, as they will at best be confusing to your customers, and they may press you for installation of those features.

These references are most prevalent in sections 2, 3.1.1, 3.7.2, 3.7.3, 3.7.6, 5.2, 6, 7, 8, 9, Appendix B.2, Appendix D, and Appendix E.  Please be careful to reword or eliminate those parts of the manual that reference Maxc, Msg, LaurelSupport.pa, Tools environment, etc.

That said, the files are on [Juniper]<DMS>Laurel>6>Manual>

including
  <DMS>Laurel>6>Manual>Laurel6-title.bravo
  <DMS>Laurel>6>Manual>Laurel6-toc.bravo
  <DMS>Laurel>6>Manual>LaurelScreen.press
  <DMS>Laurel>6>Manual>Laurel6-1.bravo
  <DMS>Laurel>6>Manual>Laurel6-2.bravo
  <DMS>Laurel>6>Manual>Laurel6-3.bravo
  <DMS>Laurel>6>Manual>Laurel6-4a.bravo
  <DMS>Laurel>6>Manual>Laurel6-4b.bravo
  <DMS>Laurel>6>Manual>Laurel6-5.bravo
  <DMS>Laurel>6>Manual>Laurel6-6.bravo
  <DMS>Laurel>6>Manual>Laurel6-7.bravo
  <DMS>Laurel>6>Manual>Laurel6-8.bravo
  <DMS>Laurel>6>Manual>Laurel6-9.bravo
  <DMS>Laurel>6>Manual>Laurel6-a.bravo
  <DMS>Laurel>6>Manual>laurel6-b.bravo
  <DMS>Laurel>6>Manual>Laurel6-c.bravo
  <DMS>Laurel>6>Manual>Laurel6-d.bravo
  <DMS>Laurel>6>Manual>Laurel6-e.bravo
  <DMS>Laurel>6>Manual>EditSummary.sil

The above list shows the order in which these files should be put together to reconstruct the manual.  All .bravo files are in Bravo 7 format, the .sil file is the SIL input file for the editor summary at the end of the manual, and the .press file is the picture of the Laurel screen.  The Laurel6-n.bravo refers to chapter or Appendix n, where chapter 4 had to be split into two halves due to its large size.  Laurel6-toc.bravo is the table of contents, which you will certainly have to modify to reflect your new manual.

The .bravo files have been tuned with Look Keep's and Page Breaks to obtain the final layout.  Each chapter begins on a right-hand page, and the preceding chapter may have been padded out with a blank page to insure this,  When you edit the files, these fine tunings will get in your way.

There are corresponding .press files for each of the source files listed above.

These files represent the final version of the Laurel Manual that is currently in the pipeline for publication as a PARC/CSL Blue&White report, not the version that was widely distributed throught Xerox last May.  This version has been cleared for international release.  You should check on any rules governing the publication of your translated version.

If you have any questions, please ask.

-- Doug

*start*
00557 00024 US 
Date: 28 Aug. 1981 4:22 pm PDT (Friday)
From: Kierr.pa
Subject: Suggestion re bogus dl's
To: LaurelSupport
cc: BogusDL^

If I try to send a message to a bogus dl, Laurel currently requires me to type
<esc>.  (Laurel says "1 invalid name(BogusDL^).")  It seems that fairly often
people type <esc> without realizing what will (not) happen and their message
goes nowhere.  (Maybe they think that some name within the dl is bad?)  I
think it would be better for Laurel to refuse to deliver a message with a bogus dl
addressed.  /Robert

*start*
00954 00024 US 
Date: 31 AUG 1981 0924-PDT
From: SHOCH.PA
Subject: Re: Laurel 6 in Sweden
To:   Brotz
cc:   SHOCH

In response to your message sent  26 Aug. 1981 11:00 am PDT (Wednesday)


Doug,

Thanks for your recent note about Laurel's use in Europe.

On the one hand, I am delighted that RX is using the Alto
and Laurel within their operations in Europe -- in the UK
and Sweden.  I already get messages from an occasional soul
in Europe, and providing them with new versions of Laurel is
in our interest.

On the other hand, I don't know what to make of the lingering
ASD probes in Sweden -- that's a problem to be worked out by
OPD and RX.  OPD surely wants to wind them down, and RX feels
obliged to provide support.....  I view RX as the marketing
unit, and we try to meet their needs;  but it surely requires
some joint planning.....

Nothing profound in all this -- sorry I can't shed any
particularly bright light.

Best regards,

john
*start*
00472 00024 US 
Date: 1 Sept. 1981 1:41 pm PDT (Tuesday)
From: chance.ES
Subject: Re: Add to @LaurelUsers
In-reply-to: Brotz.PA's message of 1 Sept. 1981 10:19 am PDT (Tuesday)
To: Brotz.PA
cc: chance, LaurelSupport.PA


Doug,

I got this laurel from Mae Thomas' master laurel disk, which she gives to new
people. So, if you can have her update her master disk, it will more than likely
stop any more laurel.help disks from being created down here in El Segundo.

*start*
00549 00024 US 
Date: 2 Sept. 1981 10:55 am (Wednesday)
From: Lundh.PA
Subject: Re: Laurel 6 documentation
In-reply-to: Brotz.PA's message of 28 Aug. 1981 3:37 pm PDT (Friday)
To: Brotz.PA
cc: Lundh.PA, LaurelSupport.PA, Bremander.WBST, Schroeder.PA

Thank you very much!

Got all files yesterday, converted them to BravoX and printed them. Everything
went beautiful!

I agree with you -- all references to Grapevine, to the Arpanet, to Maxc, to
LaurelSupport.pa, and all mentions of Xerox internal registries -- are be
removed. 

Birgitta

*start*
00785 00024 US 
Date: 8 Sept. 1981 1:32 pm PDT (Tuesday)
From: Thompson.PA
Subject: Laurel Bug?, Feature?
To: Brotz.PA
cc: Thompson

Doug,

I was strolling through my mail today (just now) in a mode that I don't usually
use. i.e. SWAT2, all window 2. I have DISPLAY AFTER DELETE: TRUE in my
user profile. When I got to the end and hit delete for what I later found out was
the last message nothing happened.

It strike me that I should have gotten the same feedback message that I would
have gotten if I had hit the DISPLAY button or something equivalent. I.e. NO
FURTHER undeleted MESSAGES.

Doesn't this seem like it would be more consistent to you. Do you care? Will you
change it in Laurel 12.92? Will you ever share an office and a cigarette with
Sharon Johnson?

Geoff


*start*
00380 00024 US 
Date: 8 Sept. 1981 4:21 pm PDT (Tuesday)
From: Taft.PA
Subject: Press file from Laurel
To: LaurelSupport

Is there any way to get the Press file generated by Laurel Hardcopy put into a
file on my local disk?

(I can think of only one: direct the hardcopy to some other machine, and run
EFTP on that machine to catch the Press file that Laurel sends.)
	Ed

*start*
00489 00024 US 
Date: 11 Sept. 1981 2:20 pm PDT (Friday)
From: BURTON.PA
Subject: Re: delivery confirmation question
In-reply-to: Brotz's message of 11 Sept. 1981 1:00 pm PDT (Friday)
To: Brotz
cc: laurelsupport

In that case I would vote for a method (possibly in my profile) of specifying
certain distribution lists that override the reply-to request.  Typing the 20 extra
characters necessary to get a private list is unreasonable particularly for small,
frequently used dl's.

*start*
10429 00024 US 
Date: 11 Sep 1981 20:41 PDT
From: Verplank at PARC-MAXC
Subject: Electronic Mail Study
To: Brown, AHenderson, Moran, Braun.es, Kingston.dlos, Cooper.es, Brotz,
 Henderson.es, SASmith, Irby, Card, DaveSmith, Dunlop.es, Bewley.es, Bott,
 Roberts, Redell, Kimball, Farrell 
cc: Verplank, Henderson.ES, CSteinfield@USC-ECL
Reply-To: Verplank, Henderson.ES, CSteinfield@USC-ECL

Here's a proposal from a PhD candidate at USC's Annenberg School of
Communication.  If you have any suggestions or recommendations, pro or con,
let me or Chuck Henderson hear them.  We are suggesting that
OPD/OSBU/Planning (i.e. Dudley Braun) sponsor the study.  In addition, we
would need the consent of Liddle and probably Pake.  Any suggestions on study
guidelines and approval procedures would be welcome. 

Steve Smith and Paul Ricci have been gathering usage data that could be used in
this study.

Anyone else interested in participating?  Being interviewed?  Offering
hypotheses?

--Bill V
---------------------------

Date: 11 Sept. 1981 5:41 pm PDT (Friday)
From: Henderson.ES
Subject: Chip's Mini-proposal
To: Verplank.pa

Here's Chip's pitch to Dudley who is the one that has to be convinced if OPD
planning is going to provide sponsorship.  Have you lined up any other
alternatives?

---------------------------

Mail-from: Arpanet host USC-ECL rcvd at 11-SEP-81 1448-PDT
Date: 11 Sep 1981 1437-PDT
From: CSTEINFIELD at USC-ECL
Subject: Mini-proposal
To:   Braun.es at PARC-MAXC
cc:   Henderson.es at PARC-MAXC, Csteinfield, Dutton


PRELIMINARY PROPOSAL TO STUDY USE OF ELECTRONIC MAIL AT XEROX


Introduction

     Designers and engineers of new communication and information
technology are continually developing systems that alter the
way in which we go about our work.  Unfortunately there has been
little systematic study of the use and impacts of these developments.
Design and implementation are often more driven by the
characteristics of new technology than the needs of users.
At Xerox, the opportunity exists to carefully examine the use
and impacts of one such new office technology: electronic mail.
A brief summary of such a study's focus and methods is provided
below.


Focus of Study

     The Laurel messaging system was introduced at Xerox several
years ago.  Since then much anecdotal evidence has been gathered
about its use.  One study, conducted by Chuck Henderson, clearly
illustrates the potential of electronic mail to create wide ranging
social and behavioral impacts in the office.  What is now needed
is a more quantitative approach, which not only uncovers areas where
impacts might lie, but also can highlight the direction and
magnitude of these impacts.  In particular, the study should provide
information in three major areas:

    1.  USES.  How the system is used must be carefully analyzed.
        Frequency of use, facilities that are used or not used, who is
        communicating with whom, what tasks are accomplished, in
        what situations is the system used, etc. are all types of
        information that will highlight potential impacts.

    2.  IMPACTS.  Certain patterns of use will lead to different
        kinds of impacts.  These should included both perceived
        impacts of the system as well as externally observed impacts.
        Perceived impacts include:  User judgements of impacts
        on work efficiency and effectiveness, job satisfaction,
        perceived changes in communication behaviors, etc.
        Unobtrusive measures of actual impacts may include changes
        in the communication patterns; i.e. who communicates with
        whom, the frequency of interaction, the number of different
        contacts, turnover and absenteeism, mobility in the 
        company in terms of promotions, etc.

    3.  FACTORS PREDICTING USES AND THEIR IMPACTS.  In particular,
        demographic characteristics of users, user attitudes and
        expectations, characteristics of their jobs/tasks, as well
        as department and organization variables all may play
        a part in explaining/predicting uses and impacts.

     By examining the relationships between these sets of variables
it is possible to gain an understanding of the impacts of 
electronic mail that might vary considerably from the images
gleaned from the anecdotal evidence.  Statistical analysis can help
uncover relationships which are not intuitively obvious.
     There are potentially hundreds of impacts of electronic mail
use.  This study will focus on those impacts which appear to have
relevance to the question of productivity, directly or indirectly.


Benefits of the Proposed Study to Xerox

     The proposed research will benefit Xerox in two critical areas:
design and implementation.  These are briefly addressed below.

     Design
  
     Designers are continuously working to improve the utility of 
the Laurel messaging system.   Armed with such data as features 
which work or don't work, types of uses to which the system is
put, and uses which are associated with negative consequences,
these designers will be better able to provide a system which 
more closely meets the needs of end users.

     Implementation

     Little is known about the most appropriate strategies for
introducing electronic mail systems.  Relating user, usage, and
impact data can assist in the development of effective implementation
strategies.  For example, users with certain job characteristics
might have unique needs for a messaging system, and thus require
an orientation which is tailored to these needs.  In addition,
it may be the case that behaviors thought to be inappropriate
(i.e. game playing, use for personal correspondence) actually
have positive consequences for individual users and the organization
as a whole.  Knowledge of these instances would be invaluable
in the development of successful implementation strategies.


General Research Methodology

     The proposed study would follow a sequence of phases common
to field research endeavors.  By field research it is meant
that actual behaviors in a field setting form the core of data
upon which the study is based.  The phases include: 

    1.  IN-DEPTH INTERVIEWS.  Interviews with system designers
        and users would be used to obtain very textured information
        about both system use and organizational "culture".  This
        information would then be used to development more 
        quantitative instruments which are both meaningful and 
        relevant to potential respondents.  These interviews can
        also provide information regarding the availability of 
        existing sources of relevant data, including company
        records, prior studies, system logs, etc.

    2.  RESEARCH DESIGN.  After interviews are conducted, a detailed
        research design can be developed.  Specifically, sampling
        strategies, data collection methods, and data analysis
        strategies can be planned.  Data collection and analysis
        are briefly addressed below.  The sampling plan will be
        devised with study objectives in mind.  Ideally a 
        representative sample of users and non-users would be
        included in the study.  The inclusion of a control group
        of non-users would permit much stronger statements about
        the impacts of electronic mail by allowing many alternative
        rival hypotheses to be ruled out.

    3.  DATA COLLECTION.  While methods of data collection cannot
        be specified until existing sources of data are carefully
        evaluated, a general strategy can be outlined.  A
        multi-operational approach to data collection will be
        used.  That is, each single method of collecting data 
        suffers from unique strengths as well as weaknesses.
        By incorporating several methods, strengths can be
        capitalized upon while protecting against weaknesses.
        Among methods likely to be employed are questionnaires
        for obtaining user attitudes and perceptions, system logs
        for obtaining usage data, and company records for obtaining
        other user information.  In all cases, privacy and
        confidentiality of respondents will be guarded.  Respondents
        will be assured that responses will not be released,
        except in statistical summary.  In addition, wherever 
        possible, the burden of effort on respondents will be
        minimized.  A final guideline for data collection is that
        whenever possible, the system itself will be used as a
        medium for gathering information.

    4.  DATA ANALYSIS.  Multivariate statisical procedures will
        be used to test hypotheses.

      Prior to each phase in the study, project advisors at Xerox
would be consulted.  In addition, instruments for data collection 
would be carefully pretested.


Products

     A report will be presented to Xerox study advisors that
describes in full detail the study's findings and methodology.
All technical data regarding system facilities and hardware will
be treated as proprietary, and the organization will not be
identified by name in any reports.  I would obtain company
approval before publishing any results, with the exception of
my dissertation.  This document will also treat system facilities
and hardware information as proprietary and will not identify
the organization by name.


Costs, Time Frame, and Next Steps

     In return for the conduct of the proposed research, I ask
only for coverage of the research expenses.  This would include
materials and supplies, system use, travel expenses if needed,
etc.  No salary would be necessary.  My motivation for carrying
out this research is to complete the requirements for my
doctoral dissertation at the Annenberg School of Communications.
I believe that the proposed project would satisfy academic
requirements, be intellectually stimulating, and be useful for
your organization.  Furthermore, it would give me the opportunity
to conduct research in an area which I find fascinating and 
drastically in need of empirical study.
     The time frame for the proposed research is constrained only
by my desire to finish my doctoral studies by June of 1982.
In order to meet this deadline, work on a more detailed
proposal should commence as soon as possible.
.
.
.

Chip Steinfield
------------------------------------------------------------
*start*
00404 00024 US 
Date: 16 Sept. 1981 8:53 am EDT (Wednesday)
From: TELLEX.Henr
Subject: Re: Add to @LaurelUsers
In-reply-to: Brotz.PA's message of 15 Sept. 1981 9:42 am PDT (Tuesday)
To: Brotz.PA
cc: TELLEX, LaurelSupport.PA

My disk was created by Gerry VerSchage. I just transferred into this
group and am new to the Alto world. I appreciate any help and am sorry
for any inconvenience.

Greg.

*start*
00582 00024 US 
Date: 16 Sept. 1981 11:44 am PDT (Wednesday)
From: Kolling.PA
Subject: disk full
To: laurelsupport
cc: kolling

It would be nice if when laurel says "disk full", it would abort the command
rather than demanding that the entire session be ended by "clicking red and
blue".  It may be possible for the user to recover from disk full by deleting stuff
from the mail file.  Presently the message or file that was being saved when the
disk full occurs is lost forever...  I'd be happy to live with losing the undo
command at that point, if that's the problem...

*start*
00300 00024 US 
Date: 17 Sept. 1981 10:55 am EDT (Thursday)
From: CONLEY.Henr
Subject: Re: Add to @LaurelUsers
In-reply-to: Brotz.PA's message of 4 Sept. 1981 1:26 pm PDT (Friday)
To: Brotz.PA
cc: CONLEY, LaurelSupport.PA

I obtained the file Help.mail from LaurelSupport.PA.

--John Conley

*start*
00359 00024 US 
Date: 22 Sept. 1981 3:51 pm PDT (Tuesday)
From: Pasco.PA
Subject: list *.mail
To: Brotz
cc: Pasco

Hmmm.  It seems if I hit ESC as the first character after starting Files.Laurel
(but not at any other time), it stuffs "list *.mail" into the command line.
A neat feature to discover; I couldn't find it in the Laurel Manual, though.  

*start*
02457 00024 US 
Date: 23 Sept. 1981 8:57 am PDT (Wednesday)
From: Ness.PA
Subject: A Naive User on Laurel
To: Brotz
cc: Morris, Ness

Doug-

I have been using (and enjoying) Laurel over the past week, and wanted to
send you my few observations.  Most of these are probably old hat to you but
since I don't know the "conventional wisdom" I thought I'd just forward them
anyway.

Browsing in Laurel-

1.	I seem to occasionally have difficulty getting Yellow recognized on the
	browse line... I think this is particularly true in the middle window.
	Perhaps the Yellow target area could be broadened a little.

2.	I would like to be able to place some marks that show up on the browse
	line.  For example, I find myself putting text, schedules, notes about
	publications etc. into the same document and it would be very nice if
	I could "jump" to the right spots a little easier than just taking a blind
	stab at the thing.

3.	By the way I would now agree that browsing the Laurel way is easier
	than in Bravo (at least for me).

ModeLess Editor

1.	I switched to the modeless editor in order to try it, and I think you are
	quite right about it.  Although I occasionally forget, on the whole it is
	easier to use, and I suspect that I have really only scratched the surface
	of the capabilities.

Enhancements

1.	It might be nice if some programs prepared their output in the "form" of a
	mail message for processing via Laurel.  A trivial example might be a
	program which prepared a nice report on your file status in the form of
	a memo rather than as FILES.LAUREL seems to do it.  On our mail system
	I get a lot of "automated" reports from status perusing programs this way
	I find it very comfortable.

2.	We implemented a moderately useful facility called "Response Mail". This
	logically looks a lot like me sending you a "form" for you to fill out and
	return to me.  Perhaps there is some way of doing this that I haven't run
	into yet.

3.	Notes formatted like this one (indented paragraphs, hanging numbers to
	the left) are not uncommon.  Some way of setting a left margin via a
	Ruler or the like would be nice in the Laurel Editor, although again it
 	may exist and I just don't know about it.

Error Situations

1.	I have encountered "Format error in mail file, get failed" after creating
	(an undoubtedly illegal) mail file by "hand".  If there is a scavenger that
	might have helped me, it would have been nice to have been told.

*start*
01495 00024 US 
Date: 28 Sept. 1981 1:58 pm PDT (Monday)
From: Fikes.PA
Subject: Re: Outside people on internal distribution lists
In-reply-to: Schroeder's message of 25 Sept. 1981 3:40 pm PDT (Friday)
To: Schroeder
cc: Brotz, Card, Birrell, Taft, Levin, Owners-CognitiveInterest^
Reply-To: Fikes

As the owner of CognitiveInterest^, I have encouraged the inclusion on that
distribution list of non-Xerox people in the Palo Alto area who are interested in
our Cognitive Science Discussion Group (CSDG) seminars.  That policy is
consistent with that of other AI groups in the area who run similar seminars
(e.g., Stanford's SIGLUNCH series), and I think it helps to foster communication
and cooperation among the groups.  An example of the type of situation I think
we should strive to avoid occured a few years ago when Ed Feigenbaum
expressed his anger to me about Stanford not receiving notices of a talk that Al
Newell had given at PARC.

I also understand there are situations in which distribution to non-Xerox folks is
inappropriate.  Therefore, I suggest that all non-Xerox people be removed from
CognitiveInterest^ and that a new dl be established, say called
CognitiveInterestAndFriends^, that is a superset of CognitiveInterest^ containing
both the internal and external folks.  (I will volunteer to help make those
changes.)  The new list would then be used for announcement of open CSDG's. 
And for other uses, people could use whichever list suits their needs.

richard   

*start*
00480 00024 US 
Date: 4 Nov. 1981 1:03 pm PST (Wednesday)
From: Ritchie.PA
Subject: Laurel Manual Suggestion
To: Brotz

Doug,

As I mentioned, the manual is exceptionally well done.  I found only
one nit; I annotated Figure 1 in the right margin indicating the upper menu,
middle menu, lower menu, the three thumb bars, and the TOC, message display,
and composition regions.  That could be done on Fig. 1 itself, and would have
saved me the uncertainty and trouble.

Bob

*start*
00264 00024 US 
Date: 6 Nov. 1981 9:04 am PST (Friday)
From: Schroeder.PA
Subject: Bug in Laurel
To: LaurelSupport.pa

Laurel should check the validity of the "Reply-To" name.  Perhaps this is an
application for the single packet validity check function.

*start*
00879 00024 US 
From: deutsch.pa
Date: 17-Nov-81 10:00:32 PST
Subject: Requests for improvements
To: LaurelSupport

I have found a few very minor ways in which Laurel falls short of
perfection and would like you to consider them for some future release.

1) Remote mail files!  I've been hearing promises for years, and I still
can't read my mail from any machine except the one in my office
(and have it work smoothly).

2) Background mail acquisition.  I would like to be able to read mail
as soon as it arrives, even if there is more mail to transfer.

3) Ability to take material from Maintain or Chat transcripts and do anything
useful with it.  When I select "New Form" it wipes out the lower window.

4) Ability to create a second viewing or composition window.

I still find Laurel one of the most wonderfully engineered systems
this place has ever built.

P. D.
*start*
00470 00024 US 
Date: 25 Nov. 1981 9:51 am PST (Wednesday)
From: Brotz.PA
Subject: Re: Laurel 6 documentation
In-reply-to: Lundh's message of 2 Sept. 1981 10:55 am (Wednesday)
To: Lundh
cc: Brotz, Bremander.WBST

How is your translation of the Laurel Manual?  You may have discovered that the English version is now released as a PARC/CSL Blue & White report.

If your version is available, I would appreciate a copy or a pointer to its press file(s).

-- Doug

*start*
00459 00024 US 
Date: 4 Dec. 1981 11:27 am PST (Friday)
From: Halbert.PA
Subject: wish list: display of all mail files
To: LaurelSupport

If you ever revamp Laurel substantially, consider this:
I now have so many mail files that stepping through them all by repeatedly
clicking "Mail file". It would be nice if an index, sort of like a message list,
could be displayed. (I could of course use Files.laurel, but I am talking about
convenience.)
--Dan

*start*
01246 00024 US 
Date: 27 March 1981 9:24 am PST (Friday)
From: Pettit.PA
Subject: Play on Dolphins
To: Woods
Reply-To: Pettit
cc: Sweet, Mallory, Brodie, Brotz, Frandeen, Neely, Artibee, McJones, Pettit

Thanks to the wizardry of Dick Sweet, there is now a version of Play which will
work on Dolphins.  The simple change Dick made is to replace the lines in
PlayNoteStandard of the form "out^ _ newState" with "SetState[newState]", where 

SetState: PROCEDURE [c: CARDINAL] = MACHINE CODE
	{ Mopcodes.zLIN1; Mopcodes.zXOR; Mopcodes.zMISC, 13B};

D0Play.mesa/bcd on [Iris]<Pettit> was edited from <Woods>Sources>Play.mesa.  All
edits are in bold.  I didn't bother trying to distinguish between Altos and
Dolphins, simply substituting the new SetState everywhere, so this version will
not work on Altos.  If you would make the same change, but only in the right
cases, to YOUR Play, we could have one standard Play which will work on both
Altos and Dolphins.

To hook up speakers to a Dolphin, one uses the 19 and 21 pins on the 37-pin
"Printer Port" on the Misc board. 

If anyone else has any programs based on Play but not importing it directly,
which you would like to run on Dolphins, you might want to make this change
too.

	Teri  

*start*
00269 00024 US 
Date: 7 Aug. 1981 4:59 pm PDT (Friday)
From: Linda.PA
Subject: Publication Clearance
To: Brotz,Anderson
cc:  Linda

The publication, "Laurel Manual" has been cleared and approved with the
appropriate signatures......it was filed today.


Linda

*start*
00305 00024 US 
Date: 25 Aug. 1981 6:12 pm PDT (Tuesday)
From: Taft.PA
Subject: DLS & Ernestine
To: Birrell
cc: Transport.ms, Taft

The DLS now has a "Grapevine" command which is equivalent to "Connect
Ernestine" but requiring just one keystroke.  (Sorry, the "E" command was
already taken.)
	Ed

*start*
00249 00024 US 
Date: 29 Sept. 1981 4:05 pm PDT (Tuesday)
From: Kolling.PA
Subject: searchmail
To: laurelsupport
cc: Kolling

Would you believe that if I feed searchmail a "malformed search string", it
searches the entire mail file anyway?

*start*
00914 00024 US 
Date: 6 Oct. 1981 5:20 pm PDT (Tuesday)
From: Woods.PA
Subject: Laurel Error Report
To: LaurelSupport

Last week I sent in a few messages about a Laurel bug I'd run into, and
included a pointer to the source of a private .bcd that was triggering the bug. 
Having found a way to get around the bug for a while, I intend to update the
.bcd accordingly, and so I'm mailing you the relevant portion to keep with the
bug report.

The bug is that if Laurel is used to write a file (via Put or Copy or Move) and
then a Laurel-runnable bcd deletes the file via DestroyFile[NewFile["<file>",7]],
and then another Put or Copy or Move attempts to write in that file, Laurel
bombs out with signal 5205B (InvalidFP).  It appears that too much information is
being cached, or perhaps Laurel should catch that signal and do a new directory
search if the file no longer exists at the former disk address.

*start*
00219 00024 US 
Date: 7 Oct. 1981 10:13 am EDT (Wednesday)
From: Lampson.PA
Subject: Cancel
To: Brotz

It is too bad that when you cancel an edit in Laurel 6, it doesn't restore the
previous selection.

Butler

*start*
00300 00024 US 
Date: 4 Nov. 1981 9:32 am PST (Wednesday)
From: McGregor.PA
Subject: Quated Public Distributions
To: LaurelSupport

Did you know that if I put quotes around a public distribution list, i.e. "Junk^",
then Laurel won't prompt me for a Reply-to option when I deliver...

Scott.

*start*
00741 00024 US 
Date: 4 Nov. 1981 6:09 pm PST (Wednesday)
From: Mieth.PA
Subject: Error Report
To: LaurelSupport.PA

i was trying to deliver a message.  I kept getting a syntax error on the subject
line.  i hit return instead of esc,  then got a message to hit the yellow button;
which i did.

Laurel 6  Alto II XM (005#102#) with 3K Ram XMcode using XM MDS: 00
Banks: 140000 code: 000051

Signal 047201 in IntExceptions
msg 000001, msg^                            

BackStop, 003550
Signaller, 000521
IntExceptions, 000215
VirtCM, 000751
VirtCM, 000560
EditorMain, 003514
EditorUndo, 000656
EditorMain, 000722
IntTrackMain, 000615
IntTrackEdit, 000310
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000122
DebugNub, 000334

*start*
04162 00024 US 
Date: 6 Nov. 1981 2:33 pm PST (Friday)
From: GNelson.PA
Subject: Multiple Substitutions in Laurel
To: Brotz
cc: GNelson

You can now execute many Laurel substitution commands with a single
keystroke, by running from within Laurel a new program called "Substitute".

The program is helpful when you want to perform many substitutions
throughout many files.  For example, suppose you want to change "" to "bell",
"" to "whistle", "developement" to "development", and ".  " to " stop "
throughout a great many files.  The COM S substitute command would have to
be used four times on each file, and the substitution arguments would have to
be retyped each time.  Using the new substitute program, you can proceed more
rapidly as follows:

First type into the bottom window the following colorful display:

developmentdevelopement

 stop .  

bell

whistle

(This is the style in which you list all the substitutions that you wish to
perform.  The laurel cherry character is typed as control-C; it is used to delimit
the patterns and replacements, since it is unlikely to be needed within them.)

Then Run the InsertMail program; this will move the cherry stew into the
middle window, out of the way of the files that you will be bringing into the
bottom window.

For each file that you want to process, Get the file into the bottom window, Run
the program Substitute, and Put the file back (after checking that the
substitutions performed as you expected).

They will rarely perform as you expect.  For example, the substitutions above
would transform a file consisting of the two sentences:

	Developement of s and s proceeds apace.  Laurel soon to be more
baroque than Teco.

into

	developement of bells and whistles preceeds apace stop Laurel soon to be
more baroque than Teco.

Note that the last period was not replaced, as it is at the end of the file and has
no spaces after it, and that the "D" has been demoted to a "d", probably
inadvertently.  Multiple global substitution schemes generally require
debugging, which is convenient from within laurel, as the Forward command
will move the substitution scheme back into the bottom window where it can be
edited.

The double quote character (") is reserved for quoting cherries or other double
quotes. A double quote is used instead of a single quote since single quotes are
often needed in the x's and y's, for example to get # or * or & to stand for
themselves in the pattern of the substitute command. 
 
In summary:

Let the contents of the middle window be

	s0  x0  y0  s1  x1  y1   ...   xN  yN  sN+1

where none of the x's or y's contains the cherry character or the double
quote character, and where none of the s's contains the cherry character.

Then the effect of the program is the same as that of the following sequence
of Laurel substitute commands, performed in the order they are listed:

Substitute x0 for y0
Substitute x1 for y1
...
Substitute xN for yN

The s's are ignored; usually they are carriage returns or comments.

If a double quote appears in one of the x's or y's, its only effect is to strip
the following character (presumably a cherry or double quote) of any
special lexical significance, so that the resulting x or y contains the 
following character and not the double quote.

The s's must contain no cherries, not even quoted ones.

If the contents of the middle window are not in the above form, or if one
of the x's or y's are longer than Laurel allows in its Substitute command, 
then an error message is given and the program exits to Laurel.

This message itself is a valid substitution scheme (with unusually long s's); try
moving it into the middle window and applying it to the sentence above about
laurel and teco. ( = control G,  = control E).  The paragraph should be
transformed as advertised.  In addition, the "No substitutions made" warning
message will flash three times, because there are no occurences of "y0", "y1", or
"yN" in the paragraph.

The substitute command is now on [ivy]<GNelson>substitute.laurel.

You might want to look over the mesa program there to see if I did anything
stupid.

Greg
*start*
01191 00024 US 
Date: 7 Nov. 1981 2:54 pm PST (Saturday)
From: Arndt.es
Subject: Re: Kal.laurel
To: AllGames^
cc: Arndt
Reply-To: Arndt

Sorry, I forgot to mention that the commands in Kal are Q (for quit; this requires
confirmation, and once confirmed, Kal will ask you if you want to save the
parameters) and ? (to list the command(s)).

Austin Henderson found a bug in Kal, so I've stored a new version (version 2,
dated 7 November 1981).

When you type any non-command key, Kal expects you to change the
parameters, so it lists the current parameters for you and then prompts you for
the new values.  The standard editing functions (backspace, backword, etc.) are
all available.  If you enter an invalid number - or a text string longer than 10
characters - Kal will output a "?" and start over with the same parameter.

Key		Meaning
		
Initial SP	Use current value, go to next parameter
Initial ESC	Display current value
Initial CR	Use current value for this parameter and exit parameter changing
SP		Use the new value for this parameter and go to next parameter
CR		Use the new value for this parameter and exit parameter changing
DEL		Exit parameter changing


~ Pete

*start*
00515 00024 US 
Date: 10 Nov. 1981 9:08 am PST (Tuesday)
From: White.PA
Subject: Laurel Reply-To Bug
To: LaurelSupport
cc: White

If I send a message via a private distribution list containing one or more Arpanet
addresses, Laurel supplies a Reply-To field in response to ESC, but the field
contains "White", rather than "White at PARC-MAXC".  When my Arpanet
recipients receive the message, they cannot use their mail system's REPLY
command to respond because the reply-to address is not fully qualified.

*start*
00667 00024 US 
Date: 3 Dec. 1981 4:27 pm PST (Thursday)
From: Deutsch.PA
Subject: Two very small Laurel suggestions
To: LaurelSupport.PA

Laurel does a wonderful job of remembering things from one activation to
another.  One thing it doesn't currently remember is the last file name used for
"Move to".  I imagine this would be a very small addition.

On a slightly different topic, if I fire up Laurel with /s and then decide I want
to read my mail, it would be nice if I could select "Mail file" with the blue
button and have it fill in the default mail file name Active (or even have it fill
in Active, but not actually read it, when I fire up with /s).

*start*
00772 00024 US 
Date: 8 Dec. 1981 9:21 am PST (Tuesday)
From: Artibee.PA
Subject: Re: Laurel 6 Bug
In-reply-to: Brotz's message of 8 Dec. 1981 9:07 am PST (Tuesday)
To: Brotz
cc: Artibee

I think there's a misunderstanding.

Johnsson's message (probably composed/sent from a Pilot 8.0 Hardy) came onto
my Alto-partition on my Dolphin via Laurel 6.  When I then forwarded his
message by bugging "Forward" command in the bottom-most Laurel 6 "window",
Laurel added the dashed lines to the text as is customary.

Are you saying that:

"(SAx000Initial.db).------------------------------------------------------------"

is an OK thing for Laurel to do when I ask it to forward?  If so, I'm confused
and would appreciate a call or message to straighten my thinking out.
*start*
02571 00024 US 
Date: 9 Dec. 1981 11:12 am PST (Wednesday)
From: Pasco.PA
Subject: Files.laurel & invalid file names
To: LaurelSupport
cc: Pasco

Did you know you can use Files.laurel to rename a file to one containing invalid
characters in its name (e.g. &) and then you can't rename it back?

See Fonts.mail and Press&Fonts.mail in the example below.

Laurel File Utility of 27-Apr-81 18:25:50
Type ? for help.
>list *.mail
820.mail   Active.Mail   ArithCoding.mail   Audio-Auburn.mail   Benefits.mail  
Bicycling.mail   Bldg.mail   CDS.mail   CherrySynth.mail   Chipmonk.mail  
CodeNames.mail   ColorMonitors.mail   Docs.mail   Dorado.mail  
DoradoNames.mail   Ecology.mail   EIB.mail   ERF.mail   Ethernet.mail  
Fis.mail   Fonts.mail   ForSale.mail   Forum.mail   Games.mail   Hangers.mail  
HomeComputing.mail   IcTester.mail   IEC.mail   Kauai.mail   Lab.mail  
Laurel.mail   LSI.mail   Lyon.mail   Magic.mail   MDG.mail   Mesa.mail  
MITConference.mail   MOSSIM.mail   MPC.mail   Networks.mail   Party.mail  
PatentLaw.mail   Personnel.mail   Pilot.mail   Plotting.mail   Policies.mail  
Progress.mail   PWBCAD.mail   Ramtek.mail   Recycling.mail   Release.mail  
RemoteControl.mail   Rio.mail   RS232.mail   Rubrik.mail   Seminars.mail  
Servers.mail   Sil.mail   Smalltalk.mail   Speech.mail   Star.mail   Sunrise.mail  
Sunshine.mail   Tax.mail   Tester.mail   Thyme.mail   Time.mail  
VENDING.MAIL   Versatec.mail   Voice.mail   
>ren Fonts.mail Press&Fonts.mail
>li *.mail
820.mail   Active.Mail   ArithCoding.mail   Audio-Auburn.mail   Benefits.mail  
Bicycling.mail   Bldg.mail   CDS.mail   CherrySynth.mail   Press&Fonts.mail  
Chipmonk.mail   CodeNames.mail   ColorMonitors.mail   Docs.mail   Dorado.mail  
DoradoNames.mail   Ecology.mail   EIB.mail   ERF.mail   Ethernet.mail  
Fis.mail   ForSale.mail   Forum.mail   Games.mail   Hangers.mail  
HomeComputing.mail   IcTester.mail   IEC.mail   Kauai.mail   Lab.mail  
Laurel.mail   LSI.mail   Lyon.mail   Magic.mail   MDG.mail   Mesa.mail  
MITConference.mail   MOSSIM.mail   MPC.mail   Networks.mail   Party.mail  
PatentLaw.mail   Personnel.mail   Pilot.mail   Policies.mail   Progress.mail  
PWBCAD.mail   Ramtek.mail   Recycling.mail   Release.mail  
RemoteControl.mail   Rio.mail   RS232.mail   Rubrik.mail   Seminars.mail  
Servers.mail   Sil.mail   Smalltalk.mail   Speech.mail   Star.mail   Sunrise.mail  
Sunshine.mail   Tax.mail   Tester.mail   Thyme.mail   Time.mail  
VENDING.MAIL   Versatec.mail   Voice.mail   
>ren Press&Fonts.mail Press-Fonts.mail
Cannot find Press&Fonts.mail
>q
*start*
01368 00024 US 
Date: 10 Dec. 1981 10:59 am PST (Thursday)
From: Ciccarelli.PA
Subject: Laurel extensions ??
To: Brotz
cc: Ciccarelli

Doug -- I noted in the HP 12/10/81 Colloquium notice (regarding an integrated
computing environment at USC/Information Sciences Institute) that one of the
services is an "appointments calendar".  I have often wished one existed here,
preferably as an adjunct to the message system, so I could keep track of meetings
easily.  

I keep a mail file for "Events" announcements recieved via Laurel, but there are
several missing capabilities (in order of estimated difficulty...): 

(1) A way of including the TIME OF THE EVENT in the TOC listing

[ If the originator of the announcement is aware of the problem,
the SUBJECT field can usually be composed so as to provide this info]

(2) Automatic sorting by date and hour, for Event-type files

(3) A way of entering re-occurring events, such as "Cholla meetings every
Tuesday at 11"

(4) A graphical presentation of all this, like a wall calendar.  Maybe the notion
of "tiny windows" (a la MesaDebugger) could be used.  The top-level
presentation could look like a wall calendar, with brief description of events of
that day; by expanding that day's box the finer detail would become visible.

Enough flaming; I just wanted to record this while it was fresh in my mind.

/ John
*start*
01274 00024 US 
Date: 22 Dec. 1981 12:15 pm PST (Tuesday)
From: Nelson.PA
Subject: Abuse of minus for em and en dash, and font documentation
To: LaurelSupport

Nit 1:

For some reason Laurel's font contains ^X, minus sign, but not ^V and ^S, en
and em dash (^V is already mapped to something, ah...).  (I also beineve that
^N is the current minus, not ^X, but I'm not sure.)  If you guys are going to put
in all kinds of funny stuff, please at least put in the stuff that appears in
common documents.  Given the empty slots available, I can live without en, but
not em.  Please consider this the next time around, even if you don't use 'em
yourself.  Just look in any "modern" bravo document to convince yourselves
about em dash in running text.  What makes this particularly bad is the
instantiation of minus for em by some misguided souls who are teaching bad
typography to others.

Nit 2:

Laurel has all these crazy characters in it.  But they don't seem to be
documented anywhere (I looked in the manual and could have missed 'em).
In fact, it seems as if their use is discouraged.  I suggest either explaining how to
use them up front, or taking them out alltogether.  None of this sorcerer's
apprentice stuff--not in a system and document of Laurel's class.
*start*
00499 00024 US 
Date: 30 Dec 1981 14:12 PST
From: Birrell at PARC-MAXC
Subject: Re: Reading mail from a distance
In-reply-to: Brotz's message of 29 Dec. 1981 1:59 pm PST (Tuesday)
To: BRIAN at MIT-ML
cc: Brotz at PARC-MAXC

You should arrange to use Arpa telnet to talk to Maxc, then use the "Telnet"
program there to talk to the Pup host "Ernestine".  Ernestine has an MSG-like
interface, using single-letter command names.  It has a "Help" command which
gives some documentation.

Andrew

*start*
01078 00024 US 
Date: 12 Jan. 1982 1:47 pm PST (Tuesday)
From: Belvoir.eos
Subject: Error Report
To: LaurelSupport.PA

My Dolphin died with 122 displayed in the MP (RM parity error).  I rebooted
and brought up Laurel again.  Since I was in the middle of composing a msg I
wanted to 'type' what was in DMS-*.tmp.  So I ran Files.laurel, check the
directory and started to type DMS*, it typed DMS-98.tmp and started to type
DMS-99.tmp when Laurel bombed.

Laurel 6  Dolphin (012#340#) with XMcode using XM MDS: 00 Banks: 170000

Signal 047201 in IntExceptions
msg 000001, msg^                            

BackStop, 003550
Signaller, 000521
IntExceptions, 000215
TempFileManager, 000177
VirtCom, 000633
VirtCom, 000561
VirtCom, 000364
VirtCM, 002754
VirtCM, 000240
VirtCM, 002120
VirtCM, 001500
VirtCM, 001356
ExecIO, 001412
ExecIO, 001115
ExecStreamIO, 000252
FilesMain, 003234
Directory, 000246
Directory, 001230
Directory, 000200
Directory, 000257
FilesMain, 002136
FilesMain, 000417
Modules, 000277
Modules, 000157
ExecSS, 001627
ExecSS, 000602
Stack end OurProcess

*start*
01685 00024 US 
Date: 22 Jan. 1982 1:33 pm PST (Friday)
From: Brotz.PA
Subject: Mail file format
To: Wilson.es
cc: LaurelSupport

A Laurel mail file has the structure (<stamp> <message>)*, i.e., a sequequential list of messages, each preceded by a small amount of text called the stamp.  Each stamp describes the message it precedes.  A typical stamp is

*start*
03925 00024 US 

The first eight characters (*start* plus one carriage return) are placed in the stamp to make them stand out in listings, etc.  The next five characters are Ascii digits (base 10) describing the length of this unit of message + stamp.  Important: this length includes the length of the stamp.  An Ascii space character comes next, followed by another five Ascii digits describing the length of the stamp.  This is nearly always 00024.  Another Ascii space character is followed by three character whose meanings are:
1) U for undeleted, D for deleted (you should never see a D here).
2) S for seen, U for unseen.  The ? displayed in the mark field of the table of
contents means this character = U.
3) The mark character (other than ?) for this message.  In the example above the mark character happens to be a blank.

A carriage return completes the 24 characters of the standard stamp.

The text of the message follows immediately, and the next stamp begins immediately after that message.  There are no padding bytes added anywhere; stamps and messages may begin or end on odd numbered bytes.

The last character of the last message is the last character in the mail file.

The format of the table of contents file is considerably more complicated.  I suggest you not deal with them.

-- Doug

*start*
01164 00024 US 
Date: 26 Jan. 1982 4:53 pm PST (Tuesday)
From: Birrell.pa
Subject: Re: "fixing" mail headers
To: Baskett, McGregor
cc: Brotz

True, the answer command could recover a bit better (although, of course, it
would be nicer if people didn't send illegal headers).  I expect Doug will add it
to his wish-list.

---------------------------

Date: 26 Jan. 1982 4:29 pm PST (Tuesday)
From: Baskett.PA
Subject: Re: "fixing" mail headers
In-reply-to: Birrell's message of 26 Jan 1982 14:33 PST
To: Birrell
cc: McGregor

Thanks.  That all makes sense.  So how about an error message that says "Can't
'cc' to a) someone in the original to list or b) someone in the original cc list. 
Type ESC to forge ahead anyway."?  That way it would do as much of the work
as it could for me and I would just have to patch up what it couldn't handle.  In
fact, (now that I am thinking of possible work for other people to do!) it could
include the unparseable strings in field marks ( and its cousin) in the cc line
of the answer form.  That would make it even easier to patch up.

Thanks again,
Forest

------------------------------------------------------------

*start*
00723 00024 US 
Date: 29 Jan. 1982 9:00 pm PST (Friday)
From: Rutenberg.PA
Subject: Re: Running programs
In-reply-to: LaurelSupport's message of 27 April 1981 12:03 pm PDT (Monday)
To: LaurelSupport


Suggestion:
Message 16 ("Running Programs") refers to shifted selection in message 9.  The
section on shifted selection is in fact in message 10 ("Composing messages"). 
Also related to shifted selection, I found that the section told me how to do it but
did not tell me why I would want to use shifted selection.

I like this tutorial very much.  I am just learning to use the Alto and I've found
going through this very helpful.  I am also very impressed with the mail system
in general!

					Michael Rutenberg
*start*
00559 00024 US 
Date: 2 Feb. 1982 8:25 pm EST (Tuesday)
From: Sherry.HENR
Subject: Files.laurel rename problem
To: LaurelImp^.pa
cc: Sherry
Reply-To: Sherry

I used files.laurel to rename a file.  The new file already existed, so the rename
failed as it is supposed to, but the original file disappeared.  The conversation
went something like this:

>ren a b
File a could not be renamed to b
>list a
no files

I had to run Scavenger to recover file a.  It did not have a directory entry but
the contents of the file were intact.
								Randy Sherry

*start*
05273 00024 US 
Date: 19 March 1982 12:13 pm PST (Friday)
From: Brotz.PA
To: Suk.pa
Subject: Re: Laurel Hardcopy Forms
In-reply-to: Your message of 19 March 1982 11:42 am PST (Friday)
cc: Brotz

The following should give you enough samples to choose from.  Spaces don't matter except for the first one on each line and those within quotes.

Font: 0 Laurel 10
Font: 4 Helvetica 8
Font: 5 Helvetica 12 B
Font: 9 HyType 11
HardcopyForm: Plain 25000 2540 3150 19050 0 T
 (Options
  (PageNumber 18415 26750 6 F)
  (PageNumber 18415 26750 6 T)
 )
 (Rows
  (0 0 35 (Everything 3150 19050 6) )
 )
HardcopyForm: PerformanceAppraisal 25000 2540 3150 19050 0 T
 (Options
  (Heading 2700 26750 0 F Heading 18000)
  (PageNumber 18415 26750 0 F)
 )
 (Rows
  (0 0 0 (Field 0 0 0 0 F F 0 PrintForm "" F T F F) )
  (0 0 0 (Field 0 0 0 0 F F 0 To "" F T F F) )
  (0 0 0 (Field 0 0 0 0 F F 0 Subject "" F T F F) )
  (0 0 0 (Field 0 0 0 0 F F 0 cc "" F T F F) )
  (0 0 0 (Field 0 0 0 0 F F 0 Date "" F T F F) )
  (0 0 0 (Field 0 0 0 0 F F 0 From "" F T F F) )
  (0 0 0 (Field 0 0 0 0 F F 0 Sender "" F T F F) )
  (0 0 0 (Field 0 0 0 0 F F 0 Heading "" F T F F) )
  (0 0 0 (OtherFields 3150 12150 8 7 T F 3650 1000) )
 )
HardcopyForm: WindowLetter 25000 2540 3150 19050 0 T
 (Options
  (Heading 2700 26750 0 F Heading 18000)
  (Caption 3800 26450 0 T "You name")
  (Caption 3800 26000 0 T "1st line of address")
  (Caption 3800 25550 0 T "2st line of address")
  (Caption 3800 25100 0 T "3st line of address")
  (Caption 500 18400 0 T ".")
  (PageNumber 18415 26750 0 F)
 )
 (Rows
  (0 21900 35 (Body 2700 19050 0) )
  (0 0 0 (Field 0 0 0 0 F F 0 PrintForm "" F T F F) )
 )
HardcopyForm: Headers 25400 2540 1800 20500 0 F
 (Options
  (Caption 8000 26670 0 T "Laurel Table of Contents" )
  (Caption 1800 26300 1 T "From:" )
  (Caption 6245 26300 1 T "Subject:" )
  (Caption 15000 26300 1 T "Date:" )
  (PageNumber 20000 26670 0 T)
  (Caption 8000 26670 0 F "Laurel Table of Contents" )
  (Caption 1800 26300 1 F "From:" )
  (Caption 6245 26300 1 F "Subject:" )
  (Caption 15000 26300 1 F "Date:" )
  (PageNumber 20000 26670 0 F)
 )
 (Rows
  (300 0 35 (Field 1800 5610 0 1 F F 2000 From "" T F F F)
    (Field 6245 14365 0 1 F F 6550 Subject "" T F F F)
    (Field 15000 20500 0 1 F F 15300 Date "" T F F F) )
 )
HardcopyForm: HyType 24730 2540 2500 20000 0 T
 (Options
  (Caption 2500 25670 9 T "Laurel HyType Message")
  (Heading 2500 25670 9 F Subject 15875)
  (PageNumber 18415 25670 9 F)
 )
 (Rows
  (0 0 106 (Field 2500 11000 9 9 T T 2500 To "" T F T F)
    (Field 11500 20000 9 9 T T 11500 From "" T F T F) )
  (420 22220 106 (Field 2500 11000 9 9 T T 2500 Subject "" T F T F)
    (Field 11500 20000 9 9 T T 11500 Date "" T F T F) )
  (0 0 0 (Field 2500 20000 9 9 F T 2500 PrintForm "" F T T T) )
  (420 0 106 (OtherFields 2500 20000 9 9 T T 2500 420) )
  (1000 0 106 (Field 2500 20000 9 9 T T 2500 In-Reply-To "" F F T F) )
  (2000 0 106 (Body 2500 20000 9) )
  (420 0 106 (Field 2500 20000 9 9 F T 3300 c cc F F T T) )
 )
Font: 6 OldEnglish 18
HardcopyForm: Diplomacy 25400 2540 3175 19050 0 T
  (Options
    (Caption 3175 26400 6 T "Diplomacy: ")
    (Heading 6085 26400 6 T Subject 12700)
    (Heading 12800 26400 6 T From 19050)
    (PageNumber 18415 26670 0 F)
  )
  (Rows
    (0 0 0 (Field 3175 19050 0 1 F T 4445 Subject "" F T T F)
      (Field 3175 10795 0 1 F T 4445 From "" F T T F) )
    (0 0 35 (Field 3175 19050 0 1 F T 4445 Sender "" F F T F) )
    (0 0 35 (OtherFields 3175 19050 0 1 F T 4445 0) )
    (1000 0 35 (Body 3175 19050 0) )
    (420 0 35 (Field 3175 19050 0 1 F T 3810 cc c F F T T) )
  )
HardcopyForm: LaurelX 25730 2540 3500 19050 0 T
 (Options
  (Caption 900 26670 5 T XEROX)
  (Caption 3500 26670 5 T "Internal Memo")
  (Heading 3500 26670 0 F Subject 15875)
  (PageNumber 18415 26670 0 F)
 )
 (Rows
  (0 0 35 (Field 3500 10795 0 4 T F 3500 To "" T F T F)
    (Field 12065 19050 0 4 T F 12065 From "" T F T F) )
  (420 22220 35 (Field 3500 10795 0 4 T F 3500 Subject "" T F T F)
    (Field 12065 19050 0 4 T F 12065 Date "" T F T F) )
  (0 0 0 (Field 3500 19050 0 4 F F 4165 PrintForm "" F T T T) )
  (420 0 35 (OtherFields 3500 19050 0 4 T F 3500 420) )
  (1000 0 35 (Field 3500 19050 0 4 T F 3500 In-Reply-To "" F F T F) )
  (2000 0 35 (Body 3500 19050 0) )
  (420 0 35 (Field 3500 19050 0 4 F F 4165 c cc F F T T) )
 )
HardcopyForm: LibraryRequest 25400 2540 3500 19050 0 T
     ( Options
        ( Caption 4445 26670 0 T "LIBRARY REQUEST" )
        ( Caption 15240 26670 3 T "XEROX" )
     )
     ( Rows
        ( 0 0 0  ( Field 8255 22225 0 1 T F 8890 Author "" T F T F ) )
        ( 35 0 50 ( Field 3810 8200 0 1 F F 3810 Option "" F F F T )
             ( Field 8255 2225 0 1 T F 8890 Title "" T F T F ) )
        (1200 0 0 (Field 8255 16460 0 1 T F 8890 PublicationDate "" T F T F )
           ( Field 16510 22225 0 1 T F 17145 Publisher "" T F T F ) )
        ( 1270 0 0  (Caption 2540 11430 1 "Additional Information" ) )
        ( 0 0 0 ( Body 3810 11430 0 )
             ( Caption 2540 11430 1 "NOTICE: Copyright Restrictions" ) )
        ( 1270 0 0 ( Field 2540 8200 0 1 T F 3810 Name "" T F T F )
             ( Field 8255 13335 0 1 T F 8890 Date "" T F T F )
             ( Field 14605 22225 0 1 T F 15875 Phone "" T F T F ) )
     )
*start*
00372 00024 US 
Date: 23 March 1982 1:42 pm PST (Tuesday)
From: McNown.pa
Subject: Bringing Up New Form
To: LaurelSupport.pa
cc:  McNown

I have an interesting uncertainty when i bug New Form.  

Sometime the subject comes up underlined ready for replacement and some times
the carrot is there ready for insertion.  I though computers were deterministic.


bob



*start*
00855 00024 US 
Date: 24 March 1982 12:44 pm PST (Wednesday)
From: Brotz.PA
Subject: Re: Bringing Up New Form
In-reply-to: McNown's message of 23 March 1982 1:42 pm PST (Tuesday)
To: McNown
cc: LaurelSupport

Congratulations.  You have discovered a bug in Laurel's modal editor.  If the editor is in insert mode, i.e., you haven't terminated your previous typein when you bug New form, then the caret will blink in front of the subject.  If you are not in insert mode at the time you bug New form, then Laurel's behavior is correct.  There is no problem in the modeless editor.

If you detect the error case, immediately type ESC to terminate insert mode, and re-invoke New form.  Proceeding otherwise is at your own risk.

Your message mentions a carrot.  Laurel has bells and whistles, but no fruits or vegetables at the present time.

-- Doug

*start*
00980 00024 US 
Date: 28 MAR 1982 1440-PST
From: MASINTER.PA
Subject: pseudo-names in Laurel
To:   Taft
cc:   Masinter, LaurelImp^

I have read your memo on file access, and in general agree
that the proposed measures are important for shoring up
some of the more gaping holes in the Internet security.

The only problem and reduction in functionality is your
proposal for disallowing "function" login names such as
SDSupport. I agree that for access control that these 
pseudo-names should not have any access authorization.

One simple solution would be for laurel to allow (and make it easy)
for person A to send out mail that says "From: B" AND WHICH
DOES NOT HAVE "Sender: A" appended in the case where B's
mail is forwarded to A.

I don't think this introduces any particular security holes,
and it also provides a way to achieve something which would
otherwise require giving out one's password: "Please answer
my mail for me (as me) when I am out of town."

Larry
*start*
02820 00024 US 
Date: 11 Feb. 1982 5:05 pm PST (Thursday)
From: Brotz.PA
To: Crowther
Subject: Laurel module breakdown
cc: Brotz


Module name			Size			Category
				S: < 10K bytes,	(OK, Minimal Rewrite,
				M: < 30K bytes,	Major Rewrite, Cedar provides,
				L: >= 30K bytes	Goes away)

AccessOp				S			Minimal Rewrite
AnswerImpl				M			OK
AppendOp				S			Minimal Rewrite
BackStop				M			Cedar provides
ChollaBBoard			M			Minimal Rewrite
ChollaCmd				M			Minimal Rewrite
ChollaMail				M			Minimal Rewrite
ChollaMailUtils			M			Minimal Rewrite
ChollaMDControl			S			OK
ChollaSpecs				S			Minimal Rewrite
ChollaStep				L			Minimal Rewrite
ChollaStepList			M			Minimal Rewrite
ChollaStepListParse			S			OK
CopyOp				S			OK, Cedar provides
CoreImpl				M			OK
CoreStreams				M			OK
Display				M		Major Rewrite, Cedar provides
DMSTime				S			Minimal Rewrite
EditorDisplay			L			Cedar provides
EditorFiles				M			Cedar provides
EditorFind				M			Cedar provides
EditorMain				M			Cedar provides
EditorMisc				S			Cedar provides
EditorTypein			S			Cedar provides
EditorUndo				S			Cedar provides
ExecIO				S			Cedar provides
ExecKeyboard			S			Cedar provides
ExecSS				M			Cedar provides
ExecStorage				S			Cedar provides
ExecStreamIO			S			Cedar provides
FileOp				M			Cedar provides
GVSender				S			Minimal Rewrite
HardcopyInstaller			L			Cedar provides?
InitInteractor				L			Major Rewrite
InitLaurel				M			Major Rewrite
InstallLaurel				L			Goes away
IntAnswerCom			S			Minimal Rewrite
IntBoundaryCom			M			Cedar provides
IntBracketsCom			M			Cedar provides
IntDiablo				S			Cedar provides?
IntDisplayCom			M			Major Rewrite
IntEditCom				S			Minimal Rewrite
IntExceptions			M			Major Rewrite
IntHardcopyCom			L			Cedar provides?
IntIdleLoop				S			Major Rewrite
IntMailCom				S			Minimal Rewrite
IntMBXState				S			Minimal Rewrite
IntMusic				S			Goes away
IntPress				M			Cedar provides?
IntRefreshers			S			Cedar provides
IntSendCom				M			Major Rewrite
IntTOC				M			Major Rewrite
IntTrackEdit				M			Cedar provides
IntTrackMain			M			Cedar provides
IntTrackMisc			S		Cedar provides, Major Rewrite
IntUserCom				S			Cedar provides
LaurelByteBlt			S			OK?
LaurelInterrupt			S			Goes away
LaurelNub				S			Major Rewrite
LaurelSegments			S			Major Rewrite
MailFileOp				M			Minimal Rewrite
MailStampFormat			S			OK
MessageParseImpl			S			Minimal Rewrite
ModuleNameImpl			S			Goes away
MTPSender				S			OK
Overview				S			OK
Protection				S			Cedar provides?
RecipientList				S			OK
ReplaceMailOp			M			Minimal Rewrite
SenderCommon			S			OK
SendParser				S			OK
SetTime				S			Goes away
TempFileManager			S		Goes away, Cedar provides?
TOCSelection			M			Major Rewrite
VirtCM				M			Goes away
VirtCMFiles				S			Goes away
VirtCom				S			Major Rewrite
VirtSS				S			Major Rewrite
VirtTOC				M			Major Rewrite

-- Doug

*start*
00643 00024 US 
Date: 17 Feb. 1982 3:14 pm PST (Wednesday)
From: Brotz.PA
Subject: Cholla 1T14
To: ChollaUsers^
Reply-To: Brotz.PA

Cholla 1T14 is now available on [Cherry]<Cholla>Laurel>Laurel.image!14.  This version corrects a file system bug that prevented file replacement.

To install Cholla 1T14, just retrieve it.

Some commands have moved around, many glitches have been smoothed over, and a new Mark command appears on the Step list middle menu.  The Mark command sticks a  in the step title of all steps selected.  COM-G, COM-P, COM-F, COM-S now work properly regardless of which menu appears in the lower window.

-- Doug

*start*
00598 00024 US 
Date: 25 March 1982 10:26 am PST (Thursday)
From: LaPrade.eos
Subject: Two Suggestions
To: LaurelSupport.pa
cc: Hains, LaPrade

1. Chat.laurel should login with the same name and registry as is logged in to
Grapevine mail service via Laurel. It should not strip off the registry as it does
now.

2. When forwarding a message, Laurel should automatically copy the subject
from the old message to use as the default subject of the covering message. The
user could then change the subject if desired, but 90% of time the user probably
wouldn't have to do anything.

   /Kerry

*start*
00511 00024 US 
Date: 29 March 1982 4:37 pm PST (Monday)
From: Horning.pa
Subject: Re: "Fog" program
In-reply-to: Your message of 20-Mar-82 16:13:30 PST (Saturday)
To: Israel
cc: Horning, Brotz

Jay,

Sorry for the delayed response--I've been on a three-week trip.

I'm not sure whether there's an official version of Fog around anywhere.
However, [Maxc]<Horning>Fog.laurel runs under Laurel 6, and is presumably
what you are looking for. No one maintains it anymore, but I still use it a lot.

Jim H.

*start*
00534 00024 US 
Date: 16 April 1982 6:46 pm PST (Friday)
From: Bergsteinsson.es
Subject: A suggestion
To: LaurelSupport.pa
cc:  Bergsteinsson

If there ever is a Laurel 7, I would like to suggest an upgrade for you
consideration.

Make "automatic delete action after move" optional, controlled by a profile
parameter.  Different people have different methods for managing and
manipulating mail with Laurel.  The procedures I have evolved to mean that I
use move but don't want the message deleted in 99% of the cases.

Linda

*start*
01923 00024 US 
Date: 7 May 1982 11:45 am PDT (Friday)
From: TonyWest.PA
Subject: Laurel/Walnut/Product Mailsystem Suggestion
To: LaurelSupport
cc: Joos, Cattell, Redell, TonyWest

Here is a hesitant suggestion for a *new* Laurel/Mailsystem feature.  It is hesitant because I don't know if you want to mess around with Laurel any more.

However, the Cedar/Walnut folks might like to consider it -- I guess that means you, Rick.

Also, perhaps the idea has meaning in the context of the product mailsystem -- I guess that means you, Dave.  I don't know what facilities are being provided in the user-interface for form-filling type things.

IDEA: Add a "Return form" button to the bottom window's command menu.

Basically, this should have the combined effect of Answer and Forward.
In other words, part of the message displayed above is copied into the lower window and the From person is used as the new addressee.  The new From person is you, of course.  

The idea is that this is a good way of returning forms which people send you to fill out.  (I know you can do it with Forward or Answer!).

You might even do something interesting like only inserting that part of the above message which falls between two lines of -------'s, so that instructions are not returned.  

Example:  suppose this above had been a questionnaire; then the above would have been the instructions, and the tear-off part to send back would be the stuff below.

Tony
--------
CSL Dealer Food Order for May 12

Bread:	
Light Rye with Caraway Seeds
		Dark Rye without Caraway Seeds
		Whole Wheat
		Egg White
		French Rolls

Meat:		
Roast Beef
		Turkey
		Ham
		Pastrami
		Corn Beef
		Salami
		German Sausage
		Liverwurst
		Mortadella

Cheese:	
Swiss
		Jack
		Cheddar

Condiments:	
Pickles
		Mayonnaise
		Mustard
		Mayonnaise+Mustard+special mixture
		(no lettuce, tomato, or sprouts)

Beverage:	
Beer 
		Wine
		Juice
		Soda
--------
*start*
00702 00024 US 
Date: 10 May 1982 6:04 pm PDT (Monday)
From: Taft.PA
Subject: Reply-to
To: LaurelSupport

A random suggestion to add to your probably-never-to-be-implemented wish list:

If an incoming message says "Reply-to: distributionList^", then Answer should
construct a form that likewise says "Reply-to: distributionList^".  That way,
someone can start a discussion with the express intent of having all replies (and
replies to replies, etc.) be distributed to all members of the group.  Currently
what happens is that everyone has to remember to type "A" to confirm delivery;
sometimes people forget, with the result that some members of the group do not
receive all the messages.
	Ed

*start*
00914 00024 US 
Date: 12 May 1982 5:21 pm PDT (Wednesday)
From: Taft.PA
Subject: Retrieval to wrong mail file
To: LaurelSupport

I sometimes "lose" messages as a result of doing a NewMail when the mail file is
something other than Active without realizing I have done so.  That is, I switch
to some other mail file in order to look at old messages, and forget to switch back
to Active before retrieving new mail.  If I don't immediately deal with all the
newly-arrived messages, they remain in the other mail file instead of Active,
and I lose track of them until I next happen to look at that mail file.

Perhaps Laurel should post a warning in the feedback window if NewMail is
done when the mail file is other than Active.  (This need not demand any
additional confirmation, since the user can easily move the received messages to
the correct mail file if he is made aware that this has happened.)
	Ed

*start*
00847 00024 US 
Date: 14 May 1982 3:43 pm PDT (Friday)
From: Taft.PA
Subject: Needless dirtying of mail files
To: LaurelSupport

"Mail file" opens the mail file for writing, which changes the file's creation date,
even if the contents of the file are never actually changed.  This causes needless
extra backup traffic when mail files are backed up on file servers by automatic
means (Store/ua, Backup, or SModel).

Laurel should either open a mail file read-only until the first attempted write
(then close and re-open it for writing), or else should save the old creation date
and put it back when the file is closed if the file was never actually written on. 
(The Alto OS uses the latter strategy, and it has served well in coping with
client programs that are insufficiently specific about their intentions when they
open files.)
	Ed

*start*
01203 00024 US 
Date: 23 July 1982 2:55 pm EDT (Friday)
From: Hube.WBST
Subject: Comment on Laurel
To: LaurelImp^.pa
cc: Hube
Reply-To: Hube

I've been an Alto user for some time now and I would like to say that Laurel is
in my opinion the most well designed software user-interface I've seen ( and
that includes Star software and Mesa software too).  However, so as not to give
you too swelled a head, I would like to make a suggestion for improvement (
assuming you may someday issue another revision).


Always display the ' TO: ' field for all mail. 

This would allow a user to determine if a message is directed at him/her directly
( indicating importance or need for response ) or whether it is directed to a DL (
indicating potentially less importance ) or whether he is only copied (i.e. cc:) to. 
It sure would help weed out the garbage from the interesting stuff.  If screen
space is a limitation, it would be satisfactory to just indicate by a single letter
code whether the user is:

 a) directly addressed (by user-id)
 b) indirectly addressed (by DL)
 c) or merely copied

An example of this would be D, I, or C respectively. 

Thankyou in advance for your consideration.

Randy

*start*
00671 00024 US 
Date: 29 April 1982 1:41 pm PDT (Thursday)
From: Ciccarelli.PA
Subject: A useful Laurel form...
To: Brotz
cc: Ciccarelli

Doug,

I often use InsertMail to place messages to myself into my Active.mail file.  I got
tired of having to remember how to do this without getting a "bad date???" or
bad Sender field, so I made a simple form called Reminder.form to retrieve via
"Get".

Since you're the Laurel "Kahuna", I thought I'd zip off a copy to you...

----------------

Subject: 
Topic of reminder
Date: 
Press COM-T for date & time
From: ***REMINDER***


Type text of reminder here, then Run {InsertMail}

-----------------------------

/John
*start*
01083 00024 US 
Date: 26 May 1982 10:44 am PDT (Wednesday)
From: McBain.ES
Subject: Forms
To: LaurelSupport.pa
cc: McBain

Last night for the first time ever, I decided to build a Laurel PrintForm for a
personal letter.  Things generally went well.  With a couple of hours of fiddling
around I managed to get out a pretty decent form.

In the process I uncovered a bug.  The instructions tell me that if I want to print
a caption with white space that the caption should be given in surrounding
quotes ("....").  The assumption that follows is that once you get inside the quotes
that all's fair.  So I tried to put "(213) 375 5186" in a caption.  Turns out that you
can't put parentheses inside the quotes.

A second problem was a little more subtle.  The option to use commas to force
new lines seems neat.  I wanted to do the following:

I entered:
To: John Doe, 1234 Some Street, His City, California 90000

What I wanted to print was:
John Doe
1234 Some Street
His City, California 90000

What I got was:
John Doe
1234 Some Street
His City
California 90000


	/Dwight 

*start*
00394 00024 US 
Date: 5 July 1982 11:24 am PDT (Monday)
From: TonyWest.PA
Subject: Laurel Suggestion
To: Brotz

How about a laurel-runnable program called "wrap", which, when you run it,
takes whatever is in the bottom window and inserts a new message header AT THE TOP OF IT.

That is presumably trivial, and would provide a very succinct alternative to
	Insertmail then Forward

Tony
*start*
00818 00024 US 
Date: 5 July 1982 11:43 am PDT (Monday)
From: TonyWest.PA
Subject: Error Report
To: LaurelSupport.PA

YAAAAA BOOOOO SUCKS to you!
Cholla Laurel breaks again.  This time, I was scrolling up in the bottom window whilst I was chatting to unix and the output was actually appearing in the window.  In other words, there would appear to be a problem with chat both receiving output and scrolling at the same time.

Tony

Laurel 6.1T26  Dolphin (003#262#) with XMcode using XM MDS: 00 Banks: 177760

Signal 055201 in IntExceptions
msg 000001, msg^                            

BackStop, 003377
Signaller, 000521
IntExceptions, 000215
VirtCM, 000205
VirtCom, 000207
EditorDisplay, 001233
EditorDisplay, 000566
ExecStreamIO, 001444
ExecStreamIO, 001063
Chat, 002304
Chat, 001477
Stack end OurProcess

*start*
02763 00024 US 
Date: 14 July 1982 9:57 pm PDT (Wednesday)
From: Ramshaw.PA
Subject: SmashFont is available for use
To: Guibas, GNelson
cc: Plass, Brotz, Ritchie, VanMelle, Wyatt, Ramshaw

On [Ivy]<Ramshaw>Laurel>SmashFont.Laurel, you will find a .bcd that you can
Run in the bottom window of Laurel6.  It will prompt you for the name of a .al
file, and will then overwrite Laurel's standard display font with the font that
you specify.  The new font must be no more than 12 pixels in height, and the
corresponding .al file must be no larger than Laurel10.al.  If either of these
constraints are not met, SmashFont will complain.

Be warned that it is rather easy to break Laurel by using SmashFont:  the
following scenario definitely kills Laurel, and other similar strategies could be
invented.  Display a message with a long window in the middle paragraph. 
Then use SmashFont to install a font whose characters are wider than those of
the current font.  Scroll the middle window up a few lines, and then back down,
and you're done:  Laurel is dead.  Thus, SmashFont is only recommended for
sympathetic and expert users.

In particular, I wrote SmashFont to be able to edit source files for the Sail
implementation of TEX in Laurel's bottom window (until I switch to Tioga for
this job).  To this end, I have used Prepress to produce two fonts that are known
to work with SmashFont:
	Sorrel10.al  for people who like Laurel's current font (which 
			is based on an old version of TimesRoman)
	Xail10.al  for people who like the fixed-pitch Sail10.al, aka Gacha.

Both of these have some of the SAIL special characters in the standard places:
	infinity, partial, subset, superset, intersection, union, alignmentTab,
	exchangeArrow, and forwardArrow;
but no others (no room).  They also have distinct bitmaps for left and right
single quote, unlike Laurel10.al.  They have a down arrow, but it has been
moved from its Sail home at ^A to the ^D slot instead, since ^A is hard to type
in Laurel.

Because of the different down arrow and the lack of the relational operators like
"less than or equal to", you might want to \input a file like my own
LaurelEditing.tex at the start of your TEX file:

\chcode'4_8  %make ^D also a subscript character
\def\le{\mathrel\char'424 }  %ways to type the arithmetic relationals
\def\ge{\mathrel\char'425 }
\def\ne{\mathrel\char'434 }
\def\lt{\mathrel\char'074 }  %just for symmetry
\def\gt{\mathrel\char'076 }

This stuff is on [Ivy]<Ramshaw>Laurel>  (or /Ivy/Ramshaw/Laurel/ depending
upon your religion):
	SmashFont.Laurel
	Laurel10.al
	Sorrel10.al
	Xail10.al
	LaurelEditing.tex.

I am willing to give short Prepress lessons to people who want to produce still
other fonts to use with Laurel via SmashFont,

Lyle
	
*start*
02181 00024 US 
Date: 20 Sept. 1982 10:27 am PDT (Monday)
From: Brotz.PA
Subject: Re: Laurel Programs
In-reply-to: Gloger.es's message of 19 Sept. 1982 10:40 pm PDT (Sunday)
To: Gloger.es
cc: Brotz, Neumeister.es

Consider the following to be the document that describes how to write Laurel runnable programs.

Laurel will run Alto-Mesa programs that use IODefs for input and output and that use any interfaces exported by the Mesa Nucleus.  PupDefs and FTPDefs are also available, as are several Laurel internal interfaces, although the Laurel interfaces are not documented.  Only the User half of FTPDefs is implemented, and only the Send half of EFTPDefs is implemented.

Simple programs using only IODefs for interaction are easy to write and should run in the same way both under Mesa.image and under Laurel.  Your program is started when the Run command is invoked, running your startup code.  To finish, just run off the end of the main line code in your startup module.  Do not call ImageDefs.StopMesa for obvious reasons, and do not add or delete cleanuip procedures.  If you use PupDefs, be sure not to turn the Pup Package on or off (it's already on.)  Use Storage for allocating and freeing storage.  Laurel will check your allocation, and will crash spectacularly if any allocated storage is not freed by the time your program finishes.

The complete list of exports from Laurel is listed below.

Laurel: CONFIGURATION
  EXPORTS
  -- from Mesa
  AllocDefs, BcdOps, DirectoryDefs, DiskKDDefs, FrameDefs, FrameOps, FSPDefs,
  ImageDefs, KeyDefs, MiscDefs, Process, ProcessDefs, Runtime, SegmentDefs, Storage,
  StreamDefs, StreamScan, String, StringDefs, SystemDefs, Time, TimeDefs,
  TrapDefs,
   -- from Pup
  BufferDefs, ByteBltDefs, CommUtilDefs, DriverDefs, EFTPDefs, PupDefs,
  PupPktDefs, PupRouterDefs, PupStream, Stream,
   -- from FTP
  FTPDefs, TimeExtraDefs,
   -- from Grapevine
  LocateDefs, NameInfoDefs, NameInfoSpecialDefs, ProtocolDefs,
  RetrieveDefs, SendDefs,
   -- from Laurel
  crD, csD, displayCommon, DMSTimeDefs, dsD, Editor, exD, inD, intCommon,
  IODefs, LaurelExecDefs, lmD, MailParse, mfD, opD, prD, Sequin, tfD, tsD, vmD 
-- Doug

*start*
08962 00024 US 
Date: Wed, 9 Mar 83 17:50 PST
From: Brotz.PA
Subject: Laurel 6.1 changes
To: Schroeder, JWhite, Taft, Levin
cc: Brotz

This message contains all information about Laurel 6.1 that you will need to keep the Laurel world going in my absence.

USER PERCEIVABLE CHANGES

Laurel 6.1's run file is 77 pages bigger than Laurel 6's.  This is mainly due to the inclusion of VM, the ChollaCmd module, the ReplaceMailOp module, and general ignoring of bit-bumming.

Blue button New mail:  When invoked with the blue mouse button, Laurel will retrieve new mail one message at a time, checkpointing the mail file locally and deleting the message on the server, until all mail is received or the local disk fills up.  A warning message appears if this New mail mode is invoked, requiring the user to confirm that this slower than normal mail retrieval is actually wanted.

Arpa header standard:  Laurel 6.1 contains an RFC822-only header parser.  Certain addresses acceptable in the past are no longer acceptable.  This will show up as the Answer command being unable to generate an answer form for these now illegal headers.  Laurel 6.1 will no longer append an Arpa host on outgoing messages.  The Answer command may also be confused by legal headers produced in the past that depended on Arpa host minimization algorithms, i.e., the header
    From: Brotz@PARC-MAXC
    To: Foo
will be answered as
    cc: Foo.Arpa
since the new parser understands that the sender was in the Arpa registry, and therefore Foo must have been shorthand for Foo.Arpa.
    Such cases should be rare.
    The profile entry ArpaGatewayHostNames is no longer supported.

CR insertion in Deliver:  Laurel 6.1 no longer automatically folds headers and places CR's in outgoing messages.  A new profile entry, DeliverWithCRs, is allowed, and is defaulted to FALSE.  If TRUE, Laurel 6.1 will insert CR's as in Laurel 6.  I would not advertise this feature.

Display of long lines in the displayed message window:  This will go much faster in Laurel 6.1.  Pseudo-CR's are written into the mail file to achieve this speed-up.

Remote file names:  In the profile entry RemoteFilePath, a $ character is replaced by the current user's name (without registry) when computing the remote file name.  This is only of interest to remote mail file users who share a common Laurel.profile.

New date syntax on outgoing messages:  The new format is
  Wed, 9 Mar 83 16:32 PST
   (Yeccchhhh).  This applies to the COM-T command as well.  The date at the upper right of the screen remains as old.


INTERNAL CHANGES

VM has replaced the Core for all File I/O.  The new interface Core, is a thin veneer over VM, and is similar to the now defunct CoreDefs.  One new module, CoreImpl, papers over this interface, providing the same old file name cache, which is now used only for enumerating recently accessed files in the brackets fill-in code.

The VirtualMgr now retains only a single page sized buffer for each object (displayed message, toc, and composed message).  TOC operations now require locks to operate properly in Cholla's multiprocessing environment.  See VirtualMgrDefs for details.  In essence, you must call LockTOC[tocHandle] to obtain a key (a CARDINAL) which must be passed to all other TOC manipulation procedures.  Most often, a call to WaitForLock[tocHandle] is more appropriate than a direct call to LockTOC, which may return 0, indicating that the tocHandle was already locked.  When finished manipulating a toc, you should call UnlockTOC[tocHandle, key].

Most operations level modules have been recoded to use CoreStreams rather than their own streaming procedures.

A new interface, ccD: ChollaCmdDefs, glues together the Cholla part of Laurel.  One procedure from this interface is used throughout Laurel proper; it is GetTOCForFile[fileName, tocClass], which returns a locked tocHandle with its key.  This procedure manages a complicated toc cache for Cholla.  Laurel proper will use only "laurel" as the tocClass.  Passing a NIL filename to this procedure clears out that classes cache (see the Quit command for details.)  If this procedure gives you any trouble, see Will Crowther.

ReplaceMailOp is very complicated.  It embodies most of the InsertMail code, but allows general insertion, deletion, or replacement of a single message in a mail file, with corresponding changes in the TOC.  It is not actually used in Laurel proper, but is called from Insert.laurel.  Cholla uses it all over the place.

The old module named ExpandOp is now named FileOp.  Expand in this module no longer understands @filename syntax.

The new mail parser's interface is MailParseDefs (not MailParse), and its implementation is in the new module ArpaMailParser.  There are no longer any Backup procedures supplied to this module's procedures.  The parser maintains a one character cache for those cases where it needs to look ahead one character.  It will read the first character of the next header field or the CR of the line following the last header field after reading a field body in GetFieldBody or ParseNameList.  This is important when counting calls to the ReadChar procedure to locate field body boundaries in IntHardcopyCom and elsewhere.  The general rule to follow is that everything works fine as long as you are streaming through the header, from field name to field body to field name to field body, etc.  If you must reset the ReadChar routine, you must FinalizeParse and InitializeParse to reset the cache correctly.  There is no performance penalty for doing this, as the new parser does almost nothing during those calls.


IF YOU WANT TO BUILD A NEW CHOLLA AND LAUREL

Command files and file lists abound on the [Cherry]<Cholla>1Txx> directories.  Source.Laurel, Source.LaurelDefs, Object.Laurel, and Object.LaurelDefs are file lists only--DO NOT USE THEM FOR COMPILATION.  Compile.LaurelDefs and Compile.Laurel are file lists containing the correct compilation order and leaving out those modules that should not be recompiled (e.g., LaurelExecDefs, which Maintain and Chat depend on.)  To compile all of the Cholla impl's (and therefore all of the Laurel impl's) say
  Compile @Compile.laurel@
to the executive.

To bind and build an image using bootmesa, use the command files mc.cm and ml.cm (for Make Cholla and Make Laurel).  Each one is to be invoked by saying
  Bind @mc
or
  Bind @ml
to the executive,

The Laurel configuration is a subset of the Cholla configuration.  Laurel leaves many Cholla interfaces unbound.  These procedures can never be called from Laurel, so this is ok, but binding Laurel normally produces Binder warning messages.  The ml.cm file ignores these warnings; the mc.cm file does not.  The correct procedure when binding new versions is to bind a Cholla first, and if it succeeds, then bind a Laurel.  The Cholla bind will detect any problems; if there are none, then the Laurel binding warning may be ignored safely.

Cholla will behave exactly as Laurel (displaying a Laurel herald, and no BBoard command) if the profile does not contain Cholla: TRUE.  Laurel will never behave as Cholla (it checks if certain Cholla procedures are bound).  The version string prefix is set up in InitInteractor, its suffix is set in Overview.  The current prefixes are "Laurel 6.1" and "Cholla 1".  The current suffix is "T34".  Before releasing, the suffix in Overview should be set to "".


USEFUL FILES TO HAVE AROUND IF YOU ARE GOING TO WORK ON LAUREL

All of the files on [Cherry]<Cholla>1Txx> where xx is the latest version.  This is the dumping ground for Laurel's pieces.  Other necessary files are:

[Ivy]<Mesa>
  Binder.bcd!2
  Compiler.image!3
  Fetch.bcd!1
  Front.run!1
  Lister.bcd!1
  Mesa.image!1
  MesaFont.Strike!1
  RunMesa.run!1
  XDebug.image!1
[Ivy]<Mesa>Bootmesa>
  Boot.bcd!1
[Ivy]<Mesa>FTP>
  FTPDefs.bcd!1
  FTPForLaurel.bcd!1
  TimeExtraDefs.bcd!1
  TimeExtraDefs.mesa!1
  TimeExtras.bcd!1
[Ivy<Mesa>Pup>
  BufferDefs.bcd!1
  ByteBltDefs.bcd!1
  ByteBltDefs.mesa!1
  CommUtilDefs.bcd!1
  DriverDefs.bcd!1
  EFTPDefs.bcd!1
  EFTPSend.bcd!1
  PupDefs.bcd!1
  PupPktDefs.bcd!1
  PupRouterDefs.bcd!1
  PupStream.bcd!1
  PupTypes.bcd!1
  Stream.bcd!1
  TinyPup.bcd!1
[Ivy]<Mesa>System>
  AllocDefs.bcd!1
  BcdOps.bcd!1
  DirectoryDefs.bcd!1
  DiskKDDefs.bcd!1
  FrameDefs.bcd!1
  FrameOps.bcd!1
  FSPDefs.bcd!1
  ImageDefs.bcd!1
  KeyDefs.bcd!1
  LoaderOps.bcd!1
  MiscDefs.bcd!1
  Process.bcd!1
  ProcessDefs.bcd!1
  Runtime.bcd!1
  SegmentDefs.bcd!1
  Storage.bcd!1
  StreamDefs.bcd!1
  StreamScan.bcd!1
  String.bcd!1
  StringDefs.bcd!1
  SystemDefs.bcd!1
  Time.bcd!1
  TimeDefs.bcd!1
  TrapDefs.bcd!1
[Ivy]<Mesa>TableCompiler>
  TableCompiler.bcd!1
[Indigo]<Grapevine>
  GrapevineUser.bcd
  LocateDefs.bcd
  NameInfoDefs.bcd
  NameInfoSpecialDefs.bcd
  ProtocolDefs.bcd
  RetrieveDefs.bcd
  SendDefs.bcd
[Indigo]<Grapevine>VM>
  AltoFile.bcd
  FileDefs.bcd
  Sequin.bcd
  VMDefs.bcd
  VMSpecial.bcd
  VMStorage.bcd

*start*
02070 00024 US 
Date: Mon, 14 Mar 83 14:37 PST
From: Brotz.PA
Subject: Laurel runnable bcd's
To: Schroeder, Levin, Taft, JWhite, McCreight, Willie-Sue

For Laurel 6.1, the interface LaurelExecDefs has not been recompiled from that used in Laurel 6, therefore, all programs that depend on that interface plus Mesa system interfaces only will run unchanged in Laurel 6.1.  This includes Maintain.laurel and Chat.laurel.

MailFileScavenger.laurel depends on the Core interface, therefore, you will need the new one.

All of the runnable programs are stored on [Cherry]<Cholla>Laurel>, with version numbers that correspond to the temporary version of Laurel 6.1 stored there.  The sources for these programs are on [Cherry]<Cholla>1T35> (the 1T35 being the current temporary version of Laurel and Cholla).

Basic is stored on [Cherry]<Cholla>Basic>.  There is a 1T35 compatible Basic.laurel on [Cherry]<Cholla>Laurel>.  Basic has never received much use, and there are definitely some problems with it.  However, if you wish to continue to support Basic, it should be reasonably simple to figure out what is going on by reading the files stored on [Cherry]<Cholla>Basic>.

The remaining runnable programs are pretty much the same ones that were offered for Laurel 6.  InsertMail.laurel is now called Insert.laurel.  There is also a Replace.laurel that behaves like Insert.laurel, except that it replaces the message selected in the TOC.  Delete.laurel does an immediate delete of the message selected in the TOC; it is not very useful for the general public and probably should not be announced.

SearchMail.laurel works as before.  A new program, Extract.laurel behaves like SearchMail, except that it copies the matching text into the composed message.  With an imaginative search specification, this program can generate amazing reports and summaries.

I declare that this message ties up the remaining loose ends.  John White will have a copy of my Laurel partition, so anything that I have dropped on the floor should be found there as a last resort.

-- Doug

*start*
00992 00024 US 
Date: Mon, 14 Mar 83 16:51 PST
From: Brotz.PA
Subject: Farewell
To: AllDc^.dc, AllDlos^.dlos, AllEs^.es, AllHenr^.henr, AllLb^.lb, AllPa^.pa, AllRx^.rx, AllSthq^.sthq, AllWbst^.wbst, AllEos^.eos
Reply-To: Brotz%Shasta@SU-Score

Having served you the past six years as a contributor to Laurel and as part of LaurelSupport.pa, I feel as if the distribution of this message is to my close circle of friends.

Today is my last day at Xerox; tomorrow I will be a member of Adobe Systems.

The next version of Laurel will be released within the next few months.  I hope you will find it to be satisfactory.  Remember, please address your gripes, praise, error reports and dreams to LaurelSupport.pa, which is being left in capable hands.

If you wish to get in touch with me, my new addresses are:

Postal:
Doug Brotz
Adobe Systems, Inc.
2685 Marine Way
Mountain View, CA 94043

Telephone:
(415) 969-5251

Net:
Brotz%Shasta@SU-Score

I wish you all the very best.

-- Doug

*start*
01137 00024 US 
Date: Wed, 6 Apr 83 15:15 PST
From: Taft.PA
Subject: Laurel development disk
To: JWhite
cc: Schroeder, Taft

We need to make some minor changes to Laurel in order to prepare it for release.  There are some problems that arise when running on a 64K Alto: the Run command doesn't work at all due to running out of memory, and performance is generally poor.  We hope we can fix this by some tuning of various parameters (size of initial frame heap, free storage heap, and VM buffer storage).  We may also experiment with some packaging changes; e.g., reduce the number of interfaces exported from the top-level configuration to the minimum required, in order to minimize the size of the LoadState.

Assuming the non-Cholla part of Laurel is in a stable state, I would like to get copies of all the files.  Doug led me to understand that you are keeping a Laurel development disk (or disk image stored on Cherry).  I believe the best way for us to get started would be to copy this disk.

Would you please copy the Laurel development disk to Cherry (if it's not there already) and tell me where it is?  Thanks.

	Ed

*start*
00816 00024 US 
Date: 7 April 1983 9:50 am PST (Thursday)
From: JWhite.PA
Subject: Re: Laurel development disk
In-reply-to: Taft's message of Wed, 6 Apr 83 15:15 PST
To: Taft
cc: JWhite, Schroeder

Ed,

All of the current Laurel (and Cholla) source files and bcd files are stored on 

			[cherry]<cholla>1T35>

Also, there is an image of Doug's Laurel/Cholla partition stored on

			[cherry]<jwhite>Brotz>bfs4

Nothing has changed since Doug left; although I'm about to make a minor
change to Cholla.  I would like to keep Laurel and Cholla internal releases
synchronized.  So, I want to try and have Cholla run on top of any changes
made to Laurel.  Doug always viewed Laurel 6.1 as a subset of Cholla and thus
kept the "truth" copy of everything in a single subdirectory.  Can we continue
this?

-- John 

*start*
00961 00024 US 
Date: Thu, 7 Apr 83 17:41 PST
From: Taft.PA
Subject: Re: Laurel development disk
In-reply-to: "JWhite's message of 7 April 1983 9:50 am PST (Thursday)"
To: JWhite
cc: Taft, Schroeder

I have copied the disk image, and Mike, Roy, and I did some experiments.  We've concluded that something more than simple tuning is required.  We are investigating alternatives ranging from buggering the Loader so that less has to be swapped in all at once during the Run command, to changing Run so that on a 64K Alto it doesn't work in the normal way but instead invokes any of a few programs that have been bound into Laurel (probably just Maintain and Chat).

In any event, we will take care to ensure that whatever we do does not have any adverse effects on Cholla.

Probably the best way to coordinate things is for me to give you any files I change, and you can make sure they work in Cholla and then store them back onto [Cherry]<Cholla>.

	Ed

*start*
02619 00024 US 
Date: Wed, 4 May 83 11:24 PDT
Sender: Taft.PA
From: The Laurel Implementors <LaurelSupport.PA>
Subject: Laurel 6.1 alpha test
To: AllMailUsers.dl: ;
Reply-to: LaurelSupport.PA

A new version of Laurel, version 6.1, has been prepared and is nearly ready for release.  At this time we are looking for people to test the new software for a few weeks before the release.  This is intended to ensure that we have not overlooked any variations in machine configuration, environment, or style of use.

Why a new Laurel?  After all, Laurel 6 has been around for about two years and has proven to be quite satisfactory for countless hundreds of users.  There are several reasons, the most important of which are:

1. We have adopted the new ARPA header standard for all messages in the Research Internet.  This is a considerable simplification over the old standard; and as part of this change we have taken the opportunity to clean up the treatment of ARPA names within the mail system so as to better insulate us from future changes in the ARPA standards.  The version of Hardy included in release 10 of the Mesa Development Environment already supports the new standard; bringing Laurel into conformity will make the exchange of messages between Laurel and Hardy users work more smoothly.

2. There are several serious bugs in Laurel 6.  For example, there are certain messages whose receipt will cause Laurel to crash.  And there is a problem that makes Laurel unusable on an Ethernet whose network number is greater than 126 octal; this restriction has put a troublesome constraint on the configuration of the Research Internet.

3. The departure of Doug Brotz, who was the principal person actively developing Laurel for the past two years, gives us an opportunity to wrap up the Laurel project cleanly and permanently.  While we will attend to any catastrophic problems that turn up, we are not planning any further development.

Laurel 6.1 is functionally nearly identical to Laurel 6, though internally it is quite different.  There is also an expanded collection of programs that may be invoked with Laurel's Run command.

If you would like to be a Laurel 6.1 alpha tester, please answer this message (i.e., send a message to LaurelSupport.PA).  We will send you more information and put your name on a special distribution list.  There will be no further announcements sent to the entire Research Internet community until Laurel 6.1 is officially released.

	The Laurel Implementors

	   Roy Levin <Levin.PA>
	   Mike Schroeder <Schroeder.PA>
	   Ed Taft <Taft.PA>
	   John White <JWhite.PA>

*start*
00555 00024 US 
Date:  5-May-83 11:21:49 PDT
From: willie-sue.pa
Subject: infrequent blank cc: field
To: Taft
cc: willie-sue

If one has a message of the form:

"Date: Thu, 5 May 83 09:35 PDT
Sender: Willie-Sue.PA
Subject: testing again
To: Willie-Sue
From: Me <willie-sue>

xxxxx"

And does an Answer, one gets:

"Subject: Re: testing again
In-reply-to: "Your message of Thu, 5 May 83 09:35 PDT"
To: Me <willie-sue>
cc: 

xxx"

Answer does duplicate name supression, but always puts out a cc: field.  It's not worth fixing, to my way of thinking.*start*
01346 00024 US 
Date: Thu, 5 May 83 13:56 PDT
Sender: Taft.PA
From: The Laurel Implementors <LaurelSupport.PA>
Subject: Additional Laurel 6.1 information
To: LaurelAlphaTest^.pa
Reply-To: LaurelSupport.PA

A couple of sources of confusion have turned up.

1. If you try to Run a program that is not on your local disk, Laurel will usually attempt to retrieve a copy from a file server.  This is done under the control of the RunPath entry in your Laurel.profile; ordinarily this looks something like:

	RunPath: [Ivy]<Laurel>

This, of course, is the wrong place for obtaining Laurel programs when you are running the alpha-test version of Laurel.  You may get around this problem in either of two ways.  (1) When you Run a program that is not on your local disk, you can type the complete remote file name into the Run brackets; e.g., [Ivy]<Laurel>6.1T36>Chat.laurel.  (2) You can edit your Laurel.profile to change the RunPath to something like:

	RunPath: [Ivy]<Laurel>6.1T36>

You will have to remember to undo this when Laurel 6.1 is officially released.

2. Basic.laurel will not work properly on an Alto-II if the Mesa microcode installed in the machine is too old.  (The symptom is that it fails to perform arithmetic properly.)  In the next release, a test for correct microcode version will be added.

	The Laurel Implementors

*start*
01156 00024 US 
Date: Thu, 5 May 83 18:29 PDT
From: Taft.PA
Subject: Laurel-runnable programs
To: LaurelAlphaTest^.PA
Reply-to: LaurelSupport.PA

Please remember that many of the new Laurel-runnable programs are unsupported.  The LaurelSupport group has no intention of doing any work on them, even to fix bugs.  If Laurel breaks while you are running one of them, there is no point in reporting it.

To date, Basic and Kal have proven particularly troublesome.  These programs depend on the presence of microcode which is not available on all machines.  If Basic or Kal breaks, it is almost assuredly because of a problem with incorrect microcode.

If Basic does not work on an Alto-II XM, it is probably because obsolete ROM1 Mesa microcode is installed; fixing this requires making a hardware change to the Alto.  If Basic does not work on a Dolphin, it is probably because you don't have the correct Alto/Mesa microcode installed on the disk; if you don't know how to install microcode, consult the person who helped set up your Dolphin originally.

Kal does not work on 64K Altos or on Alto-IIs that don't have ROM1 Mesa microcode installed.

*start*
00819 00024 US 
Date: Fri, 6 May 83 09:50 PDT
From: Taft.PA
Subject: Re: Laurel 6.1 Mail File Format
In-reply-to: "Putz's message of 5 May 1983 6:59 pm PDT (Thursday)"
To: Putz
cc: LaurelSupport, Robson

The change to mail file format is as follows.  When Laurel displays a message for the first time, it makes a decision about where to break lines.  Lines are always broken at spaces.  Laurel turns those spaces into "pseudo-CRs" with character code 240B, that is, space with the high-order bit turned on.  Thus, the original text can be recovered by ignoring the high-order bit of all characters; this is what Laurel does when copying text from a displayed message into the composition window or into a file.

I'll have to let Mike Schroeder tell you what the TOC format is, as I know nothing about it.

	Ed

*start*
00601 00024 US 
Date: Thu, 5 May 83 23:30 PDT
From: Newman.es
Subject: Error Report
To: LaurelSupport.PA

I was scrolling the bottom window while Chat was in the middle of painting into it.

Laurel 6.1T36  Alto II XM (035#014#) with 2K Rom XMcode using XM MDS: 00 Banks: 140000 code: 000051

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003377
Signaller, 000521
IntExceptions, 000223
VirtCM, 000205
VirtCom, 000207
EditorDisplay, 001233
EditorDisplay, 000566
ExecStreamIO, 001444
ExecStreamIO, 001063
Chat, 003026
Chat, 002214
Stack end OurProcess

*start*
00529 00024 US 
Date: Tue, 10 May 83 00:14 EDT
From: Ziobro.Henr
Subject: Suggestion: Allow laurel "run" from command line
To: laurelsupport.pa

	It would be really nice if laurel allowed one to start a "run" command from the command line.  Thus one could have:

EventRFC: laurel/run remotetty 

	Also it would be nice if remotetty could be killed remotely and have laurel exit.  Thus the alto would go into DMT signalling its availablility....

	Is there some guide to write "run" commands for laurel?

//Z\\
Jim Ziobro
*start*
18581 00024 US 
Date: Sun, 15 May 83 16:15 PDT
Sender: Taft.PA
From: The Laurel Implementors <LaurelSupport.PA>
Subject: Second Laurel 6.1 alpha test release
To: LaurelAlphaTest^.pa
Reply-to: LaurelSupport.PA

This is the second alpha test release of Laurel 6.1.  A number of problems discovered in the first release have been fixed (see the end of this message for a summary).  There is a new profile option, DisplayLines, of possible interest to users of 64K Altos; see section 3.  A new Laurel runnable program, Groups, has been introduced; see section 4.

This message contains everything that Laurel 6 users should need to know in order to run Laurel 6.1.  This documentation is being alpha tested as well as the software itself; so please read carefully and report anything you discover that is incorrect, unclear, or missing.

We are aiming for a formal release of Laurel 6.1 on approximately June 1, after which we hope never to change Laurel again.  It is important, therefore, that any remaining serious bugs be discovered and reported before that time.  Please begin using Laurel 6.1T37 as soon as possible.


1. Installing Laurel

This alpha test version of Laurel is called Laurel 6.1T37.  It has been stored in directory <Laurel>6.1T37> on the following file servers:

	Cactus, Erie, Ivy, Oly, Phylum, Rain, RoseBowl

To install the new Laurel, use FTP to retrieve the file <Laurel>6.1T37>Laurel.cm from one of the above servers.  Then Quit to the Executive and issue the command:

	> @Laurel

This will obtain the new version of Laurel itself, as well as updated versions of any Laurel-runnable programs already present on your disk.  When it is finished, it will start Laurel.

Dolphin users who also run Smalltalk-80 should note item 20 in section 5.


2. Changes to message format

Laurel now supports the new ARPA header standard (RFC 822).  This means that Laurel understands only those messages conforming to the standard, and will allow you to send only messages that conform.  Fortunately, the new format is nearly a subset of the old one, and is identical in most cases that matter.  The main differences to pay attention to are as follows:

-- All name-containing fields are now required to contain real mailbox names; formerly it was permissible for the From field to consist entirely of arbitrary text if a Sender field was present.  That is,

	From: The Laurel Implementors

is no longer legal; an actual mailbox must be named, e.g.,

	From: The Laurel Implementors <LaurelSupport.PA>

It continues to be true that a Sender field must be present if the sender's name differs from the mailbox named in the From field; Laurel will insert a Sender field automatically when needed.

-- The syntax for ARPA recipient names is generalized to "recipient@domain", where the domain is a hierarchical name whose root is usually "ARPA".  For example, "Joe.Blow@CMUA.ARPA" designates the recipient named Joe.Blow in the CMUA sub-domain of the ARPA domain.  Currently this naming scheme maps more-or-less directly onto the old "user@host" scheme; but it is evolving in the direction of a more general hierarchical name structure that resembles (not accidentally) the ones used in the Xerox Grapevine and Clearinghouse systems.

One restriction you should be aware of is that the local-part of ARPA recipient names (the part to the left of the "@") may not contain spaces or certain other punctuation characters unless they are quoted.  If Laurel complains about the syntax of an ARPA recipient name, try putting quotes around the local-part; for example:

	To: "Joe Blow"@CMUA.ARPA

-- The word " at " is no longer equivalent to "@" in ARPA recipient names.

-- The new Laurel has no special knowledge of ARPA mailbox names except that appearance of "@" in a name causes it to be treated as a member of the AG registry (AG stands for "ARPA Gateway", but you never need to specify it).  Furthermore, the ARPA host name PARC-MAXC is no longer treated specially.  This is in order to decouple Laurel from any future changes to ARPA name syntax or to the way in which the Xerox and ARPA internets are connected.

This means that it's no longer necessary or even desirable to append
"@PARC-MAXC" to Xerox R-Names in the headers of messages you send (even in the From or Reply-to field).  Doing so may result in messages taking unnecessary hops through Maxc.

A consequence of this change is that the Answer command may be confused by formerly legal headers that depended on ARPA name minimization algorithms, which have been eliminated.  For example, the header:

	From: Brotz@PARC-MAXC
	To: Foo

will be answered as:

	To: Brotz@PARC-MAXC
	cc: Foo.AG

since the new parser understands that the sender was in the AG registry, and therefore Foo must have been shorthand for Foo.AG.  Such cases should be rare, and will disappear altogether when everyone is using new versions of Laurel, Hardy, etc.

-- The syntax for specifying a private distribution list -- "@FileName" -- has been changed.  This was never part of the old ARPA standard, and unfortunately it conflicts with the syntax for specifying source routing information in the new standard.

The new way to designate a private distribution list employs the ARPA standard's "group" syntax.  Instead of writing:

	To: @MyFriends.dl

you should write either:

	To: MyFriends.dl: ;
 or:	To: MyFriends.dl: name1, name2, ... nameN;

The first form leaves the members of the list unspecified in the header.  When you send the message, Laurel will expand MyFriends.dl to obtain the names of the recipients (but won't modify the message header).

The second form lists the individual members.  This list, of course, may be easily filled in by expanding the name of the list, using the COM-G command.  Sending a message to recipients named in this way does not cause any distribution list expansion, since the names are already listed in the header.

If the name of the private distribution list contains special characters (brackets, commas, and a few others) then it must be quoted; e.g.,

	To: "[Ivy]<MyName>MyFriends.dl": ;

Note that this change applies only to PRIVATE distribution lists.  Public lists, e.g., MesaUsers^.pa, will continue to be treated as ordinary names.

-- There are also changes in certain fields that are generated automatically by Laurel, e.g., Date and In-reply-to.  Laurel has been changed to conform to the new standard.


3. Other functional changes

-- CR insertion in Deliver.  Laurel 6.1 no longer automatically inserts carriage returns in messages being sent.  The only CRs present will be the ones you put in explicitly.  This enables messages to be properly formatted when displayed in windows of various widths, which is important in view of the increasing diversity of mail handling programs.

Messages sent to ARPA recipients will have CRs inserted automatically as they pass through the Xerox-to-ARPA gateway on Maxc; this is necessary because a number of ARPA mail programs are incapable of properly displaying messages containing arbitrary-length "lines".  If you are sure that the recipients will not object, you may defeat the automatic CR insertion by including the field:

	Line-fold: No

somewhere in the header of the message.

-- Blue button New mail.  Ordinarily, the "New mail" command retrieves all messages pending in your in-box as a single, indivisible operation.  If there is more mail in your in-box than will fit on your local disk (as sometimes occurs if you haven't run Laurel for a long time), then "New mail" will fail to retrieve any mail at all.  If you encounter this situation, click "New mail" with the blue (right) button.  This will retrieve messages and delete them from the in-box one at a time until either your in-box is empty or your local disk is full, at which point it will stop and let you process the messages received so far.  This method of retrieving new mail is much slower than the normal method, so you should use it only if you have to.  (Fine point: this works for in-boxes stored on Grapevine servers, but not ones on IFSs or Maxc.)

-- Mail file format.  Laurel now inserts special characters into mail files to enable scrolling and display of messages to be performed substantially faster.  This means that it is no longer reasonable to read mail files using Bravo or other programs.  The correct way to move messages into a file that other programs can read is to copy them into the composition window and then store them with the Put command.

-- Operations on deleted messages.  The Hardcopy and Forward commands (but not Move to) now operate on all selected messages without regard to whether or not they have been deleted.

-- Performance.  The internals of Laurel have been extensively reorganized, mainly to enable it to serve as the foundation for the Cholla process control system.  Consequently, the performance of Laurel 6.1 is perceptibly different from that of Laurel 6.  On machines with extended memory (most Alto-IIs and all Dolphins and Dorados), Laurel 6.1's performance is generally better than Laurel 6's.  But on machines with only 64K words of memory (all Alto-Is and certain early Alto-IIs), performance is somewhat poorer.  We have recently expended considerable effort making Laurel 6.1 run better on 64K machines, and we believe it is usable even though not wonderful.

A new Laurel.profile option, DisplayLines, has been introduced.  It determines the height of the display in text lines; the default value is "DisplayLines: 60".  On a 64K Alto, decreasing this by even a few lines improves performance noticeably, because decreasing the display area makes more memory available for other purposes and thereby reduces the amount of disk swapping activity.


4. Changes to Laurel runnable programs

There have been some changes (mostly additions) to the programs you can invoke with Laurel's Run command.  These programs are available from the same directory from which you obtained Laurel itself; all have the extension ".laurel".

If you try to Run a program that is not on your local disk, Laurel will usually attempt to retrieve a copy from a file server.  This is done under the control of the RunPath entry in your Laurel.profile; ordinarily this looks something like:

	RunPath: [Ivy]<Laurel>

This, of course, is the wrong place for obtaining Laurel programs when you are running the alpha test version of Laurel.  You may get around this problem in either of two ways.  (1) When you Run a program that is not on your local disk, you can type the complete remote file name into the Run brackets; e.g., [Ivy]<Laurel>6.1T37>Chat.laurel.  (2) You can edit your Laurel.profile to change the RunPath to something like:

	RunPath: [Ivy]<Laurel>6.1T37>

You will have to remember to undo this when Laurel 6.1 is officially released.

The following programs are functionally the same as the ones for Laurel 6, though you will still need to obtain new versions for 6.1 (this is done automatically by the installation procedure in Laurel.cm).

	Chat.laurel
	Files.laurel
	MailFileScavenger.laurel
	Maintain.laurel
	PupHacks.laurel

The program InsertMail.laurel has been renamed Insert.laurel, but is otherwise the same.  The program Print.laurel has been withdrawn.

The following programs are new.  This is the sole documentation.

-- Extract.laurel behaves like SearchMail.laurel except that it copies the matching text into the composed message.  With an imaginative search specification, this program can generate amazing reports and summaries.

-- LineSort.laurel sorts a file full of text lines into order.  It requests an input file and an output file.  It also asks whether to sort by "first words" or by "markers".  First words means that the first word of each line is used as the sort key.  Markers means that LineSort searches each line for a piece of text enclosed in 
brackets (control-A and control-B, perhaps entered by means of COM-B), and uses that text as the sort key.  If a line does not contain brackets, the first word is used.

-- Replace.laurel is like Insert.laurel except that it replaces the message(s) currently selected in the table of contents rather than inserting after them.

The following new programs are unsupported and are released on a "use at your own risk" basis.  They have not been as carefully polished or as well tested as the supported software.  Some of them may not work on 64K Altos.  These programs are being made available in the hope that some people may find them useful.  LaurelSupport is not maintaining them, so don't bother to report problems with them.

-- Basic.laurel is a fairly complete implementation of the Basic language.  There is no documentation other than the on-line help message (invoked by the Help command); but if you are already familiar with Basic you should have no difficulty using this one.

Basic is too large to run on a 64K Alto.  If you find that Basic has trouble doing arithmetic, it's probably because floating point operations aren't being executed properly by your machine.  On an Alto-II XM, this occurs if obsolete ROM1 Mesa microcode is installed; fixing this requires making a hardware change to the Alto.  On a Dolphin, this occurs if you don't have the correct Alto/Mesa microcode installed on the disk; if you don't know how to install microcode, consult the person who helped set up your Dolphin originally.

-- Flush.laurel retrieves and discards the contents of your in-box, leaving it empty.  This is useful primarily for administrators to clean up after users who never read their mail.

-- Groups.laurel performs set union, subtraction, intersection, and closure expansion on both Grapevine groups and private distribution lists.  Documentation may be found in file <Laurel>6.1T37>Groups.doc.  (This program was recently contributed by Ron <Newman.es>.)

-- Kal.laurel displays a pretty kaleidoscope pattern in the displayed message window.  Kal does not work on 64K Altos.

-- NameMatch.laurel searches the Grapevine data base (slowly!) for R-Names matching some pattern.

-- SortMail.laurel prompts for an output file name (you must specify the ".mail" extension explicitly), and produces a version of Laurel's current mail file (the one named in the Mail file brackets) sorted by date.

-- RemoteTTY.laurel enables you to access your Laurel from any terminal in the Research Internet, including a home terminal dialled-in to a DLS.  To set up Laurel to be accessed remotely, simply run RemoteTTY; it will turn the screen blank except for a little picture of a telephone.  At this point you may connect to your machine (by name or internet address) from the DLS or from any machine running Chat.

When you connect, you are first required to type your password (terminated by ESC).  You may now issue commands to a simple command interpreter (type "?" for a summary).  You have complete access to all the mail files on your disk; and you may retrieve messages from your in-box and send new messages.

The one thing that isn't entirely obvious is how to send messages.  At all times there exists a "composed message", just as in regular Laurel.  To modify it, you invoke an editor with the "E" command.  This editor is quite different from Laurel's, and is patterned after Tenex TECO; if you're not familiar with TECO, you'd better get advice from someone who is.  To leave the editor, type "EX" followed by ESC.  You may now use the "S" command to send the composed message (the same as Laurel's "Deliver" command).

When you return to your machine and wish to regain local control, type your password followed by ESC.  RemoteTTY will terminate and the regular Laurel display will reappear.

-- LocalTTY.laurel is a "local" version of RemoteTTY.  It enables you to practice with RemoteTTY's facilities without leaving your own machine.


5. Disposition of bugs reported in Laurel 6.1T36

  1. REJECTED.  Display never appears; 3K RAM, 256K memory (Pellar.es).  Unreproducible, probably hardware problem.

  2. FIXED.  Kal doesn't work on non-XMesa Altos.  Added test at startup.

  3. FIXED.  Basic requires latest microcode (floating point).  Added test at startup.

  4. FIXED.  Changing mail file name from RemoteTTY doesn't refresh Mail file brackets.

  5. FIXED.  Insert leaves hourglass in cursor (Replace also).

  6. FIXED.  ForwardSpaceWord past end of composed message crashes Laurel; end test incorrect.

  7. FIXED.  E ESC to LocalTTY editor crashes it.

  8. FIXED.  Disk full and disk error crash Laurel in some situations (e.g., "Move to"), whereas they were caught and handled gracefully in Laurel 6.

  9. FIXED.  Hardcopy sometimes hangs on 64K Alto -- needs another VM buffer.  Added code to release VM buffers for message objects when any menu command is issued.

  10. FIXED.  Explicit remote Run doesn't always default extension to .laurel.

  11. FIXED.  Bogus date in SortMail crashes it.

  12. FIXED.  Free disk page count updated too often -- really slows things down.

  13. FIXED.  ArpaGateway registry should be treated the same as ARPA.

  14. REJECTED.  LocalTTY discards typescript at Quit time.  This is a feature: it's preserving the composed message left behind by the TTY editor.

  15. FIXED.  Editing is too slow on 64K Altos.  Improved somewhat by shrinking VM buffer pool.  Added DisplayLines profile option for shrinking bit map.

  16. FIXED. Thumbing TOC of empty mail file hangs Laurel.

  17. FIXED. Grapevine operations slow (esp. Maintain).  Enlarged routing cache.

  18. FIXED.  Laurel occasionally trashes mail files on Dolphins.  Changed LaurelByteBlt not to use BITBLT on Dolphin because this use of it apparently does not work.

  19. OPEN.  Scrolling composition window while runnable program is putting text into it occasionally breaks Laurel.  Suspect inadequate synchronization; probably too hard to fix.

  20. OPEN.  Running Laurel immediately after quitting from Smalltalk-80 on Dolphins doesn't work.  Workaround: before running Laurel, either boot your Dolphin or issue the command "Partition n" where n is the number of the partition you are currently using (1 or 2).

  21. OPEN.  Some header (presumably malformed) results in uncaught csD.EndOfStream from header parser.  Need more information.


6. Reporting problems

If you encounter any problems with Laurel 6.1 or with the Laurel runnable programs that are supported, please notify LaurelSupport.PA as usual.  You should mention that you are running Laurel 6.1T37 (bug reports generated automatically by Laurel contain this information already).

	The Laurel Implementors

*start*
00373 00024 US 
Date: Mon, 16 May 83 17:26 PDT
From: Trow.pa
Subject: Error message
To: LaurelSupport
cc: Trow

I got this error message when executing a Copy to an existing file: "Put will overwrite existing file."  Since Copy, not Put, was invoked, it seems to me that the error message should say "Copy will .... ".  I think this could confuse some users.

Jay

*start*
01383 00024 US 
Date: Tue, 17 May 83 09:54 PDT
From: Thomka.ES
Subject: Are you open for suggestions?
To: LaurelSupport.PA
cc: Taft.pa

There are times that I would like to see some extra features in Laurel editing.  For example, while I am sure you are aware of the ( [ { < - " and ' features that will enclose highlighted text in (paren's) [brackets] {braces} <l.t.g.t> -------------------
dashes-------------------
 "dbl quotes" and 'single quotes'

an additional function I would like to see is

, (comma) to insert a comma at the beginning of any highlighted text, this is one of the single most used editing items I do.  I realize that any Insert of a comma can be duplicated by the ESC key, but I find that while editing a message I may not be doing consecutive comma inserts.

. (period) to add a period at the end of any highlighted text.  For similar reasons as the above mentioned comma.

/ (slash) to enclose highlighted text with /slashes/.

\ (backslash) to enclose highlighted text with \backslashes\.

c (cee) to case change all highlighted text, all lowercase to upper, and all uppercase to lower.

C (shift cee) to capitalize all highlighted text.

n (en) to iNitial capitalize all highlighted alphabetical characters that follow a `space'.

w (double yu) to initial capitalize all highlighted alphabetical characters that follow a 'period space'.


	Chuck
*start*
00742 00024 US 
Date: Tue, 17 May 83 17:09 PDT
From: Taft.PA
Subject: Miscellaneous news
To: LaurelAlphaTest^.pa
Reply-to: LaurelSupport.PA

1. The Laurel alpha test software is no longer available on the Phylum file server.  Users who would have obtained software from Phylum should use Ivy instead.

2. The Laurel runnable program Print.laurel has been resurrected, thanks to efforts by Ken Pier.  It enables you to make hardcopy of files on your local disk or on a file server, and handles existing Press, plain-text, and Bravo files.  Print.laurel may be obtained from directory <Laurel>6.1T37> on the same file server from which you obtained Laurel.  Documentation is contained in file Print.doc, available from the same place.

*start*
00910 00024 US 
Date: Wed, 25 May 83 10:01 PDT
From: Taft.PA
Subject: Laurel 6.1 news
To: LaurelAlphaTest^.pa
Reply-to: LaurelSupport.PA

Laurel 6.1T37 has proven to be a good deal more reliable than Laurel 6.1T36 was.  A few bugs have turned up and been fixed; but most of the 125 or so alpha testers appear not to be encountering any difficulties.

There is one lingering problem which causes unreliable behavior on Dolphins.  This has been determined to be a problem in the Dolphin hardware or microcode rather than in Laurel itself; but the exact cause has not yet been discovered.

The formal Laurel 6.1 release will be delayed until this problem is solved.  We did not originally anticipate having another alpha test release; but it is now likely that there will be a Laurel 6.1T38 for you to try out, probably some time next week.

Thank you for your helpful reports.

	The Laurel Implementors

*start*
05160 00024 US 
Date: Sat, 28 May 83 14:38 PDT
Sender: Taft.PA
From: The Laurel Implementors <LaurelSupport.PA>
Subject: Third Laurel 6.1 alpha test release
To: LaurelAlphaTest^.pa
Reply-to: LaurelSupport.PA

This is the third alpha test release of Laurel 6.1.  A serious problem causing unreliable behavior on Dolphins has been found and fixed, as well as a small number of minor problems.  The Laurel runnable program Print.laurel has been resuscitated.

This message describes only changes since the previous alpha test release.

If no serious problems are discovered, the formal release of Laurel 6.1 will take place on Monday, June 6, after which we hope never to change Laurel again.


Installing Laurel

This alpha test version of Laurel is called Laurel 6.1T38.  It has been stored in directory <Laurel>6.1T38> on the following file servers:

	Cactus, Erie, Ivy, Oly, Rain, RoseBowl

To install the new Laurel, use FTP to retrieve the file <Laurel>6.1T38>Laurel.cm from one of the above servers.  Then Quit to the Executive and issue the command:

	> @Laurel.cm

This will obtain the new version of Laurel itself, as well as updated versions of any Laurel-runnable programs already present on your disk.  When it is finished, it will start Laurel.


Changes to Laurel runnable programs

-- Print.laurel generates hardcopy of files on your local disk or on a file server; the file may be an existing Press file, plain-text file, or Bravo file.  Documentation may be found in file <Laurel>6.1T38>Print.doc.  (This program was contributed by Ken <Pier.pa>.)


Disposition of bugs reported prior to Laurel 6.1T38

  1. REJECTED.  Display never appears; 3K RAM, 256K memory (Pellar.es).  Unreproducible, probably hardware problem.

  2. FIXED.  Kal doesn't work on non-XMesa Altos.  Added test at startup.

  3. FIXED.  Basic requires latest microcode (floating point).  Added test at startup.

  4. FIXED.  Changing mail file name from RemoteTTY doesn't refresh Mail file brackets.

  5. FIXED.  Insert leaves hourglass in cursor (Replace also).

  6. FIXED.  ForwardSpaceWord past end of composed message crashes Laurel; end test incorrect.

  7. FIXED.  E ESC to LocalTTY editor crashes it.

  8. FIXED.  Disk full and disk error crash Laurel in some situations (e.g., "Move to"), whereas they were caught and handled gracefully in Laurel 6.

  9. FIXED.  Hardcopy sometimes hangs on 64K Alto -- needs another VM buffer.  Added code to release VM buffers for message objects when any menu command is issued.

  10. FIXED.  Explicit remote Run doesn't always default extension to .laurel.

  11. FIXED.  Bogus date in SortMail crashes it.

  12. FIXED.  Free disk page count updated too often -- really slows things down.

  13. FIXED.  ArpaGateway registry should be treated the same as ARPA.

  14. REJECTED.  LocalTTY discards typescript at Quit time.  This is a feature: it's preserving the composed message left behind by the TTY editor.

  15. FIXED.  Editing is too slow on 64K Altos.  Improved somewhat by shrinking VM buffer pool.  Added DisplayLines profile option for shrinking bit map.

  16. FIXED. Thumbing TOC of empty mail file hangs Laurel.

  17. FIXED. Grapevine operations slow (esp. Maintain).  Enlarged routing cache.

  18. FIXED.  Laurel occasionally trashes mail files on Dolphins.  Changed LaurelByteBlt not to use BITBLT on Dolphin because this use of it apparently does not work.

  19. OPEN.  Scrolling composition window while runnable program is putting text into it occasionally breaks Laurel.  Suspect inadequate synchronization; probably too hard to fix.

  20. FIXED.  Running Laurel immediately after quitting from Smalltalk-80 on Dolphins doesn't work.

  21. FIXED.  Hitting end-of-file while parsing mail stamp results in uncaught csD.EndOfStream.

  22. FIXED.  Blue button New mail doesn't index the messages if disk space is exhausted during retrieval.

  23. FIXED.  Hardcopy and Forward operate on all selected messages even if they are deleted.  This is a change from Laurel 6.  Nobody knows why the change was made.  Changed it back.

  24. FIXED.  Laurel still garbles mail files on Dolphins (16-word blocks at 16-word boundaries).  Long-standing Alto/Mesa microcode bug -- programmed around it.

  25. REJECTED.  NetPrint.laurel (not maintained by LaurelSupport) no longer runs because Laurel's GFT has insufficient extra entries.  Enlarging it at all would cost another page of resident storage, which is bad for 64K machines.

  26. FIXED.  Attempting to move deleted message to nonexistent mail file causes Laurel to crash.

  27. OPEN.  RemoteTTY and LocalTTY do not keep the display consistent with the state of the mail file.  This is hard to fix.

  28. FIXED.  Replace, unlike Insert, leaves the composed message marked as having been edited since last saved.



Reporting problems

If you encounter any problems with Laurel 6.1 or with the Laurel runnable programs that are supported, please notify LaurelSupport.PA as usual.  You should mention that you are running Laurel 6.1T38 (bug reports generated automatically by Laurel contain this information already).

	The Laurel Implementors

*start*
00951 00024 US 
Date: Sat, 28 May 83 16:15 PDT
From: Stiles.es
Subject: Re: Third Laurel 6.1 alpha test release
In-reply-to: "Taft.PA's message of Sat, 28 May 83 14:38 PDT"
To: LaurelSupport.PA
cc: Stiles

I have encountered a couple more full disk type problems, still present in 6.1T38:

1.	With ~12 free disk pages left I went to maintain.laurel and did a Type Details on LaurelAlphaTest^.pa; this was large enough to go to zero pages and cause an uncaught signal 33201B with arg. 177777B.  I think when I clicked Red + Blue per the instructions I went back to Alto Executive.

2.	With 0 pages calling Laurel/c with mail pending get message:  System error encountered.  Laurel cannot proceed. Click Yellow for automatic error reporting.  However, when yellow is clicked I hear disk movement one time, then apparent death occurs:  Time report doesn't increment; possibly the cursor still tracks the mouse.  Had to reboot.

Bill <Stiles.es>

*start*
00946 00024 US 
Date: Sun, 5 Jun 83 15:22 PDT
From: Taft.PA
Subject: End of Laurel 6.1 alpha test
To: LaurelAlphaTest^.pa
Reply-to: LaurelSupport.pa

The alpha test of Laurel 6.1 has ended.  Laurel 6.1 is now in the process of being installed on file servers, and a general announcement will be made when this is completed (we hope within the next day).  When you receive the Laurel 6.1 release announcement, please follow the instructions given there -- they apply to you too.

A couple of bugs found in Laurel 6.1T38 were fixed in Laurel 6.1, notably one that would occasionally cause Laurel to hang (with an hourglass in the cursor) shortly after startup.  There were no other changes.

Your help in testing the new version of Laurel has been very valuable.  Only through extensive use by a relatively large and varied community can a program as complex as Laurel be adequately tested.  Thank you very much.

	The Laurel Implementors

*start*
04605 00024 US 
Date: Mon, 6 Jun 83 13:50 PDT
Sender: Taft.PA
From: The Laurel Implementors <LaurelSupport.PA>
Subject:  Laurel 6.1 is released 
To: AllMailUsers.dl: ;
Reply-to: LaurelSupport.PA

A new version of Laurel, version 6.1, has completed a month of alpha testing by approximately 125 users, and is now available for general use.  Laurel 6.1 entirely replaces Laurel 6.  If you use Laurel, we request that you convert to Laurel 6.1 at this time.

Why a new Laurel?  After all, Laurel 6 has been around for about two years and has proven to be quite satisfactory for countless hundreds of users.  There are several reasons, the most important of which are:

1. We have adopted the new ARPA header standard for all messages in the Research Internet.  This is a considerable simplification over the old standard; and as part of this change we have taken the opportunity to clean up the treatment of ARPA names within the mail system so as to better insulate us from future changes in the ARPA standards.  The version of Hardy included in release 10 of the Mesa Development Environment already supports the new standard; bringing Laurel into conformity will make the exchange of messages between Laurel and Hardy users work more smoothly.

2. There are several serious bugs in Laurel 6.  For example, there are certain messages whose receipt will cause Laurel to crash.  And there is a problem that makes Laurel unusable on an Ethernet whose network number is greater than 126 octal; this restriction has put a troublesome constraint on the configuration of the Research Internet.

3. The departure of Doug Brotz, who was the principal person actively developing Laurel for the past two years, gives us an opportunity to wrap up the Laurel project cleanly and permanently.  While we will attend to any catastrophic problems that turn up, we are not planning any further development.

Laurel 6.1 is functionally nearly identical to Laurel 6, though internally it is quite different.  There is also an expanded collection of programs that may be invoked with Laurel's Run command.


-- Installing Laurel --

All the files needed to run Laurel are stored in the <Laurel> directory on the following file servers:

	Aztec, Cactus, Erie, Ice, Isis, Ivy, Jaws, Oly, Rain,
	RoseBowl, Urchin, Walden

To install the new Laurel, first make sure you have at least 120 free pages on your disk (the new Laurel is larger than the old, and the installation procedure also retrieves a Laurel 6.1 documentation file to your disk).  Use FTP to retrieve the file <Laurel>Laurel.cm from one of the above servers.  Then Quit to the Executive and issue the command:

	> @Laurel.cm

This will obtain the new version of Laurel itself, as well as updated versions of any Laurel-runnable programs already present on your disk.  When it is finished, it will start Laurel.  The current mail file will contain a series of messages documenting the changes in Laurel 6.1 (see below).

Note to alpha testers: if you have been running one of the Laurel 6.1T3x test versions, you should convert to Laurel 6.1 at this time.  Thank you for your help in shaking down the new software.

Note to Cholla users: there will be a release of Cholla that corresponds to Laurel 6.1, but it is not ready yet.  You should await a separate Cholla announcement.


-- Documentation --

For normal use, Laurel 6.1's user interface is nearly identical to Laurel 6's; so you should have no difficulty getting started.  However, there are some important changes that you should be aware of, especially if you use private distribution lists or correspond with ARPA users.

Complete documentation is stored in the mail file <Laurel>Laurel61.mail on any of the above-mentioned file servers.  We suggest that you read this documentation at your earliest convenience.  The installation procedure retrieves this file to your disk and starts Laurel displaying it.  If you would like to have hardcopy, select all the messages in the table of contents and click the Hardcopy command.  When you are finished with these messages, you may delete them.


-- Reporting problems --

If you encounter any problems with Laurel 6.1 or with the Laurel runnable programs that are supported, please notify LaurelSupport.PA as usual.  You should mention that you are running Laurel 6.1; we will no longer respond to reports about Laurel 6.  Bug reports generated automatically by Laurel contain this version information already.

	The Laurel Implementors

	   Roy Levin <Levin.PA>
	   Mike Schroeder <Schroeder.PA>
	   Ed Taft <Taft.PA>
	   John White <JWhite.PA>

*start*
00829 00024 US 
Date: Tue, 7 Jun 83 10:19 PDT
From: McBain.es
Subject: Error Report
To: LaurelSupport.PA

I was running LocalTTy, went into the E(dit) function and then typed <some letter> <ESC>.  Sorry I can't remember what the letter was as I was just sort of fiddling around.	/Dwight

Laurel 6.1  Alto II XM (055#227#) with 3K Ram XMcode using XM MDS: 00 Banks: 140000 code: 000051

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
VirtCM, 000205
VirtCom, 000207
LaurelTTYEditor, 003050
LaurelTTYEditor, 014700
LaurelTTYEditor, 001260
LaurelTTYEditor, 000614
LaurelTTYInterface, 002024
LocalTTYDriver, 000270
LocalTTYDriver, 000115
Modules, 000277
Modules, 000157
ExecSS, 000754
ExecSS, 000436
ExecSS, 000301
Stack end OurProcess

*start*
00761 00024 US 
Date: Tue, 7 Jun 83 12:39 PDT
From: MKrigel.ES
Subject: Error Report
To: LaurelSupport.PA

I don't remember if you said whether Laurel - Basic is being supported. 

If it is, all I did was type:  Auto 10,10 and it went KA-BLUEY.

If there is to be no support, then kindly ignore this message.


Thanks,

Marc

Laurel 6.1  Alto II XM (055#132#) with 3K Ram XMcode using XM MDS: 00 Banks: 170000 code: 000051

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
VirtCM, 000205
VirtCom, 000207
BasicInterpA, 010200
BasicInterpA, 014044
BasicControl, 000332
Modules, 000277
Modules, 000157
ExecSS, 000754
ExecSS, 000436
ExecSS, 000301
Stack end OurProcess

*start*
03184 00024 US 
Date: Wed, 8 Jun 83 12:15 PDT
Sender: Taft.PA
From: LaurelSupport.PA
Subject: Laurel 6.1 on Alto-II
To: AllMailUsers.dl: ;
Reply-to: LaurelSupport.PA

If you run Laurel on an Alto-II, please read on; otherwise disregard this message.  This is information of interest to a large number of Laurel users, but we have no way of identifying who they are.

This is an elaboration on the "Performance" section of the "Other functional changes" message in the Laurel 6.1 documentation.  Laurel 6.1 is much more sensitive than Laurel 6 to the amount of memory present in the machine it is running on.  The performance of Laurel 6.1 on a 64K Alto (any Alto-I or certain early Alto-IIs) is not as good as Laurel 6's.  We are sorry, but there is no practical way of improving this state of affairs; 64K words are just not quite enough for a program of Laurel's size and complexity.  If you have a 64K Alto and you are dissatisfied with the performance of Laurel 6.1, you should experiment with changing the DisplayLines parameter, as described in the documentation.

A number of users have reported that Laurel 6.1 is significantly slower than Laurel 6 even when running on Alto-IIs that are believed to have extended memory (more than 64K).  This is almost certainly due to the way in which the Alto is configured; and there IS something you can do about it.

In order for Laurel (and other Mesa programs) to take advantage of extended memory, not only must there actually be more than 64K of memory, but also the correct "extended memory Mesa microcode" must be installed in the machine's second bank of microinstruction PROMs.  (Or the machine must have a 3K RAM board; but there aren't very many of those.)

In order to determine your machine's configuration, you should use Laurel's Run command to invoke the program What.laurel, which was included as part of the Laurel release.  It will display something like this:

  memConfig = [AltoType: AltoIIXM, xmMicroCode: FALSE, useXM: FALSE,
  controlStore: Ram0, banks: 100000B, mesaMicrocodeVersion: 41];
  disC.bitmapInMDS = TRUE; dsD.machineFlavor = alto;

If AltoType is AltoIIXM then your machine has extended memory.  However, if xmMicroCode is FALSE then the extended memory Mesa microcode is not installed and Laurel cannot take advantage of the extended memory.

If your Alto is configured like this, you should ask your hardware support staff to install Mesa6 PROMs (or XMesa5 PROMs) in the ROM1 positions on your Alto's control board, and to exchange the SW1K and SW2K PROMs so that SW2K is in position 51.  When this is done correctly, What.laurel will report:

  memConfig = [AltoType: AltoIIXM, xmMicroCode: TRUE, useXM: TRUE,
  controlStore: RamandRom, banks: 140000B, mesaMicrocodeVersion: 41];
  disC.bitmapInMDS = FALSE; dsD.machineFlavor = alto;

(The "banks" and "mesaMicrocodeVersion" may be different than given here, but the others will be exactly as shown.)

By doing this, you will be rewarded with very substantially improved performance when running Laurel (and other Mesa programs).  Nearly everything will work faster, and the incidence of dropped keystrokes will be reduced or eliminated.

*start*
00850 00024 US 
Date: Wed, 8 Jun 83 10:37 PDT
From: SStrasen.es
Subject: Problem Report
To: LaurelSupport.PA
cc: McBain, SStrasen

I have encountered a "System error. Laurel cannot proceed" message 
in the following situation with both the Alpha Test and released
Laurel 6.1 programs:
1. Begin by displaying a message in  window two
2. Then begin editing a message in window three
3. Select a new message to be displayed in window two
4. Attempt to dispaly the new message and return to editing
the message in window three.
In both cases I have invoked the Laurel eror recovery procedure
but have aborted it after a couple of minutes with no response.
A side effect under released Laurel 6.1 is that the mail file I was
accessing was left "in use" and hence inaccessible. Can you help
me to recover from this condition?
Thanks,
Steve Strasen
*start*
00996 00024 US 
Date: Wed, 8 Jun 83 16:55 PDT
From: SStrasen.es
Subject: Re: Problem Report
In-reply-to: "Taft.PA's message of Wed, 8 Jun 83 11:10 PDT"
To: Taft.PA
cc: SStrasen, LaurelSupport.PA, McBain

Thank you for your quick response to my problem report.
1. The "system error" problem was definitely not due to lack of disk space.
I currently have almost 2500 free pages.
2. The problem with the mail file "in use" went away with no action on
my part after a couple of hours. Your guess is as good as (actually, a whole
lot better than) mine as to what happened. It looked like a classic "file not
closed" problem but I do not know anything about Alto O/S file management.
3. I was also not able to duplicate the problem by a straightforward 
repetition of the described steps. One clue might be that I think I 
was answering a message and at the same time trying to get the same
message on the second display. If it occurs again I will try to get more
debug data and let you know. 
*start*
00740 00024 US 
Date: Thu, 9 Jun 83 08:22 PDT
From: RonFreeman.ES
Subject: Error Report
To: LaurelSupport.PA

I was running maintain (adding myself to a DL) and had told it to quit.  Then I immediately bugged display to read my latest mail message.  Possibly I should have waited for maintain to totally quit before I selected Display.

Laurel 6.1  Alto II (055#204#) with Ram only MDS: 00 Banks: 100000 code: 000051

Signal 036401 in VMPageOps
msg 177777, msg^ 000000 077400 077400 077400

BackStop, 003405
Signaller, 000521
Signaller, 001102
VMPageOps, 000267
VMPageOps, 000065
VirtCom, 000437
VirtSS, 001475
IntTrackMain, 001702
IntTrackMain, 001252
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
01003 00024 US 
Date: Thu, 9 Jun 83 11:38 PDT
From: PNeumeister.es
Subject: BIG Problem With Single Message Retrieval
To: LaurelSupport.pa, LaurelImplementors.pa
cc:  PNeumeister

Hi, I'm using Laurel 6.1T38 and used single msg. retrieval and filled up my disk.  Not all of the messages were indexed.  I deleted all but two of the messages, and bugged active mail (to get the rest of the file) and then Laurel hung in the hourglass for about 30 minutes.  I rebooted.  Laurel said no matter what that active mail was currently in use, but would show no index (so I couldn't delete any msgs).  Then, when I tried to quit, it got a recursive error, and told me to report to you an uncaught signal "036005 in [blank.. no module name]"

After deleting another file (with the exec) I was able to rebuild my active.mail.

I would really suggest NOT going all the way down to 0 pages when doing single message retrieval.. Can't you watch diskdescriptor and see when you're down to, say, 10 pages?
Paul

*start*
01053 00024 US 
Date: Thu, 9 Jun 83 17:11 PDT
From: Taft.PA
Subject: Re: BIG Problem With Single Message Retrieval
In-reply-to: "PNeumeister.es's message of Thu, 9 Jun 83 11:38 PDT"
To: PNeumeister.es
cc: LaurelSupport

It seems this feature wasn't very well designed.  What should really happen is that Laurel should index each message before checkpointing it to the mail file and deleting the message from the inbox.  In fact what happens is that messages get retrieved until the disk is full and then the indexing is done.  The indexing succeeds only if the table of contents will fit in the disk space made available by deleting the message that was being retrieved when the disk overflowed.

It's not possible to predict when disk space will be exhausted, since the page count in the disk descriptor is only a hint.  The algorithm outlined above is the only one I can think of that would work.  I probably would have changed the code to use that algorithm if I had seen how it's currently being done.  But it's too late now.....

	Ed Taft

*start*
00853 00024 US 
Date: Fri, 10 Jun 83 10:51 PDT
From: Rumph.eos
Subject: Error Report
To: LaurelSupport.PA

I was using the LocalTTY editor.  I typed "h<ESC>", and laurel bombed immediately.  (I expect that the editor's command parser fell off the end expecting something after the "h".  I had just deleted the previous editing with the command "0jhkht<ESC>".

Laurel 6.1  Dolphin (012#340#) with XMcode using XM MDS: 00 Banks: 177777

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
VirtCM, 000205
VirtCom, 000207
LaurelTTYEditor, 015053
LaurelTTYEditor, 001257
LaurelTTYEditor, 000614
LaurelTTYInterface, 002024
LocalTTYDriver, 000267
LocalTTYDriver, 000115
Modules, 000277
Modules, 000157
ExecSS, 000753
ExecSS, 000436
ExecSS, 000301
Stack end OurProcess

*start*
00579 00024 US 
Date: Mon, 13 Jun 83 14:47 EDT
From: SHEN.WBST
Subject: Error Report
To: LaurelSupport.PA

I was using NetPrint to print a Bravo file. Everything seemed to be working before laurel quit.

Laurel 6.1  Alto II XM (124#066#) with 3K Ram XMcode using XM MDS: 00 Banks: 170000 code: 000051

Signal 004605 in Modules
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
Modules, 000635
Modules, 001261
PupSockets, 000143
PupPktCool, 003544
PupPktCool, 000460
PupByteStreams, 000314
PupListeners[375B], 000702
Stack end OurProcess

*start*
00812 00024 US 
Date: Wed, 15 Jun 83 09:42 PDT
From: MNeary.es
Subject: Error Report
To: LaurelSupport.PA
cc: MNeary

I was editing a large (50KBytes) (from a CP/M .PRN) file, in the edit window.  The file contains ^L (Formfeeds).  I had just completed a "E"verything "S"ustitute  (tab) for (eight spaces).  I then did a "F"ind (tab tab).  Then I did a (esc) , trying to repeat find.  CRASH!

Laurel 6.1  Alto II XM (055#046#) with 3K Ram XMcode using XM MDS: 00 Banks: 140000 code: 000051

Signal 043601 in VirtCM
msg 177777, msg^ 000000 077400 077400 077400

BackStop, 003405
Signaller, 000521
Signaller, 001102
VirtCM, 001351
VirtCM, 001204
EditorUndo, 000672
EditorMain, 000706
IntTrackMain, 000615
IntTrackEdit, 000304
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
00662 00024 US 
Date: Wed, 15 Jun 83 10:05 PDT
From: Mulhern.PA
Subject: Error Report
To: LaurelSupport.PA

I didn't do nuffin!  Some gent wanted to use my Alto to send a message...and being the kind soul that I am, I let him.  When I tried to get my own new mail it crapped out. Doo waaahhh!

Laurel 6.1  Alto II XM (024#165#) with 3K Ram XMcode using XM MDS: 00 Banks: 170000 code: 000051

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
AccessOp, 002061
IntMailCom, 001120
LaurelNub, 001751
LaurelNub, 001671
LaurelNub, 001335
LaurelNub, 000122
DebugNub, 000334

*start*
00805 00024 US 
Date: Thu, 16 Jun 83 11:04 PDT
From: Sproull.PA
Subject: Error Report
To: LaurelSupport.PA

I was trying to copy a fairly large message into the composition window, which already contained a fairly large message. I was doing this rather than simply "Move to" because of the warning that Laurel mail files now contain various control codes -- I wanted to write two long messages into one file.

Laurel 6.1  Dolphin (003#024#) with XMcode using XM MDS: 00 Banks: 177760

Signal 043601 in VirtCM
msg 177777, msg^ 000000 077400 077400 077400

BackStop, 003405
Signaller, 000521
Signaller, 001101
VirtCM, 001351
VirtCM, 001204
EditorMain, 002576
EditorMain, 000726
IntTrackMain, 000615
IntTrackEdit, 000303
IntTrackMain, 001111
IntTrackMain, 000703
LaurelNub, 000126
DebugNub, 000333

*start*
00653 00024 US 
Date: Thu, 16 Jun 83 17:15 PDT
From: Woods.PA
Subject: Laurel 6.1 bug: Replace.laurel
To: LaurelSupport.pa

The documentation for Replace.laurel says:

-- Replace.laurel is like Insert.laurel except that it replaces the message(s) currently selected in the table of contents rather than inserting after them.

Well, I selected three consecutive messages in the TOC, Forwarded them, edited them in the composition window to create a single message, and ran Replace without having changed the selection in the TOC.  It replaced only the last of the three messages, leaving the others still in the TOC (and in the file).

	-- Don.

*start*
00587 00024 US 
Date: Thu, 23 Jun 83 07:46 PDT
From: DNCurry.PA
Subject: Error Report
To: LaurelSupport.PA

Trying to obtain ACTIVE mail file.

Laurel 6.1  Dolphin (006#036#) with XMcode using XM MDS: 00 Banks: 176000

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
VirtTOC, 001342
VirtSS, 000616
MailFileOp, 000355
ChollaCmdStub, 001657
ChollaCmdStub, 001302
ChollaCmdStub, 000106
IntMailCom, 000230
LaurelNub, 001751
LaurelNub, 001671
LaurelNub, 001335
LaurelNub, 000122
DebugNub, 000333

*start*
00942 00024 US 
Date: Thu, 23 Jun 83 08:08 PDT
From: DNCurry.PA
Subject: Error Report
To: LaurelSupport.PA

Trying to get Active mail consistently causes OOPS.  To try to fix, I retrieved new copy of Laurel.run, new MailFilePatch, and scavenged entire Alto Disk, which reported a "Beautiful File System".  Then I went into Laurel and tried MailFileScavenger, which did not report any errors.  Then I ran MailFilePatch, on Active which encounters an "Uncaught Signal, Laurel cannot proceed."  Help.

Laurel 6.1  Dolphin (006#036#) with XMcode using XM MDS: 00 Banks: 176000

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
VirtTOC, 001342
VirtSS, 000616
MailFileOp, 000355
ChollaCmdStub, 001657
ChollaCmdStub, 001302
ChollaCmdStub, 000106
IntMailCom, 000230
LaurelNub, 001751
LaurelNub, 001671
LaurelNub, 001335
LaurelNub, 000122
DebugNub, 000333

*start*
00810 00024 US 
Date: Fri, 24 Jun 83 09:13 PDT
From: Bleier.EOS
Subject: Error Report
To: LaurelSupport.PA

I was reading through my active mail, and reuqested a hardcopy of the piece I was currently reading; I used the right mouse button instead of the left mouse 
button for the hardcopy request.   I didn't use the soldering iron hardly at all. No, really I didn't. Why are you looking at me that way!!!!

Laurel 6.1  Dolphin (012#354#) with XMcode using XM MDS: 00 Banks: 177760

Signal 002601 in Faults
msg 177777, msg^ 000000 077400 077400 077400

BackStop, 003405
Signaller, 000521
Signaller, 001101
Faults, 000123
IntEditCom, 000050
Resident, 001500
IntHardcopyCom, 000430
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001111
IntTrackMain, 000703
LaurelNub, 000126
DebugNub, 000333

*start*
00574 00024 US 
Date: Fri, 24 Jun 83 15:03 EDT
From: HEWITT.Henr
Subject: Error Report
To: LaurelSupport.PA

In the process of retrieving mail when system error was declared.

Laurel 6.1  Alto II XM (015#001#) with 3K Ram XMcode using XM MDS: 00 Banks: 170000 code: 000051

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
AccessOp, 002061
IntMailCom, 001120
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001112
IntTrackMain, 000k4
LaurelNub, 000126
DebugNub, 000334

*start*
00616 00024 US 
Date: Tue, 28 Jun 83 09:57 EDT
From: Venable.WBST
Subject: Error Report
To: LaurelSupport.PA

I typed the command AUTO in the Basic interpreter and got the signal.

Laurel 6.1  Alto II XM (014#315#) with 3K Ram XMcode using XM MDS: 00 Banks: 170000 code: 000051

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
VirtCM, 000205
VirtCom, 000207
BasicInterpA, 010200
BasicInterpA, 014044
BasicControl, 000332
Modules, 000277
Modules, 000157
ExecSS, 000754
ExecSS, 000436
ExecSS, 000301
Stack end OurProcess

*start*
04387 00024 US 
Date: Tue, 28 Jun 83 10:35 PDT
From: Putz.pa
Subject: Laurel 6.1 Trouble Report
To: LaurelSupport
cc: Putz

Running on a Dorado, I had a session something like this:

1)  started Laurel with Laurel/s
2)  ran Chat.laurel (already on local disk)
3)  selected a new empty local mail file
4)  ran Insert.laurel (retrieved from Ivy)
5)  tried to run Print.laurel (retrieved from Ivy), and got the error message:

	print.laurel got an uncaught signal: 2205B, arg: 177777B

6)  clicking red+blue did not return to executive
7)  the partition would no longer boot
8)  Scavenger found errors and fixed the problem (see log below)
9)  Print.laurel worked correctly the next time

-------------------
Alto File System Scavenger of September 29, 1982
Partition: 5, Disks: 2, Cylinders: 406, Heads: 2, Sectors: 14
Ready to scavenge a dual model-44 14-sector file system [confirm] Yes
May I alter your disk to correct errors? Yes
Proceeding with scavenge...
Strange entry in directory SysDir.
Inserted SysDir., SN 20000000144b, in directory SysDir.
Inserted NewDisk-ST80.cm., SN 212b, in directory SysDir.
Inserted S.cm., SN 262b, in directory SysDir.
Inserted Ftp.Run., SN 156b, in directory SysDir.
Inserted RealNewST80.cm., SN 311b, in directory SysDir.
Inserted ST80Version.cm., SN 312b, in directory SysDir.
Inserted VM.cm., SN 313b, in directory SysDir.
Inserted SysFont.Al., SN 160b, in directory SysDir.
Inserted Swatee., SN 161b, in directory SysDir.
Inserted Rem.Cm., SN 170b, in directory SysDir.
Inserted Sys.Boot., SN 176b, in directory SysDir.
Inserted Ftp.log., SN 204b, in directory SysDir.
Inserted NewST80.cm., SN 213b, in directory SysDir.
Inserted IFS.cm., SN 214b, in directory SysDir.
Inserted HM.cm., SN 215b, in directory SysDir.
Inserted TimesRoman8.al., SN 217b, in directory SysDir.
Inserted TimesRoman10.al., SN 220b, in directory SysDir.
Inserted TimesRoman12.al., SN 221b, in directory SysDir.
Inserted TimesRoman14.al., SN 222b, in directory SysDir.
Inserted Helvetica8.al., SN 223b, in directory SysDir.
Inserted Helvetica10.al., SN 224b, in directory SysDir.
Inserted Helvetica12.al., SN 225b, in directory SysDir.
Inserted Helvetica18.al., SN 226b, in directory SysDir.
Inserted Logo24.al., SN 227b, in directory SysDir.
Inserted Math10.al., SN 230b, in directory SysDir.
Inserted GACHA10.al., SN 231b, in directory SysDir.
Inserted Gacha12.al., SN 232b, in directory SysDir.
Inserted NEPTUNE.RUN., SN 233b, in directory SysDir.
Inserted Laurel.state., SN 270b, in directory SysDir.
Inserted Smalltalk80.message., SN 671b, in directory SysDir.
Inserted ST80.cm., SN 314b, in directory SysDir.
Inserted snap.cm., SN 315b, in directory SysDir.
Inserted GetInterp.cm., SN 317b, in directory SysDir.
Inserted RunST80.cm., SN 320b, in directory SysDir.
Inserted files.laurel., SN 467b, in directory SysDir.
Inserted Swat.help., SN 240b, in directory SysDir.
Inserted SYS.ERRORS., SN 241b, in directory SysDir.
Inserted Sys.syms., SN 242b, in directory SysDir.
Inserted Laurel.run., SN 244b, in directory SysDir.
Inserted Swat., SN 245b, in directory SysDir.
Inserted Line.Cm., SN 2007b, in directory SysDir.
Inserted Snapshot.im., SN 12665b, in directory SysDir.
Inserted temp.mail., SN 13115b, in directory SysDir.
Inserted temp.mail-dmsTOC., SN 13116b, in directory SysDir.
Inserted print.laurel., SN 13117b, in directory SysDir.
Inserted INSTALLSWAT.RUN., SN 355b, in directory SysDir.
Inserted LoadMB.run., SN 330b, in directory SysDir.
Inserted Scanner-copyReplaceOldTokenNamed-with-., SN 10146b, in directory SysDir.
Inserted ST80V32.initialChanges., SN 10070b, in directory SysDir.
Inserted ST80V32.changes., SN 10204b, in directory SysDir.
Inserted Kinetic4.RUN., SN 2250b, in directory SysDir.
Inserted st80.crash., SN 460b, in directory SysDir.
Inserted st80.stats., SN 461b, in directory SysDir.
Inserted st80.recent., SN 2120b, in directory SysDir.
Inserted stepper.design., SN 11561b, in directory SysDir.
Inserted LargeNegativeInteger-class-initialize., SN 2711b, in directory SysDir.
Inserted storeICC.cm., SN 5056b, in directory SysDir.
Inserted inch.cm., SN 2624b, in directory SysDir.
Inserted ST80V32-EB.im., SN 10072b, in directory SysDir.
Inserted NewOnDorado.cm., SN 4564b, in directory SysDir.
Inserted OnePerPage.overflow., SN 4641b, in directory SysDir.
Inserted snip.cm., SN 3567b, in directory SysDir.-------------------
*start*
00743 00024 US 
Date: Thu, 30 Jun 83 10:41 PDT
From: AUGUSTE.PA
Subject: Error Report
To: LaurelSupport.PA

i had just returned to the exec from INTERLISP, and typed "laurel donna".  "donna" is the name of my regular mail file.

Laurel 6.1  Dorado (064#172#) with XMcode using XM MDS: 00 Banks: 177777

Signal 042601 in CoreStreams
msg 177777, msg^ 000000 077400 077400 077400

BackStop, 003405
Signaller, 000521
Signaller, 001101
CoreStreams, 000731
MailFileOp, 001337
ArpaMailParser, 006010
ArpaMailParser, 000200
MailStampFormat, 001074
MailFileOp, 000716
ChollaCmdStub, 001657
ChollaCmdStub, 001302
ChollaCmdStub, 000106
IntMailCom, 000230
LaurelNub, 001751
LaurelNub, 001671
LaurelNub, 001335
LaurelNub, 000122
DebugNub, 000333

*start*
00607 00024 US 
Date: Thu, 30 Jun 83 14:40 PDT
From: douglas.pa
Subject: Error Report
To: LaurelSupport.PA

I had just bugged "hardcopy".

Laurel 6.1  Dorado (064#172#) with XMcode using XM MDS: 00 Banks: 177777

Signal 042601 in CoreStreams
msg 177777, msg^ 000000 077400 077400 077400

BackStop, 003405
Signaller, 000521
Signaller, 001101
CoreStreams, 000731
MailFileOp, 001337
MailStampFormat, 000125
MailFileOp, 000631
ChollaCmdStub, 001657
ChollaCmdStub, 001302
ChollaCmdStub, 000106
IntMailCom, 000230
LaurelNub, 001751
LaurelNub, 001671
LaurelNub, 001335
LaurelNub, 000122
DebugNub, 000333

*start*
01299 00024 US 
Date: Tue, 5 Jul 83 12:00 PDT
From: Deutsch.PA
Subject: Laurel 6.1 performance problems
To: LaurelSupport

There are two significant performance problems that are new to Laurel 6:

1) When I Quit, Laurel rattles the disk arm rapidly back and forth for an inordinate length of time -- much longer than Laurel 5.  Just now, for example, I deleted a message around position 250 in a 400-odd message Active mail file, and Laurel rattled the disk for a good minute and a half while Quitting.  From the sound of things, I suspect Laurel is (a) copying a large part of the message file to a scratch file before copying it back over itself, and (b) copying only one page at a time.

2) During typein, both in message composition and in Laurel Chat, there are frequent hesitations of anywhere from half a second to over 5 seconds when typein does not echo and the cursor does not blink.  The characters are being buffered, all right, but the frequent pauses are annoying and did not occur in Laurel 5.  I have no theory about this -- it happens much too often to be caused by writing a new page on the scratch file, which produces an audible disk seek in any case (the abovementioned hesitations are silent).

Can you shed any light on these phenomena?  I have an Alto II with 128K.

*start*
01425 00024 US 
Date: Tue, 5 Jul 83 14:19 PDT
From: Taft.PA
Subject: Re: Laurel 6.1 performance problems
In-reply-to: "Deutsch's message of Tue, 5 Jul 83 12:00 PDT"
To: Deutsch
cc: LaurelSupport

It sounds as if you have one of those Alto-IIs with extended memory but lacking the XMesa PROMs, so Laurel is behaving as if it were running on a 64K machine.

1) Deleting a message in the middle of a large mail file has always taken a long time, though it is perhaps possible that it takes longer with Laurel 6.1 than it would have taken with Laurel 6.  Removing deleted messages is done by in-place compression.  It is done in a fairly simpleminded way, but the read-ahead and write-behind provided by the Mesa VM package is supposed to take care of making bulk transfers of this sort efficient.  However, the VM mechanisms are subverted if there isn't enough memory, as is true on a 64K machine.

2) The Laurel 6.1 editor has a bigger working set than the one in Laurel 6.  When you hear the disk seeking a lot during editing, I believe it is due to code thrashing.

I have received several reports of Laurel 6.1 "freezing" for varying lengths of time.  Yours is the first from anyone not on net 3.  I have been assuming until now that the freezes are caused by some sort of bad Ethernet traffic on net 3 (e.g., uncontrolled broadcasts).  I have not yet been able to gather sufficient evidence of this, however.

	Ed

*start*
00507 00024 US 
Date: Tue, 5 Jul 83 17:48 PDT
From: Taft.PA
Subject: Error in Answer form
To: LaurelSupport

If there is ever a Laurel 6.2, the following should be fixed.  "Answer", when applied to a message with a From field such as:

From: "jjs@mit-cipg"@mit-mc.ARPA

produces a header with an In-reply-to field of:

In-reply-to: ""jjs@mit-cipg"@mit-mc.ARPA's message of 15 Jun 83 10:11:31 EDT"

The embedded double-quote characters needed to be prefixed with "\" in order to conform to RFC 822.

*start*
01090 00024 US 
From: deutsch.pa
Date:  5-Jul-83 23:09:32 PDT
Subject: Re: Laurel 6.1 performance problems
In-reply-to: Taft's message of Tue, 5 Jul 83 14:19 PDT
To: Taft
cc: LaurelSupport

I ran the What program on my machine when Laurel 6.1 was first
released and sent you the results, which didn't correspond to either of
the example results in the release message.  You said I had the right
PROMs and didn't have to do anything.

While I would have to do some experimenting to verify this, Laurel 6.1
seems to take much, much longer to delete messages early in message files
when quitting, and in particular, the disk sounds are
clearly made by seeking back and forth at a very rapid pace, unlike the
sounds made by Laurel 6.  I suggest you install something in the Laurel
disk driver (at a low level) and look at what is going on.

I haven't noticed any more disk activity during editing than in
Laurel 6, only the freeze-up phenomenon.

I would be happy to make a copy of my Laurel disk for you, or let you
use my Alto, if that will help track down these little problems.

P.
*start*
00824 00024 US 
Date: Wed, 6 Jul 83 10:26 PDT
From: Diebert.PA
Subject: Error Report
To: LaurelSupport.PA

Well I was running chat to the DLS in my office.  Chat was receiveing a file from the IBM PC.  I was at the same time displaying new mail that I had received earlyer usein the newmail command while chat was running.

Call if you need more info.

Tim

Laurel 6.1  Alto II XM (003#011#) with 2K Rom XMcode using XM MDS: 00 Banks: 170000 code: 000047

Signal 036401 in VMPageOps
msg 177777, msg^ 000000 077400 077400 077400

BackStop, 003405
Signaller, 000521
Signaller, 001102
VMPageOps, 000267
VMPageOps, 000065
VirtCom, 000437
VirtCM, 000742
VirtCM, 001020
VirtCom, 000222
EditorDisplay, 000667
EditorDisplay, 000460
ExecStreamIO, 001444
ExecStreamIO, 001063
Chat, 003026
Chat, 002214
Stack end OurProcess

*start*
01048 00024 US 
Date: Wed, 6 Jul 83 13:16 PDT
From: Taft.PA
Subject: Re: Laurel 6.1 performance problems
In-reply-to: "deutsch's message of 5-Jul-83 23:09:32 PDT"
To: deutsch
cc: LaurelSupport

Well, it turns out that in Laurel 6 there was some elaborate special-purpose logic for making mail file compaction go fast.  It gobbled up the space occupied by the table of contents and displayed message windows and used it for output buffers.  This minimized the frequency of seeking back and forth between the read and write positions in the mail file.

In Laurel 6.1 this was ripped out and replaced by a simpleminded scheme based on ordinary Laurel streams, which are built on top of the Alto/Mesa VM package.  There is some amount of read-ahead and write-behind, but I don't believe it extends over more than 3 or 4 pages at a time.

I believe this explains the difference in performance when deleting a message from the middle of a big mail file.  I don't know why the change was made; but it's too late to do anything about it now.

	Ed

*start*
00636 00024 US 
Date: Thu, 7 Jul 83 14:10 EDT
From: Dusel.WBST
Subject: Error Report
To: LaurelSupport.PA

I clicked new mail blue after my disk overflowed with a normal mail retrieval.  Laurel died during the "one at a time" retrieval.

Laurel 6.1  Alto II XM (065#100#) with 3K Ram XMcode using XM MDS: 00 Banks: 140000 code: 000051

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
AccessOp, 002061
IntMailCom, 001120
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
00576 00024 US 
Date: Fri, 8 Jul 83 09:10 PDT
From: GMEREDITH.ES
Subject: Error Report
To: LaurelSupport.PA

Had invoked 'New Mail' command.  Just starting out for the morning.

Laurel 6.1  Alto II XM (056#166#) with 3K Ram XMcode using XM MDS: 00 Banks: 140000 code: 000051

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
AccessOp, 002061
IntMailCom, 001120
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
00708 00024 US 
Date: Fri, 8 Jul 83 14:58 PDT
From: JWeaver.PA
Subject: Error Report
To: LaurelSupport.PA

Selected approximately four messages and bugged hardcopy so that messages would be printed in Archive format.

Laurel 6.1  Alto II XM (060#344#) with 2K Rom XMcode using XM MDS: 00 Banks: 160000 code: 000051

Signal 000201 in Resident
msg 106202, msg^ 045152 046541 062145 071054

BackStop, 003405
Signaller, 000521
Resident, 001407
IntHardcopyCom, 003745
IntHardcopyCom, 003454
IntHardcopyCom, 003132
IntHardcopyCom, 002252
IntHardcopyCom, 000353
IntHardcopyCom, 001314
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
00560 00024 US 
Date: Mon, 11 Jul 83 08:52 PDT
From: Taft.PA
Subject: Re: "SAVE" Command
In-reply-to: "MWalker.WBST's message of Mon, 11 Jul 83 10:03 EDT"
To: MWalker.WBST
cc: laurelsupport

I don't believe there are any built-in commands for saving and recovering Basic programs.  However, you can List the program, quit out of Basic, perhaps edit the typescript, and run Insert to move it into your mail file.  At the start of your next Basic session, you can copy the program from your mail file back into Basic with a shifted secondary selection.

*start*
00580 00024 US 
Date: Tue, 12 Jul 83 15:13 EDT
From: Hruschak.WBST
Subject: Error Report
To: LaurelSupport.PA

Retreiving from Barab(spelling?) archive.  Last command was new mail.

Laurel 6.1  Alto II XM (124#114#) with 3K Ram XMcode using XM MDS: 00 Banks: 170000 code: 000051

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
AccessOp, 002061
IntMailCom, 001120
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
00630 00024 US 
Date: Wed, 13 Jul 83 14:41 EDT
From: majcher.WBST
Subject: Error Report
To: LaurelSupport.PA

Was composing a message. Hit deliver berfoe hitting esc to complete message. hit esc and laurel brokel.

Laurel 6.1  Alto II XM (114#224#) with Ram only MDS: 00 Banks: 100000 code: 000051

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
VirtCM, 001405
VirtCM, 001174
EditorUndo, 000672
EditorMain, 000706
IntTrackMain, 000615
IntTrackMain, 003120
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
01249 00024 US 
Date: Thu, 14 Jul 83 12:08 PDT
From: Taft.PA
Subject: Header checking
To: LaurelSupport

A message with a bad header was sent recently to a rather wide audience; attempting to Hardcopy this message caused Laurels to die left and right.  I believe all the error reports were for Laurel 6, so perhaps Laurel 6.1 does not have this problem.

However, the bad message was sent by a Laurel 6.1 user.  The problem with the header was that the extra CR at the end was missing.  The first several lines of the body happened to begin with spaces and/or tabs, so they appeared to be continuations of the last line of the header, which was a Reply-to field.

This made the Reply-to field syntactically incorrect.  The header parser knows it is incorrect, since attempting to answer it yields a syntax error.  However, for some reason Laurel failed to detect this during Deliver; and thus it permitted this bad header to escape.

I suspect the header parser is being called by Deliver only to extract the information required for delivery (To and cc); and since the Reply-to field isn't required for delivery, it isn't getting parsed.  This is incorrect.  Deliver should parse every field, even if it uses only some of the information.

*start*
01026 00024 US 
Date: Thu, 14 Jul 83 17:49 PDT
From: Freige.PA
Subject: Error Report
To: LaurelSupport.PA

I had just composed a "new form" message to Bob Ritchie, invoked "Deliver" and was then prompted to send this message.  Nothing unusual, except a few minutes before working on the Ritchie message, part of the displayed message in the center section of my screen got fuzzy and became unreadable.

Nancy Freige, x-4801

Laurel 6.1  Alto I (064#134#) with Ram only MDS: 00 Banks: 100000 code: 000051

Signal 002661 in Faults
msg 165520, msg^ 173774 001024 165400 000202

BackStop, 003405
Signaller, 000521
Faults, 000516
Swapper, 002050
Modules, 002223
Modules, 002160
Modules, 000554
Modules, 001737
PupSockets, 000277
PupPktCool, 004522
PupPktCool, 000517
PupByteStreams[352B], 000346
Protocol, 000650
SendMail, 002077
SendMail, 002034
GVSender, 001150
IntSendCom, 000640
IntSendCom, 000330
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
00937 00024 US 
Date: Mon, 18 Jul 83 19:10 EDT
From: JordanHD.Wbst
Subject: Error Report
To: LaurelSupport.PA
cc: JordanHD.Wbst

I was reading information in one of my mail files and MOVING it to another file. The last thing I did was select MOVE TO and hit ESC.

By the way, this new Laurel is much slower than the old one. Can we get the old one back? (Fat chance!)

Harley

Laurel 6.1  Alto II XM (123#035#) with 3K Ram XMcode using XM MDS: 00 Banks: 170000 code: 000051

Signal 002601 in Faults
msg 177777, msg^ 000000 077400 077400 077400

BackStop, 003405
Signaller, 000521
Signaller, 001102
Faults, 000123
IntTrackMain, 003603
IntTrackMain, 134741
IntTrackMain, 002202
IntTrackMain, 001252
IntTrackMain, 001112
IntTrackMain, 000704
IntBracketsCom, 002364
IntBracketsCom, 000453
IntDisplayCom, 001462
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
00509 00024 US 
Date: Mon, 18 Jul 83 11:18 PDT
From: kushner.ES
Subject: Error Report
To: LaurelSupport.PA

It broke during mail retrieval.

Laurel 6.1  Alto II XM (054#352#) with 2K Rom XMcode using XM MDS: 00 Banks: 160000 code: 000051

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
AccessOp, 002061
IntMailCom, 001120
LaurelNub, 001751
LaurelNub, 001671
LaurelNub, 001335
LaurelNub, 000122
DebugNub, 000334

*start*
00399 00024 US 
Date: Wed, 20 Jul 83 12:19 PDT
From: Putz.pa
Subject: Laurel 6.1 Bug Report
To: LaurelSupport
cc: Putz.pa, Robson.pa, Putz.pa, Putz.pa, Putz.pa, Putz.pa, Putz.pa, "Putz.pa"@PARC-MAXC

Laurel 6.1 will not compose a reply to this message, apparently because the last address starts with a quote AND wraps to a second line (note that the line is NOT folded with a CR + space).

*start*
00527 00024 US 
Date: Wed, 20 Jul 83 11:49 PDT
From: JHSY.ES
Subject: Error Report
To: LaurelSupport.PA

I was reteiving new mail when this happened...

Laurel 6.1  Dolphin (056#223#) with XMcode using XM MDS: 00 Banks: 177600

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
AccessOp, 002061
IntMailCom, 001117
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001111
IntTrackMain, 000703
LaurelNub, 000126
DebugNub, 000333

*start*
00701 00024 US 
Date: Tue, 26 Jul 83 16:52 EDT
From: Marshall.WBST
Subject: Error Report
To: LaurelSupport.PA

I WAS RUNNING BASIC

1 DEFFNF(X)
2 FNF = X+3
3 FNEND
PRINT FNF(7)

I THINK

If basic is not supported then toss this message.

--Sidney

Laurel 6.1  Dolphin (014#075#) with XMcode using XM MDS: 00 Banks: 177774

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
VirtCM, 000205
VirtCom, 000207
BasicInterpB, 004265
BasicInterpA, 010361
BasicInterpA, 005650
BasicInterpA, 014063
BasicControl, 000331
Modules, 000277
Modules, 000157
ExecSS, 000753
ExecSS, 000436
ExecSS, 000301
Stack end OurProcess

*start*
01949 00024 US 
Date: Thu, 28 Jul 83 12:44 EDT
From: clark.wbst
Subject: Laurel studdering...
To: LaurelSupport.PA
Cc: Clark.wbst,Roberts.wbst

Often laurel seems to "hang" for a while, from a few seconds to 20 or 30
seconds.  During this time the cursor moves with the mouse, but it does not
respond to button clicks, the arrow does not change form/direction, and 
anything you type does not come out, but it does queue it up so it jumps
out all at once.  This all happens often enough that when working
through a large pile of mail, it is not at all uncommon to have it happen 
many times such that you cannot just whip around with the mouse 
clicking and pushing keys because things are missed.  It does it even
on real simple things, like moving the cursor back a few characters
with the mouse and left button, or scrolling up the middle window a small
amount (I know this might need the disk, but not for 10-15 seconds! - if
it does not ignore you, it may put the bigger arrow up for the 10-15 seconds,
or the arrow may stay at the 'wrong angle' as you move it all over)
or bugging the display or delete button - you might have to click it
for 5 seconds or more continually to get it's attention.  All this is
random.  It works instantaneously and normally most of the time.

One person here reported it stopping for minutes, and the mouse not
moving the cursor during that time, although this seems to be an
isolated incident.

I do not remember such problems when 6.1 first came out.  

I do have 128K with XM etc... I keep running "what" to see if perhaps
something is loose and it went away, but it is there.  Also, it happens
on two altos, although it seems (hard to tell) on one slightly more than 
the other.  The one it seems to do more on has mesa5, the other mesa 6.

Question(s):

	Have you seen this or am I alone?

	Any ideas on what causes it? 

	Is there any hope/help?


As always, thanx for your help.

				--Ray Clark
*start*
00838 00024 US 
Date: Fri, 29 Jul 83 16:32 PDT
From: BRay.ES
Subject: Error Report
To: LaurelSupport.PA

I WAS TRYING TO RETRIEVE MY MAIL AND RAN OUT OF SPACE. WENT IN TO NEPTUNE AND DELETED SOME FILES SO THAT I COULD COME BACK INTO LAUREL TO COMPLETE MY PROJECT. DELETED THE 21 FILES LISTED AND TRIED TO QUIT. THEN THIS HAPPENED.

Laurel 6.1  Alto II XM (055#140#) with 3K Ram XMcode using XM MDS: 00 Banks: 140000 code: 000051

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
CoreStreams, 002561
CoreStreams, 001663
MailFileOp, 002614
ChollaCmdStub, 001462
ChollaCmdStub, 000741
ChollaCmdStub, 000106
IntMailCom, 000470
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
00818 00024 US 
Date: Mon, 1 Aug 83 11:09 PDT
From: Pugh.PA
Subject: Error Report
To: LaurelSupport.PA
Reply-to: Fiveash.pa
cc: Fiveash

Retrieving mail in normal way, however, since this is not my machine I must first login. I do this by bugging User, fill in my name followed by escape then fill in my password also followed by escape.   I am unable to retrieve my mail.  It tries to get it (noted 26 messgages) but cannot for some reason.


Laurel 6.1  Dolphin (005#071#) with XMcode using XM MDS: 00 Banks: 177400

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
AccessOp, 002061
IntMailCom, 001117
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001111
IntTrackMain, 000703
LaurelNub, 000126
DebugNub, 000333

*start*
00911 00024 US 
Date: Mon, 8 Aug 83 17:05 PDT
From: MReilly.ES
Subject: Error Report
To: LaurelSupport.PA

I was moving two pieces of mail to another mail file, right after cancelling the move to cammand because I had typed in the wrong mail file name.


Laurel 6.1  Alto II XM (056#237#) with 3K Ram XMcode using XM MDS: 00 Banks: 170000 code: 000051

Signal 001201 in Swapper
msg 164672, msg^ 020465 007400 164770 000652

BackStop, 003405
Signaller, 000521
Signaller, 001102
Swapper, 000357
Swapper, 001731
Resident, 001502
NonResident, 000777
AltoFileOpsA, 001662
AltoFileOpsA, 000327
AltoFileOpsB, 001457
AltoFileOpsB, 001252
VMFile, 000750
CoreStreams, 002440
CoreStreams, 002222
CoreStreams, 002076
CoreStreams, 001300
AppendOp, 000544
AppendOp, 000240
IntDisplayCom, 001700
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
00660 00024 US 
Date: Mon, 25 Jul 83 09:20 PDT
From: Peters.PASA
Subject: Error Report
To: LaurelSupport.PA

I was trying to down-load my mail from the system to my disk. Was connected to Gamay at the time.
Laurel 6.1  Alto II XM (012#047#) with Ram only MDS: 00 Banks: 100000 code: 000051

Signal 010401 in AltoMesaByteBlt
msg 177777, msg^ 000000 077400 077400 077400

BackStop, 003405
Signaller, 000521
Signaller, 001102
AltoMesaByteBlt, 000071
PupByteStreams[342B], 000726
RetrieveGV, 002102
AccessOp, 001260
IntMailCom, 001120
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
01176 00024 US 
Date: Wed, 10 Aug 83 08:58 PDT
From: Fishman.ES
Subject: Error Report
To: LaurelSupport.PA

I was invoking Laurel (Laurel/n).  The first time the screen went blank with only the hour glass cursor showing.  Then I rebooted and proceeded to run Laurel/n again.  It went further this time notifying me that my last message may have been truncated.  I was connected to Gamay for a couple of minutes and finally the automatic error reporting began.  Have fun with this.  If you want my opinion I think Laurel 6.1 stinks!  I'll gladly return to using Laurel 6.0 if it is available.  Laurel 6.1 frequently "goes out to lunch".  It ignores commands for about ten seconds and then just comes back like everything was business as usual.  I thought "new" software releases were supposed to be BETTER. 

Laurel 6.1  Alto II XM (054#072#) with 2K Rom XMcode using XM MDS: 00 Banks: 140000 code: 000051

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
AccessOp, 002061
IntMailCom, 001120
LaurelNub, 001751
LaurelNub, 001671
LaurelNub, 001335
LaurelNub, 000122
DebugNub, 000334

*start*
00550 00024 US 
Date: Mon, 15 Aug 83 09:32 PDT
From: Gunning.PA
Subject: Error Report
To: LaurelSupport.PA

I was typing an answer to a msg.  The last command was replace.

						Bill



Laurel 6.1  Dolphin (064#220#) with XMcode using XM MDS: 00 Banks: 177740

Signal 002661 in Faults
msg 165130, msg^ 170320 000232 165520 165536

BackStop, 003405
Signaller, 000521
Faults, 000516
IntIdleLoop, 000464
IntIdleLoop, 000373
IntIdleLoop, 000213
IntTrackEdit, 000302
IntTrackMain, 001111
IntTrackMain, 000703
LaurelNub, 000126
DebugNub, 000333

*start*
00386 00024 US 
Date: Tue, 16 Aug 83 09:56 PDT
From: Taft.PA
Subject: Time zones
To: LaurelSupport

Laurel apparently fails to append the time zone to dates if the zone is not in North America.

---------------------------

Date: Tue, 16 Aug 83 09:59
From: HIRST.RX
Subject: Laurel Q
To: LaurelSupport.PA
cc: HIRST

------------------------------------------------------------

*start*
00855 00024 US 
Date: Tue, 16 Aug 83 11:52 PDT
From: RDones.es
Subject: Error Report
To: LaurelSupport.PA

While trying to delete mail from my active mail file this problem occured.  I believe it might be due to a large build up of active mail.  I believe I have some 400 messages in my active mail file.  

Rene 

Laurel 6.1  Alto II XM (115#010#) with 2K Rom XMcode using XM MDS: 00 Banks: 170000 code: 000051

Signal 001201 in Swapper
msg 000000, msg^                            

BackStop, 003405
Signaller, 000521
Signaller, 001102
Swapper, 000357
Swapper, 001731
Signaller, 000536
Signaller, 000242
Signaller, 001102
Faults, 000123
Signaller, 000074
Signaller, 001102
Faults, 000123
IntTOC, 002441
IntTrackMisc, 000675
IntTrackMisc, 000500
IntTrackMisc, 000124
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
00625 00024 US 
Date: Mon, 22 Aug 83 12:56 CDT
From: Sanchez.DLOS
Subject: Error Report
To: LaurelSupport.PA

I answered a message from yhap.es, I hit the del key followed by the esc key.

Laurel 6.1  Alto II XM (077#335#) with Ram only MDS: 00 Banks: 100000 code: 000051

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
VirtCM, 001405
VirtCM, 001174
EditorUndo, 000672
EditorMain, 000706
IntTrackMain, 000615
IntTrackEdit, 001024
IntTrackEdit, 000205
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
00760 00024 US 
Date: Tue, 23 Aug 83 10:31 PDT
From: Anthon.PA
Subject: Error Report
To: LaurelSupport.PA

All I did was try to hardcopy one piece of mail, and it came up parity error.

Laurel 6.1  Alto I (024#313#) with Ram only MDS: 00 Banks: 100000 code: 000051

Signal 036055 in VMFile
msg 177777, msg^ 000000 077400 077400 077400

BackStop, 003405
Signaller, 000521
Signaller, 001102
VMIO, 002517
VMIO, 000122
VirtCom, 000376
VirtCom, 000124
IntHardcopyCom, 010052
IntHardcopyCom, 005406
IntHardcopyCom, 003745
IntHardcopyCom, 003454
IntHardcopyCom, 003132
IntHardcopyCom, 002252
IntHardcopyCom, 000353
IntHardcopyCom, 001314
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
00842 00024 US 
Date: Thu, 25 Aug 83 12:55 PDT
From: VBlatin.ES
Subject: Error Report
To: LaurelSupport.PA

I logged in, and then chose New mail command in the menue. The error was  encountered in response to that command.

Laurel 6.1  Alto II XM (055#173#) with 2K Rom XMcode using XM MDS: 00 Banks: 170000 code: 000051

Signal 031411 in DiskRequestor
msg 165460, msg^ 000001 167102 165440 000000

BackStop, 003405
Signaller, 000521
Signaller, 001120
DiskRequestor, 000543
DiskRequestor, 000335
DiskRequestor, 000126
AltoFileOpsC, 000207
AltoFileOpsB, 001631
AltoFileOpsB, 001252
VMFile, 000750
CoreStreams, 002440
CoreStreams, 002222
CoreStreams, 002076
CoreStreams, 001300
AccessOp, 001332
IntMailCom, 001120
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
00812 00024 US 
Date: Tue, 30 Aug 83 08:21 PDT
From: MMartinez.ES
Subject: Error Report
To: LaurelSupport.PA

I was in the process of inserting a line of text from a mail file into a lengthy text file that was to be stored onto my disk.

As a side note, Laurel 6.1 seems to be very SLOW in responding back from various interactive commands; the cursor hangs up, file are hard to append, etc.

Laurel 6.1  Alto II XM (055#224#) with 3K Ram XMcode using XM MDS: 00 Banks: 140000 code: 000051

Signal 043601 in VirtCM
msg 177777, msg^ 000000 077400 077400 077400

BackStop, 003405
Signaller, 000521
Signaller, 001102
VirtCM, 001351
VirtCM, 001204
EditorMain, 002576
EditorMain, 000726
IntTrackMain, 000615
IntTrackEdit, 000304
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
01416 00024 US 
Date: Wed, 31 Aug 83 09:35 PDT
From: Taft.PA
Subject: Re: Printing Locally with Laurel
In-reply-to: "Your message of 31 Aug. 1983 9:56 am (Wednesday)"
To: HIRST.RX
cc: Taft

I'm pretty sure that the decision about breaking lines when generating hardcopy is not made at hardcopy time but rather at the time the message is originally delivered.  That is, if you print a message that was sent by Laurel 6 (which breaks lines while sending) then the lines are broken; but if you print a message that was sent by Laurel 6.1 (or Hardy or Walnut or any mail system besides Laurel 6, none of which break lines while sending) then the lines aren't broken.  It does not make any difference whether you used Laurel 6 or Laurel 6.1 to RECEIVE the message.

To verify this, try printing this message, which of course was sent with Laurel 6.1.

However, Laurel 6.1 does insert "pseudo-CRs" in received mail for its own use in displaying messages efficiently.  These pseudo-CRs are characters with code 240C, and they always replace spaces (40C).  Most programs ignore the high-order bit of each character and see just spaces where Laurel 6.1 puts pseudo-CRs.  If you are in a position to change the program you are using to print your mail files, you should have it treat pseudo-CRs (code 240C) the same as regular CRs (15C).  This, by the way, works only for mail files RECEIVED by Laurel 6.1.

	Ed Taft

*start*
02043 00024 US 
Date: Wed, 31 Aug 83 10:04 PDT
Sender: Taft.PA
From: LaurelSupport.PA
Subject: Re: "Ethernet Information"
In-reply-to: "shinbrot.wbst's message of 31-Aug-83  9:13:39 EDT"
To: shinbrot.wbst
cc: EthernetInterest^.dlos, LaurelSupport.PA
Reply-To: LaurelSupport.PA

First of all, EthernetInterest^.dlos was not the right list to send your question to.  That list is for messages having to do with the Ethernet hardware, protocols, and products; whereas you are asking a question about mail systems.

Second, when you have basic procedural questions such as this, I suggest you consult some experienced local user for advice rather than broadcasting questions to a distribution list.  If you don't know whom to start with, I would suggest the person who registered you as a Laurel user.

To briefly answer your specific questions:

  a) You get on the list.
  b) There is no automatic compilation or archiving of messages to interest groups; and there is no analog to the "bulletin board" facilities available in some systems.  However, for some groups, people have collected the messages and stored them in a public place.  I would suggest asking the owner of the groups in question, who can be reached by sending a message to Owner-X where X is the name of the group.
  c) Xerox users are not ordinarily permitted to "get onto" the Arpanet in the sense of being able to initiate terminal connections or transfer files to and from other Arpanet sites.  Only people engaged in activities sponsored by ARPA or other government agencies are supposed to have such access.  However, you can correspond with Arpanet users (and other people reachable via the ARPA Internet) by electronic mail, so long as you are careful not to carry on Xerox business or to send messages that could be construed as promoting a Xerox product.  There is information about corresponding with Arpanet users in the Laurel manual, and more information in the Laurel tutorial mail files (Tutorial.mail and Laurel61.mail).

	Ed Taft (for LaurelSupport)

*start*
00652 00024 US 
Date: Thu, 1 Sep 83 16:25 EDT
From: Hengst.WBST
Subject: Error Report
To: LaurelSupport.PA

Moving window boundaries back to their normal position.

Laurel 6.1  Dolphin (124#165#) with XMcode using XM MDS: 00 Banks: 177760

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
VirtTOC, 001342
VirtTOC, 001446
VirtTOC, 000652
IntTOC, 000634
IntTOC, 000357
IntBoundaryCom, 003377
IntBoundaryCom, 002230
IntBoundaryCom, 001212
IntBoundaryCom, 000314
IntTrackMain, 002617
IntTrackMain, 001111
IntTrackMain, 000703
LaurelNub, 000126
DebugNub, 000333

*start*
00691 00024 US 
Date: Tue, 6 Sep 83 18:39 EDT
From: JordanHD.Wbst
Subject: Error Report
To: LaurelSupport.PA
cc: JordanHD.Wbst


The last command I invoked was DISPLAY.

The document appeared and I was reading it when Laurel crashed.

Harley

Laurel 6.1  Alto II XM (123#035#) with 3K Ram XMcode using XM MDS: 00 Banks: 170000 code: 000051

Signal 000201 in Resident
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
Resident, 001407
Resident, 001427
Keyboard, 000657
IntTrackMain, 000174
IntTrackEdit, 000304
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

------------------------------------------------------------

*start*
00676 00024 US 
Date: Mon, 12 Sep 83 13:37 EDT
From: Oszczakiewicz.Henr
Subject: Error Report
To: LaurelSupport.PA

Attempt to "Quit" after reading the current mail showed the "oops".

Laurel 6.1  Alto II XM (002#120#) with Ram only MDS: 00 Banks: 100000 code: 000051

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
CoreStreams, 002561
CoreStreams, 001663
MailFileOp, 002614
ChollaCmdStub, 001462
ChollaCmdStub, 000741
ChollaCmdStub, 000106
IntMailCom, 000470
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
01087 00024 US 
Date: Fri, 23 Sep 83 15:08:53 PDT
From: FilletSupport.pa
Subject: Re: Mail File Format
To: Karlton
cc: MessageSystemImplementors^, FilletSupport, Zdybel
Sender: Putz.pa
Reply-To: FilletSupport.pa
In-Reply-To: "Karlton.PA's message of Fri, 16 Sep 83 9:30:53 PDT"

Thank you for telling us about the complete mail file syntax.  (I wish I had been shown this when I asked LaurelSupport about the format earlier).

I have changed Fillet to use the correct syntax, and I have checked that Laurel and the Laurel MailFileScavenger work on files produced by Fillet.

I found that Hardy would still not read Fillet mail files, however.  After a little experimenting, I found that the problem was that Hardy was choking on the optional CR character following the variable-part.

	variable-part ::= <empty> | @ item-list @ optional-cr

I will change Fillet to no longer produce the optional CR, but either Hardy should be changed to accept it, or the mail file syntax standard should be changed to forbid it.  There's little point in having a standard if it isn't supported.*start*
00681 00024 US 
Date: Mon, 3 Oct 83 10:42 PDT
From: Hausladen.PA
Subject: Error Report
To: LaurelSupport.PA

Delivering a message.  The machine gave a promote, noting that one of the names on the list was invalid.  I changed the spelling and rebugged "deliver", then it went into error mode.

Thanks, Mary

Laurel 6.1  Dolphin (003#116#) with XMcode using XM MDS: 00 Banks: 177760

Signal 056401 in IntExceptions
msg 000001, msg^                            

BackStop, 003405
Signaller, 000521
IntExceptions, 000223
AccessOp, 002061
IntMailCom, 001117
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001111
IntTrackMain, 000703
LaurelNub, 000126
DebugNub, 000333

*start*
00879 00024 US 
Date: Thu, 13 Oct 83 11:41 PDT
From: Fikes.pa
Subject: Error Report
To: LaurelSupport.PA

I had blue-bugged "Quit".  Laurel responded with the flashing prompt that the message in the bottom window had not been sent.  I hit "esc" to indicate quit anyway, and laurel broke.

richard

Laurel 6.1  Dolphin (006#250#) with XMcode using XM MDS: 00 Banks: 177600

Signal 002635 in Faults
msg 002645, msg^ 000000 000511 166100 002643

BackStop, 003405
Signaller, 000521
Signaller, 001101
Faults, 000313
DiskRequestor, 001112
DiskRequestor, 000144
VMIO, 000675
VMPageOps, 000173
CoreStreams, 002454
CoreStreams, 002000
CoreStreams, 001670
MailFileOp, 001653
ChollaCmdStub, 001461
ChollaCmdStub, 000741
ChollaCmdStub, 000106
IntMailCom, 000470
IntTrackMain, 001725
IntTrackMain, 001252
IntTrackMain, 001111
IntTrackMain, 000703
LaurelNub, 000126
DebugNub, 000333

*start*
00660 00024 US 
Date: Fri, 14 Oct 83 09:36 PDT
From: KRobinson.ES
Subject: Error Report
To: LaurelSupport.PA

I was using maintain to remove myself from a DL, and at the same time I also was trying to display/delete a message in my active mail account.

Laurel 6.1  Alto II XM (055#023#) with Ram only MDS: 00 Banks: 100000 code: 000051

Signal 036401 in VMPageOps
msg 177777, msg^ 000000 077400 077400 077400

BackStop, 003405
Signaller, 000521
Signaller, 001102
VMPageOps, 000267
VMPageOps, 000065
VirtCom, 000437
VirtSS, 001475
IntTrackMain, 001702
IntTrackMain, 001252
IntTrackMain, 001112
IntTrackMain, 000704
LaurelNub, 000126
DebugNub, 000334

*start*
00859 00024 US 
Date: Mon, 12 Dec 83 09:12 PST
From: Deutsch.PA
Subject: Protection problem with mail files
To: LaurelSupport

I tried to access a mail file in someone else's directly whose IFS protection was:
	R: Owner World W: Owner
Laurel complained "User credentials insufficient to access this file".  It seems to me that as long as I don't try to modify the file, Laurel should let me bring it in as the current mail file.  Does the problem arise because Laurel is trying to create a TOC file in the directory that the mail file comes from?  If so, maybe the right solution is to create a TOC on the local disk.

A glitch I encountered in trying this is that if I select
	[]<Trow>mail>sun-spots
as the current mail file, Laurel just gives me an empty file without complaining; if I select
	[Filene]<Trow>mail>sun-spots
I get the error message.

*start*
00399 00024 US 
Date: Mon, 12 Dec 83 10:05 PST
From: Taft.PA
Subject: Re: Protection problem with mail files
In-reply-to: "Deutsch's message of Mon, 12 Dec 83 09:12 PST"
To: Deutsch
cc: LaurelSupport

The problem is that Laurel always opens mail files for writing. But your conjecture about needing to write the TOC is also correct. Your suggestion is already on the Laurel wish list.

	Ed