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

Reply via email to