Oddities in ECL tests on Linux

[Faré]

I don't have time and interest enough to fix this bug ­— so instead I
made a bug report:
https://bugs.launchpad.net/asdf/+bug/1789470

If someone wants to step up as an ASDF maintainer, that's one bug that
should not be too hard to fix, yet should take you inside the dirty
details of ASDF corner cases, and (at least for now) I'm still
available to help would-be maintainers understand how to navigate the
code.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Perhaps those of us who care about quality programs have not spoken up often
enough — `for bad programs to triumph requires only that good programmers
remain silent.' I call this passivity the `Silence of the Lambdas.' — hbaker


On Thu, Aug 23, 2018 at 10:40 PM Faré <fahree at gmail.com> wrote:
>
> I can reproduce the issue. When running the image, it looks like uiop
> failed to be included, even though we explicitly depend on it. I
> believe this is a combination of one or several of the below:
>
> 1- The way that ASDF, since 3.3 or so, refuses to read uiop.asd unless
> it's strictly newer than ASDF
> 2- The fact that this test configures an empty source-registry to
> begin with, so it can't load either ASDF or UIOP from source anyway,
> it seems
> 3- The fact that this ECL, unlike e.g. MKCL and SBCL, doesn't provide
> uoip as a linkable "require" module
> 4- Somehow, bundle's failure by to fall back to loading the entire
> ASDF when UIOP isn't present alone, yet needed.
> 5- Somehow, bundle's failure to link to the libasdf.a provided by ecl.
> 6- The fact that ECL, being linking-based rather than load-based,
> doesn't preserve ASDF from the builder's image.
>
> All in all, it's probably a bug in bundle.lisp.
>
> THAT SAID, I just recompiled ECL after many months (years?), using ECL
> (Embeddable Common-Lisp) 16.1.3
> (git:ba6e6ddde780c097918673f16c7aba05f354d022) on Linux amd64 Ubuntu,
> and trying to (require :asdf) (asdf:load-system :asdf) from the
> command line in the ecl executable would cause the stack to blow up
> (and eventually segfault if you keep choosing the restart to continue
> with more stack). On the other hand, I can load the asdf build and
> test system can create a bootstrap asdf.fas that can be loaded with no
> problem. SO, I'm not excluding an ECL bug, either. — Obviously, some
> things are wrong with ECL, too. I still bet there's a bug in ASDF.
>
> Sorry, I have few cycles to spare for Common Lisp these days.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> Amateur bureaucrats are often even worse than professional bureaucrats.
>         — John McCarthy
>
>
> On Thu, Aug 23, 2018 at 4:22 PM Robert Goldman <rpgoldman at sift.info> wrote:
> >
> > My Jenkins job is failing to test ECL successfully.  What's interesting
> > is that it looks like the tests are successful, but the checker is
> > failing.  Here's what I see in the transcript:
> >
> > These two expressions fail comparison with EQUAL:
> >  (UIOP/UTILITY:NEST (LISP-INVOCATION/LISP-INVOCATION:INVOKE-LISP :IMPLEMENTATION-TYPE (LISP-INVOCATION/ALLEGRO-VARIANTS:CURRENT-LISP-VARIANT) :CROSS-COMPILE NIL :IMAGE-PATH (UIOP/FILESYSTEM:NATIVE-NAMESTRING ASDF-TEST::IMG) :CONSOLE T :EVAL "(uiop:restore-image :entry-point 'hello:entry-point :lisp-interaction nil)" :RUN-PROGRAM-ARGS '(:OUTPUT :LINES :ERROR-OUTPUT T))) evaluates to ("No restarts available." "" "Top level in: #<process TOP-LEVEL>." "> ")
> >  '("hello, world") evaluates to ("hello, world")
> >
> >
> > Oddly, when I try to run this at the command line, ECL throws to the
> > interactive debugger on various signals and I have to restart it, before
> >
> > make test l=ecl
> >
> > will terminate successfully.
> >
> > I think I have seen this before, and it may be that ECL implicitly
> > assumes that there will be some kind of C compilation tool chain present
> > that I don't have, but I'm not sure about that.
> >
> > Suggestions for debugging would be welcom.
> >
> >
> >