Windows problems: moratorium continues

[Robert Goldman]

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 at sift.net
> <mailto:rpgoldman at 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
> 
>