[32386] in Perl-Users-Digest
Perl-Users Digest, Issue: 3653 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Mar 29 18:09:26 2012
Date: Thu, 29 Mar 2012 15:09:07 -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 Thu, 29 Mar 2012 Volume: 11 Number: 3653
Today's topics:
Re: How to speed up this slow part of my program <ben@morrow.me.uk>
Re: How to speed up this slow part of my program <thepoet_nospam@arcor.de>
Re: How to speed up this slow part of my program <rweikusat@mssgmbh.com>
Re: How to speed up this slow part of my program <rweikusat@mssgmbh.com>
Re: How to speed up this slow part of my program <glex_no-spam@qwest-spam-no.invalid>
Re: How to speed up this slow part of my program <rweikusat@mssgmbh.com>
Re: How to speed up this slow part of my program <ben@morrow.me.uk>
Re: How to speed up this slow part of my program <ben@morrow.me.uk>
Re: How to speed up this slow part of my program <rweikusat@mssgmbh.com>
Re: reason for local($_) ? <*@eli.users.panix.com>
Re: reason for local($_) ? <ben@morrow.me.uk>
Re: reason for local($_) ? (Randal L. Schwartz)
Re: reason for local($_) ? (Tim McDaniel)
Re: reason for local($_) ? (Tim McDaniel)
Re: reason for local($_) ? <hjp-usenet2@hjp.at>
Re: reason for local($_) ? <ben@morrow.me.uk>
Re: reason for local($_) ? <ben@morrow.me.uk>
Re: Why a different result? (Seymour J.)
Re: Why a different result? (Tim McDaniel)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 29 Mar 2012 00:05:29 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How to speed up this slow part of my program
Message-Id: <p2ic49-bp7.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Justin C <justin.1203@purestblue.com> writes:
>
> > my @matches = grep(/$item_code_part/, keys %{ $stock_items });
>
> An obvious suggestion would be to traverse the stock_items keys once
> an build a second hash which maps each item_code_part to an array
> reference containing all the corresponding stock_items keys (or even
> to a reference to the corresponding stock_items element) and use this
> second hash to locate the keys which need to be changed (or the hash
> locations which need to be changed) in constant time.
Given the problem as stated, I don't believe that's practical.
$item_code_part can match the stock_item anywhere along its length, so
you would need to enter each stock_item under all of its substrings.
That obviously turns into a combinatorial nightmare very fast.
If, of course, there is some further constraint we don't know about,
like 'the item code part is the section of the stock item up to the
third underscore', then the approach you suggest is the right one.
Ben
------------------------------
Date: Thu, 29 Mar 2012 07:27:15 +0200
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: How to speed up this slow part of my program
Message-Id: <4f73f2b3$0$7624$9b4e6d93@newsspool1.arcor-online.net>
Am 28.03.2012 17:24, schrieb Justin C:
> We have a database of thousands of clothing items. Some of the items are
> almost identical apart from their size. Consequently we use the same
> image in our web-shop to advertise items of the same style, design and
> colour.
>
> In a program I have to get new images from the art guy's computer I end
> up grepping the entire list of items $#(list-of-items) times, there must
> be a better way. The file names are exactly the same as the style codes
> apart from the size suffix being dropped. I'm using File::Find.
>
[...code snipped...]
>
> The 'find' iterates through two top level directories, 36 next level
> directories in each of the top level, and about 20k files accross the
> entire 72 level 2 directories. It then passes the filename to the sub
> which compares the filename (which is only a partial stock code because
> it may have several matches) with the hash of stock_items, pulling out
> matches. Those matches are then iterated over and the items with an
> available image get a hash element added and set to 1.
>
> I can probably do the grep and iteration over the matches with map{...},
> grep{...}, keys %{ $stock_items}; but I don't think that'll save much
> time, and I'm not certain how to do, I can see how to create a new hash,
> but I'm not sure if changing the hash while grep iterates through it is
> a good idea.
I've had similar problems in my day-to-day work (iterating over
thousands of files and building relationships with database contents)
and found the only truly efficient approach is to avoid repetitive
lookups. Save a timestamp of the last run of your script, then use the
built-in functionality of the filesystem (mtime) to only process new
and changed files instead of the whole list of files, and finally save
a modification timestamp with each stock item to do another iteration
over only those items added or changed since the last run. Those will
still have to look through the whole list of images, but the number of
iterations should be greatly reduced.
It should boil down to the following:
my %codeparts;
my $ts = get_last_run_time(); # read last run time from db
find(\&set_flag, (keys %{ $stock_groups->{text2code} }));
sub set_flag {
return unless (-f $_ );
(my $item_code_part = $_) =~ s/\.jpg//;
$item_code_part = uc($item_code_part);
$item_code_part =~ s|_|/|g;
$codeparts{$item_code_part} = 1;
return if( stat($_)[9] < $ts ); # only process new items
my @matches = grep(/$item_code_part/, keys %{ $stock_items });
foreach my $i (@matches) {
$stock_items->{$i}{got_image} = 1;
}
}
# do query for all new stock items
# select stockitem from stock where ts_added > $ts
while( $row = $sth->fetchrow_hashref() )
{
my $newitem = $row->{"itemno"};
if( grep { $newitem =~ /\Q$_\E/ } keys %codeparts )
{
$stock_items->{$newitem}{got_image} = 1;
}
}
-Chris
------------------------------
Date: Thu, 29 Mar 2012 13:29:10 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: How to speed up this slow part of my program
Message-Id: <878vij1tgp.fsf@sapphire.mobileactivedefense.com>
Christian Winter <thepoet_nospam@arcor.de> writes:
[...]
> I've had similar problems in my day-to-day work (iterating over
> thousands of files and building relationships with database contents)
> and found the only truly efficient approach is to avoid repetitive
> lookups.
The only 'truly efficient' way to solve such a problem is 'use a
suitable lookup algorithm'. Otherwise, you are always betting on
"runtime proportional to n*n won't matter because n will always be
small".
------------------------------
Date: Thu, 29 Mar 2012 13:49:00 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: How to speed up this slow part of my program
Message-Id: <874nt71sjn.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Justin C <justin.1203@purestblue.com> writes:
>>
>> > my @matches = grep(/$item_code_part/, keys %{ $stock_items });
>>
>> An obvious suggestion would be to traverse the stock_items keys once
>> an build a second hash which maps each item_code_part to an array
>> reference containing all the corresponding stock_items keys (or even
>> to a reference to the corresponding stock_items element) and use this
>> second hash to locate the keys which need to be changed (or the hash
>> locations which need to be changed) in constant time.
>
> Given the problem as stated, I don't believe that's practical.
> $item_code_part can match the stock_item anywhere along its length, so
> you would need to enter each stock_item under all of its substrings.
> That obviously turns into a combinatorial nightmare very fast.
>
> If, of course, there is some further constraint we don't know about,
> like 'the item code part is the section of the stock item up to the
> third underscore', then the approach you suggest is the right one.
Just that the posted code behaves in this way doesn't mean that this
behaviour is strictly necessary to solve the problem. If it was
otherwise, coding errors wouldn't exist. And in this particular case,
I would risk a bet on the assumption that the regular expression match
could be replaced with a comparison of the item_code_part and a
substring of each stock_items key whose start and length are the same
for each key and known in advance, IOW, that, given a stock_items key,
it's item_code_part can be calculated without knowing the set of all
item_code_parts presently corresponding to image files.
Indepedently of this, another sensible idea would be to turn the
'stock item key' into an attribute of a data structure, say, an array
reference, put these data structures into an array, traverse the array
to locate the first matching item, process that once it was found and
remove it from the array afterwards (or use a programming language
designed for people who don't want to be bothered with outlandish
distinctions like that, eg, PHP).
------------------------------
Date: Thu, 29 Mar 2012 10:04:29 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: How to speed up this slow part of my program
Message-Id: <4f7479fd$0$9080$815e3792@news.qwest.net>
On 03/28/12 10:24, Justin C wrote:
> We have a database of thousands of clothing items. Some of the items are
> almost identical apart from their size. Consequently we use the same
> image in our web-shop to advertise items of the same style, design and
> colour.
>[...]
> The bottle-neck, as I see it, is running grep 20k times, once for each
> image found. Can anyone suggest a better way?
Since you already have data in a DB, I'd suggest looking at
associating these files, to the items, in the database.
Maybe store the path to the file, or possibly the image as a BLOB, a
many to one relationship.
------------------------------
Date: Thu, 29 Mar 2012 16:35:13 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: How to speed up this slow part of my program
Message-Id: <87limje7ym.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> 3. Turn the giant regexp into a suitable kind of search tree:
> Unfortunately, the algorithm is still quadratic and doesn't
> scale, performance sucks.
This was an error on my part: The total running time should be
proportional to the number of stock_items times log(number of images)
and while this is proportional to the square of the logarithm, this is
not how these terms are commonly used and understood. But for 20k
images, the running time will still be proportional to the number of
stock items times 14, much larger than what can be achieved by
'throwing memory at the problem' aka 'using a hash table'.
------------------------------
Date: Thu, 29 Mar 2012 22:32:38 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How to speed up this slow part of my program
Message-Id: <m01f49-plp.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> >> Justin C <justin.1203@purestblue.com> writes:
> >>
> >> > my @matches = grep(/$item_code_part/, keys %{ $stock_items });
> >>
> >> An obvious suggestion would be to traverse the stock_items keys once
> >> an build a second hash which maps each item_code_part to an array
> >> reference containing all the corresponding stock_items keys (or even
> >> to a reference to the corresponding stock_items element) and use this
> >> second hash to locate the keys which need to be changed (or the hash
> >> locations which need to be changed) in constant time.
> >
> > Given the problem as stated, I don't believe that's practical.
> > $item_code_part can match the stock_item anywhere along its length, so
> > you would need to enter each stock_item under all of its substrings.
> > That obviously turns into a combinatorial nightmare very fast.
> >
> > If, of course, there is some further constraint we don't know about,
> > like 'the item code part is the section of the stock item up to the
> > third underscore', then the approach you suggest is the right one.
>
> Just that the posted code behaves in this way doesn't mean that this
> behaviour is strictly necessary to solve the problem.
True.
> And in this particular case,
> I would risk a bet on the assumption that the regular expression match
> could be replaced with a comparison of the item_code_part and a
> substring of each stock_items key whose start and length are the same
> for each key and known in advance, IOW, that, given a stock_items key,
> it's item_code_part can be calculated without knowing the set of all
> item_code_parts presently corresponding to image files.
(...or something similar, that will produce one or a few potential
item_codes per stock_item, rather than a huge number.)
You're right. I wasn't looking that far outside the problem as given,
but Justin probably should.
Ben
------------------------------
Date: Thu, 29 Mar 2012 22:36:12 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How to speed up this slow part of my program
Message-Id: <c71f49-plp.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>
> The algorithm is quadratic and doesn't scale, performance sucks.
The first part of that sentence does not imply the second: 'N is usually
small' and all that. When you're comparing heavily optimized C like the
regex engine with pretty much *any* logic in Perl, 'small' can end up
being quite large.
Ben
------------------------------
Date: Thu, 29 Mar 2012 23:03:58 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: How to speed up this slow part of my program
Message-Id: <87bonfdpyp.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>>
>> The algorithm is quadratic and doesn't scale, performance sucks.
>
> The first part of that sentence does not imply the second: 'N is usually
> small' and all that.
Assuming that the original problem was stated correctly, 'N' is not
small here. Further, when 'N' is 'small',
> When you're comparing heavily optimized C like the
> regex engine with pretty much *any* logic in Perl,
> 'small' can end up being quite large.
the overhead of 'pretty much any logic in Perl' shouldn't
matter. Also, last time I looked, hashes were a datatype built into
Perl.
------------------------------
Date: Thu, 29 Mar 2012 07:16:55 +0000 (UTC)
From: Eli the Bearded <*@eli.users.panix.com>
Subject: Re: reason for local($_) ?
Message-Id: <eli$1203290312@qz.little-neck.ny.us>
In comp.lang.perl.misc, Tim McDaniel <tmcd@panix.com> wrote:
> Um, I usually did that. As you know, $_ is a global variable that's
> used implicitly by a lot of operations. local()ing it in a sub makes
> absolutely sure that anything done in this sub or under it will not
> screw up the caller.
I find it a much better idea to just use an explicit variable
in such cases. In my mind, $_ belongs to the main program, and
might even be better off not used there.
local() is a performance hit, is how I learned it. CPUs might be
fast enough that I won't notice, but I only local out variables
I really need. $/ say, or perhaps $" or $, but usually I'd just
use a join().
Elijah
------
but $_ can be super handy for "perl -e" scripts
------------------------------
Date: Thu, 29 Mar 2012 09:41:22 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: reason for local($_) ?
Message-Id: <iqjd49-r8h.ln1@anubis.morrow.me.uk>
Quoth Eli the Bearded <*@eli.users.panix.com>:
> In comp.lang.perl.misc, Tim McDaniel <tmcd@panix.com> wrote:
> > Um, I usually did that. As you know, $_ is a global variable that's
> > used implicitly by a lot of operations. local()ing it in a sub makes
> > absolutely sure that anything done in this sub or under it will not
> > screw up the caller.
>
> I find it a much better idea to just use an explicit variable
> in such cases. In my mind, $_ belongs to the main program, and
> might even be better off not used there.
That seems bizarre, to me. To *my* mind, $_ belongs to some very small
block: a for or while (<>) loop a few lines long, or a map or grep
expression or block. These blocks might occur all over the place, but
they all set up their own (localised) values for $_, so they don't
affect each other.
I wouldn't ever use $_ as an ordinary variable, even in the main
program, except for oneliners with -n or -p.
Ben
------------------------------
Date: Thu, 29 Mar 2012 09:02:17 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
To: Ben Morrow <ben@morrow.me.uk>
Subject: Re: reason for local($_) ?
Message-Id: <86vcln8kfq.fsf@red.stonehenge.com>
>>>>> "Ben" == Ben Morrow <ben@morrow.me.uk> writes:
Ben> That seems bizarre, to me. To *my* mind, $_ belongs to some very small
Ben> block: a for or while (<>) loop a few lines long, or a map or grep
Ben> expression or block. These blocks might occur all over the place, but
Ben> they all set up their own (localised) values for $_, so they don't
Ben> affect each other.
The while *doesn't*. Maybe that's what bit you one day, so that you now
practice this "shake a voodoo stick" thing at it. In which case, you
can borrow my best practice on that and never use $_ for such loops:
while (my $line = <>) {
...
}
print "Just another Perl hacker,"; # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
------------------------------
Date: Thu, 29 Mar 2012 16:22:51 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: reason for local($_) ?
Message-Id: <jl228r$9ml$1@reader1.panix.com>
In article <iqjd49-r8h.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth Eli the Bearded <*@eli.users.panix.com>:
>> In comp.lang.perl.misc, Tim McDaniel <tmcd@panix.com> wrote:
>> > Um, I usually did that. As you know, $_ is a global variable
>> > that's used implicitly by a lot of operations. local()ing it in
>> > a sub makes absolutely sure that anything done in this sub or
>> > under it will not screw up the caller.
>>
>> I find it a much better idea to just use an explicit variable
>> in such cases. In my mind, $_ belongs to the main program, and
>> might even be better off not used there.
>
>That seems bizarre, to me.
To me as well. $_ was designed for repeated use as a temporary and to
be used in a number of string-processing functions. It's so
convenient, whether in a sub or elsewhere, to do
chomp;
s/\r+$//; # not sure this is needed in modern Perl
next if ! s/^\.\.\. //;
if (s/^Root // || s/^AltRoots\d+ //) {
push @roots, $_;
} elsif (my ($depot, $workspace) = s!^View\d+ (//depot/.*) (//.*)$!!) {
...
}
(That's code off the top of my head, a contrived example.) Of course
I could "my" a variable, but then I'd have to drop it in 6 different
places.
>To *my* mind, $_ belongs to some very small block: a for or while
>(<>) loop a few lines long, or a map or grep expression or
>block. These blocks might occur all over the place, but they all set
>up their own (localised) values for $_, so they don't affect each
>other.
Citations:
"man perlsyn" says that a foreach loop always localizes its control
variable,
Otherwise, the variable is implicitly local to the loop and
regains its former value upon exiting the loop. If the variable
was previously declared with "my", it uses that variable instead
of the global one, but it's still localized to the loop. This
implicit localisation occurs only in a "foreach" loop.
The foreach statement modifier is described well above that, with
"(with $_ aliased to each item in turn)." but no statement at that
point about localization.
The perlfunc docs for map and grep refer to "locally setting $_ to
each element", so I presume that means localizing in the same sense.
Testing shows that they are all indeed localized in the same way:
#! /usr/bin/perl
use strict;
use warnings;
my @names = (' in a loop: wilma', ' barney', ' bambam');
$_ = "\nfred\n";
print;
foreach (@names) { print }
print;
print foreach @names;
print;
map { print } @names;
print;
print grep { 1 } @names;
print;
exit 0;
produces
$ perl local/test/045.pl
fred
in a loop: wilma barney bambam
fred
in a loop: wilma barney bambam
fred
in a loop: wilma barney bambam
fred
in a loop: wilma barney bambam
fred
(That was in Perl 5.8.8, but that's not the sort of thing Perl tends
to change, for fear of breaking code.) (I've never before used
"print" with no arguments, implicitly printing $_. It feels weird.)
But "man perlop" says (in 5.8.8)
Ordinarily you must assign the returned value to a variable, but
there is one situation where an automatic assignment happens. If
and only if the input symbol is the only thing inside the
conditional of a "while" statement (even if disguised as a
"for(;;)" loop), the value is automatically assigned to the global
variable $_, destroying whatever was there previously. (This may
seem like an odd thing to you, but you'll use the construct in
almost every Perl script you write.) The $_ variable is not
implicitly localized. You'll have to put a "local $_;" before the
loop if you want that to happen.
(BTW: "while <>" as a statement modifier works the same way as "while
(<>)" as a loop. I wasn't sure.)
Are there other cases of setting $_ implicitly? I can't think of any.
The while(<>) is an illustration of a silent bug.
And I don't know that "local $_" should be slow, given that every map,
grep, and foreach() has to do it.
>I wouldn't ever use $_ as an ordinary variable, even in the main
>program, except for oneliners with -n or -p.
If nothing else, it's not a descriptive variable name.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 29 Mar 2012 16:31:19 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: reason for local($_) ?
Message-Id: <jl22on$9ml$2@reader1.panix.com>
In article <86vcln8kfq.fsf@red.stonehenge.com>,
Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>> "Ben" == Ben Morrow <ben@morrow.me.uk> writes:
>
>Ben> That seems bizarre, to me. To *my* mind, $_ belongs to some very small
>Ben> block: a for or while (<>) loop a few lines long, or a map or grep
>Ben> expression or block. These blocks might occur all over the place, but
>Ben> they all set up their own (localised) values for $_, so they don't
>Ben> affect each other.
>
>The while *doesn't*. Maybe that's what bit you one day, so that you
>now practice this "shake a voodoo stick" thing at it. In which case,
>you can borrow my best practice on that and never use $_ for such
>loops:
>
>while (my $line = <>) {
> ...
>}
$ perl -e 'while (my $line = <>) { print $line }'
hello
hello
world
world
about to enter a null line
about to enter a null line
Huh. Right. Newline counts as a character,
Huh. Right. Newline counts as a character,
so the boolean test will not exit the loop when it sees it.
so the boolean test will not exit the loop when it sees it.
It does look cleaner than while (defined(my $line = <>))
It does look cleaner than while (defined(my $line = <>))
^D
But "$line =~" left, right, and center isn't as convenient as implicit $_.
I don't have any mental model of where my() and local() can legally be
placed, so I have to test it:
#! /usr/bin/perl
use strict;
use warnings;
$_ = "fred\n";
while (local $_ = <>) { s/^/ /; print; }
print;
exit 0;
produces (with suitable input):
$ perl local/test/046.pl
hello
hello
world
world
^D
fred
So I guess I'll use
while (local $_ = <>)
Or, I suppose
while (my $_ = <>)
after every place I use Perl upgrades past 5.9.? or whatever it is that
first allowed "my $_".
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 29 Mar 2012 22:08:52 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: reason for local($_) ?
Message-Id: <slrnjn9gak.n0j.hjp-usenet2@hrunkner.hjp.at>
On 2012-03-29 16:02, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>> "Ben" == Ben Morrow <ben@morrow.me.uk> writes:
>Ben> That seems bizarre, to me. To *my* mind, $_ belongs to some very small
>Ben> block: a for or while (<>) loop a few lines long, or a map or grep
>Ben> expression or block. These blocks might occur all over the place, but
>Ben> they all set up their own (localised) values for $_, so they don't
>Ben> affect each other.
>
> The while *doesn't*. Maybe that's what bit you one day, so that you now
> practice this "shake a voodoo stick" thing at it.
Uhm. I don't think jaialai was talking about Ben's code.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Thu, 29 Mar 2012 22:43:08 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: reason for local($_) ?
Message-Id: <ck1f49-plp.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
>
> Or, I suppose
> while (my $_ = <>)
> after every place I use Perl upgrades past 5.9.? or whatever it is that
> first allowed "my $_".
Be a little careful with 'my $_'. It currently breaks things like
List::Util::first that call callbacks with a localised global $_.
Ben
------------------------------
Date: Thu, 29 Mar 2012 22:40:01 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: reason for local($_) ?
Message-Id: <he1f49-plp.ln1@anubis.morrow.me.uk>
Quoth merlyn@stonehenge.com (Randal L. Schwartz):
> >>>>> "Ben" == Ben Morrow <ben@morrow.me.uk> writes:
>
> Ben> That seems bizarre, to me. To *my* mind, $_ belongs to some very small
> Ben> block: a for or while (<>) loop a few lines long, or a map or grep
> Ben> expression or block. These blocks might occur all over the place, but
> Ben> they all set up their own (localised) values for $_, so they don't
> Ben> affect each other.
>
> The while *doesn't*.
Good point, which I had temporarily forgotten. I don't seem to use
while (<>) very often, perhaps because the body of the loop is usually
long enough that I would want to give it a proper variable anyway.
> Maybe that's what bit you one day, so that you now
> practice this "shake a voodoo stick" thing at it.
...I am not the OP.
Ben
------------------------------
Date: Wed, 28 Mar 2012 07:46:52 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Why a different result?
Message-Id: <4f72fa2c$3$fuzhry+tra$mr2ice@news.patriot.net>
In <jku13u$r0o$1@reader1.panix.com>, on 03/28/2012
at 03:38 AM, tmcd@panix.com (Tim McDaniel) said:
>But it is pointless at best. The only plausible use of ?: really is
>for evaluating the results of expressions *for use in a larger
>expression*.
Whats wrong with using ?: in an expression that is not part of a
larger expression, e.g.,
my $lhs = $foo ? $bar : $baz;
--
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: Thu, 29 Mar 2012 16:36:33 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Why a different result?
Message-Id: <jl232h$9ml$3@reader1.panix.com>
In article <4f72fa2c$3$fuzhry+tra$mr2ice@news.patriot.net>,
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>In <jku13u$r0o$1@reader1.panix.com>, on 03/28/2012
> at 03:38 AM, tmcd@panix.com (Tim McDaniel) said:
>
>>But it is pointless at best. The only plausible use of ?: really is
>>for evaluating the results of expressions *for use in a larger
>>expression*.
>
>Whats wrong with using ?: in an expression that is not part of a
>larger expression, e.g.,
>
>my $lhs = $foo ? $bar : $baz;
Since "=" is an operator (and += -= and all the rest), I count that as
being part of a larger expression.
In any event, I meant "the only really plausible use of ?: is where
the value is used, which means outside of void context" regardless of
whether there's an operator that expressly shows it explicitly.
For example,
foreach ($use_primary ? @primary : @secondary)
looks OK to me.
--
Tim McDaniel, tmcd@panix.com
------------------------------
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 3653
***************************************
