Subscribe: perl.pod-people
http://www.nntp.perl.org/rss/perl.pod-people.rdf
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
github  https github  karl williamson  man  perl  pod man  pod simple  pod text  pod usage  pod  simple  text  wrote 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: perl.pod-people

perl.pod-people



...



Published: Sun, 11 Dec 2016 06:17:08 +0000

Copyright: Copyright 1998-2016 perl.org
 



Re: podlators 4.09 released by Steve Hay via pod-people

Tue, 08 Nov 2016 14:41:18 +0000

On 5 November 2016 at 22:04, Russ Allbery wrote:
> Wow, I somehow completely mangled the From line of that. Just in case
> this didn't get through:
>
> I'm pleased to announce release 4.09 of podlators.
>

Thanks, applied in commit a7ea90b1451006596c4574b1e65894f0bda1bafc.



Re: podlators 4.09 released by Russ Allbery

Sat, 05 Nov 2016 22:04:37 +0000

Wow, I somehow completely mangled the From line of that. Just in case
this didn't get through:

I'm pleased to announce release 4.09 of podlators.

podlators contains Pod::Man and Pod::Text modules which convert POD
input to *roff source output, suitable for man pages, or plain text. It
also includes several subclasses of Pod::Text for formatted output to
terminals with various capabilities. It is the source package for the
Pod::Man and Pod::Text modules included with Perl.

Changes from previous release:

