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