Date: 12 JAN 1981 0038-EST From: JAR at MIT-MC (Jonathan A. Rees) Subject: Twenex Midas FASL assembly To: (BUG LISP) at MIT-MC ... the FASL goes to FOO.FAS instead of FOO.FASL.  Date: 11 JAN 1981 2333-EST From: DCP at MIT-MC (David C. Plummer) Subject: I DON'T BELIEVE IT !!! To: (BUG LISP) at MIT-MC WEDGE WEDGE --- WARNING -- DON'T TRUST COMPLR (defun foo (n) (print (eval `(- ,n #/A -13))) (print (eval `(+ (- ,n #/A) 13))) (print (- n #/A -13)) (print (+ (- n #/A) 13))) Compile this, and load it into your favorite lisp (base 8. of course) (foo 101) 13 13 13 13 t (foo 102) 14 14 12 <======= look at this folks !!!!!!!!!!!!!!!!!!!! 14 t I DON'T BELIEVE IT !!! I MAY HAVE LOST FAITH !!  Date: 11 JAN 1981 2309-EST From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC Compiling the file Maxsrc;Ntrace 15 the function Mtrace-Option-P somehow gets the wrong Args property in the fasl file.  Date: 11 Jan 1981 2213-EST From: KMP at MIT-XX Subject: LOOP fasl is MPV;'ing To: BUG-LISP at MIT-MC cc: MARKT at MIT-XX LOOP FASL is giving a memory protection violation on XX now. It wasn't before. We probably broke it by importing new FASLs to XX this evening. This should be looked into. -kmp -------  Date: 11 JAN 1981 2212-EST From: JAR at MIT-MC (Jonathan A. Rees) Subject: Twenex WRITEABLEP To: (BUG LISP) at MIT-MC WRITEABLEP loses on Twenex, thus DEFMACRO loses, since MACROMEMO does a writeablep check. Also, shouldn't this be moved to LSPSRC; (currently on NILSIM;)?  Date: 11 January 1981 21:14-EST From: Robert W. Kerns Subject: GCing JOB arrays. To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC Date: 11 January 1981 20:51-EST From: Alan Bawden Subject: GCing JOB arrays. To: RWK at MIT-MC cc: ALAN at MIT-MC 1) Do we all at least agree that this is a bug? I hope so! 2) Since nobody really cares about HUMBLE, is this problem just going to be ignored? (That wouldn't upset me all that much, really.) Actually, I just fixed it in the source.  Date: 11 JAN 1981 1841-EST From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC How about a check to allow you to FUNCALL sfa's?  Date: 11 JAN 1981 1714-EST From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC I don't know whether I have reported this before: When the garbage collector discovers a garbage JOB array it seems to perform a .uclose on it causing an inferior job to go away. This is incorrect and annoying. It is incorrect because it is not the case that the job has become inaccessable just because it's superior has forgotten about it for the moment, you can connect to the SAME job with another JOB array later. It is annoying because it can cause jobs to vanish without anyone explicitly asking for it.  Date: 10 JAN 1981 1711-EST From: JAR at MIT-MC (Jonathan A. Rees) Subject: Twenex logical device confusion To: (BUG LISP) at MIT-MC CC: JAR at MIT-MC With a current directory of , and with LOGIN.CMD files existant on this directory and on and , and with the file X.START present on but not on , and with @define foo: , we get the following results when applying NAMELIST, NAMESTRING, and PROBEF to various arguments: Arg PROBEF |FOO:LOGIN.CMD| ((PS RLB) LOGIN CMD /2) ((FOO) LOGIN CMD) ((PS REES) LOGIN CMD /2) ;Choke! |FOO:X.START| NIL ;Barf! ((FOO) X START) NIL Arg NAMESTRING NAMELIST |FOO:LOGIN.CMD| PS:LOGIN.CMD ((PS RLB) LOGIN CMD *) ((FOO) LOGIN CMD) FOO:LOGIN.CMD ((FOO ||) LOGIN CMD *) |FOO:X.START| PS:X.START ((PS RLB) X START *) ((FOO) X START) FOO:X.START ((FOO ||) X START *) This is inexcuseable, there are so many bugs here. I hardly know where to begin. Poor maclisp just doesn't know anything about Twenex logical names and search conventions. Rather than try to figure out just what's wrong here, I'll give suggestions as to what I think the proper results ought to be: Arg PROBEF |FOO:LOGIN.CMD| ((PS RLB) LOGIN CMD /2) ((FOO) LOGIN CMD) ((PS RLB) LOGIN CMD /2) |FOO:X.START| ((PS RWK) X START /2) ((FOO) X START) ((PS RWK) X START /2) Arg NAMESTRING NAMELIST |FOO:LOGIN.CMD| FOO:LOGIN.CMD ((FOO) LOGIN CMD *) ;Or leave in the || ((FOO) LOGIN CMD) FOO:LOGIN.CMD ((FOO) LOGIN CMD *) ; if you prefer. |FOO:X.START| FOO:X.START ((FOO) X START *) ((FOO) X START) FOO:X.START ((FOO) X START *) P.s. I'm not on the BUG-LISP list, but I would appreciate getting CC'ed any replies. This is a real problem, about which I have had many complaints from the Yale users.  Date: 10 JAN 1981 0629-EST From: JONL at MIT-MC (Jon L White) Subject: Macro-Cache'ing a pure cell? To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC Date: 9 January 1981 04:00-EST From: Robert W. Kerns . . . I changed the case you ignored to conform to the way you changed the case I ignored. . . . I decided that MACROFETCH looking at the state of MACRO-EXPANSION-USE is really the wrong thing . . . There isn't any efficiency lost by doing this, since the check for the CDR of MACROMEMO being NIL is fast. Well, (apart from the incredible semantics of the 'changed' sentence!) your changes had (NOT (WRITEABLEP ...)) where you wanted merely (WRITEABLEP ...), so I changed that; also, my prior (less desirable) code there used PUREP (i.e., STATIC-AREAP) which had an AUTOLOAD property, but WRITEABLEP doesn't, so I've added that too. But more to the point, I disagree completely with your assumption above, that MACROFETCH should not look at the MACRO-EXPANSION-USE switch -- that's precisely why such a switch was invented. If one is in the MACROEXPANDED mode, then a non-writeable cell simply can't be cached this way, and there's no reason to switch modes automatically on the user; perhaps giving him a warning msg would be of interest, so that he could switch to MACROMEMO mode manually. Really, how important is it to optimize the rare case of MACROEXPANDED mode and non-writeable call cell? (remember, if a loser has lots of pure EXPR code, he must know what he is doing, and will be using MACROMEMO mode). In short, there's verrrry little, if anything, to be gained by trying to mix modes.  Date: 9 JAN 1981 1801-EST From: JONL at MIT-MC (Jon L White) Subject: MAKE-STRING To: DCP at MIT-MC CC: (BUG LISP) at MIT-MC Under *RSET mode, MAKE-STRING should be checking its argument for being a non-negative fixnum. I've edited in the change, and it will be appearant in STRING version 134 (hopefully installed tonite).  Date: 9 JAN 1981 1615-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC ALARMCLOCK could work on Twenex, couldn't it? Isn't there a TIMER jsys or something like that? There's something that Emacs' fsclkmacro uses with reasonable success. ALARMCLOCK seems to be ITS-only and that's kinda sad.  Date: 9 January 1981 15:37-EST From: Jonathan A. Rees To: GJC at MIT-MC cc: BUG-LISP at MIT-MC, LISP-FORUM at MIT-MC, NIL at MIT-MC Date: 21 October 1980 12:22-EDT You know what I could use many times? LABELS, ala SCHEME, however, what would suit me most of those times would be a simple extension to PROG, a GOSUB ala BASIC. Question: Is this a reasonable feature to have? Yes.  Date: 9 JAN 1981 1338-EST From: DCP at MIT-MC (David C. Plummer) Subject: STRINGS To: (BUG LISP) at MIT-MC :L n (make-string "foo") ;Loading STRING 133 ;Loading EXTEND 273 ;Loading EXTBAS 31 ;Loading EXTSTR 79 ;Loading MACAID 105 ;Loading DEFMAX 71 ;Loading EXTSFA 3 ;16315242042 ILLEGAL DIMENSION - *ARRAY ;BKPT WRNG-TYPE-ARG I'm surprised it said WRONG TYPE ARG, but *sigh* it was because of *ARRAY. After loading all those packages (*sigh*) you would think it would back out gracefully.  Date: 9 January 1981 04:00-EST From: Robert W. Kerns Subject: Macro-Cache'ing a pure cell? To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 8 January 1981 13:18-EST From: Jon L White Subject: Macro-Cache'ing a pure cell? To: RWK at MIT-MC cc: BUG-LISP at MIT-MC Date: 8 January 1981 13:09-EST From: Robert W. Kerns I think it SHOULD do caching (like I had it doing before) when it finds it is not writable, with the hashing scheme. . . Unfortunately, it didn't work. Just because one has ONE cell in pure space is no reason for the cacher to change the user's setting of MACRO-EXPANSION-USE from MACROEXPAND to MACROMEMO; you cannot use the hasharray unless this is done. Now maybe a warning msg is in order, but that is another story. You didn't change this part of the code at all, except to rename PUREP to STATIC-AREAP. You did change the code for the DISPLACE case (which I seem to have ignored) to PURCOPY before writing writeable pure code, and ignored the MACROEXPANDED case. I changed the case you ignored to conform to the way you changed the case I ignored. Anyway, I decided that MACROFETCH looking at the state of MACRO-EXPANSION-USE is really the wrong thing. If you have hash-memoized something, it should use that, just like if you have DISPLACED something. If you change the switch from MACROMEMO to MACROEXPANDED, and you want to no longer use the hashed definitions (why??), you can always flush the cache. But with the bookkeeping that goes on to handle redefinitions, there is no reason to insist on ignoring the cache just because the user requests that you no longer add to it. So it now just checks for the existance of a cache. There isn't any efficiency lost by doing this, since the check for the CDR of MACROMEMO being NIL is fast. It may still reasonable for MACROEXPANDED to restore the original form if it finds MACRO-EXPANSION-USE to be other than MACROEXPANDED, on the theory that the user changed it because he was grossed out. But that isn't essential, since again, the user can get that effect by just doing (FLUSH-MACROMEMOS () ()). So I changed MACROFETCH, but not MACROEXPANDED. I did not install this yet. Do you concur that this is reasonable?  Date: 8 JAN 1981 1540-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (SETQ A (OPEN "DSK:KMP;BUGGY BUGGY" 'OUT)) #FILE-... B ;B UNBOUND VARIABLE ;BKPT UNBND-VRBL (ERRPRINT NIL A)B T ----- The file gets ;UNBOUND VARIABLE printed into it. Presumably the B should be PRIN1'd into the file, not onto the terminal, so that the file had ;B UNBOUND VARIABLE in it. -kmp  Date: 8 January 1981 1502-EST (Thursday) From: Guy.Steele at CMU-10A To: kmp at MIT-MC, gjs at MIT-AI Subject: Re: ERRLIST: Does it really claim to do that? CC: bug-lisp at MIT-MC In-Reply-To: Kent M. Pitman's message of 8 Jan 81 14:01-EST Message-Id: <08Jan81 150239 GS70@CMU-10A> I believe the precise story is that the ERRLIST is evaluated *after* unwinding the bindings, but the list of forms to be evaluated is the value of the variable ERRLIST *before* the unwinding. That is, it "works" to lambda-bind ERRLIST. This is the purpose of the variable //, which is used as a buffer during this unwinding process.  Date: 8 January 1981 14:01-EST From: Kent M. Pitman Subject: ERRLIST: Does it really claim to do that? To: GJS at MIT-AI cc: BUG-LISP at MIT-AI Date: 31 December 1980 15:49-EST From: Gerald Jay Sussman To: BUG-LISP at MIT-AI LISP manual claims that ERRLIST is evaluated before dynamic variables are unwound. Unfortunately system doesn't see it the same way. ----- Where is that stated? As nearly as I can tell, the 1974 MacLisp Manual says The value of errlist is a list of forms which are evaluated when control returns to top level either because of an error or when an environment is initially started. This feature is used to provide self-starting LISP environments and to provide special error handling for subsystems written in LISP. which seems to imply that the evaluation is after unwind. My evolving Lisp manual, having stolen its documentation from the 74 manual, says the same. The Moonual doesn't document it anyplace that I see; neither does Touretzky's guide or even the LispM manual. So if there really is someplace that this guarantee is made, please let us know the document (there being many sources of documentation and none being very complete (alas)) and page number, etc. so that we can look into it. Thanks, -kmp  Date: 8 JAN 1981 1318-EST From: JONL at MIT-MC (Jon L White) Subject: Macro-Cache'ing a pure cell? To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC Date: 8 January 1981 13:09-EST From: Robert W. Kerns I think it SHOULD do caching (like I had it doing before) when it finds it is not writable, with the hashing scheme. . . Unfortunately, it didn't work. Just because one has ONE cell in pure space is no reason for the cacher to change the user's setting of MACRO-EXPANSION-USE from MACROEXPAND to MACROMEMO; you cannot use the hasharray unless this is done. Now maybe a warning msg is in order, but that is another story.  Date: 8 JAN 1981 1309-EST From: RWK at MIT-MC (Robert W. Kerns) To: JONL at MIT-MC CC: (BUG LISP) at MIT-MC I think it SHOULD do caching (like I had it doing before) when it finds it is not writable, with the hashing scheme. Certainly I did not forget that a page which is PUREP may or may not be writtablep. That should be obvious, since the bug I was complaining about was the GC problem.  Date: 8 JAN 1981 1308-EST From: JONL,KMP at MIT-MC Sent-by: JONL at MIT-MC Subject: DISPLACE To: (BUG LISP) at MIT-MC DISPLACE should error out if either 1) the cell it's trying to write into is read-only, or 2) the cell is in a static-area (i.e., a 'purep' area, but note yet made read-only), but the stuff to be placed into it is not static. Any comments?  Date: 8 JAN 1981 1306-EST From: jonl,kmp at MIT-MC Sent-by: JONL at MIT-MC Subject: New autoloadables? To: (BUG LISP) at MIT-MC We would like to see the following functions be autoloadable, from the MLMAC file, with SUBR properties in general, and MACRO properties in addition when loaded into a COMPLR: FIXNUMP, FLONUMP, EVENP, LISTP, LOGAND, LOGIOR, LOGXOR, LOGNOT Also, what would people think of having the following macros be autoloadable (i.e., would they conflict with your own macros/funs)? WHEN, UNLESS, DOLIST, DOTIMES  Date: 8 JAN 1981 1258-EST From: JONL at MIT-MC (Jon L White) Subject: 'WRITEABLEP' To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC You may have forgotten that a page which is PUREP, may or may not be WRITEABLEP. The correction to DEFMAX was to make this test, doing the PURCOPY and displace when it is writeable, and not doing any displace'ing when it isn't (i.e., doing no cache'ing).  Date: 8 JAN 1981 1236-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: 'WRITEABLEP' and macro-expansion-cache To: JONL at MIT-MC CC: (BUG LISP) at MIT-MC Actually, it is PUREP which MACROMEMO calls. Even if pure code is writable, you don't want to put pointers to impure code in it because it won't be GC protected. I hope you haven't changed it. Note that this is the right thing for MACROMEMO to do, independently of changing DISPLACE. MACROMEMO wants to do something else rather than just become a NOP in that case.  Date: 8 JAN 1981 1215-EST From: JONL at MIT-MC (Jon L White) Subject: PUREP/WRITEABLEP To: rpg at SU-AI CC: RWK at MIT-MC, (BUG LISP) at MIT-MC The best solution to the 'WRITEABLEP' problem is simply to add it to the initial system -- apparently the resolution of the macroexpansion-cache'ing problem was to have it call 'WRITEABLEP' rather than fix up DISPLACE. So I'm testing out now a new LISP (probably version 2063) with this code in it; you should edit in the sail-specific code into the *LISP file. Older ITS versions will just continue to load the PUREP.FASL file.  Date: 7 JAN 1981 1501-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: MACRO and EXPR properties To: ALAN at MIT-MC CC: KMP at MIT-MC, DICK at MIT-MC, (BUG LISP) at MIT-MC Actually, it IS often used in place of an optimizer property, to have a MACRO property after the EXPR property for MACROEXPAND to hack, even though the expr definition is the one to be actually RUN. This is a crock, but there is much code which depends on it, and changing MACROEXPAND would break this.  Date: 7 January 1981 03:12-EST From: Alan Bawden Subject: No, it's a bug. To: KMP at MIT-MC cc: DICK at MIT-MC, BUG-LISP at MIT-MC Date: 4 January 1981 20:05-EST From: Kent M. Pitman Date: 01/04/81 14:27:15 From: DICK at MIT-ML To: (BUG LISP) at MIT-ML There is a bug in macroexpand that is seen in the following scenario ... macroexpand uses a macro even if it is not the current functional property in force.... ----- This is a widely taken-advantage-of feature, actually. ... This is not the not-so-widely taken-advantage-of feature that I am familiar with, look again: (defun bar macro (body) (cons '1+ (cdr body))) BAR (defun bar (x) (+ x x)) BAR (bar 4) 8 (macroexpand '(bar 4)) (1+ 4) bar is defined as a macro first and THEN redefined to be an expr. Eval and apply will BOTH find the expr property, the function bar has been 100% redefined to be (lambda (x) (+ x x)). You may recall that defun (and defprop) go to a great deal of hair to move properties to the front of property lists so that such redefinitions work. Now there is this kludge where apply, mapxxx, funcall, etc. ignore a macro property in favor of one that can be applied, but that is a kludge in the language to fix a defficiency (at small expense, since nothing that otherwise works is effected), and it doesn't imply a general philosophy that macro properties must ALWAYS represent correct translations. You HAVE to be able to redefine a macro as an expr (with a possibly different definition) and have everybody agree on it. If you wish to make shadowed macro properties mean what you suggest, then defun had better start doing remprops of macro properties. This is a real bug in macroexpand, and it should be fixed.  Date: 5 JAN 1981 0305-EST From: GZ at MIT-MC (Gail Zacharias) Subject: Filemode of a closed file To: (BUG LISP) at MIT-MC There doesn't seem to be a way to get the open-specs (i.e. stuff like IN/OUT/APPEND, ASCII/FIXNUM, SINGLE/BLOCK) of a closed file. The stuff is obviously there since defaulting for re-opening uses it. As it is, I need to re-open the file to get this info, and this doesn't work right for a ">" type file opened in OUT mode (since the version number gets bumped by one upon re-opening)  Date: 4 January 1981 20:05-EST From: Kent M. Pitman Subject: That's not a bug, that's a feature! To: DICK at MIT-MC cc: BUG-LISP at MIT-MC Date: 01/04/81 14:27:15 From: DICK at MIT-ML To: (BUG LISP) at MIT-ML There is a bug in macroexpand that is seen in the following scenario ... macroexpand uses a macro even if it is not the current functional property in force.... ----- This is a widely taken-advantage-of feature, actually. Consider the case of an FSUBR definition of LET (for efficiency, stepping convenience, etc) shadowed by a MACRO definition (for the sake of program-understanding programs which would like to decompose a macro form into something more primitive and intelligible). In such a case, the FSUBR definition would want to shadow the MACRO definition, but both would want to be accessible. It is also the case that certain files like to do the equivalent of the following: (DEFUN FIRST (X) (CAR X)) ; In case FIRST gets MAP'd or APPLY'd (DEFUN FIRST MACRO (X) ; For compiler use (DISPLACE X `(CAR ,@(CDR X)))) where both a macro and an expr version are available at the same time and get used in different situations. Here the MACRO shadows the EXPR, but both are accessible at times. Moral: If you're going to have more than one definition on your functions, make them compatible. -kmp  DICK@MIT-ML 01/04/81 14:27:15 To: (BUG LISP) at MIT-ML There is a bug in macroexpand that is seen in the following scenario (defun bar macro (body) (cons '1+ (cdr body))) BAR (defun bar (x) (+ x x)) BAR (bar 4) 8 (macroexpand '(bar 4)) (1+ 4) macroexpand uses a macro even if it is not the current functional property in force. Dick Waters  Date: 31 December 1980 15:49-EST From: Gerald Jay Sussman To: BUG-LISP at MIT-AI LISP manual claims that ERRLIST is evaluated before dynamic variables are unwound. Unfortunately system doesn't see it the same way.  Date: 31 DEC 1980 1334-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: STRING BUG To: (BUG LISP) at MIT-MC To see the results of a string bug, load MC:LSPDMP;STRING BUG into a job, $G it, and if you then $P it you will be in the middle of a string-bug printout.  Date: 31 December 1980 05:40-EST From: Robert W. Kerns To: JPG at MIT-MC cc: BUG-COMPLR at MIT-MC, BUG-LISP at MIT-MC Date: 30 December 1980 06:14-EST From: Jeffrey P. Golden To: BUG-COMPLR at MIT-MC cc: JPG at MIT-MC Doing the following gives ;IMPROPER USE OF MACRO - EVAL : CL^K ^G (LOAD '|JPG;CHOMP|) (CHOMP) RWK looked at this a few days ago, and a likely theory is that the call to (INITIALIZE) is REMOBing something needed by the FORMAT package. Anyway something within the FORMAT package ends up pointing into the freelist, leading to the above error condition. I'm not 100% clear as to what is happening here, but it IS clear that symbols are getting bashed that have no right to be bashed. While looking at various SY2 blocks, I found one symbol with a PNAME that ended in IN0 instead of NIL! Other than that, I found a number of other symbols with PNAME's which pointed to things they shouldn't, all with the Compiled-Code-Needs-me bit set. My theory is that the GC collects symbols with SY.CCN set, if they're not pointed to by any obarray. I can't find anything to contradict this in the code. But there's nothing to say the compiled code in question isn't still referenced just because it references a symbol not on any obarray. Just for the record, the function referencing the symbol is FORMAT-FROBNICATE-LISP-OBJECT, the symbol bashed is FMT-FROB/|, and the error message is purest nonsense. If you APPLY the former FMT-FROB/| (it now looks something like |n v|), it complains about illegal use of a MACRO, while if you look at it's PLIST, it may be GUBBISH, but nowhere is there a MACRO property...)  Date: 31 December 1980 03:44-EST From: Robert W. Kerns Subject: &body To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC Date: 30 December 1980 21:51-EST From: Alan Bawden Subject: &body To: BUG-LISP at MIT-MC cc: ALAN at MIT-MC The LispMachine version of defmacro now supports an additional & keyword: &body. It has exactly the same effect as &rest as far as the defined macro is concerned. The difference is that in addition to defining the macro it outputs a form to tell Zwei how to indent instances of the macro. So that (defmacro frobify (var form frob &body body) ...) Tells Zwei to indent like: (frobify x (+ 3 z) *frob* (print x) (print y)) The idea is that body is declared to be a body (list of forms) and not just any old random list structure. Now it would be a little hard to have this work on ITS, but it would be nice if the ITS defmacro would at least accept the keyword &body in place of &rest. Can this be done please? Thank you. Done.  Date: 30 DEC 1980 2151-EST From: ALAN at MIT-MC (Alan Bawden) Subject: &body To: (BUG LISP) at MIT-MC CC: ALAN at MIT-MC The LispMachine version of defmacro now supports an additional & keyword: &body. It has exactly the same effect as &rest as far as the defined macro is concerned. The difference is that in addition to defining the macro it outputs a form to tell Zwei how to indent instances of the macro. So that (defmacro frobify (var form frob &body body) ...) Tells Zwei to indent like: (frobify x (+ 3 z) *frob* (print x) (print y)) The idea is that body is declared to be a body (list of forms) and not just any old random list structure. Now it would be a little hard to have this work on ITS, but it would be nice if the ITS defmacro would at least accept the keyword &body in place of &rest. Can this be done please? Thank you.  Date: 29 DEC 1980 2354-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: EVAL-THE-ARGS-BEFORE-THE-FUNCTION STRIKES AGAIN To: (BUG LISP) at MIT-MC Well, folks, I got it again, the infamous screw where the argument is evaluated before the function. Sometimes doing an FEVAL on the function can side-effect on the arguments, like when you have an AUTOLOAD property on the function, and the file sets up one of the arguments to the function being called. Fortunately, NIL will do this right. I just spent a half-hour scratching my head why this bug only happened the first time, but not when I'd re-try it, or trace the function in question, etc.....  Date: 29 December 1980 22:22-EST From: George J. Carrette Subject: DISPLACE To: KMP at MIT-MC cc: BUG-LISP at MIT-MC, ALAN at MIT-MC, RWK at MIT-MC Ho, hum. Just the other day WGD wanted a list-displace (defun displace (x y) (if (or (atom x)(atom y)) (error) %%%repla*%%%%)) I think it is simpleminded, and quite outdated to be "snarfing" or "using" what should be the names of possibly generic systemic data-struture primitives for semantic evaluation purposes. Use of SUBST for "substitution" macros truly is the classic example. (1) semanticaly incorrect in many cases. (2) multiple-evaluation brain-damage. Shouldn't displace work on vectors, hunks, arrays, structures? Does the PROGN hack really make sense for those other cases? How many calls to the evaluation-semantic displace does one have in a given lisp system anyway? One or two? I say the definition of this displace should be in the EVALUATOR Package. EVALUATOR:DISPLACE. I'm suprised at the people who have said that "THE" use of displace has been in macros (i.e. extending the evaluator or handing the EVAL message). Big irrelevent deal! What about the people working on algebra systems, or data-basis, or natural language parsers? They don't call EVAL, why should "EVAL" call their displace. Remember the 9'th commandment of systems programing, (we should ask JM to post these, har har): *XI* Thou Shalt Not Covet Thy Users Namespace. -gjc  Date: 29 DEC 1980 2202-EST From: JONL at MIT-MC (Jon L White) Subject: Sub-jobs, and bi-directional i/o. To: Leonard.Zubkoff at CMU-10A, Dave.Touretzky at CMU-10A CC: (BUG LISP) at MIT-MC Date: 26 December 1980 2158-EST (Friday) From: Leonard.Zubkoff at CMU-10A (C410LZ60) Subject: PTYs in LISP Message-Id: <26Dec80 215856 LZ60@CMU-10A> I have been trying to open a PTY for both input and output in order to control a subjob from LISP on CMU-20C (TOPS-20) with no success. I receive an invalid simultaneous access error whenever I try this. Is there a way to control a sub job through PTYs in LISP on the 20? Thanks. - - - - Date: 26 December 1980 2300-EST From: Dave Touretzky at CMU-10A Why bother? Since you're running on the 20, wouldn't the SUBFORK package do what you needed? MacLisp i/o seems to be somewhat wedged in that you cannot do input and output through the same file object (as far as I know.) This means that you can't open a random access file for "update", i.e. read followed by write. Perhaps the same lossage is responsible for your PTY difficulties. True, a subforking would be much better than a PTY. However, one could use a SFA to combind two file-arrays into one file-like object (the sfa) thru which you could do bi-directional i/o. See the example in the file MC:LSPSRC;YESNOP > -- the function QUERY-IO-HANDLER is the sfa function which is set up later in the file (look for the usage of sfa-create).  Date: 29 DEC 1980 2101-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: DISPLACE To: RWK at MIT-MC, ALAN at MIT-MC, (BUG LISP) at MIT-MC CC: GJC at MIT-MC I recognize that there exists code which will be screwed by not checking purity and that there may also exist code which will be screwed up by the check. ALAN: are you doing explicit displace calls or calling defmacro with displace optin requested? Is the functin REPLACE in use all over? Probably, huh? That would be a fine name for the functin I want. I would still prefer that operators which operate in a code-oriented manner rather than a list-oriented manner be named to identify that. Eg, a code-subst functin would be more usful than a subst functin like we have right now but throwing out the simple semantics for the simple operator is unfair. .. i don't know. many hard decisions. i guess we should do something that will move toward compatibility with lispm. how heavily is displace used on lispm. ..? can we postpone doing anything drastic until i return to a terminal where i can compose my thoughts reasonably ? tnx  Date: 29 DEC 1980 2016-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: Purity and DISPLACE To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC In actual fact, I got disgusted enough to do something about it already. MACROMEMO checks before clobbering, and does a hash-style memoizing instead of a displace-style memoizing instead if the arg is pure. For this purpose this is superior to DISPLACE doing the checking and punting, since the macro doesn't get re-expanded. However, I agree that DISPLACE would be more useful if it checked. KMP, as you recall, would disagree.  Date: 29 December 1980 20:12-EST From: Alan Bawden Subject: PUREP and MACROMEMO To: RWK at MIT-MC, BUG-LISP at MIT-MC Date: 15 December 1980 10:02-EST From: Robert W. Kerns For the Nth time tonight, I have been shafted by macros which expand into code including other macro calls which want to displace. If part of the expansion of a macro is constant, then that expansion will be pure. If that pure portion also contains a call to a macro which wishes to displace, you lose your ass. Let's DO something about this! Allow me to revive the suggestion that DISPLACE should check for the purity of its first argument and not rplac in that case.  Date: 29 December 1980 1646-EST (Monday) From: Guy.Steele at CMU-10A To: WGD at MIT-MC (William G. Dubuque) Subject: Lost typeahead CC: bug-lisp at MIT-MC In-Reply-To: WGD@MIT-MC's message of 28 Dec 80 17:58-EST Message-Id: <29Dec80 164653 GS70@CMU-10A> WGD's bug is obviously yet another manifestation of the TYIPEEK/READ interaction bug that has huanted us, lo, these last five years. (The MORE processor does a TYIPEEK.)  Date: 29 December 1980 1643-EST (Monday) From: Guy.Steele at CMU-10A To: REM at MIT-MC (Robert Elton Maas) Subject: Re: Array allocation loses CC: bug-lisp at MIT-MC In-Reply-To: REM@MIT-MC's message of 26 Dec 80 05:46-EST Message-Id: <29Dec80 164329 GS70@CMU-10A> Have you tried HUNKs instead of arrays?  Date: 29 DEC 1980 1438-EST From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC LEXPR-SEND and LEXPR-SEND-AS should be added to that list.  Date: 29 DEC 1980 1438-EST From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC SEND-AS has no AUTOLOAD property, while SEND does.  Date: 28 Dec 1980 1525-PST From: Scott J. Kramer Subject: Tenex MacLisp To: Bug-Lisp at MIT-MC On Tenex, typing echoes '^_'. We're trying to bring up MacLisp on our Foonly and this lossage is unacceptable. How can I fix it? Thanx. -sjk -------  Date: 28 DEC 1980 1758-EST From: WGD at MIT-MC (William G. Dubuque) Sent-by: BIL at MIT-MC To: (BUG LISP) at MIT-MC The first character of any typeahead that occurs while something is printed is lost in a ^L redisplay, e.g. get a more break while something is being printed, type 12, and then do a ^L when the printing is finished--- only the 2 is displayed while the 1 is actually still buffered.  Date: 26 December 1980 2300-EST From: Dave Touretzky at CMU-10A To: Leonard.Zubkoff at CMU-10A (C410LZ60) Subject: Re: PTYs in LISP CC: bug-lisp at MIT-MC In-Reply-To: <26Dec80 215856 LZ60@CMU-10A> Why bother? Since you're running on the 20, wouldn't the SUBFORK package do what you needed? MacLisp i/o seems to be somewhat wedged in that you cannot do input and output through the same file object (as far as I know.) This means that you can't open a random access file for "update", i.e. read followed by write. Perhaps the same lossage is responsible for your PTY difficulties.  Date: 26 December 1980 2158-EST (Friday) From: Leonard.Zubkoff at CMU-10A (C410LZ60) To: bug-lisp at MIT-AI Subject: PTYs in LISP Message-Id: <26Dec80 215856 LZ60@CMU-10A> I have been trying to open a PTY for both input and output in order to control a subjob from LISP on CMU-20C (TOPS-20) with no success. I receive an invalid simultaneous access error whenever I try this. Is there a way to control a sub job through PTYs in LISP on the 20? Thanks. Leonard  Date: 26 DEC 1980 1817-EST From: RLB at MIT-MC (Richard L. Bryan) Subject: Printing EXTENDs To: (BUG LISP) at MIT-MC Maclisp should bite the proverbial bullet and rename PRINT methods to use :PRINT-SELF  Date: 26 DEC 1980 0546-EST From: REM at MIT-MC (Robert Elton Maas) Subject: Array allocation loses To: (BUG LISP) at MIT-MC I have an application which will need to allocate a large number (thousands) of little chunks of FIXNUMs, like FIXNUM ARRAYs of upper bound appx 10. I find that allocation of FIXNUMs is extremely slow. I made a test loop that simply pushed a lot of similar objects onto a stack (list) and measured the time it took to do a thousand of them. Scaled down to small numbers so you can understand them, here are the results. Form evaluated to give value pushed Time taken (octal) net time NIL 11 0 1 11 0 (SETQ N (ADD1 N)) in FIXNUM range 13 2 (SETQ N (ADD1 N)) in BIGNUM range 15 4 (MAKNAM '(A S D F)) 15 4 (INTERN (MAKNAM '(A S D F))) 20 9 (ARRAY NIL FIXNUM 2) 664 653 Thus it seems to take about a hundred times as long to allocate a new two-word FIXNUM array as it does to allocate a new FIXNUM or BIGNUM. Is there any efficient way to allocate small array-like bunches of FIXNUMs in MacLISP? Since ARRAYs lose so badly I'm thinking of kludging something up with PNAMEs, or just using LISTs of FIXNUMs. Any better ideas?  Date: 24 DEC 1980 1403-EST From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC Could someone please update .INFO.;LISP SHARPM to describe #% ? Thanks.  Date: 23 DEC 1980 1736-EST From: JONL at MIT-MC (Jon L White) Subject: |`,/|| and GRINDEF To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC Date: 15 DEC 1980 0503-EST From: RWK at MIT-MC (Robert W. Kerns) The comma marker is no longer hacked properly by GRINDEF. This may be related to the removal of it's MACRO property, although I can't see how. Fixed now in BACK version 50. (removal of the MACRO property introduced a typo which also removed the GRINDMACRO property).  Date: 23 DEC 1980 1706-EST From: JONL at MIT-MC (Jon L White) Subject: LISP;LOCK > To: WJL at MIT-ML CC: (BUG LISP) at MIT-MC WJL@MIT-ML 12/15/80 14:38:57 Would it be possible to notify the owners of files listed in lisp;lock before the xlisp is deleted? 2054 went away and my current versions of owldig and comdig used it. It is the intention of the LISP;LOCK file that the "locked" lisps don't go away unless all the files depending upon them have already gone away -- possibly there was a typo error which caused a "worthy" dump to go away?  Date: 23 DEC 1980 1700-EST From: JONL at MIT-MC (Jon L White) Subject: GENTEMP To: RWK at MIT-MC, RLB at MIT-MC CC: (BUG LISP) at MIT-MC I've put some more "patch-up" putprops for GENTEMP -- basically, in most files in whilch there is a usage of GENTEMP or SI:GEN-LOCAL-VAR, there should be #+FM (OR (GET 'GENTEMP '(LSUBR AUTOLOAD)) (DEFPROP GENTEMP #.(lispdir MACAID) AUTOLOAD)) at least until old lisps which don't have an autoload property for GENTEMP die out. I think STRING doesn't need it, but VECTOR and DEFVSX do. probably more.  Date: 23 DEC 1980 1559-EST From: JONL at MIT-MC (Jon L White) Subject: MAKE-LIST To: BMT at MIT-MC CC: NIL-I at MIT-MC, (BUG LISP) at MIT-MC You are the one most concerned with extending MAKE-LIST -- I see now that the LISPM community has converged upon some format. Is that format acceptable? If so, then likely the MacLISP world will have to switch MAKE-LIST over to an LSUBR, which would take so much "patching" that it may require a reassembly of LISP. Since NIL and MacLISP don't have "areas", I presume the only legal formats shuld be (MAKE-LIST ) and (MAKE-LIST ':INITIAL-VALUE )  Date: 23 DEC 1980 1552-EST From: JONL at MIT-MC (Jon L White) Subject: CGOL bugging out in new MACLISP To: TFT at MIT-AI CC: (BUG LISP) at MIT-MC, pratt at MIT-AI TFT@MIT-AI 12/17/80 19:30:40 I was trying to run some CGOL code for the first time in a while, and got a "wrong number of args to a macro" error for CATCH. . . . You shouldn't be getting CATCH's out of CGOL -- was it your own code, or is there some macro in CGOL which produces CATCH's? If the latter, then CGOL should definitely be updated and recompiled. At any rate, I fixed up the current "patch" for CATCH to allow the one-argument format. In the meantime, though, could you please tell me how I can load up an old MACLISP so that I can run CGOL? OLISP^K always gets you a modestly-previous version of LISP -- OOLISP^K gets the one previous to that.  Date: 23 DEC 1980 1116-EST From: JONL at MIT-MC (Jon L White) Subject: VECTORs To: WGD at MIT-MC CC: (BUG LISP) at MIT-MC Date: 20 December 1980 11:26-EST From: William G. Dubuque Any use of dovector results in a call to the undefined GENTEMP. Debugging VECTOR isn't too easy either, since MAKE-VECTOR recurses infinitely when loaded interpretively. Ok, I've put in #% in the places where the compiler would macroexpand the apparently-self-referential calls; but still you can use these kinds of packages interpretively only in the compiler.  Date: 22 December 1980 16:55-EST From: Gerald Jay Sussman To: BUG-LISP at MIT-AI Why the hell is the third argument to ERROR (eg. 'fail-act) tested for eq-ness? Seems to me that one could just execute the symeval of the handler, invalidating no current code, and allowing a user to define his own error handlers without screwing up system handlers.  Date: 20 December 1980 13:32-EST From: Robert W. Kerns Subject: sfa error checking To: GZ at MIT-MC cc: BUG-LISP at MIT-MC Date: 20 December 1980 08:48-EST From: Gail Zacharias Subject: sfa error checking To: BUG-LISP at MIT-MC Consider the following session: (defun nothin N '()) NOTHIN (setq test (sfa-create (function nothin) 17. 'testing)) #SFA-|TESTING|-70766 (open test) NIL (close test) NIL (deletef test) NIL (filepos test 13.) NIL (sfa-call test (function untyi) ()) NIL (tyo 3 test) T (out test 2) NIL (force-output test) NIL (prin1 1 test) T (princ 'a test) T (print 'foo test) T (cursorpos test) NIL (in test) ;; Well, at least this one errs out ;NIL NON-FIXNUM VALUE Do I have to define all these operations just to have them err out? TYI is the only one that actually complains that it is not supported. Since there is in fact an infinite variety of messages which you can send, you're expected to do your own error checking. You don't have to define ANYTHING to give an error message! Normally handlers for SFA's are CASEQ's over the message names, and the T clause is normally a call to CERROR. This isn't to say that LISP couldn't be doing it's own checking in *RSET T mode for LISP's internal operations, but there is nothing wrong with writing an explict (SFA-CALL SFA 'TYO 5), and you should be giving an error message for this, since you're not returning to in response to WHICH-OPERATIONS. BTW, the reason (IN TEST) errored out is just that NIL isn't a valid thing to return from an IN operation.  Date: 20 DEC 1980 1126-EST From: WGD at MIT-MC (William G. Dubuque) Sent-by: BIL at MIT-MC To: (BUG LISP) at MIT-MC Any use of dovector results in a call to the undefined GENTEMP. Debugging VECTOR isn't too easy either, since MAKE-VECTOR recurses infinitely when loaded interpretively.  Date: 20 DEC 1980 0848-EST From: GZ at MIT-MC (Gail Zacharias) Subject: sfa error checking To: (BUG LISP) at MIT-MC Consider the following session: (defun nothin N '()) NOTHIN (setq test (sfa-create (function nothin) 17. 'testing)) #SFA-|TESTING|-70766 (open test) NIL (close test) NIL (deletef test) NIL (filepos test 13.) NIL (sfa-call test (function untyi) ()) NIL (tyo 3 test) T (out test 2) NIL (force-output test) NIL (prin1 1 test) T (princ 'a test) T (print 'foo test) T (cursorpos test) NIL (in test) ;; Well, at least this one errs out ;NIL NON-FIXNUM VALUE Do I have to define all these operations just to have them err out? TYI is the only one that actually complains that it is not supported.  Date: 19 December 1980 20:03-EST From: Robert W. Kerns Subject: [dlw: MAKE-LIST] To: BUG-LISP at MIT-MC Date: 17 December 1980 17:10-EST From: Daniel L. Weinreb Sender: dlw at CADR7 at MIT-AI To: RWK, BUG-LISPM Re: MAKE-LIST Yes, we are going to fix make-list (and make-array) to accept winning argument format as well as old losing argument format. They both use a keyword syntax; the size of the list is the first, required argument, and everything else is by keyword. See AI: DLW; MAKE >; these changes will be installed in a new system sometime (they need some microcode support), I hope in system 54.  Date: 19 December 1980 20:03-EST From: Robert W. Kerns Subject: [MOON: MAKE-LIST] To: BUG-LISP at MIT-MC Date: 17 December 1980 16:28-EST From: David A. Moon Subject: MAKE-LIST To: RWK at MIT-MC cc: BUG-LISPM at MIT-MC RWK@MIT-MC 12/17/80 04:51:40 Re: MAKE-LIST To: (BUG LISPM) at MIT-MC In System 51.17, ZMail 6.4, Macsyma 4.0, microcode 707, on Lisp Machine Fifteen: Are you people planning on changing MAKE-LIST to take args like (COUNT &OPTIONAL WHAT-TO-PUT-IN-THE-CARs)? No, actually we're planning on changing MAKE-LIST and MAKE-ARRAY to take keyword arguments, except for the first argument which would be the length. Only reason it hasn't been done already is that it requires a coordinated system and microcode change.  Date: 19 DEC 1980 1420-EST From: KMP,WGD at MIT-MC Sent-by: KMP at MIT-MC To: (BUG LISP) at MIT-MC CC: WGD at MIT-MC It's about time we introduced COPY and COPYLIST into Maclisp as autoloading macros doing (SUBST NIL NIL x) and (APPEND x NIL), respectively. Any objections? If not, we should ask LISP-FORUM about the exact naming. LispM doesn't have a COPY function yet -- they already use COPYLIST and I think that is a reasonable name. I think we should push for having COPY do the full copy, but CWH says they may have chosen a different name, in which case we should adopt that name.  Date: 19 DEC 1980 1313-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: FBOUNDP To: JPG at MIT-MC CC: (BUG LISP) at MIT-MC Was HRRZ instead of MOVEI to load an AC with the list of props. Fixed and patched.  Date: 19 DEC 1980 0503-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC (DEFUN F (X) X) (FBOUNDP 'F) says NIL. I assume this is a bug, because it differs from the way it has worked in the past.  Date: 19 DEC 1980 0313-EST From: WGD at MIT-MC (William G. Dubuque) Sent-by: BIL at MIT-MC To: (BUG LISP) at MIT-MC (defun foo (l) (do ((ll l (cdr ll))) ((null ll)) (unless (bar ll) (return ())))) On compilation gives the classic ;%%%%% COMPILER ERROR - PLEASE CALL JONL %%%%%  Date: 19 DEC 1980 0204-EST From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC (pnget (ascii 0) 6) gives: PURPG; 15622>>HRRM 2,(1) 2/ 0 723352/ ADJSP 17,@(16) :walend  Date: 18 DEC 1980 2338-EST From: DLW at MIT-MC (Daniel L. Weinreb) To: (BUG LISP) at MIT-MC If you do :L, and then type ^Z followed by alt-P (before answering the ALLOC question), you get a BADPI. I think this means that Lisp's ionterrupt table is in a bad state at that time.  Date: 17 DEC 1980 2133-EST From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC JONL!!!!! CATCH does not work as documented in the MC:LSPMAN;MANUAL ASCII. If used with only one argument it should be (*CATCH NIL ) catching all throws. I am suprised you didn't catch this case, because it is obviously the reason CATCH was implemented in the losing way it was, to make it convenient (more convenient even!) to catch all throws than to just catch one. You should have had CATCH of one arg print out a stern lecture about how losing it was to catch all throws in that way, however, its still nice to be able to run old code, (in this case Pratt's). This is the kind of gratuitous lossage which we can do without. Just running RWK's (describe CATCH) would have been a nice thing to do before writing the CATCH macro. -gjc p.s. Its "nice" to be able to run old code so that one can get test examples and see how it should work, before one converts it for e.g. the lisp-machine.  Date: 16 December 1980 20:51-EST From: Robert W. Kerns Subject: Definate bug in complr To: BUG-MACLISP at MIT-MC cc: HARRIS at MIT-EECS See RWK;HARRIS BUG. As you can see, she is defining a function SORT of one argument. Despite this conflict with LISP's SORT function, COMPLR fails to do give the right error message (claims 'has been used before with the wrong number of arguments', instead of 'redefining system function') and it then ignores the ARGS-INFO property in favor of the FUNTYPE property, thus leading it to breakpoint complaining of the wrong-number of arguments when it finally IS used. I have suggested to HARRIS that she call her function something else.  Date: 16 DEC 1980 1748-EST From: MOON5 at MIT-MC (David A. Moon) To: (BUG LISP) at MIT-MC CC: gsb at MIT-ML l^K n (format t "~F" 1.2) gives an error. Obviously something is inconsistently installed  Date: 16 DEC 1980 1116-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: Closed-compiled MAP bug fixed. To: REM at MIT-MC, GZ at MIT-MC, GJC at MIT-MC, JPG at MIT-MC To: RLB at MIT-MC, ASB at MIT-MC, (BUG LISP) at MIT-MC To: (BUG COMPLR) at MIT-MC Yup.  Date: 16 December 1980 10:31-EST From: Robert W. Kerns To: GJC at MIT-MC cc: BUG-LISP at MIT-MC, BUG-COMPLR at MIT-MC, JPG at MIT-MC, RLB at MIT-MC, ASB at MIT-MC Date: 15 December 1980 15:13-EST From: George J. Carrette To: BUG-LISP at MIT-MC CL^K ^B (DB) (DEFUN FOO (L) (MAPCAR #'(LAMBDA (X) (CONS X 'FOO)) L)) (CL FOO) (COMMENT **** (L) Bound variable used as Function name in function FOO) (COMMENT **** (L) Unused LAMBDA variables in function FOO) ; the code produced looks ok though. FOO JONL!!!!!!! Actually, this particular bug is mine. However, it is better than the sneakier bug that JONL had that I was fixing (before, without telling you it was losing, it stepped by (CDR 'T) instead of CDRing down the list...). Unfortunately I had to leave so I couldn't test 100%, but it was working better than before. I can't believe the 10 or so files I compiled didn't show this up though. Sigh. I'll fix it now. Any code compiled between 12/14 21:53 and 12/16 2:42 with any mappers in it should be recompiled.  Date: 15 DEC 1980 1513-EST From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC CL^K ^B (DB) (DEFUN FOO (L) (MAPCAR #'(LAMBDA (X) (CONS X 'FOO)) L)) (CL FOO) (COMMENT **** (L) Bound variable used as Function name in function FOO) (COMMENT **** (L) Unused LAMBDA variables in function FOO) ; the code produced looks ok though. FOO JONL!!!!!!!  WJL@MIT-ML 12/15/80 14:38:57 To: (BUG LISP) at MIT-ML Would it be possible to notify the owners of files listed in lisp;lock before the xlisp is deleted? 2054 went away and my current versions of owldig and comdig used it.  Date: 15 DEC 1980 1323-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: MAP expansion fixed To: (BUG COMPLR) at MIT-MC CC: (BUG LISP) at MIT-MC P1MAP was the culprit, due to JONL getting confused when converting an SI:GEN-LOCAL-VAR back to a LOCAL-VAR call, and not preserving the implicit SETQ involved. However, in order to understand this function enough to find where it was happening, I had to re-arrange this function, LETifying it, etc. I'm pretty sure my change is functionally equivalent, minus the reported bug. I recompiled EXTEND; I'll look for other things that may need recompiling.  Date: 15 DEC 1980 1151-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: MAP expansion broken To: (BUG COMPLR) at MIT-MC CC: (BUG LISP) at MIT-MC WHICH-OPERATIONS is busted because the compiler compiled it (and a few other functions in the file EXTEND) incorrectly. I don't know what's going on here, but a (HRRZ 1 'T) is being output, apparently where the map variable should be being stepped. Needless to say, this leads to endless hacking of T's PLIST (which is non-null if you have FORMAT loaded). This seems to happen with any expansion of MAPC!  Date: 15 DEC 1980 1027-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: (OPEN '|TTY:| '(IN TTY)) To: (BUG LISP) at MIT-MC CC: REM at MIT-MC This resets the TTYST1 and TTYST2 words. This is obscene interference with the programmer. If the programmer is hacking the TTY modes, LISP should have the decency to leave them alone.  Date: 15 DEC 1980 1002-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: PUREP and MACROMEMO To: (BUG LISP) at MIT-MC For the Nth time tonight, I have been shafted by macros which expand into code including other macro calls which want to displace. If part of the expansion of a macro is constant, then that expansion will be pure. If that pure portion also contains a call to a macro which wishes to displace, you lose your ass. Let's DO something about this!  Date: 15 DEC 1980 0556-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: TAGS file for 'extended LISP' To: (BUG LISP) at MIT-MC There is now a TAGS file for the software on LSPSRC; and NILCOM;. It is LSPSRC;ELISP TAGS (ELISP for Extended LISP). A link exists on NILCOM; for the forgetful.  Date: 15 DEC 1980 0522-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: GC/EVAL bug To: (BUG LISP) at MIT-MC (defun (foo macro) (()) (let ((sym (gensym))) `((lambda (,sym) (print ,sym) (gc)) 6))) (*rset () ) ;So no EVALFRAMEs (GC) ;To make the only garbage what we're about to cons (FOO) 6 NIL ^Z FFVC/ & (NIL . UNBOUND) What is going on is this: The GC does not mark symbols who's value cells are on the SPECPDL. Neither does applying a LAMBDA with *RSET set to () save the lambda or binding-list on the REGPDL. And PROGN evaluation doesn't save old clauses, either, so when you get to the GC, there isn't anybody pointing to the gensym anymore. It gets collected. Later, we unbind the SPECPDL, and viola!, the freelist is bashed. The next SETQ of a symbol without a value cell will result in the symbol UNBOUND being bashed. Lossage will propogate. I don't feel up to figuring out the LAMBDA application code right now to fix this. The right fix, of course, is for the GC to protect symbols pointed to by the SPECPDL, but I guess this isn't feasible. Second choice is to make lambda-binding keep a copy of the LAMBDA list on the stack until after the UNBIND.  Date: 15 DEC 1980 0503-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: |`,/|| and GRINDEF To: (BUG LISP) at MIT-MC The comma marker is no longer hacked properly by GRINDEF. This may be related to the removal of it's MACRO property, although I can't see how.  Date: 15 December 1980 02:11-EST From: Glenn S. Burke Sender: GSB0 at MIT-ML Subject: More PURE and PUTPROP lossage To: BUG-LISP at MIT-MC Probably the entire macrofetch/macrowhatever stuff should be designed to use the hash table in spite of you if the stuff is pure. This lossage occurs in other situations, eg in macros which produce code using backquote and the list structure gets purified.  Date: 15 DEC 1980 0135-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: More PURE and PUTPROP lossage To: (BUG LISP) at MIT-MC If EXPR appears on PUTPROP, and you have, say a form with a LET, and you haven't done a PURIFY yet, then the LET will displace the supposedly PURE code with freshly-CONSed IMPURE code, and you lose. Should DISPLACE or MACROMEMO or whatever first do a PUREP check?  GSB@MIT-ML 12/15/80 00:55:08 To: (BUG LISP) at MIT-ML ALPHALESSP seems to lose in some cases on NIL. I have not found explicit cases where it has lost, but i have found two manifestations of it with SORT, one where the predicate is ALPHALESSP and the other with a predicate of a composition of ALPHALESSPs. In the latter it is sorting namelists, and the files with FN1 of NIL come out first in the listing; in the other i was testing some mapatoms variants, and one of the lists i generated sorted incorrectly; removing the NIL from it made it resort correctly. In neither of these cases was there a (status usrhnk).  GSB@MIT-ML 12/14/80 23:43:45 Re: print methods To: (BUG LISP) at MIT-ML Bob is right, LISP is totally wrong. The "stream" which should be passed in is NIL. When the internal print guy (PRNARG?) "parses" the stream, doesn't he set a bit in the left half saying that the tty is included? My understanding of this bug was that with ^R and OUTFILES, this is what was happening, and that bit was being ignored when that arg was being passed in. Couldn't you see if that bit was set and if so just pass in NIL? It only gets set for the "NIL" stream case anyway, right?  Date: 14 DEC 1980 2310-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: Print methods To: (BUG LISP) at MIT-MC I claim the print methods are correct, and LISP is wrong. I.e. LISP should be only calling the PRINT methods with the actual files to be printed on; that decoding should be done prior to sending the message.  Date: 14 DEC 1980 2306-EST From: JONL at MIT-MC (Jon L White) Subject: Printing of 'extend' objects To: csd.grinberg at SU-SCORE CC: (BUG LISP) at MIT-MC The following is a real bug, in the print methods of various EXTEND type objects (strings, vectors, structs etc); I've fixed it (albeit in a somewhat kludgy way) in all the software on the ITS systems, but you may not get the advantage of this "fix" until the next Twenex MacLISP distribution takes place (probalby in first week of January). [but if you're real hard up, bug me again, and I'll see what can be FTP'd to SCORE before then] Date: 13 Dec 1980 2133-PST From: CSD.GRINBERG at SU-SCORE Subject: maclisp problem I am having a problem with the PRINC command using the string package. When I do the following command. The output to the terminal does not occur for a string argument to PRINC. (SETQ outfile (list (open '(junk junk) '(out ascii)))) (setq ^R t) (princ "string") The write to the file occurs properly. However the terminal just returns T (the value of the function call). For both symbols and numbers, it seems to work properly. The loss is due to the fact that MacLISP's built-in print routines make a distinction between (PRINx ) and (PRINx ). The ^R switch is supposed to affect only the former format; but the way PRINT messages are generated, and the way these print methods were written, (and there doesn't seem much hope of changing these things now, except for my "kludgy" fix), they always use the latter format. My "kludgy" fix is a function now in EXTEND file (DEFUN SI:NORMALIZE-STREAM (STREAM) (IF (AND STREAM (AND ^R (NULL ^W)) (PAIRP STREAM) (NOT (MEMQ 'T STREAM)) (NOT (MEMQ TYO STREAM))) (CONS 'T STREAM) STREAM)) which is called by the various print methods.  Date: 13 DEC 1980 2330-EST From: JONL at MIT-MC (Jon L White) Subject: PUTPROP twice PURCOPY bug? To: RLB at MIT-MC, RWK at MIT-MC CC: (BUG LISP) at MIT-MC I may have fixed it -- certainly tried patching things, and editing. Caution.  Date: 13 DEC 1980 1411-EST From: GJC at MIT-MC (George J. Carrette) Subject: Linkage assumptions. To: (BUG LISP) at MIT-MC (1) When the compiler assumes FOO as *EXPR, and then finds out FOO is *LEXPR it barfs, failing to compile the function it was working on, even though the code would still run. (2) At uuolinks snap time, (or Fasload), when the system finds that FOO which was assumed *EXPR in a given place is actually *LEXPR it provides no messages. These two things work together to make it difficult to compile all of macsyma in the same environment on MC. In other words one has to go out of his way to track these things down, and can't just find out about them and fix them in a painless incremental way. How much trouble would it be to provide a switch in complr to prevent "(1)". How much trouble to provide some kind of UUOLINKS daemon solve "(2)"? The fact that it has been difficult/impossible in practice, to compile all of macsyma in the same environment on MC has made it more difficult to transport the code. Which is the only reason I'd mention this. -gjc  Date: 12 Dec 1980 2253-PST Sender: SCOTT at SRI-KL From: Scott J. Kramer Subject: Re: JCL to Maclisp on Twenex To: KMP at MIT-EECS, BUG-LISP at MIT-MC cc: LS.JALEX at MIT-EECS, LS.WJN at MIT-EECS In-Reply-To: Your message of 12-Dec-80 1800-PST The code for this hasn't been fully debugged yet so you're using a Lisp which doesn't try to do what you hoped for. -sjk -------  Date: 12 Dec 1980 2100-EST From: KMP at MIT-EECS Subject: JCL to Maclisp on Twenex To: BUG-LISP at MIT-MC cc: LS.JALEX at MIT-EECS, LS.WJN at MIT-EECS On TWENEX, saying MACLISP FOO.BAR at the monitor does not start a Maclisp and run the init file FOO.BAR ... could we look into fixing this? Also, (STATUS JCL) returns NIL. This is likely because you can only read the JCL once (it goes away when you look at it) and I bet Lisp is reading it when it loads, but not doing anything with it... -kmp -------  Date: 12 DEC 1980 2053-EST From: DCP at MIT-MC (David C. Plummer) Subject: Point of incompatibility between MacLisp and Lispm lisp To: BAK at MIT-AI CC: (BUG LISP) at MIT-MC Date: 12 DEC 1980 1453-EST From: BAK at MIT-AI (William A. Kornfeld) The form: ((LAMBDA (A B A) A) 1 2 3) evaluates to 1 in MacLisp and to 3 in Lispm lisp. Since such code is obviously wrong (what does it mean to bind the same symbol to two (supposedly different) objects AT THE SAME TIME?), what difference does it make what it returns?  GSB@MIT-ML 12/12/80 15:26:16 Re: gentemp To: (BUG LISP) at MIT-ML i moved the new macaid to ml and that fixed the problem  GSB@MIT-ML 12/12/80 15:21:39 Re: how to give people grief To: (BUG LISP) at MIT-ML (defmacro == (first second &optional (premise nil)) `(==stuff ,first ,second ',(eval premise))) => ;GENTEMP UNDEFINED FUNCTION IN UUO CALL  Date: 12 DEC 1980 0953-EST From: JONL at MIT-MC (Jon L White) To: JAR at MIT-MC CC: (BUG LISP) at MIT-MC None of us (RWK,KMP,RLB,JONL) have had the time or reason yet to fully resuscitate the XX maclisp directory; but I certainly intend to "bring it up to date" before the end of the year. There has been another round of hacking MacLISP-like things on MC, and seems little point in fiddling with the export version until this is finished (hopefully, this week signals the end of such "development").  Date: 11 December 1980 21:27-EST From: George J. Carrette Subject: CERROR and FORMAT To: RWK at MIT-MC cc: BUG-LISP at MIT-MC, JGA at MIT-MC Sigh, MFORMAT is a macro, so you have to set CERROR-PRINT to *MFORMAT. What is ~G? I'll have to change the implementation of MFORMAT so that new ops are addable without dumping out a new macsyma. (Right now its totally open compiled via hairy macros!).  Date: 11 DEC 1980 2056-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: CERROR and FORMAT To: JGA at MIT-MC, GJC at MIT-MC CC: (BUG LISP) at MIT-MC I forgot to announce this when I did it yesterday, but CERROR (and by implication, FERROR) now calls FORMAT by default. For the interested: CERROR-PRINTER (defaultly FORMAT) controls this feature. If set to NIL, the old default behaviour can be obtained. It can also be set to any other function taking arguments like FORMAT (like MFORMAT, GJC! Can we add ~G to MFORMAT?)  Date: 11 December 1980 00:55-EST From: George J. Carrette To: GSB at MIT-ML cc: BUG-LISP at MIT-MC Yes, I've been screwed many times by COMPLRS misuse of ARGS property. In fact, some times COMPLR has the WRONG args property for system functions! It would be nice to have a user-hook into the part of COMPLR (aye, theres the RUB, its probably spread all over COMPLR), which decides what to do with unknown things. Given that there is no "Function-descriptor" structure used, just random properties, well, theres just no way to do anything reasonable.  Date: 10 DEC 1980 2000-EST From: RLB at MIT-MC (Richard L. Bryan) Subject: The infamous "Pure PUTPROP Twice" bug To: (BUG LISP) at MIT-MC JONL and I just found why this one happens. The symptoms: You push your property name P onto PUTPROP, hoping that while loading up your system, putprops under P will be PURCOPYed, hence sharable among users of your system. While loading, symbol S gets a P property, and later gets another. After purify/suspend/restart, you find that symbol S has randomness under its P property -- randomness which changes from GC to GC. The diagnosis: PUTPROP is buggy. The first time it tries to put a P on S, it finds that there is no P there. It checks for P memq in PUTPROP, finds it so, purcopies the property value, purconses cells to go in the plist of S, and splices into the plist. The second time, PUTPROP finds P is on S. It DOES NOT check for P on PUTPROP, DOES NOT purcopy the property value, merely HRRMing it into the plist cell. The plist cell is typed in ST as needing to become pure, but of course won't actually become read-only until PURIFY runs. Now we have the screw of impure sexp pointed to only by not-marked-from pure sexp. It will get collected (and its cells later reused) next gc. The Rx: PUTPROP should check P for memq in PUTPROP and purcopy the value, if necessary, in all cases. It will need to remember if purcopying took place so it will know to purcons new plist cells if it finds that they are needed. Notes: (1) This is entirely unrelated to write-in-pure-page trapping of attempts by putprop to alter existing pure plist cells. (2) Surgery on PUTPROP has not been performed.  Date: 10 December 1980 17:15-EST From: Glenn S. Burke To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 8 DEC 1980 1617-EST From: GJC at MIT-MC (George J. Carrette) Would it be possible to have DEFUN put (AND (STATUS FEATURE COMPLR) (*EXPR FOOBAR)) ; or *FEXPR or *LEXPR or whatever. into the FASL files? ---- I don't think that it is DEFUN's place to decide that this is desirable, since it is the lowest-level primitive we have for creating function definitions. (I'm often not sure DEFVAR is the right thing, it propagates things too strongly many times.) The compiler could have the capability of deriving this information from its environment. It already goes about it halfway, in a kind of half-assed way, in that it ignores the functional property but uses the ARGS. I also think, however, that it shouldn't die so horribly when what it thinks it knows about something doesn't agree with what was used (ever been screwed because you are changing the definition of a function which is loaded in your compilation environment to take a different number of arguments?)  Date: 10 December 1980 07:20-EST From: Robert W. Kerns Subject: SETF To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 9 December 1980 13:42-EST From: Jon L White Subject: SETF To: BUG-LISP at MIT-MC Why does (SETF (LDB 0303 X) 5) wrap a lambda around things, binding the internal variable to 5 ? So it can return the correct value. There is no smarts about the value to be stored being repeatable. The slight improvement in code is not worth it, since it only shows up when you use it for value (in the compiler).  Date: 10 December 1980 07:17-EST From: Robert W. Kerns Subject: #% To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 9 December 1980 14:18-EST From: Jon L White Subject: #% To: RWK at MIT-MC cc: BUG-LISP at MIT-MC Date: 8 December 1980 15:31-EST From: Robert W. Kerns #%`(....) is hardly ever right! `#%(SI:XSET ,x ,y ,z) used to work perfectly well, until BACKQ make |`,/|| a macro. If you REMPROP it's MACRO property, or (SETQ BACKQUOTE-EXPAND-WHEN 'READ), it works perfectly. #%`(....) is identical with doing `(....) in an environment with BACKQUOTE-EXPAND-WHEN set to READ. this still isn't right -- the problem is that want a read-time "change of horses in mid-stream", so to speak. Here is one correct way to do it: #+FM (sublis `((A . ,totsize) (B . ,(symbolconc sname '-CLASS))) '#%(SI:MAKE-EXTEND A B)) instead of `(SI:MAKE-EXTEND ,totsize ,(symbolconc sname '-CLASS)) Whatever we do, we don't want to remove the macro property of |`,/||. I don't understand 'read-time "change of horses in mid-stream". At any rate, since the read-macro for comma (at least used to) check at read-time if it is inside a backquote, you really have to work hard to get one of those markers to evaluate. In fact, the *ONLY* way I have ever seen it happen is by #% macro-expanding them. I think one of two things should be done: 1) Remove the macro property. 2) Make MACROEXPAND know about it. Also, please note that your 'correct' solution is not as correct as you think. At the time of the macro-expansion, the macro sees just symbols A and B. It may very well do something illegal like reverse the order of evaluation, since those are SIMPLEP. However, (|`,/|| . A) is NOT SIMPLEP. In your simple case, you win, since what you're substituting for both happen to be reversable and multiply evaluable, but if totsize weren't a fixnum, but where a (progn (PRINT 'FOO) 5) and SI:MAKE-EXTEND were something more complicated that actually looked at it's arguments, you might well lose.  Date: 9 December 1980 23:02-EST From: Robert W. Kerns Subject: Re: LISP.INI on TWENEX To: Guy.Steele at CMU-10A cc: BUG-LISP at MIT-MC, Scott.Fahlman at CMU-10A Date: 9 December 1980 1327-EST (Tuesday) From: Guy.Steele at CMU-10A To: Robert W. Kerns Subject: Re: LISP.INI on TWENEX CC: bug-lisp at MIT-MC, Scott.Fahlman at CMU-10A In-Reply-To: Robert W. Kerns's message of 8 Dec 80 20:57-EST Message-Id: <09Dec80 132711 GS70@CMU-10A> Hmm... TWENEX here seems to have a HOME: device, but maybe that's just a local convention. Anyway, what can be done? Beat on DEC to adopt that totally wining local convention?  Date: 9 December 1980 22:24-EST From: Robert W. Kerns Subject: Where does SHBDMP live? To: JONL at MIT-MC cc: BUG-COMPLR at MIT-MC, BUG-LISP at MIT-MC, tlp at MIT-AI Date: 9 December 1980 17:50-EST From: Jon L White Subject: Where does SHBDMP live? To: RWK at MIT-MC cc: BUG-LISP at MIT-MC, BUG-COMPLR at MIT-MC, tlp at MIT-AI Re: TLP@MIT-AI 12/09/80 16:53:33 To: (BUG COMPLR) at MIT-AI COMPLR is trying to load some file from lspdmp; which does not exist on AI. A new SHBDMP and complr dump is on its way now, to AI and ML. Apparently you changed the SHARAB init file to dump its result on SHBDMP instead of LISP? This works fine on MC, but ML and AI don't have LSPDMP directories, and for the past year or so I've been :INSTALLing the dumps from COMLAP instead of rebuilding them on each system. In general, in the past, I've found the using links with sharab doesn't work -- the PURQIX file on LISP; may be linked to SYS;PURQIO because it is the built-in part of lisp's SUSPEND which finds those pages. But SHARAB-dumped files need to know exactly where their parts are. Well, foo, if you'd read your mail before installing you'd have know about this. I explicitly told you what I had done, and that there might be problems, and so since you knew what was going on with this, you should figure out the right thing to do and undo my changes if necessary.  Date: 9 DEC 1980 1750-EST From: JONL at MIT-MC (Jon L White) Subject: Where does SHBDMP live? To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC, tlp at MIT-AI Re: TLP@MIT-AI 12/09/80 16:53:33 To: (BUG COMPLR) at MIT-AI COMPLR is trying to load some file from lspdmp; which does not exist on AI. A new SHBDMP and complr dump is on its way now, to AI and ML. Apparently you changed the SHARAB init file to dump its result on SHBDMP instead of LISP? This works fine on MC, but ML and AI don't have LSPDMP directories, and for the past year or so I've been :INSTALLing the dumps from COMLAP instead of rebuilding them on each system. In general, in the past, I've found the using links with sharab doesn't work -- the PURQIX file on LISP; may be linked to SYS;PURQIO because it is the built-in part of lisp's SUSPEND which finds those pages. But SHARAB-dumped files need to know exactly where their parts are.  Date: 9 DEC 1980 1714-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC The lossage with HAIPART doesn't happen with all fixnum args. Only with certain ones. I might point out the following consistency. Maybe it will be helpful... (haipart -16. 4.) => 8 (haipart -16. 5.) => 16. (haipart -16. 6.) => -16. (haipart -8. 3.) => 4 (haipart -8. 4.) => 8. (haipart -8. 5.) => -8. (haipart -4. 2.) => 2. (haipart -4. 3.) => 3. (haipart -4. 4.) => -4. The following definition, which seems to correct the symptom, may predict what is wrong with HAIPART's algorithm: (DEFUN MY-HAIPART (X Y) (COND ((AND (MINUSP X) (< (HAULONG X) Y)) (MINUS (HAIPART X Y))) (T (HAIPART X Y)))) -kmp  Date: 9 DEC 1980 1418-EST From: JONL at MIT-MC (Jon L White) Subject: #% To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC Date: 8 December 1980 15:31-EST From: Robert W. Kerns #%`(....) is hardly ever right! `#%(SI:XSET ,x ,y ,z) used to work perfectly well, until BACKQ make |`,/|| a macro. If you REMPROP it's MACRO property, or (SETQ BACKQUOTE-EXPAND-WHEN 'READ), it works perfectly. #%`(....) is identical with doing `(....) in an environment with BACKQUOTE-EXPAND-WHEN set to READ. this still isn't right -- the problem is that want a read-time "change of horses in mid-stream", so to speak. Here is one correct way to do it: #+FM (sublis `((A . ,totsize) (B . ,(symbolconc sname '-CLASS))) '#%(SI:MAKE-EXTEND A B)) instead of `(SI:MAKE-EXTEND ,totsize ,(symbolconc sname '-CLASS)) Whatever we do, we don't want to remove the macro property of |`,/||.  Date: 9 DEC 1980 1342-EST From: JONL at MIT-MC (Jon L White) Subject: SETF To: (BUG LISP) at MIT-MC Why does (SETF (LDB 0303 X) 5) wrap a lambda around things, binding the internal variable to 5 ?  Date: 9 December 1980 1327-EST (Tuesday) From: Guy.Steele at CMU-10A To: Robert W. Kerns Subject: Re: LISP.INI on TWENEX CC: bug-lisp at MIT-MC, Scott.Fahlman at CMU-10A In-Reply-To: Robert W. Kerns's message of 8 Dec 80 20:57-EST Message-Id: <09Dec80 132711 GS70@CMU-10A> Hmm... TWENEX here seems to have a HOME: device, but maybe that's just a local convention. Anyway, what can be done?  Date: 9 DEC 1980 0358-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC HAIPART is documented to return a positive result. (HAIPART -2 35.) however returns -2. The bug seems to occur for all negative fixnum first arguments.  Date: 8 December 1980 20:57-EST From: Robert W. Kerns Subject: LISP.INI on TWENEX To: Guy.Steele at CMU-10A cc: BUG-LISP at MIT-MC, Scott.Fahlman at CMU-10A Date: 8 December 1980 1429-EST (Monday) From: Guy.Steele at CMU-10A To: bug-lisp cc: Scott.Fahlman at CMU-10A Re: LISP.INI on TWENEX The LISP.INI file for TWENEX should probably by default be on the HOME: device rather than PS:? What is presently the analogous thing on ITS? Sure it should. TWENEX should *HAVE* a HOME: device! TWENEX suffers from confusion between working-dir and home-dir in many other ways. Ever try to make a directory you have READ access to but not WRITE access your working directory?  Date: 8 DEC 1980 1703-EST From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC PURCOPY now works on HUNKS again. TT was being bashed by the new value-of-PURCOPY hack.  Date: 8 DEC 1980 1617-EST From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC Would it be possible to have DEFUN put (AND (STATUS FEATURE COMPLR) (*EXPR FOOBAR)) ; or *FEXPR or *LEXPR or whatever. into the FASL files? I know that for large programs one doesn't usually compile in the running environment, but this would sure be convenient for small programs, especially ones which I am going to run on the lisp machine too. I doubt anyone would notice the increase in FASL file size. (Which already has (AND (STATUS FEATURE COMPLR) (SPECIAL FOOBAR)) produced by DEFVAR.)  Date: 8 DEC 1980 1548-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: More BACKQUOTE To: JONL at MIT-MC CC: (BUG LISP) at MIT-MC BACKQUOTE-EXPAND-WHEN *USED* to be READ in the compiler. So that stuff all used to work in the compiler. Did I miss the announcement that this change was being made?  Date: 8 DEC 1980 1531-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: NO, NO, NO, NO!!!! To: JONL at MIT-MC CC: (BUG LISP) at MIT-MC #%`(....) is hardly ever right! `#%(SI:XSET ,x ,y ,z) used to work perfectly well, until BACKQ make |`,/|| a macro. If you REMPROP it's MACRO property, or (SETQ BACKQUOTE-EXPAND-WHEN 'READ), it works perfectly. #%`(....) is identical with doing `(....) in an environment with BACKQUOTE-EXPAND-WHEN set to READ. How about if we teach MACROEXPAND-1* to not expand these inner guys?  Date: 8 DEC 1980 1442-EST From: KMP at MIT-MC (Kent M. Pitman) To: Guy.Steele at CMU-10A CC: (BUG LISP) at MIT-MC On ITS, it already defaults to the (STATUS HSNAME) directory -- the home dir. That's the problem: (STATUS HSNAME) on twenex is returning the connected directory instead of the home directory. I think this is pretty clearly a bug.  Date: 8 December 1980 1429-EST (Monday) From: Guy.Steele at CMU-10A To: bug-lisp at MIT-MC Subject: LISP.INI on TWENEX CC: Scott.Fahlman at CMU-10A Message-Id: <08Dec80 142944 GS70@CMU-10A> The LISP.INI file for TWENEX should probably by default be on the HOME: device rather than PS:? What is presently the analogous thing on ITS?  Date: 8 December 1980 12:25-EST From: Kent M. Pitman To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 6 DEC 1980 0626-EST From: JONL at MIT-MC (Jon L White) Subject: CERROR, and the ubiquitous FORMAT True, some error msgs look funny with ~1G~S and so on in them, but I still maintain that forcibly loading in FORMAT is not the solution (for MacLISP, that is). Perhaps we should merely advise novice users to put a loading of FORMAT into their LISP init files. What we are doing is protecting MACSYMA and friends from the suffocation of address space. Any other opinions on this matter? ----- I think there's no real excuse for ~nG~S in the middle of a search screen. It is completely out of key with the rest of Maclisp philosophy -- that things needed load automatically. Telling people to load FORMAT explicitly is awful. Rather than funcalling FORMAT, couldn't CERROR funcall the value of some special variable which was defined to take args like format? That way, systems could put a tiny SUBR there to fake out the loading of FORMAT if they couldn't afford the space. In the case of Macsyma, *MFORMAT would nearly work except it doesn't handle ~G. It probably would be reasonable for us to put in such handling.  GSB@MIT-ML 12/08/80 11:04:19 Re: In XLISP 2057 To: (BUG LISP) at MIT-ML (apply 'this-is-an-indefined-function nil) => ;IMPROPER USE OF MACRO - EVAL  Date: 8 December 1980 1037-EST (Monday) From: Guy.Steele at CMU-10A To: JONL at MIT-MC (Jon L White) Subject: Re: CERROR, and the ubiquitous FORMAT CC: bug-lisp at MIT-MC In-Reply-To: JONL@MIT-MC's message of 6 Dec 80 06:26-EST Message-Id: <08Dec80 103758 GS70@CMU-10A> Maybe the error messages could be designed to look a little bit better when FORMAT isn't applied to them, and maybe also instead of just one goodie a list of all the args to CERROR should be passed to ERROR, so that at least you'd have half a chance of reconstructing mentally the intended formatted message. Also, why in the world are the arguments given so out of order merely to require the use of ~nG all over the place???  GSB@MIT-ML 12/08/80 06:24:17 Re: interrupt screw? To: (BUG LISP) at MIT-ML I was running some stuff, ^Z'ed the lisp, $p'ed it, and it got an mpv inside %ISSW. -- which i was not using, at all. On the stack was a call to STATUS (filemode). This is xlisp 2057. I have seen this happen before, in xlisp 2056 (or maybe a bit earlier); that also was in a call to STATUS (that time memfree, inside the gc-daemon) -- it had jumped into one of those new string-hacking routines, maybe the same one. Perhaps some protection table is being set up (or looked at) incorrectly? Or there is a bug in the lookup wrt the size of the table?  Date: 8 DEC 1980 0451-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: JONL at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC, HENRY at MIT-MC CC: MACSYMA-I at MIT-MC JONL@MIT-MC 12/05/80 04:50:18 Re: Fresh COMPLR (or XCOMPLR) ! To: (BUG LISP) at MIT-MC, henry at MIT-AI CC: (BUG COMPLR) at MIT-MC, MACSYMA-I at MIT-MC Almost always when I use a "used" compiler to compile a file (i.e., one that has already compiled some other file), the result has gibberish in many of the list-structure parts in the FASL. I am thankful this has never happened to me as in the course of compiling for MACSYMA, I have used the same loading of COMPLR to compile many MACSYMA source files for over 6 years now. Maybe the fact that I call (INITIALIZE) between source file compilations has saved me, I don't know. JONL, since you maintain COMPLR, have you tracked down the phenomenon you describe?  Date: 8 December 1980 02:43-EST From: Robert W. Kerns Subject: CERROR, and the ubiquitous "Unclaimed Message" error To: JONL at MIT-MC cc: BUG-LISP at MIT-MC, GJC at MIT-MC Date: 7 December 1980 07:21-EST From: Jon L White To: BUG-LISP at MIT-MC cc: GJC at MIT-MC Re: CERROR, and the ubiquitous "Unclaimed Message" error How often do you get in to a loop trying to print out the object which didn't claim a message? infinitely often, for often an object which doesn't claim some random msg will also fail to claim the PRINT msg. So for now, I'm making it just print the address of the offender. If the loser wants, he can just MUNKAM that address. This should never happen. OBJECT-CLASS has a PRINT method, and every instantiated class should be an inferior of OBJECT-CLASS. So if this would indeed happen, it should be reported as a separate problem. I'd make the unclaimed message handler check to see if the message being complained about is the PRINT message, and handle it specially. What think you?  Date: 8 December 1980 02:35-EST From: Robert W. Kerns Subject: PURCOPY and DEFVST's To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 6 December 1980 18:44-EST From: George J. Carrette To: BUG-LISP at MIT-MC There is some kind of bad interaction between DEFVST and purification. The file MAXTUL;MCL _UNDU_ contains a script file of the lossage encountered. For a demo of the bug, try dumping out a macsyma compilation environment, like so: MAXTUL CL when it asks the question "(*PURE?)", reply T, and then watch things load, until it bombs. -gjc This problem should be fixed in the new EXTEND, in the new LISP. They should be released shortly.  Date: 07 Dec 1980 2309-PST From: Rod Brooks To: bug-lisp at MIT-MC SUBST definition changed? This happens at SAIL and MC: (setq x '(a b)) (A B) (setq y '(a b)) (A B) (eq x y) NIL (subst 'foo x (list y y y)) (FOO FOO FOO) Whereas the online definition (at SAIL) for SUBST is: (subst x y z) substitutes x for all occurrences of y in z, and returns the modified copy of z. The original z is unchanged, as subst recursively copies all of z replacing elements eq to y as it goes. If x and y are nil, z is just copied, which is a convenient way to copy arbitrary list structure. ... subst could have been defined by: (defun subst (x y z) (cond ((eq z y) x) ;if item eq to y, replace. ((atom z) z) ;if no substructure, return arg. ((cons (subst x y (car z)) ;otherwise recurse. (subst x y (cdr z)))))) Is this change "official" or accidental (i.e. will it stay this way, or might it change back)?  Date: 8 December 1980 00:38-EST From: Robert W. Kerns Subject: YES-OR-NO-P To: GZ at MIT-MC cc: BUG-LISP at MIT-MC Date: 7 December 1980 17:50-EST From: Gail Zacharias To: BUG-LISP at MIT-MC It seems YES-OR-NO-P returns nil no matter what. Fixed.  Date: 7 DEC 1980 1750-EST From: GZ at MIT-MC (Gail Zacharias) To: (BUG LISP) at MIT-MC It seems YES-OR-NO-P returns nil no matter what.  Date: 7 DEC 1980 1559-EST From: JGA at MIT-MC (John G. Aspinall) Subject: CERROR, and the ubiquitous FORMAT To: JONL at MIT-MC CC: JGA at MIT-MC, (BUG LISP) at MIT-MC Date: 6 DEC 1980 0626-EST From: JONL at MIT-MC (Jon L White) True, some error msgs look funny with ~1G~S and so on in them, but I still maintain that forcibly loading in FORMAT is not the sloution (for MacLISP, that is). Perhaps we should merely advise novice users to put a loading of FORMAT into their LISP init files. What we are doing is protecting MACSYMA and friends from the suffocation of address space. Any other opinions on this matter? But the point is that an experienced user can recognize ~1G~S as a part of a format string, and can extract the equivalent information by a number of indirect means. Once the novice can recognize a format string they probably don't need to load FORMAT to figure out what's going on. The person you hurt with this policy, is the fledgling lisp programmer who needs to have nastiness like error messages as sugar coated as possible; - not to be told "... not only do you have an error, but you can't read the error message because of something else you don't know about". I recognize the address space problem - I've strangled more than one Macsyma, but as someone who considers himself only a few microns above the novice level of lisp programming, I don't like the effect on the present default environment that this has. Maybe experienced users (who all have inits, don't they?) should be given an "anti-autoload" property? John.  GSB@MIT-ML 12/07/80 09:11:57 Re: interrupts To: (BUG LISP) at MIT-ML If you start up a lisp and manage to ^Z $P it before it goes to ask "alloc?", at some point in there it apparently has enabled some interrupts but hasn't set up its interrupt vector or something and gets a badpi.  Date: 7 DEC 1980 0808-EST From: JONL at MIT-MC (Jon L White) Subject: DEFVSX, |defvst-contructor/|| To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC Date: 6 December 1980 23:54-EST From: Robert W. Kerns . . . isn't that (1+ ,totsize) supposed to just be totsize now that the random extra slot isn't there any more? Yes it is, and I've just changed it in the source. Also did a trick with #% so that the SI:MAKE-EXTEND will turn into MAKHUNK at time of compiling DEFVSX (in the MacLISP world, that is).  Date: 7 DEC 1980 0721-EST From: JONL at MIT-MC (Jon L White) Subject: CERROR, and the ubiquitous "Unclaimed Message" error To: (BUG LISP) at MIT-MC CC: GJC at MIT-MC How often do you get in to a loop trying to print out the object which didn't claim a message? infinitely often, for often an object which doesn't claim some random msg will also fail to claim the PRINT msg. So for now, I'm making it just print the address of the offender. If the loser wants, he can just MUNKAM that address.  Date: 7 DEC 1980 0026-EST From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC Hmm, I tried to make the USERATOMS-HOOK for classes do the necessary hair, including loading EXTBAS as needed, to define a skeletal class object if non are found. However, it's impossible to do a FASLOAD at that point in a FASLOAD, sigh.  Date: 6 DEC 1980 2354-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: DEFVSX, |defvst-contructor/|| To: (BUG LISP) at MIT-MC `(LET ((CURRENT-CONSTRUCTION (*:MAKE-EXTEND (1+ ,totsize) ,(symbolconc sname '-CLASS)))) ,. (nreconc bl (nreconc nol '(CURRENT-CONSTRUCTION)))) )) isn't that (1+ ,totsize) supposed to just be totsize now that the random extra slot isn't there any more?  Date: 6 DEC 1980 1844-EST From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC There is some kind of bad interaction between DEFVST and purification. The file MAXTUL;MCL _UNDU_ contains a script file of the lossage encountered. For a demo of the bug, try dumping out a macsyma compilation environment, like so: MAXTUL CL when it asks the question "(*PURE?)", reply T, and then watch things load, until it bombs. -gjc  Date: 6 December 1980 18:41-EST From: Robert W. Kerns Subject: SYMBOLCONC, STRINGs, and other things being D.E.A.D. To: JONL at MIT-MC cc: BUG-LISP at MIT-MC, KMP at MIT-MC Date: 6 December 1980 06:22-EST From: Jon L White Subject: SYMBOLCONC, STRINGs, and other things being D.E.A.D. To: KMP at MIT-MC cc: BUG-LISP at MIT-MC, RWK at MIT-MC Re: Date: 5 December 1980 16:49-EST From: Kent M. Pitman In Maclisp, with STRING loaded, (SYMBOLCONC "FOO" "BAR") gives a circular . . . This is entirely and wholly due to a buggy SENDI file installed by RWK yesterday at 15:05:46 -- the problem is the failure of the new SENDI to set up the variables SI:CLASS-MARKER and *:CLASS-MARKER. Not only does SYMBOLCONC give "bizarre" results, but any use whatsoever of any data interfaceing to the CLASS system is effectively dead. Fixed in SENDI 97. RWK: do a SRCCOM on SENDI to see what I changed -- I believe that the second BOUNDP in the .SXEVAL is the loss. Well, all I can say is I was lead astray by GJC reporting that it worked (after previous problems) I guess all he really determined was that it loaded. Guess I should do my own testing... The reason SENDI was installed early was to enable it to work in both regimes. Clarification: Note that the problem is note exactly the failure of SENDI to set up the variables SI:CLASS-MARKER and *:CLASS-MARKER. That is and was the responsibility of EXTEND. The .SXEVAL is merely a cross-compatibility hack that failed, sigh.  Date: 6 DEC 1980 1728-EST From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC READ doesn't seem to feel like doing an SFA-CALL on SFA's which support the READ operation.  Date: 6 DEC 1980 1339-EST From: JONL at MIT-MC (Jon L White) Subject: SQOZ/| To: (BUG LISP) at MIT-MC I moved this semi-worthless function from the basic MacLISP system into the GETMIDASOP file. As far as I know, only LAP and GETMIDASOP use it.  Date: 6 DEC 1980 0934-EST From: JONL at MIT-MC (Jon L White) Subject: PURCOPY To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC LISP version 2057 is assembling now -- it will have the feature that no item on the list found in the value cell of PURCOPY will actually be copied. Thus si:defclass... may want to push CLASS's onto PURCOPY. I wonder of spurious movement ocasioned by over-putpropping may have caused the weird lossage I previously reported about not using a "Fresh" compiler?  Date: 6 DEC 1980 0626-EST From: JONL at MIT-MC (Jon L White) Subject: CERROR, and the ubiquitous FORMAT To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC, JGA at MIT-MC True, some error msgs look funny with ~1G~S and so on in them, but I still maintain that forcibly loading in FORMAT is not the sloution (for MacLISP, that is). Perhaps we should merely advise novice users to put a loading of FORMAT into their LISP init files. What we are doing is protecting MACSYMA and friends from the suffocation of address space. Any other opinions on this matter?  Date: 6 DEC 1980 0622-EST From: JONL at MIT-MC (Jon L White) Subject: SYMBOLCONC, STRINGs, and other things being D.E.A.D. To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC, RWK at MIT-MC Re: Date: 5 December 1980 16:49-EST From: Kent M. Pitman In Maclisp, with STRING loaded, (SYMBOLCONC "FOO" "BAR") gives a circular . . . This is entirely and wholly due to a buggy SENDI file installed by RWK yesterday at 15:05:46 -- the problem is the failure of the new SENDI to set up the variables SI:CLASS-MARKER and *:CLASS-MARKER. Not only does SYMBOLCONC give "bizarre" results, but any use whatsoever of any data interfaceing to the CLASS system is effectively dead. Fixed in SENDI 97. RWK: do a SRCCOM on SENDI to see what I changed -- I believe that the second BOUNDP in the .SXEVAL is the loss.  Date: 5 DEC 1980 1649-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC In Maclisp, with STRING loaded, (SYMBOLCONC "FOO" "BAR") gives a circular hunk description which if you trim with PRINLEVEL PRINLENGTH settings you find is wanting to say ;(...) 1G~S Bizarre arg -- SYMBOLCONC ? I don't think that's such a bizarre arg. I would have thought SYMBOLCONC was something akin to (IMPLODE (MAPCAN 'EXPLODEN arglist)) but I guess it does something wierder and less robust. Anyway, I think that CERROR should load FORMAT if it's going to use those silly messages. Alternatively, it should parse enough of the string to not output any of the ~ codes. Ie, "FOO~1G~SBAR" should be prescanned and print as FOOBAR. This would be really cheap to put in if you're worried about the size of FORMAT...The ~nG stuff really bugs me and as we've seen in JGA's message -- users don't find it too reassuring either.  Date: 5 DEC 1980 1010-EST From: JONL at MIT-MC (Jon L White) Subject: +INTERNAL-LOSSAGE To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC Yea, PSZ intended to write the code for BACKQ to distinguish between usrhunks and random hunks, but never got around to it; I have a lot of code in which ` is used over descend-able usrhunks [e.g., `#(a ,b) in NIL code] so that has to work too. But for cases where the system code just isn't fully developed, I agree that something like your suggestion +INTERNAL-LOSSAGE is needed -- take a look at the current LISP;LISP RECENT and search for that name.  Date: 5 December 1980 04:57-EST From: George J. Carrette Subject: Fresh COMPLR (or XCOMPLR) ! To: JONL at MIT-MC cc: BUG-COMPLR at MIT-MC, BUG-LISP at MIT-MC, MACSYMA-I at MIT-MC, henry at MIT-AI Date: 5 DEC 1980 0450-EST From: JONL (Jon L White) To: (BUG LISP), henry at MIT-AI cc: (BUG COMPLR), MACSYMA-I Re: Fresh COMPLR (or XCOMPLR) ! Almost always when I use a "used" compiler to compile a file (i.e., one that has already compiled some other file), the result has gibberish in many of the list-structure parts in the FASL. Seems like that happens to me only when I ^G during compilation. One side effect from too much COMPLR usage is brain damage.  Date: 5 DEC 1980 0450-EST From: JONL at MIT-MC (Jon L White) Subject: Fresh COMPLR (or XCOMPLR) ! To: (BUG LISP) at MIT-MC, henry at MIT-AI CC: (BUG COMPLR) at MIT-MC, MACSYMA-I at MIT-MC Almost always when I use a "used" compiler to compile a file (i.e., one that has already compiled some other file), the result has gibberish in many of the list-structure parts in the FASL.  Date: 4 December 1980 19:23-EST From: Earl A. Killian Subject: ... To: BUG-LISP at MIT-MC I have a macro that lets me write (DEFPATTERN (LET ((VAR VAL) ...) . BODY) ((LAMBDA (VAR ...) . BODY) VAL ...)) to define LET, except that "..." doesn't read in as a symbol; it gets a dot context error. Is there some way it could be made to read in as a symbol? KMP says that this is already the case in LispM lisp.  Date: 4 December 1980 19:17-EST From: Kent M. Pitman To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 4 December 1980 05:32-EST From: Jon L White ... Really? Works for NO ONE?? I tested it out for all the previous cases and encountered no bugs. You obviously didn't test out your buggy version for the one explicit example I had sent you, namely `(A . ,b .) ----- My comment in the code when I made the original change said that `"FOO" had been previously broken. If `(A . ,b .) was working then it obviously wasn't hitting the (BREAK |+ibx-uhunkp/||) which `"FOO" was hitting. Hence, I couldn't have broken anything with my change, while my first patch was obviously broken by your rewrites. The point is not the bug -- the point was the nature of it. Specifically, random BREAK's in the middle of released code followed by no correction code for people that $P, strike me as a *REALLY* bad idea. I think that if you want to put a breakpoint in released code it should definitely not say just PSZ-LOSES or +ibx-hunkp| -- it should do something like: (DEFUN +INTERNAL-LOSSAGE (CONTINUABLE FUN TAG VAL &OPTIONAL (DATA "")) (FORMAT T ";Lisp internal function ~S is buggy.~@ ;Please report this to BUG-LISP.~@ ;Location-ID: ~A~%;Value(s): ~S~%~A" FUN TAG VAL DATA) (COND (CONTINUABLE (*BREAK T "LISP-BUG (Typing P might win)")) (T (ERROR "Error not proceedable" FUN 'FAIL-ACT)))) (DEFUN |+ibx/|| (X) ... (+INTERNAL-LOSSAGE () '|+ibx/|| 1. X) ...) Ie, if you have reason to believe that a function is buggy, then tell the user that it's not his fault, tell him how to send you mail, and what information he should provide, and tell him if P'ing is going to have a chance of recovering. (A primitive function in Lisp that did something like this might be worth the space.) But please don't just put in random BREAKs.  Date: 4 December 1980 18:37-EST From: Robert W. Kerns Subject: STRING error messages To: RLB at MIT-MC cc: BUG-LISP at MIT-MC Date: 4 December 1980 10:39-EST From: Richard L. Bryan Subject: STRING error messages To: BUG-LISP at MIT-MC Date: 4 December 1980 01:07-EST From: Robert W. Kerns From: John G. Aspinall ;ARDS ~1G~S does not pass the ~0G~S test, for function ~2G~S ? . . . If you load FORMAT you'll get totally winning messages. However, since some systems can't tolerate the address space consumed by FORMAT, it isn't loaded by default. So as a poor alternate, it just gives you the format string. Well, perhaps the rest of the args to the nonexistent FORMAT could appear on the screen as well, like what test (~0G) and what function (~2G). I often find myself ^Ging, loading FORMAT, and recreating the error in order to find this out. Unfortunately, LISP's error system doesn't provide a way to do this. In a WRONG-TYPE-ARG error, the second argument to ERROR should be the offending object.  Date: 4 December 1980 1614-EST (Thursday) From: Guy.Steele at CMU-10A To: JONL at MIT-MC (Jon L White) Subject: Re: READLINE CC: bug-lisp at MIT-MC In-Reply-To: JONL@MIT-MC's message of 4 Dec 80 05:55-EST Message-Id: <04Dec80 161451 GS70@CMU-10A> What'{s wrong with READLINE and PNGET is that MacLISP cannot distinguish between the symbols || and |^@|. What ever happened to the idea of using three bits of the symbol block to encode the number of characters in the last word of the pname string?  Date: 4 December 1980 10:39-EST From: Richard L. Bryan Subject: STRING error messages To: BUG-LISP at MIT-MC Date: 4 December 1980 01:07-EST From: Robert W. Kerns From: John G. Aspinall ;ARDS ~1G~S does not pass the ~0G~S test, for function ~2G~S ? . . . If you load FORMAT you'll get totally winning messages. However, since some systems can't tolerate the address space consumed by FORMAT, it isn't loaded by default. So as a poor alternate, it just gives you the format string. Well, perhaps the rest of the args to the nonexistent FORMAT could appear on the screen as well, like what test (~0G) and what function (~2G). I often find myself ^Ging, loading FORMAT, and recreating the error in order to find this out.  Date: 4 DEC 1980 0608-EST From: JONL at MIT-MC (Jon L White) Subject: (TO-STRING '||) To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC Date: 4 December 1980 05:59-EST From: Robert W. Kerns . . . Hmm, right, well, (TO-STRING '||) used to do something useful. I had thought (PNGET '|| 7) used to return (), but that's not true. I guess the fault is TO-STRING's. Bug is entirely the fault of GET-PNAME -- I've just edited in the change to the source, and will recompile STRING shortly.  Date: 4 December 1980 06:01-EST From: Robert W. Kerns Subject: ~ --> To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 4 December 1980 05:49-EST From: Jon L White To: RWK cc: BUG-LISP Re: ~ --> Yes, your analysis is right -- the two lines MOVEI A,STR%AR JSP TT,$GCMKAR are completely bogus and should be removed -- I must have forgotten that $GCMKAR doesn't check what kind of array it is marking. As for the need for this array, LISP;NEW RECENT, which is about to become LISP RECENT, mentions +INTERNAL-CHAR-N, +INTERNAL-RPLACHAR-N, +INTERNAL-STRING-WORD-N, and +INTERNAL-SET-STRING-WORD-N. These are being "built-in" to accommodate both the STRING package and GSB's private verions of strings; it's partly the un-interruptibility question that makes this necessary (verry short functions don't even want to push and pop INHIBIT). Actually, just in case somebody *REARRAY's it, it probably theoretically should mark it if it's a type T array.  Date: 4 December 1980 05:59-EST From: Robert W. Kerns Subject: READLINE To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 4 December 1980 05:55-EST From: Jon L White To: RWK cc: BUG-LISP Re: READLINE Date: 4 December 1980 04:30-EST From: Robert W. Kerns Um, uh, er, uh, well, folks, (PNGET (READLINE) 7) gives (0) ... clearly wrong. So what's wrong? READLINE did return the null symbol, ||, didn't it? (PNGET '|| 7) indeed should be (0) Hmm, right, well, (TO-STRING '||) used to do something useful. I had thought (PNGET '|| 7) used to return (), but that's not true. I guess the fault is TO-STRING's.  Date: 4 DEC 1980 0555-EST From: JONL at MIT-MC (Jon L White) Subject: READLINE To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC Date: 4 December 1980 04:30-EST From: Robert W. Kerns Um, uh, er, uh, well, folks, (PNGET (READLINE) 7) gives (0) ... clearly wrong. So what's wrong? READLINE did return the null symbol, ||, didn't it? (PNGET '|| 7) indeed should be (0)  Date: 4 DEC 1980 0549-EST From: JONL at MIT-MC (Jon L White) Subject: ~ --> To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC Yes, your analysis is right -- the two lines MOVEI A,STR%AR JSP TT,$GCMKAR are completely bogus and should be removed -- I must have forgotten that $GCMKAR doesn't check what kind of array it is marking. As for the need for this array, LISP;NEW RECENT, which is about to become LISP RECENT, mentions +INTERNAL-CHAR-N, +INTERNAL-RPLACHAR-N, +INTERNAL-STRING-WORD-N, and +INTERNAL-SET-STRING-WORD-N. These are being "built-in" to accommodate both the STRING package and GSB's private verions of strings; it's partly the un-interruptibility question that makes this necessary (verry short functions don't even want to push and pop INHIBIT).  Date: 4 DEC 1980 0532-EST From: JONL at MIT-MC (Jon L White) Subject: Hype To: KMP at MIT-MC CC: JGA at MIT-MC, (BUG LISP) at MIT-MC Re your BACKQ tirade: Date: 3 December 1980 18:43-EST From: Kent M. Pitman Subject: BACKQ fixed? . . . All I'm complaining about is that I had it fixed so that it worked in some cases because someone needed the code to work to get his work done. Your making it breakpoint in that case means it doesn't work for anyone and . . . Really? Works for NO ONE?? I tested it out for all the previous cases and encountered no bugs. You obviously didn't test out your buggy version for the one explicit example I had sent you, namely `(A . ,b .)  Date: 4 DEC 1980 0525-EST From: JONL at MIT-MC (Jon L White) Subject: Flaming about *LDB and SETF To: ALAN at MIT-MC CC: DLW at MIT-MC, MOON at MIT-MC, (BUG LISP) at MIT-MC I notice that some of the misunderstandings could have been avoided by using XLISP, which has LDB and *LDB implemented as subrs. I thought I had fully satisfied this complaint before, namely installing the missing autoload properties which insure that the file with the defsetf for *LDB gets loaded.  Date: 4 DEC 1980 0430-EST From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC Um, uh, er, uh, well, folks, (PNGET (READLINE) 7) gives (0) ... clearly wrong.  Date: 4 December 1980 01:48-EST From: Robert W. Kerns Subject: suckage To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC, DLW at MIT-MC, MOON at MIT-MC Date: 4 December 1980 01:26-EST From: Alan Bawden Sender: ALAN at CADR3 To: RWK cc: DLW, MOON, BUG-LISP Re: suckage Date: 3 December 1980 22:15-EST From: Robert W. Kerns Subject: suckage To: ALAN at MIT-MC cc: DLW at MIT-MC, MOON at MIT-MC, BUG-LISP at MIT-MC Well, 1) *LDB is simply what LDB used to expand into. Blameing it on MACLISP's SETF is silly, it's what MACROEXPAND produced. Now, MACLISP's SETF has a DEFSETF for *LDB. So obviously, what happened here, was that YOUR SETF did a MACROEXPAND, but wasn't prepared to handle the expansion of LDB. BULLSHIT. This was in a vanilla lisp. ONLY my defstruct was loaded, and as I said before it only generates code using LDB and DPB (and SETF of LDB and DPB). OK, let's try again. It's STILL SILLY to blame SETF. However, reading DLW's original complaint again, I find he complained that *DPB was an undefined function. Now, at this point it should be obvious that SETF expanded and returned the result, namely *DPB, which is a LEGITIMATE result. So obviously DLW caught things in some inconsistant state, HAVING NOTHING TO DO WITH SETF, where *DPB wasn't defined. But I apologize for blaming it on your SETF.  Date: 4 DEC 1980 0126-EST From: ALAN at MIT-MC (Alan Bawden) Sent-by: ALAN at CADR3 at MIT-MC Subject: suckage To: RWK at MIT-MC CC: DLW at MIT-MC, MOON at MIT-MC, (BUG LISP) at MIT-MC Date: 3 December 1980 22:15-EST From: Robert W. Kerns Subject: suckage To: ALAN at MIT-MC cc: DLW at MIT-MC, MOON at MIT-MC, BUG-LISP at MIT-MC Well, 1) *LDB is simply what LDB used to expand into. Blameing it on MACLISP's SETF is silly, it's what MACROEXPAND produced. Now, MACLISP's SETF has a DEFSETF for *LDB. So obviously, what happened here, was that YOUR SETF did a MACROEXPAND, but wasn't prepared to handle the expansion of LDB. BULLSHIT. This was in a vanilla lisp. ONLY my defstruct was loaded, and as I said before it only generates code using LDB and DPB (and SETF of LDB and DPB).  Date: 4 December 1980 01:07-EST From: Robert W. Kerns Subject: STRING error messages To: JGA at MIT-MC cc: BUG-LISP at MIT-MC Date: 1 December 1980 11:17-EST From: John G. Aspinall Subject: STRING error messages To: BUG-LISP at MIT-MC cc: JGA at MIT-MC (load '((lisp) string)) (setq a 'ards) (string-append "foo" a) ;ARDS ~1G~S does not pass the ~0G~S test, for function ~2G~S ? I don't think this is very informative. John. If you load FORMAT you'll get totally winning messages. However, since some systems can't tolerate the address space consumed by FORMAT, it isn't loaded by default. So as a poor alternate, it just gives you the format string.  Date: 3 December 1980 22:15-EST From: Robert W. Kerns Subject: suckage To: ALAN at MIT-MC cc: DLW at MIT-MC, MOON at MIT-MC, BUG-LISP at MIT-MC Well, 1) *LDB is simply what LDB used to expand into. Blameing it on MACLISP's SETF is silly, it's what MACROEXPAND produced. Now, MACLISP's SETF has a DEFSETF for *LDB. So obviously, what happened here, was that YOUR SETF did a MACROEXPAND, but wasn't prepared to handle the expansion of LDB. 2) JONL changed LDB to not expand into *LDB, and similarly hacked *:XREF, without changing SETF. This seems to have been fixed.