Oddities in ECL tests on Linux

Marius Gerbershagen marius.gerbershagen at gmail.com
Sat Sep 1 12:26:02 UTC 2018


The patch works exactly as it should. All it does is to exit the current
process with a return code of 1 if the process lands in the top level
prompt. The tests you mention also failed before on ECL <= 16.1.2, the
difference is just that instead of failing with a nonzero exit code (as
they should), they failed by getting stuck in the top level prompt. As I
already mentioned in the previous discussion, these failures are due to
a bug in ECL, which has already been fixed in the 16.1.3 release.

Am 31.08.2018 um 23:36 schrieb 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.
> 



More information about the asdf-devel mailing list