From: "Ludovic Courtès" <ludo@gnu.org>
To: "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>
Cc: 39970@debbugs.gnu.org
Subject: bug#39970: guix commands broken on Azerbaijani 'az_AZ' and Turkish 'tr_TR' locales
Date: Thu, 12 Mar 2020 17:05:26 +0100 [thread overview]
Message-ID: <874kutsgmx.fsf@gnu.org> (raw)
In-Reply-To: <20200312110206.2hsinzejnmcefmot@pelzflorian.localdomain> (pelzflorian@pelzflorian.de's message of "Thu, 12 Mar 2020 12:02:06 +0100")
Hi Florian,
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
> On Mon, Mar 09, 2020 at 06:02:40PM +0100, Ludovic Courtès wrote:
>> To me it’s not a bug in Guile, but simply the fact that regexps, as
>> implemented by the C library, are locale-dependent.
>>
>
> (use-modules (ice-9 regex))
> (regexp-exec (make-regexp "^([a-z]+)$")
> "iyiyim")
> ⇒ #f
>
> Guile’s behavior that i is not among [a-z] has been confirmed as
> unexpected by a natively Turkish friend of mine. It is different from
> the behavior of current glibc:
>
> florian@florianmacbook ~$ cat iyiyim.c
> #include <regex.h>
> #include <stdio.h>
> #include <stdlib.h>
> #define STR "iyiyım"
> int main (int argc,
> char** argv)
> {
You’re seeing a different behavior because you forgot a:
setlocale (LC_ALL, "");
call here.
>> The patch you proposed looks good to me, though perhaps we could
>> explicitly list all the alphabet in the regexp?
>>
>> A better option is to reimplement ‘store-path-package-name’ in a way
>> similar to ‘store-path-hash-part’, as in commit
>> 35eb77b09d957019b2437e7681bd88013d67d3cd.
>
> I suppose it would be better to cache the compiled regexp. What is
> this mcached syntax inside (guix store)? Or do I use Scheme’s 'delay'
> and 'force' for caching?
I lean towards avoiding regexps altogether, as I wrote above.
WDYT?
> The attached patch fixes the regexp. Shall I push the attached patch
> and then try making it cache the compiled regexp or do you still
> prefer an implementation without regexps? Why would not using a
> regexp be better?
It reduces reliance on libc, reduces complexity, and performs better as
noted in the commit log of 35eb77b09d957019b2437e7681bd88013d67d3cd.
Thanks,
Ludo’.
next prev parent reply other threads:[~2020-03-12 16:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-07 12:00 bug#39970: guix commands broken on Azerbaijani 'az_AZ' and Turkish 'tr_TR' locales pelzflorian (Florian Pelz)
2020-03-07 15:20 ` pelzflorian (Florian Pelz)
2020-03-08 7:08 ` pelzflorian (Florian Pelz)
2020-03-09 17:02 ` Ludovic Courtès
2020-03-12 11:02 ` pelzflorian (Florian Pelz)
2020-03-12 16:05 ` Ludovic Courtès [this message]
2020-03-17 9:44 ` pelzflorian (Florian Pelz)
2020-03-17 21:20 ` Ludovic Courtès
2020-03-18 6:47 ` pelzflorian (Florian Pelz)
2020-03-18 8:40 ` Ludovic Courtès
2021-05-05 4:47 ` Maxim Cournoyer
2021-05-05 9:22 ` pelzflorian (Florian Pelz)
2021-05-05 7:04 ` Taylan Kammer
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874kutsgmx.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=39970@debbugs.gnu.org \
--cc=pelzflorian@pelzflorian.de \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.