*start*
00282 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 11:13 PST
From: Masinter.pa
Subject: want Add Owner in Maintain
To: LispSupport

Unlikely, Annoying, Communications/PUP: MAINTAIN LispUsers package doesn't have "Add Owner" command; I wanted it.
*start*
00439 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 11:52 PST
From: Masinter.pa
Subject: AR#151
To: LispSupport

I can't tell from the Subject what the AR here is. 

Also, when the summary of an AR is hidden in messages toward the end, it would be good to make the Description: have the summary paragraph at the beginning.

So, this AR needs Status _ Fixed (???), Lisp Version, Priority and Difficulty.

*start*
00840 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 11:45 PST
From: vanMelle.pa
Subject: [LispSupport.pa: AR 274: Want non-fixed array space and MDS allocations]
To: Kaplan
cc: LispSupport.pa

Seems like you have an interest in this one.

     ----- Begin Forwarded Messages -----

Sender: Sannella.PA
Date: 23 Mar 84 10:33:42 PST (Friday)
Subject: AR 274: Want non-fixed array space and MDS allocations
To: vanMelle.pa
From: LispSupport.pa

----------------------------------------------------------------
Date: 22 Mar 84 13:04 PST
From: Stansbury.pa
Subject: Lisp: Should allow arrayspace to grow at expense of MDS
To: LispSupport.pa
Lisp-System-Date: 14-Mar-84 10:16:58
Machine-Type: Dolphin



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


     ----- End Forwarded Messages -----
*start*
00463 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 12:38 PST
From: vanMelle.pa
Subject: Re: AR 279: LAFITE(ON) shouldn't reset cursor
In-reply-to: LispSupport.pa's message of 23 Mar 84 12:14:33 PST (Friday)
To: LispSupport.pa
cc: vanMelle.pa

Indeed.  The most serious violator of this principal that comes to mind is Tedit (at startup when it reads the file, during Put, Get, Hardcopy etc).  Consider this another AR.


	Bill
*start*
01425 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 12:30 PST
From: vanMelle.pa
Subject: Lisp: wish: FILESLOAD version control
To: LispSupport.pa
cc: vanMelle.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

Propose new keyword for FILESLOAD: NEWERTHAN <date>.

File dependencies are currently weakly documented by putting the appropriate FILES command in the coms of the file.  There is nothing that ensures that the file so fetched is the right version.  A common need is "I want a version of FOO at least as recent as when some particular feature I depend on was added".  For example, I would like LAFITE to be able to say

(FILES (NEWERTHAN "21-Mar-84 12:21") GRAPEVINE MAILCLIENT)

This would tell FILESLOAD either (a) if the indicated file(s) are not yet loaded, then be sure that whatever file you do find to load has a recent enough date, and (b) if the file(s) are already loaded, but the filedate (as stored on the FILEDATES prop) is too old, then generate an error (or possibly ask for permission to load a newer version if one is found).

This doesn't cover the case where you're developing two parallel incompatible versions, and doesn't get into the complexity (and major hassle) of assuring that you have exactly the right version (e.g., too new a version in which the records of changed), but it at least handles a simple case and doesn't seem too hard.

	Bill
*start*
00906 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 12:38 PST
From: Sheil.pa
Subject: Lisp: TEdit/Lafite: Shift select into To: on Forward
To: LispSupport.pa

Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dolphin

If you forward a message, then extend the invert selection from >>Recipient<< to include the following CR and the "cc:Sheil.pa" field that follows on the next line (NOT including the CR) [so that what is typed next replaces both the addressee and leaves no cc field] and then shift select a name out of the text of the mesage being forwarded, then all looks fine.

Problem is that when you try and send the message, Lafite does not see the last character of the To: field, so complains with a message like "Unrecognized recipient: Foo.p" (where the actual value is "Foo.pa").

Retyping the To: field name (including the CR) makes all work fine.

Beau

*start*
00535 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 14:02 PST
From: vanMelle.pa
Subject: Lisp: PF/WHEREIS glitch
To: LispSupport.pa
cc: vanMelle.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

If I PF a function from a file that I have LOADFROM'ed, WHEREIS finds its file immediately from incore information, and PF displays the function from that file.  After doing so, it appears to still go off consulting the database to see if it lives elsewhere.  That seems like a waste of time.
*start*
01637 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 14:18 PST
From: Masinter.pa
Subject: Re: Fugue.6 Delay
In-reply-to: Dering.pasa's message of 1 Jan 01 10:27 PST
To: Dering.pasa
cc: LispSupport, Raim.pasa, LE.PASA, Roach.pa

Judy, AR#270 describes a problem of moderate impact. The impact is moderate because there is a simple workaround, namely, to call FLOPPY.MODE(PILOT) after performing SYSOUT({FLOPPY}). [LispSupport: please change Impact _ Moderate and add Workaround field].

There is a separate AR,  AR#176, which Michael Sannella, Frank Halasz et. all discussed, which indicates a problem with SYSOUT to floppy producing a bad sysout, and for which there is no workaround. There is no discussion of OSU in the mail from you are anyone about this separate problem, which might be considered a "show-stopper" (i.e., that the release cannot go out until this one is included.) If you have some separate mail or correspondence from OSU about this, could you make sure it gets edited into the appropriate AR?

There was yet another AR which was resolved as having an incorrect installation utility, which we believed was a version mismatch.

Thu, would you please make sure that all of the 1100Support staff have a summary of the AR database so far, at least in summary form? Maybe you can coordinate this.

In the future, the right way of identifying a problem will be by its AR number & Subject, e.g.

We're going to hold the release until the following problems get resolved:

AR#270, "Sysout to floppy can smash FLOPPY.MODE"
AR#275, "Block compiler should rename globalvars local to a block"
*start*
01055 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 16:54 PST
From: Dering.pasa
Subject: Re: Fugue.6 Delay
In-reply-to: Masinter.pa's message of 23 Mar 84 14:18 PST
To: Masinter.pa
cc: Dering.pasa, LispSupport.pa, Raim.pasa, LE.PASA, Roach.pa

Larry,

Your suggestion of calling (FLOPPY.MODE 'PILOT) is not a workaround for the problem described in AR 270.  See step 4 in PART 2 of the AR.


The workaround which is detailed in the disposition field of the AR is to do a (FLOPPY.RESTART) after the ^D.

I classified this as serious because it appears that the only side-effect of the ^D is to have to reset mode.  But  in any  sysout created by a subsequent invocations of (SYSOUT '{FLOPPY})  the definition of FLOPPY.MODE is smashed.  To have to have the user call a function to reset all the  floppy globals when SYSOUT function is interrupted seems to me to be a serious problem.  Also,  it would be nice to know if the same procedure is necessary if you abort other floppy functions, e.g. FLOPPY.TO.FILE.



Judy 
 
*start*
00687 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 17:37 PST
From: Masinter.pa
Subject: Re: AR#270, SYSOUT({FLOPPY})
In-reply-to: Dering.pasa's message of 23 Mar 84 16:54 PST
To: Dering.pasa
cc: Masinter.pa, LispSupport.pa, Raim.pasa, LE.PASA, Roach.pa

Judy, 

after our phone conversation, and re-reading your message, would it be adequate to call this AR

"Control-D during SYSOUT({FLOPPY}) causes next SYSOUT({FLOPPY}) to be smashed?"

Just to make sure I understand the circumstances, have you had any experience with the resulting sysout being bad after SYSOUT({FLOPPY}) if it was NOT preceded by a ^D during a previous SYSOUT({FLOPPY}) ?????


*start*
00293 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 15:08 PST
From: Burton.pa
Subject: Lisp: WAIT.FOR.TTY should call SPAWN.MOUSE
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

in case it gets called under the mouse.

richard

*start*
00592 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 17:36 PST
From: Jellinek.pa
Format: TEdit
Subject: Lisp: ?= EditCom  misfeature
To: LispSupport.pa
cc: Jellinek.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dolphin

The DEdit ?= EditCom, used to display the arguments of functions, fails for niladic functions, claiming
"(mumble not a function)" when mumble is in fact a function of 0 args.
	-Herb

)
TIMESROMAN
TIMESROMAN

TIMESROMAN
TIMESROMAN
)
TIMESROMAN
uz·*start*
02860 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 17:54:45 PST (Friday)
From: JFung.pasa
Subject: Re: AR# 279 InstallLispTool should allow booting non-LispVMem volumes
In-reply-to: Your message of 23 Mar 84 12:06:12 PST (Friday)
To: stansbury.PA
cc: Sannella.pa, LispSupport.PA, 1100Support, JFung


Dear Tayloe,

	I am glad to see somebody requested this feature.  I have this on my private version, since I found it is frustrating not able to use the Interlisp-D bouncing box to bring up my Tajo volume.(especially it is your own tool)   Anyway, here it is how it works.  (I appreciate your suggestions, but this is how it works NOW, let me know whether you like it or not).

	There is a parameter of Volume-Type: {Lisp, Non-Lisp}.  To start up the non-lisp volumes say Tajo, first you select the Non-Lisp then select the volume name from volume-menu and then bug the StartVolume!.  

	There is one catch to this, and please DO NOT let the customers know this.  The StartVolume! will not boot volume with name = Diagnostics.  This is to prevent customers from using Tajo volume.  So if you have Diagnostics volume now, it is too bad.  You need to re-partition (using Othello) your machine and not select Diagnostics as the name.  

	If you have Star volume, you need to install the Star boot file into that volume.  I hope this works, I have not tested this.  I know you can boot tajo, and then you may SHIFT-STOP to jump into Copilot.

	This will be included in the next release, whenever it is.  Right now, it is filed at: [Rose]<Lisp>New>InstallLispTool.bcd  


P.S.  	I think if you start up the volume with wrong type, say, start Tajo with type=Lisp, or start Lisp with type=Non-Lisp, it crashes. 

P.P.S.	By the way, is there a way, I can find out the members of LispAR.auto?  Just curious? 

P.P.P.S.	Can I change Status{} _ Fixed, or shall I wait till release time?

P.P.P.P.S.	I am looking forward to meet the LISPers on your next monday Lisp meeting.

	/Jerry from South 

----------------------------------------------------------------
Date: 23 Mar 84 02:54 PST
From: stansbury.pa
Subject: 
To: LispSupport.pa
cc: stansbury.pa 
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dandelion

The InstallLispTool has no provision for starting non-LispVMem volumes.  For example, if you wanted to have Star & Tajo living on the same machine as Lisp, you would not be able to use the InstallLispTool to boot those volumes.

Unless there is a way for the StartVolume! command to figure out whether the volume it is about to boot should be diagnostic-booted or normal booted, I suggest there be two commands: a StartLisp! command and a StartOther! command.  StartLisp! would do a diagnostic boot, and StartOther! would do a normal boot.

-- Tayloe.

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

*start*
00367 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 18:32 PST
From: Masinter.pa
Subject: output of 1st pass compiler smashed somehow
To: lispsupport

if you do LISTING T in the compiler, the output of the first pass is much less legible than it used to be. Dunno what happened. Maybe something got lost last edit of BYTECOMPILER?


*start*
00592 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 18:36 PST
From: Masinter.pa
Subject: optical mice have odd failure mode -- cursor moves down screen
To: LispSupport


This should actually be AR on hardware design. The 3-button optical mouse I have has a failure mode where it starts wiggling and going down the screen.

I haven't correlated it, but sometimes also my DLion IOP gets very confused and breaks (flashing MP code) even while Lisp is still running, which I suspect but have no evidence is due to lots of spurious signals from optical mouse.


*start*
00234 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 24 MAR 84 18:54 PST
From: MASINTER.PA
Subject: please submit AR: put DRAWLINE opcode in 12K control-store DLion microcode
To:   lispSupport
cc:   Charnley


*start*
00743 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 24 MAR 84 19:46 PST
From: MASINTER.PA
Subject: some files that should be kept on Phylum
To:   lispsupport

Date:  4 Jan 84 16:54 PDT
From: Martin.pasa
Subject: Re: Starting Lisp from SCRATCH
In-reply-to: Feuerman.PASA's message of Wed, 4 Jan 84 15:50 PST
To: Feuerman.PASA
cc: LispSupport.pa, 1100Support.PASA

Ken,

the best way to build an 1100 disk can be extracted from the information in {rose}<lisp>current>makepartition1.cm and makepartition2.cm.  The key idea is to erase the disk using NewOS before you begin, and then run Createfile to guarantee that the Vmem is contiguous.  If you have any questions after looking at the .cm files, give me a call.

Rick
*start*
03061 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 25 MAR 84 05:47:33 PST
Return-path: <@SUMEX-AIM.ARPA:LINKOPING@BBNG.ARPA>
Redistributed: Xerox1100UsersGroup^.PA
Received: from BBNG.ARPA by SUMEX-AIM.ARPA with TCP; Sun 25 Mar 84 05:10:52-PST
Date: Sun, 25 Mar 84 08:12:23 EST
From: LINKOPING@BBNG.ARPA
Subject: Transor
To: 1100users@SUMEX-AIM.ARPA

Does the author of a program have any natural authority whereby to declare it
hopelessly obsolete, and encourage others to write a better one? We need one,
to judge from the previous messages, but TRANSOR should be flushed. Let me
suggest the following to anyone who might like to write and document a new one.

(1) Don't use the editor at all.

(2) Don't imagine that translation is a one-shot computation. In practice one
keeps on finding more transformations which should have been included.
Therefore,  do not regard translation as editing in
place, destructively, but as copying from some suitable property like SOURCEXPR
to the function cell or EXPR property. Then one can always just re-run the whole
works again from scratch.

(3) Use a simple recursive descent control structure. The worst part about old
TRANSOR was trying to use the editor for this. An absurd decision.
But separate (a) the transformation to be applied from (b) the control of
the recursion over the subforms of the (translated) expression. The point is 
that one often wants to run a small set of transformations, but you then need
the recursion control for all the known functions to guide the sweep.

(4) The user is unfamiliar with one of the two dialects involved, often with
both. He will get done much quicker, even if he has to type  a lot more, if you
do not use sophisticated features to "help" him. Thus: PRESCAN is a good notion
but coding it in assemble was silly. Using the editor for expresssing the
transormation of old forms to new is clearly wrong. The choice is between 
writing (SW 2 3) and writing

(LAMBDA (FORM) (LIST (CAR FORM) (CADDR FORM) (CADR FORM)))

