Re: Test base library stable branch please

[leeg]

> David Ayers schrieb:
>
>>
>> Actually I get these failures on the trunk also... So I'll need to
>> investigate... (possibly associated with my locale settings for decimal
>> points?)
>
> Indeed this code looks very suspicious:
>   // if no format specified, use the same default that Cocoa does
>   if (nil == useFormat)
>     {
>       useFormat = negativeNumber ? @"-#,###.##" : @"#,###.##";
>     }
> as does the preexisting code:
> - (id) init
> {
>   id    o;
>
>   _allowsFloats = YES;
>   _decimalSeparator = '.';
>   _thousandSeparator = ',';
> ...
>
> Shouldn't the format honor the values for NSLocaleDecimalSeparator and
> NSLocaleGroupingSeparator somehow obtained via NSUserDefaults (or
> NSLocale once we have that class)?
>

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.

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

It's the tests which are broken in this case, as they compare the result
of the formatting to a non-localised string (i.e. they work fine on my
system in C locale, but would break in other locales).  I don't know when
I'll have time to fix the tests so do look at it if you want, otherwise
I'll try to fix it sometime soon.