Hi Craig,
Thanks for your prompt replies.
You asked for a bit more detail on the issue that the machinery for rerunning
(with details) the failed
tests did not seem to work for all of the failing tests.
Two examples of failed tests:
During the run of all tests these two examples appear as
lib/warnings ................................................... FAILED at
test 710
t/io/socketpair ................................................
FAILED--unexpected output at test 0
In the list of all failed tests at the end of the run of all tests they appear
as
../lib/warnings.t
io/socketpair.t
All occurrences of the file names socketpair.t and warnings.t in the
distribution directories:
DISK$ORACLE5:[PERL.perl-5^.32^.1.dist.base.t]warnings.t;1
DISK$ORACLE5:[PERL.perl-5^.32^.1.lib]warnings.t;1
DISK$ORACLE5:[PERL.perl-5^.32^.1.cpan.Socket.t]socketpair.t;1
DISK$ORACLE5:[PERL.perl-5^.32^.1.t.io]socketpair.t;1
(These two warnings.t files are not identical, presumably
DISK$ORACLE5:[PERL.perl-5^.32^.1.lib]warnings.t is the failed test.
These two socketpair.t files are not identical, presumably
DISK$ORACLE5:[PERL.perl-5^.32^.1.t.io]socketpair.t is the failed test.)
The command
$ @[.vms]test .EXE "" -"v" [.io]socketpair.t
reruns that test with more detailed output. Using similar syntax for all
failing tests that are reported
with names specified as "t/..." also reruns the corresponding failing test.
I didn't find the proper command to rerun the test on the warnings.t file (or
any of the other test names that did
not match the "t/..." syntax).
-- Ed Miller
________________________________
From: Craig Berry <craigbe...@mac.com>
Sent: Monday, February 15, 2021 7:25 PM
To: Miller, Edward S. <e...@slac.stanford.edu>; vmsperl@perl.org
<vmsperl@perl.org>
Subject: Re: Experience installing on Alpha VMS 8.3
On Feb 15, 2021, at 5:07 PM, Miller, Edward S. via vmsperl <vmsperl@perl.org>
wrote:
>
> We have recently installed PERL v5.32.1 on our Alpha VMS 8.3 system using the
> distribution from PERL.ORG.
> The README.VMS suggests that:
> "Regardless of how confident you are, make a bug report to the VMSPerl
> mailing list."
Thanks for the report. Haven't had many lately.
> This is not really a complete bug report, but more a summary of my experience
> doing the install
> and an attempt to find out whether anyone is really interested in a more
> specific 'bug report'.
>
> As far as we can tell, the install for us was successful. Our user who
> reported that his code would not
> work with our old perl version (5.004_04) reports that it now works with the
> newly installed v5.32.1.
Wow. 5.004_04 was from 1997, so that's a big jump.
> I have one change to the readme.vms I would strongly suggest: state
> unequivocally that the install procedures should
> be done using an ODS-5 disk, and that you are (very likely?) wasting your
> time attempting it on an ODS-2 disk.
> (In our case the first MMK operation failed eventually--in two different
> ways, with two different MMK versions--
> using an ODS-2 disk.)
Fair enough. Things go from possible to not recommended to just won't work and
the docs don't always keep up. README.vms does say the following:
------
ODS-5 and Extended Parse
All development and testing of Perl on VMS takes place on ODS-5 volumes with
extended parse enabled in the environment via the command C<SET
PROCESS/PARSE=EXTENDED>.
Latent support for ODS-2 volumes (including on VAX) is still present, but the
number
of components that require ODS-5 features is steadily growing and ODS-2 support
may be
completely removed in a future release.
------
That's not strictly true anymore either as VAX support is long gone. So yes,
there are some documentation updates needed.
> The step @configure "-des" was apparently successful (assuming the many
> "NOT found" messages are benign).
It will find more things on v8.4 than v8.3 (which is now a pretty old release)
and even more things on v8.4-2 with the C99 patch applied. It's normal to have
some things not found.
> The first "MMK" step had several "%CC-I" compiler messages, the most
> suspicious of which was
>
> neg = PL_statcache.st_ino < 0;
> ..................^
> %CC-I-QUESTCOMPARE, In this statement, the unsigned expression
> "PL_statcache.st_ino" is being compared with a relational
> operator to a constant whose value is not greater than zero. This might
> not be what you intended.
> at line number 2949 in file DISK$ORACLE5:[PERL.perl-5^.32^.1]pp_sys.c;1
That line of code is guarded like so:
CLANG_DIAG_IGNORE_STMT(-Wtautological-compare);
GCC_DIAG_IGNORE_STMT(-Wtype-limits);
neg = PL_statcache.st_ino < 0;
GCC_DIAG_RESTORE_STMT;
CLANG_DIAG_RESTORE_STMT;
We could add equivalent pragmas to make the VMS C compiler ignore it as well
but I question whether it's worth 10 lines of code to negate a warning on one
line of code. The author of that line insists that it's idiomatic C and
there's nothing wrong with it.
>
> The step "MMK test" completed and summarized its results with
> "Failed 58 tests out of 2350, 97.53% okay."
>
> I ran the procedure to get details of some of these failures using
> $ @[.vms]test .EXE "" -"v" (filespec)
> However I was successful in getting the proper syntax for (filespec) only
> for those that were originally
> reported as FAILED with a file specification that started with "t/", not
> the others.
58 failures is on the high side but as I said, VMS v8.3 is pretty old and I
haven't built on it in years. It's problematic that the test driver doesn't
work for tests outside of the [.t] directory. If you give me an example it's
possible I could spot a way to run it.
> The step "MMK install" was apparently successful (assuming the many "Can't cd
> to (cpan/IO-Compress/) xxx.tmp: no such file or directory"
> messages are benign).
I believe they are benign as far as getting things installed. There is a bug
in something IO::Compress uses (I think it's File::Temp) that causes the
warning but it doesn't seem to prevent it from working.
>
> A thanks to all of those who contributed to making PERL functional on VMS
> systems.
>
> -- Ed Miller SLAC NAL.
________________________________________
Craig A. Berry
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
