Stefan, I'll try to rebuild as soon as possible.
Thanks a lot, Edwin Op 25 okt. 2017 00:27 schreef "Stefan Bidigaray" <stefanb...@gmail.com>: FYI, I finally pushed the fix. Took me long enough, but it eventually got done. On Tue, Sep 19, 2017 at 3:58 AM, Edwin Ancaer <eanc...@gmail.com> wrote: > I managed to apply the first patch, setting the the initial dateFormat to > nil, and that did solve my problem. > I had to do it manually, maybe it did not work with the patch instruction, > because I have version 1.24.8 of gnustep-base, and the patch was made for > 1.24.9? > > The other patch failed at compilation, because I have no variable named > 'pat' in my version. of NSDateFormatter.m. > > After make check, I have no more errors in NSDate / NSDateFormatter.m. > > Can't help to feel a little proud of myself, the old dog can still learn > some new tricks.... > > > > > 2017-09-15 8:44 GMT+02:00 Fred Kiefer <fredkie...@gmx.de>: > >> There is at the moment a patch for NSDateFormatter in our bug tracker: >> http://savannah.gnu.org/bugs/?52011. It could well be that this fixes >> the issues discussed in this thread. The patch just arrived a few days ago >> and as far as I know it hasn’t been inspected by anybody. Still you could >> give it a try and report back. >> >> Hope this helps, >> Fred >> >> >> > Am 14.09.2017 um 22:58 schrieb Stefan Bidigaray <stefanb...@gmail.com>: >> > >> > 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 <eanc...@gmail.com> >> 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 <stefanb...@gmail.com>: >> > 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" <eanc...@gmail.com> 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 <stefanb...@gmail.com>: >> > 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 < >> stefanb...@gmail.com> 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" <eanc...@gmail.com> 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 <stefanb...@gmail.com>: >> > 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" <eanc...@gmail.com> 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 >> > Discuss-gnustep@gnu.org >> > https://lists.gnu.org/mailman/listinfo/discuss-gnustep >> > >> > >> > >> > _______________________________________________ >> > Discuss-gnustep mailing list >> > Discuss-gnustep@gnu.org >> > https://lists.gnu.org/mailman/listinfo/discuss-gnustep >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Discuss-gnustep mailing list >> > Discuss-gnustep@gnu.org >> > https://lists.gnu.org/mailman/listinfo/discuss-gnustep >> >> >> _______________________________________________ >> Discuss-gnustep mailing list >> Discuss-gnustep@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >> > > > _______________________________________________ > Discuss-gnustep mailing list > Discuss-gnustep@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > >
_______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
