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

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Thu Dec 29 09:08:00 EST 2011

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).



Posted on the dev mailing list.