Oddities in ECL tests on Linux
Robert Goldman
rpgoldman at sift.info
Sun Sep 2 23:16:58 UTC 2018
OK, that makes sense. These tests were passing for me on the Mac, but
brew has ECL 16.1.3 instead of 16.1.2.
On 1 Sep 2018, at 7:26, Marius Gerbershagen wrote:
> 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