[12614] in Perl-Users-Digest
Perl-Users Digest, Issue: 23 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jul 6 19:47:16 1999
Date: Tue, 6 Jul 1999 16:36:39 -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 Tue, 6 Jul 1999 Volume: 9 Number: 23
Today's topics:
Benchmarking results (was: Re: hiring perl programmers) (Benjamin Franz)
Re: Benchmarking results (was: Re: hiring perl programm (Benjamin Franz)
Re: Benchmarking results (was: Re: hiring perl programm (Neko)
Re: Benchmarking results (was: Re: hiring perl programm (Benjamin Franz)
Re: Benchmarking results (was: Re: hiring perl programm (Neko)
Re: Benchmarking results (was: Re: hiring perl programm (Abigail)
Berkeley DB with Perl on NT (Larry Huang)
Bijeenkomst Amsterdam Perl Mongers, 6 juli 1999 johnpc@xs4all.net
Re: Bloated code <nospam.newton@gmx.net>
Re: Bloated code (Abigail)
Re: Bloated code <nospam.newton@gmx.net>
Re: Bloated code (Neko)
Re: Bloated code jfk120@my-deja.com
Re: Bloated code (Mike Kozlowski)
Browsing VHDL hierarch <kiran@ikos.com>
Cetus Links: looking for a Perl page maintainer <manfred.schneider@rhein-neckar.de>
cgi file access issues <kpmasse@cs.sandia.gov>
Re: CGI Help please... arpith@hotmail.com
Re: CGI Help please... arpith@hotmail.com
Re: CGI Help please... <cassell@mail.cor.epa.gov>
Digest Administrivia (Last modified: 1 Jul 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 04 Jul 1999 00:16:09 GMT
From: snowhare@long-lake.nihongo.org (Benjamin Franz)
Subject: Benchmarking results (was: Re: hiring perl programmers)
Message-Id: <dJxf3.836$vI3.56275@typhoon-sf.snfc21.pbi.net>
In article <377a5462@cs.colorado.edu>,
Tom Christiansen <tchrist@mox.perl.com> wrote:
>
>Rather tangential to your point, but not to the grandparent
>article, standard programming problems we made the interviewee write
>extemporanously, although in any programming language they cared to use,
>often included these:
>
> 1) You have an array of non-negative integers. Move all the
> zero-valued elements to the front of that array.
[...]
>
>Furthermore, they were told to pay especial attention to the space and
>time complexities of their algorithms.
Here are the results of benchmarking the algorithms that people
have posted in response to this (plus some experiments I
did here).
For the small dataset I tested with, 'neko2' is the fastest -
but for very large datasets it would slow down faster as it
used up the free memory. It would be a poor choice in
practice because although it is 30% faster than
the best of the O(N)/O(0) algorithms on small datasets -
that is precisely where small differences matter the
least.
The rankings on the 'zero light' datasets for only
the space O(0) ones are as follows:
bart2(1000): (2.38 CPU)
known_value_move2(1000): (2.65 CPU)
abigail(1000): (2.68 CPU)
known_value_move(1000): (2.74 CPU)
randal_mod_snowhare(1000): (2.93 CPU)
xor-both-typeglobbed(1000): (2.89 CPU)
xor-no-globs(1000): (2.89 CPU)
randal(1000): (2.99 CPU)
xor-one-typeglobbed(1000): (3.06 CPU)
For the 'zero heavy' datasets:
bart2(2): (2.96 CPU)
known_value_move2(2): (3.09 CPU)
known_value_move(2): (3.16 CPU)
abigail(2): (3.38 CPU)
xor-no-globs(2): (3.51 CPU)
randal_mod_snowhare(2): (3.76 CPU)
randal(2): (4.59 CPU)
xor-one-typeglobbed(2): (4.61 CPU)
xor-both-typeglobbed(2): (5.30 CPU)
The best of the O(N)/O(0) algorithms is 'bart2'.
The worst were the typeglobbed algorithms -
evidently the overhead in setting up the
typeglobs exceeds the cost of dereferencing
the arrays by a noticable amount.
Regardless, the fastest time O(0) one is only 1.76
times quicker than the slowest O(0) one in the worst
case tested. But we still get to razz Randal for
his performance. He should have spent more than
5 minutes on his code. :)
The raw data and the test source code follow.
Benjamin Franz
abigail(2): (3.38 CPU) O(N) time, O(0) space
abigail(5): (2.90 CPU)
abigail(10): (2.76 CPU)
abigail(1000): (2.68 CPU)
-----------------------------------------
bart1(2): (3.61 CPU) O(N) time, O(N) space
bart1(5): (3.07 CPU)
bart1(10): (2.82 CPU)
bart1(1000): (2.65 CPU)
-----------------------------------------
bart2(2): (2.96 CPU) O(N) time, O(0) space
bart2(5): (2.61 CPU)
bart2(10): (2.50 CPU)
bart2(1000): (2.38 CPU)
-----------------------------------------
known_value_move(2): (3.16 CPU) O(N) time, O(0) space
known_value_move(5): (2.93 CPU)
known_value_move(10): (2.83 CPU)
known_value_move(1000): (2.74 CPU)
-----------------------------------------
known_value_move2(2): (3.09 CPU) O(N) time, O(0) space
known_value_move2(5): (2.85 CPU)
known_value_move2(10): (2.77 CPU)
known_value_move2(1000): (2.65 CPU)
-----------------------------------------
neko1(2): (4.89 CPU) O(N)O(log N) time, O(N) space
neko1(5): (5.03 CPU)
neko1(10): (5.15 CPU)
neko1(1000): (5.90 CPU)
-----------------------------------------
neko2(2): (2.07 CPU) O(N) time, O(N) space
neko2(5): (2.22 CPU)
neko2(10): (2.21 CPU)
neko2(1000): (2.25 CPU)
-----------------------------------------
patrick(2): (5.13 CPU) O(N) time, O(N) space
patrick(5): (5.44 CPU)
patrick(10): (5.50 CPU)
patrick(1000): (5.65 CPU)
-----------------------------------------
randal(2): (4.59 CPU) O(N) time, O(0) space
randal(5): (3.63 CPU)
randal(10): (3.31 CPU)
randal(1000): (2.99 CPU)
-----------------------------------------
randal_mod_snowhare(2): (3.76 CPU) O(N) time, O(0) space
randal_mod_snowhare(5): (3.29 CPU)
randal_mod_snowhare(10): (3.10 CPU)
randal_mod_snowhare(1000): (2.93 CPU)
-----------------------------------------
xor-both-typeglobbed(2): (5.30 CPU) O(N) time, O(0) space
xor-both-typeglobbed(5): (3.91 CPU)
xor-both-typeglobbed(10): (3.40 CPU)
xor-both-typeglobbed(1000): (2.89 CPU)
-----------------------------------------
xor-no-globs(2): (3.51 CPU) O(N) time, O(0) space
xor-no-globs(5): (3.15 CPU)
xor-no-globs(10): (3.05 CPU)
xor-no-globs(1000): (2.89 CPU)
-----------------------------------------
xor-one-typeglobbed(2): (4.61 CPU) O(N) time, O(0) space
xor-one-typeglobbed(5): (3.70 CPU)
xor-one-typeglobbed(10): (3.39 CPU)
xor-one-typeglobbed(1000): (3.06 CPU)
#!/usr/bin/perl -w
use strict;
use Benchmark;
use vars qw($l $k);
timethese(100,{
'xor-both-typeglobbed(1000)' => sub { &double_globbed(1000)},
'xor-both-typeglobbed(10)' => sub { &double_globbed(10)},
'xor-both-typeglobbed(5)' => sub { &double_globbed(5)},
'xor-both-typeglobbed(2)' => sub { &double_globbed(2)},
'xor-one-typeglobbed(1000)' => sub { &single_globbed(1000)},
'xor-one-typeglobbed(10)' => sub { &single_globbed(10)},
'xor-one-typeglobbed(5)' => sub { &single_globbed(5)},
'xor-one-typeglobbed(2)' => sub { &single_globbed(2)},
'xor-no-globs(1000)' => sub { &no_globs(1000)},
'xor-no-globs(10)' => sub { &no_globs(10)},
'xor-no-globs(5)' => sub { &no_globs(5)},
'xor-no-globs(2)' => sub { &no_globs(2)},
'known_value_move(1000)' => sub { &known_value_move(1000) },
'known_value_move(10)' => sub { &known_value_move(10) },
'known_value_move(5)' => sub { &known_value_move(5) },
'known_value_move(2)' => sub { &known_value_move(2) },
'known_value_move2(1000)' => sub { &known_value_move2(1000) },
'known_value_move2(10)' => sub { &known_value_move2(10) },
'known_value_move2(5)' => sub { &known_value_move2(5) },
'known_value_move2(2)' => sub { &known_value_move2(2) },
'abigail(1000)' => sub { &abigail(1000) },
'abigail(10)' => sub { &abigail(10) },
'abigail(5)' => sub { &abigail(5) },
'abigail(2)' => sub { &abigail(2) },
'patrick(1000)' => sub { &patrick(1000) },
'patrick(10)' => sub { &patrick(10) },
'patrick(5)' => sub { &patrick(5) },
'patrick(2)' => sub { &patrick(2) },
'bart1(1000)' => sub { &bart1(1000) },
'bart1(10)' => sub { &bart1(10) },
'bart1(5)' => sub { &bart1(5) },
'bart1(2)' => sub { &bart1(2) },
'bart2(1000)' => sub { &bart2(1000) },
'bart2(10)' => sub { &bart2(10) },
'bart2(5)' => sub { &bart2(5) },
'bart2(2)' => sub { &bart2(2) },
'randal(1000)' => sub { &randal(1000) },
'randal(10)' => sub { &randal(10) },
'randal(5)' => sub { &randal(5) },
'randal(2)' => sub { &randal(2) },
'randal_mod_snowhare(1000)' => sub { &randal_mod_snowhare(1000) },
'randal_mod_snowhare(10)' => sub { &randal_mod_snowhare(10) },
'randal_mod_snowhare(5)' => sub { &randal_mod_snowhare(5) },
'randal_mod_snowhare(2)' => sub { &randal_mod_snowhare(2) },
'neko1(1000)' => sub { &neko1(1000) },
'neko1(10)' => sub { &neko1(10) },
'neko1(5)' => sub { &neko1(5) },
'neko1(2)' => sub { &neko1(2) },
'neko2(1000)' => sub { &neko2(1000) },
'neko2(10)' => sub { &neko2(10) },
'neko2(5)' => sub { &neko2(5) },
'neko2(2)' => sub { &neko2(2) },
});
sub patrick {
my $domain = shift;
my @array = map { int(rand($domain)) } (0..3000);
my (@zero,@other);
foreach (@array) {
push(@zero,$_) if $_ == 0;
push(@other,$_) if $_ != 0;
}
push(@zero,@other);
@array = @zero;
}
sub randal {
my $domain = shift;
my @array = map { int(rand($domain)) } (0..3000);
for (my ($left,$right) = (0, 0); $right <= $#array; ++$right) {
if ($array[$right] == 0) {
@array[$left,$right] = @array[$right,$left] unless $left == $right;
++$left;
}
}
}
sub bart1 {
my $domain = shift;
my @array = map { int(rand($domain)) } (0..3000);
my (@result);
foreach (@array) {
if($_) {
push @result, $_; # at end
} else {
unshift @result, $_; # at front
}
}
@array = @result;
}
sub bart2 {
my $domain = shift;
my @array = map { int(rand($domain)) } (0..3000);
my $k=0; # zero count
for(my $i=0;$i<=$#array;$i++) {
unless($array[$i]) {
# item i is zero
$array[$i] = $array[$k]; # move item k to position i
$array[$k++] = 0; # move zero into item k (cheating :)
# and increment zero count
}
}
}
sub neko1 {
my $domain = shift;
my @array = map { int(rand($domain)) } (0..3000);
@array = sort @array;
}
sub neko2 {
my $domain = shift;
my @array = map { int(rand($domain)) } (0..3000);
my $size = @array;
@array = grep $_, @array;
unshift @array, (0) x ($size - @array);
}
sub abigail {
my $domain = shift;
my @array = map { int(rand($domain)) } (0..3000);
for (my $i = my $j = 0; $i < @array; $i ++) {
next if $array [$i];
if ($i != $j) {@array [$i, $j] = @array [$j, $i];}
$j ++;
}
}
sub double_globbed {
my $domain = shift;
my @array = map { int(rand($domain)) } (0..3000);
local ($k,$l);
my $i=0; my $j=1;
until ($i == @array or $array[$i]) { $i++; $j++; }
for (;$j<@array; $j++) {
next if $array[$j];
local (*l) = \$array[$j];
local (*k) = \$array[$i++];
$k^=($l^=$k);
$l^=$k;
}
}
sub single_globbed {
my $domain = shift;
my @array = map { int(rand($domain)) } (0..3000);
local ($k);
my $i=0; my $j=1;
until ($i == @array or $array[$i]) { $i++; $j++; }
for (;$j<@array; $j++) {
next if $array[$j];
local (*k) = \$array[$i++];
$k^=($array[$j]^=$k);
$array[$j]^=$k;
}
}
sub no_globs {
my $domain = shift;
my @array = map { int(rand($domain)) } (0..3000);
my $i=0; my $j=1;
until ($i == @array or $array[$i]) { $i++; $j++; }
for (;$j<@array; $j++) {
next if $array[$j];
$array[$i]^=($array[$j]^=$array[$i]);
$array[$j]^=$array[$i++];
}
}
sub known_value_move {
my $domain = shift;
my @array = map { int(rand($domain)) } (0..3000);
my $i=0; my $j=1;
until ($i == @array or $array[$i]) { $i++; $j++; }
for (;$j<@array; $j++) {
next if $array[$j];
$array[$j] = $array[$i];
$array[$i++] = 0;
}
}
sub known_value_move2 {
my $domain = shift;
my @array = map { int(rand($domain)) } (0..3000);
my $i=0; my $j=1;
until ($i == @array or $array[$i]) { $i++; $j++; }
for (;$j<@array; $j++) {
until ($j == @array or not $array[$j++]) {};
$array[$j] = $array[$i];
$array[$i++] = 0;
}
}
sub randal_mod_snowhare {
my $domain = shift;
my @array = map { int(rand($domain)) } (0..3000);
my $i=0; my $j=1;
until ($i == @array or $array[$i]) { $i++; $j++; }
for (;$j<@array; $j++) {
next if $array[$j];
@array[$i++,$j] = @array[$j,$i];
}
}
------------------------------
Date: Sun, 04 Jul 1999 00:31:33 GMT
From: snowhare@long-lake.nihongo.org (Benjamin Franz)
Subject: Re: Benchmarking results (was: Re: hiring perl programmers)
Message-Id: <FXxf3.866$vI3.58879@typhoon-sf.snfc21.pbi.net>
In article <dJxf3.836$vI3.56275@typhoon-sf.snfc21.pbi.net>,
Benjamin Franz <snowhare@long-lake.nihongo.org> wrote:
A corrective note for precision freaks: The 'empty' version
which only loaded the array took 1.08 CPI*Secs. I
did not correct the numbers in the previous posting for
this.
>The rankings on the 'zero light' datasets for only
>the space O(0) ones are as follows:
Raw Corrected
> bart2(1000): (2.38 CPU) 1.08
> known_value_move2(1000): (2.65 CPU) 1.57
> abigail(1000): (2.68 CPU) 1.60
> known_value_move(1000): (2.74 CPU) 1.66
> randal_mod_snowhare(1000): (2.93 CPU) 1.85
> xor-both-typeglobbed(1000): (2.89 CPU) 1.81
> xor-no-globs(1000): (2.89 CPU) 1.81
> randal(1000): (2.99 CPU) 1.91
> xor-one-typeglobbed(1000): (3.06 CPU) 1.98
>
>For the 'zero heavy' datasets:
>
> bart2(2): (2.96 CPU) 1.88
> known_value_move2(2): (3.09 CPU) 2.01
> known_value_move(2): (3.16 CPU) 2.08
> abigail(2): (3.38 CPU) 2.30
> xor-no-globs(2): (3.51 CPU) 2.43
> randal_mod_snowhare(2): (3.76 CPU) 2.68
> randal(2): (4.59 CPU) 3.41
> xor-one-typeglobbed(2): (4.61 CPU) 3.53
> xor-both-typeglobbed(2): (5.30 CPU) 4.22
[..]
>Regardless, the fastest time O(0) one is only 1.76
(correction: 2.24)
--
Benjamin Franz
------------------------------
Date: 5 Jul 1999 05:13:47 GMT
From: tgy@chocobo.org (Neko)
Subject: Re: Benchmarking results (was: Re: hiring perl programmers)
Message-Id: <7lpeub$f4i$0@216.39.141.200>
On Sun, 04 Jul 1999 00:16:09 GMT, snowhare@long-lake.nihongo.org (Benjamin
Franz) wrote:
>In article <377a5462@cs.colorado.edu>,
>Tom Christiansen <tchrist@mox.perl.com> wrote:
>>
>> 1) You have an array of non-negative integers. Move all the
>> zero-valued elements to the front of that array.
>>
>>Furthermore, they were told to pay especial attention to the space and
>>time complexities of their algorithms.
>
>For the small dataset I tested with, 'neko2' is the fastest -
>but for very large datasets it would slow down faster as it
>used up the free memory. It would be a poor choice in
>practice because although it is 30% faster than
s/practice/this case/;
>the best of the O(N)/O(0) algorithms on small datasets -
>that is precisely where small differences matter the
>least.
For the task given, 'neko2' is wrong. For most problems though, N is small
and small differences add up.
Do all of these build an intermediate list?
@array = sort @array;
@array = grep /foo/, @array;
@array = map 2 * $_, @array;
$count = grep /foo/, @array;
map s/foo/bar/, @array;
@array = map $_->[0], sort, map [$_, (split)[-1]], @array;
--
Neko | tgy@chocobo.org | I want a moogle stuffy!
------------------------------
Date: Mon, 05 Jul 1999 15:06:31 GMT
From: snowhare@long-lake.nihongo.org (Benjamin Franz)
Subject: Re: Benchmarking results (was: Re: hiring perl programmers)
Message-Id: <XR3g3.1973$_M.111530@typhoon-sf.snfc21.pbi.net>
In article <7lpeub$f4i$0@216.39.141.200>, Neko <tgy@chocobo.org> wrote:
>On Sun, 04 Jul 1999 00:16:09 GMT, snowhare@long-lake.nihongo.org (Benjamin
>Franz) wrote:
>>
>>For the small dataset I tested with, 'neko2' is the fastest -
>>but for very large datasets it would slow down faster as it
>>used up the free memory. It would be a poor choice in
>>practice because although it is 30% faster than
>
>s/practice/this case/;
>
>>the best of the O(N)/O(0) algorithms on small datasets -
>>that is precisely where small differences matter the
>>least.
>
>For the task given, 'neko2' is wrong. For most problems though, N is small
>and small differences add up.
They only add up significantly if the routine is in a loop. Otherwise -
on my machine 3000 elements were processed in 0.048 seconds
by the *slowest* of the O(N)/O(0) routines in the worse case. This is
only 0.027 seconds slower than 'neko2' - the _fastest_ of the them
period on that size dataset.
And remember that Perl _never (at least until the program exits)_ gives
memory back to the operating system once used: Used once, used forever.
>Do all of these build an intermediate list?
>
> @array = sort @array;
>
> @array = grep /foo/, @array;
>
> @array = map 2 * $_, @array;
>
> $count = grep /foo/, @array;
> map s/foo/bar/, @array;
>
> @array = map $_->[0], sort, map [$_, (split)[-1]], @array;
Yes. Think about it: Where is the output data *WHILE* @array is being
'map/grep/sort/split'ed? You are throwing the resulting intermediate list
away ('map in a void context', FAQ 6.21, perlfaq6) in one case, but it is
still generated.
--
Benjamin Franz
------------------------------
Date: 5 Jul 1999 17:53:26 GMT
From: tgy@chocobo.org (Neko)
Subject: Re: Benchmarking results (was: Re: hiring perl programmers)
Message-Id: <7lqrem$8ap$0@216.39.141.200>
On Mon, 05 Jul 1999 15:06:31 GMT, snowhare@long-lake.nihongo.org (Benjamin
Franz) wrote:
>In article <7lpeub$f4i$0@216.39.141.200>, Neko <tgy@chocobo.org> wrote:
>>
>>Do all of these build an intermediate list?
>>
>> @array = sort @array;
>>
>> @array = grep /foo/, @array;
>>
>> @array = map 2 * $_, @array;
>>
>> $count = grep /foo/, @array;
>> map s/foo/bar/, @array;
>>
>> @array = map $_->[0], sort, map [$_, (split)[-1]], @array;
>
>Yes. Think about it: Where is the output data *WHILE* @array is being
>'map/grep/sort/split'ed? You are throwing the resulting intermediate list
>away ('map in a void context', FAQ 6.21, perlfaq6) in one case, but it is
>still generated.
I wish that perl would see the same array on each side of a map, grep, or
sort and decide to edit that array in place. I wish that grep in scalar
context would just increment a counter and return a total. I wish that map
in a void context gets fixed so that Abigail could have her cake and eat it
and not gain weight. And I wish that the Schwartzian Transform (or any other
map/grep/sort pipe) would likewise edit an array in place.
But my real wish? I just wish 'neko2' wasn't O(N) space. :)
--
Neko | tgy@chocobo.org | I want a moogle stuffy!
------------------------------
Date: 5 Jul 1999 15:01:33 -0500
From: abigail@delanet.com (Abigail)
Subject: Re: Benchmarking results (was: Re: hiring perl programmers)
Message-Id: <slrn7o23nr.h6v.abigail@alexandra.delanet.com>
Neko (tgy@chocobo.org) wrote on MMCXXXIV September MCMXCIII in
<URL:news:7lqrem$8ap$0@216.39.141.200>:
;; On Mon, 05 Jul 1999 15:06:31 GMT, snowhare@long-lake.nihongo.org (Benjamin
;; Franz) wrote:
;;
;; >In article <7lpeub$f4i$0@216.39.141.200>, Neko <tgy@chocobo.org> wrote:
;; >>
;; >>Do all of these build an intermediate list?
;; >>
;; >> @array = sort @array;
;; >>
;; >> @array = grep /foo/, @array;
;; >>
;; >> @array = map 2 * $_, @array;
;; >>
;; >> $count = grep /foo/, @array;
;; >> map s/foo/bar/, @array;
;; >>
;; >> @array = map $_->[0], sort, map [$_, (split)[-1]], @array;
;; >
;; >Yes. Think about it: Where is the output data *WHILE* @array is being
;; >'map/grep/sort/split'ed? You are throwing the resulting intermediate list
;; >away ('map in a void context', FAQ 6.21, perlfaq6) in one case, but it is
;; >still generated.
;;
;; I wish that perl would see the same array on each side of a map, grep, or
;; sort and decide to edit that array in place.
That isn't always possible. How about
@foo = map {$_ > 3 ? (1, 2, 3) : $_} $foo;
;; I wish that grep in scalar
;; context would just increment a counter and return a total.
That's reasonable, and it probably does.
;; I wish that map
;; in a void context gets fixed so that Abigail could have her cake and eat it
;; and not gain weight.
That's reasonable as well, yet noone on p5p wants to implement it.
And my knowledge of the perl internals is too limited to write a patch.
;; And I wish that the Schwartzian Transform (or any other
;; map/grep/sort pipe) would likewise edit an array in place.
But the entire point of having an ST is creating an different list to sort with.
;; But my real wish? I just wish 'neko2' wasn't O(N) space. :)
Abigail
--
perl5.004 -wMMath::BigInt -e'$^V=Math::BigInt->new(qq]$^F$^W783$[$%9889$^F47]
.qq]$|88768$^W596577669$%$^W5$^F3364$[$^W$^F$|838747$[8889739$%$|$^F673$%$^W]
.qq]98$^F76777$=56]);$^U=substr($]=>$|=>5)*(q.25..($^W=@^V))=>do{print+chr$^V
%$^U;$^V/=$^U}while$^V!=$^W'
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: 5 Jul 1999 17:28:00 GMT
From: lhuang@bsr6.uwaterloo.ca (Larry Huang)
Subject: Berkeley DB with Perl on NT
Message-Id: <7lqpv0$1qf$1@watserv3.uwaterloo.ca>
Hi Everyone,
I am wondering if anyone has any luck with using Berkeley DB with Perl
on Windows NT. I've set it up on Solaris and people using it reports
no problems. My next step is to do the same with NT, but couldn't get
info on how to go about it.
I've compiled Berkeley DB on NT, but couldn't find anything about how
to access it using Perl. Can it actually be done? I've emailed the
person that did the Perl developement (Parl Marquess) but he doesn't
run NT so couldn't help me much.
Thanks in advance.
Larry
ps. please post as well as email your responses, as the machine here
sometimes drops email and/or news posts.
------------------------------
Date: 4 Jul 1999 19:52:12 GMT
From: johnpc@xs4all.net
Subject: Bijeenkomst Amsterdam Perl Mongers, 6 juli 1999
Message-Id: <7lnc23$d8r$1@xs3.xs4all.nl>
[English version follows the dutch text]
Amsterdam.pm staat voor de "Amsterdamse Perl Mongers", een groep van
gebruikers van Perl. In tegenstelling tot wat de naam suggereert is
Amsterdam.pm niet beperkt tot alleen Amsterdam, maar functioneert, tot
er meer gebruikersgroepen in Nederland zijn, als Nederlandse
gebruikersgroep.
Amsterdam.pm organiseert informele bijeenkomsten waar Perl gebruikers
kunnen samenkomen en informatie en gebruikservaringen met betrekking
tot Perl kunnen uitwisselen. Deze bijeenkomsten vinden normaliter
plaats op elke eerste dinsdag van de maand. De voertaal binnen
Amsterdam.pm is in pricipe Nederlands, maar indien nodig zal Engels
worden gebruikt, b.v. om te communiceren met niet-Nederlandssprekende
aanwezigen.
De eerstvolgende bijeenkomst vindt plaats op 6 juli 1999.
De agenda voor deze bijeenkomst is, zoals gewoonlijk, informeel:
18:00-18:30 Verzamelen bij Maximiliaan op de Nieuwmarkt
19:00-20:30 Etentje in een restaurant ergens in de buurt
21:00-..... Voortzetting op een nader te bepalen plaats.
Bezoek onze Web site http://www.Amsterdam.pm.org voor meer details.
Daar zal ook de plaats waar we na 21:00 verzamelen bekend gemaakt worden.
[English version]
Amsterdam.pm stands for the Amsterdam Perl Mongers. We're basically a
Perl user group. Despite its name, it is not local to the Amsterdam
environment, but it welcomes Perl mongers from all over the
Netherlands.
Amsterdam.pm organises informal meetings where Perl users can meet,
and exchange information and experiences with regard to using Perl.
The meetings are normally held every first Tuesday of the month.
Although the preferred language for communication is Dutch, English
will be spoken if necessary.
Our next meeting is July 6th, 1999.
It will have the following informal agenda:
18:00-18:30 Gathering at Maximiliaan's on the Nieuwmarkt
19:00-20:30 Dinner in a restaurant somewhere near the Nieuwmarkt
21:00-..... Continuation at an as jet unspecified location.
See http://www.Amsterdam.pm.org for more details. The website will soon
announce the location where we will gather after 21:00.
--
Jan-Pieter Cornet <johnpc@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
------------------------------
Date: Mon, 05 Jul 1999 09:00:27 +0200
From: "Philip 'Yes, that's my address' Newton" <nospam.newton@gmx.net>
Subject: Re: Bloated code
Message-Id: <3780580B.C4774C7D@gmx.net>
garthwebb@my-deja.com wrote:
>
> > In about one second I chopped it down to:
> > for (@array) {&doStuffWith($_)}
> >
>
> Man, what's with all that typing? In about one second I chopped that
> down to:
>
> for(@a){d($_)}
How about:
d$_ for@a;
Four characters short than your version! Why were you so verbose? :)
Cheers,
Philip
------------------------------
Date: 5 Jul 1999 05:01:23 -0500
From: abigail@delanet.com (Abigail)
Subject: Re: Bloated code
Message-Id: <slrn7o10j0.h6v.abigail@alexandra.delanet.com>
that's my address' Newton (nospam.newton@gmx.net) wrote on MMCXXXIV
September MCMXCIII in <URL:news:3780580B.C4774C7D@gmx.net>:
?? garthwebb@my-deja.com wrote:
?? >
?? > > In about one second I chopped it down to:
?? > > for (@array) {&doStuffWith($_)}
?? > >
?? >
?? > Man, what's with all that typing? In about one second I chopped that
?? > down to:
?? >
?? > for(@a){d($_)}
??
?? How about:
??
?? d$_ for@a;
map{d}@a; # Assuming d takes $_ as a default argument.
One char shorter!
Abigail
--
%0=map{reverse+chop,$_}ABC,ACB,BAC,BCA,CAB,CBA;$_=shift().AC;1while+s/(\d+)((.)
(.))/($0=$1-1)?"$0$3$0{$2}1$2$0$0{$2}$4":"$3 => $4\n"/xeg;print#Towers of Hanoi
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: Mon, 05 Jul 1999 13:36:33 +0200
From: "Philip 'Yes, that's my address' Newton" <nospam.newton@gmx.net>
Subject: Re: Bloated code
Message-Id: <378098C1.DACEA8E5@gmx.net>
Abigail wrote:
>
> that's my address' Newton (nospam.newton@gmx.net) wrote on MMCXXXIV
> September MCMXCIII in <URL:news:3780580B.C4774C7D@gmx.net>:
> ?? garthwebb@my-deja.com wrote:
> ?? >
> ?? > > In about one second I chopped it down to:
> ?? > > for (@array) {&doStuffWith($_)}
> ?? > >
> ?? >
> ?? > Man, what's with all that typing? In about one second I chopped that
> ?? > down to:
> ?? >
> ?? > for(@a){d($_)}
> ??
> ?? How about:
> ??
> ?? d$_ for@a;
>
> map{d}@a; # Assuming d takes $_ as a default argument.
>
> One char shorter!
If I could have assumed that, I'd have written
d for@a;
which is one char shorter than your solution. *And* it wouldn't have
used map in void context :).
Cheers,
Philip
------------------------------
Date: 5 Jul 1999 14:16:47 GMT
From: tgy@chocobo.org (Neko)
Subject: Re: Bloated code
Message-Id: <7lqeof$1uf$0@216.39.141.200>
On Mon, 05 Jul 1999 13:36:33 +0200, "Philip 'Yes, that's my address' Newton"
<nospam.newton@gmx.net> wrote:
>Abigail wrote:
>>
>> that's my address' Newton (nospam.newton@gmx.net) wrote on MMCXXXIV
>> September MCMXCIII in <URL:news:3780580B.C4774C7D@gmx.net>:
>> ?? garthwebb@my-deja.com wrote:
>> ?? >
>> ?? > > In about one second I chopped it down to:
>> ?? > > for (@array) {&doStuffWith($_)}
>> ?? >
>> ?? > Man, what's with all that typing? In about one second I chopped that
>> ?? > down to:
>> ?? >
>> ?? > for(@a){d($_)}
>> ??
>> ?? d$_ for@a;
>>
>> map{d}@a; # Assuming d takes $_ as a default argument.
>
>If I could have assumed that, I'd have written
>
> d for@a;
d @a; # Assuming d will loop over array for us.
d; # Assuming d will also access global @a.
--
Neko | tgy@chocobo.org | I want a moogle stuffy!
------------------------------
Date: Mon, 05 Jul 1999 17:32:45 GMT
From: jfk120@my-deja.com
Subject: Re: Bloated code
Message-Id: <7lqq7t$o97$1@nnrp1.deja.com>
In article <378098C1.DACEA8E5@gmx.net>,
"Philip 'Yes, that's my address' Newton" <nospam.newton@gmx.net>
wrote:
> Abigail wrote:
> >
> > that's my address' Newton (nospam.newton@gmx.net) wrote on MMCXXXIV
> > September MCMXCIII in <URL:news:3780580B.C4774C7D@gmx.net>:
> > ?? garthwebb@my-deja.com wrote:
> > ?? >
> > ?? > > In about one second I chopped it down to:
> > ?? > > for (@array) {&doStuffWith($_)}
> > ?? > >
> > ?? >
> > ?? > Man, what's with all that typing? In about one second I
chopped that
> > ?? > down to:
> > ?? >
> > ?? > for(@a){d($_)}
> > ??
> > ?? How about:
> > ??
> > ?? d$_ for@a;
> >
> > map{d}@a; # Assuming d takes $_ as a default argument.
> >
> > One char shorter!
>
> If I could have assumed that, I'd have written
>
> d for@a;
>
> which is one char shorter than your solution. *And* it wouldn't have
> used map in void context :).
>
> Cheers,
> Philip
>
How about
d;
Yes, it will return an error but it's extremely tight code.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: 6 Jul 1999 16:25:09 GMT
From: mkozlows@guy.ssc.wisc.edu (Mike Kozlowski)
Subject: Re: Bloated code
Message-Id: <7ltal5$o44$1@news.doit.wisc.edu>
In article <7lj62n$fka$2@fcnews.fc.hp.com>, Andrew Allen <ada@fc.hp.com> wrote:
>Just as a matter of style, I use "foreach" when iterating over a list,
>and "for" only when using the for(initializer;condition;increment)
>form.
>
>Do most other people do this also?
I actually base my usage off of the plurality of the variable name, so I'd
use:
foreach (@animal)
but:
for (@animals)
Yes, I'm aware of how profoundly silly this is, but "foreach (@animals)"
sounds ungrammatical...
--
Michael Kozlowski
http://www.cs.wisc.edu/~mlk/
------------------------------
Date: Mon, 05 Jul 1999 13:50:28 -0500
From: Kiran Maheriya <kiran@ikos.com>
Subject: Browsing VHDL hierarch
Message-Id: <3780FE74.F6CA253D@ikos.com>
Can anyone tell me where I can find a perl script which can generate
hierarchy of a VHDL design (split into multiple files) into some sort of
textual output?
I heard that there *IS* such perl script existing somewhere! (I tried
searching on the 'Net, but no results).
Please help me find that!
Thanks in advance.
kiran.
------------------------------
Date: Sun, 4 Jul 1999 10:41:13 +0200
From: "Manfred Schneider" <manfred.schneider@rhein-neckar.de>
Subject: Cetus Links: looking for a Perl page maintainer
Message-Id: <7ln6n9$3g0$1@news-ma.rhein-neckar.de>
Hi,
the Cetus Links ( http://www.cetus-links.org/ ) are a collection of
pointers to various information about Object-Orientation and
Component-Orientation.
The web site contains 15,000+ links and 60+ page. During '98 the site
was visited more than 500,000 times. The collection is developed and
maintained by a team (please see http://www.cetus-links.org/team.html )
of several people from different countries.
To enhance and to improve the site we are currently looking for someone
who would like to take over the page
Perl http://www.cetus-links.org/oo_perl.html
If you are interested to join the Cetus Team and to maintain and
enhance this page for a longer period of time please let me know.
The Cetus Team welcomes your help and support very much.
Cheers, Manfred
+-------+---------------------+------------------------+---------------+
| Cetus | O B J E C T S | Thousands of links | 64 pages |
| Links | C O M P O N E N T S | on Object-Orientation | about OO |
+-------+------+--------------+------------------------+---------------+
| Central site | http://www.cetus-links.org/ | 17 mirrors in |
| Mirror index | http://www.cetus-links.org/sites.html | 14 countries |
+--------------+---------------------------------------+---------------+
| German mirror| http://www.cetus-links.de/ | n e w ! |
+--------------+---------------------------------------+---------------+
------------------------------
Date: Tue, 06 Jul 1999 10:21:42 -0600
From: Kenneth Massey <kpmasse@cs.sandia.gov>
Subject: cgi file access issues
Message-Id: <37822D16.91E4A25A@cs.sandia.gov>
I've been researching the issues involved with maintaining a mailing
list through a cgi perl script run through a html form. Below you will
find the solution I came up with. Being new to perl and almost new to
cgi, I would appreciate any suggestions.
The issues I need to handle are
1) prevent multiple users from accessing the mailing list file at the
same time
2) If the user cancels the request in the middle of the script, don't
let the file be corrupted.
So here's the pseudocode:
open ">a.lck"
flock "a.lck"
open ">list.bak" # updated file will be written here
open "list.txt" # the actual list file
read through list.txt, and write updated file to list.bak
close list.bak
close list.txt
rename list.bak ==> list.txt
flock (unlock) "a.lck"
close "a.lck"
The purpose of list.bak is so that if the script is stopped for some
reason, list.txt will not be changed.
The purpose of a.lck is so that only one user can be accessing list.txt
or list.bak at any given time.
One other question that I have is the access priviledges on list.txt.
I'm running on Windows NT server, so how can I allow the script to
read/write to list.txt without allowing them to access it through a
browser or some other means.
Thanks,
Kenneth
------------------------------
Date: Sat, 03 Jul 1999 17:58:37 GMT
From: arpith@hotmail.com
Subject: Re: CGI Help please...
Message-Id: <7llj0a$aqv$1@nnrp1.deja.com>
In article <7lj76n$7ek3@news.cyber.net.pk>,
"Faisal Nasim" <swiftkid@bigfoot.com> wrote:
> > I'm new to CGI and would like to know if there are any free cgi
hosting
> > servers, so that I can check out how these things work and my custom
cgi
> > scripts.
> >
>
> You are asking for "CGI help" in a Perl newsgroup.... :)
>
> Anyway, try....
Thanks...I found webprovider.com and signed up... I am having problems
with cgi (in pearl), will ask questions.. Is this the right newsgroup ?
Arpith
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Sat, 03 Jul 1999 17:58:39 GMT
From: arpith@hotmail.com
Subject: Re: CGI Help please...
Message-Id: <7llj0c$ar1$1@nnrp1.deja.com>
In article <377ca520.22815547@news.uniplus.ch>,
backwards.saerdna@srm.hc (Andreas Fehr) wrote:
> On Fri, 02 Jul 1999 01:41:25 GMT, arpith@hotmail.com wrote:
>
> >Hi,
> >
> >servers, so that I can check out how these things work and my custom
cgi
> >scripts.
>
> http://www.apache.org
>
> Andreas
>
Thankyou :)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Sat, 03 Jul 1999 15:17:55 -0700
From: David Cassell <cassell@mail.cor.epa.gov>
To: arpith@hotmail.com
Subject: Re: CGI Help please...
Message-Id: <377E8C13.C4F56057@mail.cor.epa.gov>
[courtesy cc mailed to poster.. if the address isn't munged]
arpith@hotmail.com wrote:
> [snip of text with mess-up attributions]
>
> Thanks...I found webprovider.com and signed up... I am having problems
> with cgi (in pearl), will ask questions.. Is this the right newsgroup ?
Ummm, maybe not. Let me put it this way. Consider these cases:
[1] Perl code works on browser 1 but not on browser 2
[2] Need Perl code to do action X in CGI script
[3] Getting dreaded 500 error on webpage
In each of these cases, the answer is that this is almost certainly
the wrong newsgroup to ask in. Case [1] is a browser problem or
an HTML problem. Case [2] is a task for your favorite web search
engine, since this is not a 'free scripts to a good home' group.
Case [3] is usually a server configuration problem, and should be
asked in a group for your ISP or your web server.
If you have Perl code which does not do as it should; AND you have
followed the guidelines indicated in the FAQ and it still doesn't
work; AND you can cut the code down to less than 40 lines to still
reproduce the problem: then it sounds like a job for this newsgroup.
Good luck,
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: 1 Jul 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 1 Jul 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.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 23
************************************
