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 char *cLocaleId;
if (internal->_formatter)
unum_close(internal->_formatter);
cLocaleId = [[internal->_locale localeIdentifier] UTF8String];
style = NSToICUFormatStyle (internal->_style);
internal->_formatter = unum_open (style, NULL, 0, cLocaleId, NULL, &err);
if (U_FAILURE(err))
internal->_formatter = NULL;
// stupid test
UChar buffer[256];
double d = 1234.56;
int i = 1234;
UNumberFormat *fmt;
// it does not seem to matter which locale I do use, so
// simply supply nothing
fmt = unum_open(UNUM_IGNORE, NULL, 0, NULL, NULL, &err);
int32_t r = unum_formatDouble(fmt, d, buffer, 256, NULL, &err);
// print number and th result string length
fprintf(stdout, "%f %d\n", d, r);
//
[self setMaximumFractionDigits: 0];
#else
return;
#endif
}
and it does NOT work. It works as standalone program, but not inside
NSNumberFormatter. I am really confused...
TOM
Quoting Stefan Bidi <stefanb...@gmail.com>:
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, <ici...@mail.cg.tuwien.ac.at> wrote:
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
<NSNumberFormatter: 0x8f4cb0>
(gdb) s
objc_msg_lookup (receiver=0x0, selector=0x612390) at sendmsg2.c:330
330 {
Current language: auto; currently c
(gdb) bt
#0 objc_msg_lookup (receiver=0x0, selector=0x612390) at sendmsg2.c:330
#1 0x000000000040afd9 in main () at basic10_4.m:109
(gdb) s
331 if (nil == receiver) { return (IMP)nil_method; }
Looks like the runtime does not find the string formatters methods,
therefore garbage is returned.
I am using the GNUstep runtime from SVN trunk.
TOM
Quoting Stefan Bidi <stefanb...@gmail.com>:
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, <ici...@mail.cg.tuwien.ac.at> wrote:
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,560000 = 1234,56
1.234 = 1234
Could it be a Locale issue, since my Ubuntu uses a german one
(LANG="de_DE.UTF-8")? As I did a clean install of GNUstep today I did not
set a time zone or language yet, maybe that's an issue.
TOM
Quoting Stefan Bidi <stefanb...@gmail.com>:
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.
Could you run and report the output of the attach test? I just want to
make
sure libicu is doing it's thing correctly. To build it: gcc `icu-config
--ldflags` -licuio test_unum.c
Thanks
On Sun, Mar 6, 2011 at 7:02 AM, <ici...@mail.cg.tuwien.ac.at> wrote:
Hi!
Test results, lots of NSNumberFormatter fails. I am using ICU 4.6.
Cheers,
TOM
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
