[24233] in Perl-Users-Digest
Perl-Users Digest, Issue: 6425 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Apr 19 15:17:02 2004
Date: Mon, 19 Apr 2004 12:16:16 -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, 19 Apr 2004 Volume: 10 Number: 6425
Today's topics:
store a file in mysql <jcharth@hotmail.com>
Re: store a file in mysql <nospam@bigpond.com>
Re: store a file in mysql <mailing-list@gheift.de>
Re: store a file in mysql ctcgag@hotmail.com
Re: strange side-effect (bug?) in Net::SMTP (Ian D.)
Re: strange side-effect (bug?) in Net::SMTP <invalid-email@rochester.rr.com>
Re: strange side-effect (bug?) in Net::SMTP (Ian D.)
Re: sub should return modified value (Bart Van der Donck)
Re: sub should return modified value <jtc@shell.dimensional.com>
Re: sub should return modified value (Anno Siegel)
Re: sub should return modified value <bik.mido@tiscalinet.it>
threads / freeing memory (Stuart Kendrick)
Re: threads / freeing memory <thundergnat@hotmail.com>
Win32::Console with perl2exe -gui (PRSoftware)
Re: Win32::Console with perl2exe -gui <perlcdr@mail.rumania>
Re: Win32::Console with perl2exe -gui <1usa@llenroc.ude>
Re: Win32::Console with perl2exe -gui (PRSoftware)
Re: Win32::Console with perl2exe -gui (PRSoftware)
Re: Win32::Console with perl2exe -gui <1usa@llenroc.ude>
Writing fast(er) performing parsers in Perl <clint@0lsen.net>
Re: wrong exitstatus returned? (Anno Siegel)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 18 Apr 2004 00:20:29 GMT
From: joe <jcharth@hotmail.com>
Subject: store a file in mysql
Message-Id: <Xns94CECEDB599ADjosephthecianet@207.69.154.202>
hi i am trying to save a file in store in a $buff into a mysql database
this does not work. I found the execute_query in an example but i guess
that function is not part of dbi.
$dbhi = DBI->connect("DBI:mysql:mymail",root,freebsd);
my $sql8="insert into imgarchief(image)values('$buf')";
## my $sth8=Execute_Query($sql8);
my $roows8=$dbhi->do($sql8) || die "Error";
$dbhi->disconnect;
thanks
------------------------------
Date: Sun, 18 Apr 2004 11:08:59 +1000
From: Gregory Toomey <nospam@bigpond.com>
Subject: Re: store a file in mysql
Message-Id: <1206799.LXaQgodIM6@GMT-hosting-and-pickle-farming>
joe wrote:
> my $sql8="insert into imgarchief(image)values('$buf')";
When $buf gets expanded here, the statement will look like gobbldygook.
You will either need to use the mysql hex/unhex functions, or define a dbi
variable (not sure of the right terminology).
gtoomey
------------------------------
Date: Sun, 18 Apr 2004 09:36:01 +0200
From: Gerhard Heift <mailing-list@gheift.de>
Subject: Re: store a file in mysql
Message-Id: <c5tavd$meh$1@online.de>
joe wrote:
> hi i am trying to save a file in store in a $buff into a mysql database
> this does not work. I found the execute_query in an example but i guess
> that function is not part of dbi.
>
> $dbhi = DBI->connect("DBI:mysql:mymail",root,freebsd);
> my $sql8="insert into imgarchief(image)values('$buf')";
> ## my $sth8=Execute_Query($sql8);
> my $roows8=$dbhi->do($sql8) || die "Error";
>
> $dbhi->disconnect;
>
> thanks
# Making Connection
my $dbhi = DBI->connect("DBI:mysql:mymail",root,freebsd);
# Prepare the SQL-Statement
my $sql8 = "insert into imgarchief (image) values(?)";
my $sql = $dbhi->prepare($sql8);
# Execute it with the Buffer
$sql->execute($buf)
$dbhi->disconnect;
see man DBI
Gerhard
------------------------------
Date: 19 Apr 2004 02:49:05 GMT
From: ctcgag@hotmail.com
Subject: Re: store a file in mysql
Message-Id: <20040418224905.967$hG@newsreader.com>
joe <jcharth@hotmail.com> wrote:
> hi i am trying to save a file in store in a $buff into a mysql database
> this does not work. I found the execute_query in an example but i guess
> that function is not part of dbi.
Did you look in the documentation for DBI? execute_query is not there (in
modern versions anyway, I don't know it may have been there before and
removed), you don't have to guess. Maybe it was a user-defined sub defined
in the example you saw it in.
> $dbhi = DBI->connect("DBI:mysql:mymail",root,freebsd);
> my $sql8="insert into imgarchief(image)values('$buf')";
use bind variables. "...values(?)"
> ## my $sth8=Execute_Query($sql8);
Execute_Query is not the same thing as execute_query.
> my $roows8=$dbhi->do($sql8) || die "Error";
$dbhi->do($sql8,undef,$buf);
I tend to use RaiseError when I connect, thus I don't have to check each
time.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 16 Apr 2004 10:37:23 -0700
From: id2001@cablelabs.com (Ian D.)
Subject: Re: strange side-effect (bug?) in Net::SMTP
Message-Id: <1276a5f0.0404160937.73ca62f3@posting.google.com>
Bob Walton <invalid-email@rochester.rr.com> wrote in message news:<407F462E.6050803@rochester.rr.com>...
> Ian D. wrote:
>
> > This is perl, version 5.005_02 built for sun4-solaris
> >
> > I have an array that is wiped out when calling Net::SMTP->new. Here
> > is a debug from it. Note my array is intact at line 356, but after a
> > 'next', it is gone:
> >
> > main::check_mailservers(./conchk:356):
> > 356: $smtp = Net::SMTP->new('ondar',Timeout=>10,Debug=>0);
> > DB<2> x @MAILSERVERS
> > 0 ARRAY(0x6ea244)
> > 0 'sendmail'
> > 1 'ondar'
> > 2 'nobody@cablelabs.com'
> > 3 'nobody@localhost'
> > 4 150
>
>
> So, @MAILSERVERS is a one-element array, the value of which is a
> reference to another array with 5 elements. The first four of those
> elements have values which are various strings, and the fifth has a
> value which is an integer.
>
>
> > DB<3> n
> >
> > main::check_mailservers(./conchk:357):
> > 357: $td=tv_interval($t0);
> > DB<3> x @MAILSERVERS
> > 0 undef <======= WHAT THE HECK JUST HAPPENED???
>
>
> And now @MAILSERVERS is still a one-element array, but the value of it
> is now undef, rather than an array reference. This behavior could be
> explained if junk450.pl is the following program:
>
> D:\junk>type junk450.pl
> $MAILSERVERS[0]=[
> 'sendmail',
> 'ondar',
> 'nobody@cablelabs.com',
> 'nobody@localhost',
> 150,
> ];
> for $smtp (@MAILSERVERS){
> $smtp=undef;
> }
> --------------------------------
> and it is stepped through as follows:
> --------------------------------
>
> D:\junk>perl -d junk450.pl
>
> Loading DB routines from perl5db.pl version 1.19
> Editor support available.
>
> Enter h or `h h' for help, or `perldoc perldebug' for more help.
>
> main::(junk450.pl:1): $MAILSERVERS[0]=[
> main::(junk450.pl:2): 'sendmail',
> main::(junk450.pl:3): 'ondar',
> main::(junk450.pl:4): 'nobody@cablelabs.com',
> main::(junk450.pl:5): 'nobody@localhost',
> main::(junk450.pl:6): 150,
> main::(junk450.pl:7): ];
> DB<1> s
> main::(junk450.pl:8): for $smtp (@MAILSERVERS){
> DB<1> s
> main::(junk450.pl:9): $smtp=undef;
> DB<1> x @MAILSERVERS
> 0 ARRAY(0x1558798)
> 0 'sendmail'
> 1 'ondar'
> 2 'nobody@cablelabs.com'
> 3 'nobody@localhost'
> 4 150
> DB<2> n
> main::(junk450.pl:8): for $smtp (@MAILSERVERS){
> DB<2> x @MAILSERVERS
> 0 undef
> DB<3>
>
>
> Note the debug output which is identical to yours (except of course for
> the address of the anonymous array and the line numbers).
>
>
> >
> > A bug?
>
>
> Yes, in your code.
>
>
> >
> > Ian
> >
Well, it looks like new() is modifying $_. I use $_ as my control
variable in a foreach loop (implicitly), each time it points to an
element of @MAILSERVERS. Net::SMTP->new() seems to change $_, and
hence changes my array.
main::check_mailservers(./conchk:357):
357: Net::SMTP->new('ondar');
DB<11> x \$_
0 SCALAR(0x79cac8)
-> ARRAY(0x79ca98)
0 'sendmail'
1 'ondar'
2 'nobody@cablelabs.com'
3 'nobody@localhost'
4 150
DB<12> n
main::check_mailservers(./conchk:358):
358: $td=tv_interval($t0);
DB<12> x \$_
0 SCALAR(0x79cac8)
-> undef
If I use another variable to drive my loop, all is well. I don't
believe a subroutine should be modifying $_, should it?
Ian
------------------------------
Date: Sat, 17 Apr 2004 00:47:34 GMT
From: Bob Walton <invalid-email@rochester.rr.com>
Subject: Re: strange side-effect (bug?) in Net::SMTP
Message-Id: <40807AD5.8020803@rochester.rr.com>
Ian D. wrote:
> Bob Walton <invalid-email@rochester.rr.com> wrote in message news:<407F462E.6050803@rochester.rr.com>...
>
>>Ian D. wrote:
>>
>>
>>>This is perl, version 5.005_02 built for sun4-solaris
...
> If I use another variable to drive my loop, all is well. I don't
> believe a subroutine should be modifying $_, should it?
>
> Ian
>
As for whether a sub can modify $_, that is easily tested:
D:\junk>type junk450b.pl
$_='something';
sub1();
print "\$_ is now $_\n";
sub sub1{
$_='something else';
}
D:\junk>perl junk450b.pl
$_ is now something else
D:\junk>
And the answer is: Yes, a sub can modify $_. $_, along with all other
"punctuation" variables, is a true global -- if modified somewhere, it
is modified everywhere. A *good* *nice* sub would avoid using $_, or if
it does use it, would preserve the value of $_ and any other globals it
might change, through the use of local(). But how many folks actually
take the time and energy to do that in their subs (or even know they
should)? And how easy is it to mess up? Better to never count on $_
being preserved over a call. But nonetheless, a good module *should*
preserve globals. So I probably owe you an apology -- the bug probably
was in Net::SMTP. But it is still counting on a lot to assume that all
the stuff involved with a complicated module will actually preserve $_,
and it is still better to not count on it. What if the module takes an
execution path the testing didn't test, for example?
Hmmmmmmmm...a test program on my system does not duplicate your
behavior. Your Perl is pretty ancient (5.005_02) -- you might try a
modern version and see if the problem has been fixed. Here is a test
program almost identical to what you posted and its output:
D:\junk>type junk450a.pl
use Net::SMTP;
use Data::Dumper;
$MAILSERVERS[0]=[
'sendmail',
'ondar',
'nobody@cablelabs.com',
'nobody@localhost',
150,
];
foreach (@MAILSERVERS) {
my($type,$server,$from,$to,$defer,$blackout)=@$_;
$statfile=$MAILSERVER_STATE . $server;
print "Connecting to $type server $server...";
$t0=[gettimeofday];
# $failed=do_smtp($server,$from,$to);
#$smtp = Net::SMTP->new('ondar');
Net::SMTP->new('ondar');
print Dumper(@MAILSERVERS);
# @MAILSERVERS is gone now
# $td=tv_interval($t0); #commented because undefined
}
D:\junk>perl junk450a.pl
Connecting to sendmail server ondar...$VAR1 = [
'sendmail',
'ondar',
'nobody@cablelabs.com',
'nobody@localhost',
150
];
D:\junk>ver
Windows 98 [Version 4.10.2222]
D:\junk>perl -v
This is perl, v5.8.0 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)
Copyright 1987-2002, Larry Wall
Binary build 806 provided by ActiveState Corp. http://www.ActiveState.com
Built 00:45:44 Mar 31 2003
--
Bob Walton
Email: http://bwalton.com/cgi-bin/emailbob.pl
------------------------------
Date: 19 Apr 2004 06:30:59 -0700
From: id2001@cablelabs.com (Ian D.)
Subject: Re: strange side-effect (bug?) in Net::SMTP
Message-Id: <1276a5f0.0404190530.14302fab@posting.google.com>
Bob Walton <invalid-email@rochester.rr.com> wrote in message news:<40807AD5.8020803@rochester.rr.com>...
> Ian D. wrote:
>
> > Bob Walton <invalid-email@rochester.rr.com> wrote in message news:<407F462E.6050803@rochester.rr.com>...
> >
> >>Ian D. wrote:
> >>
> >>
> >>>This is perl, version 5.005_02 built for sun4-solaris
>
>
> ...
>
>
> > If I use another variable to drive my loop, all is well. I don't
> > believe a subroutine should be modifying $_, should it?
> >
> > Ian
> >
>
>
> As for whether a sub can modify $_, that is easily tested:
>
> D:\junk>type junk450b.pl
> $_='something';
> sub1();
> print "\$_ is now $_\n";
>
> sub sub1{
> $_='something else';
> }
>
> D:\junk>perl junk450b.pl
> $_ is now something else
>
> D:\junk>
>
> And the answer is: Yes, a sub can modify $_. $_, along with all other
> "punctuation" variables, is a true global -- if modified somewhere, it
> is modified everywhere. A *good* *nice* sub would avoid using $_, or if
> it does use it, would preserve the value of $_ and any other globals it
> might change, through the use of local(). But how many folks actually
> take the time and energy to do that in their subs (or even know they
> should)? And how easy is it to mess up? Better to never count on $_
> being preserved over a call. But nonetheless, a good module *should*
> preserve globals. So I probably owe you an apology -- the bug probably
> was in Net::SMTP. But it is still counting on a lot to assume that all
> the stuff involved with a complicated module will actually preserve $_,
> and it is still better to not count on it. What if the module takes an
> execution path the testing didn't test, for example?
>
>
> Hmmmmmmmm...a test program on my system does not duplicate your
> behavior. Your Perl is pretty ancient (5.005_02) -- you might try a
> modern version and see if the problem has been fixed. Here is a test
> program almost identical to what you posted and its output:
>
> D:\junk>type junk450a.pl
> use Net::SMTP;
> use Data::Dumper;
> $MAILSERVERS[0]=[
> 'sendmail',
> 'ondar',
> 'nobody@cablelabs.com',
> 'nobody@localhost',
> 150,
> ];
> foreach (@MAILSERVERS) {
> my($type,$server,$from,$to,$defer,$blackout)=@$_;
> $statfile=$MAILSERVER_STATE . $server;
> print "Connecting to $type server $server...";
> $t0=[gettimeofday];
> # $failed=do_smtp($server,$from,$to);
> #$smtp = Net::SMTP->new('ondar');
> Net::SMTP->new('ondar');
> print Dumper(@MAILSERVERS);
> # @MAILSERVERS is gone now
> # $td=tv_interval($t0); #commented because undefined
> }
>
> D:\junk>perl junk450a.pl
> Connecting to sendmail server ondar...$VAR1 = [
> 'sendmail',
> 'ondar',
> 'nobody@cablelabs.com',
> 'nobody@localhost',
> 150
> ];
>
> D:\junk>ver
>
> Windows 98 [Version 4.10.2222]
>
>
> D:\junk>perl -v
>
> This is perl, v5.8.0 built for MSWin32-x86-multi-thread
> (with 1 registered patch, see perl -V for more detail)
>
> Copyright 1987-2002, Larry Wall
>
> Binary build 806 provided by ActiveState Corp. http://www.ActiveState.com
> Built 00:45:44 Mar 31 2003
I agree that you shouldn't count on $_ across function calls, and I
have fixed that. As for the version of perl, I did try my code on a
newer version and did not have the same problem. So I really had 2
ways to fix the problem. The easiest, of course, was to just change
my control variable. Apology accepted. :-)
Ian
------------------------------
Date: 16 Apr 2004 08:10:07 -0700
From: bart@nijlen.com (Bart Van der Donck)
Subject: Re: sub should return modified value
Message-Id: <b5884818.0404160710.4c48fcc4@posting.google.com>
First, thanks for you code. It works great!
I find it difficult to agree with your statement however:
> However, argument-modifying functions are problematic and should
> normally be avoided. In languages like C, where a sub can only
> return one value, there often is not much choice if more than one
> result is needed from a sub. Perl subs can return as many values
> as they want to, so there is rarely a need for argument-modification.
In my experience, I have quite some need for this kind of approach.
I sometimes find myself in situations where I have a lot of variables
and they should all perform a same series of calculations.
E.g. when recalculating prices (discounts, adding % profit, currency
rates...), say:
&docalculations($priceppiece_1piece);
&docalculations($priceppiece_2pieces);
&docalculations($priceppiece_5pieces);
&docalculations($priceppiece_10pieces);
&docalculations($priceppiece_100pieces);
&docalculations($priceppiece_1piece_season);
&docalculations($priceppiece_2pieces_season);
&docalculations($priceppiece_5pieces_season);
&docalculations($priceppiece_10pieces_season);
&docalculations($priceppiece_100pieces_season);
etc.
In these cases, your sub would be perfect and the code gets far
clearer.
Why are argument-modifying functions problematic and to be avoided ?
Bart
------------------------------
Date: 16 Apr 2004 10:52:20 -0600
From: Jim Cochrane <jtc@shell.dimensional.com>
Subject: Re: sub should return modified value
Message-Id: <slrnc803q4.a59.jtc@shell.dimensional.com>
In article <b5884818.0404160146.421b1fc8@posting.google.com>, Bart Van der Donck wrote:
> Hello,
>
> Suppose this code:
>
> # ---------------------------
> $a=2;
> print "variable a has now value '$a'.\n";
> &addone($a);
> print "variable a has now value '$a'.\n";
> sub addone
> {
> $b=shift;
> $b++;
> return $b;
> }
> # ---------------------------
Pass a reference to the scalar to your subroutine instead of a copy:
#!/usr/bin/perl
use strict;
use warnings;
$a=2;
print "variable a is now '$a'.\n";
addone(\$a);
print "variable a is now '$a'.\n";
sub addone {
$b=shift;
$$b++;
return $b;
}
> gives as result:
>
> variable a has now value '2'.
> variable a has now value '2'.
>
> Is it possible to have $a at value '3' after executing the sub ?
> I tried with 'return', 'shift' and so, but couldn't find a way so that
> $a would directly be affected by what happens in sub &addone (without
> variable $a is mentionned in sub &addone obviously).
>
> Thanks for tips or hints
> Bart
--
Jim Cochrane; jtc@dimensional.com
[When responding by email, include the term non-spam in the subject line to
get through my spam filter.]
------------------------------
Date: 17 Apr 2004 08:22:31 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: sub should return modified value
Message-Id: <c5qpg7$h8g$1@mamenchi.zrz.TU-Berlin.DE>
Bart Van der Donck <bart@nijlen.com> wrote in comp.lang.perl.misc:
> First, thanks for you code. It works great!
Whom are you thanking? Give some attribution and some context.
> I find it difficult to agree with your statement however:
>
> > However, argument-modifying functions are problematic and should
> > normally be avoided. In languages like C, where a sub can only
> > return one value, there often is not much choice if more than one
> > result is needed from a sub. Perl subs can return as many values
> > as they want to, so there is rarely a need for argument-modification.
>
> In my experience, I have quite some need for this kind of approach.
> I sometimes find myself in situations where I have a lot of variables
> and they should all perform a same series of calculations.
> E.g. when recalculating prices (discounts, adding % profit, currency
> rates...), say:
> &docalculations($priceppiece_1piece);
> &docalculations($priceppiece_2pieces);
> &docalculations($priceppiece_5pieces);
> &docalculations($priceppiece_10pieces);
> &docalculations($priceppiece_100pieces);
> &docalculations($priceppiece_1piece_season);
> &docalculations($priceppiece_2pieces_season);
> &docalculations($priceppiece_5pieces_season);
> &docalculations($priceppiece_10pieces_season);
> &docalculations($priceppiece_100pieces_season);
> etc.
$priceppiece_1piece = docalculations($priceppiece_1piece);
...
would be clearer. Note missing "&" in front of the sub. I doubt that
it is needed here.
The explicit assignment is longer, but Perl has other means of saving typing.
$_ = docalculations( $_) for
$priceppiece_1piece,
$priceppiece_2pieces,
...
$priceppiece_100pieces_season;
is a first step, but really the related variables should be combined into
a hash:
my %priceppiece = (
1piece => <value>,
2_pieces => <value>,
...
100pieces_season => <value>,
);
Then the whole calculation becomes
$_ = docalculations( $_) for values %priceppiece.
> In these cases, your sub would be perfect and the code gets far
> clearer.
You mean shorter. An explicit assignment is always clearer than stealthily
changing a sub argument.
> Why are argument-modifying functions problematic and to be avoided ?
Because the change is invisible to the sub user. You must *know* from
the documentation (is there documentation?) that a sub does that. With
explicit assignment, there can be no doubt.
It also restricts the applicability of a sub. "docalculations( 2.50)" is an
error with argument-modifying "docalculations". "$x = docalculations( 2.50)"
could be okay.
Anno
------------------------------
Date: Sat, 17 Apr 2004 15:19:46 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: sub should return modified value
Message-Id: <ci32805o5ovhsrb99pv0f5an4rshp46coh@4ax.com>
On 16 Apr 2004 02:46:02 -0700, bart@nijlen.com (Bart Van der Donck)
wrote:
>Suppose this code:
>
># ---------------------------
Don't! Two important lines missing:
use strict;
use warnings;
Nothing to do with your problem, but you'd better know anyway...
>$a=2;
Don't! 'perldoc perlvar' && search '$a'.
>print "variable a has now value '$a'.\n";
>&addone($a);
^
Don't! Definitely obsolete && most probably not what you want.
>print "variable a has now value '$a'.\n";
>sub addone
>{
>$b=shift;
>$b++;
>return $b;
>}
># ---------------------------
>
>gives as result:
>
>variable a has now value '2'.
>variable a has now value '2'.
Correct!
You want
#!/usr/bin/perl -l
use strict;
use warnings;
my $u=2;
print 'variable $u has now value ', $u;
addone($u);
print 'variable $u has now value ', $u;
sub addone { $_[0]++ }
__END__
instead!
Michele
--
# This prints: Just another Perl hacker,
seek DATA,15,0 and print q... <DATA>;
__END__
------------------------------
Date: 18 Apr 2004 16:20:55 -0700
From: skendric@fhcrc.org (Stuart Kendrick)
Subject: threads / freeing memory
Message-Id: <62dbf7f1.0404181520.6389044d@posting.google.com>
i'm using threads to spawn a lot of tasks. the memory footprint of my
process keeps growing ... until the OS kills it. i was hoping that
detach or join would free memory ... but it looks like they don't. am
i missing something or am i looking at a bug?
perl -v
This is perl, v5.8.3 built for i686-linux-thread-multi
[...]
i'm running perl 5.8.3 under SuSE 8.2
test1.plx
#!/usr/bin/perl
use strict;
use threads;
use warnings;
our $big = 500;
our $i;
dome();
sub dome {
my $thr;
for ($i = 0; $i < $big; $i++) {
$thr = threads->new("test_me");
$thr->detach;
}
}
sub test_me {
print "Running thread $i\n";
}
when i run this program, "top" shows the memory footprint growing to
about 420MB (the box has 512MB total) ... and then the script
terminates with the message "Killed".
OK, so then I figured I'd try "joining" the things. I don't care
about the return value of "test_me" ... but hey, maybe "joining" frees
memory whereas "detaching" doesn't.
test2.plx
#!/usr/bin/perl
use strict;
use threads;
use warnings;
our $big = 5000;
our $i;
our $max = 30;
dome();
sub dome {
my $result;
my $thr;
for ($i = 0; $i < $big; $i++) {
$thr = threads->new("test_me");
$result = int($i / $max);
if ($i == $result * $max) {
print "Joining threads\n";
foreach $thr (threads->list) {
if ($thr->tid && !threads::equal($thr, threads->self)) {
$thr->join;
}
}
sleep 2;
}
}
}
sub test_me {
print "Running thread $i\n";
}
No difference -- the process grows to ~420MB and then terminates with
the message "Killed".
Insights?
--sk
Stuart Kendrick
FHCRC
------------------------------
Date: Mon, 19 Apr 2004 12:43:08 -0400
From: thundergnat <thundergnat@hotmail.com>
Subject: Re: threads / freeing memory
Message-Id: <40840199$0$16465$61fed72c@news.rcn.com>
Stuart Kendrick wrote:
> i'm using threads to spawn a lot of tasks. the memory footprint of my
> process keeps growing ... until the OS kills it. i was hoping that
> detach or join would free memory ... but it looks like they don't. am
> i missing something or am i looking at a bug?
>
> perl -v
>
> This is perl, v5.8.3 built for i686-linux-thread-multi
> [...]
>
> i'm running perl 5.8.3 under SuSE 8.2
>
> test1.plx
> #!/usr/bin/perl
> use strict;
> use threads;
> use warnings;
>
> our $big = 500;
> our $i;
>
> dome();
>
> sub dome {
> my $thr;
> for ($i = 0; $i < $big; $i++) {
> $thr = threads->new("test_me");
> $thr->detach;
> }
> }
>
> sub test_me {
> print "Running thread $i\n";
> }
>
> when i run this program, "top" shows the memory footprint growing to
> about 420MB (the box has 512MB total) ... and then the script
> terminates with the message "Killed".
>
You may want to try keeping your variables in a tighter scope. I made a
few changes to your first script and reduced the momory footprint by 90%
or better. (On my system at least.) Don't know whether this will be
helpful or not, just an observation.
#!/usr/bin/perl
use strict;
use threads;
use warnings;
my $big = 500;
dome();
sub dome {
for (0..$big) {
my $thr = threads->new(\&test_me, $_);
$thr->detach;
}
}
sub test_me {
my $i = shift;
print "Running thread $i\n";
}
------------------------------
Date: 17 Apr 2004 08:22:34 -0700
From: pr.software@nomade.fr (PRSoftware)
Subject: Win32::Console with perl2exe -gui
Message-Id: <90cbb77.0404170722.7062ea9@posting.google.com>
Hello,
I use perl2exe with the "-gui" option to create an "executable" (= a
single distribution file) without the DOS window.
But when my script has a problem, I can't have any report of the
problem.
I tried to use Win32::Console to open a new console to display the
problems but it doesn't work : the console window opens but the
standard output and input are not managed in this new console.
I tried a very simple program (myprog.pl) to check Win32::Console with
perl2exe :
use Win32::Console;
$CONSOLE = new Win32::Console;
$CONSOLE->Alloc;
print "hello\n";
<STDIN>;
sleep 10;
When I generate the .exe with "perl2exe myprog.pl" (without the -gui
option) all works fine : a console window opens, the text is displayed
and I have to press the Enter key to close the window.
But when I generate with "perl2exe -gui myprog.pl", the console window
appears but nothing is displayed and the standard input is not read
(the console is automatically closed after the 10 seconds sleep
delay).
I use :
- Win32::Console 0.031
- Perl 5.5.2 build 509
- Perl2Exe 5.03b
- Windows 98 SE.
Thanks for your help
PR
------------------------------
Date: Sat, 17 Apr 2004 21:19:32 GMT
From: perl coder <perlcdr@mail.rumania>
Subject: Re: Win32::Console with perl2exe -gui
Message-Id: <Ebhgc.59338$Lh2.27260@bignews1.bellsouth.net>
PRSoftware said:
> I use perl2exe with the "-gui" option to create an "executable" (= a
> single distribution file) without the DOS window.
>
> But when my script has a problem, I can't have any report of the
> problem.
[del]
> When I generate the .exe with "perl2exe myprog.pl" (without the -gui
> option) all works fine : a console window opens, the text is displayed
> and I have to press the Enter key to close the window.
>
> But when I generate with "perl2exe -gui myprog.pl", the console window
> appears but nothing is displayed and the standard input is not read
> (the console is automatically closed after the 10 seconds sleep
> delay).
I'm new to Windows programming, but from what I understand so far, there
are two different classes of binaries:
1. Pure GUI programs that don't have stdin/out/err file descriptors or
an associated command window (command.com or cmd.exe, depending on the
particular OS)
2. GUI or pure text programs that do have the standard file descriptors.
Such programs will spawn a command window if it wasn't launched from
one, and there is no way to prevent this (though the window can be
hidden from view immediately, but it will still flash momentarilly on
the screen).
I believe that the -gui option modifies some header bytes in the bundled
perl.exe to turn in into a pure GUI program (thus eliminating the
standard file descriptors).
DISCLAIMER: all or some of the above is possibly false! Like I said,
I'm new to the Windows world, and this is only what I've been able to
glean so far. I'd be very grateful if someone more knowledgeable in
these matters could either correct or confirm this info. ;-)
Anyway, instead of logging to a console, have you considered logging
your errors/debug info to a file instead? You can always open up a
shell window and read the log file at any time (just don't forget to set
autoflush on that filehandle so the output doesn't get buffered). Or
for that matter, you can always display the contents of that file in
your GUI program (frex, in a Tk::ROText window) if the data needs to be
easily accessible to end-users.
--
No crazy stuff in my email. ;-)
------------------------------
Date: 17 Apr 2004 22:13:39 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude>
Subject: Re: Win32::Console with perl2exe -gui
Message-Id: <Xns94CEB96BD99E0asu1cornelledu@132.236.56.8>
pr.software@nomade.fr (PRSoftware) wrote in
news:90cbb77.0404170722.7062ea9@posting.google.com:
> Hello,
>
> I use perl2exe with the "-gui" option to create an "executable" (= a
> single distribution file) without the DOS window.
>
> But when my script has a problem, I can't have any report of the
> problem.
>
> I tried to use Win32::Console to open a new console to display the
> problems but it doesn't work : the console window opens but the
> standard output and input are not managed in this new console.
>
> I tried a very simple program (myprog.pl) to check Win32::Console with
> perl2exe :
>
> use Win32::Console;
> $CONSOLE = new Win32::Console;
> $CONSOLE->Alloc;
> print "hello\n";
> <STDIN>;
> sleep 10;
I will suggest actually reading the docs for Win32::Console. I had never
used it before and it didn't take much looking to figure out.
use strict;
use warnings;
use Win32::Console;
my $STDOUT = new Win32::Console(STD_OUTPUT_HANDLE);
$STDOUT->Alloc;
$STDOUT->Display;
$STDOUT->Write("Press any key to exit\n");
my $STDIN = new Win32::Console(STD_INPUT_HANDLE);
$STDIN->Alloc;
while( 1 ) {
my @event = $STDIN->Input;
last if $event[0] == 1;
sleep 1;
}
> I use :
> - Win32::Console 0.031
> - Perl 5.5.2 build 509
Is that Perl version correct?
Sinan.
--
A. Sinan Unur
1usa@llenroc.ude (reverse each component for email address)
------------------------------
Date: 18 Apr 2004 23:52:47 -0700
From: pr.software@nomade.fr (PRSoftware)
Subject: Re: Win32::Console with perl2exe -gui
Message-Id: <90cbb77.0404182252.1f38f9c7@posting.google.com>
"A. Sinan Unur" <1usa@llenroc.ude> wrote in message news:<Xns94CEB96BD99E0asu1cornelledu@132.236.56.8>...
> pr.software@nomade.fr (PRSoftware) wrote in
> news:90cbb77.0404170722.7062ea9@posting.google.com:
>
> > Hello,
> >
> > I use perl2exe with the "-gui" option to create an "executable" (= a
> > single distribution file) without the DOS window.
> >
> > But when my script has a problem, I can't have any report of the
> > problem.
> >
> > I tried to use Win32::Console to open a new console to display the
> > problems but it doesn't work : the console window opens but the
> > standard output and input are not managed in this new console.
> >
> > I tried a very simple program (myprog.pl) to check Win32::Console with
> > perl2exe :
> >
> > use Win32::Console;
> > $CONSOLE = new Win32::Console;
> > $CONSOLE->Alloc;
> > print "hello\n";
> > <STDIN>;
> > sleep 10;
>
> I will suggest actually reading the docs for Win32::Console. I had never
> used it before and it didn't take much looking to figure out.
>
> use strict;
> use warnings;
>
> use Win32::Console;
>
> my $STDOUT = new Win32::Console(STD_OUTPUT_HANDLE);
> $STDOUT->Alloc;
> $STDOUT->Display;
> $STDOUT->Write("Press any key to exit\n");
>
> my $STDIN = new Win32::Console(STD_INPUT_HANDLE);
> $STDIN->Alloc;
>
> while( 1 ) {
> my @event = $STDIN->Input;
> last if $event[0] == 1;
> sleep 1;
> }
>
> > I use :
> > - Win32::Console 0.031
> > - Perl 5.5.2 build 509
>
> Is that Perl version correct?
>
> Sinan.
Thanks a lot : your solution is very good : probably I didn't read the
doc very well ;-(
PR
------------------------------
Date: 19 Apr 2004 02:17:43 -0700
From: pr.software@nomade.fr (PRSoftware)
Subject: Re: Win32::Console with perl2exe -gui
Message-Id: <90cbb77.0404190117.513e942b@posting.google.com>
Oops, I think I cried for victory a bit too early ...
In fact, the code of A. Sinan Unur works fine if the "executable" is
launched in a command window (the output console opens and the text is
displayed).
But if it is directly launched by double-clicking the .exe in the
explorer, the output console is displayed but nothing is written in
... Unfortunately it is the way my code is executed :-(((
Perhaps it is a problem with attributes of the created console but I
can't understand their use ...
What's the matter ???
Thanks
PR
------------------------------
Date: 19 Apr 2004 09:56:23 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude>
Subject: Re: Win32::Console with perl2exe -gui
Message-Id: <Xns94D03C6C46A2asu1cornelledu@132.236.56.8>
pr.software@nomade.fr (PRSoftware) wrote in
news:90cbb77.0404190117.513e942b@posting.google.com:
> Oops, I think I cried for victory a bit too early ...
>
> In fact, the code of A. Sinan Unur works fine if the "executable" is
> launched in a command window (the output console opens and the text is
> displayed).
>
> But if it is directly launched by double-clicking the .exe in the
> explorer, the output console is displayed but nothing is written in
> ... Unfortunately it is the way my code is executed :-(((
It works if I compile it with the line:
perl2exe t.pl
Then, double-clicking on the resulting t.exe file opens a single console
window with the "Press any key to exit" message. Pressing any key results
in the console window being closed and the program terminates.
The whole thing runs very slowly, however. (Win XP-Pro, 1 Ghz Celeron,
512 Mb RAM).
> Perhaps it is a problem with attributes of the created console but I
> can't understand their use ...
>
> What's the matter ???
I do not know. perl2exe is commercial software. Have you asked
IndigoStar?
--
A. Sinan Unur
1usa@llenroc.ude (reverse each component for email address)
------------------------------
Date: Mon, 19 Apr 2004 10:04:52 GMT
From: Clint Olsen <clint@0lsen.net>
Subject: Writing fast(er) performing parsers in Perl
Message-Id: <slrnc87923.rg7.clint@poly.0lsen.net>
I've been working on a parser project to translate from a proprietary
hardware description language into something more industry standard, and
I've found some peculiar performance characteristics in Perl. Hopefully
someone can shed a bit more light on the subject. I've been using Perl
5.8.2, so my findings should be pretty relevant to current users.
Since this project is fairly complex, I'm using Parse::Yapp to handle the
parsing functionality. Perl's natural pattern matching ability makes it
pretty simple to code up an lexical analyzer by hand.
After running the profiler on the tool, I found that over 70% of the
runtime was being taken up in the scanner (the function actually scanning
tokens from the file). So, I decided to start there.
The scanner is pretty straightforward. I precompiled patterns using qr//o
with all the reserved keywords and special patterns for tokens in the
language. I reused these patterns in m// like so:
#
# Precompile patterns.
#
my $INTEGER = qr/(-?\d+)/o;
...
...
...
elsif (/\G$INTEGER/ogc) {
return [ 'INTEGER', $1 ];
}
There are many such patterns like this, some of them quite a bit more
complicated than integers. I used /gc and the assertion \G in all the
patterns since this was mentioned in the Perl documentation for writing
lex-like scanners.
For file I/O, I snarfed the entire contents into a scalar by adjusting $/:
sub read_file {
if (open FILE, '<', $_[0]) {
local $/ = undef;
my $data = <FILE>;
\$data;
}
}
Using this method seems popular among Perl users and eliminates file i/o
issues from the programmer.
Unfortunately, the result of this combination was pretty sluggish
performance. To read a nominal file which involves considerable file
inclusion takes slightly over a minute of runtime. There is also quite a
bit of system overtime registered by the time(1) command.
The first thing I tried was to eliminate the reliance on the zero-width
assertion \G and /gc on the search. I changed all the calls from using m//
to using s// and just stripped off the leading text as I matched it. The
result of that was a fair amount of savings - around 35% runtime savings.
Encouraged by that result, I decided to take it one step further and
experiment with more traditional lexer file i/o techniques. I assumed Perl
just uses mmap() to read entire files into a scalar, but I'm not entirely
sure what happens behind the scenes without diving into the source.
I tried just opening the file and using Perl's read() call to snarf the
data in 8K chunks, using the following fill function:
sub fill {
my ($buf) = @_;
my $bufin;
$$buf[2] = (read($$buf[0], $bufin, 8192) != 8192);
$$buf[1] .= $bufin;
}
The buf object is an array triplet of a file descriptor, scalar containing
the file data currently read, and EOF indicator. Fill() isn't called until
the length of the current buffer has fallen below 256 characters. So, in
essence this just makes an assumption that no token is greater than 256
characters.
The result of this change produced dramatically better results. The
runtime dropped to no more than 15 seconds! Just to get a sense of how
much system call overhead there was, I ran strace on each of them:
-rw-r--r-- 1 clint users 8994621 Apr 16 17:00 /tmp/parse1.trc
-rw-r--r-- 1 clint users 3625534 Apr 16 17:00 /tmp/parse2.trc
-rw-r--r-- 1 clint users 976800 Apr 17 11:13 /tmp/parse3.trc
The first is the original program reading the entire file(s) in as scalars
and using the zero-width assertion (\G), the second was substituting s//
for m//gc, and the last was the change to the manual buffering. I'm pretty
shocked at the speed differences between these changes. I wouldn't call my
manual buffering very sophisticated, either. But it is certainly worth it
since it yields over a 75% speed improvement on average.
-Clint
------------------------------
Date: 19 Apr 2004 13:26:37 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: wrong exitstatus returned?
Message-Id: <c60k2d$5lo$1@mamenchi.zrz.TU-Berlin.DE>
Frank de Bot <ppi_doesnt_like_@spam_inhis_email_searchy.net> wrote in comp.lang.perl.misc:
> > Frank de Bot wrote:
[please don't top-post. lines rearranged]
> >> I have a perl script server which works with fork. But I got a problem
> >> with executing commands from a child which handles a request. The
> >> exitstatus $? is always -1 I've tried execute commands with system and
> >> `command` but nothing matters.
> >
> >
> > Linux?
> > Win32?
> > Win32 with cygwin?
> Linux
>
> I found out that $? won't function if the SIGCHLD handler is set, which
> it is. I've found a very rude way to solve this problem by adding the
> exit status via another script in front of the stdout of command I want
> to run.
> But I don't realy like this method, any suggestion?
If you have a handler, use it. See "perldoc -f waitpid".
Anno
------------------------------
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 6425
***************************************
