[23840] in Perl-Users-Digest
Perl-Users Digest, Issue: 6043 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 29 22:21:50 2004
Date: Thu, 29 Jan 2004 19:16:15 -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, 29 Jan 2004 Volume: 10 Number: 6043
Today's topics:
Re: Regular expression to find <tr> tags in 2nd level H (Shannon Jacobs)
Re: Regular expression to find <tr> tags in 2nd level H <uri@stemsystems.com>
Re: Regular expression to find <tr> tags in 2nd level H <matthew.garrish@sympatico.ca>
Re: Regular expression to find <tr> tags in 2nd level H <tadmc@augustmail.com>
Re: Regular expression to find <tr> tags in 2nd level H <jwkenne@attglobal.net>
restriction on file handle <wu26@cs.purdue.edu>
Re: restriction on file handle (Walter Roberson)
Re: restriction on file handle <dwall@fastmail.fm>
Re: restriction on file handle <usenet@morrow.me.uk>
Re: restriction on file handle <usenet@morrow.me.uk>
Re: restriction on file handle <wu26@cs.purdue.edu>
Re: restriction on file handle <tassilo.parseval@rwth-aachen.de>
Re: restriction on file handle (Anno Siegel)
Results <edgrsprj@ix.netcom.com>
Re: Results <Juha.Laiho@iki.fi>
Re: Results <edgrsprj@ix.netcom.com>
Re: retrieve webpage with POST (Peter Scott)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 22 Jan 2004 16:59:24 -0800
From: shanen@my-deja.com (Shannon Jacobs)
Subject: Re: Regular expression to find <tr> tags in 2nd level HTML tables
Message-Id: <c5862fb7.0401221659.797944a7@posting.google.com>
I'm so sorry to hear that the Google Groups system has been "neglected
for many years", as you put it so thoughtfully. It really is
unfortunate that so many people regard Google as a useful information
resource, isn't it?
Incidentally, when I finally had a bit of free time this morning, I
rethought the technical problem and did come up with a trivial
regex-based solution. It did exactly what I required on the first
attempt, confirming that the technical problem was pretty much as
trivial as I had thought it was. I guess it's just too bad that none
of you "experts" and "community contributors" were able to help.
However, this does lead to a new question:
Why did the newsgroups fail to produce the technically trivial answer?
While I can be abrasive or even rude when provoked, there is nothing
like that in my original query. I asked a simple technical question,
and wound up being dragged into a religious war about proper ways to
handle HTML. Not very useful.
If the religious issue of HTML was the problem, my advice to other
people seeking similar help is to avoid mentioning HTML. Try
describing your problem as structured database output, and maybe
you'll have better "luck" than I had.
I still regard regular expressions as useful and worthy of further
study. I cannot say the same thing about most of the people who
responded so religiously to my trivial question.
Oh yeah, I suppose I should give a hint about the solution, even
though it's a bit embarrassing. (I don't mind much as long as I can
feel I learned something along the way.) Returning to the problem
fresh and without the "box" around my thoughts, I looked at the data
files again and asked myself whether there was some other unique
string associated with the data that was associated with the second
level <tr> tags. I picked one of the likely candidates, and sure
enough, it worked. I still think there is a more clever way to do it
considering the logical structure of the HTML tags and the powerful
features of regular expressions, and I'd have been quite glad to learn
something new about those features. That would have been more
instructional than just solving the original rather trivial problem.
(By the way, the Excel-based solution was just TOO ugly to bear.)
tadmc@augustmail.com (Tad McClellan) wrote in message news:<slrnc03aec.9ln.tadmc@magna.augustmail.com>...
> Shannon Jacobs <shanen@my-deja.com> wrote:
>
>
> > 1. Just because a particular NNTP server does not carry a particular
> > newsgroup, that does not mean that the newsgroup in question does not
> > exist.
>
>
> Just because a particular newsgroup _is_ listed on a
> server does not mean that the newsgroup actually exists.
> That server may be wrong.
>
> comp.lang.perl was rmgroup'd many years ago, servers that still
> list it as a valid newsgroup look like they've been neglected
> for many years.
>
>
> > 2. With regards to the unhelpful advice to stop using Perl, I already
> > have
>
>
> Thank you.
>
> We will miss your valuable contributions to the community.
------------------------------
Date: Fri, 23 Jan 2004 02:17:51 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Regular expression to find <tr> tags in 2nd level HTML tables
Message-Id: <x7isj35rxt.fsf@mail.sysarch.com>
comp.lang.javascript removed since it has NOTHING to do with parsing
comp.lang.perl removed since it doesn't exist.
>>>>> "SJ" == Shannon Jacobs <shanen@my-deja.com> writes:
SJ> Why did the newsgroups fail to produce the technically trivial
SJ> answer?
because it is trivial to do with modules.
SJ> While I can be abrasive or even rude when provoked, there is nothing
SJ> like that in my original query. I asked a simple technical question,
SJ> and wound up being dragged into a religious war about proper ways to
SJ> handle HTML. Not very useful.
not religious at all. you don't get it about parsing html.
SJ> If the religious issue of HTML was the problem, my advice to other
SJ> people seeking similar help is to avoid mentioning HTML. Try
SJ> describing your problem as structured database output, and maybe
SJ> you'll have better "luck" than I had.
you are a fool. too bad you don't know it. but fools rarely do.
SJ> I still regard regular expressions as useful and worthy of further
SJ> study. I cannot say the same thing about most of the people who
SJ> responded so religiously to my trivial question.
oh, regexes are worthy of study. but please do it in another
language. perl's regexes are too religious for you.
SJ> Oh yeah, I suppose I should give a hint about the solution, even
SJ> though it's a bit embarrassing. (I don't mind much as long as I
SJ> can feel I learned something along the way.) Returning to the
SJ> problem fresh and without the "box" around my thoughts, I looked
SJ> at the data files again and asked myself whether there was some
SJ> other unique string associated with the data that was associated
SJ> with the second level <tr> tags. I picked one of the likely
SJ> candidates, and sure enough, it worked. I still think there is a
SJ> more clever way to do it considering the logical structure of the
SJ> HTML tags and the powerful features of regular expressions, and
SJ> I'd have been quite glad to learn something new about those
SJ> features. That would have been more instructional than just
SJ> solving the original rather trivial problem.
you just don't get it. ANY text file can be processed by regexes. that
isn't the issue. if you KNOW some facts about the file, that is
information you can use to make the parsing simpler. crunching html
files with regexes is fine IF you have knowledge about the file (such as
the stuff you found). but the GENERAL case of processing html CAN NOT
be done with a regex. and that is the point. using a module will do it
correctly and quickly and with less trouble than using a regex in
complex ways.
but you are too much in love with having things your way. the fact that
the experts have many more years of experience than you in this area
seems to matter little to you. that is why you don't feel like you got
help. you got help, just not the pablum that you can chew on.
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: Thu, 22 Jan 2004 21:03:36 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: Regular expression to find <tr> tags in 2nd level HTML tables
Message-Id: <Xh%Pb.17470$cQ6.710396@news20.bellglobal.com>
"Shannon Jacobs" <shanen@my-deja.com> wrote in message
news:c5862fb7.0401221659.797944a7@posting.google.com...
> I'm so sorry to hear that the Google Groups system has been "neglected
> for many years", as you put it so thoughtfully. It really is
> unfortunate that so many people regard Google as a useful information
> resource, isn't it?
>
Well, if Google still archives the messages then it must be a group. Someone
should re-revise this horribly outdated faq:
http://www.perldoc.com/perl5.8.0/pod/perlfaq2.html#What-are-the-Perl-newsgroups-on-Usenet---Where-do-I-post-questions-
>
> Why did the newsgroups fail to produce the technically trivial answer?
>
Because the point of this newsgroup is NOT to produce technically trivial
answers, because technically trivial answers are useless. So what if you
found some way you think might work for you? What good would posting some
bad advice that's bound to fail but that might do the job for you do for
someone searching on the same topic? Parsing html questions come up every
few days. Do you think people here want to sit and answer them with
technically trivial answers over and over again? Do you think they want to
be responding to questions along the lines of "Duh, how come this trivial
answer didn't work for me?"?
Get a life. You got flamed for asking a stupid question. If you had any
knowledge of markup languages you wouldn't have even asked it. And if you
don't like being told you're dumb, don't post to usenet.
Matt
------------------------------
Date: Thu, 22 Jan 2004 21:26:57 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Regular expression to find <tr> tags in 2nd level HTML tables
Message-Id: <slrnc11541.bef.tadmc@magna.augustmail.com>
[
Non-existent newsgroup removed again.
comp.lang.javascript removed, no JavaScript content.
Followups set.
]
[ I couldn't figure out how to repair the top-posting, so
I just snipped the full-quote at the end.
]
Shannon Jacobs <shanen@my-deja.com> wrote:
[ context: comp.lang.perl was rmgroup'd long ago ]
> I'm so sorry to hear that the Google Groups system has been "neglected
> for many years", as you put it so thoughtfully.
Usenet was administered successfully for 15 years before
DejaNews (google groups).
Google is not a part of Usenet.
Google does not administer Usenet.
Google is an archive of everything appears on Usenet without
regard to whether it is _supposed_ to appear on Usenet or not.
There is a protocol (the "P" in "NNTP") for administering Usenet.
There was a proper protocol message removing the comp.lang.perl
newsgroup many years ago when the other Perl newsgroups were formed.
It appears that you do not have enough experience with Usenet's
operation and history to be acting in an authoritative role.
But NONE of that is of much importance when compared to this:
The clued do not read comp.lang.perl
Why would you want to ask questions where there are few people with clues?
Post your Perl question to comp.lang.perl and 20 newbies will read it.
Post it to comp.lang.perl.(misc|moderated) and hundreds of people who have used
Perl for years will read it.
You choose who you want answers from...
> It really is
> unfortunate that so many people regard Google as a useful information
> resource, isn't it?
I did not say anything at all about Google, so I don't know
what you are going on about there...
> Incidentally, when I finally had a bit of free time this morning, I
> rethought the technical problem and did come up with a trivial
> regex-based solution. It did exactly what I required on the first
> attempt, confirming that the technical problem was pretty much as
> trivial as I had thought it was.
Working once with one set of data is not what most people
would term "confirmation".
Perhaps you have just not tried it with a data set that exposes
it weakness (if any)?
> Why did the newsgroups fail to produce the technically trivial answer?
Because there was no technically trivial answer.
> I asked a simple technical question,
> and wound up being dragged into a religious war about proper ways to
> handle HTML.
It was not a religious war. It was a mathematical war.
> Not very useful.
Mathematics (Set Theory) is very useful for parsing grammars.
> I still regard regular expressions as useful and worthy of further
> study.
Me too. I did not say that they were not.
Regexs are great for tokeninizing, but hopeless for the real parsing.
> I cannot say the same thing about most of the people who
> responded so religiously to my trivial question.
Your question was not as trivial as you seem to think.
(that was the point of many of the followups.)
It can be proven (in the mathematical sense) that a Regular
Expression cannot parse a Context Free Grammar (which HTML is).[1]
You can do it in special highly-restricted cases, but not in
the general case. It is impossible.
[1] but Perl's regular expressions are no longer mathematical
Regular Expressions, they've mutated.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sat, 24 Jan 2004 05:26:52 GMT
From: "John W. Kennedy" <jwkenne@attglobal.net>
Subject: Re: Regular expression to find <tr> tags in 2nd level HTML tables
Message-Id: <wmnQb.11281$O22.5275897@news4.srv.hcvlny.cv.net>
Shannon Jacobs wrote:
> I'm so sorry to hear that the Google Groups system has been "neglected
> for many years", as you put it so thoughtfully. It really is
> unfortunate that so many people regard Google as a useful information
> resource, isn't it?
Google Groups is an archive, and, as such, obviously does not delete
obsolete groups.
> Incidentally, when I finally had a bit of free time this morning, I
> rethought the technical problem and did come up with a trivial
> regex-based solution.
No you didn't, because it's impossible. Either you misstated your
requirement, your "solution" does not work, or it is not "regex-based".
> Oh yeah, I suppose I should give a hint about the solution, even
> though it's a bit embarrassing. (I don't mind much as long as I can
> feel I learned something along the way.) Returning to the problem
> fresh and without the "box" around my thoughts, I looked at the data
> files again and asked myself whether there was some other unique
> string associated with the data that was associated with the second
> level <tr> tags. I picked one of the likely candidates, and sure
> enough, it worked.
In other words, you came up with an ad-hoc solution that does not
involve the use of regex's for parsing (which regex's cannot do), and
which no-one here could possibly have thought of, since it involves
facts that you never mentioned.
That's a cute job of drawing your target around the bullet holes, but
you can't really expect adults to be impressed by that, can you?
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
------------------------------
Date: Wed, 21 Jan 2004 16:39:07 -0500
From: Yan Wu <wu26@cs.purdue.edu>
Subject: restriction on file handle
Message-Id: <400EF17B.B6434F78@cs.purdue.edu>
HI,
In the below script, "info1" is never defined but it could still run
correctly.
Is there any way to restrict the use of undefined file handle?
Thanks.
Yan
#!/p/perl/bin/perl -w
#
# Program to open the password file, read it in,
# print it, and close it again.
use strict;
use FileHandle;
my $file;
my @lines;
$file = 'myfile'; # Name the file
open(info1, $file); # Open the file
@lines = <info1>; # Read it into an array
close(info1); # Close the file
print @lines; # Print the array
------------------------------
Date: 21 Jan 2004 22:03:14 GMT
From: roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson)
Subject: Re: restriction on file handle
Message-Id: <bumsv2$q3c$1@canopus.cc.umanitoba.ca>
In article <400EF17B.B6434F78@cs.purdue.edu>,
Yan Wu <wu26@cs.purdue.edu> wrote:
: In the below script, "info1" is never defined but it could still run
:correctly.
: Is there any way to restrict the use of undefined file handle?
I don't understand?
:open(info1, $file); # Open the file
You define it right there.
Perhaps you meant to write about:
open($info1, $file) or die "$file could not be opened";
@lines = <$info1>;
close($info1);
If so then your 'use strict' would complain.
--
So you found your solution
What will be your last contribution?
-- Supertramp (Fool's Overture)
------------------------------
Date: Wed, 21 Jan 2004 22:36:59 -0000
From: "David K. Wall" <dwall@fastmail.fm>
Subject: Re: restriction on file handle
Message-Id: <Xns9477B333EF16Edkwwashere@216.168.3.30>
Yan Wu <wu26@cs.purdue.edu> wrote:
Purdue, eh? I bet spaf is a good teacher.
> HI,
> In the below script, "info1" is never defined but it could still run
> correctly.
Sure it is. You define it when you open the file.
> Is there any way to restrict the use of undefined file handle?
Check to see if the open is successful. (see below)
> Thanks.
> Yan
>
>
> #!/p/perl/bin/perl -w
For recent versions of Perl you can use the warnings pragma for more
control (if you need it).
use warnings;
instead of -w.
> #
> # Program to open the password file, read it in,
> # print it, and close it again.
> use strict;
Strictures in place. Good.
> use FileHandle;
What's this for? You don't use it anywhere.
>
> my $file;
> my @lines;
>
>
> $file = 'myfile'; # Name the file
You can initialize this at the same time you declare it (if you want):
my $file = 'myfile';
> open(info1, $file); # Open the file
You should *always* check to see if an open() succeeded. The convention is
also to use capital letters for filehandles; it's not technically necessary
but will make it easier for other people to read your code.
open INFO1, $file or die "Cannot open $file: $!";
> @lines = <info1>; # Read it into an array
There's nothing wrong with slurping in "small" files, but if you suspect
the file could be "large" you might want to process it line-by-line. These
are relative terms; they depend on what you're doing and the resources
available.
> close(info1); # Close the file
> print @lines; # Print the array
Since all you're doing is printing the file, you don't really even need
that @lines array. For example,
print <INFO1>;
will print the contents of the file associated with the INFO1 filehandle.
You also don't have to comment every single line of code. Comments are for
explaining *why* some code exists, or to give a high-level explanation of
what's going on. That is, they're notes to yourself or future maintenance
programmers to make fixing or modifying the code easier.
--
David Wall
------------------------------
Date: Wed, 21 Jan 2004 22:41:55 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: restriction on file handle
Message-Id: <bumv7j$hup$1@wisteria.csv.warwick.ac.uk>
Yan Wu <wu26@cs.purdue.edu> wrote:
> HI,
> In the below script, "info1" is never defined but it could still run
> correctly.
What do you mean by 'is never defined'? The filehandle info1 is
created by the open statement.
> Is there any way to restrict the use of undefined file handle?
This will only allow lexical filehandles:
use strict;
use subs qw/open/; # to override the builtin
sub open (\$;$@) {
# it is necessary to give the first arg separately
# as CORE::open has a prototype of (*;$@)
my ($fh, $first, @rest) = @_;
CORE::open $$fh, $first, @rest;
}
. This means that these
open my $info1, $file;
my $info1;
open $info1, $file;
will succeed whereas these
open info1, $file;
open *info1, $file;
open \*info1, $file;
open "info1", $file;
will fail at compile time.
Ben
--
Joy and Woe are woven fine,
A Clothing for the Soul divine William Blake
Under every grief and pine 'Auguries of Innocence'
Runs a joy with silken twine. ben@morrow.me.uk
------------------------------
Date: Wed, 21 Jan 2004 22:50:22 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: restriction on file handle
Message-Id: <bumvne$i44$1@wisteria.csv.warwick.ac.uk>
Ben Morrow <usenet@morrow.me.uk> wrote:
>
> This will only allow lexical filehandles:
OK, there's a case I missed:
my $fh = \*FH;
open $fh, "file";
and
my $fh = *FH;
open $fh, "file";
will succeed despite using a global FH. That's pretty obscure,
though...
Ben
--
$.=1;*g=sub{print@_};sub r($$\$){my($w,$x,$y)=@_;for(keys%$x){/main/&&next;*p=$
$x{$_};/(\w)::$/&&(r($w.$1,$x.$_,$y),next);$y eq\$p&&&g("$w$_")}};sub t{for(@_)
{$f&&($_||&g(" "));$f=1;r"","::",$_;$_&&&g(chr(0012))}};t # ben@morrow.me.uk
$J::u::s::t, $a::n::o::t::h::e::r, $P::e::r::l, $h::a::c::k::e::r, $.
------------------------------
Date: Wed, 21 Jan 2004 18:15:25 -0500
From: Yan Wu <wu26@cs.purdue.edu>
Subject: Re: restriction on file handle
Message-Id: <400F080D.705FAA2A@cs.purdue.edu>
Thanks a lot. This is what I want.
Yan
Ben Morrow wrote:
-
- use strict;
- use subs qw/open/; # to override the builti
------------------------------
Date: 21 Jan 2004 23:31:08 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: restriction on file handle
Message-Id: <bun23s$r2p$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Ben Morrow:
> Ben Morrow <usenet@morrow.me.uk> wrote:
>>
>> This will only allow lexical filehandles:
>
> OK, there's a case I missed:
>
> my $fh = \*FH;
> open $fh, "file";
>
> and
>
> my $fh = *FH;
> open $fh, "file";
>
> will succeed despite using a global FH. That's pretty obscure,
> though...
Not really. A filehandle in Perl is always a GLOB.
open my $fh, ...;
is just syntactic sugar and perl will internally generate a GLOB and
store a reference to it in $fh.
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: 22 Jan 2004 11:17:09 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: restriction on file handle
Message-Id: <buobfl$6t8$4@mamenchi.zrz.TU-Berlin.DE>
Yan Wu <wu26@cs.purdue.edu> wrote in comp.lang.perl.misc:
> Thanks a lot. This is what I want.
> Yan
>
> Ben Morrow wrote:
> -
> - use strict;
> - use subs qw/open/; # to override the builti
That's a pretty radical approach.
use warnings FATAL => 'closed';
in an appropriate scope is less intrusive.
Anno
------------------------------
Date: Thu, 22 Jan 2004 04:43:52 GMT
From: "edgrsprj" <edgrsprj@ix.netcom.com>
Subject: Results
Message-Id: <cyIPb.18701$q4.17984@newsread3.news.atl.earthlink.net>
Ok. Running against GW-Basic, one of my favorites, the Perl code looked
like it is about 10 times as fast. Although that is not extremely
impressive, it should do nicely.
Regarding documentation,
Your and Bob's notes contained enough information that I was able to
determine where the different function lists etc. are in the ActivePerl
documentation.
So, now to do some reading (actually, a lot of reading).
"edgrsprj" <edgrsprj@ix.netcom.com> wrote in message
news:dyHPb.18593$q4.17470@newsread3.news.atl.earthlink.net...
> Thanks Tad.
>
------------------------------
Date: Thu, 22 Jan 2004 18:57:00 GMT
From: Juha Laiho <Juha.Laiho@iki.fi>
Subject: Re: Results
Message-Id: <bup6dh$1gj$1@ichaos.ichaos-int>
"edgrsprj" <edgrsprj@ix.netcom.com> said:
>Ok. Running against GW-Basic, one of my favorites, the Perl code looked
>like it is about 10 times as fast. Although that is not extremely
>impressive, it should do nicely.
Well, there's not much you can do to optimize a simple loop like that
(if that example loop was your benchmark). You'll see more difference
(in execution times, but also in development times) when your programs
and data structures get more complex. F.ex. try writing a program to
calculate word frequencies from a piece of text (and this is still what
you can consider a simple program in Perl, once you understand the tools
provided by the language).
One thing that in these very small benchmarks slows down perl is that
the code is first read in in full and then compiled into some kind of
bytecode, instead of being just interpreted line-by-line. This overhead
is most visible in small programs -- in larger programs the actual
program runtime becomes the primary factor.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
------------------------------
Date: Thu, 22 Jan 2004 22:25:40 GMT
From: "edgrsprj" <edgrsprj@ix.netcom.com>
Subject: Re: Results
Message-Id: <E5YPb.19933$i4.688@newsread1.news.atl.earthlink.net>
"Juha Laiho" <Juha.Laiho@iki.fi> wrote in message
news:bup6dh$1gj$1@ichaos.ichaos-int...
> "edgrsprj" <edgrsprj@ix.netcom.com> said:
> >Ok. Running against GW-Basic, one of my favorites, the Perl code looked
> >like it is about 10 times as fast. Although that is not extremely
> >impressive, it should do nicely.
> One thing that in these very small benchmarks slows down perl is that
> the code is first read in in full and then compiled into some kind of
> bytecode, instead of being just interpreted line-by-line. This overhead
> is most visible in small programs -- in larger programs the actual
> program runtime becomes the primary factor.
> --
Thanks. I understand what you are saying. I just wanted to make certain
that if I go through the trouble of jumping to Perl and trying to convince
other researchers that I work with to make the switch, there would be a
significant gain in calculation speed under even the worst of circumstances.
And that appears to be the case for the regular Perl programs. Next I will
probably try to see what happens when Perl code is used within an .html file
and also when it runs as a true CGI program.
------------------------------
Date: Tue, 30 Dec 2003 16:02:34 GMT
From: peter@PSDT.com (Peter Scott)
Subject: Re: retrieve webpage with POST
Message-Id: <ukhIb.870479$6C4.305499@pd7tw1no>
In article <bsqn5g$eog5$1@ID-184292.news.uni-berlin.de>,
Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
>Peter Scott wrote:
>> Gunnar Hjalmarsson writes:
>>>
>>> my $req=HTTP::Request->new(POST=>$url);
>>> $req->content_type('application/x-www-form-urlencoded');
>>> $req->content('field=1&valid=yes');
>>
>> This is unnecessarily fraught with danger.
>
>Danger? In that case, the POD for LWP.pm is dangerous, because its
>first example includes just those lines.
So it does. Perusal of Backpan reveals that those lines precede
the introduction of HTTP::Request::Common. I shall submit a patch.
Thank you for pointing them out.
>> And can you be certain without checking the source whether the
>> Content-length header will be set correctly ?
>
>Which source? I don't think it is set. Does it need to be?
That's my point; you're left wondering.
--
Peter Scott
http://www.perldebugged.com/
*** NEW *** http//www.perlmedic.com/
------------------------------
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 6043
***************************************
