Re: Test base library stable branch please

[Matt Rice]

On 2007-01-01 14:05:02 -0800 David Ayers <address@hidden> wrote:

> 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 ? @"-#,###.##" : @"#,###.##";
>     }

I'd spoken with Graham Lee about this before the patch went in base,
he'd said that the formats are not localisable, but the output 
definately is,
so I'm not sure this is suspicious (haven't looked at the test in 
question though)

> 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)?
>
> 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."
>
> > FAIL: round up for fractional part >0.5
>   pass([str isEqual: @"1,235"], "round up for fractional part >0.5");
> where str = @"1,234"
>
> > FAIL: prefix and suffix used properly
>   pass([str isEqual: @"$1234.56c"], "prefix and suffix used 
> properly");
> where str = @"$1234.c"
>
> > FAIL: negativeFormat used for -ve number
>   pass([str isEqual: @"-$(1234.56)"], "negativeFormat used for -ve 
> number");
> where str = @"-$(1234.)"
>
> > FAIL: format string of length 1
>   pass([str isEqual: @"-1235"], "format string of length 1");
> where str = @"-1234"
>
> Please let us know if this can be addressed before the next stable
> branch of -base (not the upcoming bug fix release which doesn't 
> contain
> the new code yet) as these formatters will become more interesting for
> GDL2 as EOInterface evolves.  If you don't have the time, I might try 
> to
> find some.
>
> Cheers,
> David
>
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev