On Aug 18, 2011, at 6:46 PM, Carl Friedberg wrote: > Hi Craig, > > My first cut on 5.14.1 on VMS (list is very quiet, must be August vacation > time)
Thanks for the report. > $ multinet show/version > Process Software MultiNet V5.3 Rev A-X, AlphaServer DS25, OpenVMS AXP V8.3 > $ cc /vers > HP C V7.3-009 on OpenVMS Alpha V8.3 > > @configure "-des" "-Dprefix=wherever > > Failed 10 tests out of 1904, 99.47% okay. Not so bad, but not perfect. > ../cpan/CPAN-Meta/t/save-load.t Never seen this, and I don't even know offhand what this module does. > ../cpan/CPANPLUS/t/03_CPANPLUS-Internals-Source.t > ../cpan/HTTP-Tiny/t/110_mirror.t These could have something to do with network connectivity, i.e., to the Internet, not locally. Tests that attempt to phone home are somewhat frowned on, but people keep writing them. This is speculation, though, as I've never seen these. > ../cpan/Module-Build/t/PL_files.t > ../cpan/Module-Build/t/properties/dist_suffix.t > ../cpan/Module-Build/t/runthrough.t > ../cpan/Module-Build/t/tilde.t Much of this goes away with DECC$EFS_CASE_PRESERVE and/or DECC$ARGV_PARSE_STYLE. It tries to distinguish between .PL and .pl, but of course you can't when case is not preserved. The other part of it has to do with trimming the prefix off a path in the home-grown glob implementation. I've taken a couple of stabs at fixing it but haven't gotten it quite right yet. It would be relatively rare corner cases where any of this would cause trouble building something with Module::Build. > ../cpan/Time-HiRes/t/HiRes.t This is a bug in the CRTL's setitimer() implementation. I reported it in March and it's been fixed (Quix case # QXCM1001115136) but not made it into any ECO that I've seen. > ../cpan/autodie/t/recv.t > ../dist/Net-Ping/t/510_ping_udp.t Don't recall seeing these. Net::Ping, as its name implies, can be sensitive to various things allowed or not allowed on the local network. > I will ignore all Module-Build failures. Let me know if I should follow up on > any of the rest. If there's a module you're going to use, I suggest looking into its failures. Otherwise you're in pretty good shape. > I then built VMS::Device (0.09): I released 0.10 in May, which has about 100 more item codes than 0.09. > mmk test whined (I ignored) > > $16$dka2:[perl5141]perl.exe.1 "-MExtUtils::Command::MM" "-e" "test_harness(0, > '[.blib.lib]', '[.blib.arch]')" t/*.t > %DCL-W-IVVERB, unrecognized command verb - check validity and spelling > \"$16$dka2:[perl5141]perl.exe;1"\ > t/basic.t .. ok > All tests successful. > Files=1, Tests=1, 0 wallclock secs ( 0.35 usr + 0.00 sys = 0.35 CPU) > Result: PASS > > (that location is correct for the installed version of 5.14.1) This is a nit in Test::Harness, which "helpfully" decides to quote everything so it can't be misinterpreted. Oops. What you're seeing is the equivalent of: $ "dir" %DCL-E-PARSEFAIL, error parsing DCL$PATH:"dir".* -RMS-F-FNM, error in file name Obviously that's not a directory listing. One way to fix it would be to patch Test::Harness so it only quotes arguments and not the command itself: --- cpan/Test-Harness/lib/Test/Harness.pm;-0 2010-08-16 11:07:13 -0500 +++ cpan/Test-Harness/lib/Test/Harness.pm 2011-02-03 22:55:57 -0600 @@ -306,9 +306,10 @@ sub _filtered_inc { local $ENV{PERLLIB}; my $perl = $ENV{HARNESS_PERL} || $^X; + $perl = qq|"$perl"| unless IS_VMS; # Avoid using -l for the benefit of Perl 6 - chomp( @inc = `"$perl" -e "print join qq[\\n], \@INC, q[]"` ); + chomp( @inc = `$perl -e "print join qq[\\n], \@INC, q[]"` ); return @inc; } } [end] I'm not sure that's the best fix, though. I'm wondering whether the backticks implementation should be modified to parse quotes off the first parameter and replaces spaces with %^_. So "/sys$common/my programs here/foo.exe" becomes sys$common:[my^_programs^_here]foo.exe Someone stop me if this is not a good idea. > VMS::Device works as expected. > > Thank you, as always, for the hard work you put in to make perl VMS friendly. Thanks for allowing me to think I'm not completely crazy. > And, FWIW the VMS version of 5.14.1 is working before Cygwin (!) Now, *that* is surprising. ________________________________________ Craig A. Berry mailto:craigbe...@mac.com "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser