J
Josef
Hi!
Maybe i have found bugs or/and some unclearness in the documentation
of some modules in the core.
[About me:
English is not my mother tongue (obviously).
And most of my english experience came from user manuals.
Because no bug description are usually in such kind of literature,
such doing is more difficult for me, as e.g. just kidding and joking
(yes i have read perl books also ;-).
So i will start with some perl code with doing nothing else,
as demonstration the diverting from my expectations.
]
The first observation is related to List::Util,
i use first() in the example below but the same behavior
can be find also e.g. in reduce().
(But not reproduceable in grep & map.)
<code>
use strict; use warnings; use feature ':5.12';
use List::Util qw'reduce first';
say '1.) localizing $_ in selecting subroutine for first:';
$_="orginal";
sub f0 { say "frm f0: $_";0 }
my $dummy=first { say "frm c: $_"; local $_=10; f0() } 1..3;
say "after first: $_";
</code>
This produce this error messages (count of listitems-1 times):
Attempt to free unreferenced scalar: SV 0x......, Perl interpreter: 0x35f54.
Beside that, the output is what i expected, but ...
<code mode='continue'>
say '2.) localizing $a in selecting subroutine for first:';
# or something else
$a="orginal";
sub f0a { say "frm f0a: $a";0 }
$dummy=first { say "frm c: $a"; local $a=10; f0a() } 1..3;
say "after first: $a\n";
</code>
This time no errors, but the result is strange because the
local'isation leaks into the next invocation, which is not
what i expected.
<output>
frm c: orginal
frm f0a: 10
frm c: 10
frm f0a: 10
frm c: 10
frm f0a: 10
after first: orginal
</output>
Both problems have a easy workaround. Simply double the '{','}'.
<code mode='continue'>
say '3.) localizing $a in first with workaround:';
$dummy=first {{ say "frm c: $a"; local $a=10; f0a() }} 1..3;
say "after first: $a\n";
</code>
<output comment='expected'>
frm c: orginal
frm f0a: 10
frm c: orginal
frm f0a: 10
frm c: orginal
frm f0a: 10
after first: orginal
</output>
Another problem with go away with doubling the curly brackets
is by constructing closures inside.
reduce { my $f=$a; sub { ... $f->(...) ... } sub { 'bla' },...
produces always deep recursion where the reduce {{ ... }} variant
do not.
So imho this indicates a problem with scope.
If this is a feature or a optimization with ignores seldom usage then
i think it should at least be documented.
~~~~
The next have to do with unclear description
of calling subs in the form &fun;. So i can not say if it does what
it should do or not. The following example demonstrate that it is
not the same as for fun(@_) [no prototypes involved].
<code>
sub f2 { shift }
sub okidoki { f2(@_); join ',',@_ }
say okidoki 'blabla',1..10;
sub notwasiexpected { &f2; join ',',@_ }
say notwasiexpected 'missing blabla',1..10;
</code>
<output>
blabla,1,2,3,4,5,6,7,8,9,10
1,2,3,4,5,6,7,8,9,10
</output>
~~~~
The core module 'Safe' does work differently in perl 5.12.1 as in
version before like 5.12.0. In 5.13.x changed back to the old so far
i can guess with the help of cpantesters.org information.
I can not tell you more about this beside this is the reason that
the tests for module 'Petal' (on cpan) failed.
~~~~
The next problem is that the return context info is sometimes wrong.
But this sometimes happen by bigger applications and i can not
present a simple example to demostrate the issue.
The last time i see such behavior was in strawberry perl 5.12.1:
In that case a call to Data:
ump::dump at file scope (main:
directly in the script file (.pl).
<code mode='missing necessary enviroment'>
print "........\n";
dump $var;
print "........\n";
</code>
Where the output from dump is missed.
Changing print "....\n"; to say "....."; have changed this.
That is at least for me a little bit odd.
In older perls i have seen problems with wantarray.
But again not in a reproduceable way.
with best regards,
Josef
Maybe i have found bugs or/and some unclearness in the documentation
of some modules in the core.
[About me:
English is not my mother tongue (obviously).
And most of my english experience came from user manuals.
Because no bug description are usually in such kind of literature,
such doing is more difficult for me, as e.g. just kidding and joking
(yes i have read perl books also ;-).
So i will start with some perl code with doing nothing else,
as demonstration the diverting from my expectations.
]
The first observation is related to List::Util,
i use first() in the example below but the same behavior
can be find also e.g. in reduce().
(But not reproduceable in grep & map.)
<code>
use strict; use warnings; use feature ':5.12';
use List::Util qw'reduce first';
say '1.) localizing $_ in selecting subroutine for first:';
$_="orginal";
sub f0 { say "frm f0: $_";0 }
my $dummy=first { say "frm c: $_"; local $_=10; f0() } 1..3;
say "after first: $_";
</code>
This produce this error messages (count of listitems-1 times):
Attempt to free unreferenced scalar: SV 0x......, Perl interpreter: 0x35f54.
Beside that, the output is what i expected, but ...
<code mode='continue'>
say '2.) localizing $a in selecting subroutine for first:';
# or something else
$a="orginal";
sub f0a { say "frm f0a: $a";0 }
$dummy=first { say "frm c: $a"; local $a=10; f0a() } 1..3;
say "after first: $a\n";
</code>
This time no errors, but the result is strange because the
local'isation leaks into the next invocation, which is not
what i expected.
<output>
frm c: orginal
frm f0a: 10
frm c: 10
frm f0a: 10
frm c: 10
frm f0a: 10
after first: orginal
</output>
Both problems have a easy workaround. Simply double the '{','}'.
<code mode='continue'>
say '3.) localizing $a in first with workaround:';
$dummy=first {{ say "frm c: $a"; local $a=10; f0a() }} 1..3;
say "after first: $a\n";
</code>
<output comment='expected'>
frm c: orginal
frm f0a: 10
frm c: orginal
frm f0a: 10
frm c: orginal
frm f0a: 10
after first: orginal
</output>
Another problem with go away with doubling the curly brackets
is by constructing closures inside.
reduce { my $f=$a; sub { ... $f->(...) ... } sub { 'bla' },...
produces always deep recursion where the reduce {{ ... }} variant
do not.
So imho this indicates a problem with scope.
If this is a feature or a optimization with ignores seldom usage then
i think it should at least be documented.
~~~~
The next have to do with unclear description
of calling subs in the form &fun;. So i can not say if it does what
it should do or not. The following example demonstrate that it is
not the same as for fun(@_) [no prototypes involved].
<code>
sub f2 { shift }
sub okidoki { f2(@_); join ',',@_ }
say okidoki 'blabla',1..10;
sub notwasiexpected { &f2; join ',',@_ }
say notwasiexpected 'missing blabla',1..10;
</code>
<output>
blabla,1,2,3,4,5,6,7,8,9,10
1,2,3,4,5,6,7,8,9,10
</output>
~~~~
The core module 'Safe' does work differently in perl 5.12.1 as in
version before like 5.12.0. In 5.13.x changed back to the old so far
i can guess with the help of cpantesters.org information.
I can not tell you more about this beside this is the reason that
the tests for module 'Petal' (on cpan) failed.
~~~~
The next problem is that the return context info is sometimes wrong.
But this sometimes happen by bigger applications and i can not
present a simple example to demostrate the issue.
The last time i see such behavior was in strawberry perl 5.12.1:
In that case a call to Data:
ump::dump at file scope (main:directly in the script file (.pl).
<code mode='missing necessary enviroment'>
print "........\n";
dump $var;
print "........\n";
</code>
Where the output from dump is missed.
Changing print "....\n"; to say "....."; have changed this.
That is at least for me a little bit odd.
In older perls i have seen problems with wantarray.
But again not in a reproduceable way.
with best regards,
Josef