Re: Oddities in ECL tests on Linux

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