*start*
00490 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from RUTGERS.ARPA by PARC-MAXC.ARPA; 12 MAR 84 12:50:42 PST
Date: 12 Mar 84 15:51:21 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: Record FunctionData from PCALLSTATS
To: lispsupport.pa
cc: SHULMAN@RUTGERS.ARPA
I am trying to get the lisp users package DISPLAYSTATS working.
It needs this record. Can someone either mail it to me or give me access
to PCALLSTATS. Thanks.
Jeff
-------
*start*
01711 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from RUTGERS.ARPA by PARC-MAXC.ARPA; 12 MAR 84 12:52:05 PST
Date: 12 Mar 84 14:14:56 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: CLISPFONT and CLISPWORDs
To: lispsupport.pa
cc: SHULMAN@RUTGERS.ARPA
Under the documentation for CLISPFONT (p 6.55) it says that this
is the font for printing clisp words "i.e. atoms with property CLISPWORD."
This might lead one to believe that any item with this property would be
printed in the CLISPFONT. The situation was this: I needed to augment
the record package to include something of the form:
(make <newitem> memberof <path> of <object>)
which would translate to:
(OR (MEMBER <newitem> (fetch <path> of <object>))
(replace <path> of <object> with
(CONS <newitem> (fetch <path> of <object>))))
So I then wrote a "tran" function and placed this function on the
CLISPWORD property of MAKE, make, MEMBEROF and memberof. "OF" and
"of" already had RECORDTRAN on the CLISPWORD property so I left it
(the doc on CLISPWORD (p 16.22) did not say it could be a list.)
Now, when a function containing my "make" form was prettyprinted both
the words "make" and "memberof" were boldface (the CLISPFONT) but the
word "of" was in plain text. To make a long story short, it turns out
that in order for prettyprint to print CLISPWORDs in the CLISPFONT each
word must have the same "tran" function on the CLISPWORD property.
I don't know whether to call this a bug or a "feature."
Jeff
P.S. I solved my problem by making "make" and "memberof" both
RECORDTRAN CLISPWORDs (like "of") and ADVISING RECORDTRAN to use
my "tran" if it sees the "make" keyword.
-------
*start*
00368 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 Mar 84 14:24 PST
From: Burton.pa
Subject: Re: Lisp: Loading problems
In-reply-to: Denber.wbst's message of 8 Mar 84 15:18 EST
To: Denber.wbst
cc: Burton.pa, Hannaway.wbst, LispSupport.pa
I mis-spoke about there being a new lisp.run, there isn't. I hope the microcode fixes the problem.
*start*
00367 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 Mar 84 14:29 PST
Sender: Lilly.pa
Subject: Lisp: Floppy documentation
From: Stansbury
To: LispSupport.pa
cc: Lilly.pa, Hausladen.pa
Lisp-System-Date: 25-Feb-84 17:29:22
Machine-Type: Dolphin
floppy.to.floppy in the documentation doesn't exist; it's called floppy.from.file.
-- Tayloe.
*start*
00485 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 Mar 84 14:38 PST
From: masinter.pa
Subject: Lisp: funny error when DIR {FLOPPY} on unformated floppy
To: LispSupport.pa
cc: masinter.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dandelion
It says NIL break: 1 (broken) and way up in the prompt window it gives me a message about "not a Pilot floppy".
I think the error should probably be HARD DISK ERROR, and the offender should be {FLOPPY}.
*start*
00746 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 Mar 84 16:20 PST
From: masinter.pa
Subject: Dering.pasa
To: lispsupport, 1100support.pasa
cc: masinter.pa
we should be cautious about including in user documentation internal interfaces which are likely to change.
The major external interface to the floppy device is thru using files on {FLOPPY}, which behave just like a local disk.
The only extraordinary ones (FLOPPY.FORMAT, etc.) were documented in the release message(s).
As far as I know, all other functions of the floppy device are "internal" and subject to change without notice. Is there anything not documented that customers need and which we should consider adding to the standard file interface?
*start*
00551 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 Mar 84 15:53 PST
From: vanMelle.pa
Subject: Re: Lisp and 10mb on Dolphin
In-reply-to: Vittal.pasa's message of Mon, 5 Mar 84 16:38 PST
To: Vittal.pasa
cc: LispSupport.pa
Sorry about that. I assembled new microcode for the 10 and 3+10 versions, and put on <LispCore>Next the files XMBDolphinLispMc.eb and X3DolphinLispMc.eb. I currently have no way of testing those here, so please try them out. If they're ok, these new .eb files can be moved to Lisp>Current.
Bill
*start*
00345 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 00:18 PST
From: vanMelle.pa
Subject: Re: Lisp: Documentation of MP Codes on DLION
In-reply-to: Halasz.pa's message of 9 Mar 84 16:31 PST
To: Halasz.pa
cc: LispSupport.pa
There is an updated MP code summary on {PHYLUM}<Lisp>Current>LispMPCodes.press.
Bill
*start*
00452 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 14:47:35 PST (Monday)
From: lispar.auto
Subject: Re: Record FunctionData from PCALLSTATS
In-reply-to: SHULMAN's message of 12 Mar 84 15:51:21 EST
To: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
cc: lispsupport.pa
The file [maxc]<Blisp>PCALLSTATS should be readable by you using anonymous FTP. Please let us know if you get DISPLAYSTATS to work.
Thanks,
Lisp Support
*start*
00425 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 Mar 84 10:28 PST
From: Burton.pa
Subject: Re: Lisp: Loading problems
In-reply-to: Denber.wbst's message of 8 Mar 84 11:04 EST
To: Denber.wbst, Hannaway.wbst
cc: LispSupport.pa
Are you using the new LISP.RUN and DolphinLispMc.run that came with Carol.1?
I am trying to load MM1201 here but ICE is not responding. I will keep trying.
richard
*start*
01150 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 MAR 84 10:29 PST
From: JONL.PA
Subject: Re: LISPSOURCEFILEP (and WHEREIS)
To: kaplan
cc: burton, lispsupport
In response to the message sent 2-Jan-01 7:36:02 PST from kaplan.pa
You're absolutely right that WHEREISNOTICE should be calling LISPSOURCEFILEP.
A next, coordinated-with-<LispCore> version of WHEREIS could do so.
I've been working on merging the "SYNOPSIS" stuff I mentioned before
with the hashfile version of WHEREIS -- current intermediate state is
on <LispCore>Library>NEWHASHWHEREIS. It will compile the synopsis but
stash it in a hashfile rather than on the property list.
This "compilation" process is somewhat similar to the analysis that the
extension to SINGLEFILEINDEX does -- I'm wondering if the lower-level
support ought not to go into the system (in FILEPKG).
Incidentally, I forgot to mention that the one lacuna in LISPSOURCEFILEP is
this: a non-RANDACCESSP file *** which is already OPENP *** can't be hacked.
A little thought about lacunae in NS filing will show why (GETFILEPTR
fails, in addition to SETFILEPTR's problems).
*start*
00458 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 Mar 84 11:01 PST
From: Kaplan.pa
Subject: Re: Lisp: ERRORTYPELST -- another candidate for process globals
In-reply-to: JonL.pa's message of 7 Mar 84 23:12 PST
To: JonL.pa
cc: LispSupport.pa
Why don't we make ERRORTYPELST a simple SPECVAR, not a global at all. It is only looked up under error conditions, and I can't believe it would be an interesting performance bottleneck.
*start*
00399 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 Mar 84 11:22 PST
From: Sybalsky.pa
Subject: Re: Bug Report
In-reply-to: Hannaway.wbst's message of Thu, 8 Mar 84 11:43 EST
To: Hannaway.wbst
cc: LispSupport.pa
Can you tell me the file dates for the version of TEdit that you had trouble with? This problem existed very briefly, and you may have gotten a bum copy....
*start*
00504 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 Mar 84 12:09 PST
From: vanMelle.pa
Subject: Re: Lisp: ERRORTYPELST -- another candidate for process globals
In-reply-to: Kaplan.pa's message of 8 Mar 84 11:01 PST
To: Kaplan.pa
cc: JonL.pa, LispSupport.pa
I agree--ERRORTYPELST should just be a specvar. It makes sense for users to change its global behavior (e.g. in their inits), but programs that rebind it clearly want changed behavior only in their own stack context.
*start*
00788 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 Mar 84 12:14 PST
From: Burton.pa
Subject: Lisp: Leaf incorrect error messages
To: LispSupport.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
I did (LOAD '{ICE}<DENBER>LISP>MM1201). The connection was slow and I got offered the window to abort the connection. I left it alone and eventually the file finished loading with a few "[ice not responding]" messages. About 15 seconds after the file finished loading, an "[ice not responding]" message appeared in the promptwindow. About a minute later a window appearred, offering a chance to abort the connection to Ice. About a minute later, the ICE#LEAF process went away. Is there some way of avoiding the bogus error messages?
richard
*start*
00769 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 Mar 84 12:14 PST
From: masinter.pa
Subject: [Maxwell.pa: Re: proposal for alternate syntax for FETCH and REPLACE]
To: LISPAR.AUTO
----- Forwarded Messages -----
Date: 8 Mar 84 08:20:35 PST
From: Maxwell.pa
Subject: Re: proposal for alternate syntax for FETCH and REPLACE
In-reply-to: "Your message of 7 MAR 84 08:25 PST"
To: MASINTER
Cc: maxwell
The only thing that I would add is that DEdit be changed so that a fetch would all appear on one line. Thus a fetch would appear as:
(: (TYPE FIELD) VAR)
instead of:
(: (TYPE FIELD)
VAR)
I've noticed that DEdit does this for FETCH and REPLACE, so its possible somehow.
John.
----- End of Forwarded Messages -----
*start*
00387 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 Mar 84 12:31 PST
From: Sybalsky.pa
Subject: Lisp: <Lispcore>Next> cleanup?
To: LispSupport.pa
cc: Sybalsky.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
Shouldn't most of the stuff on <Lispcore>Next> get moved back to Lispcore>Sources? And shouldn't the duplicate sysouts there be deleted?
*start*
00452 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 Mar 84 12:52 PST
From: Burton.pa
Subject: Re: Lisp: <Lispcore>Next> cleanup?
In-reply-to: Sybalsky.pa's message of 8 Mar 84 12:31 PST
To: Sybalsky.pa
cc: LispSupport.pa
I think that a version of full.sysout should always stay on <lispcore>next> so that we don't have to change our keyN.cm files for the few days between release and the first new "next" loadup.
richard
*start*
00327 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 Mar 84 13:49 PST
From: masinter.pa
Subject: Lisp: SPP Retransmit Queue out of order, (HELP broken)
To: LispSupport.pa
cc: masinter.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dandelion
in \SPP.RELEASE.ACKED.PACKET under \SPPINPUTWORK.
*start*
00565 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 MAR 84 14:07 PST
From: JONL.PA
Subject: Re: Lisp: ERRORTYPELST -- another candidate for process globals
To: vanMelle, Kaplan
cc: JonL, LispSupport
In response to the message sent 8 Mar 84 12:09 PST from vanMelle.pa
Then modulo lossages in the monsterscope of the system, all we need to
do is remove the GLOBALVARS declarations on ERRORTYPELST from COMMENT, HELPDL,
and MACHINEINDEPENDENT, and re-compile them. Barring any other constraints
on this, I'll do the edits tonite.
*start*
00587 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 Mar 84 15:18 EST
From: Denber.wbst
Subject: Re: Lisp: Loading problems
In-reply-to: Burton.pa's message of 8 Mar 84 10:28 PST
To: Burton.pa
cc: Hannaway.wbst, LispSupport.pa
OH NO! You mean there's a new Lisp.run? So how come the Carol.1 release notice says
"* BCPL initialization for 1100 (Dolphin) and 1132 (Dorado) [unchanged]". I'll admit I did miss the new microcode (that was marked unchanged in the original Carol notice). I guess that just might be the problem. Sorry about that.
- Michel
*start*
00474 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 14:58:10 PST (Monday)
From: lispar.auto
Subject: Re: CLISPFONT and CLISPWORDs
In-reply-to: SHULMAN's message of 12 Mar 84 14:14:56 EST
To: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
cc: lispsupport.pa
Jeff, your problem about CLISPFONT and CLISPWORD has been assigned AR number 6. (We are converting to a new internal database.) You may inquire about the status of ARs in future releases.
*start*
07044 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 14:47 PST
From: Sybalsky.pa
Subject: Lisp: TTYIN break after several ^E's
To: LispSupport.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dandelion
I make a typo, and hit ^E to stop executing the buggy phrase; I wound up with a NON-NUMERIC ARG NIL under GO.TO.RELATIVE ... under TTYIN:
57:BT
GO.TO.RELATIVE, GO.TO.FREELINE, ERRORSET, TTYIN,
TTYINREAD, LISPXREAD, ERRORSET, EVALQT,
\REPEATEDLYEVALQT, \EVALFORM, ERRORSET, \MAKE.PROCESS0,
T,
58:BTV!
Basic frame at 40014
40010: 0 0 *local* NIL
40012: 0 0 *local* NIL
40014: 100000 40010
Frame xtn at 40016, frame name= GO.TO.RELATIVE
40016: 140004 40005 [USE= 4, X, alink]
40020: 57220 47 [fn header]
40022: 40062 171 [next, pc]
40024: 40160 235 [nametable]
40026: 40014 40004 [blink, clink]
40030: 0 0 *local* NIL
40032: 0 0 *local* NIL
40034: 37614 13427 [fvar \CURSORROW on stack]
40036: 37616 13427 [fvar \CURSORCOL on stack]
40040: 177777 0 [fvar \DSP not looked up]
40042: 37572 13427 [fvar \LMARG on stack]
40044: 177777 0 [fvar \TTPAGELENGTH
not looked up]
40046: 177777 0 [fvar \LOC.ROW.0 not looked up]
40050: 177777 0 [fvar \CHARHEIGHT
not looked up]
40052: 177777 0 [fvar \BMARG not looked up]
40054: 177777 14 [padding]
40056: 0 47 [padding]
40060: 177775 2
GO.TO.RELATIVE,
Basic frame at 37770
37770: 100000 37770
Frame xtn at 37772, frame name= GO.TO.FREELINE
37772: 140001 37551 [USE= 1, X, alink]
37774: 57164 47 [fn header]
37776: 40010 44 [next, pc]
40000: 120000 16 [nametable]
40002: 37770 37550 [blink, clink]
40004: 40016 53 [padding]
40006: 0 13 [padding]
GO.TO.FREELINE,
Basic frame at 37534
37526: 3 64030 *local* (DUMMY.FOR.ERRORSET)
37530: 0 1315 *local* INTERNAL
37532: 0 0 *local* NIL
37534: 100000 37526
Frame xtn at 37536, frame name= ERRORSET
37536: 140001 37503 [USE= 1, X, alink]
37540: 44534 47 [fn header]
37542: 37770 1543 [next, pc]
37544: 140000 37520 [nametable]
37546: 37534 37502 [blink, clink]
37550: 0 114 \INSIDE.TTYIN T
37552: 4 1620 \TTYINSTATE ((& & 21 105 0) (32
78 73 76 93 80 82 69 83 --) NIL NIL 0 {STREAM}#1,66220
TOTOPW NIL)
37554: 1 66220 \DSP {STREAM}#1,66220
37556: 1 115200 \RDTBLSA {CHARTABLE}#1,115200
37560: 0 0 \RAISEINPUT NIL
37562: 0 31124 \FIRSTTIME NOPROMPT
37564: 0 3371 *local* EVALQT
37566: 16 25 \INITPOS 21
37570: 0 0 \BMARG NIL
37572: 16 0 \LMARG 0
37574: 16 575 \RMARG 381
37576: 16 7 \CHARWIDTH 7
37600: 16 14 \CHARHEIGHT 12
37602: 16 3 \DESCENT 3
37604: 1 156740 \FONT {FONTDESCRIPTOR}#1,156740
37606: 0 0 \VARIABLEFONT NIL
37610: 16 0 \TEXTURE 0
37612: 16 32 \TTPAGELENGTH 26
37614: 0 0 \CURSORROW NIL
37616: 0 0 \CURSORCOL NIL
37620: 0 0 \HOMEROW NIL
37622: 0 0 \HOMECOL NIL
37624: 0 127 \PROMPT1 _
37626: 0 0 \PROMPT2 NIL
37630: 0 0 \FIRSTLINE NIL
37632: 0 0 \LASTAIL NIL
37634: 0 0 \LASTAILCOL NIL
37636: 0 0 \LASTAILROW NIL
37640: 0 0 \FIX NIL
37642: 0 0 \LOC.ROW.0 NIL
37644: 0 0 \LASTCHAR NIL
37646: 0 0 \SPLSTFLG NIL
37650: 0 0 *local* NIL
37652: 0 0 \BUFFER NIL
37654: 0 0 \ENDBUFFER NIL
37656: 0 0 \CURSOR NIL
37660: 0 0 \ARROW NIL
37662: 0 0 \DELETING NIL
37664: 0 0 \INSERTING NIL
37666: 0 0 \EDITBIT NIL
37670: 0 114 \DONTCOMPLETE T
37672: 0 3371 \AUTOFILL EVALQT
37674: 0 0 \NOVALUE NIL
37676: 0 0 \NOFIXSPELL NIL
37700: 0 0 \STRINGVALUE NIL
37702: 0 0 \REPEAT NIL
37704: 0 0 \COMMAND NIL
37706: 0 3371 \READING EVALQT
37710: 0 3371 \LISPXREADING EVALQT
37712: 0 0 DIRECTORY/FILE NIL
37714: 0 31124 \NOPROMPT NOPROMPT
37716: 0 31125 \FILLINGBUFFER FILLBUFFER
37720: 0 0 \LAST.DELETION NIL
37722: 0 0 *local* NIL
37724: 0 31124 *local* NOPROMPT
37726: 177777 36 \INSIDE.TTYIN [unbound]
37730: 177777 13427 [fvar PROMPT not looked up]
37732: 177777 13427 [fvar SPLST not looked up]
37734: 37100 13427 [fvar \PRIMTERMTABLE on stack]
37736: 177777 13427 [fvar RDTBL not looked up]
37740: 37104 13427 [fvar TtyDisplayStream
on stack]
37742: 177777 0 [fvar \PRIMREADTABLE
not looked up]
37744: 177777 10 [fvar DEFAULTPROMPT
not looked up]
37746: 177777 13427 [fvar OPTIONS not looked up]
37750: 177777 157762 [fvar RESETY not looked up]
37752: 177777 10 [padding]
37754: 16 626 [padding]
37756: 0 217 [padding]
37760: 177751 52
37762: 177760 110
37764: 177760 146
37766: 177774 154
ERRORSET,
Basic frame at 37466
37446: 0 127 PROMPT _
37450: 0 0 SPLST NIL
37452: 0 0 HELP NIL
37454: 3 21454 OPTIONS (EVALQT FILLBUFFER
NOPROMPT)
37456: 0 0 ECHOTOFILE NIL
37460: 0 0 TABS NIL
37462: 0 0 UNREADBUF NIL
37464: 0 114 RDTBL T
37466: 100000 37446
Frame xtn at 37470, frame name= TTYIN
37470: 140001 37425 [USE= 1, X, alink]
37472: 45524 47 [fn header]
37474: 37526 137 [next, pc]
37476: 1 66140 [nametable]
37500: 37466 37424 [blink, clink]
37502: 0 0 LISPXHIST NIL
37504: 0 0 RESETY NIL
37506: 0 0 *local* NIL
37510: 4336 11022 [fvar LISPXHIST top value]
37512: 123440 401 [fvar RESETVARSLST
non-stack binding]
37514: 177777 137 [padding]
37516: 0 17 [padding]
37520: 0 47 [padding]
37522: 177774 4
37524: 0 0 NIL
TTYIN,
Basic frame at 37410
37404: 0 114 *local* T
37406: 0 114 *local* T
37410: 100000 37404
Frame xtn at 37412, frame name= TTYINREAD
37412: 140001 37373 [USE= 1, X, alink]
37414: 67000 47 [fn header]
37416: 37446 155 [next, pc]
37420: 105744 40 [nametable]
37422: 37410 37372 [blink, clink]
37424: 0 0 *local* NIL
37426: 37074 13427 [fvar \LINEBUF.OFD on stack]
37430: 62072 11022 [fvar \INSIDE.TTYIN top value]
37432: 177777 13427 [fvar LISPXID not looked up]
37434: 177777 0 [fvar READBUF not looked up]
37436: 177777 17 [padding]
37440: 177776 0 [padding]
37442: 0 37 [padding]
37444: 177776 0
TTYINREAD,
*start*
00486 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 14:50 PST
From: vanMelle.pa
Subject: Lisp: ICONW title is sensitive to Radix
To: LispSupport.pa
cc: vanMelle.pa
Lisp-System-Date: 25-Feb-84 17:23:38
Machine-Type: Dorado
TITLEDICONW is putting up its titles in some character-by-character way that incorrectly is sensitive to Radix. E.g., with (RADIX 8), if you call (TITLEDICONW MSGFOLDERTEMPLATE "X8") you get an icon whose name is "X10".
Bill
*start*
00377 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Mar 84 17:44 PST
From: Halvorsen.pa
Subject: Lisp: \TEDIT.RESHAPEFN
To: LispSupport.pa
cc: Halvorsen.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dandelion
Non numeric arg error when trying to reshape a tedit window under on DOSUERFNS2 when called with the FNLST arg (\TEDIT.RESHAPEFN).
*start*
01045 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Mar 84 17:49 PST
From: JonL.pa
Subject: Lisp: file with name 10
To: LispSupport.pa
cc: TEditSupport.pa
Lisp-System-Date: 7-Mar-84 13:56:45
Machine-Type: Dorado
On {Phylum}<JonL>Lisp> there is a file with name "10"; it seems most likely to me that Lisp created it [creationdate is 18-Feb-84 10:07, and I was hacking in Lisp from about 7AM that day until late afternoon]
Needless to say, I can't look at it from Lisp. Sooner or later there has got to be a way from within Lisp to manipulate files for which there is no LITATOM representation of the name.
When that time comes, TEdit is going to need a way to specify a filename by, say, a STRINGP. Is it really all that useful now for TEdit's first arg to be entered in the buffer when it is a STRINGP? I.e., why type the data as a string argument? Why not just get an "empty" file and type the string in directly to the editor? Coercion to textobj's could be used when a functional interface is required.
*start*
01018 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Mar 84 21:38 PST
From: JonL.pa
Subject: Lisp: a gazillion BREAK windows
To: LispSupport.pa
cc: JonL.pa
Lisp-System-Date: 7-Mar-84 13:56:45
Machine-Type: Dorado
While using the window break facilities, I did a "revert" to a PROG frame. Then another break window came up (for no good reason) which just said "PROG break1". Shortly after that, the machine went into an infinite loop of bringing up new break windows (overlaying each other); it was trying to print out some message to a displaystream for which WFROMDS wanted to create a WINDOW (looping around again because of some error).
The mouse and interrupts were completely dead during this ballet of break windows. Finally a stack overflow afforded me the opportunity to HARDRESET several times (the first time didn't do it!).
At least the phony break windows were partiallyh overlapping the background, so they could be disposed by:
(while (WHICHW) do (CLOSEW (WHICHW)))
*start*
01954 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 11 Mar 84 01:50 PST
From: Halasz.pa
Subject: Re: Lisp: DLion Local File System
In-reply-to: Sheil.pa's message of 10 Mar 84 10:04 PST
To: Sheil.pa
cc: Halasz.pa, LispSupport.pa
I am very unsatisfied with your answer w.r.t. the DLion file system. I want to stress that from my perspective (as a DLion user and as the technical support for the PSA and ARI-Leesburg projects) the Dlion file system is by a large margin the most serious problem with Interlisp-D. I believe that this perspective is shared by a large number of other DLion users and, more importantly, by the customers in the real world. (In fact, I recently received feedback to this effect from the people working on a DLion installed in the IMF in Washington). Given the importance of this piece of code, it is very disconcerting that no-one is working on it, or worse yet, no one is responsible for it. It seems to me that it should be the #1 priority at the moment.
I do have two suggestions:
1) Put someone in charge of the Dlion file system, even if they are not actively developing it. Several times I have bombed with file system problems and run around looking for someone to look at the state of the machine. No one has ever been willing to take responsibility for this task. I have tried to debug the code by myself. While I haven't found any major solutions, I can point out a number of bugs in the DLIONFS code I have discovered this way. It seems like a knowledgeable person doing this task might gain a lot of valuable insight just by looking at various problems when they occur.
2) Assign someone to take a day and write a 4-page memo on the structure of the DLion file system and to comment the code as best as possible. I would be willing to track down problems to the best of my ability. But I have a hard time making heads or tails of the code as it now stands.
Frank
*start*
01158 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 15:28 PST
From: vanMelle.pa
Subject: TEdit: caret looks
To: TEditSupport
cc: vanMelle.pa
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 25-Feb-84 17:23:38
Machine-Type: Dorado
There seems to be some new behavior here that is very annoying. If I select the cr at the end of a paragraph and type <cr><New text>, the new text is in a font that appears to have nothing to do with any font nearby. All the text in the neighborhood is in TimesRoman10, and the new text is in TimesRoman12 Bold, which is not even a font that I have breathed a word of in this editing session (though it is the font of the first character of the file, if that matters).
If I instead select the text before the final cr (caret is in same place, but selection is some TimesRoman10 text instead of the invisible cr), then I get the new text in TimesRoman10 as I expect.
I did notice, though, and applaud, that the looks of my typein are no longer affected by something that I copy select. That is, I can copy an italicized word and not have my typein thereafter be in italics.
Bill
*start*
00407 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Mar 84 16:42 PST
From: Halvorsen.pa
Subject: TEdit: Several different units used in the menu
To: TEditSupport
TEdit-System-Date: 1-Mar-84 13:54:34
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dandelion
What is the relationship between the unit used in the margin bar, and the unit used for specifying default tab size?
*start*
01266 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Mar 84 10:04 PST
From: Sheil.pa
Subject: Re: Lisp: DLion Local File System
In-reply-to: Halasz.pa's message of 9 Mar 84 15:27 PST
To: Halasz.pa
cc: LispSupport.pa, Brown.pa, Moran.pa
Frank:
I am indeed sorry to hear that the unreliability of the DLIONFS code has been causing you problems. It was for eaxactly these reasons that we withdrew it from the release and made it into a Library package, documented in the release message of two weeks ago with the caveat that it should not be used for "otherwise unretrievable files".
I share (as does all of LispCore^) your evaluation of this code.
I share (as does all of LispCore^) your evaluation of the desirability of this state of affairs.
As you know, the person responsible for this code left (at 10 days notice) with the code still incomplete. We do not, in the very short term, have anyone to replace him. We are looking, and in the meantime we will continue to do what we have been doing - make local patches when and where we can. I do not believe that this will prove sufficient (although I would be happy to be surprised).
I'd be delighted to hear any proposal you may have about how to how to fill this shortfall.
Beau
*start*
00284 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 MAR 84 15:28 PST
From: ROACH.PA
To: ROACH, LISPSUPPORT
cc: Re:, AR 7:, In response to your message sent 12 Mar 84 15:,,
12:
As stated previously, user had out of date documentation.
Kelly
*start*
00874 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 15:30 PST
From: Sybalsky.pa
Subject: Re: TEdit: Several different units used in the menu
In-reply-to: Halvorsen.pa's message of 10 Mar 84 16:42 PST
To: Halvorsen.pa
cc: TEditSupport.pa
Line and paragraph leading &c are specified in printer's points, of which there are 72 to the inch. The margin/tab ruler is denominated in picas, of which there are 6 to the inch--12 points to the pica. However, you can set margins/tabs in half-pica (6pt) increments.
I've tried several granularities of measurement, and find that picas is about as fine as you usually need to get.
I do plan, however, to put in the option for several scales (inches, points, cm, fixed-pitch, etc). The demand for this will determine the priority. I am aware of a desire for fixed-pitch grain; how about others?
*start*
00355 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 15:32 PST
From: Sybalsky.pa
Subject: Re: TEdit: Several different units used in the menu
In-reply-to: Halvorsen.pa's message of 10 Mar 84 16:42 PST
To: Halvorsen.pa
cc: TEditSupport.pa
Oops; the default tab size is specified in points as of now. (missed that part).
*start*
00819 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 9 Mar 84 14:22 PST
From: Wallace.pa
Format: TEdit
Subject: Lafite: "Re: <mumble>"
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
When I reply to a message, its subject gets inserted into my buffer with "Re: " attached. For example, replying to the following message:
Date: 8 MAR 84 20:10 PST
From: MASINTER.PA
Subject: batteries
To: wallace
Produces the following header:
Subject: Re: batteries
To: MASINTER.PA
Which isn't what I want. You don't need the "Re:" to tell it's a reply, since there's already an In-Reply-to: field.
��[���GACHA�
�����������N��� HELVETICA�
�����������!���GACHA�
�������������� HELVETICA�
�����������ˆ���GACHA�
����������i�z·*start*
00554 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 9 Mar 84 18:01 PST
From: Wallace.pa
Subject: TEdit: The case of the vanishing caret
To: TEditSupport
TEdit-System-Date: 1-Mar-84 13:54:34
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
If you hold down control and bug left, the caret vanishes. Now I know that that's not a defined state, but it's annoying; there's no way to get it back without moving it.
Come to think if it, there's no way to get a TEDIT window's attention without moving he caret, is there?
*start*
01750 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 9 Mar 84 19:05 PST
From: Nuyens.pa
Subject: Lisp: loadup death
To: LispSupport.pa
cc: Nuyens.pa,raim.pasa
Lisp-System-Date: 25-Feb-84 17:29:22
Machine-Type: Dolphin
While trying to run <lispnew>current>loadfull.cm (the cm file to remedy show-stoppers) to fix the corefile bd, I encountered the following:
The loadup could not find dlispdomino.db. The only reasonable one for this loadup is <lisp>current>dlispdomino.db. Despite Tayloe's changes to the directory paths in this loadup procedure today, it is still not looking in the right place.
When I tried to remedy this by putting the dlispdomino where it did look, (an on-the-fly fix more likely to win than changing the dir path half way through loadup) I received the warning that the version number did not agree with the interface page. The loadup later died in a raid-from-ucode. The user stack had only a clearstk, and the system stack had only a dofault (3frames deep, only). It wouldn't let me see the lisp screen to see how far the loadup had gotten. It had built the init.dlinit and the init.sysout.
I was going to retry with another dlispdomino.db but (guess what) none on lispcore>next. The newest thing on lispcore was created Jan 1. It is not obvious to me why the wrong dlispdomino.db should cause the loadup to die after getting so far, but raid gave me no context to try and deduce the problem.
First, is the warning about version disagreement a result of the wrong dlispdomino.db? If so, could someone come up with the correct one. If not, please suggest how to determine the cause of death of the loadup. In any case where is lispcore>next>dlispdomino.db?
Thanks,
Greg
*start*
00481 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 16:31 PST
From: Sybalsky.pa
Subject: Re: Lisp: NODIRCORE buffer leak found
In-reply-to: vanMelle.pa's message of 1 Mar 84 14:21 PST
To: vanMelle.pa
cc: TEditSupport.pa, Kaplan.pa, LispSupport.pa
I changed TEdit's stream machinery to use \BIN & friends instead of \PAGEDBIN &c. This is in the currently-released TEdit; please let me know if this fixes whatever the "NODIRCORE buffer leak" is.
*start*
01963 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Sat, 10 Mar 84 11:09 PST
From: WOGULIS.PASA
Subject: PRINTOUT
To: Kaplan.pa
cc: lispsupport.pa, 1100support.pasa
The following ( <SHULMAN.XEROX>PRINTOUT ) can be found on {ROSEBOWL}<LISPUSERS>PRINTOUT . It should be moved to an appropriate place on phylum.
Jim
Received: from RUTGERS.ARPA by PARC-MAXC.ARPA; 27 FEB 84 17:13:14 PST
Date: 27 Feb 84 20:13:14 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: New PRINTOUT functions
To: raim.pasa
cc: SHULMAN@RUTGERS.ARPA
The new PRINTOUT stuff is ready to be beaten on. It is in
<SHULMAN.XEROX>PRINTOUT. When you are satisfied with them you should
replace the stuff in DWIM with these.
The new things are:
* PRINTPARA now uses pixel positioning when printing to displaystreams.
* Bitmaps are now incorporated as a printout form. This new form
is .BM <before> <descent> <bitmap> which is implemented by the
function PRINTBM. <before> is the amount to scroll up the
displaystream before bitmap is displayed. NIL means don't
scroll, T means scroll the amount the bitmap extends above the
top of the current line, a number means scroll that amount above
the top of the current line. <descent> is how far below the current
line to BITBLT the bitmap. The window is scrolled up if there is
not enough room. The following line printed will be printed so
it doesn't overlap the bitmap. NIL means don't descend, a number
means descend that amount. <bitmap> is the bitmap to print.
The displaystream is left at the same Y position it was before the
BITBLT and advanced the width of the bitmap. If the bitmap is
too wide to fit a new line is generated.
Let me know what you think.
Jeff
-------
------------------------------------------------------------
------------------------------------------------------------
*start*
02073 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from RUTGERS.ARPA by PARC-MAXC.ARPA; 10 MAR 84 09:32:41 PST
Date: 10 Mar 84 12:31:01 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: New PRINTOUT functions
To: lispsupport.pa
You might want to include this in Carol. I was using a fairly
old version of DWIM (12/8/83) to get the printout stuff from. You
might therefore want to check it out carefully first (or send me
Carol's DWIM.) At least check where PRINTOUT should set the OUTPUT
file.
It can be FTP'ed with the ANONYMOUS login.
Jeff
---------------
Mail-From: SHULMAN created at 27-Feb-84 20:13:14
Date: 27 Feb 84 20:13:14 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: New PRINTOUT functions
To: raim.pasa@PARC-MAXC.ARPA
cc: SHULMAN@RUTGERS.ARPA
The new PRINTOUT stuff is ready to be beaten on. It is in
<SHULMAN.XEROX>PRINTOUT. When you are satisfied with them you should
replace the stuff in DWIM with these.
The new things are:
* PRINTPARA now uses pixel positioning when printing to displaystreams.
* Bitmaps are now incorporated as a printout form. This new form
is .BM <before> <descent> <bitmap> which is implemented by the
function PRINTBM. <before> is the amount to scroll up the
displaystream before bitmap is displayed. NIL means don't
scroll, T means scroll the amount the bitmap extends above the
top of the current line, a number means scroll that amount above
the top of the current line. <descent> is how far below the current
line to BITBLT the bitmap. The window is scrolled up if there is
not enough room. The following line printed will be printed so
it doesn't overlap the bitmap. NIL means don't descend, a number
means descend that amount. <bitmap> is the bitmap to print.
The displaystream is left at the same Y position it was before the
BITBLT and advanced the width of the bitmap. If the bitmap is
too wide to fit a new line is generated.
Let me know what you think.
Jeff
-------
-------
*start*
00358 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 MAR 84 17:38 PST
From: ROACH.PA
Subject: Missing STREAM accessfns
To: LISPSUPPORT
cc: ROACH
ACCESSFNS for datatype STREAM are missing in the declaration
of STREAM found on SYSTEMRECLST. They are also missing in EXPORTS.ALL.
Responsible person: KAPLAN.
Kelly
*start*
00609 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 17:54 PST
From: Masinter.pa
Subject: latest Lisp AR system
To: JFung.pasa
cc: LispSupport, 1100Support, LispCore^
Jerry:
We have now the latest LispAR.bcd and other files, stored on [phylum]<LispCore>Adobe>*.
You can retrieve them for 1100Support users to use.
We have started entering in AR's for mail to LispSupport sent during the last couple of days.
Please review the ARs in the database. The next two weeks is an experimental period while we get some understanding of how this system is really going to work.
*start*
01556 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 18:03 PST
From: Masinter.pa
Subject: [Jack Mostow <MOSTOW@USC-ISIF.ARPA>: another MS bug]
To: LispSupport
reply-to: Mostow@usc-isif
----- Forwarded Messages -----
Received: from USC-ISIF.ARPA by PARC-MAXC.ARPA; 9 MAR 84 18:38:29 PST
Date: 9 Mar 84 18:36 PST
Subject: another MS bug
From: Jack Mostow <MOSTOW@USC-ISIF.ARPA>
To: masinter.PA
Larry - MASTERSCOPE seems confused about its template for SET:
NIL
92_PP(EntriesOf]
(EntriesOf
[LAMBDA (cache) **COMMENT**
(EVAL cache])
(EntriesOf)
93_. EntriesOf CALLS EVAL
T
94_PP(SetEntries]
(SetEntries
[LAMBDA (cache entries) **COMMENT**
(SET cache entries])
(SetEntries)
95_. SetEntries CALLS SET
NIL
96_GETTEMPLATE(SET]
((IF (EQ (CAR (LISTP EXPR))
(QUOTE QUOTE))
(NIL SET)
EVAL)
EVAL . PPE)
97_GETTEMPLATE(EVAL]
(EVALQT .. EVAL)
98_. REANALYZE SetEntries
.done
99_. SetEntries CALLS SET
NIL
100_dribble]
NIL
5_CALLS(SetEntries]
((SET)
(cache entries)
NIL)
6_. DESCRIBE SetEntries
SetEntries[cache,entries]
calls: SET
called by: DeleteEntry,MakeCache,FixAffectedCache,AddEntry
NIL
7_dribble]
-------
As you can see, CALLS recognizes that SetEntries calls SET, while MASTERSCOPE
doesn't. If I understand correctly, the template says to ignore cases where
the first argument is quoted, since those are equivalent to SETQ, but not to
ignore other cases. However, it seems to ignore them anyway. Regards. - Jack
-------
----- End of Forwarded Messages -----
*start*
00388 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 MAR 84 18:06 PST
From: ROACH.PA
Subject: TTY windows when you SET in INSPECT
To: LISPSUPPORT
cc: ROACH
When you use the SET menu item in INSPECT windows, you invariably
create multitudes of TTY windows. I think the old promptwindow
interface was better.
Responsible person: BURTON.
Kelly
*start*
03153 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 18:06 PST
From: Masinter.pa
Subject: [Raim.pasa: Fugue.6 Release Kit]
To: Burke.pasa , Dering.pasa, JFung.pasa, Kiewiet.pasa, Le.pasa, Wogulis.pasa
cc: Martin.pasa, Raim.pasa, LispSupport
reply-to: LispSupport
This is an AR on the release process, and a request for action from 1100Support, and a request for LispSupport to track some of this information in the future.
PLEASE send mail to LispSupport.PA as new versions of source files and documentation are available for review. We plan to stage the "Fugue.6" release on [phylum]<LispNew> and, when approved, release to [phylum]<Lisp>.
I think it would be reasonable to avoid using [rose]<Lisp> except as a duplicate of [phylum]<Lisp>, and for you to stage your files on a different directory (<1100Core>?).
Also, please note that not all Library packages listed below have been "blessed" for inclusion in the release, dubious items include EXEC, SETF, current SINGLEFILEINDEX (as opposed to old SINGLEFILEINDEX).
Also, I think it is a mistake not to re-release the entire floppy set (perhaps automating the process of making them now that Interlisp-D floppy is in better shape.) I urge you to make a new consistent set, with distinctive labels, and to urge users to recycle old set. Otherwise, inconsistencies will plague our users and cause many spurious bug reports.
If you automate floppy creation (by writing a program that does the appropriate FLOPPY.FORMAT and COPYFILEs for each floppy), then the floppy maker could also be staged, tested, and released.
----- Forwarded Messages -----
Date: Fri, 9 Mar 84 18:38 PST
From: Raim.pasa
Subject: Fugue.6 Release Kit
To: Burke, Dering, JFung, Kiewiet, Le, Wogulis
cc: Martin, Masinter.PA, Raim
Here is the final cut of the Fugue.6 Release Kit.
1. Floppies
Lisp.sysout (tl)
Diagnostics Files (jd jf)
Installation Utility (jd jf)
Lisp Packages (jw)
2. 1108 Users Guide (pb)
Index (pb)
Overview (mr)
Operations (lk)
Software Installation
Formating the local disk
Installing from floppy disks (jd)
Installing from a fileserver (lk)
Installing from the local disk (lk)
I/O Support
Floppy disk drive (jd)
RS232 (tl jw)
Hardware diagnostics
On-line diagnostics
EI Fixed Disk Diagnostics
Maintenance Panel Codes
Lisp codes (lk)
1108 codes (tl)
3. Release notes:
Fugue.6 release notes (mr)
Fugue.4 release notes (mr)
4. Lisp Packages (jw)
Lisp Library
SYSEDIT
BQUOTE
CMLARRAY
CMLSPECIALFORMS
DATABASEFNS
DECL
EXEC
FILEBROWSER
GCHAX
GRAPHZOOM
LLCOLOR
MENUEDWINDOW
READAIS
READSYS REMOTEVMEM
RS232 RS232CHAT RS232EXEC RS232FTP RS232LOGIN
SETF
SINGFILEINDEX
TEDIT TEDITHCPY
TEDITMENU
TEXTOFD
TFBRAVO
Lisp Users
BANNER
BROWSER
COLORUTILITIES
CROCK
EDITFONT
EMACS
ICONW
KAL
LOADFILES
LSET
MAZE
NOTEPAD
PAGEHOLD
PIECE-MENUS
PLAY
SYSTAT
----------------------
If your documentation is in electronic form, please move it to [rose]<lisp>Carol>; otherwise, please have handedited hardcopy available.
----- End of Forwarded Messages -----
*start*
00507 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 MAR 84 18:19 PST
From: ROACH.PA
Subject: DIR BUG
To: LISPSUPPORT
cc: ROACH
When you do "DIR <LISPUSERS>CROCK LENGTH", you get dir info on
CROCK.TTY & CROCK.DCOM as well. I think this behaviour should only
occur if you typed "CROCK*", making DIR consistent with PHYLUM's
LIST, though I notice that "DIR <LISPUSERS>CROCK. LENGTH" gets me
what I want.
Responsible person: MASINTER.
Priority: SMALL.
Kelly
*start*
00243 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 MAR 84 16:41 PST
From: ROACH.PA
Subject: EXPORTS.ALL
To: LISPSUPPORT
cc: ROACH
I see file EXPORTS.ALL both on <LISP>LIBRARY> & <LISP>SOURCES>.
Kelly
*start*
00693 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 17:00 PST
From: vanMelle.pa
Subject: Re: Lisp: Cost of \DTEST vs (OR type-test ERROR)
In-reply-to: Kaplan.pa's message of 26 Dec 83 11:58 PST
To: Kaplan.pa
cc: vanMelle, LispSupport.pa
The (\DTEST arg 'ARRAYP) is more compact than (OR (ARRAYP arg) (LISPERROR --)), but probably is about the same speed in the normal (successful) case, since the DTEST is slightly slower than the TYPEP (the DTEST needs to do an extra memory reference), but the TYPEP needs to be followed by a jump.
But here's a bug report: ELT and SETA give error "ILLEGAL ARG" instead of "ARG NOT ARRAY" when given a non-array.
Bill
*start*
01227 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 12 MAR 84 18:39:18 PST
Return-path: <@SUMEX-AIM.ARPA:Brand Hal@LLL-MFE.ARPA>
Redistributed: Xerox1100UsersGroup^.PA
Received: from LLL-MFE by SUMEX-AIM.ARPA with TCP; Mon 12 Mar 84 17:56:47-PST
Date: Mon, 12 Mar 84 17:23 PST
From: "Brand Hal"@LLL-MFE.ARPA
Subject: RSX file server
To: dolphin-users@sumex-aim.arpa
We have a Dolphin and have finally got the 3Mbyte/sec Ethernet board
and software for our LSI-11/23 running RSX. We are using FTP from the
Alto Exec, and are experiencing terrible file transfer rates from the
Dolphin to the RSX machine. Imagine transfering a file of 1849344 bytes
and getting a transfer rate of 770 bits/sec!!! We have monitored the RSX
system and it is IDLE most of the time during the transfer! I know most
people use other machines as file servers, but we are too poor at present,
so, does anybody know why we are experiencing such poor transfer rates, and
better yet, does anybody know what (if anything) we can do to improve matters.
Is anyone beside us using a DEC PDP-11 running RSX as a file server???
Thanks,
Hal Brand
BRAND@LLL-MFE.ARPA
*start*
00399 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 MAR 84 18:26 PST
From: ROACH.PA
Subject: DEDIT EVAL BUG
To: LISPSUPPORT
cc: ROACH
This bug is 5 months old now. When you use the EVAL Dedit menu
option on a selection such as S, you get S's binding inside Dedit--
not what you want.
Responsible person: SHEIL
Priority: Somewhat Important.
Kelly
*start*
01000 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 18:28 PST
From: desRivieres.pa
Subject: TEdit: Dropped characters
To: TEditSupport
cc: desRivieres.pa
TEdit-System-Date: 1-Mar-84 13:54:34
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
I find that after Tediting a file extensively (2 or 3 hours), inconsistencies arise between what Tedit thinks is in the stream and what someone READing that stream sees; in particular, some characters are dropped when the stream in READ. For example, I have seen hyphenated atoms like "create-file-pointer" read as "createfile-pointer"; i.e., some, but not all hyphens dropped. Second example: "'foobar" read as "foobar". Note that when it happens, it is persistent --- reading the expression again always produces the same result. However, doing a PUT, QUIT, GET has always cured the problem, so Tedit has got things straight.
We it happens again, I'll try to find one of you to take a look at it.
---Jim
*start*
00480 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 18:12 PST
From: vanMelle.pa
Subject: TEdit: teditmenu
To: TEditSupport
cc: vanMelle.pa
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 25-Feb-84 17:23:38
Machine-Type: Dorado
It still doesn't supply the currently-being-edited filename as the initial contents of the braces by the Put command, which means it is still much more convenient for me to use the regular menu's Put command.
*start*
00994 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 12 MAR 84 19:40:01 PST
Return-path: <@SUMEX-AIM.ARPA:HEDRICK@RUTGERS.ARPA>
Redistributed: Xerox1100UsersGroup^.PA
Received: from RUTGERS.ARPA by SUMEX-AIM.ARPA with TCP; Mon 12 Mar 84 19:00:31-PST
Date: 12 Mar 84 22:01:05 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: RSX file server
To: "Brand Hal"@LLL-MFE.ARPA
cc: dolphin-users@SUMEX-AIM.ARPA
In-Reply-To: Message from ""Brand Hal"@LLL-MFE.ARPA" of 12 Mar 84 20:23:00 EST
We are using a PDP-11/60 running RSX as a front end to our DEC-20.
That is, the actual file server software is on the 20, but the
packets pass through the 11. We get transfer rates up to 100Kbaud.
We had to play with the software a bit to get those rates. The
throughput depends critically upon the strategies you use for
buffering, retransmitting, acknowlegements, etc. I would look
carefully at the BSP implementation.
-------
*start*
00610 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 20:36 PST
From: desRivieres.pa
Subject: Lisp: OPENSTRINGSTREAM
To: LispSupport.pa
cc: desRivieres.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
I'm having trouble with OPENSTRINGSTREAM when I subsequently READ it with my own readtable, which has most special characters wired as read macros (including [,],(,), and '). Most of the time, I get END OF FILE. Things work just fine if I supply the same string directly to READ. Similarly, there are no problems if no read table is passed to READ.
--- Jim
*start*
00446 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 MAR 84 21:04 PST
From: MASINTER.PA
Subject: Want Clearinghouse tools like Maintain
To: LISPSUPPORT
Status: Wish
Impact: Annoying (?)
System: Communication
Subsystem: NS protocols
I'd like to see a uniform interface to grapevine and clearinghouse that included maintain-like capabilities.
The NS interfaces are neither documented nor as convenient as Maintain.
*start*
01197 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 MAR 84 21:31 PST
From: ROACH.PA
Subject: Adobe fields
To: lispsupport
cc: roach
I think "Subject:" belongs at the top of the AR. It would probably
also make sense to keep all the short items in one place by moving
"Assigned To:", "Priority:", "Edit-By:", & "Edit-Date:" above the
lengthier "Disposition:", "Description:", "Workaround:", and "Test Case:".
I would arrange the top half of an AR as:
number, date
subject
assigned to, priority
problem type, impact, status
system, machine
subsystem, disk
source files
lisp version, microcode version
file server, server software version
submitter, attn
edit-by, edit-date
I.e., keep the interesting stuff at the top, names of people farther
down. (If "In/By:" is supposed to be when the problem gets solved, you
can stick it up near "Priority:").
The bottom half of an AR I would organize as:
description
test case
disposition
work around
or as:
disposition
work around
description
test case
Question. Am I allowed to check out ARs, or should I work completely
through LISPSUPPORT mail? Am I allowed to use AR submit?
Kelly
*start*
01162 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 13 MAR 84 08:38:44 PST
Return-path: <@SUMEX-AIM.ARPA:MARANTZ@RUTGERS.ARPA>
Redistributed: Xerox1100UsersGroup^.PA
Received: from RUTGERS.ARPA by SUMEX-AIM.ARPA with TCP; Tue 13 Mar 84 08:05:49-PST
Date: 13 Mar 84 09:33:36 EST
From: Roy <MARANTZ@RUTGERS.ARPA>
Subject: Re: RSX file server
To: "Brand Hal"@LLL-MFE.ARPA, dolphin-users@SUMEX-AIM.ARPA
In-Reply-To: Message from ""Brand Hal"@LLL-MFE.ARPA" of 12 Mar 84 20:23:00 EST
We're using RSX, but alas not as a file server only as a packet transfer
interface "medium". I've been hacking RSX for a while now and might be able
to help you speed things up. You can speed up RSX by playing games with
F11ACP and such to make file access faster, but that in general would
depend on how you access files with the file server. Anyway I'd be interested
in getting the files server code (although I don't know if I'd use it).
Let me know if you want more detailed help. (If so why not send me privately
so as not to clutter up this list detailed info on you configuration
and sysgen)
Roy
-------
*start*
00725 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 MAR 84 22:27 PST
From: ROACH.PA
Subject: Proposed ADOBE "Difficulty:" field
To: lispsupport
cc: roach
The "Impact:" field measures how difficult it is for the customer
to live with a problem, but there seems to be no field indicating
how difficult it will be for the Assignee to fix the problem. "Priority:"
only estimates the chances that the problem will ever be solved and
"In/By:" deadlines are bound to slip with little correlation between
nearness of the deadline and complexity of the problem. How about adding
a "Difficulty:" field. Difficulty could range over values Impossible,
Dream, Hard, Moderate, & Trivial.
Kelly
*start*
00806 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 23:33 PST
From: Halasz.pa
Subject: TEdit: The margin bar in TEDITMENU is bad news.
To: TEditSupport
cc:
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dandelion
If you open two TEditMenus on two different TEdit windows, there is only one margin bar. This means if I change the margin bar for one TEdit window, the margin bar in the other TEdit window changes its setting as well (since they obviously point to the same Lisp object).
This is very, very bad news and should be changed tuit suite. TEdit windows are (conceptually) independent editors. It causes the user much confusion and frustration to have this little element of non-independence stuck in there.
Frank
*start*
00978 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 09:02:41 PST (Tuesday)
From: Dick.PA
Subject: LispARs Adobe System
To: JFung.PASA, Masinter, 1100Support, LispSupport
cc: Dick.PA
Hi Folks,
The new LispARs system was included in the latest release of Klamath. The 11.0 versions of the files are available from your release directory - [Igor]<Alphamesa>11.0>LispARs.bcd and LispARs.user.
For those of you who need Sierra 10.0 versions, please retrieve the following files and recompile LispARs.mesa. LispARs.user does not need to be recompiled.
[Ibis]<Dick>LispARs>LispARs.mesa and LispARs.user
[Idun]<apilot100>adobe>private>ARFieldListDefs.bcd
[Iris|Rain]<mesa>10.0>defs>FormSW.bcd
[Iris|Rain]<mesa>10.0>defs>Heap.bcd
In order to run this AR system, first run Adobe, deactivate all the Adobe tools, then run LispARs.bcd. At this point, LispARs will appear in the menu of AR systems attached to each Adobe tool.
---Pam
*start*
00706 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 09:58 PST
From: Barrera.pasa
Subject: Lisp: ^D disabled
To: LispSupport.pa
cc: Barrera.pasa
Lisp-System-Date: 25-Feb-84 17:29:22
Machine-Type: Dolphin
My control mechanism has been disabled for a few weeks now.
For most of that time I was using the Carol full.sysout ( I can't recall the date) made just before this one. Then, typing ^D or ^C or ^B or ^E did nothing but print "^D" (or "^C" etc.). Once in a while ^C worked but I usually ended up booting out of Lisp.
I have been using this latest version (also a full.sysout) for a few days now. The only control key which does not respond is ^D.
Stephanie
*start*
00454 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 10:33 PST
From: Sybalsky.pa
Subject: Lisp: BURY doesn't take attached windows with it right
To: LispSupport.pa
cc: Sybalsky.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dandelion
If I BURY a window group, the subsidiary windows are brought to the top as though only the main window were being buried. I'd expect the whole group to go under and stay under.
*start*
01024 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 12:16 EST
From: Denber.wbst
Subject: [Ron Newman <Newman.es>: Wait till he discovers the parenthesis key]
To: Lispusers^.pa
Here's a good one.
- Michel
----- Forwarded Messages -----
Date: 12 Mar 84 14:45:08 PST (Monday)
From: Ron Newman <Newman.es>
Subject: Wait till he discovers the parenthesis key
To: AllWhimsy^.pa, Info-Cobol@MC
cc: Others.dl:;
Reply-to: Newman.es
The following letter to the editor was published in Softalk of March, 1984:
I have come into possession recently of a program called Microlisp. I understand that it has been around for some time, so maybe someone out there knows something about it. I cannot get it to do anything but print numbers I type in or print the word "nil". How do I make it do anything else? Can you give me an example of something useful that I might be able to do with it?
Dale Watson
Cincinnati, OH
----- End of Forwarded Messages -----
*start*
00798 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 11:13 PST
From: Feuerman.pasa
Subject: Lisp: TEdit and TEditMenu
To: LispSupport.pa, TEditSupport.pa
cc: Feuerman.pasa
Lisp-System-Date: 26-Jan-84 01:48:36
Machine-Type: Dolphin
I'm trying to do a re-load to make sure that I've got the latest version of TEdit and TEditMenu. I have a problem, though. Whenever I load {PHYLUM}<LISP>LIBRARY>TEDITMENU.DCOM or {PHYLUM}<LISPCORE>LIBRARY>TEDITMENU.DCOM, I fall into Raid with the message "Invalid Address #{16,4}". This occurs on the LOAD just after it prints TEDITMENUCOMS. I tried re-loading again to see if I could pin-point the problem, and it bombs sometime after it resets \TEDITDECIMALTAB (about one or two variables after that). Whats going on?
--Ken
*start*
01945 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 MAR 84 11:56 PST
From: MASINTER.PA
Subject: ARCHIVAL PROCEDURE
To: LISPSUPPORT
Date: 13 Mar 84 10:39 PST
From: Ahenderson.pa
Subject: [KMatysek.henr: Re: Archiving Trillium Releases]
To: LispCore^.PA
cc: Ahenderson.pa
Please arrange that the old versions of the LispUsers and Library packages be kept in {Phylum}...>OLD>... too.
Austin
----- Forwarded Messages -----
Date: 13 Mar 84 09:09 EST
From: KMatysek.henr
Subject: Re: Archiving Trillium Releases
In-reply-to: TBigham.es's message of Mon, 12 Mar 84 21:10 PST
To: TBigham.es
cc: Ahenderson.pa, TrilliumCore^.pa
Austin-
It sounds like what you've been archiving for Trillium is quite sufficient. Actually, Tim mentions a more difficult problem - saving back releases of lisp (and lispusers packages). Though this was a bigger concern in the Chorus-to-Fugue transition, it concerns me that there appears to be no careful distinction of versions with the lispusers and lisp>library files and not all of the releases get archived. Is this true? (Tim's mention of no Chorus files on Phylum).
In our case - since I only pull over lispusers files as we need them due to space constraints - if we need a file that goes with the previous release (since Trillium is always a bit behind the new lisp release), I can't be assured that I'll find the compatible file (the file on {phylum}<lispusers> may be updated for the new release, and the old one is gone). For example, Doug decided to try running Lafite about a month ago, but due to the Carol release I don't think he was able to find all of the files that he needed. We're now only able to run Lafite on Carol which is not compatible with Halloween. This doesn't seem like an easy thing to control, but maybe the only solution is to keep a full copy of {phylum}<lispusers> on Aztec.
Any thoughts?
-Kathy
----- End of Forwarded Messages -----
*start*
00665 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 11:17:55 PST (Tuesday)
Subject: Re: Wait till he discovers the parenthesis key
In-reply-to: Your message of 12 Mar 84 14:45:08 PST (Monday)
To: Newman
cc: LispUsers^.pa, Hamilton
From: Bruce Hamilton <Hamilton.ES>
Reply-To: Hamilton.ES
Actually, the letter implies a serious question, related to trying to communicate with other forms of intelligent life: is there an approach, to giving inputs and observing output to an unknown program, which is in some sense optimal; i.e. leads to a complete characterization of input - output pairs in the shortest possible time?
--Bruce
*start*
00483 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 13:05 PST
From: Sybalsky.pa
Subject: Re: Lisp: TEdit and TEditMenu
In-reply-to: Feuerman.pasa's message of 13 Mar 84 11:13 PST
To: Feuerman.pasa
cc: LispSupport.pa, TEditSupport.pa
Try loading it from <Lispcore>Library>, which is where the latest public TEdit is stored. Note well, you will have to load ALL the TEdit files (including IMAGEOBJ and TFBRAVO, which you might not otherwise find).
*start*
00370 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 15:12 PST
From: Sybalsky.pa
Subject: Lisp: TEdit wish item--better searching
To: LispSupport.pa
cc: Sybalsky.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dandelion
Wish-list item, priority probably, to add a regular-expression driven find command, with laurel-like syntax.
*start*
01399 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 15:17 PST
From: Sybalsky.pa
Subject: [Feuerman.PASA: Re: Lisp: TEdit and TEditMenu]
To: LispSupport.pa
This is a bug report about TEditMenu; I've not yet tried to replicate it....
----- Forwarded Messages -----
Date: Tue, 13 Mar 84 14:14 PST
From: Feuerman.PASA
Subject: Re: Lisp: TEdit and TEditMenu
In-reply-to: "Sybalsky.pa's message of 13 Mar 84 13:05 PST"
To: Sybalsky.pa
cc: Feuerman
I tried loading it from <Lispcore>Library> also, with the same results. I suspect, though, that I'm not loading in ALL of the TEdit files. IMAGEOBJ does get loaded, but I'm not sure about TFBRAVO. Could you send me a list of all of the files?
While I'm at it,
I've run into an interesting problem. I'm creating my own FMTSPEC. Basically I'm playing around with the tab stops. The tab spec I'm using is
(36 ((72 . RIGHT) (88 . LEFT))). Well, the way this guy behaves is if you're at the left margin, type a TAB, the right-hand justification works fine. Type TAB again, and somehow it thought it was still to the left of 72, because that's where the cursor ends up again. This time, however, it's doing it left-justified. To get the behavior I want, I have to double-TAB to get the cursor to 88 after the right justified typing. Any ideas? Thanks.
--Ken.
----- End of Forwarded Messages -----
*start*
01210 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 15:05 PST
From: vanMelle.pa
Subject: more for the release message
To: 1100Support.pasa
cc: LispSupport.pa
Apparently nobody took the hint and put this in the release message.
----- Begin Forwarded Messages -----
Date: 19 Jan 84 11:45 PST
From: vanMelle.pa
Subject: Re: Still more problems
In-reply-to: Jeffrey Shulman's message of 19 Jan 84 13:55:19 EST
To: SHULMAN@RUTGERS
cc: lispsupport.pa
EDITPREFIXCHAR = NIL is a feature; thanks for reminding us to note it in the release message (if you really want it, feel free to set it back. It was a nuisance to people who didn't know about its existence).
. . .
----- End Forwarded Messages -----
In more detail:
TTYIN users: the variable EDITPREFIXCHAR is now by default NIL, meaning you can't type meta commands (this to avoid confusing users who don't know about it). If you want to be able to issue editing commands to TTYIN during your typein, you should either call (TTYINMETA T) to enable bottom-blank (STOP on 1108's) as a true meta key, or set EDITPREFIXCHAR to the character code of your preferred meta prefix (it used to be 193, for top-blank).
*start*
00505 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Tue, 13 Mar 84 15:16 PST
From: Deutsch.pa
Subject: Interlisp sources
To: LispSupport
I was given to understand (indirectly) that Xerox doesn't distribute sources for some or all of Interlisp-D. Could you enlighten me on what parts of the system customers don't get the sources for? Will the situation be different for whatever arrangement you make with universities in lieu of participating in the University Grant program?
*start*
00631 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 15:18 PST
From: Stansbury.pa
Subject: [dmrussell.pa: Lisp: Bad Compiled Function]
To: LISPSUPPORT.PA
This should be tracked down before customer release.
----- Forwarded Messages -----
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 --
----- End of Forwarded Messages -----
*start*
00540 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 15:23 PST
From: vanMelle.pa
Subject: Re: AR 37: Bad FTP transfer rates
In-reply-to: lispar.Auto's message of 13 Mar 84 10:24:34 PST (Tuesday)
To: LispSupport
cc: vanMelle.pa
This is likely a problem with their implementation of BSP. Don't know that we have anything to say about it.
p.s. Your Reply-To: field needs to say LispSupport.PA, since its registry is different from yours. Otherwise, mail readers will attempt to reply to LispSupport.auto!
*start*
00339 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 15:24 PST
From: vanMelle.pa
Subject: Re: AR 45: ^D disabled
In-reply-to: lispar.Auto's message of 13 Mar 84 11:34:07 PST (Tuesday)
To: LispSupport.pa
This is probably still the tedit bug that Tedit smashes the user's interrupts with TEDIT.INTERRUPTS.
*start*
00427 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 15:25 PST
From: vanMelle.pa
Subject: TEdit: TEDIT.INTERRUPTS
To: TEditSupport
cc: vanMelle.pa
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 25-Feb-84 17:23:38
Machine-Type: Dorado
This tedit still regularly smashes my interrupts to be the same as TEDIT.INTERRUPTS. Perhaps we should go over this code together some time.
Bill
*start*
00474 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 15:33 PST
From: Sybalsky.pa
Subject: Re: TEdit: TEDIT.INTERRUPTS
In-reply-to: vanMelle.pa's message of 13 Mar 84 15:25 PST
To: vanMelle.pa
cc: TEditSupport.pa
Name a time. While we're at it, I'd like to revive the browser-window subcommittee, to define a browser window paradigm that can be carried across to other browsers.
I'm thinking particularly, of course, of an AR browser....
*start*
00280 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 17:45 PST
From: Masinter.pa
Subject: AR's, anyone
To: JFung.pasa, 1100Support
cc: LispSupport
Hi -- we've got 47 AR's in the database already. Can you find your favorite bugs already there?
*start*
00938 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 MAR 84 17:57 PST
From: JONL.PA
Subject: Re: AR 35: Where should EXPORTS.ALL live?
To: LispSupport, LispCore^
cc: JONL
In response to the message sent 13 Mar 84 10:03:32 PST (Tuesday) from LispSupport
A "current" copy of EXPORTS.ALL should live on <LispCore>Sources>, for
the benefit of those who load ABC while editing system files.
A "snapshot" copy of EXPORTS.ALL should be on <Lisp>Library> for the benefit
of those customers/users to whom we've promised internal system records etc.
It must be coordinated with the "release" sysout, and need not be "homed"
on <Lisp>Library> -- just some place where that facilitates the coordination.
I believe that the SYSEDIT lispusers package is on <Lisp>Library>, and this
is the tool needed to make effective use of the "release" version of
EXPORTS.ALL (it corrospends with <LispCore>Sources>ABC file).
*start*
00586 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 MAR 84 21:56 PST
From: MASINTER.PA
Subject: AR 35: fix MAKE-EXPORTS.ALL and ABC and SYSEDIT to make/load from <dir>LIBRARY> rather than <dir>SOURCES>.
To: LispSupport
cc: LispCore^
It would simplify the world a bit if the home for EXPORTS.ALL was uniformly on <LispCore>Library>, <LispNew>Library> and then <Lisp>Library>.
I think it may only be necessary to move ABC and MAKE-EXPORTS.ALL to <LispCore>Library>.
This is all part of the more general AR to automate and document the release process.
*start*
01019 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 18:36 PST
From: Ahenderson.pa
Subject: Lafite: MoveTo?
To: LafiteSupport.pa
cc: Ahenderson.pa
Lafite-System-Date: 3-Feb-84 16:05:50
Lisp-System-Date: 25-Feb-84 17:29:22
Machine-Type: Dorado
I often find that I can't remember whether I have moved a message to a particular file, whether I have hardcopied it, etc. This arises because each activity marks the message with its own letter, but there is only room for one letter. It would be nice to be able to say "MoveTo unless I already did" and "Hardcopy unless I already did". Hardcopy would require remembering with the message whether it had been hardcopied. MoveTo could look: filter on message length, and then compare the message (or just first part and last part). Alternatively, remembering all the "hjappenings" since a message was placed in this folder, available by buttoning the mark letter with middle button would solve the same problem. Or all of the above.
Austin
*start*
00628 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 19:54 PST
From: Halasz.pa
Subject: TEdit: TEDIT does not mark itself dirty the first time.
To: TEditSupport
cc:
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 13-Mar-84 10:21:31
Machine-Type: Dandelion
TEdit does not mark itself dirty the first time a file is invoked. That is: If you do (TEDIT) then type some characters in the TEdit window, you can Quit without saving and TEdit will not complain. This differes from the case where you do (TEDIT File) and TEdit will complain if you quit without saving any changes.
Frank
*start*
00414 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 MAR 84 21:37 PST
From: MASINTER.PA
Subject: (fixed) Interpreted FPLUS calls don't use microcode
To: LispSupport
The functions FPLUS and FTIMES, when called from the interpreter, don't go thru the microcoded opcodes but always execute the lisp macrocode.
[I fixed this a couple of days ago. It should go in as an AR, status FIXED]
*start*
00421 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 MAR 84 22:15 PST
From: MASINTER.PA
Subject: DLion microcode priorities
To: charnley
cc: LispSupport
The next set of opcodes which seem
to be relevant are:
a) more GCRECLAIMCELL
b) EVAL (for interpreter)
c) BIN
I think those are the relevant ones for current benchmarks.
A separate AR is to please automate and document benchmarks.
*start*
00660 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 MAR 84 22:48 PST
From: MASINTER.PA
Subject: Resolve TEDIT/TTYIN incompatibilities
To: LispSupport
There are a number of differences in TEDIT and TTYIN behavior which new users find quite annoying; in particular, that extending a selection means Delete in TTYIN, but not in TEDIT, that TTYIN has the meta keys, etc.
This task is to propose a design for a uniform user interface (and DEDIT too?) and then implement.
System: Text/TTYIN (plus DEDIT plus TEdit, but no way of saying that),
Impact: Moderate (it really does get in the way more than Annoying)
Attn: (?) Sybalsky
*start*
00671 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 MAR 84 23:49 PST
From: MASINTER.PA
Subject: auto login sequences for Chat/RS232
To: LISPSUPPORT
My TRS-80 100 lap computer has a feature which is probably necessary for generic auto-login sequences. You get to encode a string of cddharacters, interspersed with:
?<char> wait for char from remote site
e.g., ?_ waits until you see a _.
= wait for 2 seconds
^<char> send control-char, e.g. ^M
'<char> send <char> even if escape.
For the Vax/VMS guy, you probably have to wait for the ":" until you send the username and for the next ":" until you send the password, etc.
*start*
01304 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 08:32 PST
From: Feuerman.pasa
Subject: Lisp: DLIONFS
To: LispSupport.pa, 1100Support.pasa
cc: Feuerman.pasa
Lisp-System-Date: 25-Feb-84 17:29:22
Machine-Type: Dandelion
I'm having a problem trying to set up my DSK volume to be Interlisp-D accessible. I'm using three partitions on my 42 MB disk, Diagnostics (type = debugger) 30000 pages, DSK (type = nonPilot) 20000 pages, and Lisp (type = normal) which takes up the rest. The sysout I'm starting from is found on {Rosebowl}<lisp>carol>full.sysout. After that I load {phylum}<Lisp>Library>DLIONFS.DCOM. Next, I call (MKDIR 'DSK). This is where it goes wrong. I see "Opened local disk volume {Diagnostics}" printed in the prompt window, then I get a break window with the message "8935936 - ILLEGAL ARG." Doing a BT! reveals:
ERRORSET
BREAK1
\EVALFORM
\EVAL
\EVALFORM
\EVAL
*ENV*
\LISPERROR
\ILLEGAL.ARG
\PUTBAS.UFN
\DL.DISKSEEK
\DL.XFERDISK
\PvTransferPage
\LvGetPage
\VFMSetupIntervalCache
\DFSInit
\DFSVOLUMEP
MKDIR
etc.
Do I have my disk partitioned correctly? I'm not sure if the types are right. Please don't suggest that I use the sysout up on Phylum, because that takes generally over an hour to bring down. Any ideas?
--Ken.
*start*
00514 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Wed, 14 Mar 84 11:11 PST
From: kiewiet.PASA
Subject: Accentuate the Positive
To: LispSupport.pa
cc: Raim, kiewiet
Magnus Ljunberg of Syntelligence, in a recent phone conversation about some outstanding issues, passed along praise of Lisp as a great tool, and said the interpreter, compiler, editor, break package, etc. are SUPERB. Also, he is very glad to hear that RS232 reliability/stability is available in the upcoming Release.
*start*
00420 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 11:23:33 PST (Wednesday)
From: JFung.pasa
Subject: Re: AR's, anyone
In-reply-to: Masinter.pa's message of 13 Mar 84 17:45 PST
To: Masinter.pa
cc: JFung, 1100Support.pa, LispSupport.pa
Larry,
Thu has been designated by Marty as the Adobe administrator. I believe all 1100Support will forward AR to Thu to be submitted(at present).
*start*
01028 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 12:47 PST
From: jordan.pa
Subject: Lafite: a question
To: LafiteSupport.pa
cc: jordan.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
Is there any way to get around the length of display time for a message, or are longer messages forever doomed to take proportionally quite longer times? When I'm finished reading message X and proceed to delete it, message X+1 is automatically displayed (in general, a very nice feature). However, if in the heading of X+1 I see it's just junk mail that's 200K chars long which I definitely want to skip, I cannot do so, and am forced to *wait* until the displaying of X+1 is finished. (Unless I ^E out or something).
Laurel didn't seem to have the waiting problem. Are the (system) printing/displaying times that different? Did it only attempt to display that portion of the message that would actually appear on the screen?
curiously,
Dan
*start*
00803 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 13:18 PST
From: DMRussell.pa
Format: TEdit
Subject: Lisp: Design Rules for Lisp Subsystems
To: LispSupport.pa
cc: DMRussell.pa
Can I make a plea for the following good idea?
A design rule that should be followed by all Lisp subsystems that take any significant amount of time to run ---
Always indicate how close the subsystem is to completing the task.
This is the way the FTP "flashing checkerboard" works when you load-up Lisp for the first time.
Other systems should emulate this design. For instance:
COPYFILE (esp. when copying a sysout), LAFITE (when it's retrieving 126 messages...).... etc.
-- DMR --
��3���
TIMESROMAN� �����������A���
TIMESROMAN� ��������� ���
TIMESROMAN� ����������€�z·*start*
00689 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 14:02 PST
From: Dietterich.pa
Subject: Lafite: Browsing folders on MAXC
To: LafiteSupport.pa
cc: Dietterich.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
I'm not sure whether I'm doing things right, but when I open a folder on MAXC2 and GET MAIL, the message is slightly garbled, I guess because it contains line feeds. These display as black rectangles, and lafite doesn't parse the header fields very well. When I move such a message to a mail file residing on IVY, the line feeds remain.
This is certainly not a pressing problem....
--Tom
*start*
01173 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 14:07 PST
From: vanMelle.pa
Subject: more for the release message
To: 1100Support, LispSupport
cc: vanMelle.pa
This from a December message I sent:
- - -
The function STORAGE in Interlisp-D now takes two optional arguments for filtering the amount of information presented:
(STORAGE TYPES PAGETHRESHOLD)
If TYPES is given, STORAGE only lists statistics for those types. TYPES is an atom or list of types (either names or numbers). If PAGETHRESHOLD is given, then STORAGE only lists statistics for types that have at least PAGETHRESHOLD pages allocated to them.
- - -
I just noticed that this is completely incompatible with Interlisp-10's STORAGE, which also takes two optional args which have no meaning for Interlisp-D. The manual notes that the printout from STORAGE is implementation-dependent, so it might also note that the arguments are also implementation-dependent. And to the above blurb might be added
[Interlisp-10 users: note that these optional arguments are implementation-dependent and different from the optional arguments to Interlisp-10's STORAGE].
Bill
*start*
00429 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from RUTGERS.ARPA by PARC-MAXC.ARPA; 14 MAR 84 14:38:50 PST
Date: 14 Mar 84 17:38:31 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: ATTACHEDWINDOW
To: lispsupport.pa
cc: SHULMAN@RUTGERS.ARPA
In the Carol release message I noticed the new user package
ATTACHEDWINDOW. Will it run in Fugue? Can I get a copy now?
Jeff
-------
*start*
00967 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 MAR 84 23:01 PST
From: MASINTER.PA
Subject: AR field list, etc.
To: roach, lispsupport
Kelly, I like most of your suggestions.
I think you can personalize how YOU see the AR's by editing the file LispAR.User, deactivating and reactivating Adobe. (If not, you might have to re-load Adobe. I don't quite understand how it works, but rebooting usually does it.)
Edit-by and Edit-date are filled in automatically, so they could stay at the bottom.
Also, Michael, I see no reason why Kelly shouldn't enter AR's directly ... why not lets try it and see how it works? That is part of what we want to learn -- does it work to have a lot of people working on the AR system?
The only rule that I think applies is:
NEVER DELETE ANY TEXT
ALWAYS MARK, IN DISPOSITION, WHAT EDITS YOU MADE.
(you can see in SDD people leave notations, e.g. 8Mar84 Pam, Status_Closed
).
How 'bout it Michael?
*start*
00325 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 MAR 84 09:35 PST
From: ROACH.PA
Subject: Re: Proposed ADOBE "Difficulty:" field
To: LISPSUPPORT
cc: ROACH
I did notice later that Adobe Query had a difficulty field.
I don't think there was a difficulty field in Adobe Edit.
Kelly
*start*
01119 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 17:42 PST
From: Masinter.pa
Subject: AREDIT: dumb but marginally useful AR viewer from Lisp
To: LispFriends^, 1100Support.pasa
reply-to: LispSupport
As many of you know, we are going to try to keep Interlisp-D bug reports, request for features, etc. in a database. We're initially using the "Adobe" system which was developed by SDD to keep track of bug reports for Mesa/Star/etc.
When you send mail to LispSupport or 1100Support, and it reports a bug, you will get back a message with an AR number. You can then find out about the status, etc. of bugs by looking at the AR "database".
The AREDIT package is a very simple implementation of an AR viewer from inside Lisp.
LOAD({Phylum}<LispUsers>AREDIT.DCOM)
To see AR#n, call AR.SHOW(n), e.g., AR.SHOW(23).
The first time, it will prompt you for a window -- the best size to give it is one about half the width of the screen and at least 1/2 the height of the screen, too.)
This implementation does not scroll, nor reshape, etc. (Like I said, dumb, but hopefully useful.)
*start*
00378 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 MAR 84 09:51 PST
From: ROACH.PA
Subject: Re: AREDIT: dumb but marginally useful AR viewer from Lisp
To: LispSupport
cc: ROACH
In response to your message sent 13 Mar 84 17:42 PST
In hopeful anticipation of future expansion, would it not make
sense to call this package ADOBE?
Kelly
*start*
00499 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 14:44 PST
From: Stansbury.pa
Subject: Lisp: Lispusers>aredit
To: LispSupport.pa
cc: Masinter.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dolphin
Calling ar.show(n) puts up a window which is neither wide nor tall enough to show an average ar. There are no scrollbars on the window and reshaping does not redisplay the ar to fit the larger sized window -- you have to call ar.show again.
-- Tayloe.
*start*
00620 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 MAR 84 23:09 PST
From: MASINTER.PA
Subject: Sysout from floppies for Carol.1/Fugue.6
To: Nuyens, Hausladen, LispSupport, LispCore^, 1100Support
cc: Carol Release Installation Utility
I've heard a number of conflicting stories about the current status of loading the latest release from floppies.
There was some suspicion that the problem came from inconsistent Installation Utilities.
(a) does anybody have the scoop on this? What is the status, did anybody make an installation utility, what happened to MakeLispFloppies.DOC etc?
*start*
01833 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 11:41:07 PST (Wednesday)
From: JFung.pasa
Subject: Re: Sysout from floppies for Carol.1/Fugue.6
In-reply-to: Your message of 13 MAR 84 23:38 PST
To: MASINTER.PA, halvorsen.pa
cc: Nuyens.pa, Hausladen.pa, LispSupport.pa, 1100Support, JFung
I would appreciate hearing any problems on this one.
I am confused by a message from halvorsen.pa re: FAILING INSTALLATIONUTILITY
----------------------------------------------------------------
Date: 28 Feb 84 14:51 PST
From: halvorsen.pa
Subject: Re: Lisp: FAILING INSTALLATIONUTILITY
In-reply-to: JFung.PASA's message of 28 Feb 84 09:00:39 PST (Tuesday)
To: JFung.PASA
cc: Halvorsen.pa, LispSupport.pa, Stansbury.pa
I am NOT referring to the InstallLispTool of 29-Nov-83, but rather to the current InstallLispTool (26-Jan-84). The problem is that there are 3500 taken up by diagnostics, defaultly 1000 pages is assigned to DSK, this does not leave enough room on the disk to fetch full.sysout. I had to reduce the allocation to DSK reformatting with Othello.
----------------------------------------------------------------
This morning I tried to install on 10Mb using "carol" released installation floppy. I was not able to have any problems.
The volume configurations are
Diagnostics: 3500 pages
Dsk: 1000 pages
Lisp 11688 pages
This gives a default of 9688 pages for vMem.
The Full.sysout is about 5900 pages, and Lisp.Sysout is about 4600 pages.
As I recall when John Vittal and Tayloe S. went to London, they are using the 10Mb machine and with same Installation Floppy. I was not able to locate John (He might be in Boston again), maybe Tayloe can clarify this for me.
I must be missing something again from halvorsen.pa message.
Confused one,
/Jerry
*start*
00553 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Wed, 14 Mar 84 12:47 PST
From: Raim.pasa
Subject: Re: Sysout from floppies for Carol.1/Fugue.6
In-reply-to: "JFung's message of 14 Mar 84 11:41:07 PST (Wednesday)"
To: JFung
cc: MASINTER.PA, halvorsen.pa, Nuyens.pa, Hausladen.pa, LispSupport.pa, 1100Support
Jerry,
These problems seem to be happening because of incompatible sysouts and initial microcode. When you and Judy stabilize the new Installation Utility for Fugue.6, we will make sure PARC is updated.
--Marty
*start*
01070 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 13:25:03 PST (Wednesday)
From: JFung.pasa
Subject: New Diagnostics volume size?
To: 1100Support, LispSupport.pa
cc: Dering, Martin, Masinter.pa, Stansbury.pa, JFung
It turns out the current 3500 pages of Diag. volume is not sufficient to run Adobe. (you may run one tool at a time, but activate multiple tools the machine will crash, I suspect no more disk pages).
In stead of increasing its size say by another 200 pages (I think 200 is sufficient), it is argued that we should not take the disk space away from customes.
Unless we change promethus.script, it will be each Adobe user's responsibility to make sure his Diagnostic volume is large enough to run Adobe.
I personally like to see Diag. volume size be increased from Promethus.script. Most machines here are formatted via Installation Utility floppy (it is easier than Othello, and a standard procedure), and I would like to see walking to one of them and be able to use Adobe.
Any comments from anyone?
/Jerry
*start*
00491 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Wed, 14 Mar 84 13:53 PST
From: Raim.pasa
Subject: Re: New Diagnostics volume size?
In-reply-to: "JFung's message of 14 Mar 84 13:25:03 PST (Wednesday)"
To: JFung
cc: 1100Support, LispSupport.pa, Dering, Martin, Masinter.pa, Stansbury.pa
Jerry,
We cannot afford to take disk space away from the customers. I would rather see an inhouse Installation Utility for Adobe users than penalize our customers.
--marty
*start*
00436 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 14:15 PST
From: Sybalsky.pa
Subject: New Package: COPYFILES
To: LispFriends^.pa
cc: Sybalsky.pa
There is a new package, residing on {Phylum}<Lispcore>Library> for the moment, called COPYFILES. It is a collection of functions that make it easier to copy groups of files around in controlled ways.
Please have a look, and forward any suggestions.
*start*
00294 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 22:08 PST
From: nuyens.pa
Subject: Lisp: can't shrink a closed window
To: LispSupport.pa
cc: nuyens.pa
Lisp-System-Date: 13-Mar-84 10:21:31
Machine-Type: Dorado
try (shrinkw (createw NIL NIL NIL T))
Greg
*start*
00317 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 MAR 84 21:30 PST
From: MASINTER.PA
Subject: Please REMOVE BLisp.PA from TEditSupport.PA
To: owners-TEditSupport
Actually, maybe we could get rid LafiteReport and TEditReport for a while? (Just the forms from the default Lafite menu?)
*start*
00647 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 07:23 PST
From: Masinter.pa
Subject: Lisp: TEDIT startup needs monitor lock
To: LispSupport.pa
cc: Masinter.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dandelion
I did TEDIT({Phylum}<LispCore>LISPARS.MESA)
and then immediately TEDIT({Phylum}<LispCore>LIspARS.USER)
I layed out one window, and then another, but the first window came up with the 2nd window's title, and then the second window didn't come up, but the TEDIT processes are there anyway.
I think that somehow the datastructures of the two TEDITs are getting confused with each other.
*start*
00507 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 12:40 PST
From: Kaplan.pa
Subject: Re: Lisp: Missing "-" on LispPrint: Terminal font
In-reply-to: desRivieres.pa's message of 10 Mar 84 15:40 PST
To: desRivieres.pa
cc: LispSupport.pa, 3LispSupport^.pa
We believe that the missing hyphen problem has been fixed, for next loadup. I think that Jean Gascon is now the raven maven. Joan Phillips at XSIS is the person who will install the printer software at CSLI.
--Ron
*start*
00629 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Mar 84 17:36 PST
From: Masinter.pa
Subject: Re: Terminal Font
In-reply-to: Phillips.PASA's message of 13 Mar 84 15:04:05 PST (Tuesday)
To: Phillips.PASA
cc: Raim.pasa, 1100Support, LispSupport, Martin.PASA, Masinter.pa, Agadoni.PASA
There is some belief that the missing "-" is a problem with the Lisp Software rather than the 8044. If so, we can resolve it more simply.
Can one of you test whether you can generate and print a "-" or "$" character from the Star workstation?
Are you running the latest (carol.1/fugue.6) release of Interlisp-D?
*start*
00288 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 14:45 PST
From: Sybalsky.pa
Subject: Lisp: AR 50
To: LispSupport.pa
cc: Sybalsky.pa
Lisp-System-Date: 13-Mar-84 10:21:31
Machine-Type: Dorado
Was fixed by moving the latest TEdit onto <Lisp>Library>.
*start*
00366 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 18:39 PST
From: masinter.pa
Subject: AR # 52, can't load Browser
To: LispSupport
cc: Stansbury, DMRussell
I can load in BROWSER just fine. Are you sure this is a problem?
(Michael, I think BROWSER fits under Graphics/Library rather than Othersoftware/Nil), please re-classify.
*start*
00300 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 14:48 PST
From: Sybalsky.pa
Subject: Re: TEdit: TEDIT does not mark itself dirty the first time.
In-reply-to: Halasz.pa's message of 13 Mar 84 19:54 PST
To: Halasz.pa
cc: TEditSupport.pa
Fixed in the next TEdit.
*start*
00335 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 18:41 PST
From: masinter.pa
Subject: AR # 55, can quit from Dirty Tedit
To: LispSupport
cc: Sybalsky
Should TEditSupport get supplanted with LispSupport? In any case, AR#55 should get marked as "Fixed", with Disposition Sybalsky's message, right?
*start*
00259 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 19:22 PST
From: masinter.pa
Subject: AR#61: System WindowGraphics
To: LispSUpport
Just suggesting categories. We want to review the categories and se ehow it is working.
*start*
00567 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 19:26 PST
From: masinter.pa
Subject: AR#62
To: LispSupport
This is a BUG not a WISH. Maybe Tom wishes it were fixed, but it is really a bug.
The "black boxes" are line-feeds. This turns into two other ARs: LineFeed should have separate graphic in Tedit and fonts (e.g., a tiny <lf>).
Second AR, TEdit should allow one to edit files which have EOL convention CR-LF as well as CR.
If this isn't the case, then Lafite should open its mail folder in Binary, rather than Text.
*start*
00191 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 19:27 PST
From: masinter.pa
Subject: AR#63 should also be Documentation/Release notes
To: LispSupport
*start*
00320 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 19:29 PST
From: masinter.pa
Subject: AR#64, AREDIT viewer for Lisp ARs
To: LispSupport
This confuses me. It is just the release message for AREDIT. What is the action Request?
I guess I shouldn't have cc'd LispSupport -- sorry.
*start*
00396 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 19:24 PST
From: vanMelle.pa
Subject: documentation for GCHAX
To: LispSupport
cc: vanMelle.pa
The long-promised document is now stored as <Lisp>Library>GCHAX.tedit & .press. This supersedes GCHAX.TTY, which you may delete at your leisure (the file is delete-protected, so I assume I shouldn't do it).
Bill
*start*
00418 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 MAR 84 15:35 PST
From: ROACH.PA
Subject: Re: New Package: COPYFILES
To: Sybalsky
cc: ROACH, LISPSUPPORT
In response to your message sent 14 Mar 84 14:15 PST
This package ought to be unnecessary. There isn't any special
reason why FILEIO should not understand
(COPYFILE '<DIR1>* '<DIR2>*)
and other related forms.
Kelly
*start*
00286 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 15:57 PST
From: Stansbury.pa
Subject: Disappearing dsk files
To: Lispsupport, Sannella, Raim.pasa, Dering.pasa
Coredevice dsk files do survive logout in the lispnew>current>full.sysout.
-- Tayloe.
*start*
00578 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 15:07:11 PST (Wednesday)
From: Sannella.PA
Subject: Re: AREDIT: dumb but marginally useful AR viewer from Lisp
In-reply-to: ROACH's message of 14 MAR 84 09:51 PST
To: ROACH
cc: LispSupport, Masinter
Re: renaming AREDIT -> ADOBE
For the time being, we will try to make the lisp-based tools compatible with Adobe. Eventually, we will probably break away. I see no need to commit ourselves to making lisp-based tools that are compatible with Adobe, which the name "Adobe.dcom" would imply.
*start*
00477 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 16:05 PST
From: Sybalsky.pa
Subject: Re: DLIONFS
In-reply-to: Sannella.PA's message of 14 Mar 84 14:40:52 PST (Wednesday)
To: LispSupport.pa, Feuerman.pasa
cc: Sybalsky.pa
My impression is that your DSK volume should be of type normal. DLIONFS is really supposed to provide you with a pilot-compatible volume, that's my reasoning. Not that I really think it IS pilot compatible, but....
*start*
00416 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 16:03 PST
From: Nuyens.pa
Subject: Lisp: NOW is being bound!
To: LispSupport.pa
cc: Nuyens.pa
Lisp-System-Date: 13-Mar-84 10:21:31
Machine-Type: Dolphin
I just got screwed by an undocumented system-updated atom called NOW. It seems to be a synonym for (IDATE). Please limit system atom names to improbable user choices.
Greg
*start*
00462 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 16:03 PST
From: Kaplan.pa
Subject: Re: Lafite: Browsing folders on MAXC
In-reply-to: Dietterich.pa's message of 14 Mar 84 14:02 PST
To: Dietterich.pa
cc: LafiteSupport.pa
This is a known problem having to do with the fact that in this release not all subsystems take proper account of the new end-of-line stream property. This will be fixed in subsequent releases.
--Ron
*start*
00498 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 16:07 PST
From: Kaplan.pa
Subject: Lisp: Formatted messages from LISPAR.AUTO
To: LispSupport.pa
cc: Kaplan.pa
Lisp-System-Date: 13-Mar-84 13:05:55
Machine-Type: Dorado
The message on AR 61 included a copy of the original message by DMRussell. This message had garbled Tedit formatting information at the end.
It may be a bug in the AR set up that it doesn't properly pass thru formatting information.
--Ron
*start*
00574 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 16:16 PST
From: Nuyens.pa
Subject: Lisp: more on mystery vars
To: LispSupport.pa
cc: Nuyens.pa
Lisp-System-Date: 13-Mar-84 10:21:31
Machine-Type: Dolphin
THEN also seems to be magic. I used masterscope to ensure that my application (which does add a process) is not binding them. I checked another lisp users world, these vars are not bound. I looked at calls of CROCK.PROCESS and \TIMER.PROCESS. Aside from these I don't see where these are being bound in my world. Ideas?
Greg
*start*
00550 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@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*
00512 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 16:44 PST
From: Stansbury.pa
Subject: Lisp: changebackgroundborder
To: LispSupport.pa
Lisp-System-Date: 14-Mar-84 10:16:58
Machine-Type: Dandelion
changebackgroundborder does not seem to survive logout: do
(changebackgroundborder blackshade)
(logout)
... Just before going away the backgroundborder changes to backgroundshade (grey) and when you restart the image, the backgroundborder stays backgroundshade.
-- Tayloe.
*start*
00630 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 17:26 PST
From: Sannella.pa
Subject: DLionfs package withdrawn
To: LispFriends^.pa
cc: LispCore^.pa, Sannella.pa
Because of reliability problems, the DLionFS package is being withdrawn from the group of Interlisp Library packages. All copies have been archived and deleted from {phylum}<Lisp>Library>. If anyone is depending on these files, please contact Sannella.pa.
It is currently a priority item in the Interlisp support group to produce a reliable 1108 local file system. As soon as we have one that is usable, it will be released.
*start*
00686 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 17:10 PST
From: masinter.pa
Subject: Re: New Diagnostics volume size?
In-reply-to: JFung.pasa's message of 14 Mar 84 13:25:03 PST (Wednesday)
To: JFung.pasa
cc: 1100Support.pasa, LispSupport.pa, Dering.pasa, Martin.pasa, Masinter.pa, Stansbury.pa
Did you know that you could make Othello "command" files, including one sthat partition the disk? Look at [phylum]<Lisp>Current>*.othello. There are several that are used for partitioning the disk. If you would like one that made the Tajo/Diagnostics volume bigger, why don't you discuss it with their authors or else make one tailored for your use.
*start*
00706 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 17:51 PST
From: masinter.pa
Subject: Re: New Diagnostics volume size?
In-reply-to: JFung.pasa's message of 14 Mar 84 13:25:03 PST (Wednesday)
To: JFung.pasa
cc: 1100Support.pasa, LispSupport.pa, Dering.pasa, Martin.pasa, Masinter.pa, Stansbury.pa
Another possibility, too: you CAN use Tajo to manipulate files on other volumes. Say
Open Lisp/w
Create <Lisp>
Push <Lisp>
This will basically "connect" you to a Tajo directory on the Lisp volume. Of course, the files will go away if you erase the volume, but if you are temporarily stuck with a machine without enough space to run Adobe, you can get more that way.
*start*
00700 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 17:53 PST
From: masinter.pa
Subject: Re: Sysout from floppies for Carol.1/Fugue.6
In-reply-to: Raim.pasa's message of Wed, 14 Mar 84 12:47 PST
To: Raim.pasa
cc: JFung.pasa, MASINTER.PA, halvorsen.pa, Nuyens.pa, Hausladen.pa, LispSupport.pa, 1100Support.pasa
Dear folks:
I would like to see the procedure by which the original installation utility is made "released".
It used to be that the standard procedure was documented in MakeLispFloppies.DOC. That document is now out of date, and needs a replacement.
It is not sufficient to make one and release it; the construction procedure needs releasing too.
*start*
00339 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 19:32 PST
From: masinter.pa
Subject: AR#65
To: LISPSUPPORT
I think you have to sort this one out too; I can't tell what the BUG is here. Can you? I'd change it to Declined, or extract out something, e.g.
Fix MAKELISPFLOPPIES.DOC
and attn: JFung.pasa
*start*
00231 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 19:33 PST
From: masinter.pa
Subject: AR#66
To: LISPSUPPORT
cc: masinter.pa
Declined; not really an Action Request. It was a design proposal.
*start*
00323 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 19:34 PST
From: masinter.pa
Subject: AR#67
To: LISPSUPPORT
cc: masinter.pa
Michael, you were clearly hurrying here. This is not an Action Request at all. Mark it Declined. You can put this message in the Disposition field if you want.
*start*
00322 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 19:39 PST
From: masinter.pa
Subject: AR # 48
To: LispSupport
You should assign System/Subsystem and (hopefully Attn) to as many AR's if you can. This one is in "Support/Archive procedures."
It also turns into an action item for you.
*start*
00363 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 19:38 PST
From: masinter.pa
Subject: AR#49
To: LispSUpport, Sybalsky
I'd change the "Subject:" to say "Want TEDIT regular-expression find command"
rather than "better TEdit searching".
For the AR rule book (which Michael will draft, yes?):
Think of newspaper headlines.
*start*
00574 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 19:59 PST
From: desRivieres.pa
Subject: TEdit: not always closing its files
To: TEditSupport
cc: desRivieres.pa
TEdit-System-Date: 1-Mar-84 13:54:34
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
I just did a PUT on a file that I had edited extensively; Tedit wrote an empty file (version 54) (I recall reporting this probelm already). Then I did a GET on the version 53, followed by a PUT, thereby creating version 55. However, Tedit forgot to close version 54.
---Jim
*start*
00415 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 20:14 PST
From: masinter.pa
Subject: SETDIRECTORIES on [phylum]<LispCore>Sources>ABC has wrong entries
To: LispSupport
It has <LispCore>LispUsers> (what is that?), doesn't have <LispNew>Library>.
Also, the resetting of DIRECTORIES in the COMS of the file is bogus because DIRECTORIES is reset by the call to SETDIRECTORIES.
*start*
00771 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 21:42 PST
From: Kaplan.pa
Subject: TEdit: ^D getting disabled
To: TEditSupport
cc: Kaplan.pa
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 13-Mar-84 10:21:31
Machine-Type: Dorado
I have a simple function that sets up a Tedit process on a window, and then moves the TTY.PROCESS back to what it was before.
Whenever I run this function, I end up with ^D being disabled. Perhaps I am doing something wrong.
The function is TEDITBUG on {Phylum}<LFG>PARSER>TEDITBUG. It will run in a vanilla FULL. For convenience, here is its definition:
[LAMBDA NIL
(TEDIT (OPENTEXTSTREAM)
(CREATEW NIL "Lexicon Window"))
(TTY.PROCESS (THIS.PROCESS]
What's going on?
--Ron
*start*
00853 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 22:57 PST
From: Kaplan.pa
Subject: Lisp: STATS hasharray bug fixed
To: LispSupport.pa
cc: Kaplan.pa
Lisp-System-Date: 13-Mar-84 10:21:31
Machine-Type: Dorado
I fixed the following bug:
Date: 8 Mar 84 14:38 PST
From: vanMelle.pa
Subject: Lisp: STATS broken
To: Kaplan, LispSupport.pa
cc: vanMelle.pa
Lisp-System-Date: 25-Feb-84 17:23:38
Machine-Type: Dorado
In the analysis phase, you get a HASH TABLE FULL error inside of PUTHASH. Arg to PUTHASH is a HARRAYP which has 80 elements in it. It appears the stats code was modified to use (HARRAY &) instead of (LIST (HARRAY &)) for its hash arrays. But wasn't the growing harray stuff withdrawn? If yes, why wasn't the change to stats withdrawn? If no, why isn't this hash array automatically growing?
Bill
*start*
01513 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 23:46 PST
From: Kaplan.pa
Subject: Re: AR 41: READ, OPENSTRINGSTREAM, & RDTBL
To: LISPSUPPORT.PA,
Cc: DesRivieres, Lispcore^
I looked the problem, originally reported by Kelly and manifested again, I believe, by AR41 from DesRivieres, about readmacros on string-streams getting passed the string itself, which is the fullname, so that the readmacro re-reads things that were previously read. The problem was that there was no link from the string to that particular stream: the next read from the string, inside the readmacro function, would create an entirely new stream and read it from the beginning.
The idea that we discussed, of having READ always pass the stream instead of the fullname, seemed problematical, since there were in fact a number of machine-independent readmacro functions in the system that specifically test the filename (usually to see if it was (EQ -- T).
So I postponed making the giant leap, and instead took the smaller step of not having streams produced by OPENSTRINGSTREAM have the string as their name. Not having an explicit name, their FULLNAME is the stream datum itself.
String streams that are produced by implicitly by simply reading from the string will have the string name, so that they will continue to show up on openfiles, and thus also be retrievable again by subsequent IO operations.
Jim: You might try your string reading macros in the next <lispcore> loadup.
--Ron
*start*
00430 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 01:05 PST
From: desRivieres.pa
Subject: Re: AR 41: READ, OPENSTRINGSTREAM, & RDTBL
In-reply-to: Kaplan.pa's message of 14 Mar 84 23:46 PST
To: Kaplan.pa
cc: LISPSUPPORT.PA, DesRivieres.pa, Lispcore^.pa
Good stuff! The changes you made to \GETSTREAM and OPENSTRINGSTREAM have completely cured the problems that I reported in AR 41.
---Jim
*start*
00376 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 MAR 84 00:25 PST
From: ROACH.PA
Subject: LANDPRESS & DEFAULTPRINTINGHOST = LISPPRINT:
To: LISPSUPPORT
cc: ROACH
Attn: Halasz
I try (LANDPRESS '{PHYLUM}<ROACH>DLION>LISPARS.REPORT) while
DEFAULTPRINTINGHOST = LISPPRINT:. I get "PRINTINGHOST - UNDEFINED
FUNCTION break".
Kelly
*start*
00193 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 00:26 PST
From: masinter.pa
Subject: junk on <LispCore>Sources>
To: Nuyens
cc: LispSupport
FINGER.DCOM
*start*
00335 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 00:27 PST
From: masinter.pa
Subject: FILESETS doesn't belong on <Lisp>Library>, dunno how it got there
To: LispSupport
cc: LispCore^
It is not anything that we release to anybody. Suggest LispSupport (as owner of <Lisp>) delete this bogus copy.
*start*
00283 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 00:31 PST
From: masinter.pa
Subject: AR#95, probably under TEDIT
To: LispSupport, Roach
cc: masinter.pa
Also, subject should probably read "Interpress output from TEdit misaligned, wrong fonts?"
*start*
00287 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 00:38 PST
From: masinter.pa
Subject: AR#83
To: LispSupport
cc: Roach
Impact is not FATAL (c'mon, Kelly). Moderate, perhaps.
A more complete description about how you get clobbered would help here.
*start*
00460 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 00:57 PST
From: masinter.pa
Subject: Bad Interpress file generated by OPENIPSTREAM/DSPXetc.
To: LispSupport
cc: Kaplan
Starting with {Phylum}<LispUsers>AREDIT.DCOM, I did
(SETQ STR (OPENIPSTREAM '{CORE}TEST.IP))
(AR.SHOW 39 STR)
(CLOSEF STR)
(EMPRESS STR)
The printer compailed Parse Failure: no such command.
I copied {CORE}TEST.IP to {Phylum}<Interpress>BUG95.IP.
*start*
00577 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 01:13 PST
From: masinter.pa
Subject: Re: Sysout from floppies for Carol.1/Fugue.6
In-reply-to: JFung.pasa's message of 14 Mar 84 11:41:07 PST (Wednesday)
To: JFung.pasa
cc: MASINTER.PA, halvorsen.pa, Nuyens.pa, Hausladen.pa, LispSupport.pa, 1100Support.pasa
I believe that Kris meant to say that the problem was with the "Installation Utility" floppy, which has incorrect values in the Prometheus.script. As such, it is Tayloe Stansbury who set up the values on the floppy that Kris has.
*start*
00449 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 02:38 PST
From: desRivieres.pa
Subject: TEdit: HARDCOPY whiteout
To: TEditSupport
cc: desRivieres.pa
TEdit-System-Date: 1-Mar-84 13:54:34
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
I HARDCOPYed a file to Lispprint: and received an 11 sheet listing, all pages blank except for the banner. I repeated the command and got the same result.
---Jim
*start*
00567 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 08:50 PST
From: Kaplan.pa
Subject: Re: Bad Interpress file generated by OPENIPSTREAM/DSPXetc.
In-reply-to: masinter.pa's message of 15 Mar 84 00:57 PST
To: masinter.pa
cc: LispSupport.pa, Kaplan.pa
Your message didn't say what loadup you were running in or where to find AR.SHOW, but I found it on AREDIT. Loading that and trying (AR.SHOW 39) to the display, I got a non-numeric arg NIL in AR.SHOWFIELD.
Please let me know when this is fixed so that I can try it again.
--Ron
*start*
00520 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 08:54 PST
From: Kaplan.pa
Subject: Re: Bad Interpress file generated by OPENIPSTREAM/DSPXetc.
In-reply-to: masinter.pa's message of 15 Mar 84 00:57 PST
To: masinter.pa
cc: LispSupport.pa, Kaplan.pa
Looking at the code for AR.SHOW1, I see that it calls CLEARW on the TO stream. This gives an illegal-arg error on an IP stream--currently there is no coercion between IP streams and windows.
How did you run this code at all?
--Ron
*start*
00462 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 08:59 PST
From: Dym.pa
Subject: Lafite: Suggestion
To: LafiteSupport.pa
cc: Dym.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dolphin
It is very hard to make the cursor point to a particular message without conflicting with the message notation feature on one side, and the scrolling on the other. Can this be changed?
--Clive
*start*
00660 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 MAR 84 09:20 PST
From: MASINTER.PA
Subject: Interpress
To: KAPLAN, sybalsky
cc: LispSupport
I was running in the loadup I made last night with the latest interpress when (a) I got the error I reported to Ron (a Parse failure from the result of calling AR.SHOW in a previous version of AREDIT, the result of which I stored on [phylum]<LispCore>Interpress>.)
In addition, when I tried to OUTFILE({LPT}LISPPRINT:) and then printed a lot of information, I got many blank pages. The cover page had no leader.
This AR is Subject: "Printing on {LPT}nshost gives all blank pages"
*start*
00912 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 MAR 84 09:31 PST
From: MASINTER.PA
Subject: AR#98, DLion local file system
To: le.pasa
cc: lispsupport
Pretty good. You should fill in the System/Subsystem categories or at least try.
In this case, the problem type is not Design - Impl, but Bug. A "Bug" means: Doesn't work as advertised. A "Design - UI" is that it works, but the interface to it is crummy awkward, etc. A "Design - Impl" is that the internal construction of the facility is faulty.
That is often hard to call.
Also, you should try to look over the previously reported AR's, maybe by making yourself a report that lists all 98 ARs so far.... I think the DLion FS problem was previously listed, in which case, it would be useful to merge.
(I don't know how SDD deals with the problem of duplicate ARs or if they do at all. It might be useful to find out.)
*start*
00641 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 MAR 84 09:37 PST
From: MASINTER.PA
Subject: AR#97, request for TCP/IP
To: Le.pasa
cc: LispSupport
I'm not entirely sure how to handle this kind of query. We almost need a separate kind of AR status, i.e., Unanswered Question.
In this case, the guy really wants 2060 support. We should forward him to the person in 1100Support who knows about connection to networks (and I am not sure, but I think that person is Phil Young? Note that Stanford is developing 10MHz Ethernet support for 2060.
(I should have cc'd PYoung on this message; will you forward?)
*start*
00473 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 12:33:03 PST (Thursday)
From: le.pasa
Subject: Re: AR#97, request for TCP/IP
In-reply-to: MASINTER.PA's message of 15 MAR 84 09:37 PST
To: MASINTER.PA
cc: Le.pasa, LispSupport.PA
Sure Larry.
About determining System/Subsystem, I thought that I am not supposed to do this. Perhalps, I misinterpreted the system. Thank for pointing out my errors. Your comments are appreciated.
Thu
*start*
01018 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 MAR 84 09:47 PST
From: MASINTER.PA
Subject: AR for Implementors Manual
To: LispSupport
cc: Kaplan, LispCore^
Section on making new file devices, How To.
The FULLNAME field must satisfy the invariant that if you take a stream, get its FULLNAME, and pass that name back to an I/O function, it will implicity operate on the original STREAM.
Thus, for files on DSK or a file server, FULLNAME should be a unique ID that describes the exact identifier of the file. For devices which are external to the machine and which might change state over a LOGOUT or SYSOUT, it is important that FULLNAME actually be an identifier of the stream, so that the across-logout across-sysout feature can attempt to re-find the file.
For some devices, e.g., the STRING device, there is no good handle of that form, and (FULLNAME STREAM) should return STREAM. This is achieved by making the FULLNAME field of the stream be NIL (to avoid circularities.)
*start*
00389 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 10:18 PST
From: Sybalsky.pa
Subject: Re: TEdit: HARDCOPY whiteout
In-reply-to: desRivieres.pa's message of 15 Mar 84 02:38 PST
To: desRivieres.pa
cc: TEditSupport.pa
This is a problem with either INTERPRESS or the printer, not TEdit. We're checking further, but are beginning to suspect the printer.
*start*
00408 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from RUTGERS.ARPA by PARC-MAXC.ARPA; 15 MAR 84 10:26:16 PST
Date: 15 Mar 84 13:25:30 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: Manual error
To: lispsupport.pa
cc: SHULMAN@RUTGERS.ARPA
Under LISTPUT1 (p 2.26) the examples strictly for LISTPUT. There should be
an example for LISTPUT1 also.
Jeff
-------
*start*
01782 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 15 MAR 84 10:32:31 PST
Return-path: <@SUMEX-AIM.ARPA:Brand Hal@LLL-MFE.ARPA>
Redistributed: Xerox1100UsersGroup^.PA
Received: from LLL-MFE by SUMEX-AIM.ARPA with TCP; Thu 15 Mar 84 09:48:23-PST
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*
00481 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 MAR 84 10:32 PST
From: MASINTER.PA
Subject: Want faster DIR and FILEBROWSER
To: LispSupport
The performance of DIR and FILEBROWSER is unacceptable for remote files. This is because they reopen the or relookup the file for every property they display.
Performance for all devices (DSK, Leaf/PUPFTP, NSFiling) need tuning.
(subSystem): general file operations
Impact: Moderate
Type: Performance
*start*
00660 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 MAR 84 10:44 PST
From: MASINTER.PA
Subject: AR for documentation
To: lispSupport
Interlisp_D documentation needs a description of its character set and the conversion to the Xerox NS character set:
Here is a response to a query about fonts that is a good beginning:
I think the only way this can work is if you DO set the system/subsystem. You will get it wrong quite a bit of the time, but over the course of a couple of months, can probably get reasonably good at it, as we give you more feedback about how things should be categorized and document the categories better.
*start*
00794 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 10:36:07 PST
From: Maxwell.pa
Subject: A Novice's View of Lisp
To: LispFriends^.pa
Reply-to: Maxwell.pa
There is a very brief paper on [Ivy]<Maxwell>Lisp>LispNotes.tioga & .press which talks about my experiences as a new user of Lisp. Here is the abstract:
Abstract: About a month ago I started to learn Interlisp for the first time, having had almost no prior experience programming in Lisp. Larry Masinter thought that this would be a wonderful opportunity to capture the initial impressions of a new Lisp user, so he asked that I keep a diary of my thoughts as I used Lisp day to day. This paper gives some of my thoughts about Lisp as a novice user based on the notes in my diary.
Enjoy,
John.
*start*
02271 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 10:43 PST
From: Sannella.pa
Subject: [Stansbury.pa: Lisp: NS Filing: Raised Priority]
To: LispSupport
----- Forwarded Messages -----
Date: 16 Feb 84 19:25 PST
From: Stansbury.pa
Subject: Lisp: NS Filing: Raised Priority
To: LispSupport.pa, Cooper, Sheil
Lisp-System-Date: 14-Feb-84 13:57:51
Machine-Type: Dolphin
There seems to be a general concensus here at PARC that the Lisp-NSFiling problems are limited to lack of random access. Au contraire, there are plenty of Lisp problems lurking there. Perhaps we have been lulled by a lack of fresh reports on the problem.
Syntelligence have had so many problems NSFiling that they have basically quit using it, and are relying on floppy and flaky {dsk} to store their stuff. They have however been able to sysout to their fileserver successfully with their pre-Carol lisp (thanks largely to Bill's work on this problem). Makefile etc. are apparently still a disaster.
NSFiling was a considerable nuisance in the lispcourse in Watford. File interactions usually (though by no means always) completed successfully. But they frequently seemed to spawn 3-5 filing processes each, n-1 of which would get confused and periodically promptprint "Filing#i not responding" ad infinitum. Why it takes more than one process to accomplish a makefile I don't know. It seems as if all the spurious processes were waiting for the fileserver to tell them something, but were not reminding the fileserver they were waiting to be served. And sometimes file interactions broke, usually when trying to close a file. People at the course who had NS fileservers at home said that they had the same problems on their own installations.
It seems that after the thaw, we must allocate some resources to fixing the Lisp end of NSFiling. For starters, we must appoint some Phylex users: to the best of my knowledge, NO ONE is using it now. I for one volunteer. But I do not wish to be alone. And once NSFiling seems solid, I don't see any reason why we can't tackle transparently caching files on the local disk -- it can't take more than a couple days to design and implement.
-- Tayloe.
----- End of Forwarded Messages -----
*start*
00720 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 10:44 PST
From: Sannella.pa
Subject: [Raim.pasa: Re: Lisp: NS Filing: Raised Priority]
To: LispSupport
----- Forwarded Messages -----
Date: 21 Feb. 1984 1:18 pm PST (Tuesday)
From: Raim.pasa
Subject: Re: Lisp: NS Filing: Raised Priority
In-reply-to: Stansbury.pa's message of 16 Feb 84 19:25 PST
To: Stansbury.pa
cc: LispSupport.pa, Cooper.pa, Sheil.pa
Tayloe,
I am considering Jerry Fung as the NS-networking resource for this problem. It
would require his spending some time at PARC though. If no one has a better
suggestion, perhaps you can take this up with beau.
--Marty
----- End of Forwarded Messages -----
*start*
00905 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 10:46 PST
From: Sannella.pa
Subject: [ROACH.PA: PHYLEX: BUGS]
To: LispSupport
----- Forwarded Messages -----
Date: 5 MAR 84 16:16 PST
From: ROACH.PA
Subject: PHYLEX: BUGS
To: LISPSUPPORT
cc: ROACH
(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".
(4) It's pretty unpleasant to see an interminable number of
"PHYLEX: Filing not responding"'s appear in my promptwindow when
I am not even interacting with the beastie.
Kelly
----- End of Forwarded Messages -----
*start*
01038 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 10:46 PST
From: Sannella.pa
Subject: [desrivieres.pa: Lisp: NS File servers]
To: LispSupport
----- Forwarded Messages -----
Date: 5 Mar 84 19:26 PST
From: desrivieres.pa
Subject: Lisp: NS File servers
To: LispSupport.pa
cc: 3LispSupport^.pa
Lisp-System-Date: 5-Mar-84 16:21:20
Machine-Type: Dandelion
Some of the problems that I have been having with Phylex:
1. (fullname 'foo 'new) always returns nil; however, (fullname 'foo 'old) seems fine.
2. Tedit PUT to a non-existent file causes a FILE NOT FOUND in OPENSTREAM. If the file exists, a different error is generated.
3. Tedit get on an empty file causes a break under SPP.GETBYTE.
4. Assorted processes named "PHYLEX: Filing#xx" buzz around like mosquitos printing "PHYLEX: Filing#xx not responding.". They have to be swatted with PSW KILL.
5. Doing a MAKESYS to Phylex: caused "SPP Retransmit Queue out of order" error.
---Jim
----- End of Forwarded Messages -----
*start*
00443 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 10:52 PST
From: Sannella.pa
Subject: garbage on LispSupport
To: LispSupport
I hereby proclaim that I am going to be forwarding various msgs from archives and LispCore^ to LispSupport, so that I can enter them into the AR database. Therefore, whomever is "listening" to the traffic on LispSupport (Jonl?), be prepared to recieve a lot of strange garbage.
*start*
00403 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 MAR 84 10:54 PST
From: MASINTER.PA
Subject: wish: DeviceIndependent New Page
To: LispSupport
cc: Kaplan, Burton
I wanted a device independent NEWPAGE:
for windows, it would CLEARW, and for print files, it would skip to the top of the next page (unless at the beginning of the page already).
Seems like a job for DIG.
*start*
00577 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:09 PST
From: Maxwell.pa
Subject: Lisp: Documentation
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
1) I would like to see the Interlisp Reference Manual online. It would be great if I could point at a procedure and say "show me the documentation for this".
2) Where the the output of a control-T documented? I am not sure what Util means. How can I distinguish between when the system is idle and when it is running as hard as it can?
Thanks,
John.
*start*
00521 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:33 PST
From: Maxwell.pa
Subject: Lisp: looking at the source in a stack
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
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.
Thanks,
John.
*start*
00500 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:35 PST
From: Maxwell.pa
Subject: Lisp: new CHANGE function
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
I would like to see a new CHANGE function like PUSH which appended to the end of a list. If the list was NIL, then it would first create a list and then append to it. I tried to write it myself, but it was beyond me. Perhaps it could be called APPENDTO?
Thanks,
John.
*start*
01320 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:06 PST
From: Maxwell.pa
Subject: Lisp: placeholders/form fill in
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
One thing that I miss from Tioga in Cedar that I would like to see in Lisp are placeholders. Tioga uses the Laurel convention of placeholders that allows you to fill in forms easily. If you hit the placeholder key (the middle unmarked key on the right) the editor moves the selection to the next placeholder in the document. This can be used to fill out forms (as this Lisp report) or to fill in parameters on a function call. In Cedar, if you type a procedure name and then ^E, the procedure name will be followed by a form for all of the parameters (sort of like what ?= does). Then you can fill in the parameters one by one, moving from one parameter to the next just by hitting the placeholder key.
Thanks,
John.
P.S. This is the first of a flood of reports that I will be sending over the next few days. I have been keeping a little diary of problems I encountered as a new Lisp user. Larry Masinter asked that I submit the problems as bug reports and feature requests in order to test out the new AR system. Please don't feel like you have to answer these immediately.
*start*
00519 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:11 PST
From: Maxwell.pa
Subject: Lisp: WhoPointsTo
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
Cedar had a low-level debugging feature called WhoPointsTo which told you who pointed to a particular piece of storage. It worked by doing a trace and sweep garbage collection and returning the list of pointers. This was great for all sorts of debugging. Can this be done in Lisp?
Thanks,
John.
*start*
00497 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:13 PST
From: Maxwell.pa
Subject: Lisp: expanding iconic windows
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
It would be nice if you could expand iconic windows just by clicking at them with the middle mouse button. The middle mouse button isn't used for anything else, and the most likely thing that you are going to do with an iconic window is expand it.
Thanks,
John.
*start*
00646 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:17 PST
From: Maxwell.pa
Subject: Lisp: modifying Init.Lisp
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
Something funny is happening with Init.Lisp. If I just try editting it without loading it, it won't complain until I try to clean it up. If I load it first, it doesn't notice that I've editted it. I mentioned this to Ron Kaplan and he seemed to have some idea of what the problem might be. He said it had something to do with the fact that the Init file got loaded in a funny way in the beginning.
Thanks,
John.
*start*
00593 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:19 PST
From: Maxwell.pa
Subject: Lisp: DEdit
To: LispSupport.pa
cc: Maxwell.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
1) Are the rules for how DEdit displays its procedures documented anywhere? I can guess why it does a lot of things, but I have a nagging suspicion that I am missing something.
2) I sometimes get confused by the fact that the local variable declaration in a PROG looks like a line of code. Perhaps if the local variables were printed in italics?
Thanks,
John.
*start*
00487 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:22 PST
From: Maxwell.pa
Subject: Lisp: DOSTATS and ^D
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
Never do a ^D to get out of a DOSTATS. The ^D works, but it doesn't turn off the statistics gathering. By the time you try to recover, the disk will have filled up and you will have fallen into SWAT, having lost everything. Can this be remedied?
Thanks,
John.
*start*
00514 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:24 PST
From: Maxwell.pa
Subject: Lisp: DWIM
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
DWIM keeps asking me if I want to break up names that are perfectly legal all by themselves. For example, it asked me if I wanted to turn FSM.GENERATE into FSM .GENERATE, even though FSM.GENERATE existed and .GENERATE didn't. I think that it may have something to do with the period.
Thanks,
John.
*start*
00489 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:26 PST
From: Maxwell.pa
Subject: Lisp: WHEREIS
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
The WHEREIS package doesn't work for me. It now complains WHEREIS: FILE NOT FOUND <LISP>LIBRARY>WHEREIS.HASH. It has been doing this for a while. I didn't report it earlier because it seemed like such an obvious problem that I was sure it would be fixed.
Thanks,
John.
*start*
00464 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:28 PST
From: Maxwell.pa
Subject: Lisp: analyzing <LFG>PARSER>FSM>
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
I tried to . ANALYZE ALL ON FSM, and it wouldn't let me. Ron Kaplan said that it was because FSM was orignally written on {MAXC}<LFG>, but the server name hadn't been included inside the file. Can this be fixed?
Thanks,
John.
*start*
00438 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@From: kaplan.pa
Date: 15-Mar-84 12:30:15 PST
Subject: Re: wish: DeviceIndependent New Page
In-reply-to: MASINTER's message of 15 MAR 84 10:54 PST
To: MASINTER
cc: LispSupport, Kaplan, Burton
That's been on the DIG list for some time. Not clear that it should do a CLEARW, however. That should be the function that does the stopscroll or the MIT wraparound.
--Ron
*start*
01580 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:45 PST
From: Sannella.pa
Subject: [JONL.PA: How one "release thing" fell thru the cracks]
To: LispSupport
----- Forwarded Messages -----
Date: 12 MAR 84 20:57 PST
From: JONL.PA
Subject: How one "release thing" fell thru the cracks
To: Sannella
cc: Stansbury, Nuyens
Date: 1 JAN 84 03:42 PST
From: JONL.PA
Subject: two little addenda
To: LispCore^
1) APROPOS now prints out to the T stream instead of the NIL stream,
and also tries to eliminate compiled "sub-functions" (but this is
only a heuristic guess)
2) Function ATOMHASH#PROBES takes 1 arg, a string, and returns NIL if
there is no existing litatom with the same pname; otherwise it returns
the number of probes necessary to find the atom in the litatom hash
table (OBARRAY, or OBLIST, or "PACKAGE" in other Lisp systems).
Uh, also, I patched PRINTLEVEL to notice when it is being called "from
top level", and it becomes "UNDO-able" in that case. This is a minor
kludge, but I don't think every call wants to update the history list,
and it's sure a pain if you're hacking around at LISPX and can't undo
some PRINTLEVEL call.
----------------------------------------------------------------------
I'll be willing to bet that Steve Gadol didn't look through the LispCore^
messages last January when he was the delagated release master. WHo knows
what other little goodies like this one are lurking around in the mails
between mid-October and mid-January?
----- End of Forwarded Messages -----
*start*
00437 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 14:12 PST
From: DMRussell.pa
Subject: IT _ ValueOf
To: LispSupport
cc: DMRussell.pa
Didn't the Inspector used to have a feature that would allow you to drop the value of whatever was selected into IT?
If so, whatever happened to this feature? I thought it was a great idea, and noticed it was missing from <LispCore>Next>Full.Sysout
-- DMR --
*start*
00315 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 14:30 PST
From: Nuyens.pa
Subject: Re: junk on <LispCore>Sources>
In-reply-to: masinter.pa's message of 15 Mar 84 00:26 PST
To: masinter.pa
cc: Nuyens.pa, LispSupport.pa
gone. I guess I forgot to conn after loading ABC.
Greg
*start*
00574 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 15:04 PST
From: Sybalsky.pa
Subject: Re: TEdit: ^D getting disabled
In-reply-to: Kaplan.pa's message of 14 Mar 84 21:42 PST
To: Kaplan.pa, VanMelle
cc: TEditSupport.pa, LispSupport
Got it! If the TTY was taken away from TEdit before it had set up the interrupts, the disabling was happening in the new TTY process. After that, the original interrupts were lost--replaced by the TEdit interrupts.
I have a new, private version of TEdit which fixed it; it will be in the next release.
*start*
00447 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 15:10 PST
From: Sannella.pa
Subject: [masinter.pa: AR#57]
To: LispSupport
----- Forwarded Messages -----
Date: 14 Mar 84 19:09 PST
From: masinter.pa
Subject: AR#57
To: SANNELLA
cc: masinter.pa
No categories assigned. Should be Language/DLion microcode, Attn Charnley. Might even turn it into 3 separate ARs.
----- End of Forwarded Messages -----
*start*
00352 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 16:08 PST
Sender: Sannella.pa
Subject: Lisp: DIR
To: LispSupport.pa
From: Stansbury.pa
Lisp-System-Date: 14-Mar-84 10:16:58
Machine-Type: Dolphin
dir {phylex:}<lispmemos>* creationdate author length
gives back creationdate, time, length -- no author!
-- Tayloe.
*start*
00661 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 16:21 PST
Sender: Sannella.pa
Subject: Lisp: Mis-parsed filenames (unpackfilename or filenamfield)
To: LispSupport.pa
From: Stansbury.pa
Lisp-System-Date: 14-Mar-84 10:16:58
Machine-Type: Dolphin
There is a file {phylex:}<lispmemos>bytecomp.user.cm which lisp is choking on.
dir {phylex:}<lispmemos>* creationdate
lists it as bytecomp.user;cm and then tries the getfileinfo with that name, causing a file not found error.
Can't we get filenames like this to parse as (filename bytecomp.user.cm version nil) rather than (filename bytecomp.user version cm)?
-- Tayloe.
*start*
00696 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 16:34 PST
From: vanMelle.pa
Subject: [vanMelle.pa: release message addendum]
To: 1100Support
cc: LispSupport
----- Begin Forwarded Messages -----
Date: 2 Feb 84 14:24 PST
From: vanMelle.pa
Subject: release message addendum
To: LispSupport
The following belongs under "known problems", if not elsewhere:
"You cannot make a sysout from a Dandelion and expect it to run on a Dolphin."
This is still a not well-known fact, and a source of confusion and dismay to those who discover it by trying it and having the sysout mysteriously die on a Dolphin.
Bill
----- End Forwarded Messages -----
*start*
00668 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Thu, 15 Mar 84 17:16 PST
From: Raim.pasa
Subject: Re: Sysout from floppies for Carol.1/Fugue.6
In-reply-to: "masinter.pa's message of 14 Mar 84 17:53 PST"
To: masinter.pa
cc: Raim, JFung, halvorsen.pa, Nuyens.pa, Hausladen.pa, LispSupport.pa, 1100Support
Larry,
A systematic means of generating floppies is on our to-do list. The Installation Utility, in particular, is generated merely by replacing one Prometheus script with another. We not not make new bootable floppies from scratch. When we have instituted well-defined procedures for this, we will share them with you.
--Marty
*start*
00453 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 17:30 PST
From: Sybalsky.pa
Subject: Lisp: TEdit stream Bin, then BACKFILEPTR loses
To: LispSupport.pa
cc: Sybalsky.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
If you BIN 1 char across a piece boundary, then backfileptr across the piece bound, it seems to lose the backfileptr. The result is that you lose a char when expanding macros under READ.
*start*
13631 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 18:24 PST
From: Halasz.pa
Subject: Lisp: Evidence from Bomb in DLIONFS
To: LispSupport.pa
cc:
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
Below is a recurrent problem with the DLIONFS. It happens to us 4 or 5 times a day when we use the file system all day. Leads to a 9318 due to uninterupptableness of the Allocate routine. Looks to me like \VAMAllocateSpace never checks to make sure that the space sent back by \VAMFindSpace (bound to the variable PossibleSpace) is sufficient for its needs. It always bombs in IGREATERP when PossibleSpace becomes NIL.
Frank
--------------
59_redo TELERAID
virtual RAID
@llisp stack in TeleRaid Context
1: \MP.ERROR
2: \LISPERROR
3: \SLOWIGREATERP
4: \VAMAllocateSpace
5: \DFSExtendFile
6: \DFSWriteOnePage
7: \DFSWritePages
8: \WRITEPAGES
9: \WRITEOUTBUFFER
10: \MAPPAGE
11: \GETPAGEBASE
12: \PAGEDBIN
13: \BIN
14: \SUBREAD
15: READ
16: NC.GetItemIdentifier
17: ERRORSET
18: NC.GetNoteCard
19: ERRORSET
20: NC.MakeContentsCard
21: PSA.MakeNoteCard
22: \EVALFORM
23: \EVAL
24: EVAL
25: PSA.MainMenuWhenSelectedFn
26: DOSELECTEDITEM
27: MENUBUTTONFN
28: ERRORSET
29: WINDOW.MOUSE.HANDLER
30: \MOUSE.PROCESS
31: \EVALFORM
32: \EVAL
33: ERRORSET
34: \MAKE.PROCESS0
35: T
@fframe 1
Basic frame at 65634
65624: 16 22 CODE 18
65626: 1 3014 STRING
"Error in uninterruptable system code -- ^N to continue into error handler"
65630: 0 0 ARG1 NIL
65632: 0 0 ARG2 NIL
65634: 100000 65624
Frame xtn at 65636, frame name= \MP.ERROR
65636: 140400 65614 [N, alink]
65640: 41400 40 [fn header]
65642: 65656 71 [next, pc]
65644: 177774 4 [nametable]
65646: 1 35400 [blink, clink]
65650: 16 30 [padding]
65652: 0 27 [padding]
65654: 16 22 18
@
Next frame (2)
Basic frame at 65600
65572: 0 0 *local* NIL
65574: 16 12 *local* 10
65576: 0 0 *local* NIL
65600: 100000 65572
Frame xtn at 65602, frame name= \LISPERROR
65602: 140000 65554 [ alink]
65604: 112044 41 [fn header]
65606: 65624 113 [next, pc]
65610: 0 0 [nametable]
65612: 0 0 [blink, clink]
65614: 65462 13427 [fvar \INTERRUPTABLE on stack]
65616: 177777 35730 [padding]
65620: 16 27 [padding]
65622: 0 27 [padding]
@
Next frame (3)
Basic frame at 65540
65534: 0 0 *local* NIL
65536: 16 346 *local* 230
65540: 100000 65534
Frame xtn at 65542, frame name= \SLOWIGREATERP
65542: 140000 65462 [ alink]
65544: 125714 40 [fn header]
65546: 65572 167 [next, pc]
65550: 65562 74 [nametable]
65552: 16 0 [blink, clink]
65554: 0 0 *local* NIL
65556: 0 0 *local* NIL
65560: 0 0 *local* NIL
65562: 0 0 *local* NIL
65564: 6 131127 [padding]
65566: 0 23 [padding]
65570: 177773 6
@
Next frame (4)
Basic frame at 65446
65442: 16 3 VolNum 3
65444: 16 346 Needed 230
65446: 100000 65442
Frame xtn at 65450, frame name= \VAMAllocateSpace
65450: 140000 65404 [ alink]
65452: 113240 54 [fn header]
65454: 65534 170 [next, pc]
65456: 125714 40 [nametable]
65460: 16 177777 [blink, clink]
65462: 0 0 \INTERRUPTABLE NIL
65464: 6 127266 VFMPages (5 6 7 8 9)
65466: 7 111400 VAMPtr (VMEMPAGEP 7 37632)
65470: 6 131000 VOLPagePtr (VMEMPAGEP 6 45568)
65472: 0 0 PossibleSpace NIL
65474: 16 1 VAMPage 1
65476: 0 0 Interval NIL
65500: 16 1 StartInterval 1
65502: 17 177777 Taken -1
65504: 1 35722 Result ((1 . -1) (18 . -2) (32 . -1) (49 . -2) (66 .
-1) (80 . -1) (97 . -1) (113 . -1) (132 . -1) (145 . -1) (160 . -8) (177 . -3)
(193 . -1) (209 . -4) (225 . -1) (240 . -2) (257 . -3) (272 . -1) (289 . -3)
(304 . -2) (320 . -12) (336 . 16) (369 . -5) (386 . -1) (401 . -2) (416 . -4)
(432 . -8) (448 . 16) (482 . -2) (496 . -1) (516 . -1) (528 . -2) (544 . -1) (
562 . -2) (576 . -3) (592 . -2) (609 . -1) (625 . -2) (641 . -5) (656 . -3) (
672 . -1) (688 . -2) (705 . -2) (720 . -3) (740 . -2) (753 . -1) (769 . -5) (
784 . -2) (800 . -1) (816 . -4) (832 . -4) (850 . -2) (866 . -2) (880 . -1) (
900 . -1) (912 . -2) (928 . -1) (946 . -2) (960 . -5) (976 . -5) (993 . -5) (
1012 . -2) (1025 . -1) (1042 . -2) (1057 . -2) (1073 . -1) (1088 . -2) (1104
. -4) (1124 . -1) (1137 . -1) (1152 . -1) (1170 . -2) (1185 . -1) (1201 . -1)
(1220 . -1) (1233 . -1) (1248 . -9) (1265 . -3) (1281 . -1) (1297 . -4) (1313
. -1) (1328 . -2) (1345 . -3) (1360 . -1) (1378 . -2) (1393 . -3) (1408 . -8)
(1424 . 16) (1457 . -5) (1474 . -1) (1489 . -2) (1504 . -4) (1520 . -8) (1536
. 16))
65506: 177777 177777 *local* [unbound]
65510: 177777 1 Page [unbound]
65512: 124042 11022 [fvar \VFMPages top value]
65514: 123720 11022 [fvar \LogicalVolumes top value]
65516: 0 114 [padding]
65520: 0 47 [padding]
65522: 177776 0
65524: 177766 22
65526: 6 131000 (VMEMPAGEP 6 45568)
65530: 7 16122 ((1536 . 16) (1520 . -8) (1504 . -4) (1489 . -2) (1474
. -1) (1457 . -5) (1424 . 16) (1408 . -8) (1393 . -3) (1378 . -2) (1360 . -1)
(1345 . -3) (1328 . -2) (1313 . -1) (1297 . -4) (1281 . -1) (1265 . -3) (1248
. -9) (1233 . -1) (1220 . -1) (1201 . -1) (1185 . -1) (1170 . -2) (1152 . -1)
(1137 . -1) (1124 . -1) (1104 . -4) (1088 . -2) (1073 . -1) (1057 . -2) (1042
. -2) (1025 . -1) (1012 . -2) (993 . -5) (976 . -5) (960 . -5) (946 . -2) (
928 . -1) (912 . -2) (900 . -1) (880 . -1) (866 . -2) (850 . -2) (832 . -4) (
816 . -4) (800 . -1) (784 . -2) (769 . -5) (753 . -1) (740 . -2) (720 . -3) (
705 . -2) (688 . -2) (672 . -1) (656 . -3) (641 . -5) (625 . -2) (609 . -1) (
592 . -2) (576 . -3) (562 . -2) (544 . -1) (528 . -2) (516 . -1) (496 . -1) (
482 . -2) (448 . 16) (432 . -8) (416 . -4) (401 . -2) (386 . -1) (369 . -5) (
336 . 16) (320 . -12) (304 . -2) (289 . -3) (272 . -1) (257 . -3) (240 . -2) (
225 . -1) (209 . -4) (193 . -1) (177 . -3) (160 . -8) (145 . -1) (132 . -1) (
113 . -1) (97 . -1) (80 . -1) (66 . -1) (49 . -2) (32 . -1) (18 . -2) (1 . -1)
)
65532: 0 0 NIL
@
Next frame (5)
Basic frame at 65370
65362: 5 7300 Stream (STREAM 5 3776)
65364: 16 42 Page 34
65366: 6 1710 Key (Key 6 968)
65370: 100000 65362
Frame xtn at 65372, frame name= \DFSExtendFile
65372: 140000 65336 [ alink]
65374: 122320 54 [fn header]
65376: 65442 153 [next, pc]
65400: 16 42 [nametable]
65402: 6 131322 [blink, clink]
65404: 0 0 \INTERRUPTABLE NIL
65406: 6 126000 Leader (VMEMPAGEP 6 44032)
65410: 17 177777 Needed -1
65412: 0 0 Available NIL
65414: 0 0 PageAddr NIL
65416: 16 3 VolNum 3
65420: 177777 0 Interval [unbound]
65422: 177777 131322 [padding]
65424: 6 131322 [padding]
65426: 0 37 [padding]
65430: 177776 0
65432: 177772 12
65434: 16 3 3
65436: 6 126000 (VMEMPAGEP 6 44032)
65440: 17 177777 -1
@
Next frame (6)
Basic frame at 65322
65314: 5 7300 Stream (STREAM 5 3776)
65316: 16 42 Page 34
65320: 1 166400 Buffer (VMEMPAGEP 1 60672)
65322: 100000 65314
Frame xtn at 65324, frame name= \DFSWriteOnePage
65324: 140000 65276 [ alink]
65326: 121514 54 [fn header]
65330: 65362 142 [next, pc]
65332: 125430 40 [nametable]
65334: 65366 516 [blink, clink]
65336: 16 3 VolNum 3
65340: 6 1710 Key (Key 6 968)
65342: 0 0 PageAddr NIL
65344: 177777 177777 [padding]
65346: 16 177777 [padding]
65350: 0 27 [padding]
65352: 177774 4
65354: 16 42 34
65356: 16 42 34
65360: 0 0 NIL
@
Next frame (7)
Basic frame at 65262
65254: 5 7300 Stream (STREAM 5 3776)
65256: 16 41 FirstPage 33
65260: 1 166400 Buffers (VMEMPAGEP 1 60672)
65262: 100000 65254
Frame xtn at 65264, frame name= \DFSWritePages
65264: 140000 65240 [ alink]
65266: 117124 54 [fn header]
65270: 65314 113 [next, pc]
65272: 0 0 [nametable]
65274: 0 0 [blink, clink]
65276: 0 0 *local* NIL
65300: 16 41 Page 33
65302: 1 166400 Buffer (VMEMPAGEP 1 60672)
65304: 177777 12 [padding]
65306: 73 73200 [padding]
65310: 0 27 [padding]
65312: 177774 4
@
Next frame (8)
Basic frame at 65224
65216: 5 7300 *local* (STREAM 5 3776)
65220: 16 41 *local* 33
65222: 1 166400 *local* (VMEMPAGEP 1 60672)
65224: 100000 65216
Frame xtn at 65226, frame name= \WRITEPAGES
65226: 140000 65212 [ alink]
65230: 62710 40 [fn header]
65232: 65254 73 [next, pc]
65234: 64736 13427 [nametable]
65236: 64734 13427 [blink, clink]
65240: 0 52147 *local* \DFSWritePages
65242: 177777 17 [padding]
65244: 1 120700 [padding]
65246: 0 23 [padding]
65250: 0 0 NIL
65252: 177776 0
@
Next frame (9)
Basic frame at 65176
65172: 1 120700 *local* (BUFFER 1 41408)
65174: 5 7300 *local* (STREAM 5 3776)
65176: 100000 65172
Frame xtn at 65200, frame name= \WRITEOUTBUFFER
65200: 140000 65152 [ alink]
65202: 50730 41 [fn header]
65204: 65216 66 [next, pc]
65206: 177777 13427 [nametable]
65210: 177774 4 [blink, clink]
65212: 0 23 [padding]
65214: 0 23 [padding]
@
Next frame (10)
Basic frame at 65136
65130: 16 40 *local* 32
65132: 5 7300 *local* (STREAM 5 3776)
65134: 0 0 *local* NIL
65136: 100000 65130
Frame xtn at 65140, frame name= \MAPPAGE
65140: 140000 65116 [ alink]
65142: 52430 41 [fn header]
65144: 65172 411 [next, pc]
65146: 16 3 [nametable]
65150: 16 3 [blink, clink]
65152: 1 120700 *local* (BUFFER 1 41408)
65154: 16 4 *local* 4
65156: 1 120700 *local* (BUFFER 1 41408)
65160: 2 23520 *local* (BUFFER 2 10064)
65162: 0 0 [padding]
65164: 0 23 [padding]
65166: 177776 0
65170: 177774 6
@
Next frame (11)
Basic frame at 65102
65076: 5 7300 *local* (STREAM 5 3776)
65100: 0 3224 *local* READ
65102: 100000 65076
Frame xtn at 65104, frame name= \GETPAGEBASE
65104: 140000 65072 [ alink]
65106: 53234 41 [fn header]
65110: 65130 256 [next, pc]
65112: 0 23 [nametable]
65114: 0 23 [blink, clink]
65116: 0 0 *local* NIL
65120: 0 0 *local* NIL
65122: 16 3 [padding]
65124: 0 23 [padding]
65126: 177775 2
@
Next frame (12)
Basic frame at 65056
65054: 5 7300 *local* (STREAM 5 3776)
65056: 100000 65054
Frame xtn at 65060, frame name= \PAGEDBIN
65060: 140000 65042 [ alink]
65062: 53570 41 [fn header]
65064: 65076 57 [next, pc]
65066: 0 23 [nametable]
65070: 177763 26 [blink, clink]
65072: 32 27620 [padding]
65074: 0 17 [padding]
@
Next frame (13)
Basic frame at 65026
65024: 5 7300 *local* (STREAM 5 3776)
65026: 100000 65024
Frame xtn at 65030, frame name= \BIN
65030: 140000 64754 [ alink]
65032: 66010 40 [fn header]
65034: 65054 57 [next, pc]
65036: 0 23 [nametable]
65040: 1 17026 [blink, clink]
65042: 0 5004 *local* \PAGEDBIN
65044: 177777 12 [padding]
65046: 73 27000 [padding]
65050: 0 17 [padding]
65052: 177776 0
@
Next frame (14)
Basic frame at 64740
64730: 5 7300 *local* (STREAM 5 3776)
64732: 1 115400 *local* (CHARTABLE 1 39680)
64734: 0 0 *local* NIL
64736: 1 53700 *local*
"{STREAM}#5,7300CardkxtCardnt context?e Contents cards. QUIT? .n card.utside the window to stop.utton will zoom the nearest edge point to the cursor.
Holding the button down will zoom continuously. BUTTON OUTSIDE TO STOP.EDIT READNUMBER EDITBITMAP MAILCL"
64740: 100000 64730
Frame xtn at 64742, frame name= \SUBREAD
64742: 140000 64706 [ alink]
64744: 151100 40 [fn header]
64746: 65024 123 [next, pc]
64750: 0 17 [nametable]
64752: 177777 0 [blink, clink]
64754: 40 31576 *local* (# 32 13182)
64756: 0 0 *local* NIL
64760: 0 0 *local* NIL
64762: 0 0 *local* NIL
64764: 0 0 *local* NIL
64766: 0 0 *local* NIL
64770: 0 0 *local* NIL
64772: 0 0 *local* NIL
64774: 0 0 *local* NIL
64776: 0 0 *local* NIL
65000: 0 0 *local* NIL
65002: 0 0 *local* NIL
65004: 177777 1615 \RBFLG [unbound]
65006: 177777 1 [fvar \RBFLG not looked up]
65010: 177777 65004 [fvar #CURRENTRDTBL# not looked up]
65012: 177777 23 [fvar \LINEBUF.OFD not looked up]
65014: 0 1711 [padding]
65016: 0 43 [padding]
65020: 177763 26
65022: 1 115400 (CHARTABLE 1 39680)
@qquit [confirm]
NIL
60_(DRIBBLE)
*start*
00668 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 18:43 PST
From: desRivieres.pa
Subject: Lisp: OPENLAMBDAs and FETCH
To: LispSupport.pa
cc: desRivieres.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
It appears that the compiler is substituting into qualified field references on FETCH and REPLACE expressions. For example, if FOO is defined to be
(OPENLAMBDA (ENV)
(FETCH (MY-RECORD-TYPE ENV) OF BAR))
then (FOO NIL) will expand to
(FETCH (MY-RECORD-TYPE NIL) OF BAR)
which, fortunately, won't compile. Would it be possible to prevent the compiler from substituting into these contents?
---Jim
*start*
00338 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 18:49 PST
From: Stansbury.pa
Subject: Re: DLIONFS
In-reply-to: Sannella.PA's message of 14 Mar 84 14:40:52 PST (Wednesday)
To: LispSupport.pa
You should forward dlionfs messages to Beau too, until he picks someone; it might hurry him up.
-- Tayloe.
*start*
00563 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 18:57 PST
From: Stansbury.pa
Subject: Lafite: TEdit format
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 15-Mar-84 11:06:37
Machine-Type: Dorado
When you forward a message with Format: TEdit in the header, it should automatically put Format: TEdit in the header of the enclosing message.
-- Tayloe.
[Maybe it already does; it occurs to me that the message which prompted me to send this was probably forwarded by Hardy instead of Lafite.]
*start*
00329 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 19:01 PST
From: Stansbury.pa
Subject: Re: question from Shulman: ATTACHEDWINDOW
In-reply-to: Sannella.PA's message of 14 Mar 84 14:57:13 PST (Wednesday)
To: LispSupport.pa
Attachedwindow was written and is maintained by Richard.
-- Tayloe.
*start*
00616 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 19:09 PST
From: Stansbury.pa
Subject: Re: FILESETS doesn't belong on <Lisp>Library>, dunno how it got there
In-reply-to: masinter.pa's message of 15 Mar 84 00:27 PST
To: masinter.pa
cc: LispSupport.pa
Filesets is loaded by abc, which at one point was on the library; that's why filesets is there. Since abc has been superceded by sysedit, and I don't believe sysedit loads filesets (at least, it shouldn't), filesets should probably be nuked from the library. There exist more uptodate versions elsewhere anyway.
-- Tayloe.
*start*
00420 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 12:29 EST
From: Denber.wbst
Subject: Lafite: NEWMAILTUNE
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dolphin
Does one need to do anything besides SETQ LAFITENEWMAILTUNE to a TUNE to get it to work? I tried it but nothing happens when I get new mail.
- Michel
*start*
00648 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 19:27 PST
From: Stansbury.pa
Subject: TEdit: Transfering TTY
To: TEditSupport
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 11:06:37
Machine-Type: Dorado
If you have a section of text blue-pending-delete selected, then button another window to type to it, then button your TEdit window again in hopes of being able to replace your pending-delete selection, guess what -- your selection gets changed. In other words, I would like the first click to give the tty back to the TEdit window, and the second to make a new selection.
-- Tayloe.
*start*
00481 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 15:21 EST
From: Denber.wbst
Subject: Lafite: TEDIT form
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dolphin
When I send a Lafite report it is addressed to LafiteSupport.pa but if I ask for a TEDIT report form it shows up addressed to TEDITSupport, which gets defaulted to TEDITSupport.WBST when I try to send it.
- Michel
*start*
00663 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 20:32 PST
From: Kaplan.pa
Subject: Re: AR 125: DWIM breaks up bound var FSM.GENERATE
In-reply-to: Sannella.PA's message of 15 Mar 84 19:58:59 PST (Thursday)
To: LispSupport.PA
cc: Masinter
He falls into that trap because the greeting guy doesn't smash the filecoms for INIT, hence they are left around for him to edit with impunity--except that he can't dump the file because it hasn't been loaded.
Best solution would be to fix it so that greeting can be done by simply LOADing a file SYSLOAD, which would automatically smash the filecoms. Why isn't this done now?
--Ron
*start*
00245 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 20:35 PST
From: Kaplan.pa
Subject: AR 125 --> 122
To: LISPSUPPORT, MASINTER
I might have sent a message about 122 that had 125 in its header. Sorry.
--Ron
*start*
00291 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 20:34 PST
From: Kaplan.pa
Subject: Re: AR 126: WHEREIS package can't find file
In-reply-to: Sannella.PA's message of 15 Mar 84 20:06:09 PST (Thursday)
To: LispSupport.PA
This should be passed to Burton.
*start*
00312 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 20:36 PST
From: Kaplan.pa
Subject: Re: Is he suffering from a wrong Filemap?
In-reply-to: Sannella.PA's message of 15 Mar 84 20:09:00 PST (Thursday)
To: LispSupport.PA
Don't know what the problem is here. Could be filemap.
*start*
00536 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@From: masinter.pa
Date: 16-Mar-84 0:10:39 PST
Subject: Re: AR 126: WHEREIS package can't find file
In-reply-to: Sannella's message of 15 Mar 84 20:06:09 PST (Thursday)
To: LispSupport
cc: masinter
I dunno who is responsible for WHEREIS. I suspect the problem is that it asks for <Lisp>Library>WHEREIS.HASH but Maxwell uses Indigo/Ivy for his home fileserver or login directory. It may be that the WHEREISHASHFILE variable has to be set in the "site" greet file.
*start*
00291 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@From: masinter.pa
Date: 16-Mar-84 0:13:58 PST
Subject: Re: AR 124: DOSTATS and ^D
In-reply-to: Sannella's message of 15 Mar 84 19:55:59 PST (Thursday)
To: LispSupport
should be Easy to fix with a RESETLST around it . *start*
00221 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 MAR 84 00:54 PST
From: MASINTER.PA
Subject: Please remove BLisp.PA from TEditSupport
To: owners-TEditSupport
Since LispAR.auto is on it.
*start*
00368 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Thu, 15 Mar 84 11:41 PST
From: Raim.pasa
Subject: Re: Disappearing dsk files
In-reply-to: "Stansbury.pa's message of 14 Mar 84 15:57 PST"
To: Stansbury.pa
cc: Lispsupport.pa, Sannella.pa, Raim, Dering
Tayloe,
Thank you. We will be testing the new sysout over the next few days.
--Marty
*start*
01394 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 20:47 PST
From: Kaplan.pa
Subject: New function for release: COPYCHARS
To: Lispsupport, LispCore^
I have installed a new function in the system (in FILEIO). Here's the documenation:
"(COPYCHARS SRCFIL DSTFIL START END)
is like COPYBYTES except that it performs the proper conversion if the EOL conventions of SRCFIL and DSTFIL are not the same. START and END are interpreted as byte specifications in SRCFIL. The number of bytes actually output to DSTFIL might be more or less than the number of bytes specified by START and END, depending on what the EOL conventions are. In the case where the EOL conventions happen to be the same, COPYCHARS simply calls COPYBYTES."
This function should be used instead of copybytes in various text-processing places in the system, so that EOL conventions get treated properly. I will fix PRETTYDEF so that it copies symbolic definitions with COPYCHARS. I believe Lafite should use it to copy mail from the grapevine to the mail folder, Tedit should use it to copy unchanged pieces (along with some other necessary changes for EOL conventions), and COPYFILE should presumably use this when copying a file of type TEXT (We might want to have a flag argument to allow the user to suppress EOL conversion if he wants to). Is there a current owner of COPYFILE?
*start*
00192 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 20:56 PST
From: Kaplan.pa
Subject: COPYCHARS documentation has been inserted in manual
To: Lispsupport
*start*
00351 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 MAR 84 00:57 PST
From: MASINTER.PA
Subject: COPYCHARS message hidden ARs
To: lispSupport
cc: Kaplan
Ron, if there is some part of this conversion tht needs finishing (like fixing COPYFILE) why don't you send in an AR to LispSupport listing what should be done, ok?
*start*
00259 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 MAR 84 00:57 PST
From: MASINTER.PA
Subject: COPYCHARS message
To: kaplan
cc: lispsupport
Also, for the record, COPYCHARS is a fix to a problem, right?
What was the problem?
*start*
00449 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 13:22 PST
From: Kaplan.pa
Subject: Re: COPYCHARS message
In-reply-to: MASINTER.PA's message of 16 MAR 84 00:57 PST
To: MASINTER.PA
cc: kaplan.PA, lispsupport.PA
There were several action items in my copychars message, which was also sent to Lispsupport.
The problem that COPYCHARS, when called in relevant places, fixes is converting EOL conventions properly.
*start*
00437 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 11:25 PST
From: Burton.pa
Subject: Re: question from Shulman
In-reply-to: Sannella.PA's message of 14 Mar 84 14:57:13 PST (Wednesday)
To: Sannella
cc: LispSupport.pa
I don't believe ATTACHEDWINDOW will run in any system earlier than Christmas. I don't know whether fugue versions come that late or not. It ok with me to let him have it.
richard
*start*
00260 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 MAR 84 01:16 PST
From: MASINTER.PA
Subject: want background process to linearize free lists to improve workingset
To: LispSupport
I think. At least I want to experiment with it
*start*
01989 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@From: masinter.pa
Date: 16-Mar-84 2:00:02 PST
Subject: mail
To: lafitesupport
----------
Date: 16 Mar 84 01:34:22 PST
From: Murray.pa
Subject: Who is the Lisp/Smalltalk mail guru?
To: Deutsch, Masinter
--------------------------------------
Date: 16 Mar 84 00:31:00 PST
From: Murray.pa
Subject: Junk mail needed
To: Junk^
Cc: Murray, JLarson, RWeaver, Redell, Willie-Sue, Karlton
Reply-to: Murray.pa
Ever seen a request like this before?
I'm working on the Cedar based mail gateway to replace Maxc as our link to the Arpanet. It's working well enough to survive all my testing so I'm looking for more traffic to smoke out the next layer of bugs.
If you are willing to type a few extra characters on some of your messages that aren't too important read on.
If you would normally send a msg to X@Y, sending it to "X@Y".NotArpa will get it to my machine instead. I'll strip off the .NotArpa and the ""s, and forward it to the right place. On the way out to the Arpanet, I'll fixup the return addresses so that answering mail will come back via PARC-GW.ARPA rather than PARC-MAXC.ARPA.
When you send a message to a recipient whose name contains an @, your mail processing software adds a .ARPA (or .AG, or .ArpaGateway) if it doesn't already end in one. The .NotArpa gets your message to my machine, and the ""s hide the @ so it doesn't get sent to Maxc.
I don't yet do the right thing with addresses of the form @A,@B:X@Y so please avoid them for now. Also, I don't do \ processing when stripping "s, so don't try nesting "s.
The server is currently running on my Dorado. It will obviously be down while it's waiting for me to look at a fatal bug or I'm working on something else. I don't expect to work on much else until I get this cleaned up so service shouldn't be too horrible. Just a warning so you don't complain about random delays...
I hope I don't drown.
--------------------------------------
*start*
00320 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 MAR 84 01:19 PST
From: MASINTER.PA
Subject: READINTERPRESS
To: kaplan
cc: LispSupport
Suggest you move it to LispUsers with a little minimal documentation.
Of course, it shouldn't get shipped to customers without some clearance...
*start*
05221 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@From: masinter.pa
Date: 16-Mar-84 1:41:52 PST
Subject: Many questions and comments from Jim Goodwin
To: LispSupport
cc: Raim.pasa
I encouraged Jim to continue to complain loudly and frequently. What to do with this message? Extract as many ARs as you can, and send summary back to Goodwin with as many replies as you can to his questions. Please include me in the cc: of your messages.
Please also include "Haggstrom.RX" and "Gittins.RX".
----------
Received: from BBNG.ARPA by PARC-MAXC.ARPA; 15 MAR 84 15:29:30 PST
Date: Thu, 15 Mar 84 18:30:00 EST
From: LINKOPING@BBNG.ARPA
Subject: Dlion info
To: masinter.pa
Larry,
Sorry it took so long to reply to your messages;
our communication along this channel is frequently rather sporadic.
They changed a terminal concentrator in Boston and caused
us no end of trouble before we figured out how to get online again.
I gather my efforts to shake forth some additional info splashed down
somewhat tactlessly in the midst of ongoing discussions between Xerox and
the Interlisp D customer community about just exactly the adequacy of info
provided. [Ref exchange of messages between Kim Korner and Lorrraine
Kiewert]. This was unintentional. I did not go to
the 100 support group first because at first I did not know that it existed.
I'll use them first next time, appropriately I hope.
Unfortunately, I do not imagine they will answer the most important questions
I have, which are not questions about specific bugs, but about the general
range of functionality and software support planned in certain large and
expensive areas. These questions may be just inherently embarrassing, in the
specific sense that answering them forces Xerox into policy committments.
It is not my intent to do that, buut customers do have some right to know
these things. Therefore I will address them to you thus
privately; you may burn this message, and reply however you see fit.
I will be glad to ask them inn another forum if you prefer.
The relation between Interlisp and the file server is unsatisfactory at several
points. This does not worry me particularly on the assuumption that it will
be fixed eventually, but I have not yet found anyone who can say "Yes, we're
working on that" or how it will look whenn fixed.
Doing a directory of something like <LISP> takes much too long.
Doing a directory of <LISP>FOO.* takes just as long.
MMAKEFILE, TEDIT, and many other operations fail, crash, and go wrong
due to the lack of a random access protocol. Will our file server eventually
support random access?
Will there ever be a release of Fugue/Carol etc which is fully interrupt
driven?
Will there be an acceptable text-editing and document handling
facility any time soon? TEDIT is not one in its present state.
I would not object to it at all if I were told that it is just the current
version of a program being developed further, and that one could expect major
improvements this year.
Those questions are probably the most important ones I have.
I could report little bugs by the basketful. I don't consider it very
constructive, because most of them look to me like things you all undoubtedly
know about already and probably have alredy fixed in your latest working system
or else things which are obviously derived from major issues like random access.
I try to report those which system people might be glad to hear about.
They don't need to be told 100 different things which go wrong when random
access files don't work. At least that was what I thought when I was
doing system work.
I am re-reading your messages.
About the chain of command:
Uwe Hein and I have worked together for 4 years or so.
He is formally my thesis advisor, when I work on that.
He has now reduced his committment to the University to part time
in order to run Epitec. which among other things is the "Xerox support
group" here. Tomas Lund also sits here with us, and works for Epitec.
It was when he and Christer Haegstrom were blocked after several days
of work on the RS232 problem, and nobody knew anything more to try,
that I decided to try breaking into Parc with netamil to find out where to go.
I have heard about Gittins. He wrote a users guide, which is
a service. Otherwise London Xerox seems from here to be a rather unnecessary
level of indirection, but probably others like Christer see benefits in having
them which are not obvious to me.
Found your other message about my talking to the guys at Stanford.
I did not really ask them to solve our problem, I asked them sort of
generally who had installations like ours. I gather they don't,
and you don't. I still do not know of any place which is all NS, no PUP;
all 1108, no 1100 or Altos or whatever; and has lots of DEC machines to
talk to.
I am aware that we have not investigated the possibility of using PUP to
talk to the DEC-20. That is a project which we are pursuing, but the information comes slowly, and
then it takes me time to get around to reading it.
In any case, I will try not to upset your applecarts by asking too many
awkward questions in the users' group discussion,. without trying Xerox first.
Jim
-------
*start*
01117 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@From: masinter.pa
Date: 16-Mar-84 1:51:25 PST
Subject: RSX file server, for the files
To: lispsupport
----------
Received: from LLL-MFE.ARPA by PARC-MAXC.ARPA; 15 MAR 84 15:35:09 PST
Date: Thu, 15 Mar 84 15:04 PST
From: "Brand Hal"@LLL-MFE.ARPA
Subject: RSX file server
To: masinter.pa
The driver, etc. came with Phil Young of Xerox (Pasadena I believe).
The Dolphin was leased (we had all kinds of problems with Lab lawyers on
contracts) with the provision that Xerox provide the software for using
our RSX machine as a file server. We were told that this was no problem
as it had been done before. However, when Phil came out, he was very kind,
but left us with the impression that that this was the last RSX file server
Xerox was ever going to do - Xerox had to make a special run just to produce
the 3Mbyte/sec. interface boards. (We opted for the 3 Mbyte version cause
when we start negotiations, the 10 was very new and there was no RSX support
for the 10.)
By the way, should we have gotten the sources???
Hal Brand
*start*
00343 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 09:44 PST
From: Sybalsky.pa
Subject: Re: Lafite: TEDIT form
In-reply-to: Denber.wbst's message of 15 Mar 84 15:21 EST
To: Denber.wbst
cc: LafiteSupport.pa
Oog. Sorry 'bout that! I've got it fixed for the next release of TEdit. Sigh--I just assumed....
*start*
00747 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 MAR 84 11:06 PST
From: JONL.PA
Subject: Re: AR 41: READ, OPENSTRINGSTREAM, & RDTBL
To: Kaplan, LISPSUPPORT
cc: DesRivieres, Lispcore^, JONL
In response to the message sent 14 Mar 84 23:46 PST from Kaplan.pa
I don't like this solution. The FULLNAME operation was the only
way to get a handle on the string for which this stream was created (by
calling OPENSTRINGSTREAM).
I still think it's appropriate for the reader simply to pass through unchanged
the argument given to READ. That way, any questions about format of the "file"
are simply deferred to the readmacro function; any such function that needs
to look at the fullname can call FULLNAME itself.
*start*
01187 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 14:12 PST
From: Kaplan.pa
Subject: Re: AR 41: READ, OPENSTRINGSTREAM, & RDTBL
In-reply-to: JONL.PA's message of 16 MAR 84 11:06 PST
To: JONL.PA
cc: Kaplan.PA, LISPSUPPORT.PA, DesRivieres.PA, Lispcore^.PA
Passing thru the argument given to READ unchanged requires the same kind of editting of all the existing macro functions that passing thru the stream would require. The user can say (READ NIL), with NIL --> T. The macro functions are also testing (EQ FILE T), and would behave incorrectly. Passing thru the name unchanged would also be a step backwards down the path we want to go on--towards passing streams only.
If we wanted to go around and edit all the affected macro functions, one tack to take is to make them internally call FULLNAME on the file argument, and test that against T if that's what they want to do. That would make it work whether we passed in the user's partial name, or the stream.
This is for the future, when we have more energy for random perturbations. (And also, we would have to make sure that FULLNAME of a fullname ran acceptably fast on the 10).
--Ron
*start*
01663 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 17 MAR 84 13:40 PST
From: JONL.PA
Subject: Re: AR 41: READ, OPENSTRINGSTREAM, & RDTBL
To: Kaplan, JONL
cc: LISPSUPPORT, DesRivieres, Lispcore^
In response to the message sent 16 Mar 84 14:12 PST from Kaplan.pa
The documented macrocharacter function interface doesn't specify that the
"file" argument has been in any way perturbed, so any changes to such a
"perturbation" should affect only the system-supplied macrochar fns which
depended upon this undocumented kludge.
True, the "right" way to go is to coerce to STREAMs, but my R.I.P comments
still apply for any code that wants to be compatible with the PDP10.
How about this as an "interim" measure:
1) convert any litatom argument to READ into FULLNAME of that litatom
2) leave STREAM arguments alone
Certainly, no PDP10 code would be affected by point (2), and point (1)
would catch all current cases of PDP10 READs.
In fact, I can't see any other solution in general for STREAMS (than to
leave them alone) since it is perfectly acceptable to create a stream
which supports most I/O operations except FULLNAME. Worse yet, how ever
can one expect FULLNAME to be information-preserving when there are multiple
streams open on the same file.
There aren't that many system-supplied macrocharacter fns (simply scanning
the three initial readtables will find them all). They could simply have
(SETQ FULL (COND ((STREAMP FILE) (FULLNAME FILE)) (T FILE)))
which, by point (1) above, would always guarantee that FULL was the
FULLNAME of the file, but would never call FULLNAME unnecessarily (especially
on the PDP10).
*start*
01114 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 17 MAR 84 22:54 PST
From: MASINTER.PA
Subject: Re: AR 41: READ, OPENSTRINGSTREAM, & RDTBL
To: JONL, Kaplan
cc: LISPSUPPORT, DesRivieres, Lispcore^
In response to the message sent 17 MAR 1984 1340-PST by JONL.PA
I think Ron introduced the minimal change which had the positive characteristics of:
a) it actually fixed the problem which started the whole thing
b) it didn't break anything else
c) it didn't commit us to immediately undertaking major rewrites of the system that we don't have the resources to pursue.
There are a number of major items which are demanding attention from Ron , you, me, etc. which this discussion merely distracts us from. Lets put in an AR, conversion from FULLNAME to STREAM, and schedule it with the rest of the items in the queue.
On this topic, I'd like to re-solicit from people what their "top-ten" tasks for the coming six months are; i.e., what are the major items that you think are important to get resolved in the near future. (Not just the ones that are on your personal agenda.)
*start*
00641 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 MAR 84 00:15 PST
From: JONL.PA
Subject: Re: AR 41: READ, OPENSTRINGSTREAM, & RDTBL
To: MASINTER, Kaplan
cc: LISPSUPPORT, DesRivieres, Lispcore^, JONL
In response to the message sent 17 MAR 84 22:54 PST from MASINTER.PA
Wrong.
It breaks the ability to find out what STRINGP the STREAM came from.
It also breaks the ability to re-open a stringstream. I have used the
former many times, and wanted the latter ocasionally. But of course,
in I-10, this isn't "broken", since it does't have STREAMs.
Larry, have you even ever used OPENSTRINGSTREAM?
*start*
00460 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 MAR 84 11:18 PST
From: JONL.PA
Subject: Re: Lisp: NOW is being bound!
To: Nuyens, LispSupport
cc: JONL
In response to the message sent 14 Mar 84 16:03 PST from Nuyens.pa
ABCDATABASE.SYSOUT shows only two funcitons SETting NOW, and both of them
have it boud first. PPROC1 from PROC and \ITEM.WINDOW.SELECTION.HANDLER
from INSPECT.
Nobody seems to use THEN as a variable.
*start*
00353 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 15:47 PST
From: vanMelle.pa
Subject: Re: AR 105: Atoms NOW, THEN being bound!
In-reply-to: Sannella.PA's message of 15 Mar 84 17:35:50 PST (Thursday)
To: LispSupport.PA
cc: LispCore^.pa
Not being BOUND, being SET. Ask the abc database
. WHO USES NOW OR THEN FREE
*start*
01088 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 MAR 84 11:52 PST
From: JONL.PA
Subject: Re: SETDIRECTORIES on [phylum]<LispCore>Sources>ABC has wrong entries
To: masinter, LispSupport
cc: JONL
In response to the message sent 14 Mar 84 20:14 PST from masinter.pa
SETDIRECTORIES is on FILESETS, not ABC.
<LispCore>LispUsers> is for those <LispUsers> files that must be coordinated
with a particular release.
Not sure what you think is the problem with the resetting of DIRECTORIES --
see my msg dated 13 MAR 84 20:00 PST mentioning that FILESETS *formerly*
had a settting of DIRECTORIES in its COMS, and I removed it. Now, ABC calls
SETDIRECTORIES after all the loadings, so it shouldn't matter how it got
set "during the interim" while finding the file to load.
Maybe Mike and the other sometime release masters should determine whether
the search path for editing <LispCore>Library> files should include a
<LispNew>Library> entry too? Currently there are no files there, but there
are files connected with sources and loadups on <LispNew>.
*start*
00499 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 11:55 PST
From: MGardner.pa
Subject: TEdit: Bravo Mistranslation
To: TEditSupport
cc: MGardner.pa
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dolphin
Bravo file didn't translate correctly into TEDIT. It lost all formating. The file is [ivy]<MGardner>AI>AI.RefReminder. I gave it the [indigo]<Alto>NPROG-user.cm since I didn't have a user.cm on this partition.
Mimi
*start*
00350 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 12:15 PST
From: Stansbury.pa
Subject: Lisp: DLIONFS
To: LispSupport.pa
cc: Lispcore^, Sheil
Lisp-System-Date: 15-Mar-84 11:06:37
Machine-Type: Dandelion
Have tested the version of the dlionfs Steve Gadol gave me Wednesday; still has B-tree problems.
-- Tayloe.
*start*
00549 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 MAR 84 12:21 PST
From: JONL.PA
Subject: Re: wish: DeviceIndependent New Page
To: MASINTER, LispSupport
cc: Kaplan, Burton, JONL
In response to the message sent 15 MAR 84 10:54 PST from MASINTER.PA
By analogy to FRESHLINE, this operation should be called FRESHPAGE.
Also, by "skip to the top of the next page (unless at the beginning of
the page already)", you must mean, for ordinary files (of type text, for
example), just outputting the formfeed character.
*start*
00601 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 13:31 PST
From: Sybalsky.pa
Subject: Lisp: For release & us, change to NS font access
To: LispSupport.pa
cc: Sybalsky.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
In the latest sysouts on Lispcore>Next, the way Lisp gets to NS fonts has changed. Instead of the variable STARFONTDIRECTORIES, there are now two variables, NSFONTDIRECTORIES and NSFONTWIDTHSDIRECTORIES.
There is a new INIT.CIS on <Lispcore>Sources> which is compatible with both worlds; it should be installed as soon as feasible.
*start*
00612 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 14:25 PST
From: Sannella.pa
Subject: TEdit: Bravo conversion
To: TEditSupport
cc: Sannella.pa
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 11:06:37
Machine-Type: Dolphin
Tried to TEdit a file and it decided that the file was in Bravo format, and prompted me with {phylum}<lisp>current>user.cm (a nice touch, since I have never in the past known what was supposed to be in the user.cm). I accepted its suggestion, but then it broke with file not found: {phylum}<lisp>current>user.cm. Oops!
-- Tayloe.
*start*
00694 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 14:36 PST
From: DMRussell.pa
Subject: Lafite: Section Delete!!!
To: LafiteSupport.pa
cc: DMRussell.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 13-Mar-84 10:21:31
Machine-Type: Dorado
On my machine, top-blank deletes all of the last section I've typed in. In Laurel, this was OKAY because by typing top-blank again, you got the deleted section back. THIS ISN'T TRUE in Lafite!!
I can't tell you the number of times I've gone to reach for BS, missed, and deleted a massive amount of text. Is there a way around this problem?? Can I get the lost text back into my window??
-- DMR --
*start*
00534 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 15:19 PST
From: Sybalsky.pa
Subject: Re: Lafite: Section Delete!!!
In-reply-to: DMRussell.pa's message of 16 Mar 84 14:36 PST
To: DMRussell.pa
cc: LafiteSupport.pa
I beg your pardon; top-blank is the UNDO key for TEdit. UNDO is undoable. However, the undo only works to a single level, so if you hit BS after UNDO, you're stuck.
I've submitted a suggestion to the TEdit queue that deletion be an accretive process as far as undo is concerned.
*start*
00551 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 15:20 PST
From: Sybalsky.pa
Subject: TEdit: deletion after UNDO of insertion should cumulate
To: TEditSupport.pa
cc: Sybalsky.pa
TEdit-System-Date: 16-Mar-84 10:14:01
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
Wish list entry for TEdit:
That hitting BS after UNDOing a massive insert shouldn't cause you to lose your inserted text. One way to do this is to have deletions add to one another if they are adjacent.... ANother is multi-level undo.
*start*
00410 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 15:17:09 PST (Friday)
From: Masinter.PA
Subject: Re: wish: DeviceIndependent New Page
In-reply-to: JONL's message of 16 MAR 84 12:21 PST
To: JONL
cc: MASINTER, LispSupport, Kaplan, Burton
This is a "DIG" feature. I dunno what it means for ordinary files.
(Please don't implement this until we have a consistent design.)
*start*
00442 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 15:17 PST
From: Kaplan.pa
Subject: Lisp: LISP.RUN versions?
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
I noticed that the creation date of <LISP>CURRENT>LISP.RUN is 1-Aug-83, while the creationdate of <Lispcore>Next>LISP.RUN is 15-Nov-83, much before the freeze date.
Did somebody forget to move something over?
--Ron
*start*
00644 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 15:56 PST
From: vanMelle.pa
Subject: Re: Lafite: TEdit format
In-reply-to: Stansbury.pa's message of 15 Mar 84 18:57 PST
To: Stansbury.pa
cc: LafiteSupport.pa
Lafite does so, but not because it noticed directly that the message was formatted--since there is formatting info in the composed forward form, Lafite asks whether to retain the formatting info when you bug Deliver, just as with any formatted message you compose. It should probably retain it automatically (i.e., explicitly insert the Format: line), but the current behavior is not bad.
Bill
*start*
00275 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 15:57 PST
From: vanMelle.pa
Subject: Re: Lafite: NEWMAILTUNE
In-reply-to: Denber.wbst's message of 15 Mar 84 12:29 EST
To: Denber.wbst
cc: LafiteSupport.pa
One has to run on a Dandelion.
*start*
00519 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 16:48:30 PST (Friday)
From: Masinter.PA
Subject: Re: AR#151, New function for release: COPYCHARS
In-reply-to: Sannella's message of 16 Mar 84 16:36:05 PST (Friday)
To: LispSupport
cc: Kaplan
This message should generate 3 ARs:
"Fix Lafite to use COPYCHAR to handle differing EOL", "Fix TEDIT to use COPYCHARS to handle differing EOL", and "Fix COPYFILE to use COPYCHARS to handle differing EOL".
Each with reference to AR#205.
*start*
00660 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 16:51:19 PST (Friday)
From: Masinter.PA
Subject: "workaround" for AR on IDATE on leapyears
To: lispsupport
----------------------------------------------------------------
Date: Fri, 16 Mar 84 13:13 PST
From: Bobrow.PA
Subject: Re: EMERGENCY QUESTION
In-reply-to: "Farrand.es's message of 16 March 1984 8:38 am PST (Friday)"
To: Farrand.es
cc: LOOPSCORE^.PA
Reply-To: Bobrow.PA
Fran,
If you load the file {PHYLUM}<LISP>SOURCES>DATEPATCH.DCOM, you will find that your TRUCKIN demo will run again.
danny
----------------------------------------------------------------
*start*
01372 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 16:52:06 PST (Friday)
From: Masinter.PA
Subject: AR release procedure
to: lispsupport
----------------------------------------------------------------
Date: 16 Mar 84 15:44:30 PST (Friday)
From: Masinter.PA
Subject: Re: LispNew -> Lisp
In-reply-to: Stansbury's message of 16 Mar 84 12:55 PST
To: Stansbury
cc: masinter, Sannella, LispCore^, Sheil
But it is true that we didn't have our act together.
At one time, we (LispCore^) kept better control of what sysout was on remote directories of our outside Lisp users. Right now, the status of [rose], [ivan], [igor], etc. is a mess.
If we kept control of the state of those directories, we would get fewer problems like the one Denber reported (he had gotten latest sysout but not latest microcode), and we would be able to put out patch releases without general broadcast of messages. The downside is that we will have users outside of PARC using inconsistent stuff.
It may be time to regularize the relations between LispSupport, 1100Support, and our users in Pasadena, ED/El Segundo, Rank, Henrietta. It is better if they are supported out of Pasadena if at all possible. It is OK if they are supported out of Palo Alto. It is not OK if they are not supported.
----------------------------------------------------------------
*start*
00595 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 17:04 PST
From: Kaplan.pa
Subject: Re: wish: DeviceIndependent New Page
In-reply-to: Masinter.PA's message of 16 Mar 84 15:17:09 PST (Friday)
To: Masinter.PA
cc: JONL.PA, LispSupport.PA, Kaplan.PA, Burton.PA
It means print a ctl-L for ordinary files--or do whatever is defined in their imageops vector.
We do need a design meaning to make sure that the DSPNEWPAGE interface will be general enough to support very kinds of scroll modes and such. We also need one to really pin down the units issue.
--Ron
*start*
01541 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 17:21:17 PST (Friday)
From: Masinter.PA
Subject: rs232 task
To: Sheil, Purcell
cc: LispSupport
The RS232 task (which we are considering for Mitch) should include VT100 emulation over RS232 lines. Here is Chris Halvorsen's description of what is necessary.
----------------------------------------------------------------
Date: 16 Mar 84 17:18 PST
From: halvorsen.pa
Subject: DSPVTS &RS232 MODEM
To: MASINTER
cc: halvorsen.pa
Larry,
Jonl is not in, but the situation with DSPVTS , as I understand it, is that it needs code to simulate an intelligent terminal. This is the small matter of programming, i.e. to see to it that the right functions get called when escape sequences come in from the host. I thought that there might simply be an a-list of escape sequences and screen operations, in which case implementing a new terminal type would be very simple, but that is not the case.
Furthermore, Jonl expressed the worry that certain screen operations on a Dlion, like clearing the screen, inserting a line etc. will take so long that the host will start sending "text" before the DLion has completed the screen operation since it believes it is talking to an intelligent which is faster at doing this. There is not buffering in DSPVTS, so characters sent while the DLION is busy would fall on the floor. Jonl suspected that you might not be able to run faster than 300 baud. There is obviously something here which could need some work.
*start*
01447 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 17:28:02 PST (Friday)
From: Masinter.PA
Subject: TCP/IP request
To: LispSupport
cc: Sheil
Add to AR on TCP/IP. Is it possible that they could obtain the 2060 ethernet driver?
----------------------------------------------------------------
Received: from UTEXAS-20.ARPA by PARC-MAXC.ARPA; 16 MAR 84 16:48:32 PST
Date: Fri, 16 Mar 84 18:47:58 CST
From: Gordon Novak Jr. <CS.NOVAK@UTEXAS-20.ARPA>
Subject: Babble
To: Masinter.PA
cc: CS.NOVAK@UTEXAS-20.ARPA
Larry,
As I mentioned to you a few weeks ago, we have 3 Dandelions, but they
are sitting high and dry and can't talk to anything, despite the fact
that we have a 2060 with Chaosnet and a VAX/UNIX with a 10MB Ethernet
running TCP/IP, not to mention RS232. It was my understanding that
Xerox was working on TCP/IP support, but now I hear that TCP/IP is
being done by a grad student at Berkeley in his spare time. Can
anything be done to raise the priority of TCP/IP and get it done by
a real wizard in real time and supported? Folks at Texas plan to buy
lots of Lisp machines (probably over $1 million this year), but it is
hard to convince them to buy machines that can't talk to anything that
already exists. MCC is potentially a large market too -- I hear they
have a contract for 40 Symbolics machines.
Thanks, Gordon
-------
----------------------------------------------------------------
*start*
01372 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 17:39 PST
From: Kaplan.pa
Subject: Re: Bitmaps
In-reply-to: Raim.pasa's message of Thu, 15 Mar 84 17:06 PST
To: Raim.pasa
cc: Lispsupport, Burton.PA, VanOrden.pasa
I don't think there is a written description of the symbolic representation of a bitmap, so I will try to describe it here.
LISPSUPPORT: This should probably generate an AR for the implementors guide.
A bitmap is represented symbolicly as a list of the form
(width height line1 line2 line3 ... lineheight)
where width and height are integers indicating the number of pixels in the bitmap, and line1 ... linen are strings (each enclosed in double quotes) of characters representing the width bits in each line.
The characters in the line strings each encode 4 bits of the line, with the 4 bits encoded by a character c determined by taking subtracting the character code of @ from the character code of c. Thus, @ encodes 0000, A encodes 0001, B encodes 0010, etc. up to O. We did it with this half-dense encoding so as to avoid characters with any special properties on lisp symbolic files.
An example:
(8 2 "@B" "CF")
These s-expression representations are simply printed on the file by PRINTBITMAP and the bitmaps command, and read and converted back to a real bitmaps by READBITMAP.
Hope this helps.
Ron
*start*
00574 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 17:39:44 PST (Friday)
From: Masinter.PA
Subject: Re: Shulman
In-reply-to: Your message of 15 Mar 84 14:17:12 EST
To: LispSupport
cc: Kaplan
Things to do:
Put LLKEY (mouse/keyboard sources) and LLARRAYELT (array reference & hash) on some Maxc directory, set protection to Read access for world, and send pointer to Shulman@Rutgers
Submit AR on Release process, attn Raim: all files in LISP.SYSOUT and not in SMALL.SYSOUT should be on <Lisp>Library> released. CHAT apparently is not.
*start*
00287 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 17:44 PST
From: Kaplan.pa
Subject: Re: Shulman
In-reply-to: Masinter.PA's message of 16 Mar 84 17:39:44 PST (Friday)
To: Masinter.PA
cc: LispSupport.PA, Kaplan.PA
Why does Shulman need LLARRAYELT ?
*start*
00617 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 20:35:41 PST (Friday)
From: Masinter.PA
Subject: Re:
In-reply-to: Your message of 15 Mar 84 14:17:12 EST
To: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
cc: LispSupport
a) You will get LLKEY
b) PRINTOUT: thanks, will put into LispUsers. I am concerned about compatibility with Interlisp-10/VAX etc.
c) never saw the BITBLT report, please resend
d) You will get LLARRAYELT
e) we will attempt to add all of the packages not in SMALL but in LISP to the library
f) LispUsers packages are not priority, and tutorial aids are (I think).
*start*
00385 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 17:49 PST
From: Martin.pasa
Subject: Re: Lisp: InstallLispTool
In-reply-to: Sannella.pa's message of 16 Mar 84 16:44 PST
To: Sannella.pa
cc: LispSupport.pa, 1100Support.pa, JFung.pasa
Make sure you get the latest initial microcode from Purcell. It was a bug he fixed a couple of weeks ago.
Rick
*start*
00350 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 18:11 PST
From: Sybalsky.pa
Subject: Re: Lisp: TEdit: Hardcopy from TEditMenu
In-reply-to: Stansbury's message of 28 Feb 84 11:57 PST
To: Stansbury.pa
cc: LispSupport.pa, Lilly.pa
Expanded menu operations no longer steal the mouse, as of the next TEdit release.
*start*
00340 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 19:21 PST
From: Sybalsky.pa
Subject: Re: Lisp: TEdit stream Bin, then BACKFILEPTR loses (AR 126)
In-reply-to: Sannella.PA's message of 16 Mar 84 15:46:18 PST (Friday)
To: LispSupport.PA
cc: Sybalsky.pa
Seems fixed; will try to verify with DesRivieres.
*start*
00719 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 19:22 PST
From: Burton.pa
Subject: changes to display break package
To: LispSupport
cc: burton, VanMelle.pa
Inspecting a function in the display frame window now calls the editor in the broken process. Thus variables evaluated in the editor will be in the broken process. Bill: This still has TTYIN problem.
The windows associated with a break window are now attached to it via ATTACHWINDOW. This officially makes ATTACHEDWINDOW a system file.
Closing a break window now only aborts the associated process if it was in tty wait and the closed window was the tty window. This should stop many unwanted aborting.
richard
*start*
01189 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from RUTGERS.ARPA by PARC-MAXC.ARPA; 17 MAR 84 06:52:31 PST
Date: 17 Mar 84 09:48:20 EST
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: BITBLT's using a BITMAP as a texture
To: lispsupport.pa
cc: masinter.pa, SHULMAN@RUTGERS.ARPA
[This is a repeat of a previous message]
I have been trying to draw patterned (dashed, dotted, etc.)
lines using BITBLT with a BITMAP as the TEXTURE argument. It is not
working at all like I would expect. I seems that it places repeating
bitmaps at fixed intervals regardless of the bitmap size. It also
seems to take seemingly random cross sections of the given bitmap
(there is a line in the manual that alludes to something about
"intersections of the tiles" with a texture argument but I haven't
been able to figure out what that means.)
To me it would seem logical that if I wanted a (4 on, 2
off) dashed line of thickness 2 I would use a 6 x 6 bitmap that looked
like:
XXOOOO
XXOOOO
XXOOOO
XXOOOO
OOXXXX
OOXXXX
It doesn't work.
Can patterned lines be drawn and how would I do it (aside from
using DRAWCURVE to do a straight line)?
Jeff
-------
*start*
00472 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 17 MAR 84 12:57 PST
From: JONL.PA
Subject: Re: Lisp: For release & us, change to NS font access
To: Sybalsky, LispSupport
cc: JONL
In response to the message sent 16 Mar 84 13:31 PST from Sybalsky.pa
You said "there is a new INIT.CIS on <Lispcore>Sources> ..." -- I think
you meant to say "... on <Lispcore>Next>". I've also updated the
INIT.KSALISPCORE accordingly on <Lispcore>Next>.
*start*
00418 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 17 Mar 84 13:19 PST
From: Sheil.pa
Subject: Lisp: USERNAME/SETINITIALS
To: LispSupport.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dolphin
In the current FULL, my usernme comes up set to SHEIL.PA, after which the call to SETINITIALS in my GREET file no longer works (expecting to find my username set to 'SHEIL (no .pa)).
Beau
*start*
00588 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 17 Mar 84 15:29 PST
From: JonL.pa
Subject: Lisp: minor bug fixes to SINGLEFILEINDEX
To: LispSupport.pa
cc: JonL.pa,Tong.pa
Lisp-System-Date: 7-Mar-84 13:56:45
Machine-Type: Dorado
I fixed a number on minor bugs in SINGLEFILEINDEX -- particularly in the cases of RELATIVEINDEXFLG = BOTH and when the mergedIndexFlg argument to SINGLEFILEINDEX is non-null (but there are others too). New version is on {Phylum}<LispCore>Library>; if it survives internal testing, it ought to be moved over to <Lisp>Library>.
*start*
00552 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 17 Mar 84 16:11 PST
From: desrivieres.pa
Subject: Lisp: CHAT and X3DolphinLisp.eb
To: LispSupport.pa
cc: desrivieres.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dolphin (with 3 and 3mb ethernet)
I have had no luck CHATting to any of PHYLUM, INDIGO, IVY, and MAXC when using my Dolphin with the combination 3/10 ethernet (lisp/z X3DolphinLisp.eb/m). It worked fine with both the regular and the pure-10mb configurations (lisp XMBDolphinLisp.eb/m).
---Jim
*start*
00631 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 17 Mar 84 17:44 PST
From: stansbury.pa
Subject: Lisp: Language: Monitor Locks
To: LispSupport.pa
cc: vanMelle
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
If I understand monitor locks correctly, if you want to protect some global resource from simultaneous access by competing processes, you have to wrap each piece of code which uses the global resource in a with.monitor.
This strikes me as the wrong way round: it would seem much safer if you could mark the resource once, rather than mark each piece of code that uses it.
-- Tayloe.
*start*
01254 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 17 Mar 84 17:45 PST
From: Kaplan.pa
Subject: Re: Maxwell's AR on WHEREIS not working for him
To: LispSupport.pa, Burton
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
I figured out why Maxwell was having trouble using WHEREIS.
The problem is that the initial value of the variable that names the whereis database file is something like <LISPUSERS>WHEREIS.HASH, i.e., it doesn't have a host in the name.
Maxwell is usually connected to IVY, hence for him it doesn't default to {Phylum}<LISPUSERS>WHEREIS.HASH.
It presumably would also fail if I were connected to {MAXC}--then it would find the pdp-10 format hashfile on lispusers there.
One fix is to take <LISPUSERS> out of the name, and do an explicit search (via FINDFILE) using the value of LISPUSERSDIRECTORIES.
The other fix is to let the current value stand as an INITVARS in WHEREIS, but also define this variable as one of the ones that ought to be set in the site-greeting file, presumably with an ADDVARS. In the latter case, INIT.CIS and INIT.KSA would have to be editted.
I'm not sure what's the best solution, given the current code, etc. Why don't you make the deciding vote, Richard.
--Ron
*start*
00492 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 17 MAR 84 21:02:01 PST
Redistributed: Xerox1100UsersGroup^.PA
Date: Sat, 17 Mar 84 20:36:10 PST
From: Eric Schoen <Schoen@SUMEX-AIM.ARPA>
Subject: Common Lisp compatibility
To: 1100users@SUMEX-AIM.ARPA
Has anyone out there tried mechanized translation of Interlisp programs
to Common Lisp? Does anyone know of any TRANSOR forms for Common Lisp
or MacLisp?
Eric
-------
*start*
01551 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 00:05 PST
From: JonL.pa
Subject: Lisp: New AARITH, and speed-up for some generic arith fns
To: LispSupport.pa
cc: JonL.pa, vanBuer%USC-ECL@SRI-NIC
Lisp-System-Date: 7-Mar-84 13:56:45
Machine-Type: Dorado
I've incorporated some polynomial approximations suggested by Darrel vanBuer into the functions of AARITH, and put a substantially new file on <LispCore>Sources> -- the old linear-interpolation kludge is now gone, along with its infamous inaccuracy.
Note: there was a bug in the former ARCTAN2 in that (ARCTAN2 -3 1) returned a value out of the range. Also the arguments X and Y were reversed, so I fixed them to accord with the manual.
There is an undocumented function ATAN on AARITH which looks like someone's botched attempt to copy the PDP-10 MacLisp version. I've supplied a correct translation (from the machine language, glaaag!), but I suspect that this one just ought to be deleted (Masterscope finds no system callers of ATAN). Aside from everything else, it appears to duplicate the functionality of ARCTAN2.
I've also fixed a glitch in several of the generic arithmetic functions (ABS, PLUS, MINUS, and TIMES) whereby they forced the "hard case" of a microcoded floating point operation. By changing, e.g. (FDIFFERENCE 0 X) into (FDIFFERENCE 0.0 X), forms like (ABS 3.4) and (TIMES <fp-number1> <fp-number2>) were speed up by a factor of from 2 to 5. [This doesn't apply to the DLion yet, since it doesn't have floating-point in ucode].
*start*
00566 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 MAR 84 00:51 PST
From: MASINTER.PA
Subject: want VT-100 emulation thru Chat, RS232, NS SPP
To: LispSupport
Many of our customers want clean, well documented, uniform access to terminal emulation for a variety of terminals. VT100 seems to be one of the more popular ones.
They want the interface to these services to be uniform, no matter whether you are going out thru a CHAT window or a RS232 window or one thru the (currently unimplemented in Lisp) NS services dial-out service.
*start*
00657 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 MAR 84 00:54 PST
From: MASINTER.PA
Subject: Please submit AR: want compiler to coerce constant args to floating fns. to floatp
To: LispSupport
cc: JonL
Currently compiled code for (FPLUS X 3) and the like emit a fixed-point 3 as the arg to the FPLUS opcode.
Unless the floating microcode on our machines is extended, this is much slower than if the compiler emitted (FPLUS X 3.0).
(I don't know if the 'fix' is to require more microcode to auto-float the arguments or to change the compiler. I suspect the fix is to extend the microcode, at least on Dorado and DLion.)
*start*
00507 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@From: kaplan.pa
Date: 18-Mar-84 9:31:15 PST
Subject: Floating arith optimizatio
To: lispsupport
Re: JonL's fix to floating point functions:
Seems like it should have been unncessary for JonL to replace
(FDIFFERENCE 0 X) with (FDIFFERENCE 0.0 X) in order to to get a 2-5 speed up.
This is something the compiler should do as an obvious optimization: Convert all constant arguments to floating point functions into floatp's.
--Ron
*start*
00618 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 10:52 PST
From: Sannella.pa
Subject: [Masinter.PA: Re: AR 147: Compiler substitutes fields in FETCH]
To: LispSupport
----- Forwarded Messages -----
Date: 16 Mar 84 16:52:29 PST (Friday)
From: Masinter.PA
Subject: Re: AR 147: Compiler substitutes fields in FETCH
In-reply-to: Your message of 16 Mar 84 15:55:55 PST (Friday)
To: Sannella
cc: desRivieres
Priority: Unlikely.
Workaround: do not use formals in OPENLAMBDA which are the same as any token other than an identifier.
----- End of Forwarded Messages -----
*start*
01387 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Sender: Sannella.PA
Date: 18 Mar 84 13:41:01 PST (Sunday)
Subject: Re: SETDIRECTORIES on [phylum]<LispCore>Sources>ABC has wrong entries
To: Sannella.pa
From: JONL.PA
----------------------------------------------------------------
Date: 16 MAR 84 11:52 PST
From: JONL.PA
Subject: Re: SETDIRECTORIES on [phylum]<LispCore>Sources>ABC has wrong entries
To: masinter, LispSupport
cc: JONL
In response to the message sent 14 Mar 84 20:14 PST from masinter.pa
SETDIRECTORIES is on FILESETS, not ABC.
<LispCore>LispUsers> is for those <LispUsers> files that must be coordinated
with a particular release.
Not sure what you think is the problem with the resetting of DIRECTORIES --
see my msg dated 13 MAR 84 20:00 PST mentioning that FILESETS *formerly*
had a settting of DIRECTORIES in its COMS, and I removed it. Now, ABC calls
SETDIRECTORIES after all the loadings, so it shouldn't matter how it got
set "during the interim" while finding the file to load.
Maybe Mike and the other sometime release masters should determine whether
the search path for editing <LispCore>Library> files should include a
<LispNew>Library> entry too? Currently there are no files there, but there
are files connected with sources and loadups on <LispNew>.
----------------------------------------------------------------
*start*
00935 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 MAR 84 21:45 PST
From: ROACH.PA
Subject: READ, OPENSTRINGSTREAM, & RDTBL PROBLEMS
To: LISPSUPPORT
cc: ROACH
Do the following:
(SETSYNTAX '$ '(MACRO FIRST NONIMMEDIATE ESCQUOTE FOO))
(DEFINEQ (FOO (LAMBDA (STREAM RDTBL)
(LIST 'BAR (READ STREAM RDTBL)))))
(SETQ STRING "$MEEF")
(SETQ STREAM (OPENSTRINGSTREAM STRING))
Then (READ STREAM) produces (BAR (BAR MEEF)) instead of the expected
answer (BAR MEEF). Suppose FOO had been
(DEFINEQ (FOO (LAMBDA (STREAM RDTBL)
(PRINT 'EEK T)
(LIST 'BAR (READ STREAM RDTBL)))))
Then (READ STREAM) would have produced (BAR EEK (BAR EEK MEEF)).
If instead of printing EEK, FOO printed (GETFILEPTR STREAM), then
(READ STREAM) would have produced (BAR 0 (BAR 1 MEEF)).
One source of problems: FOO is being passed the fullname of
STREAM (i.e. "$MEEF") rather than STREAM itself.
Kelly
*start*
00995 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 9 Mar 84 14:11 PST
From: Kaplan.pa
Subject: Re: READ, OPENSTRINGSTREAM, & RDTBL PROBLEMS
In-reply-to: ROACH.PA's message of 8 MAR 84 21:45 PST
To: ROACH.PA
cc: LISPSUPPORT.PA
Yes the user function is deliberately being passed the fulname of the file, instead of the stream. This was done originally because user functions might not be prepared to handle stream arguments, and might be doing outragious things to them like packing chars on, STRPOS etc.
In the case of the string stream, this is obviously a mistake, since the stream created by OPENSTRINGSTREAM is not cached in the open file table. A new stream is then created and cached with the fullname (= the string) is passed in to READ.
I'm willing to change the specs so that the macro function gets the stream, and hope that it doesn't cause lots of incompatibilities. This is another step on the migration from filenames to streams.
Opinions?
--Ron
*start*
00448 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 9 MAR 84 15:22 PST
From: ROACH.PA
Subject: Re: READ, OPENSTRINGSTREAM, & RDTBL PROBLEMS
To: Kaplan, ROACH
cc: LISPSUPPORT
In response to the message sent 9 Mar 84 14:11 PST from Kaplan.pa
A second anomally (I think) in my bug report was that if you
print to the T stream during the middle of the READ, what you printed
showed up in what you read.
Kelly
*start*
00414 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 9 MAR 84 17:59 PST
From: JONL.PA
Subject: Re: READ, OPENSTRINGSTREAM, & RDTBL PROBLEMS
To: Kaplan, ROACH
cc: LISPSUPPORT, JONL
In response to the message sent 9 Mar 84 14:11 PST from Kaplan.pa
Definitely!
Feed all internal functions, including user-settable macrocharacter functions,
the STREAM rather than any "name" for it.
*start*
00480 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 9 MAR 84 18:13 PST
From: ROACH.PA
Subject: Re: READ, OPENSTRINGSTREAM, & RDTBL PROBLEMS
To: JONL, Kaplan
cc: LISPSUPPORT, ROACH
In response to the message sent 9 MAR 84 17:59 PST from JONL.PA
I also think that all system code should be using STREAMs rather
than FULLFILENAMEs as file handles. This is necessary if we are ever
to have more than one stream reading the same file.
Kelly
*start*
00613 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 9 MAR 84 20:32 PST
From: JONL.PA
Subject: Re: READ, OPENSTRINGSTREAM, & RDTBL PROBLEMS
To: Kaplan, ROACH
cc: JONL, LISPSUPPORT
In response to the message sent 9 Mar 84 19:15 PST from Kaplan.pa
Grumble, do you realize what kind of task you are taking on? Interlisp-10
doesn't have STREAMs, and the kludgy patch-up in DCODEFOR10 which uses
JFNs isn't general enough.
pdp-10, R.I.P. ? and shared code too?
Would it be satisfactory for READ simply to pass to the macrochar function
just exactly the argument that it received?
*start*
00326 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 9 Mar 84 19:15 PST
From: Kaplan.pa
Subject: Re: READ, OPENSTRINGSTREAM, & RDTBL PROBLEMS
In-reply-to: ROACH.PA's message of 9 MAR 84 18:13 PST
To: ROACH.PA
cc: JONL.PA, Kaplan.PA, LISPSUPPORT.PA
OK, I'll do it, and we'll all take the heat.
--Ron
*start*
02877 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 13:06:35 PST (Sunday)
From: Sannella.PA
Subject: Re: Many questions and comments from Jim Goodwin
In-reply-to: masinter's message of 16-Mar-84 1:41:52 PST
To: LINKOPING@BBNG.ARPA
cc: masinter, LispSupport, Raim.pasa
reply-to: LispSupport
Hello. I am currently working within the Interlisp-D support group, trying to establish an "AR" database of bug reports, proposed features, etc. Larry Masinter forwarded your message (of Thu, 15 Mar 84) to me, saying "Extract as many ARs as you can, and send summary back to Goodwin with as many replies as you can to his questions."
Looking through your message, I found that your questions were not specific enough for me to extract any bug reports. Let me try answering them as well as I can....
----
"The relation between Interlisp and the file server is unsatisfactory at several points. <<<what problems have you found, specifically>>> This does not worry me particularly on the assuumption that it will be fixed eventually, but I have not yet found anyone who can say "Yes, we're working on that" or how it will look whenn fixed.
Doing a directory of something like <LISP> takes much too long.
Doing a directory of <LISP>FOO.* takes just as long."
Improving the performance of Interlisp in its use of NS file servers is a high-priority item within the Interlisp support group.
-----
"MAKEFILE, TEDIT, and many other operations fail, crash, and go wrong due to the lack of a random access protocol. Will our file server eventually support random access?"
Eventually, the file server should be able to support random access. The Interlisp-D support group does not have much control over that that (although we have tried to emphasize the importance of random access). A temporary fix that we are working on is to automatically copy files onto the local machine when dealing with a non-random access file server.
-----
"Will there ever be a release of Fugue/Carol etc which is fully interrupt driven?"
What do you mean? What do you want to do that you can't do now?
-----
"Will there be an acceptable text-editing and document handling facility any time soon? TEDIT is not one in its present state. I would not object to it at all if I were told that it is just the current version of a program being developed further, and that one could expect major improvements this year."
Do you mean that Tedit is not acceptable because you cannot use it with your non-random access file servers, or are you saying that even if this problem was solved, that Tedit would not provide acceptable functionality? What would be "an acceptable text-editing and document handling facility" to you? Tedit will containue to be developed, and its formatting facilities improved. We welcome input from users about what features are needed.
*start*
00731 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 15:53 PST
From: Sheil.pa
Subject: Lisp: Window: WIDTH property
To: LispSupport.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dolphin
Thw WIDTH windowprop is apparently calculated from the display stream clipping region, not the window size, so it is incorrect (i.e. neq the width of the region - the border) when the corresponding display stream is being clipped.
This is an arguable design, but it deserves documentation if it is an intentional feature.
(I would expect HEIGHT has the same property, but REGION does not).
[Note: There is a paren typo in the manual page that documents this at "not settable by WINDOWPROP"]
BEAU
*start*
00439 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 15:17 PST
From: Stansbury.pa
Subject: TEdit: Scroll bars
To: TEditSupport
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
Select TEdit in the backgroundmenu, Get a file, and bring up a scroll bar. No shaded region indicating where you are in the file appears until you have scrolled once.
-- Tayloe.
*start*
00946 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 13:11 PST
From: Sannella.pa
Subject: [JONL.PA: Changes to FPLUS, FTIMES]
To: LispSupport
----- Forwarded Messages -----
Date: 14 MAR 84 06:00 PST
From: JONL.PA
Subject: Changes to FPLUS, FTIMES
To: MASINTER
cc: VANMELLE, LISPCORE^
Current loadup attempt from LispCore>Sources dies underneath some FTIMES calls
(in function LOGOW, trying to layout the "snail"). I edited LOGOW so that it
didn't do the "hard" case of FTIMES, but now it dies underneath SIN, calling
FREMAINDER.
Could it be that the UFNs for these guys you changed recently are schrod?
I've left the "corpse" on Plaza, which is connected to the terminal in
1623. It was sort of in a half-way WINDOWworld state, and I called RAID
manually to see what was going on.
Maybe one of you could look at it before someone else snatches Plaza.
----- End of Forwarded Messages -----
*start*
01044 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Mar 84 20:34 PST
From: masinter.pa
Subject: more on FPLUS, FTIMES
In-reply-to: JONL.PA's message of 14 MAR 84 06:00 PST
To: JONL.PA
cc: MASINTER.PA, VANMELLE.PA, LispSupport
(To: LispSupport, AR for Documentation/Implementors Guide: Document this stuff)
I suspect the problem is that the variable \OPCODES is duplicated on more than one file, and that I changed it on one file and not on the other. I dunno where or why the duplication, but am searching.
(MORE)
I now believe the problem is that \OPCODES got copied to RDSYS during RENAMEFNS(R). It is actually the case that whenever any of a given set of files which RENAMEFNS(R) renames changes, that the rename should be redone.
RDSYS didn't used to be loaded as part of the init process. Another way of isolating the problem is to change the loadup script to
(SETQ SYSOUT (MAKEINIT --))
(load in RDSYS )
(DLFIXINIT SYSOUT --)
i.e., to make sure that RDSYS doesn't interfere with the MAKEINIT files.
*start*
00974 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 13:48 PST
From: Sannella.pa
Subject: [JONL.PA: Re: opcodes list reconstructed, new loadups on <LispCore>Next>]
To: LispSupport
----- Forwarded Messages -----
Date: 16 MAR 84 11:36 PST
From: JONL.PA
Subject: Re: opcodes list reconstructed, new loadups on <LispCore>Next>
To: masinter, LispCore^
cc: JONL
In response to the message sent 15 Mar 84 01:17 PST from masinter.pa
What *was* the problem with the \OPCODES list? Will it still be
a good idea to change the loadup script to do the MAKEINIT first and
then load in RDSYS and call DLFIXINIT ?
-----
Date: 16 Mar 84 12:56:57 PST (Friday)
From: Masinter.PA
Subject: Re: opcodes list reconstructed, new loadups on <LispCore>Next>
In-reply-to: JONL's message of 16 MAR 84 11:36 PST
To: JONL
cc: masinter, LispCore^
see AR#138, "fix MAKEFILE(LLCODE) to remind to DORENAME(R)"
----- End of Forwarded Messages -----
*start*
01220 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 10:42 PST
From: Sannella.pa
Subject: [Burton.pa: Re: Changes to FPLUS, FTIMES]
To: LispSupport
----- Forwarded Messages -----
Date: 16 MAR 84 10:59 PST
From: JONL.PA
Subject: Re: Changes to FPLUS, FTIMES
To: masinter, JONL
cc: VANMELLE, LISPCORE^
In response to the message sent 14 Mar 84 19:58 PST from masinter.pa
For the record ---
The suspicion of bug was *** not *** that something was wrong with FTIMES --
it was that the punt case was being called. No doubt it was called previously,
but there is no need for LOGOW to require that.
-------
Date: 16 Mar 84 15:44 PST
From: Burton.pa
Subject: Re: Changes to FPLUS, FTIMES
In-reply-to: JONL.PA's message of 16 MAR 84 10:59 PST
To: JONL.PA
cc: Sheil, LISPCORE^.PA
I deleted the new version of window that you put on <lispcore>sources>.
I feel that your change to LOGOW was out of line. LOGOW could NOT have been the cause of the problem since it had not changed since the system last worked. In addition, your "fix" did not correct a bug, it just changed the code to work according to your tastes.
Richard
----- End of Forwarded Messages -----
*start*
00860 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 11:23 PST
From: Sannella.pa
Subject: [JONL.PA: Re: Changes to FPLUS, FTIMES]
To: LispSupport
----- Forwarded Messages -----
Date: 17 MAR 84 13:42 PST
From: JONL.PA
Subject: Re: Changes to FPLUS, FTIMES
To: Burton, JONL
cc: Sheil, LISPCORE^
In response to the message sent 16 Mar 84 15:44 PST from Burton.pa
Dick, your comments in this message are out of line.
The change I made was in order to get the loadup to go one step further
from the point whereat it died. This had absolutely nothing at all to do
with my "tastes".
I never suggested that the change to LOGOW need be kept. After Larry found
and fixed the bug he introduced into the loadup procedure, then it is
possible to fall back on the former code.
----- End of Forwarded Messages -----
*start*
00688 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 13:46 PST
From: Sannella.pa
Subject: [JONL.PA: Re: Changes to FPLUS, FTIMES]
To: LispSupport
----- Forwarded Messages -----
Date: 16 MAR 84 10:59 PST
From: JONL.PA
Subject: Re: Changes to FPLUS, FTIMES
To: masinter, JONL
cc: VANMELLE, LISPCORE^
In response to the message sent 14 Mar 84 19:58 PST from masinter.pa
For the record ---
The suspicion of bug was *** not *** that something was wrong with FTIMES --
it was that the punt case was being called. No doubt it was called previously,
but there is no need for LOGOW to require that.
----- End of Forwarded Messages -----
*start*
00518 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 09:48 PST
From: Sheil.pa
Subject: Lafite: BAD.STATE. FOR.BOUT under GETNEWMAIL
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dolphin
Stack is GETNEWMAIL...GV.CLOSEMAILBOX; MS.RETRIEVEOP; \BOUT. Bad state is on a BSP stream, not the mail file being written to.
During the retrieve, Phylum hung for a while, so it may have timed out. I could not proceed it.
Beau
*start*
00426 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 16:01 PST
From: vanMelle.pa
Subject: Re: Lafite: BAD.STATE. FOR.BOUT under GETNEWMAIL
In-reply-to: Sheil.pa's message of 16 Mar 84 09:48 PST
To: Sheil.pa
cc: LafiteSupport.pa
Yes, this should probably just quietly abort itself. You can in general ^ out of such breaks. I'll fix the Grapevine code to be a little friendlier here.
Bill
*start*
00802 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 09:53 PST
From: JonL.pa
Subject: Lisp: Break under FONTCREATE under DEDIT
To: LispSupport.pa
cc: JonL.pa, Sheil.pa
Lisp-System-Date: 7-Mar-84 13:56:45
Machine-Type: Dorado
Frequently, but not reliably, I land up in this condition while trying to scroll a DEdit window. Stack above error (minus ERRORSET and \EVALFORM frames) looks like:
\ILLEGAL.ARG
FONTCREATE ["FAMILY" arg is PURGED, others are NIL]
\COERCEFONTDESC
\DTESTFAIL
HIPT [arg looks like a MAP entry]
REFRESHIF1 [about a dozen copies of this frame]
DEDITREPAINTFN ["R" arg is (0 60961 572 372)]
DOUSERFNS2
REDISPLAYW
SCROLLBYREPAINTFN
SCROLLW
\SCROLL.HANDLER.DOIT
SCROLL.HANDLER
WINDOW.MOUSE.HANDLER
\MOUSE.PROCESS
\MAKE.PROCESS
T
*start*
00455 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 10:30 PST
From: Sheil.pa
Subject: Re: Lisp: Break under FONTCREATE under DEDIT
In-reply-to: JonL.pa's message of 16 Mar 84 09:53 PST
To: JonL.pa
cc: Lispsupport
This particular symptom is fixed in an upcoming maintenance release.
However, I'd love to have a repeatable example since (altho the new code will recover) it does indicate a screw loose somewhere.
Beau
*start*
00445 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 15:08 PST
From: Stansbury.pa
Subject: Lisp: Implmanual.tedit
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
The current implmanual (on lispcore) does not mention \allocblock. What do all the args do? In particular, does the first arg tell the number of 1-word or the number of 2-word cells you want in the block?
-- Tayloe.
*start*
02972 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:36:40 PST (Thursday)
From: JFung.pasa
Subject: Adobe Usage
To: MASINTER.PA
cc: LE, Sannella.PA, Raim, 1100Support, LispSupport.pa, JFung
Larry,
I have some suggestions toward using Adobes.
I made up the following persons and their roles on playing Adobe and their responsible fields.
1. Submitter/Source
2. Screener
3. Desinger/Implementator ("Assigned to")
4. Test Acceptance person
First, I think we have "submitters" who submit AR, and we aslo need to have "screeners" who SCREEN these AR and assign them to the responsible person and adjust any improper assignments made by "submitters".
The submitters and source (people forward AR to submitters) should try to fill out as many fileds as possilbe in Adobe-Submit window.
We then have "screeners" who assign this AR to assigned person. (I think when submitters gain experience, then we dont need screeners, and Assigned To person can change improper assignments when they see fit.)
I. SUBMITTERS: (Le.pasa, Sannella.pa)
Responsbible for following fileds: (Suggest mandatory, all fields should be filled)
Source:
System{}/Subsystem{}
Machine{}/Disk{}
Status{New, Wish, Incomplete}. (These are the only values they should use as submitters.)
Subject:
Lisp Version:
Problem Type{}
Frequency{}
Impact{} (please dont get upset by this selection, it is a judgement call from user and may very well differ from designer/implementator's view)
Description:
I would say if any filed from above are missing, the submitter should turn it away. Else the screeners should say Status{Incomplete}
The folowing fields should be supplied if info is available:
uCode Verison:
Memory Size:
File Server{}
Server Software Version:
Test Case:
II. SCREENERS: (Masinter.pa)
The screeners should VERIFY all fileds entered are proper and assign AR to designers/implementators. (The Adobe.fields file have this information)
Responsible for following fields:
Assigned To:
and above fields supplied by Submitters.
III. DESIGNERS/IMPLEMENTATORS ("Assigned To"):
Responsible for following fields:
Difficulty{}
Priority{}
Workaround:
Attn:
Status{Open, Declined, Obsolete, Superseded, Wish, Fixed} *(restricted selection)
IV. TEST ACCEPTANCE PERSON: (1100Support in most cases, or source person if orignated from internal)
Whose responsibility is to verify "Fixed" ARs are indeed "Fixed" and change it to Status{Closed}. It he/she disagrees that it is fixed, then he/she changes it back to "Open"
Responsible for following fields:
Status:{Closed, Open}
In/By:
/Jerry
P.S. I have also suggested that we create the LispAR-Submit.Form for people to use(fill out) so they can just mail to Submitters. I think we might even give these forms to customers as guidelines for them to fill out bug-reports and ensure that WE have all the necessary information regaring a bug-report.
*start*
00863 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@From: masinter.pa
Date: 16-Mar-84 1:32:33 PST
Subject: Re: Adobe Usage
In-reply-to: JFung.pasa's message of 15 Mar 84 11:36:40 PST (Thursday)
To: JFung.pasa
cc: MASINTER, LE.pasa, Sannella, Raim.pasa, 1100Support.pasa, LispSupport
one thing in your message went by:
Impact: Fatal/Serious/Moderate/... is not entirely subjective; it is not how you feel about it. An AR can be Annoying or have Moderate impact, and yet be VERY IMPORTANT. Fatal means just that: you are going along and when this strikes, you lose work. Serious means that it slows you down, you hve to take some extra steps, etc. but it doesn't crash your system etc.
So there are objective criteria.
You left out the "Priority" field. Its setting, if we are going to take it seriously, is a subject of some negotiation.
*start*
01100 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Mar 84 00:45 PST
From: Halasz.pa
Subject: Lisp: Carol (Mar 1) Cannot be loaded from Floppies
To: LispSupport.pa
cc: Halasz
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dandelion
Here's a puzzler. If I load <lisp>current>full.sysout or <lispcore>next>full.sysout from PHYLUM using Othello, everything works fine. However, it does not work if I take either file and write it to floppies using either a COPYFILE or a SYSOUT method, and then install on a DLion using the InstallTool. When I use the floppies, everything runs until I try to access Phylum using either CHAT or a DIR command or I try to start Lafite using a Phylum active mail file. At this point, the DLion invariably bomb into RAID (9915) under \RTP.SOCKET.PROCESS with a \UNKNOWN.UFN error.
The stack looks like:
1: RAID
2: \UNKNOWN.UFN
3: NIL
4: \RTP.SOCKET.PROCESS
5: \EVALFORM
6: \EVAL
7: ERRORSET
8: \MAKE.PROCESS0
9: T
What gives??? This is very, very annoying since it means one cannot transport the Carol release via floppies.
Frank
*start*
00767 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 12:42 PST
From: Martin.pasa
Subject: Re: Lisp: Carol (Mar 1) Cannot be loaded from Floppies
In-reply-to: Halasz.pa's message of 10 Mar 84 00:45 PST
To: Halasz.pa, Roach.pa
cc: LispSupport.pa
I don't know if this relates to Frank's problem or not.
I also tried to do a COPYFILE of a sysout (from a dolphin running FTP) and on the third floppy, I got three consecutive RECORDNOTFOUND errors. I think this was shortly after formatting the floppy. I OK'd out of each of those Breaks (what else should I do?). The COPYFILE seemed to continue okay. However, the final sysout would only run for a couple of minutes.
I rebuilt the floppies in Tajo, and everything worked fine.
*start*
00434 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 MAR 84 15:18 PST
From: ROACH.PA
Subject: Re: Lisp: Carol (Mar 1) Cannot be loaded from Floppies
To: Martin.pasa, Halasz, Roach
cc: LispSupport
In response to the message sent 15 Mar 84 12:42 PST from Martin.pasa
I think I had a bug where one page per floppy was getting
garbaged. I haven't had a chance to check my fix yet though.
Kelly
*start*
00485 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Mar 84 16:44 PST
From: Sannella.pa
Subject: Lisp: InstallLispTool
To: LispSupport.pa, 1100Support.pa
cc: Sannella.pa, JFung.pasa
Lisp-System-Date: 15-Mar-84 11:06:37
Machine-Type: Dolphin
The Tajo provided with the InstallLispTool on the Installation Utility and Diagnostics Files floppies will not boot on a large microstore DLion: gets all the way up to MP 0990 and then dives into 0915.
-- Tayloe.
*start*
00605 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Mar 84 15:40 PST
From: desRivieres.pa
Subject: Lisp: Missing "-" on LispPrint: Terminal font
To: LispSupport.pa
cc: 3LispSupport^.pa
Lisp-System-Date: 5-Mar-84 16:21:20
Machine-Type: Dorado
I EMPRESSed a TEDIT-created file (without LOOKS) to LispPrint:. It was printed in a GACHA-like font (called TERMINAL) that has no "-" (55Q) character! Where can I get a description of the fonts on LispPrint: (and the set of fonts available for Ravens, so that I can make sure CSLI's printers will be properly equipped.)
---Jim
*start*
00778 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 12 Mar 84 15:24 PST
From: Sybalsky.pa
Subject: Re: Lisp: Missing "-" on LispPrint: Terminal font
In-reply-to: desRivieres.pa's message of 10 Mar 84 15:40 PST
To: desRivieres.pa
cc: LispSupport.pa, 3LispSupport^.pa
The TERMINAL font on LispPrint: does indeed have a "-" character in it -- but the character code for hyphen is NOT 55Q in the NS world.
MAKEINTERPRESS (which EMPRESS invokes to print on NS printers) now includes conversions from all of the ASCII characters that I am aware don't map straight into NS, including "-", "$",' "^", and "_". This will be in whatever new loadup happens next after now; however, any hyphens that should appear in page headings will not, for the time being.
*start*
00825 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 00:58 PST
From: desRivieres.pa
Subject: TEdit: Hardcopy to Lispprint:
To: TEditSupport
cc: desRivieres.pa
TEdit-System-Date: 1-Mar-84 13:54:34
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
When I Tedit HARDCOPY my files to Lispprint:, they are printed in the MODERN font. My files have no special looks, and I haven't changed TEDIT.DEFAULTFONT, so I expect it to display in font GACHA (or TERMINAL).
It might also be a good idea to provide some hooks to allow the user to indicate a substitute hardcopy family when going to an NS printer. Also, since MODERN seems to be the best-supported sans-serif font, it would be nice to have a .strike version of it (perhaps there already is something very similar to it?)
---Jim
*start*
00485 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 10:16 PST
From: Sybalsky.pa
Subject: Re: TEdit: Hardcopy to Lispprint:
In-reply-to: desRivieres.pa's message of 15 Mar 84 00:58 PST
To: desRivieres.pa
cc: TEditSupport.pa
There is no Gacha font on Lispprint; in the future, we MAY translate it to Terminal, but not for a while.
You CAN do a (Fontcreate 'modern 10)... While there is no .strike font, Lisp knows how to get to the NS font sets.
*start*
01218 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 13:16 PST
From: Sannella.pa
Subject: [Sybalsky.pa: Re: More on "Terminal"-font problems]
To: LispSupport
----- Forwarded Messages -----
Date: 14 Mar 84 13:09 PST
From: Sybalsky.pa
Subject: Re: More on "Terminal"-font problems
In-reply-to: Raim.pasa's message of Wed, 14 Mar 84 12:38 PST
To: Raim.pasa
cc: Sybalsky.pa, MASINTER.pa, Phillips.pasa, Sannella.pa, Kaplan.pa
You're the one who knows what the customers can live with; however, let's look at the possible needs:
--TEditing a document with Gacha 10 in it will print with modern in place of gacha; We could (kludge, kludge) put code in INTERPRESS to coerce Gacha into Terminal, and probably change 10-pt to whichever would be best. Still, if they can live without that, better.
--Creating your own interpress file, including references to Gacha 10 will have the same problem
--LISTFILES; if the font profile is changed to have Terminal 8 instead of whatever Gacha it has, this should work with the new INTERPRESS in place.
--EMPRESSing a random .tty file; same deal.
Let me know which way you want to go.
--John
----- End of Forwarded Messages -----
*start*
01555 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 13:13 PST
From: Sannella.pa
Subject: [Sybalsky.pa: More on "Terminal"-font problems]
To: LispSupport
----- Forwarded Messages -----
Date: 14 Mar 84 11:18 PST
From: Sybalsky.pa
Subject: More on "Terminal"-font problems
In-reply-to: MASINTER.PA's message of 13 MAR 84 22:52 PST
To: MASINTER.PA, Raim.pasa, Phillips.pasa, Sannella.pa
cc: sybalsky.PA, Kaplan.pa
Larry, Marty, Joan, Mike--
The problems people have been having with the "Terminal" font are due to software. Because Lisp uses ASCII and NS printers use the NS character set, we have to do some character conversions.
These conversions are needed at 3 places in the INTERPRESS code; the Fugue.6 release as of now has it in one of the three.
{Phylum}<Lispcore>Sources>INTERPRESS[.dcom] has all of the conversions in place. I was able to run listings, and the characters appeared everywhere they should. This code could be imported into the release, if the demand is great enough; it does not affect other parts of the system.
Ron--
I changed everything but APPENDIDENTIFIER.IP to do the conversion to NS charsets. Unfortunately, things like font names, e.g., "XEROX XC82-0-0 TERMINAL" want the hyphens to be ASCII hyphens! Since APPENDIDENTIFIER is the guy who emits those, I changed it to do no conversions. IP.PRIN3 et al noe CONVERT TO NS. There is also a function, NCHARS.IP, which returns the # of chars in the NS version of the string.
----- End of Forwarded Messages -----
*start*
00890 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 13:14 PST
From: Sannella.pa
Subject: [Raim.pasa: Re: More on "Terminal"-font problems]
To: LispSupport
----- Forwarded Messages -----
Date: Wed, 14 Mar 84 12:38 PST
From: Raim.pasa
Subject: Re: More on "Terminal"-font problems
In-reply-to: "Sybalsky.pa's message of 14 Mar 84 11:18 PST"
To: Sybalsky.pa
cc: MASINTER.pa, Raim, Phillips, Sannella.pa, Kaplan.pa
John,
Thank you for your thorough analysis of the problem. There are only a few sites that care about this problem, but they are up-in-arms over it. Your solution is timely. However, Terminal only exists in two sizes, 8 and 12, I believe. Can customers function with just these until we order 6 and 10? I'd rather not risk adding new Interpress.dcom unless the payoff is real.
--Marty
----- End of Forwarded Messages -----
*start*
00939 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 13:22 PST
From: Sannella.pa
Subject: [Sybalsky.pa: Re: More on "Terminal"-font problems]
To: LispSupport
----- Forwarded Messages -----
Date: 14 Mar 84 14:18 PST
From: Sybalsky.pa
Subject: Re: More on "Terminal"-font problems
In-reply-to: Raim.pasa's message of Wed, 14 Mar 84 13:48 PST
To: Raim.pasa
cc: Sybalsky.pa, MASINTER.pa, Phillips.pasa, Sannella.pa, Kaplan.pa
Then we have it. The font profile in the full.sysout I'm running in has only Modern and Terminal as interpress fonts.
I've run listings with that, and they seem reasonable, i.e., they include hyphens and arrows, at least.
So now the question: Do you want to make a new loadup with this INTERPRESS in it, or will you distribute this INTERPRESS as a patch to selected customers? If the former, we should let Mike Sannella know.
----- End of Forwarded Messages -----
*start*
00942 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 13:24 PST
From: Sannella.pa
Subject: [masinter.pa: Re: More on "Terminal"-font problems]
To: LispSupport
----- Forwarded Messages -----
Date: 14 Mar 84 17:28 PST
From: masinter.pa
Subject: Re: More on "Terminal"-font problems
In-reply-to: Sybalsky.pa's message of 14 Mar 84 14:18 PST
To: Sybalsky.pa
cc: Raim.pasa, MASINTER.pa, Phillips.pasa, Sannella.pa, Kaplan.pa
John, what I take this to mean is that the LISTFILES problem is solved in the current Carol.1/Fugue.6 problem.
If so, this would lead me to believe that the "tests" that Marty Raim and Joan Phillips ran in Pasadena may have been with a previous version of Interlisp-D.
Marty and Joan, can you confirm or deny this? Do you know what version of Interlisp-D you used. Alternatively, could you try a LISTFILES again with Carol.1/Fugue.6?
----- End of Forwarded Messages -----
*start*
00589 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 13:25 PST
From: Sannella.pa
Subject: [Sybalsky.pa: Re: More on "Terminal"-font problems]
To: LispSupport
----- Forwarded Messages -----
Date: 14 Mar 84 17:51 PST
From: Sybalsky.pa
Subject: Re: More on "Terminal"-font problems
In-reply-to: masinter.pa's message of 14 Mar 84 17:28 PST
To: masinter.pa
cc: Sybalsky.pa, Raim.pasa, Phillips.pasa, Sannella.pa, Kaplan.pa
Nyet. The LISTFILES problem is fixed in Fugue.6 after you load the new INTERPRESS.
----- End of Forwarded Messages -----
*start*
01506 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:35 PST
From: Sannella.pa
Subject: [Stansbury.pa: [JONL.PA: Did we forget this one for the release msg?]]
To: LispSupport
----- Forwarded Messages -----
Date: 12 Mar 84 15:14 PST
From: Stansbury.pa
Subject: [JONL.PA: Did we forget this one for the release msg?]
To: Sannella.pa
Cc: Jonl, Nuyens
You might want to stick this in the next release message.
-- Tayloe.
----- Forwarded Messages -----
Date: 9 MAR 84 20:10 PST
From: JONL.PA
Subject: Did we forget this one for the release msg?
To: Stansbury, Nuyens
Date: 7 Dec 83 07:43 PST
From: JonL.pa
Subject: additions to GENSYM -- RFC for name
To: Stansbury.pa
cc: LispCore^.pa
I added a function to the GENSYM file named
LITATOMPNAMEP
(for want of a better name). It take a string (or else, coerces
it's argument to a string) and then tells you how many probes
of the litatom hash table it takes to find the atom with that
pname; of course, if there is no such atom,. the result is NIL.
Interestingly, my rather bloated Lisp -- 23000 out of 32767
atoms 'used up' -- had an average probe chain length of only
2.35 (and standard deviation of 4.3). But just to show that
statistics can be very deceiving, our favourite atom had an
incredibly long look-up chain: FOO takes 153 probes! and
I probably type in more FOO's than all other atoms combined.
----- End of Forwarded Messages -----
----- End of Forwarded Messages -----
*start*
00779 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 11:41 PST
From: Sannella.pa
Subject: [JONL.PA: Re: [JONL.PA: Did we forget this one for the release msg?]]
To: LispSupport
----- Forwarded Messages -----
Date: 12 MAR 84 20:16 PST
From: JONL.PA
Subject: Re: [JONL.PA: Did we forget this one for the release msg?]
To: Stansbury, Sannella
cc: Nuyens, JONL
In response to the message sent 12 Mar 84 15:14 PST from Stansbury.pa
Uh, foo, the name that finally got "chosen" was ATOMHASH#PROBES.
I vaguely remember sending a msg to Gadol about this. Just happened
to stumble across the mail of the initial name -- LITATOMPNAMEP. Otherwise
the msg of 7 Dec describes ATOMHASH#PROBES well.
----- End of Forwarded Messages -----
*start*
01673 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 10:55 PST
From: Sannella.pa
Subject: [Kaplan.pa: Performance Certification]
To: LispSupport
----- Forwarded Messages -----
Date: 3 Feb 84 09:42 PST
From: Kaplan.pa
Subject: Performance Certification
To: Lispcore^, Sheil, Raim.pasa
We just came within a hair of releasing a brain-damaged system--and would have it hadn't been for JonL's benchmarking observations.
This suggests that we make performance certification an official part of our release process. We should automate the running of standard benchmarks so that the Release Master can easily compare the relative performance on the new and old systems. In fact, we should make sure that the results of the various benchmarks are captured in machine-readable form, so that the Release Master can be notified of any changes above some threshhold (e.g. 20% faster or slower, or 20% more or less conses, etc.)
Besides preventing us from making gross mistakes, this information should find its way into the release message:
1. If we find more than, say, a 20% improvement on something, we should broadcast that to our users, to maintain their rising expectations.
2. If we find a performance decrement of 20% and we can verify that it is not an error, than users can be told to expect this, and also told what clever trade-offs we made--what else got faster or better. Even if there is some bad news, it is better that we broadcast it in a controlled fashion indicating that we are on top of the situation rather than have users angrily discover it for themselves.
--Ron
----- End of Forwarded Messages -----
*start*
01505 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 12:57 PST
From: Sannella.pa
Subject: [vanMelle.pa: Re: Tedit continuous scrolling - my vote]
To: LispSupport
----- Forwarded Messages -----
Date: 13 Mar 84 11:10 PST
From: vanMelle.pa
Subject: Re: Tedit continuous scrolling - my vote
In-reply-to: Burton.pa's message of 6 Jan 84 13:46 PST
To: Sybalsky.pa, Burton.pa
cc: LispCore^.pa
I vote with Richard--Tedit should continuously scroll a line at a time, like everyone else. Having the scroll quantum determined by the vertical position in the scroll bar was an interesting experiment, but I just don't see it being a good feature, even substantially damped (as Richard proposes as a compromise). First, of course, it's incompatible with all the other windows in the system--I would have to be aware of what kind of window in order to know whether it cared where I was in the scroll bar. But more significantly, I find that it is hard to get slow scrolling--I absolutely must position myself very close to the top of the scroll bar, which is almost never where I am inclined to go. When I am scrolling thru a document, I typically position the cursor in the bottom half of the scroll bar in order to scroll thru in big chunks, up to a windowfull at a time. When I get to a part that I want to scroll slowly, I DON'T want to have to move to the top of the scroll bar; I just want to hold the button down.
Bill
----- End of Forwarded Messages -----
*start*
00485 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 13:27 PST
From: Sannella.pa
Subject: [masinter.pa: AR 51]
To: LispSupport
----- Forwarded Messages -----
Date: 14 Mar 84 18:37 PST
From: masinter.pa
Subject: AR 51
To: SANNELLA
cc:
I think that errors in documentation should be categorized under Documentation/Release Notes rather than Text/TTYIN. TTYIN isn't at fault, just the documentation.
----- End of Forwarded Messages -----
*start*
00707 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 15 Mar 84 15:11 PST
From: Sannella.pa
Subject: [masinter.pa: Re: Changes to FPLUS, FTIMES]
To: LispSupport
----- Forwarded Messages -----
Date: 14 Mar 84 19:58 PST
From: masinter.pa
Subject: Re: Changes to FPLUS, FTIMES
In-reply-to: JONL.PA's message of 14 MAR 84 06:00 PST
To: JONL.PA
cc: MASINTER.PA, VANMELLE.PA, LISPCORE^.PA
It seems unreasonable to edit LOGOW to fix a suspected bug in FTIMES, doesn't it?
I tried finding any problems with arithmetic in the INIT.DLINIT and haven't been so far. I will continue with the loadup again and see if I can make it happen again.
----- End of Forwarded Messages -----
*start*
00722 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 17:04 PST
From: desRivieres.pa
Subject: TEdit: SETFILEPTR moves caret
To: TEditSupport
cc: desRivieres.pa
TEdit-System-Date: 1-Mar-84 13:54:34
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
There is a minor inconsistency having to do with applying file operations to text streams (created with OPENTEXTSTREAM). In particular, SETFILEPTR causes the caret in the associated window to move, whereas the other non-writing operations, including GETFILEPTR, GETEOFPTR, READ, READC, PEEKC, and BIN do not. I'll leave you to judge whether this is what should happen --- I have no strong feelings one way or the other..
---Jim
*start*
00589 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 MAR 84 21:02 PST
From: MASINTER.PA
Subject: SETFILEPTR and caret
To: TEditSupport
cc: desRivieres
I think the MAJOR inconsistency of TEDIT streams and others is that BOUT to a TEDIT stream seems to INSERT characters rather than REPLACE them.
I think in lieu of really compelling reasons otherwise that that is a bad idea. If you are going to provide both REPLACE and INSERT operations, I would prefer that the BOUT stream operation be REPLACE and tht you provide for INSERT thru some other primitive.
*start*
00210 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 MAR 84 17:05 PST
From: MASINTER.PA
Subject: \ALLOCBLOCK 1st arg counts 32-bit (2 word) quanta
To: LISPSUPPORT
cc: Stansbury
*start*
00627 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 MAR 84 17:34 PST
From: MASINTER.PA
Subject: Want faster startup on standalone DLions
To: LispSupport
18 - *******************************************
From: lichtenberg.wbst
Date: 18-Mar-84 17:57:00 EST
Subject: Disabling network initialization
To: Masinter.pa, VanMelle.pa
Gentlemen:
Since my lone dandelion is not fortunate enough to have time, name, and pup translation servers to talk to during initialization, Interlisp takes a great deal of time looking for someone to talk to before giving up. Can I disable this?
Thanks,
/Mitch.
*start*
01042 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 MAR 84 17:40 PST
From: MASINTER.PA
Subject: Please enter AR: PROMPT#FLG yields confusing display when multiple processes have history events or under break
To: LispSupport
In the normal typin window, you can get a prompt of the form
16_
meaning that it is waiting for event 16. If another process breaks or otherwise goes thru LISPX, you get another prompt for the same event, e.g.
16:
If you do something in that other process (which can be spawned by something as simple as a mouse-click), and then go back to the executive window, you will still see the prompt for
16_
sitting there when in fact the event will be assigned a later number.
In brief: the event number is printed before the event, but doesn't actually get used up until after the event.
This wasn't a problem when there was a single typeout stream for event prompts. It is less an artifact of multiple processes than it is of multiple windows.
Bug, Annoying, Possibly, Intermittent.
*start*
00639 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 18:54 PST
From: Wallace.pa
Subject: Lisp: Interaction between titles and attached windows
To: LispSupport.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
I use attachwindows to put a small window below my TEDIT window. I then put a title on the small window. Because titles appear ABOVE their window, my title is obscured by its MAINWINDOW. It pops up disconcertingly whenever I interact with the small attached window.
Could the title's behaviour (whether it appears above the window or just inside it) be switch-controlled?
david
*start*
00861 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 19:00 PST
From: Nuyens.pa
Subject: release of LispUsers package FINGER
To: LispUsers^
cc: Nuyens.pa
Description:
Finger is a facility for determining and displaying information about other users running Interlisp-D. It displays the user's name, the Etherhostname (or the octal net address when no nameserver is available) and the user's idle time (time since last keystroke or mouseaction). Only other users who have the finger server loaded will be displayed. Users can specify the net radius to query, a list specifying only which users they want displayed, or similarly, only which hosts are to be displayed.
Finger is stored on {phylum}<lispusers>finger.dcom.
Documentation is {phylum}<lispusers>finger.tedit.
As always, comments and suggestions welcomed.
Greg
*start*
01829 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 19:35 PST
From: JonL.pa
Subject: AR41: READ problem identified for OPENSTRINGSTREAM
To: Kaplan.pa
cc: LispSupport.pa, Lispcore^.pa, DesRivieres.pa, JonL.pa
In-Reply-To: your msg of 16 Mar 84 14:12 PST
Lisp-System-Date: 7-Mar-84 13:56:45
Machine-Type: Dorado
I've just looked at the ASSIST file (where the readmacro function definitions are) -- there is nothing complicated going on at all there so I don't think there will be any problem fixing the OPENSTRINGSTREAM problem in a way that
*** doesn't require any new development
*** doesn't even require editing the macrochar fns
*** doesn't break the fullfilename facility for non-FILE streams
*** doesn't take more than 5 minutes
The following "one-line" patch to \APPLYREADMACRO ( where the comment appears in the DEFINEQ below) completely fixes the problems reported by Kelly and Jim -- namely just use the STREAM unless it's FULLNAME is a litatom:
[DEFINEQ (\APPLYREADMACRO (STREAM MACDEF ANSCELL)
(DECLARE (USEDFREE #CURRENTRDTBL#))
(PROG ((FULL (fetch FULLNAME of STREAM)))
(if (LITATOM FULL)
then (* Some system-supplied macros depend upon being
able to see T rather than anything else)
(SETQ STREAM FULL))
(RETURN (APPLY* (fetch MACROFN of MACDEF)
STREAM #CURRENTRDTBL# ANSCELL]
Looks like it takes more work to read all the messages about why this problem is unsolvable that to just go ahead and fix it right.
On that score, let me make a plea (to LispCore^) that when you feel some *important* topic needs to be discussed [e.g., what are the 10 ten projects just beyond our resources now], please use a different Subject line in the mail header than the mail you currently happen to be reading.
*start*
01564 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@From: kaplan.pa
Date: 18-Mar-84 20:20:56 PST
Subject: AR41
To: JonL, Lispsupport
I think I thought of that, but rejected it for reasons that I can't remember now. Will try to rethink.
But for the record:
The fix I installed does not make it impossible to re-open an explicit string stream, if a closed instance of such a thing is given to OPENSTRINGSTREAM. What is required is a generic facility for re-opening basebyte streams--a facility that should be installed anyway (on the last cycle, I added that kind of thing to various other file devices). The string stream, even without having a pointer to the string iteself, has enough information to reopen from the stream. And indeed, if the user held on to the string instead of the stream, he could always get a new instance.
The only capability that was lost in my fix was the ability to get back the string from the stream via FULLNAME.
Note that none of this stuff with explict string streams can affect backward compatibility with 10 code, since such things never existed on the 10.
I agree that it is a slight non-feature not to be able to get back to the string from the stream--ceteris paribus, access to more information is better than access to less.
I will try to resurrect the reasons for not following JonL's suggestion. If I can't, either I will back out my changes to OPENSTRINGSTREAM and \GETSTREAM on AOFD and stick in a fix in \APPLYREADMACRO--or submit an AR putting that on the action list.
--Ron
*start*
01086 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 23:00 PST
From: desRivieres.pa
Subject: Re: AR41 and AR39
In-reply-to: JonL.pa's message of 18 Mar 84 19:35 PST
To: LispSupport.pa
cc: Kaplan.pa, Jonl.pa, Lispcore^.pa, DesRivieres.pa, Sybalsky.pa
There is also a problem with OPENSTREAM, and it may be related to the one with OPENSTRINGSTREAM and to the one I reported to John Sybalsky (AR 39) concerning characters being lost when READing a stream opened with OPENTEXTSTREAM.
My most recent observation is that obtaining a stream via (OPENSTREAM 'FOO 'INPUT) vs. (GETSTREAM (OPENFILE 'FOO 'INPUT)) are not equivalent --- the later seems to work; the former occasionally drops characters. First, I saw
72:(PEEKC STREAM)
%
73:(READC STREAM)
%(
and then a couple minutes later:
90:(PEEKC STREAM)
%
91:(PEEKC STREAM)
%(
(I'm placing my bets on some piece of code that searches ahead for the next delimiter which fails to unread the character properly.)
---Jim
*start*
00583 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 19:38 PST
From: JonL.pa
Subject: Lisp: unnormalized Floating Point ??
To: LispSupport.pa
cc: JonL.pa
Lisp-System-Date: 7-Mar-84 13:56:45
Machine-Type: Dorado
The number (EXPT 2.0 -127) is "unnormalized" in that it has an exponent field of 0. Microcode "punts out" to macrocode on these kinds of numbers.
(FPLUS 0.0 (EXPT 2.0 -127))
for some reason is adding one to the exponent field thereby essentially doubling the number. This happens for most 0-exponent field unnormalized numbers.
*start*
00570 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@From: kaplan.pa
Date: 18-Mar-84 20:27:31 PST
Subject: auto-display-after-delete suggestion
To: lafitesupport
I have a suggestion for how to handle the auto-display capability. I find this useful on Delete when I am going thru my new mail in sequence, but as others have noted, a nuisance when I am cleaning up old mail.
My suggestion is to set a bit after every GetMail, do auto-display after delete when the bit is set, and turn it off as soon as the user does something out of sequence.
--Ron
*start*
00333 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 22:58 PST
From: Stansbury.pa
Subject: Lisp: DEdit: getting the tty
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
Bugging the Edit Buffer does not give the tty to DEdit; you have to bug the main window.
-- Tayloe.
*start*
00447 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 23:00 PST
From: Stansbury.pa
Subject: Lisp: DEdit: attatched windows
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
The three windows which comprise an edit (the main window, the Edit Buffer window, and the EditOps menu) do not move and reshape as a unit; suggest reimplementing using the new AttachedWindow package.
-- Tayloe.
*start*
00898 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 08:40 PST
From: Feuerman.pasa
Subject: Lisp: Garbage Collection
To: LispSupport.pa
cc: Feuerman.pasa
Lisp-System-Date: 26-Jan-84 01:48:36
Machine-Type: Dolphin
Is there some way to temporarily turn off the garbage collection routine? I realize I may be getting into trouble with this, but it's something I want to look into. The reason is that I'm trying to speed up a particular interactive routine, and everytime I call the routine, the cursor inverts for a good second or so before the user actually sees that the routine is being invoked. The fact that we go through a garbage collection everytime I invoke the procedure probably means somthing, too. Anybody know what that is? How much trouble could I be getting into if I were to disable the reclaim temporarily until the routine was over?
--Ken.
*start*
00276 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 09:39 PST
From: Sheil.pa
Subject: Lisp: EVALV: Request for info
To: lispsupport
Does EVALV release its stack pointer arg? Why is there not a release flag, like for ENVEVAL etc etc?
Beau
*start*
01263 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 09:51 PST
From: Sannella.pa
Subject: [MASINTER.PA: non-closable streams]
To: LispSupport.pa
----- Forwarded Messages -----
Date: 18 MAR 84 23:28 PST
From: MASINTER.PA
Subject: non-closable streams
To: LispCore^
There are some streams, (e.g., T) for which CLOSEF is basically a no-op.
For streams which connect you to file servers or to disk files, there is some sense in making closing the stream flush the cache, close the connection, etc.
For other streams, e.g., RS232, string streams, NODIRCORE, it might be preferable to make CLOSEF be a no-op. At least, that would prevent the problem of figuring out how to reopen the thing.
Shouldn't CLOSEF on a display stream be a no-op?
It seemed pretty clear tht CLOSEF on the more hardware-device kinds of things like RS232 and the keyboard stream should just leave the thing alone.
(This is a 'design discussion', because I have no current instances of something that doesn't work because of the current system design. I do recall some incident where I got into trouble by closing the RS232 stream and not knowing how to reopen it, but I don't recall the details.)
----- End of Forwarded Messages -----
*start*
00532 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 09:52 PST
From: Sannella.pa
Subject: [MASINTER.PA: USERCLOSABLE etc.]
To: LispSupport.pa
----- Forwarded Messages -----
Date: 18 MAR 84 23:29 PST
From: MASINTER.PA
Subject: USERCLOSABLE etc.
To: kaplan
cc: lispcore^
Maybe it would help to focus this design discussion in the ImplManual in the section on what the various STREAM fields mean. I don't understand USERCLOSEABLE, for example.
----- End of Forwarded Messages -----
*start*
01079 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 09:52 PST
From: Sannella.pa
Subject: [KAPLAN.pa: Re: non-closable streams]
To: LispSupport.pa
----- Forwarded Messages -----
From: KAPLAN.pa
Date: 19-Mar-84 0:06:02 PST
Subject: Re: non-closable streams
In-reply-to: MASINTER, Lispsupport
's message of 18 MAR 84 23:28 PST
To: MASINTER
cc: LispCore^
You have to be able to do a CLOSEF on a stream if you want to re-open it with difference access mode. For some streams, like display streams or T, it doesn't make sense to change the access mode, hence CLOSEF might just as well be a no-op.
Indeed, display streams probably should be marked as not closeable, since the world gets fairly confused if, e.g., you do CLOSEF to a window: the window stays around but you can't print to it cause its stream is closed. One thought I had about this was to make CLOSEF of a window also do a CLOSEW. But maybe it is better just not to close the stream.
I guess this latter point is an AR.
--Ron
----- End of Forwarded Messages -----
*start*
00889 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 09:55 PST
From: Sannella.pa
Subject: [LINKOPING@BBNG.ARPA: Communications]
To: LispSupport.pa
----- Forwarded Messages -----
Received: from BBNG.ARPA by PARC-MAXC.ARPA; 19 MAR 84 03:30:27 PST
Date: Mon, 19 Mar 84 06:15:07 EST
From: LINKOPING@BBNG.ARPA
Subject: Communications
To: masinter.pa, sannela.pa
ReSent-date: Mon, 19 Mar 84 06:29:49 EST
ReSent-from: LINKOPING@BBNG.ARPA
ReSent-to: sannella.pa
OK! Thanks for your messages, both of you; it has substantially changed my
view of the situation, and given me a useful message from Larry with which
to encourage others to be more active and pursue matters.
I will send some bug reports at once, but in separate messages.
(My network crashed 3 times getting this one written!)
Jim Goodwin
-------
----- End of Forwarded Messages -----
*start*
00616 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 09:55 PST
From: Sannella.pa
Subject: [LINKOPING@BBNG.ARPA: RESTART.PROCESS / Hard reset]
To: LispSupport.pa
----- Forwarded Messages -----
Received: from BBNG.ARPA by PARC-MAXC.ARPA; 19 MAR 84 03:36:18 PST
Date: Mon, 19 Mar 84 06:35:42 EST
From: LINKOPING@BBNG.ARPA
Subject: RESTART.PROCESS / Hard reset
To: sannella.pa
IF RESTART.PROCESS is called on a process which has been created with
SUSPEND=T and never started, this hangs the machine (hard reset required.)
jg
-------
----- End of Forwarded Messages -----
*start*
00708 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 09:56 PST
From: Sannella.pa
Subject: [LINKOPING@BBNG.ARPA: Our installation]
To: LispSupport.pa
----- Forwarded Messages -----
Received: from BBNG.ARPA by PARC-MAXC.ARPA; 19 MAR 84 03:44:08 PST
Date: Mon, 19 Mar 84 06:43:32 EST
From: LINKOPING@BBNG.ARPA
Subject: Our installation
To: sannella.pa
We have 6 Dlion's (1108's).
Fugue version 4.
One 8037 fileserver with 2 300 Meg drives running version 5 or 5.1 of the
NS software.
A laser printer whose model numbers and stuff Tomas does not remember at this
moment. I'll try to get it if it becomes relevant.
jim
-------
----- End of Forwarded Messages -----
*start*
01232 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 09:56 PST
From: Sannella.pa
Subject: [LINKOPING@BBNG.ARPA: ADD.PROCESS: minor confusion about arguments]
To: LispSupport.pa
----- Forwarded Messages -----
Received: from BBNG.ARPA by PARC-MAXC.ARPA; 19 MAR 84 03:53:59 PST
Date: Mon, 19 Mar 84 06:53:23 EST
From: LINKOPING@BBNG.ARPA
Subject: ADD.PROCESS: minor confusion about arguments
To: sannella.pa
I found the argument formats for ADD.PROCESS confusing, the manual description
of them even more so. I forget the details now, my notes of a month ago read:
(ADD.PROCESS <form> 'SUSPEND T)
creates a process named SUSPEND which is not suspended.
(ADD.PROCESS <form> 'CALL-ME-MADAM 'SUSPEND T)
gives "Illegal argument 5". (surely a classic error diagnostic!)
Only two formats seem to work:
(ADD.PROCESS <form> <name>) ; only 2 args
(ADD.PROCESS <form> 'NAME 'CALL-ME-MADAM 'SUSPEND T ...)
(endquote from my notes)
Severity : minor. Remedy: either better error checking and clearer description
in the manual of the permitted formats, or (my preferred solution) less
cleverness and fewer defaults int he arguments.
/jg
-------
----- End of Forwarded Messages -----
*start*
00951 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 09:56 PST
From: Sannella.pa
Subject: [LINKOPING@BBNG.ARPA: Shrink : Rather annoying]
To: LispSupport.pa
----- Forwarded Messages -----
Received: from BBNG.ARPA by PARC-MAXC.ARPA; 19 MAR 84 04:00:25 PST
Date: Mon, 19 Mar 84 06:59:49 EST
From: LINKOPING@BBNG.ARPA
Subject: Shrink : Rather annoying
To: sannella.pa
I have a note that the SHRINK command (in background menu) sometimes places
the resulting ICON off the visible portion of the screen! Thus it is
unrecoverable unless you are enough of a wizard to know how to use (OPENWINDOWS)
or whatever the function was, to get it back.
I believe this occurred when I shrank a window which was positioned so that
its lower parts were actually off the bottom of the screen (but the upper
parts still on it). Let me know if that fails to reproduce it.
JG
-------
----- End of Forwarded Messages -----
*start*
01147 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 09:50 PST
From: Sannella.pa
Subject: [MASINTER.PA: FULLNAME invariant]
To: LispSupport.pa
----- Forwarded Messages -----
Date: 18 MAR 84 22:34 PST
From: MASINTER.PA
Subject: FULLNAME invariant
To: lispcore^
Whatever the resolution of the readmacro issue (more on that below), it is expected of all streams S that
(EQ S (GETSTREAM (FULLNAME S) mode))
if (OPENP S mode).
This translates to the fact that if
you have the stream and get its FULLNAME that you can pass the FULLNAME around just as well.
This requirement is why the FULLNAME of things like display streams and such are just the stream itself.
While it is a nice idea to be able to take a string stream and find out what the original string was, using FULLNAME for that purpose would cause it to violate the above requirement unless the string->stream mapping were cached independently.
Ron introduced OPENSTREAMSTRING or OPENSTRINGSTREAM exactly to avoid the overhead of the caching (which IS maintained if you just call (GETSTREAM "abcd").
----- End of Forwarded Messages -----
*start*
00495 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 MAR 84 23:14 PST
From: KAPLAN.PA
Subject: LOGIN to Phylum from 10 Lisp fails
To: LISPSUPPORT
I had PUPFTP loaded on Maxc and tried to see my directory on Phylum:
DIR {PHYLUM}<KAPLAN>LISP>
It asked me to login to Phylum, and simply wouldn't believe my password
(whether typed in upper or lower case).
This resembles problems that used to crop up in D. Perhaps the 10 has the older version of the code?
--Ron
*start*
00870 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 MAR 84 23:19 PST
From: KAPLAN.PA
Subject: More on Maxc password problem
To: LISPSUPPORT
I had asked for
DIR {PHYLUM}<KAPLAN>LISP
and had the password problem.
When I did an EXEC to send the previous message and returned back to Lisp,
I tried
DIR {PHYLUM}<KAPLAN>LISP>*
which is what I had really wanted. This worked fine.
But then when I retried
DIR {PHYLUM}<KAPLAN>LISP
I got different behavior: instead of the password problem, I got a file not found message, which is what I would have expected in the first place.
I don't understand why it got better the second time. Doubt that the EXEC had anythng to do with it. Perhaps the login had taken effect in the first DIR, but that the code was such that it didn't get noticed until I backed out to the top and tried again.
--Ron
*start*
00435 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 00:04 PST
From: Sheil.pa
Subject: Lisp: MOUSESTATE always needs dumping
To: LispSupport.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dolphin
Whenever I dwimify or interpret a function with a MOUSESTATE or LASTMOUSESTATE expression in it, I find that MOUSESTATE-EXPR wants to be dumped (by the file package). What's going on here?
Beau
*start*
02208 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 14:46 PST
From: Halasz.pa
Subject: Lisp: Reflections on using TELERAID on DLions
To: LispSupport.pa
cc:
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
Just thought I'd pass along some reflections on TELERAID on the DLions.
TeleRAID is a major weakness of the 1108: it is impossible to use efficiently on networked systems and on stand-alone systems it is worse than useless.
Most important is the stand-alone problem. If you are running a stand-alone system, the only error indication you get when the system goes into RAID or some other MP error is a single four digit number in the MP and NOTHING ELSE. There is no way to make sense of this information. All there is a short information file giving a few cryptic words about the meaning of each MP number. There is no way to see the msg that would be printed by Raid on a Dolphin/Dorado, there is no way to examine the stack or variable settings. Basically, there is no way to debug the machine. YET, Interlisp is designed to pop into a MP error or RAID at the slightest provacation. The result of this mess is a very, very unpleasant experience for stand-alone DLion users. At least in the good old days of ABENDS and IEH0023, there was an error manual that expended some effort to explain the meaning of the error numbers. On stand-alone 1008s, there is nothing at all.
For networked systems the problem is much less severe, since TELERAID does work very well under this conditions. The problem is that it is a royal pain to use. One needs two machines to do any debugging using TeleRAID. This means either dedictating two machines to a single debugging project or running around trying to find a spare every time you pop into TeleRAID. If the debugging task involves popping into TeleRAID at some regular intervals this can be a real headache. RAID on the Dolphin/Dorados is infinitely easier to use efficiently since a single machine suffices.
I understand the problems of writing a separate adress space debugger on the DLion. But I just wanted to provide some user feedback that might help set development priorities.
Frank
*start*
00971 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 21:12 PST
From: vanMelle.pa
Subject: Re: auto-display-after-delete suggestion
In-reply-to: kaplan.pa's message of 18-Mar-84 20:27:31 PST
To: kaplan.pa
cc: lafitesupport.pa
Do you have LAFITEDISPLAYAFTERDELETEFLG set to ALWAYS? If it is T, the initial setting, then the next message is displayed after a delete only if it is undeleted and unexamined, the usual case of a GetMail. The only perturbation to this is if the next message is from self, then it is implicitly examined (if LAFITEIFFROMMETHENSEENFLG is true), in which case Lafite pretends the message is unexamined if the next message not from self is unexamined.
There were versions of Lafite for a few months where this was not true of LAFITEDISPLAYAFTERDELETEFLG=T due to this problem with messages from self; in those, the next message was displayed if it was undeleted, independent of whether it was examined.
Bill
*start*
00406 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 21:46 PST
From: vanMelle.pa
Subject: Re: AR 165: Can't CHAT with 3mb/10mb uCode
In-reply-to: Sannella.PA's message of 18 Mar 84 15:36:56 PST (Sunday)
To: LispSupport.pa
This is a known bug in BSP when running with both flavors of ether. I think I even told Jim so when I gave him that microcode. On my queue to fix.
*start*
00662 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 22:10 PST
From: vanMelle.pa
Subject: Re: arithmetic bugs
In-reply-to: Bill White's message of Thu, 9 Feb 84 01:06:56 PST
To: WHITE@SUMEX-AIM
cc: lispsupport.PA
In Interlisp-D, integer overflow only produces max.integer if you have set (OVERFLOW NIL). The "random large number" you see is the result modula 2^32, which is the default behavior, and the only behavior you get in Interlisp-10, which does not provide control over any kind of overflow.
If you have set (OVERFLOW T), then x/0 does produce an error in Interlisp-D.
See description of OVERFLOW in manual.
Bill
*start*
00464 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 22:48 PST
From: vanMelle.pa
Subject: Re: BITBLTing using a bitmap as a texture
In-reply-to: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>'s message of 13 Feb 84 13:48:00 EST
To: SHULMAN@RUTGERS
cc: lispsupport.pa
I believe the only requirement on the bitmap is that its width be 16. Its height can be anything. If you have a narrower texture, replicate it yourself out to 16 wide.
*start*
00502 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 22:12 PST
From: vanMelle.pa
Subject: Lisp: Dorado does not punt on integer overflow
To: LispSupport.pa
cc: vanMelle.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
Microcode version = 12004Q
(OVERFLOW T) followed by (IPLUS MAX.FIXP 1) does not cause an error, because the Dorado is not punting out to \SLOWIPLUS2, which is where the error is (should be) generated. The Dolphin does the right thing.
*start*
02157 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 MAR 84 23:09 PST
From: MASINTER.PA@PARC-MAXC.ARPA
Subject: a couple of addenda
To: linkoping@bbng.ARPA
cc: lispsupport.PA@PARC-MAXC.ARPA, Raim.pasa@PARC-MAXC.ARPA
We need to find out more about the schedule for random access from the
file server. I don't think our current response is particularly
adequate. I've heard Services 9.0 (early 1985?) but we should find out
more better.
Jim, TEdit has gone thru really major reworkings; I think the next
release we're testing will be a lot better than what you have now. The
random access problem is still a pain. Some of the problem in getting
the directory listing is in the protocol and a lot in our implementation
of it -- e.g., Lisp gets every property of every file over the net
before it starts printing out anything.
If you have the patience to type in specifics, it will actually help out
a lot.
It was a little unclear whether you were STILL working for Hein in his
"support" company; it seems perfectly reasonable to expect a local
support group to go to the trouble of documenting bugs.
If, on the other hand, you are just a user of the system, I'll just ask
it of you as a favor.
There are a lot of things to be done, and it seems that the things that
will get fixed are the ones that get complained about the most
frequently.
Vote with your mailbox. There are actually pretty few sites that ONLY
have NS file servers, and so you may well turn up more than your share
of can't-get-there-from-here's. Also, it takes reasonably knowledgable
users to generate good bug reports; we have a lot of users, but most are
pretty new to Interlisp.
While I'm asking you of favors, it would help out when you report
problems (to 1100Support.pasa or LispSupport) to use Subject: as a terse
headline description of the problem, and include your estimate of how
serious a problem it is
(Annoying, Serious (really slows you down), Fatal (loses work)) how
often it occurs, what version of Lisp you have.
You might pass this along to Hein too; we haven't heard much
(anyhthing?) from them in the way of technical queries, etc.
*start*
00367 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 MAR 84 23:12 PST
From: MASINTER.PA
Subject: AR mail
To: lispSupport
Two things:
I suggest you edit in a
From: LispSupport
in your mailsender when you send mail as LispSupport.
Your message to Goodwin sounded just a wee bit defensive. TEdit does need work, and we know it, etc.
*start*
00423 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 16:10 PST
From: ckiparsky.pa
Subject: Lisp: FILE BROWSER
To: LispSupport.pa
cc: ckiparsky.pa, Kaplan
Lisp-System-Date: 13-Mar-84 13:05:55
Machine-Type: Dandelion
In using RENAME, characters drop out of the new filename - although the prompt window echoes correctly.
Have replicated this 4 times.
-Carol Kiparsky and Meg Withgott
*start*
00767 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 16:20 PST
From: Burton.pa
Subject: Re: Lisp: RELDRAWTO
In-reply-to: desRivieres.pa's message of 1 Feb 84 21:37 PST
To: LispSupport.pa
cc: desRivieres.pa
I changed RELDRAWTO to not do anything if DX=DY=0. I also fixed the documentation on RELDRAWTO and DRAWLINE to make it clearer what happens.
Mike: included below is Jim's orig bug report.
Date: 1 Feb 84 21:37 PST
From: desRivieres.pa
Subject: Lisp: RELDRAWTO
To: LispSupport.pa
cc: desRivieres.pa
Lisp-System-Date: 26-Jan-84 01:48:36
Machine-Type: Dorado
When DX and DY are both 0, (RELDRAWTO DX DY HEIGHT 'PAINT WINDOW) draws a thin horizontal line approx. HEIGHT units long instead of drawing nothing.
---Jim
*start*
00967 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 16:46 PST
From: Masinter.pa
Subject: [Nuyens.pa: Re: non-closable streams]
To: LISPSUPPORT
CC: LispCore^
Please submit AR: Closing T stream crashes system
with the following description:
(If it crashes your system, then either we should fix it or document it as dangerous. Priority: Possibly, Impact: Fatal, Frequency: Once)
Low priority because unlikely for users to do this except on purpose, but it is definitely a bug.
----- Forwarded Messages -----
Date: 19 Mar 84 16:05 PST
From: Nuyens.pa
Subject: Re: non-closable streams
In-reply-to: MASINTER.PA's message of 18 MAR 84 23:28 PST
To: MASINTER.PA
cc: LispCore^.PA
I think you'll find that one gets interesting results by closing the T stream. Hardly a no-op. I don't want to trash my world right now trying it, but I saw Jim get in a weird state by doing it.
Greg
----- End of Forwarded Messages -----
*start*
00321 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 17:08 PST
From: Burton.pa
Subject: Lisp: OPENLAMDA interpreted bug
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Trying to run RELDRAWTO interpreted (from IMAGEIO) causes "undefined car of form" (OPENLAMBDA ...))
richard
*start*
00348 00071 UU
@00045 01536 ffffffffffffffffffffffffffffffff
@Date: 19 Mar 84 17:16 PST
From: sybalsky.pa
Subject: Re: TEdit: Hardcopy in TEditMenu usurps mouse
In-reply-to: vanMelle.pa's message of 19 Mar 84 17:09 PST
To: vanMelle.pa
cc: TEditSupport.pa
In the NEXT release of Tedit, it is fixed; that release hasn't yet been announced.
*start*
00312 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 17:09 PST
From: vanMelle.pa
Subject: TEdit: Hardcopy in TEditMenu usurps mouse
To: TEditSupport
cc: vanMelle.pa
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
(it still does)
*start*
00565 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 17:14 PST
From: Masinter.pa
Subject: Re: AR 191: EVALV should have release-stack-ptr flag
In-reply-to: LispSupport.pa's message of 19 Mar 84 17:10:13 PST (Monday)
To: LispSupport.pa
cc: SHEIL
EVALV doesn't have a RELEASEFLG because it doesn't ever give up control. The reason ENVEVAL and friends have RELEASEFLG is because they can never return. With EVALV, you can say (PROG1 (EVALV var stkp) (RELSTK stkp)]
Change AR to:
Status: Wish
Priority: Unlikely
Difficulty: Easy
*start*
00885 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 17:18 PST
From: Masinter.pa
Subject: Re: AR 190: How to turn off GC ?
In-reply-to: LispSupport.pa's message of 19 Mar 84 17:03:38 PST (Monday)
To: LispSupport.pa
cc: Feuerman.pasa, Masinter.pa
This is not so much TURNING OFF the GC as it is temporarily deferring its work.
You can modify the time-until-next-GC by setting RECLAIMMIN high before the operation (I believe 177777Q is the actual limit) and then setting it low, e.g.
(RECLAIMMIN (PROG1 (RECLAIMMIN MAX.SMALLP) <dooperation>]
Ken, you should also find out why your routine is CONSing so much. TIMEALL, BREAKDOWN, and DOSTATS may be able to help you track it down.
Please report any problems you have in tracking down the source of all of the GC activity.
[to: LispSupport: this AR is not Fixed, but it may be type: Documentation]
*start*
00407 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 17:24 PST
From: Burton.pa
Subject: Re: AR 184: Attached-window titles obscured
In-reply-to: LispSupport.pa's message of 19 Mar 84 16:42:19 PST (Monday)
To: LispSupport.pa
cc: Burton.pa
I would suggest he create a titled window in the first place. I would put a pretty low priority on switching the behavior.
richard
*start*
01714 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 17:55 PST
From: Masinter.pa
Subject: Re: Dlion info
In-reply-to: LINKOPING@BBNG.ARPA's message of Thu, 15 Mar 84 18:30:00 EST
To: LINKOPING@BBNG
cc: 1100Support, LispSupport, Haggstrom.RX
by the way:
re: "Doing a directory of something like <LISP> takes much too long.
Doing a directory of <LISP>FOO.* takes just as long."
workaround:
The FILEBROWSER library package may make living with the slow directory enumeration a little less painful, because it keeps around a list of the files and you don't have to access the file server everytime you want to look and see what is in the directory. It IS still quite slow for getting up the initial display.
Re: "MAKEFILE, TEDIT, and many other operations fail, crash, and go wrong
due to the lack of a random access protocol. Will our file server eventually
support random access?"
It was my impression that MAKEFILE would work OK with non-randaccessp files. You basically had to always LOAD the file (PROP if necessary) and then do MAKEFILE.
Setting MAKEFILEREMAKEFLG to NIL will insure that it won't try to use random access.
Re your communication link: how is remote communcation between your place and RX Sweden in Stockholm? Is it possible for you to type in your stuff, and get Christer to forward it? (Or send him a Floppy which he can copy and send to us?) I don't know how this can work, but if you can get over to BBNG, maybe you can get to RXSweden.
The use of the ARPANET is supposed to be in support of ARPA official business. While general support of Interlisp-D is probably in the ARPA communities interest, we are probably on the edge of acceptable use.
*start*
00292 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 17:58 PST
From: Masinter.pa
Subject: Re: Why did he tell me this?
In-reply-to: LispSupport.pa's message of 19 Mar 84 17:26:44 PST (Monday)
To: LispSupport.pa
cc: Masinter.pa
Michael, I think I asked him.
*start*
00324 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 17:56 PST
From: Burton.pa
Subject: Re: AR 195: SHRINK can place icon off screen
In-reply-to: LispSupport.pa's message of 19 Mar 84 17:31:07 PST (Monday)
To: LispSupport.pa
Has been fixed. I think it was fixed before fugue.6.
richard
*start*
00473 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 18:01 PST
From: Burton.pa
Subject: Re: AR 197: MOUSESTATE marks MOUSESTATE-EXPR as-changed
In-reply-to: LispSupport.pa's message of 19 Mar 84 17:52:18 PST (Monday)
To: Sheil, LispSupport.pa
This is because a function that is DOCOPY EVAL@COMPILE is saved as interpreted only. Hence loading EXPORTS.all redefines it with an interpreted version. I don't know any other way.
richard
*start*
00717 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 20:17 PST
From: Sheil.pa
Subject: Lafite: MoveTo confirmation
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dolphin
Seems to me that the semantics of MoveTo confirmation are reversed. If you left button MoveTo and then select your choice from a menu, you get asked for a mouse confirmation, even tho you have just explicitly choosen from a menu. On the other hand, if you middle button MoveTo, the move takes place with no confirmation at all, even tho you may just have missed "Update".
Moral: Confirmation belongs to implict choices, not explicit ones.
Beau
*start*
00679 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 20:52 PST
From: Sheil.pa
Subject: TEdit: Multiple edits trashing each other
To: TEditSupport
TEdit-System-Date: 1-Mar-84 13:54:34
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dolphin
I typed in (FOR IN IN '(FILE 1 FILE2 FILE3) DO (TEDIT I)) thinking that I would get three parrallel edits.
Instead I got asked for one edit window and each of the three documents got smashed into the same window (leaving an uneditable mess). Whewn I quit that window, I found the other processes running with "inactive edit" windows which were EQUAL (EQ?) to the one window I opened by hand.
Beau
*start*
00800 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 MAR 84 23:55 PST
From: MASINTER.PA
Subject: HORNERIFY for hardware floating point opcode?
To: JonL
cc: LispSupport
Can you explain what HORNERIFY does? Is it possible to have a microcoded opcode which takes two args, an input and a vector of coefficients, and does the polynomial approximation?
This is the kind of thing that
(a) will really scream on DandeTiger
and show off floating point
(b) be generally useful for all kinds
of transcendental functions of
the users choosing.
How 'bout it?
(This is a Wish: I guess)
I dunno if you can really get it to
fit in 4K dorado, but if you wanted
to.... We want DandeTiger announcement
to look really good, and this is just
the kind of thing that will show it off.
*start*
00636 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 MAR 84 00:12 PST
From: MASINTER.PA
Subject: BYTECOMPILER coerce constant args
To: JonL
cc: LispSupport
I made the fix to BYTECOMPILER but haven't recompiled it or tested. The change was in COMP.NUMERIC. I fixed it that it would coerce args to numeric functions, e.g.
(IPLUS x 3.5) would compile as (IPLUS X 3) while (FPLUS x 3) would compile as (FPLUS x 3.0).
Some of this had been working before, e.g., (FPLUS x 2 1) would have compiled as (FPLUS x 3.0).
As I type this I realize that there are more cases to handle, so wait a bit before testing.
*start*
00589 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 11:11 PST
From: masinter.pa
Subject: can hang waiting for typein without RINGBELL
To: LispSupport
cc: masinter.pa
I said TEDIT(filename) and then buttoned another window and started working. I didn't notice that the TEDIT was asking for a USER.CM in the prompt window. When I finally clicked in the prompt window, it did a RINGBELLS, so maybe it was hung up waiting for a monitor lock and never rang the bell.
No quick hack solutions to this one, please, there is something fundamentally the matter.
*start*
00540 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 11:16 PST
From: masinter.pa
Subject: TEdit: \TEDIT.BRAVOFILE? takes several minutes
To: TEditSupport
cc: masinter.pa
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dandelion
I tried TEDIT({Phylum}<LispARS>SortedSummary.TXT and it spent several minutes in \TEDIT.BRAVOFILE? and then asked me for a USER.CM. Why in the world did it think this was a bravo file anyway?
Type Performance
Annoying, Once, Hopefully
*start*
00760 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 11:04 PST
From: Burton.pa
Subject: Re: Maxwell's AR on WHEREIS not working for him
In-reply-to: Kaplan.pa's message of 17 Mar 84 17:45 PST
To: LispSupport.pa
cc: Kaplan.pa, Maxwell.pa
I fixed WHEREIS to call FINDFILE using LISPUSERSDIRECTORIES on the file names on WHEREIS.HASH.
Michael: John reported this in a paper about his experiences getting into interlisp so there may not be an AR number.
John: This version is on <LISPCORE>LIBRARY>WHEREIS.DCOM. You will need to have {phylum}<lisp>library> on LISPUSERSDIRECTORIES. Alternatively, you could move the file WHEREIS.HASH from {phylum} to a lisp user directory that is on your LISPUSERSDIRECTORIES.
richard
*start*
03840 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 11:09 PST
From: Sannella.pa
Subject: [JONL.PA: Re: non-closable streams]
To: LispSupport.pa
----- Forwarded Messages -----
Date: 19 MAR 84 17:58 PST
From: JONL.PA
Subject: Re: non-closable streams
To: MASINTER, LispCore^
cc: JONL
In response to the message sent 18 MAR 84 23:28 PST from MASINTER.PA
Well, the RS232 stream is in fact a prime candidate for a CLOSEF method.
I haven't added a functional interface (should probably do so) to "shut
down the hardware", but the device eventfn does indeed do the shut-down
at makesys and sysout time ["shutdown" could only mean dropping the DTR
and CTS lines on the Dolphin, but it implies a bit more on the DLion].
The RS232 documentation doesn't describe all this yet because I don't
think I've gotten it 100% "right". The driver code of post January
is a lot better at not barfing when you try CLOSEF on the rs232 stream.
-----
Date: 19 Mar 84 18:28 PST
From: Masinter.pa
Subject: Re: non-closable streams
In-reply-to: JONL.PA's message of 19 MAR 84 17:58 PST
To: JONL.PA
cc: Lichtenberg.wbst, LispCore^.PA
the inconsistency that I ran across (I think) was that you didn't OPENSTREAM({RS232}) to initialize it. Thus, once I had closed the stream, I had no way of reopening it.
On my little TRS-80 model 100, they support RS232 by making you open a stream on the device, and using the file name to give the paramters. That might be a good model for how to run RS232 in Interlisp-D. Translating it into Interlisp-ese, this would say:
stream_(OPENSTREAM '{RS232}1200.XON 'BOTH) would (a) initialize the hardware (instead of RS232INIT), and create the open stream. (On the Radio Shack one the "name" was a more terse code which encoded baud rate, whether Xon/Xoff was enabled, number of stop-bits, parity, etc. For all I know, it is industry or at least MicroSoft standard.)
Attempting to OPENSTREAM an RS232 stream when one is already open could generate a FILE WONT OPEN error.
[In general, the design principle is that if there are "generic" functions which map reasonably into the device-specific ones, they should be used rather than special purpose ones. For example, GETFILEINFO and SETFILEINFO can be used for setting up various parameters of streams where possible if they don't fit into other file operations; loading extra information into the file name is reasonable and done in almost all operating systems.]
-----
Date: 19 Mar 84 19:36 PST
From: Masinter.pa
Subject: Re: non-closable streams
In-reply-to: KAPLAN.pa's message of 19-Mar-84 0:06:02 PST
To: KAPLAN.pa
cc: MASINTER.pa, LispCore^.pa
The latter point may be an AR, but what is the AR? What Action are you Requesting? (and Impact, etc.).
(CLOSEF window) => (CLOSEW window)? Or Illegal operation? or no-op?
CLOSEW and CLOSEF aren't really the same. If we had a CLOSEW which somehow cleared out any space hung onto by the window (e.g., deallocated the saved-bitmap), maybe CLOSEF would be the analog, but otherwise
(CLOSEW window) = (SETFILEINFO window 'VISIBLE NIL) or some such.
-----
From: kaplan.pa
Date: 19-Mar-84 22:43:26 PST
Subject: Re: non-closable streams
In-reply-to: Masinter's message of 19 Mar 84 19:36 PST
To: Masinter
cc: KAPLAN, LispCore^
The simplest action is to make display streams not be usercloseable--which means that they will be marked as access=OUTPUT until they are collected. Thus (CLOSEF window) is a no-op.
This maintains integrity, and means, for example, that you could SEE a file to a window without having the window's stream getting smashed at the end.
It is tempting to map CLOSEF into CLOSEW, taking a very general notion of closing an object. But I don't think that has useful applications.
So the AR is: make display streams not be usercloseable.
--Ron
*start*
00618 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 10:48 PST
From: Sannella.pa
Subject: [Masinter.pa: Re: Gensym]
To: LispSupport.pa
----- Forwarded Messages -----
Date: 19 Mar 84 16:43 PST
From: Masinter.pa
Subject: Re: Gensym
In-reply-to: Raim.pasa's message of Mon, 19 Mar 84 15:47 PST
To: Raim.pasa
cc: Masinter.PA, LispCore^.PA
Marty, I cannot. The GENSYM change was advertised as being backward compatible, but apparently it was not. Can you determine in what way the Boeing code was depending on the old GENSYM behavior?
----- End of Forwarded Messages -----
*start*
01672 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 11:11 PST
From: Sannella.pa
Subject: [JONL.PA: Re: Gensym]
To: LispSupport.pa
----- Forwarded Messages -----
Date: 19 MAR 84 18:46 PST
From: JONL.PA
Subject: Re: Gensym
To: Masinter, Raim.pasa
cc: LispCore^, JONL
In response to the message sent 19 Mar 84 16:43 PST from Masinter.pa
Sorry, the new GENSYM was *not* advertised as being 100% compatible.
The basic problem appears to be that the documentation on it *** isn't in
the release message *** How did this happen?
Anyway, the differences, briefly summarized, are
1) you can supply an argument, which becomes the non-numeric prefix for
the generated symbol (this shouldnt cause problems unless someone was
spuriously passing along an argument to the old gensym)
2) the variable GENNUM is initialized at 0 instead of 10000, and there
is no limit on the size of the numerical suffix. Thus if one were to
set GENNUM to 1234567 and then call GENSYM, he would get A1234568
instead of A4568. This part was in the message I sent to Gadol etc
in early January documenting the new gensym capabilities [in fact, there
are other new capabilities -- all extensions that arent affected by
the documented user interface -- byut Tayloe and I were still desiging
these when release time came, so it didn't make sense to document their
half-baked state]
So the question to ask is if they are setting GENNUM. Also, the question to
ask is if the GENSYM commentary was ever in the release message and got
inadvertently deleted.
----- End of Forwarded Messages -----
*start*
00640 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 17:16 PST
From: Halasz.pa
Subject: TEdit: Margin bar does not work on narrow windows
To: TEditSupport
cc:
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
The margin bar does not work on narrow windows because there is no way to get the mouse "attached" to the right end of the bar if the right end is outside of the window. SInce the bar comes up 38 units wide, if the window is less than 38 units wide the right margin cannot be reset.
Frank
PS. What are those units on the margin bar anyway?
*start*
01066 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 17:34 PST
From: vanMelle.pa
Subject: TEdit: TEditmenu margin setter
To: TEditSupport
cc: vanMelle.pa
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
1. If the right margin is set beyond the right margin of the window, I find I can't shrink it back. I have to reshape the window wider so that I can get hold of the right edge and drag it in.
2. I find it hard to move the left margins leftward. Seems like I have to grab the edge and move it rightward before I can move it left.
3. I see no way to specify left margins but leave the right margin "floating", something I would do if I were allowed to. Having non-floating (i.e. fixed) right margin is a pain because it forces your editing window to be at least that wide in order to be able to see all your text. Also, once there are margins at all, I don't see how to get rid of them all, unless I can find a paragraph in my document with no margins and do a SHOW.
Bill
*start*
00646 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 18:02 PST
From: Sheil.pa
Subject: Lisp: EMPRESS Odd file name
To: LispSupport.pa
cc: maxwell
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dolphin
When I empressed John Maxwell's lisp notes file from Lisp, it turned up on the printer with a file name on the leader page of "[]<>LispNotes.tioga" (rather than, "[Phylum]<Maxwell>Lisp>LispNotes.tioga"). The fact that the extension is ".tioga" indicates that the file name was put in the press file by Cedar. Is there some funny format for file names which Cedar uses and which Lisp misinterprets?
Beau
*start*
00320 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 18:18 PST
From: Sheil.pa
Subject: Re: AR 189: Dedit: 3 windows should move and reshape together
In-reply-to: LispSupport.pa's message of 19 Mar 84 17:00:54 PST (Monday)
To: LispSupport.pa
Priority = LOW; Response = UNLIKELY.
Beau
*start*
00378 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 18:20 PST
From: Sheil.pa
Subject: Re: AR 191: EVALV should have release-stack-ptr flag
In-reply-to: Masinter.pa's message of 19 Mar 84 17:14 PST
To: Masinter.pa
cc: LispSupport.pa
OK. But the rationale should be in the manual. Personally, I find the discrepancy in style irritating.
Beau
*start*
00933 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 MAR 84 18:21 PST
From: JONL.PA
Subject: Re: Lisp: Garbage Collection
To: Feuerman.pasa, LispSupport
cc: JONL
In response to the message sent 19 Mar 84 08:40 PST from Feuerman.pasa
You could just adjust the GC parameters -- see page 18.2 of the new manual --
and that would postpone the interval between reclaims.
On the other hand, if you have a Dorado, you can call (DISABLEGC) and all the
GC activity is shut down (unfortunately, you can't then re-enable it). The
reason you need a dorado is that there is a subtle buggy interaction between
the software and microcode after DISABLEGC has been called and I don't think
the other microcoders have taken the time to track it down and fix it [I did
because I needed to run a benchmark -- the BOYER test -- with no GC running.
SIgh, it ran slower because the dominating cost was page swap time].
*start*
00428 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 19:11 PST
From: Stansbury.pa
Subject: Moving files
To: Sannella, Lispsupport
The basic program for sorting out the files on lisp>sources is on stansbury>release>move. Needs to be edited to include the creationdate of the fugue 3 full.sysout.
Same program could be used with little modification to sort out the library files.
-- Tayloe.
*start*
00626 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 18:49 PST
From: Stansbury.pa
Subject: Lisp: NSCREATEDIRECTORY creating wrong directory
To: LispSupport.pa
Lisp-System-Date: 14-Mar-84 10:16:58
Machine-Type: Dolphin
If you have a directory on an NS fileserver foo: called lisp, but no directory called lisp>fugue.n, then NSCREATEDIRECTORY({foo:}<lisp>fugue.n>sources>) creates a directory called lisp>sources.
Should either first create lisp>fugue.n> and then create lisp>fugue.n>sources>, or else at least raise an exception.
Current behavior is pretty seriously wrong.
-- Tayloe.
*start*
00525 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 18:53 PST
From: Stansbury.pa
Subject: Lisp: NSCREATEDIRECTORY creates more than one directory of the same name
To: LispSupport.pa
Lisp-System-Date: 14-Mar-84 10:16:58
Machine-Type: Dolphin
NSCREATEDIRECTORY({phylex:}<lisp>sources>) will create a new directory lisp>sources even if one already exists. Should either be a no-op or raise an exception.
Serious, since Lisp cannot interpret the resulting directory hodge-podge.
-- Tayloe.
*start*
00617 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 18:56 PST
From: Stansbury.pa
Subject: Lisp: Can't handle multiple files and directories of the same name on an NS fileserver
To: LispSupport.pa
Lisp-System-Date: 14-Mar-84 10:16:58
Machine-Type: Dolphin
Should provide some tool to decipher multiple entities of the same name on an NS fileserver. Even if we make it impossible for lisp to create multiple entities of the same name, we would like to be able to read files and directories written by star and mesa, which can create multiple entities of the same name.
-- Tayloe.
*start*
00424 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 18:53 PST
From: JonL.pa
Subject: Lisp: (IQUOTIENT MIN.FIXP -1)
To: LispSupport.pa
cc: JonL.pa
Lisp-System-Date: 7-Mar-84 13:56:45
Machine-Type: Dorado
About three months ago or so someone reported that (IQUOTIENT MIN.FIXP -1) fails to error out when (OVERFLOW T) has been done. I just fixed that -- in the \IQUOTREM macro on LLARITH.
*start*
00981 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 19:14 PST
From: Masinter.pa
Subject: [Don.Cohen <DONC@USC-ISIF.ARPA>: ESCQUOTE]
To: LispSupport
Please submit AR.
----- Forwarded Messages -----
Received: from USC-ISIF.ARPA by PARC-MAXC.ARPA; 16 MAR 84 18:57:24 PST
Date: 16 Mar 84 18:55 PST
Subject: ESCQUOTE
From: Don.Cohen <DONC@USC-ISIF.ARPA>
To: masinter.PA
I have a line in my init file that does:
(SETSYNTAX 39 (QUOTE (MACRO FIRT NONIMMEDIATE ESCQUOTE READ')) T)
When I print an atom containing a ', I get %' if SYSPRETTYFLG is NIL and ' if
it's T. What in the world does SYSPRETTYFLG have to do with this? I thought
NOESCQUOTE vs. ESCQUOTE was supposed to make the difference. This happens on
the 10, VAX and Dolphin. It's not just a matter of whether the atom is being
prettyprinted - the same thing happens if I do PRINTs. It also happens for
other characters than '.
-------
----- End of Forwarded Messages -----
*start*
00408 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 19:23 PST
From: Masinter.pa
Subject: Re: ESCQUOTE
In-reply-to: Don.Cohen <DONC@USC-ISIF.ARPA>'s message of 16 Mar 84 18:55 PST
To: DONC@USC-ISIF
cc: LISPSUPPORT
Apparently, SYSPRETTYFLG causes output to be printed with the NIL readtable instead of the T readtable.
Usually it doesn't matter since they are the same.
*start*
00486 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 19:26 PST
From: Masinter.pa
Subject: Re: ESCQUOTE
In-reply-to: Don.Cohen <DONC@USC-ISIF.ARPA>'s message of 16 Mar 84 18:55 PST
To: DONC@USC-ISIF
cc: LISPSUPPORT
workaround:
ADVISE(SHOWPRINT AROUND (RESETFORM (SETREADTABLE T) *]
that solves some of the problems although not all of them.
(For LispSupport, separate AR: why is the embed token for ADVISE always the * instead of EDITEMBEDTOKEN?).
*start*
00586 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 MAR 84 22:07 PST
From: ROACH.PA
Subject: AR 180 (Tedit SETFILEPTR move caret)
To: LISPSUPPORT
cc: ROACH, DESRIVIERES, SYBALSKY
I personally would prefer SETFILEPTR not move the caret. I have
quite a few hooks into my TEDIT.READTABLE that use SETFILEPTR with
read & print operations and it is fairly awkward looking and seemingly
slower to have the caret move around in the Tedit window while my
functions do their computing. I already know how to "SETCARETPTR"
by using TEDIT.SETSEL.
Kelly
*start*
00462 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 MAR 84 18:08 PST
From: ROACH.PA
Subject: SUGGESTED <LISPUSERS>AREDIT IMPROVEMENTS
To: LISPSUPPORT
cc: ROACH
(1) It is almost essential that you be able to vertically scroll
the AR Layout window. Otherwise, some AR descriptions will not be entirely
viewable.
(2) It would be nice if the AR Layout window could repaint itself
when "Shape"d or "Redisplay"ed.
Kelly
*start*
00681 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 21:04 PST
From: desRivieres.pa
Subject: Lisp: Fugue release manuals
To: LispSupport.pa
cc: desRivieres.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
The Fugue Release document that's sitting on the coffee table outside Larry's office contains interesting information, some of which does not seem to be available from other sources (e.g., the GATEWAY Lisp libary package). I would like to get a copy of this document (actually, I can probably wait until the next release). If possible, *all* Interlisp-D users should receive copies of all such release documents.
---Jim
*start*
00371 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 20:45 PST
From: desRivieres.pa
Subject: Lisp: LISTFILES and Tedit
To: LispSupport.pa
cc: desRivieres.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
It would be nice if LISTFILES could recognize when it was given a Tedit format file and do all the right things.
---Jim
*start*
00180 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 23:17 PST
From: Kaplan.pa
Subject: AR 192 fixed
To: Lispsupport
Essentially the same as 202
*start*
00577 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 23:05 PST
From: vanMelle.pa
Subject: Re: Lisp: METASHIFT
In-reply-to: Wallace.pa's message of 13 Feb 84 20:08 PST
To: Wallace.pa
cc: vanMelle, LispSupport.pa
The documentation is wrong. Flg has to be T, not any old non-nil value. Other non-NIL values are assumed to be action args to KEYACTION. The idea is that if someone has set Blank-bottom to some random behavior, then (RESETFORM (METASHIFT T) --) will correctly restore that random behavior. Not terribly pretty, I admit.
Bill
*start*
00729 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 17:52 PST
From: Masinter.pa
Subject: Lisp: make COPY-select be the same as Shift-select in FILEBROWSER, etc.
To: LispSupport.pa
cc: Masinter.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dandelion
TEDIT now supports the "copy" and "move" keys on the dandelion properly. However, most other packages which allow shift-select still don't pay attention to "copy": DEDIT, TTYIN, FILEBROWSER, etc.
I dunno if this is 3 separate ARs, I guess it is, one for DEDIT, one for TTYIN, one for FILEBROWSER, each with
Subject: "make XXXX know about Copy/Move key on DLion"
Impact: Annoying
Priority: Possibly
Frequency: Everytime
Status: Wish
*start*
00843 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 09:51 PST
From: masinter.pa
Subject: want GREET to ask for init file in typescript window
To: LispSupport
cc: LispCore^
If you don't have a {DSK}INIT.LISP, the system will ask you for one when it starts up the sysout. Way back before we had control over typein from multiple processes worked out, we fixed it so that it would ask for the INIT file in the PROMPT window. However, once we got things worked out, it now asks for the password in the TYPESCRIPT window.
This inconsistency is annoying. It is more annoying because it happens frequently. I think the simplest thing to do is to take back out the use of PROMPTWINDOW here.
In general, we want to reconsider the current (overuse) of promptwindow; this is one instance with a fairly clear action.
*start*
01049 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 10:40 PST
From: masinter.pa
Subject: ar#205
To: Le.pasa
cc: LispSupport
This AR should be titled
READ from strings leaves a stream in \OPENFILES for each call!
The System/Subsystem is Language/Read & Print.
(The "file package" has more to do with the mechanism that keeps track of what edits you made, and the 'pretty printer'. This AR has to do with the low level system.)
While you are at it, change Assigned To: to be Masinter, but Attn: to be Kaplan.
The Workaround: should read (lmm: use OPENSTRINGSTREAM).
Priority: Hopefully, Difficulty: Moderate
append to Description:
[lmm: This is an artifact of a change that KAPLAN made to make reading from strings not gobble up the string and cache the stream. Perhaps another fix which created a stream on the fly each time you did the READ but then ate up the characters would be better. Didn't we used to have a one-level cache that just kept the stream around for the LAST string we had read from?]
*start*
00904 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 10:51 PST
From: masinter.pa
Subject: AR#208
To: LE.PASA
cc: LISPSUPPORT
cc: vanMelle, Purcell, 1100Support.pasa, Martin.pasa
[add this msg to Disposition field]
System: Operating System/ Subsystem: Virtual Memory
(You need to look into the DLion maintenance panel code manual.)
Change Title to: "Suspect 9305 caused by bad page on disk"
Change Status: to Declined. The AR doesn't identify an Action Request.... Rick hypothesises that 9305 may be caused by a bad page on the disk. There is no a priori reason to believe that those are correlated, and Rick didn't stay long enough to insure that there was a correlation.
Users who fall into MP traps should be encouraged to use TeleRaid from another machine on their net (if they have one) to give us better information about where the MP trap is coming from.
*start*
00450 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 18:39 PST
From: Masinter.pa
Subject: AR#203
To: LispSupport.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dandelion
Should be interpreter, not compiler (different category.)
Impact is probably annoying.
Workaround is to compile the function.
Priority hopefully
difficulty easy
I thought you were going to fill in Assigned-to and Attn: to be the same.
*start*
00990 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 19:23 PST
From: Stansbury.pa
Subject: Lisp: DEdit
To: LispSupport.pa
Lisp-System-Date: 14-Mar-84 10:16:58
Machine-Type: Dolphin
A few DEdit things of which Beau is no doubt aware, but which nonetheless ought to get stuck in the AR database:
(1) Can't run DEdit from different processes at the same time or else it gets tangled.
(2) If you have multiple DEdit windows up and then delete past the second, it forgets where the 3rd - nth were and has to reprompt you for their positions.
(3) If you are editing the coms of a file called foo whose main function is called foo, and then you select foo and say Edit, it asks you whether you want to edit the file or the fns definition of foo. It ought to be smart enough to notice (first) that you are already editing the files def of foo, and that if you ask to edit foo again, you mean to edit the other def (namely, fns) of foo.
-- Tayloe.
*start*
00152 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 23:17 PST
From: Kaplan.pa
Subject: AR 84 fixed
To: Lispsupport
*start*
00692 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 MAR 84 17:30 PST
From: ROACH.PA
Subject: AR 85
To: LISPSUPPORT
cc: ROACH
ATTN should be 1100SUPPORT or RAIM. There is nothing I can do
about this problem that I am not able to reproduce on any machine
here at PARC. I've sent at least 3 messages to 1100SUPPORT detailing
my recommendations on how XSIS should handle the situation and/or
asking that XSIS give this user a response of some kind. THERE HAS
BEEN NO ACTION ON THIS PROBLEM, AND THERE WILL BE NO ACTION ON THIS
PROBLEM UNTIL 1100SUPPORT ACTS DIRECTLY WITH THE CUSTOMER OR GIVES
ME INSTRUCTIONS TO TAKE ACTION WITH THIS CUSTOMER.
Kelly
*start*
00485 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 MAR 84 16:04 PST
From: ROACH.PA
Subject: Re: Summaries of LispARs
To: LispSupport
cc: ROACH
In response to your message sent 19 Mar 84 20:20 PST
I think summarizing by System then Subsystem was useful to me.
I also tried summarizing by Subject. The last time I looked, a lot
of fields that might be good to summarize by (e.g., ATTN, PRIORITY,
DIFFICULTY) hadn't been filled in yet.
Kelly
*start*
00425 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 MAR 84 21:56 PST
From: ROACH.PA
Subject: AR 176
To: LISPSUPPORT
cc: ROACH
I believe FLOPPY was writing out one bad page per floppy in a sysout.
This problem is now fixed in <LISPCORE>SOURCES>FLOPPY.DCOM. I've tried
using COPYFILE in SYSOUT mode, installing the sysout, and then chatting
without 9915s with this FLOPPY.DCOM.
Kelly
*start*
00380 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 MAR 84 06:50 PST
From: MASINTER.PA
Subject: Please bring over [Rose]<Lisp>Carol> to Phylum and print press files
To: LispSupport
Raim is giving us an unprecedented opportunity to review docuemntation before it goes out the door. We should not blow it by not taking advantage of this opportunity.
*start*
00485 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 10:55 PST
From: masinter.pa
Subject: AR#204
To: Le.pasa
cc: LispSupport
For the time being, ARs on DLion Disk should be Attn: Stansbury, Assigned To: Purcell.
Change Subject: to "(MKDIR 'DSK) causes 8935936 - ILLEGAL ARG"
Priority: Absolutely
Frequency: Intermittent
Problem type: Bug
Difficulty: Hard
Status: Open
Note in disposition (& to others) that DLIONFS has been temporarily withdrawn.
*start*
00281 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 11:45 PST
From: masinter.pa
Subject: AR#172
To: LispSupport
This is all an artifact of the AR that I fixed re interpreted FPLUS. Why is it marked as an AR on internal system documentation?
*start*
00197 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 12:01 PST
From: masinter.pa
Subject: more edits to ARs
To: LispSupport
AR#130, assign to Sheil, attn: Sheil
*start*
00472 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 10:43 PST
From: masinter.pa
Subject: AR#206
To: LE.PASA
cc: LISPSUPPORT
Change subject from "Lisp: DRAWELLIPSE" to read
Subject: DRAWEELLIPSE does not draw a closed curve
System: Window Graphics, Subsystem: (? Graphics primitives, or library if no such)
Attn: Burton, Assigned to: Burton, Priority: Possibly, Difficulty: Moderate
Impact: annoying, Frequency: Every time
Thanks!
*start*
00324 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 10:46 PST
From: masinter.pa
Subject: AR#207
To: LE.PASA
CC: LISPSUPPORT
Change Subject: to read "SYSOUT to floppy doesn't reset FLOPPY.MODE after",
Assigned To: Roach, too. Impact: Moderate, Frequency: Every time, Priority: Hopefully.
*start*
01493 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 10:56 PST
From: masinter.pa
Subject: [Stansbury.pa: Re: your list]
To: LISPSUPPORT
This turns into two ARs, "can't run multiple DEdits" and "can't run multiple Compilers"
Date: 19 Mar 84 13:59 PST
From: Stansbury.pa
Subject: Re: your list
In-reply-to: MASINTER.PA's message of 18 MAR 84 17:43 PST
To: MASINTER.PA
cc: stansbury.PA, lispsupport.PA
"Could you explain for the record what you think is involved, e.g., some examples of what needs monitor locking and what kinds of problems the lack of monitor locks would prevent or fix?":
Examples:
(1) You can't run instances of DEdit under more than one process at a time, or it gets tangled up. This is a problem that exists right now. Monitor locking wouldn't do any good here; DEdit will have to be rewritten so that different instances of DEdit do not fight over global state.
(2) You can't run multiple instances of the compiler at once. Since the compiler doesn't block, this is a problem we won't really experience until we have a preemtive scheduler. By the time we have a preemtive scheduler, I would think that ideally we should restructure the compiler so that it does not depend upon global state, but a shorter-term solution might be to monitor-lock the global state the compiler uses, so that different instances wait for each other instead of jumping all over each other.
-- Tayloe.
----- End of Forwarded Messages -----
*start*
00625 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 12:00 PST
From: masinter.pa
Subject: more ARs
To: LispSupport
cc: masinter.pa
Submit AR:
Programming environment/file package:
Want CHECKSET functionality in standard file package, i.e., recompile if the versions match and bcompl if not. This is because sometimes RECOMPILE will willingly compile the wrong thing.
Impact: moderate, frequency: intermittent, Prehaps, Bug
Change AR#33 to Generic File operations
Easy -> Moderate
Attn: vanMelle
AR#146: change to Text/Tedit, assignee -> Sybalsky
AR#169: status_ Fixed (today)
*start*
00393 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 13:21:22 PST (Tuesday)
From: le.pasa
Subject: Re: AR#206
In-reply-to: masinter.pa's message of 20 Mar 84 10:43 PST
To: masinter.pa
cc: LE, LISPSUPPORT.pa
Larry,
Does this mean that I should edit this AR and change it accordingly to your message ,or did you or Michael already change it?
Thank you
Thu
*start*
06236 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 11:17 PST
From: Sannella.pa
Subject: [JONL.PA: Re: FULLNAME invariant]
To: LispSupport.pa
----- Forwarded Messages -----
Date: 19 MAR 84 19:22 PST
From: JONL.PA
Subject: Re: FULLNAME invariant
To: MASINTER, lispcore^
cc: JONL
In response to the message sent 18 MAR 84 22:34 PST from MASINTER.PA
In the later paragraphs of this note, I will propose a new function TRUENAME;
it simply isn't reasonable to have OPENSTRINGSTREAM return something from
which you *** can't find a back pointer to the string ***.
Unfortunately, this "invariant" you mention is nowhere documented, nor implied
in the manual or in the relase notes. Furthermore it simply *** cannot *** be
maintained when we permit multiple streams on file devices -- a capability
which the MacLisp world has had "for decades".
Also, I checked the half-dozen places in system code that use
the FULLNAME access, and 90% of them are merely informational -- e.g.,
when \EOSERROR is called, it's trying to tell you something more than
the octal address of the STREAM which hit end-of-file. The other 10%
are used in cases where the stream has assuredly been obtained from a
file device, and thus it will have a litatom fullname; these are the places
that will have to be inspected when multiple openings are permitted.
All that being said against the alleged "invariant", I find that I must
concur with Ron -- that, if you, Larry Masinter, seem to think that
there is such an invariant, then just maybe maybe some other user out
there in the hinterland watched the results of FULLNAME on file devices
and began to write code thinking the same thing.
In order not to risk finding out the hard way if there really are such
users with "breakable" code, I propose to add a new function to FILEIO called
TRUENAME which will return the full file name (if the stream is connected
to some real file on a device), and othewise will return the TRUENAME property
from the "property list" of the stream, the OTHERPROPS field.
TRUENAME is appropriate, since this "invariant" is expressly disavowed
in the MacLisp world (which has such a named function) -- one simply has
to "hang onto" the stream because he can't generally find it again by simply
knowing the file's name. Also, it's conceivable that someday the fullname
field will differ from the "true" name of the file -- this happens on the
ITS file system because of "indirect" files, which are supported in any of
the other popular operating systems.
-----
From: kaplan.pa
Date: 19-Mar-84 22:37:25 PST
Subject: Re: FULLNAME invariant
In-reply-to: JONL's message of 19 MAR 84 19:22 PST
To: JONL
cc: MASINTER, lispcore^
I think there are two very separate uses to which FULLNAME is being put.
One is the use of the FULLNAME of a file/stream as a handle on that file/stream. In this use, the invariant that Larry pointed out must be preserved. It was not being preserved by explicitly opened string streams, and I fixed that by making the FULLNAME of such streams be the stream itself.This make the read macro case work properly (not needing the change suggested later by JonL), but more than that, it made things like (READ (FULLNAME x)) produce the desired behavior of reading from the stream x, and not some new stream whose bytes were the same as the bytes underlying x.
The second use of FULLNAME currently is to provide some user comprehensible description of the stream. This is what is used in error messages, ought to be used in the pname of the stream, and is not subject to any invariant requirements. The description is essentially pure text. The most useful description for a string stream is in fact the string that the stream was originally built on. This was the reason that I originally made the string be the fullname, and in my innocence and ignorance, triggered the bugs that prompted this endless discussion.
My fix to make sure that the invariant property required by use (1) was obeyed had the undesirable side-effect of eliminating the string as serving the use (2) purpose, as JonL has observed.
JonL also correctly observes that in the long run the use (1) invariant cannot be maintained in the current fashion for any stream. This is because we will eventually allow for multiple streams open on the same file, so that if the fullname is simply the full name of the file as it is known on its device, then there could be several streams with the same name. [Indeed, the string streams were installed as the first tentative move in this direction, so it is not surprising that they provoked this conceptual confusion].
We will eventually have to decide how to deal with this, either by eliminating the notion of a type-able fullname as a handle on a stream, by including an integer in the fullname that indicates which stream instance is being specified, or in some other way. But this is for the future--I didn't want to solve this problem when I made my bug fix, nor do I want to solve it now.
However, it does seem important to distinguish the descriptive use of the fullname from the identifier use, because the descriptive use is important and will always be with us. If we start making the distinction now, we will have one less problem to deal with when we finally bite the bullet.
I think we should provide some access fns in the stream record to store the description when the description is not the same as the fullname, as a property in the OTHERPROPS field of the stream. This would be used in system code when reporting errors involving the stream, peraps by the defprint, etc. We should also provide a user handle on this field, perhaps by attributes in GETFILEINFO/SETFILEINFO, or perhaps now is the time to introduce the STREAMPROP function (cause we are really getting at properties of the stream, not the file behind it). In either case, I prefer an attribute name like DESCRIPTION instead of JonL's proposal of TRUENAME--the whole point is that this description does not "name" anything.
I agree with JonL that this should be done, but it is not high on my list of things to do. It probably has a tail of a week or so before everything comes together.
--Ron
*start*
00343 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 17:24 PST
From: Masinter.pa
Subject: Lisp: LOGOCLOCK process should restart after HARDRESET
To: LispSupport.pa
cc: Masinter.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dandelion
it doesn't now/Graphics/Library, Attn: Masinter, Annoying, Perhaps
*start*
00909 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 16:07 PST
From: vanMelle.pa
Subject: new SAMEDIR
To: LispSupport
cc: LispCore^
I put a new version of SAMEDIR on <lispcore>library>, fixing a bug that prevented MIGRATIONS from working, and slightly extending its functionality: the cdr of an entry in MIGRATIONS can now be a list of directories.
Recommend that coms of the local ABC file be modified by adding
(ADDVARS (MIGRATIONS
({PHYLUM}<LISPCORE>SOURCES> {PHYLUM}<LISPNEW>SOURCES> {PHYLUM}<LISP>SOURCES>)
({PHYLUM}<LISPCORE>LIBRARY> {PHYLUM}<LISPNEW>LIBRARY> {PHYLUM}<LISP>LIBRARY>]
so that SAMEDIR doesn't complain when you write a file on <Lispcore>Sources> that you loaded from <Lisp>Sources>, or similarly with >Library.
Potential confusion alert: there is also a version of SAMEDIR on <LispUsers>. It appears to be the same as on <Lisp>Library>.
Bill
*start*
00420 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 17:34 PST
From: Stansbury.pa
Subject: Lisp: Browser
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
Why isn't browser in the library? It really ought to be supported, and frankly deserves our support a lot more than a lot of stuff already in there.
Also ought to be in the full loadup, I think.
-- T.
*start*
00558 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 17:22 PST
From: Masinter.pa
Subject: want FILEDEF property for entries to lisp library packages
To: LispSupport
System: File package, Subsystem: Other (??)
I'm not sure about the category, but I'd like to make sure that the popular Lisp Library packages like LAFITE, CROCK, etc. are such that they have FILEDEF properties that make them auto-load, e.g.,
(PUT 'CROCK 'FILEDEF 'CROCK)
will mean that if you call (CROCK) with CROCK not loaded that it will auto-load it.
*start*
00774 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 18:13 PST
From: Stansbury.pa
Subject: Lisp: Multiple NSPRINTs call non-reentrant GETCLEARINGHOUSE
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
Multiple concurrent hardcopyws (from the hardcopy selection in the paint menu) stomp all over each other: a few get off to the printer, but the rest break with foo: not an open NS socket, with stack
closensocket
ch.broadcast.for.servers
getclearinghouse
parse.ch.name
cha.name.to.string
open.ns.printing.stream
nsprint
All share the same NS socket; presumably the first one done closed it and the rest got confused. Socket seems to be generated in getclearinghouse or ch.broadcast.for.servers.
--Tayloe.
*start*
00487 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 16:25 PST
From: Burton.pa
Subject: Lisp: Menu's stay on top
To: LispSupport.pa
Fixed a glitch in MENU when releasecontrolflg is T.
richard
Date: 27 Jan 84 16:49 PST
From: Burton.pa
Subject: lisp: menu glitch
To: LafiteSupport.pa
Lisp-System-Date: 26-Jan-84 01:48:36
When called with releasecontrolflg, the menu handler should bring the menu window to the top so that it doesn't get covered.
*start*
00944 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 18:48 PST
From: Kaplan.pa
Subject: Re: AR 187 auto-display-after-delete suggestion
In-reply-to: vanMelle.pa's message of 18 Mar 84 21:12 PST
To: vanMelle.pa
cc: kaplan.pa, lafitesupport.pa
Actually, I do have LAFITEDISPLAYAFTERDELETEFLG set to T, but I think I now see the crucial aspect of my environment that is making it not do what I want.
I frequently read mail from home using the GV terminal service. Messages that I read there and don't delete get brought into my browser marked with ? as if they haven't been seen at all. These message then get auto-displayed after deleting a preceding message, even though I don't necessarily want that to happen.
Is there any way of getting more accurate information about what has been seen from the GV? When I delete a message in the GV, it does seem to get marked in a way that Lisp can detect.
--Ron
*start*
00375 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 15:58 PST
From: Burton.pa
Subject: Re: AR 17: ICONW title sensitive to Radix
In-reply-to: lispar.auto's message of 12 Mar 84 16:00:12 PST (Monday)
To: lispar.auto
cc: Sybalsky.PA, vanMelle.PA
Fixed ICONTITLE to BOUT rather than PRIN1 into the title. Seems to fix your problem
richard
*start*
00423 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 16:47 PST
From: Burton.pa
Subject: CURSORINFN and CURSOROUTFN properties extended
To: LispSupport.pa
CURSORINFN and CURSOROUTFN can now be lists of functions as well as single functions. All functions on the list are called.
richard
ps. This was in response to a bug report by Greg Nuyens (I think) and a request from Dan Russell.
*start*
00380 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 19:55 PST
From: Kaplan.pa
Subject: AR 202: closing T
To: Lispsupport
Fixed. CLOSEF on all display streams is now a no-op.
But: looking at the code, I don't see how what Nuyens described could have happened. CLOSEF already had a special check in it to make sure that it didn't close T.
*start*
00260 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@From: masinter.pa
Date: 20-Mar-84 20:16:57 PST
Subject: Re: AR#206
In-reply-to: le.pasa's message of 20 Mar 84 13:21:22 PST (Tuesday)
To: le.pasa
cc: masinter, LISPSUPPORT
You edit it, OK?*start*
00371 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 19:08 PST
From: Kaplan.pa
Subject: Lisp: Release documentation of OPENSTRINGSTREAM
To: LispSupport.pa
cc: Kaplan.pa
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dorado
I don't think this was mentioned in the Fugue.6 release message. Should be documented for the next release.
*start*
00407 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 19:57 PST
From: Kaplan.pa
Subject: AR 36: error from ELT, SETA
To: Lispsupport, Vanmelle
This is a bug of longstanding in the currently released code. I noticed this and fixed it in my last adventure into arrays, which was subsequently withdrawn. The fix will be re-installed when I re-install the new LLARRAYELT.
*start*
00664 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 13:47 PST
From: Halasz.pa
Subject: Lisp: FONTCREATE generates incorrect file name
To: LispSupport.pa
cc:
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
FONTCREATE bombed on me today with an UNPACKFILENAME: ILLEGAL ARG. Perfectly valid args were passed to FONTCREATE, but FONTCREATE tried to open a file whose name was (Halasz.PA , "\:%%- +") which appears to be my password entry.
When I retried the FONTCREATE all worked fine. The first time (i.e., the time FONTCREATE crashed) I was running a LISTFILES in the background with SINGLEFILEINDEX loaded.
Frank
*start*
00844 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 12:05 PST
From: Cooper.pa
Subject: Lisp: Compiler or DWIM bug
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dolphin
I have a function \TCP.CHECK.INPUT.QUEUE which has two PROG variables RCV.NXT and NEXT. It compiles fine when I do (COMPILE '\TCP.CHECK.INPUT.QUEUE). But when I (TCOMPL '{PHYLUM}<COOPER>LISP>TCP;66), I get the output
=NXT
=NXT
(\TCP.CHECK.INPUT.QUEUE (TCB)) (uses: NXT)
and sure enough, it has compiled in a free variable reference to NXT. This seems pretty serious to me, since it's turning correct interpreted code into broken compiled code. For now, I'll try renaming my PROG variables to see if that avoids triggering the bug. I'll leave TCP;66 around for anyone who wants to try to debug this.
Eric
*start*
00375 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 12:47 PST
From: vanMelle.pa
Subject: Lisp: SINGLEFILEINDEX value returned
To: LispSupport.pa
cc: vanMelle.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
It returns NIL now, instead of a list of files to be listed, which is a tad disconcerting--looks like nothing happened.
*start*
00515 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 12:09 PST
From: vanMelle.pa
Subject: Lisp: SINGLEFILEINDEX divide by zero
To: LispSupport.pa
cc: vanMelle.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
I happened to be running with overflow enabled, otherwise this would never break: I got a DIVIDE BY ZERO error in (IQUOTIENT 46 0) in (\SFI.PrintIndexFactors '((\TTWAITBOX . 96))) with localvars values 1, 6 and 100; in PrintIndex in PrintOneTypeIndex.
Bill
*start*
01097 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 09:11 PST
From: Masinter.pa
Subject: Want revised VM specification
In-reply-to: JONL.PA's message of 19 MAR 84 19:22 PST
To: LispSupport
cc: JONL.PA, MASINTER.PA, lispcore^.PA
[AR Documentation/Other, Difficulty: Hard, Priority: Unlikely, Assigned to: Sheil, Attn: JonL, Impact: Moderate]
Unfortunately, a lot of the "invariants" of Interlisp are not documented.
Many were in the Interlisp Virtual Machine Specification by J Moore. That document unfortunately is out of date. One of the ways it is out of date is that it doesn't mention "streams". It is pretty clear that FULLNAME is a unique handle on the open stream. One of the "file assumptions" we are breaking is that we are allowing FULLNAME to be a non-Literal Atom.
One way to couch these design discussions would be to come up with a revision to the appropriate section of the VM; that is a reasonably formal specification which spells out the way in which the pieces interact with each other.
(I'm retrieving the VM document from archive.)
*start*
02044 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 09:46 PST
From: Sannella.pa
Subject: [masinter.pa: Re: FULLNAME invariant]
To: LispSupport.pa
----- Forwarded Messages -----
Date: 20 Mar 84 11:07 PST
From: masinter.pa
Subject: Re: FULLNAME invariant
In-reply-to: kaplan.pa's message of 19-Mar-84 22:37:25 PST
To: kaplan.pa, JonL
cc: lispcore^.pa
Thanks for your analysis. This "invariant" indeed cannot be maintained once we allow multiple streams on the same file; we should spec out the design for the multiple-stream proposal so that this and other ramifications are clear. We should fix the system read macros not to test (EQ file T), but what SHOULD they be testing???
In the interim, it seems that many of the desirata would be alleviated if the printout of the stream datatype were fixed, e.g., if you had a string-stream on "This is a very long stream"
it could print out as
[stream]"This..."
and a stream on {phylum}<LispCore>Fugue>Full.sysout;1 could printout
[stream]{Phylum}<LispCore>Fugue>Full.sysout;1.
Since the string can be very long, cutting off the printout after a fixed number of characters might be reasonable.
I started this on [phylum]<LispUsers>STREAMPNAME. Basically, it just DEFPRINTs STREAM to print out something different. This needs to be expanded to handle the 'final version' of string-streams.
I would imagine that, once the 'informational aspect' of the FULLNAME is gone, it would be more reasonable to change the end-of-file error to have the 'offender' be the STREAM rather than the FULLNAME.
This is (a) less likely to break extant code, since the PNAME of datatypes is advertised as implementation and machine-dependent (b) ALSO necessary on the way to multiple-streams-on-the-same-file (since the end-of-file is on the STREAM and not the file), (c) gives more useful information in a lot of different contexts (e.g., in a stack inspector window, would be nice to see the STREAM argument with more info).
----- End of Forwarded Messages -----
*start*
00352 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 10:35 PST
From: vanMelle.pa
Subject: Lisp: SINGLEFILEINDEX's process
To: LispSupport.pa
cc: vanMelle.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
SINGLEFILEINDEX should spawn its process with BEFOREEXIT = DON'T so that LOGOUT doesn't interrupt it.
*start*
00546 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 10:47 PST
From: Burton.pa
Subject: Lisp: Filemap rewrite code isn't checking error type
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
I ^Eed when a function was being fetched from a file to be editted (after the "loading from mumble;81" msg) and the system rewrote the file map for mumble, then fetched the function. Could the code that traps the error check to see if the error was due to user ^E or (ERROR!) caused by invalid filemap??
richard
*start*
00342 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 11:07 PST
From: Burton.pa
Subject: Lisp: Addendum to filemap making
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
When I did a MAKEFILE on the file that had had its file map rewritten, the system rewrote it again.
richard
*start*
00505 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 08:28:10 PST
From: Maxwell.pa
Subject: Re: Lisp: EMPRESS Odd file name
In-reply-to: "Sheil's message of 19 Mar 84 18:02 PST"
To: Sheil
Cc: LispSupport
The press file was made from a file whose name actually was []<>LispNotes.tioga. Cedar uses "[]<>" instead of "[Hancock]<Cedar>" as a shorthand for the root directory of a local machine. (Thus almost all of the files on a Cedar partition begin with []<>)
John.
*start*
00383 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 10:51 PST
From: Burton.pa
Subject: TEdit: TEDIT.QUITFN - make a list of fns
To: TEditSupport
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
If the quitfns were a list it would be easier for applications to avoid stepping on each other.
richard
*start*
00796 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 10:54 PST
From: MGardner.pa
Subject: TEdit: really wide tabs
To: TEditSupport
cc: MGardner.pa
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dolphin
Got into a state (with Lafite) where Tedit displayed a tab in a message as much wider than its normal default--almost five inches wide. It appeared this way both on the display and on the hardcopy (about 5.5" on the hardcopy). Furthermore, every subsequent call to Tedit had tabs behaving this way; if I do a paragraph Show on an otherwise unformatted document, it fills in Default Tab Size: 60 and one Left Tab set at 35.
By the way, in some earlier editing of another document, I had set a Left Tab at 35.
Mimi
*start*
00376 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 09:26 PST
From: Sybalsky.pa
Subject: Re: TEdit: \TEDIT.BRAVOFILE? takes several minutes
In-reply-to: masinter.pa's message of 20 Mar 84 11:16 PST
To: masinter.pa
cc: TEditSupport.pa
Right now, \TEDIT.BRAVOFILE? scans the file for ^Z's. This can be improved dramatically, and is in queue
*start*
00503 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 09:13 PST
From: Masinter.pa
Subject: Re: standalone
In-reply-to: lichtenberg.wbst's message of 20-Mar-84 10:55:04 EST
To: lichtenberg.wbst
cc: LispSupport, MASINTER.PA, vanmelle.PA
DLions can't talk to themselves. It should be an AR to make it so at the low-level
(for LispSupport; I'd guess: S/s: Os/NS Protocols, Impact: Moderate, Frequency: Everytime, Difficulty: Easy, Priority: Hopefully, attn: vanMelle).
*start*
00685 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 11:22 PST
From: vanMelle.pa
Subject: Re: standalone
In-reply-to: Masinter.pa's message of 21 Mar 84 09:13 PST
To: Masinter.pa
cc: lichtenberg.wbst, LispSupport.pa, vanMelle.PA
Indeed, this is high on my queue to fix (that Dlion's don't hear themselves; the low-level software should fake it). System/Subsystem should be Communications/Low-level ether, a subsystem category I don't see on the old list I have, but which ought to exist. This problem is not specific to either Pup or NS, but rather to the 10mb ethernet driver code. The system files in this category are LLETHER and 10MBDRIVER.
*start*
00583 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 21 MAR 84 13:16:51 PST
Return-path: <@SUMEX-AIM.ARPA:Cornhill.CST@HI-MULTICS.ARPA>
Redistributed: Xerox1100UsersGroup^.PA
Received: from HI-MULTICS.ARPA by SUMEX-AIM.ARPA with TCP; Wed 21 Mar 84 12:06:42-PST
Date: 21 Mar 84 14:00 cst
From: Cornhill.CST@HI-MULTICS.ARPA
Subject: Please remove me from the 1100users mailing list.
To: 1100users@SUMEX-AIM.ARPA
cc: cornhill@HI-MULTICS.ARPA
Please remove me from the 1100users mailing list.
Thanks, Dennis Cornhill
*start*
00293 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 12:25 PST
From: vanMelle.pa
Subject: new TTYIN
To: LispSupport
cc: LispCore^
Now fixed:
sybalsky's AR 16.
several glitches associated with Dedit typein.
it now allows itself to be called recursively.
*start*
00718 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 12:32 PST
From: Stansbury.pa
Subject: Lisp: Floppy: Copyfile and floppy.from.file too slow
To: LispSupport.pa
Lisp-System-Date: 14-Mar-84 10:16:58
Machine-Type: Dolphin
Copyfiling a large file or sysout to floppies or using floppy.from.file runs awfully slowly: close to 20 minutes per floppy. Creating the same floppy from scratch in Tajo runs noticeably quicker.
I spoke to Kelly and he said that there were a lot of diagnostic checks in that code which slow it down a lot, and which could probably now be removed. Perhaps those checks could be taken out in the near future to make life easier for floppymakers.
-- Tayloe.
*start*
00825 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Wed, 21 Mar 84 14:03 PST
From: Raim.pasa
Subject: Re: AR 224: Internal users should get release info
In-reply-to: "Your message of 21 Mar 84 12:39:22 PST (Wednesday)"
To: LispSupport.PA
cc: Raim
Michael,
A good question.
Til now, Xerox people have gotten all Interlisp technical documentation either from release messages or files stored on Phylum. Customer documentation, which is usually a subset of that information, is not routinely distributed to Xerox users.
I advocate setting up a procedure for getting customer documentation into the hands of internal users. They should be able to get it for free bygrabbing the right press files; or at some nominal cost if they want bound editions (forthcoming with the next release.)
--Marty
*start*
00826 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 14:04 PST
From: Jellinek.pa
Format: TEdit
Subject: Lisp: DEdit redisplay (DEDITREPAINTFN) bug
To: LispSupport.pa
cc: Jellinek.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dolphin
When in DEdit, if you select some items and then left-button redisplay in the DEdit window, the items lose their highlighting, though they are still selected. This is especially noticeable if you then middle-button clear (on the swap sub-menu) -- the highlighting magically reappears.
So it seems that the problem is in DEDITREPAINTFN.
~Herb
��
���
TIMESROMAN� ����������� ���
TIMESROMAN� ����������’���
TIMESROMAN� ��������������
TIMESROMAN� ���������� ���
TIMESROMAN� ��������������
TIMESROMAN� ����������p���
TIMESROMAN� ����������'�z·*start*
00760 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 15:36 PST
From: Masinter.pa
Subject: [Don.Cohen <DONC@USC-ISIF.ARPA>: Another weird interlisp behavior]
To: LISPSUPPORT
----- Forwarded Messages -----
Received: from USC-ISIF.ARPA by PARC-MAXC.ARPA; 21 MAR 84 11:34:51 PST
Date: 21 Mar 84 11:29 PST
Subject: Another weird interlisp behavior
From: Don.Cohen <DONC@USC-ISIF.ARPA>
To: masinter.PA, ddyer@USC-ISIF.ARPA
It seems that the distinction between EVAL and APPLY format is fooled by:
'(a s
d]
(notice that without the carriage return this works fine)
On both vax and dolphin (I haven't tried 10) this complains that
(QUOTE (a s d)) is an undefined function.
-------
----- End of Forwarded Messages -----
*start*
00603 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 18:22 EST
From: Marshall.wbst
Subject: Lisp: Color display bug
To: LispSupport.pa
cc: Marshall.WBST
Lisp-System-Date: 26-Jan-84 01:48:36
Machine-Type: Dorado
If I (LOGOUT) with the color display on the system crashes after writing out virtual pages (i.e., it never makes it to the alto exec) and resuming lisp will hang on the first color display operation. I am using LLCOLOR of ("13-Dec-83 10:54:01" . {PHYLUM}<LISP>LIBRARY>LLCOLOR.;4). If I call (COLORDISPLAY) before (LOGOUT) things seem to work ok.
--Sidney
*start*
00595 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 16:12 PST
From: Masinter.pa
Subject: Lisp: AIN from T breaks with with ILLEGAL STACK ARG (\BIN \PEEKBIN)
To: LispSupport.pa
cc: Masinter.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dandelion
The problem is that \READREFILL is looking for an explicit \BIN or \PEEKBIN and it is doing BINS instead.
This whole interface from \READREFILL is pretty hokey.
Impact: Minor
(this is a pretty odd thing to do)
Frequency: Everytime
(can reproduce)
Priority: Unlikely
Attn: Kaplan
Assigned to: Masinter
*start*
00372 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 14:25 PST
From: Halvorsen.pa
Subject: Lafite: Invalid HOST/DIR
To: LafiteSupport.pa
cc: Halvorsen.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dandelion
\LAFITEDEFAULTHOST&DIR claims that {phylum}<halvorsen>mail> is an invaldi HOST/DIR
*start*
00467 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 15:46 PST
From: vanMelle.pa
Subject: Re: Lafite: Invalid HOST/DIR
In-reply-to: Halvorsen.pa's message of 21 Mar 84 14:25 PST
To: Halvorsen.pa
cc: LafiteSupport.pa
Are you sure you had a closing ">" on that? Lafite is slightly fussier than CONN, which happily sticks a ">" on the end if you forgot.
If that was not the problem, was Phylum being unresponsive at the time?
Bill
*start*
00487 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 16:19 PST
From: Halvorsen.pa
Subject: Re: Lafite: Invalid HOST/DIR
In-reply-to: vanMelle.pa's message of 21 Mar 84 15:46 PST
To: vanMelle.pa
cc: LafiteSupport.pa
Yes, you are right, I noticed after I sent the msg that Phylum wasn't responding. Next time I tried (this time explicitly passing the name of the mailfile rather than relying on the default setting for lafitehost&dir) things worked ok.
*start*
01039 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 18:31 EST
From: Marshall.wbst
Subject: Lafite: Registry setting
To: LafiteSupport.pa
cc: Marshall.wbst
Lafite-System-Date: 24-Jan-84 15:08:21
Lisp-System-Date: 26-Jan-84 01:48:36
Machine-Type: Dorado
It was not obvious to me how to set the registry of the mail system. Blue-bugging "sendmail" brought up this form and defaulted the registry to NIL after my name even though my name is Marshall.wbst on the disk and the other password modules seem to set their registry ok. Attempts to send the message resulted in "Illegal RName" and "no server responded" messages. This was confusing. I figured out what happened by monitoring the ethernet. I would suggest either picking off the registry from the disk name or having some menu-driven way to set and reset the registry. A clearer error message (e.g., "Marshall.NIL is not a valid name") would also be nice.
The above is not a complaint as I think the lisp system is one of the best going.
--Sidney
*start*
00785 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 16:49 PST
From: Burton.pa
Subject: Lisp: response to ar 170
To: LispSupport.pa
cc: sheil.pa
Status: Declined?
Intentional (though arguably bad) design. Did you not believe it when you read it or was it not clear? Could you suggest a rewording?
Relevant section included below for convenience.
{Def {Type (Window Property)} {Name HEIGHT}}
{Def {Type (Window Property)} {Name WIDTH}
{Text
Value is the height and width of the interior of the window (the usable space not counting the border and title).
}}
{Def {Type (Window Property)} {Name REGION}
{Text
Value is a region (in screen coordinates) indicating where the window (counting the border and title) is located on the screen.
}}
*start*
00208 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 16:51 PST
From: Burton.pa
Subject: Lisp: ARs 195, 126, and 17 have been fixed
To: LispSupport.pa
earlier in the week.
*start*
00282 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 16:53 PST
From: Burton.pa
Subject: AR 197 fixed
To: LISPSUPPORT.PA
cc: Sheil
The problem was the MOUSESTATE-EXPR contained clisp and was being run interpreted. I removed the clisp.
richard
*start*
01203 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 16:59 PST
From: Masinter.pa
Subject: Lisp: TWO BUGS
To: LispSupport.pa
cc: Masinter.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dandelion
First bug:Subject: Lisp: GC under TEdit causes 9305
To: LispSupport.pa
cc: Masinter.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dandelion
I dunno if this is DLion microcode or TEdit or a combination of both. Something that TEDIT has on its stack when a GC gets invoked causes the DLion GC to get a 9305. Probably it is trying to reference count on the stack something that isn't a valid pointer. I guess this is a DLion microcode problem, but it is pretty serious. Could be fixed by either fixing DLion microcode or TEdit, I would guess.
Intermittent, Serious, Attn: Charnley, Sybalsky, Hopefully, Difficulty: Moderate
Second bug:
in sending the first bug report, I got an ILLEGAL ARG - NIL under GV.ADDTOITEM. I think the problem was the COPYBYTES from the TextStream to the BSP stream got a NIL as the value of BIN from the textstream. This could be an artifact of the previous report where I had a problem because it crashed in the middle of a GC.
*start*
00498 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 16:57 PST
From: Jellinek.pa
Subject: TEdit: Problem with Hardcopy and embedded bitmaps
To: TEditSupport
cc: Jellinek.pa
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dolphin
When I use CTL-O to insert a bitmap into a document and then get a hardcopy of that document, the bitmap does not appear. This occurs with both Press printers and Interpress printers.
~Herb
*start*
00421 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 17:30 PST
From: Masinter.pa
Subject: Re: release of LispUsers package FINGER
In-reply-to: Nuyens.pa's message of 18 Mar 84 19:00 PST
To: Nuyens.pa
cc: LispUsers^.pa
are you sure that your Finger program doesn't polute the net?
Also, I couldn't get it to print anything on a DLion, have you been able to get it to print something?
*start*
00638 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 18:24 PST
From: Stansbury.pa
Subject: TEdit: Get & Include
To: TEditSupport
cc: Stansbury.pa
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 14-Mar-84 10:16:58
Machine-Type: Dolphin
Would like TEdit to do something reasonable when given a wildcarded filename to Get or Include, where "something reasonable" means something like putting up a menu of files matching the wildcard, and then doing the operation on whichever one you select from the menu, or else just doing the op if there is only one file which matches the wildcard.
-- Tayloe.
*start*
01132 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 21 MAR 84 18:17:22 PST
Return-path: <@SUMEX-AIM.ARPA:Jellinek.pa@PARC-GW.ARPA>
Redistributed: Xerox1100UsersGroup^.PA
Received: from PARC-GW.ARPA by SUMEX-AIM.ARPA with TCP; Wed 21 Mar 84 17:41:02-PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 21 MAR 84 17:41:15 PST
Date: 21 Mar 84 17:34 PST
From: Jellinek.pa@PARC-GW.ARPA
Subject: Re: Common Lisp compatibility
To: schoen@sumex-aim.ARPA, 1100users@sumex-aim.ARPA
cc: Jellinek.pa@PARC-GW.ARPA
Eric -
Yes, I've written a bidirectional Franz(Mac)Lisp <-> Interlisp
translator, called Odradek. Briefly: it's a program written in Prolog
that has/is a database of equivalent constructs in the two dialects.
Odradek descends recursively through your code, translating merrily as
it goes. It works well.
Unfortunately, the code belongs to my ex-employer; I can't give you a
copy. If you know Prolog, it shouldn't be hard to write. In fact, I
had it running within an hour of its conception. I'd be happy to
explain how to write something similar.
~Herb
*start*
00926 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 22 MAR 84 05:35:16 PST
Return-path: <@SUMEX-AIM.ARPA:GREENFELD@BBNG.ARPA>
Redistributed: Xerox1100UsersGroup^.PA
Received: from BBNG.ARPA by SUMEX-AIM.ARPA with TCP; Thu 22 Mar 84 04:54:03-PST
Date: 22 Mar 84 07:54 EST
Sender: GREENFELD@BBNG.ARPA
Subject: Re: Common Lisp compatibility
From: GREENFELD@BBNG.ARPA
To: Schoen@SUMEX-AIM.ARPA
Cc: 1100users@SUMEX-AIM.ARPA
Message-ID: <[BBNG]22-Mar-84 07:54:52.GREENFELD>
In-Reply-To: The message of Sat 17 Mar 84 20:36:10-PST from Eric Schoen <Schoen@SUMEX-AIM.ARPA>
We did a small translator of Interlisp to CommonLisp when we were
evaluating delivery vehicles. It wasn't too hard, but was just a
hack, tuned for translating our testing programs. We would also
be interested in a carefully done program, or might get around to it
ourselves someday.
Norton
*start*
00437 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 MAR 84 23:08 PST
From: MASINTER.PA
Subject: Get & include
To: stansbury
cc: Teditsupport
Seems like that could be part of a wider facility.
In fact, Tayloe, you could probably do it yourself by keying off the FILE NOT FOUND error with ERRORTYPELST to see if it had a * in it, and if so, to MENU with FILDIR.
Would be a nice package for <LispUsers>.
*start*
00644 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 18:30 PST
From: Stansbury.pa
Subject: TEdit: Get & ttyin
To: TEditSupport
cc: Stansbury.pa
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 14-Mar-84 10:16:58
Machine-Type: Dolphin
When you select Get and TEdit prompts you for a filename in the promptwindow, it does not run TTYIN. Sometimes frustrating. Could be the case with other things in the menu, but I haven't checked.
Would be nice also if Get prompted you with the last file you Got, on the assumption that you tend to get things from more or less the same directory a lot.
--Tayloe.
*start*
00802 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 20:55 PST
From: desRivieres.pa
Subject: Lisp: Use of mouse to restart printing
To: LispSupport.pa
cc: desRivieres.pa
Lisp-System-Date: 14-Mar-84 10:16:58
Machine-Type: Dorado
When a display stream is in a suspended state because information is about to be scrolled off the top, it would be convenient if bugging it with the left button, say, would cause it to proceed; the right button could still be used to bring it to the surface without starting it up. And perhaps middle button could be used to say "resume printing and don't stop again" --- this might also clear up some of the problems with typeahead being send to the wrong place when possesion of the tty is moving around under program control.
---Jim
*start*
00458 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 21:18 PST
From: Halasz.pa
Subject: TEdit: No way to close a TEDIT menu once opened
To: TEditSupport
cc:
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
There should be a way to close (unexpand) a Tedit meenu once its been open. Right now, once you open a TEditMenuits stays open until you Quit the main window.
Frank
*start*
00547 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 MAR 84 09:44 PST
From: MASINTER.PA
Subject: RECORD AR
To: lispsupport
cc: vanMelle
Bill, did you do a SIZEF as well as a LOCF? Is LOCF and friends documented?
22 - *******************************************
Date: 21 Mar 84 19:01 PST
From: Stansbury.pa
Subject: RECORD question
To: Masinter
cc: Stansbury.pa
If you have a blockrecord, is there some convenient way of asking how big (in words) it is? For example, in Mesa you say SIZE[typeName].
-- Tayloe.
*start*
00619 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 10:50 PST
From: vanMelle.pa
Subject: Re: RECORD AR
In-reply-to: MASINTER.PA's message of 22 MAR 84 09:44 PST
To: Stansbury, MASINTER.PA
cc: lispsupport.PA, vanMelle.PA
No, I didn't know how to do a size. In the case of blockrecords, the best I know to do is define a dummy field at the end of the record (LASTFIELD WORD) and then ask for (INDEXF (fetch LASTFIELD of T)).
If LOCF is not documented in the implementors manual, I'll be happy to add a blurb. Is there a keeper of the manual, or can I just go in and edit it?
Bill
*start*
00950 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 10:48 PST
From: Kaplan.pa
Subject: Re: AR 250: Filemap rewrite code should check error type
In-reply-to: LispSupport.pa's message of 22 Mar 84 10:28:32 PST (Thursday)
To: LispSupport.pa
I'm not a filemap expert. I think JonL was last in there, perhaps Bill or Larry.
But you might add the following complaint:
I had a filemap loaded for FOO;1, then said to PF a function from FOO;2 on a host for which I wasn't logged in. Not noticing what was going on, I ctl-Ed while it was asking for the password.
It then went on to do the PF from the FOO;2, but IT USED THE FILEMAP FOR FOO;1.
Don't know whether this particular problem should be fixed by /REMPROPing the old filemap before starting (under a resetsave), or by having some higher level test (e.g. in PF) about whether the filemap that it gets back is actually the one for the file it was interested in.
*start*
01310 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 10:52 PST
From: Kaplan.pa
Subject: Lafite Wish: Toggle for TTY message display format
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 frequently get messages from the arpanet that are formatted for a standard TTY--fixed pitch font with tabs every 8 spaces. There seems to be no easy way of seeing those messages nicely formatted in Lafite. I have to muck around to get the font changed from the variable pitch font that I prefer for most messages, and even after doing that, the tabs are not right.
I'd like a toggle, perhaps on a middle-button popup in the message display window, that goes back and forth to TTY display mode (fixed pitch font, 8 space tabs, perhaps automatically extending the window how to a a minimum of 72 or 80 spaces). I'd also like the hardcopy of a message being displayed in such a mode to be in TTY mode also (recall my earlier request to have a hardcopy button attached to the message display window as well as the browser). But the hardcopy toggle should of course be available for messages not being displayed, as an option in the wished for middle-button subcommand pop-up on the browser hardcopy button.
--Ron
*start*
00649 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 11:21 PST
From: Sheil.pa
Subject: Re: Lisp: response to ar 170
In-reply-to: Burton.pa's message of 21 Mar 84 16:49 PST
To: Burton.pa
cc: LispSupport.pa
If the display clipping region is temporarily reset, the WIDTH and HEIGHT is *NOT* "the height and width of the interior of the window" but are the relevant values for the current clipping region. The documentation is just plain wrong as it currently stands.
Since one can get the WIDTH and HEIGHT of the region from the region, if that's what one wants, I do argue that the design should be changed.
Beau
*start*
00499 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 11:13 PST
From: Burton.pa
Subject: Lisp: TAB accepts files as MINSPACES arg
To: LispSupport.pa
cc: lispcore^
Lisp-System-Date: 15-Mar-84 00:13:18
(TAB pos minspaces file) The legal values of minspaces are NIL, T and a number. It doesn't generate an error if minspaces is a file name but behaves in T case. I propose it generate an error so that users find the easy-to-make error of (TAB 30 FILE).
richard
*start*
00584 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 09:51 PST
From: Sannella.pa
Subject: [Raim.pasa: Re: Gensym]
To: LispSupport.pa
----- Forwarded Messages -----
Date: Tue, 20 Mar 84 19:58 PST
From: Raim.pasa
Subject: Re: Gensym
In-reply-to: "JONL.PA's message of 19 MAR 84 18:46 PST"
To: JONL.PA
cc: Masinter.PA, Raim, LispCore^.PA
Reply-To: Raim.pasa
JonL,
Boeing was assuming GENNUM was initialized to 10000 and, perhaps foolishly, created some dependencies on that being the case.
--Marty
----- End of Forwarded Messages -----
*start*
00737 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 18:54 PST
From: Kaplan.pa
Subject: Lisp: P.S. New GENSYM
To: JonL, LispSupport.pa
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dorado
Actually, I don't quite see the need for all this new complexity in GENSYM. Any user who wanted to do something fancy with prefixes and suffixes could very easily call PACK*. The only new capability seems to be NEW?, and that could be made available with a separate utility to apply to a string to determine whether an atom with the string as pname already exists.
[Although note that you can't in general guarantee unique symbols unless you allow uninterned atoms, which is a known disaster.]
--Ron
*start*
00545 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 18:50 PST
From: Kaplan.pa
Subject: Lisp: New GENSYM
To: JonL, LispSupport.pa
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dorado
I remember some messages about GENSYM awhile ago, but I thought that there were still open questions about the new proposed design, and that it hadn't been installed yet.
Looking at the argument list, I can more or less figure out what PREFIX, NUMSUFFIX, and NEW? might mean. What are OSTRBUFFER and CHARCODE ?
--Ron
*start*
00190 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 17:40 PST
From: Masinter.pa
Subject: resolve GENSYM mess
To: LispSupport
Attn: Sheil
no other fields
*start*
00389 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 MAR 84 17:20 PST
From: ROACH.PA
Subject: AR.SHOW OF <LISPUSERS>AREDIT DOESN'T WORK
To: LISPSUPPORT
cc: ROACH, MASINTER
After LOADing <LISPUSERS>AREDIT.DCOM;5, I do
(AR.SHOW 83)
I get an "AR Layout" window with "Number:" in boldface and
a break "NIL - NON-NUMERIC ARG" under AR.SHOWFIELD.
Kelly
*start*
00274 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 10:06 PST
From: Burton.pa
Subject: Lisp: AR 38 fixed
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dorado
See msg about wbreak fixes of a few days ago.
richard
*start*
00542 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Mar 84 14:33 PST
From: Stansbury.pa
Subject: Re: AR 41: READ, OPENSTRINGSTREAM, & RDTBL
In-reply-to: MASINTER.PA's message of 17 MAR 84 22:54 PST
To: MASINTER.PA
cc: LISPSUPPORT.PA, DesRivieres.PA, Lispcore^.PA, Sheil.pa
Top tasks for near future:
* DLionFS
* NS Filing
* Lafite on NS fileservers
* Rewriting or monitor-locking parts of the system which cannot have more than one instance running
* Processes: preemptive scheduling and interrupts
-- Tayloe.
*start*
00488 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 MAR 84 17:43 PST
From: MASINTER.PA
Subject: your list
To: stansbury
cc: lispsupport
most of the items in your list have ARs, but the preemptive scheduling and monitor lock ones dont. (They are both Very Hard, too.)
Could you explain for the record what you think is involved, e.g., some examples of what needs monitor locking and what kinds of problems the lack of monitor locks would prevent or fix?
*start*
01259 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 13:59 PST
From: Stansbury.pa
Subject: Re: your list
In-reply-to: MASINTER.PA's message of 18 MAR 84 17:43 PST
To: MASINTER.PA
cc: stansbury.PA, lispsupport.PA
"Could you explain for the record what you think is involved, e.g., some examples of what needs monitor locking and what kinds of problems the lack of monitor locks would prevent or fix?":
Examples:
(1) You can't run instances of DEdit under more than one process at a time, or it gets tangled up. This is a problem that exists right now. Monitor locking wouldn't do any good here; DEdit will have to be rewritten so that different instances of DEdit do not fight over global state.
(2) You can't run multiple instances of the compiler at once. Since the compiler doesn't block, this is a problem we won't really experience until we have a preemtive scheduler. By the time we have a preemtive scheduler, I would think that ideally we should restructure the compiler so that it does not depend upon global state, but a shorter-term solution might be to monitor-lock the global state the compiler uses, so that different instances wait for each other instead of jumping all over each other.
-- Tayloe.
*start*
00279 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 17:30 PST
From: Masinter.pa
Subject: Re: your list
In-reply-to: Stansbury.pa's message of 19 Mar 84 13:59 PST
To: Stansbury.pa
cc: MASINTER.PA, lispsupport.PA
did these get turned into ARs?
*start*
00571 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 8 MAR 84 22:28 PST
From: MASINTER.PA
Subject: bug in "change" translation fixed
To: LispSupport
cc: Maxwell, Card, Wallace
There was a bug in the "change" translation package where (change (fetch FOO X) --) without the "of" noise word was not translated properly (it assumed that the 3rd element of the "fetch" was the token OF and always used the 4th element).
I have now fixed this in <LispCore>Sources>RECORD. To be in next loadup after I compile (I made the edit on Maxc from home.)
*start*
00507 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 9 Mar 84 09:03 PST
From: Kay.pa
Subject: Lisp: The {LPT} device
To: LispSupport.pa
cc: Kay.pa
Lisp-System-Date: 26-Jan-84 01:48:36
Machine-Type: Dolphin
I say DRIBBLE({LPT}DRIBBLE), do some stuff, and then DRIBBLE(). After a while, I go into a Break and am told that the HOST is unknown. Turns out that EFTP has been called with DRIBBLE as the host. I reset this to EXPRESSO, revert, and procede without trouble.
--Martin
*start*
00478 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@From: KAPLAN.pa
Date: 3-Jan-01 8:45:14 PST
Subject: Re: Lisp: The {LPT} device
In-reply-to: Kay's message of 9 Mar 84 09:03 PST
To: Kay
cc: LispSupport
That's a feature, not a bug, recently installed by Larry.
For device {LPT}, the namefield of a filename is interpeted as a host/server name. {LPT}EXPRESSO is what you wanted to say, or just {LPT}, which then uses the printer search mechanism.
--Ron
*start*
00477 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Fri, 9 Mar 84 15:31 PST
From: Raim.pasa
Subject: Boeing Expert System Presentation
To: 1100Core^.Pasa
cc: Sheil.PA, LispSupport.PA,
Reply-To: Raim.pasa
John Boose of Boeing AI Center will present his "Expertise Transfer System" on Monday, March 19 at 10:00 am in the 1100 Conference Room. John's system automatically interviews an expert and "absorbs" his knowledge. It's impressive to watch.
*start*
00338 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: Fri, 9 Mar 84 15:35 PST
From: CARD.PA
Subject: Re: LISP CRASH
In-reply-to: "JONL's message of 6 MAR 84 18:25 PST"
To: JONL
cc: LISPSUPPORT
On a Dolphin. I found a flaky memory board in it today, and the crashes have gone away, so maybe it was hardware.
stu
*start*
00353 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 9 Mar 84 17:10 PST
From: vanMelle.pa
Subject: Re: Lisp: Documentation of MP Codes on DLION
In-reply-to: Halasz.pa's message of 9 Mar 84 16:31 PST
To: Halasz.pa
cc: LispSupport.pa
Indeed, we are updating this list. In fact, I'm editing it right now.
How's that for timely?
*start*
00459 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 15:13 EST
From: Denber.wbst
Subject: Re: Lafite: NEWMAILTUNE
In-reply-to: vanMelle.pa's message of 16 Mar 84 15:57 PST
To: vanMelle.pa
cc: LafiteSupport.pa
"One has to run on a Dandelion."
Not anymore! I've taught my D0 how to do it (with some help from a TI sound chip). I've got PLAY running but I am as yet NEWMAILTUNE-less. Restart Lafite perhaps?
- Michel
*start*
00604 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 19 Mar 84 12:50 PST
From: vanMelle.pa
Subject: Re: Lafite: NEWMAILTUNE
In-reply-to: Denber.wbst's message of 19 Mar 84 15:13 EST
To: Denber.wbst
cc: LafiteSupport.pa
That's very nice, but of course Lafite has no way of knowing you are on a machine that can play tunes. Calling PLAYTUNE on an ordinary Dolphin or Dorado just hangs.
Have you redefined PLAYTUNE? If so, and we changed the system PLAYTUNE to be a no-op on non-Dandelions, then Lafite could go ahead and call it without checking your machine type first.
Bill
*start*
00479 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 12:25 EST
From: Denber.wbst
Subject: Re: Lafite: NEWMAILTUNE
In-reply-to: vanMelle.pa's message of 19 Mar 84 12:50 PST
To: vanMelle.pa
cc: LafiteSupport.pa
Ah - I deduce from your answer that Lafite refuses to call PLAYTUNE unless it's running on a Dandelion? I didn't even change that much - I just redefined BEEPON and BEEPOFF. I thought PLAYTUNE already was a NOP on D0's.
- Michel
*start*
00400 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 11:44 PST
From: halvorsen.pa
Subject: Re: release of LispUsers package FINGER
In-reply-to: Masinter.pa's message of 21 Mar 84 17:30 PST
To: Masinter.pa
cc: Nuyens.pa, LispUsers^.pa
I get it to print on a Dlion, but as I mentioned to Greg, updates sometimes give unexpected results (users fall out and reappear).
*start*
00839 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 11:44 PST
From: Burton.pa
Subject: Lisp: DC FOO if FOO.LSP is a file
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
used to not work. Now does. Included below is my message about it. I believe Jeff Schulman has also sent this in a couple of times.
richard
Date: 17 Feb 84 12:41 PST
From: Burton.pa
Subject: Lisp: DC foo doesn't work
To: LispSupport.pa
Lisp-System-Date: 16-Feb-84 19:39:31
when the file has an extension. It appears that the user has to type DC FOO.LSP Seems like DC FOO should probably work. One place to fix it is in HASDEF which current just checks (MEMB foo FILELST). I can fix it to look at FILELST and see if any elements of it are of the form FOO.xxx. Is this going to mess up other things?
richard
*start*
00536 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 12:07 PST
From: Jellinek.pa
Subject: TEdit: Shrinking TEdit windows (suggestion)
To: TEditSupport
cc: Jellinek.pa
TEdit-System-Date: 2-Mar-84 16:54:27
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dolphin
I suggest that when TEdit windows get shrunk they turn into something other than the default "title-bar" icon. Something distinctive, with the name of the document embedded within, perhaps. A scroll or pencil or ....
Comments?
~Herb
*start*
00432 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 Mar 84 17:19 PST
From: withgott.pa
Subject: TEdit: unknown ufn?
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 inserting new text mid-line, I've started getting 9915's. Teleraid reveals "UNKNOWN UFN" under "\PUSHTEXT" under "TEDIT.INSERT.UPDATESCREEN."
-Meg
*start*
00252 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 21 MAR 84 23:11 PST
From: MASINTER.PA
Subject: "unknown UFNs"
To: withgott
cc: TEditSupport
If you get one again, try to find me or possibly vanMelle to look at it, OK?
*start*
01229 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 12:27 PST
From: vanMelle.pa
Subject: Another FNX pagecross bug?
To: Charnley, Purcell
cc: vanMelle.pa, Masinter, LispSupport
Meg Withgott was running tedit inside Loops made on top of a lisp makesysdate 15-Mar-84 00:13:18, and got a 9915, Unknown Ufn at PC 1632 in \PUSHTEXT. 1632 is beyond the end of \PUSHTEXT's code. By tracing thru \PUSHTEXT, it appears that the program had gotten as far as finishing a call to BKBITBLT which happened to be the last instruction on a page. The code looks like
624: 15 12 7 316 FNX(12) BKBITBLT
-----page break here-----
630: 277 POP
631: 105 IVAR TEXTOBJ
Pc 1632 is, of course, almost exactly a page later. If you interpret the words starting at byte 1630 as code you get
1630: 0 unknown
1631: 100 IVAR0
1632: 0 unknown
I tried to rectify the contents of the stack with the code, which was painful because PRINTCODE's stk level indication lies, and it appears that the stack contents are consistent with the POP not having been executed, but the IVAR0 having been (the top of stack is the first Ivar, and the next element is T, which is a likely result of the BKBITBLT call).
Bill
*start*
00515 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 09:40 PST
From: Sheil.pa
Subject: Lisp: Init asks for file QXZRYU.WJK
To: LispSupport.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dolphin
While starting up the new FULL.SYSOUT, I got a message (during the init/greet phase) telling me that Phylum was not responding for the file {PHYLUM}<SHEIL>QXZRYU.WJK.
My init and greet files dont ask for such a file (and indeed, there isn't one).
What's going on here?
Beau
*start*
00551 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 12:35 PST
From: vanMelle.pa
Subject: Re: Lisp: Init asks for file QXZRYU.WJK
In-reply-to: LispSupport.pa's message of 22 Mar 84 12:16:16 PST (Thursday)
To: LispSupport.pa
cc: LispCore^.pa, Masinter.pa, Sheil
It's a kludge used to implement DIRECTORYNAMEP.
This is related to AR 12, whose general problem is: Leaf should not give "not responding" messages on non-user visible operations, such as internal closes and the funny file name for DIRECTORYNAMEP.
Bill
*start*
00261 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 13:04 PST
From: Stansbury.pa
Subject: Lisp: Should allow arrayspace to grow at expense of MDS
To: LispSupport.pa
Lisp-System-Date: 14-Mar-84 10:16:58
Machine-Type: Dolphin
*start*
00509 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 14:45:29 PST (Thursday)
From: Masinter.PA
Subject: Re: RECORD AR
In-reply-to: vanMelle's message of 22 Mar 84 10:50 PST
To: vanMelle
cc: Stansbury, MASINTER, lispsupport
Hm, that might even be a good idiom, e.g.
(BLOCKRECORD FOO (xxxx (lastfield WORD))
(ACCESSFNS FOO (SIZE (INDEXF (fetch lastfield of FOO]
then (fetch (FOO SIZE) T).
Certainly a hack, and an AR (problem type: design, User Interface).
*start*
00631 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 17:51:35 PST (Thursday)
From: Masinter.PA
Subject: "Revised Internal Design of Spice Lisp"
To: ComputerResearch^, LispFriends^
reply-to: Lilly.pa
I have a copy of a CMU report by that title, by Skef Wholey, Scott Fahlman and Joseph Ginder. It describes the instruction set and data structures used in the PERQ implementation of CommonLisp. It presumes that you already know a lot about the implementation, and is 83 pages long.
If you are interested in a copy in advance of Scott Fahlman's visit (mid-April), send mail to (Susi) Lilly.PA.
*start*
00536 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 17:54 PST
From: Stansbury.pa
Subject: Lisp: Block compiler should rename globalvars
To: LispSupport.pa
cc: Stansbury.pa
Lisp-System-Date: 14-Mar-84 10:16:58
Machine-Type: Dolphin
I think that there should be a mechanism of identifying to the block compiler globalvars which are local to a block, and that the block compiler should rename those variables (by prepending \blockname/) to try to avoid name-conflicts with other globalvars.
-- Tayloe.
*start*
00514 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 19:01 PST
Sender: halvorsen.pa
Subject: Lisp: FLOPPY error
To: LispSupport.pa
From: Kaplan
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dandelion
We had the press file Tiffany.Press written on a floppy. When we tried to (INFILE '{FLOPPY}TIFFANY.PRESS), we got an error ARG NOT LP: NIL.
This was from a \DTESTFAIL inside \SFLOPPY.OPENHUGEFILE, at PC 117. The file shows on the DIR listing as having 206 pages.
--Ron
*start*
00450 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 19:18 PST
From: Nuyens.pa
Subject: Re: TEdit: Shrinking TEdit windows (suggestion)
In-reply-to: Jellinek.pa's message of 22 Mar 84 12:07 PST
To: Jellinek.pa
cc: TEditSupport.pa
Hi,
Yup. I have just been looking at some candidates. We are going to try and align with Gumby's Emacs built on Tedit. (i.e. his icon will be TEdit's plus something else)
Greg
*start*
01279 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 19:40 PST
From: Kaplan.pa
Subject: Lisp: More on floppy error
To: LispSupport.pa
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dorado
We discovered that the problem was that we were trying to get a file off of a floppy in a system in which we had previously done FLOPPY.MODE(SYSOUT) to save a sysout.
When we did FLOPPY.MODE(PILOT), the error disappeared and everything worked fine.
It is still a bug that the the floppy code gives the user a totally incomprehensible message in this situation, instead of informing him that he has the wrong floppy mode--or better still, flipping the floppy mode to be whatever is good for the floppy that is in there. When the floppy is reading, why can't it look at the disk and figure out what kind of mode it has. And if the mode is wrong, why is it that it can get at the directory without any problem?
It also seems reasonable to me to have the floppy revert to its base mode (PILOT) after it has finished writing a sysout and the disk has been removed and replaced.
--RON
P.S. You might want to inform 1100 support about the cause of this LP error; perhaps it should be noted in the release message as a known problem with this release.
*start*
01028 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 20:15 PST
From: Kaplan.pa
Subject: Lisp: Compiler glitch
To: LispSupport.pa
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dorado
I was working on 2 unrelated files at once, with both of them loaded. One defined FOO as a constant, and the other had a function FUM that had FOO has an argument.
FUM worked correctly interpreted, but not when compiled. After wasting an hour trying to debug the situation, I discovered that even though FUM had a binding for FOO, that the compiled code had the constant value instead of the the value that was passed in.
The glitch (actually, it is really a bug, given how much energy and time it can waste) is that the compiler doesn't print out a warning when it discovers this inconsistent use of the name FOO, the way it does when you attempt to bind a global or RESETVARS a non-global.
I think a check for this case should be executed whenever code for binding a variable is compiled.
--Ron
*start*
00819 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 22 Mar 84 20:23 PST
From: Kaplan.pa
Subject: Lisp: SINGLEFILEINDEX bug
To: LispSupport.pa, JonL, Tong
Lisp-System-Date: 20-Mar-84 18:25:18
Machine-Type: Dorado
With the new SINGLEFILEINDEX loaded, if I do
(LISTFILES FOO)
I immediately get back a value of NIL.
If I don't have it loaded,
(LISTFILES FOO)
takes a while but then returns the value
({PHYLUM}<FUM>FOO.;1).
In other words, loading singlefileindex makes the value of LISTFILES be incorrect.
I don't know if this was true in the old singlefileindex, but it is a glitch that should be fixed.
Also, presumably, the singlefileindex process should be responsible for removing the file from NOTLISTEDFILES when it successfully completes. It might already be doing this--don't know.
*start*
00448 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 00:10 PST
From: Wallace.pa
Subject: Lafite: Answer command recipient defaulting
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
The answer command only replies to the sender, not to the whole recipient list. Perhaps Middle-answer could have the alternate behaviour?
david
*start*
00330 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 00:31 PST
From: Wallace.pa
Subject: Lafite: Correction to last message
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
Sorry; I was faked out by a Reply-to.
*start*
00382 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 02:30 PST
From: Wallace.pa
Subject: Lisp: LISTFILES filename
To: LispSupport.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
Could LISTFILES use a full filename when writing on the {LPT} device? Then my dover output would have a useful filename ({LPT}FOO.BAR;27743) on the cover.
*start*
00442 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 03:01 PST
From: Wallace.pa
Subject: TEdit: bugging an unselected window
To: TEditSupport
TEdit-System-Date: 1-Mar-84 13:54:34
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dorado
I can't bring a tedit window to the top without moving the cursor. Could Tedit check on mouse clicks to see whether it has the tty before executing the command?
david
*start*
00798 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 02:54 PST
From: stansbury.pa
Subject: Lisp: InstallLispTool
To: LispSupport.pa
cc: stansbury.pa
Lisp-System-Date: 1-Mar-84 14:24:22
Machine-Type: Dandelion
The InstallLispTool has no provision for starting non-LispVMem volumes. For example, if you wanted to have Star & Tajo living on the same machine as Lisp, you would not be able to use the InstallLispTool to boot those volumes.
Unless there is a way for the StartVolume! command to figure out whether the volume it is about to boot should be diagnostic-booted or normal booted, I suggest there be two commands: a StartLisp! command and a StartOther! command. StartLisp! would do a diagnostic boot, and StartOther! would do a normal boot.
-- Tayloe.
*start*
00774 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 09:26 PST
From: Masinter.pa
Subject: Lisp: LAFITE(ON) shouldn't reset cursor
To: LispSupport.pa
cc: Masinter.pa
Lisp-System-Date: 15-Mar-84 00:13:18
Machine-Type: Dandelion
There is not any reason for it, since it doesn't usurp the mouse. I think in general the hourglass cursor is appropriate when the MOUSE isn't available, but probably not at other times. It is egocentric to think that, while you're waiting for LAFITE to turn on, you don't want to do anything else.
[There may be other instances of violation of this principle which should get separate ARs]
Assigned to: vanMelle
Attention: Sybalsky
Impact: Annoying
Problem Type: Design - User Interface
Frequency: every time.
*start*
03814 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Mar 84 21:03 PST
From: Kaplan.pa
Subject: Lafite: Undelivered mail?
To: LafiteSupport.pa
Lafite-System-Date: 28-Feb-84 13:10:33
Lisp-System-Date: 13-Mar-84 10:21:31
Machine-Type: Dorado
This message was returned to me, saying that SRI-A.AG was found. But the address in the message header is SRI-AI.AG. Why didn't it see the "I" ?
Subject: Undelivered mail
From: PinotNoir.ms (a Grapevine mail server)
To: Kaplan.pa
Date: 20-Mar-84 19:29:55 PST
The message sent by Kaplan.pa at 20-Mar-84 19:28:51 PST could not be delivered to the following recipients because they were rejected by the MTP server "Maxc". The reason given was: Sorry, I never heard of an ARPA domain named "SRI-A"
Lauri@SRI-A.AG
----------------
Date: 20 Mar 84 19:28 PST
From: Kaplan.pa
Subject: New LFG system: New editting interface
To: Halvorsen.PA, Bresnan.PA, Withgott.PA, Roach.PA, JRoberts.PA, Ishikawa.PA, Wescoat.PA, Kaplan.PA,CKiparsky.PA,Lauri@SRI-AI
cc: Kaplan.pa
There is a new LFG sysout on {Phylum} with the new TEdit interface for rules and lexical entries. This means that you can switch back and forth between different editting activities and between editting and parsing. You can also have several rule or lexicon editting activities going on at the same time, and switch between them by clicking the mouse in the process you want to go to. It is also possible to copy information from one editor to another via the copy-select mechanism (holding the shift key down). Finally, you can now scroll up and down in these editting windows.
When the system starts up there is one rule window and one lexicon window, in their usual positions on the screen. However, the interface for invoking an editor is slightly different. The LEFT and MIDDLE buttons will both initiate an editting, whereas it used to be the case that LEFT caused an item to be printed without starting up an editor. Now, whatever is shown in one of these windows is available for editting.
The difference between LEFT and MIDDLE is this: If you click with MIDDLE on a word or category, the system will always prompt you for a region on the screen to set up a new editting window, leaving existing editting processes alone.
If you click with LEFT, the system will re-use an existing window that does not have an un-installed change in it. If the text in the window has been editted but you haven't installed it with ^X or aborted the edit with ^D, then the window will not be re-used. Only if all editting windows are in this tentative state will you be asked for a new window region.
This may cause your screen to get cluttered with editting windows. To clear it, merely click in the title region of a window you want to get rid of, and select the "Close" command. The window will become invisible, but it will be opened again and re-used the next time you click LEFT and there is no other available window to edit in.
As before, typing ^X to a window installs the rule or lexical entry, and puts the TTY back to the toplevel input window. Typing ^D stops the current editting, putting the TTY back to the toplevel input window, marking the lexicon window available for re-use.
The editting commands are very similar to the previous configuration. The one notable difference is that now text doesn't get deleted when it is shown white on black and you release the mouse button. Instead it remains inverted on the screen until you hit the DEL (or DELETE on dlion) key, or until you start to type in some replacement text. This might be a little confusing at first.
Please report any bugs or problems, and also please tell make suggestions for different ways of managing the LEFT/MIDDLE selections if you find this clumsy or difficult to use.
--Ron
*start*
01197 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Mar 84 11:39 PST
From: vanMelle.pa
Subject: Re: Lafite: Undelivered mail?
In-reply-to: Kaplan.pa's message of 20 Mar 84 21:03 PST
To: TEditSupport.pa
cc: Halvorsen, Kaplan.pa, Burton, LafiteSupport.pa
Kris also reported a bug like this a long time ago.
The problem is a bug in the Text device's method for PEEKBIN. At least in the case I observed, if \TEXTPEEKBIN is called when COFFSET=CBUFSIZE, i.e., when it is time to "turn the page", or in Tedit's case, go for the next piece, it sets CBUFSIZE for the next piece one too small, which means that the last character of the piece gets dropped, which often happens to be the last character of an address.
TeditSupport: if you'd like a nice reproducible case, do the following: Forward a random message (say this one). In the cc: field, where it says, say, "cc: Sybalsky.pa", replace "Sybalsky" by shift-selecting some other address out of the forwarded message, say "Burton". Break the function \SENDMESSAGE2 and deliver the message. The recipients as parsed by Lafite are an argument to that function, and you can see where the character was dropped.
Bill