[22452] in Perl-Users-Digest
Perl-Users Digest, Issue: 4673 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Mar 6 11:11:28 2003
Date: Thu, 6 Mar 2003 08:10:11 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 6 Mar 2003 Volume: 10 Number: 4673
Today's topics:
Lightweight CGI module? <tore@aursand.no>
Re: Lightweight CGI module? <koos_pol@NO.nl.JUNK.compuware.MAIL.com>
Re: Lightweight CGI module? <tore@aursand.no>
Re: Lightweight CGI module? <koos_pol@NO.nl.JUNK.compuware.MAIL.com>
Re: Lightweight CGI module? <ubl@schaffhausen.de>
Re: Lightweight CGI module? <tore@aursand.no>
Re: Lightweight CGI module? <ubl@schaffhausen.de>
Re: Perl Script to Produce XML <bart.lateur@pandora.be>
Re: Perl Vs Python (Cameron Laird)
Re: Perl Vs Python <stephan.diehl@gmx.net>
Re: Print lines of file until certain string found? <barryk2@SPAM-KILLER.mts.net>
Re: printing hash values <barryk2@SPAM-KILLER.mts.net>
Re: printing hash values <spamtrap@nowhere.com>
Re: Retrieving a Perl variable from a MySQL database <nobull@mail.com>
Re: Retrieving a Perl variable from a MySQL database <nospam@nospam.org>
Re: Scripts in background <sfandino@yahoo.com>
Re: What is wrong with this piece of UDP server code? <nobull@mail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 06 Mar 2003 10:05:32 +0100
From: "Tore Aursand" <tore@aursand.no>
Subject: Lightweight CGI module?
Message-Id: <pan.2003.03.06.09.05.11.375765@aursand.no>
What's the status on lightweight CGI modules?
The reason I'm asking, is that I'm working on a project where we've come
to the part of tuning the application for best possible performance.
The CGI module (CGI.pm) _is_ a bottleneck here; it's far too heavy for
what we're using it for. In fact, only the CGI related features of the
CGI module is being used.
What we need is a module that takes care of _only_ the following:
o Getting request values (ie. the 'param()' method)
o Getting/setting cookies
o Printing out nice/valid HTTP headers
Apache::* can't be used here, as the application _will_ be run on lots of
different OS'es _and_ under lots of different web servers; Linux, Windows,
IIS, Apache, you name it.
A search on CPAN unveiled some potential modules, but all (ie. the few I
found) seems to be outdated (ie. not updated for a few years).
I've been playing around with extracting just the things we need from
CGI.pm and put it a standalone module. This resulted in some quite
"shocking" benchmark results, as only _initialising_ the standalone module
is 400-500 percent faster than CGI.pm. With "initialising" I really mean:
#!/usr/bin/perl
#
use strict;
use warnings;
use CGI (:cgi);
use CGI::Lightweight; # own module
my $cgi = CGI->new();
my $cgi_lw = CGI::Lightweight->new();
Question: What should I do? Is there ways of getting better performance
out of CGI.pm that I'm missing?
Thanks for any answer!
--
Tore Aursand <tore@aursand.no>
------------------------------
Date: Thu, 06 Mar 2003 10:54:14 +0100
From: Koos Pol <koos_pol@NO.nl.JUNK.compuware.MAIL.com>
Subject: Re: Lightweight CGI module?
Message-Id: <newscache$einbbh$th4$1@news.emea.compuware.com>
Tore Aursand wrote (Thursday 06 March 2003 10:05):
> What's the status on lightweight CGI modules?
I am using CGI::Minimal most of the time. It is still actively being
maintained. My experience with it is very positive.
> The reason I'm asking, is that I'm working on a project where we've come
> to the part of tuning the application for best possible performance.
>
> The CGI module (CGI.pm) _is_ a bottleneck here; it's far too heavy for
> what we're using it for. In fact, only the CGI related features of the
> CGI module is being used.
>
> What we need is a module that takes care of _only_ the following:
>
> o Getting request values (ie. the 'param()' method)
CGI::Minimal does that.
> o Getting/setting cookies
You can use CGI::Cookie (part of CGI) in a standalone fashion. It is only a
small module. It does some escaping/unescaping on the fly. If you don't
need that, you could borrow from CGI::Cookie and remove the unneeded code
for some performance improvement. Although I never benchmarked CGI::Cookie,
I can't imagine it to be a hog.
> o Printing out nice/valid HTTP headers
If you have a specific project, than the HTTP headers will most certainly be
standardized. Perhaps a redirect or someting. So why not keep your own set
of library functions for this purpose? A redirect header can be as simple
as:
sub redirect {
print "Location: " . url_encode(shift) . "\n\n";
}
HTH
--
KP
------------------------------
Date: Thu, 06 Mar 2003 12:45:06 +0100
From: "Tore Aursand" <tore@aursand.no>
Subject: Re: Lightweight CGI module?
Message-Id: <pan.2003.03.06.10.47.35.196177@aursand.no>
On Thu, 06 Mar 2003 10:54:14 +0100, Koos Pol wrote:
>> What's the status on lightweight CGI modules?
> I am using CGI::Minimal most of the time. It is still actively being
> maintained. My experience with it is very positive.
Hmm. I forgot to mention my experiences with that module, as I have
downloaded and installed it;
I have only tried to run it from the command line, and it just hung;
#!/usr/bin/perl
#
use strict;
use warnings;
use CGI::Minimal;
my $cgi = CGI::Minimal->new();
Running this from the command line causes the above script to just sit
there and - obviously - wait (?) for something. I've tried to apply some
parameters as well.
Any ideas?
>> o Getting/setting cookies
> You can use CGI::Cookie (part of CGI) in a standalone fashion.
Yeah, I could do that. Haven't tried it standalone yet, but I hope it
doesn't spend valuable milliseconds to initialise things I really don't
need. :)
>> o Printing out nice/valid HTTP headers
> If you have a specific project, than the HTTP headers will most
> certainly be standardized.
Well. This isn't a big problem, really, as the HTTP headers are really
simple to print out "manually". But it's nice to let the CGI module take
care of if nevertheless.
*testing CGI::Minimal again*
Ah. It seems to wait for input from STDIN when running from the command
line, which CGI.pm _does not_ do. Hmm. Ok. I might be able to live with
that, but how am I supposed to benchmark this thing?
Oh, well... :)
--
Tore Aursand <tore@aursand.no>
------------------------------
Date: Thu, 06 Mar 2003 13:00:52 +0100
From: Koos Pol <koos_pol@NO.nl.JUNK.compuware.MAIL.com>
Subject: Re: Lightweight CGI module?
Message-Id: <newscache$gdtbbh$6j4$1@news.emea.compuware.com>
Tore Aursand wrote (Thursday 06 March 2003 12:45):
>> You can use CGI::Cookie (part of CGI) in a standalone fashion.
>
> Yeah, I could do that. Haven't tried it standalone yet, but I hope it
> doesn't spend valuable milliseconds to initialise things I really don't
> need. :)
If you care for milliseconds, you have already chosen for a persisten
solution a la mod_perl or SpeedyCGI. In that case the initialization is a
one time (irrelevant) cost. Starting a fresh Perl each invocation in a
non-persistent environment will cost you unendlessly more.
--
KP
------------------------------
Date: Thu, 06 Mar 2003 13:55:25 +0100
From: Malte Ubl <ubl@schaffhausen.de>
Subject: Re: Lightweight CGI module?
Message-Id: <b47jmg$fv3$1@news.dtag.de>
Tore Aursand wrote:
> What's the status on lightweight CGI modules?
>
> The reason I'm asking, is that I'm working on a project where we've come
> to the part of tuning the application for best possible performance.
>
> The CGI module (CGI.pm) _is_ a bottleneck here; it's far too heavy for
> what we're using it for. In fact, only the CGI related features of the
> CGI module is being used.
>
> What we need is a module that takes care of _only_ the following:
>
> o Getting request values (ie. the 'param()' method)
> o Getting/setting cookies
> o Printing out nice/valid HTTP headers
>
> Apache::* can't be used here, as the application _will_ be run on lots of
> different OS'es _and_ under lots of different web servers; Linux, Windows,
> IIS, Apache, you name it.
Well, if you care about performance you should still use mod_perl under
Apache. Runs on Windows and Linux. Otherwise the load time of a module
is not your biggest problem. I dont know whether there is a solution to
speed up CGIs under IIS but there might very well be. Normal CGI
performance is ridiculous.
->malte
--
srand 108641088; print chr int rand 256 for qw<J A P H>
------------------------------
Date: Thu, 06 Mar 2003 16:35:01 +0100
From: "Tore Aursand" <tore@aursand.no>
Subject: Re: Lightweight CGI module?
Message-Id: <pan.2003.03.06.14.55.20.180876@aursand.no>
On Thu, 06 Mar 2003 13:55:25 +0100, Malte Ubl wrote:
> Well, if you care about performance you should still use mod_perl
> under Apache.
I care about performance, but I still don't have the chance to use
mod_perl in this case. I don't see that getting the best performance out
of your application as it is requires you to choose OS _and/or_ web
server.
I want the best of two worlds here, if possible; Being able to run under
any OS and web server (well, at least as many combinations as possible)
and an application giving the best performance as possible.
I'm _fully aware_ of the fact that my application always could run faster
if I was in a position where I could decide underlying software (and, in
some circumstances - which aren't applicable here/now -, the hardware).
In my case it's CGI.pm which is the "big satan", 'cause it seems to do a
lot of thing I don't need it to do.
> Otherwise the load time of a module is not your biggest problem.
Well - it is, actually. If I can have the module loaded most times (which
is the CGI module) loaded 400-500 percent faster each time, and maybe even
use less memory too, I call that "better performance".
> Normal CGI performance is ridiculous.
Yes, but I don't intend to have this run as "normal CGI". The application
is _fast_ as long as it is running on a platform where I can cache objects
(for example the database connection) in memory;
unless ( defined $dbh ) {
# connect
}
$self->{'_dbh'} = $dbh;
That's my programming style. Works on all platforms, and it gives better
performance as long as it's possible to creata a "semi-persistent memory
envirnoment" (or something like that).
I know that IIS + PerlEx and Apache + mod_perl does that.
--
Tore Aursand <tore@aursand.no>
------------------------------
Date: Thu, 06 Mar 2003 16:49:56 +0100
From: Malte Ubl <ubl@schaffhausen.de>
Subject: Re: Lightweight CGI module?
Message-Id: <b47ttn$6js$1@news.dtag.de>
Tore Aursand wrote:
> unless ( defined $dbh ) {
> # connect
> }
> $self->{'_dbh'} = $dbh;
>
> That's my programming style. Works on all platforms, and it gives better
> performance as long as it's possible to creata a "semi-persistent memory
> envirnoment" (or something like that).
>
> I know that IIS + PerlEx and Apache + mod_perl does that.
I though you couldnt use mod_perl? Whether you use Apache::DBI or your
technique above to cache data in static variables really doesnt matter
if you are running mod_perl and or PerlEX.
But you don't want to use Cache::Cache to cache your database handle, do
you? Also, be aware of problems with shared database connections and
transactions. You'll never know what your commiting.
mod_perl runs on almost any platform that Apache runs on. Why not use
mod_perl if the server is Apache?
->malte
------------------------------
Date: Thu, 06 Mar 2003 11:18:53 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: Perl Script to Produce XML
Message-Id: <ejbe6v4fd6ji1h8a9dfh5hgmak1e1hi8kn@4ax.com>
Michael Hill wrote:
>For some reason the stylesheets are not read from the cgi-bin directory,
>even when I make changes to the .htacccess file.
Apache probably doesn't allow it.
If you set it up so scripts can be run from any directory, then scripts
and plain files can reside side by side.
--
Bart.
------------------------------
Date: Thu, 06 Mar 2003 13:11:31 -0000
From: claird@lairds.com (Cameron Laird)
Subject: Re: Perl Vs Python
Message-Id: <v6ei83msg3mv19@corp.supernews.com>
In article <b3kkdl$fvl$1@news.peterlink.ru>,
Anton Muhin <antonmuhin@sendmail.ru> wrote:
>If you are interested, there is really nice book about text processing
>in Python (I don't remember URL :().
.
.
.
Sean McGrath's *XML Processing with Python*?
We need more Wiki pages ...
--
Cameron Laird <Cameron@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
------------------------------
Date: Thu, 6 Mar 2003 14:28:27 +0100
From: Stephan Diehl <stephan.diehl@gmx.net>
Subject: Re: Perl Vs Python
Message-Id: <b47icj$5fi$02$1@news.t-online.com>
Cameron Laird wrote:
> In article <b3kkdl$fvl$1@news.peterlink.ru>,
> Anton Muhin <antonmuhin@sendmail.ru> wrote:
>>If you are interested, there is really nice book about text processing
>>in Python (I don't remember URL :().
> .
> .
> .
> Sean McGrath's *XML Processing with Python*?
>
> We need more Wiki pages ...
or
http://gnosis.cx/TPiP/ (Text Processing in Python by David Mertz)
------------------------------
Date: Thu, 6 Mar 2003 08:12:49 -0600
From: Barry Kimelman <barryk2@SPAM-KILLER.mts.net>
Subject: Re: Print lines of file until certain string found?
Message-Id: <MPG.18d1135ca37f8c6598972f@news.mts.net>
In article <cad2e56c.0303050725.7cde98a4@posting.google.com>, A. M.
Schaer (mschaer@quantaservices.com) says...
> What I am trying to do is have Perl open a file, print the lines of
> the file until it encounters a marker, <!--perl-->, then stop
> printing; however the code below doesn't do that; it just keeps
> printing the first line of the file over and over again; I know
> there's a flaw in my logic somewhere, but I just can't see it.
>
> Thanks.
>
> #!/usr/bin/perl
> ###this doesnt do what I thought
> $file="calexample.html";
> open (CURRFILE, $file) ||
> die ("Cant open file");
> $var='<!--perl-->';
>
> while ($line= <CURRFILE>) {
> #!~ does not match
> #=~ matches
> until ($line =~/$var/i)
> {
> print $line;
> }
> }
>
while ( $line = <CURRFILE> ) {
if ( $line =~ m/${var}/i ) {
last;
}
print $line;
}
--
---------
Barry Kimelman
Winnipeg, Manitoba, Canada
email : bkimelman@hotmail.com
------------------------------
Date: Thu, 6 Mar 2003 08:22:10 -0600
From: Barry Kimelman <barryk2@SPAM-KILLER.mts.net>
Subject: Re: printing hash values
Message-Id: <MPG.18d1158e994112f2989730@news.mts.net>
In article <b09a22ae.0303051922.4654a4eb@posting.google.com>, david
(dwlepage@yahoo.com) says...
> If I have lexical values:
> my ($keyname, $keyvalue, $search, $replace);
> my %uid ();
>
> What would be the best way to print the contents of my hash once it
> has been populated? I am new to perl and am having a hard time
> visualizing the whole hash concept. Any suggestions?
> Thanks,
>
Several possibilities :
while ( ($key,$value) = each %uid ) {
print "$key --> $value\n":
}
print join(", ",map { $_ . " -> " . $uid{$_} }),"\n";
Or you could use the Data::Dumper module
--
---------
Barry Kimelman
Winnipeg, Manitoba, Canada
email : bkimelman@hotmail.com
------------------------------
Date: Thu, 06 Mar 2003 14:32:33 GMT
From: Andrew Lee <spamtrap@nowhere.com>
Subject: Re: printing hash values
Message-Id: <srme6vko3ai0t4db9vf1u5tj9un583cfft@4ax.com>
On 5 Mar 2003 19:22:43 -0800, dwlepage@yahoo.com (david) wrote:
>If I have lexical values:
>my ($keyname, $keyvalue, $search, $replace);
>my %uid ();
>
>What would be the best way to print the contents of my hash once it
>has been populated? I am new to perl and am having a hard time
>visualizing the whole hash concept. Any suggestions?
In addition to the suggestions posted, read the "Data: Hashes
(Associative Arrays)" section of perlfaq4. perldoc perlfaq4 -- it is a
3/4 down the page.
HTH
------------------------------
Date: 05 Mar 2003 20:43:07 +0000
From: Brian McCauley <nobull@mail.com>
Subject: Re: Retrieving a Perl variable from a MySQL database
Message-Id: <u9el5k96sf.fsf@wcl-l.bham.ac.uk>
"Christian Caron" <nospam@nospam.org> writes:
> "Hello, $username"
>
> If I define $username in my code and then retrieve the string from the
> database, when I print it, it prints:
>
> "Hello, $username"
>
> but I would want:
>
> "Hello, somename" (because $username can be assigned to any names).
This is FAQ: "How can I expand variables in text strings?"
Can you please advise us how the question could have been better
phrased so that you would not have missed it when you checked the FAQ?
(I'm assuming you were not too selfish/lazy to bother looking in the
FAQ before you posted)
Unfortuantely the answer in the FAQ is not very good. See numerous
previous treads discussing why by searching for the exact string "How
can I expand variables in text strings?".
> eval ($labels{not_authenticated_warning}->[$language]);
> print "$labels{not_authenticated_warning}->[$language]";
Go back and re-read "perldoc -f eval". eval() not not alter its argument.
You meant:
chop ( my $message = eval "<<END\n$labels{not_authenticated_warning}[$language]\nEND\n");
print $message;
> Anyone have an idea?
Alternatively you could use the solution offered in the FAQ which
avoids the danger of someone putting malicious Perl code into the
mesages.
If you want do it the eval() may but with Safe compartments see also
my String::Interpolate module.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Thu, 6 Mar 2003 10:40:33 -0500
From: "Christian Caron" <nospam@nospam.org>
Subject: Re: Retrieving a Perl variable from a MySQL database
Message-Id: <b47q5h$han2@nrn2.NRCan.gc.ca>
"Brian McCauley" <nobull@mail.com> wrote in message
news:u9el5k96sf.fsf@wcl-l.bham.ac.uk...
> "Christian Caron" <nospam@nospam.org> writes:
>
> > but I would want:
> >
> > "Hello, somename" (because $username can be assigned to any names).
>
> This is FAQ: "How can I expand variables in text strings?"
>
> Can you please advise us how the question could have been better
> phrased so that you would not have missed it when you checked the FAQ?
> (I'm assuming you were not too selfish/lazy to bother looking in the
> FAQ before you posted)
>
My English is not so bad, but I do not often use words like "expand".
Anyway, when I checked it, I saw it was related to regular expressions
(replace), not "interpolation" (is that the right word?), so I was confused
about how it could have helped me.
I think Ted's answer to use sprintf and/or printf was a good idea (it worked
for me).
Thanks everyone!
------------------------------
Date: Thu, 06 Mar 2003 10:51:36 +0000
From: =?ISO-8859-1?Q?Salvador_Fandi=F1o_Garc=EDa?= <sfandino@yahoo.com>
Subject: Re: Scripts in background
Message-Id: <3E672838.3030204@yahoo.com>
rsegovia wrote:
> Hi There,
>
> I need a perl script which has to run 5 perl scripts in parallel. How
> can I do that? Is it possible to handle the return codes of all of
> them?
use Proc::Queue size=>5, ':all';
my @pids;
for my $s (@script_names) {
push @pids, system_back($s)
}
%results=waitpids(@pids);
Bye,
- Salva
------------------------------
Date: 06 Mar 2003 08:34:07 +0000
From: Brian McCauley <nobull@mail.com>
Subject: Re: What is wrong with this piece of UDP server code?
Message-Id: <u9adg89640.fsf@wcl-l.bham.ac.uk>
Wei Weng <wweng@play.cs.columbia.edu> writes:
> Benjamin Goldberg <goldbb2@earthlink.net> wrote:
> > Wei Weng wrote:
>
> Now, how do I easily code something to receive a line of data from $server?
> The only thing I can come up with is something like:
>
> my $msg;
>
> while ($server->recv($next_byte, 1)) {
> if ($next_byte ne "\n") {
> $msg .= $next_byte;
> } else {
> $msg .= $next_byte;
> print ("A line: $msg");
> $msg = "";
> }
> }
>
> Undoubtedly, it is very ugly. I suspect there must be some other perl way to
> make this look elegant. :)
No because it is conceptually in error. UDP is a datagram protocol
not a byte stream. Each call to recv() will read as much of one
datagram as you allow it to and discard the rest.
You must make just a single call to recv() for each datagram.
Be aware that UDP datagrams may get reordered, lost, or duplicated.
This has nothing to do with Perl.
Perhaps you should consult the socket programming FAQ.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
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.
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 4673
***************************************
