Discussion:
Oddities in ECL tests on Linux
Robert Goldman
2018-08-23 20:22:26 UTC
Permalink
My Jenkins job is failing to test ECL successfully.  What's interesting
is that it looks like the tests are successful, but the checker is
failing.  Here's what I see in the transcript:

These two expressions fail comparison with EQUAL:
(UIOP/UTILITY:NEST (LISP-INVOCATION/LISP-INVOCATION:INVOKE-LISP :IMPLEMENTATION-TYPE (LISP-INVOCATION/ALLEGRO-VARIANTS:CURRENT-LISP-VARIANT) :CROSS-COMPILE NIL :IMAGE-PATH (UIOP/FILESYSTEM:NATIVE-NAMESTRING ASDF-TEST::IMG) :CONSOLE T :EVAL "(uiop:restore-image :entry-point 'hello:entry-point :lisp-interaction nil)" :RUN-PROGRAM-ARGS '(:OUTPUT :LINES :ERROR-OUTPUT T))) evaluates to ("No restarts available." "" "Top level in: #<process TOP-LEVEL>." "> ")
'("hello, world") evaluates to ("hello, world")


Oddly, when I try to run this at the command line, ECL throws to the
interactive debugger on various signals and I have to restart it, before

make test l=ecl

will terminate successfully.

I think I have seen this before, and it may be that ECL implicitly
assumes that there will be some kind of C compilation tool chain present
that I don't have, but I'm not sure about that.

Suggestions for debugging would be welcom.
Marius Gerbershagen
2018-08-26 17:05:01 UTC
Permalink
Hi Robert,
Post by Robert Goldman
My Jenkins job is failing to test ECL successfully.  What's interesting
is that it looks like the tests are successful, but the checker is
(UIOP/UTILITY:NEST (LISP-INVOCATION/LISP-INVOCATION:INVOKE-LISP :IMPLEMENTATION-TYPE (LISP-INVOCATION/ALLEGRO-VARIANTS:CURRENT-LISP-VARIANT) :CROSS-COMPILE NIL :IMAGE-PATH (UIOP/FILESYSTEM:NATIVE-NAMESTRING ASDF-TEST::IMG) :CONSOLE T :EVAL "(uiop:restore-image :entry-point 'hello:entry-point :lisp-interaction nil)" :RUN-PROGRAM-ARGS '(:OUTPUT :LINES :ERROR-OUTPUT T))) evaluates to ("No restarts available." "" "Top level in: #<process TOP-LEVEL>." "> ")
'("hello, world") evaluates to ("hello, world")
Do you have any more information on your Jenkins job (what it does
differently than a plain run of `make test l=ecl` and how to reproduce
the failure)?
Post by Robert Goldman
Oddly, when I try to run this at the command line, ECL throws to the
interactive debugger on various signals and I have to restart it, before
make test l=ecl
will terminate successfully.
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).
Post by Robert Goldman
I think I have seen this before, and it may be that ECL implicitly
assumes that there will be some kind of C compilation tool chain present
that I don't have, but I'm not sure about that.
Well if you don't have a C compiler installed, ECL can not compile
anything unless you run `(ext:install-bytecodes-compiler)`. However,
asdf already contains a test target for the bytecodes compiler with
`make test l=ecl_bytecodes` (which will unfortunately fail at the moment
unless you apply the fix at
https://gitlab.com/embeddable-common-lisp/ecl/merge_requests/118).
Post by Robert Goldman
Suggestions for debugging would be welcome.
Best regards,
Marius Gerbershagen
Marius Gerbershagen
2018-08-30 17:46:03 UTC
Permalink
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)))
Post by Marius Gerbershagen
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.
Robert Goldman
2018-08-30 17:53:08 UTC
Permalink
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
Post by Marius Gerbershagen
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
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)
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)))
Post by Marius Gerbershagen
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.
Robert Goldman
2018-08-30 19:51:16 UTC
Permalink
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.
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.
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
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
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)
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)))
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.
Robert Goldman
2018-08-31 15:54:54 UTC
Permalink
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.
Post by 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.
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.
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
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
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)
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)))
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.
Robert Goldman
2018-08-31 21:36:15 UTC
Permalink
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.
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
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
(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.
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).
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.
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.
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.
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
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
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)
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)))
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.
Robert Goldman
2018-09-02 23:16:58 UTC
Permalink
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.
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.
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.
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
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
(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.
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).
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.
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.
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.
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
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
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)
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)))
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.
Marius Gerbershagen
2018-09-01 12:17:55 UTC
Permalink
On Thu, Aug 30, 2018 at 1:46 PM Marius Gerbershagen
Post by Marius Gerbershagen
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
IIRC, we used to used to use :sockets, but started using :rt instead
because :sockets was not available on Windows. Is there a module that
is available on all platforms?
The :sockets module is available for both Windows and Unix platforms in ECL.
Loading...