The latter is clearly preferable! Because everyone knows what LAMBDA and  CAR
do. Not everyone knows what SW will do. You think you know? What does it do,
when embedded inside (LPQ (ORR (1) (NX)(!NX)) (COMS (GETP (CAR (##))'TRANSOFORMATION]  when the form that is supposed to have its second and third argument
switched happens to have defaulted the third one? 

(5) Provide functions for things like (a) This form is an ordinary EXPR, go
translate all its arguments recursively. (b) Translate just this subexpression
recursively. (c) Give me the form enclosing this one, and a tail of it, of which
this form is the CAR. (Like !0 and UP respectively). 

A suitable set of such functions, plus some conventions about where the rules
or functions for translating subforms are stored, will be more useful and
helpful than any more "fully automated" solution can be.


If anyone does write such a package, I will be eternally relieved if he should
call it TRANSOR. 

Jim Goodwin
-------
*start*
01110 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 25 MAR 84 10:22:01 PST
Return-path: <@SUMEX-AIM.ARPA:SHEBS@UTAH-20.ARPA>
Redistributed: Xerox1100UsersGroup^.PA
Received: from UTAH-20.ARPA by SUMEX-AIM.ARPA with TCP; Sun 25 Mar 84 09:58:56-PST
Date: Sun, 25 Mar 84 10:58:47 MST
From: Stan Shebs <SHEBS@UTAH-20.ARPA>
Subject: Re: Transor
To: LINKOPING@BBNG.ARPA
cc: 1100users@SUMEX-AIM.ARPA
In-Reply-To: Message from "LINKOPING@BBNG.ARPA" of Sun 25 Mar 84 06:46:44-MST

Why not use some version of Finin's franzlator to build a TRANSOR?
It has good syntax for writing patterns, does at least a marginal job
on fexprs and macros, and does not use an editor.  It *was* designed to
be used steadily rather than for a one-shot translation, so it meets
that particular criterion.  It's also pretty complete, so it could be
used to translate itself to Interlisp, once the appropriate rules were
written.  I'm working on rules to convert Franz <-> PSL, and hope to
have a PSL version of franzlator eventually (pslator?)

							stan shebs
-------
*start*
01516 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 25 MAR 84 16:02:57 PST
Return-path: <@SUMEX-AIM.ARPA:DDYER@USC-ISIB.ARPA>
Redistributed: Xerox1100UsersGroup^.PA
Received: from USC-ISIB.ARPA by SUMEX-AIM.ARPA with TCP; Sun 25 Mar 84 15:12:07-PST
Date: 25 Mar 84 15:10:05 PST
Subject: Transor etc.
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: 1100users@SUMEX-AIM.ARPA


  I don't believe there is such a thing as a translator between lisps.
It is possible to translate gross forms to their rough equivalents, but
below that level there are myriads of incidental features of one dialect
that are difficult to anticipate or support in the intended host enviroment.

  A tool such as transor is adequate to do 80% or so of the work, but
looking for better, or trying to improve a translator to get to 100%
is unrewarding.

  The alternative to translating to common lisp is to implement
the basis of Interlisp in common lisp, and then run your Interlisp
programs untranslated.   This is the approach I used in the lisp machine
Intelisp compatability package, and even more rigorously in the
implemtation of Interlisp for the vax.

  The performance penalty for using this approach is small, and probably
negative compared to a program translated without a significant tuning effort.
The additional advantage of this approach is that it keeps your programs
in mostly their original form, so they can still be run in real Interlisp
environments.
-------
*start*
00337 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 25 Mar 84 15:44 PST
From: Stansbury.pa
Subject: Lisp: Singlefileindex
To: LispSupport.pa
cc: Stansbury.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

Fails to list a records entry for recordtypes not on the usual clisprecordtypes.  

-- Tayloe.
*start*
00440 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 01:36 PST
From: Sheil.pa
Subject: Lisp: TEdit: Multiple Hardcopys crash
To: LispSupport.pa

Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dolphin

Did three hardcopies at once (3 different windows). the second and third died with a NIL in IDIFFERENCE under TEDIT...HARDCOPY.

Went OK if I waited til one was done before starting the others.

Beau

*start*
00363 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 11:49 PST
From: Halasz.pa
Subject: Lisp: Leaf error: 1001
To: LispSupport.pa
cc: 
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

What the hell is a "Leaf error: 1001" and why isn't there a more informative msg in the prompt window when this error occurs?


Frank

*start*
00437 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 12:38 PST
From: Masinter.pa
Subject: AR#275, Status_ Declined
To: LispSupport
cc: Stansbury


This in general doesn't work because the initialization of the variables has to be renamed as well. 

It is often considered "bad form" to have the state of a process in a global variable, as opposed to, say, a variable which is bound at the entrypoint.


*start*
01544 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 24 MAR 84 08:52:07 PST
Redistributed: Xerox1100UsersGroup^.PA
Date: Sat, 24 Mar 84 08:07:01 PST
From: Eric Schoen <Schoen@SUMEX-AIM.ARPA>
Subject: Re: Common Lisp compatibility
To: 1100users@SUMEX-AIM.ARPA

My thanks to all who responded regarding my questions about machine
translation of Interlisp programs into Common Lisp.  I've tried to
answer a couple of you directly, but have had mailer problems.  The
best bet seems to be TRANSOR or a TRANSOR-like program to handle direct
translation of the obvious differences (e.g. name changes, argument order,
etc).  While there are no Interlisp to Common Lisp transforms, I did
not find it too hard to create my own.

I was hoping that someone explicitly handled CLISP I.S. OPR statements.
Using CLISP itself to pretranslate these statements into "purer" Lisp
is acceptable, but defeats the purpose of permitting the intent of the
code to be clear.  It would be nice to translate to some form of (DO ..).

The remaining problems I have at this point are thus the I.S. OPRS and
Interlisp comments.  An EMACS keyboard macro could probably take care of
turning the latter into semicolon prefixed lines of text.

Note on TRANSOR: The PRESCAN function was almost entirely ASSEMBLE code
for speed in Interlisp-10.  I've built an Interlisp-D version under 
(SELECTQ (SYSTEMTYPE) ..) and will forward the new code to Pasadena for
inclusion in future LispUsers releases.

Eric
-------
*start*
01133 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from USC-ECL.ARPA by PARC-MAXC.ARPA; 24 MAR 84 09:07:55 PST
Return-path: <@USC-ECL.ARPA:FIKES@ECLD>
Received: from ECLD by ECLA with ECLnet; Sat 24 Mar 84 09:08:24-PST
Date: Sat, 24 Mar 84 09:07:58 PST
From: Richard Fikes <FIKES%ECLD@ECLA>   
Subject: POSSIBILITIES
To: lispsupport.PA
cc: FIKES@ECLD.#ECLnet.ARPA

I am doing some coding using the possibility list interface to
generators and am having problems because they tie up too much stack
space.  In particular, if one calls POSSIBILITIES deep in a computation,
the form that is the argument to POSSIBILITIES gets called in the context
of the call to POSSIBILITIES so that the entire stack at that point
gets associated with the generator and therefore tied up by it.  Most
of my generators don't use any nonlocal stack information and therefore
could be run with an empty stack.  Is there any way of doing that? 
Can POSSIBILITIES be modified to allow that, say with another argument
that provides evaluation in an empty stack?  Any suggestions would be
appreciated.

thanks,
richard
-------
*start*
01273 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from USC-ECL.ARPA by PARC-MAXC.ARPA; 26 MAR 84 08:48:11 PST
Return-path: <@USC-ECL.ARPA:FIKES@ECLD>
Received: from ECLD by ECLA with ECLnet; Mon 26 Mar 84 08:48:39-PST
Date: Mon, 26 Mar 84 08:48:03 PST
From: Richard Fikes <FIKES@ECLD.#ECLnet.ARPA>
Subject: Problems With POSSIBILITIES
To: vanmelle.PA
cc: FIKES@ECLD.#ECLnet.ARPA, lispsupport.PA

Bill,
	I am using the possibilities list interface to generators and
am getting frequent display panel stops (i.e., 9xxx) that usually
cause loss of my virtual memory.  For example, yesterday I could cause
a 9016 each time TRYNEXT was called in one of my functions.  We have
very litle information as to what the display panel codes mean, so I
don't know what to make of that.  I suspect the possibilities list
functions may be screwing up the stack somehow, perhaps in an
interaction with the process mechanism.  I would greatly appreciate it
if you could take a quick look at POSSIBILITIES, TRYNEXT, AU-REVOIR,
and ADIEU to see if you see any problems.  I will try to get a simple
reproducable case of failure, but that may be difficult and there may
be something going on that would be relatively obvious to your eye.

thanks,
richard
-------
*start*
00982 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from BBNG.ARPA by PARC-MAXC.ARPA; 24 MAR 84 05:20:18 PST
Date: Sat, 24 Mar 84 08:21:16 EST
From: LINKOPING@BBNG.ARPA
Subject: Further bug reports
To: LISPSUPPORT.PA

Tomas Lund, a graduate student here, and part of Epitec (the AI company
which is providing some customer support to RX/Stockholm for Dlions) is
compiling a written list of bugs and stuff. This will reach you all eventually.
We had a bunch of notes, it is jus a matter of compiling this information.

I have spent some time on it too and must get back to other work for the
moment. Tomas will take care of the bugs; I may write some notes on what are
more opinions or experiences. Thanks to various for replies received.
Hello, Richard Burton.

I see a reference in a reply to Fugue 6. Do I understand correctly that
Fugue 5 must be Carol which is out already in places, and Fugue 6 is the next
release after that?

Jim Goodwin
-------
*start*
00460 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 24 Mar 84 13:27 PST
From: BrianSmith.pa
Subject: Lisp: Raid on Window Op
To: LispSupport.pa
cc: BrianSmith.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

Entered raid, had to ^D (^N didn't work) on any window shaping operation.  System stack was:

	RAID
	\MP.ERROR
	\INVADILADDR
	\PAGEFAULT
	\FAULT-HANDLER

	Invalid address {65,156516}

Eminently repeatable!

Brian

*start*
01042 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 24 MAR 84 18:36 PST
From: MASINTER.PA
Subject: document STACK OVERFLOW behavior
To:   lispsupport

In Interlisp-D (and in Interlisp-10), there is a fixed amount of space left for stack. When this space is exhausted, the STACK OVERFLOW error is caused. However, if the system waited until the stack were REALLY exhausted, there wouldn't be room to run a break . Thus, there is a "buffer" which is reserved; when the stack intrudes into the buffer, it causes a stack-overflow interrupt and subsequently a break.

Once the buffer is allocated, it is allocated; the NEXT time a stack overflow happens, it is necessary to do a "hard" reset. The hard-reset reallocaes the buffer so tht there is once again room to get an error.

The effect of all of this is that STACK OVERFLOW causes a break every other time, unless you explicitly do a
(HARDRESET) in Interlisp-D (or a RESET in Interlisp-10).

[AR to fix this so that stack is growable and size controlable; very hard]
*start*
00435 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 24 Mar 84 20:06 PST
From: desRivieres.pa
Subject: Lisp: EDITBM's STOP ==> ABORT
To: LispSupport.pa
cc: desRivieres.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

I think that "Abort" would be a better name than "Stop" on EDITBM's menu.   It would also be handier if "Ok" was the last item on the menu, instead of the second from last.

---Jim
*start*
00508 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 12:16 PST
From: Halasz.pa
Subject: Lisp: DSPCREATE goes inRAID unnecessarily
To: LispSupport.pa
cc: 
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

If you give DFSPCREATE an incorrect argument [e.g., (DSPCREATE 'BITMAP) instead of (DSPCREATE BITMAP)], it bombs into RAID with the appropriate error msg.  This seems like too drastic a move for such an innocuos error.  It should just pop into a break.

Frank

*start*
00488 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 13:38 PST
From: Sannella.pa
Subject: [Sheil.pa: AR revisions]
To: LispSupport.pa

     ----- Forwarded Messages -----

Date: 26 Mar 84 12:14 PST
From: Sheil.pa
Subject: AR revisions
To: sannella

Mike:

ARs # 130,214,21,136 and 248 are to the Lisp project, not me.

AR# 254 is marked as being for TEdit, rather than DEdit, altho the ATTN is correct.

Beau


     ----- End of Forwarded Messages -----
*start*
00275 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 13:52 PST
From: vanMelle.pa
Subject: Re: new SAMEDIR
In-reply-to: vanMelle.pa's message of 20 Mar 84 16:07 PST
To: LispSupport.pa

I made the change to MIGRATIONS in ABC that I suggested.
*start*
00913 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 14:06 PST
From: vanMelle.pa
Subject: Fixed: [vanMelle.pa: Lisp: Masterscope CHECK and CONSTANTS]
To: LispSupport

I fixed this one:

     ----- Begin Forwarded Messages -----

Date:  6 Jan 84 12:45 PST
From: vanMelle.pa
Subject: Lisp: Masterscope CHECK and CONSTANTS
To: LispSupport.pa
Lisp-System-Date:  5-Jan-84 16:27:03
Machine-Type: Dorado

Masterscope's CHECK command does not know about CONSTANTS -- it treats them like any other var, so gives warning that you used them free without declaring them.  If you use lots of CONSTANTS, it gets hard to find the interesting warnings amongst all the spurious ones.


Also, it would be nice if, when a file has no block declarations, it just dispenses altogether with the preamble "in no block" plus mile-long list of functions.
 
	Bill

     ----- End Forwarded Messages -----
*start*
00264 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 24 MAR 84 19:22 PST
From: MASINTER.PA
Subject: ATTACHEDWINDOW on <LispCore>Sources> , not Library>???
To:   burton, lispsupport

probably a CLEANUP while connected to the wrong directory
*start*
00387 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 09:58 PST
From: Burton.pa
Subject: Re: ATTACHEDWINDOW on <LispCore>Sources> , not Library>???
In-reply-to: MASINTER.PA's message of 24 MAR 84 19:22 PST
To: MASINTER.PA
cc: burton.PA, lispsupport.PA

No.  I changed WBREAK to use attached windows thus including ATTACHEDWINDOW in the loadup.

richard

*start*
00532 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 11:30 PST
From: Masinter.pa
Subject: Re: ATTACHEDWINDOW on <LispCore>Sources> , not Library>???
In-reply-to: Burton.pa's message of 26 Mar 84 09:58 PST
To: Burton.pa
cc: MASINTER.PA, lispsupport.PA

ok. LispSupport, is there some way to reflect the fact that AttachedWindows is no longer on <Lisp>Library>? Maybe we need a script file that "does the release" or something, and then reflect changes to the release process by editing the script?

*start*
00324 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 17:50 PST
From: Wallace.pa
Subject: Lisp: WHEREIS and DIRECTORIES
To: LispSupport.pa
cc: Wallace.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

WHEREIS should add <LISPCORE>SOURCES to DIRECTORIES (preferably at the end).

*start*
00737 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 11:36 EST
From: Denber.wbst
Subject: Lisp: Compiler
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dolphin

68_DEFINEQ ((VOICEINPUT NIL (NUMBERP (CHARACTER (OR (RS232READBYTE) 48]
(VOICEINPUT)
69_(COMPILE 'VOICEINPUT]
listing? No
redefine? Yes
save exprs? Yes
output file? No
{in VOICEINPUT} No such record path
at   ... (DLTTYInCSB InControl) of \DLionTTYInLoc)
in    (fetch (DLTTYInCSB InControl) of DLionTTYInLoc)
unable to dwimify  (fetch (DLTTYInCSB InControl) of DLionTTYInLoc)

compilation break: 1
(Compilation broken)
70:

...but then after ^'ing out of the break it seems to finish compiling anyway.  ??

			- Michel
*start*
00353 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 15:10 EST
From: Denber.wbst
Subject: RS232READBYTE
To: LISPSUPPORT.PA

What will RS232READBYTE do on a Dandelion?  On a Dorado?  By the way, the function I sent you earlier today didn't compile correctly, although the compiler did redefine it.  Thanks.

			- Michel
*start*
00440 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 12:54 PST
From: BrianSmith.pa
Subject: Lafite: Shrunk Icon Name
To: LafiteSupport.pa
cc: BrianSmith.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

If you shrink a message that you haven't sent yet, it generates an icon that says "n sent", rather than something like "n to be sent", or some such ...
*start*
00637 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 15:43 PST
From: Masinter.pa
Subject: Lafite: another idea for interface
To: LafiteSupport.pa
cc: Masinter.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dandelion

If the lafite status window was a little bigger, you could add a (scrollable?) message history area. It would list the messages you'd sent, and number of recipients, etc.

The little shrunk envelopes are useless, because you can't expand them and do anything reasonable with them -- they just form useless screen clutter, scattered around.
*start*
01241 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 17:18 PST
From: Wallace.pa
Format: TEdit
Subject: Lafite: Pruning headers
To: LafiteSupport.pa
cc: Wallace.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

IWBNI there were some mechanism for deleting unwanted headers from incoming messages.  This is getting rediculous (and I've gotten worse):

Received: from CSNET-RELAY.ARPA by PARC-MAXC.ARPA; 23 MAR 84 15:42:59 PST
Return-path: <@SRI-AI.ARPA:Kay.PA%parc-gw.arpa@csnet-relay.arpa>
Received: From Sri-Ai.arpa by csnet-relay via smtp;  23 Mar 84 18:26 EST
Received: from csnet-relay by SRI-AI.ARPA with TCP; Fri 23 Mar 84 15:21:38-PST
Received: From Parc-Gw.arpa by csnet-relay via smtp;  23 Mar 84 18:06 EST
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAR 84 10:50:18 PST
Date: Fri, 23 Mar 84 10:41 PST
From: Kay.PA%parc-gw.arpa@csnet-relay.arpa
Subject: Re: Csli-folks list
In-reply-to: "EMMA%sri-ai.arpa@csnet-relay.arpa's message of Thu, 22 Mar
 84 10:16:06 PST"
To: Emma Pease <EMMA%sri-ai.arpa@csnet-relay.arpa>
cc: csli-folks%sri-ai.arpa@csnet-relay.arpa


lGACHA
Ô	HELVETICA

GACHA
Az·*start*
00589 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 17:37 PST
From: halasz.pa
Subject: TEdit: \TEDIT.WORDDELETE does not handle ImageObjects
To: TEditSupport
cc: 
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dolphin

\TEDIT.WORDDELETE breaks with a "Illegal Arg IMAGEOBJ" when an IMAGEOBJECT is within the word to be deleted.  Put another way, using Ctrl-W on a word that contains an imageobj bombs.  Looks like \TEDIT.WORDDELETE tries to pass the ImageObject as if it were a number (character code?).

Frank

*start*
00418 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 18:34 PST
From: Nuyens.pa
Subject: TEdit: RIGHT EXTENSION
To: TEditSupport
cc: Nuyens.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado



NOTE to myself:
check if right selection leaves you in the wrong place when passing over the original point, still with the right button down.
*start*
00684 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 24 Mar 84 19:20 PST
From: BrianSmith.pa
Subject: TEdit: Putting the Expanded Menu!
To: TEditSupport
cc: BrianSmith.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

If, unknowingly, you use the middle button on the bar at the top of the Tedit Menu window, rather than at the top of the main Edit window, and do a PUT, TEDIT is happy to write out something approximating the Menu as the most recent version of your file, before sending you to RAID.   Nicht so goot.

The TEDITMENU was from {PHYLUM}<LISP>LIBRARY>TEDITMENU.DCOM, dated 2-Mar-84 14:25.

Brian

*start*
00315 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 15:49 PST
From: masinter.pa
Subject: Lisp: please add AREDIT to list of files in FULL.SYSOUT
To: LispSupport.pa
cc: masinter.pa
Lisp-System-Date: 26-Mar-84 11:03:55
Machine-Type: Dorado

as per discussion in Lisp group meeting.
*start*
01003 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 14:41 PST
From: Sheil.pa
Subject: Lisp: Shade alignment with windows
To: LispSupport.pa

Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dolphin

Shades are aligned to the SCREENBITMAP, rather than the display streams to which they are directed. The effect of this is that when the relative parity of the display stream to the screen changes (b/c of a mOVEW or SCROLLW), then subsequent use of the same shade will not align with existing uses (so it will not erase when XORd, for example).

Example:
  (SETQ W (CREATEW))
  (DSPFILL NIL 3598 W 'INVERT)   (* Shades)
  (DSPFILL NIL 3598 W 'INVERT)   (* Clears)
  (DSPFILL NIL 3598 W 'INVERT)   (* Reshades)
  (RELMOVEW W '(1 . 1))               (* Off by 1)
  (DSPFILL NIL 3598 W 'INVERT)   (* SHRIEK!)

This is a moderately serious bug which requires a clumsy workaround in DEdit and anyone else who shades with textured patterns in user adjustable windows.

Beau
*start*
00567 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 15:38 PST
From: masinter.pa
Subject: Lisp: EDIT in WBREAK causes window with title "DEdit of function NIL"
To: LispSupport.pa
cc: masinter.pa
Lisp-System-Date: 26-Mar-84 11:03:55
Machine-Type: Dorado

I typed EDIT into a break window, and it got me editing the expression on LISPXMACROs that caused the computation I was performing. That is well and good, but the title of the window was 

"DEdit of function NIL" which seems like a real mistake.

Howcome the funny window title?
*start*
00444 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 MAR 84 16:30 PST
From: JONL.PA
Subject: Re: Lisp: Init asks for file QXZRYU.WJK
To:   Sheil, LispSupport
cc:   JONL

In response to the message sent  22 Mar 84 09:40 PST from Sheil.pa

When I tried to LOADFROM a file on [Phylum], and [Phylum] was heavily loaded,
I got a similar nonsense message -- [PHYLUM not responding for {Phylum}<LISPCORE>LIBRARY>QXZRYU.WJK]
*start*
01930 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 16:37 PST
From: vanMelle.pa
Subject: AR status updates
To: LispSupport
cc: vanMelle.pa

Meta-comment: my intuitive notions of "easy" and "moderate" differ from the definitions given in the arfields summary.  E.g., I would call "Easy" something that I could fix in less than a day.  There are an awful lot of bugs that by the 1 week definition would be classed as easy; I don't think spending a week on an easy bug is plausible.

Ar 101.  Priority: absolutely; Difficulty: easy

Ar 194.  Priority: absolutely; Difficulty: easy

Ar 173.  Priority: hopefully; Difficulty: easy

Ar 165.  Priority: hopefully; Difficulty: moderate; Impact: moderate
  (comment: not a serious problem because running with both 3&10mb ethernets is not a normal user configuration; usually only Gateways run this way.)

Ar 129.  Subject: Standalone 1108 should NOT ask for PUP number

Ar 12.  Difficulty: moderate

Ar 267.  Difficulty: moderate

Ar 128.  Impact: may be minor.  There is no solid evidence to believe that this change to GC will have a major impact on gc hash table collisions.  Simulations might tell us.  If Attn: includes Charnley, it should also include JonL for the Dorado microcode.  Difficulty is easy, modulo the coordination among all the microcodes.  We've been saving this up for next time we need to make a coordinated change.

Ar 198.  This is two complaints:

  Subject: MP errors are too vague and happen too frequently.  Description: 
Want Lisp to make greater efforts to handle the error in Lisp, and want better discrimination among the MP errors that do happen.  Difficulty: moderate; Priority: Perhaps.

  Subject: Want a same-machine low-level debugger.  Difficulty: Very Hard; Priority: Unlikely; Status: Wish.

Ar 196.  This is an Interlisp-10 problem.  Is there a category for that?  Impact: annoying; Frequency: intermittent



*start*
00348 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 MAR 84 16:49 PST
From: ROACH.PA
Subject: BUTTONING TEDIT WINDOW TITLE DOES NOT SWITCH USER TO TEDIT PROCESS
To:   LISPSUPPORT
cc:   ROACH

     I notice that you don't switch to Tedit when you button the window
title region area of a Tedit window.  Why not?
				Kelly
*start*
00885 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 16:52 PST
From: vanMelle.pa
Subject: Re: AR 209: Lafite MoveTo confirmation after menu
To: Sheil
cc: LafiteSupport.pa

The motivation is that middle button "does something special".  In the case of MoveTo, it is an accelerator that moves to the same place you picked last time.  The theory on confirmation of MoveTo is that if you select from the menu, it's easy to klutz and pick the wrong file, something that is awkward to recover from (and can easily go unnoticed if confirmation were not required).

Your theory is that it's easy to klutz and hit MoveTo when you meant Update.

Moral: don't use middle button unless you mean to.

On the other hand, requiring confirmation on ALL moves, though I have never desired it, does not seem unreasonable, and might make for a cleaner interface.

	Bill
*start*
00596 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 18:00 PST
From: Sheil.pa
Subject: Re: AR 209: Lafite MoveTo confirmation after menu
In-reply-to: vanMelle.pa's message of 26 Mar 84 16:52 PST
To: vanMelle.pa
cc: LafiteSupport.pa

"The theory on confirmation of MoveTo is that if you select from the menu, it's easy to klutz and pick the wrong..."

In which case the system is in desparate trouble since there are all kinds of unconfirmed menu choices all over the system.

Having confirmation for ALL is clean. Confirming after a menu choice is hoaky.

Beau

*start*
00561 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 18:25 PST
From: sybalsky.pa
Subject: Re: AR 209: Lafite MoveTo confirmation after menu
In-reply-to: vanMelle.pa's message of 26 Mar 84 16:52 PST
To: vanMelle.pa
cc: Sheil.pa, LafiteSupport.pa

I prefer having middle button avoid the confirmation--I do a lot of moving things around.  On the other hand, I'd like to be able to avoid setting the default target folder sometimes--if I'm mostly moving things to folder A, but in the middle I need to move one thing to folder B.
*start*
00373 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 16:54 PST
From: Burton.pa
Subject: Lisp: Need a device independent FREEPAGES available
To: LispSupport.pa
Lisp-System-Date: 26-Mar-84 11:03:55
Machine-Type: Dorado

There should be a way to determine how many pages are left on a host/directory in a device independent way.  


richard

*start*
01102 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 17:31 PST
From: Burton.pa
Subject: [LispSupport.pa: AR 299: Enter Raid on any window shaping operation]
To: LISPSUPPORT.PA

I decline.  This is almost certainly the result of a smashed system which just happened to have been smashed in window code.

richard


     ----- Forwarded Messages -----

Sender: Sannella.PA
Date: 26 Mar 84 15:14:43 PST (Monday)
Subject: AR 299: Enter Raid on any window shaping operation
To: Burton.pa
From: LispSupport.pa

----------------------------------------------------------------
Date: 24 Mar 84 13:27 PST
From: BrianSmith.pa
Subject: Lisp: Raid on Window Op
To: LispSupport.pa
cc: BrianSmith.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

Entered raid, had to ^D (^N didn't work) on any window shaping operation.  System stack was:

	RAID
	\MP.ERROR
	\INVADILADDR
	\PAGEFAULT
	\FAULT-HANDLER

	Invalid address {65,156516}

Eminently repeatable!

Brian


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

     ----- End of Forwarded Messages -----
*start*
01022 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 MAR 84 17:51 PST
From: JONL.PA
Subject: Re: Lisp: SINGLEFILEINDEX bug
To:   Kaplan, LispSupport, Tong
cc:   JONL

In response to the message sent  22 Mar 84 20:23 PST from Kaplan.pa

Bill had already noticed that LISTFILES was returning NIL, and I just patched
SINGLEFILEINDEX to return the FULLNAME of a file *** which it is about to
list ***.  At least this way, it won't return the user-supplied name for
a file that doesn't exist.

The minor remaining problem is that even though SINGLEFILEINDEX process is
smart enough to remove the file's ROOTFILENAME from NOTLISTEDFILES *** after
it has successfully listed the file *** pooor old LISTFILES thinks it ought 
to be the one to do it.  I'll edit the LISTFILES in DMISC to cooperate more
with the new SINGLEFILEINDEX (i.e., dont do the removal -- let SINGLEFILEINDEX
process be the only one to do it), but this isn't a real high priority bug.
There should be an AR for this bug, however.

*start*
00486 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 MAR 84 17:53 PST
From: JONL.PA
Subject: Re: Lisp: LISTFILES filename
To:   Wallace, LispSupport
cc:   JONL

In response to the message sent  23 Mar 84 02:30 PST from Wallace.pa

I think someone designed an interface in which the filenames on the {LPT} 
"device" are interpreted as the name of the printer in which to do the printing.
Thus {LPT}EXPRESSO;5, when closed, would print out on host {EXPRESSO}.

*start*
00680 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 18:12 PST
From: masinter.pa
Subject: Lisp: fixed problem with first pass output from BYTECOMPILER
To: LispSupport.pa
cc: Kaplan.pa
Lisp-System-Date: 26-Mar-84 11:03:55
Machine-Type: Dorado

Somewhere in the course of Ron's edit to the hasharray creation call, some properties in the bytecompiler got messed up; what used to have

(PUTPROPS FN MLSYM (%[ %] FN))

turned into
(PUTPROPS FN MLSYM (NIL FN))

I don't know how or why this happened, which is a separate (mysterious) AR.

Ron, do you have any idea how this got smashed, i.e., were you manipulating the file with any odd mechanisms?


*start*
01228 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 MAR 84 18:34 PST
From: JONL.PA
Subject: lack of "look ahead" buffering for LEAF
To:   LispSupport

While trying to LISTFILES on a relatively small file, I did a frequent
backtrace in the process doing the listing;  it seems to be spending all
of its time (real time, that is) underneath an AWAIT.EVENT on the socket
that it is waiting for the next packet.  Since \BIN doesn't initiate a
"reload" until it has read the last byte of a page, there is no overlapping
of the processing done on a file and transit time for packets on the
net (and this is especially important for a remote host that is somewhat 
overloaded)

What harm would there be in simply requesting one page ahead of the current
buffered page?  Thus when \BIN hits the end of that page, \TURNPAGE could
immediately re-fill from the packet that was requested "some time ago",
while also initiating a request for the page beyond that one.  For truely
random file positionings, there is the possibility of having sent too
much data from the remote host, but this must be balanced with the number
of times that a BIN of a byte on page n will shortly be followed by a BIN
on page n+1.


*start*
01173 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 19:47 PST
From: Sheil.pa
Subject: Lisp: Print of FLOATP sometimes NEQP that FLOATP
To: Lispsupport

Pls add this to the AR database. Status: Bug; Priority: Moderate. Submitter: SCHMIDT@SUMEX-AIM. See attached messages.

Beau

     ----- Forwarded Messages -----

Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 21 FEB 84 11:57:45 PST
Date: Tue, 21 Feb 84 11:57:39 PST
From: Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>

Some otherwise innocent numbers; eg. 8.1 and 68.3 won't print right -  even on typein.  Eg. 8.1 prints as 8.100001 or so. This doesnt work in grids and other confined printing spaces.

Date: 13 Feb 83 05:46 PST
From: JonL.PA@PARC-MAXC.ARPA
Subject: Non-associativity of Floating Point revisited
To: CSchmidt@SUMEX-AIM.ARPA
cc: LispSupport.PA@PARC-MAXC.ARPA

I've just checked out Interlisp-D's floating point multiply and divide, and they are indeed correct.  However,  the printout routines leave something to be desired.

It isn't the case that 8.1 and 8.100001 read in as the same number.  I suspect the printout can be made "perfect" without too much trouble.

*start*
01149 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 MAR 84 19:57 PST
From: JONL.PA
Subject: Re: Lisp: PF/WHEREIS glitch
To:   vanMelle, LispSupport
cc:   JONL

In response to the message sent  23 Mar 84 14:02 PST from vanMelle.pa

The "new" version of WHEREIS that I started work on some time ago,
but haven't had time to develop for the past several weeks, has an optional
argument FIRSTONLY which means that the caller would be satisfied with
the "first" file, rather than all files found.  Otherwise, the semantics
of WHEREIS is that it must search all sources (e.g., FILELST and the hash
file database).

If you directly supply the file argument to PF, then it doesn't call WHEREIS;
if you don't supply that argument, the WHEREIS is called with a "function" to
apply to each found file.  You are probably just witnessing the wait between
the time it finds the first file, and when it finishes the total search.

Incidentally, this "new" WHEREIS is the one that will integrate the FILEDEFS
information into additional hash files -- the "historic" WHEREIS lispusers
package only has information about FNS definitions.

*start*
00419 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 MAR 84 20:04 PST
From: JONL.PA
Subject: Re: Lisp: Compiler
To:   Denber.wbst, LispSupport
cc:   JONL

In response to the message sent  23 Mar 84 11:36 EST from Denber.wbst

This is due totally to a "bug" in RS232 file -- it is exporting a macro
to the user with some fields left in symbolic form.  See upcoming reply
on RS232READBYTE bug.
*start*
01161 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 MAR 84 20:10 PST
From: JONL.PA
Subject: Re: RS232READBYTE
To:   Denber.wbst, LISPSUPPORT
cc:   JONL, wogulis.pasa, Raim.pasa, 1100support.pasa

In response to the message sent  23 Mar 84 15:10 EST from Denber.wbst

RS232READBYTE has a macro definition which is "exported" to the user (for
speed); unfortunately, the "correct" source code cannot be compiled in the
user's environment, so I have two copies of this macro in the RS232 file --
one called RS232READBYTE.BACKUP and the other RS232READBYTE -- the first of
which is the "real" definition, and the second is a copy of the first which
has been mechanically reduced to base-level Lisp code.  Unfortunately, this
mechanical translation failed on the segment of the code that is DLion-specific
(and of course almost all my usage is on a Dolphin).

I've patched this on [Phylum]<Lisp>Library>RS232. and .DCOM.


In relation to your other questions, the RS232 facilities don't yet work
on a Dorado -- the connection between the printerport and a UART (such as
found in the Martin-board for the Dolphin) hasn't been established.

*start*
00722 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 22:54 PST
From: DMRussell.pa
Subject: TEdit: Poor choice of var names in MBUTTON.FIND.NEXT.FIELD!!
To: TEditSupport
cc: DMRussell.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 26-Mar-84 11:03:55
Machine-Type: Dorado

Tsk, tsk... 
Here is the code....

(PROG (....  (SEL (fetch SCRATCHSEL of TEXTOBJ)) )
	.
	.
	.
	.
	(replace CH# of SEL with  (ADD1 CH1))
)

Very misleading.... 

If you're not careful, you'd think that MBUTTON.FIND.NEXT.FIELD actually passes its results around in SEL... not SCRATCHSEL.  Besides, using this choice of var names results in the interesting code 

	(replace SEL of SEL with ...)

-- DMR -- 
*start*
00745 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from BBNG.ARPA by PARC-MAXC.ARPA; 27 MAR 84 05:10:00 PST
Date: 27 Mar 84 08:10 EST
Sender: GREENFELD@BBNG.ARPA
Subject: ZEROP
From: GREENFELD@BBNG.ARPA
To: LispSupport.pa
Message-ID: <[BBNG]27-Mar-84 08:10:17.GREENFELD>

Don't you people think its time to change the
abomination called ZEROP?  If for no other reason than
internal consistency of Interlisp, I suggest that you
redefine ZEROP to be (EQP x 0) and define a new function
IZEROP to be what the old ZEROP did.  While this is a change to
an existing function (and therefore not to be done lightly)
I believe more people have been bitten by this function than
have counted on its strange behavior.

Norton
*start*
00742 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from RUTGERS.ARPA by PARC-MAXC.ARPA; 27 MAR 84 08:13:33 PST
Date: 27 Mar 84 11:13:40 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: LDIFFERENCE problems
To: lispsupport.pa


Forwarded bug report about differences in Interlisp-10 and Interlisp-D:

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

Mail-From: WEINRICH created at 27-Mar-84 10:22:07
Date: 27 Mar 84 10:22:07 EST
From: Tim <WEINRICH@RUTGERS.ARPA>
Subject: NLisp - DLisp incompatibility
To: Design@RUTGERS.ARPA


   If (LDIFFERENCE FOO BAR) is EQUAL to FOO (ie, FOO and BAR share no
elements), DLisp will return a result which is EQ to FOO, while NLisp
returns a copy of FOO.

   Twinerik
-------
-------
*start*
00407 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 08:45 PST
From: Wallace.pa
Subject: Lisp: HARDCOPY bug
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

The HARDCOPY option in the background menu puts the mouse at (0,maxy).  It should just leave it where it was when the item was selected from the menu; that's where I'd expect to find it.
*start*
01114 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 16:11 PST
From: Sannella.pa
Subject: [JONL.PA: Fugue.6 release notes -- GENSYM]
To: LispSupport.pa

     ----- Forwarded Messages -----

Date: 26 MAR 84 14:31 PST
From: JONL.PA
Subject: Fugue.6 release notes -- GENSYM
To:   Raim.pasa
cc:   1100Support.pasa, LispCore^

Should mention that there is no effective upper limit on the numerical
suffix part of a GENSYM (current documentation only mentions that GENNUM
is initialized to 0 rather than 10000).  Consequence is that for larger
values of GENNUM, you get "longer" gensyms (but of course the numerical
suffix will be left-padded with 0's to get a minimum length of 5 characters).

Utilization of this extension is not only to make more gensyms available,
but more gensym  ** names **;  Thus one can imagine (and indeed Tayloe did
so for a while) having two separate, independent starting points for GENNUM
depending upon which sub-application was running (switiching between these
sub-applications involved re-setting GENNUM).


     ----- End of Forwarded Messages -----
*start*
00719 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 09:04 PST
From: Sannella.pa
Subject: [MASINTER.PA: GENSYM]
To: LispSupport.pa

     ----- Forwarded Messages -----

Date: 26 MAR 84 16:50 PST
From: MASINTER.PA
Subject: GENSYM
To:   JonL
cc:   1100Support.pasa, LispCore^

There still is the limit that Interlisp-D will only allow 32K symbols, and so thus there IS an effective limit if you start out at GENNUM = 0 of getting to GENNYM = 20000; the change to GENSYM thus doubles the limit, but doesn't remove it.

Some applications will want to just keep their own counter, e.g., Tayloe could merely

(PACK* "parser" (add PARSERCOUNT 1))


     ----- End of Forwarded Messages -----
*start*
01971 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 09:13 PST
From: Sannella.pa
Subject: [JONL.PA: Re: AR 305: RS232READBYTE won't compile]
To: LispSupport.pa

     ----- Forwarded Messages -----

Date: 26 MAR 84 20:54 PST
From: JONL.PA
Subject: Re: AR 305: RS232READBYTE won't compile
To:   Sannella, Jonl

In response to the message sent  26 Mar 84 15:45:30 PST (Monday) from Sannella.PA

Fixed (in current file on [Phylum]<Lisp>Library>RS232. and .DCOM)

------------
Date: 26 MAR 84 17:03 PST
From: JONL.PA
Subject: Re: AR 246: SINGLEFILEINDEX returns NIL instead of file list
To:   Sannella, Jonl
cc:   VANMELLE

In response to the message sent  22 Mar 84 10:10:13 PST (Thursday) from Sannella.PA

Fixed (on <LispCore>Library>) to return the FULLNAME of the file to be
listed (reading between the lines, the bug report implies that it is
LISTFILES rather than SINGLEFILEINDEX with the "disconcerting" behaviour,
even though it said SINGLEFILEINDEX -- the latter doesn't take a list of
files).

The returned value, FULLNAME of file, still is only a "hint" of file to be
listed, as opposed to the former behaviour that waited until after the file
was actually listed to return a value.  Once can lose under this new scheme
by deleting the lister process, even though LISTFILES/SINGLEFILEINDEX returned
a value to its caller process.


-----

Date: 26 MAR 84 17:04 PST
From: JONL.PA
Subject: Re: AR 247: SINGLEFILEINDEX divide by zero
To:   Sannella, Jonl
cc:   vanmelle

In response to the message sent  22 Mar 84 10:12:00 PST (Thursday) from Sannella.PA

Fixed not to depend upon (IQUOTIENT X 0)  ==> 0



-----

Date: 26 MAR 84 17:07 PST
From: JONL.PA
Subject: Re: AR 249: SINGLEFILEINDEX process should have BEFOREEXIT = DON'T
To:   Sannella, Jonl
cc:   vanmelle

In response to the message sent  22 Mar 84 10:24:55 PST (Thursday) from Sannella.PA

fixed (again, on <LispCore>Library)


     ----- End of Forwarded Messages -----
*start*
00305 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 09:57 PST
From: Sybalsky.pa
Subject: Lisp: AR 146, 281 fixed (TEdit peekbin/backbin)
To: LispSupport.pa, TEditsupport.pa
cc: Sybalsky.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dandelion

In the next TEdit.
*start*
00613 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 09:33 PST
From: Burton.pa
Subject: Lisp: documentation - legal chars for file names aren't described
To: LispSupport.pa
Lisp-System-Date: 27-Mar-84 08:53:34


I couldn't find any characterization of what file name are legal.  I think this may be dependent upon the file device (?do we want to change this?).  In any case I expected to find something like:

A file name is a sequence of any alphanumeric characters plus the characters {-, ~, @, \, /, etc.} (or whatever they are) containing at least one non-numeric character.
*start*
00597 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 09:14 PST
From: Wallace.pa
Subject: Lisp: Filebrowser
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

I understand that nobody's maintaining the filebrowser right now; this is just to get these in the queue

1>RENAME should take a default like COPY does; it's a pain to specify the same prefix each time.

2>Hardcopy should just print out on the prompt window, rather than popping up a big window.  Sometimes typein gets directed to this window, which aborts the hardcopy.

david
*start*
00601 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 10:10 PST
From: Wallace.pa
Subject: Lisp: Yet more filebrowser
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

Sorry; a couple of things I forgot in my last messge:

3> The rename prompt  is missing a ")" in its text

4> Would it be possible to have a mode in which subdirectories acted like real directories?  That is, (FILEBROWSER '<FOO>*) would not display files that began with e.g. "BAR>."  There could be a command which opened another filebrowser on a selected "subdirectory."
*start*
02897 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 15:12 PST
From: Ahenderson.pa
Subject: Lisp: Documentation for Co-existence with other environments on DLions
To: LispSupport.pa
cc: Ahenderson.pa
Lisp-System-Date: 13-Mar-84 10:21:31
Machine-Type: Dorado

Folk:

In discussion with Steve Purcell and Tayloe Stansbury, occasioned by repartitioning the DLion in the PARC Technical Information Center to enable the TIC to run Interlisp-D, it has become clear that the "GettingStarted" document needs to be augmented to include a simple model of the Mesa world, how Interlisp-D fits into it, and how to set up a DLion appropriately for various default sets of desired co-existing tools. In the long run, this information should be folded into a document which talks generally about all the environments which run on DLions, providing enough information to aid people to make the decisions necessary to partition their Dlion disks.

The "big picture" information which needs to be set down should include:

~~~~~~
General Model:
	A Dlion has a local "physical volume" (disk) .
	Storage capacity is measured in "pages"
	Different sized disks have 10K, 29K and 42K pages.
	The disk can be "partitioned" into at most 6 "logical volumes".
	Each volume has a fixed number of pages.
	Partitioning the disk erases it. Hence to repartition requires saving everything from all partitions on remote file servers, repartitioning, and then reloading. 
	Each volume has two kinds of code:
		Diagnostics
		Application
	Code is associated with a partition by "installing".
	Booting is a way of getting installed code to run.
~~~~~~	
Tools:
	The tool for partitioning is Othello
	The tool for installing is Othello
	Saving information before partitioning and restoring it after is done differently for each environment.
~~~~~~
Interlisp-D Environment: Model:
	Interlisp-D uses
		1 volume for Lisp
		1 volume (optional) for local file storage
		1 volume (optional) for ?
	The factors determining the size of these volumes are:
		Lisp: 16000 pages.
		DSK
		?
	Interlisp worlds are stored as large files (SYSOUTs).
	An Interlisp-D sysout can be installed as the diagnostic code of the Lisp partition.
	Lisp is started by booting ...
~~~~~~
Interlisp-D Environment: Tools:
	Installing Interlisp-D is done ...
	Running Interlisp-D is done ...
~~~~~~
Star is ...
~~~~~~
Tajo is ...
~~~~~~
CoPilot is ...
	Tajo plus a debugger
~~~~~~
CoCoPilot is ...
~~~~~~
XDE is ...
~~~~~~

In addition, a set of "common default" configurations should be identified, and command files written to support their creation. I think we have some of these already, but they need to be augmented to set up the Star world as well as the Lisp world and tested to insure that they are usable by folk without special privileges. Bill Winfield and Carol Lehner have offered to help with this latter phase.

Austin
*start*
00337 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 15:14 PST
From: masinter.pa
Subject: latest FULL.SYSOUT doesn't have nogreet hack
To: Burton
cc: Lispsupport


Richard, for reasons I don't quite understand, the latest FULL.SYSOUT didn't greet me when I started it.

What command file did you use?


*start*
01416 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 15:31 PST
From: masinter.pa
Subject: [RWEAVER.PA: Files retrieved from archive]
To: lispsupport

The sources for the Virtual Machine specification are currently on [maxc]<Netlisp>. The vm.partN files are more up to date. I think that some of the VM documentation could form the kernel for a more formal description of what Interlisp does internally (e.g., the exact specification of what FULLNAME does and its invariants is not a good subject for the Interlisp Reference Manual but would be a good subject for the VM document).



Date: 22 MAR 84 13:29 PST
From: RWEAVER.PA
Subject: Files retrieved from archive
To:   MASINTER

<NETLISP>VM.PUB;1
<NETLISP>VM.DFS;1   not retrieved - file already exists on disk
<NETLISP>VM.PART8;1   not retrieved - file already exists on disk
<NETLISP>VM.PART7;1   not retrieved - file already exists on disk
<NETLISP>VM.PART6;1   not retrieved - file already exists on disk
<NETLISP>VM.PART5;1   not retrieved - file already exists on disk
<NETLISP>VM.PART4;1   not retrieved - file already exists on disk
<NETLISP>VM.PART3;1   not retrieved - file already exists on disk
<NETLISP>VM.PART2;1   not retrieved - file already exists on disk
<NETLISP>VM.PART1;1   not retrieved - file already exists on disk
<BLISP>1982C.TXT;1
<DOC>PARC-GUEST.PASSWORD;6


     ----- End of Forwarded Messages -----
*start*
00617 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 18:43 PST
From: withgott.pa
Subject: TEdit: INCLUDE leaves open files
To: TEditSupport
cc: withgott.pa, VanMelle, Halvorsen
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dandelion

If you INCLUDE some files into an already-open TEDIT, OPENP shows both the main file and the included files to be open.

However, if you then PUT and QUIT out of TEDIT, the main file closes, but the included files hang around open.

(Bill - thanks for the word that I had 41 (count'em) files open!)

	-Meg
*start*
00492 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 24 Mar 84 23:38 PST
From: DMRussell.pa
Subject: TEdit: MBUTTON.FIND.NEXT.FIELD
To: TEditSupport
cc: DMRussell.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 13-Mar-84 10:21:31
Machine-Type: Dorado

A complaint about MBUTTON.FIND.NEXT.FIELD...

If I point MBNF after the last button in the text (e.g. at EOF),  it breaks.  (It tries to do a record access on an atom.)  Shouldn't do that!!  

-- DMR-- 


*start*
00446 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 14:29 PST
From: Halasz.pa
Subject: TEdit: Paragraphs with IMAGEOBJs do not maintain paragraph looks across put and get.
To: TEditSupport
cc: 
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

As the subject line says:  TEdit: Paragraphs with IMAGEOBJs do not maintain paragraph looks across put and get.

Frank

*start*
01472 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 MAR 84 19:02 PST
From: JONL.PA
Subject: DEFINEDP and FGETD
To:   masinter
cc:   LispSupport

It appears as thought DEFINEDP isn't documented -- it should be.  The
functionality of DEFINEDP is exactly that described in the manual for
FGETD -- why not flush one or the other?

No one adhering to the documented FGETD could be using its value in any
dangerous way -- i.e., all you can do is test it for non-NIL, or get the 
EXPR definition found in the definition cell (if it be an EXPR!) -- so
why not just do a MOVD(DEFINEDP FGETD) in, say, the DMISC file?

I see that about 30 functions in the shared system use FGETD -- I've looked
at a lot of them and they fall into two classes (each of which is dominated
by DEFINEDP).  Those used only for the NIL or non-NIL test on value, and
those which have already ascertained that "the contents of the definition
cell" is what is wanted, e.g., by calling EXPRP first.


The problem arises of extreme importance in that the kludgy DMACRO on
FGETD takes car of some random free variable set up by the compiler
environment; this breaks if you try to run with CAR/CDRERR on.

Another alternative is to have compiler-only macros, which the MacLisp
world calls either "optimizers" or "source-code rewrites", which would
turn FGETD into DEFINEDP under the appropriate circumstances.  But I think
just the MOVD mentioned above would be a simpler solution.

*start*
00816 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 MAR 84 21:17 PST
From: MASINTER.PA
Subject: DEFINEDP and FGETD
To:   JonL
cc:   LispSupport

I'm loath to add DEFINEDP as a "known" primitive. It should have been named \DEFINEDP.

There is then a second AR which says to rename DEFINEDP to \DEFINEDP, and fix the macro on GETD and FGETD not to take car of a "random" variable.

You've made a third suggestion, which is to separate out the "macro" properties that the compiler looks at from the ones that the interpreter or other macroexpanders look at. I'm reluctant to add that complexity.

Finally, unless superceded by any of the above, the problem of CAR/CDRERR=T calling CAR of a non-list should be fixed when expanding calls to GETD should be fixed.

Is that an accurate summary?
*start*
02831 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: masinter.pa
Date: 22-Mar-84 22:43:02 PST
Subject: ARs and questions on NSPrinter & Press
To: LispSupport, Kaplan

I suspect he is confusing Interpress and Press here. 

----------

Date: 22 March 1984 9:52 pm EST (Thursday)
From: DSnyder.henr
Subject: NSPRINTER.STATUS, HARDCOPYW, and EMPRESS
To: Cooper.PA
cc: Masinter.PA, DSnyder.HENR, KMatysek, PSWall

Eric,

I've been having trouble in trying to use NSPRINTER.STATUS to find out
whether EMPRESSing to a full press printer will be successful.

What I'm really after is to get hardcopy of Trillium screens.  What I do now is to
call NSPRINTER.STATUS, and if it says SPOOLER, FORMATTER, and PRINTER
are all AVAILABLE I do a HARDCOPYW to a file, and then EMPRESS the file. 
Unfortunately, however, all I ever get from the EMPRESS attempt is the [No
response from...] message.  I've got the variables CH.NET.HINT,
CH.DEFAULT.ORGANIZATION, and CH.DEFAULT.DOMAIN all set to the right
things (I think) and it seems that the printer is getting located without any
trouble.  (The printer, incidentally, is INCA, if you want to play from there. 
NET.HINT is 112, ORG is XEROX,  and DOMAIN is HENR801C.)

Is NSPRINTER.STATUS the wrong function to be using here?  Am I interpreting
its value incorrectly?  Obviously I don't want to go to the trouble of doing the
HARDCOPYW, &tc., if the printer is unavailable. 


A few other odds and ends:

At first I was trying just to HARDCOPYW to the printer (i.e., not going through
a file).  If I do this with just one screen image it seems to work just fine (or at
least I get the [No response from...] message), but if I do a bunch of
HARDCOPYWs in a row something seems to get all clogged up, and all the
background print jobs go into breaks, saying that the host isn't available, or some
such thing.  Why is this?  It seems to me it should all work okay.  I would like
to put in a request for an extra arg or something so that I can keep HARDOPYW
from doing a BLOCK, and avoid having to save images on files.  Or is there
someway to do this now?

I've had to advise the function STREQUAL.EXCEPT.FOR.CASE, because you're
calling it (I forget from where) with non-string arguments.  It doesn't matter if
the CH... variables are strings or not.

Is there some way I can use a regular press printer if I specify the right
SCALEFACTOR in the HARDCOPYW call?  How big can a window get before
it'll blow up a press printing attempt?  Perhaps at least I can send images less
than a certain size to our press printer.

I'd also like to know if there's any way at all to get a whole bunch of screen
images into a single file.  I've tried putting one image on a file, followed by ^L,
and another image, &tc. but couldn't get anything to work.

Thanks much for your help!

David

*start*
01630 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: masinter.pa
Date: 22-Mar-84 22:50:33 PST
Subject: Re: NSPRINTER.STATUS, HARDCOPYW, and EMPRESS
In-reply-to: DSnyder.henr's message of 22 March 1984 9:52 pm EST (Thursday)
To: DSnyder.henr
cc: Cooper, Masinter, KMatysek.henr, PSWall.henr, LispSupport.PA

(I forwarded your message to LispSupport.PA. Eric only comes in one day a week; the LispSupport mailbox is checked several times a day.)

I'm working from a portable computer with an 8-line display, and have to recall exactly what was in your message. I was a little confused about whether you have a PRESS printer (Raven, Dover) or an INTERPRESS printer. (Also, what version of Interlisp-D are you running, since the interface functions changed.)

(PRINTERSTATUS printername) should call the appropriate status function, and EMPRESS the appropriate printing function, no matter what type of printer it is.

There is are limitations on the complexity of the bitmap it can print, both Press and Interpress. Dovers of course have a limit since they don't do scaling. Ravens and other PRESS printers seem to do ok with arbitrary sizes. 8044s and NS printers would do better with full screen images except for an obscure limitation in the Interpress spec which we neglected to program around in Lisp; perhaps Kaplan can tell you more on that.

If you want to watch what is going on, you can

(a) turn on (XIPTRACE T) -- it will open up a window which allows you to watch Xerox Internet Packet traffic. Or, you can turn on (COURIERTRACE T) which shows all courier calls.

That may give some more clues.

*start*
01269 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 11:52 PST
From: Masinter.pa
Subject: Re: NSPRINTER.STATUS, HARDCOPYW, and EMPRESS
In-reply-to: DSnyder.henr's message of 22 March 1984 9:52 pm EST (Thursday)
To: DSnyder.henr
cc: LISPSUPPORT, Cooper.PA, KMatysek.henr, PSWall.henr

After looking at your message again, I suspect the problem is that when you call HARDCOPYW giving it a FILE argument, it generates a PRESS file instead of an Interpress file. Then, when you attempt to EMPRESS it, it sends it to the PUP host INCA rather than the NS host INCA. (Unfortunately, there is an INCA in the pup database as well as the NS printer INCA; the PUP and NS name spaces are independent.)

(PRINTERSTATUS "Inca:Henr801c:Xerox") and (after a long time because of network delays), got back a reasonable response.

There may be a problem of the separate HARDCOPYWs not properly monitor locking, which we will look into [LispSupport, note AR, Suspect problem with multiple HARDCOPYs in a row not interlocking, in Communications/NSProtocols].

STREQUAL.EXCEPT.FOR.CASE, yes, a real bug [LispSupport, note AR: STREQUAL.EXCEPT.FOR.CASE on COURIER should be replaced with comparison using UPPERCASEARRAY that allows atoms as well as strings]
*start*
00578 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 24 MAR 84 18:56 PST
From: MASINTER.PA
Subject: more on DRAWLINE
To:   lispsupport

Date:  3 Jan 84 02:23:41 PST (Tuesday)
From: lichtenberg.wbst
Subject: DRAWLINE opcode now in standard loadup
To: Lispcore^.pa
Reply-To: Lichtenberg.wbst
cc: lichtenberg.wbst


The DRAWLINE opcode (#59 decimal) is in <LispCore>Fugue>Lisp and Full.sysout and it appears to work OK.  Please report any suspicious RAIDs or MP codes to me if you encounter them while using DRAWLINE or something that calls it.

/Mitch.



*start*
00391 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 MAR 84 15:00 PST
From: ROACH.PA
Subject: Re: Lisp: funny error when DIR {FLOPPY} on unformated floppy
To:   masinter, LispSupport
cc:   ROACH

In response to the message sent   8 Mar 84 14:38 PST from masinter.pa

     The error makes sense to me.  Unformatted and CPM floppies
aren't Pilot floppies.
				Kelly
*start*
00388 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Mar 84 16:08 PST
From: masinter.pa
Subject: Re: Lisp: funny error when DIR {FLOPPY} on unformated floppy
In-reply-to: ROACH.PA's message of 8 MAR 84 15:00 PST
To: ROACH.PA
cc: masinter.PA, LispSupport.PA

I suggest we add an error "DEVICE UNINITIALIZED".

Most anything would be better than NIL (broken).
 

*start*
00689 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 11:05 PST
From: Sybalsky.pa
Subject: Re: TEdit: Poor choice of var names in MBUTTON.FIND.NEXT.FIELD!!
In-reply-to: DMRussell.pa's message of 26 Mar 84 22:54 PST
To: DMRussell.pa
cc: TEditSupport.pa

Just for that, I just changed the whole way the function operates, so it should be faster.  It also now returns NIL if it couldn't find a new fill-in blank, or the scratchsel if it did.  Also--now fill-ins don't need to be delimited with {} for the function to work right--it looks for a SELECTPOINT, then for the next PROTECTED boundary.  THis'll be in the next release of TEdit, when it is announced.
*start*
00322 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 11:08 PST
From: Sybalsky.pa
Subject: Re: TEdit: MBUTTON.FIND.NEXT.FIELD
In-reply-to: DMRussell.pa's message of 24 Mar 84 23:38 PST
To: DMRussell.pa
cc: TEditSupport.pa

This should be fixed; I just changed the function to be cleverer.
*start*
00493 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 10:27 PST
From: DMRussell.pa
Subject: TEdit: TeditMenu
To: TEditSupport
cc: DMRussell.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

Could the MarginBar and the TeditMenu  code be put into separate files?  I found the mixture very confusing when I was trying to read through the code.  What do those two have to do with each other anyway? 

-- DMR -- 

*start*
00388 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 11:07 PST
From: Sybalsky.pa
Subject: Re: TEdit: TeditMenu
In-reply-to: DMRussell.pa's message of 26 Mar 84 10:27 PST
To: DMRussell.pa
cc: TEditSupport.pa

The various parts of the code are separated in the fileCOMS; since it is code that TEDIT relies on, I see no urgent reason to separate the files.
*start*
00635 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 09:10 PST
From: Wallace.pa
Subject: Lafite: Shrunken sending window
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

Is the little shrunken letter important or just aesthetic (the shrunken message composition window)?  I find they clutter my landscape and would like to have a switch that just closes them after sending the message.

A related point: if you shrink the composition window before sending the message off, it still forms a little letter that says "1 Sent."

david
*start*
00285 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 11:01 PST
From: Wallace.pa
Subject: Lisp: SKREAD
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

Could SKREAD take an optional argument which is the readtable to use?

*start*
00725 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 11:02 PST
From: vanMelle.pa
Subject: Re: AR 315: LEAF should buffer a page ahead
In-reply-to: LispSupport.pa's message of 27 Mar 84 10:26:07 PST (Tuesday)
To: LispSupport.pa
cc: vanMelle.pa, JonL

Leaf already buffers a page (or more) ahead, at least when the file server is willing to give it that much allocation.  But note that if the file server is slow, or Lisp is fast, so that the time to fetch a remote page substantially exceeds the time to process a page, then it will still look like you are spending most of your time waiting for the remote server (especially since you can only do the backtrace when the process is waiting).
*start*
00540 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 11:05 PST
From: Burton.pa
Subject: Lisp: FILES? mis-feature on linefeed
To: LispSupport.pa
Lisp-System-Date: 27-Mar-84 08:53:34


FILES? takes linefeed as being same as previous response.  I think this should be changed to same as last named file.  The problem is that if you type "]" to ignore something,  linefeed will then ignore too.   

severity:  Annoying
Difficulty: easy
Impact: slight incompatible change, must fix documentation and announce. 
*start*
00625 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 11:11 PST
From: masinter.pa
Subject: Re: AR#318: Interlisp-10 / -D incompatible behavior: LDIFFERENCE
In-reply-to: LispSupport.pa's message of 27 Mar 84 10:44:42 PST (Tuesday)
To: LispSupport.pa
cc: Shulman@Rutgers, Weinrich@Rutgers, Design@Rutgers

The definition for LDIFFERENCE has not changed since 1978, and is the same in Interlisp-10 and Interlisp-D; in both cases, if BAR contains no elements in common with FOO, the result of (LDIFFERENCE FOO BAR) is a (top-level) copy of FOO.

[LispSupport, please mark AR#318 as "Declined"]


*start*
01023 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Return-Path: SHULMAN@RUTGERS.ARPA
Received: from RUTGERS.ARPA by PARC-GW.ARPA ; 27 MAR 84 15:03:48 PST
Date: 27 Mar 84 18:03:54 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: Re: AR#318: Interlisp-10 / -D incompatible behavior:
To: masinter.pa, LispSupport.pa
cc: Weinrich@RUTGERS.ARPA, Design@RUTGERS.ARPA
In-Reply-To: Message from "masinter.pa@PARC-GW.ARPA" of 27 Mar 84 14:11:00 EST


	Perhaps you didn't understand:  Interlisp-D is *not* returning a
copy of the list but the list itself.  The problems Tim Weinrich is having
is that his code does destructive modifications on this result.  Since in
Interlisp-D this is not a copy he is modifying his original list (which he
doesn't want to do.)
	I should mention that the current manual does not state whether
a copy or the original list is returned.
	I do think that in either case both Interlisp's should be consistant
(or a note in the manual saying they aren't.)

						Jeff
-------
*start*
01093 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 16:23 PST
From: Masinter.pa
Subject: Re: AR#318: Interlisp-10 / -D incompatible behavior:
In-reply-to: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>'s message of 27 Mar 84 18:03:54 EST
To: SHULMAN@RUTGERS
cc: masinter.pa, LispSupport.pa, Weinrich@RUTGERS, Design@RUTGERS
reply-to: LispSupport

now I understand what is going on. There are two different versions of LDIFFERENCE on two different files in Interlisp-10. The duplicate version is in the Interlisp-10 compiler (LAP), which isn't loaded into Interlisp-D.

Now we have the separate problem of deciding which version is right. I kind of think

(DEFINEQ (LDIFFERENCE (LIST1 LIST2)
(for X in LIST1 when (NOT (MEMBER X LIST2)) collect X)]

is the right definition.

Actions here are (a) remove duplicate version of LDIFFERENCE from LAP, (b) remove duplicate LDIFFERENCE from either MISC or MACHINEINDEPENDENT, (c) change definition to be the above iterative.

The workaround is to install the above definition.

Thank you for tracking this one down.

Larry

*start*
00266 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 17:19 PST
From: Masinter.pa
Subject: Re: AR#318: Interlisp-10 / -D incompatible behavior:
In-reply-to: Masinter.pa's message of 27 Mar 84 16:23 PST
To: LispSupport.pa
cc: 

fixed
*start*
00510 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 March 1984 11:16 am PST (Tuesday)
From: DMRussell.PA
Subject: TEdit: Poor choice of var names in MBUTTON.FIND.NEXT.FIELD!!
In-reply-to: Sybalsky's message of 27 Mar 84 11:05 PST
To: Sybalsky
cc: DMRussell, TEditSupport

Thanks for the quick response!  Everything looks pretty good.  

Now, if I can only have horizontal scrolling.....

(I suppose that will have to wait.  I can work around it w/o too much problem.)

-- DMR -- 


*start*
00538 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 MAR 84 11:12 PST
From: ROACH.PA
Subject: LISTFILES FAILS TO LIST NON-INTERLISP FILES
To:   LISPSUPPORT, JONL
cc:   ROACH

     I'm sick and tired of this problem.  It almost seems that 
LISPCORE^ isn't even considering the possibility of a user wanting
to list a file not made with MAKEFILE.  Various text files always
try to be parsed as filepackage files, fail, break, and don't list.
The latest failure: (LISTFILES {PHYLUM}<WALLACE>EMACS>COMS).
				Kelly
*start*
00232 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 MAR 84 11:15 PST
From: ROACH.PA
Subject: RE: Previous msg
To:   LISPSUPPORT

     The test case is (LISTFILES {PHYLUM}<WALLACE>EMACS>PRIMIT).
				Kelly
*start*
00518 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 11:14 PST
From: masinter.pa
Subject: Lisp: AR#226
To: LispSupport.pa
cc: vanMelle
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dorado

Please mark this attn: vanMelle. I think this one must be "declined" until we can distill a better AR, (like "make ^B work better? Or Implement better TeleRaid commands?")

Change status to Open,  not New. Dunno about "impact/frequency, etc.". (Bill, maybe you want to "decline" this one?)
*start*
00664 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 15:16 PST
From: vanMelle.pa
Subject: Re: Lisp: AR#226
In-reply-to: masinter.pa's message of 27 Mar 84 11:14 PST
To: masinter.pa
cc: LispSupport.pa, vanMelle.pa

Well, it seems like this one has three parts:

1) Fix the 9016 bug.  This is hard to do unless they're willing to TeleRaid it immediately (not typing ^B) and/or provide some further context.

2) Fix the TeleRaid user to not break.  That's in my domain.  Impact: annoying; Difficulty: easy to moderate; Priority: Perhaps.

3) Make ^B in TeleRaid always work.  Difficulty: Very Hard to Impossible; Priority: Unlikely.
*start*
01084 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 11:17 PST
From: vanMelle.pa
Subject: Re: AR 209: Lafite MoveTo confirmation after menu
In-reply-to: Sheil.pa's message of 26 Mar 84 18:00 PST
To: Sheil.pa
cc: vanMelle.pa, LafiteSupport.pa

No, the system is not in desperate trouble.  Of all the menus from which you might pick the wrong item, there are very few cases where choosing the wrong item has a major penalty.  In the case of MoveTo, however (a) the only feedback about the choice you made is the tiny "default moveto" line in the title, and (b) even if you notice that it's doing the wrong thing, you can't simply abort the operation or select "Undo" to recover--you have to browse the destination file and delete the unwanted message.

There are surely other examples in the system that are deficient in this regard (the !Undo item in Dedit, which is not undoable, comes to mind), and I would recommend fixing them.

Mind you, I'm not crazy about Lafite's MoveTo interface.  I've been searching for some while for a better one.

	Bill
*start*
00354 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 11:31 PST
From: Sybalsky.pa
Subject: Lisp: AR action
To: LispSupport.pa

Please mark AR 154 attn Nuyens
AR 282 duplicates ar 45, and is fixed.
AR 62 is duplicated by 102, 157.
AR 252 duplicates AR 44
AR 210 duplicates 69.
AR 263 is a wish, and is unlikely.

Thanks.

*start*
00495 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 MAR 84 11:46 PST
From: ROACH.PA
Subject: TEDIT.INSERT LOOKS ARG DOESN'T WORK
To:   LISPSUPPORT
cc:   ROACH

     I do
	(TEDIT.INSERT {STREAM}... "L" {SELECTION}...
		      {FONTDESCRIPTOR}#5,15416)
and TEDIT breaks, passing args
	STREAM = {FONTDESCRIPTOR}#5,15416
	LOOKS = NIL
to TEDIT.CARETLOOKS.
     Why (according to documentation) aren't values for LOOKS args
in TEDIT.INSERT & TEDIT.LOOKS the same?
				Kelly
*start*
00315 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 12:23 PST
From: Burton.pa
Subject: Lisp: dc different from DC
To: LispSupport.pa
Lisp-System-Date: 27-Mar-84 08:53:34

dc FOO generates a  "NIL is not a loaded file" even when 

DC FOO

gets an editor onto the COMS.  

richard

*start*
00531 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 15:44 EST
From: Denber.wbst
Subject: KAL
To: Lispsupport.pa
cc: VanMelle.pa

I have moved the latest version of KAL.DCOM, along with a short documentation file KAL.TED to {Phylum}<Lispusers>.  This version allows switching between color and b/w screens, and includes a middle-button menu for stopping the KAL process and for twiddling the drawing parameters.

I assume this is the proper procedure for updating Lispusers packages.

			- Michel
*start*
00373 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 13:20:14 PST (Tuesday)
From: JFung.pasa
Subject: AR#279 InstallLispTool should allow booting non-LispVMem volumes
To: LispSupport.pa
cc: Stansbury.pa, JFung, 1100Support

Mike,

New version is filed at [phylum]<LispCore>Next>InstallLispTool.bcd.

I edited AR status{} _ Fixed.

	/Jerry
*start*
00432 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 13:29 PST
From: Sybalsky.pa
Subject: Re: TEdit: No way to close a TEDIT menu once opened
In-reply-to: Halasz.pa's message of 21 Mar 84 21:18 PST
To: Halasz.pa
cc: TEditSupport.pa

Just use the QUIT menu button, arrived at by buttoning in the MENU's title.  I grant this is hackish, but it should hold you until I get a better solution in place.
*start*
00347 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 13:30 PST
From: Sybalsky.pa
Subject: Re: TEdit: Get & Include
In-reply-to: Stansbury.pa's message of 21 Mar 84 18:24 PST
To: Stansbury.pa
cc: TEditSupport.pa

I'm with Larry--when it becomes a general system feature, I'll support it.  'Til then, payoff<<pain.
*start*
00643 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 14:14 PST
From: Jellinek.pa
Subject: Lisp: Wanted:  DLion area-fill microcode
To: LispSupport.pa
cc: Jellinek.pa, Lichtenberg.wbst
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dolphin

Larry Masinter suggested I make this suggestion "official":   I'd love for there to be an AREAFILL instruction added to the DLion microcode repertoire, for doing filling of arbitrary polygons drawn on bitmaps.

I really don't know enough about DLion microcode (yet) to spec this out in any great detail, but I would appreciate all comments and suggestions.

		Herb
*start*
00317 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 14:19 PST
Sender: Jellinek.pa
Subject: Lisp: OUTFILEP and core devices
To: LispSupport.pa
From: masinter.pa
cc: masinter.pa
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dolphin

OUTFILEP for core devices always returns NIL.
*start*
00369 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 14:48 PST
From: Masinter.pa
Subject: Lisp: AR#255
To: LispSupport.pa
cc: Masinter.pa
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dorado

change to Environment/History rather than Language/Stack&Interp.

It is the history-reader that messes this up. 

Difficulty, moderate.


*start*
00485 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 15:24 PST
From: vanMelle.pa
Subject: Re: AR120: Cedar-type WhoPointsTo
To: Maxwell
cc: LispSupport, vanMelle.pa

The Library package GCHAX has a function \FINDPOINTER that does the job more crudely and perhaps less reliably--not by a mark and sweep GC but just by a sweep of memory.  I have found it quite useful for finding storage leaks.  I don't know what other purposes you had in mind.

	Bill
*start*
00232 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 15:32 PST
From: vanMelle.pa
Subject: AR#273
To: LispSupport

Should be Language/DLion micrcode.  And Don claims to have found and fixed the bug.
*start*
00355 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 15:38 PST
From: Masinter.pa
Subject: Lisp: ar#179, Performance Certification Tools
To: LispSupport.pa
cc: JonL
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dorado

Priority Hopefully, attn JonL (I guess). 

JonL, do you think you should get these? (Look at AR).
*start*
00287 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 16:06 PST
From: Masinter.pa
Subject: AR#175: args to \ALLOCBLOCK?
To: LispSupport
cc: Kaplan

please change fields:

Attn: Kaplan, Subject: Document \ALLOCBLOCK, Priority: Perhaps, Difficulty: Easy


*start*
00613 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 16:06 PST
From: vanMelle.pa
Subject: Re: AR#258 Registry setting
To: Marshall.wbst
cc: LafiteSupport

Yes, Lafite should take the hint from your disk name; it currently is going thru an interface that strips off the registry therefrom.

Meanwhile, Lafite works quite nicely if you set DEFAULTREGISTRY to your local registry (e.g. WBST).  This is a variable that is expected to be set in the site init file (the thing that lives as {dsk}init.lisp).  Mention of it was inadvertantly left out of the Lafite documentation.

	Bill
*start*
00268 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 17:40 PST
From: Masinter.pa
Subject: submit AR, rename PutFloat, MAKEFLOATNUMBER to \ fns
To: LispSupport
cc: Masinter.pa

Language/Arithmetic, attn: Masinter.

Annoying/Possibly


*start*
00406 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 19:30 PST
From: desRivieres.pa
Subject: TEdit: ARG NOT IMAGEOPS
To: TEditSupport
cc: 3LispSupport^.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dorado

It is impossible to PUT a file:

ARG NOT IMAGEOPS
{**DEALLOC**}#1,73740

under OLDCLOSEF under CLOSEF under TEDIT.PUT


*start*
00381 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 09:18 PST
From: Sybalsky.pa
Subject: Re: TEdit: ARG NOT IMAGEOPS
In-reply-to: desRivieres.pa's message of 27 Mar 84 19:30 PST
To: desRivieres.pa
cc: TEditSupport.pa, 3LispSupport^.pa

PUT works just fine for me; if you could be a bit more specific about what you were doing and how you did it?
*start*
00270 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 20:06 PST
From: Burton.pa
Subject: Lisp: bug in RAND
To: LispSupport.pa
Lisp-System-Date: 27-Mar-84 08:53:34


(RAND 0 65536) returns negative numbers about half the time!!!

richard
*start*
00386 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 21:22 PST
From: Burton.pa
Subject: Lisp: fn to read connected directory?
To: LispSupport.pa
cc: LispCore^
Lisp-System-Date: 27-Mar-84 08:53:34

Is there a way to determine the connected directory?  If not, it seems like a reasonable thing to have.  If so, it should be indexed from CNDIR.

richard

*start*
00325 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 22:25 PST
From: Stansbury.pa
Subject: Re: Lisp: fn to read connected directory?
In-reply-to: Burton.pa's message of 27 Mar 84 21:22 PST
To: Burton.pa
cc: LispSupport.pa, LispCore^.pa

Won't (DIRECTORYNAME T) do what you want?

-- Tayloe.
*start*
00520 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 21:58 PST
From: Masinter.pa
Subject: FIXED: RAND(0 70000) returns negative values
To: LispSupport.pa
cc: burton
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dorado

Submit as FIXED. The problem was that internally RAND was calling IREMAINDER on a large number where it should have been calling IMOD (since the internal random state as 2 16-bit numbers could have represented a negative number.).

I fixed it, for next loadup.

*start*
01535 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 22:02 PST
From: Masinter.pa
subject: Transor
In-reply-to: LINKOPING@BBNG.ARPA's message of Sun, 25 Mar 84 08:12:23 EST
To: Linkoping@bbng
cc: LispCore^, 1100Support, Xerox1100UsersGroup^.pa

I had originally lobbied that Transor should be withdrawn as being "hopelessly obsolete"  as you mentioned. However, a number of people requested it, and some of them reported back that they had found it quite useful (although they had avoided prescan.)

Thus, TRANSOR is still distributed (without any particularly useful transor-forms), although the appropriate caveats are usually not listed.

One of the pitfalls of translation is that doing a "correct" job usually involves more proof techniques than the ordinary programmer has at his disposal. For example, in order to accurately change the order of arguments, you need to guarantee that the computation doesn't depend upon the order of evaluation; if it does, you have to go to more lengths to translate. 

Secondly, the "langauge" of Lisp is quite small; what differentiates one Lisp from another is not the language (COND, SELECTQ, LAMBDA) but the "library" (window, linear programming, history, etc.), where some library packages tend to be either machine dependent or proprietary.

In any case, as Dave Dyer suggests, emulation tends to work better than translation (sometimes emulation means hiding the transformations underneath macros and letting the compiler do the optimization phase). 



*start*
00450 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 22:57 PST
From: desRivieres.pa
Subject: TEdit: My previous problem report
To: TEditSupport
cc: 3LispSupport^.pa
TEdit-System-Date:  1-Mar-84 13:54:34
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

I have just noticed that I had {PHYLUM}<LISP>LIBRARY>EXPORTS.ALL loaded.  Perhaps that was what caused the problem with the deallocated objects.


---Jim
*start*
00418 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 22:37 PST
From: Masinter.pa
Subject: Lisp: FB {PHYLUM}<LISP*>*.OTHELLO gives lines like <URRENT>PARTITION, <UGE>INSTALL, etc.
To: LispSupport.pa
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dorado

wierd behavior when directory contains wildcard.

System OS/Generic File. Attn: ???? (wish I knew)

Annoying/EveryTime/Perhaps
*start*
00940 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 23:06 PST
From: Masinter.pa
Subject: Lisp: microcode enhancements
To: LispSupport.pa
cc: sheil (fyi)
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dorado

This is one of several ARs on rewriting ALL microcodes to include new opcodes. Looking at the function inside Rosie that is taking up the most time, I believe it would be helped substantially by (not necessarily in this order):

(a) microcoded ELT
(b) microcoded LLSH
(c) microcde combining CAR/CDR chains to length 2 or 3
(e.g., CAAR, CDDR, CADR, although CDDR is most prevelant)
(d) JEQ (if faster than EQ/TJUMP)
(e) stack relative addressing, if it enabled the stack optimization I had partially implemented
(f) microcoded FASSOC
(g) special (CONS x NIL) opcode, maybe (LIST X Y) opcode.

[big memory helps if memory/compute time is large; compute time can dominate with bad compiled code]
*start*
06977 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 23:14 PST
From: Masinter.pa
Subject: [masinter.pa: [Deutsch.pa: BitBlt timings]]
To: LispSupport

AR, category Benchmarks (I know we don't have that category, maybe we should start marking the ones that don't have a good category with something that our converter can recogize?)

Anyway, the AR is to please run these benchmarks, distribute the results to LispCore^ first for comment (e.g., if not better than Smalltalk figures, there is something wrong because ST-80 has more overhead getting in and out.)


     ----- Forwarded Messages -----

Date: Wed, 21 Mar 84 21:36:09 PST
From: Deutsch.pa
Subject: BitBlt timings
To: Wyatt, Masinter, Trow
cc: Adele, Ingalls

Folks,

I would appreciate it if you would run Rob's timing measurements on, respectively, Mesa (Cedar or not, your choice) on the Dorado and Dolphin, Interlisp on the Dorado and Dolphin, and Smalltalk on the Dolphin.  The Smalltalk code I used for my measurements is on [Filene]<Deutsch>BitBlt-class-timing.st.

I consider the Smalltalk measurements non-proprietary, since the essential information about the performance of Smalltalk BitBlt on the Dorado and Dolphin has already been published (in the second Smalltalk book).  However, if you feel more proprietary about the other systems, feel free to decline.  Also, if you feel it would be appropriate to run timings on the Dandelion for Mesa and Interlisp, please feel free to do so.

Please send the results directly to Rob, cc to me.

------------------------------
Date: Wed, 20 Jan 15 0:16:00 EST
From: rob.btl@csnet-relay.arpa
To: deutsch%parc-maxc.csnet-relay@csnet-relay.arpa
Received: from CSNET-RELAY.ARPA by PARC-MAXC.ARPA; 21 MAR 84 15:55:03 PST, by csnet-relay via btlpob;  21 Mar 84 5:05 EST

Dear Peter, BitBlt Aficionado:

I am working on a bitmap graphics course for SIGGRAPH this year, and would
like to include in the course notes a sort of catalogue of bitblt
implementations.  I would greatly appreciate timing figures on the
following uses of BitBlt:

	scroll 800wide x 1024high bitmap 1 pixel horizontally
	scroll 800wide x 1024high bitmap 1 pixel vertically
	draw 8wide x 7high character in XOR mode at random bitmap positions
	texturing in XOR mode a 40x40 square at random bitmap position

For the last two, I want the time averaged over all distinguishable x
positions, to remove any artifacts due to word boundaries.  The 8x7
character is chosen by the minimum enclosing rectangle of our 'a'.
These tests are, like most benchmarks, quite arbitrary, but I am hoping
to get enough different machines to make comparisons interesting.
Note that I am after BitBlt timings, not equivalent timings for special-
purpose primitives or what you an achieve by careful hand-coding for the
examples.  Basically, how fast can BitBlt do these tasks?

On the phone you mentioned the Dolphin and Dorado as subjects.

Many thanks for your time.



				-rob


------------------------------
Date: Wednesday, 21 March 1984, 9:27:45 pm
From: Deutsch.pa
To: rob.btl@csnet-relay
In-Reply-To: "rob.btl@csnet-relay.arpa's message of Wed, 20 Jan 15 0:16:00 EST"
sent-from: Chelsea

Rob,

Here are the results for the Dorado running Smalltalk.  The scrolling numbers were obtained by taking the numbers for an 800 wide x 512 high bitmap and doubling, since the Dorado's display is 1024 wide x 808 high.  The numbers appear to be repeatable to within about 2%.

	scroll 800wide x 1024high bitmap 1 pixel horizontally
		23.8 ms
	scroll 800wide x 1024high bitmap 1 pixel vertically
		23.3 ms
	draw 8wide x 7high character in XOR mode at random bitmap positions
		51.2 microseconds
	texturing in XOR mode a 40x40 square at random bitmap position
		156 microseconds

By "texturing" I assume you mean tiling with a non-white, non-black bitmap (on the Dorado the tile size is 16 x 16).

Note that for the last two tests I used uniformly distributed but not random bitmap positions, namely, for i = 0 to 15 do test(i * 247 rem 400).  This makes the Dorado look a little worse than necessary, because it tends to produce more faults in the memory cache.  On the second test, this appears to be significant (the time was only 133 microseconds when I used consecutive coordinates). 

I'll ask someone else to run it on the Dolphin, and perhaps on the Dorado in Mesa and/or Lisp.

Please send us a copy of the complete set of timings from all the machines you find out about.

Have fun,

P.

Date: 22 MAR 84 09:59 PST
From: MASINTER.PA
Subject: BITBLT timings
To:   deutsch
cc:   wyatt, masinter, trow, adele, ingalls

Sometimes it isn't that the figures are proprietary, but merely that it is in bad form to distribute them. We've been cautious about benchmarks of Interlisp-D coming from Xerox, because, while Xerox customers are free to perform timings and publish them, if XEROX publishes them, there is some implication that we think that they are meaningful, complete, consistent with the methodology of other benchmarks, etc.

For example, in Interlisp-D one CAN construct ahead of time the bitblt table, and then just measure the time of the BITBLT opcode itself; alternatively, one can include the setup overhead. 

While setup overhead should be included because it is incurred by most users, I wonder about the methodology others might use in generating the same figures for his tables. Distributed benchmarking performed by lots of people (some more gung-ho vendors than others) can have a lot of variation in the method of measurement. (As opposed, say, to the Smalltalk benchmarks which have some hope of being the same program.

With all of that said, I would be interested in contributing Interlisp-D timings if in exchange I could get a copy of all of his course materials. (This is what is known as Scientific Interchange.)

   

Date: Thu, 22 Mar 84 11:17:30 PST
From: Deutsch.pa
Subject: Re: BITBLT timings
To: MASINTER
cc: wyatt, trow, adele, ingalls
In-Reply-To: "MASINTER's message of Thu, 22 Mar 84 9:59:00 PST"

I'm sure Rob would be happy to send us a copy of the full course materials.  I understand your concerns about benchmarks, and I think it would be appropriate for you to communicate them to Rob when you send him the numbers.

Just for your information, the measurements I did from Smalltalk did NOT include user-level setup overhead.  In other words, they were the best that a user can get out of the system, by calling the BitBlt method with an already set-up table.  (Since Smalltalk doesn't have anything corresponding to the LL level, you still have to pay some lower-level overhead for testing the BitBlt table arguments for being SmallIntegers, extracting some parameters from the bitmap objects. etc.)  I believe that this is the most appropriate measure of BitBlt's performance for Rob's purposes, since some Smalltalk system code actually approaches this level of performance pretty closely.
     ----- End of Forwarded Messages -----
*start*
00489 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 23:27 PST
From: Masinter.pa
Subject: CALENDAR.dcom
To: Denber.wbst
cc: LispSupport

Hi -- Michel, where is Source & documentation for CALENDAR program on <LispUsers>?

LispSupport: add to the "periodic task list" to check over the <LispUsers> directory for files without corresponding source & documentation.  (what, you don't have a list already of 'jobs that need to be done every once and awhile?')
*start*
00386 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 12:58 EST
From: Denber.wbst
Subject: Re: CALENDAR.dcom
In-reply-to: Masinter.pa's message of 27 Mar 84 23:27 PST
To: Masinter.pa
cc: LispSupport.pa

Source is on Ice, documentation is in my head.  I hope to move both to Phylum (source + docs, not my head, that is) by the end of today.

			- Michel
*start*
00540 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from RUTGERS.ARPA by PARC-MAXC.ARPA; 28 MAR 84 08:13:31 PST
Date: 28 Mar 84 11:13:32 EST
From: Tim <WEINRICH@RUTGERS.ARPA>
Subject: Re: AR#318: Interlisp-10 / -D incompatible behavior:
To: LispSupport.pa, SHULMAN@RUTGERS.ARPA
cc: masinter.pa, Design@RUTGERS.ARPA
In-Reply-To: Message from "Masinter.pa@Xerox.ARPA" of 27 Mar 84 19:23:00 EST


   I agree that returning the copy is probably the correct behavior.
Thanx for looking into it.

   Twinerik
-------
*start*
00964 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 09:54 PST
From: Jellinek.pa
Format: TEdit
Subject: Lisp: Want: Siggraph 2D core graphics
To: LispSupport.pa
cc: Jellinek.pa
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dolphin

Now that I'm in the thick of writing this business-graphics package, I've come to the realization that I'm working on the wrong project.  What Interlisp-D really needs is a graphics package with at least Siggraph 2D core capabilities.  Meaning: support for windows (not our kind, the traditional graphics kind), viewports, clipping, etc.  Having something like that would have greatly simplified the package I'm writing now, and would have made it easier to augment.

It's too late for me to back out of what I've written so far, unfortunately;  I just want to add this idea to the wish list.

		Herb

‹
TIMESROMAN
TIMESROMAN

Ž
TIMESROMAN!z·*start*
01252 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 18:02 PST
From: Masinter.pa
Subject: [DSnyder.henr: Re: NSPRINTER.STATUS, HARDCOPYW, and EMPRESS]
To: LispSupport, Kaplan, Sybalsky

Can you help this fellow out? 

(a) pointer to relevant documentation?
(b) a phone call assistance?

[I think it is important to help him]


     ----- Forwarded Messages -----

Date: 26 March 1984 8:58 am EST (Monday)
From: DSnyder.henr
Subject: Re: NSPRINTER.STATUS, HARDCOPYW, and EMPRESS
In-reply-to: Masinter.pa's message of 23 Mar 84 11:52 PST
To: Masinter.pa
cc: DSnyder

Thanks for the reply.  Your diagnosis sounds good but suggests no good
solution.  Would it work to make the NS Inca into a printerdevice (using
PRINTERDEVICE(INCA)), and then HARDCOPYW(bitmap {INCA})??  How does
the use of a colon in the printer's name (INCA vs. INCA:)  affect things?  Will
HARDCOPYW *always* make a press file?

Can you answer my other questions about appropriate SCALEFACTOR for a file
containing a large (e.g., full screen) image going to a press printer (AZTEC), and
multiple images on one file?

I'm kind of desperate about getting this all straightened out very soon.

Thanks again!!


     ----- End of Forwarded Messages -----
*start*
02613 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 22:30 PST
From: Masinter.pa
Subject: Re: NSPRINTER.STATUS, HARDCOPYW, and EMPRESS
In-reply-to: DSnyder.henr's message of 26 March 1984 8:58 am EST (Monday)
To: DSnyder.henr
cc: lispsupport, kaplan, sybalsky

I don't think you need to get that complicated.

The problem is that the current interface to HARDCOPYW doesn't give you the option of saying what KIND of file you want; it attempts to read it from the printer type, but if you just want the file and no printer, then that isn't so good.



I don't think  you need to make NS Inca into a printerdevice. 

(Note to LispSupport: In fact, the PRINTERDEVICE interface I think is pretty bogus, since you can send things directly to the printer using {LPT}printername, e.g., {LPT}INCA:. The "device" interface is a little clunky in its own right, because it buffers in a funny way.)

The original problem (did you get back an AR#?) was that you were getting back a lot of spurious problems. To straighten things out:

If you want to talk about INCA as a printer, and it is a NS printer, then you will do best by ALWAYS saying INCA:, or INCA:HENR801A etc.  

You MIGHT be able to get away with saying INCA if you also do PUTPROP(INCA PRINTERTYPE INTERPRESS).

If you want HARDCOPYW to create a file and not print it, it will currently always create a file that is of type appropriate for (PRINTERTYPE) = printer type of first element of DEFAULTPRINTINGHOST.  So, HARDCOPYW will create press files if your DEFAULTPRINTINGHOST is of type PRESS, and interpress files if it is of type INTERPRESS.

Now, Interlisp knows about two KINDS of PRESS printers, those that are (PRESS SPRUCE PENGUIN DOVER), and those that are (FULLPRESS RAVEN). The only difference as far as Interlisp-D is concerned is that FULLPRESS printers know how to handle scaling; the Lisp system throws away the scalefactor if you are going to a PRESS printer because it knows that Spruce/Dover/etc. print software can't handle it.

[LispSupport: it COULD break up the image into pieces and print them on several pages]

As far as I can tell, AZTEC is neither; it is an IFS (file server). Did you mean somebody else? 

Finally: if you want to put multiple images on one file you are beyond the current capabilities of the Interlisp-D software. We would like this capability as part of a more global rewrite of the interface to printing (where the way to send an image to a file is via BITBLT) but haven't implemented this yet.  Can you please tell us more about your need, it may help in some priority setting.


*start*
00825 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 11:56 EST
From: Denber.wbst
Subject: Lisp: PROMPTREMINDERS
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dolphin

2_FILES?]
CALENDAR. . . to be dumped.
    plus the Periodic PROMTP Reminders: A0005,A0003,A0002
want to say where the above go ? Yes
(Periodic PROMTP Reminders)                <-- check spelling
A0005   File name: REMS
   new file ? Yes
A0003  REMS
A0002  REMS
NIL
3_(CLEANUP]
REMS. . .

FILE WON'T OPEN
{ICE}<DENBER>LISP>REMS.;1
Leaf error: 111 File open in conflicting way - file busy.

(OPENSTREAM broken)
4:

The file was new to FILES? (did not exist before), how did it get to be busy now?  Did Dan Russell ask you about letting reminders activate user-defined functions?  Thanks.

			- Michel

*start*
00692 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 16:21 EST
From: Denber.wbst
Subject: Re: Lisp: PROMPTREMINDERS
In-reply-to: LispSupport's message of 27 Mar 84 11:40:01 PST (Tuesday)
To: LispSupport.PA

I just tried it again and this time it worked.  What's different is that for one I had to reinit Lisp since my system started giving me that "bad compiled function" stuff again (and this time I *am* using both the new microcode and lisp.run).  I had also edited the COMS of the file (to remove a VARS list) the time it didn't work.  Don't know if those two things had anything to do with it.

			"Nobody told me there'd be days like this"
			- Michel
*start*
00824 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 17:38 EST
From: Denber.wbst
Subject: Lisp: Wedged Again
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dolphin

It's happened again.  I just started this system about an hour ago and have done nothing unusual with it.  I loaded COLOR.DCOM, RS232.DCOM, and CALENDAR.DCOM no problem.  Then I did some Lafite, Chat, and a few COPYFILE's.  Then I tried to do (LOADFNS 'COLORDISPLAYP '{PHYLUM}<LISPCORE>SOURCES>LLDISPLAY.DCOM) and boom!  Bad compiled function.  Now I can't load anything.

	 A		RRRR	GGGG	GGGG	H     H
      A A 		R     R	G	G	G	G	H	H
     A   A		RRRR	G		G		HHHH
    AAAA		R R		G		G		H	H
  A	     A	R   R	G   GG	G    GG	H	H
 A 	      A	R     R	G	 G	G	  G	H	H
A		A	R       R 	  GGG	  GGG	H	H

			- Michel
*start*
00675 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 11:30 PST
From: Burton.pa
Subject: Lisp: ATTACHEDWINDOW
To: LispSupport.pa
cc: Sybalsky.pa
Lisp-System-Date: 27-Mar-84 08:53:34

I added a feature to attachedwindow that makes it convenient for the attached window to allow itself to be closed.

WINDOWCOMACTION can be 'LOCALCLOSE in which case, CLOSE on the attached window closes and detached it.

This will allow the teditmenu and break backtrace menus to be closed independently from their main windows.

Updated documentation is on <lispcore>library>attachedwindow.ted (because I couldn't think of any place else to put it.)

richard
*start*
00227 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 12:16 PST
From: Masinter.pa
Subject: extra file [phylum]<lispusers>coewave
To: Roach
cc: LispSupport

probably got written there by mistake
*start*
00293 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 MAR 84 13:02 PST
From: ROACH.PA
Subject: Re: extra file [phylum]<lispusers>coewave
To:   Masinter
cc:   LispSupport, ROACH

In response to your message sent  28 Mar 84 12:16 PST

     Yup.  Now deleted.
				Kelly
*start*
00754 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 12:34 PST
From: Jellinek.pa
Subject: Lisp: Want: DLion matrix multiply microcode
To: LispSupport.pa
cc: Jellinek.pa
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dolphin

Two new DLion instructions to consider:

	 an instruction that will multiply two 3 x 3
	  floating-point matrices (useful for doing
	  two-dimensional homogeneous coordinate
	  transformations).

	 another one for doing 4 x 4 matrix multiplication
	   (for 3-D homogeneous coordinate
	   transformations).

The addition of these two instructions, along with the creation of some higher-level driver software, could turn the DLion into quite a good performer in the graphics arena.

		Herb
*start*
00705 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 13:33 PST
From: Sannella.pa
Subject: [Charnley.pa: New DLion uCode]
To: LispSupport.pa

     ----- Forwarded Messages -----

Date: 26 Mar 84 12:24:10 PST (Monday)
From: Charnley.pa
Subject: New DLion uCode
To: Sannella, Lispcore^
cc: Charnley

  A new set of microcode for the dandelion has been placed on {Phylum}<Lispcore>next>dLispDomino.db, and spliced into {Phylum}<Lispcore>next>Lisp.sysout and {Phylum}<Lispcore>next>Full.sysout.
  
  This file contains both 4K and 12K microcode.
  Both microcodes contain the fix for FNX at page end.
  
  Problems to me.
  
  don


     ----- End of Forwarded Messages -----
*start*
00676 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 13:28 PST
From: Sannella.pa
Subject: [masinter.PA: Re: FULLNAME invariant]
To: LispSupport.pa

     ----- Forwarded Messages -----

Date: 22 Mar 84 13:52:51 PST (Thursday)
From: masinter.PA
Subject: Re: FULLNAME invariant
In-reply-to: JONL's message of 19 MAR 84 19:22 PST
To: JONL
cc: MASINTER, lispcore^

I never did understand what TRUENAME was meant to be, that was different than FULLNAME when there was a FULLNAME, and "the string that started this" when there wasn't.

What is TRUENAME of a BSP connection? of {RS232}? of the keyboard? 


     ----- End of Forwarded Messages -----
*start*
01159 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 13:35 PST
From: Sannella.pa
Subject: [JONL.PA: Re: FULLNAME invariant]
To: LispSupport.pa

     ----- Forwarded Messages -----

Date: 26 MAR 84 17:36 PST
From: JONL.PA
Subject: Re: FULLNAME invariant
To:   masinter
cc:   lispcore^, JONL

In response to your message sent  22 Mar 84 13:52:51 PST (Thursday)

TRUENAME differs from FULLNAME in that certain file systems can have "indirect"
files; this means that there is a file catalog entry for, say, the fullname
[Server]<Directory>Name.ext;2  which causes data block sharing with the file
[Server]<AnotherDirectory>AnotherName.AExt;8    The "string that initiated" 
the opening may be something like the fullname (which of course FULLNAME 
would return), but TRUENAME would return the "real" name where the data reside.


The keyboard stream has a fullname (arbitrarily chosen) of KEYBOARD:
I'm not sure if all BSP streams have litatom fullnames.
At any rate, where there is a sensible fullname, then TRUENAME should just
defer to it (modulo the indirection mentioned above).


     ----- End of Forwarded Messages -----
*start*
00370 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 14:01 PST
From: Sheil.pa
Subject: Re: AR 337: "dc FOO" acts different from "DC FOO"
In-reply-to: LispSupport.pa's message of 28 Mar 84 09:31:00 PST (Wednesday)
To: LispSupport.pa
cc: burton.pa

This is superceded by the AR on "LISPX error correction loses args" that follows.

Beau

*start*
00570 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 14:04 PST
From: Sheil.pa
Subject: Lisp: LISPX error correction loses args
To: LispSupport.pa
cc: burton
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dolphin

If one has an NLAMBDA nospread fn FOO, one can type
	FOO ALPHA
to Lispx and FOO will be run, with ALPHA as argument.

If however, one mistypes FOO (as foo, FOOX,etc.) and the spelling corrector sucessfully corrects to FOO, Lispx does not pass the arguments along.

Example: DC file works fine; dc file does not.

Beau

*start*
00413 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 14:13 PST
From: Jellinek.pa
Subject: Lisp: DEdit: MOVEWing the window
To: LispSupport.pa
cc: Jellinek.pa
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dolphin

After moving a DEdit window, the EditOps menu does not snuggle up to the window, as it should.  (It does snuggle up after reshaping the window, however).
	Herb

*start*
00555 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 14:34 PST
From: vanMelle.pa
Subject: Lisp: RENAME inefficiency
To: LispSupport.pa
cc: vanMelle.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

If you restrict RENAME by giving it a FILES argument, even one of length 1, it still calls COPYDEF with SOURCE = NIL, which means that COPYDEF has to invoke WHEREIS, which goes to the database, even though all along it is known that the fn being renamed lives on the one file that I gave as argument to RENAME.
*start*
00259 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 13:56 PST
From: Sybalsky.pa
Subject: Lisp: AR 251 (TEDIT.QUITFN should be list of fns)
To: LispSupport.pa
cc: Sybalsky.pa

is FIXED.  It will be in the next TEdit release.
*start*
00365 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 15:02 PST
From: Sybalsky.pa
Subject: AR 336 (PROPLIST format looks info)
To: Lispsupport.pa
cc: Sybalsky.pa

Has been FIXED--the interface will be in the next TEdit release.  This is true for 

	FONT info to TEdit call
	PARALOOKS info to TEdit call
	LOOKS arg to TEDIT.INSERT


*start*
00443 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 16:18 PST
From: vanMelle.pa
Subject: Re: AR#88: Lafite holds mouse too long
To: Roach
cc: vanMelle.pa, LispSupport

Lafite's Quit command runs as its own process, so it isn't holding onto the mouse at all.  Perhaps your mail files are on {DSK}, in which case your complaint is really Operating System/Processes, Subject: want preemptive process scheduler.
*start*
00585 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 16:57 PST
From: Stansbury.pa
Subject: Lisp: InstallLispTool
To: LispSupport.pa
cc: Stansbury.pa
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dorado

InstallLispTool from lisp>current does not seem to pay attention to the NSFile and PUPFile entries in the user.cm when you make up the user.cm with an editor.  (I made my user.cm with the Tajo file window following the model in installLispTool.doc.)  However, when you set these fields via SetProfile, they are then remembered.  


-- Tayloe.
*start*
00726 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 19:44 PST
From: Roach.pa
Subject: Incorrect CTRL-selection & scrolling interaction
To: LISPSUPPORT
cc: Roach.pa

     Attn: Sybalsky, Nuyens     Impact: Annoying
     Freq: Every Time
     Pick any document larger than your Tedit window can hold.  Press <CTRL> key down, left button mouse at top-left corner of document, move mouse into scroll bar and middle button down to end of document, right button mouse at end of document, let <CTRL> key up.  The inverted portions of the Tedit window, (your CTRL-selction), do not match up with the text.  (Looks like it matches up with what the text looked like before you scrolled.)
						Kelly

*start*
01041 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: lichtenberg.wbst
Date: 28-Mar-84 23:07:46 EST
Subject: Re: Lisp: Wanted:  DLion area-fill microcode
In-reply-to: Jellinek.pa's message of 27 Mar 84 14:14 PST
To: Jellinek.pa
cc: LispSupport.pa, Lichtenberg



Fill algorithms can be pretty complex, depending on what you want to do...

Do you want to be able to fill concave polygons or polygons that double over on themselves (like a gigure "8" or something?  That makes it harder.)  Or do you want to fill normal closed polygons?  What would you be using for a boundary on the polygon?  Do you want to fill the polygon with an arbitrary shade?

Are you sure you don't want an opcode to generate a mask bitmap for use with BITBLT, that way you get the most features, and less microcode has to be written.  


All in all, sounds like a neat idea.  If it's important, I'll look into some algorithms and see if it is feasible and try to get an estimate on how much space/time/programmer time it takes.  OK?


/Mitch.
*start*
00640 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 09:29 PST
From: Jellinek.pa
Subject: Re: Lisp: Wanted:  DLion area-fill microcode
In-reply-to: lichtenberg.wbst's message of 28-Mar-84 23:07:46 EST
To: lichtenberg.wbst
cc: Jellinek.pa, LispSupport.pa

Mitch,
	Thanks for your message.  I'll try to clarify.
I'd like an opcode that would generate a mask bitmap for use with BITBLT.  As you point out, that would afford the most flexibility for (maybe) the least microcode.  As for the type of polygons to be filled:  normal closed polygons would be easiest, and seem to be the most common case.

		Herb

*start*
00605 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 21:53 PST
From: Roach.pa
Subject: Lisp: Udf NOT^H in COMP.NUMBERCALL
To: LispSupport.pa, MASINTER
cc: Roach.pa
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dandelion

     Attn: MASINTER        System: Language Support
     Subsystem: Compiler        Impact: Moderate

     When trying to compile 
	{PHYLUM}<ROACH>LISP>EMACSUTI1
(with BQUOTE package loaded) I get udf NOT^H underneath COMP.NUMBERCALL.
	(CALLS 'COMP.NUMBERCALL) =>
		((...NOT^H...) ...)
	(GETD 'NOT^H) => NIL
Looks suspiscious to me.
						Kelly
*start*
00211 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 21:55 PST
From: Roach.pa
Subject: NOT^H
To: LISPSUPPORT, MASINTER
cc: Roach.pa

"^H" in "NOT^H" is character 8.
						Kelly
*start*
00383 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: MASINTER.PA
Date: 29-Mar-84  8:24:12 PST
Subject: Re: Lisp: Udf NOT^H in COMP.NUMBERCALL
In-reply-to: Roach's message of 28 Mar 84 21:53 PST
To: Roach
cc: LispSupport, MASINTER

I fixed this and pointed out the workaround in a message to LispFriends^ day before yesterday . Workaround, MOVD(NOT NOT^V^H).

*start*
00404 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 04:57 PST
From: desRivieres.pa
Subject: Lisp: Documentation error p 18.9
To: LispSupport.pa
cc: desRivieres.pa
Lisp-System-Date: 28-Mar-84 00:03:18
Machine-Type: Dandelion

The KEYACTION example on p 18.9 is incorrect:  the initial setting of the left shift key is (1SHIFTDOWN . 1SHIFTUP), not the other way around. 
*start*
00567 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 20:36 PST
From: Roach.pa
Subject: TEDIT.INSERT.DISPLAYTEXT bug
To: LISPSUPPORT
cc: Roach.pa

     Attn: Sybalsky, Nuyens     Impact: Moderate
     In a nearly empty TEDIT window in which I had just used the LOOKS menu item, I started typing at the beginning of the file and got "DISPLAY - ILLEGAL ARG".  Function TEDIT.INSERT.DISPLAYTEXT, which appears to have been called with plausible args, is calling DSPFONT with args
	FONT = DISPLAY
	STREAM = {STREAM}#11,113600
					Kelly

*start*
00566 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 08:51 PST
From: Wallace.pa
Subject: Lafite: Sorting entries in Browser window
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

I frequently receive messages out of order (Cbernet goes down for a while, and old, unseen messages stack up).  I would like to be able to sort the messages in my browser at least chronologically.  Other predicates would be nice, but chronologically is the most important.

david


*start*
00958 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 10:08 PST
From: Sheil.pa
Subject: Re: AR 209: Lafite MoveTo confirmation after menu
In-reply-to: vanMelle.pa's message of 27 Mar 84 11:17 PST
To: vanMelle.pa
cc: LafiteSupport.pa

I think you've got my argument backwards. It's not that I recommend removing the confirm from the left button MoveTo (altho I would, because the consequences are not all that awful) but that it should be consistent with what happens on middle buttoning. Either confirm both or confirm neither. I dont think that choice of mouse button is decisively less likely to be in error than choice out of a menu (in fact, I believe the reverse).

I'd not confirm either (a la John S.'s suggestion) or confirm both, but they should be the same.

Beau

PS: Incidentally, the fact that that !Undo in DEdit is not undoable is a bug, which I have undertaken to fix, not a deficiency in interface design.  
*start*
01220 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 10:25 PST
From: Sheil.pa
Subject: Lisp: Proposal: 2 button mousing
To: LispSupport.pa
cc: raim.pasa, lispcore^

Lisp-System-Date: All

Both internally and externally we have a lot of users with 2 button mice. This situation does not seem to be getting any better quickly and may stay that way (subject to Xerox mouse manufacturing and policy whims).

We hacked around this problem using a DLion function key a long time ago. Perhaps we out to think about this hack again since the situation seems rather permanent.

Proposal: Let's consider the Mesa strategy of regarding a left-right mouse chord as being equivalent to middle.  The only application of mouse chording that I know of is the GETREGION case and there is no reason why the "switch corner" code couldnt be middle, rather than right, key dependent.

Perhaps we want to make this optional (a user settable GLOBALVAR looked at by MOUSESTATE?). But I do think we should consider it, despite the backwards incompatibility. A large fraction of our users are now working in the 2 button world. I think we have to do something for them.

Comments? A discussion on Monday?

Beau

*start*
00405 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 14:20 PST
From: Sybalsky.pa
Subject: AR 22 Declined/fixed
To: Lispsupport
cc: Sybalsky.pa

Mike--

I cannot replicate AR 22 (caret looks trouble from BVM).  I think he was bitten by the CR he selected being in TR 12 B, instead of TR10 as he thought.  Please mark the AR appropriately--I'm not sure which it should be.
*start*
00541 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 15:52 PST
From: Sheil.pa
Subject: Re: AR 311: EDIT in WBREAK causes window title "DEdit of function NIL"
In-reply-to: LispSupport.pa's message of 27 Mar 84 09:30:03 PST (Tuesday)
To: LispSupport.pa
cc: masinter

HELPFIX is calling EDITE with Type=FNS, even if there is no fn (like on TYPEIN). Hence DEdit thinks this is a function (with no name).

AR311 should be superceded by this AR on HELPFIX - type should be NIL if name arg to EDITE is NIL.

Beau

*start*
01272 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 16:07 PST
From: jordan.pa
Subject: Lisp: Dedit/Break problem
To: LispSupport.pa
cc: jordan.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

	I am having a problem with BREAKing on an S-expr while in Dedit.  For a particular function, i.e., not for *all* functions, when I break (from the menu) around an S-expr and then EXIT the Dedit of that function, the function is "automatically" unbreaking.  I am getting a message in the TopLevelW saying "FOO unbroken".  

	Other functions are breaking as expected in Dedit.  

	Exiting Dedit to the toplevel and starting again doesn't help; I now cannot BREAK this function in Dedit without it unbreaking upon EXITing.  

	I did look at some variables:  BROKENFNS and BRKINFOLST, both originally NIL, are properly set when I perform the BREAK around some S-expr while in the function.  After EXITing, BROKENFNS is NIL and BRKINFOLST is still set to the non-NIL expr.  

	Some history:  the function had been involved in a Dedit/Break tangle, at one point I fell into a (SHOULDNT).   I ^'ed out to the top level to start over, and the function from then on was unBREAKable.  
Apparently something was not properly reset.


dan


	
*start*
00982 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 18:21 PST
From: desRivieres.pa
Subject: Lisp: EXPORTS.ALL problems
To: LispSupport.pa
cc: desRivieres.pa
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dorado

I have just loaded {phylum}<lispcore>next>full.sysout.
Once inside, I loaded {phylum}<lisp>library>exports.all.  This seems to break CLOSEF (actually, OLDCLOSEF) with the following error:

ARG NOT IMAGEOPS
{**DEALLOC**}#1,73740 

This error is both persistent --- always the same deallocated object, and always traceable to the same source: the IMAGEOPS field of a stream.   

When EXPORTS.ALL was loaded, it did indicate that IMAGEOPS was redefined.

John Sybalsky was running the same sysout, also with EXPORTS.ALL loaded --- only indirectly through {phylum}<lispcore>sources>abc. I load EXPORTS.ALL directly because I don't want the rest of the stuff.  From looking at ABC, I can't see why it should matter.  Help!
 
---Jim    
*start*
02698 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 MAR 84 11:20 PST
From: ROACH.PA
Subject: FLOPPY: Streams Allocation Error
To:   LISPSUPPORT

Received: from CMU-CS-A.ARPA by PARC-MAXC.ARPA; 29 MAR 84 07:52:38 PST
Date: 29 Mar 84 05:55 EST (Thursday)
From: Donna.Auguste@CMU-CS-A.ARPA
To: 1100support.pasa
Subject: {floppy} errors
CC: roach.pa
Message-Id: <29Mar84.055519.DA81@CMU-CS-A>


i have been using the new fugue.6 release on a stand-alone dandelion
for a couple of days now, and i have several observations and
questions.

(1) where is documentation for FLOPPY.MODE and the other floppy
functions?  we have "fugue.6 release notes draft-draft-draft",
"installing software of 1108", the little blue booklet titled "xerox
1108 users guide", the big manual, and the the spiral-bound fugue book.
i couldn't find anything about FLOPPY.MODE.  note (2) will explain why i
was looking so hard.

(2) i used (SYSOUT '{FLOPPY}filename) to save my SYSOUT on four floppy
disks.  that went very smoothly (i'm really glad we can save SYSOUTs
now!).  however, i found that the next time i went to use (MAKEFILE
'{FLOPPY}filename), i got a break window with the message:  "NIL -
NON-NUMERIC ARG"; when i tried to load from a floppy, i got a break
window with the message:  "ARG NOT LP:  NIL ERROR".  i reread my large,
friendly "don't panic" letters several times, and, after some
experimenting with a spare disk, i found that the system was still
trying to write SYSOUTs, brute-force changing the name of the disk to
"Lisp Sysout #1", etc.  (FLOPPY.MODE) returned SYSOUT, and nothing i
could think of giving it as a MODE argument was acceptable.  eventually,
i went and found a free machine, and looked at FLOPPY.MODE there, reset
mine to be PILOT like the other machine had, and my problem
disappeared.  

(3) later in that same session, i did my usual
SAVE.EVERYTHING-to-floppy , and got a break window with the message:
"Floppy:  Severe Error!  :  Streams Allocation Error ERROR".  i tried
reformatting the floppy; didn't make any difference that i could see.  i
gave up, did some other things (including RECLAIM, and erasing many
windows from the screen), and retried SAVE.EVERYTHING-to-floppy.  it
worked.  about 2 hours later, i received the same error message and
could not shake it.

(4) since i seriously depend on floppies as storage for all of my
interlisp work, i would like to better understand what is going on.  can
i see the high-level source code (do i already have access to it, but
am just unaware?), or even the source microcode?  can i get a list of
the error messages and what they mean?  any documentation?

thanks,
donna auguste
(AUGUSTE@CMU-CS-A)


 
*start*
01346 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 MAR 84 11:22 PST
From: ROACH.PA
Subject: RE: {floppy} errors
To:   Donna.Auguste@CMU-CS-A
cc:   LISPSUPPORT, ROACH

Hi Donna,
     The answers to your questions:
     (1) {PHYLUM}<LISP>CURRENT>FLOPPY.TTY.  I've sent you a copy.
     (2) A known bug.  This can happen when you ^D during a sysout and
{FLOPPY}'s mode doesn't get changed back to PILOT.  Work around: Do
(FLOPPY.MODE 'PILOT) when you encounter thise error.
     (3) Somehow, you've managed to get a {FLOPPY} STREAM whose PALLOC
allocation record is missing from {FLOPPY}'s cached directory.  I
don't believe there should be anything wrong with your floppy, but
{FLOPPY}'s info in core is confused.  I'd appreciate more background
on this problem if you can repeat it.  Probable workaround is to just
open & close the floppy drive door, which will flush {FLOPPY}'s cached
directory structure.
     (4) It's up to 1100SUPPORT what source files go out to which
customers.  You can get a good idea of what functions are used by
{FLOPPY} by doing (APROPOS 'FLOPPY).  I don't have a comprehensive
error list, but the errors that should happen are generally the
standard file system errors (e.g. "FILE SYSTEM RESOURCES exceeded")
which are included in section 9.8 of the Interlisp Reference Manual.
				Kelly

*start*
01189 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 MAR 84 12:30 PST
From: JONL.PA
Subject: Re: DEFINEDP and FGETD
To:   MASINTER
cc:   LispSupport, JONL

In response to your message sent  26 MAR 84 21:17 PST

This "summary" left out the essential complaint -- 

    The existing semantics of DEFINEDP (not documented) is exactly the
    documented semantics of FGETD, modulo representation of SUBRs on PDP10 
    and D-machines


The remaining problems are secondary.  Not having DEFINEDP documented led
some users (namely, the STROBE folks at Schlumberger) to run an order of
magnitude slower on one of their inner loops -- I suggested that they use
DEFINEDP rather than GETD or FGETD (both of which cons when a value is
being returned).


The "secondary" suggestion to have something parallel to the MacLisp/Lispm
"optimizers" or "source-code-rewrites" would remove a number of totally
bogus "MACROs" from interlisp -- functions which have a MACRO definition,
but which macro try to "punt out" if not called by the compiler.  Since
EXPANDMACRO exists, it ought be be clear that the kludgy techniques such as
found in the FGETD macro are totally inadequate.

*start*
00479 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 12:23 PST
From: halvorsen.pa
Subject: Lafite: HARDCOPY
To: LafiteSupport.pa,TEDITSUPPORT
cc: halvorsen.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dandelion

When I try to hardcopy a message  TEDIT.PRESS.HARDCOPY is called, even though the LAFITEHARDCOPYFONT is MODERN and I have LISPPRINT: as the second entry on DEFAULTPRINTINGHOST.

		Kris
*start*
00673 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 MAR 84 12:17 PST
From: ROACH.PA
Subject: Suggest better way to respond to AR submissions
To:   LISPSUPPORT
cc:   ROACH

     At least for members of LISPCORE^, there doesn't seem much point
in sending out messages like "assigned AR 362".  Instead, I would rather
get a summary of the status etc. of bugs I've submitted once a month
so that I can harp on the people who aren't doing anything.  I would
only respond to AR submissions from LISPCORE^ (maybe 1100SUPORT too)
if you can give useful info such as known workaround, fixed in next
release, or some other bit of good/bad news.
				Kelly
*start*
00413 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 15:05 PST
From: halvorsen.pa
Subject: TEdit: Para looks not copied
To: TEditSupport
cc: halvorsen.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dandelion

I am at the end of a newly composed document, and suddenly the para looks of the previous para are not copied when I do a cr
*start*
00357 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 15:00 PST
From: vanMelle.pa
Subject: TEdit: TEDIT.FIND
To: TEditSupport
cc: vanMelle.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

Still breaks with ARG NOT TEXTOBJ if you give it a text stream instead of a TEXTOBJ.
*start*
01198 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 29 MAR 84 06:03:55 PST
Return-path: <@SUMEX-AIM.ARPA:RBATES@USC-ISIB.ARPA>
Redistributed: Xerox1100UsersGroup^.PA
Received: from USC-ISIB.ARPA by SUMEX-AIM.ARPA with TCP; Wed 28 Mar 84 15:59:49-PST
Date: 28 Mar 84 15:59 PST
Sender: RBATES@USC-ISIB.ARPA
Subject: Re: Masterscope on large systems
From: Raymond Bates <RBATES@ISIB.ARPA>
To: SHahn@SUMEX-AIM.ARPA
Cc: Help-LISP@SUMEX-AIM.ARPA, Help-ILISP@SUMEX-AIM.ARPA
Cc: 1100-users@SUMEX-AIM.ARPA
Message-ID: <[USC-ISIB.ARPA]28-Mar-84 15:59:22.RBATES>
In-Reply-To: The message of Wed 28 Mar 84 15:10:14-PST from Sam Hahn <SHahn@SUMEX-AIM.ARPA>

I just gave Bob Tucker at SUMEX a version of AGE that will run on
ISI-Interlisp (a.k.a.  Interlisp-VAX).  One of the files on the
tape is called DATABASE, which just happens to be a Masterscope
of the AGE system.  It should be easy to ftp the file from Diablo
over to SUMEX and use it.  I known this doesn't solve the problem
but it should be a quick solution.  The VAX does not have an
address space limitation so the entire AGE sources will fit into
core without any problems.

/Ray
*start*
00396 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 04:38 PST
From: desRivieres.pa
Subject: TEdit: TEDIT.DELETE 
To: TEditSupport
cc: EMACSSupport^.pa
TEdit-System-Date:  1-Mar-84 13:54:34
Lisp-System-Date: 28-Mar-84 00:03:18
Machine-Type: Dorado



(TEDIT.DELETE STREAM 1
     (ADD1 (GETEOFPTR STREAM)))

blows one into RAID with an illegal address.


---Jim 
*start*
02001 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 19:33 PST
From: Masinter.pa
Subject: Interlisp-D "Action Request" database
To: LispUsers^
reply-to: LispSupport, 1100Support.Pasa

For those of you who might have wondered what Jerry was talking about:

We (LispSupport.pa in Palo Alto, and 1100Support.pasa in Pasadena) are converting over to using a system for keeping track of messages, bug reports, requests for features, problems with documentation, etc.  Individual entries in this database are called "ARs", or Action Requests.

As before, when you have a problem or a question, please send mail to LispSupport.PA or 1100Support.Pasa. (I think we're all a little confused about who is supposed to use what mailbox, but it doesn't matter much.) 

So what's different? 

What is different now is that you will get back a number (the AR number) which identifies your problem report. Problems that don't get resolved immediately can be tracked; we have a better handle on where the system is going and can plan better for future releases.

There is a new LispUsers package, AREDIT, which allows one to view ARs conveniently. Although primarily designed for the use of the development staff, it will become part of the standard "Full.sysout". We intend over the next few months to build a variety of tools in Interlisp-D to give us direct access to the facilities of Adobe.

Jerry Fung is helping the Pasadena support staff with Adobe usage, and has prepared some forms which identify  the information we're trying to keep track of. The forms Jerry prepared are on [Rose]<Lisp>Adobe>*.form. Some version of this form will replace the LispReport option inside Lafite as the standard way of reporting bugs from inside Interlisp. Most of the information is what you would normally include in a bug report anyway, but it is just categorized.  We're preparing a document which explains what the various fields mean. An announcement about that will be forthcoming. 



*start*
00503 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 17:44 PST
From: halvorsen.pa
Subject: TEdit: Bug in substitute from main meny
To: TEditSupport
cc: halvorsen.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dandelion

What the substitution was made in bold face even though none of the targets, nor the typed in substitute was in bold.  (Also didn't get a question about whether replacements should be confirmed).

		Kris
*start*
03449 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 15:11:18 PST (Wednesday)
From: JFung.pasa
Subject: Submitting ARs
To: 1100Support, LispUsers^.pa
cc: LispSupport.pa, LispCore^.pa, Masinter.pa, JFung
Reply-To: JFung.pasa

This is not a flame. 

Anyone wishing to submit/edit AR towards INTERLISP system may do so, by 

a)	sending a mail-message to 1100Support.pasa (using LispAR-Submit.form, LispAR-edit.form) or
b) 	using Adobe tool with Adobe Systems = LispARs.

If you select to use b) you can skip the rest message.  If you select to use a) please read and help us.

I am trying to form a procedure where our local AR submitter (currently, Thu Le.pasa) will not get jumped on by the screener in case for any incomplete ARs, or later on  have to communicate between PARC implementors and you for more information.   I want PARC to have GOOD impression on the ARs we (PASADENA) submitted and your cooperations are definitely needed.

Please remember to fix a bug, a lot of information and feelings need to be feed in.  Lack of these information will only lengthen the "fixing" period.  

It is the "source" who has the MOST accruate information about an AR, Thu is justing doing us a FAVOR by using Adobe-tool to enter it.  It is us, the source person's job/responsibility to submit as COMPLETE information as possible, so Thu doesn't have to fight back and forth between PARC and you.

For this reason, and to ensure it, I have created two forms, the LispAR-Submit.form and LispAR.Edit.form.  These forms contain all the fields and identify those IMPORTANT fileds, so you will not leave it out. It contains fields which you as a source should be responsible to fill in.

(Note, it is OK we make error on selections, the idea is to ensure important fields are included so relevant reports can be generated and reviewed)

Thu will take the data from LispAR-Submit.form and move into Adobe database, she can do some rephrasing if necessary. Thu's role is only to relay your input to Adobe and relay back when the status on that AR has changed.  Thu is not responsible for setting "priority", "difficulty" etc.  She is responsbile (I think) to set "attn" field and notify that persion that he/she has a NEW AR.

If you later on wish to change the state of the AR, say change Status, add more information of the customers feed in, you then use LispAR-Edit.form to tell Thu.  The DISPOSITION field is used for this purpose, so later on, for the same problem people can query the database to find out the solution or workaround etc.

I have marked fields follow by ** as IMPORTANT fields in LispAR-submit.form and you should try to specify it.

I'll be glad to talk if you disagree on the fields and their enumerated values or any other better complete/consistant way that we all can benefit from it.

LispAR-Submit.form, LispAR-Edit.form and other LispAR documents may be retrieved from [Rose]<Lisp>Adobe>*

P.S.  PARC's LispSupport.pa DL now only contain one generic user (LispAR.auto) and this person sorts out the incoming mails and enters them into Adobe and notify the appropriate person. (Instead the old way, everybody was on the DL and receive the message and..).  If 1100Support.pasa does not like to see so many mails, this is one good way to go too.

P.P.S. I encourage Customer Support to let the customers aware of the fields and information that we are using for handling bug-reports. 
 

	/Jerry




*start*
00897 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 28 MAR 84 15:39:16 PST
Redistributed: Xerox1100UsersGroup^.PA
Date: Wed, 28 Mar 84 15:10:14 PST
From: Sam Hahn <SHahn@SUMEX-AIM.ARPA>
Subject: Masterscope on large systems
To: Help-LISP@SUMEX-AIM.ARPA
cc: Help-ILISP@SUMEX-AIM.ARPA, 1100-users@SUMEX-AIM.ARPA

I need help on Masterscope.

I have a large system (AGE) on which I would like to run Masterscope, but
not all the source can coexist in an image concurrently.  How can I use
Masterscope on such a big system?  

I've loaded each individual file by itself, and written DATABASE.*
(where * corresponds to each file), but when I load all the DATABASE.*
files, the system still tries to read from the source, and gives me
BAD FILE NAME messages.

Is there a solution?
			Thanks in advance, if so,
					-- sam hahn
-------
*start*
00486 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 13:59 PST
From: Jellinek.pa
Subject: TEdit: fails to reset cursor shape
To: TEditSupport
cc: Jellinek.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dolphin

TEdit fails to change the mouse cursor back to the usual left-pointing arrow when you drag it slowly across the left edge of the TEdit window;  it leaves the cursor pointing to the right.

	Herb

*start*
00507 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 13:49 PST
From: Sybalsky.pa
Subject: Re: TEdit: fails to reset cursor shape
In-reply-to: Jellinek.pa's message of 28 Mar 84 13:59 PST
To: Jellinek.pa
cc: TEditSupport.pa, Burton

Herb--

I think it's a bug in the scroll-window handler:  Dragging the mouse out thru the scroll bar runs the CURSOROUTFN for the window--but saves the cursor shape from earlier and restores it on top of the fix the TEdit CURSOROUTFN makes.
*start*
01503 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 13:38 PST
From: Sannella.pa
Subject: [masinter.pa: AR#135]
To: LispSupport.pa

     ----- Forwarded Messages -----

Date: 26 Mar 84 17:42 PST
From: masinter.pa
Format: TEdit
Subject: AR#135
To: LispCore^, JFung.pasa

This AR would be superceded if Lisp on a DLion were fixed to extend its VMEM in a reasonable way. Is there any chance of that, and if so, is there a separate AR for that?

Number: 135	Date: 17-Mar-84  0:24:29
Submitter: Masinter.PA	Source: 1
System: Other Software	Machine: 1108
Subsystem: Installation Utility	Disk: 
Problem Type: Bug	Memory Size: 
Subject: Prometheus/Othello installs VMEM too small: can hit bad spots
Source Files: 
Impact: Serious	Frequency: Everytime
Status: Open	In/By: 	Attn: JFung.pasa
Assigned To: 	Priority: Hopefully	Difficulty: Very Hard
Disposition: 
Lisp Version: 	Microcode Version: 
File Server: 	Server Software Version: 
Description: 

Fixing this will require creating new versions of Othello and Prometheus.

The InstallLispTool has been fixed to install Interlisp-D virtual memory larger than the size of the sysout tool. However, it is still the case that the Installation Utility (which is Prometheus+script) uses the old style of installation. This is serious because the virtual memory is not allocated in a way that avoids bad pages, which can lead to serious problems running Interlisp on disks with bad spots.

     ----- End of Forwarded Messages -----
*start*
00522 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 13:27 PST
From: Sheil.pa
Subject: Re: AR system; DEDIT bugs
In-reply-to: LispSupport.pa's message of 28 Mar 84 11:26:46 PST (Wednesday)
To: LispSupport.pa

OK. I found them on my personal list (the one I was working off was older).

I have AR38 (superceded) but not 162, which it was superceded by.

PS: It would help if the AR# was always the last sort field, so the numbers were not random within categories in the summaries.

Beau

*start*
00411 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 11:46:02 PST (Wednesday)
From: JFung.pasa
Subject: LispAR.press printting
To: LispSupport.pa
cc: Le, JFung

Mike,

I retrieved 26-mar press files and they got printted ok.  I dont know what was wrong with previous one.  Thu happen to have an old copy, which she is asking JonL to bring it back.  (just for your information)
*start*
00851 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Wed, 28 Mar 84 10:32 PST
From: Feuerman.pasa
Subject: Color Utilities
To: LispUsers^.pa
cc: Burton.pa, Feuerman
Reply-To: Feuerman.pasa

This is to announce a new version of Color Utilities as a LispUsers package.  These programs provide a lot of the Interlisp-D display facilities (such as windows and menus) on the color screen.

The changes from the previous version are
	1).  Upgrade to compatibility with Carol.
	2).  Quicker pop-up menus after the first pop-up.
	3).  Items in menu can be of different colors.

The important files are {PHYLUM}<LISPUSERS>COLORUTILITIES.DCOM and {PHYLUM}<LISPUSERS>COLORUTILITIES.TTY for documentation.  Make sure to load '{PHYLUM}<LISP>LIBRARY>COLOR.DCOM first.

As always, bugs, complaints, suggestions and money are welcome.

--Ken.
*start*
00830 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 10:59 PST
From: Sannella.pa
Subject: [Sheil.pa: AR system; DEDIT bugs]
To: LispSupport

     ----- Forwarded Messages -----

Date: 28 Mar 84 10:44 PST
From: Sheil.pa
Subject: AR system; DEDIT bugs
To: sannella

AR's 38,90 and 123 should be marked ATTN Sheil (they are currently unassigned) and forwarded to me.

Can we get unfilled in fields to go to the BOTTOM of the collating sequence rather than the top?

Could I have a sort, weekly, by Priority/Impact/Attn?

I think a date of submission or submitter field would also be useful (more so than Frequency) on these summaries.

I would also like ALWAYS to be copied on urgent ARs from Pasadena on which they claim release/nonrelease pends.

Beau


     ----- End of Forwarded Messages -----
*start*
00432 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 11:18 PST
From: masinter.pa
Subject: AR reports
To: LispSupport
cc: LispCore^

I personally would prefer to see the ars first sorted by

System/Subsystem (to put them together in categories)
and then by Status (to distinguish "fixed/declined")
and then by Priority

The priorities and many of the "attn" fields in the database are pretty bogus.
*start*
00412 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 12:44 PST
From: Stansbury.pa
Subject: Re: AR reports
In-reply-to: masinter.pa's message of 27 Mar 84 11:18 PST
To: masinter.pa
cc: LispSupport.pa, LispCore^.pa

I think that if ARs continue to be sorted and distributed by attn field that bugs in attn and piortity assignment will tend to get fixed more rapidly.

-- Tayloe. 
*start*
00501 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 13:19 PST
From: Sybalsky.pa
Subject: Re: AR reports
In-reply-to: Stansbury.pa's message of 27 Mar 84 12:44 PST
To: Stansbury.pa
cc: masinter.pa, LispSupport.pa, LispCore^.pa

I'd prefer to have them sorted by System/subsys then by STATUS, then whatever.  That way, I have all the fixed things collected in one place--then I'm not searching to and fro to hook new reports up with old reports all the time.

	--John
*start*
00344 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 11:38 PST
From: ckiparsky.pa
Subject: Lisp: HARDCOPY
To: LispSupport.pa
cc: ckiparsky.pa
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dandelion

The background  command  "hardcopy" isn't working  -  it gets an error window,  "unknown host".

Carol K.
*start*
00573 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 12:42 PST
From: Sybalsky.pa
Subject: Lisp: SINGLEFILEINDEX declines to list LAFITE sources
To: LispSupport.pa
cc: Sybalsky.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dandelion

I've had repeated run-ins with SINGLEFILEINDEX refusing to listfiles various copies of the lafite sources.  It claims that there's something wrong with the filemap.  I tried this on three different versions of the lafite sources, with the same result--it runs for a lo-o-o-ong time before punting.
*start*
01493 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 11:03 PST
From: masinter.pa
Subject: [Breisacher.ES: DELETE Key Copy hack]
To: teditsupport

idea for Delete-Copy etc.


Also, why don't we have "TIP tables"?

     ----- Forwarded Messages -----

Date: 26 Mar 84 17:59:42 PST (Monday)
From: Breisacher.ES
Subject: DELETE Key Copy hack
To: MesaHacks^.pa
cc: , Breisacher
Reply-To: Breisacher.ES

Do you find yourself doing this a lot while editing Mesa code?: 

  Hit DELETE, then immediately hit COPY. 
  
Well, there's an easier way. Make the TIP table changes shown below, and you can use the DELETE key alone. 

Now to do a delete followed immediately by a copy, you press down the DELETE key, then immediately select the thing you want to copy, then let up on the DELETE key. 

Normal deleting still works fine. 

Make the following edits:

TextSW.TIP:

  Change 
    "[DEF,CopyMove,(COPY Down | MOVE Down)]" 
  to 
    "[DEF,CopyMove,(COPY Down | MOVE Down | DELETE Down)]".
  
FormSW.TIP:

  Same as TextSW.TIP, if you want this to work in FormSWs.
  
Tajo.TIP:

  Add this line: 
    "DELETE Up => CopyUp;"
  
Debugger.TIP and TTY.TIP:

  Add this line: 
    "DELETE Up => ThisIsABogusAtom;" 
  This keeps the debugger and the exec from acting wierd.

  
That's it! Obviously, you have to reboot for the changes to take effect.

Lee

P.S. This has been stored as [Igor]<Hacks>11.0>Doc>DELETEKeyCopy.doc.


     ----- End of Forwarded Messages -----
*start*
00448 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 17:31 PST
From: masinter.pa
Subject: AR#279
To: JFung.pasa
cc: LispSupport


Jerry, please copy [rose]<Lisp>New>InstallLispTool.bcd to [phylum]<LispCore>Next> as a candidate to include in the next release and for testing by local users. 

When you do this, you can mark AR#279 as "fixed", please edit into Disposition field what happened and why it is fixed.


*start*
01432 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 MAR 84 15:12 PST
From: JONL.PA
Subject: Re: rs232 task
To:   Masinter, Sheil, Purcell
cc:   LispSupport, JONL

In response to the message sent  16 Mar 84 17:21:17 PST (Friday) from Masinter.PA

Just to review the "bottlenecks":

1) although the TTYPort seems to be operating better than the Martin-board
    interfacer for the Dolphin, it still doesn't not buffer characters; thus
    the liklihood of droppin characters when one of the DSPVTS functions is
    called. [DSPVTS is the functional support for Virtual Terminal Service
    under the Interlisp-D windowworld -- has functions like DSPINSCHAR for
    "inserting" a character, DSPDELLINE for "deleting" a line.  Remember also
    that DSPCLEOL is in the system now, for "Clear-to-end-of-line"]
    Sometime ago I asked Beau for an estimate of priority of the converto-to
    RS232C port; that conversion should clear up the dropped character problem.
2) the unix file TERMCAP has all the information we need for terminal emulation
    (and terminal drivers, if ever we should have to do it!);  I had planned
    to hand-transcribe enough information into Lisp to support a simple 
    emulator for the Heath 19 and VT52.  Current ethernet Chat's emulation of
    a DM2500 is a little non-standard in that it has more "escape sequences",
    but should fit rather easily into the DSPVTS mold.

*start*
01404 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Wed, 28 Mar 84 09:40 PST
From: Feuerman.pasa
Subject: TEdit Bug(?)
To: TEditSupport.pa
cc: , Feuerman

It's a little complicated, but I think the problem is that the information about paragraph starts and stops isn't making its way onto a file.

I've changed TEDIT.DEFAULT.FMTSPEC so that the 1STLEFTMAR is at 0, and LEFTMAR is at 64 (or so).  Basically, it looks like reverse indentation.  I put some text out there, and I call TEDIT.PUT.PCTB on the TEXTOBJ of the text.  Then I do (SETQ STREAM (OPENTEXTSTREAM Filename NIL Start End)), where I do know for certain the starts and stops of the text stream.  This time, however, when I call (TEDIT STREAM), only the first line is flushed left to 0, and all other lines start at 64 (including the starts of subsequent paragraphs).  I INSPECTed my way through the piece table of STREAM, and found (in addition to the fact that it has shrunk after going through the file) that the PPARALAST field of each of the pieces was set to NIL, whereas before these fields correctly indicated the ends of the paragraphs.

I'm not sure if this has already been fixed, but I'm running from a Carol full.sysout on Rosebowl dated 25-Feb-84 17:29:22 on a Dandelion.  What is the procedure on fixing these things?  When and how do I find out if this has been fixed?  Thanks for the help.

--Ken.

*start*
00800 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 28 Mar 84 00:20 PST
From: Masinter.pa
Subject: new transcendental functions
To: JonL
cc: LispSupport

What accuracy are they to? Are we within the range of what is possible given our floating point format?

I tried in Interlisp-10, Interlisp-D (on a Dorado), and Franz on GSLVAX,  (ARCSIN (SIN x)) and (ARCCOS (COS x)) for x = .001 and .027.

fn		maxc		vax		D
sin .001	.001		.0009999999999999999     .009972
cos .001	0.0		.001000000000000064311	.02799 (!!!!)
sin .027    .027         .027				.026993
cos .027	.02797      .02700000000000001   .044 (!!!!)

I think there may be a problem with ARCCOS or COS.

Is 32-bit IEEE floating point really that bad? (I guess Maxc is 36-bit, and the VAX defaults to double precision.)

*start*
00557 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 MAR 84 12:42 PST
From: JONL.PA
Subject: Re: AR 315: LEAF should buffer a page ahead
To:   vanMelle, LispSupport
cc:   JONL

In response to the message sent  27 Mar 84 11:02 PST from vanMelle.pa

The LISTFILES process indeed is "waiting" at many places, so BT shows
a wide variation of states; the preponderance of times that it is waiting
for a packet from PHYLUM suggests either that a Dorado is blindingly fast,
or (more likely) Phylum is hopelessly bogged down these days.

*start*
00598 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 12:58 PST
From: halvorsen.pa
Subject: Lafite: Moving: The only irritating slow down
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dandelion

I find that the only operation which I find cumbersome in the current Lafite is moving messages.  I once suggested a mode where you could mark a message for movement, but it would take place until an update (at which point I am willing to accept a delay).  I'd like to register my vote once more.

		Kris
*start*
00386 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Sender: Sannella.pa
Date: 29 Mar 84 13:50:13 PST (Thursday)
Subject: Re: Lisp: HARDCOPY
In-reply-to: ckiparsky's message of 27 Mar 84 11:38 PST
To: ckiparsky
cc: LispSupport
from: Masinter

The HARDCOPY command sends the hardcopy to the DEFAULTPRINTINGHOST. Is that variable set? Did you have an init file loaded?

*start*
00467 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 13:54:05 PST (Thursday)
From: Sannella.pa
Subject: Re: Lisp: HARDCOPY
In-reply-to: ckiparsky's message of 27 Mar 84 11:38 PST
To: ckiparsky
cc: LispSupport

fyi, we have submitted a bug report AR#382, 
Subject: DEFAULTPRINTINGHOST=NIL should cause clearer error message,
 Description: If DEFAULTPRINTINGHOST=NIL, you don't get a very clear error message when you try to hardcopy.
*start*
00301 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 13:09:42 PST (Thursday)
From: Sannella.pa
Subject: Re: Lafite: HARDCOPY
In-reply-to: halvorsen's message of 29 Mar 84 12:23 PST
To: halvorsen
cc: LafiteSupport, TEDITSUPPORT

isn't that what it is supposed to do?

*start*
00565 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 13:45 PST
From: halvorsen.pa
Subject: Re: Lafite: HARDCOPY
In-reply-to: Sannella.pa's message of 29 Mar 84 13:09:42 PST (Thursday)
To: Sannella.pa
cc: halvorsen.pa, LafiteSupport.pa, TEDITSUPPORT.pa

It is my opinion that it is a misfeature if you break on trying to print a file with interpress fonts when you have an interpress printer on your defaultprintinghost list.  If this is what it is supposed to do, I would suggest it isn't what it SHOULD be supposed to do.

		Kris
*start*
00789 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 MAR 84 13:22 PST
From: JONL.PA
Subject: Re: Lisp: SINGLEFILEINDEX declines to list LAFITE sources
To:   Sybalsky, LispSupport
cc:   JONL

In response to the message sent  27 Mar 84 12:42 PST from Sybalsky.pa

John, I had no trouble at all listing <LispCore>Library>LAFITE;10 -- could
you describe the version of SINGLEFILEINDEX you are using?  remember that
we LispCore folks should be loading preferentially from <LispCore>Library>
(rather than <Lisp>Library>).

Another possibility is some lossage in GETFILEMAP (from the FILEPKG file) --
but I fixed the bug in it on March 11 of this year, and you sent your note
from a sysout dated March 15.

Incidentally, I'll leave the hardcopy of LAFITE on your desk.
*start*
01197 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 MAR 84 13:13 PST
From: JONL.PA
Subject: Re: LISTFILES FAILS TO LIST NON-INTERLISP FILES
To:   ROACH, LISPSUPPORT
cc:   JONL

In response to the message sent  27 MAR 84 11:12 PST from ROACH.PA

Kelly, I had no trouble at all listing those two files with LISTFILES --
I've left the hardcopy on your desk.

Questions:  do you have a recent version of SINGLEFILINDEX? you should
be fetching it from <LispCore>Library> rather than <Lisp>Library> (when
there has been sufficient usage, then the <LispCore> version should
be moved to <Lisp>).  However, I'm not aware of bugs even in the <Lisp>Library>
version which would cause the behaviour you describe.

Finally, what sysout were you using?  There has been a bug (for years?) in
the lisp function GETFILEMAP, which I fixed on about March 11, 1984; the
manifestation of this bug would be an error of some sort when you tried
to listfiles of certain peculiar non-Lisp files.

If this keeps happening to you, but not to me, then I can understand why
you are "sick and tired" . . .  maybe there is a ROACHFLG in the system
that adds additional bugs when a ROACH is running?

*start*
00695 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 14:09 PST
From: Maxwell.pa
Subject: Lisp: DWIMIFY & COMPILE
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

I was running into strange behavior when I compiled code.  The code would run fine uncompiled, but then when I compiled it I would get strange values for parameters on procedure calls.  Martin and I finally tracked it down to DWIMIFY.  If there was an entry of the form 'SCORE' on SPELLINGS3, then any occurence of 'score' in my code would get dwimified into 'SCORE'.  This also happened with x and X.  Deleting SCORE and X from SPELLINGS3 fixed things.

Thanks,

John.
*start*
00501 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 14:10:53 PST (Thursday)
From: Sannella.pa
Subject: Re: TEdit Bug(?)
In-reply-to: Feuerman.pasa's message of Wed, 28 Mar 84 09:40 PST
To: Feuerman.pasa
cc: TEditSupport

FYI, this report is AR#387. In general, you can use the AREDIT LispUsers package to find out about what has been fixed and what is on the queue ("What is the procedure on fixing these things?  When and how do I find out if this has been fixed?"
*start*
00359 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 14:32:12 PST (Thursday)
From: Sannella.PA
Subject: Re: protection for [Phylum]<Lisp> directory
In-reply-to: JONL's message of 26 MAR 84 20:24 PST
To: JONL
cc: sannella, LispSupport

Why are you changing anything on <lisp>?  You should be making any changes on <lispcore>.
*start*
00756 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 MAR 84 20:24 PST
From: JONL.PA
Subject: protection for [Phylum]<Lisp> directory
To:   sannella
cc:   LispSupport

There is something screwy going on with files created on this directory --
I needed to make a trivial (in complexity only -- very important in effect)
edit to RS232; took me two CLEANUPs to get what I wanted.  Then I wanted
to go back and delete the file created by the first CLEANUP; but DELFILE
just hung forever, even though I had already typed in the correct password
for connecting to [Phylum]<Lisp> (how else could I have created the file
to begin with!).

This may be an AR on DELFILE; more likely it is on the default protection
set for that directory.

*start*
01120 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 14:41 PST
From: Stansbury.pa
Subject: [JONL.PA: Re: AR 294: SINGLEFILEINDEX fails to list records]
To: Jonl, Lispsupport.pa
cc: Stansbury.pa

Yes, changing DEFAULTINDEXEDTYPESLST will do the trick, but that is unnecessarily inconvenient. 

I would argue that DEFAULTINDEXEDTYPESLST ought to allow for indirection, and indirect the kinds of records indexed to the current value of CLISPRECORDTYPES.  

-- Tayloe.

     ----- Forwarded Messages -----

Date: 29 MAR 84 11:42 PST
From: JONL.PA
Subject: Re: AR 294: SINGLEFILEINDEX fails to list records
To:   Sannella, Jonl
cc:   Stansbury

In response to the message sent  26 Mar 84 13:36:36 PST (Monday) from Sannella.PA

See the documentation on teh extensions to SINGLEFILEINDEX -- the
variable DEFAULTINDEXEDTYPESLST holds the "driver" for what things will
be indexed.  I think the documentation is clear enough for a user to add
to the entry on DEFAULTINDEXEDTYPESLST under "RECORD".  If not, then the
documentation should be upgraded.


     ----- End of Forwarded Messages -----
*start*
00374 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 MAR 84 15:23 PST
From: ROACH.PA
Subject: SHOWDEF bombs on stream args
To:   LISPSUPPORT
cc:   ROACH

     (SHOWDEF NAME TYPE FILE) does not accept streams for its
FILE arg.  Breaks in UNPCAKFILENAME.  Also, SHOWDEF closes FILE
when it is finished.  Shouldn't SHOWDEF leave FILE open?
				Kelly
*start*
01542 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 29 MAR 84 16:25:31 PST
Return-path: <@SUMEX-AIM.ARPA:Sannella.pa@Xerox.ARPA>
Redistributed: Xerox1100UsersGroup^.PA
Received: from Xerox.ARPA by SUMEX-AIM.ARPA with TCP; Thu 29 Mar 84 14:08:49-PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 29 MAR 84 13:33:43 PST
Sender: Sannella.pa
Date: 29 Mar 84 13:29:35 PST (Thursday)
Subject: Re: Masterscope on large systems
In-reply-to: SHahn's message of Wed, 28 Mar 84 15:10:14 PST
To: Sam Hahn <SHahn@SUMEX-AIM.ARPA>
cc: 1100-users@SUMEX-AIM.ARPA
from: masinter.pa
reply-to: 1100Support.pasa

We keep a Masterscope database of the whole Interlisp system, which is
much larger than AGE. It isn't necessary to load the sources for any
file to Masterscope it. If you say

 . ANALYZE ON ANY FILES IN AGEFILES

where AGEFILES is a variable whose value is a list of the files in the
AGE system, it will load in the functions one at a time and analyze
them, and not retain the definitions around. If you still run into
problems doing this, you can do it in pieces, e.g., by analyzing half
the files.

Your problem with "BAD FILE NAME" is probably completely independent of
Masterscope. Perhaps some combination of you, Chris Schmidt, and
1100Support can help figure out what is going on there (e.g., what file
name was bad, what the stack under BAD FILE NAME was, can you get the
same error if you try to open the same file with the same name directly
by calling OPENFILE, etc.)
*start*
01082 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 16:27:16 PST (Thursday)
From: masinter.PA
Subject: review of .pasa ARs
To: Le.pasa
cc: LispSupport, Raim.pasa, vanMelle, masinter

Thu, I'm reviewing the ARs you submit. I hope you don't take my suggestions for improvements as criticisms! I'm glad that you are working on this, and want to help.

AR#349, from Teknowledge. I changed the Subject field to read "EMacs cursor positioning off by 1 char", since that describes what the problem IS. What you had "CHAT(DEC-20) Run EMACS" doesn't describe the problem but rather how you can get at it.

I also reduced the Impact from Serious ((can be worked around but seriously interferes with work) to Moderate (tolerable but clearly wrong). This is an arguable value judgement. I based it on the fact that it didn't destroy data or program, but rather just what the user temporarily saw on the screen. 

Serious vs Moderate isn't an "absolute" judgement, since we want to fix everything. It is just to calibrate against all of the other bug reports.
*start*
00383 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Thu, 29 Mar 84 16:45 PST
From: Raim.pasa
Subject: Re: review of .pasa ARs
In-reply-to: "masinter.PA's message of 29 Mar 84 16:27:16 PST (Thursday)"
To: masinter.PA
cc: LispSupport.PA, Raim, vanMelle.PA

Larry, 

Thank you for the courteous and supportive tone of your AR-related messages to Thu.

--Marty

*start*
00839 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: lichtenberg.wbst
Date: 29-Mar-84 19:45:29 EST
Subject: Strange Dlion Microcode bug
To: Lispsupport.pa
cc: purcell.pa, charnley.pa


I have been having some strange problems with Lisp lately.  Now and then, when I am doing perfectly innocent things like opening inspect windows, TEdit windows, and loading files, my DLion simply hangs.  No maintenance panel code, no PicoRaid, TeleRaid or the like... nuthin!  I know that  Lisp is stopped because there is no mouse tracking and no swapping... I don't know about the IOP.

I can't tell where this comes from, but I can say that I get 9305s alot when I load TEDITMENU off floppies into a sysout (MAKESYSDATE 26-Jan-84).  I haven't ever been able to load that without getting 9305s.  Could they be related?

/Mitch.
*start*
00820 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 16:59:26 PST (Thursday)
From: masinter.PA
Subject: AR#355: MPC 1273
To: le.pasa
cc: LispSupport, Raim.pasa, masinter

I changed the Subsystem from "Internal System Documentation" to "1108 Users Guide". The Internal documentation is stuff used entirely by LispSupport. The Maintenance Panel code list goes in the 1108 Users Guide, I think. 

Problem Type is Documentation. Impact is "Moderate". (I guess; what is the impact of not having accurate documentation?).

I don't know who is responsible for the 1108 Users Guide. I do know that MPC 1273 is not a Lisp-generated one, so maybe you can find it in one of the SDD books? 

Also, if Aaron Termin his MPC code list from Mabry Tyson, is it consistent with what Pasadena mails out?

*start*
01286 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 17:46:20 PST (Thursday)
From: masinter.PA
to: LispSupport

Received: from USC-ECL.ARPA by PARC-MAXC.ARPA; 29 MAR 84 17:27:22 PST
Return-path: <@USC-ECL.ARPA:FIKES@ECLD>
Received: from ECLD by ECLA with ECLnet; Thu 29 Mar 84 17:27:43-PST
Date: Thu, 29 Mar 84 17:26:49 PST
From: Richard Fikes <FIKES%ECLD@ECLA>   
Subject: Stacks and Generators
To: lispsupport.PA
cc: FIKES@ECLD.#ECLnet.ARPA, Masinter.PA, VanMelle.PA

This is a followup to my earlier messages regarding POSSIBILITIES.  I
have found bugs in my program that apparently were causing me to lose
my virtual memory due to stack problems.  Hence, I have no reason to
believe there are maicrocode problems regarding generators.  However,
because generators tie up so much stack space, they are of very
limited use.  So, I would like to reiterate my request for
modifications to POSSIBILITIES, GENERATOR, and COROUTINE to allow
creation of generators and coroutines with an empty stack (as with
processes).  That option would make them a much more useful part of
the programming environment.

Bill and Larry, thanks for the help in analyzing the situation.

richard
-------

----------------------------------------------------------------
*start*
01145 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from USC-ECL.ARPA by PARC-MAXC.ARPA; 29 MAR 84 17:27:22 PST
Return-path: <@USC-ECL.ARPA:FIKES@ECLD>
Received: from ECLD by ECLA with ECLnet; Thu 29 Mar 84 17:27:43-PST
Date: Thu, 29 Mar 84 17:26:49 PST
From: Richard Fikes <FIKES%ECLD@ECLA>   
Subject: Stacks and Generators
To: lispsupport.PA
cc: FIKES@ECLD.#ECLnet.ARPA, Masinter.PA, VanMelle.PA

This is a followup to my earlier messages regarding POSSIBILITIES.  I
have found bugs in my program that apparently were causing me to lose
my virtual memory due to stack problems.  Hence, I have no reason to
believe there are maicrocode problems regarding generators.  However,
because generators tie up so much stack space, they are of very
limited use.  So, I would like to reiterate my request for
modifications to POSSIBILITIES, GENERATOR, and COROUTINE to allow
creation of generators and coroutines with an empty stack (as with
processes).  That option would make them a much more useful part of
the programming environment.

Bill and Larry, thanks for the help in analyzing the situation.

richard
-------
*start*
01080 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 MAR 84 17:36 PST
From: JONL.PA
Subject: Re: Lisp: PROMPTREMINDERS
To:   Denber.wbst, LispSupport
cc:   JONL, DMRussell

In response to the message sent  27 Mar 84 11:56 EST from Denber.wbst

I'll have to ignore the part of your message about "File open in conflicting
way - file busy." since that is clearly not in the domain of PROMPTREMINDERS.

I fixed the typo in the "type description" for PROMPTREMINDERS filepkgcoms.

I added the feature that if the MESSAGE given to SETREMINDER (or however else
one installs a "message" in a periodic.prompt.reminder) is a listp, then
it is eval'd rather than being "flashed"  in the promptwindow.  Note that it
is eval'd only once per timeout.

Also, I factored out a subpart of the reminder package into a function called
UNTILKEYDOWNP, which repeatedly applys a function (given as arg) at a specified
interval, for a total duration of time; all of which is stopped when the user
depresses any key on the keyboard.  Dunno if this would be useful to others.

*start*
00590 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 17:52:42 PST (Thursday)
From: masinter.PA
Subject: Re: UNTILKEYDOWNP -- request for comments (including those on the coding)
In-reply-to: JONL's message of 29 MAR 84 17:38 PST
To: JonL
cc: LispSupport

There was a feature added a while back for the PERIODICALLYRECLAIM which was a timer called \LASTUSERACTION. The \LASTUSERACTION timer gets reset on mouse motions and keys as well. 

[note to LispSupport, AR documentation to document \LASTUSERACTION]

Would that be a better mechanism to build upon? 
*start*
00931 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 MAR 84 18:22 PST
From: JONL.PA
Subject: Re: UNTILKEYDOWNP -- request for comments (including those on the coding)
To:   masinter
cc:   LispSupport, JONL

In response to your message sent  29 Mar 84 17:52:42 PST (Thursday)

\LASTUSERACTION would indeed be a better coding of that section of UNTILKEYDOWNP that tries to figure out if anything has happened.  Minor problem however is that the documentation for UNTILKEYDOWNP (now in the PROMPTREMINDERS.tty/press file) specifies that LOCK, CTRL, LSHIFT, RSHIFT and mouse buttons "don't count")

If you look at the source code in {Phylum}<Lispusers>PROMPTREMINDERS, you'll
see how kludgy this can get; it keeps a vector of 112 bits which is an
image of the keyboard vector (from the emulator page) and keeps scanning
the keyboard vector until some change is noticed (modulo the keys that "don't
count").

*start*
01635 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 18:19:30 PST (Thursday)
From: masinter.PA
Subject: AR#391, Tedit and Lafite for a LOCALPRINTER
To: Sybalsky
cc: LispSupport, le.pasa, Barrera.pasa, masinter

There are two ways of handling LOCALPRINTER from TEDIT, I think.

The first is to use the printer in 'bitmap' mode; i.e., use the internal Lisp fonts and just send it in dotmatrix mode. This may need some work to get it to run fast. It may not work if the printer doesn't have enough resolution. (I think that the Siemens printer which is a high-resolution ink-jet might.)

The other way is to acquire the FONTS.WIDTHS of the built-in fonts for the local printer, and map the screen fonts onto that. That wouldn't give you a direct screen-printer mapping, but it might be faster and, just because of that, more acceptable.

Stefanie, are you planning at looking beyond the FX-80 at, say, the new Xerox color matrix printers, Versatecs, etc?

We've had some call for that.

Ed McGoldrick also showed me some output from Gould, where they had changed the LISTFILES code to use one of their color printers, with function names in red, comments in blue, etc.

We've gotten a request from Siemens for us to support the Siemens ink-jet printer, which has the advantage of being 72 dots/inch, the same as the screen resolution and I think better than the FX-80.

Notes to Thu and LispSupport, about how to handle this in AR database.  The request for ink-jet might make it into a separate AR, since that came from outside. The rest of this comment probably should get added to the end of AR#391.

*start*
00585 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 MAR 84 18:27 PST
From: JONL.PA
Subject: Re: Lisp: Wanted:  DLion area-fill microcode
To:   Jellinek, LispSupport
cc:   Lichtenberg.wbst, JONL, Burton

In response to the message sent  27 Mar 84 14:14 PST from Jellinek.pa

I'm not completely "up" on algorithms to do area filling, but I do know
of an application in ZetaLisp which uses triangulation -- namely it fills an
area under neath a curve by "coloring in" a lot of little triangles.

Maybe Burton or LIchtenberg.wbst has some knowledge about this?
*start*
00633 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 18:40 PST
From: Jellinek.pa
Subject: Re: Lisp: Wanted:  DLion area-fill microcode
In-reply-to: JONL.PA's message of 29 MAR 84 18:27 PST
To: JONL.PA
cc: Jellinek.PA, LispSupport.PA, Lichtenberg.wbst, Burton.PA

Hmm.  Sounds like an interesting technique; I wonder if will work for the general case of filling an arbitrary closed polygon?

I'm familiar with two other techniques:  1) the standard, dumb 4-way recursive fill, and 2) parity fill.
Check out Theo Pavlidis, "Algorithms for Graphics and Image Processing," p. 171 for more info.

	Herb

*start*
00555 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 MAR 84 18:58 PST
From: JONL.PA
Subject: Re: Lisp: ar#179, Performance Certification Tools
To:   Masinter, LispSupport
cc:   JONL

In response to the message sent  27 Mar 84 15:38 PST from Masinter.pa

I remember Ron's original message.  Yes, I should be the recipient
of this msg, and it's a bit low on my stack right now;  could be elevated
when the DLion local file system is "secure", so that there is a reasonable
way to re-boot and continue some series of computations.
*start*
00558 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: MASINTER.PA
Date: 29-Mar-84 19:52:55 PST
Subject: Re: Lisp: ar#179, Performance Certification Tools
In-reply-to: JONL's message of 29 MAR 84 18:58 PST
To: JONL
cc: Masinter, LispSupport

I don't disagree that this task could be lower priority than many of the others on your stack, but the problems with the DLion FS are irrelevant: performance certification would help us with Dolphin and Dorado, and the DLion FS problems may still permit the reading of a single INIT.LISP file.
*start*
00598 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 18:33 PST
From: JonL.pa
Subject: Lisp: DEdit - loss of overall scope
To: LispSupport.pa
cc: JonL.pa
Lisp-System-Date: 29-Mar-84 11:12:40
Machine-Type: Dorado

Call DEdit recursively on a "1-liner" function.  Then with "Delete-After" cause some humongous amount of code to be inserted after the "1-line" -- say about 50 lines or more.  Then DEdit can't seem to scroll up enough to see the last part of the inserted stuff; not even after trying to select the whole thing and reprinting nor by "thumb" scrolling.

*start*
00671 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 19:44 PST
From: Halasz.pa
Subject: TEdit: TEDITMENU does not detach window on Quit
To: TEditSupport
cc: 
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

If you open then QUIT from a TEDIt Menu, the next time you reshape the main TEdit window, the TEDIT menu reopens above the main window in the new reshaped configuration.  This window cannot be closed w/o closing the main window because it has no TEdit process running in it.  Moreover, it causes the quit from TEdit in the main window to crash with "arg not TEXTOBJ:  NIL".

Frank

*start*
00979 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 31 Mar 84 01:52:25 PST (Saturday)
From: le.pasa
Subject: Re: review of .pasa ARs
In-reply-to: masinter.PA's message of 29 Mar 84 16:27:16 PST (Thursday)
To: masinter.PA
cc: Le, LispSupport.PA, Raim

Larry,

Thank for all of your comments and inspiration.  I am truly glad that you take your time to review  the ARs which I  submit and suggest improvements .  Please don't get an idea that I take your suggestions as criticisms. ( I will let you know when I can't take your suggestions any more!!!).   

Also, I would like to let you know that I am up to date with Adobe.  Please don't feel that I am neglecting to use this system.  I haven't told you this, but all of us (1100customersupport) are very content when this system is taken seriously  at PARC . 

Without Jerry's help and your efforts, I don't think that LispAR could be here.  
I appreciate every little aid that you can give.  


Thu
   
*start*
00463 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 Mar 84 22:42 PST
From: Nuyens.pa
Format: TEdit
Subject: TEdit: possible find death
To: TEditSupport
cc: Nuyens.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dolphin

Check if find is affected by looks.  Apparently, find of {err} didn't find Kerr

(
TIMESROMAN	HELVETICA


TIMESROMAN
-z·*start*
00471 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 09:54 PST
From: Sannella.pa
Subject: TEdit: File won't read in
To: TEditSupport
cc: Sannella.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

I can't get the file {phylum}<lispcore>fugue6>doc>RS232Support.ted to read into Tedit.  It breaks with

END OF FILE
{phylum}<lispcore>fugue6>doc>RS232Support.ted

(TEDIT.BUILD.PCTB broken)


*start*
01071 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 09:42 PST
From: Masinter.pa
Subject: [Kiewiet.pasa: Re: AR#352]
To: LispSupport


     ----- Forwarded Messages -----

Date: 30 Mar 84 09:40 PST
From: Kiewiet.pasa
Subject: Re: AR#352
In-reply-to: masinter.PA's message of 29 Mar 84 16:53:41 PST (Thursday)
To: masinter.PA
cc: Le.pasa, Kiewiet.pasa, Raim.pasa, vanMelle.PA

More info on Lafite not quitting.

I had fallen into a number of Raid situations, all of them telling me about read errors in VMem. Since the AR, I have scavenged my disk and initialized fresh Lisp.  (I'm kind of superstitious, so I'm nervous about saying this, but so far, everything is okay.)

I will note the stack if it happends again. 
Also, I'm using  XMBDolphinLispMC.eb creation date 8-Mar-84 retrieved from {PHYLUM}<LISP>Current>.

Bill, yesterday I successfully used Lisp with X3DolphinLispMC.eb with both the 3 and 10 boards, for about an hour.  

Maybe I was having hardware problems all along.

Lorraine

     ----- End of Forwarded Messages -----
*start*
00880 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 09:46 PST
From: Masinter.pa
Subject: Re: AR#352
In-reply-to: Kiewiet.pasa's message of 30 Mar 84 09:40 PST
To: Kiewiet.pasa
cc: masinter.PA, Le.pasa, Raim.pasa, vanMelle.PA, LispSupport

I forwarded your message to LispSupport for inclusion in the AR. I guess this is cause for marking the AR as "Declined", yes?

The only reason I mentioned the "microcode version" field in the AR is that I've been trying to decide whether that is a useful field for us to keep track of. If a field isn't filled in on 95% of the ARs then there is no point in having it, it just clutters things up and doesn't give us anything to retrieve on. The "microcode version" IS relevant in about 3% of the bug reports we get. 

I wouldn't be sending this message except that we're still all new to this AR business.

*start*
00671 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 10:04 PST
From: Kiewiet.pasa
Subject: Re: AR#352
In-reply-to: Masinter.pa's message of 30 Mar 84 09:46 PST
To: Masinter.pa
cc: Kiewiet.pasa, Le.pasa, Raim.pasa, vanMelle.PA, LispSupport.pa

Yes, let's decline the AR as now I'm reasonably certain the hardware was to blame.  The processor is in the office with me and sometimes it gets pretty toasty in here.  

I'm for leaving the microcode version as a field; but I'm just one of these tremendously cautious people who likes to know I've covered all the bases.  

Thanks for the attention to this, and the whole AR project.
Lorraine
*start*
00752 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 MAR 84 20:52 PST
From: JONL.PA
Subject: Re: Lisp: EXPORTS.ALL problems
To:   desRivieres, LispSupport
cc:   JONL

In response to the message sent  28 Mar 84 18:21 PST from desRivieres.pa

Since you used the sysout from <LispCore>, you should use the EXPORTS.ALL
from <LispCore> also.  The usual procedure for "loading ABC" is to CONN
to {Phylum}<LispCore>Sources> and then just (LOAD 'ABC), which by directory
searching will find the EXPORTS.ALL  either from <LispCore>Sources> or from
<LispSources>.

I notice that the <Lisp>Library> version is about 1 month older than the
"release" sysout -- shouldn't it be updated now to at least correspond with
the Feb 26 version?

*start*
21432 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 09:39 PST
From: Masinter.pa
Format: TEdit
Subject: TEdit: NON-NUMERIC ARG under \TEDIT.FIND.FIRST.LINE under SHAPEW
To: TEditSupport
cc: Masinter.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dorado

here's the stack:

(1 0)
(102 112
"LKONNKKNHOKJMLHOIMLNOLIHOL@@"
"D@I@IA@H@HACEB@D@IBIA@A@BD@@"
"BBKBKCBJBJCCOBBFBKBJCBCBBD@@"
"B@ILIA@H@NACMB@G@ILFA@A@BD@@"
"IHIHIIHHHHIJMJHLHILIIHIHJL@@"
"A@I@IA@HHHABMBDD@IBIAAA@BD@@"
"BJKNNCJJJJCJGNFFCOBFCCCNGD@@"
"@H@@@@@@@@@@@@@@@@@@@@@@@@@@"
"HHHHHHHHHHHHHHHHHHHHHHHHHH@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"DCONNCKN@NGIIBBGCMNI@@@@@@@@"
"D@I@IA@H@IDBEBEDJA@M@@@@@@@@"
"B@I@IA@H@IDBABEDJA@O@@@@@@@@"
"B@ILIA@H@NGAINEGCILO@@@@@@@@"
"A@I@IA@H@JD@EBOLBA@K@@@@@@@@"
"A@I@IA@HHIDBEBHLBA@K@@@@@@@@"
"@HINNCHHHIGIIBHLCM@I@@@@@@@@"
"@H@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"GAIBFGKINICAH@@@@@@@@@@@@@@@"
"DJEBIDBE@MDJD@@@@@@@@@@@@@@@"
"DJEBHDBE@OD@D@@@@@@@@@@@@@@@"
"DJEBFGCILOC@H@@@@@@@@@@@@@@@"
"DJEBADBI@K@I@@@@@@@@@@@@@@@@"
"DJEBIDBE@KDJ@@@@@@@@@@@@@@@@"
"GAHLFGJE@ICCL@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"CBDDNGJBD@@@@@@@@@@@@@@@@@@@"
"DJDJIDBBL@@@@@@@@@@@@@@@@@@@"
"DBDJIDBBD@@@@@@@@@@@@@@@@@@@"
"CCLJNGBJD@@@@@@@@@@@@@@@@@@@"
"@JEOHDBJD@@@@@@@@@@@@@@@@@@@"
"DJEAHDCND@@@@@@@@@@@@@@@@@@@"
"CBEAHGIDN@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"GCLLIACINBDBAAGDKHLHK@@@@@@@"
"DJABIBJE@EDBAABFJEBHLH@@@@@@"
"DJA@IBJE@EDBAABGJEBHL@@@@@@@"
"GCHLOBKILEDBAEBGJEBJK@@@@@@@"
"EB@BIGNA@OLBAEBEJEBJHH@@@@@@"
"DJABIDFA@HLBAOBEJEBOLH@@@@@@"
"DKLLIDFANHOKLJGDKHLEC@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"CBDDNGJB@@@@@@@@@@@@@@@@@@@@"
"DJDJIDBB@@@@@@@@@@@@@@@@@@@@"
"DBDJIDBB@@@@@@@@@@@@@@@@@@@@"
"CCLJNGBJ@@@@@@@@@@@@@@@@@@@@"
"@JEOHDBJ@@@@@@@@@@@@@@@@@@@@"
"DJEAHDCN@@@@@@@@@@@@@@@@@@@@"
"CBEAHGID@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"GAIAGDKHLHKAIA@@@@@@@@@@@@@@"
"DJEABFJEBHLJEK@@@@@@@@@@@@@@"
"DJEABGJEBHLBEO@@@@@@@@@@@@@@"
"DJEEBGJEBJLBEE@@@@@@@@@@@@@@"
"DJEEBEJEBJLBEE@@@@@@@@@@@@@@"
"DJEOBEJEBOLJEA@@@@@@@@@@@@@@"
"GAHJGDKHLECAIA@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"DCONNCKN@NDKOOFDKMAODKONI@@@"
"D@I@IA@H@IDHHDIFJAAHFHI@M@@@"
"B@I@IA@H@IDHHDIGJAKHGHI@O@@@"
"B@ILIA@H@NDHHDIGKIKNGHILO@@@"
"A@I@IA@H@IDHHDIEJ@JHEHI@K@@@"
"A@I@IA@HHIDHHDIEJ@NHEHI@K@@@"
"@HINNCHHHNC@HDFDKLDODHI@I@@@"
"@H@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"GKILFGAINOH@@@@@@@@@@@@@@@@@"
"DBEBIDJE@B@@@@@@@@@@@@@@@@@@"
"DBEBIDJA@B@@@@@@@@@@@@@@@@@@"
"GCILIGAILB@@@@@@@@@@@@@@@@@@"
"DBIDIE@E@B@@@@@@@@@@@@@@@@@@"
"DBEBIDJE@B@@@@@@@@@@@@@@@@@@"
"GJEBFDIINB@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"DEMBNCBB@HKBDLO@BDDIGBANN@@@"
"DDIJIDJB@MLJEBH@BDJMDJA@I@@@"
"DDINIDJB@OLJE@H@BDJODJA@I@@@"
"EDINIDJJ@JLJDLN@CLJODJALN@@@"
"EDIFIDJJ@JLJDBH@BEOKDJA@J@@@"
"GLIFIDKNHHLJEBHBBEAKDJA@I@@@"
"BIMBNCADHHKAHLOBBEAIGCMNI@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"DBBLICCL@NGAHLOCAH@@@@@@@@@@"
"DCGBIDJ@@IDJEBHDJD@@@@@@@@@@"
"BCOBIDB@@IDJE@HDB@@@@@@@@@@@"
"BBKBICCH@NGBE@NCAH@@@@@@@@@@"
"ABKBI@J@@HEBE@H@HD@@@@@@@@@@"
"ABCBIDJ@HHDJEBHDJD@@@@@@@@@@"
"@JBLFCCLHHDIHLOCAH@@@@@@@@@@"
"@H@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"DCMABDCLLNDD@@@@@@@@@@@@@@@@"
"DBAAEDBABIFL@@@@@@@@@@@@@@@@")
and here's the frame:

(1 0)
(502 133
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@A@GLOINALGL@AOALDDO@@CNCHO@NCN@@H@NBBGL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@A@A@HAA@HA@@A@@HFDHH@B@A@HIA@H@@H@DCBD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@HA@HAA@HA@@A@@HFDHH@B@A@HIA@H@@H@DCBD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@HA@OAA@HA@@AN@HEDHH@CLA@O@L@H@@H@DBJGH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@DA@HAA@HA@@A@@HEDHH@B@A@J@B@H@@H@DBJD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@DA@HAA@HA@@A@@HDLHH@B@A@IAA@H@@H@DBFD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@BA@HAA@HA@BA@@HDLHHDB@A@HIA@HA@H@DBFD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@BA@OINALA@BA@ALDDO@DB@CHHHN@HA@OHNBBGL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@C@@@@@@@@@@@@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AOCNDDOHNCHAL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@DCNGLHIOALG@CHD@JGL@@FALGLG@N@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@DB@DDBAABD@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@D@HD@HHDBBDH@HD@JD@@@JBBD@HIA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@DB@BHBAABD@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@D@HD@E@DBBDH@HDCOD@@@J@BD@@IC@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@DCLA@BAACL@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@D@HGHB@DBBGH@HDADGH@ABALGHGAE@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@DB@A@BAABB@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AH@HD@B@DBBDD@HCADDD@AB@BDD@IE@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@DB@BHBAABBDD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@D@HD@E@DBBDDHHDGN@D@AO@B@D@II@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@DB@DDBAABBDD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@D@HD@HHDBBDDHHDBHDDF@BBBDDHIA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@DCNDDB@NCLCH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@D@HGLHHDALGHG@DBHCHB@BALCHG@N@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@D@@@@@@@@@@@@@D@@@@B@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@C@@@@@@@@@@@@AH@@@@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AABBGLG@NBBGL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@N@LGL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AABBD@BAABBA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AAADD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AEBBD@BAABBA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AADD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AECNGHBA@CNA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@NBDGH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AEBBD@BAGBBA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ABDDD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@JBBD@BAABBA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ACN@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@JBBD@BAABBA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AA@DDD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@JBBGLG@NBBA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@N@DCH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@NBBAD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AAALD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AABBAD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AI@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AABBGN@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AI@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@CNBH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AE@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@BBBH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AE@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AABBOL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AC@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AABBE@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AC@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@NBBE@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AAALGL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@C@@@@@@@@@@@L@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AAALDDO@NBB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@DBBCHHINALDDB@ECN@@B@DALA@G@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AA@HFDHIABB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@DBBA@LIABBDDB@EB@@@F@LBBC@HH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AE@HFDHIABJ@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@DBJA@LIABBEDBAOJ@@@JAD@BE@IH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AE@HEDHIABJ@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@DBJA@JIABBEDB@JCL@@B@DALA@JH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AE@HEDHIABJ@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AHBJA@JIABBEDAHJBB@@B@D@BA@JH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@J@HDLHIAAD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@DADA@IIABBBHBCO@B@@B@D@BA@LH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@J@HDLHIAAD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@DADA@IIABBBHBADBBC@B@DBBA@HH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@JALDDO@NAD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@DADCHHINALBHBADALA@OIOALGLG@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@D@@@@@@@@@@@B@@@@A@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@C@@@@@@@@@@@L@@@@B@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@C@@@@@@@@@@@@@@@@@@@@@@@@@L@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@ALDDOHN@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@DB@CHHIOCLGLG@NCLCHOAOALGHB@ECN@@G@D@LAH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@@HFDHAA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@DB@A@LI@BBD@HIABBA@HHDBBDDB@EB@@@HHLADBH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@@HFDHAA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@DB@A@LI@BBD@HIABBA@HHDBBDDBAOJ@@@HIDADBH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@@HEDO@L@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@DB@A@JINBBGHFA@CLA@HHDBBGHB@JCL@@A@DBDDH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@@HEDH@B@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AHB@A@JI@BBD@AA@BHA@O@DBBE@AHJBB@@B@DBDDH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@@HDLHAA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@DB@A@II@BBD@HIABDA@H@DBBDHBCO@B@@D@DCNGL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@@HDLHAA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@DB@A@II@BBD@HIABBA@H@DBBDDBADBBC@H@D@D@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AOALDDOHN@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@DCNCHHIOCLGLG@NBBCHH@DALDDBADALA@OIO@D@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@D@@@@@@@@@@@@@@@@@@@@@@@@@B@@@@A@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@C@@@@@@@@@@@@@@@@@@@@@@@@@L@@@@B@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AABBCHOAOBB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AOCNCH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AABBA@HHDBB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@A@BDD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AEBJA@HHDBB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@B@DDD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AEBJA@HHDCN@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@B@D@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AEBJA@HHDBB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@D@HA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@JADA@HHDBB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@D@HB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@JADA@HHDBB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@HA@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@JADCHO@DBB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@HA@GL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@C@@@@@@@@@@@L@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AOCNDDOHNCNGHOHDBB@@@@@@@@@@@@@@@@@@@@@@@@@@@DALGLOAO@HDDB@ECN@@C@DCNCHG@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@DB@DDBAA@HDDH@JCF@@@@@@@@@@@@@@@@@@@@@@@@@@@DBBA@HI@ADFLB@EB@@@E@LB@DDHH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@DB@BHBAA@HDDH@JCF@@@@@@@@@@@@@@@@@@@@@@@@@@@DBBA@HI@ADFLBAOJ@@@EADB@DDIH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@DCLA@B@L@HGHO@JBJ@@@@@@@@@@@@@@@@@@@@@@@@@@@DAHA@OANADEDB@JCL@@I@DCL@HJH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@DB@A@B@B@HE@HAABJ@@@@@@@@@@@@@@@@@@@@@@@@@@AH@DA@JA@BBEDAHJBB@@I@DBBA@JH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@DB@BHBAA@HDHHAOBJ@@@@@@@@@@@@@@@@@@@@@@@@@@@DBBA@IA@CNEDBCO@B@@OHD@BB@LH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@DB@DDBAA@HDDHAABJ@@@@@@@@@@@@@@@@@@@@@@@@@@@DBBA@HI@BBEDBADBBC@A@DBBD@HH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@DCNDDB@N@HDDOIABB@@@@@@@@@@@@@@@@@@@@@@@@@@@DALA@HIOBBDDBADALA@AAOALGLG@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@D@@@@@@@@@@@B@@@@A@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@C@@@@@@@@@@@L@@@@B@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@ALDDOH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AAALD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@@HFDH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AI@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@@HFDH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AI@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@@HEDO@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AE@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@@HEDH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AE@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@@HDLH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AC@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@@HDLH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AC@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AOALDDOH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AAALGL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@NBBDDG@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AAALD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AABBFDHH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AI@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AABBFDHH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AI@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@CNEDHH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AE@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@BBEDHH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AE@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AABBDLHH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AC@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AABBDLHH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AC@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@NBBDDG@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AAALGL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@NBB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AAALD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AABB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AI@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AABB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AI@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@CN@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AE@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@BB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AE@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AABB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AC@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"AABB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AC@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@NBB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AAALGL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@")


TIMESROMAN
Ÿ
BMOBJ.GETFN
TIMESROMAND
BMOBJ.GETFN

TIMESROMANRïz·*start*
00873 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 10:52 PST
From: Roach.pa
Subject: TEDIT handling of titleless windows
To: LISPSUPPORT
cc: Roach.pa

     Attn: Sybalsky, Nuyens     Impact: Annoying
     Although not documented, from the TEDIT code I infer that the user is allowed to assign his own titles to TEDIT windows.  On my interpretation, this should include titleless windows.  However, if you Quit a titleless TEDIT window, TEDIT will give the window the title "Edit Window [Inactive]" which is not the behaviour you get if you are using your own window title.  It would be better to treat titleless windows on an equal basis with user titled windows.
     I am able to patch around this by using a TEDIT.QUITFN window property, but the quitfn requires that you know some fairly internal details of TEDIT's code.
					Kelly

*start*
00653 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 11:16 PST
From: Roach.pa
Subject: No programmatic way to determine TEDIT looks
To: LispSupport.pa
cc: Roach.pa

     Although TEDIT offers function TEDIT.LOOKS for the user to set the looks of text in a document, there does not seem to be any programmatic way to determine the looks of a character in the document such as
     (TEDIT.GETLOOKS STREAM CH#orSEL)
returning the sort of plist TEDIT.LOOKS accepts.
     There is no way to interrogate the caret's looks, no way to determine where the paragraphs are, and no way to determine a paragraph's looks.
					Kelly
*start*
00572 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 11:26 PST
From: Roach.pa
Subject: TEXTOBJ arg in TEDIT.INCLUDE
To: LispSupport.pa
cc: Roach.pa

     The specified way of calling TEDIT.INCLUDE:
        (TEDIT.INCLUDE TEXTOBJ FILE START END)
stands out from the crowd.  All other TEDIT functions for which a TEXTOBJ or a STREAM arg might make sense take the STREAM route.  Since TEXTOBJ's are accessible from their textstreams, why not change the above way of doing business to
        (TEDIT.INCLUDE STREAM FILE START END)
					Kelly
*start*
13121 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 13:21 PST
From: Masinter.pa
Subject: [The Services Implementors <Ladner.pa>: Fourth Update of Services 8.0 System Test]
To: LISPSUPPORT
cc: Sheil

Submit AR: please upgrade Phylex to Services 8.0, and test Interlisp-D against it. (I don't think it is necessary to include this entire message in the AR, but maybe at least the header.)  I don't know who this should be ATTN to; either Sannella or Sybalsky, I think.

Submit AR: Update Interlisp-D to Services 8.0 protocol. (Communications/NS). Description: The Xerox NS protocols have changed to not require the ability to read passwords from the server, but rather to implement a more reasonable authentication protocol. Probably other changes have been made as well, e.g., the packet exchange protocol. The first task is to make sure that Interlisp-D will play properly with Services 8.0. The second task is to read carefully the release documentation and submit the ARs of what we have to do to take advantage of any new network services. (attn: Cooper).


     ----- Forwarded Messages -----

Date: 28 Mar 84 22:10:19 PST (Wednesday)
Subject: Fourth Update of Services 8.0 System Test
From: The Services Implementors <Ladner.pa>
To: ServicesSystemTest^.es
Reply-to: Ladner.pa

This message announces the fourth update to Services 8.0 System Test.  It lists the changes made to the software and documentation since the third update of system test, and includes a current version of the original release message.

This update is based on Pilot 11.0i.


CHANGES

The "Start of System Test" message, which follows this update notice, has been modified to be pertinent to this update.


CHANGES TO SYSTEM TEST CONFIGURATION

The system test configuration has been extensively expanded.  Consult the document Services 8.0 System Test Configuration for the current configuration.


CHANGES TO SOFTWARE

Services Common Software starts System Test with this update.

Services is supplying its own microcode with this update.  There is on the AlphaServices directory a microcode file that corresponds to the equivalent Pilot microcode file.  These files should be used on all servers using AlphaServices software.

The Server Monitor was made a full-fledged service; its prefix will be SMS; it will not be named in the Clearinghouse.

Backup/Restore over the network is included in this update.

The following ARs were fixed in this update:

Diagnostics: 
ECS: 5451 5501 5502 5591 5620 5665 5732 5747 5791 5792 5795 5797 5813 5850
     5831 5832 5851 5906 5923 5938 5981 5993 5996 6017 6031 6032 6054 6055 6082
     6083 6106 6116  
FS:  3422 5610 5618 5807 5862 5866 5873 5875 5905 5909 5912 5916 5919 5925 5928
     6018 6044 6046 6061 6066 6124
GWS: 4857 3204 5749 3661 5983 
IRS: 5962 5964 5980 6036 6132 6133 6356 6357
PS:  1190 1515 1547 1655 1984 2004 2475 2557 2890 3159 3643 5006 5007 5340
     5823 5949 6048 6004 5737 6027
RBS: 6090 6091 6092 6093 6095 6097 6099 6100 6119 6120 6122  
SCS: 598 666 1759 2474 4742 5223 5257 5615 5565 5622 5626 5688 5842 5892 5966 6003
     6005
Server Monitor: 5953 5960 5961 5963 5965 6123


CHANGES TO DOCUMENTATION

Due to a space shortage on McKinley, the source documents for Services ESCNs and functional specifications are not on AlphaServices; only the Interpress masters are stored.

The following documents are new and have been stored in the file drawer.

	[McKinley]<AlphaServices>8.0>Services 8.0 ESCNs>
		Backup/Restore FS
		Services Common Software FS>*
		Server Monitor ESCN


The following documents were revised.

	[McKinley]<AlphaServices>8.0>Restrictions.txt
	The restrictions were updated for AS, ECS, GWS, IRS.  This is an XDE
	text file.

	[McKinley]<AlphaServices>8.0>Services 8.0 Release Summary
	Minor corrections.

	[McKinley]<AlphaServices>8.0>Services 8.0 ESCNs>
		Clearinghouse FS
		Internetwork Router Service ESCN


 
The updated release message follows:
---------------------------------------------
Services is starting System Test of Services 8.0 in a staged fashion; not all of the functionality is in System Test at this time.  All services are in System Test, but Services Common Software is not, although there is a sufficient amount of Services Common Software to support the other services.  All of the agent software (stubs, filing, etc., is available).

This message provides pointers to the software and documentation comprising this release, discusses schedule and system test information, lists available services for client use, and describes methods for problem reporting.


SOFTWARE AND DOCUMENTATION

This software is based on Pilot 11.0i.  Files can be found on:

	[McKinley]<AlphaServices>8.0>	-- Documentation
	[Rain|Iris]<AlphaServices>8.0>	-- Software

DF's for components on the archive directory are on [Sun]<AServices>8.0>DF>.  The DF's for the 8.0h version of Services are available on [Sun]<AServices>8.0h>DF>.
	
The document describing this release can be found on:

	[McKinley]<AlphaServices>8.0>Services 8.0 Release Summary
	[McKinley]<AlphaServices>8.0>Services 8.0 Release Summary (Interpress)

This document describes the release and associated documentation, and where it is stored.  (The release summary refers to the release as it will eventually be.  References contained therein to services which haven't started System Test should be ignored.)

Given that the bootfile does not contain all of the services, installation of Services software over the ethernet is complicated.  Anyone wishing to do this should contact Bob Ladner.

A list of changes to the Services Programmer's manual are contained in the folder

	[McKinley]<AlphaServices>8.0>
		Services 8.0 Programmer's Manual Change Summary>
	[McKinley]<AlphaServices>8.0>
		Services 8.0 Programmer's Manual Change Summary (Interpress)>

A list of restrictions and facilities not yet implemented is available on

	[McKinley]<AlphaServices>8.0>Restrictions.txt
	[McKinley]<AlphaServices>8.0>Restrictions.interpress

The source file is a text file prepared in the Mesa developement environment and cannot be read directly using a Star workstation.

	
Mail sent to ServicesSystemTest^ is retained on:

	[McKinley]<AlphaServices>8.0>ServicesSystemTest.mail

The source file is a mail file prepared in the Mesa developement environment and cannot be read directly using a Star workstation.
	
This version is archived as:

	[Sun]<AServices>8.0>



SCHEDULE AND INFORMATION

Services System and Product Tests are scheduled to end on June 15, at which point Services 8.0 will be released.  Updates to Services 8.0 System Test are scheduled on a bi-weekly basis until the start of Product Test scheduled for April 2.  Services will start Product Test on a staged basis.  On April 2, the GWS, IRS, and ITS will start Product Test.  On April 16, all other services will start Product Test except for SCS.  SCS will start Product Test on May 1 as will the Backup/Restore feature of the File Service.
	
Updates after the start of Product Test will occur as necessary until the end of OS 5.0 Product Test, at which point Services 8.0 will be released.

Information for Services 8.0 system testers is disseminated through the distribution list ServicesSystemTest^.es.  If you know of anyone who should be on this list and who is not, please send a message to Owners-ServicesSystemTest^.es.


AVAILABLE SERVICES

A number of services are being offered for use by Services 8.0 system testers.  Those currently provided are listed below; others will be announced when the necessary software and/or hardware becomes available.  All services are registered in either the AlphaServices-ES, or AlphaServices-PA domains.

Debbie <Menzies.es> will act as System Adminstrator for the El Segundo services and Jennifer Douglas <JDouglas.pa> will act as System Administrator for the Palo Alto services.  Please contact them with your administrative needs or questions, or in the case of a down or inaccessible service.       

Clearinghouse Services:

  AmericanExpress serves OSBU South:Xerox, OSBU North:Xerox
  Bonita          serves AlphaServices-ES:Xerox
  Beechnut-CHS    serves OSBU North:Xerox, OSBU South:Xerox
  DeSoto          serves Alphaservices-PTL:Xerox
  Pickeral-CHS    serves Alphaservices-PA:Xerox, AlphaServices-ES:Xerox
  Hotlips         serves OSBU Bayshore:Xerox
  Ridge-CHS       serves AlphaServices-ES:Xerox, OSBU Bayshore:Xerox,
  Visa            serves OSBU North:Xerox, OSBU South:Xerox
  Whale           serves Alphaservices-PA:Xerox, AlphaServices-ES:Xerox

External Communication Services:

TTY:
  Rome-ECS:AlphaServices-PA
	TTY Ports: 1200B1CIU659, 1200B2CIU659, 1200B3CIU659, 1200B4CIU659; all 
			registered in AlphaServices-PA
		1200 baud, asynchronous, full-duplex, auto-dial,
		Bell 212A-compatible
	TTY Ports: 300A1CIU659,300A2CIU659,300A3CIU659,300A4CIU659; all registered
			in AlphaServices-PA
		300 baud, asynchronous, full-duplex, auto-dial,
		Bell 103/212A-compatible

3270 BSC:
  Sans-ECS:AlphaServices-PA
	IBM 3270 host: OnlineBusinessSystems:AlphaServices-PA
	   at Online Business Systems (contact Larry <Garlick.PA> for info on use)
  Maserati:AlphaServices-ES
	IBM 3270 host: ES-to-Rochester:AlphaServices-ES
		at GSD/Rochester (contact Larry <Garlick.PA> for info on use)

3270 SNA:
  Rome-ECS:AlphaServices-PA
	IBM 3270 host: dial-in line to Online Business Systems
		(contact Larry <Garlick.pa> for information on use)
	   
File Services

  Cambridge:AlphaServices-ES (T80, primary FS on UpAndComing:AlphaServices-ES)
  Gutenberg-FS:AlphaServices-PA (T80 disk)
  Oxford:AlphaServices-ES (T80, secondary FS on UpAndComing:AlphaServices-ES)
  Reba:AlphaServices-PA (SA-4008 disk) This file service is restricted for use by
       only the Remote Batch Service Form5081.
  SanFrancisco:AlphaServices-ES (SA-1004 disk)
  Thunderbird:AlphaServices-PTL (SA-1004 disk)

  
Gateway Services:

  Pesky-GWS:AlphaServices-PA
	Phone: (415) 856-2419
	Port: dial-in, 2400 baud, synchronous, half-duplex, Bell 201-C compatible
	
Interactive Terminal Services

  Mercedes:AlphaServices-ES
	All of the lines in the list below are on a rotary, the 300 baud first. 
	Phone: (213) 615-3187
	Port: 4 lines, 300 baud, asynchronous, full duplex, Bell 103/212A
		compatible
	Phone: (213) 615-0656
	Port: 4 lines, 1200 baud, asynchronous, full duplex, Bell 212A compatible
  
Internetwork Routing Services
	
  Bern-IRS:AlphaServices-PA
  Betelgeuse-IRS:AlphaServices-ES
  Ferrari:AlphaServices-PTL
        local port
  Rolls:AlphaServices-ES
        local port
	TTY Port: UB 873A/A1 registered in AlphaServices-ES owned by the ECS
	          Lancia:AlphaServices-ES
		  9600 baud, asynchronous, full-duplex
	
Mail Services

  Acacia-MS    serves OSBU North:Xerox
  Beechnut-MS  serves OSBU North:Xerox
  Brookside    serves OSBU South:Xerox
  Beaulieu     serves AlphaServices-ES:Xerox
  
Monitor Service
  
  Resides on Bern:AlphaServices-PA

Print Service

  AppleValley:AlphaServices-ES:Xerox  (Raven printing in CP10 product test lab)
  EasyReader:AlphaServices-ES:Xerox  (FAX printing in CP10 room 1224)
         phone: (213) 640-7858
  Examiner:OSBU South:Xerox (printer in CP10, outside room 1627)
  Gutenberg:AlphaServices-PA (T-80 printer in 200G)
  Seabiscuit:OSBU North (printer in 200G)
  
Remote Batch Service

  Form5081:AlphaServices-PA
	
NOTES FOR STAR 4.x USERS

Except as noted in the Release Summary, Services 8.0 is backward compatible with OS 4.0, 4.1, and 4.2 releases. 

 
ARs AND PROBLEMS

As usual, please submit all problem reports via the OS Software Adobe (AR) System, specifying "Services" as the system, 8.0h as the version and the hardware configuration on which the trouble occurred.  AFTER submitting the AR, you may contact your favorite Services implementor by phone or message or in person for attention to urgent problems.  (For crashes, if the appropriate person is not available, you should attempt to ascertain the error message that caused the crash, and the call stack before rebooting.)  Here are the appropriate names, by service:

	Clearinghouse Service: Mark <Gealy.pa>
	External Communication Service: Bill <Danielson.pa>
	File Service: Frank <Hanzel.es>
	Diagnostics: Larry <Kluger.pa>
	Gateway Service: Bill <Danielson.pa>
	Interactive Terminal Service: Juan <Porcar.pa>
	Internetwork Routing Service: Larry <Kluger.pa>
	Mail Service: Ted <Wobber.pa>
	Mail Gateway Service: Randy <Gobbel.pa>
	Print Service: John <Beeley.es>
	Remote Batch Service: Doug <Muirhead.pa>
	Services Common Software: Saranjit <Saund.es>

Please remember that the AR database is our primary way of keeping track of the many problem reports that we receive during System Test.  We also depend on patterns of problems reported in ARs to develop a global picture of the state of the system and of the progress of System Test.  We cannot keep track of problems reported by word of mouth or by message to random implementors, and therefore we are unable to pay serious attention to problems unless they are documented in ARs.


The Services Implementors
---------------------------------------------
*start*
01149 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 12:42 PST
From: vanMelle.pa
Subject: Re: Periodic Interrupts
In-reply-to: Dering.pasa's message of 28 Mar 84 17:13 PST
To: Dering.pasa
cc: 1100Support.pasa, LispSupport, vanMelle.pa

The main thing Eric needs to know is that the \PERIODIC.INTERRUPT definition MUST be of the form

  (if \INTERRUPTABLE
    then do-something)

In other words, if \INTERRUPTABLE (a specvar) is NIL, the function MUST immediately return.

Otherwise, \PERIODIC.INTERRUPT should be no more dangerous to use than an interrupt caused by an interrupt character, except, of course, that since it happens much more frequently than keyboard interrupts, there is a much higher chance that it will discover places in the system that should have been interrupt protected.  Furthermore, if you simulate a crude preemptive scheduler by defining your periodic interrupt function as

  (if \INTERRUPTABLE
    then (BLOCK))

you will also discover places that aren't monitor-locked appropriately and/or assume that process switches will not occur inside code that doesn't explicitly BLOCK. 

	Bill
*start*
00691 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 13:37 PST
From: Masinter.pa
Subject: Lisp: unix file names don't work with UNPACKFILENAME
To: LispSupport.pa
cc: kipps@Rand-unix
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dorado

When I tried to LOADFROM(ELLIE), it didn't add ELLIE to FILELST when I got done.

I tracked this problem down to the fact that ROOTFILENAME(/a/rosie/rosie2.4/ELLIE.;2) returned /a/rosie/rosie2.4/ELLIE rather than ELLIE. 

I don't know why LOADFROM of a file requires ROOTFILENAME to work that way, especially since I was loading the file from a Tenex. (This might be two separate ARs, but leave it as one for now.)

*start*
00412 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 16:01 EST
From: Denber.wbst
Subject: TEdit: ERROR
To: TEditSupport.pa
TEdit-System-Date:  1-Mar-84 13:54:34
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dolphin

Moving Text down after DEL.
-78

(ERROR broken)
97:

I was doing some backspacing over tabs at the beginning (or end - I'm not sure) of a line.

			- Michel
*start*
00549 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 13:11 PST
From: Sheil.pa
Subject: TEdit: Non menu substitute/find dont allow shift select
To: TEditSupport
cc: lispsupport

TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dolphin

Using the find/substitue commands in the non-TEditmenu case, I cannot shift select target or replace strings out of the document being edited. This is a royal pain if one is trying to find all instances of "dfghsdfgahgfkaghkajghkj".

Beau

*start*
01316 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 17:01 EST
From: Denber.wbst
Subject: Re: Lisp: PROMPTREMINDERS
In-reply-to: JONL.PA's message of 29 MAR 84 17:36 PST
To: JONL.PA
cc: LispSupport.PA

OK - I've got two questions:

1. In the new documentation, the example is (SETREMINDER NIL 600 (PROGN (AND (FIND.PROCESS 'LISTFILES... etc.

What keeps the PROGN from running as soon as you call the SETREMINDER?  In fact when I tried to say (PROGN (BEEPON 100)) for the message, it started beeping right away, not at the wake-up time.

2. Suppose I want to change the definition of a reminder (like the guy is running CALENDAR and he decides the message should beep *after* he entered it).  I apparently can't access the record fields of the reminder myself.  I tried saying something ugly like

 (SUBST
  '(PROGN (PROMPTPRINT 
		    (CADDR (GETDEF REMNAME 'REMINDER)))
		    (BEEPON 100))
   (CADDR (GETDEF REMNAME 'REMINDER))
   (GETDEF REMNAME 'REMINDER]

to change the message of REMNAME from a string to an expr, but that doesn't work (when the time comes, nothing happens).  (I realize it also doesn't work because the interior expressions don't get eval'd - how do you write an expression like (FOO (BAR X Y)) where you want to eval BAR without eval-ing FOO?)

			- Michel
*start*
00371 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 MAR 84 16:13 PST
From: JONL.PA
Subject: Re: Lisp: PROMPTREMINDERS
To:   Denber.wbst, JONL
cc:   LispSupport

In response to the message sent  30 Mar 84 17:01 EST from Denber.wbst

1) a bug in the documentation -- missing "'" -- which I'm fixing
2) why not just redefine the entire reminder?
*start*
00533 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 14:22 PST
From: Burton.pa
Subject: Lafite: menu name change request
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 27-Mar-84 08:53:34

On middle button of "send Mail"  I get confused about the difference between "private form" and "standard form".  
I always select private when I mean standard because I am intending to send a private message.  How about changing "private" to "stored form" or some such.

Richard
*start*
10964 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 14:58 PST
From: Masinter.pa
Format: TEdit
Subject: Lafite is confused about start of message ?
To: LafiteSupport

dunno why this happened. It hit when I did a Display.

(1 0)
(392 103
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"D@@@G@D@@@@@@D@@@@@@@@@CH@@@@@@H@@@D@@@@@@@@@@@@@@@@@@@@AL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"D@@@H@@B@@@@@@@@@@@@@@@D@@@@@@@H@@@D@@@@A@@@@@H@@@@D@@@@B@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"D@GANALGHG@@ALCH@@NALEHOAAALCHFH@ALEHGAACL@@GANALEHO@@ALGH@AKALCHG@NAJCH@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"D@@HH@DB@HH@@DDD@AABBFDDAABBDDIH@@BFDHIAA@@@HHH@BFDD@@BBB@@AEBBDDHHABFDD@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"D@GHH@DB@OH@@DC@@A@BBDDDAAAHGLHH@ANDDHIAA@@@F@HAND@D@@BBB@@AECNC@F@OBBGL@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"D@HHH@DB@H@@@D@H@A@BBDDDAA@DD@HH@BBDDHIAA@@@A@HBBD@D@@BBB@@AEB@@HAAABBD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"D@HHH@DBDHH@@DDD@AABBDDDACBBDDIH@BBFDHICAB@@HHIBBD@DH@BBB@@AEBBDDHIABFDD@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"GLGHH@DAHG@@@DCH@@NALDDD@MALCHFH@ANEHG@M@L@@G@FAND@C@@ALB@@AEALCHG@OAJCH@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@B@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@L@@@@@@@@@@@@@@@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@H@DCNCHOIOBBCHG@D@JAH@@DALCHG@NAL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@H@JB@A@BA@CFDDHHD@JBH@@LBBDDHIABB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@H@JB@A@BA@CFDDHHDCOBH@AD@BD@HACBF@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@H@JCLA@BANBJC@H@DADDH@@DALGHOAEBJ@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"F@HAAB@A@BA@BJ@HKHCADDH@@D@BDDHIEBJ@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@HAOB@A@BA@BJDDHHDGNGL@@D@BDDHIICB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@HAAB@A@BA@BJDDHHDBH@HF@DBBDDHIABB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@OIAB@CHBAOBBCHG@DBH@HBAOALCHG@NAL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@@@@@@@@@@@@@@@@@D@@@@B@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@L@@@@@@@@@@@@@@@AH@@@@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@H@@@@@@@@@@@@@@@@@@@B@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@HIOB@GH@A@@@@@H@@@@A@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@HI@B@DD@A@@@@@H@@@@A@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"B@HI@B@DD@AFBLCHI@NBL@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"B@OINB@DD@AICBDDJAACB@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"B@HI@B@GH@AAB@DDLAOBB@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"B@HI@B@D@@AAB@DDJA@BB@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"B@HI@B@D@@AIB@DDIAABB@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@HIOCND@@AFB@CHHHNBBA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"A@@@@@@@@@@@@@@@@@@@@A@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@H@@@@@@@@@@@@@@@@@@@B@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"CHG@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"DDHH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"D@@HD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"GHG@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"DD@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"DD@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"DDHHD@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"CHG@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@")
¹
TIMESROMAN)€
BMOBJ.GETFN

TIMESROMAN*:z·*start*
00439 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 16:50 PST
From: vanMelle.pa
Subject: Re: Lafite is confused about start of message ?
In-reply-to: Masinter.pa's message of 30 Mar 84 14:58 PST
To: Masinter.pa
cc: LafiteSupport.pa

It indicates some sort of inconsistency in the file.  It's not supposed to happen, so I'd certainly be interested in looking at it closer.  Repeatable?  What file?

	Bill
*start*
00507 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 16:55 PST
From: Masinter.pa
Subject: Re: Lafite is confused about start of message ?
In-reply-to: vanMelle.pa's message of 30 Mar 84 16:50 PST
To: vanMelle.pa
cc: Masinter.pa, LafiteSupport.pa

sorry to say, I got out of it by (a) closing the browser and saying "don't update", and then Quiting lafite, and then deleting the -TOC file, and then LAFITE(ON).

Will try to let you poke around next time it happens.

Larry

*start*
00532 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 MAR 84 15:38 PST
From: JONL.PA
Subject: Re: protection for [Phylum]<Lisp> directory
To:   Sannella
cc:   LispSupport, JONL

In response to your message sent  29 Mar 84 14:32:12 PST (Thursday)

1) I already gave you the reason why the RS232 file had to go on <Lisp>Library>
    do you want it again?
2) you've begged the question of the hokey setting for protection on <Lisp>
   which allows one to write a file, but not delete the file he just wrote.

*start*
00468 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 15:39 PST
From: Masinter.pa
Subject: Lisp: manual doesn't talk about CASEARRAY in ALPHORDER
To: LispSupport.pa
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dorado

type: documentation.
Should include note in STREQUAL that (STREQUAL X Y) = (EQ 'EQUAL (ALPHORDER X Y)) and that can do things like

(EQ 'EQUAL (ALPHORDER X Y UPPERCASEARRAY)) to do string-equal-except-for-case.
*start*
00735 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 15:44 PST
From: Masinter.pa
Subject: [ROACH.PA: FULLXPOINTER's in record declarations]
To: LispSupport
cc: Roach

AR under record package, type BUG, Subject: NonAligned FULLXPOINTER causes HELP.


     ----- Forwarded Messages -----

Date:  1 JAN 84 17:50 PST
From: ROACH.PA
Subject: FULLXPOINTER's in record declarations
To:   LISPCORE^
cc:   ROACH

     How come
	(DATATYPE FOO ((A WORD)(B FULLXPOINTER)))
doesn't work?  The record package seems to be sensitive to whether
or not the FULLXPOINTER comes after an odd number of WORDs, but
the only error message I get is "help!"  Is this a bug?
			Kelly

     ----- End of Forwarded Messages -----
*start*
00799 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 15:46 PST
From: Jellinek.pa
Subject: Lisp: More than one stream for same file
To: LispSupport.pa
cc: Jellinek.pa
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dolphin

This is probably the n-hundredth (n >= 1) AR on this subject, but oh! how I wish I could have more than one stream open on the same file, for reading, writing, whatever.   It is almost unbelievable that it's not possible to do so.  Case in point:  I needed both to print and to compile a file of mine.  I started a TCOMPL, realized that I also wanted hardcopy, hit ctrl-B, and ran LISTFILES.  I then typed OK.  Result: hardcopy of the tail of the file, and no compile - LISTFILES had closed the single stream to the file.  Blecch!

	Herb

*start*
01064 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 15:49 PST
From: Masinter.pa
Subject: [Tong.PA: FILECOMSLST bug]
To: LispSupport

Environment/File package, Bug
attn: Masinter, priority: Perhaps
Impact: Minor

     ----- Forwarded Messages -----

Date: Mon, 2 Jan 84 12:48 PST
From: Tong.PA
Subject: FILECOMSLST bug
To: LispSupport
cc: Bobrow, Tong

Here's an amusing bug for you that Danny Bobrow and I stumbled across.

I have a COMS list that begins:

( (* * Package for . . .)
  (VARS EditCommands OtherCommands . . .))

When I run (FILECOMSLST 'LOOPSFILEBROWSE 'VARS) I get back:

(LOOPSFILEBROWSECOMS Package EditCommands OtherCommands . . .)

The ringer in this lineup is Package; that aint no variable! But FILECOMSLST apparently thinks it is because the double-starred comment is a list in the COMS list and coincidentally has the form:
	( A * B)
and so B (i.e. Package) is interpreted as the name for a list of entities of type A (i.e. *).

Have fun with this one!

Chris


     ----- End of Forwarded Messages -----
*start*
01434 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 15:51 PST
From: Masinter.pa
Subject: [Stansbury.pa: Lisp: DECL SATISFIES]
To: LispSupport

I forget where DECL went. I think under Environment/Other, but not sure. Impact: Moderate, Type: Bug, Priority, Unlikely


     ----- Forwarded Messages -----

Date:  2 Jan 84 19:28 PST
From: Stansbury.pa
Subject: Lisp: DECL SATISFIES
To: Lispcore^
cc: Stansbury.pa
Lisp-System-Date:  1-Jan-84 03:16:41
Machine-Type: Dorado

A SATISFIES clause in a DLAMBDA failed to recognise my having deleted a field of a datatype: it kept referencing the missing field.  Deleting the SATISFIES clause, exiting DEdit, running the function, reentering DEdit, and retyping the clause verbatim was the only way to solve the problem.  

Details: the offending DLAMBDA was 
(DLAMBDA ((M FSM (SATISFIES (EQ fetch NAME of (CAR (STATES M)))(QUOTE  START))))) ...]

and FSM (without the old field) is defined as 
(DATATYPE FSM (START BackLinks SymbolTable) (TYPE? (AND (type? STATE (FETCH START OF DATUM)) (type? (ONEOF HASHARRAY NIL) (FETCH BackLinks OF DATUM)) (type? (ONEOF HASHARRAY NIL) (fetch (FSM SymbolTable) of DATUM)))))

Perusal of the stack indicated that the SATISFIES was attempting to run the old DECLTYPE for FSM (that is, with a (type? ... (fetch OLDFIELD of DATUM)) check on the no-longer-existant field.)

--Tayloe.

     ----- End of Forwarded Messages -----
*start*
01706 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 15:51 PST
From: vanMelle.pa
Subject: TEdit: won't scroll big lines small amount
To: TEditSupport
cc: vanMelle.pa

TEdit System Date:  2-Mar-84 16:54:27
Lisp System Date: 15-Mar-84 00:13:18
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Annoying

Since Tedit always scrolls by integral number of lines, if there is something in the text that is tall, e.g. an image object of some sort, then (1) it doesn't appear when you scroll text upward until you have scrolled far enough to display the entire object (the ruler in the tedit menu seems to work this way), and (2) if you try to scroll downward where the next thing to move into the window would be one of these tall lines, and you request a scroll amount that is less than the line's height, then no scroll at all occurs.  This can be very frustrating; in the case of a message Larry sent there was an object that was more than half the height of my window tall; when I tried to scroll downward at the end of the text, it looked like tedit was stuck.  A related problem to (2) is that if the top line of the window is tall, and I ask to scroll a small amount, it still scrolls the entire top line out of the window.

(2) would be slightly better if the scrolling routine rounded to the nearest number of lines, rather than truncating.  But better still, if you can get Tedit to display lines that are only partially in the window, is to have some minimum scroll distance (e.g., if I ask to scroll by more than 30 points, you always scroll something, even if it's merely a portion of a 100-point hight line). 

	Bill
*start*
00441 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 16:45 PST
From: Masinter.pa
Subject: Lisp: LISPXFNS should be documented NEW/FN
To: LispSupport.pa
cc: Masinter.pa
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dorado

Environment/History, type Documentation. The documentation of LISPX/ and NEW/FN could explain that LISPXFNS is the variable which holds the AList & make LISPXFNS indexed variable.
*start*
00586 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 16:49 PST
From: Masinter.pa
Subject: [Nuyens.pa: Lisp: Masked Icons]
To: LispSupport

Window/Library, Bug, Annoying, Perhaps, attn: Burton


Date:  3 Jan 84 12:50 PST
From: Nuyens.pa
Subject: Lisp: Masked Icons
To: LispSupport.pa
cc: Nuyens.pa
Lisp-System-Date: 19-Dec-83 07:23:10
Machine-Type: Dolphin

Masked Icons (e.g. Lafite browser icons) do not always reflect their background.  If the icon is built on a window which later is closed, the icon retains the image of the closed window. 

Greg

*start*
01728 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 16:52 PST
From: Masinter.pa
Subject: for inclusion on AR, on wanting working DISPLAYSTATS
To: LispSupport

     ----- Forwarded Messages -----

Received: from RUTGERS.ARPA by PARC-MAXC.ARPA;  3 JAN 84 13:53:55 PST
Date: 3 Jan 84 16:52:30 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: [Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>: DISPLAYSTATS bugs]
To: lispsupport.pa


	I get "No such mailbox" on LEVY.PA.

							Jeff
                ---------------

Mail-From: SHULMAN created at  3-Jan-84 16:48:20
Date: 3 Jan 84 16:48:20 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: DISPLAYSTATS bugs
To: levy.pa@PARC-MAXC.ARPA
cc: SHULMAN@RUTGERS.ARPA


Hi,

	A few bugs to report:

		1) You should put (FILESLOAD (SYSLOAD FROM VALUEOF DIRECTORIES)
				   HISTOGRAM MAKEGRAPH)
		   in DISPLAYSTATSCOMS.  There are a couple places you seem
		   to use Xerox file servers directly.

		2) Try (DISPLAYSTATS '(CONS 'A 'B)).
		   It breaks under a LOADFROM of NIL (yes NIL) from
		   {PHYLUM}<LISPCORE>SOURCES>PCALLSTATS.  Reverting to this
		   LOADFROM and RETURNing it proceeds ok until 3.

		3) It tries a LOAD? of {PHYLUM}<LISPUSERS>HISTOGRAM.DCOM and
		   GRAPHER.DCOM.  RETURNing from the LOAD? (after of course
		   loading those files by hand) it proceeds until 4.

		4) It gets to the point where it prints
			"------ Beginning evaluation of form"
		   right after that it breaks with ARG NOT ARRAY
		     {IOFILEINFOBLK}#n,nnnnn under GATHERSTATS.  At this point
		   I could not proceed.

	Let me know when a fixed version in on [MAXC]<XEOS>.  Thanks.


						Jeff
-------
-------

     ----- End of Forwarded Messages -----
*start*
00477 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 17:00 PST
From: Halasz.pa
Subject: TEdit: TEDIT.SETSEL does not reset the SELOBJ field of the curren.t selection.
To: TEditSupport
cc: 
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

If I select an IMAGEOBJ then do a TEDIT.SETSEL to a non-IMAGEOBJ place in the file, the new selection has the SELOBJ field set to the old IMAGEOBJ.


Frank

*start*
00547 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: kaplan.pa
Date: 30-Mar-84 22:52:27 PST
Subject: Re: AR 288: PF searches WHEREIS database unnecessarily
In-reply-to: Your message of 26 Mar 84 12:53:46 PST (Monday)
To: Sannella, Lispsupport
cc: Kaplan

I think that is a feature, not a bug or a waste of time.  There might be several versions of that function on different files that are accessible thru your directoy search list.  PF attempts to show them all to you.

As far as I'm concerned, this AR is closed.

--Ron
*start*
00636 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: kaplan.pa
Date: 30-Mar-84 23:10:40 PST
Subject: Re: Lisp: fixed problem with first pass output from BYTECOMPILER
In-reply-to: masinter's message of 26 Mar 84 18:12 PST
To: masinter
cc: LispSupport, Kaplan

My edit was a perfectly vanilla EDITCALLERS-MAKEFILE.  I have no idea how that could have gotten messed up--unless a previous file in the EDITCALLERS clobbered the FILERDTBL in some way.  Hard to believe, but if there is a clobbering expression for FILERDTBL somewhere, we'd better find it and make sure that it is an INITVARS or the equivalent.

--Ron
*start*
00341 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: kaplan.pa
Date: 30-Mar-84 23:20:04 PST
Subject: Re: Lisp: fn to read connected directory?
In-reply-to: Burton's message of 27 Mar 84 21:22 PST
To: Burton
cc: LispSupport, LispCore^

DIRECTORYNAME(T T) returns it as an atom
DIRECTORYNAME(T) returns it as a string.
*start*
01725 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 MAR 84 23:44 PST
From: JONL.PA
Subject: Re: new transcendental functions
To:   Masinter
cc:   LispSupport, JONL

In response to your message sent  28 Mar 84 00:20 PST

First off, you misplaced a decimal point on the first reported Interlisp-D
result, so that should relieve a lot of anxiety.

Now, the problems you point out have nothing to do, per se, with the "new"
transcendental functions -- the "old" ones are much worse.  In essence, yes, 
32-bit IEEE isn't very good for this test -- (ARCCOS (COS X)) --  which 
is numerically unstable to a very high degree near zero.

I might point out that this standard test is usually done with the angles 
given in radians -- thus you should be comparing the various values of  
            X1 = (ARCCOS (COS .001 T) T)
            X2 = (ARCCOS (COS X1 T) T)
            . . . 
            X(n+1) = (ARCCOS (COS Xn T) T)
If you make this comparison, things don't look quite so drastically bad; by
allowing the .001 to be taken in degrees, you get the effect of starting
out at about 1.7e-5 in radians.  And for a problem *this*  unstable, that
makes all the difference.



Finally, I'm a little surprised that the relative error for (ARCSIN (SIN .001))
is so large (nearly 0.3%) -- ARCSIN isn't that unstable in this range, 
it's ARCCOS that's the loser -- so I did a little mathematical research 
and came up with another approximation that's significantly better near 
the endpoint of the interval [it's also less "consy"!] with a relative 
error back down near 1e-7.  This version, along with a slight improvement 
to SIN for arguments less than PI/4, is in the new AARITH on <LispCOre>Sources>.
*start*
00529 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: MASINTER.PA
Date: 31-Mar-84 12:40:19 PST
Subject: Re: new transcendental functions
In-reply-to: JONL's message of 30 MAR 84 23:44 PST
To: JONL
cc: Masinter, LispSupport

Thank you for your research. I realized after I sent in the message that ARCCOS of COS couldn't be particularly stable for values near 0. 

Kelly Roach has a whole bunch of functions in his MATHFNS package. Can you document HORNERIFY enough to allow him to write his own versions?

*start*
00844 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 MAR 84 23:53 PST
From: JONL.PA
Subject: P5140 -- Fixed a couple weeks ago
To:   LispSupport
cc:   Dering.pasa, 1100Support.pasa


Just a reminder -- I fixed this bug in the sources a couple weeks ago.
It's not a microcode bug, since all three microcodes "punt out" when they
see such a large integer (i.e., MIN.INTEGER).

   - JonL - 



Date: Wed, 11 Jan 84 17:33 PST
Sender: Dering.PASA
Subject: Problem Report P5140  (bug in  IQUOTIENT in Interlisp-D)
To: LispSupport.pa
From: 1100Support


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

Don Cohen at ISIF reports the following:

Even with (OVERFLOW T), (IQUOTIENT MIN.INTEGER -1) = MIN.INTEGER -
I get the feeling that whoever wrote the microcode decided that integer
division could never overflow, and forgot this special case.


*start*
00206 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: kaplan.pa
Date: 31-Mar-84  4:05:10 PST
Subject: Documentation AR:  DIRECTORYNAME should be mentioned near CNDIR
To: Lispsupport

*start*
00445 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 31 Mar 84 05:17 PST
From: desRivieres.pa
Subject: Lisp: COMPILER saves EXPRS
To: LispSupport.pa
cc: desRivieres.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado


I've just noticed that neither the NOSAVE option to COMPILE! nor the STore-and-Forget options on COMPILE are having any effect: the EXPR code is left hanging on the property list.

---Jim     
*start*
01000 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 31 Mar 84 11:29 PST
From: Ahenderson.pa
Subject: Lafite: On Closing a browser.
To: LafiteSupport.pa
cc: Ahenderson.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 13-Mar-84 10:21:31
Machine-Type: Dorado

I just browsed a folder in which there are no messages previously  marked deleted but not expunged (a "clean" message file), displayed one message, and then closed the browser window. I was asked the question about updating the folder. My model of this situation is that I'd get the same result regardless of which answer I give, as nothing has changed in tghis clean file. If this is so, why not omit asking the question at all? General principle: don't ask a question the answer to which will not be used. Reason: 1) It causes the user to try to figure out why the program would want to know, thus making more difficult the formation/support of the user's model. 2) It is unnecessary interaction.

Austin
*start*
00470 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 25 Mar 84 16:01 PST
From: Stansbury.pa
Subject: Lafite: Server message when Lafite off
To: LafiteSupport.pa
cc: Stansbury.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

Got a message "From Semillon: [Abort] server full" when Lafite wasn't even turned on (I had turned it off about an hour before).  Is that supposed to happen?

-- Tayloe.
*start*
00345 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 14:25 PST
From: vanMelle.pa
Subject: Re: Lafite: Server message when Lafite off
In-reply-to: Stansbury.pa's message of 25 Mar 84 16:01 PST
To: Stansbury.pa
cc: LafiteSupport.pa

It could also occur if you run Maintain.  Otherwise, can't think of any reason.
*start*
00335 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 12:25 PST
From: Stansbury.pa
Subject: Re: Lafite: Server message when Lafite off
In-reply-to: vanMelle.pa's message of 26 Mar 84 14:25 PST
To: vanMelle.pa
cc: Stansbury.pa, LafiteSupport.pa

I wasn't running Maintain and I didn't have it loaded.


*start*
00370 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 14:30 PST
From: Masinter.pa
Subject: bytecompiler blues
To: LispCore^
cc: LispFriends^

Edit got dropped and BYTECOMPILER in this mornings <LispCore>Next> sysouts still have call to NOT^H instead of NOT. 

Fixed in next loadup. Workaround for u.d.f. NOT^H is to MOVD(NOT NOT^V^H).


*start*
00439 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 25 Mar 84 15:55 PST
From: Stansbury.pa
Subject: Lafite: Folders not closed.
To: LafiteSupport.pa
cc: Stansbury.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

Mail folders browsed but not changed (ie, don't have to write a new TOC) do not seem to be closed when you quit Lafite (via Quit button).

-- Tayloe.
*start*
00317 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 14:24 PST
From: vanMelle.pa
Subject: Re: Lafite: Folders not closed.
In-reply-to: Stansbury.pa's message of 25 Mar 84 15:55 PST
To: Stansbury.pa
cc: LafiteSupport.pa

I can't replicate this one.  If it happens again, let me know.
*start*
00522 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 16:15 PST
From: Burton.pa
Subject: Lisp: color patch for release
To: LispSupport.pa
cc: Feuerman.pasa
Lisp-System-Date: 27-Mar-84 08:53:34

I put out a new version of llcolor on <lisp>library>llcolor &.dcom to patch a problem that I also fixed in LLDISPLAY.  It keep color from working in the current release candidates.

While there I noticed the file COLORPATCH &.dcom that should be moved to whereever the old release is.

richard

*start*
00474 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 22:29 PST
From: Stansbury.pa
Subject: TEdit: Cursor backwards
To: TEditSupport
cc: Stansbury.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dorado

When you slip out the left side of a TEdit window, the cursor ends up pointing backwards -- it seems that after it has been made to point backwards at a line, it is not being reset.

-- Tayloe.
*start*
00611 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 29 MAR 84 19:55 PST
From: JONL.PA
Subject: Newer SINGLEFILEINDEX
To:   sannella
cc:   ROACH, LispSupport, 1100support.pasa

I'm moving a copy of the SINGLEFILEINDEX on <LispCore>Library>
over to <Lisp>Library> -- Kelly's experience using the Feb 28 version from
<Lisp>Library> prompts me to do this now.  I've been using the one
on <LispCore>Library> all along, and hope that at least some others in
LispCore^.pa also have been doing so; thus it would seem to be relative
bug-free, and certainly much better than the Feb 28 version.

*start*
00568 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 11:29 PST
From: Masinter.pa
Subject: [Willie-Sue.pa: "Send formated message" in Lafite]
To: LAFITESUPPORT

     ----- Forwarded Messages -----

Date: 26 Mar 84 09:33:41 PST
From: Willie-Sue.pa
Subject: "Send formated message" in Lafite
To: Masinter
Cc: Willie-Sue

Since I don't who to ask this question of, who is in charge of Lafite?  It is better to send formatting info as a separate item rather than as part of the message itself.


     ----- End of Forwarded Messages -----
*start*
05404 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 24 Mar 84 13:08 PST
From: BrianSmith.pa
Subject: TEdit: Selection problems
To: TEditSupport
cc: 3LispSupport^, BrianSmith.pa
TEdit-System-Date:  1-Mar-84 13:54:34
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

As well as the strange (and improper) selection behaviour that comes from holding the right mouse button down and moving the mouse around a bunch (which Greg and I talked about yesterday), I have encountered the following:

1. Putting down the control key, in the midst of extending a selection (i.e., while the right button is down), which out to have no visible effect, but which should prepare you to delete the current selection, in fact sometimes changes the selection quite radically, usually changing its boundaries in some striking way.  

2. Playing with the above tends to lead to: multi-piece selections (i.e., more than one continuous region blacked out on the  screen); occurences of "non-numeric arg" errors; and cases where the display doesn't correspond to the underlying text anymore (so that a redisplay changes what is seen substantially -- if you don't do so, you can trash the file).

As well as these bugs, there is currently an incompleteness regarding the interaction between the control and mouse selection.  I take it the algorithm for selection is meant to be the following (I suppose I would argue for it, if it is not the intended one).  I will try to use the terminology used in Tedit.press, but with a simpler notion of selection.  Note that the following doesn't delete with shift-selection, or with cursor positioning; the real algorithm must of course be much more complex than this.

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

a. Let {i1, i2} delimit regions of text, where the i's are the positions of the initial and final character in that selection.  Let k range over selection kinds (we currently support character, word, line, and paragraph types).  Let x always be the position of the character underneath the mouse pointer.  And let D be a flag, 0 or 1, which we will set depending on the state of the CTRL key.

b. Describe the appropriate mouse behaviour in terms of two selections: "temporary" and "current", called TS and CS, respectively. 

c. When the left or middle button is depressed, let TS be {i1, i2, k, p}, where the i's delimit the region of the character (or word or line or paragraph) pointed at, k is the appropriate kind, and p (point) is right or left, depending on whether x is nearer the right or left end of the object type (the "cursor" is presumaby moved to the p end of that object).  As the mouse moves around, TS is adjusted accordingly (underlining if D = 0, reverse video if D = 1 [see (h)]).  

d. When the left or middle button is released, CS is made to be TS; plus see (i).

e. When the right button is depressed, TS is defined as follows:   If CS = {c1, c2, k, p}, let z = (c1 + c2)/2. If k = character, define TS = {x, c2, k, left} if k < z, and {c1, x, k, right} if k > z.  If k is something else, then substitute the right hand end of the object under x for x if x > z, and the left hand end if x < z.

f. As the mouse moves around with the right button depressed, adjust TS as appropriate: if p is left, and if x grows > c2, then let TS = {c2', x, k, right}, where c2' is the left end of the object of type k whose right end was c2; similarly, if p is right, and if x becomes < c1, then let TS = {x, c1', k, left}, where c1' is the right end of the object of type k whose left end was c1.

g. When the right button is released, define CS to be TS [just like (d)]; plus see (i).

h. If, at any point, CTRL is depressed when a button is depressed (independent of which was depressed first), set D = 1.  If CTRL is released when a button is depressed, set D = 0.

i. When buttons are released, if D = 1, then set up a process to watch the control key, and when it is released, delete CS.

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

I think this is what one would naturally expect.  Note that (f) has the consequence that in one "push" of the right button (no matter how much it is then moved around), you can modify the current selection considerably, but must always retain a minimum of one object from what the current selection before the button was depressed.  To be more drastic you have to let go of the right button and use it again.  This accords with standard practice on the first use of the right button; seems it might as well always apply.

So.  The current behaviour is radically different from that spec'ed in (f), as discussed with Greg yesterday.   It is even different if you select a word, push the right button down without moving the mouse, move one word to the right and back again.  Once you cross line boundaries, it gets quite spectacular.

Also, just pushing down control, as noted above, changes the TS (and then the CS).

Also, if you want to delete a region that is already selected (a CS), you currently have to use the right button first, and then push control (and then let up on the right button, and then let up on control).  I.e., if you push down control before pushing down the right button, nothing happens at all, which is an unnecessary restriction.  Under (h), the order of the first two of these shouldn't matter.  

Hope this is helpful!  If you would argue for a different algorithm I would be interested in discussing it.

Brian

*start*
00931 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 10:43 PST
From: DMRussell.pa
Subject: TEdit: TEDIT Documentation -- TABS
To: TEditSupport
cc: DMRussell.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

The TEDIT documentation re TABS is a bit confusing.  

1. There should be an example.
2. What are the units for TABS? 
    Are the tab positions given in inches or points? 
	a) If inches, why don't you say so!
	b) If points, then what units does the marginbar use?
3. You say "This is a CONS pair" -- do you mean "dotted pair"?
	Since the second elt of the TABS list is always another 
	list, why don't you just say "This is a list, the CAR is 
	a ....".  

By the way, how do "point" map onto "screen distances"??  You should tell me what the coefficient is!  (e.g. 1 point = 2.3 pixels = .1 inch....  this is just a guess.)  

-- DMR -- 
*start*
00459 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 05:17 PST
From: Wallace.pa
Subject: Lafite: Host error Messages
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

The first time I saw "From Semillon: [Abort] Server full," it worried me.  Perhaps error messages should only be printed when the mail is undeliverable or when some wizard-mode flg is set?
*start*
00672 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 26 Mar 84 09:54 PST
From: vanMelle.pa
Subject: Re: Lafite: Host error Messages
In-reply-to: Wallace.pa's message of 26 Mar 84 05:17 PST
To: Wallace.pa
cc: LafiteSupport.pa

Indeed.  The message you saw came as a result of a change to the BSP protocol handler to make it more informative about why a connection attempt failed.  This was generally a good thing in the case of Chat and Ftp.  Unfortunately, in Lafite's case, the program itself is quite willing to recover from a connection failure, so it would rather suppress the message, at least until it gives up.  Is on my list to fix.

	Bill
*start*
00462 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 25 Mar 84 22:24 PST
From: Stansbury.pa
Subject: TEdit: Not purging {dsk}tedit.cache
To: TEditSupport
cc: Stansbury.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

Although I have long since quit TEdit, the file {dsk}tedit.cache still exists and is still open.  It contains a complete copy of the last file I was editing.

-- Tayloe.
*start*
00592 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 25 MAR 84 18:44:57 PST
Return-path: <@SUMEX-AIM.ARPA:SHULMAN@RUTGERS.ARPA>
Redistributed: Xerox1100UsersGroup^.PA
Received: from RUTGERS.ARPA by SUMEX-AIM.ARPA with TCP; Sun 25 Mar 84 18:06:21-PST
Date: 25 Mar 84 21:07:16 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: QMS Laser printer
To: 1100Users@SUMEX-AIM.ARPA


	We at Rutgers are about to get one of these.  Anyone out there
have the printermode drivers or am I about to write them?

							Jeff
-------
*start*
00245 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 24 MAR 84 16:24 PST
From: MASINTER.PA
Subject: reminder, send mail to LispSupport when you edit lisp source files
To:   kaplan
cc:   lispsupport

Can we automate this?
*start*
00779 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Fri, 23 Mar 84 16:08 PST
From: desRivieres.PA
Subject: \VMEM.INHIBIT.WRITE feature
In-reference-to: vanMelle.pa's message of 6 Mar 84 12:23 PST
To: LispSupport.pa
cc: desRivieres

The \VMEM.INHIBIT.WRITE feature would be *most* useful in the context of the CSLI course that begins early in April because it would allow us to use the 3-LISP Lisp.virtualmem on the Dlion's local disk for more than one student-session.  Without this mechanism, the students will have to load the sysout from a file server more frequently (note: 3-LISP will be made to clean up after a student; hence a sysout will have some degree of re-useablity, depending on how badly the memory gets fragmented, MTBF, etc.)

---Jim  
*start*
00592 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 23 MAR 84 05:59:20 PST
Redistributed: Xerox1100UsersGroup^.PA
Date: Thu, 22 Mar 84 16:05:37 PST
From: Marty Kent <POLSON@SUMEX-AIM.ARPA>
Subject: vax under vms as dandelion file server
To: 1100users@SUMEX-AIM.ARPA

We are about to get our first dandelion, with two more on the horizon, and
are thinking in terms of using our vax 780 running vms as file server. I would
greatly appreciate hearing from anybody who's done this re costs, unexpected
bugs, advice etc.
-------
*start*
01004 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 23 MAR 84 05:43:44 PST
Return-path: <@SUMEX-AIM.ARPA:gvax.jqj@Cornell>
Redistributed: Xerox1100UsersGroup^.PA
Received: from cu-arpa.CORNELL.ARPA (CORNELL.ARPA) by SUMEX-AIM.ARPA with TCP; Fri 23 Mar 84 05:15:58-PST
Received: from gvax.CORNELL.ARPA (gvax.ARPA) by cu-arpa.CORNELL.ARPA (4.12/3.14)
	id AA05116; Fri, 23 Mar 84 08:15:29 est
Date: Fri, 23 Mar 84 08:15:58 est
From: gvax.jqj@Cornell.ARPA (John Q. Johnson)
Message-Id: <8403231315.AA24084@gvax.CORNELL.ARPA>
Received: by gvax.CORNELL.ARPA (4.12/3.14)
	id AA24084; Fri, 23 Mar 84 08:15:58 est
To: 1100users@SUMEX-AIM.ARPA, POLSON@SUMEX-AIM.ARPA
Subject: Re:  vax under vms as dandelion file server

Contact Tim Eldredge <eldre@score or twe@su-ai>.  Teknowledge, Inc. runs
about 15 Dandelions using a VAX/VMS system as file server.  The software
from Xerox is currently very bad, but they have promised better versions
soon.
*start*
01123 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 17:21:19 PST (Thursday)
From: Masinter.PA
Subject: please make floppies
To: LispSupport
cc: vanMelle, spoor.uiuc@Rand-relay

Hi --

Dave Spoor is doing a project which involves measuring some of the parameters of paging and GC performance of a Lisp system. I'd like to help.

What he needs are the sources (from Lisp>Sources>) of LLFAULT and LLGC, and the sources (from Lisp>Library) of COREHAX and GCHAX, and a copy of the "implementors guide" in whatever state it is in currently. 

We will have to answer questions about the way in which the virtual memory system is organized via electronic mail. These q & a will form an additional part of the implementors guide.
 

In exchange, Dave promises to send us a copy of any report or documentation he generates (or, if just an oral presentation, a written summary.) In addition, we will recieve a copy of the syllabus of a course being taught at U of Ill. on Lisp Machines.

One floppy containing 4 files, sent to:

David Spoor
Coordinated Science Lab
1101 W. Springfield, Ill. 61801


*start*
01767 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 16:42:21 PST (Thursday)
From: masinter.PA
Subject: bugs with "Carol demo"
To: 1100Support
cc: Hausladen, LispSupport


Please reply about {DSK} having been fixed & see if you can get more details on 9004, 9005 and 9915 crashes from "Kolb.Siemens".

Mary, our near-term plans are to remove [Phylex:] from service in the near term. Also [phylex:] does not contain the Fugue.6=Carol.1 release, as far as I know.

----------------------------------------------------------------
From: kolb.siemens
Date: 22-Mar-84 16:47:22
Subject: Access and Sources
To: Hausladen.pa
cc: schwarcz, kolb, sheil.pa, masinter.pa

Hello, Mary, This is Thomas Schwarcz, using Dieter Kolbs GV account. 
The weather in Munich is nice, but I hear things
are really warm there.
Would you please give me read access to
[Phylex:]
<Lisp>
<LispSources>
<LispUsers> ?
My id: Schwarcz:OSBU BAYSHORE:Xerox.

Thank you for trying to get the sources across the wire.
As it turns out, it was probably a good thing. We have
decided to wait until the "official"carol release and then take
the sources. Things are being changed to often now.
There are some, selected sources/files which are of interest,
of course, and we could get those if I had access to an NS 
file server that has the same stuff as [Phylum].

Right now we are using carol demo sysout and have found some "bugs":

files stored on {DSK} dissappear after a boot 0. (NOT GOOD)

many crashes during interlisp session with panel disp 9004, 9005 and 9915, reboot necessary.


You can reach me by sending mail
to Kolb.Siemens. It is a good idea to
copy Fischer.Siemens, too.

Thanks,

Thomas


----------------------------------------------------------------
*start*
00594 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 17:16 PST
From: Martin.pasa
Subject: Re: bugs with "Carol demo"
In-reply-to: masinter.PA's message of 22 Mar 84 16:42:21 PST (Thursday)
To: 1100Support.PA
cc: masinter.PA, Hausladen.PA, LispSupport.PA

With repect to Larry's message, I have run the March 1 demo a couple of times with no problems.  

I did have fatal problems though when I had used COPYFILE to copy the sysout directly to floppies instead of building the floppies in Tajo.  Could Thomas Schwarcz have built his version the same way?

Rick
*start*
00356 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Thu, 22 Mar 84 20:48 PST
From: Raim.pasa
Subject: Re: bugs with "Carol demo"
In-reply-to: "Martin's message of 22 Mar 84 17:16 PST"
To: Martin
cc: 1100Support.PA, masinter.PA, Hausladen.PA, LispSupport.PA

(Edittree parse) creates a window too small to give much of a demo.

m.

*start*
00430 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: masinter.pa
Date: 22-Mar-84 22:12:16 PST
Subject: Re: bugs with "Carol demo"
In-reply-to: Martin.pasa's message of 22 Mar 84 17:16 PST
To: Martin.pasa
cc: 1100Support, masinter, Hausladen, LispSupport

sorry, the problem he reported is a known problem that was fixed between the distribution to Siemens and the testing of the current release candidate.
*start*
00375 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: masinter.pa
Date: 22-Mar-84 23:05:50 PST
Subject: Re: bugs with "Carol demo"
In-reply-to: masinter's message of 22-Mar-84 22:12:16 PST
To: masinter
cc: Martin.pasa, 1100Support, Hausladen, LispSupport

I wasn't clear: the problem about {DSK} files going away over LOGOUT was the one that got fixed.*start*
00712 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 11:55 PST
From: Masinter.pa
Subject: Re: bugs with "Carol demo"
In-reply-to: Raim.pasa's message of Thu, 22 Mar 84 20:48 PST
To: Raim.pasa
cc: Martin.pasa, 1100Support.PA, masinter.PA, Hausladen.PA, LispSupport.PA

Marty, the demo script changed about 6 months ago. PARSE is NIL in the initial demo; get into Lafite, and shift-select the (SETQ PARSE (PARSE MY ....)) and then call (EDITTREE PARSE) from the text of the last message.

Tayloe Stansbury changed this.

If you don't like it, submit an AR, system: Graphics, subsystem: Demo, describing how you want it.

E.g., Subject: "Want DEMO to have PARSE preset to value"


*start*
00417 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 02:25 PST
From: desRivieres.pa
Subject: TEdit: Horizontal scrolling
To: TEditSupport
cc: desRivieres.pa, Wallace.pa
TEdit-System-Date:  1-Mar-84 13:54:34
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

Why does Tedit normally support horizontal scrolling on its windows when it wraps lines to fit the screen?

---Jim
 
*start*
00479 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 04:05 PST
From: Wallace.pa
Subject: Lisp: READ from a window
To: LispSupport.pa
cc: Wallace.pa
Lisp-System-Date: 14-Mar-84 10:16:58
Machine-Type: Dorado

I can't give a window as an argument to READ; it correctly coerces the window into a stream, but then complains "File not open."  Am I confused somehow?

david

(for instance, put the cursor on your exec window and type (READ (WHICHW))


*start*
00664 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 MAR 84 09:47 PST
From: MASINTER.PA
Subject: ars and their meaning
To:   LispSupport

The TITLE of the AR should describe what the problem is. If the problem is internal system docuemntation, then the AR should be "Need documentation on Loadup process", and the Description
should be headlined

The AR process needs documenting. The following message has some information about the loadup process that should get extracted.


My point is that the AR system is a PUBLIC forum, not your personal reminder system. SOMEBODY ELSE reading the AR should be able to tell what the problem is.

*start*
01055 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 15:41 PST
From: vanMelle.pa
Subject: Partial postmortem of Teknowledge MP 9016
To: 1100Support.pasa, LispSupport
cc: vanMelle.pa

I talked Bill White thru some teleraiding.  They had gotten a 9016, from which they tried ^B from the TeleRaid server, only to get a 9305.  The latter he remotely TeleRaided, from which it was apparent the stack was trashed.  The top frame extension was odd-aligned.

We laboriously tried parsing the stack farther back and found it was deep in interpreted code, in \EVALFORM in \EVAL in PROG1.  The \EVALFORM (and \EVAL) were of a (LOADB00nn --), part of an advised LOAD.  Everything looked kosher up until the \EVALFORM.  The frame for \EVALFORM was the last intelligible thing before the odd-aligned frame, and itself was slightly garbaged: the first word of its BF was trashed with 35563, a plausible nearby stack address, 4 less than that of the misaligned FX.  The PC of the \EVALFORM indicated it was executing the APPLYFN opcode.
*start*
00557 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 13:15 EST
From: Denber.wbst
Subject: Lafite: GETMAIL
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dolphin

Doing a get mail from Barbera (over a very slow and obviously overloaded connection) eventually gave a 

BSP error: BAD.STATE.FOR.BOUT
{STREAM}#10,1300

(ERROR broken)

from BSPBOUT from MS.RETRIEVEOPERATION from GV.NEXTMESSAGE from RETRIEVEMESSAGES from GETNEWMAIL1 from GETNEWMAIL.

			- Michel
*start*
01084 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Fri, 16 Mar 84 17:43 PST
From: KIEWIET.PASA
Subject: LAFITE.DCOM 28-Feb-84
To: LafiteSupport.pa
cc: 1100Support, KIEWIET

I cannot send this report to you using Lafite for the following reasons:

System:  Dolphin XMB -  sysout date 13-Mar-84
Loaded:  {PHYLUM}<LispCore>Library>Lafite.dcom

Started (LAFITE 'ON '{DSK}15MARCH.MAIL).  Returned ON, Browsed the mail folder successfuly, then broke:  \Checkname-Undefined function.  The Stack was:  Errorset
	Break1
	\Interpreter
	GV.Authenticatename
	Mailservers
	Pollnewmail
	Errorset
	Lafitemailwatch
	Errorset
	T
While checking BT values, accidentally released on Revert.  This froze mouse and keyboard, and I was unable to ^D.

Booted system and re-initialized as before.  This time, (LAFITE 'ON '{DSK}15MARCH.MAIL) broke immediately:
	Spawn Mouse - Undefined function
	%[Spawn% Mouse%]
Stack was:
	Errorset
	Break
	\Interpreter
	Attachedwindowtotopfn
	Douserfns
	Totopw
	BKbitblt
	Dispfill
	Shadeitem
	LA.resetshade
	Errorset
	Errorset
	T
What's going on?

*start*
00352 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 21:45 PST
From: vanMelle.pa
Subject: Re: LAFITE.DCOM 28-Feb-84
In-reply-to: KIEWIET.PASA's message of Fri, 16 Mar 84 17:43 PST
To: KIEWIET.PASA
cc: LafiteSupport.pa, 1100Support.PASA

Sounds like complete randomness.  Have you checked for hardware problems?

	Bill
*start*
00885 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Mon, 19 Mar 84 09:41 PST
From: KIEWIET.PASA
Subject: Re: LAFITE.DCOM 28-Feb-84
In-reply-to: "vanMelle.pa's message of 18 Mar 84 21:45 PST"
To: vanMelle.pa
cc: KIEWIET, LafiteSupport.pa, 1100Support

Earlier the same day, the following happened:

Just after (VIDEOCOLOR T) and (VIDEOCOLOR NIL) -- just showing someone what it did to display --  fell into Raid, with a hard disk error in vmem.   Cnt'l C back and got Stack Overflow break.  Did (HARDRESET), got same message. 

Raid message was:  Big refcnt ptr not in table
{NDB:1,147644} -> {1,137700}

Rick Martin tried to Swat this, but Swat was not on my partition, so I booted out, Scavenged the disk and re-installed.

So in answer to your question, yes there were some hardware problems, but the Lafite problem was just after the Scavenge.  

Lorraine

*start*
01054 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 16:39 PST
From: Kiewiet.pasa
Subject: Re: LAFITE.DCOM 28-Feb-84
To: vanMelle.pa
cc: Kiewiet.pasa, LafiteSupport.pa

Bill,

This shouldn't have anything to do with it, should it?

(Can't test it now.  After today's Scavenge (same bad pages) after today's episode with %spawn mouse% I loaded a full sysout from Rosebowl from 25Feb84 so I could get some work done!)

Lorraine

P.S.  Thanks for the response to \Processes question.  I'm sure the customer will be glad to know that we haven't forgotten about his question. He loves (his choice of verbs, not mine) Interlisp-D system.


     ----- Forwarded Messages -----

Date: 19 Mar 84 16:21 PST
From: Barrera.pasa
Subject: Re: LAFITE.DCOM 28-Feb-84
In-reply-to: KIEWIET.PASA's message of Fri, 16 Mar 84 17:43 PST
To: KIEWIET.PASA
cc: BARRERA

Lorraine,

I don't think LAFITE likes file names which begin with a number.  I ran into problems when I named one thus.

Stephanie

     ----- End of Forwarded Messages -----
*start*
00450 00071 UUm
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 18:39 PST
From: Masinter.pa
Subject: AR#203
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dandelion

Should be interpreter, not compiler (different category.)

Impact is probably annoying.

Workaround is to compile the function.
Priority hopefully
difficulty easy

I thought you were going to fill in Assigned-to and Attn: to be the same.
*start*
00558 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 01:27 PST
From: Wallace.pa
Subject: Lisp: Inverse of CHARCODE?
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

Is there an inverse to CHARCODE that returns the symbolic name of unprintable characters?

E.g. now:

(CHARACTER (CHARCODE A)) ==> A
(CHARACTER (CHARCODE ^A)) ==> 
(CHARACTER (CHARCODE DEL)) ==> <blotch>

As opposed to:

(CHARACTER (CHARCODE A)) ==> A
(CHARACTER (CHARCODE ^A)) ==> ^A
(CHARACTER (CHARCODE DEL)) ==> DEL

david



*start*
01114 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 15:43 PST
From: Sannella.pa
Subject: Canonical Installation Utilities Floppy 
To: LispFriends^.pa
cc: Sannella.pa

In order to install Interlisp-D on a stand-alone 1108 not connected to a network, it is necessary to use an Installation Utility floppy.  There have been a number of these floppies floating around, containing totally random versions of the appropriate tools.  This message announces the existance of a canonical Installation Utilities floppy.  The floppy is stored as a floppy image file on phylum, from which it can be copied on to a new floppy.

To create a copy of the Installation Utility, start lisp running on an 1108, put a new floppy in the drive, and type

(FLOPPY.FROM.FILE '{Phylum}<Lisp>Current>InstallationUtility.floppy)

This will format the floppy (ERASING the former contents - beware) and transfer the floppy image to the floppy.  This takes about 15 minutes.

To make a copy of the "Diagnostics" floppy, follow the same procedure, using the file {Phylum}<Lisp>Current>DiagnosticsFiles.floppy

*start*
00355 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 16:34 PST
From: halvorsen.pa
Subject: TEdit: Call to RAID due to UFN under \PUSH.TEXT under \TEDITINSERT.UPDATESCREEN
To: TEditSupport
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dandelion

Short unformatted message
		Kris
*start*
00485 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from BBNG.ARPA by PARC-MAXC.ARPA; 20 MAR 84 07:26:19 PST
Date: Tue, 20 Mar 84 10:26:48 EST
From: WWOODS@BBNG.ARPA
Subject: BUG IN DISPLAY EDITOR
To: 1100SUPPORT.PASA
cc: WWOODS@BBNG.ARPA, LISPSUPPORT.PA

When you insert a comment in a function using the display editor
(EDITF), the font height difference for the smaller font of the
comment screws up the display (and reprint doesn't fix it).



-------
*start*
02051 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 15:32 PST
From: Stansbury.pa
Subject: Release process: Beta-test sites
To: Sannella, Lispsupport

As you know, we currently have two Parc beta test sites: Intelligenetics and Syntelligence.  We use them to test new software whenever we want to spread out our test-base (and especially when it is a part of the system that we at Parc seldom exercise).  Pasadena has its own test sites in addition.  We set up separate test sites so that we could have a faster loop: find bug, report, fix, and give out new software as soon as the same day.  

We should use these sites to test out the system as soon as it has been moved to LispNew -- particularly since people here will migrate toward using LispCore as soon as they have an excuse so to do.  We should also use them to test out any part of the system which will be released as a patch between releases: so when the dlionfs gets done, we should give it to them.  And there are other things you will want to use them for.

As for this release, it might well be too late to use our Parc beta-test sites, since Marty has already sent out the release to some customers, perhaps including our test sites, and will send it out to the rest very soon.  But you should check with him nonetheless, and get some floppies to IG and Syntelligence ASAP if that is appropriate.

The contacts are:

Syntelligence
Magnus (I can't pronounce his last name)
Telephone: 325-9339
Electronic address: Magnus@SRI-AI
Physical address: 800 Oak Grove, Menlo Park (North on El Camino, 2nd left after Ravenswood, down a few blocks on right)

Intelligenetics
Marty Yonke
Telephone: 328-4870
Address: 707 Laurel (!), Menlo Park (North on El Camino, right on Ravenswood, right on Laurel, 1 block)

Once you have made floppies and called these places to warn them someone is coming, I am sure you could find plenty of suckers to carry the floppies to them (me for one).

Please send an ack so I can delete the addresses from my wall.

-- Tayloe.


*start*
00817 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 20 MAR 84 13:16:15 PST
Return-path: <@SUMEX-AIM.ARPA:JS1E@CMU-CS-A>
Redistributed: Xerox1100UsersGroup^.PA
Received: from CMU-CS-A by SUMEX-AIM.ARPA with TCP; Tue 20 Mar 84 12:46:43-PST
Date: 20 Mar 84 15:05 EST (Tuesday)
From: Jeff.Shrager@CMU-CS-A.ARPA
To: 1100users@SUMEX-AIM.ARPA
Subject: PRINTBITMAP

To: 1100support@PARC-MAXC
Cc: 1100users@SUMEX-AIM
Subject: PRINTBITMAP

Can you tell me what the meaning of the output of PRINTBITMAP is?
Is there some Dover font that will print this directly?  The Alto
MARKUP program has a way of sending arbitrary Alto-screen density
pix to the Dover.  How does that happen and can we emulate that with
our Dandelions?  (Running Fugue.4 on 1108s)

Thanks
*start*
00933 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 20 MAR 84 14:23:39 PST
Redistributed: Xerox1100UsersGroup^.PA
Date: Tue, 20 Mar 84 13:49:35 PST
From: Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>
Subject: Re: PRINTBITMAP
To: Jeff.Shrager@CMU-CS-A.ARPA
cc: 1100users@SUMEX-AIM.ARPA
In-Reply-To: Message from "Jeff.Shrager@CMU-CS-A" of Tue 20 Mar 84 15:05:00-PST

	PRINTBITMAP is the function that the BITMAPS file package
command uses to save a bitmap on a file during a MAKEFILE.  Only the
low 4 bits of each character in the strings are significant.
	To print a bitmap on a dover, you want to use HARDCOPYW, which will
take either a bitmap or a window as argument.  Be sure that 
DEFAULTPRINTINGHOST and/or DEFAULTPRESSPRINTER are set to the hostname of
your dover, and that that hostname has a property PRINTERTYPE which is set
to PRESS.
--Christopher
-------
*start*
01448 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 21 MAR 84 07:58:57 PST
Return-path: <@SUMEX-AIM.ARPA:VANBUER@USC-ECL.ARPA>
Redistributed: Xerox1100UsersGroup^.PA
Received: from USC-ECL.ARPA by SUMEX-AIM.ARPA with TCP; Wed 21 Mar 84 07:24:54-PST
Date: 21 Mar 84 07:23 PST
From: VANBUER at 
Subject: Re: PRINTBITMAP
To: Jeff.Shrager@CMU-CS-A.ARPA, 1100users@SUMEX-AIM.ARPA
cc:   VANBUER at 

In response to the message sent  20 Mar 84 1505 EST (Tuesday) from Jeff.Shrager@CMU-CS-A

As Eric pointed out, PRINTBITMAP is unrelated to similacra of the screen.

There are four ways to do this:
1) press printer as described by Eric
2) Interpress printer (e.g. 8044), almost the same as Eric described, but
  printer name will have a colon in it, and type is INTERPRESS
3) With the package in PRINTER.DCOM, and a C.ITOH 8510 dot matrix printer
   (actually, this requires slight hacking for a Dandelion; it's currently
   set up for a parallel printer thru the parallel port on a Dolphin).
4) If you have a VAX running 4.1 and a Versatec, I have a set of routines
   for Dxx and Vax which print them  [To old users of this code:  I have
   changed the Dxx end of the interface to be compatible with the printer
   conventions in Fugue]

	Darrel J. Van Buer, PhD
	System Development Corp
p.s.  If there is any interest in #4, I will move the latest code to
{parc}<1100users>
-------
*start*
00797 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 21 MAR 84 13:01:53 PST
Return-path: <@SUMEX-AIM.ARPA:guyton@rand-unix>
Redistributed: Xerox1100UsersGroup^.PA
Received: from rand-unix by SUMEX-AIM.ARPA with TCP; Wed 21 Mar 84 11:47:56-PST
Date: Wed, 21 Mar 84 11:40 PST
To: 1100users@SUMEX-AIM.ARPA
cc: randvax!guyton@Rand-Unix.ARPA (James_Guyton)
Subject: one more way to print a bitmap
From: guyton@Rand-Unix.ARPA (James_Guyton)

If you have an Imagen printer (with the Impress language
option) and run unix, we can supply a simple unix program
and lisp function that will print a bitmap on the imagen.

It's a bit of a hack, and a two-step process, but it
seems to work ok.  Contact me if you'd like a copy.

-- Jim Guyton
*start*
00943 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 12:07 PST
From: Stansbury.pa
Subject: Lafite: Trying to GetMail too soon can break Lafite
To: LafiteSupport.pa
cc: Lispsupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 14-Mar-84 10:16:58
Machine-Type: Dolphin

Bugging GetMail after restarting a used memory image before it returns from logout can (with relatively high probability) cause Lafite to break with "arg not event: NIL".  Stack looks like
await.event (this is what broke with the NIL arg)
exchangepups (this is where the first event=NIL shows up)
errorset
infilep
errorset
infilep
errorset
checklafitemailfolders
dolafitebrowsercommand
doselecteditem
menubuttonfn
errorset
window.mouse.handler

In addition, the exec's logout seems to be held up over a monitor lock with stack
obtain.monitorlock
errorset
checklafitemailfolders
lafite.aroundexit
\userevent
logout

-- Tayloe.

*start*
01105 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 21 MAR 84 16:11:30 PST
Return-path: <@SUMEX-AIM.ARPA:mbr@nprdc>
Redistributed: Xerox1100UsersGroup^.PA
Received: from nprdc by SUMEX-AIM.ARPA with TCP; Wed 21 Mar 84 15:34:29-PST
Date: 21 Mar 84 15:34:02 PST
From: Mark Rosenstein <mbr@nprdc.ARPA>
Reply-To: mbr@nprdc.ARPA
To: 1100users@sumex-aim.ARPA
Subject: storage full, and how to get windows and deditmap reclaimed
Cc: mbr@nprdc.ARPA

On our 1108 I got the message Arrays full and then tried to
cleanup to floppy, but immediately got storage full.

Is there a way to reclaim enough space to write work out?
I tried (gainspace) answering yes to everything, but filepkg
info and definitions on property lists, but I still got
the storage full, part way into the cleanup. 

Are there other tricks to get enough room? Is there possibly some
sneaky way to decrease the reference counts to a bunch of big items
(say windows) (or deditmaps whatever they are (which took 120 pages))
so they will be reclaimed?

Thanks.
              Mark
*start*
00365 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Fri, 30 Mar 84 17:24 PST
Sender: Raim.pasa
Subject:  Interlisp-D on [maxc]<xeos>  
To: Arpa1100Users^.pasa
From: 1100Support
cc: 1100Support
Reply-To: 1100Support

The <xeos> directory on MAXC will be closed until further notice during which time new Interlisp-D software will be loaded.
*start*
00642 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 11:26 PST
Sender: Sannella.pa
From: LispSupport.pa
Subject: New SYSOUTs on <Lisp>Current>
To: LispFriends^.pa

This message announces a new, slightly-changed Interlisp-D sysout set, corresponding to the release that is being sent to customers.

The following files have been updated
{Phylum}<Lisp>Current>LISP.SYSOUT
{Phylum}<Lisp>Current>FULL.SYSOUT

A corresponding SMALL.SYSOUT and DEMO.SYSOUT will be created shortly.  The new sysouts have the improvement that if a core device {DSK} is created on a Dandelion, it will not disappear across logouts.


*start*
00853 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Mar 84 15:28 PST
From: Sybalsky.pa
Subject: TEdit: Upcoming changes to TEdit PROP arg
To: TEditSupport.pa, VanMelle, Kaplan
cc: Sybalsky.pa
TEdit-System-Date: 27-Mar-84 13:42:53
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dorado

This is advance warning that I'm going to remove those odious single-atom PROP list entries:

	READONLY
	LEAVETTY
	CACHE

As of the next release, they'll be keys with values of NIL or non-NIL (with NIL meaning don't have that property).  In addition, there will be a new global variable, TEDIT.DEFAULT.PROPS, which can contain a default set of properties.  TEdit will hook its explicit PROPS arg on the front of that, so you can override the defaults at will.

When and as you change over, your code will still work with the old TEdit.