[32738] in Perl-Users-Digest
Perl-Users Digest, Issue: 4002 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jul 26 18:09:30 2013
Date: Fri, 26 Jul 2013 15: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 Fri, 26 Jul 2013 Volume: 11 Number: 4002
Today's topics:
Re: [OT] engineering <rui.maciel@gmail.com>
lest talk a litle more about directories <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: lest talk a litle more about directories <rweikusat@mssgmbh.com>
min (), and Perl modules <oneingray@gmail.com>
Re: min (), and Perl modules (Tim McDaniel)
Re: No more than N element of an array <ben@morrow.me.uk>
Re: No more than N element of an array <derykus@gmail.com>
Re: No more than N element of an array <hjp-usenet3@hjp.at>
Re: No more than N element of an array <ben@morrow.me.uk>
Re: No more than N element of an array <derykus@gmail.com>
Re: No more than N element of an array (Tim McDaniel)
Re: No more than N element of an array <rweikusat@mssgmbh.com>
Re: No more than N element of an array <ben@morrow.me.uk>
Re: No more than N element of an array <ben@morrow.me.uk>
One 704 to rule them all <rweikusat@mssgmbh.com>
Re: three computing drawbacks (Seymour J.)
Re: three computing drawbacks <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: three computing drawbacks <cwilbur@chromatico.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 26 Jul 2013 10:09:21 +0100
From: Rui Maciel <rui.maciel@gmail.com>
Subject: Re: [OT] engineering
Message-Id: <kste06$r64$2@dont-email.me>
Ivan Shmakov wrote:
> [...]
>
> ... Once, I will find the patience to wait for the food
> engineers out there to design a sound nutritional solution.
>
> Meanwhile, I'm forced to rely on the off-the-shelf products,
> which are known to be full of undocumented features, deviate
> from the specifications every now and then, and (while I'm yet
> to see one myself) are reported to contain actual bugs...
>
> [Cross-posting to news:alt.food and news:comp.programming.
> Just in case.]
All engineering relies on off-the-shelf products. The shelf, though, does
depend on the circumstances and requirements. Nevertheless, it's off-the-
shelf all the way down to the turtles, if you will.[1]
Rui Maciel
[1] http://en.wikipedia.org/wiki/Turtles_all_the_way_down
------------------------------
Date: Fri, 26 Jul 2013 22:12:35 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: lest talk a litle more about directories
Message-Id: <ksuhn2$mck$1@news.ntua.gr>
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.
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.
Because the 2nd method is almost trivila I will write the code only for the
3rd binary tree method
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
}
Also here is small benchmark. If you want to test it , (its better to run it
multiple times)
#!/usr/bin/perl
# Dir creation benchmark
use strict;
use warnings;
use Time::HiRes;
use File::Path;
my $how_many = 1000;
my $how_deep = 40;
my $root_test_dir = '/tmp/test_this';
# create the dirs array;
print "Creating the test dirs array\n";
my @Test_dirs;
my $start_time=[];
for (0 .. $how_many) { my @R = $root_test_dir;
for (0 .. $how_deep) {
push @R, sprintf "%s%02d", ('a'..'z')[int(rand 24)], int(rand 100) }
push @Test_dirs, join('/',@R) }
foreach my $code (qw/
Mkdir_recursive
mkdir_btree
File_Path_module
/){
system("/bin/rm -rf $root_test_dir") if -d $root_test_dir;
$start_time = [ Time::HiRes::gettimeofday ];
print "Testing $code ... ";
foreach (@Test_dirs) { &{\&$code}($_) or die("$!") }
print "finished at ", Time::HiRes::tv_interval($start_time) ," sec\n"
}
sub File_Path_module
{
my $err;
File::Path::mkpath( $_[0], {'error' => \$err} );
@{$err} ? 0 : 1
}
sub Mkdir_recursive
{
return 1 if $_[0] eq '' || -d $_[0];
Mkdir_recursive( $_[0] =~/^(.*?)\/[^\/]+$/ ) || return undef;
mkdir $_[0] || return undef
}
sub mkdir_btree
{
my @array = split /\//, $_[0];
return 1 if -1 == $#array;
$array[0] eq '' && splice @array, 0, 2, "/$array[1]";
splice @array, 0, 2, "/$array[1]" if '' eq $array[0];
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
}
END {
print "Clearing test dir: $root_test_dir\n";
system("/bin/rm -rf $root_test_dir") if -d $root_test_dir }
------------------------------
Date: Fri, 26 Jul 2013 21:17:46 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: lest talk a litle more about directories
Message-Id: <87mwp92hzp.fsf@sapphire.mobileactivedefense.com>
"George Mpouras"
<nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
writes:
> 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.
As I already tried to tell you last time: Method 1 tuned for the case
where most directories have to be created and method 2 for the case
where most directories already exist. Both stat (the system call
behind the -X) and mkdir need to determine information about a
particular directory entry, stat because that's what it is supposed to
do and mkdir because it must not do anything if this directory entry
already exists. This means creating all directories in the path
/a/b/c/d from scratch will perform first perform for stat calls,
stat("/a/b/c/d")
stat("/a/b/c")
stat("a/b");
stat("/a");
which will fail with ENOENT, followed by four mkdir calls,
mkdir("/a");
mkdir("/a/b");
mkdir("/a/b/c");
mkdir("/a/b/c/d");
for the 'backward' method while the other will just do the 'mkdirs'.
>> 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.
>
> Because the 2nd method is almost trivila I will write the code only
> for the 3rd binary tree method
>
>
> mkdir_btree( 'd1/d2/d3/d4/d5' ) or die "$^E\n";
>
> sub mkdir_btree
> {
> my @array = split /[\/\\]/, $_[0];
I don't know this is for Windows, but a valid UNIX(*) pathname may use
any number of slashes to separate two directories,
[rw@sapphire]~ $perl -e "chdir('//////////////'); system('pwd');"
/
------------------------------
Date: Fri, 26 Jul 2013 15:16:30 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: min (), and Perl modules
Message-Id: <87ob9pqrld.fsf_-_@violet.siamics.net>
>>>>> Tim McDaniel <tmcd@panix.com> writes:
>>>>> Charles DeRykus <derykus@gmail.com> wrote:
>> You could tweak it via with [0..min($#results,MAXSEARCRESULTS)]
> There's a min sub somewhere?
> $ perl -e 'my $a = min(5,8); print $a, "\n"'
> Undefined subroutine &main::min called at -e line 1.
> Since this is my ork-place, I don't have control of modules.
How so? Doesn't $ export PERLLIB="$HOME"/.perl/modules help,
for instance?
--cut: ~/.bash_profile --
CPAN=${HOME}/.cpan
cpan_pfx=${CPAN}/prefix
perl_ver=5.14.2
PERLLIB=${cpan_pfx}/lib/perl/5.14.2\
:${cpan_pfx}/share/perl/5.14.2\
:${cpan_pfx}/lib/perl5\
:${cpan_pfx}/lib/perl\
:${cpan_pfx}/share/perl5\
:${cpan_pfx}/lib/perl/5.14\
:${cpan_pfx}/share/perl/5.14\
:${cpan_pfx}/lib/perl5/x86_64-linux-gnu-thread-multi
export CPAN PERLLIB
--cut: ~/.bash_profile --
--
FSF associate member #7257
------------------------------
Date: Fri, 26 Jul 2013 16:17:39 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: min (), and Perl modules
Message-Id: <ksu7f3$ogk$1@reader1.panix.com>
In article <87ob9pqrld.fsf_-_@violet.siamics.net>,
Ivan Shmakov <oneingray@gmail.com> wrote:
> Tim McDaniel <tmcd@panix.com> writes:
> > Since this is my ork-place, I don't have control of modules.
>
> How so? Doesn't $ export PERLLIB="$HOME"/.perl/modules help,
> for instance?
This is not for my personal laptop. This is for production code on a
Web server. I can check in new files, so I could download some module
and put it in our section of the tree. But they have reasonable
suspicions of third-party code and it's generally better to use
builtins.
Or, of course, it would be easy for me to code a min sub.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Fri, 26 Jul 2013 09:00:12 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: No more than N element of an array
Message-Id: <ctm9ca-mc3.ln1@anubis.morrow.me.uk>
Quoth Charles DeRykus <derykus@gmail.com>:
> On 7/25/2013 9:12 PM, Ben Morrow wrote:
> >
> > Quoth tmcd@panix.com:
> >> A cow-orker is coding something: he gets an array of results, but
> >> wants to take no more than the first 1000 elements. His suggestion was
[...]
> >> Is there a cleaner way?
> >
> > Perhaps
> >
> > @results = splice @results, 0, MAXSEARCHRESULTS;
>
> If fewer strokes were to factor into cleanliness, even:
>
> @results = @results[0..MAXSEARCHRESULTS];
Tim already pointed out that this returns extraneous undefs if @results
is too short.
> But, as you grow array size and MAXSEARCHRESULTS, it gets filthy slow...
>
> Setting $#results = MAXSEARCHRESULTS undoubtedly comes out of the wash
> purest and fastest.
It's probably easiest, though turning off the warning and using Tim's
splice @results, MAXSEARCHRESULTS - 1;
is probably better, on balance. Using $#ary as an lvalue has some
permanent side-effects on the array; you can see them with Devel::Peek.
[The side-effects are to do with the fact that $#ary is a scalar lvalue
and \$#ary should return a ref to the same scalar every time, so we need
an actual permanent scalar somewhere, which turns out to get stored in
the array's magic.]
Ben
------------------------------
Date: Fri, 26 Jul 2013 02:19:10 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: No more than N element of an array
Message-Id: <kstev5$71k$1@speranza.aioe.org>
On 7/26/2013 1:00 AM, Ben Morrow wrote:
>
> Quoth Charles DeRykus <derykus@gmail.com>:
>> On 7/25/2013 9:12 PM, Ben Morrow wrote:
>>>
>>> Quoth tmcd@panix.com:
>>>> A cow-orker is coding something: he gets an array of results, but
>>>> wants to take no more than the first 1000 elements. His suggestion was
> [...]
>>>> Is there a cleaner way?
>>>
>>> Perhaps
>>>
>>> @results = splice @results, 0, MAXSEARCHRESULTS;
>>
>> If fewer strokes were to factor into cleanliness, even:
>>
>> @results = @results[0..MAXSEARCHRESULTS];
>
> Tim already pointed out that this returns extraneous undefs if @results
> is too short.
Sigh, I missed it.
You could tweak it via with [0..min($#results,MAXSEARCRESULTS)] but,
aside from the purist's objection of adding a module, it should be DOA
anyway with its inefficiency (I'm guessing that it does more copying so
is slower).
>
>> But, as you grow array size and MAXSEARCHRESULTS, it gets filthy slow...
>>
>> Setting $#results = MAXSEARCHRESULTS undoubtedly comes out of the wash
>> purest and fastest.
>
> It's probably easiest, though turning off the warning and using Tim's
>
> splice @results, MAXSEARCHRESULTS - 1;
>
> is probably better, on balance.
Turning off a warning category seems slightly unclean to me... even
though it's only because of the earlier version.
Using $#ary as an lvalue has some
> permanent side-effects on the array; you can see them with Devel::Peek.
>
> [The side-effects are to do with the fact that $#ary is a scalar lvalue
> and \$#ary should return a ref to the same scalar every time, so we need
> an actual permanent scalar somewhere, which turns out to get stored in
> the array's magic.]
>
Interesting. IIUC any real downside other than the extra storage in
magic? I thought I remembered truncating via $#ary doesn't return the
memory to the process unlike undef @ary.
--
Charles DeRykus
------------------------------
Date: Fri, 26 Jul 2013 11:32:45 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: No more than N element of an array
Message-Id: <slrnkv4ght.pe3.hjp-usenet3@hrunkner.hjp.at>
On 2013-07-26 09:19, Charles DeRykus <derykus@gmail.com> wrote:
> On 7/26/2013 1:00 AM, Ben Morrow wrote:
>> Quoth Charles DeRykus <derykus@gmail.com>:
>>> @results = @results[0..MAXSEARCHRESULTS];
>>
>> Tim already pointed out that this returns extraneous undefs if @results
>> is too short.
>
> Sigh, I missed it.
>
> You could tweak it via with [0..min($#results,MAXSEARCRESULTS)] but,
> aside from the purist's objection of adding a module, it should be DOA
> anyway with its inefficiency (I'm guessing that it does more copying so
> is slower).
Why should @results[0..min($#results,MAXSEARCRESULTS)] do more copying
than @results[0..MAXSEARCHRESULTS]?
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpat. -- Ralph Babel
------------------------------
Date: Fri, 26 Jul 2013 11:26:56 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: No more than N element of an array
Message-Id: <ggv9ca-j84.ln1@anubis.morrow.me.uk>
Quoth Charles DeRykus <derykus@gmail.com>:
> On 7/26/2013 1:00 AM, Ben Morrow wrote:
> >
> > It's probably easiest, though turning off the warning and using Tim's
> >
> > splice @results, MAXSEARCHRESULTS - 1;
> >
> > is probably better, on balance.
>
> Turning off a warning category seems slightly unclean to me... even
> though it's only because of the earlier version.
If you say so. I would say, the reason you can turn them off is because
sometimes it's the right thing to do. If this were only true in
exceptional situations then 5005's local $^W would have been good
enough.
> Using $#ary as an lvalue has some
> > permanent side-effects on the array; you can see them with Devel::Peek.
> >
> > [The side-effects are to do with the fact that $#ary is a scalar lvalue
> > and \$#ary should return a ref to the same scalar every time, so we need
> > an actual permanent scalar somewhere, which turns out to get stored in
> > the array's magic.]
>
> Interesting. IIUC any real downside other than the extra storage in
> magic?
No, I don't think so.
> I thought I remembered truncating via $#ary doesn't return the
> memory to the process unlike undef @ary.
That's correct. Neither does splice. In fact, I don't think it's
possible to reduce the allocated length of an array, except by entirely
clearing it.
Ben
------------------------------
Date: Fri, 26 Jul 2013 03:38:08 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: No more than N element of an array
Message-Id: <kstjj7$k56$1@speranza.aioe.org>
On 7/26/2013 2:32 AM, Peter J. Holzer wrote:
> On 2013-07-26 09:19, Charles DeRykus <derykus@gmail.com> wrote:
>> On 7/26/2013 1:00 AM, Ben Morrow wrote:
>>> Quoth Charles DeRykus <derykus@gmail.com>:
>>>> @results = @results[0..MAXSEARCHRESULTS];
>>>
>>> Tim already pointed out that this returns extraneous undefs if @results
>>> is too short.
>>
>> Sigh, I missed it.
>>
>> You could tweak it via with [0..min($#results,MAXSEARCRESULTS)] but,
>> aside from the purist's objection of adding a module, it should be DOA
>> anyway with its inefficiency (I'm guessing that it does more copying so
>> is slower).
>
> Why should @results[0..min($#results,MAXSEARCRESULTS)] do more copying
> than @results[0..MAXSEARCHRESULTS]?
>
The min(..) tweak was to eliminate the padding with undef that occurs if
MAXSEARCHRESULTS > $#results. In general, I was referring to a
supposition (guessing as I put it) that @results = @results[...] will
likely do more copying than say splice(@results,MAXSEARCHRESULTS). At
any rate, it's slower.
--
Charles DeRykus
------------------------------
Date: Fri, 26 Jul 2013 14:27:03 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: No more than N element of an array
Message-Id: <ksu0vn$jbc$1@reader1.panix.com>
In article <kstev5$71k$1@speranza.aioe.org>,
Charles DeRykus <derykus@gmail.com> wrote:
>You could tweak it via with [0..min($#results,MAXSEARCRESULTS)]
There's a min sub somewhere?
$ perl -e 'my $a = min(5,8); print $a, "\n"'
Undefined subroutine &main::min called at -e line 1.
Since this is my ork-place, I don't have control of modules.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Fri, 26 Jul 2013 16:38:47 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: No more than N element of an array
Message-Id: <87txjh2uwo.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Charles DeRykus <derykus@gmail.com>:
>> On 7/25/2013 9:12 PM, Ben Morrow wrote:
[...]
>> Setting $#results = MAXSEARCHRESULTS undoubtedly comes out of the wash
>> purest and fastest.
>
> It's probably easiest, though turning off the warning and using Tim's
>
> splice @results, MAXSEARCHRESULTS - 1;
>
> is probably better, on balance. Using $#ary as an lvalue has some
> permanent side-effects on the array; you can see them with Devel::Peek.
>
> [The side-effects are to do with the fact that $#ary is a scalar lvalue
> and \$#ary should return a ref to the same scalar every time, so we need
> an actual permanent scalar somewhere, which turns out to get stored in
> the array's magic.]
While there is little reason to prefer one or the other, I
nevertheless want to make an argument in favor of assigning to $#ary:
'Splicing' usually refers to connecting things together. This can
still be seen in the '4 argument splice' which 'works' the contents of
a list into an array. It is a more general 'array element manipulation
operator' in Perl but statements like
"splice(@a, @a, 0, $x, $y) is equivalent to push(@a, $x, $y)"
[paraphrase of a part of 'perldoc -f splice']
remind me in an uncanny way of something I read about 'lambda
calculus' a while ago: The statement basically was "This (short string
of incomprehensible symbols) can be simplified to that (extremely long
string of incomprehensible symbols)". At this point, I concluded that
either me or the author of the text had obviously lost the plot and
that I'd rather continue to live in my own little world than endure
more relevations of this kind. The splice-operation I quoted above is
similar to this, expressing a relatively simple 'well-known' operation
in a more complicated way than necessary by invoking splice with two
additional arguments (compared to push) in order to work around the
'actual' semantics of the 4-argument splice, namely, replace some run
of array elements with a run of other "datas" (datums?). Making the
simple appear complicated may be good for achieving a "Wow!" effect
but it isn't a good strategy for software: Things tend to get
complicated on their own and the more complicated the simple stuff
already is, the less complicated the system as a whole can become
before it collapses under its own weight. That splice can be made to
perform many different array manipulation tasks IMO means it is
ill-defined and should usually be avoided. For the case at hand,
namely, truncating an array without knowing if it needs to be
truncated, the 'clever way to use splice' is actually so 'ill' that
perl even issues a warning for it. While I don't usually use Perl
runtime warnings and would recommend to disregard them most of the
time, this is at least a clear hint that someone considered this to be
a rather bizarre way to express a particular operation.
In contrast to this, 'assigning to $#ary' has the defined meaning of
'change the length of the array', maybe in a way peculiar to Perl (I
don't know of anything similar in another language) but "Perl written
in a way peculiar to Perl" is, in my opinion, not generally a bad
thing, more so if this means 'the code becomes simpler'. I do
consider
$#a = SOMETHING - 1 unless $#a < SOMETHING;
simpler than the more 'elegant' splice(@a, SOMETHING) which
performs the same 'Do we actually need to do something?' check
internally as part of validating its arguments, because it plainly
states the intent of the code: Get rid of the excess elements unless
there aren't any.
I don't think that 'But my arrays get the measles when I do that!'
is a valid counterargument: The magic scalar needs to be created in
order to perform this operation via assignment and once it has been
created, it makes sense to keep it around unless memory is very tight:
If the array is short-lived, freeing it at the same time its container
dies instead of immediately won't make a noticeable difference but if
it is long-lived, it will likely be needed again, at least because
this codepath will be taken again, and then, the proxy scalar doesn't
need to be created again.
------------------------------
Date: Fri, 26 Jul 2013 16:39:18 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: No more than N element of an array
Message-Id: <6qhaca-jv5.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <kstev5$71k$1@speranza.aioe.org>,
> Charles DeRykus <derykus@gmail.com> wrote:
> >You could tweak it via with [0..min($#results,MAXSEARCRESULTS)]
>
> There's a min sub somewhere?
List::Util.
> $ perl -e 'my $a = min(5,8); print $a, "\n"'
> Undefined subroutine &main::min called at -e line 1.
>
> Since this is my ork-place, I don't have control of modules.
Fortunately, it's core.
Ben
------------------------------
Date: Fri, 26 Jul 2013 19:23:56 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: No more than N element of an array
Message-Id: <seraca-kp8.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Charles DeRykus <derykus@gmail.com>:
>
> >> Setting $#results = MAXSEARCHRESULTS undoubtedly comes out of the wash
> >> purest and fastest.
> >
> > It's probably easiest, though turning off the warning and using Tim's
> >
> > splice @results, MAXSEARCHRESULTS - 1;
> >
> > is probably better, on balance. Using $#ary as an lvalue has some
> > permanent side-effects on the array; you can see them with Devel::Peek.
>
> While there is little reason to prefer one or the other, I
> nevertheless want to make an argument in favor of assigning to $#ary:
>
> 'Splicing' usually refers to connecting things together. This can
> still be seen in the '4 argument splice' which 'works' the contents of
> a list into an array.
'Splice' is not an ideal name for the operation; however, it's no worse
than 'substr', which is exactly the same operator on strings.
> It is a more general 'array element manipulation
> operator' in Perl but statements like
>
> "splice(@a, @a, 0, $x, $y) is equivalent to push(@a, $x, $y)"
> [paraphrase of a part of 'perldoc -f splice']
[...]
> The splice-operation I quoted above is
> similar to this, expressing a relatively simple 'well-known' operation
> in a more complicated way than necessary by invoking splice with two
> additional arguments (compared to push) in order to work around the
> 'actual' semantics of the 4-argument splice, namely, replace some run
> of array elements with a run of other "datas" (datums?). Making the
> simple appear complicated may be good for achieving a "Wow!" effect
> but it isn't a good strategy for software:
Did it occur to you that this was not intended to explain what 'push'
does, but rather to help explain what 'splice' does? I would agree with
you that the push is a simpler expression than the splice, but for
example the similar equivalence
shift(@a) splice(@a, 0, 1)
shows you how to use splice to shift multiple elements at once.
(Incidentally, that push equivalence would be rather clearer written as
splice(@a, scalar(@a), 0, $x, $y)
even though splice's 'prototype' will force scalar context for you.)
> Things tend to get
> complicated on their own and the more complicated the simple stuff
> already is, the less complicated the system as a whole can become
> before it collapses under its own weight. That splice can be made to
> perform many different array manipulation tasks IMO means it is
> ill-defined and should usually be avoided. For the case at hand,
> namely, truncating an array without knowing if it needs to be
> truncated, the 'clever way to use splice' is actually so 'ill' that
> perl even issues a warning for it.
The warning was unintentional, and was therefore removed in 5.16. The
case it was intended to warn about was when an explicit range was
specified which was entirely outside the array.
> In contrast to this, 'assigning to $#ary' has the defined meaning of
> 'change the length of the array', maybe in a way peculiar to Perl (I
> don't know of anything similar in another language) but "Perl written
> in a way peculiar to Perl" is, in my opinion, not generally a bad
> thing, more so if this means 'the code becomes simpler'. I do
> consider
>
> $#a = SOMETHING - 1 unless $#a < SOMETHING;
>
> simpler than the more 'elegant' splice(@a, SOMETHING) which
> performs the same 'Do we actually need to do something?' check
> internally as part of validating its arguments, because it plainly
> states the intent of the code: Get rid of the excess elements unless
> there aren't any.
>
> I don't think that 'But my arrays get the measles when I do that!'
> is a valid counterargument:
I don't think it's a strong argument. I do think it's a weak argument,
especially when there's another operator that does a perfectly good job.
> The magic scalar needs to be created in
> order to perform this operation via assignment and once it has been
> created, it makes sense to keep it around unless memory is very tight:
> If the array is short-lived, freeing it at the same time its container
> dies instead of immediately won't make a noticeable difference but if
> it is long-lived, it will likely be needed again, at least because
> this codepath will be taken again, and then, the proxy scalar doesn't
> need to be created again.
I would not necessarily expect either of those to be true. It's not at
all uncommon for a sub to return a data structure which then goes on to
be rather long-lived, without ever going back through the code which
created it.
Ben
------------------------------
Date: Fri, 26 Jul 2013 21:49:57 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: One 704 to rule them all
Message-Id: <87iozx2gi2.fsf@sapphire.mobileactivedefense.com>
Tidbit of LISP history I came across recently:
The erasure problem also had to be considered, and it was
clearly unaesthetic to use explicit erasure as did IPL. There
were two alternatives. The first was to erase the old contents
of a program variable whenever it was updated. Since the car
and cdr operations were not to copy structure, merging list
structure would occur, and erasure would require a system of
reference counts. Since there were only six bits left in a
word, and these were in separated parts of the word, reference
counts seemed infeasible without a drastic change in the way
list structures were represented. (A list handling scheme
using reference counts was later used by Collins (1960) on a
48 bit CDC computer).
The second alternative is garbage collection in which storage
is abandoned until the free storage list is exhausted, the
storage accessible from program variables and the stack is
marked, and the unmarked storage is made into a new free
storage list. Once we decided on garbage collection, its
actual implementation could be postponed, because only toy
examples were being done.
http://www-formal.stanford.edu/jmc/history/lisp/node3.html#SECTION00030000000000000000
'Erasure' refers to 'freeing allocated memory'. This implies that 'the
tracing garbage collector' wasn't invented by McCarthy because he
considered it a superior method of automatic memory management but was
a makeshift approach chosen because limitations of the IBM 704
hardware made using reference counting 'infeasible', given the
cons cell implementation which already existed at the time the 'memory
management problem' was starting to be considered with "We don't
absolutely have to solve this now, but do it 'somehow' in future"
being a secondary concern (according to other sources, the actual
garbage collector was later developed by a student who had to work
within the constraints of the existing system).
Isn't it amazing that - until today - automatic resource management is
held back by deficiencies inherent in a workaround for the word size
of a computer which looked like this?
http://en.wikipedia.org/wiki/File:IBM_Electronic_Data_Processing_Machine_-_GPN-2000-001881.jpg
To be fair to 'the Perl 6 people': The problem with reference
counting is that while it is convenient for language users because it
implies that all kinds of resources can be managed automatically in a
'lexically scoped way', it does exactly nothing for language
implementors as the pairs (<allocate memory>, <free memory>) and
(<increment ref count>, <decrement refcount>) are obviously
equivalent.
------------------------------
Date: Wed, 24 Jul 2013 09:31:46 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: three computing drawbacks
Message-Id: <51efd742$9$fuzhry+tra$mr2ice@news.patriot.net>
In <ksn2a9$2umn$1@news.ntua.gr>, on 07/24/2013
at 02:06 AM, "George Mpouras"
<nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> said:
>I remember solving differential equations with capacitors and coils
>at the lab.
Google for "analog computer".
--
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: Fri, 26 Jul 2013 23:14:28 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: three computing drawbacks
Message-Id: <ksulb3$vud$1@news.ntua.gr>
I have first pesrson experience Shmuel !
------------------------------
Date: Fri, 26 Jul 2013 17:23:54 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: three computing drawbacks
Message-Id: <87y58tc8wl.fsf@new.chromatico.net>
>>>>> "GM" == George Mpouras
>>>>> <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
>>>>> writes:
GM> I have first pesrson experience Shmuel !
It would be a courtesy if you would start quoting enough context to make
your posts comprehensible.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
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 4002
***************************************