[Pod::Text] Use Pod::Simple's logic to determine the native code
points for NO BREAK SPACE and SOFT HYPHEN instead of hard-coding the
ASCII values. Hopefully fixes the case of mysterious disappearing
open brackets on EBCDIC systems. (#118240)

You can download it from:



or from CPAN. This package is maintained using Git; see the instructions
on the above page to access the Git repository.

Note to Perl core maintainers who are incorporating this update: feel free
to remove the docs/metadata directory when importing, as this is source to
generate the README file and web pages. (Or you can leave it; it's not
too large.)

--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~|| 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print



podlators 4.09 released by Russ

Sat, 05 Nov 2016 21:43:08 +0000

I'm pleased to announce release 4.09 of podlators.

podlators contains Pod::Man and Pod::Text modules which convert POD
input to *roff source output, suitable for man pages, or plain text. It
also includes several subclasses of Pod::Text for formatted output to
terminals with various capabilities. It is the source package for the
Pod::Man and Pod::Text modules included with Perl.

Changes from previous release:

[Pod::Text] Use Pod::Simple's logic to determine the native code
points for NO BREAK SPACE and SOFT HYPHEN instead of hard-coding the
ASCII values. Hopefully fixes the case of mysterious disappearing
open brackets on EBCDIC systems. (#118240)

You can download it from:



or from CPAN. This package is maintained using Git; see the instructions
on the above page to access the Git repository.

Note to Perl core maintainers who are incorporating this update: feel free
to remove the docs/metadata directory when importing, as this is source to
generate the README file and web pages. (Or you can leave it; it's not
too large.)

--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~|| 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print



podlators 4.08 released by Russ Allbery

Sun, 25 Sep 2016 02:42:16 +0000

The URL

https://archives.eyrie.org/software/perl/podlators-4.08.tar.gz

has entered CPAN as

file: $CPAN/authors/id/R/RR/RRA/podlators-4.08.tar.gz
size: 125283 bytes
md5: e74b689d34855a07685508650fcfeb6d
sha1: c120f62524c437313405478fdfb00608a068172d

Changes since the previous release:

[Pod::Man] Partially revert change in 4.00 to require the name option
(--name to pod2man) when generating man pages from standard input.
Historically, pod2man silently tolerated this, and there turned out to
be a lot of software that depended on this, making the change too
disruptive. Instead, silently set the man page title to STDIN in this
case, but warn about it in the documentation. (#117990)

[Pod::Man] Fix rendering bug for "TRUE (1)", which was recognized as
needing small caps and then erroneously as a man page reference,
resulting in escaped nroff. (Found by Dan Jacobson with the
XML::LibXML::Element man page.) (Debian Bug#836831)

[Pod::Man] Fix rendering bug causing "\s0(1)" to be mistakenly marked
as a man page reference, later confusing backslash escaping.

[Pod::Man] Add new lquote and rquote options (and corresponding
--lquote and --rquote flags to pod2man) to set the left and right
quotes for C<> text independently. (#103298)

Remove test for nested L<> markup, since an upcoming version of
Pod::Simple will drop support for this. (#114075)

--
Russ Allbery (eagle@eyrie.org)



Re: Pod::Simple output as POD by David E. Wheeler

Sun, 15 May 2016 03:20:51 +0000

On May 13, 2016, at 7:00 PM, Ron Savage wrote:

> So make it -J JustPod, or is that parameter list sacrosanct?
>
> Perhaps leave -M, and add -J, which defaults to a value of JustPod.

You pass the name of the formatting module to -M. I see no reason to change it.

D=



Re: Pod::Simple output as POD by Ron Savage

Sat, 14 May 2016 02:01:11 +0000

Hi David

On 12/05/16 10:39, David E. Wheeler wrote:
> On May 11, 2016, at 5:29 PM, Karl Williamson wrote:

> Like John, I don’t much care. I agree that Pod::Simple::Pod lacks necessary information. ExtractPod seems fine to me. Uh, though there is this:
>
> perldoc [-h] [-D] [-t] [-u] [-m] [-l] [-F]
> [-i] [-V] [-T] [-r]
> [-d destination_file]
> [-o formatname]
> [-M FormatterClassName]
> [-w formatteroption:value]
> [-n nroff-replacement]
> [-X]
> [-L language_code]
> PageName|ModuleName|ProgramName|URL
>
> So the formatter arg to -M would be:
>
> perldoc -M ExtractPod
>
> Which also seems a little weird. Maybe Pod::Simple::PodFormat?

So make it -J JustPod, or is that parameter list sacrosanct?

Perhaps leave -M, and add -J, which defaults to a value of JustPod.

--
Ron Savage - savage.net.au



Re: Pod::Simple output as POD by David E. Wheeler

Fri, 13 May 2016 18:25:18 +0000

On May 13, 2016, at 11:03 AM, Karl Williamson wrote:

> If we wanted to be cute, we could call it Pod::Simple::SimplyPod, with you know, only one, natural, ingredient, and no harmful additives.

But is it organic? Or Biodynamic?

D



Re: Pod::Simple output as POD by Karl Williamson

Fri, 13 May 2016 18:03:49 +0000

On 05/11/2016 07:38 PM, John SJ Anderson wrote:
>
>> On May 11, 2016, at 17:52, Ron Savage wrote:
>> On 12/05/16 10:39, David E. Wheeler wrote:
>>
>>> Which also seems a little weird. Maybe Pod::Simple::PodFormat?
>>
>> Pod::Simple::ExtractPod is good, but possible is Pod::Simple::JustPod.
>
> With only a _tiny_ bit of my tongue in my cheek, I’ll throw out Pod::Simple::PlainOldPOD ...
>
> 8^)
>
> j.
>

I'm leaning towards Pod::Simple::JustPod. I think that captures the
essence, and seems to me to fit the paradigm of the output format.

If we wanted to be cute, we could call it Pod::Simple::SimplyPod, with
you know, only one, natural, ingredient, and no harmful additives.



Re: Pod::Simple output as POD by John SJ Anderson

Thu, 12 May 2016 14:47:29 +0000


> On May 11, 2016, at 17:52, Ron Savage wrote:
> On 12/05/16 10:39, David E. Wheeler wrote:
>
>> Which also seems a little weird. Maybe Pod::Simple::PodFormat?
>
> Pod::Simple::ExtractPod is good, but possible is Pod::Simple::JustPod.

With only a _tiny_ bit of my tongue in my cheek, I’ll throw out Pod::Simple::PlainOldPOD ...

8^)

j.



Re: Pod::Simple output as POD by Ron Savage

Thu, 12 May 2016 00:52:46 +0000

Hi

On 12/05/16 10:39, David E. Wheeler wrote:
> On May 11, 2016, at 5:29 PM, Karl Williamson wrote:

> Which also seems a little weird. Maybe Pod::Simple::PodFormat?

Pod::Simple::ExtractPod is good, but possible is Pod::Simple::JustPod.

--
Ron Savage - savage.net.au



Re: Pod::Simple output as POD by David E. Wheeler

Thu, 12 May 2016 00:40:13 +0000

On May 11, 2016, at 5:29 PM, Karl Williamson wrote:

>> My only comment on ‘ExtractPod’ as a name would be that all the other modules in the Pod::Simple dist that do similar things are simply named ‘Pod::Simple::$FORMAT’, (e.g., Pod::Simple::HTML, Pod::Simple::RTF, etc.)

Probably should have been Pod::Simple::Format::*. :-(

>> At the end of the day, you’ve done the work to get it out the door and as far as I’m concerned, you can call it whatever you like. 8^)
>
> It's more a matter of what is the least worst name to help people at a glance know what it does. I imagine that if it were named simply 'Pod' that people would think. "I've already got Pod input, why would I want Pod output", and either investigate, or blow it off. So that's why I came up with ExtractPod, but I'd like to hear other opinions.

Like John, I don’t much care. I agree that Pod::Simple::Pod lacks necessary information. ExtractPod seems fine to me. Uh, though there is this:

perldoc [-h] [-D] [-t] [-u] [-m] [-l] [-F]
[-i] [-V] [-T] [-r]
[-d destination_file]
[-o formatname]
[-M FormatterClassName]
[-w formatteroption:value]
[-n nroff-replacement]
[-X]
[-L language_code]
PageName|ModuleName|ProgramName|URL

So the formatter arg to -M would be:

perldoc -M ExtractPod

Which also seems a little weird. Maybe Pod::Simple::PodFormat?

Anyway, I’ve no strong opinions.

Best,

David



Re: Pod::Simple output as POD by Karl Williamson

Thu, 12 May 2016 00:30:01 +0000

On 05/10/2016 12:26 PM, John SJ Anderson wrote:
>
>> On May 8, 2016, at 21:04, Karl Williamson wrote:
>>
>> I have taken on the task of completing this, and am nearly done. I'm writing because I wonder what other use-cases there are for this module besides extracting pod from a file that also contains other things. I can't think of any. And if there are no significant ones, I wonder if the name should instead be Pod::Simple::ExtractPod, instead of Pod::Simple::Pod?
>
> From what I recall, that was also my use case (IIRC, I was trying to automate producing a GitHub Pages-hosted version of the POD during a Dzil release process).
>
> My only comment on ‘ExtractPod’ as a name would be that all the other modules in the Pod::Simple dist that do similar things are simply named ‘Pod::Simple::$FORMAT’, (e.g., Pod::Simple::HTML, Pod::Simple::RTF, etc.)
>
> At the end of the day, you’ve done the work to get it out the door and as far as I’m concerned, you can call it whatever you like. 8^)

It's more a matter of what is the least worst name to help people at a
glance know what it does. I imagine that if it were named simply 'Pod'
that people would think. "I've already got Pod input, why would I want
Pod output", and either investigate, or blow it off. So that's why I
came up with ExtractPod, but I'd like to hear other opinions.
>
> (Karl, sorry for the mostly duplicated response to your earlier message to me.)
>
> thanks,
> john.
>
>




Re: Pod::Simple output as POD by John SJ Anderson

Tue, 10 May 2016 18:27:09 +0000


> On May 8, 2016, at 21:04, Karl Williamson wrote:
>
> I have taken on the task of completing this, and am nearly done. I'm writing because I wonder what other use-cases there are for this module besides extracting pod from a file that also contains other things. I can't think of any. And if there are no significant ones, I wonder if the name should instead be Pod::Simple::ExtractPod, instead of Pod::Simple::Pod?

From what I recall, that was also my use case (IIRC, I was trying to automate producing a GitHub Pages-hosted version of the POD during a Dzil release process).

My only comment on ‘ExtractPod’ as a name would be that all the other modules in the Pod::Simple dist that do similar things are simply named ‘Pod::Simple::$FORMAT’, (e.g., Pod::Simple::HTML, Pod::Simple::RTF, etc.)

At the end of the day, you’ve done the work to get it out the door and as far as I’m concerned, you can call it whatever you like. 8^)

(Karl, sorry for the mostly duplicated response to your earlier message to me.)

thanks,
john.




Re: Pod::Simple output as POD by Karl Williamson

Mon, 09 May 2016 04:04:56 +0000

On 08/12/2014 02:25 PM, John SJ Anderson wrote:
> Jim -
>
> The current state of that code is that I think it mostly works, but it
> needs tests (or it needs the tests to be finished). It's been a while
> since I touched it, I'm not sure when I'm going to be able to get back
> to it, but I would be perfectly happy if somebody wanted to grab it
> and wrap it up.
>
> chrs,
> john.

I have taken on the task of completing this, and am nearly done. I'm
writing because I wonder what other use-cases there are for this module
besides extracting pod from a file that also contains other things. I
can't think of any. And if there are no significant ones, I wonder if
the name should instead be Pod::Simple::ExtractPod, instead of
Pod::Simple::Pod?

>
>
> On Tue, Aug 12, 2014 at 9:06 AM, James E Keenan wrote:
>> I am writing concerning https://rt.perl.org/Ticket/Display.html?id=116467.
>> The objective of this ticket is to revise t/porting/podcheck.t so that it no
>> longer depends on CPAN module Pod::Parser. The latter has been designated
>> "legacy code" but we cannot remove it from the core distribution until
>> podcheck.t no longer depends on it, either directly (calls to
>> parse_from_filehandle) or indirectly (via an older version of Pod::Checker
>> which depends on Pod::Parser rather than Pod::Simple).
>>
>> While studying podcheck.t recently I noticed that we could get substantially
>> closer to our goal if we took the following subroutine from podcheck.t:
>>
>> #####
>> sub extract_pod { # Extracts just the pod from a file; returns undef if
>> file
>> # doesn't exist
>> my $filename = shift;
>>
>> my @pod;
>>
>> # Arrange for the output of Pod::Parser to be collected in an array we
>> can
>> # look at instead of being printed
>> tie *ALREADY_FH, 'Tie_Array_to_FH', \@pod;
>> if (open my $in_fh, '<:bytes', $filename) {
>> my $parser = Pod::Parser->new();
>> $parser->parse_from_filehandle($in_fh, *ALREADY_FH);
>> close $in_fh;
>>
>> return join "", @pod
>> }
>> ...
>> #####
>>
>> ... and could rewrite the 'if' block using a Pod::Simple-based call.
>> However, AFAICT there is nothing in the latest CPAN release of Pod::Simple
>> by which one could simple extract the POD from a file and return it as a
>> single string, POD-formatting intact and otherwise unmodified.
>>
>> Karl Williamson noted
>> (https://rt.perl.org/Ticket/Display.html?id=116467#txn-1304150) that there
>> have been some efforts in this direction, citing:
>> https://github.com/genehack/pod-simple/tree/add-pod-simple-pod. Could you
>> advise as to the current state of development of this fork and whether it is
>> likely to be of benefit to P5P in this instance?
>>
>> Thank you very much.
>> Jim Keenan
>>
>




Re: Working on CPAN Testers fails for Pod::Simple::Search by Neil Bowers

Sat, 30 Apr 2016 13:26:44 +0000

>> Anyone object to making Neil a committer and co-maint on Pod-Simple? (I’m
>> hoping Neil doesn’t object.) The canonical repository is here:
>
> No objection, and I preemptively overrule Neil's potential objection.

Ha!

Ok.




Re: Pod::Simple issues by Russ Allbery

Sat, 30 Apr 2016 06:15:08 +0000

Karl Williamson writes:

> I'm not sure I understand what "fail on generation" means. I think it
> might mean just not generate a pod, rather than generate one with an error
> section.

Correct -- it will exit with an error message.

lothlorien:~$ cat > foo.pod
=item foo

Invalid POD.
lothlorien:~$ pod2man foo.pod > foo.1
foo.pod around line 1: '=item' outside of any '=over'
foo.pod around line 1: =over without closing =back
POD document had syntax errors at /usr/bin/pod2man line 68.
lothlorien:~$ echo $?
255

> What I was intending was to add a scream() call. The only failure that I
> saw in Pod::Simple that stopped parsing was when it was clear the
> encoding of the pod was not understandable, so there was no point in
> continuing. So I don't understand what you do, unless it is to die on
> pod errors, or some such.

Correct, the scripts die on POD errors, unless the --errors flag is used
to request some other behavior.

-errors=style
Set the error handling style. "die" says to throw an exception on
any POD formatting error. "stderr" says to report errors on
standard error, but not to throw an exception. "pod" says to
include a POD ERRORS section in the resulting documentation
summarizing the errors. "none" ignores POD errors entirely, as
much as possible.

The default is "die".

(Now let me go fix the missing - in the pod2man docs....)

--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~|| 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print



Re: Pod::Simple issues by Karl Williamson

Sat, 30 Apr 2016 04:48:25 +0000

On 04/29/2016 04:33 PM, Russ Allbery wrote:
> Karl Williamson writes:
>
>> Rather than aborting parsing at the point where this occurs, I think it
>> should continue on, but generate an errors section, like it does for most
>> other errors.
>
> This will cause a hard failure in pod2man and pod2text by default, since
> they do not generate ERRORS sections by default (you have to request that
> behavior with a flag). They used to generate ERRORS sections, which made
> people very unhappy because they didn't want their documents published
> with sections saying the documents were bad, and after a lot of previous
> discussion I changed the default to fail on generation. (I'd really
> rather not reverse that decision at this point.)
>

I'm not sure I understand what "fail on generation" means. I think it
might mean just not generate a pod, rather than generate one with an
error section. What I was intending was to add a scream() call. The
only failure that I saw in Pod::Simple that stopped parsing was when it
was clear the encoding of the pod was not understandable, so there was
no point in continuing. So I don't understand what you do, unless it is
to die on pod errors, or some such.

I tend to agree about not reversing your earlier decision.



Re: Pod::Simple issues by Russ Allbery

Fri, 29 Apr 2016 22:33:19 +0000

Karl Williamson writes:

> Rather than aborting parsing at the point where this occurs, I think it
> should continue on, but generate an errors section, like it does for most
> other errors.

This will cause a hard failure in pod2man and pod2text by default, since
they do not generate ERRORS sections by default (you have to request that
behavior with a flag). They used to generate ERRORS sections, which made
people very unhappy because they didn't want their documents published
with sections saying the documents were bad, and after a lot of previous
discussion I changed the default to fail on generation. (I'd really
rather not reverse that decision at this point.)

--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~|| 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print



Re: Working on CPAN Testers fails for Pod::Simple::Search by Marc Green

Fri, 29 Apr 2016 21:32:35 +0000

On Fri, Apr 29, 2016 at 1:54 PM, Ricardo Signes
wrote:

> * "David E. Wheeler" [2016-04-29T16:43:03]
> > Anyone object to making Neil a committer and co-maint on Pod-Simple? (I’m
> > hoping Neil doesn’t object.) The canonical repository is here:
>
> No objection, and I preemptively overrule Neil's potential objection.
>


I very much welcome it!



Re: Working on CPAN Testers fails for Pod::Simple::Search by Ricardo Signes

Fri, 29 Apr 2016 20:54:30 +0000

* "David E. Wheeler" [2016-04-29T16:43:03]
> Anyone object to making Neil a committer and co-maint on Pod-Simple? (I’m
> hoping Neil doesn’t object.) The canonical repository is here:

No objection, and I preemptively overrule Neil's potential objection.

--
rjbs



Re: Working on CPAN Testers fails for Pod::Simple::Search by David E. Wheeler

Fri, 29 Apr 2016 20:43:33 +0000

On Apr 29, 2016, at 11:41 AM, Karl Williamson wrote:

> Looking at the man page, it looks like Pod::Simple::Search does a similar function as Pod::Find does

Yes, and it has been there since forever.

Best,

David




Re: Working on CPAN Testers fails for Pod::Simple::Search by David E. Wheeler

Fri, 29 Apr 2016 20:43:21 +0000

On Apr 23, 2016, at 9:45 AM, Neil Bowers wrote:

> I talked this through with RJBS, who suggested the order should instead be:
>
> .pod .pm .pl .plx
>
> David, you added the comment to the code that’s mentioned above. Was there a reason you added that comment, or were you just commenting on what the code was doing? (like much of this module, it’s somewhat opaque :-)

I suspect I was just trying to get both functions to prefer things in the same order. I agree with Rik’s suggested ordering, however, especially if it makes the bloody tests pass.

Anyone object to making Neil a committer and co-maint on Pod-Simple? (I’m hoping Neil doesn’t object.) The canonical repository is here:

https://github.com/perl-pod/pod-simple/

Best,

David





Re: Pod::Simple issues by Karl Williamson

Fri, 29 Apr 2016 20:33:08 +0000

On 04/29/2016 01:58 PM, Shawn H Corey wrote:
> On Fri, 29 Apr 2016 13:34:21 -0600
> Karl Williamson wrote:
>
>> Nested L<> are illegal. Pretending inner one is X<> so can
>> continue looking for other errors.
>
> That would be Z<>
>
>

That would generate an additional warning that it wasn't empty. The
mechanism is to divert the incoming text into the X<> so it doesn't do
anything bad. I suppose we could set a flag for the Z<> to suppress the
warning.



Re: Pod::Simple issues by Shawn H Corey

Fri, 29 Apr 2016 19:58:39 +0000

On Fri, 29 Apr 2016 13:34:21 -0600
Karl Williamson wrote:

> Nested L<> are illegal. Pretending inner one is X<> so can
> continue looking for other errors.

That would be Z<>


--
Don't stop where the ink does.
Shawn



Pod::Simple issues by Karl Williamson

Fri, 29 Apr 2016 19:34:29 +0000

I stumbled across a bug in Pod::Simple the other day: It does not create
the promised {'raw'} structure element usable by parsers for L<>
constructs if they occur within another formatting code, such as the
fairly common C>.

I figured out a way to fix this, but in doing so I realized that
Pod::Simple does not catch nested L<... L<...>...>, contrary to the
specification:

Authors must not nest L<...> codes. For example, "L
man page>" should be treated as an error.

Pod::Simple does not treat this as an error. I think it should. Is
there any disagreement?

Rather than aborting parsing at the point where this occurs, I think it
should continue on, but generate an errors section, like it does for
most other errors. Properly handling nested L<> is tricky. Currently,
it sort of works, but the generated output for html doesn't link
properly, as one can't nest links in html. I came up with this
tentative message, which perhaps explains too much of how I was able to
easily keep parsing with this error, and still fix the original {'raw'}
bug; improved wording welcome:

Nested L<> are illegal. Pretending inner one is X<> so can continue
looking for other errors.




Re: AW: Working on CPAN Testers fails for Pod::Simple::Search by Karl Williamson

Fri, 29 Apr 2016 18:42:10 +0000

On 04/24/2016 11:34 PM, Marek Rouchal wrote:
> Does this mean that there is a "find"-like function in Pod::Simple that
> replaces Pod::Find? That would be an opportunity to discontinue
> Pod::Find along with Pod::Parser...
>
> -Marek
>
>
>

Looking at the man page, it looks like Pod::Simple::Search does a
similar function as Pod::Find does




GitHub markup and POD by Zakariyya Mughal

Tue, 26 Apr 2016 21:41:26 +0000

Hello all,

I wanted to bring to your attention several issues on GitHub having to
deal with POD. Some of them have been there for years, but nobody from
GitHub has responded.

Given how it took lots of publicity (e.g., )
to get GitHub to prioritise certain changes such as voting on issues,
perhaps we can be squeaky wheels and get these merged?

- #241 Switch to Pod::Simple::XHTML

- #421 POD CPAN Links (point from s.c.o. to metacpan.org)

- #874 Fix POD markup in test

Regards,
- Zaki Mughal

P.S. Somewhat related is
which proposes to change `$Pod::Simple::HTML::Perldoc_URL_Prefix` to switch to MetaCPAN.
I don't want to get into that here, but if someone would like to start
another thread for that, go ahead.



GitHub markup and POD by Zakariyya Mughal

Tue, 26 Apr 2016 21:03:59 +0000

Hello all,

I wanted to bring to your attention several issues on GitHub having to
deal with POD. Some of them have been there for years, but nobody from
GitHub has responded.

Given how it took lots of publicity (e.g., )
to get GitHub to prioritise certain changes such as voting on issues,
perhaps we can be squeaky wheels and get these merged?

- #241 Switch to Pod::Simple::XHTML

- #421 POD CPAN Links (point from s.c.o. to metacpan.org)

- #874 Fix POD markup in test

Regards,
- Zaki Mughal

P.S. Somewhat related is
which proposes to change `$Pod::Simple::HTML::Perldoc_URL_Prefix` to switch to MetaCPAN.
I don't want to get into that here, but if someone would like to start
another thread for that, go ahead.



GitHub markup and POD by Zakariyya Mughal

Tue, 26 Apr 2016 20:45:10 +0000

Hello all,

I wanted to bring to your attention several issues on GitHub having to
deal with POD. Some of them have been there for years, but nobody from
GitHub has responded.

Given how it took lots of publicity (e.g., )
to get GitHub to prioritise certain changes such as voting on issues,
perhaps we can be squeaky wheels and get these merged?

- #241 Switch to Pod::Simple::XHTML

- #421 POD CPAN Links (point from s.c.o. to metacpan.org)

- #874 Fix POD markup in test

Regards,
- Zaki Mughal

P.S. Somewhat related is
which proposes to change `$Pod::Simple::HTML::Perldoc_URL_Prefix` to switch to MetaCPAN.
I don't want to get into that here, but if someone would like to start
another thread for that, go ahead.



Re: AW: pod2usage and Pod::Find, Pod::PlainText by Karl Williamson

Tue, 26 Apr 2016 00:02:04 +0000

On 04/23/2016 03:26 PM, Marek Rouchal wrote:
> Thanks for the hint... two thoughts, feedback welcome:
> 1. Pod::PlainText used to be part of the core... but since now Pod::Usage depends on Pod::Simple, I think the tests should be restructured to use that, or as a last resort, Pod::Text
Is there any real difference between PlainText and Pod::Simple::Text ?

> 2. Pod::Find might deserve a separate distribution, but again the test of Pod::Usage should not depend on it.
> Hope to find some time to get that done in the next days...
>
> -Marek
>
> -----Ursprüngliche Nachricht-----
> It has been a goal to remove Pod::Parser from the core perl distribution.
>
> It turns out there is a dependency in 2 test files for pod2uage upon Pod::Find and Pod::PlainText, which are parts of Pod::Parser.
>
> The test files are Pod-Usage/t/pod/pod2usage.t
> and Pod-Usage/t/pod/pod2usage2.t
>
> Note that Pod::Usage itself doesn't depend on Pod::Parser, just two test files do. I don't understand this part of perl at all. So I'm wondering what to do about this. Could the tests just be deleted? Is there a current alternative to the functionality of these modules?
>
>
>
>




AW: Working on CPAN Testers fails for Pod::Simple::Search by Marek Rouchal

Mon, 25 Apr 2016 05:34:40 +0000



Does this mean that there is a "find"-like function in Pod::Simple that replaces Pod::Find? That would be an opportunity to discontinue Pod::Find along with Pod::Parser...
-Marek


Von meinem Samsung Gerät gesendet.



Re: Working on CPAN Testers fails for Pod::Simple::Search by Neil Bowers

Sun, 24 Apr 2016 15:52:55 +0000

> I talked this through with RJBS, who suggested the order should instead be:
>
> .pod .pm .pl .plx
>
> David, you added the comment to the code that’s mentioned above. Was there a reason you added that comment, or were you just commenting on what the code was doing? (like much of this module, it’s somewhat opaque :-)

Following more discussion at the QAH, I just did another developer release of Pod-Simple, which has the above order.

https://metacpan.org/release/NEILB/Pod-Simple-3.33_06

This fixes one specific fail seen from CPAN Testers. I’ll wait to see if any others turn up.

Neil



AW: pod2usage and Pod::Find, Pod::PlainText by Marek Rouchal

Sat, 23 Apr 2016 21:26:30 +0000

Thanks for the hint... two thoughts, feedback welcome:
1. Pod::PlainText used to be part of the core... but since now Pod::Usage depends on Pod::Simple, I think the tests should be restructured to use that, or as a last resort, Pod::Text
2. Pod::Find might deserve a separate distribution, but again the test of Pod::Usage should not depend on it.
Hope to find some time to get that done in the next days...

-Marek

-----Ursprüngliche Nachricht-----
It has been a goal to remove Pod::Parser from the core perl distribution.

It turns out there is a dependency in 2 test files for pod2uage upon Pod::Find and Pod::PlainText, which are parts of Pod::Parser.

The test files are Pod-Usage/t/pod/pod2usage.t
and Pod-Usage/t/pod/pod2usage2.t

Note that Pod::Usage itself doesn't depend on Pod::Parser, just two test files do. I don't understand this part of perl at all. So I'm wondering what to do about this. Could the tests just be deleted? Is there a current alternative to the functionality of these modules?






pod2usage and Pod::Find, Pod::PlainText by Karl Williamson

Sat, 23 Apr 2016 20:50:20 +0000

It has been a goal to remove Pod::Parser from the core perl distribution.

It turns out there is a dependency in 2 test files for pod2uage upon
Pod::Find and Pod::PlainText, which are parts of Pod::Parser.

The test files are Pod-Usage/t/pod/pod2usage.t
and Pod-Usage/t/pod/pod2usage2.t

Note that Pod::Usage itself doesn't depend on Pod::Parser, just two test
files do. I don't understand this part of perl at all. So I'm
wondering what to do about this. Could the tests just be deleted? Is
there a current alternative to the functionality of these modules?

Thanks



Working on CPAN Testers fails for Pod::Simple::Search by Neil Bowers

Sat, 23 Apr 2016 16:46:29 +0000

I’m at the QAH, and have continued digging into some CPAN Testers fails for Pod::Simple::Search. I previously emailed about this to cpan-workers, but it’s become pod specific, so RJBS suggested this mailing list.

To fix some of them I made find() and survey() be consistent with respect to what file extensions they consider.

Based on the following comment in the code …
https://metacpan.org/source/MARCGREEN/Pod-Simple-3.32/lib/Pod/Simple/Search.pm#L336
… I made the following be the order that file are considered:
.pod .pm .pl .plx
(which isn’t the usual order — .pod files are usually picked above all else)

This almost fixed things, but resulted in a few failures caused where the system Pod/ directory had both of the following:

perlpodstyle
perlpodstyle.pod

(separate issue: how does this even happen? I’m at the QAH and will challenge a few people with that)

What happens in this case is that survey() says that the right path for perlpodstyle is perlpodstyle.pod, but find() says it’s the version without the pod extension. This is down to this line of code:

https://metacpan.org/source/MARCGREEN/Pod-Simple-3.32/lib/Pod/Simple/Search.pm#L262

If I change that regexp to be:

m{^perl.*(\.pod)?$}s

Then it fixes the failing tests … I was ready to ship my next developer release …

BUT

I talked this through with RJBS, who suggested the order should instead be:

.pod .pm .pl .plx

David, you added the comment to the code that’s mentioned above. Was there a reason you added that comment, or were you just commenting on what the code was doing? (like much of this module, it’s somewhat opaque :-)

Neil





Re: podlators 4.07 released by Dave Mitchell

Mon, 21 Mar 2016 15:00:41 +0000

On Mon, Mar 21, 2016 at 08:41:33AM -0400, Ricardo Signes wrote:
> * Dave Mitchell [2016-03-21T04:56:11]
> > I vote for this being merged into blead despite the code-freeze. I can
> > vouch for the 1st and 3rd fixes, I know nothing about the second.
>
> +1

Now in as 503c90f6fd25c0a96d3bab0361a7d3e15b87b647



--
Nothing ventured, nothing lost.



Re: podlators 4.07 released by Shlomi Fish

Mon, 21 Mar 2016 14:19:08 +0000

On Mon, 21 Mar 2016 08:56:11 +0000
Dave Mitchell wrote:

> On Sun, Mar 20, 2016 at 07:24:47PM -0700, Russ Allbery wrote:
> > I'm pleased to announce release 4.07 of podlators.
> >
> > podlators contains Pod::Man and Pod::Text modules which convert POD
> > input to *roff source output, suitable for man pages, or plain text. It
> > also includes several subclasses of Pod::Text for formatted output to
> > terminals with various capabilities. It is the source package for the
> > Pod::Man and Pod::Text modules included with Perl.
> >
> > Changes from previous release:
> >
> > [Pod::Man] Avoid undefined variable warnings when determining the
> > title for a Perl module at the top level of a distribution. Thanks,
> > Dave Mitchell. (#112625)
> >
> > [Pod::Man] Fix font resets with nroff when fixed-width fonts are used
> > in the label for an =item. Previously, italic was being ended with
> > \f(CW even in nroff mode, which, with groff, only changes the font to
> > fixed-width and doesn't reset to a non-italic font. Thanks, Paul
> > Townsend. (#98199)
> >
> > [Pod::Man] Suppress warnings about a missing Encode module if
> > PERL_CORE is set in the environment. Due to build ordering during
> > Perl core builds, Encode is expected to not yet be available during
> > the build step that sets PERL_CORE. Thanks, Dave Mitchell.
>
> I vote for this being merged into blead despite the code-freeze. I can
> vouch for the 1st and 3rd fixes, I know nothing about the second.
>

Sounds good. I approve of it as well. +1.

Regards,

Shlomi Fish

--
-----------------------------------------------------------------
Writing a BitKeeper replacement is probably easier at this point than getting
its license changed.
— Matt Mackall (who ended up writing a BitKeeper replacement)



Re: podlators 4.07 released by H.Merijn Brand

Mon, 21 Mar 2016 14:19:05 +0000

On Mon, 21 Mar 2016 08:56:11 +0000, Dave Mitchell
wrote:

> On Sun, Mar 20, 2016 at 07:24:47PM -0700, Russ Allbery wrote:
> > I'm pleased to announce release 4.07 of podlators.
> >
> > podlators contains Pod::Man and Pod::Text modules which convert POD
> > input to *roff source output, suitable for man pages, or plain text. It
> > also includes several subclasses of Pod::Text for formatted output to
> > terminals with various capabilities. It is the source package for the
> > Pod::Man and Pod::Text modules included with Perl.
> >
> > Changes from previous release:
> >
> > [Pod::Man] Avoid undefined variable warnings when determining the
> > title for a Perl module at the top level of a distribution. Thanks,
> > Dave Mitchell. (#112625)
> >
> > [Pod::Man] Fix font resets with nroff when fixed-width fonts are used
> > in the label for an =item. Previously, italic was being ended with
> > \f(CW even in nroff mode, which, with groff, only changes the font to
> > fixed-width and doesn't reset to a non-italic font. Thanks, Paul
> > Townsend. (#98199)
> >
> > [Pod::Man] Suppress warnings about a missing Encode module if
> > PERL_CORE is set in the environment. Due to build ordering during
> > Perl core builds, Encode is expected to not yet be available during
> > the build step that sets PERL_CORE. Thanks, Dave Mitchell.
>
> I vote for this being merged into blead despite the code-freeze. I can
> vouch for the 1st and 3rd fixes, I know nothing about the second.

+10!

--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.23 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/



Re: podlators 4.07 released by Ricardo Signes

Mon, 21 Mar 2016 12:41:42 +0000

* Dave Mitchell [2016-03-21T04:56:11]
> I vote for this being merged into blead despite the code-freeze. I can
> vouch for the 1st and 3rd fixes, I know nothing about the second.

+1

--
rjbs



Re: podlators 4.07 released by Dave Mitchell

Mon, 21 Mar 2016 08:56:43 +0000

On Sun, Mar 20, 2016 at 07:24:47PM -0700, Russ Allbery wrote:
> I'm pleased to announce release 4.07 of podlators.
>
> podlators contains Pod::Man and Pod::Text modules which convert POD
> input to *roff source output, suitable for man pages, or plain text. It
> also includes several subclasses of Pod::Text for formatted output to
> terminals with various capabilities. It is the source package for the
> Pod::Man and Pod::Text modules included with Perl.
>
> Changes from previous release:
>
> [Pod::Man] Avoid undefined variable warnings when determining the
> title for a Perl module at the top level of a distribution. Thanks,
> Dave Mitchell. (#112625)
>
> [Pod::Man] Fix font resets with nroff when fixed-width fonts are used
> in the label for an =item. Previously, italic was being ended with
> \f(CW even in nroff mode, which, with groff, only changes the font to
> fixed-width and doesn't reset to a non-italic font. Thanks, Paul
> Townsend. (#98199)
>
> [Pod::Man] Suppress warnings about a missing Encode module if
> PERL_CORE is set in the environment. Due to build ordering during
> Perl core builds, Encode is expected to not yet be available during
> the build step that sets PERL_CORE. Thanks, Dave Mitchell.

I vote for this being merged into blead despite the code-freeze. I can
vouch for the 1st and 3rd fixes, I know nothing about the second.

--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.