[31799] in Perl-Users-Digest
Perl-Users Digest, Issue: 3062 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Aug 4 16:09:26 2010
Date: Wed, 4 Aug 2010 13:09:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 4 Aug 2010 Volume: 11 Number: 3062
Today's topics:
Re: Extract variable length numbers (tab delimitered) f <thomas@tifozi.net>
Re: Extract variable length numbers (tab delimitered) f <sherm.pendley@gmail.com>
Re: Extract variable length numbers (tab delimitered) f <tadmc@seesig.invalid>
Re: Extract variable length numbers (tab delimitered) f <sherm.pendley@gmail.com>
Re: Extract variable length numbers (tab delimitered) f <uri@StemSystems.com>
Re: Extract variable length numbers (tab delimitered) f <tzz@lifelogs.com>
Re: I think an assertion might do this? <derykus@gmail.com>
Re: I think an assertion might do this? <misterperl@gmail.com>
Re: looking for Hamming+BCH+Reed - Solomon Codes in per <jimsgibson@gmail.com>
Makefile.PL / ExtUtils::MakeMaker refuses to pick up fi <klaus03@gmail.com>
Re: Posting Guidelines for comp.lang.perl.misc ($Revisi <sherm.pendley@gmail.com>
Re: Spreadsheet shows scientific notation occasionally <needpassion@gmail.com>
Re: Spreadsheet shows scientific notation occasionally <needpassion@gmail.com>
Re: Spreadsheet shows scientific notation occasionally <needpassion@gmail.com>
Re: Spreadsheet shows scientific notation occasionally <jimsgibson@gmail.com>
Re: Storing array elements tab delimitered in a string <thomas@tifozi.net>
Re: Storing array elements tab delimitered in a string <sherm.pendley@gmail.com>
Re: Storing array elements tab delimitered in a string <thomas@tifozi.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 4 Aug 2010 19:20:05 +0200
From: "Thomas Andersson" <thomas@tifozi.net>
Subject: Re: Extract variable length numbers (tab delimitered) from a string?
Message-Id: <8btlopF18lU1@mid.individual.net>
wolf wrote:
> these are all valid arguments to improving the code :)
>
> However, since the original poster didn't even know how to wield
> SPLIT, i wanted to keep it as simple and un-confusing as possible,
> demonstrating just SPLIT as the important thing to handle.
> As such the code works well enough :p
Thanks, I'm not just looking for solutions but to learn as well so the
simple solutions is best, the fancy stuff I can do later.
------------------------------
Date: Wed, 04 Aug 2010 13:53:36 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: Extract variable length numbers (tab delimitered) from a string?
Message-Id: <m2r5ies1r3.fsf@sherm.shermpendley.com>
"Thomas Andersson" <thomas@tifozi.net> writes:
> wolf wrote:
>
>> these are all valid arguments to improving the code :)
>>
>> However, since the original poster didn't even know how to wield
>> SPLIT, i wanted to keep it as simple and un-confusing as possible,
>> demonstrating just SPLIT as the important thing to handle.
>> As such the code works well enough :p
>
> Thanks, I'm not just looking for solutions but to learn as well so the
> simple solutions is best, the fancy stuff I can do later.
You should take sln's suggestions with a grain of salt. He does appear
to know his way around regexes, but he's got that regex hammer in his
hand and wants every problem to be a nail - even when it's clearly not.
Also keep in mind that "fancy" solutions are rarely the best. I've heard
it said that debugging is twice as difficult as writing code, and that
being the case, code that's written to the limit of one's abilities is
by definition impossible to debug. In all but the most extreme cases,
clarity and ease of maintenance are *far* more valuable over the long
run than clever tricks.
sherm--
--
Sherm Pendley <www.shermpendley.com>
<www.camelbones.org>
Cocoa Developer
------------------------------
Date: Wed, 04 Aug 2010 13:45:35 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Extract variable length numbers (tab delimitered) from a string?
Message-Id: <slrni5jd5t.7vq.tadmc@tadbox.sbcglobal.net>
Sherm Pendley <sherm.pendley@gmail.com> wrote:
> I've heard
> it said that debugging is twice as difficult as writing code, and that
> being the case, code that's written to the limit of one's abilities is
> by definition impossible to debug.
Everyone knows that debugging is twice as hard as writing a program in
the first place. So if you are as clever as you can be when you write
it, how will you ever debug it? ~Brian Kernighan
That Kernighan guy has a bit of a reputation amongst programmer types. :-)
--
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, 04 Aug 2010 15:07:56 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: Extract variable length numbers (tab delimitered) from a string?
Message-Id: <m2aap2yz5f.fsf@sherm.shermpendley.com>
Tad McClellan <tadmc@seesig.invalid> writes:
> Sherm Pendley <sherm.pendley@gmail.com> wrote:
>
>> I've heard
>> it said that debugging is twice as difficult as writing code, and that
>> being the case, code that's written to the limit of one's abilities is
>> by definition impossible to debug.
>
> Everyone knows that debugging is twice as hard as writing a program in
> the first place. So if you are as clever as you can be when you write
> it, how will you ever debug it? ~Brian Kernighan
>
> That Kernighan guy has a bit of a reputation amongst programmer types. :-)
Aha, yes! That's the quote I was thinking of. Thanks for filling in the
citation - that would have bugged me until I found it. :-)
sherm--
--
Sherm Pendley <www.shermpendley.com>
<www.camelbones.org>
Cocoa Developer
------------------------------
Date: Wed, 04 Aug 2010 15:21:25 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Extract variable length numbers (tab delimitered) from a string?
Message-Id: <87aap2i3pm.fsf@quad.sysarch.com>
>>>>> "TM" == Tad McClellan <tadmc@seesig.invalid> writes:
TM> Sherm Pendley <sherm.pendley@gmail.com> wrote:
>> I've heard
>> it said that debugging is twice as difficult as writing code, and that
>> being the case, code that's written to the limit of one's abilities is
>> by definition impossible to debug.
TM> Everyone knows that debugging is twice as hard as writing a program in
TM> the first place. So if you are as clever as you can be when you write
TM> it, how will you ever debug it? ~Brian Kernighan
TM> That Kernighan guy has a bit of a reputation amongst programmer types. :-)
is twice as hard the same as twice the duration? i find i have a very
different ratio of development time to debug time than many coders. i
break it up into three periods and mine are roughly 40% design (much in
my head), 40% coding and 20% debugging. and much of the debugging is
very easy stuff (at least to me). my take on the general coder
population is like 10% design (if that much), 40% coding and 50%
debugging. well it seems like that from what i see and hear. debugging
should be easy IMO if you design the code right. a given bug should be
quickly isolated to the area that handles that part of data. this brings
up the design philosophy of high isolation of modules. again, few adhere
to that idea so they have many places which could cause a given bug
thereby making debugging harder. i don't use a debugger, IDE or anything
but print and i get working code without pain. brains over typing! :)
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, 04 Aug 2010 14:23:44 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Extract variable length numbers (tab delimitered) from a string?
Message-Id: <877hk689mn.fsf@lifelogs.com>
On Wed, 04 Aug 2010 13:53:36 -0400 Sherm Pendley <sherm.pendley@gmail.com> wrote:
SP> Also keep in mind that "fancy" solutions are rarely the best. I've heard
SP> it said that debugging is twice as difficult as writing code, and that
SP> being the case, code that's written to the limit of one's abilities is
SP> by definition impossible to debug. In all but the most extreme cases,
SP> clarity and ease of maintenance are *far* more valuable over the long
SP> run than clever tricks.
OTOH a programmer that doesn't explore new techniques is not growing (I
mean technically; physically they grow with or without new techniques).
So there's value in exploration and cleverness.
Ted
------------------------------
Date: Wed, 4 Aug 2010 11:48:31 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: I think an assertion might do this?
Message-Id: <2f3ec7f2-c02e-4453-8ef4-762a2a7a54a4@s17g2000prh.googlegroups.com>
On Aug 4, 6:02=A0am, Mr P <misterp...@gmail.com> wrote:
> Hey Perlistas...
>
> I wanted to replace any and all multiple sequential EOLs with a single
> one. This worked nicely:
>
> (a) =A0s/(\n)\n+/$1/g;
>
> But thinking abot it some more. it occurred to me that these wouldn't
> quite work
>
> (b) s/(\n)\n/$1/g;
> (c) s/\n(\n)/$1/g;
> (d) s/\n\n/\n/g;
>
> because even though they are greedy, they don't retrace. And
> predictably they didn't work.
The /g switch applies the substitution globally
but greedy applies only to quantifiers such as *,
+ or {m,n}, etc.
The reason /g fails is that the engine matches and
substitutes consecutive pairs of \n's but, a final
trailing \n in any odd number of consecutive \n's
doesn't get replaced.
>
> I've never really used assertions, at least not enough to be familiar
> with them. I guess this would be a positive look-behind to force the
> engine to retrace?
It's easier IMO to think of this with the positive
look-ahead assertion solution that was shown. A
positive look-behind would work too though:
s/ (?<=3D\n) \n//gx;
>
> Can someone offer an example please where I can use something like s/
> (\n)\n/$1/g; with an assertion to do what (a) does? It would be
> instructional for me to see this example.
>
No, the look-ahead/behind assertions are zero length
so with something such as you've shown plus a look-
ahead/behind assertion, you'd be capturing and then
just replacing only the capture. The target wouldn't
be changed at all.
--
Charles DeRykus
------------------------------
Date: Wed, 4 Aug 2010 13:08:38 -0700 (PDT)
From: Mr P <misterperl@gmail.com>
Subject: Re: I think an assertion might do this?
Message-Id: <bad8265c-3ba5-40a3-9f74-531b10ac7925@x25g2000yqj.googlegroups.com>
On Aug 4, 9:59=A0am, Tad McClellan <ta...@seesig.invalid> wrote:
> Mr P <misterp...@gmail.com> wrote:
> > I wanted to replace any and all multiple sequential EOLs with a single
> > one. This worked nicely:
>
> > (a) =A0s/(\n)\n+/$1/g;
>
> You don't need regular expressions to do that:
>
> =A0 =A0 tr/\n/\n/s;
> or
> =A0 =A0 tr/\n//s;
>
That's quite a surprising solution to me as I would not have thought
of tr// - I will monkey with it thanks.. I always thought of tr// as a
1:1 mapping which is not what this is, so it seems un-natrual.
>
> I don't see how assertions can help with this problem...
It seemed like a natural solution to me.
start with /n/n/n
s/(\n)\n/$1/ now you have \n\n.
Which would MATCH again, IF the engine started at the scalar
beginning (hence my use of the word RETRACE, and my thought that this
was a LOOK-Behind case)..
>
As far as greed and quantifiers, requiring quantifiers makes no sense.
If I dont have the /g switch, the regex operates ONE TIME on the
scalar. If /g (regardless of quantifiers) it operates on the entire
scalar, as many times as it matches. And if it reset to the beginning
of the scalar AFTER each match, it would even work the same way as s/\n
\n*/\n/;
>
THanks.
> --
> 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, 04 Aug 2010 09:33:46 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: looking for Hamming+BCH+Reed - Solomon Codes in perl
Message-Id: <040820100933465762%jimsgibson@gmail.com>
In article
<dc815c7b-b3ee-41b6-92d6-51efce6bb66a@f42g2000yqn.googlegroups.com>,
Amir <sting.t2@gmail.com> wrote:
> Hi,
> do you have any idea where can I find implementations of the Hamming
> +BCH+Reed - Solomon Codes in Perl?
A quick search at <http://search.cpan.org> for 'hamming' reveals the
Algorithm::Hamming::Perl module. Only a couple of hits for
'reed-solomon', and they don't look too promising. Nothing at all for
'BCH'.
Looks like an opportunity here for someone to contribute to CPAN!
--
Jim Gibson
------------------------------
Date: Wed, 4 Aug 2010 10:07:32 -0700 (PDT)
From: Klaus <klaus03@gmail.com>
Subject: Makefile.PL / ExtUtils::MakeMaker refuses to pick up files in /bin
Message-Id: <34166943-1036-49d4-bff7-e70868915306@i31g2000yqm.googlegroups.com>
In my module File::Vctools http://search.cpan.org/~keichner/File-Vctools-0.06/
I have a couple of *.pl files that live in the /bin subdirectory of
the archive.
Here is the Build.PL that installs the module (using Module::Build as
the installer)
**************************************
use strict;
use warnings;
use 5.010;
use Module::Build;
unless ($^O eq 'MSWin32' or $^O eq 'linux') {
die "Error-0010: File::Vctools can only run on \$^O = 'MSWin32' or
'linux', but found \$^O = '$^O'";
}
Module::Build->new(
module_name => 'File::Vctools',
license => 'perl',
requires => {
'XML::Reader' => 0.37,
'Algorithm::Diff' => 1.19_02,
'File::Slurp' => 9999.12,
},
dist_abstract => 'Compare different versions of text files and
identify changes',
)->create_build_script;
**************************************
Everything works fine...
...except for the Makefile.PL that I want to offer for those who don't
want to (or can't)
install using Module::Build, so that they can install using
ExtUtils::MakeMaker instead.
The problem is that Makefile.PL / ExtUtils::MakeMaker refuses to pick
up the *.pl files located in /bin.
Is there an option that I can put into Makefile.PL so that the *.pl
files in /bin are
picked up by Makefile.PL ?
Anyway, here is the Makefile.PL (that does not pick up the *.pl files
in /bin)
**************************************
use 5.010;
use ExtUtils::MakeMaker;
unless ($^O eq 'MSWin32' or $^O eq 'linux') {
die "Error-0010: File::Vctools can only run on \$^O = 'MSWin32' or
'linux', but found \$^O = '$^O'";
}
# See lib/ExtUtils/MakeMaker.pm for details of how to influence
# the contents of the Makefile that is written.
WriteMakefile(
NAME => 'File::Vctools',
VERSION_FROM => 'lib/File/Vctools.pm', # finds $VERSION
PREREQ_PM => {
'XML::Reader' => 0.37,
'Algorithm::Diff' => 1.19_02,
'File::Slurp' => 9999.12,
}, # e.g., Module::Name => 1.1
($] >= 5.005 ? ## Add these new keywords supported since 5.005
(ABSTRACT_FROM => 'lib/File/Vctools.pm', # retrieve abstract
from module
AUTHOR => 'Klaus Eichner <klaus03@gmail.com>') : ()),
);
**************************************
------------------------------
Date: Wed, 04 Aug 2010 13:33:15 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: Posting Guidelines for comp.lang.perl.misc ($Revision: 1.9 $)
Message-Id: <m2zkx2s2p0.fsf@sherm.shermpendley.com>
Willem <willem@turtle.stack.nl> writes:
> Justin C wrote:
> ) On 2010-08-03, Ralph Malph <ralph@happydays.com> wrote:
> )> tl, dnr
> )
> ) Tedious life-form, do not resuscitate?
>
> More vulgarly: Trolling loser, do not reply.
You have to admit though, it's nice of the loser to admit what he is
and what he's doing. Most loser trolls don't do that. :-)
sherm--
--
Sherm Pendley <www.shermpendley.com>
<www.camelbones.org>
Cocoa Developer
------------------------------
Date: Wed, 4 Aug 2010 10:26:15 -0700 (PDT)
From: mike yue <needpassion@gmail.com>
Subject: Re: Spreadsheet shows scientific notation occasionally with some cells, but it is wrong
Message-Id: <298fb657-9ce0-48bf-a7cb-be7132b6c842@i28g2000yqa.googlegroups.com>
I didn't use either write or write_string, I used write_col() instead.
$worksheet->write_col( 14, 1, \@start_addrs, $RIGHT_ALIGN );
So the data comes from an array.
Do I need to set the format RIGHT_ALIGN to a particular string or
something? how?
------------------------------
Date: Wed, 4 Aug 2010 13:00:45 -0700 (PDT)
From: mike yue <needpassion@gmail.com>
Subject: Re: Spreadsheet shows scientific notation occasionally with some cells, but it is wrong
Message-Id: <c4bb48d0-2abd-440b-aeae-54605d1c1fd0@q22g2000yqm.googlegroups.com>
On Aug 4, 11:07=A0am, Jim Gibson <jimsgib...@gmail.com> wrote:
> In article
> <298fb657-9ce0-48bf-a7cb-be7132b6c...@i28g2000yqa.googlegroups.com>,
>
> mike yue <needpass...@gmail.com> wrote:
> > I didn't use either write or write_string, I used write_col() instead.
> > =A0 =A0 $worksheet->write_col( 14, 1, \@start_addrs, $RIGHT_ALIGN );
> > So the data comes from an array.
> > Do I need to set the format RIGHT_ALIGN to a particular string or
> > something? how?
>
> $RIGHT_ALIGN should be a valid Format object reference as returned by
> the add_format() method called on a workbook object:
>
> =A0 my $RIGHT_ALIGN =3D $workbook->add_format();
>
> The format should not change the interpretation of the object type as
> determined by the write_col method.
>
> Try using write_string() to store the data instead of write_col(). You
> will have to store one cell at a time in a loop.
>
> --
> Jim Gibson
I've done that but don't feel good with it - Still wonder if there is
a better solution.
Thanks Jim.
------------------------------
Date: Wed, 4 Aug 2010 13:01:54 -0700 (PDT)
From: mike yue <needpassion@gmail.com>
Subject: Re: Spreadsheet shows scientific notation occasionally with some cells, but it is wrong
Message-Id: <614d138f-07ae-4a94-b5dc-6622cd1fb39f@d17g2000yqb.googlegroups.com>
Also Thanks to Sherm and Peter!
------------------------------
Date: Wed, 04 Aug 2010 11:07:17 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: Spreadsheet shows scientific notation occasionally with some cells, but it is wrong
Message-Id: <040820101107177903%jimsgibson@gmail.com>
In article
<298fb657-9ce0-48bf-a7cb-be7132b6c842@i28g2000yqa.googlegroups.com>,
mike yue <needpassion@gmail.com> wrote:
> I didn't use either write or write_string, I used write_col() instead.
> $worksheet->write_col( 14, 1, \@start_addrs, $RIGHT_ALIGN );
> So the data comes from an array.
> Do I need to set the format RIGHT_ALIGN to a particular string or
> something? how?
$RIGHT_ALIGN should be a valid Format object reference as returned by
the add_format() method called on a workbook object:
my $RIGHT_ALIGN = $workbook->add_format();
The format should not change the interpretation of the object type as
determined by the write_col method.
Try using write_string() to store the data instead of write_col(). You
will have to store one cell at a time in a loop.
--
Jim Gibson
------------------------------
Date: Wed, 4 Aug 2010 19:18:46 +0200
From: "Thomas Andersson" <thomas@tifozi.net>
Subject: Re: Storing array elements tab delimitered in a string
Message-Id: <8btlmaFogU1@mid.individual.net>
bugbear wrote:
>> I there an easy way to stora all elements of an array tab
>> delimitered in a string (need to prepare collected data for import
>> to a database).?
>
> What import formats does your database support?
MS Access 2007, the import itself should be a problem. I also realized that
the array was not neccessary anyway, now I just concatenate the collected
data with tabs inserted to a string that I later write out with linefeed to
a txt file.
------------------------------
Date: Wed, 04 Aug 2010 13:30:52 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: Storing array elements tab delimitered in a string
Message-Id: <m24ofathdf.fsf@sherm.shermpendley.com>
"Thomas Andersson" <thomas@tifozi.net> writes:
> Sherm Pendley wrote:
>
>>> I there an easy way to stora all elements of an array tab
>>> delimitered in a string (need to prepare collected data for import
>>> to a database).?
>>
>> join() is the opposite of split().
>>
>> my $record = join("\t", @fields);
>>
>> However! Note that this simple approach is fragile - if any of your
>> fields contain tab characters, it will break. You might want to use
>> map() to quote each field before joining them together:
>>
>> my $record = join("\t", map("\"$_\"", @fields))
>>
>> That can break too, if your fields can contain quotes *and* tabs.
>> There comes a point where it's easier to use DBI to connect to your
>> database and insert your data directly. :-)
>
> Thank you, my array will contain single words or numbers only so shouldn't
> be a problem. Might colons be a problem?
Not if you're using tabs as field separators. The general pattern is
that whatever characters you're assigning special meaning to - i.e.
tabs as field separators, quote marks as string delimiters, etc. -
need to be handled differently whenever they are used as "normal"
characters instead.
That's why there comes a point where it's easier to just use DBI and
insert the data directly - exporting to a text file can be easier in the
simplest case, but grows in complexity if you start having to handle
a bunch of special cases and escape sequences.
> (I know my script fails at
> collecting the fields containing a time ref and I assume it's due to the
> colon).
More likely, it's due to the database expecting a different format; for
example, if it's a datetime field in MySQL, you can't supply just the
time by itself. Or, if it's expecting YY/MM/DD, and you give it a date
that's formatted as 12/20/67, it will see that date as being invalid.
I'd need to see the field definition, and an example of a failed input
to tell for sure though - without that, all I can offer is vague gen-
eralizations.
sherm--
--
Sherm Pendley <www.shermpendley.com>
<www.camelbones.org>
Cocoa Developer
------------------------------
Date: Wed, 4 Aug 2010 19:38:42 +0200
From: "Thomas Andersson" <thomas@tifozi.net>
Subject: Re: Storing array elements tab delimitered in a string
Message-Id: <8btmrjF7qlU1@mid.individual.net>
Sherm Pendley wrote:
>> Thank you, my array will contain single words or numbers only so
>> shouldn't be a problem. Might colons be a problem?
>
> Not if you're using tabs as field separators. The general pattern is
> that whatever characters you're assigning special meaning to - i.e.
> tabs as field separators, quote marks as string delimiters, etc. -
> need to be handled differently whenever they are used as "normal"
> characters instead.
Turns out the colon wasn't the problem, the cell contained more data than I
knew so now I have to figure out a new solution.
> That's why there comes a point where it's easier to just use DBI and
> insert the data directly - exporting to a text file can be easier in
> the simplest case, but grows in complexity if you start having to
> handle a bunch of special cases and escape sequences.
That will be added as I learn, trying to start simple at first, remember a
week ago I had never seen a line of perl code in my life.
>> (I know my script fails at
>> collecting the fields containing a time ref and I assume it's due to
>> the colon).
>
> More likely, it's due to the database expecting a different format;
> for example, if it's a datetime field in MySQL, you can't supply just
> the time by itself. Or, if it's expecting YY/MM/DD, and you give it a
> date that's formatted as 12/20/67, it will see that date as being
> invalid.
>
> I'd need to see the field definition, and an example of a failed input
> to tell for sure though - without that, all I can offer is vague gen-
> eralizations.
I'm using HTML::TreeBuilder to create a html tree to navigate through by
feeding my data collector sub the coordinates of my data. It works fine for
all cells containing strings of text or numbers, what caused it to fail was
that the meanies had inserted the date in a link within the cell. Now I need
figure out how to only collect the interesting data and bypass the link.
------------------------------
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 3062
***************************************
