[31873] in Perl-Users-Digest
Perl-Users Digest, Issue: 3136 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Sep 17 18:09:22 2010
Date: Fri, 17 Sep 2010 15:09:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 17 Sep 2010 Volume: 11 Number: 3136
Today's topics:
Confused about closures <schaitan@gmail.com>
Re: Confused about closures <jl_post@hotmail.com>
Re: How to update the GUI <ben@morrow.me.uk>
Re: How to update the GUI <founder@pege.org>
Re: Marc the Reaper <derykus@gmail.com>
Re: Memory leak with threads <rvtol+usenet@xs4all.nl>
Re: Memory leak with threads <jcombe@gmail.com>
Re: Memory leak with threads <rvtol+usenet@xs4all.nl>
Re: Memory leak with threads sln@netherlands.com
Syntax change in 5.12 <founder@pege.org>
Re: Syntax change in 5.12 <tadmc@seesig.invalid>
Re: Syntax change in 5.12 <spam+newsgroups@bde-arc.ampr.org>
Re: Syntax change in 5.12 <rvtol+usenet@xs4all.nl>
Re: Syntax change in 5.12 <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 17 Sep 2010 07:28:22 -0700 (PDT)
From: Krishna Chaitanya <schaitan@gmail.com>
Subject: Confused about closures
Message-Id: <fc490ee6-c5af-45ee-96e6-5b4f9e1696e2@i4g2000prf.googlegroups.com>
Hi,
Following's an extract from Perl FAQ 7.13 (closures):
****************
Closures are often used for less esoteric purposes. For example,
when
you want to pass in a bit of code into a function:
my $line;
timeout( 30, sub { $line = <STDIN> } );
If the code to execute had been passed in as a string, '$line =
<STDIN>', there would have been no way for the hypothetical
timeout()
function to access the lexical variable $line back in its
caller's
scope.
****************
I'm not clear about what's being said here...why would timeout need to
access $line here at all? What would be wrong with:
timeout(30,scalar(<STDIN>));
What's the real, "less esoteric", use of the closure being described
here? Pls. help me...am I missing something obvious?
Thanks in advance,
Chaitanya
P.S: Pardon me if this is something silly which's escaping me...am
overworked. Pls. bear...
------------------------------
Date: Fri, 17 Sep 2010 08:00:40 -0700 (PDT)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: Confused about closures
Message-Id: <0e044d36-db18-4db6-ba05-3f3d4be123e7@j19g2000vbh.googlegroups.com>
On Sep 17, 8:28=A0am, Krishna Chaitanya <schai...@gmail.com> wrote:
>
> Following's an extract from Perl FAQ 7.13 (closures):
>
> ****************
> =A0 =A0 Closures are often used for less esoteric purposes. For example,
> when
> =A0 =A0 you want to pass in a bit of code into a function:
> =A0 =A0 =A0 =A0 =A0 =A0 my $line;
> =A0 =A0 =A0 =A0 =A0 =A0 timeout( 30, sub { $line =3D <STDIN> } );
> =A0 =A0 If the code to execute had been passed in as a string, '$line =3D
> =A0 =A0 <STDIN>', there would have been no way for the hypothetical
> timeout()
> =A0 =A0 function to access the lexical variable $line back in its
> caller's
> =A0 =A0 scope.
> ****************
>
> I'm not clear about what's being said here...why would timeout
> need to access $line here at all?
I think what perlfaq7 is trying to say is that timeout() is just a
hypothetical function that someone might need to create: nothing more
than a function that takes a subroutine as an argument.
Instead of passing in sub { ... } as an argument to a function,
sometimes people will pass in a string containing code, to be eval()ed
in the function.
> What would be wrong with:
>
> timeout(30,scalar(<STDIN>));
If you did that, then $line wouldn't be populated. Apparently the
person who created the hypothetical timeout() function wants to
populate $line with input taken from STDIN. Your way
( timeout(30,scalar(<STDIN>)) ) wouldn't do that. Not only that, but
your way would execute scalar(<STDIN>) right before the timeout()
function was called, instead of inside it.
> What's the real, "less esoteric", use of the closure being described
> here? Pls. help me...am I missing something obvious?
I think perlfaq7 means it's "less esoteric" when compared to
passing in the code as a string, like this:
timeout( 30, '$line =3D <STDIN>' );
If a programmer wants to pass in code to execute inside a function
(during the function's execution), sometimes they will pass the code
into the function as a string, and then eval() it in the function.
However, the "less esoteric" way of doing it is to pass it in as a
subroutine reference itself -- that is, instead of passing in '$line =3D
<STDIN>', you pass in sub { $line =3D <STDIN> }. That way the $line
variable can refer to the one that was declared (with "my") right
before the call to timeout().
In other words, when executing the passed-in code with:
my $line;
timeout( 30, sub { $line =3D <STDIN> } );
the $line variable we see here gets populated. But with:
my $line;
timeout( 30, '$line =3D <STDIN>' );
then the $line variable we see here WON'T get populated. Instead, a
$line variable visible in the timeout() function will get populated
instead (when the code gets eval()ed in the timeout() function).
So if you want the $line variable (the one we're seeing declared
before the call to timeout()) to be populated, using the closure is
the better way to do it.
I hope that helps, Chaitanya.
Cheers,
-- Jean-Luc
------------------------------
Date: Fri, 17 Sep 2010 17:43:13 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How to update the GUI
Message-Id: <1eicm7-pmn.ln1@osiris.mauzo.dyndns.org>
Quoth =?UTF-8?B?Um9sYW5kIE3DtnNs?= <founder@pege.org>:
> On 2010-09-17 06:23, Ben Morrow wrote:
> >
> > Quoth =?UTF-8?B?Um9sYW5kIE3DtnNs?=<founder@pege.org>:
> >> On 2010-09-17 02:37, Ben Morrow wrote:
> >>>
> >>> Quoth =?ISO-8859-1?Q?Roland_M=F6sl?=<founder@pege.org>:
> >>>> I am just migrating a software from
> >>>> a 11 year old version from active Perl.
> >>>
> >>> Which version of Perl were you using previously?
> >>
> >> ActiveState built 522 from 1999
> >
> > Which version of *perl* is that? 5005?
>
> Perl 5
<sigh> Perl 5 *point* *what*? Please post the output of perl -v for the
old perl.
> > If so you should have upgraded
> > a long time ago.
>
> This was not possible, because of the GUI problem
So Peter is correct in suggesting that this is not a problem with
upgrading to 5.12, but rather a problem with upgrading to 5.6? Have you
checked the PerlScript docs to see if anything changed between 5005 and
5.6? Given the core perl changes that happened at that time I wouldn't
be the least bit surprised if PerlScript had to change as well.
> >> I transferred with Laplink PC-Mover
> >> the installation from my old Win XP to my new notebook
> >
> > So, let me get this straight:
> >
> > 5005 on WinXP works correctly
> > 5005 on Win7 works correctly
> > 5.12 on Win7 fails
>
> Yes, the GUI update problem
>
> > Have you tried using 5.12 on WinXP?
>
> I have installed 5.12 on my old Win XP notebook
> to test
...and?
> >>> Please post a minimal program that exhibits this problem.
>
> Save this as example.hta
Thank you. I can't run it, since I haven't got ActivePerl installed
anywhere (nor Windows 7, for that matter), but if you talk to
ActiveState having a simple example like this will be invaluable.
Ben
------------------------------
Date: Fri, 17 Sep 2010 20:00:37 +0200
From: =?UTF-8?B?Um9sYW5kIE3DtnNs?= <founder@pege.org>
Subject: Re: How to update the GUI
Message-Id: <i70ac3$iql$1@news.albasani.net>
On 2010-09-17 18:43, Ben Morrow wrote:
>
> Quoth =?UTF-8?B?Um9sYW5kIE3DtnNs?=<founder@pege.org>:
>> On 2010-09-17 06:23, Ben Morrow wrote:
>>>
>>> Quoth =?UTF-8?B?Um9sYW5kIE3DtnNs?=<founder@pege.org>:
>>>> On 2010-09-17 02:37, Ben Morrow wrote:
>>>>>
>>>>> Quoth =?ISO-8859-1?Q?Roland_M=F6sl?=<founder@pege.org>:
>>>>>> I am just migrating a software from
>>>>>> a 11 year old version from active Perl.
>>>>>
>>>>> Which version of Perl were you using previously?
>>>>
>>>> ActiveState built 522 from 1999
>>>
>>> Which version of *perl* is that? 5005?
>>
>> Perl 5
>
> <sigh> Perl 5 *point* *what*? Please post the output of perl -v for the
> old perl.
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Roland Mösl>perl -v
This is perl, version 5.005_03 built for MSWin32-x86-object
(with 1 registered patch, see perl -V for more detail)
Copyright 1987-1999, Larry Wall
Binary build 522 provided by ActiveState Tool Corp.
http://www.ActiveState.com
Built 09:52:28 Nov 2 1999
>>> If so you should have upgraded
>>> a long time ago.
>>
>> This was not possible, because of the GUI problem
>
> So Peter is correct in suggesting that this is not a problem with
> upgrading to 5.12, but rather a problem with upgrading to 5.6? Have you
> checked the PerlScript docs to see if anything changed between 5005 and
> 5.6? Given the core perl changes that happened at that time I wouldn't
> be the least bit surprised if PerlScript had to change as well.
I checked this in several attempts 2002 to solve the problem
with the GUI update.
I had no success.
But now is the situation critical, because
more and more of my clients will migrate to a Win7 64 Bit,
and it's very complicate to install with the PC-mover trick
>>>> I transferred with Laplink PC-Mover
>>>> the installation from my old Win XP to my new notebook
>>>
>>> So, let me get this straight:
>>>
>>> 5005 on WinXP works correctly
>>> 5005 on Win7 works correctly
>>> 5.12 on Win7 fails
>>
>> Yes, the GUI update problem
>>
>>> Have you tried using 5.12 on WinXP?
>>
>> I have installed 5.12 on my old Win XP notebook
>> to test
>
> ...and?
Regardless what windows version, there is this GUI update problem
--
Roland Mösl - PEGE - http://www.pege.org
Planetary Engineering Group Earth
------------------------------
Date: Fri, 17 Sep 2010 11:58:22 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Marc the Reaper
Message-Id: <1d8ae073-0d61-4f73-8667-bbba56d1cd30@a4g2000prm.googlegroups.com>
On Sep 17, 2:59=A0am, "Dr.Ruud" <rvtol+use...@xs4all.nl> wrote:
> On 2010-09-17 08:09, Marc Girod wrote:
>
> > On Sep 16, 10:13 am, "C.DeRykus"<dery...@gmail.com> =A0wrote:
> >> So you could change the handler slightly and
> >> eliminate the waitpid in the sleep loop.
>
> > Thanks. You are right, of course.
> > What is your reason to prefer 'while keys %family' to 'while %family'?
>
> Benchmark! (keys() is normally lighter and faster)
>
A quick benchmark seems to favor keys over HISC
(Hash In Scalar Context) but better benchmarks
would likely include variously sized hashes.
perldata also hints HISC is of limited use:
If you evaluate a hash in scalar context,
it returns false if the hash is empty. If
there are any key/value pairs, it returns true;
... This is pretty much useful only to find out
whether Perl's internal hashing algorithm is
performing poorly on your data set.
There's also an interesting internals discussion on
this topic which seemed somewhat inconclusive:
http://www.perlmonks.org/?node_id=3D760534
Some may like keys because it's more familiar;
HISC could give someone pause to remember what it
does or how it works. However, perldata documents
HISC to return false for an empty hash. A case of
TIMTOWTDI.
--
Charles DeRykus
------------------------------
Date: Fri, 17 Sep 2010 12:25:09 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Memory leak with threads
Message-Id: <4c934205$0$41106$e4fe514c@news.xs4all.nl>
On 2010-09-17 10:40, Jon Combe wrote:
>> You need to measure the process space from the OS, not from Perl, which
>> after all likely cannot be trusted if it is leaking memory.
>>
>> On Linux:
>>
>> for ( my $i = 0 ; $i< 150000 ; $i++ )
>> {
>> my $thread = threads->create('thread_function');
>> $thread -> join();
>> if ( $i % 1000 == 0 )
>> {
>> printf ( "%010i\t%3\$s" , $i, `ps -p $$ -o rss` );
>> }
>>
>> }
>
> Here is a sample of the output I get from this - so it does confirm
> for sure it's leaking memory.
>
> 0000000000 2872
> 0000001000 3672
> 0000002000 4384
> 0000003000 5092
> 0000004000 5804
> 0000005000 6516
> 0000006000 7228
> 0000007000 7936
> 0000008000 8648
> 0000009000 9356
> 0000010000 10072
> 0000011000 10784
> 0000012000 11496
> 0000013000 12204
> 0000014000 12920
> 0000015000 13628
> 0000016000 14340
> 0000017000 15052
> 0000018000 15764
> 0000019000 16428
> 0000020000 17184
> 0000021000 17900
> 0000022000 18616
> 0000023000 19328
Also check perl -V |grep thread
With a perl 5.8.5. and archname=i386-linux-thread-multi, I get:
0000000000 2748
0000001000 2892
0000002000 2892
0000003000 2892
0000004000 2892
0000005000 2892
etc.
--
Ruud
------------------------------
Date: Fri, 17 Sep 2010 04:16:44 -0700 (PDT)
From: Jon Combe <jcombe@gmail.com>
Subject: Re: Memory leak with threads
Message-Id: <3cf75329-f766-4916-ab4b-3ad268b5b37f@u13g2000vbo.googlegroups.com>
> Also check perl -V |grep thread
>
> With a perl 5.8.5. and archname=3Di386-linux-thread-multi, I get:
>
> 0000000000 =A0 =A0 =A02748
> 0000001000 =A0 =A0 =A02892
> 0000002000 =A0 =A0 =A02892
> 0000003000 =A0 =A0 =A02892
> 0000004000 =A0 =A0 =A02892
> 0000005000 =A0 =A0 =A02892
I'm wondering if this leak was introduced between 5.8.5 and 5.8.8? The
result I originally posted are for perl 5.8.8 (osname=3Dlinux,
osvers=3D2.6.18-53.el5, archname=3Di386-linux-thread-multi)
Here are the results for 5.12.2 i686-linux-thread-multi
0000000000 2972
0000001000 4280
0000002000 5568
0000003000 6856
0000004000 8148
0000005000 9436
0000006000 10724
0000007000 12016
0000008000 13304
0000009000 14592
0000010000 15880
I also have tried 5.10.1 (archname=3Di686-linux-gnu-thread-multi)
0000000000 2896
0000001000 4404
0000002000 5896
0000003000 7388
0000004000 8884
0000005000 10376
0000006000 11868
0000007000 13360
0000008000 14852
0000009000 16344
0000010000 17840
0000011000 19332
0000012000 20824
So all the three versions I have tried exhibit it.
Jon
------------------------------
Date: Fri, 17 Sep 2010 13:56:34 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Memory leak with threads
Message-Id: <4c935773$0$41115$e4fe514c@news.xs4all.nl>
On 2010-09-17 13:16, Jon Combe wrote:
> I'm wondering if this leak was introduced between 5.8.5 and 5.8.8?
I started a thread ;) on p5p with the same subject, to find out.
--
Ruud
------------------------------
Date: Fri, 17 Sep 2010 09:57:01 -0700
From: sln@netherlands.com
Subject: Re: Memory leak with threads
Message-Id: <3i67961k7rlgfhpo4pkr8vntguopnfh4lg@4ax.com>
On Fri, 17 Sep 2010 01:37:35 -0700 (PDT), Jon Combe <jcombe@gmail.com> wrote:
>I get the following output:-
>
>ALL:- :
>threads::all=SCALAR(0x993fd0c)
>threads::all=SCALAR(0x99cc024)
>threads::all=SCALAR(0x99cc03c)
>threads::all=SCALAR(0x99cc054)
>threads::all=SCALAR(0x99cdc50)
>threads::all=SCALAR(0x99cdc68)
>threads::all=SCALAR(0x99cdc80)
>threads::all=SCALAR(0x99cdc98)
>threads::all=SCALAR(0x99cdcb0)
>threads::all=SCALAR(0x99cdcc8)
>RUNNING:- :
>threads::running=SCALAR(0x99cc018)
>threads::running=SCALAR(0x99cdd4c)
>threads::running=SCALAR(0x99cdd64)
>threads::running=SCALAR(0x99cdd7c)
>threads::running=SCALAR(0x99cdd94)
>threads::running=SCALAR(0x99cddac)
>threads::running=SCALAR(0x99cddc4)
>threads::running=SCALAR(0x99cdddc)
>threads::running=SCALAR(0x99cddf4)
>threads::running=SCALAR(0x99cde0c)
>JOINABLE:- :
>threads::joinable=SCALAR(0x99cdcbc)
>threads::joinable=SCALAR(0x9da0e58)
>threads::joinable=SCALAR(0x9da0e70)
>threads::joinable=SCALAR(0x9da0e88)
>threads::joinable=SCALAR(0x9da0ea0)
>threads::joinable=SCALAR(0x9da0eb8)
>threads::joinable=SCALAR(0x9da0ed0)
>threads::joinable=SCALAR(0x9da0ee8)
>threads::joinable=SCALAR(0x9da0f00)
>threads::joinable=SCALAR(0x9da0f18)
>ALL:- :
>
>RUNNING:- :
>
>JOINABLE:- :
>
>
>So it does behave as I expect in that after doing the join no threads
>are running.
>
I find it weird threads->list() doesen't work for the unix flavor.
I get the same (almost) when using threads::list().
The error is that most of the time, the threads already
returned (are not running) when getting the list
with 'threads::list(threads::running)'.
Using threads->list() acurately (mostly) reflects the
right status.
Either way it doesen't matter. I think what matters more
is if the thread is being detached before it is joined.
I put a test together. See what you get with this.
Try with/without the comment in the sleep() in the thread
function. If its not detached before its joined, then there might
be a leak problem.
Another test might be to exit() from main after the threads are
created. This should print some thread messages.
use strict;
use warnings;
use threads;
use threads::shared;
my @threads;
for ( my $j = 1 ; $j <= 10 ; $j++ )
{
my $thread = threads->create(\&thread_function, $j);
push ( @threads , $thread );
}
sleep(1);
my @running;
my @joinable;
my @detached;
for ( @threads )
{
push (@running, $_) if ( $_->is_running() );
push (@joinable, $_) if ( $_->is_joinable() );
push (@detached, $_) if ( $_->is_detached() );
}
print "\n";
print "ALL:- : \n" . join ( "\n" , @threads ) . "\n";
print "RUNNING:- : \n" . join ( "\n" , @running ) . "\n";
print "JOINABLE:- : \n" . join ( "\n" , @joinable ) . "\n";
print "DETACHED:- : \n" . join ( "\n" , @detached ) . "\n";
sleep(1);
print "Joining ...\n\n";
for ( @threads )
{
$_ -> join();
}
@running = ();
@joinable = ();
@detached = ();
for ( @threads )
{
push (@running, $_) if ( $_->is_running() );
push (@joinable, $_) if ( $_->is_joinable() );
push (@detached, $_) if ( $_->is_detached() );
}
print "RUNNING:- : \n" . join ( "\n" , @running ) . "\n";
print "JOINABLE:- : \n" . join ( "\n" , @joinable ) . "\n";
print "DETACHED:- : \n" . join ( "\n" , @detached ) . "\n";
sub thread_function
{
print "thread $_[0] start\n";
# sleep(4);
print "thread $_[0] done\n";
}
__END__
Output:
thread 1 start
thread 1 done
thread 2 start
thread 2 done
thread 3 start
thread 3 done
thread 4 start
thread 4 done
thread 5 start
thread 5 done
thread 6 start
thread 6 done
thread 7 start
thread 7 done
thread 8 start
thread 8 done
thread 9 start
thread 9 done
thread 10 start
thread 10 done
ALL:- :
threads=SCALAR(0x18f7cec)
threads=SCALAR(0x18f7d0c)
threads=SCALAR(0x18f7d2c)
threads=SCALAR(0x18f7d4c)
threads=SCALAR(0x18f7d6c)
threads=SCALAR(0x18f7d8c)
threads=SCALAR(0x18f7dac)
threads=SCALAR(0x18f7dcc)
threads=SCALAR(0x18f7dec)
threads=SCALAR(0x18f7e0c)
RUNNING:- :
JOINABLE:- :
threads=SCALAR(0x18f7cec)
threads=SCALAR(0x18f7d0c)
threads=SCALAR(0x18f7d2c)
threads=SCALAR(0x18f7d4c)
threads=SCALAR(0x18f7d6c)
threads=SCALAR(0x18f7d8c)
threads=SCALAR(0x18f7dac)
threads=SCALAR(0x18f7dcc)
threads=SCALAR(0x18f7dec)
threads=SCALAR(0x18f7e0c)
DETACHED:- :
Joining ...
RUNNING:- :
JOINABLE:- :
DETACHED:- :
------------------------------
Date: Fri, 17 Sep 2010 12:23:42 +0200
From: =?ISO-8859-1?Q?Roland_M=F6sl?= <founder@pege.org>
Subject: Syntax change in 5.12
Message-Id: <i6vfjc$97f$1@news.albasani.net>
Beyond the GUI problem and to find a
replacement for Win32::Shell::Execute,
I had an error message:
my $mask = $word;
$mask =~ y/0123456789/----------/;
The line with the regular expression
worked well in V5 built 522 from 1999.
Where is the problem?
--
Roland Mösl - PEGE - http://www.pege.org
Planetary Engineering Group Earth
------------------------------
Date: Fri, 17 Sep 2010 08:24:59 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Syntax change in 5.12
Message-Id: <slrni96r0r.4uk.tadmc@tadbox.sbcglobal.net>
Roland Mösl <founder@pege.org> wrote:
> I had an error message:
Errr, what did the error message say?
Did you look it up in perldiag.pod?
> my $mask = $word;
> $mask =~ y/0123456789/----------/;
>
> The line with the regular expression
There is no regular expression there!
y/// (tr///) is does not use regular expressions.
from perlop:
=item tr/SEARCHLIST/REPLACEMENTLIST/cds
=item y/SEARCHLIST/REPLACEMENTLIST/cds
contrast that with:
=item m/PATTERN/msixpogc
=item s/PATTERN/REPLACEMENT/msixpogce
--
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: Fri, 17 Sep 2010 14:19:32 -0700
From: "D. Stussy" <spam+newsgroups@bde-arc.ampr.org>
Subject: Re: Syntax change in 5.12
Message-Id: <i70m1h$jq2$1@snarked.org>
"Roland Mösl" <founder@pege.org> wrote in message
news:i6vfjc$97f$1@news.albasani.net...
> Beyond the GUI problem and to find a
> replacement for Win32::Shell::Execute,
> I had an error message:
>
> my $mask = $word;
> $mask =~ y/0123456789/----------/;
>
> The line with the regular expression
> worked well in V5 built 522 from 1999.
>
> Where is the problem?
Your code, probably.
With Perl 5.12.0, it appears that certain constructs were tightened up to
be more strict. Code that ran without wanrings under 5.10 and earlier now
issue warnings.
------------------------------
Date: Fri, 17 Sep 2010 23:42:14 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Syntax change in 5.12
Message-Id: <4c93e0b8$0$41102$e4fe514c@news.xs4all.nl>
On 2010-09-17 12:23, Roland Mösl wrote:
> I had an error message:
>
> my $mask = $word;
> $mask =~ y/0123456789/----------/;
>
> The line with the regular expression
> worked well in V5 built 522 from 1999.
>
> Where is the problem?
The first problems are that you don't mention the message,
and that you misspell transliteration.
Just shorten the series of hypens to a single one.
perl -MO=Deparse -we'
my $mask;
$mask =~ y/0123456789/----/;
'
--
Ruud
------------------------------
Date: Fri, 17 Sep 2010 22:48:48 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Syntax change in 5.12
Message-Id: <0b4dm7-jjp.ln1@osiris.mauzo.dyndns.org>
Quoth "D. Stussy" <replies@newsgroups.kd6lvw.ampr.org>:
>
> With Perl 5.12.0, it appears that certain constructs were tightened up to
> be more strict. Code that ran without wanrings under 5.10 and earlier now
> issue warnings.
I believe the only change is that 'deprecation' warnings are now
mandatory (that is, they will appear even without an explicit 'use
warnings'). Did anything else change?
Ben
------------------------------
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 3136
***************************************
