Closed p5pRT closed 19 years ago
One failure:
lib/locale................................FAILED at test 99
Here's the harness output:
../lib/locale...............................# The following locales # # C C POSIX POSIX af_ZA af_ZA.ISO8859-1 af_ZA.ISO8859-15 # af_ZA.UTF-8 am_ET am_ET.UTF-8 be_BY be_BY.CP1131 be_BY.CP1251 # be_BY.ISO8859-5 be_BY.UTF-8 bg_BG bg_BG.CP1251 bg_BG.UTF-8 # ca_ES ca_ES.ISO8859-1 ca_ES.ISO8859-15 ca_ES.UTF-8 cs_CZ # cs_CZ.ISO8859-2 cs_CZ.UTF-8 da_DK da_DK.ISO8859-1 da_DK.ISO8859-15 # da_DK.UTF-8 de_AT de_AT.ISO8859-1 de_AT.ISO8859-15 # de_AT.UTF-8 de_CH de_CH.ISO8859-1 de_CH.ISO8859-15 # de_CH.UTF-8 de_DE de_DE.ISO8859-1 de_DE.ISO8859-15 # de_DE.UTF-8 el_GR el_GR.ISO8859-7 el_GR.UTF-8 en_AU # en_AU.ISO8859-1 en_AU.ISO8859-15 en_AU.US-ASCII en_AU.UTF-8 # en_CA en_CA.ISO8859-1 en_CA.ISO8859-15 en_CA.US-ASCII # en_CA.UTF-8 en_GB en_GB.ISO8859-1 en_GB.ISO8859-15 # en_GB.US-ASCII en_GB.UTF-8 en_IE en_IE.UTF-8 en_NZ # en_NZ.ISO8859-1 en_NZ.ISO8859-15 en_NZ.US-ASCII en_NZ.UTF-8 # en_US en_US.ISO8859-1 en_US.ISO8859-15 en_US.US-ASCII # en_US.UTF-8 es_ES es_ES.ISO8859-1 es_ES.ISO8859-15 # es_ES.UTF-8 et_EE et_EE.ISO8859-15 et_EE.UTF-8 fi_FI # fi_FI.ISO8859-1 fi_FI.ISO8859-15 fi_FI.UTF-8 fr_BE # fr_BE.ISO8859-1 fr_BE.ISO8859-15 fr_BE.UTF-8 fr_CA # fr_CA.ISO8859-1 fr_CA.ISO8859-15 fr_CA.UTF-8 fr_CH # fr_CH.ISO8859-1 fr_CH.ISO8859-15 fr_CH.UTF-8 fr_FR # fr_FR.ISO8859-1 fr_FR.ISO8859-15 fr_FR.UTF-8 he_IL # he_IL.UTF-8 hi_IN.ISCII-DEV hr_HR hr_HR.ISO8859-2 hr_HR.UTF-8 # hu_HU hu_HU.ISO8859-2 hu_HU.UTF-8 hy_AM hy_AM.ARMSCII-8 # hy_AM.UTF-8 is_IS is_IS.ISO8859-1 is_IS.ISO8859-15 # is_IS.UTF-8 it_CH it_CH.ISO8859-1 it_CH.ISO8859-15 # it_CH.UTF-8 it_IT it_IT.ISO8859-1 it_IT.ISO8859-15 # it_IT.UTF-8 ja_JP ja_JP.SJIS ja_JP.UTF-8 ja_JP.eucJP kk_KZ # kk_KZ.PT154 kk_KZ.UTF-8 ko_KR ko_KR.CP949 ko_KR.UTF-8 # ko_KR.eucKR lt_LT lt_LT.ISO8859-13 lt_LT.ISO8859-4 # lt_LT.UTF-8 nl_BE nl_BE.ISO8859-1 nl_BE.ISO8859-15 # nl_BE.UTF-8 nl_NL nl_NL.ISO8859-1 nl_NL.ISO8859-15 # nl_NL.UTF-8 no_NO no_NO.ISO8859-1 no_NO.ISO8859-15 # no_NO.UTF-8 pl_PL pl_PL.ISO8859-2 pl_PL.UTF-8 pt_BR # pt_BR.ISO8859-1 pt_BR.UTF-8 pt_PT pt_PT.ISO8859-1 pt_PT.ISO8859-15 # pt_PT.UTF-8 ro_RO ro_RO.ISO8859-2 ro_RO.UTF-8 ru_RU # ru_RU.CP1251 ru_RU.CP866 ru_RU.ISO8859-5 ru_RU.KOI8-R # ru_RU.UTF-8 sk_SK sk_SK.ISO8859-2 sk_SK.UTF-8 sl_SI # sl_SI.ISO8859-2 sl_SI.UTF-8 sr_YU sr_YU.ISO8859-2 sr_YU.ISO8859-5 # sr_YU.UTF-8 sv_SE sv_SE.ISO8859-1 sv_SE.ISO8859-15 # sv_SE.UTF-8 tr_TR tr_TR.ISO8859-9 tr_TR.UTF-8 uk_UA # uk_UA.ISO8859-5 uk_UA.KOI8-U uk_UA.UTF-8 zh_CN zh_CN.GB18030 # zh_CN.GB2312 zh_CN.GBK zh_CN.UTF-8 zh_CN.eucCN zh_HK # zh_HK.Big5HKSCS zh_HK.UTF-8 zh_TW zh_TW.Big5 zh_TW.UTF-8 # # tested okay. # # The following locales # # eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8 # # had problems. # FAILED tests 99\, 105-106\, 108-109\, 113\, 115 Failed 7/117 tests\, 94.02% okay
On 20 May 2005\, at 14:10\, schinder@G5.local (via RT) wrote:
# New Ticket Created by schinder@G5.local # Please include the string: [perl #35895] # in the subject line of all future correspondence about this issue. # \<URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=35895 >
This is a build failure report for perl from schinder@G5.local\, generated with the help of perlbug 1.35 running under perl v5.8.7.
----------------------------------------------------------------- [Please enter your report here]
One failure:
lib/locale................................FAILED at test 99
Here's the harness output:
../lib/locale...............................# The following locales # # C C POSIX POSIX af_ZA af_ZA.ISO8859-1 af_ZA.ISO8859-15 ... # zh_HK.Big5HKSCS zh_HK.UTF-8 zh_TW zh_TW.Big5 zh_TW.UTF-8 # # tested okay. # # The following locales # # eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8 # # had problems. # FAILED tests 99\, 105-106\, 108-109\, 113\, 115 Failed 7/117 tests\, 94.02% okay
The issue here seems to be that the locale says that the radix
separator (that is\, the character used to separate the integer part
of a number from the decimal fraction) for this locale is "'"\, and
perl can't cope. Here's a sample of the output from harness -v:
# Locale = eu_ES
# w =
ÿ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyzªµºÀÁÂÃÄ
ÅÆÇÈÉ ËÌÍÎÏ?ÑÒÓÔÕÖØÙÚÛÜ??ßàáâãäåæçèéêëìíîï?ñòóôõöøùúûü??
# UPPER = ABCDEFGHIJKLMNOPQRSTUVWXYZÀÁÂÃÄÅÆÇÈÉ ËÌÍÎÏ?ÑÒÓÔÕÖØÙÚÛÜ??
# lower = ÿabcdefghijklmnopqrstuvwxyzµàáâãäåæçèéêëìíîï?ñòóôõöøùúûü??
# BoThCaSe = ªºß
# Neoalpha = ÿµÀÁÂÃÄÅÆÇÈÉ ËÌÍÎÏ?ÑÒÓÔÕÖØÙÚÛÜ??àáâãä
åæçèéêëìíîï?ñòóôõöøùúûü??
# 103..107: a = 1'23\, b = 1'23\, Locale = eu_ES
# 104..107: c = 1'23\, d = 1'23\, Locale = eu_ES
# Argument "1'23" isn't numeric in numeric eq (==) at ../lib/locale.t
line 669.
# failed 105 with locale 'eu_ES'
# failed 106 with locale 'eu_ES'
# Argument "1'23" isn't numeric in numeric eq (==) at ../lib/locale.t
line 673.
# 108..110: e = 1'23\, Locale = eu_ES
# Argument "1'23" isn't numeric in numeric eq (==) at ../lib/locale.t
line 682.
# failed 108 with locale 'eu_ES' # failed 109 with locale 'eu_ES' # 111..115: f = 1.23\, g = 2'34\, locale = eu_ES # failed 113 with locale 'eu_ES' # failed 115 with locale 'eu_ES'
I can't find out whether this definition of the radix separator is
correct: the locale definition for eu_ES reached via unicode.org
\<http://www.unicode.org/cldr/version/1.2.html> has no definition for
\
specifies "'". (Some do specify it for \
separator.) The Darwin sources for "International Components for
Unicode" at \<http://www.opensource.apple.com/darwinsource/10.4.1/
ICU-6.2.4/icuSources/data/locales/eu_ES.txt> (registration required)
show English-style number formats for the eu_ES locale\, but without
going through the learning curve needed to build Darwin\, I don't know
whether this file provides (or is supposed to provide) the locale
definitions shipped in /usr/share/locale/eu_ES*.
I lean towards thinking that the separator should not be "'"\, ands
that this is Apple's bug. Anybody care to comment?
[Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=install severity=none --- Site configuration information for perl v5.8.7:
Configured by root at Fri May 20 07:37:12 EDT 2005.
Summary of my perl5 (revision 5 version 8 subversion 7) configuration: Platform: osname=darwin\, osvers=8.1.0\, archname=darwin-thread-multi-2level uname='darwin g5.local 8.1.0 darwin kernel version 8.1.0: tue
may 10 18:16:08 pdt 2005; root:xnu-792.1.5.obj~4release_ppc power
macintosh powerpc ' config_args='' hint=recommended\, useposix=true\, d_sigaction=define usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n\, bincompat5005=undef Compiler: cc='cc'\, ccflags ='-fno-common -DPERL_DARWIN -no-cpp-precomp - fno-strict-aliasing -pipe -I/usr/local/include -I/sw/include'\, optimize='-O3'\, cppflags='-no-cpp-precomp -fno-common -DPERL_DARWIN -no-cpp- precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/sw/include' ccversion=''\, gccversion='4.0.0 20041026 (Apple Computer\, Inc.
build 4061)'\, gccosandvers='darwin8' intsize=4\, longsize=4\, ptrsize=4\, doublesize=8\, byteorder=4321 d_longlong=define\, longlongsize=8\, d_longdbl=define\,
longdblsize=16 ivtype='long'\, ivsize=4\, nvtype='double'\, nvsize=8\,
Off_t='off_t'\, lseeksize=8 alignbytes=8\, prototype=define Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc'\, ldflags ='-L/usr/ local/lib -L/sw/lib' libpth=/usr/local/lib /usr/lib /sw/lib libs=-lgdbm -ldbm -ldb -ldl -lm -lc perllibs=-ldl -lm -lc libc=/usr/lib/libc.dylib\, so=dylib\, useshrplib=false\,
libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs\, dlext=bundle\, d_dlsymun=undef\, ccdlflags=' ' cccdlflags=' '\, lddlflags=' -bundle -undefined dynamic_lookup - L/usr/local/lib -L/sw/lib'Locally applied patches: RC1
--- @INC for perl v5.8.7: lib /Users/schinder/Controlled/Perl /usr/local/lib/perl5/5.8.7/darwin-thread-multi-2level /usr/local/lib/perl5/5.8.7 /usr/local/lib/perl5/site_perl/5.8.7/darwin-thread-multi-2level /usr/local/lib/perl5/site_perl/5.8.7 /usr/local/lib/perl5/site_perl/5.8.6/darwin-thread-multi-2level /usr/local/lib/perl5/site_perl/5.8.6 /usr/local/lib/perl5/site_perl/5.8.5/darwin-thread-multi-2level /usr/local/lib/perl5/site_perl/5.8.5 /usr/local/lib/perl5/site_perl/5.8.4/darwin-thread-multi-2level /usr/local/lib/perl5/site_perl/5.8.4 /usr/local/lib/perl5/site_perl/5.8.3/darwin-thread-multi-2level /usr/local/lib/perl5/site_perl/5.8.3 /usr/local/lib/perl5/site_perl .
--- Environment for perl v5.8.7: DYLD_LIBRARY_PATH=/usr/local/lib:/sw/lib:/usr/lib:/usr/X11R6/lib HOME=/Users/schinder LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/Users/schinder/bin:/usr/local/bin:/usr/local/sbin:/sw/ bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin:/opt/schily/bin:/ usr/local/naif/FORTRAN/toolkit/exe:. PERL5LIB=/Users/schinder/Controlled/Perl PERL_BADLANG (unset) SHELL=/bin/sh
-- Dominic Dunlop
The RT System itself - Status changed from 'new' to 'open'
Dominic Dunlop wrote:
On 20 May 2005\, at 14:10\, schinder@G5.local (via RT) wrote:
# New Ticket Created by schinder@G5.local # Please include the string: [perl #35895] # in the subject line of all future correspondence about this issue. # \<URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=35895 >
This is a build failure report for perl from schinder@G5.local\, generated with the help of perlbug 1.35 running under perl v5.8.7.
----------------------------------------------------------------- [Please enter your report here]
One failure:
lib/locale................................FAILED at test 99
Here's the harness output:
../lib/locale...............................# The following locales # # C C POSIX POSIX af_ZA af_ZA.ISO8859-1 af_ZA.ISO8859-15 ... # zh_HK.Big5HKSCS zh_HK.UTF-8 zh_TW zh_TW.Big5 zh_TW.UTF-8 # # tested okay. # # The following locales # # eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8 # # had problems. # FAILED tests 99\, 105-106\, 108-109\, 113\, 115 Failed 7/117 tests\, 94.02% okay
The issue here seems to be that the locale says that the radix separator (that is\, the character used to separate the integer part of a number from the decimal fraction) for this locale is "'"\, and perl can't cope. Here's a sample of the output from harness -v:
# Locale = eu_ES # w = ˇ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz™µ∫¿¡¬√ƒ ≈∆«»… ÀÃÕŒœ–—“”‘’÷ÿŸ⁄€‹›fifl‡·‚„‰ÂÊÁËÈÍÎÏÌÓÔÒÚÛÙıˆ¯˘˙˚¸˝˛ # UPPER = ABCDEFGHIJKLMNOPQRSTUVWXYZ¿¡¬√ƒ≈∆«»… ÀÃÕŒœ–—“”‘’÷ÿŸ⁄€‹›fi # lower = ˇabcdefghijklmnopqrstuvwxyzµ‡·‚„‰ÂÊÁËÈÍÎÏÌÓÔÒÚÛÙıˆ¯˘˙˚¸˝˛ # BoThCaSe = ™∫fl # Neoalpha = ˇµ¿¡¬√ƒ≈∆«»… ÀÃÕŒœ–—“”‘’÷ÿŸ⁄€‹›fi‡·‚„‰ ÂÊÁËÈÍÎÏÌÓÔÒÚÛÙıˆ¯˘˙˚¸˝˛ # 103..107: a = 1'23\, b = 1'23\, Locale = eu_ES # 104..107: c = 1'23\, d = 1'23\, Locale = eu_ES # Argument "1'23" isn't numeric in numeric eq (==) at ../lib/locale.t line 669.
# failed 105 with locale 'eu_ES' # failed 106 with locale 'eu_ES' # Argument "1'23" isn't numeric in numeric eq (==) at ../lib/locale.t line 673.
# 108..110: e = 1'23\, Locale = eu_ES # Argument "1'23" isn't numeric in numeric eq (==) at ../lib/locale.t line 682.
# failed 108 with locale 'eu_ES' # failed 109 with locale 'eu_ES' # 111..115: f = 1.23\, g = 2'34\, locale = eu_ES # failed 113 with locale 'eu_ES' # failed 115 with locale 'eu_ES'
I can't find out whether this definition of the radix separator is correct: the locale definition for eu_ES reached via unicode.org \<http://www.unicode.org/cldr/version/1.2.html> has no definition for \
\ ; no locale with a \ \ definition specifies "'". (Some do specify it for \ -- thousands separator.) The Darwin sources for "International Components for Unicode" at \<http://www.opensource.apple.com/darwinsource/10.4.1/ ICU-6.2.4/icuSources/data/locales/eu_ES.txt> (registration required) show English-style number formats for the eu_ES locale\, but without going through the learning curve needed to build Darwin\, I don't know whether this file provides (or is supposed to provide) the locale definitions shipped in /usr/share/locale/eu_ES*. I lean towards thinking that the separator should not be "'"\, ands that this is Apple's bug. Anybody care to comment?
It certainly seems to be Apple's bug. en_EU/LC_MONETARY shows "\,"\, not "'"\, for the monetary decimal point (if I'm reading it right; I compared it with en_US/LC_MONETARY). Checking some of the neighboring locale's (es_ES\, fr_FR) LC_NUMERIC shows "\,".
The question is\, should perl be able to handle whatever is in that locale slot\, even if it makes no sense\, or at least give a more useful error message?
[Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=install severity=none --- Site configuration information for perl v5.8.7:
Configured by root at Fri May 20 07:37:12 EDT 2005.
Summary of my perl5 (revision 5 version 8 subversion 7) configuration: Platform: osname=darwin\, osvers=8.1.0\, archname=darwin-thread-multi-2level uname='darwin g5.local 8.1.0 darwin kernel version 8.1.0: tue may 10 18:16:08 pdt 2005; root:xnu-792.1.5.obj~4release_ppc power macintosh powerpc ' config_args='' hint=recommended\, useposix=true\, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n\, bincompat5005=undef Compiler: cc='cc'\, ccflags ='-fno-common -DPERL_DARWIN -no-cpp-precomp - fno-strict-aliasing -pipe -I/usr/local/include -I/sw/include'\, optimize='-O3'\, cppflags='-no-cpp-precomp -fno-common -DPERL_DARWIN -no-cpp- precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/sw/include' ccversion=''\, gccversion='4.0.0 20041026 (Apple Computer\, Inc. build 4061)'\, gccosandvers='darwin8' intsize=4\, longsize=4\, ptrsize=4\, doublesize=8\, byteorder=4321 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=16 ivtype='long'\, ivsize=4\, nvtype='double'\, nvsize=8\, Off_t='off_t'\, lseeksize=8 alignbytes=8\, prototype=define Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc'\, ldflags ='-L/usr/ local/lib -L/sw/lib' libpth=/usr/local/lib /usr/lib /sw/lib libs=-lgdbm -ldbm -ldb -ldl -lm -lc perllibs=-ldl -lm -lc libc=/usr/lib/libc.dylib\, so=dylib\, useshrplib=false\, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs\, dlext=bundle\, d_dlsymun=undef\, ccdlflags=' ' cccdlflags=' '\, lddlflags=' -bundle -undefined dynamic_lookup - L/usr/local/lib -L/sw/lib'
Locally applied patches: RC1
--- @INC for perl v5.8.7: lib /Users/schinder/Controlled/Perl /usr/local/lib/perl5/5.8.7/darwin-thread-multi-2level /usr/local/lib/perl5/5.8.7 /usr/local/lib/perl5/site_perl/5.8.7/darwin-thread-multi-2level /usr/local/lib/perl5/site_perl/5.8.7 /usr/local/lib/perl5/site_perl/5.8.6/darwin-thread-multi-2level /usr/local/lib/perl5/site_perl/5.8.6 /usr/local/lib/perl5/site_perl/5.8.5/darwin-thread-multi-2level /usr/local/lib/perl5/site_perl/5.8.5 /usr/local/lib/perl5/site_perl/5.8.4/darwin-thread-multi-2level /usr/local/lib/perl5/site_perl/5.8.4 /usr/local/lib/perl5/site_perl/5.8.3/darwin-thread-multi-2level /usr/local/lib/perl5/site_perl/5.8.3 /usr/local/lib/perl5/site_perl .
--- Environment for perl v5.8.7: DYLD_LIBRARY_PATH=/usr/local/lib:/sw/lib:/usr/lib:/usr/X11R6/lib HOME=/Users/schinder LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/Users/schinder/bin:/usr/local/bin:/usr/local/sbin:/sw/ bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin:/opt/schily/bin:/ usr/local/naif/FORTRAN/toolkit/exe:. PERL5LIB=/Users/schinder/Controlled/Perl PERL_BADLANG (unset) SHELL=/bin/sh
-- Paul Schinder schinder@pobox.com
Dominic Dunlop wrote:
The issue here seems to be that the locale says that the radix separator (that is\, the character used to separate the integer part of a number from the decimal fraction) for this locale is "'"\, and perl can't cope. Here's a sample of the output from harness -v:
I made the change "'" to "\," in /usr/share/locale/eu_ES/LC_NUMERIC\, and I still get the same failure:
# Locale = eu_ES # w = ˇ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz™µ∫¿¡¬√ƒ≈∆«»… ÀÃÕŒœ–—“”‘’÷ÿŸ⁄€‹›fifl‡·‚„‰ÂÊÁËÈÍÎÏÌÓÔÒÚÛÙıˆ¯˘˙˚¸˝˛ # UPPER = ABCDEFGHIJKLMNOPQRSTUVWXYZ¿¡¬√ƒ≈∆«»… ÀÃÕŒœ–—“”‘’÷ÿŸ⁄€‹›fi # lower = ˇabcdefghijklmnopqrstuvwxyzµ‡·‚„‰ÂÊÁËÈÍÎÏÌÓÔÒÚÛÙıˆ¯˘˙˚¸˝˛ # BoThCaSe = ™∫fl # Neoalpha = ˇµ¿¡¬√ƒ≈∆«»… ÀÃÕŒœ–—“”‘’÷ÿŸ⁄€‹›fi‡·‚„‰ÂÊÁËÈÍÎÏÌÓÔÒÚÛÙıˆ¯˘˙˚¸˝˛ # 103..107: a = 1\,23\, b = 1\,23\, Locale = eu_ES # 104..107: c = 1\,23\, d = 1\,23\, Locale = eu_ES # Argument "1\,23" isn't numeric in numeric eq (==) at ../lib/locale.t line 669.
# failed 105 with locale 'eu_ES' # failed 106 with locale 'eu_ES' # Argument "1\,23" isn't numeric in numeric eq (==) at ../lib/locale.t line 673.
# 108..110: e = 1\,23\, Locale = eu_ES # Argument "1\,23" isn't numeric in numeric eq (==) at ../lib/locale.t line 682.
# failed 108 with locale 'eu_ES' # failed 109 with locale 'eu_ES' # 111..115: f = 1.23\, g = 2\,34\, locale = eu_ES # failed 113 with locale 'eu_ES' # failed 115 with locale 'eu_ES'
and similarly for the other eu_ES. I've never needed to use a locale at all before (besides setting "LC_*="C" to avoid problems with them). Do they need to be compiled somehow or something? Why isn't this working now?
-- Paul Schinder schinder@pobox.com
Paul Schinder wrote:
It certainly seems to be Apple's bug. en_EU/LC_MONETARY shows "\,"\, not "'"\, for the monetary decimal point (if I'm reading it right; I compared it with en_US/LC_MONETARY). Checking some of the neighboring locale's (es_ES\, fr_FR) LC_NUMERIC shows "\,".
I concur that this is probably something weird with the Apple implementation. I have a small script in my Math::Currency distro which extracts the currency information for different locales and this is what I see with SUSE 9.2's eu_ES:
$LC_MONETARY->{EUR} = { INT_CURR_SYMBOL => 'EUR '\, CURRENCY_SYMBOL => 'EUR'\, MON_DECIMAL_POINT => '\,'\, MON_THOUSANDS_SEP => '.'\, MON_GROUPING => '3'\, POSITIVE_SIGN => ''\, NEGATIVE_SIGN => '-'\, INT_FRAC_DIGITS => '2'\, FRAC_DIGITS => '2'\, P_CS_PRECEDES => '1'\, P_SEP_BY_SPACE => '1'\, N_CS_PRECEDES => '1'\, N_SEP_BY_SPACE => '1'\, P_SIGN_POSN => '1'\, N_SIGN_POSN => '1'\, };
(even the utf8 variant shows the same values for MON_DECIMAL_POINT and MON_THOUSANDS_SEP). If you are interested in confirming\, download the Math::Currency distro from CPAN and run the scripts/new_currency under Darwin (you'll have to delete the existing lib/Math/Currency/EUR.pm) and report back what it finds.
The question is\, should perl be able to handle whatever is in that locale slot\, even if it makes no sense\, or at least give a more useful error message?
Perl is able to use locales for *output*\, but isn't completely internationalized with regard to *input* (i.e. the tokenizer isn't that smart yet). I wouldn't hold my breath for Perl5\, but perhaps Perl6 can get this right.
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham\, MD 20706 301-459-3366 x.5010 fax 301-429-5747
On 5 Jun 2005\, at 01:36\, John Peacock wrote:
I concur that this is probably something weird with the Apple
implementation. I have a small script in my Math::Currency distro
which extracts the currency information for different locales and
this is what I see with SUSE 9.2's eu_ES:$LC_MONETARY->{EUR} = { INT_CURR_SYMBOL => 'EUR '\, CURRENCY_SYMBOL => 'EUR'\, MON_DECIMAL_POINT => '\,'\, MON_THOUSANDS_SEP => '.'\, MON_GROUPING => '3'\, POSITIVE_SIGN => ''\, NEGATIVE_SIGN => '-'\, INT_FRAC_DIGITS => '2'\, FRAC_DIGITS => '2'\, P_CS_PRECEDES => '1'\, P_SEP_BY_SPACE => '1'\, N_CS_PRECEDES => '1'\, N_SEP_BY_SPACE => '1'\, P_SIGN_POSN => '1'\, N_SIGN_POSN => '1'\, };
(even the utf8 variant shows the same values for MON_DECIMAL_POINT
and MON_THOUSANDS_SEP). If you are interested in confirming\,
download the Math::Currency distro from CPAN and run the scripts/ new_currency under Darwin (you'll have to delete the existing lib/ Math/Currency/EUR.pm) and report back what it finds.Agreed it's Apple's bug. Here's my trivial test script\, followed by
some output (from Apple's default perl\, which for Tiger\, is 5.8.6):
$ cat localetest.pl use POSIX qw(setlocale localeconv); use Data::Dumper; $Data::Dumper::Sortkeys = 1; # Present hash keys in sorted order printf "Locale = %s\n"\, POSIX::setlocale( &POSIX::LC_ALL\, shift || 'C'); print Dumper POSIX::localeconv(); $ for l in '' en_GB es_ES eu_ES; do /usr/bin/perl localetest.pl $l; done Locale = C $VAR1 = { 'decimal_point' => '.'\, 'grouping' => ''\, 'mon_grouping' => '' }; Locale = en_GB $VAR1 = { 'currency_symbol' => '£'\, 'decimal_point' => '.'\, 'frac_digits' => 2\, 'grouping' => ''\, 'int_curr_symbol' => 'GBP '\, 'int_frac_digits' => 2\, 'mon_decimal_point' => '.'\, 'mon_grouping' => ''\, 'mon_thousands_sep' => '\,'\, 'n_cs_precedes' => 1\, 'n_sep_by_space' => 0\, 'n_sign_posn' => 1\, 'negative_sign' => '-'\, 'p_cs_precedes' => 1\, 'p_sep_by_space' => 0\, 'p_sign_posn' => 1\, 'thousands_sep' => '\,' }; Locale = es_ES $VAR1 = { 'currency_symbol' => 'Eu'\, 'decimal_point' => '\,'\, 'frac_digits' => 2\, 'grouping' => ''\, 'int_curr_symbol' => 'EUR '\, 'int_frac_digits' => 2\, 'mon_decimal_point' => '\,'\, 'mon_grouping' => ''\, 'mon_thousands_sep' => '.'\, 'n_cs_precedes' => 1\, 'n_sep_by_space' => 1\, 'n_sign_posn' => 1\, 'negative_sign' => '-'\, 'p_cs_precedes' => 1\, 'p_sep_by_space' => 1\, 'p_sign_posn' => 1 }; Locale = eu_ES $VAR1 = { 'currency_symbol' => 'Eu'\, 'decimal_point' => '\' '\, 'frac_digits' => 2\, 'grouping' => ''\, 'int_curr_symbol' => 'EUR '\, 'int_frac_digits' => 2\, 'mon_decimal_point' => '\,'\, 'mon_grouping' => ''\, 'mon_thousands_sep' => '.'\, 'n_cs_precedes' => 1\, 'n_sep_by_space' => 1\, 'n_sign_posn' => 1\, 'negative_sign' => '-'\, 'p_cs_precedes' => 1\, 'p_sep_by_space' => 1\, 'p_sign_posn' => 1\, 'thousands_sep' => '.' };
Notice the really silly decimal_point for the eu_ES locale. (I'm also
vaguely surprised that none of the locales I've tried has a grouping
or mon_grouping defined.) I've posted this as a bug to Apple (Bug ID#
4139653).
On 4 Jun 2005\, at 20:40\, Paul Schinder wrote:
The question is\, should perl be able to handle whatever is in that locale slot\, even if it makes no sense\, or at least give a more useful error message?
I don't think it's reasonable to ask perl to do anything sensible or
helpful when presented with a decimal_point this silly.
--
Dominic Dunlop
Dominic Dunlop wrote:
On 4 Jun 2005\, at 20:40\, Paul Schinder wrote:
The question is\, should perl be able to handle whatever is in that locale slot\, even if it makes no sense\, or at least give a more useful error message?
I don't think it's reasonable to ask perl to do anything sensible or
helpful when presented with a decimal_point this silly.
Actually\, I'm on the other side of the fence now (now that I looked at the code). It does appear that Perl intends to correctly handle other radix characters than period (although toke.c only understands that one). I haven't exactly worked out the sequence of events but it's clear that 'use locale' does munge the input sufficiently so that non-period radixes should be interpreted properly.
What I realized was that the one character that has even more special behavior is the single quote. This used to be used (pre Perl5?) as the package qualifier (what we now use :: for)\, so the "numbers" in question area probably being parsed as weird package variables\, so locale cannot do anything useful with them.
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham\, MD 20706 301-459-3366 x.5010 fax 301-429-5747
On 5 Jun 2005\, at 13:33\, John Peacock wrote:
Dominic Dunlop wrote:
I don't think it's reasonable to ask perl to do anything sensible
or helpful when presented with a decimal_point this silly.Actually\, I'm on the other side of the fence now (now that I looked
at the code). It does appear that Perl intends to correctly handle
other radix characters than period (although toke.c only
understands that one). I haven't exactly worked out the sequence
of events but it's clear that 'use locale' does munge the input
sufficiently so that non-period radixes should be interpreted
properly.
Even two-character ones like we have here? I suppose so\, as the C
standard shows struct lconv having char *'s for all such fields.
What I realized was that the one character that has even more
special behavior is the single quote. This used to be used (pre
Perl5?) as the package qualifier (what we now use :: for)\, so the
"numbers" in question area probably being parsed as weird package
variables\, so locale cannot do anything useful with them.
Wow. That takes me back. Yes\, I remember using that now... -- Dominic Dunlop
On Sun\, Jun 05\, 2005 at 06:24:31PM +0200\, Dominic Dunlop wrote:
On 5 Jun 2005\, at 13:33\, John Peacock wrote:
Dominic Dunlop wrote:
Actually\, I'm on the other side of the fence now (now that I looked
at the code). It does appear that Perl intends to correctly handle
other radix characters than period (although toke.c only
understands that one). I haven't exactly worked out the sequence
of events but it's clear that 'use locale' does munge the input
sufficiently so that non-period radixes should be interpreted
properly.Even two-character ones like we have here? I suppose so\, as the C
standard shows struct lconv having char *'s for all such fields.
Effort was put into making fa_IR work. IIRC the fun there was that the Unicode character that is the radix separator is 2 bytes when UTF8 encoded (but 1 character). Given that the low level implementation doesn't know how bytes map to characters\, I think that arbitrary multi character sequences should be working too.
Nicholas Clark
On Sun\, Jun 05\, 2005 at 12:41:04PM +0200\, Dominic Dunlop wrote:
Locale = eu_ES $VAR1 = { 'currency_symbol' => 'Eu'\, 'decimal_point' => '\' '\, 'frac_digits' => 2\, 'grouping' => ''\, 'int_curr_symbol' => 'EUR '\, 'int_frac_digits' => 2\, 'mon_decimal_point' => '\,'\, 'mon_grouping' => ''\, 'mon_thousands_sep' => '.'\, 'n_cs_precedes' => 1\, 'n_sep_by_space' => 1\, 'n_sign_posn' => 1\, 'negative_sign' => '-'\, 'p_cs_precedes' => 1\, 'p_sep_by_space' => 1\, 'p_sign_posn' => 1\, 'thousands_sep' => '.' };
Notice the really silly decimal_point for the eu_ES locale. (I'm also
vaguely surprised that none of the locales I've tried has a grouping
or mon_grouping defined.) I've posted this as a bug to Apple (Bug ID#
4139653).
Yes\, I'd say it's an apple bug. It might actually be in printf. Here's a pure C test case:
$ cat locale.c #include \<stdio.h> #include \<locale.h>
int main(int argc\, char **argv) { char *locale; while((locale = *++argv)) { struct lconv *l;
if (!setlocale(LC_NUMERIC\, locale)) { printf("setlocale for '%s' failed\n"\, locale); continue; } l = localeconv(); printf ("locale >%s\<\, separator = >%s\<\, 1.23 prints as >%.3g\<\n"\, locale\, l->decimal_point\, 1.23); } return 0; } $ ./locale eu_ES locale >eu_ES\<\, separator = >' \<\, 1.23 prints as >1'23\<
If it's not a bug\, I'd like to know why the C standard lets you skip putting the space in the string in printf.
Nicholas Clark
[nicholas - Mon Jun 27 08:43:02 2005]:
On Sun\, Jun 05\, 2005 at 12:41:04PM +0200\, Dominic Dunlop wrote:
Locale = eu_ES $VAR1 = { 'currency_symbol' => 'Eu'\, 'decimal_point' => '\' '\, 'frac_digits' => 2\, 'grouping' => ''\, 'int_curr_symbol' => 'EUR '\, 'int_frac_digits' => 2\, 'mon_decimal_point' => '\,'\, 'mon_grouping' => ''\, 'mon_thousands_sep' => '.'\, 'n_cs_precedes' => 1\, 'n_sep_by_space' => 1\, 'n_sign_posn' => 1\, 'negative_sign' => '-'\, 'p_cs_precedes' => 1\, 'p_sep_by_space' => 1\, 'p_sign_posn' => 1\, 'thousands_sep' => '.' };
Notice the really silly decimal_point for the eu_ES locale. (I'm also
vaguely surprised that none of the locales I've tried has a grouping
or mon_grouping defined.) I've posted this as a bug to Apple (Bug ID#
4139653).Yes\, I'd say it's an apple bug. It might actually be in printf. Here's a pure C test case:
$ cat locale.c #include \<stdio.h> #include \<locale.h>
int main(int argc\, char **argv) { char *locale; while((locale = *++argv)) { struct lconv *l;
if \(\!setlocale\(LC\_NUMERIC\, locale\)\) \{ printf\("setlocale for '%s' failed\\n"\, locale\); continue; \} l = localeconv\(\); printf \("locale >%s\<\, separator = >%s\<\, 1\.23 prints as >%\.3g\<\\n"\, locale\, l\->decimal\_point\, 1\.23\);
} return 0; } $ ./locale eu_ES locale >eu_ES\<\, separator = >' \<\, 1.23 prints as >1'23\<
If it's not a bug\, I'd like to know why the C standard lets you skip putting the space in the string in printf.
Since this problem with Apple's implemented of the eu_ES locale has now been documented in README.macosx\, this ticket can be closed.
@smpeters - Status changed from 'open' to 'resolved'
Migrated from rt.perl.org#35895 (status was 'resolved')
Searchable as RT35895$