From: [email-masked]
To: [email-masked]
Date: Mon, 5 Oct 87 12:32 EDT

[The referenced message has been redirected:
  Correcting "Bug-Lisp" -> "Bug-LispM"
    [email-masked] has been removed;
    [email-masked] has been added.]

Date: Thu,  1 Oct 87 23:39:03 EDT
From: David Chapman <[email-masked]>
To: [email-masked]
Message-ID: <[email-masked]>

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 <[email-masked]>
To: [email-masked]
Message-ID: <[email-masked]>

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.)

Date: Wed, 6 May 87 00:09:19 EDT
From: Jim Davis <[email-masked]>
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 <[email-masked]>
Subject:  Gee, that's not his host's name
To: [email-masked]
cc: [email-masked], [email-masked]
In-reply-to: Msg of Sat 20 Dec 86 13:22 EST from Ramin Zabih <RDZ at AI.AI.MIT.EDU>
Message-ID: <[email-masked]>

    Date: Sat, 20 Dec 86 13:22 EST
    From: Ramin Zabih <RDZ at AI>
    Typing :FINGER on AI just produced this output:
    ...
    RDZ       Ramin Zabih                 F      T23 <<error printing host>>: 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...

Date: Sat, 20 Dec 86 13:22 EST
From: Ramin Zabih <[email-masked]>
Subject: Gee, that's not my host's name
To: [email-masked], [email-masked]

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 <<error printing host>>: 709 x8827 RDZ, Zvona (Chaos)

It seems that someone is confused about the name of the 3600 I'm using...

Date: Wed, 7 May 86 21:50 EDT
From: Jonathan A Rees <[email-masked]>
Subject: ubiquitous prettyprinter bug
To: [email-masked], [email-masked]
cc: [email-masked]

[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 ,<var> where <var> 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" <[email-masked]>
Subject: ITS names
To: [email-masked]
cc: [email-masked]
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 <[email-masked]>
Subject:  ALLFILES behavior
To: [email-masked]
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" <[email-masked]>
To: [email-masked]
cc: [email-masked]
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 <[email-masked]>
Subject:  Maclisp <> MACRO
To: [email-masked]
cc: [email-masked]
In-reply-to: Msg of Mon 29 Jul 85 16:35:36-PDT from Joel P. Bion <JPBion at SU-SUSHI.ARPA>
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 <[email-masked]>
Subject: Maclisp <> MACRO
To: [email-masked]

Is there any documentation on Maclisp interfacing with MACRO?

Joel
-------

Date: Mon, 24 Jun 85 20:19 EDT
From: Charles Hornig <[email-masked]>
Subject: Common Lisp defsetf
To: Richard E. Zippel <[email-masked]>,
    [email-masked]

    Date: Tue, 4 Jun 85 21:41 EDT
    From: Richard E. Zippel <RZ@ZERMATT>

    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.

Date: Tue, 11 Jun 85 12:09 EDT
From: Kent M Pitman <[email-masked]>
Subject: Timit
To: [email-masked]
cc: [email-masked]

    Date: Tue, 11 Jun 85 08:53:56 EDT
    From: Stavros M. Macrakis <[email-masked]>

    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 <[email-masked]>
Subject: Timit
To: [email-masked]
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.

Date: Thu 6 Jun 85 21:57:11-PDT
From: Scott J. Kramer <[email-masked]>
Subject: Re: distribution copies
To: [email-masked], [email-masked]
cc: [email-masked], [email-masked]
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
-------

Date: 17 May 1985 1634-PDT
From: [email-masked] (Dwight Hare)
Subject: Misfeature in SAVE/GET
To: [email-masked]
cc: [email-masked]
ReSent-Date: Fri 24 May 85 06:55:35-EDT
ReSent-From: Martin David Connor <[email-masked]>
ReSent-To: [email-masked]

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
-------

Date: Sun 19 May 85 12:36:21-PDT
From: Andy Freeman <[email-masked]>
Subject: Re: distribution copies
To: [email-masked]
cc: [email-masked], [email-masked]

(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 <cr>
to get maclisp to respond.

-andy
-------

Date: Sun, 19 May 85 05:34:21 EST
From: David Vinayak Wallace <GUMBY@MIT-MC>
Subject:  distribution copies
To: MKL@SRI-CSL
cc: bug-maclisp@MIT-OZ

    Date: 19 May 1985 0110-PDT
    From: Mark K. Lottor <MKL at SRI-CSL>

    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

Date: 19 May 1985 0110-PDT
From: Mark K. Lottor <[email-masked]>
Subject: distribution copies
To: [email-masked]

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 <GSB@MIT-MC>
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 <[email-masked]>
Subject: EXEC/MACLISP interface problem
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked],
    [email-masked]

Thanks to the original author of the MIDAS program also,
whoever that may be.
					Dan Blom
-------

Date: Wed, 8 May 1985  10:27 PDT
From: "Leonard N. Zubkoff" <[email-masked]>
To:   "Daniel S. Blom" <[email-masked]>
Cc:   [email-masked], [email-masked]
Subject: EXEC/MACLISP interface problem

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: [email-masked]
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked],
    [email-masked], [email-masked]
