On 9/14/16 Sep 14 -6:14 AM, Faré wrote:
I don't know whether that would help on Windows, but I have a fix for the require-system function that hopefully makes test-force stable, in !16 on gitlab.
Mostly I'm working my way back through history, then forward.
3.1.7.16 was broken because of the typo. 3.1.7.17 has the typo fixed, but fails test-clean-load on ecl_bytecodes. I believe that this is spurious, though. It's crashing on the code that hooks into REQUIRE, and it crashes only when run as
make test-clean-load l=ecl_bytecodes
and NOT when run as
run-tests.sh -c ecl_bytecodes
Here's the error:
An error occurred during initialization: In form (PROGN (PUSHNEW '("fasb" . SI:LOAD-BINARY) *LOAD-HOOKS* :TEST 'EQUAL :KEY 'CAR) (UNLESS (ASSOC "asd" *LOAD-HOOKS* :TEST 'EQUAL) (APPENDF *LOAD-HOOKS* '(("asd" . SI:LOAD-SOURCE)))) (DEFVAR *WRAPPED-MODULE-PROVIDER* (MAKE-HASH-TABLE)) (SETF (GETHASH 'MODULE-PROVIDE-ASDF *WRAPPED-MODULE-PROVIDER*) 'MODULE-PROVIDE-ASDF) (DEFUN WRAP-MODULE-PROVIDER (PROVIDER NAME) (LET ((RESULTS (MULTIPLE-VALUE-LIST (FUNCALL PROVIDER NAME)))) (WHEN (FIRST RESULTS) (REGISTER-PRELOADED-SYSTEM (COERCE-NAME NAME))) (VALUES-LIST RESULTS))) (SETF *MODULE-PROVIDER-FUNCTIONS* (LOOP :FOR PROVIDER :IN *MODULE-PROVIDER-FUNCTIONS* :COLLECT (ENSURE-GETHASH PROVIDER *WRAPPED-MODULE-PROVIDER* #'(LAMBDA (MODULE-NAME) (WRAP-MODULE-PROVIDER PROVIDER MODULE-NAME)))))) Wrong number of arguments passed to function NIL..
I have checked what I thought was the obvious hypothesis: a NIL in *MODULE-PROVIDER-FUNCTIONS* -- but that is not the cause. And why the intercession of "make" should matter, I cannot say.
I'm just not sure if there's any version that passes the tests on Windows since 16 August 2016.
I'll have another look, but may have to give up the bisect strategy and just try to fix the head. This is obviously deeply undesirable. But bisect assumes that I can detect the interesting failures in a hill-climbing way, whereas here we have multiple points at which breakage has been introduced.
Unfortunately, unlike on Mac and Linux, I have absolutely no clue how to automate Windows testing, which leads to these messes, which are precisely what continuous integration is supposed to avoid.
best, r
On Tue, Sep 13, 2016, 23:05 Robert Goldman <rpgoldman@sift.net mailto:rpgoldman@sift.net> wrote:
Unfortunately, the last time I was able to run the Windows tests before 2 days ago was in mid-August. Since then, there have been a flurry of commits, many of which could have impacted the state of test-force.script. Indeed, test-force.script *itself* has changed, so that, although we call it a "regression test," we have no reason to believe that it *ever* worked on Windows in its present form. Unfortunately, it may take me a while to get enough bisecting done to figure out when we jumped the rails. I'll keep everyone posted, but in the meantime, we should consider the repo locked against more changes. Windows is badly broken, and we shouldn't be trying to move forward again until we have restored function on this platform. thanks, r
Sorry, it's my bad for checking in bad code in master (that I fixed later on, but too late).
What's failing at head on which implementations, already? Can you publish logs?
It's so annoying that there isn't a free-as-in-beer reputable non-malware test image of Windows to use for testing.
-#f
On Wed, Sep 14, 2016, 09:59 Robert Goldman rpgoldman@sift.net wrote:
On 9/14/16 Sep 14 -6:14 AM, Faré wrote:
I don't know whether that would help on Windows, but I have a fix for the require-system function that hopefully makes test-force stable, in !16 on gitlab.
Mostly I'm working my way back through history, then forward.
3.1.7.16 was broken because of the typo. 3.1.7.17 has the typo fixed, but fails test-clean-load on ecl_bytecodes. I believe that this is spurious, though. It's crashing on the code that hooks into REQUIRE, and it crashes only when run as
make test-clean-load l=ecl_bytecodes
and NOT when run as
run-tests.sh -c ecl_bytecodes
Here's the error:
An error occurred during initialization: In form (PROGN (PUSHNEW '("fasb" . SI:LOAD-BINARY) *LOAD-HOOKS* :TEST 'EQUAL :KEY 'CAR) (UNLESS (ASSOC "asd" *LOAD-HOOKS* :TEST 'EQUAL) (APPENDF *LOAD-HOOKS* '(("asd" . SI:LOAD-SOURCE)))) (DEFVAR *WRAPPED-MODULE-PROVIDER* (MAKE-HASH-TABLE)) (SETF (GETHASH 'MODULE-PROVIDE-ASDF *WRAPPED-MODULE-PROVIDER*) 'MODULE-PROVIDE-ASDF) (DEFUN WRAP-MODULE-PROVIDER (PROVIDER NAME) (LET ((RESULTS (MULTIPLE-VALUE-LIST (FUNCALL PROVIDER NAME)))) (WHEN (FIRST RESULTS) (REGISTER-PRELOADED-SYSTEM (COERCE-NAME NAME))) (VALUES-LIST RESULTS))) (SETF *MODULE-PROVIDER-FUNCTIONS* (LOOP :FOR PROVIDER :IN *MODULE-PROVIDER-FUNCTIONS* :COLLECT (ENSURE-GETHASH PROVIDER *WRAPPED-MODULE-PROVIDER* #'(LAMBDA (MODULE-NAME) (WRAP-MODULE-PROVIDER PROVIDER MODULE-NAME)))))) Wrong number of arguments passed to function NIL..
I have checked what I thought was the obvious hypothesis: a NIL in *MODULE-PROVIDER-FUNCTIONS* -- but that is not the cause. And why the intercession of "make" should matter, I cannot say.
I'm just not sure if there's any version that passes the tests on Windows since 16 August 2016.
I'll have another look, but may have to give up the bisect strategy and just try to fix the head. This is obviously deeply undesirable. But bisect assumes that I can detect the interesting failures in a hill-climbing way, whereas here we have multiple points at which breakage has been introduced.
Unfortunately, unlike on Mac and Linux, I have absolutely no clue how to automate Windows testing, which leads to these messes, which are precisely what continuous integration is supposed to avoid.
best, r
On Tue, Sep 13, 2016, 23:05 Robert Goldman <rpgoldman@sift.net mailto:rpgoldman@sift.net> wrote:
Unfortunately, the last time I was able to run the Windows testsbefore
2 days ago was in mid-August. Since then, there have been a flurryof
commits, many of which could have impacted the state of test-force.script. Indeed, test-force.script *itself* has changed, so that, although we call it a "regression test," we have no reason to believe that it*ever*
worked on Windows in its present form. Unfortunately, it may take me a while to get enough bisecting done to figure out when we jumped the rails. I'll keep everyone posted, butin
the meantime, we should consider the repo locked against morechanges.
Windows is badly broken, and we shouldn't be trying to move forward again until we have restored function on this platform. thanks, r
On 9/14/16 Sep 14 -9:07 AM, Faré wrote:
Sorry, it's my bad for checking in bad code in master (that I fixed later on, but too late).
What's failing at head on which implementations, already? Can you publish logs?
Allegro (all flavors), CCL, SBCL, and ECL-bytecodes (note that I don't have the toolchain to run ECL non-bytecodes on windows) all fail test-force, and all fail in the same way:
SBCL:
Check that require-system of touched .asd will reload the asdf. (That's what it does now, but if it could be fixed that'd be nice.) While evaluating the form starting at line 96, column 0 of #P"F:/asdf/test/test-force.script": TEST ABORTED: These two expressions fail comparison with EQUAL: (ASYMVAL :*TIMES-LOADED* :TEST-ASDF-SYSTEM) evaluates to 1 2 evaluates to 2
CCL: Check that require-system of touched .asd will reload the asdf. (That's what it does now, but if it could be fixed that'd be nice.) TEST ABORTED: These two expressions fail comparison with EQUAL: (ASYMVAL :*TIMES-LOADED* :TEST-ASDF-SYSTEM) evaluates to 1 2 evaluates to 2
ECL and Allegro same. Backtraces useless because the action seems to be in either how REQUIRE-SYSTEM is detecting the need to reload or in how TOUCH-FILE and GET-FILE-STAMP are working on Windows, and those aren't on the stack when the assertion fails.
Cheers, r
Hopefully, my branch fixes test-force on Windows as well as on Linux.
I wouldn't worry too much about test-force until the current development is complete. It's a release blocker, but not an otherwise worrisome deal since it's new tests for a recently discovered issue that we now understand how to improve upon without breaking other features, thanks to Daniel Kochmanski's patient work.
-#f
On Wed, Sep 14, 2016, 12:50 Robert Goldman rpgoldman@sift.net wrote:
On 9/14/16 Sep 14 -9:07 AM, Faré wrote:
Sorry, it's my bad for checking in bad code in master (that I fixed later on, but too late).
What's failing at head on which implementations, already? Can you publish logs?
Allegro (all flavors), CCL, SBCL, and ECL-bytecodes (note that I don't have the toolchain to run ECL non-bytecodes on windows) all fail test-force, and all fail in the same way:
SBCL:
Check that require-system of touched .asd will reload the asdf. (That's what it does now, but if it could be fixed that'd be nice.) While evaluating the form starting at line 96, column 0 of #P"F:/asdf/test/test-force.script": TEST ABORTED: These two expressions fail comparison with EQUAL: (ASYMVAL :*TIMES-LOADED* :TEST-ASDF-SYSTEM) evaluates to 1 2 evaluates to 2
CCL: Check that require-system of touched .asd will reload the asdf. (That's what it does now, but if it could be fixed that'd be nice.) TEST ABORTED: These two expressions fail comparison with EQUAL: (ASYMVAL :*TIMES-LOADED* :TEST-ASDF-SYSTEM) evaluates to 1 2 evaluates to 2
ECL and Allegro same. Backtraces useless because the action seems to be in either how REQUIRE-SYSTEM is detecting the need to reload or in how TOUCH-FILE and GET-FILE-STAMP are working on Windows, and those aren't on the stack when the assertion fails.
Cheers, r
On 9/14/16 Sep 14 -12:08 PM, Faré wrote:
Hopefully, my branch fixes test-force on Windows as well as on Linux.
I'm not sure I understand. In my experience, test-force is *only* broken on Windows, so there is nothing to be fixed on Linux (or Mac).
I'll try seeing if merging your patch fixes things on Windows. Is it tested on Linux?
I wouldn't worry too much about test-force until the current development is complete. It's a release blocker, but not an otherwise worrisome deal since it's new tests for a recently discovered issue that we now understand how to improve upon without breaking other features, thanks to Daniel Kochmanski's patient work.
-#f
On Wed, Sep 14, 2016, 12:50 Robert Goldman <rpgoldman@sift.net mailto:rpgoldman@sift.net> wrote:
On 9/14/16 Sep 14 -9:07 AM, Faré wrote: > Sorry, it's my bad for checking in bad code in master (that I fixed > later on, but too late). > > What's failing at head on which implementations, already? Can you > publish logs? Allegro (all flavors), CCL, SBCL, and ECL-bytecodes (note that I don't have the toolchain to run ECL non-bytecodes on windows) all fail test-force, and all fail in the same way: SBCL: Check that require-system of touched .asd will reload the asdf. (That's what it does now, but if it could be fixed that'd be nice.) While evaluating the form starting at line 96, column 0 of #P"F:/asdf/test/test-force.script": TEST ABORTED: These two expressions fail comparison with EQUAL: (ASYMVAL :*TIMES-LOADED* :TEST-ASDF-SYSTEM) evaluates to 1 2 evaluates to 2 CCL: Check that require-system of touched .asd will reload the asdf. (That's what it does now, but if it could be fixed that'd be nice.) TEST ABORTED: These two expressions fail comparison with EQUAL: (ASYMVAL :*TIMES-LOADED* :TEST-ASDF-SYSTEM) evaluates to 1 2 evaluates to 2 ECL and Allegro same. Backtraces useless because the action seems to be in either how REQUIRE-SYSTEM is detecting the need to reload or in how TOUCH-FILE and GET-FILE-STAMP are working on Windows, and those aren't on the stack when the assertion fails. Cheers, r
On 14 Sep 2016, at 20:12, Robert Goldman rpgoldman@sift.net wrote:
On 9/14/16 Sep 14 -12:08 PM, Faré wrote:
Hopefully, my branch fixes test-force on Windows as well as on Linux.
I'm not sure I understand. In my experience, test-force is *only* broken on Windows, so there is nothing to be fixed on Linux (or Mac).
I'll try seeing if merging your patch fixes things on Windows. Is it tested on Linux?
Assuming that the two of you are talking about the fix-require-system-function branch that
https://gitlab.common-lisp.net/asdf/asdf/merge_requests/16
is for, the answer is: Yes, it’s tested on Linux, in the sense that the results for it
it: http://139.162.161.212/asdf/3.1.7.19-5-7f6e4fa-fix-require-system-function/s... and the master branch: http://139.162.161.212/asdf/3.1.7.19-3-7b7b9f0/status
are identical.
Elias
On 14 Sep 2016, at 16:00, Robert Goldman rpgoldman@sift.net wrote:
On 9/14/16 Sep 14 -6:14 AM, Faré wrote:
I don't know whether that would help on Windows, but I have a fix for the require-system function that hopefully makes test-force stable, in !16 on gitlab.
Mostly I'm working my way back through history, then forward.
3.1.7.16 was broken because of the typo. 3.1.7.17 has the typo fixed, but fails test-clean-load on ecl_bytecodes. I believe that this is spurious, though. It's crashing on the code that hooks into REQUIRE, and it crashes only when run as
make test-clean-load l=ecl_bytecodes
and NOT when run as
run-tests.sh -c ecl_bytecodes
Here's the error:
An error occurred during initialization: In form (PROGN (PUSHNEW '("fasb" . SI:LOAD-BINARY) *LOAD-HOOKS* :TEST 'EQUAL :KEY 'CAR) (UNLESS (ASSOC "asd" *LOAD-HOOKS* :TEST 'EQUAL) (APPENDF *LOAD-HOOKS* '(("asd" . SI:LOAD-SOURCE)))) (DEFVAR *WRAPPED-MODULE-PROVIDER* (MAKE-HASH-TABLE)) (SETF (GETHASH 'MODULE-PROVIDE-ASDF *WRAPPED-MODULE-PROVIDER*) 'MODULE-PROVIDE-ASDF) (DEFUN WRAP-MODULE-PROVIDER (PROVIDER NAME) (LET ((RESULTS (MULTIPLE-VALUE-LIST (FUNCALL PROVIDER NAME)))) (WHEN (FIRST RESULTS) (REGISTER-PRELOADED-SYSTEM (COERCE-NAME NAME))) (VALUES-LIST RESULTS))) (SETF *MODULE-PROVIDER-FUNCTIONS* (LOOP :FOR PROVIDER :IN *MODULE-PROVIDER-FUNCTIONS* :COLLECT (ENSURE-GETHASH PROVIDER *WRAPPED-MODULE-PROVIDER* #'(LAMBDA (MODULE-NAME) (WRAP-MODULE-PROVIDER PROVIDER MODULE-NAME)))))) Wrong number of arguments passed to function NIL..
I have checked what I thought was the obvious hypothesis: a NIL in *MODULE-PROVIDER-FUNCTIONS* -- but that is not the cause. And why the intercession of "make" should matter, I cannot say.
I believe that was fixed by the commit immediately after 3.1.7.17, namely 33a2560f8589ae5b436f0fc26a75591cf2edcc60, no?
I could create a branch off of e.g. 3.1.7.11 for your testing where I cherry-pick from the current master, throw out irrelevant merges and clean up the history a bit, to make things easier to bisect.
Elias
On 9/14/16 Sep 14 -9:27 AM, Elias Pipping wrote:
On 14 Sep 2016, at 16:00, Robert Goldman rpgoldman@sift.net wrote:
On 9/14/16 Sep 14 -6:14 AM, Faré wrote:
I don't know whether that would help on Windows, but I have a fix for the require-system function that hopefully makes test-force stable, in !16 on gitlab.
Mostly I'm working my way back through history, then forward.
3.1.7.16 was broken because of the typo. 3.1.7.17 has the typo fixed, but fails test-clean-load on ecl_bytecodes. I believe that this is spurious, though. It's crashing on the code that hooks into REQUIRE, and it crashes only when run as
make test-clean-load l=ecl_bytecodes
and NOT when run as
run-tests.sh -c ecl_bytecodes
Here's the error:
An error occurred during initialization: In form (PROGN (PUSHNEW '("fasb" . SI:LOAD-BINARY) *LOAD-HOOKS* :TEST 'EQUAL :KEY 'CAR) (UNLESS (ASSOC "asd" *LOAD-HOOKS* :TEST 'EQUAL) (APPENDF *LOAD-HOOKS* '(("asd" . SI:LOAD-SOURCE)))) (DEFVAR *WRAPPED-MODULE-PROVIDER* (MAKE-HASH-TABLE)) (SETF (GETHASH 'MODULE-PROVIDE-ASDF *WRAPPED-MODULE-PROVIDER*) 'MODULE-PROVIDE-ASDF) (DEFUN WRAP-MODULE-PROVIDER (PROVIDER NAME) (LET ((RESULTS (MULTIPLE-VALUE-LIST (FUNCALL PROVIDER NAME)))) (WHEN (FIRST RESULTS) (REGISTER-PRELOADED-SYSTEM (COERCE-NAME NAME))) (VALUES-LIST RESULTS))) (SETF *MODULE-PROVIDER-FUNCTIONS* (LOOP :FOR PROVIDER :IN *MODULE-PROVIDER-FUNCTIONS* :COLLECT (ENSURE-GETHASH PROVIDER *WRAPPED-MODULE-PROVIDER* #'(LAMBDA (MODULE-NAME) (WRAP-MODULE-PROVIDER PROVIDER MODULE-NAME)))))) Wrong number of arguments passed to function NIL..
I have checked what I thought was the obvious hypothesis: a NIL in *MODULE-PROVIDER-FUNCTIONS* -- but that is not the cause. And why the intercession of "make" should matter, I cannot say.
I believe that was fixed by the commit immediately after 3.1.7.17, namely 33a2560f8589ae5b436f0fc26a75591cf2edcc60, no?
I could create a branch off of e.g. 3.1.7.11 for your testing where I cherry-pick from the current master, throw out irrelevant merges and clean up the history a bit, to make things easier to bisect.
Thanks. I'll work off 3.1.7.18 and see if that works any better.
I don't think it's necessary to do a new branch, for now, at least. I'll keep you posted on how things go.
best, r
-
Elias Pipping -
Faré -
Robert Goldman