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") T CL-USER(2): (foo-bar-rb) (foo-bar '(foo))
Maximum error depth exceeded (11 nested errors) with 'FASL version mismatch; found '57' but expected '39' in with-standard-io-syntax'. CL-USER(3):
I don't get the whole FASL stuff.
Blake
On Mon, Jul 23, 2012 at 5:40 PM, Alessio Stalla alessiostalla@gmail.comwrote:
On Mon, Jul 23, 2012 at 6:48 PM, Durward McDonell durward.mcdonell@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".
Hi!
What FASL are you speaking of? There is nothing explicitly loading one in your code. Is this related to autoloading?
Cheers Alessio
armedbear-devel mailing list armedbear-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel