Nope, it is not. The issue arises when "unum_formatDouble" is called
inside NSNumberFormatter, which converts a double to a string
representation, and it always returns a string containing "NaN".
Stefan's standalone test program does work, but inside
NSNumberFormatter something gets terribl
Am 06.03.2011 um 18:57 schrieb ici...@mail.cg.tuwien.ac.at:
Hi,
icicle@nordpol-laptop:~/Desktop/ICUtest$ gcc `icu-config --cflags`
`icu-config --ldflags` -licuio -o test test_unum.c
test_unum.c:6: Warnung: Rückgabetyp von »main« ist nicht »int«
icicle@nordpol-laptop:~/Desktop/ICUtest$ ./tes
I tackled that one, now it looks like in NSNumberFormatter's -
(NSString*) stringForObjectValue: (id)anObject method. Something in
the STRING_FROM_NUMBER macro is failing and returning NaN. I am trying
to narrow it down.
TOM
Quoting Stefan Bidi :
I really don't know what the problem is.
I really don't know what the problem is. It looks like objc_msg_lookup is
being called with receiver = 0x0, that will certainly return a bogus method
(nil_method).
On Sun, Mar 6, 2011 at 12:33 PM, wrote:
> Ouch, looks like something else entirely:
>
> 107 [fmt setNumberStyle: NSNumber
Whatever is going on, I do not have a clue. Now I simply took some
code from the test case you sent me, pasted it right into
@implementation NSNumberFormatter (PrivateMethods)
- (void) _resetUNumberFormat
{
#if GS_USE_ICU == 1
UNumberFormatStyle style;
UErrorCode err = U_ZERO_ERROR;
const
Hi!
icicle@nordpol-laptop:~/Desktop/ICUtest$ gcc `icu-config --cflags`
`icu-config --ldflags` -licuio -o test test_unum.c
test_unum.c:6: Warnung: Rückgabetyp von »main« ist nicht »int«
icicle@nordpol-laptop:~/Desktop/ICUtest$ ./test
1.234,56 = 1234.56
1.234 = 1234
The decimal separator ha
Ouch, looks like something else entirely:
107 [fmt setNumberStyle: NSNumberFormatterPercentStyle];
(gdb)
108 testHopeful = YES;
(gdb)
109 PASS_EQUAL([fmt stringFromNumber: num], @"_123,443##",
(gdb) po num
-1234.43
(gdb) po fmt
(gdb) s
objc_msg_lookup (receiver=0x0,
I'm not really sure. I was hoping this test would return NaN as well. Try
this other test. Before, I used NULL (default locale) in the tests and now
it explicitly chooses "en", same as the GNUstep tests. I'm hoping libicu
will return NaN this time.
On Sun, Mar 6, 2011 at 11:57 AM, wrote:
> H
Hi,
icicle@nordpol-laptop:~/Desktop/ICUtest$ gcc `icu-config --cflags`
`icu-config --ldflags` -licuio -o test test_unum.c
test_unum.c:6: Warnung: Rückgabetyp von »main« ist nicht »int«
icicle@nordpol-laptop:~/Desktop/ICUtest$ ./test
1.234,56 = 1234,56
1.234 = 1234
Could it be a Locale is
Hmm... The results you're getting are quite strange. The only time these
method returns NaN is if the object is not a NSNumber. If it is, than we
just send it through icu to get converted. The problem here is that either
libicu is returning 'NaN' for these values or NSNumber is return nil.
Coul
Hi!
Test results, lots of NSNumberFormatter fails. I am using ICU 4.6.
Cheers,
TOM
Building in NSNumberFormatter
This is gnustep-make 2.4.0. Type 'make print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.
Making all for test_tool basic10_4...
Making all for test_t
On 5 Mar 2009, at 20:53, David Wetzel wrote:
Hi folks,
I tried the test suite on a NetBSD amd64 VM:
runtests.sh base
--- Running tests in base ---
base/NSBundle/general.m:
FAIL: -classNamed returns the correct class
FAIL: -executablePath returns an executable path (gnustep bundle)
These
Hi folks,
I tried the test suite on a NetBSD amd64 VM:
runtests.sh base
--- Running tests in base ---
base/NSBundle/general.m:
FAIL: -classNamed returns the correct class
FAIL: -executablePath returns an executable path (gnustep bundle)
base/NSConnection/connection.m:
FAIL: NSConnection can
13 matches
Mail list logo
