[23120] in Perl-Users-Digest
Perl-Users Digest, Issue: 5341 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Aug 10 14:06:13 2003
Date: Sun, 10 Aug 2003 11:05:20 -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 Sun, 10 Aug 2003 Volume: 10 Number: 5341
Today's topics:
Re: A simple doubt :-/ <wwonko@rdwarf.com>
connecting to a database (with no web server) <member32241@dbforums.com>
Re: connecting to a database (with no web server) <noreply@gunnar.cc>
Re: connecting to a database (with no web server) (Tad McClellan)
Re: connecting to a database (with no web server) <NOSPAM@bigpond.com>
Re: extract strings between alternating text <noreply@gunnar.cc>
Re: extract strings between alternating text <REMOVEsdnCAPS@comcast.net>
Re: extract strings between alternating text (Tad McClellan)
Re: help needed making unicode entities <flavell@mail.cern.ch>
Re: Location problem <flavell@mail.cern.ch>
Re: Location problem <REMOVEsdnCAPS@comcast.net>
Re: Location problem <flavell@mail.cern.ch>
Messages from FreezeThaw of a DBI handle <wwonko@rdwarf.com>
Re: Output to (X)HTML <me@home.com>
Re: perl DBI <wwonko@rdwarf.com>
Re: Perl Math Syntax <wwonko@rdwarf.com>
Problem with FindBin and taint mode under Windows <wwonko@rdwarf.com>
Re: Script "terminates" when processing large numbers o <wwonko@rdwarf.com>
Script displays in dos window, not browser <joe@burnettworks.com>
Re: Script displays in dos window, not browser <jurgenex@hotmail.com>
Re: Web hosts and mod_perl <wwonko@rdwarf.com>
Re: <bwalton@rochester.rr.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 8 Aug 2003 19:20:49 +0000 (UTC)
From: Louis Erickson <wwonko@rdwarf.com>
Subject: Re: A simple doubt :-/
Message-Id: <bh0t6h$a1e$1@holly.rdwarf.com>
Brian McCauley <nobull@mail.com> wrote:
: viijv@thedifferenZ.com (Vijoy Varghese) writes:
:> The programs written in 'C' language *.c is compiled...
: [snip how compiled lanuages work ]
:> Now, a CGI program written in Perl, *.cgi there is no compilation or
:> linking. That is each time we try to activate this program the Perl
:> interpreter have to convert it to the *.exe format(or directly to hard
:> core machine language of 0's and 1's?) and this process is repeated
:> during all activation of the *.cgi script, right?
: Actually in converts it into an intermediate form - Perl byte code.
: The Perl by code is then interpreted by a virtual machine.
:> So this is a kind of overhead when a same script is activated some
:> 1000 time in a minute, right? But still people are using Perl for CGI
:> scripting, why?
One reason people use Perl for CGI is because it is easier and faster
to write correct CGI programs with it. It's also easier and faster
to debug, maintain and extend Perl CGI program than most C programs.
Perl provides a lot of very good tools for CGI, and helps you not make
the common encoding/decoding mistakes, as well as the C programmer's
constant battle with memory allocation. You're rarely going to have a
buffer overflow in Perl. If your C program does... your machine can be
taken over by malicious users who know how to use a segmentation violation
to their own benefit.
I've also been much more successful at finding Perl modules to help me
write code quickly than I have been at finding C libraries to help me
do similar things quickly. Even if there are libraries, they're harder
to call, install, and use than a Perl module. And usually not as well
documented.
Also, a Perl program is often good enough. I have many small customers
here who aren't in the realm of 1000 page hits a month, much less 1000
a minute. I can launch the Perl interpreter 1000 times a month, no problem.
If you get in to a load situation where you need the incredibly high
performance, you need to be rethinking your use of CGI, regardles if
it's Perl or otherwise. Hopefully, by the time you're there, you'll
have the budget to do so.
These things mean your CGI programs are more secure, and cheaper to develop.
Both of those are important concerns to many people. =)
: Be aware that a lot of the overhead is also in the process creation
: overhead. Even if you use native executable CGIs you still have to
: pay.
I've got an old CGI app here written in C. It would take maybe a 10th
of a second longer for it to deliver pages were it written in Perl.
Nobody would notice the difference. But, because it's in C, I don't
ever want to touch it, because that's harder.
: If you want speed one way is to load your web server apps into the
: web server itself. For example, in Apache you do this with Apache
: loadable modules.
:> Yes, Perl is fun, its always fun to program using a
:> language which remind us more of a 'natural language' rather than a
:> 'programming language'. But still, why don't some one make a
:> 'Compiled Perl' with all features of current Perl, but which can be
:> compiled to machine language, so that there is no need to 'translate'
:> it each time its activated.
: Attempts have been made but they've not managed to produce significant
: speed improvements.
:> Or is there is already one available?
: There are, AFAIK, no production-ready Perl compilers or byte-code loaders.
Even if there are, converting Perl to native machine code won't often
get much more improvement than a C program. The way Perl runs, allowing
buffers to grow, and keeping reference counts will ALWAYS have more overhead
than a C program's bare-metal memory managment, unless the C programmer has
gone to a lot of work to do that themselves... and then it may as well be
in Perl, speed-wise.
And, even if your code is running in native machine code, you still have to
call the same library functions, which also depend on the same sort of
forgiving and flexible constructs.
The real speed gain in C is not the native machine code. The real speed gain
is the rigid and manually managed memory handling, and the fact that a
human can go in and optimize that all to death where it needs to be.
(And, usually where it isn't.) A C program does less than a Perl program.
<snipped much goodness about mod_perl>
: Note: there are other alternatives to CGI that also eleminiate the
: process creation-per-transation overhead, e.g. FastCGI.
This is the one I'm currently using, and it helps quite a bit, with less
changes needed to get the script running. Like mod_perl, it removes the
process creation and script interpretation steps, and you wind up just
running the bytecode in the virtual machine. This is pretty quick.
I haven't found a way to use mod_perl that wasn't horribly difficult.
This may be my missing something obvious, and if it is, I'd very much
love to be hit with the clue stick. None of the tutorials or documentation
I've seen talks about how to take a functioning, cleanly written CGI
program and make it run correctly under mod_perl.
--
Louis Erickson - wwonko@rdwarf.com - http://www.rdwarf.com/~wwonko/
Swahili, n.:
The language used by the National Enquirer to print their
retractions. -- Johnny Hart
------------------------------
Date: Sun, 10 Aug 2003 10:50:42 +0000
From: dominant <member32241@dbforums.com>
Subject: connecting to a database (with no web server)
Message-Id: <3222148.1060512642@dbforums.com>
Is this practicable?
I observed that in the connect function we must specified the host. What
if there is not web server?
--
Posted via http://dbforums.com
------------------------------
Date: Sun, 10 Aug 2003 13:55:23 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: connecting to a database (with no web server)
Message-Id: <bh5bsj$nscig$1@ID-184292.news.uni-berlin.de>
You should repeat the essence of your question in the message body:
"connecting to a database (with no web server)"
dominant wrote:
> Is this practicable?
Yes, of course it is.
> I observed that in the connect function we must specified the host.
> What if there is not web server?
Which connect function are you talking about, and where did you
observe that? Did you study the documentation for the module you are
trying to use?
The connect() method in DBI.pm does not require that host is specified.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 10 Aug 2003 08:51:10 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: connecting to a database (with no web server)
Message-Id: <slrnbjcjee.fvf.tadmc@magna.augustmail.com>
dominant <member32241@dbforums.com> wrote:
>
> Is this practicable?
Is what practicable?
> I observed
Where did you observe it?
Show us what you saw, and we can help you interpret it.
Keep it to yourself, and it is up to you to interpret it.
> that in the connect function we must specified the host.
I have never observed such a thing, so I am curious as to
where you saw that.
Where did you see that?
> What
> if there is not web server?
Huh?
You do not need a web server to run Perl programs whether they
connnect to a database or not, so I dunno what you are getting
at there...
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 10 Aug 2003 23:58:57 +1000
From: "Gregory Toomey" <NOSPAM@bigpond.com>
Subject: Re: connecting to a database (with no web server)
Message-Id: <bh5j30$ug793$1@ID-202028.news.uni-berlin.de>
"dominant" <member32241@dbforums.com> wrote in message
news:3222148.1060512642@dbforums.com...
>
> Is this practicable?
>
> I observed that in the connect function we must specified the host. What
> if there is not web server?
This group is full of of people who think Perl=CGI=Apache.
Assuming you use DBI, DBI->connect has noting to do with web servers. There
are plenty of Perl programmers who don't go near web servers.
gtoomey
------------------------------
Date: Sun, 10 Aug 2003 12:31:27 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: extract strings between alternating text
Message-Id: <bh56v7$tvdaf$1@ID-184292.news.uni-berlin.de>
Tad McClellan wrote:
> [ comp.lang.perl is not a Newsgroup. Removed. ]
>
> Lydia Shawn <apfeloma@hotmail.com> wrote:
>
>> bla trigger3 trigger4 trigger1 blabla trigger1 5000.00 trigger3
>> trigger1 trigger2 trigger2 600.00 trigger4 trigger1 50.00
>> trigger4
>>
>> i want to extract the numbers everytime they occur between
>> trigger1 or 2 and trigger3 or 4.
>
> while ( /(trigger1|trigger2)(.*?)(trigger3|trigger4)/sg ) {
> my $str = $2;
> print "$1\n" if $str =~ /(\d+\.\d+)/
> }
Or, still assuming that the input is in $_:
@return = /(?:trigger1|trigger2)\s*([\d.]+)\s*(?:trigger3|trigger4)/gs;
Please don't just copy and paste. You'd better take Sam's advise and
study the docs about regular expressions.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 10 Aug 2003 06:21:09 -0500
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: extract strings between alternating text
Message-Id: <Xns93D34AB855A46sdn.comcast@206.127.4.25>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
apfeloma@hotmail.com (Lydia Shawn) wrote in
news:1240b4dc.0308100156.2728ebcc@posting.google.com:
> hi eric,
>
>> You want to match
>> The string "trigger1" or "trigger2"
>> followed by possible whitespace
>> followed by digits (and maybe a decimal point?)
>> followed by more possible whitespace
>> followed by the string "trigger3" or "trigger4"
>
> exactly right! the variable was a mistake in my earlier posting but
> you got it anyway!
>
> for some reason though the | doesn't seem to do it's job..
>
> =~ /(trigger1|trigger2)\s*([\d.]+)\s*(trigger3|trigger4)/six;
>
> returns "trigger1"
>
> but when i leave out the | like here:
>
> =~ /trigger2\s*([\d.]+)\s*trigger4/six;
> it matches the number between trigger1 and trigger4 properly..
> i'd want to match all three though!
There are three sets of parentheses in the pattern, therefore three
strings are returned. I suspect you're only checking the first, or
you're only looking at $1.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPzYqiGPeouIeTNHoEQIkQACg66NHgFvWoLYFET68eRLnzPvxszwAn0M7
C4B9NToDB3OuCKgj/f+j+mw/
=kZNU
-----END PGP SIGNATURE-----
------------------------------
Date: Sun, 10 Aug 2003 08:42:30 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: extract strings between alternating text
Message-Id: <slrnbjciu6.fvf.tadmc@magna.augustmail.com>
Lydia Shawn <apfeloma@hotmail.com> wrote:
> the variable was a mistake in my earlier posting
Have you seen the Posting Guidelines that are posted here frequently?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 10 Aug 2003 15:49:47 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: help needed making unicode entities
Message-Id: <Pine.LNX.4.53.0308101541350.3463@lxplus010.cern.ch>
On Sun, Aug 10, Dan Jacobson inscribed on the eternal scroll:
> Alan> [In perl] to apply :utf8 semantics to an already-open filehandle
> Alan> you use the extended form of binmode().
>
> perldoc -f binmode has no eye grabbing example.
I'm looking at http://www.perldoc.com/perl5.8.0/pod/func/binmode.html
binmode FILEHANDLE, LAYER
[...]
If LAYER is present it is a single string, but may contain multiple
directives. The directives alter the behaviour of the file handle.
When LAYER is present using binmode on text file makes sense.
To mark FILEHANDLE as UTF-8, use :utf8.
Might not be an "eyegrabbing example", but it seems clear enough to
me, no?
Your "eyegrabbing example" seens to be here:
http://www.perldoc.com/perl5.8.0/pod/perluniintro.html#Unicode-I-O
and on already open streams, use binmode():
binmode(STDOUT, ":utf8");
I would certainly recommend referring back to both perluniintro and
perlunicode while doing this sort of work - they've helped me, anyhow.
cheers
------------------------------
Date: Sun, 10 Aug 2003 12:28:10 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: Location problem
Message-Id: <Pine.LNX.4.53.0308101211230.2137@lxplus092.cern.ch>
On Sun, Aug 10, Ron Spears inscribed on the eternal scroll:
[unattributed quote:]
> > Try:
> >
> > my $loc = "Location: http://www.website.com/confirm.htm?passed_variable";
> > print "$loc\n\n";
>
> Actually, in my code case this method won't work.
I don't see any reason in principle why the approach wouldn't be
viable, but your supposed workaround just seemed to add confusion.
> For the previous
> poster, the reason why I am printing it twice is because in code
> reality there is a bunch of stuff between each of these statements and
> the intent was to store the redirected URL for execution at the end of
> the code. For some reason in this sendmail routine, if I position
> this line after a particular line in the sendmail rountine, print
> "Content-type: text/html\n\n"; it causes the redirect to print out as
> html on the screen only...
You don't seem to understand the distinction between the CGI response
header and the response body. If you're seeing something on the
screen, then it's a fair bet that the CGI response header had already
been sent, and your supposed header is being treated as body content.
So stop doing that.
I'd have to suggest looking at the CGI specification again to
understand what you're doing, or trying to do. Perl FAQ 9 has some
pointers, but you don't really have a Perl question as such, so I'm
taking the liberty of redirecting the thread to the WWW CGI group
(beware the automoderation bot - see its posting guidelines).
> So I am still trying to pass a variable off to confirm.htm
You're trying to redirect the client to a new URL with a query string
in it, and that looks to be the right approach. You just don't have
the details quite right yet. But tossing-in random variations isn't
going to help.
good luck
--
PLEASE NOTE: comp.infosystems.www.authoring.cgi is a
SELF-MODERATED newsgroup. aa.net and boutell.com are
NOT the originators of the articles and are NOT responsible
for their content.
HOW TO POST to comp.infosystems.www.authoring.cgi:
http://www.thinkspot.net/ciwac/howtopost.html
------------------------------
Date: Sun, 10 Aug 2003 06:24:15 -0500
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: Location problem
Message-Id: <Xns93D34B3F3C7E0sdn.comcast@206.127.4.25>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
ronspear_tx@yahoo.com (Ron Spears) wrote in
news:304a0e4e.0308092359.cf9cac8@posting.google.com:
> the code. For some reason in this sendmail routine, if I position
> this line after a particular line in the sendmail rountine, print
> "Content-type: text/html\n\n"; it causes the redirect to print out as
> html on the screen only...
"For some reason"...? I think you need to go read up on how HTTP headers
work...
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPzYrQ2PeouIeTNHoEQKqGgCfX/UD2YOdXR8r/ayJwOHqtvEYFsEAniKm
bqluJJe6g+jXaj1UCrEmCmvu
=UB97
-----END PGP SIGNATURE-----
------------------------------
Date: Sun, 10 Aug 2003 15:12:57 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: Location problem
Message-Id: <Pine.LNX.4.53.0308101505480.3463@lxplus010.cern.ch>
On Sun, Aug 10, Eric J. Roode inscribed on the eternal scroll:
> "For some reason"...? I think you need to go read up on how HTTP headers
> work...
From the context, I understood the question to be about a CGI
response, rather than a raw HTTP transaction response.
They're very similar, of course, by design; but there are subtle
differences, so I'd have to recommend keeping the concepts distinct on
one's mind.
Of course, this has nothing specifically to do with Perl.
But as perlport points out, the correct portable terminator for
interworking sockets (and this goes for HTTP) would be \015\012 (i.e
CRLF) written in binary mode.
For CGI, however, where the process is communicating with the web
server (httpd) on the _same_ platform, the platform-specific newline
representation, i.e \n , is considered appropriate. And that's what
we saw being used in this presumed-CGI context, so that detail was OK
(the problem lay elsewhere, as I said before).
So that at least manages to drag _some_ Perl relevance into the
thread, even if this particular issue doesn't answer the questioner's
problem ;-)
cheers
------------------------------
Date: Sun, 3 Aug 2003 21:32:31 +0000 (UTC)
From: Louis Erickson <wwonko@rdwarf.com>
Subject: Messages from FreezeThaw of a DBI handle
Message-Id: <bgjv1f$u7c$1@holly.rdwarf.com>
Digging around, I found several comments about this on the 'net, but didn't
find a really conclusive discovery of what caused it, and thought I'd share
what I found with the group, and with the archives.
Forgive me if this is common knowledge. It was filling up my Apache logs,
and I had to fiddle with it for a couple of hours to find it, and I thought
maybe I'd save someone the time. =)
If you FreezeThaw a database handle from DBI, then you'll get some strange
errors to STDOUT when you thaw it. They look like this:
SV = RV(0x879ced0) at 0xbffff710
REFCNT = 1
FLAGS = (ROK,READONLY)
RV = 0x87a3ea4
I don't know what generates them or why, but if you don't thaw the database
handle, they don't occur.
My workaround was to remove the database handle from the hash I was freezing,
and put it back after I had done so. That way, it wasn't there when I tried
to thaw it.
This seemed to affect both Linux with Perl 5.6.0 and Windows with ActiveState
Perl 5.6.1.
Hope it helps someone, and if someone knows a better solution, I'd be happy
to hear it!
Thanks!
--
Louis Erickson - wwonko@rdwarf.com - http://www.rdwarf.com/~wwonko/
An effective way to deal with predators is to taste terrible.
------------------------------
Date: Sun, 10 Aug 2003 06:45:33 -0700
From: Steve <me@home.com>
Subject: Re: Output to (X)HTML
Message-Id: <n3jcjvojeuo22kgf456hovq9s7eutikgq6@4ax.com>
its very simple...just add this before your first print statement:
print "Content-type: text/html", "\n\n";
any tags you want, just print them out:
print "<html><body><center>";
if you are just printing raw data and want a line break, use <br>
instead of \n
also, this helps a lot:
use CGI::Carp qw(fatalsToBrowser);
Hope that helps,
__________
http://www.hudsonscripting.com/
On Thu, 07 Aug 2003 11:33:33 -0400, Lou Moran <ellem52@mac.com> wrote:
>Using this code:
>
>#! /usr/local/bin/perl
>use diagnostics ;
>use warnings ;
>use strict ;
>use List::Util qw (sum) ; #not in the standard distro
>
>my $roll = 6 ;
>
>until ($roll == 0) { #rolls the dice 6 times
> $roll -- ;
>
> my @d61 = int(rand(5) + 2) ; #6 sided die with no 1
> my @d62 = int(rand(5) + 2) ;
> my @d63 = int(rand(5) + 2) ;
> my @d64 = int(rand(5) + 2) ;
>
> my @all = sort #split line for looks
> { $b <=> $a } @d61, @d62, @d63, @d64 ; #sorts rolls
> #to prepare for
> pop @all ; #pop removing
> #the lowest roll
> my $sum = sum(@all) ; #before adding
>
> print "\n@all - $sum\n" ;
>}
>
>__END__
>
>I would like to have the print output an HTML page. I assume I will
>need to use the (a) CGI module but I am quite fuzzy on which one and
>if it would be as easy as calling the Module and referencing @all and
>$sum
------------------------------
Date: Tue, 5 Aug 2003 15:26:11 +0000 (UTC)
From: Louis Erickson <wwonko@rdwarf.com>
Subject: Re: perl DBI
Message-Id: <bgoiaj$5t1$1@holly.rdwarf.com>
Chris <no_thanks@bms.umist.ac.uk> wrote:
: sangeetha wrote:
:>
:> DBI connect('test','root',...) failed: Can't connect to local MySQL
:> server through socket '/tmp/mysql.sock' (2) at db.pl line 10
:> Error opening database: Can't connect to local MySQL server through
:> socket '/tmp/mysql.sock' (2)
:>
That's a MySQL connection problem. Your password or username are
incorrect, or you don't have a 'test' database, or you're not running
MySQL or something. Make sure you can connect from the mysql command
on the command line, and use those same parameters in the Perl script.
If you are, then I'm completely wrong.
: I've got the same problem, but only with one combination of perl and
: mysql. If I use perl 5.6.1 'built for i686-linux' with mysql 3.23.48 I
: get the error, but if use perl 5.6.1 'built for i586-linux' I don't. As
: I have access to both on our network I just use the i586 version.
: I don't know what's causing it nor why a simple difference like is
: having an effect, but our overworked sysadmin doesn't have time to look
: into it so I'm making do at the moment. I know this doens't answer your
: question really, but I hope it helps nonetheless :-)
I suspect that the difference isn't the processor that Perl is built for.
It is more likely to be something else.
If it's exactly that error, then the machine with 'i686' on it has no
MySQL server, or that's the wrong password. Make sure you can connect
with mysql from the command line.
If it's other problems, check to make sure that your 'i686' system has DBI
and DBD::MySQL installed.
--
Louis Erickson - wwonko@rdwarf.com - http://www.rdwarf.com/~wwonko/
Naeser's Law:
You can make it foolproof, but you can't make it damnfoolproof.
------------------------------
Date: Tue, 5 Aug 2003 15:05:16 +0000 (UTC)
From: Louis Erickson <wwonko@rdwarf.com>
Subject: Re: Perl Math Syntax
Message-Id: <bgoh3c$4gt$1@holly.rdwarf.com>
Uri Guttman <uri@stemsystems.com> wrote:
:>>>>> "EJR" == Eric J Roode <REMOVEsdnCAPS@comcast.net> writes:
: EJR> Why is that "better"? For a simple variable increment, I would
: EJR> say that it's just a matter of style. I can't see any real
: EJR> difference between
: EJR> $opened = $opened + 1;
: EJR> $opened += 1;
: EJR> $opened++;
: run them under the benchmark module. report your results back here.
Hmm. Uri, why do you say this? It sounds like you are suggesting that
the fastest one is the best. I thought you were one of the "Whatever is
the easiest to read, write, and maintain is best" school, and felt that
premature optimiazion was evil.
Not to say that all optimization is evil, or that it's not interesting to
know.
Myself, I think that $v = $v + 1; may be clearest for someone new to
programming, although I find it a bit wordy. I prefer $v++, but I'm from C,
and expected to like that kind of confusion. I like pointers, too, so
that should tell you what kind of a pervert I really am. =)
You've got me curious now, so I've gone ahead and fired up Benchmark as you
suggested. The results are not what I expected, either. (This is just
another example of why you should always use timings, rather than what
you expect.)
If the program I've written isn't a good demonstration of this, please
let me know. I've seen several discussions with Benchmark go by where
the program used for timing wasn't right, which gave bogus values.
[Note: I have reformatted this output slightly to make it fit 80 columns.]
wwonko@holly:~ $ perl
use strict;
use warnings;
use Benchmark;
our $counter;
Benchmark::cmpthese(10000000, {
plusequ=>sub {$counter += 1},
plusone=>sub {$counter = $counter +1},
plusplus=>sub {$counter++}
});
Benchmark: timing 10000000 iterations of plusequ, plusone, plusplus...
plusequ: 2 wallclock secs ( 1.41 usr + 0.02 sys = 1.43 CPU)
@ 6993006.99/s (n=10000000)
plusone: 4 wallclock secs ( 2.98 usr + -0.02 sys = 2.96 CPU)
@ 3378378.38/s (n=10000000)
plusplus: 2 wallclock secs ( 1.63 usr + -0.02 sys = 1.61 CPU)
@ 6211180.12/s (n=10000000)
Rate plusone plusplus plusequ
plusone 3378378/s -- -46% -52%
plusplus 6211180/s 84% -- -11%
plusequ 6993007/s 107% 13% --
wwonko@holly:~ $
Running this again got me:
Rate plusone plusplus plusequ
plusone 3412969/s -- -44% -56%
plusplus 6097561/s 79% -- -22%
plusequ 7812500/s 129% 28% --
Obviously, my system load influenced this somewhat.
If I'm reading this correctly, it looks like $v += 1; is fastest, closely
followed by $v++. I would have expected the reverse. And, $v = $v +1; is
the slowest, as I would have expected.
Interestingly, I get different results if I use a 'my' variable rather
than an 'our' variable. One is lexical and the other isn't, correct?
wwonko@holly:~ $ perl
use strict;
use warnings;
use Benchmark;
Benchmark::cmpthese(10000000, {
plusequ=>sub {my $counter = 0; $counter += 1},
plusone=>sub {my $counter = 0; $counter = $counter +1},
plusplus=>sub {my $counter = 0; $counter++}
});
Benchmark: timing 10000000 iterations of plusequ, plusone, plusplus...
plusequ: 4 wallclock secs ( 5.07 usr + -0.01 sys = 5.06 CPU)
@ 1976284.58/s (n=10000000)
plusone: 6 wallclock secs ( 5.07 usr + 0.01 sys = 5.08 CPU)
@ 1968503.94/s (n=10000000)
plusplus: 6 wallclock secs ( 5.07 usr + -0.12 sys = 4.95 CPU)
@ 2020202.02/s (n=10000000)
Rate plusone plusequ plusplus
plusone 1968504/s -- -0% -3%
plusequ 1976285/s 0% -- -2%
plusplus 2020202/s 3% 2% --
wwonko@holly:~ $
And again...
Rate plusone plusequ plusplus
plusone 1930502/s -- -1% -3%
plusequ 1956947/s 1% -- -2%
plusplus 1988072/s 3% 2% --
These are not the results I expected, but they seem to be reasonably stable.
--
Louis Erickson - wwonko@rdwarf.com - http://www.rdwarf.com/~wwonko/
Cynic, n.:
One who looks through rose-colored glasses with a jaundiced eye.
------------------------------
Date: Sun, 3 Aug 2003 19:44:34 +0000 (UTC)
From: Louis Erickson <wwonko@rdwarf.com>
Subject: Problem with FindBin and taint mode under Windows
Message-Id: <bgjon2$nvt$1@holly.rdwarf.com>
I've just run in to a problem on a project I'm working on here, which may
mean I can't use taint mode on a bunch of CGI scripts. This is not a really
good solution, and I'd like to figure a way around it.
When you use FindBin, under ActiveState's Windows perl, it fails right away
with a taint check.
As far as I can tell, this is because FindBin calls abs_path to resolve the
path elements in $Bin and $RealBin. abs_path on Unix is taint-safe.
On Windows, abs_path is aliased to fast_abs_path, which uses chdir. chdir
is not taint safe, and therefore FindBin is not taint safe on Windows.
It looks to me like the only "safe" way to do this would be to write a version
of abs_path that works on Windows, and then to use that instead of
fast_abs_path, and to update Cwd to use the new function.
This is with AS Perl 5.6.1 build 635.
I'm kind of in a catch-22... I could write my own, but I can't get it in
to @INC properly without FindBin, and FindBin is the trouble...
I saw a couple of questions about this in the Usenet archive on Google, and
a couple of references to it on the Web, but I didn't find a really good
answer from anyone.
Is there a way to use FindBin with -T on Windows? Or am I on my own?
--
Louis Erickson - wwonko@rdwarf.com - http://www.rdwarf.com/~wwonko/
You may be recognized soon. Hide.
------------------------------
Date: Sun, 3 Aug 2003 02:46:16 +0000 (UTC)
From: Louis Erickson <wwonko@rdwarf.com>
Subject: Re: Script "terminates" when processing large numbers of files
Message-Id: <bght1o$rbn$1@holly.rdwarf.com>
Gregory Toomey <NOSPAM@bigpond.com> wrote:
: "Scott Stark" <sstark@us.ibm.com> wrote in message
: news:ce94ec71.0308011603.54421c32@posting.google.com...
:> Hi, I'm running a script that reads through large numbers of html
:> files (1500-2000 or so) in each of about 20 directories, searching for
:> strings in the files.
: Some ISPs stop long running 'batch' processes by killing them after a
: certain elapsed time.
: Could that be the case here?
Some Unixes have user process limits, on CPU time, memory, processes started,
etc. root usually has none. Check 'ulimit' to see if you, or ask your
sysadmin. 'Terminated' sounds like csh complaining the program was killed
to me.
------------------------------
Date: Sun, 10 Aug 2003 16:25:14 GMT
From: "Joe Burnett" <joe@burnettworks.com>
Subject: Script displays in dos window, not browser
Message-Id: <KluZa.113785$Ho3.14438@sccrnsc03>
Hello,
I am trying to run a trivial perl script, but the results either get
displayed in a dos window,
or the source code gets displayed in a browser. The former happens when I
open the script
in IE with a pl extension. The latter happens if I open the script with a
cgi extension. Both
scripts reside in "C:\Program Files\Apache Group\Apache2\cgi-bin".
Obviously, I have an
apache server (the service is started, as well as two apache.exe processes).
I have ActiveState
perl installed. Here is the script:
#!C:\Perl\bin\perl.exe
print "Content-type: text/html\n\n";
print "<html>\n<head><title>First CGI</title></head>\n";
print "<body><h1>\n";
print "Hello world!!";
print "</h1>\n </body>\n</html>\n";
I have been looking in the news groups for two days to no avail.
Thanks,
Joe
------------------------------
Date: Sun, 10 Aug 2003 16:38:12 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Script displays in dos window, not browser
Message-Id: <UxuZa.6309$dm.3161@nwrddc02.gnilink.net>
Joe Burnett wrote:
> I am trying to run a trivial perl script, but the results either get
> displayed in a dos window,
Well, then apparently the Perl script works perfectly fine: it prints
exactly what it is supposed to print.
> or the source code gets displayed in a browser.
> I have an apache server
[...]
> I have been looking in the news groups for two days to no avail.
Doesn't surprise me. You are looking the wrong place.
You should check out a NG that actually deals with Apache to find out how to
configure Apache.
jue
------------------------------
Date: Mon, 4 Aug 2003 15:17:08 +0000 (UTC)
From: Louis Erickson <wwonko@rdwarf.com>
Subject: Re: Web hosts and mod_perl
Message-Id: <bgltdk$uq0$1@holly.rdwarf.com>
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
: trwww wrote:
:> Gunnar Hjalmarsson wrote:
:>> It would be great if it was possible to configure a server in a
:>> way that handles such potential problems properly. Is there
:>> anybody who knows if that is possible?
:>
:> What a provider could do so that all requests could be served over
:> port 80 is set up a proxy httpd that dispatches internal httpds
:> based on the 'host:' header in the request. This will give each
:> user their own memory to work in. It is an expensive solution
:> though.
Rather than using completely seperate machines, you could set up seperate
copies of Apache, listening on different ports or IP addresses, all on one
machine. It would use a little more memory, and a little more disc, but
would be a lot less expensive than seperate boxes.
Your proxy could even do translation to internal IP addresses, so that you
didn't have to give each seperate host a valid external IP address, if you
felt that urge.
--
Louis Erickson - wwonko@rdwarf.com - http://www.rdwarf.com/~wwonko/
One seldom sees a monument to a committee.
------------------------------
Date: Sat, 19 Jul 2003 01:59:56 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re:
Message-Id: <3F18A600.3040306@rochester.rr.com>
Ron wrote:
> Tried this code get a server 500 error.
>
> Anyone know what's wrong with it?
>
> if $DayName eq "Select a Day" or $RouteName eq "Select A Route") {
(---^
> dienice("Please use the back button on your browser to fill out the Day
> & Route fields.");
> }
...
> Ron
...
--
Bob Walton
------------------------------
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 5341
***************************************
