[30065] in Perl-Users-Digest
Perl-Users Digest, Issue: 1308 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Feb 25 16:09:39 2008
Date: Mon, 25 Feb 2008 13:09:08 -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 Mon, 25 Feb 2008 Volume: 11 Number: 1308
Today's topics:
[ANN] Perl Newsgroup Web Archive <ward@NOequanimitySPAM.nl>
Re: hash <RedGrittyBrick@SpamWeary.foo>
Re: help others or elaine24.mary@gmail.com
modperl: HTML::Template not working inside handler gmail@indigorobot.com
Re: new variable stupidity <syscjm@sumire.gwu.edu>
Re: Processing workload distribution xhoster@gmail.com
Re: Processing workload distribution <smallpond@juno.com>
Re: Processing workload distribution <jimsgibson@gmail.com>
Re: Processing workload distribution <r.ted.byers@rogers.com>
Re: Processing workload distribution <r.ted.byers@rogers.com>
Re: Processing workload distribution <r.ted.byers@rogers.com>
Re: Processing workload distribution <joost@zeekat.nl>
Re: Threading NOT working as expected <willem@stack.nl>
Re: Threading NOT working as expected <r.ted.byers@rogers.com>
Re: Threading NOT working as expected <willem@stack.nl>
Re: Threading NOT working as expected <willem@stack.nl>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 25 Feb 2008 20:24:33 +0100
From: Ward Bekker <ward@NOequanimitySPAM.nl>
Subject: [ANN] Perl Newsgroup Web Archive
Message-Id: <47c315f1$0$21025$dbd4b001@news.wanadoo.nl>
Just live:
Perl Newsgroup Archive : A simple & searchable web-archive for
comp.lang.perl.misc. Find only anwers because we do not show messages
without a reply. ;-)
http://perl.equanimity.nl
Regards,
Ward
------------------------------
Date: Mon, 25 Feb 2008 19:25:59 +0000
From: RedGrittyBrick <RedGrittyBrick@SpamWeary.foo>
Subject: Re: hash
Message-Id: <I8ydnb2bOr_Oi17anZ2dneKdnZydnZ2d@bt.com>
Newsgroups wrote:
>> Pass Dumper() a reference rather than a list of keys and values:
>> print Dumper \%languages;
>
> Yes, it's works in my example, then it doesn't works when I try to send
> the datas to a distant server using soap::lite
>
>
SOAP::Lite has a debug option which I have found to be useful.
You can also output the received XML using "->outputxml(1)";
By using Data::Dumper at both ends you should be able to work out how to
handle the data consistently.
I found that experimenting with SOAP::Data was useful in understanding
SOAP::Lite a little better.
------------------------------
Date: Mon, 25 Feb 2008 12:06:17 -0800 (PST)
From: elaine24.mary@gmail.com
Subject: Re: help others or
Message-Id: <9131f93c-c89d-4286-9ab2-fa116d566cac@j28g2000hsj.googlegroups.com>
On Feb 20, 5:29=A0am, rpriy...@gmail.com wrote:
> help others or
>
> guide others or
>
> love others .
>
> ******************************************************http://cellbiologyst=
ructural.blogspot.com/
> ******************************************************
hi how r u
------------------------------
Date: Mon, 25 Feb 2008 11:33:05 -0800 (PST)
From: gmail@indigorobot.com
Subject: modperl: HTML::Template not working inside handler
Message-Id: <3a49f71b-5fce-4e23-b64f-5f5fb422e364@64g2000hsw.googlegroups.com>
Hello everyone,
I'm working on coding up a mod_perl handler, but am unable to get
HTML::Template to output. Below is my current code:
# file:MyHandler.pm
#------------------------------------------------------------------
package MyHandler;
#Load some helpful functions
use strict; #strict tolerance for code
use warnings; #extra warnings in the log
use Carp; #verbose logging
use diagnostics; #more verbose logging
#Loadup some functions for later use
use HTML::Template;
#Loadup functions involved in being a handler
use Apache2::RequestRec ();
use Apache2::RequestIO ();
use Apache2::Request;
use Apache2::Const -compile => qw(OK);
#------------------------------------------------------------------
#
# Subroutines
#
sub handler {
my $hdlr = shift;
$hdlr->content_type('text/html');
$hdlr->print("Handler started<br />");
my $template = HTML::Template->new( filename => "/templates/
main.tmpl");
$hdlr->print("outputting template...<br />");
$template->output();
$hdlr->print("after main, now sending Apache 'OK'<br />");
return Apache2::Const::OK;
}
1;
all of the $hdlr->print statements are printed in the web browser, but
the contents of "/templates/main.tmpl" are not printed. I don't see
any errors in the Apache logs.
------------------------------
Date: Mon, 25 Feb 2008 19:48:22 -0000
From: Chris Mattern <syscjm@sumire.gwu.edu>
Subject: Re: new variable stupidity
Message-Id: <slrnfs66s4.22i.syscjm@sumire.gwu.edu>
On 2008-02-23, Tad J McClellan <tadmc@seesig.invalid> wrote:
> Time Waster <bfc@fenway.UUCP> wrote:
>> OK, i'm being lazy to ask here. :(
>>
>> I'm always finding myself doing this:
>> $newvar = $oldvar;
>> $newvar = s/something/else/;
>> ..because i want both of them. Is there a way to do this in 1 statement?
>
>
> (my $newvar = $oldvar) =~ s/something/else/;
>
I thought that would change $oldvar as well, but it doesn't. Why not?
--
Christopher Mattern
NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities
------------------------------
Date: 25 Feb 2008 19:30:54 GMT
From: xhoster@gmail.com
Subject: Re: Processing workload distribution
Message-Id: <20080225143056.300$LY@newsreader.com>
Ted <r.ted.byers@rogers.com> wrote:
> On Feb 25, 1:25=A0pm, Joost Diepenmaat <jo...@zeekat.nl> wrote:
> > Ted <r.ted.by...@rogers.com> writes:
> > > Here is my code:
> >
> > > use threads;
> >
> > > my $thr0 =3D threads->create(\&dbspawn,'e5pf16.sql','e5pf16.log');
> > > $thr0->join;
> >
> > you should join() all threads /after/ creating all of them. a join()
> > blocks untill the thread is done. In other words, move the ->join()
> > calls to the end of script.
> >
> > --
> > Joost Diepenmaat | blog:http://joost.zeekat.nl/| work:http://zeekat.nl/
>
> Ah, OK.
>
> While it is not likely in this case, since the scripts normally take
> several hours to run, what happens if you create half a dozen threads,
> and one of them finishes before you get to join it?
Then it waits very very patiently for you to "join" it. No problem.
(Unless you accumulate a large number of them).
> Also, I recall reading somewhere that some system calls block
> everything in the process until the system call returns.
There is the Perl function named "system", then there are calls that perl
makes into the kernel, referred to as system calls. They are different
but confusingly named. Is your concern about the first or the latter?
> Is that
> true?
I suspect that it is true of certain kernel-level system calls, but such
calls should be extremely fast (otherwise, they OS designers should have
reworked them not to block.) There isn't much you can do about it in
a Perl program, or at least not without knowing exactly what the call
is.
> If so, which are involved, and what would be the workaround?
Find a better OS to run your Perl program on? :)
Anyway, don't worry about it until it happens.
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: Mon, 25 Feb 2008 11:32:55 -0800 (PST)
From: smallpond <smallpond@juno.com>
Subject: Re: Processing workload distribution
Message-Id: <56048855-0534-4e8b-92cb-b3817282cd1e@34g2000hsz.googlegroups.com>
On Feb 25, 1:07 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth smallpond <smallp...@juno.com>:
>
>
>
> > See perlthrtut and check your perl build with: perl -V
> > Look for a line like:
>
> > usethreads=define use5005threads=undef useithreads=define
> > usemultiplicity=define
>
> > I believe that the last part indicates whether perl tries to use
> > multiple CPUs.
>
> Please don't make things up and post them without verifying.
> Multiplicity indicates whether it is possible to have several perl
> interpreters in the same process: this is a requirement for ithreads (so
> any perl with useithreads=define will also have usemultiplicity=define)
> but is also used without ithreads for e.g. mod_perl. It has *nothing* to
> do with use of multiple CPUs: this is determined by your OS's thread
> scheduling policy.
>
> Ben
I didn't make it up, I looked at previous postings in this NG where
someone has ithreads=define and not usemultiplicity.
http://groups.google.com/group/comp.lang.perl.misc/browse_frm/thread/8f27b699aff8a37d/18a233467aaa72d8?hl=en&lnk=gst&q=usemultiplicity#18a233467aaa72d8
------------------------------
Date: Mon, 25 Feb 2008 12:22:44 -0800
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: Processing workload distribution
Message-Id: <250220081222447022%jimsgibson@gmail.com>
In article
<43db91c7-7e79-40bd-9dc3-45adc6152db9@i7g2000prf.googlegroups.com>, Ted
<r.ted.byers@rogers.com> wrote:
> On Feb 25, 1:30 pm, xhos...@gmail.com wrote:
> > Ted <r.ted.by...@rogers.com> wrote:
> > > Here is my code:
> >
> > > use threads;
> >
> > > my $thr0 = threads->create(\&dbspawn,'e5pf16.sql','e5pf16.log');
> > > $thr0->join;
> >
> > Join means you wait for $thr0 to finish. Obviously this is going
> > to lead to serialization. The simple answer is to move all the joins
> > from where they are and put them after all of the creates have been done.
> > The *right* answer is probably to put the thread objects into an array,
> > then after that loop over that array doing joins, rather than using a bunch
> > of different variables to hold the objects.
> >
> > Xho
.
>
> Yup that was it.
>
> This script was just a test to make sure I got it all right. I was
> going to worry about putting it into arrays after I got it right.
>
> that means one array for the script name, a second for the log name,
> and a third for the thread objects.
Better to use an "array of arrays", "array of hashes", or "hash of
hashes" to keep the bits of information together (untested):
# array of arrays:
my @aoa = (
[ "script_name1", "log_name1" ],
[ "script_name2", "log_name2" ],
...
);
for my $ref ( @aoa ) {
$ref->[2] = threads->create(\&dbspawn, $ref->[0], $ref->[1]);
}
etc.
--
Jim Gibson
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
Date: Mon, 25 Feb 2008 12:28:42 -0800 (PST)
From: Ted <r.ted.byers@rogers.com>
Subject: Re: Processing workload distribution
Message-Id: <ffc06347-d41f-47a9-a0d2-1d3bf821e234@z17g2000hsg.googlegroups.com>
On Feb 25, 1:51=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
>
> As others have said, join waits for the thread, so you need to do it
> last. Also, this is *not* an efficient way to create many threads. I
> would probably write something like
>
> =A0 =A0 $_->join for map {
> =A0 =A0 =A0 =A0 threads->create(\&dbspawn, "$_.sql", "$_.log");
> =A0 =A0 } qw/e5pf16 gpf45 gpf46 gpf48 gpf49 gpf50/;
>
;-) I like the look of this.
> or probably drop the sub altogether and use async:
>
> =A0 =A0 $_->join for map {
> =A0 =A0 =A0 =A0 async {
> =A0 =A0 =A0 =A0 =A0 =A0 system "mysql -t -u rejbyers <$_.sql >$_.log"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and warn "$script failed";
>
> =A0 =A0 =A0 =A0 =A0 =A0 # there's little point in dieing when the thread's=
about to
> =A0 =A0 =A0 =A0 =A0 =A0 # exit anyway...
> =A0 =A0 =A0 =A0 }
> =A0 =A0 } qw/.../;
>
> but you may find something a little less compressed easier to
> understand:
>
> =A0 =A0 my @jobs =3D qw/e5pf16 gpf45 .../;
>
> =A0 =A0 my @threads =3D map {
> =A0 =A0 =A0 =A0 async {
> =A0 =A0 =A0 =A0 =A0 =A0 system "...";
> =A0 =A0 =A0 =A0 }
> =A0 =A0 } @jobs;
>
> =A0 =A0 $_->join for @threads;
>
> Of course, given that you only use the threads to launch processes, you
> would be better off just launching processes:
>
> =A0 =A0 my @procs =3D map { system 1, "..." } @jobs;
>
> =A0 =A0 waitpid $_ for @procs;
>
Are there performance implications for the various forms you suggest,
apart from the obvious that the last just has the overhead of creating
the needed processes while the others create the same processes within
threads that carry their own overhead. But I doubt that this overhead
could be significant when the scripts that are launched take hours to
complete.
> > Is there a Win64::process, or will Win32::process work on a 64 bit
> > version of windows using the 64 bit build of perl?
>
> I don't know. That is, there isn't a Win64::Process, and I don't know
> whether Win32::Process works on Win64. That depends on whether the
> underlying Win32 system calls still work the same way: I suspect they
> do. There are no Win64 results from CPAN Testers (surprise), which is
> usually the first place to look. In any case, since there aren't any
> Win64 ppms, you'd need to compile libwin32 from source. Do you have an
> appropriate compiler?
>
Well, I have MS Visual Studio 2003, so I suppose I could build it here
(with a 64 bit target) and deploy it at the office. I have yet to get
cygwin to work on a 64 bit machine, so the 64 bit machine does not
have a native compiler installed. But wait a minute. On the 64 bit
machine, 'ppm list' includes libwin32 at the bottom of the list. And,
I see in the documentation Activestate provided with this build that
Win32::process is available, along with a long list of other Win32
modules. Mind you, I don't know if it works since I just found it
mere minutes ago.
Thanks
Ted
------------------------------
Date: Mon, 25 Feb 2008 12:39:03 -0800 (PST)
From: Ted <r.ted.byers@rogers.com>
Subject: Re: Processing workload distribution
Message-Id: <3da9d19a-3026-46f6-b5c8-f7212a60583c@h25g2000hsf.googlegroups.com>
On Feb 25, 2:30=A0pm, xhos...@gmail.com wrote:
> Ted <r.ted.by...@rogers.com> wrote:
> > On Feb 25, 1:25=3DA0pm, Joost Diepenmaat <jo...@zeekat.nl> wrote:
> > > Ted <r.ted.by...@rogers.com> writes:
> > > > Here is my code:
>
> > > > use threads;
>
> > > > my $thr0 =3D3D threads->create(\&dbspawn,'e5pf16.sql','e5pf16.log');=
> > > > $thr0->join;
>
> > > you should join() all threads /after/ creating all of them. a join()
> > > blocks untill the thread is done. In other words, move the ->join()
> > > calls to the end of script.
>
> > > --
> > > Joost Diepenmaat | blog:http://joost.zeekat.nl/|work:http://zeekat.nl/=
>
> > Ah, OK.
>
> > While it is not likely in this case, since the scripts normally take
> > several hours to run, what happens if you create half a dozen threads,
> > and one of them finishes before you get to join it?
>
> Then it waits very very patiently for you to "join" it. =A0No problem.
> (Unless you accumulate a large number of them).
>
At present, we're talking a few dozen at a time. But, I wouldn't mind
having the problem of making it work for thousands, given what that
would imply about our commercial success!
> > Also, I recall reading somewhere that some system calls block
> > everything in the process until the system call returns.
>
> There is the Perl function named "system", then there are calls that perl
> makes into the kernel, referred to as system calls. =A0They are different
> but confusingly named. =A0Is your concern about the first or the latter?
>
I assumed the former was just a special case of the latter. I was
concerned about the former, though, because at present I am merely
launched child processes using it. But the latter would always
create a nagging doubt, for when I need to make more interesting
threads.
> > Is that
> > true?
>
> I suspect that it is true of certain kernel-level system calls, but such
> calls should be extremely fast (otherwise, they OS designers should have
> reworked them not to block.) =A0There isn't much you can do about it in
> a Perl program, or at least not without knowing exactly what the call
> is.
>
> > If so, which are involved, and what would be the workaround?
>
> Find a better OS to run your Perl program on? :)
> Anyway, don't worry about it until it happens.
>
OK. In this case, though, I don't have the option of choosing OS
since our administrator only knows Windows, and I have neither the
time nor the full suite of skills required to administer a unix box.
I develop application level code and analyze data, and even for that
there is insufficient time in the day. Now if Perl could make the
days last 48 hours ....
;-)
Thanks
Ted
------------------------------
Date: Mon, 25 Feb 2008 12:39:54 -0800 (PST)
From: Ted <r.ted.byers@rogers.com>
Subject: Re: Processing workload distribution
Message-Id: <ae2405a9-5940-499c-bcaa-b8c63c66378a@e10g2000prf.googlegroups.com>
On Feb 25, 2:04=A0pm, Joost Diepenmaat <jo...@zeekat.nl> wrote:
> Ted <r.ted.by...@rogers.com> writes:
> > While it is not likely in this case, since the scripts normally take
> > several hours to run, what happens if you create half a dozen threads,
> > and one of them finishes before you get to join it?
>
> if the thread has already finished, the join() should just return
> immediately (after possibly doing some cleanup). Note that you should
> always either join() or detach() each thread.
>
> > Also, I recall reading somewhere that some system calls block
> > everything in the process until the system call returns.
>
> Besides thread-specific calls, like the ones used by threads::shared's
> synchronization methods, I don't know of anything like that. From perl's
> point of view, you should probably regard threads as completely seperate
> processes that have some nifty additional IPC mechanisms.
>
> This also implies that unless you need those sharing mechanisms, you're
> not gaining anything by using threads instead of fork() - and you're
> quite likely to be losing efficiency and gaining some possible issues) -
> at least on OSs that support fork natively. Though I gather that on
> Windows systems, the situation is different.
>
> --
> Joost Diepenmaat | blog:http://joost.zeekat.nl/| work:http://zeekat.nl/
Good to know. Thanks. I didn't consider fork because i was under the
impression that it doesn't work right on Windows.
Thanks
ted
------------------------------
Date: Mon, 25 Feb 2008 22:00:48 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: Processing workload distribution
Message-Id: <87hcfwu4xr.fsf@zeekat.nl>
Ted <r.ted.byers@rogers.com> writes:
> Good to know. Thanks. I didn't consider fork because i was under the
> impression that it doesn't work right on Windows.
With regards to issues, fork() and threads should be more or less
equivalent on (native, non-cygwin) windows perls, since on windows fork
is implemented using threads. I vaguely recall that there may still be
some issues with fork() on windows, but they should be subtle as long as
you're not relying on /exact/ POSIX semantics for fork on windows.
In any case, threads (on any platform) and fork() on windows both have
their more-or-less subtle issues, so if it works for you, just use it,
but if you run into unexplained issues, they're definitely one of places
trouble may be looming.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Mon, 25 Feb 2008 19:11:03 +0000 (UTC)
From: Willem <willem@stack.nl>
Subject: Re: Threading NOT working as expected
Message-Id: <slrnfs64m7.2psb.willem@snail.stack.nl>
Ted wrote:
) When I first tried creating perl threads, the main process ended after
) the threads where created but before any of them really started. On
) reading further, I saw that I had to join the threads so that the main
) process would sit idle waiting for the threads to finish. So I added
) statements to join each thread. But now, it looks like the
) consequence of this is that the code in each thread is executed one
) after the other, as if it was a single process rather than a set of
) independantly executing threads.
How do you know this ? Have you tested this thoroughly ?
Note that if you run multiple threads, that one thread will be running
at a time, and the OS will switch to the next thread every so often.
So if you do a trivial task in one thread, then, yes, it's very likely that
the operating system won't have a chance to switch to other tasks before it
completes, effectively completing one task after another.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Mon, 25 Feb 2008 12:05:09 -0800 (PST)
From: Ted <r.ted.byers@rogers.com>
Subject: Re: Threading NOT working as expected
Message-Id: <c080e569-4803-48d6-92f9-d3cd7b4cace1@i29g2000prf.googlegroups.com>
On Feb 25, 2:11=A0pm, Willem <wil...@stack.nl> wrote:
> Ted wrote:
>
> ) When I first tried creating perl threads, the main process ended after
> ) the threads where created but before any of them really started. =A0On
> ) reading further, I saw that I had to join the threads so that the main
> ) process would sit idle waiting for the threads to finish. =A0So I added
> ) statements to join each thread. =A0But now, it looks like the
> ) consequence of this is that the code in each thread is executed one
> ) after the other, as if it was a single process rather than a set of
> ) independantly executing threads.
>
> How do you know this ? =A0Have you tested this thoroughly ?
>
> Note that if you run multiple threads, that one thread will be running
> at a time, and the OS will switch to the next thread every so often.
>
> So if you do a trivial task in one thread, then, yes, it's very likely tha=
t
> the operating system won't have a chance to switch to other tasks before i=
t
> completes, effectively completing one task after another.
>
> SaSW, Willem
> --
> Disclaimer: I am in no way responsible for any of the statements
> =A0 =A0 =A0 =A0 =A0 =A0 made in the above text. For all I know I might be
> =A0 =A0 =A0 =A0 =A0 =A0 drugged or something..
> =A0 =A0 =A0 =A0 =A0 =A0 No I'm not paranoid. You all think I'm paranoid, d=
on't you !
> #EOT
Wilem,
These scripts that are being launched by the perl script threads
typically take several hours to complete.
Yes, I have done enough multithreaded programming (in C++ and Java) to
know that on a single core single processor machine, only one thread
runs at a time. There is, then, little advantage, for most of my
programming to do multithreaded development. However, my present
development machine has a dual core processor, and the server I'm
working with has a quad core processor. So, on my own machine, two
threads ought to be running concurrently and on the server, that would
be four concurrent threads.
Thanks
Ted
------------------------------
Date: Mon, 25 Feb 2008 20:46:52 +0000 (UTC)
From: Willem <willem@stack.nl>
Subject: Re: Threading NOT working as expected
Message-Id: <slrnfs6a9s.2s0u.willem@snail.stack.nl>
Ted wrote:
) Wilem,
)
) These scripts that are being launched by the perl script threads
) typically take several hours to complete.
)
) Yes, I have done enough multithreaded programming (in C++ and Java) to
) know that on a single core single processor machine, only one thread
) runs at a time. There is, then, little advantage, for most of my
) programming to do multithreaded development. However, my present
) development machine has a dual core processor, and the server I'm
) working with has a quad core processor. So, on my own machine, two
) threads ought to be running concurrently and on the server, that would
) be four concurrent threads.
Oh, I see. Sorry for jumping to conclusions.
I'll read through the reast of the thread to see if I have some
more useful insights.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Mon, 25 Feb 2008 20:49:41 +0000 (UTC)
From: Willem <willem@stack.nl>
Subject: Re: Threading NOT working as expected
Message-Id: <slrnfs6af5.2s0u.willem@snail.stack.nl>
Willem wrote:
) I'll read through the reast of the thread to see if I have some
) more useful insights.
I see you got your answer already in the other thread. ^_^
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
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 1308
***************************************
