I got through almost all the upgrade tests before failing with allegromodern trying to upgrade from 1.85:
; registering #<system :asdf @ #x1000afe932> as asdf ; Fast loading /Users/rpg/lisp/asdf/build/asdf.fasl TEST ABORTED: Attempt to fast load a non-fasl file: #P"/Users/rpg/lisp/asdf/build/asdf.fasl" Script failed upgrade FAILED for allegromodern from 1.85 using method 'load-asdf-lisp'load-asdf-system
I can see why this fails!
When I look at ~/lisp/asdf/build/asdf.fasl in emacs I see this:
#!/usr/local/bin/sbcl --script # FASL compiled from "/Users/rpg/lisp/asdf/build/asdf.lisp" using SBCL version 1.1.3.7-63e78fc
which suggests to me that we may be leaking something from one test to another...
best, r
On Tue, Feb 26, 2013 at 3:00 PM, Robert Goldman rpgoldman@sift.info wrote:
I got through almost all the upgrade tests before failing with allegromodern trying to upgrade from 1.85:
; registering #<system :asdf @ #x1000afe932> as asdf ; Fast loading /Users/rpg/lisp/asdf/build/asdf.fasl TEST ABORTED: Attempt to fast load a non-fasl file: #P"/Users/rpg/lisp/asdf/build/asdf.fasl" Script failed upgrade FAILED for allegromodern from 1.85 using method 'load-asdf-lisp'load-asdf-system
I can see why this fails!
When I look at ~/lisp/asdf/build/asdf.fasl in emacs I see this:
#!/usr/local/bin/sbcl --script # FASL compiled from "/Users/rpg/lisp/asdf/build/asdf.lisp" using SBCL version 1.1.3.7-63e78fc
which suggests to me that we may be leaking something from one test to another...
Oh, I see.
Usually, we do not create a build/asdf.fasl, because the output-translations layer moves it away.
However, when testing antique version 1.85, we do create that file. And then, we have the clash between asdf.fasl from sbcl and asdf.fasl from allegro, just like we used to have in the bad old times — precisely because we're testing an upgrade from the bad old times.
To counter that, the first upgrade target is load-asdf-lisp-clean, but in this case, it wasn't cleaning enough.
I've pushed a fix to the repository, and my manual testing suggests the tests are working after in a way that they weren't before: make u l=sbcl ASDF_UPGRADE_TEST_TAGS=1.85 make u l=allegro ASDF_UPGRADE_TEST_TAGS=1.85
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Any sufficiently advanced misquotation is indistinguishable from an original statement. — John McCarthy, misquoted
On 2/26/13 Feb 26 -2:52 PM, Faré wrote:
On Tue, Feb 26, 2013 at 3:00 PM, Robert Goldman rpgoldman@sift.info wrote:
I got through almost all the upgrade tests before failing with allegromodern trying to upgrade from 1.85:
; registering #<system :asdf @ #x1000afe932> as asdf ; Fast loading /Users/rpg/lisp/asdf/build/asdf.fasl TEST ABORTED: Attempt to fast load a non-fasl file: #P"/Users/rpg/lisp/asdf/build/asdf.fasl" Script failed upgrade FAILED for allegromodern from 1.85 using method 'load-asdf-lisp'load-asdf-system
I can see why this fails!
When I look at ~/lisp/asdf/build/asdf.fasl in emacs I see this:
#!/usr/local/bin/sbcl --script # FASL compiled from "/Users/rpg/lisp/asdf/build/asdf.lisp" using SBCL version 1.1.3.7-63e78fc
which suggests to me that we may be leaking something from one test to another...
Oh, I see.
Usually, we do not create a build/asdf.fasl, because the output-translations layer moves it away.
However, when testing antique version 1.85, we do create that file. And then, we have the clash between asdf.fasl from sbcl and asdf.fasl from allegro, just like we used to have in the bad old times — precisely because we're testing an upgrade from the bad old times.
To counter that, the first upgrade target is load-asdf-lisp-clean, but in this case, it wasn't cleaning enough.
I've pushed a fix to the repository, and my manual testing suggests the tests are working after in a way that they weren't before: make u l=sbcl ASDF_UPGRADE_TEST_TAGS=1.85 make u l=allegro ASDF_UPGRADE_TEST_TAGS=1.85
Drat! Still not fully fixed in the context of
make test-all-upgrade
Above backtrace due to this condition: #P"/Users/rpg/.cache/common-lisp/acl-8.2m-macosx-x64/Users/rpg/lisp/asdf/build/asdf.fasl" does not exist, cannot load Script failed upgrade FAILED for allegromodern from 1.85 using method 'load-asdf-lisp'load-asdf-system you can retry just that test with: ASDF_UPGRADE_TEST_TAGS="1.85" ASDF_UPGRADE_TEST_METHODS="'load-asdf-lisp'load-asdf-system" ./test/run-tests.sh -u allegromodern or more interactively (and maybe with rlwrap or in emacs), start with: mlisp -q then copy/paste: (load"test/script-support.lisp") (asdf-test::da) (test-upgrade 'load-asdf-lisp'load-asdf-system "1.85")
My guess is that this is another one of those bugs that's a bug in the testing, rather than in ASDF itself...
I notice that the test is trying to load from my .cache rather than loading from the special place for parking asdf test products. Is that related?
Best, r
Drat! Still not fully fixed in the context of [...]
OK, so I pushed an update to the test scripts that better handles output translations in the context of upgrade from old versions of ASDF.
My guess is that this is another one of those bugs that's a bug in the testing, rather than in ASDF itself...
Yes, it is. I also rewrote most of the testing infrastructure over the last few months, though happily I didn't have to preserve 100% backward incompatibility here, since the only client is asdf.
I notice that the test is trying to load from my .cache rather than loading from the special place for parking asdf test products. Is that related?
Definitely was part of the bug. I didn't chase the ins and outs of what was wrong, but I put in belt and suspenders to ensure that the output-translations is properly defined during upgrade.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A flea and a fly in a flue were imprisoned, so what could they do? Said the fly: "let us flee!". Said the flea: "let us fly!". So they flew thru a flaw in the flue...
-
Faré -
Robert Goldman