[33109] in Perl-Users-Digest
Perl-Users Digest, Issue: 4385 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Mar 8 16:09:22 2015
Date: Sun, 8 Mar 2015 13:09:06 -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, 8 Mar 2015 Volume: 11 Number: 4385
Today's topics:
d <gravitalsun@hotmail.foo>
Re: d <peter@makholm.net>
Re: d <gravitalsun@hotmail.foo>
Re: d <rweikusat@mobileactivedefense.com>
Re: d <gravitalsun@hotmail.foo>
Re: d <rweikusat@mobileactivedefense.com>
each ARRAY (was: function returning a list of the indic <hjp-usenet3@hjp.at>
Re: variable expansion issue <bauhaus@futureapps.invalid>
Re: variable expansion issue <bauhaus@futureapps.invalid>
Re: variable expansion issue <m@rtij.nl.invlalid>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Re: variable expansion issue <bauhaus@futureapps.invalid>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Re: variable expansion issue <bauhaus@futureapps.invalid>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Re: variable expansion issue <news@todbe.com>
Re: variable expansion issue <bauhaus@futureapps.invalid>
Re: variable expansion issue <hjp-usenet3@hjp.at>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 08 Mar 2015 01:06:36 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: d
Message-Id: <mdg09s$md9$1@news.ntua.gr>
#!/usr/bin/perl
use strict; use warnings; use feature qw/say/;
my %hash1= (key=> ['v1','v2']);
use Data::Dumper; print Dumper \%hash1;
F();
use Data::Dumper; print Dumper \%hash1;
sub F
{
my %hash2;
foreach (keys %hash1) {$hash2{$_}=$hash1{$_}}
foreach (@{$hash2{key}})
{
$_=''
}
}
------------------------------
Date: Sun, 08 Mar 2015 10:30:28 +0100
From: Peter Makholm <peter@makholm.net>
Subject: Re: d
Message-Id: <87r3szeszv.fsf@vps1.hacking.dk>
George Mpouras <gravitalsun@hotmail.foo> writes:
> my %hash1= (key=> ['v1','v2']);
> use Data::Dumper; print Dumper \%hash1;
> F();
> use Data::Dumper; print Dumper \%hash1;
Not sure what you point is, but it is to be expected that F() changes
the content indirectly referenced by %hash1.
Complex datastructures in Perl are based on references to arrays and
hashes. References are a first class value (and not just an internal
implementation detail) which is just copied in the assignment.
That is '$foo = $hashref' means that $foo wil reference *the* *same*
hash that $hashref is supposedly references and not a deep copy. So when
F() makes a copy of the array references and then makes changes through
this reference it is changing the original array.
If you want a deep copy you need to do it explicitly, for example by
using Storable::dclone()
//Makholm
------------------------------
Date: Sun, 08 Mar 2015 13:36:51 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: d
Message-Id: <mdhc8l$25hh$1@news.ntua.gr>
> That is '$foo = $hashref' means that $foo wil reference *the* *same*
its not hashref its copy of flat values
> If you want a deep copy you need to do it explicitly, for example by
> using Storable::dclone()
dclone should not needed if the value is anonymous array
------------------------------
Date: Sun, 08 Mar 2015 19:41:43 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: d
Message-Id: <87h9tvgtu0.fsf@doppelsaurus.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
"The code"
,----
| #!/usr/bin/perl
| use strict; use warnings; use feature qw/say/;
|
| my %hash1= (key=> ['v1','v2']);
| use Data::Dumper; print Dumper \%hash1;
| F();
| use Data::Dumper; print Dumper \%hash1;
|
| sub F
| {
| my %hash2;
| foreach (keys %hash1) {$hash2{$_}=$hash1{$_}}
|
| foreach (@{$hash2{key}})
| {
| $_=''
| }
| }
`----
>> That is '$foo = $hashref' means that $foo wil reference *the* *same*
>
> its not hashref its copy of flat values
If (as in the example above) $hash1{key} references an anonymous array,
$hash2{key} will end up referencing the same anonymous array after a
$hash2{key} = $hash1{key};
The 2nd loop then modifies the value in the shared array.
------------------------------
Date: Sun, 08 Mar 2015 21:47:00 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: d
Message-Id: <mdi8vl$1n3l$1@news.ntua.gr>
On 8/3/2015 9:41 μμ, Rainer Weikusat wrote:
> foreach (keys %hash1) {$hash2{$_}=$hash1{$_}}
it should be a different anonymous array with the same data
this is a copy $hash2{$_}=$hash1{$_}
this is a ref $hash2{$_}=\$hash1{$_}
------------------------------
Date: Sun, 08 Mar 2015 19:58:04 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: d
Message-Id: <87d24jgt2r.fsf@doppelsaurus.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> On 8/3/2015 9:41 μμ, Rainer Weikusat wrote:
>> foreach (keys %hash1) {$hash2{$_}=$hash1{$_}}
>
> it should be a different anonymous array with the same data
>
> this is a copy $hash2{$_}=$hash1{$_}
> this is a ref $hash2{$_}=\$hash1{$_}
If you want it to be a different anonymous array with the same data, you
have to copy the array and not the scalar pointing at it. That would be
@{$hash2{$_}} = @{$hash1{$_}}
Your second example sets $hash2{$_} to a reference to the scalar
$hash1{$_} refers to, eg,
[rw@doppelsaurus]/tmp#perl -le '$h1{a} = [3]; $h2{a} = \$h1{a}; ${$h2{a}} = 66; print $h1{a}'
66
------------------------------
Date: Sun, 8 Mar 2015 12:30:58 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: each ARRAY (was: function returning a list of the indices of its true arguments)
Message-Id: <slrnmfocni.ru5.hjp-usenet3@hrunkner.hjp.at>
On 2015-03-04 22:30, C.DeRykus <derykus@gmail.com> wrote:
> Too bad it's still experimental (v5.18+), eg:
Is it? Neither the docs of 5.14 nor those of 5.20 mention this aspect as
experimental (or I can't find it). Are confusing this with autoderef,
which is indeed - as of 5.20 - experimental?
> while(each @arr){say $_ if $arr[$_]}
This is only marginally more convenient than
for (0 .. $#arr) { say $_ if $arr[$_] }
Where using each on an array shines is that you can use it to get the
index and value at once:
while (my ($i, $v) = each @arr) { say $i if $v }
It's not much of an improvement (if any) in this trivial example, and
you could always replace it with
for my $i (0 .. $#arr) {
$v = $arr[$i];
...
}
but for some loops it makes a difference in readability and it makes
hashes and array more similar.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Fri, 06 Mar 2015 08:52:25 +0100
From: Georg Bauhaus <bauhaus@futureapps.invalid>
Subject: Re: variable expansion issue
Message-Id: <mdbmad$1gv$1@dont-email.me>
On 05.03.15 18:51, Rainer Weikusat wrote:
> But that's not the least bit practical: Relying on 'unchangedness' of
> the filesystem state can often be avoided, there's no need to postpone
> that until the origin of matter has been determined.
We wouldn't be writing Perl programs if the universe were recursively
known, I think, thanks for that fine specimen of rhetorical shift.
So, how about outlining the "often be avoided" with an example of stat
and NFS mounts in Perl? You needn't address the suicidal squirrels damaging
the ethernet cables. Although fixing the whole in the wall would be
practically removing that cause of interrupts.
------------------------------
Date: Fri, 06 Mar 2015 09:00:35 +0100
From: Georg Bauhaus <bauhaus@futureapps.invalid>
Subject: Re: variable expansion issue
Message-Id: <mdbmpn$2sg$1@dont-email.me>
On 06.03.15 08:52, Georg Bauhaus wrote:
> On 05.03.15 18:51, Rainer Weikusat wrote:
>> But that's not the least bit practical: Relying on 'unchangedness' of
>> the filesystem state can often be avoided, there's no need to postpone
>> that until the origin of matter has been determined.
>
> We wouldn't be writing Perl programs if the universe were recursively
> known, I think, thanks for that fine specimen of rhetorical shift.
> So, how about outlining the "often be avoided" with an example of stat
> and NFS mounts in Perl? You needn't address the suicidal squirrels damaging
> the ethernet cables. Although fixing the whole in the wall would be
> practically removing that cause of interrupts.
Also, fixing the "whole" should be a good use of Perl. Note to self:
write spell checker extension.
------------------------------
Date: Fri, 6 Mar 2015 09:16:18 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: variable expansion issue
Message-Id: <ib4osb-q6j.ln1@news.rtij.nl>
On Fri, 06 Mar 2015 08:52:25 +0100, Georg Bauhaus wrote:
> On 05.03.15 18:51, Rainer Weikusat wrote:
>> But that's not the least bit practical: Relying on 'unchangedness' of
>> the filesystem state can often be avoided, there's no need to postpone
>> that until the origin of matter has been determined.
>
> We wouldn't be writing Perl programs if the universe were recursively
> known, I think, thanks for that fine specimen of rhetorical shift.
> So, how about outlining the "often be avoided" with an example of stat
> and NFS mounts in Perl? You needn't address the suicidal squirrels
> damaging the ethernet cables. Although fixing the whole in the wall
> would be practically removing that cause of interrupts.
Reminds me of when my cat killed my mouse... :-)
M4
------------------------------
Date: Fri, 06 Mar 2015 15:14:32 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <874mpy17l3.fsf@doppelsaurus.mobileactivedefense.com>
Georg Bauhaus <bauhaus@futureapps.invalid> writes:
> On 05.03.15 18:51, Rainer Weikusat wrote:
>> But that's not the least bit practical: Relying on 'unchangedness' of
>> the filesystem state can often be avoided, there's no need to postpone
>> that until the origin of matter has been determined.
>
> We wouldn't be writing Perl programs if the universe were recursively
> known, I think, thanks for that fine specimen of rhetorical shift.
From the perspective of someone writing Perl code to be executed on a
'modern' computer, the origin of the universe and the firmware of a
storage device are comparable terrae incognitae.
> So, how about outlining the "often be avoided" with an example of stat
> and NFS mounts in Perl?
Perl doesn't do NFS mounts. And that's just the same kind of invalid
argument: No use wearing helmets on a construction site, after all, a
meteor could hit at any time or maybe a global, thermonuclear war.
------------------------------
Date: Fri, 06 Mar 2015 17:18:26 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: variable expansion issue
Message-Id: <mdcjv6$lk2$1@dont-email.me>
On 06.03.15 16:14, Rainer Weikusat wrote:
>> So, how about outlining the "often be avoided" with an example of stat
>> >and NFS mounts in Perl?
> Perl doesn't do NFS mounts.
Sticking to the literal, as always?
------------------------------
Date: Fri, 06 Mar 2015 20:37:45 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <877futzwti.fsf@doppelsaurus.mobileactivedefense.com>
"G.B." <bauhaus@futureapps.invalid> writes:
> On 06.03.15 16:14, Rainer Weikusat wrote:
>>> So, how about outlining the "often be avoided" with an example of stat
>>> >and NFS mounts in Perl?
>> Perl doesn't do NFS mounts.
>
> Sticking to the literal, as always?
I you don't mean what you write, how about writing what you mean?
------------------------------
Date: Fri, 06 Mar 2015 21:47:12 +0100
From: Georg Bauhaus <bauhaus@futureapps.invalid>
Subject: Re: variable expansion issue
Message-Id: <mdd3n4$tak$1@dont-email.me>
On 06.03.15 21:37, Rainer Weikusat wrote:
> "G.B." <bauhaus@futureapps.invalid> writes:
>> On 06.03.15 16:14, Rainer Weikusat wrote:
>>>> So, how about outlining the "often be avoided" with an example of stat
>>>>> and NFS mounts in Perl?
>>> Perl doesn't do NFS mounts.
>>
>> Sticking to the literal, as always?
>
> I you don't mean what you write, how about writing what you mean?
I did, just a matter of suitable bracketing, for example:
(So, (how about outlining
(the "often be avoided")
with
(an example of ((stat and NFS mounts) in Perl))?))
------------------------------
Date: Fri, 06 Mar 2015 21:13:53 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <87385hzv5a.fsf@doppelsaurus.mobileactivedefense.com>
Georg Bauhaus <bauhaus@futureapps.invalid> writes:
> On 06.03.15 21:37, Rainer Weikusat wrote:
>> "G.B." <bauhaus@futureapps.invalid> writes:
>>> On 06.03.15 16:14, Rainer Weikusat wrote:
>>>>> So, how about outlining the "often be avoided" with an example of stat
>>>>>> and NFS mounts in Perl?
>>>> Perl doesn't do NFS mounts.
>>>
>>> Sticking to the literal, as always?
>>
>> I you don't mean what you write, how about writing what you mean?
>
> I did, just a matter of suitable bracketing, for example:
>
> (So, (how about outlining
> (the "often be avoided")
> with
> (an example of ((stat and NFS mounts) in Perl))?))
Well, minus stating that "it can't be done" (whatever) because "NFS" is
not implemented by perl, there's nothing to say to that except maybe
"assuming you're up to something specific related to using the
NFS-protocol for accessing file systems in computers reachable via some
network, it's often going to be irrelevant because often, filesystems
won't be accessed in this way" ...
------------------------------
Date: Fri, 06 Mar 2015 15:36:28 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: variable expansion issue
Message-Id: <mdddkq$ang$1@dont-email.me>
On 3/6/2015 13:13, Rainer Weikusat wrote:
> Georg Bauhaus <bauhaus@futureapps.invalid> writes:
>> On 06.03.15 21:37, Rainer Weikusat wrote:
>>> "G.B." <bauhaus@futureapps.invalid> writes:
>>>> On 06.03.15 16:14, Rainer Weikusat wrote:
>>>>>> So, how about outlining the "often be avoided" with an example of stat
>>>>>>> and NFS mounts in Perl?
>>>>> Perl doesn't do NFS mounts.
>>>>
>>>> Sticking to the literal, as always?
>>>
>>> I you don't mean what you write, how about writing what you mean?
>>
>> I did, just a matter of suitable bracketing, for example:
>>
>> (So, (how about outlining
>> (the "often be avoided")
>> with
>> (an example of ((stat and NFS mounts) in Perl))?))
>
> Well, minus stating that "it can't be done" (whatever) because "NFS" is
> not implemented by perl, there's nothing to say to that except maybe
> "assuming you're up to something specific related to using the
> NFS-protocol for accessing file systems in computers reachable via some
> network, it's often going to be irrelevant because often, filesystems
> won't be accessed in this way" ...
Maybe NLM and a Perl interface to same would be a subject to pursue here. ;)
------------------------------
Date: Sat, 07 Mar 2015 09:13:55 +0100
From: Georg Bauhaus <bauhaus@futureapps.invalid>
Subject: Re: variable expansion issue
Message-Id: <mdebun$rts$1@dont-email.me>
On 07.03.15 00:36, $Bill wrote:
>>> (So, (how about outlining
>>> (the "often be avoided")
>>> with
>>> (an example of ((stat and NFS mounts) in Perl))?))
>>
>> Well, minus stating that "it can't be done" (whatever) because "NFS" is
>> not implemented by perl,
The headline-ish phrase "stat and NFS mounts" is open to a no-nonsense
interpretation by Perl programmer in the context, I think?
If "stat and the system call it does" leads to the conclusion
that Perl may well have stale information about the file system
resource, then how does one often avoid that state of things?
How does the solution port to different execution environments
(such as those including NFS mounted file systems like VMware)?
>> it's often going to be irrelevant because often, filesystems
>> won't be accessed in this way" ...
>
> Maybe NLM and a Perl interface to same would be a subject to pursue here. ;)
Precisely! Maybe also if transactional file systems could make Perl's
file operations more "safe"? And to what extent? Or is this not
necessary for your Perl based solution? If there is an example of
how issues can "often be avoided", can you show it?
Issues that stem from interruptible OS processes while accessing
file system resources, say. I'm really interested.
(Because what I normally do is not more than
- arrange file storage in such a way that only a select group of
*nix users has access,
- use file system locks,
- have programs decline operation if a resource is not in a know
good state,
- send a note to the operators in an emergency.)
------------------------------
Date: Sun, 8 Mar 2015 12:40:49 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: variable expansion issue
Message-Id: <slrnmfoda1.ru5.hjp-usenet3@hrunkner.hjp.at>
On 2015-03-05 17:46, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> The problem is that you apparently don't understand that neither
>
> stat('node');
> -f _;
>
> nor
>
> -f 'node'
>
> is an atomic operation, ie one whose processing will be completed
> entirely after it started without any other process capable of changing
> the state of the filesystem while this processing happens. The first is
> two perl ops, the second only one but 'a Perl op' is a usually rather
> lengthy C function in the perl binary which does a system call somewhere
> midstream. And only small part of the code executing as part of the system
> call is atomic.
This is very true but IMHO missing the point. The real point is that the
information retrieved by stat or -f has to be used to be useful, and
it will of necessity used *later*.
Even if -f 'node' happened to be atomic, the combination of -f 'node'
and some other operation (e.g. open('node')) definitely isn't.
(It might be in Georg's hypothetical "transactional filesystem", but
even then you would need a way to delimit transactions and prepare for
failure)
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sun, 08 Mar 2015 19:32:39 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <87lhj7gu94.fsf@doppelsaurus.mobileactivedefense.com>
Georg Bauhaus <bauhaus@futureapps.invalid> writes:
> On 07.03.15 00:36, $Bill wrote:
>
>>>> (So, (how about outlining
>>>> (the "often be avoided")
>>>> with
>>>> (an example of ((stat and NFS mounts) in Perl))?))
>>>
>>> Well, minus stating that "it can't be done" (whatever) because "NFS" is
>>> not implemented by perl,
>
> The headline-ish phrase "stat and NFS mounts" is open to a no-nonsense
> interpretation by Perl programmer in the context, I think?
I have absolutely no idea what you're up to, mostly because I refuse to
speculate about possibilities.
> If "stat and the system call it does" leads to the conclusion
> that Perl may well have stale information about the file system
> resource, then how does one often avoid that state of things?
Well, as I already wrote: Instead of trying to divine if an operation
would succeed, try it and look at the result, eg,
------------
use Errno qw(EEXIST);
sub do_chdir
{
if (chdir($_[0])) {
print STDERR ("chdir $_[0] worked!\n");
return;
}
print("chdir $_[0] didn't work: $!\n");
}
unless (mkdir('/tmp/file') || $! == EEXIST) {
die("$!");
}
open($fh, '>', '/tmp/directory');
do_chdir('/tmp/file');
do_chdir('/tmp/directory');
-----------
> How does the solution port to different execution environments
> (such as those including NFS mounted file systems like VMware)?
I again suggest that you state what you're alluding to/ hinting at.
------------------------------
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 4385
***************************************
