Pod::Checker should be switched to use Pod::Simple #12716

p5pRT · 2013-01-21T15:11:02Z

Migrated from rt.perl.org#116467 (status was 'resolved')

Searchable as RT116467$

p5pRT · 2013-01-21T15:11:02Z

From @rjbs

Created by @rjbs

Pod::Checker should be rewritten/reworked to use Pod::Simple exclusively,
rather than Pod::Parser. This way, Pod::Checker can be kept in the core
while Pod::Parser is ejected.

This work was done, in great part, by Marc Green. It needs to be finished,
tested, and merged.

Perl Info


Flags:
    category=library
    severity=medium
    module=Pod::Checker

Site configuration information for perl 5.17.7:

Configured by rjbs at Tue Dec 18 18:00:18 EST 2012.

Summary of my perl5 (revision 5 version 17 subversion 7) configuration:
   
  Platform:
    osname=darwin, osvers=12.2.1, archname=darwin-2level
    uname='darwin walrus.local 12.2.1 darwin kernel version 12.2.1: thu oct 18 16:32:48 pdt 2012; root:xnu-2050.20.9~2release_x86_64 x86_64 '
    config_args='-de -Dprefix=/Users/rjbs/perl5/perlbrew/perls/17.7 -Dusedevel -Aeval:scriptdir=/Users/rjbs/perl5/perlbrew/perls/17.7/bin'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/opt/local/include',
    optimize='-O3',
    cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/opt/local/include'
    ccversion='', gccversion='4.2.1 Compatible Apple Clang 4.0 ((tags/Apple/clang-421.0.57))', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib -L/opt/local/lib'
    libpth=/usr/local/lib /opt/local/lib /usr/lib
    libs=-lgdbm -ldbm -ldl -lm -lutil -lc
    perllibs=-ldl -lm -lutil -lc
    libc=, so=dylib, useshrplib=false, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -L/opt/local/lib -fstack-protector'

Locally applied patches:
    


@INC for perl 5.17.7:
    /Users/rjbs/.perlbrew/libs/17.7@std/lib/perl5/darwin-2level
    /Users/rjbs/.perlbrew/libs/17.7@std/lib/perl5
    /Users/rjbs/perl5/perlbrew/perls/17.7/lib/site_perl/5.17.7/darwin-2level
    /Users/rjbs/perl5/perlbrew/perls/17.7/lib/site_perl/5.17.7
    /Users/rjbs/perl5/perlbrew/perls/17.7/lib/5.17.7/darwin-2level
    /Users/rjbs/perl5/perlbrew/perls/17.7/lib/5.17.7
    .


Environment for perl 5.17.7:
    DYLD_LIBRARY_PATH (unset)
    HOME=/Users/rjbs
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/Users/rjbs/.perlbrew/libs/17.7@std/bin:/Users/rjbs/perl5/perlbrew/bin:/Users/rjbs/perl5/perlbrew/perls/17.7/bin:/Users/rjbs/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/rjbs/code/hla
    PERL5LIB=/Users/rjbs/.perlbrew/libs/17.7@std/lib/perl5
    PERLBREW_BASHRC_VERSION=0.58
    PERLBREW_HOME=/Users/rjbs/.perlbrew
    PERLBREW_LIB=std
    PERLBREW_MANPATH=/Users/rjbs/.perlbrew/libs/17.7@std/man:/Users/rjbs/perl5/perlbrew/perls/17.7/man
    PERLBREW_PATH=/Users/rjbs/.perlbrew/libs/17.7@std/bin:/Users/rjbs/perl5/perlbrew/bin:/Users/rjbs/perl5/perlbrew/perls/17.7/bin
    PERLBREW_PERL=17.7
    PERLBREW_ROOT=/Users/rjbs/perl5/perlbrew
    PERLBREW_VERSION=0.58
    PERLDOC=-n/opt/local/bin/groff
    PERL_AUTOINSTALL=--skipdeps
    PERL_BADLANG (unset)
    PERL_LOCAL_LIB_ROOT=/Users/rjbs/.perlbrew/libs/17.7@std
    PERL_MAILERS=sendmail:/Users/rjbs/bin/sendmail
    PERL_MB_OPT=--install_base /Users/rjbs/.perlbrew/libs/17.7@std
    PERL_MM_OPT=INSTALL_BASE=/Users/rjbs/.perlbrew/libs/17.7@std
    SHELL=/opt/local/bin/zsh

