Re: Adopt a platform today!

[Fred Kiefer]

Hi Richard,

thank you for fixing this problem and even more for your great work on
the test framework.
My test results are now a bit better:

  5456 Passed tests
     28 Failed tests
      5 Skipped sets
      1 Dashed hope

All of the failed tests have to do with formatting stuff, so most likely
it is mostly the missing ICU that is causing them. I am not surely
convinced that the NSNumberFormatter basic tests should fail for me. So
I tried to run these manually:

core/base/Tests # gnustep-tests base/NSNumberFormatter/basic.m
--- Running tests in base/NSNumberFormatter ---

base/NSNumberFormatter/basic.m:
Failed script:   base/NSNumberFormatter/basic.m

      1 Failed script

And in the tests.log I find:

Testing base/NSNumberFormatter/basic.m...
ERROR: /usr/GNUstep/System/Library/Makefiles/TestFramework/runtest.sh:
Test file (base/NSNumberFormatter/basic.m) does not exist
Failed script:   base/NSNumberFormatter/basic.m

Looks like there is still something wrong here even in latest SVN test code.


When I run this test via
core/base/Tests # gnustep-tests base/NSNumberFormatter

I get:

Testing basic.m...
This is gnustep-make 2.4.0. Type 'gmake print-gnustep-make-help' for help.
Making all for test_tool basic...
 Compiling file basic.m ...
 Linking test_tool basic ...
Running basic.m...
This is gnustep-make 2.4.0. Type 'gmake print-gnustep-make-help' for help.
Passed test:     +[NSNumberFormatter alloc] returns a NSNumberFormatter
Failed test:     basic.m:22 ... default format same as Cocoa
Expected '1,234.57' and got '(null)'

It turns out that the NSNumberFormatter is already null and that the
test in the -init method whether the _formatter isn't nil should only be
run for the ICU case. I understand that it is very hard to test code for
the non-ICU case, when you already have this library installed.

Cheers
Fred

Am 19.02.2011 16:10, schrieb Fred Kiefer:
> Without ICU installed I get the following results from the base test
> suite on an OpenSuse 11.3 64-bit system. (GNUstep freshly from SVN) I am
> using gcc 4.5.0 and the libobjc that comes along with it:
> 
>    5456 Passed tests
>      34 Failed tests
>       5 Skipped sets
>       1 Dashed hope
> 
> The first fail is this one:
> 
> base/NSBundle/general.m:
> Failed test:     general.m:24 ... -principalClass returns NSObject for
> the +bundleForLibrary:gnustep-base
> 
> Running the NSBundle tests separately gives the following log file:
> 
>  Compiling file general.m ...
> general.m: In function ‘main’:
> general.m:23:3: warning: cast from pointer to integer of different size
> general.m:23:3: warning: comparison between pointer and integer
> general.m:32:3: warning: cast from pointer to integer of different size
> general.m:32:3: warning: comparison between pointer and integer
> general.m:35:3: warning: cast from pointer to integer of different size
> general.m:35:3: warning: comparison between pointer and integer
> general.m:68:3: warning: cast from pointer to integer of different size
> general.m:68:3: warning: comparison between pointer and integer
> general.m:73:3: warning: cast from pointer to integer of different size
> general.m:73:3: warning: comparison between pointer and integer
>  Linking test_tool general ...
> Running base/NSBundle/general.m...
> This is gnustep-make 2.4.0. Type 'gmake print-gnustep-make-help' for help.
> Passed test:     +bundleForLibrary: makes a bundle for us
> Failed test:     general.m:24 ... -principalClass returns NSObject for
> the +bundleForLibrary:gnustep-base
> 
> This looks like a 64 bit issue and I would say it is caused by the PASS
> macros missing a few brackets. In Testing.h we have:
> 
>      _cond = (int) expression; \
> 
> Which definitely should be
> 
>      _cond = (int)(expression); \
> 
> But why are we using the local copy at all?
> All the other macros in that file look a bit fragile as well.