From: Eli Zaretskii <eliz@gnu.org>
To: ludo@gnu.org
Cc: guile-devel@gnu.org
Subject: Re: MinGW vs. setlocale
Date: Sun, 15 Jun 2014 20:23:17 +0300 [thread overview]
Message-ID: <83ppiaulx6.fsf@gnu.org> (raw)
In-Reply-To: <83fvjaxa7o.fsf@gnu.org>
> Date: Thu, 12 Jun 2014 21:18:51 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> CC: guile-devel@gnu.org
>
> I still have one problem left: the Turkish character-mapping tests
> are failing. I think that's because somehow the LC_ALL environment
> variable gets set to "C". With the current libunistring code, that
> setting in the environment overrides what's been set by 'setlocale',
> and the Turkish language rules are not used.
>
> I will fix this in libunistring
Done, and all the tests in i18n.test now pass on Windows. But I also
needed another small change in i18n.c, see below.
> By the way, how do I run a single test from test-suite?
I'd still love to know the answer to this one.
> > >> --8<---------------cut here---------------start------------->8---
> > >> scheme@(guile-user)> ,m (ice-9 i18n)
> > >> scheme@(ice-9 i18n)> (locale-decimal-point (make-locale LC_ALL "fr_FR"))
> > >> $2 = ","
> > >> scheme@(ice-9 i18n)> (locale-thousands-separator (make-locale LC_ALL "fr_FR"))
> > >> $3 = " "
> > >> --8<---------------cut here---------------end--------------->8---
> > >
> > > I did try that, and saw a strange thing: the thousands separator is
> > > displayed as "\xa0". That is very strange, because nl_langinfo does
> > > return " " for the French locale, as expected. Why would the blank be
> > > translated into NBSP? Can this also be due to libunistring problems?
> >
> > NBSP is actually a better answer than just space, because it’d be unwise
> > to introduce a break in the middle of a number.
>
> But nl_langinfo returns a blank. So who converts that to NBSP?
Answering myself here: no one. What I thought was a blank was
actually NBSP (which was displayed as blank by GDB), that's what the
Windows French locale returns as the thousands separator. I guess
i18n.test shouldn't assume the separator is a blank, but should
instead use the actual character.
> > So does ‘number->locale-string’ return "123\xa0456" for you?
>
> No, I get "123456". I will revisit this after I finish fixing
> libunistring,
Revisited and fixed. It turned out i18n.scm needed to be recompiled,
because it records the supported values of nl_langinfo arguments in
the .go file. So whenever more supported values are added to
nl_langinfo (which was what I did for GROUPING), i18n.scm should be
recompiled. (Shouldn't this happen automatically?)
> > >> > UNRESOLVED: i18n.test: format ~h: French: 12345.5678
> > >> > UNRESOLVED: i18n.test: format ~h: English: 12345.5678
> > >> >
> > >> > ~h is not supported on Windows.
> > >>
> > >> ~h is implemented using ‘number->locale-string’.
> > >
> > > Maybe I'm confused, but isn't ~h about position directive in formats?
> >
> > Yes, but that’s implemented in Scheme, in ice-9/format.scm.
>
> Thanks for the pointer, I guess I will need to take a better look at
> that.
Once i18n.scm was recompiled, the ~h format test also started working.
There are a couple of other locale-related tests that fail on Windows,
like the one that reads Unicode text from strings. I decided not to
fix those, because they test a fundamentally non-portable operation.
Here are the changes I needed for i18n.c to get the tests to succeed.
They have to do with non-portable assumptions about when the various
nl_langinfo constants are defined. E.g., there's no reason to assume
that if INT_FRAC_DIGITS isn't defined, neither will be FRAC_DIGITS.
As luck would have it, MinGW has some of these, but not the others, so
the conditionals failed, and Guile failed to convert P_SIGN_POSN to
one of the symbolic values, instead leaving it at its numerical value.
--- libguile/i18n.c~2 2014-06-15 14:21:53 +0300
+++ libguile/i18n.c 2014-06-15 14:58:09 +0300
@@ -1583,9 +1583,13 @@ SCM_DEFINE (scm_nl_langinfo, "nl-langinf
}
#endif
-#if (defined FRAC_DIGITS) && (defined INT_FRAC_DIGITS)
+#if defined FRAC_DIGITS || defined INT_FRAC_DIGITS
+#ifdef FRAC_DIGITS
case FRAC_DIGITS:
+#endif
+#ifdef INT_FRAC_DIGITS
case INT_FRAC_DIGITS:
+#endif
/* This is to be interpreted as a single integer. */
if (*c_result == CHAR_MAX)
/* Unspecified. */
@@ -1597,12 +1601,18 @@ SCM_DEFINE (scm_nl_langinfo, "nl-langinf
break;
#endif
-#if (defined P_CS_PRECEDES) && (defined INT_N_CS_PRECEDES)
+#if defined P_CS_PRECEDES || defined N_CS_PRECEDES || \
+ defined INT_P_CS_PRECEDES || defined INT_N_CS_PRECEDES || \
+ defined P_SEP_BY_SPACE || defined N_SEP_BY_SPACE
+#ifdef P_CS_PRECEDES
case P_CS_PRECEDES:
case N_CS_PRECEDES:
+#endif
+#ifdef INT_N_CS_PRECEDES
case INT_P_CS_PRECEDES:
case INT_N_CS_PRECEDES:
-#if (defined P_SEP_BY_SPACE) && (defined N_SEP_BY_SPACE)
+#endif
+#ifdef P_SEP_BY_SPACE
case P_SEP_BY_SPACE:
case N_SEP_BY_SPACE:
#endif
@@ -1613,11 +1623,16 @@ SCM_DEFINE (scm_nl_langinfo, "nl-langinf
break;
#endif
-#if (defined P_SIGN_POSN) && (defined INT_N_SIGN_POSN)
+#if defined P_SIGN_POSN || defined N_SIGN_POSN || \
+ defined INT_P_SIGN_POSN || defined INT_N_SIGN_POSN
+#ifdef P_SIGN_POSN
case P_SIGN_POSN:
case N_SIGN_POSN:
+#endif
+#ifdef INT_P_SIGN_POSN
case INT_P_SIGN_POSN:
case INT_N_SIGN_POSN:
+#endif
/* See `(libc) Sign of Money Amount' for the interpretation of the
return value here. */
switch (*c_result)
next prev parent reply other threads:[~2014-06-15 17:23 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-08 15:04 MinGW issues in Guile 2.0.11 Eli Zaretskii
2014-06-09 15:47 ` Eli Zaretskii
2014-06-09 18:01 ` Mark H Weaver
2014-06-09 18:25 ` Eli Zaretskii
2014-06-09 19:30 ` MinGW vs. setlocale Ludovic Courtès
2014-06-10 16:17 ` Eli Zaretskii
2014-06-11 13:13 ` Ludovic Courtès
2014-06-11 15:33 ` Eli Zaretskii
2014-06-12 8:39 ` Ludovic Courtès
2014-06-12 18:18 ` Eli Zaretskii
2014-06-15 17:23 ` Eli Zaretskii [this message]
2014-06-21 11:17 ` Eli Zaretskii
2014-06-21 15:02 ` Ludovic Courtès
2014-06-21 15:11 ` Eli Zaretskii
2014-06-21 21:23 ` Ludovic Courtès
2014-06-22 16:13 ` Eli Zaretskii
2014-06-19 4:53 ` Doug Evans
2014-06-19 8:16 ` Ludovic Courtès
2014-06-09 19:32 ` MinGW vs. c-api.test Ludovic Courtès
2014-06-10 9:05 ` Neil Jerram
2014-06-10 11:42 ` Ludovic Courtès
2014-06-10 15:32 ` Eli Zaretskii
2014-06-10 15:56 ` David Kastrup
2014-06-10 18:00 ` Eli Zaretskii
2014-06-11 0:36 ` dsmich
2014-06-11 2:52 ` Eli Zaretskii
2014-06-10 11:44 ` Ludovic Courtès
2014-06-10 15:39 ` Eli Zaretskii
2014-06-11 12:37 ` Ludovic Courtès
2014-06-11 15:08 ` Eli Zaretskii
2014-06-12 8:29 ` Ludovic Courtès
2014-06-12 17:16 ` Eli Zaretskii
2014-06-12 19:48 ` Ludovic Courtès
2014-06-12 19:59 ` Eli Zaretskii
2014-06-12 21:20 ` Ludovic Courtès
2014-06-13 9:15 ` Neil Jerram
2014-06-13 16:04 ` Ludovic Courtès
2014-06-13 16:19 ` Eli Zaretskii
2014-06-13 16:26 ` Neil Jerram
2014-06-13 16:31 ` Mike Gerwitz
2014-06-13 18:09 ` Eli Zaretskii
2014-06-09 19:42 ` Windows file name separators Ludovic Courtès
2014-06-10 16:00 ` Eli Zaretskii
2014-06-30 11:15 ` Ludovic Courtès
2014-06-30 14:56 ` Eli Zaretskii
2014-07-01 9:36 ` Ludovic Courtès
2014-07-01 15:30 ` Eli Zaretskii
2014-07-01 15:38 ` Ludovic Courtès
2014-07-02 16:04 ` Eli Zaretskii
2014-07-02 20:56 ` Ludovic Courtès
2014-07-02 20:57 ` Ludovic Courtès
2014-07-03 15:10 ` Eli Zaretskii
2014-07-03 17:11 ` Ludovic Courtès
2014-07-03 18:09 ` Eli Zaretskii
2014-07-07 20:53 ` Mark H Weaver
2014-07-08 2:37 ` Eli Zaretskii
2014-07-02 16:13 ` Fix 'dirname' and 'basename' on MS-Windows Eli Zaretskii
2014-07-09 14:22 ` Ludovic Courtès
2014-07-09 14:53 ` Eli Zaretskii
2014-07-02 16:16 ` Provide reasonable stack limit " Eli Zaretskii
2014-07-02 21:02 ` Ludovic Courtès
2014-07-03 16:28 ` Eli Zaretskii
2014-07-02 16:30 ` Bug in scm_getaffinity Eli Zaretskii
2014-07-02 21:04 ` Ludovic Courtès
2014-07-03 16:31 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83ppiaulx6.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).