Bug #71044 for Number-Format: make test fails on Strawberry

Sat Sep 17 21:33:26 2011 cnighswonger [...] foundations.edu - Ticket created

Subject:

make test fails on Strawberry

When building on Win32 using Strawberry Perl 5.12.3.0, 'make test' fails as noted in the output below. I'd be glad to help debug with some direction from the package maintainer. Chris C:\strawberry\cpan\build\Number-Format-1.73-ctpUEg>dmake test C:\strawberry\perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib\lib', 'blib\arch')" t/*.t t/format_bytes.t ..... ok t/format_negative.t .. ok t/format_number.t .... ok t/format_picture.t ... ok t/format_price.t ..... ok t/locale.t ........... 1/? Invalid sep_by_space value at t/locale.t line 77 # Looks like your test exited with 255 just after 5. t/locale.t ........... Dubious, test returned 255 (wstat 65280, 0xff00) All 5 subtests passed (less 3 skipped subtests: 2 okay) t/object.t ........... ok t/round.t ............ ok t/unformat_number.t .. ok Test Summary Report ------------------- t/locale.t (Wstat: 65280 Tests: 5 Failed: 0) Non-zero exit status: 255 Files=9, Tests=147, 4 wallclock secs ( 0.19 usr + 0.94 sys = 1.12 CPU) Result: FAIL Failed 1/9 test programs. 0/147 subtests failed. dmake: Error code 255, while making 'test_dynamic' C:\strawberry\cpan\build\Number-Format-1.73-ctpUEg>

Sun Mar 11 06:09:35 2012 ASB [...] cpan.org - Correspondence added

Same here on Win 7 x64 with strawberry perl 5.12.2 built for MSWin32- x64-multi-thread: Checking if your kit is complete... Looks good Writing Makefile for Number::Format Writing MYMETA.yml and MYMETA.json (C:\strawberry\perl\bin\perl.exe Makefile.PL exited with 0) CPAN::Reporter: Makefile.PL result is 'pass', No errors. cp Format.pm blib\lib\Number\Format.pm (C:\strawberry\c\bin\dmake.EXE exited with 0) CPAN::Reporter: dmake result is 'pass', No errors. WRW/Number-Format-1.73.tar.gz C:\strawberry\c\bin\dmake.EXE -- OK Running make test C:\strawberry\perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib\lib', 'blib\arch')" t/*.t t/format_bytes.t ..... ok t/format_negative.t .. ok t/format_number.t .... ok t/format_picture.t ... ok t/format_price.t ..... ok Invalid sep_by_space value at t/locale.t line 77 # Looks like your test exited with 255 just after 5. t/locale.t ........... Dubious, test returned 255 (wstat 65280, 0xff00) All 5 subtests passed (less 3 skipped subtests: 2 okay) t/object.t ........... ok t/round.t ............ ok t/unformat_number.t .. ok Test Summary Report ------------------- t/locale.t (Wstat: 65280 Tests: 5 Failed: 0) Non-zero exit status: 255 Files=9, Tests=147, 1 wallclock secs ( 0.13 usr + 0.05 sys = 0.17 CPU) Result: FAIL Failed 1/9 test programs. 0/147 subtests failed. dmake.EXE: Error code 255, while making 'test_dynamic' (C:\strawberry\c\bin\dmake.EXE test exited with 65280) CPAN::Reporter: Test result is 'fail', One or more tests failed. CPAN::Reporter: preparing a CPAN Testers report for Number-Format-1.73 Do you want to review or edit the test report? (yes/no) [no] Do you want to send the report? (yes/no) [yes] CPAN::Reporter: sending test report with 'fail' via Metabase WRW/Number-Format-1.73.tar.gz C:\strawberry\c\bin\dmake.EXE test -- NOT OK //hint// to see the cpan-testers results for installing this module, try: reports WRW/Number-Format-1.73.tar.gz Running make install make test had returned bad status, won't install without force Failed during this command: WRW/Number-Format-1.73.tar.gz : make_test NO

Sun Mar 11 06:09:36 2012 The RT System itself - Status changed from 'new' to 'open'

Tue Apr 22 07:36:40 2014 manfred.jebram [...] gmx.de - Correspondence added

From:

manfred.jebram [...] gmx.de

I had the same problem using: Number-Format-1.73 Strawberry Perl v5.16.2 built for MSWin32-x86-multi-thread) Win XP SP3 Prof. (32-bit) Reason seems to be the POSIX module, which returns many "-1" values where Number::Format->new() expects missing hash keys... I was able to successfully test and install by using the attached patch as a workaround. But it might be smarter to fix this problem in the POSIX module.

Subject:

Number_Format.pm.patch

--- Format.pm Sat Sep 26 01:47:51 2009 +++ Format.pm.patched Tue Apr 22 13:04:31 2014 @@ -416,6 +416,8 @@ while(my($arg, $default) = each %$DEFAULT_LOCALE) { $me->{$arg} = (exists $locale_values->{$arg} + && defined $locale_values->{ $arg } + && $locale_values->{ $arg } ne '-1' ? $locale_values->{$arg} : $default);

Fri Nov 21 19:59:44 2014 COSMICNET [...] cpan.org - Correspondence added

RT-Send-CC:

manfred.jebram [...] gmx.de, bill [...] wards.net

On Windows, setting the locale to 'C' means that a number of numeric locale formatting values come back as -1: The code: my $loc = POSIX::setlocale( &POSIX::LC_ALL, 'C' ); my $lconv = POSIX::localeconv(); foreach my $key (sort keys %$lconv) { print "$key = $lconv->{$key}\n"; } Produces the output: decimal_point = . frac_digits = -1 int_frac_digits = -1 n_cs_precedes = -1 n_sep_by_space = -1 n_sign_posn = -1 p_cs_precedes = -1 p_sep_by_space = -1 p_sign_posn = -1 This has been the POSIX behaviour for the C locale on Windows for some time. This is causing the locale.t tests to fail as Format.pm expects p_sep_by_space to be 0, 1, or 2. It seems that the correct solution would be to treat the -1 values as 0 for each of these formatting keys. Lyle