Reply-To: [email-masked]
In-Reply-To: Message from "David Vinayak Wallace <GUMBY@MIT-MC>" 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 <GUMBY@MIT-MC>
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 <GUMBY @ MIT-MC>
Message-ID: <[MIT-MC].491660.850508.GUMBY>

    Date: Tue,  7 May 85 19:34:03 EST
    From: Alan Bawden <ALAN>

    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 <GUMBY@MIT-MC>
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 <ALAN>
Message-ID: <[MIT-MC].491610.850508.GUMBY>

    Date: Tue,  7 May 85 19:34:03 EST
    From: Alan Bawden <ALAN>

    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 <ALAN@MIT-MC>
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 <GJC>
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?

Date: Tue, 7 May 85 19:04 EDT
From: Kent M Pitman <[email-masked]>
Subject: [Daniel S. Blom: Re: EXEC/MACLISP interface problem]
To: [email-masked]

Date: Tue 7 May 85 16:01:52-PDT
From: Daniel S. Blom
Subject: Re: EXEC/MACLISP interface problem
Sender: [email-masked]
To: [email-masked]
cc: [email-masked]
Reply-To: [email-masked]

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
-------

Date: Tue, 7 May 85 18:33 EDT
From: Kent M Pitman <[email-masked]>
Subject: Re: EXEC/MACLISP interface problem
To: [email-masked]
cc: [email-masked], [email-masked]

    Date: Tue 7 May 85 15:11:58-PDT
    From: Daniel S. Blom
    To: [email-masked]
    cc: [email-masked]
    Reply-To: [email-masked]

    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]<UNSUPPORTED>SHARE.EXE.2 to [XX]<MACLISP>SHARE.EXE.2
          and [OZ]HLP:SHARE.HLP.2	   to [XX]<MACLISP>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

Date: Tue, 7 May 85 17:56 EDT
From: Kent M Pitman <[email-masked]>
Subject: EXEC/MACLISP interface problem
To: [email-masked]
cc: [email-masked], [email-masked],
    [email-masked], [email-masked]

    Date: Tue,  7 May 85 17:42:46 EST
    From: George J. Carrette <GJC@MIT-MC>

    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 <GJC@MIT-MC>
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 <KMP at SCRC-STONY-BROOK.ARPA>
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.

Date: Tue, 7 May 85 17:27 EDT
From: Kent M Pitman <[email-masked]>
Subject: [Daniel S. Blom: Re: EXEC/MACLISP interface problem]
To: [email-masked]

Date: Tue 7 May 85 14:21:06-PDT
From: Daniel S. Blom
Subject: Re: EXEC/MACLISP interface problem
Sender: [email-masked]
To: [email-masked]
cc: [email-masked]
Reply-To: [email-masked]

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.
-------

Date: Tue, 7 May 85 16:55 EDT
From: Kent M Pitman <[email-masked]>
Subject: EXEC/MACLISP interface problem
To: [email-masked], [email-masked]
cc: [email-masked]

    Date: Tue 7 May 85 13:49:34-PDT
    From: Daniel S. Blom
    Subject: EXEC/MACLISP interface problem
    Sender: [email-masked]
    To: [email-masked]
    cc: [email-masked]
    Reply-To: [email-masked]

    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: [email-masked]
To: [email-masked]
cc: [email-masked]
Reply-To: [email-masked]

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: [email-masked]
To: [email-masked]
cc: [email-masked]
Reply-To: [email-masked]

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
-------

