This block of test is failing: (DBG "Load ASDF with proper configuration: should find asdf.asd from the source above") (initialize-source-registry `(:source-registry (:directory ,*asdf-directory*) (:directory ,*uiop-directory*) :ignore-inherited-configuration)) (clear-system "asdf") (load-system :asdf) ;; This time we found it, but it was skipped because the version was the same (assert-equal nil (system-source-file (find-system :asdf))) Can you explain why it's correct to have the SYSTEM-SOURCE-FILE of ASDF be NIL? I'm sorry, but I simply don't understand what you are testing here, or why the right answer is NIL. I think there's some critical fact about the system that you expect to hold after the immediately previous call to UPGRADE ASDF, but I don't know what it is. This is what's in the log file: While evaluating the form starting at line 48, column 0 of #P"/Users/rpg/lisp/asdf/test/test-sysdef-asdf.script": TEST ABORTED: These two expressions fail comparison with EQUAL: NIL evaluates to NIL (SYSTEM-SOURCE-FILE (FIND-SYSTEM :ASDF)) evaluates to #P"/Users/rpg/lisp/asdf/asdf.asd" Thanks, r
On Fri, Feb 26, 2016 at 1:45 PM, Robert Goldman <rpgoldman@sift.net> wrote:
This test fails for me on SBCL, Allegro, and CCL.
The problem was that your bump-version script did an incomplete job at updating all occurrences of 3.1.6.13 to 3.1.6.14, and this confused the mechanism whereby asdf declines to load a version of itself that isn't strictly more recent, so as not to upset its current state (and to make upgrade idempotent). I tried to update your bump-version script, but perl gave me a headache and I stopped trying. If the new-style test scripts aren't reliable enough for you on windows and mac, hopefully the lisp bump-version script should still be working fine on linux and mac. It should only be run when asdf is working correctly, at which point the bootstrap issues should be stable. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To make an apple pie from scratch, you must first create the universe. — Carl Sagan
I'll fix it tomorrow, thanks for the explanation. I couldn't figure out how to salvage the old bump script, since there is a new one in the full lisp scripting system. Sent from my iPhone
On Feb 26, 2016, at 22:39, Faré <fahree@gmail.com> wrote:
On Fri, Feb 26, 2016 at 1:45 PM, Robert Goldman <rpgoldman@sift.net> wrote: This test fails for me on SBCL, Allegro, and CCL. The problem was that your bump-version script did an incomplete job at updating all occurrences of 3.1.6.13 to 3.1.6.14, and this confused the mechanism whereby asdf declines to load a version of itself that isn't strictly more recent, so as not to upset its current state (and to make upgrade idempotent).
I tried to update your bump-version script, but perl gave me a headache and I stopped trying. If the new-style test scripts aren't reliable enough for you on windows and mac, hopefully the lisp bump-version script should still be working fine on linux and mac. It should only be run when asdf is working correctly, at which point the bootstrap issues should be stable.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To make an apple pie from scratch, you must first create the universe. — Carl Sagan
On Sat, Feb 27, 2016 at 6:10 AM, Robert P. Goldman <rpgoldman@sift.net> wrote:
I'll fix it tomorrow, thanks for the explanation.
I couldn't figure out how to salvage the old bump script, since there is a new one in the full lisp scripting system.
The previous script was also written in lisp, using a more rudimentary ancestor of the current scripting system. I don't see how it would work and not the current lisp script. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In a just society, it is shameful to be poor. In a corrupt society, it is shameful to be rich. — Confucius
OK, I fixed the script, which was failing to modify upgrade.lisp. So now every location that I can find has the correct version expression, and the tests pass. I still return to the original question: What is this test intended to establish? According to the test source code, there is a condition under which not only do we return NIL for the system definition file for ASDF, but it is an error to return anything but NIL. What is that condition? Why is it ever an error to have ASDF loaded but have its system definition file be undefined? I suspect that what happens is that if ASDF is already loaded and current, system-source-file of find-system returns NIL. But why? Can you explain this test? There is no docstring for SYSTEM-SOURCE-FILE, so it's hard to see why it should ever be NIL. If I hadn't seen this test, I would have guessed that returning NIL for an existant system wold be an error condition. thanks! r
On Sat, Feb 27, 2016, 20:14 Robert Goldman <rpgoldman@sift.net> wrote:
OK, I fixed the script, which was failing to modify upgrade.lisp.
So now every location that I can find has the correct version expression, and the tests pass.
OK. I still return to the original question:
What is this test intended to establish?
According to the test source code, there is a condition under which not only do we return NIL for the system definition file for ASDF, but it is an error to return anything but NIL.
What is that condition? Why is it ever an error to have ASDF loaded but have its system definition file be undefined?
I suspect that what happens is that if ASDF is already loaded and current, system-source-file of find-system returns NIL. But why? Can you explain this test? There is no docstring for SYSTEM-SOURCE-FILE, so it's hard to see why it should ever be NIL. If I hadn't seen this test, I would have guessed that returning NIL for an existant system wold be an error condition.
The test is checking that ASDF is refusing to either downgrade or reload a same version of ASDF. A system-source-file can be nil when a system was not loaded from mass storage but preloaded or otherwise programmatically defined via e.g. (eval `(defsystem ...)) In this test, ASDF *is* found in the source registry, but it's version is not strictly more recent than the one in memory, so trying to load it should NOT result in ASDF being loaded, but instead in a warning being issued. —#f
participants (3)
-
Faré -
Robert Goldman -
Robert P. Goldman