[28047] in Perl-Users-Digest
Perl-Users Digest, Issue: 9411 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jun 30 18:06:04 2006
Date: Fri, 30 Jun 2006 15:05:08 -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, 30 Jun 2006 Volume: 10 Number: 9411
Today's topics:
Re: A question of speed xhoster@gmail.com
Re: A question of speed <sigzero@gmail.com>
Re: A question of speed <john@castleamber.com>
Re: A question of speed <flavell@physics.gla.ac.uk>
Re: A question of speed <sherm@Sherm-Pendleys-Computer.local>
Re: A question of speed <john@castleamber.com>
Re: accessing object variables from callback function <nobull67@gmail.com>
Re: crash on async in taint mode <ynleder@nspark.org>
Re: Problem with Multi- threaded Server xhoster@gmail.com
Re: Professional IDE for a cross-platform Perl applicat <catdogbeloved@yahoo.com>
Re: Professional IDE for a cross-platform Perl applicat <catdogbeloved@yahoo.com>
Re: Professional IDE for a cross-platform Perl applicat <catdogbeloved@yahoo.com>
Re: Professional IDE for a cross-platform Perl applicat <noreply@invalid.net>
Re: Professional IDE for a cross-platform Perl applicat <tadmc@augustmail.com>
Re: Professional IDE for a cross-platform Perl applicat <john@castleamber.com>
Re: Professional IDE for a cross-platform Perl applicat <john@castleamber.com>
Rookie Perl Question <swangdb@auburn.edu>
Re: Rookie Perl Question <ermeyers@adelphia.net>
Re: Rookie Perl Question <swangdb@auburn.edu>
Re: Rookie Perl Question <tadmc@augustmail.com>
Re: Rookie Perl Question <tadmc@augustmail.com>
RSS preprocessors <spartacus@mailinator.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 30 Jun 2006 16:05:10 GMT
From: xhoster@gmail.com
Subject: Re: A question of speed
Message-Id: <20060630120546.896$gH@newsreader.com>
"Robert Hicks" <sigzero@gmail.com> wrote:
> I have some co-workers that are writing an email parser (not sure of
> the specifics) that is going to process around 5000 emails a day. I
> suggested that they go a pure Perl route but they are leary about Perl
> being "fast" enough to parse that many emails.
Unless the words "process" and "parse" are concealing something which is
utterly obscene, this is absolutely no problem.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 30 Jun 2006 09:09:01 -0700
From: "Robert Hicks" <sigzero@gmail.com>
Subject: Re: A question of speed
Message-Id: <1151683741.442882.310430@d56g2000cwd.googlegroups.com>
xhos...@gmail.com wrote:
> "Robert Hicks" <sigzero@gmail.com> wrote:
> > I have some co-workers that are writing an email parser (not sure of
> > the specifics) that is going to process around 5000 emails a day. I
> > suggested that they go a pure Perl route but they are leary about Perl
> > being "fast" enough to parse that many emails.
>
> Unless the words "process" and "parse" are concealing something which is
> utterly obscene, this is absolutely no problem.
>
: )
Not that I know of...
:Robert
------------------------------
Date: 30 Jun 2006 17:02:47 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: A question of speed
Message-Id: <Xns97F27A892C432castleamber@130.133.1.4>
"Robert Hicks" <sigzero@gmail.com> wrote:
> I have some co-workers that are writing an email parser (not sure of
> the specifics) that is going to process around 5000 emails a day. I
> suggested that they go a pure Perl route but they are leary about Perl
> being "fast" enough to parse that many emails.
>
> I have no definitive experience with something on this scale but I am
> sure someone on the Perl group does.
SpamAssassin is written in Pure Perl AFAIK, and 5,000 emails sound like
peanuts to me.
--
John Bokma Freelance software developer
&
Experienced Perl programmer: http://castleamber.com/
------------------------------
Date: Fri, 30 Jun 2006 18:32:34 +0100
From: "Alan J. Flavell" <flavell@physics.gla.ac.uk>
Subject: Re: A question of speed
Message-Id: <Pine.LNX.4.64.0606301825050.26549@ppepc87.ph.gla.ac.uk>
On Fri, 30 Jun 2006, John Bokma wrote:
> "Robert Hicks" <sigzero@gmail.com> wrote:
>
> > I have some co-workers that are writing an email parser (not sure
> > of the specifics) that is going to process around 5000 emails a
> > day. I suggested that they go a pure Perl route but they are leary
> > about Perl being "fast" enough to parse that many emails.
>
> SpamAssassin is written in Pure Perl AFAIK, and 5,000 emails sound
> like peanuts to me.
Sounds right to me. On our departmental mail server, it's the
highest-cost of the processes which run on incoming mail, and we try
to reject as much rubbish as we can at an earlier stage so as not to
put unnecessary load on the system; but a few thousand mails per day
would hardly bring it into a sweat.
However, it might be worth keeping in mind that SA typically runs as a
continuously running daemon, to which the individual mails are fed.
My hunch is that the simple-minded approach of firing-up a separate
instance of the script each time that a mail arrives would incur
considerable overhead.
h t h
------------------------------
Date: Fri, 30 Jun 2006 15:24:35 -0400
From: Sherm Pendley <sherm@Sherm-Pendleys-Computer.local>
Subject: Re: A question of speed
Message-Id: <m2y7vela4s.fsf@Sherm-Pendleys-Computer.local>
"Robert Hicks" <sigzero@gmail.com> writes:
> I have some co-workers that are writing an email parser (not sure of
> the specifics) that is going to process around 5000 emails a day. I
> suggested that they go a pure Perl route but they are leary about Perl
> being "fast" enough to parse that many emails.
>
> I have no definitive experience with something on this scale but I am
> sure someone on the Perl group does.
Smarter folks than me have said it better:
"You can always write faster code in C, but you can always write code
faster in Perl".
"The first rule of optimization is, don't do it. The second rule of
optimization is, don't do it *yet*."
"Premature optimization is the root of all evil."
I forget the origins of those quotes, but they're words to live by. With that
in mind, I would take a "first pass" at the app using pure Perl. If perform-
ance is acceptable at that point, you're done.
Otherwise, profile the app to find the bottlenecks, and try to find better
algorithms to use in those areas before resorting to C - a slow algorithm
written in Perl will be slow in C too.
Finally, if your app is still not performing adequately after all this is
done, I'd look at using XS or Inline to replace any critical sections of
the app with C versions.
Startup speed could be an issue with Perl here. If your app is run 5000 times
a day and handles a single email each time, then that's 5000 times that perl
has to compile the code. You'd be better off with a single long-lived Perl app
that calls its parsing function 5000 times.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: 30 Jun 2006 21:21:48 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: A question of speed
Message-Id: <Xns97F2A6738DB26castleamber@130.133.1.4>
"Alan J. Flavell" <flavell@physics.gla.ac.uk> wrote:
> On Fri, 30 Jun 2006, John Bokma wrote:
>
>> "Robert Hicks" <sigzero@gmail.com> wrote:
>>
>> > I have some co-workers that are writing an email parser (not sure
>> > of the specifics) that is going to process around 5000 emails a
>> > day. I suggested that they go a pure Perl route but they are leary
>> > about Perl being "fast" enough to parse that many emails.
>>
>> SpamAssassin is written in Pure Perl AFAIK, and 5,000 emails sound
>> like peanuts to me.
>
> Sounds right to me. On our departmental mail server, it's the
> highest-cost of the processes which run on incoming mail, and we try
> to reject as much rubbish as we can at an earlier stage so as not to
> put unnecessary load on the system; but a few thousand mails per day
> would hardly bring it into a sweat.
>
> However, it might be worth keeping in mind that SA typically runs as a
> continuously running daemon, to which the individual mails are fed.
>
> My hunch is that the simple-minded approach of firing-up a separate
> instance of the script each time that a mail arrives would incur
> considerable overhead.
For quite some time I just did that, I downloaded with a small POP script
each message, fed it to SA, and if it was spam, it was deleted off the
server. The script was ran after login, and it was able to handle 500+
emails within a reasonable timeframe even though I ran it in a very clumsy
way :-)
--
John Bokma Freelance software developer
&
Experienced Perl programmer: http://castleamber.com/
------------------------------
Date: 30 Jun 2006 11:42:29 -0700
From: "Brian McCauley" <nobull67@gmail.com>
Subject: Re: accessing object variables from callback function
Message-Id: <1151692949.112950.304170@i40g2000cwc.googlegroups.com>
Dr.Ruud wrote:
> kaisung@gmail.com schreef:
>
> > my $test = MyTest->new();
>
> Variant:
>
> my $test = new MyTest ;
Yes, TIMTOWTDI, but most (not all) Perl experts prefer the ->
> print "numTags = $test->{numTags}\n" ;
>
> (which bypasses the method)
(which is bad)
------------------------------
Date: Fri, 30 Jun 2006 20:17:54 +0200
From: Yohan N. Leder <ynleder@nspark.org>
Subject: Re: crash on async in taint mode
Message-Id: <MPG.1f0f893e7ba2e18c9898b0@news.tiscali.fr>
In article <ffbcn3-geo.ln1@osiris.mauzo.dyndns.org>,
benmorrow@tiscali.co.uk says...
> http://perlmonks.org/index.pl?node_id=547313
>
> Ben
>
OK, posted : "fork() and async{} with "use threads", both crash on
ActivePerl 5.8.8 build 817 with Apache2 under Windows 2000 Pro FR SP4"
on the page you gave. Unless going through Win32::Process, do you know a
work-around ?
------------------------------
Date: 30 Jun 2006 18:19:20 GMT
From: xhoster@gmail.com
Subject: Re: Problem with Multi- threaded Server
Message-Id: <20060630141957.020$AR@newsreader.com>
xhoster@gmail.com wrote:
> "janicehwang1325@yahoo.com" <janicehwang1325@yahoo.com> wrote:
> > Ya, I miss that part and I amend my program by putting the close with
> > SSL_no_shutdown. However, this only help when the client program ends
> > the connection and the server program would not hang. It does not
> > actually solve the segmentation fault problem.
>
> The SSLeay module seems to be fundamentally unsafe for threads. I tried
> a few things to hack it with CLONED, etc. but haven't been able to. The
> mere existence of a thread is enough to trigger the problem, the thread
> doesn't need to do anything with the socket at all. By changing the
> "close" parameters, I could make it segfault either ealier (upon the
> initial close) or later (half way through the 2nd accept) but couldn't
> get rid of it altogether.
Just an addition, the SSLeay module is not fundamentally unsafe for
threads, it is just the way that IO::Socket::SSL interacts with it that is
unsafe.
If I disable IO::Socket::SSL::DESTROY, the seg faults stop but it leaks
like a sieve. If I re-enable that but disable
IO::Socket::SSL::SSL_Context::DESTROY, then it still solves the seg-fault
and still leaks, but a lot less. So you would need to find a way to make
sure that that DESTROY only happens in one of the threads, either the
parent or the child, and not in both. Something like DBI's
InactiveDestroy.
Or just fork instead of threads. Ask your boss "How much are you willing
to spend to accomplish your stupid and arbitrary requirements?"
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 30 Jun 2006 11:33:29 -0700
From: "Bob" <catdogbeloved@yahoo.com>
Subject: Re: Professional IDE for a cross-platform Perl application
Message-Id: <1151692409.487573.55810@m73g2000cwd.googlegroups.com>
Re: John Bokma
> Ah, yeah, the magical IDE. I think it's called outsourcing :-D
No, it is called IDE.
> >> Porting from/to Linux/Windows works perfectly without changing any
> >> Tk-related code. There is c.l.p.tk for perl-tk questions.
> >
> > Sorry, I am no longer interested in tk.
>
> Nor in programming, so it seems.
Excuse me? No, I am not interested in programming GUI. There are so
many
GUIs around, and keep improving. Should I recode the application each
time I change the interface? I have been doing it for 15 years, I know
what
I am talking about, and I want to step away from it. I want to separate
the actual routines from the GUI, and let an IDE deal with the GUI and
the
port to various platforms.
> I doubt if you will find an "IDE" that takes your Perl/TK application and
> magically transforms it into a fast running cross platform product you
> just have to plug some C into.
I share the doubt. Indeed I have to make the cut by hand, rebuild the
GUI
into the IDE, and then glue the routines to the new GUI.
> Probably best thing to do is reverse engineer it, and redesign it in a
> language that matches todays requirements, and maybe for a few years to
> come.
I start entertaining the belief that I have to rewrite the whole
application again.
Yes, perl compiles, but it failes with my application; it is too
complex. I think
I'll have to write the core SQL-related routines into C, and call them
from
within perl, to ensure that I am not breaking anything. When all these
routines
are converted, I can detach the GUI, make the new one, and attach the
new
routines to it. However, this is wishful thinking, as I have no clue of
how the
IDE would interface with my routines. The nasty bit are the global
variables...
> BTW, Perl *does* compile. But if you want it to compile to hide secrets,
> you are mistaken. If you want to compile it to bundle it, have a look at
> PAR. If you want to "compile" to speed things up: a close look at the code
> might improve it.
PAR? I've never heard of it. I'll look into it.
Thanks,
Bob
------------------------------
Date: 30 Jun 2006 11:39:03 -0700
From: "Bob" <catdogbeloved@yahoo.com>
Subject: Re: Professional IDE for a cross-platform Perl application
Message-Id: <1151692743.505718.299270@75g2000cwc.googlegroups.com>
Re: Tad McClellan
> > The first version was written in a DOS-based database. The
> > unix-based perl/tk version is the latest of ports. The former
> > was perl/cgi running under a web browser.
>
> A Perl CGI program *never* runs under a browser.
>
> CGI programs run on web *servers*.
I can assure you that my perl/cgi application was running on a web
browser.
Bloody slowly, and with serious limitations, but it was running. I
managed
to gain in speed and functionality with Tk. I hope I will gain further
speed
and functionality with a better GUI.
> > The application uses linux-specific features,
>
> Then an IDE will not help in porting it.
An IDE will not do the porting for me, that's for sure. But it will
help me
in spotting all the OS dependent parts, so that I can change them.
Bob
------------------------------
Date: 30 Jun 2006 11:46:32 -0700
From: "Bob" <catdogbeloved@yahoo.com>
Subject: Re: Professional IDE for a cross-platform Perl application
Message-Id: <1151693192.413313.37790@b68g2000cwa.googlegroups.com>
For you to understand what I mean, have a look at the following:
http://www.activestate.com/Perl.plex?hdr=1
What I am in search for, is your wisdom about similar products.
I would like to have pointers to other similar products, together
with your comments on whether they cut the mustard, so to speak.
Bob
------------------------------
Date: Fri, 30 Jun 2006 19:06:57 GMT
From: Ala Qumsieh <noreply@invalid.net>
Subject: Re: Professional IDE for a cross-platform Perl application
Message-Id: <lDepg.57907$fb2.51956@newssvr27.news.prodigy.net>
Bob wrote:
> I start entertaining the belief that I have to rewrite the whole
> application again.
I was about to suggest that. A 15-year old application is just too old to
port around to different platforms given the leaps and bounds that happened
in computing since then. You have a major new requirement now: portability.
With that in mind, start from a clean slate.
--Ala
------------------------------
Date: Fri, 30 Jun 2006 15:24:02 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Professional IDE for a cross-platform Perl application
Message-Id: <slrneab232.4br.tadmc@magna.augustmail.com>
Bob <catdogbeloved@yahoo.com> wrote:
> Re: Tad McClellan
>
>> > The first version was written in a DOS-based database. The
>> > unix-based perl/tk version is the latest of ports. The former
>> > was perl/cgi running under a web browser.
>>
>> A Perl CGI program *never* runs under a browser.
>>
>> CGI programs run on web *servers*.
>
> I can assure you that my perl/cgi application was running on a web
> browser.
No it wasn't.
CGI is *specified* to run on web servers. If it runs on a web
browser, then it is not conforming to the CGI.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 30 Jun 2006 21:31:05 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: Professional IDE for a cross-platform Perl application
Message-Id: <Xns97F2A8065F2AFcastleamber@130.133.1.4>
"Bob" <catdogbeloved@yahoo.com> wrote:
> I start entertaining the belief that I have to rewrite the whole
> application again.
> Yes, perl compiles, but it failes with my application; it is too
> complex.
That's odd.
> I think
> I'll have to write the core SQL-related routines into C,
Why on earth? If you don't handle the data that comes out of SQL queries
efficiently, it might be that you want to move more of the handling into
SQL itself (stored procedures). I have seen too often people doing the
weirdest things in language X which should have been done in SQL.
> routines to it. However, this is wishful thinking, as I have no clue
> of how the
> IDE would interface with my routines.
That's where the programming bit jumps in :-)
> The nasty bit are the global
> variables...
Like I said: write a new functional specification, and drop this piece of
junk, since that is how it sounds.
> PAR? I've never heard of it. I'll look into it.
It packs all modules + script + interpreter into one file. I use it now
and then on Windows, I get one exe (quite large, even a small script is 2+
MB) without the need of installing Perl.
--
John Bokma Freelance software developer
&
Experienced Perl programmer: http://castleamber.com/
------------------------------
Date: 30 Jun 2006 21:34:13 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: Professional IDE for a cross-platform Perl application
Message-Id: <Xns97F2A88E421C6castleamber@130.133.1.4>
"Bob" <catdogbeloved@yahoo.com> wrote:
> For you to understand what I mean, have a look at the following:
>
> http://www.activestate.com/Perl.plex?hdr=1
>
> What I am in search for, is your wisdom about similar products.
> I would like to have pointers to other similar products, together
> with your comments on whether they cut the mustard, so to speak.
An IDE is just a fancy knife. You have to provide the mustard, and do the
cutting :-)
--
John Bokma Freelance software developer
&
Experienced Perl programmer: http://castleamber.com/
------------------------------
Date: 30 Jun 2006 11:21:38 -0700
From: "swangdb" <swangdb@auburn.edu>
Subject: Rookie Perl Question
Message-Id: <1151691698.694383.36120@d30g2000cwa.googlegroups.com>
I want to run some unix commands from a perl script.
This works, it prints out all lines that don't begin with a # in the
file $ALIASES:
***
$temp = "egrep -v \^# $ALIASES";
system($temp);
***
This doesn't work, it tries to take the egrep output and cut out part
of it:
***
$temp = "egrep -v \^# $ALIASES | cut -d: -f1";
system($temp);
***
I get the following output:
Usage: egrep [OPTION]... PATTERN [FILE]...
Try `egrep --help' for more information.
How can I make this work?
Thanks!
------------------------------
Date: Fri, 30 Jun 2006 14:35:45 -0400
From: "Eric R. Meyers" <ermeyers@adelphia.net>
Subject: Re: Rookie Perl Question
Message-Id: <EvGdneTtoOGc8jjZnZ2dnUVZ_rmdnZ2d@adelphia.com>
swangdb wrote:
> I want to run some unix commands from a perl script.
>
> This works, it prints out all lines that don't begin with a # in the
> file $ALIASES:
>
> ***
> $temp = "egrep -v \^# $ALIASES";
> system($temp);
> ***
>
> This doesn't work, it tries to take the egrep output and cut out part
> of it:
>
> ***
> $temp = "egrep -v \^# $ALIASES | cut -d: -f1";
> system($temp);
> ***
>
> I get the following output:
>
> Usage: egrep [OPTION]... PATTERN [FILE]...
> Try `egrep --help' for more information.
>
> How can I make this work?
>
> Thanks!
$aliases = 'some/file/name';
open( FH, $aliases ) || die "opening aliases: $!\n";
while ( <FH> )
{
print if ( ! m/^[#]/ );
} ## end while
close( FH );
## FYI: Buy Perl programming book "Learning Perl" ISBN: 1-56592-284-0.
## The system() call doesn't return output to you.
## Another means is open( FH, "egrep -v ... |" ) which opens a piped FH.
------------------------------
Date: 30 Jun 2006 13:27:12 -0700
From: "swangdb" <swangdb@auburn.edu>
Subject: Re: Rookie Perl Question
Message-Id: <1151699232.475889.153880@h44g2000cwa.googlegroups.com>
Eric R. Meyers wrote:
> swangdb wrote:
> > This doesn't work, it tries to take the egrep output and cut out part
> > of it:
> >
> > ***
> > $temp = "egrep -v \^# $ALIASES | cut -d: -f1";
> > system($temp);
> > ***
> $aliases = 'some/file/name';
>
> open( FH, $aliases ) || die "opening aliases: $!\n";
>
> while ( <FH> )
> {
> print if ( ! m/^[#]/ );
>
> } ## end while
>
> close( FH );
Eric,
Thanks for showing a real perl way to do this. I received a quick fix
to my command, add one backslash before the existing backslash:
$temp = "egrep -v \\^# $ALIASES | cut -d: -f1";
system($temp);
I actually want to put this output to a file, so I guess system is
okay:
$temp = "egrep -v \\^# $ALIASES | cut -d: -f1 > $outfile";
system($temp);
Thanks again!
------------------------------
Date: Fri, 30 Jun 2006 15:30:12 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Rookie Perl Question
Message-Id: <slrneab2ek.4br.tadmc@magna.augustmail.com>
swangdb <swangdb@auburn.edu> wrote:
> I want to run some unix commands from a perl script.
> $temp = "egrep -v \^# $ALIASES";
> system($temp);
Have you read the documentation for the function that you are using?
> This doesn't work, it tries to take the egrep output
> system($temp);
Have you read the documentation for the function that you are using?
> How can I make this work?
The way it says to in the documentation for the function that you are using.
perldoc -f system
This is *not* what you want to use to capture the output from a
command, for that you should use merely ...
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Fri, 30 Jun 2006 15:32:50 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Rookie Perl Question
Message-Id: <slrneab2ji.4br.tadmc@magna.augustmail.com>
Eric R. Meyers <ermeyers@adelphia.net> wrote:
> print if ( ! m/^[#]/ );
That is fine if you are trying to hide what the code does.
In case you might prefer maintainable code instead, then:
print unless /^#/;
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Fri, 30 Jun 2006 20:21:14 +0000
From: Spartacus <spartacus@mailinator.net>
Subject: RSS preprocessors
Message-Id: <e8413s$csb$02$2@news.t-online.com>
I'm searching for RSS/XML server side publishing systems. Are there any good
perl (or lamp) applications in the open-source realm anyone can recommend
with or without web-based cgi-interface?
------------------------------
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 9411
***************************************
