[9715] in Perl-Users-Digest
Resend: Perl-Users Digest, Issue: 3306 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Aug 1 21:48:06 1998
Date: Sat, 1 Aug 98 18:39:05 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 1 Aug 1998 Volume: 8 Number: 3306
Today's topics:
What's the future of Perl? <qcoldiro@deal.unl.edu>
Re: What's the future of Perl? <quednauf@nortel.co.uk>
Re: What's the future of Perl? <jdporter@min.net>
Re: What's the future of Perl? <jdporter@min.net>
Re: What's the future of Perl? <jhi@alpha.hut.fi>
Re: What's the future of Perl? (M.J.T. Guy)
Re: What's the future of Perl? <dgris@rand.dimensional.com>
Re: What's the future of Perl? (Ilya Zakharevich)
Re: What's the future of Perl? (Matt Knecht)
Re: What's the future of Perl? (Michael J Gebis)
Re: What's the future of Perl? (Andrew M. Langmead)
Re: What's the future of Perl? <jdporter@min.net>
Re: What's the future of Perl? (Ilya Zakharevich)
Re: What's the future of Perl? (Ilya Zakharevich)
Re: What's the future of Perl? (Michael J Gebis)
Re: What's the future of Perl? (Ronald J Kimball)
Re: What's the future of Perl? (M.J.T. Guy)
Re: when/where perl.exe (5.005) for Win32? (Brian Jepson)
Re: when/where perl.exe (5.005) for Win32? <snif.nospamplease@xs4all.nl>
Re: Year 2000 (Abigail)
Re: Year 2000 <johnc@interactive.ibm.com>
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 30 Jul 1998 08:48:46 -0500
From: quinn coldiron <qcoldiro@deal.unl.edu>
Subject: What's the future of Perl?
Message-Id: <35C079BE.57EAF62D@deal.unl.edu>
I have heard some various things about the future versions of Perl. The
one rumor I heard that excites me the most is that the next release will
have a compiler, so we can make compiled code if we want, or keep
running our code as an interpreted script. Is this true? Another thing
I have wondered is will Perl every get a Case or Switch statement?
quinn
--
------------------------------------------
Quinn P. Coldiron
DEAL Lab
03 AG Comm
472-5249
qcoldiro@unlinfo.unl.edu
******* http://citv.unl.edu/linux/ *******
------------------------------------------
------------------------------
Date: Thu, 30 Jul 1998 15:07:41 +0100
From: "F.Quednau" <quednauf@nortel.co.uk>
Subject: Re: What's the future of Perl?
Message-Id: <35C07E2D.4B62F8FD@nortel.co.uk>
quinn coldiron wrote:
>
> I have heard some various things about the future versions of Perl. The
> one rumor I heard that excites me the most is that the next release will
> have a compiler, so we can make compiled code if we want, or keep
> running our code as an interpreted script. Is this true? Another thing
> I have wondered is will Perl every get a Case or Switch statement?
>
> quinn
>
There is a message further up from Gurusamy Sarathy, 5.005 released
(with maintenance update 01), it explains what is new in perl 5.005. And
yes, there seems to be a compiler for it now. But I don't know
everything about perl 5.004 yet, so I'll wait (For all the bugs to get
sorted as well:)[Crap attitude, or what?]
> I have wondered is will Perl every get a Case or Switch statement?
For what? Check the thread 'Reacting to 1 of 10 or so possible
values.... Need some streamlining help.' There are s...loads of
different ways to make switchy stuff.
On a personal note I see the future of Perl in the stars. When you sit
in a ship and you are lost in Space, then you will be happy that your
Comp runs Perl 15.0066, that can do super fast regexpes on the star
cartography database, spitting out the results that you are infinitely
far away from home in just a few minutes :)
--
____________________________________________________________
Frank Quednau
http://www.surrey.ac.uk/~me51fq
________________________________________________
------------------------------
Date: Fri, 31 Jul 1998 14:36:05 GMT
From: John Porter <jdporter@min.net>
Subject: Re: What's the future of Perl?
Message-Id: <35C1D6F0.3E@min.net>
[Someone who thinks he's as cool as Prince] wrote:
>
> the theory goes that a compiled binary has a much faster
> "execution" (or is that "initilization"?) because it doesn't have to
> be parsed through an interpretor (which also has to execute).
I think you've got your terms a little confused.
The parsing is done by the compiler; the interpreter is what
executes the bytecodes. So by using the perl compiler, you
save on compiling at run-time, because that has already been done.
So initialization is faster; but execution is about the same.
--
John Porter
------------------------------
Date: Fri, 31 Jul 1998 14:42:44 GMT
From: John Porter <jdporter@min.net>
Subject: Re: What's the future of Perl?
Message-Id: <35C1D87F.6494@min.net>
Jon Hamilton wrote:
>
> We may spell it "for", but we had better work in the letters in
> "anchor" in there as well:
Hmm.
% cd /usr/local/lib/perl5/pod
% grep forach *.pod
%
Looks like 'forach' is not a perl keyword.
:-)
--
John Porter
------------------------------
Date: 31 Jul 1998 18:08:04 +0300
From: Jarkko Hietaniemi <jhi@alpha.hut.fi>
Subject: Re: What's the future of Perl?
Message-Id: <oeeogu63vor.fsf@alpha.hut.fi>
mjtg@cus.cam.ac.uk (M.J.T. Guy) writes:
> >Changing the if to /^boo$/ of course does what was probably intended.
>
> And of course, whenever we see an anchored constant regular expression
> like that, we immediately think "Regexes aren't the best solution to
> all problems. That's why Perl has an `eq' operator."
>
> if ($_ eq 'boo') { ... }
>
> But presumably Tom was just using /boo/ as a place holder for something
> much more complex.
And of course we know that
/^boo$/
and
$_ eq 'boo'
ENOEQUIVALENT.
--
$jhi++; # http://www.iki.fi/~jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
------------------------------
Date: 31 Jul 1998 23:31:38 GMT
From: mjtg@cus.cam.ac.uk (M.J.T. Guy)
Subject: Re: What's the future of Perl?
Message-Id: <6ptk4q$j3a$1@pegasus.csx.cam.ac.uk>
Matt Knecht <hex@voicenet.com> wrote:
>Ilya Zakharevich <ilya@math.ohio-state.edu> wrote:
>>[A complimentary Cc of this posting was sent to Jarkko Hietaniemi
>><jhi@alpha.hut.fi>],
>>who wrote in article <oeeogu63vor.fsf@alpha.hut.fi>:
>>> And of course we know that
>>>
>>> /^boo$/
>>>
>>> and
>>> $_ eq 'boo'
>>>
>>> ENOEQUIVALENT.
>>
>>Just for the rest of us: Jarkko is implying that these guys are not
>>equivalent. True, but very subtle.
>
>Which begs the question "Why aren't they equivalent?".
Think trailing newline.
Mike Guy
------------------------------
Date: Fri, 31 Jul 1998 23:57:14 GMT
From: Daniel Grisinger <dgris@rand.dimensional.com>
Subject: Re: What's the future of Perl?
Message-Id: <6ptkup$299$1@rand.dimensional.com>
[posted to comp.lang.perl.misc and mailed to the cited author]
In article <C%qw1.487$NJ5.2870710@news2.voicenet.com>
hex@voicenet.com (Matt Knecht) wrote:
[snip assertion that $_ eq 'boo' and /^boo$/ are not equivalent]
>Which begs the question "Why aren't they equivalent?".
$_ = "boo\n"; # :-)
dgris
--
Daniel Grisinger dgris@perrin.dimensional.com
"No kings, no presidents, just a rough consensus and
running code."
Dave Clark
------------------------------
Date: 31 Jul 1998 23:38:42 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: What's the future of Perl?
Message-Id: <6ptki2$ije$1@mathserv.mps.ohio-state.edu>
[A complimentary Cc of this posting was sent to M.J.T. Guy
<mjtg@cus.cam.ac.uk>],
who wrote in article <6ptk4q$j3a$1@pegasus.csx.cam.ac.uk>:
> >>> $_ eq 'boo'
> >>>
> >>> ENOEQUIVALENT.
> >>
> >>Just for the rest of us: Jarkko is implying that these guys are not
> >>equivalent. True, but very subtle.
> >
> >Which begs the question "Why aren't they equivalent?".
>
> Think trailing newline.
Hmm, really! I was thinking of $*. ;-)
Ilya
------------------------------
Date: Fri, 31 Jul 1998 21:51:30 GMT
From: hex@voicenet.com (Matt Knecht)
Subject: Re: What's the future of Perl?
Message-Id: <C%qw1.487$NJ5.2870710@news2.voicenet.com>
Ilya Zakharevich <ilya@math.ohio-state.edu> wrote:
>[A complimentary Cc of this posting was sent to Jarkko Hietaniemi
><jhi@alpha.hut.fi>],
>who wrote in article <oeeogu63vor.fsf@alpha.hut.fi>:
>> And of course we know that
>>
>> /^boo$/
>>
>> and
>> $_ eq 'boo'
>>
>> ENOEQUIVALENT.
>
>Just for the rest of us: Jarkko is implying that these guys are not
>equivalent. True, but very subtle.
Which begs the question "Why aren't they equivalent?".
--
Matt Knecht - <hex@voicenet.com>
------------------------------
Date: 31 Jul 1998 17:39:28 GMT
From: gebis@fee.ecn.purdue.edu (Michael J Gebis)
Subject: Re: What's the future of Perl?
Message-Id: <6psvgg$3vs@mozo.cc.purdue.edu>
John Porter <jdporter@min.net> writes:
}[Someone who thinks he's as cool as Prince] wrote:
}> the theory goes that a compiled binary has a much faster
}> "execution" (or is that "initilization"?) because it doesn't have to
}> be parsed through an interpretor (which also has to execute).
}I think you've got your terms a little confused.
}The parsing is done by the compiler; the interpreter is what
}executes the bytecodes. So by using the perl compiler, you
}save on compiling at run-time, because that has already been done.
}So initialization is faster; but execution is about the same.
Here's one:
In theory, there are optimizations that can be applied during
compilation that are not done now, because they would produce an
unacceptable runtime overhead. In theory, once compilation is no
longer a runtime task, there's little penalty for spending a few extra
seconds doing the optimization, and the code produced can indeed be
better.
--
Mike Gebis gebis@ecn.purdue.edu mgebis@eternal.net
------------------------------
Date: Fri, 31 Jul 1998 18:11:09 GMT
From: aml@world.std.com (Andrew M. Langmead)
Subject: Re: What's the future of Perl?
Message-Id: <Ewz16M.GLn@world.std.com>
root.noharvest.\@not_even\here.com (-) writes:
>Well... the theory goes that a compiled binary has a much faster
>"execution" (or is that "initilization"?) because it doesn't have to
>be parsed through an interpretor (which also has to execute).
Since so much of perl is determined at runtime, there is little that
can be done for "faster execution". The best you could hope for is
"faster initialization" Basically, if you time the execution of "perl
-c filename", you can find out how much time perl spends compiling
your script before executing it. You can hope for a decrease in some
of that time.
There is also some potential for an increase in the amount of memory
shared between multiple simultaneous invocations of the same
script. When a script is turned into its intermediate form by the perl
interpreter, it is placed in the unitialized memory area for that
process. If the script is turned into this form _once_ by the
compiler module, then the syntax tree is in the initialized data
segment of the executable file. This initialized data can be shared
between multiple simultaneous invocations of the same program. (To me,
this sounds like it may be a help for many CGI scripts.)
But then you have to weigh in other factors. If you build perl to use
a shared library for the interpreter, you then get more memory shared
between simultaneous invocations of different perl programs.
Unfortunately, as a downside, the time to start a script may increase
due to the executable's initialization, in which it has to do the
symbol fixups. (So I guess my first comment is still true. "perl -c
filename" will still be longer than the initialization time of the
compiled script, but _both_ may be increased if there is a shared perl
library.)
I have no evidence of this, but there may be some optimization
benefits that eventually come out of the compiler. For example, the
perl interpreter tries to determine if small blocks can be optimized
away. This can make if statements about as efficient as if modifiers.
print "something" if $conditional;
if($conditional) {
print "something";
}
produce about the same code. (As seen with the -D14 flag of a perl
compiled with DEBUGGING support.) On the other hand:
if($conditional) {
print "some";
print "thing";
print "\n";
}
has more than just the extra print statements, it also has "enter" and
"leave" opcodes because the perl interpreter has given up on trying to
decide whether the contents of the if statement need a block for
scoping or not.
The compiler theoretically has more time to examine the code, so may
be able to optimize more aggressively.
--
Andrew Langmead
------------------------------
Date: Fri, 31 Jul 1998 18:40:05 GMT
From: John Porter <jdporter@min.net>
Subject: Re: What's the future of Perl?
Message-Id: <35C2101E.42E2@min.net>
Michael J Gebis wrote:
>
> John Porter <jdporter@min.net> writes:
> }So initialization is faster; but execution is about the same.
>
> In theory, there are optimizations that can be applied during
> compilation that are not done now, because they would produce an
> unacceptable runtime overhead. In theory, once compilation is no
> longer a runtime task, there's little penalty for spending a few extra
> seconds doing the optimization, and the code produced can indeed be
> better.
Yes; but a speed-up of <5% is "about the same" in my book.
Not to mention the fact that other factors might overwhelm
those optimizations, such as eval'ing expressions which aren't
known until run-time.
--
John Porter
------------------------------
Date: 31 Jul 1998 20:31:17 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: What's the future of Perl?
Message-Id: <6pt9il$q0h$1@mathserv.mps.ohio-state.edu>
[A complimentary Cc of this posting was sent to Jarkko Hietaniemi
<jhi@alpha.hut.fi>],
who wrote in article <oeeogu63vor.fsf@alpha.hut.fi>:
> And of course we know that
>
> /^boo$/
>
> and
> $_ eq 'boo'
>
> ENOEQUIVALENT.
Just for the rest of us: Jarkko is implying that these guys are not
equivalent. True, but very subtle.
Ilya
------------------------------
Date: 31 Jul 1998 20:29:10 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: What's the future of Perl?
Message-Id: <6pt9em$pmj$1@mathserv.mps.ohio-state.edu>
[A complimentary Cc of this posting was sent to Andrew M. Langmead
<aml@world.std.com>],
who wrote in article <Ewz16M.GLn@world.std.com>:
> There is also some potential for an increase in the amount of memory
> shared between multiple simultaneous invocations of the same
> script. When a script is turned into its intermediate form by the perl
> interpreter, it is placed in the unitialized memory area for that
> process. If the script is turned into this form _once_ by the
> compiler module, then the syntax tree is in the initialized data
> segment of the executable file. This initialized data can be shared
> between multiple simultaneous invocations of the same program. (To me,
> this sounds like it may be a help for many CGI scripts.)
No. The memory image of the script is constructed during runtime, not
during compile time. I have no idea why, but maybe C compilers are
not able to construct a typical graph with 100K nodes in read-only
memory. Hmm, or is it the program loader who would construct it?
typedef struct foo {
struct foo *other;
} foo;
extern foo foo1;
extern foo foo2;
foo foo1 = { &foo2 };
foo foo2 = { &foo1 };
main()
{
printf("&foo1=%#x, &foo2=%#x,\n foo2=%#x, foo1=%#x.\n",
&foo1, &foo2, foo2.other, foo1.other);
exit(0);
}
compiles OK with gcc...
> But then you have to weigh in other factors. If you build perl to use
> a shared library for the interpreter, you then get more memory shared
> between simultaneous invocations of different perl programs.
Executables are shared too, thus this argument is void.
Ilya
------------------------------
Date: 31 Jul 1998 21:56:10 GMT
From: gebis@fee.ecn.purdue.edu (Michael J Gebis)
Subject: Re: What's the future of Perl?
Message-Id: <6ptehq$a0v@mozo.cc.purdue.edu>
John Porter <jdporter@min.net> writes:
}Michael J Gebis wrote:
}> John Porter <jdporter@min.net> writes:
}> }So initialization is faster; but execution is about the same.
}>
}> In theory, there are optimizations that can be applied during
}> compilation that are not done now, because they would produce an
}> unacceptable runtime overhead. In theory, once compilation is no
}> longer a runtime task, there's little penalty for spending a few extra
}> seconds doing the optimization, and the code produced can indeed be
}> better.
}Yes; but a speed-up of <5% is "about the same" in my book.
}Not to mention the fact that other factors might overwhelm
}those optimizations, such as eval'ing expressions which aren't
}known until run-time.
It is true that currently the speedup is "about the same" but
compilation opens up a whole new world of possibilties. There are
lots of potential optimization algorithms which could have big wins
which have not been attempted because of the run-time of these
algorithms. And things like profiling-feedback were pretty much
impossible without a compiler.
I am talking in vague hypothetical terms here, of course. Those
interested in the 5.005 compiler probably will see little immediate
gain.
--
Mike Gebis gebis@ecn.purdue.edu mgebis@eternal.net
------------------------------
Date: Fri, 31 Jul 1998 20:01:24 -0400
From: rjk@coos.dartmouth.edu (Ronald J Kimball)
Subject: Re: What's the future of Perl?
Message-Id: <1dd1raf.qaw1onmxg583N@bay1-301.quincy.ziplink.net>
Matt Knecht <hex@voicenet.com> wrote:
> >> /^boo$/
> >>
> >> and
> >> $_ eq 'boo'
> >>
> >> ENOEQUIVALENT.
> >
> >Just for the rest of us: Jarkko is implying that these guys are not
> >equivalent. True, but very subtle.
>
> Which begs the question "Why aren't they equivalent?".
[Aside: No it doesn't, it *raises the question*. Begging the question
is a term in logic referring to the fallacy of circular reasoning. :-) ]
/^boo$/ allows for a trailing newline; $_ eq 'boo' does not.
$_ = "boo\n";
print /^boo$/ ? "Regex matches\n" : "\n";
print $_ eq 'boo' ? "Equals string\n" : "\n";
--
_ / ' _ / - aka - rjk@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: 1 Aug 1998 12:08:29 GMT
From: mjtg@cus.cam.ac.uk (M.J.T. Guy)
Subject: Re: What's the future of Perl?
Message-Id: <6pv0ft$351$1@pegasus.csx.cam.ac.uk>
Ilya Zakharevich <ilya@math.ohio-state.edu> wrote:
>[A complimentary Cc of this posting was sent to M.J.T. Guy
><mjtg@cus.cam.ac.uk>],
>who wrote in article <6ptk4q$j3a$1@pegasus.csx.cam.ac.uk>:
>>
>> Think trailing newline.
>
>Hmm, really! I was thinking of $*. ;-)
I always thought you had a warped mind. :-)
Mike Guy
------------------------------
Date: 30 Jul 1998 13:55:09 GMT
From: bjepson@ids.net (Brian Jepson)
Subject: Re: when/where perl.exe (5.005) for Win32?
Message-Id: <slrn6s0ur6.dk.bjepson@gelvis.ids.net>
On Thu, 30 Jul 1998 14:33:30 +0200, Jonkers <snif@xs4all.nonono.nl> wrote:
>When/where is the Win32-executable perl.exe of Perl 5.005 available? The
>site http://www.perl.com/pace/pub/perldocs/latest.html still says
>"The current version is perl5.00402-bindist04-bc.zip (or .tar.gz if you
>prefer)." and the contents of the ftp-directory seems to confirm this.
>
>Or is the binary distribution somewhere else available?
>
The ActivePerl distribution at http://www.ActiveState.com is based on
5.005.
Hope this helps,
--
Brian Jepson * (bjepson@ids.net) * http://users.ids.net/~bjepson
Choosy mothers choose to chew Chew-Z
------------------------------
Date: Thu, 30 Jul 1998 19:26:39 +0200
From: "Jonkers" <snif.nospamplease@xs4all.nl>
Subject: Re: when/where perl.exe (5.005) for Win32?
Message-Id: <6pqabv$hh4$1@news2.xs4all.nl>
David B. White wrote in message <6pq834$rnu$1@mdnews.btv.ibm.com>...
>In article <6ppp5h$7h8$1@news.gns.getronics.nl>,
> "Jonkers" <snif@xs4all.nonono.nl> writes:
>> When/where is the Win32-executable perl.exe of Perl 5.005 available? The
>
>Sander,
>When I looked on 7/30/98,
>http://www.perl.com/CPAN-local/ports/win32/Standard/x86/
>appeared to have perl5.005 tar.gz files (original, plus two patch levels).
True, but those are the source files, not the compiled, ready-to-run Win32
perl.exe executable. I expect I can't compile it myself (I haven't got a
compiler, for example).
Sander
------------------------------
Date: 30 Jul 1998 16:44:26 GMT
From: abigail@fnx.com (Abigail)
Subject: Re: Year 2000
Message-Id: <6pq7ta$p1l$1@client3.news.psi.net>
joe (jsteorts@csc.com) wrote on MDCCXCIII September MCMXCIII in
<URL: news:01bdbb23$e65324e0$d445e1c0@C-105813.gsfc.nasa.gov>:
++ I was wondering about Perl and the Year 2000.
++
Is there something wrong with your eyes?
Perhaps you consider English a write only language?
Is it that difficult to read the FAQ?
Abigail
--
perl -wle '$, = " "; sub AUTOLOAD {($AUTOLOAD =~ /::(.*)/) [0];}
print+Just (), another (), Perl (), Hacker ();'
------------------------------
Date: Thu, 30 Jul 1998 14:39:08 +0000
From: John Call <johnc@interactive.ibm.com>
Subject: Re: Year 2000
Message-Id: <35C08578.2B77079B@interactive.ibm.com>
Abigail wrote:
> Is there something wrong with your eyes?
> Perhaps you consider English a write only language?
>
> Is it that difficult to read the FAQ?
>
> Abigail
> --
> perl -wle '$, = " "; sub AUTOLOAD {($AUTOLOAD =~ /::(.*)/) [0];}
> print+Just (), another (), Perl (), Hacker ();'
I thought once the "Perl Studs" got their .moderated group that any
advice they gave here would be a little less venomous. I guess not. You
got the new group. Go be rude in there. If you give advice here then
take the Tom P.'s approach please.
John Call
------------------------------
Date: 12 Jul 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Mar 98)
Message-Id: <null>
Administrivia:
Special notice: in a few days, the new group comp.lang.perl.moderated
should be formed. I would rather not support two different groups, and I
know of no other plans to create a digested moderated group. This leaves
me with two options: 1) keep on with this group 2) change to the
moderated one.
If you have opinions on this, send them to
perl-users-request@ruby.oce.orst.edu.
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.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 3306
**************************************
