[racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]

On 29-12-11 15:08, Matthew Flatt wrote:
> At Thu, 29 Dec 2011 10:34:53 +0100, Marijn wrote:
>> Because the french locale uses comma (,) as the decimal separator like
>> my dutch one and unlike the english one which uses dot (.). So when
>> the locale-aware C number reading function gets to it and sees (.) it
>> fails to recognize is as a valid number character. Now that I've
>> thought about it more the weird behavior where it starts working
>> correctly after having seen a number bigger than 1.0 smells like an
>> unmatched push/pop locale pair. Might this then not also cause quite a
>> big locale stack to be allocated? Finally I wanted to ask if it was
>> possible that the automated tests are run with a non-english or random
>> locale.
>>
>> Matthew, I still wanted to remark that I find it strange that plain
>> racket did not exhibit the same locale-dependence. Do you have an
>> explanation for that? Does it read some >=1.0 float causing the locale
>> stack to become ``seeded'' (due to postulated unmatched push/pop).
> 
> I am not clear on how the LC_NUMERIC locale gets set to anything other
> than "C". My best guess is that Gtk sets it, and that's why the problem
> happens only in DrRacket and why the problem showed up relatively
> recently.
> 
> There's not really a stack of locales in Racket. Aside from the two
> clearly matched pairs of scheme_push_c_numeric_locale() and
> scheme_pop_c_numeric_locale(), Racket sets LC_CTYPE and LC_LOCALE on
> demand for functions like `bytes->string/locale' or `path->string'.
> It's possible that Racket and Gtk will interfere with each other and
> that Racket needs to manage the those settings more tightly (setting
> them and restoring them more like the LC_NUMERIC handling).

Alright, so trying with today's master, it looks like you made changes
such that .1 now evaluates correctly. This locale bug was the root cause
of several other nasty bugs, such as the plot library not working
(well), Check Syntax hanging drracket and prolly other nasty things
which made drracket appear fragile in non-english locales.

It looks like there is still a residual bug though, that causes the
stairs function when zoomed in to have non-vertical parts as you can see
in the screenshot, though I can reproduce it also with the C locale, so
looks like a genuine plot library bug this time. Although I am surprised
at that too, since Neil looked at a similar screenshot by me earlier
which also showed this problem. Forgot to push the fix for this Neil?

Marijn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drracket-plot-stairs-zoom-nonvertical-lines.png
Type: image/png
Size: 61122 bytes
Desc: not available
URL: <http://lists.racket-lang.org/dev/archive/attachments/20120111/fb45b6c2/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.racket-lang.org/dev/archive/attachments/20120111/fb45b6c2/attachment.sig>