Hi folks,
I have a strange compilation problem with SBCL and CL-PPCRE, when
compiling a file via ASDF. I have the following method, that operates
on CXML nodes/handlers:
(defmethod s_date ((node docnode) (h disc-handler))
"Parse year from date. We'll assume german dates for now."
(let ((date (attribute-value (find-attribute "value" (attributes node)))))
#+DBG (format t "Produced at date: ~A~%" date)
(register-groups-bind (day month year)
("([0-9][0-9]?)\.([0-9][0-9]?)\.([120][120][0-9][0-9])" date)
(declare (ignore day month))
(setf (year (disc h)) year))))
Now, if I change the last setf to
(setf (year (disc h)) (parse-integer year))
and compile the definition, I get an SBCL warning:
; in: DEFMETHOD S_DATE (DOCNODE DISC-HANDLER)
; CL-PPCRE:REGISTER-GROUPS-BIND
; --> LET MULTIPLE-VALUE-BIND MULTIPLE-VALUE-CALL FUNCTION WHEN COND IF
; --> PROGN LET* LET IF
; ==>
; NIL
;
; caught WARNING:
; This is not a STRING:
; NIL
; See also:
; The SBCL Manual, Node "Handling of Types"
I don't understand that warning at all. I had a look at the
macroexpansion of the register-group-bind, but I see nothing
suspicious (to me).
Now, if I compile the entire file with that changed method, I get the
very same warning. Now, the file is part of an entire system and if I
try to compile that, I get a compilation error, with no particular
explanation as to what went wrong:
; /var/cache/common-lisp-controller/1368/sbcl/local/home/schauer/programming/lisp/cl/disccol/reviews/parse-plattentests.fasl written
; compilation finished in 0:00:00
WARNING:
COMPILE-FILE warned while performing #<COMPILE-OP NIL {BF2F459}> on
#<CL-SOURCE-FILE "parse-plattentests" {C046911}>.
debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" {A801B09}>:
Error during processing of --eval option (LOAD #P"start.lisp"):
erred while invoking #<COMPILE-OP NIL {BF2F459}> on
#<CL-SOURCE-FILE "parse-plattentests" {C046911}>
The backtrace is:
0] BACKTRACE 8
0: ((LAMBDA (SB-IMPL::E)) #<ASDF:COMPILE-FAILED {BA103E9}>)
1: ((LAMBDA (SB-IMPL::E)) #<ASDF:COMPILE-FAILED {BA103E9}>)
2: (SIGNAL #<ASDF:COMPILE-FAILED {BA103E9}>)
3: (ERROR ASDF:COMPILE-FAILED)
4: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE))
#<unavailable argument>
#<unavailable argument>
#<ASDF:COMPILE-OP NIL {BF2F459}>
#<ASDF:CL-SOURCE-FILE "parse-plattentests" {C046911}>)
5: ((LAMBDA
(SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.
SB-PCL::.ARG1.))
#<unavailable argument>
#<unavailable argument>
#<ASDF:COMPILE-OP NIL {BF2F459}>
#<ASDF:CL-SOURCE-FILE "parse-plattentests" {C046911}>)
6: ((LAMBDA ()))
7: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA #) {B2F4805}>)
What baffles me is that I get that error only when I add the
parse-integer call. I don't understand that at all and also don't have
the slightest idea where to look next. Any hints?
Thanks,
Holger
--
--- http://hillview.bugwriter.net/ ---
"Ja, und ganz sicher sind *SIE* hinter uns her und wollen uns Qt und KDE
nehmen, so wie sie es schon mit Bielefeld gemacht haben."
-- Florian Kuehnert in de.comp.os.linux.misc
On 5293 September 1993, Leandro Rios wrote:
> It seems that tour regexp is malformed. When there is no match,
> register-groups-bind returns nil and does not execute the &body of the
> macro.
Huh? We're not talking about run-time, but about compilation time.
I.e., at the time the code gets compiled, it's not possible to tell
whether the the regex will match or not.
> Look at the macroexpansion:
> (macroexpand-1 (cl-ppcre:register-groups-bind (day month year)
> (WHEN #:MATCH-START2170 ;<<<<<<<<<<<<<<<<<<<<<<<<<<< HERE
[...]
> (VALUES DAY MONTH YEAR)))))
Please note that the values expression (the &body) is entirely
encapsulated inside the when.
You're right, the regex is not correct wrt. the kind of data I wanted
to retrieve (i.e., it's semantically wrong). But that doesn't explain
the compilation warning/error at all.
Holger
--
--- http://hillview.bugwriter.net/ ---
"Ja, und ganz sicher sind *SIE* hinter uns her und wollen uns Qt und KDE
nehmen, so wie sie es schon mit Bielefeld gemacht haben."
-- Florian Kuehnert in de.comp.os.linux.misc
Holger Schauer escribi�:
> Huh? We're not talking about run-time, but about compilation time.
Duh! You're right, sorry about the confusion. Anyway, I cannot reproduce
this error. What SBCL version are you using? I'm using 1.0.14. See if
this is of any help:
http://article.gmane.org/gmane.lisp.lib.tbnl.general/491/match=this+is+not+a+string
Again, sorry about the confusion.
Leandro
Holger Schauer <··············@gmx.de> writes:
> What baffles me is that I get that error only when I add the
> parse-integer call. I don't understand that at all and also don't have
> the slightest idea where to look next. Any hints?
PARSE-INTEGER needs a string argument. SBCL has noticed that there's a
chance it'd be called with NIL instead, and is giving a warning about
that. (Of course that chance does not really exist, since that block
of code will only be executed when the rexexp matched. But SBCL
doesn't know of the relationship between a match succeeding and that
particular group having been matched).
One way to fix You can silence the warning with
a MUFFLE-CONDITIONS declaration in some appropriate scope:
#+sbcl (declare (sb-ext:muffle-conditions warning))
Or you can let SBCL know that YEAR will in fact not be NIL when
PARSE-INTEGER is called:
(when year (parse-integer year))
--
Juho Snellman
On 5293 September 1993, Juho Snellman wrote:
> Holger Schauer <··············@gmx.de> writes:
>> What baffles me is that I get that error only when I add the
>> parse-integer call. I don't understand that at all and also don't have
>> the slightest idea where to look next. Any hints?
> PARSE-INTEGER needs a string argument. SBCL has noticed that there's a
> chance it'd be called with NIL instead, and is giving a warning about
> that. [...]
> Or you can let SBCL know that YEAR will in fact not be NIL when
> PARSE-INTEGER is called: (when year (parse-integer year))
Thanks. That indeed fixes both the warning and the error on ASDF
loading. While the problem at hand is now fixed, I would still be
interested to learn why a simple compilation warning may result in an
ASDF compile error. I would have thought that at the end of the day
all what ASDF does is to call compile-file. Usually warnings don't
result in errors during a load-op or compile-op, so is that also some
kind of SBCL special behaviour wrt. to type warnings or something?
Holger
--
--- http://hillview.bugwriter.net/ ---
"Ja, und ganz sicher sind *SIE* hinter uns her und wollen uns Qt und KDE
nehmen, so wie sie es schon mit Bielefeld gemacht haben."
-- Florian Kuehnert in de.comp.os.linux.misc
From: Thomas A. Russ
Subject: Re: System compilation failure, CLPPCRE, ASDF, SBCL involved
Date:
Message-ID: <ymimypk2a4b.fsf@blackcat.isi.edu>
Holger Schauer <··············@gmx.de> writes:
> On 5293 September 1993, Juho Snellman wrote:
> > Holger Schauer <··············@gmx.de> writes:
> >> What baffles me is that I get that error only when I add the
> >> parse-integer call. I don't understand that at all and also don't have
> >> the slightest idea where to look next. Any hints?
>
> > PARSE-INTEGER needs a string argument. SBCL has noticed that there's a
> > chance it'd be called with NIL instead, and is giving a warning about
> > that. [...]
> > Or you can let SBCL know that YEAR will in fact not be NIL when
> > PARSE-INTEGER is called: (when year (parse-integer year))
>
> Thanks. That indeed fixes both the warning and the error on ASDF
> loading. While the problem at hand is now fixed, I would still be
> interested to learn why a simple compilation warning may result in an
> ASDF compile error. I would have thought that at the end of the day
> all what ASDF does is to call compile-file. Usually warnings don't
> result in errors during a load-op or compile-op, so is that also some
> kind of SBCL special behaviour wrt. to type warnings or something?
Well, I don't know about ASDF, but I encountered something perhaps
similar when doing Loom development. What happened was that we had code
that called COMPILE and actually checked the second return value from
the COMPILE function to see if there were any problems. The style
warnings generated by CMUCL were enough to trigger this. (The code was
pre-ANSI and unfortunately, didn't check the third return value
instead...). Also, I think that some of the compiler notes were not
properly handled by COMPILE at one time, either.
Anyway, if there is some checking going on that tries to detect whether
a compilation succeeded or not, it could be affected by a compiler that
is somewhat pickier about the warnings that it issues.
COMPILE-FILE also returns three values, with the 2nd and 3rd
corresponding to WARNING-P and FAILURE-P, so this could be what is
triggering the ASDF behavior.
--
Thomas A. Russ, USC/Information Sciences Institute
On Thu, 28 Feb 2008 10:45:24 -0800, Thomas A. Russ wrote:
> COMPILE-FILE also returns three values, with the 2nd and 3rd
> corresponding to WARNING-P and FAILURE-P, so this could be what is
> triggering the ASDF behavior.
>
I have noticed that SBCL sometimes returns t in failure-p, even when there
are only warnings and no Error messages, and an output file has been
generated OK. This might explain it.
Tim
From: Thomas A. Russ
Subject: Re: System compilation failure, CLPPCRE, ASDF, SBCL involved
Date:
Message-ID: <ymiir081yw7.fsf@blackcat.isi.edu>
tim <····@internet.com> writes:
> On Thu, 28 Feb 2008 10:45:24 -0800, Thomas A. Russ wrote:
>
> > COMPILE-FILE also returns three values, with the 2nd and 3rd
> > corresponding to WARNING-P and FAILURE-P, so this could be what is
> > triggering the ASDF behavior.
> >
>
> I have noticed that SBCL sometimes returns t in failure-p, even when there
> are only warnings and no Error messages, and an output file has been
> generated OK. This might explain it.
Interestingly enough, the standard requires FAILURE-P to be T whenver
there are errors or warnings that are not style warnings. So any
warning that isn't a style warning is supposed to set FAILURE-P to T,
even if that is not what one would naively expect.
I suppose the rationale is that if there are non-style warnings, they
may indicate that the code COULD fail to operate correctly and that one
needs to be careful. But if a particular implementation is especially
zealous about producing warnings, then this may cause applications that
were designed with a different understanding of what a warning implies
to conclude that the code is broken.
--
Thomas A. Russ, USC/Information Sciences Institute
tim <····@internet.com> writes:
> On Thu, 28 Feb 2008 10:45:24 -0800, Thomas A. Russ wrote:
> I have noticed that SBCL sometimes returns t in failure-p, even when there
> are only warnings and no Error messages, and an output file has been
> generated OK. This might explain it.
That is how COMPILE-FILE is specified to work by the standard:
failure-p should be true if there were any errors or warnings (besides
style-warnings) during the compilation.
--
Juho Snellman
From: Maciej Katafiasz
Subject: Re: System compilation failure, CLPPCRE, ASDF, SBCL involved
Date:
Message-ID: <fq73gr$q74$3@news.net.uni-c.dk>
Den Thu, 28 Feb 2008 17:50:26 +0100 skrev Holger Schauer:
> Thanks. That indeed fixes both the warning and the error on ASDF
> loading. While the problem at hand is now fixed, I would still be
> interested to learn why a simple compilation warning may result in an
> ASDF compile error. I would have thought that at the end of the day all
> what ASDF does is to call compile-file. Usually warnings don't result in
> errors during a load-op or compile-op, so is that also some kind of SBCL
> special behaviour wrt. to type warnings or something?
No. It's a deficiency in reporting errors in COMPILE-FILE -- basically it
boils down to ASDF being unable to distinguish between warnings and
errors, so it has to error out on both (the alternative being to silently
accept both, which is even worse).
Cheers,
Maciej