[31588] in Perl-Users-Digest
Perl-Users Digest, Issue: 2847 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Mar 3 14:09:24 2010
Date: Wed, 3 Mar 2010 11:09:07 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 3 Mar 2010 Volume: 11 Number: 2847
Today's topics:
Re: Automatic Web Form Submission <tadmc@seesig.invalid>
Re: Can you compile a perl executable? <bugbear@trim_papermule.co.uk_trim>
CGI html table generation <justin.0911@purestblue.com>
Re: CGI html table generation <tadmc@seesig.invalid>
Re: CGI html table generation <RedGrittyBrick@spamweary.invalid>
Re: CGI html table generation <hhr-m@web.de>
Re: flushing buffer for printing to the screen <hjp-usenet2@hjp.at>
Re: how to speed up a string-substitution loop? <adam.kellas@gmail.com>
Re: how to speed up a string-substitution loop? <uri@StemSystems.com>
Re: how to speed up a string-substitution loop? <adam.kellas@gmail.com>
Re: how to speed up a string-substitution loop? <uri@StemSystems.com>
Re: how to speed up a string-substitution loop? sln@netherlands.com
Re: how to speed up a string-substitution loop? sln@netherlands.com
ruby com-piler that worked <robin1@cnsp.com>
Re: strange behavior <darkon.tdo@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 03 Mar 2010 07:09:09 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Automatic Web Form Submission
Message-Id: <slrnhosnkh.dk8.tadmc@tadbox.sbcglobal.net>
andy <andygough1974@gmail.com> wrote:
> I have to do many travel request searches for flights and would like
> to automate it,
Have you checked that the Terms of Service for each site allows
automated access?
> I can parse the results with regular expressions no problem,
That is a fragile approach, but is sometimes Good Enough.
> I read a little about WWW::Mechanize, is this the module you experts
> would recommend me to use?
perldoc -q form
How do I automate an HTML form submission?
If the FAQ recommends it, then you can assume that experts
recommend it without even asking any experts...
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Wed, 03 Mar 2010 09:00:18 +0000
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: Can you compile a perl executable?
Message-Id: <GpOdnSlBxsW_uBPWnZ2dnUVZ8l9i4p2d@brightview.co.uk>
Jürgen Exner wrote:
> Steve <steve@staticg.com> wrote:
>> If I made an application, and wanted to make it portable, is it
>> possible to compile it into a single binary?
>
> See "perldoc -q compile":
> "How can I compile my Perl program into byte code or C?"
>
> jue
I note that this perldoc appears to be happy
that B::Bytecode is the way to do this,
and yet the documentation for B::Bytecode
says
"
NOTICE
There are also undocumented bugs and options.
THIS CODE IS HIGHLY EXPERIMENTAL. USE AT YOUR OWN RISK.
"
Can anyone clarify how reliable/useable this compilation is?
BugBear
------------------------------
Date: Wed, 03 Mar 2010 12:06:48 -0000
From: Justin C <justin.0911@purestblue.com>
Subject: CGI html table generation
Message-Id: <2c38.4b8e50d8.e2207@zem>
I've spent many years just bodging my html with the CGI module. But now
I'm trying to do it properly and I'm happy with my progress so far. What
I am having trouble with is specifying cell widths (and therefore the
width of the entire column).
I'm creating tables like this:
print table({-border=>1},
Tr({-align=>'left', -valign=>'top'},
[
td([ "foo", "bar", "baz" ]),
td([ "eenie", "meenie", "minee" ]),
td({-colspan=>'3',-align=>'center'},[
submit('Upload') . " or " . reset('Clear')
])
]
)
);
I used to set my widths with <td width="20%"> (or whatever value), but
I see that that method is now deprecated, and that we should use styles.
If that is the case, how does one, using the above table creation
method, add styles per table cell, because, from the above it appears
that cell attributes can be set only for the entire row by putting,
after "td(", {-attribute=>'setting', -other_attr=>'setting'}.
Thank you for any help you can give with this.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Wed, 03 Mar 2010 07:16:25 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: CGI html table generation
Message-Id: <slrnhoso25.dk8.tadmc@tadbox.sbcglobal.net>
Justin C <justin.0911@purestblue.com> wrote:
> td([ "foo", "bar", "baz" ]),
> I used to set my widths with <td width="20%"> (or whatever value), but
> I see that that method is now deprecated, and that we should use styles.
> If that is the case, how does one, using the above table creation
> method, add styles per table cell,
td({-style => 'width: 20%'}, [ "foo" ]);
td({-style => 'width: 30%'}, [ "bar" ]);
td({-style => 'width: 50%'}, [ "baz" ]);
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Wed, 03 Mar 2010 15:08:02 +0000
From: RedGrittyBrick <RedGrittyBrick@spamweary.invalid>
Subject: Re: CGI html table generation
Message-Id: <4b8e7b53$0$2492$db0fefd9@news.zen.co.uk>
On 03/03/2010 13:16, Tad McClellan wrote:
> Justin C<justin.0911@purestblue.com> wrote:
>
>> td([ "foo", "bar", "baz" ]),
>
>> I used to set my widths with<td width="20%"> (or whatever value), but
>> I see that that method is now deprecated, and that we should use styles.
>> If that is the case, how does one, using the above table creation
>> method, add styles per table cell,
>
>
> td({-style => 'width: 20%'}, [ "foo" ]);
> td({-style => 'width: 30%'}, [ "bar" ]);
> td({-style => 'width: 50%'}, [ "baz" ]);
>
Ideally the styles would be specified in a separate CSS stylesheet
rather than embedded in the html markup.
I guess you need something like
td({-class => 'productname'}, [ "foo" ]);
td({-class => 'region'}, [ "bar" ]);
Apply the widths in your CSS stylesheet. E.g.
td.productname { width: 20%; }
<diversion>
Personally, whilst the CGI module has it's uses, I've not found it very
useful for HTML generation. After all you are still mixing your Perl
code with HTML. Things that are arguable better separated by using a
templating approach. Automatic tag completion (i.e. enforcement of very
basic HTML syntax conformance) is the only benefit I see over something like
print qq(<td class="productname">foo</td>);
The cost you pay for this benefit is the introduction of effectively a
third language. I've not been convinced it is worth it.
I do think CGI.pm is useful for handling the HTTP protocol, CGI
interface, decoding parameters etc.
</diversion>
--
RGB
------------------------------
Date: Wed, 3 Mar 2010 16:31:49 +0100
From: Helmut Richter <hhr-m@web.de>
Subject: Re: CGI html table generation
Message-Id: <Pine.LNX.4.64.1003031626040.4396@lxhri01.lrz.lrz-muenchen.de>
On Wed, 3 Mar 2010, RedGrittyBrick wrote:
> Personally, whilst the CGI module has it's uses, I've not found it very useful
> for HTML generation. After all you are still mixing your Perl code with HTML.
> Things that are arguable better separated by using a templating approach.
> Automatic tag completion (i.e. enforcement of very basic HTML syntax
> conformance) is the only benefit I see over something like
>
> print qq(<td class="productname">foo</td>);
>
>
> The cost you pay for this benefit is the introduction of effectively a third
> language. I've not been convinced it is worth it.
>
> I do think CGI.pm is useful for handling the HTTP protocol, CGI interface,
> decoding parameters etc.
I thinks so, too. Another thing I consider very useful is setting default
values for a new iteration of a form to the last values given by the
end-user, thus allowing returning a partially incorrectly filled-out form
to the user for correction and completion. This feature, however, requires
that the pertinent HTML text is generated by the functions of the CGI
module. Other HTML text may be interspersed that is directly written to
STDOUT.
--
Helmut Richter
------------------------------
Date: Wed, 3 Mar 2010 10:59:04 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: flushing buffer for printing to the screen
Message-Id: <slrnhoscn8.glf.hjp-usenet2@hrunkner.hjp.at>
On 2010-03-02 22:32, Uri Guttman <uri@StemSystems.com> wrote:
>>>>>> "PJH" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
>
> PJH> On 2010-03-02 19:29, Uri Guttman <uri@StemSystems.com> wrote:
> >>>>>>> "JE" == Jürgen Exner <jurgenex@hotmail.com> writes:
> JE> "efoss@fhcrc.org" <efoss@fhcrc.org> wrote:
> >> >> I want to be certain that a print statement is immediately executed.
> >> >> Googling around led me to use "$| = 1". Is this correct? Here is an
> >> >> example of how I'm using it:
> >> >>
> >> >> $| = 1;
> >> >> $test = 3;
> >> >> print "test is $test\n";
> >>
> JE> Yes, that is the correct use of $|.
> >>
> >> actually that never uses $| ! the print string ends in newline so it
> >> will always be flushed to stdout. $| is meant for when you print text
> >> without a newline (say a prompt or partial output or to a socket).
>
> PJH> No. When the file handle (here STDOUT) doesn't point to a tty, it is
> PJH> only flushed when the buffer is full not after each line.
>
> but as i keep posting, the code as shown goes to stdout and the tty
> unless he redirects it. it is obvious he is looking for the support of
> print to the terminal
Only because he wrote so in the subject ("printing to the screen"). I
admit that I didn't notice that when I first replied.
I don't think this is obvious from his code at all. As you already
noticed, his code does use a newline (so it's flushed) and it exits
immediately after the print (so it's flushed again).
> without a newline. that is almost the only real use for $|.
I almost never use it for that. Most of the time I use it to get line
buffering for file output (I.e., each print (or printf) writes a whole
line).
hp
------------------------------
Date: Wed, 3 Mar 2010 06:29:38 -0800 (PST)
From: Adam Kellas <adam.kellas@gmail.com>
Subject: Re: how to speed up a string-substitution loop?
Message-Id: <28817f21-cb87-4891-a948-b5e20562a6cb@b30g2000yqd.googlegroups.com>
On Mar 3, 12:12=A0am, "Uri Guttman" <u...@StemSystems.com> wrote:
> this isn't religion. there are plenty of religious wars on the net. this
> is about quality code. readability matters. it makes your code easier to
> understand, maintain, modify, etc. you may think this is cute and your
> style but most others don't. someone else posted the same thing. as for
> having / in the data, there is no way it is used that often. and regexes
> don't usually change on the fly too often. finally the best (and this
> comes from damian conway, among many others) alternate delimiter is
> {}. it allows nested pairs of {} inside without escaping, it is easy to
> see, it doesn't hide the regex itself. and you can even split the two
> parts of s{} =A0{} with spaces and it works.
I don't consider it cute, I consider it a convention. The value of a
convention or standard is independent of its objective right-ness.
Perhaps if I could go back in time I'd make some different choices,
but wouldn't we all? Though how you can argue that % is ugly while /
is not while explicitly rejecting the notion that it's an aesthetic
disagreement - and that "quality code" belongs to your side - is
beyond me. You might as well argue that yellow is uglier than blue.
I don't object to this line of discussion though. Perhaps you will
save some naive young person from the horrors of addiction to percent
signs. For me it's 15 years and thousands of lines of maintained code
too late.
> =A0 AK> Use of $_ was deliberate here because I gather it's marginally fa=
ster
> =A0 AK> and I was trying to tune the loop for speed. But in general I agr=
ee
> =A0 AK> that named variables are preferable.
>
> not fast enough to be worth it. we are talking minute speedups and your
> code has other issues. readibility and safety easily trump the miniscule
> speedup you may get in this case.
Really, we have no disagreement here. It's just that when one is
trying desperately to speed something up it's reasonable to try
everything you know of. What I posted was not a published, supported
piece of code, it was the result of a tuning exercise.
AK
------------------------------
Date: Wed, 03 Mar 2010 10:21:23 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: how to speed up a string-substitution loop?
Message-Id: <877hptph1o.fsf@quad.sysarch.com>
>>>>> "AK" == Adam Kellas <adam.kellas@gmail.com> writes:
AK> On Mar 3, 12:12 am, "Uri Guttman" <u...@StemSystems.com> wrote:
>> this isn't religion. there are plenty of religious wars on the net. this
>> is about quality code. readability matters. it makes your code easier to
>> understand, maintain, modify, etc. you may think this is cute and your
>> style but most others don't. someone else posted the same thing. as for
>> having / in the data, there is no way it is used that often. and regexes
>> don't usually change on the fly too often. finally the best (and this
>> comes from damian conway, among many others) alternate delimiter is
>> {}. it allows nested pairs of {} inside without escaping, it is easy to
>> see, it doesn't hide the regex itself. and you can even split the two
>> parts of s{} {} with spaces and it works.
AK> I don't consider it cute, I consider it a convention. The value of a
AK> convention or standard is independent of its objective right-ness.
AK> Perhaps if I could go back in time I'd make some different choices,
AK> but wouldn't we all? Though how you can argue that % is ugly while /
AK> is not while explicitly rejecting the notion that it's an aesthetic
AK> disagreement - and that "quality code" belongs to your side - is
AK> beyond me. You might as well argue that yellow is uglier than blue.
but convention implies many people doing it. you are the only one i have
ever seen (and i see tons of code) using % for a delimiter. so you are
not conventional but instead out of the norm. it is your convention and
others find it hard to read. you write code for others, not
yourself. get over yourself with this. you are wrong in conventional
ways.
AK> I don't object to this line of discussion though. Perhaps you will
AK> save some naive young person from the horrors of addiction to percent
AK> signs. For me it's 15 years and thousands of lines of maintained code
AK> too late.
you can always change style. i have many times over my career as i learn
better ways to code.
>> AK> Use of $_ was deliberate here because I gather it's marginally faster
>> AK> and I was trying to tune the loop for speed. But in general I agree
>> AK> that named variables are preferable.
>>
>> not fast enough to be worth it. we are talking minute speedups and your
>> code has other issues. readibility and safety easily trump the miniscule
>> speedup you may get in this case.
AK> Really, we have no disagreement here. It's just that when one is
AK> trying desperately to speed something up it's reasonable to try
AK> everything you know of. What I posted was not a published, supported
AK> piece of code, it was the result of a tuning exercise.
desperation is not a reason to try everything under the sun for
speedups. just applying the benchmark module is a saner way to find out
what is actually faster and by how much.
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, 3 Mar 2010 08:04:21 -0800 (PST)
From: Adam Kellas <adam.kellas@gmail.com>
Subject: Re: how to speed up a string-substitution loop?
Message-Id: <10643c09-3cf8-4e0d-b701-c61eb1b0b476@g26g2000yqn.googlegroups.com>
On Mar 3, 10:21=A0am, "Uri Guttman" <u...@StemSystems.com> wrote:
> >>>>> "AK" =3D=3D Adam Kellas <adam.kel...@gmail.com> writes:
> =A0 AK> Really, we have no disagreement here. It's just that when one is
> =A0 AK> trying desperately to speed something up it's reasonable to try
> =A0 AK> everything you know of. What I posted was not a published, suppor=
ted
> =A0 AK> piece of code, it was the result of a tuning exercise.
>
> desperation is not a reason to try everything under the sun for
> speedups. just applying the benchmark module is a saner way to find out
> what is actually faster and by how much.
OK, if you insist, we do have a disagreement. I will simply note that
the benchmark module is of little use when the code you're fixing is
so slow as to never finish.
AK
------------------------------
Date: Wed, 03 Mar 2010 11:09:31 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: how to speed up a string-substitution loop?
Message-Id: <87vdddo090.fsf@quad.sysarch.com>
>>>>> "AK" == Adam Kellas <adam.kellas@gmail.com> writes:
AK> On Mar 3, 10:21 am, "Uri Guttman" <u...@StemSystems.com> wrote:
>> >>>>> "AK" == Adam Kellas <adam.kel...@gmail.com> writes:
>> AK> Really, we have no disagreement here. It's just that when one is
>> AK> trying desperately to speed something up it's reasonable to try
>> AK> everything you know of. What I posted was not a published, supported
>> AK> piece of code, it was the result of a tuning exercise.
>>
>> desperation is not a reason to try everything under the sun for
>> speedups. just applying the benchmark module is a saner way to find out
>> what is actually faster and by how much.
AK> OK, if you insist, we do have a disagreement. I will simply note that
AK> the benchmark module is of little use when the code you're fixing is
AK> so slow as to never finish.
no, it is useful when you think using $_ will save you massive amounts
of time when it doesn't. so that will lead you to better coding style
and to focus on your real slowdown. also profiling modules will help
(even in code that never finishes) to find out where the time is spent.
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, 03 Mar 2010 08:42:02 -0800
From: sln@netherlands.com
Subject: Re: how to speed up a string-substitution loop?
Message-Id: <7k1to5d7tp00asdju65t606knjs9ibnfs3@4ax.com>
On Tue, 2 Mar 2010 08:39:16 -0800 (PST), Adam Kellas <adam.kellas@gmail.com> wrote:
>Hi,
>
>Looking for suggestions on how to speed up the function below. It's
>intended to "re-macroize" the output of make; in other words given a
>sequence of command lines generated by make, and a set of make macros,
>I need to substitute in the make variables such that "gcc -c -g -O2 -
>Wall -DNDEBUG" might become (say) "$(CC) -c $(CFLAGS) $(DFLAGS)", as
>much as possible as it was in the original Makefile. The %Variables
>hash maps strings to macro names; thus with the above example we would
>have
>
> $Variables{'gcc'} = '$(CC)';
> $Variables{'-g -O2 -Wall'} = '$(CFLAGS)';
> $Variables{'-DNDEBUG'} = '$(DFLAGS)';
>
>Anyway, the function below seems to work but scales very badly and
>becomes unusable when enough variables are in use. Any ideas on how to
>write it better?
>
>sub varify {
> my $word = shift;
> $word =~ s%\$%\$\$%g;
> for my $substr (keys %Variables) {
> while ((my $start = index($word, $substr)) >= 0) {
> substr($word, $start, length($substr)) = $Variables{$substr};
> }
> }
> return $word;
>}
>
>Thanks,
>AK
Just a comment that no where is it written that you can reconstruct
variables from the output of variable substitution.
$(a) = a
$(b) = -b$(a)
cc a.obj $(b) ab.obj ->
cc a.obj -ba ab.obj
----
cc a.obj -ba ab.obj ->
cc $(a).obj -b$(a) $(a)b.obj ->
cc $(a).obj $(b) $(a)b.obj != cc a.obj $(b) ab.obj
Even if you could be guaranteed distinction in the final
output, the order in which you do the reverse substitution
has to start from the first variable defined and progress
to the last defined, ie: FIFO.
This means you can't use a hash, which is random and can't
be fifo. Instead you have to store the pseudo variables and
thier data in an array:
@Variables = (
'$(a)' , 'a',
'$(b)' , '-b$(a)',
);
then read each pair as you progress down the list.
Then, to be complete, you have to repeat the substitution
reconstruction process as many times as the deepest nesting
of the $Variables. This could be acomplished by repeating
until there is no difference between the old and new strings.
But, if you can overcome these hurdles, you might get a
broken up static snapshot of makefile state, which can
dynamically generate multiple states.
In this case it would be:
$(a) = a
$(b) = -b$(a)
cc $(a).obj $(b) $(a)b.obj
(but this was designed to fail)
-sln
------------------------------
Date: Wed, 03 Mar 2010 09:10:17 -0800
From: sln@netherlands.com
Subject: Re: how to speed up a string-substitution loop?
Message-Id: <hj4to59f57vlcf7uomge9jkki1ei5u6lph@4ax.com>
On Wed, 03 Mar 2010 08:42:02 -0800, sln@netherlands.com wrote:
>On Tue, 2 Mar 2010 08:39:16 -0800 (PST), Adam Kellas <adam.kellas@gmail.com> wrote:
>
>>Hi,
>>
>>Looking for suggestions on how to speed up the function below. It's
>>intended to "re-macroize" the output of make; in other words given a
>>sequence of command lines generated by make, and a set of make macros,
>>I need to substitute in the make variables such that "gcc -c -g -O2 -
>>Wall -DNDEBUG" might become (say) "$(CC) -c $(CFLAGS) $(DFLAGS)", as
>>much as possible as it was in the original Makefile. The %Variables
>>hash maps strings to macro names; thus with the above example we would
>>have
>>
>> $Variables{'gcc'} = '$(CC)';
>> $Variables{'-g -O2 -Wall'} = '$(CFLAGS)';
>> $Variables{'-DNDEBUG'} = '$(DFLAGS)';
>>
>>Anyway, the function below seems to work but scales very badly and
>>becomes unusable when enough variables are in use. Any ideas on how to
>>write it better?
>>
>>sub varify {
>> my $word = shift;
>> $word =~ s%\$%\$\$%g;
>> for my $substr (keys %Variables) {
>> while ((my $start = index($word, $substr)) >= 0) {
>> substr($word, $start, length($substr)) = $Variables{$substr};
>> }
>> }
>> return $word;
>>}
>>
>>Thanks,
>>AK
>
>Just a comment that no where is it written that you can reconstruct
>variables from the output of variable substitution.
>
>$(a) = a
>$(b) = -b$(a)
When checking if the value is in the target,
there must be a check that the value itself
is not a variable name.
'this is the t$(a)rget '
^
Found value 'a' here.
Aviod substitution if its part of a variable name,
enclosed with $().
$target =~ s/ \$\(.*?\) \K | ($value) / defined $1 ? $varname : '' /xeg;
Probably in the simplese cases, this will never happen, but its possible.
-sln
------------------------------
Date: Wed, 3 Mar 2010 02:36:56 -0800 (PST)
From: Robin <robin1@cnsp.com>
Subject: ruby com-piler that worked
Message-Id: <fe9fbca6-e8c2-442f-b8f2-8c066d2f3513@a18g2000yqc.googlegroups.com>
http://rubygems.org/gems/ocra
I found this ruby to exe compiler and it seems to work. Enjoy.
-Robin
------------------------------
Date: Wed, 03 Mar 2010 11:18:50 -0600
From: darkon <darkon.tdo@gmail.com>
Subject: Re: strange behavior
Message-Id: <Xns9D307D446662Adarkon@216.168.3.30>
Ben Morrow <ben@morrow.me.uk> wrote:
> I wouldn't recommend AS Perl for Mac OS (or Win32 nowadays,
> for that matter).
Why is that? I've been using AS on Win32 for about 10 years now. Is
Strawberry Perl now the recommended package for Windows?
(Kind of a moot point for me, at least at work: Activestate Perl is
the only one we're currently allowed to use.)
------------------------------
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 2847
***************************************
