[asdf-devel] About asdf:*compile-file-failure-behaviour* and its value on SBCL
Hi, ASDF developers I think asdf:*compile-file-failure-behaviour* should never been set to :error, just :warn is good. CLHS [1] said about COMPILE-FILE's 2nd and 3rd return values: "The secondary value, warnings-p, is false if no conditions of type error or warning were detected by the compiler, and true otherwise. "The tertiary value, failure-p, is false if no conditions of type error or warning (other than style-warning) were detected by the compiler, and true otherwise." This means, any warnings other than style-warning will cause COMPILE-FILE return T on its third return value. Than every Lisp file which contains a general (WARN "...") form, when compiling, will cause COMPILE-FILE return T on its third return value, and therefore was marked as "failure" (by ASDF). In current asdf.lisp, asdf:*compile-file-failure-behaviour* was defined as follow: (defvar *compile-file-failure-behaviour* (or #+sbcl :error #+clisp :ignore :warn) "How should ASDF react if it encounters a failure (per the ANSI spec of COMPILE-FILE) when compiling a file? Valid values are :error, :warn, and :ignore. Note that ASDF ALWAYS raises an error if it fails to create an output file when compiling.") I don't know why SBCL here is special, but this definition caused my project (cl-net-snmp 6.0) failed to be compiled by ASDF "only" on SBCL. Just try to put following lines in your ASDF based project and try to build it: (eval-when (:compile-toplevel) (warn "xxx")) you'll find how ludicrous the current setting of asdf:*compile-file-failure-behaviour* are. Regards, Chun Tian (binghe) [1] http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_fi.htm#compile-f...
On 19 March 2011 14:51, Chun Tian (binghe) <binghe.lisp@gmail.com> wrote:
Hi, ASDF developers
I think asdf:*compile-file-failure-behaviour* should never been set to :error, just :warn is good.
Well, SBCL is known for its anal attitude towards declaring as an error or failure anything that could be possibly interpreted as such by the standard, the idea being that a program that works in SBCL should work anywhere. Traditionally, a warning in SBCL counts as a failure in compilation.
I don't know why SBCL here is special, but this definition caused my project (cl-net-snmp 6.0) failed to be compiled by ASDF "only" on SBCL. Just try to put following lines in your ASDF based project and try to build it:
(eval-when (:compile-toplevel) (warn "xxx"))
you'll find how ludicrous the current setting of asdf:*compile-file-failure-behaviour* are.
What about using alexandria:simple-style-warning ? Maybe there should be a short-hand alexandria:style-warn? Meh. Or if that's what you want, just format something to the error-output. In any case, it's a long tradition for SBCL to behave that way, and other library authors, including I, have accepted that fact. I'm sorry that the answer isn't completely satisfactory to you. Been there, done that. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] You don't have to like everything about me, but if you don't love me the way I am, it's not me you love, only some fantasy of yours.
Hi, Fare Thanks you for your explanation ... it seems that you're suggesting a general WARN condition should never been signaled on compile-time. Most of the compile-time warnings in my program comes from cl-yacc [1], because I'm trying to do LALR parsing for a very ambiguous language called ASN.1 [1], there're 28 Shift/Reduce, and 1 Reduce/Reduce conflicts in my LALR grammar rules and it produce correct result. Fortunately I used a modified version of cl-yacc and directly include it as vendor code (and changed its package), so I can change all these warnings into style-warnings, to make SBCL happy. There's another compile-time warning in my CLOS related code, something like this: (defclass a-class () ((slot :type 'a-subclass))) (defclass a-subclass (a-class) ()) When compiling the first class definition, SBCL warn that the type A-SUBCLASS haven't been defined (this is true, but I defined it immediately in next form). I think, to make SBCL happy, again, I have to reorder above two definitions, putting the definition of A-SUBCLASS before A-CLASS, and CLOS does support this, using a MOP feature called FORWARDED-REFERENCE-CLASS. I still don't think these coding styles are wrong according ANSI Common Lisp standards, but if ASDF insist to do so, I have to modify my code. Regards, Chun Tian (binghe) [1] http://www.pps.jussieu.fr/~jch/software/cl-yacc/ 在 2011-3-20，07:53， Faré 写道：
On 19 March 2011 14:51, Chun Tian (binghe) <binghe.lisp@gmail.com> wrote:
Hi, ASDF developers
I think asdf:*compile-file-failure-behaviour* should never been set to :error, just :warn is good.
Well, SBCL is known for its anal attitude towards declaring as an error or failure anything that could be possibly interpreted as such by the standard, the idea being that a program that works in SBCL should work anywhere. Traditionally, a warning in SBCL counts as a failure in compilation.
I don't know why SBCL here is special, but this definition caused my project (cl-net-snmp 6.0) failed to be compiled by ASDF "only" on SBCL. Just try to put following lines in your ASDF based project and try to build it:
(eval-when (:compile-toplevel) (warn "xxx"))
you'll find how ludicrous the current setting of asdf:*compile-file-failure-behaviour* are.
What about using alexandria:simple-style-warning ? Maybe there should be a short-hand alexandria:style-warn? Meh. Or if that's what you want, just format something to the error-output. In any case, it's a long tradition for SBCL to behave that way, and other library authors, including I, have accepted that fact. I'm sorry that the answer isn't completely satisfactory to you. Been there, done that.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] You don't have to like everything about me, but if you don't love me the way I am, it's not me you love, only some fantasy of yours.
"Chun Tian (binghe)" <binghe.lisp@gmail.com> writes:
There's another compile-time warning in my CLOS related code, something like this:
(defclass a-class () ((slot :type 'a-subclass)))
(defclass a-subclass (a-class) ())
When compiling the first class definition, SBCL warn that the type A-SUBCLASS haven't been defined
I can't reproduce. Is this an oversimplification of your actual problem? Zach
Hi, Zach Sorry, I checked again, it's just a style-warning, ASDF actually won't stop the building process: * (compile-file "warning") ; compiling file "/Users/binghe/Lisp/src/warning.lisp" (written 20 MAR 2011 09:27:10 AM): ; compiling (IN-PACKAGE :CL-USER) ; compiling (DEFCLASS A-CLASS ...) ; compiling (DEFCLASS A-SUBCLASS ...) ; file: /Users/binghe/Lisp/src/warning.lisp ; in: DEFCLASS A-CLASS ; (DEFCLASS A-CLASS NIL ((SLOT :TYPE A-SUBCLASS))) ; --> PROGN EVAL-WHEN ; ==> ; (LET () ; (SB-PCL::LOAD-DEFCLASS 'A-CLASS 'STANDARD-CLASS 'NIL ; (LIST ; (LIST* :NAME 'SLOT :READERS 'NIL :WRITERS 'NIL ; :INITARGS 'NIL 'SB-PCL::TYPE-CHECK-FUNCTION ; (SB-INT:NAMED-LAMBDA # ; # ; # ; SB-PCL::VALUE) ; '(:TYPE A-SUBCLASS))) ; (LIST :DIRECT-DEFAULT-INITARGS NIL) 'NIL 'NIL ; '(SLOT) (SB-C:SOURCE-LOCATION) 'NIL)) ; ; caught STYLE-WARNING: ; undefined type: A-SUBCLASS ; ; compilation unit finished ; Undefined type: ; A-SUBCLASS ; caught 1 STYLE-WARNING condition ; /Users/binghe/Lisp/src/warning.fasl written ; compilation finished in 0:00:00.017 #P"/Users/binghe/Lisp/src/warning.fasl" T NIL But I still want to change the order to make it better in SBCL: * (compile-file "warning") ; compiling file "/Users/binghe/Lisp/src/warning.lisp" (written 20 MAR 2011 09:29:21 AM): ; compiling (IN-PACKAGE :CL-USER) ; compiling (DEFCLASS A-SUBCLASS ...) ; compiling (DEFCLASS A-CLASS ...) ; /Users/binghe/Lisp/src/warning.fasl written ; compilation finished in 0:00:00.014 #P"/Users/binghe/Lisp/src/warning.fasl" NIL NIL --binghe 在 2011-3-20，09:06， Zach Beane 写道：
"Chun Tian (binghe)" <binghe.lisp@gmail.com> writes:
There's another compile-time warning in my CLOS related code, something like this:
(defclass a-class () ((slot :type 'a-subclass)))
(defclass a-subclass (a-class) ())
When compiling the first class definition, SBCL warn that the type A-SUBCLASS haven't been defined
I can't reproduce. Is this an oversimplification of your actual problem?
Zach
On 20 March 2011 03:06, Zach Beane <xach@xach.com> wrote:
"Chun Tian (binghe)" <binghe.lisp@gmail.com> writes:
(defclass a-class () ((slot :type 'a-subclass)))
(defclass a-subclass (a-class) ())
When compiling the first class definition, SBCL warn that the type A-SUBCLASS haven't been defined
I can't reproduce. Is this an oversimplification of your actual problem?
Me neither, but... (declaim (optimize safety)) (defclass a-class () ((slot :type 'a-subclass))) (defclass a-subclass (a-class) ()) (defmethod foo ((x a-class) y) (setf (slot-value x 'slot) y)) gives: ; caught WARNING: ; Undefined type 'A-SUBCLASS. The name starts with QUOTE: probably use of a ; quoted type name in a context where the name is not evaluated. Replace 'a-subclass with a-subclass, and modern (1.0.45.11 or later, I would guess) SBCL is silent and happy. (Though really SBCL _should_ complain about the quote even without the OPTIMIZE SAFETY and DEFMETHOD FOO...) :P Cheers, -- Nikodemus
Hi, Nikodemus The QUOTE in "'a-subclass" is actually a typo. Actually I'm compiling this in my last post: (in-package :cl-user) (defclass a-subclass (a-class) ()) (defclass a-class () ((slot :type a-subclass))) I didn't even declaim a (optimize safety) ... --binghe 在 2011-3-20，09:38， Nikodemus Siivola 写道：
On 20 March 2011 03:06, Zach Beane <xach@xach.com> wrote:
"Chun Tian (binghe)" <binghe.lisp@gmail.com> writes:
(defclass a-class () ((slot :type 'a-subclass)))
(defclass a-subclass (a-class) ())
When compiling the first class definition, SBCL warn that the type A-SUBCLASS haven't been defined
I can't reproduce. Is this an oversimplification of your actual problem?
Me neither, but...
(declaim (optimize safety))
(defclass a-class () ((slot :type 'a-subclass)))
(defclass a-subclass (a-class) ())
(defmethod foo ((x a-class) y) (setf (slot-value x 'slot) y))
gives:
; caught WARNING: ; Undefined type 'A-SUBCLASS. The name starts with QUOTE: probably use of a ; quoted type name in a context where the name is not evaluated.
Replace 'a-subclass with a-subclass, and modern (1.0.45.11 or later, I would guess) SBCL is silent and happy. (Though really SBCL _should_ complain about the quote even without the OPTIMIZE SAFETY and DEFMETHOD FOO...) :P
Cheers,
-- Nikodemus
2011/3/20 Chun Tian (binghe) <binghe.lisp@gmail.com>:
The QUOTE in "'a-subclass" is actually a typo. Actually I'm compiling
Fair enough. However, if you update your SBCL you will see that the behaviour has changed a bit. Cheers, -- Nikodemus
participants (4)
-
Chun Tian (binghe) -
Faré -
Nikodemus Siivola -
Zach Beane