[6642] in Perl-Users-Digest
Perl-Users Digest, Issue: 267 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Apr 10 06:07:34 1997
Date: Thu, 10 Apr 97 03:01:29 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 10 Apr 1997 Volume: 8 Number: 267
Today's topics:
Re: Reply to Ousterhout's reply (was Re: Ousterhout and (James Logajan)
Re: Reply to Ousterhout's reply (was Re: Ousterhout and <steve@srsuna.shlrc.mq.edu.au>
Re: Reply to Ousterhout's reply (was Re: Ousterhout and <erik@naggum.no>
Re: Reply to Ousterhout's reply (was Re: Ousterhout and <graham.matthews@maths.anu.edu.au>
Re: Reply to Ousterhout's reply (was Re: Ousterhout and <graham.matthews@maths.anu.edu.au>
Re: Reply to Ousterhout's reply (was Re: Ousterhout and (cosc19z5@bayou.uh.edu)
Starting and stopping non-perl sub-process of a child <dorman@s3i.com.anti-spam>
Re: Unix and ease of use (WAS: Who makes more ...) (Ryurick M. Hristev)
Re: Unix and ease of use (WAS: Who makes more ...) (Hume Smith)
Re: Who makes more $$ - Windows vs. Unix programmers? (Kaz Kylheku)
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 10 Apr 1997 03:46:22 GMT
From: jamesl@netcom.com (James Logajan)
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Message-Id: <jameslE8EL5A.vF@netcom.com>
John Ousterhout (ouster@tcl.eng.sun.com) wrote:
: Every single programmer who ever wrote a program in Tcl, Perl, C++, Visual
: Basic, or even C could have chosen Lisp, Scheme, or Smalltalk. But they
: didn't.
Others have responded to this point adequately; however, I just happen to be
working on a product that is going to require a scripting or extension
language. We get to pick our own language (for once). Our short list includes:
Lua
Python
Perl
Tcl
I have not used any of these before, so have "fresh eyes" on our team. We
need a language that is easy for beginners to pick up, that is not too
slow, handles string processing well, has a small memory footprint, and
is of course extensible. OOP support was considered important, but not
vital.
So far, Lua is winning, with Python still in the running because of its
stronger OO support. Tcl is horribly slow with no particular feature
that compensates for its sluggishness. Perl seems too syntactically unruly
for people to get a good grip on how best to compose their work but has
about the same speed as Python.
Lua is about 1/10 the size of the others (~70k versus ~1000k for all the
others on a Sparc) and is several times faster than Python and Perl. Tcl
is an order of magnitude (10, not 2!) slower than Python/Perl.
It is too bad that Lua doesn't have its own newsgroup (yet?). I was
pleasantly surprised by the small size, fast speed, simple syntax, and
powerful semantics of the language.
------------------------------
Date: 10 Apr 1997 13:36:32 +1000
From: Steve Cassidy <steve@srsuna.shlrc.mq.edu.au>
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Message-Id: <yoiv1v8s73.fsf@sputnik.shlrc.mq.edu.au>
> As for Tcl, it's there for one reason and one reason only -- strong
> corporate backing. We've got a powerful company that wants to
> make a quick buck and therefore is using its clout to force
> Tcl down our throats. This is the same tactic used by charlatans
> like Micro$oft. Indeed that's the only possible explanation
> as to why a glorified text preprocessor would even get a second
> look -- that and the fact that it is riding on the coattails
> of Tk.
Many people, myself included, started using tcl/tk before Sun took it
up. Remember that this is a free tool, which for my purposes is very
important. The current corporate backing is certainly seeking to
extend the user base of tcl/tk but, I would imagine, a vast proportion
of the current code base would still be there if Sun hadn't taken over.
My own decision to use tcl was based on easy embedding in my code and
the presence of Tk. I'm no great fan of the language but it is wrong
to compare Sun with Microsoft in this manner -- microsoft is unlikely
to give you the source of VB or port it to unix.
--
Steve Cassidy
Speech, Hearing and Language Research Center
School of English Linguistics and Media
Tel: +61 2 9850 8729 Macquarie University
Fax: +61 2 9850 8240 North Ryde,NSW, 2109
steve@srsuna.shlrc.mq.edu.au Australia
http://srsuna.shlrc.mq.edu.au/~steve
------------------------------
Date: 09 Apr 1997 23:37:10 +0000
From: Erik Naggum <erik@naggum.no>
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Message-Id: <3069617830783259@naggum.no>
* John Ousterhout
| Every single programmer who ever wrote a program in Tcl, Perl, C++,
| Visual Basic, or even C could have chosen Lisp, Scheme, or Smalltalk.
| But they didn't.
yeah, this is a _really_ ingenious argument. let's look at the operating
word here, "could". how do people choose languages? do they pick them out
of the blue? or do they pick languages according to hype, marketing,
availability, perceived proximity to known languages, etc? it should be
pretty darn obvious that they don't choose languages they don't "know".
C++ won because it was "a better C", then, as people got more into it, it
grew to become a behemoth of a language. perl was a cute little thing that
combined several of the silly little Unix languages into one language and
added a few cute improvements. then it got cancer and grew to become an
enormous _implementation_ of a largely unspecified language, just like its
predecessors. now, tcl is not really language, either, just as the Bourne
shell, awk, sed, etc, are not languages. they are just tools in a toolbox.
languages have more than one implementation. perl doesn't. does Tcl?
the Distinguished Professor of Computer Science has turned into a Marketing
Droid. how incredibly sad.
| If you want to know the truth, I think you need to stop making
| superficial excuses and ask deeper semantic questions.
the way I read this debate, people are asking deep, semantic questions of
Tcl and they get superficial excuses for answers.
| There really is something better about each of these "ugly languages"
| that gives them an advantage over the "good" languages; I'll leave it up
| to you to figure out what it is.
one word: novelty. for some reason, immature people prefer a new language
over an existing language when they are presented with one new and one old.
unformed people delight in the gaudy and in novelty.
cooked people delight in the ordinary.
#\Erik
--
I'm no longer young enough to know everything.
------------------------------
Date: Thu, 10 Apr 1997 09:14:28 +1000
From: Graham Matthews <graham.matthews@maths.anu.edu.au>
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Message-Id: <334C22D4.EB8@maths.anu.edu.au>
Graham Matthews <graham.matthews@maths.anu.edu.au> writes:
> |> There is a much simpler reason why all these ugly languages about -- its
> |> called intertia. There was a lot of code written in the 70s in ugly
> |> languages -- written before we knew how to make good languages. All that
> |> code has to be supported, interfaced to, etc, so all the ugly languges
> |> it is written in are now the standard. Simple.
John Ousterhout wrote:
> Sorry, but this doesn't really make sense. For example, if "ugly languages"
> refers to Tcl or Perl or C++, none of these languages even existed in the
> 1970s. In contrast, various flavors of Lisp have been around since at least
> the early 60's and Smalltalk first appeared in the late 60's.
I didn't say that every language designed in the 60s or 70s was bad. Nor
did I say anything about every language designed since the 60s and 70s.
So your argument falls flat.
John Ousterhout wrote:
>Every single
> programmer who ever wrote a program in Tcl, Perl, C++, Visual Basic, or even
> C could have chosen Lisp, Scheme, or Smalltalk. But they didn't.
Yep and the probable reason they didnt was that they had to interface to
some existing code already written in one of these languages. Or (in the
case of Perl) they wanted to do something very specific and found the
language in question excellent for that.
John Ousterhout wrote:
> If you
> want to know the truth, I think you need to stop making superficial excuses
> and ask deeper semantic questions. There really is something better about
> each of these "ugly languages" that gives them an advantage over the "good"
> languages; I'll leave it up to you to figure out what it is.
So far I have yet to see something better about these "ugly languages".
As far as I can see people have quite effectively rebutted all the
points you made in your white paper, and subsequently on newsnet. For
example you mentioned how concise Tcl code was to interface to Tk. But
then someone posted a more concise piece of TkGofer code that did the
same thing. etc etc etc
graham
--
The girls is all salty, the boys is all sweet,
the food ain't too shabby
an' they piss in the streets
In France, way down in France, way on down, way on down in France
------------------------------
Date: Thu, 10 Apr 1997 09:08:06 +1000
From: Graham Matthews <graham.matthews@maths.anu.edu.au>
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Message-Id: <334C2156.116D@maths.anu.edu.au>
Graham Matthews wrote:
> > The argument is flawed. Smalltalk is in fact widely used in commercial
> > programming. So your nice separation into "ugly but used" vs "elegant
> > and academic" is false. Moreover Java is taking off commercially and yet
> > it is essentially a subset of Smalltalk.
Smiljan Grmek wrote:
> Sorry, Smalltalk is infinitesimaly used. There is an ongoing drive by
> IBM (of all companies!) but with little sucess. This can easily be
> verified if you look at job offerings on the Net with Smalltalk as
> keyword.
Unfortunately looking at the Net job offering is not the gospel truth.
I'll give you a hint. Go read up how many software servers were written
in Smalltalk (before the advent of Java).
Smiljan Grmek wrote:
> And it is hard to discuss computer languages with someone who can
> seriously entertain the thought that 'Java is a *subset* (of all
> possible relationships!) of Smalltalk!'
But on many fronts Java is a subset of Smalltalk, both linguistically
and implementationally. The most obvious example is the Java virtual
machine that everyone is praising as the best thing since slice bread.
Smalltalk (and other languages) have had virtual machines for years.
> So now we know how to make *good* languages - like good indians?
> Seriously, languages must be designed for average, garden variety of
> programmers, not CS graduates.
What rubbish. You can train people to use a modern language just like
you can and do train them to use an older language. The "oh these new
languages are too hard to learn for Joe average programmer" just doesn't
stand up. How can a language with no pointers, no explicit memory
alloc/dealloc, etc be harder to learn than one where you have to do all
that yourself ...
>US DOD stated that conversion to parallel
> processing is not advisable because only 1/3 of their programmers could
> program in appropriate languages.
Indeed! And good programming languages do the conversion for the
programmer. Exactly my point.
graham
--
The girls is all salty, the boys is all sweet,
the food ain't too shabby
an' they piss in the streets
In France, way down in France, way on down, way on down in France
------------------------------
Date: 10 Apr 1997 00:03:33 GMT
From: cosc19z5@Bayou.UH.EDU (cosc19z5@bayou.uh.edu)
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Message-Id: <5ihaol$n3g@Masala.CC.UH.EDU>
John Ousterhout (ouster@tcl.eng.sun.com) wrote:
: In article <334B68EC.3F66@maths.anu.edu.au>, Graham Matthews <graham.matthews@maths.anu.edu.au> writes:
: |>
: |> There is a much simpler reason why all these ugly languages about -- its
: |> called intertia. There was a lot of code written in the 70s in ugly
: |> languages -- written before we knew how to make good languages. All that
: |> code has to be supported, interfaced to, etc, so all the ugly languges
: |> it is written in are now the standard. Simple.
: Sorry, but this doesn't really make sense. For example, if "ugly languages"
: refers to Tcl or Perl or C++, none of these languages even existed in the
: 1970s.
Sounds like you need to review your history of languages. C++, while
not existing in the 70s, was designed to be a superset of a language
that was -- you get three guesses as to which language that is. Therefore
C++ _IS_ a product of inertia.
As for Perl and Tcl, they seem very "shell-like" to me, so I'm tempted
to say that they are also a product of inertia from that direction,
but someone with more knowledge in these particular languages would
do well to answer that issue, and also perform appropriate dating
as to the age of the predecessors of those 2 languages.
: In contrast, various flavors of Lisp have been around since at least
: the early 60's and Smalltalk first appeared in the late 60's.
I was under the impression that Smalltalk first appeared in the early
70s.
: Every single
: programmer who ever wrote a program in Tcl, Perl, C++, Visual Basic, or even
: C could have chosen Lisp, Scheme, or Smalltalk.
Here you show a grievous lack of common sense that goes well with your
lack of knowledge about language-history. The only programmers who
would be able to choose Lisp, Scheme, or Smalltalk are those who
would have known that those languages existed, and you would be
surprised at how many people do _NOT_ know they exist. I ran into
these languages because I was _ACTIVELY_ looking for languages,
this is the same reason I ran into Haskell (my favorite language).
Consider the average programmer who does not actively look for
new languages, but sits on her/his tail until some organization
hypes a marginal package as The Next Big Thing(tm), and then
proceeds to swallow it up. That's how crappy products become
big. That's the story of Tcl.
Many of the programmers I spoke with have very little if any knowledge
about the above languages, how can you even claim that they prefer
the languages they are using over the above ones?
Furthermore remember that most programmers program in the language
mandated by their employers -- I am the same way. We don't have
a choice most of the time.
: But they didn't. If you
: want to know the truth, I think you need to stop making superficial excuses
: and ask deeper semantic questions.
I think you need to wake up and smell the coffee. There are numerous
reasons why these superior languages were not chosen, the fact that
you are grasping at one flimsy reason does nothing but make one wonder
if you even have a clue.
: There really is something better about
: each of these "ugly languages" that gives them an advantage over the "good"
: languages; I'll leave it up to you to figure out what it is.
Let's see, C became popular for one reason only -- it was almost
mandatory for programming under Unix which was widespread (and
still is). So C rode on the coattails of an operating system, and
was not chosen on any virtue of the language itself. C++ is
popular for one reason only -- it isn't a far step away from C which
means that the C crowd flock to it in safety. So C++ rode on the
coattails of C which rode on the coattails of Unix.
Perl I could give some credit for -- it is a powerful tool although
its resemblence to shell scripting is still an issue which I feel
has helped it gain more acceptance. It's a lot easier to accept
something that looks familiar than something that looks foreign
(which explains why Lisp languages and Smalltalk didn't gain the
following that C and C++ did).
As for Tcl, it's there for one reason and one reason only -- strong
corporate backing. We've got a powerful company that wants to
make a quick buck and therefore is using its clout to force
Tcl down our throats. This is the same tactic used by charlatans
like Micro$oft. Indeed that's the only possible explanation
as to why a glorified text preprocessor would even get a second
look -- that and the fact that it is riding on the coattails
of Tk.
Try to come up with some arguments next time.
--
Cya,
Ahmed
------------------------------
Date: 09 Apr 1997 15:54:07 -0400
From: Clark Dorman <dorman@s3i.com.anti-spam>
Subject: Starting and stopping non-perl sub-process of a child
Message-Id: <du3lg9dls.fsf@s3i.com>
Greetings again,
I'm still trying to understand stopping a child and/or sub-process
when I want to. What I'm doing is forking a process, the parent has the pid
of the child and sends a STOP signal if the cpu load gets too high. That
works fine when what the child is doing is self-contained (i.e. its actually
the perl program taking up the cpu. See below for the program, stopper2.pl ).
[I'm on a Sun SparcStation 2, Solaris 5.5, perl version 5.003, under csh]
What I want to do in the child is to run a C program, and that
program too should stop when I send a stop to the child, shouldn't it?
That's what happens when I do it from the terminal, I think. It seems that a
process and all it's children stop when I hit Cntl-Z. When I do a kill
'STOP', $pid from the parent (and $pid is the child), nothing happens: the
child keeps going, and the child's process (the C program) keeps going:
% stopper.pl
In the parent, pid of child is 21307
In the child
stopping the child (1.04)
[
from another window, I see:
PID PPID S COMMAND
21306 18942 S /home/dorman/bin/perl -w stopper.pl
21307 21306 S /home/dorman/bin/perl -w stopper.pl
21313 21307 O time_waster
So, 21306 is the parent, 21307 is the child. 21307 created a process 21313,
the C program I want to run. Note that even though the program sent a stop
signal to the child, it is sleeping (Status = S), not stopped (Status=T).
The time_waster is taking up a cpu.
]
^Z
[ everything stops:
PID PPID S COMMAND
21306 18942 T /home/dorman/bin/perl -w stopper.pl
21307 21306 T /home/dorman/bin/perl -w stopper.pl
21313 21307 T time_waster
]
----------------------------------------------------------------------
When I do a similar thing but the child is entirely a perl script, the
process stops nicely.
% stopper2.pl
In the child
In the parent, pid of child is 23484
stopping the child (1.51) (23484)
[
PID PPID S COMMAND
23483 17752 S /home/dorman/bin/perl -w stopper2.pl
23484 23483 T /home/dorman/bin/perl -w stopper2.pl
]
restarting the child (1.49)
[
PID PPID S COMMAND
23483 17752 S /home/dorman/bin/perl -w stopper2.pl
23484 23483 O /home/dorman/bin/perl -w stopper2.pl
]
----------------------------------------------------------------------
Here is the perl program that I'm using, called stopper.pl. The difference
between stopper.pl and stopper2.pl is that different time wasting programs
are commented out.
#!/home/dorman/bin/perl -w
$pid = fork;
$my_hostname = `hostname` or die "Cannot find hostname ($!)";
$load_limit = 0.5;
if ($pid > 0) { # parent
print " In the parent, pid of child is $pid \n";
$childRunning = 1;
$childActive = 1;
while ($childRunning ) {
############################################################
# check load
$rup_response = `rup $my_hostname 2>&1` ;
if ( $rup_response =~ /average:\s(\d+.\d+),/ ) {
$load_level = $1;
} else {
die "Something wrong with rup_response ($rup_response)";
}
############################################################
# stop if load level too high and it's active
if ($load_level > $load_limit and $childActive) {
print " stopping the child ($load_level) ($pid)\n";
kill 'STOP', $pid;
$childActive = 0;
}
if ($load_level < $load_limit and ! ($childActive) ) {
print " restarting the child ($load_level)\n";
kill 'CONT', $pid;
$childActive = 1;
}
sleep 1;
############################################################
# Do stuff.
$psResponse = `/usr/bin/ps -p $pid` or die
"cannot do a ps on the process ($!)";
# print " ps response is ($psResponse) \n";
exit(0) if ($psResponse =~ /defunct/);
}
}
elsif ($pid == 0) {
print " In the child \n";
&do_the_work(); # we're the child
print " child done, exiting ------------------------------\n";
$childRunning = 0;
exit(0);
}
else {
# fork failed
die "child process failed \n";
}
######################################################################
# This is a dummy task that just wastes time.
# Uncomment this to make stopper2.pl
#
# sub do_the_work {
# for ($j=0; $j<100000; $j++) {
# $result = 0;
# for ($i=1; $i<= 1e12; $i *= 7) {
# $result = &commas( $i );
# }
# }
# }
#
#sub commas {
# local( $_) = @_;
# 1 while s/(.*\d)(\d\d\d)/$1,$2/;
# $_;
#}
######################################################################
# This is a dummy task that just wastes time.
# Comment this out (and uncomment above) to make stopper2.pl
sub do_the_work {
system('time_waster');
}
# In case you care, time_waster.c is the following:
#
#include <stdio.h>
#
#main() {
# double x, M, N, d, y , z, A;
# double px, py, pm1, pm2, pm3, asdf;
#
# N = 250.;
#
# for ( asdf = 0; asdf < 100000; asdf++) {
# for ( d = 0.99; d>0.; d-= 0.1) {
# for ( M = 1; M <= N; M++) {
# A = ( 2*M*d - N*d +N ) ;
# pm3 = (N-N*d*d)/( A * ( A-2*d) );
# }
# }
# }
#}
### end stopper.pl #######################################################
I would really appreciate it if someone could help me with this. Do I need
to stop the subprocesses by pid, and what is a good way to get the pid's back
to the parent?
Clark
------------------------------
Date: 10 Apr 1997 09:38:08 +1200
From: physrmh@ANTISPAMphys.canterbury.ac.nz (Ryurick M. Hristev)
Subject: Re: Unix and ease of use (WAS: Who makes more ...)
Message-Id: <qv63esz3min.fsf@phys.canterbury.ac.nz>
"Tim Behrendsen" <tim@a-sis.com> writes:
> But I don't even need to go there. Name one freely available
> *significant* product that is *clearly* better than *any* commercial
> product, regardless of price. There are some good programs of limited
> size that are not worth a commercial entity rewriting (some may
> say Emacs, but I wouldn't...), but I mean products of significant
> size and complexity.
TeX
--
Delete ANTISPAM to reply. Apologies for inconvenience. (Spam,Grrrrr :)
______________________________________________________________________
Ryurick M. Hristev ()..()/^\/^\ -<:-)
physrmh@ANTISPAMphys.canterbury.ac.nz \/ \#/\#/\) What opinions ?
______________________________________________________________________
------------------------------
Date: 10 Apr 1997 00:17:28 GMT
From: hclsmith@tallships.istar.ca (Hume Smith)
Subject: Re: Unix and ease of use (WAS: Who makes more ...)
Message-Id: <5ihbio$7c@news.istar.ca>
>Tim Behrendsen (tim@a-sis.com) wrote:
>: I didn't say that there weren't good, or even excellent free
>: products around. I said name one that is better than *ANY*
>: commercial software, *REGARDLESS* of price, and of sufficient
>: complexity.
i suspect, no matter what we suggest, you'd say it was either not complex
enough or not good enough; they're pretty damn subjective.
nevertheless: "gcc", and note pruned newsgroups and followups.
------------------------------
Date: 9 Apr 1997 20:37:05 GMT
From: kaz@vision.crest.nt.com (Kaz Kylheku)
Subject: Re: Who makes more $$ - Windows vs. Unix programmers?
Message-Id: <5igulh$kal@bcrkh13.bnr.ca>
In article <slrn5knqq6.87o.darin@connectnet1.connectnet.com>,
Darin Johnson <darin@usa.net.delete_this_part> wrote:
>>>The fact that UNIX is a pun on Multics is no urban legend, but a simple
>>>historic fact. If you don't believe Lawrence Kirby, please write mail to
>>>Brian Kernighan.
>>
>>Doesn't the term 'pun' imply that you can infer multiple meanings? A
>>UNIfied eXecutive is a good description of unix.
>
>Um, the "pun" is on "Eunuchs" and "MULTICS". UNIfied eXecutive is
>just a figment of someone's imagination. There is good documentation
True. You can't infer meanings that weren't implied in the original pun.
To do so is a case of wishful historic revisionism. :)
>for this.
The use of the term ``executive'' to mean ``kernel'' is quite foreign to the
UNIX culture. Unified Executive can rougly translate to Monolithic Kernel, I
suppose. In any case, the word ``executive'' has a nasty corporate ring to it,
and is hence repulsive to the long-haired, bearded, dope-smoking, Jesus Christ
look-alike true UNIX hackers clad in denim.
------------------------------
Date: 8 Mar 97 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 8 Mar 97)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V8 Issue 267
*************************************
