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
-
Faré -
Jean-Claude Beaudoin