[32722] in Perl-Users-Digest
Perl-Users Digest, Issue: 3986 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jul 11 11:09:33 2013
Date: Thu, 11 Jul 2013 08: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 Thu, 11 Jul 2013 Volume: 11 Number: 3986
Today's topics:
=?UTF-8?Q?Stack=20Overflow=20modera?= =?UTF-8?Q?tor=20= <matsp999@aim.com>
Re: assignments of arrays brakhagem@gmail.com
Existing module for file browser brakhagem@gmail.com
Perl calling ps - COLUMNS ignored? <n@solenttechnology.co.uk>
Re: Perl calling ps - COLUMNS ignored? <ben@morrow.me.uk>
Re: Perl calling ps - COLUMNS ignored? <n@solenttechnology.co.uk>
this should work <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: this should work <jimsgibson@gmail.com>
Re: this should work <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Re: this should work (Tim McDaniel)
Re: this should work <rweikusat@mssgmbh.com>
Re: this should work <jurgenex@hotmail.com>
Re: this should work <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Re: this should work <ben@morrow.me.uk>
Re: this should work <peter@makholm.net>
Re: this should work <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Re: this should work <ben@morrow.me.uk>
Re: this should work <rweikusat@mssgmbh.com>
Re: this should work <hjp-usenet3@hjp.at>
Re: this should work <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Re: this should work <rweikusat@mssgmbh.com>
Re: this should work <rweikusat@mssgmbh.com>
Re: this should work <peter@makholm.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 10 Jul 2013 08:05:42 +0000 (UTC)
From: Mats Peterson <matsp999@aim.com>
Subject: =?UTF-8?Q?Stack=20Overflow=20modera?= =?UTF-8?Q?tor=20=E2=80=9Canimuson=E2=80=9D?=
Message-Id: <krj4km$dgc$2@dont-email.me>
A moderator who calls himself “animuson” on Stack Overflow doesn’t want
to face the truth. He has deleted all my postings regarding Python
regular expression matching being extremely slow compared to Perl.
Additionally, my account has been suspended for 7 days. Such a dickwad.
Mats
--
Mats Peterson
http://alicja.homelinux.com/~mats/
------------------------------
Date: Wed, 10 Jul 2013 20:07:19 -0700 (PDT)
From: brakhagem@gmail.com
Subject: Re: assignments of arrays
Message-Id: <86e9fc0c-16d7-4f78-a9f7-9ef6bc9e55b8@googlegroups.com>
------------------------------
Date: Wed, 10 Jul 2013 20:10:56 -0700 (PDT)
From: brakhagem@gmail.com
Subject: Existing module for file browser
Message-Id: <1bb10dbb-d5d2-4e98-b5ea-5fdb2fe8e699@googlegroups.com>
------------------------------
Date: Wed, 10 Jul 2013 05:48:56 -0700 (PDT)
From: neilsolent <n@solenttechnology.co.uk>
Subject: Perl calling ps - COLUMNS ignored?
Message-Id: <4c056507-0cb0-4259-bc2b-e81e50806059@googlegroups.com>
Hi
I am seeing weird behaviour when calling ps from perl on AIX.
I want to control the width of the output from ps through the COLUMNS environment variable.
The shell script gives truncated output when run directly, but
seems to ignore COLUMNS when called from Perl! Can anyone explain why?
thanks,
Neil.
root@test1:/tmp# cat /tmp/a.sh
#!/bin/sh
COLUMNS=10
export COLUMNS
ps -fu prdgwd -o "%u;%p;%P;%C;%y;%x;%a"
root@test1:/tmp# cat /tmp/a.pl
#!/bin/perl
print `/tmp/a.sh`;
root@test1:/tmp# /tmp/a.sh
RUSER PID PPID %CPU TT TIME COMMAND
prdgwd; 3604630;12910802; 0.0; pts/2; 00:00:00;-ksh
prdgwd;10223670; 3211486; 0.0; -; 00:00:00;/bin/ksh /usr/l
prdgwd;10551322;10223670; 0.0; -; 00:00:00;sleep 900
prdgwd;11075748; 1; 0.0; -; 00:00:27;/opt/IBM/ITM/ha
prdgwd;13566176;19529852; 0.0; -; 00:00:00;db2vend (PD Ven
prdgwd;18153590;19529852; 0.0; -; 00:00:06;db2acd
prdgwd;19005538;19529852; 0.2; -; 00:03:45;db2sysc 0
prdgwd;20971672; 3604630; 0.0; pts/2; 00:00:16;db2top -d clsgw
root@test1:/tmp# /tmp/a.pl
RUSER PID PPID %CPU TT TIME COMMAND
prdgwd; 3604630;12910802; 0.0; pts/2; 00:00:00;-ksh
prdgwd;10223670; 3211486; 0.0; -; 00:00:00;/bin/ksh /usr/local/dbabin/db2_log_cleanup.ksh
prdgwd;10551322;10223670; 0.0; -; 00:00:00;sleep 900
prdgwd;11075748; 1; 0.0; -; 00:00:27;/opt/IBM/ITM/ha/aix526/ud/bin/kuddb2 clsppal38_prdgwd
prdgwd;13566176;19529852; 0.0; -; 00:00:00;db2vend (PD Vendor Process - 258)
prdgwd;18153590;19529852; 0.0; -; 00:00:06;db2acd
prdgwd;19005538;19529852; 0.2; -; 00:03:45;db2sysc 0
prdgwd;20971672; 3604630; 0.0; pts/2; 00:00:16;db2top -d clsgwd
------------------------------
Date: Wed, 10 Jul 2013 18:10:25 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl calling ps - COLUMNS ignored?
Message-Id: <15h0ba-snt.ln1@anubis.morrow.me.uk>
Quoth neilsolent <n@solenttechnology.co.uk>:
>
> I am seeing weird behaviour when calling ps from perl on AIX.
> I want to control the width of the output from ps through the COLUMNS
> environment variable.
> The shell script gives truncated output when run directly, but
> seems to ignore COLUMNS when called from Perl! Can anyone explain why?
Probably because your ps only honours COLUMNS when output is to a
terminal. If you just want to cut the output off at a given column,
that's not hard; something like
my @ps = `ps ...`;
length > 49 and substr($_, 49) = ""
for @ps;
Ben
------------------------------
Date: Thu, 11 Jul 2013 01:28:30 -0700 (PDT)
From: neilsolent <n@solenttechnology.co.uk>
Subject: Re: Perl calling ps - COLUMNS ignored?
Message-Id: <d0def461-6d59-47d9-b9c6-a275ee5c262d@googlegroups.com>
On Wednesday, 10 July 2013 18:10:25 UTC+1, Ben Morrow wrote:
> Quoth neilsolent <n@solenttechnology.co.uk>:
>
> >
>
> > I am seeing weird behaviour when calling ps from perl on AIX.
>
> > I want to control the width of the output from ps through the COLUMNS
>
> > environment variable.
>
> > The shell script gives truncated output when run directly, but
>
> > seems to ignore COLUMNS when called from Perl! Can anyone explain why?
>
>
>
> Probably because your ps only honours COLUMNS when output is to a
>
> terminal. If you just want to cut the output off at a given column,
>
> that's not hard; something like
>
>
>
> my @ps = `ps ...`;
>
> length > 49 and substr($_, 49) = ""
>
> for @ps;
>
>
>
> Ben
Thanks Ben. You are right of course - I think ps is testing stdout for being a terminal. So this has nothing to do with perl.
I posted this to troubleshoot a wider problem - although you have answered the post I still have not solved the problem - oh well.
------------------------------
Date: Thu, 11 Jul 2013 01:08:24 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: this should work
Message-Id: <krkm21$19jd$1@news.ntua.gr>
foreach my $dir (qw/commands_pre commands_post/) {
$dir = "/tmp/$dir";
print "$dir\n"
}
# Modification of a read-only value attempted at ./test line 139
------------------------------
Date: Wed, 10 Jul 2013 15:49:35 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: this should work
Message-Id: <100720131549354102%jimsgibson@gmail.com>
In article <krkm21$19jd$1@news.ntua.gr>, George Mpouras
<nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> wrote:
> foreach my $dir (qw/commands_pre commands_post/) {
> $dir = "/tmp/$dir";
> print "$dir\n"
> }
>
> # Modification of a read-only value attempted at ./test line 139
Because of the aliasing feature of foreach loops, you are trying to
modify the elements of qw/commands_pre commands_post/, which are not
lvalues. Try this instead:
#!/usr/bin/perl
use strict;
use warnings;
foreach my $dir (qw/commands_pre commands_post/) {
my $tmpdir = "/tmp/$dir";
print "$tmpdir\n"
}
See 'perldoc perlsyn' and the section entitled 'Foreach Loops':
"LABEL foreach VAR (LIST) BLOCK"
"If any element of LIST is an lvalue, you can modify it by modifying VAR
inside the loop. Conversely, if any element of LIST is NOT an lvalue,
any attempt to modify that element will fail. In other words, the
'foreach' loop index variable is an implicit alias for each item in the
list that you're looping over."
--
Jim Gibson
------------------------------
Date: Thu, 11 Jul 2013 09:42:04 +0300
From: George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Subject: Re: this should work
Message-Id: <krlk2f$2e7e$1@news.ntua.gr>
it is a perl bug or bad behavior , should change.
------------------------------
Date: Thu, 11 Jul 2013 08:02:52 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: this should work
Message-Id: <krlorb$4k3$1@reader2.panix.com>
In article <krlk2f$2e7e$1@news.ntua.gr>,
George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> wrote:
>it is a perl bug or bad behavior , should change.
I don't like it -- it's an "action at a distance spookiness" effect
that I've found little use for. I just work around it.
You have just had the documentation quoted and explained. It's a
long-standing aspect of Perl. I call something a "bug" when it's a
result that does not match the documentation, so you have no right to
call it a "perl bug".
"Misfeature" or "bad design": aliasing something to each item in turn,
where changing the variable changes the underlying thing, is
documented in several areas and decades old. If you don't like it, it
has an immediate and obvious workaround: assign it to a temporary.
TL;DR: Quit whining. Learn when aliasing happens and don't change
aliased variables (unless you have a need for it).
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 11 Jul 2013 10:32:41 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: this should work
Message-Id: <87a9ltqw5i.fsf@sapphire.mobileactivedefense.com>
Jim Gibson <jimsgibson@gmail.com> writes:
[...]
> foreach my $dir (qw/commands_pre commands_post/) {
> my $tmpdir = "/tmp/$dir";
> print "$tmpdir\n"
> }
The perl compiler doesn't do invariant code motion because whether or
not some code is 'invariant' cannot generally be decided at compile
time. Because of this, the loop body above behave exactly as written
down: For each iteration, it creates a new my variable and assigns a
value to it. Unless there's a specific reason why this behaviour would
be desirable, such constructs should be avoided[*].
[*] This is also true for the more general case of 'Yes we can!'
variable declarations: Just because a new my variable can be created
as part of some construct doesn't mean there's a good reason why it
should be created, not only because this takes time but more
importantly, because it makes the code more complicated, especially as
real world code isn't going to have nice and small two lines blocks
but rather big and ugly 500 lines blocks with 5 hundred lines blocks
inside and each of these further subdivided into dozens of line
blocks (this is probably still and optimistic estimate). This makes
for extremely 'enjoyable' variable hunting ...
------------------------------
Date: Thu, 11 Jul 2013 03:34:00 -0700
From: Jrgen Exner <jurgenex@hotmail.com>
Subject: Re: this should work
Message-Id: <qd2tt8d52f7d2pqne0db60v8nkglki47vk@4ax.com>
George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> wrote:
>it is a perl bug or bad behavior , should change.
_WHAT_ is a bug or bad behaviour in the Perl interpreter?
Please quote sufficient context such that your postings are meaningful.
jue
------------------------------
Date: Thu, 11 Jul 2013 13:55:59 +0300
From: George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Subject: Re: this should work
Message-Id: <krm2ui$kif$1@news.ntua.gr>
Στις 11/7/2013 13:34, ο/η Jürgen Exner έγραψε:
> George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> wrote:
>> it is a perl bug or bad behavior , should change.
>
> _WHAT_ is a bug or bad behaviour in the Perl interpreter?
> Please quote sufficient context such that your postings are meaningful.
>
> jue
>
Perl is for humans so its behavior should be the expected if there is
not a serious reason not to be
------------------------------
Date: Thu, 11 Jul 2013 12:45:29 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: this should work
Message-Id: <pfi2ba-85p1.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <krlk2f$2e7e$1@news.ntua.gr>,
> George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> wrote:
[for's aliasing]
> >it is a perl bug or bad behavior , should change.
>
> I don't like it -- it's an "action at a distance spookiness" effect
> that I've found little use for. I just work around it.
I disagree: I find it really useful, and one of the things that
irritated me about 'given' is that is *doesn't* alias. It's useful
for performing a sequence of modifications on a sequence of values;
something like
for (@array) {
s/^\s+//;
s/\s+$//;
}
It's also consistent with sub argument passing.
Now the fact map aliases, on the other hand, is a pity.
Ben
------------------------------
Date: Thu, 11 Jul 2013 13:57:19 +0200
From: Peter Makholm <peter@makholm.net>
Subject: Re: this should work
Message-Id: <871u7571i8.fsf@vps1.hacking.dk>
George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>
writes:
[ foreach is aliasing ]
> Perl is for humans so its behavior should be the expected if there is
> not a serious reason not to be
I can't see any serious reason for Perl not to work as documented and
designed. The feature is useful and well-documented and absolutely not a
bug.
//Makholm
------------------------------
Date: Thu, 11 Jul 2013 15:03:09 +0300
From: George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Subject: Re: this should work
Message-Id: <krm6sh$vfk$1@news.ntua.gr>
the behavior is different for an @array and a hardcoded list
------------------------------
Date: Thu, 11 Jul 2013 12:51:33 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: this should work
Message-Id: <5ri2ba-85p1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Jim Gibson <jimsgibson@gmail.com> writes:
>
> [...]
>
> > foreach my $dir (qw/commands_pre commands_post/) {
> > my $tmpdir = "/tmp/$dir";
> > print "$tmpdir\n"
> > }
>
> The perl compiler doesn't do invariant code motion because whether or
> not some code is 'invariant' cannot generally be decided at compile
> time.
I don't know what you mean by that, but...
> Because of this, the loop body above behave exactly as written
> down: For each iteration, it creates a new my variable and assigns a
> value to it.
...this is nonsense. Perl quite deliberately reuses the same variable
every time, to avoid the allocation overhead, unless you pass a (strong)
reference to it outside the loop. Try it and see:
use Scalar::Util qw/refaddr/;
for (1, 2, 3) {
my $tmp = "foo/$_";
say refaddr \$tmp;
}
> Unless there's a specific reason why this behaviour would
> be desirable, such constructs should be avoided[*].
>
> [*] This is also true for the more general case of 'Yes we can!'
> variable declarations: Just because a new my variable can be created
> as part of some construct doesn't mean there's a good reason why it
> should be created, not only because this takes time but more
> importantly, because it makes the code more complicated, especially as
> real world code isn't going to have nice and small two lines blocks
> but rather big and ugly 500 lines blocks with 5 hundred lines blocks
> inside and each of these further subdivided into dozens of line
> blocks (this is probably still and optimistic estimate).
Speak for yourself. *My* real-world code doesn't look like that.
Ben
------------------------------
Date: Thu, 11 Jul 2013 13:42:14 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: this should work
Message-Id: <87li5dclp5.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Jim Gibson <jimsgibson@gmail.com> writes:
>>
>> [...]
>>
>> > foreach my $dir (qw/commands_pre commands_post/) {
>> > my $tmpdir = "/tmp/$dir";
>> > print "$tmpdir\n"
>> > }
>>
>> The perl compiler doesn't do invariant code motion because whether or
>> not some code is 'invariant' cannot generally be decided at compile
>> time.
>
> I don't know what you mean by that, but...
In this case, this would be transforming the
for (...) {
my $tmp = 'ar!';
}
to
my $tmp;
for (...) {
$tmp = 'ar!';
}
because the 'my $tmp' is invariant code: It's effective result never
changes throughout the loop.
>
>> Because of this, the loop body above behave exactly as written
>> down: For each iteration, it creates a new my variable and assigns a
>> value to it.
>
> ...this is nonsense. Perl quite deliberately reuses the same variable
> every time, to avoid the allocation overhead, unless you pass a (strong)
> reference to it outside the loop. Try it and see:
>
> use Scalar::Util qw/refaddr/;
>
> for (1, 2, 3) {
> my $tmp = "foo/$_";
> say refaddr \$tmp;
> }
Maybe some versions of Perl do that (which would be an
improvement). But the one I tested certainly doesn't. Assuming the
following code
-------------
use Benchmark;
sub in_loop
{
for (0 .. 100) {
my $a = $_ + 1;
}
}
sub out_of_loop
{
my $a;
for (0 .. 100) {
$a = $_ + 1
}
}
timethese(-2,
{
in_loop => \&in_loop,
out_of_loop => \&out_of_loop
});
-------------
the loop in in_loop is translated to (perl -MO=Concise,in_loop, perl
5.10.1)
e <0> iter s ->f
- <@> lineseq sK ->-
7 <;> nextstate(main 596 a.pl:6) v ->8
c <2> sassign vKS/2 ->d
a <2> add[t5] sK/2 ->b
- <1> ex-rv2sv sK/1 ->9
8 <#> gvsv[*_] s ->9
9 <$> const[IV 1] s ->a
b <0> padsv[$a:596,597] sRM*/LVINTRO ->c
d <0> unstack s ->e
[b] is what creates the variable.
For out_of_loop, this looks like this:
e <0> iter s ->f
- <@> lineseq sK ->-
9 <;> nextstate(main 601 a.pl:14) v ->a
c <2> add[$a:600,603] sK/TARGMY,2 ->d
- <1> ex-rv2sv sK/1 ->b
a <#> gvsv[*_] s ->b
b <$> const[IV 1] s ->c
d <0> unstack s ->e
and the padsv ... LVINTRO happens in the subroutine preamble.
Running the program here yields the expected result that out_of_loop
executes at about 1.43 times the speed of in_loop.
>> Unless there's a specific reason why this behaviour would
>> be desirable, such constructs should be avoided[*].
>>
>> [*] This is also true for the more general case of 'Yes we can!'
>> variable declarations: Just because a new my variable can be created
>> as part of some construct doesn't mean there's a good reason why it
>> should be created, not only because this takes time but more
>> importantly, because it makes the code more complicated, especially as
>> real world code isn't going to have nice and small two lines blocks
>> but rather big and ugly 500 lines blocks with 5 hundred lines blocks
>> inside and each of these further subdivided into dozens of line
>> blocks (this is probably still and optimistic estimate).
>
> Speak for yourself. *My* real-world code doesn't look like that.
I speak for code written by people other than me I happen to know. I'm
completely willing to believe that you either don't know any code
written by other people or only code written by other people who are
above-average skilled programmers and that you're one yourself,
however, that doesn't change this observation.
------------------------------
Date: Thu, 11 Jul 2013 14:52:59 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: this should work
Message-Id: <slrnkttale.hh4.hjp-usenet3@hrunkner.hjp.at>
On 2013-07-11 12:03, George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> wrote:
> the behavior is different for an @array and a hardcoded list
Yes, for the same reason that the behaviour for $x[1] = 5 is different
than 2 = 5: You can assign a value to an array element, but you can't
assign a value to a constant.
After
my @x = (1, 2, 3);
for (@x) {
$_ = 5;
}
@x has the value (5, 5, 5), so it's basically the same as:
$x[0] = 5;
$x[1] = 5;
$x[2] = 5;
Now consider the equivalent with constants:
for (1, 2, 3) {
$_ = 5;
}
That would be the same as:
1 = 5;
2 = 5;
3 = 5;
Oops!
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: Thu, 11 Jul 2013 16:01:20 +0300
From: George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Subject: Re: this should work
Message-Id: <krma9j$17v0$1@news.ntua.gr>
ok but this is a tautology
for (1, 2, 3) {
$_ = 5;
}
should NOT be the same as:
1 = 5;
2 = 5;
3 = 5
never mind , some things never change
------------------------------
Date: Thu, 11 Jul 2013 14:27:09 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: this should work
Message-Id: <87d2qpcjma.fsf@sapphire.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> In article <krlk2f$2e7e$1@news.ntua.gr>,
> George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> wrote:
[so-called 'aliasing in for loops']
>>it is a perl bug or bad behavior , should change.
>
> I don't like it -- it's an "action at a distance spookiness" effect
> that I've found little use for. I just work around it.
[...]
> "Misfeature" or "bad design":
I think a discrepancy between your 'mental model' of 'Perl execution'
and the way it actually works exists here: In perl, values are always
represented as SVs ('scalars') and a SV is a pretty complex object,
copying of which may be 'expensive', eg, the following perl code:
---
use Devel::Peek;
my $s = 'string';
my $ss = $s;
Dump($s);
Dump($ss);
---
causes a the string assigned to s to be copied to a newly, dynamically
allocated area of memory, as can be seen in the output generated when
running this code:
---
SV = PV(0x603b78) at 0x621188
REFCNT = 1
FLAGS = (PADMY,POK,pPOK)
PV = 0x61b9f0 "string"\0
CUR = 6
LEN = 8
SV = PV(0x603c38) at 0x6211b8
REFCNT = 1
FLAGS = (PADMY,POK,pPOK)
PV = 0x617a10 "string"\0
CUR = 6
LEN = 8
---
Because an SV is not really a 'value' in the sense of, say, a C
integer or pointer, it is always passed 'by reference' into
syntactical constructs which work with 'lists of SVs' such as map { },
for ( ) { } or subroutine calls and it is up to the user to copy the
'argument SV' in case an independently modifiable copy of the original
thing is actually needed for some reason (perl supports, supported or
was supposed to support COW-sharing of 'SV string bodies' in some
circumstance or at some point in the in the past, but except 'somebody
worked on that in the past', I don't really know any details about
that). That's similar to the way Java handles this where complex
objects are always passed 'by reference', just that Java also has
'primitive types' which are passed by value and Perl doesn't.
------------------------------
Date: Thu, 11 Jul 2013 14:29:01 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: this should work
Message-Id: <878v1dcjj6.fsf@sapphire.mobileactivedefense.com>
George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>
writes:
> ok but this is a tautology
>
> for (1, 2, 3) {
> $_ = 5;
> }
>
> should NOT be the same as:
>
> 1 = 5;
> 2 = 5;
> 3 = 5
>
>
> never mind , some things never change
Indeed: Perl still represents all values as SVs internally and this
means the literal numbers exist in your source code but in the
compiled code, they're just used to initialize read-only SVs which are
passed by reference. That's something one just needs to be aware of
when using Perl.
------------------------------
Date: Thu, 11 Jul 2013 15:50:55 +0200
From: Peter Makholm <peter@makholm.net>
Subject: Re: this should work
Message-Id: <87fvvljjcw.fsf@vps1.hacking.dk>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> thing is actually needed for some reason (perl supports, supported or
> was supposed to support COW-sharing of 'SV string bodies' in some
> circumstance or at some point in the in the past, but except 'somebody
> worked on that in the past', I don't really know any details about
> that).
Copy-on-Write strings was supposed to be enabled by default for Perl
5.18, but it broke a significant number of XS modules. It can be enabled
by running Configer with '-Accflags=-DPERL_NEW_COPY_ON_WRITE' when
building perl.
I believe it is enabled in perl 5.19.
//Makholm
------------------------------
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 3986
***************************************
