[16482] in Perl-Users-Digest
Perl-Users Digest, Issue: 3894 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Aug 2 21:15:42 2000
Date: Wed, 2 Aug 2000 18:15:31 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <965265330-v9-i3894@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Wed, 2 Aug 2000 Volume: 9 Number: 3894
Today's topics:
Re: very cool routine <rbank@csf.edu>
Re: very cool routine <bkennedy99@home.com>
Re: very cool routine (Marcel Grunauer)
Re: very cool routine <rbank@csf.edu>
Re: very cool routine <rbank@csf.edu>
Re: very cool routine (Marcel Grunauer)
Re: very cool routine <rbank@csf.edu>
Re: very cool routine <rbank@csf.edu>
Re: very cool routine <elephant@squirrelgroup.com>
Re: very cool routine (Brandon Metcalf)
Re: very cool routine <rbank@csf.edu>
Re: very cool routine <elephant@squirrelgroup.com>
Re: very cool routine (Marcel Grunauer)
Re: very cool routine <rbank@csf.edu>
Re: very cool routine <rbank@csf.edu>
Re: very cool routine (Marcel Grunauer)
Re: very cool routine <rbank@csf.edu>
Re: very cool routine <rbank@csf.edu>
Re: very cool routine <rbank@csf.edu>
Re: very cool routine (Marcel Grunauer)
Re: very cool routine <godzilla@stomp.stomp.tokyo>
Re: very cool routine <rbank@csf.edu>
Re: very cool routine <rbank@csf.edu>
Re: very cool routine <flavell@mail.cern.ch>
Re: very cool routine <elephant@squirrelgroup.com>
Re: very cool routine <elephant@squirrelgroup.com>
Re: WWWBoard.PL <uri@sysarch.com>
Re: WWWBoard.PL <flavell@mail.cern.ch>
Re: WWWBoard.PL (brian d foy)
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 2 Aug 2000 16:08:51 -0600
From: "Robin Bank" <rbank@csf.edu>
Subject: Re: very cool routine
Message-Id: <8ma63j$oiu$1@reader.nmix.net>
PLUS...
I like mine better. You should too. It's easier to use. Less arguments.
Cheers,
--
< Robin Bank >
{ Web Design / Programming }
[ Internet @ Cybermesa ] [ www.cybermesa.com ] [ 505 - 988 - 9200 ]
"Robin Bank" <rbank@csf.edu> wrote in message
news:8ma51f$o2s$1@reader.nmix.net...
> splice ?
>
> *embarassed look*
>
> However...
>
> The splice function is not an operator, it is a function, and therefore no
> less big and bulky than mine... In fact, probably more so, because mine
is
> the bear minimum ammount of code needed. (pretty much)
>
> Later,
>
> --
> < Robin Bank >
> { Web Design / Programming }
> [ Internet @ Cybermesa ] [ www.cybermesa.com ] [ 505 - 988 - 9200 ]
>
>
>
------------------------------
Date: Wed, 02 Aug 2000 22:16:30 GMT
From: "Ben Kennedy" <bkennedy99@home.com>
Subject: Re: very cool routine
Message-Id: <251i5.77942$A%3.1081598@news1.rdc2.pa.home.com>
"Robin Bank" <rbank@csf.edu> wrote in message
news:8ma51f$o2s$1@reader.nmix.net...
> The splice function is not an operator, it is a function, and therefore no
> less big and bulky than mine... In fact, probably more so, because mine
is
> the bear minimum ammount of code needed. (pretty much)
In general, builtin functions tend to be signifigantly faster than user
defined functions since they are heavily optimed in C. The 'Benchmark'
module is good for determining relative speeds for code:
use Benchmark;
timethese(100000, {
"userfunc" =>
'my @array = qw(A B C D E F G H J);@array = del_element(3,@array);',
"builtin" =>
'my @array = qw(A B C D E F G H J);splice(@array,3,1);',
}
);
sub del_element
{
my ($element, @array) = @_;
my ($len, $count);
$len = @array;
$len = $len - 1;
$count = $element;
while ($count <= $len)
{
$array[$count] = $array[$count + 1];
$count++;
}
return (@array);
}
------------------------------
Date: Wed, 02 Aug 2000 22:30:07 GMT
From: marcel@codewerk.com (Marcel Grunauer)
Subject: Re: very cool routine
Message-Id: <slrn8oh8h3.819.marcel@gandalf.local>
On Wed, 2 Aug 2000 15:50:40 -0600, Robin Bank <rbank@csf.edu> wrote:
>splice ?
>
>*embarassed look*
>
>However...
>
>The splice function is not an operator, it is a function, and therefore no
>less big and bulky than mine... In fact, probably more so, because mine is
>the bear minimum ammount of code needed. (pretty much)
No need to guess, just use Benchmark. Basically, your function just
copies array elements almost ad nauseum, while splice() is lightning fast.
I would have liked to up the array length and count so the splice()
benchmark doesn't complain about "too few iterations", but I didn't have
all week to wait for your function to complete.
use Benchmark;
sub del_element {
my ($element, @array) = @_;
my ($len, $count);
$len = @array;
$len = $len - 1;
$count = $element;
while ($count <= $len) {
$array[$count] = $array[$count + 1];
$count++;
}
return (@array);
}
sub del_element_ref {
my ($element, $arrayref) = @_;
my ($len, $count);
$len = $#$arrayref;
$len = $len - 1;
$count = $element;
while ($count <= $len) {
$arrayref->[$count] = $arrayref->[$count + 1];
$count++;
}
}
my @a = my @b = my @c = (1..10000);
timethese(10000, {
'splice' => sub { splice @a, 0, 1 },
'del_element' => sub { @b = del_element(0, @b) },
'del_element_ref' => sub { del_element_ref(0, \@c) },
});
__END__
Benchmark:
timing 10000 iterations of del_element, del_element_ref, splice ...
del_element: 415 wallclock secs
(407.73 usr + 0.36 sys = 408.09 CPU) @ 24.50/s (n=10000)
del_element_ref: 245 wallclock secs
(238.33 usr + 0.18 sys = 238.51 CPU) @ 41.93/s (n=10000)
splice: 0 wallclock secs
( 0.01 usr + 0.00 sys = 0.01 CPU) @ 1000000.00/s (n=10000)
(warning: too few iterations for a reliable count)
Well, actually del_element doesn't shorten the @array, it just shifts
elements, but I believe that might have been your intention, so I've
benchmarked it against splice() anyway. And it's an unfair case, because
I'm always removing the first element (even though the list gets shorter
while benchmarking), but if your function is to be a replacement for
splice, it should hold up even in the worst case.
So not only is splice() faster by a few orders of magnitude, it _also_
can insert a replacement list with the 4-arg version _and_ splice returns
the spliced list.
It seems this has to do with the fact that you copy the whole array
twice (into the function and out of it), plus of course a core function
is _a lot_ faster than a function you build yourself (in Perl, anyway).
As you can see, the version of your function that accepts an array
reference still takes ages, but a lot of time is wasted just copying
arguments and function results.
--
Marcel
sub AUTOLOAD{($_=$AUTOLOAD)=~s;^.*::;;;y;_; ;;print} Just_Another_Perl_Hacker();
------------------------------
Date: Wed, 2 Aug 2000 16:56:15 -0600
From: "Robin Bank" <rbank@csf.edu>
Subject: Re: very cool routine
Message-Id: <8ma8sg$ppr$1@reader.nmix.net>
As for actual execution time, it is faster or at least the same speed as the
internal function, because the internal code is THE SAME, it's just a
subroutine, even though we never see the code for it. The actual typing in
of the code may not be faster. But, we got copy and paste for that...
--
< Robin Bank >
{ Web Design / Programming }
[ Internet @ Cybermesa ] [ www.cybermesa.com ] [ 505 - 988 - 9200 ]
"Uri Guttman" <uri@sysarch.com> wrote in message
news:x7og3b2ubd.fsf@home.sysarch.com...
> >>>>> "RB" == Robin Bank <rbank@csf.edu> writes:
>
> RB> splice ?
> RB> *embarassed look*
>
> you should.
>
> RB> The splice function is not an operator, it is a function, and
> RB> therefore no less big and bulky than mine... In fact, probably
> RB> more so, because mine is the bear minimum ammount of code
> RB> needed. (pretty much)
>
> hahaha! as if your perl code could be faster than the internal splice
> code. that is the whole purpose of having builtin functions, to make
> commonly done things faster and easier to code.
>
> i see you will soon worship at the feet of that golden troll,
> moronzilla. please leave and never darken my towels again!
>
> :-)
>
> uri
>
> --
> Uri Guttman --------- uri@sysarch.com ----------
http://www.sysarch.com
> SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX
Consulting
> The Perl Books Page -----------
http://www.sysarch.com/cgi-bin/perl_books
> The Best Search Engine on the Net ----------
http://www.northernlight.com
------------------------------
Date: Wed, 2 Aug 2000 16:57:25 -0600
From: "Robin Bank" <rbank@csf.edu>
Subject: Re: very cool routine
Message-Id: <8ma8uk$pq0$1@reader.nmix.net>
OK, my bad...if they're written in C, I can see why they'd be faster. I was
under the impression that the builtin functions were written in perl.
Good deal,
--
< Robin Bank >
{ Web Design / Programming }
[ Internet @ Cybermesa ] [ www.cybermesa.com ] [ 505 - 988 - 9200 ]
"Ben Kennedy" <bkennedy99@home.com> wrote in message
news:251i5.77942$A%3.1081598@news1.rdc2.pa.home.com...
>
> "Robin Bank" <rbank@csf.edu> wrote in message
> news:8ma51f$o2s$1@reader.nmix.net...
>
> > The splice function is not an operator, it is a function, and therefore
no
> > less big and bulky than mine... In fact, probably more so, because mine
> is
> > the bear minimum ammount of code needed. (pretty much)
>
> In general, builtin functions tend to be signifigantly faster than user
> defined functions since they are heavily optimed in C. The 'Benchmark'
> module is good for determining relative speeds for code:
>
> use Benchmark;
>
> timethese(100000, {
> "userfunc" =>
> 'my @array = qw(A B C D E F G H J);@array =
del_element(3,@array);',
> "builtin" =>
> 'my @array = qw(A B C D E F G H J);splice(@array,3,1);',
> }
> );
>
>
> sub del_element
> {
> my ($element, @array) = @_;
> my ($len, $count);
> $len = @array;
> $len = $len - 1;
> $count = $element;
> while ($count <= $len)
> {
> $array[$count] = $array[$count + 1];
> $count++;
> }
> return (@array);
> }
>
>
>
>
------------------------------
Date: Wed, 02 Aug 2000 22:56:01 GMT
From: marcel@codewerk.com (Marcel Grunauer)
Subject: Re: very cool routine
Message-Id: <slrn8oha2i.97i.marcel@gandalf.local>
On Wed, 2 Aug 2000 16:56:15 -0600, Robin Bank <rbank@csf.edu> wrote:
>As for actual execution time, it is faster or at least the same speed as the
>internal function, because the internal code is THE SAME, it's just a
>subroutine, even though we never see the code for it. The actual typing in
>of the code may not be faster. But, we got copy and paste for that...
Please, don't talk rubbish. Test it and you'll see. The splice()
function is implemented in C, and even if you took the code for it and
rewrote it one-to-one (as far as possible) in Perl, you'll never get
the same performance, because using Perl you're dealing with perl's
internal representation of variables and you don't have access to fast
memory-copying functions (unless you use splice).
But, good thing that splicing an array help luserzilla with natural
language emulation!
--
Marcel
sub AUTOLOAD{($_=$AUTOLOAD)=~s;^.*::;;;y;_; ;;print} Just_Another_Perl_Hacker();
------------------------------
Date: Wed, 2 Aug 2000 17:04:07 -0600
From: "Robin Bank" <rbank@csf.edu>
Subject: Re: very cool routine
Message-Id: <8ma9b6$q1i$1@reader.nmix.net>
Well, first off...
You're a total geek ;-)
second, the reason for the speed difference is partly the stuff you said,
but mainly because the builtin functions are written in C as you will read
on a previous post.
C is fast.
PERL is comparably extremely slow.
Copiler VS Interpreter
Later,
--
< Robin Bank >
{ Web Design / Programming }
[ Internet @ Cybermesa ] [ www.cybermesa.com ] [ 505 - 988 - 9200 ]
"Marcel Grunauer" <marcel@codewerk.com> wrote in message
news:slrn8oh8h3.819.marcel@gandalf.local...
> On Wed, 2 Aug 2000 15:50:40 -0600, Robin Bank <rbank@csf.edu> wrote:
>
> >splice ?
> >
> >*embarassed look*
> >
> >However...
> >
> >The splice function is not an operator, it is a function, and therefore
no
> >less big and bulky than mine... In fact, probably more so, because mine
is
> >the bear minimum ammount of code needed. (pretty much)
>
>
> No need to guess, just use Benchmark. Basically, your function just
> copies array elements almost ad nauseum, while splice() is lightning fast.
>
> I would have liked to up the array length and count so the splice()
> benchmark doesn't complain about "too few iterations", but I didn't have
> all week to wait for your function to complete.
>
>
> use Benchmark;
>
> sub del_element {
> my ($element, @array) = @_;
> my ($len, $count);
> $len = @array;
> $len = $len - 1;
> $count = $element;
> while ($count <= $len) {
> $array[$count] = $array[$count + 1];
> $count++;
> }
> return (@array);
> }
>
> sub del_element_ref {
> my ($element, $arrayref) = @_;
> my ($len, $count);
> $len = $#$arrayref;
> $len = $len - 1;
> $count = $element;
> while ($count <= $len) {
> $arrayref->[$count] = $arrayref->[$count + 1];
> $count++;
> }
> }
>
> my @a = my @b = my @c = (1..10000);
>
> timethese(10000, {
> 'splice' => sub { splice @a, 0, 1 },
> 'del_element' => sub { @b = del_element(0, @b) },
> 'del_element_ref' => sub { del_element_ref(0, \@c) },
> });
>
> __END__
>
> Benchmark:
> timing 10000 iterations of del_element, del_element_ref, splice ...
>
> del_element: 415 wallclock secs
> (407.73 usr + 0.36 sys = 408.09 CPU) @ 24.50/s (n=10000)
> del_element_ref: 245 wallclock secs
> (238.33 usr + 0.18 sys = 238.51 CPU) @ 41.93/s (n=10000)
> splice: 0 wallclock secs
> ( 0.01 usr + 0.00 sys = 0.01 CPU) @ 1000000.00/s (n=10000)
> (warning: too few iterations for a reliable count)
>
>
>
> Well, actually del_element doesn't shorten the @array, it just shifts
> elements, but I believe that might have been your intention, so I've
> benchmarked it against splice() anyway. And it's an unfair case, because
> I'm always removing the first element (even though the list gets shorter
> while benchmarking), but if your function is to be a replacement for
> splice, it should hold up even in the worst case.
>
> So not only is splice() faster by a few orders of magnitude, it _also_
> can insert a replacement list with the 4-arg version _and_ splice returns
> the spliced list.
>
> It seems this has to do with the fact that you copy the whole array
> twice (into the function and out of it), plus of course a core function
> is _a lot_ faster than a function you build yourself (in Perl, anyway).
>
> As you can see, the version of your function that accepts an array
> reference still takes ages, but a lot of time is wasted just copying
> arguments and function results.
>
>
> --
> Marcel
> sub AUTOLOAD{($_=$AUTOLOAD)=~s;^.*::;;;y;_; ;;print}
Just_Another_Perl_Hacker();
------------------------------
Date: Wed, 2 Aug 2000 17:09:34 -0600
From: "Robin Bank" <rbank@csf.edu>
Subject: Re: very cool routine
Message-Id: <8ma9n4$q1s$1@reader.nmix.net>
my bad... I wasn't aware they were written in C.
That explains it.
However, say you install a module which has a routine which is exactly the
same length and has the same functionality as a regular subroutine, the
routine in the module will be the same speed as the subroutine since they're
both written in PERL.
The source of this confusion stems from thinking that the perl builtin
functions were written in PERL and just imported automatically at run-time.
I was wrong! It's not faster. It's much slower.
But I ain't stupid as you claim.
>i see you will soon worship at the feet of that golden troll,
>moronzilla. please leave and never darken my towels again!
Later,
--
< Robin Bank >
{ Web Design / Programming }
[ Internet @ Cybermesa ] [ www.cybermesa.com ] [ 505 - 988 - 9200 ]
"Robin Bank" <rbank@csf.edu> wrote in message
news:8ma8sg$ppr$1@reader.nmix.net...
> As for actual execution time, it is faster or at least the same speed as
the
> internal function, because the internal code is THE SAME, it's just a
> subroutine, even though we never see the code for it. The actual typing in
> of the code may not be faster. But, we got copy and paste for that...
>
> --
> < Robin Bank >
> { Web Design / Programming }
> [ Internet @ Cybermesa ] [ www.cybermesa.com ] [ 505 - 988 - 9200 ]
>
> "Uri Guttman" <uri@sysarch.com> wrote in message
> news:x7og3b2ubd.fsf@home.sysarch.com...
> > >>>>> "RB" == Robin Bank <rbank@csf.edu> writes:
> >
> > RB> splice ?
> > RB> *embarassed look*
> >
> > you should.
> >
> > RB> The splice function is not an operator, it is a function, and
> > RB> therefore no less big and bulky than mine... In fact, probably
> > RB> more so, because mine is the bear minimum ammount of code
> > RB> needed. (pretty much)
> >
> > hahaha! as if your perl code could be faster than the internal splice
> > code. that is the whole purpose of having builtin functions, to make
> > commonly done things faster and easier to code.
> >
> > i see you will soon worship at the feet of that golden troll,
> > moronzilla. please leave and never darken my towels again!
> >
> > :-)
> >
> > uri
> >
> > --
> > Uri Guttman --------- uri@sysarch.com ----------
> http://www.sysarch.com
> > SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX
> Consulting
> > The Perl Books Page -----------
> http://www.sysarch.com/cgi-bin/perl_books
> > The Best Search Engine on the Net ----------
> http://www.northernlight.com
>
>
------------------------------
Date: Wed, 02 Aug 2000 23:10:15 GMT
From: jason <elephant@squirrelgroup.com>
Subject: Re: very cool routine
Message-Id: <MPG.13f347b56910685a9896b1@news>
Robin Bank writes ..
>The splice function is not an operator, it is a function, and therefore no
>less big and bulky than mine... In fact, probably more so, because mine is
>the bear minimum ammount of code needed. (pretty much)
ok .. backgrounding the complete ignorance in your comparison of a Perl
routing with an internal function for a second .. your function is
certainly NOT the minimum code .. nor will it generate the least amount
of work for the machine
>< Robin Bank >
>{ Web Design / Programming }
>[ Internet @ Cybermesa ] [ www.cybermesa.com ] [ 505 - 988 - 9200 ]
I'll add you to my list of companies to avoid .. thanks
--
jason -- elephant@squirrelgroup.com --
------------------------------
Date: 2 Aug 2000 22:30:13 GMT
From: bmetcalf@nortelnetworks.com (Brandon Metcalf)
Subject: Re: very cool routine
Message-Id: <8ma7dl$qoc$1@bcrkh13.ca.nortel.com>
rbank@csf.edu writes:
> splice ?
>
> *embarassed look*
>
> However...
>
> The splice function is not an operator, it is a function, and therefore no
> less big and bulky than mine... In fact, probably more so, because mine is
> the bear minimum ammount of code needed. (pretty much)
Splice is a builtin function and you'll find that it is much, much
faster than your code. Benchmark it if you wish. You shouldn't try
defending yourself on this one.
Brandon
------------------------------
Date: Wed, 2 Aug 2000 17:12:35 -0600
From: "Robin Bank" <rbank@csf.edu>
Subject: Re: very cool routine
Message-Id: <8ma9rd$q25$1@reader.nmix.net>
Yep. I realize this now. Read my reply.
--
< Robin Bank >
{ Web Design / Programming }
[ Internet @ Cybermesa ] [ www.cybermesa.com ] [ 505 - 988 - 9200 ]
"Marcel Grunauer" <marcel@codewerk.com> wrote in message
news:slrn8oha2i.97i.marcel@gandalf.local...
> On Wed, 2 Aug 2000 16:56:15 -0600, Robin Bank <rbank@csf.edu> wrote:
>
> >As for actual execution time, it is faster or at least the same speed as
the
> >internal function, because the internal code is THE SAME, it's just a
> >subroutine, even though we never see the code for it. The actual typing
in
> >of the code may not be faster. But, we got copy and paste for that...
>
>
> Please, don't talk rubbish. Test it and you'll see. The splice()
> function is implemented in C, and even if you took the code for it and
> rewrote it one-to-one (as far as possible) in Perl, you'll never get
> the same performance, because using Perl you're dealing with perl's
> internal representation of variables and you don't have access to fast
> memory-copying functions (unless you use splice).
>
>
> But, good thing that splicing an array help luserzilla with natural
> language emulation!
>
>
> --
> Marcel
> sub AUTOLOAD{($_=$AUTOLOAD)=~s;^.*::;;;y;_; ;;print}
Just_Another_Perl_Hacker();
------------------------------
Date: Wed, 02 Aug 2000 23:12:56 GMT
From: jason <elephant@squirrelgroup.com>
Subject: Re: very cool routine
Message-Id: <MPG.13f34854b65b15ee9896b2@news>
Robin Bank writes ..
>I like mine better. You should too. It's easier to use. Less arguments.
ahh .. so you really CAN'T read the documentation at all then .. splice
will accept two arguments .. the array and the index of the element to
be deleted .. in reverse order to your lame routine .. but it's still
pretty simple
splice @array, $index;
--
jason -- elephant@squirrelgroup.com --
------------------------------
Date: Wed, 02 Aug 2000 23:07:02 GMT
From: marcel@codewerk.com (Marcel Grunauer)
Subject: Re: very cool routine
Message-Id: <slrn8oham9.9es.marcel@gandalf.local>
On Wed, 2 Aug 2000 17:04:07 -0600, Robin Bank <rbank@csf.edu> wrote:
>
>You're a total geek ;-)
I take it as a compliment...
>second, the reason for the speed difference is partly the stuff you said,
>but mainly because the builtin functions are written in C as you will read
>on a previous post.
Yup.
>C is fast.
>PERL is comparably extremely slow.
Well, it depends. For pure number crunching or function that more or
less directly manipulate memory, then yes, Perl is slow. But Perl also
provides you with so many goodies (like hashes, regular expressions, map,
grep, fast array manipulation functions etc.) which you would otherwise
have to program yourself in C, so it's still pretty fast.
The rule of thumb is simply to use a Perl function instead of rewriting
it in Perl, and to make use of idiomatic Perl, then your programs will
run fast.
--
Marcel
sub AUTOLOAD{($_=$AUTOLOAD)=~s;^.*::;;;y;_; ;;print} Just_Another_Perl_Hacker();
------------------------------
Date: Wed, 2 Aug 2000 17:24:47 -0600
From: "Robin Bank" <rbank@csf.edu>
Subject: Re: very cool routine
Message-Id: <8maahu$qhs$1@reader.nmix.net>
> I'll add you to my list of companies to avoid .. thanks
I'll add you to my list of geeks without a life who, knowing they're ugly as
hell, spend the entire day (and night) hacking perl to impress other such
geeks.
I tend to avoid such people.
In fact, I generally don't have to work too hard at it, since these hermit
types hardly ever come out into the light of day where I may encounter them.
Have a good one "jason"
--
< Robin Bank >
{ Web Design / Programming }
[ Internet @ Cybermesa ] [ www.cybermesa.com ] [ 505 - 988 - 9200 ]
------------------------------
Date: Wed, 2 Aug 2000 17:26:06 -0600
From: "Robin Bank" <rbank@csf.edu>
Subject: Re: very cool routine
Message-Id: <8maakd$qi2$1@reader.nmix.net>
> You shouldn't try
> defending yourself on this one.
Next time I won't. Can't you read the previous posts?? It was a
misunderstanding. I was un-aware that the builtin functions were written in
C rather than PERL...
--
< Robin Bank >
{ Web Design / Programming }
[ Internet @ Cybermesa ] [ www.cybermesa.com ] [ 505 - 988 - 9200 ]
------------------------------
Date: Wed, 02 Aug 2000 23:23:01 GMT
From: marcel@codewerk.com (Marcel Grunauer)
Subject: Re: very cool routine
Message-Id: <slrn8ohbl5.9es.marcel@gandalf.local>
On Wed, 2 Aug 2000 17:26:06 -0600, Robin Bank <rbank@csf.edu> wrote:
>> You shouldn't try
>> defending yourself on this one.
>
>Next time I won't. Can't you read the previous posts?? It was a
>misunderstanding. I was un-aware that the builtin functions were written in
>C rather than PERL...
Sometimes people are on slow newsfeeds, so he might not have read your
posts before writing his response.
--
Marcel
sub AUTOLOAD{($_=$AUTOLOAD)=~s;^.*::;;;y;_; ;;print} Just_Another_Perl_Hacker();
------------------------------
Date: Wed, 2 Aug 2000 17:30:30 -0600
From: "Robin Bank" <rbank@csf.edu>
Subject: Re: very cool routine
Message-Id: <8maasl$qig$1@reader.nmix.net>
Actually, no matter how you put it, C code is gonna run faster. You could
re-write all the PERL "goodies" in C and the program would still be hella
faster since it's a compiled lang and writes directly to the machine instead
of using an interpreter.
However, PERL is a hell of a lot faster in terms of writing a program used
for "Practical Extraction and Report" - hell, that's why I use PERL, the
coding time is a whole lot better.
--
< Robin Bank >
{ Web Design / Programming }
> I take it as a compliment...
>
> >second, the reason for the speed difference is partly the stuff you said,
> >but mainly because the builtin functions are written in C as you will
read
> >on a previous post.
>
> Yup.
>
> >C is fast.
> >PERL is comparably extremely slow.
>
> Well, it depends. For pure number crunching or function that more or
> less directly manipulate memory, then yes, Perl is slow. But Perl also
> provides you with so many goodies (like hashes, regular expressions, map,
> grep, fast array manipulation functions etc.) which you would otherwise
> have to program yourself in C, so it's still pretty fast.
>
> The rule of thumb is simply to use a Perl function instead of rewriting
> it in Perl, and to make use of idiomatic Perl, then your programs will
> run fast.
>
> --
> Marcel
> sub AUTOLOAD{($_=$AUTOLOAD)=~s;^.*::;;;y;_; ;;print}
Just_Another_Perl_Hacker();
------------------------------
Date: Wed, 2 Aug 2000 17:32:04 -0600
From: "Robin Bank" <rbank@csf.edu>
Subject: Re: very cool routine
Message-Id: <8maavj$qil$1@reader.nmix.net>
Oh really? The docs I read didn't show that notation. I did read 'em though-
actually not PERLdoc, a perl reference book.
--
< Robin Bank >
{ Web Design / Programming }
[ Internet @ Cybermesa ] [ www.cybermesa.com ] [ 505 - 988 - 9200 ]
> ahh .. so you really CAN'T read the documentation at all then .. splice
> will accept two arguments .. the array and the index of the element to
> be deleted .. in reverse order to your lame routine .. but it's still
> pretty simple
>
> splice @array, $index;
------------------------------
Date: Wed, 2 Aug 2000 17:34:54 -0600
From: "Robin Bank" <rbank@csf.edu>
Subject: Re: very cool routine
Message-Id: <8mab4t$qpv$1@reader.nmix.net>
Sorry man,
I take that last flame back. Just in a pissy mood.
Later,
--
< Robin Bank >
{ Web Design / Programming }
[ Internet @ Cybermesa ] [ www.cybermesa.com ] [ 505 - 988 - 9200 ]
> I'll add you to my list of companies to avoid .. thanks
------------------------------
Date: Wed, 02 Aug 2000 23:27:59 GMT
From: marcel@codewerk.com (Marcel Grunauer)
Subject: Re: very cool routine
Message-Id: <slrn8ohbv0.9sl.marcel@gandalf.local>
On Wed, 2 Aug 2000 17:30:30 -0600, Robin Bank <rbank@csf.edu> wrote:
>Actually, no matter how you put it, C code is gonna run faster. You could
>re-write all the PERL "goodies" in C and the program would still be hella
>faster since it's a compiled lang and writes directly to the machine instead
>of using an interpreter.
>
>However, PERL is a hell of a lot faster in terms of writing a program used
>for "Practical Extraction and Report" - hell, that's why I use PERL, the
>coding time is a whole lot better.
Precisely. It's the one point I forgot to make before sending that post;
that development speed matters (a lot) as well.
Frankly I don't care whether a program I run from the shell every now
and then takes a millisecond or three seconds; what matters is that you
can do it in Perl in a few minutes versus quite a few hours in C or some
other low-level language.
Glad we agree :)
--
Marcel
sub AUTOLOAD{($_=$AUTOLOAD)=~s;^.*::;;;y;_; ;;print} Just_Another_Perl_Hacker();
------------------------------
Date: Wed, 02 Aug 2000 16:52:49 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: very cool routine
Message-Id: <3988B451.98E80F41@stomp.stomp.tokyo>
Robin Bank wrote:
(snipped)
> second, the reason for the speed difference is partly the
> stuff you said, but mainly because the builtin functions
> are written in C as you will read on a previous post.
> C is fast.
> PERL is comparably extremely slow.
> Copiler VS Interpreter
(snipped)
Ummm... Mr. Bank, I really must object. If you employ
good logic, cite truisms, state facts and debate issues
based on rational thinking, these people, well... their
brains will explode. This would be messy. I will not have
you making a mess within my newsgroup.
Godzilla!
------------------------------
Date: Wed, 2 Aug 2000 18:00:21 -0600
From: "Robin Bank" <rbank@csf.edu>
Subject: Re: very cool routine
Message-Id: <8mackk$ra0$1@reader.nmix.net>
yeah, finally someone agrees with me :-)
And, yeah, leave the "few milleseconds" to the supergeeks...
--
< Robin Bank >
{ Web Design / Programming }
[ Internet @ Cybermesa ] [ www.cybermesa.com ] [ 505 - 988 - 9200 ]
> Glad we agree :)
------------------------------
Date: Wed, 2 Aug 2000 18:00:57 -0600
From: "Robin Bank" <rbank@csf.edu>
Subject: Re: very cool routine
Message-Id: <8maclo$ra1$1@reader.nmix.net>
OK.. Good answer.
> >Next time I won't. Can't you read the previous posts?? It was a
> >misunderstanding. I was un-aware that the builtin functions were written
in
> >C rather than PERL...
------------------------------
Date: Thu, 3 Aug 2000 01:56:14 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: very cool routine
Message-Id: <Pine.GHP.4.21.0008030149380.17469-100000@hpplus03.cern.ch>
On Wed, 2 Aug 2000, Robin Bank wrote:
> Later,
What is it about upside-down fullquoters that they can't post anything
useful or sensible? Score appropriately adjusted, preparatory to
you-know-what.
> { Web Design / Programming }
Heaven forfend.
------------------------------
Date: Thu, 03 Aug 2000 00:36:50 GMT
From: jason <elephant@squirrelgroup.com>
Subject: Re: very cool routine
Message-Id: <MPG.13f35c07a9c5f4609896b3@news>
Robin Bank writes ..
>Sorry man,
>I take that last flame back. Just in a pissy mood.
your apology is bemusingly accepted
--
jason -- elephant@squirrelgroup.com --
------------------------------
Date: Thu, 03 Aug 2000 00:54:11 GMT
From: jason <elephant@squirrelgroup.com>
Subject: Re: very cool routine
Message-Id: <MPG.13f36016c7bee2c89896b4@news>
Robin Bank writes ..
>
>jason wrote ..
>>
>> ahh .. so you really CAN'T read the documentation at all then .. splice
>> will accept two arguments .. the array and the index of the element to
>> be deleted .. in reverse order to your lame routine .. but it's still
>> pretty simple
>>
>> splice @array, $index;
>
>Oh really? The docs I read didn't show that notation. I did read 'em though-
>actually not PERLdoc, a perl reference book.
chuck the book then .. if it doesn't cover everything then it's not
worth it - especially when there is so much included and free
documentation
while we're here .. it's Perl and not PERL .. the acronym lost it's
meaning a long time ago (this is also covered in the FAQ section of the
docs)
perldoc perlfaq1
and some general usenet tips .. post your reply beaneath or preferrably
interleved where appropriate with the original rather than above
posting the reply above is known affectionately (not) as jeopardy style
posting and is not conducive to this forum of discussion
also .. try to leave the attributions in .. so that subsequent readers
know who wrote what
[ jeopardectomy and re-attribution done ]
--
jason -- elephant@squirrelgroup.com --
------------------------------
Date: Wed, 02 Aug 2000 22:07:12 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: WWWBoard.PL
Message-Id: <x7lmyf2u7j.fsf@home.sysarch.com>
>>>>> "SJM" == Sara Jane Martin <saraj_martin@time-inc.com> writes:
SJM> I'm not saying this to promote Matt's scripts but as a person who
SJM> is new to perl, I like to "play with" bits of new scripts that I
SJM> can find to help myself out as a programmer and I was wondering
SJM> if it was even worth it with Matt's scripts. Or are they so bad
SJM> that they would just confuse me (and be potentially harmful)?
no. yes.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: Thu, 3 Aug 2000 00:27:52 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: WWWBoard.PL
Message-Id: <Pine.GHP.4.21.0008022338260.17369-100000@hpplus03.cern.ch>
[please post lines of the customary length, around 72 chars, and
trim your quotage down the the minimum relevant]
On Wed, 2 Aug 2000, Sara Jane Martin wrote:
> I recently went to www.worldwidemart.com/scripts to look at Matt's
> scripts simply because I was curious as to how they could be so
> bad that they have earned such a widespread reputation.
> Now, I can't really distinguish between good perl and bad perl
> because I am a new programmer
This is the problem, isn't it? There's absolutely no shame in being a
newcomer and even less in being curious, but if you immerse yourself
in poorly-written code it's harder to unlearn the bad habits than to
start off on (basically) the right foot.
> but I'm curious as to whether or not
> the "security patches" that are advertized in the new release do
> much good or not.
Let me make a specific point to you. If you base your implementation
on a well-respected package, in this case CGI.pm, then when a security
advisory comes out and the package gets fixed, you can take advantage
of the fix just as soon as you install the fixed package. Many a time
you'll get bug fixes you didn't even realise you need. And the same
goes for everyone else using your code.
If you're relying on hand-knitted code, which, as often as not, will
be spread around the whole of your source, then you have serious work
to do, to audit the code for the published vulnerability, decide how
to fix the problem, implement and test the fix and make sure to get it
out to everyone using your source.
Just sometimes, this might mean you get out a more timely fix than the
guy who supports the module: but in global terms it simply doesn't
scale.
> As Neil said, he found many problems with
> wwwboard in 1997 but have there been any significant improvements
> since then?
The code still has "Perl 4" programming style written all over it: it
takes no benefit of the improvements in Perl 5.
Even a relative dabbler like myself can see pieces of obvious
silliness:
$name = "$FORM{'name'}";
(useless use of quotes) followed by
$name =~ s/"//g;
$name =~ s/<//g;
$name =~ s/>//g;
$name =~ s/\&//g;
Should use a single tr instead of four separate statements (assuming
for the moment that this is actually doing anything that needs doing);
print NEWFILE "<html>\n";
print NEWFILE " <head>\n";
print NEWFILE " <title>$subject</title>\n";
print NEWFILE " </head>\n";
print NEWFILE " <body>\n";
print NEWFILE " <center>\n";
print NEWFILE " <h1>$subject</h1>\n";
print NEWFILE " </center>\n";
print NEWFILE "<hr size=7 width=75%>\n";
If one was determined to hand-knit this, this is a clear case for a
here-document (and the HTML it's generating is crap, but that's
another matter).
But amongst all those details - there seems to be nothing at all to
lock the files which it is updating. So it's a matter of chance and
statistics whether two updates attempted concurrently would trample
over each other. I COULD NOT FIND THE WORD 'lock' ANYWHERE IN THE
PACKAGE, not in the code, not in the readme, not in the FAQ. For any
CGI implementation that's going to open common files, this is simply
absurd.
And since there is no mention of "charset" anywhere in the script,
it's a fair assumption that it violates the security advice given in
CA-2000-02. And it's unaware of the serious security bug in X
Netscape 4 which recent versions of CGI.pm protect against, even for
those who're unaware of the bug themselves.
These are just a few random comments based on visual inspection of the
source code for a few minutes. The style is dreadful. If this is
meant to be version 2, then heaven help version 1.
The fact is, none of the serious people around here want to spend
their valuable time poring over the entrails of Matt's stuff; if they
did anything, they'd want to implement a proper solution instead of
tinkering with that - perfectly reasonable student exercise at the
time it was written, but long past its best-by date. So, you're stuck
with people like me shooting off their mouths, instead of
well-informed critiques.
You'd be much better to go and visit Randal's WebTechniques, if this
is the kind of scripting that you're interested in.
> I'm not saying this to promote Matt's scripts but as a person who
> is new to perl, I like to "play with" bits of new scripts that I
> can find to help myself out as a programmer
That's perfectly understandable and commendable, but I'd rather
steer you towards scripts that are better-engineered as a grounding.
And in fact it all gets much easier, because when the detail is
stashed away in well-designed modules (which you can later develop for
yourself), you can concentrate on what you're doing, without getting
submerged in the details. This is a vital principle of software
design: break the task into logical parts, implement them
independently and hide the details inside them; fit them together
across well-defined interworking interfaces to solve the task in hand.
Re-use them to solve related tasks.
That's my assessment, anyhow.
http://www.stonehenge.com/merlyn/WebTechniques/
------------------------------
Date: Wed, 02 Aug 2000 19:32:19 -0400
From: brian@smithrenaud.com (brian d foy)
Subject: Re: WWWBoard.PL
Message-Id: <brian-ya02408000R0208001932190001@news.panix.com>
In article <Pine.GHP.4.21.0008022338260.17369-100000@hpplus03.cern.ch>, "Alan J. Flavell" <flavell@mail.cern.ch> posted:
> The fact is, none of the serious people around here want to spend
> their valuable time poring over the entrails of Matt's stuff; if they
> did anything, they'd want to implement a proper solution instead of
> tinkering with that - perfectly reasonable student exercise at the
> time it was written, but long past its best-by date.
indeed. the security problem is the squeaky wheel in these scripts,
but the design and implementation just plain suck. look at the
threading model of WWWBoard some time. it's plain awful and opens up
al sorts of other problems.
if someone fixed all the problems, there would be no original code
left.
--
brian d foy
CGI Meta FAQ <URL:http://www.smithrenaud.com/public/CGI_MetaFAQ.html>
Perl Mongers <URL:http://www.perl.org/>
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 V9 Issue 3894
**************************************
