How to disregard the first match of a loop?

[Nene]

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?

####

#!/usr/bin/perl -w
use strict;

while ( my $line = <DATA> ) {


if ($line =~ m/Ltm:ool Member: \S+ (\S+)/) {
$a = $1;
}
if ($line =~ m/State : (\S+)/) {
$b = $1;
print "$a $b\n";
}
}

__DATA__
Ltm:ool: 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:ool 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:ool Member: TEST_POOL 10.10.10.10:7502

 

[John W. Krahn]

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?

####

#!/usr/bin/perl -w
use strict;

while ( my $line =<DATA> ) {


if ($line =~ m/Ltm:ool Member: \S+ (\S+)/) {
$a = $1;
}
if ($line =~ m/State : (\S+)/) {
$b = $1;
print "$a $b\n";
}
}

#!/usr/bin/perl
use warnings;
use strict;

my $pool_member;
while ( my $line = <DATA> ) {

if ( $line =~ /Ltm:ool Member: \S+ (\S+)/ ) {
$pool_member = $1;
}
elsif ( defined $pool_member && $line =~ /State\s+:\s+(\S+)/) {
print "$pool_member $1\n";
}
}




John

 

[sln]

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:ool: 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:ool 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:ool 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:ool( 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;
}
}

 

[Ilya Zakharevich]

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

 

[Rainer Weikusat]

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.

 

[Rainer Weikusat]

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' ...

 

[Charlton Wilbur]

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

 

[Rainer Weikusat]

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.

 

[Uri Guttman]

RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.
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

 

[Rainer Weikusat]

RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.

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.

 

[Uri Guttman]

RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.

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

 

[Rainer Weikusat]

RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.


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.

Killing the context you have chosen to disregard in order to change
the meaning of my statement such that it doesn't make sense anymore
doesn't improve anything here: I wrote that a compiler which could do
invariant code motion would/ should move a part of the specific
statement in question, next unless $first_seen++, out of the loop
because, taking the purpose ('disregard the first match of a loop')
and context ('my $first_seen; while (... ) { next unless ...; }') of
it into account, doing so wouldn't change 'the meaning of the code',
only improve its execution speed. I also wrote that the lexical
variable and the per-iteration increment could very likely also be
killed because - again recurring to the purpose of the construction -
neither the variable nor its final value would likely be used by other
code executing after the loop.

perl can't have one.

I didn't claim that it could.

[...]

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?

I get that - to you - 'community' is what I shouldn't be allowed to
be part of.

 

[Charlton Wilbur]

RW> I wrote that a compiler which could do invariant code motion
RW> would/ should move a part of the specific statement in question,

No, actually, you wrote this:

RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.

Perhaps in your idiolect "move" and "kill" are synonymous.

Charlton

 

[Uri Guttman]

RW> I wrote that a compiler which could do invariant code motion
RW> would/ should move a part of the specific statement in question,

CW> No, actually, you wrote this:

RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.

CW> Perhaps in your idiolect "move" and "kill" are synonymous.

and regardless of move or kill, you can never do that with perl due to
possible dynamic behavior due to tie and overload and overriding of
builtins. no compiler can detect those before they happen.

but our dear rainer will win out in his mind as he always does. must be
nice to live in a castle in the clouds.

uri

 

[Ted Zlatanov]

RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'. This is (AFAIK) something the Perl compiler
RW> cannot do and therefore, the programmer should try to keep 'one-off'
RW> statements of this type out of loops manually.

$var++ is effectively a free operation in Perl, unless you're in a tight
loop, and even then it's very unlikely to matter.

The DO_SOMETHING and loop condition are likely to be much, much heavier
in terms of workload. For instance the m/State.../ call that's done on
every loop cycle will tie up the processor much more. So I would
optimize that piece first if optimization was warranted at all.

Ted

 

[Rainer Weikusat]

RW> I wrote that a compiler which could do invariant code motion
RW> would/ should move a part of the specific statement in question,

CW> No, actually, you wrote this:

RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.

CW> Perhaps in your idiolect "move" and "kill" are synonymous.

and regardless of move or kill, you can never do that with perl due to
possible dynamic behavior due to tie and overload and overriding of
builtins.

Neither 'tie' nor 'overload' nor 'overriding of builtins' were
applicable to this specific example.

but our dear rainer will win out in his mind as he always does.

To quote Snoopy: "Poor, sweet baby" ...

 

[Rainer Weikusat]

RW> I wrote that a compiler which could do invariant code motion
RW> would/ should move a part of the specific statement in question,

No, actually, you wrote this:

RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.

Perhaps in your idiolect "move" and "kill" are synonymous.

No, actually, I didn't put RW> in front of it.

 

[Uri Guttman]

RW> I wrote that a compiler which could do invariant code motion
RW> would/ should move a part of the specific statement in question,RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.
RW> Neither 'tie' nor 'overload' nor 'overriding of builtins' were
RW> applicable to this specific example.

and how do you know that? or how would an optimizing compiler know
that? your predictions of what code will do is amazing.

RW> To quote Snoopy: "Poor, sweet baby" ...

just as i PREDICTED. never listen, never will. are you ever wrong on
anything? a rhetorical question, that.

uri

 

[Rainer Weikusat]

RW> I wrote that a compiler which could do invariant code motion
RW> would/ should move a part of the specific statement in question,
RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.

RW> Neither 'tie' nor 'overload' nor 'overriding of builtins' were
RW> applicable to this specific example.

and how do you know that?

"Re: How to disregard the first match of a loop?"?

or how would an optimizing compiler know
that? your predictions of what code will do is amazing.


RW> To quote Snoopy: "Poor, sweet baby" ...

just as i PREDICTED. never listen, never will. are you ever wrong on
anything? a rhetorical question, that.

As I already wrote in the indirect reply to 'Ted 0.5" (safely resting
in my killfile until he either posts something sensible or kingdom
come, me expecting rather the latter than the former), I'm am not a bad
caricature of you. Consequently, I admit when I'm wrong.

 

[Ted Zlatanov]

RW> As I already wrote in the indirect reply to 'Ted 0.5" (safely resting
RW> in my killfile until he either posts something sensible or kingdom
RW> come, me expecting rather the latter than the former), I'm am not a bad
RW> caricature of you. Consequently, I admit when I'm wrong.

Heh heh, I'm honored to be killfiled parenthetically.

Ted