*start* 01613 00024 US Return-Path: Redistributed: Xerox1100UsersGroup^.PA Received: from SUMEX-AIM.ARPA by Xerox.ARPA ; 03 AUG 84 11:35:30 PDT Date: Fri, 3 Aug 84 10:35:50 PDT From: Mark Richer Subject: add.process & userexec To: 1100users@SUMEX-AIM.ARPA I have found doing a (ADD.PROCESS '(USEREXEC)) very useful and have even put it on a utility menu so I can call it more easily. I would like to add several features, but I'm having difficulty: (1) I would like to give the new userexec process the tty process immediately, and it seems a way to do this is to do a (GIVE.TTYPROCESS to the new process's window. Doing the ADD.PRCESS creates and automatically opens a TTY window for the process, but doing a (PROCESSPROP process 'WINDOW) returns NIL, and looking in inspect window also show PROCWINDOW to be NIL. What does this mean? (2) OKay, so I thought I could define my own window by adding the prop-value pair 'WINDOW mywindow to the ADD.PROCESS call; this creates two windows (my test was (ADD.PROCESS '(USEREXEC) 'WINDOW (CREATEW ] ). BUTTONING EITHER WINDOW GIVES THE TTY PORCESS TO THE USEREXEC, BUT YOU CAN ONLY TYPE IN THE TTY WINDOW CREATED BY LISP. HOWEVER, THE PROCWINDOW FOR THE PROCESS IS INDEED THE ONE I CREATED. PERHAPS, THIS IS BEHAVIOR IS EXPLAINIED IN THE MANUAL. IF SO , PLEASE POINT THE WAY. (3) I WOULD also like the WINDOW so I can close it after the userexec returns (BY TYPING OK) or after the process is killed. The default is the window just sits there, and I think that's a bit deceiving. thanks, Mark ----- ------- *start* 01353 00024 US Date: 13 Aug 84 17:46 PDT From: Masinter.pa Subject: [Christopher Lane : Re: hash] To: LispSupport, 1100Support cc: Lane@sumex Please make sure "HASH" is included in the packages release. The documentation should credit Cris Lane for rewriting it to be implementation independent. The version on Library> is the appropriate one to release. You might send a copy of the documentation you believe is the "correct" documentation to Chris Lane (Lane@sumex) to obtain verification that it is indeed the correct documentation, since there's been some confusion in the past. ----- Begin Forwarded Messages ----- Return-Path: Received: from SUMEX-AIM.ARPA by Xerox.ARPA ; 13 AUG 84 17:40:48 PDT Date: Mon, 13 Aug 84 17:27:10 PDT From: Christopher Lane Subject: Re: hash To: Masinter.pa In-Reply-To: Message from "Masinter.pa@XEROX.ARPA" of Mon 13 Aug 84 16:10:00-PDT . . . The existence of and changes to the hashfile system has never been made clear to the lispusers' community. I still get inquiries about when the Interlisp-D hash stuff will be released after I sent it over to lispsupport a year ago. On one of the release floppies I found the NEWHASH dcom file (called HASH.DCOM) and the HASHFILE (D.Dyer) documentation, and nothing else. . . . *start* 00508 00024 US Date: 17 AUG 84 01:02 PDT From: MASINTER.PA Subject: changes to EDITLOADFNS? to improve behavior with moving files To: LispSupport I've also fixed up the logic in the procedure invoked when you say EDITF which attempts to load the function from the file; it should work better, especially in the circumstances where files moved from one directory to another. I don't know exactly if there was an AR on this, but this is in response to a couple of complaints about this situation. *start* 00553 00024 US Date: 17 AUG 84 01:06 PDT From: MASINTER.PA Subject: feature request: backup disk To: LispSupport cc: 1100Support I dunno if anybody has ever asked for this, but it seems like something everybody wants -- a procedure which would run when you went home and backup all files on DSK onto a file server or floppy. I imagine a simple minded thing almost like COPYFILES (in fact, maybe COPYFILES would even work for this application??? with a little bit of extra code in it to do some cleanup of the backup directory, it might. *start* 00599 00024 US Date: 17 Aug 84 02:40 PDT From: Shrager.pa Subject: Lisp: Macro gives bogus messages at compile To: LispSupport.pa cc: JonL Lisp System Date: 15-Aug-84 20:06:06 Machine: Dorado (Shrager) Microcode version: 24,4 Memory size: 10000 Frequency: Always Impact: Annoying I've got a macro that simulates the maclisp DO function, but when I compile it into functions, they often give me the message: Possible parenthesis error... Non-atomic car of form. The macro expands to somthing like: ((Lambda ...) args) but this shouldn't bother the compiler. See: lisp>maclisp *start* 00986 00024 US Date: 16 Aug 84 16:37 EDT From: Denber.wbst Subject:CLISP Declarations To: Lispusers^.pa Please excuse the duplication if you already saw this, but it appears that a large majority of this dl never got it. ---------------- Date: 14 Aug 84 11:09 EDT From: Denber.wbst Subject: CLISP Declarations To: Lispusers^.pa Can anyone make any sense out of the "CLISP declarations", whose entire explanation seems to be part of a footnote on page 16.13 of the manual? In particular, I want to say (FOR I FROM I TO 10 SUM (FPLUS I 0.5)) If you run this, you get 55, which is wrong. The answer should be real. The manual mumbles something about CLISP declarations under SUM on page 4.6, without telling you how to make such a declaration. My attempt at following the "example" (such as it is) on page 16.13 was (CLISP (CLISP: FLOATING) (FOR I FROM I TO 10 SUM (FPLUS I 0.5))) which also yields 55! Help! - Michel ----- End of Forwarded Messages ----- *start* 00782 00024 US Date: 17 Aug 84 09:38 PDT From: newman.pasa Subject: Lisp: COMPILER To: LispSupport.pa cc: newman.pasa Lisp-System-Date: 21-Jun-84 10:50:28 Machine-Type: Dandelion I have a function in a file which runs fine and dandy. The poblem is that it apparently will not compile. As a result, when I load the compiled version of the file, the function is not loaded, and I get an error when the function is called. The file is called {dante}linguinideletemenu. Unfortunately it won't run in a standard LISP sysout because it is a part of a much larger package. If you want to test it, let me know; I will tell you what you need to run it. However, I think that you should be able to compile it in a standard LISP sysout . Thanks for your help. >>Dave *start* 00482 00024 US Date: 17 Aug 84 10:56:57 PDT (Friday) From: Masinter.PA Subject: Re: CLISP Declarations In-reply-to: Denber.wbst's message of 16 Aug 84 16:37 EDT To: Denber.wbst cc: Lispusers^ Michel -- this is a leftover piece of nonsense from Interlisp-10. In order to fix this bug, set (CLISPDEC 'MIXED) in your init file. It will make all implicit arithmetic operations use generic arithmetic. Some future release of Interlisp will have this declaration in effect. *start* 00928 00024 US Date: 17 Aug 84 11:24:46 PDT (Friday) From: Masinter.PA Subject: Re: installation utility floppies In-reply-to: JFung.pasa's message of 15 Aug 84 15:09:22 PDT (Wednesday) To: JFung.pasa cc: Raim.pasa, LispSupport Command files that don't work are useless. If you have to *actually* build the files some other way, then don't pretend that you can do it with a command file. It used to be there was one single file MakeLispFloppies.DOC that had several sections, with documentation on how to build various floppies. I'm not sure why you went to change it to be some kind of ".cm" file when the ".cm" file doesn't work. You need to build files that build Trident Prometheus installation floppies too. I urge you to go back and create a MakeLispFloppies.DOC which has all of the info on how to create all of the floppies associated with the harmony release, and we will delete the bogus command files. *start* 00353 00024 US Date: 17 Aug 84 12:00 PDT From: Kiewiet.pasa Subject: Release Notes To: LispSupport.pa cc: 1100Support Would it be possible to include in the Release Notes for Harmony a list of the ARs fixed? I think this would really look good, and confirm for our customers that these reports don't fall into some "black hole". --Lorraine *start* 05507 00024 US Date: 17 Aug 84 13:43 PDT From: Masinter.pa Subject: interlisp handling of filenames for Unix/VMS To: vanMelle, wallace, LispSupport Format: TEdit [This is an AR: regularize Interlisp-D handling of Unix filenames] Maybe Interlisp-D could handle file names on remote Unix and VMS sites in the same way that ISI's VAX interlisp does. I dunno if this belongs on the Lisp end or the VAX end, but I suspect it is better to put it on the VAX end. Unix: The UNIX operating system's facility for handling files posed two obstacles for ISI-INTERLISP. First, the UNIX system does not save old files which have been updated. All new files supersede their old versions in the user's directory. Second, the UNIX system recognizes distinct file names of only 14 characters or less; any longer names are truncated by the UNIX system to fit this format. The UNIX operating system's file names are really pointers to files, which means that a file can have more than one name. ISI-INTERLISP uses this feature to save old versions of files as new ones are created. When a file is updated, ISI-INTERLISP designates it as a new file and gives it an appropriate version number. It also passes along to each updated file an unnumbered name, so that the latest version of the file always has two names assigned to it, one numbered and one unnumbered. The UNIX operating system recognizes the unnumbered names but not the numbered ones, so any manipulation of older versions of files must be done in Interlisp. Under Berkeley Unix 4.1, to be able to handle numbered files at the UNIX shell level, one must use the special versions of @IIT(csh) and @IIT(ls) provided with ISI-INTERLISP. Setting the environment variable VERSIONS in the modified C shell causes the shell to pass the "true" names of files to programs rather than the names with characters truncated to 7 bits. Typing "setenv VERSIONS n", where n is an integer, allows the new ls to print the file names as "filename;versionnumber". Under 4.1, Interlisp implements the version number by setting the high order bit of the last character of the file name. This convention limits the length of file names to 13 characters, since one character must be reserved for version numbers. However, if the file is a .v (binary) file, or if the FORCEEXT flag is set to T, the file name is truncated to the first 11 characters to allow room for the extension as well as the version number. This method of handling version numbers is unnecessary under Berkely Unix 4.2. The UNIX operating system also, by nature, distinguishes between upper- and lower- case characters in file names. ISI-INTERLISP, however, recognizes either upper or lower case and will match the upper or lower case pattern of the previous version when creating new files. VMS Under VMS, no special handling is required for version numbers since this is taken care of by the operating system. VMS permits two forms of punctuation in directory names: [DIRECTORY] and . Due to the difficulty of typein for "[]" style punctuation under Interlisp (since, by default, these characters represent meta-open and meta-close, they must be preceded by the escape character "%"), users of ISI-INTERLISP under VMS are encouraged to adopt "<" and ">" for directory name punctuation. In fact, internally ISI-INTERLISP will convert to this form under most circumstances. Manipulating File Names The directory structure of the UNIX operating system is represented by separating the names of successive directories leading to the intended file by slashes (e.g., /usr/Interlisp/foo). A user can change a TENEX or TOPS-20 -type file name to this format by using the following function: (TRANSLATEFILENAME FILENAME) uses the alist FILENAMETRANSLATIONS to direct the translation of all or specific fields of FILENAME. The entries of FILENAMETRANSLATIONS can be any of the field names known to UNPACKFILENAME, plus the following: FIRST Each form in FIRST is evaluated before any other processing is done. FILENAME and FILENAMETRANSLATIONS are bound to the file name and to the whole translation list, respectively. FULLNAME A list of dotted pairs of full path names. If the CAR of any of these pairs matches FILENAME, the corresponding CDR is returned as the translation. HOST, DEVICE, DIRECTORY, NAME, EXTENSION, VERSION Each of these is a list of dotted pairs, which are matched with the corresponding fields as returned by UNPACKFILENAME. If any CAR matches the input, the CDR replaces it. LAST After all changes have been made, each form in LAST is evaluated. Below is a sample showing the recommended format for setting FILENAMETRANSLATIONS. (SETQQ FILENAMETRANSLATIONS ((DIRECTORY (DDYER . /lisp/ddyer/lisp) (VORECK . /lisp/voreck/lisp) (RBATES . /lisp/rbates/lisp) (IGNATOWSKI . /lisp/ignatowski/lisp) (LISPUSERS . /lisp/Interlisp/lispusers)) (EXTENSION (COM . v)) (NAME (MACHINEINDEPENDENT . machine) (FOO . newfoo)) (LAST (SETQ FILENAME (PACKFILENAME (QUOTE VERSION) NIL (QUOTE BODY) FILENAME] With this format, if FILENAME="FOO.COM.3", TRANSLATEFILENAME would produce "/lisp/ignatowski/lisp/newfoo.v". FILENAME can also be a list of a file name's properties as returned by UNPACKFILENAME, in which case it would return that list with the changes according to FILENAMETRANSLATIONS.  TIMESROMAN nGACHA 0z*start* 00327 00024 US Date: 17 Aug 84 14:15:32 PDT (Friday) From: JFung.pasa Subject: MP 217 on InstallLisp To: LispSupport.pa cc: , JFung I am getting MP 217 from InstallLisp when starting lisp volume. I am using lisp.sysout from [eris]next and the lisp11SAx000Initial.db dated 2-Aug-84. Any idea why? Thanks! *start* 01830 00024 US Date: Fri, 17 Aug 84 15:20 PDT From: VanLehn.PA Subject: New Grapher To: LispFriends^.PA Reply-to: Kaplan, VanLehn Dear lisp friend -- There is a new version of grapher. We would like you to use it in place of the current one before it is released to the un-friendly world. Its stored as {ERIS}LIBRARY>GRAPHER.DCOM It should help cure your array space problems. The old Grapher created a bitmap per node. This one doesn't. The price is that scrolling may take a little longer. To REDISPLAYW a very large graph takes twice as long as it used to, but I think you will find it acceptable (if you don't like this, set CACHE/NODE/LABEL/BITMAPS/FLG to T). Also, the GRAPHRECORD was changed to burn half as many cons cells. Fortunately, you do not have to recompile, since all the old fields that are advertised for public use were left in their old positions. LAYOUTGRAPH takes a new format token. Adding REVERSE/DAUGHTERS to the list of format items will reflect horizontal graphs vertically, and vertical graphs horizontally. If you run in Harmony, then (HARDCOPYGRAPH ) will produce a file from a formated graph (e.g., like SHOWGRAPH, only for files). Currently, it only works for PRESS files. Interpress files will be coming soon. If the device field of the file name is LPT, the file will automatically get sent to the appropriate printer. ImageType is, of course, either PRESS or INTERPRESS, and defaults to INTERPRESS. Translation is a position in screen points of the lower left corner of the graph from the lower left corner of the piece of paper. HARDCOPYGRAPH will go away when device-independent graphics comes. People who want to print more than a single graph on a file can see the definition of HARDCOPYGRAPH. -- Ron & Kurt *start* 00360 00024 US Date: 17 Aug 84 16:45:51 PDT (Friday) From: LRosenberg.PA Subject: Starting With Lisp To: LispUsers^.PA cc: , LRosenberg Reply-To: LRosenberg.PA I am a newhire who is very interesting in keeping active in LISP. I am wondering where one would acquire a manual as well as where the necessary files are located? Thanks, Larry Rosenberg *start* 00462 00024 US Date: 17 Aug 84 18:14 PDT From: card.pa Subject: Re: CLISP Declarations In-reply-to: Denber.wbst's message of 16 Aug 84 16:37 EDT To: Denber.wbst cc: Lispusers^.pa Reply-to: card.pa Format: TEdit Try doing: (I.S.OPR (QUOTE FSUM) (QUOTE (SETQ $$VAL (FPLUS $$VAL BODY))) (QUOTE (BIND ($$VAL _ 0.0)))) then use FSUM in place of SUM. TIMESROMAN mGACHA ! TIMESROMAN _z*start* 03316 00024 US Date: 17 Aug 84 20:04 PDT From: Masinter.pa Subject: new grapher: scrolling SPY windows doesn't redisplay all To: vanLehn, Kaplan cc: LispSupport Format: TEdit In latest loadup, if you make a spy window and scroll it around, you will find some situations where it doesn't display the whole label. SPY makes its own bitmaps for the labels, i.e., it calls GRAPHER with a bitmap for every node label. For example, here's what I get on the screen: ;??0699=99!96H0@0??>qMP(JHOP(H_Jg HJ HHHP (H`^/p when I should get @3dA9J)BRBBP%3BPŹ (BPJ)BR3dy҆ DDDDDDDDDDDD z\w=` 2L !7 BR$) R% J!? C$!! C@!+q'9" ! C @!+ C%!"`! B @!# BP$ P% JR #zPt`^2, ` DDDDDDDDDDDD I got the second display just by buttoning the "redisplay" in the window menu.  TIMESROMAN  BMOBJ.GETFN2 TIMESROMAN  BMOBJ.GETFN2R TIMESROMAN Vz*start* 00206 00024 US Date: 18 AUG 84 11:28 PDT From: MASINTER.PA Subject: InstallLisp.bcd To: JFung.pasa cc: LispSupport Works for me. Could you send a typescript of what you type in the Tajo exec? *start* 00399 00024 US Date: 18 AUG 84 14:44 PDT From: MASINTER.PA Subject: GETCOMMENT in TTYIN To: vanMelle cc: lispsupport I'm getting rid of NORMALCOMMENTSFLG and GET* and GETCOMMENT. Maybe I should make it a LISPUSERS package? I'm getting rid of it just 'cause I don't like it. Sounds like a bad idea, eh? TTYIN calls GETCOMMENT unfortunately, which means that maybe ths was a bad idea. *start* 00778 00024 US Date: 18 Aug 84 15:28 PDT From: DMRussell.pa Subject: Lisp: MAINTAIN Interface To: LispSupport.pa cc: DMRussell.pa, AHenderson, Moran Lisp-System-Date: 21-Jun-84 10:50:28 Machine-Type: Dorado The MAINTAIN package has a *very* annoying interface. Why was it decided to reproduce the abomination that Laurel uses for its interface design? The very simplest design rule of all time says: Try to make all interfaces appear similar. (I'm well aware that there are times when you want interfaces to differ. This isn't one of them.) This one sticks out like a sore thumb! Grump grump grump. Surely all of that "command completion" stuff must occupy extra storage. Can't it just be tossed out, and replaced with a normal user front-end? -- DMR -- *start* 00287 00024 US Date: 20 Aug 84 09:41:05 PDT (Monday) From: jfung.pasa Subject: Re: InstallLisp.bcd In-reply-to: MASINTER.PA's message of 18 AUG 84 11:28 PDT To: MASINTER.PA cc: JFung, LispSupport.PA The 26-Jul-84 version works but NOT 2-Aug-84. Please check 2-Aug-8 version. *start* 00323 00024 US Date: 20 Aug 84 11:03:32 PDT (Monday) From: Masinter.PA Subject: Re: InstallLisp.bcd In-reply-to: jfung.pasa's message of 20 Aug 84 09:41:05 PDT (Monday) To: jfung.pasa cc: MASINTER, LispSupport The version on [eris]Mesa> is dated 31-Jul-84 1:14:46 PDT. Where did you get your version? *start* 00431 00024 US Date: 20 Aug 84 10:42 PDT From: DMRussell.pa Subject: Lisp: TIMESROMAN 36 ITALIC Messed up! To: LispSupport.pa, TEDitSupport.pa cc: DMRussell.pa Lisp-System-Date: 21-Jun-84 10:50:28 Machine-Type: Dorado The characterbitmap of TIMESROMAN 36 ITALIC is very confused. Lots of trash floating around in it -- kerns are totally gone. Should be repaired. Looks like FONTCREATE is the culprit. -- DMR -- *start* 01993 00024 US Date: 6 AUG 84 22:32 PDT From: MASINTER.PA Subject: proposal for incompatible default settings .... To: LispCore^ I propose making two changes in default system settings before Harmony: a) change DWIM to default (CLISPDEC 'MIXED) rather than (CLISPDEC 'INTEGER). That would mean that (A+B) would turn into (PLUS A B) rather than (IPLUS A B), and (add X 3) would use PLUS, and (for I from 1 to 10 sum N) would use PLUS and GREATERP for the iteration, and PLUS for accumulating the sum. I believe that all of our microcodes including 4K DLion now implement PLUS for integers exactly as efficiently as IPLUS. I think IPLUS is anachronistic and has resulted in a number of bug reports and obscure confusions. There *is* a possibility that some odd piece of the system will stop working with this change, but I sort of doubt it.... the only difference is in the case where you do (for I from X to Y ...) and Y/X are floating point arguments. There is also a possibility that some odd case of PLUS/TIMES etc *doesn't* work the same or as fast, and that something will suddenly become dreadfully slower, but I also doubt it. Every other modern lisp defaults to generic arithmetic in lieu of other declarations. If you *SAY* explicitly IPLUS, you should of course get IPLUS, but if you don't say or say implicitly, this would change the default. A related proposal, but which would only affect our code and not users code, is tht I think we should compile the system so that "fetch" of datatype fields does a type check. Currently we don't. On the Dolphin and Dorado, the result was usually innocuous, but on DLions, it means that we get 9318's and other obscure behavior rather than errors. You can, of course, explicitly say "ffetch" rather than "fetch" if you want a Fast Fetch, but I think that for most of the system it doesn't matter (or it is doing a FFETCH anyway.) Both of these should go in before we do the global recompile of the system, of course. *start* 00809 00024 US Date: 8 Aug 84 11:27 PDT From: masinter.pa Subject: disappearing caret found To: LispCore^ Reply-to: masinter.pa I found and fixed a problem which was causing the caret to disappear: if you reshaped a window while the caret was up in a way to cause the caret to be outside of the clipping region, the system would believe the caret was "up", but would never take it "down" in order to reshow it in the new location. This sometimes happened when people had init files which reshaped the TTY window. It wasn't a problem when you invoked SHAPEW from the window menu, because popping up the window menu takes the caret down. In the course of fixing this, I also got rid of the 'CARET1' datatype, since it didn't really need to be a datatype at all and usually only had one instance. *start* 00694 00024 US Date: 7 Aug 84 18:06 PDT From: Kaplan.pa Subject: Re: proposal for incompatible default settings .... In-reply-to: MASINTER.PA's message of 6 AUG 84 22:32 PDT To: MASINTER.PA cc: LispCore^.PA Although I think the changes that Larry is proposing are desirable things to do, I don't think this is the time to fool around with pervasive system declarations. This is the sort of thing that should be done not just before a release but just after, when there is a long time for all the hidden bugs to surface. There is bound to be a long exponential tail on this. I think the harmony release message should warn users that we intend to do this on the following release. *start* 00742 00024 US Date: 12 AUG 84 22:21 PDT From: MASINTER.PA Subject: WHEREIS database updated, plus ... To: lispcore^ I attempted to update the WHEREIS database from latest LispCore>Sources and LispUsers files. Let me know if WHEREIS doesn't find something you think it should find. Also, I've made some edits to MAKEFILE to hopefully make it do more better in the cases where you've moved your source file to another directory (as seems to be the case a lot with customers who use FLOPPY etc.) As soon as I recompile FILEPKG and there is a loadup, I'd appreciate it if folks would watch out for the file package doing the 'wrong' thing on them. (I guess I should broadcast this to LispFriends^ as soon as there's a loadup.) *start* 00778 00024 US Date: 13 Aug 84 12:44 PDT From: JonL.pa Subject: Re: proposal for incompatible default settings .... In-reply-to: MASINTER.PA's message of 6 AUG 84 22:32 PDT To: MASINTER.PA cc: LispCore^.PA, 1100Support.pasa The proposal to change the Interlisp default declaration from (CLISPDEC 'INTEGER) to (CLISPDEC 'MIXED) is certainly overdue. Since this will be an incompatible change, I suggest that we resurrect the "announcement" letter about the pending ZEROP change, and extend it to include this one; thus we can warn the user community some months in advance of the delivery of sysouts with these changes installed. Fixing the clispdec for ffetchfield is, of course, only ABC related and shouldn't particularly involve the user community. -- JonL -- *start* 00245 00024 US Date: 20 Aug 84 17:24 PDT From: Masinter.pa Subject: I'm not running new AR form so I'll send a message instead To: LispSUpport cc: Masinter NSPRINT dies with illegal arg. UPCSTATS has call to FTIMES2 instead of FTIMES *start* 00360 00024 US Date: 20 Aug 84 18:17 PDT From: halvorsen.pa Subject: Lisp: Copyfile/OPENSTREAM breaks from VAX to MAXC To: LispSupport.pa cc: halvorsen.pa Lisp System Date: 14-Aug-84 22:01:47 Machine: Dandelion (204#13#) Microcode version: 24,4 Memory size: 17777 Frequency: Always Impact: Serious OPENSTREAM breaks with illegal arg error: (EOL LF) *start* 01741 00024 US Date: 20 Aug 84 18:32 PDT From: Masinter.pa Subject: Re: How harmonious is Harmony? In-reply-to: Rosenberg.PA's message of 20 Aug 84 17:31:45 PDT (Monday) To: Rosenberg.PA cc: LispSupport, Gascon reply-to: LispSupport I've been reading over the new documentation, and I have a few questions. My problem is that I don't have enough room on my 29-MB disk for a separate Lisp volume, and so I plan to overwrite my 7900-page System (Star) volume with Lisp.sysout when needed, and then reinstall Star afterwards (installing the Star bootfile is trivial). -- I just don't think this will work. Lisp should have more than 7900 pages for its virtual memory file, unless you run in SMALL.SYSOUT or what have you. If it were a 12000 page volume, this might work, but not 7900. I'll answer the questions anyway: 1) When I reinstall Star, do I have to reinstall the Klamath diagnostic microcode too? -- only if you want to run diagnostics, of course. 2) As for the compatibility of the Lisp initial microcode and the standard Klamath initial microcode, if I install the Lisp initial microcode, run Lisp, reinstall Star (and thus erase Lisp), and then do a 0-boot, will I end up in (a) Othello, or (b) some unpleasant state? -- I believe you may wind up in an unpleasant state, e.g., flashing 217 in the Maintenance Panel. I normally do 1-boots to start Star anyway. Alternatively, of course, you can load in new initial microcode. 3) Are there any other cases where the two worlds may collide? -- yes, if you install Lisp on a volume that is small, it has a tendency to overrun the volume boundaries and trash the next volume. If you attempt to put Lisp on a 7900 page volume, you should make it the *last* volume. *start* 00309 00024 US Date: 21 Aug 84 09:50 PDT From: Masinter.pa Subject: Lisp: NIL - UNDEFINEDFUNCTION when CH.LIST.DOMAINS(*:XEROX) To: LispSupport.pa cc: vanMelle Lisp System Date: 21-Aug-84 06:58:35 Machine: Dorado (Plaza) Microcode version: 24,4 Memory size: 10000 Frequency: Once Impact: Moderate *start* 00430 00024 US Date: 21 Aug 84 12:04 PDT From: Masinter.pa Subject: Re: oncocin> files... In-reply-to: lichtenberg.wbst's message of 20 Aug 84 09:10:45 EDT (Monday) To: lichtenberg.wbst, Stansbury, Nuyens, LispSupport The .STRIKE files on Oncocin> differ in length from the ones on Fonts> by the same name. How do the fonts differ? Are these changes we want to include in standard Interlisp-D? *start* 00481 00024 US Date: 21 Aug 84 15:25 PDT From: Burton.pa Subject: Lisp: HARDCOPYW of full screen no longer works To: LispSupport.pa cc: Kaplan, Nuyens Lisp System Date: 21-Aug-84 06:58:35 Machine: Dorado (Burton) Microcode version: 24,4 Memory size: 10000 Frequency: Always Impact: Moderate HARDCOPYW complains that bitmap is too big. It seems to be ignoring scale factors in the new stream stuff. I had to back up to CAROL to get a screen press file made. richard *start* 00826 00024 US From: lichtenberg.wbst Date: 21-Aug-84 21:00:00 EDT Subject: Re: oncocin> files... In-reply-to: Masinter.pa's message of 21 Aug 84 12:04 PDT To: Masinter.pa cc: lichtenberg, Stansbury.pa, Nuyens.pa, LispSupport.pa If the file lengths are different, then by al means save them -- they are probably special for the ONCOCIN demo. I noticed that they have a few .STRIKE files of their own - MEDICAL-something.STRIKE, I believe. I am not sure if anyone out there knows how to run it besides the people who brought it in. Again... I believe Tayloe is the best person to talk to on that front. For now, I would say keep as much as possible - after all, it is another big Interlisp-D application to show off.. (it looked sorta flashy at the show. - lots of active mouse regions, etc.) /Mitch. *start* 00282 00024 US Date: 21 Aug 84 20:30 PDT From: masinter.pa Subject: new version of HelloDLion.boot & HelloTriDLion.boot on [eris]Mesa> To: LispFriends^ Reply-to: LispSupport This version doesn't get a 915 when running Describe Physical Volume when it hits DSK. *start* 00263 00024 US Date: 21 AUG 84 23:04 PDT From: MASINTER.PA Subject: TYPE and MESATYPE on floppy To: Roach cc: LispSupport What are the allowable values for TYPE on Mesa floppies? What are the allowable /known values for MESATYPE on Mesa floppies? *start* 00615 00024 US Date: 22 Aug 84 02:32 PDT From: JonL.pa Subject: Lisp: BREAKCONNECTION seems to damage the hashfile WHEREIS To: LispSupport.pa cc: Burton,vanMelle,JonL.pa Lisp System Date: 15-Aug-84 20:42:17 Machine: Dorado (Darwin) Microcode version: 24,4 Memory size: 10000 Frequency: Intermittent Impact: Serious I think this may be "Frequency: Always" now. I've often managed to recuperate by diddling with SYSHASHFILELST and SYSHASHFILE and WHEREIS.HASH, but one would like to think that this is unnecessary. If there's an AR here, it probably should be against the HASH file package. -- JonL -- *start* 01175 00024 US Date: 22 Aug 84 09:26 PDT From: Kiewiet.pasa Subject: Harmony on Dolphins To: Masinter.pa cc: 1100Support, LafiteSupport.pa, Kiewiet.pasa Larry, Just for fun, I tried the 15-Aug-84 sysout on my 1100 with XMBDolphinLispmc.eb of 8-Mar-84 and was successful in getting into Lisp. A bizarre thing happened. After loading Lafite.dcom and attempting to Browse the day's mail folder, the Browser pop-up menu remembered a few of my {dsk}, {dsk2} and {Rosebowl} folders. It also remembered one of Jim Wogulis's {Rosebowl} folders, and he hasn't used this machine since February! Isn't the fresh Lafite supposed to be ignorant of all mail folders other than Active.mail, the default? Also, when Lafite couldn't find the day's mail folder, I did a DIR * on both {Dsk} and {Dsk2} and got identical directories (also rather out of date.) While working in {dsk2}, Lafite refuses to open the {dsk} mail folder which is in perfectly good shape. Should any of this be an AR? If Harmony can't figure out the present state of my directory, I would think it should be. Lorraine P.S. I can't test this too much longer, as my Dolphin is being sold to Fuji. *start* 00456 00024 US Date: 22 Aug 84 11:27 PDT From: masinter.pa Subject: \FTP.OPENFILE causes FILE WONT OPEN error under ERRORSET which seems to catch the error To: vanMelle cc: LispSupport I guess the way the error handler works, you can't cause a LISPERROR from a "system" function under an ERRORSET, cause the error position in the break will be wrong? Or maybe it is the problem that the ERRORSET shouldn't be REALFRAMEP for the purpose of break? *start* 01018 00024 US Date: 22 Aug 84 13:04 PDT From: vanMelle.pa Subject: living dangerously with Lafite To: LispFriends^ Reply-to: vanMelle.pa If you keep your mail on {DSK}, and are running in LispCore>Next, read on. The very latest Lafite (Aug 14) tickled a bug in another part of the system, such that if you retrieved mail and then did not Expunge the folder or close its browser, not all of the new mail was actually written to disk. In other words, there was a danger period (between GetMail and Expunge/Close) during which you could lose mail if you crashed or booted. Symptom of this having happened to a mail file is that you browse it, it fails to parse, possibly saying the toc does not agree, and there appear to be lots of nulls at the end of the file. This bug did not affect mail files stored on file servers. I have fixed the bug, so new loadups will be okay, but if you want to live less dangerously in the meanwhile, (LOADFNS '\PAGED.FORCEOUTPUT '{ERIS}SOURCES>PMAP.DCOM). Bill *start* 00718 00024 US Date: 22 Aug 84 15:24 PDT From: trigg.pa Subject: Lisp: Dlion 9321 crash during tedit loadfn To: LispSupport.pa cc: trigg.pa Lisp System Date: 22-Aug-84 00:45:52 Machine: Dandelion (Melba) Microcode version: 24,4 Memory size: 5777 Frequency: Intermittent Impact: Fatal I was running next>full.sysout version from 8/17 and had been having tedit problems. Usually they were "Illegal Arg: T" to IMAGEOBJPROP. The latter function was called from various Tedit functions. I believe the last time it was called from (something like) TEDIT.UPDATE.SCREEN. I tried to display edit that function, it offered to load the symbolic in, and then crashed my Dlion during the load with a 9321. *start* 01091 00024 US Date: 22 Aug 84 15:33 PDT From: vanMelle.pa Subject: Re: Harmony on Dolphins In-reply-to: Kiewiet.pasa's message of 22 Aug 84 09:26 PDT To: Kiewiet.pasa cc: Masinter.pa, 1100Support.pasa, LafiteSupport.pa Lafite "knows" about your mail folders by reading Lafite.profile on your default Lafite directory, or the home directory. If that happens to be {DSK}, you could have gotten an old profile left behind by the previous owner. Directory of {DSK} and {DSK2} would be identical if (DISKPARTITION) = 2. Also if someone had copydisk'ed one to the other, but in that case there would be at least some subtle differences, such as the READDATE of Lisp.run. We have seen cases of Dolphins (ar 955) being unsuccessful in accessing the other partition. Cause unknown, except suspected to be flakiness in the disk driver that is not exposed by Alto diagnostics, which are less demanding. Seems to me most such problems have gone away when the techs swapped out the right components. Are you convinced that these problems exist only in Harmony and not in Carol? Bill *start* 00410 00024 US Date: 22 Aug 84 16:08 PDT From: Kiewiet.pasa Subject: Packages database To: LispSupport.PA cc: Kiewiet.pasa We will soon be closing the Lisp Package Database. If there are any outstanding corrections to be made to package attributes, such as Author, Maintainer, Distributability, please message EDouglas.pasa. On Monday, August 27, no further changes will be accepted. --Marty Raim *start* 00241 00024 US Date: 22 Aug 84 16:05 PDT From: acuff.pa Subject: Re: Packages database In-reply-to: Kiewiet.pasa's message of 22 Aug 84 16:08 PDT To: Kiewiet.pasa cc: LispSupport.PA How does one peruse this database? -- Rich *start* 00487 00024 US Date: 22 Aug 84 16:20 PDT From: Masinter.pa Subject: some files *will* need recompilation To: LispSupport Somewhere along the line in the last few years, a bug got fixed which caused floating point operations to be compiled as expected. The result, however, is that some programs compiled in 1982 apparently need recompilation before they will run. [every attempt is made to keep the system upward compatible, etc. etc. This one is UNDEFINED FUNCTION, FTIMES2] *start* 01858 00024 US Date: 22 Aug 84 16:41 PDT From: Kiewiet.pasa Format: TEdit Subject: Re: Harmony on Dolphins In-reply-to: vanMelle.pa's message of 22 Aug 84 15:33 PDT To: vanMelle.pa cc: Kiewiet.pasa, Masinter.pa, 1100Support.pasa, LafiteSupport.pa Lafite "knows" about your mail folders by reading Lafite.profile on your default Lafite directory, or the home directory. If that happens to be {DSK}, you could have gotten an old profile left behind by the previous owner. Aha. That explains my own DSK and Rosebowl entries, but not active.mail. Directory of {DSK} and {DSK2} would be identical if (DISKPARTITION) = 2. Also if someone had copydisk'ed one to the other, but in that case there would be at least some subtle differences, such as the READDATE of Lisp.run. I used {DSK2} previously for Fugue.6, then for Tutorials and Demo.sysout, with no problem getting DIR for {DSK}. The disks were installed separately from {Rosebowl}. We have seen cases of Dolphins (ar 955) being unsuccessful in accessing the other partition. Cause unknown, except suspected to be flakiness in the disk driver that is not exposed by Alto diagnostics, which are less demanding. Seems to me most such problems have gone away when the techs swapped out the right components. If the disk driver is the same, regardless of partition, why do I not experience flakiness in partition1 when I access partition2. Are you convinced that these problems exist only in Harmony and not in Carol? Lafite's not had any of these problems in Carol's earlier Beta sysout, or the official release of Carol. --Lorraine TIMESROMAN GACHA V TIMESROMAN GACHA TIMESROMAN DGACHA TIMESROMAN MGACHA { TIMESROMAN : z*start* 00332 00024 US Date: 22 Aug 84 16:44 PDT From: Kiewiet.pasa Subject: Re: Packages database In-reply-to: acuff.pa's message of 22 Aug 84 16:05 PDT To: acuff.pa cc: Kiewiet.pasa, EDouglas, Raim, LispSupport.PA Rich, I'm forwarding your query to Earlie Douglas (EDouglas.pasa), the Package Database Administrator. Lorraine *start* 00610 00024 US Date: 22 Aug 84 16:43 PDT From: vanMelle.pa Subject: Re: GETCOMMENT in TTYIN In-reply-to: MASINTER.PA's message of 18 AUG 84 14:44 PDT To: MASINTER.PA cc: vanMelle.PA, lispsupport.PA Sounds ok to make it a LispUsers package. I would not be surprised to hear of Interlisp-D users who use it, although it makes a little less sense here (but still some, given our pitiful litatom limit). I am fixing TTYIN to do its think conditionally. Actually, you would never have noticed GETCOMMENT being udf if you had left NORMALCOMMENTSFLG being T instead of throwing it out altogether. Bill *start* 03575 00024 US Date: 22 Aug 84 17:04 PDT From: Masinter.pa Subject: functions called, not defined To: LISPSUPPORT cc: LispCore^ Reply-to: LispSupport some of these are legit NEW called by (TEDIT.NEW.FIND) \ILLEGAL.STACK.ARG called by (RETAPPLY RETEVAL) \FLOATUNBOX called by (\UNBOXFLOAT1 \UNBOXFLOAT2) \FLOATBOX called by (\UNBOXFLOAT1 \UNBOXFLOAT2) \SETCOLORCURSORBM called by (SETCURSOR) \TAKEDOWNCOLORCURSOR called by (BITMAPBIT BKBITBLT SETCURSOR BITBLT) \INIT.GATEWAY called by (\ETHEREVENTFN) REPEAT called by (\TEDIT.BRAVOFILE?) \GATEWAY.FORWARD.PUP called by (\FORWARD.PUP) CLOSER called by (/CLOSER) \BWTOCOLORBLT called by (BKBITBLT BITBLT) COLORNUMBERP called by (\CLIPANDDRAWLINE BKBITBLT \FILLCIRCLE.DISPLAY BITBLT) \PUTUPCOLORCURSOR called by (\CURVEEND \CURVE \LINEWITHBRUSH \CURVE2 \CLIPANDDRAWLINE1 \CLIPANDDRAWLINE \SLOWBLTCHAR \DSPPRINTCR/LF \BLTCHAR BITMAPBIT BKBITBLT \FILLCIRCLE.DISPLAY \DRAWELLIPSE.DISPLAY \DRAWCIRCLE.DISPLAY BITBLT) COLORTEXTUREFROMCOLOR# called by (BKBITBLT \FILLCIRCLE.DISPLAY BITBLT) \IFCOLORDS\TAKEDOWNCOLORCURSOR called by (\CURVEEND \CURVE \LINEWITHBRUSH \CURVE2 \CLIPANDDRAWLINE1 \CLIPANDDRAWLINE \SLOWBLTCHAR \DSPPRINTCR/LF \BLTCHAR BITMAPBIT \FILLCIRCLE.DISPLAY \DRAWELLIPSE.DISPLAY \DRAWCIRCLE.DISPLAY) \DDSETCOLORFONT called by (\SLOWBLTCHAR) \GETCOLORFONT called by (\DSPFONT.DISPLAY) COLORDISPLAY called by (DISPLAYBEFOREEXIT) \SETMACHINEDEPENDENTCOLORFNS called by (DISPLAYAFTERENTRY) \CREATESOCKET called by (DEBUGGINGTRSERVER) VGETBASEBYTE called by (DEBUGGINGTRSERVER) BINSKIP called by (LCSKIP) FNCLOSER called by (/FNCLOSER) FNCLOSERA called by (/FNCLOSERA) FNCLOSERD called by (/FNCLOSERD) EDITRACEFN called by (\EDITBLOCK/EDITCOM) EDITUSERFN called by (\EDITBLOCK/EDITDEFAULT) GETCOMMENT called by (TTED \MATCHBLOCK/PATPARSE1 EDITDATE?) L-CASE1 called by (COMMENT4) HELPSYS called by (DO? DO?A0059 SMARTARGLISTA0018 SMARTARGLIST) SGETHASH called by (SMARTARGLIST) TIMEDUMMYFUNCTION called by (TIMEALL) BLOCKCOMPILE2 called by (BLOCKCOMPILE1 BYTEBLOCKCOMPILE2 BYTEBLOCKCOMPILE2A0001) COMPILE2 called by (COMP.ATTEMPT.COMPILE COMPILE1) ARCHIVEFN called by (HISTORYSAVE) OPENR called by (/CLOSER) FNOPENR called by (/FNCLOSER) FNOPENRA called by (/FNCLOSERA) FNOPENRD called by (/FNCLOSERD) RECORDECL called by (\CLISPLOOKUP0/CLISPLOOKUP1) ASSEMBLETRAN called by (WTFIX) CLISPIFYUSERFN called by (CLISPIFY2B) NOTCHECKED called by (ASKUSERA0034 ASKUSER) AT2VC called by (HVBAKREAD) \DRAWCOLORLINE1 called by (\CLIPANDDRAWLINE1) \GETCOLORBRUSH called by (\LINEWITHBRUSH \CURVE2 \DRAWELLIPSE.DISPLAY \DRAWCIRCLE.DISPLAY) \POSSIBLECOLOR called by (DSPCOLOR DSPBACKCOLOR) \OLD\BACKGROUND called by (NU\BACKGROUND) \OUTSTREAMARG called by (NEWPRINTDEF) XHELPSYS called by (DO?CMD) DISPLAYHELP called by (TTGIVEHELP2) BKSYSCHAR0 called by (TTUNREADBUF) \GATEWAY.FORWARD.XIP called by (\FORWARD.XIP) \FLOPPY.DEBUGBLOCKS called by (\FLOPPY.PREPAREFORCRASH) EBCDICTOASCII called by (\FLOPPY.DUMP) ASCIITOASCII called by (\FLOPPY.DUMP) CLOSEINSPECT called by (\FLOPPY.DEBUG) \TEDIT.NEW.PARSE.SEARCHSTRING called by (TEDIT.NEW.FIND) MB.CREATE.FULLMENU called by (\TEXTMENU.DOC.CREATE) DRAWBOX called by (TEDIT.SHOWREGION) VPUTBASE called by (DEBUGGINGTRSERVER) VPUTBASEBYTE called by (VBROKENDEF) VCREATECELL called by (V\COPY) VCOPYSTRING called by (V\COPY) VCONS called by (V\COPY) HASHFILENAME called by (WHEREISA0001) IMTRAN called by (IMNAME.UPDATE.HASHFILE) RESETSAVE.MOVD called by (IMNAME.UPDATE.HASHFILE) PARTITION.LIST called by (IMNAME.UPDATE.REFS) LIST.TO.STRING called by (IMNAME.UPDATE.SEND.INFO) *start* 00287 00024 US Date: 22 Aug 84 17:14 PDT From: JonL.pa Subject: Re: Packages database In-reply-to: Kiewiet.pasa's message of 22 Aug 84 16:08 PDT To: Kiewiet.pasa cc: LispSupport.PA How does one access this database? Should I review it before Aug 27 (I think so). -- JonL -- *start* 00257 00024 US From: MASINTER.pa Date: 22-Aug-84 22:30:44 PDT Subject: Re: GETCOMMENT in TTYIN In-reply-to: vanMelle's message of 22 Aug 84 16:43 PDT To: vanMelle cc: MASINTER, lispsupport taking it out was over-ambitious. I will put it back in. *start* 00354 00024 US Date: 23 Aug 84 08:44 PDT From: Burton.pa Subject: Re: functions called, not defined In-reply-to: Masinter.pa's message of 22 Aug 84 17:04 PDT To: Masinter cc: LispSupport.pa All of the ones with 'COLOR' in there names are legit. They will only be called if LLCOLOR and COLOR (whichw contain them) have been loaded. richard *start* 00484 00024 US Date: 23 Aug 84 08:48 PDT From: Kiewiet.pasa Subject: Re: Packages database In-reply-to: JonL.pa's message of 22 Aug 84 17:14 PDT To: JonL.pa cc: Kiewiet.pasa, LispSupport.PA HI JonL, Earlie Douglas (EDouglas.pasa) is the person to contact regarding access/use of the PDB. Marty Raim can tell you if you should check it. Marty sent that message from my machine. Sorry for the confusion; I'm just managing gathering and proofing documentation. Lorraine *start* 00865 00024 US Date: 23 Aug 84 09:50 PDT From: Shrager.pa Subject: Lisp: HC fns consistently misposition. To: LispSupport.pa cc: gascon, moran, foss Lisp System Date: 22-Aug-84 00:45:52 Machine: Dorado (Shrager) Microcode version: 24,4 Memory size: 10000 Frequency: Always Impact: Serious There is a consistent(ly incorrect) relationship between where, on the D-Machine screen, the image left/bottom is, and where, on the LispPrint page. Of the origin of your image is at screen 0,0 then it comes out in the center of the LispPrint page. Otherwise, the Y coordinate appears to be offset by approximately how far from screen-0 you happen to be. Therefore, the only consistent way of getting proper hardcopies of less than screen sized objects is to snapshot them and put the snapshot in the lower left of the screen, then hardcopy from the snapwindow. *start* 00692 00024 US Date: 23 Aug 84 10:24 PDT From: DMRussell.pa Subject: Lisp: Reading beyond the end of file To: LispSupport.pa cc: DMRussell.pa Lisp-System-Date: 3-Jul-84 16:48:16 Machine-Type: Dorado I just did a LOADFNS(FOO BAR) Unfortunately, the last time I wrote the file BAR, my machine crashed in mid-stream. Thus BAR is half-done. When I LOADFNS, Interlisp tells me: *****Note: {PHYLUM}FOO;11 is not the newest version loading from {PHYLUM}FOO;12 And then proceeds to break on SKREAD. The intelligent thing to do (instead of just breaking) would be to ask the user if it should load from version 11. It would be very nice. -- DMR -- *start* 00456 00024 US Date: 23 Aug 84 12:54 PDT From: masinter.pa Subject: Re: GETCOMMENT in TTYIN In-reply-to: MASINTER.pa's message of 22-Aug-84 22:30:44 PDT To: MASINTER.pa cc: vanMelle.pa, lispsupport.pa GETCOMMENT is back in the system. However, the read macro & prettyprint macro is not installed. To install them, you must now call (NORMALCOMMENTS FLG) rather than merely setting NORMALCOMMENTSFLG. (NORMALCOMMENTS T) is the intial default. *start* 00614 00024 US Date: 23 Aug 84 14:06 PDT From: masinter.pa Subject: TINYTIDY, & new Hello To: lispfriends^ Reply-to: masinter.pa on {eris}TINYTIDY & .DCOM, small hack in the style of the Mesa one: takes the icons on your screen and lines them up along the edge: (TINYTIDY edge spacing) edge defaults to RIGHTBOTTOM, but LEFT, LEFTBOTTOM, RIGHT, RIGHTBOTTOM, TOP, TOPRIGHT, BOTTOM, BOTTOMRIGHT are all allowed. spacing (pixels between icons) defaults to 4 - - - - - - - - - - In a completely unrelated announcement, there is yet another version of Hello.boot for Mesa 11.0 DLion users. *start* 00465 00024 US Date: 23 Aug 84 16:19 PDT From: Masinter.pa Subject: new behavior on BREAK-REVERT To: LispFriends^ Reply-to: LispSupport I've been trying to fix up the behavior of the REVERT command in break windows to avoid the occasional machine-crash which used to happen when you would, say, REVERT to a PROG. There are enough special cases that I may have gotten one wrong -- please watch when you do REVERT (in loadups dated *after* today, right?) *start* 00800 00024 US Date: 23 Aug 84 23:37 PDT From: acuff.pa Subject: Lisp: Potential problem with FILEIO To: LispSupport.pa cc: acuff.pa Lisp System Date: 22-Aug-84 00:45:52 Machine: Dandelion (131#66#) Microcode version: 24,4 Memory size: 5777 Frequency: Once Impact: Minor I BCOMPL'd FILEIO and got two breaks. Both were on (create WORD HIBYTE _ (--) LOBYTE _ (--)) expressions. As far as I can tell, the code that was produced (when I said OK to the break) is identical to that currently in the system. The breaks said it was impossible to DWIMIFY the create because replace was not defined for HIBYTE and LOBYTE. This is true (from looking at the ACCESSFNS for WORD), but create is defined correctly. The DW edit command also failed, but GETD produced correct results. -- Rich *start* 00694 00024 US Date: 23 AUG 84 23:41 PDT From: MASINTER.PA Subject: 10vs3Etherprotocols.txt To: raim.pasa cc: 1100Support.pasa, LispSupport On [eris]Fugue.6>Doc> is a file called 10vs3EtherProtocols.txt which explains the details of PUP encapsulation that Dwight Hare has been asking about. This document apparently did not make it into the set of things that got released. What Dwight has to implement is slightly more complex than he has inferred. The sources for PUPIDSERVER and LLETHER will give him more clues if the documentation in 10VS3EtherProtocols is unclear. I suppose we also need to carry forward 10VS3EtherProtocols.txt into Carol/Harmony documentation. *start* 00442 00024 US Date: 23 AUG 84 23:51 PDT From: MASINTER.PA Subject: package database To: EDouglas.pasa cc: Raim.pasa, LispSupport I made some edits to the file [eris]Carol>Doc>LIBRARY.packages to reflect some changes I believe necessary: *however*, I only got about 1/2 way thru. Can I call you on the telephone and discuss the remaining edits to the database, or would you prefer that I continue to mark up the file? *start* 00558 00024 US Date: 24 Aug 84 09:29 PDT From: Masinter.pa Subject: Re: Try Again (sigh) In-reply-to: MGittins.RX's message of 17-Aug-84 18:54:43 To: MGittins.RX cc: LOOPSCORE^.PA, LispSupport Reply-to: LispSupport About problem 2: Perhaps the problem is that when you start loops it doesn't read your init flag with MAKEFILEREMAKEFLG = NIL? MAKEFILE should not be attempting to read the previous version if MAKEFILEREMAKEFLG is NIL, as in "As far as I can tell the fault is occuring when MAKEFILE is trying to read the previous version . . . " *start* 02534 00024 US Date: 24 Aug 84 09:29 PDT From: Masinter.pa Subject: [MGittins.RX: Try Again (sigh)] To: LispSupport For the archives since these are Lisp not Loops problems.... ----- Begin Forwarded Messages ----- From: MGittins.RX Date: 17-Aug-84 18:54:43 Subject: Try Again (sigh) To: LOOPSCORE^.PA Try to get through again ---------- Subject: Undelivered mail From: GreeneKing.ms (a Grapevine mail server) To: mgittins.rx Date: 16-Aug-84 10:42:12 The message sent by mgittins.rx at 14-Aug-84 9:52:09 could not be delivered to the following recipients within a reasonable time, because of network failures or the unavailability of other servers. Bobrow.PA, DMRussell.pa, Hausladen.PA, HThompson@CSLI.Arpa, JONL.PA, Kahn.pa, Kay.pa, Masinter.pa, MGardner.pa, Mittal.PA, Stefik.PA, VanMelle.PA, Masinter.pa ---------------- From: mgittins.rx Date: 14-Aug-84 9:53:02 Subject: Some Problems with LOOPS To: LOOPSCORE^.pa cc: Masinter.pa Having had the chance the other day to talk with Danny he remarked that I should sent problems, questions etc to this dl, hence this message. 1) The use of the control key in Truckin to interrupt the game does not look at the keyboard mapping. For European 1108s we map the control key to the shift lock position, but to interrupt truckin you still have to press the PROPS key. 2) We hve had major problems saving players on NS file servers. Although this looks like an Interlisp problem rather than LOOPS it does happen with much greater frequency in the LOOPS released sysout than any other (this is Fugue.6 version). There are two hen making the first instace of some file containing the player a break sometimes occurs with "SPP retransmit queue out of order", this only happen occasionaly. The second symtom is that when making subsequent versions a break occurs with "File wont Open", this happens nearly every time in the LOOPS world. We have had more chance to look at this but cant get very far without sources. As far as I can tell the fault is occuring when MAKEFILE is trying to read the previous version, it has found it OK and requested a stream on the file, courier passes back what looks like a valid stream handle. However somewhere along the line someone decides that the file doesnt have INPUT access although the ACCESSBITS is 1 (English is wonderful sometimes). I suspect that there is a screwy call to IOMODEP causing the trouble. I will continue to work on the problem as time permits. Martin ----- End Forwarded Messages ----- *start* 00386 00024 US Date: 24 Aug 84 15:46 PDT From: trigg.pa Subject: Lisp: Hardcopy broken? To: LispSupport.pa cc: trigg.pa Lisp System Date: 22-Aug-84 00:45:52 Machine: Dandelion (Melba) Microcode version: 24,4 Memory size: 5777 Frequency: Always Impact: Annoying I can't get Hardcopy to work. It goes into an error break saying the file "Window Image" not found. - Randy *start* 00295 00024 US Date: 25 AUG 84 16:07 PDT From: MASINTER.PA Subject: improving timeout parameters in Services 8.0? To: vanMelle cc: LispSupport Is it just wishful thinking, or were we successful in getting them to increase the timeout parameter for file transfer in Services 8.0? *start* 00984 00024 US Date: 25 AUG 84 16:26 PDT From: MASINTER.PA Subject: prometheus To: JFung.pasa cc: 1100Support, LispSupport I've verified that I have all of the sources for prometheus available here, and have been able to rebuild a prometheus from sources. I think we are now in a position to make some modifications to suit our needs. The desire of course is to get a version of Hello that could install from floppy, PUP or NS host, and would also take a script. If we had that, it would solve most of our installation needs. People could use the script if they wanted, or change it around, e.g., if they wanted to partition their disk a different way. Do you have a list of "wishes" for Prometheus? I think, for example, that it would be resonable to add a "Install Lisp Sysout" command that would know how many floppies were to come, might take variations in the floppy name, and would extend the virtual memory appropriately. I don't know what else is desired. *start* 01089 00024 US Date: 24 Aug 84 23:16 PDT From: JonL.pa Subject: LCROCK -- a digital/analog Clock for LOGOW space. To: LispUsers^ Reply-to: JonL.pa There is a variant of Kelly Roach's CROCK on [Eris]LCROCK which directly puts a "nice" clock face in the unused portion of the logowindow. [I have noticed that many persons try to position a regular CROCK clock over the "dead" space in the logowindow]. To start it up, load in the .dcom file and call (START.LCROCK ) where , if non-NIL, will replace the "Interlisp-D" as the logo part of the logowindow; and , if non-NIL will be the position of the lower-left corner (if NIL, then it will try to use the same position as the previously existing logowindow). One of the problems with separate LOGOW and CROCK windows is that they aren't "attached"; and when one tries to attach them, they aren't "attached" in the right places. Also, LCROCK tries to be more efficient at determining the placements of the hands, so as to minimize the cost of updating the clock. -- JonL -- *start* 00525 00024 US Date: 25 Aug 84 22:30 PDT From: Shrager.pa Subject: Lisp: Copyfile from Maxc To: LispSupport.pa Lisp System Date: 23-Aug-84 18:52:49 Machine: Dorado (Shrager) Microcode version: 24,4 Memory size: 10000 Frequency: Always Impact: Moderate (COPYFILE '{Maxc}TextFile '{Phylum}...) makes a completely uninterpretable mess in the output file. I assume that this is due to word format incompatiblily, but perhaps COPYFILE or the communications drivers to Maxc should know about this. -- Jeff *start* 01029 00024 US Date: 26 AUG 84 00:11 PDT From: MASINTER.PA Subject: FXPrinter & rs232 To: JonL cc: LispSupport the other day I was trying to show someone the FX.80 which is on the pool DLion. I started with a recent FULL.SYSOUT from LispCore>Next, loaded in FXPRINTER & RS232 from LispCore>Library, and set DEFAULTPRINTINGHOST to FX.80. I then attempted to Hardcopy a section of the screen. FXPRINTER asked me some questions about setup and baud rate. Since I didn't know the baud rate, I just guessed, and selected 1200 baud. It then went into a mode where it was rapidly flashing an error message in the prompt window, but not printing. I control-D'd out of that, and tried to do an RS232INIT() to clear things up, but it kept on getting some kind of "Getting no response fromthe ..." message. If the DLion TTY port gets wedged, can we unwedge it? Is there some part of the RS232 code which should be uninterruptable? Why the rapidly flashing error message? How can I tell what baud rate is appropriate? *start* 00217 00024 US Date: 26 AUG 84 10:53 PDT From: MASINTER.PA Subject: COPYFILE( from maxc... To: Shrager cc: LispSupport There is no file called TEXTFILE on [maxc] Did you destroy the evidence? *start* 00467 00024 US Date: 26 Aug 84 16:48 PDT From: Masinter.pa Subject: Re: Okay, but you asked for it! In-reply-to: Shrager.pa's message of 26 Aug 84 14:23 PDT To: Shrager.pa cc: LispSupport As I suspected, {maxc}testfile is of TYPE BINARY. Whatever program you used to write it incorrectly marked the file type and bytesize (it is a 36-bit-binary file). One way to fix it is to go into Interlisp-10 and (SETFILEINFO 'TESTFILE 'BYTESIZE 7] *start* 00457 00024 US Date: 26 Aug 84 19:33 PDT From: acuff.pa Subject: Copying Lisp source files To: LispSupport, Masinter cc: acuff.pa Is it really true that there is no clean way to copy a lisp source (or compiled) file without loading the file and making it? If not, is this just that (a) nobody's gotten around to it, (b) there is an alternative way that is almost as good, or (c) there is something I don't know that makes it hard. -- Rich *start* 01015 00024 US Date: 26 Aug 84 23:41 PDT From: vanMelle.pa Subject: Re: improving timeout parameters in Services 8.0? In-reply-to: MASINTER.PA's message of 25 AUG 84 16:07 PDT To: MASINTER.PA cc: vanMelle.PA, LispSupport.PA Might be wishful thinking. A filing connection still times out within a minute if Lisp is unresponsive, i.e., some process is not yielding and letting the SPP connection manager in. However, when Lisp is responsive, even if it is not actively eating the data, the connection stays alive much longer. In fact, I let one go for 25 minutes without it timing out, so it's possible there is no longer a Filing-level timeout at all during a transaction (which, after all, is what the spec requires). So that's good news (assuming it used to not be true; I never did examine the old Services filing behavior in detail). But without preemptive process scheduling, we are still dead because of the responsiveness requirement. Thus, NS Filing only for COPYFILE-like operations. Bill *start* 00337 00024 US Date: 27 AUG 84 00:23 PDT From: MASINTER.PA Subject: SPP timeouts To: vanMelle cc: LispSupport Is the SPP timeout any worse than the BSP timeout? It sounds like if I put a few blocks in the compiler and DWIMIFY that you actually *might* be able to load, makefile and compile to and from an NS server. No? *start* 00618 00024 US Date: 27 Aug 84 00:45 PST From: acuff.pa Subject: Re: Copying Lisp source files In-reply-to: masinter.pa's message of 26-Aug-84 23:26:56 PDT To: masinter.pa cc: acuff.pa, LispSupport.pa COPYFILE does not change the information *inside* of the file, which is the problem with moving Lisp files around. The FILEPKG gets confused, etc. For instance, if you've got sources that you've been working on in your private dir (as per your statement), the only truly effective way that I know to move them back to the canonical dir is with MAKEFILE, which can be painful on non-dorados. -- Rich *start* 00560 00024 US Date: 27 AUG 84 01:53 PDT From: MASINTER.PA Subject: moving lisp source files To: acuff cc: lispsupport That problem is exactly what recent changes to the file package were attempting to fix: basically, MAKEFILE and LOADFNS and a few other folks pay a lot less attention to the place the file was originally made. I think that it should be basically OK to COPYFILE a file from one place to the other, and intend to fix any places where it no longer works. I'm interested if you have a recent example which doesn't work "right". *start* 00429 00024 US Date: 27 AUG 84 02:07 PDT From: MASINTER.PA Subject: FLOPPY To: Roach cc: LispSupport Kelly: The version of floppy that you put on Sources> today caused the loadup to crash (exactly how I can't tell from home). It is absolutely unreasonable of you to have deleted the intermediate versions. It is imperative that the "last known working version" always be retained. What got into you? *start* 00608 00024 US Date: 27 Aug 84 05:54 PDT From: Shrager.pa Subject: (SETFILEINFO 'TESTFILE 'BYTESIZE 7] In-reply-to: Masinter.pa's message of 26 Aug 84 16:48 PDT To: Masinter.pa cc: LispSupport.pa Format: TEdit This makes the file readable but loses about 75% of its contents. The program that created the file is ARPANet FTP. I'll play around with settings in there to see if I can make that work correctly. Maybe "interpret as text" should be a flag in COPYFILE? Thanks for the advice. -- Jeff 4 TIMESROMAN ,GACHA  TIMESROMAN z*start* 00251 00024 US Date: 27 Aug 84 05:57 PDT From: Shrager.pa Subject: copyfile In-reply-to: Masinter.pa's message of 26 Aug 84 16:48 PDT To: Masinter.pa cc: LispSupport.pa Telling FTP that it is an ASCII file corrects the difficulty. -- Jeff *start* 00711 00024 US Date: 22 Aug 84 02:59 PDT From: JonL.pa Subject: new I.S.OPRS: inpname To: LISPCORE^ Reply-to: JonL.pa Some weeks ago, I fixed a bug in the implementaion of the I.S.OPRS for "inatom" -- it was duplicating the "body" expression twice, with resultant multiple side effects. Yet, it seems odd that such I.S.OPRS are more general, and available to the user community. With only slightly more overhead, I put in "inpname" which is "safe", and iterates over the pname chars of the datum (this stuff is all EXPORTED to ABC, but not yet installed in the sysout). "inpname" of course will be just as fast as "instring" or "inatom" when the datum is in fact a stringp or litatom. -- JonL -- *start* 00360 00024 US Date: 22 Aug 84 09:55 PDT From: masinter.pa Subject: tedit in release notes To: sannella cc: Sybalsky The fact that TEDIT, when called upon a file that is not random access (e.g., on a NS server or FTP-only host), will copy the file locally, is a great feature of the Harmony release that should be highlighted in the release message. *start* 00328 00024 US Date: 22 Aug 84 16:35 PDT From: masinter.pa Subject: WHOCALLS To: LispCore^ Reply-to: masinter.pa The latest loadups have a function WHOCALLS(fn) which scans all code looking for "fn". I think I will take it out and make it a separate LispUsers package, but it is in the standard system for the moment. *start* 00747 00024 US Date: 23 Aug 84 14:28 PDT From: Kaplan.pa Subject: fn redefined ? To: Masinter cc: Lispcore^ In the latest loadup, maybe earlier ones, when running in ABC, it seems like functions either aren't getting recompiled or redefined as I expect. I edit a function, then cleanup the file, and it indicates that the fn is being compiled. But then I LOADFNS(fn file.dcom). I get a message (fn redefined), but in fact it appears that the fn did not get redefined (or else it did, but the new code didn't get put on the file). If this is because DFNFLG is PROP, then at least the system should not say that it is redefining if it really isn't. But maybe this is more generic? Anybody else observe any funniness recently? --Ron *start* 00465 00024 US Date: 23 Aug 84 16:19 PDT From: Masinter.pa Subject: new behavior on BREAK-REVERT To: LispFriends^ Reply-to: LispSupport I've been trying to fix up the behavior of the REVERT command in break windows to avoid the occasional machine-crash which used to happen when you would, say, REVERT to a PROG. There are enough special cases that I may have gotten one wrong -- please watch when you do REVERT (in loadups dated *after* today, right?) *start* 00425 00024 US Date: 27 Aug 84 09:54 PDT From: acuff.pa Subject: Re: moving lisp source files In-reply-to: MASINTER.PA's message of 27 AUG 84 01:53 PDT To: MASINTER.PA cc: acuff.PA, lispsupport.PA Ok, great! I assume you want to fix any case where the file gets moved, even if it's extra-lisp? I'll stop using the "MAKEFILE" mode, start using COPYFILE, and let you know about any problems. Thanks, -- Rich *start* 00302 00024 US Date: 27 Aug 84 15:47 PDT From: Edouglas.pasa Subject: Re: package database In-reply-to: MASINTER.PA's message of 23 AUG 84 23:51 PDT To: MASINTER.PA cc: EDouglas.pasa, Raim.pasa, LispSupport.PA Please call me. If I can assist you with this, I will be happy to do so. Earlie *start* 00608 00024 US Date: 27 Aug 84 20:24 PDT From: masinter.pa Subject: writing BSP files doesn't take -- termination wrong To: vanMelle cc: LispSupport, Roach Lisp System Date: 23-Aug-84 18:52:49 Machine: Dandelion (Purcell) Microcode version: 24,4 Memory size: 15777 Frequency: Always Impact: Fatal This one must have crept in 25-Aug 23:10 BSP or DPUPFTP of that date: OPENFILE({ERIS}FOO OUTPUT NEW NIL (SEQUENTIAL] PRINT(HI) CLOSEALL] the file will be closed and deleted. Apparently Eris thinks the connection terminated. This is why the last couple of loadups have failed (apologies, Kelly) *start* 00324 00024 US Date: 27 Aug 84 20:53 PDT From: masinter.pa Subject: renamed BSP => BADBSP, DPUPFTP => BADDPUPFTP & restarted loadup To: vanMelle cc: LispSUpport, Burton Bill, I renamed the new versions of DPUPFTP & BSP temporarily to get a loadup going. The old versions are still on LispCore>SOurces>BAD*. Larry *start* 00868 00024 US Date: 29 Aug 84 08:21 EDT From: Gocek.henr Subject: Star and Lisp To: Consultants^.ES, LispSupport.PA cc: Evanitsky, Boesl, Parthasarathi, Dumas, Hill I've been involved in trying to load the newest version of Star (4.3?) and Lisp on a 43MB Dandelion. Star won't load. The Star installation floppies eventually print a vague error message like, "Trouble loading software" on the second or third disk. The configuration is: Othello - 500 - DebuggerDebugger Lisp - 16200 - Normal Dsk - 2000 - Normal System - 6100 - Normal User - 40000+ - Normal Installed on Othello is OthelloDLion.boot. Installed on User are Mesa.db, DLion.germ, and TajoDLion.boot. The physical pointers were set to User. Also installed is 1.5M of RAM. Is 6100 pages too small? Am I missing something? I can give more detailed info if it would help. Thanks, Gary *start* 00590 00024 US Date: 29 Aug 84 13:06 EDT From: Gocek.henr Subject: Lisp/Star problem solved To: Consultants^.ES, LispSupport.PA cc: Evanitsky, Boesl, Parthasarathi, Dumas, Hill The problem seems to have been due to the act of installing mesa.db and dlion.germ on User and then setting the physical pointers to User (and answering all of the Yes/No questions with Yes). I installed Mesa.db and dlion.germ on System and set the physical pointers to Othello, and Star loaded correctly. I also have heard that Othello 11.0 is 524 pages, so I will need bigger Othello volumes. Gary *start* 00930 00024 US Date: 29 Aug 84 15:04 PDT From: burton.pa Subject: extraneous login request To: LafiteSupport I keep my mail on {dsk1} which has a password identical to my grapevine password. Recently (since last Friday?) I have been asked for my password for {dsk1} (in a nice looking prompt window). Did something change about it trying existing passwords on new devices first? Richard ps. When I first saw this prompt window, I typed my password and nothing happened. I then noticed my password had echoed and generated a UBA error in the exec window and finally saw the little message to "click here to type" in the prompt window. I'm not sure how to fix it but I don't like the idea of being encouraged to type my password when it echoes. Maybe the part of the login the prints the proposed login name could be held until that process has the tty. That way the user won't be inclined to type the password. *start* 00590 00024 US Date: 29 Aug 84 09:23:15 PDT (Wednesday) From: LNelson.ES Subject: Re: Star and Lisp In-reply-to: Gocek.henr's message of 29 Aug 84 08:21 EDT To: Gocek.henr cc: Consultants^, LispSupport.PA, Evanitsky.henr, Boesl.henr, Parthasarathi.henr, Dumas.henr, Hill.henr Gary, By the way, your 500 page Othello volume is also too small. The 11.0 version is 524 pages. I recommend 600 or 650 pages for Othello. Rain El Segundo IFS 1.38.1, File server of February 14, 1984; 7 users out of 8 11.0 OthelloDLion.boot!12 268288 4-Jun-84 10:54:26 PDT LeRoy *start* 00842 00024 US Date: 29 Aug 84 15:27 PDT From: vanMelle.pa Subject: Re: extraneous login request In-reply-to: burton.pa's message of 29 Aug 84 15:04 PDT To: burton.pa cc: LafiteSupport.pa I don't think anything has changed in that regard. I, too, have mail files on a different partition and haven't suffered any extraneous password requests. Were you asked the question while running on a non-password-protected partition? Was your disk name Burton or Burton.pa? (not sure whether those things matter, but I'm looking for possible differences.) I agree about the password prompter--it needs to be a little less tempting to type at when it doesn't have the tty. Your suggestion seems reasonable. The other thing I might wish for is that it be as easy to have a large title on a window as it is to have a large border. Bill *start* 00379 00024 US Date: 29 Aug 84 15:38 PDT From: burton.pa Subject: Re: extraneous login request In-reply-to: vanMelle.pa's message of 29 Aug 84 15:27 PDT To: vanMelle.pa cc: burton.pa, LafiteSupport.pa I changed the name on that partition from Burton to Burton.pa. That's probably it as partition 1 is just Burton. Suggestion about window title font noted. richard *start* 01318 00024 US Date: 29 Aug 84 12:11:01 PDT (Wednesday) From: Menzies.es Subject: Re: Star and Lisp In-reply-to: Your message of 29 Aug 84 08:19:46 PDT (Wednesday) To: Gocek.henr cc: Consultants^, LispSupport.PA, Evanitsky.henr, Boesl.henr, Parthasarathi.henr, Dumas.henr, Hill.henr, Menzies.es Reply-To: Menzies.es Gary, My earlier message may have been confusing. Let me clear it up a bit. debbie - - - - - - - - - - - - - - - All size disks vs Othello: Othello >= 575 for bootfile alone 850 for bootfile, microcode, and germ Disk size vs minimum System size: 10Mb disk System >= 6700 29Mb disk System >= 8000 42Mb disk System >= 9000 All size disks vs User: User >= 9000 (allows approx 4000 free pages after installation of data files) Note: Beginning with Star 3.3L, the maximum size for the System volume in a two-volume System/User configuration is 12000 pages. If you make the System volume larger, then Star will think you want to put all your data files and desktops into the System volume. This is generally not a good idea, as File Check cannot be run over the user file system if it resides in the same volume as the bootfile. For more information on installing Star, refer to the Installation Document stored on [Rain]3.3mr>Doc>Installation.doc *start* 00649 00024 USa Return-Path: Received: from SU-AI.ARPA by Xerox.ARPA ; 29 AUG 84 17:21:56 PDT Date: 29 Aug 84 17:21 PDT From: Terry Winograd To: lispsupport.PA I am trying to begin using TEDIT for real work, but having problems. When I do a GET from a remote (DEC20) server, the file comes in with a line-feed following every carriage return. A copyfile on the same file seems to do the right thing instead. Also, when I try to copyfile from SCORE (a standard DEC-20) I get the message that it doesn:t respond to the leaf server. Isn't there a copyfile that uses one of the simpler protocols? Thanks --t *start* 00608 00024 US Date: 28 Aug 84 14:01 PDT From: Roach.pa Subject: Re: FLOPPY In-reply-to: MASINTER.PA's message of 27 AUG 84 02:07 PDT To: MASINTER.PA cc: Roach.PA, LispSupport.PA I deleted FLOPPY's from 3 days ago rather than the July versions which are the versions I know work(ed). The intermediate versions you created weren't actually known working versions I believe. I renamed the July FLOPPY.DCOM to make it be the latest version and I will look at the most recent August version, but from your last message, I understand that FLOPPY may not be responsible for your loadup problems. *start* 00528 00024 US Date: 28 Aug 84 12:52 PDT From: trigg.pa Subject: Lisp: DEdit of undefined function To: LispSupport.pa cc: trigg.pa Lisp System Date: 23-Aug-84 18:52:49 Machine: Dandelion (Melba) Microcode version: 24,4 Memory size: 5777 Frequency: Always Impact: Annoying From the top level, if I call DF on an undefined function, it lets me edit a "blank" function. If I try to do that from inside DEdit (by clicking 'edit' for an undefined function name), it doesn't work. Could this be made consistent? Thanks. *start* 00272 00024 US Date: 28 Aug 84 19:28 PDT From: Roach.pa Subject: Re: FLOPPY To: MASINTER.PA cc: Roach.pa, LispSupport.PA The August version of FLOPPY loads OK in a virgin sysout. I've remade it the current version. Kelly *start* 00659 00024 US Date: 29 Aug 84 08:19:46 PDT (Wednesday) From: Menzies.es Subject: Re: Star and Lisp In-reply-to: Gocek.henr's message of 29 Aug 84 08:21 EDT To: Gocek.henr cc: Consultants^, LispSupport.PA, Evanitsky.henr, Boesl.henr, Parthasarathi.henr, Dumas.henr, Hill.henr Reply-To: Menzies.es If you are attempting to load Star 3.3mr, which is the curent update, then you must have your Systems volumes (minimum) as follows: 10Mb disk System = 6700 29Mb disk System = 8000 42Mb disk System = 9000 All size disks User = 9000 (allows approx 4000 free pages after installation of data files) Maximum size is 12,000 pages. debbie *start* 02118 00024 USa Date: 30 Aug 84 10:42 PDT From: trigg.pa Subject: Lisp: Questions about 'for' and 'if' To: LispSupport.pa cc: trigg.pa Lisp System Date: 23-Aug-84 18:52:49 Machine: Dandelion (Melba) Microcode version: 24,4 Memory size: 5777 Frequency: >> Always, Intermittent, Once << Impact: >> Fatal, Serious, Moderate, Annoying, Minor << I just came here from Maryland where we were running Franz augmented with bits of Interlisp (as well as MIT Flavors). Given that bias, I had a couple of observations: 1. When we stole your 'for' syntax (and implemented via a macro translation to Franz 'do') we allowed multiple 'in's. Why is this illegal in Interlisp? For example, how does one accomplish the following without two 'in's? (for x in LIST1 y in LIST2 collect (CONS x y)) (Our rule was that the for loop ends as soon as any 'in', 'out', 'from', etc. ends.) 2. Regarding 'if', why did you choose that syntax? I've noticed that it makes it harder to type certain expressions that should be simple. In particular, this applies to the ones with multiple 'then' or 'else' clauses since a PROGN is required. Thus, (COND ( )) requires (if then (PROGN )) which seems cumbersome so people will continue to use the simpler COND form. We used an 'if' syntax that relied on the keywords 'then' and 'else' to dictate the breaks. Specifically, the syntax is ::= (if [][] ::= [then] ::= else | elseif [][] ::= implicit PROGN of s-expressions. Since the 'then' keyword is optional, the above example could be written: (if ) which is quite compact. There are other syntaxes for 'if' which allow multiple 's using an implicit AND. In that case, the 'then' keyword is required. But even that yields a more concise form then the Interlisp version. What's the reasoning here? - Randy *start* 00538 00024 US Date: 30 Aug 84 13:27 PDT From: Kaplan.pa Subject: EOL Convention in Tedit To: Teditsupport, Lispsupport I was under the impression that Tedit had been fixed to do the right kind of coercions for files whose EOL convention is not CR. This appears not to be the case. I TEDITed a file on Maxc, and got the ugly black-boxes for all the linefeeds. Can this be fixed by Harmony? Remember, that most of the rest of the world depends on file servers (e.g. Vaxes, 20's) whose native eol convention is not CR. --Ron *start* 00786 00024 US Date: Thu, 30 Aug 84 10:55 PDT From: VanLehn.PA Subject: Bugs To: LispSupport.pa cc: VanLehn These bugs from CURRENT> 1. While doing a HardcopyW a couple of days ago, a break window popped up with the message: Error in Courier program CLEARINGHOUSE, procedure RETRIEVE.MEMBERS: ARGUEMTN.ERROR (NO.SUCH.OBJECT FIRST) 2. In an almost new sysout, I accidently typed REDO 1 instead of REDO 15. It started to do a MAKESYS, but I killed it before it wrote anything. This seems like a dangerous trap to leave hanging around. MAKESYS should clobber the history list. 3. The inspector's menu of record names, in my program, is so long that the last dozen record names are off the bottom of the screen. To select them, I need a two column menu. -- Kurt *start* 00667 00024 USa From: dcatton.rx Date: 31-Aug-84 14:24:30 Subject: missing AR To: lispsupport.pa cc: vanmelle.pa linkoping@@bbng.arpa Bill, I guess this isnt exactly your problem but your response (July 22) to thethree ARs I sent way back on June 25 is my only proof of delivery. The three ARs concerned (1)DATATYPE fields,(2)getfileinfo and (3) the behaviour of CNDIR. The last two got XSIS references 1504 1506. What happened to the first ?to recapitulate DATATYPE field declarations of funny sizes i.e. not 16, 32 give garbage returns to FETCHES when numbers are stored into them. LISPSUPPORT please mail me if you can't locate this. will pickles at AIL *start* 00610 00024 US Date: 31 Aug 84 11:34 EDT From: Koomen.wbst Subject: Lisp: PACK/UNPACKFILENAME not inverse !!! To: LispSupport.pa cc: Koomen.wbst Lisp-System-Date: 21-Jun-84 10:50:28 Machine-Type: Dandelion (MOVD 'PACKFILENAME 'PFN) (* for brevity's sake) (MOVD 'UNPACKFILENAME 'UPFN) (UPFN '*FOO*) = (NAME *FOO*) (UPFN '*FOO*.) = (NAME *FOO* EXTENSION NIL) (PFN (UPFN '*FOO*.)) = *FOO* (EQUAL (DIRECTORY '*FOO*) (DIRECTORY '*FOO*.) = NIL (EQUAL (DIRECTORY (PFN (UPFN '*FOO*))) (DIRECTORY (PFN (UPFN '*FOO*.)))) = T I think (UPFN '*FOO*.) should return (NAME *FOO* EXTENSION "") -- Hans *start* 01176 00024 US Date: 31 Aug 84 11:38 EDT From: Denber.wbst Format: TEdit Subject: New Calendar To: Lispsupport.pa I understand that there is to be a new Lisp release shortly. I would appreciate it if you could include in the Lispusers section of the release notice mention of the fact that Calendar has been significantly revised and improved. I will be moving the new version to {Eris} next week. Thanks. (1 0) (73 28 "@@@@@@@@@@@@@@@@@@@@" "@@@@@@@@@@@@@@@@@@@@" "@@@@@@@@@B@@@@C@@@@@" "@@@@@@@@@F@@@@DH@@@@" "@@@@@@@@@F@@@@DH@@@@" "@L@@@@@@@E@@@@DH@@@@" "AJ@@@@@@@E@@@@HH@@@@" "AB@@@@@@@E@@@@HH@@@@" "CB@@@@@@@E@@@@HH@@@@" "BA@@@AH@@E@@@@HH@@@@" "BACB@B@@@D@@@@HH@@@@" "@ACC@@@@@B@@@@DH@@@@" "@AGC@@@@@B@@@@E@@@@@" "@AEM@@@@@EH@@@F@@@@@" "@AMI@@@F@DD@H@F@@@@@" "@AHI@B@I@BDAF@F@@@@@" "@AHI@BA@@DDAB@K@@@@@" "@A@I@BA@@DDABAAH@@@@" "@A@I@BA@@LBABF@H@@@@" "@A@I@BA@@LBAEH@D@D@@" "@A@I@FA@ADCHL@@C@H@@" "@A@IHIC@FD@GH@@@K@@@" "@B@HMIBOH@@@@@@@D@@@" "@B@HCAB@@@@@@@@@@@@@" "@B@@@@L@@@@@@@@@@@@@" "@@@@@@@@@@@@@@@@@@@@" "@@@@@@@@@@@@@@@@@@@@" "@@@@@@@@@@@@@@@@@@@@")  TIMESROMAN  BMOBJ.GETFN TIMESROMAN ,z*start* 40325 00024 US Date: 30 Aug 84 12:11 PDT From: Dietterich.pa Subject: Lisp: Same symbol appears multiple times in fn name table To: LispSupport.pa cc: Dietterich.pa Format: TEdit Lisp System Date: 29-Aug-84 20:58:02 Machine: Dorado (LeParc) Microcode version: 24,4 Memory size: 10000 Frequency: Intermittent Impact: Unknown NOTE: This msg contains big bitmaps. Is the following a bug? I have the following function  m@!pqD"@QDEHBd $2(@QDEHBd $2(@HG@I@QSEx@T *(@T9 IG#.$H@R$HD@T D*D@8I GI"'C@R$ODBL $&|@TI@YI2)AC@R$HDBL $&D@IDA/QC|LjxqD "D C G#C@  A> @q>H_|* $"@Bc g0q LDP@H@!HBc<H $$I I aJDM$x0@* $!"BU $$ry HID$@0@$"@ABU H@($$A HHI$P@H@ @I>8p@qHD|B$$@$   #:Ju [8g8 ,`ĒN&i$@%4$$ I4'H$I<0$$r$$ I$$Ȑ$I $$$ I$#H4 Ip#> F$r @ @)cÝ%0`,bB1LXS 0Î 8c#éM$!&I$'HI$4CIIhtI$ $ $I:IT!'$I$xG$$<BO9HDy $ 'O#4"I$ dI$A$@I$$ BHPIHDA $ $$H"##98Np$rBGu HC 8 8 #g"     0@ @ Kt`$asĖ8 +#`#FX:u3M$4t@M$@$H:N -$N$@IhII$I$$$@I'@ $HH $#OHHd9$$$$@I$ @ %HHI$ @DHH I$I4p$`a3`ƒ8I#p'GSGHIuBD!Ç8'!$HD!($A$HD (AH@ B(§AK@ BD" ADHD |D A$HD!DD!#8!DGȄ 8"@p>|DD@DB "@! "DBl@DB @! "(Bl @0B @ <P"BT @B @  P""B"T @DB @! 0"(B>T @DB "@! 0"DB"T @8A"|p>qD"D@@`@8>8qȟ |`p>!q 8q`D" "`H"@!DH"@B CD"||"3|yH"@ADH"@B Cc6@Pf3f͘"`@ AC @ `Cc6@Pf f"@A  @ Cc6D0"f"fH"@AH"@B Cc6D0"f"f͘H"@A$H"@B Ca8qȄf|fyp!#p@>8pC @ @     @006`6`6`6` @* OêC`)$P:ыЁ:A4:I$pBI$M @* !A$#$@2II@ !$" ,@ K$I@ p!4@rm:щ8@ @>D yB d!@"D"ͰD!0 |爄T"H!@!D@HT"H!@AD@E0 "x!P @AG P"D!P "@ A%PT"D!0 >@A0T"D!0"@A$@0B8xqȄ"| $@B  @8D<pȟD yB d!@"D"ͰD!0 |爄T"H!@!D@HT"H!@AD@E0 "x!P @AG P"D!P "@ A%PT"D!0 >@A0T"D!0"@A$@0B8xqȄ"| $@B  @8D<pȟLDB$I"LADAH"DpB and when compiled, the inspector looks like this: 8p`8 "D "DljX &@aB,x&LO,8#" d *x!p$B D2 *T$2D# D*D"  *TD"|B D2D " 2dD "@"ID "D!! D $"DĊ2D#D 8p  8C,8#@  |# @"@!!"@`068c"@!!"Ï8pC@P *DB x!Ȃ DDB @P*|.@!DC @ѐ*@"@!a"@D@ @*DB"@!a" DDB @*8| #a8pCH  O H HH   HɀJJLH    ""Dτp    `ÇDHDɀ"EJ"EJL DH C a<8!ѐ%H"!O<#%HD"%HD"!G xH$H@D@""DI$(L2""DP!GBTP@BxP %@%@TP@DJ" P  &@&@dɐ@G"H "$H$BD@H"D p!ÇÂ>8pHD aÇ8pÀ!ϑ>xH$H@D$@""DH$B(L2d" DP!GTRB<xP %@!TR@DJ" P  &@"dɓ$@G"H "$H$D$@H"D τp!Ç>8pÀHD 8p! |EHD"""EH(L2b""ĂTRB$ $TRDJ$ 'dɓ'G>" D H"p>8pH8pÀ!H$H@D$@""HD(L2`@" EGǂTRB@@$@TR@DJ@$@dɓ @GH$BD$@H"qÂ>8pÀH cÀ8p!B#<H`$F$@D#"$H"ID(L2e"($J"! EBBTRB <J! B%@TRDJ(L!B&@dɓ!GdE$H !B$BD!HdE"!Â>8pH>#"aÏÀ8pÀ!H|H$H$@D$@""H"H$B(L2d"&"!OTR@B*B %H!TR@DJ*D &@"dɓ&@G2"H"$H$D$@H"H"p!Ç>8pÀHOa!DE""@B""BlE"@B""Bl!āĂABBTI $$ADJ"B"TO ''AGB>TA"  @H B"Tp!H>"DÀ!>H"$@B"H"B"(DǂABH$@ADJ Hπ$@AGH$B@HpÂH>@Ç!@DH$@@B"""$@ADɀDB"&""BEJEB@AB*!BEJ@@ADJ*!̀CL@@AG2"@DHB@@H"$@CH@$@@ DB @@ @ @@"@ B D@ @π @@$@@ D G@ @@Ȁ @@B@ Is this a bug? Should SITENTRY appear twice as a local variable? On AUg 20, when I executed this function on a Dlion, it broke inside $DEF (an NLAMBDA that evaluates its argument) with the message SITENTRY - Unbound atom. Evidentally, it was picking up the wrong occurrance of SITENTRY on the stack. Also on AUG20, execution of this function on a Dorado occasionally gave different results when interpreted than when compiled but I didn't have time to track them down. Today, the function seems to work on a DORADO, and I haven't tried it on a Dlion. --Tom  TIMESROMAN ` BMOBJ.GETFN25 TIMESROMAN 7 BMOBJ.GETFN29 TIMESROMAN z*start* 01366 00024 US Date: 30 Aug 84 11:16 PDT Sender: Sannella.pa Subject: Re: Tedit/copyfile and DEC20 server In-reply-to: Terry Winograd 's message of 29 Aug 84 17:21 PDT To: TW@SU-AI cc: lispsupport.PA From: LispSupport.pa Reply-To: LispSupport.pa Interlisp tries to do the right conversions for servers with different EOL conventions (CR, LF, CRLF), but all of the cases have not been taken care of yet. Tedit currently ONLY supports the single-CR EOL-convention. Interlisp can automatically convert files with different EOL conventions, but watch out with formatted TEDIT files: the formatting info at the end of the file contains absolute pointers, which can be invalidated if all CRs are converted to CRLF. If you do a COPYFILE (which changes CRLF->CR) of the unformatted text, and then you use Tedit, you should be alright. In the latest versions of Interlisp, COPYFILE has been fixed to use the FTP protocol. Until that version is released, you can use the following hack: (DEFINEQ (COPYFILE.FTP (A B) (PROG ((ASTREAM (OPENSTREAM A (QUOTE INPUT) (QUOTE OLD) NIL (QUOTE (SEQUENTIAL T)))) (BSTREAM (OPENSTREAM B (QUOTE OUTPUT) (QUOTE NEW) NIL (QUOTE (SEQUENTIAL T))))) (COPYBYTES ASTREAM BSTREAM) (CLOSEF ASTREAM) (CLOSEF BSTREAM))) If you use COPYCHARS instead of COPYBYTES, this will also do the appropriate EOL conversion. *start* 02435 00024 US Date: 30 Aug 84 19:26 PDT From: Raim.pasa Subject: Lisp meeting 8/25 To: Pahlavan cc: Bird, Cheslow, Dering, EDouglas, Hihn, JFung, Le, Martin, Mersfelder, Spoor, PYoung, Wogulis, Vittal, LispSupport.pa, Raim 1. Beau proclaimed that Dennis Dunn's sales force was "overwhelmed" with prospective customers. 2. Rich Acuff plans to announce his DVI package, which allows hardcopy to go to "cheap" laser printers, such as the Imagen. He continues to make progress on TCP/IP. 3. Richard Burton has implemented hardcopy streams, which allow the user to display text in the same form it will be printed (or a close approximation thereof). This will be released as part of Richard's Sketch package. 4. Kelly announced the first release of a facility to archive local disk directories on floppies. He also announced his fix to the Lisp/Mesa floppy incompatability problem. 5. Mike Sannella released his Lisp based ARedit tool (to a well-deserved round of applause.) 6. Beau re-outlined the procedure for submitting urgent requests to PARC: (1) Submit an AR plus a message to the person named in the Attention field of the AR. (2) The PARC person who receives the AR must either take responsibility for it or re-assign responsibility to someone else. (3) Mike Sannella makes sure the assignment is made. (4) If after a week no action has been taken, message Sheil.pa with a reference to the AR. 7. Ron Kaplan announced further enhancements to DIG. Grapher has been enhanced to deliver clipped images to hardcopy. 8. Clay Agadoni and his organization were acknowledged for their responsiveness in getting a demo machine to Boston on very short notice. 9. Larry Masinter has made "countless" fixes to various major system components. He released a new version of the Hello Mesa tool. 10. The customized sysout for APEX will be a Harmony sysout available by mid-November. 11. The current Harmony instabilities are: DLion file system, Tedit, and printing. 12. Larry Masinter agreed to implement a "bucketizing" algorithm for allocating array space. 13. The question was raised whether unboxed floating point numbers should be supported in Harmony. The observation was made that 1100 and 1132 performance would be adversely effected. Steve Purcell suggested a DandeTiger library package which would provide unboxed floating point without affecting the performance of other machines.