[28080] in Perl-Users-Digest
Perl-Users Digest, Issue: 9444 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jul 10 11:06:05 2006
Date: Mon, 10 Jul 2006 08:05:04 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 10 Jul 2006 Volume: 10 Number: 9444
Today's topics:
Re: converting line input into columns <tadmc@augustmail.com>
Re: converting line input into columns <tadmc@augustmail.com>
Re: converting line input into columns <tadmc@augustmail.com>
Re: Get the reference to an array from a function... <sgt19@tid.es>
Re: Hangman <weberw@adelphia.net>
Inline missing with ActiveState? <bol@adv.magwien.gv.at>
madrid perl hackers, where are you? <sgt19@tid.es>
Re: Problem converting euro from windows-1252 to UTF-8 <bart@nijlen.com>
Re: Problem converting euro from windows-1252 to UTF-8 <nevosa@gmail.com>
Re: Problem converting euro from windows-1252 to UTF-8 <rvtol+news@isolution.nl>
Re: Profanity checking, phonetically. <shrike@cyberspace.org>
Re: Profanity checking, phonetically. <sgt19@tid.es>
Re: Spreadsheet::[Parse|Write]Excel - accessing the con <justin.0511@purestblue.com>
Re: What is a type error? <marshall.spight@gmail.com>
Re: What is a type error? <marshall.spight@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 10 Jul 2006 07:19:55 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: converting line input into columns
Message-Id: <slrneb4hfb.3kb.tadmc@magna.augustmail.com>
axel@white-eagle.invalid.uk <axel@white-eagle.invalid.uk> wrote:
> The format of the data given here does not match the format as given
> in your original posting. Applying the posted script against data
> in a different format means it will not provide the required
> results.
>
> Instead it wastes people's time.
Hence, it is an abuse of those people.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 10 Jul 2006 07:28:20 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: converting line input into columns
Message-Id: <slrneb4hv4.3kb.tadmc@magna.augustmail.com>
vanagas99@yahoo.com <vanagas99@yahoo.com> wrote:
> There is no reason for Tad to give a speach, either.
So you wouldn't say anything when someone takes cuts in line
in front of you?
In article <1995Nov9.193745.13694@netlabs.com>, lwall@netlabs.com
(Larry Wall) wrote: ...
[snip] I view a programming language as a place to be
explored, like Disneyland. You don't need to have a lot of preparation
to explore a theme park. You do have to go along with the crowd
control measures, though. In a sense, each ride has its own
prerequisites--if you cut in line, you risk getting tossed out of the
park.
What we have here in this newsgroup is a failure in crowd control.
Reading the FAQ is like staying in line--it's something you should
learn in kindergarten. Usenet needs a better kindergarten.
I was being a (pretty gruff) kindergarten teacher.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 10 Jul 2006 08:12:22 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: converting line input into columns
Message-Id: <slrneb4khm.3n5.tadmc@magna.augustmail.com>
vanagas99@yahoo.com <vanagas99@yahoo.com> wrote:
>
> A. Sinan Unur wrote:
>> vanagas99@yahoo.com wrote in
>> news:1152496902.511701.167670@p79g2000cwp.googlegroups.com:
>>
>> >
>> > Tad McClellan wrote:
>> >> vanagas99@yahoo.com <vanagas99@yahoo.com> wrote:
>> >>
>> >> > sorry,
>> >>
>> ...
>>
>> >> It is pretty clear that your "sorry" is not at all sincere,
>> > Great addition to my perl learning experience.....
You do not have a Perl learning experience.
If you did, you would have posted the Perl that you've learned,
and we would have helped you fix it.
You have a "fix my program for me" experience.
> I didn't even know what
> "posting on top" means...
So you didn't even know what you you were apologizing for then?
> plus, blabing about the sincerity of my
> "sorry"???
Appearing to apologize while not even knowing what it is about
is pretty clearly insincere.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 10 Jul 2006 16:35:05 +0200
From: Stephan Titard <sgt19@tid.es>
Subject: Re: Get the reference to an array from a function...
Message-Id: <e8toih$i7d7@news.hi.inet>
David Squire escribió:
> Paul Lalli wrote:
>> Sherm Pendley wrote:
>>> "Paul Lalli" <mritty@gmail.com> writes:
>>>
>>>> David Squire wrote:
>>>>>> 2. return @arr,
>>>>> In this case test() returns a *list*, which contains the elements that
>>>>> are stored in the array @arr, but it is not the same thing as @arr
>>>> That's not strictly true.
>>> Actually, it is - ask any XS programmer. If you attempt to return an
>>> array
>>> or hash from a sub, what perl pushes onto the stack is a list of
>>> SV*s, not
>>> the AV* or HV* itself.
>>
>> Poor choice of response on my part. My point was intended to be that
>> simply saying "return @arr" does not guarantee that any of the items
>> contained in @arr are going to end up in the variable(s) that are
>> assigned to the subroutine call. If the call itself is in scalar
>> context, then @arr is evaluated in scalar context. I have not yet read
>> the documentation you pointed me to, so I can only assume that in this
>> case, the list returned from the subroutine is infact a list containing
>> one element - the size of @arr.
>>
>
> True, and, to me, surprising. This implies that the subroutine knows the
> context in which it was called, which seems to me to break all sorts of
> principals of encapsulation, low coupling, etc.
>
>
> DS
but it is *not* actually, context is forced on the subroutine (it
propagates down the call chain if you are not playing tricks -- magic
goto, etc...), and the only thing the sub can do is decide what to do
according to context...
it is good practice to design your sub the have a sensible return
according to context
Also, Contextual::Return is worth a look.
hth
--stephan
------------------------------
Date: 10 Jul 2006 07:46:20 -0700
From: "weberw@adelphia.net" <weberw@adelphia.net>
Subject: Re: Hangman
Message-Id: <1152542780.340894.168240@m73g2000cwd.googlegroups.com>
Thanks for answering my quesiton. The correct syntax to populate
%guesses would be what?
axel@white-eagle.invalid.uk wrote:
> weberw@adelphia.net <weberw@adelphia.net> wrote:
> > Can someone help with my code? When the user enters "c" in the text
> > box it fills in c_ _, which is great. But when they enter the next
> > letter, like "a". It erases the c_ _ and produces _ a _. I need to
> > keep it to be ca_. Also how do you get the number of wrong guesses in
> > a string? Example, j,l,u,v etc.so the user knows the letters they have
> > entered?
>
> > #!C://Perl/bin/perl
>
> use strict;
> use warnings;
>
> > use CGI ':standard';
> > use CGI::Carp 'fatalsToBrowser';
> > use constant MAX_MISSES => 8;
>
> > &display();
>
> There is no need to use & when calling a subroutine unless you know why
> you need it.
>
> > my $word;
> > $word = "cat";
> > my $misses_left = MAX_MISSES;
> > my %letters = map {$_ => 1} split //, $word;;
> > my %guesses = ();
>
> At this point %guesses has no entries. So all previous 'guesses' have
> been lost as that information has not been retained.
>
> This information easily be retained by passing it back in the form as a
> hidden element.
>
> > if (param()) {
> >
> > my $guess = param('guess');
> > &processguess($guess);
>
> >
> > sub processguess{
>
> > if (exists $guesses{$guess}) {
> > print qq(You\'ve already guessed "$guess".\n);
> > }
>
> This code will never be executed as %guesses is empty.
>
> > $guesses{$guess}++;
>
> > if (exists $letters{$guess}) {
> > delete $letters{$guess};
> > keys %letters or last GUESSES;
>
> You don't specify a label GUESSES.
>
> > } else {
> > --$misses_left;
> > print "another";
>
> I'm afraid the purpose of this print escapes me.
>
> > }
> > if ($misses_left > 0)
> > {
> > print "Your guess is: ", join(' ', sort keys %guesses), "\n";
> > print "You have $misses_left misses left.\n\n";
> > print join(' ', map {exists $guesses{$_} ? $_ : '_'} split //,
> > $word), "\n";
> > my $guess;
> >
> > }
> >
> > }
> > }
> > }
>
> One too many right-braces here.
>
> > sub display {
>
> > my $the_cookie = cookie (
> > -name=>'gameid',
> > -value=>$id,
>
> $id is never defined. Using warnings would have told you that.
>
> > [snip]
>
>
> Axel
------------------------------
Date: Mon, 10 Jul 2006 13:18:47 +0200
From: "Ferry Bolhar" <bol@adv.magwien.gv.at>
Subject: Inline missing with ActiveState?
Message-Id: <1152530328.331626@proxy.dienste.wien.at>
Hi,
while playing with ActiveState Perl 5.8.8, I couldn't found the Inline
Module and
its childs (Inline::C, Inline::Foo).
Is this module not included in the distribution? Can I download it from
CPAN?
I'm not interested in compiling C code, but running code of a special
interpreter
(called DCL) as part of perl scripts. IIRC, Inline will also provide ways to
do
things like this.
MTIA for your answers, and kind greetings,
Ferry
--
Ing. Ferry Bolhar
Municipality of Vienna, Department 14
A-1010 Vienna / AUSTRIA
E-mail: bol@adv.magwien.gv.at
------------------------------
Date: Mon, 10 Jul 2006 15:33:38 +0200
From: Stephan Titard <sgt19@tid.es>
Subject: madrid perl hackers, where are you?
Message-Id: <e8tkve$i7e9@news.hi.inet>
Hi, I kwow this is a bit off-topic...but I don't know how to get in
touch with potential Madrid mongers...(Madrid, Spain)
the site madrid.pm.org is there right, but appears mostly dead.
I am mistaken? could anybody point to related links and/or mailing lists
thanks
p.s it's hard to believe there are no perl hackers in the madrid area ;)
------------------------------
Date: 10 Jul 2006 03:07:20 -0700
From: "Bart Van der Donck" <bart@nijlen.com>
Subject: Re: Problem converting euro from windows-1252 to UTF-8 !!
Message-Id: <1152526040.291511.308970@m73g2000cwd.googlegroups.com>
nevosa wrote:
> I am trying to convert RFC-2047 encode MIME headers to UTF-8. It is
> working fine so far using the MIME::WordDecoder and Unicode::MapUTF8
> CPAN packages. I have done some unit testing and it seems to work fine
> except for when I try to convert windows-1252 encode euro(0x80) symbol
> to UTF-8.
>
> Subject: This sub has non-ascii chars.Pound:
> ?windows-1252?Q?Euro_=80_?=
>
> In this case the conversion simply fails and what i see as output is 2
> spaces (0x20 0x20).
Windows-1252 differs from "default" ISO-8859-1 by using displayable
characters rather than control characters in the 0x80-0x9F range. If
you're running *nix, Windows-1252 might not be available.
To make sure, see
http://en.wikipedia.org/wiki/Windows-1252
And then try to display the characters in the yellow squares. If
they're not correctly converted, you've found the culprit.
Hope this helps,
--
Bart
------------------------------
Date: 10 Jul 2006 04:20:33 -0700
From: "nevosa" <nevosa@gmail.com>
Subject: Re: Problem converting euro from windows-1252 to UTF-8 !!
Message-Id: <1152530433.798150.165790@b28g2000cwb.googlegroups.com>
Thanks Bart for taking out time and looking into my problem.
But my problem is not the display part. I don't mind it not being
displayed properly on my putty screen. What i want is the correct UTF-8
encoding for euro (package Unicode:MapUTF-8 claims of being capable of
converting from any charset to UTF-8 and vice -versa). But it fails to
convert to correct UTF-8 value for euro. Euro in UTF-8 should have a
hex value of 0xE2-0x82-0xAC but what i see as output for euro is
0x20-0x20 which is wrong. I also tried for other chars in range
0x80-0x9f and rest all seem to get converted to their correct UTF-8
values.Problem is only with euro (the most frequently used of them all
!!).
To me it seems that there is a missing mapping for euro in the map
files being used by the perl MapUTF-8 package. what can i do if that is
the case?
I can't edit the .map files also as they are in binary.
Rgds,
Naveen
Bart Van der Donck wrote:
> nevosa wrote:
>
> > I am trying to convert RFC-2047 encode MIME headers to UTF-8. It is
> > working fine so far using the MIME::WordDecoder and Unicode::MapUTF8
> > CPAN packages. I have done some unit testing and it seems to work fine
> > except for when I try to convert windows-1252 encode euro(0x80) symbol
> > to UTF-8.
> >
> > Subject: This sub has non-ascii chars.Pound:
> > ?windows-1252?Q?Euro_=80_?=
> >
> > In this case the conversion simply fails and what i see as output is 2
> > spaces (0x20 0x20).
>
> Windows-1252 differs from "default" ISO-8859-1 by using displayable
> characters rather than control characters in the 0x80-0x9F range. If
> you're running *nix, Windows-1252 might not be available.
>
> To make sure, see
>
> http://en.wikipedia.org/wiki/Windows-1252
>
> And then try to display the characters in the yellow squares. If
> they're not correctly converted, you've found the culprit.
>
> Hope this helps,
>
> --
> Bart
------------------------------
Date: Mon, 10 Jul 2006 14:50:40 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: Problem converting euro from windows-1252 to UTF-8 !!
Message-Id: <e8tpk2.1ks.1@news.isolution.nl>
nevosa schreef:
Don't top-post. Get rid of the double exclamation marks. Better, get rid
of any exclamation marks. Phrases like "immediate help" are
counterproductive too.
A googlegroups search on "utf-8 mime" in this group, sorted by date,
would have brought you to this message:
http://groups.google.co.uk/groups?selm=MPG.1ef8c6dc9d98f907989893@news.tiscali.fr
(click on View thread)
> it fails to convert to correct UTF-8 value for euro. Euro in UTF-8
> should have a hex value of 0xE2-0x82-0xAC but what i see as output
> for euro is 0x20-0x20 which is wrong. I also tried for other chars in
> range 0x80-0x9f and rest all seem to get converted to their correct
> UTF-8 values.Problem is only with euro (the most frequently used of
> them all !!).
> To me it seems that there is a missing mapping for euro in the map
> files being used by the perl MapUTF-8 package. what can i do if that
> is the case?
The two spaces come from the two underscores.
In your OP, there was an equal sign missing before the first question
mark.
perl -MEncode -le '
print decode("MIME-Header", "Subject:
{=?windows-1252?Q?_Euro_=80_?=}")
'
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: 10 Jul 2006 05:15:27 -0700
From: "shrike@cyberspace.org" <shrike@cyberspace.org>
Subject: Re: Profanity checking, phonetically.
Message-Id: <1152533727.350774.52070@75g2000cwc.googlegroups.com>
Bill Smith (use net) wrote:
> "David Squire" <David.Squire@no.spam.from.here.au> wrote in message
> news:e8r2ag$fhr$1@gemini.csx.cam.ac.uk...
> > shrike@cyberspace.org wrote:
> >
> > [snip]
> >>
> > .. which I picked up somewhere (here?) a few years ago and adapted. I
> > have yet to see one that looked pronounceable, let alone profane.
> >
> >
>
> I suspect that users are much more likely to record a password if it is not
> pronounceable. This can be a problem in some enviroments.
>
> Bill Smith
In my case neither is a factor.
Once my passwords are issued they only authenticate for a few hours,
and parrallel sessions and CPU usage are controlled on a per-user
basis. Users can advertise their passwords on the side of a bus for all
I care.
But I would rather avoid commiting the faux pas of issueing a username
like "pckrhd". Of course the number of concievable iterations makes
such a thing virtually inevitable as the number of logins scales. But I
can try, which is all that is required.
I was amazed out how difficult it was to find raw profanity lists on
the internet. I found one or two very incomplete ones. I have made the
module. It was about 16 lines of perl and 200 lines of profanity. It
has been quite a funny excercise. The profanity list on Wikipedia for
example had me laughing so hard I nearly cried.
-Thanks everyone for your help!
-Matt
------------------------------
Date: Mon, 10 Jul 2006 16:09:28 +0200
From: Stephan Titard <sgt19@tid.es>
Subject: Re: Profanity checking, phonetically.
Message-Id: <e8tn2h$i7e10@news.hi.inet>
shrike@cyberspace.org escribió:
> Sherm Pendley wrote:
>> John Bokma <john@castleamber.com> writes:
>>
>>> *hits self with Perl Cookbook*
>>>
>>> Indeed, didn't read good.
>> Try a smaller book next time - seeing double from a concussion isn't likely
>> to improve things. :-)
>>
>> sherm--
>
> Unless your billing per line ;-)
>
> Thanks all. I expected this to be oddball enough not to be in the
> cookbook. The previous poster was correct: it is uid/password
> combinations that I am checking.
>
> Is this sort of thing common enough to bother adding a module to CPAN?
> I expect to write a module specifically for this. I would call it
> Text::Soundex::Profanity
>
> -Opinions?
> -Matt
>
o Text::Metaphone::* using the new shiny soundex
I did not try it but I remember it looked interesting...
at least I have an entry in my perl module notebook
hth
--stephan
------------------------------
Date: Mon, 10 Jul 2006 14:02:51 -0000
From: Justin C <justin.0511@purestblue.com>
Subject: Re: Spreadsheet::[Parse|Write]Excel - accessing the contents of a cell
Message-Id: <slrneb4ngb.n0s.justin.0511@stigmata.purestblue.com>
On 2006-07-10, Andrew <hawk007@flight.us> wrote:
> Also, (this might be completely unrelated to your particular case, but
> it does concern Spreadsheet::ParseExcel -- last time I checked, a
> couple of months ago), if you are generating or resaving your Excel
> sheets with OpenOffice (in *.xls format), you may end up with some
> strange hidden "defects"(?) that undermine ParseExcel.pm, making it
> produce unexpected results. IIRC, in particular, this has/had to do
> with blank/undefined cells, but there could be other problems as well.
> I gave up trying to fix it and circumvented it by (re)saving the
> spreadsheet in MS Excel.
Fortunately (?) these are virgin Excel sheets. OO has only been near
them to copy them.
Justin.
--
Justin C by the sea.
------------------------------
Date: 10 Jul 2006 07:47:11 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is a type error?
Message-Id: <1152542831.623833.25880@m79g2000cwm.googlegroups.com>
Joachim Durchholz wrote:
> Chris Smith schrieb:
> > For example, I wrote that example using variables of type int. If we
> > were to suppose that we were actually working with variables of type
> > Person, then things get a little more complicated. We would need a few
> > (infinite classes of) derived subtypes of Person that further constrain
> > the possible values for state. For example, we'd need types like:
> >
> > Person{age:{18..29}}
> >
> > But this starts to look bad, because we used to have this nice
> > property called encapsulation. To work around that, we'd need to
> > make one of a few choices: [...] (c) invent some kind of generic
> > constraint language so that constraints like this could be expressed
> > without exposing field names. [...] Choice (c), though, looks a
> > little daunting.
>
> That's not too difficult.
> Start with boolean expressions.
> If you need to check everything statically, add enough constraints that
> they become decidable.
I'm not sure I understand. Could you elaborate?
> For the type language, you also need to add primitives for type
> checking, and if the language is stateful, you'll also want primitives
> for accessing earlier states (most notably at function entry).
Again I'm not entirely clear what this means. Are you talking
about pre/post conditions, or are you talking about having the
constraint language itself be something other than functional?
Marshall
------------------------------
Date: 10 Jul 2006 08:02:31 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is a type error?
Message-Id: <1152543751.186771.113230@h48g2000cwc.googlegroups.com>
Chris Smith wrote:
> Marshall <marshall.spight@gmail.com> wrote:
> > Chris Smith wrote:
> > >
> > > But this starts to look bad, because we used to have this nice property
> > > called encapsulation. To work around that, we'd need to make one of a
> > > few choices: (a) give up encapsulation, which isn't too happy; (b) rely
> > > on type inference for this kind of stuff, and consider it okay if the
> > > type inference system breaks encapsulation; or (c) invent some kind of
> > > generic constraint language so that constraints like this could be
> > > expressed without exposing field names. Choice (b) is incomplete, as
> > > there will often be times when I need to ascribe a type to a parameter
> > > or some such thing, and the lack of ability to express the complete type
> > > system will be rather limiting. Choice (c), though, looks a little
> > > daunting.
> >
> > Damn the torpedoes, give me choice c!
>
> You and I both need to figure out when to go to sleep. :) Work's gonna
> suck tomorrow.
It's never been a strong point. Made worse now that my daughter
is one of those up-at-the-crack-of-dawn types, and not old enough
to understand why it's not nice to jump on mommy and daddy's
bed while they're still asleep. But aren't you actually a time zone
or two east of me?
> > I've been saying for a few years now that encapsulation is only
> > a hack to get around the lack of a decent declarative constraint
> > language.
>
> Choice (c) was meant to preserve encapsulation, actually. I think
> there's something fundamentally important about information hiding that
> can't be given up. Hypothetically, say I'm writing an accounting
> package and I've decided to encapsulate details of the tax code into one
> module of the application. Now, it may be that the compiler can perform
> sufficient type inference on my program to know that it's impossible for
> my taxes to be greater than 75% of my annual income. So if my income is
> stored in a variable of type decimal{0..100000}, then the return type of
> getTotalTax may be of type decimal{0..75000}. Type inference could do
> that.
The fields of an object/struct/what have you are often hidden behind
a method-based interface (sometimes callled "encapsulated") only
because we can't control their values otherwise. (The "exposing
the interface" issue is a non-issue, because we're exposing some
interface or another no matter what.) The issue is controlling the
values, and that is better handled with a declarative constraint
language. The specific value in the fields aren't known until
runtime.
However for a function, the "fields" are the in and out parameters.
The specific values in the relation that the function is aren't known
until runtime either, (and then only the subset for which we actually
perform computation.)
Did that make sense?
> But the point here is that I don't WANT the compiler to be able to infer
> that, because it's a transient consequence of this year's tax code. I
> want the compiler to make sure my code works no matter what the tax code
> is. The last thing I need to to go fixing a bunch of bugs during the
> time between the release of next year's tax code and the released
> deadline for my tax software. At the same time, though, maybe I do want
> the compiler to infer that tax cannot be negative (or maybe it can; I'm
> not an accountant; I know my tax has never been negative), and that it
> can't be a complex number (I'm pretty sure about that one). I call that
> encapsulation, and I don't think that it's necessary for lack of
> anything; but rather because that's how the problem breaks down.
There's some significant questions in my mind about how much of
a constraint language would be static and how much would be
runtime checks. Over time, I'm starting to feel like it should be
mostly runtime, and only occasionally moving into compile time
at specific programmer request. The decidability issue comes up.
Anyone else?
> Just expressing all of that in a method signature looks interesting
> enough. If we start adding abstraction to the type constraints on
> objects to support encapsulation (as I think you'd have to do), then
> things get even more interesting.
There are certainly syntactic issues, but I believe these are amenable
to the usual approaches. The runtime/compile time question, and
decidability seem bigger issues to me.
Marshall
------------------------------
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:
#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.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
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.
#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 V10 Issue 9444
***************************************
