Date: Saturday, 8 January 1983 14:36-EST Sender: EB @ MIT-OZ From: EB @ MIT-MC To: Bug-Lisp @ MIT-OZ Does OZ have the latest Maclisp? Lisp 2129, which is installed there, still has the bug wherein it opens JFNs in restricted mode.  Date: 1 Jan 1983 0310-EST From: GJS at MIT-OZ Subject: compiler bug -- floating overflow missed. To: bug-maclisp at MIT-OZ see src:foo.lsp and foo.lap. -------  Date: 20 DEC 1982 0705-PST From: JONL at PARC-MAXC Subject: reVisitations in the night! To: gsb at MIT-ML cc: bug-lisp at MIT-MC, Guy.Steele at CMU-CS-A Point well taken about compability between interpreted and compiled code -- but that argues in no way for admitting a meaning for division by zero (APL notwithstanding -- I'd like to know who needs/wants the current behaviour of REMAINDER). Independent of the compability of compiled code is the question of compability of extended meanings between the generic and type-specific operators. Except for my intrusion of the problem of DIFFERENCE and "-", I'm not sure if there have been any arguments about this. P.S. I continue to use "division" for the multiple-valued result; LISP has historically used QUOTIENT and REMAINDER to select between the two. Also, as we have remarked before in the CommonLisp mails, the REMAINDER function isn't quite the same as MOD; I'm not sure what the poin of MODding by 0 would be, but it could stand on a different footing than remainder.  Date: 20 December 1982 0833-EST (Monday) From: Guy.Steele at CMU-CS-A To: bug-lisp at MIT-MC, gsb at MIT-ML, jonl at PARC-MAXC, alan at MIT-MC Subject: (\ x 0) If anyone cares, APL defines A divided by 0 to be in error unless A is also zero, in which case the result is 1. However, A mod 0 is always equal to A in APL. Go figure it. --Guy  Date: 19 December 1982 23:20-EST From: Glenn S. Burke Subject: Re: Re: (\ x 0) revisited, revisited, revisited To: jonl at PARC-MAXC cc: BUG-lisp at MIT-MC No, the whole point of this proposal is that the "right" thing to do is not to cause an error for a zero divisor, but to check for that and "do the right thing". This is predicated on the premise that for the REMAINDER operation, a 0 divisor has a defined result. (Presumably someone else once thought this, given that the REMAINDER function has this check.) The \ function is not an interface to the second value returned by the IDIV instruction. Our semantics are just that the interpreted version will behave compatibly with the compiled one. If it takes an extra couple of instructions to do it right, then great. (HAULONG takes a couple instructions, as do some of the fix-float conversions.)  Date: 19 DEC 1982 1945-PST From: JONL at PARC-MAXC Subject: Re: (\ x 0) revisited, revisited, revisited To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC, GSB at MIT-ML, JONL In response to your message sent 19 December 1982 21:00-EST It has always been the case that MacLisp's "single-character" arithmetic functions were driven by the desire for open-compilation. Thus one gives up any interpreter error checking in the compiled code, merely accepting what the hardware returns. It's certainly no surprise, then, that the PDP10 does odd things with division by zero -- or do I mistake the tone of your note? By the bye, I had to bring in the generic operation, since the "right" thing for the \ subr to do is to cause an error when given a 0 divisor (just as it would if you gave it NIL for an arg); unfortunately, this may not be the right thing to do to "fix" the REMAINDER function: see the caveat in my previous msg.  Date: 19 December 1982 21:00-EST From: Alan Bawden Subject: (\ x 0) revisited, revisited, revisited To: jonl at PARC-MAXC cc: BUG-LISP at MIT-MC, GSB at MIT-ML In-reply-to: The message of 19 Dec 1982 17:48-EST from Glenn S. Burke The IDIV instruction deals with division by zero by doing nothing. AC and AC+1 are left with their original contents, and the Overflow and No Divide bits are set. This may be the right thing for division, but since the IDIV instruction is also the way to get a remainder, and since the remainder is perfectly well-defined for the 0 case, this means that there is a hole in the basic instruction-set. I would say that AC+1 should get loaded with the contents of AC in this case. So this really is DEC's bug! Now I presume that the contract of "\" is to "do what the hardware does", just like "+" is defined to do what the ADD instruction does. This is a pretty strange contract given that the hardware just hands you back whatever happens to be in AC+1, which could be anything! This is exactly what code produced by COMPLR is doing. But the "\" SUBR returns the first argument in this case. This has NOTHING to do with generic vs. specific arithmetic functions. Nobody has yet mentioned the REMAINDER function. It is simply a bug. The "\" function does different things interpreted and compiled. An easy fix is to change the "\" SUBR to return a randomly chosen value if you tried to remainder by 0. A harder fix is to fix COMPLR to output the extra instruction necessary to make the check in compiled code. Actually another discrepancy I just noticed is that (eq (get '\ 'subr) (get 'remainder 'subr)) => T! So we can also haul up the "\" SUBR on charges of not doing enough error checking!  Date: 19 DEC 1982 1745-PST From: JONL at PARC-MAXC Subject: Re: (\ x 0) revisited, revisited To: GSB at MIT-ML cc: BUG-lisp at MIT-MC, JONL In response to your message sent 19 December 1982 17:48-EST Uh, "remainder" is just one of the two multiple results from division, the other being "quotient". There are several places in the MacLisp world where the generic arithmetic functions have some slightly different defaulting than the type-specific ones, and I agree with you that this one doesn't have any benefit. I wonder who depends upon the generic remainder working for a divisor of 0 -- probably some totally obscure place in MacSYMA? The lossage of having (- X) default differently from (DIFFERENCE x) was perprated "during my time", but I certainly disavow it. (Pratt was one of the contenders for this discrepancy, since it seemed to make something simpler in CGOL).  Date: 19 December 1982 17:48-EST From: Glenn S. Burke Subject: (\ x 0) revisited, revisited To: jonl at PARC-MAXC cc: BUG-lisp at MIT-MC that's remainder, not division. Division should be an error. Remainder, however, should at least be compatible with what the interpreter does (it shares code with the generic remainder, which performs the special 0 divisor check and returns x). Getting x back for division by 0 is an error in the program (division by 0) [at least in the maclisp world], getting 0 (or something random) back for remainder by 0 is a bug, unless we claim that it is an error, and then fix (break?) the generic remainder function.  Date: 19 DEC 1982 1438-PST From: JONL at PARC-MAXC Subject: Re: (\ x 0), revisited To: gsb at MIT-ML cc: bug-lisp at MIT-MC Mail-from: Arpanet host SUMEX-AIM rcvd at 19-DEC-82 1302-PST Date: 19 Dec 1982 1304-PST From: Bill White Subject: division by 0 To: lispsupport at PARC-MAXC cc: CSCHMIDT at SUMEX-AIM, WHITE at SUMEX-AIM I recently discovered that dividing by 0 in Interlisp gave the same result as dividing by 1. Is this a feature or a bug? Certainly seems like an odd choice if its a feature. Bill White ------- Bill White (no relation) is with Teknowledge, Inc. I agree with him that equating division by zero with division by one is an odd choice for a feature. Quest? Would you also propose to fix up (\ x y) dynamically, in addition to the compile-time detectable (\ x 0) ?  GSB@MIT-ML 12/18/82 20:15:47 Re: (\ x 0), revisited To: (BUG LISP) at MIT-ML Who all out there in hacker land would have hysterics if it were made to check for 0 and return x? (This is the open-compiled fixnum-only one.)  Date: 11 Dec 1982 1456-EST From: Michael J. Konopik Subject: Re: and migration To: KMP at MIT-OZ cc: file-r at MIT-OZ, bug-lisp at MIT-OZ In-Reply-To: Your message of 11-Dec-82 1434-EST There is a list of no-reap directories. I will add LIBLSP to this. This list has the characteristic that it (reaper) will only mark files that have not been touched in over a year. Is this time period acceptable? If not, I can make another group of directories that will fall into the frame you desire. -Mike -------  Date: 11 Dec 1982 1434-EST From: KMP at MIT-OZ Subject: and migration To: cent at MIT-OZ, file-r at MIT-OZ cc: bug-lisp at MIT-OZ, gren at MIT-OZ, eric at MIT-OZ Saying SET FILE RESIST will patch the symptom, but not the cause. We really don't want anything in that dir reaped ever. If we use SET FILE RESIST, we have to always be remembering to set it on new files and when we miss, we'll lose. Since it is the obvious intent of the system that these should not be reaped and the obvious intent of the system programs that they should make the system run smoothly, some system hacker should fix the dumper so that it has a table of immune dirs... -------  Date: 11 December 1982 08:07-EST From: Pandora B. Berman Subject: To: ALAN at MIT-MC cc: KMP at MIT-ML, file-r at MIT-OZ, bug-lisp at MIT-OZ Date: 10 December 1982 04:58-EST From: Alan Bawden Subject: To: FILE-R at MIT-OZ Can you please un-migrate these files? done. LIBLSP should be immune to this sort of thing probably, is there a bit one can set in the directory that will prevent this? or do I have to set the bits in all the files? according to an old sysmsg sent by jsol, the twenex rough equivalent of a don't-reap bit is to say @SET FILE RESIST filename, other.file, foo.bar.23,... with *s allowed. PS:FONTRD.FASL.3 PS:HASH.FASL.1 PS:LAUGH.FASL.1 PS:SAVE.FASL.1  Date: 11 Dec 1982 0114-EST From: KMP at MIT-OZ Subject: Migration To: file-r at MIT-OZ cc: bug-oz at MIT-OZ, bug-lisp at MIT-MC and should probably not be mechanically reaped. There are many files there which may not be touched for a long time but which are still essential to have "on call". If these dirs seem excessively larged, someone should complain to bug-lisp and they will be hand reaped. But someone should put in software control so that we bug-lisp people don't have to send mail saying to retrieve files every time a migration happens. Some directories just have to be immune to that sort of thing. Please bring back to disk PS:FONTRD.FASL.3 PS:HASH.FASL.1 PS:LAUGH.FASL.1 PS:SAVE.FASL.1 Thank you. -------  Date: Friday, 10 December 1982 04:51-EST Sender: CENT at MIT-OZ From: CENT at MIT-MC To: bug-lisp at MIT-OZ Subject:migration (dumper was supposed to send you this itself. apparently its mail file creating mechanism doesn't know it has to put headers on msgs.) ---------- LIBLSP Migrated files The following files have been migrated: PS:FONTRD.FASL.3 PS:HASH.FASL.1 PS:LAUGH.FASL.1 PS:SAVE.FASL.1  Date: 30 November 1982 02:29-EST From: Glenn S. Burke Subject: READLINE To: KMP at MIT-MC cc: FEINBERG at CMU-CS-C, BUG-LISP at MIT-MC The bug is that it simply returns NIL, and does not give an error. It should be complaining about eof in the middle of a line. I think this whole class of things is broken (it doesn't do the right thing with eof in the middle of an atom, for instance, and the only reason semicolon-comments do anything at eof is that they are kludged grossly). I'm not sure that this has always been true.  Date: Monday, 29 November 1982 09:49-EST Sender: ZVONA at MIT-OZ From: ZVONA at MIT-MC To: bug-lisp at MIT-OZ cc: user-accounts at MIT-OZ Could some one do an INQUIR entry for LIBLSP? Thanks.  Date: 29 November 1982 04:16-EST From: Kent M. Pitman Subject: READLINE To: FEINBERG at CMU-CS-C cc: BUG-LISP at MIT-MC Date: 28 November 1982 02:11-EST (Sunday) From: FEINBERG at CMU-CS-C To: Bug-Lisp Re: READLINE When using READLINE to read a file, if the last line does not contain a carriage-return, that line is not read. Clearly either a carriage-return or end-of-file should work as a line terminator. ----- It is not "clear" that it should. It is only your belief that it should. It is the belief of the language spec, however, that it should not. Maclisp thinks a line should be ended with a newline character. It might be that the language spec should be changed sometime, but in any case, the observed behavior is not a bug. -kmp  Date: 28 November 1982 02:11-EST (Sunday) From: FEINBERG at CMU-CS-C To: Bug-Lisp at MIT-MC Subject: READLINE When using READLINE to read a file, if the last line does not contain a carriage-return, that line is not read. Clearly either a carriage-return or end-of-file should work as a line terminator. --Chiron  Date: 25 NOV 1982 1701-PST From: JONL at PARC-MAXC Subject: Re: Allocation during Fasload? To: FEINBERG at CMU-CS-C, Bug-Lisp at MIT-MC cc: JONL In response to the message sent 25 November 1982 17:14-EST (Thursday) from FEINBERG@CMU-CS-C No. But beware: many files have a form in them near the beginning which looks something like (ALLOC ...)  Date: 25 November 1982 17:14-EST (Thursday) From: FEINBERG at CMU-CS-C To: Bug-Lisp at MIT-MC Subject: Allocation during Fasload? Howdy! When I load a random FASL file, does the fasloader automatically change my allocation (like list space)? --Chiron  Date: Tuesday, 23 November 1982 18:31-EST Sender: CSTACY at MIT-OZ From: CSTACY at MIT-MC To: Bug-Lisp at MIT-OZ Where is Lisp 2122?  Date: 22 November 1982 02:46-EST (Monday) Sender: MARTY at MIT-OZ From: Martin David Connor To: GSB at ML Subject: A minor update for Top-20 Maclisp Cc: Bug-Lisp at MC I found the following in MC:L;STATUS > Specifically in the (sstatus ttyint ... ) code: ... SSTIN1: HRRM B,(TT) ... IFN D20,[ POP P,TT ;RESTORE TTSAR ROT F,1 ;RESTORE CHARACTER CAIE F,3 ;DON'T ALLOW USE TO ASSIGN ^C ==> CAILE F,26. ;TOPS-20 ONLY SUPPORTS TO ^Z | JRST UNLKTRUE ;RETURN TRUE, BUT DON'T DO TELL THE OP SYS | ... | = Well, this perhaps used to be true, but is no longer. these days, one can assign several other characters. I think the update I would suggest is to remove the test altogether, since the bit values for the interrupt word on the 20 after the altmode would have to be special cased. For my particular application I need to get control at interrupt I made myself a patched lisp until this is changed, and I indeed am able to get the altmode interrupt properly.  Date: 21 November 1982 19:43-EST (Sunday) From: FEINBERG at CMU-CS-C To: George J. Carrette Cc: BUG-LISP at MIT-MC Subject: "Howdy!" Howdy! Yes, they let me hack the directory at CMU. In fact, I am in charge of maintaining Maclisp on six TOPS-20 systems at CMU. The problem was that I didn't realize that people built sharable things with LISP.EXE, I thought that only sharable things were made with BBLISP.EXE. I was corrected on this. --Chiron  Date: Sunday, 21 November 1982 15:53-EST From: Leonard N. Zubkoff To: George J. Carrette Cc: BUG-LISP at MIT-MC, FEINBERG at MIT-OZ Subject: "Howdy!" The directory is essentially frozen on CMUC. The directory here is only touched by Scott Fahlman and myself; other persons are only allowed to touch it with the explicit permission of either Scott or I. This state of affairs became necessary after a number of situations where importing new versions of packages from MIT caused our system to break. At this point in time, all our efforts are directed towards bringing Spice Lisp and Common Lisp up, and we view it as safer to live with the known problems in our current MacLisp than to expend the effort to remain current. We are using MacLisp very heavily as a tool in these other efforts, and having a stable system is absolutely essential. Leonard  Date: 21 November 1982 15:35-EST From: George J. Carrette Subject: "Howdy!" To: FEINBERG at MIT-OZ cc: BUG-LISP at MIT-MC I was wondering, do they let you hack the directory at CMU? If so, why was it that you had to find out "experimentaly" as you put it, that is was bad to delete versions of LISP.EXE?  Date: 21 November 1982 02:47-EST (Sunday) From: FEINBERG at CMU-CS-C at MIT-MC To: MOON at SCRC-TENEX Cc: Bug-CRTSTY at MIT-OZ, Bug-Lisp at MIT-OZ, Bug-LispM at MIT-OZ, Bug-Oz at MIT-OZ Subject: Two new mailing lists Howdy! Date: Sunday, 21 November 1982 02:22-EST From: MOON at SCRC-TENEX To: Chiron cc: Bug-CRTSTY at MIT-OZ, Bug-Lisp at MIT-OZ, Bug-LispM at MIT-OZ, Bug-Oz at MIT-OZ Re: Two new mailing lists Date: 21 November 1982 01:16-EST (Sunday) From: Chiron Supdup-Extentions@MIT-OZ It would be easier to remember the name of this mailing list if you would follow normal English spelling. That's "extensions". Right. Now it is SUPDUP-EXTENSIONS@OZ. It works for DM, MC, and ML, too.  Date: Sunday, 21 November 1982 02:22-EST From: MOON at SCRC-TENEX To: Chiron Cc: Bug-CRTSTY at MIT-OZ, Bug-Lisp at MIT-OZ, Bug-LispM at MIT-OZ, Bug-Oz at MIT-OZ Subject: Two new mailing lists In-reply-to: The message of 21 Nov 1982 01:16-EST () from Chiron Date: 21 November 1982 01:16-EST (Sunday) From: Chiron Supdup-Extentions@MIT-OZ It would be easier to remember the name of this mailing list if you would follow normal English spelling. That's "extensions".  Date: 21 November 1982 01:16-EST (Sunday) From: Chiron To: Bug-CRTSTY at MIT-OZ, Bug-LispM at MIT-OZ, Bug-Oz at MIT-OZ, Bug-Lisp at MIT-OZ Subject: Two new mailing lists Howdy! There are two new mailing lists at Oz: Maclisp-Maintainers@MIT-OZ This purpose of this mailing list is to coordinate bug fixes and day to day maintaince of Maclisp on Oz and perhaps other MIT sites. If anyone is planning to touch the directory on Oz, they should send a note to this list letting the experts know what is up, so the experts have the opertunity to tell you if the planned activities will interfere with the stability of Maclisp. In particular, any modifications to LISP.EXE or BBLISP.EXE at Oz should be cleared through this list. Supdup-Extentions@MIT-OZ The purpose of this mailing list is to discuss extentions to the Supdup protocol. If you are not familiar with the twenex mailbox system and would like to be added to either of these mailing lists, send mail to Feinberg@Oz, and I'll add you. --Chiron  Date: 21 November 1982 00:36-EST From: David C. Plummer Subject: Scheme broken on OZ today. To: FEINBERG at CMU-CS-C cc: GLR at MIT-MC, BUG-LISP at MIT-OZ, GJC at MIT-OZ, GJS at MIT-OZ, HAL at MIT-OZ, HANSON at MIT-OZ, RWK at SCRC-TENEX The canonical sources currently live on MC, but should be moved to Oz eventually. Be careful. Every change that is made must be guarenteed not to break MACSYMA or SCHEME. There is much more chance for randomness (or willingness to change things) on OZ than there is on MC.  Date: 21 November 1982 00:32-EST From: David C. Plummer Subject: Re: Scheme broken on OZ today. To: RWK at SCRC-TENEX cc: DCP at MIT-MC, GJC at MIT-MC, GLR at MIT-OZ, FEINBERG at MIT-OZ, HAL at MIT-OZ, GJS at MIT-OZ, HANSON at MIT-OZ, BUG-LISP at MIT-OZ A kludge around that is to map your DATA space into the upper 2/3 or whatever of every PROGRAM space. Then it simply doesn't MATTER what's in the left half of AC's, and everything acts just like before, wrt data. Unfortunately, more kludges. They may even work!! Still, I can think of better things to do with my time than fooling with -20's. So can I, but we have to dirty our toes every now and then; as a reminder if nothing else.  Date: 21 November 1982 00:05-EST (Sunday) From: FEINBERG at CMU-CS-C at MIT-MC To: GLR at MIT-MC Cc: BUG-LISP at MIT-OZ, GJC at MIT-OZ, GJS at MIT-OZ, HAL at MIT-OZ, HANSON at MIT-OZ, RWK at SCRC-TENEX Subject: Scheme broken on OZ today. Howdy! I am currently helping out in the maintainence of Maclisp on Oz. GSB is, I believe, considered in charge. The canonical sources currently live on MC, but should be moved to Oz eventually. I agree with GJC, Maclisp should remain stable right now. Make an XLISP, and use that. Apparently BBLISP.EXE and LISP.EXE are two very special files, and updating them can really break the world (as I found out the hard way). Perhaps this discussion should move off of Bug-Lisp and onto a local Oz mailing list of some sort. --Chiron  Date: 20 Nov 1982 2345-EST From: Robert W. Kerns Subject: Re: Scheme broken on OZ today. To: DCP at MIT-MC cc: GJC at MIT-MC, GLR at MIT-OZ, FEINBERG at MIT-OZ, HAL at MIT-OZ, GJS at MIT-OZ, HANSON at MIT-OZ, BUG-LISP at MIT-OZ, RWK at SCRC-TENEX In-Reply-To: Your message of 20-Nov-82 2232-EST You don't have to write a new Lisp if your DATA space is address space 0, at least not on CAR and CDR's account. Your two instructions, one loading and the other setting the left half, already exist as HRRZ and HLRZ. But there are other problems: Arrays and lots of other things use indirection, which won't win. A kludge around that is to map your DATA space into the upper 2/3 or whatever of every PROGRAM space. Then it simply doesn't MATTER what's in the left half of AC's, and everything acts just like before, wrt data. That's not so hard as a real extended-address space Lisp, and means code no longer trades off against data, which is a real problem for MACSYMA on the -10. Still, I can think of better things to do with my time than fooling with -20's. -------  Date: 20 November 1982 22:25-EST From: David C. Plummer Subject: Re: Scheme broken on OZ today. To: RWK at SCRC-TENEX cc: GJC at MIT-MC, GLR at MIT-OZ, FEINBERG at MIT-OZ, HAL at MIT-OZ, GJS at MIT-OZ, HANSON at MIT-OZ, BUG-LISP at MIT-OZ You want to make separate code and data spaces for the current MACLISP, do you?? Well, FORGET IT!!! Perhaps you should get Gorin's book on TWENEX assembler and read the section on extended addressing. Basically, CAR and CDR won't work. Well, it might have a prayer if the CODE for CAR and CDR were in the DATA section. This goes for all other code that does a CAR or CDR. Well, then again, you might be able to get around that by making CAR and CDR be two instructions instead of one. The second instruction would set the left half to be the DATA section. Kludge, kludge, kludge. Now what about all those other primitive LISP operators?? That is not the right solution. The right solution is to reimplement 'Lisp' for extended addressing machines. For 2060's this would give you 31 address spaces (assuming you can't do much useful stuff in section 0). On the Jupiter I think the number jumps to 4095 (and then all you need is several dozen disk drives for paging). I know of at least one effort to write an extended addressing superset of Common Lisp. How much MACLisp code will need to be modified or rewritten probably depends on how well it was written for portability in the first place. My feable knowledge of Common Lisp forces me to make the following warnings: * Expect your programs to get bigger. CONSes will take up two words instead of one. * Fixnums may shrink to 32 (or even 30) bits. Overflow will cons bignums. * Expect arithmetic operations to slow down. I think Common Lisp does generic arithemetic. If so, a simple + on non-declared numbers needs to check the arguments and value (even in compiled code).  Date: Saturday, 20 November 1982 18:03-EST Sender: GJC at MIT-OZ From: GJC at MIT-MC To: GLR at MIT-OZ Cc: BUG-LISP at MIT-OZ, FEINBERG at MIT-OZ, GJS at MIT-OZ, HAL at MIT-OZ, HANSON at MIT-OZ, RWK at SCRC Subject: FLAME warning: Scheme broken on OZ today. In-reply-to: The message of 20 Nov 1982 15:43-EST from GLR You would patch Maclisp without knowing who was doing maintenance and where the canonical sources are? Sigh... As of now there is no Local Maclisp maintenance, and no canonical sources. When OZ came up I was to install Maclisp here from sources on MC and XX, but instead MARTY cleverly arranged for people outside of MIT and the LAB to "help him out" thereby contributing to the present inconsistent mess. However, things seemed to run anyway, so it wasn't worth hassling, considering the amount of other work to do on other projects. On the other hand, when I try to run SCHEME on OZ to verify examples run in other implementations (in this case on the VAX), I don't like to end up spending lots of time hassling MACLISP and lack of DISK SPACE on OZ. (Who ?designed? the present disk-structure settup here anyway? With all those RP06's, why are we losing? Doesn't anybody GFR?) If you have problems with Maclisp on TOPS-20, first try to get around them by loading LISP-LEVEL stuff, and dumping out your own version using SHARE. The mere fact that you had INTERLOCK problems with trying to patch LISP.EXE should have told you that somebody was depending on it. The present problem is just that the most experienced Maclisp user/implementor people here at the labs don't find it worthwhile to fix maclisp bugs in the MIDAS sources. Mainly because they are responsible for or depend on stable large systems in the present versions of Maclisp, and because they have new implementations of lisp systems to work on. To push forward the maclisp world for the sake of small changes is conterproductive, as a small time spent by inexperienced hackers can force the spending of considerable time by experienced hackers. This is a very expensive form of MAKE-WORK. (Real $$$ expensive too.) -GJC p.s. In other words. Cool it for a while in the Maclisp directory. After the Thanksgiving break you can talk with GSB, myself, and others about what changes are really needed.  Date: Saturday, 20 November 1982 15:47-EST Sender: KWH at MIT-OZ From: KWH at MIT-MC To: Dick at MIT-OZ Cc: bug-emacs at MIT-OZ, bug-lisp at MIT-OZ, bug-oz at MIT-OZ In-reply-to: The message of 19 Nov 1982 16:31-EST from Dick I have been screwed by this too-- one interim fix might be to have LEDIT write its save-files to SRC: instead of PS: (Actually the problem should be fixed rather than being patched like this....) Ken  Date: Saturday, 20 November 1982 15:43-EST Sender: GLR at MIT-OZ From: GLR at MIT-MC To: GJC at MIT-OZ Cc: BUG-LISP at MIT-OZ, FEINBERG at MIT-OZ, GJS at MIT-OZ, HAL at MIT-OZ, HANSON at MIT-OZ, RWK at SCRC Subject: Scheme broken on OZ today. In-reply-to: The message of 20 Nov 1982 12:46-EST from GJC I am responsible for the SCHEME lossage. Tried patching the binary via a RPLACA on the file system, but the filesystem put LISP.EXE.2130 into limbo instead and SCHEME lost. Even though "Many sites around the country are running perfectly well with old versions of Maclisp," there are bugs in MACLISP: programs that ran on ITS don't run in TOPS-20. Several months ago I sent in a bug report and nothing was done; I patched EXE.2129 and asked where the canonical sources were. EXE.2130 didn't have the patch, so I edited the sources on OZ and tried to repatch EXE.2130, but lost. Who is doing the maintenance? Where are the canonical sources? It is pointless to extend MACLISP even to put in CODE and DATA space; you're begging for a raft of new bugs. The reliability and readibility of COMPLR alone should be persuasive enough to kill that notion. And just for a factor of 2? Jerry  Date: 20 Nov 1982 1323-EST From: Robert W. Kerns Subject: Re: Scheme broken on OZ today. To: GJC at MIT-MC, GLR at MIT-OZ, FEINBERG at MIT-OZ cc: HAL at MIT-OZ, GJS at MIT-OZ, HANSON at MIT-OZ, BUG-LISP at MIT-OZ, RWK at SCRC-TENEX In-Reply-To: Your message of 20-Nov-82 1253-EST I think George's suggestions for what to do for MacLisp are right on the mark. Of the two, separating CODE and DATA is probably the easier. It certainly would make MACSYMA and other large existing programs much happier. Perhaps understandably, I am a proponent of the idea that there shouldn't be any DEVELOPMENT going on in MacLisp. However, supporting existing applications better is worthwhile. Please be careful about stability, however. As with most mature (even elderly) systems, most of the MacLisp programs are not themselves being developed, and sometimes simply cannot be maintained. Let it enjoy its old age in peace, and make it comfortable. I know there are some people at MIT who are doing AI development in MacLisp. I think it's absurd. -------  Date: Saturday, 20 November 1982 12:46-EST Sender: GJC at MIT-OZ From: GJC at MIT-MC To: GLR at MIT-OZ, FEINBERG at MIT-OZ CC: HAL at MIT-OZ, GJS at MIT-OZ, HANSON at MIT-OZ, BUG-LISP at MIT-OZ Subject: Scheme broken on OZ today. It is not a good thing to hack the Maclisp directory at will on OZ without considering what programs depend on it. This goes for *any* changes, whether as seemingly trivial as assembling a new version with a trivial change, patching the binary, or making changes to the lisp sources. Mumble. What can I say, here are a few points to consider: (1) Many sites around the country are running perfectly well with old versions of Maclisp. (2) There have been no significant functional change in Maclisp in a while. (3) There are many many untested changes accumulated in the sources. (4) The history of SCHEME in maclisp is frought with lossage like this, inconsistently hacked versions of LISP, COMPLR, macro sources, etc. You want to do some real maclisp hacking? Think about how to do an extended addressing hack with seperate CODE and DATA space. Think about adding a real string primitive datatype. These two things would significantly extend the useful life of maclisp. -GJC  Date: Friday, 19 November 1982 16:31-EST Sender: DICK at MIT-OZ From: Dick@MIT-MC To: bug-oz at MIT-OZ, bug-lisp at MIT-OZ, bug-emacs at MIT-OZ A particularly annoying problem that comes up because the disk gets full all of the time happens when using LEDIT from LISP. If the emacs subfork gets an error trying to write a file because the disk is full, it pops up into LISP and YOU CANNOT RESTART IT. As a result, you loose all the editing you had done since the last save. This should be changed so that you can restart it after you free up some disk space (I have no idea whether the fix has to be in EMACS or more likely in LISP). Also we really need to do something about running with so little overhead all the time. it is a real pain. Dick Waters  Date: 18 November 1982 12:19-EST From: Kent M. Pitman To: REM at MIT-MC cc: BUG-LISP at MIT-MC Date: 18 November 1982 09:49-EST From: Robert Elton Maas Sometimes when I ctrl-S to stop output it never comes back on even though I've typed new stuff which echos just fine -- what do I have to type to undo a ctrl-S? (I conjecture the read-eval-print loop turns it back on but ordinary READLINE in a user program doesn't.) ----- That's right, READLINE will not re-enable output. The mechanism is: Output is disabled by setting the variable ^W (uparrow W, not C-W) to T and re-enabled by setting it to NIL. The control character c-W sets ^W to T. The control character c-V sets ^W to NIL. The control character c-S, like c-W, sets ^W to T, but has the additional effect that when seen by the reader at READ (not READLINE, TYI, etc) time sets ^W back to NIL. The reason that it only works at READ time is that it works via STATUS MACRO; ie, (STATUS MACRO #^S) => +INTERNAL-^S-MACRO which is described roughly by (LAMBDA (NIL NIL) (SETQ ^W NIL) NIL). Note that this macro is a splicing macro and consequently causes a token break. (AB) is read as (A B) while (AB) is read as (AB). Note further that (READLINE) does not ignore any of the characters , , or . This may imply that you want to write your own READLINE that does (a) discard  and  when it sees them and (b) set ^W back to NIL when it sees  and then discard the . Hope this answers some of your questions along these lines. --kmp  Date: 18 November 1982 09:49-EST From: Robert Elton Maas To: BUG-LISP at MIT-MC Sometimes when I ctrl-S to stop output it never comes back on even though I've typed new stuff which echos just fine -- what do I have to type to undo a ctrl-S? (I conjecture the read-eval-print loop turns it back on but ordinary READLINE in a user program doesn't.)  Date: 17 November 1982 16:18-EST From: Alan Bawden Subject: USRHUNK bug To: BUG-LISP at MIT-MC cc: KWH at MIT-MC With (STATUS USRHU) set to a predicate that always returns T. And (STATUS SENDI) set to a COMPLR-compiled LEXPR. Doing: (setq a (hunk 1 2 3)) (delete a (list (hunk 4 5 6) a)) JUMPs to location 0. This is because .DELETE keeps the MEMBER subr in accumulator D, but nobody bothers to save D when calling out to the SENDI handler (and because the standard .LCALL stuff makes free with D). Actually I don't see any comments in the source to the effect that MEMBER, MEMQ, etc. are supposed to preserve D.  Date: Wednesday, 17 November 1982 15:46-EST Sender: DICK at MIT-OZ From: Dick@MIT-MC To: *its at MIT-OZ, info-lispm at MIT-OZ, info-lisp at MIT-OZ Subject: LetS -- a new looping macro for lisp LetS is a new Lisp looping macro which makes it possible to write a wide class of loops as simple expressions. For example, in order to sum up the positive elements of the one dimensional array A one need only wirte: (Rsum (Fgreater (Evector A))) LetS is described fully in AIM-680 which has just appeared. I will give a talk describing LetS in a few weeks. LetS is compatably with both MacLisp and LispMachine Lisp. It exists on the directories LIBSLP and LMLIB. Try it you will like it. Dick Waters Send all comments etc. to Dick@OZ.  Date: 15 November 1982 03:23-EST From: Glenn S. Burke To: JPG at MIT-MC cc: BUG-LISP at MIT-MC, UCBKIM.jkf at UCB-C70 If there is no errset or the error will be stacked anyway because of the setting of the variable ERRSET, then the error-handling function gets called, and it prints the error message itself, using the ERRPRINT function. If the error is not going to be stacked, then if the errset specified that the error should be printed, it is printed using ERRPRINT (effectively), without going into the handler, and the errset thrown to. The result of this is that with errset one might not get specially-formatted error messages because the handler doesn't get called at all. Conversely, if you arrange for the handler to get called by (setq errset 'car) or somesuch nonsense, it has no way of finding out if it should print the message or not, or enter debugger or break loop or not.  Date: 14 November 1982 23:51-EST From: Jeffrey P. Golden To: BUG-LISP at MIT-MC cc: JPG at MIT-MC, UCBKIM.jkf at UCB-C70 I've unfortunately held onto this message for some time, so I'm not sure JKF still needs the info. He was planning on implementing an IO-LOSSAGE handler for Franz Lisp. Do any of you have any info on the following? Date: 15-Oct-82 11:14:44-PDT (Fri) From: UCBKIM.jkf@Berkeley Subject: io lossage To: JPG@MIT-MC In-Reply-To: Your message of 12 October 1982 05:26-EDT I am trying to figure out if what you do is possible in Franz Lisp. Our error system is easy to describe (see page 10-2 of the Franz manual). An error hander can be activated on i/o type errors and it can print the appropriate message on file not found errors, but it cannot say: pop to next errset, but don't print any message because I've already printed something. [actually based on the implementation of errsets, I know a way it could be done, but there is no documented method of doing it] how does maclisp do this? Does the 'errset' never print a message, and some error handler function always print the message?  Date: 9 November 1982 20:18-EST From: William G. Dubuque Sender: BIL at MIT-MC Subject: Is JONL back? To: BUG-LISP at MIT-MC Here's a DEFUN& bug I thought was fixed long ago: (defun lose (a &aux (b (f a)) (c (g b c))) (list a b c)) This expands into code which computes c <- (g b c) before a <- (f a). I wish someone would fix that code once and for all.  Date: 6 November 1982 02:40-EST (Saturday) From: Chiron To: Bug-OZ at MIT-OZ, Bug-Lisp at MIT-OZ CC: Dick at MIT-OZ, EB at MIT-OZ Subject: Lisp 2130 Howdy! There is a new version of LISP and BBLISP out with the JFN problem fixed. Thanks to JSOL there is also a new COMPLR out based in the new Lisp. Stay tuned. --Chiron  Date: 5 November 1982 01:33-EST (Friday) Sender: GUMBY at MIT-OZ From: David Vinayak Wallace To: bug-lisp at mc Subject: Cursorpos bug (cursorpos 'c) bombs out under twenex if you don't set your terminal type. david  Date: 4 November 1982 16:55-EST (Thursday) From: FEINBERG at CMU-20C at MIT-ML To: Dick at MIT-MC Subject: Restricted JFNs Cc: bug-maclisp at MIT-OZ Howdy! This was supposed to be fixed in the latest Maclisp. I will check and make sure Oz has the most recent version. --Chiron  Date: 4 Nov 1982 1646-EST From: Ed Barton To: Dick at MIT-MC cc: bug-maclisp at MIT-OZ, EB at MIT-OZ Date: Thursday, 4 November 1982 14:28-EST Sender: DICK at MIT-OZ From: Dick@MIT-MC To: bug-maclisp at MIT-OZ On the 20 (i.e. OZ) both lisp and the complr open their files in a restricted mode that makes it impossible for anything else to touch the files. For example, the exec won't even show that they exist or anything. Most of the time this dosn't matter, but consider the following situation. The compiler dies in a strange state, and you are trying to figure out what is going on. Under ITS you could always go into ddt and look at the _unfa_ file in order to get some idea about what was going on. On OZ you cannot do that becuase though the file is there, it is restricted and you cannot touch it. In particular, you cannot close it, so when the complr fork is killed, the file is automatically deleted. It seems to me that things would be a great deal more convenient if lisp in general and the complr in particular just opened files normally. Dick Waters Does nobody fix LISP bugs? I sent numerous bug reports about this years ago and the response from JONL was that LISP didn't do what LISP in fact does, that is, open the JFN in restricted mode. Then a few months later someone (on the west coast, I believe) ran into the same problem and got the same response, but tracked down the place IN THE CODE where LISP was opening its JFNs in restricted mode. Now it seems to me that once the offending piece of code has been identified, that is sufficient both to prove that LISP is guilty of this paranoid behavior and to show the implementors how to fix it. But No.... I just opened a file with Lisp on OZ and its JFN didn't even show up in the exec's @i files printout. SYSDPY told me it was there, though, assigned in restricted mode just like the old bug. -------  Date: Thursday, 4 November 1982 14:28-EST Sender: DICK at MIT-OZ From: Dick@MIT-MC To: bug-maclisp at MIT-OZ On the 20 (i.e. OZ) both lisp and the complr open their files in a restricted mode that makes it impossible for anything else to touch the files. For example, the exec won't even show that they exist or anything. Most of the time this dosn't matter, but consider the following situation. The compiler dies in a strange state, and you are trying to figure out what is going on. Under ITS you could always go into ddt and look at the _unfa_ file in order to get some idea about what was going on. On OZ you cannot do that becuase though the file is there, it is restricted and you cannot touch it. In particular, you cannot close it, so when the complr fork is killed, the file is automatically deleted. It seems to me that things would be a great deal more convenient if lisp in general and the complr in particular just opened files normally. Dick Waters  Date: 3 NOV 1982 2058-PST From: JONL at PARC-MAXC Subject: 4th level indirection -- maybe you haven't yet seen this? To: info-lisp at MIT-AI, info-lispm at MIT-AI cc: gls at MIT-AI, rpg at MIT-MC Date: 3 Nov. 1982 1:49 pm PST (Wednesday) From: Treichel.PA Subject: Lisp Song To: CIS^ Reply-To: Treichel Have you seen this? Jeanie --------------------------- Date: 3 Nov. 1982 4:23 pm EST (Wednesday) From: Gafter.Henr Subject: LISP song To: AllWhimsy^.pa, Language^, Gottwald, KAnderson cc: Gafter This was in the uucp bboard net.jokes recently. ------------------------------------------------------- From decvax!utzoo!utcsrgv!roderick Mon Nov 1 14:24:35 1982 Another Glitch in the Call ------- ------ -- --- ---- (Sung to the tune of a recent Pink Floyd song.) We don't need no indirection We don't need no flow control No data typing or declarations Hey! Did you leave the lists alone? Chorus: All in all, it's just a pure-LISP function call. We don't need no side effect-ing We don't need no scope control No global variables for execution Hey! Did you leave those args alone? (Chorus) We don't need no allocation We don't need no special nodes No dark bit-flipping in the functions Hey! Did you leave the bits alone? (Chorus) We don't need no compilation We don't need no load control No link edit for external bindings Hey! Did you leave that source alone? (Chorus, and repeat) ------------------------------------------------------------  Date: 3 November 1982 21:32-EST From: Christopher C. Stacy Subject: [TONYH: forwarded] To: BUG-LISP at MIT-MC Date: 29 October 1982 17:56-EDT From: TONYH at MIT-AI To: BUG-PROGRAM at MIT-AI I have three little problems which defy all of the info we have here. If anyone can offer any help or suggestions we'd be very grateful.: (1) Macros which are compiled in one file cannot be called from another file if the latter is also compiled. The error message is MACRO NOT PERMITTED IN UUO CALL. We think it must be something to do with the declarations made at the tops of files for the compiler's sake, but we have no information about them, and all our guesses based on MacLisp source files have failed; (2) We have tried to make the tilde a special readmacro. The idea is that special comments within a file (they're quoted strings) should be prefaced by the tilde, and that when the file is loaded the readmacro will place these comments into a HELP system. The file containing the readmacro definition is compiled, and the idea works well as long as the files subsequently loaded (those with the tilde-ised comments in) are not compiled. The readmacro won't work on FASL files , including its own file. Also, does anyone happen to know how to stop typed-in characters from being echoed back to the terminal? I'm trying to build alittle keypad- driven editor, but my keypad (VT52) sends three characters at once, which I'd rather not see! Oh - I've just remembered another one. Our MacLisp occasionally has fits of GC_DAEMON errors involving STRING-COMPRESS-SPACE, and frankly none of us can understand the source code which might tell us why... Many thanks in advance to anyone who can help, from the very heart of quaint little old England. Tony.  Date: 1 Nov 1982 0055-PST From: David Eppstein Subject: SUBFORK module (LEDIT) To: Bug-LISP at MIT-MC The lines in SI:GIVUP-TTYINTS that set the inferior fork's capabilities are switched, so that the fork gets no caps, causing LEDIT to lose big. Old code: (jsys #.EPCAP handle (boole 2 1_18 cap_inferior) (boole 2 1_18 cap_poss_inf) 1) Correct code: (jsys #.EPCAP handle (boole 2 1_18 cap_poss_inf) (boole 2 1_18 cap_inferior) 1) David -------  Date: 31 October 1982 16:04-EST From: George J. Carrette Subject: lossage after lossage To: TONYH at MIT-AI cc: BUG-LISP at MIT-MC It doesn't help to be superstitious about Maclisp. In fact, it helps a lot to keep things as simple as possible, not using a feature unless you really understand what it is doing. Here is what I recommend: (1) In one file, put your "compile-time" environment. This includes macros and readmacros, and special declarations, e.g. (herald macros) (defvar helplist) (defun help-comment-readmacro () (push (cons (read) (read)) helplist)) (setsyntax #/~ 'macro 'help-comment-readmacro) (defmacro helplist-begin () (setq helplist ()) (defmacro helplist-end () `(defprop help ,helplist comments)) ;; Note that I didn't bother with defining a fancy DEFREADMACRO, since ;; it just isn't worth the trouble. (2) Then your source-file would look like : (eval-when (eval compile) (or (get 'macros 'version) (load "macrofile"))) (helplist-begin) .... stuff stuff stuff ... (helplist-end) (3) Do not use the Maclisp string package. It is has proven to be completely unreliable. An alternative, which has been used in a text editor written in maclisp, is in "GJC;CHAR >" on MIT-MC. Someday a reasonable string may be released as part of the Maclisp distribution, until then you should be able to get by fine with something like "GJC;CHAR >" Note that this file should be loaded at COMPILE and RUNTIME, since it includes declarations, readmacros, and code. -gjc  Date: 31 October 1982 13:05-EDT From: TONYH at MIT-AI To: BUG-LISP at MIT-AI Dear JONL - Thank you very much for your help. Unfotunatley, in trying to make use of it ZI seem to have made things worse, to such an extent that the system itself pleaded with me to call you again. I'd better show you what I'm doing - you'll probably see at a glance what horrors I'm perpetrating on your long-suffering MacLisp: (declare (SETQ DEFMACRO-FOR-COMPILING 'T DEFMACRO-DISPLACE-CALL 'T) (special helplist)) ;;; During loading, the tilde (~) readmacro allows the special comments ;;; in this file to be stored for later access by the APROPOS function. ;;; On the property-list of 'HELP, under the property 'COMMENTS, will ;;; be found a list of the comments, each element being a dotted pair ;;; of the unquoted part of the comment and the quoted part. (eval-when (compile load) (and (status feature COMPLR) (own-symbol DEFREADMACRO /~-readmacro))) ;superstition... (eval-when (eval load compile) (setq helplist nil) (defmacro defreadmacro (char &rest body) (let ((macro-name (symbolconc char '-readmacro))) (setsyntax char 'macro macro-name) `(defun ,macro-name () ,.body))) (defreadmacro /~ (let* ((/^q t) (comment `(,(read) ,[atsign](read)))) (push comment helplist) t))) [atsign] intended to represent the symbol on this machine! Then follows the comment itself: ~MSG "Simple formatter..." ...and the function it is supposed to describe - also a macro. Then, a line I added in the belief that it was the kind of thing you were advising: (putprop 'help '#.helplist 'comments) That's the end of the file. I then tried to compile it: ;BKPT DATA So I did: $p (COMMENT **ERROR** #75526 Unrecognizable datum __ Collecatoms in function FOO) ; %%%%%%%%%%%%%%%%%%%%COMPILER ERRO(R - CALL JONL%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ;BKPT BARF Ugh, what have I done? Sorry to bother you with this again so soon. I would have flogged on with it on my own except for what the machine said just there. As to your other valuable help - yes, I had just about reached the same conclusion regarding how to re-use "compiled" macros. I just hoped, (we are riddled with superstition here) that there might be a clever way around the problem. We seem to have the May '82 version of STRING, but I'll check that the dates are right. And Lord alone knows what happened to any notes you included with the source tapes - such things go through many administrative hands before reaching poor hackers like us! Thank you again, anyway. Tony.  Date: 30 October 1982 21:26-EDT From: Howard I. Cannon Subject: [TONYH: forwarded] (Have fun!) To: BUG-LISP at MIT-MC Date: 29 October 1982 17:56-EDT From: TONYH at MIT-AI To: BUG-PROGRAM at MIT-AI I have three little problems which defy all of the info we have here. If anyone can offer any help or suggestions we'd be very grateful.: (1) Macros which are compiled in one file cannot be called from another file if the latter is also compiled. The error message is MACRO NOT PERMITTED IN UUO CALL. We think it must be something to do with the declarations made at the tops of files for the compiler's sake, but we have no information about them, and all our guesses based on MacLisp source files have failed; (2) We have tried to make the tilde a special readmacro. The idea is that special comments within a file (they're quoted strings) should be prefaced by the tilde, and that when the file is loaded the readmacro will place these comments into a HELP system. The file containing the readmacro definition is compiled, and the idea works well as long as the files subsequently loaded (those with the tilde-ised comments in) are not compiled. The readmacro won't work on FASL files , including its own file. Also, does anyone happen to know how to stop typed-in characters from being echoed back to the terminal? I'm trying to build alittle keypad- driven editor, but my keypad (VT52) sends three characters at once, which I'd rather not see! Oh - I've just remembered another one. Our MacLisp occasionally has fits of GC_DAEMON errors involving STRING-COMPRESS-SPACE, and frankly none of us can understand the source code which might tell us why... Many thanks in advance to anyone who can help, from the very heart of quaint little old England. Tony.  Date: Friday, 29 October 1982 20:21-EDT Sender: KLOTZ at MIT-OZ From: Leigh L. Klotz To: bug-maclisp at mc Subject:Message mailed to strange address Date: Friday, 29 October 1982 17:56-EDT From: TONYH at MIT-AI To: BUG-PROGRAM at MIT-AI I have three little problems which defy all of the info we have here. If anyone can offer any help or suggestions we'd be very grateful.: (1) Macros which are compiled in one file cannot be called from another file if the latter is also compiled. The error message is MACRO NOT PERMITTED IN UUO CALL. We think it must be something to do with the declarations made at the tops of files for the compiler's sake, but we have no information about them, and all our guesses based on MacLisp source files have failed; (2) We have tried to make the tilde a special readmacro. The idea is that special comments within a file (they're quoted strings) should be prefaced by the tilde, and that when the file is loaded the readmacro will place these comments into a HELP system. The file containing the readmacro definition is compiled, and the idea works well as long as the files subsequently loaded (those with the tilde-ised comments in) are not compiled. The readmacro won't work on FASL files , including its own file. Also, does anyone happen to know how to stop typed-in characters from being echoed back to the terminal? I'm trying to build alittle keypad- driven editor, but my keypad (VT52) sends three characters at once, which I'd rather not see! Oh - I've just remembered another one. Our MacLisp occasionally has fits of GC_DAEMON errors involving STRING-COMPRESS-SPACE, and frankly none of us can understand the source code which might tell us why... Many thanks in advance to anyone who can help, from the very heart of quaint little old England. Tony.  Date: 29 OCT 1982 1700-PDT From: JONL at PARC-MAXC Subject: Your recent note on MacLisp errors To: TONYH at MIT-AI cc: BUG-LISP at MIT-MC Your questions (1) and (2) arise from misunderstanding how and when macros are applied (both readmacros and interpreter/compiler macros). 1) Macros are never "called" in the sense that we think of calling a funciton -- they are "expanded" by the interpreter and compiler, but of course if they are not available to the compiler when compiling some file, then no expansion can be done, and the compiler will defaultly assume that the unknown name stands for a function call (rather than for some macro to be expanded). 2) when READing a file, the s-expressions are stored as ascii text, and the readmacro characters are invoked when such character is encountered by the READer; FASL files, on the contrary, store either the compiled versions of programs, or a special internal-format for other s-exressions. Perhaps a reasonable approach is for the tilde macro merely to append to some global list, which is then output near the end of your file. Thus both ascii files being READ and compile dFASL files would have a consistent representation of what is wanted in the HELP system (namely, the list of goodies which was produced by READing the ffile in the first place). As for deletion of the echo, it will depend on what kind of system you are using TOPS10 or TOPS20. If the latter, you can turn of echoing by an appropriate STATUS call which sets the bits in the TOPS20 echocontrol words; There may be some explanation of this (i.e., the extended STATUS calls for TOPS20) in the note which I used to attach to the distributed MacLisp tapes. As for the GCDAEMON reported errors, it sounds like you have a copy of the STRING package from early to mid 1980. Many bugs in it were fixed in late 1980 and very early 1981, so these problems should go away if you can get the current distribution (which was supposed to have taken place just as I was leaving MIT in mid March of this year.) More hints on problems (1) and (2) Thus usual procedure for using "compiled" macros is to seperate them out into a file by themselves, and have them loaded into the compiler each time you compile some file which might use some of them. Admittedly this is not quite as nice as defining the macros where they might "naturally" occur, but . . . Suppose you have your tilede macro collect some data into TILDELIST. Then at the end of the file you could put a form (SETQ DATASTUFF '#.TILDELIST) this wouold be one way of insureing that DATASTUFF would have the save value after loading the FASL file as when loading thee source file.  Date: 29 October 1982 18:17-EDT From: Alan Bawden Subject: [TONYH: forwarded] (bug-PROGRAM??????) To: BUG-LISP at MIT-MC Date: 29 October 1982 17:56-EDT From: TONYH at MIT-AI To: BUG-PROGRAM at MIT-AI I have three little problems which defy all of the info we have here. If anyone can offer any help or suggestions we'd be very grateful.: (1) Macros which are compiled in one file cannot be called from another file if the latter is also compiled. The error message is MACRO NOT PERMITTED IN UUO CALL. We think it must be something to do with the declarations made at the tops of files for the compiler's sake, but we have no information about them, and all our guesses based on MacLisp source files have failed; (2) We have tried to make the tilde a special readmacro. The idea is that special comments within a file (they're quoted strings) should be prefaced by the tilde, and that when the file is loaded the readmacro will place these comments into a HELP system. The file containing the readmacro definition is compiled, and the idea works well as long as the files subsequently loaded (those with the tilde-ised comments in) are not compiled. The readmacro won't work on FASL files , including its own file. Also, does anyone happen to know how to stop typed-in characters from being echoed back to the terminal? I'm trying to build alittle keypad- driven editor, but my keypad (VT52) sends three characters at once, which I'd rather not see! Oh - I've just remembered another one. Our MacLisp occasionally has fits of GC_DAEMON errors involving STRING-COMPRESS-SPACE, and frankly none of us can understand the source code which might tell us why... Many thanks in advance to anyone who can help, from the very heart of quaint little old England. Tony.  Date: Wednesday, 27 October 1982 23:52-EDT From: Leonard N. Zubkoff To: Martin David Connor Cc: Bug-Complr at MIT-MC, Bug-Lisp at MIT-MC Subject: Strange interaction between LEDIT and COMPLR on Tops-20 Assuming that the default Ann Arbor Teco terminal type does not have a meta key, then I know the problem very well as I used to have it on my Concept-LNZ with meta key. The fix I used is Teco code in my Emacs init library of the following sort: !* Create Sail Mode and Meta Key Variables. These variables save the ! !* values of FS Sail$ and FS Tty Fci$ so that FS Tty Macro$ can reset them ! !* automatically if Emacs is restarted. ! -1 M.V Zubkoff_Sail_Mode !* Initialize Sail Mode to -1. ! 0 M.V Zubkoff_Meta_Key !* Initialize Meta Key to 0. ! 1: !* Assume Sail Font on Concept-LNZ's. ! !* If the System doen't know what Baud Rate the terminal is using, ! !* set it to 1200 baud. Also, reset FS Sail$ and FS Tty Fci$ from ! !* the variables Zubkoff_Sail_Mode and Zubkoff_Meta_Key. ! @:I*| 2 FS Echo Lines FS OSpeed"E 1200 FS OSpeed' QZubkoff_Sail_Mode"G 1 FS Sail' QZubkoff_Meta_Key FS Tty Fci | FS TTY Macro FS TTY Init I hope this helps. Leonard  Date: 27 October 1982 22:17-EDT (Wednesday) Sender: MARTY at MIT-OZ From: Martin David Connor To: Bug-Lisp at MC, Bug-Complr at MC Subject: Strange interaction between LEDIT and COMPLR on Tops-20 Here is an interesting problem: When using LEDIT, the system recognizes that I have an Ann Arbor, with a Meta key. If I later create a COMPLR fork with ^K, it seems to lose that fact that I have a Meta key when I return to my LEDIT fork. Has anyone else experienced this before? Can anyone suggest a fix? Thanks, Marty; -------  Date: 27 October 1982 16:19-EDT From: George J. Carrette Subject: getting screwed by FLONUM call sequences. To: JLL at MIT-MC cc: BUG-LISP at MIT-MC If you do want to use these for efficiency reasons but you still want generality, then you can use the same macrology and trampolines that numerical code in Macsyma uses, (specifically intended for code which is Macsyma->Lisp translated). The macros are in LIBMAX;NUMERM, the runtime support in MAXSRC;NUMER, and example usage in MAXSRC;ROMBRG and MAXSRC;NDIFFQ. One way to see how it all hangs together would be to try (in Macsyma): F(Y):=ROMBERG(X^2,X,0,Y); COMPILE('F); and see what the generated code is. When you get into stuff like this it actually gets pretty hairy... -gjc  Date: 27 October 1982 03:08-EDT From: Alan Bawden Subject: forwarded for JLL: compiling lisp code To: JLL at MIT-MC cc: BUG-LISP at MIT-MC, GJC at MIT-MC, GSB at MIT-MC, ELLEN at MIT-MC Date: 26 October 1982 11:00-EDT From: Joseph L. Leva Subject: compiling lisp code I'm having trouble compiling the lsubrcall function where the 2nd argument is flonum. The following function works fine in the interpreter but gives an error when run from compiled code. (defun fls (fun a1 a2) ((lambda (fpt) (cond ((null fpt)(displa fun)(error '| has no LSUBR|))) (lsubrcall flonum fpt a1 a2)) (get fun 'lsubr))) The solution is to not use (LSUBRCALL FLONUM ...). Just use (LSUBRCALL T ...). Saying FLONUM tells the compiler that you only plan to call subrs that support an extended calling convention, not just that you plan to call subrs that return flonums. +$ in fact does NOT support this calling convention. Since in fact very few LSUBRs support this calling convention, while ALL subrs support the normal calling convention, you should just use T and forget the FLONUM. I guess the interpreter should have errored rather than looking like it was working.  Date: 27 October 1982 00:10-EDT From: Kent M. Pitman Subject: [Rees: [Ellis: (\ X Y) in SOLVE-DI2]] To: BUG-LISP at MIT-MC Date: Tuesday, 26 October 1982 23:11-EDT From: Jonathan Rees To: KMP, GJC Re: [Ellis: (\ X Y) in SOLVE-DI2] Does this (the \ inconsistency, that is) deserve note on BUG-LISP? ```````````````````` Date: 26-Oct-82 1:20PM-EDT (Tue) From: John R. Ellis To: Nicolau cc: Fisher, , Rees Re: (\ X Y) in SOLVE-DI2 (\ X Y) When Y = 0, the Maclisp SUBR that implements \ for the interpreter gives a different result than the machine instruction that Maclisp uses when it compiles \. Typical, but you should always be wary of dividing by 0 in any compiled language (I'm not saying that's the way things SHOULD BE, just the way they are). ... ----- probably. -kmp  Date: 22 Oct 1982 1500-EDT From: Ed Barton Subject: [Ian G. Macky : overwriting existing files.] To: Bug-Lisp at MIT-OZ @LISP seems to have the same problem as the one fixed here; it refuses to overwrite existing files. It should probably be fixed. --------------- Date: 22 October 1982 12:41-EDT (Friday) Sender: GREN at MIT-OZ From: Ian G. Macky To: Ed Barton Cc: bug-cftp at MIT-OZ, bug-file-server at MIT-OZ Subject: overwriting existing files. It turns out that the FILE server was setting GJ%NEW\GJ%FOU for output files, which was not really the best thing. If you make it just GJ%FOU, then files that have an explicit version number get overwritten, while versionless ones get the next higher number... this seems like the right behavior, so I made the change in FILE.449 here on OZ. --M/MM ------- -------  Date: Sunday, 10 October 1982 16:32-EDT Sender: ALAN at MIT-OZ From: Alan Bawden Subject: using the defstruct :print option. To: DAM at MIT-OZ Cc: BUG-LISP at MC The error messages you were getting were about ?FORMAT being called with the wrong number of arguments, right? This is the usual COMPLR braindamage where you forget to tell it that a function is a lexpr and the first time it discovers you calling that function with a different number of arguments it drops dead. (Despite the fact that just warning you and then continuing would be OK since it hasn't actually produced any incorrect code or anything.) The temporary fix is for you to put a "(DECLARE (*LEXPR ?FORMAT))" somewhere (probably the same place you load defstruct), and to also be sure that you get the format package loaded into your runtime correctly (since ?FORMAT doesn't have an AUTOLOAD property either). BUG-* people: I never noticed this before because the complr on ITS already has FORMAT loaded into it apparently. Could someone do the right thing to give ?FORMAT an args declaration in the compiler so that I don't have to continue to warn people about this? Thanks. I also thought that we had agreed to make ?FORMAT have an AUTOLOAD property since it really is a necessity in using format in MacLisp. -------  Date: Sunday, 3 October 1982, 02:30-EDT From: David Vinayak Wallace Subject: ALLFIL package under 20x To: bug-lisp at mc Has anyone got ALLFIL up under twenex? Any pointers would be appreciated. thanks  Date: 2 October 1982 15:31-EDT From: Alan Bawden Subject: ALPHALESSP: More data To: BUG-LISP at MIT-MC, JPG at MIT-MC, KMP at MIT-MC Date: 1 October 1982 07:01-EDT From: Kent M. Pitman Looks like when the characters match exactly up to the length of the first symbol and the second symbol's pname continues on, the symbol LESSP is returned. Pretty odd. The fix is to patch the MOVEI D,QLESSP at ALPHAL to be MOVE D,VT.ITY It only seems to matter whether D contains NIL or non-NIL except that the contents of D get returned in the special case that JPG discovered.  Date: 1 October 1982 07:01-EDT From: Kent M. Pitman Subject: More data To: BUG-LISP at MIT-MC cc: JPG at MIT-MC Well, my feeling is that people shouldn't rely on the exact truth value which comes back from a true/false predicate. Sad that it ws documented like that. By the way, here's some more data. There seems to be a pattern: Arg1 Arg2 Return Value A AB T AB ABC T ABC ABCD T ABCD ABCDE T ABCDE ABCDEF LESSP ABCDEF ABCDEFG T ABCDEFG ABCDEFGH T ABCDEFGH ABCDEFGHI T ABCDEFGHI ABCDEFGHIJ T ABCDEFGHIJ ABCDEFGHIJK LESSP ABCDE ABCDEFG LESSP Looks like when the characters match exactly up to the length of the first symbol and the second symbol's pname continues on, the symbol LESSP is returned. Pretty odd.  Date: 1 October 1982 06:40-EDT From: Jeffrey P. Golden To: BUG-LISP at MIT-MC cc: ASB at MIT-MC, JPG at MIT-MC The documentation (MOONual) says ALPHALESSP returns T or NIL. Yet (ALPHALESSP '$A_OR '$A_OR1) returns LESSP.  Date: 23 Sep 1982 15:40 PDT From: JonL at PARC-MAXC Subject: Re: In-reply-to: KMP's message of 13 September 1982 16:18-EDT To: Kent M. Pitman cc: ALAN at MIT-MC, BUG-LISP at MIT-MC, bug-oz at MIT-OZ, gsb at MIT-ML The little bootstrap file that is intended for keeping on is generated from MACLISPBOOT.MID (source may be on [XX]SS:). However, note that it loads from PS:LISP.EXE.0 , meaning highest version of LISP.EXE. Indeed, that file on should be set for autokeep.  GSB@MIT-ML 09/17/82 19:57:35 Re: previous patch To: (BUG LISP) at MIT-ML well it's patched in the bblisp on oz. The scheme dump shares with lisp on the wrong dir so i can't replace the copy, and XX is wedged in such a way that i can only get in via telnet which seems to interpret as in nddt.  GSB@MIT-ML 09/17/82 19:46:34 Re: (status ttysize) bug, 20x To: (BUG LISP) at MIT-ML i should have said, STTYS1+1 should use MOVM rather than MOVE.  Date: 17 September 1982 19:44-EDT From: Glenn S. Burke Subject: (status ttysize) on 20X To: ALAN at MIT-MC cc: BUG-lisp at MIT-MC Fixed in the source, STATUS 259 (hohoho). The sign bit is used for (status terpri) on a per-file basis, and things like LINEL and this code have to be careful to use magnitude only. I will patch this in on OZ and XX shortly. (sstatus terpri t [file]) sets this; it is probably being done by something you load up.  Date: Friday, 17 September 1982 03:32-EDT Sender: ALAN at MIT-OZ From: Alan Bawden To: bug-lisp at MIT-OZ Subject: (status ttysize) on 20X Currently in my lisp (status ttysize) returns (30 . -117). While in a fresh lisp it returns the correct (30 . 117). This has happened to me twice now, and I would really like to know who smashes that location. I can't reproduce it. Anybody else ever seen this? -------  Date: 15 September 1982 01:50-EDT From: Stavros M. Macrakis Subject: < WNA msg To: BUG-LISP at MIT-MC (< 4.5 3) ;4.5 fixnum cant compare to flonum args=4.5 (return '(4)) ...still unhappy... (return '(3.4)) ...happy...  Date: Tuesday, 14 September 1982 10:52-PDT From: Jonathan Alan Solomon To: David C. Plummer Cc: ALAN at MIT-MC, BUG-LISP at MIT-MC, bug-oz at MIT-OZ, gsb at MIT-ML, KMP at MIT-MC Address: 3737 South Hoover Street Room PHE 204 Los Angeles, California 90089-0273 Phone: (213) 202-1793 Yes for V5, If you save a EXEC.EXE properly with this switch set it will remain set for everyone. Individual users who want to change it can simply unset it in their COMAND.CMD files. In my exec there already exists a command to override the file setting. People seem to be doing SET FILE (no) EPHEMERAL and (no) AUTOKEEP at random and whenever they feel like it. If you INSTALL LISP SYS:LISP.EXE AUTOKEEP NO CONFIRM you will *always* get a Kept lisp no matter what anyone does to the file (this is in my exec under v4). --JSol  Date: 14 September 1982 11:53-EDT From: David C. Plummer To: JSol at USC-ECLC cc: KMP at MIT-MC, ALAN at MIT-MC, BUG-LISP at MIT-MC, bug-oz at MIT-OZ, gsb at MIT-ML Date: Monday, 13 September 1982 14:39-PDT From: Jonathan Alan Solomon Address: 3737 South Hoover Street Room PHE 204 Los Angeles, California 90089-0273 Phone: (213) 202-1793 All of this flaming will cease when OZ runs TOPS-20 V5. Then you will be able to say SET PROGRAM FOO KEEP START, etc. This is so much nicer than the current way. I assume 'you' (i.e. someone) can say SET PROGRAM FOO KEEP START in the system startup so that it will apply globally to all users. That may introduce some new screws to user interfaces, but it is better than the current situation. Perhaps the V4 system startup should ensure that LISP (and other interesting programs) have the correct AUTOKEEPedness and EPHEMERALness??  Date: 13 September 1982 16:44-EDT (Monday) From: FEINBERG at CMU-20C at MIT-MC To: Alan Bawden Cc: bug-ledit at MIT-OZ, bug-lisp at MIT-OZ Subject: 20X ledit Howdy! I was sort of maintaining Ledit at Oz. When you ship the modern version of Ledit over to Oz you will find that it will not work properly. If you care to fix it, please do. When I get a free moment in the next few days I will take a look at it to see if what can be done, if no one else wishes to take a stab at it. --Chiron  Date: 13 September 1982 2150-EDT From: Dave Touretzky at CMU-10A To: bug-lisp at MIT-MC Subject: incorrectly redefining system functions CC: Jon Rosenberg at CMU-10A If you redefine a system SUBR as an LSUBR, the ARGS info doesn't get updated under Twenex MacLisp (version 2130 on CMUC), but it is updated correctly in the TOPS-10 version (number 2129 on CMUA.) For example, if you compile the following (DEFUN OUT NARGS (CONS 'OUTRAGEOUS: (LISTIFY NARGS))) you naturally get a warning from COMPLR about "redefining a system function." If you then load the fasl file under TOPS-10 MacLisp and do (ARGS 'OUT) you get NIL. If you load the exact same fasl file into a Twenex MacLisp, (ARGS 'OUT) returns (NIL . 2), and if you call OUT you get a wrong number of arguments error. -- Dave Touretzky  Date: Monday, 13 September 1982 14:39-PDT From: Jonathan Alan Solomon To: Kent M. Pitman Cc: ALAN at MIT-MC, BUG-LISP at MIT-MC, bug-oz at MIT-OZ, gsb at MIT-ML Address: 3737 South Hoover Street Room PHE 204 Los Angeles, California 90089-0273 Phone: (213) 202-1793 All of this flaming will cease when OZ runs TOPS-20 V5. Then you will be able to say SET PROGRAM FOO KEEP START, etc. This is so much nicer than the current way.  Date: 13 September 1982 16:18-EDT From: Kent M. Pitman To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC, bug-oz at MIT-OZ, gsb at MIT-ML It's sort of a bug in Autokeep (or maybe in Twenex) that you can't set the Autokeep bit for an entire cluster of files and have it apply to new versions when written. I think what happened is that when Glenn wrote the patch the other night to fix SUSPEND lossage, he didn't set the autokeep bit back on. This was not so much an issue of OZ policy or anything silly like that as just an easy slip to have happen. This is yet another good reason why MACLISP should probably be an unchanging .EXE file which does nothing more than reload some other file (such as 's MACLISP.EXE). I think this is what is done on EE and I think the reasons are similar. In any case, sorry for your lost work. It was not intended that it shouldn't be kept. -kmp  Date: Monday, 13 September 1982 14:47-EDT Sender: ALAN at MIT-OZ From: Alan Bawden Subject: shafted again To: bug-oz at MIT-OZ Cc: bug-lisp at MIT-OZ I just lost a fair amount of work because lisp was not set to autokeep. It is getting to be a real PAIN IN THE ASS that we can't get our act together on this problem. I would think that any program that has any signifigant state (or that can have arbitrary subforks) should be set autokeeping. This doesn't seem to be that hard a rule to follow, so can't somebody who is more familiar than I am with the stuff in the system directories make a pass over them and check for screws like that? -------  Date: Monday, 13 September 1982 13:57-EDT Sender: ALAN at MIT-OZ From: Alan Bawden Subject: 20X ledit To: bug-lisp at MIT-OZ, bug-ledit at MIT-OZ Who maintains 20X ledit? I finally convinced the ITS ledit people that the command ^R LEDIT Zap DEFUN to LISP should leave point in the same place rather than moving it to the front of the just Zapped toplevel form. I argued that if I was making many changes to a particular spot in a fairly large toplevel form, testing them out by frequently Zapping the whole form, it was a pain to have to re-find my position each time I returned to EMACS. Especially when the toplevel form is large enough to cause a redisplay when moving from the front to the location of my changes. I find that the 20X ledit still exibits this behavior which is doubly annoying because it is now inconsistent and I use MacLisp in both systems. Perhaps the 20X ledit maintainers simply haven't heard about this change? (Perhaps the bug-ledit mailing list should distribute to both sets of maintainers if it doesn't already. I'll add them if they tell me who they are.) Perhaps we simply haven't gotten the most recent version of 20X ledit? (I'll install it here on OZ.) Perhaps the 20X ledit maintainers LIKE the repositioning behavior? (That would be pessimal, but perhaps they could be persuaded to install a switch?) While we are on the subject, can't 20X ledit use defstruct instead of defvst? I really hate having to load the defvst runtime into my lisp just so that I can edit. Defstruct has no runtime. (Or perhaps this is the sub-fork package that uses defvst? Could it be changed?) -------  Date: Monday, 13 September 1982 13:34-EDT Sender: ALAN at MIT-OZ From: Alan Bawden Subject: ^G quits and VTS To: bug-lisp at MIT-OZ While we are tracking down Lisp/VTS bugs. Could somebody figure out why a ^G quit fails to update the cursor position correctly? (I am presuming that there is something that Lisp could be doing to inform VTS of what just happened. I might be wrong of course.) -------  Date: 11 September 1982 18:03-EDT From: Kent M. Pitman To: BUG-MACLISP at MIT-MC (namelist '(foo bar (dsk . kmp))) => ((* |(DSK .|) FOO BAR) (namelist '((dsk . kmp) foo bar))) => ((DSK /#74000) FOO BAR) These should be consistent. I wouldn't even mind if they both erred. I've never liked the feature of doing IMPLODE of EXPLODE on non-atoms in namelists. It's too easy to have code that does '((dsk foo) 'a 'b) and have NAMELIST turn this into DSK: FOO; (QUOTE (QUOTE. I'd just as soon require that filename components be atoms.  Date: Saturday, 11 September 1982 14:58-EDT From: Skef Wholey To: Glenn S. Burke Cc: BUG-complr at MIT-MC, BUG-lisp at MIT-MC, feinberg at CMU-20C, SROBINSON at DEC-MARLBORO Subject: load-byte/deposit-byte miscompilation Much thanks for your help. Nice to know that the number of bugs in MacLisp decreases some of the time... --Skef  Date: 11 September 1982 05:15-EDT From: Glenn S. Burke Subject: load-byte/deposit-byte miscompilation To: BUG-lisp at MIT-MC cc: feinberg at CMU-20C, Wholey at CMU-20C, BUG-complr at MIT-MC, SROBINSON at DEC-MARLBORO This has been fixed in the source of SRCTRN. One problem was that an original argument was being used for compile-time evaluation rather than the macroexpanded and un-quoted form in several places. There was also a shift missing in one case. A patch file has been made for the currently installed ITS compilers (version 1131) and those on OZ and XX (version 1127). For lack of a better mechanism, i consed up a twenex compiler patch file scheme, which is just a trivial variation of what is already in use on ITS. The file COMPILER-PATCH-TEMPLATE.LSP is the basic template, with directions: in this case, the specific files are CLFIX.1127, which loads COMPILER-PATCH-1127.FASL, which was made from COMPILER-PATCH-1127.LSP.  Date: 11 September 1982 03:50-EDT From: Glenn S. Burke To: BUG-LISP at MIT-MC (quit ) seems to always do .LOGOUT 1, first. This sort of obviates the options to quit, doesn't it? This should be only .LOGOUT.  Date: 10 September 1982 1132-EDT (Friday) From: Guy.Steele at CMU-10A To: Glenn S. Burke Subject: Re: 2129 patches for twenex (VTS) CC: bug-lisp at MIT-MC In-Reply-To: Glenn S. Burke@MIT-MC's message of 9 Sep 82 22:39-EST That's a *lot* of patches!  Date: 9 September 1982 23:39-EDT From: Glenn S. Burke Subject: 2129 patches for twenex (VTS) To: BUG-LISP at MIT-MC STTY1A+15 should be SKIPN VTS20P rather than SKIPE. This will make (status tty) return the correct last two values rather than 0. Instead of MOVE 2,TI.ST6(TT) at OPNT2+22, there should be the sequence RTMOD HRR 2,TI.ST6(TT) IOR 2,[STDTMW] This will make "the right things" happen when a suspended lisp comes up on a different terminal (type) from that which it was suspended on. This has been patched on OZ. I will update the BBLISP and LISP EXE files on XX now, as the SS structure there seems to be restored.  GSB@MIT-ML 09/09/82 03:20:05 Re: previous patch, to OPNT2 To: (BUG LISP) at MIT-ML is incorrect. I'll publicize the correction when i stop being shafted by losing hardware, and when i go over it with a Travers  Date: 7 September 1982 18:46-EDT From: Glenn S. Burke Subject: suspend tty code fix (tops-20 vts) To: BUG-LISP at MIT-MC cc: mt at MIT-OZ According to MT, the problem is that Lisp is setting a whole word with stmod rather than only the left half as it should; this can be fixed by making it do RTMOD, and then HLL 2,TI.ST6 rather than the MOVE it now does, at OPNT2+twentysome. This has been fixed in the source, and patched into the BBLISP on OZ. We made a .EXE, but did not install it on yet (it was in use).  Date: 7 September 1982 16:07-EDT From: Glenn S. Burke Subject: (LISTEN) To: BUG-LISP at MIT-MC i replied to REM  Date: 6 September 1982 21:20-EDT From: Robert Elton Maas Subject: (LISTEN) To: BUG-LISP at MIT-MC Why does (LISTEN) take about 100 miliseconds (0.1 second) to execute? This seems to be a very long time.  Date: 6 September 1982 18:38-EDT From: Kent M. Pitman To: BUG-LISP at MIT-MC I forwarded DEVON's bug report to BUG-LISPM where it should have gone.  Date: 6 September 1982 18:39-EDT From: Devon S. McCullough To: BUG-lisp at MIT-OZ In lisp in Remote-File 14.0, LMFILE-Remote 18.0, MIT-Specific 10.0, System 87.19, Experimental ZMail 46.3, microcode 164, No, devon, on Lisp Machine One: In the blue manual on page 158, 11.1 describing closures, it says The form (closure var-list function), where var-list is a list of... ... the value cells of the symbols. Then function is applied to the ARGUMENT. (This... in the next-to last paragraph on the page. ARGUMENT should be plural, or I'm mixed up!  Date: 2 September 1982 01:19-EDT From: Kent M. Pitman To: RPK at MIT-MC cc: BUG-LISP at MIT-MC I put a package on LIBLSP; (and on OZ) called LISPM. Please play with this and tell me if it gives you any troubles. If no one reports any bugs in a week or two, I'll announce it to INFO-MACLISP. The file defines compatibility definitions for DEFSUBST, DOLIST, DOTIMES, MEXP, WITH-OPEN-FILE and WITH-OPEN-STREAM. Documentation is in LIBDOC;LISPM > and in OZ:PS:LISPM.LSP -kmp  Date: 1 September 1982 23:36-EDT (Wednesday) From: FEINBERG at CMU-20C To: Glenn S. Burke Cc: BUG-LISP at MIT-MC Subject: renamef failure Howdy! It is patched on OZ. --Chiron  Date: 1 September 1982 22:52-EDT From: Glenn S. Burke Subject: renamef failure To: BUG-LISP at MIT-MC the IOJRST at RENAM5+6 should be a JFCL. If the RNAMF fails then the file has been closed but the jfn not released. The IOJRST after the failing CLOSF will clobber the first error message (and probably not allow the error to return because iojrst stack hacks probably aren't additive). I have changed this in the source, someone patch it on a 20?  Date: 1 September 1982 16:56-EDT From: Alan Bawden Subject: WITH-OPEN-FILE To: RpK at MIT-ML cc: BUG-LISP at MIT-MC, RpK at MIT-OZ Date: 1 September 1982 13:40-EDT From: Robert P. Krajewski Does WITH-OPEN-FILE exist in MacLisp ? It would be a very nice thing to have. I'd define a robust version of it, but I don't know how MacLisp does UNWIND-PROTECTs and such. (If you take out the clean-up code, it's very simple.) MacLisp does UNWIND-PROTECT by having an UNWIND-PROTECT special form just like the LispMachine's. There is no built-in WITH-OPEN-FILE macro, but clearly you can write your own using UNWIND-PROTECT, or wait until KMP writes one (he'll think of some screws you never dreamed of I'll bet) or you can convert your code to using IOTA. This may be a stupid question, but why don't the objects returned by OPEN accept messages like :TYO, :TYI, :STRING-OUT, :LINE-OUT, :TRUENAME, and so on ? All they seem to accept are very general messages that would be handled by the Lisp Machine SI:VANILLA-FLAVOR -- :PRINT-SELF and others. I don't understand this question in the least. The objects returned by OPEN don't except ANY messages. They are not message recieving objects. They do have a printed representation, but that isn't accomplished by sending any messages. You don't do I/O by sending them messages, but by calling functions like PRINC and TYO and passing them the "file object" as an argument.  Date: 1 September 1982 16:27-EDT From: Kent M. Pitman Subject: WITH-OPEN-FILE To: RPK at MIT-MC cc: BUG-LISP at MIT-MC There is a package on LIBLSP called IOTA which does what you want. I'm working on a library of macros and functions to help people trying to hack Lisp Machine compatibility. Among things in that library will be WITH-OPEN-FILE. For now, though, IOTA is the thing to use. It's used heavily in lots of Maclisp systems and works fine. Documentation is in LIBDOC;IOTA > -kmp  Date: 1 September 1982 13:40-EDT From: Robert P. Krajewski Subject: WITH-OPEN-FILE To: BUG-Lisp at MIT-MC cc: RpK at MIT-OZ Does WITH-OPEN-FILE exist in MacLisp ? It would be a very nice thing to have. I'd define a robust version of it, but I don't know how MacLisp does UNWIND-PROTECTs and such. (If you take out the clean-up code, it's very simple.) This may be a stupid question, but why don't the objects returned by OPEN accept messages like :TYO, :TYI, :STRING-OUT, :LINE-OUT, :TRUENAME, and so on ? All they seem to accept are very general messages that would be handled by the Lisp Machine SI:VANILLA-FLAVOR -- :PRINT-SELF and others. ``Bob''  Date: 1 September 1982 02:04-EDT From: George J. Carrette Subject: hacking/assembly maclisp To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Thanks for the info, now, I wonder if I have *read* access to the Maclisp directory on XX? sigh... it is a wonder anything gets done at MIT inside LCS. Yes, I expected to be at the lisp conference, but when the time came to leave it seemed more fun to stay at ATARI and hack up some demo's in NIL on their brand-new 780. I heard that some of the graphics in TRON were done in Maclisp on a Foonly (by the way). Remember that bug note/question about extened objects and arithmetic some months ago? I think it was from the same guy, Craig Renolds? Anyway, thats the state of things, I'll be at ATARI again in a little while and I'll give you a call in Palo Alto, want to see some 3-D graphics in NIL controlled via the flavor system? [No, I didn't implement a number-compiler for NIL yet, the crunching stuff is written in (sigh) "C" which gets interfaced to NIL in the obvious way.] -gjc  Date: 1 September 1982 00:00-EDT From: Glenn S. Burke To: BUG-LISP at MIT-MC on oz, an LH/| page disappears when the job is suspended and restarted. One gets a memory protection violation...  Date: 31 August 1982 23:57-EDT From: Glenn S. Burke To: BUG-LISP at MIT-MC on OZ,  Date: 31 August 1982 01:15-EDT From: Kent M. Pitman Sender: VP at MIT-MC Subject: FORMAT losing To: GSB at MIT-MC cc: BUG-LISP at MIT-MC In Maclisp 2122, Format 827. on MIT-MC: Ignoring the rough points in what these actually ask FORMAT to do ('cuz there are a few conceptual bugs), these functions do not behave in ways even remotely resembling what the LispM does with them. For example, the LispM does not err, pdl-overflow, or complain of missing ~]'s. Simple tests like (f nil), (f '(a)), (f '(a b)), (f '(a b c)) and likewise for g should give you a feel for what I'm talking about. G'luck. (defun f (x) (lexpr-funcall #'format t "~#[nothing~;~S~;~S and ~S~ ~:;~@{~<~% ~1,50:;~#[~1; and~] ~S~>~^,~}~]" x)) (defun g (x) (format t "~%;; ~{~<~%;; ~1,50:;~#[~1; and~] ~S~>~^,~}.~%" x)) -kmp  Date: 30 Aug 1982 16:10 PDT From: JonL at PARC-MAXC Subject: Re: fixes to maclisp In-reply-to: GJC's message of 20 August 1982 23:27-EDT To: George J. Carrette cc: JONL at MIT-MC, BUG-LISP at MIT-MC I've just returned from two weeks travelling (LispConference, AAAI, MIT visit etc) and I didn't see you at MIT -- are you still there? There used to be a .CTL file on MIT-XX, PS:ASSLIS.CTL, which you could just SUBMIT and it would doo all the rest. It would leave an *uninitialized* result on SS:BBLISP.EXE. and also do an initialization phase leaving PS:XLISP.EXE. and PS:LISP.SYMBOLS.. You then rename XLISP to LISP after certifying that things are winning. The value of the uninitialized file is that it's hard to patch the LISP.EXE file with the existing NDDT since it involves changing file page accessibilities (read-only etc).  GSB@MIT-ML 08/30/82 01:34:11 Re: new format installed on MC and OZ To: (BUG LISP) at MIT-ML format 827 has been put on MC and OZ. the file types involved are FASL, BRACK, FLOAT, NUM, and UMACS. This fixes a fencepost bugs in ~$ and a misfeature in operator definition via define-format-op, and maybe some other things which i have since forgotten.  Date: 27 August 1982 15:51-EDT From: Glenn S. Burke Subject: (SSTATUS SYNTAX #/| ...) To: Rees at YALE cc: Ellis at YALE, Ruttenberg at YALE, BUG-Lisp at MIT-MC I believe that SETSYNTAX is what you want here; it assumes that the choices (bits only, MACRO, SPLICING) are mutually exclusive. (sstatus syntax ...) only hacks the syntax bits. In obscure applications this is actually useful (the fact that it doesn't clobber the macro/chtran entry, that is), because you can do strange and perverse things with something like "." so that it is still decimal point but also acts like a special-token (implemented as a reader macro). (I've done this. It almost works.)  Date: 24 August 1982 20:56 edt From: Barry Margolin at MIT-MULTICS Subject: Re: Lisp problem Sender: Margolin.Multics at MIT-MULTICS To: Greg Skinner cc: bug-lisp at MIT-OZ In-Reply-To: Message of 24 August 1982 20:50 edt from Greg Skinner There were no bugs displayed in that session. By default, Maclisp is in base 8, and 15(8) = 13(10) (where the notation xx(n) means the numeral xx in base n), and the GCD of 5(10) and 13(10) is indeed 1. The variables that control the base that numbers are input and output in are "base", which is the base that numbers are output in, and "ibase", which controls the input base. Associated with these is the variable "*nopoint", which if set to T causes the decimal point that normally follows decimal numbers on output to be suppressed. Note that any fixnum that has a trailing decimal point (as in 100.) is also read in in decimal, regardless of the setting of ibase, so to initially set the base variables you should say: (setq base 10.) (setq ibase 10.)  Date: 24 Aug 1982 2050-EDT From: Greg Skinner Subject: Lisp problem To: bug-lisp at MIT-OZ Subject: LISP problem Is this a bug or just a feature? (especially (gcd 15 5) evaluating to 1, while the others seem to evaluate correctly). Plus, is there any way that LISP can be set so that base 10 numbers are echoed as such? (re 8 = 10 and 10 = 10) [PHOTO: Recording initiated Tue 24-Aug-82 8:37PM] TOPS-20 Command processor 4(661)-2 @lisp LISP 2129 Alloc? n * (gcd 15 5) 1 (gcd 30 10) 10 (gcd 8 4) 4 (gcd 60 30) 30 (gcd 50 5) 5 (quotient 50 4) 12 50 50 (quit) @pop [PHOTO: Recording terminated Tue 24-Aug-82 8:38PM] -------  Date: 24 August 1982 18:40-EDT From: Glenn S. Burke Subject: distribution request To: TY at MIT-ML cc: BUG-LISP at MIT-ML tar@MIT-ML (Sent by ___036@MIT-ML) 08/24/82 14:48:02 Re: Phone message Steve Cadrak called. Academic Computing Center University of Vermont Burlington, VT 05405 He would like to obtain the latest MACLISP. (He has version 2009) TOPS-20 version 5. (802) 656-3910  Date: 23 August 1982 17:03-EDT From: Alan Bawden Subject: push/defvst interaction? To: Ruttenberg at YALE cc: BUG-LISP at MIT-MC Date: 22-Aug-82 10:22PM-EDT (Sun) From: John Ruttenberg It doesn't happen if you are using defstruct instead. We would use defstruct, except that using it into named hunks makes it want to use some version of defvst that we don't have here. Where are the authorative up to date sources for things like defstruct and defvst? I'd like to know if we can get this fix and others like it. I heve never released a version of defstruct that had anything whatsoever to do with ANY of the out-of-core (autoloading) MacLisp libraries. There is a feature that made defstruct a front end for defvst which I have never released to anyone, but that wouldn't do you any good anyway. Can you send me an example of a defstruct that tries to load ANYTHING? Up-to-date defstruct FASL can be found on LISP;STRUCT FASL. Also note that I don't seem to be able to compile the bug infested code. (Same problem - some unbound gensym in the push expression). I'm not surprised that you can't compile it either.  Date: 23 August 1982 02:45-EDT From: George J. Carrette Subject: push/defvst interaction? To: Ruttenberg at YALE cc: ALAN at MIT-MC, BUG-LISP at MIT-MC As a bit of honest practical advice, I would concur with ALAN in suggesting that you use DEFSTRUCT in preference to DEFVST. The story goes like this: DEFVST was supposed to be part of a package of code which was "NILCOM," common to both NIL and Maclisp, and presumably to be part of "common-lisp." As it turned out though, the implementation of all of that "NILCOM" code was too tentative and kludgy to be worth bringing up in actual VAX NIL, so instead code like Defstruct (which is de-facto common-lisp) was brought up. So you see, there can be little incentive here (at MIT) to support/fix-bugs in code such as DEFVST. On the other hand, it is quite easy for me to make available to you an option to defstruct called "EXTEND" which does the same job as "DEFVST" except that the interface is a lot cleaner, and it actually works! (It is what RLB and I used last summer to cross-compile NIL from the pdp-10 to the VAX). You can get it by FTPing "GJC;SFIX FASL" from the MIT-MC machine. Source is in "GJC;SFIX >" on MIT-MC. To answer your question about source code: The most up-to-date versions of things are on the LIBDOC, LSPSRC, and NILCOM directories on MIT-MC. The *best* solution seems to be to keep a winning Maclisp environment working on MIT-OZ, and let people FTP stuff from there. -gjc  Date: 22-Aug-82 10:22PM-EDT (Sun) From: John Ruttenberg Subject: Re: push/defvst interaction? To: Alan at MIT-MC Cc: Bug-Lisp at MIT-MC In-Reply-To: Bawden's message of 22 August 1982 19:29-EDT It doesn't happen if you are using defstruct instead. We would use defstruct, except that using it into named hunks makes it want to use some version of defvst that we don't have here. Where are the authorative up to date sources for things like defstruct and defvst? I'd like to know if we can get this fix and others like it. Also note that I don't seem to be able to compile the bug infested code. (Same problem - some unbound gensym in the push expression). -------  Date: 22 August 1982 19:29-EDT From: Alan Bawden Subject: push/defvst interaction? To: BUG-LISP at MIT-MC cc: Ruttenberg at YALE Date: 14-Aug-82 10:55AM-EDT (Sat) From: John Ruttenberg It seems especially odd to me that things should blow up only after the second call to bug. A smaller case of the bug: (defvst bug-st (a = (*array () t 10)) ) (defun bug (self member index) (push member (arraycall t (bug-st-a self) index))) (setq b (cons-a-bug-st)) (bug b 'a 4) (bug b 'a 4) After the first call to BUG it's definition has been changed to be: (defun bug (self member index) (push member (arraycall t index))) This is probably an artifact of PUSH being a fexpr (but thinking like a macro), bug it also seems to depend heavily on the source of the array being a defvst accessor. It doesn't happen if you are using defstruct instead. Perhaps those responsible for defvst/push will step forward and fix?  Date: 22 August 1982 18:59-EDT From: Alan Bawden Subject: (SSTATUS SYNTAX #/| ...) To: Rees at YALE cc: BUG-LISP at MIT-MC, Ellis at YALE, Ruttenberg at YALE Date: Saturday, 14 August 1982 00:31-EDT From: Jonathan Rees (SSTATUS SYNTAX #/| 2.) 2 '| /^T This is because (SSTATUS SYNTAX) doesn't know enough to set up the character translation when it turns off a macro character. You can either do (SSTATUS CHTRAN #/| #/|) immediately afterwords, or use (SETSYNTAX #/| 2. #/|) instead. I started to fix this, but the code is too ugly to be believed.  Date: Saturday, 14 August 1982 00:31-EDT From: Jonathan Rees To: Bug-Lisp at MIT-MC Subject: (SSTATUS SYNTAX #/| ...) Cc: Ellis at YALE, Ruttenberg at YALE Trying to set the syntax of | doesn't work. (SSTATUS SYNTAX #/| 2.) ;2 is syntax of %, :, etc. 2 '| /^T Vertical bars in symbols read as control-T's.  Date: 14-Aug-82 10:55AM-EDT (Sat) From: John Ruttenberg Subject: Bug in setf and arraycall To: Bug-Lisp at MIT-MC Seems to be a problem with push and arraycall. Here's the source file: (defvst bug-st (a = (*array () t 10)) ) (defmacro bug-st-ai (self index) `(arraycall t (bug-st-a ,self) ,index)) (defun bug (self member index) (push member (bug-st-ai self index))) (setq b (cons-a-bug-st)) (bug b 'a 4) (bug b 'a 4) And here's how Maclisp takes it: Yale Haclisp 82 (in Maclisp 2088) > (defvst bug-st (a = (*array () t 10)) ) ;Loading DEFVST 3 ;Loading EXTMAC 183 ;Loading ERRCK 20 ;Loading VECTOR 64 ;Loading DEFVSX 85 BUG-ST >(defmacro bug-st-ai (self index) `(arraycall t (bug-st-a ,self) ,index)) BUG-ST-AI >(defun bug (self member index) (push member (bug-st-ai self index))) BUG >(setq b (cons-a-bug-st)) #{BUG-ST A #T-10-71712} >(bug b 'a 4) (A) >(bug b 'a 4) ;G0017 UNBOUND VARIABLE ;BKPT UNBND-VRBL > (baktrace) BAKTRACE +INTERNAL-UBV-BREAK_ ARRAYCALL_ PUSH_ BUG_ It seems especially odd to me that things should blow up only after the second call to bug. -------  Date: 20 August 1982 23:27-EDT From: George J. Carrette Subject: fixes to maclisp To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Can you tell us the best way to assemble a Maclisp on a tops-20 so that we can put in the various accumulated fixes in the version on OZ? For example, the MT fix to suspend. Thanks.  Date: 13 August 1982 01:06-EDT From: George J. Carrette Subject: Terminal problem with SHARE To: RPK at MIT-MC cc: Nessus at MIT-EECS, BUG-LISP at MIT-OZ, RpK at MIT-OZ, RpS at MIT-OZ This is a bug in the code in SUSPEND which gets run on start-up. The problem is that the code EXPLICITLY sets some bits in the TTY status word on start up using information it had cached away before the SUSPEND, an obviously losing thing to do. Anyway, I got Mike Travers to look at the code a couple months ago, and it is an easy fix, just a matter of actually doing it and reassembling. In the mean time you can make two maclisp's for yourself, one suspended from a SUPDUP terminal, and one not.  Date: 12 August 1982 13:52-EDT (Thursday) Sender: RPK at MIT-OZ From: Robert P. Krajewski To: BUG-LISP at MIT-OZ Subject: Terminal problem with SHARE cc: RpK at OZ, GJC at MIT-OZ, RpS at MIT-OZ, Nessus at EE I `made' my own MacLisp with the SHARE program, and experienced no problems until I ran it using a Lisp Machine as a SUPDUP terminal. This Lisp, which I dumped from a batch job, would not receive control characters correctly. Control- would echo as ^\A. I could not ^C out either -- it just echoed in that strange way ! However, I could ^C if I typed Beta -- it would first echo ^\P, though. I started up a LISP, and had no such problems. What is the function to call to tell MacLisp to look at the terminal and do the right thing ? ``Bob'' -------  Date: 6 August 1982 18:56-EDT From: Kent M. Pitman Subject: tty prescan bug To: BUG-MACLISP at MIT-MC If a comment ends in an odd number of slashes, the tty prescan will assume that the end of the comment is being "quoted" away and will scan the following line as part of the comment rather than as comment text. The bug is in that (#/; . #\newline) is in the TTYSCAN-STRINGERS/| list, which assumes that the "/" char is allowed for quoting. I doubt this can be fixed easily. I just point it out mostly just so maintainer types know the bug exists in case it ever causes someone confusion.  Date: 6 August 1982 17:06-EDT From: Glenn S. Burke Subject: bizarre and unexpected message To: BUG-LISP at MIT-ML cc: TY at MIT-ML Yow, am i official yet? TAR@MIT-ML (Sent by TAR0@MIT-ML) 08/06/82 11:25:07 Hazeltine called, and wants to let you (and MIT in general) that they have successfully implemented a version of MacLisp and they are interested in being on the updates list. Roy Freedman Hazeltine Corporation Freedman@USC-ECLB. ----------------  Date: 3 Aug 1982 0926-EDT From: SCHRAG at RADC-TOPS20 Subject: MacLisp for TOPS-10 To: GJC at MIT-MC, Bug-Lisp at MIT-MC, RWK at MIT-MC, To: Guy.Steele at CMUA cc: TY at MIT-XX I am (still) trying to get hold of MacLisp to run on TOPS-10 for Robinson and Sibert at Syracuse University, who are working under contract to RADC. I don't need to put anybody through the trouble of ljljmaking a tape. If someone could tell me where are versions of COMPLR and MACLSP that run on TOPS-10, I would just ftp them and put them on the tape that I am making for Syracuse. Can somebody please give me a hint? Thanks--Bob. -------  Date: 26 July 1982 20:00-EDT (Monday) From: Pat O'Donnell To: info-lisp at ai Subject: JSYS Calls under twenex Maclisp The JSYS package I described earlier can be found in the directory PS: on both MIT-EECS and MIT-OZ (they can be exported to other machines if these are inaccessible). JSYS.MID, for the source, and JSYS.FASL for binary. ERSTR.FASL (.MID) is also useful. Documentation is in JSYS.DOC. Useful variables are defined in JSYS-TABLE.LSP (snarfed from the jsys package mentioned by JonL) and JSYS-FLAGS.LSP, which is almost empty, although useful macros are defined. - Pat  Date: 26 July 1982 11:29-EDT (Monday) From: Pat O'Donnell To: JonL at PARC-MAXC Cc: CSD.FREEMAN at SU-SCORE, David Vinayak Wallace , Zubkoff at CMU-20C, info-lisp at ai Subject: JSYS calls under twenex maclisp I have a package which was inspired by the JSYS function mentioned by JonL. It takes the same arguments, except that it does some conversion between Maclisp data types and Twenex data types. In particular, symbols get converted to ASCIZ strings, and jfns are retrieved from file objects. Cons's are interpreted as left-half and right-half. Further, the argument, if NIL will return a list of the first four accumulators, and a variable is set to the number of instructions skiped (plus 1). I am planning (someday) to supplement it to accept more accumulators, if necessary. If anyone is interested in this package, I will make it available. - Pat  Date: 26 Jul 1982 04:48 PDT From: JonL at PARC-MAXC Subject: Re: JSYS calls under twenex maclisp In-reply-to: GUMBY's message of 25 July 1982 20:02-EDT To: David Vinayak Wallace cc: INFO-LISP at MIT-AI, Zubkoff at CMU-20C, CSD.FREEMAN at SU-SCORE RE: How can I access values returned in random registers after a jsys call (i.e "returns +1 if unsuccessful, error code in acc 2")? The SUBFORK package, available with MacLisp on Twenex systems, has a function JSYS which does just what you want. (JSYS ) Thus the fifth argument tells which acumulator's contents to return as the result of the JSYS call. JSYS currently doesn't make any distinction between successful and unsuccessful returns, but it could be fairly easily hacked in thru the MULTIPLE-VALUE mechanism currently in MacLisp. The SUBFORK package is primarily a "spin-off" of the MacLisp/EMACS interface for Twenex users -- it provides a convenient way to run other subsystems as a subfork of your MacLisp job. I'm not sure if it ever got documented for general consumption, but there are several little goodies in it that are probably of general interest.  Date: 26 Jul 1982 04:08 PDT From: JonL at PARC-MAXC Subject: Re: In-reply-to: DICK's message of Sunday, 25 July 1982 14:03-EDT To: Dick@MIT-AI cc: bug-lisp at MIT-AI Well, Dick, that's not the function of LET to correct user bugs. The only reason why PROG was kludged for fixnum variables is that MacLisp doesn't have the variable-with-initialization case; LET explicitly forces the user to select an initial value.  Date: 26 Jul 1982 04:06 PDT From: JonL at PARC-MAXC Subject: Re: MacLISP In-reply-to: Dave Touretzky's message of 25 July 1982 0329-EDT To: Dave Touretzky at CMU-10A,TY at MIT-XX cc: schrag at radc-tops20, bug-lisp at MIT-MC, Guy Steele at CMU-10A Good empathy for the pooor luser who just wants to be able to use his TOPS-10 cycles to best advantage! Real question now is: Who at MIT is willing/capable of distributing MacLisp tapes since I've left? TY, how about it?  Date: 26 July 1982 00:14-EDT From: George J. Carrette Subject: JSYS calls under twenex maclisp To: GUMBY at MIT-AI cc: BUG-LISP at MIT-MC INFO-LISP is not the place to ask for information about lisp, it is the place to send information about lisp. BUG-LISP is a better handle on lisp hackers. Anyway, what you need to do is learn about LAP, lisp assembly programming, and the conventions used by the compiler. Under some conditions you may be able to get away with using (EXAMINE 2) for example to get the contents of register 2.  Date: 25 July 1982 20:02-EDT From: David Vinayak Wallace Subject: JSYS calls under twenex maclisp To: INFO-LISP at MIT-AI How can I access values returned in random registers after a jsys call (i.e "returns +1 if unsuccessful, error code in acc 2")? david  Date: Sunday, 25 July 1982 14:03-EDT Sender: DICK at MIT-OZ From: Dick@MIT-AI To: bug-lisp at MIT-AI The following will not compile because the let tries to bind the I to NIL! LET should check and make sure that it binds each arg to something of the correct type when it is defaulting like this. (declare (fixnum i)) (defun foo () (let (i) (setq i (read)) (print i))) -------  Date: 25 July 1982 0329-EDT From: Dave Touretzky at CMU-10A To: George J. Carrette Subject: Re: MacLISP CC: schrag at radc-tops20, bug-lisp at MIT-MC, rwk at MIT-MC, Guy Steele at CMU-10A In-Reply-To: George J. Carrette@MIT-MC's message of 25 Jul 82 01:00-EST Nonsense. You've misunderstood Mr. Schrag's problem. The people at Syracuse want to write code in a clean and simple Lisp dialect that they can then move to a Lisp Machine. They are currently working in UCI Lisp. If they wrote equivalent code in Maclisp it would be trivial to move to the Lisp Machine. These guys do not need to know about #+ conditionalizations or any of the other esoteric psuedo-Lisp Machine cruft that's been added to MacLisp in the last few years. Give them a distribution tape and tell them to say DEFUN instead of DE, and I'm sure they'll be happy. -- Dave Touretzky  Date: 25 July 1982 02:00-EDT From: George J. Carrette Subject: MacLISP To: SCHRAG at RADC-TOPS20 cc: BUG-LISP at MIT-MC, RWK at MIT-MC, Guy.Steele at CMU-10A Considering the trouble of running under TOPS-10, well, Maclisp just isn't that close to lispmachinelisp. Can you get your hands on a VAX-750? Right now I'm working over the summer with another guy from MIT in a VAX-VMS-NIL environment on a 750 that the company was able to rent quite quickly for the summer months. We brought up code originally written on a lispmachine without hassle, and expect to be able to port back easily too. (Actually, the same thing was true with the Macsyma port to NIL, conditionalizations which were #+LISPM could just be changed to #+(OR LISPM NIL), the initial port taking 4 days due to this "lucky-break," whereas both the PDP-10 Maclisp and Franz conditionalizations indicate something really out of a different genre.) My experience is that this is the minimum-time minimum-hassle solution.  Date: 23 July 1982 1723-EDT (Friday) From: Guy.Steele at CMU-10A To: rwk at MIT-MC, gjc at MIT-MC Subject: MacLISP CC: bug-lisp at MIT-MC - - - - Begin forwarded message - - - - Mail-From: ARPANET host MIT-MC received by CMU-10A at 23-Jul-82 15:36:45-EDT Date: 23 Jul 1982 1139-EDT From: SCHRAG at RADC-TOPS20 Subject: MacLisp for TOPS-10 To: GLS at MIT-MC I am trying to acquire a version of MacLisp that will run under TOPS-10 (version 6.03). Syracuse University has a contract with RADC to develop a programming environment called LOGLISP, which is a synthesis of LISP and logic programming. To date they have developed the system in UCI-LISP, but plan to move to LISP machines later this year. We hope that MacLisp will be a good vehicle for development in the interim, its being closer to LISP machine LISP than UCI-LISP. I have communicated with Scott Fahlman and Dave Touretzky at CMU--they have given me pointers to the CMU "MacLisp environment," which I have ftp'ed. Dave suggested that since CMU's versions of MACLSP and COMPLR are modified for their "modified" TOPS-10 system, I should obtain these files from MIT on "distribution tape." Syracuse is not on the ARPANET, and I am planning to make a tape for them of MacLisp files. Would it be possible to obtain these files via ftp, and save the trouble of making and mailing a tape? Thank you for your attention. Bob Schrag RADC/COAD ------- - - - - End forwarded message - - - -  Date: 17 July 1982 18:23-EDT From: Alan Bawden Subject: sxhash To: GLR at MIT-MC cc: BUG-LISP at MIT-MC Date: 17 July 1982 17:36-EDT From: Jerry Roylance I thought SXHASH was changed ages ago so (not (= (sxhash '(a b)) (sxhash '(b a)))) I believe what was decided was that it was unreasonable to suddenly change the behavior of SXHASH because of the danger of screwing people with SXHASHes recorded in files. Thus a switch was installed to allow the user to choose between the old behavior and the new, and the default was made to be the old. Doing (sstatus sxhash nil) will turn on the new behavior which has the property you are looking for. Someday the new behavior may become the default, but I wouldn't hold my breath.  Date: 17 July 1982 17:36-EDT From: Jerry Roylance To: BUG-LISP at MIT-AI I thought SXHASH was changed ages ago so (not (= (sxhash '(a b)) (sxhash '(b a))))  Date: 14 July 1982 20:29-EDT From: David C. Plummer Subject: Re: opening files in 8 bit. To: JonL at PARC-MAXC cc: DCP at MIT-MC, BUG-LISP at MIT-MC, Zubkoff at CMU-20C, FEINBERG at CMU-20C CPR's stranging opening is unrelated to 8.bit. He was trying to send a CHAOS LSN packet, which is CHA:.foo where foo is the contact name. I think we did get around that (somehow), but 8.bit looks like it needs a lisp wizard to go down inside OPEN and do the right thing.  Date: 14 Jul 1982 17:04 PDT From: JonL at PARC-MAXC Subject: Re: opening files in 8 bit. In-reply-to: DCP's message of 14 July 1982 01:57-EDT To: David C. Plummer cc: Zubkoff at CMU-20C, BUG-LISP at MIT-MC, FEINBERG at CMU-20C I'm just offering a hint here as to what may be the trouble. I looked into that code when someone (was it you?) reported trouble opening the CHAOSnet from Lisp; Chris Ryland also had some comments about it. I thought I saw the problem as some difficulity in the QIO code which doesn't properly let you use null extensions (which apparently the CHAOSnet wants).  Date: 14 July 1982 01:57-EDT From: David C. Plummer Subject: opening files in 8 bit. To: Zubkoff at CMU-20C cc: BUG-LISP at MIT-MC, FEINBERG at CMU-20C If I recall correctly, you can open a disk file in 8-bit mode by using '(out tty image) or '(in tty image). The combination of TTY and IMAGE causes Lisp to use a byte size of 8 in the Openf% call. This may work for a disk file, but it doesn't work on CHAOSnet. I tried all possible modes about a year ago and didn't have any success.  Date: 13 July 1982 19:02-EDT (Tuesday) From: FEINBERG at CMU-20C To: David C. Plummer Cc: bug-lisp at MIT-MC Subject: opening files in 8 bit. Howdy! Perhaps there is code in [OZ]SS:SUBFORK.LSP which could help out here. I think I remember it defining some LAP functions to do direct Twenex OPENF jsys calls. You will need a Twenex JSYS manual to decode what is going on. This is a short term solution until I or someone else can find the cycles to do this right. --Chiron  Date: 12 Jul 1982 11:11 PDT From: JonL at PARC-MAXC Subject: Re: (OPEN 'FOO '(APPEND)) on TOPS-20 In-reply-to: GLR's message of 10 July 1982 21:43-EDT To: Jerry Roylance cc: BUG-LISP at MIT-AI Sure, editing MC:L;QIO > is the first step. Canonical Twenex sources used to be kept on [XX]SS:, and the Twenex .EXE file produced by submitting PS:ASSLISS.CTL -- but maybe sinze OZ is coming alive, the "canonical" place may be there. What about it ALAN, will you oversee this? Minor note: your suggested change probably wanted OPEN3E+2/ TRC 2, OF%WR+OF%RD instead of OPEN3E+2/ TRC 2, OF%RD didn't it?  Date: 12 Jul 1982 1109-EDT From: David C. Plummer Subject: opening files in 8 bit. To: bug-lisp at MIT-MC Might it be possible to add a feature to OPEN to allow it to open files in 8 bit mode. This might be T(W)ENEX dependent, but ITS lets you do other things more easily. Specific application: I want to open a CHA: file and read it in 8bit. I think ITS does this, but if it doesn't I can always do SYSCALLs (which I do anyway). (OPEN "CHA:MIT-OZ.STATUS" '(in 8bit)) ?? I don't care about the syntax, I would like the functionality. -------  Date: 10 July 1982 21:43-EDT From: Jerry Roylance Subject: (OPEN 'FOO '(APPEND)) on TOPS-20 To: BUG-LISP at MIT-AI cc: GLR at MIT-AI (OPEN 'FOO '(APPEND)) on TOPS-20 does not allow random access on the opened file. The code opens the file in OF%APP (append mode) which TOPS-20 must interpret as allowing only writes to the end of the file and enforces that by prohibiting the user from moving the filepos. The appropriate mode (see the OPENF JSYS) is OF%RD+OF%WR (read and write = update). Changing OPEN3E+2/ TRC 2, OF%APP+OF%WR+OF%RD to OPEN3E+2/ TRC 2, OF%RD allows random access. Would somebody please make this change or tell me how to do it? Do I just edit MC:L;QIO > ? Jerry  Date: 7 July 1982 14:54-EDT From: David Chapman To: BUG-LISP at MIT-AI, BUG-GPRINT at MIT-AI, BUG-ZWEI at MIT-AI progw and progv have bodys. Zwei, GPRINT, and GRIND-TOP-LEVEL none of them realize this.  Date: Monday, 5 July 1982, 20:03-EDT From: David Chapman To: BUG-lisp at MIT-AI In lisp in Remote-File 10.1, LMFILE-Remote 17.1, MIT-Specific 9.0, System 86.53, ZMail 45.4, Local-File 37.1, DAEDALUS 45.2, Tester 26.1, microcode 136, , on Lisp Machine Eight: I have a file of which there is only one version, macros.lisp.1. I qc-filed this, producing macros.qfasl.1. I then tried to qc-file the same file again. It died with a FAE error. Now, either the theory should be that qfasls get the same version mumber as their source, or else it should be that qfasls are given sequential version numbers like any other file. In the first case, the qfasl should be opened for write in overwrite mode; and in the second, the > version should be opened. Now maybe the current theory is that you do some heuristic combination of these two on the theory that you might want old qfasls for something, so they should never be overwriten, and you want to know which qfasls came from which sources, so in the case cited you can't win. I can't imagine any reason for keeping old qfasls generated from the same source, but in any case a better way of recovering would be to explain the problem and ask if the old qfasl should be overwritten or if the > version should be used instead. No doubt ``this will be fixed in the new error system'' with all the rest of file error handling.  Date: 30 Jun 1982 0446-EDT From: EGK at MIT-OZ (Edjik) To: KMP at MIT-MC cc: MERMAN at MIT-MC, BUG-LISP at MIT-MC, EGK at MIT-OZ In-Reply-To: Your message of 30-Jun-82 0007-EDT The reason valret works the way it does is because when the EXEC runs a program it takes the *LINE* of text that was used to invoke that program, prepends the name of the program and sticks that back into the rescan buffer for the program to read. this is why you can pass arguments to a program on the command line, ie, "finger foo" when typed to the EXEC will cause the exec to stick the string "FINGER foo" into the jobs rescan buffer. Since there is only one rescan buffer, anything else that might have been in the buffer is lost. When finger starts up, it checks the rescan buffer for any commands. TOPS-20 could use a set of pipes so input intended for a process could be done right. Various people have indicated a desire to put pipes into tops-20 but so far no one has done so. -- Edjik -------  Date: 29 June 1982 23:58-EDT From: Kent M. Pitman To: MERMAN at MIT-MC cc: BUG-LISP at MIT-MC Date: Tuesday, 29 June 1982 16:11-EDT From: Dave Goodine ... Is it possible to tell LISP to send a string to TWENEX and have it process it? I've tried using VALRET, but it doesn't seem to work as it does on ITS. Empirically, I note that VALRET works in a subtlely different way than on Twenex than on ITS. If there is input pending after a program is entered and that program doesn't use that input, the input is discarded. eg, (VALRET "F ") will work to invoke finger, and (VALRET "RESET . F ") will work to kill the current fork (RESET is a monitor command, not a program), but (VALRET "F CONT ") will end up with the CONT discarded, where the analagous (VALRET ":F P") would work just fine on ITS. Other than this misfature (and the amazingly losing habit Twenex has of typing "@" even tho' it's not going to echo the valretted text), VALRET seems to work reasonably for me, also.  Date: 29 June 1982 23:11-EDT (Tuesday) From: FEINBERG at CMU-20C To: Dave Goodine Cc: bug-lisp at MIT-AI Subject: (VALRET (...)) on TWENEX Howdy! Exactly what is losing? It seems to work fine for me on OZ. --Chiron  Date: Tuesday, 29 June 1982 22:57-EDT From: DICK at MIT-OZ To: FEINBERG at CMU-20C Cc: bug-lisp at MIT-AI Subject: Loading from LISP Boy do I feel dumb. The ppn property and all that junk is in lisp all right. You had the right idea with the crunit. I was doing something in one of the files I was loading that was setting the device default to DSK: and that was blowing everything out of the water later. Dick -------  Date: 29 June 1982 22:56-EDT (Tuesday) From: Chiron To: bug-oz at MIT-OZ, Bug-LISP at AI Subject: Lisp:, PPNs and Other Stories CC: Dick at OZ Howdy! Vanilla Maclisp at Oz seems to be autoloading OK, currently Dick is checking his LISP.INI file to see what specific problems might be lurking. I installed a file COMMON.INI which can be copied by naive users who don't want to bother to customize their own LISP.INIs. Included in the file is the magic PPN incantation, which should not be necessary, but is included just in case. --Chiron -------  Date: Tuesday, 29 June 1982 22:08-EDT From: DICK at MIT-OZ To: FEINBERG at CMU-20C Cc: bug-lisp at MIT-AI Subject: Loading from LISP First there already is a lisp device, the problem is that the autoad properties that are loaded with the standard maclisp point to the lisp directory, and not the lisp device. I was hoping some maclisp maintainer would fix that so they pointed to the device instead. Also what is the PPN kludge and would it fix this problem? I never heard of it before. Dick -------  Date: 29 June 1982 21:12-EDT (Tuesday) From: FEINBERG at CMU-20C To: DICK at MIT-AI Subject: Loading from LISP Cc: bug-lisp at MIT-AI Howdy! I believe the right solution is to define a LISP: device which points to PS:. You can also use the PPN kludge, which is mainly for losing TOPS-10, but which I feel has no place on a Twenex system. --Chiron  Date: Tuesday, 29 June 1982 16:11-EDT From: Dave Goodine Subject: (VALRET (...)) on TWENEX To: bug-lisp at MIT-OZ Is it possible to tell LISP to send a string to TWENEX and have it process it? I've tried using VALRET, but it doesn't seem to work as it does on ITS. -merman -------  Date: Tuesday, 29 June 1982 15:47-EDT From: DICK at MIT-OZ To: bug-lisp at MIT-OZ on OZ, there are a number of autoload properties that attempt to read files of the LISP directory. However, this directory does not exist. The files are actually on a directory LISP:. It seems that there are two easy ways to fix this. Change the directory to or change the autoloads to refer to the LISP device. We should do one or the other. Dick -------  Date: 26 Jun 1982 0501-EDT From: EGK at MIT-OZ (Edjik) Subject: init files and connected dirs To: bug-lisp at MIT-OZ 20x maclisp trys to get its init file from the connected directory rather than the users login directory. Is this what most people want? EMACS and other programs carefully take their init files from a users login directory and this seems philosophicly to be the right thing to do. I would be willing to make this little change if the powers than be deem it ok. Also, heres another plug to seperate tops-10 and tops-20 file name conventions. lets start by changing the tops-20 lisp.ini to lisp.init (ala emacs)! -- Edjik -------  Date: Saturday, 26 June 1982 01:50-EDT From: Skef Wholey To: Ken Harrenstien Cc: BUG-ATSIGN at MIT-AI, BUG-LISP at MIT-AI, BUG-OZ at MIT-AI, GJC.Skef at MIT-OZ, GSB at MIT-AI, MARTY at MIT-AI, RICH at MIT-AI Subject: ATSIGN Yes, I was indeed looking at an out-of-date version, so the PA1050 remark was bogus, but I am working on an extension to the LREC format that will allow long file names -- I know that that is the thing that has to be hacked.  Date: 25 June 1982 18:27-EDT From: Ken Harrenstien Subject: ATSIGN To: MARTY at MIT-AI, GJC.Skef at MIT-OZ cc: RICH at MIT-AI, GSB at MIT-AI, BUG-OZ at MIT-AI, BUG-LISP at MIT-AI, BUG-ATSIGN at MIT-AI You must not have looked very closely at the code, since I was the one who converted ATSIGN to flush the PA1050 package when running on 10X/20X systems. That is not an issue; it is already TNX-ized. The 6-char limitation on filename.ext is actually due to the format of LREC files and various other tables, which assume that filenames come in sixbit words. You cannot fix this fundamental problem without changing the LREC file format at the very least. It is possible, but it won't be easy. The MIDAS code in TSRTNS contains one mechanism for manipulating long filenames internally; it may be worth a look. I will FTP back my latest version of ATSIGN to make sure that all current mods are in the canonical copy. You should put yourself on bug-atsign if you start hacking anything...  Date: Friday, 25 June 1982, 17:45-EDT From: Robert W. Kerns Subject: Re: Extension for Lisp files To: JonL at PARC-MAXC Cc: Alan Bawden , RICH at MIT-AI, BUG-OZ at MIT-MC, BUG-LISP at MIT-MC In-reply-to: The message of 24 Jun 82 14:16-EDT from JonL at PARC-MAXC Date: 24 Jun 1982 11:16 PDT From: JonL at PARC-MAXC Unfortunately, the MacLisp choice for LSP was necessitated by compatibilitly between TOPS-10 and TOPS-20 implementations. ... It's not too late for Twenex MacLisp to become "incompatible" with TOPS-10 -- there's about three places in the system where the symbol LSP is built in (I could spend a little time on the phone with you if you'd like to tackle this one); also there's about half-dozen places where LSP is built in to lisp-based code (such as the places that look for FOO.INIT files for various systems FOO) which includes COMPLR, NILAID, SHARAB and possibly one or two more. But there are indeed many TOPS-10 lusers of MacLisp -- witness the cry for help by Pedro Otaduy recently. Of course, the LISP machine manages to call files FOO.LSP on VMS, foo.l on Unix, FOO.LISP on TOPS-20, and FOO > on ITS. MacLisp somehow feels that it's OK for namelists to be incompatible between ITS and TOPS-20, but not between TOPS-20 and TOPS-10.  Date: Friday, 25 June 1982 02:59-EDT From: Martin David Connor To: Skef Wholey Subject: The ATSIGN program Cc: Rich at MIT-OZ, GSB at MIT-OZ, Bug-OZ at MIT-OZ, Bug-LISP at MIT-OZ Date: 25 Jun 1982 0243-EDT From: Skef Wholey Subject: The ATSIGN program To: Marty at MIT-OZ Hi: I've spent a little time looking at @, and will proceed to make it at least accept full TOPS-20 file names, and possibly remove its dependency on the PA1050 compatibility package. --Skef ------- Great! Let us know what you come up with. If you need any info let me know. Go for it! Marty -------  Date: 24 June 1982 15:07-EDT From: Glenn S. Burke Subject: Extension for Lisp files To: ALAN at MIT-MC cc: BUG-OZ at MIT-MC, BUG-LISP at MIT-MC When we started transporting stuff written with LSB to SPEECH we just punted the maclisp convention, because the stuff was lispm source compatible. The LSB code, modulo a couple kludges like in the load function (which already does some checking), only really likes the LISP extension. Personally i think Maclisp should be changed.  Date: 24 Jun 1982 11:16 PDT From: JonL at PARC-MAXC Subject: Re: Extension for Lisp files In-reply-to: ALAN's message of 23 June 1982 20:33-EDT To: Alan Bawden cc: RICH at MIT-AI, BUG-OZ at MIT-MC, BUG-LISP at MIT-MC, BUG-ATSIGN at MIT-AI Unfortunately, the MacLisp choice for LSP was necessitated by compatibilitly between TOPS-10 and TOPS-20 implementations. The reason ATSIGN takes only 3-letter extensions of OZ is that it is running in TOPS-10 compatiblity mode. If any of you hackers fix this (i.e., get a native Twenex version of ATSIGN) Johan DeKleer and I sure would like a copy to use on MAXC. It's not too late for Twenex MacLisp to become "incompatible" with TOPS-10 -- there's about three places in the system where the symbol LSP is built in (I could spend a little time on the phone with you if you'd like to tackle this one); also there's about half-dozen places where LSP is built in to lisp-based code (such as the places that look for FOO.INIT files for various systems FOO) which includes COMPLR, NILAID, SHARAB and possibly one or two more. But there are indeed many TOPS-10 lusers of MacLisp -- witness the cry for help by Pedro Otaduy recently. [SHARAB *could* be made to work on Twenex too, but there's little point to it -- there is a more general facililty developed at Yale which works at the Twenex level, rather than the Lisp level, for aiding in incremental sharing of "cascaded" systems. KMP and GJC both had copies of it on the EE machine last fall.]  Date: 24 June 1982 01:02-EDT From: George J. Carrette Subject: Extension for Lisp files To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC, BUG-OZ at MIT-MC, RICH at MIT-AI I got a suggestion, since the Lispmachine software is infinitely more abstract and easy to change when it comes to things like filetypes in Pathnames we change the lispm software to use "LSP" as the extension for lisp program files. Seriously, who wants to hack things like LOAD in MIDAS, and the MAKLAP function in COMPLR? Have you seen that function???? I've hacked it in the past, but I think its like radiation absorbtion, you only get a limited quota per lifetime, and I want to save the rest of my exposure allowance for something that really matters. (Note: I may have used up a lot hacking Macsyma, but I think you develop anti-bodies for that.) -gjc  Date: 23 June 1982 20:33-EDT From: Alan Bawden Subject: Extension for Lisp files To: RICH at MIT-AI cc: BUG-OZ at MIT-MC, BUG-LISP at MIT-MC Date: 23 June 1982 10:49-EDT From: Charles Rich Hey Guys! I think there is a serious problem that people should know about right away. The version of the ATSIGN program we currently have on OZ, which everyone will want to use to make listings of their Lisp source files (Lispmachine and otherwise) really only accepts three letter extensions. This means you must name your lisp files FOO.LSP instead of FOO.LISP. Either we get a more winning version from somewhere or we should warn people now about this convention. A related screw is that LispMachines use the extension LISP for source code, while MacLisp uses the extension LSP. Thus you must choose which lisp you will be forced to type the extensions to. I like LISP better than LSP, and I really wish I could convince MacLisp to default to that instead (the LOAD function, the autoloader and complr's command-line parser being the most obvious manifestations). Suggestions?  Date: 23 June 1982 08:10-EDT From: Alan Bawden Subject: LIBLSP directory on OZ To: INFO-MACLISP at MIT-MC cc: BUG-LISP at MIT-MC, BUG-OZ at MIT-MC I just spent several hours copying the contents of the LIBLSP; directories on AI, ML and MC onto a new directory on OZ. This means that things like (load '((liblsp) laugh)) will do the same thing on OZ that they do on ITS. The contents of the LIBDOC; directories have also been copied onto . (Reunited with their fasl files just as they used to be on ITS before there was a directory overflow.) I made a great many small decisions about which versions of various packages to take (there were many inconsistencies across ITS's). I tried to take the most up-to-date version of everything, but I probably goofed up many times. If you maintain a package on LIBLSP, you might consider checking that I have moved an acceptable source and fasl of your package to OZ. I did not move any package that I personally knew was specific to ITS, but that means I certainly moved many that were. People are invited to delete packages that they are SURE will be useless on OZ. I was forced to change the name of one package: DEBUG* became DEBUG-STAR.  Date: 21 Jun 1982 23:05 PDT From: JonL at PARC-MAXC Subject: Re: MacLisp on OZ -- the LISP: logical name In-reply-to: ALAN's message of Sunday, 20 June 1982 23:46-EDT To: ALAN at MIT-AI cc: bug-lisp at MIT-AI, bug-oz at MIT-AI This started before the PPN hack was generalized (the PPN hack starrted on TOPS-10). MacLISP should work perfectly well without the LISP: device/logicalname, but if there is such, and if it doesn't point to the PS: directory, then the PPN hac gets de-installed at startup time. It's very highly recommended that software access system stuff through the lisp-leve device "LISP" rather than through (PS MACLISP) so that (ho ho) one could actually put the lisp system on say LIB: rather than PS:. But in either case, the PPN hac is an independent thing (except in so far as the startup code will remove it if it is inconsistent). Possibly the check for "consistency" between a logical name LISP: and the PPN property of LISP depends upon the existence of a file LISP:SITE.TXT [which as I mentioned before holds the value for (STATUS SITE)], but I hope not. It would probably be better to check for LISP:LISP.EXE.  Date: 22 June 1982 01:06-EDT From: George J. Carrette Subject: MacLisp on OZ To: ALAN at MIT-OZ cc: bug-lisp at MIT-OZ, bug-oz at MIT-OZ Its a good idea to move LIBLSP to OZ. I have a tendency to like the name though, and to give LIBLSP the right PPN property. Speaking of TOPS-20 maclisp, here are a couple bugs to remember to fix. [1] When you run COMPLR.EXE use INFO MEMORY and note that you don't get any sharing with the MACLISP.EXE from which the COMPLR was suspended. FIX: Move MIT-EE:SHARE.EXE to on OZ, and use it instead of SAVE to make the COMPLR.EXE file. [2] There is a bug in TTY initialization after SUSPEND which shows up for example in COMPLR and SCHEME on MIT-EE (when you SUPDUP). FIX: Mike Travers has the fix. -gjc  Date: 21 June 1982 21:34-EDT From: Alan Bawden Subject: PS:SITE.TXT To: sjk at MIT-OZ cc: BUG-LISP at MIT-MC, feinberg at MIT-OZ Date: 21 Jun 1982 1807-EDT From: Scott J. Kramer To: feinberg at MIT-OZ cc: alan at MIT-OZ Re: PS:SITE.TXT I changed it from OZ to MIT-OZ... best to use the official name. scott And for the second time, I changed it back to just OZ so that it would match all the rest of the sites at MIT (EE, MC, ML etc.). DON'T change it again, I have already written it into my code.  Date: 21 Jun 1982 1429-PDT From: MACLISP at SRI-AI Sender: SCOTT at SRI-AI To: ALAN at MIT-OZ cc: bug-lisp at MIT-MC In-Reply-To: Your message of 20-Jun-82 2003-PDT Create a LISP: (normally PS:) SITE.TXT file and you'll win. scott -------  Date: Sunday, 20 June 1982 23:46-EDT From: ALAN at MIT-OZ To: bug-lisp at MIT-OZ, bug-oz at MIT-OZ Subject:MacLisp on OZ Would it be useful to move the LIBLSP directory from ITS to OZ? Some of the more useful things are already present in (such as STEP and APROPOS) but people may have come to depend on some of the other, less commonly used utilities. Also people are liable to have things like (load '((liblsp) frob)) in their code, and it would be nice to make the transition easy for them. (I just moved the DRIBBLE package into , it has a tendency to name files "dribbl.>.1", but it is still useful.) On EE there is a LISP: logical-name for ps:. I presume this is so that the MacLisp specific hack where ((LISP) FOO) gets translated to ((PS MACLISP) FOO) by virtue of the symbol LISP having a PPN property of (PS MACLISP) will work in the entire Twenex environment. This sounds like a good idea, perhaps OZ should have it to. -------  Date: Sunday, 20 June 1982 22:47-EDT From: ALAN at MIT-OZ To: bug-lisp at mc Subject:OZ In the currently installed MacLisp on OZ (status site) returns TOPS-20, which is indeed the second to the last element on the (status features) list. (status feature OZ) returns NIL. What has to be done to get the site-name to appear there? I'd be happy to learn how to go about installing MacLisps on a TOPS-20 site since I'll be a user of it on OZ. -------  Date: 20 June 1982 02:56-EDT From: Glenn S. Burke Subject: FORMAT's ~a1,a2,b1,b2,...:; To: KMP at MIT-MC cc: BUG-LISP at MIT-MC Date: 20 June 1982 02:11-EDT From: Kent M. Pitman Format with a ~[... ~'A,'Z,'a,'z:; ...~] as described on page 350 of the purple LispM manual does not win. It catches #/a fine, but #/d falls through to the 'other' clause. I reported this back in January but it was never fixed. And it is probably still somewhere in my rmail file waiting for me to go back over the things i didn't handle immediately. Anyway, i took a look at the source and the bug was obvious and the fix should appear shortly; there have been other changes recently for Multics and NIL versions so i'm not up for testing a new version tonight. (The colon test was backwards...)  Date: 20 June 1982 02:11-EDT From: Kent M. Pitman Subject: FORMAT's ~a1,a2,b1,b2,...:; To: GSB at MIT-MC cc: BUG-LISP at MIT-MC Format with a ~[... ~'A,'Z,'a,'z:; ...~] as described on page 350 of the purple LispM manual does not win. It catches #/a fine, but #/d falls through to the 'other' clause. I reported this back in January but it was never fixed. -kmp  Date: Saturday, 19 June 1982, 15:08-EDT From: David A. Moon Subject: Proposed new FORMAT operator: ~U("units") To: Guy.Steele at CMU-10A Cc: bug-lisp at MIT-AI, bug-lispm at MIT-AI, common-lisp at SU-AI In-reply-to: The message of 11 Jun 82 22:33-EDT from Quux Tilde yourself! I think this is a little too specialized to go into FORMAT.  Date: 17 June 1982 20:21-EDT From: Mark J. Dulcey To: BUG-ITS at MIT-AI, BUG-BOLIO at MIT-AI, BUG-LISP at MIT-AI I corrected a bug in the file AI: LMIO1; RFONTW >, and installed the changes on the Lisp Machine. However, I know that these functions are also used by other folks (not on the Lisp Machine), so I thought I'd let you know so you can recompile and load the new FASL files.  Date: 15 June 1982 00:16-EDT From: George J. Carrette To: PJO at MIT-MC cc: BUG-LISP at MIT-MC Date: 14 June 1982 18:01-EDT From: OTADUY PEDRO J. To: BUG-LISP Nobody has responded to my report on FILLARRAY etc bugs. Does anybody care????? Yes. I heard that this is one of the things "fixed in the new error system." But seriously, (maybe thats too much of an inside joke) people do care if local programs and research groups running on local systems, TOPS-20 and ITS, are hurt by maclisp bugs. The only people to maintain maclisp at MIT now are those who support systems such as BRANDX and MACSYMA, and/or still maintain serious personal working environments in Maclisp. Maclisp is also used to support a Scheme system used in teaching. [One big local use of Maclisp, to support the NIL cross-compiler, is "no more" because NIL is perfectly happy running on the VAX where it should. This might also imply something about support for many features which were added as "NIL compatibility," especially since none of the "NILCOM" code was ever used in NIL.] Note: JONL who as the maintainer of pdp10 maclisp used to fix bugs and add other things, is no longer at MIT. In summary, people do care. There are good hackers at MIT that want to make sure that pdp-10 maclisp has a long and useful "old age." It make take a couple months before you see any particular action though. -gjc  Date: 14 June 1982 18:01-EDT From: OTADUY PEDRO J. To: BUG-LISP at MIT-MC Nobody has responded to my report on FILLARRAY etc bugs. Does anybody care?????  Date: 12 June 1982 1119-EDT (Saturday) From: Quux To: bug-lisp at MIT-AI, bug-lispm at MIT-AI, common-lisp at SU-AI Subject: More on ~U (short) Sender: Guy.Steele at CMU-10A Reply-To: Guy.Steele at CMU-10A I forgot to mention that the @ flag should cause scaling by powers of 2^10 instead of 10^3: (format () "~Ubits, ~:Ub, ~@Ubits, ~:@Ub" 65536 65536 65536 65536) => "65.536 kilobits, 65.536 Kb, 64.0 kilobits, 64.0 Kb" --Q  Date: 12 June 1982 03:23-EDT From: Kent M. Pitman To: BUG-MACLISP at MIT-MC I replied to EIS@AI re stack unwinding, also mentioning that INFO-MACLISP was the wrong place for him to send the query.  Date: 11 June 1982 2233-EDT (Friday) From: Quux To: bug-lisp at MIT-AI, bug-lispm at MIT-AI, common-lisp at SU-AI Subject: Proposed new FORMAT operator: ~U("units") Sender: Guy.Steele at CMU-10A Reply-To: Guy.Steele at CMU-10A Here's a krevitch that will really snork your flads. ~U swallows an argument, which should be a floating-point number (an integer or ratio may be floated first). The argument is then scaled by 10^(3*K) for some integer K, so that it lies in [1.0,1000.0). If this K is suitably small, then the scaled number is printed, then a space, then a metric-system prefix. If not, then the number is printed in exponential notation, then a space. With a :, prints the short prefix. Examples: (FORMAT () "~Umeters, ~Uliters, ~:Um, ~:UHz" 50300.0 6.0 .013 1.0e7) => "50.5 kilometers, 6.0 liters, 13.0 mm, 10.0 MHz" And you thought ~R was bad!  Date: 6 Jun 1982 1526-EDT From: Scott Robinson To: bug-lisp at MIT-MC Subject: LOAD-BYTE, DEPOSIT-BYTE bugs .... Message-ID: <"MS10(2055)+GLXLIB1(1056)" 11829722457.14.254.71284 at DEC-MARLBORO> I have discovered a few bugs in LOAD-BYTE and DEPOSIT-BYTE generation by SRCTRN 20. They are: 1) LOAD-BYTE didn't evaluate the shift displacement in the generated code. This was a typeo. 2) DEPOSIT-BYTE didn't shift the byte to be deposited before anding with the 'hole' mask. The following is a SRCCOM of the fixes to SRCTRN 20 to eliminate these problems. (How do I get the MIT-MC sources updated?) Thanks, Scott Robinson (617) 467-6988 SROBINSON@DEC-MARLBORO ; SRCTRN.LSP.21 & SRCTRN.LSP.20 6-Jun-82 1451 PAGE 1 LINE 12, PAGE 1 1) (setq |verno| (cond ((fixp x) file) ('/21))))) 1) LINE 12, PAGE 1 2) (setq |verno| (cond ((fixp x) file) ('/20))))) 2) LINE 65, PAGE 3 1) (setq word `(LSH ,word (- ,position)))) 1) `(BOOLE 1 ,word ,byte-mask)))) LINE 65, PAGE 3 2) (setq word `(LSH ,word ,(- position)))) 2) `(BOOLE 1 ,word ,byte-mask)))) LINE 77, PAGE 3 1) ((let ((lsher `(LSH ,val ,position)) 1) (masked-word `(BOOLE 4 ,word ,shift-mask))) 1) (if (and nval (= nval 0)) LINE 77, PAGE 3 2) ((let ((masked-word `(BOOLE 4 ,word ,shift-mask))) 2) (if (and nval (= nval 0)) LINE 84, PAGE 3 1) `(BOOLE 1 ,lsher ,shift-mask))))))))))) 1) (ldbp `(BOOLE 1 (LSH ,word (- ,position)) ,byte-mask)) LINE 83, PAGE 3 2) `(BOOLE 1 ,val ,shift-mask))))))))))) 2) (ldbp `(BOOLE 1 (LSH ,word (- ,position)) ,byte-mask)) --------  Date: 2 June 1982 2223-EDT From: Dave Touretzky at CMU-10A To: bug-lisp at MIT-MC Subject: bug in TOPS-20 MacLisp terminal i/o The file CSTEP.FASL on CMU-20C contains a CMU-modified version of the Rich stepper. It demonstrates a bug in TOPS-20's i/o routine for reading single characters from the terminal. To check out this bug you should load the CMU programming environment described in the files LISP.INI and COMMON.INI on CMU-20C. One especially pertinent item: we run with (status linmode t). After starting up a fresh Lisp, do the following: (STEP T) ;load CMU's stepper (PLUS 1 2) ;note that stepper isn't reading a space alone -- it ;needs a to terminate the read (bogus!) ^C START ;restart Lisp (STEP T) ;try the stepper again (PLUS 1 2) ;now it can read by itself! ^G ;quit to toplevel again (STEP T) ;try the stepper one more time (PLUS 1 2) ;now it can't read !!!! Clearly the terminal initialization done by START and that done by ^G is not the same. I claim that only START does the initialization correctly. -- Dave Touretzky  Date: 14 MAY 1982 1607-PDT From: JONL at PARC-MAXC Subject: Assembling MacLISP under TOPS-10 To: david at MIT-AI cc: BUG-LISP at MIT-MC Several mesages will be printed out that do not reflect true "errors", but were merely inserted in the source code so that the lisp maintainers would be reminded of some lacunae in the non-ITS versions. The comment about "###### HOW TO SHAR WITH PURQIO FILES" is no problem. On the other hand, the VECALL undefined is a true error, and is probably symptomatic of some failure to conditionalize code for the SAIL-specific assembly (SAIL is a variant of TOPS-10). It's generally true that non-virtual-memory TOPS-10 sites have troubles running anyything interesting in MacLISP; a total core allotment of about 100K would be reasonable for the Compiler, and as I recall, many sites restrict the random user to about 40K or so. See if you can get a larger allotment "late at nite".  Date: 14 May 1982 16:51-EDT From: David M. Krowitz To: BUG-LISP at MIT-AI When I try to compile lisp 2129 using the TOPS10 switch, I get the following error messages: sharp1+1 3060 2. 37-022 ###### HOW TO SHARE WITH "PURQIO" FILE? gethgh 3107 0. 38-079 VECALL Undefined I am using midas 428 running under tops10 version 6.03A on a regular KA10 (ie. no paging hardware has been added). In addition to these error messages, the lisp version number is typed out as 687194. I am able to load the relocatable binary file which is provided with the lisp distribution tape, but it seems to run out of memory space very quickly. typing something like (ARRAY FOO T 5000.) usually result in a "can't get core" message. Trying to load COMPLR.FAS runs into the same problem. --david krowitz  Date: 12 May 1982 20:49-EDT From: David C. Plummer To: MACRAK at MIT-MC cc: BUG-LISP at MIT-MC Try -1^ someday for grins...  Date: 12 May 1982 20:47-EDT From: Stavros M. Macrakis To: BUG-LISP at MIT-MC 12_ returns 24000 i.e. 12_12  Date: 10 May 1982 15:11-EDT From: OTADUY PEDRO J. To: BUG-LISP at MIT-MC This is Pedro at ORNL. I am trying to get Maclisp version 2022 up in our KA10-TOPS10. I have found bugs in array related functions. FILLARRAY,FILEPOS,IN and LOADARRAYS have fatal BUGs in this version. I have observed that they are not present in the version presently running at your MC site. Can anyperson give me the patchup recepy? FILEPOS symptoms: Let 0=0 be case #2 , (FILEPOS fidump)=3 be case #3 where fi is a FIXNUM file OPen for INput created by (FILLARRAY fi 'ARRAYX) , and fidump is same but created by a DUMPARRAYS command. THEN... (FILLARRAY 'ARRAYN fi) Halts at 444066 for both cases #1 and #2...but on reentering 'ARRAYN shows to be unchanged in case #1 ,while 'ARRAYN shows the correct info in case #2. ON the other hand (?) case #3 works satisfactorily. LOADARRAYS was not working at all.Upon some study i found IN to be the culprit. Replacing the JUMPN 10,452756 @453015 (inside IN) with a JUMPG ... instruction did fix LOADARRAYS. Now i don't know if this is Kosher but it works. Gratious reader of this missive...if you can help with these bugs and do so I will be most grateful. Also, are there any other bugs I should be aware of? THanks. sincerely..pedro.  Date: 6 MAY 1982 1041-PDT From: JONL at PARC-MAXC Subject: Of%Pdt To: zubkoff at CMUC, feinberg at CMUC cc: fahlman at CMUC, bug-lisp at MIT-MC Feinberg's note was quite right -- I've already edited the MC sources for the Gj%Acc change. I also agree with him that no change should be made in the Lisp semantics for what appears to be a CMU-specific bug (failure to update read date doesn't occur at XX). Perhaps most TOPS-20 systems do reap the directory, but the corresponding directory on the ITS machines is maintained "by hand" for just the reasons noted -- the difficulty of maintiaining a coherent systems when critical, but seldom referenced, parts disappear randomly.  Date: 5 May 1982 22:29-EDT (Wednesday) From: FEINBERG at CMU-20C To: Leonard N Zubkoff CC: Bug-Lisp at MC, Fahlman at CMU-20C Subject: Changes to Maclisp --Text follows this line-- Howdy! I believe the Jonl has already updated maclisp wrt Gj%Acc. As for Of%Pdt, I suspect that the monitor bug should be fixed, not Maclisp. Certainly checking to see if a file is a FASL file should not constitute reading it. I suggest that we just run with your modified version of Maclisp on CMUC until Aaron Wohl gets around to fixing the bug. Also, perhaps there is a way to prevent the reaper from reaping the directory, which I think is a bad idea in the first place. It is hard enough to keep Maclisp running without files magically disappearing onto tape. Unless a significant number of other sites are encountering this problem, we should stick with a local fix. --Chiron Subject:  Date: Wednesday, 5 May 1982 21:48-EDT From: Leonard N Zubkoff To: Steele at CMU-20C, Fahlman at CMU-20C, Jonl at Parc-Maxc, Bug-Lisp at mc Subject: Changes to Maclisp We've recently discovered a peculiar interaction between MacLisp and the migration system program (reaper). It seems that some .fasl files that were being accessed by MacLisp frequently were not having their last-read dates updated properly, causing them to be migrated and thus making MacLisp unusable until they were restored. Our system programmer, Aaron Wohl, postulates that this is caused by MacLisp's first opening a file with the do-not-update-read-date bit set (Of%Pdt) and then actually opening the file for reading. Apparently, the monitor is then failing to update the read date on the second file opening as well. Searching through the Lisp sources, it appears that the only place such an Openf% is ever used is in the function FASLP; also, it seems highly likely that most uses of FASLP would be immediately followed by actually reading the file. In order to alleviate this problem, I've built and installed Lisp version 2130 on CMUC using a modified QIO.mid with the following changes: (1) Of%Pdt is no longer set on the Openf% in FASLP. (2) All GtJfn% calls have had the Gj%Acc removed, so that the files are visible (this change in response to discussions with Jonl indicating that this would be a good idea). If whoever is responsible for maintaining the master Lisp sources would make these changes there as well, it would be appreciated. Alternatively, just ftp the file Ps:Qio.mid.751 from CMUC. Leonard Zubkoff  Date: 3 May 1982 23:53-EDT From: Kent M. Pitman To: BUG-LISP at MIT-MC (setq a (open 'tty: '(in fixnum tty single))) (in a)^C ;(IN #FILE-IN-|TTY:* *|-70776) EOF - IN IN does not see control-C in a file as an EOF, I don't know why it should on the TTY. In particular, if the person has the tty open, he ought to know he does anyway. If he wants to interpret ^C as an eof, it seems easy for him to do so. I imagine it is probably irritating to anyone that tries this that ^C is trapped in this way ... I don't need this to work for code, so it's not worth fixing for now unless it is bothering someone else. I just thought I'd note the problem. -kmp  Date: 27 April 1982 16:36-EDT From: Glenn S. Burke Subject: OOPS To: BUG-MACLISP at MIT-MC cc: DCP at MIT-MC Long long time ago, (status xuname), (status xjname) and (status hsname) were flushed in favor of the more abstract names USERID, SUBSYSTEM, and HOMEDIR. (status hsname) somehow managed to creep back in, taking additional arguments to allow it to find the hsnames of other people (and on other ITSs), using new hairy .break stuff with ddt; (status homedir) doesn't take these magic args, and anyway (status hsname) only exists (well, it should) on ITS unless there was more of what follows. The fact that (status xuname) exists sounds like a momentary lapse somewhere. I'm sure it had been flushed once, and can't see why it might have been reinstated. Anyone want to 'fess up? Seems superfluous to me.  Date: 26 April 1982 21:25-EST From: Alan Bawden Subject: (STATUS STATUS) To: DCP at MIT-MC cc: BUG-MACLISP at MIT-MC Date: 26 April 1982 16:59-EST From: David C. Plummer Why is there no (STATUS XJNAME) ?? (STATUS SUBSYS) Don't ask me why.  Date: 26 April 1982 16:59-EST From: David C. Plummer Subject: OOPS To: BUG-MACLISP at MIT-MC Sorry about that... Why is there no (STATUS XJNAME) ??  Date: 26 April 1982 16:04-EST From: David C. Plummer To: BUG-MACLISP at MIT-MC Why is there no (STATUS XUNAME) ??  Date: 22 April 1982 14:31-EST From: George J. Carrette Subject: &mumbles at all levels. To: ALAN at MIT-MC cc: BUG-LISPM at MIT-MC, LISP-FORUM at MIT-MC, BUG-LISP at MIT-MC, DULCEY at MIT-ML Go for it! Indeed, for the destructuring implementation for NIL I implemented &mumbles at all levels, and it was easier, cleaner, and produced considerably less code per DEFMACRO than using the other methods. For example, the following defmacro: (defmacro g ((a b (c d)) &optional e) (foo a b c d e)) compiles into 42 pdp-10 instructions using the technology presently provided in Maclisp, but only 7 pdp-10 instructions using the technology used in NIL (inside the compilation environment in pdp-10 maclisp which *was* used to compile the cross compiler). -gjc  GSB@MIT-ML 04/18/82 22:50:12 Re: like wow, man, catch this FSM To: (BUG LISP) at MIT-ML "0.0966z" says "illegal token parsed", but "0.0966:" reads in as the symbol "00966:".  Date: 17 April 1982 17:20-EST From: William G. Dubuque Sender: BIL at MIT-MC To: JONL at MIT-MC cc: BUG-LISP at MIT-MC It seems that the &optional bug is back: (defun f (&optional (x x)) x) You claimed this was fixed in DEFMAC 165. Most probably it was broken with your &AUX fix in 166.  Date: 13 April 1982 05:23-EST From: Kent M. Pitman Subject: ASSQ and SI:ASSQ-CAREFUL To: GSB at MIT-MC cc: BUG-LISP at MIT-MC I know there is a lot of code in Maclisp which depends on the careful way Maclisp works in *RSET T mode. I'd say slow down the ASSQ in *RSET NIL mode and make it do the same thing. Changing things the other way will break a lot of existing code.  Date: 13 April 1982 03:30-EST From: Howard I. Cannon To: GSB at MIT-MC cc: BUG-LISP at MIT-MC, JLK at MIT-MC I think the reason it checks .BCHN for being 0 is that it starts out zero, so it may think it's checking for a "spurious IOC error". Why don't you change it to try reading the error code, and if that fails, just jump to IOCER9. I assume STATUS fails on a channel that isn't open.  Date: 12 April 1982 14:54-EST From: Glenn S. Burke To: BUG-LISP at MIT-MC cc: HIC at MIT-MC, JLK at MIT-MC IOCERR special-cases a .BCHN of 0 and fails to read the error coode into D. I can't see hw this can be really worth anything, especially since it will still jump to IOOCER8 and maybe call the IOCINS. (Otherwise it shoould jump to IOOCOER9 which wouoldn't call IOCOINS.) (Excuse the typicing spasticity, especially "O" key, this is a Brand New Keyuboard installed by Techincal Services.) I will change this somehow unless somoeone can tell my why not to. This blooows away the (admittedly uncoommon) case where the channel number is incorrect. But also, it can make it difficult to use channel 0 tempoorarily. n.b. i can't break any lisp-internal iooc-traps because there aren't any.  Date: 12 April 1982 14:05-EST From: Glenn S. Burke Subject: Re: assq compatibility with Maclisp To: JONL at PARC-MAXC cc: BUG-lisp at MIT-MC There is no non-pair check in the fast loop. The slow loop claims it is allowing a toplevel NIL in the list to be ignored, although what it actually does is to do a pairp test, therefore becoming assq-carefully. The problem we have here is that we need to decide if this is a feature or not, to what extent (NIL only, or non-pairs), and can we afford support it. My own memory tells me that we used to have only the fast loop; unfortunately, this produced behaviour which approximated assq-carefully (unless you came up with a losing case), and people came to use and depend on it, thinking of it as a feature. Anyone know if there is a common-lisp stance on this kludge/feature?  Date: 12 APR 1982 1041-PST From: JONL at PARC-MAXC Subject: Re: assq compatibility with Maclisp To: GSB at MIT-ML cc: bug-lisp at MIT-MC In-Reply-To: Your message of 11-APR-82 1337-PST The "feature" in question is "fast" execution -- thus the (*rset nil) case doesn't check the type of the list items. I guess there was an addition somewhere to the semantics of assoc/assq such that non-PAIR's were treated as (NIL . NIL) -- apparently this didn't get put into the "fast" non-error-checking loop? -------  Date: 11 April 1982 16:37-EST From: Glenn S. Burke Subject: assq compatibility with Maclisp To: JCMA at MIT-AI, BUG-lisp at MIT-MC cc: BUG-LISPM at MIT-AI Date: Saturday, 10 April 1982, 06:04-EST From: JCMA@MIT-AI Why do assq and assoc have to be incompatible with maclisp? That is, why aren't assoc-careful and assq-careful the defaults? ---- It happens that Maclisp does not actually do assq-carefully, at least not deliberately. It simply fails to check, and so can be fooled. ---- [transition to bug-lisp report] ---- uh oh... Even though i "knew" what maclisp was doing, i figured that i would test it to see. The little cretin does assq-carefully in (*RSET T) mode, and doesn't in (*RSET NIL) mode. What this means is that the following happens in (*rset nil) (assq nil '(0)) => 0 and in (*rset t) it yields NIL. The reason for this is that the CAR of the fixnum 0 gives NIL. Similarly one can create other fixnums (and flonums) which will fool assq for any other object. So much for features. This sounds like a totally useless, misleading, and inconsistent Maclisp feature. It is a waste of the address space which someone has been trying hard to conserve. If it is going to check, it should bitch, it shouldn't conditionally do the wrong thing.  DGB@MIT-MC 04/04/82 23:30:22 To: info-lisp at MIT-AI Does anyone out there have a nice format for implementing Lisp on a micro (specifically a 6809)? Or is there a public domain version of 6809 lisp living somewhere on the net? Replies to DGB at MIT-MC.  Date: 2 April 1982 03:05-EST From: Jon L White To: ben at MIT-ML cc: TY at MIT-MC, BUG-LISP at MIT-MC I sent a tape to Kevin Sullivan about two months ago or so, and we spoke on the phone about loading it up. I though Kevin was to phone me back if there were any problems, and didn't hear from him again. There have been other TOPS-10 sites which had trouble reading the tapes written on the XX drives; I don't know where the problem is.  Date: 1 April 1982 2214-est From: Antonio Elias Subject: Steppers, etc. To: bug-lisp at mit-ai Dear sirs: This is not a bug gripe; I have been referred to you for possible information on Maclisp, since nobody in the Multics-world seem to be able to answer: In the current (Rev. 1, post-Moon) Maclisp manual there exists a reference to a wonderous device called "The Morgenstern Stepper", available, so is claimed, "in the Multics implementation". Needless to say, the prescribed incantation fails to produce anything other than an unbound symbol barf. QUESTION: Is this, or any other stepper, available "in the Multics implementation", or can such a device be transferred from another implementation to Multics Maclisp (assuming evalhook and any other necessary goodies are still alive...) Are there, or have there been any plans to implement "The Extensions" (defstruct, setf, etc.), other than backquote, in Multics? Thanks, -- Antonio Elias (x7504, Aero & Astro)  BEN@MIT-ML 03/31/82 15:01:28 Re: TOPS-10 Maclisp for Tufts To: TY at MIT-ML CC: BEN at MIT-ML, MERMAN at MIT-ML, (BUG LISP) at MIT-ML Ty, Quite some time ago, I asked JONL to send a tape of TOPS-10 MACLISP to Tufts. We had several rounds of sending tapes that turned out to have parity errors, according to tapedrives at both MIT and Tufts. Jonl currently has (or had) a tape of ours, and we still don't have MACLISP. Could you make us a MACLISP tape and send it to Tufts? Kevin Sullivan Computer Services Tufts University Miller Hall Medford, MA 02155. If this is a problem, or if there is something I should do, could you send me a message? We have been working with a 1979 MACLISP for quite some time, and it's getting crufty. Thanks very much. Ben  Date: 31 March 1982 07:25-EST From: Glenn S. Burke Subject: fc lossage? To: BUG-its at MIT-AI cc: BUG-LISP at MIT-ML, EB at MIT-ML Date: 30 March 1982 19:31-EST From: Edward Barton :lisp LISP 2122 Alloc? n * (open "fc:eb;ef >") MPV; 61322>>.CALL 61641 (RCHST) ---- The MPV does not come from the call, and no words have been written by it. This does not happen on ML, where apparently no one has been updating DEVICE;JOBDEV FC for some time.  Date: 30 March 1982 19:31-EST From: Edward Barton To: BUG-LISP at MIT-AI :lisp LISP 2122 Alloc? n * (open "fc:eb;ef >") MPV; 61322>>.CALL 61641 (RCHST) Foo.  Date: 24 March 1982 19:47-EST From: Kent M. Pitman Subject: For better or worse (likely the latter)... To: Rees at YALE cc: BUG-LISP at MIT-MC, Nicolau at YALE, Ruttenberg at YALE Feature. There is no hardware for doing better than that on KA's, so even tho' KL's and 20's and such could use double precision, it isn't done. At least that's my understanding of why the case of PLUS errs. PLUS is defined to error check (sadly, if you number declare its args, it no longer will, but you can explain to the folks there about that, I assume). Anyway, the answer to your question is that +$ is defined to -- for better or worse -- yield whatever the hardware yields for that operation, and the hardware always gives back some answer, it never errs. So you always get whatever trash it gives back when you do bounds over/under-running. Use PLUS with no declarations if you care about error checking. --kmp ps. the same lossage applies to +, //, //$, and their spelled out counterparts. pps. oops. not lossage. sorry. the same "feature" applies...  Date: Wednesday, 24 March 1982 19:35-EST From: Jonathan Rees To: Bug-Lisp at MIT-MC Subject: Floating point add Cc: Nicolau at YALE, Ruttenberg at YALE (+$ 1.595524E+38 1.13966002E+37) 1.47634439E-39 whereas (plus 1.595524E+38 1.13966002E+37) ;ARITHMETIC OVERFLOW ;BKPT *RSET-TRAP Is this a bug or a feature?  Date: 23 March 1982 16:07-EST From: John G. Aspinall Subject: fixing, flooring, ceiling,... To: BUG-LISP at MIT-MC About a year or two ago I remember a discussion on LISP-DISCUSSION about the various rounding functions, and a suggestion that someone implement the set for MacLisp. There was a standard (IEEE ?) that specified them. Was this ever done? To remind - round towards zero : fix - round towards -infinity : floor - round towards +infinity : ceiling - round away from zero : John.  Date: 16 March 1982 19:42-EST From: George J. Carrette To: SOLEY at MIT-MC, DCP at MIT-MC cc: BUG-LISP at MIT-MC Do you guys really expect to see bugs in the Maclisp reader fixed? Geeeezzzz, I don't believe it. You can always write one yourself in lisp, load EE:READER.FASL, but then the tty-prescan won't jive, so load KMP's rubout handler from EE:RUB.FASL. Don't like the evaluator? Well, replace that too. Keep it up, and you soon run out of core.  Date: 16 March 1982 14:59-EST From: Richard Mark Soley To: DCP at MIT-MC cc: BUG-LISP at MIT-MC Date: 16 March 1982 13:11-EST From: David C. Plummer To: BUG-LISP >>>>>>>>>>>>>>>>>>>> GROSS <<<<<<<<<<<<<<<<<<<< typing 2.2.2 gives 2.0 0.2 >>>>>>>>>>>>>>>>>>>> GROSS <<<<<<<<<<<<<<<<<<<< BUG! BUG! BUG! It prints "2.2" then "0.2". -- Richard  Date: 16 March 1982 13:11-EST From: David C. Plummer To: BUG-LISP at MIT-MC >>>>>>>>>>>>>>>>>>>> GROSS <<<<<<<<<<<<<<<<<<<< typing 2.2.2 gives 2.0 0.2 >>>>>>>>>>>>>>>>>>>> GROSS <<<<<<<<<<<<<<<<<<<<  Date: 13 Mar 1982 0849-EST From: Jon L. White Subject: Making MacLISP distribution tapes on XX To: ty at MIT-XX cc: bug-Maclisp at MIT-MC I've changed the EXPORT program on MC (fasl is on LISP20; directory, and you can start it running with the lisp init file for export ther by saying :MACLISP LISP20;EXPORT LISP). It now puts out an @ENABLE rather than @ACCESS SS:, and I've tested that it works and makes tapes using my login too. -------  Date: 9 March 1982 14:43-EST From: Jon L White Subject: Restricted JFN's To: Touretzky at CMU-10A, Feinberg at CMU-20C cc: BUG-MACLISP at MIT-MC, Zubkoff at CMU-20C I don't really have any investement in keeping JFN's restricted -- since you obviously have a strong feeling for their being full accessed then the obvious thing to do is merely flush the GJ%ACC bits rather than try yet-another-switch. I've just edited the source for QIO to let OPEN (and consequently LOAD) use unrestricted JFN's. But the other "internal" functions will stay the same unless someone finds a reason to change them too (namely, PROBEF, DELETEF, RENAMEF, FASLP). Maybe you wan't to ask Zubkoff to get the latest stuff on CMUC?  Date: 8 March 1982 2007-EST From: Dave Touretzky at CMU-10A To: jonl at MIT-MC Subject: restricted JFN's CC: feinberg at CMU-20C, bug-maclisp at MIT-MC I agree with Feinberg's suggestion, except I think the default should be to not restrict the JFNs. I find the @INFO FILES command a quick and useful check of what a program's been up to; restricting that information (or making it harder to get at than simply typing ^C and @INFO FILES) is counterproductive to 99% of MacLisp users. Sure, there might be a subfork hacker out there who is so paranoid he wants to protect his JFNs, but if he's that tight-assed he can certainly make the effort to set the RESTRICT-JFN switch to T or do (SSTATUS RJFN T) or perform whatever other magic incantation is necessary.  Date: 8 March 1982 19:26-EST (Monday) From: FEINBERG at CMU-20C Subject: Restricted JFNs To: Jonl at MC CC: Bug-Maclisp at MC, Bug-Twenex at XX Howdy! Sorry, but you are inaccurate about Teco. Teco does indeed have subforking capability (the FZ command). It uses this capability to make Babyl work, and to make spelling correction possible. In almost every case of the GTJFN command, you never specify the JFN number you want, it finds a free JFN for you. I don't understand your paranoia about this issue, however I feel a compromise can be reached. Why not have a global flag which determines whether or not Maclisp should use restricted JFNs? The default can even be paranoia mode. This is very easy to implement efficiently. The only other objection I can see for this is that no one wants to write the code for it. In that case, I would be glad to implement this feature. ARYFIL is just not an acceptable solution for me, and I am willing to do something about it. I am not the only person who wants this fixed, either.  Date: 8 March 1982 10:51-EST From: Jon L White Subject: Wrong result To: JSOL at USC-ECLC cc: BUG-MACLISP at MIT-MC, Feinberg at CMU-20C Date: Friday, 5 March 1982 09:19-PST From: Jonathan Alan Solomon Subject: Terminology and resolution of "restricted JFN" problem; and functions OPENF and TNX-GTJFN Seems to me that you can do it without "restricting the JFN". If you open the file "restricted access", which uses the following bit (excerpt from INFO's JSYS node): B29(OF%RTD) Allow restricted access (i.e., allow only one process to access the file). You will get the desired results (no other process can hack the file), while at the same time, INFORMATION (ABOUT) FILE will show it. Note, this is for the OPENF jsys, not for the GTJFN jsys. The JFN is available, but the file is locked. I believe that what was desired was that the JFN be "protected" from mungeing by random subforks, but that the file access *not* be restricted. That is, it's ok for several forks/jobs to open the file for simultaneous reading; the "frozen" access, by default, prohibits more than one user at a time from gaining write/append access.  Date: 8 March 1982 10:41-EST From: Jon L White Subject: Restricted Access -- of what? To: FEINBERG at MIT-MC cc: BUG-MACLISP at MIT-MC, BUG-TWENEX at MIT-MC Date: 6 March 1982 02:46-EST (Saturday) From: FEINBERG at CMU-20C . . . It would seem to me that only files which are internal to the workings of Maclisp should be restricted, if any, and that user files should be wide open. Certainly Teco takes this approach, and it doesn't seem to lose. . . . I don't think the analogy with TECO holds -- MacLISP facilitates random user subforks, and TECO doesn't; it is these random subforks which could munge JFNs. Anyway, your original complaint was about geting a LISP handle on open files which somehow your program had "forgotten" -- the question of access to the JFN is essentially irrelevant for this.  Date: 6 March 1982 02:46-EST (Saturday) From: FEINBERG at CMU-20C To: Jon L White Cc: BUG-MACLISP at MIT-MC, BUG-TWENEX at MIT-MC Subject: Restricted Access Howdy! Randomness? I don't understand. I really have never even heard of programs accidentally munging other programs' JFNs. Doing my own JSYS calls certainly is not a clean solution. It would seem to me that only files which are internal to the workings of Maclisp should be restricted, if any, and that user files should be wide open. Certainly Teco takes this approach, and it doesn't seem to lose. It seems to me that the philosphy of Maclisp was that the user was always given plenty of rope to work with, even if he hung himself (sstatus toplevel, RPLACA, etc.). I think this should extend to file I/O.  Date: Friday, 5 March 1982 09:19-PST From: Jonathan Alan Solomon To: Jon L White Cc: BUG-MACLISP at MIT-MC, BUG-TWENEX at MIT-MC, Feinberg at CMU-20C Subject: Terminology and resolution of "restricted JFN" problem; and functions OPENF and TNX-GTJFN Seems to me that you can do it without "restricting the JFN". If you open the file "restricted access", which uses the following bit (excerpt from INFO's JSYS node): B29(OF%RTD) Allow restricted access (i.e., allow only one process to access the file). You will get the desired results (no other process can hack the file), while at the same time, INFORMATION (ABOUT) FILE will show it. Note, this is for the OPENF jsys, not for the GTJFN jsys. The JFN is available, but the file is locked. Cheers, --JSol  Date: 5 March 1982 11:20-EST From: Jon L White Subject: Terminology and resolution of "restricted JFN" problem; and functions OPENF and TNX-GTJFN To: Feinberg at CMU-20C cc: BUG-MACLISP at MIT-MC, BUG-TWENEX at MIT-MC Date: 2 March 1982 21:59-EST (Tuesday) From: FEINBERG at CMU-20C Subject: Why does @INFORMATION (ABOUT) FILES ... say "restricted JFN"? I beg to differ with you, JONL. Here is a excerpt from QIO.MID.750: . . . The line MOVSI 1,(GJ%ACC+GJ%SHT) sets the Restricted Access bit. . . . Since I offered the ARYFIL package as a way to get a "handle" on any JFN created by LISP, I assumed the complaint from EB was related to "restricted" access of files. My "denial" only applies to the file access, which @INFORMATION (ABOUT) FILE... doesn't pertain; in fact I am the one who was confused for thinking that the @INFORMATION command tells you anything at all about the file access mode, as opposed to the JFN access. But back to the point which raised this issue -- I'd be reluctant to make such a sweeping change (removing all the GJ%ACC bits) from LISP system code since it was put there in the first place to protect LISP from randomness. If an application intends to hack multiple forking (such as LEDIT does) then it will likely have the SUBFORK package loaded. SUBFORK has the function OPENF which allows you to specify both the JFN mode and file-access mode for opening files, and the function TNX-GTJFN which allows you to specify the JFN mode for random GTJFN's.  Date: 3 March 1982 16:13-EST From: Alias for KMP Sender: KMP at MIT-MC To: A2DEH at MIT-MC cc: BUG-LISP at MIT-MC Date: 21 February 1982 00:07-EST From: Donald E. Hopkins Subject: Lisp bug? To: BUG-LISP at MIT-MC There seems to be a problem in Lisp with EQ... I did the following: (setq a (readline)) ; Just hit cr || (eq '|| a) NIL ; Huh?! Readline does not return an interned symbol. Use (INTERN (READLINE)) if you want to the result of the readline to be placed on (or found on if it's already there) the obarray for comparison with other things seen by READ. (setq b (implode nil)) || (eq b '||) NIL ; *SIGH* The correct answer to this EQ is T. I cannot reproduce your NIL result. -kmp  Date: 2 March 1982 21:59-EST (Tuesday) From: FEINBERG at CMU-20C To: Jon L White Cc: BUG-MACLISP at MIT-MC Subject: Why does @INFORMATION (ABOUT) FILES ... say "restricted JFN"? Howdy! I beg to differ with you, JONL. Here is a excerpt from QIO.MID.750: ;HERE TO ALLOCATE A FRESH JFN AND OPEN THE FILE OPEN3D: PUSH FXP,TT ;SAVE THE TTSAR MOVEI T,F.DEV(TT) HRLI T,-L.F6BT PUSH FXP,(T) ;COPY THE GIVEN DEVICE NAMES ONTO THE STACK AOBJN T,.-1 PUSHJ P,6BTTLS ;CONVERT TO A NAMESTRING IN PNBUF POP FXP,TT ;GET TTSAR MOVE T,(FXP) ;RESTORE MODE BITS IN T MOVSI 1,(GJ%ACC+GJ%SHT) .SEE .GJDEF TRNE T,1 TLNE T,FBT.AP TLOA 1,(GJ%OLD) ;FOR INPUT OR APPEND, WE WANT AN EXISTING FILE TLO 1,(GJ%FOU+GJ%NEW) ;FOR OUTPUT, A NON-EXISTENT FILE MOVE 2,PNBP GTJFN ;GET A JFN The line MOVSI 1,(GJ%ACC+GJ%SHT) sets the Restricted Access bit. There are apparently many GJ%ACCs throughout QIO.MID. If there is a good reason for them to be there, that is one thing. Denying that they are there is a different story. I would proposed eliminating GJ%ACC from all GTJFN calls. This would make debugging easier.  Date: 2 March 1982 13:40-EST From: Jon L White Subject: Why does @INFORMATION (ABOUT) FILES ... say "restricted JFN"? To: Feinberg at CMU-20C cc: BUG-MACLISP at MIT-MC I actually sent out a bug note about this the other day, and apparently forgot to include you in the recipient list: Date: 28 February 1982 13:06-EST From: Jon L White Subject: Why does @INFORMATION (ABOUT) FILES ... say "restricted JFN"? To: eb at MIT-AI cc: JONL at MIT-MC, BUG-TWENEX at MIT-MC Date: 27 February 1982 17:33-EST From: Edward Barton Evidently some obnoxious password is required to run Maclisp on XX, so I can't check. But a year ago, at least, Maclisp DEFINITELY opened files with restricted JFNs. Do Information (about) files at exec level after a file has been opened for input, just to be sure. Or I would, if I had the password. 1) Foo, yes, Al Vezza doesn't want anyone ***using*** MacLISP on XX. 2) I dunno why the INFORMATION (about) FILES command calls that JFN "restricted". I've used MacLISP to open a file both ways -- "frozen" and "restricted" -- and the INFORMATION command doesn't make any distinction between the two; however, the accesses permitted are indeed correct, despite the confusing report (i.e., if "restricted", then another reader can't gain access).  Date: 1 March 1982 15:32-EST (Monday) From: FEINBERG at CMU-20C To: Jon L White Cc: BUG-MACLISP at MIT-MC, eb at MIT-ML Howdy! In fact they claim to be restricted (no other process can touch them) when I type I FILE-STATUS to the EXEC.  Date: 27 February 1982 13:28-EST From: Jon L White To: eb at MIT-ML cc: BUG-MACLISP at MIT-MC, feinberg at CMU-20C EB@MIT-ML 02/27/82 12:58:24 ARYFIL and such are all very nice, but why does it use restricted JFN's in the first place????? They aren't "restricted" -- they are "frozen" accesses. I suspect that Feinberg was confused. "Frozen" means that any number of readers can gain access, but at most one writer can have APPEND access (I don't think you can get random write access from within LISP). A file opened for ordinary write access isn't visible in the catalogue until it is closed; maybe that's what caused Feinberg to think it was "restricted". Any comments Neal? P.S.: I'm using version 2129 at MIT-XX -- I notice that CMUC still has version 2122 from last fall; hopefully this won't make a diference, but I'll send a note to Zubkoff to suggest the possibility of an update for CMUC.  EB@MIT-ML 02/27/82 12:58:24 To: JONL at MIT-MC CC: (BUG MACLISP) at MIT-ML ARYFIL and such are all very nice, but why does it use restricted JFN's in the first place?????  Date: 27 February 1982 12:17-EST From: Jon L White Subject: Closing Files To: feinberg at CMU-20C cc: BUG-MACLISP at MIT-MC Date: 23 February 1982 22:56-EST (Tuesday) From: FEINBERG at CMU-20C Under twenex, why does Maclisp use restricted JFNs when you open a file? This is very annoying when it is important to close a file, but you don't have a handle on it. . . . Either the JFNs should be unrestricted, or there should be a lisp functions which closes all files, or you should at least be able to specify UNRESTRICTED as a file mode to OPEN. If a file-object is GC'd, then the GC will close it; but if you simply forgot how to access it (e.g., you SETQ'd it to some variable whose name you've forgotten, or put it in some list somewhere), then you can load in the ARYFIL package and call (OPEN-FILES), which will return a list of all currently-open file objects except (STATUS TTYIFA) and (STATUS TTYOFA) which aren't GC'able. Source for this package contains some documentation of additional facilities; it is on the CMU-20C machine as ARYFIL.LSP.  Date: 26 February 1982 16:08-EST (Friday) From: FEINBERG at CMU-20C To: Bug-Maclisp at MC Subject: DSK: Howdy! What is the status of fixing the the bug where someone redefines DSK: to a list of things, and then Maclisp breaks? Another user has just been screwed by this.  Date: 23 February 1982 23:25-EST From: George J. Carrette Subject: Closing Files. To: FEINBERG at CMU-20C cc: BUG-MACLISP at MIT-MC For your information: File objects get closed when they are sweeped by the garbage collector.  Date: 23 February 1982 22:56-EST (Tuesday) From: FEINBERG at CMU-20C To: Bug-Maclisp at MC Subject: Closing Files Howdy! Under twenex, why does Maclisp use restricted JFNs when you open a file? This is very annoying when it is important to close a file, but you don't have a handle on it. Yes I know about IOTA, but sometimes you don't plan ahead, and sometimes you are using someone elses code. Either the JFNs should be unrestricted, or there should be a lisp functions which closes all files, or you should at least be able to specify UNRESTRICTED as a file mode to OPEN.  Date: Sunday, 21 February 1982, 06:47-EST From: Robert W. Kerns Subject: Lisp bug? To: BUG-LISP at MIT-MC In-reply-to: The message of 21 Feb 82 00:07-EST from Donald E. Hopkins I replied to A2DEH about EQ and READLINE.  Date: 21 February 1982 00:07-EST From: Donald E. Hopkins Subject: Lisp bug? To: BUG-LISP at MIT-MC There seems to be a problem in Lisp with EQ... I did the following: (setq a (readline)) ; Just hit cr || (eq '|| a) NIL ; Huh?! (setq b (implode nil)) ; NIL was what a function to read || ; text until you type a Ctrl-C ; outputted if you just hit Ctrl-C ; (It would output a list of the ; ASCII values of the characters ; typed.) (eq b '||) NIL ; *SIGH* (eq a b) NIL ; Lose! What's going on? -Don  Date: 19 February 1982 13:44-EST From: Jon L White Subject: VALRET, and use of .LOGOUT To: GJS at MIT-MC cc: BUG-MACLISP at MIT-MC Date: 10 February 1982 01:13-EST From: Gerald Jay Sussman To: BUG-MACLISP at MIT-MC Load up a valuable LISP and type (valret). The symptom was that the job was killed -- possibly the semantics of .LOGOUT changed between the initial implementation of VALRET and now, but in any case, I've fixed it so that (VALRET) is equivalent to (VALRET '|:VK |).  Date: 17 February 1982 20:13-EST From: Jon L White Subject: SHARPM To: ALAN at MIT-MC, GSB at MIT-MC cc: BUG-LISP at MIT-MC The additions to SHARPM which I mentiond about a month or so ago are now installed in version 82 -- 1) #nRddd format now works 2) #|...cruft...|# format now works, as per ALAN's request 3) the actual format of the /#-MACRO-DATALIST has been changed -- be advised if you ever depended upon it. This change is only on MC right now, but I'll :INSTALL it "soon". If anyone needs to back out of it, you should move LISP;SHARPM OFASL into LISP;SHARPM FASL. NOTE WELL: this change must correspondingly be coordinated with the installation of EXTEND (from version 291 to 292), BITS (from version 45 to 46), and VECTOR (from version 73 to 74) -- thus an un-doing of SHARPM must also install LISP;* OFASL into LISP;* FASL for these three files (for efficiency reasons, they depend upon the format of that list).  Date: 16 February 1982 19:18-EST From: Jon L White Subject: Recognizing AUTOLOADing macros To: DEVON at MIT-MC, CSTACY at MIT-MC cc: BUG-LISP at MIT-MC, BUG-COMPLR at MIT-MC The following deficiency in COMPLR is now corrected: Date: 9 February 1982 23:10-EST From: Christopher C. Stacy DEVON@MIT-MC (Sent by DEVON0@MIT-MC) 02/04/82 01:14:37 Isn't it reasonable for compiled and interpreted code to have the same environment? I tried (eval-when (compile) (load "guest5;devon lisp")) which puts autoload properties on many of my commonly used macros, etc, but the compiler ignores that, and I've been reduced to keeping two copies of everything, one for the compiler and one for the interpreter since I don't know how to make the compiler recognise synonyms and do autoloads! And I keep having to fix the smae bugs twice!!! Help!!! Actually, some parts of the COMPLR did already "recognize" these autoload properties (e.g., top-level forms), but there was a deficiency in the way that "code" was being macroexpanded which caused it to ignore autoloadable macros unless they had a FUNTYP-INFO property. I've changed this so that it will try autoloading unless the function is already FBOUNDP. I've tried this out with your macros on a little test file: (eval-when (compile) (load "guest5;devon lisp")) (defun foo (x) (iff (eq x 'FOO) 5)) and it wins now. Unfortunately, the net to AI was down, so the patch is only on MC and ML as of now. By the bye, DEVON, did you know that there is a function ARRAYP in the file MLSUB (for MacLisp SUBroutines)? It checks to be sure that the array isn't one of the "funny" kind, like READTABLE, FILE, SFA, or whatever; these "funny" kinds are of typep ARRAY, but are of differing array-type. This function may be documented soon.  Date: 10 February 1982 11:29-EST From: George J. Carrette Subject: Autoloading macros. To: DEVON at MIT-MC cc: BUG-LISP at MIT-MC In order to have autoloading macros in the compiler you have to do [1] (DEFPROP FOO "FOO;BAR" AUTOLOAD) [2] (DEFPROP FOO AUTOLOAD-MACRO MACRO) where: (DEFUN AUTOLOAD-MACRO (FORM) (REMPROP (CAR FORM) 'MACRO) (LOAD (GET (CAR FORM) 'AUTOLOAD)) (OR (GET (CAR FORM) 'MACRO) (ERROR "Macro not autoloaded" (CAR FORM))) FORM)  Date: 10 February 1982 01:13-EST From: Gerald Jay Sussman To: BUG-MACLISP at MIT-MC Load up a valuable LISP and type (valret).  Date: 9 February 1982 23:10-EST From: Christopher C. Stacy Subject: [DEVON at MIT-MC: Forwarded] To: BUG-LISP at MIT-AI DEVON@MIT-MC (Sent by DEVON0@MIT-MC) 02/04/82 01:14:37 To: CSTACY at MIT-MC CC: DEVON at MIT-MC Isn't it reasonable for compiled and interpreted code to have the same environment? I tried (eval-when (compile) (load "guest5;devon lisp")) which puts autoload properties on many of my commonly used macros, etc, but the compiler ignores that, and I've been reduced to keeping two copies of everything, one for the compiler and one for the interpreter since I don't know how to make the compiler recognise synonyms and do autoloads! And I keep having to fix the smae bugs twice!!! Help!!!  Date: 6 February 1982 14:51-EST From: Kent M. Pitman Subject: LSP vs LISP To: KWC at MIT-MC cc: BUG-LISPM at MIT-MC, BUG-LISP at MIT-MC It is easy to make Emacs understand that .LISP files default the major mode to LISP. Creating a macro called & LISP Mode which just re-calls LISP Mode will do it. This can be done in an init file in a cheatish way by: m.mLISP Modefo..QMM & LISP Modem.vMM & LISP Mode Also, I have an Emacs library that will generate tags files for most major languages, so making Emacs tags files shouldn't be a consideration. The library is called TAGGEN and exists at least on the ITS's if it is not distributed outward by now... So the Emacs end of your recent note about LSP vs LISP is probably not a real problem. -kmp  Date: 6 Feb 1982 1359-EST From: Kenneth W. Church Subject: lisp vs. lsp To: bug-lisp at MIT-ML, bug-lispm at MIT-ML, kwc at MIT-ML this is a real problem that needs to be resolved once and for all. all lispm software assumes that lisp files are of type "lisp" and all maclisp code (except lsb) assume "lsp". I would like my code to run both places. Major screws: tags will not run on "lisp" files fs:copy-file will give "lisp" as the type of a file that it thinks is lisp code complr and (qc-file ...) don't agree symbolics and mit 20's don:t agree can we come to some compromise and stick with it. - ken -------  Date: 3 February 1982 00:00-EST From: Glenn S. Burke Subject: who is EPSS To: BUG-LISP at MIT-MC such that i get bitched at by the mailer? I commented it out of the BUG-LISP mailing list.  Date: 2 February 1982 23:58-EST From: Glenn S. Burke To: WGD at MIT-MC cc: BUG-LOOP at MIT-MC, BUG-MACLISP at MIT-MC Date: 2 February 1982 10:03-EST From: William G. Dubuque Sender: BIL at MIT-MC (loop for (ignore x) in pairs ...) doesn't ignore; however using () instead of ignore works. Is this the defined behavior for loop? Yes. [I realize that the ignore conventions aren't standardized across Lisps; perhaps the MacLisp compiler could be made to recognize ignore also.] It does. The problem here is that IGNORE is only specially recognized when used in a variable-binding position. As i remember it, it isn't recognized in such things as (multiple-value (ignore foo) ...) (i'm talking lispm here--maybe this has been "fixed" but i don't think so). What you are saying is that (SETQ IGNORE (CAR L)) should do something special, like not bother. (I could say something nasty like "it's bad enough that the symbols T and NIL are treated specially, you want IGNORE to be also?", but i won't.)  Date: 2 February 1982 10:03-EST From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-LOOP at MIT-MC cc: BUG-MACLISP at MIT-MC (loop for (ignore x) in pairs ...) doesn't ignore; however using () instead of ignore works. Is this the defined behavior for loop? [I realize that the ignore conventions aren't standardized across Lisps; perhaps the MacLisp compiler could be made to recognize ignore also.]  Date: 23 January 1982 10:16-EST From: Jon L White Subject: SETF on LDB constructs To: DCP at MIT-MC cc: RWK at MIT-MC, BUG-LISP at MIT-MC Date: 16 January 1982 13:35-EST From: David C. Plummer I BUGged this last year, and I just got screwed by it again: (macroexpand '(setf (ldb 0410 (arraycall fixnum foo 0)) (length bar))) ==> ((LAMBDA (|T..120| |T..121|) (SETQ |T..120| (DPB |T..121| 410 |T..120|)) |T..121|) (ARRAYCALL FIXNUM FOO 0) (LENGTH BAR)) It appears that if the new value involves a computation, setf gets quite confused. The SETF inversion process is a murky one, especially for the 'composed' operators like ARRAYCALL, PROGN, and LDB; RWK knows the most about this code, and should probably look into it (he has promised, again!, to do so.)  Date: 22 January 1982 03:00-EST From: Jon L White Sender: RPG at MIT-MC Subject: LEXPR-FUNCALL, and VECTORP To: WGD at MIT-MC cc: BUG-LISP at MIT-MC I merely re-compiled the new source for the VECTOR package, and the problem (i.e., SI:CLASS-TYPEP not having been macroexpanded) went away -- could it have been some transient when the fle was compiled last week?  Date: 18 January 1982 22:21-EST From: George J. Carrette Subject: To DEFSTRUCT users. To: BUG-LISPM at MIT-AI, BUG-LISP at MIT-AI Do any defstruct users have a "defstruct-define-type" which is good for extracting and depositing fixnums from various fields of a BIT-STRING (say represented as an ART-1B array on the LISPM, or a BIGNUM on the PDP-10).  Date: 18 January 1982 01:00-EST From: Robert W. Kerns Subject: DEFSETF To: DCP at MIT-MC cc: BUG-LISP at MIT-MC DEFSETF is not autloaded. I don't knowif it ever as autoloaded. (LOAD '((LISP)DEFSETF)) will get it.  Date: 18 January 1982 01:00-EST From: Robert W. Kerns Subject: DEFSETF To: DCP at MIT-MC cc: BUG-LISP at MIT-MC DEFSETF is not autloaded. I don't knowif it ever as autoloaded. (LOAD '((LISP)DEFSETF)) will get it.  Date: 17 January 1982 10:15-EST From: David C. Plummer To: BUG-LISP at MIT-MC from LSPMAI;LISP NEWS: Sunday December 9,1979 FM+5D.18H.52M.12S. LISP 1914/COMPLR 904 - JONL, RWK - 5) SETF is an FSUBR like the LISPM's general update operator DEFSETF is an autoloadable macro to help one extend the SETF range. I know that SETF is now a macro, but DEFSETF seems to have disappeared, and there is no mention of it disappearing in LISP RECENT. Where is it? If it is gone, how about making (SETF (EXAMINE LOCATION) NEW-VALUE) ==> (PROGN (DEPOSIT LOCATION NEW-VALUE) NEW-VALUE)  Date: 17 January 1982 05:43-EST From: Kent M. Pitman To: MARTY at MIT-MC cc: BUG-LISP at MIT-MC The version of LEDIT that Lisp uses has not changed since Feb 27, 1981. I installed a fresh version on AI in case there had been some bit damage to the FASL, which is highly unlikely. More likely you are not doing things the same on the two machines. If you are (double check, please), then it is almost certainly an Emacs lossage, not a Maclisp lossage, and should be reported to BUG-EMACS. -kmp  Date: 17 January 1982 05:32-EST From: Martin David Connor To: BUG-LISP at MIT-AI The LEDIT program on MC works as I would expect. (this relates to the previous message)  Date: 17 January 1982 05:31-EST From: Martin David Connor To: BUG-LISP at MIT-AI Is there something wrong with LEDIT on AI? I just was editing a short function, and when I did the M-Z followed by a C-X Z, it did not read the buffer into lisp, and the function remained undefined.  Date: 16 January 1982 14:32-EST From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-LISP at MIT-MC The VECTOR package seems to break LEXPR-FUNCALL, e.g. (load '((lisp)vector)) (lexpr-funcall 'list ()) => ;SI:CLASS-TYPEP UNDEFINED FUNCTION IN UUO CALL  Date: 16 January 1982 13:35-EST From: David C. Plummer Subject: Will this ever get fixed? To: BUG-LISP at MIT-MC I BUGged this last year, and I just got screwed by it again: (macroexpand '(setf (ldb 0410 (arraycall fixnum foo 0)) (length bar))) ==> ((LAMBDA (|T..120| |T..121|) (SETQ |T..120| (DPB |T..121| 410 |T..120|)) |T..121|) (ARRAYCALL FIXNUM FOO 0) (LENGTH BAR)) It appears that if the new value involves a computation, setf gets quite confused.  ALAN@MIT-ML 01/15/82 23:50:56 Re: #| ... |# To: (BUG LISP) at MIT-ML A while back the LispMachine adopted #| as the way to begin a balanced comment. (This idea was discussed on lisp-forum about a year and a half ago.) The way this works is that the two character sequence "#|" begins a comment that can only be ended by a matching "|#". An important feature is that nesting "#| ... |#" pairs within such a comment "work". In other words, the #| macro must count containing "#|"s and "|#"s to be certain it is finished. (This is the opposite of the way the PL/1 /* ... */ comment works, but the Multics PL/1 community tells me that this is a loss and that they would rather it work the #| way.) I bring this up now, because I just now screwed myself by forgetting that PDP10 MacLisp doesn't have it. If you are interested in introducing this bit of compatability into PDP10 MacLisp, please take a look at the algorithm the LispMachine uses to parse the stuff in the comment (AI:LMIO;READ the function xr-/#/|-macro) so that we both parse them the same way. (I'll gladly consider any improvements you might suggest.)  Date: 14 January 1982 22:39-EST From: Kent M. Pitman Sender: VP at MIT-MC To: GSB at MIT-ML cc: BUG-LISP at MIT-MC Format with a ~[... ~'A,'Z,'a,'z:; ...~] as described on page 309 of the blue lispm manual does not win. It catches #/a fine, but #/d falls through to the 'other' clause.  GSB@MIT-ML 01/08/82 15:55:42 Re: well feeping features To: (BUG LISP) at MIT-ML cursorpos seems to decide to be a no-op when its last arg is NIL. This broke the no-file-arg case of (cursorpos nil), which worked sometime in the past.  Date: 4 January 1982 03:27-EST From: Devon S. McCullough Sender: DEVON7 at MIT-MC To: BUG-LISP at MIT-MC this is REALLY picky, but if FORMAT has a "HAVE"/"HAS" pluralizer, the compiler should use it in message "have been used but remain undef..."  Date: 4 January 1982 01:56-EST From: Devon S. McCullough Sender: DEVON7 at MIT-MC To: BUG-LISP at MIT-MC I've got a bug that just can't be reproduced in the interpreter, it may be timing-related but I don't think it's a compiler bug, just something that only happens at the faster execution speed of compiled code. At some random time I get a MPV error at 44333 and if I G then another MPV error at 11346 occurs. In an effort to track this down, I aborted the program before it bombed, using the (^G) function, not ^G which was disabled while the program runs. Then I typed (subr 44333) and I got a MPV at 10033>>hlrz 4,(17). So I ran a new LISP and did (subr 44222) and it replied GC, and then did (subr 11346) and it came back with READ-EVAL-*-PRINT, no problem. Thus my bug seems to be freaking the GC somehow. It turns out there are no RPLACAs or RPLACDs anywhere in my code, so they aren't responsible for trashing random memory locations, are there any alternative causes?  Date: 3 January 1982 01:29-EST From: Alan Bawden Subject: You two recent bug reports To: DEVON at MIT-MC cc: BUG-LISP at MIT-MC Well you don't give a very clear picture of the symptoms of the bug are suffering from, but here is some advice that might help you out: 1) When a macro (such as your TTYVAR macro) calls a function (such as your SIXBIT function) as MACRO EXPAND TIME it should be enclosed within an (EVAL-WHEN (... COMPILE ...) ...). When the compiler compiles an ordinary top-level DEFUN form is just compiles it, it doesn't arrange to define it in the compile-time lisp world unless you ask it to. Since the body of a macro is evaluated at compile-time, you must take care to define any functions called there. 2) I notice that you do (car (syscall ...)) a fair amount. This is probably not the source of your MPVs (taking the car and cdr of small fixnums being relatively safe), but if you are in the habit of taking car and cdr of other things that are likely to not be conses, then you are living dangerously.  Date: 3 January 1982 01:06-EST From: Devon S. McCullough Sender: DEVON0 at MIT-MC To: DCP at MIT-MC cc: BUG-LISP at MIT-MC Well, it's like this: (defun foo (zot) (mumble zot)) (defmacro bar (baz) `( ... ,(foo baz) ...)) ; It must be something I'm doing ; elsewhere in the file. The symptom has now changed! Instead of deciding FOO is undefined, it runs FOO on BAZ instead of the value of BAZ from the invocation of the macro! The actual code in question is the function SIXBIT and the macro TTYVAR in the file MC:GUEST5;DEVON LBUG which feel free to examine, and delete. The EXACT SAME CODE runs fine when placed in a file all by itself, if you could see what I'm breaking in the LBUG file, I'd appreciate it. I solved the problem by making SIXBIT a macro, but I sure am baffled! I almost think it's the complr not me.  Date: 2 January 1982 23:28-EST From: Devon S. McCullough To: BUG-LISP at MIT-MC My program keeps dying with MPV's, is there any possible explanation, cure, or way to find out just what it was doing before it bombed? alt-P and alt-G just give more MPV's, I'm baffled. Seems run-time related.  Date: 2 January 1982 11:04-EST From: David C. Plummer To: DEVON at MIT-MC cc: BUG-LISP at MIT-MC Date: 2 January 1982 00:57-EST From: Devon S. McCullough How come if I do (defun foo ...) (defmacro bar ... (foo) ...) the compiler thinks foo is undefined fn obj??? the unfasl shows foo did ok before it shows bar losing. Is (foo) part of the expansion process, or is it part of the form returned? E.g. (defmacro bar (baz) (foo baz)) will lose because foo is not in the compile-time environment, but (defmacro bar (baz) `(foo ,baz)) should win.  Date: 2 January 1982 00:57-EST From: Devon S. McCullough To: BUG-LISP at MIT-MC How come if I do (defun foo ...) (defmacro bar ... (foo) ...) the compiler thinks foo is undefined fn obj??? the unfasl shows foo did ok before it shows bar losing.  Date: 28 December 1981 21:01-EST From: Alan Bawden To: MACRAK at MIT-MC cc: BUG-BINPRT at MIT-MC, BUG-LISP at MIT-MC MACRAK@MIT-MC 12/28/81 13:47:05 :Binprt sys;ts macsym and :binprt sys2;ts emacs report Checksum errors. Is that really true? Or does that mean something else? As I understand the checksum algorithm it is really true. In fact I believe that I once determined that whenever a lisp is dumped the indirect symbol table block at the end of the file is given a bogus checksum. I never bothered to report this to bug-lisp (until now) because it seemed more reasonable to fix binprt to simply report the error (rather than crapping out, as it used to do). I suppose the emacs dumper has the same problem. Date: 28 December 1981 14:18-EST From: Stavros M. Macrakis Subject: Binprt To: BUG-BINPRT at MIT-MC Kindly verify :info binprt. Seems correct to me.  RSG@MIT-ML 12/28/81 10:03:48 To: (BUG LISP) at MIT-ML CC: RSG at MIT-ML On AI today, in a totally fresh lisp (didn't run my init file), I typed (ALLFILES '(((DSK RSG) * RSG))) and it returned NIL. (I have several files on my directory AI:RSG; which meet those specs.) -- rsg  Date: 26 December 1981 17:09-EST From: Jon L White Subject: EVAL-WHEN To: BUG-LISP at MIT-MC cc: BUG-LISPM at MIT-MC Compiler and interpreter should barf if some unrecognized keyword appears. For example, (EVAL-WHEN (EVAL-COMPILE) (DEFMACRO ...) ) should give a complaint rather than leaving ... undefined.  Date: 24 December 1981 21:23-EST From: Devon S. McCullough To: BUG-MACLISP at MIT-MC DUMPARRAYS rejects atoms with array values, apparently insists on an array property.  Date: 22 December 1981 03:48-EST From: Richard L. Bryan Subject: SUBLIS To: BUG-LISP at MIT-MC SUBLIS appears to descend the hunks of EXTENDs. Try (load '|MC:RLB;TRUTH|) (sublis '((a . b)) #T) to see unrecoverable regpdl overflow.  Date: 21 December 1981 02:35-EST From: Kent M. Pitman Sender: ___012 at MIT-MC To: RSG at MIT-MC cc: BUG-LISP at MIT-MC the error may be caused by trying to do too many accesses to the archive device to fast. archive devices on its are slow and are often found locked when one wishes they could be opened. this is more likely to happen on a fast system than a slow one, since it allows sequential pieces of code that does this accessing to be reached more quickly. it may not be easily fixable since the problem is not one in maclisp at all and really shouldn't happen in the first place... ITS archives are a crock to be avoided wherever possible.  RSG@MIT-ML 12/20/81 18:25:44 To: (BUG LISP) at MIT-ML CC: RSG at MIT-ML Often when running the function DIRECTORY on an archive I get the following error: MACHINE-ERROR reference to non-existent memory at address 43411 in function MAPDIRECTORY. The args to the MACHINE-ERROR interrupt are (EXAMINE 0. 43411. 0.) . This seems to happen randomly, with higher probability of happening when the system load is light (ie, when it is running fairly fast). I have an init file that calls DIRECTORY on all my archives in sequence in order to set up a list-structure directory of my files when I invoke lisp. This is where the error happens. If I call the same code manually (typing in the calls to DIRECTORY for each archive) the error never happens. The code which invokes the error-prone calls is near the end of the function INITIALIZE-LISP which is the last function in the file ML: RSG; BASE > . The file BASE FASL is loaded (and INITIALIZE-LISP called) by ML: RSG; RSG LISP . The lisp is totally fresh (other than BASE FASL being loaded and INITIALIZE-LISP being called) when this strange behavior happens. -- rsg  Date: 17 December 1981 13:49-EST From: Jon L White Subject: Lisp 2022 on a Tops-10 To: JGA at MIT-MC cc: BUG-LISP at MIT-MC Date: 17 December 1981 12:12-EST From: John G. Aspinall Subject: Lisp 2022 on a Tops-10 I'm trying to use MacLisp on LLL-MFE. It runs Tops-10, and the lispversion is 2022. The folks at LLL are not supporting it, but it was installed and (I think) running once. Certain things work, but it appears that something is broken. Two examples are: . . . Yes, I believe that Jonathan Letvin installed some version of MacLISP at LLL; not only is 2022 quite out of date (current version at XX is 2122, and there is a LISP.REL file there for TOPS-10 systems), but a lot of other things are probably dated too. One easy quick fix is just to copy the MacLISP directory from CMUA, which is a little out of date, but at least somewhat consistent; another is to get a tape made at XX at send it to LLL.  Date: 17 December 1981 12:12-EST From: John G. Aspinall Subject: Lisp 2022 on a Tops-10 To: BUG-LISP at MIT-MC cc: JGA at MIT-MC [I'm not sure this is where this inquiry should go, but please redirect if necessary.] I'm trying to use MacLisp on LLL-MFE. It runs Tops-10, and the lispversion is 2022. The folks at LLL are not supporting it, but it was installed and (I think) running once. Certain things work, but it appears that something is broken. Two examples are: 1. Invoking IF DEFMAX 77 loads MLMAC 35 loads then it bombs out with an illegal UUO. 2. Invoking LET LET 90 loads DEFMAX 77 loads then it bombs out with an illegal UUO. Can you tell me how to diagnose its problems, and/or what to look for? For instance the current MLMAC on MC is 92, is 35 so out of date that it is incompatible? Thanks for any help, John.  Date: 12 December 1981 03:19-EST From: Alan Bawden To: BUG-LISP at MIT-MC This a bug in the GRIND/SPRINTer: b (LAMBDA (RETURN-17) (CLOSED) ((LAMBDA (X) (ENV RETURN-17) (SETQ X (LAMBDA (C-20 Y) (CLOSED X) (SETQ X (LAMBDA (C-21) (CLOSED Y) (C-21 Y)) C-20)) RETURN-17)) (QUOTE 1))) (sprinter b) (LAMBDA (RETURN-17) (CLOSED) ((LAMBDA (X) (ENV RETURN-17) ( ;(RETURN-17) SETQ-PREDICT ;BKPT WRNG-NO-ARGS Now, I will admit that that happens to look like a three "argument" SETQ, but I don't think that just because I happen to have some list structure that LOOKS like code (but isn't) I should be treated this way. That isn't a very comprehensible error message, and just why does it claim to be a WRNG-NO-ARGS error? (It's not actually going to let me return something to continue with is it?)  Date: Friday, 11 December 1981 01:02 est From: Margolin.PDO at MIT-Multics To: Richard Kawala cc: INFO-LISP at MIT-AI bcc: INFO-LISP at MIT-AI In-Reply-To: Message of 10 December 1981 22:37 est from Richard Kawala On the market, a very popular book is Winston and Horn's "LISP". The Student Information Processing Board at MIT also publishes "Notes on the Programming Language LISP", by Bernie Greenberg, which is used as the course notes for the SIPB's Radical Introduction to LISP course. For this, send a request and $2.50 (if a check, make it out to "SIPB") to: SIPB rm 39-200 77 Massachussetts Ave. Cambridge, MA 02139  Date: 11 December 1981 00:14-EST From: Alan Bawden To: KAWALA at MIT-AI cc: BUG-LISP at MIT-MC Date: 10 December 1981 22:37-EST From: Richard Kawala Can anyone out there recommend a book that will teach LISP? Please reply direct to me as I am not on this mailing list. Thanks. "Notes on the Programming Language Lisp" by Bernie Greenberg is an excellent introduction to Lisp. Copies can be obtained by sending $3.50 ($2.50 to cover duplication costs and $1.00 to cover postage and handling) to: Student Information Processing Board MIT Room 39-200 Cambridge Mass 02139 In the future, please direct your queries to the BUG-LISP mailing list so as not to bother so many people. The people on INFO-LISP are not on it to answer questions, but rather to receive updates about recent Lisp developments.  Date: 10 December 1981 22:37-EST From: Richard Kawala To: INFO-LISP at MIT-AI Can anyone out there recommend a book that will teach LISP? Please reply direct to me as I am not on this mailing list. Thanks.  GSB@MIT-ML 12/09/81 17:22:39 To: (BUG LISP) at MIT-ML EVAPH restores A and T in the wrong order. Personally, i still think that a non-null value of EVAL should be used in preference to the user-hunk application that is going on there, since the latter is making assumptions as to how the arguments should be evaluated (with the result that if the user-hunk does not support functional-application, the arguments get evaluated BEFORE that gets detected -- not very nice considering that such an error is usually the result of a typo). Of course none of this can be detected because EVAPH is broken.  Date: 9 December 1981 17:19-EST From: Jon L White To: glr at MIT-AI cc: BUG-LISP at MIT-MC Date: 9 December 1981 15:52-EST From: Jerry Roylance COMPLR does not compile the do loop correctly (defun bug () (do ((i 0 j) (j 1 (1+ j))) ((> j 10)) (print (list i j)))) The bug is caused by the clause "(i 0 j)", which involves parallel assignments -- you can completely get around this problem for now by declareing 'j' to be fixnum (you might as well declare 'i' too).  Date: 9 December 1981 15:52-EST From: Jerry Roylance To: BUG-LISP at MIT-AI cc: GLR at MIT-AI COMPLR does not compile the do loop correctly (defun bug () (do ((i 0 j) (j 1 (1+ j))) ((> j 10)) (print (list i j))))  Date: 8 December 1981 16:49-EST From: Jon L White Subject: Fixing weird COMPLR bug fixes SI:INVALIDATED loss too? To: ALAN at MIT-MC, WGD at MIT-MC, eb at MIT-ML cc: BUG-MACLISP at MIT-MC, BUG-COMPLR at MIT-MC Date: 20 November 1981 00:13-EST From: Alan Bawden I reported a bug several months back and left a test case in ALAN;LOSS >. . . (This is the (foo x ) bug again, remember?) This bug is now fixed in COMPLR 1130. It resulted from a bad interaction between "optimizing" COND compilations and PROGN compilations, and only occured in quite contorted situations. This problem is probalby responsible for the lossage noted by WGD and EB previously when some displaced macro got munged; since the munging was not due to any bug in DEFMAX, it would have to be some bug like this one (or, horrors, a GC bug). Probaly EB and WGD should recompile their macro files, and report any future SI:INVALIDATED comments to bug-complr too. (The SI:INVALIDATED note ocurs when displaced macro call gets randomly RPLAC'd, which could certainly happen when "foo" in alan's example is the call to DISPLACE for macro displacement).  Date: 7 December 1981 14:45-EST From: Jon L White Subject: MacLISP/EMACS interface To: devon at MIT-ML cc: BUG-EMACS at MIT-MC, BUG-MACLISP at MIT-MC DEVON@MIT-ML 12/06/81 18:06:42 is there a package that allows you to switch from ITS MacLisp to Emacs by typing ^E, and from Emacs back to Lisp by typing ^Z, in such a way that MacLisp will read in the Emacs buffer? Many of us use the LISPT package -- you can just load it in like (LOAD "LISP;LISPT FASL") or let it be autoloaded if you simply do (LISPT). You can also do (SSTATUS TTYINT #^E 'LISPT-EDIT-INTERRUPT) to get an interrupt character set up for quick entry into the editor. Once you get the editor started, you can use the APROPOS command to see commands etc which have the substring LISPT in them.  DEVON@MIT-ML 12/06/81 18:06:42 To: (BUG EMACS) at MIT-ML CC: (BUG MACLISP) at MIT-ML is there a package that allows you to switch from ITS MacLisp to Emacs by typing ^E, and from Emacs back to Lisp by typing ^Z, in such a way that MacLisp will read in the Emacs buffer?  Date: 4 December 1981 13:38-EST From: Jon L White Subject: &WHOLE for DEFMACRO To: MOON at MIT-MC cc: KMP at MIT-MC, BUG-LISPM at MIT-MC, BUG-MACLISP at MIT-MC This idea, &WHOLE, was discussed through the mails early in 1979, and someone (I believe RMS?) suggested another keyword for the same idea to be used in the LISPM defmacro. It's appearance in MacLISP/NIL was noted in the following from LISP;LISP NEWS Sunday December 9,1979 FM+5D.18H.52M.12S. LISP 1914/COMPLR 904 - JONL, RWK - ... 12) Some things that failed to be documented previously about DEFUN/DEFUN& &WHOLE - DEFMACRO now permits a keyword &WHOLE, to get at whole call form by specifying a variable to be bound to the whole call form. (DEFMACRO FOOM (&WHOLE X) ) would bind X just like (MACRO FOOM (X) ) Typically, one would use &WHOLE when several symbols are set to the same macro code body, or when one wants a pointer ot the cell invoking the call; e.g., the following two macros FOO and FOOQ are essentially the same except for the action in the lines indicated by ;**** : (defmacro FOO (x y &optional (z 1) &whole form) (do () ((fixp z)) (setq form (error "Count arg unreasonable for OPERATEing" form 'FAIL-ACT))) (let ((arglist `(,x ,y))) (if (eq (car form) 'FOOQ) ;**** (setq arglist (mapcar #'(lambda (a) `(QUOTE ,a))))) ;**** `(OPERATE ,@arglist ,z))) (fsetq FOOQ (fsymeval 'FOO))  Date: 3 December 1981 11:46-EST From: George J. Carrette Subject: DEFMACRO and &WHOLE and &lossage. To: Moon at MIT-AI cc: BUG-LISPM at MIT-MC, BUG-MACLISP at MIT-MC, KMP at MIT-MC &WHOLE isn't supported in VAX-NIL's Defmacro either, it would just be a special case to check for it, if it were useful though ... As far as "&..." words in general go, to make sure that people don't get screwed, for example by using something that may be a good keyword in the future, the system gobbles all "&..." words in effect by having a pname check for them in the LAMBDA-binding section of the compiler, and interpreter. This check doesn't cost very much and covers all possible lossage of this class in a central location. I'd recommend it for the Lispm too.  Moon@MIT-AI 12/03/81 04:31:49 Re: DEFMACRO and &WHOLE To: KMP at MIT-MC CC: (BUG LISPM) at MIT-MC, (BUG MACLISP) at MIT-MC Date: 30 November 1981 17:20-EST From: Kent M. Pitman Subject: &keyword lossage To: BUG-LISPM at MIT-MC cc: BUG-MACLISP at MIT-MC On the LispM, &WHOLE is not a keyword to DEFMACRO. In Maclisp/NIL it is. What's this for? I can't think of anything that isn't a bad idea that it could be for. Since DEFMACRO is itself a macro, it could check for symbols starting with &'s which are not keywords and warn the user. The effects of mis-spelling a keyword or assuming that one is one when it is not can be quite confusing. This should be done.  GSB@MIT-ML 12/02/81 17:11:45 To: (BUG LISP) at MIT-ML (quit 340000) very carefully looks, finds that its arg is a fixnum, and then immediately does a .LOGOUT 1, followed by various perverted contortions designed to kill the lisp in spite of any intentions. (340000 indeed would kill the lisp if used as the e.a. to a .break 16,).  Date: 2 December 1981 17:06-EST From: Jon L White Subject: Error msg for "illegal-return-value-from-splicing-macro" To: GSB at MIT-MC cc: BUG-LISP at MIT-MC GSB@MIT-ML 12/01/81 20:26:26 To: (BUG LISP) at MIT-ML the illegal-return-value-from-splicing-macro should have the consideration to show the illegal return value. It does now -- I just patched the relevant LERR into an LER3, since the 'illegal value' had been left in acc A. Have also edited souces.  Date: 2 December 1981 16:59-EST From: Jon L White Subject: Error on bad value for READTABLE To: GSB at MIT-MC cc: BUG-LISP at MIT-MC GSB@MIT-ML 12/01/81 20:30:24 To: (BUG LISP) at MIT-ML GTRDT9 does a %FAC BDGLBV which is hardly informative, considering that BDGLBV addresses a subroutine, not a sixbit error message. GTRDT8 should have PUSHJ'd to BDGLBV -- GTRDT9 is obsolete. I've patched the current LISP (version 2122) and edited the sources.  Date: 2 December 1981 16:57-EST From: Jon L White To: PONDY at MIT-AI cc: MOON at MIT-MC, BUG-LISP at MIT-MC Date: 2 December 1981 14:23-EST From: David A. Moon Date: 1 December 1981 20:52-EST From: Peter Andreae why are there so many versions of purqio on sys; - dsk space is very full. All of the PURQIO files on AI:SYS; have relatively recent reference dates, to some dumped-out system (built up over MacLISP) is sharing pages with them. I keep an eye on these things from time to time, and try to encourage 'owners' of old dumps to either delete them, or re-dump them in a current lisp.  Date: 2 December 1981 14:23-EST From: David A. Moon To: BUG-LISP at MIT-MC Date: 1 December 1981 20:52-EST From: Peter Andreae To: BUG-PURQIO at MIT-AI why are there so many versions of purqio on sys; - dsk space is very full.  GSB@MIT-ML 12/01/81 20:30:24 To: (BUG LISP) at MIT-ML GTRDT9 does a %FAC BDGLBV which is hardly informative, considering that BDGLBV addresses a subroutine, not a sixbit error message.  GSB@MIT-ML 12/01/81 20:26:26 To: (BUG LISP) at MIT-ML the illegal-return-value-from-splicing-macro should have the consideration to show the illegal return value.  Date: 30 November 1981 17:20-EST From: Kent M. Pitman Subject: &keyword lossage To: BUG-LISPM at MIT-MC cc: BUG-MACLISP at MIT-MC On the LispM, &WHOLE is not a keyword to DEFMACRO. In Maclisp/NIL it is. Since DEFMACRO is itself a macro, it could check for symbols starting with &'s which are not keywords and warn the user. The effects of mis-spelling a keyword or assuming that one is one when it is not can be quite confusing.  Date: 30 Nov 1981 1357-PST From: J. Q. Johnson Subject: re: bug in MACLISP 2122 To: JONL at MIT-MC cc: admin.lougheed at SU-SCORE, bug-maclisp at MIT-MC In-Reply-To: Your message of 30-Nov-81 1323-PST Date: 30 November 1981 16:23-EST From: Jon L White To: Admin.lougheed at SU-SCORE . . . This is entirely due to the recent (as far as MacLISP is concerned) incompatible change to TOPS-20, that of making PS: be a logical name. Note that "making PS: a logical name" is *not* necessarily a recent change. Anyone could have done this for him/herself at any time since Tops-20 was first released (well, PS: only mattered since Release 2, but...). Maclisp has had lots of time to adapt to the Tops-20 way of doing things, and has failed to do so. The only real recent change is that now the system REQUIRES that PS: be a logical name, so what was formerly a user restriction now becomes a bug. Oh well, for new lisp programs we can always encourage people to use ELISP instead of Maclisp. -------  Date: 30 November 1981 16:23-EST From: Jon L White To: Admin.lougheed at SU-SCORE cc: KMP at MIT-MC, BUG-MACLISP at MIT-MC, admin.mrc at SU-SCORE, admin.jqj at SU-SCORE Date: 30 Nov 1981 0049-PST Subject: bug in MACLISP 2122 From: Kirk Lougheed The latest version of MACLISP at SCORE seems to have some problems. When I try to invoke LEDIT while connected to my login directory, . . . This is entirely due to the recent (as far as MacLISP is concerned) incompatible change to TOPS-20, that of making PS: be a logical name. We have been discussing alternatives for this problem. Generally, you should send MacLISP complaints to BUG-MACLISP@MIT-MC, unless there is some site-specific problem.  Date: 30 November 1981 12:21-EST From: Jon L White Subject: ARRAY-DIMENSION-N To: WGD at MIT-MC cc: GSB at MIT-MC, BUG-MACLISP at MIT-MC Date: 21 November 1981 15:37-EST From: William G. Dubuque (array-dimension-n () (*array () T 1)) => .VAL 0; EROR%A+22>>PUSHJ P,UINT Fixed, and patched in current lisp.  GSB@MIT-ML 11/29/81 15:29:29 Re: new format,loop To: (BUG LISP) at MIT-ML i have installed new format & loop on ML. I will propagate them elsewhere when it seems safe to do so.  Date: 24 Nov 1981 1840-PST From: Mohammed at SRI-KL Subject: Buggy complr To: bug-maclisp at MIT-MC Jon: For reasons I can't fathom, sometimes COMPLR decides that functions which have been loaded and declared haven't. Witness: [PHOTO: Recording initiated Tue 24-Nov-81 6:30PM] [Synonym LO defined] End of COMAND.CMD.5 @tyPE (FILE) test1.lsp (eval-when (load eval) ;This is the fix you described for getting (cond ((status feature complr) ;LEXPRS declared in the complr (declare (*lexpr test1))))) ;environment (herald test1 /0) ;(eval-when (load) ;I used this to prove to ; (error "Yes we are being loaded!! (TEST1)")) ;myself that the file is ;actually loaded. (defun test1 (a &optional (b 'ly)) (print (symbolconc a b))) @ @tyPE (FILE) test2.lsp (eval-when (load eval compile) (load '((ps |mohammed.maclisp|) test1 fasl))) (defun test2 () (test1 0.) (test1 0. 2.)) @complr.EXE.2 LISP COMPILER 1118 [in LISP 2122] _test2 (COMMENT **ERROR** (TEST1 0. 2.) Wrong number of args in function TEST2) ; DATA ERROR - TO PROCEED TYPE $P ;BKPT DATA $P _ ;BKPT ^B (plist 'test1) (*EXPR T VERSION /7 LSUBR #270000) ;Note that TEST1 IS in the environment (describe 'test1) ;Loading DESCRIBE 4 ;Loading EXTEND 284 ;Loading EXTBAS 35 ; Loading FORMAT ([MC]DSK:FORMAT;FORMAT 793) TEST1 is defined as a LSUBR; Args: (1 . 2) TEST1 has property *EXPR: T ;and that it is marked as an EXPR TEST1 has property VERSION: /7* @ty test2.unfasl '(THIS IS THE UNFASL FOR ((PS |MOHAMMED.MACLISP|) TEST2 LSP /7)) '(ASSEMBLED BY FASLAP /392) '(COMPILED BY LISP COMPILER /935 COMAUX /25 PHAS1 /81 MAKLAP /80 INITIA /115) ;COMPILED ON NOVEMBER 24, 1981, AT 6:31 PM ;Loading TEST1 7 (COMMENT **** TEST1 Has been previously used with wrong number of arguments in funct ion TEST2) (COMMENT **ERROR** (TEST1 0. 2.) Wrong number of args in function TEST2) ; DATA ERROR - TO PROCEED TYPE $P (COMMENT **** (TEST2) - Failed to compile) (COMMENT **** (TEST1) have been used but remain undefined in this file) (COMMENT **FASL** TOTAL = 0. WORDS) @pop [PHOTO: Recording terminated Tue 24-Nov-81 6:32PM] Yet, COMPLR doesn't want to know that TEST1 is defined. John L. Mohammed -------  Date: 21 November 1981 16:14-EST From: Glenn S. Burke To: WGD at MIT-MC cc: BUG-MACLISP at MIT-MC Date: 21 November 1981 15:37-EST From: William G. Dubuque Sender: BIL at MIT-MC (array-dimension-n () (*array () T 1)) => .VAL 0; EROR%A+22>>PUSHJ P,UINT Couldn't this at least do some error checking when *RSET = T ? That error is coming from the arg checking, which is being performed with internal (INHIBIT) interrupts inhibited. The fixnum check should be moved out of the protected code.  Date: 21 November 1981 15:37-EST From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-MACLISP at MIT-MC (array-dimension-n () (*array () T 1)) => .VAL 0; EROR%A+22>>PUSHJ P,UINT Couldn't this at least do some error checking when *RSET = T ?  MOON@MIT-MC 11/21/81 15:35:11 Re: Compiling files in Maclisp To: KWH at MIT-AI CC: (BUG MACLISP) at MIT-AI, (BUG LMMAN) at MIT-AI Date: 21 November 1981 02:55-EST From: "Kenneth W. Haase, Jr." To: BUG-MACLISP at MIT-AI, BUG-LMMAN at MIT-AI COMPLR didn't seem to know the IF-FOR-MACLISP function documented in the new (and the old also, I think) LISPM manual. Is this a bug in Maclisp, the manual, or me? I can just use #M, but it would be nice if I could pretty up my code by having clear regions.... Did you put either the declaration given on page 189 of the red manual or the one given on page 206 of the blue/gray manual at the front of your file?  Date: 21 November 1981 13:28-EST From: Jeffrey P. Golden To: ASB at MIT-MC, LEWISR at MIT-MC cc: BUG-LISP at MIT-MC, JPG at MIT-MC ASB@MIT-MC 11/21/81 13:04:20 LEWISR@MIT-MC 11/20/81 22:38:29 Another question, if I may. While something was running (a file was being loaded), a message ;GLEEP! OUT OF BIT BLOCKS came. However, the loading concluded and the program proceeded with execution. What did the message mean, and should I distrust the results of the calculation? I am not really the one to ask about this. The message is printed by Lisp, and I think it means something like "I am choking so badly that this is just about all I can tell you about it." I have always found that things continue quite normally after the message appears, but it is a bit unnerving. Perhaps JPG can enlighten us both. I don't really know what it means either. I've tried to get the LISP system hackers to say something on the subject with no success. E.g. I've never gotten an answer to the mail I sent below: JPG@MIT-MC 22 AUG 1978 0350-EDT To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC, CHAR at MIT-MC, ELLEN at MIT-MC It would be nice if something were done about the cute "gleep! out of bit blocks" message. This message is unintelligible to us all wrt the state it is trying to convey and its seriousness. E.g., can a MACSYMA be reasonably continued after the user receives this message? Can it happen when (STATUS MEMFREE) is not 0? And exactly what does it mean as far as the functioning of the GC or whatever?  Date: 21 November 1981 02:55-EST From: "Kenneth W. Haase, Jr." To: BUG-MACLISP at MIT-AI, BUG-LMMAN at MIT-AI COMPLR didn't seem to know the IF-FOR-MACLISP function documented in the new (and the old also, I think) LISPM manual. Is this a bug in Maclisp, the manual, or me? I can just use #M, but it would be nice if I could pretty up my code by having clear regions....  Date: 18 November 1981 13:38-EST From: Jon L White Subject: New mis-feature of TOPS-20, Release 5, and/or search rules for Logical names To: Admin.MRC at SU-SCORE cc: JONL at MIT-MC, "(FILE LISP;BUG MAIL)" at MIT-MC, RYLAND at SRI-KL, ADMIN.JQJ at SU-SCORE, CSD.CLAYTON at SU-SCORE, CSD.GENESERETH at SU-SCORE, ZUBKOFF at CMU-20C, BUG-TWENEX at MIT-XX Problems with logical names under Twenex have come up in the past, and the new state, having PS: be a 'logical name', will break MacLISP. Since it is now installed on SCORE that way, then SCORE's MacLISP will essentially be unusable until there is some resolution -- I don't yet know of other sites with Release 5 yet, so maybe we can 'fix' this before too many others are affected. One fix I suggested is having MacLISP 'special-case' the PS: device, but that amounts to defeating this new misfeatureful generality and I'm not sure that that's wise in the long run. The only other alternative is for the searching rules to act in accord with my suggestion below, which is part of my reply to your reply: Date: 17 Nov 1981 1519-PST From: Mark Crispin In-Reply-To: Your message of 17-Nov-81 1130-PST . . . Yes, the systemwide logical name of PS: is a new feature of TOPS-20. . . The bug is MACLISP's. It should supply both the device and the directory specification to GTJFN in all circumstances. This doesn't work -- when the GTJFN supplies a directory specification, it overrides any such in the logical name. E.g., suppose you have @DEF FOO: PS:,PS: and suppose has a BS.LSP, but doesn't. Then using "FOO:BS.LSP" will succeed, but "FOO:BS.LSP" will not. I suspect that in the latter case, the "FOO:" part is limited to supplying a real device name (i.e., PS:) for the searching procedure, whereas it should go through its search sequence independently of the . The MacLISP user will find himself 'supplying' directory specifications without conscious effort, since that is the reason for the DEFAULTF variable; possibly initializing it to ((* *) * ...) would get around some problems, but may introduce other undesirable perturbations. If it needs the true location of the file, it should GTJFN it with GJ%OLD (to force a chase down the logical name tree to find an existing file) then use JFNS to get the string back. That's indeed how the PROBEF and TRUENAME functions work. Release 5 is going to be this way as a standard. HELP! Any of you Twenex wizards out there got an idea?  Date: 17 November 1981 17:34-EST From: Jon L White Subject: Announce-&-load-init-file To: gsb at MIT-ML cc: BUG-LISP at MIT-MC GSB@MIT-ML 11/16/81 18:44:10 if i have GSB;* COMPLR and not GSB;GSB COMPLR and a start a complr it croaks. Fixed in SHARABLE version 47 now -- I've made up new SHARAB^K and MACLISP^K dumps, and and also dumped out a new COMPLR in this more recent version of MACLISP (was time for a new COMPLR anyway). P.S. -- not installed on AI yet due to late-afternoon lossages.  Date: 17 November 1981 17:31-EST From: Jon L White Subject: FLATC on pseudo-strings To: PSZ at MIT-ML cc: BUG-LISP at MIT-MC PSZ@MIT-ML 11/17/81 12:49:21 (flatc '"foobar") is 6, but of course if one prints "foobar", it occupies 8 characters. . . . Right, because (princ '"foobar") causes only 6 chars to come out -- if you want to know about the double-quotes, then try FLATSIZE.  Soley@MIT-MC 11/17/81 13:16:15 Re: Bad interaction between default strings (MACLISP) and FLATC To: PSZ at MIT-ML, (BUG LISP) at MIT-ML PSZ@MIT-ML 11/17/81 12:49:21 Re: Bad interaction between default strings (MACLISP) and FLATC To: (BUG LISP) at MIT-ML (flatc '"foobar") is 6, but of course if one prints "foobar", it occupies 8 characters. I understand why 6 is also a "reasonable" answer, but for the classical uses of FLATC it's just wrong. Me thinks you'd be needing the function FLATSIZE, not FLATC, to return 8. -- Richard  PSZ@MIT-ML 11/17/81 12:49:21 Re: Bad interaction between default strings (MACLISP) and FLATC To: (BUG LISP) at MIT-ML (flatc '"foobar") is 6, but of course if one prints "foobar", it occupies 8 characters. I understand why 6 is also a "reasonable" answer, but for the classical uses of FLATC it's just wrong.  GSB@MIT-ML 11/16/81 18:44:10 Re: announc-&-load-init-file bombs To: (BUG LISP) at MIT-ML if i have GSB;* COMPLR and not GSB;GSB COMPLR and a start a complr it croaks.  Date: 14 November 1981 16:15-EST From: Richard Mark Soley Subject: &optional arguments and complr To: JONL at MIT-MC cc: BUG-MACLISP at MIT-MC, MOHAMMED at SRI-KL Why can't defun generate the *LEXPR? -- Richard  Date: 14 November 1981 14:38-EST From: Jon L White Subject: &optional arguments and complr To: MOHAMMED at SRI-KL cc: BUG-MACLISP at MIT-MC Functions defined with &optional arguments are automatically turned into 'lexpr's, so that a variable number of arguments may be handled. The only full solution to the "number of arguments" problem during compilation is to declare such functions as *LEXPR, in the files which use them. However, note that COMPLR's message is merely a warning -- the compiled code is still correct (albeit somewhat less than optimal since SUBR-type calls to a function with LSUBR-calling-sequence cannot have their UUO links 'snapped'). Date: 12 Nov 1981 1408-PST From: MOHAMMED at SRI-KL There is a bug in the way complr handles functions with optional arguments. I've prepared a dribble file to demonstrate the problem: . . . 1. Despite the fact that the function TEST1 is loaded when TEST2 is compiled, complr decides that something is wrong because the function is being called with a different number of arguments. 3. It makes no difference whether the fasl or lsp version of TEST1 is loaded. Whatever information may be found about TEST1 must be consistent with that in the intended target environment -- declarations are the only safe way to give this information, since the compilation environment need not be (and indeed in many cases is not) consistent with the target. 2. When TEST1 is re-compiled in the same complr as TEST2, the problem does not occur. After the COMPLR compiles a function, it makes the declarations that are deducible from its definition; in this case, it notes that TEST1 is LSUBR type in the target environment. 4. Declaring TEST1 to be a *LEXPR in the TEST2 file is an effective temporary solution to the problem. Also a long-term solution.  Date: 12 November 1981 23:26-EST From: George J. Carrette To: JONL at MIT-MC cc: BUG-LISP at MIT-MC, JAR at MIT-MC, KMP at MIT-MC I sure am glad I sent the note about sharing! Indeed, I was starting to work on a sharing program for TOPS-20 which didn't assume anything about maclisp guts . Lets see that code Jonathon!  Date: 12 Nov 1981 1408-PST From: MOHAMMED at SRI-KL Subject: &optional arguments and complr To: bug-maclisp at MIT-MC To whom it may concern: There is a bug in the way complr handles functions with optional arguments. I've prepared a dribble file to demonstrate the problem: [PHOTO: Recording initiated Tue 10-Nov-81 6:13PM] [Synonym LO defined] End of COMAND.CMD.5 @ty test1.lsp (herald test1 /0) (defun test1 (a b &optional (c 1)) (* a b c)) @ty test2.lsp (eval-when (load eval compile) (or (get 'test1 'version) (load '(test1 fasl ps |mohammed.maclisp|)))) (herald test2 /0) (defun test2 (a b) (test1 a b) (test1 a b 3)) @complr.EXE.2 LISP COMPILER 1118 [in LISP 2122] _test1 _ @ty test1.uNFASL.3 '(THIS IS THE UNFASL FOR ((PS |MOHAMMED.MACLISP|) TEST1 LSP /3)) '(ASSEMBLED BY FASLAP /392) '(COMPILED BY LISP COMPILER /935 COMAUX /25 PHAS1 /81 MAKLAP /80 INITIA /115) ;COMPILED ON NOVEMBER 10, 1981, AT 6:13 PM (COMMENT **FASL** 0. (LAP TEST1 LSUBR)) (COMMENT **FASL** TOTAL = 20. WORDS) @complr.EXE.2 LISP COMPILER 1118 [in LISP 2122] _test2 (COMMENT **ERROR** (TEST1 A B 3.) Wrong number of args in function TEST2) ; DATA ERROR - TO PROCEED TYPE $P ;BKPT DATA $P _ @ty test2.uNFASL.1 '(THIS IS THE UNFASL FOR ((PS |MOHAMMED.MACLISP|) TEST2 LSP /1)) '(ASSEMBLED BY FASLAP /392) '(COMPILED BY LISP COMPILER /935 COMAUX /25 PHAS1 /81 MAKLAP /80 INITIA /115) ;COMPILED ON NOVEMBER 10, 1981, AT 6:14 PM ;Loading TEST1 3 (COMMENT **** TEST1 Has been previously used with wrong number of arguments in funct ion TEST2) (COMMENT **ERROR** (TEST1 A B 3.) Wrong number of args in function TEST2) ; DATA ERROR - TO PROCEED TYPE $P (COMMENT **** (TEST2) - Failed to compile) (COMMENT **** (TEST1) have been used but remain undefined in this file) (COMMENT **FASL** TOTAL = 0. WORDS) @complr.EXE.2 LISP COMPILER 1118 [in LISP 2122] _test1 _test2 _ @dir test* PS: TEST1.FASL.3 .LSP.3 .UNFASL.3 TEST2.FASL.1 .LSP.1 .UNFASL.1 Total of 6 pages in 6 files @ty test2.uNFASL.1 '(THIS IS THE UNFASL FOR ((PS |MOHAMMED.MACLISP|) TEST2 LSP /1)) '(ASSEMBLED BY FASLAP /392) '(COMPILED BY LISP COMPILER /935 COMAUX /25 PHAS1 /81 MAKLAP /80 INITIA /115) ;COMPILED ON NOVEMBER 10, 1981, AT 6:14 PM ;Loading TEST1 3 (COMMENT **FASL** 0. (LAP TEST2 SUBR)) (COMMENT **FASL** TOTAL = 18. WORDS) @pop [PHOTO: Recording terminated Tue 10-Nov-81 6:15PM] Notes: 1. Despite the fact that the function TEST1 is loaded when TEST2 is compiled, complr decides that something is wrong because the function is being called with a different number of arguments. 2. When TEST1 is re-compiled in the same complr as TEST2, the problem does not occur. 3. It makes no difference whether the fasl or lsp version of TEST1 is loaded. 4. Declaring TEST1 to be a *LEXPR in the TEST2 file is an effective temporary solution to the problem. John L. Mohammed -------  Date: 12 November 1981 16:27-EST From: Jon L White To: GJC at MIT-MC, KMP at MIT-MC cc: BUG-LISP at MIT-MC, JAR at MIT-MC Date: 12 November 1981 15:59-EST From: George J. Carrette Do you know a way to get optimal sharing of maclisp on TOPS-20? It would be very good to have different suspended systems share the Maclisp they were dumped in. A real system performance issue on the MIT-EECS machine, where three undergraduate courses use three different systems dumped in lisp. Indeed, MacLISP on TOPS-20 could look for its "PURQIO" file, and share pages from it -- but that doesn't solve the incremental sharing problem. The SHARABLE file, written in LISP and LAP which GSB and I wrote, could handle TOPS-20 systems too, providing that the LAP part which does system calls were modified for finding out Twenex-style file info. Could it be that someone at Yale has already done some such thing? Date: 12 November 1981 16:08-EST From: Kent M. Pitman We should not be worrying about sharing on TOPS-20 from the Maclisp point of view. The Yale people have the answer to that. We should get JAR to bring us the stuff on their SHARE program which takes care of dumping shared dumps in a totally system-independent way (needs no cooperation from Maclisp). I'd like to see it when available.  Date: 12 November 1981 16:22-EST From: Jon L White To: KMP at MIT-MC cc: BUG-LISP at MIT-MC Date: 11 November 1981 17:03-EST From: Kent M. Pitman In a fresh lisp, I went to try your describe fixes. I got (MAKE-STRING 5 #/A) ;Loading SHARPM 80 . . . ;Loading EXTBAS 38 ;TO-CHARACTER-N? UNDEFINED FUNCTION IN UUO CALL Fixed in current STRING (version 185) -- was missing the autoload putprop for TO-CHARACTER-N?, which is used when you feed a second arg to MAKE-STRING.  Date: 12 November 1981 16:08-EST From: Kent M. Pitman To: GJC at MIT-MC cc: BUG-LISP at MIT-MC, JAR at MIT-MC We should not be worrying about sharing on TOPS-20 from the Maclisp point of view. The Yale people have the answer to that. We should get JAR to bring us the stuff on their SHARE program which takes care of dumping shared dumps in a totally system-independent way (needs no cooperation from Maclisp).  Date: 12 November 1981 15:59-EST From: George J. Carrette To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Do you know a way to get optimal sharing of maclisp on TOPS-20? It would be very good to have different suspended systems share the Maclisp they were dumped in. A real system performance issue on the MIT-EECS machine, where three undergraduate courses use three different systems dumped in lisp.  Date: 11 November 1981 17:03-EST From: Kent M. Pitman To: BUG-LISP at MIT-MC In a fresh lisp, I went to try your describe fixes. I got (MAKE-STRING 5 #/A) ;Loading SHARPM 80 ;Loading DEFMAX 98 ;Loading STRING 185 ;Loading EXTEND 289 ;Loading EXTSTR 94 ;Loading EXTBAS 38 ;TO-CHARACTER-N? UNDEFINED FUNCTION IN UUO CALL  Date: 10 November 1981 20:50-EST From: Jon L White Subject: STRING-REVERSE-SEARCH-NOT-SET, and effect upon STRING-RIGHT-TRIM To: DCP at MIT-MC cc: BUG-LISP at MIT-MC Date: 20 September 1981 16:26-EDT From: David C. Plummer Subject: Why can't things ever be tested? Or, Doesn't anybody else use strings (if they are, why is this breaking for me)? In the current string package... (string-right-trim '(#\space) "this is a test ") "this is a test " ;; STRING-LEFT-TRIM and STRING-TRIM both trim from the left, but ;; even STRING-TRIM doesn't trim from the right. Fixed as of STRAUX version 74. Sorry for waiting so long to answer this one -- indeed it sounds like these two functions (STRING-RIGHT-TRIM and STRING-TRIM) aren't used by anybody else. The culprit was a fence-post-error-by-1 in the default calculation of the 'limit' argument to STRING-REVERSE-SEARCH-NOT-SET (works ok when user supplies that arg). It turns out that STRING-RIGHT-TRIM calls STRING-REVERSE-SEARCH-NOT-SET, and was getting this wrong value back . . .  Date: 10 November 1981 20:44-EST From: Jon L White Subject: DESCRIBE methods for various things To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC Date: 18 September 1981 00:27-EDT From: Alan Bawden (make-string 5 #/a) "aaaaa" (describe *) The object at #733646 of class STRING, and is 4 Q's long. I've just added DESCRIBE methods for STRINGs, VECTORs, and BITSs -- presumably the new format will be less obscure.  Date: 10 November 1981 16:15-EST From: Jon L White Subject: SOURCE-TRAN "optimizer" for SI:XSET To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 10 November 1981 16:03-EST From: George J. Carrette CL^K! . . . This comes from a bogus SOURCE-TRANS on SI:XSET. Try (si:xstuff-expander '(si:xset (a) (b) (c))). Fixed, and patch file for current COMPLR emmended. One wing of the "optimizer" had a ",." where a "," was wanted.  Date: 10 November 1981 16:03-EST From: George J. Carrette To: BUG-LISP at MIT-MC CL^K! (load '((lisp)vector)) (defun f (a b) (vset a (g) b)) (cl:cl f) .... ** RPLACX undeclared taken as special ... This comes from a bogus SOURCE-TRANS on SI:XSET. Try (si:xstuff-expander '(si:xset (a) (b) (c))).  Date: 9 November 1981 16:09-EST From: Jon L White Subject: losing with newly released STRING ? To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 9 November 1981 01:53-EST From: George J. Carrette After enough consing/garbage-collection the pnames of strings change. ... ;; note the value of the following variable STATUS-SSTATUS-FUNCTION-ALIST ;; then compile a file (comfile "jl;emacs") . . . This problem may not be related particularly to the new STRING, but possibly to the dynamics of GC/consing -- your dumped VASL is already garbaged, before you ever start to do COMFILE. The point at which you noticed the bug occurred while trying to make a FORMAT string, and I noticed that the GC-DAEMON in VASL is backwards (in a sense) -- by not loading the Baker GCDEMN file "early" (i.e., before the STRING file) its daemon function gets run before the string gc-daemon function, and if it causes any consing, there could be some lossages. I'll change the Baker GCDEMN file to run its function 'last', rather than first. But where did this value for STATUS-SSTATUS-FUNCTION-ALIST get created? None of the strings on it are "real", which is why they go away after the first STRING-GC; but the string GC markarray has entries for lots of other STATUS/SSTATUS keyword names which aren't on that list. Could you make up a new VASL with the to-be-fixed Baker GCDEMN, and with the current STRING, but having first done (SETQ STR:GC-CHECK? 'T) ? If there are any truly weird conditions occuring during the load-up phase, this should catch them (but it also may catch a legitimate situation where queue-ing up of interrupts had occurred).  Date: 9 November 1981 01:53-EST From: George J. Carrette Subject: losing with newly released STRING To: BUG-LISP at MIT-MC After enough consing/garbage-collection the pnames of strings change. One way to exhibit the bug: :NVASL ;; note the value of the following variable STATUS-SSTATUS-FUNCTION-ALIST ;; then compile a file (comfile "jl;emacs") ;; about 10% through the file a function which depends on using STRING-EQUAL ;; signals an error, now look at the list STATUS-SSTATUS-FUNCTION-ALIST -gjc  GSB@MIT-ML 11/09/81 00:37:41 Re: STRING, fyi To: (BUG LISP) at MIT-ML STRING was setting *format-string-generator to TO-STRING> -- presumably this is an excremental-search/meta-> type of typo. Since this was in the installed version i fixed and recompiled and installed the fasl to AI and ML. (Bad version = 181)  Date: 7 November 1981 12:11-EST From: David C. Plummer Subject: null file name To: RYLAND at SRI-KL cc: BUG-MACLISP at MIT-MC As an interim (or complete solution) the following seems to work: (open '((cha) /.foo 0)) When I did that on EE, it didn't return (yet), so I ^C'd out of MACLISP and looked at my file status: Restricted JFN Not opened Read My guess is that this along the right track.  Date: 6 Nov 1981 1605-PST From: Chris Ryland Subject: null file name To: bug-maclisp at MIT-MC I'm trying to open a Chaosnet server file (CHA:.FOO) from Maclisp OPEN, and lose trying to specify a null filename (which is critical to specifying the Chaos server entire filename). Is there a way to do this? -------  Date: 6 November 1981 18:35-EST From: Jon L White Subject: # macros. To: kwh at MIT-AI cc: BUG-MACLISP at MIT-MC, BUG-LISPM at MIT-MC Date: 6 November 1981 17:13-EST From: "Kenneth W. Haase, Jr." I have a file with Maclisp and LISPM code intermixed, and use #Q and #M to differentiate code for each one. However inside of one of the LISPM defs (protected by #Q) I use #\Control-E, and for some reason MACLISP sees this and returns an error. (That it didn't recognize #\Control-E) Is there anyway to make Maclisp just not read that definition? In SHARPM version 79, I've just fixed it so that it doesn't complain about certain "errors" which are detected as errors only by virtue of the fact that the code is being processed by MacLISP reader -- the range of symbolic character names is one of these. Thus, '(A #Q #\Control-E) will win, but '(A #\Control-E) will lose in MacLISP. This also applies to NIL constructs too -- so that '(A #N #T) will win, but '(A #T) will lose in native MacLISP. For this context, #Q and #+LISPM are interchangeable. The COMPLR has been dumped out with SHARPM version 78 current, so until another dump is made (hopefully, tomorrow), you may have to re-load by hand.  Date: 6 November 1981 17:13-EST From: "Kenneth W. Haase, Jr." Subject: # macros. To: BUG-LISPM at MIT-AI, BUG-MACLISP at MIT-AI cc: KWH at MIT-AI I have a file with Maclisp and LISPM code intermixed, and use #Q and #M to differentiate code for each one. However inside of one of the LISPM defs (protected by #Q) I use #\Control-E, and for some reason MACLISP sees this and returns an error. (That it didn't recognize #\Control-E) Is there anyway to make Maclisp just not read that definition?  Date: 4 November 1981 11:43-EST From: Jon L White Subject: SETF lacking bootstrap autoload property, and repeat of GENTEMP suggestion To: psz at MIT-ML cc: BUG-LISP at MIT-MC PSZ@MIT-ML 11/03/81 01:16:07 I just tried the following in a bare Lisp: (defun foo macro (x) '(arraycall t foo 2 2)) . . . (setf (foo) t) ;Loading SETF 292 . . . ;GENTEMP UNDEFINED FUNCTION IN UUO CALL Fixed in SETF version 293, which I just installed. Probably GENTEMP should have an initial AUTOLOAD property, but adding new capability to the initial system without taking more address space is a time-consuming process. For some time, we've been planning to get a wide-spread acceptance of the GENTEMP idea, but it's been going slowly. Anyone yet interested either of the two ideas: 1) Truly unique gensyms -- incorporating enough information to distinguish site name and time quantum; 2) New data type -- a "gensym" symbol, which is guaranteed to be un-interned, but still identifiable over calls to READ, e.g. (SETQ L '(A #G00025 B #G00025)) would guarantee (EQ (CADR L) (CADDDR L)), but subsequent calls to READ would get a different, un-interned symbol for #G00025.  PSZ@MIT-ML 11/03/81 01:16:07 To: (BUG LISP) at MIT-ML I just tried the following in a bare Lisp: (defun foo macro (x) '(arraycall t foo 2 2)) (setq foo (array nil t 3 3)) (setf (foo) t) ;Loading SETF 292 ;Loading DEFMAX 98 ;Loading EXTSTR 94 ;GENTEMP UNDEFINED FUNCTION IN UUO CALL Doesn't seem right.  Date: 3 November 1981 00:51-EST From: Robert W. Kerns To: BUG-LISP at MIT-MC cc: SK at MIT-MC I suppose VALRET should be made to understand strings...  EB@MIT-ML 10/30/81 02:52:46 To: (BUG LISP) at MIT-ML Redefining classes, recently fixed, seems to sometimes cause the message ;System error, or system code incomplete: Id 'NIL' in function SI:INVALIDATED. ; Losing datum is: LIST ;+INTERNAL-LOSSAGE (NIL SI:INVALIDATED LIST) to eventually be produced. I don't know how to reproduce this.  Date: 28 October 1981 13:53-EST From: Jon L White Subject: MacLISP and structures on Twenex To: Roger.Dannenberg at CMU-10A cc: BUG-LISP at MIT-MC, Leonard.Zubkoff at CMU-10A Date: 27 October 1981 0002-EDT (Tuesday) From: Roger.Dannenberg at CMU-10A (C410RD60) Message-Id: <27Oct81 000217 RD60@CMU-10A> 1) when maclisp comes up it looks for lisp.ini and then trys to load ps:lisp.ini (note the difference). If I connect to pqcc: then I must have lisp.ini on both pqcc: and ps: (!) ... 4) maclisp won't read the *ledit* buffer when I'm connected to pqcc: (I can make it work by connecting to ps:) Most MacLISP software was written on ITS systems, where there is no concept of multiple "structures". (STATUS UDIR) returns the name of the connected directory, but of course doesn't make available the name of the connected structure. Thus LEDIT can't find out this information either. Probably some additional primitive needs to be added for TOPS users.  Date: 28 October 1981 13:18-EST From: Jon L White Subject: Use of *RSET, and your conjectures To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 27 October 1981 19:46-EST From: George J. Carrette If you think it is reasonable to have factors of 60 difference in speed with the bit and string primitives depending on *RSET, ... I never implied anything at all like that -- only the worst case (which you were carping about) admits such large error-checking time. VASLAP uses NIBBLE and SET-NIBBLE which are much different (as I told you in my previous note). There is no reason to run a debugged compiler in *RSET mode -- only the expansion of user macros and the interpretation of user code need to be so protected. Thus Interpreters, like MacSYMA are correct in doing this; but assemblers, like VASLAP, don't run random code, and when they are fairly well debugged don't need *RSET for their own protection. ... JONL, the reason all the "NILCOM" stuff you wrote had to be reimplemented was to gain correctness and reliability. I disagree with your opinion as to why you re-did some of the semantics your own way. This is a nasty way of justifying your independent actions.  Date: 27 October 1981 0811-EDT (Tuesday) From: Leonard.Zubkoff at CMU-10A (C410LZ60) To: Bug-Lisp at MIT-MC Subject: MacLisp with multiple structures Message-Id: <27Oct81 081113 LZ60@CMU-10A> I received the following Bug report; it seems to me that this is due to the fact that (ststus udir) knows nothing about the connected structure, only the connected directory. Is there a fix for this in the works? Leonard - - - - Begin forwarded message - - - - Date: 27 October 1981 0002-EDT (Tuesday) From: Roger.Dannenberg at CMU-10A (C410RD60) To: Leonard.Zubkoff at CMU-10A Subject: maclisp and structures Message-Id: <27Oct81 000217 RD60@CMU-10A> Origin: C410RD60 at CMU-10A; 27 Oct 1981 0002-EDT I've been trying to use maclisp on cmuc for about 2 hours, and still can't get ledit etc. to work. My ignorance of tops-20 is probably the major cause of my problems, but there are a few other bugs: 1) when maclisp comes up it looks for lisp.ini and then trys to load ps:lisp.ini (note the difference). If I connect to pqcc: then I must have lisp.ini on both pqcc: and ps: (!) 2) when connected to pqcc:, there seems to be no way to slurp files (I guess that's touretzky's problem) 3) when connected to pqcc:, (LLOAD file ext) will look for ps:file.ext instead of pqcc:file.ext 4) maclisp won't read the *ledit* buffer when I'm connected to pqcc: (I can make it work by connecting to ps:) (I think the above are real bugs, but maybe there's something I should be doing to avoid them.) thanks, roger - - - - End forwarded message - - - -  Date: 27 October 1981 07:56-EST From: Jon L White Subject: Validity of your off-the-wall timing conjectures To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 26 October 1981 14:38-EST From: George J. Carrette To: JONL at MIT-MC I ran my timing tests with *RSET both on an off. You get a factor of 3 speed-up with *RSET off. Still not good enough. ... The speed-up factor for typical NIL data-emulation functions is 40. to 70., not 3 as your reply suggests (in particular, the CHAR and BIT1P functions). Apart from the fact that your "timings" were not accompanied by any numbers, there is reason to believe you neglected to factor out the GC time: the fact that I had to remind you about the *RSET factor suggests this, but even more critically, you were simply unaware of extensive amount of checking (in *RSET mode) in the NIL-data-type emulation functions. Long before you were around, RWK, REES, RLB and I insisted on the capability for full error checking in *RSET mode. Forgetting about your totally off-the-wall comparison between the VAX and the PDP10 ("apples" and "oranges", since PDP10 doesn't have load-byte-indexed), there is the question of why you mailed off your unsupported conjectures to the BUG-LISP community. If you intended to press for faster emulation on the PDP10, then you completely blew it, for you didn't even make any timings of the alternative emulation schemes. Furthermore, you obviously hadn't considered the memory constraints (*** and data size limitations ***) imposed by the alternatives (for example, limitation of 512. chars for a STRING, or consing n fixnums for a BITS in addition to the hunk space taken) Date: 26 October 1981 18:12-EST From: George J. Carrette Subject: Timing worries. ... However, you are not one to talk about what most of the nil system code needs, since you haven't written any of it. In particular the assembler handles BITS in its own way. ... WRONG! The assembler uses the emulation BITS package. In particular, it needs NIBBLE and SET-NIBBLE, and for these, the emulation is efficient. During debugging of the assembler (a process which continued for at least a year), RLB appreciated the *RSET mode; after that we ran it in *RSET () mode without problem. I know code I've written -- if you've replaced it with your own version of things (as you generally seem to do), then that's just one more reason why the NIL project is one year and four months behind schedule.  Date: 26 October 1981 18:12-EST From: George J. Carrette Subject: Timing worries. To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Yeah, INTERN is a lot faster on the VAX too, and yes, I use FUNCALL a lot too, so I should be using SUBRCALL in Maclisp. Also, the I/O is a lot more efficient on the VAX. It all adds up. However, you are not one to talk about what most of the nil system code needs, since you haven't written any of it. In particular the assembler handles BITS in its own way. Of reasonable importance is how often such programs will be run on the PDP10 -- if it's a small number of times (as you suggest) then virtually all your time spent developing alternative, less general systems will be wasted. The programs will run just once, to bring up NIL. However, that is worth everything. It doesn't matter if it is useless for some hypothetical maclisp user. What good is this "generality" you have spent so much of you time on? -gjc  Date: 26 October 1981 15:22-EST From: Jon L White Subject: Your timing worries, and generality To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 26 October 1981 14:38-EST From: George J. Carrette ... But why a function call to get an element of a string? That is what stinks. So, I changed the implementation, made my own strings that used a HUNK of FIXNUMS, and got open coding and decent speed. Originally, my STRING emulation package used hunks, but there are severe limitations to that approach -- you certainly can't get enough generality (or space efficiency) from this approach to do most of the NIL system code already written (assembler, compiler, text processor etc). ... The same thing works like a charm for BIT1P ==> (LOGAND (LSH 1 (\ J 36.)) (CXR (+ 2 (// J 36.)) X)). ... This is sort of what happens with BIT1P now, except that a function call has to be done in order to retrieve the bit from a FIXNUM array. Speaking of function calls, the call to +INTERNAL-CHAR-N takes about 20 microseconds to retrieve a character from a string -- the corresponding VAX retrieval has got to be at least 1 microsecond, and possibly more (depending on whether the arguments have to be moved to registers, etc). Thus even allowing your 'factor of 3' for failure to set *RSET to (), *** and timing only this correspondingly slow operation ***, its hard to imagine how you came up with a figure of 138. times slower on the PDP10. Could it be that there's something else you're not telling? Of course, BITS emulations may be slower since they aren't as generally useful as STRINGs are -- the important thing was that they be large enough to handle cross-compiled SUBRs, and using hunks rather than FIXNUM arrays won't make it for the big cases. Worse yet, the memory utilization factor is even more important on the PDP10, and it is poor when you have to take a new page of HUNKn space just because you wanted a single BITS of some random size. Of reasonable importance is how often such programs will be run on the PDP10 -- if it's a small number of times (as you suggest) then virtually all your time spent developing alternative, less general systems will be wasted. But if BITS are really important, and if everyone agrees to limit their size by the hunk kludgery, then a simple upward-compatible change can be done in the BITS package.  Date: 26 October 1981 14:38-EST From: George J. Carrette To: JONL at MIT-MC cc: BUG-LISP at MIT-MC I ran my timing tests with *RSET both on an off. You get a factor of 3 speed-up with *RSET off. Still not good enough. The compilation of (BIT1P X J) is particulaly poor. So I open-coded somethings by hand, and called +INTERNAL-RPLACHAR-N et. al. Still not good enough. But why a function call to get an element of a string? That is what stinks. So, I changed the implementation, made my own strings that used a HUNK of FIXNUMS, and got open coding and decent speed. The same thing works like a charm for BIT1P ==> (LOGAND (LSH 1 (\ J 36.)) (CXR (+ 2 (// J 36.)) X)). Oh well. Doesn't really matter I guess. I just wish there were more vax around so that we didn't have to use the PDP10 to do the port from VMS-NIL to UNIX-NIL.  Date: 26 October 1981 13:24-EST From: Jon L White Subject: "modifications", or extensions? a 2-bit misunderstanding To: KMP at MIT-MC cc: BUG-MACLISP at MIT-MC Date: 25 October 1981 15:33-EDT From: Kent M. Pitman Subject: Questionable "modifications" to LIBDOC;6BIT (1) I have never had an application for doing 6bit->ascii or vice versa in real time. ... In LISP code, neither have I. That's why there isn't any such function in the extensions I added to 6BIT. Do you really know what you're talking about here? Worrying about someone using BOOLE or LOGAND instead of LOAD-BYTE or whatever is like worrying about someone using (PROG1 ...) instead of LET ... I suggested using DEPOSIT-BYTE to accumulate a result, rather than the code you wrote, which did 6 cons's etc. This is a significant speed question; your reply about sounds just like so much hot air directed at the wrong thing. (3) My code uses advertised functions, not crufty internal things with /| hanging off the end of them. I didn't make any changes to the action of the code you wrote -- my extensions (e.g. the function SYMBOL-TO-SIXBIT) would use that internal function only in cases you didn't cover. If you want to write your own package in such a form and propose it as an alternative that's fine, but I don't think that the LIBDOC;6BIT KMP2 which you wrote qualifies as something simply "added to" LIBDOC;6BIT KMP1. Ok, I've created the package LIBDOC;6BIT JONL2. Sorry.  Date: 26 October 1981 13:11-EST From: Jon L White Subject: New EXTEND is winning. To: WGD at MIT-MC cc: BUG-LISP at MIT-MC Date: 26 October 1981 03:17-EST From: William G. Dubuque Subject: back to normal ... Loading VECTOR into a XCOMPLR loses when a putprop is attempted on a fixnum while loading the new winning EXTEND. I renamed LISP;EXTEND FASL to LISP;EXTEND LOSER and the linked LISP;EXTEND FASL to OFASL. Actually, the problem was that the current dumped COMPLR has some out-of-date files already loaded in it (losing EXTSTR was the offender in this case). I've re-installed the new EXTEND, and put up a COMPLR fix file (which also loads in the new DEFMACRO file, having the features you requested a few weeks ago regarding &aux etc.)  Date: 26 October 1981 11:44-EST From: Jon L White Subject: Timings for the BITS emulations in MacLISP To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 25 October 1981 13:48-EDT From: George J. Carrette Subject: Joke of the century. The implementation of strings and bitvectors in Maclisp is a joke. I brought up the NIL READer in maclisp to use as a Macro32 parser, and the damn thing runs 138 times slower than it does in real VAX NIL. If it were only 2 times slower it would be usable, but 138 times, that is absurd. For a 297 calls to +TYI there were 1297 calls to SI:CHECK-TYPER, 936 calls to PTR-TYPEP, 936 calls to BITSP, . . . Your failed to mention whether or not you ran your timing tests with *RSET on or off. This makes a big difference for the emulation code -- remember, PDP10 doesn't have load-byte-indexed instructions, nor general variable-length bit-field hacking, and these data types and primitive operations were designed with an architecture in mind more like the VAX or 370 than the PDP10. The emulation packages were designed to check all types of arguments, and try to be "secure", so setting *RSET to () should give an inordinate speed-up. More to the point, if you know what you're doing, you can use the low-level functions +INTERNAL-CHAR-N and +INTERNAL-RPLACHAR-N instead of CHAR and RPLACHAR for another large speedup. Still, none of these are likely to be "open-compiled" for the PDP10, since the basic targeted instructions just aren't in the PDP10 repetoire.