Date: 20 June 1981 11:52-EDT From: David C. Plummer To: BUG-LISP at MIT-MC In current XLISP assume you are on tty 50, so that the sixbit symbol whose value is 50 is 5 spaces followed by a capital-H (setq foo (open '((spy) | H|) '(in ascii single))) #FILE-IN-|SPY:* *|-70754 (read foo) MPV; RDCHAR+1>>MOVE B,@RSXTB B/ AOJE F,SSTTY3 202354/ ?? This may be an artifact of 12 bit input sources (Space Cadet Keyboards)  Date: 19 June 1981 12:44-EDT From: John G. Aspinall Subject: FFORMA (floating point format stuff) To: BUG-LISP at MIT-MC cc: JGA at MIT-MC This is a minor quibble - not worth a lot of effort - but: (print-fixed-precision-floating 5.0e-04 16. 8. '(e) t) prints 5.000001e-04. Several other flonums do this too, the error seems to be adding one in the last digit always.  Date: 17 June 1981 13:15-EDT From: Jon L White To: KRONJ at MIT-MC cc: BUG-MACLISP at MIT-MC, GJC at MIT-MC, LISP-FORUM at MIT-MC Date: 16 June 1981 23:39-EDT From: David Eppstein Is there any way to get DEFVST-structures to print in a machine-readable format? Or does there exist somewhere a way to make the #-readmacro recognize #{STRUCTNAME FOO ...} type constructions? If you have the DEFVST file loaded into a lisp which has some structures created in it (even those that may have been loaded from FASL files before the DEFVST/EXTEND files were loaded), then the structures will print out nicely -- in fact, one could define a meaning for "#{", using DEFSHARP, to cause the printed form to read in into an EQUAL structure. But there has not been complete agreement on this feature, nor really strong interest, so no one has taken the liberty of adding it yet.  Date: 17 June 1981 12:17-EDT From: Jon L White Subject: DEFVST should autoload DEFVSX To: WGD at MIT-MC cc: BUG-LISP at MIT-MC Date: 17 June 1981 06:26-EDT From: William G. Dubuque DEFVST 148 needs SI:CHECK-DEFVST-VERSION, which is undefined. At least it is after loading a compiled file containing defvsts into a bare lisp and then loading DEFVST. Right -- it's defined in DEFVSX, which DEFVST used to subload, and which got lost in the shuffle to SHARPC conditionalizations, but I've just fixed it in version 149.  Date: 17 June 1981 06:26-EDT From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-LISP at MIT-MC DEFVST 148 needs SI:CHECK-DEFVST-VERSION, which is undefined. At least it is after loading a compiled file containing defvsts into a bare lisp and then loading DEFVST.  GSB@MIT-ML 06/17/81 03:59:26 Re: Lisp 2117 on XX To: (BUG LISP) at MIT-ML CC: (BUG BRAND-X) at MIT-ML, BYRON at MIT-ML (status ttysize) returns (width . height) instead of (height . width). This greatly confuses various programs, not the least of which is my tty prescan; it depends on this information to be correct, and this causes incredibly gross losing spasticity for rubout processing.  Date: 16 June 1981 23:39-EDT From: David Eppstein To: BUG-MACLISP at MIT-MC Is there any way to get DEFVST-structures to print in a machine-readable format? Or does there exist somewhere a way to make the #-readmacro recognize #{STRUCTNAME FOO ...} type constructions?  Date: 16 June 1981 17:44-EDT From: George J. Carrette Subject: (APPLY 'SSTATUS ...) To: GSB at MIT-MC cc: BUG-LISP at MIT-MC I always use (EVAL `(SSTATUS FOOBAR ',BAZ)) now, since it always works in an obvious manner. [...honestly never could gronk how fsubr's apply ...]  GSB@MIT-ML 06/16/81 04:45:58 Re: lisp 2117 on XX To: (BUG LISP) at MIT-ML (apply 'sstatus (cons 'tty (status tty tyi))) dies with ;#22075 PC WITH ILLEGAL INSTRUCTION CODE and messes up something or other such that ^B doesn't work but ^K and space get ^B breaks. This makes it difficult to save & restore tty status flags.  Date: 16 June 1981 02:10-EDT From: Jon L White Sender: JONL0 at MIT-MC Subject: DESCRIBE method for STRUCT-CLASS To: RWK at MIT-MC cc: BUG-LISP at MIT-MC Date: 11 June 1981 02:10-EDT From: Robert W. Kerns The describe method for STRUCT-CLASS is bogus. (DESCRIBE (GET 'LOCAL 'FEATURE-SET)) says all the slot values are LOCAL. The problem is that you didn't have SHARPA loaded, so the DESCRIBE method was getting () for the selector property of the various macro-accessors. Probably a good idea for the describe method to retrieve that index some other way.  Date: 16 June 1981 01:54-EDT From: Jon L White Sender: JONL0 at MIT-MC Subject: SI:GEN-LOCAL-VAR To: RLB at MIT-MC cc: BUG-LISP at MIT-MC The form (SI:GEN-LOCAL-VAR) just coughs up a "local var", but doesn't provide the SETQ -- that's the form to use with LETs etc. Also, (SI:GEN-LOCAL-VAR () "FooBar") supplies the same kind of prefix to the local var that (GENTEMP "FooBar") would supply.  Date: 16 June 1981 01:46-EDT From: Richard L. Bryan Subject: SI:GEN-LOCAL-VAR To: JONL at MIT-MC, BUG-LISP at MIT-MC Yeah, I suppose so. Although I suppose it doesn't apply to DEFUN& and DEFMACRO, there are often stylistic reasons for wanting to code with LET rather than SETQ (always, for instances of GENTEMP in my code). I suppose that means that a flavor of GENTEMP is desirable which automatically does the putprop under :LOCAL-VAR that SI:GEN-LOCAL-VAR does. Or else it means that the expansion of SI:GEN-LOCAL-VAR shouldn't be doing the SETQ for itself. Actually, I prefer the latter.  Date: 16 June 1981 01:18-EDT From: Jon L White Subject: DEFMACRO's generation of internal variables To: BUG-LISP at MIT-MC DEFUN& and DEFMACRO should use SI:GEN-LOCAL-VAR, instead of GENTEMP, so that these super-internal variables aren't automatically SPECIALized when compiling with SPECIALS = T.  Date: 15 June 1981 14:05-EDT From: Jon L White Subject: Restriction condition in DEFVST To: RLB at MIT-MC, touretzky at CMU-10A cc: BUG-LISP at MIT-MC Touretzky's case is now fixed, as mentioned in: Date: 12 June 1981 20:03-EDT From: Richard L. Bryan Date: 12 June 1981 1946-EDT From: Dave Touretzky at CMU-10A (defvst x (name /: symbol)) ...load some stuff... X (cons-a-x) ;FOO UNBOUND VARIABLE The restriction alist in the (SETQ INIFORM ...) part of the DEFVST macro has a pair (SYMBOL . FOO) which should be (SYMBOL . 'FOO). I wrote out a new source version MC:NILCOM;DEFVST 144 but didn't compile it since I don't understand all the circular interfile compilation dependencies. The compilation dependencies are hierarchical rather than circular, and are as follows: DEFVST 3 || \/ DEFVSX 2 || \/ DEFVSY 1 || \/ EXTSTR 0 That is, in order to compile a level-n file, all the files below it have to be usable in the COMPLR, but none at the same or higher level is required. Some other features are used too, like EXTEND, EXTMAC, EXTHUK, DEFSETF, and UMLMAC, but they are independent of DEFVSxxx. I've also edited the DEFVSxxx files to use a 1-arg version of GLOBALIZE, and to use the SHARPC form of code conditionalization (should make cross-compilation a little more comprehensible). Dave: You should just FTP over to CMUA new versions of DEFVST.FAS, DEFVSX.FAS, and DEFVSY.FAS (the latter two not being strictly necessary to update, but why not).  Date: 14 June 1981 21:46-EDT From: Robert W. Kerns Sender: BIL at MIT-MC Subject: *ARRAY doesn't check size for plausibility To: BUG-LISP at MIT-MC It would be nice if (*ARRAY () T 100000. 12.) would give you an error, instead of returning you an array that claims to be bigger than your address space, but which only GC-protects a fraction of your address space. Even better, of course, would be to fix it so it really does give you an array as big as it says it does. Of course, we can always simulate arrays by counting on our fingers.  Date: Sunday, 14 June 1981, 19:12-EDT From: Robert W. Kerns To: KRONJ at MIT-MC Cc: BUG-LISP at MIT-MC, WGD at MIT-MC, RLB at MIT-MC In-reply-to: The message of 12 Jun 81 21:33-EDT from David Eppstein Date: 12 June 1981 21:33-EDT From: David Eppstein To: BUG-LISP at MIT-MC What is EVAL-ORDERED* and why does it have an autoload property of ((LISP) AUTOLOAD FASL), which upon not being found gives me an IO-LOSSAGE error when I try to load my file ((AR1 GUEST2) GENE >). As far as I can tell, it is in the middle of a DEFVST when it has that problem. EVAL-ORDERED* is an internal function which tries to keep the evaluated parts of a SETF spec evaluated in left-to-right order despite the fact that some things which SETF expands into take their arguments in funny orders. It had an absurd autoload property because JONL's mind wandered while he was changing the file to use his new DEF-OR-AUTOLOAD macro. I have fixed this.  Date: Sunday, 14 June 1981, 17:17-EDT From: Robert W. Kerns Subject: [GJS at MIT-AI: Forwarded] To: DICK at MIT-MC Cc: GJS at MIT-MC, BUG-LISP at MIT-MC Date: 14 June 1981 06:04-EDT From: Gerald Jay Sussman To: BUG-LISP at MIT-AI debug* 205 is a loser. blows up in ? also loses after continuation (C) when next error happens.  Date: 14 June 1981 11:12-EDT From: George J. Carrette Subject: array garbage collection. To: RWK at MIT-MC cc: BUG-LISP at MIT-MC It is very easy to illustrate the bug, I put a file which did in L;GCBIB BUG. Somebody deleted it though. Here it is: (ARRAY K NIL 10) ; a NON-GC array for looking at things. (DO ((A (*ARRAY NIL T 10))) (T (STORE (ARRAYCALL T A 0) A) ; array points to itself. (STORE (K 0) A) ())) (PROGN (STORE (K 1) (*ARRAY NIL T 10)) ()) (K 0) ; ok. (K 1) ; ()()() ; Clear the value of * (GC) (K 1) => dead array. ; ok. (K 0) => live array. ; the sucker didn't get GC'd. If you look at the code for GC-marking of the ARRAY datatype you will see that it can't possibly garbage collect the array in (K 0). No matter how many times you GC. Anyway, the body of a HUNK is marked correctly, I don't really see why the body of an ARRAY could be that much more difficult to handle. I'll admit the GC code is a bit "tight" as far as register-saving conventions, etc., so it will take a bit of effort to figure out how to change the code. But with all the work being put into maclisp lately it is a shame to see fundamental and fixable bugs simply ignored. -gjc p.s. This bug should be mentioned in the documentation for *ARRAY.  Date: 14 June 1981 06:04-EDT From: Gerald Jay Sussman To: BUG-LISP at MIT-AI debug* 205 is a loser. blows up in ? also loses after continuation (C) when next error happens.  Date: 13 June 1981 23:42-EDT From: Glenn S. Burke Subject: maknam/intern To: BUG-LISP at MIT-MC i replied to gz  Date: 13 June 1981 22:55-EDT From: Gail Zacharias Subject: maknam/intern To: BUG-LISP at MIT-MC This may not be a bug, I just don't understand why it gives a different answer the two times... (I am hoping the second one is correct) :lisp LISP 2100 Alloc?n (setq foo (maknam '(b a r))) BAR (eq foo (intern foo)) T (setq foo (maknam '(b a r))) BAR (eq foo (intern foo)) NIL  Date: 13 June 1981 16:58-EDT From: Glenn S. Burke Subject: array garbage collection. To: RWK at MIT-MC cc: BUG-LISP at MIT-MC To the best of my knowledge, when the array linkages are circular they never get gced. I was shafted by this once long ago. I still haven't figured out why it doesn't just continue recursing for the mark phase. (Or if i did once upon a time i don't remember.)  Date: 13 June 1981 12:40-EDT From: David C. Plummer To: BUG-MACLISP at MIT-MC sorry, meant MUNKAM, not maknum  Date: 13 June 1981 12:29-EDT From: David C. Plummer Subject: eoffn To: BUG-MACLISP at MIT-MC (I would cc this to BUG-MANUAL, but that list seems to be dead.) The documentation in :info maclisp input ... which describes eoffn does not conform to practice (or vice versa). [for a file opened with (open ... '(in fixnum single))] doc: when eof is reached, the end-of-file function is called with two arguments... practice: the end-of-file function gets only one argument: the file object. (for ascii files it gets two arguments) doc: the second argument is the eofval made on the call to the reader, or nil if none was supplied practice: in the (in ...) case, none CAN be supplied (maybe one should be possible), and therefore I suggest that the newly created second argument to the eoffn be made nil. This should be made more general (if it doesn't break 3.14*10^100 programs already in existence). Also, on the same subject of (open ... '(in fixnum single)) doc: if the end-of-file function returns neither t nor nil, then the result is immediately returned as the value of the input. practice: (eoffn '(lambda (x) -1)) does NOT return -1, it returns a number similar to 100040075056(octal). I don't care where this number came from, since it is supposed to be -1. In fact, if I try to return '(this is a list) I get 0, and if I try "this is a string" I get 10000075061(8). I did a maknum on these, and 100040075056 is FIXNUM, 0 in NIL, and 10000075061 is SYMBOL (I don't know which string package I have, it doesn't matter). Would somebody mind removing all the extra code that is necessary to produce such bizzare results and just make it simple and general and CORRECT !!!!! Separate bug -- on TWENEX, as far as I can tell eoffn does not work for files opened for (in fixnum single). When eof is reached, it complains that eof is reached and does not check for an eoffn.  Date: Friday, 12 June 1981, 21:58-EDT From: Robert W. Kerns Subject: array garbage collection. To: GJC at MIT-MC Cc: BUG-LISP at MIT-MC In-reply-to: The message of 12 Jun 81 00:25-EDT from George J. Carrette Date: 12 June 1981 00:25-EDT From: George J. Carrette Subject: array garbage collection. To: BUG-LISP at MIT-MC cc: GJC at MIT-MC I have a HUNK which points to an array containing hunks, and theses hunks point back to the top hunk, and also to arrays which contain hunks that point back to the top hunk. => I swear I can show that arrays are not getting garbage collected properly <= Storage is not getting reclaimed, and I run out very fast this way on a pdp-10. I almost think I'm crazy reporting that the maclisp garbage collector doesn't work. Please tell me it isn't so. -gjc I believe you. It can require multiple GCs to reclaim arrays linked cirularly. This is a known problem not easily fixed, and I have some mail stashed away from several years ago detailing the problem in depth. It would be interesting to know if the arrays NEVER get reclaimed, or just require several GCs to be reclaimed.  Date: Friday, 12 June 1981, 21:50-EDT From: Robert W. Kerns Subject: (status hsname 'foo 'a) To: kmp at MIT-MC Cc: BUG-LISP at MIT-MC In-reply-to: The message of 11 Jun 81 16:37-EDT from Kent M. Pitman Date: 11 June 1981 16:37-EDT From: Kent M. Pitman Sender: ELLEN0 at MIT-MC Subject: (status hsname 'foo 'a) To: BUG-LISP at MIT-MC This gives an ILOPR; when given an invalid site. It could be more forgiving. Only by catching the ILOPR itself. ILOPR is the only mechanism DDT has to indicate an error in a .BREAK 12,.  Date: 12 June 1981 21:33-EDT From: David Eppstein To: BUG-LISP at MIT-MC What is EVAL-ORDERED* and why does it have an autoload property of ((LISP) AUTOLOAD FASL), which upon not being found gives me an IO-LOSSAGE error when I try to load my file ((AR1 GUEST2) GENE >). As far as I can tell, it is in the middle of a DEFVST when it has that problem.  Date: 12 June 1981 20:05-EDT From: Edward Barton Subject: Files on Twenex To: BUG-LISP at MIT-AI Yes, files opened for read come out with restricted JFNs too. Also, the claim that files open for write always have restricted JFNs on Twenex seems to be false. At any rate I just got a file that did not previously exist open for read/write access with DDT, and it did not have a restricted JFN. Restricted JFNs com from setting the restricted JFN bit, not from some other source of magic.  Date: 12 June 1981 20:03-EDT From: Richard L. Bryan Subject: DEFVST lossage To: BUG-LISP at MIT-MC Date: 12 June 1981 1946-EDT From: Dave Touretzky at CMU-10A (defvst x (name /: symbol)) ...load some stuff... X (cons-a-x) ;FOO UNBOUND VARIABLE The restriction alist in the (SETQ INIFORM ...) part of the DEFVST macro has a pair (SYMBOL . FOO) which should be (SYMBOL . 'FOO). I wrote out a new source version MC:NILCOM;DEFVST 144 but didn't compile it since I don't understand all the circular interfile compilation dependencies.  Date: 12 June 1981 1946-EDT From: Dave Touretzky at CMU-10A To: bug-lisp at MIT-MC Subject: DEFVST lossage (defvst x (name /: symbol)) ...load some stuff... X (cons-a-x) ;FOO UNBOUND VARIABLE  JIS@MIT-AI 06/12/81 10:08:26 To: EB at MIT-AI CC: (BUG Lisp) at MIT-MC Ed, Was this a file that you opened for output. If so then the file doesn't truely exist until you close it, and until that time TWENEX treats the JFN as restricted, there is little that Maclisp can do about this... -Jeff  Date: 12 June 1981 08:49-EDT From: Edward Barton To: BUG-LISP at MIT-AI In LISP 2117 on XX, why on earth should MACLISP open a file with a "Restricted JFN" so you can't tell anything about it with @INFORMATION (ABOUT) FILES ??  Date: 12 June 1981 08:47-EDT From: Edward Barton To: BUG-LISP at MIT-AI In LISP 2117 on XX, there is no way to open a file with a null file type. For example, (open "foo..1" '(dsk out)) creates FOO.LSP.1 and (open "bar..1") gives FILE NOT FOUND if BAR.LSP.1 does not exist. This is a bug.  Date: 12 June 1981 00:25-EDT From: George J. Carrette Subject: array garbage collection. To: BUG-LISP at MIT-MC cc: GJC at MIT-MC I have a HUNK which points to an array containing hunks, and theses hunks point back to the top hunk, and also to arrays which contain hunks that point back to the top hunk. => I swear I can show that arrays are not getting garbage collected properly <= Storage is not getting reclaimed, and I run out very fast this way on a pdp-10. I almost think I'm crazy reporting that the maclisp garbage collector doesn't work. Please tell me it isn't so. -gjc  GSB@MIT-ML 06/11/81 23:09:37 Re: new format To: (BUG LISP) at MIT-ML i just installed format 749. This fixes the floating point operators which were dropping the sign, and the use of parameters to ~:; in ~  Date: 11 June 1981 16:37-EDT From: Kent M. Pitman Sender: ELLEN0 at MIT-MC Subject: (status hsname 'foo 'a) To: BUG-LISP at MIT-MC This gives an ILOPR; when given an invalid site. It could be more forgiving.  Date: 11 June 1981 08:22-EDT From: Robert W. Kerns Sender: RWK0 at MIT-MC Subject: More DEFVST lossage To: BUG-LISP at MIT-MC The print message for structures appears to cause structures to be printed twice, somehow. The DEFMETHOD doesn't appear guilty.  Date: 11 June 1981 02:10-EDT From: Robert W. Kerns To: BUG-LISP at MIT-MC The describe method for STRUCT-CLASS is bogus. (DESCRIBE (GET 'LOCAL 'FEATURE-SET)) says all the slot values are LOCAL.  Date: 10 June 1981 03:20-EDT From: Richard L. Bryan To: BUG-LISP at MIT-MC The SETF has a def-or-autoloadable for EVAL-ORDERED* to the file AUTOLOAD ????  Date: 9 June 1981 21:24-EDT From: George J. Carrette To: BUG-LISP at MIT-MC Screwed again. Ah Bullshit. Guess what (DEFUN FOO (&OPTIONAL (X X)) (FROB)) expands into? (DEFUN FOO |LexprVar..1| (LET (X) (DSETQ X (COND ((> |lexprVar..1| 0) (ARG 1)) (X)) (FROB))) This is WRONG. The correct code is (DEFUN FOO |LexprVar..1| (LET* ((X (COND ((> |lexprVar..1| 0) (ARG 1)) (X))) (FROB))) Where I have use LET* because thats what a sequence of &OPTIONAL's would want. -gjc  Date: 9 June 1981 11:15-EDT From: Jon L White Subject: WHEN-FEATURE To: RLB at MIT-MC cc: BUG-LISP at MIT-MC Date: 6 June 1981 05:04-EDT From: Richard L. Bryan At some time since 6/3/81 19:24, SHARPC was broken so that (WHEN-FEATURE ((LOCAL-FEATURES ITS) mumble))) no longer works. It had worked fine as of the above date. Broken by compilation, which depends on SHARPA. Apparently Kerns hasn't yet changed the documentation for SHARPC -- the names of feature sets are now LOCAL, MACLISP, NIL etc, rather than LOCAL-FEATURES, MACLISP-FEATURES, NIL-FEATURES etc. DAMN IT!! Is it so hard to test this stuff before barfing it out on the rest of the world??? Certainly, the format (WHEN-FEATURE ((LOCAL ITS) mumble))) does work and was tested in SHARPC. I may have mentioned to you the change in names, plus the synonyming/equivalencing feature for backward compatibility; the latter feature is the buggy one, which is in SHARPA. I've corrected it, and re-compiled SHARPC so that the backwards-compatibility thing works now.  Date: 9 June 1981 10:56-EDT From: Jon L White Subject: Initial LISP symbols for autoloadable packages To: GCJ at MIT-MC cc: KMP at MIT-MC, BUG-LISP at MIT-MC Date: 6 June 1981 21:40-EDT From: Kent M. Pitman Subject: DEFMACRO-FOR-COMPILING JONL says it's just soaking up free symbol space. It doesn't cost you anything. Seems pretty random, tho' ... I suppose when we need the symbol space for something else it will go away. Files which are autoloaded can't guanantee sharing of the symbols, but if some of these symbols are pre-existing from the initial lisp, then they can just utilise the otherwise dead space in pure areas. Doesn't cost anything for the user who doesn't need the autoloading file, and saves space for the onewho does. As KMP says, just which symbols "soak" up this sp[ace is a floating decision.  Date: 7 Jun 1981 0828-PDT Sender: SCOTT at SRI-AI From: MACLISP at SRI-AI To: GJC at MIT-MC, BUG-LISP at MIT-MC In-Reply-To: Your message of 6-Jun-81 1947-PDT Mail-from: ARPAnet host MIT-MC rcvd at 6-Jun-81 1950-PDT Date: 6 June 1981 22:47-EDT From: George J. Carrette To: BUG-LISP at MIT-MC Maclisp on EE is messed up. My init file gets ((LISP) PUREP FASL) file not found error, while loading MLMAC. this has been fixed now. -------  Date: 6 June 1981 22:47-EDT From: George J. Carrette To: BUG-LISP at MIT-MC Maclisp on EE is messed up. My init file gets ((LISP) PUREP FASL) file not found error, while loading MLMAC.  Date: 6 June 1981 21:40-EDT From: Kent M. Pitman Subject: DEFMACRO-FOR-COMPILING To: GJC at MIT-MC cc: BUG-LISP at MIT-MC JONL says it's just soaking up free symbol space. It doesn't cost you anything. Seems pretty random, tho' ... I suppose when we need the symbol space for something else it will go away.  Date: 6 June 1981 05:04-EDT From: Richard L. Bryan To: BUG-LISP at MIT-MC At some time since 6/3/81 19:24, SHARPC was broken so that (WHEN-FEATURE ((LOCAL-FEATURES ITS) mumble))) no longer works. It had worked fine as of the above date. The error message complains that a feature set is not the name of a feature set. DAMN IT!! Is it so hard to test this stuff before barfing it out on the rest of the world???  Date: 5 June 1981 17:02-EDT From: Jon L White To: macrak at USC-ECLB-IPI cc: BUG-LISP at MIT-MC Date: Friday, 5 June 1981 10:56-PDT From: MACRAKIS at USC-ECLB-IPI In the current lisp I filched from XX, Linel is initialized to 106, but (linel t) is initialized to 1, which confuses the poor grinder... At XX, (linel t) returns 79., not 1; could there be somethig wrong with the JSYS at ECL which returns the console parameters?  Date: Friday, 5 June 1981 10:56-PDT From: MACRAKIS at USC-ECLB-IPI To: Bug-lisp at MC Subject: Linel T In the current lisp I filched from XX, Linel is initialized to 106, but (linel t) is initialized to 1, which confuses the poor grinder...  Date: 5 June 1981 13:44-EDT From: George J. Carrette To: KMP at MIT-MC cc: BUG-LISP at MIT-MC Date: 5 June 1981 00:14-EDT From: Kent M. Pitman To: GJC cc: BUG-LISP Date: 4 June 1981 21:59-EDT From: George J. Carrette Why is DEFMACRO-FOR-COMPILING in the bare lisp environment and bound to T? ----- The Lisp Machine behaves in this way and for naive users, it would be best if macros did not disappear at compile time. DEFMACRO-FOR-COMPILING=NIL is a sophisticated setting and should not be the default. -kmp Sorry, the question is really "why isn't this variable autoloading along with DEFMACRO? It would seem that unless one has done a defmacro nothing in the environment needs this switch" For example, the variable MACROS, which has been in maclisp for some time now, is unbound in a bare lisp.  Date: Friday, 5 June 1981 08:39-PDT From: MACRAKIS at USC-ECLB-IPI To: Scott at sri-ai, bug-lisp at mc Subject: ^Z reentry This is absolutely consistent for me under the stated circumstances. --Stavros  Date: 5 June 1981 01:10-EDT From: Jon L White Subject: (SETF (FIXNUM-IDENTITY ...) ...) To: ALAN at MIT-MC cc: GZ at MIT-MC, BUG-LISP at MIT-MC So finally I've gone in and fixed this cretinous loser! Date: 12 May 1981 13:40-EDT From: Alan Bawden Date: 12 May 1981 05:44-EDT From: Gail Zacharias (SETF (FIXNUM-IDENTITY (CAR SOME-LIST)) 17.) wants that SOME-LIST should be a fixnum... . . . While you people are fixing this, could you make it expand into: (fixnum-identity (progn (rplaca some-list (fixnum-identity 17.)) 17.)) or some other variation that does a fixnum-identity BEFORE performing the side-effect? This would be a useful error check to have in the interpreter. (SETF (FIXNUM-IDENTITY foo) bar) ==> (FIXNUM-IDENTITY (SETF foo (FIXNUM-IDENTITY bar))) So ALAN get's his interpretive error checking, and GZ's bug is fixed.  Date: 5 June 1981 00:14-EDT From: Kent M. Pitman To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 4 June 1981 21:59-EDT From: George J. Carrette Why is DEFMACRO-FOR-COMPILING in the bare lisp environment and bound to T? ----- The Lisp Machine behaves in this way and for naive users, it would be best if macros did not disappear at compile time. DEFMACRO-FOR-COMPILING=NIL is a sophisticated setting and should not be the default. -kmp  Date: 5 June 1981 00:02-EDT From: Jon L White Subject: LEDIT on EECS To: GJS at MIT-MC, ALAN at MIT-MC, scott at SRI-AI cc: BUG-MACLISP at MIT-MC The reason why LEDIT caused PDL overflow was a .FASL file which was not fully compatible for use in "ancient" LISPs -- I've updated the file (MLMAC 83) and copied it to EE, so now things work smoothly again.  Date: 4 June 1981 21:59-EDT From: George J. Carrette Sender: RLB at MIT-MC To: BUG-LISP at MIT-MC Why is DEFMACRO-FOR-COMPILING in the bare lisp environment and bound to T?  Date: 4 Jun 1981 1247-PDT Sender: SCOTT at SRI-AI From: MACLISP at SRI-AI Subject: Re: LEDIT on EE To: JONL at MIT-MC, ALAN at MIT-MC, GJS at MIT-MC cc: BUG-MACLISP at MIT-MC, scott at SRI-AI In-Reply-To: Your message of 4-Jun-81 1206-PDT re: DEFVSY... probably caught me in the middle of installing that this morning. Run XMACLISP to avoid the FIXPDL overflow. I'll have the other files installed soon. -sjk -------  Date: 4 Jun 1981 1243-PDT Sender: SCOTT at SRI-AI From: MACLISP at SRI-AI Subject: Re: ^Z reentry To: MACRAKIS at USC-ECLB-IPI, Bug-Lisp at MIT-MC In-Reply-To: Your message of 3-Jun-81 1621-PDT Mail-from: ARPAnet host MIT-MC rcvd at 3-Jun-81 1621-PDT Date: Wednesday, 3 June 1981 16:10-PDT From: MACRAKIS at USC-ECLB-IPI To: Bug-Lisp at MC CC: Macrakis at USC-ECLB-IPI Subject: ^Z reentry Jonl-- I am running Lisp 2114 from XX on T-20 at ECLB. (foo bar ^Z @cont (foo bar)) gives "732142 not ascii value". Same thing happens on XX, with a different number. I've also had this problem but it occurs very randomly. -------  Date: 4 June 1981 15:06-EDT From: Jon L White Subject: LEDIT on EE To: ALAN at MIT-MC, GJS at MIT-MC cc: BUG-MACLISP at MIT-MC, scott at SRI-AI Date: 4 June 1981 14:39-EDT From: Alan Bawden Date: 4 June 1981 01:33-EDT From: Gerald Jay Sussman on eecs, (ledit) fails because the file DEFVSY , which should be on (PS MACLISP) is not there. That's funny, it fails for me due to an unrecoverable fixpdl everflow. (Someone seems to have moved DEFVSY over however.) It works fine in the current LISP (version 1117) which is called XLISP on EE until after the end of the term. If no one objects now, maybe SCOTT could continue the move of current software from XX to EE. KMP had wanted to wait until after the end of the term to update EE so that the students using ULISP didn't have to take notice of any changes.  Date: 4 June 1981 14:39-EDT From: Alan Bawden To: BUG-MACLISP at MIT-MC cc: GJS at MIT-MC Date: 4 June 1981 01:33-EDT From: Gerald Jay Sussman on eecs, (ledit) fails because the file DEFVSY , which should be on (PS MACLISP) is not there. That's funny, it fails for me due to an unrecoverable fixpdl everflow. (Someone seems to have moved DEFVSY over however.)  Date: 4 June 1981 01:33-EDT From: Gerald Jay Sussman To: BUG-MACLISP at MIT-MC on eecs, (ledit) fails because the file DEFVSY , which should be on (PS MACLISP) is not there.  Date: Wednesday, 3 June 1981 16:10-PDT From: MACRAKIS at USC-ECLB-IPI To: Bug-Lisp at MC CC: Macrakis at USC-ECLB-IPI Subject: ^Z reentry Jonl-- I am running Lisp 2114 from XX on T-20 at ECLB. (foo bar ^Z @cont (foo bar)) gives "732142 not ascii value". Same thing happens on XX, with a different number.  Date: 3 June 1981 03:47-EDT From: Robert W. Kerns To: BUG-LISP at MIT-MC Why have DEFVST-structs been broken to be circlar in the absence of EXTEND?  Date: 3 June 1981 02:51-EDT From: John C. Gilmore To: BUG-LISP at MIT-AI I'm just a dumb user re lisp system facilities, so when I wanted to run the Boston Globe ad I typed :lisp mc:humor;lisp ad to DDT. It responded with a pause and then the message "GC CALLED FROM ALLOC - LOSE, LISP IS DEAD" and ".VAL 0; 126020>>HRLI 1,440700". Have fun. - John Gilmore  GSB@MIT-ML 06/02/81 21:21:47 Re: new format To: (BUG LISP) at MIT-ML (format nil "foo~^bar") now returns "foo", not NIL or |foo|.  Date: 2 June 1981 13:38-EDT From: George J. Carrette To: BUG-LISP at MIT-MC Oops, the problem with MCOMPI an the LOCK MAIL file was due to a call to MAIL within MCLDMP (INIT) itself in addition to the mail call in PURE-SUSPEND.  Date: 1 June 1981 16:03-EDT From: Jon L White Subject: CHEKC-TYPE To: KMP at MIT-MC cc: BUG-LISP at MIT-MC Date: 25 May 1981 00:05-EDT From: Kent M. Pitman Is there any reason CHECK-TYPE can't do something with SETF instead of SETQ? GJC says his generic PUSH/POP definer can make this win. Yea, this could be hacked -- basically just a usage of EVONCE would make it win too. By the bye, I'm cc'ing this to bug-lisp, since the ERRCK facility is usable on just about all LISP's -- not just MacLISP.  JONL@MIT-MC 06/01/81 15:10:04 Re: TTYCONS for SFAs To: KMP at MIT-MC CC: (BUG BUG-MACLISP) at MIT-MC Date: 27 May 1981 10:46-EDT From: Kent M. Pitman I don't think that (SSTATUS TTYCONS ...) should care if it gets a tty input file object at all. Even so, it certainly shouldn't care about SFA's, especially if the SFA's claim to be TTY type sfa's -- ie, (MEMQ 'TTY (STATUS FILEM sfa)) => non-(). Can this please be fixed to handle at least the SFA case? Thanks. It already does accept the SFA case -- It doesn't even check for (STATUS FILEM sfa) having any interesting properties. The hac now is that there is another 'symbolic' slot in all SFA's (no more space needed, just using an unused slot); this slot is named "XCONS", and holds the bi- directional correspondent, if any, for the given sfa. Incidentally, the other 'symbolic' slots are FUNCTION, WHICH-OPERATIONS, PNAME, and PLIST and all of this is documented in .INFO.;LISP SFA.  JONL@MIT-MC 06/01/81 15:08:54 Re: A Miscellany of YESNOP bugs, fixed in version 41. To: KMP at MIT-MC CC: (BUG BUG-MACLISP) at MIT-MC Date: 27 May 1981 11:28-EDT From: Kent M. Pitman I don't see why (Y-OR-N-P ...) must have a bidirectional stream. . . . I've just fixed this, at least for the MacLISP case -- it will ask for the TTYCONS of its stream, and this works ok for sfa's too. Possibly some such kludge can be retro-fit to the LISPM, and there should be some reasomable way to do this for NIL too. Date: 27 May 1981 11:37-EDT From: Kent M. Pitman Subject: Y-OR-N-P doesn't errcheck well... (Y-OR-N-P TYI) seems to hang forever. ^Z'ing it and looking at the pc says that it is XCT'ing a .IOT B,TT. (Where B is open in .uai mode -- i guess that means it is TYI). Could it be that it is .IOT'ing thinking it is printing when in fact it is reading instead?? Note that (Y-OR-N-P TYI)YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY will return T on the 52nd Y. Similarly, . . . As indicated, this is fixed by letting Y-OR-N-P ask about the TTYCONS. KMP@MIT-MC 05/27/81 11:44:21 Re: More Y-OR-N-P (Y-OR-N-P NIL) seems to do (FORMAT NIL "") and then prompt with (Y or N). Note that FORMAT'ing to NIL returns a string while PRINT'ing to NIL prints on the default output devices! . . . So the MacLISP version of Y-OR-N-P should just use ?FORMAT instead of FORMAT. I've fixed this too.  Date: 1 June 1981 12:25-EDT From: Richard C. Garner To: BUG-LISP at MIT-MC I don't know if this is a bug, but when you DUMPARRAYS an array of more than one dimension and then LOADARRAYS it, the array becomes one dimensional with all the elements on top of each other. --Defbob  Date: 31 May 1981 15:14-EDT From: Jon L White To: gsb at MIT-ML cc: BUG-LISP at MIT-MC GSB@MIT-ML 04/17/81 02:27:50 (lap a b) ... does (args 'a nil) Should check B being SUBR, LSUBR, FSUBR Fixed. New lap is version 110.  Date: 31 May 1981 14:41-EDT From: Glenn S. Burke To: BUG-LISP at MIT-MC GSB@MIT-ML 04/29/81 20:07:46 Re: tty prescan loses badly the new hack for calling the tty prescan initially also causes it to get called again, after it has returned, for subparts of the expression being read via recursive READs. You can follow this easily enough by putting a breakpoint at $DEVPS and typing something like #'FOO . This is not noticible with the dumb prescan but it breaks brand-x totally. p.s. it is not sufficient to additionally make sure the right half of BFPRDP is 0 before calling the prescan function when there are already buffered back characters. p.p.s. The "cain r,qttybuf" test is bogus, since R hasn't been restored yet. I am incapable of bringing up brand-x in the current lisp without redefining READ, *READ, and +INCLUDE-EOFFN, and having a hook on the value of READ. I.e., to make things work i have to totally bypass anyplace which would call the (status ttyscan), and to do that i must get my paws into the stuff which fucks with infile and instack. This is disgusting, to put it mildly.  Date: 31 May 1981 14:37-EDT From: Glenn S. Burke To: BUG-LISP at MIT-MC GSB@MIT-ML 04/17/81 02:27:50 (lap a b) ... does (args 'a nil) Should check B being SUBR, LSUBR, FSUBR  Date: 31 May 1981 13:26-EDT From: Gail Zacharias Subject: (cursorpos 'n) To: BUG-LISP at MIT-MC (progn (cursorpos 'n) (princ "foo") (tyi tyi))x prints foo and returns 120.(#/x), as expected, but (progn (cursorpos 'n) (tyi tyi))x just hangs there waiting for another character. When the second character is typed, it will be processed by lisp, after 120. is returned.  Date: 30 May 1981 17:07-EDT From: Alan Bawden Subject: everyone likes a gross hack now and then! To: BUG-LISP at MIT-MC If we are going to have (eq (plist "foo") (plist "bar")), then why not make stringp be a check to see if the plist of the symbol is eq to the cannonical one? If *string-plist* is bound to (+INTERNAL-STRING-MARKER T), then (stringp x) can macroexpand into (eq (cdr x) *string-plist*), which should compile just about optimally. (Of course if you want strings to have property lists, then this won't work.)  Date: 30 May 1981 16:46-EDT From: KMP,JAR at MIT-MC Sender: JAR at MIT-MC To: BUG-LISP at MIT-MC Why is it that (EQ (PLIST "foo") (PLIST "bar")) isn't T (with pseudo-strings). Seems like it would save a bit of space at no real cost to anyone if they shared the same pure plist.  Date: 27 May 1981 12:17-EDT From: George J. Carrette Subject: arguments to READ, TYI, and PRINT, TYO To: BUG-LISP at MIT-MC It would be very nice to have a defined primitive that took a list of "READ-compatible" arguments, and returned a list ( ). I could use this in both Macsyma and Cgol, instead of defining my own primitive. (I really hate to have to use FILEP, SFAP, and check the value of ^Q.) The lispm has an SI:DECODE-READ-ARGS, that nicely insulates one from the particularly ugly way of checking STREAM-P'ness used. Maybe all this is moot. What I *really* want is to be able to take my function (DEFUN MY-READ-BARE (STREAM EOF-TOKEN) ...) and do (SETF #'MY-READ (CREATE-A-READER #'MY-READ-BAR)). [Perhaps a special form (DEFREADER MY-READ MY-READER-BARE)] So that I'm insulated from whatever hacks are used on a particular system for doing stream-defaulting, rubout-processing, or whatever.  KMP@MIT-MC 05/27/81 11:44:21 Re: More Y-OR-N-P To: (BUG BUG-MACLISP) at MIT-MC (Y-OR-N-P NIL) seems to do (FORMAT NIL "") and then prompt with (Y or N). I think that there should be some consistency in the argument convention here. Note that FORMAT'ing to NIL returns a string while PRINT'ing to NIL prints on the default output devices! This is why the (Y or N) comes out. Perhaps Y-OR-N-P should either not recognize NIL as a file, or if it does it should expand it according to ^Q and such -- I think something like (SETQ FILEOBJ (OR FILEOBJ (IF ^Q INFILE TYI))) would probably do the trick. Then at least you'd have a uniform argument treatment. I suspect YES-OR-NO-P loses similarly, tho' I haven't checked.  Date: 27 May 1981 11:37-EDT From: Kent M. Pitman Subject: Y-OR-N-P doesn't errcheck well... To: BUG-MACLISP at MIT-MC (Y-OR-N-P TYI) seems to hang forever. ^Z'ing it and looking at the pc says that it is XCT'ing a .IOT B,TT. (Where B is open in .uai mode -- i guess that means it is TYI). Could it be that it is .IOT'ing thinking it is printing when in fact it is reading instead?? Note that (Y-OR-N-P TYI)YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY will return T on the 52nd Y. Similarly, (Y-OR-N-P TYI)NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN returns NIL on the 52nd N. And oddly, (Y-OR-N-P TYI)AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAN does not return at the 5nd char. Anyway, this bug would go away if Y-OR-N-P were a bit smarter about these file objects it takes as I suggested in my previous note.  Date: 27 May 1981 11:28-EDT From: Kent M. Pitman To: BUG-MACLISP at MIT-MC I don't see why (Y-OR-N-P ...) must have a bidirectional stream. Why can't you have it pick the ttycons of the given file object to do the operations which would otherwise be the wrong direction. i.e., I think that (Y-OR-N-P TYI) and (Y-OR-N-P TYO) are perfectly well-defined. I hate using T as a file object and I think having to define an SFA that just pretends to be TYI/TYO (yes, I know there are some already written but it's still a silly overhead) is unreasonable.  Date: 27 May 1981 10:46-EDT From: Kent M. Pitman To: BUG-MACLISP at MIT-MC I don't think that (SSTATUS TTYCONS ...) should care if it gets a tty input file object at all. Even so, it certainly shouldn't care about SFA's, especially if the SFA's claim to be TTY type sfa's -- ie, (MEMQ 'TTY (STATUS FILEM sfa)) => non-(). Can this please be fixed to handle at least the SFA case? Thanks.  Date: 25 May 1981 00:05-EDT From: Kent M. Pitman To: BUG-MACLISP at MIT-MC Is there any reason CHECK-TYPE can't do something with SETF instead of SETQ? GJC says his generic PUSH/POP definer can make this win.  Date: 24 May 1981 21:12-EDT From: Robert W. Kerns Subject: macroexpand To: GZ at MIT-MC cc: BUG-LISP at MIT-MC Date: 24 May 1981 02:41-EDT From: Gail Zacharias Subject: macroexpand To: BUG-LISP at MIT-MC (MACROEXPAND '((A B) C)) ==> (A B) Now gives ((A B) C), as it ought.  Date: 24 May 1981 04:31-EDT From: BIL,KMP at MIT-MC Sender: KMP at MIT-MC Subject: Another tty prescan oddity... To: BUG-MACLISP at MIT-MC cc: BIL at MIT-MC '(''))))))) 3 ;READ-MACRO CONTEXT ERROR The tty prescan must be pretty confused to let this get so far before complaining.  Date: 24 May 1981 02:41-EDT From: Gail Zacharias Subject: macroexpand To: BUG-LISP at MIT-MC (MACROEXPAND '((A B) C)) ==> (A B)  Date: 23 May 1981 18:59-EDT From: Robert W. Kerns Subject: CNAMEF/OPEN interaction To: EB at MIT-MC, BUG-LISP at MIT-MC Ah, it only happens when you give a second argument to OPEN, and the OPEN fails. If you substitute (OPEN F) for (OPEN F '(DSK IN FIXNUM)) in your example, it behaves properly.  EB@MIT-ML 05/23/81 18:25:14 Re: unreproducible CNAMEF/OPEN interaction To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC I append the following transcript from XXFILE: :lisp LISP 2100 Alloc? n * (setq f (open "nul:")) #FILE-IN-|NUL:* *|-70776 (close f) T (cnamef f "dsk:luser;foo bar") #FILE-IN-|DSK:LUSER;FOO BAR|-70776 f #FILE-IN-|DSK:LUSER;FOO BAR|-70776 (open f '(dsk in fixnum)) ;(OPEN #FILE-IN-|* *|-70776 (DSK IN FIXNUM)) NON-EXISTENT DIRECTORY ;BKPT IO-LOSSAGE f #FILE-IN-|* *|-70776 (cnamef f "dsk:luser;foo bar") #FILE-IN-|DSK:LUSER;FOO BAR|-70776 f #FILE-IN-|DSK:LUSER;FOO BAR|-70776 (open f '(dsk in ascii)) ;(OPEN #FILE-IN-|* *|-70776 (DSK IN ASCII)) NON-EXISTENT DIRECTORY f #FILE-IN-|* *|-70776 (quit) :KILL  Date: 23 May 1981 17:26-EDT From: Robert W. Kerns To: EB at MIT-AI cc: BUG-LISP at MIT-AI Date: 21 May 1981 19:32-EDT From: Edward Barton To: BUG-LISP at MIT-AI If you CNAMEF a file object to the name of a nonexistent file and then do an OPEN on the file object, the stored filenames of the file object are changed to * *. Why? It makes it hard to figure out what file was not found if you don't already know. I cannot reproduce this.  Date: 23 May 1981 06:04-EDT From: Kent M. Pitman Subject: Arg checking for *ARRAY To: BUG-MACLISP at MIT-MC (*ARRAY NIL 'READTABLE 500) ;500 ATOMIC SYMBOL REQUIRED (*ARRAY NIL 'READTABLE 'AN-ATOMIC-SYMBOL) ;AN-ATOMIC-SYMBOL NOT AN ARRAY (SETQ OK-LETS-TRY-AN-ARRAY (*ARRAY NIL T 100)) (*ARRAY NIL 'READTABLE OK-LETS-TRY-AN-ARRAY) ;#T-100-70754 NOT READTABLE - *ARRAY The first error message seems way offbase. Probably the second is, also. Is a readtable the only allowable third arg? If so, would it be hard for all of these forms to give the same error message (the NOT READTABLE ... message)?  Date: 23 May 1981 04:15-EDT From: Kent M. Pitman To: BUG-MACLISP at MIT-MC (FILLARRAY 'FOO NIL) ;NIL WRONG TYPE ARRAY - FILLARRAY (FILLARRAY 'FOO '(NIL)) ;FOO NOT AN ARRAY I prefer the second error message.  Date: 21 May 1981 19:32-EDT From: Edward Barton To: BUG-LISP at MIT-AI If you CNAMEF a file object to the name of a nonexistent file and then do an OPEN on the file object, the stored filenames of the file object are changed to * *. Why? It makes it hard to figure out what file was not found if you don't already know.  Date: 21 May 1981 07:30-EDT From: Jon L White Subject: Clobbered error msg To: DICK at MIT-ML cc: RLB at MIT-MC, BUG-LISP at MIT-MC DICK@MIT-ML 05/20/81 17:18:05 I would like to enter the following in the random bug of the week contest. If you type: (close 'a) Youmain get: ;A G 3ZB""01I,R*03Z2"FC04( 66 ;BKPT WRNG-TYPE-ARG Patched in current LISP^K, and corrected in sources. (By the bye, I just searched the ERROR file for other occurences of the word "ASCII" and didn't find any more inadvertent flip-flops of error msg types).  Date: 21 May 1981 02:13-EDT From: Alias for KMP Subject: more on yesterday's TYIPEEK lossage To: BUG-MACLISP at MIT-MC INCST3: TLNE T,SO.TIP ;FOO! TYIPEEK IS DIFFERENT! TDZA C,C ; BUT IF NOT TYIPEEK THEN USE MOVEI C,INCST3 ; NEW EOF VALUE, SOMETHING UNIQUE PUSHJ P,ISTCAL ;CALL THE SFA POP P,C ;RESTORE EOF VALUE CAIN A,INCST3 ;DID THE SFA RETURN EOF? JRST INCST4 ;YES, HANDLE IT JSP T,FXNV1 ;ELSE THE VALUE RETURNED MUST BE A FIXNUM POPJ P, ----- Note how SFA's get sent a NIL but on return check for INCST3 ...? How is the guy going to know to return that? I just did (SETQ STREAM (SFA-CREATE #'(LAMBDA (SELF OP DATA) (CASEQ OP ((WHICH-OPERATIONS) '(TYIPEEK)) ((TYIPEEK) '#,(MUNKAM (GETDDTSYM 'INCST3))) (T (ERROR "Loss" OP)))) 0. "Loss")) (TYIPEEK NIL STREAM) => -1. (TYIPEEK NIL STREAM -3) => -3. which is the kind of behavior that I want... Somehow this need for #,(MUNKAM ...) seems awkward, though.  RLB@MIT-MC 05/20/81 17:19:08 To: (BUG LISP) at MIT-ML DICK@MIT-ML 05/20/81 17:18:05 I would like to enter the following in the random bug of the week contest. If you type: (close 'a) Youmain get: ;A G 3ZB""01I,R*03Z2"FC04( 66 ;BKPT WRNG-TYPE-ARG I would say that some error message got clobbered. Dick Waters NAFOS contains ascii, not sixbit, as expected.  DICK@MIT-ML 05/20/81 17:18:05 To: (BUG LISP) at MIT-ML I would like to enter the following in the random bug of the week contest. If you type: (close 'a) Youmain get: ;A G 3ZB""01I,R*03Z2"FC04( 66 ;BKPT WRNG-TYPE-ARG I would say that some error message got clobbered. Dick Waters  Date: 20 May 1981 04:23-EDT From: Kent M. Pitman Subject: TYIPEEK / SFA interaction changed?? To: BUG-MACLISP at MIT-MC It used to be that the following definition (DEFUN SFA-HANDLER (SELF OP DATA) (CASEQ OP ((WHICH-OPERATIONS) '(TYIPEEK)) ((TYIPEEK) DATA) (T (ERROR "I am too dumb to do that" OP)))) (SETQ STREAM (SFA-CREATE #'SFA-HANDLER 0. "Dumb Stream")) would allow you to do (TYIPEEK NIL STREAM) => -1 (TYIPEEK NIL STREAM -1) => -1 (TYIPEEK NIL STREAM -3) => -3 even tho (TYIPEEK NIL (OPEN 'NUL: 'IN) -1) => -1 (TYIPEEK NIL (OPEN 'NUL: 'IN) -3) => -1 ; this was a bug then and still is now Anyway, now you get the following behavior instead: (TYIPEEK NIL STREAM) => ;NIL NON-FIXNUM VALUE (TYIPEEK NIL STREAM -1) => ;NIL NON-FIXNUM VALUE In an EOF case, the TYIPEEK message to an SFA must be able to return its DATA argument. DATA used to get bound to #nnnnnn and somehow if you returned this, it magically figured out you wanted the eof value returned to the user. Now I would prefer that DATA be bound to the value supplied (default -1 if none supplied), but that's just preference. The important thing tho' is that I have code that is broken until someone fixes the TYIPEEK message to pass some piece of data which if returned will give the right value back from TYIPEEK without erring... Naturally, while you're at it you could fix that other bug wherein only -1 can be returned from an EOF on a real file object when TYIPEEK'ing, even if some other arg is supplied (see the -3 case above). -kmp  Date: 18 May 1981 21:26-EDT From: Jon L White Subject: CERROR To: FEINBERG at CMU-20C cc: BUG-LISP at MIT-MC Date: 17 May 1981 2258-EDT From: Chiron of Thessaly When using the FERROR function here from the Cerror package, function explodes way down in the SFA handler because CHARPOS is undefined. I belive I made the right fix, . . . [in] RAF;CERROR 44 at MIT-MC . . . Indeed, the handler function for the ERROR-OUTPUT sfa should have a CHARPOS message. But the meaning of the third argument, when the message-key is CHARPOS or LINEL, is either () or a list of a value to which the corresponding attribute should be set. I've fixed this up accordingly, and fixed a similar problem with the CURSORPOS handling code, and installed here as CURSORPOS 46 -- source is on the LSPSRC directory. Note that a new QUERIO files will be necessary too, since the new CERROR may use a function with will autoload from QUERIO now.  Date: 15 May 1981 22:44-EDT From: George J. Carrette To: BUG-LISP at MIT-MC Is there any reason why GCTWA needs to be an FSUBR?  Date: 15 May 1981 04:00-EDT From: Kent M. Pitman Subject: Maclisp/LispM &OPTIONAL incompatibility To: BUG-MACLISP at MIT-MC (DEFUN LOSSAGE (&OPTIONAL (X X)) X) => (SETQ X 'X-GLOBAL-VALUE) (LOSSAGE 'PARAMETER-GIVEN) => PARAMETER-GIVEN (LOSSAGE) => NIL ;Should give X-GLOBAL-VALUE I hope this is a bug and not a deliberate design decision. The LispM returns the `right' value, X-GLOBAL-VALUE, for the last evaluation shown.  Date: 12 May 1981 18:10-EDT From: Jon L White Subject: Rubout/Echo lossage To: GJC at MIT-MC cc: KMP at MIT-MC, BUG-LISP at MIT-MC Date: 12 May 1981 10:20-EDT From: Jon L White Subject: Alleged Rubout/Echo lossage Date: 12 May 1981 01:35-EDT From: George J. Carrette Rubout processing and echoing is sometimes wedged. The following is quite reproducable: :GJC;B (load '((blis11)wordc)) (wordc-rep^L Right where I have indicated a ^L, you can type without getting any re-display or rubout-processing. Things seem to get wedged quite often on the next form after a toplevel call to LOAD. I typed exactly the same and observed no lossage whatsoever. Evidently, whatever you saw isn't so easily reproducible. What was missing was that you had, upon ocasion, typed one extra right paresn -- not that in your mail to me you had the correct number typed in. Thus the lossage is observable (as KMP's eagle eyes spotted) when you type the extra right parens. Happily, I believe I've fixed the problem, and patched it in the currrent LISP dump.  Date: 12 May 1981 13:40-EDT From: Alan Bawden Subject: setf bug To: BUG-LISP at MIT-MC cc: GZ at MIT-MC Date: 12 May 1981 05:44-EDT From: Gail Zacharias (SETF (FIXNUM-IDENTITY (CAR SOME-LIST)) 17.) wants that SOME-LIST should be a fixnum... This is becase it expands into: (progn (fixnum-identity (rplaca some-list 17.)) 17.) While you people are fixing this, could you make it expand into: (fixnum-identity (progn (rplaca some-list (fixnum-identity 17.)) 17.)) or some other variation that does a fixnum-identity BEFORE performing the side-effect? This would be a useful error check to have in the interpreter.  Date: 12 May 1981 10:20-EDT From: Jon L White Subject: Alleged Rubout/Echo lossage To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 12 May 1981 01:35-EDT From: George J. Carrette Rubout processing and echoing is sometimes wedged. The following is quite reproducable: :GJC;B (load '((blis11)wordc)) (wordc-rep^L Right where I have indicated a ^L, you can type without getting any re-display or rubout-processing. Things seem to get wedged quite often on the next form after a toplevel call to LOAD. I typed exactly the same and observed no lossage whatsoever. Evidently, whatever you saw isn't so easily reproducible.  Date: 12 May 1981 05:44-EDT From: Gail Zacharias Subject: setf bug To: BUG-LISP at MIT-MC (SETF (FIXNUM-IDENTITY (CAR SOME-LIST)) 17.) wants that SOME-LIST should be a fixnum...  Date: 12 May 1981 01:35-EDT From: George J. Carrette To: BUG-LISP at MIT-MC cc: GJC at MIT-MC Rubout processing and echoing is sometimes wedged. I've noticed this quite often in the new lisp, even seeing JONL control-G the read-eval-print loop when a control-L should have been enough. The following is quite reproducable: :GJC;B (load '((blis11)wordc)) (wordc-rep^L Right where I have indicated a ^L, you can type without getting any re-display or rubout-processing. Things seem to get wedged quite often on the next form after a toplevel call to LOAD. -gjc  Date: 9 May 1981 16:55-EDT From: Jon L White Subject: '(#B10 10) To: WGD at MIT-MC, KMP at MIT-MC, RLB at MIT-MC cc: BUG-LISP at MIT-MC Date: 7 APR 1981 0515-EST From: WGD at MIT-MC (William G. Dubuque) In MACLISP 2077 with SHARPM 72 and BASE = IBASE = 10, *NOPOINT = () '(#o10 10) ==> (8. 8.) ! -------- Date: 7 APR 1981 1409-EST From: kmp at MIT-MC (Kent M. Pitman) Subject: more on base '(10 #8r10 10) => (10. 8. 8.) '(10 #2r10 10) => (10. 2. 2.) '(10 #o10 #.(print (list 'ibase= ibase 'base= base)) 10) (IBASE= 10. BASE= 10.) => (10. 8. T 10.) Maybe something about #. is re-initializing things... Ha, TYIPEEK is the villain! It clobbers the variable used to hold both a "reason" why TYI is called and the "re-entrancy level" of a call to read -- BFPRDP. Aparently whoever put this variable into the reader is not the same person who used it in TYIPEEK. Anyway, TYI and other functions interact with it correctly, so I've edited the source to have TYIPEEK save-and-restore this variable, just like the others. At first RLB and I thought it was merely the fact that the reader was "cache"ing the error-checked value of IBASE upon main entry, so I patched a lot of save-and-restore around reader macro calls into the current LISP dump. But upon closer inspection, I discovered that BFPRDP had the wrong value when the SHARPM function for radix reads was calling READ (re-entrantly, of course). Here is an example which shows TYIPEEK to be the villain: ;;Run this in OLISP^K to see the effect of the bug. (defun RR () (let ((IBASE (caseq (tyi) ((#/X #/x) 16.) ((#/O #/o) 8) ((#/B #/b) 2) (T (tyipeek) (* 2 IBASE) )))) (read))) (setsyntax '/! 'macro 'RR) (setq BASE (setq IBASE 10.)) '(!O10 10) '(!X10 10) '(!D10 10) '(!B10 10)  Date: 8 May 1981 06:19-EDT From: Alan Bawden To: BUG-LISP at MIT-MC (CASEQ) should be detected as a "WRONG FORMAT" fexpr.  gsb@MIT-ML (Sent by WJL@MIT-ML) 05/05/81 10:14:52 To: (BUG LISP) at MIT-ML the "fix" in TYOFLF isn't fully fixed because the TYOFLF case doesn't want to heed that TLNN check at TYOFFF+2. i.e. only the formfeed wants to punt endpagefn if its a tty, not the linefeed case.  Date: 5 May 1981 01:07-EDT From: Robert W. Kerns Subject: STRING oddity To: JONL at MIT-MC cc: KMP at MIT-MC, BUG-LISP at MIT-MC, VP at MIT-MC Date: 4 May 1981 11:15-EDT From: Jon L White Subject: STRING oddity To: KMP at MIT-MC cc: BUG-LISP at MIT-MC, VP at MIT-MC Date: 4 May 1981 00:59-EDT From: Kent M. Pitman (ARGS 'FLATSIZE->CHARACTER-CLASS) => (5 . 5) Why not just (NIL . 5)? Because the SEND interpreter like to assume LSUBR format -- it does make for faster dispatching. DEFMETHOD* creates method functions and puts in the *LEXPR declaration. Correction: The SEND interpreter *MUST* assume LSUBR format, or assume it is not compiled, because LSUBR and SUBR pointers cannot be distinguished! The declaration is **LEXPR, not *LEXPR.  Date: 4 May 1981 13:50-EDT From: George J. Carrette To: BUG-LISP at MIT-MC cc: BUG-MACSYMA at MIT-MC The LPH bug with PLOT2 is probably a LISP BUG in +TYO not sending full bucky bits to PLASMA CHAOS.  Date: 4 May 1981 11:15-EDT From: Jon L White Subject: STRING oddity To: KMP at MIT-MC cc: BUG-LISP at MIT-MC, VP at MIT-MC Date: 4 May 1981 00:59-EDT From: Kent M. Pitman (ARGS 'FLATSIZE->CHARACTER-CLASS) => (5 . 5) Why not just (NIL . 5)? Because the SEND interpreter like to assume LSUBR format -- it does make for faster dispatching. DEFMETHOD* creates method functions and puts in the *LEXPR declaration.  Date: 4 May 1981 10:19-EDT From: Jon L White Subject: XTRSYMs To: GSB at MIT-ML cc: BUG-LISP at MIT-MC GSB@MIT-ML 05/02/81 08:33:30 To: (BUG LISP) at MIT-ML Can GCST be made into an XTRASYM? (If not i guess i just have to cheat and assume that it is (+ st (lsh 1 seglog))...) FWNACK would be nice also. I just put these two in the source, but you may remember we/ve recently had a new lisp installed, and may not reassemble for some months. Until then, calculating GCST as 1 segment beyond ST is ok.  Date: 4 May 1981 00:59-EDT From: Kent M. Pitman Subject: STRING oddity To: BUG-LISP at MIT-MC cc: VP at MIT-MC (ARGS 'FLATSIZE->CHARACTER-CLASS) => (5 . 5) Why not just (NIL . 5)?  GSB@MIT-ML 05/02/81 08:33:30 To: (BUG LISP) at MIT-ML Can GCST be made into an XTRASYM? (If not i guess i just have to cheat and assume that it is (+ st (lsh 1 seglog))...) FWNACK would be nice also.  GSB@MIT-ML 05/01/81 00:40:59 Re: upcoming format, fyi To: (BUG LISP) at MIT-ML I wrote out a new SHARPM, with the entries of /#-symbolic-characters-table reordered. Upcoming format will use this (if it is around) to do character name inversion. (In its absence, format knows about the format-effectors, so won't lose too badly.) I will install the new format on ML tonight; i'd like to leave it here only for a week or so, in case any unnoticed bugs crop up. The files now involved have different names so that the old and new formats don't screw each other with autoloading: FORMAT FASL - the usual FORMAT NUM - all of the ~R code. FORMAT BRACK - ~< and ~{ stuff FORMAT FLOAT - ~F, ~E, ~$ - floating point stuff. FORMAT INVOKE - contains the format-invoke function, which exists for compatibly defining format operators in implementations which do not have SFAs. FORMAT UMACS - user-macros; define-format-op, etc. Some of the stuff has been remodularized, and some random data-structure has been flushed, so some stuff (notably the justification hair for ~A, ~S, ~D, ~O) has been moved back into the main fasl file. ~C has been changed to be more compatible with the current Lispm definition. Approximately: ~C just outputs the arg (coerced to a character code) ~@C does a # inversion, eg "#\return", "#/A" ~:C tries to print the character in human-readable form. Uses the same name inversion as ~@C does. eg, "Return", "Meta-A". ~:@C is ~@C plus parenthetically states how the character can be typed on the user's keyboard. There is a hook for this, and no action is supplied by default. The floating-point operators are under development, and i will not commit myself to detailed specifications other than the following: ~nF = output the flonum arg in n digits ~nE = output the flonum arg in exponential format in n digits ~r,l$ = output the flonum arg in fixed format with exactly r digits to the right of the decimal point, and at least l to the left (default r = 2, l = 1, as in "dollars")  Date: 30 April 1981 10:29-EST From: Kent M. Pitman To: JONL at MIT-MC cc: BUG-LISP at MIT-MC ... When an unusual value for the array is given to FILLARRAY, then the possibility exists that it may be a file object, so that is why BLTARRAY is loaded. Of course it finds out that none of its cases are applicable either, so ... Maybe FILLARRAY could check more before autloading... If it's worried arg2 is going to be a file, while doesn't it use FILEP or (EQ (TYPEP x) 'ARRAY) ...? These predicates seem much more relevant.  Date: 30 April 1981 08:59-EST From: Jon L White To: KMP at MIT-MC cc: BUG-LISP at MIT-MC Date: 30 April 1981 02:03-EST From: Kent M. Pitman (FILLARRAY 'NON-ARRAY NIL) ;Loading BLTARRAY 2 ;NIL G3ZB""G((-*D... . . . and why does NIL show up in the error message here instead of NON-ARRAY which appears in the other case. In the first case, it was complaining about the first argument (NON-ARRAY), whereas in this case, it is complaining about the second argument, namely ().  Date: 30 April 1981 08:52-EST From: Jon L White Subject: Initial value for variable TTY To: JPG at MIT-MC, GSB at MIT-ML, KWC at MIT-ML cc: BUG-LISP at MIT-MC Date: 30 April 1981 07:35-EST From: Jeffrey P. Golden In a fresh L^K : TTY is bound to +INTERNAL-TTY-ENDPAGEFN instead of a nice integer indicating terminal type. Boo! Patched in TS LISP, and corrected in sources. Same condition as reported in GSB@MIT-ML 04/29/81 16:20:13 Re: bleagh! To: (BUG LISP) at MIT-ML In lisp 2100, the variable TTY has an initial value of +INTERNAL-TTY-ENDPAGEFN. . . . [Ken: use (= (status ttytype) 0) instead of (= tty 0)]  Date: 30 April 1981 07:55-EST From: Jon L White Subject: FILLARRAY subloading BLTARRAY To: KMP at MIT-MC cc: BUG-LISP at MIT-MC Addenda to previous comment: it's when the second arg is "unusual" -- namely not a list -- that BLTARRAY is loaded. Typical usage for "unusual" second args is file-arrays.  Date: 30 April 1981 07:47-EST From: Jon L White To: KMP at MIT-MC cc: BUG-LISP at MIT-MC Date: 30 April 1981 02:03-EST From: Kent M. Pitman (FILLARRAY 'NON-ARRAY NIL) ;Loading BLTARRAY 2 ;NIL G3ZB""G((-*D... Why is BLTARRAY loaded here but not for (FILLARRAY 'NON-ARRAY '(NIL)) and why does NIL show up in the error message here instead of NON-ARRAY which appears in the other case. When an unusual value for the array is given to FILLARRAY, then the possibility exists that it may be a file object, so that is why BLTARRAY is loaded. Of course it finds out that none of its cases are applicable either, so ... Maybe FILLARRAY could check more before autloading.  Date: 30 Apr 1981 0003-PDT From: Dick Gabriel Subject: NOT AN ARRAY To: bug-lisp at MIT-AI The problem with (fillarray 'not-array '(nil)) is that at ARGT3 (in L;ARRAY >), `SIXBIT' is incorrectly spelled `ASCII'. I fixed it in the sources, patched it at SAIL, but will leave it up to the locals to patch it at MIT. -rpg-  Date: 30 April 1981 02:03-EST From: Kent M. Pitman Subject: While we're on the subject To: BUG-LISP at MIT-MC (FILLARRAY 'NON-ARRAY NIL) ;Loading BLTARRAY 2 ;NIL G3ZB""G((-*D... Why is BLTARRAY loaded here but not for (FILLARRAY 'NON-ARRAY '(NIL)) and why does NIL show up in the error message here instead of NON-ARRAY which appears in the other case.  Date: 30 April 1981 02:01-EST From: Kent M. Pitman Subject: Additional data on FILLARRAY of non-arrays To: BUG-LISP at MIT-MC (FILLARRAY 'NON-ARRAY '(NIL)) ;NON-ARRAY G3ZB""G((-*D@V4( ;C %D10+ 'HN5@... I note for the record that DDT says: 1'G3ZB"" = 0"NOT A 1'G((-*D = 0"N ARR 1'@V4(  = 0"AY! ... Hope this helps.  GSB@MIT-ML 04/30/81 01:43:40 Re: someones error msg loses To: (BUG LISP) at MIT-ML (fillarray 'non-array '(nil)) Try it, you'll like it  GSB@MIT-ML 04/29/81 20:07:46 Re: tty prescan loses badly To: (BUG LISP) at MIT-ML the new hack for calling the tty prescan initially also causes it to get called again, after it has returned, for subparts of the expression being read via recursive READs. You can follow this easily enough by putting a breakpoint at $DEVPS and typing something like #'FOO . This is not noticible with the dumb prescan but it breaks brand-x totally. p.s. it is not sufficient to additionally make sure the right half of BFPRDP is 0 before calling the prescan function when there are already buffered back characters. p.p.s. The "cain r,qttybuf" test is bogus, since R hasn't been restored yet.  GSB@MIT-ML 04/29/81 16:20:13 Re: bleagh! To: (BUG LISP) at MIT-ML CC: KWC at MIT-ML In lisp 2100, the variable TTY has an initial value of +INTERNAL-TTY-ENDPAGEFN. This causes an interpreted "=" great consternation. For that matter, what possible reason is there for announce-&-load-init-file to bind ERRSET to NIL? This is totally cretinous and makes errors next to impossible to track down because of the errset in there. [Ken: use (= (status ttytype) 0) instead of (= tty 0)]  KWC@MIT-ML 04/28/81 17:49:09 To: (BUG LISP) at MIT-ML (boole 7 foo) is the identity function in the interpreter but generates a compiler error. I have a macro that forms masks by OR-ing and AND-ing a bunch of things. It would be really nice if it could generate the appropriate code in this case so I don't have to check if there is only one of them.  GSB@MIT-ML 04/28/81 03:35:41 Re: gcdemn To: (BUG LISP) at MIT-ML i installed the changes i made nearly two months ago and had forgotten to install...  Date: 24 April 1981 20:11-EST From: George J. Carrette To: BUG-LISP at MIT-MC Would it be possible to have a mode where if print is going to output something of TYPEP RANDOM it signals an error? This problem came up when the macsyma->lisp translator did nasty things and output garbage for the lisp compiler to read. It would be nice to catch these kind of errors as soon as possible, (in this case the file was FTP'd to another machine before it was compiled). -gjc  Date: 23 April 1981 00:10-EST From: George J. Carrette To: BUG-LISP at MIT-MC (MEMQ FOO '(BAR)) generates a stupid error message in the compiler, (COMMENT **** (OR (EQ FOO (QUOTE BAR))) There are not two or more clauses here - do you really want this? ) I think it should cut out the cute shit here since it doesn't even try to catch much more important errors like (defun f (x) (declare (flonum x)) (+ x x)) Give me a break, its wasting my time with stylistic remarks when it doesn't even check for simple data-type errors. -gjc  Date: 22 April 1981 19:20-EST From: George J. Carrette To: BUG-MACLISP at MIT-MC TYI to SFA is broken in in L and MACLISP. (defun foo (a b c) (if (eq b 'which-operations) '(tyi) c)) (setq foo (sfa-create 'foo 0 'foo)) (trace foo) (tyi foo -1) you will see foo entered with arguments (#SFA-|FOO|-666 TYI #47216). What kind of garbage is this third argument? Anyway, somehow TYI manages to return -1.  Date: 22 April 1981 15:54-EST From: Kent M. Pitman Subject: New mailing list To: BUG-LISP at MIT-MC This is to notify you that you are on the recently-revised BUG-LISP mailing list. For further info, see the file MC: LSPMAIL; MACLISP INFO. To have yourself removed from this mailing list, send mail to INFO-MACLISP-REQUEST and it will be taken care of in the near future. -kmp  Date: 22 April 1981 15:36-EST From: Jon L White Subject: Reappearance of ? To: SOLEY at MIT-MC cc: BUG-STRING at MIT-MC Oddly enough, this isn't a "reappearance", but a newly-found fence-post bug in string-pnput: Date: 22 April 1981 13:32-EST From: Richard Mark Soley Subject: Reappearance of The zeroed words bug has returned. Try loading a Nile: . . . and look at the fun in STR:GCMARRAY. Fixed in STRING 155, and new NILAID dumped out. In fact, the particular manifestation you saw should have been "Reappearance of " rather than "Reappearance of "; at least that is what I saw and fixed.  Date: 22 April 1981 15:35-EST From: Jon L White Subject: To: SOLEY at MIT-MC cc: BUG-STRING at MIT-MC Oddly enough, this isn't a "reappearance", but a newly-found fence-post bug in string-pnput: Date: 22 April 1981 13:32-EST From: Richard Mark Soley Subject: Reappearance of The zeroed words bug has returned. Try loading a Nile: . . . and look at the fun in STR:GCMARRAY. Fixed in STRING 155, and new NILAID dumped out. In fact, the particular manifestation you saw should have been "Reappearance of " rather than "Reappearance of "; at least that is what I saw and fixed.  Date: 22 April 1981 13:32-EST From: Richard Mark Soley Subject: Reappearance of To: BUG-STRING at MIT-MC The zeroed words bug has returned. Try loading a Nile: NILE$$^S NILAID^K (load 'debug) and look at the fun in STR:GCMARRAY. Sigh. -- Richard  Date: 22 April 1981 13:27-EST From: Richard Mark Soley Subject: STRING-MISMATCHQ To: JONL at MIT-MC cc: BUG-STRING at MIT-MC Date: 22 April 1981 06:55-EST From: Jon L White To: SOLEY cc: BUG-STRING Re: STRING-MISMATCHQ Re: Date: 21 April 1981 16:45-EST From: Richard Mark Soley Why WHY WHY was STRING-MISMATCHQ changed? It was working so well.... STRING-MISMATCHQ should return a FIXNUM (index of first change) or it should return NIL (no difference in strings). . . . STRING-MISMATCHQ now works ok in version 153 (now on LISP;). Soley, this problem and the recent string gc probelm are partly to blame on you and your idea of having a STR/:COMPARE-WORDS -- had it been left to me, there would have been no desire to fiddle with tenuously-working code. No more "ideas" for STRING. Please, JONL, let's have none of that -- I never asked you to change anything, just add str:compare-words. -- Richard  Date: 22 April 1981 06:55-EST From: Jon L White Subject: STRING-MISMATCHQ To: SOLEY at MIT-MC cc: BUG-STRING at MIT-MC Re: Date: 21 April 1981 16:45-EST From: Richard Mark Soley Why WHY WHY was STRING-MISMATCHQ changed? It was working so well.... STRING-MISMATCHQ should return a FIXNUM (index of first change) or it should return NIL (no difference in strings). . . . STRING-MISMATCHQ now works ok in version 153 (now on LISP;). Soley, this problem and the recent string gc probelm are partly to blame on you and your idea of having a STR/:COMPARE-WORDS -- had it been left to me, there would have been no desire to fiddle with tenuously-working code. No more "ideas" for STRING.  Date: 21 April 1981 16:45-EST From: Richard Mark Soley Subject: STRING-MISMATCHQ does NOT work. To: BUG-STRING at MIT-MC ********** BUG REPORT ********** Why WHY WHY was STRING-MISMATCHQ changed? It was working so well.... STRING-MISMATCHQ should return a FIXNUM (index of first change) or it should return NIL (no difference in strings). The current string-mismatchq returns NIL or #T (incorrectly, I might add), all of which adds up to NILE being dead in the water yet again. I believe it is the VERY VERY INCORRECT REPEAT INCORRECT call to str/:compare-words inside a #+PDP-10 in STRING-MISMATCHQ in NILCOM;STRING >; remember that str/:compare-words, to be fast, does NOT bother to return WHERE discrepancies arise, it just returns if they DO OR NOT. It would be very nice if this BUG was fixed sometime in the not-too-distant future. ********** BUG REPORT ********** -- Richard  Date: 21 April 1981 10:57-EST From: Robert W. Kerns Subject: Malformed MacLisp To: ALAN at MIT-MC, MOON at MIT-MC cc: BUG-LMMAN at MIT-MC, BUG-LISP at MIT-MC HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHaHaHaHaHaHaHaHahahahahahahahahahaaaaaaaaaaaaaaaaaaa..................URKK!! I hope I don't have any occurances of that in my code, using special variables! I think the right thing to do here is to leave the LISPM alone and fix the losing MacLisp interpreter. The compiler is OK.  Date: 21 April 1981 10:50-EST From: Alan Bawden Subject: Malformed do loops To: RWK at MIT-MC cc: MOON at MIT-MC, BUG-LMMAN at MIT-MC, BUG-LISP at MIT-MC Date: 21 April 1981 08:15-EST From: Robert W. Kerns Date: 17 April 1981 17:31-EST From: Alan Bawden Subject: Malformed do loops To: MOON at MIT-MC cc: BUG-lmman at MIT-AI, BUG-lispm at MIT-AI Date: 17 April 1981 16:04-EST From: David A. Moon ALAN@MIT-MC 04/17/81 07:29:03 To: (BUG lmman) at MIT-AI The do loops in both of the samefringe functions in the stack-group documentation examples, are malformed. (pages 154 and 155) No they aren't. This is an incompatibility between Lisp machine and Maclisp. That code was tested by running it directly out of the source file of the manual by the way. Well that's a shame. Could we get it changed back? Doesn't anyone else ever mis-type the number of parens in a do loop out there? I sure am surprised I haven't noticed this before given the number of times I make the error. Huh? Am I confused or are you two? As near as I can figure, both DO loops are perfectly legal in both LISPM and MacLisp. Or are you refering to something else besides the atomic index variable specification? Well, well. MacLisp does seem to try and support this losing feature: (putprop 'v1 'foo 'bar) FOO (do (v1 v2) (nil) (print (list v1 v2))) (NIL NIL) ;first time around v1 and v2 bound to nil ;FOO UNBOUND VARIABLE ;(caddr 'v1) is FOO! ;BKPT UNBOUND-VARIABLE  BARMAR@MIT-MC 04/21/81 01:43:21 Re: #\STOP-OUTPUT To: (BUG lisp) at MIT-AI I have a suggestion for what to do with #\STOP-OUTPUT and friends in MacLisp, although I realize it is not the greatest. These should evaluate to whatever the LispMachine SUPDUP program sends when these function keys are typed, i.e. sends a ^P, etc. The problem with this is that if the LispMachine programmers decide to change the interpretations of these keys, MacLisp would need to be patched to contain the fix. I do not know if these interpretations are an advertised feature of LispMachine SUPDUP, so such things should not be wired into MacLisp until they are standardized. Barmar  Date: 19 April 1981 23:35-EST From: Daniel L. Weinreb Subject: YES-OR-NO-P and Y-OR-N-P To: JONL at MIT-MC, ALAN at MIT-MC cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC The Lisp Machine did, at one time, allow the args to Y-OR-N-P to be in either order, because we were in the middle of an incompatible phase-over.  Date: 19 April 1981 15:37-EST From: Jon L White To: eb at MIT-AI cc: BUG-LISP at MIT-MC Date: 18 April 1981 01:36-EST From: Edward Barton What on earth does this mean: ;System error, or system code incomplete: Id 'NIL' in function SI:INVALIDATED. ; Losing datum is: LIST ;+INTERNAL-LOSSAGE (NIL SI:INVAIDATED LIST) In the LISP RECENT note of "Friday, Dec 5,1980", there was an announcement of the function +INTERNAL-LOSSAGE -- this particular instance of its usage is related to the macro-caching package. Probably you changed the value of MACRO-EXPANSION-USE in the middle of some debugging session, but even if you didn't, the new DEFMAX package should correct the problem. I made the DEFMAX facility more robust with regard to this kind of problem on April 5, but apparently didn't :INSTALL it to AI -- have just done so this afternoon. So if you could try the same problem again, I'd appreciate knowing if it has gone away (using DEFMAX 92).  Date: 19 April 1981 13:20-EST From: Jon L White Subject: Having our cake and eating it too To: dick at MIT-AI cc: BUG-LISP at MIT-MC Date: 18 April 1981 15:02-EST From: Richard C. Waters more of a question than a bug, when calls to status and sstatus are compiled, do they still have to parse the command name even when this is known at compile time. Yes, I'm afraid this is so -- QUUX started a system of multiple entries to STATUS functions some years ago, so that the complr could just PUSHJ P, to the right place, but we never finished this. The question was one of achieving a very small efficiency factor, versus a modestly large investment of development time; we preferred to develop other things, and at this point in time, its hard to justify much more development-for-the-sake-of-speed on the PDP10 MacLISP. A similar but more interesting question, re EXTENDS. . . When this is the case everything could compile very effeciently, because you could find out at compile time what all of the methods were and everything, and save a great deal of searching around. . . . This point is certainly worth considering -- indeed SMALLTALK does this. There is very little needed in the COMPLR in the form of "understanding" declarations to make it happen. THis problem will occur in NIL too, although the feeling of many persons is that the FLAVOR system has such a small, albeit constant, time overhead that most persons won't care to bother with declarations.  Date: 18 April 1981 15:02-EST From: Richard C. Waters To: BUG-LISP at MIT-AI more of a question than a bug, when calls to status and sstatus are compiled, do they still have to parse the command name even when this is known at compile time. A similar but more interesting question, re EXTENDS. there are many complex ways you might use them certainly possibly including doing new defclass*s and new defmethod*s on the fly. However one might very well just use them to keep the data structures and stuff straight, with all of the classes and methods known at compile time. When this is the case everything could compile very effeciently, because you could find out at compile time what all of the methods were and everything, and save a great deal of searching around. I have the feeling that no such effeciency happens, and I wonder if anybody is working on this or not. I feel it is sad if we have to pay very heavily in effeciency for a feature that is otherwise very aesthetic when with a little work we aught to be able to have our cake and eat it too. Dick Waters  Date: 18 April 1981 01:36-EST From: Edward Barton To: BUG-LISP at MIT-AI What on earth does this mean: ;System error, or system code incomplete: Id 'NIL' in function SI:INVALIDATED. ; Losing datum is: LIST ;+INTERNAL-LOSSAGE (NIL SI:INVAIDATED LIST)  GSB@MIT-ML 04/17/81 02:27:50 To: (BUG LISP) at MIT-ML (lap a b) ... does (args 'a nil) Should check B being SUBR, LSUBR, FSUBR  Date: 16 Apr 1981 1529-PST From: G.JONL at SU-SCORE Subject: More MacLISP stuff, and LEDIT To: csd.grinberg at SU-SCORE cc: zubkoff at CMU-10A, bug-lisp at MIT-MC Well, Finally foound what appears to be the near-optimal solution for the TOPS-20 line-mode, and have patched it into the dumped maclisp here at score; These things just aren't visible on MIT-XX and other MIT Tweneces, since they ahve the super-winning VTS code now. In fact, neither ITS version nor TENEX version lets LINMODE get full control, as it does under the RDTTY jsys. But in any case, it seems back in shape again; maybe we should try FTPing the LISP.EXE file from SCORE to CMU-20C for the benefit of bug-finders there? As for LEDIT, well, there is another problem evident at SCORE which doesn't happen at CMU, MIT, or on TENEX systems -- namely, login names like "CSD.FOO" don't work right as a file extension for the temporary name file hac. I've fixed up the lisp side of LEDIT to strip off all characters up to and including the last ".", but someone'll have to look at the LEDIT.EMACS file and figure out how to get the string in q-reg 3 (which came from FS UName) to be likewise stripped. Any takers? -------  Date: 14 April 1981 14:17-EST From: Jon L White Subject: sstatus tty To: SOLY at MIT-MC cc: BUG-LISP at MIT-MC, NILE at MIT-MC Date: 13 April 1981 16:38-EST From: Richard Mark Soley Subject: AAAAAAAAAAARGH!!!!! Huh? Try (sstatus tty # # #) in NILAID. He don't work! It gets a wrong-type-arg on #FILE-IN-blah-blah, which is (I believe) the value of TYI. . . . Fixed. This was a bug in XLISP, which was wy it showed up in NILAID but not in regular LISP.  Date: 13 April 1981 21:46-EST From: Robert W. Kerns Sender: ___111 at MIT-MC Subject: (SSTATUS TTY ...) To: SOLEY at MIT-MC, KMP at MIT-MC cc: BUG-LISP at MIT-MC, BUG-NIL at MIT-MC, NILE at MIT-MC To clarify what is going on with this, the reason SSTATUS TTY returns NIL is that ITS won't let it set these TTY variables unless it has the TTY, despite the fact that it could be made to work just by storing into the saved per-job copy of those variables. So as long as ITS doesn't work as it should, both functionalities are probably desireable, and LISP should not be changed.  Date: 13 April 1981 18:52-EST From: Kent M. Pitman Subject: (SSTATUS TTY ...) To: SOLEY at MIT-MC cc: BUG-LISP at MIT-MC, BUG-NIL at MIT-MC, NILE at MIT-MC On ITS, you should use (SYSCALL n 'TTYSET TYI x y z) as in LIBDOC;TTY > since (SSTATUS TTY ...) or (STATUS TTY ...) -- I forget -- has the severe `bug' that if the job does not have the TTY, it simply does nothing. It does not hang waiting for the job to get the TTY, but rather just returns NIL. (STATUS TTY) is, sadly, used all over as a predicate to tell if a job has the TTY. This is a total loss, but... On non-ITS, I guess you have to work out the LAP for a jsys or suffer with ([S]STATUS TTY ...). At least on those sites, people don't tend to control-P their jobs so won't be as inclined to lose. -kmp  Date: 13 April 1981 1740-EST (Monday) From: Guy.Steele at CMU-10A To: bug-lisp at MIT-MC Subject: Re: #\STOP-OUTPUT in Maclisp CC: dick at MIT-AI, kmp at MIT-MC, rwk at MIT-MC, soley at MIT-MC In-Reply-To: Richard Mark Soley's message of 13 Apr 81 10:17-EST Message-Id: <13Apr81 174003 GS70@CMU-10A> An idea that occurred to me was to introduce a notion of "reading a form, but not really". The problem is more general than #\STOP-OUTPUT. For example, suppose one is reading into a MacLISP: should #+LISPM #,(QUIT) kill your LISP or not? So suppose that, explicitly or implicitly, READ takes a flag saying whether or not to *really* construct the S-expression, or just skip over things. #+ and #- would set the flag to the disable state when reading the following form if the conditional fails. When the flag is in this state: (1) #\ will simply read the following S-expression, and complain if it isn't a symbol, but not complain if it is not a known name. (2) #, and #. will read the following S-expression in the failing state, but not evaluate. (3) #+ and #- will read a following name and then an S-expression, both in the failing state; in particular, they cannot complain if the flag name following is not known. (4) Numbers and symbols are pretty much undistinguished, and probably have to read as symbols. This is in case one dialect supports different syntaxes for numbers; then one can get away with #+QuaternionLISP 3+5i-6.7j+43.7e5k . (5) # followed by a character for which no macro is defined probably should just quietly disappear (with the losing character). This mostly makes #+ScribeLISP (#@Begin[Foo] ZTESCH #@End[Foo]) work, though not in all cases. Admittedly it does more than one can do with IF-FOR-LISPM -- but the point is to mostly let you get away with incompatible syntax as well as semantics. Then again, perhaps it would be more clear simply to do #+LISPM[ anything with balanced brackets ] ? Sigh. --Guy  Date: 13 April 1981 16:38-EST From: Richard Mark Soley Subject: AAAAAAAAAAARGH!!!!! To: BUG-NIL at MIT-MC, BUG-LISP at MIT-MC cc: NILE at MIT-MC Huh? Try (sstatus tty # # #) in NILAID. He don't work! It gets a wrong-type-arg on #FILE-IN-blah-blah, which is (I believe) the value of TYI. This is awfully important; I need to turn off echoing to work. Last bit of info: sstatus tty seems to work find in LISP, just not in NILAID. -- Richard ************* YES, THIS IS A BUG REPORT **************  Date: 13 April 1981 12:28-EST From: Kent M. Pitman Subject: #\STOP-OUTPUT ;continued To: SOLEY at MIT-MC cc: BUG-LISP at MIT-MC No. Nested #+'s are bad enuf. Bug telling a guy that inside a #+LISPM he may need do do some #-LISPM conditionals? That's far from intuitive. Also, for Sussman's sake (and I think he takes a reasonable position), whatever we decide to do must work inside of (IF-FOR-LISPM ...). It cannot be constrained to work only inside of #+LISPM or #Q. That would be very ugly. Finally, we do want to allow the #\... things which are invalid to compose structure, otherwise they will be very hard to debug. It is easy for someone to recognize bad structure once it is read in, but read errors are the bane of lisp programming because they do not give you a hold on your program -- you cannot look at them in debuggers, etc. This is why Bob and I decided that even in the erring case, we need to cons a form successfully during READ (even if such a form will err at EVAL). -kmp  Date: 13 April 1981 10:17-EST From: Richard Mark Soley Subject: #\STOP-OUTPUT in Maclisp To: KMP at MIT-MC, RWK at MIT-MC cc: BUG-LISP at MIT-MC, DICK at MIT-AI Sender: KMP Re: #\STOP-OUTPUT in Maclisp We've decided that #\STOP-OUTPUT and friends should do something like a CONS-A-READ-UNDEFINED-OBJECT so that the object read in is How about: #\ #+LISPM STOP-OUTPUT #-LISPM SOMETHING-ELSE -- Richard  Date: 12 April 1981 10:11-EST From: Robert W. Kerns Subject: More BADPI;'s To: KMP at MIT-MC cc: BUG-LISP at MIT-MC Date: 11 April 1981 17:55-EST From: Kent M. Pitman Sender: VP at MIT-MC Subject: More BADPI;'s To: BUG-LISP at MIT-MC Gee, even cli interrupts seem to kill ALLOC. I just got mail from COMSAT in an alloc and that died with BADPI;(ATTY;ALLTYI>>.IOT B,C C/-1 oh, well. -kmp C'mon, that's not a CLI interrupt, that's an ATTY; interrupt. Your HACTRN got the CLI interrupt.  Date: 11 APR 1981 1755-EST From: kmp at MIT-MC (Kent M. Pitman) Sent-by: VP at MIT-MC Subject: More BADPI;'s To: (BUG LISP) at MIT-MC Gee, even cli interrupts seem to kill ALLOC. I just got mail from COMSAT in an alloc and that died with BADPI;(ATTY;ALLTYI>>.IOT B,C C/-1 oh, well. -kmp  Date: 11 APR 1981 1751-EST From: VP at MIT-MC (Victoria Pigman) To: (BUG LISP) at MIT-MC When in ALLOC if you type ? and are getting the doc typed out if you get a **MORE** interrupt, it shows up as a BADPI;(IOCH1;) ALOIOT>>.IOT A,A A/40 I suspect this is the same bug with BADPI; that GSB et al have been complaining about for ages. This is a good reliable way to reproduce it, tho'. -kmp  EB@MIT-ML 04/11/81 15:45:38 To: (BUG LISP) at MIT-ML RENAMEF of an open file object does a CNAMEF, but RENAMEF of a closed one does not.  Date: 10 APR 1981 1521-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: Misleading error message To: (BUG LISP) at MIT-MC (SSTATUS /! #'(LAMBDA () (READ)) SPLICING) '(A . C !(C)) ;MULTIPLE SPLICING MACROS RETURNED NON-NIL AFTER "." -- READ This error message is misleading for two reasons: * There is only one splicing macro involved. * Non-NIL values are not the issue. Eg, '(A . !(B)) returns (A . B) as expected. -kmp  Date: 10 APR 1981 1504-EST From: kmp,rwk at MIT-MC Sent-by: KMP at MIT-MC Subject: #\STOP-OUTPUT in Maclisp To: DICK at MIT-AI CC: (BUG LISP) at MIT-MC We've decided that #\STOP-OUTPUT and friends should do something like a CONS-A-READ-UNDEFINED-OBJECT so that the object read in is # or something to that effect. That way, the compiler can detect the error reliably, and the interpreter will stand a fair chance of providing a useful diagnostic, too. Eg, EVAL'ing # should presumably err immediately. If this really bothers someone please let us know. It probably won't go in immediately. -kmp  Date: 10 April 1981 14:29-EST From: Kent M. Pitman To: RWK at MIT-MC cc: BUG-LISP at MIT-MC, DICK at MIT-AI Bob, as long as #+ is constrained to call the Maclisp reader, it isn't fair that (COND ((= C #+LISPM #\STOP-OUTPUT #-LISPM #^S) ...) ...) should fail at read-time. I would advocate one of two things. * STOP-OUTPUT should read as some useful value (eg, #^S). This would make it possible perhaps to actually share code between dialects. * If you want to force an error, why not have #\STOP-OUTPUT simply read as the symbol STOP-OUTPUT in Maclisp. Then things like (= C #\STOP-OUTPUT) would die on a ;STOP-OUTPUT NON-NUMERIC VALUE error, which would help quickly isolate the location of the error. And things like #+LISPM #\STOP-OUTPUT would not fry the reader. I think I prefer the latter solution because it sets a useful precedent for how to handle other characters which may not have simple mappings in ascii (, , ... etc.) -kmp  Date: 10 APR 1981 1423-EST From: RWK at MIT-MC (Robert W. Kerns) To: dick at MIT-ML CC: (BUG LISP) at MIT-MC Well, as I said, #\ isn't the only thing that has that problem, and a more general solution really is called for. But I fully agree that ANY solution is better than none and that you're right to complain.  DICK@MIT-ML 04/10/81 14:20:09 To: RWK at MIT-MC CC: (BUG LISP) at MIT-ML sorry I wasn't more explicit. My problem is that the #\stop-output is in the scope of a #Q. I am not trying to get it to read in as anything interesting, I just don't want it to bomb out. Since #\ produces a number, I suggest that #\stop-output read in as #O220 just like on the lispm. It is true that there is no stop-output in maclisp, but this shouldn't make it impossible for a program to read in (particularly if the #\stop-output is hidden by a #Q). dick waters  Date: 10 APR 1981 1407-EST From: RWK at MIT-MC (Robert W. Kerns) To: DICK at MIT-MC CC: (BUG LISP) at MIT-MC Pray tell, what should #\STOP-OUTPUT read in as in MacLisp? I think it not being able to read in is entirely correct, since that indeed is the problem; there is no STOP-OUTPUT character to read in as in MacLisp. I think some other solution is wanted to the problem, but I am not sure just what it would be. Maybe nobody else can think of a better solution either, in which case we should make such things read in as -1 or something, but I hope somebody has a better idea. Note that this problem is not limited to #\, but is found wherever there is a read-syntax feature of one system you wish to use in a file which is read by more than one system.  DICK@MIT-ML 04/10/81 13:59:58 To: (BUG LISP) at MIT-ML It would help compatability with lispm if #\ reconized all off the names that are recognized on the lispm. for example it is not currently possible to even read in #\stop-output in maclisp. Dick Waters  Date: 10 APR 1981 1230-EST From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC (TYI ()) ; works. (UNTYI X ()) ; does not like () argument.  Date: 10 APR 1981 0408-EST From: JONL at MIT-MC (Jon L White) Subject: Previously fixed bug To: SOLEY at MIT-MC CC: (BUG LISP) at MIT-MC, NILE at MIT-MC, RZ at MIT-MC Date: 9 April 1981 21:42-EST From: Richard Mark Soley Subject: ;17. Can't get enough STRING space. NILE$$^S NILAID^K (load 'debug) Sigh. <<<<<<< ******* MAJOR STRING BUG ******* >>>>>>> I've already seen this some time ago, and fixed it, although never explicity said what th proble was. Since you had to delete the later NILAIDs earlier tis week, I guesss you were just running in an out-of-date version. At any rate, I've made up a new NILAID, and loaded up your example as noted above, which didn't lose. Dumped it out as NILE;TS TRYTHIs. i'll continue to login from time to time, so if this hasn't finished off th bug, let me know.  Date: 10 April 1981 03:06-EST From: Robert W. Kerns To: KRONJ at MIT-MC cc: BUG-LISP at MIT-MC Date: 9 April 1981 03:02-EST From: David Eppstein To: BUG-LISP at MIT-MC If from a bare LISP I load EXTEND and do (describe 'object-class) I get an UNDF-FNCTN break with the message METHOD-NEXT UNDEFINED FUNCTION IN UUO CALL Am I doing something wrong, or is this a bug? Fixed. JONL: Structure macros like METHOD-NEXT belong in EXTMAC!  Date: 9 APR 1981 2142-EST From: SOLEY at MIT-MC (Richard Mark Soley) Subject: ;17. Can't get enough STRING space. To: (BUG NIL) at MIT-MC, (BUG LISP) at MIT-MC CC: NILE at MIT-MC, RZ at MIT-MC Look in NILE;DSK:CRASH NILAID or do: NILE$$^S NILAID^K (load 'debug) Sigh. -- Richard <<<<<<< ******* MAJOR STRING BUG ******* >>>>>>>  Date: 9 April 1981 19:53-EST From: Edward Barton To: BUG-LISP at MIT-AI The .INFO.;LISP NEWS documentation for SYSCALL says its arguments are supposed to be fixnums, with an update that says a file array gets turned into its channel number. Apparently (syscall 0 'foo 'A) passes (maknum 'a) as the address of its argument. Is that useful for anything? If not, I propose that a more useful treatment of symbols might be to convert them to sixbit. That would make TTYVAR calls easier, for example. Or else things that are neither fixnums nor file arrays should cause an error.  Date: 9 APR 1981 1535-EST From: MOON at MIT-MC (David A. Moon) Subject: CURSORPOS argument order To: KMP at MIT-MC CC: CWH at MIT-MC, (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-AI CC: DICK at MIT-AI Since there has been a lot of flaming about this, I will waste another 10 seconds of everyone's time pointing out that the bug has been fixed and CURSORPOS is now compatible between Lisp machine and Maclisp. It's not a patch.  Date: 9 APR 1981 0302-EST From: KRONJ at MIT-MC (David Eppstein) To: (BUG LISP) at MIT-MC If from a bare LISP I load EXTEND and do (describe 'object-class) I get an UNDF-FNCTN break with the message METHOD-NEXT UNDEFINED FUNCTION IN UUO CALL Am I doing something wrong, or is this a bug?  Date: 8 April 1981 17:04-EST From: Kent M. Pitman Subject: CURSORPOS argument order To: CWH at MIT-MC cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-AI, DICK at MIT-AI, Moon at MIT-AI Date: 8 April 1981 14:01-EST From: Carl W. Hoffman Date: 8 APR 1981 0029-EST From: Moon at MIT-AI (David A. Moon) Well it's documented to take it as the first arg in Maclisp, or it was when the Lisp machine cursorpos was written. Evidently it was changed. The only Lisp machine program I know of that uses CURSORPOS is Macsyma; so how come Macsyma works? Streams? But that's Space Age Technology. Macsyma calls CURSORPOS without a stream argument. The [now outdated] LispM manual has always claimed that streams were not supported, so I doubt at this point that many programs depend on them. The most recent documentation on the subject is as follows from .INFO.;LISP NEWS: FRIDAY APRIL 18,1975 FQ+9H.34M.47S. LISP 1049 - GLS - CURSORPOS MAY TAKE AN EXTRA ARGUMENT TO DETERMINE WHICH OUTPUT TTY TO DO THE CURSOR POSITIONING ON. IF THE LAST ARGUMENT CAN BE TAKEN TO BE A TTY, IT IS. ONE INCOMPATIBILITY IS THAT (CURSORPOS 'T) NOW MEANS GET THE COORDINATES OF TTY "T" RATHER THAN GO TO THE TOP OF THE SCREEN. TO GO TO THE TOP OF THE SCREEN FOR THE DEFAULT TTY, USE (CURSORPOS 'TOP) OR (CURSORPOS 124) OR (CURSORPOS 'T T). I would advocate letting the new manual be wrong and putting the arg in the `right' place since the function is documented to be for `Maclisp compatibility.' -kmp  Date: 8 April 1981 16:42-EST From: Kent M. Pitman To: KWC at MIT-ML cc: ALAN at MIT-MC, BUG-LISP at MIT-MC Date: 04/08/81 09:29:54 From: KWC at MIT-ML I noticed that DEFSTRUCT-EXPAND-REF-MACRO has a SUBR property ... Perhaps someone could think of a better name, because this name can be misinterpreted as I did at first. ----- Well, it's not as ambiguous as it looks at first glance. In fact, as it turns out, Lisp doesn't even try to parse the name at all. It *only* looks on the plist. So it will, correctly, infer that this is a subr without even being slowed down by the apparent ambiguity. It will not only not be misinterpreted, it won't even be miscompiled! Could be you're due for a vacation, Ken. You've been studying natural language too long. -kmp  Date: 8 April 1981 16:28-EST From: Kent M. Pitman To: JPG at MIT-MC cc: BUG-LISP at MIT-MC Date: 8 April 1981 14:48-EST From: Jeffrey P. Golden To: BUG-LISP Why does (NTHCDR '(1 2) 1) take forever. Since I got the arguments in the wrong order, why not a quick error message instead? ----- Why not run in (*RSET T) mode where you get such errors? -kmp  Date: 8 APR 1981 1613-EST From: ALAN at MIT-MC (Alan Bawden) To: KWC at MIT-ML CC: (BUG LISP) at MIT-MC KWC@MIT-ML 04/08/81 09:29:54 I noticed that DEFSTRUCT-EXPAND-REF-MACRO has a SUBR property ... Perhaps someone could think of a better name, because this name can be misinterpreted as I did at first. Well I'm sorry to say that changing this name will cause every defstruct in the world to have to be recompiled. (LispMachines and Multics too!) What's wrong with the name? It is what defstruct uses to expand reference macros, and it even works to say something like: (defstruct-expand-ref-macro '(spaceship-captain enterprise)) => (aref enterprise 2) What did you think it ment?  Date: 8 APR 1981 1448-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC Why does (NTHCDR '(1 2) 1) take forever. Since I got the arguments in the wrong order, why not a quick error message instead?  Date: 8 April 1981 14:01-EST From: Carl W. Hoffman Subject: CURSORPOS argument order To: Moon at MIT-AI cc: BUG-LISP at MIT-MC, DICK at MIT-AI, BUG-LISPM at MIT-AI Date: 8 APR 1981 0029-EST From: Moon at MIT-AI (David A. Moon) Well it's documented to take it as the first arg in Maclisp, or it was when the Lisp machine cursorpos was written. Evidently it was changed. The only Lisp machine program I know of that uses CURSORPOS is Macsyma; so how come Macsyma works? Streams? But that's Space Age Technology. Macsyma calls CURSORPOS without a stream argument.  KWC@MIT-ML 04/08/81 09:29:54 To: (BUG LISP) at MIT-ML I noticed that DEFSTRUCT-EXPAND-REF-MACRO has a SUBR property ... Perhaps someone could think of a better name, because this name can be misinterpreted as I did at first.  Date: 8 April 1981 02:22-EST From: Alan Bawden Subject: fowarded mail To: RWK at MIT-MC cc: ALAN at MIT-MC, HENRY at MIT-MC, BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC Date: 7 April 1981 18:11-EST From: Robert W. Kerns I take it this is the MacLisp destructuring version of LET you're trying to load? I don't know where the QFASL for this lives, but if you will recompile NILCOM;LET > you should win. ... Well, I took it to be a bug report about the LispMachine destructuring LET whose source and object live in LISPM2;LET. Perhaps someone should check that out as well...?  Date: 8 APR 1981 0029-EST From: Moon at MIT-AI (David A. Moon) Subject: CURSORPOS argument order To: DICK at MIT-AI, (BUG LISPM) at MIT-AI, (BUG lisp) at MIT-MC Date: 7 APR 1981 1758-EST From: HES at MIT-AI (Howard Shrobe) To: (BUG LISPM) at MIT-AI In System 65.33, ZMail 19.4, Daedalus 15.7, microcode 739, on Lisp Machine Two: why does cursorpos take the stream as the first arg in lispm when it takes it as the last arg in maclisp? Well it's documented to take it as the first arg in Maclisp, or it was when the Lisp machine cursorpos was written. Evidently it was changed. The only Lisp machine program I know of that uses CURSORPOS is Macsyma; so how come Macsyma works?  Date: 7 April 1981 18:11-EST From: Robert W. Kerns Subject: fowarded mail To: ALAN at MIT-MC, HENRY at MIT-MC cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC ALAN@MIT-MC 04/07/81 01:55:21 Re: fowarded mail To: (BUG LISPM) at MIT-MC Date: 7 April 1981 01:50-EST From: Henry Lieberman Subject: LET on the Lisp Machine To: BUG-LISP at MIT-AI The LET QFASL file doesn't seem to work. It bombs on trying to do a GLOBALIZE. I take it this is the MacLisp destructuring version of LET you're trying to load? I don't know where the QFASL for this lives, but if you will recompile NILCOM;LET > you should win. RMS incompatibly changed the GLOBALIZE function without suitable notification (or better, using a different name for his new functionality).  Date: 7 April 1981 18:09-EST From: Richard Mark Soley To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 7 APR 1981 1554-EST From: GJC (George J. Carrette) To: (BUG LISP) Do (TRACE READ) (SETQ READ 'READ). Why is the argument to READ so random? For a partial answer to your question, the argument (#11152) is the label TLRED1 in LISP. Why don't you look at the code for read? -- Richard  Date: 7 APR 1981 1554-EST From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC Do (TRACE READ) (SETQ READ 'READ). Why is the argument to READ so random?  Date: 7 APR 1981 1409-EST From: kmp at MIT-MC (Kent M. Pitman) Sent-by: ___124 at MIT-MC Subject: more on base To: (BUG LISP) at MIT-MC '(10 #8r10 10) => (10. 8. 8.) '(10 #2r10 10) => (10. 2. 2.) '(10 #o10 #.(print (list 'ibase= ibase 'base= base)) 10) (IBASE= 10. BASE= 10.) => (10. 8. T 10.) Maybe something about #. is re-initializing things...  Date: 7 APR 1981 1058-EST From: kmp at MIT-MC (Kent M. Pitman) Sent-by: ___011 at MIT-MC Subject: More cases of #o lossage... To: (BUG LISP) at MIT-MC CC: WGD at MIT-MC (SETQ IBASE 10. BASE 10. *NOPOINT NIL) '(#o10 () 10) => (8. NIL 8.) '(10 #o10 10) => (10. 8. 8.) '((#o10 10) 10) => ((8. 8.) 8.) Note also that #o'(10 10) ;(QUOTE (8. 8.)) Numeric token expected by some #-function when will this ever get fixed? btw, these bugs are in XLisp.2097 as well. -kmp  GSB@MIT-ML 04/07/81 07:35:32 To: (BUG LISP) at MIT-ML tracing something which returns multiple values loses if the printing involved uses multiple values. Even if trace-indent is hacked to bind +internal-interrupt-bound-variables, this might still lose as in an all-compiled system that might not be initialized. Plus there is the question of binding *:arn to 0 rather than nil...  Date: 7 APR 1981 0515-EST From: WGD at MIT-MC (William G. Dubuque) Sent-by: BIL at MIT-MC To: (BUG LISP) at MIT-MC In MACLISP 2077 with SHARPM 72 and BASE = IBASE = 10, *NOPOINT = () '(#o10 10) ==> (8. 8.) !  Date: 7 April 1981 01:50-EST From: Henry Lieberman Subject: LET on the Lisp Machine To: BUG-LISP at MIT-AI The LET QFASL file doesn't seem to work. It bombs on trying to do a GLOBALIZE.  Date: 7 April 1981 01:40-EST From: Richard L. Bryan Subject: STR:COMPRESS-SPACE To: JONL at MIT-MC cc: SOLEY at MIT-MC, BUG-LISP at MIT-MC, BUG-NIL at MIT-MC, NILE at MIT-MC Date: 6 APR 1981 1720-EST From: JONL at MIT-MC (Jon L White) Ok, I think I see why the last few chars of each string is being garbaged by STR:COMPRESS-SPACE. I don't have time to repair it be fore getting on the plane to CA, but I've talked out the problem with RLB and he may tackle it while I'm gone. Looks to me like it works now, STRING version /150 . I won't create a new NILAID. RMSoley, find the next bug!  Date: 6 APR 1981 1720-EST From: JONL at MIT-MC (Jon L White) Subject: STR:COMPRESS-SPACE To: SOLEY at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG NIL) at MIT-MC, NILE at MIT-MC Ok, I think I see why the last few chars of each string is being garbaged by STR:COMPRESS-SPACE. I don't have time to repair it be fore getting on the plane to CA, but I've talked out the problem with RLB and he may tackle it while I'm gone. Basically, Soley, some time ago, you and I decided it would be good for string-equal just to be able to do word comparisons, so that made the requirement that the bits in the last stored word of a string must be guaranteed to be zero -- certifying this guarantee after a string-relocation is what has been causing the bug.  Date: 6 APR 1981 1434-EST From: JONL at MIT-MC (Jon L White) To: SOLEY at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG NIL) at MIT-MC, NILE at MIT-MC Date: 6 April 1981 11:17-EST From: Richard Mark Soley Subject: Dead STRINGs in NILAIDs To: BUG-NIL at MIT-MC, BUG-LISP at MIT-MC I don't know what's causing it, but in NADMP 1049 and NADMP 1050, 98% of all strings are garbage (with the canonical garbage being 's). At this point I will not plead with you; I have no complaints with using NADMP 1048 and loading in LISP;STRING >, this works fine. Yes, this is very weird, that string's get garbaged when STRING 149 is run in current xlisp (version 2097), but not when run in current lisp (version 2077). I'll be gone to California for a week, and will look fix it when I get back -- at least you can work in the current lisp environment.  Date: 6 APR 1981 1126-EST From: SOLEY at MIT-MC (Richard Mark Soley) Subject: More info on STRING bug. To: (BUG NIL) at MIT-MC, (BUG LISP) at MIT-MC CC: NILE at MIT-MC It is always the last word of a string that gets garbaged, and it is NOT always zeroed; try doing: NILE$$^S NILAID^K (load 'debug) When it blows out, take a look at STR:GCMARRAY. You will find that the majority of strings have had their last word garbaged, with completely random stuff. This bug exists in NILAID 1049 AND NILAID 1050, but NOT in NILAID 1048. Therefore PLEASE do not delete NADMP 1048. -- Richard  Date: 6 APR 1981 1117-EST From: SOLEY at MIT-MC (Richard Mark Soley) Subject: Dead STRINGs in NILAIDs To: (BUG NIL) at MIT-MC, (BUG LISP) at MIT-MC Dear JONL: I don't know what's causing it, but in NADMP 1049 and NADMP 1050, 98% of all strings are garbage (with the canonical garbage being 's). At this point I will not plead with you; I have no complaints with using NADMP 1048 and loading in LISP;STRING >, this works fine. Perhaps something is broken. -- Richard  GSB@MIT-ML 04/06/81 05:03:35 Re: sstatus tty, cont. To: (BUG LISP) at MIT-ML in fact, (sstatus tty n1 n2 n3) does also. (sstatus tty {ni}* tyi) gets an MPV.  Date: 6 April 1981 04:49-EST From: Kent M. Pitman Subject: PREDICT and GRINDEF To: GSB at MIT-ML cc: BUG-LISP at MIT-ML, KWC at MIT-ML, PSZ at MIT-ML, WAM at MIT-ML Date: 04/04/81 21:32:37 From: GSB at MIT-ML It seems that grindef defines some rather useful names, like PREDICT. PREDICT's name should be a little bit more specific about who or what it is predicting for. ----- I have renamed the function PREDICT to GPREDICT. PREDICT looks like something users might know about, so to avoid lossage I have PREDICT get defined as an alias for GPREDICT iff GPREDICT is not FBOUNDP. If you happen to load your PREDICT definition after GRINDEF, you'll not be redefining anything critical. The EXPR property that conditionally goes on PREDICT can be removed after a while if/when people have changed any code that expected this function to exist. The new GFN is version 462 and is installed on AI,ML, and MC. Let me know if there are problems. The previous version is MC:LISP;GFN OFASL if anything bad happens and someone wants to retract the change. -kmp  GSB@MIT-ML 04/06/81 03:58:36 Re: in xlisp 2097 To: (BUG LISP) at MIT-ML (sstatus tty n1 n2) complains that is not a fixnum. 'tis not defaulting values properly...  Date: 5 April 1981 20:57-EST From: Jonathan A. Rees Subject: Twenex Maclisp wish list To: BUG-LISP at MIT-MC 1. Does FASLOAD or anyone else do anything about the OF%PLN bit in their various OPENF's? Evidently file I/O goes incredibly faster if the monitor doesn't need to continually be checking the line-number-p bit in file words. Perhaps for ascii files there could be an SSTATUS option settable on systems where you KNOW that you're never going to encounter a line number you'll want to ignore. 2. Is there any chance that Maclisp could hack the TOPS-20 argument block if it's given one? The idea is, you get this 128-word chunk of crap with the PRARG jsys; the first word is usually zero, and if it is, the rest of the words are an ASCIZ string which should be fetchable from lisp with STATUS JCL. This convention is used quite a bit at Yale and perhaps elsewhere, especially places using Yale tools, which are spreading. (This is the "correct" way of doing things, compared to what the DEC EXEC does with the "rescan buffer" nonsense. Actually the text in the PRARG, I think like the rescan buffer, gets you the entire command line, not just the JCL.) 3. Does Maclisp do a SETSN on startup (set system name)? If it did a SETSN to "MACLISP," programs which cared (like statistics gatherers: "how much time is being spent by Maclisps?") would be much happier.  Date: 5 APR 1981 1808-EST From: DCP at MIT-MC (David C. Plummer) Subject: CASEQ To: (BUG LISP) at MIT-MC PLEASE move this discussion to LISP-FORUM. As far as I can tell, you are discussing language issues, NOT BUGS. Thanks.  Date: 5 April 1981 15:47-EST From: George J. Carrette Subject: more on CASEQ To: KMP at MIT-MC cc: BUG-LISP at MIT-MC, JONL at MIT-MC What the heck is this "SYMMETRY" you are talking about? I see the following: [1] Sometimes the predicate used is "EQ" [2] Sometimes it is "=" In the interpreter both "EQ" and "=" do their own error checking, so that there is no need for the CASEQ special form to deal with it. Otherwise what it sounds like you are trying to do is construct a special form which really doesn't make much sense in terms of the other PRIMITIVES of the language. -gjc  Date: 5 APR 1981 1341-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: more on CASEQ To: GJC at MIT-MC CC: (BUG LISP) at MIT-MC, JONL at MIT-MC The definition of CASEQ for symbols as you describe is fine. The problem comes in its being then asymmetric for the fixnum case. You do not want to allow the fixnum case to expand into (LET ((TEMP form)) (COND ((= TEMP thing1) ...) ((= TEMP thing2) ...) ((OR (= TEMP thing3) (= TEMP thing4)) ...) (T ...))) since arbitrary forms cannot be compared with = and since one does not want to waste time doing a typep check in compiled code. hence in the interpreter, you do want an error for non-fixnum 1st arg... so by symmetry (if you care about such things), you should get an error for non-symbol first arg in the symbol case. that at least is what i believe to have been the reasoning involved in the original decision.  Date: 5 APR 1981 1339-EST From: JONL at MIT-MC (Jon L White) Subject: CASEQ To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC, GJC at MIT-MC I think you are mistaking a ubiquitous feature for a bug -- compiled code almost always omits the error checks implicit in the definition of the forms. At least one will have more of a choice with the NIL compiler. Of course, this isn't an issue where the micro-code can come to the run-time rescue.  Date: 5 APR 1981 1337-EST From: KMP at MIT-MC (Kent M. Pitman) To: JONL at MIT-MC CC: (BUG LISP) at MIT-MC, GJC at MIT-MC Yes, the case where it doesn't behave as described is in compiled code. GJC is pointing out that what is legal compiled and interpreted is different -- moreover, he claims that what it does compiled is perfectly acceptable and ought to be valid in the interpreter.  Date: 5 APR 1981 1220-EST From: JONL at MIT-MC (Jon L White) To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC Date: 5 April 1981 12:04-EST From: Kent M. Pitman Subject: CASEQ doesn't do MEMQ Well, CASEQ has always been clearly defined to do this kind of error checking -- insisting on a type-match between its first arg and the test forms. The fact that Lisp happened not to detect errors in some cases is just an implementational artifact. Do you claim there is some discrepancy between the documented action and the implementation? What are these "some cases" you mention? I agree, though, that we could relax the definition to be more tolerant of funny datatypes for CASEQ's first arg. Didn't you suggest the other day that this should not be called CASEQ, but rather something like GJCASEQ (as an acronym, maybe for Generalized Jumping CASEQ ??) ?  Date: 5 April 1981 12:04-EST From: Kent M. Pitman Subject: CASEQ doesn't do MEMQ To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Well, CASEQ has always been clearly defined to do this kind of error checking -- insisting on a type-match between its first arg and the test forms. The fact that Lisp happened not to detect errors in some cases is just an implementational artifact. I agree, though, that we could relax the definition to be more tolerant of funny datatypes for CASEQ's first arg. ;; Assumed DATUM is received evaluated and clauses unevaluated. (DEFUN CASEQ-INTERPRETER (DATUM &REST CLAUSES) (IF (FIXNUM-TYPE-CASEQ? CLAUSES) (SAME-OLD-FIXNUM-CASEQ-INTERPRETER-AS-WE-ALWAYS-HAD DATUM CLAUSES) (IF (SYMBOLP DATUM) (SAME-OLD-SYM-CASEQ-INTERPRETER-AS-WE-ALWAYS-HAD DATUM CLAUSES) (INTERPRET-IMPLICIT-PROGN (CDR (ASSQ 'T CLAUSES))))))  Date: 5 APR 1981 1158-EST From: JONL at MIT-MC (Jon L White) To: GJC at MIT-MC CC: (BUG LISP) at MIT-MC Say, this sort of proposal/discussion really belongs in LISP-FORUM, if anywhere: Date: 5 April 1981 11:31-EST From: George J. Carrette Subject: CASEQ doesn't do MEMQ To: KMP at MIT-MC cc: BUG-LISP at MIT-MC Hold it. I meant CASEQ does a MEMQ *after* some syntactic sugar has been applied, e.g. (CASEQ q (item ...)) => (CASEQ q ((item) ...)). . . . However, with respect to your initial bug report Date: 4 APR 1981 1414-EST From: GJC at MIT-MC (George J. Carrette) (CASEQ '(FOO BAR) '((X) 8)) gives a WRNG-TYPE-ARG error for its first argument. Says it wants a SYMBOL or a FIXNUM. I thought the definition of CASEQ was that it used MEMQ to test the cases except that "=" is used in maclisp if the cases are all fixnums. The documentation of CASEQ appears in the LISP NEWS dated "JAN 26,1978", and says nothing about MEMQ. Furthermore, the format is a special form with the keys being explicity typed in, so EQ is only appropriate for SYMBOLS, as is mentioned in that documentation.  Date: 5 April 1981 11:31-EST From: George J. Carrette Subject: CASEQ doesn't do MEMQ To: KMP at MIT-MC cc: BUG-LISP at MIT-MC Hold it. I meant CASEQ does a MEMQ *after* some syntactic sugar has been applied, e.g. (CASEQ q (item ...)) => (CASEQ q ((item) ...)). You did not address the most important point, the incompatibility introduced between interpreter and compiler. If I write (Defun foo (form) (if (atom form) form (caseq (car form) ((if) (if (foo (cadr form)) (foo (caddr form)) (foo (cadddr form)))) ((quote) (cadr form)) ((lambda) ..something..) (t (apply (foo (car form)) (mapcar #'foo (cdr form))))))) then it is clear what I am doing. If the car of the form is not EQ to one of '(IF QUOTE LAMBDA) then it gets handled by the T case. This includes forms like '((LAMBDA (X Y) ...) ....). I expect a simple syntactic transformation from that CASEQ, into (LET ((TEMP (CAR FORM))) (COND ((EQ TEMP 'IF) ...) ((EQ TEMP 'QUOTE) ...) ((EQ TEMP 'LAMBDA) ...) ('ELSE ...))) And this is what is does in the compiler! You had better have an INCREDIBLY good reason to give up the game here by writing a FEXPR for CASEQ which I can't seem to understand. -gjc  Date: 5 APR 1981 0502-EST From: JONL at MIT-MC (Jon L White) Subject: Why did STR:ARRAY somtimes go away To: (BUG LISP) at MIT-MC this guy should be marked in the TTS.GC bit whenever he is alive. True, GCMKAR assumes that one wants to descend him, but if the contents of the TTSAR doesn't get this one bit (TTS.GC) it will go away. Having some value point ot it will insure that it gets "marked", but it might be more reasonable to just have some code set the bit.