[28200] in Perl-Users-Digest
Perl-Users Digest, Issue: 9564 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 4 21:05:37 2006
Date: Fri, 4 Aug 2006 18:05:04 -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 Fri, 4 Aug 2006 Volume: 10 Number: 9564
Today's topics:
Hash in inherited object fields not properly accessible <shenkin@gmail.com>
Re: How probably not to hand over a variable from one p <glennj@ncf.ca>
Re: Perl hash of hash efficiency. <yekasi@gmail.com>
Re: Perl hash of hash efficiency. <yekasi@gmail.com>
Re: Perl hash of hash efficiency. <David.Squire@no.spam.from.here.au>
Re: Perl hash of hash efficiency. <jgibson@mail.arc.nasa.gov>
Re: Perl hash of hash efficiency. <jgibson@mail.arc.nasa.gov>
Pod::Parser not recognising "interior sequences" <news@lawshouse.org>
Re: Prototyping Subs as func expr, list As In map? <benmorrow@tiscali.co.uk>
Read buffer size for XML::Twig <jwells@prophet.com>
Re: Recursion <koko_loko_0@yahoo.co.uk>
Re: Recursion <uri@stemsystems.com>
Re: Recursion xhoster@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 4 Aug 2006 17:26:26 -0700
From: "PeterSShenkin" <shenkin@gmail.com>
Subject: Hash in inherited object fields not properly accessible (5.8.6, RH 7.3)
Message-Id: <1154737586.651018.76150@i42g2000cwa.googlegroups.com>
Here's a code excerpt that isn't sufficient to duplicate the problem as
a standalone, but does illustrate what the problem is. For the bug to
appear, $self->compute_base() has to be called from a class that
inherits from the one where the subroutine is defined. Then, on the
call to $self->compute_base(), the "while" loop behaves as if the
type_stats hash is empty; that is, the body is not executed. The hash
actually does have elements, so I expected the body to be executed for
each one. (The hash elements both exist and are defined.)
In the course of inserting printouts to determine what was going on, I
discovered that computing ntype_stats as shown below causes the "while"
to behave properly. Presumably, the call to "keys" makes the hash
contents visible.
Following the code excerpt is the output of "perl -V".
Apologies if this is a known bug; if so, please refer me to where it is
documented.
sub compute_base {
# compute() each child and return hash of results:
my $self = shift;
if( not ref $self ) {
confess
"$self" . "::compute_base: '$self' is not an object";
}
my $nsample = $self->{nsample};
my $results;
# the while finds no k,v pairs on the 1st call to compute_base
# without the following line; this seems to be a bug in Perl:
my $ntype_stats = scalar keys %{$self->{type_stats}};
while( my ($k,$v) = each %{$self->{type_stats}} ) {
$results->{$k} = $v->compute($nsample);
}
return $results;
}
Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
Platform:
osname=linux, osvers=2.4.20-28.7, archname=i686-linux-thread-multi
uname='linux rosaleen 2.4.20-28.7 #1 thu dec 18 11:31:59 est 2003
i686 unknown '
config_args='-Dprefix=/utils -Dusethreads
-Accflags=-DPERL_REENTRANT_MAXSIZE=65536'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DPERL_REENTRANT_MAXSIZE=65536 -fno-strict-aliasing -pipe
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm',
optimize='-O2',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DPERL_REENTRANT_MAXSIZE=65536 -fno-strict-aliasing -pipe
-I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='2.96 20000731 (Red Hat Linux 7.3
2.96-113)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.2.5'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Mar 12 2005 15:27:25
@INC:
/utils/lib/perl5/5.8.6/i686-linux-thread-multi
/utils/lib/perl5/5.8.6
/utils/lib/perl5/site_perl/5.8.6/i686-linux-thread-multi
/utils/lib/perl5/site_perl/5.8.6
/utils/lib/perl5/site_perl/5.8.1
/utils/lib/perl5/site_perl
------------------------------
Date: 5 Aug 2006 00:09:09 GMT
From: Glenn Jackman <glennj@ncf.ca>
Subject: Re: How probably not to hand over a variable from one perl script to another
Message-Id: <slrned7od5.6cv.glennj@smeagol.ncf.ca>
At 2006-08-04 03:57PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
> Anyhow, definitely for speed I would go with Storable, but a neutral
> data language is generally better otherwise.
http://www.json.org/
http://search.cpan.org/~makamaka/JSON-1.07/lib/JSON.pm
--
Glenn Jackman
Ulterior Designer
------------------------------
Date: 4 Aug 2006 15:58:11 -0700
From: "tak" <yekasi@gmail.com>
Subject: Re: Perl hash of hash efficiency.
Message-Id: <1154732291.613125.161650@b28g2000cwb.googlegroups.com>
A. Sinan Unur wrote:
> "tak" <yekasi@gmail.com> wrote in news:1154727416.683423.205940
> @i3g2000cwc.googlegroups.com:
>
> > Here is the partial code that reads the data from a txt file.
>
> Please read the posting guidelines for this group, especially the sections
> on quoting and posting code (along with data).
>
> use strict;
> use warnings;
>
> missing.
You are right, i did not read the posting guidelines on posting and
quoting code. Perl is the first time i am posting something on google
groups..
>
> > open(mainfile)
>
> Wot?
>
what what? mainfile is the path to the file.... i thought it makes
sense...
> or die("Could not open master file
> > '$mainfile'.");
> > foreach my $line (<mainfile>) {
>
> Haven't you read any of the responses??? I pointed this out as a distinct
> possibility. You are slurping the entire file, just to process it line by
> line.
I did read all the responses. I do not know what you mean by
"Slurping", sorry, i am not a native english speaker.Slurping is not a
technical term that you can learn in a Perl book, nor any of the tech
books that you can find in barnes and noble.
>
> Given this snippent, I presume the rest of your code is just as silly, and
> it is no shock that you run out of memory.
>
> Please read the posting guidelines. Especially the section about posting
> code.
>
> You have just wasted our time trying to guess what your problem was. I
> won't be seeing you.
>
> Sinan
>
The problem was resolved before you responded. Have you not read any of
the responses that I made to several posted before you? At first i
thought it is a collision issue, then later on, i figure it is a memory
issue.
And if you read my post - i mentioned that I am NOT a perl programmer,
this is the FIRST time i am doing things in perl. In java, there is no
foreach, there is a for, there is a while, and a do loop. But there is
no FOREACH. And by looking at the next useful comments made by the next
poster - he mentioned that i should not be using foreach, use while
instead. You could've say the same thing - but you are not in a
position to say i wasted your time trying to guess what my issue was.
B/c the issue was resolved before you posted, and your distinctive
guess was not in a technical term that i could understand. I posted
the code for you to review, is b/c I see that even the issue was
resolved, there are still posted interested on it, and posting more
replies. And that was the reason why i posted it. And furthermore, that
was the original code that sucks up 1.9gb, I did get more advice on how
to make it smaller
And as for you will not be seeing me - OK. If that makes you feel
better.
------------------------------
Date: 4 Aug 2006 15:58:49 -0700
From: "tak" <yekasi@gmail.com>
Subject: Re: Perl hash of hash efficiency.
Message-Id: <1154732329.856663.283560@i42g2000cwa.googlegroups.com>
i see. thx
John W. Krahn wrote:
> tak wrote:
> >
> > Here is the partial code that reads the data from a txt file.
> >
> > open(mainfile) or die("Could not open master file
> > '$mainfile'.");
> > foreach my $line (<mainfile>) {
> > $i++;
> > chomp($line);
> > my @values = split(/\|/, $line);
> >
> > $Master_Hash{$values[3]} = \@values;
> >
> > if ($i % 10000 == 0) {
> > #print ("loaded $i lines in hash so far - last entry was:
> > $values[3] \n");
> > my $size = keys(%Master_Hash);
> > my $scalarSize = scalar %Master_Hash;
> > print "Loaded $i entries - #ofKeys: $size - ScalarSize:
> > $scalarSize\n";
> > }
> > }
> >
> > And each line is about 420 characters.
> >
> > $ wc -l -L 07*file
> > 238348 449 07302006file
> >
> > After it finishes loading these 240k lines into the hash - the xp task
> > manager reports 1.91 GB of usage.
>
> foreach operates on lists so the contents of $mainfile are first loaded into a
> list in memory before the contents are processed. Use a while loop instead so
> that only one line is loaded into memory at a time. So change:
>
> foreach my $line (<mainfile>) {
>
> To:
>
> while ( my $line = <mainfile> ) {
>
>
>
> John
> --
> use Perl;
> program
> fulfillment
------------------------------
Date: Sat, 05 Aug 2006 00:02:23 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: Perl hash of hash efficiency.
Message-Id: <eb0jlv$fq7$1@gemini.csx.cam.ac.uk>
tak wrote:
[snip]
> You are right, i did not read the posting guidelines on posting and
> quoting code. Perl is the first time i am posting something on google
> groups..
This is not "Google groups". This is a Usenet group. Usenet has been
around since before HTML and the WWW, and long before Google. All Google
is doing here is providing a gateway (for you, I, as are many others
here, am using a real newsreader).
DS
------------------------------
Date: Fri, 04 Aug 2006 16:51:14 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: Perl hash of hash efficiency.
Message-Id: <040820061651145952%jgibson@mail.arc.nasa.gov>
In article <1154732291.613125.161650@b28g2000cwb.googlegroups.com>, tak
<yekasi@gmail.com> wrote:
> A. Sinan Unur wrote:
> > "tak" <yekasi@gmail.com> wrote in news:1154727416.683423.205940
> >
> > > open(mainfile)
> >
> > Wot?
> >
>
> what what? mainfile is the path to the file.... i thought it makes
> sense...
mainfile needs a leading $ to be a variable or surrounding by quotes to
be a file name.
>
> > or die("Could not open master file
> > > '$mainfile'.");
> > > foreach my $line (<mainfile>) {
> >
> > Haven't you read any of the responses??? I pointed this out as a distinct
> > possibility. You are slurping the entire file, just to process it line by
> > line.
>
>
> I did read all the responses. I do not know what you mean by
> "Slurping", sorry, i am not a native english speaker.Slurping is not a
> technical term that you can learn in a Perl book, nor any of the tech
> books that you can find in barnes and noble.
I googled for 'slurp' and found this at #4:
http://www.perl.com/pub/a/2003/11/21/slurp.html
(It was written by some guy named 'Uri' :)
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
Date: Fri, 04 Aug 2006 16:58:13 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: Perl hash of hash efficiency.
Message-Id: <040820061658131069%jgibson@mail.arc.nasa.gov>
In article <040820061651145952%jgibson@mail.arc.nasa.gov>, Jim Gibson
<jgibson@mail.arc.nasa.gov> wrote:
> In article <1154732291.613125.161650@b28g2000cwb.googlegroups.com>, tak
> <yekasi@gmail.com> wrote:
>
> > A. Sinan Unur wrote:
> > > "tak" <yekasi@gmail.com> wrote in news:1154727416.683423.205940
>
> > >
> > > > open(mainfile)
> > >
> > > Wot?
> > >
> >
> > what what? mainfile is the path to the file.... i thought it makes
> > sense...
>
> mainfile needs a leading $ to be a variable or surrounding by quotes to
> be a file name.
I wrote that without thinking too much (it is 5pm Friday afternoon
here, after all). 'open(mainfile)' is actually valid Perl, but it is
very obscure syntax, and you shouldn't use it.
From 'perldoc -f open':
open FILEHANDLE,EXPR
...
If EXPR is omitted, the scalar variable of the same name as the
FILEHANDLE contains the filename. (Note that lexical vari-
ables--those declared with "my"--will not work for this pur-
pose; so if you're using "my", specify EXPR in your call to
open.)
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
Date: Fri, 04 Aug 2006 23:07:06 +0100
From: Henry Law <news@lawshouse.org>
Subject: Pod::Parser not recognising "interior sequences"
Message-Id: <1154729221.11222.0@proxy02.news.clara.net>
Can someone who has worked with Pod::Parser help me work out what I'm
doing wrong? Googling for "interior_sequence" turned up nothing of
interest. OS is Windows XP, running ActiveState Perl. I've installed
the latest version of Pod::Parser using PPM.
I'm writing a simple Pod parsing module. So far all it does is subclass
some of the methods from Pod::Parser, but the "interior_sequence"
subroutine doesn't ever seem to be called. I'm posting (a) the module
(stripped down); (b) a tiny Pod document for testing; (c) the driver
program; and (d) the incorrect output.
Stripped-down module "PodD::HTMLDoc"
===================================
package PodD::HTMLDoc;
use 5.008;
use strict;
use warnings;
use base qw(Pod::Parser);
sub command {
my ($parser, $command, $paragraph, $line_num) = @_;
print "command: \$command=$command, \$line_num=$line_num\n";
}
sub verbatim {
my ($parser, $paragraph, $line_num) = @_;
print "verbatim: \$paragraph=$paragraph, \$line_num=$line_num\n";
}
sub textblock {
my ($parser, $paragraph, $line_num) = @_;
print "textblock: \$paragraph=$paragraph, \$line_num=$line_num\n";
}
sub interior_sequence {
my ($parser, $seq_command, $seq_argument) = @_;
print "interior_sequence: \$seq_command=$seq_command,
\$seq_argument=$seq_argument\n";
}
1;
Tiny Pod document
=================
=pod
Some text I<italic> more text
=cut
The driver program
==================
#! /usr/bin/perl
use strict; use warnings;
use PodD::HTMLDoc;
my $podfile = shift;
die "'$podfile' not found\n" unless (-f $podfile);
my $parser = new PodD::HTMLDoc();
$parser->parse_from_file($podfile);
The output
==========
command: $command=pod, $line_num=2
textblock: $paragraph=Some text I<italic> more text
, $line_num=4
... no conversion of the interior sequence (which is I<italic>).
--
Henry Law <>< Manchester, England
------------------------------
Date: Fri, 4 Aug 2006 09:37:27 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: Prototyping Subs as func expr, list As In map?
Message-Id: <7jdbq3-jdg.ln1@osiris.mauzo.dyndns.org>
Quoth "Veli-Pekka Tätilä" <vtatila@mail.student.oulu.fi>:
> Ben Morrow wrote:
> > Quoth "Veli-Pekka Tätilä" <vtatila@mail.student.oulu.fi>:
> <snipped myself even more>
> >> map { lc } @list;
> >> and
> >> map lc, @list;
> >> Do the same thing.
> >> reduce $a * $b, @list; # Won't compile.
> >> Type of arg 1 to List::Util::reduce must be block or sub {} (not
> >> multiplication (*))
> >> Apparently the built-ins don't parse quite the same way as the
> >> user-functions prototyped with the & character.
> > This is correct. There is no way to get a perl sub to parse the way map
> > does...
> OK, that's what I thought, too. Thanks for confirming.
>
> >> why not interpret the first argument & like map and
> >> grep do it, when it isn't a code ref? From the user functions point of
> >> view it could be indistinguishable from a normal code ref.
> >>
> >> The only downside I can see is not being able to use something totally
> >> different from a code ref as the first argument, of a user sub then.
> > I don't understand this: a &-prototyped sub can only accept a coderef.
> > <snip>
> In the above passage, I speculated a bit unclearly that: if map-like
> user-functions interpreted anything that was not a coderef as though it was
> an EXPR and put it inside a sub-routine, you could not pass such functions
> any other type of first arguments then.
And I said, basically, that this was not a problem as a (&@) prototype
is not allowed to accept any other type of first argument.
> But you would, however, get more
> map-like behavior, I suppose. This is easier explained in perl than my
> second language English skills, <smile>. Suppose that:
>
> myMapLike EXPR, @list;
>
> would be auto-converted to
>
> myMapLike { EXPR } @list; # For convenience.
>
> provided that:
>
> ref(EXPR) ne 'CODE';
Or rather, provided EXPR doesn't start with a { (or \&).
> > suspect that map and grep are heavily special-cased in the lexer and
> > parser, and it would be hard to get user subs to accept EXPR as well.
> Impractical probably but hwy would it be hard? Couldn't you use the same
> processing as for map and grep, when the usage resembles them?
Well, I can't really follow all the logic (in particular, I can't see
where the MAPSTART and GREPSTART opcodes are generated), but there is a
whole lot of stuff in toke.c/perly.y that actually starts lexing things
differently immediately after 'map' or 'grep'. Extending that to include
user-defined sub names may be tricky.
Ben
--
All persons, living or dead, are entirely coincidental.
benmorrow@tiscali.co.uk Kurt Vonnegut
------------------------------
Date: 4 Aug 2006 16:57:08 -0700
From: "Jase Wells" <jwells@prophet.com>
Subject: Read buffer size for XML::Twig
Message-Id: <1154735828.715198.311860@m79g2000cwm.googlegroups.com>
I'm using XML::Twig to process a large XML file, and it's working fine.
That is, except for a particular node whose text is quite long -- the
data between the start/end tags is around 50 MB or so.
It seems to take a looong time to read, so I added a char_handler to
see what was happening. My char_handler subroutine tells me it's
receiving at most 1024 bytes at a time. Is there some option to change
the buffer size XML::Twig (or XML::Parser) uses to read the source
file? I've looked around, but no luck yet.
-j
------------------------------
Date: Fri, 4 Aug 2006 23:03:58 +0100
From: "kokolo" <koko_loko_0@yahoo.co.uk>
Subject: Re: Recursion
Message-Id: <eb0g8g$if$1@news.al.sw.ericsson.se>
> I found an implementation without sub-arrays:
> http://www.thescripts.com/forum/thread49795.html
> changedit so it works and tried it for 99999 elements.
> It did it in13 seconds while my code does it in 14.
> How quick it can get at all?
>
> kokolo
>
I won't spam on this subject any more. I ckecked out a little and realized
that the code from the link above is
just a re-written C-code from
http://linux.wku.edu/~lamonml/algor/sort/quick.html
It doesn't have any Perl flavor and is much harder to read.
Yes, it's faster but only 1 sec for 100000 elements (13 to 14). I like this
one much more for the flavor (push, pop) and readibility:
_____________________________________________________-
print "Enter the number of elements to sort: \n";
chomp($size=<STDIN>);
foreach (1..$size) {push @array,int(rand(1000))}
$start=time();
@array= qs(@array);
#print "The sorted array:\n @array \n";
print "$size elementsQuickSorted in ,",time()-$start," seconds.\n";
sub qs {
my @array=@_;
my $pivot=$#array;
my @left;
my @right;
for ($i=0;$i<$pivot;$i++){
if ($red[$i]<=$red[$pivot]){ unshift @left,$red[$i]}
else { push @right,$red[$i]}
}
if ($#left>0){@left=qs(@left)}
if ($#right>0){@right=qs(@right)}
push @left,($red[$pivot],@right);
return @left;
}
____________________________________________________________________________
___________
I appreciate all advices, those about referencing in particular but I'd
really appreciate if somebody
can help me find how quick Perl can get with quicksort.
C does 100000 elements in less than a second. I'm aware Perl has to be
slower and that there are builtins,etc. but I'm not asking for general
advices.
C-like code does it in 13. I believe this is far from Perl limit.
kokolo
------------------------------
Date: Fri, 04 Aug 2006 19:54:33 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Recursion
Message-Id: <x78xm4rr9i.fsf@mail.sysarch.com>
>>>>> "k" == kokolo <koko_loko_0@yahoo.co.uk> writes:
k> I found an implementation without sub-arrays:
k> http://www.thescripts.com/forum/thread49795.html
k> changedit so it works and tried it for 99999 elements.
k> It did it in13 seconds while my code does it in 14.
k> How quick it can get at all?
gack, that is crappy code no matter what and of course the web page
ruined whatever formating it may have had. i wouldn't be surprised if
you could double the speed by cleaning up the logic. it tests the same
shit over and over when you could skip stuff since you know when the
right and left index are the same.
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: 05 Aug 2006 00:38:56 GMT
From: xhoster@gmail.com
Subject: Re: Recursion
Message-Id: <20060804204725.004$HF@newsreader.com>
xhoster@gmail.com wrote:
>
> That said, your program does seem to be N**2, rather than NlogN, and I
> see no reason that it should be. Even with all the badness built in, it
> should still be NlogN, or maybe N(logN)**2, not N**2. I don't quite get
> it.
OK, I solved the problem. Your sort has a bad worst case performance (on
an array that is already sorted, reverse sorted, all ties, etc.) because it
falls into a N**2 step of just picking off one element per recursion.
Because of the way you generate data, you have only 1000 distinct values
and therefore you have a huge number of ties. Once all those ties come
together into a subarray, sorting that subarray has bad performance. That
happens over and over again.
I took out the "int" from your data generation, and bang, things got much
better.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
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 9564
***************************************
