Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 5 Oct 87 12:41:26 EDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 248667; Mon 5-Oct-87 12:32:18 EDT Date: Mon, 5 Oct 87 12:32 EDT From: KMP@STONY-BROOK.SCRC.Symbolics.COM To: BUG-LISP@AI.AI.MIT.EDU References: <263565.871001.ZVONA@AI.AI.MIT.EDU> Message-ID: <871005123222.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> [The referenced message has been redirected: Correcting "Bug-Lisp" -> "Bug-LispM" BUG-LISP@AI.AI.MIT.EDU has been removed; BUG-LISPM@AI.AI.MIT.EDU has been added.]  Date: Thu, 1 Oct 87 23:39:03 EDT From: David Chapman To: BUG-LISP@AI.AI.MIT.EDU Message-ID: <263567.871001.ZVONA@AI.AI.MIT.EDU> Oops, that was supposed to go to bug-lispm. Orry. Can someone forward it there? Thanks.  Date: Thu, 1 Oct 87 23:30:53 EDT From: David Chapman To: BUG-LISP@AI.AI.MIT.EDU Message-ID: <263565.871001.ZVONA@AI.AI.MIT.EDU> When I CFTP to REAGAN and get a directory listing, it comes out in a completely random order, which is difficult to work with. It should be sorted alphabetically like other ftp directory listings are. (This is cftping from an ITS; I can't tell you what version of Genera REAGAN is running, because I'm in California.)  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 6 May 87 00:13:04 EDT Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 6 MAY 87 00:12:05 EDT Received: from EDDIE.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 6 May 87 00:11-EDT Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id ; Wed, 6 May 87 00:09:36 EDT Received: by media-lab.MIT.EDU (5.54/4.8) id AA08364; Wed, 6 May 87 00:09:19 EDT Date: Wed, 6 May 87 00:09:19 EDT From: Jim Davis Message-Id: <8705060409.AA08364@media-lab.MIT.EDU> To: bug-lisp@oz Subject: CL file-position ignores byte size In Symbolics 3650 Release 6.G, IP-TCP 29.13, Experimental Local Fixes 1.0, Versatec 9.0, Spire 17.2, Experimental DECTALK 1.1, Experimental DICTIONARY 2.0, BROWN 1.0, Experimental SPELL 2.0, Experimental Prose 2000 Speech Synthesizer 3.0, Experimental Segmentation Editor 1.11, DP200 Speech Recognizer 1.0, Experimental Streets 1.0, Experimental Route Finder 1.1, Experimental Location 1.0, Experimental Route Describer 1.0, Experimental Direction Assistance Toplevel 1.4, Experimental Direction Assistance 1.0, Experimental ASSP 2.0, microcode NBS-COL-MIC 388, on Obvious: In Rel 6.G, the CL file-position function always returns a value calculated using 8bit bytes. Thus: (setq s (open "EMS:/u2/jrd/experiment/1l1.pt" :direction :input :element-type '(unsigned-byte 16))) (dotimes (i 10) (read-byte s)) (file-position s) ==> 20 Perhaps you have fixed this in 7.1  Date: Sun, 21 Dec 86 22:34:01 EST From: Alan Bawden Subject: Gee, that's not his host's name To: RDZ@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, BUG-LISP@AI.AI.MIT.EDU In-reply-to: Msg of Sat 20 Dec 86 13:22 EST from Ramin Zabih Message-ID: <133383.861221.ALAN@AI.AI.MIT.EDU> Date: Sat, 20 Dec 86 13:22 EST From: Ramin Zabih Typing :FINGER on AI just produced this output: ... RDZ Ramin Zabih F T23 <>: 709 x8827 RDZ, Zvona (Chaos) It seems that someone is confused about the name of the 3600 I'm using... RDZ's host has a short name of "NULL". He's been expecting the name "NULL" to break some program ever since he named it that. I presume thats why he mailed this bug report to Bug-LISP. Nothing's broken actually. I was just hacking him...  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 21 Dec 86 22:15:54 EST Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 DEC 86 20:28:45 EST Received: from REAGAN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 20 Dec 86 13:25-EST Received: from NULLSTELLENSATZ.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 16312; Sat 20-Dec-86 13:22:41 EST Date: Sat, 20 Dec 86 13:22 EST From: Ramin Zabih Subject: Gee, that's not my host's name To: bug-lisp@OZ.AI.MIT.EDU, bug-its@AI.AI.MIT.EDU Message-ID: <861220132243.9.RDZ@NULLSTELLENSATZ.AI.MIT.EDU> Typing :FINGER on AI just produced this output: -User- --Full name-- Jobnam Idle TTY -Console location- ___005 < [not logged in] HACTRN 23.T05 906 x1729 CENT, OAF KWH Ken Haase HACTRN *:**.T15 Net site PREP (Chaos) DPH Daniel Huttenlocher HACTRN 46.T16 723 x8843 Alan, DPH RDZ Ramin Zabih F T23 <>: 709 x8827 RDZ, Zvona (Chaos) It seems that someone is confused about the name of the 3600 I'm using...  Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 MAY 86 21:52:46 EDT Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 1141; Wed 7-May-86 21:50:54-EDT Date: Wed, 7 May 86 21:50 EDT From: Jonathan A Rees Subject: ubiquitous prettyprinter bug To: bug-lisp@MIT-MC.ARPA, bug-lispm@MIT-MC.ARPA cc: t-bugs@YALE.ARPA Message-ID: <860507215037.2.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU> [User input is in lower case, system output is in upper case] (defun foo (@x) `(a , @x b)) FOO (foo 'z) (A Z B) (grindef foo) (DEFUN FOO (@X) `(A ,@X B)) The pretty printer generates incorrect output for backquote forms containing , where is a variable whose name begins with the character @. A bug easily sympathized with, but a bug nonetheless. - Jonathan  Date: Mon, 21 Apr 86 20:59:31 EST From: "Christopher C. Stacy" Subject: ITS names To: BUG-LISP@MC.LCS.MIT.EDU cc: BUG-DDT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].891348.860421.CSTACY> (STATUS HSNAME 'PINTO 'MX) gives an ILOPR on MC, a DDT BUG on AI or MX.  Date: Wed, 5 Feb 86 17:57:47 EST From: Jonathan A Rees Subject: ALLFILES behavior To: BUG-LISP@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].808858.860205.JAR> In Maclisp 2138 on ITS: Small bug in the Pitmanual (page 215): PROBEF understands >, while ALLFILES doesn't.  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 13 OCT 85 06:08:40 EDT Date: Sun 13 Oct 85 06:06:34-EDT From: "Mike Lupin" To: COLE%MIT-OZ@MIT-MC.ARPA cc: Lisp%MIT-OZ@MIT-MC.ARPA Message-ID: <12150746965.29.GZT.LUPIN@MIT-OZ> What is up.. I've decided to learn Lisp. Where is the documentation hidden?? I found <1d.historicial> It was full of lisp docs. If you can get them on line for me I would love it. I just want to print them And your right this system IS 10 TIMES BETTER than my schools!! well later.... Lupin. (mike) -------  Date: Mon, 29 Jul 85 22:16:22 EDT From: David Vinayak Wallace Subject: Maclisp <> MACRO To: JPBion@SU-SUSHI.ARPA cc: BUG-MACLISP@MIT-MC.ARPA In-reply-to: Msg of Mon 29 Jul 85 16:35:36-PDT from Joel P. Bion Message-ID: <[MIT-MC.ARPA].592998.850729.GUMBY> If you want to use MIDAS (in every way more featureful than MACRO, unless, of course, you have some code already in MACRO, or already know MACRO but not MIDAS) there's documentation in INFO. MIDAS knows how to generate FASL files from your source. I doubt it would be too easy to do the same in MACRO, but FASL format is documented in MC:.INFO.; if you're really curious.  Received: from SU-SUSHI.ARPA by MIT-MC.ARPA 29 Jul 85 19:40:29 EDT Date: Mon 29 Jul 85 16:35:36-PDT From: Joel P. Bion Subject: Maclisp <> MACRO To: Bug-Maclisp@MIT-MC.ARPA Is there any documentation on Maclisp interfacing with MACRO? Joel -------  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 24 JUN 85 20:49:27 EDT Received: from MIT-MC by MIT-OZ via Chaosnet; 24 Jun 85 20:50-EDT Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 24 Jun 85 20:20:26 EST Received: from BIG.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 262063; Mon 24-Jun-85 20:18:14-EDT Date: Mon, 24 Jun 85 20:19 EDT From: Charles Hornig Subject: Common Lisp defsetf To: Richard E. Zippel , BUG-LISP%OZ@MIT-MC.ARPA In-Reply-To: <850604214119.7.RZ@ZERMATT> Message-ID: <850624201934.6.HORNIG@BIG.SCRC.Symbolics.COM> Date: Tue, 4 Jun 85 21:41 EDT From: Richard E. Zippel In Symbolics 3670 Release 6.0, IP-TCP 29.0, MLSite 7.2, Mailer 43.0, Experimental Imagen Spooler 2.1, Experimental Schema 84.0, microcode TMC5-IO4-MIC 319, on Zermatt: I occasionally define a simple setf method i.e.: (cl:defsetf nth-string set-nth-string) and then define that a more complex definition is required, i.e.: (cl:defsetf nth-string (string i) (char) `(set-nth-string ,char ,string ,i)) It seems that the lt::trivial-setf-method property is not deleted when the more complex property is added and thus the most recent defsetf does not take effect. Thank you for reporting this problem. It will be fixed in a future release.  Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 11 Jun 85 12:11:26 EST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 251982; Tue 11-Jun-85 12:07:32-EDT Date: Tue, 11 Jun 85 12:09 EDT From: Kent M Pitman Subject: Timit To: MACRAK@MIT-MC.ARPA cc: BUG-LISP@MIT-MC.ARPA In-Reply-To: <[MIT-MC.ARPA].538214.850611.MACRAK> Message-ID: <850611120933.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Tue, 11 Jun 85 08:53:56 EDT From: Stavros M. Macrakis Does anyone know where to find Jonl's old Timit fnc? (timit (foobar)) => 4.566 Just times one call of foobar. Simpler than the nice package on Liblsp, but still handy. LIBLSP;BS (see LIBDOC;BS for `documentation').  Date: Tue, 11 Jun 85 08:53:56 EDT From: Stavros M. Macrakis Subject: Timit To: BUG-LISP@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].538214.850611.MACRAK> Does anyone know where to find Jonl's old Timit fnc? (timit (foobar)) => 4.566 Just times one call of foobar. Simpler than the nice package on Liblsp, but still handy.  Received: from MIT-OZ by MIT-MC via Chaosnet; 7 JUN 85 00:59:04 EDT Received: from MIT-XX by MIT-OZ via Chaosnet; 7 Jun 85 00:58-EDT Received: from SRI-AI.ARPA by MIT-XX.ARPA with TCP; Fri 7 Jun 85 00:58:22-EDT Date: Thu 6 Jun 85 21:57:11-PDT From: Scott J. Kramer Subject: Re: distribution copies To: FREEMAN@SUMEX-AIM.ARPA, GUMBY@MIT-MC.ARPA cc: MKL@SRI-CSL.ARPA, bug-maclisp%MIT-OZ@MIT-XX.ARPA In-Reply-To: Message from "Andy Freeman " of Sun 19 May 85 12:41:34-PDT Reply-To: sjk@sri-spam I have some code somewhere that implements VTS-like rubout processing and CURSORPOS in Maclisp with SFA's. I had it semi-working here, but was spending most of my time on UNIX and never fully debugged it. If there's sufficient interest, I'll leave the files somewhere on OZ after I dig them out of my archives. I originally got the code from John Ellis at Yale. You could probably use TEXTI (or...? I'm out of touch with alot of Twenex stuff lately) to implement fancy input processing if you like MIDAS. The Yale stuff seemed to work sufficiently, tho'. scott -------  Received: from MIT-XX.ARPA by MIT-MC.ARPA; 24 May 85 06:53:49 EST Return-Path: <@SU-SCORE.ARPA:DHARE@SRI-CSL.ARPA> Received: from SU-SCORE.ARPA by MIT-XX.ARPA with TCP; Fri 17 May 85 20:44:36-EDT Received: from SRI-CSL.ARPA by SU-SCORE.ARPA with TCP; Fri 17 May 85 16:35:46-PDT Date: 17 May 1985 1634-PDT From: DHARE@SRI-CSL.ARPA (Dwight Hare) Subject: Misfeature in SAVE/GET To: tops-20@SU-SCORE.ARPA cc: mkl@SRI-CSL.ARPA ReSent-Date: Fri 24 May 85 06:55:35-EDT ReSent-From: Martin David Connor ReSent-To: bug-lisp@MIT-MC.ARPA I have run into a strange problem where a page disappears through a SAVE and a GET which causes a MACLISP program to blow up. The disappearing page is empty (all zeros) and there is some code in the save jsys which implies that empty pages are not saved. Unfortunately, the GET of that saved image produces a memory map without the page being marked as existing. A reference to this page causes an ill mem ref from Maclisp (which has this error interrupt enabled for debugging purposes). It seems to me that SAVE and GET in conjunction should ensure that all existant pages are preserved through a SAVE and a GET. Does anyone know of a simple patch to fix the problem? Dwight -------  Received: from MIT-OZ by MIT-MC via Chaosnet; 19 MAY 85 15:39:28 EDT Received: from MIT-MC by MIT-OZ via Chaosnet; 19 May 85 15:37-EDT Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA; 19 May 85 15:38:42 EST Date: Sun 19 May 85 12:36:21-PDT From: Andy Freeman Subject: Re: distribution copies To: GUMBY@MIT-MC.ARPA cc: MKL@SRI-CSL.ARPA, bug-maclisp%MIT-OZ@MIT-XX.ARPA In-Reply-To: Message from "David Vinayak Wallace " of Sun 19 May 85 02:36:28-PDT (sstatus linmode t) is another alternative. It is easier to "implement", but the results aren't as good as real terminal support. (Tops-20 users expect ^W (^U) to delete the previous word (current line) and usually can delete across lines; real tenex users expect neither.) All you really get is backspace and you have to type to get maclisp to respond. -andy -------  Received: from MIT-OZ by MIT-MC via Chaosnet; 19 MAY 85 05:36:15 EDT Received: from MIT-MC by MIT-OZ via Chaosnet; 19 May 85 05:34-EDT Date: Sun, 19 May 85 05:34:21 EST From: David Vinayak Wallace Subject: distribution copies To: MKL@SRI-CSL cc: bug-maclisp@MIT-OZ In-reply-to: Msg of 19 May 1985 0110-PDT from Mark K. Lottor Message-ID: <[MIT-MC].510163.850519.GUMBY> Date: 19 May 1985 0110-PDT From: Mark K. Lottor Also, our current version of Maclisp doesn't delete characters on the screen using backspace (i.e. it echoes deleted characters). Is this something that only works right if you have a VTS% jsys or do we just have Maclisp terminal types compiled in wrong? You need to have vts. If you really feel up to hacking ttytypes, fix the code for CURSORPOS and RUBOUT in *LISP (but don't eat a big lunch beforehand!). Now that twenex TECO has a seperate TECTRM file, perhaps MACLISP could be tought to use the same thing? It would cost a couple of pages, I think. david  Received: from MIT-OZ by MIT-MC via Chaosnet; 19 MAY 85 04:16:05 EDT Received: from MIT-MC by MIT-OZ via Chaosnet; 19 May 85 04:14-EDT Received: from SRI-CSL.ARPA by MIT-MC.ARPA; 19 May 85 04:15:04 EST Date: 19 May 1985 0110-PDT From: Mark K. Lottor Subject: distribution copies To: bug-maclisp%oz@MIT-MC.ARPA Where can the standard maclisp distribution stuff be found? Also, our current version of Maclisp doesn't delete characters on the screen using backspace (i.e. it echoes deleted characters). Is this something that only works right if you have a VTS% jsys or do we just have Maclisp terminal types compiled in wrong? Mark -------  Date: Thu, 16 May 85 01:22:16 EST From: Glenn S. Burke Subject: EXEC/MACLISP interface problem To: BUG-LISP@MIT-MC Message-ID: <[MIT-MC].505500.850516.GSB> For whatever it's worth at this date, i thought that when we generated the first "new" maclisp this was put into the code. Or maybe i had put it into the source and it got dyked out or something?  Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA; 10 May 85 19:57:07 EST Date: Fri 10 May 85 16:55:34-PDT From: Peter Weyhrauch Subject: EXEC/MACLISP interface problem To: alan@MIT-MC.ARPA cc: bug-lisp@MIT-MC.ARPA, gjc@MIT-MC.ARPA, zzz.d@SU-SCORE.ARPA, kmp@SCRC-STONY-BROOK.ARPA Thanks to the original author of the MIDAS program also, whoever that may be. Dan Blom -------  Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 8 MAY 85 13:28:11 EDT Date: Wed, 8 May 1985 10:27 PDT Message-ID: From: "Leonard N. Zubkoff" To: "Daniel S. Blom" Cc: BUG-LISP@MIT-MC.ARPA, ZZZ.D@SU-SCORE.ARPA Subject: EXEC/MACLISP interface problem In-reply-to: Msg of 7 May 1985 14:01-PDT from Daniel S. Blom Dan, I used the following fix for this problem in MacLisp at CMU. Specifically, the Ssave% Jsys does not save zero pages. This is not normally a problem, as the monitor creates them again when you first access them. MacLisp, however, enables the page creation interrupt and when an interrupt occurs, it checks to see if the page was created explicitly by a SETMM instruction. If not, it gives an illegal memory reference. There are two simple ways to disable the interrupt; we've been running with it off for years now and know of no interesting problems it has missed. If you build your MacLisp from source, you can change the interrupt channel mask given to the Aic% Jsys to leave page creation .IcNxp turned off. Otherwise, just patch location INTNXP to a Debrk%. I needed this when doing the debugger/coldloader for the Spice Lisp Virtual Machine on the 20; it used extended addressing and MacLisp would die after getting page creation interrupts for pages in extended memory. Leonard  Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA; 8 MAY 85 13:18:47 EDT Date: Wed 8 May 85 10:18:03-PDT From: Daniel S. Blom Subject: Re: EXEC/MACLISP interface problem Sender: PWEYHRAUCH@SUMEX-AIM.ARPA To: GUMBY@MIT-MC.ARPA cc: ALAN@MIT-MC.ARPA, BUG-LISP@MIT-MC.ARPA, GJC@MIT-MC.ARPA, zzz.d@SU-SCORE.ARPA, KMP@SCRC-STONY-BROOK.ARPA Reply-To: PWEYHRAUCH@SUMEX-AIM.ARPA In-Reply-To: Message from "David Vinayak Wallace " of Wed 8 May 85 09:46:28-PDT Thanks. The MIDAS program works just fine. The problem is solved. Thank you all for your help. Dan Blom -------  Date: Wed, 8 May 85 12:44:34 EST From: David Vinayak Wallace Subject: EXEC/MACLISP interface problem To: ALAN@MIT-MC cc: BUG-LISP@MIT-MC, GJC@MIT-MC, PWEYHRAUCH@SUMEX-AIM, zzz.d@SU-SCORE, KMP@SCRC-STONY-BROOK Supercedes: Msg of Wed, 8 May 85 12:29:53 EST from David Vinayak Wallace Message-ID: <[MIT-MC].491660.850508.GUMBY> Date: Tue, 7 May 85 19:34:03 EST From: Alan Bawden I don't remember ever having a fix for the page-of-zeros problem, perhaps GSB was the person who had one? I have a fix; let me dig it off backup tape. It used to screw me with HACTRN. The fix is short enough that I'll just include it here. I think it was originally written by Pat O'Donnell. Put it in a file and assemble it with MIDAS. MIDAS will produce a FASL file which you can load before dumping. You should call fix-tops-20-lossage asap after starting the saved image (i.e. before the gc or anything that might cause a page fault can run). ---- tear here ---- ;;; -*- Midas -*- its==:0 tops20==:1 title fix twenex's not saving/creating zero pages ;;; not saving them is a pretty good idea, ;;; but you should re-create them when the file is mapped in! .FASL .INSRT LISP:FASDFS.MID .ENTRY FIX-TOPS-20-LOSSAGE SUBR 0001 ; no arguments MOVEI A,.FHSLF DIR ; disable software interrupt system. SETZB D,F ; D = segment table offset, F = memory address MOVEI R,1000 ; R = loop counter (1000 pages of 1000 ; addresses. TOUCH: MOVE TT,ST(D) ; get the segment flags TLNN TT,ST.$NXM ; Skip if the page isn't supposed to exist. MOVE TT,(F) ; READ FROM THE PAGE (touch it. ; TOPS-20 will create it if it doesn't ; exist, giving us an interrupt (off). AOS D ; next page ADDI F,1000 SOJN R,TOUCH CIS ; assume we touched a NXM page. Clear ; the interrupt EIR ; reenable the interrupt system MOVEI A,.ATOM T ; return truth POPJ P, FASEND  Date: Wed, 8 May 85 12:29:53 EST From: David Vinayak Wallace Subject: EXEC/MACLISP interface problem To: ALAN@MIT-MC cc: BUG-LISP@MIT-MC, GJC@MIT-MC, PWEYHRAUCH@SUMEX-AIM, zzz.d@SU-SCORE, KMP@SCRC-STONY-BROOK In-reply-to: Msg of Tue 7 May 85 19:34:03 EST from Alan Bawden Message-ID: <[MIT-MC].491610.850508.GUMBY> Date: Tue, 7 May 85 19:34:03 EST From: Alan Bawden I don't remember ever having a fix for the page-of-zeros problem, perhaps GSB was the person who had one? I have a fix; let me dig it off backup tape. It used to screw me with HACTRN.  Date: Tue, 7 May 85 19:34:03 EST From: Alan Bawden Subject: EXEC/MACLISP interface problem cc: GJC@MIT-MC, BUG-LISP@MIT-MC, PWEYHRAUCH@SUMEX-AIM, zzz.d@SU-SCORE, KMP@SCRC-STONY-BROOK In-reply-to: Msg of Tue 7 May 85 17:42:46 EST from George J. Carrette Message-ID: <[MIT-MC].490658.850507.ALAN> I don't remember ever having a fix for the page-of-zeros problem, perhaps GSB was the person who had one?  Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA; 7 MAY 85 19:07:24 EDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232261; Tue 7-May-85 19:02:45-EDT Date: Tue, 7 May 85 19:04 EDT From: Kent M Pitman Subject: [Daniel S. Blom: Re: EXEC/MACLISP interface problem] To: BUG-LISP@MIT-MC.ARPA Message-ID: <850507190405.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Return-path: Received: from SUMEX-AIM.ARPA by SCRC-STONY-BROOK.ARPA via INTERNET with SMTP id 232258; 7 May 85 18:58:31-EDT Date: Tue 7 May 85 16:01:52-PDT From: Daniel S. Blom Subject: Re: EXEC/MACLISP interface problem Sender: PWEYHRAUCH@SUMEX-AIM.ARPA To: KMP@SCRC-STONY-BROOK.ARPA cc: zzz.d@SU-SCORE.ARPA Reply-To: PWEYHRAUCH@SUMEX-AIM.ARPA In-Reply-To: Message from "Kent M Pitman " of Tue 7 May 85 15:38:18-PDT I FTPed and tried SHARE and it too falied to save the all zero page. Its help file never makes any claims about all zero pages so I wonder if this is really a bug. It does filter out the shared pages as advertised. Thanks, Dan Blom -------  Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA; 7 MAY 85 18:36:58 EDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232239; Tue 7-May-85 18:31:43-EDT Date: Tue, 7 May 85 18:33 EDT From: Kent M Pitman Subject: Re: EXEC/MACLISP interface problem To: PWEYHRAUCH@SUMEX-AIM.ARPA cc: zzz.d@SU-SCORE.ARPA, BUG-LISP@MIT-MC.ARPA In-Reply-To: The message of 7 May 85 18:11-EDT from Daniel S. Blom Message-ID: <850507183302.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Tue 7 May 85 15:11:58-PDT From: Daniel S. Blom To: KMP@SCRC-STONY-BROOK.ARPA cc: zzz.d@SU-SCORE.ARPA Reply-To: PWEYHRAUCH@SUMEX-AIM.ARPA I can't find SHARE on our MACLISP directory. HELP SHARE on MIT-XX fails to give any information. Where should I look? I just copied [OZ]SHARE.EXE.2 to [XX]SHARE.EXE.2 and [OZ]HLP:SHARE.HLP.2 to [XX]SHARE.HLP.2 so hopefully you can get them from there now. This program is useful for dumping Lisps and has nothing to do with an after-the-fact fix to your reported problem. Also, this program only helps you dump a Lisp if you knew before you started the Lisp that you were going to want to dump it. It will not help you dump a Lisp if you've started it already without entering through the SHARE program. The program originated at Yale. If you have comments/questions about it, I think "Tools@YALE" is the right mail address to send them to. -kmp  Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA; 7 MAY 85 18:00:39 EDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232214; Tue 7-May-85 17:54:47-EDT Date: Tue, 7 May 85 17:56 EDT From: Kent M Pitman Subject: EXEC/MACLISP interface problem To: GJC@MIT-MC.ARPA cc: KMP@SCRC-STONY-BROOK.ARPA, BUG-LISP@MIT-MC.ARPA, PWEYHRAUCH@SUMEX-AIM.ARPA, zzz.d@SU-SCORE.ARPA In-Reply-To: <[MIT-MC].490476.850507.GJC> Message-ID: <850507175608.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Tue, 7 May 85 17:42:46 EST From: George J. Carrette You dont really need any more context, this ZERO page problem is a known maclisp problem when using the EXEC SAVE command. As I recall GSB or ALAN had a work-around or perhaps a fix. You might also tell people about the SHARESAVE command (or whatever it is called) from Yale. Its useful enought that it should be included with tops-20 maclisp distributions. The program is SHARE.EXE. On MIT machines, it's available in the default search rules and HELP SHARE tells how to use it. I seem to remember that it does go out in distributions (or that we'd at least been thinking about sending it out for years) so it might already be there, but if it's not we could put it someplace where it can be FTP'd.  Date: Tue, 7 May 85 17:42:46 EST From: George J. Carrette Subject: EXEC/MACLISP interface problem To: KMP@SCRC-STONY-BROOK cc: BUG-LISP@MIT-MC, PWEYHRAUCH@SUMEX-AIM, zzz.d@SU-SCORE In-reply-to: Msg of Tue 7 May 85 16:55 EDT from Kent M Pitman Message-ID: <[MIT-MC].490476.850507.GJC> You dont really need any more context, this ZERO page problem is a known maclisp problem when using the EXEC SAVE command. As I recall GSB or ALAN had a work-around or perhaps a fix. You might also tell people about the SHARESAVE command (or whatever it is called) from Yale. Its useful enought that it should be included with tops-20 maclisp distributions.  Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA; 7 MAY 85 17:30:36 EDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232179; Tue 7-May-85 17:25:55-EDT Date: Tue, 7 May 85 17:27 EDT From: Kent M Pitman Subject: [Daniel S. Blom: Re: EXEC/MACLISP interface problem] To: BUG-LISP@MIT-MC.ARPA Message-ID: <850507172716.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Return-path: Received: from SUMEX-AIM.ARPA by SCRC-STONY-BROOK.ARPA via INTERNET with SMTP id 232170; 7 May 85 17:17:22-EDT Date: Tue 7 May 85 14:21:06-PDT From: Daniel S. Blom Subject: Re: EXEC/MACLISP interface problem Sender: PWEYHRAUCH@SUMEX-AIM.ARPA To: KMP@SCRC-STONY-BROOK.ARPA cc: zzz.d@SU-SCORE.ARPA Reply-To: PWEYHRAUCH@SUMEX-AIM.ARPA In-Reply-To: Message from "Kent M Pitman " of Tue 7 May 85 14:03:44-PDT So you did get my message. I got something from Mailer@SRI-AI that said my message "failed." So I sent it again. Sorry if you got two copies. FOL is a proof checker written entirely in a LISP-like language that sits on top of MACLISP (right now), implemented by macros. It's running interpreted entirely now. I don't know how the all zero page is created, but it's there just after loading all the FOL files. -------  Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA; 7 MAY 85 17:03:34 EDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232146; Tue 7-May-85 16:54:36-EDT Date: Tue, 7 May 85 16:55 EDT From: Kent M Pitman Subject: EXEC/MACLISP interface problem To: PWEYHRAUCH@SUMEX-AIM.ARPA, bug-lisp@MIT-MC.ARPA cc: zzz.d@SU-SCORE.ARPA In-Reply-To: The message of 7 May 85 16:49-EDT from Daniel S. Blom Message-ID: <850507165556.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Tue 7 May 85 13:49:34-PDT From: Daniel S. Blom Subject: EXEC/MACLISP interface problem Sender: PWEYHRAUCH@SUMEX-AIM.ARPA To: bug-lisp@MIT-MC.ARPA cc: zzz.d@SU-SCORE.ARPA Reply-To: PWEYHRAUCH@SUMEX-AIM.ARPA I am having this problem with the FOL program. What happens is an all zero page is created by MACLISP but not saved by the EXEC SAVE (or CSAVE) command. After the saved program is loaded into core with GET, the non-zero page isn't in the map. After actually starting the program with the START command, when MACLISP tries to write on that page, it prints (if enabled--FOL usually traps errors itself using ERRSET) a memory protection violation message and signals an ERRSET trappable error. The systems person I talked to here (MRC) suggested I complain to this mailbox. What do you suggest? Thanks Dan Blom ------- What is the FOL program? I think we need more context.  Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA; 7 MAY 85 17:02:37 EDT Date: Tue 7 May 85 14:01:35-PDT From: Daniel S. Blom Subject: EXEC/MACLISP interface problem Sender: PWEYHRAUCH@SUMEX-AIM.ARPA To: BUG-LISP@MIT-MC.ARPA cc: ZZZ.D@SU-SCORE.ARPA Reply-To: PWEYHRAUCH@SUMEX-AIM.ARPA I am having this problem with the FOL program. What happens is an all zero page is created by MACLISP but not saved by the EXEC SAVE (or CSAVE) command. After the saved program is loaded into core with GET, the non-zero page isn't in the map. After actually starting the program with the START command, when MACLISP tries to write on that page, it prints (if enabled--FOL usually traps errors itself using ERRSET) a memory protection violation message and signals an ERRSET trappable error. The systems person I talked to here (MRC) suggested I complain to this mailbox. What do you suggest? Thanks Dan Blom -------  Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA; 7 MAY 85 16:50:16 EDT Date: Tue 7 May 85 13:49:34-PDT From: Daniel S. Blom Subject: EXEC/MACLISP interface problem Sender: PWEYHRAUCH@SUMEX-AIM.ARPA To: bug-lisp@MIT-MC.ARPA cc: zzz.d@SU-SCORE.ARPA Reply-To: PWEYHRAUCH@SUMEX-AIM.ARPA I am having this problem with the FOL program. What happens is an all zero page is created by MACLISP but not saved by the EXEC SAVE (or CSAVE) command. After the saved program is loaded into core with GET, the non-zero page isn't in the map. After actually starting the program with the START command, when MACLISP tries to write on that page, it prints (if enabled--FOL usually traps errors itself using ERRSET) a memory protection violation message and signals an ERRSET trappable error. The systems person I talked to here (MRC) suggested I complain to this mailbox. What do you suggest? Thanks Dan Blom -------  Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA; 5 MAY 85 19:47:36 EDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 230447; Sun 5-May-85 19:45:19-EDT Date: Sun, 5 May 85 19:44 EDT From: Kent M Pitman Subject: MDC.WAYNE: "list" command To: Bug-LISP@MIT-MC.ARPA Message-ID: <850505194427.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I sent MDC.WAYNE some mail suggesting he find out about MAPATOMS, BOUNDP, FBOUNDP, MAKNUM, MUNKAM, and such ...  Received: from MIT-OZ by MIT-MC via Chaosnet; 5 MAY 85 02:17:49 EDT Date: Sun 5 May 85 02:18:12-EDT From: Wayne McGuire Subject: "list" command To: bug-lisp%MIT-OZ@MIT-MC.ARPA Is there a program or function somewhere on OZ which one can call in Lisp, and which will generate an alphabetical list of the names of all defined Lisp functions currently in RAM, and their byte size? -------  Received: from MIT-OZ by MIT-MC via Chaosnet; 26 MAR 85 10:11:09 EST Date: Tue 26 Mar 85 10:09:53-EST From: Bob Hall Subject: Re: mapcan and get To: bug-lisp%MIT-OZ@MIT-MC.ARPA In-Reply-To: Message from "Kent M Pitman " of Sun 24 Mar 85 18:13:49-EST This is to thank kmp,gjc, and alan who have pointed out the error in my thinking. My misconception arose from a too-hasty reading of Winston's book (I didn't read the all important footnote on p.83). Thanks for taking the time. -- Bob -------  Date: 24 March 1985 16:14-EST From: Alan Bawden Subject: mapcan and get To: RJH @ MIT-OZ cc: BUG-LISP @ MIT-MC In-reply-to: Msg of Sat 23 Mar 85 17:19:48-EST from Bob Hall Your bug report doesn't say what you think the problem is. The expected behavior, given that MAPCAN calls NCONC to put together it's answer, is that after the first time you call MAPCAN-TEST you have clobbered the A and B properties of RIGHT. The second time you call MAPCAN-TEST the answer is thus a circular list that prints: "(D E E F E F E F E F E F E F ...)". If you observe some -other- behavior, you should send a more complete bug report. If you find -this- behavior confusing, you need to understand side effects in Lisp better.  Received: from MIT-OZ by MIT-MC via Chaosnet; 24 MAR 85 15:23:14 EST Received: from MIT-MC by MIT-OZ via Chaosnet; 24 Mar 85 15:22-EST Date: 24 March 1985 15:22-EST From: David Vinayak Wallace Subject: mapcan and get To: bug-lisp @ MIT-OZ In-reply-to: Msg of Sat 23 Mar 85 17:19:48-EST from Bob Hall Date: Sat 23 Mar 85 17:19:48-EST From: Bob Hall ; Dear bug-lisp: ; Do you know about the failure of mapcan when used with get? He's going to report the DELQ bug next.  Received: from MIT-OZ by MIT-MC via Chaosnet; 23 MAR 85 20:27:59 EST Received: from MIT-MC by MIT-OZ via Chaosnet; 23 Mar 85 20:26-EST Date: 23 March 1985 20:27-EST From: George J. Carrette Subject: mapcan and get To: RJH @ MIT-OZ cc: bug-lisp @ MIT-OZ In-reply-to: Msg of Sat 23 Mar 85 17:19:48-EST from Bob Hall I think you want (defun mapcan-test (l) (mapcan #'(lambda (x) (append (get 'right x) nil)) l)). Think about it.  Received: from MIT-OZ by MIT-MC via Chaosnet; 23 MAR 85 17:43:49 EST Date: Sat 23 Mar 85 17:19:48-EST From: Bob Hall Subject: mapcan and get To: bug-lisp%MIT-OZ@MIT-MC.ARPA ; Dear bug-lisp: ; Do you know about the failure of mapcan when used with get? ; To see what happens, load the following file. ; Just an example. (setf (get 'right 'a) '(d e)) (setf (get 'right 'b) '(e f)) (setf (get 'right 'c) '(e f)) (setq l '(a b c)) (setq r '(d e f)) ;;;;; (defun mapcan-test (l) (mapcan '(lambda (x) (get 'right x)) l)) ; Now do the following twice (after loading this file). ; (mapcan-test l) ; (mapcan-test l) ; Weird, huh? Thanks, Bob. -------  Date: 22 February 1985 15:13-EST From: Alan Bawden Subject: Array Bug To: MDC.WAYNE @ MIT-OZ cc: BUG-LISP @ MIT-MC In-reply-to: Msg of Fri 22 Feb 85 05:41:34-EST from Wayne McGuire Date: Fri 22 Feb 85 05:41:34-EST From: Wayne McGuire To: bug-lisp at OZ Re: Array Bug Typing in Lisp (array image T 1024 1024) (store (image 314 271) 88) produces an error code. Why? Are the numbers in this bug report decimal or octal? If they are decimal (as I suspect they must be because of the "88") then the answer is: Because an array with 1024^2 elements is bigger than can fit in the address space of a PDP10. Of course MacLisp should signal an error at the time you ask for an array so impossibly big, rather than trashing your lisp world, perhaps that might get fixed. If they are in octal then the answer is that there is a bug (that I just fixed in the source) in the routine that STORE uses to determine the size of an array. These lines are from page 75 of the first edition of Winston's and Horn's _Lisp_. Really? I guess they never tried it in MacLisp.  Date: Fri 22 Feb 85 05:41:34-EST From: Wayne McGuire Subject: Array Bug To: bug-lisp%MIT-OZ@MIT-MC.ARPA Typing in Lisp (array image T 1024 1024) (store (image 314 271) 88) produces an error code. Why? These lines are from page 75 of the first edition of Winston's and Horn's _Lisp_. -------  Date: Wed, 6 Feb 1985 14:25 EST Message-ID: From: EB%MIT-OZ@MIT-MC.ARPA To: Bug-Lisp%MIT-OZ@MIT-MC.ARPA Subject: the infamous ;NNNNN NOT ASCII VALUE As has been reported many times, typing ^Z at Tops-20 Maclisp often causes the above error when Lisp is continued. The following user-level fix appears to get around the problem: (sstatus ttyint #^Z '(lambda n (quit)))  Date: 11 January 1985 20:05-EST From: Alan Bawden Subject: Playing silly games with COMPLR To: wade @ SU-WHITNEY cc: BUG-MACLISP @ MIT-MC, JonL.pa @ XEROX In-reply-to: Msg of 11 Jan 85 16:08 PST from JonL.pa at XEROX.ARPA Even the most recent version of COMPLR exhibits this problem. Although I have been fixing the occasional bug in the MacLisp system, I have not been doing anything to fix problems with COMPLR itself. All I can offer is advice on dealing with the problem. My best guess is that COMPLR is specifically confused about the nature of the value of the variable N in the code (+ n (if (eq thing n) 1 -1) ...). If N really is a fixnum suitable as an argument to the + function, then it is unlikely that using EQ to compare it to something else will be useful. COMPLR likes to theorize like this about quantities that it thinks are fixnums in order to perform clever optimizations. If you violate certain assumptions it makes about fixnums, you can confuse it. One of these assumptions is that you will never care about the the EQness of fixnums. The best way to get around problems like this is (I hate to tell you) to rewrite your code in some trivial way in order to fool COMPLR into not thinking about whatever it was that confused it. For example, I rewrote your code to be (defun foo (n) (if n nil (let ((thing 'black)) (let ((qaz (if (eq thing n) 1 -1)) (wsx (if (eq thing (if (eq n 'z) 'a 'b)) 1 -1))) (foo (+ n qaz wsx)))))) and it compiled just fine.  Received: from Riesling.ms by ArpaGateway.ms ; 11 JAN 85 16:08:40 PST Date: 11 Jan 85 16:08 PST From: JonL.pa@XEROX.ARPA Subject: [Wade Hennessey : maclisp compiler error] To: wade@SU-WHITNEY.ARPA cc: BUG-MACLISP@MIT-MC.ARPA, JonL.pa@XEROX.ARPA This looks like a legitmate bug, but it's been nearly three years since I've been maintaining MacLisp. I had thought all those compiler messages said something more rational, like "Call a MacLisp maintainer"; but either you are using a very old version, or one of messages got missed at conversion time. -- JonL -- ----- Begin Forwarded Messages ----- Return-Path: <@MIT-MC:wade@Whitney> Received: from MIT-MC (MIT-MC.ARPA) by Xerox.ARPA ; 08 JAN 85 22:37:46 PST Date: 7 Jan 85 21:47 PST From: Wade Hennessey Subject: maclisp compiler error To: jonl@MIT-MC.ARPA Message-Id: <85/01/07 2147.590@Whitney> I seem to have hit a bug in the maclisp compiler : [PHOTO: Recording initiated Mon 7-Jan-85 9:45PM] @type error.lsp (defun foo (n) (if n nil (let ((thing 'black)) (foo (+ n (if (eq thing n) 1 -1) ;chg thing to 'crazy and it works (if (eq thing (if (eq n 'z) 'a 'b)) 1 -1)))))) @complr LISP COMPILER 1121 [in LISP 2122] _error (COMMENT **ERROR** NIL No type for COMCOND in function FOO) ;%%%%%%%% COMPILER ERROR - CALL JONL %%%%%%%% ;BKPT BARF @reset complr @type fix.lsp (defun foo (n) (if n nil (let ((thing 'black)) (foo (+ n (if (eq 'crazy n) 1 -1) ;chg thing to 'crazy and it works (if (eq thing (if (eq n 'z) 'a 'b)) 1 -1)))))) @complr LISP COMPILER 1121 [in LISP 2122] _fix _ @type fix.unfasl '(THIS IS THE UNFASL FOR ((LOTSA |W.WADE|) FIX LSP /1)) '(ASSEMBLED BY FASLAP /392) '(COMPILED BY LISP COMPILER /935 COMAUX /25 PHAS1 /83 MAKLAP /80 INITIA /116) ;COMPILED ON JANUARY 7, 1985, AT 9:45 PM (COMMENT **FASL** 0. (LAP FOO SUBR)) (COMMENT **FASL** TOTAL = 31. WORDS) @pop [PHOTO: Recording terminated Mon 7-Jan-85 9:46PM] Is this really a bug, or have a done something wrong? Or is this just an old version of the compiler? ----- End Forwarded Messages -----  Date: 10 January 1985 18:12-EST From: Stavros M. Macrakis Subject: MACRAK's SUBLIS problems To: KMP @ MIT-MC, ALAN @ MIT-MC cc: BUG-LISP @ MIT-MC, JPG @ MIT-MC, WGD @ MIT-MC In-reply-to: Msg of 9 Jan 1985 22:10-EST from Kent M Pitman Yes, Maclisp Sublis. And yes, I know the implementation of Sublis, and I know its problems. On the other hand, I didn't feel like fixing them for myself. As it happens, my application doesn't need the fast lookup property of Sublis so much as the minimal copying, which puts me in a Catch-22, because you can't catch out-of-cells traps when the copying becomes excessive! Now we all know that Macsyma's out-of-cells trap function does not in fact screw up property lists, so if Macsyma would suppress ^A and ^B interrupts during the trap, Sublis could be un-Nointerrupt'ed.... In short, Sublis is an incredible crock, I use it because it's handy, it gives my code an obscure bug, I'm unwilling to fix it, and it's probably not worth anyone else's time to fix it either unless PDP-10 Maclisp is expected to last for many years longer.  Date: 9 January 1985 22:10-EST From: Kent M Pitman Subject: MACRAK's SUBLIS problems To: MACRAK @ MIT-MC cc: ALAN @ MIT-MC, BUG-LISP @ MIT-MC, JPG @ MIT-MC, WGD @ MIT-MC You are talking about Maclisp SUBLIS and not Macsyma's, right? (Just making sure, since the Macsyma version uses a similar "strategy" to that used by Lisp but may or may not have the same interrupt troubles.)  Date: 9 January 1985 21:50-EST From: Alan Bawden Subject: SUBLIS To: MACRAK @ MIT-MC cc: BUG-LISP @ MIT-MC, JPG @ MIT-MC, WGD @ MIT-MC In-reply-to: Msg of 9 Jan 1985 20:28-EST from Stavros M. Macrakis Well, the way SUBLIS works is a fantastic joke. SUBLIS is uninterruptible because it puts temporary SUBLIS properties on all of the symbols being substituted for, and it wants to be sure to get them off before anyone looks. Unless the alist argument to SUBLIS is very long, this efficiency hack probably doesn't buy much, so if SUBLIS is causing problems, a reasonable fix might be to simply roll your own sublis-like function. I'll even LAP up a version of SUBLIS for you all, if the extra efficiency that might gain is deemed desirable.  Date: 9 January 1985 20:28-EST From: Stavros M. Macrakis To: JPG @ MIT-MC, WGD @ MIT-MC cc: BUG-LISP @ MIT-MC By the way, SimpEval and SyntaxEv work on f[x]:= type functions as well as f(x):= ones. The only queerness is that the partial results are partially evaluated, e.g. w[x] := w[x-1]*x+1; SimpEval(w[2],w); => 5, but w[2] => 2*w[1]+1 (after the simpeval, of course) There appears to be a bug in Sublis such that if you run out of space in the middle, it causes `too many deferred interrupts' and dies. It doesn't like being interrupted, not even to let you allocate more space. This is pretty screwy, but is anyone maintaining MacLisp to the point of wanting to bother to repair this? It comes up with large SimpEval's occasionally.  Date: 6 December 1984 13:47-EST From: Alan Bawden Subject: GC To: KMP @ MIT-MC, RLB @ SCRC-TENEX cc: BUG-LISP @ MIT-MC, DJB @ MIT-OZ In-reply-to: Msg of 5 Dec 1984 14:08-EST from Kent M Pitman Date: 5 December 1984 14:08-EST From: Kent M Pitman Date: Wednesday, 5 December 1984, 10:32-EST From: Richard L. Bryan Date: Sat 1 Dec 84 19:28:31-EST From: Dave Braunegg I got the error message GC CALLED FROM ALLOC - LOSE, LISP IS DEAD Doesn't that happen if you have an init file that doesn't start with (COMMENT ...) ? Yes, it does. In fact, I've never seen it for any other reason. After all, as far as I know, only the startup ALLOC can give that message and he couldn't be typing expressions before he was out of ALLOC so my guess is he must have meant this was somewhere in an init file. I checked his init file. He has none.... When I looked he had a perfectly ordinary init file whose first form was (COMMENT). However DJB informas me that at the time of the lossage his init file was offline! I'm sure we can all think of interesting effects that that might have had... [ Aside to KMP: I note that the new MacLisp manual doesn't say anything about init files or what they must/can contain. ]  Received: from SCRC-STONY-BROOK by MIT-OZ via Chaosnet; 5 Dec 84 11:49-EST Received: from SCRC-SUDBURY by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 138109; Wed 5-Dec-84 10:31:21-EST Date: Wednesday, 5 December 1984, 10:32-EST From: Richard L. Bryan Subject: GC To: ALAN at MIT-MC, DJB at MIT-OZ cc: bug-lisp at MIT-OZ In-Reply-To: The message of 4 Dec 84 13:29-EST from Alan Bawden Message-ID: <841205103259.7.RLB@SUDBURY.SCRC.Symbolics.COM> Date: 4 December 1984 13:29-EST From: Alan Bawden Date: Sat 1 Dec 84 19:28:31-EST From: Dave Braunegg When trying to run LISP, I (SETQ BASE 10. IBASE 10.), then did a fixed-point division. When I then tryed a floating-point division, I got the error message GC CALLED FROM ALLOC - LOSE, LISP IS DEAD This happened several times. What is wrong? Well, of course this doesn't happen for me as you describe it, but probably that is because there is something you aren't telling me that you don't think is important. If you send be a PHOTO of a -complete- session with MacLisp in which this happens, perhaps we can figure it out. Doesn't that happen if you have an init file that doesn't start with (COMMENT ...) ?  Received: from MIT-MC by MIT-OZ via Chaosnet; 4 Dec 84 13:40-EST Date: 4 December 1984 13:29-EST From: Alan Bawden Subject: GC To: DJB @ MIT-OZ cc: bug-lisp @ MIT-OZ In-reply-to: Msg of Sat 1 Dec 84 19:28:31-EST from Dave Braunegg Date: Sat 1 Dec 84 19:28:31-EST From: Dave Braunegg When trying to run LISP, I (SETQ BASE 10. IBASE 10.), then did a fixed-point division. When I then tryed a floating-point division, I got the error message GC CALLED FROM ALLOC - LOSE, LISP IS DEAD This happened several times. What is wrong? Well, of course this doesn't happen for me as you describe it, but probably that is because there is something you aren't telling me that you don't think is important. If you send be a PHOTO of a -complete- session with MacLisp in which this happens, perhaps we can figure it out.  Date: Sat 1 Dec 84 19:28:31-EST From: Dave Braunegg Subject: GC To: bug-lisp%MIT-OZ@MIT-MC.ARPA When trying to run LISP, I (SETQ BASE 10. IBASE 10.), then did a fixed-point division. When I then tryed a floating-point division, I got the error message GC CALLED FROM ALLOC - LOSE, LISP IS DEAD This happened several times. What is wrong? Dave -------  Date: 10 October 1984 23:30-EDT From: Alan Bawden Subject: ^@ To: KMP @ MIT-MC cc: BUG-LISP @ MIT-MC, GZ @ MIT-MC In-reply-to: Msg of 10 Oct 1984 18:39-EDT from Kent M Pitman Yup. I remember that the screws involving ^@ were even worse before HIC arrived on the scene. Basically, ^@ isn't in the MacLisp character set.  Date: 10 October 1984 18:39-EDT From: Kent M Pitman To: ALAN @ MIT-MC, GZ @ MIT-MC cc: BUG-LISP @ MIT-MC The problem of || isn't the worst of it. Consider the case of |/^@|, |/^@/^@|, ... Also, notice the printer bug that makes |A/^@/^@/^@/^@B| print funny. ie, (EQ '|A/^@/^@/^@/^@| 'A) => T but (EQ '|A/^@/^@/^@/^@B| 'AB) => NIL ;thank goodness These little misfeatures have been known a long time and lots of silly code exists to handle them (user and system), so I wouldn't advocate changing them. But I'd file them away to study before playing the Programming Languages Edition of Trivial Pursuit.  Date: 10 October 1984 13:02-EDT From: Alan Bawden Subject: || To: GZ @ MIT-MC cc: BUG-LISP @ MIT-MC In-reply-to: Msg of 10 Oct 1984 04:45-EDT from Gail Zacharias Date: 10 October 1984 04:45-EDT From: Gail Zacharias So which is right representation of ||? Well I'm pretty sure I have seen code in MacLisp that -knows- that the printname list of a symbol is always at least one element long, so I would have to say that (0) is the right answer. This is what READ (another authority on building symbols) gives you when you type "||", so PNPUT in in the minority. Since PNPUT is such a low-level kludge (on the LispMachine it would be spelled "%PNPUT"...) I would have to say that you are simply violating its contract if you give it a zero-length list.  Date: 10 October 1984 04:45-EDT From: Gail Zacharias Subject: || To: BUG-LISP @ MIT-MC (setq x (pnput () T)) || (eq x (pnput () T)) T (setq y (implode ())) || (eq y (implode ())) T (eq x y) NIL ;That's right, you guessed it: (pnget x 7) NIL (pnget y 7) (0) So which is right representation of ||?  Date: 7 October 1984 16:59-EDT From: Gail Zacharias Subject: GETCOR To: BUG-LISP @ MIT-MC How come GETCOR is not available on twenex? I.e. FASDFS defines it under IFN ITS. But in the source it is under IFN PAGING, and it seems to work ok in fact. (It seems that just doing .GLOBAL GETCOR doesn't work, which is why I'm reporting it... I guess it needs to be put in some table or something).  Date: Sun 23 Sep 84 22:18-EDT From: Ed Barton Subject: cursorpos broken on batch jobs To: bug-lisp@MIT-OZ (CURSORPOS 'C) gives ;I/O ERROR DURING OUTPUT in a batch job. Why doesn't it just return NIL? Is there any way to prevent this error from happening every time I try to run a batch LISP job that has a FORMAT ~| somewhere deep in the guts of the program?  Date: 23 September 1984 16:52-EDT From: Kent M Pitman Subject: m-F in LEDIT To: Mellis @ MIT-EECS cc: BUG-MACLISP @ MIT-MC In-reply-to: Msg of Sun 23 Sep 1984 06:05 EDT from Adam G. Mellis Date: Sun, 23 Sep 1984 06:05 EDT From: Adam G. Mellis According to ledit.doc, ^R LEDIT Find Function is bound to M-F, yet this function isn't in the ledit library (and M-F is bound to ^R Forward Word). What happened to M-F? In fact, this is sort of an Emacs issue, not a Maclisp issue, but I looked it up in the source to the Emacs LEDIT library anyway. The answer is that ^R LEDIT Find Function does not get put on any key. Probably someone found that having meta-F not do the normal cursor motion command was too confusing. If you want it on a key, you should set it up yourself as a personal customization in your EMACS.VARS file. I guess I recommend putting it on some other key than m-F, though. Perhaps c-m-. would be a good choice. -kmp  Date: Sun, 23 Sep 1984 06:05 EDT Message-ID: Sender: T.MELLIS%MIT-EECS@MIT-MC.ARPA From: "Adam G. Mellis" Subject: M-F To: bug-lisp@MIT-MC According to ledit.doc, ^R LEDIT Find Function is bound to M-F, yet this function isn't in the ledit library (and M-F is bound to ^R Forward Word). What happened to M-F? Adam  Date: Thu, 13 Sep 1984 23:27 EDT Message-ID: From: BERWICK.PILATO%MIT-OZ@MIT-MC.ARPA To: bug-lisp%MIT-OZ@MIT-MC.ARPA Dear anonymous aardvark, Here is a Maclisp bug, unless I'm doing something wrong. The problem is with pushing an item onto an array location when some arguments are atomic and others aren't. Only the first evaluation of the push form works, then an argument seems to get clobbered. The interpreter fails, but not the compiler. Please find enclosed some sample code that fails, some dribble, and other debugging info that may be helpful. ;TEST.LOG (load "test.lsp")(print (status lispversion)) /2141 (defun test () (do ((my-array (*array nil t 5)) (i 0 (1+ i))) ((> i 4)) (print (push 'a (arraycall t my-array (+ i 0)))))) T (grindef test) (DEFUN TEST NIL (DO ((MY-ARRAY (*ARRAY NIL T 5)) (I 0 (1+ I))) ((> I 4)) (PRINT (PUSH 'A (ARRAYCALL T MY-ARRAY (+ I 0)))))) * (test) ;Loading SETF 293 ;Loading EXTSTR 96 ;Loading MACAID 120 ;Loading EVONCE 14 (A) ;|T..1| UNBOUND VARIABLE ;BKPT UNBND-VRBL ;debugging info -- the stack: (+INTERNAL-UBV-BREAK ((|T..1|))) |T..1| (ARRAYCALL T MY-ARRAY |T..1|) (CONS 'A (ARRAYCALL T MY-ARRAY |T..1|)) ((LAMBDA (|T..5|) (STORE (ARRAYCALL T MY-ARRAY |T..1|) |T..5|)) (CONS 'A (ARRAYCALL T MY-ARRAY |T..1|))) (PUSH 'A (ARRAYCALL T MY-ARRAY |T..1|)) (PRINT (PUSH 'A (ARRAYCALL T MY-ARRAY |T..1|))) (DO ((MY-ARRAY (*ARRAY NIL T 5)) (I 0 (1+ I))) ((> I 4)) (PRINT (PUSH 'A (ARRAYCALL T MY-ARRAY |T..1|)))) (TEST) QUIT * (grindef test) (DEFUN TEST NIL (DO ((MY-ARRAY (*ARRAY NIL T 5)) (I 0 (1+ I))) ((> I 4)) (PRINT (PUSH 'A (ARRAYCALL T MY-ARRAY |T..1|))))) * ;compiling info: ;@complr test ; ;LISP COMPILER 1128 [in LISP 2140] ; ;Loading fix-up file |OZ:CLFIX.1128.2| ;@ '(THIS IS THE UNFASL FOR ((OZ |BERWICK.PILATO|) TEST LSP /1)) '(ASSEMBLED BY FASLAP /392) '(COMPILED BY LISP COMPILER /936 COMAUX /25 PHAS1 /86 MAKLAP /80 INITIA /120) ;COMPILED ON SEPTEMBER 12, 1984, AT 5:52 AM (COMMENT **FASL** 0. (LAP TEST SUBR)) (COMMENT **FASL** TOTAL = 47. WORDS) (load "test.fasl") /2141 50726 (test) (A) (A) (A) (A) (A) NIL  Received: from Semillon.ms by ArpaGateway.ms ; 11 SEP 84 12:17:57 PDT Date: 11 Sep 84 12:17 PDT From: JonL.pa@XEROX.ARPA Subject: [MJackson.Wbst: Why Your Pascal and Modula-2 Programs Don't Work] To: Guy.Steele@CMU-CS-A.ARPA cc: Bug-Lisp@MIT-MC.ARPA,Lisp-Forum@MIT-MC.ARPA,LispCore^.pa@XEROX.ARPA Reply-to: JonL.pa@XEROX.ARPA The classic fencepost bug? ----- Begin Forwarded Messages ----- Date: Tue, 11 Sep 84 11:02 EDT From: MJackson.Wbst Subject: Why Your Pascal and Modula-2 Programs Don't Work To: AllWhimsy^.ES cc: Modula-2^.ES, ProcessTechnology^ Reply-To: MJackson.Wbst "In an array, individual elements are readily identified by means of a computed index, which represents a position in the sequence of elements. The address of the fifth element, for example, is simply the address of the first element plus five times the size of an element." -- Niklaus Wirth in the September /Scientific American/ ----- End Forwarded Messages -----  Date: Fri 31 Aug 84 17:28-EDT From: Ed Barton Subject: ;NNNNN NOT ASCII VALUE in Tops-20 Maclisp To: bug-lisp@MIT-OZ If you type ^Z at Maclisp while it is in a terminal input wait (TYIXCT), the code at CN.Z arranges for CN.ZX to contain an address to return to and then does a HALTF. Code at ALTP following the HALTF returns to the address that is stored in CN.ZX when LISP is continued. Unfortunately, CN.XZ contains TYIXCT+1 (plus some flags), so control gets past TYIXCT without any character having been read. Register 2 contains garbage. If the garbage is sufficiently random, the ;NNNNN NOT ASCII VALUE error occurs. I don't know enough about MACLISP or TOPS-20 to know what's really wrong here, but perhaps this information will allow someone else to fix the ;NNNNN NOT ASCII VALUE error. Does anyone ever make a new Maclisp?  Date: Fri 31 Aug 84 14:48-EDT From: Ed Barton Subject: ;nnnnn NOT ASCII VALUE To: bug-lisp@MIT-OZ I still get the ;nnnnnn NOT ASCII VALUE error when continuing LISP under some circumstances. I don't believe anyone ever tracked it down. However, the following apparently reproducible symptom may be related: 1. Get out of LISP with ^Z. 2. Continue LISP. 3. Type ^L. After these steps, LISP cleared the screen as expected, but also typed one or two characters (most often just ^@) of garbage that it had hallucinated during the ^Z/CONTINUE sequence.  Date: Mon, 6 Aug 1984 15:11 EDT Message-ID: From: Jerry Roylance To: GSB%MIT-OZ@MIT-MC.ARPA cc: BUG-LISP%MIT-OZ@MIT-MC.ARPA COMPLR's FOO-BYTE-EXPANDER is busted again. The fixes made in 1982 never became part of the permanent system? I reinstalled the 1127 patch for the 1128 COMPLR on OZ. Could someone make sure these changes get into the next version of COMPLR? Jerry  Date: 28 July 1984 15:26-EDT From: Alan Bawden To: BUG-LISP @ MIT-MC I don't recall if anyone has noticed this before, but I just noticed that the EOFFN for a file being read using IN cannot return a value to the caller. This is because IN is NCALLable, so the EOFFN would have to arrange to return its value as a machine number in TT, rather than as an object in A.  Date: 13 July 1984 20:35-EDT From: Pandora B. Berman Subject: help To: ANALOG.KY @ MIT-OZ cc: BUG-LISP @ MIT-MC Date: Wed 11 Jul 84 21:03:25-EDT From: ANALOG.KY%MIT-OZ@MIT-MC.ARPA Subject: help To: bboard%MIT-OZ@MIT-MC.ARPA Help... Anyone knows how to set MACLISP to work with decimal instead of octal numbers? Thanx first, you should use BUG-LISP for lisp questions; it's a more concentrated source of knowledge than the local bboards. second, if you incant (setq base 10. ibase 10.) you will get outputs written (BASE) and inputs read (IBASE) in decimal.  Date: 16 June 1984 18:01-EDT From: Alan Bawden Subject: help in setting up LISP on PREP To: DRogers @ MIT-OZ cc: BUG-LISP @ MIT-MC In-reply-to: Msg of Sat 16 Jun 84 17:08:19-EDT from David Rogers Date: Sat 16 Jun 84 17:08:19-EDT From: David Rogers Anybody wish to help me set up a LISP on PREP so that is has all the nice flavor and structure stuff? ... Unfortunately, Bug-LISP deals only with MacLisp bugs and questions. You might be lucky and hit somebody who knows about Franz anyway, but in general you have come to the wrong place. If I had to use a Lisp on a VMS Vax myself, I wouldn't go for Franz either, I would use NIL. Have you considered that possibility? (Or perhaps you are trying to bring up some code already written in Franz, or you have to transport your work to a Franz later.) BTW, when you get to bringing up the "structure stuff" please ignore my name at the front of the defstruct file. The Franz people are distributing that without my permission (they didn't even ASK me about it) and you should therefore complain to anybody but me if you find problems.  Date: Sat 16 Jun 84 17:08:19-EDT From: David Rogers Subject: help in setting up LISP on PREP To: BUG-LISP%MIT-OZ@MIT-MC.ARPA Anybody wish to help me set up a LISP on PREP so that is has all the nice flavor and structure stuff? Or does anyone have any pointers? All aid and advice would be greatly appreciated, as I am not well versed in Franz-Lisp setup issues. Thanks, David -------  Date: 12 June 1984 21:45-EDT From: Glenn S. Burke Subject: Unnamed arrays not GC'd like they should. To: REM @ SU-AI cc: BUG-LISP @ MIT-MC They get gc'ed, but not until the following gc. The consequence of this is that arrays which reference themselves circularly do not go away; however your example would have looped indefinitely if you had proceeded the gc-overflow and it had upped the space a bit more.  Date: 04 Jun 84 1143 PDT From: Robert Maas Subject: Unnamed arrays not GC'd like they should. To: BUG-LISP@MIT-MC.ARPA (This transcript collected at MIT-MC, 1984.June.04) (Bug in GC, array words not reclaimed even though array no longer referenced.) *:L LISP 2138 Alloc? N * ^D (GC) ;GC DUE TO USER ; 403[25%] LIST, 772[98%] FIXNUM, 1000[100%] FLONUM, ; 773[99%] BIGNUM, 457[29%] SYMBOL, 756[96%] ARRAY WORDS FREE ;;Note that only 244 words of array are in use NIL (STATUS GCSIZE 'ARRAY) 0 (SSTATUS GCSIZE 'ARRAY 2000) ;;Forcing it to allocate more array space T ;; before the next GC (STATUS SPCSIZE 'ARRAY) 1000 (PROG () L (SETQ AA (ARRAY NIL T 5 5)) (PRINC ".") (GO L)).............! ............... ;;Gobbling up array cells and immediately ;; disgarding them. All arrays except the ;; very last should be reclaimed by GC. ;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 3000 WORDS................! .......................................................................! .......................................................................! ............................................................. ;ADDING A NEW ARRAY SEGMENT -- ARRAY SPACE NOW 2000 WORDS..............! ....................... ;;GCSIZE working, allocated more space ;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 4000 WORDS................! .......................................................................! .......................................................................! ............................................ ;ADDING A NEW FIXNUM SEGMENT -- FIXNUM SPACE NOW 2000 WORDS............! ..... ;GC DUE TO LIST AND ARRAY SPACES ; 366[12%] LIST, 1764[98%] FIXNUM, 1000[100%] FLONUM, ; 773[99%] BIGNUM, 452[29%] SYMBOL, 2[0%] ARRAY WORDS FREE ;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 5000 WORDS ;ADDING A NEW ARRAY SEGMENT -- ARRAY SPACE NOW 3000 WORDS ;;Bug here, now that it thinks all 2000 ;; words of array space are "in use" (pointed ;; at from somewhere else) when in fact ;; only the original 244 words plus the ;; very last (25-word plus header) SETQ'd ;; array should still be "in use". ;; There should be about 1750 array words free ;; instead of zero. ;BKPT GC-OVERFLOW  Date: 4 June 1984 00:15-EDT From: Alan Bawden Subject: Hunks To: BUG-MACLISP-MANUAL @ MIT-MC, BMT @ MIT-MC cc: BUG-LISP @ MIT-MC In-reply-to: Msg of 2 Jun 1984 13:57-EDT from Barry M. Trager Date: 2 June 1984 13:57-EDT From: Barry M. Trager SUBST appears to have very strange semantics with respect to HUNKS. It appears that hunks are not descended but they are top-level copied. Is there some rationale for this behavior? It was trying to descend them and do what you would expect, but there were a couple of bugs standing in the way. I have fixed them in the source. Bug-MacLisp-Manual: While poking around for background on this bug I discovered a couple of inprovements that could be made in the manual: 1. The MAKHUNK function has a feature not ducumented in the manual. Given a list instead of a number as an argument it creates a hunk whose elements are taken from the list. (MAKHUNK (LIST A B C)) = (HUNK A B C). 2. The documentation for the HUNKP variable is a bit vague about just what it effects. The complete story is that only three functions are affected: EQUAL, PRINT, and PURCOPY. \Not/ SUBST as the documentation implies! Additionally I discovered that EQUAL, PRINT, and PURCOPY are not consistent about the order in which they check the STATUS USRHUNK function and the value of HUNKP. Since the USRHUNK stuff has never been really documented for users, and since changing the values of HUNKP (or the value of MAKHUNK) is not recommended, this isn't really important. I just record it here for posterity. 3. The "concept" entry for hunks points out that you can use the CXR 0 (CDR) of a hunk as a property list. This paragraph is a bit vague. I presume you are trying to say that GET will use the CXR 0 of a hunk as if it was a property list. If that is what you mean, then you should say so. As written, the reader might well wonder why he couldn't keep a property list in the CXR 7 slot if he wanted to.  Date: 2 June 1984 13:57-EDT From: Barry M. Trager To: BUG-LISP @ MIT-MC SUBST appears to have very strange semantics with respect to HUNKS. It appears that hunks are not descended but they are top-level copied. Is there some rationale for this behavior?  Date: 30 April 1984 17:33-EST From: Gail Zacharias Subject: DEFSTRUCT predicate option To: BUG-LISP @ MIT-MC If you use :predicate :eval-when (eval compile), the predicate gets defined as as an expr at compile time only, which is pretty useless. Any way to make it either be a macro or make it get compiled (i.e. exempt it from the overall eval-when option)?  Received: from SCH-PECOS by SCH-GILA with CHAOS; Thu 5-Apr-84 09:41:23-PST Date: Thu, 5 Apr 84 09:43 PST From: "Robert W. Kerns" Subject: How intelligent is the complr? To: "John G. Aspinall" Cc: BUG-LISP@MIT-MC.ARPA In-reply-to: The message of 4 Apr 84 10:33-PST from John G. Aspinall Message-ID: <840405094357.8.RWK@YUKON.SCRC.Symbolics> Date: 4 April 1984 13:33-EST From: John G. Aspinall I need a null function or functions that just fill a temporary hole. I need them with 0, 1 and 2 args. I would like them to be efficient. Is (defun nullfun (&rest nil) nil) the better choice, or should I define 0, 1 and 2 arg versions (defun nullfun0 () nil) (defun nullfun1 (nil) nil) (defun nullfun2 (nil nil) nil) like so. Does the complr do the smart thing with the first choice? When I compile the first version, I get a notice about an unused variable called |Lexprvar...| in the unfasl file, but I don't read LAP so I don't know whether that got into the machine code or not. Fixed-number-of-arguments functions (up to 5 arguments) use a more efficient calling sequence. Therefore, your NULLFUNn functions will be called more efficiently. Also, the generated code for a variable-number-of-arguments function is substantially slower, but this can be gotten around with a hand-coded function if really needed.  Date: 5 APR 84 15:56 PST From: JONL.PA@PARC-MAXC.ARPA Subject: Re: How intelligent is the complr? To: ALAN@MC.ARPA, JONL.PA@MC.ARPA cc: BUG-LISP@MC.ARPA, JGA@MC.ARPA, JONL.PA@PARC-MAXC.ARPA In response to the message sent 5 Apr 84 17:42 EST from ALAN@MIT-MC.ARPA SIgh, 40 usecs is indeed large -- I'd hoped to see something more like about 15 usecs on a KL10. Other possible out is, horrors, hand-coded LAP which just adjust the PDL (using value from T) and then does POPJ P,  Date: 5 April 1984 17:42-EST From: Alan Bawden Subject: How intelligent is the complr? To: JONL.PA @ PARC-MAXC cc: BUG-LISP @ MIT-MC, JGA @ MIT-MC JGA and I both made measurements of the speed of the LEXPR overhead. It is far from unmeasurable. My numbers show about a 40 microsecond penalty for using the LEXPR calling convention. In the non-uuolink-snapped case this makes calling a LEXPR about 50% more expensive. You will understand why this is so if you recall that the .LCALL routine that all LEXPRs JSP to to set themselves up, performs such book-keeping operations including performing a pair of dynamic bindings, etc.  Date: 4 APR 84 12:13 PST From: JONL.PA@PARC-MAXC.ARPA Subject: Re: How intelligent is the complr? To: ALAN@MC.ARPA, JGA@MC.ARPA cc: BUG-LISP@MC.ARPA, JONL.PA@PARC-MAXC.ARPA In response to the message sent 4 Apr 84 14:53 EST from ALAN@MIT-MC.ARPA The slowdown for using an LEXPR may actually be unmeasurable -- there will be a couple of extra instructions in the function, but since you don't have a real &rest variable, there will be no consing up of an arglist. Why not try timing 10000 calls to each kind?  Date: 4 April 1984 14:53-EST From: Alan Bawden Subject: How intelligent is the complr? To: JGA @ MIT-MC cc: BUG-LISP @ MIT-MC In-reply-to: Msg of 4 Apr 1984 13:33-EST from John G. Aspinall Defining separate functions nullfun0, nullfun1, nullfun2 will result in the fastest functions. The LEXPR calling convention will slow down the &REST function.  Date: 4 April 1984 13:33-EST From: John G. Aspinall Subject: How intelligent is the complr? To: BUG-LISP @ MIT-MC I need a null function or functions that just fill a temporary hole. I need them with 0, 1 and 2 args. I would like them to be efficient. Is (defun nullfun (&rest nil) nil) the better choice, or should I define 0, 1 and 2 arg versions (defun nullfun0 () nil) (defun nullfun1 (nil) nil) (defun nullfun2 (nil nil) nil) like so. Does the complr do the smart thing with the first choice? When I compile the first version, I get a notice about an unused variable called |Lexprvar...| in the unfasl file, but I don't read LAP so I don't know whether that got into the machine code or not.  Date: 29 March 1984 12:18-EST From: David Vinayak Wallace Subject: Mac-Lisp To: JGA @ MIT-MC cc: BUG-MACLISP @ MIT-MC In-reply-to: Msg of 28 Mar 1984 12:25-EST from John G. Aspinall Date: 28 March 1984 12:25-EST From: John G. Aspinall Is "Maclisp" copyrighted or a registered trademark? Seems to me that it would be the number one choice of name for an Apple Macintosh lisp. Maybe LCS could make a few bucks by licensing the name? Please look into it.  Date: 28 March 1984 12:25-EST From: John G. Aspinall Subject: Mac-Lisp To: BUG-MACLISP @ MIT-MC Is "Maclisp" copyrighted or a registered trademark? Seems to me that it would be the number one choice of name for an Apple Macintosh lisp. Maybe LCS could make a few bucks by licensing the name?  Date: 24 March 1984 18:20-EST From: Alan Bawden Subject: NCONC vs. APPEND To: ROBOT.GML @ MIT-OZ cc: BUG-LISP @ MIT-MC In-reply-to: Msg of Sat 24 Mar 1984 15:57 EST from ROBOT.GML%MIT-OZ at MIT-MC.ARPA Date: Sat, 24 Mar 1984 15:57 EST From: ROBOT.GML%MIT-OZ at MIT-MC.ARPA (defun testr (a b list1 list2) (let ((list3 '(x y))) (cond-every ((< a b) (nconc list3 list2)) ((> a b) (nconc list3 list1)) (t list3)))) ... it doesn't matter that you keep changing the parameters, it still comes out larger each time. Since NCONC is defined to mutate its first argument, this is entirely correct and expected behavior. If you had done (GRINDEF TESTR) after calling it a couple of times, you would have found that it now looked something like: (defun testr (a b list1 list2) (let ((list3 '(x y foo bar baz))) (cond-every ((< a b) (nconc list3 list2)) ((> a b) (nconc list3 list1)) (t list3)))) Moral: don't mutate the constants in your code. Perhaps you should be using APPEND?  Date: Sat, 24 Mar 1984 15:57 EST Message-ID: From: ROBOT.GML%MIT-OZ@MIT-MC.ARPA To: bug-lisp%MIT-OZ@MIT-MC.ARPA When this little bit of code is run, (defun testr (a b list1 list2) (let ((list3 '(x y))) (cond-every ((< a b) (nconc list3 list2)) ((> a b) (nconc list3 list1)) (t list3)))) with a) the first time and (x y ) the second time and (x y the third time. etc. it doesn't matter that you keep changing the parameters, it still comes out larger each time.  Date: 10 March 1984 17:46-EST From: Alan Bawden Subject: maclisp problem To: DMS @ MIT-OZ cc: BUG-MACLISP @ MIT-MC, bug-oz @ MIT-OZ, help @ MIT-OZ, sundar @ MIT-OZ In-reply-to: Msg of 10 Mar 1984 17:27 EST (Sat) from David Siegel Are you sure you just aren't being confused by the fact that (LEDIT) runs an emacs as a subfork of your Lisp fork? If you were to type C-X Z to an Emacs with the LEDIT library loaded, that was running as a subfork of your EXEC, you would observe the symptoms you describe.  Date: 10 Mar 1984 17:27 EST (Sat) Message-ID: From: David Siegel Subject: maclisp problem To: bug-maclisp%MIT-OZ@MIT-MC.ARPA, bug-oz%MIT-OZ@MIT-MC.ARPA, help%MIT-OZ@MIT-MC.ARPA, sundar%MIT-OZ@MIT-MC.ARPA This may be a silly question but... When I get into Lisp or Maclisp, and type a control-e or (ledit) to get into emacs, I run into a problem... First, I load LEDIT by hand (can I get this done automatically when I go into lisp mode, or do I have to have it always done by putting it in my emacs init file?) Then, I type C-X Z to try to get back to Lisp. I'm always put back to top level exec. When I type cont lisp, I get LEDIT COMPLETE, and things are ok. How come I can't get back to Lisp directly? Thanks!  Date: 3 March 1984 15:44-EST From: Alan Bawden Subject: SUBFORK To: GLR @ MIT-OZ cc: BUG-LISP @ MIT-MC In-reply-to: Msg of Sat 3 Mar 1984 10:56 EST from Jerry Roylance Since it is 20X-only its source lives in MC:LISP20;  Date: Sat, 3 Mar 1984 10:56 EST Message-ID: From: Jerry Roylance To: BUG-LISP%MIT-OZ@MIT-MC.ARPA Subject: SUBFORK Where did the source go? I didn't see it on MC:LSPSRC;. Jerry  Date: Fri 2 Mar 84 20:58:19-PST From: Willis Dair Subject: MACLISP availablity To: Bug-MACLISP@MIT-MC.ARPA Phones: Work - (408) 984-4082; Home - (408) 923-BRIM Address: Santa Clara Univ.; Kenna Comp. Ctr.; Santa Clara, Ca., 95053 I was referred to send mail to this address to find out how I can get a TOPS-20 version of MACLISP. We at University of Santa Clara, Santa Clara, Ca. are using MACLISP but there are pieces missing. Any info as to how to acquire MACLISP for the -20 would be appreciated. Thanks. Willis -------  Date: Sat 25 Feb 84 14:20:22-PST From: Ross Casley Subject: Re: A Bug in Maclisp -- emacs? To: GUMBY@MIT-MC.ARPA cc: bug-lisp@MIT-MC.ARPA, crispin@SU-SCORE.ARPA In-Reply-To: Message from "David Vinayak Wallace " of Sat 25 Feb 84 12:22:00-PST I do use ^O/^Q for page control while in LISP. ^Q still works properly while in EMACS. ^O doesn't, and neither does ^T. ^T should interchange two letters, but instead it gives the usage times, sytem load etc., the same as if it were typed in a normal program. So neither ^T nor ^O ever gets to EMACS. It looks like EMACS opens the terminal in the wrong mode for some reason. The question is whether it is MACLISP which confuses EMACS before it starts, or EMACS just gets confused because it is not being run by the EXEC (or something), or the monitor is confused for some reason and doesn't open the terminal in the mode which has been requested. None of these problems arise when using EMACS normally. Does anyone know of another program which uses emacs the same way as maclisp? Perhaps we could isolate the problem that way. Ross. -------  Date: 25 February 1984 15:22-EST From: David Vinayak Wallace Subject: A Bug in Maclisp -- emacs? To: CS204.CASLEY @ SU-SCORE cc: BUG-LISP @ MIT-MC, crispin @ SU-SCORE In-reply-to: Msg of Fri 24 Feb 84 19:10:28-PST from Ross Casley Do you use ^O/^Q for page control while in LISP? The code for LEDIT claims only to cache the state of the tty before giving control to EMACS, so I would guess that perhaps it's your EMACS that's being confused. I can't duplicate this behaviour here at MIT, and I don't have access to a non-VTS system on which to try it out. Do you have similar problems when running EMACS normally? david  Mail-From: CS204.CASLEY created at 24-Feb-84 19:10:28 Date: Fri 24 Feb 84 19:10:28-PST From: Ross Casley Subject: A Bug in Maclisp To: crispin@SU-SCORE.ARPA ReSent-date: Fri 24 Feb 84 20:59:42-PST ReSent-from: Mark Crispin ReSent-to: BUG-LISP@MIT-MC.ARPA I remember noticing this some months ago, but thought it had been fixed. Maybe it has come back again...... If you call emacs via the maclisp (ledit) function, and try to use ^O to split a line in the file, TOPS-20 intercepts the command and interprets it as meaning that I want no further screen output from the editor. I noticed that after leaving emacs and maclisp, my screen length was not set properly, and setting "TERMINAL ZENITH-19" or "TERMINAL LENGTH 20" had no effect. This persisted until I logged out; resetting the forks to maclisp and emacs did not cure the problem. If you are not the person to send this to, I apologize. Who should it be? Ross -------  Date: 22 February 1984 12:20-EST From: Kent M Pitman Subject: Opening files locally To: Lamping @ SU-SCORE, Zubkoff%TARTAN @ CMU-CS-C cc: BUG-LISP @ MIT-MC In-reply-to: Msg of Tue 21 Feb 1984 23:29 EST from Leonard N. Zubkoff Actually, rather than (LET ((var (OPEN ...))) ... (CLOSE var)) you want to use an UNWIND-PROTECT to make sure the file gets closed before you lose your pointer to it. There are a couple of libraries with canned versions of the appropriate UNWIND-PROTECT (which I don't recommend writing yourself, since it's a lot of trouble to get right unless you've got a lot of experience writing UNWIND-PROTECTs correctly). You might check out either the IOTA macro (see the source to ((LIBLSP) IOTA) for documentation) or the WITH-OPEN-FILE macro (see the source to ((LIBLSP) LISPM) for documentation). -kmp  Received: from TARTAN by CMU-CS-C with TLnet; 21 Feb 84 23:30:09-EST Received: ID ; Tue 21 Feb 84 23:29:05-EST Date: Tue, 21 Feb 1984 23:29 EST From: Leonard N. Zubkoff To: John Lamping Cc: BUG-LISP@MIT-MC.ARPA Subject: Control Character I/O In-reply-to: Msg of Tue 21 Feb 84 19:22:05-PST from John Lamping John, You need to open the terminal in a special mode and then do your output to an explicit file-object. For example, (let ((image-tty (open 'Tty: '(out tty image single)))) (tyo #o33 image-tty) ... (close Image-tty)) Leonard  Date: Tue 21 Feb 84 19:22:05-PST From: John Lamping Subject: Control Character I/O To: BUG-LISP@MIT-MC.ARPA Could you tell me how to explain to TOPS-20 fromo MACLISP that I don't want to do any special processing of control characters on input or output. Especially, I would like to output escape sequences to my terminal without TOPS-20 turning them into $'s. Thank you! -------  Date: 10 February 1984 22:14 EST From: Kent M Pitman Subject: MSGFILES, Heralds To: ALAN @ MIT-MC cc: BUG-LISP @ MIT-MC, BUG-MACLISP-MANUAL @ MIT-MC, GLR @ MIT-OZ References: Msg of Fri 10 Feb 1984 12:13 EST from Jerry Roylance In-reply-to: Msg of 10 Feb 1984 13:37 EST from Alan Bawden Date: 10 February 1984 13:37 EST From: Alan Bawden Date: Fri, 10 Feb 1984 12:13 EST From: Jerry Roylance The messages ;Loading LET ; Loading FORMAT should be directed to MSGFILES, not T. They are as far as I can tell, can you demonstrate a way to get them to go elsewhere? Heh, heh. I bet I know what he did. I'm surprised you didn't figure it out, Alan. This is a very standard bug -- almost as common as radix confusion, I'd guess. If MSGFILES is non-NIL, then indeed the messages will go to MSGFILES, -BUT- there is a slight bug in the implementation: (TERPRI MSGFILES) (PRINC ";Loading FOO 37" MSGFILES) does the wrong thing when MSGFILES is NIL. An arg of NIL to TERPRI and PRINC means to use the default destinations. These forms should really be conditional on MSGFILES as well as (NOT (STATUS FEATURE NOLDMSG)). Or is there some other way of turning them off? There is. Do (SSTATUS FEATURE NOLDMSG). Bug-MacLisp-Manual: (SSTATUS FEATURE NOLDMSG) isn't documented. In fact, the existence of load messages isn't documented as far as I can tell. Fixed in several places in the source.  Date: Fri, 10 Feb 1984 12:13 EST Message-ID: From: Jerry Roylance To: BUG-LISP%MIT-OZ@MIT-MC.ARPA Subject: MSGFILES, Heralds The messages ;Loading LET ; Loading FORMAT should be directed to MSGFILES, not T. Or is there some other way of turning them off? Jerry  Date: 10 February 1984 13:37 EST From: Alan Bawden Subject: MSGFILES, Heralds To: GLR @ MIT-OZ cc: BUG-LISP @ MIT-MC, BUG-MACLISP-MANUAL @ MIT-MC In-reply-to: Msg of Fri 10 Feb 1984 12:13 EST from Jerry Roylance Date: Fri, 10 Feb 1984 12:13 EST From: Jerry Roylance The messages ;Loading LET ; Loading FORMAT should be directed to MSGFILES, not T. They are as far as I can tell, can you demonstrate a way to get them to go elsewhere? Or is there some other way of turning them off? There is. Do (SSTATUS FEATURE NOLDMSG). Bug-MacLisp-Manual: (SSTATUS FEATURE NOLDMSG) isn't documented. In fact, the existence of load messages isn't documented as far as I can tell.  Date: Fri, 10 Feb 1984 12:13 EST Message-ID: From: Jerry Roylance To: BUG-LISP%MIT-OZ@MIT-MC.ARPA Subject: MSGFILES, Heralds The messages ;Loading LET ; Loading FORMAT should be directed to MSGFILES, not T. Or is there some other way of turning them off? Jerry  Date: 8 February 1984 16:57 EST From: Alan Bawden Subject: DO: an interpreter bug To: BUG-LISP @ MIT-MC, DEVON @ MIT-MC, KMP @ MIT-MC, REM @ MIT-MC, WGD @ MIT-MC, JonL.pa @ PARC-MAXC In-reply-to: Msg of 8 Feb 1984 13:55 EST from William G. Dubuque OK, OK, OK. I fixed it in the source and patched it in the XLISP on MC.  Date: 8 February 1984 13:55 EST From: William G. Dubuque Sender: BIL @ MIT-MC Subject: DO: an interpreter bug To: JonL.pa @ PARC-MAXC cc: ALAN @ MIT-MC, BUG-LISP @ MIT-MC, DEVON @ MIT-MC, REM @ MIT-MC, KMP @ MIT-MC In-reply-to: Msg of 8 Feb 84 01:35 PST from JonL.pa at PARC-MAXC.ARPA Well I've been screwed by this bug a number of times (I used to like to distinguish between the case when a local binding is initially undefined and when it is NIL, so I would write (let ((some-list) undef)...) to mean that SOME-LIST should be thought of as initially NIL and that UNDEF's initial binding is undefined. Note that this is a syntactic specification of a semantic distinction. I usually utilized this distinction when it was important to emphasize the fact that subsequent code depended upon certain initializations. [I have since abandoned this scheme for other reasons] This bug can often lead to rather obscure errors when the interpreter starts marching down property lists. For this reason, I would think that the small amount of time necessary to remedy this simple problem would be well worth the effort. There should probably be a suitable warning regarding this problem in the Pitmanual.  Date: 8 Feb 84 01:35 PST From: JonL.pa@PARC-MAXC.ARPA Subject: DO: an interpreter bug To: Devon@MC.ARPA, Alan@MC.ARPA cc: Bug-Lisp@MC.ARPA, REM@MC.ARPA Hey, fellows, cool it. The COMPLR is correct. The original 1974 MacLisp manual makes no mention of non-lists in the var-inits lists, but this seems to have been a standard feature of MacLisp-like lisps since before 1980. I don't know if anyone tried to fix the interpreter's version of DO -- quite likely no pdp10 MacLisp user depended on the extended syntax -- but I wouldn't be suprised if someone reported this interpreter bug years ago. The question is, "Who wants to fix it"?  Date: 5 February 1984 16:43 EST From: Alan Bawden Subject: is it or isn't it a COMPLR bug? To: DEVON @ MIT-MC cc: BUG-LISP @ MIT-MC, REM @ MIT-MC In-reply-to: Msg of 5 Feb 1984 00:45 EST from Devon S. McCullough Date: 5 February 1984 00:45 EST From: Devon S. McCullough Alan, try this and see for yourself that it works fine in both the interpreter and the compiler. ... Ok, I tried it and I got: (do-fun) 1 (*) ;LJOB-EXPAND-RUN-MACRO UNBOUND VARIABLE ;BKPT UNBOUND-VARIABLE If that confuses you, look at the property list of the symbol L in my lisp environment: (plist 'l) (MACRO LJOB-EXPAND-RUN-MACRO) The interpreter is blindingly taking the CDR of the symbol L. It's a bug in the INTERPRETER. The fact that you seem to be able to compile such DOs is totally orthogonal. Since macros are run INTERPRETED inside the compiler, you sometimes get bit there. Maybe you have stylistic objections to to the way I define the local iteration variable L in the loop, but that's a matter of taste. I have no stylistic objections. I'm just trying to tell you that it doesn't work. This was not originally a feature of MacLisp DO, and someone seems to have made an attempt to support it, but he blew it. Must I drop everything and fix it immediately for you? Will it kill you to insert a couple of extra parens into your DO?  Date: 5 February 1984 00:45 EST From: Devon S. McCullough Subject: is it or isn't it a COMPLR bug? To: BUG-LISP @ MIT-MC cc: REM @ MIT-MC Alan, try this and see for yourself that it works fine in both the interpreter and the compiler. Maybe you have stylistic objections to to the way I define the local iteration variable L in the loop, but that's a matter of taste. The macro merely expands to NIL, but if you now add the expression (DO-MAC) to the end of the file and try to compile it then you get a MPV in the compiler. I'm not complaining, nor trying to give you a hard time! I just think it's a neat bug, I'm curious about how the compiler works, but it's beyond me to figure this one out by myself. If I'm missing something that's screamingly obvious to you, please enlighten me. ; -*- Lisp -*- (defun do-fun () (do ((n 1 (1+ n)) l) ((> n 7)) (setq l (cons '* l)) (print n) (princ l))) (defmacro do-mac () (do ((n 1 (1+ n)) l) ((> n 7)) (setq l (cons '* l)) (print n) (princ l)))  Date: 4 February 1984 19:00 EST From: Alan Bawden Subject: Further adventures with DO To: DEVON @ MIT-MC cc: BUG-LISP @ MIT-MC In-reply-to: Msg of 4 Feb 1984 11:53 EST from Devon S. McCullough Date: 4 February 1984 11:53 EST From: Devon S. McCullough To: BUG-COMPLR (do (this that other) (endtest etc) etc etc) works fine in the interpreter and the compiler. ... I repeat. This does NOT work in the interpreter. If the property lists of the symbols THIS, THAT, and OTHER are non-existent, then it will mislead you into thinking that it is working. The fact that the compiler runs in *RSET NIL mode makes it worse there. It does appear that the compiler tries to compile them. It might even succeed for all I know, but since it doesn't work interpreted... Why don't you take the advice we gave you the last time you reported this and slap a pair of parens around those variables?  Date: Tue, 31 Jan 1984 16:57 EST Message-ID: From: CJL%MIT-OZ@MIT-MC.ARPA To: BUG-MACLISP%MIT-OZ@MIT-MC.ARPA Subject: (STATUS TTYSIZE) is broken for lengths and widths > 127. on TWENEX (STATUS TTYSIZE) returns the wrong numbers for terminal lengths and widths greater than 127. on TWENEX. I suspect that this is because it uses TT%LEN and TT%WID of the JFN mode word. These fields are only seven bits. A better way to get the length and width of the terminal is to use the .MORLL and .MORLW codes with MOTPR%. They return the values as full 36. bit words.  Date: 9 Jan 1984 13:44 EST (Mon) Message-ID: From: Martin David Connor To: Bug-Lisp@MIT-MC Subject: LOAD and pathnames Would someone fix this? [PHOTO: Recording initiated Mon 9-Jan-84 1:39PM] MIT TOPS-20 Command Processor 5(750)-2 !lisp ^V LISP 2141 Alloc? n * (load "ps:hostmap") ;(LOAD ((|ps| ||) |hostmap| LSP *)) FILE NOT FOUND What happened to the directory name? ;BKPT IO-LOSSAGE (load "hostmap") Well, if I leave off the structure name. But come now. ;Loading HOSTMAP 24 122160 ^Z !pop [PHOTO: Recording terminated Mon 9-Jan-84 1:40PM]  Date: 4 JAN 84 01:08 PST From: JONL.PA@PARC-MAXC.ARPA Subject: Re: Setf's of load-byte don't work - broken foo-byte-expander To: ALAN@MC.ARPA, JONL.PA@MC.ARPA cc: CJL%MIT-OZ@MC.ARPA, bug-lisp@MC.ARPA, JONL.PA@PARC-MAXC.ARPA In response to the message sent Wed, 4 Jan 84 04:04 EST from ALAN@MIT-MC.ARPA Unless someone has fixed the DEFSETF for LOAD-BYTE, then he *will* have a setf bug problem. I thought GSB fixed the LOAD-BYTE optimizer about a year ago?  Date: Wednesday, 4 January 1984, 04:04-EST From: Alan Bawden Subject: Re: Setf's of load-byte don't work - broken foo-byte-expander To: JONL.PA at PARC-MAXC Cc: CJL%MIT-OZ at MIT-MC, bug-lisp at MIT-MC In-reply-to: The message of 4 Jan 84 03:39-EST from JONL.PA at PARC-MAXC Date: 4 JAN 84 00:39 PST From: JONL.PA@PARC-MAXC.ARPA This is a long-standing bug. RWK promised to look at it in the fall of 1981, but never got around to it. The code for the setf expander is a bit dense, and several others (myself included) elected not to spend a great deal of time probing into it. The problem hs nothing to do with SETF. The problem is that the optimizer on LOAD-BYTE and DEPOSIT-BYTE is broken.  Received: from MIT-MC by MIT-OZ via Chaosnet; 4 Jan 84 03:44-EST Date: 4 JAN 84 00:39 PST From: JONL.PA@PARC-MAXC.ARPA Subject: Re: Setf's of load-byte don't work - broken foo-byte-expander To: CJL%MIT-OZ@MC.ARPA, bug-lisp%MIT-OZ@MC.ARPA cc: JONL.PA@PARC-MAXC.ARPA In response to the message sent Tue, 3 Jan 84 21:15 EST from CJL%MIT-OZ@MIT-MC.ARPA This is a long-standing bug. RWK promised to look at it in the fall of 1981, but never got around to it. The code for the setf expander is a bit dense, and several others (myself included) elected not to spend a great deal of time probing into it.  Date: Tue, 3 Jan 1984 21:15 EST Message-ID: From: Chris Lindblad To: bug-lisp%MIT-OZ@MIT-MC.ARPA Subject: Setf's of load-byte don't work - broken foo-byte-expander The following function doesn't work when compiled. Alan looked at it for a while, and says that foo-byte-expander is broken. (DEFUN MAKE-BYTEPOINTER (BYTE-SIZE ADDRESS BYTE-POSITION) (LET ((BP 0.)) (SETF (LOAD-BYTE BP 0 18.) ADDRESS) (SETF (LOAD-BYTE BP 24. 6.) BYTE-SIZE) (SETF (LOAD-BYTE BP 30. 6.) BYTE-POSITION) BP))  Date: 17 Dec 83 1316 PST From: Yoni Malachi Subject: BCOMPLR deleted files To: BUG-LISP@MIT-MC I compiled a file with BCOMPLR using the command FILE.LSP(fmt) I got the message ((....)) compiled - 0 words and then the file disappeared. It happend to three files only one of them I managed to rescue using UNDEL which identified BCOMPLR as the deleting program. What makes it even stranges us that the file protection was 257 so I was supposed to be asked before the file could be deleted. This happend at the end of a long sequence of files that were compiled succesfully followed by e file which missed a closing paren. Before compiling the other files (those that were deleted) files i did ^G and then (maklap) Thanks, Yoni Malachi.  Date: 11 December 1983 20:29 EST From: Kent M Pitman Subject: SASW: use of ALLFILES To: BUG-LISP @ MIT-MC My guess is he wasn't reading current documentation. My manual documents ALLFILES correctly. I sent him more detailed mail to this effect. -kmp  Date: 11 December 1983 16:47 EST From: George J. Carrette Sender: GJC0 @ MIT-MC Subject: use of ALLFILES To: SASW @ MIT-MC cc: BUG-LISP @ MIT-MC In-reply-to: Msg of 11 Dec 1983 16:45 EST from Steven A. Swernofsky Allfiles takes a list of namelists.  Date: 11 December 1983 16:45 EST From: Steven A. Swernofsky Subject: use of ALLFILES To: BUG-LISP @ MIT-MC cc: SASW @ MIT-MC According to the manual, (allfiles x) takes a namelist. But, (allfiles (namelist nil)) responds with an error -- it says that you should use a namelist and not a namestring! Also, (alfiles (namestring nil)) also responds with an error -- it says that you have a bad namestring! What am I doing wrong? Neither of these errors seems credible. Thank you. -- Steve  Date: 29 November 1983 03:21 EST From: Kent M Pitman To: BUG-LISP @ MIT-MC For those who care, I added a function called TIME:PARSE-LIST to the TIME library on LIBLSP. It's like TIME:PARSE on the LispM, but returns a list of information rather than multiple values. See LIBDOC;TIME > for details. The code is translated from my Teco time parser, so don't expect to be able to read it... it looks more like Teco than like Lisp. It may have some shortcomings, but it handles a lot of the useful cases and should suffice for simple applications.  Date: 16 November 1983 14:27 EST From: George J. Carrette Subject: (TYO #\BS) in Tops20 Maclisp To: Acuff @ RUTGERS cc: BUG-LISP @ MIT-MC, JPG @ MIT-MC In-reply-to: Msg of 16 Nov 1983 04:22 EST from Jeffrey P. Golden There are a couple "terminal-handlers" for vanilla tops-20 maclisp hanging around, the ones I know about are: [1] one I installed at HP labs palo-alto in summer of 1982 [2] one used at YALE university. [3] one JONL did at MIT. These quite effectively do cursorpos and other operations once you tell it what kind of terminal you have. The basic hack is that the proper SSTATUS TTY call is done to put the terminal in image mode, and then the values of TYI and TYO are bashed with an SFA which handles all input and output. Then SSTATUS TTYSCAN is done to setup a rubout-handler which will use the lisp-level cursorpos calls. At least, that is how jonl's and my code worked. My code was backtranslated from VAX-NIL => MACLISP. (The NIL code parses the Unix "termcap" database by the way.) This is all to say that you shouldn't expect the assembly-language level code for terminal-handling in vanilla tops-20 to do anything reasonable, your best bet is to get one of these packages which patch things quite nicely at lisp-level. -gjc  Date: 16 November 1983 04:22 EST From: Jeffrey P. Golden Subject: (TYO #\BS) in Tops20 Maclisp To: BUG-LISP @ MIT-MC cc: JPG @ MIT-MC Can someone help Acuff@RUTGERS? He's got an H19 terminal, if that matters. Also, they don't have VTS. Date: 16 Nov 83 00:37:10 EST From: Rich Acuff at Ohio State To: JPG@MIT-MC.ARPA I've experimented with MACLISP here, and it seems to be a 'feature' of TYO that it will 'emulate' a backspace character by doing a return, and several spaces. The strange thing is that the BS character IS output before the return-spaces. I can't find any documentation or code for TYO here, so I couldn't check this out for sure. If you can tell me where to find some documentation and code for TYO (presumably in Midas), and how to load MACLISP's symbol table from Tops-20 DDT, I'll get out of your hair.  Date: Tuesday, 15 November 1983, 02:29-EST From: David Vinayak Wallace Subject: correction: ledit hook To: bug-lisp at MIT-MC Attention: tops-20 ledit users Correction: In order to be more consistent with other MACLISP hooks, Ledit-return-hook (documented in a previous message) should be a function of no arguments to be called when returning to lisp. So again, to clear your screen after exiting emacs, try (setq ledit-return-hook '(lambda () (cursorpos 'c))) david  Date: Sunday, 13 November 1983, 06:50-EST From: David Vinayak Wallace Subject: LEDIT return hook To: bug-lisp at MIT-MC Cc: rich at MIT-MC, kmp at MIT-MC Due to overwhelming demand, twenex maclisp now has a hook evaluated when you return from the emacs subfork. If LEDIT-RETURN-HOOK is non-null, it is a form to evaluate between returning to lisp and evaluating the zapped forms. It can be bound to (cursorpos'c) to clear your screen after returning, for instance. Compiled, tested and installed in OZ:PS:LEDIT.FASL.44. Source on MC. david  Date: 10 November 1983 10:32 EST From: George J. Carrette Subject: LEDIT To: RICH @ MIT-OZ cc: JONL.PA @ PARC-MAXC, bug-lisp @ MIT-OZ, KMP @ MIT-OZ In-reply-to: Msg of 10 Nov 1983 09:26 EST (Thu) from Charles Rich hold it, I might have a more practical suggestion for you than hacking maclisp and ledit. If you are using maclisp on a loaded system such as OZ its probably because you can use it from a regular dial-up terminal, from home. If that is the case then you will probably like an account on a VAX with NIL to run a lot better. KMP would like it because he can use evaluate-defun or lisp-listener mode without loosing the context of the editor screen. You would like it because of all the clean and documented hooks into sub-systems such as the editor. (Yes folks, the NIL manual even tells how the editor is built and how to write simple extensions to it.) Let me know if you want an account arranged. [Users get kind of possesive about their VAX's, if you know what I mean, especially when there are unused ones sitting around due to lack of energy to hook up disks and network ports and modems.] -gjc  Date: 10 Nov 1983 09:26 EST (Thu) Message-ID: From: Charles Rich To: JONL.PA@PARC-MAXC.ARPA Cc: bug-lisp%MIT-OZ@MC.ARPA, KMP%MIT-OZ@MC.ARPA Subject: LEDIT In-reply-to: Msg of 10 Nov 1983 01:09-EST from JONL.PA at PARC-MAXC.ARPA Date: Thursday, 10 November 1983 01:09-EST From: JONL.PA at PARC-MAXC.ARPA To: KMP%MIT-OZ at MC.ARPA, RICH%MIT-OZ at MC.ARPA cc: bug-lisp%MIT-OZ at MC.ARPA, JONL.PA at PARC-MAXC.ARPA Re: LEDIT In response to the message sent Wed, 9 Nov 83 16:54:45 EST from KMP%MIT-OZ@MIT-MC.ARPA I think the initial versions of Twenex LEDIT did clear the screen upon return from EMACS. Myself and others complained about the unnecessary loss of screen context (as you call it), and it was changed. Would be curious to know if this preference is a "close call", or overwhelmingly one way or the other, in the user community. I'd like a user hook in the right place, i.e. after the call to Emacs and before the returned sexps are evaluated. I recall there actually used to be such a hook. Right now I define my own ^E to call (LEDIT) and then do a (CURSORPOS 'C), but then I don't get to see the values of the sexpressions zapped to lisp. -CR  Date: 9 NOV 83 22:09 PST From: JONL.PA@PARC-MAXC.ARPA Subject: Re: LEDIT To: KMP%MIT-OZ@MC.ARPA, RICH%MIT-OZ@MC.ARPA cc: bug-lisp%MIT-OZ@MC.ARPA, JONL.PA@PARC-MAXC.ARPA In response to the message sent Wed, 9 Nov 83 16:54:45 EST from KMP%MIT-OZ@MIT-MC.ARPA I think the initial versions of Twenex LEDIT did clear the screen upon return from EMACS. Myself and others complained about the unnecessary loss of screen context (as you call it), and it was changed. Would be curious to know if this preference is a "close call", or overwhelmingly one way or the other, in the user community.  Date: Wed 9 Nov 83 16:54:45-EST From: KMP%MIT-OZ@MIT-MC.ARPA Subject: Re: LEDIT To: RICH%MIT-OZ@MIT-MC.ARPA cc: bug-lisp%MIT-OZ@MIT-MC.ARPA In-Reply-To: Message from "Charles Rich " of Wed 9 Nov 83 10:15:00-EST (CURSORPOS 'C) returning to lisp is a bad idea. As much as you may find it unaesthetic, there are enough users who think it worth preserving the maximum context information from their Emacs (due to lack of multi-window mode on mainframes) that it would be a bad idea to gratuitously clear the screen. That can only destroy information and although I don't use LEDIT myself, I have to agree that the people who say the aesthetics don't outweigh the potential loss of information have a stronger case. If you feel very strongly about this, request a hook variable to control this behavior; that could probably be done if there was interest. -------  Date: 9 Nov 1983 10:15 EST (Wed) Message-ID: From: Charles Rich To: bug-lisp%MIT-OZ@MIT-MC.ARPA Subject: LEDIT CC: KMP%MIT-OZ@MIT-MC.ARPA It would be nice if the Lisp end of Ledit did a (CURSORPOS 'C) when it returned to Lisp instead of the current behavior of leaving you near the bottom of the screen with most of the old Emacs buffer in view. Btw, where is the source for LEDIT.FASL kept -- I wanted to look if there was a user hook I could set to get this behavior. Thanks, Chuck.  Date: Tuesday, 8 November 1983, 18:41-EST From: Alan Bawden To: GLR at MIT-AI Cc: Bug-Lisp at MIT-MC In-reply-to: Date: Mon, 7 Nov 1983 22:14 EST From: Jerry Roylance Hmm. Has MACLISP stopped looking in the connected directory for init files? A lot of batch jobs stopped working. Yup. We "fixed the bug" where MacLisp would look in your connected directory rather than your home directory for your Lisp init file.  Date: Mon, 7 Nov 1983 22:14 EST Message-ID: From: Jerry Roylance To: Bug-Lisp%MIT-OZ@MIT-MC.ARPA Hmm. Has MACLISP stopped looking in the connected directory for init files? A lot of batch jobs stopped working. Jerry  Date: Sun, 6 Nov 1983 18:54 EST Message-ID: From: MHS%MIT-OZ@MIT-MC.ARPA To: BUG-MACLISP%MIT-OZ@MIT-MC.ARPA Subject: I/O Lossage Cc: Mhs%MIT-OZ@MIT-MC.ARPA The device name doesn't seem to be set up correctly and load barfs. Here's a trace: [PHOTO: Recording initiated Sun 6-Nov-83 6:51PM] TOPS-20 Command Processor 5(742)-2 @cd ss: Note what I've connected to @lisp LISP 2141 Alloc? n * (status ve[[lispversion) /2141 (status site) OZ (load "hack.file") ;(LOAD ((PS |PUBLICATIONS.LISP|) |hack| |file| *)) NO SUCH DIRECTORY NAME ;BKPT IO-LOSSAGE ^C @pop [PHOTO: Recording terminated Sun 6-Nov-83 6:52PM] Note the PS in the filespec.  Date: Sun 6 Nov 83 15:57-EST From: George J. Carrette Subject: maclisp forever... To: bug-lisp%MIT-OZ@MIT-MC.ARPA according to GJS the maclisp printer used to have this feature where if a symbol had a PRINT property that property got funcalled with the symbol as its argument. Somehow this feature got removed, even though there is this kludgy special case check for symbols with a +INTERNAL-STRING-MARKER property. Q: Would it be too much to ask to have this feature restored? I get a feeling it might be a problem having to do with register-saving optimizations etc, but somehow the HUNK kludge handles a similar problem. (Perhaps incorrectly?) The purpose of this is to experiment with a back-to-basics i.e. list structure, kind of programming style.  Date: Mon, 24 Oct 1983 05:19 EDT Message-ID: From: Jerry Roylance To: BUG-LISP%MIT-OZ@MIT-MC.ARPA Subject: CURSORPOS fails in a batch job The batch job @LISP *(CURSORPOS 'C) produces a lisp error. The PITUAL claims it should be a nop. (STATUS FILEMODE TYO) does not contain CURSORPOS.  Date: Fri, 30 Sep 1983 14:38 EDT Message-ID: <[MIT-OZ].GLR.30-Sep-83 14:38:42> From: Jerry Roylance To: BUG-LISP@MIT-OZ SETF (EVAL-ONCE) gets confused? This works: (setf (ldb ppss (arraycall fixnum array index)) val) => (store (arraycall fixnum array index) (dpb val ppss (arraycall fixnum array index))) But change val to a function call, and we start SETQ'ing gensyms (setf (ldb ppss (arraycall fixnum array index)) (fcn)) => (let ((g0001 (arraycall fixnum array index))) (setq g0001 (dpb val ppss g0001)))  Date: 27 September 1983 12:34 EDT From: Leo P. Harten To: BUG-LISP @ MIT-MC Inside macsyma, I did a control-b break and then (alloc t) (subst 1000 400 *) (eval (alloc *)) in order to increase the FLPDL from 400 to 1000. after these steps, (alloc t) gives 992 for the FLPDL. why 992??? thanks for any info on this.  Date: Thursday, 22 September 1983, 01:52-EDT From: Kent M. Pitman Subject: TYIPEEK and SFAs -- A longstanding bug that needs fixing To: Alan at MC Cc: BUG-MACLISP at MIT-MC I got mail from you a couple months ago saying you wanted to flush Maclisp 1914 from MC but I was locking the dump with my Fortran translator. I finally found the bug report which describes the reason the translator doesn't run in a later version of Lisp. I'd appreciate it if you could look at this bug, as I do consider it rather severe... I just checked and all the reported symptoms still occur as described in Lisp 2138 on MC. -----Begin Dredged Up Mail----- Date: 20 May 1981 04:23-EDT From: Kent M. Pitman To: BUG-MACLISP Re: TYIPEEK / SFA interaction changed?? It used to be that the following definition (DEFUN SFA-HANDLER (SELF OP DATA) (CASEQ OP ((WHICH-OPERATIONS) '(TYIPEEK)) ((TYIPEEK) DATA) (T (ERROR "I am too dumb to do that" OP)))) (SETQ STREAM (SFA-CREATE #'SFA-HANDLER 0. "Dumb Stream")) would allow you to do (TYIPEEK NIL STREAM) => -1 (TYIPEEK NIL STREAM -1) => -1 (TYIPEEK NIL STREAM -3) => -3 even tho (TYIPEEK NIL (OPEN 'NUL: 'IN) -1) => -1 (TYIPEEK NIL (OPEN 'NUL: 'IN) -3) => -1 ; this was a bug then and still is now Anyway, now you get the following behavior instead: (TYIPEEK NIL STREAM) => ;NIL NON-FIXNUM VALUE (TYIPEEK NIL STREAM -1) => ;NIL NON-FIXNUM VALUE In an EOF case, the TYIPEEK message to an SFA must be able to return its DATA argument. DATA used to get bound to #nnnnnn and somehow if you returned this, it magically figured out you wanted the eof value returned to the user. Now I would prefer that DATA be bound to the value supplied (default -1 if none supplied), but that's just preference. The important thing tho' is that I have code that is broken until someone fixes the TYIPEEK message to pass some piece of data which if returned will give the right value back from TYIPEEK without erring... Naturally, while you're at it you could fix that other bug wherein only -1 can be returned from an EOF on a real file object when TYIPEEK'ing, even if some other arg is supplied (see the -3 case above). -kmp Date: 21 May 1981 02:13-EDT From: Alias for KMP To: BUG-MACLISP Re: more on yesterday's TYIPEEK lossage INCST3: TLNE T,SO.TIP ;FOO! TYIPEEK IS DIFFERENT! TDZA C,C ; BUT IF NOT TYIPEEK THEN USE MOVEI C,INCST3 ; NEW EOF VALUE, SOMETHING UNIQUE PUSHJ P,ISTCAL ;CALL THE SFA POP P,C ;RESTORE EOF VALUE CAIN A,INCST3 ;DID THE SFA RETURN EOF? JRST INCST4 ;YES, HANDLE IT JSP T,FXNV1 ;ELSE THE VALUE RETURNED MUST BE A FIXNUM POPJ P, ----- Note how SFA's get sent a NIL but on return check for INCST3 ...? How is the guy going to know to return that? I just did (SETQ STREAM (SFA-CREATE #'(LAMBDA (SELF OP DATA) (CASEQ OP ((WHICH-OPERATIONS) '(TYIPEEK)) ((TYIPEEK) '#,(MUNKAM (GETDDTSYM 'INCST3))) (T (ERROR "Loss" OP)))) 0. "Loss")) (TYIPEEK NIL STREAM) => -1. (TYIPEEK NIL STREAM -3) => -3. which is the kind of behavior that I want... Somehow this need for #,(MUNKAM ...) seems awkward, though.  Date: Tuesday, 20 September 1983, 04:13-EDT From: Kent M. Pitman Subject: [Followup: ALPHALESSP] To: Alan at MIT-MC Cc: BUG-MACLISP at MIT-MC While you're building new Maclisps,.... The (ALPHALESSP 'FOOBA 'FOOBAR) bug still happens. Remember that one? Dunno if you care. I just noticed you claimed to have figured out the fix and yet it's still broken in Lisp 2138 on MC. Date: 2 October 1982 15:31-EDT From: Alan Bawden To: BUG-LISP, JPG, KMP Re: ALPHALESSP: More data 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. --kmp  Date: 18 September 1983 17:00 EDT From: Alan Bawden Subject: SETSYNTAX and (STATUS CHTRAN) on TOPS-20 To: GLR @ MIT-OZ cc: BUG-LISP @ MIT-MC In-reply-to: Msg of Sat 17 Sep 1983 21:53 EDT from Jerry Roylance Ah! An ancient and venerable problem. It seems that MacLisp stores the CHTRAN and MACRO properties of a character in the same 18 bits. (See, you never need them both at once...) Theoretically, whenever a character crosses the boundary from macroness to non-macroness its CHTRAN should be reset to something reasonable (like itself). Unfortunately, the code that implements SETSYNTAX/(S)STATUS CHTRAN/MACRO is one of these MacLisp gems where four different entry points each load a different instruction into an accumulator and them jump to a common routine that does an XCT somewhere (and then some of the instructions skip!!). Its not worth fixing. Basically, when you modify a character's syntax, always use SETSYNTAX, and always supply a non-nil third argument, and the problem won't happen. The next edition of the Pitmanual should contain some clarification of this...  Date: Sat, 17 Sep 1983 21:53 EDT Message-ID: <[MIT-OZ].GLR.17-Sep-83 21:53:22> From: Jerry Roylance To: BUG-LISP@MIT-OZ Subject: SETSYNTAX and (STATUS CHTRAN) on TOPS-20 ;;; Bug in MACLISP ;;; setsyntax screws chtran ;;; (defun maclisp-bug () (let ((readtable (*array nil 'readtable))) (setsyntax #/, 'single nil) (print (status macro #/,)) (print (status chtran #/,)) (sstatus macro #/, nil) (print (status chtran #/,)) NIL )) I suspect that setsyntax does completely remove the , readmacro.  Date: 17 September 1983 20:08 EDT From: Igor Rivin To: BUG-MACLISP @ MIT-MC Calling GRIND0 on a file which contains the form (defun foo (l) (mapcar #'list l)) causes a ;BKPT *RSET-TRAP probably because of the # reader macro.  Date: 6 September 1983 20:30 EDT From: David C. Plummer To: KMP @ MIT-MC cc: DCP @ MIT-MC, RWK @ MIT-MC, ALAN @ MIT-MC, BUG-MACLISP @ MIT-MC, GJC @ MIT-MC, GUMBY @ MIT-MC Date: 6 September 1983 19:17 EDT From: Kent M. Pitman GUMBY @ MIT-MC Uh, I believe the story is... WHEN and UNLESS are in UMLMAC. ... Yow!! Information and historical perspective! I think we're all agreed that they should appear in the standard MacLisp, and Alan mumbled "some day..." which I hope means the next time he has a hack attack and builds a new MacLisp.  Date: 6 September 1983 19:17 EDT From: Kent M. Pitman To: DCP @ MIT-MC cc: RWK @ MIT-MC, ALAN @ MIT-MC, BUG-MACLISP @ MIT-MC, GJC @ MIT-MC, GUMBY @ MIT-MC Uh, I believe the story is... WHEN and UNLESS are in UMLMAC. They have been there for ages; since long before the LispM adopted them. It took forever to convince the LispM people that they were a win because there was a stubbornness on the part of the LispM designers who claimed that there were already too many control constructs in LispM lisp and that people should use AND and OR for simple cases and IF/COND for the hairier cases. I believe the justification for them being in UMLMAC and not being autoloading stemmed from the fact that no one was willing to standardize them into the LispM. I think that now that they have gained acceptance in the LispM community that it would be an extremely good idea if they became standard in Maclisp as well. It seems that my manual doesn't document them, even as something you could make autoload. That's a bit sad.  Date: 6 September 1983 17:05 EDT From: David C. Plummer Subject: autoloading To: RWK @ SCRC-TENEX cc: ALAN @ MIT-MC, DCP @ MIT-MC, BUG-MACLISP @ MIT-MC, GJC @ MIT-MC, GUMBY @ MIT-MC Received: from SCRC-YUKON by SCRC-TENEX with CHAOS; Tue 6-Sep-83 01:42:37-EDT Date: Tuesday, 6 September 1983, 01:36-EDT From: Robert W. Kerns In-reply-to: The message of 6 Sep 83 00:02-EDT from Alan Bawden Date: 6 September 1983 00:02 EDT From: Alan Bawden WHEN and UNLESS really are very new. I added them myself to Lisp Machine lisp only about a year ago. Certainly well after IF, FORMAT and LOOP were common. GRRR. New in a geological sense, perhaps. They had been part of MLMAC (and I believe by extension loaded into the compiler) for a year or two before you got around to adding them to the Lisp Machine. Sorry, guy, chomplr certainly does NOT know about WHEN and UNLESS, and they are NOT in MLMAC. I guess what you are really saying is that Alan won't get around to adding them to the lisp machine for at least a year? Gee, time to update my programs...  Received: from SCRC-YUKON by SCRC-TENEX with CHAOS; Tue 6-Sep-83 01:42:37-EDT Date: Tuesday, 6 September 1983, 01:36-EDT From: Robert W. Kerns Subject: autoloading To: ALAN@MIT-MC, DCP@MIT-MC Cc: BUG-MACLISP@MIT-MC, GJC@MIT-MC, GUMBY@MIT-MC In-reply-to: The message of 6 Sep 83 00:02-EDT from Alan Bawden Date: 6 September 1983 00:02 EDT From: Alan Bawden WHEN and UNLESS really are very new. I added them myself to Lisp Machine lisp only about a year ago. Certainly well after IF, FORMAT and LOOP were common. GRRR. New in a geological sense, perhaps. They had been part of MLMAC (and I believe by extension loaded into the compiler) for a year or two before you got around to adding them to the Lisp Machine.  Date: 6 September 1983 00:02 EDT From: Alan Bawden Subject: autoloading To: DCP @ MIT-MC cc: BUG-MACLISP @ MIT-MC, GJC @ MIT-MC, GUMBY @ MIT-MC In-reply-to: Msg of 5 Sep 1983 22:50 EDT from David C. Plummer WHEN and UNLESS really are very new. I added them myself to Lisp Machine lisp only about a year ago. Certainly well after IF, FORMAT and LOOP were common. Yes, they should have autoload properties. So should DEFSTRUCT, DEFSTRUCT-EXPAND-REF-MACRO and DEFSTRUCT-EXPAND-CONS-MACRO (the minimal set to make DEFSTRUCT work). Someday...  Date: 5 September 1983 22:50 EDT From: David C. Plummer To: GJC @ MIT-MC, GUMBY @ MIT-MC cc: BUG-MACLISP @ MIT-MC FORMAT and LOOP have autoload properties. I would guess both of these postdate IF and neither is used by MACSYMA. If a bare maclisp can endure 3 (4 actually) more symbols, I think WHEN and UNLESS should be two of them (probably loading from MLMAC), and DEFSTRUCT the 3rd (the 4th symbol being STRUCT or whatever file it loads from).  Date: 5 September 1983 19:21 EDT From: George J. Carrette Subject: WHEN/UNLESS To: DCP @ MIT-MC cc: BUG-MACLISP @ MIT-MC In-reply-to: Msg of 5 Sep 1983 13:24 EDT from David C. Plummer There might also be some concern about the number of built-in symbols in a bare maclisp. I know that JONL was talking about being up against some kind of page boundary with symbols before he left maclisp. Macsyma and other systems etc. (I'm not saying that there aren't a lot of random things in the default maclisp that perhaps aren't as useful as WHEN/UNLESS).  Date: Monday, 5 September 1983, 15:36-EDT From: David Vinayak Wallace To: David C. Plummer Cc: BUG-MACLISP at MIT-MC In-reply-to: The message of 5 Sep 83 13:24-EDT from David C. Plummer Date: 5 September 1983 13:24 EDT From: David C. Plummer Any good reason WHEN and UNLESS don't have autoload properties? I would think they would be in MLMAC with IF, but they aren't (as far as I can tell). Probably because they postdate IF (and the time MLMAC was written).  Date: 5 September 1983 13:24 EDT From: David C. Plummer To: BUG-MACLISP @ MIT-MC Any good reason WHEN and UNLESS don't have autoload properties? I would think they would be in MLMAC with IF, but they aren't (as far as I can tell). .  Date: 29 August 1983 22:23 EDT From: Alan Bawden Subject: Finding LISP.INI files on Tops-20 To: MARTY @ MIT-OZ cc: BUG-lisp @ MIT-OZ In-reply-to: Msg of Aug 29 1983 5:59PM-EDT from Martin David Connor Date: Monday, August 29, 1983 5:59PM-EDT From: Martin David Connor It would be nice if MACLISP cannot find a LISP.INI file on DSK: if it would then try PS:LISP.INI. Funny you should bring this up. Last weekend Gumby and I hacked 20X MacLisp so that PS: is searched rather than your connected directory for an init file. Try XLISP on OZ. While I was at it, I made it look for "LISP.INIT", and only if that fails look for "LISP.INI". (Next, we plan to make the choice of extension ("LSP" vs. "LISP") a per-site option.) The way it is now, I have to connect to my PS: directory to start my lisp, and if I happen to forget, it barfs most ungracefully and irrecoverably. It "BARFS"? I have never seen that happen, for me it just failed to load my init file.  Date: Monday, August 29, 1983 5:59PM-EDT From: Martin David Connor Subject: Finding LISP.INI files on Tops-20 To: BUG-lisp at MIT-OZ It would be nice if MACLISP cannot find a LISP.INI file on DSK: if it would then try PS:LISP.INI. The way it is now, I have to connect to my PS: directory to start my lisp, and if I happen to forget, it barfs most ungracefully and irrecoverably. Thank you.  JOEK@MIT-ML 08/11/83 14:05:39 To: (BUG LISP) at MIT-ML Earlier today I sent you two messages regarding what I thought was a bug in MacLisp. It turned out to be only a perversity of MacLisp(dynamic scoping) and an unfortunate function name in my source code. No problem.  JOEK@MIT-ML 08/11/83 10:16:00 To: (BUG LISP) at MIT-ML There seems to be some problem with ML's version of MacLisp when it comes to autoloading. I've been trying to use the ledit and trace features, but it will give me an error message concerning a set command not receiving enough arguments(expecting an argument list of (i a b c)). These features seemed to be working yesterday, but today they are not.  Date: 9 August 1983 14:24 EDT From: George J. Carrette To: BUG-LISP @ MIT-MC If I have (defprop scm (dsk scheme) ppn) it would be nice if (load "scm:foo") worked. As it is, "SCM:FOO" is getting interpreted as ((SCM *) FOO) ==> ((SCM GJC) FOO) ==> NO SUCH DEVICE SCM. IF "SCM:FOO" ==> ((SCM)FOO) then things would work ok. Suggested fix, when doing the namestring ==> namelist conversion, if a device with a PPN property is given then don't supply a directory spec of "*" if no directory spec is given. The reason "SCM:FOO" is nice is because it is easy to get it to work on TOPS-20 & VMS through the use of "define scm ...."  Date: 5 August 1983 22:06 EDT From: Alan Bawden Subject: (sstatus random (status random)) To: KMP @ MIT-MC, JUDY @ MIT-OZ cc: BUG-MACLISP @ MIT-MC In-reply-to: Msg of Fri 5 Aug 1983 14:33 EDT from JUDY at MIT-OZ Date: Fri, 5 Aug 1983 14:33 EDT From: JUDY at MIT-OZ Depending upon the current random seed, Maclisp sometimes gives an error message of "bad argument" for the call (sstatus random (status random)) Date: 5 August 1983 15:19 EDT From: Kent M. Pitman As a hunch, I tried just patching SSRAN6+2 to use JUMPL instead of JUMPLE (in Lisp 2138 on ITS) and this makes my RANDOM-TESTER function happy. That of course doesn't mean it's the right fix, but it does suggest that the error checking is probably just overly paranoid since presumably something coming out of (STATUS RANDOM) has to be a valid input to (SSTATUS RANDOM). Thank you KMP, you are absolutely correct. Fixed in the source. I also fixed the check at SSRAN6+3 which was a little too liberal about what it accepted. [I must look up the reference for this random number generator. It seems to be different from the LispMachine version in that it steps its pair of pointers in the opposite direction. I suspect this makes a difference in the randomness of the result. Of course I can't fix it if people are depending on (sstatus random 17) doing the same thing next year as last...]  Date: 5 August 1983 15:19 EDT From: Kent M. Pitman Subject: Judy's RANDOM bug To: BUG-MACLISP @ MIT-MC I put a function RANDOM-TESTER in the file MC:LSPSRC;RNDTST which will cause Judy's bug to happen while also printing other useful debugging info. If/when a fix is made, you might use this function to test the fix. As a hunch, I tried just patching SSRAN6+2 to use JUMPL instead of JUMPLE (in Lisp 2138 on ITS) and this makes my RANDOM-TESTER function happy. That of course doesn't mean it's the right fix, but it does suggest that the error checking is probably just overly paranoid since presumably something coming out of (STATUS RANDOM) has to be a valid input to (SSTATUS RANDOM).  Date: Fri, 5 Aug 1983 14:33 EDT From: JUDY@MIT-OZ To: bug-maclisp@MIT-OZ cc: judy@MIT-OZ Subject: problem with setting the status of the random function Depending upon the current random seed, Maclisp sometimes gives an error message of "bad argument" for the call (sstatus random (status random)) and similarly for something like (setq foo (status random)) (sstatus random foo) In particular this will happen (to me at least) after random is called 34 (base 10) times, 70 times, 105 times, 141 times, 176 times, 212 times, etc. After random has been called 34 times (starting with the initial seed) (status random) returns (0 36 26091955856 ...). After 70 times (status random) returns (35 0 26091955856 ...) 105 (0 36 22609952497 ...) 141 (35 0 22609952497 ...) 176 (0 36 -14927067643 ...) 212 (35 0 -14927067643 ...) If you will notice, 70 is 36 away from 34, 105 is 35 away from 70, 141 is 36 away from 105, etc. Judy  Date: 3 August 1983 20:25 EDT From: George J. Carrette Subject: # To: JGA @ MIT-MC cc: BUG-LISP @ MIT-MC In-reply-to: Msg of 3 Aug 1983 17:44 EDT from John G. Aspinall See the *ALL NEW* MACLISP MANUAL, available from LCS PUBLICATIONS!  Date: 3 August 1983 17:44 EDT From: John G. Aspinall Subject: # To: BUG-LISP @ MIT-MC cc: JGA @ MIT-MC How do I, temporarily and reversibly, turn off the macro-invoking powers of # ? I would like it to look alphabetic during reads from a file.  Date: Monday, 1 August 1983, 05:15-EDT From: David Vinayak Wallace Subject: lisp i/o To: Arturo Perez Cc: bug-lisp@MIT-OZ In-reply-to: The message of 30 Jul 83 22:43-EDT from Arturo Perez Date: 30 Jul 1983 2243-EDT From: Arturo Perez I am in search of information detailing how Lisp inputs/outputs to files. Can anyone out there point me to a source of info? Thanx. There is now a maclisp manual; there should be a copy in Eric's office. Basically, (open "file" ) will return a file-object. You should save it and do (close ) when done. specify how to open the file. READ and WRITE are the most useful. Alone, they will open a file in ASCII mode. If you open a file for WRITE, (format "This is some text.") will put the string "This is some text." in the file represented by . Similarly, (READ ) or (TYI ) will input from the file. The manual explains more complicated things, like how to use binary files, how to redirect IO to and from files, etc. Hope this is of some help. david  Date: 25 July 1983 23:42 EDT From: Alan Bawden To: JPG @ MIT-MC cc: BUG-LISP @ MIT-MC In-reply-to: Msg of 25 Jul 1983 18:33 EDT from Jeffrey P. Golden (defun sxhash-symbol (x) (do ((l (pnget x 7) (cdr l)) (a 0 (logxor a (car l)))) ((null l) (lsh a -1))))  Date: 25 July 1983 18:33 EDT From: Jeffrey P. Golden To: BUG-LISP @ MIT-MC cc: JPG @ MIT-MC Does anyone know if the code for SXHASH called on a symbol was ever written in s-expression form as opposed to Midas? Can the code be so written? Can someone send me such code?  Date: 22 July 1983 18:23 EDT From: Alan Bawden Subject: UINT0B+11 bug quashed To: BUG-LISP @ MIT-MC, ELLEN @ MIT-MC, JPG @ MIT-MC cc: MMMM @ MIT-MC I got it I think. Patched on MC and fixed in the source. This bug was an old one, probably dating back to when the +INTERNAL-WITHOUT-INTERRUPTS was written. It only started to bite Macsyma users because the latest Macsyma starting to bind that infamous variable a lot more frequently. This might fix other seemingly interrupt related randomness, I don't know. It doesn't fix the MPV bug that JPG mentioned yesterday. If it seems to happens again to anyone, dump it out again for me please, thanks.  Date: 21 July 1983 03:52 EDT From: Jeffrey P. Golden Subject: UNWIND-PROTECT and MACSYMA To: BUG-LISP @ MIT-MC cc: KLOTZ @ MIT-MC, GUMBY @ MIT-MC, ELLEN @ MIT-MC, JPG @ MIT-MC KLOTZ@MIT-OZ 07/21/83 01:48 EDT To: bug-lisp@MIT-OZ Being an adventurous soul, I tried out a new macsyma recently. I managed to get various errors easily. For example, I would take the limit of some large sum, and while it was calculating, type ^B. This would frequently cause the error, just by itself, with no ^Z'ing involved. I don't know if this facet of the behavior has been reported, so I thought I'd mention it. I am not on BUG-LISP. GUMBY mentioned KLOTZ's note to me. I don't know if it is related to the above but there is a known UNWIND-PROTECT bug in LISP. SUM and LIMIT in MACSYMA use UNWIND-PROTECT. Anyway, here is an old bug-note I once sent to BUG-LISP. The bug still happens. (The FMULT file mentioned is quite old, so it contains CATCH instead of *CATCH. You can ignore that if you wish.) Note that it exits to DDT at a location different from UINT0B+11 . I don't know if that means it is a different bug, and that the 'current' UINT0B+11 bug is a new bug due to LISP 2138. JPG@MIT-MC (for RWG) 08/07/80 05:18:14 ~LISP If you type to a fresh MACSYMA: LOADFILE(FMULT,3,ALJABR); LIMIT(BUSTER,N,INF); , and as soon as you see the "Loading done" message for MATRUN FASL, you hit control-G, you will exit to DDT with MPV; 67277>>MOVE 12,(17) or perhaps a PURPG error. This appears to be a bug in the unwind phase of LISP's UNWIND-PROTECT code. It seems that FXPDL, FLPDL, and SPECPDL are all out of whack.  Date: Thu, 21 Jul 1983 01:48 EDT From: Leigh L. Klotz To: bug-lisp@MIT-OZ Being an adventurous soul, I tried out a new macsyma recently. I managed to get various errors easily. For example, I would take the limit of some large sum, and while it was calculating, type ^B. This would frequently cause the error, just by itself, with no ^Z'ing involved. I don't know if this facet of the behavior has been reported, so I thought I'd mention it.  Date: 21 July 1983 01:18 EDT From: Alan Bawden Subject: More bits. To: MMMM @ MIT-MC, JPG @ MIT-MC, ELLEN @ MIT-MC, BUG-LISP @ MIT-MC Date: 20 July 1983 21:10 EDT From: Moses Minta To: BUG-LI Here is the error which is suspected to be caused by a bug in tty(lisp?). I was advised to disown the job and send you this message. Will appreciate any help in solving this mystery. Thanks. Thanks! Now we have an example to study. I dumped this lisp in CRASH;LISP TTYRET and recorded the user variables in ALAN;TTYRET VARS if anyone else would like to take a look at this. Despite the fact that when this bug usually happens it is a %PJATY interrupt that is already sitting on INTPDL, in THIS case it seems to be an interrupt on the TTY: input channel! The thing that all instances do have in common, however, is that an UNWIND-PROTECT was interrupted out of (look at the gubble at the top of the stack). [I guess "TTYRET" wasn't a good name in light of this.] I still don't understand what is going on here though. BTW, I have had no trouble Ging a Macsyma that dies in this way.  GSB@MIT-ML 07/19/83 16:04:49 Re: Bug in DO when compiled. To: BEN at MIT-ML CC: (BUG LISP) at MIT-ML This is a compiler bug with undeclared fixnum arithmetic. If you declare your variables FIXNUM, as they obviously are, then it should go away, and produce better code to boot.  Date: 19 July 1983 15:50 EDT From: Kent M. Pitman To: BEN @ MIT-ML cc: BUG-LISP @ MIT-MC You're right. (defun f (a b) (do ((d a d1) (d1 b (+ d d1))) ((> d 200.)) (print (list 'D= d 'D1= d1)))) compiles wrong. I believe this is a known bug related to number compilation. I have heard it explained but don't recall the explanation so can't tell you how to predict it. Perhaps someone else on this list will volunteer it. In any case, either of (defun f (a b) (declare (fixnum a b)) (do ((d a d1) (d1 b (+ d d1))) ((> d 200.)) (declare (fixnum d d1)) (print (list 'D= d 'D1= d1)))) or (defun f (a b) (do ((d a d1) (d1 b (plus d d1))) ((greaterp d 200.)) (print (list 'd= d 'd1= d1)))) will work for you. Hope this is at least somewhat helpful. Probably you want the former; the latter is just there for contrast.  BEN@MIT-ML 07/19/83 15:28:52 Re: Bug in DO when compiled. To: (BUG LISP) at MIT-ML CC: BEN at MIT-ML A simple iteration using DO, with no global variables or anything funny, works correctly when interpreted, fails when compiled. The simple version of the bug is in BEN;DO_BUG > and DO_BUG FASL. The problem is that the update value for the first DO variable D behaves as if it had the same expression as the second variable D1. Even if this cannot be fixed in the visible future, it would be very valuable to know the nature and extent of this bug.  Date: 19 Jul 1983 09:34 EDT (Tue) From: Daniel Brotsky To: bug-lisp@MIT-OZ Subject: .INI files not loaded from subdirectories I have trouble believing that, when I am in a subdirectory, LISP does not load the LISP.INI file from my home directory. Why not? dan  Date: 17 July 1983 13:55 EDT From: Alan Bawden Subject: ERROR; 65063>>CAME 6,1642 To: JPG @ MIT-MC cc: BUG-LISP @ MIT-MC, ELLEN @ MIT-MC, MMMM @ MIT-MC In-reply-to: Msg of 17 Jul 1983 01:05 EDT from Jeffrey P. Golden I got some more bits from Moon about this problem. Possibly this is caused by Macsyma's TTY-RETURN handler getting an error when it is invoked. (MPV or write-in-read-only-memory, or similar.) Perhaps something very subtle changed when this new Macsyma was built? Even given this theory I am unable to reproduce the lossage myself. I note that Macsyma has it's own MACHINE-ERROR handler which certainly doesn't simplify the situation.  Date: 17 July 1983 01:05 EDT From: Jeffrey P. Golden To: MMMM @ MIT-MC cc: ELLEN @ MIT-MC, JPG @ MIT-MC, BUG-LISP @ MIT-MC MMMM@MIT-MC 07/16/83 23:55:43 What does the error code "65063>>CAME 6,1642" mean? If I do get this error how do i continue working in macsyma. This error takes me to DDT and :job followed by :continue does not get me back to macsyma. It appears to be caused by a bug in the tty interrupt routines in the Lisp that Macsyma is in. I do not know how you continue working with that Macsyma. (I have not seen this happen myself, but I have heard of its happening.) If this happens to you again, the best thing you can do is disown that Macsyma and send a note to BUG-LISP and/or to MACSYM so that a Lisp expert can study the broken Macsyma in the hopes of figuring out just what is causing this.  GSB@MIT-ML 07/15/83 22:17:45 Re: .lose because of intpdl To: ALAN at MIT-ML CC: (BUG lisp) at MIT-MC I think i have seen this before, but am not absolutely certain. UINT0B familiar; this may not be new.  Date: 15 July 1983 20:46 EDT From: Alan Bawden Subject: Mustn't call UINT0 from within a PI server To: BUG-LISP @ MIT-MC, MOON @ MIT-MC, ELLEN @ MIT-MC Date: 15 July 1983 01:46 EDT From: V. Ellen Golden To: ALAN Re: BUG LISP???? I have seen this twice now, but the people usually started up a new MACSYMA. Dave MOON helped RGA to save his, and he (MOON) thought it was a Lisp problem, so it might be related to the new lisp.... I send it to you (This is the one MOON fixed...). Date: 12 July 1983 16:06 EDT From: V. Ellen Golden Date: 12 July 1983 12:37 EDT From: Richard Gregory-Allen Here I am in another fix. I was running a Macsyma and had ^Z'd out to play around in the editor. When I tried to $P back into my job, I got the following message; ERROR; (ATTY;) 65063>>CAME 6,1642 6/ -41,,1642 1642/ -31,,1652 and I'm back at DDT. (I don't remember if the (ATTY;) was there before I disowned it the first time, I don't think so though.) I've got quite a bit of time invested in the session so I'd really love to be able to rescue it. I've seen this condition before (with less invested) though only since this latest version (304) of Macsyma has been installed. I've disowned the job (jobname is A) in hopes that you can somehow fix it. -------------- This error is somehow associated with the "tty handler" and MACSYMA getting control of the "tty". In general it means that the job is "broken", but I was able to get Dave MOON to look at it and he managed to get rid of the interrupt and rescue the MACSYMA. It is now sitting loose in the system as ELLEN A. To reown it and save out what you want you type :ujob ellen a Good luck! The code near the .LOSE in question: MOVE T,[-LINTPDL,,INTPDL] ;MUSTN'T CALL UINT0 FROM CAME T,INTPDL ; WITHIN A PI SERVER .LOSE I guess I would like to know what was on the interrupt PDL when this happens. (Perhaps Moon will tell me.) I can't seem to reproduce this myself, but it is a little vague just what this guy was doing. (He speaks of "disowning" as if he thinks that that is what ^Z does, or perhaps he isn't telling the whose story.) Next time it happens perhaps someone will dump the remains on the CRASH; directory for autopsy? (Although I guess that might not save all the necessary state for something interrupt-driven.) In the meantime I guess It's time to learn about how interrupts work. Perhaps anyone on bug-lisp who might have an idea why any changes made in the last year should change anything interrupt related (I just examined all of the recent changes, and I don't see any obvious candidates) should speak up.  Date: 10 July 1983 15:29 EDT From: Kent M. Pitman Subject: bug in #\foo To: GJC @ MIT-MC cc: BUG-LISP @ MIT-MC In-reply-to: Msg of 4 Jul 1983 16:09 EDT from George J. Carrette Date: 4 July 1983 16:09 EDT From: George J. Carrette To: BUG-LISP Re: bug in #\foo #\screw-me-at-readtime or #\screw-me-at-runtime. Both these forms read in as NIL instead of giving an error. Therefore a typo such as (TYO #\CP) is not caught until runtime. A feature? ----- Yes, actually. I believe this is what allows #Q#\CLEAR-INPUT to not cause an error at read time. I suspect the value to conditionalization is worth more than the spelling-correction feature, given the choice. On the other hand, it might be possible to have #+, #-, etc. bind something that disabled what would otherwise be an error at readtime so you could get the best of both worlds; I'm not volunteering to make that change, though...  Date: 4 July 1983 20:51 EDT From: Kent M. Pitman To: BUG-LISP @ MIT-MC I responded to JGA's query about DO-WITH-TTY-OFF, etc. with some suggestions about where timing errors might be coming from and with the recommendation that he keep echo globally turned off rather than turning it on and off all the time. It's doubtful that anything in his note is a lisp bug; I think he was just looking for a good place to seek advice.  Date: 4 July 1983 18:17 EDT From: John G. Aspinall Subject: a question of interrupts (I guess) To: BUG-LISP @ MIT-MC cc: JGA @ MIT-MC I have a problem that seems like some sort of synchronization thing, but I don't really understand it. The following function queries a Tektronix terminal for its joystick position. (defun tek-get-ginput () (+tyo #\ALT graphic-output) (+tyo #\TEK-GINMODE graphic-output) (prog1 (do-with-tty-off (list (tyi) (+ (lsh (logand (tyi) #o37) 5) (logand (tyi) #o37)) (+ (lsh (logand (tyi) #o37) 5) (logand (tyi) #o37)))) (tyi))) Graphic-output is a output stream, open in image mode, to the tty. The two-character sequence (#\tek-ginmode is defined as #o32) puts the Tek in GIN (Graphic INput) mode. The regular cursor disappears, and is replaced with an arrow. The user points this at wherever, and hits any key. The Tek transmits a 6 character sequence - the key typed is first, then four (non-control) characters containing the coordinates (encoded obviously above), then a . The 's job is to return the Tek to it's previous mode (not GIN mode) so it ought to be echoed, the other chars probably shouldn't be echoed, hence the code above. Now the problem. I put this in a real simple command loop to trace a pattern on the screen - m:move, d:draw, etc. This thing returns a lisp form that can be evaluated for the pattern again. (defun trace () (do ((com (tek-get-ginput) (tek-get-ginput)) (form nil)) ((or (= (car com) #/q) (= (car com) #/Q)) (cons 'progn (nreverse form))) (caseq (car com) ((#\FF) (graphout (page) (do ((form (reverse form) (cdr form))) ((null form)) (eval (car form))))) ((#/m #/M) (push (rplaca com 'move) form)) ((#/d #/D) (push (rplaca com 'draw) form)) ((#\RUBOUT) (pop form))))) This works fine, IF I TYPE SLOWLY ENOUGH. (This, on a 1200 baud Vadic, MC lightly loaded.) On the other hand, two keystroke commands within (I would guess) 0.5 second of each other, put it in a state where it looks as if something's out of synch. Several keystrokes later, it sometimes returns to normal, having missed all those commands, but I can't reproduce that reliably. All suggestions welcome - and thanks in advance.  Date: 4 July 1983 16:09 EDT From: George J. Carrette Subject: bug in #\foo To: BUG-LISP @ MIT-MC #\screw-me-at-readtime or #\screw-me-at-runtime. Both these forms read in as NIL instead of giving an error. Therefore a typo such as (TYO #\CP) is not caught until runtime. A feature?  Date: 1 July 1983 05:33 EDT From: Kent M. Pitman To: BUG-LISP @ MIT-MC On OZ, with TERMINAL GLASS, (CURSORPOS 'C) gives I/O ERROR DURING OUTPUT. Also, (CURSORPOS n m) gives such an error. Certainly (CURSORPOS 'C) should just try doing (CURSORPOS 'A) if it can't work correctly. Also, the setting of cursor position is a little tougher; I guess I think it should just be a no-op and that people who care should check the filemodes of the tty. The problem with (CURSORPOS 'C) is that just about every program in existence clears the screen at one time or another, and those programs are worthless on a glass tty as a result. I'd not be surprised to find this was some VTS screw, but I don't really care; I assume we can patch around it from Maclisp in any case...  Date: 29 June 1983 12:38 EDT From: Charles F. F. Karney Subject: Cursor positioning with Tops-20 lisp (in Macsyma on XX) To: BUG-LISP @ MIT-MC cc: JPG @ MIT-MC If I perform the following code: (setq tt (open '|tty:| '(tty out image single))) (defun ttt () (mapcar (function (lambda (x) (+tyo x tt))) '(143. 20. 20. 65. 66. 67. 143. 0. 0.)) (tyi)) (ttt) Then 'ABC' gets written out at position 20,20 and the cursror homes. However following this don't get generated. E.g. t ==> T (on the same line). (cursorpos 'top) clears this condition. This works OK in ITS.  Date: 26 June 1983 14:59 EDT From: Kent M. Pitman Subject: DUMPARRAYS etc. To: JPG @ MIT-MC cc: CFFK @ MIT-MC, BUG-LISP @ MIT-MC Oops. Well, at one time within the last two years it was definitely the case that FILLARRAY to a file array on Twenex gave an error that indicated it had a wrong type arg. I was trying to find why DUMPARRAYS, etc didn't work on Twenex at the time and that was the reason. I guess that's been fixed now -- Sorry, Jeff, I wasn't reading your note carefullly and didn't notice 'til I'd already sent my reply that you had had at least some success on Twenex. I'm not surprised you found my reply confusing. Replies sent by people not paying attention to what's being complained about frequently come out that way, I guess.  Date: 24 June 1983 05:31 EDT From: Jeffrey P. Golden Subject: DUMPARRAYS etc. To: KMP @ MIT-MC, CFFK @ MIT-MC cc: BUG-LISP @ MIT-MC, JPG @ MIT-MC KMP@MIT-MC 06/23/83 18:01:59 To: JPG at MIT-MC CC: (BUG LISP) at MIT-MC, CFFK at MIT-MC JPG@MIT-MC 06/23/83 04:24 EDT To: CFFK cc: BUG-LISP CFFK@MIT-MC 06/22/83 23:47:11 To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC In TOPS-20 (with MACSYMA--if that matters) (array f flonum 3) (fillarray 'f '(2.0 3.0 4.0)) (dumparrays '(f) '((ps cffk) tst out)) ==> ? PA1050: ADDRESS CHECK OR ILLEGAL UUO AT LOCATION 415263 When I try this on OZ I find it works fine. When I try this in Macsyma on XX the problem I have is file offline, so I don't know how you got the error message you got. I can't fix this on XX now as someone changed the password to on me denying me access to that directory. I'll attempt to have this all fixed tomorrow. DUMPARRAYS is an ITS-only package. This is becuase FILLARRAY to a file object isn't implemented on Tops-20. I find Kent's response strange, because I already reported that I tried it on OZ and it worked fine. CFFK's problem was that he was using a clobbered BLTARRAY file on XX. Anyway, I now report that this stuff now works also on XX.  Date: 23 June 1983 18:01 EDT From: Kent M. Pitman To: JPG @ MIT-MC cc: BUG-LISP @ MIT-MC, CFFK @ MIT-MC In-reply-to: Msg of 23 Jun 1983 04:24 EDT from Jeffrey P. Golden Date: 23 June 1983 04:24 EDT From: Jeffrey P. Golden To: CFFK cc: BUG-LISP CFFK@MIT-MC 06/22/83 23:47:11 To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC In TOPS-20 (with MACSYMA--if that matters) (array f flonum 3) (fillarray 'f '(2.0 3.0 4.0)) (dumparrays '(f) '((ps cffk) tst out)) ==> ? PA1050: ADDRESS CHECK OR ILLEGAL UUO AT LOCATION 415263 When I try this on OZ I find it works fine. When I try this in Macsyma on XX the problem I have is file offline, so I don't know how you got the error message you got. I can't fix this on XX now as someone changed the password to on me denying me access to that directory. I'll attempt to have this all fixed tomorrow. ----- DUMPARRAYS is an ITS-only package. This is becuase FILLARRAY to a file object isn't implemented on Tops-20.  Date: 23 June 1983 04:24 EDT From: Jeffrey P. Golden To: CFFK @ MIT-MC cc: BUG-LISP @ MIT-MC CFFK@MIT-MC 06/22/83 23:47:11 To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC In TOPS-20 (with MACSYMA--if that matters) (array f flonum 3) (fillarray 'f '(2.0 3.0 4.0)) (dumparrays '(f) '((ps cffk) tst out)) ==> ? PA1050: ADDRESS CHECK OR ILLEGAL UUO AT LOCATION 415263 When I try this on OZ I find it works fine. When I try this in Macsyma on XX the problem I have is file offline, so I don't know how you got the error message you got. I can't fix this on XX now as someone changed the password to on me denying me access to that directory. I'll attempt to have this all fixed tomorrow.  Date: 22 June 1983 23:47 EDT From: Charles F. F. Karney To: BUG-LISP @ MIT-MC cc: JPG @ MIT-MC In TOPS-20 (with MACSYMA--if that matters) (array f flonum 3) (filarray 'f '(2.0 3.0 4.0)) (dumparrays '(f) '((ps cffk) tst out)) ==> ? PA1050: ADDRESS CHECK OR ILLEGAL UUO AT LOCATION 415263  Date: 16 June 1983 20:05 EDT From: Alan Bawden Subject: New MacLisp now installed on MC. To: BUG-LISP @ MIT-MC, INFO-MACLISP @ MIT-MC, (*MSG *MC) @ MIT-MC I have just installed a new MacLisp (version 2138) on MC forged from the latest sources. This corresponds almost exactly to the XLISP that has been available on MC for the last month or so. Since most of the changes to the sources since the last MacLisp were made (over a year ago) had to do with IO on 20X, there is little to watch out for. A matching COMPLR has been installed as well, along with a MACLISP and a SHARABLE built on top of it. The previous versions of LISP and COMPLR have been renamed to OLISP and OCOMPLR. People who maintain dumped systems are encouraged to update their entries in LISP;LOCK >. I garbage collected quite a few entries myself, and several dumps are going to disappear from disk soon unless someone speaks up for them.  Date: 14 June 1983 14:31 EDT From: Alan Bawden Subject: files migrated on oz To: CENT @ MIT-ML cc: BUG-LISP @ MIT-ML In-reply-to: Msg of 06/14/83 06:00:30 from CENT at MIT-ML I have installed myself as the owner of the MacLisp-related directories on OZ.  CENT@MIT-ML 06/14/83 06:00:30 Re: files migrated on oz To: (BUG LISP) at MIT-ML if there is someone locally responsible for worrying about this sort of thing, please create a DIRECTORY.OWNER file on this dir so i don't have to bother everyone when files get reaped. ---------- Date: 14-Jun-83 02:46:24 From: Dumper Reply-to: File-Retrieve To: BUG-BACKUPERS Subject: Migrated files The following files have been migrated: PS:6003.LISP.4 PS:LISP.EXE.2131 PS:TTY.FASL.18  Date: Saturday, 4 June 1983, 19:32-EDT From: David M. J. Saslav Subject: binding 't to other things (like nil) To: bug-lisp@MIT-OZ I don't think it's a good idea to be able to say (setq 't ni), since this makes forms like (cond (t 45) (nil 50) ((print "me") 100)) return: ME 100  Date: 28 MAY 83 17:45 PDT From: JONL.PA@PARC-MAXC.ARPA Subject: MAKHUNK (yuch!) To: alan%oz@mit-mc.ARPA cc: bug-lisp@mit-mc.ARPA All this weirdness is not only documented, but was the subject of lengthy discussions several years ago (I thought you were a participant then but maybe not). The conflict is between HUNKs interpreted as a cons cell with extra slots, and between HUNKs interpreted as a primitive kind of VECTOR. The syntax for the latter, (A B C . ) was choses precisely because it had no other reasonable interpretation.  Date: Fri, 27 May 1983 01:08 EDT From: Alan Bawden To: bug-lisp@MIT-OZ Subject:Yuch! I just discovered that the setting of the MAKHUNK switch controls TWO things at once. Setting it to T makes (makhunk 2) return a hunk (which I like), and it also makes '(1 . 2 .) return a hunk (which I think sucks, I would much prefer to get a dot context error). Yuch!  Date: 15 May 1983 12:02 EDT From: George J. Carrette Subject: TTY.LSP.24 fixes bugs in TTY.KMP.20 To: KMP @ MIT-OZ cc: BUG-LISP @ MIT-OZ, PHW @ MIT-OZ In-reply-to: Msg of Sat 14 May 1983 17:01 EDT from KMP at MIT-OZ I could have sworn that I diked out the SUBLOAD and SI:GENTEMP stuff from TTY a while ago. Indeed, check out LIBDOC;TTY 19, which was written in NOV '82. At least the FASL for this was moved to OZ also, when I found I got screwed by missing autoload files. Evidently the OZ version was further hacked later on by someone else, reintroducing the lossage. Blame me for not moving the source to OZ also. N.B. All those who would hack Maclisp on OZ: The sources to Maclisp have not ever been considered to be on OZ. The software was installed by "helpful" outsiders before responsible local maclisp hackers could act. Since then it has been fun to watch. Kent, if it weren't for people like you fixing up things maybe we could have the total collapse that would lead to a fresh start though? -gjc  Date: Sat, 14 May 1983 17:01 EDT From: KMP@MIT-OZ To: BUG-LISP@MIT-OZ cc: PHW@MIT-OZ Subject: TTY.LSP.24 fixes bugs in TTY.KMP.20 PHW tried to use my TTY package (containing DO-WITH-TTY-ON, DO-WITH-TTY-OFF, etc) and found it broken because the FASL file was trying to INCLUDE LISP:SUBLOAD. The reason it was trying to do this was to get around some hassle with SI:GEN-LOCAL-VARIABLE, which JONL had patched the source to use in place of GENSYM. The reason the INCLUDE happened at the wrong time was because someone wrote (IF (STATUS FEATURE ITS) (INCLUDE ...) (INCLUDE ...)) instead of (INCLUDEF (IF ...)). The macros in this file are the sort that other macros do not expand into. They are the kind of thing which programs expand into and as such, with the exception of a few cases of "#%", GENSYM is completely reasonable and has no problems about it. In any case, I have seen far too many bugs caused by the fact that these things do not primitively autoload and I don't think it's worth using either GENTEMP or SI:GEN-LOCAL-VARIABLE unless they become primitively available. They are inappropriate for use in libraries which are not maintained as an essential feature of the system until they are primitively accessible. I would appreciate if people would refrain from adding stupid little "features" like this to my libraries without at least telling me that they have done so and without checking that the "features" work. I tend to check the software I release relatively carefully and this sort of thing gives my software a bad name. In this case, the FASL file wouldn't even LOAD so it's quite clear that no one had tested it. I wrote OZ:PS:TTY.LSP.24 and compiled it. It seems to work fine. Please report bugs. By the way, this version also includes another macro called BIND-TTYINT which allows a let-style syntax for binding TTYINT things. eg, (BIND-TTYINT ((#^B NIL) (#^H #^B)) ...body...) binds ^B to no interrupt and Backspace to work like ^B for the invocation of the BODY. I'll copy this back to ITS later today in case anyone finds it easier to pick up the new versions from there than from here. --kmp  Date: 9 May 1983 20:10 EDT From: Robert W. Sjoberg To: BUG-LISP @ MIT-MC Regarding my last message: please disregard...the number given was a bignum, not a fixnum.. Sorry.  Date: 9 May 1983 20:08 EDT From: Robert W. Sjoberg To: BUG-LISP @ MIT-MC Why is 514255554455 an unacceptable numeric value when given to the fixnum operations? (This is an octal value.) It looks pretty good to me....  Date: 6 May 1983 01:40 EDT From: Alan Bawden Subject: Macrodef To: MALACHI @ SU-SCORE cc: BUG-LISP @ MIT-MC In-reply-to: Msg of Thu 5 May 83 14:26:24-PDT from Yoni Malachi Date: Thu 5 May 83 14:26:24-PDT From: Yoni Malachi Re: Macrodef Where is it? What is it? (Are you looking for DEFMACRO perhaps?)  Date: Thu 5 May 83 14:26:24-PDT From: Yoni Malachi Subject: Macrodef To: bug-maclisp@SU-SCORE.ARPA Where is it? Yoni. -------  Date: Thursday, May 5, 1983 2:58AM-EDT From: David Vinayak Wallace Subject: EB's bug To: bug-lisp at MIT-OZ I just got it too (in COMPLR): ;626625 NOT ASCII VALUE Was this determined to be (gasp) a twenex bug?  Date: 2 May 1983 16:56 EDT From: Alan Bawden Subject: ;229044. NOT ASCII VALUE To: EB @ MIT-OZ cc: BUG-LISP @ MIT-MC In-reply-to: Msg of Mon 2 May 1983 00:48 EDT from EB at MIT-OZ Date: Mon, 2 May 1983 00:48 EDT From: EB at MIT-OZ Sometimes when I continue Twenex Maclisp and type at it quickly, it gets an error saying ;229044. NOT ASCII VALUE or some such thing. Me too, although I have never observed it to have any correlation to how fast I was typing. A clearly related behavior I have also noticed: various control character seem to accumulate in my Lisp input buffer as I continue Lisp over and over.  Date: Mon, 2 May 1983 00:48 EDT From: EB@MIT-OZ To: bug-lisp@MIT-MC Sometimes when I continue Twenex Maclisp and type at it quickly, it gets an error saying ;229044. NOT ASCII VALUE or some such thing.  Date: Mon, 2 May 1983 00:36 EDT From: EB@MIT-OZ To: bug-complr@MIT-MC CC: Bug-Lisp@MIT-MC @COMPLR on OZ gets its JFNs in restricted mode. The EXEC can't find them, and SYSDPY says they are restricted. This is a screw, because there is no way to close or see the _UNFA_ files if random errors happen in the middle of a compilation. I complained long ago about the fact that Twenex Maclisp treats files this way, and so did many other people, but I don't know if the problem was ever fixed. Is Twenex Maclisp still broken, or do we just have an old COMPLR on OZ?  Date: 25 April 1983 04:13 EDT From: David C. Plummer Subject: ASSLIS is such a kludge! To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-LISP @ MIT-MC Date: 24 April 1983 18:31 EST From: Alan Bawden File deletion is supposed to work on the core-link, and I distinctly remember that in the (recent) past it HAS worked (DCP might remember otherwise?). I don't remember if it is supposed to or not. If anyone wants a few cheap laughs (and can read Midas), they should take a look at MC:L;ASSLIS >. It's certainly the kludgiest program I've seen in a long time. I thought I could read Midas, but I have a hard time reading that thing.  Date: 24 April 1983 18:31 EST From: Alan Bawden Subject: ASSLIS is such a kludge! To: BUG-ITS @ MIT-MC cc: BUG-LISP @ MIT-MC CLU:.FILE. (DIR) currently lists: LISP MIDAS BARQIO CLOSED-> HACTRN FOO MIDAS BARQIO CLOSED-> HACTRN L MIDAS BARQIO CLOSED-> HACTRN L MIDAS FOOQIO CLOSED-> HACTRN The reason it says " HACTRN" is that it used to say "ALAN HACTRN" until I logged out that job. Before that all four entries were in CLOSED->CLOSED state and I tried to delete tham using  in DDT. Instead of deleting them it seems to have decided I wanted to USE them. I checked, and DDT did not still have any CLx channels. I guess these will stay here until MC crashes next. File deletion is supposed to work on the core-link, and I distinctly remember that in the (recent) past it HAS worked (DCP might remember otherwise?). If anyone wants a few cheap laughs (and can read Midas), they should take a look at MC:L;ASSLIS >. It's certainly the kludgiest program I've seen in a long time.  Date: 21 April 1983 00:55 EST From: Alias for WGD Sender: ___070 @ MIT-MC To: BUG-LISP @ MIT-MC Someone should dump out a new COMPLR with the latest version of SHARPM in it---its a hassle to have to explicitly check if /#-macro-/| is fbound to see if we have the #| macro.  Date: Tuesday, 19 April 1983, 00:26-EST From: David Vinayak Wallace To: WILLIS at MIT-ML Cc: bug-lisp at ml In-reply-to: The message of 18 Apr 83 23:04-EST from WILLIS at MIT-ML Try :TCTYP PRINTING or :TCTYP GLASS.  Date: 19 April 1983 00:17 EST From: Alan Bawden Subject: IMAGE mode IO To: WILLIS @ MIT-ML cc: BUG-LISP @ MIT-ML In-reply-to: Msg of 04/18/83 23:04:55 from WILLIS at MIT-ML Well, its a real feature of ITS that the system always presents programs with a virtual terminal so that they don't have to know the peculiarities of the user's actual terminal. LISP is no exception to this; its TYO function just sends a character to that virtual terminal. (So, No, I can't imagine your shock and horror, since I find it to be rather well-modularized myself.) Now naturally there are times when you wish to get around the virtual terminal for some special application. ITS allows programs that know what they are doing to open the TTY device in what is called IMAGE mode. In this mode characters output to the terminal (TTY) are just transmitted directly. From LISP you can open the terminal in this mode by doing: (OPEN '|TTY:| '(OUT TTY IMAGE)) This form returns a file-object. Save that file-object and pass it to the TYO function as a second argument. Then whatever you passed as the first argument, should be sent directly to your device..  Date: Tuesday, 19 April 1983, 00:08-EST From: Kent M. Pitman Subject: WILLIS@ML's TYO gripe To: bug-lisp at mc I sent him a note suggesting he look into IMAGE mode I/O.  WILLIS@MIT-ML 04/18/83 23:04:55 To: (BUG LISP) at MIT-ML CC: WILLIS at MIT-ML I have been trying for some time to print out text files on a printer connected to my ADDS Viewpoint terminal. At the cost of great pain and agony I managed (I think) to write a tiny LISP program to send a file to the terminal without using the ITS PRINT utility, since this does various things intended for the terminal which foul up the printer output. Imagine my shock and horror to find that (apparently) even the tyo subr goes via CRTSTY, and therefore does annoying things like outputting spaces (ASCII 32.) as cursor control characters. Is there a LISP subr which sends absolutely nothing but the given ASCII code to my modem? Alternatively, is there a system variable which I can reset to make the system think (temporarily) that I have a totally dumb terminal?  Date: 14 April 1983 0101-EST From: Dave Touretzky at CMU-CS-A To: bug-lisp at MIT-MC Subject: CMU MacLisp broken CC: Scott Fahlman , Leonard Zubkoff , Neal Feinberg , Richard Goldschmidt at CMU-CS-A CMU recently, with no prior warning, changed the name of its primary TOPS-10 machine from CMU10A to CMUCSA. As a result, MacLisp no longer recognizes us as a CMU site: (STATUS OPSYSTEM-TYPE) returns TOPS-10 instead of CMU. This has in turn broken some of the code in the CMU MacLisp programming environment. I traced the problem to two lines of code a couple of screenfuls past the label D10SET. The solution is to replace the string "CMU10" with the string "CMUCS" where it appears on those two lines. Would somebody like to make the change in the sources? -- Dave Touretzky  Date: 12 April 1983 02:19 EST From: Pandora B. Berman Subject: file migrated To: bug-lisp @ MIT-OZ dumper was trying to send this, but didn't know who to send it to. to tell it, create a file called DIRECTORY.OWNER. which contains the name of someone responsible for the dir; then dumper will send to that person. ---------- Date: 11 Apr 1983 0538-EST From: The Mailer Daemon To: Subject: Message of 11-Apr-83 05:35:32 Message failed for the following: LIBLSP@MIT-OZ: No such mailbox ------------ Date: 11-Apr-83 05:35:32 From: DUMPER To: LIBLSP Subject: Migrated files The following files have been migrated: PS:APROPOS.FASL.1 -------  Date: 11 April 1983 21:08 EST From: Kent M. Pitman To: bagley @ MIT-OZ cc: BUG-LISP @ MIT-MC oops. i meant ((LIBLSP) LISPM).. sorry 'bout the confusion. --kmp  Date: 11 April 1983 21:08 EST From: Kent M. Pitman To: bagley @ MIT-OZ cc: BUG-LISP @ MIT-MC Use ((LMLIB) LISPM) for now. Some of that stuff will become autoloading in a Lisp release soon, I think.  Date: 11 Apr 1983 20:00 EST (Mon) From: Steven C. Bagley To: bug-lisp@MIT-OZ Subject: lispm vs. maclisp Has somebody written a package to allow some lispm code to run in maclisp? I realize this isn't completely possible, but I'm thinking of such functions as DOLIST, which don't exist in maclisp.  Date: Thu, 7 Apr 1983 05:17 EST From: Alan Bawden To: bug-lisp@MIT-OZ Subject:I though we fixed this? In my current lisp job on OZ: (status ttysize) (30 . -117) Is this a "fixed in the source but not patched"?  Date: 7 April 1983 04:24 EST From: Alan Bawden To: BUG-LISP @ MIT-MC Is LISP:LISP.SYMBOLS.2129 not the place I should expect to find the symbols for MacLisp version 2129 currently running on OZ? They don't appear to be correct.  Received: from SCRC-MYSTIC by SCRC-TENEX with CHAOS; Wed 6-Apr-83 01:11:38-EST Date: Wednesday, 6 April 1983, 01:07-EST From: David C. Plummer Subject: LOOP macro expansions To: BUG-lisp@MIT-MC, bug-Lispm@SCRC-TENEX, BUG-LOOP@MIT-ML Cc: BSG@SCRC-TENEX, GSB@MIT-ML In-reply-to: The message of 5 Apr 83 19:23-EST from DCP at SCRC-TENEX Small warning to those who put my suggestion in their private versions of LOOP: Be sure to also get the EVAL-WHEN at the beginning of the file that sets up all the features/non-features. Failure to do this will, among other things, cause collection to fail on the LispM. I just found this out the hard way...  Date: 5 April 1983 22:05 EST From: George J. Carrette Subject: LOOP macro expansions into LET To: DCP @ SCRC-TENEX cc: BUG-LISP @ MIT-MC, BUG-LOOP @ MIT-ML, GSB @ MIT-ML, BSG @ SCRC-TENEX, bug-Lispm @ SCRC-TENEX In-reply-to: Msg of 5 Apr 1983 19:23-EST from DCP at SCRC-TENEX In PDP-10 maclisp, if you wanted to take up GSB's suggestion, you could have LET and LET* in the interpreter autoload "LIBLSP;LETFEX FASL" which is an implementation of LET optimized for the interpreter, it defines 'em as FEXPRs. Not only is it fast and cons no extra storage, it is about 1/6 the size of the macro let implementation, and comes with a money-back guarantee.  Date: Tuesday, 5 April 1983 19:23-EST From: DCP at SCRC-TENEX To: Glenn S. Burke Cc: BSG at SCRC-TENEX, BUG-lisp at MIT-MC, bug-Lispm at SCRC-TENEX, BUG-LOOP at MIT-ML Subject: LOOP macro expansions In-reply-to: The message of 5 Apr 1983 16:07 EST from Glenn S. Burke I see your point about memoizing. *sigh*. So perhaps there is a need for #+/-LOOP-uses-LET feature. I tried to be careful about when LETs where merged into LET*s. I think I got it right... I, for sure, won't make the "official" change, since I have no idea where the correct source is and how it must propigate. (For now I've just put it into my LispM environment.)  Date: 5 April 1983 16:07 EST From: Glenn S. Burke Subject: LOOP macro expansions To: BUG-LOOP @ MIT-ML, BSG @ SCRC-TENEX, DCP @ SCRC-TENEX cc: BUG-lisp @ MIT-MC, bug-Lispm @ SCRC-TENEX There is a good reason why the variables are collected suitably for let, and that is because they originally were. As i remember it, loop used let even when it was coding its own destructuring (as it does in the multics & lispm implementations). The killer, though, was all those macro expansions in interpreted code (Maclisp in particular). I mean, we were talking about using up 10% of the address space of pdp10 maclisp running an interpreted program, just to memoize those LET macro expansions! (That was Martin's parser, when it ran (mostly) interpreted.) Because of that kind of lossage, loop (and LSB and various other things i've written) generally try to expand into the simplest possible forms. It's been worth it from the point of view of those running out of address space. Otherwise, i really don't care. A special-form let makes this much more attractive. Just don't break the pdp10 version. (Remember that not all the lets can be merged into let*s too.) If no one else gets to it, i'll look at this in a day or two when i'm done with some documentation and bolio hacking.  Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Tue 5-Apr-83 09:08:54-EST Date: Tuesday, 5 April 1983, 09:04-EST From: Bernard S. Greenberg Subject: LOOP macro expansions To: DCP@SCRC-TENEX, bug-Lispm@SCRC-TENEX, bug-lisp@MIT-MC In-reply-to: The message of 5 Apr 83 04:18-EST from David C. Plummer Date: Tuesday, 5 April 1983, 04:18-EST From: David C. Plummer [Please forward this to the correct mailing lists; I'm not quite sure what the correct audience is.] I would like to change LOOP-TRANSLATE-1 to use LET for the local variables it creates instead of using LAMBDA. This is for expansion readability. The relevent code fragment is below. You will notice that internally loop collects the variables in a manner nearly directly suited for LET. Perhaps #+/-Lispm is not the correct crition. Perhaps a new FEATURE status is needed which determines if the target has the LET macro or special form. I have not changed any sources. Which Lisps, if any, do not support LET? Perhaps previous instantiations of Multics, but that's been fixed years ago. Multics doesn't have LET*, though, although that could be fixed faster than it would take to discuss it. I, for one, am greatly in favor of DCP's proposal.  Received: from SCRC-MUDDY by SCRC-TENEX with CHAOS; Tue 5-Apr-83 05:45:35-EST Date: Tuesday, 5 April 1983, 05:41-EST From: David C. Plummer Subject: LOOP macro expansions To: DCP@SCRC-TENEX, bug-Lispm@SCRC-TENEX, bug-lisp@MIT-MC In-reply-to: The message of 5 Apr 83 04:18-EST from David C. Plummer While we're at it, we could combine multiple single LETs into LET*s. I don't suggest you take this verbatim, since I am making a few assumptions on the internal data structures as the macro gets built. ('t #+Lispm (setq tem (if (and (= (length vars) 1) (listp tem) (listp (car tem)) (or (eq (caar tem) 'let*) (and (eq (caar tem) 'let) (= (length (cadar tem)) 1)))) `(let* (,(car vars) ,.(cadar tem)) ,.(cddar tem)) `(let ,(reverse vars) ,.tem))) #-Lispm (let ((lambda-vars ()) (lambda-vals ())) (do ((l vars (cdr l)) (v)) ((null l)) (cond ((atom (setq v (car l))) (push v lambda-vars) (push () lambda-vals)) ('t (push (car v) lambda-vars) (push (cadr v) lambda-vals)))) (setq tem `((lambda ,lambda-vars ,.tem) ,.lambda-vals))))  Date: Tuesday, 5 April 1983, 04:18-EST From: David C. Plummer Subject: LOOP macro expansions To: bug-Lispm at SCRC-TENEX, bug-lisp at mc [Please forward this to the correct mailing lists; I'm not quite sure what the correct audience is.] I would like to change LOOP-TRANSLATE-1 to use LET for the local variables it creates instead of using LAMBDA. This is for expansion readability. The relevent code fragment is below. You will notice that internally loop collects the variables in a manner nearly directly suited for LET. Perhaps #+/-Lispm is not the correct crition. Perhaps a new FEATURE status is needed which determines if the target has the LET macro or special form. I have not changed any sources. ('t #+Lispm (setq tem `(let ,(reverse vars) ,.tem)) #-Lispm (let ((lambda-vars ()) (lambda-vals ())) (do ((l vars (cdr l)) (v)) ((null l)) (cond ((atom (setq v (car l))) (push v lambda-vars) (push () lambda-vals)) ('t (push (car v) lambda-vars) (push (cadr v) lambda-vals)))) (setq tem `((lambda ,lambda-vars ,.tem) ,.lambda-vals))))  Date: 4 April 1983 14:35 EST From: Alan Bawden Subject: LOOP, et al. (a bit of a flame, sorry) To: Gumby @ MIT-OZ cc: Nessus @ MIT-EECS, bug-lisp @ MIT-OZ, PONDY @ MIT-OZ In-reply-to: Msg of 4 Apr 1983 03:36-EST from David Vinayak Wallace I am getting pretty tired of finding messages in my mailbox from people crapping on me for the fact that I use LOOP.  Date: 4 Apr 1983 10:00 EST (Mon) From: Peter Andreae To: David Vinayak Wallace Cc: bug-lisp@MIT-OZ, Nessus@MIT-EECS Subject: LOOP, et al. (a bit of a flame, sorry) In-reply-to: Msg of 4 Apr 1983 03:36-EST from David Vinayak Wallace Thanks, I think I agree with you. Several people sent me nice DO* macros which I will probably use. PONDY  Date: Monday, 4 April 1983, 03:36-EST From: David Vinayak Wallace Subject: LOOP, et al. (a bit of a flame, sorry) To: PONDY@MIT-OZ CC: Nessus@MIT-EECS, bug-lisp@MIT-OZ Date: 31 Mar 1983 1742-EST From: Nessus at MIT-EECS (Doug Alan) I dunno about DO*, but there is a very nice macro called LOOP that does almost every you would ever want and more. Documentation (if you can parse it) is available in the Lisp Machine Manual. It autoloads into MacLisp. DO* exists for the lisp machine; you can probably take its definition and put it in maclisp. GSB wrote LOOP in maclisp. It is documented in an AI memo. Caveat: I (among many others) DON'T think it is a very nice macro. On the other hand, many people love it. There have been many flames on the subject; here is a brief synopsys: o It has a pascal-like keyword syntax which is hard for humans to parse, o Its behavior is not clearly defined in any but the simplest of cases. Therefore, you rely heavily on MACROEXPAND when writing and debugging LOOP paths, and even then you don't always know when things get evaluated. o Its control structure (the separation of path definitions from the body of the form, and the interleaving of loop controls with the loop body) is just plain weird. o It will make your code less understandable to many people. I don't want to re-open this style discussion; many people use loop and are happy with it. Talk to some maclisp hackers about it if you want to know more; other arguments WERE brought up. I don't think that many BUG-LISP people want to see these flames go by.  Date: 31 Mar 1983 1742-EST From: Nessus at MIT-EECS (Doug Alan) Subject: Re: do To: PONDY at MIT-OZ, bug-lisp at MIT-OZ In-Reply-To: Your message of 31-Mar-83 1601-EST I dunno about DO*, but there is a very nice macro called LOOP that does almost every you would ever want and more. Documentation (if you can parse it) is available in the Lisp Machine Manual. It autoloads into MacLisp. -Doug -------  Date: 31 Mar 1983 14:21 EST (Thu) From: Peter Andreae Subject: do To: bug-lisp@MIT-OZ DO is a very nice function, but it lacks something that LET has :- a sequential version. Ie, would it be possible to have DO* that assigns the variables in the variable list sequentially rather than in parallel? (maybe one already exists. If so, are there any pointers to where it might be found?) PONDY.  Date: Sun, 20 Mar 1983 01:21 EST From: Jerry Roylance To: Alan Bawden Cc: Alan@MIT-OZ, BUG-LISP@MIT-MC, Daniel@MIT-OZ Subject: GLR Gets Confused About MOVE direction In-reply-to: Msg of 19 Mar 1983 23:53 EST from Alan Bawden Alan, Yes, the code is correct and yes I was thinking PDP-11 (what's +-1 among friends). I do, however, have some code that runs interpreted but not compiled; it's bug will have to be found later. Jerry  Date: 19 March 1983 23:53 EST From: Alan Bawden Subject: COMPLR Gets Confused About Register Allocation To: GLR @ MIT-OZ cc: BUG-LISP @ MIT-MC, Daniel @ MIT-OZ, Alan @ MIT-OZ In-reply-to: Msg of Sat 19 Mar 1983 23:32 EST from Jerry Roylance The code you sent looks 100% correct to me. Perhaps you don't remember that (IDIVI 7. 12.) leaves the remainder in accumulator 8? (Or perhaps you think that this is a PDP-11?)  Date: Sat, 19 Mar 1983 23:32 EST From: Jerry Roylance To: BUG-LISP@MIT-OZ Subject: COMPLR Gets Confused About Register Allocation cc: Daniel@MIT-OZ The (MOVE 7. 8.) in the lap code below should be (MOVE 8. 7.) (DEFUN BUG (FOO) (DECLARE (FIXNUM FOO)) (1+ (\ FOO 12.))) '(THIS IS THE LAP FOR ((PS GLR) BUG LSP /1)) '(COMPILED BY LISP COMPILER /936 COMAUX /25 PHAS1 /85 MAKLAP /80 INITIA /120) ;COMPILED ON MARCH 19, 1983, AT 11:26 PM (DEFPROP BUG 17863852910 EXPR-HASH) (LAP BUG SUBR) (EVAL (SETQ IBASE 10.)) (ARGS BUG (() . 1.)) (MOVE 7. 0. 1.) (IDIVI 7. 12.) (ADDI 8. 1.) (MOVE 7. 8.) (JSP T FXCONS) (POPJ P) ()  Date: Tuesday, 15 March 1983 14:17 EST From: Alan Bawden To: Bug-Lisp@MIT-MC Subject: (very) old pathname system: is this right? (open '((ps alan) 2x3)) #FILE-IN-|PS:2X3.LSP.9|-71740 (close *) T (namestring '((ps alan) 2x3)) |PS:2X3.*| ;??? (open *) ;(OPEN |PS:2X3.*|) NO SUCH FILE TYPE ;BKPT IO-LOSSAGE  Date: 7 March 1983 21:53 EST From: Glenn S. Burke Subject: &rest arguments to DEFMACRO To: AGRE @ MIT-OZ cc: BUG-lisp @ MIT-MC I cannot reproduce this, it works for me.  Date: Monday, 7 March 1983 00:26-EST Sender: AGRE @ MIT-OZ From: AGRE @ MIT-MC To: bug-lisp @ MIT-OZ Subject: &rest arguments to DEFMACRO To a fresh lisp I typed (defmacro foo (a &rest b) (print a) (print b) `(list ',a ',b)) (foo 1 2) barfs with wrong-number-of-args error (foo 1 2 3) and (foo 1 2 3 4) print 1. and 3. In another lisp, I loaded lisp:mlsub and then typed (defmacro), which loaded all the right things. Then this all worked in the new lisp. So DEFMAX should load MLSUB if it has to. Gumby  Date: 3 March 1983 02:28-EST (Thursday) From: David Vinayak Wallace To: info-lisp @ MIT-OZ Reply-to: GUMBY@MC Subject: Recovering broken ledits If you have been losing when your ledit crashed (directory access or disk quota problems) and unable to restart it, have no fear. All is not lost. Type (SUBSYS LEDIT-FORK'START) and your emacs will be back ok. To have it read your ledit buffer you will have to then exit the emacs and then ^E and proceed as usual. Cheers. david  Date: 3 March 1983 01:54 EST From: Kent M. Pitman To: BUG-LISP @ MIT-MC I explained about DELETE to PGA.  Date: 3 Mar 1983 0150-EST From: PGA@MIT-OZ To: bug-lisp@MIT-OZ Why does delete only modify the middle of the list? [PHOTO: Recording initiated Thu 3-Mar-83 1:45AM] TOPS-20 Command Processor 5(740)-2 @lisp LISP 2129 Alloc? n * (setq tl '(0 1 2 4 6 10)) (0 1 2 4 6 10) (delete 0 tl) ;Try and remove the car. (1 2 4 6 10) ;It looks like it's gone tl (0 1 2 4 6 10) ;But it's not. (delete 2 tl) (0 1 4 6 10) ;Things from the middle of the list ; really go away though. tl (0 1 4 6 10) ^C @pop [PHOTO: Recording terminated Thu 3-Mar-83 1:46AM] -------  Date: 28 February 1983 18:10 EST From: Glenn S. Burke Subject: READLINE To: KMP @ MIT-MC cc: BUG-LISP @ MIT-MC READLINE is not respecting the syntax table for rubout, the prescan is. The "bug" is that the prescan uses the syntax table itself, rather than driving itself only by the reading function and having commands which are independent of the readtable. It would be even grosser if readline were to use the syntax table; it's contract has nothing to do with that.  Date: 27 February 1983 21:40 EST From: Kent M. Pitman Subject: READLINE To: BUG-LISP @ MIT-MC Why does READLINE respect the syntax table in how it process rubout but not for crlf. It would seem to me that these should be consistent and almost surely it shouldn't care what the readtable says. In particular, consider the following (type carefully, or you'll be sorry): (SETSYNTAX #\RUBOUT 'A #\RUBOUT) (READLINE)AB{Rubout}C{Return} |AB^?C| (SETSYNTAX #\CR 'A #\CR) (READLINE)ABC{Return} ABC or, in a fresh lisp again, ... (SETSYNTAX #/% (ASCII #\RETURN) #/%) (READLINE)ABC%DEF{Return} |ABC%DEF| ;but (SETSYNTAX #/% (ASCII #\RUBOUT) #/%) (READLINE)ABC DEG%F |ABC DEF| This hit me because I happened to have READTABLE bound to something very odd when I was doing some error recovery that wanted to READLINE something from the TTY. If it is fixable, it'd be nice. For the time being, I can `kludge' around it by binding READTABLE back to something good, but in general I see no reason for READLINE to use that syntax info at all ... Does someone know something I don't about why this is going on?  Date: 27 February 1983 15:52 EST From: George J. Carrette To: KMP @ MIT-MC cc: BUG-LISP @ MIT-MC, MARTY @ MIT-OZ In-reply-to: The message of 25 Feb 1983 20:35 EST from Kent M. Pitman Actually, MARTY talked to GSB and I before making the patch on OZ, so was familiar with the problems of merging. There still of course is THE problem, which is that there really aren't any local maclisp maintainers, and there certainly aren't any implementors! GSB, ALAN, and I had the idea that over IAP we would build and "smoke out" a new Maclisp version using the MC sources and stuff from XX and other tops-20 sites, but that just didn't happen. I'm of the opinion that it wouldn't be that bad a thing if OZ had a slightly divergent Maclisp from the MC version, if it will help make it easier to have the OZ version winning. There just isn't that much interesting in the "latest maclisp." A win as long as the people hacking OZ are local, accessable, aware (of local users), and responsible! There have been numerous examples in the past of course where lossage happened because the perpetrators did not satisfy all 5 conditions. Be that as it may, you yourself are a person who could build a new maclisp on ITS and TOPS-20. (eh?) On the other hand, I'm sure MARTY can handle making a new TOPS-20 version from the MC sources, since he has ample expert maclisp consultants on hand. -gjc  Date: 26 February 1983 01:56 EST From: Alan Bawden Subject: :PRINT-SELF message sending code. To: EB @ MIT-MC cc: BUG-LISP @ MIT-MC Date: Friday, 25 February 1983 13:49-EST From: EB When I use DPRINT and DRIBBL together, #FOO-nnnnn objects don't print anything to the terminal; they only print into the dribble file. Is there some way around this? This bug has been around for quite a while. It has also been the case that the NIL-in-MacLisp EXTEND objects failed to print themselves properly when DRIBBLing was turned on. The problem is a deficiency in the code that sends the :PRINT-SELF message to user hunks, it simply throws away the information about whether printing to the TTY is turned on or off. GSB and I just figured out a fix to this and fixed it in the source. We might make a new lisp soon, so you might actually see this fix sometime.  GSB@MIT-ML 02/26/83 01:09:32 Re: sources To: (BUG LISP) at MIT-ML The canonical place for sources is on MC. If source changes have been made elsewhere, they will not show up when the next lisp is made; merge them in quickly.  Date: 25 February 1983 20:42 EST From: Kent M. Pitman Subject: advertising random patches to local copies of Maclisp To: info-oz @ MIT-OZ cc: BUG-LISP @ MIT-MC, MARTY @ MIT-OZ Until and unless MARTY's recent mod to lisp is installed in the system sources, please avoid using the prematurely-announced feature if you want to assure that the feature doesn't disappear out from under you in some later recompilation of Maclisp. Reliable notices about changes to Maclisp will continue to come to you, as they always have, through the Lisp News file.  Date: 25 February 1983 20:35 EST From: Kent M. Pitman To: MARTY @ MIT-OZ cc: BUG-LISP @ MIT-MC Patches should be made to Maclisp ONLY if they are to be merged into the master sources. OZ should NOT have its own version of Maclisp which is in any way non-standard since the implementors are local and they need to be able to run Lisp to find out what a vanilla lisp is. If you have a patch to be made, just mail it to BUG-LISP explaining what it does and let someone who knows how to keep from making the world inconsistent actually do the change.  Date: 25 Feb 1983 2018-EST From: Martin David Connor Subject: OZ:PS:LISP.EXE.2132 To: bug-lisp at MIT-MC cc: info-oz at MIT-OZ Contains a one instruction patch at location 22756 to allow any interrupt character to be specified with (SSTATUS TTYINT ....). The source indicates range checking that no longer applies. This does mean that someone could theoretically do (sstatus ttyint 3 #'(lambda (f c) (princ "lose, lose"))) after which ^C will not get you out of lisp, although (quit) will still work. This also allows lisp programs to sense that the job has lost remote carrier (on a dialup), and execute a function. Anyway, perhaps someone will put this patch in the master sources on MC and build a new lisp. I'm willing to do the work if someone explains the protocol for installing Maclisp (symbol files, purification, bootstraps...). -------  Date: 24 Feb 1983 0410-EST From: GUMBY at MIT-OZ at MIT-MC Subject: COMPLR keeping To: info-lisp at MIT-OZ at MIT-MC why does complr keep? it's a total screw. I would like it to be ephemeral, but at least it should not keep! -------  Date: Thursday, 17 February 1983 22:36-EST Sender: GJS @ MIT-OZ From: GJS @ MIT-MC To: BUG-LISP @ MIT-MC Subject: Bug in PURIFY on TOPS-20 Maclisp Seems that PURIFY doesn't work (one needs it to run RWK's TIMER package). We get: #3326 PC WITH ILLEGAL INSTRUCTION CODE - George Carrette  Date: 16 February 1983 00:45-EST (Wednesday) Sender: GUMBY @ MIT-OZ From: David Vinayak Wallace To: JonL.pa @ PARC-MAXC Cc: Bug-Lisp @ MIT-OZ, Bug-OZ @ MIT-OZ, daniel @ MIT-OZ, Gumby @ MIT-OZ, MacLisp @ SRI-AI, NCP.EGK @ SU-GSB-HOW Subject: I really don't know where to send this one... In-reply-to: The message of 15 Feb 83 21:14 PST () from JonL.pa@PARC-MAXC.ARPA Date: 15 Feb 83 21:14 PST (Tuesday) From: JonL.pa@PARC-MAXC.ARPA On OZ, as well as on many other machines, "Maclisp" is installed as "Lisp". There is a little 1-block bootstrap file that does the work. If you insist, someone may be willing to install the bootstrapper under the name "MacLisp" also. Done. Yow, are we flaming yet?  Received: from PARC-MAXC.ARPA by SU-SCORE.ARPA with TCP; Tue 15 Feb 83 21:18:01-PST Date: 15 Feb 83 21:14 PST (Tuesday) From: JonL.pa@PARC-MAXC.ARPA Subject: Re: I really don't know where to send this one... In-reply-to: MacLisp@SRI-AI.ARPA's message of Mon, 14 Feb 83 14:40:50 PST To: MacLisp Hackers cc: NCP.EGK@SU-GSB-HOW.ARPA, Bug-Oz%mit-Oz@SU-SCORE.ARPA, Bug-Lisp%MIT-Oz@SU-SCORE.ARPA, daniel%mit-Oz@SU-SCORE.ARPA, Gumby%mit-Oz@SU-SCORE.ARPA On OZ, as well as on many other machines, "Maclisp" is installed as "Lisp". There is a little 1-block bootstrap file that does the work. If you insist, someone may be willing to install the bootstrapper under the name "MacLisp" also.  Received: from SRI-AI.ARPA by SU-SCORE.ARPA with TCP; Mon 14 Feb 83 14:43:12-PST Date: Mon 14 Feb 83 14:40:50-PST From: MacLisp Hackers Subject: Re: I really don't know where to send this one... To: NCP.EGK@SU-GSB-HOW.ARPA, Bug-Oz%mit-Oz@SU-SCORE.ARPA, Bug-Lisp%MIT-Oz@SU-SCORE.ARPA, daniel%mit-Oz@SU-SCORE.ARPA, Gumby%mit-Oz@SU-SCORE.ARPA In-Reply-To: Your message of Sun 13 Feb 83 13:15:11-PST There ISN'T a SYS:MACLISP.EXE on OZ! -------  Mail-from: SU-NET host GSB-HOW rcvd at 12-Feb-83 0121-PST Date: Sat 12 Feb 83 01:19:56-PST From: Edjik Subject: Re: I really don't know where to send this one... To: Bug-Oz%mit-Oz@SU-SCORE, Bug-Lisp%MIT-Oz@SU-SCORE, daniel%mit-Oz@SU-SCORE, Gumby%mit-Oz@SU-SCORE cc: NCP.EGK@SU-GSB-HOW In-Reply-To: Your message of Fri 11 Feb 83 19:02:00-PST Don't blame TOPS-20 for rotten features people install in the EXEC. On almost every other top-20 in existance, (the exceptions being the MIT ones), saying @maclisp will run the maclisp program. (provided they have maclisp of course). People Bastardize something and then blame it for being that way!! Jesus! "Lazy Connect" (as this ""feature"" is called) is a crock. it should at least check for a valid program to run before assuming that the person wants to connect!! -- Edjik -------  Date: 11 February 1983 22:02-EST (Friday) Sender: GUMBY @ MIT-OZ From: David Vinayak Wallace To: DANIEL @ MIT-OZ Cc: bug-lisp @ MIT-OZ, bug-oz @ MIT-OZ Subject: I really don't know where to send this one... In-reply-to: The message of 11 Feb 1983 20:30-EST from DANIEL at MIT-OZ Date: Friday, 11 February 1983 20:30-EST From: DANIEL at MIT-OZ Why does @maclisp at top level act as a noop? Another winning feature, brought to you by TWENEX! It doesn't. It connects you to the MACLISP directory (try it when connected to a SRC: directory). Type LISP instead, or MACLIPS. david  Date: 11 Feb 1983 2030-EST From: DANIEL at MIT-OZ Subject: I really don't know where to send this one... To: bug-oz at MIT-OZ, bug-lisp at MIT-OZ Why does @maclisp at top level act as a noop? Daniel -------  Date: 6 February 1983 13:43 EST From: Kent M. Pitman Subject: PSR's eof in comment gripe To: BUG-LISP @ MIT-MC I answered PSR's message.  Date: 5 Feb 1983 2324-EST From: PSR at MIT-OZ Subject: reader bug To: bug-lisp at MIT-OZ A file with a comment at the end and no final crlf gets a EOF in line error during LOAD. -------  Date: Tuesday, 1 February 1983, 11:26-EST From: Kent M. Pitman Subject: Circular lists (long but hopefully interesting message) To: JOSHM at OZ, DCP at OZ Cc: SCHEME-CODERS at OZ, BUG-SCHEME at OZ, BUG-LISP at OZ, JAR at MC Date: 31 Jan 1983 2044-EST From: JOSHM at MIT-OZ Subject: Circular lists To: bug-lisp at MIT-OZ cc: scheme-coders at MIT-OZ, bug-scheme at MIT-OZ Is there a system procedure defined that will determine if a list is circular, or does anyone know of anything already written, or at last resort, a good algorithm with which I can implement one? -Josh Date: 31 January 1983 21:14 EST From: David C. Plummer Just as a screw case, consider (MACLisp) (defun screw-case () (let ((the-list (cons nil nil))) ;get a list (rplacd the-list the-list) ;make it circular (dotimes (i almost-an-address-space-of-consing) (push nil the-list)) ;prepend a lot of conses the-list)) BTW, what's the prefered way to create a circular list in scheme anyway? ----- Rivest's algorithms course (MIT 6.045) discussed a good algorithm for doing this. I am forever forgetting who actually designed this algorithm, but it was one of the more well-known algorithms people. The idea is that you release two runners on a list, running at different rates. If the fast one (who should be ahead of the slow one from the start) ever finds the slow one ahead of him, then there was a circularity... These are the definitions we originally installed in T (Yale Scheme). Jonathan removed them, against my recommendations because he didn't think anyone cared about having them. I still think they should be re-instated because they are healthy to have as built-ins. People aren't notably good at writing them. ; Start two runners. If the slow one catches the fastest, then the list was ; circular. (DEFINE (CIRCULAR? MOVE X) (IF (NULL-LIST? X) NIL (ITERATE RACE ((SLOW-RUNNER X) (FAST-RUNNER (MOVE X))) (COND ((OR (NULL-LIST? FAST-RUNNER) (NULL-LIST? (MOVE FAST-RUNNER))) NIL) ((EQ? SLOW-RUNNER FAST-RUNNER) T) ;Fast runner caught up! (T (RACE (MOVE SLOW-RUNNER) (MOVE (MOVE FAST-RUNNER)))))))) Eg, (CIRCULAR? CDR X) looked for cdr circularities. (CIRCULAR? CAR X) looks for car circularities. Note this is a constant space, linear time (with the length of the list) algorithm; worst case for a length M long with a circular tail N long nconc'd on is M+2N, I think. Here's an example of `coroutining' it with LENGTH... (DEFINE (LENGTH X) (COND ((NULL-LIST? X) 0.) (T (ITERATE RACE ((SLOW-RUNNER X) (FAST-RUNNER (CDR X)) (COUNT 1)) (COND ((NULL-LIST? FAST-RUNNER) COUNT) ((NULL-LIST? (CDR FAST-RUNNER)) (1+ COUNT)) ((EQ? SLOW-RUNNER FAST-RUNNER) (ERROR "Argument to LENGTH is circular: (~S ...)" (CAR X))) (T (RACE (CDR SLOW-RUNNER) (CDDR FAST-RUNNER) (+ COUNT 2.)))))))) In Maclisp, it'd be roughly, ... ; Start two runners. If the slow one catches the fastest, then the list was ; circular. (DEFUN CIRCULAR? (MOVE X) (IF (NULL X) NIL (DO ((SLOW-RUNNER X (FUNCALL MOVE SLOW-RUNNER)) (FAST-RUNNER (FUNCALL MOVE X) (FUNCALL MOVE (FUNCALL MOVE FAST-RUNNER)))) ((OR (NULL FAST-RUNNER) (NULL (FUNCALL MOVE FAST-RUNNER))) NIL) ; Fast runner fell off end (IF (EQ SLOW-RUNNER FAST-RUNNER) (RETURN T))))) ; Fast runner looped and caught up! Though due to the slowness of FUNCALL, the following special purpose definition might be much faster... (DEFUN CIRCULAR-CDR? (X) (IF (NULL X) NIL (DO ((SLOW-RUNNER X (CDR SLOW-RUNNER)) (FAST-RUNNER (CDR X) (CDDR FAST-RUNNER))) ((OR (NULL FAST-RUNNER) (NULL (CDR FAST-RUNNER))) NIL) ; Fast runner fell off end (IF (EQ SLOW-RUNNER FAST-RUNNER) (RETURN T))))) ; Fast runner looped and caught up!  Date: 31 January 1983 21:14 EST From: David C. Plummer Subject: Circular lists To: JOSHM @ MIT-OZ cc: bug-lisp @ MIT-OZ, scheme-coders @ MIT-OZ, bug-scheme @ MIT-OZ Just as a screw case, consider (MACLisp) (defun screw-case () (let ((the-list (cons nil nil))) ;get a list (rplacd the-list the-list) ;make it circular (dotimes (i almost-an-address-space-of-consing) (push nil the-list)) ;prepend a lot of conses the-list)) BTW, what's the prefered way to create a circular list in scheme anyway?  Date: 31 Jan 1983 2044-EST From: JOSHM at MIT-OZ Subject: Circular lists To: bug-lisp at MIT-OZ cc: scheme-coders at MIT-OZ, bug-scheme at MIT-OZ Is there a system procedure defined that will determine if a list is circular, or does anyone know of anything already written, or at last resort, a good algorithm with which I can implement one? -Josh -------  Date: 24 January 1983 17:49 EST From: George J. Carrette Subject: do-with-tty-off To: JOSHM @ MIT-OZ cc: bug-lisp @ MIT-OZ, bug-scheme @ MIT-OZ In-reply-to: The message of 24 Jan 1983 1652-EST from JOSHM at MIT-OZ I put the newest TTY.FASL on OZ now, GENTEMP problem has been diked out.  Date: 24 Jan 1983 1652-EST From: JOSHM at MIT-OZ Subject: do-with-tty-off To: bug-lisp at MIT-OZ, bug-scheme at MIT-OZ Doesn't quite work the way I expected: [PHOTO: Recording initiated Mon 24-Jan-83 4:48PM] TOPS-20 Command Processor 5(737)-2 @lisp  MacLisp version 2129 radix = 10 * (load "lisp:tty.fasl") ;Loading TTY 17 45673 (do-with-tty-off (readch) (readch)) ;GENTEMP UNDEFINED FUNCTION IN UUO CALL ;BKPT UNDF-FNCTN (quit) @pop [PHOTO: Recording terminated Mon 24-Jan-83 4:49PM] How am I supposed to use it? -Josh -------  Date: 24 Jan 1983 1405-EST From: JOSHM at MIT-OZ Subject: Re: How do I... To: Feinberg at CMU-CS-C cc: JOSHM%MIT-OZ at MIT-MC, bug-lisp%MIT-OZ at MIT-MC, bug-scheme%MIT-OZ at MIT-MC In-Reply-To: Your message of 21-Jan-83 2143-EST Thanks. -Josh -------  Date: 23 Jan 1983 1744-EST From: BROOKS at MIT-OZ Subject: PS, SRC To: BUG-MACLISP at MIT-OZ When connected to an SRC: directory, MACLISP screws up it file defaulting insisting on PS. In particular if there is a LISP.INI file it detects it but then can't open it, because it tries to OPEN on a PS: directory. -------  Received: ID ; 21 Jan 83 21:43:21 EST Date: 21 Jan 83 21:43:19 EST From: Feinberg@CMU-CS-C To: JOSHM%MIT-OZ@MIT-MC Cc: bug-lisp%MIT-OZ@MIT-MC, bug-scheme%MIT-OZ@MIT-MC Subject: How do I... In-reply-to: The message of 21 Jan 1983 17:37-EST from JOSHM at MIT-OZ at MIT-MC Hi. Load TTY.FASL, and use DO-WITH-TTY-OFF, like so: (DO-WITH-TTY-OFF ... ) ;Like a PROGN with echo --Chiron  Date: 21 Jan 1983 1737-EST From: JOSHM at MIT-OZ at MIT-MC Subject: How do I... To: info-lisp at MIT-OZ at MIT-MC cc: bug-lisp at MIT-OZ at MIT-MC, bug-scheme at MIT-OZ at MIT-MC, info-scheme at MIT-OZ at MIT-MC How do turn off input echoing from inside maclisp or scheme? I'm writing a display oriented program and the typed input keeps destroying the display. -Josh -------  Date: 21 Jan 1983 1737-EST From: JOSHM at MIT-OZ Subject: How do I... To: info-lisp at MIT-OZ cc: bug-lisp at MIT-OZ, bug-scheme at MIT-OZ, info-scheme at MIT-OZ How do turn off input echoing from inside maclisp or scheme? I'm writing a display oriented program and the typed input keeps destroying the display. -Josh -------  Date: Tuesday, 11 January 1983 13:46-EST Sender: EB @ MIT-OZ From: EB @ MIT-MC To: Bug-Lisp @ MIT-OZ There is no ALARMCLOCK function in Lisp 2129 on Oz. Is the lack of ALARMCLOCK permanent?