Re: Test errors for 5.8.3
At 10:25 PM -0400 4/7/04, John E. Malmberg wrote: Craig A. Berry wrote: If there is a discrepancy between your current offset from UTC and your timezone rule, then something that is explicitly testing that the two are in synch may run into problems. Anything that uses UTC or offsets from it (in short, anything using the standard C library functions) would have the same problem during the window between the time change and the system clock being reset. The actual problem is that there are multiple independent ways of specifying the offset from the local time to UTC on OpenVMS for historical reasons. I had a conversation with the editor of the OpenVMS FAQ about this today, and there will likely be an update to at least the OpenVMS FAQ. The bottom line is to prevent problems, if you are not changing to/from DST at the exact time that the timezone rule states, you need to use the ZIC utility to create a new timezone. Good to know about. Just to be clear, the particular problem that manifested itself is something that happens when running the Perl test suite (specifically [.lib]vmsish.t) during the window between the DST change and the clock reset. vmsish.t uses the logical name SYS$TIMEZONE_DIFFERENTIAL as a base for comparison to test various timezone-related functions in Perl, which are in turn (usually) based on CRTL functions.* I think the safest thing to say is that running the test during this window is unsupported. *For ancient CRTLs that have a non-functioning gmtime(), Perl does its best to determine the timezone offset using SYS$TIMEZONE_DIFFERENTIAL, and if it can't do that because the logical is not defined, it assumes the local time is UTC. Perl also has rudimentary timezone rule parsing capabilities, again for very ancient CRTLs. I leave the definition of ancient intentionally ambiguous since I don't know at what point in the century previous to ours these CRTL issues were resolved. -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
Re: Test errors for 5.8.3
Craig A. Berry wrote: At 11:00 PM -0400 4/6/04, John E. Malmberg wrote: Assorted other issues snipped (I may get back to comment on them at some point, but no promises). No problems. If there is a discrepancy between your current offset from UTC and your timezone rule, then something that is explicitly testing that the two are in synch may run into problems. Anything that uses UTC or offsets from it (in short, anything using the standard C library functions) would have the same problem during the window between the time change and the system clock being reset. The actual problem is that there are multiple independent ways of specifying the offset from the local time to UTC on OpenVMS for historical reasons. I had a conversation with the editor of the OpenVMS FAQ about this today, and there will likely be an update to at least the OpenVMS FAQ. The bottom line is to prevent problems, if you are not changing to/from DST at the exact time that the timezone rule states, you need to use the ZIC utility to create a new timezone. And this was not obvious to me before this incident, and I am sure based on my conversation with the FAQ editor that I am not the only one to miss this. :-) -John [EMAIL PROTECTED] Personal Opinion Only
Re: Test errors for 5.8.3
Craig A. Berry wrote: At 9:14 PM -0400 4/4/04, John E. Malmberg wrote: I just have built Perl 5.8.3 on OpenVMS Alpha 7.3-2. When running the tests, the vmsish test failed. lib/vmsish...FAILED at test 25 That was patched here: http://public.activestate.com/cgi-bin/perlbrowse?patch=3 Patch applied, and the Alpha tests restarted. They took 51 minutes on a 600 Mhz. All tests pass now on Alpha. The same build on OpenVMS VAX 7.3 failed 8 tests. PYTHON search build.log failed t/op/packFAILED at test 0 Hmm. That would be good to know about. What do you get from $ @[.vms]test .exe -v [.op]pack.t $ If F$Mode() .nes. INTERACTIVE Then Define/Nolog PERL_SKIP_TTY_TEST 1 $ MCR Sys$Disk:[]Perl. -I[-.lib] TEST. -v [.OP]PACK.T Improperly handled condition, image exit forced. Signal arguments Stack contents Number = 0003 Name = 04B400207785 0016C111 03C00007 0008 0001 022D2AEA 4080 Register dump R0 = 7FFF R1 = R2 = R3 = 7FFF R4 = R5 = 8000 R6 = 0001 R7 = 0008 R8 = 0009 R9 = 0043 R10= 00207784 R11= 0001 AP = 7FE9FDE0 FP = 7FE9FDA0 SP = 7FE9FE14 PC = 0016C111 PSL= 03C0 t/OP/PACKFAILED at test 0 Failed 1 test script out of 0, 0.00% okay. I guess I will need to do a debug build. That will probably take a while. PYTHON @local_root:[00]build_gnv_perl.com/out=build.log %DCL-E-OPENOUT, error opening _$1$DIA1:[00].DAT; as output -RMS-E-PRV, insufficient privilege or file protection violation Maybe a little longer. Now why is configure trying to put a file there? In trying to chase that down I get: Your PGFLQUOTA of 10 appears too small to build perl5. Now that looks interesting as the command file is supposed to allow that much. I fix that and still can not find the error, so am now running the procedure with out the output going to a log file, and now the build is running, probably well into tomorrow. t/op/statFAILED at test 75 This could be timezone setting related. lib/ExtUtils/t/basic.FAILED at test 26 lib/ExtUtils/t/Constant..FAILED at test 23 Dunno about these. There could be directory depth issues in the tests themselves. I thought ODS-2 on OpenVMS 7.3 allows deep directories on VAX. Well we look at this after I get a debug build. lib/Math/BigInt/t/bare_mbi...FAILED at test 2600 lib/Math/BigInt/t/bigintpm...FAILED at test 2600 lib/Math/BigInt/t/sub_mbiFAILED at test 2600 I think the BigInt module uses doubles to store chunks of very large integers. It probably makes some assumption that blows up on the very limited exponent range of D_FLOAT, which is still the default for Perl floating point on VAX. You could do a G_FLOAT build or hack into the innards of BigInt enough to see what it needs. The author has been very helpful sorting out similar situations in the past. Will look at that also. Looks like trying the G_FLOAT build for VAX might be the easiest thing to try. lib/vmsish...FAILED at test 22 Any chance you haven't reset the clock since the daylight savings change? Considering that the build started before the DST, and the tests probably did not finish until after DST, Yes. But if perl is using different rules than the system is, this could be a problem at other sites. At my former employer, the time change was delayed until the end of a shift. I hope this does not indicate a window where perl scripts could misbehave. Failed 8 test scripts out of 760, 98.95% okay. This has been better in recent memory. I don't have any vaxen and not many (any?) people who do are in the habit of building development releases on a regular basis and reporting or fixing the failures that show up. I will do what I can find time for. The VAX is idle and has nothing better to do, so after I get something working on Alpha, I copy it over the VAX. Now I also have to figure out how to set the [EMAIL PROTECTED] address subscribed to this list to a nomail setting. Now to start applying the BASH patches to the kit. -John [EMAIL PROTECTED] Personal Opinion Only
Test errors for 5.8.3
I just have built Perl 5.8.3 on OpenVMS Alpha 7.3-2. When running the tests, the vmsish test failed. lib/vars.ok lib/vmsish...FAILED at test 25 lib/warnings.ok The same build on OpenVMS VAX 7.3 failed 8 tests. PYTHON search build.log failed t/op/packFAILED at test 0 t/op/statFAILED at test 75 lib/ExtUtils/t/basic.FAILED at test 26 lib/ExtUtils/t/Constant..FAILED at test 23 lib/Math/BigInt/t/bare_mbi...FAILED at test 2600 lib/Math/BigInt/t/bigintpm...FAILED at test 2600 lib/Math/BigInt/t/sub_mbiFAILED at test 2600 lib/vmsish...FAILED at test 22 Failed 8 test scripts out of 760, 98.95% okay. -John [EMAIL PROTECTED] Personal Opinion Only
Test errors for 5.8.3
I just have built Perl 5.8.3 on OpenVMS Alpha 7.3-2. When running the tests, the vmsish test failed. lib/vars.ok lib/vmsish...FAILED at test 25 lib/warnings.ok The same build on OpenVMS VAX 7.3 failed 8 tests. PYTHON search build.log failed t/op/packFAILED at test 0 t/op/statFAILED at test 75 lib/ExtUtils/t/basic.FAILED at test 26 lib/ExtUtils/t/Constant..FAILED at test 23 lib/Math/BigInt/t/bare_mbi...FAILED at test 2600 lib/Math/BigInt/t/bigintpm...FAILED at test 2600 lib/Math/BigInt/t/sub_mbiFAILED at test 2600 lib/vmsish...FAILED at test 22 Failed 8 test scripts out of 760, 98.95% okay. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Test errors for 5.8.3
At 9:14 PM -0400 4/4/04, John E. Malmberg wrote: I just have built Perl 5.8.3 on OpenVMS Alpha 7.3-2. When running the tests, the vmsish test failed. lib/vars.ok lib/vmsish...FAILED at test 25 lib/warnings.ok That was patched here: http://public.activestate.com/cgi-bin/perlbrowse?patch=3 The same build on OpenVMS VAX 7.3 failed 8 tests. PYTHON search build.log failed t/op/packFAILED at test 0 Hmm. That would be good to know about. What do you get from $ @[.vms]test .exe -v [.op]pack.t ? t/op/statFAILED at test 75 This could be timezone setting related. lib/ExtUtils/t/basic.FAILED at test 26 lib/ExtUtils/t/Constant..FAILED at test 23 Dunno about these. There could be directory depth issues in the tests themselves. lib/Math/BigInt/t/bare_mbi...FAILED at test 2600 lib/Math/BigInt/t/bigintpm...FAILED at test 2600 lib/Math/BigInt/t/sub_mbiFAILED at test 2600 I think the BigInt module uses doubles to store chunks of very large integers. It probably makes some assumption that blows up on the very limited exponent range of D_FLOAT, which is still the default for Perl floating point on VAX. You could do a G_FLOAT build or hack into the innards of BigInt enough to see what it needs. The author has been very helpful sorting out similar situations in the past. lib/vmsish...FAILED at test 22 Any chance you haven't reset the clock since the daylight savings change? Failed 8 test scripts out of 760, 98.95% okay. This has been better in recent memory. I don't have any vaxen and not many (any?) people who do are in the habit of building development releases on a regular basis and reporting or fixing the failures that show up. -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
