I can't believe this is a bug. I must be doing something
wrong, but I don't see it. I'm working on a program
(simulation) at home and want to append the results of
intermediate calculations to a file for looking at later.
I have extracted/dummied some code. The names have changed
but the intent and number of parameters is the same. When
I run this the first time (no file exists) it looks right.
When I run it the second time it looks like it appends the
values to the file as I want, but the original values are
replaced by nulls (ASCII 0).
(defvar a 0)
(defvar b 1)
(defvar c 2)
(defvar d 3)
(defvar e 4)
(defvar f 5)
(defvar g 6)
(defvar h 7)
(defvar i 8)
(defvar j 9)
(defvar k 10)
(defvar l 11)
(defvar m 12)
(defvar n 13)
(defvar o 14)
(with-open-file (ofile "file.csv" :direction :output
:if-exists :append :if-does-not-exist :create)
(format ofile "~D,~D,~D,~F,~F,~F,~D,~F,~F,~F,~D,~D,~F,~F,~F~."
a b c d e f g h i j k l m n o))
Thanks for looking at this.
Mike
In article <···················@fe05.lga>, Mike <·····@mikee.ath.cx>
wrote:
> I can't believe this is a bug. I must be doing something
> wrong, but I don't see it. I'm working on a program
> (simulation) at home and want to append the results of
> intermediate calculations to a file for looking at later.
>
> I have extracted/dummied some code. The names have changed
> but the intent and number of parameters is the same. When
> I run this the first time (no file exists) it looks right.
> When I run it the second time it looks like it appends the
> values to the file as I want, but the original values are
> replaced by nulls (ASCII 0).
>
> (defvar a 0)
> (defvar b 1)
> (defvar c 2)
> (defvar d 3)
> (defvar e 4)
> (defvar f 5)
> (defvar g 6)
> (defvar h 7)
> (defvar i 8)
> (defvar j 9)
> (defvar k 10)
> (defvar l 11)
> (defvar m 12)
> (defvar n 13)
> (defvar o 14)
>
> (with-open-file (ofile "file.csv" :direction :output
> :if-exists :append :if-does-not-exist :create)
> (format ofile "~D,~D,~D,~F,~F,~F,~D,~F,~F,~F,~D,~D,~F,~F,~F~."
> a b c d e f g h i j k l m n o))
What's the "~." operator at the end? Shouldn't it be "~%" to start a
new line?
I'm not sure why this would cause the behavior you're seeing, though.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
On 2006-01-29, Barry Margolin <······@alum.mit.edu> wrote:
> In article <···················@fe05.lga>, Mike <·····@mikee.ath.cx>
> wrote:
>
>> I can't believe this is a bug. I must be doing something
>> wrong, but I don't see it. I'm working on a program
>> (simulation) at home and want to append the results of
>> intermediate calculations to a file for looking at later.
>>
>> I have extracted/dummied some code. The names have changed
>> but the intent and number of parameters is the same. When
>> I run this the first time (no file exists) it looks right.
>> When I run it the second time it looks like it appends the
>> values to the file as I want, but the original values are
>> replaced by nulls (ASCII 0).
>>
>> (defvar a 0)
>> (defvar b 1)
>> (defvar c 2)
>> (defvar d 3)
>> (defvar e 4)
>> (defvar f 5)
>> (defvar g 6)
>> (defvar h 7)
>> (defvar i 8)
>> (defvar j 9)
>> (defvar k 10)
>> (defvar l 11)
>> (defvar m 12)
>> (defvar n 13)
>> (defvar o 14)
>>
>> (with-open-file (ofile "file.csv" :direction :output
>> :if-exists :append :if-does-not-exist :create)
>> (format ofile "~D,~D,~D,~F,~F,~F,~D,~F,~F,~F,~D,~D,~F,~F,~F~."
>> a b c d e f g h i j k l m n o))
>
> What's the "~." operator at the end? Shouldn't it be "~%" to start a
> new line?
>
> I'm not sure why this would cause the behavior you're seeing, though.
>
By the spec ~. is a newline. Can/should I use ~% instead?
Mike
Mike <·····@mikee.ath.cx> writes:
>>> (with-open-file (ofile "file.csv" :direction :output
>>> :if-exists :append :if-does-not-exist :create)
>>> (format ofile "~D,~D,~D,~F,~F,~F,~D,~F,~F,~F,~D,~D,~F,~F,~F~."
>>> a b c d e f g h i j k l m n o))
>>
>> What's the "~." operator at the end? Shouldn't it be "~%" to start a
>> new line?
>>
>> I'm not sure why this would cause the behavior you're seeing, though.
>>
>
> By the spec ~. is a newline. Can/should I use ~% instead?
What spec page?
AFAIK, ~. is a clisp extension, EXT:ELASTIC-NEWLINE, not a ANSI CL
standard format operator. In portable code, use ~%.
If you want you can write:
(format ofile
#+clisp "~D,~D,~D,~F,~F,~F,~D,~F,~F,~F,~D,~D,~F,~F,~F~."
#-clisp "~D,~D,~D,~F,~F,~F,~D,~F,~F,~F,~D,~D,~F,~F,~F~%"
a b c d e f g h i j k l m n o))
I bet you won't bother...
--
__Pascal Bourguignon__ http://www.informatimago.com/
"A TRUE Klingon warrior does not comment his code!"
On 2006-01-29, Pascal Bourguignon <····@mouse-potato.com> wrote:
> Mike <·····@mikee.ath.cx> writes:
>>>> (with-open-file (ofile "file.csv" :direction :output
>>>> :if-exists :append :if-does-not-exist :create)
>>>> (format ofile "~D,~D,~D,~F,~F,~F,~D,~F,~F,~F,~D,~D,~F,~F,~F~."
>>>> a b c d e f g h i j k l m n o))
>>>
>>> What's the "~." operator at the end? Shouldn't it be "~%" to start a
>>> new line?
>>>
>>> I'm not sure why this would cause the behavior you're seeing, though.
>>>
>>
>> By the spec ~. is a newline. Can/should I use ~% instead?
>
> What spec page?
>
> AFAIK, ~. is a clisp extension, EXT:ELASTIC-NEWLINE, not a ANSI CL
> standard format operator. In portable code, use ~%.
>
> If you want you can write:
>
> (format ofile
> #+clisp "~D,~D,~D,~F,~F,~F,~D,~F,~F,~F,~D,~D,~F,~F,~F~."
> #-clisp "~D,~D,~D,~F,~F,~F,~D,~F,~F,~F,~D,~D,~F,~F,~F~%"
> a b c d e f g h i j k l m n o))
>
>
> I bet you won't bother...
>
Thanks. I didn't know ~% was more portable and ~. a clisp-ism.
No, I won't bother, I'll do it the portable way.
Mike
Mike <·····@mikee.ath.cx> writes:
> When I run it the second time it looks like it appends the
> values to the file as I want, but the original values are
> replaced by nulls (ASCII 0).
You didn't say what lisp implementation you're using, but I will guess
that you are using CLISP 2.37, which has a bug that looks like this.
(In general, if you're not sure whether something is a bug in your
understanding or your implementation, it's worth trying a reduced test
case in another implementation to see if it does something different.)
Christophe
Christophe Rhodes <·····@cam.ac.uk> wrote in
···················@cam.ac.uk:
> Mike <·····@mikee.ath.cx> writes:
>
>> When I run it the second time it looks like it appends the
>> values to the file as I want, but the original values are
>> replaced by nulls (ASCII 0).
>
> You didn't say what lisp implementation you're using, but I will guess
> that you are using CLISP 2.37, which has a bug that looks like this.
>
> (In general, if you're not sure whether something is a bug in your
> understanding or your implementation, it's worth trying a reduced test
> case in another implementation to see if it does something different.)
>
> Christophe
>
Sounds like 2.37.
I upgraded the other day, and then I tried to append to a file, and it
ended up with lots of 0's in it. Thanks for telling me to upgrade to 2.38
(which I did anyway for the standalone exes but just sped up my
installation of it :)
2.38 does fix the append bug.
Thanks,
Jeremy.