Paul Marquess wrote:
Thanks John. I've CCed Tom Hughes for the IO:Zlib results.
I did not realize at the time that I did the tests that they were not
the same ZLIB module.
I see that the majority of the failures match those that Abe Timmerman
reported earlier today. Apart from running with bleed what else is different
between the two versions that could account for the extra failures you are
seeing? Is it anything to do with running the VMS C library in UNIX
emulation mode that you mentioned?
I am not running the VMS C Library in UNIX mode. I am trying to get all
unknown blead issues on VMS resolved so that I can start getting Perl to
work when the C library is in that mode.
It might have been one of my changes, or it might just be something that
is different between our environments.
See what happens below to the external.t test when I create a path
logical name which has no meaning to VMS. Before it was silently
skipped, and now it is a failure.
And this is still with out the C library in UNIX mode.
I will try to look at this some more later, I have blead perl and this
module all built in debug so I should be able to find the real reason
for these errors. Once I find the reason, it is likely that I could
really use help for the correct fix.
There are a number of places that the VMS specific code is failing
silently because of a bug, and this is not detected because there is
some fallback code that compensates. But there are also consequences to
fixing those bugs as they expose others.
lib/IO/Zlib/t/basic.t 15 of 15 ok.
lib/IO/Zlib/t/external.t
1..0 # Skip: no /usr/bin/gzip
If the GNV package is installed on VMS, then gzip is
available at /bin/gzip. As I had nothing in /usr, I
set up a logical name so that /usr/bin/gzip should
find a gzip. This test still produced the same output.
Also gzip may (or may not) be present anywhere on the
system with a foreign command (shell alias) or the
DCL$PATH search list used to find it.
The test is verifying that '/usr/bin' is in $ENV{"PATH"}, an environment
variable generally ignored on VMS. Easy to hack, but then the test
fails later:
lib/IO/Zlib/t/external.t
ok 17
>: non-translatable vms error code: 0x186D4
%rms-f-syn, file specification syntax error
PROJECT_ROOT:[PERL-BLEAD.t]test.gz;: no such file or directory
ok 18
not ok 21
ok 22
Can't call method "gzread" on an undefined value at ../lib/IO/Zlib.pm
line 472.
%RMS-E-FNF, file not found
I recon so.
ext/Compress/Zlib/t/03zlib-v1.t 351 of 351 ok
ext/Compress/Zlib/t/04def.t fails on test 102 and dies.
not ok 102 - create IO::Gzip
# Failed test ([-.ext.compress.zlib.t]04def.t at line 322)
Can't call method "fileno" on an undefined value at
[-.ext.compress.zlib.t]04def.t line 324.
# Looks like you planned 1781 tests but only ran 102.
# Looks like your test died just after 102.
%SYSTEM-F-ABORT, abort
Not sure why this is failing for you but passing for Abe.
I will have to investigate. There are enough Phase-of-Moon issues
involved that it could be anything.
Of this script, tests 31,48,52,56,60,68 are expected behavior
on VMS when the C library is not in a UNIX emulation mode.
I do not have blead Perl able to fully work in this mode yet.
At the time that I wrote this, I had forgotten that readdir() seems to
suppresses the trailing "." so this is an inconsistency.
There is a problem with readdir() suppressing the trailing dot on a NULL
file type in VMS mode. In some cases it is significant because if it is
not present, VMS may add a default type when it tries to use the file.
system("[]PERL") ! runs the file []Perl.exe
system("[]PERL.") ! runs the file []Perl.
-John
[EMAIL PROTECTED]
Personal Opinion Only