Date: Sun, 5 May 85 19:44 EDT
From: Kent M Pitman <[email-masked]>
Subject: MDC.WAYNE: "list" command
To: [email-masked]

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 <[email-masked]>
Subject: "list" command
To: [email-masked]

     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 <[email-masked]>
Subject: Re: mapcan and get
To: [email-masked]
In-Reply-To: Message from "Kent M Pitman <KMP at SCRC-STONY-BROOK>" 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 <ALAN @ MIT-MC>
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 <RJH%MIT-OZ at MIT-MC.ARPA>

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.

Date: 24 March 1985 15:22-EST
From: David Vinayak Wallace <GUMBY @ MIT-MC>
Subject:  mapcan and get
To: bug-lisp @ MIT-OZ

    Date: Sat 23 Mar 85 17:19:48-EST
    From: Bob Hall <RJH at OZ>

    ; Dear bug-lisp:

    ; Do you know about the failure of mapcan when used with get?

He's going to report the DELQ bug next.

Date: 23 March 1985 20:27-EST
From: George J. Carrette <GJC @ MIT-MC>
Subject:  mapcan and get
To: RJH @ MIT-OZ
cc: bug-lisp @ MIT-OZ

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 <[email-masked]>
Subject: mapcan and get
To: [email-masked]

; 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 <ALAN @ MIT-MC>
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 <MDC.WAYNE%MIT-OZ at MIT-MC.ARPA>

    Date: Fri 22 Feb 85 05:41:34-EST
    From: Wayne McGuire <MDC.WAYNE at OZ>
    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 <[email-masked]>
Subject: Array Bug
To: [email-masked]

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: <EB.12085574776.BABYL@MIT-OZ>
From: [email-masked]
To:   [email-masked]
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 <ALAN @ MIT-MC>
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: [email-masked]
Subject: [Wade Hennessey <[email-masked]>: maclisp compiler error]
To: [email-masked]
cc: [email-masked], [email-masked]

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 <[email-masked]>
Subject: maclisp compiler error
To: [email-masked]
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 <MACRAK @ MIT-MC>
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 <KMP>

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 <KMP @ MIT-MC>
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 <ALAN @ MIT-MC>
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 <MACRAK>

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 <MACRAK @ MIT-MC>
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 <ALAN @ MIT-MC>
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 <KMP>

    Date: 5 December 1984 14:08-EST
    From: Kent M Pitman <KMP>
        Date: Wednesday, 5 December 1984, 10:32-EST
        From: Richard L. Bryan <RLB at SCRC-TENEX>
            Date: Sat 1 Dec 84 19:28:31-EST
            From: Dave Braunegg <DJB at OZ>
            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. ]

Date: Wednesday, 5 December 1984, 10:32-EST
From: Richard L. Bryan <RLB at SCRC-TENEX>
Subject: GC
To: ALAN at MIT-MC, DJB at MIT-OZ
cc: bug-lisp at MIT-OZ

    Date: 4 December 1984 13:29-EST
    From: Alan Bawden <ALAN @ MIT-MC>

	Date: Sat 1 Dec 84 19:28:31-EST
	From: Dave Braunegg <DJB at OZ>
	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 <ALAN @ MIT-MC>
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 <DJB%MIT-OZ at MIT-MC.ARPA>

    Date: Sat 1 Dec 84 19:28:31-EST
    From: Dave Braunegg <DJB at OZ>
    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 <[email-masked]>
Subject: GC
To: [email-masked]

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 <ALAN @ MIT-MC>
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 <KMP>

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 <KMP @ MIT-MC>
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 <ALAN @ MIT-MC>
Subject:  ||
To: GZ @ MIT-MC
cc: BUG-LISP @ MIT-MC
In-reply-to: Msg of 10 Oct 1984 04:45-EDT from Gail Zacharias <GZ>

    Date: 10 October 1984 04:45-EDT
    From: Gail Zacharias <GZ>
    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 <GZ @ MIT-MC>
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 <GZ @ MIT-MC>
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 <[email-masked]>
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 <KMP @ MIT-MC>
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 <Mellis%MIT-EECS at MIT-MC.ARPA>

    Date: Sun, 23 Sep 1984  06:05 EDT
    From: Adam G. Mellis <Mellis%MIT-EECS at MIT-MC.ARPA>

    According to <maclisp>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: <T.MELLIS.12049821247.BABYL@MIT-EECS>
