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