<p dir="ltr">Sorry, it's my bad for checking in bad code in master (that I fixed later on, but too late).</p>
<p dir="ltr">What's failing at head on which implementations, already? Can you publish logs?</p>
<p dir="ltr">It's so annoying that there isn't a free-as-in-beer reputable non-malware test image of Windows to use for testing.</p>
<p dir="ltr">-#f</p>
<br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 14, 2016, 09:59 Robert Goldman <<a href="mailto:rpgoldman@sift.net">rpgoldman@sift.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 9/14/16 Sep 14 -6:14 AM, Faré wrote:<br>
> I don't know whether that would help on Windows, but I have a fix for<br>
> the require-system function that hopefully makes test-force stable, in<br>
> !16 on gitlab.<br>
<br>
Mostly I'm working my way back through history, then forward.<br>
<br>
3.1.7.16 was broken because of the typo.<br>
3.1.7.17 has the typo fixed, but fails test-clean-load on ecl_bytecodes.<br>
 I believe that this is spurious, though.  It's crashing on the code<br>
that hooks into REQUIRE, and it crashes only when run as<br>
<br>
make test-clean-load l=ecl_bytecodes<br>
<br>
and NOT when run as<br>
<br>
run-tests.sh -c ecl_bytecodes<br>
<br>
Here's the error:<br>
<br>
An error occurred during initialization:<br>
In form<br>
(PROGN<br>
 (PUSHNEW '("fasb" . SI:LOAD-BINARY) *LOAD-HOOKS* :TEST 'EQUAL :KEY 'CAR)<br>
 (UNLESS (ASSOC "asd" *LOAD-HOOKS* :TEST 'EQUAL)<br>
   (APPENDF *LOAD-HOOKS* '(("asd" . SI:LOAD-SOURCE))))<br>
 (DEFVAR *WRAPPED-MODULE-PROVIDER* (MAKE-HASH-TABLE))<br>
 (SETF (GETHASH 'MODULE-PROVIDE-ASDF *WRAPPED-MODULE-PROVIDER*)<br>
         'MODULE-PROVIDE-ASDF)<br>
 (DEFUN WRAP-MODULE-PROVIDER (PROVIDER NAME)<br>
   (LET ((RESULTS (MULTIPLE-VALUE-LIST (FUNCALL PROVIDER NAME))))<br>
     (WHEN (FIRST RESULTS) (REGISTER-PRELOADED-SYSTEM (COERCE-NAME NAME)))<br>
     (VALUES-LIST RESULTS)))<br>
 (SETF *MODULE-PROVIDER-FUNCTIONS*<br>
         (LOOP :FOR<br>
               PROVIDER<br>
               :IN<br>
               *MODULE-PROVIDER-FUNCTIONS*<br>
               :COLLECT<br>
               (ENSURE-GETHASH PROVIDER<br>
                               *WRAPPED-MODULE-PROVIDER*<br>
                               #'(LAMBDA (MODULE-NAME)<br>
                                   (WRAP-MODULE-PROVIDER PROVIDER<br>
                                                         MODULE-NAME))))))<br>
Wrong number of arguments passed to function NIL..<br>
<br>
I have checked what I thought was the obvious hypothesis: a NIL in<br>
*MODULE-PROVIDER-FUNCTIONS* -- but that is not the cause.  And why the<br>
intercession of "make" should matter, I cannot say.<br>
<br>
I'm just not sure if there's any version that passes the tests on<br>
Windows since 16 August 2016.<br>
<br>
I'll have another look, but may have to give up the bisect strategy and<br>
just try to fix the head.  This is obviously deeply undesirable.  But<br>
bisect assumes that I can detect the interesting failures in a<br>
hill-climbing way, whereas here we have multiple points at which<br>
breakage has been introduced.<br>
<br>
Unfortunately, unlike on Mac and Linux, I have absolutely no clue how to<br>
automate Windows testing, which leads to these messes, which are<br>
precisely what continuous integration is supposed to avoid.<br>
<br>
best,<br>
r<br>
<br>
><br>
><br>
> On Tue, Sep 13, 2016, 23:05 Robert Goldman <<a href="mailto:rpgoldman@sift.net" target="_blank">rpgoldman@sift.net</a><br>
> <mailto:<a href="mailto:rpgoldman@sift.net" target="_blank">rpgoldman@sift.net</a>>> wrote:<br>
><br>
>     Unfortunately, the last time I was able to run the Windows tests before<br>
>     2 days ago was in mid-August.  Since then, there have been a flurry of<br>
>     commits, many of which could have impacted the state of<br>
>     test-force.script.<br>
><br>
>     Indeed, test-force.script *itself* has changed, so that, although we<br>
>     call it a "regression test," we have no reason to believe that it *ever*<br>
>     worked on Windows in its present form.<br>
><br>
>     Unfortunately, it may take me a while to get enough bisecting done to<br>
>     figure out when we jumped the rails.  I'll keep everyone posted, but in<br>
>     the meantime, we should consider the repo locked against more changes.<br>
>     Windows is badly broken, and we shouldn't be trying to move forward<br>
>     again until we have restored function on this platform.<br>
><br>
>     thanks,<br>
>     r<br>
><br>
><br>
<br>
</blockquote></div>