[32739] in Perl-Users-Digest
Perl-Users Digest, Issue: 4003 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Jul 28 06:09:29 2013
Date: Sun, 28 Jul 2013 03:09:05 -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 Sun, 28 Jul 2013 Volume: 11 Number: 4003
Today's topics:
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 <gravitalsun@hotmail.foo>
Re: lest talk a litle more about directories <willem@turtle.stack.nl>
Re: lest talk a litle more about directories gamo@telecable.es
Re: lest talk a litle more about directories <gravitalsun@hotmail.foo>
Re: lest talk a litle more about directories <gravitalsun@hotmail.foo>
Re: lest talk a litle more about directories <kkeller-usenet@wombat.san-francisco.ca.us>
Re: lest talk a litle more about directories <gravitalsun@hotmail.foo>
Re: lest talk a litle more about directories gamo@telecable.es
Re: lest talk a litle more about directories <cwilbur@chromatico.net>
Re: lest talk a litle more about directories <ben@morrow.me.uk>
Re: lest talk a litle more about directories <kkeller-usenet@wombat.san-francisco.ca.us>
Re: lest talk a litle more about directories <gravitalsun@hotmail.foo>
Re: lest talk a litle more about directories <news@lawshouse.org>
Re: three computing drawbacks <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: three computing drawbacks <jimsgibson@gmail.com>
Re: three computing drawbacks <sbryce@scottbryce.com>
Re: three computing drawbacks <cwilbur@chromatico.net>
Re: three computing drawbacks <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 27 Jul 2013 13:25:59 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: lest talk a litle more about directories
Message-Id: <87vc3wi3zc.fsf@sapphire.mobileactivedefense.com>
"George Mpouras"
<nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
writes:
[...]
> 3) The most wise approach is to define an array from all the upper
> nodes. Then perform a binary tree search at this array against a node
> existence code. This is give as log(N) accesses at worst case.
>
> So what is the best solution; Unfortunately there is not ….
>
> If your directories “usually” exist, the 2nd method will be the faster
> because it will finish at the very first iterations.
> If your directories “usually” do not exist, the 3rd method will be the
> faster because it will dig faster at the bottomless abyss.
[...]
> mkdir_btree( 'd1/d2/d3/d4/d5' ) or die "$^E\n";
>
> sub mkdir_btree
> {
> my @array = split /[\/\\]/, $_[0];
> return 1 if -1 == $#array;
> $array[0] eq '' && splice @array, 0, 2, "/$array[1]";
> my ($begin, $end) = (0, scalar @array);
>
> while ($begin < $end)
> {
> my $cut = int(($begin + $end)/2);
> -d join('/', @array[0..$cut]) ? ($begin = $cut + 1) : ($end = $cut)
> }
>
> return 1 unless $begin < @array;
> mkdir(join '/', @array[0 .. $_]) || return 0 for $begin .. $#array;1
> }
The 'log(N) worst case' is not true: This algortihm has a constant
overhead of log(N) stat calls for every case (this could be improved
somewhat by using mkdir in the loop). This means it is worse than
'create from the top' when all directories have to be created and will
become worse than 'create from the bottom' if the number of
subdirectories which have to be created at depth n is large enough
that (m - 1) * log(n) stat calls amount to more work than what was avoided
when creating the first subdirectory at this depth. The work saved
when creating the first directory is (based on mkdir)
2n - 1 - n - log(n)
This must be larger than (m - 1) * log(n) for the binary search to
beneficial. Putting this together,
2n - 1 - n - log(n) > (m - 1) * log(n)
this ends up as (Rechenfehler vorbehalten)
(n - 1)/log(n) > m
The /usr tree on the machine I used as example has a maximum depth of
12. Using this program,
--------------
sub log2
{
return log($_[0])/log(2);
}
sub threshold
{
return ($_[0] - 1) / log2($_[0]);
}
print($_, "\t", threshold($_), "\n") for 2 .. 12;
--------------
yields the following threshold values:
2 1
3 1.26185950714291
4 1.5
5 1.72270623229357
6 1.93426403617271
7 2.13724312264813
8 2.33333333333333
9 2.52371901428583
10 2.70926996097583
11 2.89064826317888
12 3.06837240216243
(as soon as a directory at depth [first column] has more
subdirectories than [second column], the algorithm sucks).
I've used find /usr -type d to generate a list of directories, edited
the first line to remove a trailing slash and then used the following
program
-------------
use List::Util qw(sum);
@ds = map {chomp; $_} <STDIN>;
for (@ds) {
/(.*?\/)[^\/]*$/ and $path = $1;
# print($_, "\t", $path, "\n");
++$dirs{$path};
}
for (keys(%dirs)) {
$depth = tr/\///;
push(@{$counts[$depth]}, $dirs{$_});
}
for (1 .. $#counts) {
print($_, "\t", scalar(@{$counts[$_]}), "\t", sum(@{$counts[$_]}) / @{$counts[$_]}, "\n") if @{$counts[$_]};
}
---------------
to calculate the average number of subdirectories at each depth.
The result is (depth, number of times encountered, avg)
1 1 1
2 1 10
3 6 82.3333333333333
4 228 10.0833333333333
5 673 2.93610698365527
6 521 8.13435700575816
7 556 2.42446043165468
8 289 1.96193771626298
9 136 2.63970588235294
10 85 3.23529411764706
11 56 3.17857142857143
12 5 5
In other words (if the results are at least mostly correct :-), this
idea sucks dead hippopotamusses through nanotubes in the real world.
------------------------------
Date: Sat, 27 Jul 2013 18:51:40 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: lest talk a litle more about directories
Message-Id: <kt0qae$2s5g$1@news.ntua.gr>
Στις 27/7/2013 15:25, ο/η Rainer Weikusat έγραψε:
> "George Mpouras"
> <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
> writes:
>
> [...]
>
>> 3) The most wise approach is to define an array from all the upper
>> nodes. Then perform a binary tree search at this array against a node
>> existence code. This is give as log(N) accesses at worst case.
>>
>> So what is the best solution; Unfortunately there is not ….
>>
>> If your directories “usually” exist, the 2nd method will be the faster
>> because it will finish at the very first iterations.
>> If your directories “usually” do not exist, the 3rd method will be the
>> faster because it will dig faster at the bottomless abyss.
>
> [...]
>
>> mkdir_btree( 'd1/d2/d3/d4/d5' ) or die "$^E\n";
>>
>> sub mkdir_btree
>> {
>> my @array = split /[\/\\]/, $_[0];
>> return 1 if -1 == $#array;
>> $array[0] eq '' && splice @array, 0, 2, "/$array[1]";
>> my ($begin, $end) = (0, scalar @array);
>>
>> while ($begin < $end)
>> {
>> my $cut = int(($begin + $end)/2);
>> -d join('/', @array[0..$cut]) ? ($begin = $cut + 1) : ($end = $cut)
>> }
>>
>> return 1 unless $begin < @array;
>> mkdir(join '/', @array[0 .. $_]) || return 0 for $begin .. $#array;1
>> }
>
> The 'log(N) worst case' is not true: This algortihm has a constant
> overhead of log(N) stat calls for every case (this could be improved
> somewhat by using mkdir in the loop). This means it is worse than
> 'create from the top' when all directories have to be created and will
Do not forget that computers do not if the directories have to be
created. So it finds faster if they have to be.
> become worse than 'create from the bottom' if the number of
> subdirectories which have to be created at depth n is large enough
> that (m - 1) * log(n) stat calls amount to more work than what was avoided
> when creating the first subdirectory at this depth. The work saved
> when creating the first directory is (based on mkdir)
>
> 2n - 1 - n - log(n)
>
> This must be larger than (m - 1) * log(n) for the binary search to
> beneficial. Putting this together,
>
> 2n - 1 - n - log(n) > (m - 1) * log(n)
>
> this ends up as (Rechenfehler vorbehalten)
>
> (n - 1)/log(n) > m
>
> The /usr tree on the machine I used as example has a maximum depth of
> 12. Using this program,
>
> --------------
> sub log2
> {
> return log($_[0])/log(2);
> }
>
> sub threshold
> {
> return ($_[0] - 1) / log2($_[0]);
> }
>
> print($_, "\t", threshold($_), "\n") for 2 .. 12;
> --------------
>
> yields the following threshold values:
>
> 2 1
> 3 1.26185950714291
> 4 1.5
> 5 1.72270623229357
> 6 1.93426403617271
> 7 2.13724312264813
> 8 2.33333333333333
> 9 2.52371901428583
> 10 2.70926996097583
> 11 2.89064826317888
> 12 3.06837240216243
>
> (as soon as a directory at depth [first column] has more
> subdirectories than [second column], the algorithm sucks).
>
> I've used find /usr -type d to generate a list of directories, edited
> the first line to remove a trailing slash and then used the following
> program
>
> -------------
> use List::Util qw(sum);
>
> @ds = map {chomp; $_} <STDIN>;
>
> for (@ds) {
> /(.*?\/)[^\/]*$/ and $path = $1;
> # print($_, "\t", $path, "\n");
>
> ++$dirs{$path};
> }
>
> for (keys(%dirs)) {
> $depth = tr/\///;
> push(@{$counts[$depth]}, $dirs{$_});
> }
>
> for (1 .. $#counts) {
> print($_, "\t", scalar(@{$counts[$_]}), "\t", sum(@{$counts[$_]}) / @{$counts[$_]}, "\n") if @{$counts[$_]};
> }
> ---------------
>
> to calculate the average number of subdirectories at each depth.
> The result is (depth, number of times encountered, avg)
>
> 1 1 1
> 2 1 10
> 3 6 82.3333333333333
> 4 228 10.0833333333333
> 5 673 2.93610698365527
> 6 521 8.13435700575816
> 7 556 2.42446043165468
> 8 289 1.96193771626298
> 9 136 2.63970588235294
> 10 85 3.23529411764706
> 11 56 3.17857142857143
> 12 5 5
>
> In other words (if the results are at least mostly correct :-), this
> idea sucks dead hippopotamusses through nanotubes in the real world.
>
well good comments.
This idea do not sucks. When deep directories usually do not exist it is
the faster one.
------------------------------
Date: Sat, 27 Jul 2013 21:41:42 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: lest talk a litle more about directories
Message-Id: <kt1498$li5$1@news.ntua.gr>
> In other words (if the results are at least mostly correct :-), this
> idea sucks dead hippopotamusses through nanotubes in the real world.
>
the binary search is the fastest method to access a specific record on a
unknown data structure, that is why is often used from databases, but as
I said there is not one absolute answer. the fallowing factors must
considered before decide what to do on a specific machine:
* what is the timecost of a cpu cycle
* what is the timecost to ask for a node existense
* what is the timecost to create a node
* which is the statistical behaviour of the application
* what is the current status of your data
So the problem is not so determenistic after all
------------------------------
Date: Sat, 27 Jul 2013 19:52:29 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: lest talk a litle more about directories
Message-Id: <slrnkv899g.c9.willem@turtle.stack.nl>
George Mpouras wrote:
) Ok let???s talk about a little more about creating directories (or any other
) trie structure entries).
) There are three basic methods :
)
) 1) The simple, just start create them from top to bottom. This is give us
) N disk accesses always. Silly but do not underestimate it because it does
) not consume cpu.
)
) 2) The smarter. Search from bottom to top for the first existing node and
) start creating from this point and bellow; this is give us N only at the
) worst case.
)
) 3) The most wise approach is to define an array from all the upper nodes.
) Then perform a binary tree search at this array against a node existence
) code. This is give as log(N) accesses at worst case.
Have you considered the possibility that it takes O(N) disk accesses
to check if a directory (a1/a2/.../aN) exists ?
The OS will have to open a1, find a2, open a2, find a3, etc.
However, if you already have a handle to directory a2,
then checking or creating a3 is a single step.
If that is the case, method 1 will always be fastest.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Sat, 27 Jul 2013 20:26:44 +0000 (UTC)
From: gamo@telecable.es
Subject: Re: lest talk a litle more about directories
Message-Id: <kt1ae4$ko$1@speranza.aioe.org>
> my @array = split /[\/\\]/, $_[0];
-----------------------
I'm afraid that's not compatible with VMS
------------------------------
Date: Sat, 27 Jul 2013 23:31:40 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: lest talk a litle more about directories
Message-Id: <kt1and$16a9$1@news.ntua.gr>
Στις 27/7/2013 23:26, ο/η gamo@telecable.es έγραψε:
>> my @array = split /[\/\\]/, $_[0];
> -----------------------
>
> I'm afraid that's not compatible with VMS
>
>
this one maybe ? split /\/+/, $_[0];
what is the VMS ?
------------------------------
Date: Sat, 27 Jul 2013 23:39:52 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: lest talk a litle more about directories
Message-Id: <kt1b6q$180d$1@news.ntua.gr>
Στις 27/7/2013 23:26, ο/η gamo@telecable.es έγραψε:
>> my @array = split /[\/\\]/, $_[0];
> -----------------------
>
> I'm afraid that's not compatible with VMS
>
>
are you working in one of these ?
http://en.wikipedia.org/wiki/VAX
unbelievable cool !
------------------------------
Date: Sat, 27 Jul 2013 14:13:41 -0700
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: lest talk a litle more about directories
Message-Id: <6ppdcaxnld.ln2@goaway.wombat.san-francisco.ca.us>
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.
If you really believe that your methods are superior, you should write
them up as a patch to File::Path, so that others can thoroughly test
your code and include them in the module if they work properly.
--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: Sun, 28 Jul 2013 00:39:24 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: lest talk a litle more about directories
Message-Id: <kt1eme$1hgd$1@news.ntua.gr>
Στις 28/7/2013 00:13, ο/η Keith Keller έγραψε:
> 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.
>
> If you really believe that your methods are superior, you should write
> them up as a patch to File::Path, so that others can thoroughly test
> your code and include them in the module if they work properly.
>
> --keith
>
Thanks for the comment but for me, it is off topic . Are you interested
in Perl ? Are the modules a religion for you ?
------------------------------
Date: Sat, 27 Jul 2013 21:57:50 +0000 (UTC)
From: gamo@telecable.es
Subject: Re: lest talk a litle more about directories
Message-Id: <kt1fou$elo$1@speranza.aioe.org>
this one maybe ? split /\/+/, $_[0];
what is the VMS ?
-----------------------------
I don't think it works. As I badly remember directories in VMS are not
a special file, e.g. the command to change directory is SET DEF=
and it's not available to cd until the aparition of POSIX compatible
interface.
And why is important to be compatible with VMS/OpenVMS? Because it has
a security features very interesting. Last time I see it working with
a X interface was in a hidroelectrical power station, controlling the
open and close of gates to water.
VMS has other remarcable utilities as the EDT editor, since I use the
JED editor emulating EDT, with Perl syntax highlighting, of course.
------------------------------
Date: Sat, 27 Jul 2013 19:07:34 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: lest talk a litle more about directories
Message-Id: <87ppu3d2kp.fsf@new.chromatico.net>
>>>>> "GM" == George Mpouras <gravitalsun@hotmail.foo> writes:
GM> Στις 28/7/2013 00:13, ο/η Keith Keller έγραψε:
>> 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.
>>
>> If you really believe that your methods are superior, you should
>> write them up as a patch to File::Path, so that others can
>> thoroughly test your code and include them in the module if they
>> work properly.
GM> Thanks for the comment but for me, it is off topic . Are you
GM> interested in Perl ? Are the modules a religion for you ?
You know, if the sole object is to create directories as quickly as
possible, I bet C's an order of magnitude faster than Perl.
When you choose to use Perl in the first place, you are choosing to
optimize for programmer time over CPU time. To make that choice and
then to squander the benefits you get from it by writing buggy,
unportable code because you think it saves you time instead of
determining what your actual time requirements are and seeing if the
standard, well-tested, portable approach will suffice is fucking
moronic (and if that's what you want, PHP is *over there* and ColdFusion
is *down the hall*), and beyond that, it shows a fundamental lack of
understanding of what software engineering (as opposed to mere coding)
is about.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Sun, 28 Jul 2013 00:03:26 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: lest talk a litle more about directories
Message-Id: <u60eca-6oa2.ln1@anubis.morrow.me.uk>
Quoth gamo@telecable.es:
> this one maybe ? split /\/+/, $_[0];
> what is the VMS ?
> -----------------------------
>
> I don't think it works. As I badly remember directories in VMS are not
> a special file, e.g. the command to change directory is SET DEF=
> and it's not available to cd until the aparition of POSIX compatible
> interface.
Just use File::Spec (or one of the interfaces to it). That's what it's
there for.
(VMS has complicated path syntax rules. It supports Unix-style paths as
well as traditional VMS paths, which look like
'device:[dir.dir]file.ext;version'. AIUI it also supports quoting in the
path spec, so it's possible to have (for instance) a directory name with
a dot in it.)
Ben
------------------------------
Date: Sat, 27 Jul 2013 22:37:25 -0700
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: lest talk a litle more about directories
Message-Id: <l9necaxqai.ln2@goaway.wombat.san-francisco.ca.us>
On 2013-07-27, George Mpouras <gravitalsun@hotmail.foo> wrote:
>
> Thanks for the comment but for me, it is off topic .
What a stupid comment. File::Path may be offtopic for *you* but it is
certainly not for new Perl programmers who might be tempted to take your
bad advice.
> Are you interested in Perl ? Are the modules a religion for you ?
No, but I'm not clueless enough to presume that I can do better than
people who have been contributing to Perl's core for many years.
If you're just playing around for kicks, that's your business. But it's
ridiculous to assume that your methods are worth recommending,
especially to people new to Perl, over module code that has been in
production use for years. You may never realize that, but it's still
important for people who care about Perl to warn new programmers against
bad coding practice.
--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: Sun, 28 Jul 2013 12:54:36 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: lest talk a litle more about directories
Message-Id: <kt2pov$1dr5$1@news.ntua.gr>
> If you're just playing around for kicks, that's your business.
I like this place for discussing interesting things. if you want to kick
something kick yourself
George
------------------------------
Date: Sun, 28 Jul 2013 11:00:49 +0100
From: Henry Law <news@lawshouse.org>
Subject: Re: lest talk a litle more about directories
Message-Id: <r9WdnWkCaO9MdmnMnZ2dnUVZ8qydnZ2d@giganews.com>
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.
--
Henry Law Manchester, England
------------------------------
Date: Sat, 27 Jul 2013 01:21:30 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: three computing drawbacks
Message-Id: <ksusp9$1js5$1@news.ntua.gr>
> 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 ?
------------------------------
Date: Fri, 26 Jul 2013 17:13:55 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: three computing drawbacks
Message-Id: <260720131713556518%jimsgibson@gmail.com>
In article <ksusp9$1js5$1@news.ntua.gr>, George Mpouras
<nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> wrote:
> > 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 ?
I am not using Thunderbird. My Usenet reader only shows one message at
a time. I believe many Usenet readers do the same. This is preferrable
to me, as I do not wish to see the entire thread each time I read the
newest posting.
If I want to see previous messages, I have to click on a link to see
the entire previous message, which does not have the latest posting in
it.
Therefore: yes, quoting to what your are responding is important for
some of us.
--
Jim Gibson
------------------------------
Date: Sat, 27 Jul 2013 08:57:04 -0600
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: three computing drawbacks
Message-Id: <kt0mod$krm$1@dont-email.me>
On 7/26/2013 4:21 PM, George Mpouras wrote:
> Do you think quoting is so important any more with the tree view
> readers like thunderbid ?
I use Thunderbird, but I don't have it in tree view mode. I have it sort
posts by date. That way the most recent posts are at the bottom, and I
don't have to go looking for them. So, even for users of Thunderbird,
quoting can be very helpful.
------------------------------
Date: Sat, 27 Jul 2013 18:59:51 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: three computing drawbacks
Message-Id: <87txjfd2xk.fsf@new.chromatico.net>
>>>>> "GM" == George Mpouras
>>>>> <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
>>>>> writes:
>> It would be a courtesy if you would start quoting enough context
>> to make your posts comprehensible.
GM> Do you think quoting is so important any more with the tree view
GM> readers like thunderbid ?
Point the first: if I did not, would I have admonished you for not
quoting?
Point the second: it would be a further courtesy if you did not make
unwarranted assumptions about what tools other people use.
When you write a post with no context whatsoever and impose a burden on
me of having to figure out what you're responding to before I determine
whether you're talking out of your ass or not, you move the default
assumption to "he's talking out of his ass" and you move the bozometer
one notch closer to "plonk." You may not care about that, but I
consider it a courtesy to warn you that you are barreling at high speed
down that path.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Sun, 28 Jul 2013 03:54:54 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: three computing drawbacks
Message-Id: <uodeca-qrs.ln1@anubis.morrow.me.uk>
Quoth Charlton Wilbur <cwilbur@chromatico.net>:
> >>>>> "GM" == George Mpouras
> >>>>> <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
> >>>>> writes:
>
> >> It would be a courtesy if you would start quoting enough context
> >> to make your posts comprehensible.
>
> GM> Do you think quoting is so important any more with the tree view
> GM> readers like thunderbid ?
>
> Point the first: if I did not, would I have admonished you for not
> quoting?
>
> Point the second: it would be a further courtesy if you did not make
> unwarranted assumptions about what tools other people use.
>
> When you write a post with no context whatsoever and impose a burden on
> me of having to figure out what you're responding to before I determine
> whether you're talking out of your ass or not, you move the default
> assumption to "he's talking out of his ass" and you move the bozometer
> one notch closer to "plonk." You may not care about that, but I
> consider it a courtesy to warn you that you are barreling at high speed
> down that path.
It may or may not interest you to know that I currently have three
killfile entries for George, because he keeps changing his posting
address:
/"George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam>/f:j
/George Bouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>/f:j
/gravitalsun/f:j
Ben
------------------------------
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 4003
***************************************
