[32885] in Perl-Users-Digest
Perl-Users Digest, Issue: 4163 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Mar 5 03:09:29 2014
Date: Wed, 5 Mar 2014 00:09:05 -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 Wed, 5 Mar 2014 Volume: 11 Number: 4163
Today's topics:
Re: last iteration of a for loop <rweikusat@mobileactivedefense.com>
Re: last iteration of a for loop <ben@morrow.me.uk>
Re: use strict; use warnings; <news@todbe.com>
Re: use strict; use warnings; <john@castleamber.com>
Re: use strict; use warnings; <triflemenot@protocol.invalid>
Re: use strict; use warnings; <triflemenot@protocol.invalid>
Re: use strict; use warnings; <jurgenex@hotmail.com>
Re: use strict; use warnings; <johnblack@nospam.com>
Re: use strict; use warnings; <ben@morrow.me.uk>
Re: use strict; use warnings; <john@castleamber.com>
Re: use strict; use warnings; <triflemenot@protocol.invalid>
Re: use strict; use warnings; <xhoster@gmail.com>
Re: use strict; use warnings; <jurgenex@hotmail.com>
Re: using real objects in constructors <jimsgibson@gmail.com>
Re: using real objects in constructors (Tim McDaniel)
Re: using real objects in constructors <ben@morrow.me.uk>
Re: using real objects in constructors (Tim McDaniel)
Re: using real objects in constructors <news@lawshouse.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 04 Mar 2014 23:19:04 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: last iteration of a for loop
Message-Id: <871tyh8sd3.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> >
>> > Smartmatch, given and when have recently (5.18) been retroactively
>> > marked experimental. 5.18 will warn if it sees them, unless you've
>> > disabled the warning: see perl518delta. The semantics are rather badly
>> > designed, and are likely to change, if the features don't simply do away
>> > altogether.
>>
>> The actual text says
>>
>> Smart match, added in v5.10.0 and significantly revised in
>> v5.10.1, has been a regular point of complaint.
[...]
>> It is clear that smartmatch is almost
>> certainly either going to change or go away in the
>> future. Relying on its current behavior is not recommended.
[...]
>> http://perldoc.perl.org/5.18.0/perldelta.html#The-smartmatch-family-of-features-are-now-experimental
>>
>> AIUI, this does not state that the idea to introduce a real switch/ case
>> statement into Perl was 'a rather bad one'
>
> You are using quote marks. Who are you quoting?
If in doubt, an invisible 'Greg KH' who has no problems with claiming to
be "The Greatest Programmer On Earth" and considering switch-statements
so incomprehensible that they have to be replaced at the same time and
any other dedicated member of the software section of the "There's
nothing worthwhile of being stated which can't be expressed clearly by
a string of differently accentuated 'fucks'"-tribe.
[...]
>> Considering this, I think that it is likely that Perl will retain the
>> given/ when/ default part, although with different and possibly entirely
>> 'unsmart' matching semantics, eg, use equality instead, and probably,
>> with some way to request for 'set matches', ie, consider a condition as
>> true when the given value is a member of somehow specified list.
>
> Well, in principle that's all that smartmatch is supposed to be doing:
> equality or regex match or set match, as appropriate. In practice this
> falls down at the first hurdle: Perl 5 has *two* equality operators, and
> it matters which you use. (It also doesn't have a well-defined
> reification of 'a class', making is-a tests equally problematic.)
I was writing about 'equality' and possibly, some notion of set
matches. I didn't include regexes because these can already be matched
against $_ without writing the '$_ =~'-part every time. I was also being
intentionally vague on 'set matches' because this was supposed to
include the possibility of something with a much more limited scope than
the 14 different set matches documented for perl 5.10.1 smart matching.
I'll address the 'equality' issue below.
>> OTOH, the ~~-operator might will disappear entirely if it turns out
>> to be impossible to agree upon sensible semantics (and I certainly
>> wouldn't mind that as I found 'smart matching' rather dumb on several
>> occasions).
>
> If you can define sensible and useful semantics for 'when', then ~~ can
> be defined to do the same thing.
That would hardly be worthwhile.
[...]
> OTOH, given/when without some sort of smart matching just isn't that
> useful.
Trying to be so ueber-smart that the final result is nothing because the
problem invariably diffuses into a cloud of nebolous opinions which all
have something going for and against them it isn't particular smart in
the end. "Do something less ambitious for now and leave the complicated
stuff for the future" is IMHO a better approach. Eg, a C
switch-statement requires all cases to be integer constants. That's
already useful when dealing with functions returning some discrete
values and possibly, a default case, eg, fork or <=> or anything which
returns 'magic numbers' to indicate different things. 'Equality' than
becomes == and if this doesn't do what is desired, another construct has
to be used. Going one step further, one could allow 'string literals'
(including interpolation) as well. 'Equality' than mean 'use == if it is
an integer constant and eq otherwise'. Additionally dealing with literal
regexes shouldn't be a big problem.
This would cover almost everything I've been using given/when for so
far and would still go beyond what is provided by the most 'current'
version of Java. I've actually used functions a la
sub eql($)
{
return $_ == $_[0];
}
or
sub equal($)
{
return $_ eq $_[0];
}
in the past in 'switch statements implemented as for loop' to avoid
repeating the '$_' (of course, I want to use that, that's why I wrote
for (something) {} in the first place) and the same comparison operator
every time.
Another simplistic addition would be to allow 'range operator
statements' in order to match a sequence of integers or literal strings.
> (given doesn't even alias, making it's most obvious use, as an
> equivalent to VB's 'with', impossible.)
AFAIK, with-statemens have existed in Pascal since "the dawn of times"
(relative to the age of VB, that is) ...
------------------------------
Date: Wed, 5 Mar 2014 00:29:57 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: last iteration of a for loop
Message-Id: <5p7iua-v4r1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> > OTOH, given/when without some sort of smart matching just isn't that
> > useful.
>
> Trying to be so ueber-smart that the final result is nothing because the
> problem invariably diffuses into a cloud of nebolous opinions which all
> have something going for and against them it isn't particular smart in
> the end. "Do something less ambitious for now and leave the complicated
> stuff for the future" is IMHO a better approach. Eg, a C
> switch-statement requires all cases to be integer constants. That's
> already useful when dealing with functions returning some discrete
> values and possibly, a default case, eg, fork or <=> or anything which
> returns 'magic numbers' to indicate different things.
Do you really think so? I don't. Given a choice between (say)
given ($pid) {
when (undef) {
die "fork failed";
}
when (0) {
child();
}
default {
parent();
}
}
and
if (!defined $pid) {
die "fork failed";
}
elsif ($pid == 0) {
child();
}
else {
parent();
}
I think the if/elsif wins on both concision and clarity. And that's not
even taking into account the other ways Perl provides of writing the
same logic, nor the fact that interfaces that return magic numbers are
not very Perlish in the first place.
> 'Equality' than
> becomes == and if this doesn't do what is desired, another construct has
> to be used.
Yeah, this is more-or-less equivalent to my assumption that more syntax
would be required in the 'when' part. Perhaps something like
given ($foo) {
when/n (2) {...}
when/s ("foo") {...}
when/d {...}
}
(that /d is 'defined', not 'default') to indicate the type of match to
use. (Possibly not that syntax, of course, which I just pulled out of my
arse based on regex modifiers.)
> Going one step further, one could allow 'string literals'
> (including interpolation) as well. 'Equality' than mean 'use == if it is
> an integer constant and eq otherwise'. Additionally dealing with literal
> regexes shouldn't be a big problem.
You are assuming here that the condition part of the when (or the RHS of
~~) can only be a literal? That mostly solves the typing problem, though
it would necessarily be restricted to *real* literals: a sub returning a
constant would not do, because constants like that are subject to type
coercion just like any other values. (That is, just because EPERM was
defined as an integer constant originally, that does not mean it will
still be (only) an integer constant by the time we get to compiling the
when statement.) I suspect that would be too limiting to be useful: I
can't remember the last time I compared something to a list of
literally-specified magic numbers; I go to some effort to make sure I
don't need to do that sort of thing.
> This would cover almost everything I've been using given/when for so
> far and would still go beyond what is provided by the most 'current'
> version of Java. I've actually used functions a la
>
> sub eql($)
> {
> return $_ == $_[0];
> }
>
> or
>
> sub equal($)
> {
> return $_ eq $_[0];
> }
>
> in the past in 'switch statements implemented as for loop' to avoid
> repeating the '$_' (of course, I want to use that, that's why I wrote
> for (something) {} in the first place) and the same comparison operator
> every time.
Mmm. It does save you a little; I'm not sure it's enough to be worth
having, though.
> > (given doesn't even alias, making it's most obvious use, as an
> > equivalent to VB's 'with', impossible.)
>
> AFAIK, with-statemens have existed in Pascal since "the dawn of times"
> (relative to the age of VB, that is) ...
You are, of course, right. I've never spoken Pascal (or anything
Pascal-derived), so it didn't come to mind. (I have, for my sins,
written VB on occasion. I had to wash my mouth out afterwards.)
Ben
------------------------------
Date: Tue, 04 Mar 2014 16:48:00 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: use strict; use warnings;
Message-Id: <lf5s84$nj2$1@news.albasani.net>
On 3/4/2014 13:26, Trifle Menot wrote:
> On Tue, 4 Mar 2014 20:00:21 +0000 (UTC), Kaz Kylheku <kaz@kylheku.com>
> wrote:
>
>> The practice of holding unverifiable assumptions to be true is precisely
>> what Dawkins is known for opposing.
>
> Without axioms there would be no math. But I think atheism is the wrong
> axiom.
>
> a) do I exist: pin prick, ouch.
>
> b) does the universe exist: hmmm, look around.
>
> c) does the universe exist without cause: ???
>
> If so, why is there "something" rather than "nothing." Why does anything
> exist at all? A natural "void," without any matter or energy, seems more
> natural to me. Like starting from 0. :-)
>
> So I believe the universe had a cause. But of course atheists must ask
> "who created God?"
Who did?
> Einstein knew time is a property of the universe, the so called fourth
> dimension. Human existence is limited by time and the spatial dimensions
> of the universe. We cannot step outside that reality.
>
> But God exists outside time itself. That's what "eternal" means. But in
> programming terms, we may wonder, did God "bootstrap" his own existence?
> I don't know.
god does not exist within or outside of time. Mother nature rules all.
> It's obvious that humans of flesh and blood cannot exist outside time
> itself. Since we cannot experience that condition, how can we possibly
> understand it? Human intellectual capacity is limited, axiomatically so,
> by the reality where we exist. We don't have sufficient reasoning power
> to understand if God bootstrapped himself, or how.
>
> Thus my remark about God and DNA. Studying DNA is one thing. Tampering
> with it is another. Vengeance belongs to God.
So not only do you believe in the supernatural, but you believe this being
to be vengeful.
> I don't intend to fan the fire of atheism vs. faith. I was merely noting
> that even great programmers should maintain humility. Certainly so, when
> facing God.
I've worked with Larry and believe me when I say he doesn't expect to be
worshiped. ;)
------------------------------
Date: Tue, 04 Mar 2014 19:22:15 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: use strict; use warnings;
Message-Id: <87lhwpxwvs.fsf@castleamber.com>
Trifle Menot <triflemenot@protocol.invalid> writes:
> I don't intend to fan the fire of atheism vs. faith. I was merely noting
> that even great programmers should maintain humility. Certainly so, when
> facing God.
Which is a meaninless statement to people who don't believe.
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
------------------------------
Date: Wed, 05 Mar 2014 01:43:03 +0000
From: Trifle Menot <triflemenot@protocol.invalid>
Subject: Re: use strict; use warnings;
Message-Id: <6ptch9dcrthfhhq67bovste97qd20pchfp@4ax.com>
On Tue, 04 Mar 2014 16:48:00 -0800, "$Bill" <news@todbe.com> wrote:
> So not only do you believe in the supernatural
Doubters say "supernatural" as though faith is baseless superstition.
> but you believe this being to be vengeful
After praying, Samson got vengeance for one of his eyes.
> I've worked with Larry and believe me when I say he doesn't expect
> to be worshiped. ;)
Larry may be great, but I wasn't talking about him.
I was making an observation about programmers in general. Many of them
are arrogant little snots. I've met enough to know.
But let's not carry this any further. It's well off topic already. I
didn't come here to troll. I had a question about printing a string in
hex, and Rainer gave a helpful answer. But as often happens on usenet,
one degenerate person went crazy, and things got ugly.
I like Perl for throwing things together, but I don't use it everyday.
Other things demand my attention, and there I go ...
------------------------------
Date: Wed, 05 Mar 2014 01:47:41 +0000
From: Trifle Menot <triflemenot@protocol.invalid>
Subject: Re: use strict; use warnings;
Message-Id: <va0dh99ki7t5td8dti9aumafmp20erlbco@4ax.com>
On Tue, 04 Mar 2014 19:22:15 -0600, John Bokma <john@castleamber.com>
wrote:
>Trifle Menot <triflemenot@protocol.invalid> writes:
>
>> I don't intend to fan the fire of atheism vs. faith. I was merely noting
>> that even great programmers should maintain humility. Certainly so, when
>> facing God.
>Which is a meaninless statement to people who don't believe.
True, but without respect for eternal authority, people often fail at
humility.
------------------------------
Date: Tue, 04 Mar 2014 18:21:57 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: use strict; use warnings;
Message-Id: <rm1dh9dkpd81afrh32lqkaha2ookqsoce2@4ax.com>
Trifle Menot <triflemenot@protocol.invalid> wrote:
>I don't intend to fan the fire of atheism vs. faith. I was merely noting
>that even great programmers should maintain humility. Certainly so, when
>facing God.
As the antecedent in this implication is wrong, the consequent of the
conditional is irrelevant.
jue
------------------------------
Date: Tue, 4 Mar 2014 20:56:59 -0600
From: John Black <johnblack@nospam.com>
Subject: Re: use strict; use warnings;
Message-Id: <MPG.2d804e759c9531ed9897c2@news.eternal-september.org>
In article <61hch9ljno156km5417ebdtq7ielgeji9c@4ax.com>, triflemenot@protocol.invalid says...
> On Tue, 4 Mar 2014 20:00:21 +0000 (UTC), Kaz Kylheku <kaz@kylheku.com>
> wrote:
>
> > The practice of holding unverifiable assumptions to be true is precisely
> > what Dawkins is known for opposing.
>
> Without axioms there would be no math.
snip nonsense...
John Black
------------------------------
Date: Wed, 5 Mar 2014 03:17:33 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: use strict; use warnings;
Message-Id: <djhiua-mms1.ln1@anubis.morrow.me.uk>
Quoth Trifle Menot <triflemenot@protocol.invalid>:
>
> I don't intend to fan the fire of atheism vs. faith.
Liar.
Ben
------------------------------
Date: Tue, 04 Mar 2014 21:31:10 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: use strict; use warnings;
Message-Id: <877g89tj7l.fsf@castleamber.com>
Trifle Menot <triflemenot@protocol.invalid> writes:
> On Tue, 04 Mar 2014 19:22:15 -0600, John Bokma <john@castleamber.com>
> wrote:
>
>>Trifle Menot <triflemenot@protocol.invalid> writes:
>>
>>> I don't intend to fan the fire of atheism vs. faith. I was merely noting
>>> that even great programmers should maintain humility. Certainly so, when
>>> facing God.
>
>>Which is a meaninless statement to people who don't believe.
>
> True, but without respect for eternal authority, people often fail at
> humility.
My experience with most people who claim to be religious is simply this:
they are religious when it's adventageous to them... So I think in
general people often fail at humility, no matter what they believe, if
they believe.
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
------------------------------
Date: Wed, 05 Mar 2014 04:17:35 +0000
From: Trifle Menot <triflemenot@protocol.invalid>
Subject: Re: use strict; use warnings;
Message-Id: <lc8dh95qj4oij1lbum770gce9tj6qbr9i0@4ax.com>
On Wed, 5 Mar 2014 03:17:33 +0000, Ben Morrow <ben@morrow.me.uk> wrote:
>Quoth Trifle Menot <triflemenot@protocol.invalid>:
>> I don't intend to fan the fire of atheism vs. faith.
> Liar.
To "fan the fire" means keep it going.
But never mind, I know hypocrites and truth don't mix. Any excuse for
slander is good enough for them.
<plonk>
------------------------------
Date: Tue, 04 Mar 2014 18:10:26 -0800
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: use strict; use warnings;
Message-Id: <lf69ui$p68$1@dont-email.me>
On 03/03/14 16:27, Ben Morrow wrote:
>
> Quoth Trifle Menot <triflemenot@protocol.invalid>:
>>
>> That means programmers write a lot of sloppy programs. It also means
>> humans should leave DNA to God.
>
> I've got a Dr Dawkins for you on line 3...
I didn't know that his calls were still getting put through.
Xho
------------------------------
Date: Tue, 04 Mar 2014 21:08:52 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: use strict; use warnings;
Message-Id: <i8cdh9dp0qkno4rlst23sfqar2dd67qlhk@4ax.com>
Trifle Menot <triflemenot@protocol.invalid> wrote:
>True, but without respect for eternal authority, people often fail at
>humility.
Apparently you have never experienced Buddhism.
jue
------------------------------
Date: Tue, 04 Mar 2014 16:58:45 -0800
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: using real objects in constructors
Message-Id: <040320141658450958%jimsgibson@gmail.com>
In article <87r46h991n.fsf@sable.mobileactivedefense.com>, Rainer
Weikusat <rweikusat@mobileactivedefense.com> wrote:
> The usual way to construct an instance of a Perl class (I'm aware of)
> would look somewhat like this:
>
> sub new
> {
> my ($class, $arg) = @_;
> my $self;
>
> $self->[0] = $arg;
> return bless($self, $class);
> }
>
> Fairly recently, it occured to me that this can also be accomplished
> with
>
> sub new
> {
> my ($class, $arg) = @_;
> my @self;
>
> $self[0] = $arg;
> return bless(\@self, $class);
> }
>
> Are there any good (or not-so-good) reasons to prefer one over the
> other?
Couldn't you also do this, then:
sub new
{
my ($class, $arg) = @_;
return bless([$arg], $class);
}
--
Jim Gibson
------------------------------
Date: Wed, 5 Mar 2014 04:48:41 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: using real objects in constructors
Message-Id: <lf6ab9$5ab$1@reader1.panix.com>
In article <040320141658450958%jimsgibson@gmail.com>,
Jim Gibson <jimsgibson@gmail.com> wrote:
>In article <87r46h991n.fsf@sable.mobileactivedefense.com>, Rainer
>Weikusat <rweikusat@mobileactivedefense.com> wrote:
>
>> The usual way to construct an instance of a Perl class (I'm aware of)
>> would look somewhat like this:
>>
>> sub new
>> {
>> my ($class, $arg) = @_;
>> my $self;
>>
>> $self->[0] = $arg;
>> return bless($self, $class);
>> }
>>
>> Fairly recently, it occured to me that this can also be accomplished
>> with
>>
>> sub new
>> {
>> my ($class, $arg) = @_;
>> my @self;
>>
>> $self[0] = $arg;
>> return bless(\@self, $class);
>> }
>>
>> Are there any good (or not-so-good) reasons to prefer one over the
>> other?
>
>Couldn't you also do this, then:
>
>sub new
>{
> my ($class, $arg) = @_;
> return bless([$arg], $class);
>}
so
sub new{bless [$_[1]],$_[0]}
?
(My first thought was "sub new{bless [pop],pop}", but that only
works if there are exactly two arguments.)
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 5 Mar 2014 05:10:40 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: using real objects in constructors
Message-Id: <g7oiua-4v32.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <040320141658450958%jimsgibson@gmail.com>,
> Jim Gibson <jimsgibson@gmail.com> wrote:
> >
> >Couldn't you also do this, then:
> >
> >sub new
> >{
> > my ($class, $arg) = @_;
> > return bless([$arg], $class);
> >}
>
> so
>
> sub new{bless [$_[1]],$_[0]}
The nearest thing to a 'standard' Perl constructor would be
sub new { bless $_[1], $_[0] }
It takes a hashref of attributes and turns it into an object.
Ben
>
> ?
>
> (My first thought was "sub new{bless [pop],pop}", but that only
> works if there are exactly two arguments.)
>
>
> --
> Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 5 Mar 2014 05:57:47 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: using real objects in constructors
Message-Id: <lf6ecr$gs6$1@reader1.panix.com>
In article <g7oiua-4v32.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth tmcd@panix.com:
>> In article <040320141658450958%jimsgibson@gmail.com>,
>> Jim Gibson <jimsgibson@gmail.com> wrote:
>> >
>> >Couldn't you also do this, then:
>> >
>> >sub new
>> >{
>> > my ($class, $arg) = @_;
>> > return bless([$arg], $class);
>> >}
>>
>> so
>> sub new{bless [$_[1]],$_[0]}
>> ?
>
>The nearest thing to a 'standard' Perl constructor would be
> sub new { bless $_[1], $_[0] }
>It takes a hashref of attributes and turns it into an object.
But
sub new{bless@_[1,0]}
saves 9 precious characters.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 05 Mar 2014 06:59:04 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: using real objects in constructors
Message-Id: <0eWdnYWGfKvYVovOnZ2dnUVZ8hWdnZ2d@giganews.com>
On 04/03/14 17:18, Rainer Weikusat wrote:
> it occured to me that this can also be accomplished
I'm very confused, watching my betters arguing over what (to me) looks
like the hairstyles of the angels on the head of the pin.
What's the matter with the "usual way" which Rainer starts with? If
it's the usual way, then surely out of deference to whoever is to
maintain your code, it's the way you should do it?
--
Henry Law Manchester, England
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 4163
***************************************
