These two scripts perform the same basic task, but do so inconsistently.
The tools/ script should be removed, and someone should investigate
how it's checking the pod (it finds errors in the current distro
while the test does not.)
--
Will "Coke" Coleda
wi...@coleda.com
I just ran tools/doc/pod_errors.pl and I ended up getting a segfault.
But under tcsh, `find . -not \( -name .svn -prune \) -type f -exec
podchecker '{}' \; | & grep -v 'does not contain any pod commands' |
grep -v 'pod syntax OK'` gives me far too many errors and warnings to
be good. Seems as though podchecker is stricter than our pod checker.
> But under tcsh, `find . -not \( -name .svn -prune \) -type f -exec
> podchecker '{}' \; | & grep -v 'does not contain any pod commands' |
> grep -v 'pod syntax OK'` gives me far too many errors and warnings to
> be good. Seems as though podchecker is stricter than our pod checker.
That's odd, as I fixed a failing pod test a while ago where an extra
C<=cut> was in a C<.pmc> file and podchecker said everything was hunky
dory, but t/doc/pod.t was complaining. Running the file just through
perldoc didn't seem to throw up anything either. So it seems that at
times podchecker isn't as strict.
The output from tools/docs/pod_errors.pl at least gives information
about where the problem is in the file, which is something that
t/doc/pod.t unfortunately doesn't.
Just my 2c.
Paul
> On 04/04/07, Joshua Isom <jri...@gmail.com> wrote:
>> On Apr 3, 2007, at 11:29 PM, Will Coleda (via RT) wrote:
>>
>> > # New Ticket Created by Will Coleda
>> > # Please include the string: [perl #42293]
>> > # in the subject line of all future correspondence about this issue.
>> > # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42293 >
>> >
>> >
>> > These two scripts perform the same basic task, but do so
>> > inconsistently.
>> >
>> > The tools/ script should be removed, and someone should investigate
>> > how it's checking the pod (it finds errors in the current distro
>> > while the test does not.)
>> >
>> > --
>> > Will "Coke" Coleda
>> > wi...@coleda.com
>>
>> I just ran tools/doc/pod_errors.pl and I ended up getting a segfault.
> That's interesting; what OS are you using? I'm using Gentoo linux x86
> and found with, for example, the t/codingstd/c_indent.t test would
> cause (the gentoo package) perl to segfault. However, I've compiled
> my own version of perl (same version as well 5.8.8) and it runs the
> tests fine and the tools/docs/pod_errors.pl test runs. Anyway, the
> reason I'm interested is because I was wondering if the segfault were
> a Gentoo perl proplem.
>
I'm running darwin, ppc. The perl is 5.8.7 and was updated by me. I
don't think I've gotten perl to segfault in quite some time, and if I
trust my crashreporter log, the problem almost always is in S_regmatch,
but I'm not sure which file actually does the checking, too much
inheritance runaround.
>> But under tcsh, `find . -not \( -name .svn -prune \) -type f -exec
>> podchecker '{}' \; | & grep -v 'does not contain any pod commands' |
>> grep -v 'pod syntax OK'` gives me far too many errors and warnings to
>> be good. Seems as though podchecker is stricter than our pod checker.
> That's odd, as I fixed a failing pod test a while ago where an extra
> C<=cut> was in a C<.pmc> file and podchecker said everything was hunky
> dory, but t/doc/pod.t was complaining. Running the file just through
> perldoc didn't seem to throw up anything either. So it seems that at
> times podchecker isn't as strict.
>
> The output from tools/docs/pod_errors.pl at least gives information
> about where the problem is in the file, which is something that
> t/doc/pod.t unfortunately doesn't.
>
> Just my 2c.
>
> Paul
>
So we have three methods to test for pod errors, and three different
standards for the pod. Seems as though this ticket got a little more
complicated.
> I'm running darwin, ppc. The perl is 5.8.7 and was updated by me. I
> don't think I've gotten perl to segfault in quite some time, and if I
> trust my crashreporter log, the problem almost always is in S_regmatch,
> but I'm not sure which file actually does the checking, too much
> inheritance runaround.
If it's a crash in S_regmatch that's usually due to a regular expression
going exponential and exhausting the C stack. In turn, that's usually due to
nested capturing parentheses, non-matching, and lots of backtracking.
Whilst the C stack crash is fixed in 5.9.x, those sorts of regexps can often
take an insane amount of time to realise that they aren't going to match,
so (assuming I'm right here) it means that it's likely that there's a
badly written (to the point of buggy) regexp in the pod checker.
Not that that really helps track it down.
Nicholas Clark
IIRC I found and removed one of those from a Pod module that was integrated
into bleadperl. It may well have been Pod::Simple, and if so, as Allison has
released new versions recently, it should now be gone, if it wasn't already.
Nicholas Clark