[31821] in Perl-Users-Digest
Perl-Users Digest, Issue: 3084 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Aug 18 14:09:22 2010
Date: Wed, 18 Aug 2010 11:09:06 -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 Wed, 18 Aug 2010 Volume: 11 Number: 3084
Today's topics:
Re: combining hashes <uri@StemSystems.com>
Re: combining hashes <bugbear@trim_papermule.co.uk_trim>
Re: combining hashes <hjp-usenet2@hjp.at>
Re: combining hashes <cartercc@gmail.com>
Re: combining hashes <sherm.pendley@gmail.com>
Re: combining hashes <jurgenex@hotmail.com>
Re: combining hashes <bugbear@trim_papermule.co.uk_trim>
Re: combining hashes <hjp-usenet2@hjp.at>
Re: combining hashes <uri@StemSystems.com>
Re: FAQ 5.23 AND: Perl the latest vs Perl the gratest <paduille.4061.mumia.w+nospam@earthlink.net>
Re: FAQ 5.23 AND: Perl the latest vs Perl the gratest <nospam-abuse@ilyaz.org>
Re: FAQ 5.23 AND: Perl the latest vs Perl the gratest <ben@morrow.me.uk>
Re: FAQ 5.23 AND: Perl the latest vs Perl the gratest <tzz@lifelogs.com>
Writing specific ./configure programs and makefiles <news@lawshouse.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 17 Aug 2010 18:23:01 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: combining hashes
Message-Id: <87bp90ri9m.fsf@quad.sysarch.com>
>>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
BM> Quoth "Uri Guttman" <uri@StemSystems.com>:
>>
>> again, we can't take what ccc says about sorting, ordering and hashes at
>> face value. we must interpret what he says through alice's mirror of
>> words meaning what i mean them to mean! :)
BM> Humpty Dumpty. Alice was just as confused by it as we are.
true but the phrase is from one of the alice books so i attributed it
that way. RIP martin gardner :(
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Wed, 18 Aug 2010 09:00:06 +0100
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: combining hashes
Message-Id: <qJidnTl5GpKbDvbRnZ2dnUVZ8jidnZ2d@brightview.co.uk>
Tad McClellan wrote:
> Tad McClellan <tadmc@seesig.invalid> wrote:
>> ccc31807 <cartercc@gmail.com> wrote:
>>> However, I still ordinarily think 'hash' when the instruction is 'in
>>> order' and think 'array' when it doesn't matter and all I need is
>>> something to hold a list.
>>
>> However, you still have an inversion in your thinking!
>
>
> Upon further reflection, I am quite sure that the disconnect
> is between how data is stored versus how it is output.
>
> You can store it ordered in an array.
>
> You can store it unordered in a hash.
>
> You can sort the output of either into any order your customer requires.
I can see where some of the confusion could come from though.
If you store data from an (unordered) hash using an unsorted
iterator into an (ordered) array, where did the order (in the array)
come from?
:-)
BugBear
------------------------------
Date: Wed, 18 Aug 2010 10:53:10 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: combining hashes
Message-Id: <slrni6n7rm.kmu.hjp-usenet2@hrunkner.hjp.at>
On 2010-08-18 08:00, bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
> Tad McClellan wrote:
>> Tad McClellan <tadmc@seesig.invalid> wrote:
>>> ccc31807 <cartercc@gmail.com> wrote:
>>>> However, I still ordinarily think 'hash' when the instruction is 'in
>>>> order' and think 'array' when it doesn't matter and all I need is
>>>> something to hold a list.
>>>
>>> However, you still have an inversion in your thinking!
>>
>>
>> Upon further reflection, I am quite sure that the disconnect
>> is between how data is stored versus how it is output.
>>
>> You can store it ordered in an array.
>>
>> You can store it unordered in a hash.
>>
>> You can sort the output of either into any order your customer requires.
>
> I can see where some of the confusion could come from though.
>
> If you store data from an (unordered) hash using an unsorted
> iterator into an (ordered) array, where did the order (in the array)
> come from?
You cheated by talking about an "unsorted" iterator instead of an
"unordered" one ;-). The iterator does return the elements in a specific
order, so that's where the order in the array comes from. The order that
the iterator walks through the hash is implementation-dependent. For
perl, that order depends not only on the current contents of the hash
but also on the exact sequence of insertions and deletions which led to
the current state. So in a mathematical sense, a hash is ordered at any
time, but the order may change every time the hash is changed. So you
can't even talk about the order of a specific hash over its lifetime
(there may be many orders), much less the order of hashes in general.
From a practical point of view, the order of a hash almost never
is what a human would call "ordered" - it looks random, that's why it's
called a hash.
hp
------------------------------
Date: Wed, 18 Aug 2010 06:35:22 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: combining hashes
Message-Id: <178beef1-81b6-4dca-a96d-6b5064ae92dc@i31g2000yqm.googlegroups.com>
On Aug 17, 3:41=A0pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> > End users know how they want their data.
>
> Yes. And so far none of my end users has asked me to deliver data "as a
> hash". They may want it as CSV or Excel files or PDFs. They may want it
> ordered by some criteria. But they don't care about arrays or hashes.
> The closest thing to a hash an end user might ever see is a table in an
> RDBMS with a unique key.
I think this is the source of the confusion, at least on my part.
Because you have direct access to the value of a hash element through
the key, it's easier to manipulate. Even though the hash itself is
apparently randomized, you can untangle the data by 'ordering' the
keys in some way, and I use 'ordering' is a generic sense, like
sorting or filtering.
> Yes, the result of the query is ordered. But as you write yourself, the
> table is not. Just because you *can* order something doesn't mean it
> *is* ordered.
Exactly. The important thing is that the output is 'ordered' which is
all that end users care about.
> > Looking back on what I originally wrote, this is what I said -- you
> > can't use a common key to combine the values in two different hashes
> > unless you 'order' the key in the second hash by the key in the first
> > hash. The little code snippet I posted shows this explicitly.
>
> I haven't the slightest idea what "'order' the key in the second hash by
> the key in the first hash" is supposed to mean, not even after looking
> at the snippet you probably mean.
To take a real life example, I have %retirement that contains key
value pairs consisting of the employee ID and the employee's
retirement system status, like this:
12345 =3D> 'Member'
23456 =3D> 'Non=3DMember'
34567 =3D> 'Retired'
45678 =3D> 'Inactive Member'
I also have %employees which contain data relating to individual
employees, but that does not contain the retirement system status. It
looks like this:
56789 =3D> { last =3D> 'Doe', first =3D> 'John', title =3D> 'Mr.', ...}
To produce the report, I have to 'merge' %retirement and %employee. I
can easily do this like:
foreach my $id {keys %employee)
{
$employee{$id}{retirement} =3D $retirement{$id} if exists
$retirement{$id};
$employee{$id}{retirement} =3D 'Unknown' unless exists
$retirement{$id};
}
> you obviously don't care about the order and you should have omitted the
> "order by zip". Why tell the database to order the result if you
> immediately throw the order away?
In practice, I never use 'order by' in my SQL, I always do it in the
script.
> You do realize that what you are sorting here is a list (the list of
> keys) - i.e. practically an array.
I didn't, until this thread. All I knew was that it worked. But now I
do know, which is progress.
> > You can tell me that a list of names by last, first, middle, and
> > suffix isn't an ordered list,
>
> Of course it is ordered. A list has order. A hash does not. Do you
> really not understand the difference between a list and a hash?
One of the reasons that I am studying Lisp is to learn more about ways
to structure data. Lisp has an especially rich set of data structures,
lists (obviously), arrays, hash tables, sets, bags, vectors, trees,
and so on. The basis for all of these is a series of conses, and the
difference lies in how the conses are structured. It's pretty deep
stuff, and I can't say that I'm finding it easy. All I can say is that
I'm learning.
CC.
------------------------------
Date: Wed, 18 Aug 2010 09:53:53 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: combining hashes
Message-Id: <m2vd78gh72.fsf@sherm.shermpendley.com>
ccc31807 <cartercc@gmail.com> writes:
> Exactly. The important thing is that the output is 'ordered' which is
> all that end users care about.
Yes, we all speak in terms our clients, users, etc. can understand,
when we're speaking to them. But you're not talking to your end users
when you post here. The important thing *here* is to use technical
terms correctly.
sherm--
--
Sherm Pendley
<camelbones.sourceforge.net>
Cocoa Developer
------------------------------
Date: Wed, 18 Aug 2010 07:44:53 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: combining hashes
Message-Id: <b6sn661nk3dekjlq4qhg4ti1m06hpij95r@4ax.com>
ccc31807 <cartercc@gmail.com> wrote:
>I think this is the source of the confusion, at least on my part.
>Because you have direct access to the value of a hash element through
>the key, it's easier to manipulate.
Right, you finally mentioned the key word here: access.
> Even though the hash itself is
>apparently randomized, you can untangle the data by 'ordering' the
>keys in some way, and I use 'ordering' is a generic sense, like
>sorting or filtering.
And again you mentioned the key word: 'ordering _THE_KEYS_(!!!)'
You are not ordering the hash because that cannot be done (at least not
without additional virtual data structures on top of the hash) but you
take the list of keys and you order that list.
jue
------------------------------
Date: Wed, 18 Aug 2010 16:50:38 +0100
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: combining hashes
Message-Id: <9LGdnQKOZaTTnPHRnZ2dnUVZ8qidnZ2d@brightview.co.uk>
Jürgen Exner wrote:
> ccc31807 <cartercc@gmail.com> wrote:
>> I think this is the source of the confusion, at least on my part.
>> Because you have direct access to the value of a hash element through
>> the key, it's easier to manipulate.
>
> Right, you finally mentioned the key word here: access.
>
>> Even though the hash itself is
>> apparently randomized, you can untangle the data by 'ordering' the
>> keys in some way, and I use 'ordering' is a generic sense, like
>> sorting or filtering.
>
> And again you mentioned the key word: 'ordering _THE_KEYS_(!!!)'
> You are not ordering the hash because that cannot be done (at least not
> without additional virtual data structures on top of the hash) but you
> take the list of keys and you order that list.
ccc seems to confuse "ordered" with "can be ordered".
BugBear
------------------------------
Date: Wed, 18 Aug 2010 18:05:40 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: combining hashes
Message-Id: <slrni6o16l.414.hjp-usenet2@hrunkner.hjp.at>
On 2010-08-18 13:35, ccc31807 <cartercc@gmail.com> wrote:
> On Aug 17, 3:41 pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
>> > Looking back on what I originally wrote, this is what I said -- you
>> > can't use a common key to combine the values in two different hashes
>> > unless you 'order' the key in the second hash by the key in the first
>> > hash. The little code snippet I posted shows this explicitly.
>>
>> I haven't the slightest idea what "'order' the key in the second hash by
>> the key in the first hash" is supposed to mean, not even after looking
>> at the snippet you probably mean.
>
> To take a real life example, I have %retirement that contains key
> value pairs consisting of the employee ID and the employee's
> retirement system status, like this:
> 12345 => 'Member'
> 23456 => 'Non=Member'
> 34567 => 'Retired'
> 45678 => 'Inactive Member'
> I also have %employees which contain data relating to individual
> employees, but that does not contain the retirement system status. It
> looks like this:
> 56789 => { last => 'Doe', first => 'John', title => 'Mr.', ...}
> To produce the report, I have to 'merge' %retirement and %employee. I
> can easily do this like:
> foreach my $id {keys %employee)
> {
> $employee{$id}{retirement} = $retirement{$id} if exists
> $retirement{$id};
> $employee{$id}{retirement} = 'Unknown' unless exists
> $retirement{$id};
> }
You can omit the scare quotes around "merge". What you are doing here is
called merging (SQLers would talk about an (outer) join). It is not
called "ordering". Nothing in that code imposes an order. You may use
the newly merged information in the hash for sorting later but you don't
do it here.
>> > You can tell me that a list of names by last, first, middle, and
>> > suffix isn't an ordered list,
>>
>> Of course it is ordered. A list has order. A hash does not. Do you
>> really not understand the difference between a list and a hash?
>
> One of the reasons that I am studying Lisp is to learn more about ways
> to structure data. Lisp has an especially rich set of data structures,
> lists (obviously), arrays, hash tables, sets, bags, vectors, trees,
> and so on. The basis for all of these is a series of conses, and the
> difference lies in how the conses are structured.
Hmm. I don't see how you can build a real array from conses. A cons
contains at most two pointers, so everything you get are (possibly
degenerated) binary trees.
If you really want to learn about data structures I suggest using a
language which lets you get down to the metal, like C or even assembler
(not necessarily a real one like x86, better a synthetic one like
MMIX)
hp
------------------------------
Date: Wed, 18 Aug 2010 12:28:58 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: combining hashes
Message-Id: <87occzj35h.fsf@quad.sysarch.com>
>>>>> "c" == ccc31807 <cartercc@gmail.com> writes:
c> On Aug 17, 3:41 pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
>> > End users know how they want their data.
>>
>> Yes. And so far none of my end users has asked me to deliver data "as a
>> hash". They may want it as CSV or Excel files or PDFs. They may want it
>> ordered by some criteria. But they don't care about arrays or hashes.
>> The closest thing to a hash an end user might ever see is a table in an
>> RDBMS with a unique key.
c> I think this is the source of the confusion, at least on my part.
c> Because you have direct access to the value of a hash element through
c> the key, it's easier to manipulate. Even though the hash itself is
c> apparently randomized, you can untangle the data by 'ordering' the
c> keys in some way, and I use 'ordering' is a generic sense, like
c> sorting or filtering.
so SAY sorting. don't use ordering IN the hash. that is all you need to
so. sorting a list of hashes by a key or value is common and normal. it
is NOT ordering the hash. hell, it has to be a list to be ordered.
>> Yes, the result of the query is ordered. But as you write yourself, the
>> table is not. Just because you *can* order something doesn't mean it
>> *is* ordered.
c> Exactly. The important thing is that the output is 'ordered' which is
c> all that end users care about.
and it is a list/array of records in an order. get that too.
>> You do realize that what you are sorting here is a list (the list of
>> keys) - i.e. practically an array.
c> I didn't, until this thread. All I knew was that it worked. But now I
c> do know, which is progress.
just get that lists/arrays can be ordered/sorted. hashes can't. simple.
using the right terminology is half the battle.
>> > You can tell me that a list of names by last, first, middle, and
>> > suffix isn't an ordered list,
>>
>> Of course it is ordered. A list has order. A hash does not. Do you
>> really not understand the difference between a list and a hash?
c> One of the reasons that I am studying Lisp is to learn more about ways
c> to structure data. Lisp has an especially rich set of data structures,
c> lists (obviously), arrays, hash tables, sets, bags, vectors, trees,
c> and so on. The basis for all of these is a series of conses, and the
c> difference lies in how the conses are structured. It's pretty deep
c> stuff, and I can't say that I'm finding it easy. All I can say is that
c> I'm learning.
all languages have those data structures. really. i can do them in
assembler, c, lisp, perl, etc. data structures are a language
independent concept and if properly taught they aren't tied to a single
language. some structures are easier/harder in different langs but all
are doable. don't claim lisp 'has' most structures.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 17 Aug 2010 22:59:50 -0500
From: "Mumia W." <paduille.4061.mumia.w+nospam@earthlink.net>
Subject: Re: FAQ 5.23 AND: Perl the latest vs Perl the gratest
Message-Id: <saydnUIm--k9xfbRnZ2dnUVZ_tSdnZ2d@earthlink.com>
On 08/17/2010 09:08 AM, Ted Zlatanov wrote:
> On Fri, 13 Aug 2010 21:11:33 +0000 (UTC) Ilya Zakharevich<nospam-abuse@ilyaz.org> wrote:
>
> IZ> When I write reusable code, I'm interested in balancing "the lowest common
> IZ> denominator" vs "annoyance factor with coding to rare flavors of Perl".
>
> IZ> I'd be more interested in consulting FAQ (and other docs) when I
> IZ> operate in the second ("reusable") mode. So I'm much more interested
> IZ> in FAQ focusing on the "current pool" of deployed Perl than it
> IZ> focussing on the latest version.
>
> You want the FAQ to be a textbook/cookbook; I want it to reflect what's
> current. Your viewpoint is valid and well-addressed by about 50 books
> in the marketplace. I don't see why the FAQ should be another. There
> just aren't that many places to find out "what's the best way to do X
> with the latest Perl."
>
> Ted
My 2¢ is that the FAQ is better as a cookbook. A power-user's personal
blog would be the best way to showcase the latest and greatest features
(including best practices with Perl's later than 5.8.8).
------------------------------
Date: Wed, 18 Aug 2010 06:47:29 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: FAQ 5.23 AND: Perl the latest vs Perl the gratest
Message-Id: <slrni6n0g1.jam.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-08-17, Ted Zlatanov <tzz@lifelogs.com> wrote:
> IZ> When I write reusable code, I'm interested in balancing "the lowest common
> IZ> denominator" vs "annoyance factor with coding to rare flavors of Perl".
> IZ> I'd be more interested in consulting FAQ (and other docs) when I
> IZ> operate in the second ("reusable") mode. So I'm much more interested
> IZ> in FAQ focusing on the "current pool" of deployed Perl than it
> IZ> focussing on the latest version.
> You want the FAQ to be a textbook/cookbook; I want it to reflect what's
> current.
"What is current" is addressed in "reference guides". I see no point
in duplicating that. [*]
> Your viewpoint is valid and well-addressed by about 50 books
> in the marketplace.
The moment "a book in a marketplace" enters a discussion of the docs,
I plunk. Books have their place. Just not in this discussion.
Yours,
Ilya
[*] Unfortunately (and I do not need to repeat it) the current state
of Perl docs is abysmal. One of (many) major problems is that
there is no separation of "user's guide" and "reference guide"
parts. (Only the FAQ is clearly standing alone.)
It might be that one can break man/pod-pages into these two
categories (although I doubt this). But even if this is true,
there is no indication (I know of) of this separation.
------------------------------
Date: Wed, 18 Aug 2010 13:19:55 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: FAQ 5.23 AND: Perl the latest vs Perl the gratest
Message-Id: <bovsj7-62b.ln1@osiris.mauzo.dyndns.org>
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
>
> [*] Unfortunately (and I do not need to repeat it) the current state
> of Perl docs is abysmal. One of (many) major problems is that
> there is no separation of "user's guide" and "reference guide"
> parts. (Only the FAQ is clearly standing alone.)
>
> It might be that one can break man/pod-pages into these two
> categories (although I doubt this). But even if this is true,
> there is no indication (I know of) of this separation.
Well, the *tut pods are intended as tutorials, and the *ref as reference
guides :). The others are uncategorised.
There is something of an ongoing project to split most of the existing
manpages into those two categories, but as I'm sure you can imagine it's
a lot of work. It's also not the sort of work most programmers find fun,
so it doesn't tend to get done as often as it might. Being rude about it
doesn't help anyone.
Ben
------------------------------
Date: Wed, 18 Aug 2010 08:38:09 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: FAQ 5.23 AND: Perl the latest vs Perl the gratest
Message-Id: <87y6c4dose.fsf@lifelogs.com>
On Tue, 17 Aug 2010 22:59:50 -0500 "Mumia W." <paduille.4061.mumia.w+nospam@earthlink.net> wrote:
MW> My 2¢ is that the FAQ is better as a cookbook. A power-user's personal
MW> blog would be the best way to showcase the latest and greatest
MW> features (including best practices with Perl's later than 5.8.8).
Sorry, but I must disagree. Personal blogs are not a reliable resource
or packaged with Perl and thus have nowhere near the power and presence
of the FAQ.
On Wed, 18 Aug 2010 06:47:29 +0000 (UTC) Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
IZ> The moment "a book in a marketplace" enters a discussion of the docs,
IZ> I plunk. Books have their place. Just not in this discussion.
Of course, we can ignore books in a discussion about the FAQ. I simply
didn't know your rules about our discussion.
Your other points about how you would like the Perl docs to be in a
perfect world are not very convincing to me, either. I think we've
clearly established that neither of us is easily convinced :)
Ted
------------------------------
Date: Wed, 18 Aug 2010 17:38:22 +0100
From: Henry Law <news@lawshouse.org>
Subject: Writing specific ./configure programs and makefiles
Message-Id: <UJCdnSwsr4_ikfHRnZ2dnUVZ7rOdnZ2d@giganews.com>
I have an application written in Perl which consists of a set of modules
and a number of programs that use them, together with lots of in-line
code, to implement the application function. Installing it requires
copying programs into a number of different places (/usr/bin/myprog,
/usr/bin/local and the cgi-bin library as well as one of the Perl @INC
libraries), and there are configuration steps which depend on the
environment of the target machine.
So far I have hand-cranked a very specific ./configure program which
prompts the user for the desired location of the various files and for
machine-dependent things like local server addresses and user account
names; it generates a configuration file and some other local files, and
then writes a Makefile which contains "install", "update", "uninstall"
targets etc.
Question: is there Perl support for writing such a ./configure program?
I'm aware of Makemaker for automating the installation of _modules_,
but I've got lots of _programs_ too. In my mind what I think such
support might offer would include:
* Read a file defining all the source and target libraries,
specifying whether they were to be created or not, etc
* Allow ./configure to add extra files to the installation tree;
a config file, for example.
* Choose a suitable library from @INC, based on some provided criteria.
* Support generation of prompts to the user for alternate destinations.
* Write commands to the Makefile to carry out certain
pre-installation activities.
* Write Makefile commands installing the various components.
* Create the "uninstall" section to include all files installed
and keep track of which directories can be deleted.
* Save the parameters of the previous invocation of ./config for use in
subsequent installations.
I had a look at GNU automake too, but I can't see how it would meet this
need.
--
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 3084
***************************************
