[32364] in Perl-Users-Digest
Perl-Users Digest, Issue: 3631 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Mar 5 06:09:30 2012
Date: Mon, 5 Mar 2012 03:09:06 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 5 Mar 2012 Volume: 11 Number: 3631
Today's topics:
Re: $var = do { ... }? <m@rtij.nl.invlalid>
Re: $var = do { ... }? <ben@morrow.me.uk>
Re: $var = do { ... }? <rweikusat@mssgmbh.com>
Re: $var = do { ... }? <rvtol+usenet@xs4all.nl>
Re: access to variable names inside subprocedure <kiuhnm03.4t.yahoo.it>
Re: Best way to search for a string which has N% in a c sln@netherlands.com
Re: given...when <rvtol+usenet@xs4all.nl>
little quiz <kiuhnm03.4t.yahoo.it>
Re: little quiz <ben@morrow.me.uk>
Re: little quiz <kiuhnm03.4t.yahoo.it>
Re: little quiz <rweikusat@mssgmbh.com>
Re: little quiz <m@rtij.nl.invlalid>
Re: little quiz <kiuhnm03.4t.yahoo.it>
Re: little quiz <sreservoir@gmail.com>
Re: little quiz <kiuhnm03.4t.yahoo.it>
Re: little quiz <ben@morrow.me.uk>
Re: little quiz <kiuhnm03.4t.yahoo.it>
Re: sorting unicode file under windows command line ehabaziz2001@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 3 Mar 2012 23:58:02 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: $var = do { ... }?
Message-Id: <q8ka29-733.ln1@news.rtij.nl>
On Sat, 03 Mar 2012 17:11:56 +0000, Rainer Weikusat wrote:
> Testing $@ is 'always correct' while the return value of eval might be
> 'false' for any number of reasons because it is just the return value of
> the last thing executed in the scope of the eval.
I think I get your point. You *have* to make sure all exception handlers
are correct (not a biggy) because otherwise you risk screwing up your
evals. Right?
M4
------------------------------
Date: Sun, 4 Mar 2012 00:29:20 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: $var = do { ... }?
Message-Id: <0kpa29-lke2.ln1@anubis.morrow.me.uk>
Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
> On Sat, 03 Mar 2012 17:11:56 +0000, Rainer Weikusat wrote:
>
> > Testing $@ is 'always correct' while the return value of eval might be
> > 'false' for any number of reasons because it is just the return value of
> > the last thing executed in the scope of the eval.
Which is why you should use Try::Tiny, which fixes this for you.
> I think I get your point. You *have* to make sure all exception handlers
> are correct (not a biggy) because otherwise you risk screwing up your
> evals. Right?
Localising $@ in DESTROY would not be sufficient, even if you could rely
on all destructors in all code you use doing so. See the BACKGROUND
section of Try::Tiny's documentation.
Ben
------------------------------
Date: Sun, 04 Mar 2012 14:44:40 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: $var = do { ... }?
Message-Id: <87eht81l47.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
>> On Sat, 03 Mar 2012 17:11:56 +0000, Rainer Weikusat wrote:
>>
>> > Testing $@ is 'always correct' while the return value of eval might be
>> > 'false' for any number of reasons because it is just the return value of
>> > the last thing executed in the scope of the eval.
>
> Which is why you should use Try::Tiny, which fixes this for you.
You mean it screws up the return value of an eval?
>> I think I get your point. You *have* to make sure all exception handlers
>> are correct (not a biggy) because otherwise you risk screwing up your
>> evals. Right?
>
> Localising $@ in DESTROY would not be sufficient, even if you could rely
> on all destructors in all code you use doing so.
It is never possible to rely on the fact that some code isn't
buggy. The solution is to fix the bugs AND NOT to download more
(presumably buggy) code which tries to work around them.
> See the BACKGROUND section of Try::Tiny's documentation.
Hic Rhodos, hic salta: What are you precisely referring to? I read
this background section and wrote about the two things I found in
there which were not just handwaiving. So, what did I miss and/or get
wrong? According to your opinion, not according to a random text some
random guy uploaded to a random web server in 2009(!), presumably more
than fifteen years after people started to use exception handling in
Perl despite you claim that's impossible without the 2009 guy.
------------------------------
Date: Mon, 05 Mar 2012 11:35:36 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: $var = do { ... }?
Message-Id: <4f5496f8$0$6965$e4fe514c@news2.news.xs4all.nl>
On 2012-03-02 21:10, Ben Morrow wrote:
> If you insist on doing the eval yourself, you should test the truth of
> the eval
>
> eval {
> ...
> } or do {
> ...
> };
>
> rather than relying on $@, since there are cases (destructors, for one,
> depending on your version of perl) where $@ can be cleared even though
> the eval failed. You still lose the error, but at least you know there
> was one.
Indeed, testing $@ is a bad practice.
Your code snippet is missing some important features, see:
my $ok;
eval {
$ok = foo();
1; # success
}
or do { # exception
my $eval_error = $@ || 'zombie error';
...;
};
--
Ruud
------------------------------
Date: Mon, 05 Mar 2012 11:54:20 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: access to variable names inside subprocedure
Message-Id: <4f549b5c$0$1378$4fafbaef@reader2.news.tin.it>
On 3/2/2012 16:23, ccc31807 wrote:
> On Mar 1, 3:38 pm, Ben Morrow<b...@morrow.me.uk> wrote:
>> but I can't see something like those first three lines without wanting
>> to turn it into a loop.
>
> In my current state of just-above-minimal competence, I try to
> abstract the logic. I bought a copy of 'Higher Order Perl' a number of
> years ago, and quite frankly found it beyond me at that time. After
> having studied through about eight Lisp books, it makes more sense,
> but it's still hard work.
Another thing: try Haskell instead. It's much less lispy.
Kiuhnm
------------------------------
Date: Sat, 03 Mar 2012 12:19:31 -0800
From: sln@netherlands.com
Subject: Re: Best way to search for a string which has N% in a character class?
Message-Id: <nvt4l7h6enciq9tssc9mhp4k11a39s5qi3@4ax.com>
On Fri, 2 Mar 2012 12:53:18 -0800 (PST), Peng Yu <pengyu.ut@gmail.com> wrote:
>On Mar 2, 12:07 pm, "J. Gleixner" <glex_no-s...@qwest-spam-no.invalid>
>wrote:
>> On 03/02/12 10:29, Peng Yu wrote:
[snip]
>> Using 'tr' and 'length' would probably help you.
>>
[snip]
>>
>> Divide one by the other, multiply by 100 and you have the percent.
>
>I don't think that you understand my question.
>
>Suppose that I have a string $str which the concatenation of $str1,
>$str2 and $str3, where both $str1 and $str3 have less than 50% of [A-
>D] and $str2 have more than 50% of [A-D].
>
>I need to discovered from $str where $str2 starts and ends. I don't
>see how tr and length alone can address this question.
%50 of what? Without boundry conditions, the type of regex solution
your thinking of is impossible.
The way you state your problem is that [A-D] can exist randomly
in sequence or between [^A-D] characters.
The the only thing you state as known is the total length of random
length strings after cattenation and before the %50 over/under content
of each.
You can slide a regex frame over the final string but ther is not enough
information about boundry conditions to get real information.
There is just more unknowns than there are equations.
For instance,
- if the length of each substring were the same it could be
solved, but this way would not need a regex.
- if the [A-D] were adjacent, still the start/end could not be
determined, only the knowledge that this match of > %50 is in
the substring that needs to be found, but still no begin/end information
about it.
I think it was a nice try though, futile, but nice.
-sln
------------------------------
Date: Mon, 05 Mar 2012 12:01:20 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: given...when
Message-Id: <4f549d00$0$6901$e4fe514c@news2.news.xs4all.nl>
On 2012-02-27 13:13, Kiuhnm wrote:
> I've been experimenting a little with given...when
I've been avoiding given/when like the plague.
--
Ruud
------------------------------
Date: Sun, 04 Mar 2012 13:19:29 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: little quiz
Message-Id: <4f535dd0$0$1392$4fafbaef@reader1.news.tin.it>
Look at this code which prints the first ten positive integers:
--->
#!/usr/bin/perl
use 5.010;
sub f1
{
state $v;
++$v;
say $v;
}
f1 for (1..10);
<---
Can you rewrite f1 without using 'state'?
You may only modify f1 and you may not use external code etc...:
--->
#!/usr/bin/perl
use 5.010;
sub f1
{
# write only here...
}
f1 for (1..10);
<---
Kiuhnm
------------------------------
Date: Sun, 4 Mar 2012 15:15:59 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: little quiz
Message-Id: <fidc29-bm03.ln1@anubis.morrow.me.uk>
Quoth Kiuhnm <kiuhnm03.4t.yahoo.it>:
> Look at this code which prints the first ten positive integers:
>
> --->
> #!/usr/bin/perl
>
> use 5.010;
>
> sub f1
> {
> state $v;
> ++$v;
> say $v;
> }
>
> f1 for (1..10);
> <---
>
> Can you rewrite f1 without using 'state'?
> You may only modify f1 and you may not use external code etc...:
TIMTOWTDI:
sub f1 {
++$v;
say $v;
}
(did you mean to forbid this?)
sub f1 {
my $v if 0;
++$v;
say $v;
}
(the warning only became mandatory under 5.12, you only required 5.10;
this was the semi-official way of doing 'state' before 5.10)
sub f1 {
my $v;
*f1 = sub {
++$v;
say $v;
};
f1();
}
(though this is just the same as the first example, really: I'm still
storing the state in the stash, just a bit more obscurely)
sub f1 {
BEGIN {
my $v;
sub f2 {
++$v;
say $v;
}
}
f2();
}
(this is nearly clean, though the BEGIN block isn't really part of f1)
sub f1 {
my $v;
sub f2 {
++$v;
say $v;
}
f2();
}
(and in fact you can skip the BEGIN, since you didn't use warnings)
sub f1 {
open X, "<", \"\n";
<X>;
say $.;
}
sub f1 {
"1 2 3 4 5 6 7 8 9 10 " =~ /(\d+) /g;
say $1;
}
Ben
------------------------------
Date: Sun, 04 Mar 2012 18:48:06 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: little quiz
Message-Id: <4f53aad5$0$1388$4fafbaef@reader1.news.tin.it>
On 3/4/2012 16:15, Ben Morrow wrote:
> Quoth Kiuhnm<kiuhnm03.4t.yahoo.it>:
>> Look at this code which prints the first ten positive integers:
>>
>> --->
>> #!/usr/bin/perl
>>
>> use 5.010;
>>
>> sub f1
>> {
>> state $v;
>> ++$v;
>> say $v;
>> }
>>
>> f1 for (1..10);
>> <---
>>
>> Can you rewrite f1 without using 'state'?
>> You may only modify f1 and you may not use external code etc...:
>
> TIMTOWTDI:
>
> sub f1 {
> ++$v;
> say $v;
> }
>
> (did you mean to forbid this?)
Yep.
> sub f1 {
> my $v if 0;
> ++$v;
> say $v;
> }
>
> (the warning only became mandatory under 5.12, you only required 5.10;
> this was the semi-official way of doing 'state' before 5.10)
That's new to me.
Same thing without the warning:
sub f1 {
my $v if my $y;
++$v;
say $v;
}
I didn't even know that
my $v = 7;
my $v = 0;
was possible.
I didn't know that "my" was an operator.
> sub f1 {
> my $v;
> *f1 = sub {
> ++$v;
> say $v;
> };
> f1();
> }
>
> (though this is just the same as the first example, really: I'm still
> storing the state in the stash, just a bit more obscurely)
>
> sub f1 {
> BEGIN {
> my $v;
> sub f2 {
> ++$v;
> say $v;
> }
> }
> f2();
> }
>
> (this is nearly clean, though the BEGIN block isn't really part of f1)
>
> sub f1 {
> my $v;
> sub f2 {
> ++$v;
> say $v;
> }
> f2();
> }
That's my solution! I was surprised when I saw that named sub
definitions are evaluated just once.
BTW, I don't like that f2 is visible from outside of f1.
> (and in fact you can skip the BEGIN, since you didn't use warnings)
>
> sub f1 {
> open X, "<", \"\n";
> <X>;
> say $.;
> }
Clever, but then why not
sub f1 {
say 1+$.++;
}
> sub f1 {
> "1 2 3 4 5 6 7 8 9 10 " =~ /(\d+) /g;
> say $1;
> }
I didn't know I could use =~ with the /g option in scalar context:
while ("1 2 3 4 5 6 7 8 9 10 " =~ /(\d+) /g) {
say $1;
}
Is it an idiom or a little trick?
Kiuhnm
------------------------------
Date: Sun, 04 Mar 2012 19:00:28 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: little quiz
Message-Id: <87y5rgry2b.fsf@sapphire.mobileactivedefense.com>
Kiuhnm <kiuhnm03.4t.yahoo.it> writes:
> Look at this code which prints the first ten positive integers:
>
> --->
> #!/usr/bin/perl
>
> use 5.010;
>
> sub f1
> {
> state $v;
> ++$v;
> say $v;
> }
>
> f1 for (1..10);
> <---
>
> Can you rewrite f1 without using 'state'?
> You may only modify f1 and you may not use external code etc...:
>
> --->
> #!/usr/bin/perl
>
> use 5.010;
>
> sub f1
> {
> # write only here...
> }
>
> f1 for (1..10);
> <---
sub f1 {
print("$_\n");
}
------------------------------
Date: Sun, 4 Mar 2012 20:23:20 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: little quiz
Message-Id: <82sc29-ndb.ln1@news.rtij.nl>
On Sun, 04 Mar 2012 13:19:29 +0100, Kiuhnm wrote:
> Look at this code which prints the first ten positive integers:
>
> --->
> #!/usr/bin/perl
>
> use 5.010;
>
> sub f1
> {
> state $v;
> ++$v;
> say $v;
> }
>
> f1 for (1..10);
> <---
>
> Can you rewrite f1 without using 'state'? You may only modify f1 and you
> may not use external code etc...:
>
#!/usr/bin/perl
use 5.010;
sub f1
{
say $_;
}
f1 for (1..10);
M4
------------------------------
Date: Sun, 04 Mar 2012 23:21:03 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: little quiz
Message-Id: <4f53eacd$0$1390$4fafbaef@reader2.news.tin.it>
On 3/4/2012 20:23, Martijn Lievaart wrote:
> On Sun, 04 Mar 2012 13:19:29 +0100, Kiuhnm wrote:
>
>> Look at this code which prints the first ten positive integers:
>>
>> --->
>> #!/usr/bin/perl
>>
>> use 5.010;
>>
>> sub f1
>> {
>> state $v;
>> ++$v;
>> say $v;
>> }
>>
>> f1 for (1..10);
>> <---
>>
>> Can you rewrite f1 without using 'state'? You may only modify f1 and you
>> may not use external code etc...:
>>
>
> #!/usr/bin/perl
>
> use 5.010;
>
> sub f1
> {
> say $_;
> }
>
> f1 for (1..10);
>
> M4
I should have written "[...]external code, external variables, etc...",
where "external" means not declared inside f1.
Kiuhnm
------------------------------
Date: Sun, 04 Mar 2012 18:00:49 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: little quiz
Message-Id: <jj0s6u$60e$1@dont-email.me>
On 03/04/2012 05:21 PM, Kiuhnm wrote:
> On 3/4/2012 20:23, Martijn Lievaart wrote:
>> On Sun, 04 Mar 2012 13:19:29 +0100, Kiuhnm wrote:
>>
>>> Look at this code which prints the first ten positive integers:
>>>
>>> --->
>>> #!/usr/bin/perl
>>>
>>> use 5.010;
>>>
>>> sub f1
>>> {
>>> state $v;
>>> ++$v;
>>> say $v;
>>> }
>>>
>>> f1 for (1..10);
>>> <---
>>>
>>> Can you rewrite f1 without using 'state'? You may only modify f1 and you
>>> may not use external code etc...:
>>>
>>
>> #!/usr/bin/perl
>>
>> use 5.010;
>>
>> sub f1
>> {
>> say $_;
>> }
>>
>> f1 for (1..10);
>>
>> M4
>
> I should have written "[...]external code, external variables, etc...",
> where "external" means not declared inside f1.
oh, declared?
sub f1
{
say our $_;
}
------------------------------
Date: Mon, 05 Mar 2012 00:15:49 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: little quiz
Message-Id: <4f53f7a4$0$1380$4fafbaef@reader2.news.tin.it>
On 3/5/2012 0:00, sreservoir wrote:
> On 03/04/2012 05:21 PM, Kiuhnm wrote:
[...]
>> I should have written "[...]external code, external variables, etc...",
>> where "external" means not declared inside f1.
>
> oh, declared?
>
> sub f1
> {
> say our $_;
> }
Ops... I meant declared outside f1!
Kiuhnm
------------------------------
Date: Sun, 4 Mar 2012 23:39:09 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: little quiz
Message-Id: <t1bd29-n75.ln1@anubis.morrow.me.uk>
Quoth Kiuhnm <kiuhnm03.4t.yahoo.it>:
> On 3/4/2012 16:15, Ben Morrow wrote:
>
> > sub f1 {
> > my $v if 0;
> > ++$v;
> > say $v;
> > }
> >
> > (the warning only became mandatory under 5.12, you only required 5.10;
> > this was the semi-official way of doing 'state' before 5.10)
>
> That's new to me.
It was always accidental that this worked at all: it's to do with the
details of when the compile-time and run-time parts of 'my' happen, and
which conditionals get constant-folded at compile time. It is
sufficiently useful that it was promoted to a proper supported feature
with 'state'.
> Same thing without the warning:
>
> sub f1 {
> my $v if my $y;
> ++$v;
> say $v;
> }
I think the lack of warning is not intentional: that is, I think any
change to core perl which caused my example to stop working would do the
same to yours, it's just not so visible at compile time that that is the
case.
>
> I didn't even know that
> my $v = 7;
> my $v = 0;
> was possible.
Those are separate variables which happen to have the same names. It's
exactly the same situation as
my $v = 7;
{
my $v = 0;
}
except the scope of the second $v extends all the way to the end of the
scope of the first.
> I didn't know that "my" was an operator.
I'm not sure what you mean by that... it has a runtime effect,
certainly.
> > sub f1 {
> > my $v;
> > sub f2 {
> > ++$v;
> > say $v;
> > }
> > f2();
> > }
>
> That's my solution! I was surprised when I saw that named sub
> definitions are evaluated just once.
> BTW, I don't like that f2 is visible from outside of f1.
Those two things go together: the sub definition is only evaluated once
*because* you're defining a globally-visible named sub. What you were
expecting is 'my sub', which doesn't exist yet (and very possibly never
will: it seems it's harder to get right than it appears).
It's no worse, really, than sub definitions being visible outside the
file they were defined in. They are global objects living in the symbol
table, so their names aren't lexically scoped at all (modulo tricks like
namespace::clean...).
> > (and in fact you can skip the BEGIN, since you didn't use warnings)
> >
> > sub f1 {
> > open X, "<", \"\n";
> > <X>;
> > say $.;
> > }
>
> Clever, but then why not
>
> sub f1 {
> say 1+$.++;
> }
Well, yes, but that's just the same as using an ordinary global. I was
trying to find some other place to store global state.
My initial thought was that $. counted *output* lines (I don't have
occasion to use it much) which would make 'say $.' count all on its own.
Alas, no...
> > sub f1 {
> > "1 2 3 4 5 6 7 8 9 10 " =~ /(\d+) /g;
> > say $1;
> > }
>
> I didn't know I could use =~ with the /g option in scalar context:
> while ("1 2 3 4 5 6 7 8 9 10 " =~ /(\d+) /g) {
> say $1;
> }
> Is it an idiom or a little trick?
It's absolutely intentional that it works that way, if that's what you
mean. Of course, the intent was to use it in while(), the way you did,
rather than on successive calls to a sub.
Implicit iterators like that are an important part of Perl: m//g, s///g,
each(), scalar-<>, scalar-.., and ?? all have implicit state stashed
away somewhere. Keeping track of where that state is kept is often
rather important, and is one of the reasons those operators are not used
as much as they used to be.
Ben
------------------------------
Date: Mon, 05 Mar 2012 11:50:31 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: little quiz
Message-Id: <4f549a77$0$1377$4fafbaef@reader2.news.tin.it>
On 3/5/2012 0:39, Ben Morrow wrote:
> Quoth Kiuhnm<kiuhnm03.4t.yahoo.it>:
[...]
>> Same thing without the warning:
>>
>> sub f1 {
>> my $v if my $y;
>> ++$v;
>> say $v;
>> }
>
> I think the lack of warning is not intentional: that is, I think any
> change to core perl which caused my example to stop working would do the
> same to yours, it's just not so visible at compile time that that is the
> case.
Much in Perl is not intentional :)
Do you remember my post about given...when?
Perl's syntax is so complex that suprises are bound to come up.
I've seen my share of hacks and tricks when doing metaprogramming in
C++. The Turing-completeness of templates was totally unexpected.
>> I didn't even know that
>> my $v = 7;
>> my $v = 0;
>> was possible.
>
> Those are separate variables which happen to have the same names. It's
> exactly the same situation as
>
> my $v = 7;
> {
> my $v = 0;
> }
>
> except the scope of the second $v extends all the way to the end of the
> scope of the first.
>
>> I didn't know that "my" was an operator.
>
> I'm not sure what you mean by that... it has a runtime effect,
> certainly.
In many languages, those are just directives to the compiler. Their
effect is entirely determined at compile-time.
>>> sub f1 {
>>> my $v;
>>> sub f2 {
>>> ++$v;
>>> say $v;
>>> }
>>> f2();
>>> }
>>
>> That's my solution! I was surprised when I saw that named sub
>> definitions are evaluated just once.
>> BTW, I don't like that f2 is visible from outside of f1.
>
> Those two things go together: the sub definition is only evaluated once
> *because* you're defining a globally-visible named sub. What you were
> expecting is 'my sub', which doesn't exist yet (and very possibly never
> will: it seems it's harder to get right than it appears).
>
> It's no worse, really, than sub definitions being visible outside the
> file they were defined in. They are global objects living in the symbol
> table, so their names aren't lexically scoped at all (modulo tricks like
> namespace::clean...).
Will Perl 6 correct these issues? I understand it will break code anyway.
>>> sub f1 {
>>> "1 2 3 4 5 6 7 8 9 10 " =~ /(\d+) /g;
>>> say $1;
>>> }
>>
>> I didn't know I could use =~ with the /g option in scalar context:
>> while ("1 2 3 4 5 6 7 8 9 10 " =~ /(\d+) /g) {
>> say $1;
>> }
>> Is it an idiom or a little trick?
>
> It's absolutely intentional that it works that way, if that's what you
> mean. Of course, the intent was to use it in while(), the way you did,
> rather than on successive calls to a sub.
>
> Implicit iterators like that are an important part of Perl: m//g, s///g,
> each(), scalar-<>, scalar-.., and ?? all have implicit state stashed
> away somewhere. Keeping track of where that state is kept is often
> rather important, and is one of the reasons those operators are not used
> as much as they used to be.
Good, I know two implicit iterators out of six...
Kiuhnm
------------------------------
Date: Sun, 4 Mar 2012 03:35:36 -0800 (PST)
From: ehabaziz2001@gmail.com
Subject: Re: sorting unicode file under windows command line
Message-Id: <9999183.1338.1330860936116.JavaMail.geo-discussion-forums@vbbfy7>
T24gVHVlc2RheSwgRmVicnVhcnkgMTQsIDIwMTIgMTI6MzQ6MDIgUE0gVVRDKzIsIGhhcHB5dG9k
YXkgd3JvdGU6DQo+IEkgYW0gdHJ5aW5nIHRvIHNvcnQgYSBmaWxlIGFjY29yZGluZyB0byB1bmlj
b2RlIGZpZWxkDQo+IChwb3NpdGlvbixsZW5ndGgpIHVuZGVyIEJlcmtlbGV5IHVuaXggdmVyc2lv
biAod2luZG93cyB2ZXJzaW9uKS4gSQ0KPiB0cmllZCBtc29ydDMuZXhlIHV0aWxpdHkgYnV0IGNh
biBub3QgZmluZCBtc29ydDMuZXhlIHdvcmtpbmcgd2l0aCBtZS4NCj4gSXMgdGhlcmUgYSBjb21t
YW5kIGxpbmUgdXRpdGxpdHkgb3IgcGVybC9zZWRhd2sgcHJvZ3JhbSB0aGF0IHNvcnRzIGENCj4g
ZmlsZSBhY2NvcmRpbmcgdG8gdW5pY29kZSBjb2x1bW4gVVRGLTggd2l0aA0KPiBzdGFydF9wb3Np
dGlvbixsZW5ndGhfcG9zaXRpb24uDQo+IA0KPiBJIGNhbiBub3QgaW5zdGFsbCBjeWdpbi4NCj4g
DQo+IE15IGxpbmUgYXJlIGxpa2UgdGhpcyA6DQo+IA0KPiAgICAgIDEgw7fZhsK32LnCpCDCudmG
wrQg2YTCqNmD2YUgwrfZgMKxwqQgwrfZhtmD2IzZgsKkICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICDigJnigJnigJMNCj4g4oCi4oCU4oCT2q/aiNqvIDEgICAxICAgMSAgIDEgICAg
ICAgICDigJnigJnigJPigKLigJTigJMNCj4g2q/aiNqvICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCudmD2IzYtdi5DQo+IMKkQSAgICAg
ICBtYXN0ZXJfZmlsZV9IT0xELmxvZyAgICAgICAgINmD2IzYtdi5wqQgw6LaiNi62YXCpCDCudik
2YIgw6jZgtmGwrfZgCDYutmAwq7YucKkIMO324HCsQ0KPiDCt9mAwrHZgCDYow0KPiDar+KAmA0K
PiAgICAgICAyIMO3wqTZhdimwrkg2YTZhtio2Kog2YfZgtuBwrENCj4g4oCT4oCd4oCU2qnigJTi
gJPar9qI2q8gMSAgIDEgICAxICAgMiAgICAgICAgIOKAk+KAneKAlNqp4oCU4oCTDQo+INqv2oja
ryAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgwrnZg9iM2LXYuQ0KPiDCpEEgICAgICAgbWFzdGVyX2ZpbGVfSE9MRC5sb2cgICAgICAgICDZ
g9iM2LXYucKkIMOi2ojCudik2YAgwqTCucKo2KIg2KMg4oCd2ogNCg0KSSBhc3N1cmUgdG8geW91
IHRoYXQgaXMgbm90aGluZyBpcyBoYXBwZW5lZCAuIEhvdyBjYW4gSSByZWNvZ25pemUgdGhlIGNo
YXJhY3RlciBzZXQgb2YgdGhlIGRhdGEgZmlsZSAuDQpNeSBQZXJsIHNjcmlwdHMgaXMgbGlrZSB0
aGlzIDoNCg0KdXNlIGVuY29kaW5nICd1dGY4JzsgDQpteSBARmlsZTsgDQpteSAlUG9zaXRpb25z
X2FuZF9sZW5naHRzID0gKCANCjExMCA9PiAxMiAsIA0KKTsgDQoNCg0KDQoNCiNGb3IgZXh0ZXJu
YWwgZmlsZSANCm9wZW4gRklMRSwgJz46dXRmOCcsICdjOlxjb21waWxlclxwZXJsXGJpblxzb3J0
aW5nLnR4dCcgb3IgZGllICIkXkVcbiI7IA0KYmlubW9kZSBTVERPVVQsICc6dXRmOCc7IA0KDQoN
CndoaWxlIChteSAkbGluZSA9IDxEQVRBPikgeyANCm15ICRyb3c7IA0KICAgIGZvcmVhY2ggbXkg
JFBPUyAoc29ydCB7JGE8PT4kYn0ga2V5cyAlUG9zaXRpb25zX2FuZF9sZW5naHRzKSB7IA0KICAg
IHB1c2ggQHskcm93fSwgc3Vic3RyICRsaW5lLCAkUE9TLCAkUG9zaXRpb25zX2FuZF9sZW5naHRz
eyRQT1N9IA0KICAgIH0gDQpwdXNoIEBGaWxlLCAkcm93IA0KDQoNCn0gDQoNCg0KI3VzZSBEYXRh
OjpEdW1wZXI7IHByaW50IER1bXBlcihcQEZpbGUpO2V4aXQ7IA0KDQpmb3JlYWNoIG15ICRyb3cg
KHNvcnQgeyRhLT5bMF0gY21wICRiLT5bMF0gfHwgJGEtPlsyXSBjbXAgJGItPlsyXX0gQEZpbGUp
IHsgDQpwcmludCAiQHskcm93fVxuIiANCg0KDQoNCn0gDQoNCg0KTXkgRGF0YSBmaWxlIGlzIGxp
a2UgOg0KDQoNCg0KDQogICAgICAxIMK32YDCsdmAINmB2YbZg8KkwrnCqMKkINi6wrfYjNiqINmB
2K/ZgiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAg2q/igJzigJ3aiNqI4oCY4oCc4oCY2ojaiNqI2q8g
MCAgIDAgICAwICAgMCAgICAgICAgINqv4oCc4oCd2ojaiOKAmOKAnOKAmNqI2ojaiNqvICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgINmGwrnYokEg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwrnYpNmAIMOnwrnZg9iM
2LXYucKkIMOnwrnZg9iM2LXYucKkICDDp8K52YPYjNi12LnCpCDCudmAwrHZi8KkIMKpwrnCt9i5
wqQg2YjZhdiM2LXCudii2LnCpCDYo9mFwrEgw6jYt9uBINqv2qkNCiAgICAgIDIgwrfZhtif2YXC
qMKkIMK32YDCscKkIMK32YbCsdmFIMK32YDCscKkICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDar9qI
2qnaiOKAnOKAnOKAouKAk9qI2ojaiNqvIDAgICAwICAgMCAgIDAgICAgICAgICDar9qI2qnaiOKA
nOKAnOKAouKAk9qI2ojaiNqvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgINmD2J/Zgti5wqRBICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICDCudik2YAgw6fCudmD2IzYtdi5wqQgw6fCudmD2IzYtdi5wqQgIMOo2YbYstmF
2YLZgNi5wqQgLSDDq8KkwrfDoNii2LnCpCDYn9i3wrnZgCDCucK32IzZgg0KICAgICAgMyDZgdmL
24HYucKkIMK3wqjYqiDCt9mAwrHZgCDCt9mF2YDCsdmAINi6wrfYjNiqICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgINqv2ojaqdqI4oCc4oCc4oCT2ojar9qI2ojaryAwICAgMCAgIDAgICAwICAgICAgICAg2q/a
iNqp2ojigJzigJzigJPaiNqv2ojaiNqvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgINmD2J/Zgti5wqRBICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICDCudik2YAgw6fCudmD2IzYtdi5wqQgw6fCudmD2IzYtdi5wqQgw6La
iNqILi7Dp8K52YPYjNi12LnCpCDYodmA2KIgw7fZhtiqINih2YbZhduB2LnCpCDCuduBwq4g2KMg
w7fZgCDDt9iM2YDYqiDYoyDCpCDar+KAnQ0KICAgICAgNCDZhNq+2IzCsdiiIMK3wqTZhcKu2LnC
pCDCt8Ko2Kogw7fZhtuBwrEgw6rCt8Ku2YAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIA==
------------------------------
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 3631
***************************************
