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 <rpgold...@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 <rpgold...@sift.net
> > <mailto:rpgold...@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
> >
> >
>
>
