in reply to Re^2: parsing and comparing test reports
in thread parsing and comparing test reports

Maybe this link will work better for you? link Thanks for even considering doing that. I'm lost in a report jungle.

:) No problem ... FWIW that part of the internet is accessible to me now

The essence of all the reports is the same, your test is checking for some string having 69.231 and it doesn't have that

My opinion there is probably nothing more to be learned from these reports (no real point in parsing them), failing and passing machines are fairly identical, the numbers reported are also the same except for the percentage

So the problem is with the printing of the report

Either you're giving sprintf what it doesn't like (wrong format), or sprintf implementation is broken on machine (unlikely but not impossible )

So if I were you, next move would be to add  warn "\n\n", Data::Dump::pp( \%formats, \%stats  ), "\n\n"; around at   line 1700 "calculate results" in Algorithm/AM.pm

and push it to cpan


The essence
bad good
Number of data items: 5 Total Excluded: 5 Nulls: exclude Gang: squared Number of active variables: 3 Statistical Summary e 4 0.000% r 9 0.000% ---------------------------------------- 340282366920938463463374607431768211455G
Number of data items: 5 Total Excluded: 5 Nulls: exclude Gang: squared Number of active variables: 3 Statistical Summary e 4 30.769% r 9 69.231% -- 13

# Failed test 'Chapter 3 data, counting pointers' # at t/01-classify.t line 29. # got: "Test items left: 1\x{0a}Time: 22:05:32\x{0a}3 1 2\x{0 +a}0/1 22:05"... # length: 525 # doesn't match '(?^:e\s+4\s+30.769%\v+r\s+9\s+69.231%)'

These are the reports that are essentially verbatim

http://www.cpantesters.org/cpan/report/e3cf19e0-9104-11e3-a9c1-1212e1b +fc7aa http://www.cpantesters.org/cpan/report/a5d58f40-9102-11e3-bce1-5d00e1b +fc7aa http://www.cpantesters.org/cpan/report/60a792e6-90fe-11e3-bd14-e3bee46 +21ba3 http://www.cpantesters.org/cpan/report/b1ed04d2-90eb-11e3-bd14-e3bee46 +21ba3 http://www.cpantesters.org/cpan/report/c1cec644-90e4-11e3-8f3c-fc23d5a +f1b80 http://www.cpantesters.org/cpan/report/9977cb68-90c7-11e3-bd14-e3bee46 +21ba3 http://www.cpantesters.org/cpan/report/caaee1d4-90a5-11e3-93ec-1875e0b +fc7aa http://www.cpantesters.org/cpan/report/2551f684-9098-11e3-982b-d442e0b +fc7aa http://www.cpantesters.org/cpan/report/e1cacd14-9097-11e3-b1d0-1a39e0b +fc7aa http://www.cpantesters.org/cpan/report/df8119d2-9097-11e3-b1d0-1a39e0b +fc7aa http://www.cpantesters.org/cpan/report/dd494586-9097-11e3-b1d0-1a39e0b +fc7aa http://www.cpantesters.org/cpan/report/d8c26b28-9097-11e3-b1d0-1a39e0b +fc7aa http://www.cpantesters.org/cpan/report/041a98e0-78cd-1014-b688-8f2a93e +8ee67 http://www.cpantesters.org/cpan/report/b7342604-910f-11e3-bd14-e3bee46 +21ba3 http://www.cpantesters.org/cpan/report/d3744b62-9111-11e3-bd14-e3bee46 +21ba3

The rest you can ignore

This one had extra fail due to dzil stuff (ignore, probably outdated zilla)

http://www.cpantesters.org/cpan/report/db123494-9097-11e3-b1d0-1a39e0bfc7aa

This one is probably identical except some of the fail test output is missing, probably tester has old version of Test::More , maybe missing IPC::Run,

http://www.cpantesters.org/cpan/report/041a98e0-78cd-1014-b688-8f2a93e8ee67

This one had old perl , so ignore this report

 Perl v5.14.0 required--this is only v5.10.1, stopped at Makefile.PL http://www.cpantesters.org/cpan/report/d648825a-910b-11e3-b4a0-401c3071082f

as its purely testers problem (probably old version of testers toolchain)

If you want to do something you could add an extra key (MIN_PERL_VERSION) to writemakefile, see http://wiki.cpantesters.org/wiki/CPANAuthorNotes

Replies are listed 'Best First'.
Re^4: parsing and comparing test reports
by nglenn (Beadle) on Feb 09, 2014 at 03:11 UTC
    Thanks for looking at all of that for me! I am glad to have someone tell me not to bother doing a bunch of extra work.

    I will try doing that. Actually, maybe I'll use Devel::Peek for it. The thing about that huge number is that it's a custom big integer. It is created in AM.xs (grandtotal), and is an array of longs. In the XS normalize function it has a string and double representation added to it, and I suspected that it would be susceptible to overflow or something if the datatypes have the wrong bit size. Maybe I'll follow your advice on printing my suspicions and just add a ton of print statements in the XS, too.

Re^4: parsing and comparing test reports
by nglenn (Beadle) on Feb 11, 2014 at 23:31 UTC

    Not sure if you'll even get this message since you were signed in anonymously, but I just wanted to say thanks. I uploaded 8 releases to CPAN, each with various printing statements, and found that the problem was an uninitialized array element, which may or may not be garbage in C. So there was a bug on every system, but it just showed up in only some systems. We're all very happy to have found it!