Oddities in ECL tests on Linux

[Robert Goldman]

Unfortunately, this patch doesn't seem to work.  Maybe it interferes 
with condition handlers?  At any rate, after I insert it into 
script-support.lisp I now get two *new* test failures in 
package-inferred-system-test.script and 
test-defsystem-depends-on.script.  I get a message that

```
Top level in: #<process TOP-LEVEL>.
ECL unexpectedly landed in the top level prompt. Script aborted.
Using ecl, package-inferred-system-test.script failed
```

...and one like it for the other test.  So there were some failures 
there that were correctly caught before that are no longer.

On 31 Aug 2018, at 13:43, Marius Gerbershagen wrote:

> Yes, the Ubuntu package definitely should be updated to version 16.1.3
> which fixes the issue. But the ECL developers can't run to the
> maintainer of the ECL package of every linux distribution and ask them
> to upgrade their package each time they make a new release. And even 
> if
> they could, the package maintainers probably wouldn't do it, since 
> some
> other package might depend on an older ECL version.
>
> For the moment, the best solution I can offer you for your problem is 
> a
> dirty hack to prevent older ECL versions from entering the interactive 
> REPL:
>
> diff --git a/test/script-support.lisp b/test/script-support.lisp
> index 86b6c1f2..7f72488a 100644
> --- a/test/script-support.lisp
> +++ b/test/script-support.lisp
> @@ -83,6 +83,14 @@ Some constraints:
>    (defun ensure-directories-exist (path)
>      #+genera (fs:create-directories-recursively (pathname path))))
>
> +;; Dirty hack to prevent buggy ECL versions from landing in the top
> level prompt when they shouldn't
> +#+ecl (when (and (string<= (lisp-implementation-version) "16.1.2")
> +                 (not *debug-asdf*))
> +        (setq si:*tpl-prompt-hook*
> +              #'(lambda ()
> +                  (format *error-output* "ECL unexpectedly landed in
> the top level prompt. Script aborted.~%")
> +                  (exit-lisp 1))))
> +
>  ;;; Survival utilities
>  (defun asym (name &optional package errorp)
>    (let* ((pname (or package :asdf))
>
>
> Of course since this is only a workaround to prevent the tests from
> stopping, the tests in which ECL would stop without the workaround 
> will
> fail on ECL versions <= 16.1.2.
>
> Am 31.08.2018 um 17:54 schrieb 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/asdf-devel/attachments/20180831/fe33e29b/attachment.html>