discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep-corebase to be released next week


From: Fred Kiefer
Subject: Re: GNUstep-corebase to be released next week
Date: Wed, 18 Jul 2012 22:39:27 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0

For me (OpenSuse 64bit AMD) the only failing test is this one:

Failed test:     format.m:28 ... Float/Doubles are formatted correctly
expected 5.500000 5.5   3.000000e-06, but got 5,500000 5,5   3,000000e-06

This definitely is a problem of the locale, you should have a look at the base test in NSNumberFormatter/basic10_4.m on how to ensure a specific locale for the test.

Fred

On 18.07.2012 09:47, Sebastian Reitenbach wrote:

On Wednesday, July 18, 2012 01:44 CEST, Stefan Bidi <stefanbidi@gmail.com> 
wrote:

I believe I fixed the at least some of the failing tests.  I made
CFNumber test more verbose to get some insight in what is going on.
The CFString formating tests will be a little more tricky, this most
likely has to do with how ppc passes arguments.  Unfortunately, I have
no idea where to even start fixing this error.

yep, I looked a bit into it, and it seems, this needs some byte swapping, 
depending
on CFByteOrderGetCurrent() or the like. I'll also look into it later today.

So far, all, besides this timezone name now work for me on i386 and amd64.
on macppc, only the following fails:

Running Tests/CFNumber/general.m...
Failed test:     general.m:24 ... SInt32 converted to SInt8 (251) correctly.
Running Tests/CFString/format.m...
Failed test:     format.m:14 ... Characters are formatted correctly
expected r un, but got
Failed test:     format.m:50 ... Strings are formatted correctly
expected 0xc A longer than usual string., but got 0x0 A longer than usual 
string.
Failed test:     general.m:40 ... Standard localized name is correct.
expected Central European Time, but got Central European Standard Time


The pthread thing should also be resolved, please give it another shot.

Yes, works for me, as long as I don't have LIBS defined in configure 
environment.
I patched configure.ac again to fix that, a space is missing ;)

But I've seen to detect the objc_getClass, you took the easy route.
What if someone installs libobjc2 so that it must be linked with:
-li-give-a-fuck-how-i-call-the-runtime
then your test will fail again. Therefore I suggested to use input from
gnustep-config --objc-libs
I'm not good with this autoconf, but if you don't mind, I'll take a look at it 
also.

So the patch below fixes:
  - the configure mentioned above
  - a couple "no newline at the end of file" compiler warnings
  - and in CFStringFormat.c, the warning:
   CFStringFormat.c: In function '_CFStringAppendFormatAndArgumentsAux':
   CFStringFormat.c:1057: warning: comparison is always false due to limited 
range of data type

but actually, I don't know why you don't put the CFUnknownType, or define it as 
UINT16_MAX?
then this weirdo casting I'm doing might not be necessary, which I doubt may 
not even be right.

cheers,
Sebastian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]