On Mon, Jan 23, 2012 at 3:01 AM, Fred Kiefer <fredkie...@gmx.de> wrote:
> That bug description is not accurate. When running the NSNumberformatter > test program we only call setlocale() twice, once with "" and once with > NULL as the locale. That would be supported behaviour according to the bug > description, but clearly it is not. > I'll attach that modified version to the bug report. I changed your test program to call setlocale() and now it also reports NaN > (See attachment). This really makes me wonder whether it is such a great > idea to use an internationalisation library that only supports English :-( > In all fairness, it has been classified as bug in the library. The "official" way of setting the locale in ICU is using uloc_setDefault(). To get the locale it's uloc_getDefault(). But I see your point and am a little surprised that this is even an issue. I'm even more surprised that it keeps getting pushed off to a later release. It seems to have originally been scheduled for 4.6, then 4.8 and now 5.0. > BTW: Is there a reason why the macro STRING_FROM_NUMBER calls the > conversion twice, even when it was successful on the first attempt? I don't > like the use of macros that much it really makes it hard to tell what is > going on and code in macros never gets as much review as normal code. > No, it's wrong. I saw that when mucking around in there, too, but didn't a fix commit (I'll do so when I get home, today). Don't ask me how I managed to screw that up... I don't know either. On 21.01.2012 23:00, Stefan Bidi wrote: > >> After running a few more tests and still not understanding what is going >> on >> I went to good and found this bug report: >> http://bugs.icu-project.org/**trac/ticket/8214<http://bugs.icu-project.org/trac/ticket/8214> >> >> Seems that ICU does not like it when we use setlocale(). >> >> On Sat, Jan 21, 2012 at 1:53 PM, Stefan Bidi<stefanb...@gmail.com> >> wrote: >> >> I am completely baffled by this bug. I've been trying to debug this for >>> the last 3 hrs and have gotten absolutely no where. I added a unum_open >>> and unum_formatDouble call in -init and I still get NaN when >>> LANG=de_DE.UTF-8. The test program continues to work without a hitch, >>> though. Something about how we handle the NSNumberFormatterInternal >>> structure is screwing up UNumberFormat (I also added a unum_open and >>> unum_formatDouble call in basic10_4.m and it worked fine). >>> >>> >>> On Sat, Jan 21, 2012 at 11:00 AM, Stefan Bidi<stefanb...@gmail.com>** >>> wrote: >>> >>> On Sat, Jan 21, 2012 at 10:41 AM, Fred Kiefer<fredkie...@gmx.de> >>>> wrote: >>>> >>>> Your test code works fine here and results in 1.234 as expected. My >>>>> $LANG is de_DE.UTF-8. And with $LANG set to C the test run fine. >>>>> Strange enough currentLocale ends up being en_US_POSIX >>>>> >>>>> >>>> -currentLocale looks for a Locale default, if it exists that's what it >>>> uses. Do you have that set? >>>> >>>> This still wouldn't explain why UNumberFormat is returning NaN. Both >>>> you >>>> and Philippe have a valid locale. On the plus side, if I set >>>> LANG=de_DE.UTF-8 I can reproduce this. I'll go try to figure out what's >>>> going on. >>>> >>> > _______________________________________________ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev > >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
