I have 2 questions that come from the latest version of cl-pdf and
cl-typesetting.
In almost all implementations
(parse-integer "1 2" :junk-allowed t) => 1 1
Except in the CMUCL dated 2003-09-08 which reply 1 and 4. The previous CMUCL
versions give 1 and 1 like all the others. (found by Eric Marsden)
Is it compliant? If yes is it a good idea ?
The second question was about make-instance but I found the answer while
writing my question... :)
So I have only the parse-integer question left...
Marc
"Marc Battyani" <·············@fractalconcept.com> wrote in message
···············@library1.airnews.net...
> I have 2 questions that come from the latest version of cl-pdf and
> cl-typesetting.
>
> In almost all implementations
> (parse-integer "1 2" :junk-allowed t) => 1 1
> Except in the CMUCL dated 2003-09-08 which reply 1 and 4. The previous
CMUCL
> versions give 1 and 1 like all the others. (found by Eric Marsden)
>
> Is it compliant? If yes is it a good idea ?
>
> The second question was about make-instance but I found the answer while
> writing my question... :)
> So I have only the parse-integer question left...
>
Ouch! After re-reading PARSE-INTEGER in the HS, I think it can be argued
both ways
1. CMUCL is the only one that gets it right, if you connect these two
statements:
"Optional leading and trailing whitespace[1] is ignored."
"The second value is either the index into the string of the delimiter
that terminated the parse,"
If leading and trailing whitespace is ignored, it can't terminate the parse.
2. CMUCL gets it wrong
If there is junk, the trailing whitespace isn't actually trailing,
and it is more efficient to terminate on the first whitespace found
when :JUNK-ALLOWED is T.
Take your pick. I'm inclined to number one because of this
behaviour(LW.PE-4.2.0):
CL-USER 9 > (parse-integer "1 ")
1
6
CL-USER 10 > (parse-integer "1 " :junk-allowed t)
1
1
Just doesn't feel right. OTOH, I like the efficiency of terminating early.
My head hurts, I'm going for my first coffee of the day.
--
Cheers, Geoff
"Geoffrey Summerhayes" <·············@hotmail.com> wrote in
>
> "Marc Battyani" <·············@fractalconcept.com> wrote
> > I have 2 questions that come from the latest version of cl-pdf and
> > cl-typesetting.
> >
> > In almost all implementations
> > (parse-integer "1 2" :junk-allowed t) => 1 1
> > Except in the CMUCL dated 2003-09-08 which reply 1 and 4. The previous
> CMUCL
> > versions give 1 and 1 like all the others. (found by Eric Marsden)
> >
> > Is it compliant? If yes is it a good idea ?
>
> Ouch! After re-reading PARSE-INTEGER in the HS, I think it can be argued
> both ways
>
> 1. CMUCL is the only one that gets it right, if you connect these two
> statements:
>
> "Optional leading and trailing whitespace[1] is ignored."
> "The second value is either the index into the string of the delimiter
> that terminated the parse,"
>
> If leading and trailing whitespace is ignored, it can't terminate the
parse.
>
> 2. CMUCL gets it wrong
>
> If there is junk, the trailing whitespace isn't actually trailing,
> and it is more efficient to terminate on the first whitespace found
> when :JUNK-ALLOWED is T.
>
> Take your pick. I'm inclined to number one because of this
> behaviour(LW.PE-4.2.0):
>
> CL-USER 9 > (parse-integer "1 ")
> 1
> 6
>
> CL-USER 10 > (parse-integer "1 " :junk-allowed t)
> 1
> 1
>
> Just doesn't feel right. OTOH, I like the efficiency of terminating early.
> My head hurts, I'm going for my first coffee of the day.
So your conclusion after the coffee ?
Maybe I should ask to the CMUCL guys why they did that change...
Marc
Marc Battyani wrote:
> So your conclusion after the coffee ?
> Maybe I should ask to the CMUCL guys why they did that change...
I think they were fixing a bug in the :junk-allowed nil case.
Paul
Paul F. Dietz <·····@dls.net> wrote:
+---------------
| Marc Battyani wrote:
| > Maybe I should ask to the CMUCL guys why they did that change...
|
| I think they were fixing a bug in the :junk-allowed nil case.
+---------------
Sounds right, especially since the CLHS says [emphasis added]:
The second value is either the index into the string of the
delimiter that terminated the parse, or the UPPER BOUNDING INDEX
OF THE SUBSTRING if the parse terminated at the end of the substring
(AS IS ALWAYS THE CASE IF JUNK-ALLOWED IS FALSE).
Compare CLISP-2.29 and CMUCL-18e [before the change] on the following:
clisp> (parse-integer "1 " :junk-allowed nil)
1 ;
4
clisp>
versus:
cmucl> (parse-integer "1 " :junk-allowed nil)
1
1
cmucl>
Given the quoted CLHS except above, one might well say that CLISP
does it "right" in this case...
-Rob
p.s. However, just to be ornery, also note that:
clisp> (parse-integer "1 2" :junk-allowed t)
1 ;
1
clisp>
So at least one implementation gets the :JUNK-ALLOWED NIL case right
*without* giving 1,4 for the :JUNK-ALLOWED T case. Go figure.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"Paul F. Dietz" <·····@dls.net> wrote
> Marc Battyani wrote:
>
> > Maybe I should ask to the CMUCL guys why they did that change...
>
> I think they were fixing a bug in the :junk-allowed nil case.
So you think that they are right and that all the other implementations are
wrong ?
Marc
Marc Battyani wrote:
>>I think they were fixing a bug in the :junk-allowed nil case.
>
> So you think that they are right and that all the other implementations are
> wrong ?
I think the spec is ambiguous in the :junk-allowed t case.
Paul
Marc Battyani wrote:
>
> "Paul F. Dietz" <·····@dls.net> wrote
> > Marc Battyani wrote:
> >
> > > Maybe I should ask to the CMUCL guys why they did that change...
> >
> > I think they were fixing a bug in the :junk-allowed nil case.
>
> So you think that they are right and that all the other implementations are
> wrong ?
>
cmucl is not the only implementationwhich performs this way.
> Marc
Hi Marc Battyani,
> "Paul F. Dietz" <·····@dls.net> wrote
>> Marc Battyani wrote:
>>
>> > Maybe I should ask to the CMUCL guys why they did that change...
>>
>> I think they were fixing a bug in the :junk-allowed nil case.
>
> So you think that they are right and that all the other implementations are
> wrong ?
Marc, I have just spent hours debugging my own Debian package of cl-pdf
2.0.3 to end up uncovering the same issue [there's some really strange
output occurring with Debian's common-lisp-controller and CMUCL CVS at the
moment:
; /usr/lib/common-lisp/cmucl/cl-pdf/font.x86f written.
; Compilation finished in 0:00:01.
; Loading #p"/usr/lib/common-lisp/cmucl/cl-pdf/font.x86f".
Opt.. DFO Constraint Opt Constraint Type Opt. DFO Constraint Rtran Opt.. DFO Con
straint Opt Constraint Type Env GTN LTN DFO Control Stack DFO IR2Tran Copy Life
TNs: 51 local, 20 temps, 7 constant, 22 env, 0 comp, 23 global.
Wired: 50, Unused: 0. 19 blocks, 151 global conflicts.
Pack Code CoreOpt Constraint Type Env GTN LTN Control IR2Tran Copy Life
TNs: 3 local, 2 temps, 1 constant, 2 env, 0 comp, 2 global.
Wired: 5, Unused: 0. 1 block, 4 global conflicts.
Pack Code Core
; Compilation unit aborted.
; 1 fatal error
; 2 notes
Built Error: Condition PARSE-ERROR was signalled]
I have patched core/reader.lisp so CMUCL is consistent with CLISP and
SBCL. I expect it will be applied since it merely fixes an unforeseen
consequence of fixing the :junk-allowed nil case while still being
conforming.
The patch is trivial:
$ diff -u src/code/reader.lisp.original src/code/reader.lisp
--- src/code/reader.lisp.original 2003-11-06 21:16:20.000000000 +1300
+++ src/code/reader.lisp 2003-11-06 22:40:13.000000000 +1300
@@ -1539,7 +1539,7 @@
(incf index)
(setq any-digits t)
(setq result (+ (* radix result) weight)))
- (skip-whitespace)
+ (unless junk-allowed (skip-whitespace))
;;
;; May be /= index if string is displaced.
(let ((real-index (+ (- index start) orig-start)))
However figuring this out is not trivial. parse-integer has to be
modified to run independently so any changes can be tested without
having to rebuild CMUCL each time.
All these test cases return conforming results:
(parse-integer "123") => 123, 3
(parse-integer " 123") => 123, 5
(parse-integer "123 ") => 123, 5
(parse-integer " 123 ") => 123, 8
(parse-integer "123" :start 1 :radix 5) => 13, 3
(parse-integer "no-integer" :junk-allowed t) => nil, 0
(parse-integer "123junk" :junk-allowed t) => 123, 3
(parse-integer "123 junk" :junk-allowed t) => 123, 3
(parse-integer "1 2") => There's junk in this string: "1 2". [Condition of type kernel:simple-parse-error]
(parse-integer "1 2" :junk-allowed t) => 1, 1
(parse-integer " 1 2" :junk-allowed t) => 1, 6
Regards,
Adam
"Adam Warner" <······@consulting.net.nz> wrote
> Marc, I have just spent hours debugging my own Debian package of cl-pdf
> 2.0.3 to end up uncovering the same issue [there's some really strange
> output occurring with Debian's common-lisp-controller and CMUCL CVS at the
> moment:
...
> I have patched core/reader.lisp so CMUCL is consistent with CLISP and
> SBCL. I expect it will be applied since it merely fixes an unforeseen
> consequence of fixing the :junk-allowed nil case while still being
> conforming.
Good! Did the CMUCL guys told you why they have done that change ?
Tell me if they accept to put your patch or if they prefer their new version.
> (parse-integer "1 2" :junk-allowed t) => 1, 1
> (parse-integer " 1 2" :junk-allowed t) => 1, 6
I prefer this :)
Though the alternative of changing the parsing ot the integer in cl-pdf is
probably still needed.
BTW no that you are a cl-pdf pro, May be you could be interested in
contributing to cl-typesetting ?
Marc,
BTW I tried to send you an email but it bounced. you should ask your ISP to
allow emails from fractalconcept.com
Hi Marc Battyani,
>> Marc, I have just spent hours debugging my own Debian package of cl-pdf
>> 2.0.3 to end up uncovering the same issue [there's some really strange
>> output occurring with Debian's common-lisp-controller and CMUCL CVS at the
>> moment:
> ...
>> I have patched core/reader.lisp so CMUCL is consistent with CLISP and
>> SBCL. I expect it will be applied since it merely fixes an unforeseen
>> consequence of fixing the :junk-allowed nil case while still being
>> conforming.
>
> Good! Did the CMUCL guys told you why they have done that change ?
> Tell me if they accept to put your patch or if they prefer their new version.
You can follow the events here:
<http://news.gmane.org/onethread.php?group=gmane.lisp.cmucl.devel&root=%3Cpan.2003.11.06.10.19.33.822912%40consulting.net.nz%3E>
>> (parse-integer "1 2" :junk-allowed t) => 1, 1
>> (parse-integer " 1 2" :junk-allowed t) => 1, 6
>
> I prefer this :)
I prefer consistency between implementations + the efficiency of not
having to potentially parse a whole string when it is not necessary to
confirm that the rest of the string is whitespace in order to determine
whether an error should be produced.
Otherwise to create an efficient implementation of parse-integer that
stops after the first integer has been read you first have to write
an integer parser to find the end of the integer and then pass that index
to the :end keyword in parse-integer.
A wonderful resource for the community would be the ability to annotate
the specification with reasons why the community makes decisions a
particular way. I understand this would be possible if we started with the
unofficial dpANS documents. I was very pleased to learn that good
arguments exist for them being public domain:
<http://groups.google.com/groups?selm=sfwr84z4dnq.fsf%40shell01.TheWorld.com&output=gplain>
> Though the alternative of changing the parsing ot the integer in cl-pdf
> is probably still needed.
>
> BTW no that you are a cl-pdf pro, May be you could be interested in
> contributing to cl-typesetting ?
I'm yet to do more with cl-pdf than confirm ex1.pdf is generated! I have
previously done my own graph generation and font metric parsing but I'd
rather not reinvent the wheel as cl-pdf is far more capable and it
provides an opportunity for me to learn about the CLOS (this is initially
the reason I avoided it. It was easier to write my own bits than try to
grok the CLOS style of programming). So contributing to cl-typesetting is
a way off.
> Marc,
>
> BTW I tried to send you an email but it bounced. you should ask your ISP
> to allow emails from fractalconcept.com
I administer my own mail server. I've checked my logs and discover:
2003-11-07 10:10:54 recipients refused from
atuileries-117-2-7-98.w193-252.abo.wanadoo.fr [193.252.218.98] (RBL
dynablock.easynet.nl)
I've added fractalconcept.com to my recipients_reject_except_senders in
Exim. In order to significantly cut down on viruses and spam (hundreds a
day, now down to 5-10% of that) I reject messages when the IP address
is on one of a number of real time black hole lists. In this case it's
only because you were emailing from what is believed to be a dynamic IP
address.
(Other people running an SMTP server from a dynamic IP address can still
contact me by sending outgoing mail via their ISP's mail server)
Regards,
Adam
>> Good! Did the CMUCL guys told you why they have done that change ? Tell
>> me if they accept to put your patch or if they prefer their new
>> version.
>
> You can follow the events here:
> <http://news.gmane.org/onethread.php?group=gmane.lisp.cmucl.devel&root=%3Cpan.2003.11.06.10.19.33.822912%40consulting.net.nz%3E>
Marc, it looks like CMUCL is going to remain with the new version. cl-pdf
cannot rely upon a consistent second return value of PARSE-INTEGER.
The decision is backwards incompatible with previous releases of CMUCL,
contrarian and objectively less efficient.
Regards,
Adam
PS: Thanks for the email!
"Adam Warner" <······@consulting.net.nz> wrote
> >> Good! Did the CMUCL guys told you why they have done that change ? Tell
> >> me if they accept to put your patch or if they prefer their new
> >> version.
> >
> > You can follow the events here:
> >
<http://news.gmane.org/onethread.php?group=gmane.lisp.cmucl.devel&root=%3Cpan
.2003.11.06.10.19.33.822912%40consulting.net.nz%3E>
>
> Marc, it looks like CMUCL is going to remain with the new version. cl-pdf
> cannot rely upon a consistent second return value of PARSE-INTEGER.
>
> The decision is backwards incompatible with previous releases of CMUCL,
> contrarian and objectively less efficient.
Common Lisp has (had?) the advantage of being a stable platform on which you
can rely. Though it's fashionable to want to change it.
Their new interpretation seems to be perfectly legal, but I also think its a
bad move to change it for no reason.
In areas where the spec is fuzzy, it would be good to have a de facto
standard.
Anyway if you (or another CMUCL user) have some time to modify and test
cl-pdf on the new CMUCL I will release a new version.
Marc