TPF Devel::Cover grant report Week 11

[Paul Johnson]

In accordance with the terms of my grant from TPF this is the report for
week 11 of my work on improving Devel::Cover.

This report covers 28.07 to 03.08.

One of the nice things about having this grant and being able to spend
more time working on Devel::Cover than I would otherwise have been able
to is that I'm getting feedback from my reports and checkins, and that I
have more time to be able to follow up on it.

Over the years I've received a lot of mail regarding Devel::Cover and
I've not always been able to properly reply to it all. In some cases
I'm sure I've not replied at all. If anyone has sent me something that
needs a reply, please feel free to remind me either by mail or,
preferably, on github if appropriate.

So I've started looking back at some of my outstanding mail (starting
with those where I have been prompted). One of the first I looked at
was about a problem I have known about for many years.

When you want to know your coverage there are two main phases: the first
in which you exercise your code and the coverage data is collected, and
the second in which that data is displayed, hopefully in a format which
makes it easy to understand. In each phase you can limit the amount of
coverage information both by limiting the files for which you collect
data and by limiting the criteria.

In general it is best to collect as little data as possible in the first
phase. This will reduce the size of the coverage database but, more
importantly, it will make the running of the tests faster. But there
are times when, having collected the data, you only want to display a
subset of it. Thus you can also filter the data when you generate your
report.

When the report is generated, by default, a summary of the coverage is
printed. This summary has always been a summary of all the data in the
database, rather than a summary of the data in the report. I remember
looking into this many years ago and deciding that it was going to be
complicated to fix and this is probably why I've never seriously looked
at the problem up to now. But now I have, and the fix wasn't as
complicated as I had imagined that it would be. There's probably a
lesson of some sort there.

I also took a look at RT 49916 which relates to file and directory
permissions with respect to code that changes EUID. I think this is
fixed but I'm waiting to hear back before closing the ticket.

I had a look into a cpantesters report on bleadperl which pointed back
to perl #113684, which is a report I've written about before. Father
Chrysostomos has made some commits to address the problem and this has
lead to a minor change in B::Deparse which affects Devel::Cover. This
is somewhat dictated by the limitations of B::Deparse. The full details
are in the RT thread, but the long and short of it all is that these
changes are here to stay and so I will adjust Devel::Cover accordingly
as soon as 5.17.3 is released.

I've also been running cpancover jobs every so often. This takes quite
a time to finish but I like to think of CPAN and cpancover as my
extended test suite. When I see something that doesn't look right I can
then go in and investigate in a bit more detail. I started running
cpancover with perl 5.16.1-RC1 to see how it pans out. See the results at
http://cpancover.com

At the QA hackathon this year I put together a Vim plugin to display
coverage information within Vim. I really like this plugin because I
can see my coverage information right where I am editing my code, but I
noticed that this plugin wasn't honouring the coverage criteria it was
given, so I fixed that up too.

Finally, I started looking into RT 69240. Initially, this looked like
it should be a reasonably simple problem, but when I eventually
unearthed a CPAN module where I could reproduce the problem it slowly
became clear that I was on the trail of a longstanding problem that I
had known about for many years but had never been able to reliably
reproduce, and that I had never had a sufficient chunk of time to be
able to track down.

Now, thanks to this grant, I do. This is exactly the sort of problem I
had hoped to be able to solve with this grant. I have started off by
trying to catch up on the backlog of bugs that have been reported, but
then problems such as this are the priority before, with luck, moving on
to new features.

But, in the best tradition of soap operas, I'm not going to give you all
the details because most of the results actually fall into week 12. If
you've managed to read this far and you do actually care, the commit
messages will provide the basics of the story. Otherwise, it will be in
my next report.

So there's not too much listed below, but this week and week 12 have
produced some of the best results of the grant so far. I hope this will
be the way in which the grant progresses.

Closed RT tickets:

68517 summary, report total from cover tool includes ignored files
77818 tests fail due to spaces in @INC (Devel::Cover::Inc issue)

Fixed cpantesters reports:

http://www.cpantesters.org/cpan/report/a7ec86de-db7e-11e1-97c0-97aef2681f56

You can see the commits at https://github.com/pjcj/Devel--Cover/commits/master

Hours worked:

02.08 09:40
03.08 12:25

Total 22:05