Dear Jean-Claude,
ASDF 3.3 (the "plan" branch) is failing miserably on MKCL, because it signals a non-serious condition (that is only handled in some contexts) as a way to detect out-of-date .asd files. All other CL implementations know to ignore such conditions when they are not handled. But instead MKCL borks with error messages such as:
Unhandled condition signaled during command line arguments processing: system test-asdf is out of date.
I believe it's a bug in MKCL, maybe specifically in command line processing. Can you fix it?
Should I add some backward compatibility for older versions of MKCL, or is it superfluous?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "Wherever you go, there you are!" Dual: "Wherever you are, thence you go." Beats "I'll start exercising as soon as I'm into shape."
Hello Faré,
On Thu, Jul 20, 2017 at 9:06 PM, Faré fahree@gmail.com wrote:
Dear Jean-Claude,
ASDF 3.3 (the "plan" branch) is failing miserably on MKCL, because it signals a non-serious condition (that is only handled in some contexts) as a way to detect out-of-date .asd files. All other CL implementations know to ignore such conditions when they are not handled. But instead MKCL borks with error messages such as:
Unhandled condition signaled during command line arguments processing: system test-asdf is out of date.
Looking at the most probable source of this message (in src/lsp/cmdline.lsp) I am a bit puzzled by the situation...
Please, reassure me on the exact version of MKCL you're using: 1.1.10-???
And how do you invoke MKCL to get this result (command line arguments)? Do you have handy a small scenario to reproduce this problem?
I believe it's a bug in MKCL, maybe specifically in command line processing. Can you fix it?
Looks more like a ill-advised feature than a bug, that I can surely fix/improve to better satisfaction. I am investigating...
Should I add some backward compatibility for older versions of MKCL, or is it superfluous?
Not sure yet. I'll tell you with the fix.
On Thu, Jul 20, 2017 at 10:23 PM, Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com wrote:
Looking at the most probable source of this message (in src/lsp/cmdline.lsp) I am a bit puzzled by the situation...
Please, reassure me on the exact version of MKCL you're using: 1.1.10-???
MKCL 1.1.10.14-16ceee1
And how do you invoke MKCL to get this result (command line arguments)?
Using the "plan" branch on https://gitlab.common-lisp.net/asdf/asdf cd .../asdf make t l=mkcl
Do you have handy a small scenario to reproduce this problem?
mkcl -eval "(progn (define-condition foo (condition) ()) (signal 'foo))"
NB: at the REPL, this form correctly evaluates to NIL without an error.
I believe it's a bug in MKCL, maybe specifically in command line processing. Can you fix it?
Looks more like a ill-advised feature than a bug, that I can surely fix/improve to better satisfaction. I am investigating...
Definitely a bug. Only serious-condition's should cause mkcl to abort if unhandled.
Should I add some backward compatibility for older versions of MKCL, or is it superfluous?
Not sure yet. I'll tell you with the fix.
—♯ƒ • 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 Fri, Jul 21, 2017 at 3:00 AM, Faré fahree@gmail.com wrote:
On Thu, Jul 20, 2017 at 10:23 PM, Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com wrote: (...)
I believe it's a bug in MKCL, maybe specifically in command line processing. Can you fix it?
Looks more like a ill-advised feature than a bug, that I can surely fix/improve to better satisfaction. I am investigating...
Definitely a bug. Only serious-condition's should cause mkcl to abort if unhandled.
The fix I intend for this bug is currently on MKCL's github repo master head. Please give it a try.
Should I add some backward compatibility for older versions of MKCL, or is it superfluous?
Not sure yet. I'll tell you with the fix.
I don't see what could be done at a reasonable cost, so I would simply let it go and point the latest and greatest to whoever stumbles on this.
—♯ƒ • 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
Probably your best footer quote ever!
On Sun, Jul 23, 2017 at 3:07 AM, Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com wrote:
The fix I intend for this bug is currently on MKCL's github repo master head. Please give it a try.
Works for me. There are now only 4 ASDF failures instead of 67/67 in the "plan" branch, and they are probably my bad. I'll investigate.
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
Probably your best footer quote ever!
I'm glad you liked it. I have many others, including by the same author.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org [A] Computer [programming] language is inherently a pun — [it] needs to be interpreted by both men & machines. — Henry Baker
After update now I see 4 failures also:
test-bundle.script test-defsystem-depends-on-phase-overlap.script test-program.script test3.script
[as an aside, we should probably re-title test3.script to make it more clear what it is that it is intended to test.]
test-bundle seems like it might be an mkcl build process issue. The error I see for this is:
Test the pre-compiled system feature TEST ABORTED: Module error: Error while loading module SOCKETS: system sockets is out of date
After a clean build of mkcl I see this:
$ find /usr/local/lib/mkcl-1.1.10/contrib/ -iname 'sockets*' -exec ls -l {} ; -rw-r--r-- 1 root root 57 Jul 23 11:35 /usr/local/lib/mkcl-1.1.10/contrib/sockets.as2 -rw-r--r-- 1 root root 941964 Jun 20 15:18 /usr/local/lib/mkcl-1.1.10/contrib/sockets.a -rw-r--r-- 1 root root 229708 Jul 23 11:35 /usr/local/lib/mkcl-1.1.10/contrib/SOCKETS.a -rw-r--r-- 1 root root 194 Jul 23 11:35 /usr/local/lib/mkcl-1.1.10/contrib/sockets.asd -rwxr-xr-x 1 root root 628800 Jun 20 15:18 /usr/local/lib/mkcl-1.1.10/contrib/sockets.fasb -rwxr-xr-x 1 root root 184872 Jul 23 11:35 /usr/local/lib/mkcl-1.1.10/contrib/SOCKETS.fasb
Is there any chance the old, lower-cased files are causing my problem here? Or is it the upcased ones?
Here's the date of the asd file:
-rw-r--r-- 1 root root 194 Jul 23 11:56 /usr/local/lib/mkcl-1.1.10/contrib/sockets.asd
Looks newer than the corresponding library files.
For the phase overlap test, I believe the following is the proximate error:
6: (#<bytecompiled-function SI:BYTECODE> ((#:G-31773-1570) (#:G-31773-1569 . ASDF/INTERFACE::MY-CL-SOURCE-FILE)))
I believe that this is returning NIL. But this may be a symptom, not a root cause.
test-program is having the same test failure we see on ECL:
TEST ABORTED: These two expressions fail comparison with EQUAL: (RUN-PROGRAM (SI:QUASIQUOTE ((SI:UNQUOTE (NATIVE-NAMESTRING (OUTPUT-FILE 'PROGRAM-OP 'HELLO-NO-UIOP))))) :OUTPUT :LINES :ERROR-OUTPUT T) evaluates to ("Look ma, no UIOP!" "But no TEST-PACKAGE :-(!" "And no ASDF!") '("Look ma, no UIOP!" "And TEST-PACKAGE!" "And no ASDF!") evaluates to ("Look ma, no UIOP!"
"And TEST-PACKAGE!"
"And no ASDF!")
...and test3 looks like it has the same problem as the phase overlap test.
Cheers, r
On 7/23/17 Jul 23 -10:06 AM, Faré wrote:
On Sun, Jul 23, 2017 at 3:07 AM, Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com wrote:
The fix I intend for this bug is currently on MKCL's github repo master head. Please give it a try.
Works for me. There are now only 4 ASDF failures instead of 67/67 in the "plan" branch, and they are probably my bad. I'll investigate.
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
Probably your best footer quote ever!
I'm glad you liked it. I have many others, including by the same author.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org [A] Computer [programming] language is inherently a pun — [it] needs to be interpreted by both men & machines. — Henry Baker
Regarding these ASDF failures on MKCL: * test-program was a bug in my latest ASDF tweaks, now fixes. * test-bundle and test3 smell like another case where MKCL errors out due to non-serious conditions being signalled, this time inside a require. * test-defsystem-depends-on-phase-overlap.script is because said test tries to undefine a class using (setf (find-class 'asdf::my-cl-source-file) nil) and MKCL disapproves, unlike all other tested CL implementations, erroring with: "TEST ABORTED: NIL is not of type SI:INSTANCE." Is that a compliant way to undefine a class? If not, is there one and what is it?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If you could ask a unique question to a computer during a Turing test, what would you ask? — Douglas Hofstadter, Metamagical Themas
On Sun, Jul 23, 2017 at 1:03 PM, Robert Goldman rpgoldman@sift.net wrote:
After update now I see 4 failures also:
test-bundle.script test-defsystem-depends-on-phase-overlap.script test-program.script test3.script
[as an aside, we should probably re-title test3.script to make it more clear what it is that it is intended to test.]
test-bundle seems like it might be an mkcl build process issue. The error I see for this is:
Test the pre-compiled system feature TEST ABORTED: Module error: Error while loading module SOCKETS: system sockets is out of date
After a clean build of mkcl I see this:
$ find /usr/local/lib/mkcl-1.1.10/contrib/ -iname 'sockets*' -exec ls -l {} ; -rw-r--r-- 1 root root 57 Jul 23 11:35 /usr/local/lib/mkcl-1.1.10/contrib/sockets.as2 -rw-r--r-- 1 root root 941964 Jun 20 15:18 /usr/local/lib/mkcl-1.1.10/contrib/sockets.a -rw-r--r-- 1 root root 229708 Jul 23 11:35 /usr/local/lib/mkcl-1.1.10/contrib/SOCKETS.a -rw-r--r-- 1 root root 194 Jul 23 11:35 /usr/local/lib/mkcl-1.1.10/contrib/sockets.asd -rwxr-xr-x 1 root root 628800 Jun 20 15:18 /usr/local/lib/mkcl-1.1.10/contrib/sockets.fasb -rwxr-xr-x 1 root root 184872 Jul 23 11:35 /usr/local/lib/mkcl-1.1.10/contrib/SOCKETS.fasb
Is there any chance the old, lower-cased files are causing my problem here? Or is it the upcased ones?
Here's the date of the asd file:
-rw-r--r-- 1 root root 194 Jul 23 11:56 /usr/local/lib/mkcl-1.1.10/contrib/sockets.asd
Looks newer than the corresponding library files.
For the phase overlap test, I believe the following is the proximate error:
6: (#<bytecompiled-function SI:BYTECODE> ((#:G-31773-1570) (#:G-31773-1569 . ASDF/INTERFACE::MY-CL-SOURCE-FILE)))
I believe that this is returning NIL. But this may be a symptom, not a root cause.
test-program is having the same test failure we see on ECL:
TEST ABORTED: These two expressions fail comparison with EQUAL: (RUN-PROGRAM (SI:QUASIQUOTE ((SI:UNQUOTE (NATIVE-NAMESTRING (OUTPUT-FILE 'PROGRAM-OP 'HELLO-NO-UIOP))))) :OUTPUT :LINES :ERROR-OUTPUT T) evaluates to ("Look ma, no UIOP!" "But no TEST-PACKAGE :-(!" "And no ASDF!") '("Look ma, no UIOP!" "And TEST-PACKAGE!" "And no ASDF!") evaluates to ("Look ma, no UIOP!"
"And TEST-PACKAGE!"
"And no ASDF!")
...and test3 looks like it has the same problem as the phase overlap test.
Cheers, r
On 7/23/17 Jul 23 -10:06 AM, Faré wrote:
On Sun, Jul 23, 2017 at 3:07 AM, Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com wrote:
The fix I intend for this bug is currently on MKCL's github repo master head. Please give it a try.
Works for me. There are now only 4 ASDF failures instead of 67/67 in the "plan" branch, and they are probably my bad. I'll investigate.
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
Probably your best footer quote ever!
I'm glad you liked it. I have many others, including by the same author.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org [A] Computer [programming] language is inherently a pun — [it] needs to be interpreted by both men & machines. — Henry Baker
On Sun, Jul 23, 2017 at 7:49 PM, Faré fare@tunes.org wrote:
Regarding these ASDF failures on MKCL:
- test-program was a bug in my latest ASDF tweaks, now fixes.
- test-bundle and test3 smell like another case where MKCL errors out
due to non-serious conditions being signalled, this time inside a require.
It does smell fishy in that area now that you mention it. Investigating...
- test-defsystem-depends-on-phase-overlap.script is because said test
tries to undefine a class using (setf (find-class 'asdf::my-cl-source-file) nil) and MKCL disapproves, unlike all other tested CL implementations, erroring with: "TEST ABORTED: NIL is not of type SI:INSTANCE." Is that a compliant way to undefine a class? If not, is there one and what is it?
This is clearly a bug in MKCL! Your attempt at undefining a class is directly in line with "Issue SETF-FIND-CLASS Writeup" annexed to the ANSI-CL standard.
On Mon, Jul 24, 2017 at 1:28 AM, Jean-Claude Beaudoin < jean.claude.beaudoin@gmail.com> wrote:
On Sun, Jul 23, 2017 at 7:49 PM, Faré fare@tunes.org wrote:
Regarding these ASDF failures on MKCL:
- test-program was a bug in my latest ASDF tweaks, now fixes.
- test-bundle and test3 smell like another case where MKCL errors out
due to non-serious conditions being signalled, this time inside a require.
It does smell fishy in that area now that you mention it. Investigating...
- test-defsystem-depends-on-phase-overlap.script is because said test
tries to undefine a class using (setf (find-class 'asdf::my-cl-source-file) nil) and MKCL disapproves, unlike all other tested CL implementations, erroring with: "TEST ABORTED: NIL is not of type SI:INSTANCE." Is that a compliant way to undefine a class? If not, is there one and what is it?
This is clearly a bug in MKCL! Your attempt at undefining a class is directly in line with "Issue SETF-FIND-CLASS Writeup" annexed to the ANSI-CL standard.
Please give a try to the latest MKCL's github repo master head, it has new commits that should fix both problems mentioned here above.
Cheers,
JCB
On Tue, Jul 25, 2017 at 5:20 AM, Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com wrote:
Please give a try to the latest MKCL's github repo master head, it has new commits that should fix both problems mentioned here above.
Yup. It all works now. Thanks!
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Designing a computer programming system that doesn't address transactional persistence means that you're proud of having no data worth keeping. —#f
On 7/25/17 Jul 25 -4:20 AM, Jean-Claude Beaudoin wrote:
Please give a try to the latest MKCL's github repo master head, it has new commits that should fix both problems mentioned here above.
What's the right repo to work from? I have this:
origin https://gitlab.common-lisp.net/mkcl/mkcl.git (fetch)
but I see you are talking about a github repo instead of cl.net
Thanks, r
On Tue, Jul 25, 2017 at 9:14 AM, Robert Goldman rpgoldman@sift.net wrote:
On 7/25/17 Jul 25 -4:20 AM, Jean-Claude Beaudoin wrote:
Please give a try to the latest MKCL's github repo master head, it has new commits that should fix both problems mentioned here above.
What's the right repo to work from? I have this:
origin https://gitlab.common-lisp.net/mkcl/mkcl.git (fetch)
but I see you are talking about a github repo instead of cl.net
I got the fixes from https://github.com/jcbeaudoin/MKCL.git
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is just as difficult and dangerous to try to free a people that wants to remain servile as it is to enslave a people that wants to remain free. ― Niccolò Machiavelli (1469–1527)
On 7/25/17 Jul 25 -8:18 AM, Faré wrote:
On Tue, Jul 25, 2017 at 9:14 AM, Robert Goldman rpgoldman@sift.net wrote:
On 7/25/17 Jul 25 -4:20 AM, Jean-Claude Beaudoin wrote:
Please give a try to the latest MKCL's github repo master head, it has new commits that should fix both problems mentioned here above.
What's the right repo to work from? I have this:
origin https://gitlab.common-lisp.net/mkcl/mkcl.git (fetch)
but I see you are talking about a github repo instead of cl.net
I got the fixes from https://github.com/jcbeaudoin/MKCL.git
Confirmed: after pulling from that github repo, all tests pass on MKCL. Haven't tested upgrade yet: will do so now.
Still confused about the relationship between the cl.net and github repos.
R
On Tue, Jul 25, 2017 at 11:29 AM, Robert Goldman rpgoldman@sift.net wrote:
On 7/25/17 Jul 25 -8:18 AM, Faré wrote:
On Tue, Jul 25, 2017 at 9:14 AM, Robert Goldman rpgoldman@sift.net
wrote:
(...)
What's the right repo to work from? I have this:
origin https://gitlab.common-lisp.net/mkcl/mkcl.git (fetch)
This repo on gitlab is a mirror that is tracking the MKCL github repo (here below) with a lag of less than 24 hours (typically much less than that).
but I see you are talking about a github repo instead of cl.net
I got the fixes from https://github.com/jcbeaudoin/MKCL.git
This repo on github is the main one that I work from directly. So new commits will appear on it first before being replicated to gitlab.
Confirmed: after pulling from that github repo, all tests pass on MKCL. Haven't tested upgrade yet: will do so now.
Great. Thanks for the confirmation.
JCB
-
Faré -
Faré -
Jean-Claude Beaudoin -
Robert Goldman