[32652] in Perl-Users-Digest
Perl-Users Digest, Issue: 3928 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Apr 18 16:09:31 2013
Date: Thu, 18 Apr 2013 13:09:13 -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, 18 Apr 2013 Volume: 11 Number: 3928
Today's topics:
Re: clever fork <ben@morrow.me.uk>
Re: More idiomatic <derykus@gmail.com>
Re: More idiomatic <derykus@gmail.com>
Re: More idiomatic <derykus@gmail.com>
Re: More idiomatic <jurgenex@hotmail.com>
Re: More idiomatic <rvtol+usenet@xs4all.nl>
Re: More idiomatic <rweikusat@mssgmbh.com>
Re: More idiomatic <rweikusat@mssgmbh.com>
Re: More idiomatic <kst-u@mib.org>
Re: More idiomatic <source@netcom.com>
Re: More idiomatic <rweikusat@mssgmbh.com>
This looks like a Perl bug <noads.gravitalsun.adsno@adsno.hotmail.noads.com>
Re: This looks like a Perl bug <rvtol+usenet@xs4all.nl>
Re: This looks like a Perl bug <rweikusat@mssgmbh.com>
Re: This looks like a Perl bug <rweikusat@mssgmbh.com>
Re: This looks like a Perl bug <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: This looks like a Perl bug <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: This looks like a Perl bug <jurgenex@hotmail.com>
Re: This looks like a Perl bug <rweikusat@mssgmbh.com>
Re: This looks like a Perl bug <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: This looks like a Perl bug <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: This looks like a Perl bug <jurgenex@hotmail.com>
Re: This looks like a Perl bug <rweikusat@mssgmbh.com>
Re: This looks like a Perl bug <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 17 Apr 2013 23:35:13 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: clever fork
Message-Id: <1mk34a-rlq1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> "George Mpouras"
> <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
> writes:
> > I want to utilize all the cpu cores as much as possible.
> > What I am thinking is to "break" my sql queries to as many parts as
> > the number of cpu cores , and then fork every part.
> > Do you think it is going to work ;
>
> Probably. The more interesting question is "Does this make
> sense?". You could utilize more than one core for 'application
> computing' in this way, however 'SQL query' usually implies RDBMS
> which means that a lot of the 'computing' is done insided the
> database management system which is unaffected by forks done in an
> application
Assuming a query can genuinely be broken up into independant parts (that
is, that the RDBMS doesn't end up doing all the work for each part
anyway) and that the RDBMS doesn't use multiple cores on its own, it can
be worth doing. As you say, though, there's usually no need to fork to
do this: with most DBs you can open several DB connections from a single
thread and submit one query to each connection.
However, there are still important issues here: the most important is
that the separate sessions will necessarily use separate transactions,
so there may be data-integrity problems.
Ben
------------------------------
Date: Wed, 17 Apr 2013 23:02:51 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: More idiomatic
Message-Id: <d507e7ef-ec74-4476-a75c-cd8f7f5e7f0f@googlegroups.com>
On Wednesday, April 17, 2013 7:54:31 AM UTC-7, David Harmon wrote:
> On Wed, 17 Apr 2013 07:37:29 +0100 in comp.lang.perl.misc, Ben
>
> Morrow <ben@morrow.me.uk> wrote,
>
> >I think the strategy I might go for here would be to concatenate the
>
> >pieces to get a unique key, but not try to pull them out again
>
> >afterwards. Instead put the individual pieces in a structure,
>
>
>
> Yes, I think that is a good answer.
One possibility to avoid an artificial concatenation
character and then needing to break it down later:
my $key = "$fromline$useragent$hascont";
$statstab{$key} = [
(${$statstab{$key}}[0] //= $fromline),
(${$statstab{$key}}[1] //= $useragent),
(${$statstab{$key}}[2] //= $hascont),
do{${$statstab{$key}}[3] //= 0; ++${$statstab{$key}}[3]}
];
...
for (sort keys %statstab) {
($fromline,$useragent,$hascont) = @{$statstab{$_}}[0.2]
...
--
Charles DeRykus
------------------------------
Date: Wed, 17 Apr 2013 23:18:05 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: More idiomatic
Message-Id: <59219ecc-a0b4-49ad-a10e-bc7c8e96878e@googlegroups.com>
On Wednesday, April 17, 2013 11:02:51 PM UTC-7, C.DeRykus wrote:
> On Wednesday, April 17, 2013 7:54:31 AM UTC-7, David Harmon wrote:
>
> > On Wed, 17 Apr 2013 07:37:29 +0100 in comp.lang.perl.misc, Ben
>
> >
>
> > Morrow <ben@morrow.me.uk> wrote,
>
> >
>
> > >I think the strategy I might go for here would be to concatenate the
>
> >
>
> > >pieces to get a unique key, but not try to pull them out again
>
> >
>
> > >afterwards. Instead put the individual pieces in a structure,
>
> >
>
> >
>
> >
>
> > Yes, I think that is a good answer.
>
>
>
>
>
> One possibility to avoid an artificial concatenation
>
> character and then needing to break it down later:
>
>
>
>
>
> my $key = "$fromline$useragent$hascont";
>
> $statstab{$key} = [
>
> (${$statstab{$key}}[0] //= $fromline),
>
> (${$statstab{$key}}[1] //= $useragent),
>
> (${$statstab{$key}}[2] //= $hascont),
>
> do{${$statstab{$key}}[3] //= 0; ++${$statstab{$key}}[3]}
>
> ];
>
>
>
Untested... and I see quickly that this re-creates the
array each time which isn't terribly efficient, eg, if
the $statstab key already exists, you could just update
the count.
--
Charles DeRykus
------------------------------
Date: Thu, 18 Apr 2013 01:07:49 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: More idiomatic
Message-Id: <2eaad7c6-af86-4b1a-b51d-aba9894a4113@googlegroups.com>
On Wednesday, April 17, 2013 11:18:05 PM UTC-7, C.DeRykus wrote:
> On Wednesday, April 17, 2013 11:02:51 PM UTC-7, C.DeRykus wrote:
>
> > On Wednesday, April 17, 2013 7:54:31 AM UTC-7, David Harmon wrote:
>
> >
>
> > > On Wed, 17 Apr 2013 07:37:29 +0100 in comp.lang.perl.misc, Ben
>
> >
>
> > >
>
> >
>
> > > Morrow <ben@morrow.me.uk> wrote,
>
> >
>
> > >
>
> >
>
> > > >I think the strategy I might go for here would be to concatenate the
>
> >
>
> > >
>
> >
>
> > > >pieces to get a unique key, but not try to pull them out again
>
> >
>
> > >
>
> >
>
> > > >afterwards. Instead put the individual pieces in a structure,
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Yes, I think that is a good answer.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > One possibility to avoid an artificial concatenation
>
> >
>
> > character and then needing to break it down later:
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > my $key = "$fromline$useragent$hascont";
>
> >
>
> > $statstab{$key} = [
>
> >
>
> > (${$statstab{$key}}[0] //= $fromline),
>
> >
>
> > (${$statstab{$key}}[1] //= $useragent),
>
> >
>
> > (${$statstab{$key}}[2] //= $hascont),
>
> >
>
> > do{${$statstab{$key}}[3] //= 0; ++${$statstab{$key}}[3]}
>
> >
>
> > ];
>
> >
>
> >
>
> >
>
>
>
> Untested... and I see quickly that this re-creates the
>
> array each time which isn't terribly efficient, eg, if
>
> the $statstab key already exists, you could just update
>
> the count.
>
>
Better ... lightly tested:
...
my $key = "$fromline$useragent$hascont";
if ( exists $statstab{$key} ) {
${$statstab{$key}}[3]++;
} else {
$statstab{$key} = [$fromline, $useragent, $hascont,1];
}
...
--
Charles DeRykus
------------------------------
Date: Thu, 18 Apr 2013 06:31:44 -0700
From: Jrgen Exner <jurgenex@hotmail.com>
Subject: Re: More idiomatic
Message-Id: <g3tvm8li34lah3gchmtq1e6p62ufu86bm2@4ax.com>
"C.DeRykus" <derykus@gmail.com> wrote:
>On Wednesday, April 17, 2013 11:18:05 PM UTC-7, C.DeRykus wrote:
>> On Wednesday, April 17, 2013 11:02:51 PM UTC-7, C.DeRykus wrote:
>>
>> > On Wednesday, April 17, 2013 7:54:31 AM UTC-7, David Harmon wrote:
>>
>> >
>>
>> > > On Wed, 17 Apr 2013 07:37:29 +0100 in comp.lang.perl.misc, Ben
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > Morrow <ben@morrow.me.uk> wrote,
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > >I think the strategy I might go for here would be to concatenate the
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > >pieces to get a unique key, but not try to pull them out again
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > >afterwards. Instead put the individual pieces in a structure,
[...]
As if full-quotes aren't bad enough is there any sane reason why you are
doubling your quotes by inserting an additional empty line after each
and every quoted line? That is nuts!
And yet worse: attribute those added lines to the previous poster?
Would you stop doing that ASAP, please.
jue
------------------------------
Date: Thu, 18 Apr 2013 16:50:25 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: More idiomatic
Message-Id: <51700831$0$2313$e4fe514c@news2.news.xs4all.nl>
On 2013-04-18 10:07, C.DeRykus wrote:
> ${$statstab{$key}}[3]++;
Alternative:
++ $statstab{$key}[3];
--
Ruud
------------------------------
Date: Thu, 18 Apr 2013 16:41:22 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: More idiomatic
Message-Id: <87k3nzn8wt.fsf@sapphire.mobileactivedefense.com>
"C.DeRykus" <derykus@gmail.com> writes:
[...]
> Better ... lightly tested:
>
> ...
> my $key = "$fromline$useragent$hascont";
> if ( exists $statstab{$key} ) {
> ${$statstab{$key}}[3]++;
> } else {
> $statstab{$key} = [$fromline, $useragent, $hascont,1];
> }
This could be written as
$statstab{$key} //= [$fromline, $useragent, $hascont];
++$statstab{$key}[3];
(it could also use ||= for compatibility with older Perls since values
which end up as zero when interpreted as a number shouldn't exist in
this case). Also, declaring constants for accessing the subfields
would be a good idea, eg
use constant COUNT => 3;
.
.
.
$statstab{$key} //= [$fromline, $useragent, $hascont];
++$statstab{$key}[COUNT];
------------------------------
Date: Thu, 18 Apr 2013 18:07:07 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: More idiomatic
Message-Id: <87bo9bn4xw.fsf@sapphire.mobileactivedefense.com>
David Harmon <source@netcom.com> writes:
> On Wed, 17 Apr 2013 07:37:29 +0100 in comp.lang.perl.misc, Ben
> Morrow <ben@morrow.me.uk> wrote,
>>I think the strategy I might go for here would be to concatenate the
>>pieces to get a unique key, but not try to pull them out again
>>afterwards. Instead put the individual pieces in a structure,
>
> Yes, I think that is a good answer.
Perl also supports 'multidimensional hash keys'. An expression of the
form
$h{a,c,b}
is equivalent to using a hash key which is created automtically by
joining the components with the current value of $; as separator
(default is \034), => perlvar(1)
------------------------------
Date: Thu, 18 Apr 2013 10:28:33 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: More idiomatic
Message-Id: <lntxn3g33y.fsf@nuthaus.mib.org>
Jürgen Exner <jurgenex@hotmail.com> writes:
[...]
> As if full-quotes aren't bad enough is there any sane reason why you are
> doubling your quotes by inserting an additional empty line after each
> and every quoted line? That is nuts!
> And yet worse: attribute those added lines to the previous poster?
>
> Would you stop doing that ASAP, please.
Google Groups does that automatically. Yes, it's stupid.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Thu, 18 Apr 2013 10:54:23 -0700
From: David Harmon <source@netcom.com>
Subject: Re: More idiomatic
Message-Id: <-9GdnQSAvv3wru3MnZ2dnUVZ_smdnZ2d@earthlink.com>
On Wed, 17 Apr 2013 23:02:51 -0700 (PDT) in comp.lang.perl.misc,
"C.DeRykus" <derykus@gmail.com> wrote,
>One possibility to avoid an artificial concatenation
>character and then needing to break it down later:
>
>my $key = "$fromline$useragent$hascont";
>$statstab{$key} = [
> (${$statstab{$key}}[0] //= $fromline),
> (${$statstab{$key}}[1] //= $useragent),
> (${$statstab{$key}}[2] //= $hascont),
Sorry to disagree, but I much prefer Ben's hash with mnemonic keys
over this array with numeric indexes that I must track the meaning
of by additional effort.
------------------------------
Date: Thu, 18 Apr 2013 19:11:08 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: More idiomatic
Message-Id: <87sj2nlner.fsf@sapphire.mobileactivedefense.com>
David Harmon <source@netcom.com> writes:
> On Wed, 17 Apr 2013 23:02:51 -0700 (PDT) in comp.lang.perl.misc,
> "C.DeRykus" <derykus@gmail.com> wrote,
>>One possibility to avoid an artificial concatenation
>>character and then needing to break it down later:
>>
>>my $key = "$fromline$useragent$hascont";
>>$statstab{$key} = [
>> (${$statstab{$key}}[0] //= $fromline),
>> (${$statstab{$key}}[1] //= $useragent),
>> (${$statstab{$key}}[2] //= $hascont),
>
> Sorry to disagree, but I much prefer Ben's hash with mnemonic keys
> over this array with numeric indexes that I must track the meaning
> of by additional effort.
While this probably doesn't matter much for 'small amounts of code':
Using declared constants in order to access array slots by name has
the additional benefit that misspelling a slot name results in a
compile-time error instead of (when 'use warnings' is in effect) an
odd runtime warning which happens in some situations aggregated
together without rhyme or reason, most of which are perfectly normal
in Perl code, just not 'perfectly normal' in the minds of certain
people.
------------------------------
Date: Thu, 18 Apr 2013 18:33:12 +0300
From: "George Mpouras" <noads.gravitalsun.adsno@adsno.hotmail.noads.com>
Subject: This looks like a Perl bug
Message-Id: <kkp3no$1dsd$1@news.ntua.gr>
# it should print string, string but it prints string number
# there is no explanation for this behavior
weird('2') for 1..2;
sub weird {
my $num = $_[0] eq '' ? 0 : $_[0] ^ $_[0] ? 0 : 1;
my $col = $_[0] - 1;
print $num ? "number\n" : "string\n"
}
------------------------------
Date: Thu, 18 Apr 2013 17:58:31 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: This looks like a Perl bug
Message-Id: <51701827$0$2231$e4fe514c@news2.news.xs4all.nl>
On 2013-04-18 17:33, George Mpouras wrote:
> # it should print string, string but it prints string number
> # there is no explanation for this behavior
>
> weird('2') for 1..2;
>
> sub weird {
> my $num = $_[0] eq '' ? 0 : $_[0] ^ $_[0] ? 0 : 1;
> my $col = $_[0] - 1; print $num ? "number\n" : "string\n"
> }
Not a bug. The parameter '2' becomes numeric, because of the operations.
Just rewrite it to:
sub silly {
my ($p) = @_; # copy
my $num = ($p eq "") ? 0 : ($p ^ $p) ? 0 : 1;
my $col = $p - 1;
print $num ? "number\n" : "string\n";
}
But what are you trying to achieve?
--
Ruud
------------------------------
Date: Thu, 18 Apr 2013 17:25:31 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: This looks like a Perl bug
Message-Id: <87fvynn6v8.fsf@sapphire.mobileactivedefense.com>
"Dr.Ruud" <rvtol+usenet@xs4all.nl> writes:
> On 2013-04-18 17:33, George Mpouras wrote:
>> # it should print string, string but it prints string number
>> # there is no explanation for this behavior
>>
>> weird('2') for 1..2;
>>
>> sub weird {
>> my $num = $_[0] eq '' ? 0 : $_[0] ^ $_[0] ? 0 : 1;
>> my $col = $_[0] - 1; print $num ? "number\n" : "string\n"
>> }
>
> Not a bug. The parameter '2' becomes numeric, because of the
> operations.
This is not quite true. Same effect with somewhat less code:
------------
weird('2') for 1 .. 2;
sub weird {
my $num = $_[0] ^ $_[0] ? 0 : 1;
my $col = $_[0] - 1;
print $num ? "number\n" : "string\n"
}
------------
What happens here is that $_[0] ^ $_[0] returns a string whose value
is a single 0-byte during the first call. This is not a 'logical false
value', hence $num becomes 1. The $_[0] - 1 causes the scalar supplied
as first argument to weird to become IOK, that is, it acquires an IV
whose value is 2. The same scalar is used as argument to the second
weird call. Consequently, $_[0] ^ $_[0] becomes an integer operation
whose result is 0 which counts as false and $num becomes 1.
If this is not considered a bug, this kind of 'silent' runtime
modification of compile-time literals is at least very
counter-intuitive.
------------------------------
Date: Thu, 18 Apr 2013 18:16:39 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: This looks like a Perl bug
Message-Id: <87zjwvlpxk.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> my $num = $_[0] ^ $_[0] ? 0 : 1;
> my $col = $_[0] - 1;
> print $num ? "number\n" : "string\n"
> }
> ------------
>
> What happens here is that $_[0] ^ $_[0] returns a string whose value
> is a single 0-byte during the first call. This is not a 'logical false
> value', hence $num becomes 1.
s/becomes 1/becomes 0/
------------------------------
Date: Thu, 18 Apr 2013 21:08:14 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: This looks like a Perl bug
Message-Id: <kkpcqg$2qfs$1@news.ntua.gr>
the same peace of code is called with exact the same conditions and doing
different things
------------------------------
Date: Thu, 18 Apr 2013 21:11:13 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: This looks like a Perl bug
Message-Id: <kkpd03$2r7a$1@news.ntua.gr>
>> But what are you trying to achieve?
its a very big project , what you see here is a very small piece of code
that expose the strange behaviour .
we had a very big headache to find what was wrong and where .
------------------------------
Date: Thu, 18 Apr 2013 11:13:56 -0700
From: Jrgen Exner <jurgenex@hotmail.com>
Subject: Re: This looks like a Perl bug
Message-Id: <ond0n8dbja8uu4vsurdci38due33dfn425@4ax.com>
"George Mpouras"
<nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> wrote:
>the same peace of code
It would help if you would include what piece (I'm assuming you meant
piece and not peace) of code you are talking about.
>is called with exact the same conditions
It would help if you would state what those conditions are.
> and doing different things
It would help if you would state what those different things are.
Without those details your statement is about as useful as "This thingy
is made of that green whatever".
jue
------------------------------
Date: Thu, 18 Apr 2013 19:28:54 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: This looks like a Perl bug
Message-Id: <87obdblml5.fsf@sapphire.mobileactivedefense.com>
"George Mpouras"
<nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
writes:
> the same peace of code is called with exact the same conditions and
> doing different things
It is not called 'with the exact same conditions': The '2' ends
up as an anonymous scalar initialized to the value of the
string literal and the state of this anonymous scalar is changed by
the routine.
NB: I do not claim that this is not a bug, especially considering that
there's apparently some special-case code to prevent undefined values
from becoming defined as side effect of using them as numbers.
------------------------------
Date: Thu, 18 Apr 2013 21:41:47 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: This looks like a Perl bug
Message-Id: <kkpepd$1j5$1@news.ntua.gr>
>> It would help if you would state what those conditions are.
all you need to know is the piece of code I provide . nothing else .
------------------------------
Date: Thu, 18 Apr 2013 21:42:52 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: This looks like a Perl bug
Message-Id: <kkpere$20c$1@news.ntua.gr>
Ο "Rainer Weikusat" έγραψε στο μήνυμα
news:87obdblml5.fsf@sapphire.mobileactivedefense.com...
"George Mpouras"
<nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
writes:
> the same peace of code is called with exact the same conditions and
> doing different things
>> It is not called 'with the exact same conditions': The '2' ends
no you are not right. it is well defined subroutine with one argument.
------------------------------
Date: Thu, 18 Apr 2013 11:48:59 -0700
From: Jrgen Exner <jurgenex@hotmail.com>
Subject: Re: This looks like a Perl bug
Message-Id: <ctf0n859upinu6k7omh4ojjr7353rocdk3@4ax.com>
"George Mpouras"
<nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> wrote:
>
>>> It would help if you would state what those conditions are.
>
>all you need to know is the piece of code I provide . nothing else .
You must have forgotten to provide that piece of code?
<fullquote>
the same peace of code is called with exact the same conditions and
doing
different things
</fullquote>
jue
------------------------------
Date: Thu, 18 Apr 2013 19:50:02 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: This looks like a Perl bug
Message-Id: <87haj3lllx.fsf@sapphire.mobileactivedefense.com>
"George Mpouras"
<nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
writes:
> Ο "Rainer Weikusat" έγραψε στο μήνυμα
> "George Mpouras"
> <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
> writes:
>> the same peace of code is called with exact the same conditions and
>> doing different things
>
>>> It is not called 'with the exact same conditions': The '2' ends
>>> up as an anonymous scalar initialized to the value of the
>>> string literal and the state of this anonymous scalar is changed by
>>> the routine.
[Text restored]
> no you are not right. it is well defined subroutine with one
> argument.
---------
use Devel::Peek;
weird('2') for 1 .. 2;
sub weird {
Dump($_[0]);
my $num = $_[0] ^ $_[0] ? 0 : 1;
my $col = $_[0] - 1;
print $num ? "number\n" : "string\n";
Dump($_[0]);
}
---------
This prints
SV = PV(0x604308) at 0x621180
REFCNT = 1
FLAGS = (PADTMP,POK,READONLY,pPOK)
PV = 0x62a6b0 "2"\0
CUR = 1
LEN = 8
string
SV = PVIV(0x616a70) at 0x621180
REFCNT = 1
FLAGS = (PADTMP,IOK,POK,READONLY,pIOK,pPOK)
IV = 2
PV = 0x62a6b0 "2"\0
CUR = 1
LEN = 8
SV = PVIV(0x616a70) at 0x621180
REFCNT = 1
FLAGS = (PADTMP,IOK,POK,READONLY,pIOK,pPOK)
IV = 2
PV = 0x62a6b0 "2"\0
CUR = 1
LEN = 8
number
SV = PVIV(0x616a70) at 0x621180
REFCNT = 1
FLAGS = (PADTMP,IOK,POK,READONLY,pIOK,pPOK)
IV = 2
PV = 0x62a6b0 "2"\0
CUR = 1
LEN = 8
------------------------------
Date: Thu, 18 Apr 2013 21:55:04 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: This looks like a Perl bug
Message-Id: <kkpfia$592$1@news.ntua.gr>
>> You must have forgotten to provide that piece of code?
# one more time
weird('2') for 1..2;
sub weird {
my $num = $_[0] eq '' ? 0 : $_[0] ^ $_[0] ? 0 : 1;
my $col = $_[0] - 1;
print $num ? "number\n" : "string\n"
}
------------------------------
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 3928
***************************************
