*start*
01449 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 31 Mar 84 12:44 PST
From: TBigham.es
Subject: Lisp: Three Bugs and a suggestion
To: LispSupport.pa
cc: TBigham.es
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dolphin

I have three problems in Carol1 and one suggestion.

1) Interrupt characters such as Control D  don't seem to have the power they used to have.  I beleive I used to be able to stop most functions with control D, but now it is just ignored.  Moreover, after a function has completed there are several ^D's printed in the toplevel window.  After I initiate (INTERRUPTCHAR T), this problem seems to disppear.

2) When I break on a function, backtrace, and dedit a funtion on the BT list, the value of the variables within that function return nobind when evaluated.  I haven't any idea how to work around this.

3) When printing to a product printer I haven't been able to get  HARDCOPYW's rotation to make any difference.  The printout is always landscape.  Also I haven't seen a hook to change or suppress the title message "Window Screen Image".  

Suggestion:

Could we have the break window push to the top after editing a function throught the backtrace menu ?  Sometimes I've burried the break window with my edit window (I have DEditLinger T) and have to close or bury the edit window to get back to the break window.  Having it return to the top will also call attention to it.

Tim Bigham


*start*
00518 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 31 Mar 84 13:40 PST
From: Wallace.pa
Subject: Lisp: Manditory file versions
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

I would like to have a recognition mode (i.e. EXACT) that would allow me to specify a destination filename without version numbers.  Currently I can (and do) get screwed when hacking files on the alto or floppy filesystems.

This is also true for file operations such as RENAME and COPY
*start*
00738 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 31 Mar 84 13:57 PST
From: Wallace.pa
Subject: Lisp: Sysout to {floppy}
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

Two problems:

1> If your disk is write-protected you crash horribly, with nothing in the backtrace to even indicate what the problem is.  It should just print "Diskette is write-protected" and wait fr you to replace the floppy.

2> You can't name the sysout anything but "Lisp.sysout."  We have our own installation tool that expects a different filename (deliberately to avoid confusion).  It's really hard to create these disks because we have to use MESA (or Kelly Roach) to rename the sysout files.

david

*start*
01463 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 31 MAR 84 14:08 PST
From: MASINTER.PA
Subject: FIXSPELL.UPPERCASE.QUIET control for quiet uppercasification in DWIM
To:   LispSupport
cc:   LispCore^

Numerous people have complained that the 'feature' of DWIM turning lower case atoms into upper-case ones without warning or notification was causing a great deal of confusion.

However, a few users who routinely use UpperAndLowerCase identifiers like the fact that they don't have to use the shiftlock when typing CAR or CDR or EF -- that DWIM will 'correct' the lower case versions and they don't need to be informed about it.

Rather than resolving this dilema, I've taken the Interlisp-way: there is a FLG: FIXSPELL.UPPERCASE.QUIET, which enables the 'quiet' conversion. The initial value for FIXSPELL.UPPERCASE.QUIET is NIL, which turns OFF the feature (making the system work differently than it does now.)

The edit was quite trivial; there was a special clause in FIXSPELL which implemented this feature, and I just wrapped a (AND FIXSPELL.UPPERCASE.QUIET --) around it.

I'm uncertain whether to document the variable, or just to announce that the system behavior changed.

I'm working from home and don't trust the maxc version of the compiler any more ; so I've merely stored the updated source of SPELL on <LispCore>Sources> without the corresponding SPELL.DCOM. If noone else gets to it, I will compile it upon my return.

*start*
00380 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 31 Mar 84 14:12 PST
From: Burton.pa
Subject: TEdit: OPENTEXTSTREAM changes file ptrs
To: TEditSupport
cc: Burton.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 29-Mar-84 17:34:40

in the files that are contained in the pieces of TEXT passed in.  I don't think this should happen.


richard

*start*
00596 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 31 Mar 84 15:18 PST
From: Roach.pa
Subject: TEdit: Cursor changing bug
To: LISPSUPPORT.PA
cc: Roach.pa

     Impact: Annoying
     If you move the cursor slowly through the left window boundary of a Tedit window, the cursor changes from direction from northwest to northeast (north = top of screen).  The cursor continues to point northeast even though you are over the background or you may switch to another process.  I wouldn't be terribly bothered if the cursor direction changing
were just eliminated.
						Kelly
*start*
00420 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 31 Mar 84 17:53 PST
From: Stansbury.pa
Subject: Lisp: Hardcopyw to file will not empress
To: LispSupport.pa
cc: Stansbury.pa, Hausladen
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dorado

(HARDCOPYW (WHICHW) 'FOO) followed by (EMPRESS 'FOO) breaks saying that foo is a press file with a non-integral number of pages.  Yuk.

-- Tayloe.

*start*
00648 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 31 Mar 84 18:13 PST
From: Moran.pa
Subject: Lafite: CAN'T PARSE MAIL FILE
To: LafiteSupport.pa
cc: Moran.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dorado

...when running lafite from partition 1 with my mail file on partition 2.  On part 1 I'm running from a sysout created by Halasz.  If I forget to set LAFITEDEFAULTHOST&DIR, then it reads his mail file fine (from phylum), but when I set it to {DSK2}, it bombs.  When on partition 2, however, I'm able to read and parse the mail file fine with both laurel and lisp .
*start*
00411 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  1 Apr 84 22:44 PST
From: vanMelle.pa
Subject: Re: Lafite: CAN'T PARSE MAIL FILE
In-reply-to: Moran.pa's message of 31 Mar 84 18:13 PST
To: Moran.pa
cc: LafiteSupport.pa

Sounds like it might be a problem with Lisp's accessing of other partitions.  I'll be happy to look at the files involved sometime and see what's going on.

	Bill
*start*
00370 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 31 Mar 84 15:07 PST
From: Halasz.pa
Subject: Lisp: Current version of <lisp>library>suinglefileindex is bad.
To: LispSupport.pa
cc: 
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dorado

Listfiles bombs with DetermineFileMap undefined function.
Previous version (;38) works fine.

Frank

*start*
00584 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: LISPAR.AUTO
Date:  1-Apr-84  0:26:29 PST
Subject: Re: Lisp: Manditory file versions
In-reply-to: Wallace.pa's message of 31 Mar 84 13:40 PST
To: Wallace.pa
cc: LispSupport.pa

Gumby, are you fronting for Roach here?

What does EXACT possibly mean as a output recognition mode? Could you give a more precise specification?

(No other system I know of has a feature like this, so I think it may be hard. If you know of one, getting us a copy of the appropriate pages of its reference manual would be useful.)
*start*
01242 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  1 Apr 84 22:01 PST
From: Wallace.pa
Format: TEdit
Subject: Re: Lisp: Manditory file versions
In-reply-to: LISPAR.AUTO's message of 1-Apr-84  0:26:29 PST
To: LISPAR.AUTO
cc: LispSupport.pa

	Gumby, are you fronting for Roach here?
How did you guess?

	What does EXACT possibly mean as a output recognition
	mode? Could you give a more precise specification?
What I mean is that if I open the file "FOO.BAR" I don't want file "FOO.BAR!x" opened.  Versionless files are not only meaningful but necessary for some operations on {DSK} and {FLOPPY}.
                                                                                                                                        
	(No other system I know of has a feature like this, so I
	think it may be hard. If you know of one, getting us a
	copy of the appropriate pages of its reference manual
	would be useful.)

Do you mean no other Interlisp system?  I know of a number of systems that support such a thing.  But in any case, a kluge would suffice for now, even if it's not interlisp-y.
     
Who is this, anyway?  Larry?

kGACHA


TIMESROMAN
ÕGACHA
Az·*start*
00370 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  1 Apr 84 16:37 PST
From: Sheil.pa
Subject: Lisp: EDITSHADE ^E leaves unclean
To: LispSupport.pa

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

If one ^Es out of an EDITSHADE, it's window is left on the screen with a closefn of DON'T but not listening to the QUIT button.

Beau

*start*
00948 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  1 Apr 84 22:38 PST
From: vanMelle.pa
Subject: Re: Lisp: Proposal: 2 button mousing
In-reply-to: Sheil.pa's message of 29 Mar 84 10:25 PST
To: Sheil.pa
cc: LispSupport.pa, raim.pasa, LispCore^.pa

I think it is reasonable and not even particularly hard.  Mainly it is a little extra hair in the keyboard handler where it decodes the mouse "keys".  It needs to have a state machine and a timer so that it can decide if left and right go down close enough in time to be considered "simultaneous" and hence be treated as middle.  To handle the few cases of chording we have, you have to decide how to interpret left+right followed by one of left or right going up.  This seems entirely tractable to me.  The penalty of it all is principally some extra overhead in the keyhandler, but that can probably be arranged to occur only, or principally, on mouse transitions.

	Bill
*start*
00785 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  1 Apr 84 22:42 PST
From: vanMelle.pa
Subject: Re: Lafite: On Closing a browser.
In-reply-to: Ahenderson.pa's message of 31 Mar 84 11:29 PST
To: Ahenderson.pa
cc: LafiteSupport.pa

If indeed no Update needs to be done, then Close does not ask.  I suspect what you're observing is that Lafite considers Update needed if the file does not have an up to date table of contents (you browsed the file and it had to parse it first).  Even though nothing else changed, Lafite wants to write out a toc file so that next time you browse the file it is easier.  Not sure how to best handle this, except perhaps for Lafite to remember "toc needed" as a separate case from "Update needed" and prompt accordingly.

	Bill
*start*
00825 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 08:33 PST
From: Sannella.pa
Subject: [kaplan.pa: Re: AR 411: UNIX file names don't work with UNPACKFILENAME]
To: LispSupport.pa

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

From: kaplan.pa
Date: 31-Mar-84 21:25:18 PST
Subject: Re: AR 411: UNIX file names don't work with UNPACKFILENAME
In-reply-to: Your message of 31 Mar 84 14:08:41 PST (Saturday)
To: Sannella


This should be passed on to someone else.  Although I have thought about the issues and will be glad to offer advice, I have no interest in solving the general filename problem.  I think that an XSISer should be assigned responsibility for interfacing to various customer file configurations.

Please assign this to someone else.

--Ron

     ----- End of Forwarded Messages -----
*start*
00581 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 08:33 PST
From: Sannella.pa
Subject: [Burton.pa: Re: New LLCOLOR]
To: LispSupport.pa

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

Date:  2 Apr 84 06:31 PST
From: Burton.pa
Subject: Re: New LLCOLOR
In-reply-to: Sannella.PA's message of 31 Mar 84 15:19:46 PST (Saturday)
To: Sannella.PA
cc: Burton.pa, Feuerman.pasa, Raim.pasa

That file should go out with the sysout.  There are only a few users but all will crash after logout without that fix.  

richard


     ----- End of Forwarded Messages -----
*start*
01797 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 08:57 PST
From: Sannella.pa
Subject: [Raim.pasa: Scheduling]
To: LispSupport.pa

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

Date: Thu, 29 Mar 84 09:42 PST
From: Raim.pasa
Subject: Scheduling
To: VanMelle.PA
cc: LispCore^.PA

fyi...

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

Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 28 MAR 84 13:45:34 PST
Date: Wed, 28 Mar 84 13:45:07 PST
From: Eric Schoen <Schoen@SUMEX-AIM.ARPA>
Subject: Periodic interrupts
To: 1100support.pasa

The scheme I described in this space previously was a bit too flakey
for general use.  I did come up with something more reliable.  I 
defined a new class of interrupt called SCHEDULER.  I then armed ^S to
be the scheduler interrupt.  At every \PERIODIC.INTERRUPT I 
uninterruptably (replace (INTERRUPTSTATE INTCHARCODE) of \INTERRUPTSTATE
with (CHARCODE ^S)) and (SETQ \PENDING.INTERRUPT T).  When the 
periodic interrupt goes away, I get a lisp software interrupt.  For
class SCHEDULER, INTERRUPTED was redefined to call the function SCHEDULER,
which does something like suspend and wake various processes.  The people
trying to use this stuff are simulating a data acquisition system in which
processes have various priorities, and are using their own priority
mechanism, rather than trying to use those parts of PROCESSWORLD priorities
which are implemented.

The other benefit from this code is that with \PERIODIC.INTERRUPT turned
off, I can still force a block during a non-blocking computation simply by
typing ^S.

And yes, it's very dangerous and things still crash now and then, but
it's sufficient to simulate our systems.

Eric
-------
------------------------------------------------------------


     ----- End of Forwarded Messages -----
*start*
01080 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 09:09 PST
From: Sannella.pa
Subject: [Masinter.pa: [vanMelle.pa: Re: two little addenda]]
To: LispSupport.pa

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

Date: 30 Mar 84 15:42 PST
From: Masinter.pa
Subject: [vanMelle.pa: Re: two little addenda]
To: LispCore^

fyi

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

Date:  1 Jan 84 16:52 PST
From: vanMelle.pa
Subject: Re: two little addenda
In-reply-to: JONL.PA's message of 1 JAN 84 03:42 PST
To: JONL.PA
cc: LispCore^.PA

There is a much easier, less grody, and of course, official, way to make an arbitrary function FOO undoable on typein: define a function /FOO that is an undoable version of FOO, and then add (FOO . /FOO) to the variable LISPXFNS.  Thus define

(/PRINTLEVEL (CARVAL CDRVAL)
   ((LAMBDA (RESULT)
	(UNDOSAVE (LIST (FUNCTION /PRINTLEVEL) RESULT))
	RESULT)
    (PRINTLEVEL CARVAL CDRVAL].

I put this definition on UNDO and restored the old APRINT.

	Bill

     ----- End of Forwarded Messages -----

     ----- End of Forwarded Messages -----
*start*
00630 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 12:19 EST
From: Denber.wbst
Subject: Re: Lisp: PROMPTREMINDERS
In-reply-to: JONL.PA's message of 30 MAR 84 16:13 PST
To: JONL.PA
cc: LispSupport.PA

Ah of course - that's better, but I still have the problem of wanting to eval *now* something that has to be inside a QUOTE.  I want to beep and print the message so I say

'(PROGN (BEEPON 100)
		(PROMPTPRINT (CADDR (GETDEF RMDR
								'REMINDER))))

I don't want the BEEPON or PROMPTPRINT eval'd now, but I do want the arg to PROMPTPRINT eval'd now.  How do you do this in Lisp?

			- Michel
*start*
00211 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 09:19 PST
From: ROACH.PA
Subject: AR 276
To:   LISPSUPPORT
cc:   ROACH

     Has already been reported as AR 217.
				Kelly
*start*
00274 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 11:32 PST
From: ROACH.PA
Subject: AR217 additions
To:   LISPSUPPORT
cc:   ROACH

	Difficulty _ Moderate
	Frequency _ Every time
	Impact _ Moderate
	Problem Type _ Bug
	Priority _ Perhaps
*start*
00195 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 11:44 PST
From: ROACH.PA
Subject: AR217
To:   LISPSUPPORT
cc:   ROACH

     Subject _ Error ARG NOT LP: NIL
*start*
00501 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 11:39 PST
From: ROACH.PA
Subject: AR253 additions
To:   LISPSUPPORT

	Difficulty _ Moderate
	Priority _ Unlikely
	I probably won't remove the self consistency checks until
end of summer.  Some of the consistency checks have actually caught
bugs in the field and have helped me in my debugging effort.  When
I am reasonably sure that the checks are no longer doing anyone
any good, I will phase them out.
				Kelly
*start*
00587 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 11:53 PST
From: ROACH.PA
Subject: AR270 (GETD 'FLOPPY.MODE) = NIL
To:   LISPSUPPORT, DERING.PASA
cc:   ROACH

Judy,
     I am unable to reproduce your problem.  After moving a sysout off
of floppies to another Dlion, (GETD 'FLOPPY.MODE) is {CCODEP}#1,11000,
not NIL, and everything about FLOPPY.MODE seems to be working.  The
ARG NOT LP error part of your message is a bug, and is being treated under
AR217.

Lispsupport,
	Difficulty _ Impossible
	Priority _ Unlikely
	Status _ Incomplete

				Kelly
*start*
00560 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 11:48 PST
From: Sybalsky.pa
Subject: Lafite: Can't parse a header-only msg for send?
To: LafiteSupport.pa
cc: Sybalsky.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dandelion

If I send a header-only msg without 2 CRs at the end, I die under the header-parser with a non-numeric arg NIL.  This might be caused by TEdit's cretinous (yes I know who did it) returning NIL at EOF; would you prefer I errored out for you to catch?
*start*
00163 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 11:46 PST
From: Sybalsky.pa
Subject: Lisp: AR 178 FIXED
To: LispSupport.pa

*start*
00349 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 12:06 PST
From: Sybalsky.pa
Subject: Re: AR 369: EXPORTS.ALL won't load
In-reply-to: LispSupport.pa's message of 29 Mar 84 12:47:44 PST (Thursday)
To: LispSupport.pa
cc: Sybalsky.pa

Not me, baby.  I have no clue what's going on.  IMAGEOPS belong to Ron Kaplan.
*start*
01009 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 12:06 PST
From: ROACH.PA
Subject: AR207 SYSOUT to floppy doesn't reset FLOPPY.MODE
To:   LISPSUPPORT
cc:   ROACH

     I did a sysout to floppies this morning and find FLOPPY.MODE
being set back to PILOT as it should be after moving the sysout
onto another machine.  Of course, if the user was in FLOPPY.MODE
SYSOUT before doing the (SYSOUT '{FLOPPY}), then FLOPPY.MODE will
remain at SYSOUT.
     Teknowledge told me on my last visit to them (early Feb) that
they had this sort of problem after sysouting to a VAX.  Maybe it's
a bug that's been fixed or maybe some code is doing something funny
to aftersysoutforms or device eventfns somewhere.  I can't reproduce
the problem and I'll need more information before I can do anything
meaningful.
     The ARG NOT LP NIL part of this message is a bug and is being
handled under AR217.
     Difficulty _ Impossible
     Priority _ Unlikely
     Status _ Incomplete
				Kelly
*start*
00206 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 12:09 PST
From: ROACH.PA
Subject: AR371 additions
To:   LISPSUPPORT

	Difficulty _ Hard
	Priority _ Unlikely
				Kelly
*start*
00483 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 11:50 PST
From: Sybalsky.pa
Subject: Lisp: Need a "Can't Replicate" status for ARs
To: LispSupport.pa
cc: Sybalsky.pa
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dandelion

Systm:  AR/Adobe.
Impact:  Annoying
Problem:  There are frequently ARs that I can't replicate.  It would be nice if there were a mechanism for marking such items as "not preprducible" or "awaiting more information".
*start*
00194 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 11:38 PST
From: Sybalsky.pa
Subject: Lisp: AR 155 (doc NS directories stuff)
To: LispSupport.pa

is fixed.
*start*
00404 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 11:51 PST
From: Sybalsky.pa
Subject: Lisp: AR summaries need a NEW flag
To: LispSupport.pa
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dandelion

It's a pain to have to search the weekly bug summary for items that are "new this week".  'Twould be nice if they were flagged somehow, so I could scan them first.
*start*
00306 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 11:21 PST
From: ROACH.PA
Subject: <LISPCORE>LIBRARY>SETF.DCOM -> <LISP>LIBRARY>SETF.DCOM
To:   LISPSUPPORT
cc:   ROACH

     Please move the <LISPCORE>LIBRARY> version of SETF.DCOM
to <LISP>LIBRARY>.  Thanks.
				Kelly
*start*
00928 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 12:08 PST
From: vanMelle.pa
Subject: Re: AR#440: the text should appear somewhere
To: le.pasa
cc: LispSupport

This is two questions.  The subject of the first should be something like "printout to T from a funarg never appears".  Disposition: please get a test case or more detailed description--this report is too vague.

The second part, "How do I print to the top level tty window from some random process?" is answered: If you really want to do this (and note that you usually don't; a random process usually has no control over what is happening in the top level tty, and no way of coordinating with it--do you really want to print there even if you're in the middle of a compilation?), there is a function PROCESS.TTY that takes a process as arg and gives back its ttydisplaystream.  Thus, (PROCESS.TTY 'EXEC) might be what you want.
*start*
00319 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 11:43 PST
From: ROACH.PA
Subject: AR276 additions
To:   LISPSUPPORT
cc:   ROACH

     Superseded-by _ 217
     Difficulty _ Moderate
     Frequency _ Every time
     Impact _ Moderate
     Problem Type _ Bug
     Priority _ Perhaps
*start*
00957 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 12:13 PST
From: Kaplan.pa
Subject: Re: AR 456: HARDCOPYW producing bad press files
In-reply-to: LispSupport.pa's message of 2 Apr 84 11:49:42 PST (Monday)
To: LispSupport.pa
cc: Kaplan.pa

I do not really understand the HARDCOPYW interface.  Problems on this should be given to Masinter.  Nuyens also looked into this recently, perhaps he should be included.

I think that there are some serious design flaws in here, and also in the Printertypes interface.  Larry and I had different conceptions of the way it should be, and the result probably fell somewhere in the middle.

All that aside, I wouldn't be surprised if this problem is due to the fact that HARDCOPYW is somehow constructing an Interpress file, but then attempting to print it as a press file, perhaps because the extension of the file is .PRESS.

Right now, Gregg might be the best bet for this.

--Ron
*start*
00437 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 12:13 PST
From: vanMelle.pa
Subject: Re: AR#442: improve documentation of DLion keyboard
To: 1100Support.pasa
cc: LispSupport

This looks like an action item for 1100Support: the guide you give to users should definitely tell them what DLion keys correspond to what Dolphin keys.  E.g., middle-blank -> OPEN; bottom-blank -> STOP; line-feed -> SAME.
*start*
00300 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 11:57 PST
From: Maxwell.pa
Subject: Lisp: STRINGREGION
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

STRINGREGION should optionally take a font instead of a window.

Thanks,

John.
*start*
00341 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 11:59 PST
From: Sybalsky.pa
Subject: Re: AR 362: CTRL-sel & Scrolling causes bad inverted text
In-reply-to: LispSupport.pa's message of 29 Mar 84 12:04:04 PST (Thursday)
To: LispSupport.pa
cc: Sybalsky.pa, TeditSupport.pa

Is FIXED for the next release.
*start*
00614 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 12:02 PST
From: vanMelle.pa
Subject: Re: AR#439: DWIM questions in mouse process can't be answered
To: 1100Support
cc: LispSupport

I think this was fixed last fall, but probably after Fugue.4 went out.  I can't replicate this in the current sysout; see if you can, and/or if you can replicate it in Fugue.4.  For a test case, you can do something like

_(SETQ MYFUNNYNAME 1)

_(PROCESS.EVAL 'MOUSE '(ADD1 MYFUNYNAME))

and see if you can answer the question that pops up in the new mouse window, "MYFUNYNAME -> MYFUNNYNAME ?"
*start*
00449 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 13:38 PST
From: Kiewiet.pasa
Subject: Re: AR#439: DWIM questions in mouse process can't be answered
In-reply-to: vanMelle.pa's message of 2 Apr 84 12:02 PST
To: vanMelle.pa
cc: 1100Support.pa, LispSupport.pa

Thanks, Bill, for the speedy reply.  I don't have a Fugue4 loadup here either, so I'm passing the response to Rick that it is fixed in Fugue6.

Lorraine
*start*
00318 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 12:02 PST
From: Sybalsky.pa
Subject: Lisp: AR 354 isn't mine
To: LispSupport.pa
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dandelion

Bill Van Melle, maybe.  I don't run the keyboard code, so I can't very well document it.
*start*
00274 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 12:16 PST
From: vanMelle.pa
Subject: Re: AR#451: HANDLE.RAW.XIP causes checksum error
To: 1100Support.pasa
cc: LispSupport

This is an old bug that was fixed and reported fixed long ago.
*start*
00602 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 12:18 PST
From: vanMelle.pa
Subject: TEdit: Cursor not restored when leaving window to left
To: TEditSupport
cc: vanMelle.pa

TEdit System Date:  2-Mar-84 16:54:27
Lisp System Date: 29-Mar-84 17:34:40
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Annoying

When I move the cursor out of a tedit window leftward, the cursor changes into a uprightward pointing arrow as I pass thru the "line" bar, but then never changes back to normal as I proceed out the window.
*start*
00489 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Sender: Sannella.PA
Date:  2 Apr 84 12:28:45 PST (Monday)
Subject: Re: Lisp: Current version of <lisp>library>suinglefileindex is bad.
In-reply-to: Halasz's message of 31 Mar 84 15:07 PST
To: Halasz
cc: jonl, lispsupport
From: LispSupport

Thnak you for your message.  We have found the problem, and put a new version of singlefileindex on <lisp>library>.  I have personally loaded and used it, and it seems to work.

*start*
01204 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 12:55 PST
From: JONL.PA
Subject: Re: [kaplan.pa: Re: AR 411: UNIX file names don't work with UNPACKFILENAME]
To:   Sannella, LispSupport
cc:   JONL

In response to the message sent   2 Apr 84 08:33 PST from Sannella.pa


For some time now, I've been lobbying for a "smarter" UNPACKFILENAME -- it
would solve a lot of other problems too.

Basically, UNPACKFILENAME would have to know the operating system type
of the name for which it is unpacking; generally the HOST name can be found
in a OS-independent way (i.e., it is the string between the { and }, or
it is supplied by default from the connected directory).  Of course, an 
additional optional argument would be added to the user-level functions so 
that the automatic default could be overrided with an explicit OS name.


Amongst the other kinds of problems it would solve are the automatic
uppercasification of file names (some file systems are case-sensitive, and
others alledgedly aren't); and possibly the EXACT feature wanted by Gumby
and Roach.


Whether or not I could work on this problem is dependent on the priority of
the other items on my queue.

*start*
00839 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 13:04 PST
From: JONL.PA
Subject: Re: [Masinter.pa: [vanMelle.pa: Re: two little addenda]]
To:   Sannella, LispSupport
cc:   JONL, LispCore^

In response to the message sent   2 Apr 84 09:09 PST from Sannella.pa

Larry sent out a message after forwarding the note of 1 Jan 84 below saying
that he didn't mean to do it -- his finger slipped while having several
different mail browsers open.

The basic problem here is that LISPXFNS isn't documented, and probably
doesn't need to be.  The documented interface is NEW/FN.

The AR, if any need be, should be that NEW/FN should be mentioned in section
8.5 of the manual, about paragraph 5, which starts out "Therefore for each
primitive destructive function, Interlisp has defined an undoable version ..."

*start*
01069 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 13:12 PST
From: JONL.PA
Subject: Re: Lisp: PROMPTREMINDERS
To:   Denber.wbst, JONL
cc:   LispSupport

In response to the message sent   2 Apr 84 12:19 EST from Denber.wbst

The usual Interlisp way of doint this is via SUBST, SUBLIS or SUBPAIR.  E.G.,
   (SUBST (CADDR (GETDEF RMDR 'REMINDER))
          'MSG
          '(PROGN (BEEPON 100) (PROMPTPRINT 'MSG)))

If you really want to hack the reminder definitions this way, you should
probably have CALENDAR (or whatever the application) do a LOADFROM on
the source of PROMPTREMINDERS in order to get the symbolic RECORD definition
for REMINDERS.  There is a primitive version of that declaration "exported"
to the user (via the .DCOM) file called something like \SHOWABLE.PROMPT.REMINDER
so that the INSPECTor can get a handle on it.  But I don't forsee any problem
with your application doing the LOADFROM (underneath a filecom of DECLARE:
EVAL@COMPILE DONTCOPY of course) as long as the piece of code with the SUBST
is compiled.

*start*
00316 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 16:45 EST
From: Denber.wbst
Subject: Re: Eval-ing
In-reply-to: LispSupport's message of 2 Apr 84 12:58:01 PST (Monday)
To: LispSupport.PA
cc: JONL.PA

BQUOTE!  Yes yes, I love it - but why is this not in the manual?

			- Michel
*start*
02048 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 14:27 PST
From: JONL.PA
Subject: Re: Eval-ing
To:   Denber.wbst, LispSupport
cc:   JONL

In response to the message sent   2 Apr 84 16:45 EST from Denber.wbst

I thought BQUOTE was in the manual (Fall 1983 version).  But there are
several problems with trying to use it in Interlisp -- 
1) The basic problem it "solves" is that it "compiles a program to cons
   up the structure" rather than doing the copy thing like SUBST/SUBLIS/SUBPAIR
   do.  But with the interpreter and compiler "caching" macro expansions in
   CLISPARRAY, there seems to be little need for extra speed; in the Common 
   Lisp world, there is no pervasive mechanism like CLISPARRAY (but provisions 
   for an automatic "caching scheme" on a mcaro-by-macro basis).
2) With the varying contents of the T readtable, EDITRDTBL, FILERDTBL, etc,
   one can't use the macrocharacter everywhere -- thus he is left with a
   "hybrid" system, where he must expect to put BQUOTE in some places, but
   "," in others.  There is a long-standing desire on the part of some of
   us up here to homogenize the various readtables, so that PQUOTE and some
   version of a backquote can be made standard (including being printed out 
   with the backquote notation rather than with "BQUOTE" by prettyprint).
3) The "backquote" notion came out of the MacLisp world (now generall called
   the Common Lisp world) where the most common use was in macro-producing
   macros; given the character and treatment of macros in Interlisp, there
   seems to virtually no place (or instances of usages) of macro-producing
   macros.  However, as your example shows, there are some legitimate usages
   that are not related to macros.  Nevertheless, there are at least three 
   "bugs" with the current Interlisp design that make it incompatible with
   the Common Lisp one, so if one has had some experience in the Common Lisp 
   world, he will likely want to load in Kelly Roach's Library package called 
   BQUOTE.

*start*
00983 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Sender: Sannella.PA
Date:  2 Apr 84 12:58:01 PST (Monday)
Subject: Re: Lisp: PROMPTREMINDERS
In-reply-to: Denber.wbst's message of 2 Apr 84 12:19 EST
To: Denber.wbst
cc: JONL, LispSupport
From: LispSupport

Re: Ah of course - that's better, but I still have the problem of wanting to eval *now* something that has to be inside a QUOTE.  I want to beep and print the message so I say

'(PROGN (BEEPON 100)
		(PROMPTPRINT (CADDR (GETDEF RMDR
								'REMINDER))))

I don't want the BEEPON or PROMPTPRINT eval'd now, but I do want the arg to PROMPTPRINT eval'd now.  How do you do this in Lisp?

			- Michel
-----


(LIST 'PROGN
      '(BEEPON 100)
      (LIST 'PROMPTPRINT (CADDR (GETDEF RMDR 'REMINDER)]
      
      or 

(SUBST (CADDR (GETDEF RMDR 'REMINDER))
       'XXX
       '(PROGN (BEEPON 100) (PROMPTPRINT XXX))]

     or
     
(BQUOTE (PROGN (BEEPON 100)
		(PROMPTPRINT ,(CADDR (GETDEF RMDR 'REMINDER)))
*start*
00315 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 13:07 PST
From: Wallace.pa
Subject: TEdit: Cant: Too few selections
To: TEditSupport
TEdit-System-Date:  1-Mar-84 13:54:34
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

This error message is missing an apostrophe.

*start*
00356 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 12:53 PST
From: vanMelle.pa
Subject: Re: AR 458: Can't COPYFILE to protected directory --- even if password given!
In-reply-to: LispSupport's message of 2 Apr 84 12:29:24 PST (Monday)
To: LispSupport.PA
cc: vanMelle.pa, jonl.PA

This is a pupftp bug on my list to fix.
*start*
00706 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 12:48 PST
From: vanMelle.pa
Subject: AR status updates
To: LispSupport
cc: vanMelle.pa

AR 382: Attn Kaplan (hardcopy problem, not ether).

AR 389: Problem Type: performance

AR 168: perhaps/moderate/moderate

AR 193: Absolutely/Easy

AR 128: change to Perhaps

AR 165: change to Perhaps

AR 409: Difficulty moderate

AR 424: Difficulty moderate

AR 28: Difficulty easy

AR 306: Difficulty moderate

AR 283: Difficulty easy

AR 226: change to Attn Charnley; Priority Hopefully

AR 307: Difficulty moderate

AR 54: Difficulty hard

AR 88: Difficulty very hard

AR 393: change to Tedit, attn Sybalsky, priority Hopefully
*start*
00272 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 14:02 PST
From: Sybalsky.pa
Subject: Lisp: ARs 18 362, 404, 364 Fixed
To: LispSupport.pa
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dandelion

Will be in next release of TEdit.
*start*
00403 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 31 MAR 84 15:09 PST
From: ROACH.PA
Subject: STREAM = NOBIND underneath SEE
To:   LISPSUPPORT, LISPCORE^
cc:   ROACH

     Doing
	SEE {PHYLUM}<ROACH>PAPER>HEAD8.TEDIT
I get "NOBIND - UNDEFINED FUNCTION" after seeing most of the first 4 lines
of the file.  I see PFCOPYBYTES calling \PEEKBIN with arg STREAM = NOBIND.
				Kelly
*start*
00456 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: kaplan.pa
Date: 31-Mar-84 21:30:05 PST
Subject: Re: STREAM = NOBIND underneath SEE
In-reply-to: ROACH's message of 31 MAR 84 15:09 PST
To: ROACH
cc: LISPSUPPORT, LISPCORE^

Which system was this in?  I worked on PFCOPYBYTES to do the EOL convention, but I'm not sure that my fixes made it into a loadup.  Don't delete the offending file, and I will take a look on Monday.

--Ron
*start*
00332 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  1 APR 84 10:13 PST
From: ROACH.PA
Subject: Re: STREAM = NOBIND underneath SEE
To:   kaplan
cc:   ROACH, LISPSUPPORT

In response to your message sent  31-Mar-84 21:30:05 PST

     Bug occurred in system with MAKESYSDATE = "29-Mar-84 17:34:40".
				Kelly
*start*
01460 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 30 Mar 84 13:18:59 PST (Friday)
From: JFung.pasa
Subject: AR communications
To: Masinter.pa
cc: LispSupport.pa, 1100Support, Sheil.pa, JFung

Larry, Mike,

I am trying to strengthen the AR communications.  I think right now we have a good way of identifying AR and submiiting them.  But no communication coming back.  

I propose that when the person ("attentioned") who claims a change of Status state, should inform the following persons: 1. Source 2. PARC Adobe Adminstrator (LispSupport) and 3) PASADENA Adobe Administrator (Le.pasa, or 1100Support).  I believe the important filed here is Status.
Or if he prefers just broadcast to the apporpriate DL about change of status.  A mail with header information will be sufficinet. (Subject: AR nnnn Status{} _ Fixed)
(I must confess I didnot do this on my ARs.)

Unless we do this, then it is up to each individual who is interested with that AR to keep constantly monitoring its state, which I believe is inefficient.

I am raising this issue because we have miscommunications of the state of the AR and not remaining uptodate about its state changes. (at least myself)

How does this sound to you folks?

P.S. 	I really think that you should start using the "assigned to" field, I can't understand why not.  If no one wants the AR, then it is up to the management to "assign" it to someone and meantime assign priority.

	/Jerry

*start*
00378 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 31 Mar 84 14:29 PST
From: Christman.pa
Subject: Lafite: not finding mail on cabernet
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 28-Mar-84 00:03:18
Machine-Type: Dorado

Lafite claimed I had no mail on cabernet, yet when
i ran laurel I retrieved 93 messages..

-dave
*start*
01354 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: kaplan.pa
Date: 31-Mar-84 21:44:01 PST
Subject: Tedit bug
To: TeditSupport


Halvorsen reports a bug in the TEDIT shift and control-shift mechanism, as indicated below.  If you are not already aware of this, please check with him for details.

I would consider this a FATAL  bug, since it seems to muck up the users file.  If it can be fixed easily, the fix should be installed and a new Tedit released ASAP.  If it can't be fixed quickly and it is newly introduced, then Tedit should be backed up to the last known working version.  If it can't be fixed and can't be backed up, then a new Tedit should be released ASAP that disables control-shift entirely, pending a final fix.  

--Ron


----------

Date: 27 Mar 84 15:10 PST
From: halvorsen.pa
Subject: Subject: LFG editors
To: LFG^.pa
cc: halvorsen.pa

There is a bug in the TEDIT shift and control-shift mechanism which will cause you problems if you try to use these features of TEDIT when editting rules or grammars.  

Try typing the text in instead of shift-selecting, and you will get a more predictable result.

The bug in question is one which omits  characters from the file, while displaying them on the screen.  You think you are ok from looking at your editting window, but in fact you are not.

	Per-Kristian

*start*
00527 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 13:56 PST
From: Sybalsky.pa
Subject: Re: Tedit bug
In-reply-to: kaplan.pa's message of 31-Mar-84 21:44:01 PST
To: kaplan.pa
cc: TeditSupport.pa

After pondering his description for a while, I figured out that it's an instance of the "characters getting dropped when READing from a TExtStream" bug--assuming this is the same problem he showed me about a week ago.

The bug has been found and fixed, and will be in the next release of TEdit.
*start*
00918 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 09:54 PST
From: DMRussell.pa
Subject: Lisp: GRAPHER comments
To: LispSupport.pa
cc: DMRussell.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

Nit-picky details -- 

It would be nice if SHOWGRAPH took a window name as an argument.  I KNOW I can create a window and pass that in, but I like the way SHOWGRAPH lays out its window (automatically choosing the right size) and don't want to compute that on my own.  

When a node is BOXED, it is a little hard to read.  How about making the box bigger by one pixel all around?  

More seriously, the error messages are less than always obvious.  The error message is almost always "Node doesn't have a position", but when you look at the node -- it does.  The true cause is ALWAYS something else.  (I know this is hard to fix.  But I had to say something.)  


-- DMR -- 

*start*
00746 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 09:58 PST
From: DMRussell.pa
Subject: Lisp: Menu operation
To: LispSupport.pa
cc: DMRussell.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

I like two things about the way LOOPS has its menus set up.  

1) The menu "remembers" the last selection you made.  That is, the cursor is automatically positioned over the selection chosen last time around.  This is great, because I very often do things repetitively (e.g. inspect the same record type, over and over).  

2) A menu item that has "submenus" is indicated by a >> sign on the far right of the menu item line.  

Can these be incorporated into Interlisp's menu handling style?

-- DMR -- 

*start*
00630 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 11:55 PST
From: Sybalsky.pa
Subject: Lisp: Scrollbar & CursorOutFn fight over cursor shape
To: LispSupport.pa
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dandelion

If I have a window whose CURSOROUTFN resets the shape of the mouse cursor, and I leave the window via the scroll bar, then:

	--Mouse enters scroll bar, changes shape to arrow (OK).

	--Mouse leaves scroll bar, CURSOROUTFN is called (OK).

	--Scrollbar handler resets cursor shape (not OK).

If the order of the last two were reversed, it would make TEdit's life easier.
*start*
00915 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 14:57 EST
From: Denber.wbst
Subject: Lisp: LISPUSERS
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dolphin

I realize Lispusers packages are unsupported, but is there any mechanism for fixing/removing those that don't work?  I tried to use DATETIME and was unable to make it do anything useful.  In particular, a call to PARSEDATETIME, eg. (PARSEDATETIME "11 PM") results in an EOF error.

It seems that the eof character they are appending to the string (the vertical bar) is not recognized as such.  The READ in EXPANDINPUT then runs off the end.  I tried using a different character (a $) and it worked (I made $ a breakchr in DTRDTBL).  Unfortunately, the $ caused other problems later on.  The source doesn't seem to have been changed since 1978.  Has anyone used it lately besides me?

			- Michel
*start*
00388 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 12:22 PST
From: vanMelle.pa
Subject: Re: Lafite: Can't parse a header-only msg for send?
In-reply-to: Sybalsky.pa's message of 2 Apr 84 11:48 PST
To: Sybalsky.pa
cc: LafiteSupport.pa

Absolutely.  BIN at the end of a stream should always apply (and return the result from) the stream's ENDOFSTREAMOP.
*start*
00299 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 12:23 PST
From: Sybalsky.pa
Subject: Re: TEdit: TEDITMENU does not detach window on Quit
In-reply-to: Halasz.pa's message of 29 Mar 84 19:44 PST
To: Halasz.pa
cc: TEditSupport.pa

Got it--in next release.  Thnkx
*start*
00612 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 13:23 PST
From: JONL.PA
Subject: Re: AR 456: HARDCOPYW producing bad press files
To:   Kaplan, LispSupport
cc:   JONL, Nuyens

In response to the message sent   2 Apr 84 12:13 PST from Kaplan.pa

Many months ago I complained that HARDCOPYW was arbitrarily producing an
Interpress file, even though the first printer on my DEFAULTPRINTINGHOSTS
was a press printer.  The lossage, of course, is that the nearest Interpress
printer is a loooong walk, and a floor hop away; whereas the press printer
is "just around the corner".

*start*
00343 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 13:46 PST
From: Sybalsky.pa
Subject: Re: TEdit: TEDIT.SETSEL does not reset the SELOBJ field of the curren.t selection.
In-reply-to: Halasz.pa's message of 30 Mar 84 17:00 PST
To: Halasz.pa
cc: TEditSupport.pa

Already fixed for the next release.  Thanks.
*start*
00867 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 14:55 PST
From: JONL.PA
Subject: AR 317: ZEROP should be redefined
To:   LispCore^
cc:   LispUsers^

Norton Greenfeld, of Applied Expert Systems, Inc., suggests that we
remedy the situation with the misleadingly-named function ZEROP.  Instead of 
being defined as (EQ X 0), he suggests (EQP X 0), and also suggests adding 
a primitive IZEROP.

Using the masterscope database for the system code (as well as many
library packages) I could easily "fix up" any system usages for which
this change would cause problems.  Also, I believe an OPENLAMBDA macro 
definition for the new ZEROP, which would do a SELECTC on (NTYPX X) first
(begfore doing a function call) would forstall any time-performance problems.

But what about you users -- how would you be affected by such a change?

*start*
00486 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 14:16 PST
From: Burton.pa
Subject: Re: AR 441: Want break window brought to top after editing fn from backtrace menu
In-reply-to: LispSupport.pa's message of 2 Apr 84 09:41:26 PST (Monday)
To: LispSupport.pa

I am planning on changing it so that the cursor will always be visible.  This will have the effect of bringing the break window to the top when DEdit returns control to the break.

richard

*start*
00328 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 14:19 PST
From: Sybalsky.pa
Subject: Re: TEdit: Cant: Too few selections
In-reply-to: Wallace.pa's message of 2 Apr 84 13:07 PST
To: Wallace.pa
cc: TEditSupport.pa

I think you mean DEDIT.  I don't recall ever putting such a msg into TEDIT.
*start*
06713 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from BBNG.ARPA by PARC-MAXC.ARPA;  2 APR 84 16:25:23 PST
Date: 2 Apr 84 19:25 EST
Sender: GREENFELD@BBNG.ARPA
Subject: Xerox customer support
From: GREENFELD@BBNG.ARPA
To: 1100support.pasa
Cc: lispsupport.pa
Message-ID: <[BBNG] 2-Apr-84 19:25:57.GREENFELD>

APEX is considering becoming a major customer of Xerox lisp
machines, and an important part of this decision is the quality
of customer support.  Our own installation is acting as a test
site for this support, and has just been through a Xerox customer
support operation.  We have come out of it in worse shape than
before it all started.  I want to detail what happened so that
the situation can be remedied and perhaps prevented in the
future.

The Saga (as best I can remember it)

The weekend before this last one our printer (an 8045) went down
and would not boot.  On Monday I dutifully called the local BSG
office, and was told that the appropriate person would get right
back to me.  Within ten minutes another person had called and
immediately sized up the problem and its solution:  reload our
software.

Unfortunately, we had not been given software with our printer,
and so were told to contact XSIS and acquire it.  I then called
Pasadena, and ended up talking to Clay Agadoni.  He said, of
course we should have gotten the software, and asked how much
memory our printer had (1.5 megabytes).  He then put me in touch
with Joan Phillips, the specialist in printers.  She wasn't in at
that moment and would get back in touch.

Tuesday.  I reached Joan.  She also immediately figured out the
problem and said that the floppies and documentation on how to
use them would be in the mail right away.

Wednesday came and no floppies.  A call to Joan yielded the
response that the documentation had caused the package to go out
that morning, by Express Mail, so we should get them Thursday
morning.  Later Wednesday Rob Ferrar called (he's in our nearest
XSIS service center in Rosslyn, Virginia).  He said that he would
have to come up to install the software and would also change our
memory size back to the standard, since the error seemed to be
one that he had recently seen, and related to the
larger-than-standard memory.  He would be here Thursday morning.

Thursday came, but no Rob.  The Washington area had been hit by
an unusual snowstorm and all airports were closed.  He would try
for Friday (and would have to juggle his schedule to do it).

Friday.  Rob arrived, and converted our printer from 1.5M to
384Kbytes; he loaded all the services software, and many fonts.
Unfortunately, our tests of listfiles appeared to print out blank
pages, though window prints and snapshots worked.  Rob had to
leave (the weather was looking somewhat ominous).  The floppies
from Joan containing the services software arrived in the
afternoon.


Observations

First, it is important to point out that our perceptions are that
all the individuals involved were quite helpful.  As individuals
they are intelligent and knowledgeable, with an attitude that
says "customer support."

However, there seems to be some higher-level problems that make
Xerox support not as comforting as it could be.  A customer
should never be told by one Xerox organization that he has to go
talk to another Xerox organization!  There should be one contact
point within Xerox that does the routing, if that's needed.

On another level, our printer also runs our Clearinghouse.  Thus,
if we had not had a backup means for the Clearinghouse, our
entire development crew would have been out of business for
nearly a week.

With the smaller amount of memory, the printer takes much longer
to operate (up to twice as slow for the time between getting the
document and starting to print).  The rationale that the smaller
memory would cause fewer crashes doesn't take into account the
fact that we had been operating the printer satisfactorily for
about 8 months prior to all this.  And the new slowness sent our
crew up the walls, since they had backlogged printing for the
week.

Finally, while we supposedly now have 59 fonts (according to the
printer), it has been traumatic for us lispers.  Our fontdefs
settings just no longer worked.  After a large amount of
exploration I found that we have the following lisp-accessible
fonts:
	
        Classic:  8,10,12,14,24 point sizes
	Modern:        12
        Gacha:  6,8,10,12
	
There are a variety of others (PRINTWHEEL, etc.)  that I have no
idea how to get to.  I might point out that in this interaction
we lost fonts we had before, such as other sizes of Modern.

Gacha is nice to have, since we had been struggling with only
variable width fonts.  We had asked about Gacha, had been told it
was an extra cost option, and were waiting for the price.  There
are some problems with this Gacha, however:  it is missing
characters 34, 94, 95, 96, and all those above 127.  These
characters are (in ASCII) ", _, ^, and accent-grave.  Its
somewhat difficult to read lisp code without the first two of
these.

The characters above 127 are a different problem.  Xerox has
standardized its fonts on some international standard (not ASCII,
but similar).  This doesn't cause much of a problem, and the
normal Interpress routines translate ^ and _ to some code greater
than 127.  (Either way we can't print these characters in Gacha.)
But we also can't print $, which has also been moved from its
standard ASCII position.  We had asked Xerox some time ago for
lisp to be cognizant of this particular switch, and the answer
was to advise the relevent printout functions, which we did.
Having Gacha not conform to Xerox's own standard makes it rather
difficult for us to use it.  I might note that $ is particularly
relevent to financial applications.

The net result of all this is that after a service call, we are
in worse shape than before!  Our printing takes much longer, we
don't have the fonts we were using, and the whole disaster took
nearly a week.  I do not believe that XSIS or Xerox would
perceive this as a good example of customer support.


Action items:

1.  Re-install the 1.5M memory immediately.  We prefer the
environment we've been working with for 8 months.  I will trade
the extra productivity for the more-often crashes, and I'm not
sure it crashes more often.

2.  Clean up the font picture.  What are the fonts we (or anyone
else) should have?  What fonts does Interlisp know about?  When
will there be similar fonts for printer and display?  and is
there one fixed-width font we can use?  [a Xerox standard should
be adhered to]

3.  Devise some structure that does not have us working thru more
than one Xerox sub-organization.

*start*
00524 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 16:44 PST
From: Dering.pasa
Subject: Re: AR270 (GETD 'FLOPPY.MODE) = NIL
In-reply-to: ROACH.PA's message of 2 APR 84 11:53 PST
To: ROACH.PA
cc: LISPSUPPORT.PA, DERING.PASA

 
Kelly,

I was able to reproduce the problem I described several times.
Were you using the March 13 Sysout?  Did you do the required step of aborting a previous (Sysout '{FLOPPY}) with a ^D?

These steps are detailed on Part 2 of AR 270  dated 22 Mar 84.


Judy

*start*
00426 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 17:09 PST
From: Burton.pa
Subject: TEdit: TEXTSTREAMP
To: TEditSupport
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 29-Mar-84 17:34:40

I noticed that it returned T.  I would suggest that it return the stream as do most datatype predicates.  Or is NIL a legal textstream?

richard

ps.  TEXTSTREAMP is a legal user entry, no?


*start*
00894 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 18:03 PST
From: ROACH.PA
Subject: Can't hardcopy overline sub/superscripts with TEDIT
To:   LISPSUPPORT
cc:   ROACH

     Impact _ Moderate

     Harcopying overlined subscripts & superscripts in TEDIT does not
work.  Create a file containing "sss", lower the first "s" and raise the
last "s" by passing (SUBSCRIPT 4) & (SUPERSCRIPT 4) to TEDIT.LOOKS,
making the appropriate selections.  Overline all 3 "s"'s and you will
get something resembling

	  -
	 -s
	-s
	s

in your TEDIT window.  If you like, you can simply Get
{PHYLUM}<ROACH>PAPER>SSS.TEDIT which already has this set up for you.
Bugging the Hardcopy item in TEDIT's menu gives me hardcopy resembling

	--#
	 s
	s

The "#" represents "s" overstruck with "-".  The appearance in the
TEDIT window is the correct appearance in my opinion.
				Kelly
*start*
00733 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 17:57 PST
From: JONL.PA
Subject: earlier troubles with COPYFILE
To:   LispSupport
cc:   vanMelle

Date:  8 MAR 84 19:33 PST
From: ROACH.PA
Subject: Re: <Lisp> directory
To:   masinter, LispCore^
cc:   ROACH

In response to the message sent   8 Mar 84 15:47 PST from masinter.pa

     There is no way to PUPFTP to <LISP> from MAXC.  COPYFILE & RENAMEFILE
to <LISP> do not seem to work, even if you give the password, and there
is no remembering of the password you give.  The only way to get anything
done is by CHATing to PHYLUM and going through 3 times as many motions as
normal plus knowing or being able to find the right password.
				Kelly
*start*
00724 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 15:37 PST
Sender: Guibert.pa
Subject: Lafite: Reply-to field for messages sent to DLs
To: LafiteSupport.pa
cc: Guibert.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dolphin
From: Shy and embarrassed


It would be great if Lafite would stick in a Reply-to Field when one sends a message to a distribution list.  For those of us who were used to using Laurel this is a REALLY useful feature.  It's embarrassing after working here 3 years to get public floggings for not having done something which you were accustomed to the system taking care of for you.


Yours truly,

Shy and embarrassed
*start*
00598 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 16:44 PST
From: vanMelle.pa
Subject: Re: Lafite: Reply-to field for messages sent to DLs
In-reply-to: Shy and embarrassed's message of 2 Apr 84 15:37 PST
To: Guibert.pa
cc: LafiteSupport.pa

Dear S & E,

Sorry about that.  Inserting a Reply-to field when appropriate is high on my list of things to do when overhauling the message sender.  I am often embarrassed when I see messages from Lafite users that omit a Reply-to field because of deficiencies in their mail program...

Sincerely,

Properly Embarrassed
*start*
02118 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 17:16 PST
From: vanMelle.pa
Subject: new Lafite
To: LispFriends^
cc: LispSupport
Reply-to: LafiteSupport.PA

on [Phylum]<LispCore>Library> and in the next full.sysout.

Fixes ARs 80, 111, 280, 414, and assorted other glitches.

By popular demand, Lafite no longer changes the shape of the cursor while you're inside the browser.  Those who have tried this modification find it much easier to select messages and not get confused by the message mark region.  As before, you can select a message by clicking anywhere in its summary line (except in the small mark region, where clicking enters the change mark mode).  Should there turn out to be popular demand for the old behavior, I may be forced to control it with a flag, but see how you like this way first.

For those of you who don't like to wait for Hardcopy to finish, or don't like losing every third of your 1-message-at-a-time listings because someone walked off with your hardcopy attached to the back of a big listing, or just are offended at the waste of paper involved, there is a new flag: LAFITEHARDCOPYBATCHFLG.  When this flag is true, Lafite "batches" your hardcopy requests, and doesn't actually print them until you do an Update, at which point it sends them all to the printer in one batch.  When you have hardcopy pending, the Hardcopy button is speckled to remind you of this fact.  The Update button has an additional choice "Do Hardcopy Only" in case you want to get your batched hardcopy printed without doing an actual Update.  The behavior of LAFITENEWPAGEFLG when batching hardcopy is that it applies only to the messages selected at each Hardcopy invocation; each new set of messages starts on a new page, independent of the setting of LAFITENEWPAGEFLG.

The Lisp/Lafite/Tedit report forms now have some additional information in them to aid the AR database.

Message senders no longer vanish on a HardReset.  They don't come back to life (this awaiting a future release), but they do stay open and change their title to "dead message editor".

	Bill
*start*
00419 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 17:57 PST
From: Nuyens.pa
Subject: Re: Lisp: NOW is being bound!
In-reply-to: JONL.PA's message of 16 MAR 84 11:18 PST
To: JONL.PA
cc: Nuyens.PA, LispSupport.PA

The problem is simply that \LASTUSERACTION is destructively changed.   Thus (SETQ A \LASTUSERACTION) will update A every millisecond (or whatever).  So no mystery.

Greg
*start*
00554 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 19:00 PST
From: JONL.PA
Subject: what are my ARs?
To:   sannella
cc:   Lispsupport

While browsing the AR database, I notice that AR 141 had been "assigned" to
me.  Yet I don't ever remember seeing notification of this, either in 
electronic mail, nor in my "SortedSummary".  It's kind of a moot point,
since it describes some actions that were completed in the past, but there
are several other ARs also in the category (e.g., AR 140, and who knows what
all else?).
*start*
01571 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 19:08 PST
From: JONL.PA
Subject: AR 167: more comments
To:   LispSupport

Date:  2 APR 84 12:37 PST
From: JONL.PA
Subject: Re: new transcendental functions
To:   MASINTER
cc:   JONL, Roach

In response to your message sent  31-Mar-84 12:40:19 PST

Out of curiosity, how did you "realize that ARCCOS of COS couldn't be
particularly stable for values near 0" after you sent out the msg?  After
all, it could well have been a bug -- the situation with ARCSIN of SIN,
for example, was similar! and it takes a little analysis to determine
which is the Poor-Approximation and which is the Inherent-Instability.


HORNERIFY is merely a shorthand way of writing out a polynomial evaluation --
it exists as a non-exported macro in AARITH and takes a form like
    (HORNERIFY a[n] X a[n-1] . . . a2 a1 a0)
into the appropriate composition of FPLUS and FTIMES to evaluate the polynomial
    a[n]X^n + a[n-1]X^(n-1) + . . .  + a1X + a0
using, of course, horners rule for order of calculations.


The brunt of the work for numerical approximation is to find a transformation
of the argument domain into some limited domain under which a polynomial
approximation has desirable "closeness" to the function.  There exist methods
for generating polynomials with minimum "max error" over the range, and there
exist methods for generating polynomials with minimum integral of error over
the domain.  As you can imagine, a few points with large error can still be
quite acceptable to the latter method.

*start*
00314 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 20:58 PST
From: JONL.PA
Subject: Re: AR 167: more comments
To:   JONL, LispSupport

In response to the message sent   2 APR 84 19:08 PST from JONL.PA

The middle paragraph of the aforementioned message has a bearing on
AR 211.
*start*
01252 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 19:49 PST
From: JonL.pa
Subject: AR 460 -- user wants handle on "Top level typescript window"
To: vanMelle.pa
cc: LispSupport.pa, Le.pasa, JonL.pa

It may be that the luser hasn't fully grasped the notion of a tty window for each process, but it shouldn't be a "sin" for several proceses to be dropping printout into the same window -- rather the coordination of such should be the programmer responsibility (with monitor locks, or strategy, or "nothing" if that's ok).  I know the LOOPS people do something like this -- they have a notion of a global exec window which several processes may be printing into.

PROCESS.TTY is more related to the combination of window/keyboard that makes up a "terminal" -- I think the user is just asking how to get a pointer the the apparently-hidden global resource titled "Top level typescript window" -- but it certainly can't hurt to probe his motives (e.g., does he REALLY want that window, or would a yatw suffice?)

Apart from documenting \TopLevelTtyWidow, is there any way for a user to find a handle on this window?   He could be told, for example, to just (SETQ MYTTYWINDOW (WHICHW)) with the cursor set appropriately.
*start*
00279 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 20:17 PST
From: JonL.pa
Subject: AR 159: priority and difficulty 
To: LispSupport
cc: JonL.pa

Priority: Perhaps
Difficulty: moderate
Impact: Serious to some users, merely annoying to others

*start*
00291 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 20:55 PST
From: JONL.PA
Subject: Re: Lisp: microcode enhancements
To:   JONL
cc:   LispSupport

In response to your message sent   2 APR 84 15:09 PST

This seems to apply to AR 57 "Microcode Priorities"

*start*
01763 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 21:00 PST
From: JonL.pa
Subject: AR priorities etc
To: LispSupport
cc: JonL.pa

Priority etc for
ARs 186, 199, 131, 132, 385, 386, 294, 314, 316, 383


AR 186 -- (FPLUS 0.0 (EXPT 2.0 -127)) ...
Difficulty: easy
Frequency: every time
Impact: annoying
Priority: perhaps

AR 199 -- Dorado does not punt on integer overflow
Difficulty:  Moderate  (because opening up the ucode for just one
         small thing is a pain, so other ucode tasks will be
         bunched in with this one, for a "several week" project)
Impact: annyoying
Priority: Hopefully

AR 131 -- improve performance on "consy" benchmarks
        Should also be flagged attention to Charnley

AR 132 -- I decline this one.  I believe that BARRERA.PASA has
        been hacking this package, and may have fixed the complaint.

AR 385 & AR 386 -- Aren't these the same AR really?  Could AR 384 just
        be marked "Status: Superseded by AR 385" ?

AR 294 -- I decline.  Further comments: An automatic interface with 
        "indirection" as suggested in this AR is not feasible (in general)
        since SINGLEFILEINDEX is taking a rather limited, local-context
        look at the expressions on the file while it is trying to parse it
        looking for definitions.  The documentation mentions this "heuristic"
        approach at finding the definitions.  I really speeds things up to 
        do it this way (orders and orders of magnitude!)

AR 314 
Status: Fixed (in sysouts made after March 26)

AR 316
Difficulty: Moderate
Impact: serious (to some, anyhow! merely  Minor to others)

AR 383 --  This AR should either be declined or closed -- neither
    I nor John seem to be able to reproduce it.


*start*
00336 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 14:47 PST
From: vanMelle.pa
Subject: new mp codes
To: LispCore^, LispSupport
cc: 1100Support.pasa

I changed 6 more Raid calls into distinct Mp codes (9319 thru 9324) and updated [Phylum]<LispCore>Next>LispMPCodes.tedit & .press accordingly.

	Bill
*start*
00831 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 15:09 PST
From: JONL.PA
Subject: Re: Lisp: microcode enhancements
To:   Masinter, LispSupport
cc:   sheil, JONL, vanMelle, Charnley

In response to the message sent  27 Mar 84 23:06 PST from Masinter.pa

On the file [Phylum]<LispCore>Doc>Ucode.Suggestion is a note from me sent
back in early January.  I proposed a new opcode that operates similarly
to TYPEP except that its alphabyte would be a "high end of range" rather
than an exact type to match.  So, discarding the typecode 0 (which my note
fails to make clear) one would compile, say,  NUMBERP, in 2 bytes instead
of the 12 or 13 it now takes.

I also proposed using the TYPEP opcode for LITATOM; there is a discussion about
the performance effects if TYPEP and LISTP share microcode.

*start*
00818 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 15:14 PST
From: JONL.PA
Subject: new mode for BREAKwindow
To:   Burton
cc:   LispSupport

Looking over the ATTACHEDWINDOW documentation, it appears as though the
following problem is merely the failure to reset the defaults for generation
of BREAK windows (with their subwindows for BT and the frame information).

Doing a BT! often winds up with a lot of information "dropped off the bottom"
of teh BT window; true, one could scroll it, but I prefer to reshae it manually.
However, the new default for reshaping causes a re-shape attempt for this
window to re-shape the whole group;  that is not good, since I don't
want the main break window to grow in height merely because the (rather
narrow) BT window has to grow in height.

*start*
00507 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 17:28 PST
From: stansbury.pa
Subject: Lafite: greetings
To: LafiteSupport.pa
cc: desrivieres.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 31-Mar-84 23:30:06
Machine-Type: Dandelion

At present, once one user has sent or read mail in a world, he remains the sender  (the "from:" and "cc:") despite intervening MAKESYS and GREET operations.  It would be better if Lafite forgot this information.

---Jim   
*start*
01147 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 12:30 PST
From: ROACH.PA
Subject: AR453
To:   LISPSUPPORT

     More precisely, David's problem is renaming {FLOPPY}lisp.sysout
to another versionless file name.  RENAMEFILE is inadequate because it
will always add a version number.  I have proposed a RECOG = EXACT in
the past.  Under this proposal, a function like RENAMEFILE would take
2 new args OLDRECOG & NEWRECOG:
	(RENAMEFILE OLDFILE NEWFILE OLDRECOG NEWRECOG)
OLDRECOG & NEWRECOG will default to 'OLD & 'NEW, but the user could
specify NEWRECOG = 'EXACT to get versionless filenames or any other
filenames that should not go through PACKFILENAME/UNPACKFILENAME
parsing.  I'll probably be putting a version of FLOPPY.DCOM out on
<LISPCORE>SOURCES> soon that will support RECOG = 'EXACT in its
internal functions, so that the user could call an internal function
like \PFLOPPY.RENAMEFILE with appropriate args, but clearly this isn't
going to become official.  I therefore punt this problem to FILEIO.
	Attn _ Kaplan
	Subsystem _ General file operations
	Machine _ 1108
	Source Files _ FILEIO
				Kelly
*start*
00928 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 15:03 PST
From: vanMelle.pa
Subject: TEdit: ExpandedMenu breaks on first use
To: TEditSupport
cc: vanMelle.pa

TEdit System Date:  2-Mar-84 16:54:27
Lisp System Date: 29-Mar-84 17:34:40
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Annoying

I brought up the expanded menu on a previously unformatted document.  I selected "Just" in the paragraph looks menu, and broke with an ILLEGAL ARG NIL in (TEXTOBJ NIL) in TEDIT.FIND.OBJECT in MB.NWAYBUTTON.SELFN.  The TEXTOBJ local in the latter two frames was NIL.  If I ^ out of the break, "Just" is highlighted, the formerly highlighted "Left" has but a bar over it, and subsequent selections in the menu succeed.

Furthermore, while I'm in that break, I can't type to any other tedit window.   I had to ^ out before I could type this message.
*start*
00505 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 10:42 EST
From: Denber.wbst
Subject: Re: new Lafite
In-reply-to: vanMelle.pa's message of 2 Apr 84 17:16 PST
To: LafiteSupport.PA

That reminds me - a minor point, but when you accidentally select the mark region, it says "hit ESC to abort".  Just about everything else (Laurel, Bravo, Chat ...) uses esc to *confirm*, and DEL to abort.  What say?  Can I run this new Lafite in an original Carol.1 sysout?

		- Michel
*start*
00374 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 12:36 PST
From: vanMelle.pa
Subject: Re: AR#351: Lafite MessageHardcopier and HardcopyW break with unclear error message
To: 1100Support.pasa
cc: LispSupport.pa

Attn. Kaplan.  But first check that Ms. Kiewiet is not still having hardware problems.  This sounds like outright flakiness.
*start*
00486 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 16:40 PST
From: Sheil.pa
Subject: [le.pasa: AR#436, #437]
To: lispsupport

mike:

could i see these pls?

beau

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

Date:  2 Apr 84 10:37:30 PST (Monday)
From: le.pasa
Subject: AR#436, #437
To: Sheil.pa
cc: le.pasa

Beau,

AR#436, and #437 are under your attn:.  Please have a look at these when you can.

Thank you,

Thu

     ----- End of Forwarded Messages -----
*start*
00758 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 09:35 PST
From: Sybalsky.pa
Subject: Re: Incorrect fontwidths for special Interpress codes
In-reply-to: Kaplan.pa's message of 20 Mar 84 23:28 PST
To: Kaplan.pa
cc: Lispsupport.pa, Sybalsky.pa

In the short run, we shouldn't have much trouble with the fonts widths inconsistency.   The reason is that the screen Star fonts--and the NSFonts widths files--all obey the STAR character code set instead of the NS code set.  Thus, hyphen and dollar sign have the right width.

Until we get real NS support, I have no good schemes for how to handle the problem in general; perhaps we should just create our own version of the star build-a-font-file tool to do the conversions.
*start*
03715 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 12:07:57 PST (Tuesday)
From: JFung.pasa
Subject: Re: Summaries of LispARs/LispAR-Submit.Form
In-reply-to: Sannella.pa's message of 19 Mar 84 20:20 PST
To: LispSupport.pa
cc: 1100Support, Le, Sannella.pa, JFung

I think it is good to have some defined AR files generated periodically.  I have some inputs, I think to use Adobe to its full extent power, we must be careful of identifying some key fields which when submitted, their value should not be omitted.  I went thru some ARs and found a lot fields missing.  Minor fileds are OK, but some like Impact, Assigned To, Priority are very important.   As the implementators at PARC, you probably only concern with ARs assigned to you.  Without having "Assigned To" filled in AR, it is difficult to get this information. 

I have created a LispAR-Submit.Form which has all the current fields in Submit window.  The purpose of this form is to use as a mail-file, people have no access to Tajo/Adobe can send this form to their designated submitters.  I recommend those fields with ** are mandatory, they have to be set.

Regarding about sorted AR files, I feel one sorted by Priority/asscending and Impact/asscending would be very usefule. Remember all ARs with priority Absoultely must be fixed prior to next release.  (We are lucky that  enumerated fileds in Priority: {Absolutely, Hopefully, Perhaps, Unlikely} are in the order of we want.)

By the way, your press file have a lot of control characters at the end, (residue from TEDIT??), I dont know whether they will be printed ok inside Interlisp, but it sure created a LOT of pages when printed under Tajo. 


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

Subject: LispAR-Submit.Form
To: 
Le.pasa, Sannella.pa
cc: 
myself

--filed at [Rose]<Lisp>Adobe>LispAR-Submit.Form


SOURCE**: 	
Name.pasa

SYSTEM/SUBSYSTEM**: 	
Communications 
NS Protocols; PUP Protocols; RS232; VAX Server; Lisp Servers; TCP/IP; Other

			
Window and Graphics 
 Window System; Library; Fonts; Printing; Color; Demos; Other

			
Operating System Support 
 Virtual Memory; General File Operations; DLion Disk; DLion Floppy; Dolphin/Dorado Disk; Processes; Keyboard; Other

			
Language Support 
 Arithmetic; Compiler, code format; Microcode; Storage formats/Mgt; Read and Print; Stack and Interpreter; Bootstrapping & TeleRaid; Diagnostics; Other

			
Programming Environment 
 Break Package; Code Editor; DWIM; File Package; History; Masterscope; Record Package; Performance Tools

			
Text 
 TEdit; TTYIN; Lafite; Other

			
Documentation 
 Tools; 1108 Users Guide; Primer; Product Descr/Tech Summary; Programmer's Introduction; Interlisp Reference Manual; Internal system documentation; Other

			
Other software 
 Installation Utility; Release Procedure; Other


MACHINE/DISK 	
1100
		
1108 
SA1000 (10MB); SA4000 (29MB); Q2040 (43MB); Q2080 (80MB); T80 (80MB); T300 (315MB); Other


STATUS**: 	
New; Wish; Incomplete

SUBJECT**:	
terse summary of problem

SOURCE FILES: 	
source moudles that are affected

LISP VERSION:	
Fugue.4; Fugue.6; Carol.1

MICROCODE VERSION: 
if 1100 or 1132, this can be the date of the .EB file, if 1108, should identify 4K or 12K

MEMORY SIZE:	
memory size

PROBELM TYPE: 	
Bug; Design-Impl; Design-UI; Documentation; Performance 

FREQUENCY: 	
Every time; Intermittent; Once

IMPACT**: 	
Fatal; Serious; Moderate; Annoying; Minor


FILE SERVER: 	
8037; IFS; VAX/VMS-3Mb; VAX/VMS-10Mb; VAX/UNIX; Other

SERVER SOFTWARE VERSION:	
Server Software Version

DESCRIPTION:  	
description of problem in more detail

TEST CASE: 	
pointer to file needed to recreate prblem
  
*start*
13645 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 13:16 PST
From: masinter.pa
Subject: illegal UFN Raid call
To: LispSupport
cc: Charnley, Purcell

I got another "unknown ufn" raid call, this one again because the PC in COMP.SELECTQ was way off.


Here is the frame:

Basic frame at   46074
  46072:       6 116304 *local* (((0 1 2) T) NIL)
  46074:  100000  46072 

Frame xtn at   46556, frame name= COMP.SELECTQ
  46556:  140001  46063 [USE= 1, X,  alink]
  46560:  160050     43 [fn header]
  46562:   46632   1662 [next, pc]
  46564:  105744     40 [nametable]
  46566:   46074  46062 [blink, clink]
  46570:       6 173326 *local* (TAG 7)
  46572:       0      0 *local* NIL
  46574:       0      0 *local* NIL
  46576:       0      0 *local* NIL
  46600:       0      0 *local* NIL
  46602:       6 116112 *local* (NIL (pushnew ALAMS1 (CADR X)) T)
  46604:       0      0 *local* NIL
  46606:       0      0 *local* NIL
  46610:   44572  13427 [fvar LBCNT  on stack]
  46612:   44654  13427 [fvar CODE  on stack]
  46614:  177777    200 [fvar EFF  not looked up]
  46616:  177777 172400 [fvar RETF  not looked up]
  46620:       0      0 [padding]
  46622:       0     33 [padding]
  46624:  177767     16 
  46626:       0  11011 FJUMP
  46630:       6 173254 (TAG 8)



and here is the code:




 stkmin:    106 na:    1 pv:    5 startpc:   70 argtype: 0 framename: COMP.SELECTQ ntsize:   10
 nlocals:   10
   0:    106
   2:      1
   4:      5
   6:     70
  10:      0
  12:  17302
  14:     10
  16:   4010
name table: 
  20:  16765     40: 140010     FVAR 8: LBCNT
  22:   1260     42: 140011     FVAR 9: CODE
  24:  16537     44: 140012     FVAR 10: EFF
  26:  17000     46: 140013     FVAR 11: RETF
  30:      0     50:      0
  32:      0     52:      0
  34:      0     54:      0
  36:      0     56:      0
Local args: 
  60:     71     64:      0     IVAR 0: A
  62:      0     66:      0

----
  70:     0  147  35 257      ACONST    TAG
  73:     1  127  20          FVARX     LBCNT
  75:     2  153              '1
  76:     3  330              IPLUS2
  77:     2  143  20          FVARX_    LBCNT
 101:     2  150              'NIL
 102:     3   32              CONS
 103:     2   32              CONS
 104:     1   21 161   7      BIND       [pvar0]; [pvar1] [pvar2] [pvar3] [pvar4] [pvar5] [pvar6] [
pvar7]
 107:     1  100              IVAR      A
 110:     2    1              CAR
 111:     2   11  35 342      FN1       COMP.VAL
 114:     2  277              POP
 115:     1  100              IVAR      A
 116:     2    2              CDR
 117:     2  142   0          IVARX_    A
 121:     2  277              POP
 122:     1  127  22          FVARX     CODE
 124:     2  144              COPY
 125:     3    1              CAR
 126:     3    1              CAR
 127:     3  140  36  57      GVAR      SELECTVARTYPES
 132:     4   34              FMEMB
 133:     3  226              FJUMP-> 143
 134:     2    1              CAR
 135:     2  271              PVAR_^    [pvar1]
 136:     1   10  35 334      FN0       COMP.DELPUSH
 141:     2  260 127          JUMPX-> 270
 143:     2    1              CAR
 144:     2    1              CAR
 145:     2  147   3 266      ACONST    SETQ
 150:     3  360              EQ
 151:     2  262  25          FJUMPX-> 176
 153:     1  127  22          FVARX     CODE
 155:     2  144              COPY
 156:     3    1              CAR
 157:     3    2              CDR
 160:     3    1              CAR
 161:     3  140  36  57      GVAR      SELECTVARTYPES
 164:     4   34              FMEMB
 165:     3  231              FJUMP-> 200
 166:     2    1              CAR
 167:     2    2              CDR
 170:     2  271              PVAR_^    [pvar1]
 171:     1   10  35 325      FN0       COMP.STPOP
 174:     2  260  74          JUMPX-> 270
 176:     1  127  22          FVARX     CODE
 200:     2    1              CAR
 201:     2    1              CAR
 202:     2  147  35 255      ACONST    CONST
 205:     3  360              EQ
 206:     2  262  60          FJUMPX-> 266
 210:     1  127  22          FVARX     CODE
 212:     2    1              CAR
 213:     2    2              CDR
 214:     2  276              PVAR_^    [pvar6]
 215:     1   10  35 334      FN0       COMP.DELPUSH
 220:     2  277              POP
 221:     1  100              IVAR      A
 222:     2  144              COPY
 223:     3    2              CDR
 224:     3  243              TJUMP-> 231
 225:     2  277              POP
 226:     1  100              IVAR      A
 227:     2  260  25          JUMPX-> 254
 231:     2    1              CAR
 232:     2    1              CAR
 233:     2    3              LISTP
 234:     2  225              FJUMP-> 243
 235:     1  116              PVAR      [pvar6]
 236:     2  100              IVAR      A
 237:     3    1              CAR
 240:     3    1              CAR
 241:     3   34              FMEMB
 242:     2  204              JUMP-> 250
 243:     1  100              IVAR      A
 244:     2    1              CAR
 245:     2    1              CAR
 246:     2  116              PVAR      [pvar6]
 247:     3  360              EQ
 250:     2  226              FJUMP-> 260
 251:     1  100              IVAR      A
 252:     2    1              CAR
 253:     2    2              CDR
 254:     2   11  36  15      FN1       COMP.PROGN
 257:     2   20              RETURN
 260: *
          2  100              IVAR      A
 261:     3    2              CDR
 262:     3  142   0          IVARX_    A
 264:     3  260 336          JUMPX-> 222
 266:     1  151              'T
 267:     2  132              PVAR_     [pvar2]
 270:     2  277              POP
 271:     1  100              IVAR      A
 272:     2    2              CDR
 273:     2  263  34          TJUMPX-> 327
 275:     1  112              PVAR      [pvar2]
 276:     2  225              FJUMP-> 305
 277:     1  111              PVAR      stkmin:    106 na:    1 pv:    5 startpc:   70 argtype: 0 framename: COMP.SELECTQ ntsize:   10
 nlocals:   10
   0:    106
   2:      1
   4:      5
   6:     70
  10:      0
  12:  17302
  14:     10
  16:   4010
name table: 
  20:  16765     40: 140010     FVAR 8: LBCNT
  22:   1260     42: 140011     FVAR 9: CODE
  24:  16537     44: 140012     FVAR 10: EFF
  26:  17000     46: 140013     FVAR 11: RETF
  30:      0     50:      0
  32:      0     52:      0
  34:      0     54:      0
  36:      0     56:      0
Local args: 
  60:     71     64:      0     IVAR 0: A
  62:      0     66:      0

----
  70:     0  147  35 257      ACONST    TAG
  73:     1  127  20          FVARX     LBCNT
  75:     2  153              '1
  76:     3  330              IPLUS2
  77:     2  143  20          FVARX_    LBCNT
 101:     2  150              'NIL
 102:     3   32              CONS
 103:     2   32              CONS
 104:     1   21 161   7      BIND       [pvar0]; [pvar1] [pvar2] [pvar3] [pvar4] [pvar5] [pvar6] [
pvar7]
 107:     1  100              IVAR      A
 110:     2    1              CAR
 111:     2   11  35 342      FN1       COMP.VAL
 114:     2  277              POP
 115:     1  100              IVAR      A
 116:     2    2              CDR
 117:     2  142   0          IVARX_    A
 121:     2  277              POP
 122:     1  127  22          FVARX     CODE
 124:     2  144              COPY
 125:     3    1              CAR
 126:     3    1              CAR
 127:     3  140  36  57      GVAR      SELECTVARTYPES
 132:     4   34              FMEMB
 133:     3  226              FJUMP-> 143
 134:     2    1              CAR
 135:     2  271              PVAR_^    [pvar1]
 136:     1   10  35 334      FN0       COMP.DELPUSH
 141:     2  260 127          JUMPX-> 270
 143:     2    1              CAR
 144:     2    1              CAR
 145:     2  147   3 266      ACONST    SETQ
 150:     3  360              EQ
 151:     2  262  25          FJUMPX-> 176
 153:     1  127  22          FVARX     CODE
 155:     2  144              COPY
 156:     3    1              CAR
 157:     3    2              CDR
 160:     3    1              CAR
 161:     3  140  36  57      GVAR      SELECTVARTYPES
 164:     4   34              FMEMB
 165:     3  231              FJUMP-> 200
 166:     2    1              CAR
 167:     2    2              CDR
 170:     2  271              PVAR_^    [pvar1]
 171:     1   10  35 325      FN0       COMP.STPOP
 174:     2  260  74          JUMPX-> 270
 176:     1  127  22          FVARX     CODE
 200:     2    1              CAR
 201:     2    1              CAR
 202:     2  147  35 255      ACONST    CONST
 205:     3  360              EQ
 206:     2  262  60          FJUMPX-> 266
 210:     1  127  22          FVARX     CODE
 212:     2    1              CAR
 213:     2    2              CDR
 214:     2  276              PVAR_^    [pvar6]
 215:     1   10  35 334      FN0       COMP.DELPUSH
 220:     2  277              POP
 221:     1  100              IVAR      A
 222:     2  144              COPY
 223:     3    2              CDR
 224:     3  243              TJUMP-> 231
 225:     2  277              POP
 226:     1  100              IVAR      A
 227:     2  260  25          JUMPX-> 254
 231:     2    1              CAR
 232:     2    1              CAR
 233:     2    3              LISTP
 234:     2  225              FJUMP-> 243
 235:     1  116              PVAR      [pvar6]
 236:     2  100              IVAR      A
 237:     3    1              CAR
 240:     3    1              CAR
 241:     3   34              FMEMB
 242:     2  204              JUMP-> 250
 243:     1  100              IVAR      A
 244:     2    1              CAR
 245:     2    1              CAR
 246:     2  116              PVAR      [pvar6]
 247:     3  360              EQ
 250:     2  226              FJUMP-> 260
 251:     1  100              IVAR      A
 252:     2    1              CAR
 253:     2    2              CDR
 254:     2   11  36  15      FN1       COMP.PROGN
 257:     2   20              RETURN
 260: *
          2 stkmin:    106 na:    1 pv:    5 startpc:   70 argtype: 0 framename: COMP.SELECTQ ntsize:   10
 nlocals:   10
   0:    106
   2:      1
   4:      5
   6:     70
  10:      0
  12:  17302
  14:     10
  16:   4010
name table: 
  20:  16765     40: 140010     FVAR 8: LBCNT
  22:   1260     42: 140011     FVAR 9: CODE
  24:  16537     44: 140012     FVAR 10: EFF
  26:  17000     46: 140013     FVAR 11: RETF
  30:      0     50:      0
  32:      0     52:      0
  34:      0     54:      0
  36:      0     56:      0
Local args: 
  60:     71     64:      0     IVAR 0: A
  62:      0     66:      0

----
  70:     0  147  35 257      ACONST    TAG
  73:     1  127  20          FVARX     LBCNT
  75:     2  153              '1
  76:     3  330              IPLUS2
  77:     2  143  20          FVARX_    LBCNT
 101:     2  150              'NIL
 102:     3   32              CONS
 103:     2   32              CONS
 104:     1   21 161   7      BIND       [pvar0]; [pvar1] [pvar2] [pvar3] [pvar4] [pvar5] [pvar6] [
pvar7]
 107:     1  100              IVAR      A
 110:     2    1              CAR
 111:     2   11  35 342      FN1       COMP.VAL
 114:     2  277              POP
 115:     1  100              IVAR      A
 116:     2    2              CDR
 117:     2  142   0          IVARX_    A
 121:     2  277              POP
 122:     1  127  22          FVARX     CODE
 124:     2  144              COPY
 125:     3    1              CAR
 126:     3    1              CAR
 127:     3  140  36  57      GVAR      SELECTVARTYPES
 132:     4   34              FMEMB
 133:     3  226              FJUMP-> 143
 134:     2    1              CAR
 135:     2  271              PVAR_^    [pvar1]
 136:     1   10  35 334      FN0       COMP.DELPUSH
 141:     2  260 127          JUMPX-> 270
 143:     2    1              CAR
 144:     2    1              CAR
 145:     2  147   3 266      ACONST    SETQ
 150:     3  360              EQ
 151:     2  262  25          FJUMPX-> 176
 153:     1  127  22          FVARX     CODE
 155:     2  144              COPY
 156:     3    1              CAR
 157:     3    2              CDR
 160:     3    1              CAR
 161:     3  140  36  57      GVAR      SELECTVARTYPES
 164:     4   34              FMEMB
 165:     3  231              FJUMP-> 200
 166:     2    1              CAR
 167:     2    2              CDR
 170:     2  271              PVAR_^    [pvar1]
 171:     1   10  35 325      FN0       COMP.STPOP
 174:     2  260  74          JUMPX-> 270
 176:     1  127  22          FVARX     CODE
 200:     2    1              CAR
 201:     2    1              CAR
 202:     2  147  35 255      ACONST    CONST
 205:     3  360              EQ
 206:     2  262  60          FJUMPX-> 266
 210:     1  127  22          FVARX     CODE
 212:     2    1              CAR
 213:     2    2              CDR
 214:     2  276              PVAR_^    [pvar6]
 215:     1   10  35 334      FN0       COMP.DELPUSH
 220:     2  277              POP
 221:     1  100              IVAR      A
 222:     2  144              COPY
 223:     3    2              CDR
 224:     3  243              TJUMP-> 231
 225:     2  277              POP
 226:     1  100              IVAR      A
 227:     2  260  25          JUMPX-> 254
 231:     2    1              CAR
 232:     2    1              CAR
 233:     2    3              LISTP
 234:     2  225              FJUMP-> 243
 235:     1  116              PVAR      [pvar6]
 236:     2  100              IVAR      A
 237:     3    1              CAR
 240:     3    1              CAR
 241:     3   34              F*start*
00543 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 14:15 PST
From: Burton.pa
Subject: Lafite: misleading  msg  AllDown
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

When restarting after a LOGOUT I got the msg "Not logged in: AllDown".  I bugged "getmail" and the prompt window showed aborted from Semillon, Riesling, and PinotBlanc because of  server full.  Maybe the error msg should say Servers full rather than AllDown?

richard

*start*
00476 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 11:09 PST
From: Halvorsen.pa
Subject: Lafite: BSP error
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dandelion

When I do a get mail and am notified that some of my mail files were open during a file server crash I often (always?) get a BSP error with the message Bad.State.For.Bout. under \BOUT under MS.RETRIEVEOPERATION
*start*
00629 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 10:02 PST
From: Burton.pa
Subject: Re: Lafite: Undelivered mail?
In-reply-to: Kaplan.pa's message of 20 Mar 84 21:03 PST
To: LafiteSupport.pa
cc: Kaplan.pa

I ran into a similar problem last week.  There were a few characters missing from the end of the address field as reported from grapevine, so I replaced those by retyping them and the missing characters moved to before the retyped characters.  I eventually fixed by deleting the entire to: field and retyping it.  Maybe a count was being interpreted differently in a piece??

richard

*start*
00571 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 09:49 PST
From: Sannella.pa
Subject: [masinter.pa: AR#112]
To: LispSupport.pa

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

Date: 20 Mar 84 11:38 PST
From: masinter.pa
Subject: AR#112
To: Sannella

This is marked Fixed, but it isn't. There is still no documentation on how to make new file devices or what constraints the various fields must take.

Assigned to: and Attn: are blank, I guess Sheil for both, since he is now 'documentation czar'.




     ----- End of Forwarded Messages -----
*start*
00916 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 23:28 PST
From: Kaplan.pa
Subject: Incorrect fontwidths for special Interpress codes
To: Lispsupport, Sybalsky
cc: Kaplan.pa

In trying to get DSPXPOSITION to work right for Interpress, I noticed that there is a glitch in the fix to INTERPRESS.OUTCHARFN.

The problem is that widths are going to be computed incorrectly when for characters that are not in character set 0.  The characters that are printed out by IPBOUTCHARCODE are measured as they go by, which isn't so cool if you are printing out the charset shift, the new charset number, etc. in this way.

Seems like here, and perhaps other places, we have to measure the width of the original 16 bit code (how do we do that?) before we print it out.

This might not matter in MAKEINTERPRESS, but INTERPRESS.OUTCHARFN and perhaps IP.PRIN3 really do care about this.

--Ron
*start*
00536 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 23:53 PST
From: Wallace.pa
Subject: Lafite: Selecting/deleting messages by reference
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

If I get a reply to some message, it contains an In-reply-to field referencing my query.  It would be nice to have commands that allowed one to:
1> jump back to the original query,
2> erecursively delete an entire conversation.


*start*
00402 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 23:38 PST
From: Kaplan.pa
Subject: TEdit: Wish that TEDIT would interface to PRINTERFILETYPES
To: TEditSupport
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 13-Mar-84 10:21:31
Machine-Type: Dorado

So that TEDIT.HCPY (or whatever) would be called when I tried to LISTFILES or EMPRESS a Tedit file.

--Ron
*start*
00760 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 22:57 PST
From: vanMelle.pa
Subject: Re: [Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>: password control]
In-reply-to: Wogulis.pasa's message of 13 Feb 84 15:57 PST
To: Wogulis.pasa
cc: vanMelle, LispSupport.PA, 1100Support.pasa

The "more direct way" to wipe out the password cache is to call (LOGIN).

But as for the other complaint, if your server is correctly generating a protection error or illegal connect password, Lisp should give you a chance to supply a connect password for the directory on which the file lives.  If you have an exception, it would be interesting to see the details, so we can plug the leak (if, indeed, the problem is at the Lisp end).

	Bill
*start*
01197 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 MAR 84 17:19 PST
From: JONL.PA
Subject: Re: Floating arith optimizatio
To:   kaplan, lispsupport
cc:   JONL

In response to the message sent  18-Mar-84  9:31:15 PST from kaplan.pa

These factors, 2 to 5, of course apply only to the low-level functions 
mentioned, but in some cases these do add up to a surprising overall 
performance degradation;  it all just goes to show critical even one "leaky 
hole in the dike" can be.  Larry has already requested an AR on the obvious 
compiler optimization, but that's still not the root of the matter.  Two 
main points spring to mind:

1) ucode, where possible, should do the coercions.  The compiler simply
   can't optimize out cases like (FPLUS X Y) where X is fixp and Y floatp.
2) system code, such as on AARITH etc, should not depend upon these
   sometime compiler/ucode optimizations.  One man calls this a matter of
   "taste" -- another sees a benchmark speedup of over 50% [yes, the loss
   in SQRT was enough to slow down Darrel's benchmark, which he claims is
   making the  popular rounds in ComputerScience circles,  from 20 secs to
   30 secs on a Dorado.

*start*
00305 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: kaplan.pa
Date: 18-Mar-84 20:06:25 PST
Subject: priorities
To: lispsupport, Masinter

I submitted my priorities to Beau last fall.  I don't think anything has changed since then; consult with him to find out what I think.

--Ron*start*
00418 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from RUTGERS.ARPA by PARC-MAXC.ARPA; 18 MAR 84 16:13:18 PST
Date: 18 Mar 84 19:13:36 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: \KEYHANDLER1
To: lispsupport.pa
cc: SHULMAN@RUTGERS.ARPA


Hi,

	I'm about the hack on \KEYHANDLER1.  How do you people modify this
in a running system?  A bunch of MOVD's?

							Jeff
-------
*start*
00415 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 17 Mar 84 17:02 PST
From: Wallace.pa
Subject: Lisp: TCP gateway service
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

IS there a TCP gateway to the ARPANET?  It would be great to be able to chat to arpa hosts, or do, say (EMPRESS '{ARPA-HOST}FILENAME).  I was told that interlisp-d does speak TCP.

david

*start*
01070 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 10:26 EST
From: Denber.wbst
Subject: Keeping up with the Joneses
To: Lafitesupport.pa

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

Date: 15 Mar 84 14:53:00 PST (Thursday)
From: PNeumeister.PA
Subject: Hack Request: CalendarMailSift
To: Manes, Karlton, Yamamoto
cc: MesaHacks^, PNeumeister

To increase the group capabilities of Calendar, it might be nice to have a hack either incorporated into hardy, or a standalone (like NewMailTune) that searches all New Mail for a reminder message from somebody other than whom the machine belongs to.  If it finds one, it should insert the reminder info into your calendar with only a pop-up reminder with a time-to-remind of something like half the time till the event..

This way, if somebody else schedules a meeting for you, sends you a reminder a day ahead of time, and you lose the message, it will show up in your Calendar and you will still be reminded(but you won't send a message to yourself).



     ----- End of Forwarded Messages -----
*start*
00841 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 10:16:59 PST (Friday)
From: masinter.PA
Subject: adobe files on [phylum]<LispCore>Adobe>
To: JFung.pasa, 1100Support, LispFriends^
cc: masinter

The "Adobe>" subdirectory of <LispCore>  (and <LispNew> and <Lisp>) will be used for staging versions of Mesa-based tools for dealing with the Adobe database. It has current versions of the following files, which you need to run adobe:

LispARs.user
LispArs.bcd
adobe-user-slice.cm  (edit into your user.cm on your mesa volume)
Adobe.bcd


These versions are all compatible only with Mesa 10.0.

(To JFung.pasa, LispSupport: I think these are the latest versions. If you have different versions of any of these files, please let me know. "adobe-user-slice.cm and LispARs.user were edited by me this morning.)
*start*
00654 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 09:01 PST
From: Sybalsky.pa
Subject: Re: TEdit: Couple of comments
In-reply-to: DMRussell.pa's message of 15 Mar 84 15:29 PST
To: DMRussell.pa
cc: TEditSupport.pa

(1) Yes there is a good reason--it prevents the functions being evaluated when you LOADFROM the file.  This is necessary if JONL's database builder is to be able to notice files without really loading them.  You should be loading the DCOM first, in any case.

(2) I think that's a great idea!  I'll try to get it into the code today, so it will be in the next release; wait for the announcement msg....
*start*
00523 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Thu, 15 Mar 84 21:18 PST
From: kiewiet.pasa
Subject: Re: [vanMelle.pa: release message addendum]
In-reply-to: "vanMelle.pa's message of 15 Mar 84 16:34 PST"
To: vanMelle.pa
cc: Raim,1100Support.pa, LispSupport.pa

Bill,

Thanks for pointing out the DLion/Dolphin sysout incompatibility.  I've had this question more than once (since I'm the "isolated Dolphin upgrade rep").  

I recommend that we put this caveat in the Release Notes.

Lorraine

*start*
02048 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:20 PST
From: Sybalsky.pa
Subject: Lisp: XSIS Network Consulting database?
To: LispSupport.pa, 1100Support.pasa
cc: Sybalsky.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado

Does 1100Support have a mechanism for internalizing messages like the one below, so they can tell other people about fixes, resources, &c?  If so, could you tell us northerners about it, so we can either refer people to you, or check things out when we get informal gripes?

Thanks

	--John

---------

Date: Thu, 15 Mar 84 09:32 PST
From: "Brand Hal"@LLL-MFE.ARPA
Subject: RSX file server
To: dolphin-users@sumex-aim.arpa

   I am pleased to announce that we have increased the performance of our RSX file server by about 1.2 orders of magnitude.   This was accomplished by dis-assembling the RSX ethernet driver (yes, they only left us the .TSK files), and then making improvements to the driver.   The major improvement was greatly increasing the speed of the transfer of the ethernet packet from the task buffer to the driver buffer (A driver buffer is necessary as the Xerox hardware can only DMA to the low 64 Kbytes).   Now we are getting transfers in both directions at 10.5 Kbits/sec. and the RSX system is nearly always busy during the transfer.   Anyone who might profit from this is invited to mail me, Hal Brand - BRAND@LLL-MFE.ARPA, and I will be glad to provide any and all details.
   My thanks to all who responded about the problem.   The notion that multiple packets we sent to the RSX machine gave me the confidence to spend the time to dis-assemble the driver in an effort to increase its through-put so as not to allow the 2nd packet to be missed.   I am no pretty sure that the problem was that the RSX handler was so slow that the 2nd packet was lost by RSX and then the dolphin had to wait 3 to 5 seconds to time-out the response to the 2nd packet before re-transmitting it.
   Again, my thanks to all.
							Hal Brand
							BRAND@LLL-MFE.ARPA

*start*
00501 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Thu, 15 Mar 84 18:04 PST
From: Raim.pasa
Subject: Re: Lisp: XSIS Network Consulting database?
In-reply-to: "Sybalsky.pa's message of 15 Mar 84 11:20 PST"
To: Sybalsky.pa
cc: LispSupport.pa, 1100Support

John,

We do not have a "mechanism" per se.  Networking issues, such as the one in your example, are managed by Phil Young who does have a paper filing mechanism for keeping track.

Do you have any suggestions?

--Marty

*start*
00638 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 15:02:37 PST (Thursday)
From: le.pasa
Subject: AR report
To: 1100Support.Pasa, LispSupport.Pa


The following numbers are the ARs that I have received from 1100Support.  these requests were  submitted.  Please verify and let me know if your requests are missing:
   96: Schlumberger doll
   97:  TCP/IP Support for Dlions  From CS.TEmin@UTEXAS-20.arpa
   98:  Reliable local file system from Syntelligence
   99:  Random Access capability from Syntelligence
   100: Removable Media from Syntelligence
   101: Bug in FUGUE PROCESSPROP from Eric Schoen
*start*
01142 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 15:19 PST
From: Sannella.pa
Subject: [obrien@Rand-Unix.ARPA (Michael_OBrien): Re: How do Dolphins determine net number?]
To: LispSupport

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

Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 15 MAR 84 11:45:23 PST
Return-path: <@SUMEX-AIM.ARPA:obrien@rand-unix>
Redistributed: Xerox1100UsersGroup^.PA
Received: from rand-unix by SUMEX-AIM.ARPA with TCP; Thu 15 Mar 84 10:48:20-PST
Date: Thu, 15 Mar 84 10:46 PST
To: kiewiet.PASA
Cc: 1100Support.PASA, 1100users@SUMEX-AIM.ARPA
Subject: Re: How do Dolphins determine net number?
In-reply-to: Your message of Thu, 15 Mar 84 10:00 PST.
From: obrien@Rand-Unix.ARPA (Michael_OBrien)

	Thanks very much for your input.  In fact someone else on the net
sent me the same info a few days after I posted my original message.  I
modified the turnaround routine in the manner you suggest and all our
Dolphins now know their correct net number (wouldn't it be nice if they
could just get it off the D0EN2 board, where it's set in switches?).

     ----- End of Forwarded Messages -----
*start*
01054 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 15:29 PST
From: DMRussell.pa
Subject: TEdit: Couple of comments
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

Question: Why are all of the X.INIT functions marked as DONTEVAL@LOAD in TEDITMENU??  (For X in '(MENUOBJ MARGINBAR THREESTATE MBUTTON) ...)
This means I must manually eval each of those guys each time I load TEDITMENU!  Is there a good reason for  this??

Comment: The TEDIT-Menu creation function (\TEDITMENU.CREATE) accepts a list of lists.  This list describes entries in the TEDITMenu being created.  Unfortunately, each user-editable field (i.e. (INSERT) fields) must be initialized by moving the pointer to each field in succession and then doing an insertion at that point.  Would it not be better to allow them to be initialized at menu-creation time?  That is, done in the same style as the (TEXT) field description?  (e.g. (INSERT "InitialValue"))

-- DMR -- 

*start*
00352 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 15:10 EST
From: Denber.wbst
Subject: TEdit: ILLEGAL ARG
To: TEditSupport.PA
TEdit-System-Date:  1-Mar-84 13:54:34
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dolphin

(TEDIT '{ICE}<LISP>LIBRARY>ICONW.DOC]

ILLEGAL ARG
0

(FONTCREATE BROKEN)
59:

			- Michel
*start*
01070 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 17:44:52 PST (Thursday)
From: Sannella.PA
Subject: Who do I send DLIONFS msgs to?
To: Sheil
cc: vanMelle, LispSupport

Yesterday, I forwarded a message (about DLIONFS) from LispSupport to all of LispCore^, explaining that since there was no person responsible for the DLIONFS, I had to send it to everyone.  Bill sent back this idea.  So, who should I send these msgs to?

----------------------------------------------------------------
Date: 14 Mar 84 16:20 PST
From: vanMelle.pa
Subject: Re: DLIONFS
In-reply-to: Sannella.PA's message of 14 Mar 84 14:40:52 PST (Wednesday)
To: LispSupport.pa
cc: vanMelle.pa

Rather than that, which will typically just result in everyone deleting the message, I would say forward it to one particular person (hound Beau to tell you who is responsible), who can at least stash them all in a distinguished mail file for the benefit of whoever gets saddled with the task ultimately.

----------------------------------------------------------------
*start*
01095 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Mar 84 17:53 PST
From: Kaplan.pa
Subject: Re: Lisp: STATS broken
In-reply-to: vanMelle.pa's message of 8 Mar 84 14:38 PST
To: vanMelle.pa
cc: Kaplan.pa, LispSupport.pa

The changed implementation of the new hasharrays WAS withdrawn--but that change to STATS apparently was missed in the withdrawal.  Sorry about that.

Actually, a new interface was installed (after the new implementation and after I had editted lots of code to take out the extra LISTs but before its withdrawal) which doesn't depend on changing the semantics of HARRAY.  I think this was suggested in one of the Monday meetings.  In the interface, which exists now and will quietly upgrade to the new implementation, the function HASHARRAY is the one that defaults to a growing hash array.  It currently returns (CONS (HARRAY )), but in the next week or so will start returning a growable hasharray datum.

Thus, the fix in STATS, which I will try to do tonight, is to replace that HARRAY with HASHARRAY, sans LIST or CONS.

Again, Sorry.

--Ron
*start*
00456 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Mar 84 17:24 PST
From: Burton.pa
Subject: Re: Lafite: edit mark character - annoyance
In-reply-to: vanMelle.pa's message of 8 Mar 84 15:29 PST
To: vanMelle.pa
cc: Burton.pa, Kaplan.pa, LafiteSupport.pa

Much better.  With the cursor the same I can even see the feedback to let me know I'm in the edit mark area so that doesn't feel like it will be an issue anymore.

richard

*start*
01871 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 15 MAR 84 10:39:54 PST
Return-path: <@SUMEX-AIM.ARPA:kiewiet.PASA@PARC-MAXC.ARPA>
Redistributed: Xerox1100UsersGroup^.PA
Received: from PARC-MAXC.ARPA by SUMEX-AIM.ARPA with TCP; Thu 15 Mar 84 10:02:43-PST
Date: Thu, 15 Mar 84 10:00 PST
From: kiewiet.PASA
Subject: How do Dolphins determine net number?
To: obrien@Rand-Unix.ARPA
cc: 1100Support.PASA, 1100users@SUMEX-AIM.ARPA

The Dolphin believes the network number that it is addressed by in any
packet it receives that it solicited (or is interested in, e.g.,
broadcast routing packets).  In particular, if it asked for the time and
got back a packet that addressed it by the correct net number, it would
believe it.  You say the reply has the correct net & host numbers, but
did you mean correct in the source or in the destination fields?  It is
possible that your time server is simply "turning around" the request
packet, but not filling in the unknown fields.  For example, the request
would have had Source address = 0#xxx#yyy; simply turning that around
would produce a reply with Destination address = 0#xxx#yyy instead of
21#xxx#yyy.

The standard practice of most low-level pup software is to fill in such
unknown fields (if the recipient knows them) before passing the packet
on to higher-level software.  If this were done in the time server case,
then when the server swapped the source and destination addresses, the
net number would have gotten filled in correctly.

If this is not the problem, we'd need more information.  In particular,
you say only that your Dolphin Alto exec didn't know the net number.
Did Lisp?

Problem reports are seen more quickly by 1100Support if you send your
query directly to us at 1100Support.pasa@Parc-maxc, rather than to
1100users@SUMEX-AIM.ARPA.

*start*
00907 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 15 MAR 84 11:45:23 PST
Return-path: <@SUMEX-AIM.ARPA:obrien@rand-unix>
Redistributed: Xerox1100UsersGroup^.PA
Received: from rand-unix by SUMEX-AIM.ARPA with TCP; Thu 15 Mar 84 10:48:20-PST
Date: Thu, 15 Mar 84 10:46 PST
To: kiewiet.PASA
Cc: 1100Support.PASA, 1100users@SUMEX-AIM.ARPA
Subject: Re: How do Dolphins determine net number?
In-reply-to: Your message of Thu, 15 Mar 84 10:00 PST.
From: obrien@Rand-Unix.ARPA (Michael_OBrien)

	Thanks very much for your input.  In fact someone else on the net
sent me the same info a few days after I posted my original message.  I
modified the turnaround routine in the manner you suggest and all our
Dolphins now know their correct net number (wouldn't it be nice if they
could just get it off the D0EN2 board, where it's set in switches?).
*start*
00259 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 18:48 PST
From: masinter.pa
Subject: please keep me posted
To: randvax!henry@Rand-Unix
cc: LispSupport, 1100Support

did PUP & LLETHER work? Can we get you a newer system?
*start*
00662 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 11:04 PST
From: vanMelle.pa
Subject: Re: Lisp: Srange occurance with Chat/Lafite
In-reply-to: Halasz.pa's message of 25 Jan 84 12:32 PST
To: Halasz.pa
cc: vanMelle, LispSupport.pa

They are likely related ("Semillon not responding" message from Lafite and Chat failing to log you in): a case of multi-process failure to interlock the use of a global pup socket.  Not a really easy problem to fix, unfortunately, but also not a serious problem (Impact = Annoying).  I did fix, however, the spurious "NIL not implemented for this host" message you get as a side effect.

	Bill
*start*
00811 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 17:38 PST
From: Martin.pasa
Subject: Re: Carol.1 10M D0 microcode?
In-reply-to: vanMelle.pa's message of 9 Mar 84 15:04 PST
To: vanMelle.pa
cc: KMatysek.henr, LispSupport.pa

I did not see the original message about copying between partitions so I do not know if this information is relevant.

One of our cutomers had a Dolphin with a 10MHz ethernet board, but was running 3MHz microcode.  He was not hooked up to a net, so it should not matter.  Right?  

Wrong.  Copyfile seems to check the ethernet for some reason even if you are just copying between partitions.  If you run the wrong microcode for the ethernet board you have in the system, COPYFILE just hangs forever.  With the proper microcode, it works fine.

Rick
*start*
00487 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 18:05 PST
From: vanMelle.pa
Subject: Re: Carol.1 10M D0 microcode?
In-reply-to: Martin.pasa's message of 9 Mar 84 17:38 PST
To: Martin.pasa
cc: vanMelle.pa, LispSupport.pa

Doesn't sound related to Kathy's problem.

The fact that Lisp hangs if you run with 3MHz ether microcode and no 3MHz ether card is a relatively simple bug in the ether startup code I hope to fix now that we're unfrozen.

	Bill
*start*
00380 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 MAR 84 16:14 PST
From: ROACH.PA
Subject: MPC 513
To:   1100SUPPORT
cc:   LISPSUPPORT

     So far, the user with MPC 513 problems with his Dandelion has
not gotten a response of any kind that I am aware of.  Is XSIS going
to bring the Dlion in or send me on a field trip?  What's the plan?
				Kelly
*start*
01068 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Sun, 11 Mar 84 16:18 PST
From: kiewiet.PASA
Subject: Re: Lisp:  Installation Utitlity does not work properly
In-reply-to: "Halasz.pa's message of 10 Mar 84 15:20 PST"
To: Halasz.pa
cc: LispSupport.pa, 1100Support.pa

MP0915 
If 0915 occurs during the installation of the software, the problem could be a bad page on the rigid disk, the system cannot read the floppy disk, or a hardware failure.  Has the floppy been used successfully in the past?  Do you ever get  the  "copying InstallLispTool.bcd. . . . .copied" message, or just the 0915 hang?

You note that your sysout date is 1-MAR 84.  There is a new Installation Utility for the 25 FEB 84 sysout, containing new InstallLispTool.bcd and Prometheus Script files.  


I repeated the Installation procedure and the MP code was always 0990, which is normal.  Please let us know if you would like a Fugue.4 installation utility
floppy disk, or the Utility we are preparing to send out with the next release.

Lorraine Kiewiet
1100Support

*start*
00354 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Fri, 9 Mar 84 16:29 PST
From: kiewiet.PASA
Subject: Re: Lisp and 10mb on Dolphin
In-reply-to: "vanMelle.pa's message of 9 Mar 84 15:55 PST"
To: vanMelle.pa
cc: kiewiet, LispSupport.pa, Vittal

Hmmm.  Thanks.  I do have a file of "things to try when I have the time"

Lorraine

*start*
00422 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Fri, 9 Mar 84 11:19 PST
From: Vittal.pasa
Subject: Re: Lisp and 10mb on Dolphin
In-reply-to: "vanMelle.pa's message of 8 Mar 84 15:53 PST"
To: vanMelle.pa
cc: Vittal, LispSupport.pa

The XMBDolphinLispMc.eb seems to work just fine.

We're still trying to figure out if X3DolphinLispMc.eb works.  I'll get back to you on it.

Thanks alot!

John

*start*
00776 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 14:56 PST
From: vanMelle.pa
Subject: Re: Lisp and 10mb on Dolphin
In-reply-to: KIEWIET.pasa's message of Fri, 9 Mar 84 12:19 PST
To: KIEWIET.pasa
cc: LispSupport, Vittal.pasa

Your problem with X3DolphinLispMc.eb appears to be a bug in the pup software--confusion when the machine is on two different nets, something we have really never tested, except with GATEWAY, which is not a very strenuous test (the bug affects BSP, which underlies CHAT and PUPFTP; possibly other things, though not GATEWAY).

Otherwise, the new microcode files look fine (the techs got my 10Mhz machine reconnected, so I've been able to run them myself as well), so I have moved them over to Lisp>Current.

	Bill
*start*
00527 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Fri, 9 Mar 84 15:17 PST
From: kiewiet.PASA
Subject: Re: Lisp and 10mb on Dolphin
In-reply-to: "vanMelle.pa's message of 9 Mar 84 14:56 PST"
To: vanMelle.pa
cc: KIEWIET, LispSupport.pa, Vittal

Bill,

Then the bug in the pup software would prevent customers using Dolphin as their Gateway between 3 and 10 from converting to 25 Feb sysout right now?  

I'm curious because a customer phoned me just Wednesday to query about such matters.  

Lorraine

*start*
00743 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 15:55 PST
From: vanMelle.pa
Subject: Re: Lisp and 10mb on Dolphin
In-reply-to: kiewiet.PASA's message of Fri, 9 Mar 84 15:17 PST
To: kiewiet.PASA
cc: vanMelle.pa, LispSupport.pa, Vittal.PASA

No, I specifically said that I do not believe the bug affects GATEWAY (it might be worth your while to try proving me wrong, though).  The bug DOES affect a user who wants to run BSP on the same machine as the GATEWAY is running.  I don't know offhand whether this is a new bug with Carol, or existed in Fugue as well (you could try it if you like, but beware that the bug is intermittent (depends on the exact sequence of network events at startup time)).

	Bill
*start*
00677 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Mar 84 17:24 PST
From: vanMelle.pa
Subject: omitted from the release message
To: LispSupport
cc: Denber.wbst

This is mainly of interest to site liaisons (do we have a list of them?): Carol makes use of the "LookupFile" protocol, where available, to speed calls to INFILEP and some related functions.  The LookupFile protocol is currently only implemented on IFS's, and then only when explicitly enabled by the IFS manager (through the "Enable LookupFile server" subcommand of the Change System Parameters command).

I noticed, for example, that the LookupFile server on {ICE} is disabled.

	Bill
*start*
00876 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Thu, 8 Mar 84 17:31 PST
From: KIEWIET.PASA
Subject: New Interlisp-D now available
To: LispSupport.pa
cc: 1100Support, KIEWIET

Regarding:  GCHAX, LLCOLOR, COLORUTILITIES, POLYGONS

My task is to gather documentation on new or updated Lisp Library or Lisp Users packages for the next Release.

Can anyone help me find, or provide, documentation on what's new or improved of the above? (Or in the case of POLYGONS, there wasn't any for Fugue4 either).  I made the assumption that the documentation belongs in the same directory as the source or compiled code we are to provide in the Release.  

On {PHYLUM}<LISP>LIBRARY> I found GCHAX.TTY dated 14 Jan83, and no entry of documentation on LLCOLOR.  On {PHYLUM}<LISPUSERS> I found COLORUTILITIES.TTY dated 12 Dec 83.

Many thanks.

Lorraine Kiewiet



*start*
00477 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 11 Mar 84 13:23 PST
From: Halvorsen.pa
Subject: TEdit: SHOW of a character gives you show of the paragraph as well
To: TEditSupport
TEdit-System-Date:  1-Mar-84 13:54:34
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dandelion

If you select a character and do a show in the character section of the expanded you also get the para looks displayed, and the display scolls down to the marginbar.  
*start*
00516 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 11 MAR 84 12:18 PST
From: ROACH.PA
Subject: Re: Lisp: file with name 10
To:   JonL, LispSupport
cc:   TEditSupport, ROACH

In response to the message sent  10 Mar 84 17:49 PST from JonL.pa

     I think the last time this got discussed, Ron pointed out reasons
(e.g. FILEPACKAGE) why filenames should be litatoms.  Naturally, |10|
could be a litatom, but there don't seem to be enough votes in
LISPSUPPORT for biting the bullet.
				Kelly
*start*
00525 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 11 Mar 84 12:08 PST
From: Halvorsen.pa
Subject: TEdit: State inhereted by new expanded menus
To: TEditSupport
TEdit-System-Date:  1-Mar-84 13:54:34
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dandelion

More along the lines of Jim's observations regarding reused windows.  When you give a tedit window a new expanded it gets the state of another expanded menu, if you have one.  It would be preferable if came up with the default options.  
*start*
00516 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Mar 84 16:34 PST
From: desRivieres.pa
Subject: TEdit: scrubbing the windows
To: TEditSupport
cc: desRivieres.pa
TEdit-System-Date:  1-Mar-84 13:54:34
Lisp-System-Date:  5-Mar-84 16:21:20
Machine-Type: Dorado

When Tedit reuses a window (a feature which I like), it is important that the window is completely clean.  It appears that at present some state from the last editing session is being missed; e.g., the default font.

---Jim   
*start*
00903 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Mar 84 15:42 PST
From: JonL.pa
Subject: Lisp: BROWSER's "boxing"
To: LispSupport.pa
cc: JonL.pa
Lisp-System-Date:  7-Mar-84 13:56:45
Machine-Type: Dorado

It appears as though BROWSER is doing a depth-first search when it constructs its "paths" tree;  I'd prefer a breadth-first.  Example -- 


This is the current structure:

        -BoxedFn1
       /
TopFn----BoxedFn2
       \
        -UnboxedFn3--BoxedFn2--BoxedFn1--UnboxedFn4--BoxedFn2


This is what I'd rather see

        -BoxedFn1--UnboxedFn4--BoxedFn2
       /
TopFn----BoxedFn2--BoxedFn1
       \
        -UnboxedFn3--BoxedFn2


The latter format gives preference to the topmost&leftmost "boxed" instance of a function node as being the primary node for that funciton; the other "boxed" nodes with the same label can then be viewed as "continuation" pointers.
*start*
00988 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 MAR 84 22:55 PST
From: MASINTER.PA
Subject: string streams etc.
To:   lispcore^
cc:   lispsupport

(a) let us keep design decisions on LispCore^, and bug reports on LispSupport. (This will be more important later)
(b) if this change were innocuous, it would not cause any shared programs to break. "RIP -10 etc" is irrelevant.
(c) I can think of one read macro in the system for which this change is not innocuous, namely the NORMALCOMMENTSFLG readmacro.

Passing the original argument is not reasonable because the readmacro handler no longer knows the original arg, and it may have been coerced from some odd, incomplete form. Passing the FULLNAME if it is a LITATOM and otherwise the stream might be reasonable, although adhoc. Passing the stream, and fixing NORMALCOMMENTSFLG is possibly acceptable. Changing FULLNAME of string streams to return the tail of the string yet unread is another possibility.
*start*
00408 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 17:16 PST
From: Roach.pa
Subject: Lisp: <LISP>CURRENT>CAROL1RELEASE.TEDIT
To: LispSupport.pa
cc: Roach.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dandelion

     Austin Henderson points out that STRPOS & STRPOSL
in the text "BSEARCH contains new definitions for ..." should be BSTRPOS & BSTRPOSL.
					Kelly


*start*
01831 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 MAR 84 20:43 PST
From: JONL.PA
Subject: BSTRPOS versus STRPOS in release message
To:   Roach
cc:   AHenderson, LispSupport


Re: your message of 9 Mar 94 17:16 PST

Omigosh!  the documentation is right, and the file wrong!

I'm quite certain that I sent out a note to LispFriends near the first 
of January, and copied BSEARCH to <Lisp>Library> then;  but I can't find 
any copy of that "announcement" in the <BLISP> mails.  Unfortunately, the
version that appeared recently was, of course, the copied version from
<LispCore>Library> (which had other bugs in it too).

Mea Culpa, for leaving "dead" code on <LispCore>Library> -- this automated
movement is working directly at odds with the use of <LispCore> as a "staging"
place for partly-baked software.  Below is a partial copy of a 21 Jan message 
that indicates I had d"released" BSEARCH before then.


Date: 21 JAN 84 00:58 PST
From: JONL.PA
Subject: new WHEREIS -- where *should* it be?
To:   Stansbury
cc:   Kaplan, LispCore^, Lichtenberg.wbst

In response to the message sent  20 Jan 84 14:25 PST from Stansbury.pa

Ah, you're right.  What to do for things that need some "staging",
but are intended as preliminary versions of new system functions?  I don't
just want to stick this thing in the system without someone else trying it?
. . . . . . . . . . 

The BSEARCH files was in the same category (contains new definitions for
STRPOS, STRPOSL, as well as a new funciton BFILEPOS), and I moved it to
<Lisp>Library> myself since I consider it "readY" for widespread use.
But I'm not so sure about the new WHEREIS -- I'd rather see if someone
else around here would try it a time or two before letting it either
(1) go out as a temporary lispusers package, or (2) be installed in
the system.

*start*
00650 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 16:31 PST
From: Halasz.pa
Subject: Lisp: Documentation of MP Codes on DLION
To: LispSupport.pa
cc: 
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dandelion

It sure would be nice if the documentation of the MP Codes for the 1108 were accurate and up to date.  Two of the most common MP codes (i.e., 9318 and 9024) are not listed in {PHYLUM}<LISP>CURRENT>DLMPCODES.TXT.  At minimum this would improve users' ability to report problems that they encounter, and thus make LispSupport's job easier.  It would also help us to debug our own code/problems.


Frank
*start*
00400 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 15:54 PST
From: Burton.pa
Subject: Re: Lisp: Blinking caret upon return from sysout
In-reply-to: vanMelle.pa's message of 9 Mar 84 12:53 PST
To: vanMelle.pa
cc: LispSupport.pa, Halasz.pa

Thanks for finding this.  I fixed it as you suggested.  There is a new version of LLDISPLAY on <lispcore>sources>.

richard

*start*
00378 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 15:28 PST
From: dmrussell.pa
Subject: Lisp: Bad Compiled Function
To: LispSupport.pa
cc: dmrussell.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

In LispCore>Next>FULL.SYSOUT

Can't load {PHYLUM}<LISPUSERS>BROWSER.DCOM
because of "Bad Compiled function NUMSPATHS"

-- DMR -- 
*start*
00376 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 15:25 PST
From: Wallace.pa
Subject: TEdit: check load.tedit
To: TEditSupport
cc: Wallace.pa
TEdit-System-Date:  8-Mar-84 21:33:43
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

... to see if when called with (lt T NIL NIL NIL) the user doesn't load ABC.  seems to be so.

Greg
*start*
00523 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 15:03 PST
Sender: gascon.pa
Subject: TEdit: PROMPTFORWORD
To: TEditSupport
from: nuyens
TEdit-System-Date:  8-Mar-84 16:30:36
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dandelion

Promptforword is not returning at all.  It is as though the tty can't find the promptwindow.  With the current wedged state of the tedit menu buttons, it means that it is not possible to save without ^b'ing and explicitly putting the file.  

Greg
*start*
00646 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 15:04 PST
From: vanMelle.pa
Subject: Re: Carol.1 10M D0 microcode?
In-reply-to: KMatysek.henr's message of Fri, 9 Mar 84 15:17 EST
To: KMatysek.henr
cc: LispSupport.pa

There are now up to date versions of XMBDolphinLispMc.eb and X3... on {Phylum}<Lisp>Current>.  Sorry for the confusion.

We have not observed problems copying from one partition to the other, but this is not something that we exercise very heavily, either.  If you find no hardware problems we may want to look at this a little closer, especially if you get any consistent behavior.

	Bill
*start*
01077 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Fri, 9 Mar 84 15:17 EST
From: KMatysek.henr
Subject: Carol.1 10M D0 microcode?
To: LispSupport.pa
cc: KMatysek

It appears that the Carol.1 XMB and X3 microcode for the dolphin have not been issued on {Phylum}<Lisp>Current> (current file dates are 5-Oct-83 & 1-Nov-83).

Also, we appear to be having a problem using COPYFILE on an 1100 on a 10M net and I'm not sure if it's a problem with the disk or a possible problem with COPYFILE (using Fugue). When copying a file from one partition to the other (using Copyfile or Copybytes), the Sysdir of the other partition is getting mangled causing the next operation to that partition to break with a "hard disk error". Running scavenge fixes it some of the time - other times, we've had to erase the disk and start from scratch to fix the problem. We've been using copyfile and copybytes on another 1100 without any problems, so I suspect that we have a hardware problem. I was just wondering if this may have been experienced elsewhere.

Thanks,
Kathy

*start*
00444 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Mar 84 16:11 PST
From: Halasz.pa
Subject: Lisp: Blinking caret upon return from sysout
To: LispSupport.pa
cc: 
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dandelion

After returning from a sysout, the blinking caret does not appear.  You can type into the to p level tty window, but the caret does not appear until you do some action like a login.


Frank

*start*
01118 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 12:53 PST
From: vanMelle.pa
Subject: Re: Lisp: Blinking caret upon return from sysout
In-reply-to: Halasz.pa's message of 8 Mar 84 16:11 PST
To: LispSupport.pa
cc: Halasz.pa

I suspect this is because \CARETFLASHTIME is garbage over logout.  Richard: suggest putting a (\CLOCK0 \CARETFLASHTIME) into the display device's afterxxx eventfn.

This is a general problem, that timers do not always "expire" over logout.  The process code assures that any process waiting on a timer does wake up after logout, but privately maintained timers escape this.  The problem is worst on the Dandelion, whose millisecond timer starts out at zero when you boot Lisp.  The Dolphin and Dorado currently inherit the Alto's millisecond timer, which is not zeroed at startup, and which generally increases along with the date.  However, if you logged out on a Dolphin and came back 25 days later to resume that memory image, you'd observe the same caret lossage, I believe.  Might even be true if you booted a sysout 25 days after it was made.

	Bill
*start*
00566 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Mar 84 15:34 PST
From: masinter.pa
Subject: Lisp: FLOPPY loses space in FILE RESOURCES EXCEEDED
To: LispSupport.pa
cc: masinter.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dandelion

If in the course of writing files on a floppy you get FILE  SYSTEM RESOURCES EXCEED, and you abort out of it, the file is closed, does not appear in the directory, but the space isn't there either.

I would think that the file should be inserted in the directory at OPEN time, not close, no?

*start*
02407 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Mar 84 16:00 PST
Sender: Dering.pasa
Subject:   New Floppy Functions
To: Roach.pa
From: Dering
cc:1100Support,LispSupport.PA,Dering

System: FEB-25 Sysout

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

Kelly,

I have been assigned the task of preparing documentation on FLOPPY device for distribution to customer sites.  I  would appreciate your help with the following questions.

1.  Are FLOPPY.LENGTHS and FLOPPY.ALLOCATIONS intended to be user functions?  If so, shouldn't we document what they return?  Also, these functions do not appear to notice if  the floppy  door has been opened since their last call.

2.  (FLOPPY.WAIT.FOR FLOPPY T)  also does not "notice"  the floppy door has been opened.  If you call this function, change the floppy, and do DIR {FLOPPY}*  the directory of the previous floppy is returned.  If you open and close the floppy drive door and the do DIR the correct directory listing will be returned.

3.  (FLOPPY.CAN.READP) returns T if there is a floppy in the drive;  (FLOPPY.WAIT.FOR.FLOPPY) returns NIL.  The documentation implies they are equivalent.

4.  I have been unable to use FLOPPY.SCAVENGE to restore files that have been deleted from the floppy.  The problem is manifested in two forms.  On a floppy on which formatting and copying of files was done in Mesa,  (FLOPPY.SCAVENGE) breaks with the message "NIL - ARG NOT LIST" (LISTPUT BROKEN) .  The arguments to LISTPUT have the following values:  LST=nil  PROP=version VAL=nil.  After the unsuccessful scavenge any operation on the floppy results in the error (LISTPUT BROKEN).
(FLOPPY.SCAVENGE) on a floppy created entirely in the 25-FEB sysout did not break.  The deleted file was restored and could be loaded.  However,  no additional files could be written  on the floppy.  A  DIR listed a new file ?0001 and FLOPPY.LENGTHS  showed a file of 1936 pages.

5.  Finally could you clarify the documentation on (FLOPPY.RESTART), in particular what is meant by  "A last resort way to try to restart {FLOPPY] if you think {FLOPPY} IS smashed."  Does this mean the user should execute this function if he thin the code that support the {FLOPPY} device has been damaged somehow, e.g. some global variable has been unintentionall redefined?  Why should you try opening and closing the floppy drive door first?  

Thanks for any help you can provide.


Judy   *start*
00518 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Mar 84 15:29 PST
From: vanMelle.pa
Subject: Re: Lafite: edit mark character - annoyance
In-reply-to: Burton.pa's message of 7 Mar 84 16:04 PST
To: Burton.pa, Kaplan
cc: LafiteSupport.pa

I tend to agree that the cursor is a lousy one.  To try out the behavior of not changing the cursor, try (SETQ LA.RIGHTARROWCURSOR DEFAULTCURSOR).  If you agree that's better (I think I like it better), then I'll throw out the cursor changing.

	Bill
*start*
00564 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Mar 84 18:00 PST
From: Burton.pa
Subject: Re: New Interlisp-D now available
In-reply-to: KIEWIET.PASA's message of Thu, 8 Mar 84 17:31 PST
To: KIEWIET.PASA
cc: LispSupport.pa, 1100Support.PASA

The documentation on LLCOLOR hasn't changed since Dec 82 and is on <lisp>library>color.txt.  The files llcolor, color, hlcolor and colordemo are a set which is documented in color.txt.  The changes to LLCOLOR were updates due to changes in low level of Interlisp-D and bug fixes.

richard

*start*
00653 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Mar 84 17:51 PST
From: vanMelle.pa
Subject: Lisp: Masterscope RENAME glitch
To: LispSupport.pa
Lisp-System-Date: 25-Feb-84 17:23:38
Machine-Type: Dorado

With DEFAULTRENAMEMETHOD = MASTERSCOPE, if I call

(RENAME x y 'FIELDS file)

I get the response
Warning --x is also used as (FIELDS)

and it prompts me to approve every replacement.  Normally it only does this when x is used as more than one filepkg type.  Here it seems to think FIELDS is not FIELDS.  I've only noticed this recently, but it's happened more than once.  The previous time was with type VARS.

	Bill


*start*
00306 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 MAR 84 23:08 PST
From: JONL.PA
Subject: Re: Lisp: Masterscope RENAME glitch
To:   vanMelle, LispSupport
cc:   JONL

In response to the message sent   8 Mar 84 17:51 PST from vanMelle.pa

I'm having the same trouble with FNS !
*start*
00319 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 MAR 84 18:36 PST
From: JONL.PA
Subject: DIR FOO;6 DELETE
To:   LispSupport

This also deleted FOO.DCOM;6 (which unfortunately wasn't coordinated with
FOO;6).  If I'd wanted that behaviour, I'd have said
DIR FOO*;6 DELETE

25-Feb-84 Sysout
*start*
00812 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 MAR 84 19:16 PST
From: JONL.PA
Subject: Re: DIR FOO;6 DELETE
To:   JONL, LispSupport

In response to the message sent   8 MAR 84 18:36 PST from JONL.PA

Ahhh, I see now a "consistent" reading of the documentation on the DIR
p.a. command which explains this behaviour:  "... * and * as the default
extension and default version respectively".

Even though this is modeled after the TENEX DIR command, I'd much prefer 
that NO default extension be supplied.   I.e., I like the model of the "List" 
command on IFS's better.


Since the question came up in the context of a DELETE, it might
be worth asking if some re-constituted DEL command could be devised; in
particular, it would supply no "defaults" for extensions, versions etc.

*start*
00755 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 MAR 84 18:54 PST
From: JONL.PA
Subject: More DIR bugs and glitches
To:   LispSupport

DIR MACH*.  
lists only the source files and not the .DCOMs

DIR MACH*.DCOM
lists only the .DCOMs and not the sources

But . . .

DIR (MACH*. + MACH*.DCOM)
lists each .DCOM file twice in addition to the source files


Also, the manual doesn't say anything about DIRECTORY being limited in
Interlisp-D, yet the TRIMTO and OLDVERSIONS commands don't work

Finally, when the filename-plus-version is longer than about 20 characters,
an extra line is inserted before printing the "other" data such as
creationdate.  Why?  The ttywindow here is amply wide to accommodate many
more characters.

*start*
00679 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 MAR 84 18:45 PST
From: ROACH.PA
Subject: Re: Dering.pasa
To:   masinter, lispsupport, 1100support.pasa
cc:   ROACH

In response to the message sent   8 Mar 84 16:20 PST from masinter.pa

     As I've mentioned to Judy in a separate communication, all
the functions {PHYLUM}<LISP>CURRENT>FLOPPY.TTY other than
FLOPPY.LENGTHS & FLOPPY.ALLOCATIONS are public, relatively stable,
and tend to be necessary in one way or another.  Most are peculiar
to {FLOPPY}.  Abstracting out a function like FREEPAGES is a real
possibility.  Other candidates might be SCAVENGE, GETFDEVINFO, and
SETFDEVINFO.
				Kelly
*start*
00840 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Mar 84 21:09 PST
From: Bobrow.pa
Subject: TEdit: Appending CR, seeing TABS
To: TEditSupport
cc: Bobrow.pa
TEdit-System-Date:  1-Mar-84 13:54:34
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

I started with a large Bravo document, {IVY}<BOBROW.  To reformat, I wanted to add lines in between old references at the back of the vita.  To do this I put the.  I sometimes got random stuff in my display, and sometimes got an ERROR PULLING TEXT FROM TOO SHORT A LINE
in TEDIT.CR.UPDATESCREEN
in TEDIT.INSERT.UPDATESCREEN.

Problem compounded when window is relatively narrow (e.g. 5 inches)

Also, look at {IVY}<BOBROW>DGBVITA84.TED.  On the screen the tabs look funny (e.g. at Lecturer Stanford University), but they hardcopy OK (and vice versa).
danny
*start*
00846 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Mar 84 23:18 PST
From: Kaplan.pa
Subject: Lafite: BSP error
To: LafiteSupport.pa
cc: Kaplan.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date:  2-Mar-84 15:25:21
Machine-Type: Dorado

I got a BIN.TIMEOUT error underneath GV.READCONNECT (with NAME argument GV.READCONNECT) under LOCATESOCKETS under GV.STARTSEND.

I don't really doubt that the timeout actually happened, but I don't see why the naive user ought to have this particular break inflicted on him.  Isn't there a more graceful way of recovering from this kind of situation?--e.g. embed the whole thing in an NLSETQ and quietly go on to some other server?

In general, problems in background activities (like sending a message) shouldn't get into weird (i.e. not secretary-proof) states.

--Ron


*start*
00480 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Mar 84 23:23 PST
From: Bobrow.pa
Subject: Lisp: New non feature in Pop up menus
To: LispSupport.pa
cc: Bobrow.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

Pop up menus with lists longer than the screen always come up with their bottom cut off.  One used to be able to use the right button to move these menus up.  The right button now acts the same as the rest of the buttons.
danny
*start*
00317 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 MAR 84 23:38 PST
From: JONL.PA
Subject: INIT.KSA
To:   Kaplan
cc:   LispSupport, KSA^

I've fixed {Phylum}<Lisp>Current>INIT.KSA  (and also .KSALISPCORE) to
have the STARFONTDIRECTORIES set up the way you did it for INIT.CIS
last week.

*start*
00708 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 11:42 PST
From: Nuyens.pa
Subject: [Wallace.pa: Multiple readtables?]
To: TEditSupport
cc: Nuyens.pa

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

Date: 28 Feb 84 17:25 PST
From: Wallace.pa
Subject: Multiple readtables?
To: Nuyens

Is there any plan in tedit to have multiple readtables?
(Readtables are what you use to dispatch commands, right?)
I would like to have, say, a default readtable, and allow
"modes" (a la emacs, au cours) to bind the command table
to their own set of key bindings.

So: do I want to do this myself, or do you think it's worth
putting into tedit?

david


     ----- End of Forwarded Messages -----
*start*
00480 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 13:58 PST
From: vanMelle.pa
Subject: Re: Lafite: BSP error
In-reply-to: Kaplan.pa's message of 8 Mar 84 23:18 PST
To: Kaplan.pa
cc: LafiteSupport.pa

I agree.  This whole chunk of code needs some going over for wrapping NLSETQ's in the right places.  Would benefit a lot from a better error mechanism, of course: you want to quietly swallow some errors, but not necessarily all errors.

	Bill
*start*
00451 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 12:11 EST
From: Denber.wbst
Subject: Re: Lisp: Loading problems
In-reply-to: Burton.pa's message of 8 Mar 84 14:24 PST
To: Burton.pa
cc: Hannaway.wbst, LispSupport.pa

Yup that was it alright.  So I'm a schmo.  I *did* read the Carol release notes which said all that was new was the sysout, so when Carol.1 came out I figured ... (excuses, excuses).

			- Michel
*start*
00299 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 12:31 EST
From: Denber.wbst
Subject: Re: omitted from the release message
In-reply-to: vanMelle.pa's message of 8 Mar 84 17:24 PST
To: vanMelle.pa
cc: LispSupport.pa

OK - I just turned it on on Ice.

		- Michel
*start*
00410 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 14:05 PST
From: TBigham.es
Subject: Lisp: Hardcopyw on Product Printers
To: LispSupport.pa
cc: TBigham.es
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dolphin


Should a rotation of 90 in HARDCOPYW make a printout  on an 8044 portrait rather than landscape?  I can't seem to make and output other than landscape.




*start*
00556 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Mar 84 14:51 PST
From: vanMelle.pa
Subject: Re: Lafite: "Re: <mumble>"
In-reply-to: Wallace.pa's message of 9 Mar 84 14:22 PST
To: Wallace.pa
cc: LafiteSupport.pa

True, but the In-Reply-To: field is not evident in the table of contents.

Are you really offended by the "Re:"?  Considering that the Answer commands of all the other mail systems I am familiar with (Laurel, Hardy, MSG, MM) insert a "Re:" in their reply subjects, there must be a few people who like it.

	Bill
*start*
00412 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 12:38 PST
From: vanMelle.pa
Subject: Lisp: get rid of FLOPPY.MODE
To: LispSupport.pa

Lisp System Date: 29-Mar-84 17:34:40
Frequency: Always
Impact: Moderate
Problem Type: Design UI

Floppy should infer its mode in all normal cases.  The user can but get it wrong, and get confused should the mode have been set incorrectly.
*start*
01089 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 APR 84 13:50 PST
From: ROACH.PA
Subject: Renewed plea that AR180 be fixed.
To:   LISPSUPPORT

     If letting you know a user's priorities will influence the TEDIT
debugging effort in any way, I would like to renew my plea that AR180
be fixed.  This is the bug concerning TEDIT's moving the caret around
when you do SETFILEPTR on a textstream and remains my #1 complaint.
It seriously affects the behaviour of commands like DEL, ^P, and ^N in
<LISPUSERS>EMACS.DCOM.  Quote from Brian Smith:

     "For example, ^P and ^N take a long time ... they display the
caret at the end or beginning of the line they are moving to, which
suggests an extra re-display is happening."

David Wallace has noted this behaviour to me, and Jim DesRivieres sent
you AR180.  The Difficulty field of this AR is marked Easy, but the
bug has been around for some time now, and hasn't always existed
(you introduced it when you fixed another of SETFILEPTR's bugs).  I'm
hoping that this bug will get some needed atention.

				Kelly
*start*
00447 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 15:10 PST
From: sybalsky.pa
Subject: Re: TEdit: possible find death
In-reply-to: Nuyens.pa's message of 29 Mar 84 22:42 PST
To: Nuyens.pa
cc: TEditSupport.pa

FIND is not related to fonts; I couldn't get it to reporduce the non-finding problem.  NB however that FIND is case sensitive.  So it might be that the guy tried to find "ERR" and couldn't find "err".
*start*
00953 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 APR 84 15:15 PST
From: JONL.PA
Subject: Need an AR on the default handling of errors propogating to top-level in processes
To:   LispSupport
cc:   vanMelle, Bobrow, Tong

Danny has often been "befuddled" by some computation which was started
underneath the MOUSE process (started from an INSPECTor?), but which
subsequently dies from an error.  Not being able to distinguish between
a process which successfully completes and one which commits an error and
is thereby killed (by the default for the RESTARTABLE prop), he has taken
to setting NLSETQGAG to NIL.

The system really won't run properly, in many places, with NLSETQGAG = NIL,
for a common strategy is to do (CAR (NLSETQ (WIN-OR-RETURN-NIL))).

Possibly a change to the default processprop RESTARTABLE so that a
BREAK is run; of course, a prop of NIL would still mean "kill", and YES
would still mean "restart".

*start*
00456 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 09:48 PST
From: Burton.pa
Subject: Lisp: \WIN macro
To: LispSupport.pa
cc: lispcore^
Lisp-System-Date: 29-Mar-84 17:34:40

There is a macro for \WIN that is making it into the loadup.  It is something like (SIGNED (create word ...) BITSPERWORD).  It appears to be trying to create a +-2^15 integer which is different from the \WIN macro that comes with ABC.  
richard

*start*
00315 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 10:40 PST
From: sybalsky.pa
Subject: Re: Lisp: \WIN macro
In-reply-to: Burton.pa's message of 3 Apr 84 09:48 PST
To: Burton.pa
cc: LispSupport.pa, lispcore^.pa

Guilty!  I've changed the name of mine, and made it local.  Sorry.
*start*
00565 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 15:44 PST
From: vanMelle.pa
Subject: Lisp: (HELP n --) prints wrong error message
To: LispSupport.pa
cc: vanMelle.pa

Lisp System Date: 29-Mar-84 17:34:40
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Annoying

If the first argument to HELP is a number, the error message printed in the break window appears to be interpreting that number as an error number.  Thus, for example, (HELP 5 "FOO") prints HARD DISK ERROR / "FOO".
*start*
00883 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 APR 84 16:04 PST
From: ROACH.PA
Subject: (RPAQQ HELPFLAG BREAK%!) doesn't work right
To:   LISPSUPPORT
cc:   ROACH

     I've been told that my
	(MOVD 'TRUE 'BREAKCHECK)
is undesirable because of NLSETQ forms in the system code.  Jon L White
suggests I set system global HELPFLAG to BREAK!--a strategy I've tried before.
According to the IRM (p 9.11) "If HELPFLAG=BREAK!, a break will always occur
following an error."  If only it were true.  Doing
	(RPAQQ HELPFLAG BREAK%!)
doesn't work as advertised.  I can get interaction like

	52_(FOOBAR X)

	UNDEFINED CAR OF FORM
	FOOBAR

	53_HELPFLAG
	BREAK!

without breaking.  I am therefore still stuck with the
(MOVD 'TRUE 'BREAKCHECK), must redefine SMARTARGLIST, and count on
the SINGLEFILEINDEX package to work properly.
     Impact _ Annoying
				Kelly
*start*
00483 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 17:27 PST
From: Cooper.pa
Subject: fixed ARs 218 and 219 (NSCREATEDIRECTORY)
In-reply-to: LispSupprt.pa's message of 21 Mar 84 12:13:29 PST (Wednesday)
To: LispSupport.pa

The latest version of NSFILING fixes these two bugs. Attempts to create a directory some of whose intermediate directories do not exist, and attempts to create a directory that already exists, generate BAD FILE NAME errors.
*start*
00383 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 14:55 PST
From: sybalsky.pa
Subject: Re: AR 407: TEDIT.INCLUDE should take STREAM arg instead of TEXTOBJ
In-reply-to: LispSupport.pa's message of 31 Mar 84 13:36:21 PST (Saturday)
To: LispSupport.pa
cc: Sybalsky.PA, Nuyens.PA

TEDIT.INCLUDE alkways would take a stream; I've changed the arglist.
*start*
01135 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 APR 84 17:37 PST
From: JONL.PA
Subject: AR 294 re-vivified!
To:   LispSupport
cc:   Stansbury, Tong

Yesterday I "declined" this AR, but after talking it
over with Tayloe, it indeed does appear to be the case that this particular
instance will work with "indirection" -- the condition must be that the
"name" for the definition must be exactly the name for the function which
MAKEFILE uses to output the definition on the file.

Thus, e.g., ASSOCRECORD has this property, since that is the name for the
kind of record and its definition will appear on a fil as
(ASSOCRECORD <foobar> ...)
whereas BITMAPS won't work because BITMAPS is the filepkg name for the
definition, but it is output on a file by MAKEFILE as
(RPAQ <foobar> ...)

In light of all this, I'm attempting to add this "indirection" feature
to SINGLEFILEINDEX, for records to indirect through the value of
CLISPRECORDTYPES, to be in the next version on [Phylum]<LispCore>Library>.
There is a protocol that governs what goes on CLISPRECORDTYPES, and it
gurantees the abovementioned property.
*start*
00416 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 10:55 PST
From: Burton.pa
Subject: Lisp: GETSTREAM - strange error msg
To: LispSupport.pa
Lisp-System-Date: 29-Mar-84 17:34:40

I mistaken had  (GETSTREAM FILE 'STREAM) in my code.  FILE was NIL and (OUTPUT) was {DSK}file.tmp.  The error message I got was "file not open" {PHYLUM}<PAPERWORKS>file.tmp.  Wrong host/dir.

richard

*start*
00331 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 10:45 PST
From: Guibert.pa
Subject: Re: Lafite: Reply-to field for messages sent to DLs
In-reply-to: vanMelle.pa's message of 2 Apr 84 16:44 PST
To: vanMelle.pa
cc: Guibert.pa, LafiteSupport.pa

Thanks Bill.  Glad to see it's on your list.

~j
*start*
00466 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 APR 84 18:31 PST
From: JONL.PA
Subject: flaky file names
To:   LispSupport

1) Please delete <Lisp>Library>GCHAX.TTY so that it isn't inadvertently
   distributed with the release.  (Bill has recently produced GCHAX 
   documentation with extension .press and, I think, .bravo or .ted)
2) I renamed <Lispcore>fugue6>doc>Figue..  to be <Lispcore>fugue6>doc>Fugue...
   an obvious typo.

*start*
00934 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 17:05 PST
From: Jellinek.pa
Format: TEdit
Subject: Lisp: PAINTW
To: LispSupport.pa
cc: Jellinek.pa
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dolphin

If you left-button Paint in a window which has a DSPCLIPPINGREGION smaller than the actual size of the window, then left-buttoning again inside the window, but outside of the clipping region, brings up the WindowMenu and not the Paint menu.  Thus, you can have multiple instances of PAINTW running in the same window.

As Richard says, perhaps there should be two "clipping" regions per window - one, the actual region of the window, and the other used for clipping lines, etc.  The window software would maintain the first, and users could safely tweak the other to their hearts' content.
	Herb
Â
TIMESROMAN
TIMESROMAN<
TIMESROMANz·*start*
00898 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 17:18 PST
From: Cooper.pa
Subject: Re: AR 409: Update Interlisp-D to Services 8.0 protocol
In-reply-to: LispSupport.pa's message of 31 Mar 84 13:52:24 PST (Saturday)
To: Masinter
cc: vanMelle, Cooper, LispSupport

I looked at the Services 8.0 documentation in Larry's office. I still need to look at the latest Courier specs for these protocols. Also, I need to know which servers are running Services 8.0 so that I can try using them from Lisp.

Right now it looks like only minor changes (if any) will be necessary on the Lisp side regarding credentials.

The changes to Filing may enable us to improve the performance of NSFILING. They now support version numbers (so no more horrible enumeration on every open) and lookup by pathname (eliminating the directory-by-directory walk down the tree).

					Eric

*start*
00539 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: MASINTER.pa
Date:  3-Apr-84 22:14:44 PST
Subject: Re: AR 409: Update Interlisp-D to Services 8.0 protocol
In-reply-to: Cooper's message of 3 Apr 84 17:18 PST
To: Cooper
cc: Masinter, vanMelle, LispSupport

The message in the AR Update to System Test includes the names of the servers which run Services 8.0. We also have the "Inhouse installation of Services 8.0" document I think which will allow us to bring it up on our file server or some otehr workstation.
*start*
00513 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 10:55 PST
From: Cooper.pa
Subject: Re: AR 409: Update Interlisp-D to Services 8.0 protocol
In-reply-to: MASINTER.pa's message of 3-Apr-84 22:14:44 PST
To: MASINTER.pa
cc: Cooper.pa, vanMelle.pa, LispSupport.pa

Could you please forward me a copy of the message containing the list of Services 8.0 servers? I never saw it.

Also, do you think we can change Phylex over without destroying the existing file system?

							Eric
*start*
00478 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 11:25 PST
From: vanMelle.pa
Subject: Re: new Lafite
In-reply-to: Denber.wbst's message of 3 Apr 84 10:42 EST
To: Denber.wbst
cc: LafiteSupport.PA

True, but DEL is standardly an interrupt character, and messing with interrupt chars is a pain.  Actually, any control character aborts it; I could have said "Hit BS to abort".

I believe this version runs in <Lisp>Current>Lisp.sysout as well.
*start*
01124 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 13:59 PST
From: Kiewiet.pasa
Subject: [vanMelle.pa: 
Re: AR#351: Lafite MessageHardcopier and HardcopyW break with unclear error message]
To: VANMELLE.PA
cc: 1100Support, LispSupport.pa

Bill,

Let's cancel the AR.

Yes it certainly seems that hardware was suspect.  The processor sits in my 9x12 office with a DLion processor and NO air conditioning on weekends.  (I can hardly wait till August).

Monday we replaced the controller after the machine simply refused to boot in any consistent way.  Powering up the machine  sounds like a chorus of dying cats.  (Which I'm told is for want of a new power supply, on back order.)

C'est la vie!

Lorraine

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

Date:  2 Apr 84 12:36 PST
From: vanMelle.pa
Subject: Re: AR#351: Lafite MessageHardcopier and HardcopyW break with unclear error message
To: 1100Support.pasa
cc: LispSupport.pa

Attn. Kaplan.  But first check that Ms. Kiewiet is not still having hardware problems.  This sounds like outright flakiness.

     ----- End of Forwarded Messages -----
*start*
00496 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 14:38:03 PST (Tuesday)
From: JFung.pasa
Subject: Re: [vanMelle.pa:
In-reply-to: Kiewiet's message of 3 Apr 84 13:59 PST
To: Kiewiet
cc: VANMELLE.PA, 1100Support, LispSupport.pa

Lorraine,

If you wish to cancel the AR, please let Thu know about it so it will be effective.  You may say Status{} _ Declined, and put your reasoning in the Disposition field.  

You may use LispAR-Edit.form for this purpose.  

*start*
00536 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 16:11 PST
From: vanMelle.pa
Subject: Lisp: Masterscope confused by OPCODES
To: LispSupport.pa

Lisp System Date: 29-Mar-84 17:34:40
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Annoying

Masterscope does not correctly analyze a form whose car is (OPCODES --).  E.g., in the macro for \MYALINK, which simply turns into ((OPCODES MYALINK)), it considers this form to use the variable MYALINK free.
*start*
00689 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 17:08 PST
From: vanMelle.pa
Subject: Lisp: CHECK/MENU/IMAGE does not test for MENU type
To: LispSupport.pa
cc: vanMelle.pa

Lisp System Date: 29-Mar-84 17:34:40
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Moderate

If you give CHECK/MENU/IMAGE a non-menu, it returns garbage, often a pointer outside the virtual address space, which causes a map out of bounds error when you try to fetch fields out of it, or even typetest it for bitmap.  Specific instance of this awful behavior is that
  (fetch (MENU IMAGEHEIGHT) of X)
falls into Raid if X=NIL.
*start*
00778 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 APR 84 20:48 PST
From: JONL.PA
Subject: Re: AR 197: MOUSESTATE marks MOUSESTATE-EXPR as-changed
To:   Burton, Sheil, LispSupport
cc:   JONL

In response to the message sent  19 Mar 84 18:01 PST from Burton.pa

I'm not quite sure that the DOCOPY EVAL@COMPILE part is relevant --
MOUSESTATE-EXPR is under a FNS in HLDISPLAY that is quite normal except
for being under the scope of an EXPORT.

Wouldn't the problem just go away if the EXPORT were applied only to
macros definitions there?  After all, everything else is "installed" in the
basic Lisp.  Is the macro MOUSESTATE changing so rapidly? or is it so
different from other macros that expand into calls to some  "lower-level" 
system function?
*start*
00524 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 11:09 PST
From: vanMelle.pa
Subject: Re: AR 460 -- user wants handle on "Top level typescript window"
In-reply-to: JonL.pa's message of 2 Apr 84 19:49 PST
To: JonL.pa
cc: vanMelle.pa, LispSupport.pa, Le.pasa

I didn't say it was a sin, just not obviously what one wants.  Still too much single-process mentality.

I am absolutely opposed to documenting \TopLevelTtyWindow, a variable that probably ought to go away, at least eventually.
*start*
01625 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 15:02 PST
From: Sannella.pa
Subject: [MASINTER.PA: ZEROP]
To: LISPSUPPORT

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

Date:  2 APR 84 23:49 PST
From: MASINTER.PA
Subject: ZEROP
To:   jonl
cc:   lispcore^

I think the negatives outweigh the positives in making this change.

I'd rather see us clean up the places where you can get an 'unnormalized' number (a 0 in a floating point box).

Just because some user is confused by a name doesn't mean that we should rush off and change it.

-----

From: KAPLAN.pa
Date:  3-Apr-84  7:53:55 PST
Subject: Re: ZEROP
In-reply-to: MASINTER's message of 2 APR 84 23:49 PST
To: MASINTER
cc: jonl, lispcore^

I also don't think that the cleanliness obtained from this backward incompatible change is worth the cost of having to change code all over the place in order not to lose performance.

This is one of many of the original bad design features of Interlisp, but not worth the trouble of improving.

If you want to pursue this, I would suggest using some other name besides ZEROP as the generic zero test, so that ZEROP could retain its original meaning.  If xxxxP is the new generic name, the family could be filled out with IxxxxP and FxxxxP.  A better name for the current meaning of ZEROP might be EQZP (to emphasize the EQ test), and this could be added as a synonym.  Over the long run, ZEROP could be de-documented.

But please don't make me examine the hundreds of personal and other project files that expect ZEROP to have its current meaning.

--Ron

     ----- End of Forwarded Messages -----
*start*
00589 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 18:59 PST
From: Kaplan.pa
Subject: Re: [LispSupport.pa: AR 466 & 467 & 468]
In-reply-to: Burton.pa's message of 3 Apr 84 09:58 PST
To: Burton.pa
cc: kaplan.pa, Vanlehn.pa, Lispsupport

I essentially have Grapher checked out.  In particular, I have fixed his problem 2 (box size).

I don't understand his problem #1:  What is a window NAME ?  Perhaps what he wants is to pass in a variable which will be set by SHOWGRAPH.  Or maybe SHOWGRAPH should return the window as value?  What is he after?

--Ron
*start*
01261 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 APR 84 21:14 PST
From: JONL.PA
Subject: Re: Lisp: New GENSYM
To:   Kaplan, LispSupport
cc:   JONL

In response to the message sent  20 Mar 84 18:50 PST from Kaplan.pa

Long ago, Kelly asked similar questions.  Namely, what are the extra
args to GENSYM for, and why does it appear to be so complicated?

The extra args are only for some "internal" calls; the interface that Tayloe
and I agreed upon is not yet implemented, so looking beyond what ARGLIST
or the release documentation gives you will be a waste of time.

However, in defense of apparent complexity, note that the "new" gensym
is nearly an order  of magnitude faster than the "old" one, and for a
myriad of gensyms, that amounts to 150 seconds savings (Dolphin timings)!!
Note also two items of functionality not provided by PACK*:
  1) the numerical suffix part is extended out with leading zeros to
     insure a minimal numerical part (Common Lisp does not do this)
  2)  The "new" option is indeed usefule to some; I've previously supplied
    all the arguments why "new" can't mean "unique", but the user who
   requested this feature fully understands, and insists that what he 
   wants is "new", not "unique".

*start*
00207 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 APR 84 21:20 PST
From: JONL.PA
Subject: my immediately previous note on GENSYM
To:   LispSupport

should be attached to AR 214
*start*
00222 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 APR 84 21:27 PST
From: JONL.PA
Subject: Is there an AR for documenting FILESLOAD
To:   LispSUpport

FILESLOAD apparently isn't in the manual.
*start*
01304 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 21:38 PST
From: Burton.pa
Format: TEdit
Subject: Lisp: AR 378
To: Sybalsky
cc: LispSupport.pa
Lisp-System-Date: 29-Mar-84 17:34:40

re your comments about scrollbar and cursoroutfn

If I have a window whose CURSOROUTFN resets the shape of the mouse cursor, and I leave the window via the scroll bar, then:

	--Mouse enters scroll bar, changes shape to arrow (OK).

	--Mouse leaves scroll bar, CURSOROUTFN is called (OK).

	--Scrollbar handler resets cursor shape (not OK).

If the order of the last two were reversed, it would make TEdit's life easier.


According to my tests and inspection of the code, the scroll handler is called and exited before the cursoroutfn.  Can we get together and figure this out??
richard

Æ
TIMESROMAN
|
TIMESROMAN



TIMESROMAN

9
TIMESROMAN



TIMESROMAN

8
TIMESROMAN



TIMESROMAN

3
TIMESROMAN



TIMESROMAN

O
TIMESROMAN
¨
TIMESROMANáz·*start*
00480 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 18:05 PST
From: Halvorsen.pa
Subject: TEdit: Position of caret too far to the right
To: TEditSupport
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 30-Mar-84 18:12:07
Machine-Type: Dandelion

The caret it too far to the right relative to the typein point.  Try selecting the 4 in "4." If you select so insertion will happen after the 4 the caret is flashing after the period. 

	Kris
*start*
00374 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 10:26 PST
From: sybalsky.pa
Subject: Re: TEdit: Position of caret too far to the right
In-reply-to: Halvorsen.pa's message of 2 Apr 84 18:05 PST
To: Halvorsen.pa
cc: TEditSupport.pa

The caret looks ok to me; if you can get this too-far-right ness to happen for you, I'd like to see it.
*start*
00446 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 20:34 PST
From: Kaplan.pa
Subject: Re: AR 333: LISTFILES should try to list non-Interlisp files
In-reply-to: LispSupport.pa's message of 28 Mar 84 08:53:03 PST (Wednesday)
To: LispSupport.pa, Roach

Is this a problem with standard LISTFILES, or a problem when you have SINGLEFILEINDEX loaded?

If the latter, then this AR should be passed off to JonL.

--Ron
*start*
00648 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 11:07 PST
From: vanMelle.pa
Subject: Lisp: (TTYDISPLAYSTREAM \TopLevelTtyWindow) still on RESETFORMS
To: LispSupport.pa
cc: vanMelle.pa

Lisp System Date: 29-Mar-84 17:34:40
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Annoying

It was long ago recommended that (TTYDISPLAYSTREAM \TopLevelTtyWindow) be removed from RESETFORMS on the grounds that there is no longer any excuse for it to be there, and it gets in the way of such things has having multiple exec windows.  Is there any excuse for it to remain?
*start*
00835 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 14:51 PST
From: vanMelle.pa
Subject: TEdit: press file losing font changes
To: TEditSupport
cc: vanMelle.pa

TEdit System Date:  2-Mar-84 16:54:27
Lisp System Date: 29-Mar-84 17:34:40
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Intermittent
Impact: Moderate

Sometimes the press file produced by Tedit has text appear in the default font instead of the correct font.  The text is spaced as though formatted for the correct font.  E.g., the file <LispCore>Next>LispMPCodes.tedit opens with a title in TimesRoman 12 Bold, but <LispCore>Next>LispMPCodes.press, made from it via the PressFile command, shows the title in TimesRoman 10 plain.  The bold face heading on the next paragraph also appears incorrectly.
*start*
00453 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 10:16 PST
From: Sybalsky.pa
Subject: Re: TEdit: press file losing font changes
In-reply-to: vanMelle.pa's message of 2 Apr 84 14:51 PST
To: vanMelle.pa
cc: TEditSupport.pa

I think I've got this one squashed:  There used to be a (shudder) global variable which contained the "current character looks".  Naturally, if you were hardcopying while reading your mail....
*start*
00309 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 15:33 PST
From: sybalsky.pa
Subject: Re: TEdit: TEDIT.DELETE 
In-reply-to: desRivieres.pa's message of 29 Mar 84 04:38 PST
To: desRivieres.pa
cc: TEditSupport.pa, EMACSSupport^.pa

Fixed.  It'll be in the next release....
*start*
00935 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 11:17 PST
From: vanMelle.pa
Subject: TEdit: TEDIT.INSERT scrolling when DONTSCROLL=T
To: TEditSupport
cc: vanMelle.pa

TEdit System Date:  2-Mar-84 16:54:27
Lisp System Date: 29-Mar-84 17:34:40
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Annoying

I have a case where TEDIT.INSERT causes the window to scroll even though the argument DONTSCROLL is T.  The string begins with a cr (it is LAFITEENDOFMESSAGESTR), and it is inserted in a place such that the cr is on the last visible line of the window, and the rest of the string would be one line below the window.  In this particular case, the insertion causes the window to scroll so that the entire string is visible.

I still have the message that demonstrates this bug, if you'd like to come see it live before I delete the message.

	Bill
*start*
00799 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 MAR 84 16:08 PST
From: ROACH.PA
Subject: READAIS
To:   LISPSUPPORT
cc:   ROACH

     (1) If you AISBLT to a window, the right border of the window is
not respected and you dirty your screen.
     (2) During an AISBLT, it is possible for other windows to pop above
the window you are AISBLTing to (in my case it was CROCK).  Bits then
get sent to the wrong window.
     (3) Given the slowness of AISBLT, its uninterruptability is
unfortunate.  Couldn't AISBLT be made interruptable at convenient points?
     (4) I had a lot of difficulty guessing what a FILTER was supposed
to be.  Finally I figured out it had to be an array size 256, origin 0,
with values between 0 & 255.  Maybe this should be documented.
				Kelly
*start*
00749 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 11:53 PST
From: Nuyens.pa
Subject: Lafite: problems after logout
To: LafiteSupport.pa
cc: Nuyens.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 27-Mar-84 08:53:34
Machine-Type: Dolphin

When I logged back into Lisp I got "file x no longer exists" msgs for about 4 files (some of which  are probably mail files).  I logged back out.  On logout I got the msg "non-numeric arg nil".  When I logged back in, and bugged get mail in a browser, DOLAFITEBROWSERCOMMAND had reasonable args, but CHECKLAFITEMAILFOLDERS was called with nil across the board. 
Sorry, but this is one of these "not much info, but you should know it happened"-type reports.

Greg
*start*
00346 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 APR 84 18:14 PST
From: ROACH.PA
Subject: Can't Adobe Query on Source
To:   lispsupport

     There doesn't appear to be a Source field in the Adobe Query
like there is in the Adobe Edit window.  I want to find out what
is becoming of all the ARs I submit.
				Kelly
*start*
00668 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 16:43 EST
From: Denber.wbst
Subject: Lafite: No more messages
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dolphin

I displayed the last message, deleted it, moved the triangle up to the next-to-last message and selected Answer.  I got an answer form for the next-to-last, which is right.  But then I clicked Display and instead of displaying the current (next-to-last) message (which was not deleted), it said "No more messages", as if the Displayer still thought it was pointing to the last message.

			- Michel
*start*
00428 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 Apr 84 13:56 PST
From: vanMelle.pa
Subject: Re: Lafite: No more messages
In-reply-to: Denber.wbst's message of 2 Apr 84 16:43 EST
To: Denber.wbst
cc: LafiteSupport.pa

I can't replicate this in the version of Lafite I'm running (soon to be released), so I shall assume it is fixed.  Let me know if you have this problem in the next release.

	Bill
*start*
00256 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 14:35 PST
From: sybalsky.pa
Subject: Re: TEdit: TEXTSTREAMP
In-reply-to: Burton.pa's message of 2 Apr 84 17:09 PST
To: Burton.pa
cc: TEditSupport.pa

Fixed it....Thanks
*start*
00362 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 11:04 PST
From: ckiparsky.pa
Subject: Lisp: FILE BROWSER
To: LispSupport.pa
cc: ckiparsky.pa, Kaplan
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dandelion

Once again (c.f. 19 Mar. message), in using RENAME, characters drop out of the new filename.  

Carol Kiparsky

*start*
00764 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 APR 84 18:25 PST
From: JONL.PA
Subject: AR 59: autologin sequence for RS232CHAT
To:   LispSupport
cc:   masinter, jonl

I'd like to decline this particular in favor of the existing RS232LOGIN
machinery.  Perhaps another AR needs to be generated "Please document
RS232LOGIN".  

P.S.  RS232LOGIN currently seems to be broken, and I've lent my MODEM
   out to someone (who? not sure, maybe Halverson), so I'll have to get
   it fixed before wanting others to read the documentation.  It got
   broken once last fall when Bill changed the contents of
   the data in LOGINPASSWORDS (he flubbed an edit trying to update RS232LOGIN),
   but the particular problem now sseems to be deeper.

*start*
00473 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 10:58 PST
From: vanMelle.pa
Subject: Lisp: want to be able to revert to a dummyframep
To: LispSupport.pa

Lisp System Date: 29-Mar-84 17:34:40
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Annoying

It is a real pain not to be able to REVERT to a \ fn in a break.  Please allow it, subject to confirmation, or wizardflg, or something
*start*
00368 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 11:36 PST
From: Sybalsky.pa
Subject: Re: AR 180:  further Roach flame
In-reply-to: LispSupport.pa's message of 4 Apr 84 11:05:48 PST (Wednesday)
To: LispSupport.pa
cc: Sybalsky.pa

FIXED.  However, there may be unpleasant side effects, like BOUT won't do what he expects any more.
*start*
01069 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 APR 84 11:37 PST
From: ROACH.PA
Subject: TEDIT misformats deletions near sub/superscripts
To:   LISPSUPPORT

     Impact _ Annoying
     There seem to be a variety of nonserious TEDIT formatting
problems when it comes to making deletions in contexts where there are
subscripts or superscripts.  Fortunately, all are illusory and will go
away on Redisplay or for the more resistant cases, Shape of your TEDIT
window.
     Some examples.  We use ^ and ! to indicate that the following
char is SUPERSCRIPTed or SUBSCRIPTED 4 points.  (All examples only
involve chars F, O, B, A, R, 1, & <CR>.)
(1) Delete <CR> in
	FOO<CR>
	BAR!1
FOO vertically aligns with subscript 1.
(2) Delete 1 in
	FOO<CR>
	BAR!1
Bottom part of FOO gets chopped.
(3) Delete <CR> in
	FOO!1<CR>
	BAR
BAR vertically aligns with subscript 1.
(4) Delete 1 in
	FOO!1BAR
Top part of FOOBAR gets chopped.  Must Shape TEDIT window to get
correct display.
(5) Delete 1 in
	FOO<CR>
	BAR^1
Bottom part of FOO gets chopped.
				Kelly
*start*
00914 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 11:45 PST
From: vanMelle.pa
Subject: Lisp: WHENCLOSE does not notice CLOSEF of STREAM
To: LispSupport.pa
cc: vanMelle.pa

Lisp System Date: 29-Mar-84 17:34:40
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Moderate

If you CLOSEF a stream directly, rather than calling CLOSEF on the stream's fullname, any WHENCLOSE operations do not get called, and properties on the stream's fullname linger.  For example, if you say (WHENCLOSE <stream> 'AFTER 'CleanupFn), and then (CLOSEF <stream>), CleanupFn never gets run, and <stream's> fullname still has an AFTERCLOSE prop of (CleanupFn).

Probably need to rethink WHENCLOSE anyway, since streams no longer are guaranteed to have litatom fullnames.  And WHENCLOSE EOF should probably interact with the stream's ENDOFSTREAMOP.

	Bill
*start*
00201 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 APR 84 12:08 PST
From: ROACH.PA
Subject: AR491
To:   LISPSUPPORT

	Machine _ 1108
	Difficulty _ Hard
	Priority _ Perhaps
*start*
00602 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 12:25:01 PST (Wednesday)
From: Sannella.PA
Subject: Re: [LispSupport.pa: AR 466 & 467 & 468]
In-reply-to: Kaplan's message of 3 Apr 84 18:59 PST
To: Kaplan
cc: Burton, Vanlehn, Lispsupport

I have changed AR 466: Subject_"Want SHOWGRAPH to take window title as arg", Attn_Kaplan  (What he wants is to pass in the window TITLE, without creating a window himself)

I have changed AR 467 (Grapher node boxes should be bigger): Status_Fixed Attn_Release

I changed AR 468 (Improve Grapher Error Messages): Attn_Kaplan

*start*
00275 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 17:21 PST
From: Nuyens.pa
Subject: TEdit: Superscript?
To: TEditSupport
cc: Nuyens.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dorado

greg
*start*
01502 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 17:13 PST
From: vanMelle.pa
Subject: AR status updates
To: LispSupport
cc: vanMelle.pa

First, a question.  I note that there are quite a few AR's marked fixed, attn release, for which the fix is not yet on <LispCore>.  Specifically, scads of tedit bugs.  Is this the correct status?  I would expect the implementor to not report a bug "fixed" until the software was actually in a position to be in the next loadup and hence next release.


444: Subject: Want "cumulative" mode for function call stats

442: Absolutely, Easy

458: Easy

461: Subject: Tedit stream should apply its ENDOFSTREAMOP at EOF

438: Perhaps

158: Hopefully, Easy

100: Perhaps, Hard, Annoying

382: Hopefully, Easy

99: This is two problems: (1) Want Product file server to support random access.  This is an AR for the file server folks, but we might keep a copy of it anyway, attn Lisp management.  (2) Want Lisp to cope with non-random access file server, e.g., by caching files locally.  This is Operating System/File system, Perhaps/Hard/Serious/Design Impl, Attn vanMelle.

212: This is two problems.  (1) The ringbells "feature" in PROMPTFORWORD only is active while PROMPTFORWORD has the tty.  Personally, I would say this is not the problem, since I think the ringbells hack in PROMPTFORWORD is of dubious worth, and often an annoyance.  (2) Tedit prompts in an obscure place (the prompt window), far from the scene of the action.
*start*
00381 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 18:22 PST
From: Wallace.pa
Subject: Lisp: Max volume size on DLion
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

The maximum size you can make a lisp volume on a DLion seems to be 16200 pages.  If you make one any larger your sysout won't run.  It hangs in 199.
*start*
00488 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 18:32 PST
From: Roach.pa
Subject: Ugly LAFITE window creation
To: LISPSUPPORT

     Impact _ Annoying     Freq _ Every Time
     Routinely, when I bug SendMail in the background menu, a small deformity of a window gets created near the cursor before blossoming into the window I really want.  The Filebrowser also has this problem.  Perhaps it has something to do with attached windows.
						Kelly
 
*start*
01636 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 19:34 PST
From: vanMelle.pa
Subject: more AR update
To: LispSupport
cc: vanMelle.pa

321, 322, 323, 343: These FileBrowser ARs are part of a Library package, much like Lafite or Browser.  They shouldn't be Operating System/Generic File, because FileBrowser is simply a user of the file system.  They fit more under Window/Library, but I'm not crazy about that classification either.  Maybe it's just Other Software.

124: to be consistent with other DOSTATS ar's, this ought to be PE/Performance tools.

340: Easy, Impact: Moderate (not serious, OUTFILEP is not guaranteed to work, and in fact fails on other devices than CORE).

259: Comment: if this is a Dandelion ucode problem, it is also a Dolphin/Dorado ucode problem, because they fall into Raid when GC tries to mark the stack bit on a bogus pointer.  So it seems clearly in Tedit's domain.  On the other hand, you might add an AR wish for all three microcodes, "GCREF should not cause invalid address for pointers out of bounds".

91: The first half of this should have been TTYIN, attn to me; it is now fixed.  The second half has nothing to do with TTYIN: it is "Typing ^B in a break window gives a "Break within Break" error".  Impact: Annoying, Difficulty: Hard.

432: This problem is really Communications/Pup, Subject: Leaf after logout activity not interlocked against other processes.  I have partially fixed this problem: change to processworld has made it difficult for other processes to run before device after logout event functions have run, relegating this problem to Minor.
*start*
00747 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: masinter.pa
Date:  5-Apr-84  1:03:05 PST
Subject: Re: AR 409: Update Interlisp-D to Services 8.0 protocol
In-reply-to: Cooper's message of 4 Apr 84 16:34 PST
To: Cooper
cc: LispSupport, MASINTER, vanMelle

Eric, as usual, OSD has provided a back door into the server. The Services 8.0 still supports the OLD protocol.

However, because some of our users have discovered CH.LOOKUP.USER, I've been pushing for a plan where the 'old' protocol will get turned off. Then we'll need the new one.

It is fortunate we have this grace period to do the upgrade, but it won't last forever -- at most 6 months, and might be only for the next 2 months, at least for Xerox internal.

*start*
00540 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 16:34 PST
From: Cooper.pa
Subject: Re: AR 409: Update Interlisp-D to Services 8.0 protocol
In-reply-to: LispSupport's message of 4 Apr 84 11:57:40 PST (Wednesday)
To: LispSupport.PA
cc: Cooper.PA, MASINTER.PA, vanMelle.PA

A preliminary test indicates that the Lisp NS software doesn't require any changes to be used with Services 8.0. I tried some Clearinghouse, Printing, and Filing functions on the new servers, all of which worked fine.

						Eric
*start*
00387 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 APR 84 09:20 PST
From: DEUTSCH.PA
Subject: DMPHASH is broken
To:   LispSupport

Here is a dribble script made on Maxc just now:

NIL
3_(SETQ HH (HARRAY 20]
{HARRAYP}#541502
4_(PUTHASH 1 2 HH]
2
5_(DMPHASH HH]
(RPAQ HH (HARRAY 23))
(PUTHASH 1 2 NOBIND)
NIL
6_DRIBBLE]

Note the NOBIND in the PUTHASH.

P. D.
*start*
00817 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 14:49 PST
From: vanMelle.pa
Subject: AR 207: SYSOUT to floppy doesn't reset FLOPPY.MODE after
To: LispSupport
cc: vanMelle.pa, Roach

Kelly's reply does not completely address the bug.

  "I did a sysout to floppies this morning and find FLOPPY.MODE being set back to PILOT as it should be after moving the sysout onto another machine."

But was floppy.mode smashed on the machine that performed the sysout?  Was floppy.mode smashed even if the sysout wasn't to floppy?  I.e., what does the sequence

_SYSOUT({Phylum}<Roach>FOO.SYSOUT)

_FLOPPY.MODE()

return when run on a Dandelion?  My cursory reading of the floppy code is that it returns SYSOUT, clearly a bug.  Unless Kelly disagrees, I propose this AR be reopened.

	Bill

*start*
00316 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 APR 84 09:53 PST
From: ROACH.PA
Subject: Re: AR 207: SYSOUT to floppy doesn't reset FLOPPY.MODE after
To:   vanMelle, LispSupport
cc:   ROACH

In response to the message sent   4 Apr 84 14:49 PST from vanMelle.pa

     Kelly disagrees.
*start*
00684 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 15:16 PST
From: Sannella.pa
Subject: [DMRussell.PA: Re: Lisp: GRAPHER comments]
To: LispSupport

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

Date: 3 April 1984 9:55 am PST (Tuesday)
From: DMRussell.PA
Subject: Re: Lisp: GRAPHER comments
In-reply-to: Your message of 3 Apr 84 09:08:37 PST (Tuesday)
To: Sannella

You can kill off one of those ARs.  I read the documentation -- SHOWGRAPH
does in fact take a window name as an arg.  It's just that the arg name is poorly
chosen.  The args to SHOWGRAPH should be --

(SHOWGRAPH graph window/or/windowname ... )




     ----- End of Forwarded Messages -----
*start*
00415 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 15:13 PST
From: Jellinek.pa
Subject: Lisp: wish: DEdit as separate process
To: LispSupport.pa
cc: Jellinek.pa
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dolphin

I propose that DEdit run as a process separate from the exec, a la TEdit.  I find the current situation cumbersome for a variety of (obvious?) reasons.
	Herb
*start*
00931 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 15:17 PST
From: Sannella.pa
Subject: [JONL.PA: 'unnormalized', and "some user"]
To: LispSupport

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

Date:  3 APR 84 17:48 PST
From: JONL.PA
Subject: 'unnormalized', and "some user"
To:   Masinter
cc:   LispCore^

In-reply-to: your message of 2 APR 84 23:49

A 0 in a floating point box is the IEEE format for a floating-point zero;
might you have been thinking of something else (e.g., the bug in FPLUS I
reported last week with unnormalized numbers?)

The issue is no longer that "some user" (singular) is confused by the name
ZEROP; from the replies in my mailbox, it appears as though it is "many
users" (very plural!).

I'm fairly certain that the only negative is uncertainty about who actually
wants  (ZEROP 0.0) ==> NIL   -----  can you think of any others?


     ----- End of Forwarded Messages -----
*start*
01185 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 15:55 PST
From: Sannella.pa
Subject: [MASINTER.pa: ZEROP, and mechanism for making design decisions]
To: LispSupport

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

From: MASINTER.pa
Date:  3-Apr-84 23:00:48 PST
Subject: ZEROP, and mechanism for making design decisions
To: LispCore^
cc: Sheil

I am opposed to the proposal to change ZEROP, because the cons outweigh the pros, as I outlined in a private message to JonL.

I do not believe it is appropriate to make design decisions by appealing to Lispusers^, a relatively large community of internal Xerox users, unless there is some consensus that we need a survey of user opinions in order to make the design decision. 

The Interlisp-D system is quite large and fragile. Minor gratuitous incompatibilities are potentially destabilizing and distract us from the major high priority tasks that we have before us.

I would like to drop this ZEROP nonsense. If anyone wants to discuss it further, can we postpone it until next Tuesday, 10 AM-10:30 AM, at which time we will have a meeting of the ZEROP committee.


     ----- End of Forwarded Messages -----
*start*
01121 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 15:54 PST
From: Sannella.pa
Subject: [MASINTER.pa: Re: GENSYM]
To: LispSupport.pa

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

From: MASINTER.pa
Date:  3-Apr-84 22:45:21 PST
Subject: Re: GENSYM
In-reply-to: JONL's message of 3 APR 84 21:41 PST
To: JONL
cc: MASINTER, 1100Support.pasa, LispCore^

you have never made an argument for why it was necessary to make an incompatible change to GENSYM rather than some new user package, into which you can put all of the complexity you want.

I want to keep the "core" of Interlisp as small and simple as possible. Users have enough trouble finding their way around without being confrunted with a lot of new options in the 'kernel' of the language.

The only exceptions I can think of are those places where we decide to adopt some feature from CommonLisp into the Interlisp kernel (rather than as a part of a separate ZCommonLisp compatibility package.) In those cases, we must be careful not to differ in any respect fro the CommonLisp specification.


     ----- End of Forwarded Messages -----
*start*
00833 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 15:56 PST
From: Sannella.pa
Subject: [JONL.PA: Re: GENSYM]
To: LispSupport

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

Date:  4 APR 84 12:00 PST
From: JONL.PA
Subject: Re: GENSYM
To:   MASINTER
cc:   1100Support.pasa, LispCore^, JONL

In response to your message sent   3-Apr-84 22:45:21 PST

Did I have to make the argument about the broken state of the "old" GENSYM?

Didn't Doug Lenat already make it?  Didn't the LOOPS people too?  when
they found the limitations which the documented change corrected? or finally
Tayloe?  and the list goes on and on and on.

Larry,  how about being realistic on this case, rather than re-iterating
general principles that apply in some cases and don't apply in others.

     ----- End of Forwarded Messages -----
*start*
00562 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 15:57 PST
From: Sannella.pa
Subject: [Burton.pa: Re: GENSYM]
To: LispSupport

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

Date:  4 Apr 84 14:56 PST
From: Burton.pa
Subject: Re: GENSYM
In-reply-to: JONL.PA's message of 4 APR 84 12:00 PST
To: JONL.PA
cc: MASINTER.PA, 1100Support.pasa, LispCore^.PA

"Did I have to make the argument about the broken state of the "old" GENSYM?"

That is exactly what you had to do, and didn't do.

richard


     ----- End of Forwarded Messages -----
*start*
00842 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 16:21 PST
From: vanMelle.pa
Subject: Re: AR#388:DELFILE hangs
To: LispSupport
cc: vanMelle.pa, Kaplan, JonL

The significant clue seems to be that the files on <Lisp> have had their Write protection set to "None".  That protection does not affect the creation of files, apparently, but new versions inherit the protection of the previous version, and so cannot be deleted.  I suspect the only way to delete such files is to chat to the server, connect to <Lisp>, change the file's protection, then delete it.  Thus the only thing Lisp's DELFILE can reasonably do is return NIL.

So change AR:

Subject: DELFILE of a file write-protected against owner hangs
System: communications
Subsystem: Pup protocols
Attn: vanMelle
Impact: Annoying
Problem Type: Bug
*start*
00729 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 16:29 PST
From: vanMelle.pa
Subject: TEdit: TEDIT.FORMATTEDFILEP
To: TEditSupport
cc: vanMelle.pa

TEdit System Date:  2-Mar-84 16:54:27
Lisp System Date: 29-Mar-84 17:34:40
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Always

It would be nice if TEDIT.FORMATTEDFILEP returned a different result depending on whether there were image objects, or merely different fonts.  In the latter case, the chance of information loss involved in flushing the formatting is much lower; and Lafite could, for example, ask the more direct question "retain font information?" instead of the vaguer "retain formatting?".
*start*
00583 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 10:14 PST
From: sybalsky.pa
Subject: Re: TEdit: TEDIT.FORMATTEDFILEP
In-reply-to: vanMelle.pa's message of 4 Apr 84 16:29 PST
To: vanMelle.pa
cc: TEditSupport.pa

As of next release, will return one of the atoms


	IMAGEOBJ--the file contains image objects
	PARALOOKS--the file contains formatted paragraphs
	CHARLOOKS--the file contains font changes.
	NIL--not a formatted file.


It makes the tests in that order, so if you have both para looks changes and font changes, you get back PARALOOKS.*start*
00689 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 APR 84 10:22 PST
From: ROACH.PA
Subject: AR176 WORKAROUND
To:   LISPSUPPORT

     Although AR176 has been fixed, FUGUE.6 has gone out the door
without it and customers who expect to SYSOUT even though it isn't
"supported" (read documented) are likely to gripe.  I think the
following patch will help:
	(ADVISE '(\PFLOPPY.TRUNCATEFILE IN \SFLOPPY.CLOSESMALLFILE)
		'BEFORE
		'LAST
		'(SETQ LASTPAGE (ADD1 LASTPAGE)))
This patch should be suggested to any user in possession of Fugue.6
griping about 9005s, sysouts almost working but not quite, not being
able to chat in a sysout made by floppy, etc.
				Kelly
*start*
00808 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 09:16 PST
From: Kaplan.pa
Subject: Lafite: When bad mail comes back
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dorado

I bugged deliver on a message with a bad address, then went on to edit message  (2) in another window.  When the bad address was discovered, Lafite ungreyed its window and popped it back up, and ALSO MADE IT BE THE TTY STREAM.  Thus, all the typing that I was doing into message (2) flipped into the Subject line of message (1), which really seems foolish.

I suggest that a bad message be brought back with extra attention called to it perhaps by flashing it a couple of times, but that it not automatically be made the TTY process.
*start*
00698 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 20:54 PST
From: desRivieres.pa
Subject: Lisp: CHAT to DEC20s
To: LispSupport.pa
cc: desRivieres.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

When one CHATs to MAXC, somehow the information about the kind of terminal being emulated and the dimensions of the screen is automatically passed along.  However, Ron Kaplan tells me that this is not the case over at CSLI --- when he CHATed to CSLI-TURING (a 2060) and started EMACS, he was asked to specify what kind of terminal he was on.  How can this be rectified?  I could not find anything in the book on this (or on CHAT's EMACS mode).

---Jim 
*start*
00465 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 14:42 PST
From: vanMelle.pa
Subject: Re: Lisp: CHAT to DEC20s
In-reply-to: LispSupport.pa's message of 4 Apr 84 12:53:06 PST (Wednesday)
To: LispSupport.pa
cc: vanMelle.pa

It is either a problem in the setting of the global CHAT.DISPLAYTYPE (the numeric code of "Datamedia" on the host being chatted to), or the host's chat server does not recognize the displaytype mark byte.
*start*
00442 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 10:30 EST
From: Denber.wbst
Subject: Lisp: COLOR
To: LispSupport.pa
cc: Burton.pa, Feuerman.pasa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dolphin

I have loaded {Ice}<Lisp>Library>COLOR.DCOM and {Phylum}<Lispusers>Colorutilities.dcom.  A call to (COLORDISPLAY T) now results in a break in COLORMAPCREATE - Illegal arg - NOBIND.  ??

			- Michel
*start*
00531 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 09:19:31 PST (Wednesday)
From: Feuerman.PASA
Subject: Re: Lisp: COLOR
In-reply-to: Denber.wbst's message of 4 Apr 84 10:30 EST
To: Denber.wbst
cc: LispSupport.pa, Burton.pa, Feuerman

Michel,

Just to make sure we eliminate other possibilities, try (COLORDISPLAY T 4).  It may be that it's not defaulting the bits per pixel argument properly.  But then again, I've never run across that particular problem, so I don't necessarily know.

--Ken.
*start*
00710 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 14:08 EST
From: Denber.wbst
Subject: Re: Lisp: COLOR
In-reply-to: Feuerman.PASA's message of 4 Apr 84 09:19:31 PST (Wednesday)
To: Feuerman.PASA
cc: LispSupport.pa, Burton.pa

Nope, that didn't help - here's what I get.  The args to COLORMAPCREATE when it breaks are INTENSITIES = NOBIND, BITSPERPIXEL = 4.  Called from COLORMAPOF with args NEWCM = NOBIND and BITSPERPIXEL = 4.  Called from COLORDISPLAY with args COLORMAPIFON = T, BITSPERPIXEL = 4, CLEARSCREENFLG = NIL, CBITMAP = some bitmap #, COLORBITS = {}#71,151000.

Does that mean anything to you?  Do I still need to have that colorpatch file loaded?

			- Michel
*start*
00361 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 07:43:46 PST (Thursday)
From: Feuerman.PASA
Subject: Re: Lisp: COLOR
In-reply-to: Denber.wbst's message of 4 Apr 84 14:08 EST
To: Denber.wbst
cc: Feuerman, LispSupport.pa, Burton.pa

Sorry, that one's beyond me.  Richard Burton is probably the one to help for that.

--Ken.
*start*
00713 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 14:13 EST
From: Denber.wbst
Subject: TEdit: Cursor
To: TEditSupport.pa
TEdit-System-Date:  1-Mar-84 13:54:34
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dolphin

If you're in a TEDIT window and leave to type something to the top-level, when you return to TEDIT you have to click the mouse to make that window active.  Unfortunately, TEDIT takes that as a cursor move command, so you lose your old cursor position in the process of regaining the editor's attention.  It would be nice if TEDIT would simply TOTOPW itself without moving the old cursor location on the first click when re-entering its window.

			- Michel
*start*
00466 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: masinter.pa
Date:  5-Apr-84  0:24:55 PST
Subject: want auto-Reply-TO: feature in Lafite
To: LafiteSupport

impact: minor
priority: possibly (my guess)

I'd like the same options for Reply-To: that Hardy gives: namely a 3-way option:
send anyway
don't send
add reply-to

when the message recipients include a DL.

This is low impact because it won't do much good in non-XEROX environments.
*start*
00304 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 11:13 PST
From: Burton.pa
Subject: Re: AR 498: CHECK/MENU/IMAGE returns garbage if given non-MENU
In-reply-to: LispSupport.pa's message of 4 Apr 84 12:06:44 PST (Wednesday)
To: LispSupport.pa


Fixed in next loadup.

*start*
00660 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 09:10 PST
From: Sheil.pa
Subject: DEdit ARs'
To: lispsupport

Mike:

Over the next few days, I'll be emptying out my private bug file into the AR system. To start with, I'd like to give you some info on the current ARs.

AR 174   Priority: Hope   Diff:	Mod    Impact:	Serious
AR 188   Priority: Prhps  Diff:	Easy
AR 290   Repeats 15
AR 400   Diff:	Moderate
AR 359   Diff:	Moderate
AR 254   Priority: Hope   Diff: Easy
AR 366   Priority: Hope   Diff: Moderate
AR 189   Diff:	Moderate
AR 234   Priority: Perhaps
AR 228   Diff:  Easy

The others I can't decide on yet.

Beau

*start*
00646 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 11:13:44 PST (Thursday)
From: JFung.pasa
Subject: AR 394: "Problem with Domain token" _ Fixed 
To: LispCore^.pa
cc: halvorsen.pa, LispSupport.pa, JFung
Reply-To: JFung.pasa

The problem of token can't have embeded space in user.cm is "fixed".  I.E. the tool now correctly shows domain "XSIS North" instead of just "XSIS".  

It is fixed at both ProfileTool and InstallTool. 
 
(Note: using ProfileTool will destroy your current user.cm file not recommended for internal users)

Filed at [Phylum]<lispCore>Next>InstallLispTool.bcd

	Thanks for your patience!

*start*
00741 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 11:43 PST
From: vanMelle.pa
Subject: TEdit: NewEditProcess in exactly wrong places!
To: TEditSupport
cc: vanMelle.pa

TEdit System Date:  2-Mar-84 16:54:27
Lisp System Date: 29-Mar-84 17:34:40
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Impact: Annoying

If I click Middle in a window displaying a readonly text stream, I get the NewEditProcess menu.  On the other hand, if, after a HARDRESET, I click middle in a window that used to have a live Tedit, the appropriate thing is selected, as if the window were still alive, but the caret does not flash and there is no Tedit process, nor any NewEditProcess menu to get me one.
*start*
00863 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 16:06 PST
From: MGardner.pa
Subject: TEdit: Problems with Hardcopy button in ExpandedMenu
To: TEditSupport
cc: MGardner.pa

TEdit System Date:  2-Mar-84 16:54:27
Lisp System Date: 13-Mar-84 17:32:33
Machine: Dolphin (Palladio)
Microcode version: 24,1
Memory size: 6000
Frequency: Once
Impact: Moderate

I filled in printer "expresso" and bugged Hardcopy.  But it turned out that Expresso was unavailable, so I wanted to cancel that.

(1) No way to cancel hardcopy.

(2) Mouse was tied up.  Had to type ^G and spawn mouse to get a mouse.

(3) With mouse, brought up a PSW and killed the OLDMOUSE process that looked like it was trying to send file to printer.  Process went away okay, but Hardcopy button vanished from menu, leaving only the "server: {xxx}" part of that item.
*start*
00662 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 10:53 PST
From: MGardner.pa
Subject: TEdit: Tabs
To: TEditSupport
cc: MGardner.pa

TEdit System Date:  2-Mar-84 16:54:27
Lisp System Date: 13-Mar-84 17:32:33
Machine: Dolphin (Palladio)
Microcode version: 24,1
Memory size: 6000
Frequency:  Always
Impact:  Annoying

When I do tabs, the placement and spacing of them don't appear on the screen the way they appear on paper. It's real deceiving.  I used up 5 sheets of paper before I got the tabs close to the way I wanted and that was pure luck.  Without a hardcopy mode formatting is difficult and very time consuming.

Mimi
*start*
00771 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 22:00 PST
From: JonL.pa
Subject: Lisp: WINDOWWORLD problems
To: LispSupport.pa
cc: Burton,vanMelle,JonL.pa
Lisp-System-Date: 29-Mar-84 11:12:40
Machine-Type: Dorado

I called (WINDOWWORLD T) to try to re-install a more "vanilla" background and other window setup.  It left the background a motley mixture of the "vanilla" background and the "crufty" background I happened to have at the time of calling WINDOWWORLD.  The "mixture" seemed to be along the lines of where there were pre-existing windows.

But the Lafite Status window just "disappeared".  I tried (LAFITE 'ON NIL) afterwards, and nothing happened.  Finally, (LAFITE 'OFF) followed by (LAFITE 'ON NIL) brought it back.


*start*
00691 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 21:23 PST
From: Kaplan.pa
Subject: Lafite: RAID in Answer
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dorado

I applied the Anser command to a message that didn't have a parseable from or to field.

I went into raid inside \ILLEGAL.ARG inside \INSUREWINDOW inside CLEARW inside BROWSERPROMPTPRINT.  The window argument to \INSUREWINDOW printed out from raid as  {list page header @ 12 0}.

Whenever I tried to print look at that arg in Lisp (e.g. from a break after teleraid) I went back into raid with a map out of bounds error

--Ron 
*start*
00415 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 Apr 84 10:51 PST
From: Wallace.pa
Subject: Lafite: NIL - NON-NUMERIC ARG
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 clicked Get mail and my lafite broke with NIL NON-NUMERIC ARG.  Bt shows is in CHECKLAFITEMAILFOLDERS; LISPXHIST, RESETY and RESETZ all NIL.
*start*
00866 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 APR 84 17:07 PST
From: ROACH.PA
Subject: 2 more for the TEDIT wish list
To:   LISPSUPPORT
cc:   ROACH

     (1) Changing all characters with a given font in a document
to some other font.  E.g., changing all TIMESROMAN chars to
GACHA chars without affecting the HIPPO chars.  A workaround:
(SETFONTDESCRIPTOR 'TIMESROMAN ... GACHAFONT), Get the file, Put
the file, (SETFONTDESCRIPTOR 'TIMESROMAN ... TIMESROMANFONT)
     (2) Replacing strings with a given set of looks.  E.g.,
I may have a symbol H subscript LAMBDA, involving two chars, the first
in GACHA, the second in HIPPO and SUBSCRIPTed 4 points.  I would
want to do replaces on just this symbol and not every occurence of
"HL" in my file.
     (1) & (2) are noncritical wish items for sometime in the glorious
future.
				Kelly
*start*
00491 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Thu, 5 Apr 84 13:33:14 PST
From: Deutsch.pa
Subject: AR # 521
To: LispSupport
In-Reply-To: "Sannella's message of Thu, 5 Apr 84 12:40:08 PST"

Examining the code for DMPHASH with EDITA makes it clear that the problem results from DMPHASH being compiled in a way that results in ARRAYNAME not being bound as a specvar, so that the free reference in the functional argument of MAPHASH doesn't find the correct value.*start*
00649 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 13:14 PST
From: Kaplan.pa
Subject: Lisp: Break command menu
To: LispSupport.pa
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dorado

If you get a break not in the TTY process, the break window comes up waiting for you to click into it before it switches the TTY there.  If instead of clicking Left, you click Middle to popup the menu and choose a break command, the command characters get unread into the current TTY displaystream, not the break.

Seems like clicking Middle for the pop-up should switch the TTY just like Left before doing anything else.


*start*
02306 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Thu, 5 Apr 84 13:51:04 PST
From: Deutsch.pa
Subject: AR mechanism, and accessibility of the Lisp system
To: LispSupport
cc: Masinter, Bobrow

As the principal original designer of the Interlisp-D implementation, and a Lisp programmer and implementor for over 20 years, I would like to express my dismay at the increasing conversion of Interlisp into a "closed" system.  The first step was the removal of the source code from the system on the grounds of space.  The second step was the removal of the source *pointers* from the system on the same grounds.  This made it effectively impossible even for knowledgeable users to explore the system, without incurring an inordinate wait for loading FNS/VARS.  The third step was the de-supporting of the external data base which could have substituted for the time-consuming FNS/VARS mechanism.  The next step was the decision not to even distribute sources to Interlisp-D customers, which makes it impossible for XSIS to offload any of their support work and cripples Xerox' ability to benefit from work by customers at the system level.  The most recent step is the institution of the AR mechanism, which drastically decreases the ability of users to find out anything about the fate of bug reports or feature requests by interposing a queue of unknown (and unknowable) delay, priority mechanism, etc., not to mention the psychological "black hole" effect which I have seen operate in the Mesa world.

As each of these steps has occurred, I have felt less and less interested in continuing to work in the Interlisp world.  I find the AR mechanism particularly objectionable: I submitted a bug report for something that would obviously take someone less than 10 minutes to find and fix, and got back the message "This problem has been assigned AR # 521 in the LispSupport action request database".  I would rather have waited 3 or 4 days for the fix than gotten a message the next day telling me nothing and giving me the impression that my bug report had been stuffed in some huge anonymous file somewhere from which it might, maybe, be retrieved someday.

It should be noted that I use Lisp only on Maxc from a terminal at home.  If I were using a D-machine I might feel different.*start*
01621 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 17:09 PST
From: Masinter.pa
Subject: Re: AR mechanism, and accessibility of the Lisp system
In-reply-to: Deutsch.pa's message of Thu, 5 Apr 84 13:51:04 PST
To: Deutsch.pa
cc: LispSupport.pa, Masinter.pa, Bobrow.pa, Sheil

Peter,

About pointers, open system, etc.: 

At least for internal Xerox users, the WHEREIS lisp library package, when loaded, will let you look at any function in the system. The WHEREIS package also works from Maxc. I guess this is the 'external database'. It has not been de-supported; in fact, it recently was added to the packages we support from Interlisp-D.

I agree that it would be best if we could distribute sources  to customers as long as they are protected by adequate licensing agreements, but I've stopped trying to work taht particular issue. With the licensing of Xerox protocols and release of Pilot sources to universities, it may become easier to do so. 

Your analysis of the support burden being lessened when sources are released is well taken.

About ARs and responsiveness:

There are now several hundred users of Interlisp-D. The Interlisp-D system is quite large. The list of things we've already signed up to do is quite large. When we were using electronic mail, and distributing bug reports to everyone, the mail traffic got to be unbearable. There were approximately 6000 messages in 1983. With size of the user community, we can no longer afford the mechanisms that make it possible to respond immediately. So far, we haven't seen the 'black hole' effect, and I hope we don't.


*start*
00636 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 12:44 PST
From: Masinter.pa
Subject: (NS.ECHOUSER '3#125000.0.307#) gives odd error: NIL Isn't a valid DestinationHost specification
To: LispSupport
cc: vanMelle, Cooper, wallace

communcation/NS
impact: Moderate (can't test ethernet)
problem type: Bug
attn: cooper/vanmelle

I tried (NS.ECHOUSER '3#125000.0.307#) and got back the message NIL Isn't a valid DestinationHost specification.

What gives? I thought this used to work.

Also, Problem type Documentation: NS.ECHOUSER isn't indexed in the current manual!!!!! Neither is PUP.ECHOUSER. 

  
*start*
01021 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 11:56 PST
From: Masinter.pa
Subject: AR#438
To: le.pasa
cc: LispSupport, Charnley, vanMelle, JonL
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dorado

Hi Thu. Please reply courteously to Eric@SRI-KL that unfortunately, DOSTATS doesn't work on the 1108 in the current implementation; we would like to have it working by the next major release of Interlisp-D but that it is hard and behind a number of other major DLion microcode tasks.

(Please note that Eric@SRI-KL is Eric Ostram (sp), who is the technical liason for CSLI at Stanford, which is a site that is going to have 100 machines, and  probably be our largest installation.)

Please mark the AR attn vanMelle, Charnley. 

Bill: can you elaborate what needs to get done to put stats into the 1108. I understand that it might be hard, but what else besides the modifications to the microcode needs to get done? Do you have a design? If so, can you append it to this AR? 

*start*
00800 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 14:22 PST
From: Sannella.pa
Subject: [kaplan.pa: Re: AR 200: addenda]
To: LispSupport

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

From: kaplan.pa
Date:  4-Apr-84 18:40:07 PST
Subject: Re: AR 200: addenda
In-reply-to: Your message of 4 Apr 84 13:28:15 PST (Wednesday)
To: Sannella
cc: Kaplan

I'm not responsible for File Browser--and I don't know who has picked it up since Gadol left.  I think Bill was looking at it at one point.  Maybe this one should be thrown up in the air to see if anybody has an interest in taking over that code.  (I have an interest but absolutely no time for something new like this).

In any event, please dis-assign this from me.

Thanks--

Ron

     ----- End of Forwarded Messages -----
*start*
01306 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 14:24 PST
From: Sannella.pa
Subject: [masinter.pa: 
Re: AR 500: (TTYDISPLAYSTREAM \TopLevelTtyWindow) should be removed from RESETFORMS]
To: LispSupport.pa

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

From: masinter.pa
Date:  5-Apr-84  0:55:46 PST
Subject: Re: AR 500: (TTYDISPLAYSTREAM \TopLevelTtyWindow) should be removed from RESETFORMS
In-reply-to: Sannella's message of 4 Apr 84 12:39:20 PST (Wednesday)
To: Sannella
cc: Burton

I think this is Burton's (Window/Window system). 

-----

Date:  5 Apr 84 09:50 PST
From: Burton.pa
Subject: Re: AR 500: (TTYDISPLAYSTREAM \TopLevelTtyWindow) should be removed from RESETFORMS
In-reply-to: masinter.pa's message of 5-Apr-84  0:55:46 PST
To: masinter.pa
cc: Sannella.pa, VanMelle.pa

I would guess that you were right but I can't find where it happens.  I've looked on the coms of adisplay, lldisplay and window.  Anybody got any other ideas where it might be happening??

richard

-----

Date:  5 Apr 84 10:31 PST
From: vanMelle.pa
Subject: Re: AR 500: (TTYDISPLAYSTREAM \TopLevelTtyWindow) should be removed from RESETFORMS
In-reply-to: Burton.pa's message of 5 Apr 84 09:50 PST
To: Burton.pa
cc: masinter.pa, Sannella.pa

WBREAK

     ----- End of Forwarded Messages -----
*start*
00305 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 18:35 PST
From: Burton.pa
Subject: Re: AR 500: (TTYDISPLAYSTREAM \TopLevelTtyWindow) should be removed from RESETFORMS
In-reply-to: vanMelle.pa's message of 5 Apr 84 10:31 PST
To: Lispsupport
cc: vanMelle.pa


fixed.

*start*
00278 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 15:09:50 PST (Thursday)
From: JFung.pasa
Subject: AR: 65 Fix MAKELISPFLOPPIES.DOC _ Fixed
To: Masinter.pa
cc: LispSupport.pa, JFung

Filed  at [Phylum/Rose]<Lisp>Current>MakeLispFloppies.doc
*start*
00524 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 15:23 PST
From: vanMelle.pa
Subject: Re: AR 507: Intermittent MP codes 9318/9016
In-reply-to: LispSupport.pa's message of 5 Apr 84 14:44:01 PST (Thursday)
To: LispSupport.pa

This is System/Subsys unknown, Attn 1100Support until we are given further information.  "MP 9318" is entirely too vague to have any hope of even narrowing down the culprit.  MP 9016 I think was already given an AR attn Charnley that also is awaiting more info.
*start*
00749 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 15:32 PST
From: Barrera.pasa
Subject: Lafite: Displaying the Last Message
To: LafiteSupport.pa
cc: Barrera.pasa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 23-Mar-84 17:29:16
Machine-Type: Dolphin

	Let us say that there are N messages in a certain mail file.  If the Nth message is selected and then the Display menu item selected, "No more messages" appears in the window above the menu.  This only happens when viewing it out of sequence.

	In order to display the Nth message, one must select the (N-1)st message and select Display twice.

	I believe there is a newer version of Lafite available, so if this has already been fixed, I apologize.
*start*
00549 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 15:41 PST
From: vanMelle.pa
Subject: Re: Lafite: Displaying the Last Message
In-reply-to: Barrera.pasa's message of 5 Apr 84 15:32 PST
To: Barrera.pasa
cc: LafiteSupport.pa

I don't believe this is true even in the version you are running (28-Feb-84).  If the Nth message is selected and then the Display menu item selected, "No more messages" appears ONLY IF the Nth message is already being displayed in a display window.  Do you have a counterexample?

	Bill
*start*
00361 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 17:52 PST
From: Barrera.pasa
Subject: Re: Lafite: Displaying the Last Message
In-reply-to: vanMelle.pa's message of 5 Apr 84 15:41 PST
To: vanMelle.pa
cc: Barrera.pasa, LafiteSupport.pa

I can't reproduce my error, so I must have been mistaken.   

My apologies.

Stephanie
*start*
00834 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 17:22 PST
From: Masinter.pa
Subject: Re: AR: 65 Fix MAKELISPFLOPPIES.DOC _ Broken
In-reply-to: JFung.pasa's message of 5 Apr 84 15:09:50 PST (Thursday)
To: JFung.pasa
cc: Masinter.pa, LispSupport.pa

Jerry:

a) there is no [phylum]<Lisp>Current>MakeLispFloppies.DOC as you said in your message.

b) if there were to be one, it should be placed on <LispCore>Next> or given to Michael Sannella to place there (or on <LispNew>Next>). 

c) AR#65 comingles two separate issues: one of which is to update the documentation and script for making floppies (MakeLispFloppies.DOC), one of which was a potential AR with the Lisp.PrometheusScript which is used in the installation utility. Your message indicated that you had only resolved the first issue.


*start*
00389 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 15:16 PST
From: vanMelle.pa
Subject: Re: AR#509
To: LispSupport, 1100Support.pasa

This problem is FilePkg, attn Kaplan.  I think it is largely (but perhaps not completely) superseded by another AR--"Filepkg confused by name in FILECREATED expression being different than name file was loaded under". 
*start*
00888 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 16:21 PST
From: Stansbury.pa
Subject: Record Package
To: Masinter, Lispsupport
cc: Stansbury.pa

If you define a new clisprecordtype (say MESAARRAY), define a bunch of MESAARRAYs, and then redefine the function which translates MESAARRAYs into some previously known clisprecordtype, then there should be some convenient way of having all existing MESAARRAYs retranslated and redeclared.  

I had the worst time trying to convince my MESAARRAYs to redeclare themselves, since the text of the declarations had not changed: I finally had to redeclare each MESAARRAY with an off-the-wall definition, and then redeclare it again with its intended definition.  

It would be nice if there were some documented way of causing a record to redeclare itself even if it didn't think it needed to be.

-- Tayloe.
*start*
00367 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 APR 84 23:44 PST
From: MASINTER.PA
Subject: re Record package & redefining user record types
To:   stansbury
cc:   LispSupport

The manual doesn't say how to do this.

The 'cache' of records to their translations is stored in CLISPARRAY, so a (CLRHASH CLISPARRAY) should do it for you.

*start*
00504 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 17:17 PST
From: Masinter.pa
Subject: AR#521
To: LispSupport
cc: Deutsch

This is Interlisp-10 only (i.e., same script works in Interlisp-D). I'm not sure when I'm going to do my next Interlisp-10 loadup; I was actually hoping not to do any more on Maxc at all before Maxc's decommission. Set Priority: Possibly, Attn Masinter.

Workaround: use UGLYVARS and HPRINT instead of DMPHASH to save and restore hash arrays.

*start*
01631 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 18:23 PST
From: Kaplan.pa
Subject: Lafite: Default move-to folder
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dorado

I use a somewhat larger font for my window title font, and the result is that the name of the Default move-to window does not really show on the screen.  This means that I am never safe in using the middle button, because I don't know where the message is likely to go and I am not told where it went after it went there.

I suggest the following change in interaction:  When the middle button is used for Move-to, print out the name of the destination folder in the little prompt window above the browser.  That solves the problem of knowing where to go to retrieve the message.

I think I would also not mind it if it requested a mouse confirm after printing out the name of the folder, so I would then get told in advance and have a chance to deny the default move folder, even though I can't see what it is on the screen.  The extra click is a minor inconvenience in return for really being sure about what is going on.

In fact, I actually don't see why there is a difference now in the confirmation requirements of the Left and Middle button:  With the Left button, you have to explicitly select the folder, then confirm.  The argument says that you needn't bother confirming on Middle cause its an already known target should apply equally well to a folder that you have just carefully selected.

I think there should be confirms on both interactions.
*start*
00462 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: leavitt.guest
Date:  5-Apr-84 21:23:52 EST
Subject: Furniture for an 1108
To: xerox1100usersgroup^.pa
cc: leavitt

I will shortly be receiving an 1108 with a 40MB disk, and I would be
most interested in hearing about any "systems furniture" that anyone has 
used with such a machine.  I'll be acquiring an FX100 as a local printer.
Thanks in advance for your good ideas.

Mike Leavitt
*start*
00465 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: DonWinter.pasa
Date:  5-Apr-84 18:38:52 PST
Subject: Re: Furniture for an 1108
In-reply-to: leavitt.guest's message of 5-Apr-84 21:23:52 EST
To: leavitt.guest
cc: xerox1100usersgroup^.pa

Some furniture which does a pretty good job of operating with an 1108 has been purchased for the Pasadena facility of XSIS. Contact Paul <Ricks.pasa> for details of source, availability, etc.

				Don*start*
02108 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 19:00 PST
From: Burton.pa
Subject: Lisp: caret behavior change
To: LispSupport.pa
cc: LispFriends^

 
I fixed the caret to be per process.  This should fix the problem of carets being left on the screen and of windows being created to take the caret out of.  I changed it so that the caret is always visible.  If it is hidden by another window, its window is brought to the top.  I added the function CARETRATE which changes the caret rate of the current process and documented the variable DEFAULTCARETRATE and DEFAULTCARET which change the behavior of the initial caret of the process.  Included below are the changed sections of the manual.

This change touched a lot of files so please report any strange behavior.

richard


{FnDef {Name CARET} {Args NEWCARET}
{Text
Sets the shape that blinks at the location of the next output to the {lisp TTYDISPLAYSTREAM}.  {arg NEWCARET} is either (1) {lisp NIL} - no changes, returns a {lisp CURSOR}{note ptr to CURSORs?} representing the current caret, (2) {lisp OFF} - turns the caret off, (3) a {lisp CURSOR} which gives the new caret shape or (4) {lisp T} - reset the caret to the default which is the value of {VAR DEFAULTCARET}. {index globalvar DEFAULTCARET}  {VAR DEFAULTCARET} can be set to change the initial caret for new processes.  The hotspot of {arg NEWCARET} indicates which point in the new caret bitmap should be located at the current output position.  The previous caret is returned.
Note: the bitmap for the caret is not limited to the dimensions {var CURSORWIDTH} by {var CURSORHEIGHT}.
}}


{FnDef {Name CARETRATE} {Args NMILLISECONDS}
{Text
Sets the rate at which the caret for the current process will flash.  The caret will be visible for {ARG NMILLISECONDS} milliseconds, then not visible for {ARG NMILLISECONDS}  milliseconds.   If {ARG NMILLISECONDS} is {lisp T}, the rate is set to {VAR DEFAULTCARETRATE}.  {INDEX Globalvar DEFAULTCARETRATE} The previous value of {FN CARETRATE} is returned.  If the caret is off, {fn CARETRATE} return NIL.
}}


*start*
00562 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 APR 84 22:04 PST
From: JONL.PA
Subject: Bug in REPLACE when fieldname is a complex accessfn
To:   LispSupport

[RECORD MUMBLEBAR (A B)
  (ACCESSFNS MUMBLEBAR 
    ((C (LIST (FETCH (MUMBLEBAR A) OF DATUM)  (FETCH (MUMBLEBAR B) OF DATUM))
        (PROGN (REPLACE (MUMBLEBAR A) OF DATUM WITH (FETCH (MUMBLEBAR A) OF NEWVALUE))
               (REPLACE (MUMBLEBAR A) OF DATUM WITH (FETCH (MUMBLEBAR A) OF NEWVALUE]


(REPLACE (MUMBLEBAR C) OF '(1 2) WITH '(3 4))

fails to return (3 4).
*start*
00489 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 APR 84 23:06 PST
From: JONL.PA
Subject: failure to clear bottom line of a WINDOW
To:   LispSupport

I have a borderless window, into which I scribbled some stuff with PAINT
(from the window menu); then I used CLEAR (again from menu) to clear the window.
But frequently -- roughly 50% of the time -- the pixels on the absolute bottom
line aren't cleared.

Sorry, I can't seem to see any other relevant clues.

*start*
00420 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 00:38 PST
From: JonL.pa
Subject: LISTFILES
To: KAPLAN
cc: LISPSUPPORT,JonL.pa

If you (LOAD 'FOO.DCOM) and then connect to a directory that has a source for FOO on it, and then (LISTFILES FOO), it will get the source form the directory that the .dcom came from.

Is this supposed to be a feature?  Seems like a misdesign/bug to me.

*start*
00234 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 APR 84 01:05 PST
From: MASINTER.PA
Subject: AR#418
To:   lispsupport
cc:   sheil

Please mark this Attn: Sheil, who knows far more about DECL than I do.

*start*
00410 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 03:45 PST
From: Wallace.pa
Subject: Lisp: HASH TABLE FULL
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

I got this error after redefining about 300 commands in TEDIT.  Why can't the hashing function just a>figure out that I'm rehashng on the same key, and/or b>grow tha table as necessary?

*start*
00370 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Fri, 6 Apr 84 08:10 PST
From: Raim.pasa
Subject: AR edit
To: Le.pasa, LispSupport.pa
cc: 1100Support


NUMBER:		442

STATUS: 	Fixed

ATTN:		vanMelle.PA

ASSIGNED TO:	1100Support.PA

DISPOSITION:	The keyboard chart in the 1108 Users Guide has been updated to show 1100 keyboard equivalences.


*start*
00795 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 08:58 PST
From: Sannella.pa
Subject: [MASINTER.PA: AR#462: want status Can't duplicate...]
To: LispSupport.pa

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

Date:  6 APR 84 01:00 PST
From: MASINTER.PA
Subject: AR#462: want status Can't duplicate...
To:   Sybalsky, Sannella

In the situation you describe, either the AR describes something with Frequency: Intermittant, or should be marked either Declined or Incomplete.

You should send a message back to the submitter/source about the problem, and ask them to send any more information if they have it. The message you send can include the AR# in the title.

Please mark THIS AR (about wanting a new status) as Declined.

     ----- End of Forwarded Messages -----
*start*
01096 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 14:33 PST
From: Sannella.pa
Subject: [JONL.PA: Re: ZEROP]
To: LispSupport.pa

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

Date:  3 APR 84 13:44 PST
From: JONL.PA
Subject: Re: ZEROP
To:   KAPLAN, MASINTER
cc:   lispcore^, JONL

In response to the message sent   3-Apr-84  7:53:55 PST from KAPLAN.pa

Hold the "horses", Ron -- everything you're worrying about was already
"taken care of" in my note to LispUsers^:

1) no code would have to be changed for performace per se -- the macro I 
   suggested for ZEROP would at most take a 6-byte sequence into about a 
   14-byte sequence, with essentially no measurable time loss.

2) no code ** at all ** would have to be changed except code that wants
   (ZEROP 0.0) ==> NIL.  Unless there is evidence to the contrary, I
   don't know of anyone who actually *wants* this behaviour; on the
   contrary, Greenfeld wants the opposite (which in fact seems to be
   the default presumption, even by users who ought to know better).

     ----- End of Forwarded Messages -----
*start*
00439 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 10:51 PST
From: vanMelle.pa
Subject: Re: AR 517: DLion Sysout hangs in 199 if lisp volume is bigger than ~16200 pages
In-reply-to: LispSupport.pa's message of 6 Apr 84 09:14:56 PST (Friday)
To: LispSupport.pa

Personally, I don't believe it.  But in any case it should be attention Purcell/Charnley as 199 is something that is Dlion initial microcode.
*start*
04065 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Fri, 6 Apr 84 10:23:56 PST
From: Putz.pa
Subject: TEdit format messages: yuchh!
To: LafiteSupport
cc: MessageSystemImplementors^
Format: not TEdit

Grapevine items of type 1010B are supposed to contain a "human-readable textual message."  I don't consider "

<TIMESROMAN

<TIMESROMAN

<TIMESROMAN

<bTIMESROMAN

<)TIMESROMAN

<
TIMESROMAN

<TIMESROMAN

< TIMESROMAN

<TIMESROMAN

<TIMESROMAN

<oTIMESROMAN|z7" particularly human-readable.

Grapevine has a perfectly good mechanism for sending formatting and other information along with a textual message.  Walnut and Fillet both use additional Grapevine items to encode formatting information.  Lafite is not being a very good Grapevine citizen.

-- Steve

------------------------------
Date:  6 Apr 84 09:56 PST
From: MGardner.pa
Subject:  Shlomo Weiss Seminar
To: ComputerResearch^.pa
cc: MGardner.pa, KSA^.pa

This a reminder that Shlomo Weiss will be here on Monday and Tuesday, April 9 and 10. Please contact me today if you want to meet with him. I'd like to have his agenda completed by today.

Mimi <MGardner>
ext. 4835


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

Date: 21 Mar 84 11:53 PST
From: MGardner.pa
Format: TEdit
Subject: Candidate: Shlomo Weiss, April 9-10
To: ComputerResearch^.pa
cc: MGardner.pa, KSA^.pa



	Very High Performance Scalar Processors

			by Shlomo Weiss
		      University of Wisconsin
		
			April 9, 1984

    	      CSL Commons
	    1:00 PM - 3:00 PM


Abstract:

Decoupled architectures achieve high scalar performance by 
cleanly splitting instruction processing into memory access 
and execution tasks. We first describe a  decoupled architecture
based on the CRAY-1 scalar architecture. Then, we compare its 
performance with the CRAY-1 and with an implementation of the 
CRAY-1 based on Tomasulo's algorithm which uses extensive tagging
and result forwarding in order to achieve dynamic instruction 
scheduling. Next, the sensitivity to memory access delays is 
studied by varying memory access time over a wide range of values.
Finally, we study queue lengths in decoupled machines, and show 
the effect of queue lengths on performance. Relatively short queues 
are shown to give optimum, or near optimum, performance.

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

In summer of 1982 Shlomo Weiss was a summer intern with KSA (then the VLSI Systems Design Area).  During the summer he developed an interactive program for simulating and displaying digital circuits represented in terms of combinational logic and clocks.  Unanimous consensus of the group was that he is a very bright fellow.

Shlomo's interests range from digital architectures to computer-aided design to expert systems.  He is a potential candidate for positions in any of the three laboratories in computer research at PARC.

Shlomo will be here for 2 days to allow time for interviewing.  Interested persons should contact Mimi Gardner to get in the schedule.  


<TIMESROMAN

<TIMESROMAN

<TIMESROMAN

<bTIMESROMAN

<)TIMESROMAN

<
TIMESROMAN

<TIMESROMAN

< TIMESROMAN

<TIMESROMAN

<TIMESROMAN

<oTIMESROMAN|z7------------------------------------------------------------



     ----- End Forwarded Messages -----

------------------------------
*start*
00445 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 11:00 PST
From: vanMelle.pa
Subject: Re: TEdit format messages: yuchh!
In-reply-to: Putz.pa's message of Fri, 6 Apr 84 10:23:56 PST
To: Putz.pa
cc: TEditSupport, LafiteSupport.pa, MessageSystemImplementors^.pa

We quite agree.  Putting the formatting info in a separate grapevine item is on the task list.  Don't know how soon it will happen, though.

	Bill
*start*
00376 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 11:21 PST
From: Burton.pa
Subject: Re: AR 539: Break middle-button pop-up menu should switch the TTY to the break window
In-reply-to: LispSupport.pa's message of 6 Apr 84 10:20:44 PST (Friday)
To: LispSupport.pa
cc: kaplan.pa

I can't duplicate this.  Can we get together on it?

richard

*start*
01247 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Fri, 6 Apr 84 11:26:44 PST
From: Deutsch.pa
Subject: Re: AR mechanism, and accessibility of the Lisp system
To: Masinter
cc: LispSupport, Bobrow, Sheil
In-Reply-To: "Masinter's message of Thu, 5 Apr 84 17:09:00 PST"

Larry,

Thanks for the timely and informative reply.

I was going on out-of-date information about the external database: I loaded in WHEREIS last night and it did exactly what I wanted it to.  Thanks for the pointer.

I would feel much, much better about the AR system if LispSupport could make a statement of the form "Within N days of submitting an AR, you will be notified of its approximate priority and likely resolution date."  When bug reports were being handled informally, I felt I had reasonable assurance that someone with the competence to evaluate and repair the bug would look at it within a few days: with the AR system, it feels as though new procedural barriers have been interposed, with the effect that it may be a long time before anyone competent even sees the problem, and the old feeling of a personal contract with the system maintainers has to be replaced by an impersonal (and explicit) contract with the support organization.*start*
00172 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 11:45 PST
From: Burton.pa
Subject: Lisp: ar #511 has been fixed
To: LispSupport.pa


*start*
00185 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 11:56 PST
From: Burton.pa
Subject: ar# 522
To: Lispsupport
cc: le.pasa

fixed.  Thanks.

richard

*start*
00158 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 12:00 PST
From: Burton.pa
Subject: ar# 378 fixed
To: Lispsupport.pa



*start*
00178 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 12:01 PST
From: Burton.pa
Subject: ar# 441 fixed - break window to top
To: Lispsupport.pa

*start*
00487 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 11:48 PST
From: Burton.pa
Subject: Lafite: can't send msg without body
To: LafiteSupport.pa

Lafite System Date: 30-Mar-84 17:28:59
Lisp System Date:  5-Apr-84 19:01:16
Machine: Dorado (Kay)
Microcode version: 24,4
Memory size: 10000
Frequency: Once 
Impact: Annoying

Trying to send a message with only a subject and a to field (not followed by any cr's) broke trying to parse the header.

richard

*start*
00308 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 12:11 PST
From: vanMelle.pa
Subject: Re: Lafite: can't send msg without body
In-reply-to: Burton.pa's message of 6 Apr 84 11:48 PST
To: Burton.pa
cc: LafiteSupport.pa

Thank you.  This is a bug in Tedit, assigned AR 461.
*start*
00592 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 12:13 PST
From: vanMelle.pa
Subject: Re: AR 207: SYSOUT to floppy doesn't reset FLOPPY.MODE after
In-reply-to: ROACH.PA's message of 5 APR 84 09:53 PST
To: ROACH.PA
cc: vanMelle.PA, LispSupport.PA

I would not say the impact is severe, but it clearly is a bug:

13_MAKESYSDATE
"29-Mar-84 17:34:40"
14_FLOPPY.MODE]
PILOT
15_SYSOUT({INDIGO}<LISP>TEMP>FOO.SYSOUT]
{INDIGO}<LISP>TEMP>FOO.SYSOUT;1
16_FLOPPY.MODE]
SYSOUT
17_PL FLOPPY
FILEDATES : (("20-Mar-84 19:45:55" . {PHYLUM}<LISPCORE>SOURCES>FLOPPY.;3))

*start*
00216 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 12:16 PST
From: Burton.pa
Subject: ars # 434 and 435 - inspect printlevel doc
To: LispSupport

Updated file WPDISPLAYTOOLS.IM.


*start*
00397 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 12:18 PST
From: Burton.pa
Subject: Re: AR 421: Masked Icons should reflect background better
In-reply-to: LispSupport.pa's message of 31 Mar 84 14:46:00 PST (Saturday)
To: LispSupport.pa

Change this to difficulty hard.  There is no way for the icon to be informed when the windows underneath it do something.
*start*
00566 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 12:12 PST
From: Jellinek.pa
Subject: Lafite: TTYINMETA(T)
To: LafiteSupport.pa
cc: TEditSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dolphin

I like to run with TTYINMETA(T), which lets me use the bottom-blank key to do various nice things.  Unfortunately, it causes middle-blank to lose its "skip-to-next-field" meaning in the Lafite message editor, redefining it to mean "insert an `€'".
This is not a good thing.
		Herb
*start*
00826 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 12:28 PST
From: vanMelle.pa
Subject: Re: Lafite: TTYINMETA(T)
In-reply-to: Jellinek.pa's message of 6 Apr 84 12:12 PST
To: Jellinek.pa
cc: LafiteSupport.pa, TEditSupport.pa

This is a difficult problem, known as "need way to input blank keys and extra Dlion keys that coordinates with MetaShift enabled."  The main difficulty is that input from the keyboard is limited to 8-bit characters only, and that leaves no extra characters left over if MetaShift is on (e.g., if you enable MetaShift, then Top-Blank and Meta-A are indistinguishable).


The workaround for your immediate problem is  

(TEDIT.SETSYNTAX 200Q 'NEXT)

Also, if you happen to like Top-Blank being the Tedit Undo key (I don't), you should also

(TEDIT.SETSYNTAX 0 'UNDO)
*start*
00629 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 16:10 PST
From: Moran.pa
Subject: Lafite:  CAN'T DISPLAY ?-MESSAGE 
To: LafiteSupport.pa
cc: Moran.pa

Lafite System Date: 30-Mar-84 17:28:59
Lisp System Date:  1-Mar-84 14:24:22
Machine: Dorado (Moran)
Microcode version: 24,4
Memory size: 10000
Frequency: ALWAYS
Impact: ANNOYING

EVERY TIME I TRY TO DISPLAY A NEW MESSAGE (IE, ONE WITH A ? IN FRONT OF IT), IT BREAKS WITH AN "ARG NOT LINEDESCRIPTOR: NIL ERROR" MESSAGE.  THE MESSAGE DOES GET DISPLAYED, HOWEVER, SO I CAN JUST ^ OUT OF IT.  BUT THE ? DOESN'T GO AWAY IN THE BROWSER WINDOW. 
*start*
00645 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 16:20 PST
From: vanMelle.pa
Subject: Re: Lafite:  CAN'T DISPLAY ?-MESSAGE 
In-reply-to: Moran.pa's message of 5 Apr 84 16:10 PST
To: Moran.pa
cc: Sannella, LafiteSupport.pa

I suspect you are running too old a version of Lisp for this new version of Lafite (in general, software on <LispCore> has no guarantee of running in the older sysouts on <Lisp>).  In particular, your version of Tedit may be too old.

Mike, is there a reason that there isn't a newer version of Full.sysout on <Lisp>Current> to correspond to the newer Lisp.sysout (13-Mar-84)?

	Bill
*start*
00516 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 09:19 PST
From: Sannella.pa
Subject: Re: Lafite:  CAN'T DISPLAY ?-MESSAGE 
In-reply-to: vanMelle.pa's message of 5 Apr 84 16:20 PST
To: vanMelle.pa
cc: Moran.pa, Sannella.pa, LafiteSupport.pa

Yes there is a reason (that there isn't a newer version of Full.sysout on <Lisp>Current>), but not a good one --- I had problems making the corresponding full.sysout.

I am about to release a new, coordinated set of sysouts to lispnew.
*start*
01489 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 15:33 PST
From: Sannella.pa
Subject: [Sheil.pa: [Raim.pasa: Teknowledge trip report]]
To: LispSupport

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

Date:  4 Apr 84 10:03 PST
From: Sheil.pa
Subject: [Raim.pasa: Teknowledge trip report]
To: sannella

Pls check that these ARE in fact submitted as ARs.

Beau

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

Date: Tue, 3 Apr 84 16:14 PST
From: Raim.pasa
Subject: Teknowledge trip report
To: Pahlavan
cc: VanMelle.PA, Sheil.PA, Raim

Marcel,

I visited Teknowledge on April 2 in response to yet another urgent invitation from Bill White.  There are two pressing problems, both of which are being submitted as AR's.

1.  0915 abort when installing Lisp from VAX.  The problem is either in Jerry Fungs Install Tool or in DEI version 6.  Jerry and Phil are investigating this.  In the meantime, Teknowledge will try using a potentially unreliable workaround to recover from the 0915.

2.  9016 and 9318 Raid calls.  Teknowledge claims that at least once per day per 1108, Lisp aborts with 9016 or 9318 MP codes.  Teknowledge staff still prefer to timeshare on the 2060 rather than risk losing work on the 1108.  Because of  (1) above, I was unable to  find a way to reproduce these problems for Bill van Melle.  I will schedule another trip with the 0915 problem has stabilized. 

--Marty


     ----- End of Forwarded Messages -----

     ----- End of Forwarded Messages -----
*start*
01089 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 13:18:20 PST (Thursday)
From: Sannella.PA
Subject: AR 176: SYSOUT[{FLOPPY}] produces bad sysout
To: Roach.pa
cc: Raim.pasa, LispSupport.pa

Isn't this bug fixed in the 20-Mar-84 FLOPPY.DCOM, which is in the sysout that is down being tested right now?


----------------------------------------------------------------
Date:  5 APR 84 10:22 PST
From: ROACH.PA
Subject: AR176 WORKAROUND
To:   LISPSUPPORT

     Although AR176 has been fixed, FUGUE.6 has gone out the door
without it and customers who expect to SYSOUT even though it isn't
"supported" (read documented) are likely to gripe.  I think the
following patch will help:
	(ADVISE '(\PFLOPPY.TRUNCATEFILE IN \SFLOPPY.CLOSESMALLFILE)
		'BEFORE
		'LAST
		'(SETQ LASTPAGE (ADD1 LASTPAGE)))
This patch should be suggested to any user in possession of Fugue.6
griping about 9005s, sysouts almost working but not quite, not being
able to chat in a sysout made by floppy, etc.
				Kelly

----------------------------------------------------------------
*start*
00385 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 17:15 PST
From: Stansbury.pa
Subject: Raid call
To: vanMelle, Lispsupport
cc: Stansbury.pa

There is a call to raid in \dl.xferdisk in diskdlion; since you seem to be on a binge of changing raid calls to mp calls, could you change this one too?  It might help us track some stuff down.

-- Tayloe.
*start*
00381 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 00:44 PST
From: Nuyens.pa
Subject: TEdit: resetsave the window
To: TEditSupport.pa
cc: Nuyens.pa
TEdit-System-Date:  5-Apr-84 10:49:15
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dorado

if the user designates a window, then tedit breaks, ^ leaves the window up.  should close it.

Greg
*start*
01122 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 15:57 PST
From: vanMelle.pa
Subject: TEdit: smashing WINDOW prop of EXEC process on HARDRESET
To: TEditSupport
cc: vanMelle.pa

TEdit System Date:  2-Mar-84 16:54:27
Lisp System Date: 29-Mar-84 17:34:40
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Moderate (prevents copy selection into EXEC window)

There is a somewhere in tedit a resetsave containing (PROCESS.WINDOW (THIS.PROCESS) OLDVALUE).  The problem is, this form gets run on a HARDRESET to clean up after the process, at which point the (THIS.PROCESS) you were thinking of is no longer.  The resetsave should instead be something like (RESETSAVE NIL (LIST 'PROCESS.WINDOW (THIS.PROCESS) oldWindow)), so that the form contains the affected process directly, rather than relying on (THIS.PROCESS) to be correct.

(An alternative strategy is for PROC to temporarily resurrect each dead process just long enough to run their resetforms, probably a good idea anyway, but this is harder, and not necessary to fix this problem.)
*start*
00698 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 17:25:44 PST (Thursday)
From: Halvorsen.PA
Subject: Re: AR 394: "Problem with Domain token" _ Fixed
In-reply-to: JFung.pasa's message of 5 Apr 84 11:13:44 PST (Thursday)
To: JFung.pasa
cc: Halvorsen,Lispsupport

First time I used the new version of the installlisptool I it booted Tajo when I confirmed boot of the destination volume after having done a remote boot from Lisp1 to Lisp.  I believe that I noticed out of the corner of my eye that the Volume type was indicated as NonLisp (but I wouldn't swear to that). I had Lisp1 selected as the volume in the tool.  What's this new volume type business?

Kris
*start*
00875 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 08:31:10 PST (Friday)
From: JFung.pasa
Subject: Re: AR 394: "Problem with Domain token" _ Fixed
In-reply-to: Halvorsen.PA's message of 5 Apr 84 17:25:44 PST (Thursday)
To: Halvorsen.PA
cc: JFung, Lispsupport.PA

Kris,

I am sorry I have not mentioned the changes on this version.  I was planning to announce the "official" next release with the next major lisp release.  I put in LispCore>Next so some people if wanted can "try" it out first.

Anyway,  the new Volume-Type is a temporary kluge(sp?) for us to boot non-lisp volumes (like Tajo, Copilot, Star).  I will try to make this transparent to the users but right now, you have to tell the tool whether the volume you want to boot is Lisp or Non-Lisp.

Sorry for the confusion and thanks for trying the "prelease" tool.


	/Jerry
  
*start*
00951 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 10:16 PST
From: Pindar.pa
Subject: Lafite: Shifting user while in Lafite
To: LafiteSupport.pa
cc: Pindar.pa, AHenderson.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 29-Mar-84 16:35:49
Machine-Type: Dandelion

Folk:

(From Austin Henderson)

I was logged in as me when I loaded Lafite into a Lisp.Sysout (not Full). I started Lafite, but then realized that I wanted to be logged in as Maia Pindar. This realization came when Lafite was asking for confirmation to create files in {Phylum}<AHenderson>Lisp>. I didn't confirm, but then could not figure out how to redirect Lafite. I logged in as Maia, and connecte to her directory, turned Lafite OFF and ON again, and still it insisted on being AHenderson. Note however that this form was created with her name on it. Help with either a model or a command or a change in the behavior.

Thanks,

Austin
*start*
00268 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 APR 84 01:03 PST
From: MASINTER.PA
Subject: please attn 212 to vanMelle for additional explication
To:   lispsupport
cc:   vanmelle

Bill, do you have some ideas about what this is about?
*start*
01431 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 11:28 PST
From: vanMelle.pa
Subject: Re: please attn 212 to vanMelle for additional explication
In-reply-to: MASINTER.PA's message of 6 APR 84 01:03 PST
To: MASINTER.PA
cc: lispsupport.PA, vanmelle.PA

PROMPTFORWORD has a "feature" whereby if you don't type anything at it, then every 60 seconds it calls RINGBELLS.  This is implemented by a timer in its input character routine.  This routine, being a good citizen, calls \TTYBACKGROUND while it is idle, which has the side effect of blocking (until next bugged) if you take the tty process away from PROMPTFORWORD.

(1) I hate this feature.  My understanding of why this feature is in there is because of calls to PROMPTFORWORD in the Promptwindow, which often go unnoticed.  [Side note: submit ar "Flush RINGBELLS from PROMPTFORWORD (or make it optional)"].

(2) But given this feature, its behavior in your case is probably correct.  If you are typing at window x and suddenly the machine starts ringing a bell at you because you haven't typed in window y, what are you supposed to make of it?  Flashing the window where the prompting is going on would make much more sense.

(3) For this particular problem, the correct solution I think is for Tedit to do its prompting in or near its own window.  John says he is adding a promptwindow to Tedit (like Lafite), so this may already be done.
*start*
00726 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Sender: Sannella.PA
Date:  6 Apr 84 11:56:05 PST (Friday)
Subject: Re: AR: 65 Fix MAKELISPFLOPPIES.DOC _ Broken
In-reply-to: Masinter's message of 5 Apr 84 17:22 PST
To: Masinter
cc: JFung.pasa, LispSupport
From: LispSupport.pa

1) I have moved [phylum]<Lisp>Current>MakeLispFloppies.DOC to <lispcore>next>.

2) In general, nobody but I should put anything on [phylum]<lisp>

3) AR 65 started when it seemed that there was a problem with the InstillationUtility.  Eventually, this was discovered to be untrue, so I converted the AR to the more general one of documenting the floppy-making procedure, which seemed to be one of the causes of the confusion.
*start*
00657 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 12:09:44 PST (Friday)
From: JFung.pasa
Subject: Re: AR: 65 Fix MAKELISPFLOPPIES.DOC _ Broken
In-reply-to: Sannella.PA's message of 6 Apr 84 11:56:05 PST (Friday)
To: Sannella.PA
cc: Masinter.PA, JFung, LispSupport.PA

Thanks Mike.

In the future I'll notify you of the files (located at Rose) when needed to be moved to Phylum.  (I got confused always on where to store files, I am trying to keep myself straight on this)

Are we agreed that there is no more "open" problems on this AR.  I think the doc contains the right script to make the InstallationUtility floppy.
*start*
01350 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 16:07 PST
From: vanMelle.pa
Subject: TEdit: Extending selection unstable
To: TEditSupport
cc: vanMelle.pa

TEdit System Date:  2-Mar-84 16:54:27
Lisp System Date: 29-Mar-84 17:34:40
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Annoying (very)

Extending a selection with Right is "unstable" in that if I hold Right down and sweep the mouse up and down, the fixed end of the selection moves.

A very obvious, and most annoying instance of this is as follows: put caret somewhere.  Now, intending to select from there to somewhere to the right of it in the line, click down on Right somewhere to the right of the caret and slightly below, so that what you get instead is selection thru the next line.  If you now correct by moving the mouse up to the original line, you see that the start of your selection is no longer where the caret was; in fact, the caret has moved to where the cursor now is (or to the beginning of its word if the original selection was with middle), and the selection extends thru the next line.

Actually, with a little experimenting, I see you can replace "right" with "left" (not referring to buttons) and/or interchange "above" and "below" and still demonstrate this losing behavior.
*start*
00486 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 13:59 PST
From: Masinter.pa
Subject: Lisp: cross reference SPAWN.MOUSE tools under the buttoneventfn documentation
To: LispSupport.pa
cc: Masinter.pa
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dorado

not entirely obvious from the window system document that if your buttoneventfn breaks or runs forever, you should probably SPAWN.MOUSE. A cross reference there would help.
(Source: Gadol).
*start*
00565 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 14:42 PST
From: Kaplan.pa
Subject: Re: AR 521: DMPHASH prints out (PUTHASH 1 2 NOBIND) --addenda
In-reply-to: LispSupport.pa's message of 6 Apr 84 10:16:49 PST (Friday)
To: LispSupport.pa

For some reason this behavior does not show up on D, only in 10, although from the code even in D it is surprising that we haven't seen the problem.

Anyway, I fixed the code (MACHINEINDEPENDENT), and the fix will appear in 10 whenever we do another 10 loadup.

Mark this as fixed.

--Ron
*start*
00540 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 14:47 PST
From: Masinter.pa
Subject: want the 'background menu' to come up on middle button, not right button
To: Burton, LispSupport
cc: Masinter.pa

It would be a lot more consistent if the stuff in the background menu popped up on middle button (operations that do things) rather than on right button (window commands). Maybe Snap and Hardcopy on right button, and PSW, TEdit, SendMail, ShowAR etc on middle?

this is 'wish' 'Design-UI' 'annoying'. 
*start*
00468 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 15:33 PST
From: Burton.pa
Subject: Re: AR 546: CLEAR doesn't always clear bottom line of borderless window
In-reply-to: LispSupport.pa's message of 6 Apr 84 13:06:28 PST (Friday)
To: LispSupport.pa
cc: Jonl.pa

I've tried several ways of reproducing it and haven't been able to.  Where you changing the DSPCLIPPINGREGION of the window?  

Let me know if it happens again.

richard
*start*
00250 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 16:43 PST
From: Masinter.pa
Subject: AR#191, EVALV
To: LispSupport
cc: Sheil

EVALV now has a 'release' flag. Documentation in manual updated. Mark AR as FIXED.


*start*
00519 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 16:18 PST
From: Jellinek.pa
Subject: Lisp: function CLEAR
To: LispSupport.pa
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dolphin

I suggest that the undocumented function CLEAR, which is used by the window system, be renamed.  CLEAR is a not-uncommon function name for people to use in their own systems; redefining CLEAR causes serious problems (e.g. CHANGEBACKGROUND breaks).  Maybe \CLEAR would be a better name?

		Herb

*start*
00387 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 16:43 PST
From: Masinter.pa
Subject: ARs on FILEBROWSER
To: LispSupport
cc: Sheil

I'm not willing to accept ARs on FILEBROWSER for my own attention, no matter what the priority. I suggest you mark them attn: Lisp for now. (AR #324 is the one that caused this message, but I think there are others.)
*start*
00794 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 17:20 PST
From: Masinter.pa
Subject: AR#118, do EDIT WHERE given stack ptr
To: Maxwell, LispSupport, Burton

John, your request:

I would like it if when I asked for the source of a procedure that is on the call stack, the breakpoint handler would scroll to the currently executing line and underline it.  Masterscope does this when you say . EDIT WHERE . . . , so it seems like it is possible.

is sort of handled by the EDIT command in the break window/menu. I.e., if you EDIT using that command, it is supposed to do exactly that.

Maybe it didn't work for you? Or the documentation isn't clear?

How else did you get into the editor that it would be possible to know that you were executing somewhere?

*start*
00203 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 17:20 PST
From: Masinter.pa
Subject: AR#118
To: LispSupport

Status_ Incomplete pending further input from Maxwell.
*start*
00239 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 17:51 PST
From: Masinter.pa
Subject: AR#277 Status_ Fixed
To: LispSupport
cc: Kaplan


compiling now checks & warns if you attempt to bind a constant.

*start*
00334 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 18:05 PST
From: Masinter.pa
Subject: new ar submit as fixed, documentation
To: lispsupport

I moved the discussion of SUBRs to the Interlisp-10 part of the manual. I cleaned up the description of SMARTARGLIST to correspond more with the reality.

*start*
00671 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 18:18 PST
From: vanMelle.pa
Subject: Ar updates
To: LispSupport
cc: vanMelle.pa

AR's 533, 485,  124 are of at most Moderate impact, because it is easy to avoid or work around them.

Ar 533: Workaround: Don't try to Answer a message that has no From field (if the code were working correctly, you would at best get the response "can't answer this message").  Difficulty: Easy

Ar 485: Difficulty easy, impact annoying, Workaround: if you have a 10Mhz but not a 3Mhz ethernet card in your dolphin, make sure you run with the 10MHz microcode!

Ar 124: Impact moderate, difficulty easy.
*start*
00159 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 15:09 PST
From: Kaplan.pa
Subject: AR464 fixed
To: Lispsupport, Roach


*start*
00542 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 APR 84 14:15 PST
From: MASINTER.PA
Subject: AR, compiler, ation
To:   lispsupport

Date: 25 Jan 84 00:48 PST
From: Stansbury.pa
Subject: Lisp: Compiler message
To: Lispcore^, Masinter
cc: Stansbury.pa
Lisp-System-Date: 21-Jan-84 09:05:46
Machine-Type: Dolphin

What does the compiler message 

In FOOBAR:
(T - unusual CDR arg list)
((FOOBAR not compiled))

mean?  Happened to me twice, and I can't find anything weird in either of the two functions.

-- Tayloe.
*start*
00464 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 15:19 PST
From: Kaplan.pa
Subject: AR 340:  OUTFILEP returning NIL for CORE 
To: Lispsupport, Vanmelle, Jellinek
cc: Kaplan.pa

I couldn't get it to do this.  I tried OUTFILEP on old and new file names, and it always behaved properly.  Could you give me an actual example that fails?

If not, then the status on this should be switched to FIXED (or Closed or whatever).

--Ron
*start*
00563 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: lispar.auto
Date:  7-Apr-84 22:39:56 PST
Subject: Re: AR 340:  OUTFILEP returning NIL for CORE
In-reply-to: Kaplan.pa's message of 7 Apr 84 15:19 PST
To: Kaplan.pa
cc: Lispsupport.pa, Vanmelle.pa, Jellinek.pa

It happened to me. I take it back that it was exactly {CORE}. Rather, I was running on a DLion with the core-device {DSK}, and connected to {DSK}, and OUTFILEP(FOO) returned NIL. 

I was running in [maxc]<masinter>rosie.sysout which was based on the fugue.6/carol.1 release.

*start*
00397 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: kaplan.pa
Date:  8-Apr-84 16:26:08 PST
Subject: Re: AR 340:  OUTFILEP returning NIL for CORE
In-reply-to: lispar.auto's message of 7-Apr-84 22:39:56 PST
To: lispar.auto
cc: Kaplan, Lispsupport, Vanmelle, Jellinek

Can you make it happen at will?  Please be more specific about the circumstances under which it happens.

*start*
00565 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: lispar.auto
Date:  8-Apr-84 18:12:17 PST
Subject: Re: AR 340:  OUTFILEP returning NIL for CORE
In-reply-to: kaplan.pa's message of 8-Apr-84 16:26:08 PST
To: kaplan.pa
cc: lispar, Lispsupport.pa, Vanmelle.pa, Jellinek.pa, Masinter.pa

Yes, Ron, I could make it happen at will. Walk up to a DLion and say OUTFILEP({DSK}FOO) . Recall that DSK on DLions without DLIONFS is done by COREDEVICE(DSK).

It happened reproducably, as I mentioned in my message, using [maxc]<masinter>ROSIE.SYSOUT.

*start*
00592 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 09:34 PST
From: Kaplan.pa
Subject: Re: AR 340:  OUTFILEP returning NIL for CORE
In-reply-to: lispar.auto's message of 8-Apr-84 18:12:17 PST
To: Masinter.pa
cc: kaplan.pa, Lispsupport.pa, Vanmelle.pa, Jellinek.pa 

The only thing that I can make fail, either on {CORE} or FOO with (COREDEVICE 'FOO) is that OUTFILEP with an explicit version given (i.e., a full name) returns NIL.  OUTFILEP of a partial name seems to behave quite properly.

Did you observe failure in other than this specific case?

--Ron
*start*
00389 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 09:57 PST
From: Jellinek.pa
Subject: Re: AR 340:  OUTFILEP returning NIL for CORE 
In-reply-to: Kaplan.pa's message of 7 Apr 84 15:19 PST
To: Kaplan.pa
cc: Lispsupport.pa, Vanmelle.pa, Jellinek.pa

Actually, this was Larry's bug - I just typed it in for him.  I'll forward your response to him.
		Herb
*start*
00679 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 15:29 PST
From: Kaplan.pa
Subject: AR 29:  Miising accessfns for STREAM
To: Lispsupport, Vanmelle

This is not a problem with STREAMs.  It seems to be a problem with all sysem datatype declarations:  The function SAVEONSYSRECLST on RECORD only includes the fields of the datatype, not the tail of the declaration, which is where the accessfns would be.

I don't know who decided to do it this way or why, but Bill was the last editor of this function.

Not understanding the issues, I won't work on this further.  Either it should be passed on to Bill, or marked as declined, I guess.

--Ron
*start*
00923 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 15:46 PST
From: vanMelle.pa
Subject: Re: AR 29:  Miising accessfns for STREAM
In-reply-to: Kaplan.pa's message of 7 Apr 84 15:29 PST
To: Kaplan.pa
cc: Lispsupport.pa, vanMelle, Burton.pa

One of the reasons that SYSRECORDS does not save the tail of the declaration is that the inspector doesn't use it.  I assume it was Richard's decision that inspect of a system record included only the "real" fields, not any accessfns or other overlays; but in any case, I agree with it.  In fact, I often wish this were true for user records as well; in most cases I have seen, the additional fields are just synonyms or alternative perspectives on the main record, and I find it confusing and/or annoying to find them in the inspect window.  Once in a while, the accessfns even have undesirable side effects when accessed by the inspector.

	Bill
*start*
00454 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 15:58 PST
From: vanMelle.pa
Subject: Lisp: HARDRESET smashes lock state
To: LispSupport.pa

Lisp System Date:  6-Apr-84 18:33:24
Machine: Dandelion (Big-Chip)
Microcode version: 24,4
Memory size: 5777
Frequency: Always
Impact: Annoying

After a hard reset on a Dlion, the lock state established by the Lock/Unlock (Superscript/Subscript) keys is smashed to unlocked.
*start*
00783 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 APR 84 18:18 PST
From: MASINTER.PA
Subject: TIMEALL figures wrong
To:   lispsupport

Date: 13 JAN 84 18:27 PST
From: JONL.PA
Subject: (DISABLEGC) on BOYER benchmark
To:   LispCore^

is a net loss.  The swap time for new pages dominates.  Approximately 50 secs
instead of 17CPU and 13GC.

Curiously, however, TIMEALL reports elapsed time and CPU time the same.
Shouldn't there be some factoring out for disk swapout time?  TIMEALL also shows
PAGEFAULTS = 1934
SWAPWRITES = 1452
DISKOPS = 1450
FIXP LISTP
4    226469
----------------------------------
Attn: vanMelle, Jellinek
This is Environment/Performance tools (sort of)

Impact: Moderate
Problem type: bug

Looks like there's a glitch in the stats. 
*start*
00501 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 21:25 PST
From: christman.pa
Subject: Lafite: losage
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 31-Mar-84 23:30:06
Machine-Type: Dorado

Often I start lafite and it says "reading TOC ... reading additional message"
and I get my mail file PLUS all the new messages I deleted the last time
i ran lafite.  I always "quit" from lafite.   Am I doing something
obviously wrong?

-dave
*start*
00529 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Apr 84 20:59 PST
From: vanMelle.pa
Subject: Re: Lafite: losage
In-reply-to: christman.pa's message of 7 Apr 84 21:25 PST
To: christman.pa
cc: LafiteSupport.pa

Your symptoms are consistent with NOT doing an Update on the file and not doing a Quit (which does an Update on all your files).  If you have a case where you you are sure you did a Quit and the next time you started Lafite you find previously deleted messages, I'd like to see it.

	Bill
*start*
00593 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 APR 84 11:33 PST
From: DEUTSCH.PA
Subject: MIN/MAX.SMALLP/FIXP not bound in Interlisp-10
To:   LispSupport

(As an Interlisp-10 user, I don't know how to get to the AR system,
so I am continuing to send bug reports to LispSupport.  If there is
a way for me to use the AR system from a dumb terminal, let me know.)

Contrary to p. 2.38 of the Interlisp manual, the variables
MIN.SMALLP, MAX.SMALLP, MIN.FIXP, and MAX.FIXP are not bound in
Interlisp-10.  MIN.INTEGER and MAX.INTEGER are bound to reasonable values.
*start*
00548 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: lispar.auto
Date:  8-Apr-84 18:04:22 PST
Subject: Re: MIN/MAX.SMALLP/FIXP not bound in Interlisp-10
In-reply-to: DEUTSCH.PA's message of 8 APR 84 11:33 PST
To: DEUTSCH.PA
cc: LispSupport.PA, Masinter.PA, JonL.PA

Peter,

First, it is always appropriate to just send messages to LispSupport. 

Apparently the Interlisp-10 versions of these constants got dropped somewhere along the line. I seem to recall that they had been set up at one time. Will look into it further. 
*start*
00763 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Apr 84 15:28 PST
From: Sheil.pa
Subject: Re: AR 368: Cannot BREAK S-expr from inside DEdit
In-reply-to: LispSupport.pa's message of 29 Mar 84 12:32:23 PST (Thursday)
To: jordan
cc: LispSupport

Dan:

I cannot make any sense out of this bug report and cannot replicate anything like it.

I'd be happy to look into it if you can give me a reproducible example or ask me to look at an instance if you cannot give me a reproducible version. But a report that something happens "For a particular function, i.e., not for *all* functions" without a pointer to the defn of said fn is rather hard to make anything of.

Beau

LispSupport: Status: Declined, Reason: Insufficient specification

*start*
00563 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: lispar.auto
Date:  8-Apr-84 18:08:45 PST
Subject: Re: AR 368: Cannot BREAK S-expr from inside DEdit
In-reply-to: Sheil.pa's message of 8 Apr 84 15:28 PST
To: Sheil.pa
cc: jordan.pa, LispSupport.pa, masinter.pa

(Minor procedural point; ARs that have incomplete information can be marked "incomplete" rather than "declined". "declined" is interpreted as "that's not a bug, its a feature!". "incomplete" means "Sounds like a bug all right, but insufficient information to track it down".
*start*
00373 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Apr 84 15:23 PST
From: Sheil.pa
Subject: Re: AR 359: EditOps menu should follow moved window
In-reply-to: LispSupport.pa's message of 29 Mar 84 11:14:56 PST (Thursday)
To: LispSupport.pa
cc: JELLINEK

This feature was added in the new DEdit, altho I don't think my release msg said so.

Beau

*start*
00527 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 13:57 PST
From: Masinter.pa
Subject: Re: Lisp: CH.LOOKUPUSER
In-reply-to: Sheil.pa's message of 8 Apr 84 15:32 PST
To: Sheil.pa
cc: LispSupport.pa, Masinter.pa, vanmelle.pa, Raim.pasa, Cooper


Beau,

I've added CH.LOOKUP.USER to the list of HITATOMS uses. I wonder if this list of HITATOMS should be applied to the current release. The new HITATOMS is currently on <lispcore>Sources>HITATOMS.

If this has an AR # I don't know what it is.
*start*
00396 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Apr 84 15:32 PST
From: Sheil.pa
Subject: Lisp: CH.LOOKUPUSER
To: LispSupport.pa
cc: Masinter, vanmelle

Lisp-System-Date: 30-Mar-84 17:16:13
Machine-Type: Dolphin

Before the next release CH.LOOKUPUSER **must** be added to the smashed atom list.

Attn: Masinter, Priority: Absol, Diff: Easy, Impact: Serious.

Beau

*start*
00781 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Apr 84 16:36 PST
From: vanMelle.pa
Subject: new PROC
To: LispSupport
cc: LispCore^

This fixes AR's 101, 194, 193, and 289.

Also changes the behavior of spawned mouse processes in favor of keeping the original mouse process alive and killing the new process once the interaction that required the spawned mouse completes.  This either fixes or ameliorates, depending on your point of view, AR 31 (too many TTY windows created when you SET in INSPECT).

There is a new process prop RESTARTFORM, which is the form used (instead of the original form given to ADD.PROCESS) if
 the process is restarted.  Of course, the process must also have a non-nil RESTARTABLE prop for this to have any effect.

	Bill*start*
01061 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 15:23 PST
From: Masinter.pa
Subject: demo file
To: LispSupport
cc: Burton, Stansbury, Withgott

Michael:

I took the version of POLYGONS and LINES that were in FPOLY, fixed them up to remove the kludge for interfacing to the "old" microcoded drawline, and put them on a new file, LINEDEMO.DCOM.

I was reluctant to change POLYGONS; I'm not sure exactly what happened but, the demo POLYGONS got changed to look pretty different from the old version on POLYGONS.DCOM, there are some things in the old version that aren't in the new, but that the old version doesn't seem to work (the menu stuff doesn't, at least.)

Rather than sort out the differences between POLYGONS and FPOLY, I just made a new file LINEDEMO which had my 'best shot' at what would fly with DEMO.SYSOUT.

I think we can now throw out FPOLY, but may want to retain POLYGONS for further investigation (but not distribute it.)

 Meg: the "LINES" demo is now on LINEDEMO.DCOM. Just load it and call (LINES).


*start*
01533 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 15:51 PST
From: Masinter.pa
Subject: [Martin.pasa: [VANBUER@USC-ECL.ARPA: CHANGEBACKGROUND and bitmaps]]
To: Burton
cc: LispSupport

AR: Window/other

READBITMAP barfed, non-numeric arg, when I tried to merely shift-select this into my EXEC window. The READBITMAP wanted

(24 14 1

rather than (24 14

as the first line. Did the format of bitmaps on files changed? Wasn't it made backward compatible?

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

Date:  5 Apr 84 16:56 PST
From: Martin.pasa
Subject: [VANBUER@USC-ECL.ARPA: CHANGEBACKGROUND and bitmaps]
To: LispUsers^.pa
cc: Martin.pasa

Thought you all might like to see this.  

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

Received: from USC-ECL.ARPA by PARC-MAXC.ARPA; 30 MAR 84 08:27:10 PST
Date: 30 Mar 84 08:26 PST
From: VANBUER@USC-ECL.ARPA
Subject: CHANGEBACKGROUND and bitmaps
To: Martin.pasa
cc: VanBuer@USC-ECL.ARPA

From playing around with this, the restriction on bitmaps to get "right" results
is that the width of the bitmap must be a multiple of 8 and at least 16.  The
height is unrestricted.
Try this one:
(SETQ BBB(READBITMAP))
(24 14
"@@AOO@@@"
"@@B@@H@@"
"@@B@@H@@"
"@@D@@D@@"
"@@D@@D@@"
"@@H@@B@@"
"@@H@@B@@"
"OO@@@A@@"
"@@H@@B@@"
"@@H@@B@@"
"@@D@@D@@"
"@@D@@D@@"
"@@B@@H@@"
"@@B@@H@@")
(CHANGEBACKGROUND BBB)

Amazingly, the distortion is only 1% even though it's only a 14x24 tile.
	Darrel
-------

     ----- End of Forwarded Messages -----

     ----- End of Forwarded Messages -----
*start*
03402 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 17:39 PST
From: jordan.pa
Subject: Lisp: windows and eventprops
To: burton
cc: lispsupport.pa, jordan.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

Richard,

	Following up on our discussion of windows and eventfn properties, I would like to mention the following additional observations and suggestions:
(I am focusing on the interaction of CURSOROUTFN, CURSORINFN, and EVENTBUTTONFN).

	Observations:
  
	1)  The triggering of CURSORIN- and CURSOROUTFN is dependent on the buttonstate of the mouse in an inconsistent manner that causes some confusion.  
		a) If I ButtonDown in the Background and then move into window A, A's CURSORINFN is triggered.   Remaining in this DownButtonstate until I leave A, if I
			i)  ButtonUp in the Background, A's CURSOROUTFN is triggered *on the Upstroke* and not when I exit the window.  
			ii) ButtonUp in window B, A's CURSOROUTFN is triggered, along with B's CURSORINFN *on the Upstroke while in B*.  In this case, B's EVENTBUTTONFN is not triggered (consistent with the belief of allowing an easy no-op option for A, I guess, although the button originally went down in the Background and not in A).

		b)  Similarly, If I enter A with ButtonUp, then ButtonDown while in A and move outside A with Button still Down, (i) and (ii) also hold.

	The above implies 1)  that WHEN a window's CURSORINFN/CURSOROUTFN is triggered is dependent on the mousestate, and not always when the window is actually entered/exited, and 2)  after ButtonDowning in the Background, the first window I glide over while Down is essentially selected and committed for that stroke.

	2)  Tracking the mouse with BUTTONEVENTFNs and setting global variables or FLGing via windowprops or whatever to bypass the window handler and consequences due to (1) doesn't really help because, not being able to tell when the CURSORfns will trigger, you don't know where you are (unless you write your own mini-windowhandler).

	Suggestion:

	Simply, I think the CURSOR...FNs should trigger independent of the Buttonstate of the mouse.   This would allow us to provide feedback to the user for what window the cursor is currently over, regardless of whether the buttons are up or down or how they got that way.   In particular, I should be able to UN-highlight a window when the cursor slides out because after that point (until it slides back in) a no-op will be performed, i.e., the window is UN-selected.  
Similarly, I should be able to highlight the current window, independent of where I came from and in what Buttonstate.
	I DO agree that BUTTONEVENTFNs should not trigger for any window anywhere outside the window in which the button went down.  This form of the no-op option appears to be the best and should stay.
	Thus, my suggestion is to give programmers more control once a BUTTONEVENTFN is triggered, let them worry about the CURSOR...FNs side effects as the cursor slides all around the place, but do stop short of changing the feature mentioned in the previous paragraph.  

	Is this possible?  I realize that if this change were made it may cause grief for a lot of existing code.

Dan


p.s.  Menus....  My assumption (as I don't know) is that those aren't little windows at all but boxed items highlighted by an ItemHandler a la WindowHandler under the menu's BUTTONEVENTFN. 

*start*
00521 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 23:17 PST
From: Halvorsen.pa
Subject: TEdit: Para looks disappear with scrolling
To: TEditSupport.pa
cc: Halvorsen.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  6-Apr-84 18:33:24
Machine: Dandelion (Halvorsen)
Microcode version: 24,4
Memory size: 17777
Frequency:  Sometimes 
Impact:  Serious


When you set the margins on a paragraph to  anything but the default full width lines overflow on the left and on the right.*start*
00418 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 15:13 PST
From: Kaplan.pa
Subject: Lafite: Wish:  A Find command in the message displayer
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 13-Mar-84 10:21:31
Machine-Type: Dorado

I'd like to be able to find things in the messages that I'm reading without having to scroll and search with my eyeballs.
*start*
01373 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 APR 84 15:14 PST
From: MASINTER.PA
Subject: AR filebworser
To:   lispsupport
cc:   JELLINEK

0jPlease mark all AR's on FileBrowser attn: Jellinek. We may redirect them later if Herb chooses not to work on the FileBrowser, but maybe he can at least scope it out...
Date: 13 Jan 84 18:57 PST
From: Kaplan.pa
Subject: Lisp: File browser bug
To: Gadol, LispSupport.pa
cc: Kaplan.pa
Lisp-System-Date: 12-Jan-84 18:49:00
Machine-Type: Dorado

I did FILEBROWSER(<FOO>*FUM*) and it turned out that there were files named <FOO>FUMA and <FOO>FUM>X (i.e., with FUM a subdirectory.  The latter files did not show up in the browser, and instead what I saw was <FOO>FUM>.;1 and <FOO>FUM.;2.  When I SEEd those files, what I saw was another browser window with the files in that directory, followed at the end by .;1 and .;2.  When I SEEed one of those, I got exactly the same kind of secondary browser, with the same funny files at the end.

Also, some of the FUM files were in a FIE subdirectory:  <FOO>FIE>FUMZ.  These showed up in the browser as <FIE>FUMZ, which was very misleading.  If the common prefix <FOO> is going to be stripped off, then at least the filename in the browser should not begin with the dishonest open bracket.  If I don't see <FOO>FIE>FUMZ, at least I should see >FIE>FUMZ.

--Ron
*start*
00534 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 18:24 PST
From: Halvorsen.pa
Subject: TEdit: Para looks on indented paras
To: TEditSupport.pa
cc: Halvorsen.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  6-Apr-84 18:33:24
Machine: Dandelion (Halvorsen)
Microcode version: 24,4
Memory size: 17777
Frequency: Intermittent or Always
Impact: Moderate

The problem I reported yesterday where indetended paras appear as overflowing happend when the tedit window is narrower than the page
*start*
00692 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 18:28 PST
From: Halvorsen.pa
Subject: Lafite: Button panel not appearing in message window and lwo frequency playtune
To: LafiteSupport.pa
cc: Halvorsen.pa

Lafite System Date: 30-Mar-84 17:28:59
Lisp System Date:  6-Apr-84 18:33:24
Machine: Dandelion (Halvorsen)
Microcode version: 24,4
Memory size: 17777
Frequency: Once 
Impact:  Annoying

Believe it or not.  When the message sender was expanded from a sent icon the attachedwindow with the buttons was missing (the prompt window on top of it was there) and my Dlion started play a low frequency tune which only disappeared when I killed the process.
*start*
00559 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 19:12 PST
From: Halvorsen.pa
Subject: Lisp: Playtune and no buttons ALWAYS when I try to send a Lafite report
To: Lafitesupport.pa
cc: Halvorsen.pa

Lisp System Date:  6-Apr-84 18:33:24
Machine: Dandelion (Halvorsen)
Microcode version: 24,4
Memory size: 17777
Frequency: Always
Impact:  Ver very Annoying

What a way to avoid bug reports!
  (Whenever I select the Lafite Report form after choosing sendmail in the screen background this annoying situation arises).

		Kris*start*
00797 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 19:30 PST
From: vanMelle.pa
Subject: Re: Lafite: Button panel not appearing in message window and lwo frequency playtune
In-reply-to: Halvorsen.pa's message of 7 Apr 84 18:28 PST
To: Halvorsen.pa
cc: LafiteSupport.pa

Incredible, isn't it...

The missing menu is an unfortunate interaction between Lafite and the just released Tedit; I'm in the process of fixing it now.

The tone, however, is a complete mystery to me.  On the Dandelion I tried it on, it was not a low-frequency tone (rather something above middle C), and happened quite repeatably, though not always the same tone exactly.  It was not the result of a call to BEEPON, which suggests it was somebody trashing a location in the IO page.

	Bill
*start*
00574 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 18:53 PST
From: Halvorsen.pa
Subject: TEdit: SHIFT SELECTION MOVES CARET TO BEGINNING OF FILE
To: TEditSupport.pa
cc: Halvorsen.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  6-Apr-84 18:33:24
Machine: Dandelion (Halvorsen)
Microcode version: 24,4
Memory size: 17777
Frequency:  Once 
Impact: Serious

In shift selecting from one window to another the text was properly inserted in the middle of the file whereupon the fileptr and the caret is moved to the top of the file
*start*
00527 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 19:09 PST
From: Halvorsen.pa
Subject: TEdit: Putting to copyfile from {core} to {phylum} looses all paralooks
To: TEditSupport.pa
cc: Halvorsen.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  6-Apr-84 18:33:24
Machine: Dandelion (Halvorsen)
Microcode version: 24,4
Memory size: 17777
Frequency:  Always
Impact: Fatal

Put to core, copyfile to phylum,  when you get the file from phylum there is no formatting infomation left.

*start*
00500 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 20:15 PST
From: Halvorsen.pa
Subject: TEdit: Top of file displayed when insertion happens at the very end
To: TEditSupport.pa
cc: Halvorsen.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  6-Apr-84 18:33:24
Machine: Dandelion (Halvorsen)
Microcode version: 24,4
Memory size: 17777
Frequency: Once (I wouldn't be surprised if it happened again)
Impact:Serious

Detailed problem description:  That's it
*start*
00481 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 20:18 PST
From: Halvorsen.pa
Subject: TEdit: TEDIT.SELECTED.PIECES broken, non numeric arg
To: TEditSupport.pa
cc: Halvorsen.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  6-Apr-84 18:33:24
Machine: Dandelion (Halvorsen)
Microcode version: 24,4
Memory size: 17777
Frequency: Once
Impact:Serious

Breaks under TEDIT.MOVE on a call to \SLOWIDIFFERENCE (Y is NIL) under \SPLITPIECE.
*start*
00668 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 20:24 PST
From: Halvorsen.pa
Subject: TEdit: SPURIOUS REVERSE VIDEO IN TEDIT WINDOW NOT BEING TYPED AT
To: TEditSupport.pa
cc: Halvorsen.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  6-Apr-84 18:33:24
Machine: Dandelion (Halvorsen)
Microcode version: 24,4
Memory size: 17777
Frequency: Once
Impact:Annoying

When I delete a character in one TEDIT window a spurious region in another window is highlighted.  There are different files in the two windows.  I have previously moved material out of the window with the highlighting.  Highlighting disappears immediately.
*start*
00465 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 20:36 PST
From: Halvorsen.pa
Subject: TEdit: Selection underlining runs through middle of text
To: TEditSupport.pa
cc: Halvorsen.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  6-Apr-84 18:33:24
Machine: Dandelion (Halvorsen)
Microcode version: 24,4
Memory size: 17777

The text was moved in from another window and font was changed from TimesRoman 10 to Modern 12
*start*
00675 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 20:43 PST
From: Halvorsen.pa
Subject: TEdit: You have to scroll top main menu if you want to both set and apply margins
To: TEditSupport.pa
cc: Halvorsen.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  6-Apr-84 18:33:24
Machine: Dandelion (Halvorsen)
Microcode version: 24,4
Memory size: 17777
Frequency:  Always
Impact:  Annoying

Because of the ratio between the size of the teditwindow and that of the main menu, I at least never manage to get a size on the main menu large enough that I don't have to scroll back and forth to set and apply paralooks.  
Very inconvenient.*start*
00370 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 Apr 84 20:57 PST
From: Halvorsen.pa
Subject: Lisp: STACKOVERFLOW UNDER \10MBWATHCER
To: LispSupport.pa
cc: Halvorsen.pa

Lisp System Date:  6-Apr-84 18:33:24
Machine: Dandelion (Halvorsen)
Microcode version: 24,4
Memory size: 17777
Frequency: Once
Impact: 
When PHYLUM was uncommunicative

*start*
01414 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 APR 84 21:28 PST
From: MASINTER.PA
Subject: AR stac/interpreter/moderate
To:   lispsupport

Date: Mon, 9 Jan 84 16:32 PST
Sender: dering.PASA
Subject: Problem Report P5072  (Stack bug (Ucode halt))
To: LispSupport.pa
From: 1100Support


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

Tom Lipkis reports the following:

The following sequence of events causes a microcode halt in Fugue.3.
If a compiled function calls an undefined function, one ends up in a break
with LASTPOS pointing to the \INTERPRETER frame under the compiled
function.  If one then types OK (an odd thing to do, granted, but this
actually happened to someone), one gets back into the same UNDEFINED
FUNCTION break, with LASTPOS (which is now a different stack pointer)
still pointing at the \INTERPRETER frame.  However, buttoning frames in
the backtrace menu at this point does not change LASTPOS (though it does
display the appropriate stuff in the frame window).  Further, a REVERT @
at this point results in a microcode halt.  If one first sets LASTPOS
with an @ FOO command, the revert works ok.

This does not appear to be an Interlisp-D specific problem, as a similar
thing happens in Interlisp-VAX (where, instead of the Ucode halt, it gets
a STACK POINTER HAS BEEN RELEASED error).


(Originally reported  to  1100Support 12/9/83,  not previously forwarded  to LispSupport)

*start*
00447 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 APR 84 21:30 PST
From: MASINTER.PA
Subject: want DEL command
To:   lispsupport

make sure there is an AR ; want DEL command which does what you expect (and is documented in the EXECFNS package.)

Also, make note to fix up documentation on DIR, DEL, etc. to correspond with reality.

Attn: Jellinek (as with FileBrowser, these are really two parts of the same thing.)
*start*
00901 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 APR 84 21:38 PST
From: MASINTER.PA
Subject: comm/NS 
To:   lispsupport

Date: Mon, 9 Jan 84 17:09 PST
Sender: dering.PASA
Subject: Problem Report P5137  (Syntelligence problems)
To: LispSupport.pa
From: 1100Support


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

Magnus at Syntelligence reports the following:

System: Fugue.4

Machine: 1108

1.  Doing IO to the NS file server sometimes results in the prompt window displaying:  Alpha:filing#N not responding.  Alpha is a fileserver name. N is usually a small integer.  The process status window shows several active processes of the form Alpha:filing#N.

2.  The 1108 "hangs up" sometimes during a COPYFILE or LOAD.  During one such load, user did ^H and got the following backtrace:

monitor.await.event
errorset
spp.getbyte
read
lapread
...

(Magnus)

(Reported to 1100Support 1/6/84)


*start*
01090 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 APR 84 22:15 PST
From: MASINTER.PA
Subject: want DISPLAYDOWN on DLion too
To:   LispSupport
cc:   lichtenberg.wbst

Date: 10 Jan 84 10:13:53 PST (Tuesday)
From: lichtenberg.wbst
Subject: Re: FLASHWINDOW and BEEP on the DLion
In-reply-to: JONL.PA's message of 9 JAN 84 20:45 PST
To: JONL.PA
cc: vanMelle.pa, LispSupport.PA


"...  Apparently there is no such simple capability [inverting the screen] for the DLion.   That may explain why a call to ***  FLASHWINDOW *** doesn't seem to do anything on a DLion..."

But there is, THERE IS!

With ABC loaded, do:

(replace DLDISPCONTROL of \IOPAGE with 2048)

to make the screen inverse video, and

(replace DLDISPCONTROL of \IOPAGE with 32768)

to cause the display to be filled with the border pattern, and prevent microcode access to the display (I guess that's what DISPLAYDOWN does on the Dolphin/Dorado - am I correct?)

Resetting those bits to zero will return the display to normal.

I suggest that this be added to (VIDEOCOLOR) at least. 

...

/Mitch.



*start*
00699 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 APR 84 22:17 PST
From: MASINTER.PA
Subject: race condition in permanent menus annoying, confusing
To:   LispSupport

Date: 10 Jan 84 12:31 PST
From: masinter.pa
Subject: Lisp: odd behavior with process status window menu
To: LispSupport.pa
cc: masinter.pa
Lisp-System-Date: 10-Jan-84 08:14:57
Machine-Type: Dandelion

I've observed some odd behavior with the menu in the process status window -- sometimes when I click in the menu, I get into a mode where there is a box around the menu items. Other times, I can't get into that mode.

Perhaps there is some kind of race condition with menus that are permanently up?


*start*
00714 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 APR 84 23:05 PST
From: MASINTER.PA
Subject: More on DISPLAYDOWN request
To:   lispsupport

Date: 10 Jan 84 12:58 PST
From: vanMelle.pa
Subject: Re: FLASHWINDOW and BEEP on the DLion
In-reply-to: lichtenberg.wbst's message of 10 Jan 84 10:13:53 PST (Tuesday)
To: lichtenberg.wbst
cc: LispSupport.PA

I have edited VIDEOCOLOR appropriately.

The other feature, disabling the display, should be used to make startup cleaner, but this requires a little coordination with the boot code (the boot ucode should set the disable bit before turning on the display ucode; Lisp then turns the bit off when it gets the display into place).

	Bill
*start*
00376 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 APR 84 23:06 PST
From: MASINTER.PA
Subject: AR, documentation, window library
To:   LispSupport

The docuementation for READAIS doesn't include a description of AIS format. 

The AIS docuement is online on Maxc as a .bravo file. It probably would do to include it in the READAIS docuementation.

*start*
04181 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 APR 84 23:10 PST
From: MASINTER.PA
Subject: AR, read & print, Minor, Subject: PQUOTE doesn't handle seprs
To:   lispsupport

    196, 10 JAN, To: LispSupport -- problems with PQUOTE
 -  192, 10 JAN, To: ... -- [Don.Cohen <DONC@USC-ISIF.ARPA>: lispuser packages]



192  *********************
Date: 10 Jan 84 12:47 PST
From: masinter.pa
Subject: [Don.Cohen <DONC@USC-ISIF.ARPA>: lispuser packages]
To: 1100Support
cc: LispSupport, masinter.pa

Don Cohen is primarily an Interlisp-VAX user, but he has submitted a number of LispUsers packages.


     ----- Fowarded Messages -----

Received: from USC-ISIF.ARPA by PARC-MAXC.ARPA; 10 JAN 84 12:20:42 PST
Date: 10 Jan 84 12:19 PST
Subject: lispuser packages
From: Don.Cohen <DONC@USC-ISIF.ARPA>
To: masinter.PA
cc: lipkis@USC-ISIF.ARPA

I've just been talking with Tom Lipkis, who showed me the new lisp manual
and various documentation for lispusers packages.  I noticed that TRACEIN
was in the list (but not described), and that ALL, COMMENTS, WAKEUP were
not mentioned.  I believe that LOSTLISTS is the only package that is PDP10
specific.  The others certainly work on the VAX and, except for WAKEUP, 
I've seen them work on dolphins.  WAKEUP should work on a dolphin, but it
loses some of its value since the dolphin has no auditory output.
I also noticed a package called PQUOTE.  I have something like that, but
it was nontrivial to build, so I suspected that PQUOTE might be wrong. 
Tom agreed with me, so I have now extracted the pieces of my version and
I send them along.  I can explain the various pitfalls if you're
interested.  This is <DONC>PQUOTE on ISIF - If you want it I'll write
documentation. 

(FILECREATED "10-Jan-84 12:07:33" <DONC>PQUOTE..2 1183   

      changes to:  (VARS PQUOTECOMS)

      previous date: "10-Jan-84 12:00:55" <DONC>PQUOTE..1)


(PRETTYCOMPRINT PQUOTECOMS)

(RPAQQ PQUOTECOMS ((FNS READ' PRINTQUOTE)			       |
		   (P (SETSYNTAX 39 (QUOTE (MACRO FIRST NONIMMEDIATE   |
						  NOESCQUOTE READ'))   |
				 T)				       |
		      (SETSYNTAX 39 (GETSYNTAX 39 T)		       |
				 FILERDTBL)			       |
		      (SETQ PRETTYPRINTMACROS			       |
			    (CONS (CONS (QUOTE QUOTE)		       |
					(QUOTE PRINTQUOTE))	       |
				  PRETTYPRINTMACROS))		       |
		      (* ALISTS and ADDVARS fail here))))
(DEFINEQ

(READ'
  (LAMBDA (FILE RDTBL)
    (KWOTE (READ FILE RDTBL))))

(PRINTQUOTE
  (LAMBDA (X)
    (COND
      ((AND (LISTP (CDR X))
	    (NULL (CDDR X)))
	(PRIN1 "'")
	(PRINTDEF (CADR X)
		  (POSITION))
	NIL)
      (T X))))
)
(SETSYNTAX 39 (QUOTE (MACRO FIRST NONIMMEDIATE NOESCQUOTE READ'))
	   T)
(SETSYNTAX 39 (GETSYNTAX 39 T)
	   FILERDTBL)
(SETQ PRETTYPRINTMACROS (CONS (CONS (QUOTE QUOTE)
				    (QUOTE PRINTQUOTE))
			      PRETTYPRINTMACROS))
(* ALISTS and ADDVARS fail here)
(DECLARE: DONTCOPY
  (FILEMAP (NIL (646 892 (READ' 658 . 721) (PRINTQUOTE 725 . 889)))))
STOP
-------

     ----- End of Forwarded Messages -----196  *********************
Date: 10 JAN 84 15:10 PST
From: MASINTER.PA
Subject: problems with PQUOTE
To:   LispSupport

Received: from USC-ISIF.ARPA by PARC-MAXC.ARPA; 10 JAN 84 14:53:25 PST
Date: 10 Jan 84 14:52 PST
Subject: Re: lispuser packages
From: Don.Cohen <DONC@USC-ISIF.ARPA>
To: masinter.pa
In-Reply-To: Your message of 10 Jan 84 12:46 PST

Now that I've had a chance to look at your PQUOTE, here's the problem:
READ' doesn't read right if there's a CR after the '.  With your PQUOTE
I was able to get the prettyprinter to print ' followed by CR followed by
a list on the next line.  My solution was to change READ' so that it would
read the right thing in that case.  The only difference is that in my version
when you type (at the terminal) ' followed by CR (or any sepr) the next thing
gets quoted - which I don't think is unreasonable.  I was glad to see that
you caught the nasty cases of "fake" quotes, as in (BQUOTE (QUOTE , x)).
The * problem would go away with my new READ'.  What's more, the current
READ' will mess up if someone invents a new prettyprintmacro that sticks
in a sepr char.  (I can tell I'm about to get a mass of counterarguments...)
-------
*start*
00546 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 APR 84 23:15 PST
From: MASINTER.PA
Subject: AR, want V VEMEM fragmentation inspection tool
To:   lispsupport

Date: Tue, 10 Jan 84 18:40 PST
From: Raim.pasa
Subject: Re: Lisp: How fragmented is my VMEM?
In-reply-to: "Kaplan.pa's message of 9 Jan 84 12:56 PST"
To: Kaplan.pa
cc: LispSupport.pa

I agree!   Many 1100 customers who marvel at the decreasing responsiveness of their aging 1100s would welcome a means of inspecting the allocation of the VMEM file.

marty
*start*
07113 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 APR 84 23:34 PST
From: MASINTER.PA
Subject: AR, want opcode for FIXP, NUMBERP, LITATOM
To:   LispSupport
cc:   JonL

I would agree with this proposal, with some modifications. 

First, there are some points which have a type table entry of 0. Thus, ILEQ is not reasonable, but 0<ntypx<alpha might be. However, given statistical frequency, a DISPATCH might be just as well, with 3 opcodes:

FIXP, NUMBERP, LITATOM.

Actually, we have proposed in the past a combination opcode which does the test and a conditional jump:

JFIXP, JNFIXP, JNUMBERP, JNNUMBERP, JLITATOM, JNLITATOM.

There is some (complex) logic in the compiler available already which will compile the unusual cases where the predicate is NOT used merely to determine a branch, or when a long branch is needed. 

I believe with the advent of BIGNUMs that we will absolutely want bignums to satisfy FIXP and NUMBERP, and that indeeed we will want rationals to be NUMBERP. Thus, there is another argument which says that the determination of these predicates should not be made by a numerical comparison of the type number, but rather by a bit test in the DTD, which would give us the opportunity to make odd sub-classes of these datatypes.

[JonL: I'm cc:ing you for your comments; please feel free to add them to this AR. Since this is a Difficulty HARD requiring work on all three microcodes and the compiler, and an impact MINOR or MODERATE, and there are some open design issues, I think we should make sure we've resolved all of the open design questions before pressing ahead with implementation.]
Date: 11 Jan 84 02:43 PST
From: JonL.pa
Subject: New suggestion. And cold data to douse hot conjecture
To: Masinter
cc: vanMelle, Charnley, Purcell, JonL, BLISP

Re: your message of 6 JAN 84 17:12 PST

Based on some observations while re-running a few of the dorado 
benchmarks, I suggest adding a new opcode which is like TYPEP, 
except that it checks for type number ILEQ rather than EQ to 
the data byte; reasoning follows below.

Interestingly, while re-running these benchmarks, I uncovered
several items which should put to rest the conjectures that 
LITATOM isn't statistically important, and that adding a micro
instruction to the TYPEP opcode would result in a net loss.  
In the commentary below, "system" means SYSFILES on FULL.SYSOUT
plus another dozen or so of my favorite <Lisp>Library> files.


1) Masterscope shows 357 system callers of LITATOM -- almost
   double the number of all the other TYPEP generators combined
   (excepting one, which I'll discuss in 2 below).  The others, 
   and their "weights", with some overlap, are STRINGP(112), 
   FLOATP(30), SMALLP(83), STACKP(20), and ARRAYP(40);  FIXP 
   doesn't figure in here since it is a union of types, and 
   no place gives rise to a bare TYPEP(\FIXP) call.   If the 
   performance of LITATOM isn't important, then maybe that of 
   the others isn't either?

   More to the point, if LITATOM were to use TYPEP, then     
   *** regardless of whether the 100% to 200% speedup were
   ever statisticaly observable *** the fact that two bytes
   would be saved on each usage would free up at least a page
   and a half of system space, and probably more.

2) LISTP (opcode) generators are often "hidden", in that the
   MAP series open-code using it, and many iterative statements
   would also.  There must be thousands of places in the system
   where LISTP is used.  So I decided to run some benchmarks to
   see ** how much ** the extra microinstruction really cost.

   Most of Gabriel's "list intensive" benchmarks don't even 
   generate any usages of TYPEP (or LISTP) -- many use ATOM
   which generates NTYPX;  but BOYER does (via NLISTP) -- and  
   it calls EQUAL which also does -- all in central rather 
   than in peripheral parts of the program.  So I ran BOYER 6  
   times in each flavor of microcode, and came up with a 

   ***** 0%  difference *****

   Actual data, hand-recorded in my lab notebook are also
   reproduced below.  For a second set of comparisons, I
   put the file <Lisp>Library>BSEARCH on my local disk, and
   did 5 runs of (LOAD '{DSK}BSEARCH 'PROP), and then 3 runs of
   (MAKEFILE '{DSK}BSEARCH 'NEW)in each flavor of microcode.
   The result?

   ***** 0%  difference *****

   These results sound so incredible, that I just had to run
   *something* that would show the difference.  A tightest-
   possible loop, cdring down a length-1000 list 10,000 times,
   indeed showed the differential:  without the extra micro-
   instruction, it was 2815.5 nanoseconds per loop, and with
   the extra one, it was 2879.3 nanoseconds; happily, this
   difference is effectively 64 nanoseconds (which, by the
   way, is only a 2% difference -- practically, the largest 
   measurable for this change).


Of course, this "0%" is a statistical figure, which just 
means that any differences were below the "noise" in measuring.
Still, one could hardly have a more clear-cut decision about
the advisibility of supporting LITATOM with the TYPEP opcode.
If one is still uncertain, then the implementation of the
LISTP opcode could be differentiated from that of the TYPEP 
opcode (maybe they are already on the other machines?? it just 
happened to be convenient on the Dorado for them to be exactly 
the same micro routine).


A final comment.  Until now, I didn't really realize how
badly FIXP compiles -- 9 bytes instead of 1 or 2.  NUMBERP is
even worse!   Masterscope reports 195 direct system callers of
FIXP, 136 of NUMBERP, and 73 of ATOM (there are probably more,
and there's almost no overlap).  If we had a new 2-byte opcode
which was like TYPEP, but it checked for ILEQ rather than EQ of
the type code, then all of these functions could use it, and 
all would benefit enormously.
    (FIXP X)    == (ILEQ (NTYPX X) 2)
    (NUMBERP X) == (ILEQ (NTYPX X) 3)
    (ATOM X)    == (ILEQ (NTYPX X) 4)
[a swap of LISTP and STRING typecodes would also permit strings
to be considered "atoms"]


---------------------------------------------------------------
  Data: Times in seconds. Format <GC>/<CPU> where both needed 
---------------------------------------------------------------


BOYER:    Vanilla ucode | Crusty ucode
------------------------|----------------
            13.4/17.6   |  13.4 17.7
            13.3/17.8   |  13.4/17.9
            13.4/17.9   |  13.5/17.9
            13.4/17.8   |  13.4/17.9
            13.2/17.5   |  13.3/17.7
            13.4/17.8   |  13.4/17.9

[on LOAD, the last 3 runs only are reported, since the early
runs tended to be obscured by swapping, page initialization,
etc.  The times "stabilized" after that.]
LOAD:     Vanilla ucode | Crusty ucode    
------------------------|----------------    
             1.04       |    1.04
             1.04       |    1.04
             1.04       |    1.03       [Bizarre, no?]

MAKEFILE: Vanilla ucode | Crusty ucode  
------------------------|----------------    
            7.17        |    7.17
            7.17        |    7.17
            7.18        |    7.18

*start*
00646 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 APR 84 23:36 PST
From: MASINTER.PA
Subject: comm/NS Minor Bug, subject: ious "not responding" messages
To:   lispsupport

Date: 11 Jan 84 11:00 PST
From: sybalsky.pa
Subject: Lisp: LISPPRINT: not responding falsely
To: LispSupport.pa
cc: cooper.pa
Lisp-System-Date: 10-Jan-84 20:16:07
Machine-Type: Dandelion

I printed a document on LispPrint:, and it had to go thru a cycle of "Lispprint:  Printing not responding" while the server got fired up.

Now, long after my document has completed printing, I'm still getting the stupid "not responding" messages.

	--John
*start*
01420 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 APR 84 23:38 PST
From: MASINTER.PA
Subject: AR Environment/Editors: NLAMBDA entries to editors confused if given QUOTEd arg
To:   lispSupport

Received: from RUTGERS.ARPA by PARC-MAXC.ARPA; 11 JAN 84 11:40:55 PST
Date: 11 Jan 84 14:40:43 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: Editing a file COMS
To: lispsupport.pa
cc: SHULMAN@RUTGERS.ARPA


	I new Interlisp-D user wanted to edit the COMS list of a file.
He tried (DC 'INIT.LISP) and (DC INIT.LISP) and both times got back
"INIT.LISP is not a loaded file" (it was loaded).  I then recalled that
there was an EDITCOMS function (I personally do an EDITV) and told him
that.  It is supposed to be documented on page 17.50, it isn't.  When I
tried it myself I found out the function did not exist.

	He then asked about DV, I told him to try it an he typed
(DV 'INITCOMS).  It asked which definition listing only VARS.  When you
button that it gives you INITCOMS in an edit window then IMMEDIATELY 
returns to top level with T.  If you type (DV INITCOMS) without the
quote it works.  You get the same behavior using EDITV instead of DV.

	I should mention that DF (and EDITF) work correctly with the
function name quoted or unquoted.

	Needless to say these bugs were confusing to the new user
(but I guess that is what you pay me to straighten out.)

							Jeff
-------

*start*
00739 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Apr 84 16:26 PST
From: vanMelle.pa
Subject: TEdit: Break on closing window following HARDRESET
To: TEditSupport.pa
cc: vanMelle.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  7-Apr-84 20:16:56
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Once
Impact: Annoying

Presumably as a result of the aforementioned bug wherein a tedit window gives itself the EXEC p
rocess as its PROCESS prop after a HARDRESET:

I did a HARDRESET, then tried to close a Tedit window that had a menu attached.  Got a break under TEDIT.KILL where it was trying to kill the EXEC process (which was the menu's PROCESS prop at the time).*start*
00496 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Apr 84 18:47 PST
From: halvorsen.pa
Subject: TEdit: EOF error screenfonts>frutiger-10....
To: TEditSupport
cc: halvorsen.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dandelion

Happens when two files are loaded into two TEdit windows simultaneously both Modern10.

Btw.  I have reverted out out the last full  since Tedit in that loadup appeared very unstable.

		Kris
*start*
00531 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Apr 84 22:03 PST
From: halvorsen.pa
Subject: TEdit: Tabs don't show up on SHOW in para menu
To: TEditSupport
cc: halvorsen.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dandelion

I set up a table with tabs reformatted the follwing paragraph.  Couldn't select words in the table (which looked ok still) redisplayed window and found all tab info gone.  Tabs no longer show up when using SHOW in para menu.
*start*
03042 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Apr 84 22:29 PST
From: vanMelle.pa
Subject: Dandelion phantom middle mouse button
To: LispFriends^
cc: LispSupport

For all you two-button mouse users:

The latest sysouts on <LispCore>Next> have the feature that the middle mouse button can be simulated by "chording" the left and right buttons.

Specifically, if Lisp sees Left and Right go down simultaneously, it considers that to be Middle, rather than either Left or Right.  The definition of "simultaneously" is within the interval defined by MOUSECHORDWAIT, below.  Middle is considered to be down until BOTH Left and Right come up.

If you need to do a mouse operation that would require Middle plus some other button down, you can free one (but never both) of the buttons by letting up on it while still holding the other one down.  The logical state of the mouse is still considered Middle, but the freed button is now available to register up or down independently.  For example, on a 3-button mouse if you are reshaping a window using Middle and want to switch corners, you press Right while still holding down Middle, move to the desired corner, and then let up on Right.  To do the same thing on a 2-button mouse, after pressing Left+Right to get Middle, you let up on Right while still holding Left.  This "frees" Right from the chord, and you can now press down on Right, move to the other corner, let up on Right, all the while still holding Left.  (This is probably easier to do than describe.)

To get the combination Left + Right, just don't press them down at the same instant.  To get Left + Middle + Right, or to get combinations in which Middle is not the first (logical) button to go down, you must still resort to the use of the Center key on the keyboard.  (I don't know any operations that require such a combination.)

The Center key continues to be a synonym for Middle mouse, independent of the above.

(MOUSECHORDWAIT msecs)		[Function]

Specifies the interval of time (in milliseconds) during which the Left and Right buttons on a DLion mouse must go down to be considered "simultaneous" and hence treated as Middle.  Returns the previous setting.  (MOUSECHORDWAIT) returns the current setting without changing it.  (MOUSECHORDWAIT NIL) disables chording.  The largest permissible setting is 1872 milliseconds, or almost 2 seconds.

The system is conservatively initialized with (MOUSECHORDWAIT 50).  You may want to set it higher; I suspect 100 or even 200 might be acceptable.  The competing constraints: The lower the setting, the more difficult it is to chord (the more coordinated your fingers must be).  The higher the setting, the longer the system must wait when you press down Left or Right alone before deciding that it's not going to turn into Middle; hence, the less responsive the mouse might seem in such cases.  If there is some concensus among Dandelion users regarding the optimal setting, we could make that the default before this system gets released.

	Bill
*start*
00368 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 08:42 PST
From: Sheil.pa
Subject: Re: Dandelion phantom middle mouse button
In-reply-to: vanMelle.pa's message of 8 Apr 84 22:29 PST
To: vanMelle.pa, LispSupport.pa

Bill:

Thanks greatly for getting onto this so fast.

Beau


Mike:

There is an AR Wish for this somewhere.

Beau

*start*
00451 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Apr 84 22:56 PST
From: vanMelle.pa
Subject: Lisp: forDuration compiles using \FIXP free
To: LispSupport.pa
cc: vanMelle.pa

Lisp System Date:  8-Apr-84 18:02:02
Machine: Dandelion (Big-Chip)
Microcode version: 24,4
Memory size: 5777
Impact: Minor

forDuration compiles a (\CREATECELL \FIXP), which is a free ref to the variable \FIXP if you don't have ABC loaded.

	Bill
*start*
00475 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 APR 84 20:34 PST
From: JONL.PA
Subject: Re: Lisp: forDuration compiles using \FIXP free
To:   vanMelle, LispSupport
cc:   JONL

In response to the message sent   8 Apr 84 22:56 PST from vanMelle.pa

This is a bug in NCREATE rather than in DURATION.

The AR is:  (NCREATE 'FIXP) macroexpands into (CREATECELL \FIXP) and \FIXP
            hasn't been declared GLOBALVARS in the installed sysout.

*start*
00625 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Apr 84 23:31 PST
From: vanMelle.pa
Subject: TEdit: Scrolling Tedit window leaves caret droppings
To: TEditSupport.pa
cc: Burton, vanMelle.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  7-Apr-84 20:16:56
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Intermittent
Impact: Annoying

I have noticed a number of caret droppings on my Tedit windows, that seem to arise when scrolling, but not very reliably.  The droppings appear to be the top half of the tedit caret, rather than the default caret.
*start*
00415 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Apr 84 23:57 PST
From: halvorsen.pa
Subject: TEdit: Tab info affected by shift selecting
To: TEditSupport
cc: halvorsen.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dandelion

Text in a paragraph which is aligned by tabs sometimes loose its alignment when the paragraph is shift selected
*start*
00388 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 08:11 PST
From: TBigham.es
Subject: Lisp: Clearinghouse
To: LispSupport.pa
cc: TBigham.es
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dolphin

The function SHOW.ENTIRE.CLEARINGHOUSE doesn't seem to exist.  When I evaluate it, I get an "UNDEFINED CAR OF FORM".  Have I missed something obvious?
*start*
01026 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 08:33 PST
From: Sannella.pa
Subject: [Masinter.pa: AR#147]
To: LispSupport

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

Date:  6 Apr 84 17:14 PST
From: Masinter.pa
Subject: AR#147
To: Sannella
cc: desRivieres

After some reflection, I've decided that Jim's request far exceeds the original scope of OPENLAMBDA (which reserves the right to be a 'substitution macro'.)

Jim, if you want the semantics of LAMBDA, use LAMBDA.

Michael: I cannot find using IM.INSPECTOR any referent to OPENLAMBDA where I could insert this comment. Would you change this into an AR on Documentation, please? 

The idea is to add a note in the description of OPENLAMBDA on P 5.18 that says: OPENLAMBDA assumes that it can substitute literally the actuals for the formals in the body of the macro if the actual is side-effect free or a constant. Thus, you should be careful to use names in ARGS which don't occur in the BODY.

     ----- End of Forwarded Messages -----
*start*
00441 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 08:37 PST
From: Sheil.pa
Subject: Re: AR 368: Cannot BREAK S-expr from inside DEdit
In-reply-to: lispar.auto's message of 8-Apr-84 18:08:45 PST
To: LispSupport
cc: masinter.pa

Sorry - I was thinking as I wrote it that we needed a category like that, but I didn't know what it was (Unreplicated?). Incomplete sounds fine and that is what I meant.

Beau

*start*
00514 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 09:12 PST
From: Masinter.pa
Subject: AR#354
To: LispSupport

MODIFY.KEYACTION isn't indexed. Maybe that's the problem? Also, the index contains no references for KEYBOARD, etc. or at least, the IM inspector doesn't know about them.

I don't know who this belongs to, as I think the appropriate action is to index MODIFY.KEYACTION and regenerate the IM inspectors.

I guess this is Attn: Sannella, no? I don't want it any more.
*start*
01324 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 09:24 PST
Sender: Sannella.pa
From: LispSupport.pa
Subject: New Release of Interlisp-D
To: LispUsers^.pa

A new set of sysouts (Lisp.sysout, Full.sysout, Small.sysout) has been created, tested, and placed on {phylum}<Lisp>Current>.  A corresponding Demo.sysout will be placed there shortly.  The significant differences between these sysouts and the previous release to {phylum}<Lisp>Current> are the following:

++ Change for Interpress users:  Some Interpress fonts, such as "Terminal", have some characters at non-standard character numbers.  As a result, certain characters (hyphen, dollar, uparrow, leftarrow) would not print in these fonts.  The Interpress software has been changed to map these characters appropriately when using Interpress fonts.

++ New 1108 Floppy disk code:  The floppy disk code has been substantially improved.  A bug that caused sysouts to floppy to contain bad pages has been fixed.  The current documentation is in {phylum}<lisp>current>floppy.tty.

++ New 1108 microcode has been included in the sysouts, fixing an obscure bug that caused MP code 9915's.

++ A bug that caused DOSTATS to break with a hash overflow error has been fixed.

++ The precision of transcendental functions has been improved.
*start*
00786 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Sender: Sannella.PA
Date:  9 Apr 84 14:39:56 PST (Monday)
From: LispSupport.pa
Subject: New Release of Interlisp-D  -- bug!
To: LispUsers^.pa
Reply-To: LispSupport.pa

I regret to report that the new release that was announced this morning has a serious bug --- the interpreted versions of FTIMES and FPLUS were not included.  Note that this does not affect the compilation of FTIMES --- indeed, this is why it was so hard to catch this bug.

At this moment, a new set of sysouts is being created, which will be put on {phylum}<lisp>current> as soon as possible.

If you have already retrieved the new sysout from this morning, the problem can be fixed by loading the patch file {phylum}<lisp>current>FPPATCH.DCOM.
*start*
00856 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 09:36 PST
From: MGardner.pa
Subject: TEdit: Copy Option and Tabs
To: TEditSupport
cc: MGardner.pa

TEdit System Date:  2-Mar-84 16:54:27
Lisp System Date: 13-Mar-84 17:32:33
Machine: Dolphin (Palladio)
Microcode version: 24,1
Memory size: 6000
Frequency:  Always
Impact:  Annoying

There is no copy option in the expanded menu; which means if I want more than one copy of something I have to go through the Hardcopy routine more than once.

Also, I did a document with tabs and then saved it. The next day I pulled up the same document and made some changes (but not to the tabs) and made a hardcopy. To my dismay the tabs had moved.  I then decided to check where my tabs were by using the ruler in the expanded menu. Another surprise. There were no tab arrows.

Mimi
*start*
00470 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 03:02 PST
From: Wallace.pa
Subject: TEdit: ^E while in TEDIT.GETINPUT
To: TEditSupport.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000
Frequency: Always
Impact: Annoying

When being asked for input (say in GET) you can't abort by typing ^E.  It just inverts the interaction window.

*start*
00457 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 11:24 PST
From: sybalsky.pa
Subject: Re: TEdit: ^E while in TEDIT.GETINPUT
In-reply-to: Wallace.pa's message of 9 Apr 84 03:02 PST
To: Wallace.pa
cc: TEditSupport.pa

Nyet Pravda.  Hitting a space, to let the interaction window "scroll" will really abort the operation.  Now, as to WHY that window doesn't just scroll and have done with it, I dunno. I'll pass it along.
*start*
00544 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 12:27 PST
From: vanMelle.pa
Subject: Lisp: READNUMBER sensitive to Radix
To: LispSupport.pa
cc: vanMelle.pa

Lisp System Date:  7-Apr-84 20:16:56
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Moderate

If you call READNUMBER when (RADIX 8), the button panel contains "10" and "11" instead of "8" and "9", and the accumulated result is not shown in decimal radix, so it's hard to tell what you've entered.
*start*
01232 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 12:38 PST
From: vanMelle.pa
Subject: AR updates
To: LispSupport
cc: vanMelle.pa

AR 527: this is a restatement/amplification of AR 472; they should be combined.  Hopefully/Moderate/Moderate.

AR 353: Fixed.

AR 533: Fixed.

AR 115: Hard.  Also, the following items in some of the messages should be separate AR's (maybe some are, but if so they're not on my list):

From: ROACH.PA
     (1) I don't get prompted by PHYLUM or MAXC for password.  I think 
it is unreasonable that PHYLEX: demands my password.
     (2) Subdirectory creation should happen automatically rather
than PHYLEX:'s current "FILE NOT FOUND" breakage.
     (3) I don't think "XSIS North:Xerox" should be part of PHYLEX:'s
device name.  I also feel the same way about "LispPrint:XSIS North".

From: desrivieres.pa
1.  (fullname 'foo 'new) always returns nil; however, (fullname 'foo 'old) seems fine.
 
AR 173: Impact Moderate

AR 296: Difficulty: Moderate (Leaf Error 1001 is undocumented, so some investigation required).

AR 240: Easy

AR 440: Declined pending further description.  (Is there such a status?)

AR 485: Easy

AR 429: Diff  Moderate

AR 476: Diff  Moderate


*start*
00292 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 12:41 PST
From: vanMelle.pa
Subject: Re: Lafite: When bad mail comes back [Ar 524]
In-reply-to: Kaplan.pa's message of 5 Apr 84 09:16 PST
To: Kaplan.pa
cc: LafiteSupport.pa

Now fixed to not grab the tty.
*start*
00732 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 12:48 PST
From: vanMelle.pa
Subject: Re: Lafite: not finding mail on cabernet [Ar 465]
In-reply-to: Christman.pa's message of 31 Mar 84 14:29 PST
To: Christman.pa
cc: LafiteSupport.pa

Did Lafite actually say "Empty" for Cabernet, rather than "not responding"?  Even if the former, it is faintly possible, if unlikely, that Cabernet had been down a long time, recently come up, and mailers that had been waiting to send mail to it suddenly flooded it with 93 messages between the time you checked with Lafite and ran Laurel.

I doubt this is a problem with Lafite; hence, Status: Declined unless it happens again.  Thanks for the report.

	Bill
*start*
00482 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 13:27 PST
From: Masinter.pa
Subject: Re: AR 200: FileBrowser RENAME drops chars of new filename
In-reply-to: LispSupport.pa's message of 9 Apr 84 13:21:49 PST (Monday)
To: LispSupport.pa
cc: ckiparsky.pa, Kaplan.PA, Masinter.PA, Sheil.PA

"Unfortunately, there is noone assigned to maintain the File browser, so it probably will not get fixed soon.  "

is an unacceptable thing to tell anyone.

*start*
00631 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 13:03 PST
From: Cooper.pa
Subject: Lisp: bug in come-hither mode of DEDIT menu
To: LispSupport.pa

Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (CISDORADO10)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Moderate

When you hit TAB to bring over the DEDIT menu, the cursor is positioned exactly on the left border. Unfortunately, this makes the menu move around; if you jerk the mouse quickly so that the cursor jumps *inside* the menu, then it works fine, but it's sort of like the Alto "Fly Swatter" game.

Eric
*start*
00461 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 13:05 PST
From: vanMelle.pa
Subject: more Ar's
To: LispSupport
cc: vanMelle.pa

Ar 525: This is either fixed or declined (the fix being to set CHAT.DISPLAYTYPE correctly).  Did my reply get sent to anyone?  Has there been any further news?

Ar 258: Diff moderate

AR 432: Diff moderate

AR 26: Fixed with the latest Tedit release.

AR 479: Diff Moderate

AR 392: Diff Hard

*start*
00353 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 13:57 PST
From: ckiparsky.pa
Subject: Re: AR 200: FileBrowser RENAME drops chars of new filename
In-reply-to: Masinter.pa's message of 9 Apr 84 13:27 PST
To: Masinter.pa
cc: LispSupport.pa, ckiparsky.pa, Kaplan.PA, Sheil.PA

DEAR LARRY - I AGREE.  THANKS.

CAROL K.
*start*
00625 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 14:14 PST
From: withgott.pa
Subject: TEdit: new windows and fontcopy broken
To: TEditSupport
cc: withgott.pa
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dandelion

When I get a new TEDIT, I often, but not always, get a break under FONTDESCRIPTOR%#1,1155550 saying ILLEGAL ARG and FONTCOPY broken.  

If I then up-arrow and close the TEDIT window, I can start up a new TEDIT and not get the break.

 So it only happens after TEDIT.CREATEW and specification of a region for a new window.

	-Meg
*start*
00560 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 13:20 PST
From: Burton.pa
Subject: Lisp: Chat not grabbing tty soon enough
To: LispSupport.pa

Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Burton)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Annoying

I bugged "reconnect" in a chat window whose connection had been closed and started typing.  The input went to the EXEC process until the connection was reestablished.  Can you have chat grab the tty when it starts to reconnect?

richard
*start*
00781 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 14:10 PST
From: vanMelle.pa
Subject: Re: Lafite: NIL - NON-NUMERIC ARG [AR 534]
In-reply-to: Wallace.pa's message of 3 Apr 84 10:51 PST
To: Wallace.pa
cc: LafiteSupport.pa

I'll have to decline this one, unless further information is available.  E.g., was this immediately after returning from Logout; was the browser in any unusual state when you clicked GetMail; and most importantly, what exactly was the stack?

General comment:  BT! is much more helpful than BT.  And when you get a NON-NUMERIC ARG error, you can usually find a frame at the top of the stack that actually shows the numeric computation that caused the error, and perhaps report what the other arguments to it were.

	Bill
*start*
01260 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 14:20 PST
From: vanMelle.pa
Subject: Re: AR#166: Monitor Locks by marking resource
To: LispSupport, Stansbury
cc: vanMelle.pa

Unlikely/Hard

Languages I know of that associate a monitor with a structure (e.g., Mesa's Monitor Records) have the benefit of a compiler to know where the accesses are and implicitly wrap monitor lock contexts around them.

In Lisp's case, one has to rely a little more on programmer discipline.  You say "it would seem much safer if you could mark the resource once, rather than mark each piece of code that uses it".  True, but "uses it" is a little vague.  You need to require that all accesses to it go through some stylized construct that enforces the monitor.  No reason you can't hide that with macros or accessfns, of course.  But this turns out to be pretty much equivalent to "you have to wrap each piece of code which uses the global resource in a with.monitor".  And the with.monitor around the entire chunk of code is probably going to be a lot more efficient than putting one on each access.

Another comment is that protecting a shared resource typically involves more than just the explicit accesses to a data structure.

	Bill
*start*
00915 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 14:37 PST
From: jordan.pa
Subject: Re: AR 368: Cannot BREAK S-expr from inside DEdit
In-reply-to: Sheil.pa's message of 8 Apr 84 15:28 PST
To: Sheil.pa
cc: jordan.pa, LispSupport.pa

Beau,

	I found the bug I reported to be pretty strange and was not clear on exactly what info to report, as the function was involved in a Dedit/Break tangle, and I also was not able to immediately reproduce it.  I did mention a few variables I thought might be relevant and described the sequence of actions that appeared to have led up to the bug.  

	I've encountered the bug before and, not wanting to see it forgotten, if you can suggest specifically what would be the variables/functions/things to report for a situation like the one I described I will again try to reproduce it, and re-report (or, grab the nearest lispsupporter). 

Dan
*start*
00286 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 15:36 PST
From: vanMelle.pa
Subject: Re: Lafite: RAID in Answer [AR 533]
In-reply-to: Kaplan.pa's message of 3 Apr 84 21:23 PST
To: Kaplan.pa
cc: LafiteSupport.pa

Now fixed.  Thanks for the report.
*start*
00719 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 15:48 PST
From: vanMelle.pa
Subject: Lisp: Masterscope confused by "FIND"
To: LispSupport.pa
cc: vanMelle.pa

Lisp System Date:  7-Apr-84 20:16:56
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Annoying

I have a file named FIND.  Anytime I try to ask masterscope a question about it, say

. ANALYZE ON FIND
  or
. WHO ON FIND CALLS LAFITE

it responds

  should I LOADFROM {PHYLUM}<LISPUSERS>SHOW.;1 ?

I eventually realized that FIND was the problem, even though FIND is not a documented Masterscope keyword, and solved the problems by asking instead

. ANALYZE ON 'FIND

etc.


*start*
00693 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 15:53 PST
From: vanMelle.pa
Subject: TEdit: bogus "Edit operation in progress"
To: TEditSupport.pa
cc: vanMelle.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  7-Apr-84 20:16:56
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Minor

It seems that when I shift select something out of an AREDIT display window into a Lafite message sender, it prints "Edit operation in progress", even though it happily performs the selection.  This only happens for the first such selection into any given message sender, but is quite repeatable in that case
.*start*
00851 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 16:17 PST
From: christman.pa
Subject: Re: Lafite: not finding mail on cabernet [Ar 465]
In-reply-to: vanMelle.pa's message of 9 Apr 84 12:48 PST
To: vanMelle.pa
cc: Christman.pa, LafiteSupport.pa


Did Lafite actually say "Empty" for Cabernet, rather than "not responding"?  Even if the former, it is faintly possible, if unlikely, that Cabernet had been down a long time, recently come up, and mailers that had been waiting to send mail to it suddenly flooded it with 93 messages between the time you checked with Lafite and ran Laurel.

As I recall it said "Empty".  

Re:  Not updating TOC.  In retrospect  it seems that I
was having trouble with Lafite when I was also using
laurel and lafite.  These days im just using lafite and
updating seems to work ok.


*start*
00381 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 18:07 PST
From: Sheil.pa
Subject: Re: DEdit break while reshaping input buffer
In-reply-to: Nuyens.pa's message of 9 Apr 84 16:29 PST
To: Nuyens.pa
cc: LispSupport.pa

Greg:

This bug report is 48K+ characters long and indecipherable. Please resubmit something short and comprehensible.

Beau

*start*
01263 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 16:56 PST
From: vanMelle.pa
Subject: Re: Ar #561
In-reply-to: le.pasa's message of 9 Apr 84 17:42:34 PST (Monday)
To: le.pasa
cc: LispSupport, 1100Support.pasa

  "When copying a text file from floppy to DEI/VAX, VMS sometimes assigns type attribute BINARY.  The next time the file is accessed from Lisp, it is seen in the wrong mode."

The report puzzled me, so I called Bill White for clarification.  Something apparently got lost in translation.  The real problem is:

The Library files distributed by Floppy have no file type.   When you COPYFILE such a file to another place, such as their Vax or their 20, the file is written as type TEXT (the default), which is wrong for dcom files, and loses information in the case of writing the file on the 20.

Thus, there are potentially two problems here:

(1) Files on the Library floppies have no TYPE attribute.  This is either attn Roach, if the problem is that Floppy doesn't support or recognize the TYPE attribute, or else attn 1100Support for the way it is creating floppies for distribution.

(2) COPYFILE, when the source file has no TYPE, should infer the type.  This has been on my task list for a while now.

	Bill
*start*
00401 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 18:25 PST
From: Wallace.pa
Subject: Lisp: Reporting bugs
To: LispSupport.pa
cc: LafiteSupport

Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000
Impact: Minor 

There ought to be a break package command that inserts a stack backtrace into a bug report form.
*start*
00361 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 19:04 PST
From: Masinter.pa
Subject: Re: [Kaplan.pa: AR 340:  OUTFILEP returning NIL for CORE ]
In-reply-to: Jellinek.pa's message of 9 Apr 84 09:58 PST
To: kaplan, jellinek, lispsupport
cc: Masinter.pa

Change AR to read OUTFILEP({CORE}file;1) always fails; status OPEN.


*start*
00678 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 19:06 PST
From: JonL.pa
Subject: Lisp: INTERRUPTCHAR's HARDFLG interacts badly with ??
To: LispSupport.pa
cc: JonL.pa
Lisp-System-Date:  4-Apr-84 15:14:33
Machine-Type: Dolphin

Try

(INTERRUPTCHAR (CHARCODE ^T) '(CONTROL~T~AND~MORE) T)

where CONTROL~T~AND~MORE just dribbles some information out to the T stream (using DSPSOUT) and then calls the CONTROL-T function.

there seems to be random stuff in the keyboard input buffer upon occasion after typing a ^T; furthermore, typing a <CR> after ^T seems to cause something from one of the previous lines to be inserted.  TTYIN is loaded.


*start*
00837 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 APR 84 19:21 PST
From: JONL.PA
Subject: Re: AR 546: CLEAR doesn't always clear bottom line of borderless window
To:   Burton, LispSupport
cc:   Jonl

In response to the message sent   6 Apr 84 15:33 PST from Burton.pa

No, I never mucked with DSPCLIPPINGREGION -- simply had created a borderless
window into which I "painted" some bits, and then used windowMenu com "Clear"
to try to reset the window.

I had, however, scrolled the window up from time to time, using the "cached"
pilot bitblt table.  Nevertheless, the lossages occurred in between scrollings,
and didn't seem to be connected with them.

I believe i had called SHAPEW to place the window's bottom line on line 16
of the SCREENBITMAP (Which probably shouldn't make any difference but . . .)

*start*
00478 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 10:35 PST
From: Burton.pa
Subject: Re: AR 546: CLEAR doesn't always clear bottom line of borderless window
In-reply-to: JONL.PA's message of 9 APR 84 19:21 PST
To: JONL.PA
cc: Burton.PA, LispSupport.PA

There was a bug in the caret code for a few days that put bits in the border region of the window.  These would not be cleared by CLEARW.  Could this have been what you noticed?

richard

*start*
00751 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 APR 84 19:36 PST
From: JONL.PA
Subject: Re: AR 29:  Miising accessfns for STREAM
To:   vanMelle, Kaplan
cc:   Lispsupport, Burton, JONL

In response to the message sent   7 Apr 84 15:46 PST from vanMelle.pa

Before deleting the inspector facility that shows all "fields" (including
the ACCESSFNS ones), be sure that there is some way to get that effect
when wanted.  For example, I was inspecting some random datatype (maybe it
was the PILOTBBT?) and the basic fields where something like BASEHI and BASELO,
which when printed out just look like two random numbers; but seeing the BASE
"field" make it all clear -- BASE just did a \VAG2 of the appropriate other
fields.

*start*
00681 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: KAPLAN.pa
Date: 10-Apr-84  7:41:16 PST
Subject: Re: AR 29:  Miising accessfns for STREAM
In-reply-to: JONL's message of 9 APR 84 19:36 PST
To: JONL
cc: vanMelle, Kaplan, Lispsupport, Burton

Actually, I also question the wisdom of suppressing accessfns in the inspector. Sometimes that's the only way of giving a symbolic interpretatation to what would otherwise be garbage.  The ACCESS field of a stream is one example that comes to mind.

Seems to me that the accessfns ought to at last be passed thru on sysemreclst, ad perhaps then the inspector could have a flag that suppressed them or not.

--Ron
*start*
00416 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 APR 84 20:15 PST
From: DEUTSCH.PA
Subject: FFILEPOS does not work if byte size ~= 7
To:   LispSupport

I would expect it to work at least for byte size = 8.
(Note: this is in Interlisp-10.)
FILEPOS works just fine for both 7 and 8, presumably
because it is calling BIN rather than accessing the characters
directly from the file pages.
*start*
00704 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 09:19 PST
From: Kaplan.pa
Subject: TEdit: New attached window
To: TEditSupport.pa
cc: Kaplan.pa

The little attached window that appears above Tedit windows is new, and it is totally screwing the screen layout in the LFG system.

What is it used for?   If it used only for certain commands, can I close it without screwing things up (and without closing the main window).  Can it be made to come up and down automatically?

If it isn't reasonable to have it go away, how can I determine the size of the composite containing the Tedit window plus the attached window, so that I can position things above it? 

--Ron  
*start*
00818 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 09:38 PST
From: Kaplan.pa
Subject: Lafite: Message sending commands come up separately from main window
To: LafiteSupport.pa

Lafite System Date:  8-Apr-84 17:20:45
Lisp System Date: 10-Apr-84 09:05:55
Machine: Dorado (Ahwahnee)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Annoying

The message sender comes up in 2 pieces:  first the command (Deliver SaveForm Abort) menu is created at one place on the screen, then the main editting window comes up, then the menu jumps over to the main window.

A minor bit of ugliness.  Would be better if they both came up at the same time--or if that is hard, if the menu were created at its ultimate destination, so that it doesn't jump around on the screen.

--Ron
*start*
00387 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 11:02 PST
From: vanMelle.pa
Subject: Re: Lafite: Message sending commands come up separately from main window
In-reply-to: Kaplan.pa's message of 10 Apr 84 09:38 PST
To: Kaplan.pa
cc: LafiteSupport.pa

Yes, this is a long-noted problem with ATTACHEDWINDOW, which I have volunteered to fix this week.
*start*
00509 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 10:30 PST
From: Burton.pa
Subject: Lisp: lowercase function not correcting
To: LispSupport.pa
cc: VanMelle.pa

Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Burton)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Annoying

Starting in a new full.sysout, 
lafite(on)

(note lowercase) generated

UNDEFINED FUNCTION
lafite

LAFITE(ON)

worked.

I thought case coerced at the top level?

richard
*start*
00511 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 10:51 PST
From: Masinter.pa
Subject: Re: AR 574: Expanding Lafite form causes low-fequency tone --- somebody trashing IO page?
In-reply-to: LispSupport.pa's message of 10 Apr 84 10:29:57 PST (Tuesday)
To: LispSupport.pa
cc: vanMelle.pa

is OK, but use Purcell, vanMelle, Charnley, Masinter for "IO Page trashing" or other low-level possibilities.

I'm trying to get Beau back on LispCore^ by getting the mail traffic down.

*start*
00851 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 11:23 PST
From: vanMelle.pa
Subject: Re: AR 582: STACKOVERFLOW UNDER \10MBWATHCER
In-reply-to: LispSupport.pa's message of 10 Apr 84 10:42:17 PST (Tuesday)
To: LispSupport.pa
cc: vanMelle.pa, cooper.pa, Halvorsen

Since all processes share the same collective stack space, Stack Overflow often "strikes" a process other than the real culprit.  Barring further evidence, I shall assume that is true in this case as well, and Decline the Ar.

LispSupport: 10MBxxx stuff is "low-level Ether", not "NS protocols" (don't confuse the speed of the ethernet with the type of traffic it carries); no need to attn Cooper on these.

AR: Wish: Make Stack Overflow error happen in the process with the deepest stack.  OS/Processes, Perhaps, Moderate, Annoying, attn me.

	Bill
*start*
00753 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 11:31 PST
From: Burton.pa
Subject: Lisp: New Dedit looks bad with BIG fonts
To: LispSupport.pa
cc: Sheil.pa

Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Burton)
Microcode version: 24,4
Memory size: 10000
Frequency: Always
Impact: Moderate

Dedit uses the wrong font size when running the demo.  I think has to do with BIG changing the fonts.  With the demo loaded, the function names appear in large (helvetica 18?) font with the line spacing being only 12 or so.  Scrolling off and back on print the function names in a smaller font which has the right linefeed height but the width of the selection is still as if they were printed in the larger font.


*start*
00541 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 12:31 PST
From: Sheil.pa
Subject: Re: Lisp: New Dedit looks bad with BIG fonts
In-reply-to: Burton.pa's message of 10 Apr 84 11:31 PST
To: LispSupport.pa, Burton

To fix this, DEdit would have to move alreday printed material when there is a change of font on a line. I suggest that the big fonts should be better matched, as this would probably look lousy anyway, even if done right by DEdit.

But the bug is real: Priority: Perhaps; Diff: Hard.

Beau

*start*
00412 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 11:38 PST
From: Jellinek.pa
Subject: Lisp: Masterscope can't deal with lowercase queries
To: LispSupport.pa
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dolphin

Masterscope says it can't parse, e.g.

	. edit where any call foobarbaz

though it can parse

	. EDIT WHERE ANY CALL foobarbaz

I deem this a misfeature.
	H
*start*
00566 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 12:08 PST
From: vanMelle.pa
Subject: Re; AR#349: EMacs cursor positioning off by 1 char
To: LispSupport
cc: vanMelle.pa, 1100Support.pasa

Now fixed.  Turns out that some versions of EMACS more recent than the one we have on Maxc perform character insertion by a bizarre sequence, which is documented in the manual as "not advised", but which nevertheless Chat was not emulating correctly.

Should the customer be eager for a fix, this happens to be a one-function patch.

	Bill
*start*
00672 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Sender: Sannella.PA
Date: 10 Apr 84 11:41:39 PST (Tuesday)
Subject: Lisp: Clearinghouse
To: vanMelle.pa
cc: Cooper, LispSupport.pa
From: LispSupport.pa

----------------------------------------------------------------
Date:  9 Apr 84 08:11 PST
From: TBigham.es
Subject: Lisp: Clearinghouse
To: LispSupport.pa
cc: TBigham.es
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dolphin

The function SHOW.ENTIRE.CLEARINGHOUSE doesn't seem to exist.  When I evaluate it, I get an "UNDEFINED CAR OF FORM".  Have I missed something obvious?

----------------------------------------------------------------
*start*
00999 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 12:21 PST
From: Cooper.pa
Subject: Re: Lisp: Clearinghouse
In-reply-to: LispSupport.pa's message of 10 Apr 84 11:41:39 PST (Tuesday)
To: TBigham.es
cc: LispSupport.pa, vanMelle.pa, Cooper.PA

You didn't miss anything; you found a bug in our documentation. The function SHOW.CLEARINGHOUSE subsumes the now non-existent SHOW.ENTIRE.CLEARINGHOUSE function.

			AR for Documentation:

Delete the entry for SHOW.ENTIRE.CLEARINGHOUSE and merge the following information into the entry for SHOW.CLEARINGHOUSE:

The function (SHOW.CLEARINGHOUSE) displays the structure of Clearinghouse servers.

If ENTIRE.CLEARINGHOUSE? is non-NIL, the entire organization/domain structure will be constructed (this may take quite a while), otherwise only the cache of Clearinghouse servers contacted during the current session is used.

If DONT.GRAPH is non-NIL, list structure is returned rather than displaying the tree via GRAPHER.
*start*
00335 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 12:26 PST
From: Burton.pa
Subject: Re: AR 604: READNUMBER sensitive to Radix
In-reply-to: LispSupport.pa's message of 10 Apr 84 11:58:43 PST (Tuesday)
To: LispSupport.pa
cc: VanMelle

fixed.  It now works in radix 10 regardless of RADIX.

richard

*start*
00768 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 15:31 EST
From: Denber.wbst
Subject: Lafite: Mail File Trashed
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dolphin

I was Moving a message from a mail file on my local disk to {Ice}<Denber>Lisp>Active.mail when Ice crashed.  I tried it again when Ice came back up and this time it worked.  Then I closed the local browser and tried to open the remote file.  I got

"Cannot parse file {ICE}<DENBER>LISP>ACTIVE.MAIL;1 near message 188, byte 456030 because: Bad header or previous message length is incorrect".

Now what?  I sure hope you have a LafiteMailFileScavenger - I really need that file.  Help!

			- Michel
*start*
00563 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 14:00 PST
From: vanMelle.pa
Subject: Re: Lafite: Mail File Trashed
In-reply-to: Denber.wbst's message of 10 Apr 84 15:31 EST
To: Denber.wbst
cc: LafiteSupport.pa

Lafite is clever enough to parse a file that has had only part of a message moved into it, but only if that message is the last one in the file; i.e., you would have to browse the file immediately after the aborted Move.

There is no Lafite scavenger yet, but the Laurel MailFileScavenger works just fine.

	Bill
*start*
00508 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 10:42 PST
From: Masinter.pa
Subject: Re: LispUsers packages
In-reply-to: Don.Cohen <DONC@USC-ISIF.ARPA>'s message of 9 Apr 84 10:55:55 PST
To: DONC@USC-ISIF
cc: MASINTER.PA, lispsupport.PA

Don,

I got the files and will include them at least for internal use.

You might note that InterIn-reply-to: Don.Cohen <DONC@USC-ISIF.ARPA>'s message of 9 Apr 84 10:55:55 PST
To: DONC@USC-ISIF
cc: MASINTER.PA, lispsupport.PA

Don,*start*
00621 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 10:43 PST
From: Masinter.pa
Subject: Re: File Browser ARs
In-reply-to: LispSupport.pa's message of 10 Apr 84 10:14:49 PST (Tuesday)
To: LispSupport.pa
cc: Jellinek.pa, Masinter.PA, Sannella.PA

just to try to make the situation clear:

Herb is currently considering what his next project is. Filebrowser is one possibility. There are other possibilities: DIG, performance tuning. I've suggested marking the ARs as "attn: Jellinek" but he will probably be moving a large number of the ones attn: Jellinek OFF his list in the future.


*start*
00516 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 10:51 PST
From: Jellinek.pa
Subject: Re: File Browser ARs
In-reply-to: Masinter.pa's message of 10 Apr 84 10:43 PST
To: Masinter.pa
cc: LispSupport.pa, Sannella.PA

Larry summed it up pretty well.  I think I would like to work on the file browser; I think it would provide a good introduction to the innards of the Interlisp-D system.  After I make some headway with that, I can start looking at device independent graphics.
	H

*start*
00204 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 14:47 PST
From: Masinter.pa
Subject: AR#203 Status_ Fixed: error when OPENLAMDA interpreted
To: LispSupport, Burton

*start*
01042 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 15:15 PST
From: Masinter.pa
Subject: AR#328, DEFINEDP _ FIXED, and some other changes
To: LispSupport
cc: LispCore^

I fixed it so that the macro for FGETD and GETD generate calls to \DEFINEDP. It is merely a compiler optimization that calls to GETD in 'predicate' context generate calls to \DEFINEDP rather than the (slower, consy) GETD.

I also removed FGETD from the manual, since it is (relatively) useless in Interlisp-D.

I created a new file, COMPATIBILITY. I moved FGETD and DEFINEDP to COMPATIBILITY. 

Hopefully, slowly, and carefully, we can move things in Interlisp-D that are only there for backward compatibility with Interlisp-10 (and which we wish to remove from the manual) into COMPATIBILITY, where it can (for some adventurous customers with no 'old' code) be jettisoned.

I'm telling you what I did, but I would actually prefer if people didn't actually use this file COMPATIBILITY without discussing it with me first.

Thanks,

Larry
*start*
00161 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 15:17 PST
From: Masinter.pa
Subject: AR#329 Status_Fixed
To: LispSupport

*start*
00388 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 15:33 PST
From: Sannella.pa
Subject: [Masinter.pa: AR#125]
To: LispSupport.pa

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

Date: 10 Apr 84 15:27 PST
From: Masinter.pa
Subject: AR#125
To: Sannella


Please mark Difficulty: Hard, Priority: Perhaps, Impact: Minor.



     ----- End of Forwarded Messages -----
*start*
00485 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 15:06 PST
From: Wallace.pa
Subject: TEdit: Custom Prompt window
To: TEditSupport.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  8-Apr-84 18:02:02
Machine: Dandelion (CSLI-3)
Microcode version: 24,4
Memory size: 5777
Frequency: Always
Impact: Annoying

I use my own prompt window.  If I supply a 'PROMPTWINDOW
 tedit-prop could I not have the standard prompt window instantated at all?*start*
00518 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 02:27 PST
From: Wallace.pa
Subject: TEdit: SUBSTITUTE blows out
To: TEditSupport.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000
Frequency: Always
Impact: Serious

SUBSTITUTE blows into the error handler with ILLEGAL ARG ^T.  The problem is that TEDIT.SUBSTITUTE calls TEDIT.GETINPUT supplying NIL as the textobj argument.

david

*start*
00276 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 15:37 PST
From: Sybalsky.pa
Subject: Re: TEdit: SUBSTITUTE blows out
In-reply-to: Wallace.pa's message of 9 Apr 84 02:27 PST
To: Wallace.pa
cc: TEditSupport.pa

Fixed; in the next release.
*start*
00831 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 03:09 PST
From: Wallace.pa
Subject: TEdit: FIND and insert
To: TEditSupport.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000
Frequency: Intermittent
Impact: Serious

This happens (I believe) only when part of the file is on the fileserver.  In any case, I load in a file and do a FIND on it.  The selection is correctly set to the proper place in the file.  If I don't move the cursor with the mouse but instead start typing text the sreen starts redisplaying madly, first the beginning of the file, then the selected page, then the beginning again...

For instance:
GET {phylum}<wallace>emacs>primit.  FIND NOTIFY.  then type some text.

david
*start*
00300 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 15:27 PST
From: Sybalsky.pa
Subject: Re: TEdit: FIND and insert
In-reply-to: Wallace.pa's message of 9 Apr 84 03:09 PST
To: Wallace.pa
cc: TEditSupport.pa

The screen update bug is fixed; will be in next release.
*start*
00618 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 12:07 PST
From: Jellinek.pa
Format: TEdit
Subject: TEdit: descriptions missing from two items on menu
To: TEditSupport
TEdit-System-Date:  2-Mar-84 16:54:27
Lisp-System-Date: 29-Mar-84 17:34:40
Machine-Type: Dolphin

The standard middle-button-titlebar-menu in TEdit is missing prompt strings from the Hardcopy and Press File menu items, though it has them for all the others.
	Herb

>
TIMESROMAN
TIMESROMAN
TIMESROMAN

TIMESROMAN:
TIMESROMAN
�z·*start*
00318 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 15:16 PST
From: Sybalsky.pa
Subject: Re: TEdit: descriptions missing from two items on menu
In-reply-to: Jellinek.pa's message of 10 Apr 84 12:07 PST
To: Jellinek.pa
cc: TEditSupport.pa

Thanks; it'll be fixed in the next release.
*start*
00336 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 15:17 PST
From: Masinter.pa
Subject: can't send message with a null body
To: LafiteSupport

gets an end of stream error. Attempt to ^ out of error didn't work either, got a DUMMY.FOR.ERRORSET - UNDEFINED CAR OF FORM (which in itself is a problem.)

*start*
01030 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Tue, 10 Apr 84 13:10 PST
From: Raim.pasa
Subject: Re: Ar #561
In-reply-to: "vanMelle.pa's message of 9 Apr 84 16:56 PST"
To: vanMelle.pa, Sannella.PA,
cc: le, LispSupport.pa, 1100Support

Bill,

Thank you for your clarification.

Our testing indicates that Floppy code does not support  the TYPE attribute.  I.e., when we copy {dsk}foo.dcom to {floppy}foo.dcom, no type information is maintained.  When a customer attempts to take his distribution floppy and copy {floppy}foo.dcom to {fileserver}foo.dcom, type TEXT is the default.

The upshot seems to be that 1108 customers can't routinely create <lispusers> and <lisplibrary> on their fileservers.  Is their a workaround?  I seem to recall an undocumented variable called DEFAULTFILETYPE.  Would setting it to BINARY for *.dcom and *.sysout files be a suitable workaround for customers to know about?

(Michael:  based on Bill's communication, who should submit an EditAR with attn: Roach)?

--Marty
*start*
00565 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 14:23 PST
From: vanMelle.pa
Subject: Re: Ar #561
In-reply-to: Raim.pasa's message of Tue, 10 Apr 84 13:10 PST
To: Raim.pasa
cc: vanMelle.pa, Sannella.PA, le.pasa, LispSupport.pa, 1100Support.pasa

Yes, setting DEFAULTFILETYPE to BINARY during COPYFILE of binary files is the workaround.  If DEFAULTFILETYPE isn't documented, it should be.

	Bill

p.s. Mike: There is a related AR, attn me, that Dolphin/Dorado {DSK} does not support TYPE.  Perhaps/Moderate/Moderate/DesignImpl.
*start*
00861 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 13:58 PST
From: vanMelle.pa
Subject: TEdit: Excrutiating performance underneath Put
To: TEditSupport.pa
cc: vanMelle.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  7-Apr-84 20:16:56
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Impact: Serious

I was editing a file of modest size (13000 bytes) from Phylum, and did a Put of it to {DSK} after some editing.  It took a long time (don't know exactly how long; I gave up and went to lunch).  The reason it was taking so long was that apparently for every piece, it was calling OPENFILE and CLOSEF of the file behind the piece (the file on Phylum), which happened to be OPENP anyway!  Although the file was not large, it had nearly 300 pieces in it, so you can imagine this took a while.
*start*
01030 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Apr 84 14:04 PST
From: vanMelle.pa
Subject: TEdit: Put locks out the world
To: TEditSupport.pa
cc: vanMelle.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  7-Apr-84 20:16:56
Machine: Dorado (Archimedes)
Microcode version: 24,4
Memory size: 10000
Impact: Serious

The aforementioned Put that took forever was initiated from the fancy menu.

(1) This tied up the mouse, so I had to spawn mouse to get one for other uses.

(2) While the Put was happening, Tedit refused to accept input in other windows.  For example, I called up a Tedit Report form to report the awful performance.  It happily flashed its caret at me, but refused to accept input until that completely unrelated Put finished (at which time it did process my typeahead).

(3) Also during this long Put, all other Tedits were flashing their carets at me, even though NONE of them was the tty process.  They stopped this inappropriate flashing after the Put finished.

	Bill
*start*
00987 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 05:36 PST
From: Wallace.pa
Subject: Lisp: Compiling LAMBDA
To: LispSupport.pa

Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000
Frequency: Always
Impact: Moderate

Is there any way to compile a function that doesn't have a name?   I use LAMBDA to close functions over some variables, and it's awfully slow to interpret those functions every time.

david

Example: I have:

(DEFINEQ EMACS.COMMAND (LAMBDA (FN)
  `(LAMBDA (STREAM)
     (PROG ((SUCESSP (ERSETQ (EMACS.APPLY* ',FN STREAM))))
       (IF (NULL SUCESSP) THEN
           (TEDIT.NOTIFY STREAM "Command Aborted" '(FRESHLINE)))
       (IF (NEQ (CAR SUCESSP) 'NUMERIC.ARG) THEN
           (WINDOWPROP (EMACSSTREAM.WINDOW STREAM) 'NUMERIC.ARG 1) ELSE
         (TEDIT.NOTIFY STREAM (CONCAT "Arg: " (WINDOWPROP (EMACSSTREAM.WINDOW STREAM) 'NUMERIC.ARG))
                       '(CLEARW))))))*start*
00470 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Apr 84 23:21 PST
From: Wallace.pa
Subject: Lisp: Copying floppies.
To: LispSupport.pa

Lisp System Date:  8-Apr-84 18:02:02
Machine: Dlion
Frequency: Always
Impact: Minor

IWBNI there were a way to copy floppies over the ethernet (even accessing them via {foo.floppy} would be acceptable).  Right now you have to do floppy.from.file and floppy.to.file which take 15-20 minutes each.

david
*start*
00585 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 00:16 PST
From: Wallace.pa
Subject: Lisp: (OVERFLOW T)
To: LispSupport.pa

Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000
Frequency: Always
Impact: Serious

Doing (OVERFLOW T) causes all sorts of things to break (just try it; they're too numerous to list).  It should either work or be taken out of the manual.  Personally, I prefer to run with it, as if I'm causing arithmetic errors I'd rather find the problem than see weird behav
iour.*start*
00595 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 00:33 PST
From: Wallace.pa
Subject: Lisp: Ensuring the closed-ness of a file
To: LispSupport.pa

Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000
Frequency: Always
Impact: Moderate

Is there any way to ensure the closed-ness of a file?  Apparently CLOSEF doesn't guarentee to close the file until you log out.  That's a screw.  I've been calling CLOSEALL, but I'd like to selectively close individual files (so I don't screw other processes).

david

*start*
00829 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 02:47 PST
From: Wallace.pa
Subject: TEdit: Centring of display
To: TEditSupport.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000
Frequency: Always
Impact: Minor

IWBNI operations such as FIND and SUSTITUTE centred the thing they found rather than positioning the line in question at the top of the screen.  It's frequently helpful, especially in SUBTITUTE to see more context than just the one line in question.

Also, I noticed in the old TEDIT that SUBSTITUTE wouldn't mark (underline) its subject string if it was in the top line in the display.  I haven't been able to get SUBSTITUTE to work in the new Tedit to see if this is still true.
*start*
02766 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 10:56 PST
From: Sannella.pa
Subject: [Magnus Ljungberg <Magnus@SRI-AI.ARPA>: Problems?]
To: LispSupport

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

Received: from SRI-AI.ARPA by PARC-MAXC.ARPA;  1 FEB 84 09:07:20 PST
Date: Wed, 1 Feb 84 09:07:37 PST
From: Magnus Ljungberg <Magnus@SRI-AI.ARPA>
Subject: Problems?
To: Stansbury.pa
cc: Magnus@SRI-AI.ARPA

Hi Tayloe:
Here is a first problem dump from us; some of the problems are of such a
nature that people here are going back to Fugue.4 with all its problems.

Openstream with resonable arguments results in an illegal arg: 141499636
Closeall did not come back after this error.

TEDIT looses files, gets holes in files, and mixes up beginning and
end of a file.  There have been cases where a perfectly normal file
suddenly contains a lot of unprintable characters, shown as black
boxes on the screen.

The system hangs in file accesses to the local disk.

There is often breaks upon 'login', apperently the system is trying to
reopen NS streams but it breaks in a 'NIL udf.', this was also a problem in
fugue.4.

The figures shown in the Interlisp File System Window is not coherent with
(DIFFERNCE 11688 (VMEMSIZE)), why?

It seems like pages are not marked as free after a file is being deleted,
this is an intermittent problem.

When MKDIR is called with a LV that allready contains a directory it seems
like the new directory is put 'after' the old one, the space is not reclaimed,
why?

Whem I repartition the disk some of the space in the Dsk LV is not reclaimed,
i.e. the system comes up with much less than 1000 pages left.  Also MKDIR
complains that there already exist an directory, which can't be read by
(DIRECTORY)

(DIRECTORY '{DSK}) hangs, we fix this by <ctrl><shift><delete> into
TELERAID and then ^D.  Why isn't <ctrl><shift><delete> documented? It
is an excelent feature!

UNPACKFILENAME is not consistent with OPENFILE:
(UNPACKFILENAME 'FOO.BAR.3) => ( -- VERSION 3)
while openfile opens a file named FOO.BAR.3;1 given the same argument.

The system seems to get more problems the longer it is run, I normally
repartition the disk every second day or so.

What are your own experience from this system, could our problems stem from
the fact that we use 10 M byte drives?

I would appreciate if you could give me a call, to discuss the present
problems, and what you will do before the release.
Thanks and looking forward to hearing from you,
		/Magnus
PS. Sorry about the poor linguistics in the message, I prepared the text on
a IBM-PC. DS.
PPS.  We are all impressed by the increased speed of the system, even if we
have hoped that XNS would be even faster.
-------

     ----- End of Forwarded Messages -----
*start*
03322 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  2 APR 84 20:50 PST
From: JONL.PA
Subject: Re: TEDIT BUGS etc.
To:   LispSupport
cc:   1100Support.pasa

Date:  2 APR 84 17:35 PST
From: JONL.PA
Subject: Re: TEDIT BUGS ETC.
To:   WWOODS@BBNG, 1100SUPPORT.PA@BBNG
cc:   LISPSUPPORT.PA@BBNG, WOODS@BBNG, JONL, LispCore^

In response to the message sent  Tue, 6 Mar 84 14:34:26 EST from WWOODS@BBNG.ARPA

I've been wanting to respond to your comments about TEDIT for some time
now -- I think several other persons on LispCore^.pa have seen it, and
have some thoughts, but it hasn't been expressed yet.  John Sybalsky,
who is developing TEdit, has made some strides forward, and David Wallace
has resurrected Kelly Roach's library package called EMACS (hooking into
the programmable interface of TEdit to provide guess-what-kind-of user
interface).

First, some trivial things:
T1) you can search for a string containing just about any character you
   want (modulo interruptchars, which TEdit seems to turn off anyway) just
   by "escaping" the character with ^V in the string;  this particularly
   applies to ? and to CR
T2) I like the idea of the font-selection menu having each menu item print
   out in the font designated by its name.  MENUs indeed can have a bitmap
   for an item (or for the CAR of an item) so it wouldn't mean having all
   the font "in core" just to create this menu.

Second, I'd like to add my support to your suggestion for certain functionality
which I'll just call "Serious Lacunae"
SL1) TEdit is far too "mouse bound".  this shows up no only in the lack of
   cursor-motion and scrolling keys, but also in the large number of user
   hand motions necessary for search, move, and copy commands (see next two
   points).
SL2) Searching is overly cumbersome to initiate; it begins at an obscure
   place in the file, and often doesn't provide enough of a "standout" at
   the point whereat the item was found.  Some time ago I suggested an EMACS-
   like incremental search for TEdit, but if the <Lisp>Library> package to
   support EMACS style isn't overly-confining, maybe that will be satisfactory
   by itself;  I don't know about too many other editors, but EMACS doesn't
   start its searching from "the beginning of what is visible in the window"
   and although I appreciate the problem  (especially when the caret is in
   some obscure place) I don't think you can dispense with exact-position
   for the start place;  I too would rather see the "found place" centered
   on the window rather than placed at the top (like BRAVO does).
SL3) There is no easy way to mark your place in the file and come back to
   it.  EMACS has the concept of a ring-buffer (eight long) of marked places,
   which is very useful, and TECO of course has "variables".  Would it be so
   hard to implement "variables" for TEDIT, which remembered file spots?
SL4) Undo should be like teh LISP editor to be really useful.  Yes, and double
   yes!  I too have often been hit by inadvertent nudgings of the undo key
   (while reaching for BS key) and discovered it only after typing something
   else, thereby losing all my work.


All in all, your memo was very thoughtful, and I for one appreciate your
taking the time to record all these things in an orderly fashion.

  - JonL -

*start*
00912 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  3 APR 84 16:21 PST
From: ROACH.PA
Subject: Brian Smith comments concerning TEDIT
To:   LISPSUPPORT
cc:   ROACH

     Comments from Brian Smith to Emacssupport^ relevant to Tedit:

    (1) "Tabs are set to 5 (i.e., at columns 1, 6, 11, etc.)  Is this
controllable?"  (What IS the motivation for having .5 inch tabs rather
than say 7x8=56 pixel wide tabs with and tab stops at multiples of 56
in TEDIT.DEFAULT.FMTSPEC which would be convenient with the
TEDIT.DEFAULT.FONT (GACHA10MRR) and would make life easier going
between MAXC's EMACS and TEDIT?)
    (2) "too much formatting, and ... too much redisplaying."  "it
looks as if every character you type redisplays the line, which is
surely crazy."
    (3) "whereas using the scroll bar obviously uses bit-blit,
inserting a carriage-return re-formats everything below you."

				Kelly
*start*
01642 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: MASINTER.pa
Date:  3-Apr-84 23:19:34 PST
Subject: fyi, walnut
To: lafiteSupport



----------

Date:  2 Apr 84 08:27:00 PST (Monday)
From: elliott.PA
Subject: dealer notes for 3/7
To: dealernotes^
cc: willie-sue, donahue
Reply-To: elliott.PA

Willie-Sue Orr described Walnut5, a major redesign of the Walnut mail system.  Walnut currently has several annoying "features" and some major deficiencies.  She discussed how they intend to solve the current problems, including hiding transaction aborts at the lowest level, retrieving new mail in parallel rather than as a single transaction, finding ways to deal with the proliferation of message set buttons, finding better ways to display large message sets, and adding a full programming interface.  There was a "mailing" discussion (the successor to "printing" discussions) for suggestions for enhancements and features.

Jim Donahue discussed the current state and future plans for Cypress and Squirrel.  Cypress is an entity/relation model database system, and Squirrel is a browser/editor for Cypress data bases.  The main lessons they learned about how database applications should be structured and about how Cypress should change are: transactions are painful, especially in handling aborts gracefully; contrary to most of the data base literature, the user wants many data bases; and Cypress type checking is too expensive, especially for primitive types.  To address these, they plan to cache schemata over a closed transaction, redo the DBStorage level, speed up type checking, and build a Cypress server.
*start*
00522 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 19:33 PST
From: Wallace.pa
Subject: Lisp: Resetting interrupts
To: LispSupport.pa
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

I set keyboard interrupts in my EMACS process which are different from the default ones.  Frequently I notice that they are still in effect when I go back to my exec window.

I can reproduce this by shrinking my EMACS window, but I suspect this is not the only time this problem occurs.

david
*start*
00478 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: masinter.pa
Date:  5-Apr-84  1:05:56 PST
Subject: some extra hair for your Tooldriver script
To: LispSupport

Could we get it to send me a message about all of the AR numbers on my summary sheet? E.g., the same set of ARs, but the report would just be

number, number, number, ....

Or, maybe, all those ARs which were edited or submitted in the last week?

Just some ideas; not for immediate action.
*start*
11887 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: masinter.pa
Date:  5-Apr-84  1:39:04 PST
Subject: Many ARs
To: masinter, LispSupport

I typed these in on my little portable; there are a bunch of ARs. I'm gonna download it; I hope there isn't too much junk in the message.

System:other software
Subsystem:loadup
Impact:moderate
Problem type:wish
Priority:hopefully
Difficulty:moderate
Subject:want "tiny" loadup
Description:A number of applications would like a 'minimum runtime' 
environment, into which they could load their applications. This is a 
'hard' problem because it may require moving things around in files so 
that the parts of the system tht are ENVIRONMENT (like DWIM etc.) are 
separated from the part of the system that are LANGUAGE (like macros). 
-------------------------------------
System:other software
Subsystem:other
Impact:moderate
Problem type:wish
Priority:possibly
Difficulty:very hard
Subject:want a prolog
Description:a large number of customers have expressed a strong desire 
to have a working PROLOG implementation supported by Xerox. There are a 
couple of starting places, e.g., Kolmorowski's Interlisp-based prolog 
and Deutsch's concurrent prolog. The simplest way of handling this is to
get some machines to Harvard and Edinburgh and let Jellinek monitor 
their progress.
-------------------------------------
System:OS
Subsystem:vmem
Impact:moderate
Problem type:wish
Priority:Hopefully
Difficulty:hard
Subject:want larger address space on 1108
Description: idea is to increase Interlisp-D address space to 24 bits. 
Requires a number of separate tasks to be done: change map flags, change
page format, increase size of MDS type table, change microcode to know 
about new MDS size, lock down new space, determine all places in system 
that 'know' about address space including ugly constants hidden in 
LLPARAMS, VMEM, REMOTEVMEM, MAKEINIT, etc.
-------------------------------------
System:kernel
Subsystem:compiler
Impact:moderate
Problem type:performance
Priority:hopefully
Difficulty:moderate
Subject:want boxless floatingpoint mode
Description:for real floatingpoint performance, we need a mode of the 
compiler that uses unboxed numbers on the stack. Now, how to get that?

Design: add FIXP, FLOATP declarations. Variables declared that way are 
automatically made localvars and renamed. All access to the variable in 
non-arithmetic cases are made into BOX references (so this can 
NEGATIVELY IMPACT performance because of upward funarg number problem 
can't handle any other way).

E.g., bind X _ N turns into bind XUNBOX _ (VAG N) ; reference to X turns
into (LOC X). Optimization, (FPLUS A B) turns into (LOC (UBFPLUS (VAG A)
(VAG B))) and (VAG (LOC Z)) turns into Z. The FPLUS transformation 
should be taken only if A or B are known to be forms which generate 
LOCs.

-------------------------------------
System:text
Subsystem:printing
Impact:moderate
Problem type:wish
Priority:perhaps
Difficulty:moderate
Subject:want Interpress decomposer
Description:Ron Kaplan started on a program that would read Interpress 
files and display them. If we had a program that would read Intepress 
files, and from that, generate a Lisp program which actually created 
that file, we could proceed toward some pretty interesting and general 
utilities; e.g., we could take the diagrams tht were generated by Star 
and move them back into a paramaterizable and editable format. I suggest
this as an AR rather than an idea for, say, Ken Feueurman, because I 
think that there are probably some capabilities that are needed in the 
intepress generation code that aren't there. In fact, it would be best 
if the interpress reader generated DIG code, e.g., so that you could 
then run the program on the display. (It is almost necessary to do that 
if you are going to display an interpress document in a window smaller 
than the document.)
-------------------------------------
System:kernel
Subsystem:compiler
Impact:moderate
Problem type:performance
Priority:perhaps
Difficulty:moderate
Subject:debug compiler optimizations with stack relative instructions
Attn: charnley, vanMelle, JonL, Masinter
Description: This AR is in two parts. One part is to write microcode for
COPY.N and STORE.N two-byte opcodes for doing stack relative addressing.
I suggest that in addition to COPY (= COPYN 0) we have COPY1, COPY2, and
then a (hard, slower COPY.N two byte). This design is partly because 
there is a much bigger difference on the Dolphin, but pprobably it will 
also make a difference on DLion. 

Now, what to do with this? Well, there is already built into the 
compiler a large suite of optimizations based around stack relative 
addressing, including duplicate sub-expression elimination, and getting 
rid of extra frames where all args are local, etc. I think that the next
round of compiler wizardry will rely on the ability to address more than
the top of stack.
-------------------------------------
System:environment
Subsystem:file package
Impact:moderate
Problem type:bug/wish
Priority:Hopefully
Difficulty:Moderate
Subject:rationalize file package information about file location
Description:Currently, the internal representation of where the 
'external' source of a file is is pretty ad-hoc. For example, when you 
LOAD a file, it pays attention to the filename in the FILECREATED 
expression. In fact, this turns out to be a non feature in environments 
like Interlisp-D where users tend to move files from one place to 
another quite frequently.

I think the right way of handling this is to remove the pretense that 
the system can keep track of where the file was originally made as a 
meaningful concept. Rather, it should only pay attention to where it 
FOUND the file. To ensure that this is adhered to, we would change the 
file name in FILECREATED to be the generic (internal) file name rather 
than the external name. Secondly, we would make LOAD and LOADFROM etc. 
explicitly store in some kind of a-list database the correspondence 
between internal external etc. files. (This is an off the cuff design 
but it is the simplest.) For example, one list might be just a list of 
'load events': (internalname externalname filetype loadtype time) in 
reverse order of occurrence. Then we would ensure that those packages 
which were looking up some information about a file would just look it 
up in the 'load event' database with the appropriate functional 
interface. This would simplify a lot of internal hackery in the file 
package, and also allow us to rationalize what happens when you make a 
file on the floppy, copy it to disk, compile it on the disk, move both 
to the file server, etc. 

It would mean tht files wouldn't have {phylum} built in and the system 
wouldn't be looking for it all the time. We could remove the hack from 
FINDFILE and every place that was looking at the FILEDATE property.
If, for performance reasons, the A-list becomes to onerous, we could 
build a cache. This discussion belongs in the one about 'moving files' 
that somebody submitted.
-------------------------------------
System:OS
Subsystem:generic file
Impact:moderate
Problem type:wish
Priority:Perhaps
Difficulty:hard
Subject:want remote dialin, chat server, etc. capabilities from dumb 
terminals
Description:This AR covers a number of similar tasks which should be 
done in parallel to avoid duplication. The general idea is to be able to
talk to Interlisp-D from a remote terminal. There are as many instances 
of remote terminals as there of CHATs going out: RS232, Ttyport, Chat, 
NS Telnet, and eventually TCP/IP telnet. This job is done in a couple of
different steps:

a) make sure that Interlisp-D can still run with window package either 
turned off or not loaded. This means making sure that all of the places 
that assume windows in fact have conditional code that tests if the 
window system is on. 
Secondly, need some way of changing the keyboard stream from {KEY} to 
one of the other bisync streams. It probably means rewriting the low 
level keyboard driver to go thru the stream interface. The next hard 
problem is making sure that the process that is running the keyboard 
stream gets frequent cycles, partly because even if there is some low 
level buffering going on, there needs to be immediate attention to 
interrupt characters (so the user can control runaway processes).

Finally, we need some kind of access protection login mechanism, and a 
way of limiting the use of the machine (e.g., making everybody login, 
and if you are logged in, then you can't log in from over the net.)

Finally, and much harder, is allowing some kind of distributed terminal 
controller select one out of a number of machines and give the pretense 
of a timesharing service from a bank of networked Interlisp-D machines. 
This is hrder because there is no way of booting the machine over the 
network, and the personal machine doesn't have the crash recovery 
properties that you need for remote access of unattended machines to 
work.
-------------------------------------
System:text
Subsystem:tedit
Impact:moderate
Problem type:wish
Priority:perhaps
Difficulty:moderate
Subject:support CSLI EMACS interface to TEdit
Description: CSLI is doing their EMacs interface and developing it, but 
in order for Xerox to distribute it, we may need to support it. That 
means tht we have to have some in house expertise on its implementation 
and be willing to add it to the set of supported packages.
-------------------------------------
System:language
Subsystem:interpreter
Impact:minor
Problem type:design-impl
Priority:hopefully
Difficulty:moderate
Subject:fix macroexpansion not to use DWIM
Description: There is no reason that the feature of Interlisp-D 
expanding macros at interpret time has to be done via DWIM. And it is 
embarrassing. And it is easy to fix. I think it might even solve some of
the problems that the current DWIM-based interpreter has. There is still
a question about DWIMINMACROSFLG, i.e., whether DWIMify gets called on 
the macro body before the macro is expanded, because otherwise CLISPIFY 
has to be taken out of the standard system
-------------------------------------
System:programming enviornment
Subsystem:dwim
Impact:annoying
Problem type:Design-Impl
Priority:unlikely
Difficulty:moderate
Subject:separate out and make separately loadable all DWIMIFYENGLISH 
options
Description:This is just a misfeature that we should just as soon drop, 
the ability to say things like (if X is a Number then Jump in the river)

A) it doesn't work too well
b) it cruds up the code inside DWIM
There is hardly any other justification for doing this, since it doesn't
seem to get in the way when you don't use it. That's why the priority is
Unlikely.
-------------------------------------
System:#
Subsystem:
Impact:
Problem type:
Priority:
Difficulty:
Subject:
Description:
-------------------------------------
System:#
Subsystem:
Impact:
Problem type:
Priority:
Difficulty:
Subject:
Description:
-------------------------------------
System:#
Subsystem:
Impact:
Problem type:
Priority:
Difficulty:
Subject:
Description:
-------------------------------------
System:#
Subsystem:
Impact:
Problem type:
Priority:
Difficulty:
Subject:
Description:
-------------------------------------
System:#
Subsystem:
Impact:
Problem type:
Priority:
Difficulty:
Subject:
Description:
Subject:filebrowser and directory 
Subject:better DLion disk
Subject:Pilot disk for Dolphin/Dorado.
Subject:get rid of Alto emulator
Subject:want bignums
Subject:Reduce workingset 
Subject:Automate release procedure
Subject:enhancements to mailing list
Subject:TEDIT use DLion keys like Star
Subject:want paned windows
Subject:want message passing

[Michael: these last bunch are ones that are in another file tht I have on maxc on my directory LISPARS.TXT. I'll send that in as soon as Maxc comes back up]
*start*
00779 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 15:28 PST
From: Sannella.pa
Subject: [Kaplan.pa: Lisp: Caching NS files locally]
To: LispSupport

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

Date:  3 Apr 84 21:52 PST
From: Kaplan.pa
Subject: Lisp: Caching NS files locally
To: Vanmelle, Lispcore^
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dorado

CSLI folks have gotten wind of the fact that the ns filer doesn't support random access.  There was a plan at one point to automatically cache those files locally, either in {CORE} or {DSK}.  What is the status of that plan?  Is it likely to happen?  Is there any chance that the file server itself will support random access any time soon?

--Ron

     ----- End of Forwarded Messages -----
*start*
00878 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 15:30 PST
From: Sannella.pa
Subject: [stansbury.pa: Re: Lisp: Caching NS files locally]
To: LispSupport

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

Date:  3 Apr 84 22:27 PST
From: stansbury.pa
Subject: Re: Lisp: Caching NS files locally
In-reply-to: Kaplan.pa's message of 3 Apr 84 21:52 PST
To: Kaplan.pa
cc: Vanmelle.pa, Lispcore^.pa, Sheil

It is my understanding that random access is not supported in Services 8.0, which would mean that we would have to wait at least until the release of 9.0, which is probably too long.  Caching seems the only reasonable way to go.

Caching obviously presupposes a working dlion disk.  It is my hope that as soon as we get the dsk working reliably, someone (Bill?) will implement automatic caching.


-- Tayloe.

     ----- End of Forwarded Messages -----
*start*
00911 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 15:28 PST
From: Sannella.pa
Subject: [Kaplan.pa: Installing a dlion from a 2060?]
To: LispSupport

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

Date:  3 Apr 84 21:56 PST
From: Kaplan.pa
Subject: Installing a dlion from a 2060?
To: Lispcore^, 1100Support.pasa

There is a rumor floating around Stanford (Sumex and CSLI) that the install tool cannot install a sysout on an 1108 from a Dec 2060.  The rumor mentions something about an "STP" protocol that the 2060 doesn't support, even though it does support pupftp and leaf.

Does anybody know what the truth of the matter is (or should be)?  Do we expect that this should work (in which case the fact that it doesn't is a bug that should be looked into), or are we aware of this as a problem that everyone will have to live with?

--Ron  

     ----- End of Forwarded Messages -----
*start*
01011 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  4 Apr 84 15:32 PST
From: Sannella.pa
Subject: [MASINTER.pa: Re: Installing a dlion from a 2060?]
To: LispSupport

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

From: MASINTER.pa
Date:  3-Apr-84 23:53:23 PST
Subject: Re: Installing a dlion from a 2060?
In-reply-to: Kaplan's message of 3 Apr 84 21:56 PST
To: Kaplan
cc: Lispcore^, 1100Support.pasa

The fact that we COULD install Interlisp-D using the install tool from Maxc would indicate that either this DOES work and Stanford is confused, or else there is a bug with the DEC-20 implementation of PUPFTP that Stanford has which does not exist with the Maxc implementation.

(There is another alternative, whcih is that the 2060 is merely DIFFERENT in a way that the Install Tool cares about but is still within the specification. This latter alternative may explain the "STP error" message.

In any case, I am not aware of an AR on this problem.

     ----- End of Forwarded Messages -----
*start*
09839 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 13:14 PST
From: Masinter.pa
Subject: Another batch of ARs
To: LispSupport.pa

---------------------------------------
System: OS, Subsystem: Generic files
Impact: Moderate
Difficulty: Moderate
Priority: Hopefully
Subject: Performance problems with filebrowser and directory enumeration
Problem type: Performance
Description: This involves some rewrites of the interface between filebrowser 
and the file devices to regularize the interface, allow for the passing back of
a unique handle better than the file name which can identify the file (to avoid
further directory lookups for file browser operations; lookup can be 
intrinsicly VERY expensive esp for NS file servers but also for others), and 
allow FileBrowser to ask a priori the info that it wants (e.g., for PUP 
directory enumeration.) The other issue is deciding who sorts the file list; 
currently it is completely had hoc.
Filebrowser is also missing some essential features, such as DELVER
---------------------------------------
System: OS, Subsystem: DLion Disk
Priority: Absolutely
Attn: Purcell (for elaboration)
Problem type: Wish
Difficulty: Hard
The issue here is that we haven't fully elaborated ALL of the things necessary 
to make the DLion disk fully functional. We have some short-term goals, but the
long term goal includes things like file scavengers, Mesa compatibility, and a 
number of other issues that we've only briefly touched on.
Make the VMEM a real file, the Mesa/MFile/Basic Workstation compatibility issue

---------------------------------------
System: OS, Subsystem: Alto disk
Priority: Perhaps
Difficulty: Hard
Problem type: wish
Subject: Pilot disk for Dolphin/Dorado.
Description: As we proceed with 300 MB dorado disks, it will become more 
important to have a pilot-based file system for them that doesn't require 19 
partitions. The pilot microcode is there and possible to be integrated; JonL 
might be able to handle the integration
--------------------------------------
System: language, Subsystem: Dorado microcode
Impact: Moderate
Attn: vanMelle (for elaboration)
Difficulty: Hard
Priority: Perhaps
Subject: get rid of Alto emulator
Description: Almost all of the need for the Alto emulator in Interlisp-D on 
Dolphin and Dorado is gone. At least on the Dorado, it would free up 
substantial amounts of microcode space if we could get rid of the remaining 
needs. 
  we could either retain the current bootstrap/with/BCPL or convert over to a 
new boot regime (which would allow faster startup on Dorado, a real pain now to
swap in your workingset. 

I think the main tasks are to move the thernet controller from BCPL into Lisp (
which may solve some of the performance problems and also some bugs with the 
Dorado ethernet controller) and to move the disk controller into Lisp (maybe it
is there already). Can you fill this AR out some more, Bill?
--------------------------------------
System:language
Subsystem:arithmetic
Impact:moderate
Problem type:wish
Priority:perhaps
Difficulty:hard
Subject:want bignums
Description:this is a desire for a smoothly integrated BIGNUM package in 
Interlisp-D.
Smooth integration means that it fits well into the current way of Interlisp-D 
doing arithmetic. Interlisp puts few if any constraints on the way arithmetic 
is done or the word size (since we have both 32 and 36 bit implementations with
a variety of SMALLP ranges). However, the current Interlisp-D implementation in
places confuses INTEGER (arbitrary precision) with 32-bit arithmetic. Thus, one
of the preconditions may require running with OVERFLOW(T) and weeding out those
places tht are relying on implicit arithmetic modulus. 

Design A: 16-bit smalls, 32-bit mediums, arbitrary bignums.
All numbers are NUMBERP and FIXP (must change macro for FIXP, NUMBERP or maybe new opcode or bit in DTD). All arithmetic operations PLUS, TIMES, IPLUS, ITIMES etc work on bigs. TYPENAME is the proper way to distinguish between the three datatypes tht distinguished numbers. This involves minor changes to microcode, 
but massive rewrite of tha arithmetic UFNs, with some care exhibited. At the 
same time, we can add rational arithmetic. Rationals are NUMBERP not FIXP not 
FLOATP. 

Design B is just to get rid of the intermediate 32-bit quanta. This is probably
undesirable only because of the number of places in the system that use 32-bit 
boxes for things like clocks and timers.

It is imperative that "FIXP" be retained as a generic "INTEGERP".

It is reasonable when adding bignums to also add positive infinity and negative
infinity. These special quantities which are also FIXP are the value of 
MAX.FIXP and MIN.FIXP.

JonL has had a confusion between Interlisp FIXP and MacLisp FIXNUM and 
introduced some distinctions between FIXP and INTEGER. While MACLISP made that 
cut, it would be more reasonable for backward compatibility to say that ALL 
integers are FIXP.

This distinction probably will need to be elaborated in the manual.

--------------------------------------
System:environment
Subsystem:editor
Impact:moderate
Problem type:performance
Priority:perhaps
Difficulty:moderate
Subject:Reduce workingset of programming enviornment loop
Description:I assigned this to "editor" but it fits in with a number of other 
applications. As Gordon Novak reported quite a while ago, the memory 
requirements of the Interlisp-D read/edit/debug/etc. look are very very high. 
It was unreasonably high. One of the major complaints about the "unusable" 
performance on the 1100 and 1108 with 1.5 MByte was exactly that the 
environment workingset was too big. Now, ano matter how much memory you add, 
this is an issue because once you've run an application, your enviornment gets 
paged out, and the time to page it in is proportional to its workingset--- more
memory won't help in the long run, unless the calculation and the editor all 
fit into the memory of the machine. Now, what to do? The first thing is to run 
with RELEASEWORKINGSET and COREHAX thru the loop of doing a LOADFROM of a program, editing it using DEDIT, running it, hitting a breakpoint, showing the 
stack, etc. and look and see what gets swapped in, using COREHAX and possibly 
some better tools developed for this purpose. We might need to write something 
that logs what pages get swapped in and what datatype they are.  What actually 
has to change can only be determined after more investigation.
--------------------------------------
System:other software
Subsystem:release procedure
Impact:moderate
Problem type:wish
Priority:absolutely
Difficulty:moderate
Subject:Automate release procedure
Description:one of the major sources of confusion between one release master 
and the next has been exactly what is done in the release process. We need at 
least a document and preferably a PROGRAM which automates the processes that 
happen when doing a variety of tasks for LispSupport. (Perhaps document with 
major procedures embodied in programs.) For example, I would like to retain the
wish that LispSupport take charge of updating the release directories on [Rose]
, [Idun], [Ivan], [Aztec], and a number of other file servers which purport to 
hold the Interlisp-D release but in fact have old or out of date copies. 
Perhaps this is a job for Pasadena? They haven't taken on the job of supporting
the internal Xerox interlisp-D user community; I'm reluctant to add that to 
their burden, since they are so overloaded that they would let it slide and our
internal reputation would slip.

--------------------------------------
System:Text
Subsystem:tedit
Impact:moderate
Problem type:design-ui
Priority:absolutely
Difficulty:moderate
Subject:TEDIT use DLion keys like Star
Description:The current layout of TEdit doesn't look at all like the way that 
Star uses the extra function keys. I think that the Star or XDE design is just 
fine for most of them. In particular, using Larger/Smaller to change font size,
using Font to pop up a menu of choices (maybe with some chance of typing in a 
new font name in a pop-up prompt window), using Superscript/Subscript (may 
require moving lock/unlock elsewhere), using "Next" to hit next fillin slot, 
and shift-Next to hit previous one, using the "Find" button to invoke Find, 
etc. These interface engineering tasks are imperative for the acceptance of 
TEdit, even though they don't affect the 'engine' underneath. The lack of these
kinds of features is probably the major motivation for the retrograde movement 
to the weaker EMacs interface. While we need EMacs for other reasons, we 
shouldn't let it win for stupid reasons. There've been a variety of complains 
from users about this. My rough cut on design is "Make it look like Star or 
XDE, since that is what they designed the keyboard for."
--------------------------------------
System:window
Subsystem:window
Impact:moderate
Problem type:design-ui
Priority:hopefully
Difficulty:hard
Subject:want paned windows, independent scrolling, etc.
Description:the functionality of attached windows could have been generated 
more reasonably with the notion of a "paned" window. 

--------------------------------------
System:language
Subsystem:other
Impact:moderate
Problem type:design-ui
Priority:Absolutely
Difficulty:hard
Subject:want built-in support for objects and message passing,
Description:This AR is not only for the support, but also for some beginnings 
of the rewrite of the internals of the system to use object oriented 
programming to redo displaystreams and streams and the window system. A radical
appropach to this would be to steal the Smalltalk window system en mass and 
start from tht. It would have the advantage of a full-fledged object-oriented 
window system, and only some political disadvantages (or maybe they are 
advantages).
*start*
01852 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 17:03 PST
From: Kaplan.pa
Subject: Installing an 1108 from a 2060
To: Lispsupport, Lispcore^

I asked Chuck Schmidt at Sumex to try installing his 1108 from the CSLI 20 using the install tool.  He reports that it in fact doesn't work.  In fact, it appears that the more recent tool hangs up.  Is that the most recent tool?  Do we understand what is going on?  Do we need more information?  I wish someone more knowledgeable then me would look into this, perhaps asking Schmidt to help out.  But please cc me on any messages.

Ron
     ----- Forwarded Messages -----

Return-Path: SCHMIDT@SUMEX-AIM.ARPA
Received: from SUMEX-AIM.ARPA by Xerox.ARPA ; 05 APR 84 12:16:11 PST
Delivery-Notice: While sending this message to XEROX.ARPA, the
 SUMEX-AIM.ARPA mailer was obliged to send this message in 50-byte
 individually Pushed segments because normal TCP stream transmission
 timed out.  This probably indicates a problem with the receiving TCP
 or SMTP server.  See your site's software support if you have any questions.
Date: Thu, 5 Apr 84 12:10:28 PST
From: Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>
Subject: Re: IMAGEOPS stuff
To: kaplan.pa
cc: Eric@SU-CSLI.ARPA, Lane@SUMEX-AIM.ARPA
In-Reply-To: Message from "kaplan.pa@Xerox.ARPA" of Wed 4 Apr 84 20:12:41-PST

	Just to be sure, I tried loading a fugue4 sysout off of
Turing with both of the two Install Lisp Tools we have.
They are ILT 10.0 of 29 Nov 83 15:54 and XSIS ILT of 26-Jan-84 17:20
on Pilot 10.0.  Both of these tools report a length of 0 pages 0 bytes.
The former declares the sysout successfully installed after about a second,
and the later simply hangs and has to be rebooted.
	What Install Lisp Tool do you use on your 1108's?
--Christopher
-------

     ----- End of Forwarded Messages -----
*start*
01034 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 16:56 PST
From: Martin.pasa
Subject: [VANBUER@USC-ECL.ARPA: CHANGEBACKGROUND and bitmaps]
To: LispUsers^.pa
cc: Martin.pasa

Thought you all might like to see this.  

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

Received: from USC-ECL.ARPA by PARC-MAXC.ARPA; 30 MAR 84 08:27:10 PST
Date: 30 Mar 84 08:26 PST
From: VANBUER@USC-ECL.ARPA
Subject: CHANGEBACKGROUND and bitmaps
To: Martin.pasa
cc: VanBuer@USC-ECL.ARPA

From playing around with this, the restriction on bitmaps to get "right" results
is that the width of the bitmap must be a multiple of 8 and at least 16.  The
height is unrestricted.
Try this one:
(SETQ BBB(READBITMAP))
(24 14
"@@AOO@@@"
"@@B@@H@@"
"@@B@@H@@"
"@@D@@D@@"
"@@D@@D@@"
"@@H@@B@@"
"@@H@@B@@"
"OO@@@A@@"
"@@H@@B@@"
"@@H@@B@@"
"@@D@@D@@"
"@@D@@D@@"
"@@B@@H@@"
"@@B@@H@@")
(CHANGEBACKGROUND BBB)

Amazingly, the distortion is only 1% even though it's only a 14x24 tile.
	Darrel
-------

     ----- End of Forwarded Messages -----
*start*
01144 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from RUTGERS.ARPA by PARC-MAXC.ARPA;  5 APR 84 18:16:56 PST
Date: 5 Apr 84 21:16:44 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: Need to know a few XNS things
To: LispSupport.pa
cc: SHULMAN@RUTGERS.ARPA, marantz@RUTGERS.ARPA


	Roy Marantz has gotten up a preliminary 3Mb to 10MB packet
"transmorgifyer" so our DLions can talk to our DEC-20 3Mb Pup based
software (this all runs on an 11/60 running as a gateway between the
two.)  There are only a few problems:

	1) What XNS does the "Install Lisp Tool" send out before it will
	   do a PupFtp "install"?  What should we say back to start the
	   Pup based transfer?

	2) Every second or so the DLion sends out an XNS packet for I believe
	   routing info.  What should we send back to shut it up?

	3) During a "1 boot" when it asks for the time (code 937 on the
	   display panel) it does this with an XNS packet.  What is
	   the format of an XNS date/time request?

	Item 1 is critical to our continuing use of DLions since we
generate our own images to use daily.  Thanks.

							Jeff
-------
*start*
00252 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 APR 84 19:09 PST
From: ROACH.PA
Subject: MOVING TEDIT B(8) FILES TO MAXC
To:   LISPSUPPORT

     What is the proper way to move TEDIT 8-bit binary files to
MAXC?
				Kelly
*start*
02125 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: MASINTER.PA
Date:  5-Apr-84 23:08:10 PST
Subject: confusing Installation utility?
To: LispSupport, JFung.pasa, 1100Support.pasa

I'm concerned tht the "bad" installation utility that left too little space for virtual memory on an 1108 with a 10MB disk might be still running around. It is especially of some concern that there the 'PARC' version is different from the 'Pasadena' version: didn't we go to some trouble to straighten this out and copy the canonical floppy here?



----------

Date:  5 Apr 84 19:49 PST
From: Hausladen.pa
Subject: Problems with Loops sysout
To: Masinter
cc: Hausladen.pa

Hi Larry,

Here are some of the problems I had with getting Loops ready for distribution.  There appears to be two different types of Installation Utilities, one for PARC and one for XSIS in Pasadena. XSIS's installation utility has some extra options for starting Interlisp directly from the installation utility.

Also in testing the Loops standalone sysout for distribution to our customers, I ran into some problems I didn't understand.  The standalone sysout is over 91xx pages long.  On a 10megabyte disk, it appears to run out of Vmem when I try to run Truckin, or so it was suggested to me by some of the folks in Pasadena.  

The behavior that it exhibited is as follows: twice I load the sysout from floppies onto a dandelion in the burnin lab, using floppies made at PARC.  Once I used the  installation utility and diagnostics files form PARC and once using the floppies of XSIS. The demo works fine until I get to the Truckin game, were it appears to stop cold, ~30 seconds after starting the game.  This happened two times in a row.  None of the keys worked but the cursor still could be moved around and the cursor kept going back and forth between garbage collecting and a plain cursor.  I am building a new sysout with the latest lisp.sysout from Mike S.  I will make up some floppies tomorrow morning and see if that helps.   It could be that the lisp.sysout that I used earlier had a bug that is now been fixed.

Thanks, Mary
*start*
00767 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  5 Apr 84 23:21 PST
From: Wallace.pa
Subject: Lafite: mail file munged
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date:  1-Mar-84 14:24:22
Machine-Type: Dorado

{PHYLUM}<WALLACE>ACTIVE.MAIL is damaged in some way that prevents me from expunging old messages, except from the end.

Lafite's handling of this is bizarre.  When I ^ out of the error it leaves my display in a munged state (blank lines in the browser window).  I ought at least be able to undelete the offending messages, and call for help, having safely written my changes to disk.  Right now all I can do is close the browser, selecting the "Don't update" option.  This feels very unsafe.

david

*start*
04696 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 00:32 PST
From: Sheil.pa
Subject: New version of DEdit
To: lispcore^
cc: lispsupport, lispfriends^

There is a new version of DEdit on {phylum}<lispcore>sources (and in future loadups).

The major change is that DEdit's internal data structures have been revised so that they take 1/3 less space.  This should radically improve swapping performance over extended programming sessions.

A much requested feature: New function template. If one runs DF on either a name with no function defn (either real or spelling correctable) or with second arg NEW, i.e. DF FOO NEW, one is given a "blank" defn which will be installed on exit if any changes are made to it.

In addition, many bugs have been fixed and much general sanitation and reworking of the internals has taken place. 

Enjoy.

Beau

-------

Bug and feature requests fixed include: 

AR bugs fixed:

AR 38, 162: EVAL in DEdit uses wrong bindings
AR 174: Break under FONTCREATE
AR 254: DEdit redisplay (DEDITREPAINTFN) bug
AR 15, 290: ?= EditCom fails on 0-arg functions
AR 228: Shift select supports both COPY and the right shift key

Pre AR bugs:

Date: 14 Oct. 1982 !!!!!!
From: Raim.EOS
Subject: A fy in the Dedit ointment

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

Date: 12 Oct 1982 1304-PDT
From: VANBUER at USC-ECL
Subject: Small Dedit bug (later as P116, later still as P1149)

When using Control to batch commands, it's possible to screw up the editmenu.
I did point, point, point, typein, control down: replace, replace, control up, replace. After doing the 3 replaces, the replace menu item is still inverted!!

-------

Date: 23-MAR-83 13:59:04 PDT
From: vanMelle.PA

If you SWITCH a comment and a non-comment, the latter gets prettyprinted as a comment.

-----

Date:  4 MAY 83 18:17 PDT
From: JONL.PA
Subject: TAB key in DEdit

There seems to be some ocasional "race" condition concerning DEdit's use of the TAB key....

--------
Date: 31 MAY 83 09:52 PDT
From: KAPLAN.PA
Subject: Font glitches in Dedit

Dedit seems to be confused about the height of fonts.  I deleted something and the top row or 2 of bits from what was previously there stayed on the screen....

-------

Date: 10 Jun 83 14:59 PDT
From: vanMelle.pa
Subject: DEDIT reprinting

... recently I have noticed several cases where after exit DEdit reprinted the entire function, apparently as a side effect of changing the edit date comment!

-------

Date: 18 June 1983 9:43 pm PDT (Saturday)
From: HALASZ.PA
Subject: Bug in Dedit in FUGUE

...IF you pass through the "standard" editor (use editcoms) on the way to Dedit AND if you delete something in Dedit AND you exit while the deleted item is still selected in the type-in window, THEN Dedit will smash the defn of the function and replace it with the deleted (selected in the type-in window) S-expression

-------

Date:  9 Jul 83 12:29 PDT
From: Masinter.pa
Subject: DEDIT glitch -- () creates circular structure

if I do EDITE((A B C)), middle-bug the expression twice and then button (), it creates a circular structure which results in a stack overflow.

------

Date: 20 Jul 83 12:35 PDT
From: vanMelle.pa
Subject: Dedit: Illegal arg NIL to FONTCREATE

-------

Date: 27 JUL 83 20:59 PDT
From: ROACH.PA

If the EditOps menu overlaps my active chat window, then Chat and Dedit play king of the mountain, fighting over whether the menu or the chat window should be on top.

--------

Date: 26 JUL 83 16:40 PDT
From: ROACH.PA

I still occasionally get 9126 "Shouldn't happen! DEDITDSPS tangled" losing my Dedit

--------

Date:  6 Feb 84 16:40 PST
From: Kaplan, BURTON

If you SETQ(FOO '((X . Y))), then DV FOO, select the (X . Y) sublist, typein (A . B) and hit replace, the screen shows ((A . Y)) instead of ((A . B))

-------

Date:  6 Mar 84 12:40 PST
From: Stansbury.pa

Select the entire structure you're editing and then apply Break to it.  Tries to wrap infinitely many break1's around the structure and ends in stack overflow.

--------

Date: 27 SEP 83 23:02 PDT
From: JONL.PA

if you have some expression that has multiple copies of an atom on it, e.g.
    (BITBLT DS LEFT OLDBOTTOM LEFT DS LEFT  ...]
and start a Find for LEFT, it will find the first LEFT in the line, but subsequent Find commmands just hang there and will not advance to later instances.

--------

Date: 27 SEP 83 23:02 PDT
From: JONL.PA

if the cursor is "near" the top of the screen, then holding TAB down will snuggle the menu over to the cursor into such a position that some of it will be clipped off the screen.

--------

Not everything made it into this version. Over the next few days, I'll be dumping my residual bugs into the AR system.

*start*
00328 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 08:57 PST
Sender: Sannella.pa
Subject: Re: New version of DEdit
In-reply-to: Sheil.pa's message of 6 Apr 84 00:32 PST
To: Sheil.pa
cc: LispSupport.pa
From: LispSupport.pa

Should I assume that all of the "Pre AR bugs" are still outstanding?
*start*
02980 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 09:00 PST
From: Sannella.pa
Subject: [Sybalsky.pa: Re: TEDIT BUGS ETC.]
To: Lispsupport.pa

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

Date:  4 Apr 84 13:51 PST
From: Sybalsky.pa
Subject: Re: TEDIT BUGS ETC.
In-reply-to: JONL.PA's message of 2 APR 84 17:35 PST (a reply to Woods' list of comments)
To: JONL.PA
cc: Sheil, LispCore^.PA

First off the bat, I think it was poor taste to carry discussions like this outside the doors of Xerox.  I've got a reply to Woods in the works, filed as <Sybalsky>WoodsReply.TEdit; I think the correct protocol would have been for you to comment on that INTERNALLY.

To answer your points:

(T2) Well, now, I think you're wrong.  I suppose TEdit could store bitmaps for the stock fonts that appear in the font menu; not so, of course, for "Other" fonts.  I agree that showing the font names in the font would be a nice touch.

(SL1) Mouse boundedness is in the eye of the beholder.  I happen to prefer using the mouse to move around; still, reasonable people can differ.  That's why there are the functional interfaces to the various TEdit operations.  I have limited time to spend on things; unless you're volunteering to implement a TEDITKEYS package....

(SL2)  Same answer.  If you want an expert "Find" command, write one.  I don't have the time, unless customer demand pushes it upward on the stack.  By the way, have you tried the TEDITMENU package?

(SL3)  is answered in my draft answer to Woods.  I claim that what you usually want is several panes on the editing window, so that you can have visible all the places in the file you need to remember.  Marker tokens, I think, are mainly useful in an editor macro language--which is another issue; such a macro facility would be nice (especially if they could be "compiled" to run fast).  Still, it takes user demand to push things up the stack.  Right now, page layout seems to be a bigger item.

(SL4)  The problems with UNDO have been accepted as a bug report.  However, I have no plans to support UNDOing operations out of sequence--the problems are just too hairy.

-----

Date:  5 APR 84 15:21 PST
From: JONL.PA
Subject: Re: TEDIT BUGS ETC.
To:   Sybalsky, JONL
cc:   Sheil, LispCore^

In response to the message sent   4 Apr 84 13:51 PST from Sybalsky.pa

John, it so happens that Bill Woods has been a personal friend of mine
for nearly 20 years.  It also so happens the Bill and I long ago had personally 
discussed features of EMACS that we would like to see in TEdit, *** and I even
supplied him with the arpanet addresses so that  he could forward his own
comments through the official channels.

Since the only non-Xerox recipient of my reply was Bill himself, and since
the reply contained essentially the comments I had long ago personally
discussed with him, I don't see how this constitutes "carry[ing] discussions
outside the doors of Xerox".


     ----- End of Forwarded Messages -----
*start*
02605 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 09:54 PST
From: Kiewiet.pasa
Subject: 1100Support procedures
To: Roach.pa
cc: Raim, 1100Support, LispSupport.pa

Kelly,

Today I received a msg from Marty that AR370 was Fixed.  One of my responsibilities as Customer Liaison is to follow up on the disposition of my customers' ARs.  

AR370 includes a message directly from you to the customer, with no cc to 1100Support.

This could create confusion and does waste time, because the Customer Liaison assigned to Pittsburgh (me) was not aware that you had told her the following:

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

By the way, I believe  the first sentence of (4) in incorrect information.  Release of source files is an issue being discussed at a MUCH higher level than the 1100Support dl.

There have been some messages lately regarding the need for Xerox to have one point of contact for customer.  If you respond  directly to Pittsburgh, without informing us, you will not only get more questions sent directly to you, but confuse the customer as to where to direct queries.

Lastly, one of the goals of our group of Customer Liaisons (a part of the 1100Support dl) is that we learn from each of these  answers to bug reports.  That is why you should send your responses to us for redistribution to the customer.

Lorraine
*start*
00341 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 10:17 PST
From: Sheil.pa
Subject: Re: New version of DEdit
In-reply-to: LispSupport.pa's message of 6 Apr 84 08:57 PST
To: LispSupport.pa

NO!!! They are the ones that I fixed!!

Beau

PS: The unfixed ones will dribble in over the next fewe days as ARs.
*start*
00325 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Sender: Sannella.PA
Date:  6 Apr 84 10:45:12 PST (Friday)
Subject: FXPRINTER
To: Barrera.pasa
cc: LispSupport
From: Masinter
reply-to: LispSupport

Still have not gotten a pointer to your new version of FXPRINTER for release to [phylum]. Where'd it go?

*start*
01018 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 11:35 PST
From: Barrera.pasa
Subject: Re: FXPRINTER
In-reply-to: Masinter's message of 6 Apr 84 10:45:12 PST (Friday)
To: LispSupport.PA
cc: Barrera.pasa

There are two basic reasons why I have not done as you requested.

The first is that I've spent most of this frustrating week dealing with hardware problems and software incompatiblity problems.

The second is that Marty doesn't want to put FXPRINTER out on LISP>LIBRARY because he is not ready to make it available to customers yet.   But I guess <LISPCORE> is a whole different story.  

So the bottom line is I haven't gotten around to it, and I plan to talk to Marty about it as soon as he is available.  I would transfer it over myself, except that we are having problems with too many people changing things on the public files and I have been directed to try to keep things within the "chain of command".

But thanks for the reminder.  I will do what I can.

Stephanie
*start*
02429 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 11:44:21 PST (Friday)
From: JFung.pasa
Subject: Re: confusing Installation utility?
In-reply-to: MASINTER.PA's message of 5-Apr-84 23:08:10 PST
To: MASINTER.PA
cc: LispSupport.PA, JFung, 1100Support, Hausladen.pa, Dering

Larry,

1.	Canonical Installation + Diagnostic Files floppies exist as evidenced by Sannella's message for "Fugue-6" release.

2.	I am not sure whether this version has the "options" to start lisp volumes from prometheus script, if not, then that will be included and we (I & Judy) WILL make sure to notify LispSupport on version changes.  
	(I think I am going to add some "key/mouse button" to start a Lisp without jumping into InstallTool, since field installation folks complained about taking away click both buttons to boot lisp)

3.	The story of how large a LispVolume on 10Mb disk is as follows:
	first, Diagnostics takes 3000 pages, {DSK} if exist in script takes 1000 pages, and the rest goes to Lisp (i guess around 12500 pages). I believe Judy has wrote down the figures on different configurations. Can you help Judy? 
	

	I believe the confusion or problem is not on the script but what should be the MINIMUM lisp volume to run on 10Mb, in this case LOOPS included so it will not "freeze".
	
	
----------------------------------------------------------------
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*
01592 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 11:47 PST
From: Masinter.pa
Subject: [Wogulis.pasa: Re: Interlisp internal documentation]
To: LispSupport
cc: Wogulis.pasa, Burton

I think this deserves an AR, system Window/Library, problem type: Performance (sort of), Impact: Moderate, subject: Grapher apparently holds onto graph windows after they are closed.

Does that sound right? Richard, any comments? Should this be VanLehn?

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

Date:  6 Apr 84 08:11 PST
From: Wogulis.pasa
Subject: Re: Interlisp internal documentation
In-reply-to: MASINTER.PA's message of 5 APR 84 23:43 PST
To: MASINTER.PA
cc: WOGULIS.PASA

Larry,

I see there is some documents on {phylum}<lispcore>doc> that might be close to what I want. I have not looked at them closely though.

The window creating I was doing was with SHOWGRAPH (from GRAPHER). As I remember it, this was the only windowing I was doing (aside from Dedits and Lafite). I'm not completely sure that this is what caused it . If I run into it again, I will try to pay more attention to what I had been doing.

By the way, what I am doing is writing some tools to help make the Lisp Library and Lispusers floppies we send to customers. The idea is to have all files that depend on one another on the same floppy i.e. BROWSER loads GRAPHER and GRAPHER loads SMALLFONTS, these should all be on the same floppy. Part of what I'm doing is graphing these dependencies as a tree structure as an easy way to see what is going on.

Jim

     ----- End of Forwarded Messages -----
*start*
01422 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 12:19:43 PST (Friday)
From: Sannella.PA
Subject: Questions from Shulman
To: vanMelle.pa
cc: Cooper.pa, JFung.pasa, LispSupport.pa

----------------------------------------------------------------
Received: from RUTGERS.ARPA by PARC-MAXC.ARPA;  5 APR 84 18:16:56 PST
Date: 5 Apr 84 21:16:44 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: Need to know a few XNS things
To: LispSupport.pa
cc: SHULMAN@RUTGERS.ARPA, marantz@RUTGERS.ARPA


	Roy Marantz has gotten up a preliminary 3Mb to 10MB packet
"transmorgifyer" so our DLions can talk to our DEC-20 3Mb Pup based
software (this all runs on an 11/60 running as a gateway between the
two.)  There are only a few problems:

	1) What XNS does the "Install Lisp Tool" send out before it will
	   do a PupFtp "install"?  What should we say back to start the
	   Pup based transfer?

	2) Every second or so the DLion sends out an XNS packet for I believe
	   routing info.  What should we send back to shut it up?

	3) During a "1 boot" when it asks for the time (code 937 on the
	   display panel) it does this with an XNS packet.  What is
	   the format of an XNS date/time request?

	Item 1 is critical to our continuing use of DLions since we
generate our own images to use daily.  Thanks.

							Jeff
-------

----------------------------------------------------------------
*start*
02746 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 Apr 84 17:01:58 PST (Friday)
From: JFung.pasa
Subject: Re: Questions from Shulman
In-reply-to: Sannella.PA's message of 6 Apr 84 12:19:43 PST (Friday)
To: Sannella.PA
cc: JFung, LispSupport.pa

Mike,

I hate to "speculate" on item 1, I can collect XNS packets with the CourierPeekTool (SDD's tool).   If you can wait, I'll try to gather these packets for you.  But, I will be in El Segundo testing DEI-DLion file transfer (teknowledge's crisis), next monday, tuesday....

Here is the speculation if you can't wait.

1).	What XNS does the "Install Lisp Tool" send out before it will
	do a PupFtp "install"?  What should we say back to start the
	Pup based transfer?
	
	The Install Lisp Tool does not send XNS packets on PupFtp install. When Dlion is power-up, the pilot boot file sends some XNS packets, like CH's BroaadcastForServers (pkt-exchange), CH's Retrieve Item(courier), Time-request/response(pkt-exchange), Router-request(Routing Info) packets.
	
When you retrieve sysout from NS file server, you will then encounter some XNS packets like:
	a.	Open-Connection {SPP system packets, sst=0} Pkt
	b.	Series of Filing (Courier) packets (Logon, Open-Directory, Open-Drawer, Open-Folder, Store, followed by proper Closes)
		I am not certain whether BulkData Transfer protocol is used in Pilot 10.
	c.	I am not sure whether Close-Connection packets (SPP with sst 254, 255) are used.	
		
Is this what they want?	(Im not sure whether I answered to the point)



3).	The XNS Time-Request packet is documented in XSIS Misc. Standards.  This may still be Xerox private.  Here is the format:

Time-Request Packet Format:

	Level-1:
		word 0:		Checksum
		word 1:		packet length
		word 2:		transport control/packet type
		word 3-7:	destination address (net/host)
		word 8:		destination socket
		word 9-13:	Source address	
		word 14:	source socket (time-socket =8)		

	Level-2:
		word 0-1:	packet-exchange ID
		word 2:		client type (1=Time packet)
		
    
	Level-3:
		word 0:		Protocol version
		word 1:		Request type (1)
		


Time-Response Packet Format:

	Level-1:
		word 0:		Checksum
		word 1:		packet length
		word 2:		transport control/packet type
		word 3-7:	destination address (net/host)
		word 8:		destination socket
		word 9-13:	Source address	
		word 14:	source socket (time-socket =8)		

	Level-2:
		word 0-1:	packet-exchange ID
		word 2:		client type (1=Time packet)
		
    
	Level-3:
		word 0:		Protocol version
		word 1:		Response type (2)
		word 2-3:	Current Time (GMT)
		word 4:		Offset direction
		word 5:		Offset hours
		word 6:		Offset minutes
		word 7:		Start of DST
		word 8:		End of DST
		word 9:		Tolerance flag
		word 10-11:	Tolerance (+/- msec).
	
*start*
00405 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 APR 84 21:37 PST
From: MASINTER.PA
Subject: Lisp.PrometheusScript on [rose] copy to [phylum
To:   LispSupport

michael, Rose was down when I tried to copy the files from Rose to Phylum.

I'm disturbed that we had different versions, and that the 'official' version of Lisp.PrometheusScript is nowhere to be found on Phylum.

*start*
01463 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 APR 84 21:55 PST
From: MASINTER.PA
Subject: your problem loading loops
To:   Hausladen
cc:   1100Support, LispSupport

Mary,

After talking to Judy Dering, I suspect that the problem with loading Loops that you had in Pasadena is NOT related to any problem with running out of virtual memory.

It may have been a problem with the sysout that you had, or the way in which it was stored on a floppy.

Can we try to reproduce the problem here?

Things to try:

a) can you load the same sysout over
the ethernet using the InstallTool or
Othello? If so, then suspect that the
floppy got written incorrectly, either
because  of a bug in the floppy driver 
or data corruption on the floppy itself.

If that fails in the same way, can you load the same sysout (either via ethernet or floppy) on a 29 Mb disk?


One possibility I just thought of: could this be an artifact of the problem that Prometheus doesn't extend the VMEM? Can someone find out (using the EIDisk diagnostic) whether the two machines Mary tried have bad spots on their disks?

The problem is that, while Prometheus (installation utility diskette) will install the lisp vmem as a single file, it doesn't extend it to cover the whole volume. Lisp, upon startup, is happy to extend the vmem willy-nilly, without checking for bad pages.

Was one of the 'top' or 'bottom' bars of the cursor turned on when the machine froze?

*start*
00786 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  6 APR 84 21:58 PST
From: MASINTER.PA
Subject: Floppy mode SYSOUT
To:   Roach
cc:   LispSupport

We currently have a problem in that the installation utility doesn't make the VMEM file big enough when you install from floppies.

One way around that is to mark the file on the floppy as having SIZE of 16000 pages, even though you only store as many pages as you need.

I think that is possible to do when writing the file. I'm not explaining this well, but it would fix something that is otherwise a show-stopper.

It would mean, however, that people wouldn't ever use Mesa to write sysouts anymore. It would also mean that it would be impossible to use the JFung hack of Install from one volume to another.

*start*
00689 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  7 APR 84 23:04 PST
From: MASINTER.PA
Subject: LispUsers packages
To:   DONC@ISIF
cc:   lispsupport

Don,

I don't know if I ever answered your message about LispUsers packages. I've got ALL, COMMENT, and a few others.

I think the Pasadena support staff has adopted a new policy tht they're not going to distribute stuff without testing it out. Maybe we should set up a separate real LISPUSERS directory tht everybody in the Interlisp world could contribute to , and then you would just FTP the files there (I'm worried for example tht we don't have the most recent versions. Wanna check out [maxc]<lispusers>?
*start*
00703 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from RUTGERS.ARPA by PARC-MAXC.ARPA;  8 APR 84 14:02:37 PST
Date: 8 Apr 84 17:02:47 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: How do you redefine \KEYHANDLER1
To: lispsupport.pa
cc: masinter.pa, raim.pasa, SHULMAN@RUTGERS.ARPA


	I asked this before but never received an answer:

	Under program control I would like to redefine the definition of
\KEYHANDLER1.  How do I stick the new definition into a running system
without having to execute a (HARDRESET)?

	This is very important since the Tutorial will have to do this
and the answer to this question is holding me up.

	Thanks.


							Jeff
-------
*start*
00643 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@From: masinter.pa
Date:  8-Apr-84 22:46:45 PST
Subject: LispSupport mail will also be archived on Maxc
To: Sannella
cc: LispAR.auto

As of this message, LispSupport mail will also be archived on maxc. That means that you don't have to sae things that were sent to LispSupport on CLOSED.Mail.

Mail that should be saved and is not sent to LispSupport should probably get forwarded back to LispSupport.

We probably will have to worry about this again later when Maxc goes away.

I was worried about the case where bug reports came in and got lost because of disk crashes.

*start*
00488 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Apr 84 23:09 PST
From: Wallace.pa
Subject: Lisp: Exit from SHOWAR
To: LispSupport.pa

Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000
Frequency: Always
Impact: Annoying

If you use the left-button menu item "QUIT" on the SHOWAR window it just hangs around (but only responds to right-clicks).  It should either close the window or not pop up a menu.
*start*
00449 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Apr 84 23:13 PST
From: Wallace.pa
S
ubject: Lisp: New LaFite bug forms are great
To: LispSupport.pa

Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000

I like these new bug forms.  How about deleting the blank line between sections so that mail readers that filter your mail can more easily classify the messages?*start*
00696 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  8 Apr 84 23:17 PST
From: Wallace.pa
Subject: Lisp: Errors while loading init file
To: LispSupport.pa

Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000
Frequency: Always
Impact: Moderate

When I load my lisp init file errors just print on the terminal, and execution continues.  I frequently start a fresh lisp and wander off while it loads.  When I get back I can't tell what errors have ocurred (they can scroll of the top of the window) which can cause weird behaviour.

Is there some variable I can set so that the system will ALWAYS break on errors?

david
*start*
00740 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 00:22 PST
From: Wallace.pa
Subject: TEdit: Shrinking new Tedit windows
To: TEditSupport.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000
Frequency: Always
Impact: Annoying

When the buffer's filename changes (by writing a new version), the next time you shrink the window you are reprompted for the icon's region.  It should use the old region (or, more efficiently, reuse the old icon, even).

Also, you should use the same filename pruner LaFite does so that files in your connected directory are represented without their device and directory.

david
*start*
01039 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 02:10 PST
From: Wallace.pa
Subject: TEdit: New IO window is in the wrong place
To: TEditSupport.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000
Frequency: Always
Impact: Annoying

The new tedit interaction window is created above the region created with the mouse (like titles were until recently).  This has two annoying effects:

1> If you make a region that abuts another window (I know, most people like overlapping windows, but I don't) the interaction window will obscure some of the text in the window above it.

2> If you make a region whose top is at the top edge of the screen, the interaction window is instantiated off the screen.  This means that it you select e.g. GET, the visible effect is that the caret stops blinking and responding to typein.  This is somewhat confusing.

david

Why don't you use something like EMACS.GET.REGIONS? 
*start*
00577 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 03:14 PST
From: Wallace.pa
Subject: TEdit: Pops up window when giving up TTY
To: TEditSupport.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000
Frequency: Intermittent
Impact: Annoying

One of my Tedit windows always pops up a little window when it gives up the tty (which means every time it gets input from the promptwindow).  This didn't start to happen until I got an error in the tedit.
*start*
00650 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 03:17 PST
From: Wallace.pa
Subject: TEdit: FIND sugestions
To: TEditSupport.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000
Frequency: Always
Impact: Minor

It would be nce if FIND printed out "(done)" when it's found its target string.  The underline is hard to find, and if it doesn't have to redisplay you don't notice when it's done.  It also might be nice to have it create a pending-delete selection, both for visibility and replacement convenience.

david
*start*
00853 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 04:17 PST
From: Wallace.pa
Subject: TEdit: No rom in hash table for meta-numbers
To: TEditSupport.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000
Frequency: Always
Impact: Serious

Whenever I try to evaluate the following form I get "HASH TABLE FULL":

(FOR I FROM (CHARCODE 0) TO (CHARCODE 9) DO
   (EMACS.MAKE.META.COMMAND I `(LAMBDA (STREAM)
                                  (\\COM.META.AUTOARGUMENT STREAM ,(IDIFFERENCE I
                                                                     (CHARCODE 0)))))) 

Where EMACS.MAKE.META.COMMAND is defined to be:


(TEDIT.SETFUNCTION (LOGOR 200Q (TOUPPER CHARNUM))
         (EMACS.COMMAND FUNCTION) TEDIT.READTABLE)*start*
00415 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 05:37 PST
From: Wallace.pa
Subject: TEdit: TEDITPROMPTFONT
To: TEditSupport.pa

TEdit System Date:  6-Apr-84 16:45:56
Lisp System Date:  8-Apr-84 18:02:02
Machine: Dorado (Ventana)
Microcode version: 24,2
Memory size: 10000
Impact: Minor

Shouldn't TEDITPROMPTFONT be TEDIT.PROMPT.FONT to be consistent with TEDIT.DEFAULT.FONT?
*start*
00475 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Mon, 9 Apr 84 09:44 PST
From: Raim.pasa
Subject: Re: 1100Support procedures
In-reply-to: "Kiewiet's message of 6 Apr 84 09:54 PST"
To: Kiewiet
cc: Roach.pa, Raim, 1100Support, LispSupport.pa

Lorraine,

There is indeed confusion here.  AR370 was addressed to the attention of M. Raim.  The subject was: " Must include floppy info in the release package"
This is fixed in the 1108 Users Guide.

m.

*start*
02592 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Return-Path: DONC@USC-ISIF
Received: from USC-ISIF by Xerox.ARPA ; 09 APR 84 10:58:06 PST
Date: 9 Apr 84 10:55:55 PST
Subject: Re: LispUsers packages
From: Don.Cohen <DONC@USC-ISIF.ARPA>
To: MASINTER.PA, DONC@USC-ISIF.ARPA
cc: lispsupport.PA
In-Reply-To: (Message from "MASINTER.PA@XEROX" of 7 APR 84 23:04 PST)

I can't tell what's up-to-date on maxc (I can do a directory thru ftp, but
not a vdir, and can't login as anonymous thru telnet...), so I'll let you
see what's current and what's not.  Judging from my collection of .tty
files, I have the following packages (here's my vdirectory):
 [USC-ISIF]  9-Apr-84  10:38:31

   PS:<DONC>
 TRACEIN..18;P775252        7 16673(7)   14-Mar-84 10:37:51 DONC      
   .TTY.5;P775252           5 10706(7)   19-Dec-83 16:00:23 DONC      
 ALL.COM.12;P775252         4 9588(7)    20-Dec-82 17:00:31 DONC      
   .LISP.35;P775252         3 7171(7)    20-Dec-82 16:59:12 DONC      
   .TTY.4;P775252           1 2483(7)    10-May-82 10:21:30 DONC      
 COMMENTS..5;P775252        3 7611(7)    21-Dec-82 17:44:42 DONC      
   .COM.5;P775252           4 9041(7)    21-Dec-82 17:45:38 DONC      
   .TTY.1;P775252           3 5532(7)     7-Dec-82 11:40:48 DONC      
 WAKEUP..11;P775252         1 1281(7)    20-Dec-82 17:33:39 DONC      
   .COM.2;P775252           1 1840(7)    20-Dec-82 17:38:45 DONC      
   .TTY.1;P775252           1 419(7)      2-Dec-82 13:21:02 DONC      
 LOSTLISTS..17;P775252      3 6090(7)    11-Apr-82 09:50:51 DONC      
   .COM.8;P775252           3 5839(7)    11-Apr-82 09:51:09 DONC      
   .TTY.4;P775252           3 5793(7)    11-Apr-82 10:36:42 DONC      
 PQUOTE..5;P775252          1 1352(7)     9-Apr-84 10:25:41 DONC      
   .TTY.2;P775252           1 931(7)      9-Apr-84 10:33:23 DONC      

 Total of 44 pages in 16 files

I welcome testing, especially if I can get the feedback.  As a summary
of these packages:
PQUOTE is, I think, a better version of the PQUOTE that you have (and
perhaps ought to be part of the standard Interlisp).
LostLists is only for Interlisp-10 (but it's quite useful there).
Wakeup is fairly trivial, only useful if your terminal can beep.
Comments is a documentation package (see how you like it).
All simply organizes files by the word being defined, rather than by
filepkgtype.
Tracein is a very useful debugging facility - one could make a pretty good
argument that it should be part of standard interlisp (the same argument
would hold for EVALHOOK.) - works in every interlisp as far as I know.
-------
*start*
00391 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 11:16 PST
From: Barrera.pasa
Subject: New version of FXPRINTER
To: LispSupport.pa
cc: Barrera.pasa


A new version of the FXPRINTER package has been moved to {PHYLUM}<LISPCORE>LIBRARY> along with updated documentation.  The Epson FX80 desk-top printer may now also be used as the default printing host. 
*start*
00711 00071 UU 
@00045 01536 ftffffffffffffffffffffffffffffff
@Date:  9 Apr 84 13:33 PST
From: Masinter.pa
Subject: Re: How do you redefine \KEYHANDLER1
In-reply-to: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>'s message of 8 Apr 84 17:02:47 EST
To: SHULMAN@RUTGERS
cc: lispsupport.pa, masinter.pa, raim.pasa

Jeff, I think what you need to do is just to redefine \KEYHANDLER1 at the beginning of the tutorial, with some kind of definition which tests and will run the normal keyboard handler. You also want to make sure that your new KEYHANDLER doesn't take up too much time -- the current one soaks up about 5% of all machine cycles, and if you're sloppy you could blow it up to 20% without much trouble.