Re: some gnustep-base tests are randomly failing

[Richard Frith-Macdonald]

On 28 Oct 2011, at 17:47, Sebastian Reitenbach wrote:

> 
> On Friday, October 28, 2011 16:57 CEST, Fred Kiefer <fredkiefer@gmx.de> 
> wrote: 
> 
>> On 28.10.2011 16:44, Sebastian Reitenbach wrote:
>>> I found some time, trying to play with other locales so I did:
>>> export LC_CTYPE='en_US.UTF-8'
>>> and reran the testsuite for a couple of times. The random tests don't seem 
>>> to fail anymore.
>>> But with the LC_CTYPE exported, some other tests fail constantly:
>>> Testing json.m...
>>> Running base/NSJSONSerialization/json.m.
>>> Failed test:     json.m:42 ... Round trip worked with pretty printing
>>> Failed test:     json.m:44 ... Round trip worked with ugly printing
>>> Failed test:     json.m:45 ... Round trip worked through stream
>> 
>> These should be fixed by Richard latest change.
>> 
>>> Testing basic.m...
>>> Running base/NSNumberFormatter/basic.m...
>>> Failed test:       basic.m:50 ... numeric and space padding OK
>>> Expected '  001234' and got ' _ 01234'
>> 
>> Interesingly, before Richards change I got the same error, but now I 
>> have different ones here:
>> 
>> base/NSNumberFormatter/basic.m:
>> Failed test:       basic.m:23 ... default format same as Cocoa
>> Failed test:       basic.m:27 ... Handle leading zeroes in fractional 
>> part: 1.01
>> Failed test:       basic.m:31 ... Handle leading zeroes in fractional 
>> part: 1.1
>> Failed test:       basic.m:37 ... -setAllowsFloats: does not effect rounding
>> Failed test:       basic.m:58 ... prefix and suffix used properly
>> Failed test:       basic.m:62 ... negativeFormat used for -ve number
>> 
>> No idea why this is the case, but I had these tests failing previously.
> 
> With a new svn checkout, the tests I had with LC_CTYPE failing are gone, and 
> I now get the same like Fred:
> 
> 
> Testing basic.m...
> Running base/NSNumberFormatter/basic.m...
> Start set:       basic.m:7 ... basic
> Passed test:       basic.m:17 ... +[NSNumberFormatter alloc] returns a 
> NSNumberFormatter
> Failed test:       basic.m:23 ... default format same as Cocoa
> Failed test:       basic.m:27 ... Handle leading zeroes in fractional part: 
> 1.01
> Failed test:       basic.m:31 ... Handle leading zeroes in fractional part: 
> 1.1
> Failed test:       basic.m:37 ... -setAllowsFloats: does not effect rounding
> 2011-10-28 04:33:38.407 basic[1213] 
> NSNumberFormatter-getObjectValue:forString:... not fully implemented
> Passed test:       basic.m:40 ... float input is disallowed
> 2011-10-28 04:33:38.412 basic[1213] 
> NSNumberFormatter-getObjectValue:forString:... not fully implemented
> Passed test:       basic.m:44 ... allowsFloat error
> Passed test:       basic.m:50 ... numeric and space padding OK
> Failed test:       basic.m:58 ... prefix and suffix used properly
> Failed test:       basic.m:62 ... negativeFormat used for -ve number
> Passed test:       basic.m:65 ... notANumber special case
> Passed test:       basic.m:69 ... format string of length 1
> End set:         basic.m:71 ... basic

I think all this depends on the ICU library and the code Stefan Bidigaray added 
to use it recently.
Perhaps he can say why a change of locale should make the tests fail  ... that 
might be normal/correct behavior of the API (in which case I guess we need to 
improve the tests), or it might be some simple change to the code is required 
to get the ICU code to behave consistently.