PS does the following to warn you about redefining built-in operators:
(warn "Redefining Parenscript operator/macro ~A" name)
As it happens, we redefine DEFMACRO and IN-PACKAGE to expand to nothing and @ to expand to something a bit different than what PS does. The purpose of these redefinitions is to support cross-compiling a number of files to both CL and JS.
Unfortunately, that warning turns into an error preventing ASDF from loading the system in SBCL:
; compilation unit aborted ; caught 1 fatal ERROR condition ; caught 3 WARNING conditions
I don't see what the ERROR is, since only the above three warnings are written to the REPL. It goes away, however, when I comment out the WARN form above.
I have an ugly workaround for this (reach in to PS::*PS-DEFINED-OPERATORS* and rip out these three symbols before attempting to redefine them), but that seems like a horrible thing to do. Resorting to SBCL's condition-muffling mechanism seems even worse.
Just to be clear, I don't object to PS issuing the warning, just to the fact that it turns into a fatal error along the way. So I guess my question is: what's the intended way to redefine a PS operator/macro, on the rare occasion when one really does need to do that?
Daniel
I give up. This is happening because compile-file returns "failure-p, is false if no conditions of type error or warning (other than style-warning) were detected by the compiler."
According to Clozure, this means style-warning exactly, and not any subclasses. Which is completely useless, because style-warning doesn't have any format arguments, so you have to subclass it for it to say anything meaningful.
Anyone have any ideas on what to do? Should I just give up on trying to use warnings and write to *debug-io* myself?
Vladimir
2011/1/17 Daniel Gackle danielgackle@gmail.com:
PS does the following to warn you about redefining built-in operators: (warn "Redefining Parenscript operator/macro ~A" name) As it happens, we redefine DEFMACRO and IN-PACKAGE to expand to nothing and @ to expand to something a bit different than what PS does. The purpose of these redefinitions is to support cross-compiling a number of files to both CL and JS. Unfortunately, that warning turns into an error preventing ASDF from loading the system in SBCL: ; compilation unit aborted ; caught 1 fatal ERROR condition ; caught 3 WARNING conditions I don't see what the ERROR is, since only the above three warnings are written to the REPL. It goes away, however, when I comment out the WARN form above. I have an ugly workaround for this (reach in to PS::*PS-DEFINED-OPERATORS* and rip out these three symbols before attempting to redefine them), but that seems like a horrible thing to do. Resorting to SBCL's condition-muffling mechanism seems even worse. Just to be clear, I don't object to PS issuing the warning, just to the fact that it turns into a fatal error along the way. So I guess my question is: what's the intended way to redefine a PS operator/macro, on the rare occasion when one really does need to do that? Daniel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
On Wed, Jan 26, 2011 at 5:04 AM, Vladimir Sedach vsedach@gmail.com wrote:
I give up. This is happening because compile-file returns "failure-p, is false if no conditions of type error or warning (other than style-warning) were detected by the compiler."
According to Clozure, this means style-warning exactly, and not any subclasses. Which is completely useless, because style-warning doesn't have any format arguments, so you have to subclass it for it to say anything meaningful.
Anyone have any ideas on what to do? Should I just give up on trying to use warnings and write to *debug-io* myself?
Just my €.02, but... to me "no conditions of type... other than style-warning" does exclude both style-warning and its subclasses, since an instance of a subclass of style-warning is of type style-warning. So I'd say you encountered a CCL bug, and using a subclass of style-warning should be fine.
Alessio
It see that this issue is taking up a lot of valuable time - more than it probably deserves. I vote for just removing the warnings. If that's a bad idea, then maybe just leave them as they are for now? We do have a workaround.
A far more important fix is the one to restore lambda lists for local functions. We've got 30 or so temporary patches scattered around our code because of this bug, and I'm anxious to get them out of there. (I know a fix was committed for this, but we can't use it because of an additional bug it seemed to introduce, which I reported a couple of days ago).
Thanks, Daniel
On Wed, Jan 26, 2011 at 3:42 AM, Alessio Stalla alessiostalla@gmail.comwrote:
On Wed, Jan 26, 2011 at 5:04 AM, Vladimir Sedach vsedach@gmail.com wrote:
I give up. This is happening because compile-file returns "failure-p, is false if no conditions of type error or warning (other than style-warning) were detected by the compiler."
According to Clozure, this means style-warning exactly, and not any subclasses. Which is completely useless, because style-warning doesn't have any format arguments, so you have to subclass it for it to say anything meaningful.
Anyone have any ideas on what to do? Should I just give up on trying to use warnings and write to *debug-io* myself?
Just my €.02, but... to me "no conditions of type... other than style-warning" does exclude both style-warning and its subclasses, since an instance of a subclass of style-warning is of type style-warning. So I'd say you encountered a CCL bug, and using a subclass of style-warning should be fine.
Alessio
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
I think you're right about this being a CCL bug. The simple-style-warning works ok on SBCL (I'm going to have to figure out what to do with CLISP before the release, because it doesn't seem to like named-readtables...).
Vladimir
2011/1/26 Alessio Stalla alessiostalla@gmail.com:
On Wed, Jan 26, 2011 at 5:04 AM, Vladimir Sedach vsedach@gmail.com wrote:
I give up. This is happening because compile-file returns "failure-p, is false if no conditions of type error or warning (other than style-warning) were detected by the compiler."
According to Clozure, this means style-warning exactly, and not any subclasses. Which is completely useless, because style-warning doesn't have any format arguments, so you have to subclass it for it to say anything meaningful.
Anyone have any ideas on what to do? Should I just give up on trying to use warnings and write to *debug-io* myself?
Just my €.02, but... to me "no conditions of type... other than style-warning" does exclude both style-warning and its subclasses, since an instance of a subclass of style-warning is of type style-warning. So I'd say you encountered a CCL bug, and using a subclass of style-warning should be fine.
Alessio
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel@common-lisp.net
-
Alessio Stalla -
Daniel Gackle -
Vladimir Sedach