p5pRT · 2013-03-19T02:51:02Z

From @rjbs

A few months ago, I posted a notice about some of this work:

http://markmail.org/thread/wwuo7gkjbaef6y6s

The biggest problem right now is that the Pod::Checker code is "acting weird" with the "garbled
E<>" tests. I'm not sure exactly what's going on, but I have a sneaking suspicion that if it's
addressed, everything else will fall in line.

I have pushed a lousy "shove all Marc's work into the dist" here:

https://github.com/rjbs/Pod-Checker/commits/pod-simple-checker

Once that's done, the next steps are to release it to CPAN and to bring it into a branch in core.
That will immediately fail all tests, but Marc's work (with some work from Karl) pointed at by
previous commentary in this ticket is meant to deal with all those problems.

I expect there will be some bitrot! :-(

We'll need to get porting/podcheck.t passing with the new Pod-Checker before it can be cored.
This is likely to be something to land immediately on 5.19.0, rather than 5.17.10, but I guess
we'll see how quickly somebody can get this fixed.

--
rjbs

p5pRT · 2013-03-19T02:51:03Z

From [Unknown Contact. See original ticket]

A few months ago, I posted a notice about some of this work:

http://markmail.org/thread/wwuo7gkjbaef6y6s

The biggest problem right now is that the Pod::Checker code is "acting weird" with the "garbled
E<>" tests. I'm not sure exactly what's going on, but I have a sneaking suspicion that if it's
addressed, everything else will fall in line.

I have pushed a lousy "shove all Marc's work into the dist" here:

https://github.com/rjbs/Pod-Checker/commits/pod-simple-checker

Once that's done, the next steps are to release it to CPAN and to bring it into a branch in core.
That will immediately fail all tests, but Marc's work (with some work from Karl) pointed at by
previous commentary in this ticket is meant to deal with all those problems.

I expect there will be some bitrot! :-(

We'll need to get porting/podcheck.t passing with the new Pod-Checker before it can be cored.
This is likely to be something to land immediately on 5.19.0, rather than 5.17.10, but I guess
we'll see how quickly somebody can get this fixed.

--
rjbs

p5pRT · 2013-03-19T02:51:03Z

@rjbs - Status changed from 'new' to 'open'

p5pRT · 2014-08-09T00:40:25Z

From @jkeenan

On Mon Mar 18 19:51:02 2013, rjbs wrote:

A few months ago, I posted a notice about some of this work:

http://markmail.org/thread/wwuo7gkjbaef6y6s

The biggest problem right now is that the Pod::Checker code is "acting
weird" with the "garbled
E<>" tests. I'm not sure exactly what's going on, but I have a
sneaking suspicion that if it's
addressed, everything else will fall in line.

I have pushed a lousy "shove all Marc's work into the dist" here:

https://github.com/rjbs/Pod-Checker/commits/pod-simple-checker

Once that's done, the next steps are to release it to CPAN and to
bring it into a branch in core.
That will immediately fail all tests, but Marc's work (with some work
from Karl) pointed at by
previous commentary in this ticket is meant to deal with all those
problems.

I expect there will be some bitrot! :-(

We'll need to get porting/podcheck.t passing with the new Pod-Checker
before it can be cored.
This is likely to be something to land immediately on 5.19.0, rather
than 5.17.10, but I guess
we'll see how quickly somebody can get this fixed.

rjbs:

When I go to http://cpansearch.perl.org/src/MAREKR/Pod-Checker-1.71/lib/Pod/Checker.pm, I read in the documentation:

#####
v1.45 inherits from Pod::Simple as opposed to all previous versions inheriting from Pod::Parser.
#####

If so, what is left to do on this ticket?

Thank you very much.
Jim Keenan

p5pRT · 2014-08-09T00:54:32Z

From @rjbs

* James E Keenan via RT <perlbug-followup@perl.org> [2014-08-08T20:40:25]

When I go to http://cpansearch.perl.org/src/MAREKR/Pod-Checker-1.71/lib/Pod/Checker.pm, I read in the documentation:

#####
v1.45 inherits from Pod::Simple as opposed to all previous versions inheriting from Pod::Parser.
#####

If so, what is left to do on this ticket?

Note that latest isn't in core. And if you import it, everything breaks.

Importing it without everything breaking is what is left to do.

--
rjbs

p5pRT · 2014-08-11T01:53:29Z

From @jkeenan

On Fri Aug 08 17:54:32 2014, rjbs wrote:

* James E Keenan via RT <perlbug-followup@perl.org> [2014-08-
08T20:40:25]

When I go to http://cpansearch.perl.org/src/MAREKR/Pod-Checker-
1.71/lib/Pod/Checker.pm, I read in the documentation:

#####
v1.45 inherits from Pod::Simple as opposed to all previous versions
inheriting from Pod::Parser.
#####

If so, what is left to do on this ticket?

Note that latest isn't in core. And if you import it, everything
breaks.

If by "everything breaks", you mean that t/porting/podcheck.t fails even to compile, then I see your point.

Importing it without everything breaking is what is left to do.

I've been staring at this ticket for several days. The work involved in adapting podcheck.t to using a Pod::Simple-based Pod::Checker rather than a Pod::Parser-based Pod::Checker is non-trivial. This is so for a number of reasons:

* podcheck.t is really three programs in one: a program to test the validity of POD in the core distribution and two programs to modify a database of "known issues". The three programs co-exist in one file by means of different command-line options. Speaking for myself, that's too many things for one file to do in a maintainable way. Moreover, I believe that in Perl, a file whose name ends in ".t" should be a test file and nothing but a test file. It should not also be a file that changes the state of files distributed with core; the ".pl" extension should be used for that. If some of the code in podcheck.t is used by more than one of the three variants, it should be refactored out into a module.

* podcheck.t has dependencies on Pod::Parser in two different areas. A subroutine called extract_pod() explicitly calls Pod::Parser::new() and Pod::Parser::parse_from_filehandle(). But parse_from_filehandle() is also invoked inside internal package My::Pod::Parser, which is the location where podcheck.t's dependency on the "old" Pod::Checker -- the version currently found in core -- is greatest.

* podcheck.t invokes Pod::Checker methods which are not found in the latest version of Pod::Checker on CPAN. So we not only have to remove all dependencies on Pod::Parser; we have to remove all dependencies on methods no longer offered by Pod::Checker.

* podcheck.t simply attempts to do much, much more than apply the "podchecker" utility to a file in the core distribution -- regardless of whether that "podchecker" is based on the "old" Pod::Checker (Pod::Parser-based) or the "new" Pod::Checker (Pod::Simple-based).

Before investing a lot of time in refactoring, however, I would like to know if others agree with the analysis I have presented.

Thank you very much.
Jim Keenan

p5pRT · 2014-08-11T17:41:09Z

From @khwilliamson

On 08/10/2014 07:53 PM, James E Keenan via RT wrote:

On Fri Aug 08 17:54:32 2014, rjbs wrote:

* James E Keenan via RT <perlbug-followup@perl.org> [2014-08-
08T20:40:25]

When I go to http://cpansearch.perl.org/src/MAREKR/Pod-Checker-
1.71/lib/Pod/Checker.pm, I read in the documentation:

#####
v1.45 inherits from Pod::Simple as opposed to all previous versions
inheriting from Pod::Parser.
#####

If so, what is left to do on this ticket?

Note that latest isn't in core. And if you import it, everything
breaks.

If by "everything breaks", you mean that t/porting/podcheck.t fails even to compile, then I see your point.

Importing it without everything breaking is what is left to do.

I've been staring at this ticket for several days. The work involved in adapting podcheck.t to using a Pod::Simple-based Pod::Checker rather than a Pod::Parser-based Pod::Checker is non-trivial. This is so for a number of reasons:

* podcheck.t is really three programs in one: a program to test the validity of POD in the core distribution and two programs to modify a database of "known issues". The three programs co-exist in one file by means of different command-line options. Speaking for myself, that's too many things for one file to do in a maintainable way. Moreover, I believe that in Perl, a file whose name ends in ".t" should be a test file and nothing but a test file. It should not also be a file that changes the state of files distributed with core; the ".pl" extension should be used for that. If some of the code in podcheck.t is used by more than one of the three variants, it should be refactored out into a module.

* podcheck.t has dependencies on Pod::Parser in two different areas. A subroutine called extract_pod() explicitly calls Pod::Parser::new() and Pod::Parser::parse_from_filehandle(). But parse_from_filehandle() is also invoked inside internal package My::Pod::Parser, which is the location where podcheck.t's dependency on the "old" Pod::Checker -- the version currently found in core -- is greatest.

* podcheck.t invokes Pod::Checker methods which are not found in the latest version of Pod::Checker on CPAN. So we not only have to remove all dependencies on Pod::Parser; we have to remove all dependencies on methods no longer offered by Pod::Checker.

* podcheck.t simply attempts to do much, much more than apply the "podchecker" utility to a file in the core distribution -- regardless of whether that "podchecker" is based on the "old" Pod::Checker (Pod::Parser-based) or the "new" Pod::Checker (Pod::Simple-based).

Before investing a lot of time in refactoring, however, I would like to know if others agree with the analysis I have presented.

Thank you very much.
Jim Keenan

---
via perlbug: queue: perl5 status: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=116467

I'm not sure what I think about the separating out or not; so I guess
I'm neutral

I thought there was more to do than rjbs indicated. I had been planning
to work with him on this, when he got the tuits and inclination.

There is a version of podcheck.t that inherits from Pod::Simple. It's
been waiting for other things to gel for 2.5 years now. What I know is
missing is code to extract just the pod from a file. Work to do this
was started
https://github.com/genehack/pod-simple/tree/add-pod-simple-pod

p5pRT · 2014-08-11T18:39:34Z

From @jkeenan

On Mon Aug 11 10:41:09 2014, public@khwilliamson.com wrote:

On 08/10/2014 07:53 PM, James E Keenan via RT wrote:

On Fri Aug 08 17:54:32 2014, rjbs wrote:

* James E Keenan via RT <perlbug-followup@perl.org> [2014-08-
08T20:40:25]

When I go to http://cpansearch.perl.org/src/MAREKR/Pod-Checker-
1.71/lib/Pod/Checker.pm, I read in the documentation:

#####
v1.45 inherits from Pod::Simple as opposed to all previous versions
inheriting from Pod::Parser.
#####

If so, what is left to do on this ticket?

Note that latest isn't in core. And if you import it, everything
breaks.

If by "everything breaks", you mean that t/porting/podcheck.t fails
even to compile, then I see your point.

Importing it without everything breaking is what is left to do.

I've been staring at this ticket for several days. The work involved
in adapting podcheck.t to using a Pod::Simple-based Pod::Checker
rather than a Pod::Parser-based Pod::Checker is non-trivial. This is
so for a number of reasons:

* podcheck.t is really three programs in one: a program to test the
validity of POD in the core distribution and two programs to modify a
database of "known issues". The three programs co-exist in one file
by means of different command-line options. Speaking for myself,
that's too many things for one file to do in a maintainable way.
Moreover, I believe that in Perl, a file whose name ends in ".t"
should be a test file and nothing but a test file. It should not
also be a file that changes the state of files distributed with core;
the ".pl" extension should be used for that. If some of the code in
podcheck.t is used by more than one of the three variants, it should
be refactored out into a module.

* podcheck.t has dependencies on Pod::Parser in two different areas.
A subroutine called extract_pod() explicitly calls Pod::Parser::new()
and Pod::Parser::parse_from_filehandle(). But
parse_from_filehandle() is also invoked inside internal package
My::Pod::Parser, which is the location where podcheck.t's dependency
on the "old" Pod::Checker -- the version currently found in core --
is greatest.

* podcheck.t invokes Pod::Checker methods which are not found in the
latest version of Pod::Checker on CPAN. So we not only have to
remove all dependencies on Pod::Parser; we have to remove all
dependencies on methods no longer offered by Pod::Checker.

* podcheck.t simply attempts to do much, much more than apply the
"podchecker" utility to a file in the core distribution -- regardless
of whether that "podchecker" is based on the "old" Pod::Checker
(Pod::Parser-based) or the "new" Pod::Checker (Pod::Simple-based).

Before investing a lot of time in refactoring, however, I would like
to know if others agree with the analysis I have presented.

Thank you very much.
Jim Keenan

---
via perlbug: queue: perl5 status: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=116467

I'm not sure what I think about the separating out or not; so I guess
I'm neutral

I thought there was more to do than rjbs indicated. I had been
planning
to work with him on this, when he got the tuits and inclination.

There is a version of podcheck.t that inherits from Pod::Simple. It's
been waiting for other things to gel for 2.5 years now.

Do you know where that version of podcheck.t is available?

What I know
is
missing is code to extract just the pod from a file. Work to do this
was started
https://github.com/genehack/pod-simple/tree/add-pod-simple-pod

I'm glad you mentioned that. If we were able to replace the current, Pod::Parser-based extract_pod() subroutine with one based on Pod::Simple, we'd be halfway there. But when I looked at Pod::Simple yesterday, I didn't see any obvious way to simply extract the POD from a file and get it back as a single string.

Thank you very much.
Jim Keenan

p5pRT · 2014-08-12T00:46:37Z

From @jkeenan

On Sun Aug 10 18:53:29 2014, jkeenan wrote:

On Fri Aug 08 17:54:32 2014, rjbs wrote:

* James E Keenan via RT <perlbug-followup@perl.org> [2014-08-
08T20:40:25]

When I go to http://cpansearch.perl.org/src/MAREKR/Pod-Checker-
1.71/lib/Pod/Checker.pm, I read in the documentation:

#####
v1.45 inherits from Pod::Simple as opposed to all previous versions
inheriting from Pod::Parser.
#####

If so, what is left to do on this ticket?

Note that latest isn't in core. And if you import it, everything
breaks.

If by "everything breaks", you mean that t/porting/podcheck.t fails
even to compile, then I see your point.

Today, for reasons that are not clear, t/porting/podcheck.t in blead *does* compile for me.

#####
$ ./perl -v |head -2|tail -1
This is perl 5, version 21, subversion 3 (v5.21.3 (v5.21.2-123-g2ebcba0)) built for x86_64-linux

$ ./perl -Ilib -c t/porting/podcheck.t
t/porting/podcheck.t syntax OK
#####

p5pRT · 2014-08-12T01:25:56Z

From @khwilliamson

On Mon Aug 11 17:46:37 2014, jkeenan wrote:

On Sun Aug 10 18:53:29 2014, jkeenan wrote:

On Fri Aug 08 17:54:32 2014, rjbs wrote:

* James E Keenan via RT <perlbug-followup@perl.org> [2014-08-
08T20:40:25]

When I go to http://cpansearch.perl.org/src/MAREKR/Pod-Checker-
1.71/lib/Pod/Checker.pm, I read in the documentation:

#####
v1.45 inherits from Pod::Simple as opposed to all previous
versions
inheriting from Pod::Parser.
#####

If so, what is left to do on this ticket?

Note that latest isn't in core. And if you import it, everything
breaks.

If by "everything breaks", you mean that t/porting/podcheck.t fails
even to compile, then I see your point.

Today, for reasons that are not clear, t/porting/podcheck.t in blead
*does* compile for me.

#####
$ ./perl -v |head -2|tail -1
This is perl 5, version 21, subversion 3 (v5.21.3 (v5.21.2-123-
g2ebcba0)) built for x86_64-linux

$ ./perl -Ilib -c t/porting/podcheck.t
t/porting/podcheck.t syntax OK
#####

It should compile unless you remove Pod::Checker, so I don't understand.
--
Karl Williamson

p5pRT · 2014-08-12T11:34:26Z

From @jkeenan

On Mon Aug 11 18:25:56 2014, khw wrote:

On Mon Aug 11 17:46:37 2014, jkeenan wrote:

On Sun Aug 10 18:53:29 2014, jkeenan wrote:

On Fri Aug 08 17:54:32 2014, rjbs wrote:

* James E Keenan via RT <perlbug-followup@perl.org> [2014-08-
08T20:40:25]

When I go to http://cpansearch.perl.org/src/MAREKR/Pod-Checker-
1.71/lib/Pod/Checker.pm, I read in the documentation:

#####
v1.45 inherits from Pod::Simple as opposed to all previous
versions
inheriting from Pod::Parser.
#####

If so, what is left to do on this ticket?

Note that latest isn't in core. And if you import it, everything
breaks.

If by "everything breaks", you mean that t/porting/podcheck.t fails
even to compile, then I see your point.

Today, for reasons that are not clear, t/porting/podcheck.t in blead
*does* compile for me.

#####
$ ./perl -v |head -2|tail -1
This is perl 5, version 21, subversion 3 (v5.21.3 (v5.21.2-123-
g2ebcba0)) built for x86_64-linux

$ ./perl -Ilib -c t/porting/podcheck.t
t/porting/podcheck.t syntax OK
#####

It should compile unless you remove Pod::Checker, so I don't understand.

Error on my part: I was switching between branches without re-compiling. Please ignore.

p5pRT · 2014-08-15T04:12:02Z

From @khwilliamson

On 08/11/2014 12:39 PM, James E Keenan via RT wrote:

I thought there was more to do than rjbs indicated. I had been
planning
to work with him on this, when he got the tuits and inclination.

There is a version of podcheck.t that inherits from Pod::Simple. It's
been waiting for other things to gel for 2.5 years now.

There's been a significant amount of bit rot, and I don't have many
tuits now, so it'll be a while to get it up to date.

p5pRT · 2016-05-27T18:09:06Z

From @khwilliamson

This has been fixed by 1f44a80
--
Karl Williamson

p5pRT · 2016-05-27T18:09:08Z

@khwilliamson - Status changed from 'open' to 'pending release'

p5pRT · 2016-05-27T22:29:54Z

From @rjbs

On Fri May 27 11:09:06 2016, khw wrote:

This has been fixed by 1f44a80

Thanks, Karl! I know that this was a bunch of unglamorous work that won't get oohs and aahs from most future users, and also that I found it tedious enough that I trailed off partway through. I appreciate you picking up the ball and getting it across the finish line!

--
rjbs

p5pRT · 2016-05-27T23:44:51Z

From @jkeenan

On Fri May 27 15:29:54 2016, rjbs wrote:

On Fri May 27 11:09:06 2016, khw wrote:

This has been fixed by 1f44a80

Thanks, Karl! I know that this was a bunch of unglamorous work that
won't get oohs and aahs from most future users, and also that I found
it tedious enough that I trailed off partway through. I appreciate
you picking up the ball and getting it across the finish line!

I second rjbs's gratitude; this was a major refactoring effort!

--
James E Keenan (jkeenan@cpan.org)

p5pRT · 2016-05-29T18:33:24Z

From @xsawyerx

On 05/28/2016 01:44 AM, James E Keenan via RT wrote:

On Fri May 27 15:29:54 2016, rjbs wrote:

On Fri May 27 11:09:06 2016, khw wrote:

This has been fixed by 1f44a80
Thanks, Karl! I know that this was a bunch of unglamorous work that
won't get oohs and aahs from most future users, and also that I found
it tedious enough that I trailed off partway through. I appreciate
you picking up the ball and getting it across the finish line!
I second rjbs's gratitude; this was a major refactoring effort!

Having seen some of the work from the side-lines until of late, I third
that second! :)

p5pRT · 2017-05-30T20:12:40Z

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release today of Perl 5.26.0, this and 210 other issues have been
resolved.

Perl 5.26.0 may be downloaded via:
https://metacpan.org/release/XSAWYERX/perl-5.26.0

If you find that the problem persists, feel free to reopen this ticket.

p5pRT · 2017-05-30T20:12:41Z

@khwilliamson - Status changed from 'pending release' to 'resolved'

p5pRT closed this as completed May 30, 2017

p5pRT added Severity Medium distro-darwin type-library labels Oct 19, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Pod::Checker should be switched to use Pod::Simple #12716

Pod::Checker should be switched to use Pod::Simple #12716

p5pRT commented Jan 21, 2013

p5pRT commented Jan 21, 2013

p5pRT commented Mar 19, 2013

p5pRT commented Mar 19, 2013

p5pRT commented Mar 19, 2013

p5pRT commented Aug 9, 2014

p5pRT commented Aug 9, 2014

p5pRT commented Aug 11, 2014

p5pRT commented Aug 11, 2014

p5pRT commented Aug 11, 2014

p5pRT commented Aug 12, 2014

p5pRT commented Aug 12, 2014

p5pRT commented Aug 12, 2014

p5pRT commented Aug 15, 2014

p5pRT commented May 27, 2016

p5pRT commented May 27, 2016

p5pRT commented May 27, 2016

p5pRT commented May 27, 2016

p5pRT commented May 29, 2016

p5pRT commented May 30, 2017

p5pRT commented May 30, 2017

Pod::Checker should be switched to use Pod::Simple #12716

Pod::Checker should be switched to use Pod::Simple #12716

Comments

p5pRT commented Jan 21, 2013

p5pRT commented Jan 21, 2013

From @rjbs

Created by @rjbs

p5pRT commented Mar 19, 2013

From @rjbs

p5pRT commented Mar 19, 2013

From [Unknown Contact. See original ticket]

p5pRT commented Mar 19, 2013

p5pRT commented Aug 9, 2014

From @jkeenan

p5pRT commented Aug 9, 2014

From @rjbs

p5pRT commented Aug 11, 2014

From @jkeenan

p5pRT commented Aug 11, 2014

From @khwilliamson

p5pRT commented Aug 11, 2014

From @jkeenan

p5pRT commented Aug 12, 2014

From @jkeenan

p5pRT commented Aug 12, 2014

From @khwilliamson

p5pRT commented Aug 12, 2014

From @jkeenan

p5pRT commented Aug 15, 2014

From @khwilliamson

p5pRT commented May 27, 2016

From @khwilliamson

p5pRT commented May 27, 2016

p5pRT commented May 27, 2016

From @rjbs

p5pRT commented May 27, 2016

From @jkeenan

p5pRT commented May 29, 2016

From @xsawyerx

p5pRT commented May 30, 2017

From @khwilliamson

p5pRT commented May 30, 2017