[armedbear-devel] bug in FASL loader
blake at mcbride.name
Tue Jul 24 00:56:22 UTC 2012
Wow, I get some really weird stuff testing this with the latest trunk as
follows. (I put his code in a file named yyy.lisp. I did not compile it.
There is no yyy.fasl)
Blake-Mac-17:tmp blake$ abcl
Armed Bear Common Lisp 1.1.0-dev-svn-14015
Java 1.6.0_33 Apple Inc.
Java HotSpot(TM) 64-Bit Server VM
Low-level initialization completed in 0.369 seconds.
Startup completed in 1.371 seconds.
Type ":help" for a list of available commands.
CL-USER(1): (load "yyy.lisp")
Maximum error depth exceeded (11 nested errors) with 'FASL version
mismatch; found '57' but expected '39' in with-standard-io-syntax'.
I don't get the whole FASL stuff.
On Mon, Jul 23, 2012 at 5:40 PM, Alessio Stalla <alessiostalla at gmail.com>wrote:
> On Mon, Jul 23, 2012 at 6:48 PM, Durward McDonell
> <durward.mcdonell at jhuapl.edu> wrote:
> > Hello.
> > I believe I have found a bug in FASL loading, with respect
> > to *read-base* being reset. At least, I get the behavior I
> > expect in sbcl, and not in abcl.
> > Consider the following code:
> > (defmacro foo-bar (s)
> > `(sublis '((foo . bar)) ,s))
> > (defun foo-bar-rb ()
> > (let ((*read-base* #x10)
> > (it (read)))
> > (eval it)))
> > Load this code, then execute (foo-bar-rb).
> > It will wait for input. Type (foo-bar '(foo)).
> > I would expect this to evaluate to (bar), but
> > abcl gives a FASL version mismatch, where it
> > seems that it is reading the FASL in the new
> > base (16 instead of 10), and reports "found '56'
> > but expected '38' in sublis".
> What FASL are you speaking of? There is nothing explicitly loading one
> in your code. Is this related to autoloading?
> armedbear-devel mailing list
> armedbear-devel at common-lisp.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the armedbear-devel