I think that might be the case. The only thing I can think of is that a call to malloc is failing inside ICU. On Nov 28, 2012 11:34 AM, "Gregory Casamento" <[email protected]> wrote:
> Sorry, forgot to forward to the list... > > GC > > ---------- Forwarded message ---------- > From: Gregory Casamento <[email protected]> > Date: Wed, Nov 28, 2012 at 12:31 PM > Subject: Re: Issue with NSDateFormatter on Windows with ICU... > To: Stefan Bidi <[email protected]> > > > Yes, that's correct I am using mingw. Here is the information: > > > heron@glados-vm-win7 ~ > $ gcc test_udat.c -lpthread -lm -L/mingw/bin -licui18n -licuuc > -licudata -l > pthread -lm > > heron@glados-vm-win7 ~ > $ a.exe > (1) Error Code: U_MEMORY_ALLOCATION_ERROR > (2) Error Code: U_MEMORY_ALLOCATION_ERROR > > heron@glados-vm-win7 ~ > $ icu-config --version > 4.6 > > heron@glados-vm-win7 ~ > $ > > > On Wed, Nov 28, 2012 at 12:20 PM, Stefan Bidi <[email protected]>wrote: > >> Assuming you are running the gnustep mingw environment, you should be >> able to use icu-config --ldflags. I can't remember where icu-config is on >> windows and I no longer have a windows install to check. >> On Nov 28, 2012 11:14 AM, "Gregory Casamento" <[email protected]> >> wrote: >> >>> Sorry I was delayed on getting back to this. Work and sleep >>> interfered. I ran the tests, same issue. The problem is in the >>> initialization code of NSDateFormatter itself, not in how Gorm is >>> initializing it. >>> >>> I got your test program... the only issue is that I can't figure out >>> WHERE ICU is installed on windows so that I can give the correct directive >>> to gcc via -L. Any idea? >>> >>> GC >>> >>> >>> On Tue, Nov 27, 2012 at 9:10 PM, Stefan Bidi <[email protected]>wrote: >>> >>>> Greg, >>>> Can you compile and run the attached test. It is really simple and >>>> will say if the ICU lib on your system is working or not. >>>> >>>> On Tue, Nov 27, 2012 at 6:53 PM, Stefan Bidi <[email protected]> >>>> wrote: >>>> > Greg, what happens if you run the NSDateFormatter tests? Does >>>> > everything still crash? >>>> > >>>> > I'll prepare a set of tests to exercise the ICU functionality. That >>>> > might help figure out what is going on here. Which version of the ICU >>>> > and base are you using? >>>> > >>>> > On Tue, Nov 27, 2012 at 3:43 PM, Gregory Casamento >>>> > <[email protected]> wrote: >>>> >> Same result. >>>> >> >>>> >> >>>> >> On Tue, Nov 27, 2012 at 2:02 PM, Stefan Bidi <[email protected]> >>>> wrote: >>>> >>> >>>> >>> No, this is correct. ICU requires Unicode for time zones. >>>> >>> >>>> >>> The thing is that ICU does not recognize the Windows timezone >>>> names, they >>>> >>> must be in the Olson format. >>>> >>> >>>> >>> A work around might be to set that to null for now and see if that >>>> works. >>>> >>> >>>> >>> On Nov 27, 2012 12:25 PM, "Richard Frith-Macdonald" >>>> >>> <[email protected]> wrote: >>>> >>>> >>>> >>>> >>>> >>>> On 27 Nov 2012, at 18:18, Gregory Casamento wrote: >>>> >>>> >>>> >>>> > >>>> >>>> > Here is what is being sent.... >>>> >>>> > >>>> >>>> > (gdb) p *(NSDateFormatterInternal *)_internal >>>> >>>> > $3 = {{isa = 0x6702f740}, _behavior = 0, _locale = 0x41f9a28, >>>> >>>> > _tz = 0x278ce08, _timeStyle = 0, _dateStyle = 0, _formatter = >>>> 0x0} >>>> >>>> > (gdb) p NSToUDateFormatStyle(0) >>>> >>>> > $4 = -1 >>>> >>>> > (gdb) po ((NSDateFormatterInternal *)_internal)->_locale >>>> >>>> > en_US >>>> >>>> > (gdb) p tzID >>>> >>>> > $6 = ( >>>> >>>> > UChar *) 0x4202b80 "E\000a\000s\000t\000e\000r\000n\000 >>>> >>>> > \000S\000t\000a\000n >>>> >>>> > \000d\000a\000r" >>>> >>>> >>>> >>>> The thing that strikes me instantly is that we are looking at >>>> unicode >>>> >>>> (16bit characters). >>>> >>>> Could it be that the ICU library routine is expecting ascii or >>>> utf-8, but >>>> >>>> because windows uses 16bit characters natively it's getting >>>> confused? >>>> >>>> If so, that would be easy to fix. >>>> >>>> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Gregory Casamento >>>> >> Open Logic Corporation, Principal Consultant >>>> >> yahoo/skype: greg_casamento, aol: gjcasa >>>> >> (240)274-9630 (Cell) >>>> >> http://www.gnustep.org >>>> >> http://heronsperch.blogspot.com >>>> >>> >>> >>> >>> -- >>> Gregory Casamento >>> Open Logic Corporation, Principal Consultant >>> yahoo/skype: greg_casamento, aol: gjcasa >>> (240)274-9630 (Cell) >>> http://www.gnustep.org >>> http://heronsperch.blogspot.com >>> >> > > > -- > Gregory Casamento > Open Logic Corporation, Principal Consultant > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell) > http://www.gnustep.org > http://heronsperch.blogspot.com > > > > -- > Gregory Casamento > Open Logic Corporation, Principal Consultant > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell) > http://www.gnustep.org > http://heronsperch.blogspot.com > > _______________________________________________ > Gnustep-dev mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnustep-dev > >
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
