Windows problems: moratorium continues

[Elias Pipping]

> On 14 Sep 2016, at 16:00, Robert Goldman <rpgoldman at 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