[26050] in Perl-Users-Digest
Perl-Users Digest, Issue: 8258 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jul 18 21:05:17 2005
Date: Mon, 18 Jul 2005 18:05:04 -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 Mon, 18 Jul 2005 Volume: 10 Number: 8258
Today's topics:
Re: "Can't return a temporary from lvalue subroutine... <jkrugman345@yahbitoo.com>
Re: copy contructor (Anno Siegel)
Re: copy contructor <abigail@abigail.nl>
ithreads & memory (bler)
Re: ithreads & memory xhoster@gmail.com
Memory leak in loop when not using "my" - why? <sini@removemegmx.de>
Re: Regexp for variable length tags <jgibson@mail.arc.nasa.gov>
Re: Regexp for variable length tags <noreply@gunnar.cc>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 19 Jul 2005 00:50:00 +0000 (UTC)
From: J Krugman <jkrugman345@yahbitoo.com>
Subject: Re: "Can't return a temporary from lvalue subroutine..."
Message-Id: <dbhino$3t7$1@reader2.panix.com>
In <dbgjls$l1e$1@mamenchi.zrz.TU-Berlin.DE> anno4000@lublin.zrz.tu-berlin.de (Anno Siegel) writes:
>J Krugman <jkrugman345@yahbitoo.com> wrote in comp.lang.perl.misc:
>> I give the relevant code below.
>The code is reasonable, I would have written it similarly, except for
>> sub var : lvalue {
>> my $self = shift;
>> $self->{_var_} = shift if @_;
>This line is now redundant, or it would be if the code worked as expected.
>You're assigning through the lvalue now. It isn't exactly wrong to have
>it, but it distracts from the purpose of the lvalue-method.
My thought was to give users the option setting through the lvalue
*or* through the more conventional
$self->var(1);
...but maybe this is not such a hot idea...
>For a workaround, instead of tying the whole hash, you can tie each
>hash value to a scalar.
That's good to know. I was under the mistaken impression that only
"simple" scalar variables (i.e. like $foo, as opposed to $foo{bar})
could be tied to scalars.
>For one, you must either pre-tie all fields in the ->new method of
>My_Class, in which case you can't add fields dynamically. If you must
>do that, the ->var method(s) must do the tying on the fly when a new
>key is generated.
You lost me there, Anno. I don't see how, in general, an lvalue
method could do any on-the-fly tying, since all but the last
statement of the method are ignored when it is used as an lvalue.
(Yes, it could do it if it is being used as a non-lvalue method,
but that imposes a strange API).
>Another problem is that the STORE method of a tied scalar doesn't know
>about the hash key the value is stored under. Since each tied scalar
>belongs to a fixed key, it would be possible to store the hash key in
>the tying object (the one in Tie::Scalar...). But that's extra work,
>and it means you can't use Tie::StdScalar as is, because it has no
>provisions for extra values.
(A bit over my head, but that's OK: I know have a lot to learn.)
>I suppose your motivation is that you like the idea of lvalue methods,
>but need more control over what gets stored by careless users in your
>sensitive objects.
Exactly! Very clairvoyant of you.
>A similar problem exists with objects that expose
>(parts of) their interior though overloading a dereference operator,
>say %{}. Like lvalues, it gives you pretty syntax, but leaves your
>objects wide open. I have used tied hashes to correct this (that is,
>returned a reference to a tied hash in response to %{ $obj}, and haven't
>encountered the particular difficulty you're seeing. That may be
>an alternative approach.
I'm having a hard time picturing what you describe here. It seems
to imply that $obj somehow knows when it's being dereferenced (and
responds accordingly by "returning" a tied hash???), which I find
hard to understand. Is this something you do in any published code
that I could study?
Thank you very much for your post.
jill
--
To s&e^n]d me m~a}i]l r%e*m?o\v[e bit from my a|d)d:r{e:s]s.
------------------------------
Date: 18 Jul 2005 22:58:10 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: copy contructor
Message-Id: <dbhc62$53b$1@mamenchi.zrz.TU-Berlin.DE>
Abigail <abigail@abigail.nl> wrote in comp.lang.perl.misc:
> Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMMMCCCXXXIX
> September MCMXCIII in <URL:news:dbfv8r$88k$1@mamenchi.zrz.TU-Berlin.DE>:
>
> [ Snip ]
>
> && In my opinion, class design around accessors does solve the attribute
> && problem. Whether the solution is satisfactory (generally, or for a
> && specific problem) is another question.
>
>
> Just one question: how are you storing your attributes?
Any old way. The standard hash-as-a-record, its equivalent for
arrays, whatever the base type has to offer. The derived class
doesn't know, that's why it *has* to override all accessors.
If these are few and well known, the effort is expendable. The
rest of the class follows suit. You can well have an array class
inherit in this way from a hash class, and other combinations.
I'll give an example. In the code below, a class Parent has two
fields (attributes), alpha and beta. It also has the method total
which returns the sum of alpha and beta. It is implemented as
an array of two elements.
A class Client, implemented as the usual hash, wants to keep the role
of alpha, but split the field beta into the sum of its other fields
gamma and delta. It wants to inherit the ->total method from Parent,
which should thus be the sum of alpha, gamma and delta.
My point is that the method ->total, written to form the sum of a
two-element array, now forms the sum of a three-element hash.
Anno
#!/usr/local/bin/perl
use strict; use warnings; $| = 1;
my $c = Client->new( 5, 6, 7);
print "$_ -> ", $c->$_, "\n" for qw( alpha beta gamma delta total);
##########################################################################
package Parent;
sub new {
my $class = shift;
my ( $alpha, $beta) = @_;
bless [ $alpha, $beta], $class;
}
sub alpha { $_[ 0]->[ 0] }
sub beta { $_[ 0]->[ 1] }
sub total { $_[ 0]->alpha + $_[ 0]->beta }
package Client;
BEGIN { our @ISA = 'Parent' }
sub new {
my $class = shift;
my ( $alpha, $gamma, $delta) = @_;
bless {
alpha => $alpha,
gamma => $gamma,
delta => $delta,
}, $class;
}
sub alpha { $_[ 0]->{ alpha} }
sub gamma { $_[ 0]->{ gamma} }
sub delta { $_[ 0]->{ delta} }
sub beta { $_[ 0]->gamma + $_[ 0]->delta }
__END__
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: 19 Jul 2005 00:30:00 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: copy contructor
Message-Id: <slrnddoic8.7fo.abigail@alexandra.abigail.nl>
Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMMMCCCXXXIX
September MCMXCIII in <URL:news:dbhc62$53b$1@mamenchi.zrz.TU-Berlin.DE>:
:) Abigail <abigail@abigail.nl> wrote in comp.lang.perl.misc:
:) > Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMMMCCCXXXIX
:) > September MCMXCIII in <URL:news:dbfv8r$88k$1@mamenchi.zrz.TU-Berlin.DE>:
:) >
:) > [ Snip ]
:) >
:) > && In my opinion, class design around accessors does solve the attribute
:) > && problem. Whether the solution is satisfactory (generally, or for a
:) > && specific problem) is another question.
:) >
:) >
:) > Just one question: how are you storing your attributes?
:)
:) Any old way. The standard hash-as-a-record, its equivalent for
:) arrays, whatever the base type has to offer. The derived class
:) doesn't know, that's why it *has* to override all accessors.
:) If these are few and well known, the effort is expendable. The
:) rest of the class follows suit. You can well have an array class
:) inherit in this way from a hash class, and other combinations.
:)
:) I'll give an example. In the code below, a class Parent has two
:) fields (attributes), alpha and beta. It also has the method total
:) which returns the sum of alpha and beta. It is implemented as
:) an array of two elements.
:)
:) A class Client, implemented as the usual hash, wants to keep the role
:) of alpha, but split the field beta into the sum of its other fields
:) gamma and delta. It wants to inherit the ->total method from Parent,
:) which should thus be the sum of alpha, gamma and delta.
:)
:) My point is that the method ->total, written to form the sum of a
:) two-element array, now forms the sum of a three-element hash.
:)
:) Anno
:)
:) #!/usr/local/bin/perl
:) use strict; use warnings; $| = 1;
:)
:) my $c = Client->new( 5, 6, 7);
:) print "$_ -> ", $c->$_, "\n" for qw( alpha beta gamma delta total);
:)
:) ##########################################################################
:)
:) package Parent;
:)
:) sub new {
:) my $class = shift;
:) my ( $alpha, $beta) = @_;
:) bless [ $alpha, $beta], $class;
:) }
:)
:) sub alpha { $_[ 0]->[ 0] }
:) sub beta { $_[ 0]->[ 1] }
:)
:) sub total { $_[ 0]->alpha + $_[ 0]->beta }
:)
:)
:) package Client;
:) BEGIN { our @ISA = 'Parent' }
:)
:) sub new {
:) my $class = shift;
:) my ( $alpha, $gamma, $delta) = @_;
:) bless {
:) alpha => $alpha,
:) gamma => $gamma,
:) delta => $delta,
:) }, $class;
:) }
:)
:) sub alpha { $_[ 0]->{ alpha} }
:) sub gamma { $_[ 0]->{ gamma} }
:) sub delta { $_[ 0]->{ delta} }
:)
:) sub beta { $_[ 0]->gamma + $_[ 0]->delta }
:)
:) __END__
Well, that "works", but that kind of defeats the purpose of using OO:
reusing code. You will have to redefined *every* method of a parent class.
Take for instance the above example - since you aren't going to break
encapsulation, you don't know how the class is implemented. It might as
well be:
package Parent;
sub new {
my $class = shift;
my ( $alpha, $beta) = @_;
bless [ $alpha, $beta, $alpha + $beta ], $class;
}
sub alpha { $_[ 0]->[ 0] }
sub beta { $_[ 0]->[ 1] }
sub total { $_[ 0]->[ 2] }
It has the same interface, but if you now create your Client class
as presented, calling the method 'total' results in "Not an ARRAY reference".
You have to redefine any method that touches an attribute directly - and
you either have to peek inside (breaking encapsulation) to know which
methods touch an attribute - or redefine every method.
But if you redefine every method, what's the point of inheritance?
Abigail
--
perl -wle '$, = " "; sub AUTOLOAD {($AUTOLOAD =~ /::(.*)/) [0];}
print+Just (), another (), Perl (), Hacker ();'
------------------------------
Date: Mon, 18 Jul 2005 22:12:14 +0000 (UTC)
From: "Micha³ Lesiak (bler)" <michalusenet@blaair.eu.org>
Subject: ithreads & memory
Message-Id: <Xns969821251E05michalusenetblaaireu@193.110.122.97>
Hello,
A simple script:
#!/usr/bin/perl
use threads;
use Time::HiRes "usleep";
sub th {
usleep(10000);
}
while(1) {
$th_n = threads->new(\&th);
$th_n->detach;
usleep(100000);
}
and that is, every 0,1s a new thread is created, and it runs for 0,01s. So,
when a new $th_n starts, the previous one is dead and gone - but the memory
is not released. The script goes on until it eats up all the memory avaible
and segfaults.
Now, this is just to show the problem, my real application creates a couple
of 10s threads once in a while - and it runs for months, which in due
course ends just like the above, out of memory and segfault. I know there
are some problems with ithreads, but in my case this means it's completely
unusable, so I think I'm doing something wrong. Can you help me?
perl 5.8.7 (5.8.2, 5.8.5 also been tried), kernel 2.6.11.6 (some other
versions tested too), threads 1.05.
--
M.
------------------------------
Date: 18 Jul 2005 22:38:21 GMT
From: xhoster@gmail.com
Subject: Re: ithreads & memory
Message-Id: <20050718183821.191$VB@newsreader.com>
"Micha³ Lesiak (bler)" <michalusenet@blaair.eu.org> wrote:
> Hello,
>
> A simple script:
>
> #!/usr/bin/perl
>
> use threads;
> use Time::HiRes "usleep";
>
> sub th {
> usleep(10000);
> }
>
> while(1) {
> $th_n = threads->new(\&th);
> $th_n->detach;
> usleep(100000);
> }
You should check the actual time slept by usleep. It is possible
that the parent is waking up early and hence spawning new threads
more often than you think.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Tue, 19 Jul 2005 02:30:56 +0200
From: Sinisa Susnjar <sini@removemegmx.de>
Subject: Memory leak in loop when not using "my" - why?
Message-Id: <42dc49c1_2@news.arcor-ip.de>
Hello Group,
could a Perl Guru please explain to me what is going on here (so I can
become one too ;-) )?!?
Progy1.pl:
#!/usr/bin/perl
while ($line = <>) {
chomp($line);
($key, $value) = split(':', $line);
$myhash{$key} = $value;
}
Progy1.pl shows a small piece of code from a larger program that is
supposed to do mass-data manipulation (>50 mio lines of data).
I was asked to check for memory leaks... it was leaking tons (>4GB) of
memory and I discovered that with rewriting it like Progy2.pl below, the
memory leaks would go away:
Progy2.pl:
#!/usr/bin/perl
use strict;
use warnings;
my %myhash;
while (my $line = <>) {
chomp($line);
my ($key, $value) = split(':', $line);
$myhash{$key} = $value;
}
Yeah, sure - I could lean back and say problem solved, but I would
really like to understand why Progy1 is leaking and Progy2 not...
It seems to me that perl is allocating memory in Progy1.pl for the
variables within the while {} for every single pass through the loop and
never giving them back or reuse or garbage collect them (is the GC too
slow?), while in Progy2.pl - with the variables declared with "my" -
everything works as expected, i.e. no memory leaks, overall memory
consumption aroung 70MB which is ok for the type of files being processed.
btw, I am using perl 5.6.1 on Solaris 2.8...
I read the FAQs (I hope thorougly enough...)
Hope, somebody can help...
Regards,
Sinisa Susnjar
------------------------------
Date: Mon, 18 Jul 2005 15:18:42 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: Regexp for variable length tags
Message-Id: <180720051518423424%jgibson@mail.arc.nasa.gov>
In article <dbh2i3$8aa$1@news.nems.noaa.gov>, Jon Burroughs
<Jon@nospam.com> wrote:
> I am processing some data that has a up to three key-value pairs
> concatenated together. The keys can be "ADD, REM, EQD". Values are
> variable length.
>
> There will always be an "ADD" section, followed by 0 to 1 "REM"
> sections, followed by 0 to 1 "EQD" sections. For example:
> ADDxxxxxxxxREMyyyyyEQDzzzzz
>
> I'm trying to find a regular expression that will split this apart into
> separarate sections in one step.
>
> So far, I have this:
>
> $rec =~ /(ADD.+)(REM.+)(EQD.+)/;
>
> But, this only works if I know the record has all three tokens.
>
> This gobbles too much:
> $rec =~ /(ADD.+)(REM.+)?(EQD.+)?/;
You can use split with a capturing pattern to extract both the keys and
the values:
#!/usr/local/bin/perl
#
use warnings;
use strict;
my $s = 'ADDxxxxxxxREMyyyyyyEQDzzzzzz';
my @fields = split(/(ADD|REM|EQD)/,$s);
print "fields: ", join(',',@fields), "\n";
__END__
which gives:
fields: ,ADD,xxxxxxx,REM,yyyyyy,EQD,zzzzzz
Note the leading empty field.
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
------------------------------
Date: Tue, 19 Jul 2005 00:53:57 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Regexp for variable length tags
Message-Id: <3k2q8aFs04q5U1@individual.net>
Jon Burroughs wrote:
> There will always be an "ADD" section, followed by 0 to 1 "REM"
> sections, followed by 0 to 1 "EQD" sections. For example:
> ADDxxxxxxxxREMyyyyyEQDzzzzz
>
> I'm trying to find a regular expression that will split this apart into
> separarate sections in one step.
Why regex?
my @rec;
while (<DATA>) {
chomp;
for my $key ( qw/EQD REM ADD/ ) {
if( (my $pos = index $_, $key) >= 0 ) {
$rec[$.-1]{$key} = substr $_, $pos+3;
substr $_, $pos, 100, '';
}
}
}
use Data::Dumper;
print Dumper \@rec;
__DATA__
ADDxxxxxxREMyyyyyEQDzzzzz
ADD2222REM666666
ADD7777777EQD8888
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 V10 Issue 8258
***************************************
