Re: Oddities in ECL tests on Linux

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.
>>