On 03/05/2016 03:56 PM, Neil Bowers wrote:
Hi Marc, & CPAN Workers,

I’ve been looking into the final two CPAN Testers fails, and have finally got to the bottom of them.
The failing test is search50.t, and the problem is where it does the following:

- call survey() to get hash of name => path
- foreach name, then call find() and check it returns the same path

There are two CPAN Testers fails:

http://www.cpantesters.org/cpan/report/4ddcddb1-6c58-1014-bec3-a1032b7077ee <http://www.cpantesters.org/cpan/report/4ddcddb1-6c58-1014-bec3-a1032b7077ee>
http://www.cpantesters.org/cpan/report/39970866-dd9c-11e5-a3ee-89603848fe5a <http://www.cpantesters.org/cpan/report/39970866-dd9c-11e5-a3ee-89603848fe5a>
Do you have any thoughts on why these occurred on these particular
OS/Perl version combinations?

Also, could I ask what repository/branch you're working from?
Basically the problem is that

- the pod directory has both perlpodstyle and perlpodstyle.pod in it (how come?!)
- the survey() method doesn’t even find perlpodstyle, it just finds perlpodstyle.pod
- the find() method finds both and it finds perlpodstyle first
- so the test failed

With this understanding I reproduced the failing test.

The problem comes down to two lines of code. In _make_search_callback(), which is invoked by survey(), we have:

unless( m/^[-_a-zA-Z0-9]+\.(?:pod|pm|plx?)\z/is ) {

So it’s only considering files that end in .pod, .pm, .pl, or .plx

But in find() we have:

foreach my $ext ('', '.pod', '.pm', '.pl') { # possible extensions

As you can see, it first checks for no extension. Also note that it’s not checking for the ‘.plx’ extension, which survey handles. I’ve never come across anyone using the .plx extensions, but I guess for a while maybe people did:

http://www.perlmonks.org/?node_id=336713 <http://www.perlmonks.org/?node_id=336713>

I think that the best fix is to make the survey() pattern match files with no extensions, and also files with the .plx extension.
If I read your analysis correctly, survey() -- or, more precisely
_make_search_callback() -- already handles '.plx'. It's find() that
fails to handle '.pl'.

If that's correct, then why not make both functions handle exactly the
same set of file extensions? Whether that should be specified
explicitly or by regex -- I have no preference. But we could then
abstract out the formula for scanning extensions into a function in a
single location.

Note: untested.

Thank you very much.
Jim Keenan

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 6 | next ›
Discussion Overview
groupcpan-workers @
postedMar 5, '16 at 8:57p
activeMar 7, '16 at 6:12p



site design / logo © 2021 Grokbase