Windows problems: moratorium continues

[Faré]

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 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'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
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20160914/da89ae3d/attachment.html>