<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">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 <em>new</em> test failures in package-inferred-system-test.script and test-defsystem-depends-on.script. I get a message that </p>
<pre style="background-color:#F7F7F7; border-radius:5px 5px 5px 5px; margin-left:15px; margin-right:15px; max-width:90vw; overflow-x:auto; padding:5px" bgcolor="#F7F7F7"><code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0" bgcolor="#F7F7F7">Top level in: #<process TOP-LEVEL>.
ECL unexpectedly landed in the top level prompt. Script aborted.
Using ecl, package-inferred-system-test.script failed
</code></pre>
<p dir="auto">...and one like it for the other test. So there were some failures there that were correctly caught before that are no longer.</p>
<p dir="auto">On 31 Aug 2018, at 13:43, Marius Gerbershagen wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Yes, the Ubuntu package definitely should be updated to version 16.1.3<br>
which fixes the issue. But the ECL developers can't run to the<br>
maintainer of the ECL package of every linux distribution and ask them<br>
to upgrade their package each time they make a new release. And even if<br>
they could, the package maintainers probably wouldn't do it, since some<br>
other package might depend on an older ECL version.<br>
<br>
For the moment, the best solution I can offer you for your problem is a<br>
dirty hack to prevent older ECL versions from entering the interactive REPL:<br>
<br>
diff --git a/test/script-support.lisp b/test/script-support.lisp<br>
index 86b6c1f2..7f72488a 100644<br>
--- a/test/script-support.lisp<br>
+++ b/test/script-support.lisp<br>
@@ -83,6 +83,14 @@ Some constraints:<br>
(defun ensure-directories-exist (path)<br>
#+genera (fs:create-directories-recursively (pathname path))))<br>
<br>
+;; Dirty hack to prevent buggy ECL versions from landing in the top<br>
level prompt when they shouldn't<br>
+#+ecl (when (and (string<= (lisp-implementation-version) "16.1.2")<br>
+ (not *debug-asdf*))<br>
+ (setq si:*tpl-prompt-hook*<br>
+ #'(lambda ()<br>
+ (format *error-output* "ECL unexpectedly landed in<br>
the top level prompt. Script aborted.~%")<br>
+ (exit-lisp 1))))<br>
+<br>
;;; Survival utilities<br>
(defun asym (name &optional package errorp)<br>
(let* ((pname (or package :asdf))<br>
<br>
<br>
Of course since this is only a workaround to prevent the tests from<br>
stopping, the tests in which ECL would stop without the workaround will<br>
fail on ECL versions <= 16.1.2.<br>
<br>
Am 31.08.2018 um 17:54 schrieb Robert Goldman:</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">On 31 Aug 2018, at 10:35, Marius Gerbershagen wrote:<br>
<br>
This is most likely a bug in ECL. I recommend trying out a newer version<br>
of ecl (16.1.3 or the current develop branch from the git repository).<br>
<br>
I see your point, but have two comments:<br>
<br>
1.<br>
<br>
If this really /is/ an ECL bug, then shouldn't the Ubuntu package be<br>
updated and fixed? ASDF is supposed to work on the ECL that users<br>
will have, not only on the one that developers have.<br>
<br>
2.<br>
<br>
I don't see a way to get a new ECL except by pulling from Gitlab and<br>
building. I do not have the time to run around building all<br>
available lisp implementations from source (and, again, ASDF should<br>
work on the versions of the implementations that users actually<br>
have, which means the ones provided by the packaging systems on the<br>
platforms). I build only SBCL, because that's an implementation I<br>
build anyway, for my work needs. Faré had the energy to play with<br>
all the different implementations in a substantial way, but I do not.<br>
<br>
So if the released version of an implementation is broken, I will simply<br>
regard that implementation as broken. If the /released version/ of an<br>
implementation is broken for long enough (I'm looking at you, clisp), it<br>
will become unsupported by ASDF. Unsupported means "patches will be<br>
accepted, but I will no longer run the tests, and test failure on an<br>
unsupported implementation will not be a reason to hold up an ASDF release."<br>
<br>
Note that at the moment /all/ implementations are essentially<br>
unsupported on Windows, since I have lost my Windows VM, and even if I<br>
got it back, I would have no way to develop on Windows. If you are a<br>
Windows user and this bothers you, I would be happy to support you in<br>
setting up a test environment, and even more happy to help you learn to<br>
patch ASDF. But even someone who doesn't want to patch ASDF, but who<br>
would be willing to run the test suite (or help figure out how it could<br>
be run through, e.g., Travis), would be a great help.<br>
<br>
Am 30.08.2018 um 21:51 schrieb Robert Goldman:<br>
<br>
I'm experimenting with your changes now but, for some reason that I<br>
don't understand, when I run the tests as |make l=ecl|<br>
interactively on<br>
Ubuntu (using the Ubuntu ECL package |16.1.2-3|), signals are<br>
throwing<br>
me into the interactive debugger, instead of being caught. I have no<br>
idea why this started happening, because I used to be able to<br>
run ECL<br>
successfully, and I don't believe I have changed the package<br>
(although<br>
Ubuntu might have upgraded it).<br>
<br>
Actually /usr/bin/ecl is crashing with SIGABRT when running<br>
programs,<br>
apparently, on my Ubuntu box. (|SIGABRT in si_run_program()|).<br>
I'll try<br>
uninstalling and reinstalling ECL in the hopes that fixes this, but<br>
unless I get some help, I will not be able to continue testing<br>
ASDF on<br>
ECL on Linux.<br>
<br>
On 30 Aug 2018, at 13:22, Marius Gerbershagen wrote:<br>
<br>
No, I don't think so. The sockets module has been part of ECL since<br>
version 0.9f from 2005. Please note, that this test can fail<br>
anyway if<br>
ECL is built without support for the respective module (be it :rt or<br>
:sockets). The change only prevents it from failing on a default<br>
build<br>
configuration.<br>
<br>
Am 30.08.2018 um 19:53 schrieb Robert Goldman:<br>
<br>
Thank you very much for these, Marius. I will look into fixing them<br>
directly. One question - do I need to check for ECL version<br>
number when<br>
requiring sockets in the test? I.e., to I need to test with |:rt| in<br>
older versions and |:sockets| in newer? Or will |:sockets| work<br>
in older<br>
versions of ECL, as well?<br>
<br>
Best,<br>
R<br>
<br>
On 30 Aug 2018, at 12:46, Marius Gerbershagen wrote:<br>
<br>
Harmless in the sense that ECL doesn't crash or throw me in the<br>
interactive debugger. Besides, the test failures seem to be easily<br>
fixed. The test-require.script test fails because it tries to<br>
require<br>
the :rt module which is deprecated on the develop branch and no<br>
longer<br>
build by default. A simple fix is to use the :sockets module<br>
instead:<br>
<br>
diff --git a/test/test-require.script b/test/test-require.script<br>
index e5f70857..1ef84e8c 100644<br>
--- a/test/test-require.script<br>
+++ b/test/test-require.script<br>
@@ -178,7 +178,7 @@<br>
#+allegro :sax<br>
#+clisp (first (remove "asdf" *dynmod-list* :test 'equal))<br>
#+(or clozure cmucl) :defsystem<br>
- #+ecl :rt ;; loads faster than :ecl-quicklisp<br>
+ #+ecl :sockets<br>
#+lispworks "comm"<br>
#+mkcl :walker<br>
#+sbcl :sb-md5<br>
<br>
The test-program.script test seems to fail to include uiop<br>
because of an<br>
error in the linkable-system function. Tracing it shows that the<br>
function returns nil for the uiop system object,<br>
1> (ASDF/BUNDLE::LINKABLE-SYSTEM #<system "uiop">)<br>
<1 (ASDF/BUNDLE::LINKABLE-SYSTEM NIL)<br>
which seems to be caused by a missing call to coerce-name:<br>
<br>
diff --git a/bundle.lisp b/bundle.lisp<br>
index 2ff56f93..42034c9f 100644<br>
--- a/bundle.lisp<br>
+++ b/bundle.lisp<br>
@@ -529,7 +529,7 @@ which is probably not what you want; you<br>
probably<br>
need to tweak your output tran<br>
;; If an ASDF upgrade is available from source, but not a UIOP<br>
upgrade to that,<br>
;; then use the asdf/driver system instead of<br>
;; the UIOP that was disabled by check-not-old-asdf-system.<br>
- (if-let (s (and (equal x "uiop") (output-files 'lib-op "asdf")<br>
(find-system "asdf/driver")))<br>
+ (if-let (s (and (equal (coerce-name x) "uiop") (output-files<br>
'lib-op "asdf") (find-system "asdf/driver")))<br>
(and (output-files 'lib-op s) s))<br>
;; If there was no source upgrade, look for modules provided by<br>
the implementation.<br>
(if-let (p (system-module-pathname (coerce-name x)))<br>
<br>
<br>
Am 29.08.2018 um 01:22 schrieb Faré:<br>
<br>
I can't reproduce this, for me the tests run fine without<br>
being thrown<br>
in the debugger. I only get two harmlessly looking test failures<br>
(test-program.script and test-require.script).<br>
<br>
No test failure is harmless. The test-program.script failure is what<br>
Robert saw, that I can reproduce. I didn't reproduce a failure with<br>
test-require. I had more problems with ECL from the develop branch,<br>
but maybe it was a bad idea to use the develop branch.<br>
<br>
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•<br>
<a href="http://fare.tunes.org" style="color:#999">http://fare.tunes.org</a><br>
There are two kinds of people, those who do the work<br>
and those who take the credit. Try to be in the first group;<br>
there is less competition there<br>
— Indira Gandhi.<br>
</p>
</blockquote></blockquote></div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>