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.
I can reproduce the issue. When running the image, it looks like uiop failed to be included, even though we explicitly depend on it. I believe this is a combination of one or several of the below:
1- The way that ASDF, since 3.3 or so, refuses to read uiop.asd unless it's strictly newer than ASDF 2- The fact that this test configures an empty source-registry to begin with, so it can't load either ASDF or UIOP from source anyway, it seems 3- The fact that this ECL, unlike e.g. MKCL and SBCL, doesn't provide uoip as a linkable "require" module 4- Somehow, bundle's failure by to fall back to loading the entire ASDF when UIOP isn't present alone, yet needed. 5- Somehow, bundle's failure to link to the libasdf.a provided by ecl. 6- The fact that ECL, being linking-based rather than load-based, doesn't preserve ASDF from the builder's image.
All in all, it's probably a bug in bundle.lisp.
THAT SAID, I just recompiled ECL after many months (years?), using ECL (Embeddable Common-Lisp) 16.1.3 (git:ba6e6ddde780c097918673f16c7aba05f354d022) on Linux amd64 Ubuntu, and trying to (require :asdf) (asdf:load-system :asdf) from the command line in the ecl executable would cause the stack to blow up (and eventually segfault if you keep choosing the restart to continue with more stack). On the other hand, I can load the asdf build and test system can create a bootstrap asdf.fas that can be loaded with no problem. SO, I'm not excluding an ECL bug, either. — Obviously, some things are wrong with ECL, too. I still bet there's a bug in ASDF.
Sorry, I have few cycles to spare for Common Lisp these days.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Amateur bureaucrats are often even worse than professional bureaucrats. — John McCarthy
On Thu, Aug 23, 2018 at 4:22 PM Robert Goldman rpgoldman@sift.info wrote:
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.
I don't have time and interest enough to fix this bug — so instead I made a bug report: https://bugs.launchpad.net/asdf/+bug/1789470
If someone wants to step up as an ASDF maintainer, that's one bug that should not be too hard to fix, yet should take you inside the dirty details of ASDF corner cases, and (at least for now) I'm still available to help would-be maintainers understand how to navigate the code.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Perhaps those of us who care about quality programs have not spoken up often enough — `for bad programs to triumph requires only that good programmers remain silent.' I call this passivity the `Silence of the Lambdas.' — hbaker
On Thu, Aug 23, 2018 at 10:40 PM Faré fahree@gmail.com wrote:
I can reproduce the issue. When running the image, it looks like uiop failed to be included, even though we explicitly depend on it. I believe this is a combination of one or several of the below:
1- The way that ASDF, since 3.3 or so, refuses to read uiop.asd unless it's strictly newer than ASDF 2- The fact that this test configures an empty source-registry to begin with, so it can't load either ASDF or UIOP from source anyway, it seems 3- The fact that this ECL, unlike e.g. MKCL and SBCL, doesn't provide uoip as a linkable "require" module 4- Somehow, bundle's failure by to fall back to loading the entire ASDF when UIOP isn't present alone, yet needed. 5- Somehow, bundle's failure to link to the libasdf.a provided by ecl. 6- The fact that ECL, being linking-based rather than load-based, doesn't preserve ASDF from the builder's image.
All in all, it's probably a bug in bundle.lisp.
THAT SAID, I just recompiled ECL after many months (years?), using ECL (Embeddable Common-Lisp) 16.1.3 (git:ba6e6ddde780c097918673f16c7aba05f354d022) on Linux amd64 Ubuntu, and trying to (require :asdf) (asdf:load-system :asdf) from the command line in the ecl executable would cause the stack to blow up (and eventually segfault if you keep choosing the restart to continue with more stack). On the other hand, I can load the asdf build and test system can create a bootstrap asdf.fas that can be loaded with no problem. SO, I'm not excluding an ECL bug, either. — Obviously, some things are wrong with ECL, too. I still bet there's a bug in ASDF.
Sorry, I have few cycles to spare for Common Lisp these days.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Amateur bureaucrats are often even worse than professional bureaucrats. — John McCarthy
On Thu, Aug 23, 2018 at 4:22 PM Robert Goldman rpgoldman@sift.info wrote:
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.
Hi Robert,
Am 23.08.2018 um 22:22 schrieb 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 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")
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)?
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).
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).
Suggestions for debugging would be welcome.
Best regards, 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.
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.
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.
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.
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 beeasily 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 uiopbecause 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; youprobably 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 testfailures (test-program.script and test-require.script).
No test failure is harmless. The test-program.script failureis 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.
On Thu, Aug 30, 2018 at 1:46 PM Marius Gerbershagen marius.gerbershagen@gmail.com wrote:
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 test-program.script test seems to fail to include uiop because of an error in the linkable-system function.
(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")))
Good catch and good fix! At least, it works for me: the test fails without and works with the patch.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The highest goal of computer science is to automate that which can be automated. — Derek L. VerLee
Am 01.09.2018 um 04:36 schrieb Faré:
On Thu, Aug 30, 2018 at 1:46 PM Marius Gerbershagen marius.gerbershagen@gmail.com wrote:
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.
The :sockets module is available for both Windows and Unix platforms in ECL.
Procrastinating at work, I looked and the non-portable module we previously moved from, and it was :serve-events, not :sockets.
I created !104 with the two fixes by Marius: https://gitlab.common-lisp.net/asdf/asdf/merge_requests/104
I think we should release 3.3.3, unless Didier (or someone else) wants to also complete !103.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Time and money spent in helping men to do more for themselves is far better than mere giving. — Henry Ford
-
Faré -
Marius Gerbershagen -
Robert Goldman