Re: Test base library stable branch please

[David Ayers]

Graham J Lee schrieb:
> On 2 Jan 2007, at 09:38, address@hidden wrote:
> 
>>> David Ayers schrieb:
>>>
>>
>> No...at least, not if it needs to work in the same way as Cocoa's
>> NSNumberFormatter.  Because the documentation says this:
>>  When you enable localization for a number formatter, separators are
>> converted to characters appropriate to the environment in which the
>> application is running.
>> and this:
>> when you enable localization for a number formatter object, the dollar
>> sign character is converted to the currency symbol appropriate for the
>> environment in which the application is running.
>>
>> I took that to mean that the layout of the format string doesn't  change,
>> but the output does depending on the locale.
>>
> 
> In fact, that only seems true if you explicitly enable localisation  in
> a given formatter.  But I looked at providing that, and I think it 
> would require that we already have NSLocale.  Which of course isn't 
> true :-(.  Anyway, regardless the tests *ought* to still pass,  because
> the test case *doesn't* enable localisation.
> 
> N.B. in the Cocoa docs it explicitly says that the thousands  separator
> is "," unless and until you change it e.g. by enabling  localisation. 
> So I take it that the default behaviour is non-localised.
> 
>>> Currently in a de_AT.UTF-8 locale these tests fail:
>>>
>>>> base/NSNumberFormatter/basic.m:
>>>> FAIL: default format same as Cocoa
>>>
>>>   pass([str isEqual: @"1,234.57"], "default format same as Cocoa");
>>> where str = @"1,234."
>>>
> I still haven't been able to duplicate that.  Maybe if you're going  to
> FOSDEM we could meet up and have a mini-hackfest to see WTF is 
> happening :-)

The issue was not a bug in NSNumberFormatter.  It was a bug in the
implementation of NSDecimalNumber

- (id) initWithBytes: (const void*)value objCType: (const char*)type
which called:
[[NSString alloc] initWithFormat: @"%g",v];
instead of
[[NSString alloc] initWithFormat: @"%g"
                          locale: GSPrivateDefaultLocale(), v];
It's just that due to the missing tests for NSDecimalNumber, the issue
didn't show up in the test suite until the tests for the formatter where
added.

Note that NSString's initWithFormat: will call initWithFormat:locale:
with a nil locale which implies a 'C' locale representation while the
subsequent -initWithString: of NSDecimalNumber is implemented as:

  return [self initWithString: numberValue
    locale: GSPrivateDefaultLocale()];

which in turn interprets the string with the current locale as documented:

http://www.gnustep.org/resources/documentation/Developer/Base/Reference/NSDecimalNumber.html#method$NSDecimalNumber-initWithString$

I believe Richard has fixed this part on the release branch already.

But there are actually more issues with the
- (id) initWithBytes: (const void*)value objCType: (const char*)type
implementation, as it ignores the type parameter and simply assumes that
it is a double value.  My patch proposal tries to handle most of the
other types that could be passed to the method.  And it also tries to
handle INF and NAN double and float values better.  But I must admit
that I do not have a Cocoa reference implementation to verify whether
Cocoa handles INF/NAN "correctly".

Sorry, I won't be able to make it to FOSDEM otherwise I would have been
sure to schedule a GDL2 session already.

Cheers,
David