On Sat Aug 25 10:22:49 2007, [EMAIL PROTECTED] wrote: > I haven't gotten these warnings when doing coverage analysis for several > months. So we can close this ticket.
It turns out that the reason I haven't been getting these warnings is that I wasn't looking for them -- in a manner of speaking. In recent months I haven't been running coverage analysis on my iBook because it's so much slower than my Linux server. For unknown reason, I was also not getting those warnings on Linux. So I closed the ticket, not realizing that the fact that I wasn't getting the warnings was that I wasn't doing the coverage analysis on the box that was generating them! Last night I ran coverage analysis on the iBook for the first time in months and got all these warnings. So I'm re-opening the ticket. But there's another problem lurking here. As I recently posted on the perl.qa mailing list (http://tinyurl.com/36zssb), I've been experiencing problems using Devel::Cover with my configuration tests. It will work perfectly for a week or so, then start to have individual test files return this result: t/configure/028-option_or_data....................dubious Test returned status 0 (wstat 11, 0xb) after all the subtests completed successfully Problems: (1) This causes the coverage analysis to fail. And since the first step is 'cover -delete', all coverage results currently existing on my server get wiped out. (2) Such a test file always passes when run without Devel::Cover. When I open up such a test file to look at it, I can occasionally fix it thru voodoo code, e.g., adding one test (pass("Keep Devel::Cover happy");) that doesn't really add anything to the test but seems to shut off the problem cited above. (3) Sometimes I'll fix the problem on one file, only to have the problem suddenly crop up on the next test file or another file later in the test suite. So this was one of those problems that are so maddening because they appear to be intermittent. But yesterday I noticed two things: (1) When the problems did occur, they never occurred any earlier in the test suite than the test cited above: t/configure/028-option_or_data.t. (2) That same file was the first one on which (yesterday, at least) I got the "subroutine redefined" warning. Upon inspection, I realized that 028 was also the first file in the test suite sequence to use a testing function I wrote, Parrot::Configure::Test::test_step_thru_runstep(). When you go to test certain configuration steps, you cannot do so unless you know the results of earlier configuration steps. test_step_thru_runstep() runs a simulation of those steps. So I'm hypothesizing that something in test_step_thru_runstep() (a) generates at least some of the 'subroutine redefined' warnings I get when I do coverage analysis on the iBook; and (b) underlies the 'Test returned status 0' error which is borking my coverage analysis on Linux. kid51
