[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: typo
- To: (BUG LISP) at MIT-AI
- To: (BUG LISP) at MIT-AI
- To: bug-lisp @ mc
- Subject: Re: typo
- From: ALAN@MIT-AI
- From: ALAN@MIT-AI
- From: Dave Touretzky <Dave.Touretzky at CMU-10A>
- Date: Fri, 10 Nov 79 05:33:46 GMT
- Date: Fri, 10 Nov 79 05:30:59 GMT
- Date: Wed, 10 Oct 79 23:29:00 GMT
- Cc: Scott.Fahlman at CMU-10A, John.McDermott at CMU-10A
- Original-date: 10/11/79 01:33:46 EDT
- Original-date: 10/11/79 01:30:59 EDT
- Original-date: 10 October 1979 1929-EDT
There appears to be a strange bug in FASLOAD that causes it to get
halfway through and then say "file not in fasload format", although
under other conditions the file will load fine. To reproduce this
bug, log in on CMUA and do:
.mount temp: ;if temp: not already mounted
.run vops[a780jm01]
(lslurp a780jm01 xtty)
(lslurp a780jm01 border)
(configure order7)
Note that the program tries to load SORT.FAS and gets an error from
fasload. Also, EDIT.FAS may fail to load under the same conditions.
I know the fasl files are alright; they load without trouble most of
the time. But in certain weird but reproducible situations this bug
shows up.
Things to think about:
SLURP has its own autoload handler. Perhaps the bug is in
some compiled code in the SLURP package clobbering something
that fasload uses.
Setting the variable GC-MESSAGES to T shows that FIXNUM space
is being expanded during the autoload. However, you can ^G out
and call (SORT) or (EDITF) explicitly, and the second time storage
does not get expanded but the error recurs.
This bug is causing some grief to one of our MacLisp users. Any help
you could give me on it would be appreciated.