[27240] in Perl-Users-Digest
Perl-Users Digest, Issue: 9021 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Mar 5 21:05:42 2006
Date: Sun, 5 Mar 2006 18:05:04 -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 Sun, 5 Mar 2006 Volume: 10 Number: 9021
Today's topics:
'require'ing globals without 'used only once' complaint <erco@3dsite.com>
Re: A Problem With GD <markem@airmail.net>
Re: A Problem With GD <markem@airmail.net>
Re: A Problem With GD <markem@airmail.net>
Re: A Problem With GD <markiemark@wahlberg.org>
Are python's generators / yield possible in perl? <nobody@dizum.com>
Re: Different results parsing a XML file with XML::Simp <hjp-usenet2@hjp.at>
merge event loops and threads (was Re: simple pointer o <uri@stemsystems.com>
Re: Question about sub calling other sub <news@chaos-net.de>
Re: Question about sub calling other sub <news@chaos-net.de>
Re: Question about sub calling other sub (Anno Siegel)
Re: Question about sub calling other sub xhoster@gmail.com
Re: Upload file format checking xhoster@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 05 Mar 2006 16:53:45 -0800
From: Greg Ercolano <erco@3dsite.com>
Subject: 'require'ing globals without 'used only once' complaints from 'perl -w'?
Message-Id: <uKLOf.1084$RC4.663@fe03.lga>
I'm trying to figure out a way to load global variables using 'require'
with 'perl -w' enabled, but without getting "<varname> used only once" errors.
The only "solution" I've seen is to make sure all globals are referenced
more than once, but that gets hard to manage when you scale up the project.
My situation is a project of cgi-bin scripts, where there are several scripts
all wanting to load global settings from a single 'config.pl' file.
My current way of doing things is to make a 'config.pl' file that has the
global settings, ie:
$G::bgcolor = "#ff0000";
$G::cgibin = "/cgi-bin/MyApp/";
# ..etc..
1;
..and then all the actual scripts load these settings with 'require', eg:
#!/usr/bin/perl -w
use strict;
require "config.pl";
..
..that being in each of the potentially many script files that make up
the project.
Trouble is, if a script only refers to a global once, a "used only once"
error is printed, once per variable, which clogs the httpd daemon's error
logs with errors, one per variable.
The easy solution is to turn off the -w flag, but often it's useful to
leave it on during production to catch runtime errors.
From a developer's point of view, it's a real PITA to manually ensure
having no-op references for each global in /each/ script, eg:
#!/usr/bin/perl -w
use strict;
require "config.pl";
$G::bgcolor = $G::bgcolor; # silence 'used once' errors
$G::cgibin = $G::cgibin; # ""
..that becomes unmanageable fast.
Is there a 'right way' to do this without getting too 'hacky',
and without disabling -w? Maybe making the globals into a package?
Code examples welcome..
------------------------------
Date: Sun, 05 Mar 2006 14:27:29 -0600
From: Mark Manning <markem@airmail.net>
Subject: Re: A Problem With GD
Message-Id: <120mibarunsi00d@corp.supernews.com>
I'm sorry, but I believe you mis-quoted. Uri Guttman is the person who stated
that so I must assume the "dumb fuck" is either you or Mr. Guttman.
Mark Manning wrote:
> Mark Manning <markem@airmail.net> trolled:
>
>>Uri Guttman wrote:
>>
>>>finally we can invoke godwin's law and end this stupid thread.
>>>we all agree manning is an arrogant ass who will never get clpm
>>>or the larger perl community (especially cpan) nor will he ever
>>>understand api design. so stop responding to him as godwin's law
>>>implies. he seems to come back every couple of days and blather
>>>so give it a rest and maybe he will quietly slink away.
>>>
>>>amazing how that law works and how this jerk was totally
>>>anticipated by it.
>
>
> Godwin's "law" is not a real law, you dumb fuck. Only a complete
> moron who can't think for himself would recognize Godwin's "law" as
> anything more than a not-so-funny joke.
>
> cordially, as always,
>
> rm
------------------------------
Date: Sun, 05 Mar 2006 14:31:52 -0600
From: Mark Manning <markem@airmail.net>
Subject: Re: A Problem With GD
Message-Id: <120miji6jveb657@corp.supernews.com>
David H. Adler wrote:
> On 2006-03-02, Mark Manning <markem@airmail.net> wrote:
>
>>Since it is you and I talking here - you should be able to know what
>>the "it" is. Others, if they want to know what "it" is should read the
>>previous posts. Therefore, the "it" is unnecessary.
>
>
> Therefore, you are clearly unintested in participating in usenet in a
> useful, accepted way.
The one does not mean the other.
> Why you seem surprised that people are annoyed that you have no interest
> in interacting with them in an appropriate and polite way is what I
> don't understand.
I have never said I was surprised. Saddened maybe - but not surprised. There
were people like this in the 70's, 80's, and 90's - why would the 2000's be any
different? And before you say "There wasn't any Usenet in the 70's!" remember
that what you call "Usenet" was just a loose network of people from different
universities back in the 70's.
> Regardless, I'm sure that you see no reason to act any differently and I
> suppose that's your right. It is also the right of everyone here to call
> you on inappropriate behavior and/or killfile you. I certainly hope you
> never need any more assistance - regardless of how *you* see it. You
> probably won't get it.
I haven't asked for assistance on Usenet in well over a decade.
> On your own head be it.
>
> dha
Such as drama queen.
------------------------------
Date: Sun, 05 Mar 2006 15:06:34 -0600
From: Mark Manning <markem@airmail.net>
Subject: Re: A Problem With GD
Message-Id: <120mkkl98nhr19b@corp.supernews.com>
A. Sinan Unur wrote:
> Mark Manning <markem@airmail.net> wrote in
> news:1208qpaie24bgae@corp.supernews.com:
>
>
>>A. Sinan Unur wrote:
>>
>>>You might be missing the point of UseNet: When I have a
>>>question/issue, I find a group where my question is relevant, and
>>>then post it to receive any feedback anyone on that group can give.
>>
>>Well, the reason I posted to comp.lang.perl.misc was beause there
>>isn't a comp.lang.gd or anything like that.
>
>
> I am not saying comp.lang.perl.misc was the wrong place to post your
> question, although comp.lang.perl.modules might have been more
> appropriate.
That - is probably true.
>
> When you post on comp.lang.perl.misc, you are expected to post code that
> is strict and warnings clean, and others can run with little effort.
Only - if you are looking for help. My original post did not say I was looking
for help. It said:
"I believe I may have uncovered a problem with the GIF renderer under GD...."
Not
"I need help with GD."
>>>Each group has its own rules. As I try to stay away from the alt.*
>>>hierarchy, it is not hard to find out what those rules are and follow
>>>them.
>>>
>>>c.l.p.m. also has rules. One of those is that you need to provide
>>>enough information with your post. IMNSHO, that is especially true
>>>when you are blaming mistakes in the code on imagined defects in
>>>someone else's library in a public forum.
Your first mistake was thinking I was asking for help. Your second is in
thinking I was "blaming mistakes". It never said "I KNOW I've found a problem"
or "There IS a problem" it said:
"I BELIEVE I MAY HAVE uncovered a problem..."
You jumped the gun. Not once but several times.
> A neutral question would have been: "How do I get in touch with the
> author of libgd or the author of GD.pm?" with no extranous claims of
> bugs in either library.
Well, that may be a better way of doing it, but my way has always been to lead
in with what it is I am thinking. Which was what I posted. The person who
e-mailed me did point me in the direction of Mr. Stein's web page. I am
presently attempting to track down the bug in Mr. Boutell's source code. If I
can find it I will submit the bug back to him so it can be removed. The hint in
the problem which I posted is that there is one off-color dot for every four
dots. Which means (to me) that the GIF section is using an 8bit word while the
truecolor software uses a 32bit word. Therefore, even though the truecolor flag
has already been set - it is being ignored somewhere in the code and that code
is overwritting the truecolor image thinking that it is writing out GIF (or
8bit) information into the image.
> Incidentally, those questions are trivially answered by a two second
> Google or CPAN query, so what is the point of asking thousands of people
> around the world to do that for you?
Again - you state that I am asking a question. Yet, above you recognize that
maybe I am correct in my assertion that I was not looking for help. Which side
are you going to be on? Either I was asking for help or I was looking for someone.
>
> A statement that raises the possibility of a bug requires a test case
> that replicates the behavior.
Yes, that is correct. Mr. Stein has already tested the program I sent and
informed me that the GD.pm package is not where the error is located. Which is
why I am concentrating on Mr. Boutell's code.
>>>In that case, how can you make the claim that there is a bug in
>>>GD.pm?
>>
>>As I have said before. The code that was posted was thrown together
>>and it gave the results it gave. That code is not THE code I am
>>working on but as quickly reduced and posted as I could after I'd
>>decided to go ahead and do it. My mistake - is in posting the code.
>
>
> No, your mistake is not posting code in the first place. Anyone who
> might be willing to help you will need to be able to replicate the
> behavior.
No - it definitely was a mistake. I've already tracked down yet another problem
with the code which I will be including in my final write-up to Mr. Boutell.
> Your second mistake is posting code that was not strict and warnings
> clean.
No - my mistake was just posting the code.
>
> Your third mistake was to call me an ass for trying to teach you how to
> write code so you can eliminate the possibility of bugs in your *own*
> code before claiming a bug in a library.
And what if I did not want you to "teach me" anything? Yet, when I first said
"no thanks" to you - you continued to try to cram down my throat your special
"teachings". Something forced onto someone else is not something that person
will thank you for.
>>>By the way, you seem to have a fascination with rear-ends? Why do you
>>>have to mention them every few words? Could you stop cursing maybe?
>>
>>It was in response to what you were saying - as you well know.
>
>
> Oh, I see ...
No. I don't think you really do as is obvious by your previous postings.
>
> "A. Sinan Unur" <1usa@llenroc.ude.invalid> wrote in
> news:Xns9775C5C9B6F93asu1cornelledu@127.0.0.1:
>
>
>>>>Right margin comments that wrap are silly and annoying.
>>>>
>>>>Give your variables meaningful names, and declare them in the
>>>>smallest applicable scope so you don't have to resort to comments
>>>>to remember what they do.
>
>
> **That** justifies you calling me an ass?!
No - try this:
"Not posting warnings and strict clean code is considered *very* rude
here. So, here's a piece of my mind before I wrestle through your code."
I did not ask you to "wrestly through your code" - nor to give me a piece of
your mind - you asked me:
"How can anyone else reproduce the error if you do not provide a short but
complete script that generates the behavior you see?"
I didn't care if you could reproduce the error but as I've said I went
"whatever" and provided a short, but complete script and you then said:
"It looks like you haven't read the posting guidelines yet. Please do."
Followed by the rest that went downhill from there.
>>I DARE you to ...
>
>
> *Sigh*
>
> I am sure everyone else has had enough of this. So, bye.
Ah. So you couldn't find anywhere that I said anyone had to conform to my way
of doing things. You can only do that if you cut up whatever I've posted and
change it around to fit your outlook. Which IS that you want everyone to
conform to your way of doing things.
I believe you are beginning to realize that what you did was not a very nice
thing to do. Believe me when I say I worked at a help desk for years at college
and some of the people who worked there began acting like you have acted here.
It happens. You answer hundreds and thousands of questions. Many repetitious,
many you ask yourself why they even bothered to come to you they know so little
or get everything wrong. The trap is allowing yourself to begin treating
everyone like they are morons or that you are better than they are. Especially
when you have no idea who that other person really is.
>
> Sinan
Heh. I already know this isn't going to be the last message.
------------------------------
Date: Mon, 06 Mar 2006 00:52:18 GMT
From: Mark Manning <markiemark@wahlberg.org>
Subject: Re: A Problem With GD
Message-Id: <6JLOf.263$_b.42623@news20.bellglobal.com>
Mark Manning <markem@airmail.net> trolled:
> I'm sorry, but I believe you mis-quoted. Uri Guttman is the
> person who stated that so I must assume the "dumb fuck" is either
> you or Mr. Guttman.
I am sorry, but you not only top-posted, you failed to line up the
>>>'s properly. If you had lined up the >>>'s properly you would
see that Guttman, and not you, was the target of my post.
Have a nice day.
cordially, as always,
rm
> Mark Manning wrote:
> > Mark Manning <markem@airmail.net> trolled:
> >
> >>Uri Guttman wrote:
> >>
> >>>finally we can invoke godwin's law and end this stupid thread.
> >>>we all agree manning is an arrogant ass who will never get clpm
> >>>or the larger perl community (especially cpan) nor will he ever
> >>>understand api design. so stop responding to him as godwin's law
> >>>implies. he seems to come back every couple of days and blather
> >>>so give it a rest and maybe he will quietly slink away.
> >>>
> >>>amazing how that law works and how this jerk was totally
> >>>anticipated by it.
> >
> >
> > Godwin's "law" is not a real law, you dumb fuck. Only a complete
> > moron who can't think for himself would recognize Godwin's "law" as
> > anything more than a not-so-funny joke.
> >
> > cordially, as always,
> >
> > rm
--
How come so many stat fans, and pseudo stat fans, are Jewish?
------------------------------
Date: Mon, 6 Mar 2006 00:30:02 +0100 (CET)
From: Nomen Nescio <nobody@dizum.com>
Subject: Are python's generators / yield possible in perl?
Message-Id: <a2a21cb30891ee5e7e7ca8ed41462093@dizum.com>
Does perl have an equivalent to python's generators? I want
to be able to basically call yield() instead of return() to implement
iterators. If this exists, can XS code access it via perl guts?
------------------------------
Date: Sun, 05 Mar 2006 23:09:03 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Different results parsing a XML file with XML::Simple (XML::Sax vs. XML::Parser)
Message-Id: <dufni0$1jo$1@hermes.luga.at>
Erik Wasser wrote:
[XML::Simple gives correct results with XML::Parser, but wrong results
with XML::SAX]
> My question was: why two XML parsers are getting different results?
> The different results are confusing me not unicode itself.
Looks like a bug in XML::SAX or one of the libraries it uses.
However, like Sinan, I cannot reproduce it here on a Debian Sarge
system:
perl, v5.8.4 built for i386-linux-thread-multi
XML::Simple version 2.14
XML::SAX version 0.12
XML::Parser version 2.34
libexpat1 1.95.8-3
So it may be caused by something weird in your einvironment.
hp
--
This is not a signature
------------------------------
Date: Sun, 05 Mar 2006 18:34:13 -0500
From: Uri Guttman <uri@stemsystems.com>
To: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: merge event loops and threads (was Re: simple pointer operations (newbe))
Message-Id: <x7oe0k4gay.fsf_-_@mail.sysarch.com>
>>>>> "TvP" == Tassilo v Parseval <tassilo.von.parseval@rwth-aachen.de> writes:
TvP> Also sprach Uri Guttman:
>>
AS> As far as I'm concerned thread users get what they deserve and deserve
AS> what they get :)
>>
>> as a strong advocate of event loops over threads i fully agree with that
>> sentiment. :)
TvP> Well, I know that you know that. But for Event::Lib, I received
TvP> quite a few mails from people who were apparently under the
TvP> misapprehension that each event handler is triggered in its own
TvP> process or thread. An event-based application is still running
TvP> sequentially so it will not always spare one the pain to use
TvP> fork() or threads.
i have an idea and most of the design for a module that will allow event
loops to work well with kernel (not perl!) threads that will run
blocking operations. of course it involves xs which i have done very
little with. would you (or anyone else) be interested in working on it
with (or for :) me? one variation on it (which could use this new module
or be its own module) would do true async file i/o and be synchronized
with the event loop. i have done such a beast before in pure c and it
worked very well. i think these modules are wanted and would be useful
to many event loop apps. imagine a simple api for async file i/o in perl
that was actually portable and bypasses all those wacko kernel aio apis
that each OS provides.
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: Sun, 5 Mar 2006 21:25:39 +0100
From: Martin Kissner <news@chaos-net.de>
Subject: Re: Question about sub calling other sub
Message-Id: <slrne0mia3.7ej.news@maki.homeunix.net>
Randal L. Schwartz wrote :
>>>>>> "Martin" == Martin Kissner <news@chaos-net.de> writes:
>
>Martin> I have a sub, which can be called by different other subs.
>Martin> There are some slight differences depending from which sub it is called.
>Martin> Is it possible to find out, which other sub called the actual sub?
>
> Please, please don't do this. You are introducing fragility and instability in
> your code by thinking this way.
Thank you for your feedback.
I will gladly take advice from expierienced Perl programmers.
Still more gladly I would like to understand where the problem is or
how the fragility and instability could arise.
> If you want a subroutine to have different behaviors, pass it a flag argument
> of some kind.
This is what I have done now using a variable $action.
> But why not just create two different subroutines to call, so
> the "flag" is effectively part of the subroutine name. Then factor out the
> parts in common of those two subroutines to a new subroutine or two. Then you
> have more reusable components, and a much better and clearer design.
I am very interested in learning to improve my code design.
In this case the differences are so small that I feel it would be better
to have only one sub. Else I'd feel like using two different tools for
driving screws *in* and *out* ;-)
Actually when I started I had three very simliar looking subs which I
now put together into one. By passing flags ($action) I trigger what
they are supposed to do.
Best regards
Martin
--
perl -e '$S=[[73,116,114,115,31,96],[108,109,114,102,99,112],
[29,77,98,111,105,29],[100,93,95,103,97,110]];
for(0..3){for$s(0..5){print(chr($S->[$_]->[$s]+$_+1))}}'
------------------------------
Date: Sun, 5 Mar 2006 21:31:51 +0100
From: Martin Kissner <news@chaos-net.de>
Subject: Re: Question about sub calling other sub
Message-Id: <slrne0miln.7ej.news@maki.homeunix.net>
Christian Winter wrote :
> Martin Kissner schrieb:
>> hello together,
>>
>> I have a sub, which can be called by different other subs.
>> There are some slight differences depending from which sub it is called.
>> Is it possible to find out, which other sub called the actual sub?
> See "perldoc -f caller".
> The fourth element in the list returned by caller(EXPR) is
> the complete name of the invoking sub, including the package
> name, so in this case you will get back main::one and
> main::two.
Thank you.
This looks like the solution I was looking for. Good to know.
Nevertheless I have decided to stick with the flags version for now.
Thanks also to Dr.Ruud for the feedback.
Best regards
Martin
--
perl -e '$S=[[73,116,114,115,31,96],[108,109,114,102,99,112],
[29,77,98,111,105,29],[100,93,95,103,97,110]];
for(0..3){for$s(0..5){print(chr($S->[$_]->[$s]+$_+1))}}'
------------------------------
Date: 5 Mar 2006 23:31:00 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Question about sub calling other sub
Message-Id: <dufsbk$5bo$2@mamenchi.zrz.TU-Berlin.DE>
Martin Kissner <news@chaos-net.de> wrote in comp.lang.perl.misc:
> Randal L. Schwartz wrote :
> >>>>>> "Martin" == Martin Kissner <news@chaos-net.de> writes:
> >
> >Martin> I have a sub, which can be called by different other subs.
> >Martin> There are some slight differences depending from which sub it
> is called.
> >Martin> Is it possible to find out, which other sub called the actual sub?
> >
> > Please, please don't do this. You are introducing fragility and instability in
> > your code by thinking this way.
>
> Thank you for your feedback.
> I will gladly take advice from expierienced Perl programmers.
> Still more gladly I would like to understand where the problem is or
> how the fragility and instability could arise.
>
> > If you want a subroutine to have different behaviors, pass it a flag argument
> > of some kind.
>
> This is what I have done now using a variable $action.
>
> > But why not just create two different subroutines to call, so
> > the "flag" is effectively part of the subroutine name. Then factor out the
> > parts in common of those two subroutines to a new subroutine or two. Then you
> > have more reusable components, and a much better and clearer design.
>
> I am very interested in learning to improve my code design.
> In this case the differences are so small that I feel it would be better
> to have only one sub. Else I'd feel like using two different tools for
> driving screws *in* and *out* ;-)
>
> Actually when I started I had three very simliar looking subs which I
> now put together into one. By passing flags ($action) I trigger what
> they are supposed to do.
The flag mechanism is sometimes used to avoid code duplication. In general,
I'd go with Randal and try to factor out the common part(s). "In a good
program, every routine does almost nothing". Sometimes different tools
for screwing a particular kind of screw in and out is a good solution.
But don't use the caller instead of an explicit flag. You create a
dependency that doesn't have to be there. There may be reasons to
call the subs from other packages, or to rename the packages that are
calling them. In both cases, the basically unrelated subs must be
changed. With the other solutions, (flag or part of the sub name)
everything happens at the place of call.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: 05 Mar 2006 23:53:15 GMT
From: xhoster@gmail.com
Subject: Re: Question about sub calling other sub
Message-Id: <20060305185752.751$Re@newsreader.com>
anno4000@lublin.zrz.tu-berlin.de (Anno Siegel) wrote:
> >
> > Actually when I started I had three very simliar looking subs which I
> > now put together into one. By passing flags ($action) I trigger what
> > they are supposed to do.
>
> The flag mechanism is sometimes used to avoid code duplication. In
> general, I'd go with Randal and try to factor out the common part(s).
> "In a good program, every routine does almost nothing".
I can't say I agree with that. If each sub does almost nothing, i.e. no
more or even less than a simple perl expression does, there is little point
in having them.
> Sometimes
> different tools for screwing a particular kind of screw in and out is a
> good solution.
>
> But don't use the caller instead of an explicit flag. You create a
> dependency that doesn't have to be there. There may be reasons to
> call the subs from other packages, or to rename the packages that are
> calling them. In both cases, the basically unrelated subs must be
> changed.
That I agree with.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 05 Mar 2006 22:24:40 GMT
From: xhoster@gmail.com
Subject: Re: Upload file format checking
Message-Id: <20060305172917.534$uX@newsreader.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
> Gunnar Hjalmarsson wrote:
> > Bryan wrote:
> >> What is the best way to validate that an uploaded file (using CGI.pm)
> >> is a tab delimited table of the correct format? I.e. every line has
> >> the same number of columns as the header, and the header has to match
> >> a predefined set of table headers. Should it be done as the file is
> >> read in? After I store it to disk?
> >
> > I don't understand how you would be able to validate the file before it
> > has been stored to disk, at least temporarily.
>
> You (or more exactly, the CGI module) are reading the contents of the
> file from stdin. In general, it is certainly possible to validate the
> contents as it is being read - it doesn't have to be stored at all.
> However, CGI stores the contents in a temporary file, so usually, when
> you get around to it, it is already on disk. But from reading the docs,
> it looks like upload_hook might be used to change that (I've never used
> it).
upload_hook lets you peek at the file-data while it is being saved to disk,
but doesn't let you peek at instead of it being written to disk.
But it is a fairly simple hack to make it work that way, something like:
if ($DISABLE_UPLOADS) {
while (defined($data = $buffer->read)) {
if (defined $self->{'.upload_hook'}) {
$totalbytes += length($data);
&{$self->{'.upload_hook'}}($filename ,$data,
$totalbytes, $self->{'.upload_data'});
}
}
last UPLOADS;
}
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 9021
***************************************
