Skip Menu |

This queue is for tickets about the HTML-FormFu CPAN distribution.

Report information
The Basics
Id: 109159
Status: resolved
Priority: 0/
Queue: HTML-FormFu

People
Owner: Nobody in particular
Requestors: SREZIC [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 2.01
Fixed in: 2.03



Subject: t/aggregate.t may fail under some circumstances (locale, freebsd, recent perl)
t/aggregate.t fails under the following circumstances: * a newer perl (5.22.0 or newer, it can be produced on some late 5.21.x versions) * a locale where the decimal separator is comma and not dot (e.g German and probably most European non-English locales). * freebsd Log of the failing test: # Failed test 'exact number not there' # at t-aggregate/deflators/formatnumber.t line 24. # '<form action="" method="post"> # <div> # <input name="foo" type="text" value="10002300,12300000" /> # </div> # </form> # ' # matches '(?^:10002300.123)' # Looks like you failed 1 test of 1. # Failed test 'Tests for t-aggregate/deflators/formatnumber.t' # at /usr/perl5.23.4p/lib/site_perl/5.23.4/Test/Aggregate/Nested.pm line 229. # Looks like you failed 1 test of 402. t/aggregate.t .................. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/402 subtests What happens here? Maybe the bug is somewhere in Number::Format. Normally, there are some thousand separators in the formatted number. But not on freebsd with a new perl and a German locale: $ env LC_ALL=de_DE.UTF-8 perl5.23.4 -MNumber::Format -e 'warn Number::Format->new->format_number(10002300.123)' 10002300,12 at -e line 1. With a C locale it looks like expected: $ env LC_ALL=C perl5.23.4 -MNumber::Format -e 'warn Number::Format->new->format_number(10002300.123)' 10,002,300.12 at -e line 1. With an older perl it seems that the locale is ignored, and it's formatted like an English number: $ env LC_ALL=de_DE.UTF-8 perl5.20.0 -MNumber::Format -e 'warn Number::Format->new->format_number(10002300.123)' 10,002,300.12 at -e line 1. Everywhere Number::Format 1.75 was installed.
This is an interesting one - it shows up the smokers testing matrix as failures - eg http://www.cpantesters.org/cpan/report/becc6060-28f8-11e6-91fb-a1eac85efef1 However I think this is because the test is fundamentally wrong - it checks that the processed form does *NOT* match qr/10002300.123/ - which is OK in en.GB as commas get added in for the thousands separator. For DE this does match because the . is not a literal! For now I have changed this to look for a numeric value with optional , or . thousand separators and either a , or . decimal point, with all the digits and anchoring by the wrapping quotes. I think this should work for all the locales I know of, but may break if someone puts it through a locale using non digits, LTR or other separators applied in a different way... Klingon?? Marking it as patched but leaving not resolved until its had better testing. https://github.com/fireartist/HTML-FormFu/commit/53e55c6447b2f7941b1936d151277bf66157a17d
On 2016-06-03 09:17:27, NIGELM wrote: Show quoted text
> This is an interesting one - it shows up the smokers testing matrix as > failures - eg http://www.cpantesters.org/cpan/report/becc6060-28f8- > 11e6-91fb-a1eac85efef1 > > However I think this is because the test is fundamentally wrong - it > checks that the processed form does *NOT* match qr/10002300.123/ - > which is OK in en.GB as commas get added in for the thousands > separator. For DE this does match because the . is not a literal! > > For now I have changed this to look for a numeric value with optional > , or . thousand separators and either > a , or . decimal point, with all the digits and anchoring by the > wrapping quotes. I think this should work for > all the locales I know of, but may break if someone puts it through a > locale using non digits, LTR or other > separators applied in a different way... Klingon?? > > Marking it as patched but leaving not resolved until its had better > testing. > > https://github.com/fireartist/HTML- > FormFu/commit/53e55c6447b2f7941b1936d151277bf66157a17d
This looks fixed with the current HTML-FormFu versions.
Closing this as resolved