[32595] in Perl-Users-Digest
Perl-Users Digest, Issue: 3868 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jan 26 06:09:20 2013
Date: Sat, 26 Jan 2013 03: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 Sat, 26 Jan 2013 Volume: 11 Number: 3868
Today's topics:
Callback to Perl interpreter in C--something simpler th <kw@codebykevin.com>
Re: Callback to Perl interpreter in C--something simple <ben@morrow.me.uk>
Re: capturing, computing the ephemeris and passing it t <jurgenex@hotmail.com>
Re: capturing, computing the ephemeris and passing it t <cwilbur@chromatico.net>
Re: capturing, computing the ephemeris and passing it t <cal@example.invalid>
Re: How can I create a binary-distribution? <cartercc@gmail.com>
Re: including a Perl script in a C executable <glex_no-spam@qwest-spam-no.invalid>
module for generic tag processing/formatting <morty.abzug@gmail.com>
Re: module for generic tag processing/formatting <ben@morrow.me.uk>
Re: module for generic tag processing/formatting <rweikusat@mssgmbh.com>
Re: Trouble with embedded whitespace in filenames using <cwilbur@chromatico.net>
Re: Trouble with embedded whitespace in filenames using <cwilbur@chromatico.net>
Re: Trouble with embedded whitespace in filenames using <troffasky@hotmail.com>
Re: Trouble with embedded whitespace in filenames using <rweikusat@mssgmbh.com>
Re: Trouble with embedded whitespace in filenames using <cwilbur@chromatico.net>
Re: Trouble with embedded whitespace in filenames using <usenet.14@scottsonline.org.uk.invalid>
Re: Trouble with embedded whitespace in filenames using <rweikusat@mssgmbh.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 25 Jan 2013 18:43:37 -0500
From: Kevin Walzer <kw@codebykevin.com>
Subject: Callback to Perl interpreter in C--something simpler than XS?
Message-Id: <kdv5b8$71t$1@dont-email.me>
I'm trying to implement a Perl interface to a subset of Apple's
AppleEvent framework, allowing a Perl app to respond to AppleScript
commands. CPAN has a module devoted to this, but it is part of a larger
framework that is suffering from bit-rot, has large swaths of deprecated
and obsolete API calls, and won't build under 64-bit.
I'm moving right along with the AppleEvent / C API stuff, but I'm not
quite clear on how to convert this vanilla C code into something that
Perl can interface with. What I want to do is to pass a subroutine name
as a string to the Perl interpreter that the interpreter can run.
Here's one example C function:
//Handler for AppleEvents
static OSErr AEScriptsAEHandler(const AppleEvent *theAppleEvent,
AppleEvent *reply, long refCon) {
OSErr err = noErr;
AEDesc returnData;
AEEventID eventID;
OSType typeCode;
AEDesc directParameter;
char *script;
//Read the AppleEvent
err = AEGetParamDesc(theAppleEvent, keyDirectObject, typeUnicodeText,
&returnData);
//get event ID to look up in CFDictionary
err = AEGetAttributePtr(theAppleEvent, keyEventIDAttr, typeType,
NULL, &eventID, sizeof(eventID), NULL );
//get direct parameter
err = AEGetKeyDesc(theAppleEvent, keyDirectObject, typeType,
&directParameter);
CFStringRef scriptName;
stringeventID = UTCreateStringForOSType(eventID);
scriptName = CFDictionaryGetValue(aeDict, stringeventID);
CFIndex length = CFStringGetLength(scriptName);
CFIndex maxSize = CFStringGetMaximumSizeForEncoding(length,
kCFStringEncodingUTF8);
script = (char *)malloc(maxSize);
CFStringGetCString(scriptName, script, maxSize, kCFStringEncodingUTF8);
//actually run the script
err = ExecuteScript(script, NULL);
}
What this code does is check a CFDictionary ref for a value that
corresponds to the ID of a specific Apple event ("script"), and my idea
is to pass the "script" string to a function called "ExecuteScript" that
would incorporate the Perl interpreter. Is there a simpler way to
implement this than wading through all the XSUB goo?
In Tcl's C API it's simple as initializing a Tcl interpreter:
static Tcl_Interp *myInterp;
and then calling this function:
Tcl_Eval(myInterp, script);
In looking at the XS bits, am I missing something simpler that might
serve my needs? The idea here is that I'm passing a single subroutine
call to the Perl interpreter, then I'll be returning the subroutine's
output back to the AppleEvent C API as a string. There aren't a lot of
hooks or complex data structures that need to be addressed: I just want
to have this as a loadable module that can interact with the running
interpreter.
Thanks for any advice,
Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
------------------------------
Date: Sat, 26 Jan 2013 10:09:27 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Callback to Perl interpreter in C--something simpler than XS?
Message-Id: <njmct9-o3i.ln1@anubis.morrow.me.uk>
Quoth Kevin Walzer <kw@codebykevin.com>:
> I'm trying to implement a Perl interface to a subset of Apple's
> AppleEvent framework, allowing a Perl app to respond to AppleScript
> commands. CPAN has a module devoted to this, but it is part of a larger
> framework that is suffering from bit-rot, has large swaths of deprecated
> and obsolete API calls, and won't build under 64-bit.
>
> I'm moving right along with the AppleEvent / C API stuff, but I'm not
> quite clear on how to convert this vanilla C code into something that
> Perl can interface with. What I want to do is to pass a subroutine name
> as a string to the Perl interpreter that the interpreter can run.
>
> //Handler for AppleEvents
> static OSErr AEScriptsAEHandler(const AppleEvent *theAppleEvent,
> AppleEvent *reply, long refCon) {
<snip>
> //Read the AppleEvent
> err = AEGetParamDesc(theAppleEvent, keyDirectObject, typeUnicodeText,
> &returnData);
<snip>
> //actually run the script
> err = ExecuteScript(script, NULL);
> }
>
> What this code does is check a CFDictionary ref for a value that
> corresponds to the ID of a specific Apple event ("script"), and my idea
> is to pass the "script" string to a function called "ExecuteScript" that
> would incorporate the Perl interpreter. Is there a simpler way to
> implement this than wading through all the XSUB goo?
This sounds like you want to call Perl from C, not C from Perl. That
means you need to read perlembed and perlcall rather than perlxs.
What language is the 'main' part of your program written in?
> In Tcl's C API it's simple as initializing a Tcl interpreter:
>
> static Tcl_Interp *myInterp;
static PerlInterpreter *my_perl;
(Obviously you then have to initialise it, which is 3 function calls.)
> and then calling this function:
>
> Tcl_Eval(myInterp, script);
dSP;
call_argv(script, G_VOID, NULL);
'script' here is assumed to be a (fully-qualified) subroutine name. If
you want it to be a piece of Perl code, you want eval_pv.
> In looking at the XS bits, am I missing something simpler that might
> serve my needs? The idea here is that I'm passing a single subroutine
> call to the Perl interpreter, then I'll be returning the subroutine's
> output back to the AppleEvent C API as a string. There aren't a lot of
> hooks or complex data structures that need to be addressed: I just want
> to have this as a loadable module that can interact with the running
> interpreter.
...and now you've gone back to talking about extending perl again. I'm
confused. How does your program start? Do you want to start in Perl,
call into C, and then call back into Perl again? That's entirely
possible, but you have to use both the perlxs and perlcall facilities.
However, that C above looks to me as though it's a callback from some
Apple facility. How does that get invoked? If it gets called
asynchronously, while there is other Perl code being executed, you will
probably need to use the ithreads mechanism to prevent the two bits of
Perl from interfering with each other.
Ben
------------------------------
Date: Thu, 24 Jan 2013 04:26:48 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: capturing, computing the ephemeris and passing it to gfortran
Message-Id: <gp92g8tpbs9bfv2tllepa4jhptoffqrrc7@4ax.com>
Cal Dershowitz <cal@example.invalid> wrote:
>How does one use perl to upload images with the meta-data?
??????
To upload any file to a server you use whatever method this server
provides. There are modules that support all kind of servers and
services (FTP, NFS, NNTP, ...) on CPAN.
jue
------------------------------
Date: Thu, 24 Jan 2013 09:53:27 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: capturing, computing the ephemeris and passing it to gfortran
Message-Id: <87r4lay6mw.fsf@new.chromatico.net>
>>>>> "CD" == Cal Dershowitz <cal@example.invalid> writes:
CD> How does one use perl to upload images with the meta-data?
One figures out what protocol the server or service one is uploading to
uses to communicate about images and metadata, and one implements that
protocol in Perl. Then one uses that protocol to upload the images and
that metadata.
Different people can work on different parts of that solution, and there
is a fair chance that the minimally clueful can find the first part
mostly done on CPAN if they are using a common service.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Sat, 26 Jan 2013 00:54:33 -0700
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: capturing, computing the ephemeris and passing it to gfortran
Message-Id: <2c2dnXVLEt0kFp7MnZ2dnUVZ_uCdnZ2d@supernews.com>
On 01/24/2013 03:08 AM, Cal Dershowitz wrote:
> On 01/24/2013 02:51 AM, Henry Law wrote:
>> On 24/01/13 09:15, Cal Dershowitz wrote:
>>> That's the nominal reason for me establishing a new appropriate
>>> tool-chain for what I'm going to be doing.
>>>
>>> I've been thinking about the fortran part for a while, so assume that
>>> that part won't embarrass you.
>>>
>>> $ pwd
>>> /home/fred/Desktop/27.5
>>> $ ls
>>> Screenshot from 2013-01-24 00:19:49.png
>>> Screenshot from 2013-01-24 00:20:14.png
>>> $
>>>
>>>
>>> How does one use perl to upload images with the meta-data?
>>
>> Is this a coded message to a sleeper group? It makes no sense at all.
>>
>>
>
> go to sleep, grandpa.
First off, I was a total dick here. I wanted to strangle somebody else
but decided my better course was tapping keys on my computer.
--
Cal
------------------------------
Date: Thu, 24 Jan 2013 07:21:55 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: How can I create a binary-distribution?
Message-Id: <ec4fa8cd-399f-40c0-890d-84f93f2710e1@f8g2000yqa.googlegroups.com>
On Jan 19, 12:06=A0am, zuckzo...@yahoo.com wrote:
> Your question is older than me.
I tried to do this, and finally decided to use C.
Perl is a great language, I use it every day. But one job to which
it's NOT suited is the creation of stand along executables.
If you need one of those, use C. If it's a larger project or you need
graphics, use Java. If you have a client/server environment, use Perl/
CGI (or similar). If you are in Windows World, use VS. Using Perl for
this purpose is a lot like buying a Toyota to drive to Jamaica on your
vacation -- perhaps a great idea once you solve the problem of driving
underwater.
CC.
------------------------------
Date: Thu, 24 Jan 2013 10:10:05 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: including a Perl script in a C executable
Message-Id: <51015cdd$0$52253$815e3792@news.qwest.net>
On 01/23/13 10:25, ccc31807 wrote:
> On Tuesday, January 22, 2013 1:11:18 PM UTC-5, Jürgen Exner wrote:
>>
>> therefore I conclude that you are on Windows) "View" -> "Details";
>> right-click on the header bar where it says "Name, Date Modified, Type
>> ... " (actual headers will vary), and select "More..." from the context
>> menu. Then he can select to display whatever information his heart
>> desires.
>
> It's a 'manager problem' and you are exactly right. I can't cater to every whim, at least not when I've got work to do otherwise. He can get the information he wants, but not necessarily the format he wants, and we've worked it out.
>
> Besides, I just wondered if it could be done ... an idle thought that I'm now a little ashamed of posting. I write very little in C, I write a lot of Perl, and I suppose I can blame the question on a neuron misfire thinking that I should be able to invoke a Perl script from C the same way I can invoke an executable in Perl (by system(), e.g.).
C has system(), but that's a dumb way to go since there is printf
and toupper in C, there's no need to involve Perl. The program is
already using printf, so it should be a very simple change.
Do it right. Spend 5-minutes learning now and avoid hours of
frustration later.
------------------------------
Date: Fri, 25 Jan 2013 08:30:45 -0800 (PST)
From: Morty Abzug <morty.abzug@gmail.com>
Subject: module for generic tag processing/formatting
Message-Id: <534f17a6-9443-4dcf-a84e-fbdfd55c94ed@googlegroups.com>
One thing I've wanted a couple of times, and have coded once: a module for =
generic string processing/formatting. I looked on CPAN, and don't see it. =
I vaguely recall having seen something like this before. Am I missing som=
ething? Or should I genericize my current code and publish it?
The idea is to do something like this:
my $formatter=3Dnew String::Formatter(h=3D>"red-sonja", o=3D>"linux", r=3D>=
"3.0");
my $output=3D$formatter->format("Output for host %h\n"); # should yield "Ou=
tput for host red-sonja\n"
Does something like this already exist? I'd prefer not to reinvent the whe=
el if at all possible. I can't find it on CPAN, but maybe I'm not looking =
hard enough.
------------------------------
Date: Fri, 25 Jan 2013 17:07:45 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: module for generic tag processing/formatting
Message-Id: <1oqat9-r29.ln1@anubis.morrow.me.uk>
Quoth Morty Abzug <morty.abzug@gmail.com>:
> One thing I've wanted a couple of times, and have coded once: a module
> for generic string processing/formatting. I looked on CPAN, and don't
> see it. I vaguely recall having seen something like this before. Am I
> missing something? Or should I genericize my current code and publish
> it?
>
> The idea is to do something like this:
>
> my $formatter=new String::Formatter(h=>"red-sonja", o=>"linux", r=>"3.0");
> my $output=$formatter->format("Output for host %h\n"); # should yield
> "Output for host red-sonja\n"
>
> Does something like this already exist? I'd prefer not to reinvent the
> wheel if at all possible. I can't find it on CPAN, but maybe I'm not
> looking hard enough.
This sounds like a template module. There are many on CPAN, though not
one I can think of with that syntax. I would recommend Template::Simple
for something simple like that, or TT2 (that is, the Template-Toolkit
and related distributions) for a rather complete solution.
Actually, now that I think of it, it might be possible to make
Template::Simple use that with a lookbehind; something like
my $T = Template::Simple->new(
pre_delim => qr/%/,
post_delim => qr/(?<=.)/,
);
though TBH it's so simple I'd probably just use
s/%([a-zA-Z])/$data{$1}/g
If you want more complex sprintf-like formatting, you could look at
String::Sprintf.
Ben
------------------------------
Date: Fri, 25 Jan 2013 18:46:33 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: module for generic tag processing/formatting
Message-Id: <87wqv1rth2.fsf@sapphire.mobileactivedefense.com>
Morty Abzug <morty.abzug@gmail.com> writes:
> One thing I've wanted a couple of times, and have coded once: a
> module for generic string processing/formatting. I looked on CPAN,
> and don't see it. I vaguely recall having seen something like this
> before. Am I missing something? Or should I genericize my current
> code and publish it?
>
> The idea is to do something like this:
>
> my $formatter=new String::Formatter(h=>"red-sonja", o=>"linux", r=>"3.0");
> my $output=$formatter->format("Output for host %h\n"); # should yield "Output for host red-sonja\n"
>
> Does something like this already exist?
Ehh ... yes ... it is called 'interpolating variables into a string',
in this case
%values = (h => 'red-sonia');
print "Output for host $values{h}";
Unless you want something much more complicated than that,
------------
package Formatter;
sub new
{
my $class = shift;
my %self;
%self = @_;
return bless(\%self, $class);
}
sub format
{
my ($self, $s) = @_;
$s =~ s/%([A-Za-z0-9_]+)/$self->{$1}/g;
return $s;
}
package main;
my $fmt = Formatter->new(h => 'red-sonja');
print $fmt->format("Host %h\n");
-------------
it exists now.
------------------------------
Date: Thu, 24 Jan 2013 10:13:16 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <87ip6my5pv.fsf@new.chromatico.net>
>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
RW> You asserted that you are convinced that a certain program
RW> wouldn't suffer from a certain problem. The question was "Why
RW> doesn't the perl 2-argument open work with filenames containing
RW> leading whitespace?". Even if your believes about this program
RW> happen to be correct, voicing them doesn't answer the question.
It doesn't answer the question, but it solves the problem.
The OP asked his question because he wanted to compare a large number of
files for equality, and was writing a Perl script to do so.
Which do you think is more helpful -- "here's a way to get Perl to get
around the odd edge case you've encountered," or "here's an easily
available open source program that solves your larger problem"?
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Thu, 24 Jan 2013 10:11:37 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <87mwvyy5sm.fsf@new.chromatico.net>
>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
RW> MD5 (or any other hashing algorithm) is a lot more expensive
RW> than a comparison and especially so if MD5 needs to process 2G
RW> of data while the comparison would only need 8K.
You make several unfounded assumptions here.
One, that the cost of a single linear read of a file, such as needed to
calculate a file hash, is comparable in expense and time to two or more
interleaved file reads, such as needed to do a direct comparison. Since
the seeking takes more time than the reading -- often by an order of
magnitude -- and the reading takes more time than the calculation --
again, often by an order of magnitude -- it is difficult to support this
claim. Yes, in terms of raw processor time, calculating an MD5 hash on
each of two blocks of memory and then comparing the result is more
expensive than comparing the two blocks of memory, especially if the
comparison can terminate at the first difference; but processor time is
far from the only cost being paid, and in the average case where a
filesystem is involved I expect the tradeoffs to be far less clear.
Two, that the number of comparisons is small. The more comparisons you
have, the more the advantage goes to the hashing algorithm. If you have
2 files, it is best to read the first 8K of each and compare them,
since, as you note, odds are that any differences will appear early on.
If you have 1000 files, reading the first 8K of each file for
comparison purposes means a great deal of seeking and reading; and then
you either store the first 8K, leading to a large working set (and the
first time you swap, you've lost anything you won by avoiding
calculating hashes), or you repeatedly seek and read. MD5 hashes, at 16
bytes each, require a much smaller working set.
Three, that no other caching or optimization is possible. If this task
is done repeatedly, it should be possible to cache the hash values of
the files and compare a timestamp on the hash value to the timestamp on
the file. If two files differ in size, they are clearly not equivalent;
determining the size of the file may be basically free, since the cost
for the call is likely to have been paid by an unavoidable system call.
This is a tradeoff between disk seek time, disk read time, processor
time, and memory, and the optimal point varies depending on how many
files one is comparing. The MD5 approach burns processor time in an
attempt to save disk seek times and disk read times so that clock time
can be optimized. If you're optimizing for processor time, the hashing
approach is obviously not the way to go; if you're optimizing for clock
time or disk access, the question is a lot less cut and dried than you
seem to think.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Thu, 24 Jan 2013 21:01:47 +0000
From: alexd <troffasky@hotmail.com>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <kds7fr$uh4$1@dont-email.me>
Charlton Wilbur (for it is he) wrote:
> Which do you think is more helpful
It's not about being helpful, it's about who can "win" the argument.
--
<http://ale.cx/> (AIM:troffasky) (UnSoEsNpEaTm@ale.cx)
21:01:16 up 38 days, 23:33, 6 users, load average: 0.90, 0.82, 0.77
Qua illic est reprehendit, illic est a vindicatum
------------------------------
Date: Thu, 24 Jan 2013 22:47:35 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <87wqv2yz94.fsf@sapphire.mobileactivedefense.com>
alexd <troffasky@hotmail.com> writes:
> Charlton Wilbur (for it is he) wrote:
>
>> Which do you think is more helpful
>
> It's not about being helpful, it's about who can "win" the argument.
In this case, it was about answering a question someone asked which
happened to be related to perl. If that someone should perhaps have
asked a different question in another newsgroup is for him to decide.
------------------------------
Date: Thu, 24 Jan 2013 21:41:57 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <87ehhax9u2.fsf@new.chromatico.net>
>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
RW> alexd <troffasky@hotmail.com> writes:
>> It's not about being helpful, it's about who can "win" the
>> argument.
RW> In this case, it was about answering a question someone asked
RW> which happened to be related to perl. If that someone should
RW> perhaps have asked a different question in another newsgroup is
RW> for him to decide.
In other words, it really isn't about being helpful, as far as you're
concerned.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Fri, 25 Jan 2013 08:52:08 +0000
From: Mike Scott <usenet.14@scottsonline.org.uk.invalid>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <kdth3p$a2m$1@dont-email.me>
On 25/01/13 02:41, Charlton Wilbur wrote:
>>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
> RW> alexd <troffasky@hotmail.com> writes:
>
> >> It's not about being helpful, it's about who can "win" the
> >> argument.
>
> RW> In this case, it was about answering a question someone asked
> RW> which happened to be related to perl. If that someone should
> RW> perhaps have asked a different question in another newsgroup is
> RW> for him to decide.
>
> In other words, it really isn't about being helpful, as far as you're
> concerned.
Thank you. I used to have a work colleague who'd suggest that 'if you
want to go there, don't start here'. He was too often right; partial
solutions can be worse than none, and this seems a case in point.
I do notice the OP has gone silent. Would be good to know his progress.
--
Mike Scott (unet2 <at> [deletethis] scottsonline.org.uk)
Harlow Essex England
------------------------------
Date: Fri, 25 Jan 2013 12:53:26 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <87d2wtzant.fsf@sapphire.mobileactivedefense.com>
Charlton Wilbur <cwilbur@chromatico.net> writes:
>>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
> RW> alexd <troffasky@hotmail.com> writes:
>
> >> It's not about being helpful, it's about who can "win" the
> >> argument.
>
> RW> In this case, it was about answering a question someone asked
> RW> which happened to be related to perl. If that someone should
> RW> perhaps have asked a different question in another newsgroup is
> RW> for him to decide.
>
> In other words, it really isn't about being helpful, as far as you're
> concerned.
My opinion on 'being helpful' apparently differs from your opinion on
that. And - this being the important aspect here - what pre-existing
program could possibly solve the problem the OP was trying to solve is
a discussion of its own and one which belongs elsewhere.
------------------------------
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 3868
***************************************
