[24229] in Perl-Users-Digest
Perl-Users Digest, Issue: 6421 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Apr 19 14:56:45 2004
Date: Mon, 19 Apr 2004 11:56:02 -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: 6421
Today's topics:
perl compilation problem : Version_check" is not export (felipe200112)
Perl is the answer? <andries@zilz.nl>
Re: Perl Script Not Running From Crontab. axel@white-eagle.co.uk
Perl Script to Copy files <bojanra@nortelnetworks.com>
Re: Perl Script to Copy files <me@privacy.net>
Re: print LIST vs print join "", LIST (Xavier Noria)
Re: print LIST vs print join "", LIST (Xavier Noria)
Re: print LIST vs print join "", LIST <tassilo.parseval@rwth-aachen.de>
Re: print LIST vs print join "", LIST (Anno Siegel)
Re: print LIST vs print join "", LIST <tassilo.parseval@rwth-aachen.de>
Re: print LIST vs print join "", LIST (Anno Siegel)
Re: print LIST vs print join "", LIST <uri@stemsystems.com>
Re: print LIST vs print join "", LIST <tassilo.parseval@rwth-aachen.de>
Re: print LIST vs print join "", LIST <tassilo.parseval@rwth-aachen.de>
Re: print LIST vs print join "", LIST (Anno Siegel)
Re: print LIST vs print join "", LIST <uri@stemsystems.com>
Re: Problem with CGI.pm POST_MAX <Joe.Smith@inwap.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 19 Apr 2004 09:36:42 -0700
From: felipe200112@yahoo.com (felipe200112)
Subject: perl compilation problem : Version_check" is not exported by the ExtUtils::MakeMaker module
Message-Id: <b1c37d24.0404190836.743ff14a@posting.google.com>
When compiling whatever perl module to my debian version ( unstable
release indeed - see perl version ), I have those problems :
If it is newbies problems, thanks to help me soon.
=========================
"Version_check" is not exported by the ExtUtils::MakeMaker module
Can't continue after import errors at -e line 0
=========================
linux51:/usr/src/rpm/SOURCES/IO-Socket-SSL-0.93# perl Makefile.PL
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Writing Makefile for IO::Socket::SSL
linux51:/usr/src/rpm/SOURCES/IO-Socket-SSL-0.93# make
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
"Version_check" is not exported by the ExtUtils::MakeMaker module
Can't continue after import errors at -e line 0
BEGIN failed--compilation aborted.
make: *** [Version_check] Error 255
linux51:/usr/src/rpm/SOURCES/IO-Socket-SSL-0.93#
linux51:/usr/src/rpm/SOURCES/IO-Socket-SSL-0.93# uname -a
Linux linux51.fty 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686
GNU/Linux
linux51:/usr/src/rpm/SOURCES/IO-Socket-SSL-0.93# perl -v
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
This is perl, v5.8.3 built for i386-linux-thread-multi
Copyright 1987-2003, Larry Wall
Perl may be copied only under the terms of either the Artistic License
or the
GNU General Public License, which may be found in the Perl 5 source
kit.
Complete documentation for Perl, including FAQ lists, should be found
on
this system using `man perl' or `perldoc perl'. If you have access to
the
Internet, point your browser at http://www.perl.com/, the Perl Home
Page.
linux51:/usr/src/rpm/SOURCES/IO-Socket-SSL-0.93#
Felipe
------------------------------
Date: Mon, 19 Apr 2004 19:34:42 +0200
From: Andries <andries@zilz.nl>
Subject: Perl is the answer?
Message-Id: <4d3880lph91adlhpds8sv0ndo4btcdb13s@4ax.com>
Hello there,
I hope someone can help me.
This is my problem:
I have a list of thousands and thousands of the next lines:
----------------------------------------------------------------------
<a href="hs80.htm#halveringstijd"target="topic">halveringstijd</a><br>
<a href="hs80.htm#hartkleppen" target="topic"></a><br>
<a href="hs80.htm#hartvolume" target="topic"></a><br>
<a href="hs80.htm#hemoglobine" target="topic"></a><br>
<a href="hs80.htm#heteroseksueel " target="topic"></a><br>
<a href="hs80.htm#hijgen" target="topic"></a><br>
<a href="hs80.htm#histamine" target="topic"></a><br>
--------------------------------------------------------------------------------------
I need to copy the word between the # and " and put it after the > and
</a>
It can done by hand like the first line but it can be automated with a
perl script isn't it?
If so I still have a problem can anyone tell me how?
TIA
Andries Meijer
------------------------------
Date: Sat, 17 Apr 2004 12:23:53 GMT
From: axel@white-eagle.co.uk
Subject: Re: Perl Script Not Running From Crontab.
Message-Id: <tl9gc.4399$ws2.872@news-binary.blueyonder.co.uk>
Matt Cluver <cluver@netdepict.com> wrote:
> I'm having a problem with crontab running my perl script, it runs
> perfectly fine from the prompt while logged in. The script is chmodded
> to 777, I have included a lib statement to take care of possible
> enviroment variable issues.
> I would appreciate someone taking a look, thanks in advance.
> Crontab:
> 0 0 * * * perl /full/path/to/qotd.pl
> Perl:
> #!/usr/bin/perl
Are you sure when crontab passes the command to the shell, that the
shell is finding perl in its path?
Perhaps explicly specifying the path might help:
0 0 * * * /usr/bin/perl /full/path/to/qotd.pl
Axel
------------------------------
Date: Wed, 14 Apr 2004 14:36:19 -0400
From: "bojan" <bojanra@nortelnetworks.com>
Subject: Perl Script to Copy files
Message-Id: <c5k078$clb$1@zcars0v6.ca.nortel.com>
Hi
Does anyone have some script file to copy files from specific date on UNIX?
-rw-r--r-- 1 bojanra magellan 6217 Apr 1 13:03 test1
-rw-rw-r-- 1 bojanra magellan 15136 Apr 2 13:17 test2
-rw-rw-r-- 1 bojanra magellan 10444 Apr 3 13:50 test3
-rw-r--r-- 1 bojanra magellan 9820 Apr 4 13:51 test4
Here I just want to copy files from Apr 2 to Apr 3. (test2 & test3)
Thanks,
Bojan
------------------------------
Date: Sun, 18 Apr 2004 21:43:03 +1200
From: "Tintin" <me@privacy.net>
Subject: Re: Perl Script to Copy files
Message-Id: <c5tihp$5jrah$1@ID-172104.news.uni-berlin.de>
"bojan" <bojanra@nortelnetworks.com> wrote in message
news:c5k078$clb$1@zcars0v6.ca.nortel.com...
> Hi
>
> Does anyone have some script file to copy files from specific date on
UNIX?
>
> -rw-r--r-- 1 bojanra magellan 6217 Apr 1 13:03 test1
> -rw-rw-r-- 1 bojanra magellan 15136 Apr 2 13:17 test2
> -rw-rw-r-- 1 bojanra magellan 10444 Apr 3 13:50 test3
> -rw-r--r-- 1 bojanra magellan 9820 Apr 4 13:51 test4
>
> Here I just want to copy files from Apr 2 to Apr 3. (test2 & test3)
perldoc -f stat
perldoc File::Copy
------------------------------
Date: 16 Apr 2004 12:17:35 -0700
From: fxn@hashref.com (Xavier Noria)
Subject: Re: print LIST vs print join "", LIST
Message-Id: <31a13074.0404161117.68a536d@posting.google.com>
Brian McCauley <nobull@mail.com> wrote in message news:<u9u0zk3x02.fsf@wcl-l.bham.ac.uk>...
> That would depend on whether or not it is safe to assume that $,=''
>
> (A lot of commonly used modules _do_ assume this so IMHO it's best never
> to muck with $,)
I think that's unlikely to be the point: He controls the code he is
explaining, no mention to $, is made and does not look like it's
modified. Moreover, the canonical way to deal with global variables
like that is not to touch them globally, but to use local() if you
need to in some exceptional place. I wouldn't bet that's the reason
(though I could loss of course).
Doing that as defensive programming in case you afterwards modify $,
accidentally looks too convoluted as well to me.
-- fxn
------------------------------
Date: 17 Apr 2004 01:30:27 -0700
From: fxn@hashref.com (Xavier Noria)
Subject: Re: print LIST vs print join "", LIST
Message-Id: <31a13074.0404170030.27433338@posting.google.com>
fxn@hashref.com (Xavier Noria) wrote in message news:
<31a13074.0404160306.5bedc6e9@posting.google.com>...
> In a recent article by Dan Sugalski there's this code[*]:
>
> foreach my $node (@nodes) {
> my (@lines) = process_node(@$node);
> print join("", @lines);
> }
>
> Is that print line a matter of style, or is it a better choice over the much simpler
>
> print @lines;
>
> ?
Now that I think about it, I kind of recall that Uri commented in a
side note in his talk in the past YAPC::Europe in Paris that
print "string1" . "string2" . ... . "stringn";
is more efficient than
print "string1", "string2", ..., "stringn";
I am not 100% sure though, is that right? Does that translate to that
idiom with join() as well? If that was the case I would bet that's the
reason.
-- fxn
------------------------------
Date: 17 Apr 2004 09:09:11 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: print LIST vs print join "", LIST
Message-Id: <c5qs7n$4ron5$1@ID-231055.news.uni-berlin.de>
Also sprach Xavier Noria:
> fxn@hashref.com (Xavier Noria) wrote in message news:
><31a13074.0404160306.5bedc6e9@posting.google.com>...
>> In a recent article by Dan Sugalski there's this code[*]:
>>
>> foreach my $node (@nodes) {
>> my (@lines) = process_node(@$node);
>> print join("", @lines);
>> }
>>
>> Is that print line a matter of style, or is it a better choice over the much simpler
>>
>> print @lines;
>>
>> ?
>
> Now that I think about it, I kind of recall that Uri commented in a
> side note in his talk in the past YAPC::Europe in Paris that
>
> print "string1" . "string2" . ... . "stringn";
>
> is more efficient than
>
> print "string1", "string2", ..., "stringn";
>
> I am not 100% sure though, is that right? Does that translate to that
> idiom with join() as well? If that was the case I would bet that's the
> reason.
It appears to be right. My intuitive assumption would have been that the
list-print is more efficient, but apparently not. This benchmark:
use Benchmark qw/cmpthese/;
my @ary = ("foo") x 5;
cmpthese(-2, {
ary => sub {
print STDERR @ary;
},
concat => sub {
print STDERR $ary[0] . $ary[1] . $ary[2] . $ary[3] . $ary[4];
},
joined => sub {
print STDERR join '', @ary;
},
list => sub {
print STDERR $ary[0], $ary[1], $ary[2], $ary[3], $ary[4];
},
});
with stderr piped to /dev/null results in:
Rate list ary concat joined
list 170559/s -- -12% -48% -58%
ary 194564/s 14% -- -40% -52%
concat 325517/s 91% 67% -- -20%
joined 407659/s 139% 110% 25% --
As it looks, the join-approach is the least costly one. Another slight
surprise for me.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: 17 Apr 2004 12:17:21 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: print LIST vs print join "", LIST
Message-Id: <c5r78h$otd$1@mamenchi.zrz.TU-Berlin.DE>
Xavier Noria <fxn@hashref.com> wrote in comp.lang.perl.misc:
> fxn@hashref.com (Xavier Noria) wrote in message news:
> <31a13074.0404160306.5bedc6e9@posting.google.com>...
> > In a recent article by Dan Sugalski there's this code[*]:
> >
> > foreach my $node (@nodes) {
> > my (@lines) = process_node(@$node);
> > print join("", @lines);
> > }
> >
> > Is that print line a matter of style, or is it a better choice over
> the much simpler
> >
> > print @lines;
> >
> > ?
>
> Now that I think about it, I kind of recall that Uri commented in a
> side note in his talk in the past YAPC::Europe in Paris that
>
> print "string1" . "string2" . ... . "stringn";
>
> is more efficient than
>
> print "string1", "string2", ..., "stringn";
>
> I am not 100% sure though, is that right? Does that translate to that
> idiom with join() as well? If that was the case I would bet that's the
> reason.
Oh dear... I'm afraid we're looking for more reason than there is in
a casual choice of idioms.
"join '', @lines" is *the* way in Perl to put array elements together
in a string. That you can get a printout that looks the same without
(explicit) join is something else.
If anything, there is a difference of purpose. If the purpose of the
program is to print out the result, "print @lines" is the idiom of choice.
If its purpose is to return the string, as in a sub, "join '', @lines" is
the operative code, and "print" is a courtesy. The second view is the
broader one.
Here we come back to Uri's argument, but not for efficiency reasons but
on the general principle of "Print rarely, print late". If a piece of
code prints something, you can't take it back, and you have to bend over
backwards to make the printout invisible if you don't want it. So don't
do it, delay the decision to print to the latest possible time. The
same goes for warnings (of course) and dying in general-purpose subs.
"Die rarely, die late" is a recommendable principle too.
Anno
------------------------------
Date: 17 Apr 2004 12:28:42 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: print LIST vs print join "", LIST
Message-Id: <c5r7tq$4pmus$1@ID-231055.news.uni-berlin.de>
Also sprach Anno Siegel:
> Here we come back to Uri's argument, but not for efficiency reasons but
> on the general principle of "Print rarely, print late". If a piece of
> code prints something, you can't take it back, and you have to bend over
> backwards to make the printout invisible if you don't want it. So don't
> do it, delay the decision to print to the latest possible time. The
> same goes for warnings (of course) and dying in general-purpose subs.
>
> "Die rarely, die late" is a recommendable principle too.
Incidentally, a couple of hours ago I browsed through
http://www.extremeperl.org/, a book about Extreme Programming in Perl.
On reading a corresponding paragraph, it reminded me of XP's principle
of dying as early as possible. So there appear to be at least two
schools of dying now.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: 17 Apr 2004 14:54:38 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: print LIST vs print join "", LIST
Message-Id: <c5rgfe$9s$2@mamenchi.zrz.TU-Berlin.DE>
Tassilo v. Parseval <tassilo.parseval@post.rwth-aachen.de> wrote in comp.lang.perl.misc:
> Also sprach Anno Siegel:
>
> > Here we come back to Uri's argument, but not for efficiency reasons but
> > on the general principle of "Print rarely, print late". If a piece of
> > code prints something, you can't take it back, and you have to bend over
> > backwards to make the printout invisible if you don't want it. So don't
> > do it, delay the decision to print to the latest possible time. The
> > same goes for warnings (of course) and dying in general-purpose subs.
> >
> > "Die rarely, die late" is a recommendable principle too.
>
> Incidentally, a couple of hours ago I browsed through
> http://www.extremeperl.org/, a book about Extreme Programming in Perl.
>
> On reading a corresponding paragraph, it reminded me of XP's principle
> of dying as early as possible. So there appear to be at least two
> schools of dying now.
What is "XP's principle of dying early"? Does "XP" mean what I think it
does? And that's supposed to be an argument? :)
Seriously, I know that dying early is sometimes promoted, arguing that
it is useless and potentially harmful to carry on after something
essential went wrong. However, whether it's useless to continue is
for the user to decide, there may be alternatives outside the scope
of the program that dies (and the programmer who wrote the "die").
This view reflects a bit the program-centric view that a coder
necessarily assumes while working on a problem. "When *this* fails, we
can't do anything for the user. Better bail out." Indeed, it does
save the user the effort of checking for errors and thus is a service
for the user, or can been seen as such.
But doing too much is a design error when it takes a responsibility
from the user they would rather keep, and premature dying belongs in
this category. Programmers who design on-the-fly are particularly
prone to this error. I know this from undisclosed sources :)
In reality, I don't remember many cases where failure of some component
resulted in serious corruption of anything. I mean failure in a
recognizable sense where it *could* have died, not silent malfunction.
I do remember cases where a job wasn't completed because some minor
component chose a trivial error to "bail out", and it's a major nuisance.
So I'm for dying rarely and late.
Anno
------------------------------
Date: Sat, 17 Apr 2004 15:24:21 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: print LIST vs print join "", LIST
Message-Id: <x7y8ou6316.fsf@mail.sysarch.com>
>>>>> "TvP" == Tassilo v Parseval <tassilo.parseval@rwth-aachen.de> writes:
TvP> Also sprach Xavier Noria:
>>
>> Now that I think about it, I kind of recall that Uri commented in a
>> side note in his talk in the past YAPC::Europe in Paris that
>>
>> print "string1" . "string2" . ... . "stringn";
>>
>> is more efficient than
>>
>> print "string1", "string2", ..., "stringn";
>>
TvP> It appears to be right. My intuitive assumption would have been that the
TvP> list-print is more efficient, but apparently not. This benchmark:
of course i am right!!
the lesson from that section of the talk is
print rarely, print late.
you can see the slides from that section of my talk at:
http://stemsystems.com/slides/common_sense/slides/slide-0401.html
i don't show a benchmark but i did them like tassilo did. print is very
slow. now, i don't fuss over it in small scripts or in things where it
doesn't matter. but in larger scripts, daemons, high efficiency things,
socket stuff, i avoid print as much as possible. for whole files,
file::slurp is faster and cleaner. for sockets, sysread/syswrite is
better.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 18 Apr 2004 06:06:40 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: print LIST vs print join "", LIST
Message-Id: <c5t5tf$5ciu7$1@ID-231055.news.uni-berlin.de>
Also sprach Anno Siegel:
> Tassilo v. Parseval <tassilo.parseval@post.rwth-aachen.de> wrote in comp.lang.perl.misc:
>> Also sprach Anno Siegel:
>>
>> > Here we come back to Uri's argument, but not for efficiency reasons but
>> > on the general principle of "Print rarely, print late". If a piece of
>> > code prints something, you can't take it back, and you have to bend over
>> > backwards to make the printout invisible if you don't want it. So don't
>> > do it, delay the decision to print to the latest possible time. The
>> > same goes for warnings (of course) and dying in general-purpose subs.
>> >
>> > "Die rarely, die late" is a recommendable principle too.
>>
>> Incidentally, a couple of hours ago I browsed through
>> http://www.extremeperl.org/, a book about Extreme Programming in Perl.
>>
>> On reading a corresponding paragraph, it reminded me of XP's principle
>> of dying as early as possible. So there appear to be at least two
>> schools of dying now.
>
> What is "XP's principle of dying early"? Does "XP" mean what I think it
> does? And that's supposed to be an argument? :)
XP being Extreme Programming. Say, Anno, you didn't really think that it
might have been something Redmondish? ;-)
Meanwhile, I have found the exact spot where I picked up this statement
for everyone to check:
http://www.extremeperl.org/bk/coding-style
Grep for 'fails fast'.
> Seriously, I know that dying early is sometimes promoted, arguing that
> it is useless and potentially harmful to carry on after something
> essential went wrong. However, whether it's useless to continue is
> for the user to decide, there may be alternatives outside the scope
> of the program that dies (and the programmer who wrote the "die").
>
> This view reflects a bit the program-centric view that a coder
> necessarily assumes while working on a problem. "When *this* fails, we
> can't do anything for the user. Better bail out." Indeed, it does
> save the user the effort of checking for errors and thus is a service
> for the user, or can been seen as such.
I was rather thinking of libraries than programs. If you have a
function/method that is supposed to do destructive I/O and it is passed
garbage, it is certainly better to abort immediately than carrying on.
Otherwise it might happen that the function does half of the I/O and
then eventually dies leaving things in an inconsistent state.
> But doing too much is a design error when it takes a responsibility
> from the user they would rather keep, and premature dying belongs in
> this category. Programmers who design on-the-fly are particularly
> prone to this error. I know this from undisclosed sources :)
I am always in favour of design on-the-fly. I still have vivid memories
of the kind of planning-hoops I had to go through at university. There
was one lab in particular, where we had to program a rather largish Java
application involving a GUI. It all began with writing boring
requirement specifications that were afterwards modelled into UML. As I
recall it, the class diagram I came up with did impress mostly everyone.
However, it turned out to be unimplementable in Swing because it assumed
an event-model that simply didn't exist in this widget set.
So I had to change everything. In the end, I secretly changed my UML
diagrams to fit my final program and hoped that no one would notice
(they didn't, of course). Had I designed the thing on-the-fly, the
result would have been very similar without the many hours of overhead
needed to create an UML diagram that no one cared about or wanted to
see.
So I prefer the much more practical XP approach which essentially says:
"Implement the first thing that works and that you can think of and then
refactor". Perl is a wonderful language for that.
> So I'm for dying rarely and late.
There's another thing to take into account: A program dying early sure
shows the best runtime performance of them all. ;-)
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: 18 Apr 2004 06:21:54 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: print LIST vs print join "", LIST
Message-Id: <c5t6q2$5ec7l$1@ID-231055.news.uni-berlin.de>
Also sprach Uri Guttman:
>>>>>> "TvP" == Tassilo v Parseval <tassilo.parseval@rwth-aachen.de> writes:
>
> TvP> Also sprach Xavier Noria:
> >>
> >> Now that I think about it, I kind of recall that Uri commented in a
> >> side note in his talk in the past YAPC::Europe in Paris that
> >>
> >> print "string1" . "string2" . ... . "stringn";
> >>
> >> is more efficient than
> >>
> >> print "string1", "string2", ..., "stringn";
> >>
>
> TvP> It appears to be right. My intuitive assumption would have been that the
> TvP> list-print is more efficient, but apparently not. This benchmark:
>
> of course i am right!!
>
> the lesson from that section of the talk is
>
> print rarely, print late.
>
> you can see the slides from that section of my talk at:
>
> http://stemsystems.com/slides/common_sense/slides/slide-0401.html
>
> i don't show a benchmark but i did them like tassilo did. print is very
> slow. now, i don't fuss over it in small scripts or in things where it
> doesn't matter. but in larger scripts, daemons, high efficiency things,
> socket stuff, i avoid print as much as possible. for whole files,
> file::slurp is faster and cleaner. for sockets, sysread/syswrite is
> better.
The rule is probably to keep away from system-calls as long as possible
anyway. Especially the I/O-ish ones are slow just because I/O is slow
compared with calculations a CPU can carry out by itself.
In the context of this discussion however, we always had only one
print....on the surface at least.
Now, looking at the pp_print's source I can see why
print LIST;
is slower than
print join '', LIST;
Perl calls Perl_do_print() for every item in the list resulting in one
system-call per list element. This is even true for arrays, so perl will
not translate
print @ARY;
into
print join $,, @ARY;
In fact, it will print the array in a particularly wasteful way, namely:
for (0 .. $#ARY) {
print $ARY[$_];
print $, if $_ < $#ARY;
}
Good that you made me aware of that. I made some assumptions on the way
perl would possibly handle these cases that turn out to be very wrong.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: 19 Apr 2004 09:33:59 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: print LIST vs print join "", LIST
Message-Id: <c606e7$pft$1@mamenchi.zrz.TU-Berlin.DE>
Tassilo v. Parseval <tassilo.parseval@post.rwth-aachen.de> wrote in comp.lang.perl.misc:
> Also sprach Anno Siegel:
>
> > Tassilo v. Parseval <tassilo.parseval@post.rwth-aachen.de> wrote in
> comp.lang.perl.misc:
> >> Also sprach Anno Siegel:
> >>
> >> > Here we come back to Uri's argument, but not for efficiency reasons but
> >> > on the general principle of "Print rarely, print late". If a piece of
> >> > code prints something, you can't take it back, and you have to bend over
> >> > backwards to make the printout invisible if you don't want it. So don't
> >> > do it, delay the decision to print to the latest possible time. The
> >> > same goes for warnings (of course) and dying in general-purpose subs.
> >> >
> >> > "Die rarely, die late" is a recommendable principle too.
> >>
> >> Incidentally, a couple of hours ago I browsed through
> >> http://www.extremeperl.org/, a book about Extreme Programming in Perl.
> >>
> >> On reading a corresponding paragraph, it reminded me of XP's principle
> >> of dying as early as possible. So there appear to be at least two
> >> schools of dying now.
> >
> > What is "XP's principle of dying early"? Does "XP" mean what I think it
> > does? And that's supposed to be an argument? :)
>
> XP being Extreme Programming. Say, Anno, you didn't really think that it
> might have been something Redmondish? ;-)
Oh. Okay, sorry :) Extreme Programming didn't come to mind.
> Meanwhile, I have found the exact spot where I picked up this statement
> for everyone to check:
>
> http://www.extremeperl.org/bk/coding-style
>
> Grep for 'fails fast'.
I have taken a look. I wouldn't necessarily conclude from that remark
that "failing fast" is a tenet of Extreme Programming. It simply states
the old argument that it is better to die than to risk doing damage.
In the particular case I tend to agree. The function that "fails
fast" here is the plan() function of Test.pm, whose only purpose is
to prepare for a number of tests to be run. In that capacity, deciding
not to run the tests when the plan is in error is entirely reasonable.
If someone really wants to run plan() for some other purpose, they can
wrap eval() around it.
> > Seriously, I know that dying early is sometimes promoted, arguing that
> > it is useless and potentially harmful to carry on after something
> > essential went wrong. However, whether it's useless to continue is
> > for the user to decide, there may be alternatives outside the scope
> > of the program that dies (and the programmer who wrote the "die").
> >
> > This view reflects a bit the program-centric view that a coder
> > necessarily assumes while working on a problem. "When *this* fails, we
> > can't do anything for the user. Better bail out." Indeed, it does
> > save the user the effort of checking for errors and thus is a service
> > for the user, or can been seen as such.
>
> I was rather thinking of libraries than programs. If you have a
> function/method that is supposed to do destructive I/O and it is passed
> garbage, it is certainly better to abort immediately than carrying on.
> Otherwise it might happen that the function does half of the I/O and
> then eventually dies leaving things in an inconsistent state.
To elaborate, when I say "die late" i don't mean to return an incomplete
or defective result with no indication. "Die late" implies that the
user *can* decide to die later, meaning that there must be an error
indicator. So the user can avoid the possible damage, but the
responsibility is his.
Someone could have decided to let system calls in Perl die in case of
errors, instead of returning a boolean success indicator. That would
save clpm a lot of admonitions that begin with "Always, yes *always*...",
reminding people of the responsibility they fail to take. We would also
see a whole lot of "eval { open(...) }; if ( $@ ) { ... }". I like it
the way it is.
> > But doing too much is a design error when it takes a responsibility
> > from the user they would rather keep, and premature dying belongs in
> > this category. Programmers who design on-the-fly are particularly
> > prone to this error. I know this from undisclosed sources :)
>
> I am always in favour of design on-the-fly. I still have vivid memories
> of the kind of planning-hoops I had to go through at university. There
> was one lab in particular, where we had to program a rather largish Java
> application involving a GUI. It all began with writing boring
> requirement specifications that were afterwards modelled into UML. As I
> recall it, the class diagram I came up with did impress mostly everyone.
> However, it turned out to be unimplementable in Swing because it assumed
> an event-model that simply didn't exist in this widget set.
>
> So I had to change everything. In the end, I secretly changed my UML
> diagrams to fit my final program and hoped that no one would notice
> (they didn't, of course). Had I designed the thing on-the-fly, the
> result would have been very similar without the many hours of overhead
> needed to create an UML diagram that no one cared about or wanted to
> see.
I don't have a formal education in CS, and anecdotes like this tend to
ease my regret about that. From afar I have watched some diagramming
techniques come and go (flowcharts were discarded in the 70s, Nassi-
Shneiderman in th 80s). UML seems to be an OO equivalent -- I haven't
looked closer yet. They have always been put forward as a planning
tool, and there has always been a tendency to use them as an analysis
tool, i.e. draw the diagram for an already written program to understand
its structure.
What happened to you seems quite typical. What use is a perfect plan
when it turns out that there is no reasonable implementation under
practical constraints.
> So I prefer the much more practical XP approach which essentially says:
> "Implement the first thing that works and that you can think of and then
> refactor". Perl is a wonderful language for that.
Indeed. However, it doesn't hurt to become aware of the pitfalls *this*
approach has. One of them is cramming too much functionality into a routine
you're writing, just because it's a good occasion (and also because the
ways the routine will be used aren't quite clear yet). Programmers like to
implement, it's the designer's job to decide what it worth implementing.
When the designer and the coder are the same person, at the same time,
that job becomes harder.
Anno
------------------------------
Date: Mon, 19 Apr 2004 13:44:56 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: print LIST vs print join "", LIST
Message-Id: <x7pta4rsiw.fsf@mail.sysarch.com>
>>>>> "AS" == Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> writes:
AS> Someone could have decided to let system calls in Perl die in case of
AS> errors, instead of returning a boolean success indicator. That would
AS> save clpm a lot of admonitions that begin with "Always, yes *always*...",
AS> reminding people of the responsibility they fail to take. We would also
AS> see a whole lot of "eval { open(...) }; if ( $@ ) { ... }". I like it
AS> the way it is.
and there is a module for that IIRC. it traps system calls and dies on
failure. so you have to wrap the calls in eval{} to trap them. not worth
the effort IMO unless you are an exception style addict.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Mon, 19 Apr 2004 00:42:03 GMT
From: Joe Smith <Joe.Smith@inwap.com>
Subject: Re: Problem with CGI.pm POST_MAX
Message-Id: <vfFgc.156462$gA5.1872250@attbi_s03>
Bryan wrote:
> I have a script that uses the following code:
> $CGI::POST_MAX = 1024 * 100; # Set 100K limit on uploads
>
> I have used this before and it worked fine. Now, with a newer version
> of CGI.pm (> 3.0) this functionality no longer works at all. When
> trying to upload a too-large file, the server (apache) just hangs until
> it times out.
Looks to be an ill-advised change between CGI.pm 2.56 and CGI.pm 3.00.
Old:
METHOD: {
# avoid unreasonably large postings
if (($POST_MAX > 0) && ($content_length > $POST_MAX)) {
$self->cgi_error("413 Request entity too large");
last METHOD;
}
New:
METHOD: {
# avoid unreasonably large postings
if (($POST_MAX > 0) && ($content_length > $POST_MAX)) {
# quietly read and discard the post
my $buffer;
my $max = $content_length;
while ($max > 0 && (my $bytes = read(STDIN,$buffer,$max < 10000 ? $max
: 10000))) {
$max -= $bytes;
}
$self->cgi_error("413 Request entity too large");
last METHOD;
}
I cannot see any advantage in reading in an outrageous posting.
There ought to be two limits: Exceed the lower one, and the input
is discarded (but allow keep-alive to work). Exceed the upper one,
and return the error immediately (and optionally close the socket
in self-defense).
-Joe
------------------------------
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 6421
***************************************
