Oddities in ECL tests on Linux

[Robert Goldman]

On 31 Aug 2018, at 10:35, Marius Gerbershagen wrote:

> This is most likely a bug in ECL. I recommend trying out a newer 
> version
> of ecl (16.1.3 or the current develop branch from the git repository).

I see your point, but have two comments:

1. If this really *is* an ECL bug, then shouldn't the Ubuntu package be 
updated and fixed?  ASDF is supposed to work on the ECL that users will 
have, not only on the one that developers have.

2. I don't see a way to get a new ECL except by pulling from Gitlab and 
building.  I do not have the time to run around  building all available 
lisp implementations from source (and, again, ASDF should work on the 
versions of the implementations that users actually have, which means 
the ones provided by the packaging systems on the platforms).  I build 
only SBCL, because that's an implementation I build anyway, for my work 
needs.  Faré had the energy to play with all the different 
implementations in a substantial way, but I do not.

So if the released version of an implementation is broken, I will simply 
regard that implementation as broken.  If the *released version* of an 
implementation is broken for long enough (I'm looking at you, clisp), it 
will become unsupported by ASDF.  Unsupported means "patches will be 
accepted, but I will no longer run the tests, and test failure on an 
unsupported implementation will not be a reason to hold up an ASDF 
release."

Note that at the moment *all* implementations are essentially 
unsupported on Windows, since I have lost my Windows VM, and even if I 
got it back, I would have no way to develop on Windows.  If you are a 
Windows user and this bothers you, I would be happy to support you in 
setting up a test environment, and even more happy to help you learn to 
patch ASDF.  But even someone who doesn't want to patch ASDF, but who 
would be willing to run the test suite (or help figure out how it could 
be run through, e.g., Travis), would be a great help.


>
> Am 30.08.2018 um 21:51 schrieb Robert Goldman:
>> I'm experimenting with your changes now but, for some reason that I
>> don't understand, when I run the tests as |make l=ecl| interactively 
>> on
>> Ubuntu (using the Ubuntu ECL package |16.1.2-3|), signals are 
>> throwing
>> me into the interactive debugger, instead of being caught. I have no
>> idea why this started happening, because I used to be able to run ECL
>> successfully, and I don't believe I have changed the package 
>> (although
>> Ubuntu might have upgraded it).
>>
>> Actually /usr/bin/ecl is crashing with SIGABRT when running programs,
>> apparently, on my Ubuntu box. (|SIGABRT in si_run_program()|). I'll 
>> try
>> uninstalling and reinstalling ECL in the hopes that fixes this, but
>> unless I get some help, I will not be able to continue testing ASDF 
>> on
>> ECL on Linux.
>>
>> On 30 Aug 2018, at 13:22, Marius Gerbershagen wrote:
>>
>>     No, I don't think so. The sockets module has been part of ECL 
>> since
>>     version 0.9f from 2005. Please note, that this test can fail 
>> anyway if
>>     ECL is built without support for the respective module (be it :rt 
>> or
>>     :sockets). The change only prevents it from failing on a default 
>> build
>>     configuration.
>>
>>     Am 30.08.2018 um 19:53 schrieb Robert Goldman:
>>
>>         Thank you very much for these, Marius. I will look into 
>> fixing them
>>         directly. One question - do I need to check for ECL version
>>         number when
>>         requiring sockets in the test? I.e., to I need to test with 
>> |:rt| in
>>         older versions and |:sockets| in newer? Or will |:sockets| 
>> work
>>         in older
>>         versions of ECL, as well?
>>
>>         Best,
>>         R
>>
>>         On 30 Aug 2018, at 12:46, Marius Gerbershagen wrote:
>>
>>         Harmless in the sense that ECL doesn't crash or throw me in 
>> the
>>         interactive debugger. Besides, the test failures seem to be 
>> easily
>>         fixed. The test-require.script test fails because it tries to
>>         require
>>         the :rt module which is deprecated on the develop branch and 
>> no
>>         longer
>>         build by default. A simple fix is to use the :sockets module
>>         instead:
>>
>>         diff --git a/test/test-require.script 
>> b/test/test-require.script
>>         index e5f70857..1ef84e8c 100644
>>         --- a/test/test-require.script
>>         +++ b/test/test-require.script
>>         @@ -178,7 +178,7 @@
>>         #+allegro :sax
>>         #+clisp (first (remove "asdf" *dynmod-list* :test 'equal))
>>         #+(or clozure cmucl) :defsystem
>>         - #+ecl :rt ;; loads faster than :ecl-quicklisp
>>         + #+ecl :sockets
>>         #+lispworks "comm"
>>         #+mkcl :walker
>>         #+sbcl :sb-md5
>>
>>         The test-program.script test seems to fail to include uiop
>>         because of an
>>         error in the linkable-system function. Tracing it shows that 
>> the
>>         function returns nil for the uiop system object,
>>         1> (ASDF/BUNDLE::LINKABLE-SYSTEM #<system "uiop">)
>>         <1 (ASDF/BUNDLE::LINKABLE-SYSTEM NIL)
>>         which seems to be caused by a missing call to coerce-name:
>>
>>         diff --git a/bundle.lisp b/bundle.lisp
>>         index 2ff56f93..42034c9f 100644
>>         --- a/bundle.lisp
>>         +++ b/bundle.lisp
>>         @@ -529,7 +529,7 @@ which is probably not what you want; you
>>         probably
>>         need to tweak your output tran
>>         ;; If an ASDF upgrade is available from source, but not a 
>> UIOP
>>         upgrade to that,
>>         ;; then use the asdf/driver system instead of
>>         ;; the UIOP that was disabled by check-not-old-asdf-system.
>>         - (if-let (s (and (equal x "uiop") (output-files 'lib-op 
>> "asdf")
>>         (find-system "asdf/driver")))
>>         + (if-let (s (and (equal (coerce-name x) "uiop") 
>> (output-files
>>         'lib-op "asdf") (find-system "asdf/driver")))
>>         (and (output-files 'lib-op s) s))
>>         ;; If there was no source upgrade, look for modules provided 
>> by
>>         the implementation.
>>         (if-let (p (system-module-pathname (coerce-name x)))
>>
>>
>>         Am 29.08.2018 um 01:22 schrieb Faré:
>>
>>         I can't reproduce this, for me the tests run fine without
>>         being thrown
>>         in the debugger. I only get two harmlessly looking test 
>> failures
>>         (test-program.script and test-require.script).
>>
>>         No test failure is harmless. The test-program.script failure 
>> is what
>>         Robert saw, that I can reproduce. I didn't reproduce a 
>> failure with
>>         test-require. I had more problems with ECL from the develop 
>> branch,
>>         but maybe it was a bad idea to use the develop branch.
>>
>>         —♯ƒ • François-René ÐVB Rideau 
>> •Reflection&Cybernethics•
>>         http://fare.tunes.org
>>         There are two kinds of people, those who do the work
>>         and those who take the credit. Try to be in the first group;
>>         there is less competition there
>>         — Indira Gandhi.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20180831/c5f5fd4c/attachment.html>