[32740] in Perl-Users-Digest
Perl-Users Digest, Issue: 4004 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jul 29 05:17:33 2013
Date: Mon, 29 Jul 2013 02:17:07 -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, 29 Jul 2013 Volume: 11 Number: 4004
Today's topics:
'portable' filesystem manipulation (was: lest talk a li <rweikusat@mssgmbh.com>
Re: 'portable' filesystem manipulation (was: lest talk <ben@morrow.me.uk>
Re: 'portable' filesystem manipulation <rweikusat@mssgmbh.com>
Re: 'portable' filesystem manipulation <rweikusat@mssgmbh.com>
Re: 'portable' filesystem manipulation <ben@morrow.me.uk>
Re: lest talk a litle more about directories <rweikusat@mssgmbh.com>
Re: lest talk a litle more about directories <gravitalsun@hotmail.foo>
Re: lest talk a litle more about directories <cwilbur@chromatico.net>
Re: lest talk a litle more about directories <kkeller-usenet@wombat.san-francisco.ca.us>
Re: lest talk a litle more about directories <rweikusat@mssgmbh.com>
Regex basic question <vedpsingh@gmail.com>
Re: Regex basic question <ben@morrow.me.uk>
Re: Regex basic question <derykus@gmail.com>
Re: Restart Perl Application upon KDE Restart (Seymour J.)
Re: Restart Perl Application upon KDE Restart <ben@morrow.me.uk>
Re: three computing drawbacks (Seymour J.)
Re: three computing drawbacks (Seymour J.)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 28 Jul 2013 12:43:30 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: 'portable' filesystem manipulation (was: lest talk a litle more about directories)
Message-Id: <874nbehpul.fsf_-_@sapphire.mobileactivedefense.com>
gamo@telecable.es writes:
>> my @array = split /[\/\\]/, $_[0];
> -----------------------
>
> I'm afraid that's not compatible with VMS
Well, so what? Does VMS run on anything but VAX(fossilized) and
Alpha(dead)? Looking into the other direction: A sensible
implementation for VMS also won't be compatible with anything except
'similar systems' (that would be VMS). An idea I recently had
while looking at the File::Path code: Given that there really isn't
such a things as 'distributable pre-compiled Perl code'[*], the
characteristics of the host filesystem are known at compile time and
this means selection an implementation which works for a particular
kind of file system/ operating system should really be done at
compile-time and not at runtime with the help of 'generic' switching
code which is - in effect - the least common denominator
implementation working badly everywhere.
[*] I had a short conversation with the present 'Perl compiler code'
because my boss really didn't like the fact that we were distributing
Perl source code to customers. I asked it "Can you support this?" and
the answer was 'Segmentation Violation!'.
------------------------------
Date: Sun, 28 Jul 2013 14:07:06 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: 'portable' filesystem manipulation (was: lest talk a litle more about directories)
Message-Id: <qkhfca-v952.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> gamo@telecable.es writes:
> >> my @array = split /[\/\\]/, $_[0];
> > -----------------------
> >
> > I'm afraid that's not compatible with VMS
>
> Well, so what? Does VMS run on anything but VAX(fossilized) and
> Alpha(dead)?
Modern versions run on IA64, and the perl port is actively maintained.
See e.g.
http://www.nntp.perl.org/group/perl.daily-build.reports/2013/07/msg146975.html
.
Ben
------------------------------
Date: Sun, 28 Jul 2013 18:50:00 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: 'portable' filesystem manipulation
Message-Id: <877gga8th3.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> An idea I recently had while looking at the File::Path code: Given
> that there really isn't such a things as 'distributable pre-compiled
> Perl code'[*], the characteristics of the host filesystem are known
> at compile time and this means selection an implementation which
> works for a particular kind of file system/ operating system should
> really be done at compile-time and not at runtime with the help of
> 'generic' switching code which is - in effect - the least common
> denominator implementation working badly everywhere.
perl seems a little schizophrenic in this respect since it both
includes File::Spec which provided 'portable pathname manipulation' in
an IMHO sensible way[*] by delegateing all actual work to a
system-specific implementation module and File::Basename (used by
File::Path) which employs if - elsif - else-cascades to select the
code to execute for a particular system at runtime.
[*] Mostly. It still relies on a hardcoded 'system list' in order to
determine which module to load, uses @ISA for forwarding calls to
'implementation modules' and loads these via require. Ideally, it
should select a module based on 'system name' only (possibly with an
override facility) and the implementation modules should put their
public routines on @EXPORT. The 'entry point module' could then just
use the implementation module in order to put everything in place with
no additional runtime overhead.
The File::Spec::Functions module provides something similar to this
but it uses
foreach my $meth (@EXPORT, @EXPORT_OK) {
my $sub = File::Spec->can($meth);
no strict 'refs';
*{$meth} = sub {&$sub('File::Spec', @_)};
}
at runtime in order to generate proxy subs. The 'double call' is
necessary to work around the IMHO totally weird descision to use
'method calls' for this in the first place (explanation why this could
make any sense greatly apprecicated) ...
------------------------------
Date: Sun, 28 Jul 2013 21:03:44 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: 'portable' filesystem manipulation
Message-Id: <8738qy8na7.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> gamo@telecable.es writes:
>> >> my @array = split /[\/\\]/, $_[0];
>> > -----------------------
>> >
>> > I'm afraid that's not compatible with VMS
>>
>> Well, so what? Does VMS run on anything but VAX(fossilized) and
>> Alpha(dead)?
>
> Modern versions run on IA64,
That would be something like this
http://www8.hp.com/us/en/products/integrity-servers/product-detail.html?oid=4311905#!tab=features
Should I ever get stinkin' filthy rich (hardly a reason to fear that
this might actually happen), I'll buy one of these and see if I can
turn it into a Linux workstation. Until then, I don't expect any code
written by me to run on such hardware ...
------------------------------
Date: Sun, 28 Jul 2013 23:55:12 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: 'portable' filesystem manipulation
Message-Id: <g3kgca-2uc.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>
> perl seems a little schizophrenic in this respect since it both
> includes File::Spec which provided 'portable pathname manipulation' in
> an IMHO sensible way[*] by delegateing all actual work to a
> system-specific implementation module and File::Basename (used by
> File::Path) which employs if - elsif - else-cascades to select the
> code to execute for a particular system at runtime.
Yes, I agree, it's a bit peculiar. However, they both work, and have
been thoroughly tested on many systems over many years, so I suppose
noone thinks it's worth changing them.
> [*] Mostly. It still relies on a hardcoded 'system list' in order to
> determine which module to load,
What else would you do?
> uses @ISA for forwarding calls to 'implementation modules' and loads
> these via require. Ideally, it should select a module based on 'system
> name' only (possibly with an override facility)
System names are too whimsical to use like that; they need to be
normalised to something sensible. That's all the list of 'known systems'
is doing.
> and the implementation
> modules should put their public routines on @EXPORT. The 'entry point
> module' could then just use the implementation module in order to put
> everything in place with no additional runtime overhead.
>
> The File::Spec::Functions module provides something similar to this
> but it uses
>
> foreach my $meth (@EXPORT, @EXPORT_OK) {
> my $sub = File::Spec->can($meth);
> no strict 'refs';
> *{$meth} = sub {&$sub('File::Spec', @_)};
> }
>
> at runtime in order to generate proxy subs. The 'double call' is
> necessary to work around the IMHO totally weird descision to use
> 'method calls' for this in the first place (explanation why this could
> make any sense greatly apprecicated) ...
The method implementation is indeed bizarre. I think the only reason it
works like that is that the module was written in the very early days of
Perl OO, before any sort of best practices had emerged, and someone
thought it would be a clever idea. (IMHO the same applies to Exporter
and Dynaloader, neither of which ought to use inheritance. AutoLoader
used to do the same, apparently, but has been changed.)
OTOH, does it matter? The code's there, it's tested, it works, and it's
reliable. The weirdness can usually just be ignored.
Ben
------------------------------
Date: Sun, 28 Jul 2013 12:27:09 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: lest talk a litle more about directories
Message-Id: <878v0qhqlu.fsf@sapphire.mobileactivedefense.com>
Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> writes:
> On 2013-07-26, George Mpouras <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> wrote:
>> Ok let???s talk about a little more about creating directories (or any other
>> trie structure entries).
>> There are three basic methods :
>
> The best method is to use File::Path unless you have thoroughly
> documented that you need to optimize directory creation because
> File::Path isn't fast enough. Using File::Path optimizes for
> programmer time and portability.
File::Path happens to be part of the Perl distribution because the guy
who happened to have written it happened to be on a sufficiently
friendly/ familiar footing with the guy (or guys) who made such
descisions at that time, as such things commonly happen in 'open
source land'. It certainly wasn't ever peer-reviewed by someone with
at least half a clue (eg, the outoging check for 'has another process
created the directory meanwhile is totally useless because said other
process could create it one microsecond after the check) and isn't a
particularly good implementation. If you think it is helpful for you,
than, by all means, use it. If someone else either doesn't think so or
wants to spend some time with researching sensible solutions to a
particular problem, even a problem you really don't care about, it
would be appropriate to let him instead of demanding that he has to
make the same choices you happen to have made (even if you
encompasses the population of all of China) because you happen to
have made them.
> If you really believe that your methods are superior, you should write
> them up as a patch to File::Path, so that others
... can laugh about you being so naive to try to 'contribute'
something to 'an open source project' because your solution is better
than the one the Really Important and Well-Connected Guy[tm] (who -
coincidentally - makes a living by offering his 'superior Perl
expertise' to the highest bidder) wrote.
------------------------------
Date: Sun, 28 Jul 2013 20:40:59 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: lest talk a litle more about directories
Message-Id: <kt3l3f$mg7$1@news.ntua.gr>
Στις 28/7/2013 13:00, ο/η Henry Law έγραψε:
> On 28/07/13 10:54, George Mpouras wrote:
>> I like this place for discussing interesting things
>
> So do I; but I'm afraid I have decided that the things you discuss are
> interesting only to you. Go right ahead, but I won't see them. Or, to
> be precise, I shall see only the parts quoted by the people who really
> know what they're talking about (Charlton, Ben and a dozen others) when
> they're destroying your arguments.
>
it is ok I can live with that.
I had many other things to say at this and other threads.
But as no one cares, and I have so bad treatment here, I better leave
this place.
Good luck to everyone.
------------------------------
Date: Sun, 28 Jul 2013 20:59:51 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: lest talk a litle more about directories
Message-Id: <87hafecha0.fsf@new.chromatico.net>
>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
RW> ... can laugh about you being so naive to try to 'contribute'
RW> something to 'an open source project' because your solution is
RW> better than the one the Really Important and Well-Connected
RW> Guy[tm] (who - coincidentally - makes a living by offering his
RW> 'superior Perl expertise' to the highest bidder) wrote.
I'm sure hundreds of thousands of lurkers support you in email, but you
sound like a crank and a loon here.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Sun, 28 Jul 2013 20:29:22 -0700
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: lest talk a litle more about directories
Message-Id: <i54hcaxakv.ln2@goaway.wombat.san-francisco.ca.us>
On 2013-07-28, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> File::Path happens to be part of the Perl distribution because the guy
> who happened to have written it happened to be on a sufficiently
> friendly/ familiar footing with the guy (or guys) who made such
> descisions at that time, as such things commonly happen in 'open
> source land'.
The guy who originally authored the module is no longer the maintainer.
> It certainly wasn't ever peer-reviewed by someone with
> at least half a clue (eg, the outoging check for 'has another process
> created the directory meanwhile is totally useless because said other
> process could create it one microsecond after the check) and isn't a
> particularly good implementation.
Did you submit a patch to the current maintainer?
> If someone else either doesn't think so or
> wants to spend some time with researching sensible solutions to a
> particular problem, even a problem you really don't care about, it
> would be appropriate to let him instead of demanding that he has to
> make the same choices you happen to have made (even if you
> encompasses the population of all of China) because you happen to
> have made them.
I am not demanding that George use File::Path. I am suggesting that he
not suggest that others use his code, and instead offer patches to
File::Path, where much larger numbers of programmers can obtain it, and
where it can be maintained in a more, uh, maintainable fashion.
Do you have good, verifiable reason to think that these patches, if they
passed tests, would not be accepted? I strongly suspect not.
--keith
--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
------------------------------
Date: Mon, 29 Jul 2013 09:55:46 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: lest talk a litle more about directories
Message-Id: <87fvuxu4ml.fsf@sapphire.mobileactivedefense.com>
Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> writes:
> On 2013-07-28, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
[...]
>> It certainly wasn't ever peer-reviewed by someone with
>> at least half a clue (eg, the outoging check for 'has another process
>> created the directory meanwhile is totally useless because said other
>> process could create it one microsecond after the check) and isn't a
>> particularly good implementation.
>
> Did you submit a patch to the current maintainer?
I don't use this code. Hence, I don't modify it, either. And the only
sensible modification here would be a wholesale rewrite to get rid of
the recursion. Assuming I did that for some other reason than
'performing an experiment whose outcome interested me' (like the two
subroutines I posted in a related threat), I'd probably just use the
result. Interactions with open source projects tend to be longuish,
flame-happy (since you basically 'appear on the scene' telling one of
the established bigwigs that he did something wrong) and lead nowhere
(eg, I have DBD::Pg with fully-working support for asynchronous
interactions with Postgres. I tried to 'submit' some preliminary
patches to 'the maintainer' and he even accepted some of. As soon as it got
into 'I changed this because it was stupidly written' [in a very
slight way], that came to an end. Considering that I'm usually
strongly urged to spend as little time as possible on each individual
work task, why would I cleanup to async stuff to a degree where it
could be published, given that I know that it works, so that that can
be shelved [or - at best - rewritten by one of the 'core guys'] as
well?)
>> If someone else either doesn't think so or
>> wants to spend some time with researching sensible solutions to a
>> particular problem, even a problem you really don't care about, it
>> would be appropriate to let him instead of demanding that he has to
>> make the same choices you happen to have made (even if you
>> encompasses the population of all of China) because you happen to
>> have made them.
>
> I am not demanding that George use File::Path. I am suggesting that he
> not suggest that others use his code,
He didn't do that. He published some musings about 'directory creation'
which included two routines actually doing this.
> and instead offer patches to File::Path,
[...]
> Do you have good, verifiable reason to think that these patches, if they
> passed tests, would not be accepted?
To be honest: So far, I submitted a single patch to something
maintained as part of perl and that got accepted, it was even
preferred over a similar one written by someone else. But that
happened indirectly through the Debian BTS. OTOH, I remember (all too
clearly) a period of time where I was trying to live on EUR 300/ month
(fixed rent cost of EUR 210) while expected to work. This was
ultimatively caused (or at least stimulated) by colliding with some
'Perl community' people who pulled some strings after drawing me into
a series of heated exchanges, something I absolutely couldn't deal with
ten years ago, on USENET. It is not difficult to find some of the
names in various 'Perl core' stuff and this is an experience I'm not
keen to repeat, especially considering that what people believe about
other people never changes, no matter how hard observable reality
contradicts it.
Consequently, I wouldn't want to try and would advise others to treat
very carefully in this area.
------------------------------
Date: Sun, 28 Jul 2013 19:38:24 -0700 (PDT)
From: Ved <vedpsingh@gmail.com>
Subject: Regex basic question
Message-Id: <28e7b80b-9504-45db-bef5-b700494d0dc0@googlegroups.com>
Hi,
I have written a small program.
Things are fine when I am using functions like REVERSE (i.e. line 12).
But, having problem in Reg Exp statement (line 14).
------------------------------------------
#!usr/bin/perl
use strict; use warnings;
open(my $in, "<", "data2.munge") or die "error reading for reading";
open(my $out, ">", "data3.munge") or die "error creating for writting ";
my $rev =0;
while (<$in>) {
chomp;
#my $rev = reverse $_;
####Below line not working##
my $rev =~ s/dog/cat/;
print $out "$rev\n";
}
close $in;
close $out;
___________________________________________________
cat
dog dog
dog
cat
cat
dog dog
dog
cat
cat
dog dog
dog
cat
--------------------------------------------------
------Error message-------------------------------
Use of uninitialized value $rev in concatenation (.) or string at test1.pl line 14, <IN> line 1.
Use of uninitialized value $rev in pattern match (m//) at test1.pl line 14, <IN> line 1.
..............and so on......
------------------------------
Date: Mon, 29 Jul 2013 06:58:11 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Regex basic question
Message-Id: <jschca-3ee2.ln1@anubis.morrow.me.uk>
Quoth Ved <vedpsingh@gmail.com>:
>
> #!usr/bin/perl
> use strict; use warnings;
>
> open(my $in, "<", "data2.munge") or die "error reading for reading";
> open(my $out, ">", "data3.munge") or die "error creating for writting ";
>
> my $rev =0;
>
> while (<$in>) {
> chomp;
>
> #my $rev = reverse $_;
> ####Below line not working##
> my $rev =~ s/dog/cat/;
OK, there are two things you're not understanding here. The first is
that s/// changes the string it's working on in-place. This is different
from something like 'reverse', which returns a new string. If you'd just
written
s/dog/cat/;
then $_ would have changed.
The second is that =~ is a very strange operator. It takes one of the
pattern-match operators which normally work on $_, like s///, and
changes it to work on a different variable. So if you had written this:
my $rev = $_;
$rev =~ s/dog/cat/;
then it would have done what you expected. It's common for people who
are familiar with Perl to shorten that to
(my $rev = $_) =~ s/dog/cat/;
but that's rather a complicated expression, so it's probably better to
stick to the separate statements until you get used to them.
Ben
------------------------------
Date: Mon, 29 Jul 2013 00:09:19 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Regex basic question
Message-Id: <kt54fq$52i$1@speranza.aioe.org>
On 7/28/2013 7:38 PM, Ved wrote:
> ...
> my $rev =~ s/dog/cat/;
> print $out "$rev\n";
>
> }
> ...
> --------------------------------------------------
> ------Error message-------------------------------
> Use of uninitialized value $rev in concatenation (.) or string at test1.pl line 14, <IN> line 1.
> Use of uninitialized value $rev in pattern match (m//) at test1.pl line 14, <IN> line 1.
> ..............and so on......
>
For regular expression basics, here're a couple of good sources:
perldoc perlretut
perldoc perlrequick
And for a more comprehensive look:
perldoc perlre
--
Charles DeRykus
------------------------------
Date: Sun, 28 Jul 2013 09:22:13 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Restart Perl Application upon KDE Restart
Message-Id: <51f51b05$4$fuzhry+tra$mr2ice@news.patriot.net>
In <ksreib$liq$4@news.albasani.net>, on 07/25/2013
at 03:00 PM, "Adam H. Kerman" <ahk@chinet.com> said:
>The mechanism indicated in the Content-Transfer-Encoding header of
>7bit or 8bit is used with unencoded data, whereas quoted-printable or
>base64 is used with data encoded in the named mechanism. I have no
>idea why you believe an author couldn't post an article to Usenet,
>the body of which consists of unencoded Latin-1 characters, without
>violating syntax.
Which part of "No octets with decimal values greater than 127 are
allowed" don't you understand?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Sun, 28 Jul 2013 21:23:45 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Restart Perl Application upon KDE Restart
Message-Id: <h7bgca-jb2.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <ksreib$liq$4@news.albasani.net>, on 07/25/2013
> at 03:00 PM, "Adam H. Kerman" <ahk@chinet.com> said:
>
> >The mechanism indicated in the Content-Transfer-Encoding header of
> >7bit or 8bit is used with unencoded data, whereas quoted-printable or
> >base64 is used with data encoded in the named mechanism. I have no
> >idea why you believe an author couldn't post an article to Usenet,
> >the body of which consists of unencoded Latin-1 characters, without
> >violating syntax.
>
> Which part of "No octets with decimal values greater than 127 are
> allowed" don't you understand?
Perhaps the part where ISO8859-1 *necessarily* contains octets greater
than 127?
Ben
------------------------------
Date: Sun, 28 Jul 2013 09:41:50 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: three computing drawbacks
Message-Id: <51f51f9e$7$fuzhry+tra$mr2ice@news.patriot.net>
In <ksusp9$1js5$1@news.ntua.gr>, on 07/27/2013
at 01:21 AM, "George Mpouras"
<nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> said:
>> It would be a courtesy if you would start quoting enough context to make
>> your posts comprehensible.
>>
>> Charlton
>Do you think quoting is so important any more with the tree view
>readers like thunderbid ?
They aren't universal, and they don't put the quote in context[1].
Attribution lines and context matter.
[1] In the case of the analog computer thread, the article was short
enough that the context was clear if you saw the article and
response together, but that's usualy not the case.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Sun, 28 Jul 2013 13:15:37 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: three computing drawbacks
Message-Id: <51f551b9$8$fuzhry+tra$mr2ice@news.patriot.net>
In <ksulb3$vud$1@news.ntua.gr>, on 07/26/2013
at 11:14 PM, "George Mpouras"
<nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> said:
>I have first pesrson experience Shmuel !
Yes, what you described working on *was* an analog computer, but did
you know that you were speaking in prose?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
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 4004
***************************************
