[32205] in Perl-Users-Digest
Perl-Users Digest, Issue: 3470 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Aug 10 16:09:29 2011
Date: Wed, 10 Aug 2011 13:09:10 -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 Wed, 10 Aug 2011 Volume: 11 Number: 3470
Today's topics:
Re: Generating an anonymous reference to an OO method <rweikusat@mssgmbh.com>
Re: Generating an anonymous reference to an OO method <uri@StemSystems.com>
Re: Generating an anonymous reference to an OO method <tzz@lifelogs.com>
Re: How to disregard the first match of a loop? sln@netherlands.com
Re: How to disregard the first match of a loop? <nospam-abuse@ilyaz.org>
Re: How to disregard the first match of a loop? <rweikusat@mssgmbh.com>
Re: How to disregard the first match of a loop? <bugbear@trim_papermule.co.uk_trim>
Re: How to disregard the first match of a loop? <rweikusat@mssgmbh.com>
Re: How to disregard the first match of a loop? <cwilbur@chromatico.net>
Re: How to disregard the first match of a loop? <rweikusat@mssgmbh.com>
Re: How to disregard the first match of a loop? <uri@StemSystems.com>
Re: How to disregard the first match of a loop? <rweikusat@mssgmbh.com>
Re: How to disregard the first match of a loop? <uri@StemSystems.com>
Program printing all possible combinations of TCP flags <rweikusat@mssgmbh.com>
Re: Spaces <source@netcom.com>
Warning scalar value @h{...} better written as $h{...} <NoSpamPleaseButThisIsValid3@gmx.net>
Re: Warning scalar value @h{...} better written as $h{. <rweikusat@mssgmbh.com>
Re: Warning scalar value @h{...} better written as $h{. <tadmc@seesig.invalid>
Re: Warning scalar value @h{...} better written as $h{. <rweikusat@mssgmbh.com>
Re: Which data serialization format? <tzz@lifelogs.com>
Re: Which data serialization format? <tzz@lifelogs.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 09 Aug 2011 12:16:55 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Generating an anonymous reference to an OO method
Message-Id: <87zkjiq1g8.fsf@sapphire.mobileactivedefense.com>
Michael Vilain <vilain@NOspamcop.net> writes:
> In article <87oc006luy.fsf@lifelogs.com>,
> Ted Zlatanov <tzz@lifelogs.com> wrote:
>
>> On Fri, 29 Jul 2011 18:34:01 +0100 Rainer Weikusat <rweikusat@mssgmbh.com>
>> wrote:
>>
>> RW> "Uri Guttman" <uri@StemSystems.com> writes:
>>
>> >> you have shown a massive unwillingness to learn from anyone here.
>>
>> RW> I have (and do) show 'a massive unwillingness' to accept anything from
>> RW> anyone without complete information (IOW not "I know something you
>> RW> don't know") and a sensible reason for it.
>>
>> The problem with that, Rainer, is that you are, strictly speaking,
>> a Vogon.
A fairly amusing observation about people I have made in the past is
that they tend to 'find' exaggerated versions of their own character
deficiencies in others. So, whenever you make an uninformed statement
about me (after all, you don't know me), you are actually making a
statement about yourself (someone you happen to know, possibly, the
only someone --- an amazing number of people also never seem to
realize that 'the others are actually different').
Try to consider that before posting more off-topic insults.
------------------------------
Date: Tue, 09 Aug 2011 07:46:08 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Generating an anonymous reference to an OO method
Message-Id: <87k4amst8f.fsf@quad.sysarch.com>
>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
RW> Try to consider that before posting more off-topic insults.
have you considered the fact (not an opinion) that you have pissed off a
majority of the regulars here in a very short time? this can't be caused
by any other reason than your obstinate narrow minded views. you came
here recently and have shown nothing but contempt for anyone who
disagrees with you who can't 'prove' their ideas are better than yours
to your 'high' standards. why don't you just leave already as you won't
learn here, you don't teach much and we are not worthy of your
presence. and don't bother to go to any perl conferences or workshops as
you will also be so bored at the myriad of ideas that don't match up
with your superior perl skills. as for proof of my idea here, i place
perl developers and grade them on many criteria one of which is how they
get along with others and their ideas. you fail there. of course you
won't accept that since it didn't come from you. but that is the whole
point. there is a world outside of you that actually knows a thing or
two and you might even learn something. but you won't. i predict you
will come back with a snarky comment about being insulted. this isn't an
insult but a factual description of your behavior here. name one new
friend you have made here. try that out. an actual new friend with whom you
communicate. i can name many.
and this is very on topic as perl is also a very large community and you
seem to want to keep outside it. fine with me but then stay all the way
out.
uri
--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------
------------------------------
Date: Tue, 09 Aug 2011 16:56:30 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Generating an anonymous reference to an OO method
Message-Id: <87aabip7u9.fsf@lifelogs.com>
On Tue, 09 Aug 2011 12:16:55 +0100 Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> Ted Zlatanov <tzz@lifelogs.com> wrote:
>> The problem with that, Rainer, is that you are, strictly speaking,
>> a Vogon.
RW> A fairly amusing observation about people I have made in the past is
RW> that they tend to 'find' exaggerated versions of their own character
RW> deficiencies in others.
Heh, you're a psychologist too? Truly a Renaissance soul.
RW> So, whenever you make an uninformed statement about me (after all,
RW> you don't know me), you are actually making a statement about
RW> yourself (someone you happen to know, possibly, the only someone ---
RW> an amazing number of people also never seem to realize that 'the
RW> others are actually different').
This is exactly the kind of conversation we should be having.
Ted
------------------------------
Date: Tue, 09 Aug 2011 08:15:57 -0700
From: sln@netherlands.com
Subject: Re: How to disregard the first match of a loop?
Message-Id: <phj247p0sg6kihqfk126imug8fse2j47p2@4ax.com>
On Mon, 8 Aug 2011 17:41:32 -0700 (PDT), Nene <rodbass63@gmail.com> wrote:
>Hi,
>I want to disregard the first match of the 'm/State : (\S+)/'
>which would be the string 'Availability' because the first match is
>meaningless, the other matches of Availability are important. So how I
>do disregard/omit the first capture of a loop?
>
[snip bad formatted code]
>__DATA__
>Ltm::Pool: TEST_POOL
>--------------------------------------
>Status
> Availability : available
> State : enabled
> Reason : The pool is available
> ^M
>Traffic ServerSide
> Bits In 4.1G
> Bits Out 0
> Packets In 4.8M
> Packets Out 0
> Current Connections 0
> Maximum Connections 153
> Total Connections 723.4K
>
>Ltm::Pool Member: TEST_POOL 10.10.10.10:7502
>-------------------------------------------------
>tatus
> Availability : available
> State : enabled
> Reason : Pool member is available
>
>Traffic ServerSide General
> Bits In 522.8M -
> Bits Out 0 -
> Packets In 614.2K -
> Packets Out 0 -
> Current Connections 0 -
> Maximum Connections 20 -
> Total Connections 90.9K -
> Total Requests - 0
>
>Ltm::Pool Member: TEST_POOL 10.10.10.10:7502
You have a lot of state stuff going on there.
Without modifying your sample too much, this is the way
I would do it:
use strict;
use warnings;
my ($pool_member, $state);
while ( my $line = <DATA> )
{
if ( $line =~ /Ltm::Pool( Member: \S+ (\S+)|)/ ) {
$state = 0;
if ($1) {
$pool_member = $2;
$state = 1;
}
next;
}
if ( $state && $line =~ /State : (\S+)/ ) {
print "$pool_member $1\n";
$state = 0;
}
}
------------------------------
Date: Wed, 10 Aug 2011 09:18:13 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: How to disregard the first match of a loop?
Message-Id: <slrnj44j6l.m2q.nospam-abuse@chorin.math.berkeley.edu>
09-08-2011, Nene <rodbass63@gmail.com> :
> Hi,
> I want to disregard the first match of the 'm/State : (\S+)/'
I use the following "idiom":
my $first_seen;
LOOP: (...) {
next unless $first_seen++;
DO_SOMETHING:
}
Hope this helps,
Ilya
------------------------------
Date: Wed, 10 Aug 2011 14:04:11 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: How to disregard the first match of a loop?
Message-Id: <87mxfhto38.fsf@sapphire.mobileactivedefense.com>
Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:
> 09-08-2011, Nene <rodbass63@gmail.com> :
>> Hi,
>> I want to disregard the first match of the 'm/State : (\S+)/'
>
> I use the following "idiom":
>
> my $first_seen;
> LOOP: (...) {
> next unless $first_seen++;
> DO_SOMETHING:
> }
An optimizing compiler would/ should kill this in the course of
'invariant code motion'. This is (AFAIK) something the Perl compiler
cannot do and therefore, the programmer should try to keep 'one-off'
statements of this type out of loops manually.
------------------------------
Date: Wed, 10 Aug 2011 14:33:01 +0100
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: How to disregard the first match of a loop?
Message-Id: <wqidndUoysoQFd_TnZ2dnUVZ8k-dnZ2d@brightview.co.uk>
Rainer Weikusat wrote:
> Ilya Zakharevich<nospam-abuse@ilyaz.org> writes:
>> 09-08-2011, Nene<rodbass63@gmail.com> :
>>> Hi,
>>> I want to disregard the first match of the 'm/State : (\S+)/'
>>
>> I use the following "idiom":
>>
>> my $first_seen;
>> LOOP: (...) {
>> next unless $first_seen++;
>> DO_SOMETHING:
>> }
>
> An optimizing compiler would/ should kill this in the course of
> 'invariant code motion'. This is (AFAIK) something the Perl compiler
> cannot do and therefore, the programmer should try to keep 'one-off'
> statements of this type out of loops manually.
Surely that only applies if you're up against performance issues?
"Programmers waste enormous amounts of time thinking
about, or worrying about, the speed
of noncritical parts of their programs..."
-- Knuth.
BugBear
------------------------------
Date: Wed, 10 Aug 2011 15:11:18 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: How to disregard the first match of a loop?
Message-Id: <87bovxtkzd.fsf@sapphire.mobileactivedefense.com>
bugbear <bugbear@trim_papermule.co.uk_trim> writes:
> Rainer Weikusat wrote:
>> Ilya Zakharevich<nospam-abuse@ilyaz.org> writes:
>>> 09-08-2011, Nene<rodbass63@gmail.com> :
>>>> Hi,
>>>> I want to disregard the first match of the 'm/State : (\S+)/'
>>>
>>> I use the following "idiom":
>>>
>>> my $first_seen;
>>> LOOP: (...) {
>>> next unless $first_seen++;
>>> DO_SOMETHING:
>>> }
>>
>> An optimizing compiler would/ should kill this in the course of
>> 'invariant code motion'. This is (AFAIK) something the Perl compiler
>> cannot do and therefore, the programmer should try to keep 'one-off'
>> statements of this type out of loops manually.
>
> Surely that only applies if you're up against performance issues?
>
> "Programmers waste enormous amounts of time thinking
> about, or worrying about, the speed
> of noncritical parts of their programs..."
>
> -- Knuth.
Provided you are writing mnemonic machine code aka 'assembly', what
Knuth's statement was referring to, I'd agree with that: There's no
use in trying to write 'an optimal machine code program' in every
little detail since there are way too much details in such a program
to ever get anything reasonably complex done when trying to do so
(or so, cf http://www.pbm.com/~lindahl/mel.html). But I assume that
this is only very rarely done nowadays and Perl isn't machine. It's a
fairly heavyweight 'very high-level language' with a compiler whose
'self-defense against mindless code churning' features are rather weak
and consequently, some intelligence is required to use it sensibly and
since there is so much which doesn't need to be done manually, thanks
to the 'very high level', that's usually not overly time consuming[*].
[*] In Germany, people whose main problem is "how do I get
this done at all" are called apprentices and treated and paid
as such, except if they have a degree in math and what they
are trying to do is 'programming' ...
------------------------------
Date: Wed, 10 Aug 2011 13:22:19 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: How to disregard the first match of a loop?
Message-Id: <8762m5i3lg.fsf@new.chromatico.net>
>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
RW> Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:
>> 09-08-2011, Nene <rodbass63@gmail.com> ÐÉÛÅÔ:
>>> Hi, I want to disregard the first match of the 'm/State :
>>> (\S+)/'
>>
>> I use the following "idiom":
>>
>> my $first_seen; LOOP: (...) { next unless $first_seen++;
>> DO_SOMETHING:
>> }
RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.
If an optimizing compiler changes the meaning of the code in the course
of its optimizations, it is a seriously flawed compiler.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Wed, 10 Aug 2011 19:39:04 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: How to disregard the first match of a loop?
Message-Id: <87aabhcdrr.fsf@sapphire.mobileactivedefense.com>
Charlton Wilbur <cwilbur@chromatico.net> writes:
>>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> RW> Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:
> >> 09-08-2011, Nene <rodbass63@gmail.com> :
> >>> Hi, I want to disregard the first match of the 'm/State :
> >>> (\S+)/'
> >>
> >> I use the following "idiom":
> >>
> >> my $first_seen; LOOP: (...) { next unless $first_seen++;
> >> DO_SOMETHING:
> >> }
>
> RW> An optimizing compiler would/ should kill this in the course of
> RW> 'invariant code motion'.
>
> If an optimizing compiler changes the meaning of the code in the course
> of its optimizations, it is a seriously flawed compiler.
The condition checked by the unless will be true when its encountered
first and will always remain false afterwards. Consequently, it can be
moved out of the loop without affecting the meaning of anything and
very likely, considering the problem this was supposed to apply to,
the $first_seen variable and the pointless per-iteration increment
could also be eliminated altogether.
------------------------------
Date: Wed, 10 Aug 2011 15:03:19 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: How to disregard the first match of a loop?
Message-Id: <87ty9p2io8.fsf@quad.sysarch.com>
>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
RW> Charlton Wilbur <cwilbur@chromatico.net> writes:
>>>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
RW> Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:
>> >> 09-08-2011, Nene <rodbass63@gmail.com> :
>> >>> Hi, I want to disregard the first match of the 'm/State :
>> >>> (\S+)/'
>> >>
>> >> I use the following "idiom":
>> >>
>> >> my $first_seen; LOOP: (...) { next unless $first_seen++;
>> >> DO_SOMETHING:
>> >> }
>>
RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.
>>
>> If an optimizing compiler changes the meaning of the code in the course
>> of its optimizations, it is a seriously flawed compiler.
RW> The condition checked by the unless will be true when its encountered
RW> first and will always remain false afterwards. Consequently, it can be
RW> moved out of the loop without affecting the meaning of anything and
RW> very likely, considering the problem this was supposed to apply to,
RW> the $first_seen variable and the pointless per-iteration increment
RW> could also be eliminated altogether.
again you are very wrong. any variable could be tied and therefore
have dynamic behavior that no compiler could predict. perl doesn't do
invariant code removal because it can't. and don't say something like
the code can be analyzed to make sure that isn't tied. other code could
tie it later on or even core perl funcs can be overridden to do
that. the work required to track all possiblities down would make the
compiler ridiculously large and slow.
did you really think after all these years that no one has EVER thought
about invariant code removal? it is a technique dating from the late
50's and p5p is well aware of it and has NEVER addressed it knowing it
can't be done in perl.
uri
--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------
------------------------------
Date: Wed, 10 Aug 2011 20:08:54 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: How to disregard the first match of a loop?
Message-Id: <871uwtcce1.fsf@sapphire.mobileactivedefense.com>
"Uri Guttman" <uri@StemSystems.com> writes:
>>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
> RW> Charlton Wilbur <cwilbur@chromatico.net> writes:
> >>>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> RW> Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:
> >> >> 09-08-2011, Nene <rodbass63@gmail.com> :
> >> >>> Hi, I want to disregard the first match of the 'm/State :
> >> >>> (\S+)/'
> >> >>
> >> >> I use the following "idiom":
> >> >>
> >> >> my $first_seen; LOOP: (...) { next unless $first_seen++;
> >> >> DO_SOMETHING:
> >> >> }
> >>
> RW> An optimizing compiler would/ should kill this in the course of
> RW> 'invariant code motion'.
> >>
> >> If an optimizing compiler changes the meaning of the code in the course
> >> of its optimizations, it is a seriously flawed compiler.
>
> RW> The condition checked by the unless will be true when its encountered
> RW> first and will always remain false afterwards. Consequently, it can be
> RW> moved out of the loop without affecting the meaning of anything and
> RW> very likely, considering the problem this was supposed to apply to,
> RW> the $first_seen variable and the pointless per-iteration increment
> RW> could also be eliminated altogether.
>
> again you are very wrong. any variable could be tied and therefore
> have dynamic behavior that no compiler could predict.
You are completely ignoring both the purpose of the example 'code
idiom' ("disregard the first match of a loop") and the 'idiom' code
which was actually posted (that declared $first_seen via my
immediately in front of the code block). After having thus changed the
topic of the thread completely, you 'conclude' that my statement
would be 'again very wrong'.
ROTFL.
------------------------------
Date: Wed, 10 Aug 2011 15:25:41 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: How to disregard the first match of a loop?
Message-Id: <87ty9p132i.fsf@quad.sysarch.com>
>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
RW> "Uri Guttman" <uri@StemSystems.com> writes:
RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.
>> again you are very wrong. any variable could be tied and therefore
>> have dynamic behavior that no compiler could predict.
RW> You are completely ignoring both the purpose of the example 'code
RW> idiom' ("disregard the first match of a loop") and the 'idiom' code
RW> which was actually posted (that declared $first_seen via my
RW> immediately in front of the code block). After having thus changed the
RW> topic of the thread completely, you 'conclude' that my statement
RW> would be 'again very wrong'.
you said an optimizing compiler would remove this. perl can't have
one. so what is your point of even bringing it up? that is your flaw
here.
again, you are not making any friends here. do you like doing this? why
are you even here if you don't care to be part of a community? do you
even get what community is?
uri
--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------
------------------------------
Date: Tue, 09 Aug 2011 16:08:17 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Program printing all possible combinations of TCP flags
Message-Id: <87obzypqqm.fsf@sapphire.mobileactivedefense.com>
Main function of this program is/was to generate a list of C string
literals used to populate an array which can be used to map the
numerical value of the flags field in a TCP header to a string
containing an uppercase letter (Fin, Syn, Rst, Psh, Ack, Urg) for each
set flag. Since it is kind-of cute an the algorithm is (IMHO) not
completely trivial/ obvious anymore, I thought I'd just post it here:
NB: This is fairly fast at the expense of possibly consuming huge
amounts of memory.
---------------
#!/usr/bin/perl
my @flags = qw(F S R P A U);
{
my @all;
push(@all, '');
for my $f (@flags) {
push(@all, map { $_.$f; } @all);
}
printf("\"%s\",\n", $_) for (@all);
}
---------------
------------------------------
Date: Tue, 09 Aug 2011 09:29:06 -0700
From: David Harmon <source@netcom.com>
Subject: Re: Spaces
Message-Id: <P_mdnRz9ffL5_dzTnZ2dnUVZ_t2dnZ2d@earthlink.com>
On Sun, 07 Aug 2011 21:38:41 -0500 in comp.lang.perl.misc, Tad
McClellan <tadmc@seesig.invalid> wrote,
>Kulin Remailer <remailer@reece.net.au> wrote:
>
>> How does perl treat spaces? Does it ignore them as in Fortran?
>
>
>The second paragraph of
>
> perldoc perlsyn
>
>answers your question:
>
> Perl is a free-form language, you can format and indent it however
> you like. Whitespace mostly serves to separate tokens, unlike
> languages like Python where it is an important part of the syntax.
And unlike Fortran, where white space is allowed and ignored even
inside of identifiers. Nobody has made that mistake since, although
Python's abuse of white space comes close.
------------------------------
Date: Wed, 10 Aug 2011 18:44:58 +0200
From: Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net>
Subject: Warning scalar value @h{...} better written as $h{...}
Message-Id: <4e42b58c$0$6567$9b4e6d93@newsspool3.arcor-online.net>
Hello all,
why does the following code produce a warning?
perl -wle'opendir $d, "/home";my %h;@h{readdir $d}=();print for keys %h'
Scalar value @h{readdir $d} better written as $h{readdir $d} at -e line 1.
Of course, one must not follow the advice because that would do
something different.
One can of course write
@h{@{[readdir $d]}}=();
to suppress the warning, but that looks a bit complicated.
Tested with v5.8.8 and v5.10.1.
Wolf
------------------------------
Date: Wed, 10 Aug 2011 18:02:07 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Warning scalar value @h{...} better written as $h{...}
Message-Id: <877h6ltd2o.fsf@sapphire.mobileactivedefense.com>
Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net> writes:
> perl -wle'opendir $d, "/home";my %h;@h{readdir $d}=();print for keys %h'
> Scalar value @h{readdir $d} better written as $h{readdir $d} at -e
> line 1.
My guess (I haven't checked the code) would be that it wrongly
considers 'readdir $d' to be a string which will be autoquoted when
used as a hash subscript and because of this, thinks you are using a
slice where accessing a single element would be sufficient.
[...]
> One can of course write
> @h{@{[readdir $d]}}=();
> to suppress the warning, but that looks a bit complicated.
Another workaround is to make 'readdir' look like a function call,
that is, use readdir($d), at least for 5.10.1.
------------------------------
Date: Wed, 10 Aug 2011 13:31:11 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Warning scalar value @h{...} better written as $h{...}
Message-Id: <slrnj45j4t.4md.tadmc@tadbox.sbcglobal.net>
Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net> wrote:
> Hello all,
>
> why does the following code produce a warning?
>
> perl -wle'opendir $d, "/home";my %h;@h{readdir $d}=();print for keys %h'
> Scalar value @h{readdir $d} better written as $h{readdir $d} at -e line 1.
>
> Of course, one must not follow the advice because that would do
> something different.
Help the parser by using parens around readdir's arg list:
perl -wle'opendir $d, "/home";my %h;@h{readdir($d)}=();print for keys %h'
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Wed, 10 Aug 2011 20:04:51 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Warning scalar value @h{...} better written as $h{...}
Message-Id: <8762m5ccks.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net> writes:
>> perl -wle'opendir $d, "/home";my %h;@h{readdir $d}=();print for keys %h'
>> Scalar value @h{readdir $d} better written as $h{readdir $d} at -e
>> line 1.
>
> My guess (I haven't checked the code) would be that it wrongly
> considers 'readdir $d' to be a string which will be autoquoted when
> used as a hash subscript
I just had a look at the code because I was curious and the following
check is used in order to determine if the operation inside the
slice-defining subscript cannot possibly yield more than one value:
if (*s == '[' || *s == '{') {
if (ckWARN(WARN_SYNTAX)) {
const char *t = s + 1;
while (*t && (isALNUM_lazy_if(t,UTF) || strchr(" \t$#+-'\"", *t)))
t++;
if (*t == '}' || *t == ']') {
t++;
PL_bufptr = PEEKSPACE(PL_bufptr); /* XXX can realloc */
Perl_warner(aTHX_ packWARN(WARN_SYNTAX),
"Scalar value %.*s better written as $%.*s",
(int)(t-PL_bufptr), PL_bufptr,
(int)(t-PL_bufptr-1), PL_bufptr+1);
}
}
}
This is, of course, just plain broken:
[rw@sapphire]~ $perl -we 'my @a; @a[1 + 1] = 2;'
Scalar value @a[1 + 1] better written as $a[1 + 1] at -e line 1.
[rw@sapphire]~ $perl -we 'my @a; @a[(1 + 1)] = 2;'
[rw@sapphire]~ $
------------------------------
Date: Tue, 09 Aug 2011 05:45:59 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Which data serialization format?
Message-Id: <87ipq6x3q0.fsf@lifelogs.com>
On Tue, 9 Aug 2011 09:24:21 +0200 Tobias Nissen <tn@movb.de> wrote:
TN> Ted Zlatanov wrote:
TN> [...]
>> Today, I would either use JSON-encoded binary data or I would find a
>> way to use Google Protocol Buffers through a C/C++ embedded library,
>> depending on the complexity of the work.
TN> Since the whole thing is going to do RPC I want something that does not
TN> process messages not conforming to some kind of schema. JSON::Schema
TN> does not seem to be in a "production grade" state.
I don't know what a schema will buy you, because I don't know your
specific needs. If you *really* need a schema, maybe you need a
database that will enforce it for you. But anyhow, my point was that
the Thrift Perl bindings are probably too slow.
TN> I want to use Moose throughout the code. Is there some RPC framework
TN> that it more suited for the use with Moose (and protobuf) than others?
Do not jump into Moose if you need speed, unless it's for managing just
the connections. Moose may be too slow to manage your data structures.
At least benchmark it before you commit to using it.
Ted
------------------------------
Date: Tue, 09 Aug 2011 06:04:28 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Which data serialization format?
Message-Id: <87ei0ux2v7.fsf@lifelogs.com>
Ted Zlatanov wrote:
>>> Today, I would either use JSON-encoded binary data or I would find a
>>> way to use Google Protocol Buffers through a C/C++ embedded library,
>>> depending on the complexity of the work.
Speaking of JSON-encoded binary, MessagePack may be decent according to
this blog entry:
http://www.igvita.com/2011/08/01/protocol-buffers-avro-thrift-messagepack/
He also mentions Avro, Thrift, and Protocol Buffers obviously, so these
four seem to be a fairly solid set of choices nowadays.
Ted
------------------------------
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 3470
***************************************
