From: Sam S. <sd...@gn...> - 2010-07-29 16:02:23
|
Should CLOS warnings be style warnings? now that the compiler user CLCS, the CLOS warnings may confuse ASDF, DEFSYSTEM and such into thinking that compilation failed. Should these warnings be made style warnings? They are relatively common but do not seem to indicate _real_ problems. The specific case: WARNING: COMPILE-FILE warned while performing #<COMPILE-OP (:FORCE T :VERBOSE T) #x00033879D660> on #<CL-SOURCE-FILE "gsll" "histogram" "updating-accessing">. WARNING: COMPILE-FILE failed while performing #<COMPILE-OP (:FORCE T :VERBOSE T) #x00033879D660> on #<CL-SOURCE-FILE "gsll" "histogram" "updating-accessing">. as a result of WARNING: Replacing method #<STANDARD-METHOD (#<STANDARD-CLASS HISTOGRAM2D> #<BUILT-IN-CLASS T> #<BUILT-IN-CLASS T>)> in #<STANDARD-GENERIC-FUNCTION SET-RANGES-UNIFORM> WARNING: Replacing method #<STANDARD-METHOD (#<STANDARD-CLASS HISTOGRAM>)> in #<STANDARD-GENERIC-FUNCTION COPY> WARNING: Replacing method #<STANDARD-METHOD (#<STANDARD-CLASS HISTOGRAM2D>)> in #<STANDARD-GENERIC-FUNCTION COPY> when recompiling GSLL. |
From: Pascal C. <pc...@p-...> - 2010-07-29 17:45:54
|
Method replacement (and class redefinition, etc.) is part of standard CLOS semantics, and is not deprecated or discouraged by the spec in any way. This means that it is, at best, only subjectively "faulty" or "substandard". This seems to suggest that style-warning is the appropriate choice, considering the HyperSpec entry for style-warning. Pascal On 29 Jul 2010, at 18:02, Sam Steingold wrote: > Should CLOS warnings be style warnings? > now that the compiler user CLCS, the CLOS warnings may confuse ASDF, DEFSYSTEM > and such into thinking that compilation failed. > Should these warnings be made style warnings? > They are relatively common but do not seem to indicate _real_ problems. > The specific case: > > WARNING: COMPILE-FILE warned while performing #<COMPILE-OP (:FORCE T :VERBOSE > T) #x00033879D660> on #<CL-SOURCE-FILE "gsll" "histogram" > "updating-accessing">. > WARNING: COMPILE-FILE failed while performing #<COMPILE-OP (:FORCE T :VERBOSE > T) #x00033879D660> on #<CL-SOURCE-FILE "gsll" "histogram" > "updating-accessing">. > > as a result of > > WARNING: Replacing method > #<STANDARD-METHOD > (#<STANDARD-CLASS HISTOGRAM2D> #<BUILT-IN-CLASS T> > #<BUILT-IN-CLASS T>)> > in #<STANDARD-GENERIC-FUNCTION SET-RANGES-UNIFORM> > WARNING: Replacing method #<STANDARD-METHOD (#<STANDARD-CLASS HISTOGRAM>)> in > #<STANDARD-GENERIC-FUNCTION COPY> > WARNING: Replacing method #<STANDARD-METHOD (#<STANDARD-CLASS HISTOGRAM2D>)> > in #<STANDARD-GENERIC-FUNCTION COPY> > > when recompiling GSLL. > > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > clisp-devel mailing list > cli...@li... > https://lists.sourceforge.net/lists/listinfo/clisp-devel -- Pascal Costanza, mailto:pc...@p-..., http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium |
From: Bruno H. <br...@cl...> - 2010-07-29 19:18:54
|
Sam asked: > Should CLOS warnings be style warnings? No, STYLE-WARNING is defined to apply to code that is faulty / substandard / uses deprecated features or similar. If a warning depends not only on the code but also on the current state of compilation environment, it cannot be a STYLE-WARNING. > now that the compiler user CLCS, the CLOS warnings may confuse ASDF, DEFSYSTEM > and such into thinking that compilation failed. > Should these warnings be made style warnings? > They are relatively common but do not seem to indicate _real_ problems. > The specific case: > > WARNING: COMPILE-FILE warned while performing #<COMPILE-OP (:FORCE T :VERBOSE > T) #x00033879D660> on #<CL-SOURCE-FILE "gsll" "histogram" > "updating-accessing">. This one seems ok: A summary warning about warnings occurring during a compilation is fine. > WARNING: COMPILE-FILE failed while performing #<COMPILE-OP (:FORCE T :VERBOSE > T) #x00033879D660> on #<CL-SOURCE-FILE "gsll" "histogram" > "updating-accessing">. This looks like a bug in the message: Why does it say that COMPILE-FILE "failed", when it were only warnings? Bug in ASDF or DEFSYSTEM? I would suggest that you create a subclass EXT:CLOS-WARNING of class WARNING and, if necessary, teach ASDF and/or DEFSYSTEM to ignore this kind of warning. Pascal Costanza wrote: > Method replacement (and class redefinition, etc.) is part of standard CLOS > semantics, and is not deprecated or discouraged by the spec in any way. This > means that it is, at best, only subjectively "faulty" or "substandard". > This seems to suggest that style-warning is the appropriate choice, considering > the HyperSpec entry for style-warning. I don't understand the logic that leads to the last sentence. Bruno [1] http://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Body/contyp_style-warning.html |
From: Sam S. <sd...@gn...> - 2010-07-29 19:07:43
|
On 7/29/10, Bruno Haible <br...@cl...> wrote: > Sam asked: > > Should CLOS warnings be style warnings? > > No, STYLE-WARNING is defined to apply to code that is faulty / substandard / > uses deprecated features or similar. If a warning depends not only on the code > but also on the current state of compilation environment, it cannot be a > STYLE-WARNING. the notion of style does not have to be static. loading the same file several times is bad style, and the second and subsequent loadings evoke the warning. > > WARNING: COMPILE-FILE failed while performing #<COMPILE-OP (:FORCE T :VERBOSE > > T) #x00033879D660> on #<CL-SOURCE-FILE "gsll" "histogram" > > "updating-accessing">. > > > This looks like a bug in the message: Why does it say that COMPILE-FILE > "failed", when it were only warnings? Bug in ASDF or DEFSYSTEM? http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_fi.htm 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. i.e., non-style warnings ==> failure-p == true > I would suggest that you create a subclass EXT:CLOS-WARNING of class WARNING we already have such a class. I suggest that it inherits from style-warning, not warning because these warnings do not indicate serious problems. > if necessary, teach ASDF and/or DEFSYSTEM to ignore this kind of warning. it is not clear to me that the ASDF maintainers will be willing to add complexity to their code to satisfy clisp quirks. I think these warning are poised to go the way rational contagion warnings went: since they are warning overly aggressively about non-existent problems, people just disable them and thus they, effectively, do not exist. the current behavior will merely lead people to set clos::*enable-clos-warnings* to nil. -- Sam Steingold <http://sds.podval.org> |
From: Bruno H. <br...@cl...> - 2010-07-29 19:50:40
|
Sam wrote: > loading the same file several times is bad style, > and the second and subsequent loadings evoke the warning. So the warning is actually about an unclean compilation environment, not about a particular code. Hence STYLE-WARNING is inappropriate for it. > http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_fi.htm > > 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. > > i.e., non-style warnings ==> failure-p == true I don't understand how one can call it a "failure" if COMPILE-FILE creates an output file, no errors were encountered, and some warnings were encountered. I'd suggest that tools like ASDF or DEFSYSTEM look at the first value of COMPILE-FILE, not at the third value. > I suggest that it inherits from style-warning, not warning because > these warnings do not indicate serious problems. Warnings never indicate serious problems, because serious problems are indicated by conditions of type ERROR. With your argumentation, any of the warnings emitted by these forms (defconstant foo '(a b c)) ; when executed more than once (defstruct (foo (:print-function #'print-foo)) ()) and basically any other warning that can occur during macro expansion would have to be changed into a STYLE-WARNING so that the third value of COMPILE-FILE becomes NIL. This makes no sense. The right fix is to ignore the third value of COMPILE-FILE. > the current behavior will merely lead people to set > clos::*enable-clos-warnings* to nil. And what about the warnings from DEFCONSTANT and DEFSTRUCT and others, then? > > if necessary, teach ASDF and/or DEFSYSTEM to ignore this kind of warning. > > it is not clear to me that the ASDF maintainers will be willing to add > complexity to their code to satisfy clisp quirks. Ask them to use #+clisp. Bruno |
From: Gabriel D. R. <gd...@in...> - 2010-07-29 20:52:02
|
On Thu, Jul 29, 2010 at 2:50 PM, Bruno Haible <br...@cl...> wrote: >> http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_fi.htm >> >> 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. >> >> i.e., non-style warnings ==> failure-p == true > > I don't understand how one can call it a "failure" if COMPILE-FILE > creates an output file, no errors were encountered, and some warnings > were encountered. The value of failure-p is not solely defined in terms of COMPILE-FILE producing or not producing an output file. In reality, the fact CLISP has been agressively abusing of WARNING is increasingly making CLISP unusable with automated builds that rely on the standard spec. I have encountered such a case recemtly with OpenAxiom/CLISP -- something thatshould be a STYLE-WARNING is reported as a WARNING, provoking a failure, where none existed; all other free Lisps happily report STYLE-WARNIG on that case. > I'd suggest that tools like ASDF or DEFSYSTEM look > at the first value of COMPILE-FILE, not at the third value. That looks to me like a stretched interpretation of COMPILE-FILE. -- Gaby |
From: Sam S. <sd...@gn...> - 2010-07-29 21:43:56
|
On 7/29/10, Gabriel Dos Reis <gd...@in...> wrote: > >> http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_fi.htm > >> > >> 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. > >> > >> i.e., non-style warnings ==> failure-p == true > > > > I don't understand how one can call it a "failure" if COMPILE-FILE > > creates an output file, no errors were encountered, and some warnings > > were encountered. > > The value of failure-p is not solely defined in terms of COMPILE-FILE > producing or not producing an output file. are you talking about failure-p in the spec? if yes, then its definition has nothing to do with producing or not producing an output file. > > I'd suggest that tools like ASDF or DEFSYSTEM look > > at the first value of COMPILE-FILE, not at the third value. > > That looks to me like a stretched interpretation of COMPILE-FILE. what makes you think that non-nil tertiary value of COMPILE-FILE means that COMPILE-FILE failed - apart from the name of the return value? I think that the name is not particularly appropriate. -- Sam Steingold <http://sds.podval.org> |
From: Gabriel D. R. <gd...@in...> - 2010-07-29 22:07:54
|
On Thu, Jul 29, 2010 at 4:43 PM, Sam Steingold <sd...@gn...> wrote: > On 7/29/10, Gabriel Dos Reis <gd...@in...> wrote: >> >> http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_fi.htm >> >> >> >> 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. >> >> >> >> i.e., non-style warnings ==> failure-p == true >> > >> > I don't understand how one can call it a "failure" if COMPILE-FILE >> > creates an output file, no errors were encountered, and some warnings >> > were encountered. >> >> The value of failure-p is not solely defined in terms of COMPILE-FILE >> producing or not producing an output file. > > are you talking about failure-p in the spec? Yes. > if yes, then its definition has nothing to do with > producing or not producing an output file. Exactly. > >> > I'd suggest that tools like ASDF or DEFSYSTEM look >> > at the first value of COMPILE-FILE, not at the third value. >> >> That looks to me like a stretched interpretation of COMPILE-FILE. > > what makes you think that non-nil tertiary value of COMPILE-FILE means > that COMPILE-FILE failed - apart from the name of the return value? > > I think that the name is not particularly appropriate. I'm not interpreting 'failure' as failure to produce an output file. I am interpreting it as is in the spec -- detection of an ERROR or WARNING condition (other than STYLE-WARNING.) How is that used? This is a situation where it can be used by automated builds: if the input file contains a use of a variable that was not declared, then the compiler would issue a warning for a use of a variable that is not declared. Depending on the situation, runtime evaluation is likely to produce an error. In that case, the WARNING (and not a STYLE-WARNING) is a indication that something might go wrong. So, an automated build tool would consult failure-p and abort the build. That is one of the several ways that OpenAxiom uses that value. It has been effective with SBCL, ECL, Clozure CL, and CLISP until recently. -- Gaby |
From: Sam S. <sd...@gn...> - 2010-07-29 22:39:05
|
On 7/29/10, Gabriel Dos Reis <gd...@in...> wrote: > > > > what makes you think that non-nil tertiary value of COMPILE-FILE means > > that COMPILE-FILE failed - apart from the name of the return value? > > > > I think that the name is not particularly appropriate. > > I'm not interpreting 'failure' as failure to produce an output file. > I am interpreting it as is in the spec -- detection of an ERROR or > WARNING condition (other than STYLE-WARNING.)> > How is that used? > This is a situation where it can be used by automated builds: if the > input file contains a use of a variable that was not declared, then > the compiler would issue a warning for a use of a variable that is > not declared. Depending on the situation, runtime evaluation is > likely to produce an error. In that case, the WARNING (and not > a STYLE-WARNING) is a indication that something might go wrong. > > So, an automated build tool would consult failure-p and abort the > build. I do not see how this behavior is justified by the spec. specifically, I do not see how a WARNING can justify an ABORT. -- Sam Steingold <http://sds.podval.org> |
From: Gabriel D. R. <gd...@in...> - 2010-07-29 22:50:40
|
On Thu, Jul 29, 2010 at 5:38 PM, Sam Steingold <sd...@gn...> wrote: > On 7/29/10, Gabriel Dos Reis <gd...@in...> wrote: >> > >> > what makes you think that non-nil tertiary value of COMPILE-FILE means >> > that COMPILE-FILE failed - apart from the name of the return value? >> > >> > I think that the name is not particularly appropriate. >> >> I'm not interpreting 'failure' as failure to produce an output file. >> I am interpreting it as is in the spec -- detection of an ERROR or >> WARNING condition (other than STYLE-WARNING.)> >> How is that used? >> This is a situation where it can be used by automated builds: if the >> input file contains a use of a variable that was not declared, then >> the compiler would issue a warning for a use of a variable that is >> not declared. Depending on the situation, runtime evaluation is >> likely to produce an error. In that case, the WARNING (and not >> a STYLE-WARNING) is a indication that something might go wrong. >> >> So, an automated build tool would consult failure-p and abort the >> build. > > I do not see how this behavior is justified by the spec. > specifically, I do not see how a WARNING can justify an ABORT. I am not sure I am following you. Are you talking of a Lisp compiler or a build tool based on a Lisp compiler? -- Gaby |
From: Pascal C. <pc...@p-...> - 2010-07-30 00:04:30
|
On 29 Jul 2010, at 20:53, Bruno Haible wrote: > > Pascal Costanza wrote: >> Method replacement (and class redefinition, etc.) is part of standard CLOS >> semantics, and is not deprecated or discouraged by the spec in any way. This >> means that it is, at best, only subjectively "faulty" or "substandard". >> This seems to suggest that style-warning is the appropriate choice, considering >> the HyperSpec entry for style-warning. > > I don't understand the logic that leads to the last sentence. The spec says this about style-warning: "The type style-warning includes those conditions that represent situations involving code that is conforming code but that is nevertheless considered to be faulty or substandard." Replacing existing methods by way of defmethod or add-method is conforming code. If anybody considers this nevertheless faulty or substandard, a style-warning is the only choice according to that description. According to 3.2.5, it can't be an error, because replacing a method does not cause the compiler to get stuck, and it can't be a warning, because the consequences of replacing a method are not undefined, and replacing a method will not cause a run-time error. Pascal -- Pascal Costanza, mailto:pc...@p-..., http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium |
From: Sam S. <sd...@gn...> - 2010-07-30 00:38:09
|
On 7/29/10, Gabriel Dos Reis <gd...@in...> wrote: > >> So, an automated build tool would consult failure-p and abort the > >> build. > > > > I do not see how this behavior is justified by the spec. > > specifically, I do not see how a WARNING can justify an ABORT. > > I am not sure I am following you. > Are you talking of a Lisp compiler or a build tool based on a Lisp compiler? I do not see how a WARNING signaled by a Lisp compiler, can justify a blanket abort by a build tool. -- Sam Steingold <http://sds.podval.org> |
From: Gabriel D. R. <gd...@in...> - 2010-07-30 02:14:08
|
On Thu, Jul 29, 2010 at 7:38 PM, Sam Steingold <sd...@gn...> wrote: > On 7/29/10, Gabriel Dos Reis <gd...@in...> wrote: >> >> So, an automated build tool would consult failure-p and abort the >> >> build. >> > >> > I do not see how this behavior is justified by the spec. >> > specifically, I do not see how a WARNING can justify an ABORT. >> >> I am not sure I am following you. >> Are you talking of a Lisp compiler or a build tool based on a Lisp compiler? > > I do not see how a WARNING signaled by a Lisp compiler, > can justify a blanket abort by a build tool. What is CLISP's semantics of a WARNING condition from COMPILE-FILE? -- Gaby |
From: Sam S. <sd...@gn...> - 2010-07-30 02:47:40
|
On 7/29/10, Gabriel Dos Reis <gd...@in...> wrote: > What is CLISP's semantics of a WARNING condition from > COMPILE-FILE? there are warnings signaled by compile-file (which have the usual semantics described in the spec) and also warnings which are signaled by other components (e.g., CLOS) invoked by compile-file. since now compile-file handles it warnings/errors through CLHS, these warnings from other components now affect the compile-file's return values. e.g., compile-file of ==================== (eval-when (:compile) (warn "foo")) ==================== will return failure-p=T because it will signal the "foo" warning. -- Sam Steingold <http://sds.podval.org> |
From: Gabriel D. R. <gd...@in...> - 2010-07-30 03:42:55
|
On Thu, Jul 29, 2010 at 9:47 PM, Sam Steingold <sd...@gn...> wrote: > On 7/29/10, Gabriel Dos Reis <gd...@in...> wrote: >> What is CLISP's semantics of a WARNING condition from >> COMPILE-FILE? > > there are warnings signaled by compile-file (which have the usual > semantics described in the spec) and also warnings which are signaled > by other components (e.g., CLOS) invoked by compile-file. > since now compile-file handles it warnings/errors through CLHS, these > warnings from other components now affect the compile-file's return > values. > e.g., compile-file of > ==================== > (eval-when (:compile) (warn "foo")) > ==================== > will return failure-p=T because it will signal the "foo" warning. yes; I have no problem with that because there is a WARNING condition. And I expect failure-p to be true for that case. My problem is what CLISP decides to signal as a WARNING as opposed to STYLE-WARNING. -- Gaby |
From: Sam S. <sd...@gn...> - 2010-07-30 13:46:09
|
On 7/29/10, Gabriel Dos Reis <gd...@in...> wrote: > On Thu, Jul 29, 2010 at 9:47 PM, Sam Steingold <sd...@gn...> wrote: > > On 7/29/10, Gabriel Dos Reis <gd...@in...> wrote: > >> What is CLISP's semantics of a WARNING condition from > >> COMPILE-FILE? > > > > there are warnings signaled by compile-file (which have the usual > > semantics described in the spec) and also warnings which are signaled > > by other components (e.g., CLOS) invoked by compile-file. > > since now compile-file handles it warnings/errors through CLHS, these > > warnings from other components now affect the compile-file's return > > values. > > e.g., compile-file of > > ==================== > > (eval-when (:compile) (warn "foo")) > > ==================== > > will return failure-p=T because it will signal the "foo" warning. > > yes; I have no problem with that because there is a WARNING condition. > And I expect failure-p to be true for that case. and you are prepared to declare that compilation failed? even though a perfectly valid FAS file was created? I think this is eminently wrong. > My problem is what CLISP decides to signal as a WARNING > as opposed to STYLE-WARNING. Yes, I agree with Pascal on this matter. However, there _are_ situations when CLISP will signal warnings which are not style warnings, which does not mean that the compilation failed. -- Sam Steingold <http://sds.podval.org> |
From: Gabriel D. R. <gd...@in...> - 2010-07-30 16:06:14
|
On Fri, Jul 30, 2010 at 8:46 AM, Sam Steingold <sd...@gn...> wrote: > On 7/29/10, Gabriel Dos Reis <gd...@in...> wrote: >> On Thu, Jul 29, 2010 at 9:47 PM, Sam Steingold <sd...@gn...> wrote: >> > On 7/29/10, Gabriel Dos Reis <gd...@in...> wrote: >> >> What is CLISP's semantics of a WARNING condition from >> >> COMPILE-FILE? >> > >> > there are warnings signaled by compile-file (which have the usual >> > semantics described in the spec) and also warnings which are signaled >> > by other components (e.g., CLOS) invoked by compile-file. >> > since now compile-file handles it warnings/errors through CLHS, these >> > warnings from other components now affect the compile-file's return >> > values. >> > e.g., compile-file of >> > ==================== >> > (eval-when (:compile) (warn "foo")) >> > ==================== >> > will return failure-p=T because it will signal the "foo" warning. >> >> yes; I have no problem with that because there is a WARNING condition. >> And I expect failure-p to be true for that case. > > and you are prepared to declare that compilation failed? A build tool based on COMPILE-FILE can declare that the compilation failed -- even if COMPILE-FILE produced a FASL output -- if it determined that WARNING or an ERROR was signaled. As long as CLISP sticks to the standard spec of failure-p, there is nothing wrong with that -- if the goal of the build tool is to enforce absence of a certain kind of construct. As noted below, if CLISP starts smashing STYLE-WARNING under WARNING, then it would be eminently wrong as you say below. > even though a perfectly valid FAS file was created? > I think this is eminently wrong. > >> My problem is what CLISP decides to signal as a WARNING >> as opposed to STYLE-WARNING. > > Yes, I agree with Pascal on this matter. let's say we are at least three to agree on this. > However, there _are_ situations when CLISP will signal warnings which > are not style warnings, which does not mean that the compilation > failed. Yes, I understand that. And I believe we are in a violent agreement. At the risk of sounding like a broken record, I am talking from the perspective of a build tool based on COMPILE-FILE. From CLHS point of view, the Lisp compilation may not fail, yet failure-p be true -- there is no dispute about that. The tool may declare that the compilation fails if its job is to enforce absence of certain constructs that elicit WARNING. -- Gaby |