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 ecl-devel
mailing list