New Spanish PO file for 'gcc' (version 7.1-b20170226)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Spanish team of translators. The file is available at: http://translationproject.org/latest/gcc/es.po (This file, 'gcc-7.1-b20170226.es.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH] Define std::to_chars and std::from_chars for C++17 (P0067R5, partial)
On 07/04/17 13:29 +0100, Jonathan Wakely wrote:
+ constexpr char __abc[] = "abcdefghijklmnopqrstuvwxyz";
+ unsigned char __lc = std::tolower(__c);
+ constexpr bool __consecutive = __consecutive_chars(__abc, 26);
+ if _GLIBCXX17_CONSTEXPR (__consecutive)
+ {
+ // Characters 'a'..'z' are consecutive
+ if (std::isalpha(__c) && (__lc - 'a') < __b)
+ __c = __lc - 'a' + 10;
Is that alright? I have my eyes set on the following line in particular:
+ unsigned char __lc = std::tolower(__c);
Correct me if I'm wrong but that's locale sensitive. As it turns out in
a Turkish locale the lowercase for is <ı> "U+0131 LATIN SMALL LETTER
DOTLESS I".
I installed a Turkish locale on an old system of mine (Linux, UTF-8) and
sketched out the lines to quickly test the logic. As best as I can tell
the following happens when the global locale is set to Turkish:
- __lc is 'I' unchanged because <ı> U+0131 would encode to two UTF-8
codepoints aka can't fit in a char
- the test succeeds
- the computed value that ends up being written to __c is decimal -14
Keep in mind I didn't run the actual code from the patch, so I may have
got something wrong. Still, the Turkish i/İ and ı/I pairs are just one
example in one locale. Are std::tolower and std::isalpha the right tools
for this job? (These are the only two locale sensitive parts I
noticed in the code.)
Re: [PATCH] Define std::to_chars and std::from_chars for C++17 (P0067R5, partial)
On 16 April 2017 at 19:16, Luc Danton wrote:
> On 07/04/17 13:29 +0100, Jonathan Wakely wrote:
>>
>> + constexpr char __abc[] = "abcdefghijklmnopqrstuvwxyz";
>> + unsigned char __lc = std::tolower(__c);
>> + constexpr bool __consecutive = __consecutive_chars(__abc,
>> 26);
>> + if _GLIBCXX17_CONSTEXPR (__consecutive)
>> + {
>> + // Characters 'a'..'z' are consecutive
>> + if (std::isalpha(__c) && (__lc - 'a') < __b)
>> + __c = __lc - 'a' + 10;
>
>
>
> Is that alright? I have my eyes set on the following line in particular:
>
>> + unsigned char __lc = std::tolower(__c);
>
>
> Correct me if I'm wrong but that's locale sensitive. As it turns out in
> a Turkish locale the lowercase for is <ı> "U+0131 LATIN SMALL LETTER
> DOTLESS I".
Good catch, thanks.
>
> I installed a Turkish locale on an old system of mine (Linux, UTF-8) and
> sketched out the lines to quickly test the logic. As best as I can tell
> the following happens when the global locale is set to Turkish:
>
> - __lc is 'I' unchanged because <ı> U+0131 would encode to two UTF-8
>codepoints aka can't fit in a char
> - the test succeeds
> - the computed value that ends up being written to __c is decimal -14
>
> Keep in mind I didn't run the actual code from the patch, so I may have
> got something wrong. Still, the Turkish i/İ and ı/I pairs are just one
> example in one locale. Are std::tolower and std::isalpha the right tools
> for this job? (These are the only two locale sensitive parts I
> noticed in the code.)
Yeah, I'll avoid isalpha and tolower.
Re: [PATCH, gfortran] Cleanup the submodule tests
Hi Dominique,
> I am currently testing the following patch that handle both modules and
> submodules. It is a little bit clumsy and may not handle all the possible
> syntax variants. Any comment welcomed!-) Testing in progress.
so, how did the testing go?
> proc list-module-names-1 { file } {
> set result {}
> -set tmp [grep $file "^\[ \t\]*((#)?\[
> \t\]*include|\[mM\]\[oO\]\[dD\]\[uU\]\[lL\]\[eE\](?!\[
> \t\]+\[pP\]\[rR\]\[oO\]\[cC\]\[eE\]\[dD\]\[uU\]\[rR\]\[eE\]\[ \t\]+))\[
> \t\]+.*" line]
> +if {[file isdirectory $file]} {return}
> +set tmp [igrep $file
> "^\\s*((#)?\\s*include|(sub)?module(?!\\s+(recursive\\s+)?(procedure|subroutine|function)\\s*))\\s*.*"
> line]
This is supposed to catch all lines including "module", but not
"module procedure", "module subroutine" etc, right? Why do you need
"recursive" here, but no other attributes like "pure" or "elemental"?
> if {![string match "" $tmp]} {
> foreach i $tmp {
> - regexp "(\[0-9\]+)\[ \t\]+(?:(?:#)?\[ \t\]*include\[
> \t\]+)\[\"\](\[^\"\]*)\[\"\]" $i dummy lineno include_file
> + regexp -nocase
> "(\[0-9\]+)\\s+(?:(?:#)?\\s*include\\s+)\[\"\'\](\[^\"\'\]*)\[\"\'\]" $i
> dummy lineno include_file
My regex sorcery may be a bit rusty, but why does \\s need a double
escape while \t appears with single escape?
> @@ -99,7 +100,11 @@ proc list-module-names-1 { file } {
> }
> continue
> }
> - regexp "(\[0-9\]+)\[
> \t\]+(?:(\[mM\]\[oO\]\[dD\]\[uU\]\[lL\]\[eE\]\[
> \t\]+(?!\[pP\]\[rR\]\[oO\]\[cC\]\[eE\]\[dD\]\[uU\]\[rR\]\[eE\]\[ \t\]+)))(\[^
> \t;\]*)" $i i lineno keyword mod
> + regexp -nocase "(\[0-9\]+)\\s+(module|submodule)\\s*(\[^;\]*)" $i
> i lineno keyword mod
> + regsub "\\s*!.*" $mod "" mod
> + regsub ":\[^)\]*" $mod "" mod
> + regsub "\\(\\s*" $mod "" mod
> + regsub "\\s*\\)\\s*" $mod "@" mod
> if {![info exists lineno]} {
> continue
> }
Not sure I understand this part. Guess I'm spending too little time
with regexps to find them readable :(
Cheers,
Janus
