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.com> wrote:
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