[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8033: Not the byte compiler; problem lies deeper

From: Michael Welsh Duggan
Subject: bug#8033: Not the byte compiler; problem lies deeper
Date: Mon, 14 Feb 2011 17:08:27 -0500
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)

Chong Yidong <address@hidden> writes:

> Michael Welsh Duggan <address@hidden> writes:
>> Here is a patch which fixes this problem.
>> *** src/print.c      2011-02-14 15:39:19 +0000
>> --- src/print.c      2011-02-14 20:24:00 +0000
>> ***************
>> *** 1063,1068 ****
>> --- 1063,1070 ----
>>         /* Generate the fewest number of digits that represent the
>>       floating point value without losing information.  */
>>         dtoastr (buf, FLOAT_TO_STRING_BUFSIZE, 0, 0, data);
>> +       /* Force a decimal point even if integer */
>> +       width = 1;
>>       }
>>     else                     /* oink oink */
>>       {
> Thanks, but could you explain why printing the float 1.0 as "1" can
> cause this problem in Gnus?  The code in Gnus passes the actual Lisp
> objects around, so the printer shouldn't be involved.

Because the byte compiler uses something like `print' in order to create
the forms in the elc file, and some "1.0"'s in the
`gnus-buffer-configuration' get rendered as "1" in the elc file.  Hence,
when the .elc file gets loaded instead of the .el file (and why not, it
is more recent), you get the bogus integer value instead of the float

This is also why this issue will not occur for people who have not
bootstrapped, since gnus-win.el has not changed.  It does not get
recompiled, and as a result the elc file left behind by a previous
compile still has the "1.0" values in it.

Michael Welsh Duggan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]