[29987] in Perl-Users-Digest
Perl-Users Digest, Issue: 1230 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 24 18:09:44 2008
Date: Thu, 24 Jan 2008 15:09:10 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 24 Jan 2008 Volume: 11 Number: 1230
Today's topics:
Re: File::SortedSeek not working xhoster@gmail.com
Re: Get an arbitrary hash key, quickly. <mark.clementsREMOVETHIS@wanadoo.fr>
Re: Get an arbitrary hash key, quickly. <simon.chao@fmr.com>
Re: Get an arbitrary hash key, quickly. <1usa@llenroc.ude.invalid>
Re: Get an arbitrary hash key, quickly. <simon.chao@fmr.com>
Re: Get an arbitrary hash key, quickly. xhoster@gmail.com
Re: Get an arbitrary hash key, quickly. <simon.chao@fmr.com>
Re: Get an arbitrary hash key, quickly. <1usa@llenroc.ude.invalid>
help with system( ) sansbacon@gmail.com
Re: help with system( ) <kkeller-usenet@wombat.san-francisco.ca.us>
Smart Debugger (Perl) <karthi.ir@gmail.com>
Re: sprintf rounding with FreeBSD and perl 5.8.x cherbst@gmail.com
Re: sprintf rounding with FreeBSD and perl 5.8.x <nospam-abuse@ilyaz.org>
Re: The Way to Paradise is Perl <1usa@llenroc.ude.invalid>
Re: The Way to Paradise <1usa@llenroc.ude.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 24 Jan 2008 21:00:07 GMT
From: xhoster@gmail.com
Subject: Re: File::SortedSeek not working
Message-Id: <20080124160009.884$8V@newsreader.com>
worker <tzhai2007@gmail.com> wrote:
> On Jan 24, 12:36 pm, "J. Gleixner" <glex_no-s...@qwest-spam-
> no.invalid> wrote:
> > worker wrote:
> > > Hi, all,
> > > I am using this File::SortedSeek module to search a big data file
> > > and it is not working.
> >
> > > The data file has these entries:
> >
> > > 01/01/1960,0.75
> > > 01/02/1960,0.00
The example code produced file like this:
01/10/1949,0.1
01/02/1950,0.2
1/1/1960,7.0
1/2/1960,8.0
3/3/1980,9.0
It is not canonical, as the sometimes it is zero-padded and sometimes
it is not. It does appear to be in a reasonable sorted order, but I
don't know if that is by design or by accident (If you designed something
to sort it properly, why doesn't it canonicalize it while it is at it?)
But isn't clear if the semantics are day/month/year or month/day/year,
as both are compatible with the given order. I'm assuming day/month/year
...
> $line = <DTEST>;
> chomp ($line);
> $tell = File::SortedSeek::alphabetic(*TEST,$line,\&munge_string);
The query $line needs to be munged in way compatible with the querent
lines' munging. Otherwise it won't work. The easiest way to do this is to
pass in munge_string($line) rather than $line.
>
> sub munge_string {
> my $line = shift || return undef;
> # return ($line =~ m/\|(\w+)$/) ? $1 : undef;
> # return ($line =~ m/^[0-9]+\/[0-9]+\/[0-9]+,/) ? $1 : undef;
> return ($line =~ m/^\/,/) ? $1 : undef;
> }
The function has to munge the data in such a way that the lines of the
file being searched are in alphabetic sorted order after the munging. With
the sort order your file already has, it thus has to reorder the fields so
that the most significant (year) comes first.
return ($line =~ m/(^[0-9]+)\/([0-9]+)\/([0-9]+)(,|$)/) ?
sprintf "%04d%02d%02d", $3,$2,$1 : undef;
The (,|$) is so that it will work on the query, which is not followed by a
comma, as well as the querent.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Thu, 24 Jan 2008 19:29:48 +0000
From: Mark Clements <mark.clementsREMOVETHIS@wanadoo.fr>
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <4798e742$0$851$ba4acef3@news.orange.fr>
xhoster@gmail.com wrote:
> I need a work queue, but I don't really care about the order (LIFO, FIFO,
> random) in which things come out of it. Either is pretty simple and
> efficient with a Perl array, and either would suffice. But I want the
> queue to not hold duplicate entries. I could use an array as a stack or
> queue, with a parallel hash to be checked to prevent duplicates from being
> entered. But why keep parallel data structures? Just use the hash as the
> queue:
>
> while (key %hash) {
> my $to_do=each %hash;
> delete $hash{$to_do};
> ## do stuff with $to_do, which might make new entries in %hash
> };
>
> Well, except that this gets really slow on large hashes.
>
Have you looked at one of the Heap modules, eg Heap::Simple?
Mark
------------------------------
Date: Thu, 24 Jan 2008 11:33:50 -0800 (PST)
From: nolo contendere <simon.chao@fmr.com>
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <36220d3e-e44c-4b76-9da0-db23ff14ba6c@k39g2000hsf.googlegroups.com>
On Jan 24, 1:59=A0pm, xhos...@gmail.com wrote:
> Uri Guttman <u...@stemsystems.com> wrote:
> > >>>>> "x" =3D=3D xhoster =A0<xhos...@gmail.com> writes:
>
>
>
>
> > =A0 x> while (key %hash) {
> > =A0 x> =A0 my $to_do=3Deach %hash;
>
> > why not do this instead?
>
> > while( my $todo =3D each %hash ) {
>
> > =A0 =A0 =A0 =A0 #do work
> > =A0 =A0 =A0 =A0 delete $hash{$to_do};
> > =A0 =A0 =A0 =A0 keys %hash ; =A0 =A0# reset iterator
>
> Effectively the same thing, just re-worded. =A0Works, but has the
> same slowness issue, presumably for the same reason.
>
So if you remove the keys %hash in the above scenario, would the
condition to 'while' evaluate to true after the iterator reached then
end if keys were added? will the iterator "know" that it needs to loop
around again? it's unclear from the perldoc -f each:
When the hash is entirely read, a null array is
returned in list context (which when assigned
produces a false (0) value), and "undef" in scalar
context. The next call to "each" after that will
start iterating again. There is a single iterator
for each hash, shared by all "each", "keys", and
"values" function calls in the program; it can be
reset by reading all the elements from the hash, or
by evaluating "keys HASH" or "values HASH". If you
add or delete elements of a hash while you're
iterating over it, you may get entries skipped or
duplicated, so don't. Exception: It is always safe
to delete the item most recently returned by
"each()", which means that the following code will
work:
while (($key, $value) =3D each %hash) {
print $key, "\n";
delete $hash{$key}; # This is safe
}
It says undef will be returned if the hash is entirely read. But since
the hash is not empty, is it considered "entirely read"? Also, it says
it's always safe to delete the most recently returned item, but sounds
like it's UNsafe to add elements while iterating.
based on this, Uri's way (which is essentially the same as your
original slow way, if a tad bit cleaner), seems the correct way.
------------------------------
Date: Thu, 24 Jan 2008 19:43:52 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <Xns9A2F95D8A3EA5asu1cornelledu@127.0.0.1>
xhoster@gmail.com wrote in news:20080124122509.078$og@newsreader.com:
> I need a work queue, but I don't really care about the order (LIFO,
> FIFO, random) in which things come out of it. Either is pretty simple
> and efficient with a Perl array, and either would suffice. But I want
> the queue to not hold duplicate entries. I could use an array as a
> stack or queue, with a parallel hash to be checked to prevent
> duplicates from being entered. But why keep parallel data structures?
> Just use the hash as the queue:
>
> while (key %hash) {
> my $to_do=each %hash;
> delete $hash{$to_do};
> ## do stuff with $to_do, which might make new entries in %hash
> };
>
> Well, except that this gets really slow on large hashes.
It is possible I am misunderstanding what you are doing, but I would
have written:
#!/usr/bin/perl
use strict;
use warnings;
my %queue;
$queue{ $_ } = undef for 1 .. 1_000_000;
while ( my @keys = keys %queue ) {
for my $task ( @keys ) {
delete $queue{ $task };
#
# Do something
#
# Add another task with a small probability
#
if ( 0.1 > rand ) {
$queue{ 1 + int(rand 1_000_000) } = undef;
}
}
}
C:\Home\asu1\Src\test\hash_queue> timethis hq
TimeThis : Command Line : hq
TimeThis : Start Time : Thu Jan 24 14:42:36 2008
TimeThis : End Time : Thu Jan 24 14:42:46 2008
TimeThis : Elapsed Time : 00:00:09.312
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines: <URL:http://www.augustmail.com/~tadmc/clpmisc.shtml>
------------------------------
Date: Thu, 24 Jan 2008 12:24:59 -0800 (PST)
From: nolo contendere <simon.chao@fmr.com>
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <36b5756e-5bfd-4d44-8109-978ef73db81d@t1g2000pra.googlegroups.com>
On Jan 24, 2:43=A0pm, "A. Sinan Unur" <1...@llenroc.ude.invalid> wrote:
> xhos...@gmail.com wrote innews:20080124122509.078$og@newsreader.com:
>
> > I need a work queue, but I don't really care about the order (LIFO,
> > FIFO, random) in which things come out of it. =A0Either is pretty simple=
> > and efficient with a Perl array, and either would suffice. =A0But I want=
> > the queue to not hold duplicate entries. =A0I could use an array as a
> > stack or queue, with a parallel hash to be checked to prevent
> > duplicates from being entered. =A0But why keep parallel data structures?=
> > =A0Just use the hash as the queue:
>
> > while (key %hash) {
> > =A0 my $to_do=3Deach %hash;
> > =A0 delete $hash{$to_do};
> > =A0 ## do stuff with $to_do, which might make new entries in %hash
> > };
>
> > Well, except that this gets really slow on large hashes.
>
> It is possible I am misunderstanding what you are doing, but I would
> have written:
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> my %queue;
> $queue{ $_ } =3D undef for 1 .. 1_000_000;
>
> while ( my @keys =3D keys %queue ) {
> =A0 =A0 for my $task ( @keys ) {
> =A0 =A0 =A0 =A0 delete $queue{ $task };
> =A0 =A0 =A0 =A0 #
> =A0 =A0 =A0 =A0 # Do something
> =A0 =A0 =A0 =A0 #
> =A0 =A0 =A0 =A0 # Add another task with a small probability
> =A0 =A0 =A0 =A0 #
> =A0 =A0 =A0 =A0 if ( 0.1 > rand ) {
> =A0 =A0 =A0 =A0 =A0 =A0 $queue{ 1 + int(rand 1_000_000) } =3D undef;
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>
> }
>
> C:\Home\asu1\Src\test\hash_queue> timethis hq
>
> TimeThis : =A0Command Line : =A0hq
> TimeThis : =A0 =A0Start Time : =A0Thu Jan 24 14:42:36 2008
> TimeThis : =A0 =A0 =A0End Time : =A0Thu Jan 24 14:42:46 2008
> TimeThis : =A0Elapsed Time : =A000:00:09.312
>
That was my initial thought as well (well, something like that
anyway), and I think that was Xho's initial thought. But I think he's
trying to devise a solution that doesn't require both %queue and
@keys.
------------------------------
Date: 24 Jan 2008 20:43:33 GMT
From: xhoster@gmail.com
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <20080124154335.948$kk@newsreader.com>
nolo contendere <simon.chao@fmr.com> wrote:
> On Jan 24, 1:59=A0pm, xhos...@gmail.com wrote:
> > Uri Guttman <u...@stemsystems.com> wrote:
> > > >>>>> "x" =3D=3D xhoster =A0<xhos...@gmail.com> writes:
> >
> >
> >
> >
> > > x> while (key %hash) {
> > > x> my $to_do=each %hash;
> >
> > > why not do this instead?
> >
> > > while( my $todo = each %hash ) {
> >
> > > #do work
> > > delete $hash{$to_do};
> > > keys %hash ; # reset iterator
> >
> > Effectively the same thing, just re-worded. Works, but has the
> > same slowness issue, presumably for the same reason.
> >
>
> So if you remove the keys %hash in the above scenario, would the
> condition to 'while' evaluate to true after the iterator reached then
> end if keys were added?
No. Once the iterator reached the end, it will return undef and the loop
will exit. So as far as the loop is concerned, there is no "after"
the iterator reaches the end, because the loop is done.
> will the iterator "know" that it needs to loop
> around again?
Only if you happen to invoke it once more after it already indicated
the it was done. But the loop, without the reset, doesn't invoke it
again.
> it's unclear from the perldoc -f each:
>
> When the hash is entirely read, a null array is
> returned in list context (which when assigned
> produces a false (0) value), and "undef" in scalar
> context. The next call to "each" after that will
> start iterating again. There is a single iterator
> for each hash, shared by all "each", "keys", and
> "values" function calls in the program; it can be
> reset by reading all the elements from the hash, or
> by evaluating "keys HASH" or "values HASH". If you
> add or delete elements of a hash while you're
> iterating over it, you may get entries skipped or
> duplicated, so don't. Exception: It is always safe
> to delete the item most recently returned by
> "each()", which means that the following code will
> work:
>
> while (($key, $value) =3D each %hash) {
> print $key, "\n";
> delete $hash{$key}; # This is safe
> }
>
> It says undef will be returned if the hash is entirely read. But since
> the hash is not empty, is it considered "entirely read"?
Of course. Otherwise, if you did an each without a delete (which
is the most common way to use each), then it would be infinite loop.
> Also, it says
> it's always safe to delete the most recently returned item, but sounds
> like it's UNsafe to add elements while iterating.
If you violate their warning about adding things to the hash while
iterating, then it may be deemed fully read even though some elements have
not been iterated over during this current round of iteration. So if you
violate that warning, then when each returns empty you have to use some
other way to make sure the hash itself is empty.
I'm pretty sure it is safe in the sense that it will not segfault or
anything like that, it is only unsafe towards your assumptions that
everything has been seen.
> based on this, Uri's way (which is essentially the same as your
> original slow way, if a tad bit cleaner), seems the correct way.
I don't see that. Both methods always reset the iterator between the time
additions are made and the time each is called again. (Well, Uri's doesn't
reset the iterator before the very first each, which presumably comes
after some insert which was done before the loop was reached, but surely
that is not a problem.)
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Thu, 24 Jan 2008 12:54:41 -0800 (PST)
From: nolo contendere <simon.chao@fmr.com>
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <ca51b47b-f26b-4bdc-b214-fa0874ac30de@i12g2000prf.googlegroups.com>
On Jan 24, 3:43=A0pm, xhos...@gmail.com wrote:
> nolo contendere <simon.c...@fmr.com> wrote:
> > On Jan 24, 1:59=3DA0pm, xhos...@gmail.com wrote:
> > > Uri Guttman <u...@stemsystems.com> wrote:
> > > > >>>>> "x" =3D3D=3D3D xhoster =3DA0<xhos...@gmail.com> writes:
>
>
> > based on this, Uri's way (which is essentially the same as your
> > original slow way, if a tad bit cleaner), seems the correct way.
>
> I don't see that. =A0Both methods always reset the iterator between the ti=
me
> additions are made and the time each is called again. =A0(Well, Uri's does=
n't
> reset the iterator before the very first each, which presumably comes
> after some insert which was done before the loop was reached, but surely
> that is not a problem.)
True, the flaw in this algorithm is that it always resets the
iterator. Personally, I like Sinan's implementation.
------------------------------
Date: Thu, 24 Jan 2008 21:00:34 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <Xns9A2FA2D9BBDBCasu1cornelledu@127.0.0.1>
nolo contendere <simon.chao@fmr.com> wrote in
news:36b5756e-5bfd-4d44-8109-978ef73db81d@t1g2000pra.googlegroups.com:
> On Jan 24, 2:43 pm, "A. Sinan Unur" <1...@llenroc.ude.invalid> wrote:
>> xhos...@gmail.com wrote innews:20080124122509.078$og@newsreader.com:
>>
>> > I need a work queue, but I don't really care about the order (LIFO,
>> > FIFO, random) in which things come out of it. Either is pretty
>> > simple
>
...
>> > Well, except that this gets really slow on large hashes.
>>
>> It is possible I am misunderstanding what you are doing, but I would
>> have written:
Obviously, I was.
...
> That was my initial thought as well (well, something like that
> anyway), and I think that was Xho's initial thought. But I think he's
> trying to devise a solution that doesn't require both %queue and
> @keys.
Thank you for the clarification.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines: <URL:http://www.augustmail.com/~tadmc/clpmisc.shtml>
------------------------------
Date: Thu, 24 Jan 2008 14:16:36 -0800 (PST)
From: sansbacon@gmail.com
Subject: help with system( )
Message-Id: <55820cad-25f1-4a85-9c70-09660a33130d@c23g2000hsa.googlegroups.com>
i am looking to automate the creation of username/passwords for digest
authentication via a simple perl script. i found a module on cpan for
htpasswd but not htdigest.
the system call is htdigest /usr/local/apache/passwd/digest realm
username
then you are prompted to enter and reenter the password
how do i send the password via a perl script?
thank you for your assistance,
eric
------------------------------
Date: Thu, 24 Jan 2008 14:55:51 -0800
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: help with system( )
Message-Id: <nkhn65xp6m.ln2@goaway.wombat.san-francisco.ca.us>
On 2008-01-24, sansbacon@gmail.com <sansbacon@gmail.com> wrote:
> i am looking to automate the creation of username/passwords for digest
> authentication via a simple perl script. i found a module on cpan for
> htpasswd but not htdigest.
>
> the system call is htdigest /usr/local/apache/passwd/digest realm
> username
>
> then you are prompted to enter and reenter the password
> how do i send the password via a perl script?
Look for the Perl Expect module.
--keith
--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
------------------------------
Date: Thu, 24 Jan 2008 13:01:23 -0800 (PST)
From: kraman <karthi.ir@gmail.com>
Subject: Smart Debugger (Perl)
Message-Id: <71d222d8-a4f4-42d8-9493-5e5d5e7cf4a6@s13g2000prd.googlegroups.com>
Hi All,
Please find the smart debugger for Perl. it is an enchanced version
of perl's default debugger
with lots of smart features.
http://develsdb.googlecode.com/svn/trunk/perl/
http://develsdb.googlecode.com/svn/wiki/SmartDebuggerPerl.wiki
CPAN: http://search.cpan.org/~kraman/Devel-sdb-0.01/sdb.pm
SCREENCAST: http://blip.tv/file/get/Kraman-DevelsdbSmartDebugger804.swf
hope you find this useful.
Regards,
Karthik
------------------------------
Date: Thu, 24 Jan 2008 12:18:20 -0800 (PST)
From: cherbst@gmail.com
Subject: Re: sprintf rounding with FreeBSD and perl 5.8.x
Message-Id: <94b94b78-24c9-4f8f-867d-e6d8f2e58fc2@s19g2000prg.googlegroups.com>
On Jan 24, 12:39 pm, RedGrittyBrick <RedGrittyBr...@SpamWeary.foo>
wrote:
> cher...@gmail.com wrote:
> > I'm getting a weird result with some rounding in a sprintf with perl
> > 5.8.8:
>
> > c = 2.47 / 100; # => 0.0247
>
> Odd comment! What do you mean "0.0247"?
>
> $c = 2.47 / 100;
> does not produce the result 0.0247, since 2.47 and .0247 aren't
> representable in finite binary digits:
Yes, I took a crash course in floating point problems over the last
few days. All I'm really trying to get at is why perl on FreeBSD is
different from everything else (ruby and python on Linux and FreeBSD).
> Not I, but I'd guess there is something interesting to see in
> perl -V
> on your BSD and Linux systems.
They *are* different, I hadn't used -V before:
Linux:
Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT
PERL_MALLOC_WRAP THREADS_HAVE_PIDS
USE_ITHREADS
USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API
FreeBSD:
Compile-time options: MYMALLOC PERL_MALLOC_WRAP USE_64_BIT_INT
USE_LARGE_FILES USE_PERLIO
USE_64_BIT_INT looks interesting, still trying to hunt down where it's
set (not Makefile, not config.sh...)
------------------------------
Date: Thu, 24 Jan 2008 22:10:28 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: sprintf rounding with FreeBSD and perl 5.8.x
Message-Id: <fnb2ck$5s$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
<cherbst@gmail.com>], who wrote in article <94b94b78-24c9-4f8f-867d-e6d8f2e58fc2@s19g2000prg.googlegroups.com>:
> USE_64_BIT_INT looks interesting, still trying to hunt down where it's
> set (not Makefile, not config.sh...)
Assuming IEEE complience (should be taken as given), only NVsize
should matter. See the beginning of the thread on milliseconds for
details.
Hope this helps,
Ilya
------------------------------
Date: Thu, 24 Jan 2008 19:50:48 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: The Way to Paradise is Perl
Message-Id: <Xns9A2F9705A7961asu1cornelledu@127.0.0.1>
smallpond <smallpond@juno.com> wrote in news:3ea165fd-a2f4-40e9-91e0-
9d0feccc418b@z17g2000hsg.googlegroups.com:
> [ reply to spam snipped ]
Don't reply to spam. If you want to do something marginally useful as
response, mark the post as spam in Google Groups.
In the mean time, *PLONK*.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines: <URL:http://www.augustmail.com/~tadmc/clpmisc.shtml>
------------------------------
Date: Thu, 24 Jan 2008 19:51:36 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: The Way to Paradise
Message-Id: <Xns9A2F97288524Easu1cornelledu@127.0.0.1>
magoo <t.x.michaels@gmail.com> wrote in news:321824e9-607d-4429-9d6a-
3f8c1ad6f53f@h11g2000prf.googlegroups.com:
> What the heck is wrong with "looking lustfully at strange women, and
> vice versa"?
This, however, is not the place to discuss the merits of such activity.
Especially with a spammer.
*PLONK*
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines: <URL:http://www.augustmail.com/~tadmc/clpmisc.shtml>
------------------------------
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 V11 Issue 1230
***************************************
