Stefan,
I'll try to rebuild as soon as possible.
Thanks a lot,
Edwin
Op 25 okt. 2017 00:27 schreef "Stefan Bidigaray" :
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
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 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,
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
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
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
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
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
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
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
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,
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
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
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
Hi Edwin,
There must be something wrong with your installation. I created the
attached tests (simply copied yours) and I'm getting the correct output. I
even set the locale to nl_BE, in case that was the problem.
My output was:
2017-08-26 11:28:59.892 a.out[2724:2724] the date as date
object
Hmm, that does seem stage. It should all be working. I'm sure the problem
is not the FreeBSD source, David does a pretty good job keeping those
updated.
I'll test it on my end a bit to try to figure it out.
On Aug 26, 2017 00:46, "Edwin Ancaer" wrote:
> Fred, Stefan,
>
>
Fred, Stefan,
Indeed, the instruction [format lenient] returns 1, independant of setting
the value with
[format setLenient: NO] and [format setLenient: YES].
I'm sure I saw libicu mentioned in the dependencies for gnustep, and given
the definition of isLenient in NSDatformatter.m and the fact
Based on your previous posts, it sounds like your current locale is
en_US_POSIX. Can you verify that by checking the output of [NSDateFormatter
-locale]? This locale outputs the same date string regardless of the style.
You can set the formatter's locale with -setLocale: before any calls to
Hi Edwin,
could you please check whether this version of GNUstep was compiled with ICU
support? The easiest way to do so is to print out the value of [format
isLenient] next set it to a different value (if you get 0/NO set it to YES, if
you get 1/YES set it to NO) [format setLenient: YES] and
Hello,
I hardly dare to suggest it, but I have got the impression that the methods
setDateStyle & setTimeStyle have no influence on the result of the method
stringFromDate, as you can see in the examples below.
Is it me, again not having understood the workings of these classes
completely, or is
19 matches
Mail list logo