[asdf-devel] something in recent commit causes ACL testing to go into an infinite loop

[Robert Goldman]

On 3/21/10 Mar 21 -10:49 AM, Robert Goldman wrote:
> Now when I run the tests on allegro I get a FILE-INCOMPATIBLE-FASL-ERROR
> on file3.fasl.  ASDF then tries to invoke the ASDF:RETRY restart.  Then
> it gets the FILE-INCOMPATIBLE-FASL-ERROR on file3.fasl.  ASDF then tries
> to invoke the ASDF:RETRY restart.  Then ....
> 
> This happened when I tested with 8.2 after testing on 8.1.
> 
> When I run this interactively, with the -d option on the command line, I
> can invoke a restart which recompiles the file in question, and the
> tests complete successfully (21 of 21 successful).
> 
> So this suggests that there is a bug in the ASDF:RETRY restart.
> 

Quick follow-up:  I encountered the bug again when testing with 8.2
allegromodern

This suggests there may be > 1 bug here.  One bug being the fact that
the RESTART throws us into an infinite loop.

The second is that the output-locations are not functioning properly.
With the output-locations, I don't think ACL should ever be trying to
load stale fasls --- I think this bug comes with it trying to load the
old 8.1 fasls lying around.  These should be in a different directory.

Here's the issue --- we see the following load form:

Fast loading /Users/rpg/lisp/asdf/tmp/fasls/mlisp/test/file3.fasl
Caught error #<file-incompatible-fasl-error @ #x1000bbafc2>; $ cp
try-reloading-dependency.hidden try-reloading-dependency.asd


Why is this mlisp?  Why isn't it one of:


(#P"/Users/rpg/.cache/common-lisp/allegro-8.2a-64bit-macosx-x86-64/**/*.*"

#P"/Users/rpg/.cache/common-lisp/allegro-8.2a-64bit-macosx-x86-64/**/*.*")

seems like we're not getting the implementation-specific output
directory we should get, but instead getting some ad hoc one that the
scripts are creating.

R