[29997] in Perl-Users-Digest
Perl-Users Digest, Issue: 1240 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jan 29 14:09:43 2008
Date: Tue, 29 Jan 2008 11:09:07 -0800 (PST)
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, 29 Jan 2008 Volume: 11 Number: 1240
Today's topics:
Re: A do-file location: how the code inside that do-fil <snhirsch@gmail.com>
Re: Get an arbitrary hash key, quickly. <simon.chao@fmr.com>
Re: Get an arbitrary hash key, quickly. <ben@morrow.me.uk>
Re: Get an arbitrary hash key, quickly. xhoster@gmail.com
Re: Get an arbitrary hash key, quickly. xhoster@gmail.com
Re: Get an arbitrary hash key, quickly. xhoster@gmail.com
Re: Get an arbitrary hash key, quickly. xhoster@gmail.com
Re: Get an arbitrary hash key, quickly. <ced@blv-sam-01.ca.boeing.com>
Re: mod_perl ignoring changed to $ENV{{PATH}? ian.sillitoe@googlemail.com
Odd (undocumented?) behavior of RAM file within a loop <usenet@davidfilmer.com>
Posting Guidelines for comp.lang.perl.misc ($Revision: tadmc@seesig.invalid
Re: regular expression negate a word (not character) (Greg Bacon)
scalar to array? <user@example.net>
Re: scalar to array? xhoster@gmail.com
Re: uniq without sort <-------------- GURU NEEDED <eedmit@NO.eed.SPAM.ericsson.PLS.se>
Using Imager module to resample images <jwcarlton@gmail.com>
Re: Using Imager module to resample images <zentara@highstream.net>
Re: Using Imager module to resample images <abigail@abigail.be>
Re: Using Imager module to resample images <1usa@llenroc.ude.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 29 Jan 2008 08:04:42 -0500
From: Steven Hirsch <snhirsch@gmail.com>
Subject: Re: A do-file location: how the code inside that do-file find it?
Message-Id: <64GdnTaHlLT3uQLanZ2dnUVZ_sWdnZ2d@giganews.com>
Michele Dondi wrote:
> On Mon, 21 Jan 2008 15:02:46 -0800 (PST), "comp.llang.perl.moderated"
> <ced@blv-sam-01.ca.boeing.com> wrote:
>
>> I would have thought 'FindBin' (perldoc FindBin) would have been the
>> best answer if the former.
>
> OTOH FindBin is somewhat bugged.
For _real_ entertainment, try FindBin when the script is about 8 levels deep
in a large AFS filesystem.
------------------------------
Date: Tue, 29 Jan 2008 08:04:53 -0800 (PST)
From: nolo contendere <simon.chao@fmr.com>
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <e02ac247-dd59-4d40-9126-08774105d1bb@s8g2000prg.googlegroups.com>
On Jan 28, 8:05=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth nolo contendere <simon.c...@gmail.com>:
>
> > On Jan 28, 5:52=A0pm, "comp.llang.perl.moderated" <c...@blv-
> > sam-01.ca.boeing.com> wrote:
>
> > > Do you need 'each' since values don't seem
> > > to be retrieved...Some simple benchmarks
> > > suggest just looping over the keys would
> > > be quite a bit faster if that's the case:
>
> > > QUEUE: {
> > > =A0 foreach my $to_do (keys %hash) {
> > > =A0 =A0 =A0delete $hash{$to_do};
> > > =A0 =A0 =A0## do stuff with $to_do, which might
> > > =A0 =A0 =A0 =A0 # make new entries in %hash
> > > =A0 }
> > > =A0 redo QUEUE if keys %hash;
>
> > > }
>
> > perldoc perlsyn:
> > =A0 =A0 =A0 =A0...
> > =A0 =A0 =A0 =A0If any part of LIST is an array, "foreach" will get very
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^^^^^^^^^
> It isn't. keys returns a list. What *is* true in this case is that if
> any entries you haven't got to yet are deleted from the hash, they will
hmm, I thought it was unsafe to delete any entries other than the one
just accessed.
> still be in for's list and will be returned anyway; since that isn't the
> case here, it doesn't matter.
>
right. my understanding is that for (and foreach) take a snapshot of
the list, and iterate through that snapshot.
> However, I would have thought that as the number of keys gets larger,
> this get slower, since it has to build a complete list of the keys each
> time through QUEUE. Let's see...
>
wouldn't every subsequent list be smaller for the most part? unless
"do stuff" generated more keys than were deleted on average.
------------------------------
Date: Tue, 29 Jan 2008 16:38:12 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <kc1475-pvb.ln1@osiris.mauzo.dyndns.org>
Quoth nolo contendere <simon.chao@fmr.com>:
> On Jan 28, 8:05 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> >
> > It isn't. keys returns a list. What *is* true in this case is that if
> > any entries you haven't got to yet are deleted from the hash, they will
>
> hmm, I thought it was unsafe to delete any entries other than the one
> just accessed.
No, this is a misconception (though one that is somewhat supported by
the docs). See http://blog.plover.com/prog/perl/undefined.html#3 .
Deleting the current entry is actually the potentially-unsafe case, but
perl special-cases it for you so it works correctly (the entry has to be
deleted lazily, after the iterator has moved on to the next entry).
In any case, none of this applies to
for (keys %h) { ... }
keys is in list context, so the complete list of keys is generated
before the loop even starts iterating.
> > still be in for's list and will be returned anyway; since that isn't the
> > case here, it doesn't matter.
>
> right. my understanding is that for (and foreach) take a snapshot of
> the list, and iterate through that snapshot.
Not quite; keys returns a list which is a snapshot of the current set of
keys. What you do with that list afterwards is irrelevant.
> > However, I would have thought that as the number of keys gets larger,
> > this get slower, since it has to build a complete list of the keys each
> > time through QUEUE. Let's see...
>
> wouldn't every subsequent list be smaller for the most part? unless
> "do stuff" generated more keys than were deleted on average.
No, that wasn't what I meant. I meant 'as the initial set of keys
becomes large, perhaps building a complete list of that set becomes
inefficient'. It seems it doesn't.
Ben
------------------------------
Date: 29 Jan 2008 16:50:50 GMT
From: xhoster@gmail.com
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <20080129115051.993$Ge@newsreader.com>
nolo contendere <simon.chao@gmail.com> wrote:
> >
> > QUEUE: {
> > =A0 foreach my $to_do (keys %hash) {
> > =A0 =A0 =A0delete $hash{$to_do};
> > =A0 =A0 =A0## do stuff with $to_do, which might
> > =A0 =A0 =A0 =A0 # make new entries in %hash
> > =A0 }
> > =A0 redo QUEUE if keys %hash;
> >
> > }
> >
>
> perldoc perlsyn:
> ...
> If any part of LIST is an array, "foreach" will get very
> confused if
> you add or remove elements within the loop body, for example
> with
> "splice". So don't do that.
But in this case, no part of the LIST is an array. keys %hash is not
an array.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: 29 Jan 2008 17:00:48 GMT
From: xhoster@gmail.com
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <20080129120050.119$y5@newsreader.com>
"comp.llang.perl.moderated" <ced@blv-sam-01.ca.boeing.com> wrote:
> >
> > while (%hash) { # does not reset iterator
> > my $to_do=each %hash;
> > next unless defined $to_do; # not a real hash key,
> > # signals end of iterator
> > ## do stuff with $to_do, which might make new entries in %hash
> >
> > };
> >
> > If my speculation on the internals is right, then this would still
> > perform poorly if the hash first grows very large, then shrinks to
> > be only a few elements, but those last few elements keep triggering
> > the addition of just one more element each time. In my case, that
> > shouldn't be a problem.
> >
> > Any comments on this code? Is there some less quirky way to do this
> > efficiently? Is there a simple (as simple as perl's internals can get)
> > way to fix "each" so that it doesn't have this degenerate case?
>
> Do you need 'each' since values don't seem
> to be retrieved...Some simple benchmarks
> suggest just looping over the keys would
> be quite a bit faster if that's the case:
>
> QUEUE: {
> foreach my $to_do (keys %hash) {
> delete $hash{$to_do};
> ## do stuff with $to_do, which might
> # make new entries in %hash
> }
> redo QUEUE if keys %hash;
> }
I like it. It does have a 2nd caching structure, but that structure is
implicit and entirely managed by perl as part of the foreach loop. I might
change the outer loop syntax somewhat, as I prefer to avoid labels
whenever possible.
while (keys %hash) {
foreach my $to_do (keys %hash) {
delete $hash{$to_do};
## do stuff with $to_do, which might
# make new entries in %hash
}
}
(Causes one extra scalar "keys %hash", but that shouldn't be a problem)
The "do stuff" can only add new entries, not remove entries (other than
$to_do itself) without causing problems. Deleting wasn't part of the
original specification, and that limitation is not a problem in this
particular case.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: 29 Jan 2008 17:20:23 GMT
From: xhoster@gmail.com
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <20080129122025.013$Dt@newsreader.com>
nolo contendere <simon.chao@fmr.com> wrote:
> On Jan 28, 8:05=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > Quoth nolo contendere <simon.c...@gmail.com>:
> >
> > > On Jan 28, 5:52=A0pm, "comp.llang.perl.moderated" <c...@blv-
> > > sam-01.ca.boeing.com> wrote:
> >
> > > > Do you need 'each' since values don't seem
> > > > to be retrieved...Some simple benchmarks
> > > > suggest just looping over the keys would
> > > > be quite a bit faster if that's the case:
> >
> > > > QUEUE: {
> > > > =A0 foreach my $to_do (keys %hash) {
> > > > =A0 =A0 =A0delete $hash{$to_do};
> > > > =A0 =A0 =A0## do stuff with $to_do, which might
> > > > =A0 =A0 =A0 =A0 # make new entries in %hash
> > > > =A0 }
> > > > =A0 redo QUEUE if keys %hash;
> >
> > > > }
> >
> > > perldoc perlsyn:
> > > =A0 =A0 =A0 =A0...
> > > =A0 =A0 =A0 =A0If any part of LIST is an array, "foreach" will get
> > > very
> >
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^^^^^^^^^
> > It isn't. keys returns a list. What *is* true in this case is that if
> > any entries you haven't got to yet are deleted from the hash, they will
>
> hmm, I thought it was unsafe to delete any entries other than the one
> just accessed.
That is with "each %hash", not with "keys %hash".
>
> > still be in for's list and will be returned anyway; since that isn't
> > the case here, it doesn't matter.
> >
>
> right. my understanding is that for (and foreach) take a snapshot of
> the list, and iterate through that snapshot.
Except when the LIST of the foreach has an array in it, then it doesn't
take a snapshot--it does something else (presumably as an optimization),
the details of which are not documented but the effects of which are
(weirdness when changing the array).
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: 29 Jan 2008 17:31:56 GMT
From: xhoster@gmail.com
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <20080129123158.376$FG@newsreader.com>
Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth nolo contendere <simon.chao@gmail.com>:
> > On Jan 28, 5:52 pm, "comp.llang.perl.moderated" <c...@blv-
> > sam-01.ca.boeing.com> wrote:
> > >
> > > Do you need 'each' since values don't seem
> > > to be retrieved...Some simple benchmarks
> > > suggest just looping over the keys would
> > > be quite a bit faster if that's the case:
> > >
> > > QUEUE: {
> > > foreach my $to_do (keys %hash) {
> > > delete $hash{$to_do};
> > > ## do stuff with $to_do, which might
> > > # make new entries in %hash
> > > }
> > > redo QUEUE if keys %hash;
> > >
> > > }
> > >
> >
> > perldoc perlsyn:
> > ...
> > If any part of LIST is an array, "foreach" will get very
> ^^^^^^^^^^^
> It isn't. keys returns a list. What *is* true in this case is that if
> any entries you haven't got to yet are deleted from the hash, they will
> still be in for's list and will be returned anyway; since that isn't the
> case here, it doesn't matter.
>
> However, I would have thought that as the number of keys gets larger,
> this get slower, since it has to build a complete list of the keys each
> time through QUEUE.
I'm sure you already know this, but just be clear for others, I think the
potential slowness you hypothetically referring to is just a constant
multiplier of slowness (and a rather small one at that), right? The
slowness that I originally posted about was of a different
sort--pathological slowness that seems to be around O(N**2) when it really
"should" be O(N).
Once I take care of the O(N**2)->O(N), I'm not so interested in
microoptimizing the rest, except as a theoretical curiosity.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Tue, 29 Jan 2008 09:55:16 -0800 (PST)
From: "comp.llang.perl.moderated" <ced@blv-sam-01.ca.boeing.com>
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <534fe8d7-466c-406a-b660-61727b0e54ed@1g2000hsl.googlegroups.com>
On Jan 29, 9:00 am, xhos...@gmail.com wrote:
> "comp.llang.perl.moderated" <c...@blv-sam-01.ca.boeing.com> wrote:
>
> > > while (%hash) { # does not reset iterator
> > > my $to_do=each %hash;
> > > next unless defined $to_do; # not a real hash key,
> > > # signals end of iterator
> > > ## do stuff with $to_do, which might make new entries in %hash
>
> > > };
>
> > > If my speculation on the internals is right, then this would still
> > > perform poorly if the hash first grows very large, then shrinks to
> > > be only a few elements, but those last few elements keep triggering
> > > the addition of just one more element each time. In my case, that
> > > shouldn't be a problem.
>
> > > Any comments on this code? Is there some less quirky way to do this
> > > efficiently? Is there a simple (as simple as perl's internals can get)
> > > way to fix "each" so that it doesn't have this degenerate case?
>
> > Do you need 'each' since values don't seem
> > to be retrieved...Some simple benchmarks
> > suggest just looping over the keys would
> > be quite a bit faster if that's the case:
>
> > QUEUE: {
> > foreach my $to_do (keys %hash) {
> > delete $hash{$to_do};
> > ## do stuff with $to_do, which might
> > # make new entries in %hash
> > }
> > redo QUEUE if keys %hash;
> > }
>
> I like it. It does have a 2nd caching structure, but that structure is
> implicit and entirely managed by perl as part of the foreach loop. I might
> change the outer loop syntax somewhat, as I prefer to avoid labels
> whenever possible.
>
> while (keys %hash) {
> foreach my $to_do (keys %hash) {
> delete $hash{$to_do};
> ## do stuff with $to_do, which might
> # make new entries in %hash
> }}
>
> (Causes one extra scalar "keys %hash", but that shouldn't be a problem)
>
> The "do stuff" can only add new entries, not remove entries (other than
> $to_do itself) without causing problems. Deleting wasn't part of the
> original specification, and that limitation is not a problem in this
> particular case.
>
Memory might be the only issue then. And it's
really nice to have Ben explain how it really
all works :)
--
Charles
------------------------------
Date: Tue, 29 Jan 2008 08:27:27 -0800 (PST)
From: ian.sillitoe@googlemail.com
Subject: Re: mod_perl ignoring changed to $ENV{{PATH}?
Message-Id: <39039e1c-0fd2-427e-9a53-8ac9fc11cbe3@t1g2000pra.googlegroups.com>
On Jan 15, 3:30 pm, bwooster47 <bwooste...@gmail.com> wrote:
> I've narrowed down to a simple script a problem where it looks like
> when running undermod_perl, it does not support changes to the
> $ENV{PATH} variable - it does require the assignment to avoid the
> tainting, but then any assignment itself does not take effect - I
> added /usr/local/bin to PATH, but am unable to execute commands in
> that folder when running undermod_perl.
>
> Could not find anything about this in themod_perlweb pages, but a
> Usenet search seems to suggest thatmod_perlonly honors PerlSetEnv
> PATH in config, and does not honor PATH changes in the script? That
> does not sound right, what about the cases where a PATH change is
> needed for some scripts only, so a global PerlSetEnv would be too
> much.
>
> Example - for testing, I copied /bin/echo to /usr/local/bin/echo, and
> then ran this script - it runs fine when run under the shell, but when
> run under Apache +mod_perl, it fails.
>
> Script:
> #!/usr/bin/perl -Tw
>
> print "Content-type: text/plain\n\n";
>
> $ENV{PATH} = "/bin:/usr/bin:/usr/local/bin:";
> foreach ( "echo", "myecho", "/usr/local/bin/myecho") {
> print "------ Testing command '$_'\n";
> my $string = `$_ testing execution of '$_'`;
> print " failed to execute '$_', \$? is $?/" . ($? >> 8) . " : $!
> \n"
> if ($? != 0);
> print " \$string is: $string\n";
>
> }
>
> Shell output (perl -Tw script)
> Content-type: text/plain
>
> ------ Testing command 'echo'
> $string is: testing execution of echo
>
> ------ Testing command 'myecho'
> $string is: testing execution of myecho
>
> ------ Testing command '/usr/local/bin/myecho'
> $string is: testing execution of /usr/local/bin/myecho
>
> Web page output - this fails to execute myecho without the path:
> ------ Testing command 'echo'
> $string is: testing execution of echo
>
> ------ Testing command 'myecho'
> failed to execute 'myecho', $? is 32512/127 :
> $string is:
> ------ Testing command '/usr/local/bin/myecho'
> $string is: testing execution of /usr/local/bin/myecho
This looks like a 'Taint' issue - I would check by running it without
the 'T' switch. If you want to use Taint (which you will) then you
could look at the perl5lib CPAN package which is Taint-safe
http://search.cpan.org/~nobull/perl5lib-1.02/lib/perl5lib.pm
------------------------------
Date: Tue, 29 Jan 2008 10:53:48 -0800
From: David Filmer <usenet@davidfilmer.com>
Subject: Odd (undocumented?) behavior of RAM file within a loop
Message-Id: <2eOdndq_7J5h6ALaRVn_vwA@giganews.com>
Greetings. I am writing a program which processes some files within a
loop, and I am using the ability (as of Perl 5.8) to open a filehandle
on a scalar reference (which I recycle in the loop). Kindly consider
this stripped-down trivial code example which illustrates my question:
#!/usr/bin/perl
use strict; use warnings;
foreach (1..3) {
warn "Pass #$_\n";
my $file_in_memory;
open(my $fh, '>', \$file_in_memory) or die "Oops - $!\n";
close $fh;
}
__END__
It works fine for the first pass. However, subsequent passes emit warnings:
Pass #1
Pass #2
Use of uninitialized value in open at /perl/blah line 7.
Pass #3
Use of uninitialized value in open at /perl/blah line 7.
(line 7 is the "open" statement). Sure enough, if I make this change to
"initialize" the scalar:
my $file_in_memory = '';
then I have no problems (except I bust the second rule of chapter 4 in
Dr. Damian's _PBP_ - yikes).
Although the problem is easy enough to work around, I wonder why it
behaves this way (which I don't see documented). The really strange
thing (to me) is that it doesn't complain on the first pass. Any ideas?
Thx!
--
David Filmer (http://DavidFilmer.com)
------------------------------
Date: Tue, 29 Jan 2008 08:14:14 GMT
From: tadmc@seesig.invalid
Subject: Posting Guidelines for comp.lang.perl.misc ($Revision: 1.8 $)
Message-Id: <qfBnj.5083$so6.2088@newssvr19.news.prodigy.net>
Outline
Before posting to comp.lang.perl.misc
Must
- Check the Perl Frequently Asked Questions (FAQ)
- Check the other standard Perl docs (*.pod)
Really Really Should
- Lurk for a while before posting
- Search a Usenet archive
If You Like
- Check Other Resources
Posting to comp.lang.perl.misc
Is there a better place to ask your question?
- Question should be about Perl, not about the application area
How to participate (post) in the clpmisc community
- Carefully choose the contents of your Subject header
- Use an effective followup style
- Speak Perl rather than English, when possible
- Ask perl to help you
- Do not re-type Perl code
- Provide enough information
- Do not provide too much information
- Do not post binaries, HTML, or MIME
Social faux pas to avoid
- Asking a Frequently Asked Question
- Asking a question easily answered by a cursory doc search
- Asking for emailed answers
- Beware of saying "doesn't work"
- Sending a "stealth" Cc copy
Be extra cautious when you get upset
- Count to ten before composing a followup when you are upset
- Count to ten after composing and before posting when you are upset
-----------------------------------------------------------------
Posting Guidelines for comp.lang.perl.misc ($Revision: 1.8 $)
This newsgroup, commonly called clpmisc, is a technical newsgroup
intended to be used for discussion of Perl related issues (except job
postings), whether it be comments or questions.
As you would expect, clpmisc discussions are usually very technical in
nature and there are conventions for conduct in technical newsgroups
going somewhat beyond those in non-technical newsgroups.
The article at:
http://www.catb.org/~esr/faqs/smart-questions.html
describes how to get answers from technical people in general.
This article describes things that you should, and should not, do to
increase your chances of getting an answer to your Perl question. It is
available in POD, HTML and plain text formats at:
http://www.rehabitation.com/clpmisc.shtml
For more information about netiquette in general, see the "Netiquette
Guidelines" at:
http://andrew2.andrew.cmu.edu/rfc/rfc1855.html
A note to newsgroup "regulars":
Do not use these guidelines as a "license to flame" or other
meanness. It is possible that a poster is unaware of things
discussed here. Give them the benefit of the doubt, and just
help them learn how to post, rather than assume that they do
know and are being the "bad kind" of Lazy.
A note about technical terms used here:
In this document, we use words like "must" and "should" as
they're used in technical conversation (such as you will
encounter in this newsgroup). When we say that you *must* do
something, we mean that if you don't do that something, then
it's unlikely that you will benefit much from this group.
We're not bossing you around; we're making the point without
lots of words.
Do *NOT* send email to the maintainer of these guidelines. It will be
discarded unread. The guidelines belong to the newsgroup so all
discussion should appear in the newsgroup. I am just the secretary that
writes down the consensus of the group.
Before posting to comp.lang.perl.misc
Must
This section describes things that you *must* do before posting to
clpmisc, in order to maximize your chances of getting meaningful replies
to your inquiry and to avoid getting flamed for being lazy and trying to
have others do your work.
The perl distribution includes documentation that is copied to your hard
drive when you install perl. Also installed is a program for looking
things up in that (and other) documentation named 'perldoc'.
You should either find out where the docs got installed on your system,
or use perldoc to find them for you. Type "perldoc perldoc" to learn how
to use perldoc itself. Type "perldoc perl" to start reading Perl's
standard documentation.
Check the Perl Frequently Asked Questions (FAQ)
Checking the FAQ before posting is required in Big 8 newsgroups in
general, there is nothing clpmisc-specific about this requirement.
You are expected to do this in nearly all newsgroups.
You can use the "-q" switch with perldoc to do a word search of the
questions in the Perl FAQs.
Check the other standard Perl docs (*.pod)
The perl distribution comes with much more documentation than is
available for most other newsgroups, so in clpmisc you should also
see if you can find an answer in the other (non-FAQ) standard docs
before posting.
It is *not* required, or even expected, that you actually *read* all of
Perl's standard docs, only that you spend a few minutes searching them
before posting.
Try doing a word-search in the standard docs for some words/phrases
taken from your problem statement or from your very carefully worded
"Subject:" header.
Really Really Should
This section describes things that you *really should* do before posting
to clpmisc.
Lurk for a while before posting
This is very important and expected in all newsgroups. Lurking means
to monitor a newsgroup for a period to become familiar with local
customs. Each newsgroup has specific customs and rituals. Knowing
these before you participate will help avoid embarrassing social
situations. Consider yourself to be a foreigner at first!
Search a Usenet archive
There are tens of thousands of Perl programmers. It is very likely
that your question has already been asked (and answered). See if you
can find where it has already been answered.
One such searchable archive is:
http://groups.google.com/advanced_group_search
If You Like
This section describes things that you *can* do before posting to
clpmisc.
Check Other Resources
You may want to check in books or on web sites to see if you can
find the answer to your question.
But you need to consider the source of such information: there are a
lot of very poor Perl books and web sites, and several good ones
too, of course.
Posting to comp.lang.perl.misc
There can be 200 messages in clpmisc in a single day. Nobody is going to
read every article. They must decide somehow which articles they are
going to read, and which they will skip.
Your post is in competition with 199 other posts. You need to "win"
before a person who can help you will even read your question.
These sections describe how you can help keep your article from being
one of the "skipped" ones.
Is there a better place to ask your question?
Question should be about Perl, not about the application area
It can be difficult to separate out where your problem really is,
but you should make a conscious effort to post to the most
applicable newsgroup. That is, after all, where you are the most
likely to find the people who know how to answer your question.
Being able to "partition" a problem is an essential skill for
effectively troubleshooting programming problems. If you don't get
that right, you end up looking for answers in the wrong places.
It should be understood that you may not know that the root of your
problem is not Perl-related (the two most frequent ones are CGI and
Operating System related), so off-topic postings will happen from
time to time. Be gracious when someone helps you find a better place
to ask your question by pointing you to a more applicable newsgroup.
How to participate (post) in the clpmisc community
Carefully choose the contents of your Subject header
You have 40 precious characters of Subject to win out and be one of
the posts that gets read. Don't waste them. Take care while
composing them, they are the key that opens the door to getting an
answer.
Spend them indicating what aspect of Perl others will find if they
should decide to read your article.
Do not spend them indicating "experience level" (guru, newbie...).
Do not spend them pleading (please read, urgent, help!...).
Do not spend them on non-Subjects (Perl question, one-word
Subject...)
For more information on choosing a Subject see "Choosing Good
Subject Lines":
http://www.cpan.org/authors/id/D/DM/DMR/subjects.post
Part of the beauty of newsgroup dynamics, is that you can contribute
to the community with your very first post! If your choice of
Subject leads a fellow Perler to find the thread you are starting,
then even asking a question helps us all.
Use an effective followup style
When composing a followup, quote only enough text to establish the
context for the comments that you will add. Always indicate who
wrote the quoted material. Never quote an entire article. Never
quote a .signature (unless that is what you are commenting on).
Intersperse your comments *following* each section of quoted text to
which they relate. Unappreciated followup styles are referred to as
"top-posting", "Jeopardy" (because the answer comes before the
question), or "TOFU" (Text Over, Fullquote Under).
Reversing the chronology of the dialog makes it much harder to
understand (some folks won't even read it if written in that style).
For more information on quoting style, see:
http://web.presby.edu/~nnqadmin/nnq/nquote.html
Speak Perl rather than English, when possible
Perl is much more precise than natural language. Saying it in Perl
instead will avoid misunderstanding your question or problem.
Do not say: I have variable with "foo\tbar" in it.
Instead say: I have $var = "foo\tbar", or I have $var = 'foo\tbar',
or I have $var = <DATA> (and show the data line).
Ask perl to help you
You can ask perl itself to help you find common programming mistakes
by doing two things: enable warnings (perldoc warnings) and enable
"strict"ures (perldoc strict).
You should not bother the hundreds/thousands of readers of the
newsgroup without first seeing if a machine can help you find your
problem. It is demeaning to be asked to do the work of a machine. It
will annoy the readers of your article.
You can look up any of the messages that perl might issue to find
out what the message means and how to resolve the potential mistake
(perldoc perldiag). If you would like perl to look them up for you,
you can put "use diagnostics;" near the top of your program.
Do not re-type Perl code
Use copy/paste or your editor's "import" function rather than
attempting to type in your code. If you make a typo you will get
followups about your typos instead of about the question you are
trying to get answered.
Provide enough information
If you do the things in this item, you will have an Extremely Good
chance of getting people to try and help you with your problem!
These features are a really big bonus toward your question winning
out over all of the other posts that you are competing with.
First make a short (less than 20-30 lines) and *complete* program
that illustrates the problem you are having. People should be able
to run your program by copy/pasting the code from your article. (You
will find that doing this step very often reveals your problem
directly. Leading to an answer much more quickly and reliably than
posting to Usenet.)
Describe *precisely* the input to your program. Also provide example
input data for your program. If you need to show file input, use the
__DATA__ token (perldata.pod) to provide the file contents inside of
your Perl program.
Show the output (including the verbatim text of any messages) of
your program.
Describe how you want the output to be different from what you are
getting.
If you have no idea at all of how to code up your situation, be sure
to at least describe the 2 things that you *do* know: input and
desired output.
Do not provide too much information
Do not just post your entire program for debugging. Most especially
do not post someone *else's* entire program.
Do not post binaries, HTML, or MIME
clpmisc is a text only newsgroup. If you have images or binaries
that explain your question, put them in a publically accessible
place (like a Web server) and provide a pointer to that location. If
you include code, cut and paste it directly in the message body.
Don't attach anything to the message. Don't post vcards or HTML.
Many people (and even some Usenet servers) will automatically filter
out such messages. Many people will not be able to easily read your
post. Plain text is something everyone can read.
Social faux pas to avoid
The first two below are symptoms of lots of FAQ asking here in clpmisc.
It happens so often that folks will assume that it is happening yet
again. If you have looked but not found, or found but didn't understand
the docs, say so in your article.
Asking a Frequently Asked Question
It should be understood that you may have missed the applicable FAQ
when you checked, which is not a big deal. But if the Frequently
Asked Question is worded similar to your question, folks will assume
that you did not look at all. Don't become indignant at pointers to
the FAQ, particularly if it solves your problem.
Asking a question easily answered by a cursory doc search
If folks think you have not even tried the obvious step of reading
the docs applicable to your problem, they are likely to become
annoyed.
If you are flamed for not checking when you *did* check, then just
shrug it off (and take the answer that you got).
Asking for emailed answers
Emailed answers benefit one person. Posted answers benefit the
entire community. If folks can take the time to answer your
question, then you can take the time to go get the answer in the
same place where you asked the question.
It is OK to ask for a *copy* of the answer to be emailed, but many
will ignore such requests anyway. If you munge your address, you
should never expect (or ask) to get email in response to a Usenet
post.
Ask the question here, get the answer here (maybe).
Beware of saying "doesn't work"
This is a "red flag" phrase. If you find yourself writing that,
pause and see if you can't describe what is not working without
saying "doesn't work". That is, describe how it is not what you
want.
Sending a "stealth" Cc copy
A "stealth Cc" is when you both email and post a reply without
indicating *in the body* that you are doing so.
Be extra cautious when you get upset
Count to ten before composing a followup when you are upset
This is recommended in all Usenet newsgroups. Here in clpmisc, most
flaming sub-threads are not about any feature of Perl at all! They
are most often for what was seen as a breach of netiquette. If you
have lurked for a bit, then you will know what is expected and won't
make such posts in the first place.
But if you get upset, wait a while before writing your followup. I
recommend waiting at least 30 minutes.
Count to ten after composing and before posting when you are upset
After you have written your followup, wait *another* 30 minutes
before committing yourself by posting it. You cannot take it back
once it has been said.
AUTHOR
Tad McClellan and many others on the comp.lang.perl.misc newsgroup.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Tue, 29 Jan 2008 17:12:09 -0000
From: gbacon@hiwaay.net (Greg Bacon)
Subject: Re: regular expression negate a word (not character)
Message-Id: <13punj94ev46910@corp.supernews.com>
In article <fnlfr0.1fk.1@news.isolution.nl>,
Dr.Ruud <rvtol+news@isolution.nl> wrote:
: I negated the test, to make the regex simpler: [...]
Yes, your approach is simpler. I assumed from the "need it all
in one pattern" constraint that the OP is feeding the regular
expression to some other program that is looking for matches.
I dunno. Maybe it was the familiar compulsion with Perl to
attempt to cram everything into a single pattern.
Greg
--
What light is to the eyes -- what air is to the lungs -- what love is to
the heart, liberty is to the soul of man.
-- Robert Green Ingersoll
------------------------------
Date: Tue, 29 Jan 2008 13:50:15 -0500
From: monkeys paw <user@example.net>
Subject: scalar to array?
Message-Id: <MKadnS_EYNTD6ALanZ2dnUVZ_vyinZ2d@insightbb.com>
What is the easiest way to push a scalar variable containing text into
an array?
i.e.
$text = 'here is
a line
that has
four lines';
@lines = ???
the end result is:
@lines =('here is', 'a line', 'that has', 'four lines');
------------------------------
Date: 29 Jan 2008 18:58:15 GMT
From: xhoster@gmail.com
Subject: Re: scalar to array?
Message-Id: <20080129135817.741$bq@newsreader.com>
monkeys paw <user@example.net> wrote:
> What is the easiest way to push a scalar variable containing text into
> an array?
> i.e.
>
> $text = 'here is
> a line
> that has
> four lines';
>
> @lines = ???
>
> the end result is:
>
> @lines =('here is', 'a line', 'that has', 'four lines');
push @lines, split /\n/, $text;
Or if didn't really want to push by rather assign:
my @lines=split /\n/, $text;
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Tue, 29 Jan 2008 17:03:42 +0100
From: Michael Tosch <eedmit@NO.eed.SPAM.ericsson.PLS.se>
Subject: Re: uniq without sort <-------------- GURU NEEDED
Message-Id: <fnniou$6ji$1@deacx010.eed.ericsson.se>
Michele Dondi wrote:
> On Thu, 24 Jan 2008 18:45:24 -0800 (PST), gnuist006@gmail.com wrote:
>
>> I want uniq without sorting the initial order.
>>
>> The algorithm is this. For every line, look above if there is another
>> line like it. If so, then ignore it. If not, then output it. I am
>> sure, I can spend some time to write this in C. But what is the
>> solution using shell ? This way I can get an output that preserves the
>> order of first occurrence. It is needed in many problems.
>
> In shell I don't know. In Perl it's well known to be as trivial as
>
> perl -ne 'print unless $saw{$_}++' file
>
> (And it's not even the most golfed down solution!)
>
>
It can be transformed to standard awk like this:
awk 'saw[$0]++==0' file
This is "print first unique".
For "print last unique" you really need perl:
perl -ne '$s{$_}=++$i; END {print sort {$s{$a}<=>$s{$b}} keys %s}'
--
Michael Tosch @ hp : com
------------------------------
Date: Tue, 29 Jan 2008 03:08:11 -0800 (PST)
From: Jason Carlton <jwcarlton@gmail.com>
Subject: Using Imager module to resample images
Message-Id: <9cdfe3c1-f349-44ae-888f-61c1b2a0b63e@t1g2000pra.googlegroups.com>
I've been forcing my visitors to resample their images manually to
keep them below 50kb, but this has only had so-so results. A lot of my
visitors don't understand how to resample their image, so I'm getting
high-resolution images that are something like 20px x 20px, but still
take up 50kb!
So, I've been thinking about resampling the images on the fly. The
images would be restricted to JPG, JPEG, GIF, and PNG.
I was planning to use a combination of Image::Resize and Imager, which
I've never used before, but since the load on the server is ALWAYS
high, I had a few questions first:
1. Will the use of Imager take up a lot of CPU resources?
2. How do I recognize an animated GIF from a static GIF?
3. Does Imager compress JPG images automatically? I didn't see an
option to set a compression level in the docs, but it may be called
something else that I'm not recognizing.
4. I assume that I'll need to use Image::Resize to get the current
width and height, and if it exceeds the maximum that I input then I'll
use Imager to resample it. Is there a smarter (read: simpler and/or
less resource-heavy) option that this?
TIA,
Jason
------------------------------
Date: Tue, 29 Jan 2008 07:41:21 -0500
From: zentara <zentara@highstream.net>
Subject: Re: Using Imager module to resample images
Message-Id: <vv6up3521ho9pu3io1l4qvsk0nag72mgvg@4ax.com>
On Tue, 29 Jan 2008 03:08:11 -0800 (PST), Jason Carlton
<jwcarlton@gmail.com> wrote:
>I've been forcing my visitors to resample their images manually to
>keep them below 50kb, but this has only had so-so results. A lot of my
>visitors don't understand how to resample their image, so I'm getting
>high-resolution images that are something like 20px x 20px, but still
>take up 50kb!
>
>So, I've been thinking about resampling the images on the fly. The
>images would be restricted to JPG, JPEG, GIF, and PNG.
>
>I was planning to use a combination of Image::Resize and Imager, which
>I've never used before, but since the load on the server is ALWAYS
>high, I had a few questions first:
>
>1. Will the use of Imager take up a lot of CPU resources?
Never noticed an excessive cpu usage, but check it yourself.
>2. How do I recognize an animated GIF from a static GIF?
I believe it's safe to assume a static gif begins with GIF87, and
an animated with GIF89. But I'm not sure it's an absolute.
>3. Does Imager compress JPG images automatically? I didn't see an
>option to set a compression level in the docs, but it may be called
>something else that I'm not recognizing.
>
>4. I assume that I'll need to use Image::Resize to get the current
>width and height, and if it exceeds the maximum that I input then I'll
>use Imager to resample it. Is there a smarter (read: simpler and/or
>less resource-heavy) option that this?
Your best bet is to read
perldoc Imager::Files for the jpegquality parameter
perldoc Imager::Transformations for converting and scaling
perldoc Imager::ImageTypes
perldoc Imager will give an overview
Also http://groups.google.com will have many examples.
Search for things like:
"perl Imager resize", etc
zentara
>Jason
--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html
------------------------------
Date: 29 Jan 2008 14:45:42 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: Using Imager module to resample images
Message-Id: <slrnfpuf0m.lm4.abigail@alexandra.abigail.be>
_
zentara (zentara@highstream.net) wrote on VCCLXIV September MCMXCIII in
<URL:news:vv6up3521ho9pu3io1l4qvsk0nag72mgvg@4ax.com>:
@@ On Tue, 29 Jan 2008 03:08:11 -0800 (PST), Jason Carlton
@@ <jwcarlton@gmail.com> wrote:
@@
@@ >2. How do I recognize an animated GIF from a static GIF?
@@
@@ I believe it's safe to assume a static gif begins with GIF87, and
@@ an animated with GIF89. But I'm not sure it's an absolute.
While it is true that a GIF87a image is static, and that any animated
gif image is a GIF89a one, it does not mean that GIF89a forbids static
images. GIF89a is an enhancement of GIF87a. It allows animated images,
but it also allows interlaced images and other features. It doesn't
mandate one.
Abigail
--
perl -wle'print"Κυστ αξοτθες Πεςμ Θαγλες"^"\x80"x24'
------------------------------
Date: Tue, 29 Jan 2008 15:32:26 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Using Imager module to resample images
Message-Id: <Xns9A346B39C33F8asu1cornelledu@127.0.0.1>
zentara <zentara@highstream.net> wrote in
news:vv6up3521ho9pu3io1l4qvsk0nag72mgvg@4ax.com:
> On Tue, 29 Jan 2008 03:08:11 -0800 (PST), Jason Carlton
> <jwcarlton@gmail.com> wrote:
>
...
>>2. How do I recognize an animated GIF from a static GIF?
>
> I believe it's safe to assume a static gif begins with GIF87, and
> an animated with GIF89. But I'm not sure it's an absolute.
http://members.aol.com/royalef/gif89a.txt
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines: <URL:http://www.augustmail.com/~tadmc/clpmisc.shtml>
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 1240
***************************************