Sender: [email-masked]
From: "Adam G. Mellis" <[email-masked]>
Subject: M-F
To:   bug-lisp@MIT-MC

According to <maclisp>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: <BERWICK.PILATO.12047389611.BABYL@MIT-OZ>
From: [email-masked]
To:   [email-masked]

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:<MACLISP>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: [email-masked]
Subject: [MJackson.Wbst: Why Your Pascal and Modula-2 Programs Don't
 Work]
To: [email-masked]
cc: [email-masked],[email-masked],[email-masked]
Reply-to: [email-masked]

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 <[email-masked]>
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 <[email-masked]>
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: <GLR.12037337760.BABYL@MIT-OZ>
From: Jerry Roylance <[email-masked]>
To:   [email-masked]
cc:   [email-masked]

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 <ALAN @ MIT-MC>
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 <CENT @ MIT-MC>
Subject: help
To: ANALOG.KY @ MIT-OZ
cc: BUG-LISP @ MIT-MC

    Date: Wed 11 Jul 84 21:03:25-EDT
    From: [email-masked]
    Subject: help
    To: [email-masked]
    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 <ALAN @ MIT-MC>
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 <DRogers%MIT-OZ at MIT-MC.ARPA>

    Date: Sat 16 Jun 84 17:08:19-EDT
    From: David Rogers <DRogers at OZ>
    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 <[email-masked]>
Subject: help in setting up LISP on PREP
To: [email-masked]

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 <GSB @ MIT-MC>
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 <[email-masked]>
Subject: Unnamed arrays not GC'd like they should.   
To:   [email-masked]  

(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 <ALAN @ MIT-MC>
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 <BMT>

    Date: 2 June 1984 13:57-EDT
    From: Barry M. Trager <BMT>
    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 <BMT @ MIT-MC>
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 <GZ @ MIT-MC>
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)?

Date: Thu, 5 Apr 84 09:43 PST
From: "Robert W. Kerns" <[email-masked]>
Subject: How intelligent is the complr?
To: "John G. Aspinall" <[email-masked]>
Cc: [email-masked]

    Date: 4 April 1984 13:33-EST
    From: John G. Aspinall <JGA @ 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.
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: [email-masked]
Subject: Re: How intelligent is the complr?
To: [email-masked], [email-masked]
cc: [email-masked], [email-masked], [email-masked]

In response to the message sent  5 Apr 84 17:42 EST from [email-masked]

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 <ALAN @ MIT-MC>
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: [email-masked]
Subject: Re: How intelligent is the complr?
To: [email-masked], [email-masked]
cc: [email-masked], [email-masked]

In response to the message sent  4 Apr 84 14:53 EST from [email-masked]

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 <ALAN @ MIT-MC>
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 <JGA>

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 <JGA @ MIT-MC>
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 <GUMBY @ MIT-MC>
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 <JGA>

    Date: 28 March 1984 12:25-EST
    From: John G. Aspinall <JGA>

    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 <JGA @ MIT-MC>
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 <ALAN @ MIT-MC>
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: <ROBOT.GML.12001967680.BABYL@MIT-OZ>
From: [email-masked]
To:   [email-masked]

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<b you get:

