[24906] in Perl-Users-Digest
Perl-Users Digest, Issue: 7156 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Sep 21 21:08:34 2004
Date: Tue, 21 Sep 2004 18:06:50 -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, 21 Sep 2004 Volume: 10 Number: 7156
Today's topics:
Re: "RFC": re [un]pack() <nospam-abuse@ilyaz.org>
Re: $| (undocumented) magic? (krakle)
@{[times[} <Patrick_member@newsguy.com>
Re: @{[times[} <Patrick_member@newsguy.com>
Re: @{[times[} <noreply@gunnar.cc>
Re: @{[times[} <mritty@gmail.com>
Re: @{[times[} <Patrick_member@newsguy.com>
[ANNOUNCE] MultiProcFactory 0.01 (Aaron Dancygier)
[ANNOUNCE] Apache::Session::Memcached 0.02 <bepi@perl.it>
[OT?] SDBM file HUGE on disk <corff@cis.fu-berlin.de>
Re: [OT?] SDBM file HUGE on disk <noreply@gunnar.cc>
Re: [OT?] SDBM file HUGE on disk <corff@cis.fu-berlin.de>
Re: [OT?] SDBM file HUGE on disk <see@sig.invalid>
Re: [OT?] SDBM file HUGE on disk <corff@cis.fu-berlin.de>
Re: [OT?] SDBM file HUGE on disk <Joe.Smith@inwap.com>
Re: [OT?] SDBM file HUGE on disk <corff@cis.fu-berlin.de>
Re: [OT?] SDBM file HUGE on disk <corff@cis.fu-berlin.de>
A Mod Rewrite Question <kerry@whitehouse.gov>
Re: A Mod Rewrite Question <bernard.el-haginDODGE_THIS@lido-tech.net>
Re: A Mod Rewrite Question <tore@aursand.no>
Re: A Mod Rewrite Question <spam@koivi.com>
ANNOUNCE: CGI::Explorer V 2.05 <ron@savage.net.au>
ANNOUNCE: DBIx::Admin::BackupRestore V 1.03 <ron@savage.net.au>
ANNOUNCE: File::Slurp 9999.06 <uri@stemsystems.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 21 Sep 2004 20:23:52 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: "RFC": re [un]pack()
Message-Id: <ciq2ko$gla$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Michele Dondi
<bik.mido@tiscalinet.it>], who wrote in article <gb71k0ls58i0rjjjjuk0otgq0cg8t7fti1@4ax.com>:
> To be fair I had the idea I'm about to expose while developing a new
> japh of mine (the one about which I'm talking in my other post),
> though I think that this may be useful in "production" code too...
>
> Coming to the point, it often happens to resort to "cascaded"
> [un]pack()s. In my specific case I have
>
> $coded=pack 'u', pack 'w', $something;
>
> and respectively
>
> $something=unpack 'w', unpack 'u', $coded;
>
> but even longer combinations are possible/common. Now I understand
> that this stresses the natural order in which transformations are
> applied, though I wonder if templates could be cascaded instead, by
> means of a new metacharachter, e.g. C<:>, a la
>
> $coded=pack 'u:w', $something; # Or perhaps 'w:u'
My opinion on this construct is very contrary to what other posters
suggest. Actually, this construct is a part of my pack()-megapatch of
a couple of years ago.
[Just to remind the history: this megapatch should have consisted of
7 parts, I actually debugged and submitted to p5p only 5 parts of
it; I eventually stopped since only the first two parts were
included anyway.]
This construct is absolutely analogues to the '/' operator of
(un)pack(), the only difference is that one of unpacked values is used
as a target of daughter unpack(), not as a count for the daughter
unpack(). (Similarly for pack().) So in my patch it would be sitting
on // operator:
unpack "... v/a* // (v*) ..."
will unpack the substructure "length in bytes, followed by an array of
integers of this length". Note the similarity with
unpack "... v / v* ..."
used when the count is in number of integers, not bytes.
The reasons why (IMO) the approach of doing this programmatically is
viable for very simple examples only:
a) it breaks the symmetry between pack()/unpack(): when done
programmatically, one must (obviously) use different code for
pack()ing and unpack()ing; in addition to increased probability
of having bugs, these two pieces of code can easily go out of
sync.
b) This construct is *very* widespread; it is easy to do
programmatically for very simple examples only; with more
complicated packed sturctures it may take quite some effort to
find *which* entries one needs to apply the second (un)pack().
c) (un)pack() is one of the few pieces of functional-programming
sublanguage of Perl (RExes are another one). Moving more
processing inside (un)pack() replaces CODE by DATA.
[Now, when my patches added the ability of comments and
structure inside (un)pack() templates], such a move means a
major simplification of code. For complicated tasks, this may
mean significant reduction of design/debugging time.
Hope this helps,
Ilya
------------------------------
Date: 18 Sep 2004 21:29:22 -0700
From: krakle@visto.com (krakle)
Subject: Re: $| (undocumented) magic?
Message-Id: <237aaff8.0409182029.b099879@posting.google.com>
Jeff 'japhy' Pinyan <pinyaj@rpi.edu> wrote in message news:<Pine.SGI.3.96.1040917201725.66659A-100000@vcmr-64.server.rpi.edu>...
> On 17 Sep 2004, krakle wrote:
>
> >Michele Dondi <bik.mido@tiscalinet.it> wrote in message news:<60olk0d79evnjqgkb8rcegha97bvfv09iv@4ax.com>...
> >> On 16 Sep 2004 21:48:53 -0700, krakle@visto.com (krakle) wrote:
> >>
> >> >> It seems you don't waste your time with JAPHs, because you only spend
> >> >> your efforts in "productive code"
> >> >
> >> >My point: Programs can be written in 4 lines of code. The rest of your
> >> >post was ignored.
> >>
> >> Thank you so much for having informed us all that
> >> "programs can be written in 4 lines of code". I can't imagine where we
> >> could be without your contribution!
> >
> >Michele, Not sure why you are taking offense to any of my replies.. It
> >was in response to T. Ogawas "we can't write _any_ valid program in
> >four lines". Ofcourse you can... So hostile in here...
>
> I think Ogawas meant "any" as "every", that is: "we can't write _every_
> valid program".
Alrighty then.
------------------------------
Date: 20 Sep 2004 11:29:15 -0700
From: Patrick Flaherty <Patrick_member@newsguy.com>
Subject: @{[times[}
Message-Id: <cin7hr01n5a@drn.newsguy.com>
Hi,
Started using @{[times]} recently for measuring run (execution) time. (I'm
aware that there's also a Benchmark module).
To figure out what was going on here, I first looked up times in perlvar - not
there. Then thought to try perlfunc. Ah.
So what's the magic, in particular in {[...]}, that converts the return array
into an array-on-the-fly?
I understand that @ refers to arrays and [] also. But what still has me a
little mystified is how, evaluating from in-to-out, when you go from [ to { and
then @, you start at a function and its return value (an array [or list?]) and
end up where you do.
Looked this up in the Nutshell _Perl Programming_ but didn't find an answer.
thanx.
pat
------------------------------
Date: 20 Sep 2004 11:31:34 -0700
From: Patrick Flaherty <Patrick_member@newsguy.com>
Subject: Re: @{[times[}
Message-Id: <cin7m601nkk@drn.newsguy.com>
make that @{[times]}
(got the second square bracket backwards).
In article <cin7hr01n5a@drn.newsguy.com>, Patrick Flaherty says...
>
>Hi,
>
>Started using @{[times]} recently for measuring run (execution) time. (I'm
>aware that there's also a Benchmark module).
>
>To figure out what was going on here, I first looked up times in perlvar - not
>there. Then thought to try perlfunc. Ah.
>
>So what's the magic, in particular in {[...]}, that converts the return array
>into an array-on-the-fly?
>
>I understand that @ refers to arrays and [] also. But what still has me a
>little mystified is how, evaluating from in-to-out, when you go from [ to { and
>then @, you start at a function and its return value (an array [or list?]) and
>end up where you do.
>
> Looked this up in the Nutshell _Perl Programming_ but didn't find an answer.
>
> thanx.
>
> pat
>
------------------------------
Date: Mon, 20 Sep 2004 21:06:29 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: @{[times[}
Message-Id: <2r8o0fF175tlcU1@uni-berlin.de>
Patrick Flaherty wrote:
> Started using @{[times]} recently for measuring run (execution)
> time. (I'm aware that there's also a Benchmark module).
>
> To figure out what was going on here, I first looked up times in
> perlvar - not there. Then thought to try perlfunc. Ah.
>
> So what's the magic, in particular in {[...]}, that converts the
> return array into an array-on-the-fly?
>
> I understand that @ refers to arrays and [] also. But what still
> has me a little mystified is how, evaluating from in-to-out, when
> you go from [ to { and then @, you start at a function and its
> return value (an array [or list?]) and end up where you do.
perldoc -q "expand function"
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 20 Sep 2004 20:17:26 GMT
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: @{[times[}
Message-Id: <qVG3d.3093$kn2.1699@trndny07>
"Gunnar Hjalmarsson" <noreply@gunnar.cc> wrote in message
news:2r8o0fF175tlcU1@uni-berlin.de...
> Patrick Flaherty wrote:
> > Started using @{[times]} recently for measuring run (execution)
> > time. (I'm aware that there's also a Benchmark module).
> >
> > To figure out what was going on here, I first looked up times in
> > perlvar - not there. Then thought to try perlfunc. Ah.
> >
> > So what's the magic, in particular in {[...]}, that converts the
> > return array into an array-on-the-fly?
> >
> > I understand that @ refers to arrays and [] also. But what still
> > has me a little mystified is how, evaluating from in-to-out, when
> > you go from [ to { and then @, you start at a function and its
> > return value (an array [or list?]) and end up where you do.
>
> perldoc -q "expand function"
Unfortunately the FAQ doesn't actually answer the question of *how* this
works, just that it does.
Work backwards. Start with the function call. The function will return
a value or list of values, depending in part on context. The [ ] is a
construct to create an anonymous array reference. It therefore imposes
a list context. So the function will return a list of values. (That
list can, of course, contain only one or even zero items). That list of
items is used to populate the anonymous array created by (and referenced
by) the [ ]. So you have an anonymous array reference. Finally, @{ }
is the syntax used to take whatever is enclosed by { } and dereference
that as an array. If, for example, $ref is an array reference, @{$ref}
is the array referenced by $ref.. So @{ [ ... ] } is the array
referenced by [ ... ].
This is primarily used as a work-around to interpolate function calls.
Ordinarily, function calls do not interpolate inside doublequoted
strings. That is, you cannot do this:
sub fctn {
return 5;
}
print "Function returns: fctn()\n"; #WRONG - ERROR
Instead, you must do:
print "Function returns: ", fctn(), "\n"; #list context for fctn
or
print "Function returns: " . fctn() . "\n"; #scalar context.
Using this work-around, however, perl will analyize the @{[...]}
construct before it starts looking at the string. By the time it's
done, it sees the construct as an ordinary array - which does indeed
interpolate. You are then allowed to do:
print "Function returns: @{[fctn()]}\n";
Note the caveat that this will always force fctn() to be called in a
list context. Note more importantly that most people would agree this
syntax is far uglier than the standard conventions of either separating
the strings as above, or of assigning the return value of the function
to a variable and then interpolating that variable.
Hope this helps,
Paul Lalli
------------------------------
Date: 20 Sep 2004 13:47:55 -0700
From: Patrick Flaherty <Patrick_member@newsguy.com>
Subject: Re: @{[times[}
Message-Id: <cinflr02ks6@drn.newsguy.com>
That was an excellent explanation.
Thanx Paul.
pat
In article <qVG3d.3093$kn2.1699@trndny07>, Paul Lalli says...
>
>"Gunnar Hjalmarsson" <noreply@gunnar.cc> wrote in message
>news:2r8o0fF175tlcU1@uni-berlin.de...
>> Patrick Flaherty wrote:
>> > Started using @{[times]} recently for measuring run (execution)
>> > time. (I'm aware that there's also a Benchmark module).
>> >
>> > To figure out what was going on here, I first looked up times in
>> > perlvar - not there. Then thought to try perlfunc. Ah.
>> >
>> > So what's the magic, in particular in {[...]}, that converts the
>> > return array into an array-on-the-fly?
>> >
>> > I understand that @ refers to arrays and [] also. But what still
>> > has me a little mystified is how, evaluating from in-to-out, when
>> > you go from [ to { and then @, you start at a function and its
>> > return value (an array [or list?]) and end up where you do.
>>
>> perldoc -q "expand function"
>
>Unfortunately the FAQ doesn't actually answer the question of *how* this
>works, just that it does.
>
>Work backwards. Start with the function call. The function will return
>a value or list of values, depending in part on context. The [ ] is a
>construct to create an anonymous array reference. It therefore imposes
>a list context. So the function will return a list of values. (That
>list can, of course, contain only one or even zero items). That list of
>items is used to populate the anonymous array created by (and referenced
>by) the [ ]. So you have an anonymous array reference. Finally, @{ }
>is the syntax used to take whatever is enclosed by { } and dereference
>that as an array. If, for example, $ref is an array reference, @{$ref}
>is the array referenced by $ref.. So @{ [ ... ] } is the array
>referenced by [ ... ].
>
>This is primarily used as a work-around to interpolate function calls.
>Ordinarily, function calls do not interpolate inside doublequoted
>strings. That is, you cannot do this:
>
>sub fctn {
> return 5;
>}
>print "Function returns: fctn()\n"; #WRONG - ERROR
>
>Instead, you must do:
>print "Function returns: ", fctn(), "\n"; #list context for fctn
>or
>print "Function returns: " . fctn() . "\n"; #scalar context.
>
>Using this work-around, however, perl will analyize the @{[...]}
>construct before it starts looking at the string. By the time it's
>done, it sees the construct as an ordinary array - which does indeed
>interpolate. You are then allowed to do:
>
>print "Function returns: @{[fctn()]}\n";
>
>Note the caveat that this will always force fctn() to be called in a
>list context. Note more importantly that most people would agree this
>syntax is far uglier than the standard conventions of either separating
>the strings as above, or of assigning the return value of the function
>to a variable and then interpolating that variable.
>
>Hope this helps,
>Paul Lalli
>
>
>
------------------------------
Date: Mon, 20 Sep 2004 05:29:03 GMT
From: adancygier@bigfootinteractive.com (Aaron Dancygier)
Subject: [ANNOUNCE] MultiProcFactory 0.01
Message-Id: <I4DzDq.26x@zorch.sf-bay.org>
Hi, I've written a series of modules that I'd like to share with
all of you. It's usefull for multiprocess applications that
define a pattern in whatever system you may be programming in. For
instance say you have 20 scripts that connect to multiple db schemas
and or physical db's to do db maintenance or query some tables. You
can bundle up the core logic very nicely into an implentation class.
Where the only thing that differentiates the actual scripts is the
subroutine reference required for each child process. The key is
finding the pattern and implementing it as a subclass. It has some
nice features like shared memory (a hash and a scalar). Parent
process can process these shared variables when children return
status. This is a very useful tool for system maintenance scripts and
distributed reporting applications. So give it a look if you are
interested. Most importantly if after looking at the code and docs,
you have any suggestions send me and email.
Thanks,
Aaron
------------------------------
Date: Fri, 17 Sep 2004 10:00:41 GMT
From: Enrico Sorcinelli <bepi@perl.it>
Subject: [ANNOUNCE] Apache::Session::Memcached 0.02
Message-Id: <I49DuE.KL4@zorch.sf-bay.org>
Hi all,
I'm glad to announce Apache::Session::Memcached.
This module provide a way to use memcached, a memory cache daemon, for
Apache::Session storage implementation (more informations about memcached are
available at http://www.danga.com/memcached)
See:
perldoc Apache::Session::Memcached
perldoc Apache::Session::Memcached::Store
for module documentation and use.
Any comment and/or criticism are welcome :-)
by
- Enrico
------------------------------
Date: 19 Sep 2004 12:56:48 GMT
From: <corff@cis.fu-berlin.de>
Subject: [OT?] SDBM file HUGE on disk
Message-Id: <2r5e0gF16a212U2@uni-berlin.de>
Hi all,
I tied a hash containing ca. 19000 key/value-pairs via SDBM to an
external file. Most of the values are strings less than 20 characters
long, only occasionally there are strings longer than 40...50 characters,
and rolled out as a flat file the 19000-odd lines occupy ca. 650kB.
Reading these data into a hash and tying that to an external file
creates a db file on disk wich is around 16MB large.
Is there any chance to create a smaller file?
Even though this question may be a little off topic I'd appreciate
any hint, thank you,
Oliver.
--
Dr. Oliver Corff e-mail: corff@zedat.fu-berlin.de
------------------------------
Date: Sun, 19 Sep 2004 15:46:42 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: [OT?] SDBM file HUGE on disk
Message-Id: <2r5gt1F16mno1U1@uni-berlin.de>
corff@cis.fu-berlin.de wrote:
> I tied a hash containing ca. 19000 key/value-pairs via SDBM to an
> external file. Most of the values are strings less than 20
> characters long, only occasionally there are strings longer than
> 40...50 characters, and rolled out as a flat file the 19000-odd
> lines occupy ca. 650kB. Reading these data into a hash and tying
> that to an external file creates a db file on disk wich is around
> 16MB large.
>
> Is there any chance to create a smaller file?
Try another type of DBM file, e.g. DB_File.
The AnyDBM_File POD includes a comparison table:
http://search.cpan.org/perldoc?AnyDBM_File
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 19 Sep 2004 19:18:13 GMT
From: <corff@cis.fu-berlin.de>
Subject: Re: [OT?] SDBM file HUGE on disk
Message-Id: <2r64blF15moe8U1@uni-berlin.de>
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
: The AnyDBM_File POD includes a comparison table:
: http://search.cpan.org/perldoc?AnyDBM_File
Hi Gunnar,
I consulted that table (which I had seen earlier), it says:
odbm ndbm sdbm gdbm bsd-db
---- ---- ---- ---- ------
Database Size ? ? small big? ok[1]
I must confess that I cannot really accept 16MB for 19000 strings
filling 500kB as flat file, as "small". The keys are all six ASCII
characters "long".
I am also afraid that NDBM requires additional software which is
not readily available on my remote outdated Win98 target machine
which, worst of all, has no net access (at least it has ASPerl
in a fairly recent version (5.8.0) installed. So I'll have to live
with SDBM's voracious appetite for disk space.
Oliver.
--
Dr. Oliver Corff e-mail: corff@zedat.fu-berlin.de
------------------------------
Date: Sun, 19 Sep 2004 18:22:35 -0400
From: Bob Walton <see@sig.invalid>
Subject: Re: [OT?] SDBM file HUGE on disk
Message-Id: <414E06AB.7080606@sig.invalid>
corff@cis.fu-berlin.de wrote:
> Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
>
> : The AnyDBM_File POD includes a comparison table:
> : http://search.cpan.org/perldoc?AnyDBM_File
>
> Hi Gunnar,
>
> I consulted that table (which I had seen earlier), it says:
>
> odbm ndbm sdbm gdbm bsd-db
> ---- ---- ---- ---- ------
> Database Size ? ? small big? ok[1]
>
> I must confess that I cannot really accept 16MB for 19000 strings
> filling 500kB as flat file, as "small". The keys are all six ASCII
> characters "long".
I agree, in that in my experience SDMB has ballooned a flat file by
factors of perhaps 3 to 7 or so, not the factor of 32 you are reporting.
But SDBM is pretty rudimentary, and who knows what a near worst-case set
of keys could produce. You didn't do anything like copy the SDBM file
in from another OS or an older version of Perl (or another DBM-type
[shudder]), did you? There is no guarantee of portability with any
DBM-type file, even between machines with the same OS and Perl version
(the admin who set up the system could have configured different
parameters for two different systems). If the contents are to be
transferred, convert them to ASCII and recreate (but I have found that
the simple way of using Data::Dumper isn't good for large tied hashes,
for reasons I don't understand -- just a simple program that writes the
keys and values out with appropriate encoding/decoding against control
characters works fine). I have had great success with both SDBM and
DB_File, and have never had a glitch in either in all the apps I've used
them in. One other possibility: Are you using a DBM-type tied hash in
a CGI application without proper locking? Proper locking is essential.
>
> I am also afraid that NDBM requires additional software which is
> not readily available on my remote outdated Win98 target machine
> which, worst of all, has no net access (at least it has ASPerl
> in a fairly recent version (5.8.0) installed. So I'll have to live
> with SDBM's voracious appetite for disk space.
I don't think you'll find any of the Unix-specific DBM's ported to
Windows. Gunnar was suggesting DB_File, which is standard (that means
"comes with") ActiveState Perl in all recent versions. In fact, I think
maybe it is the default for dbmopen/dbmclose these days, instead of
SDBM. Try that as he suggested. See:
perldoc DB_File
for details. DB_File isn't referenced in the table in the FAQ. HTH.
> Oliver.
--
Bob Walton
Email: http://bwalton.com/cgi-bin/emailbob.pl
------------------------------
Date: 20 Sep 2004 05:50:54 GMT
From: <corff@cis.fu-berlin.de>
Subject: Re: [OT?] SDBM file HUGE on disk
Message-Id: <2r79duF16up0tU1@uni-berlin.de>
Bob Walton <see@sig.invalid> wrote:
: corff@cis.fu-berlin.de wrote:
: > Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
: >
: > : The AnyDBM_File POD includes a comparison table:
: > : http://search.cpan.org/perldoc?AnyDBM_File
: >
: > Hi Gunnar,
: >
: > I consulted that table (which I had seen earlier), it says:
: >
: > odbm ndbm sdbm gdbm bsd-db
: > ---- ---- ---- ---- ------
: > Database Size ? ? small big? ok[1]
: >
: > I must confess that I cannot really accept 16MB for 19000 strings
: > filling 500kB as flat file, as "small". The keys are all six ASCII
: > characters "long".
: I agree, in that in my experience SDMB has ballooned a flat file by
: factors of perhaps 3 to 7 or so, not the factor of 32 you are reporting.
: But SDBM is pretty rudimentary, and who knows what a near worst-case set
: of keys could produce.
Well, it looks as if the answer is hidden here. The keys I use are
strictly consecutive in order, running from "0001.1" to "4973.4" with
the digit after the dot being in a range of [1..4]. Perhaps some scrambling
on my side will produce seemingly "random" (but still unique) keys which
will make a smaller SDBM file? Sounds worth trying.
: You didn't do anything like copy the SDBM file
: in from another OS or an older version of Perl (or another DBM-type
: [shudder]), did you?
No no. I use AS Perl 5.8.0 and a
tie (%mongol, 'SDBM_File', 'mongdb', O_RDWR|O_CREAT, 0666)
or die "Couldn't tie SDBM file 'mongdb': $!; aborting.\n";
statement, and then initially fill the hash %mongol at the first run
with data from a keyed list with approx. 19000 entries.
: There is no guarantee of portability with any
: DBM-type file, even between machines with the same OS and Perl version
: (the admin who set up the system could have configured different
: parameters for two different systems). If the contents are to be
Data porting is not an issue, the plain, flat ASCII list is my transport
format of choice in this particular case.
: One other possibility: Are you using a DBM-type tied hash in
: a CGI application without proper locking? Proper locking is essential.
No, just a plain single-user GUI.
: I don't think you'll find any of the Unix-specific DBM's ported to
: Windows. Gunnar was suggesting DB_File, which is standard (that means
: "comes with") ActiveState Perl in all recent versions. In fact, I think
: maybe it is the default for dbmopen/dbmclose these days, instead of
: SDBM. Try that as he suggested. See:
: perldoc DB_File
Won't work on a AS Perl 5.8.0 WinXP installation!
Thank you a lot for the comments and discussion,
Oliver.
--
Dr. Oliver Corff e-mail: corff@zedat.fu-berlin.de
------------------------------
Date: Mon, 20 Sep 2004 08:03:22 GMT
From: Joe Smith <Joe.Smith@inwap.com>
Subject: Re: [OT?] SDBM file HUGE on disk
Message-Id: <e9w3d.222680$Fg5.1242@attbi_s53>
corff@cis.fu-berlin.de wrote:
> : perldoc DB_File
>
> Won't work on a AS Perl 5.8.0 WinXP installation!
Why not? What part does not work on WinXP?
Start -> All Programs -> ActiveState ActivePerl 5.8 -> Perl Package Manager
ppm> install DB_File
====================
Install 'DB_File' version 1.810 in ActivePerl 5.8.0.806.
====================
Downloaded 288942 bytes.
Extracting 10/10: blib/arch/auto/DB_File/DB_File.lib
Installing C:\Perl\site\lib\auto\DB_File\DB_File.bs
Installing C:\Perl\site\lib\auto\DB_File\DB_File.dll
Installing C:\Perl\site\lib\auto\DB_File\DB_File.exp
Installing C:\Perl\site\lib\auto\DB_File\DB_File.lib
Installing C:\Perl\html\site\lib\DB_File.html
Files found in blib\arch: installing files in blib\lib into architecture
dependent library tree
Installing C:\Perl\site\lib\DB_File.pm
Installing C:\Perl\site\lib\auto\DB_File\autosplit.ix
Successfully installed DB_File version 1.810 in ActivePerl 5.8.0.806.
ppm>
-Joe
------------------------------
Date: 20 Sep 2004 11:08:06 GMT
From: <corff@cis.fu-berlin.de>
Subject: Re: [OT?] SDBM file HUGE on disk
Message-Id: <2r7s0mF16fk16U1@uni-berlin.de>
Joe Smith <Joe.Smith@inwap.com> wrote:
: corff@cis.fu-berlin.de wrote:
: > : perldoc DB_File
: >
: > Won't work on a AS Perl 5.8.0 WinXP installation!
: Why not? What part does not work on WinXP?
: Start -> All Programs -> ActiveState ActivePerl 5.8 -> Perl Package Manager
: ppm> install DB_File
: ====================
: Install 'DB_File' version 1.810 in ActivePerl 5.8.0.806.
: ====================
: Downloaded 288942 bytes.
Hi Joe,
Thank you for this demonstration which leaves me silent and flushing.
I simply did not find DB_File in my installation (a minute ago), and
since I never ever really develop things on Windows XP (only for my
team mates who just use XP; for myself, I stick with Linux), I didn't
even think of using DB_File because I thought it is just an interface
into a Berkeley db library. Well, I'll tell later which version
(Tie::File vs. DB_File) brings the better performance.
Thank you,
Oliver.
--
Dr. Oliver Corff e-mail: corff@zedat.fu-berlin.de
------------------------------
Date: 21 Sep 2004 15:42:53 GMT
From: <corff@cis.fu-berlin.de>
Subject: Re: [OT?] SDBM file HUGE on disk
Message-Id: <2rb0ftF182kagU1@uni-berlin.de>
corff@cis.fu-berlin.de wrote:
: Hi Joe,
: Thank you for this demonstration which leaves me silent and flushing.
Yet, I forgot to mention, the target machine has no connection to the
net, and data to be "carried" there (literally) must fit on a floppy.
In the meantime I made Tie::File work with my data set, it's a bit slow,
but it works.
More details later,
Oliver.
--
Dr. Oliver Corff e-mail: corff@zedat.fu-berlin.de
------------------------------
Date: Mon, 20 Sep 2004 09:36:14 GMT
From: "WH" <kerry@whitehouse.gov>
Subject: A Mod Rewrite Question
Message-Id: <iwx3d.22427$RTE1.19424@news01.bloor.is.net.cable.rogers.com>
RewriteEngine On
RewriteOptions MaxRedirects=10
RewriteBase /dir
RewriteRule ^(?<!check.pl.)(.*)$ check.cgi?$2 [L]
I am trying to match anything not starting with check.cgi.
But it is not working.
------------------------------
Date: Mon, 20 Sep 2004 12:00:22 +0200
From: "Bernard El-Hagin" <bernard.el-haginDODGE_THIS@lido-tech.net>
Subject: Re: A Mod Rewrite Question
Message-Id: <Xns956A7A21FC5D4elhber1lidotechnet@62.89.127.66>
"WH" <kerry@whitehouse.gov> wrote:
> RewriteEngine On
>
> RewriteOptions MaxRedirects=10
>
> RewriteBase /dir
>
> RewriteRule ^(?<!check.pl.)(.*)$ check.cgi?$2 [L]
I don't know what all of that crap is, but...
> I am trying to match anything not starting with check.cgi.
...this can be done like so:
if ( $input !~ m/^check\.cgi/ ) {
# $input doesn't start with 'check.cgi'
}
--
Cheers,
Bernard
------------------------------
Date: Mon, 20 Sep 2004 14:07:11 +0200
From: Tore Aursand <tore@aursand.no>
Subject: Re: A Mod Rewrite Question
Message-Id: <pan.2004.09.20.12.07.10.159200@aursand.no>
On Mon, 20 Sep 2004 09:36:14 +0000, WH wrote:
> RewriteEngine On
> RewriteOptions MaxRedirects=10
> RewriteBase /dir
> RewriteRule ^(?<!check.pl.)(.*)$ check.cgi?$2 [L]
>
> I am trying to match anything not starting with check.cgi.
>
> But it is not working.
And your _Perl_ question is?
--
Tore Aursand <tore@aursand.no>
"Why shouldn't truth be stranger than fiction? Fiction, after all, has
to make sense." (Mark Twain)
------------------------------
Date: Mon, 20 Sep 2004 13:43:12 GMT
From: Justin Koivisto <spam@koivi.com>
Subject: Re: A Mod Rewrite Question
Message-Id: <Q7B3d.97$AU4.4217@news7.onvoy.net>
WH wrote:
> RewriteEngine On
>
> RewriteOptions MaxRedirects=10
>
> RewriteBase /dir
>
> RewriteRule ^(?<!check.pl.)(.*)$ check.cgi?$2 [L]
>
> I am trying to match anything not starting with check.cgi.
>
> But it is not working.
Don't know that you can use look-aheads or look-behinds for mod_rewrite.
Below might work though...
RewriteCond %{REQUEST_URI} !^check\.pl
RewriteRule ^(.*)$ check.cgi?$1 [L]
<Sorry c.l.perl.misc... it's a bit OT for you.>
--
Justin Koivisto - spam@koivi.com
http://www.koivi.com
------------------------------
Date: Tue, 14 Sep 2004 04:09:20 GMT
From: Ron Savage <ron@savage.net.au>
Subject: ANNOUNCE: CGI::Explorer V 2.05
Message-Id: <I49Dt9.1G4w@zorch.sf-bay.org>
The pure Perl module CGI::Explorer V 2.05
is available immediately from CPAN,
and from http://savage.net.au/Perl-modules.html.
On-line docs, and a *.ppd for ActivePerl are also
available from the latter site.
An extract from the docs:
2.05 Fri Sep 3 09:18:00 2004
- Fix bug whereby the root node did not have the 'target' attribute set,
so clicking on the root node could produce output in the wrong pane
--
Cheers
Ron Savage, ron@savage.net.au on 14/09/2004
http://savage.net.au/index.html
------------------------------
Date: Tue, 14 Sep 2004 04:10:43 GMT
From: Ron Savage <ron@savage.net.au>
Subject: ANNOUNCE: DBIx::Admin::BackupRestore V 1.03
Message-Id: <I49DtL.KJo@zorch.sf-bay.org>
The pure Perl module DBIx::Admin::BackupRestore V 1.03
is available immediately from CPAN,
and from http://savage.net.au/Perl-modules.html.
On-line docs, and a *.ppd for ActivePerl are also
available from the latter site.
An extract from the docs:
1.03 Tue Sep 14 13:39:00 2004
- A new option has been added to the constructor: fiddle_timestamp.
The default value of the option is 1, so the module behaves as it did before.
If you call new(fiddle_timestamp => 0), we skip the documented process of fiddling
values of type timestamp during a call to restore(), so that the data being restored
is inserted as-is. This option was requested by Daniel Santamaria.
1.02 Thu Aug 26 12:57:00 2004
- A new parameter has been added to the constructor: skip_tables.
If new is called as new(skip_tables => ['some_table_name']), the restore phase
does not restore the tables named in the call to new().
This option is designed to work with CGI scripts using the module CGI::Sessions.
Now, the CGI script can run with the current CGI::Session data, and stale
CGI::Session data is not restored from the XML file.
This parameter is optional. It defaults to [].
--
Cheers
Ron Savage, ron@savage.net.au on 14/09/2004
http://savage.net.au/index.html
------------------------------
Date: Tue, 21 Sep 2004 05:28:52 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: ANNOUNCE: File::Slurp 9999.06
Message-Id: <I4DzEo.27M@zorch.sf-bay.org>
File::Slurp 9999.06 adds two minor features. First it now handles
paragraph mode (when you set $/ to '') and t/paragraph.t is its test.
Second it now handles the DATA handle correctly with no sysseek
workaround needed. t/data_list.t and t/data_scalar.t are its tests.
It has been tested on Solaris 9 (5.6.1), OSX (5.8), Linux (RH9) (5.8),
BSD, and winblows (winxp and 5.8.1).
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: 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 7156
***************************************
