[26051] in Perl-Users-Digest
Perl-Users Digest, Issue: 8259 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jul 19 06:05:26 2005
Date: Tue, 19 Jul 2005 03:05:05 -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 Tue, 19 Jul 2005 Volume: 10 Number: 8259
Today's topics:
Re: "Can't return a temporary from lvalue subroutine... <tassilo.von.parseval@rwth-aachen.de>
Re: Earthquake Forecasting Program July 11, 2005 <edgrsprj@ix.netcom.com>
How to call an internal CGI subroutine? <jwxxxxx@yahoo.com>
Re: How to call an internal CGI subroutine? xhoster@gmail.com
Re: How to call an internal CGI subroutine? <kkeller-usenet@wombat.san-francisco.ca.us>
Re: ithreads & memory (bler)
Re: ithreads & memory xhoster@gmail.com
Re: Memory leak in loop when not using "my" - why? xhoster@gmail.com
Re: Memory leak in loop when not using "my" - why? <sini@removemegmx.de>
Re: PAR 0.89 + Socket + ASP 5.8.7 = PL_memory_wrap <tassilo.von.parseval@rwth-aachen.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 19 Jul 2005 07:52:52 +0200
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: "Can't return a temporary from lvalue subroutine..."
Message-Id: <slrnddp59k.s2.tassilo.von.parseval@localhost.localdomain>
Also sprach J Krugman:
> 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:
>>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.
Not at all. If that was the case, you couldn't store a tied scalar in
an array or hash thusly:
tie my $scalar => 'Class';
$hash{ key } = $scalar;
>>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).
It can be done quite easily:
sub var : lvalue {
my $self = shift;
tie $self->{_var_} => 'Class';
$self->{_var_};
}
Also, it's not at all true that only the last statement in a
lvalue-function is executed. It's just so that the last statement has to
be the (non-temporary) scalar you want to assign to.
>>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've read this paragraph a few times now. I am not quite sure either
what Anno is referring to.
>>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?
You can overload the hash-dereference operator for a class:
package Class;
use overload '%{}' => sub {
my $self = shift;
$self->[0];
};
sub new {
my ($class) = @_;
bless [
{
key1 => 'value1',
key2 => 'value2',
},
] => $class;
}
package main;
use Data::Dumper;
my $obj = Class->new;
print Dumper $obj;
%$obj = (key3 => 'value3');
print Dumper $obj;
__END__
$VAR1 = bless( [
{
'key2' => 'value2',
'key1' => 'value1'
}
], 'Class' );
$VAR1 = bless( [
{
'key3' => 'value3'
}
], 'Class' );
By returning a reference to a tied-hash in the overload-handler of '%{}'
one could then control what is stored in $self->[0].
Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
------------------------------
Date: Tue, 19 Jul 2005 02:53:49 GMT
From: "edgrsprj" <edgrsprj@ix.netcom.com>
Subject: Re: Earthquake Forecasting Program July 11, 2005
Message-Id: <1XZCe.1076$6f.1020@newsread3.news.atl.earthlink.net>
"Bob Officer" <bobofficers@invalid.net> wrote in message
news:83und1pv3du700os4oug71i6ks242ojqfp@4ax.com...
> On Mon, 11 Jul 2005 08:31:31 GMT, in sci.geo.earthquakes, "edgrsprj"
> <edgrsprj@ix.netcom.com> wrote:
>
> >PROPOSED EARTHQUAKE FORECASTING
> >COMPUTER PROGRAM DEVELOPMENT EFFORT
> demand that public monies be giving to him to support his "research".
>
People around the world can download and use my data and computer programs
for free, subject to normal copyright terms. For example, they cannot claim
that they are the original developers of the computer programs.
Where this person gets the stuff that he posts to Newsgroups is beyond me.
------------------------------
Date: Tue, 19 Jul 2005 00:04:00 -0400
From: James White <jwxxxxx@yahoo.com>
Subject: How to call an internal CGI subroutine?
Message-Id: <pan.2005.07.19.04.04.00.763812@yahoo.com>
This is something that my books don't seem to address.
How are subroutines called within a single CGI script? In the partial
example below, clicking on the save button will normally attempt to run
the cgi script called "xxx". Is there a way to cause the button to call
the local routine at the bottom?
Thanks
James W
#!/usr/bin/perl -wT
use CGI ':standard';
#first build a form of some kind.
print <<START_OF_HTML;
Content-type: text/html
<HTML>
...etc html stuff
<form method=post action="<xxx>">
<input type="submit" name="save_file" value="Save">
</form>
...etc closing html stuff
</HTML>
START_OF_HTML
sub someroutine {
do something
}
------------------------------
Date: 19 Jul 2005 05:29:40 GMT
From: xhoster@gmail.com
Subject: Re: How to call an internal CGI subroutine?
Message-Id: <20050719012940.606$gS@newsreader.com>
James White <jwxxxxx@yahoo.com> wrote:
> This is something that my books don't seem to address.
>
> How are subroutines called within a single CGI script?
The same way they are called in any other Perl program (assuming your CGI
script is written in Perl.)
> In the partial
> example below, clicking on the save button will normally attempt to run
> the cgi script called "xxx". Is there a way to cause the button to call
> the local routine at the bottom?
Local to what? The submit button is in the web browser, on the client
machine. The CGI script is attached to the web server, on the server
machine. What is local to whom?
>
> Thanks
> James W
>
> #!/usr/bin/perl -wT
> use CGI ':standard';
>
> #first build a form of some kind.
> print <<START_OF_HTML;
> Content-type: text/html
>
> <HTML>
> ...etc html stuff
> <form method=post action="<xxx>">
> <input type="submit" name="save_file" value="Save">
> </form>
> ...etc closing html stuff
> </HTML>
>
> START_OF_HTML
>
> sub someroutine {
> do something
> }
You could write someroutine in javascript, and print out the javascript
code in the html response, and us an OnClick (or something like that)
directive on the submit button to invoke the javascript.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Mon, 18 Jul 2005 22:27:08 -0700
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: How to call an internal CGI subroutine?
Message-Id: <difuq2xdfb.ln2@goaway.wombat.san-francisco.ca.us>
In article <pan.2005.07.19.04.04.00.763812@yahoo.com>, James White wrote:
> This is something that my books don't seem to address.
>
> How are subroutines called within a single CGI script? In the partial
> example below, clicking on the save button will normally attempt to run
> the cgi script called "xxx". Is there a way to cause the button to call
> the local routine at the bottom?
Sure: have the action refer to the original script, have the
script test for the existence of a save_file parameter key, and
if it exists, call someroutine() (and otherwise do a default
action, like presenting the form). Read perldoc CGI for some
help on doing this.
> #!/usr/bin/perl -wT
> use CGI ':standard';
use strict;
use warnings; # instead of -w, if your Perl supports it
> #first build a form of some kind.
> print <<START_OF_HTML;
> Content-type: text/html
You may also want to investigate using CGI methods to print
all this stuff, too. In many cases it makes for cleaner code
(and, for forms with pull-downs, scrollboxes, and other list-like
items, has nice little shortcuts).
>
> <HTML>
> ...etc html stuff
> <form method=post action="<xxx>">
> <input type="submit" name="save_file" value="Save">
> </form>
> ...etc closing html stuff
> </HTML>
>
> START_OF_HTML
>
>
> sub someroutine {
> do something
> }
--keith
--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom
see X- headers for PGP signature information
------------------------------
Date: Tue, 19 Jul 2005 02:31:46 +0000 (UTC)
From: "Micha³ Lesiak (bler)" <michalusenet@blaair.eu.org>
Subject: Re: ithreads & memory
Message-Id: <Xns96982E126DEC8michalusenetblaaireu@193.110.122.97>
xhoster@gmail.com wrote in news:20050718183821.191$VB@newsreader.com:
> 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.
It's all the same when I use "sleep 1" and "sleep 4", respectively. It just
take longer. As I said, it may take weeks but it does happen, once the
memory for a thread is allocated it's released only when the program quits.
--
M.
------------------------------
Date: 19 Jul 2005 04:23:27 GMT
From: xhoster@gmail.com
Subject: Re: ithreads & memory
Message-Id: <20050719002327.291$6y@newsreader.com>
"Micha³ Lesiak (bler)" <michalusenet@blaair.eu.org> wrote:
> xhoster@gmail.com wrote in news:20050718183821.191$VB@newsreader.com:
>
> > 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.
>
> It's all the same when I use "sleep 1" and "sleep 4", respectively.
I'm not sure that that precludes this possibility.
> It
> just take longer. As I said, it may take weeks but it does happen, once
> the memory for a thread is allocated it's released only when the program
> quits.
I can't produce the problem on 5.8.0 with threads 0.99
(or maybe I just am not waiting long enough).
Are the threads hanging around holding memory, or is the memory building
up in the parent process? (e.g. does:
ps -efl | fgrep <progname>
show an ever increasing number of processes, or just one or two processes
with increasing memory use?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 19 Jul 2005 05:20:43 GMT
From: xhoster@gmail.com
Subject: Re: Memory leak in loop when not using "my" - why?
Message-Id: <20050719012043.504$e5@newsreader.com>
Sinisa Susnjar <sini@removemegmx.de> wrote:
> 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
What was leaking memory? The above code, or the larger program you
abstracted it from?
> 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;
> }
I find it very hard to believe that, of the code you showed, one leaks
and the other doesn't.
>
> 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.
How could you fit a hash with >50 million key-value pairs into 70MB of
memory?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Tue, 19 Jul 2005 07:58:14 +0200
From: Sinisa Susnjar <sini@removemegmx.de>
Subject: Re: Memory leak in loop when not using "my" - why?
Message-Id: <42dc9677_1@news.arcor-ip.de>
xhoster@gmail.com wrote:
> Sinisa Susnjar <sini@removemegmx.de> wrote:
>
>>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
>
>
> What was leaking memory? The above code, or the larger program you
> abstracted it from?
>
The above code. The larger program was filled with multiple
code-snippets like the above.
>
>>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;
>>}
>
>
> I find it very hard to believe that, of the code you showed, one leaks
> and the other doesn't.
I could not believe it myself! I tried to reproduce it @home under x86
Linux with perl 5.8.3 and I couldn't! I will try downloading the newest
perl version today at my jobs place and see if that makes a difference...
>
>
>>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.
>
>
> How could you fit a hash with >50 million key-value pairs into 70MB of
> memory?
Ok ok, you cought me... it was more like 128MB - the 70MB was from 30
mio records... (plus: I do not think the key/value pairs are all unique)
>
> Xho
>
------------------------------
Date: Tue, 19 Jul 2005 10:54:23 +0200
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: PAR 0.89 + Socket + ASP 5.8.7 = PL_memory_wrap
Message-Id: <slrnddpftv.oo.tassilo.von.parseval@localhost.localdomain>
Also sprach John Bokma:
> So what I did:
>
> cd C:\Archivos de programa\Microsoft Visual C++ Toolkit 2003
> run Visual C++ Toolkit 2003 Command Prompt
>
> in this "prompt":
>
> cd C:\Archivos de programa\Microsoft Platform SDK
> setenv /XP32 /RETAIL
> cd C:\......\PAR-0.89.tar\PAR-0.89
>
> Set Lib=
> C:\Archivos de programa\Microsoft Visual Studio .NET 2003\Vc7\lib;%Lib%
> nmake clean
> perl Makefile.PL
> nmake
> nmake install
>
>
> And... works!
The Microsoft compiler kid comes with a little batch-file, vcvars32.bat,
somewhere in the compiler's bin/ directory. If you run this file prior
to any compilational work, the environment should be set correctly. You
even need this when using the dedicated Visual C++ command prompt as I
learnt myself two days ago.
Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
------------------------------
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 8259
***************************************