(x y <list2>)  the first time
and 
(x y <list2> <list2'>) the second time
and 
(x y <list2> <list2'> <list2''> 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 <ALAN @ MIT-MC>
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 <DMS%MIT-OZ at MIT-MC.ARPA>

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: <DMS.11998314032.BABYL@MIT-OZ>
From: David Siegel <[email-masked]>
Subject: maclisp problem
To:   [email-masked], [email-masked],
      [email-masked], [email-masked]

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 <ALAN @ MIT-MC>
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 <GLR%MIT-OZ at MIT-MC.ARPA>

Since it is 20X-only its source lives in MC:LISP20;

Date: Sat, 3 Mar 1984  10:56 EST
Message-ID: <GLR.11996407769.BABYL@MIT-OZ>
From: Jerry Roylance <[email-masked]>
To:   [email-masked]
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 <[email-masked]>
Subject: MACLISP availablity
To: [email-masked]
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 <[email-masked]>
Subject: Re: A Bug in Maclisp -- emacs?
To: [email-masked]
cc: [email-masked], [email-masked]
In-Reply-To: Message from "David Vinayak Wallace <GUMBY @ MIT-MC>" 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 <GUMBY @ MIT-MC>
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 <CS204.CASLEY at SU-SCORE.ARPA>

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 <[email-masked]>
Subject: A Bug in Maclisp
To: [email-masked]
ReSent-date: Fri 24 Feb 84 20:59:42-PST
ReSent-from: Mark Crispin <[email-masked]>
ReSent-to: [email-masked]

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 <KMP @ MIT-MC>
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 <Zubkoff%TARTAN at CMU-CS-C.ARPA>

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

Date: Tue, 21 Feb 1984  23:29 EST
From: Leonard N. Zubkoff <[email-masked]>
To:   John Lamping <[email-masked]>
Cc:   [email-masked]
Subject: Control Character I/O

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 <[email-masked]>
Subject: Control Character I/O
To: [email-masked]

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 <KMP @ MIT-MC>
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 <GLR at MIT-OZ>
In-reply-to: Msg of 10 Feb 1984 13:37 EST from Alan Bawden <ALAN>

    Date: 10 February 1984 13:37 EST
    From: Alan Bawden <ALAN>

        Date: Fri, 10 Feb 1984  12:13 EST
        From: Jerry Roylance <GLR at OZ>
        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: <GLR.11990654613.BABYL@MIT-OZ>
From: Jerry Roylance <[email-masked]>
To:   [email-masked]
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 <ALAN @ MIT-MC>
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 <GLR%MIT-OZ at MIT-MC.ARPA>

    Date: Fri, 10 Feb 1984  12:13 EST
    From: Jerry Roylance <GLR at OZ>
    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: <GLR.11990654613.BABYL@MIT-OZ>
From: Jerry Roylance <[email-masked]>
To:   [email-masked]
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 <ALAN @ MIT-MC>
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 <WGD>

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 <WGD @ MIT-MC>
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: [email-masked]
Subject: DO: an interpreter bug
To: [email-masked], [email-masked]
cc: [email-masked], [email-masked]

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 <ALAN @ MIT-MC>
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 <DEVON>

    Date: 5 February 1984 00:45 EST
    From: Devon S. McCullough <DEVON>
    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 <DEVON @ MIT-MC>
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 <ALAN @ MIT-MC>
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 <DEVON>

    Date: 4 February 1984 11:53 EST
    From: Devon S. McCullough <DEVON>
    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: <CJL.11988085006.BABYL@MIT-OZ>
From: [email-masked]
To:   [email-masked]
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: <MARTY.11982282652.BABYL@MIT-OZ>
From: Martin David Connor <[email-masked]>
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:<gz.lisp>hostmap")
    ;(LOAD ((|ps| ||) |hostmap| LSP *)) FILE NOT FOUND
What happened to the directory name?
    ;BKPT IO-LOSSAGE
    (load "<gz.lisp>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: [email-masked]
Subject: Re: Setf's of load-byte don't work - broken foo-byte-expander
To: [email-masked], [email-masked]
cc: [email-masked], [email-masked], [email-masked]

In response to the message sent  Wed, 4 Jan 84 04:04 EST from [email-masked]

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 <ALAN at MIT-MC>
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: [email-masked]
    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: [email-masked]
Subject: Re: Setf's of load-byte don't work - broken foo-byte-expander
To: [email-masked], [email-masked]
cc: [email-masked]

In response to the message sent  Tue, 3 Jan 84 21:15 EST from [email-masked]

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: <CJL.11980791940.BABYL@MIT-OZ>
From: Chris Lindblad <[email-masked]>
To:   [email-masked]
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 <YM@SU-AI>
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 <KMP @ MIT-MC>
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 <GJC @ MIT-MC>
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 <SASW>

Allfiles takes a list of namelists.

Date: 11 December 1983 16:45 EST
From: Steven A. Swernofsky <SASW @ MIT-MC>
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 <KMP @ MIT-MC>
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 <GJC @ MIT-MC>
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 <JPG>

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 <JPG @ MIT-MC>
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 <[email-masked]>
   To: [email-masked]
   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 <Gumby at MIT-MC>
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 <Gumby at MIT-MC>
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:<MACLISP>LEDIT.FASL.44.  Source
on MC.

david

Date: 10 November 1983 10:32 EST
From: George J. Carrette <GJC @ MIT-MC>
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 <RICH%MIT-OZ at MIT-MC.ARPA>

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: <RICH.11966506998.BABYL@MIT-OZ>
From: Charles Rich <[email-masked]>
To:   [email-masked]
Cc:   [email-masked], [email-masked]
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 [email-masked]

    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: [email-masked]
Subject: Re: LEDIT
To: [email-masked], [email-masked]
cc: [email-masked], [email-masked]

In response to the message sent  Wed, 9 Nov 83 16:54:45 EST from [email-masked]

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: [email-masked]
Subject: Re: LEDIT
To: [email-masked]
cc: [email-masked]
In-Reply-To: Message from "Charles Rich <RICH@MIT-OZ>" 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: <RICH.11966253835.BABYL@MIT-OZ>
From: Charles Rich <[email-masked]>
To:   [email-masked]
Subject: LEDIT
CC:   [email-masked]

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
<MACLISP>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 <Alan at MIT-MC>
To: GLR at MIT-AI
Cc: Bug-Lisp at MIT-MC
In-reply-to: <GLR.11965860451.BABYL@MIT-OZ>

    Date: Mon, 7 Nov 1983  22:14 EST
    From: Jerry Roylance <[email-masked]>
    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: <GLR.11965860451.BABYL@MIT-OZ>
From: Jerry Roylance <[email-masked]>
To:   [email-masked]

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: <MHS.11965561925.BABYL@MIT-OZ>
From: [email-masked]
To:   [email-masked]
Subject: I/O Lossage
Cc:   [email-masked]

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:<publications.lisp>

Note what I've connected to

    @lisp

    LISP 2141
    Alloc? n

    * 

    (status ve[[[Klispversion)
    /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 <[email-masked]>
Subject: maclisp forever...
To: [email-masked]

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: <GLR.11961994795.BABYL@MIT-OZ>
From: Jerry Roylance <[email-masked]>
To:   [email-masked]
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 <GLR@MIT-OZ>
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 <LPH @ MIT-MC>
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 <kmp at MIT-MC>
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 <KMP>
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 <TURNIP>
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 <kmp at MIT-MC>
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 <ALAN>
    To:   BUG-LISP, JPG, KMP
    Re:   ALPHALESSP: More data
    
	Date: 1 October 1982 07:01-EDT
	From: Kent M. Pitman <KMP>
    
	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 <ALAN @ MIT-MC>
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 <GLR at MIT-OZ>

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 <GLR@MIT-OZ>
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 <RIVIN @ MIT-MC>
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 <DCP @ MIT-MC>
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 <KMP @ MIT-MC>
        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 <KMP @ MIT-MC>
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 <DCP @ MIT-MC>
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 <RWK@SCRC-TENEX>
    In-reply-to: The message of 6 Sep 83 00:02-EDT from Alan Bawden <ALAN at MC>

        Date: 6 September 1983 00:02 EDT
        From: Alan Bawden <ALAN @ MIT-MC>
        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 <RWK@SCRC-TENEX>
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 <ALAN at MC>

    Date: 6 September 1983 00:02 EDT
    From: Alan Bawden <ALAN @ MIT-MC>
    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 <ALAN @ MIT-MC>
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 <DCP>

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 <DCP @ MIT-MC>
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 <GJC @ MIT-MC>
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 <DCP>

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 <Gumby at MIT-OZ>
To: David C. Plummer <DCP at MIT-MC>
Cc: BUG-MACLISP at MIT-MC
In-reply-to: The message of 5 Sep 83 13:24-EDT from David C. Plummer <DCP at MIT-MC>

    Date: 5 September 1983 13:24 EDT
    From: David C. Plummer <DCP @ 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).

Probably because they postdate IF (and the time MLMAC was written).

Date: 5 September 1983 13:24 EDT
From: David C. Plummer <DCP @ MIT-MC>
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 <ALAN @ MIT-MC>
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 <MARTY at MIT-OZ>

    Date: Monday, August 29, 1983 5:59PM-EDT
    From: Martin David Connor <MARTY at MIT-OZ>
    It would be nice if MACLISP cannot find a LISP.INI file on
    DSK: if it would then try PS:<login-name>LISP.INI.

Funny you should bring this up.  Last weekend Gumby and I hacked 20X
MacLisp so that PS:<login-name> is searched rather than your connected
directory for an init file.  Try <MACLISP>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 <MARTY@MIT-OZ>
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:<login-name>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 <GJC @ MIT-MC>
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 <ALAN @ MIT-MC>
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 <KMP>
    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 <KMP @ MIT-MC>
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 <GJC @ MIT-MC>
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 <JGA>

See the *ALL NEW* MACLISP MANUAL, available from LCS PUBLICATIONS!

Date: 3 August 1983 17:44 EDT
From: John G. Aspinall <JGA @ MIT-MC>
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 <Gumby@MIT-OZ>
Subject: lisp i/o
To: Arturo Perez <UC.ART@MIT-EECS>
Cc: bug-lisp@MIT-OZ
In-reply-to: The message of 30 Jul 83 22:43-EDT from Arturo Perez <UC.ART at MIT-EECS>

    Date: 30 Jul 1983 2243-EDT
    From: Arturo Perez <UC.ART at MIT-EECS>

    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" <options>) will return a file-object.  You
should save it and do (close <file-obj>) when done.  <Options> 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
<file-obj> "This is some text.") will put the string "This is some
text." in the file represented by <file-obj>.  Similarly, (READ
<file-obj>) or (TYI <file-obj>) 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 <ALAN @ MIT-MC>
To: JPG @ MIT-MC
cc: BUG-LISP @ MIT-MC
In-reply-to: Msg of 25 Jul 1983 18:33 EDT from Jeffrey P. Golden <JPG>

(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 <JPG @ MIT-MC>
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 <ALAN @ MIT-MC>
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 <JPG @ MIT-MC>
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 <KLOTZ@MIT-OZ>
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 <ALAN @ MIT-MC>
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 <MMMM>
    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 <KMP @ MIT-MC>
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 <DCB@MIT-OZ>
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 <ALAN @ MIT-MC>
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 <JPG>

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 <JPG @ MIT-MC>
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 <ALAN @ MIT-MC>
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 <ELLEN>
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 <ELLEN @ MIT-MC>

        Date: 12 July 1983 12:37 EDT
        From: Richard Gregory-Allen <RGA @ MIT-MC>

        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 <KMP @ MIT-MC>
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 <GJC>

    Date: 4 July 1983 16:09 EDT
    From: George J. Carrette <GJC>
    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 <KMP @ MIT-MC>
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 <JGA @ MIT-MC>
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 <alt> <ctrl-z> (#\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 <cr>.

The <cr>'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 <GJC @ MIT-MC>
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 <KMP @ MIT-MC>
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 <CFFK @ MIT-MC>
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)<space>
Then 'ABC' gets written out at position 20,20 and the
cursror homes.  However following this <newlines> don't get
generated.  E.g. t<space> ==> 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 <KMP @ MIT-MC>
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 <JPG @ MIT-MC>
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 <MACLISP> 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 <KMP @ MIT-MC>
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 <JPG>

    Date: 23 June 1983 04:24 EDT
    From: Jeffrey P. Golden <JPG>
    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 <MACLISP> 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 <JPG @ MIT-MC>
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 <MACLISP> 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 <CFFK @ MIT-MC>
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 <ALAN @ MIT-MC>
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 <ALAN @ MIT-MC>
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 <DUMPER@MIT-OZ>
Reply-to: File-Retrieve <FILE-R@MIT-OZ>
To: BUG-BACKUPERS
Subject: Migrated files

    The following files have been migrated:

PS:<MACLISP>6003.LISP.4
PS:<MACLISP>LISP.EXE.2131
PS:<MACLISP>TTY.FASL.18

Date: Saturday, 4 June 1983, 19:32-EDT
From: David M. J. Saslav <SAZ@MIT-OZ>
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: [email-masked]
Subject: MAKHUNK (yuch!)
To: [email-masked]
cc: [email-masked]

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 <ALAN@MIT-OZ>
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 <GJC @ MIT-MC>
Subject:  <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>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: <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>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:<LIBLSP>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 <SJOBRG @ MIT-MC>
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 <SJOBRG @ MIT-MC>
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 <ALAN @ MIT-MC>
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 <MALACHI at SU-SCORE.ARPA>

    Date: Thu 5 May 83 14:26:24-PDT
    From: Yoni Malachi <MALACHI at SU-SCORE.ARPA>
    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 <[email-masked]>
Subject: Macrodef
To: [email-masked]

Where is it?
Yoni.
-------

Date: Thursday, May 5, 1983 2:58AM-EDT
From: David Vinayak Wallace <GUMBY@MIT-OZ>
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 <ALAN @ MIT-MC>
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 <DCP @ MIT-MC>
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 <ALAN @ MIT-MC>

    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 <ALAN @ MIT-MC>
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 <Bil @ MIT-MC>
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 <Gumby at MIT-OZ>
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 <ALAN @ MIT-MC>
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 <kmp at MIT-MC>
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 <FAHLMAN at CMU-CS-C>,
    Leonard Zubkoff <Zubkoff at CMU-CS-C>,
    Neal Feinberg <feinberg at CMU-CS-C>, 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 <CENT @ MIT-ML>
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 <Mailer@MIT-OZ>
To: <TU77-MAN@MIT-OZ>
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:<LIBLSP>APROPOS.FASL.1
-------

Date: 11 April 1983 21:08 EST
From: Kent M. Pitman <KMP @ MIT-MC>
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 <KMP @ MIT-MC>
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 <BAGLEY@MIT-OZ>
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 <ALAN@MIT-OZ>
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 <ALAN @ MIT-MC>
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 <DCP@SCRC-TENEX>
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 <GJC @ MIT-MC>
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 <GSB at MIT-ML>
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 <GSB at MIT-ML>

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 <GSB @ MIT-ML>
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 <BSG@SCRC-TENEX>
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 <DCP at SCRC-TENEX>

    Date: Tuesday, 5 April 1983, 04:18-EST
    From: David C. Plummer <DCP at SCRC-TENEX>
    [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 <DCP@SCRC-TENEX>
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 <DCP at SCRC-TENEX>

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 <DCP at SCRC-TENEX>
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 <ALAN @ MIT-MC>
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 <Gumby at MIT-OZ>

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 <PONDY@MIT-OZ>
To:   David Vinayak Wallace <Gumby@MIT-OZ>
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 <Gumby>

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 <Gumby@MIT-OZ>
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 <PONDY@MIT-OZ>
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 <GLR@MIT-OZ>
To:   Alan Bawden <ALAN@MIT-MC>
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 at MIT-MC>

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 <ALAN @ MIT-MC>
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 <GLR at MIT-OZ>

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 <GLR@MIT-OZ>
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 <ALAN@MIT-OZ>
To:   Bug-Lisp@MIT-MC
Subject: (very) old pathname system: is this right?

(open '((ps alan) 2x3))
#FILE-IN-|PS:<ALAN>2X3.LSP.9|-71740 
(close *)
T 
(namestring '((ps alan) 2x3))
|PS:<ALAN>2X3.*|		;???
(open *)
;(OPEN |PS:<ALAN>2X3.*|) NO SUCH FILE TYPE

;BKPT IO-LOSSAGE

Date: 7 March 1983 21:53 EST
From: Glenn S. Burke <GSB @ MIT-ML>
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 <GUMBY @ MIT-OZ>
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 <KMP @ MIT-MC>
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 <GSB @ MIT-ML>
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 <KMP @ MIT-MC>
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 <GJC @ MIT-MC>
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 <KMP>

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 <ALAN @ MIT-MC>
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 <KMP @ MIT-MC>
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 <KMP @ MIT-MC>
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 <MARTY at MIT-OZ>
Subject: OZ:PS:<MACLISP>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 <N> ....).

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 <GUMBY @ MIT-MC>
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 [email-masked]

    Date: 15 Feb 83 21:14 PST (Tuesday)
    From: [email-masked]

    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: [email-masked]
Subject: Re: I really don't know where to send this one...
In-reply-to: [email-masked]'s message of Mon, 14 Feb 83 14:40:50
 PST
To: MacLisp Hackers <[email-masked]>
cc: [email-masked], [email-masked],
 [email-masked], [email-masked],
 [email-masked]

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 <[email-masked]>
Subject: Re: I really don't know where to send this one...
To: [email-masked], [email-masked],
    [email-masked], [email-masked],
    [email-masked]
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 <NCP.EGK@SU-GSB-HOW>
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 <GUMBY @ MIT-MC>
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 <KMP @ MIT-MC>
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 <kmp at MIT-MC>
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 <DCP @ MIT-MC>

    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 <DCP @ MIT-MC>
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 <GJC @ MIT-MC>
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
[H[J
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 <FEINBERG@CMU-CS-C>; 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 <MACLISP>TTY.FASL, and use DO-WITH-TTY-OFF, like so:

(DO-WITH-TTY-OFF <form1> <form2> ... <formn>)  ;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?