Re: gcov/xs trickery.

2002-02-09 Thread Paul Johnson

On Fri, Feb 08, 2002 at 04:29:33PM +, Richard Clamp wrote:
> Last night at the London.pm meeting I mentioned to Nick Clark that I
> was puzzling over the problem of ensuring suitable test coverage for
> ..xs modules, to which he kindly put me out of my misery and pointed me
> at gcov.
> 
> This is the recipie I'm currently working on.  It's a little messy,
> and guaranteed fragile, but it works for me, and that's a step
> forwards.
> 
> In Makefile.PL add:
> 
> sub MY::postamble {
> return < gcov:
> \trm -f `basename \$(XS_FILES)`.{bb,bbg,da,o}
> \t\$(MAKE) test CCFLAGS="\$(CCFLAGS) -fprofile-arcs -ftest-coverage"
> \tgcov \$(XS_FILES)
> EOF
> }

I suspect that adding -O0 to the flags would be useful, otherwise the
optimiser can remove some of the contructs you are trying to test.

> Then C and poke around at the generated Foo.xs.gcov
> results.

I have been (slowly) investigating how to integrate gcov with the
backend of Devel::Cover.  I deliberately designed the backend to be
language agnostic.  Unfortunately, I've not had much time to work on it
recently.

One thing has become very apparent though.  Perl still has many untested
corners.

Here's where I'm up to.  This is from a debugging bleadperl last night:

 -- -- -- -- -- -- --
File   stmt branch   path   condpod   time  total
 -- -- -- -- -- -- --
av.c  80.84n/an/an/an/an/a  80.84
deb.c  0.00n/an/an/an/an/a   0.00
doio.c75.70n/an/an/an/an/a  75.70
doop.c86.90n/an/an/an/an/a  86.90
dump.c55.46n/an/an/an/an/a  55.46
ext/B/B.c 40.88n/an/an/an/an/a  40.88
ext/B/B.xs50.17n/an/an/an/an/a  50.17
ext/B/C/C.c0.00n/an/an/an/an/a   0.00
ext/B/C/C.xs   0.00n/an/an/an/an/a   0.00
ext/B/defsubs.h  100.00n/an/an/an/an/a 100.00
ext/ByteLoader/ByteLoader.c   24.14n/an/an/an/an/a  24.14
ext/ByteLoader/ByteLoader.xs   0.00n/an/an/an/an/a   0.00
ext/ByteLoader/byterun.c   0.00n/an/an/an/an/a   0.00
ext/Cwd/Cwd.c 89.66n/an/an/an/an/a  89.66
ext/Cwd/Cwd.xs69.05n/an/an/an/an/a  69.05
ext/Data/Dumper/Dumper.c  93.33n/an/an/an/an/a  93.33
ext/Data/Dumper/Dumper.xs 87.05n/an/an/an/an/a  87.05
ext/Devel/DProf/DProf.c   65.22n/an/an/an/an/a  65.22
ext/Devel/DProf/DProf.xs  81.72n/an/an/an/an/a  81.72
ext/Devel/PPPort/PPPort.c 90.00n/an/an/an/an/a  90.00
ext/Devel/PPPort/PPPort.xs   100.00n/an/an/an/an/a 100.00
ext/Devel/PPPort/module2.c   100.00n/an/an/an/an/a 100.00
ext/Devel/PPPort/module3.c   100.00n/an/an/an/an/a 100.00
ext/Devel/Peek/Peek.c 23.27n/an/an/an/an/a  23.27
ext/Devel/Peek/Peek.xs 5.22n/an/an/an/an/a   5.22
ext/Digest/MD5/MD5.c  79.73n/an/an/an/an/a  79.73
ext/Digest/MD5/MD5.xs 92.24n/an/an/an/an/a  92.24
ext/DynaLoader/DynaLoader.c   63.08n/an/an/an/an/a  63.08
ext/DynaLoader/DynaLoader.xs  67.57n/an/an/an/an/a  67.57
ext/DynaLoader/dlutils.c  50.00n/an/an/an/an/a  50.00
ext/Encode/8859_def.h100.00n/an/an/an/an/a 100.00
ext/Encode/EBCDIC_def.h  100.00n/an/an/an/an/a 100.00
ext/Encode/EUC_JP/EUC_JP.c 0.00n/an/an/an/an/a   0.00
ncode/EUC_JP/EUC_JP_def.h   0.00n/an/an/an/an/a   0.00
ext/Encode/Encode.c   47.06n/an/an/an/an/a  47.06
ext/Encode/Encode.xs  57.36n/an/an/an/an/a  57.36
ext/Encode/Symbols_def.h 100.00n/an/an/an/an/a 100.00
ext/Encode/encengine.c91.84n/an/an/an/an/a  91.84
ext/Fcntl/Fcntl.c 93.75n/an/an/an/an/a  93.75
ext/Fcntl/constants.c 17.22n/an/an/an/an/a  17.22
ext/Fcntl/constants.xs82.35n/an/an/an/an/a  82.35
ext/File/Glob/Glob.c  92.31n/an/an/an/an/a  92.31
ext/File/Glob/Glob.xs100.00n/an/an/an/an/a 100.00
ext/File/Glob/bsd_glob.c  69.60n/an/an/an/an/a  69.60
ext/File/Glob/constants.c 34.41n/an/an/an/an/a  34.41
ext/File/Glob

Re: gcov/xs trickery.

2002-02-09 Thread Richard Clamp

On Sat, Feb 09, 2002 at 05:25:27PM +0100, Paul Johnson wrote:
> I suspect that adding -O0 to the flags would be useful, otherwise the
> optimiser can remove some of the contructs you are trying to test.

Good call.

> > Then C and poke around at the generated Foo.xs.gcov
> > results.
> 
> I have been (slowly) investigating how to integrate gcov with the
> backend of Devel::Cover.  I deliberately designed the backend to be
> language agnostic.  Unfortunately, I've not had much time to work on it
> recently.
> 
> One thing has become very apparent though.  Perl still has many untested
> corners.

We were speculating a little about that too.  63% is certainly better
than my most cynical guess, and with enough room for improvement that
it looks like it could be grounds for sufficient fun.

Is the code you used due for a release soon?  Can I make it go faster
by asking less dumb questions?  And where do bees come from?

> Here's where I'm up to.  This is from a debugging bleadperl last night:

I was going to look at both those things tomorrow, but I'm more than
happy to let you have it.  It gives me time to arrange going to
conferences and practice breaking things.

While the thought is in my brain, are you planning to talk at any
conferences this year?  I know I'd like to see a Devel::Cover
flavoured talk, and I suspect I'm not alone.

It's also helped me enough recently retrofitting tests to some code at
work that I suspect that I owe you at least a drink or six.

-- 
Richard Clamp <[EMAIL PROTECTED]>
   do you believe in the one big song?