[32716] in Perl-Users-Digest
Perl-Users Digest, Issue: 3980 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jul 3 00:09:19 2013
Date: Tue, 2 Jul 2013 21:09:05 -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 Tue, 2 Jul 2013 Volume: 11 Number: 3980
Today's topics:
Benchmark-ing Tree::Range::RB? <oneingray@gmail.com>
having trouble with hash of arrays... bjobrien62@gmail.com
Re: I'd like to try Perl... (David Combs)
Re: issues with POD <mvdwege@mail.com>
Re: issues with POD <dave@invalid.invalid>
Re: issues with POD <ben@morrow.me.uk>
Re: issues with POD (Seymour J.)
perldoc and perl-doc <oneingray@gmail.com>
Re: perldoc and perl-doc <rweikusat@mssgmbh.com>
Re: perldoc and perl-doc <oneingray@gmail.com>
Re: perldoc and perl-doc <jurgenex@hotmail.com>
Re: perldoc and perl-doc <oneingray@gmail.com>
Re: perldoc and perl-doc <hjp-usenet3@hjp.at>
Re: perldoc and perl-doc <ben@morrow.me.uk>
Re: perldoc and perl-doc <rweikusat@mssgmbh.com>
Re: perldoc and perl-doc <cwilbur@chromatico.net>
will there be a perl version of www.prevayler.org anyti <visphatesjava@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 02 Jul 2013 19:37:37 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Benchmark-ing Tree::Range::RB?
Message-Id: <87r4fg3g8u.fsf_-_@violet.siamics.net>
>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
[...]
> Also, having Set::IntSpan (and Set::IntSpan::Fast, as per the
> documentation) implemented on top of an ordered list seems to imply
> the insertion and deletion times of O (N), while for a red-black tree
> they're both O (log N). Though ::XS may still outperform a pure-Perl
> tree-based implementation on reasonable use cases.
So, I've ran a simplistic benchmark over the three, which is,
roughly (the exact code is as shown below):
# my ($size, $iter) = (4194304, 5);
my @vec
= (map { int (rand ($size)); } (1 .. $size));
my $set
= Set::IntSpan::Fast->new ();
$set->add ($_)
foreach (@vec);
It took awhile to complete, but the results seem to suggest that
Tree::Range::RB is indeed faster than both Set::IntSpan::Fast
and Set::IntSpan, should the problem size be sufficiently large.
Size: 4194304 Iterations: 5 (negative is time in seconds)
Tree::Range::RB: 8003 wallclock secs (7944.34 usr 5.88 sys + 0.00 cusr 0.00 csys = 7950.22 CPU) @ 0.00/s (n=5)
Set::IntSpan: 17759 wallclock secs (17556.78 usr 10.12 sys + 0.00 cusr 0.00 csys = 17566.90 CPU) @ 0.00/s (n=5)
Set::IntSpan::Fast: 19318 wallclock secs (19060.33 usr 9.25 sys + 0.00 cusr 0.00 csys = 19069.58 CPU) @ 0.00/s (n=5)
s/iter Set::IntSpan::Fast Set::IntSpan Tree::Range::RB
Set::IntSpan::Fast 3814 -- -8% -58%
Set::IntSpan 3513 9% -- -55%
Tree::Range::RB 1590 140% 121% --
44565.74user 26.12system 12:31:28elapsed 98%CPU (0avgtext+0avgdata 972212maxresident)k
224inputs+0outputs (1major+316600minor)pagefaults 0swaps
Or did I make some silly mistake with that?
TIA.
### Code:
use common::sense;
use Benchmark qw (cmpthese timethis);
use Scalar::Util qw (looks_like_number);
require Set::IntSpan;
require Set::IntSpan::Fast;
require Tree::Range::RB;
my ($size, $iter)
= (map { (/^0/ ? oct ($_) : $_); } (@ARGV));
$size
//= 0x100000;
$iter
//= -521;
looks_like_number ($size)
or die ($size, ": Size given is not a number\n");
looks_like_number ($iter)
or die ($iter, ": Iterations count given is not a number\n");
warn ("Size: ", 0 + $size, " Iterations: ", 0 + $iter,
" (negative is time in seconds)\n");
my @vec
= (map { int (rand ($size)); } (1 .. $size));
sub xcmp {
## .
$_[0] <=> $_[1];
}
sub xeq {
## .
$_[0] eq $_[1];
}
my $trr
= timethis ($iter,
sub {
my $rat_opt = {
"cmp" => \&xcmp,
"equal-p" => \&xeq
};
my $value
= [ "*value*" ];
my $rat
= Tree::Range::RB->new ($rat_opt);
$rat->range_set ($_, 1 + $_, $value)
foreach (@vec);
},
"Tree::Range::RB", "all");
my $sis
= timethis ($iter,
sub {
my $set
= Set::IntSpan->new ();
$set->insert ($_)
foreach (@vec);
},
"Set::IntSpan", "all");
my $sisf
= timethis ($iter,
sub {
my $set
= Set::IntSpan::Fast->new ();
$set->add ($_)
foreach (@vec);
},
"Set::IntSpan::Fast", "all");
cmpthese ({
"Set::IntSpan" => $sis,
"Set::IntSpan::Fast" => $sisf,
"Tree::Range::RB" => $trr
},
"all");
--
FSF associate member #7257 np. ybjsaf.it
------------------------------
Date: Tue, 2 Jul 2013 17:11:28 -0700 (PDT)
From: bjobrien62@gmail.com
Subject: having trouble with hash of arrays...
Message-Id: <d40f131f-5799-4efd-9484-1683b43c9966@googlegroups.com>
This is confusing me...
I have a patient id and that patient id can have a list of patient names (each with different spelling, but the same person)
my %hash = ();
my $pid = "Patient ID";
my $pname = "Patient Name";
I check to see if there is an entry in the hash for patient ID.
If there is then I want the array of Patient Names for the Patient ID.
Then I want to see if this spelling is found in the Array.
If it is do nothing, if it isn't then I add the new spelling to the array then set that array as the value for the hash pid.
if (exists($hash{$pid})) {
$pnames = $hash{$pid};
@found = grep(/$pname/, @pnames);
$size = @found;
if ($size == 0) {
push(@$names, $pname);
$hash{$pid} = [ @foo ];
}
} else {
$hash{$pid} = [ $pname ];
}
Then I want to print out the list...
my $patid = "";
foreach my $patid (keys %hash) {
print "The spellings for $patid are\n";
foreach (@{$hash{$patid}}) {
print "\t$_\n";
}
}
------------------------------
Date: Wed, 3 Jul 2013 02:31:46 +0000 (UTC)
From: dkcombs@panix.com (David Combs)
Subject: Re: I'd like to try Perl...
Message-Id: <kr02ei$bv7$1@reader2.panix.com>
In article <MPG.2c057fe1b0af9e4b989779@news.eternal-september.org>,
John Black <jblack@nospam.com> wrote:
>In article <d9ac9117-18c9-4114-ad7a-612c23ba1dd5@dk8g2000vbb.googlegroups.com>,
>marc.girod@gmail.com says...
>> Note also the Cygwin option...
>
>Yeah, spend a few minutes checking out the cygwin environment. I started with Strawberry
>Perl and ended up removing it and installing cygwin. You get perl and tons more if you want.
>You choose what you want installed or not installed but what you end up with is an
>environment and set of tools that looks like and includes most of what you get with Unix. In
>fact, when I'm in a cygwin terminal, I can pretty much behave as if its a unix window and
>everything seems to work as I expect.
>
>John Black
Sorry, I use cygwin (via *shell* in emacs), but I don't know
what this "cygwin terminal" is. I probably would benefit
from it!
Any comments or help on it? Thanks!
---
One problem I have is getting the *cygwin* shell stuff to work:
(this is from some time ago, so I might have forgotten
a bit of what I did):
I (thought I) found that if I wanted to use pipes, variables,
etc within a cygwin shell (sh, tcsh (I believe), etc), then
I was required to use that horrible windows "cmd" black-and-white
window, which was really, really gross.
One problem I had was that I could not prepare IN EMACS a command
to execute there, and paste that command into that
horrible cmd window. Could only type it in there by hand,
character by character.
Likewise, I think I recall, it was difficult or impossible
to "copy" text from within that window (for pasting elsewhere);
copying and pasting simply didn't work in cmd windows.
Question: have you found a way to run cygwin shells, etc,
other than within a cmd window?
Question: have you found a way TO do copy, paste, etc
with a cmd window?
And, generally, how do people run the cygwin shells?
In what environment?
Question: how do they get the full features of one
of those shells to work, within emacs? Within, say,
*shell* or *eshell*?
THANKS MUCH FOR ANY HELP!
David
------------------------------
Date: Tue, 02 Jul 2013 10:13:25 +0200
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: issues with POD
Message-Id: <86hagds7kq.fsf@gaheris.avalon.lan>
Ben Morrow <ben@morrow.me.uk> writes:
> However, once you start installing modules directly from CPAN (which I
> don't recommend with an OS-installed perl in any case), or developing
> your own, you start to find that Perl developers assume 'perl vX means
> you have module Y in core', or 'header H', or 'Unicode data file U',
> and these assumptions no longer necessarily hold.
>
> I am speaking from the background of rather a lot of bug reports which
> end up like this
>
> '...I don't have ___.'
> 'You ought to, it's in the core.'
> '...Oh, right, my OS package doesn't include that...'
>
> not to mention the 'but perldoc doesn't work' people we get here from
> time to time.
>
Which is why Debian has helper tools to create your own packages from
CPAN modules.
In case of most modules, a CPAN module can be installed with one
command. The only thing it doesn't do yet is automatic dependency
management, but that is something you don't get with manual installs
either.
And perldoc is a bit of a red herring. Debian users know that Debian
doesn't package docs by default and will see it is a 'Suggested'
package, so they can install it when needed.
The problem is Debian derivatives that stupidly install a subset of
Debian packages without looking at the Suggests for their default build,
and then sell themselves as a ready-made solution for the (beginning)
Linux developer. Yes, I do mean Ubuntu.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Tue, 2 Jul 2013 08:54:43 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: issues with POD
Message-Id: <fV45K0OBJxbE-pn2-O1PE6qgbTSpG@paddington.bear.den>
On Tue, 2 Jul 2013 08:13:25 UTC, Mart van de Wege <mvdwege@mail.com>
wrote:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> > However, once you start installing modules directly from CPAN (which I
> > don't recommend with an OS-installed perl in any case), or developing
> > your own, you start to find that Perl developers assume 'perl vX means
> > you have module Y in core', or 'header H', or 'Unicode data file U',
> > and these assumptions no longer necessarily hold.
> >
> > I am speaking from the background of rather a lot of bug reports which
> > end up like this
> >
> > '...I don't have ___.'
> > 'You ought to, it's in the core.'
> > '...Oh, right, my OS package doesn't include that...'
> >
> > not to mention the 'but perldoc doesn't work' people we get here from
> > time to time.
> >
> Which is why Debian has helper tools to create your own packages from
> CPAN modules.
>
> In case of most modules, a CPAN module can be installed with one
> command. The only thing it doesn't do yet is automatic dependency
> management, but that is something you don't get with manual installs
> either.
>
> And perldoc is a bit of a red herring. Debian users know that Debian
> doesn't package docs by default and will see it is a 'Suggested'
> package, so they can install it when needed.
>
> The problem is Debian derivatives that stupidly install a subset of
> Debian packages without looking at the Suggests for their default build,
> and then sell themselves as a ready-made solution for the (beginning)
> Linux developer. Yes, I do mean Ubuntu.
I just fell over that one with Ubuntu and I was going to ask sometime.
I am not a great fan of Ubuntu so what distro do you perl hackers
recommend so *I* get control of such things?
TIA
--
Regards
Dave Saville
------------------------------
Date: Tue, 2 Jul 2013 11:42:10 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: issues with POD
Message-Id: <2dnaaa-sqt.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
> On Tue, 2 Jul 2013 08:13:25 UTC, Mart van de Wege <mvdwege@mail.com>
> wrote:
>
> > Which is why Debian has helper tools to create your own packages from
> > CPAN modules.
> >
> > In case of most modules, a CPAN module can be installed with one
> > command. The only thing it doesn't do yet is automatic dependency
> > management, but that is something you don't get with manual installs
> > either.
The various CPAN clients will pull in dependencies as needed. What you
don't get natively is uninstall; MakeMaker has an uninstall target, but
it's never really been very reliable, because it has no way of tracking
if a file has been overwritten since it was installed, and because some
modules traditionally use INSTALLDIRS=>"perl" which means you end up
with part of the core missing if you then uninstall them.
But that doesn't help if a module has an undeclared dependency on a bit
of the core which isn't installed (undeclared because it's core, so it
ought to always be there). Nothing automated can work out those deps.
> > And perldoc is a bit of a red herring. Debian users know that Debian
> > doesn't package docs by default and will see it is a 'Suggested'
> > package, so they can install it when needed.
This subthread started with a Debian user who didn't know that.
> > The problem is Debian derivatives that stupidly install a subset of
> > Debian packages without looking at the Suggests for their default build,
> > and then sell themselves as a ready-made solution for the (beginning)
> > Linux developer. Yes, I do mean Ubuntu.
>
> I just fell over that one with Ubuntu and I was going to ask sometime.
> I am not a great fan of Ubuntu so what distro do you perl hackers
> recommend so *I* get control of such things?
FreeBSD. (Though I don't hate Debian itself, despite my complaints, on
the occasions when I need to use Linux specifically.)
Ben
------------------------------
Date: Mon, 01 Jul 2013 17:38:11 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: issues with POD
Message-Id: <51d1f6c3$12$fuzhry+tra$mr2ice@news.patriot.net>
In <87li5r4h33.fsf@violet.siamics.net>, on 06/30/2013
at 05:57 PM, Ivan Shmakov <oneingray@gmail.com> said:
> > A mixture of two different documentation formats could get very
> > ugly very quickly.
> Why?
Tool sets.
> To note is that there already /is/ a mixture,
Not within CPAN.
> > Python and Ruby are in the same tradition. I'd really prefer
> > something more in the tradition of Icon, SNOBOL and Wylbur.
> Could you please show some example, comparing the approaches?
As an example, in Perl I would concisely write [aeiou] while in Icon I
would write the more verbose any('aeiou'). In general, the Perl syntax
for a regex relies heavily on special characters while the other
languages I mentioned rely more heavily on words used as, e.g.,
function names. Icon in particular is nice because it has a cset[1]
(character set) data type and because patterns can be eaily built from
procedures.
[1] I vaguely recall that Perl 6 may have something similar.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 02 Jul 2013 11:17:36 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: perldoc and perl-doc
Message-Id: <874ncd43e7.fsf_-_@violet.siamics.net>
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth "Dave Saville" <dave@invalid.invalid>:
>>>>> On Tue, 2 Jul 2013 08:13:25 UTC, Mart van de Wege wrote:
[...]
>>> And perldoc is a bit of a red herring. Debian users know that
>>> Debian doesn't package docs by default and will see it is a
>>> 'Suggested' package, so they can install it when needed.
> This subthread started with a Debian user who didn't know that.
Even though I think I've clarified this thing up in [1], I'd
like to reiterate it once more: I knew about the perl-doc
package since well before this discussion, and it was indeed the
first package for me to look for "command-line perldoc."
My point was that I never used the latter, and I feel no loss of
that, or an urge to start using it, like, now.
[1] news:877ghe786a.fsf@violet.siamics.net
[...]
PS. And should anyone ask my advice about reading Perl documentation,
it's highly unlikely that perldoc(1) would come to my mind as
something deserving a mention.
--
FSF associate member #7257
------------------------------
Date: Tue, 02 Jul 2013 12:37:59 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: perldoc and perl-doc
Message-Id: <87ppv1xkdk.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
[...]
> PS. And should anyone ask my advice about reading Perl documentation,
> it's highly unlikely that perldoc(1) would come to my mind as
> something deserving a mention.
perldoc -f is quite useful for looking up descriptions of individual
builtin functions/operators. I also perldoc -q, although less
frequently.
------------------------------
Date: Tue, 02 Jul 2013 14:34:32 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: perldoc and perl-doc
Message-Id: <87zju52fpj.fsf@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>> Ivan Shmakov <oneingray@gmail.com> writes: [...]
>> PS. And should anyone ask my advice about reading Perl
>> documentation, it's highly unlikely that perldoc(1) would come to my
>> mind as something deserving a mention.
> perldoc -f is quite useful for looking up descriptions of individual
> builtin functions/operators.
How is it different to pointing one's browser at, say,
http://perldoc.perl.org/functions/NAME.html?
> I also perldoc -q, although less frequently.
Indeed, a sensible application. (And it certainly looks like a
kind of a "structured" search facility.)
But what makes me wonder is: was it added to work-around the
whole issue of the Perl FAQ being split into several manpages?
--
FSF associate member #7257
------------------------------
Date: Tue, 02 Jul 2013 08:18:44 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: perldoc and perl-doc
Message-Id: <ndr5t8t336dlpfhjrrbm4o316o8rnfnaot@4ax.com>
Ivan Shmakov <oneingray@gmail.com> wrote:
>>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>>> Ivan Shmakov <oneingray@gmail.com> writes: [...]
>
> >> PS. And should anyone ask my advice about reading Perl
> >> documentation, it's highly unlikely that perldoc(1) would come to my
> >> mind as something deserving a mention.
>
> > perldoc -f is quite useful for looking up descriptions of individual
> > builtin functions/operators.
>
> How is it different to pointing one's browser at, say,
> http://perldoc.perl.org/functions/NAME.html?
There is no need for an additional tool, i.e. a browser. There is no
need for an Internet connection. And the documentation is actually
matching the version of Perl that I am using.
jue
------------------------------
Date: Tue, 02 Jul 2013 15:23:38 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: perldoc and perl-doc
Message-Id: <87vc4t2dfp.fsf@violet.siamics.net>
>>>>> Jürgen Exner <jurgenex@hotmail.com> writes:
[...]
>>> perldoc -f is quite useful for looking up descriptions of
>>> individual builtin functions/operators.
>> How is it different to pointing one's browser at, say,
>> http://perldoc.perl.org/functions/NAME.html?
> There is no need for an additional tool, i. e. a browser.
For me, it's perldoc(1) that's an "additional" tool.
> There is no need for an Internet connection.
Indeed. However, a developer is likely to have one, anyway.
> And the documentation is actually matching the version of Perl that I
> am using.
OTOH, the documentation packaged with the version of Perl used
may still have bugs already resolved in the newer version served
from http://perldoc.perl.org/.
--
FSF associate member #7257
------------------------------
Date: Tue, 2 Jul 2013 17:38:43 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: perldoc and perl-doc
Message-Id: <slrnkt5t03.vuk.hjp-usenet3@hrunkner.hjp.at>
On 2013-07-02 15:18, Jürgen Exner <jurgenex@hotmail.com> wrote:
> Ivan Shmakov <oneingray@gmail.com> wrote:
>> How is it different to pointing one's browser at, say,
>> http://perldoc.perl.org/functions/NAME.html?
>
> There is no need for an additional tool, i.e. a browser. There is no
> need for an Internet connection. And the documentation is actually
> matching the version of Perl that I am using.
And it works for all perl-related stuff I have installed: Perl core,
CPAN modules, modules and scripts developed in-house ...
http://perldoc.perl.org/ only covers the core. HTML-formatted docs for
CPAN modules are on http://search.cpan.org. And your own stuff is
whereever you (or your co-workers) put it. So that's at least three
different places. With perldoc it's only one.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Tue, 2 Jul 2013 16:37:42 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: perldoc and perl-doc
Message-Id: <6n8baa-0vp.ln1@anubis.morrow.me.uk>
Quoth Ivan Shmakov <oneingray@gmail.com>:
> >>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> >>>>> Ivan Shmakov <oneingray@gmail.com> writes: [...]
>
> >> PS. And should anyone ask my advice about reading Perl
> >> documentation, it's highly unlikely that perldoc(1) would come to my
> >> mind as something deserving a mention.
>
> > perldoc -f is quite useful for looking up descriptions of individual
> > builtin functions/operators.
>
> How is it different to pointing one's browser at, say,
> http://perldoc.perl.org/functions/NAME.html?
It doesn't hit the network? It doesn't involve leaving your terminal
window and using a whole nother program? (I realise this may be less of
a concern if you live inside Emacs, as I gather you do.) It's
considerably older, so many of us don't carry perldoc.perl.org in our
conscious mind (indeed, if I found myself needing to read the core docs
on a machine without perl installed, I'd probably find the perl tarball
on search.cpan.org instead).
Also, and perhaps more importantly, it gives you the documentation for
the version of perl you are running.
> > I also perldoc -q, although less frequently.
>
> Indeed, a sensible application. (And it certainly looks like a
> kind of a "structured" search facility.)
>
> But what makes me wonder is: was it added to work-around the
> whole issue of the Perl FAQ being split into several manpages?
Probably it was added to 'work around' the fact that the perl FAQ is
rather large, and searching with less(1) would come up with lots of
false positives. (And some systems don't even have less.)
perldoc -X *ought* to be useful, but in practice the perl infrastructure
hasn't yet got on top of building the index and keeping it up to date.
At some point someone went through all the core docs and put in a whole
lot of X<> entries, so it seems someone wants it to be useful.
Ben
------------------------------
Date: Tue, 02 Jul 2013 17:20:00 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: perldoc and perl-doc
Message-Id: <87vc4t9bnz.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
>>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>>> Ivan Shmakov <oneingray@gmail.com> writes: [...]
>
> >> PS. And should anyone ask my advice about reading Perl
> >> documentation, it's highly unlikely that perldoc(1) would come to my
> >> mind as something deserving a mention.
>
> > perldoc -f is quite useful for looking up descriptions of individual
> > builtin functions/operators.
>
> How is it different to pointing one's browser at, say,
> http://perldoc.perl.org/functions/NAME.html?
It prints a help message telling me that perldoc -f needs an argument
(and some other information) instead of 'The requested URL
/functions/NAME.html was not found on this server' (SCNR).
I consider it more convenient to use: It is easier to type than the
WWW-based version, it uses 'my default pager' whose search
facilities are more comfortable to use and more powerful than those of
firefox, it displays less stuff I don't care for and it is faster. It
is also more reliable because it works regardless of the conditions
'on the internet' ATM, using local computing facilities in order to
access the documentation is nicer to the people who generously provide
the perldoc WWW-service and - last but not least - it is better for
national security because it doesn't inject additional noise into
worlds largest and technically most sophiscated facility for storing
p0rn trailers and 'penis enlargment pills!' spam mails some very
duteous people built using tax payer's money so that they can sift
through all this trash to ensure that there are no terorists hiding
somewhere in it.
Possibly offensive content below the page break.
Also, imagine the frustation of someone who is one a holy mission to
locate child pornography who only ever gets Perl documentation. Surely
the cause of quite a few nervous breakdowns ...
------------------------------
Date: Tue, 02 Jul 2013 12:08:56 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: perldoc and perl-doc
Message-Id: <87ip0tgd0n.fsf@new.chromatico.net>
>>>>> "IS" == Ivan Shmakov <oneingray@gmail.com> writes:
IS> How is [perldoc -f] different to pointing one's browser at, say,
IS> http://perldoc.perl.org/functions/NAME.html?
perldoc -f uses the perl documentation associated with your
installation. perldoc.perl.org takes extra steps and brainpower to
ensure that they match.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Tue, 2 Jul 2013 11:16:26 -0700 (PDT)
From: johannes falcone <visphatesjava@gmail.com>
Subject: will there be a perl version of www.prevayler.org anytime soon?
Message-Id: <d6d9c650-6ee0-4573-8c79-f2d72766b5fa@googlegroups.com>
It seems computing world will converge toward prevayler sooner or later.
A web framework using prevayler from getgo would seem to dominate the future.
With moose it seems www.prevayler.org could be redone in perl.
Anyone try yet?
------------------------------
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 3980
***************************************
