[32025] in Perl-Users-Digest
Perl-Users Digest, Issue: 3289 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Feb 17 16:09:27 2011
Date: Thu, 17 Feb 2011 13:09:09 -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 Thu, 17 Feb 2011 Volume: 11 Number: 3289
Today's topics:
Re: data transformation, Perl and MicroSoft sln@netherlands.com
Re: Hashes are good, but not good enough. <xhoster@gmail.com>
Re: Hashes are good, but not good enough. <tzz@lifelogs.com>
Re: Hashes are good, but not good enough. <nospam-abuse@ilyaz.org>
Re: Regex question; match <br> after opening tag <jwcarlton@gmail.com>
Re: Regex question; match <br> after opening tag <sherm.pendley@gmail.com>
Re: Regex question; match <br> after opening tag <mvdwege@mail.com>
Re: Regex question; match <br> after opening tag <mvdwege@mail.com>
Re: Regex question; match <br> after opening tag <cartercc@gmail.com>
Re: repository problem w/x64 ActivePerl 5.12 <jae6363@gmail.com>
Strategies for modifying marked-up text? <news4281@baetzler.de>
Re: Strategies for modifying marked-up text? <hjp-usenet2@hjp.at>
Re: Strategies for modifying marked-up text? <cartercc@gmail.com>
Re: toy list processing problem: collect similar terms <w_a_x_man@yahoo.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 17 Feb 2011 11:44:44 -0800
From: sln@netherlands.com
Subject: Re: data transformation, Perl and MicroSoft
Message-Id: <k6uql61ofi9tqreb46qkbc6ocgakbh7l9n@4ax.com>
On Fri, 11 Feb 2011 09:33:31 -0800 (PST), ccc31807 <cartercc@gmail.com> wrote:
>My apology to those of you who think this post is OT.
>
><quote>
>Challenges of Data Integration
>
>Technology Challenges
>
>Technology challenges start with source systems. We are moving from
>collecting data on transactions (where customers commit to getting,
>buying, or otherwise acquiring something) to collecting data on pre-
>transactions (where mechanisms such as Web clicks or RFID tags track
>customer intentions).
You know what I think about these Technology Challenges?
I think they can fucking go to fucking hell !!!
This joins the ranks with "adver-blasting", invasion of privacy,
and more of its ilk. Together, a thing to be shunned, spit on,
and kicked in the balls!
As far as I'm concerned, the Anti-Technology Technology is far
more profitable if your customers are the working people of the
world. Thats a business that will ultimately come out on top.
Fuck this shit!
-sln
------------------------------
Date: Thu, 17 Feb 2011 00:14:54 -0800
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <4d5cd742$0$20084$ed362ca5@nr5-q3a.newsreader.com>
Ted Zlatanov wrote:
> On Mon, 14 Feb 2011 19:27:09 -0800 Xho Jingleheimerschmidt <xhoster@gmail.com> wrote:
>
> XJ> Ted Zlatanov wrote:
>>> Hundreds of millions of hash keys will take up a lot of memory, probably
>>> unnecessarily.
>
> XJ> Any space is unnecessary. I could always just throw the problem over
> XJ> the wall to someone else,
>
> (AKA "put it in a database", and of course databases are *engineered* to
> store and index large amounts of data)
Most database systems, at least RDBMS ones, are actually primarily
engineered for ACID compliance, and these designs impose huge overheads.
My first answer to most insufferably slow join problems is just to
suck all the data into giant Perl hashes and do it there.
>
> Any time you take an argument to extremes it sounds awkward. As I keep
> asking, why do you need hundreds of millions of keys?
I don't, that I know of. But I am not the only person who does things,
and I oppose the idea we should insults people's problems just because
we don't understand them. I've used ordinary Perl hashes with up to
16777216 and would go to 4 times that without a second thought. Beyond
that, I'd probably still do it, but just keep a close eye on "top" until
I was comfortable with it.
> Are you actually
> going to use the values? What's the usage pattern? My point is that
> "just stuff hundreds of millions of keys in a hash" is VERY likely not
> the answer to any actual need and experienced programmers know that.
Except for the ones that disagree with it.
>
>>> Iterating through them will be painful even unsorted
>
> XJ> Painful for whom? Does a CPU feel pain? And if so, do I care?
>
> For the user waiting for the results. Again, what's the usage pattern?
> Will you need to iterate? If so, how quickly do you need the results?
They don't *need* the results at all. But they would like them more
quickly than they will get them by waiting for me to code and debug a
highly specialized data structure, rather than using the general purpose
one I already have.
> Do you mind waiting for one CPU to crunch the data?
If I did, I'd do something about it. That something would probably
involve Perl hashes to some degree, but 100 million element ones. It
probably wouldn't involve DAWG.
> Or are you going to
> fork or use threads? You'll certainly have time to think about this
> while you're waiting for Perl to sputter through the opcodes in a tight
> loop, busting the cachelines every time.
Normally I would think about some *different* problem while waiting for
one crunch to go through. Or go get some lunch. Or go home and sleep.
What do you think PostGresql, Oracle and DAWGS do to cachelines?
Xho
------------------------------
Date: Thu, 17 Feb 2011 09:49:43 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <87hbc21x0o.fsf@lifelogs.com>
On Thu, 17 Feb 2011 00:14:54 -0800 Xho Jingleheimerschmidt <xhoster@gmail.com> wrote:
XJ> Ted Zlatanov wrote:
>> (AKA "put it in a database", and of course databases are *engineered* to
>> store and index large amounts of data)
XJ> Most database systems, at least RDBMS ones, are actually primarily
XJ> engineered for ACID compliance, and these designs impose huge
XJ> overheads. My first answer to most insufferably slow join problems is
XJ> just to suck all the data into giant Perl hashes and do it there.
I was talking about databases in general, including NoSQL types without
the ACID constraint.
Joins are a special kind of query where it does make sense to do things
in memory if the database can't, so I would agree with you that's a good
idea, depending on the specific need. I actually did something similar
to that kind of join query in Perl and compared it to just running the
query inside Sybase. Perl was faster for a while but Sybase won in the
end as the amount of data grew.
>> Any time you take an argument to extremes it sounds awkward. As I keep
>> asking, why do you need hundreds of millions of keys?
XJ> I don't, that I know of. But I am not the only person who does
XJ> things, and I oppose the idea we should insults people's problems just
XJ> because we don't understand them.
I think if you read my original message, 90% of it was trying to find
out more about the problem. I was trying to say I'm deeply suspicious
of "just throwing lots of data in a hash" as a way to solve actual
problems. It may work, but as the amount of data grows it won't
necessarily scale.
>> For the user waiting for the results. Again, what's the usage pattern?
>> Will you need to iterate? If so, how quickly do you need the results?
XJ> They don't *need* the results at all. But they would like them more
XJ> quickly than they will get them by waiting for me to code and debug a
XJ> highly specialized data structure, rather than using the general
XJ> purpose one I already have.
Er, the data structure is *not* the issue and I wasn't advocating a
complicated one. Whether you throw 100 million keys in a hash or 100
million rows in a database table, you're still managing large amounts of
data in a flat structure. But you're not answering the usage questions,
which I'll say again are what really matters.
>> Or are you going to fork or use threads? You'll certainly have time
>> to think about this while you're waiting for Perl to sputter through
>> the opcodes in a tight loop, busting the cachelines every time.
XJ> Normally I would think about some *different* problem while waiting
XJ> for one crunch to go through. Or go get some lunch. Or go home and
XJ> sleep.
XJ> What do you think PostGresql, Oracle and DAWGS do to cachelines?
Interesting question. DAWGs don't do anything, they are a data
structure. If the code is in C and the data structure is compact, you
have a chance to avoid these penalties. I think DAWG won't do well
there but tries and bloom filters may.
With Perl the data and instructions are just not local enough. This is
my experience on x86 Nehalems and a reasonable inner loop.
Databases are usually engineered for concurrent access, which lets you
scale much more than Perl hashes would. I don't know performance
specifics for PostgreSQL or Oracle, but they do seem to be popular,
especially Oracle, for large data sets. I would imagine Oracle, at
least, has a couple of engineers checking the code performance at the
CPU level.
Ted
------------------------------
Date: Thu, 17 Feb 2011 20:41:46 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <slrnilr20a.vgp.nospam-abuse@powdermilk.math.berkeley.edu>
On 2011-02-16, Ted Zlatanov <tzz@lifelogs.com> wrote:
> to partition by day. Anyhow, my whole point is "think before you throw
> a lot of data in a single place." It may indeed make sense to create
> such a large single-level hash. I'm not aware of such a case but am
> willing to hear specifics and discuss them.
> IZ> So are Perl hashes - and I expect they are going to be order(s?) of
> IZ> magnitude more space efficient and quickier than databases. (Provided
> IZ> that memory holds enough water.)
>
> You have to at least consider the cost of memory. It's significantly
> more expensive than disk and requires a much larger startup time to
> populate after a restart.
The cost we discuss is of order of magnitude $3000. If there is a
database-aware expert around, this may be a saving reasonable to
consider. Otherwise, one should take into account also the added
maintainance cost of using yet another tool...
I like your startup time argument. I did not think of this!
Thanks,
Ilya
------------------------------
Date: Wed, 16 Feb 2011 18:15:36 -0800 (PST)
From: jwcarlton <jwcarlton@gmail.com>
Subject: Re: Regex question; match <br> after opening tag
Message-Id: <04359962-cc16-461a-9639-feb9b2ae0cc4@x21g2000vbn.googlegroups.com>
> > I try; really, I do.
>
> "Do, or do not - there is no try." - Yoda
I thought that was Mr. Miyagi? LOL
> That just goes to show, you should consider the source. One of our more
> persistent trolls here used to give that same, very misguided, advice
> whenever the topic came up. I'm sorry to hear you were misled by bad
> advice.
It happens. Honestly, for awhile I was getting 0 help on here, just
all trolls, so it left a rather bad taste in my mouth.
I've been coding in Perl for almost 15 years, and I keep thinking of
how helpful everyone here used to be when I was just starting. I don't
know if it's that the type of people that post has changed, or if I'm
just more sensitive, or if I'm just becoming an old man thinking about
"the good ol' days". Probably a mix of the 3.
I used to ALWAYS know better than to feed the trolls, too. Maybe it is
just an old man thing? :-(
> The HTML::HTML5::Parser docs say that parse_string() should give you an
> instance of XML::LibXML::Document, and the message above indicates that
> it did. That's good news, as it shows that nothing actually went wrong;
> the problem is that you're trying to print the object as if it were just
> a string. What you should do instead is check the docs for that module,
> and find a method for that object that will give you a string. At first
> glance, it looks to me like toString() would be appropriate:
>
> =A0 print $comment->toString();
Awesome! That worked perfectly, Sherm.
I looked all through the docs, both last night and today, and didn't
see anything like that. For the sake of my own learnin', where exactly
did you find that?
> Note that X::L::Document has some other interesting methods, that relate
> to querying the document to get a collection of all the elements of a
> given type, or an element with a particular id. These DOM methods are
> the same (language differences aside) as those provided by JavaScript
> on the document object.
Cool, thanks again!
------------------------------
Date: Wed, 16 Feb 2011 21:27:32 -0500
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: Regex question; match <br> after opening tag
Message-Id: <m2k4gz4cq3.fsf@sherm.shermpendley.com>
jwcarlton <jwcarlton@gmail.com> writes:
> Sherm Pendley <sherm.pendley@gmail.com> writes:
>
>> The HTML::HTML5::Parser docs say that parse_string() should give you an
>> instance of XML::LibXML::Document, and the message above indicates that
>> it did. That's good news, as it shows that nothing actually went wrong;
>> the problem is that you're trying to print the object as if it were just
>> a string. What you should do instead is check the docs for that module,
>> and find a method for that object that will give you a string. At first
>> glance, it looks to me like toString() would be appropriate:
>>
>> print $comment->toString();
>
> Awesome! That worked perfectly, Sherm.
>
> I looked all through the docs, both last night and today, and didn't
> see anything like that. For the sake of my own learnin', where exactly
> did you find that?
I don't have it installed, so found it on <http://search.cpan.org> and
scanned its docs - there's a handy list of all its methods at the top.
Based on its name, toString() looked like it might be relevant to what
you were trying to do, so I checked the full description of it to make
sure.
I've invested quite a few points in the Looking Stuff Up skill over the
years, and found that it's a pretty good investment. :-)
sherm--
--
Sherm Pendley
<http://camelbones.sourceforge.net>
Cocoa Developer
------------------------------
Date: Thu, 17 Feb 2011 08:13:00 +0100
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: Regex question; match <br> after opening tag
Message-Id: <86r5b7gmmb.fsf@gareth.avalon.lan>
George Mpouras <nospam.gravitalsun@hotmail.com.nospam> writes:
>>
>> Don't do that with a regex. A regular expression can only express a
>> regular grammar - hence the name. HTML is a context-free grammar, which
>> needs a more complex parser than a regex can provide.
>>
>
> sometimes a "good enough" workaround is just fine
Yes, but that requires understanding that it *is* a "good enough"
workaround.
And the burden of proving that understanding is on the one asking a
FAQ. And he's not doing too good a job of it right now.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Thu, 17 Feb 2011 08:18:19 +0100
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: Regex question; match <br> after opening tag
Message-Id: <86mxlvgmdg.fsf@gareth.avalon.lan>
jwcarlton <jwcarlton@gmail.com> writes:
>> > He and I have a history
>>
>> Then maybe you should simply ignore his posts.
>
> I try; really, I do. I was mostly concerned that others would glance
> over the thread and think that he had legitimately solved the problem.
>
>
I did. His solution of using a parser was the correct one.
>
> I've considered HTML::Parser, but if I understand correctly, don't you
> have to specifically define which tags you want to parse? That's all
> well and good, except that people often paste data from other sites,
> so it's difficult to think of every possibility.
You are Not Getting It.
If your users can give you data that you cannot handle, the best method
is to reject or discard it (in case of HTML, don't process tags you have
no handlers for).
The way HTML::Parser goes about it according to your description *is*
the right way to do it.
When treating outside data, always do so on a white-list basis: only
accept what you have explicitly defined. Trying to think of everything
leads to security holes. If you write software this way, the question is
*when* it will be exploited, not if.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Thu, 17 Feb 2011 11:04:09 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: Regex question; match <br> after opening tag
Message-Id: <6c521e18-dca8-4d96-8e9f-a69ed4d560fc@y35g2000prc.googlegroups.com>
On Feb 15, 11:43=A0pm, jwcarlton <jwcarl...@gmail.com> wrote:
> I'm trying to remove opening and closing <br> tags.
What you want to do, assuming that you have the entire ASCII text in a
variable, is this:
$var =3D~ s/<br[^>]*>//ig;
This looks for three literal characters, the '<', 'b', and 'r', then
looks for any number of characters (including zero characters) which
are not a literal '>', then a literal '>', and replaces them with
nothing, looking globally in a case insensitive manner.
CC.
------------------------------
Date: Thu, 17 Feb 2011 11:14:02 -0800 (PST)
From: Jonathan Epstein <jae6363@gmail.com>
Subject: Re: repository problem w/x64 ActivePerl 5.12
Message-Id: <fc0d4a20-cc1f-4e62-a15e-f2d7f2864823@o18g2000prh.googlegroups.com>
On Feb 16, 7:44=A0pm, "jl_p...@hotmail.com" <jl_p...@hotmail.com> wrote:
> On Feb 16, 12:09=A0pm, Jonathan Epstein <jae6...@gmail.com> wrote:
>
>
>
> > I have used PPM and/or CPAN many times to install the ptkdb
> > debugger, but this time am stuck. =A0I'm running a 64-bit version
> > of Perl on Windows 7, and am trying to use the bribes.org
> > repository.
>
> =A0 =A0I had quite a few problems like yours whenever I installed a new
> version of ActiveState Perl on a new version of Windows. =A0That pretty
> much went away, however, when I switched to Strawberry Perl.
>
> =A0 =A0Once I installed Strawberry Perl, I was able to use the ptkdb
> debugger after installing it with these commands:
>
> =A0 =A0 =A0 cpan Tk
> =A0 =A0 =A0 cpan Devel::ptkdb
>
> (Occasionally "cpan Devel::ptkdb" would fail, in which case I'd use
> "ppm install Devel::ptkdb" instead.)
>
> =A0 =A0Because of its ease of installing modules, I never regretted
> switching to Strawberry Perl when using Windows. =A0And since many of my
> peers still use ActivePerl, it's still pretty much hit-or-miss when
> I'm trying to set them up to be able to use ptkdb.
>
> =A0 =A0I hope this helps, Jonathan.
>
> =A0 =A0Cheers,
>
> =A0 =A0-- Jean-Luc
Thanks, Jean-Luc. I'd never heard of Strawberry Perl, but am willing
to try it. I've used both PPM and CPAN in the past with Windows-based
Perl. My guess is that your version of Strawberry Perl is 32-bit, as
you'll see below.
I think where I've run into trouble recently, is my use of 64-bit
Perl, which I selected so I could deal with large in-memory datasets.
I can't even build my own versions of Tk and Devel::ptkdb via CPAN,
because I don't have a 64-bit-friendly Visual Studio compiler, since
the free 'Visual Studio Express' doesn't support 64-bit compilation
and linking. I suspect that this is the same reason that most non-
ActiveState PPM repositories haven't been built for 64-bit packages.
So I think I'm out of luck for now ... am uninstalling 64-bit
ActiveState Perl and installing a 32-bit version. I'll also try to
order a higher-end Visual Studio compiler at work.
If anyone knows of a working solution for Devel::ptkdb and 64-bit Perl
on Windows, in the meantime, I'd be grateful.
Thanks again for your response, Jean-Luc.
Jonathan
------------------------------
Date: Thu, 17 Feb 2011 10:45:11 +0100
From: Thomas Baetzler <news4281@baetzler.de>
Subject: Strategies for modifying marked-up text?
Message-Id: <ijiqna$ak9$02$1@news.t-online.com>
Hi,
I'm looking for input on how to run search/replace operations on
paragraphs of HTML text without having to worry about the surrounding
markup.
So far I'm using HTML::Treebuilder to parse a HTML document and identfy
the individual paragraphs in the text. By recursively using the
content_list method, I can locate the individual text chunks that make
up the paragraph text.
What I'd like to do is merge these chunks into a single string, run some
search/replace regexes on it, then update the individual text chunks
with the changes.
Is there a better way to do this than stopping after each change to see
what's changed and keep track of chunk borders that way?
I could probably work on individual chunks in turn, but taking care of
all the edge cases where I'd have to do lookahead/lookback in adjoining
chunks could be, well, tedious ;-)
TIA for any suggestion you might have!
Cheers,
Thomas
------------------------------
Date: Thu, 17 Feb 2011 18:37:43 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Strategies for modifying marked-up text?
Message-Id: <slrnilqn77.uqs.hjp-usenet2@hrunkner.hjp.at>
On 2011-02-17 09:45, Thomas Baetzler <news4281@baetzler.de> wrote:
> I'm looking for input on how to run search/replace operations on
> paragraphs of HTML text without having to worry about the surrounding
> markup.
Replace fixed strings or regexps?
> So far I'm using HTML::Treebuilder to parse a HTML document and identfy
> the individual paragraphs in the text. By recursively using the
> content_list method, I can locate the individual text chunks that make
> up the paragraph text.
>
> What I'd like to do is merge these chunks into a single string, run some
> search/replace regexes on it, then update the individual text chunks
> with the changes.
>
> Is there a better way to do this than stopping after each change to see
> what's changed and keep track of chunk borders that way?
You could write a custom matcher which walks your HTML tree. That's
probably a lot of work and quite slow if you need the whole power of
perl regexps, but might work if you need only some subset (fixed strings
in the extreme case).
Other than that, I think keeping the offsets of the start and end of
each element and readjusting them after each replacement is probably the
easiest way.
> I could probably work on individual chunks in turn, but taking care of
> all the edge cases where I'd have to do lookahead/lookback in adjoining
> chunks could be, well, tedious ;-)
Here is one case which comes immediately in mind and for which I don't
have a good solution:
If we have the HTML fragment
<p>Here is some <em>italicized text</em></p>
and you do a
s/ some italicized / a bit of emphasized /
what should be the result? The em element must start somewhere within
the replaced text but where?
hp
------------------------------
Date: Thu, 17 Feb 2011 10:28:45 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: Strategies for modifying marked-up text?
Message-Id: <c639f99c-5943-4dd6-ad12-8015263a05aa@o32g2000prb.googlegroups.com>
On Feb 17, 4:45=A0am, Thomas Baetzler <news4...@baetzler.de> wrote:
> I'm looking for input on how to run search/replace operations on
> paragraphs of HTML text without having to worry about the surrounding
> markup.
Depending on the particular search and replace operations, it would
probably be easiest to slurp the entire file in memory and do the
search and replace just once. This is by far the best way to make
global changes to a document, provided it will fit into memory. The
format of the document (HTML, XML, TXT, CSV, etc.) does not matter.
If you had the entire document in memory, in a variable name $html,
and you wanted to change all occurrences of 'George W. Bush' to
'Barack H. Obama', you could do this:
$html =3D~ s/George W. Bush/Barack H. Obama/g;
You might also want to look at 'Perl slurp mode'
CC.
------------------------------
Date: 17 Feb 2011 07:19:43 GMT
From: "WJ" <w_a_x_man@yahoo.com>
Subject: Re: toy list processing problem: collect similar terms
Message-Id: <ijii6f0181m@enews6.newsguy.com>
Xah Lee wrote:
> here's a interesting toy list processing problem.
>
> I have a list of lists, where each sublist is labelled by
> a number. I need to collect together the contents of all sublists
> sharing
> the same label. So if I have the list
>
> ((0 a b) (1 c d) (2 e f) (3 g h) (1 i j) (2 k l) (4 m n) (2 o p) (4 q
> r) (5 s t))
>
> where the first element of each sublist is the label, I need to
> produce:
>
> output:
> ((a b) (c d i j) (e f k l o p) (g h) (m n q r) (s t))
>
Solving without hash-tables or "group-by".
Using Guile:
First, sort the groups by the numbers.
(stable-sort groups (lambda(a b)(< (car a) (car b))))
((0 a b) (1 c d) (1 i j) (2 e f) (2 k l) (2 o p) (3 g h)
(4 m n) (4 q r) (5 s t))
Next, flatten the list.
(append-map identity step1)
(0 a b 1 c d 1 i j 2 e f 2 k l 2 o p 3 g h 4 m n 4 q r 5 s t)
Remove duplicate numbers.
(delete-duplicates step2)
(0 a b 1 c d i j 2 e f k l o p 3 g h 4 m n q r 5 s t)
We now need a very useful function called "scan".
;; Yields sublists of contiguous items that satisfy func.
(define (scan func lst)
(let ((tail (find-tail func lst)))
(if tail
(cons (take-while func tail)
(scan func (drop-while func tail)))
'())))
(scan symbol? step3)
((a b) (c d i j) (e f k l o p) (g h) (m n q r) (s t))
------------------------------
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 3289
***************************************
