[32712] in Perl-Users-Digest
Perl-Users Digest, Issue: 3976 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jun 28 16:09:19 2013
Date: Fri, 28 Jun 2013 13:09:04 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 28 Jun 2013 Volume: 11 Number: 3976
Today's topics:
$ pod2man --quotes= <oneingray@gmail.com>
[OT] non-issues with non-solutions <oneingray@gmail.com>
Re: [OT] non-issues with non-solutions <rweikusat@mssgmbh.com>
[OT] PostScript <oneingray@gmail.com>
configuring CPAN to apply patches (such as #29468, IPv6 <oneingray@gmail.com>
Re: interactive selection of text lines <josef.moellers@invalid.invalid>
Re: interactive selection of text lines gamo@telecable.es
Re: issues with POD <oneingray@gmail.com>
Re: issues with POD (Tim McDaniel)
Re: issues with POD <ben@morrow.me.uk>
Re: issues with POD <m@rtij.nl.invlalid>
Re: issues with POD <oneingray@gmail.com>
Re: issues with POD <rweikusat@mssgmbh.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 27 Jun 2013 15:20:08 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: $ pod2man --quotes=
Message-Id: <87ppv77f87.fsf_-_@violet.siamics.net>
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
[...]
>>> The characters passed to --quotes aren't the characters as they
>>> will appear in the output, they are roff escapes. (I don't really
>>> understand roff, but the characters you pass are inserted directly
>>> into a .ds line.)
>> Which means that it may require a more thorough code change to fix
>> the issue. (Thanks for the pointer, BTW.)
> ... no, it means that changing it would break backcompat, so it's
> probably not going to happen.
How would it? Currently, the use of --quotes= with arguments
other than the two-octet ones and "none" results in an error.
Having pod2man interpret multi-octet sequences as two-character
ones looks like a "pure" extension.
Besides, that appears to contradict your own claim below that
"pod2man [is not being run] with --quotes for a very long time."
> (Not to mention that the whole question of dealing with non-ASCII
> command-line arguments is largely unsolved on non-Win32 systems.)
On POSIX systems, I'd expect non-ASCII command-line arguments to
be passed as octet sequences, in the encoding specified by the
LC_CTYPE category.
It has worked for me so far, BTW.
>>> Remember, all this stuff comes from perl 5.000, before perl (or
>>> groff, I expect) had any sort of Unicode support.
>> How could this justify having the bug remain unfixed?
> Because noone in a position to change it thinks it's a bug, or thinks
> it's worth fixing? We're talking about pod2man here; I doubt
> anyone's run it with --quotes for a very long time.
Which appears to make the compatibility concerns irrelevant.
--
FSF associate member #7257
------------------------------
Date: Fri, 28 Jun 2013 13:45:05 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: [OT] non-issues with non-solutions
Message-Id: <8738s273j2.fsf_-_@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> As a rule of thumb, people resort to sophisms when marketing their
> opinions when they can't think of any better way to further their
> causes. This may be because they themselves know that they are wrong
> or - considering that 'web development' is what the guy who runs the
> advertising agency dabbles in - because they're really marketing
> specialists to whom all this 'programming stuff' is part of the cost
> of displaying advertisements they'd rather (and totally rationally in
> this case) want to get rid of.
> The problem with this is that computers do more (and much more
> sophisticated) things than "being your plastic pal who's fun to be
> with" and what minimizes the per-case workload of the guy who decides
> on the colour said 'plastic pal' should have today (and hence, helps
> him to maximize his income for a given time period) might not be the
> most sensible way to construct 24x7 autonomously operating software
> system people rely on in order to get some (not inherently
> computer-related) job done.
Even though I cannot quite parse these two paragraphs (is it
some kind of Perl code, BTW?), I seem to wholeheartedly agree
with this way of thought itself.
--
FSF associate member #7257
------------------------------
Date: Fri, 28 Jun 2013 15:13:53 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: [OT] non-issues with non-solutions
Message-Id: <87ip0y8gri.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
>>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
> [...]
>
> > As a rule of thumb, people resort to sophisms when marketing their
> > opinions when they can't think of any better way to further their
> > causes. This may be because they themselves know that they are wrong
> > or - considering that 'web development' is what the guy who runs the
> > advertising agency dabbles in - because they're really marketing
> > specialists to whom all this 'programming stuff' is part of the cost
> > of displaying advertisements they'd rather (and totally rationally in
> > this case) want to get rid of.
>
> > The problem with this is that computers do more (and much more
> > sophisticated) things than "being your plastic pal who's fun to be
> > with" and what minimizes the per-case workload of the guy who decides
> > on the colour said 'plastic pal' should have today (and hence, helps
> > him to maximize his income for a given time period) might not be the
> > most sensible way to construct 24x7 autonomously operating software
> > system people rely on in order to get some (not inherently
> > computer-related) job done.
>
> Even though I cannot quite parse these two paragraphs (is it
> some kind of Perl code, BTW?), I seem to wholeheartedly agree
> with this way of thought itself.
Hmm ... I admit that I'm at least partially guilty of the same thing
(I was criticizing) :-). The important meta-bit would be "Think for
yourself".
------------------------------
Date: Fri, 28 Jun 2013 11:58:38 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: [OT] PostScript
Message-Id: <87bo6q78gh.fsf_-_@violet.siamics.net>
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
[...]
>>>> Well, looking at the license the software I use to produce
>>>> PostScript may attach to the pieces of the code which end up in
>>>> the resulting "document" isn't exactly the thing I'd like to spend
>>>> my time on.
>>> Me either. What makes you think the Turing-completeness of the
>>> language used makes any difference to that, though?
>> It doesn't. Yet I fail to understand the purpose the software may
>> embed some "hidden" non-code /creative/ work of its developer into
>> the resulting document.
> Fonts? And they usually have quite restrictive licences, from a
> 'reusing in other documents' point of view.
Indeed. Though in practice, I fail to recall using any fonts
that fail to meet DFSG for my documents recently.
[...]
>>> certainly not if you're just using the document as a document, and
>>> not trying to pick it apart and use the bits to write your own
>>> PostScript driver.
>> If /I/ release the document in question under, say, CC BY-SA, how
>> the recipient (licensee) is expected to know that some parts of the
>> document's own digital representation are in fact under some other
>> license, issued by a third party?
> By applying common sense. Your copyright and therefore your licence
> applies to what you created, that is, to the content of the document.
And how the recipient is intended to know that?
The same applies to the other kinds of works, though. But for
the images and such, I'd expect the copyrights to be properly
stated in the /visible/ part of the document. For the fonts, it
may seem a bit excessive. Still, for the embedded code parts,
-- I wouldn't expect it to happen at all.
[...]
--
FSF associate member #7257
------------------------------
Date: Fri, 28 Jun 2013 19:48:29 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: configuring CPAN to apply patches (such as #29468, IPv6 in Net::HTTP)
Message-Id: <87ip0y584y.fsf@violet.siamics.net>
>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
[The particular example given is relevant to a longstanding bug
in Net::HTTP, thus cross-posting to news:comp.lang.perl.modules.
Omitting the latter from Followup-To:, though.]
[...]
>> <pet peeve> The correct place to file a bug in a Perl module is in
>> its CPAN bug tracker, or, in this case, in the zbar Sourceforce
>> tracker.
> BTW, there's a longstanding bug filed at the CPAN RT [2] (along with
> a patch.) However, it appears to be filed against libwww-perl, while
> it actually belongs to Net-HTTP.
> The question is: how do I reassign it?
> [2] https://rt.cpan.org/Public/Bug/Display.html?id=29468
As there seems to be no progress on this one, I've had to
finally learn the necessary magic for CPAN to patch that
(trivial) bug for me on each installation attempt.
The first part of the incantation is altering $CPAN::Config, to
which I've added "patches_dir":
--cut: ~/.cpan/CPAN/MyConfig.pm --
my $cpan_home
= ($ENV{"CPAN"}
// ($ENV{"HOME"} . "/.cpan"));
...
$CPAN::Config = {
...
'patches_dir' => $cpan_home . q (/patches),
...
'prefs_dir' => $cpan_home . q (/prefs),
--cut: ~/.cpan/CPAN/MyConfig.pm --
The "prefs_dir" value was already there, and it's the directory
I've added the following YAML data:
### 6yy1cmawx4oqu5kdx7qks77n3n.yml -*- YAML -*-
## Patch the IPv6 support into Net::HTTP
---
match:
module: "Net::HTTP"
patches:
- "cpmz4z7w7toa3mk6bi4rmp66n8.patch"
### 6yy1cmawx4oqu5kdx7qks77n3n.yml ends here
The patch itself goes to the "patches_dir" as specified above
(it's the same as the one given at [2], yet with an earlier
$VERSION within the context section of the diff):
--- lib/Net/HTTP.pm.~1~ 2011-11-21 20:23:21.000000000 +0000
+++ lib/Net/HTTP.pm 2012-01-08 18:13:21.000000000 +0000
@@ -5,8 +5,13 @@
$VERSION = "6.02";
unless ($SOCKET_CLASS) {
- eval { require IO::Socket::INET } || require IO::Socket;
- $SOCKET_CLASS = "IO::Socket::INET";
+ if (eval { require IO::Socket::INET6 }) {
+ $SOCKET_CLASS = "IO::Socket::INET6";
+ } else {
+ eval { require IO::Socket::INET }
+ || require IO::Socket;
+ $SOCKET_CLASS = "IO::Socket::INET";
+ }
}
require Net::HTTP::Methods;
require Carp;
Voil`a! The $ cpan Net::HTTP command that followed resulted in
the fixed version of the module being installed. (Even though
there was an expected "fuzz" warning from patch(1).)
[...]
--
FSF associate member #7257
------------------------------
Date: Thu, 27 Jun 2013 21:00:12 +0200
From: Josef Moellers <josef.moellers@invalid.invalid>
Subject: Re: interactive selection of text lines
Message-Id: <b33gdsFf850U1@mid.individual.net>
On 06/24/2013 09:54 AM, Ulli Horlacher wrote:
> I want to (de-)select interactivly text lines with cursor keys and space
> bar.
> Something like Tk::Checkbutton, but for a terminal and not GUI.
>
> The text must be scrollable, because I have more text lines than they
> would fit on the terminal.
> Example: select files from a directory listing.
>
> Is there a module for this kind of task?
>
>
I haven't used them but search cpan for "curses".
------------------------------
Date: Thu, 27 Jun 2013 20:11:14 +0000 (UTC)
From: gamo@telecable.es
Subject: Re: interactive selection of text lines
Message-Id: <kqi692$q4u$1@speranza.aioe.org>
If you are lucky and uses Linux, the dialog (1) could do menus
type radiolist for you. You only have to read stderr, because
stdout is used to sohow the menus.
URL: http://www.telecable.es/personales/gamo/Codigo_dialog_pl.html
Best regards,
------------------------------
Date: Thu, 27 Jun 2013 15:25:19 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: issues with POD
Message-Id: <87obar7ezk.fsf@violet.siamics.net>
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
[...]
>> The HTML syntax /allows/ Unicode quotes. Inside the payload, that
>> is. (Which the text of the NAME section certainly is.)
> No, it isn't. That's exactly my point. The content of the NAME
> section is syntax, and it needs to look like
> <title> - <abstract>
> with an ASCII hyphen. You may not like this, but that's the way it
> is.
I don't like, and it won't happen on my Pods.
It's free software, though. Anyone's free take the Pods and
improve (or "improve") them as one sees fit.
[...]
>> But I do. So, assuming that my intent is to provide quality
>> documentation (both the contents and the form) for the users of the
>> software I develop, should I satisfy the NAME convention, at the
>> cost of having to host the /proper/ HTML renditions of the
>> documentation by myself? Or should I instead disregard the
>> convention -- used by the developer's tools I won't use myself
>> anyway, -- to ensure that certain well-known Web resource will have
>> the documentation rendered properly?
> The former. The assumption about NAME formatting is widespread, and
> you don't know what types of systems people might be using your
> module on or what sort of Pod-formatting tools they might have.
> Portability is more important than typographical niceties.
Well, let's see if there'd be any actual bug reports...
[...]
>>> Heh. I can just picture the conversation... Not to mention that
>>> command-line perldoc would no longer function, making your modules
>>> unusable.
>> "Command-line perldoc"? What's it?
> Are you serious? Run 'perldoc Pod::Man' from your shell prompt.
$ perldoc Pod::Man
You need to install the perl-doc package to use this program.
$
So?
But if you mean that perldoc is just a fancy way to extract the
Pods out of the sources, convert them into executable roff code,
interpret them with roff, and produce a kind of "extended" ASCII
document, -- then I'd like to note that the intermediate roff
code is already present on my system, and M-x woman in Emacs
shows it without actually executing it with a roff interpreter.
> More generally, providing HTML documentation means you *only* provide
> HTML documentation.
It doesn't. Arguably, a profile of even the good old
HTML 4.0 Strict that matches the expressiveness of Pod would be
easier to convert into a variety of formats than Pod itself.
However, I understand that it's a common misconception.
Hopefully, I'd be able to prepare some counter-examples for the
SFD this September.
> Pod can be converted to a great many formats (that's the point).
So can be DocBook.
[...]
>>>> Please note that -Tps produces not a document, but a program to
>>>> be executed (by a PostScript interpreter, in this case), which
>>>> has implications to both security
>>> That is a relevant concern under some circumstances; this is not
>>> one of them.
>> It's a valid concern whenever the code comes from a generally
>> untrusted source. Such as from a Web site its author put it to.
>> (Which is how the documentation for free software packages is often
>> distributed.)
> Perl documentation distributed in any format other than Pod is
> worthless, since perldoc can't find it.
? How does this relate to my suggestion to avoid PostScript?
>>> (I have, somewhat reluctantly, moved to using PDF instead of
>>> PostScript almost exclusively. I like PostScript: it's
>>> comfortingly insane. (The same could be said about Perl.))
>> Still, I don't quite understand why one might want to use an ad-hoc
>> graphics language, when there're general-purpose ones, with a number
>> of graphics libraries to choose from? (And that includes Perl,
>> BTW.)
> Because my printer speaks PostScript? (Actually it doesn't, but
> historically that was the reason for using it.)
Nowadays, the majority of printers speak neither PostScript nor
PDF. It's the host the printer's attached to that does. And
I'd argue that the host speaks PDF more often than PostScript.
>>>> and software freedom.
>>> Don't be so ridiculous.
>> Well, looking at the license the software I use to produce
>> PostScript may attach to the pieces of the code which end up in the
>> resulting "document" isn't exactly the thing I'd like to spend my
>> time on.
> Me either. What makes you think the Turing-completeness of the
> language used makes any difference to that, though?
It doesn't. Yet I fail to understand the purpose the software
may embed some "hidden" non-code /creative/ work of its
developer into the resulting document.
> I very much doubt any such licences are enforceable, in any case;
Perhaps; IANAL.
> certainly not if you're just using the document as a document, and
> not trying to pick it apart and use the bits to write your own
> PostScript driver.
If /I/ release the document in question under, say, CC BY-SA,
how the recipient (licensee) is expected to know that some parts
of the document's own digital representation are in fact under
some other license, issued by a third party?
[...]
>> To me, it looks much more like a very good reason to update the
>> particular groff install.
> That would be the FreeBSD base system. The groff there is not going
> to be updated, it's going to be replaced, because newer groffs are
> GPLv3.
I was unaware that the FreeBSD developers are opposing GPLv3.
And why do they, BTW? (It was always my impression that FreeBSD
is more lax regarding the licenses than, say, Debian.)
Anyway, isn't it possible to install an (additional) groff
instance from the ports?
>> (Unless the agreement would be to just drop POD altogether, and move
>> on to the better tools. Which I still hope for, even understanding
>> all the improbability of such a decision.)
> We're not going to do that. We *like* Pod.
Slightly tangential to the discussion is the question whether
the "total manpower" of /we/ is currently rising or diminishing?
> Personally, when I'm writing technical documentation, I would write
> in Pod for choice. I appreciate its lack of clutter.
... And also predictability, structure, the ease to run
structured searches against, etc.?
[...]
--
FSF associate member #7257
------------------------------
Date: Thu, 27 Jun 2013 18:43:08 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: issues with POD
Message-Id: <kqi13s$gc6$1@reader2.panix.com>
In article <0fkt9a-kmb2.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>Formats designed by and for pedants.
"You say that like it's a bad thing."
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 27 Jun 2013 22:21:29 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: issues with POD
Message-Id: <pvmu9a-t9f2.ln1@anubis.morrow.me.uk>
Quoth Ivan Shmakov <oneingray@gmail.com>:
> >>>>> Ben Morrow <ben@morrow.me.uk> writes:
> >>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>
> >> "Command-line perldoc"? What's it?
>
> > Are you serious? Run 'perldoc Pod::Man' from your shell prompt.
>
> $ perldoc Pod::Man
> You need to install the perl-doc package to use this program.
Your perl install is broken; it has been mangled by over-zealous
packagers looking to save a few bytes. You need to find which magic
package to install to give you the whole thing.
> But if you mean that perldoc is just a fancy way to extract the
> Pods out of the sources, convert them into executable roff code,
> interpret them with roff, and produce a kind of "extended" ASCII
> document, -- then I'd like to note that the intermediate roff
> code is already present on my system, and M-x woman in Emacs
> shows it without actually executing it with a roff interpreter.
OK, if that works for you. A lot of Perl programmers use perldoc, and
rely on it working properly, so providing documentation perldoc can't
find is not helpful.
[PostScript]
> >>
> >> It's a valid concern whenever the code comes from a generally
> >> untrusted source. Such as from a Web site its author put it to.
> >> (Which is how the documentation for free software packages is often
> >> distributed.)
>
> > Perl documentation distributed in any format other than Pod is
> > worthless, since perldoc can't find it.
>
> ? How does this relate to my suggestion to avoid PostScript?
Since Perl documentation is distributed in Pod format, the only reason
you would have it in PS is because you have generated it yourself,
presumably with tools you trust not to put anything malicious in the
output.
> >> Well, looking at the license the software I use to produce
> >> PostScript may attach to the pieces of the code which end up in the
> >> resulting "document" isn't exactly the thing I'd like to spend my
> >> time on.
>
> > Me either. What makes you think the Turing-completeness of the
> > language used makes any difference to that, though?
>
> It doesn't. Yet I fail to understand the purpose the software
> may embed some "hidden" non-code /creative/ work of its
> developer into the resulting document.
Fonts? And they usually have quite restrictive licences, from a 'reusing
in other documents' point of view.
> > I very much doubt any such licences are enforceable, in any case;
>
> Perhaps; IANAL.
>
> > certainly not if you're just using the document as a document, and
> > not trying to pick it apart and use the bits to write your own
> > PostScript driver.
>
> If /I/ release the document in question under, say, CC BY-SA,
> how the recipient (licensee) is expected to know that some parts
> of the document's own digital representation are in fact under
> some other license, issued by a third party?
By applying common sense. Your copyright and therefore your licence
applies to what you created, that is, to the content of the document.
> >> To me, it looks much more like a very good reason to update the
> >> particular groff install.
>
> > That would be the FreeBSD base system. The groff there is not going
> > to be updated, it's going to be replaced, because newer groffs are
> > GPLv3.
>
> I was unaware that the FreeBSD developers are opposing GPLv3.
> And why do they, BTW? (It was always my impression that FreeBSD
> is more lax regarding the licenses than, say, Debian.)
I don't know the details; all I know is the GPLv3 has been deemed too
restrictive for the base system. Unlike Debian, the ports collection
still contains software with all licences, open-source and commercial;
though of course the prebuilt packages are only available where the
licence allows it.
> Anyway, isn't it possible to install an (additional) groff
> instance from the ports?
Why would I want to do that? The only thing I use groff for is to read
manpages. Why would I want them as PDFs? (Or as PostScript, for that
matter; I was only using it as an example of a format I expected to get
the endashes right.)
> >> (Unless the agreement would be to just drop POD altogether, and move
> >> on to the better tools. Which I still hope for, even understanding
> >> all the improbability of such a decision.)
>
> > We're not going to do that. We *like* Pod.
>
> Slightly tangential to the discussion is the question whether
> the "total manpower" of /we/ is currently rising or diminishing?
If Perl is dying (which it isn't, by the way), it's not because we don't
use DocBook.
> > Personally, when I'm writing technical documentation, I would write
> > in Pod for choice. I appreciate its lack of clutter.
>
> ... And also predictability, structure, the ease to run
> structured searches against, etc.?
No, mostly I appreciate its lack of clutter. Pod makes writing
documentation no harder than writing comments, which means I actually do
write documentation, even for code I don't think anyone else will ever
see. This is a Good Thing.
(Besides, what do I need structured searches for? I've got ack.)
Ben
------------------------------
Date: Fri, 28 Jun 2013 12:38:58 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: issues with POD
Message-Id: <2n50aa-orq.ln1@news.rtij.nl>
On Thu, 27 Jun 2013 22:21:29 +0100, Ben Morrow wrote:
> Quoth Ivan Shmakov <oneingray@gmail.com>:
>> >>>>> Ben Morrow <ben@morrow.me.uk> writes: Quoth Ivan Shmakov
>> >>>>> <oneingray@gmail.com>:
>>
>> >> "Command-line perldoc"? What's it?
>>
>> > Are you serious? Run 'perldoc Pod::Man' from your shell prompt.
>>
>> $ perldoc Pod::Man You need to install the perl-doc package to use this
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> program.
>
> Your perl install is broken; it has been mangled by over-zealous
> packagers looking to save a few bytes. You need to find which magic
> package to install to give you the whole thing.
Maybe that magic package would be perl-doc? :-)
M4
------------------------------
Date: Fri, 28 Jun 2013 12:04:45 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: issues with POD
Message-Id: <877ghe786a.fsf@violet.siamics.net>
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>>>> "Command-line perldoc"? What's it?
>>> Are you serious? Run 'perldoc Pod::Man' from your shell prompt.
>> $ perldoc Pod::Man
>> You need to install the perl-doc package to use this program.
> Your perl install is broken;
"It's not a bug."
> it has been mangled by over-zealous packagers looking to save a few
> bytes. You need to find which magic package to install to give you
> the whole thing.
Fortunately, with the error message quoted above, the packagers
already made that a trivial thing to do.
JFTR: the purpose of such splits is to avoid the installation of
the documentation on the hosts that merely /run/ existing code,
and aren't used for the actual development. The installs I use
for Perl development are /ought/ to contain "perl-doc," but
I forgot to do it for this particular one, and I'm not quite
inclined to touch it in the foreseeable future. In the
meantime, I use http://search.cpan.org/perldoc? and
http://perldoc.perl.org/. (Besides, Lynx is almost as fancy as
the Emacs' own WoMan browser.)
>> But if you mean that perldoc is just a fancy way to extract the Pods
>> out of the sources, convert them into executable roff code,
>> interpret them with roff, and produce a kind of "extended" ASCII
>> document, -- then I'd like to note that the intermediate roff code
>> is already present on my system, and M-x woman in Emacs shows it
>> without actually executing it with a roff interpreter.
> OK, if that works for you. A lot of Perl programmers use perldoc,
> and rely on it working properly, so providing documentation perldoc
> can't find is not helpful.
Nowhere have I opposed the use of perldoc. What I contest is
the use of perldoc as the ultimate judge of the documentation
format.
To put it another way: if perldoc can't find the documentation,
-- it's clearly a bug. But it's not necessarily a bug in the
/documentation/ itself.
That being said, I'm (obviously) not familiar with perldoc.
Thus, I'm curious if there's any compelling reason for perldoc
/not/ to support, say, DocBook (or DITA, HTML, TEI, etc.)?
[...]
>> Anyway, isn't it possible to install an (additional) groff instance
>> from the ports?
> Why would I want to do that? The only thing I use groff for is to
> read manpages.
ACK. Although I've found some other uses for groff on
occasions, as I've stated before, I don't usually use it for
reading the manpages, either.
[...]
>>>> (Unless the agreement would be to just drop POD altogether, and
>>>> move on to the better tools. Which I still hope for, even
>>>> understanding all the improbability of such a decision.)
>>> We're not going to do that. We *like* Pod.
>> Slightly tangential to the discussion is the question whether the
>> "total manpower" of /we/ is currently rising or diminishing?
> If Perl is dying (which it isn't, by the way), it's not because we
> don't use DocBook.
I didn't assert either of that. (Even though there're several
definitions of "dying," I guess I understand what you mean.)
My point is that I know of no reason for a programmer looking
for a new language to learn to choose Perl, and I'm not actually
seeing a lot of newcomers to join this group lately, either.
(As compared to, say, news:comp.lang.javascript and
news:comp.lang.python... Why, should they get a Perl course on
Coursera, wouldn't it be rightful to call it "The glorious, and
overly long, history of the Perl programming language", or
something like that?)
The other point to note is that even though I'm using Perl for
almost decade and a half now (on and off), I still can't make
head or tail of it at times. On the contrary, while I have put
virtually no effort to learn Python whatsoever, I seem to
understand the code written in it quite well.
So, there're two reasons for me to stick to Perl. First of all,
it has a rich set of (quality) libraries (although Go, and
perhaps Python, Racket, etc. may surpass it in the near future,
if not already have), which appear to cover my demands well.
The other reason is that Perl isn't of the "one size fits all"
type. Contrast it with Python ("one indentation fits all"), or
Racket ("one package format fits all"), or Go ("one
documentation format fits all")...
... Or is it?
[...]
--
FSF associate member #7257
------------------------------
Date: Fri, 28 Jun 2013 14:29:49 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: issues with POD
Message-Id: <87mwqa8isy.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Ivan Shmakov <oneingray@gmail.com>:
>> >>>>> Ben Morrow <ben@morrow.me.uk> writes:
>> >>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>>
>> >> "Command-line perldoc"? What's it?
>>
>> > Are you serious? Run 'perldoc Pod::Man' from your shell prompt.
>>
>> $ perldoc Pod::Man
>> You need to install the perl-doc package to use this program.
>
> Your perl install is broken; it has been mangled by over-zealous
> packagers looking to save a few bytes. You need to find which magic
> package to install to give you the whole thing.
"Please note that whatever precisely constitutes 'the whole thing'
might be subject to change with little or no advance warning based on
what 'certain developers' presently do or don't consider fashionable",
possibly based on outright irrational reasons (or intentionally
disingenious mock arguments. It is not always possible to distinguish
which is which) such as
I find no small irony in a few posts asking whether there's
any reason to use Moose or Mouse or Moo when you can write
your own object accessors by hand (I wrote my own templating
system by hand too. No more.)
Side remark: I should be noted that the suspicion that what was
supposed to be the be-all and end-all of YARFPOO has already again
'logically' splintered into three different semi-compatible
implementations with mutually exclusive design goals is correct. More
to follow as time goes by and old non-solutions to non-problem are
abandoned because their non-maintainers get bored with them and people
discover more aspects in which all of the existing YARFPOOs are deficient
in this or that way and hence, set forth to - once and for all this
time! - nail the jello to the tree in the perfect way 'from scratch'
all over again. Structual similarities to daily soap opera
installments are unintentional but very like not accidental.
I wonder if somebody ever really asked a so thoroughly stupid question
when considering the scope of the moose mouse that mooed versus
'writing accessors'. This looks suspiciously like strawman. 'writing
accessors' is not a particularly sensible activity in its own right:
Objects should provide behaviour and not hierarchically structured
storage. If a particular 'behaviour' can sensibly be abstracted away
from a specific way of handling state information, it shouldn't be
tied to one: The implementation should be capable of working with all
kinds of objects providing a compatible interface and not be part of
any of them. Comparing 'writing accessors' to 'writing a template
system' is again totally bogus: The tasks are of vastly differing
technical complexity.
As a rule of thumb, people resort to sophisms when marketing their
opinions when they can't think of any better way to further their
causes. This may be because they themselves know that they are wrong
or - considering that 'web development' is what the guy who runs the
advertising agency dabbles in - because they're really marketing
specialists to whom all this 'programming stuff' is part of the cost
of displaying advertisements they'd rather (and totally rationally
in this case) want to get rid of.
The problem with this is that computers do more (and much more
sophisticated) things than "being your plastic pal who's fun to be
with" and what minimizes the per-case workload of the guy who decides
on the colour said 'plastic pal' should have today (and hence, helps
him to maximize his income for a given time period) might not be the
most sensible way to construct 24x7 autonomously operating software
system people rely on in order to get some (not inherently
computer-related) job done.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3976
***************************************
