I'm still trying to figure out what GNUstep is doing differently from the tests I'm sending you. As far as I can tell, the results should be identical. We really do not do anything particularly special. Short of having you step through the methods step-by-step, checking results along the way, I don't know what to do.
I'm going to install FreeBSD in a VM and more thoroughly check this out. It might be a few days until I get ti all done. In the mean time, I fixed the test. It's attached. On Thu, Sep 14, 2017 at 4:45 PM, Edwin Ancaer <[email protected]> wrote: > Stefan, > > the result remains correct, but now I had 2 warnings when compiling. I > don't know if that has any meaning though. > > [edwin@ottopedi ~/ICUTest]$ cc test_icu.c `icu-config --ldflags > --ldflags-icuio`-I/usr/local/include > test_icu.c:15:13:* warning:* implicit declaration of function > 'u_strFromUTF8' is invalid in C99 [-Wimplicit-function-declaration] > pattern = u_strFromUTF8 (buffer, 128, NULL, "yyyyMMdd hh:mm", 14, status); > ^ > test_icu.c:15:11: *warning:* incompatible integer to pointer conversion > assigning to 'UChar *' (aka 'unsigned short *') from 'int' > [-Wint-conversion] > pattern = u_strFromUTF8 (buffer, 128, NULL, "yyyyMMdd hh:mm", 14, > status); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~ > 2 warnings generated. > [edwin@ottopedi ~/ICUTest]$ ls -al > total 24 > drwxr-xr-x 2 edwin edwin 512 Sep 14 22:41 . > drwxr-xr-x 38 edwin edwin 3072 Sep 14 22:41 .. > -rwxr-xr-x 1 edwin edwin 7174 Sep 14 22:41 a.out > -rw-r--r-- 1 edwin edwin 1462 Sep 14 22:40 test_icu.c > -rw-r--r-- 1 edwin edwin 1334 Sep 14 22:39 test_icu1.c > [edwin@ottopedi ~/ICUTest]$ > [edwin@ottopedi ~/ICUTest]$ ./a.out > Date Formatted with defaults: 20170914 10:41 p.m. > Date Formatted with defaults: 14 sep. 2017 > Date Formatted with defaults: 14 september 2017 om 22:41:38 CEST > > I you have any ideaes about things that I could try to shed some light on > this.... > > Kind regards, > > Edwin > > > 2017-09-14 22:23 GMT+02:00 Stefan Bidigaray <[email protected]>: > >> Hmm... There definitely something wrong in GNUstep, then. The question is >> what!? Looking at the code, I'm not entirely sure what could be happening, >> and why your system is giving different results than mine. You are using >> ICU version 58.2, so I'm wondering if some behavior changed between what I >> have (version 55.1) and the later ICU releases. >> >> I modified the previous test to verify that your version of ICU does the >> same thing as previous releases. Can you please recheck? Maybe later >> versions are be choosing the pattern over the styles. This is the only >> thing I can think of, right now. >> >> Thanks >> >> On Sep 14, 2017 15:47, "Edwin Ancaer" <[email protected]> wrote: >> >>> Stefan, >>> >>> the result is correct now >>> >>> [edwin@ottopedi ~/ICUTest]$ ./a.out >>> >>> Date Formatted with defaults: 20170914 09:40 p.m. >>> Date Formatted with defaults: 14 sep. 2017 >>> Date Formatted with defaults: 14 september 2017 om 21:40:33 CEST >>> >>> Does this mean the problem is in my GNUstep installation? >>> >>> Kind regards, >>> >>> >>> 2017-09-14 18:28 GMT+02:00 Stefan Bidigaray <[email protected]>: >>> >>>> Hi Edwin, >>>> The attached test does something very similar to GNUstep, and you >>>> should get the same answers. Can you check this out and report back? >>>> >>>> To build: >>>> cc test_icu.c `icu-config --ldflags --ldflags-icuio` >>>> >>>> My results: >>>> Date Formatted with defaults: 20170914 12:26 p.m. >>>> Date Formatted with defaults: 14 sep. 2017 >>>> Date Formatted with defaults: 14 september 2017 12:26:33 GMT-4 >>>> >>>> Regards >>>> >>>> On Thu, Sep 14, 2017 at 11:45 AM, Stefan Bidigaray < >>>> [email protected]> wrote: >>>> >>>>> I'll come up with a test for ICU and post it here. I'll make sure to >>>>> use the same functions used by GNUstep to verify. >>>>> >>>>> I'm still betting the problem is in your ICU installation. The GNUstep >>>>> code is a thin layer on top of ICU, it's unlikely that the problem lies >>>>> there. I'm not saying impossible, just unlikely. >>>>> >>>>> On Sep 14, 2017 11:38, "Edwin Ancaer" <[email protected]> wrote: >>>>> >>>>>> Stefan, >>>>>> >>>>>> I did, and the test returns the same wrong results: >>>>>> >>>>>> 2017-09-14 17:26:09.914 DateFormatter[80496:100318] the date as date >>>>>> object 2017-09-14 17:26:09 +0200 >>>>>> 2017-09-14 17:26:09.953 DateFormatter[80496:100318] Dateformatter >>>>>> defaults >>>>>> 2017-09-14 17:26:09.970 DateFormatter[80496:100318] DateFormatter >>>>>> timezone: Europe/Brussels >>>>>> 2017-09-14 17:26:09.986 DateFormatter[80496:100318] DateFormatter >>>>>> locale: nl_BE >>>>>> 2017-09-14 17:26:10.003 DateFormatter[80496:100318] DateFormatter >>>>>> datestyle: 0 >>>>>> 2017-09-14 17:26:10.020 DateFormatter[80496:100318] DateFormatter >>>>>> timestyle: 0 >>>>>> 2017-09-14 17:26:10.023 DateFormatter[80496:100318] Date formatted >>>>>> with defaults 20170914 05:26 p.m. >>>>>> 2017-09-14 17:26:10.027 DateFormatter[80496:100318] DateFormatter: >>>>>> Date -> NoStyle, Time -> MediumStyle >>>>>> 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter >>>>>> timezone: Europe/Brussels >>>>>> 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter >>>>>> locale: nl_BE >>>>>> 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter >>>>>> datestyle: 0 >>>>>> 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter >>>>>> timestyle: 2 >>>>>> 2017-09-14 17:26:10.028 DateFormatter[80496:100318] Date formatted >>>>>> with style 20170914 05:26 p.m. >>>>>> 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter: >>>>>> Date -> LongStyle, Time -> LongStyle >>>>>> 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter >>>>>> timezone: Europe/Brussels >>>>>> 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter >>>>>> locale: nl_BE >>>>>> 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter >>>>>> datestyle: 3 >>>>>> 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter >>>>>> timestyle: 3 >>>>>> 2017-09-14 17:26:10.028 DateFormatter[80496:100318] Date formatted >>>>>> with style 20170914 05:26 p.m. >>>>>> >>>>>> Could i run a C-program that formatted the date with locale nl and >>>>>> conclude >>>>>> - the problem is in my ICU installation if the result of the >>>>>> program is wrong? >>>>>> - the problem is in my GNUstep installation if the result of the >>>>>> program is OK? >>>>>> >>>>>> Kind regards >>>>>> >>>>>> 2017-09-14 17:05 GMT+02:00 Stefan Bidigaray <[email protected]>: >>>>>> >>>>>>> Hi Edwin, >>>>>>> From everything you've said so far, the problem doesn't seem to be >>>>>>> in GNUstep. The method you are using would return nil if ICU wasn't >>>>>>> installed. Additionally, the return value is what you'd expect from the >>>>>>> en_US_POSIX locale, the default in FreeBSD. >>>>>>> >>>>>>> With that in mind, have you tried explicitly setting the formatter's >>>>>>> locale using the -setLocale: method? It's possible your setup is falling >>>>>>> back to the systemLocale, which would be a separate problem. >>>>>>> >>>>>>> Have you tried running the test I attached in my previous email? >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> On Sep 14, 2017 10:38, "Edwin Ancaer" <[email protected]> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I return from holidays that have been haunted by this problem :-). >>>>>>>> >>>>>>>> I asked about libicudata.so on the freebsd list. The answer was " >>>>>>>> >>>>>>>> >>>>>>>> *devel/icu is built --with-data-packaging=archive which means the >>>>>>>> data ends up in icudt* file e.g., $ pkg info -l icu | fgrep icudt | >>>>>>>> xargs >>>>>>>> du -Ah 25M /usr/local/share/icu/58.2/**icudt58l.dat*" >>>>>>>> >>>>>>>> We compared the necessary ICU libraries and they all are present at >>>>>>>> my side, with more or less equal sizes. >>>>>>>> >>>>>>>> In the config.log file for gnustep base, I found: >>>>>>>> ... >>>>>>>> HAVE_GNUTLS='1' >>>>>>>> *HAVE_ICU='1'* >>>>>>>> HAVE_INET_NTOP='yes' >>>>>>>> HAVE_INET_PTON='yes' >>>>>>>> HAVE_LIBDISPATCH='1' >>>>>>>> HAVE_LIBXML='1' >>>>>>>> HAVE_LIBXSLT='1' >>>>>>>> HAVE_MDNS='0' >>>>>>>> HAVE_OBJC_SYNC_ENTER='yes' >>>>>>>> ... >>>>>>>> >>>>>>>> This seems to indicate ICU is used. Just to be sure, I added >>>>>>>> >>>>>>>> #if GS_USE_ICU == 1 >>>>>>>> NSLog(@" GS USE ICU == 1"); >>>>>>>> #endif >>>>>>>> >>>>>>>> to my program, and effectively, the display appeared: >>>>>>>> >>>>>>>> 2017-09-14 11:04:41.625 TM1[79500:100088] GS USE ICU == 1 >>>>>>>> >>>>>>>> I tried debugging, but from a recent conversation on this list, it >>>>>>>> seems I need a port gdb80, that is not present in my FreeBSD 11.0 ports >>>>>>>> directory (have got gdb and gdb66). >>>>>>>> >>>>>>>> I must be missing something obvious, but for now, I'm rather stuck. >>>>>>>> Problems like this make one feel utterly stupid. >>>>>>>> >>>>>>>> Would you have any suggestions left? >>>>>>>> >>>>>>>> (I already reinstalled the icu and gnustep base ports, no errors >>>>>>>> detected, no change in the result). >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> >>>>>>>> Edwin. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Discuss-gnustep mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >>>>>>>> >>>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Discuss-gnustep mailing list >>>>>> [email protected] >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >>>>>> >>>>>> >>>> >>> >
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
