From: Abe Timmerman [mailto:[EMAIL PROTECTED]
> Op een mooie zomerdag (Sunday 11 September 2005 19:14),schreef Paul > Marquess: > > From: John E. Malmberg [mailto:[EMAIL PROTECTED] > > > > > This is the status of Blead 25366 (Sept 9, 2005 download) on VMS. > > > > > > Only the ZLIB test is failing for unknown reasons. Paul, if your > > > changes got applied to blead, then they are still not working. > > > Otherwise, I have pulled down the latest ZLIB from CPAN and will try > > > that one out. > > > > No, the changes are only on CPAN. > > > > This is the latest snapshot > > > > http://search.cpan.org/CPAN/authors/id/P/PM/PMQS/Compress-Zlib- > 2.000_02.tar > >. gz > > This is with 5.8.6 on Alpha: Thanks Abe. There aren't as many test failing as I was expecting there to be on an OS that is quite different from the Unix variants. The good news is that the tests that John reported as failing with the core Compress::Zlib are indeed fixed with this new version. Also all the tests below are failing (I think) because of non-portable coding in the test suite, not in the code itself. > t/14gzopen...... > > # Failed test (t/14gzopen.t at line 421) > > # Failed test (t/14gzopen.t at line 424) > > # Failed test (t/14gzopen.t at line 425) > # gzerrno 0 > # Looks like you failed 3 tests of 186. OK, those failing tests are checking that gzopen can detect a non-writable file. At the moment I'm creating one with this my $name = "test.gz" ; ... writeFile($name, "abc"); chmod 0, $name ; I imagine the "chmod 0, $name" is the non-portable part that I'm tripping over. Can you try changing line 419 of t/14gzopen.t to this please and report if that makes any difference? chmod 0444, $name ; ... > t/22append...... > Cannot open abcde.out: file currently locked by another user > # Looks like you planned 490 tests but only ran 150. > # Looks like your test died just after 150. > %SYSTEM-F-ABORT, abort > dubious > Test returned status 44 (wstat 1024, 0x400) > (VMS status is 44) > DIED. FAILED tests 151-490 > Failed 340/490 tests, 30.61% okay I think this may be tripping over some debug code in the test harness. Under VMS if you open a file for writing, can you then open it again for reading whilst the write filehandle is still active? I think that is where this error may be coming from Cannot open abcde.out: file currently locked by another user Can you edit t/22append.t and comment out lines with calls to hexDump -- there should only be three, on lines 269, 287 and 292. All should look like this hexDump($buffer); ... > t/16top......... > glob failed (can't start child: invalid argument) at /P5M/ > COMPRESS-ZLIB-2_000_01 > /blib/lib/Compress/Zlib/Common.pm line 232. > legal or die??? at /P5M/COMPRESS-ZLIB-2_000_01/blib/lib/Compress/Zlib/ > Common.pm > line 237. That is tripping over file globbing. The test is failing when I try to execute this glob "in[1234]" and there are 4 matching files "in1", "in2", "in3" and "in4". Hmm, just had a read at perlvms.pod -- is VMS complaining because "[1234]" looks like a directory or does it not support '[1234]' as a wildcard character class? ... > t/globmapper.... > > # Failed test (t/globmapper.t at line 84) > # Structures begin differing at: > # $got->[0][0] = 'td/abc1.' > # $expected->[0][0] = 'td/abc1' > > # Failed test (t/globmapper.t at line 89) > # Structures begin differing at: > # $got->{td/abc3} = Does not exist > # $expected->{td/abc3} = 'td/abc3.X' > ... > # Looks like you failed 8 tests of 68. Again, file globbing is the problem. I created test files "abc1", "abc2" and "abc3" and it looks like when you run this glob "abc*" you get this back "abc1.", "abc2.", "abc3." -- all have a trailing period appended. It been about 10 years since I worked on VMS, but I seem to remember that ALL vms files have extensions. So the trailing period is just an empty file extension. Is that correct? If so, and there isn't a way to get configure the vms glob emulation to work just like Unix, I can rework my tests so that they all my test files have extensions. Paul
