[33137] in Perl-Users-Digest
Perl-Users Digest, Issue: 4415 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Apr 16 03:09:21 2015
Date: Thu, 16 Apr 2015 00:09:04 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 16 Apr 2015 Volume: 11 Number: 4415
Today's topics:
Re: "Deep Recursion" warning on factorial script. <lionslair@consolidated.net>
Re: "Deep Recursion" warning on factorial script. <news@todbe.com>
Re: -d test recognizes Windows 8.1 SYMLINKD as being di <see.my.sig@for.my.address>
Fast Factorial Script: 10000! in 1.5sec. <see.my.sig@for.my.address>
Re: Fast Factorial Script: 10000! in 1.5sec. <netnews@invalid.com>
Re: Fast Factorial Script: 10000! in 1.5sec. <kaz@kylheku.com>
Re: Fast Factorial Script: 10000! in 1.5sec. <gamo@telecable.es>
Re: Fast Factorial Script: 10000! in 1.5sec. <rweikusat@mobileactivedefense.com>
Re: Fun With Unicode <kaz@kylheku.com>
Re: Fun With Unicode <see.my.sig@for.my.address>
Re: Mentifex Strong AI Perlmind Programming Journal: 20 <kaz@kylheku.com>
Re: Regex replace line breaks (Seymour J.)
Re: Regex replace line breaks (Seymour J.)
Re: Regex replace line breaks (Seymour J.)
Re: Regex replace line breaks <news@todbe.com>
Re: Regex replace line breaks <lionslair@consolidated.net>
Re: Regex replace line breaks <news@todbe.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 14 Apr 2015 22:43:19 -0500
From: Martin Eastburn <lionslair@consolidated.net>
Subject: Re: "Deep Recursion" warning on factorial script.
Message-Id: <v7lXw.248294$sB1.58133@fx22.iad>
Those - Univac Mil are likely defined in a word able to do that.
But some machines have 1, 2, and 3 addresses per instruction.
And some of the big monster machines are IBM Military -
Division now closed but the machines are still running.
They were 64 bit and 128 bit parallel processors. Two 64 bit fed the
128. They were the first high speed parallel processors but were secret
from telling how and what they were used for. So IBM had to bite
tongues as other companies announced theirs some years later.
So design says what the assembler can and cannot do. The size of the
op-code and if the single word was the entire code or not.
A location can store 3 and 2 instructions or a single one in the same
space. The 3 address op-code may be a dummy after the initial run or
another condition. From then on it runs a different flow.
Martin
On 4/13/2015 11:33 PM, $Bill wrote:
> On 4/13/2015 21:26, Martin Eastburn wrote:
>> John the code that changes itself and uses the address space of the
>> various call and jumps can not be done in assembly. Only Machine can
>> do it as it is hardwired to specific memory and does specific op-codes.
>
> That depends entirely on the assembler. A good, flexible assembler can
> duplicate
> anything you can write without one and has the advantage of being readable.
>
> My first language was IBM 360 BAL (ignoring Gotran and Fortran in college).
>
> I worked with some Univac military computers whose assembly language
> could pretty
> much replicate anything in machine code.
------------------------------
Date: Wed, 15 Apr 2015 07:36:31 -0700
From: "$Bill" <news@todbe.com>
Subject: Re: "Deep Recursion" warning on factorial script.
Message-Id: <mglt00$ojc$1@dont-email.me>
On 4/14/2015 20:43, Martin Eastburn wrote:
> Those - Univac Mil are likely defined in a word able to do that.
>
> But some machines have 1, 2, and 3 addresses per instruction.
>
> And some of the big monster machines are IBM Military -
> Division now closed but the machines are still running.
> They were 64 bit and 128 bit parallel processors. Two 64 bit fed the 128. They were the first high speed parallel processors but were secret
> from telling how and what they were used for. So IBM had to bite tongues as other companies announced theirs some years later.
>
> So design says what the assembler can and cannot do. The size of the op-code and if the single word was the entire code or not.
>
> A location can store 3 and 2 instructions or a single one in the same space. The 3 address op-code may be a dummy after the initial run or
> another condition. From then on it runs a different flow.
I worked a lot on 16 and 18 bit computers that had 64KW of memory - we did in
64KW what people today use 500MB for. I worked on a telemetry system display
computer that had like 120 display overlays that ran in 4K of memory. :)
For research and development, I ported the software from Modcomp Classic midi-computers
to an LSI-11 Micro and then to an IBM PC with a 10 MB disc drive.
------------------------------
Date: Tue, 14 Apr 2015 14:02:26 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: -d test recognizes Windows 8.1 SYMLINKD as being directory???
Message-Id: <g7SdnSjnz_v-HbDInZ2dnUVZ572dnZ2d@giganews.com>
On 4/14/2015 9:34 AM, Rainer Weikusat wrote:
> ... [symlinks treated as being directories is] consistent with the
> behaviour on Linux (and very likely elsewhere),
>
> [rw@doppelsaurus]/tmp#mkdir dir
> [rw@doppelsaurus]/tmp#ln -s dir alias
> [rw@doppelsaurus]/tmp#perl -e 'print -d("alias"), "\n";'
> 1
>
> and also what's usually wanted because the whole point of having a
> symlink is that the 2nd name can be used instead of the first. Because
> of this, Perl defaults to using stat to determine the information for
> the filetest operators.
Hmmm. Yes, that makes sense.
> It's possible to use lstat (=> stat(2),lstat(2)) instead calling it
> explicitly and then use the -X with _ as argument,
>
> [rw@doppelsaurus]/tmp#perl -e 'lstat("alias"); print -d(_), "\n";'
>
> ^^^^
> As can be seen, nothing can be seen here
>
> or use the lstat return values directly.
Fascinating. Thanks for the information; that give me a way to
distinguish between symlinks and actual directories.
However, I'm not so much interested in avoiding symlinks
altogether as in avoiding loops and cross-coupling in the
recursive tree. Loops cause endless recursion,
and cross-coupling causes reprocessing of directories.
My current "no inode reusage" test does prevent both, in that it
rejects anything claiming to be a "directory" which has an inode
which has been seen before during the current program instance
(implemented by pushing each accepted directory's inode onto
a package-global array @inodes).
However, perhaps rejecting symlinks altogether would be better.
That would also reject branching out of a small branch of "/"
and into some other (perhaps much larger) branch of "/",
which might eat much more time and resources.
Ah, I know, I'll reject symlinks in RecurseDirs(), and make
a second version called RecurseDirsAndLinks() that follows links.
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
------------------------------
Date: Tue, 14 Apr 2015 17:05:17 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Fast Factorial Script: 10000! in 1.5sec.
Message-Id: <C5udnTuSAsegNrDInZ2dnUVZ572dnZ2d@giganews.com>
Speed race: my script computes 10000! in 1.5sec. (No recursion
this time.) Can you make a script that's faster? :-)
Actually, I wrote 2 versions. The first version is
unlimited-precision; it prints every digit of 10000!
in about 2.0 seconds:
#! /usr/bin/perl
# /rhe/scripts/math/factorial
use v5.14;
use strict;
use warnings;
use Math::BigInt;
my $x = $ARGV[0];
my $f = Math::BigInt->bfac($x);
say "$x! = $f";
exit 0;
But the number it prints for 10000! is too big to even look at,
much less comprehend, because it's over 35000 digits. So I wrote
a low-precision version, which only takes about 1.5sec to compute
10000!:
#! /usr/bin/perl
# /rhe/scripts/math/lpfactorial
use v5.14;
use strict;
use warnings;
use Math::BigInt;
my $x = $ARGV[0];
my $f = Math::BigInt->bfac($x);
$f->bround(5);
my $s = $f->bsstr();
say "$x! = $s";
exit 0;
I wonder how BigInt's "bfac()" achieves such speed?
I tried iterative multiplication ($f *= $_ for 1..$x)
but it was much slower, about 5.0sec instead of 1.5sec,
so obviously bfac() is doing something different.
And, in case you're wondering,
10000! = about 2.8463E35659
Vastly larger than a googol (1E100).
But vastly smaller than a googolplex
(1E100000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000).
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
------------------------------
Date: Tue, 14 Apr 2015 17:48:34 -0700
From: HASM <netnews@invalid.com>
Subject: Re: Fast Factorial Script: 10000! in 1.5sec.
Message-Id: <874moi9py5.fsf@127.0.0.1>
Robbie Hatley <see.my.sig@for.my.address> writes:
> I wonder how BigInt's "bfac()" achieves such speed?
gamma function?
-- HASM
------------------------------
Date: Wed, 15 Apr 2015 01:51:50 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: Fast Factorial Script: 10000! in 1.5sec.
Message-Id: <20150414181159.790@kylheku.com>
On 2015-04-15, Robbie Hatley <see.my.sig@for.my.address> wrote:
>
> Speed race: my script computes 10000! in 1.5sec. (No recursion
> this time.) Can you make a script that's faster? :-)
TXR language (that I made):
Via built-in "n perm k" function (numbe of sequence sof k items chosen from a set of n),
not printing the results:
$ time ./txr -e '(n-perm-k 10000 10000)'
real 0m0.096s
user 0m0.072s
sys 0m0.020s
C code:
val n_perm_k(val n, val k)
{
return rising_product(plus(minus(n, k), one), n);
}
This rising_product, in turn, naively iterates through the numbers and
multiplies them together; nothing special. The code is in C, but it uses the
high level functions like plus, mul, which dispatch on the type in an
unoptimized, and call into the bignum library. The bignum library is Michael
Bromberger's MPI, with some hacks here and there by me.
Interpreted code using a naive for loop is quite a bit slower:
$ time ./txr -e '(for ((i 2) (acc 1)) ((<= i 10000)) ((set acc (* acc i)) (inc i)))'
real 0m0.152s
user 0m0.124s
sys 0m0.028s
This is 32 bit code, on this hardware:
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
stepping : 7
cpu MHz : 2862.094
cache size : 6144 KB
TXR Lisp is completely, utterly unoptimized; evaluation proceeds by
interpretation of the raw abstract syntax tree, represented as nested lists.
So far I haven't really put any effort into making it go fast.
Anything significantly slower has to go out of its way to achieve bad performance.
You can see that a lot of time is chewed up in the interpretation of the for
loop, when you compare a more functional approach. Instead of calling a built-in
function, we can write some functional code. This competes very well against
the C rising_product, in spite of the overheads of range producing a lazy list,
which is consumed inside reduce:
$ time ./txr -e '[reduce-left * (range 2 10000)]'
real 0m0.099s
user 0m0.072s
sys 0m0.024s
The conversion of binums to text is very inefficient, using a naive algorithm that
divides by 10 repeatedly and takes the remainder; the time jumps to 1.4 seconds.
A big improvement could be made there; there are much faser better ways to turn
bignums into base ten (and other radix) digits. It's a good idea to separate
this if you want to properly benchmark just the raw calculation:
$ time ./txr -p '[reduce-left * (range 2 10000)]' > /dev/null
real 0m1.403s
user 0m1.384s
sys 0m0.016s
As far as bignums go, I chose the MPI library for its simplicity and relatively
clean code (plus liberal license compatible with BSD). It's not a feature-rich
or fast library. The integer square root was quite bad; I rewrote it to make
it faster. The multiplication is basic; it doesn't even use Karatsuba or
anything.
For a faster factorial, we probably don't want to be doing this naive
multiplication. Basically, we don't want to be accumulating one huge number,
and multiplying it by the next tiny number in the sequence.
------------------------------
Date: Wed, 15 Apr 2015 06:31:15 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Fast Factorial Script: 10000! in 1.5sec.
Message-Id: <mgkpik$vql$1@speranza.aioe.org>
El 15/04/15 a las 02:05, Robbie Hatley escribió:
> Speed race: my script computes 10000! in 1.5sec. (No recursion
> this time.) Can you make a script that's faster? :-)
>
> Actually, I wrote 2 versions. The first version is
> unlimited-precision; it prints every digit of 10000!
> in about 2.0 seconds:
$ time perl test.gmp
(a very big number)
real 0m0.028s
user 0m0.024s
sys 0m0.004s
No recursive, off course.
--
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance
------------------------------
Date: Wed, 15 Apr 2015 10:53:01 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Fast Factorial Script: 10000! in 1.5sec.
Message-Id: <87egnl1zwi.fsf@doppelsaurus.mobileactivedefense.com>
Robbie Hatley <see.my.sig@for.my.address> writes:
> Speed race: my script computes 10000! in 1.5sec. (No recursion
> this time.) Can you make a script that's faster? :-)
[...]
> I wonder how BigInt's "bfac()" achieves such speed?
> I tried iterative multiplication ($f *= $_ for 1..$x)
http://blogten.blogspot.co.uk/2007/01/calculating-n.html?showComment=1169930940000#c1563328965910785064
The Calc.pm source code also provides an instructive example why
'comments' are a double-edged sword,
# Calculate (k-j) * (k-j+1) ... k .. (k+j-1) * (k + j)
# See http://blogten.blogspot.com/2007/01/calculating-n.html
# The above series can be expressed as factors:
# k * k - (j - i) * 2
http://cpansearch.perl.org/src/PJACKLAM/Math-BigInt-1.9993/lib/Math/BigInt/Calc.pm
As this should have been
k ** 2 - (j - i) ** 2
or
k * k - (j - i) * (j - i)
For some idiotic reason, I've also verified that this is actually
correct despite this is really painful for me because my mind tends to
produce seemingly random permutations of unfamiliar strings of symbols
aka 'dyslexics have rome fnu', even with math lectures, although this
tends to be fun of the more useless sort ...
------------------------------
Date: Tue, 14 Apr 2015 20:16:31 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: Fun With Unicode
Message-Id: <20150414130806.601@kylheku.com>
On 2015-04-13, Robbie Hatley <see.my.sig@for.my.address> wrote:
> research I discovered that the representation of the BOM
> inside Perl is *NOT* the same as the bytes in the file. A Unicode
Yes, you're dealing with a complete idiocy: a UTF-8 encoded BOM.
UTF-8 doesn't require a byte order marker, because it is specified down
to the bit level; there is no choice of byte order. The most significant
part of a code point is encoded in the earliest UTF-8 byte.
------------------------------
Date: Tue, 14 Apr 2015 17:06:14 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: Fun With Unicode
Message-Id: <C5udnTqSAsfrNrDInZ2dnUVZ570AAAAA@giganews.com>
On 4/14/2015 1:16 PM, Kaz Kylheku wrote:
> ... you're dealing with a complete idiocy: a UTF-8 encoded BOM.
> UTF-8 doesn't require a byte order marker, because it is specified down
> to the bit level; there is no choice of byte order. The most significant
> part of a code point is encoded in the earliest UTF-8 byte.
For some reason Bill Gates & Company thought they knew better,
so they made Notepad and other MS software add a BOM to the beginning
of every utf8-encoded text file. Go figure.
Perhaps they're using it as a marker saying "This is a Unicode file"?
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
------------------------------
Date: Tue, 14 Apr 2015 20:20:35 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: Mentifex Strong AI Perlmind Programming Journal: 2015 April 12
Message-Id: <20150414131732.683@kylheku.com>
On 2015-04-13, George Mpouras <gravitalsun@hotmail.foo> wrote:
> On 12/4/2015 8:48 μμ, mentificium@gmail.com wrote:
>> The Perlmind Programming Journal (PMPJ) is a record
>> from the very start of how the Mentifex Strong AI Mind
>> project moves beyond REXX and Forth and JavaScript into
>> the Perl programming environment.
>>
>> Mentifex
>
> I am interesting at AI.
> What you have done so far, do you have a working prototype ;
Arthur T. Murray is a *long* time Usenet troll.
http://www.nothingisreal.com/mentifex_faq.html
I'm quite surprised by this re-emergence; I have not seen a new instance
of this Mentifex bullshit in years in the newsgroups I visit.
------------------------------
Date: Tue, 14 Apr 2015 10:05:52 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Regex replace line breaks
Message-Id: <552d1ec0$19$fuzhry+tra$mr2ice@news.patriot.net>
In <slrnmihu97.m1i.hjp-usenet3@hrunkner.hjp.at>, on 04/11/2015
at 12:36 PM, "Peter J. Holzer" <hjp-usenet3@hjp.at> said:
>Or a future perl. Apparently, EBCDIC support is being fixed in the
>current development cycle and will probably be included in the next
>stable release again.
That's welcome news. Thansk.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 14 Apr 2015 10:03:48 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Regex replace line breaks
Message-Id: <552d1e44$18$fuzhry+tra$mr2ice@news.patriot.net>
In <20150410184231.603@kylheku.com>, on 04/11/2015
at 01:55 AM, Kaz Kylheku <kaz@kylheku.com> said:
>CR makes sense in that situation because it's idempotent.
As is NUL, and NUL never causes an extraneous mechanical motion (on
some terminals a CR would trigger the mechanics even if you were
already at the left margin.)
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 14 Apr 2015 09:58:55 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Regex replace line breaks
Message-Id: <552d1d1f$17$fuzhry+tra$mr2ice@news.patriot.net>
In <mg9id9$818$1@dont-email.me>, on 04/10/2015
at 03:22 PM, "$Bill" <news@todbe.com> said:
>TTY's were pretty much gone before UNIX arrived - I used to repair
>them and CR,CR,LF was quite common for Teletype Corp teletype
>machines
Why not CR NUL LF, or multiple NUL characters as needed?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 14 Apr 2015 18:56:15 -0700
From: "$Bill" <news@todbe.com>
Subject: Re: Regex replace line breaks
Message-Id: <mgkgef$24j$1@dont-email.me>
On 4/14/2015 06:58, Shmuel (Seymour J.) Metz wrote:
> In <mg9id9$818$1@dont-email.me>, on 04/10/2015
> at 03:22 PM, "$Bill" <news@todbe.com> said:
>
>> TTY's were pretty much gone before UNIX arrived - I used to repair
>> them and CR,CR,LF was quite common for Teletype Corp teletype
>> machines
>
> Why not CR NUL LF, or multiple NUL characters as needed?
Don't know how to type a null code in Baudot - other than just
pausing. But if you're using paper tape, there is no pausing.
Also, it's a lot easier to hit the same key twice than to find
another key on the keyboard. You could hit figures/letters
shift a couple of times, but CR is safer.
------------------------------
Date: Tue, 14 Apr 2015 22:30:00 -0500
From: Martin Eastburn <lionslair@consolidated.net>
Subject: Re: Regex replace line breaks
Message-Id: <1XkXw.326730$lw2.320977@fx14.iad>
Nul does Nothing. a CR does a return. If the first one
didn't function for a dirty rotators or metal arm the second one
would. Remember these are Mechanical beasts.
The common way to clean them after xxx hours - is take the inner
frame out of the case and put it into a dishwasher. Wash.
Take out and put into a drum of oil. Water floats. Skim water.
Take out and set on drain rack. Then remount in tray (that catches oil)
and hook up the electrical wire.....
Oil is messy, but keeps it running.
Martin former owner of a 5-level beauty and currently an 8 level Beauty.
My prime < 1000 hours I traded it to a friend who had a LSI-11 in a
chip. It had a 60 ma current loop port.
Martin
On 4/14/2015 8:58 AM, Shmuel (Seymour J.) Metz wrote:
> In <mg9id9$818$1@dont-email.me>, on 04/10/2015
> at 03:22 PM, "$Bill" <news@todbe.com> said:
>
>> TTY's were pretty much gone before UNIX arrived - I used to repair
>> them and CR,CR,LF was quite common for Teletype Corp teletype
>> machines
>
> Why not CR NUL LF, or multiple NUL characters as needed?
>
------------------------------
Date: Wed, 15 Apr 2015 07:28:15 -0700
From: "$Bill" <news@todbe.com>
Subject: Re: Regex replace line breaks
Message-Id: <mglsgg$mvo$1@dont-email.me>
On 4/14/2015 20:30, Martin Eastburn wrote:
> Nul does Nothing. a CR does a return. If the first one
> didn't function for a dirty rotators or metal arm the second one
> would. Remember these are Mechanical beasts.
>
> The common way to clean them after xxx hours - is take the inner
> frame out of the case and put it into a dishwasher. Wash.
> Take out and put into a drum of oil. Water floats. Skim water.
We had a vat with spray nozzles filled with Trichloroethylene that we doused
them in after stripping them down (big fan above to vent the fumes outside).
Then we would rebuild them and slick them up with lubricants in the process.
That was called Depot Level Maintenance. :)
> Take out and set on drain rack. Then remount in tray (that catches oil)
> and hook up the electrical wire.....
>
> Oil is messy, but keeps it running.
>
> Martin former owner of a 5-level beauty and currently an 8 level Beauty.
> My prime < 1000 hours I traded it to a friend who had a LSI-11 in a chip. It had a 60 ma current loop port.
------------------------------
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 4415
***************************************
