Hi all,
I've stumbled a bit here on "format". Can someone please either correct
any misapprehensions I might have, or just quickly try this on some
other Lisp implementation?
(format t "~{~a~}" (list "string1" "string2" (concatenate 'string
"string3" (string #\newline))))
Looks like this when I run it.
CL-USER> (format t "~{~a~}" (list "string1" "string2" (concatenate
'string "string3" (string #\newline))))
string1string2
string3
NIL
My question is, why is there (apparently?) an extra newline after
string2? I have experimented with moving/adding/deleting/etc the
newline after string3, and managed to produce this (apparent) bug under
this particular configuration -> ie formating strings that end in
newlines with ~a.
I'm running:
clisp --version
GNU CLISP 2.35 (2005-08-29) (built 3334391766) (memory 3334450252)
on
Linux Mandrake (Mandriva 2005 LE).
I might have missed something real obvious here, so I'll have another
look after I've had a sleep. It might just be a bug (my first find?)
Have a good night/whatever time you're at. Thanks.
senator wrote:
> My question is, why is there (apparently?) an extra newline after
> string2?
there is no extra newline in LispWorks on Windows and CMUCL on Linux.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
"senator" <···············@gmail.com> wrote in message
·····························@g43g2000cwa.googlegroups.com...
> Hi all,
>
> I've stumbled a bit here on "format". Can someone please either correct
> any misapprehensions I might have, or just quickly try this on some
> other Lisp implementation?
>
> (format t "~{~a~}" (list "string1" "string2" (concatenate 'string
> "string3" (string #\newline))))
>
> Looks like this when I run it.
> CL-USER> (format t "~{~a~}" (list "string1" "string2" (concatenate
> 'string "string3" (string #\newline))))
> string1string2
> string3
>
> NIL
>
> My question is, why is there (apparently?) an extra newline after
> string2?
Bug.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"senator" <···············@gmail.com> writes:
> Hi all,
>
> I've stumbled a bit here on "format". Can someone please either correct
> any misapprehensions I might have, or just quickly try this on some
> other Lisp implementation?
>
> (format t "~{~a~}" (list "string1" "string2" (concatenate 'string
> "string3" (string #\newline))))
>
> Looks like this when I run it.
> CL-USER> (format t "~{~a~}" (list "string1" "string2" (concatenate
> 'string "string3" (string #\newline))))
> string1string2
> string3
>
> NIL
>
> My question is, why is there (apparently?) an extra newline after
> string2? I have experimented with moving/adding/deleting/etc the
> newline after string3, and managed to produce this (apparent) bug under
> this particular configuration -> ie formating strings that end in
> newlines with ~a.
>
> I'm running:
> clisp --version
> GNU CLISP 2.35 (2005-08-29) (built 3334391766) (memory 3334450252)
>
> on
> Linux Mandrake (Mandriva 2005 LE).
>
> I might have missed something real obvious here, so I'll have another
> look after I've had a sleep. It might just be a bug (my first find?)
> Have a good night/whatever time you're at. Thanks.
This is a bug. Please, report it on ··········@lists.sourceforge.net
--
__Pascal Bourguignon__ http://www.informatimago.com/
Grace personified,
I leap into the window.
I meant to do that.
[CCed to ··········@lists.sourceforge.net]
Pascal Bourguignon wrote:
> "senator" <···············@gmail.com> writes:
>
>
>>Hi all,
>>
>>I've stumbled a bit here on "format". Can someone please either correct
>>any misapprehensions I might have, or just quickly try this on some
>>other Lisp implementation?
>>
>>(format t "~{~a~}" (list "string1" "string2" (concatenate 'string
>>"string3" (string #\newline))))
>>
>>Looks like this when I run it.
>>CL-USER> (format t "~{~a~}" (list "string1" "string2" (concatenate
>>'string "string3" (string #\newline))))
>>string1string2
>>string3
>>
>>NIL
>>
>>My question is, why is there (apparently?) an extra newline after
>>string2? I have experimented with moving/adding/deleting/etc the
>>newline after string3, and managed to produce this (apparent) bug under
>>this particular configuration -> ie formating strings that end in
>>newlines with ~a.
>>
>>I'm running:
>>clisp --version
>>GNU CLISP 2.35 (2005-08-29) (built 3334391766) (memory 3334450252)
>>
>>on
>>Linux Mandrake (Mandriva 2005 LE).
>>
>>I might have missed something real obvious here, so I'll have another
>>look after I've had a sleep. It might just be a bug (my first find?)
>>Have a good night/whatever time you're at. Thanks.
>
>
> This is a bug. Please, report it on ··········@lists.sourceforge.net
I've taken the liberty of CCing this message to the clisp-list. I hate
it when somebody discovers/reports a bug, and is told to go report it
somewhere else, fill out Form 3A in triplicate etcetera. The reward for
the discovery of a bug in an open source work should be a big "thank
you" from the community for helping, not a subtle implication that,
absent more work (however minor), the bug will simply be ignored because
the poster didn't follow procedure.
>
> I've taken the liberty of CCing this message to the clisp-list. I hate
Thanks for that.
> it when somebody discovers/reports a bug, and is told to go report it
> somewhere else, fill out Form 3A in triplicate etcetera. The reward for
heh... We all try our best, but there's just too many
mouse-clicks/keystrokes to go through.
> the discovery of a bug in an open source work should be a big "thank
> you" from the community for helping, not a subtle implication that,
> absent more work (however minor), the bug will simply be ignored because
> the poster didn't follow procedure.
Well, I popped over to sourceforge and had a quick look, and it looks
like Sam Steingold (thanks Sam) submitted that into the bug tracking
system at
http://sourceforge.net/tracker/index.php?func=detail&aid=1412454&group_id=1355&atid=101355
Apparently, it's some kinda interactive with the pretty printer.
Setting it to nil works. From the bug report itself:
(let ((*print-pretty* nil))
(format nil "~{~a~}"
(list "string1" "string2"
(concatenate 'string "string3" (string #\newline)))))
"string1string2string3
"
That's good enough for me, for now. Sweet. Thanks to all replies.
From: Sam Steingold
Subject: Re: Quick (hopefully) help with format
Date:
Message-ID: <umzhnhqos.fsf@gnu.org>
> * Cameron MacKinnon <··········@pyrnefcbg.arg> [2006-01-22 17:17:44 -0500]:
>
> I hate it when somebody discovers/reports a bug, and is told to go
> report it somewhere else, fill out Form 3A in triplicate etcetera. The
> reward for the discovery of a bug in an open source work should be a
> big "thank you" from the community for helping, not a subtle
> implication that, absent more work (however minor), the bug will
> simply be ignored because the poster didn't follow procedure.
I don't think I quite follow your logic.
You appear to be saying that if one buys software from a for-profit
commercial entity, then it is OK to require him to "fill out Form 3A in
triplicate", while if he gets software for free from unpaid volunteers,
those same volunteers should give him "a big 'thank you'" if he merely
_discovers_ the bug, even if does not report it in a useful way (as
defined by the volunteers).
Am I missing something?
For specificity, let us assume that we are talking about Mozilla here,
and I discovered a bug in nested <ul> rendering and reported it, say, on
runet.web.browsers. Do I deserve "a big 'thank you'" from Asa Dotzler?
--
Sam Steingold (http://www.podval.org/~sds) running w2k
http://ffii.org http://pmw.org.il http://www.mideasttruth.com
http://www.camera.org http://www.honestreporting.com
There are 3 kinds of people: those who can count and those who cannot.
Sam Steingold wrote:
>>* Cameron MacKinnon <··········@pyrnefcbg.arg> [2006-01-22 17:17:44 -0500]:
>>
>>I hate it when somebody discovers/reports a bug, and is told to go
>>report it somewhere else, fill out Form 3A in triplicate etcetera. The
>>reward for the discovery of a bug in an open source work should be a
>>big "thank you" from the community for helping, not a subtle
>>implication that, absent more work (however minor), the bug will
>>simply be ignored because the poster didn't follow procedure.
>
>
> I don't think I quite follow your logic.
>
> You appear to be saying that if one buys software from a for-profit
> commercial entity, then it is OK to require him to "fill out Form 3A in
> triplicate",
No. Some companies act this way, but it isn't smart business.
> while if he gets software for free from unpaid volunteers,
> those same volunteers should give him "a big 'thank you'" if he merely
> _discovers_ the bug, even if does not report it in a useful way (as
> defined by the volunteers).
Yes.
> For specificity, let us assume that we are talking about Mozilla here,
> and I discovered a bug in nested <ul> rendering and reported it, say, on
> runet.web.browsers. Do I deserve "a big 'thank you'" from Asa Dotzler?
Well, if Asa or his associates hang out on runet.web.browsers, then yes.
If a developer's goal is a bug-free product, it shouldn't matter where
the bug gets reported or how much detail there is (so long as there's
enough, possibly gleaned via subsequent conversation, to reproduce the
bug).
In an ideal world, everybody would read the release notes and all the
comments in the source code (even the important ones buried at the
bottom), and post bugs to the appropriate list/system. But in the real
world, you can't choose your users, you write the README file as if it
is the only file they'll read, and you take bug sightings on public
forums as an opportunity to show how customer focused you are and how
quickly you can provide a fix. In an ideal real world, that is.