[asdf-devel] something in recent commit causes ACL testing to go into an infinite loop
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.
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
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.
That's a bug. I don't know anything about it, though. It may have already existed, or I may have broken something when moving the restarts to their own function.
The second is that the output-locations are not functioning properly.
They work properly. They are just not configured the way you'd like. During testing, I recently changed the compile script from "always compile asdf.lisp" to "only compile it if it hasn't changed", with the output in asdf-*implementation*.lisp, to speed up testing at a time I was doing lots of it. Since the asdf fasl name only included the implementation name, I decided that it didn't make sense to add more distinctions to the other fasl names, and configured the output-translations accordingly. To make tests from clean, you can rm -rf asdf/tmp/ [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Anarchism is founded on the observation that since few men are wise enough to rule themselves, even fewer are wise enough to rule others. — Edward Abbey
I understand about the change to the output, and the not recompiling, but I think you're not using the standard implementation rewriting rules, because, e.g., all the modern lisp binaries are going into "mlisp," whereas ordinarily 8.1 and 8.2 fasls would go into different directories, right? Would it be possible to use the normal rewrite rules in the tests? Best R "Faré" <fahree@gmail.com> wrote:
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.
That's a bug. I don't know anything about it, though. It may have already existed, or I may have broken something when moving the restarts to their own function.
The second is that the output-locations are not functioning properly.
They work properly. They are just not configured the way you'd like.
During testing, I recently changed the compile script from "always compile asdf.lisp" to "only compile it if it hasn't changed", with the output in asdf-*implementation*.lisp, to speed up testing at a time I was doing lots of it.
Since the asdf fasl name only included the implementation name, I decided that it didn't make sense to add more distinctions to the other fasl names, and configured the output-translations accordingly.
To make tests from clean, you can rm -rf asdf/tmp/
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Anarchism is founded on the observation that since few men are wise enough to rule themselves, even fewer are wise enough to rule others. — Edward Abbey
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
On 22 March 2010 22:13, Robert Goldman <rpgoldman@sift.info> wrote:
I understand about the change to the output, and the not recompiling, but I think you're not using the standard implementation rewriting rules, because, e.g., all the modern lisp binaries are going into "mlisp," whereas ordinarily 8.1 and 8.2 fasls would go into different directories, right?
Would it be possible to use the normal rewrite rules in the tests?
Sure but then we should either 1- always recompile asdf.lisp (as before) or 2- copy all the implementation directory detection into compile-asdf.lisp I'm leaning towards solution 1. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Always remember that you are unique. Just like everyone else.
On 22 March 2010 22:35, Faré <fahree@gmail.com> wrote:
On 22 March 2010 22:13, Robert Goldman <rpgoldman@sift.info> wrote:
Would it be possible to use the normal rewrite rules in the tests?
Sure but then we should either 1- always recompile asdf.lisp (as before) or 2- copy all the implementation directory detection into compile-asdf.lisp
I'm leaning towards solution 1.
Meh, another problem that's not worth the time spent arguing it. I just committed something that will hopefully satisfy you: try load asdf.fasl before you declare it OK. If loading fails, recompile. This will hopefully catch the cases where the compiler changed incompatibly. Then, use the "normal" :implementation redirection for further FASLs. Please try again. Sorry for the noise. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Instead of loving your enemies, treat your friends a little better. — Edgar Watson Howe
On 3/22/10 Mar 22 -10:04 PM, Faré wrote:
On 22 March 2010 22:35, Faré <fahree@gmail.com> wrote:
On 22 March 2010 22:13, Robert Goldman <rpgoldman@sift.info> wrote:
Would it be possible to use the normal rewrite rules in the tests?
Sure but then we should either 1- always recompile asdf.lisp (as before) or 2- copy all the implementation directory detection into compile-asdf.lisp
I'm leaning towards solution 1.
Meh, another problem that's not worth the time spent arguing it.
I just committed something that will hopefully satisfy you: try load asdf.fasl before you declare it OK. If loading fails, recompile. This will hopefully catch the cases where the compiler changed incompatibly. Then, use the "normal" :implementation redirection for further FASLs.
Please try again. Sorry for the noise.
Brilliant, Faré, thanks. Working now. I will ticket the restart issue, because it is probably worth a check. I will see if I can make a test case. May just be a matter of us not having thought about the restarts being used under programmatic control (as in the test scripts) instead of interactively. Best, r
participants (2)
-
Faré -
Robert Goldman