Tied hash numeric values are rounded off under Perl v5.8.6
Hello,
We recently upgraded Perl to v5.8.6 and noticed a behavioral change
w.r.t tied hashes using Tie::IxHash (Tie::Hash::Indexed also) & numeric
hash values. The same version of the module works fine under Perl v5.6.1
Problem:
The attached program below rounds off the numeric hash value
under 5.8.6. (Check "Scalar" & "Splice" values)
<>
Under Perl v5.6.1 the above code works fine.
<>
Further debugging revealed:
From perldelta v5.8.0 -
http://www.perldoc.com/perl5.8.0/pod/perldelta.html#Understanding-of-Num
bers
. . . .
Perl now tries internally to use integer values in
numeric conversions and basic arithmetics (+ - * /) if the arguments are
integers, and tries also to keep the results stored internally as
integers. This change leads to often slightly faster and always less
lossy arithmetics. (Previously Perl always preferred floating point
numbers in its math.)
. . . .
A quick test with the below example
<>
From http://www.faqs.org/docs/perl5int/perlvar.html
. . . .
What about pIOK? pIOK means that the IV slot represents
the underlying ("p" for "private") data. If, for instance, the SV is
tied, then we may not use the "10" that is in the IV slot - we must call
the appropriate FETCH routine to get the value - so IOK is not set. The
"10", however, is private data, only available to the tying mechanism,
so pIOK is set.
. . . .
We understand that this is a behavioral change in Perl v5.8, and one
could revert to the old v5.6.1 behavior by re-compiling Perl with
-DNO_PERL_PRESERVE_IVUV, which we would like to avoid for the reasons
mentioned in the perldelta page above.
Hopefully the Perl module Tie::IxHash could be made aware of this
behavior and avoid errors like above in data interpretation. Please note
that this behavior exists for all tied variables, not just tied hashes.
Any quick response would be appreciated.
Thanks. Rajesh
$ perl -V:'version'
version='5.8.6';
$ perl
use Tie::IxHash;
use Devel::Peek;
my %h;
tie %h, "Tie::IxHash";
$a = 3.55;
$b = $a * 2;
$h{numeric} = $a;
print "Splice = ";
print @h{numeric}, "\n";
print "Scalar = ";
print $h{numeric}, "\n";
^D
Splice = 3
Scalar = 3.55
$$ /usr/local/bin/perl -V:'version'
version='5.6.1';
$ /usr/local/bin/perl
use Tie::IxHash;
use Devel::Peek;
my %h;
tie %h, "Tie::IxHash";
$a = 3.55;
$b = $a * 2;
$h{numeric} = $a;
print "Splice = ";
print @h{numeric}, "\n";
print "Scalar = ";
print $h{numeric}, "\n";
^D
Splice = 3.55
Scalar = 3.55
$$ perl -V:'version'
version='5.8.6';
$ perl
use Devel::Peek;
$a = 3.55;
Devel::Peek::Dump($a);
$b = 2.5 * $a * 4.5;
Devel::Peek::Dump($a);
^D
SV = NV(0x180d38) at 0x17af28
REFCNT = 1
FLAGS = (NOK,pNOK)
NV = 3.55
SV = PVNV(0x19acc8) at 0x17af28
REFCNT = 1
FLAGS = (NOK,pIOK,pNOK)
IV = 3
NV = 3.55
PV = 0
$
Note: The pIOK is set for $a, even when $a is just used in the expr "$b = 2.5 *
$a * 4.5"
The same code when run under v5.6.1 does *not* set pIOK for $a
$ /usr/local/bin/perl -V:'version'
version='5.6.1';
$ /usr/local/bin/perl
use Devel::Peek;
$a = 3.55;
Devel::Peek::Dump($a);
$b = 2.5 * $a * 4.5;
Devel::Peek::Dump($a);
^D
SV = NV(0x11bc78) at 0x110934
REFCNT = 1
FLAGS = (NOK,pNOK)
NV = 3.55
SV = NV(0x11bc78) at 0x110934
REFCNT = 1
FLAGS = (NOK,pNOK)
NV = 3.55
$
Re: Fw: Tied hash numeric values are rounded off under Perl v5.8.6
On Thu, Sep 01, 2005 at 09:58:49PM -0700, Yitzchak Scott-Thoennes wrote: > > I wouldn't really like to venture what the correct fix is, epecially as > > I'm still consfused about the meanings of the public verses private N/I/P > > flags. > > I *think* I understand it, and magic values shouldn't get public flags > full stop. sv_2pv_flags is correct in assuming this. There's code > somewhere that downgrades them to private that should discard any > private flags if any public flags were found (but doesn't). I think the code I'm thinking of is in restore_magic (called by mg_get).
Re: Fw: Tied hash numeric values are rounded off under Perl v5.8.6
On Thu, Sep 01, 2005 at 10:19:11PM +0100, Dave Mitchell wrote:
> On Thu, Sep 01, 2005 at 10:25:24PM +0200, Marcus Holland-Moritz wrote:
> > I think this is a bug in Perl itself that was introduced with
> > 5.8.0 and is still present. It can be cut down to this code:
> >
> > #!perl -wl
> > use Tie::Hash;
> > tie %h, "Tie::StdHash";
> > $a = 3.55;
> > $_ = $a + 0;
> > $h{a} = $a;
> > print $h{a}, ", ", @h{qw(a)};
> >
> > __END__
> >
> > [EMAIL PROTECTED] ~ $ perl5.6.2 test.pl
> > 3.55, 3.55
> >
> > [EMAIL PROTECTED] ~ $ perl5.8.0 test.pl
> > 3.55, 3
> >
> > [EMAIL PROTECTED] ~ $ bleadperl test.pl
> > 3.55, 3
>
> It's down to the different ways Perl_sv_2pv_flags handles magic and
> non-magic values. In the former case, it does mg_get(), which happens to set
> the SV with NOK,pIOK,pNOK flags and IV = 3, NV = 3.55.
> Then, the C branch prefers I over N:
>
> if (SvIOKp(sv)) {
>
> goto tokensave;
> }
> if (SvNOKp(sv)) {
>
>
> so stringifies to "3".
> The non-magical branch only does the I thing if there isn't an N thing:
>
> if (SvIOK(sv) || ((SvIOKp(sv) && !SvNOKp(sv {
>
> so it stringifies to "3.55".
>
> I wouldn't really like to venture what the correct fix is, epecially as
> I'm still consfused about the meanings of the public verses private N/I/P
> flags.
I *think* I understand it, and magic values shouldn't get public flags
full stop. sv_2pv_flags is correct in assuming this. There's code
somewhere that downgrades them to private that should discard any
private flags if any public flags were found (but doesn't).
Re: [perl #37039] perlref documentation about optional -> is too vague
On Thu, Sep 01, 2005 at 08:20:17PM -0700, Yitzchak Scott-Thoennes wrote: > > A warning would be good, but I don't think it's necessary before applying > > my patch, and presumably it would also apply to > > > >@array[0..5]->[1]; > > I mean (foo())[0..5]->[1]; > > > whereas > > > >@array[ (0..5)[-1] ]->[1]; > > I mean ( (foo())[0..5] )[-1]->[1] > > > shouldn't warn with or without the ->. Still agreed. > To summarize, the issue of slices of whatever kind being used in a > scalar context is a separate issue from whether the -> should be > required before dereferences following a list slice. Right. Sorry for the distraction. -- Rick Delaney [EMAIL PROTECTED]
Re: [perl #37039] perlref documentation about optional -> is too vague
On Thu, Sep 01, 2005 at 08:09:41PM -0700, Yitzchak Scott-Thoennes wrote:
> On Thu, Sep 01, 2005 at 09:20:07PM -0400, Rick Delaney wrote:
> >
> > What is
> >
> > my $x = (foo())[0..5][1];
> >
> > supposed to mean? I know it will return (foo())[5][1] but is it a good
> > idea to support this syntax when it looks it might mean some kind of
> > multidimensional slice? To me it looks like
> >
> > map { (foo())[$_][1] } 0 .. 5;
>
> I don't see any difference between your case above and
>
>my $x = (foo())[0..5];
>
> which also doesn't warn.
The difference is that scalar context (on the slice) in this case is
imposed by the assignee but in the first case scalar context is just
imposed. Changing $x to @x will only change the context of the
slice in the latter case which I think is confusing.
>
> > And if that syntax is ok, why not
> >
> > my $x = @array[0..5][1];
>
> Because I couldn't conceive of a use for it? There is separate syntax
> for getting a single element or multiple elements of an array or hash,
> but only one syntax for both cases for a list.
I couldn't conceive of one either, nor for the list slice case. Except
for the single-element slice under discussion. The fact that you can't
distinguish single-element from multiple-element in a slice makes it
even more important to have a warning for multiple-element slices.
>
> > ? I think a warning is in order at least. We already have
> > "Multidimensional syntax %s not supported" for
> >
> > $array[0,1][1];
>
> A warning would be good, but I don't think it's necessary before applying
> my patch,
Agreed.
> and presumably it would also apply to
>
>@array[0..5]->[1];
Good point.
> whereas
>
>@array[ (0..5)[-1] ]->[1];
>
> shouldn't warn with or without the ->.
Agreed, though that is a syntax error without the ->.
--
Rick Delaney
[EMAIL PROTECTED]
Re: advice needed for lib/File/Copy.t dates not preserved on VMS
Craig A. Berry wrote:
At 7:51 PM -0400 8/31/05, John E. Malmberg wrote:
Test 20 of lib/File/Copy.t is failing on VMS because the copied
file has not inherited the creation date from the original file.
Unless I'm looking at the wrong test, it's not creation time, but
rather mtime, which is the last time the contents of the file were
modified (probably ATR$C_REVDATE unless POSIX timestamps are enabled
on an ODS-5 disk). And even though the test description says "mtime
preserved by copy()", it's not testing copy() but rather move().
Ok, one part of the fix will be to change the error message to match the
test.
If you simply rename a file, it does seem that mtime ought to stay the
same. Not sure why that's not working on VMS.
I do now, it is a documented feature in the CRTL.
This test will only pass now on VMS if three conditions exist.
1. The test directory is an ODS-5 volume.
Also I do not know how to determine from Perl if the volume is an ODS-5
volume, as Perl does not seem to have implemented statvfs().
2. The hardware is not a VAX.
I do not yet know how to look that up in a Perl script. My suspicion is
that I will find something in config.
3. The feature DECC$EFS_FILE_TIMESTAMPS is enabled.
The DECC$EFS_FILE_TIMESTAMPS is one of the features that must be enabled
before main() is entered, so unless someone changes the pre-main init
code in VMS.C, the test $ENV{'DECC$EFS_FILE_TIMESTAMPS'} having the
first character being any one of "EeTt1" will determine if the feature
is active.
I am sure that test would be a simple Perl syntax for someone more
experienced at Perl programming than I have.
Essentially, the modification time field only exists on an ODS-5 volume.
On an ODS-2 volume, there is a revision time field and that is used
instead of the modification time field. A rename() operation updated
the modification time field.
The revision time field is updated on any change to the file.
The modification time field is only updated if the data in the file changes.
It might be possible to make a wrapper to rename() on VMS to save and
preserve the revision time after the rename. IMHO, it is not worth the
effort. Better just to document the issue.
Now as to the test, the simple thing is to always skip it for VMS, and
the next thing would be to only skip it if all three conditions are
present for it to be run.
-John
[EMAIL PROTECTED]
Personal Opinion Only
Re: [perl #37039] perlref documentation about optional -> is too vague
On Thu, Sep 01, 2005 at 08:09:41PM -0700, Yitzchak Scott-Thoennes wrote:
> On Thu, Sep 01, 2005 at 09:20:07PM -0400, Rick Delaney wrote:
> > On Thu, Sep 01, 2005 at 05:41:36PM -0700, Yitzchak Scott-Thoennes wrote:
> > > On Wed, Aug 31, 2005 at 06:07:11AM -0700, japhy @ perlmonk. org wrote:
> > > > sub foo { ...; return @data }
> > > >
> > > > my $x = (foo())[0][1];
> > > >
> > > > which would have the same effect as
> > > >
> > > > my @return = foo();
> > > > my $x = $return[0][1];
> > > >
> > > > However, it's a syntax error.
> > [...]
> > > I don't see any reason not to just make it legal syntax instead:
> >
> >
> > What is
> >
> > my $x = (foo())[0..5][1];
> >
> > supposed to mean? I know it will return (foo())[5][1] but is it a good
> > idea to support this syntax when it looks it might mean some kind of
> > multidimensional slice? To me it looks like
> >
> > map { (foo())[$_][1] } 0 .. 5;
>
> I don't see any difference between your case above and
>
>my $x = (foo())[0..5];
>
> which also doesn't warn.
>
> > And if that syntax is ok, why not
> >
> > my $x = @array[0..5][1];
>
> Because I couldn't conceive of a use for it? There is separate syntax
> for getting a single element or multiple elements of an array or hash,
> but only one syntax for both cases for a list.
>
> > ? I think a warning is in order at least. We already have
> > "Multidimensional syntax %s not supported" for
> >
> > $array[0,1][1];
>
> A warning would be good, but I don't think it's necessary before applying
> my patch, and presumably it would also apply to
>
>@array[0..5]->[1];
I mean (foo())[0..5]->[1];
> whereas
>
>@array[ (0..5)[-1] ]->[1];
I mean ( (foo())[0..5] )[-1]->[1]
> shouldn't warn with or without the ->.
To summarize, the issue of slices of whatever kind being used in a
scalar context is a separate issue from whether the -> should be
required before dereferences following a list slice.
Re: [perl #37039] perlref documentation about optional -> is too vague
On Thu, Sep 01, 2005 at 09:20:07PM -0400, Rick Delaney wrote:
> On Thu, Sep 01, 2005 at 05:41:36PM -0700, Yitzchak Scott-Thoennes wrote:
> > On Wed, Aug 31, 2005 at 06:07:11AM -0700, japhy @ perlmonk. org wrote:
> > > sub foo { ...; return @data }
> > >
> > > my $x = (foo())[0][1];
> > >
> > > which would have the same effect as
> > >
> > > my @return = foo();
> > > my $x = $return[0][1];
> > >
> > > However, it's a syntax error.
> [...]
> > I don't see any reason not to just make it legal syntax instead:
>
>
> What is
>
> my $x = (foo())[0..5][1];
>
> supposed to mean? I know it will return (foo())[5][1] but is it a good
> idea to support this syntax when it looks it might mean some kind of
> multidimensional slice? To me it looks like
>
> map { (foo())[$_][1] } 0 .. 5;
I don't see any difference between your case above and
my $x = (foo())[0..5];
which also doesn't warn.
> And if that syntax is ok, why not
>
> my $x = @array[0..5][1];
Because I couldn't conceive of a use for it? There is separate syntax
for getting a single element or multiple elements of an array or hash,
but only one syntax for both cases for a list.
> ? I think a warning is in order at least. We already have
> "Multidimensional syntax %s not supported" for
>
> $array[0,1][1];
A warning would be good, but I don't think it's necessary before applying
my patch, and presumably it would also apply to
@array[0..5]->[1];
whereas
@array[ (0..5)[-1] ]->[1];
shouldn't warn with or without the ->.
Re: Tandyman error
Robert William Leach <[EMAIL PROTECTED]> wrote:
:I get the same segmentation fault behavior when I run it myself and I
:have an idea what is going on here. This specific regular expression
:limitation is not mentioned in the documentation, but it has to do with
:a maximum limit inside the curly braces. The string of N's in your
:sequence being matched against is exceeding that limit. This is the
:line of code that is causing the segmentation fault when it reaches
:that string of N's:
:
: while($seq =~ /((.{$unit_size})\2{$minunits,})(.{0,$unit_size})/g)
:
:My guess is that when the string matches "\2{$minunits,}" more than a
:certain number of times, you get a segmentation fault, but in perl's
:regular expression documentation, the limit is said to be on the
:numbers used in the curly braces, not the length of the string itself.
:At the time of the fault, $minunits is 10 and $unit_size is also 2, so
:it's the string being matched that is causing the code to choke.
The limit of around 32766 is the only explicit limit. The implicit limit,
which is what is causing the segfault, is the size of the C stack - the
regular expression engine uses recursive function calls in the C code,
and if the code recurses too deeply it overflows the stack.
The intention is eventually to replace the current implementation with
one that avoids this problem, but that is unlikely to happen in time
for the next major release (perl-5.10). In the meantime, you can usually
extend the available range by using OS tools to increase the size of
the stack available to perl.
You'll find some additional information in the bugs database at
.
Hugo
Re: File::Temp::tempfile() croaks
Tom Christiansen was very clear that he wanted drastic action when
something went wrong with "safe" tempfiles.
I'll update the documentation for the next release.
Tim
On Wed, 24 Aug 2005, Steve Hay wrote:
I was just caught out by some undocumented behaviour in
File::Temp::tempfile(), namely, that it croak()'s in some
circumstances. (The particular situation that I had was trying to
create a temporary file in a specific directory which it turns out is
not writable).
There is no indication in the tempfile() docs that it might croak() in
such cases (or at all). Would it be worth updating the docs to mention
this fact so that users know to eval{} tempfile() calls, or should
tempfile() not actually croak() at all?
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
Re: [perl #37039] perlref documentation about optional -> is too vague
On Thu, Sep 01, 2005 at 05:41:36PM -0700, Yitzchak Scott-Thoennes wrote:
> On Wed, Aug 31, 2005 at 06:07:11AM -0700, japhy @ perlmonk. org wrote:
> > sub foo { ...; return @data }
> >
> > my $x = (foo())[0][1];
> >
> > which would have the same effect as
> >
> > my @return = foo();
> > my $x = $return[0][1];
> >
> > However, it's a syntax error.
[...]
> I don't see any reason not to just make it legal syntax instead:
What is
my $x = (foo())[0..5][1];
supposed to mean? I know it will return (foo())[5][1] but is it a good
idea to support this syntax when it looks it might mean some kind of
multidimensional slice? To me it looks like
map { (foo())[$_][1] } 0 .. 5;
And if that syntax is ok, why not
my $x = @array[0..5][1];
? I think a warning is in order at least. We already have
"Multidimensional syntax %s not supported" for
$array[0,1][1];
--
Rick Delaney
[EMAIL PROTECTED]
Re: [perl #37039] perlref documentation about optional -> is too vague
On Wed, Aug 31, 2005 at 06:07:11AM -0700, japhy @ perlmonk. org wrote:
> In 'perlref', item #3 of 'Using References' says
>
> One more thing here. The arrow is optional between brackets sub-
> scripts, so you can shrink the above down to
>
> $array[$x]{"foo"}[0] = "January";
>
> This led me to believe I could write:
>
> sub foo { ...; return @data }
>
> my $x = (foo())[0][1];
>
> which would have the same effect as
>
> my @return = foo();
> my $x = $return[0][1];
>
> However, it's a syntax error. This can be fixed with an arrow:
>
> my $x = (foo())[0]->[1];
>
> The problem is that (foo())[0] is NOT analogous to $array[$x]; one is a
> list slice, the other is a single element from an array. But the
> documentation does not distinguish when it says "optional between brackets
> subscripts [sic]".
>
> I think the language there should be polished a bit.
I don't see any reason not to just make it legal syntax instead:
--- p/perly.y.orig 2005-06-08 01:32:12.0 -0700
+++ p/perly.y 2005-08-31 11:02:57.520643200 -0700
@@ -487,6 +487,10 @@ subscripted:star '{' expr ';' '}'
| subscripted '(' ')'/* $foo->{bar}->() */
{ $$ = newUNOP(OP_ENTERSUB, OPf_STACKED,
newCVREF(0, scalar($1))); }
+ | '(' expr ')' '[' expr ']'/* list slice */
+ { $$ = newSLICEOP(0, $5, $2); }
+ | '(' ')' '[' expr ']' /* empty list slice! */
+ { $$ = newSLICEOP(0, $4, Nullop); }
;
/* Binary operators between terms */
@@ -622,10 +626,6 @@ term : termbinop
{ $$ = newUNOP(OP_AV2ARYLEN, 0, ref($1, OP_AV2ARYLEN));}
| subscripted
{ $$ = $1; }
- | '(' expr ')' '[' expr ']'/* list slice */
- { $$ = newSLICEOP(0, $5, $2); }
- | '(' ')' '[' expr ']' /* empty list slice! */
- { $$ = newSLICEOP(0, $4, Nullop); }
| ary '[' expr ']' /* array slice */
{ $$ = prepend_elem(OP_ASLICE,
newOP(OP_PUSHMARK, 0),
End of Patch.
BTW, cygwin only has bison 1.875b, not the allowed 1.875 or 1.875c,
but it seemed to work. I also note that Debian stable has 1.875d;
would it make sense to just allow any 1.875* version?
--- p/regen_perly.pl.orig 2005-05-07 04:36:14.0 -0700
+++ p/regen_perly.pl2005-08-31 11:16:02.86992 -0700
@@ -65,7 +65,7 @@
# the test below to allow that version too. DAPM Feb 04.
my $version = `$bison -V`;
-unless ($version =~ /\b(1\.875c?|2\.0)\b/) { die <
Smoke [5.9.0] 25346 FAIL(m) openbsd 3.6 (i386/1 cpu)
Automated smoke report for 5.9.0 patch 25346
accognoscere.homeunix.org: AMD Athlon(TM) XP 1800+ ("AuthenticAMD" 686-class)
(i386/1 cpu)
onopenbsd - 3.6
using cc version 2.95.3 20010125 (prerelease, propolice)
smoketime 3 minutes 1 seconds (average 22.625 seconds)
Summary: FAIL(m)
O = OK F = Failure(s), extended report at the bottom
X = Failure(s) under TEST but not under harness
? = still running or test results not (yet) available
Build failures during: - = unknown or N/A
c = Configure, m = make, M = make (after miniperl), t = make test-prep
25346 Configuration (common) none
--- -
m - m -
m - m - -Duse64bitint
m - m - -Duseithreads
m - m - -Duseithreads -Duse64bitint
| | | +- PERLIO = perlio -DDEBUGGING
| | +--- PERLIO = stdio -DDEBUGGING
| +- PERLIO = perlio
+--- PERLIO = stdio
--
Report by Test::Smoke v1.19#716 running on perl 5.8.5
(Reporter v0.016 / Smoker v0.015)
Re: s///ge; consumes PL_tmps_stack in its loop
RGS,
On Sep 01, 2005, at 22:21 , Rafael Garcia-Suarez wrote:
+if( (cx->sb_iters&0x)==0 ) {
OK, so if I understand correctly, you're doing that every 65536th
loop ?
Just trying to understand your patch a bit more.
I too wondered if 65536 was the optimal value so I benchmarked
(result below)
Looks like the optimal value is 1024, not 65536. Sounds natural
since on most platforms the page size is 4k, or sizeof(pointer)*1024.
The modified patch (against maintperl) and benchmark script and its
result right after the signature.
Dan the (Perl5 Porter|Friend of Hers)
--- perl-5.8.x/pp_ctl.c Fri Apr 22 23:29:48 2005
+++ perl-5.8.x.d/pp_ctl.c Fri Sep 2 06:29:36 2005
@@ -159,6 +159,9 @@
RETURN;
}
+#define HIOS_HACK_FREETMPS_IN_SGE 1
+#define ITERS_BEFORE_FREETMPS_IN_SGE 1024
+
PP(pp_substcont)
{
dSP;
@@ -189,6 +192,13 @@
cx->sb_rxtainted |= 2;
sv_catsv(dstr, POPs);
+#ifdef HIOS_HACK_FREETMPS_IN_SGE
+ if( (cx->sb_iters % ITERS_BEFORE_FREETMPS_IN_SGE) == 0 ) {
+ /* shrink tmps stack */
+ FREETMPS;
+ SAVETMPS;
+ }
+#endif
/* Are we done */
if (cx->sb_once || !CALLREGEXEC(aTHX_ rx, s, cx->sb_strend,
orig,
s == m, cx->sb_targ, NULL,
__END_OF_PATCH__
# benchmark script -- modified so it runs on BSD-ish platforms
use strict;
use Time::HiRes qw/time gettimeofday tv_interval/;
my $t = [ gettimeofday() ];
my $i = 0;
my $s = "." x 1_000_000;
printf "length: %d\n", length($s);
my $started = time();
$s=~ s{ . }
{ my $x="."; ++$i % 100_000 or &ps; $x }gex;
printf "Total: %f seconds\n", time()-$started;
# 0 1 23 4 5
# USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME
COMMAND
sub ps{
my ($vst, $rss);
for my $ps (split /\n/, `ps awwux`){
my @ps = split /\s+/, $ps;
next if $ps[1] != $$;
($vst, $rss) = @ps[4,5];
}
my $tt = $t;
$t=[ gettimeofday ];
printf "i=%d, interval=%f, vst=%d, rss=%d\n",
$i, tv_interval($tt,$t), $vst, $rss;
}
__END__
# Benchmark Result on FreeBSD 5.4-STABLE i386, 2GB RAM, Dual Xeon
2.66GHz
# Got similar results on Mac OS X v10.4.2
# hack turned off
length: 100
i=10, interval=0.335474, vst=9584, rss=9084
i=20, interval=0.421420, vst=15064, rss=14572
i=30, interval=0.535432, vst=20292, rss=19808
i=40, interval=0.629692, vst=25204, rss=24720
i=50, interval=0.723880, vst=30156, rss=29676
i=60, interval=0.978336, vst=32688, rss=32216
i=70, interval=0.972722, vst=36660, rss=36188
i=80, interval=1.044227, vst=47692, rss=47232
i=90, interval=1.154285, vst=48768, rss=48312
i=100, interval=1.204723, vst=58036, rss=57588
Total: 8.211410 seconds
#define ITERS_BEFORE_FREETMPS_IN_SGE 8
length: 100
i=10, interval=0.309985, vst=5920, rss=5396
i=20, interval=0.426167, vst=6504, rss=5892
i=30, interval=0.328450, vst=7560, rss=6888
i=40, interval=0.319155, vst=9132, rss=8232
i=50, interval=0.322011, vst=9132, rss=8524
i=60, interval=0.334513, vst=11488, rss=10396
i=70, interval=0.333703, vst=11488, rss=10688
i=80, interval=0.344401, vst=11488, rss=10980
i=90, interval=0.353685, vst=15028, rss=13636
i=100, interval=0.356945, vst=15028, rss=13928
Total: 3.426557 seconds
#define ITERS_BEFORE_FREETMPS_IN_SGE 256
length: 100
i=10, interval=0.263990, vst=5272, rss=4772
i=20, interval=0.288537, vst=5316, rss=4820
i=30, interval=0.298329, vst=5708, rss=5212
i=40, interval=0.306359, vst=5848, rss=5352
i=50, interval=0.316509, vst=6136, rss=5640
i=60, interval=0.321965, vst=6328, rss=5832
i=70, interval=0.330730, vst=5940, rss=5440
i=80, interval=0.372460, vst=6820, rss=6324
i=90, interval=0.443334, vst=7012, rss=6516
i=100, interval=0.374078, vst=6376, rss=5828
Total: 3.311563 seconds
#define ITERS_BEFORE_FREETMPS_IN_SGE 1024
length: 100
i=10, interval=0.262606, vst=5276, rss=4776
i=20, interval=0.287707, vst=5504, rss=5004
i=30, interval=0.296727, vst=5412, rss=4912
i=40, interval=0.305621, vst=5508, rss=5008
i=50, interval=0.312880, vst=6096, rss=5596
i=60, interval=0.318939, vst=6244, rss=5744
i=70, interval=0.327908, vst=6340, rss=5840
i=80, interval=0.337890, vst=6716, rss=6220
i=90, interval=0.345272, vst=6908, rss=6412
i=100, interval=0.351104, vst=6132, rss=5632
Total: 3.141935 seconds
#define ITERS_BEFORE_FREETMPS_IN_SGE 4096
length: 100
i=10, interval=0.264656, vst=5412, rss=4912
i=20, interval=0.288359, vst=5632, rss=5132
i=30, interval=0.298809, vst=5540, rss=5040
i=40, interval=0.347351, vst=5636, rss=5136
i=50, interval=0.421626, vst=6224, rss=5724
i=60, interval=0.368024, vst=6416, rss=5920
i=70, interval=0.328497, vst=6608, rss=6112
i=80, interval=0.337559, vst=6036, rss=5532
i=90, interval=0.345616, vst=6132, rss=5628
i=100, interval
Re: Fw: Tied hash numeric values are rounded off under Perl v5.8.6
On Thu, Sep 01, 2005 at 10:25:24PM +0200, Marcus Holland-Moritz wrote:
> I think this is a bug in Perl itself that was introduced with
> 5.8.0 and is still present. It can be cut down to this code:
>
> #!perl -wl
> use Tie::Hash;
> tie %h, "Tie::StdHash";
> $a = 3.55;
> $_ = $a + 0;
> $h{a} = $a;
> print $h{a}, ", ", @h{qw(a)};
>
> __END__
>
> [EMAIL PROTECTED] ~ $ perl5.6.2 test.pl
> 3.55, 3.55
>
> [EMAIL PROTECTED] ~ $ perl5.8.0 test.pl
> 3.55, 3
>
> [EMAIL PROTECTED] ~ $ bleadperl test.pl
> 3.55, 3
It's down to the different ways Perl_sv_2pv_flags handles magic and
non-magic values. In the former case, it does mg_get(), which happens to set
the SV with NOK,pIOK,pNOK flags and IV = 3, NV = 3.55.
Then, the C branch prefers I over N:
if (SvIOKp(sv)) {
goto tokensave;
}
if (SvNOKp(sv)) {
so stringifies to "3".
The non-magical branch only does the I thing if there isn't an N thing:
if (SvIOK(sv) || ((SvIOKp(sv) && !SvNOKp(sv {
so it stringifies to "3.55".
I wouldn't really like to venture what the correct fix is, epecially as
I'm still consfused about the meanings of the public verses private N/I/P
flags.
--
Wesley Crusher gets beaten up by his classmates for being a smarmy git,
and consequently has a go at making some friends of his own age for a
change.
-- Things That Never Happen in "Star Trek" #18
Fw: Tied hash numeric values are rounded off under Perl v5.8.6
I think this is a bug in Perl itself that was introduced with
5.8.0 and is still present. It can be cut down to this code:
#!perl -wl
use Tie::Hash;
tie %h, "Tie::StdHash";
$a = 3.55;
$_ = $a + 0;
$h{a} = $a;
print $h{a}, ", ", @h{qw(a)};
__END__
[EMAIL PROTECTED] ~ $ perl5.6.2 test.pl
3.55, 3.55
[EMAIL PROTECTED] ~ $ perl5.8.0 test.pl
3.55, 3
[EMAIL PROTECTED] ~ $ bleadperl test.pl
3.55, 3
Unfortunately I don't have the time right now to investigate
myself. I'm forwarding your message to the perl5-porters list.
Marcus
Begin forwarded message:
Date: Thu, 1 Sep 2005 13:52:59 +0530
From: "Mandalemula, Rajesh" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>, "Mandalemula, Rajesh" <[EMAIL PROTECTED]>
Subject: Tied hash numeric values are rounded off under Perl v5.8.6
Hello,
We recently upgraded Perl to v5.8.6 and noticed a behavioral change
w.r.t tied hashes using Tie::IxHash (Tie::Hash::Indexed also) & numeric
hash values. The same version of the module works fine under Perl v5.6.1
Problem:
The attached program below rounds off the numeric hash value
under 5.8.6. (Check "Scalar" & "Splice" values)
<>
Under Perl v5.6.1 the above code works fine.
<>
Further debugging revealed:
From perldelta v5.8.0 -
http://www.perldoc.com/perl5.8.0/pod/perldelta.html#Understanding-of-Num
bers
. . . .
Perl now tries internally to use integer values in
numeric conversions and basic arithmetics (+ - * /) if the arguments are
integers, and tries also to keep the results stored internally as
integers. This change leads to often slightly faster and always less
lossy arithmetics. (Previously Perl always preferred floating point
numbers in its math.)
. . . .
A quick test with the below example
<>
From http://www.faqs.org/docs/perl5int/perlvar.html
. . . .
What about pIOK? pIOK means that the IV slot represents
the underlying ("p" for "private") data. If, for instance, the SV is
tied, then we may not use the "10" that is in the IV slot - we must call
the appropriate FETCH routine to get the value - so IOK is not set. The
"10", however, is private data, only available to the tying mechanism,
so pIOK is set.
. . . .
We understand that this is a behavioral change in Perl v5.8, and one
could revert to the old v5.6.1 behavior by re-compiling Perl with
-DNO_PERL_PRESERVE_IVUV, which we would like to avoid for the reasons
mentioned in the perldelta page above.
Hopefully the Perl module Tie::IxHash could be made aware of this
behavior and avoid errors like above in data interpretation. Please note
that this behavior exists for all tied variables, not just tied hashes.
Any quick response would be appreciated.
Thanks. Rajesh$ perl -V:'version'
version='5.8.6';
$ perl
use Tie::IxHash;
use Devel::Peek;
my %h;
tie %h, "Tie::IxHash";
$a = 3.55;
$b = $a * 2;
$h{numeric} = $a;
print "Splice = ";
print @h{numeric}, "\n";
print "Scalar = ";
print $h{numeric}, "\n";
^D
Splice = 3
Scalar = 3.55
$$ /usr/local/bin/perl -V:'version'
version='5.6.1';
$ /usr/local/bin/perl
use Tie::IxHash;
use Devel::Peek;
my %h;
tie %h, "Tie::IxHash";
$a = 3.55;
$b = $a * 2;
$h{numeric} = $a;
print "Splice = ";
print @h{numeric}, "\n";
print "Scalar = ";
print $h{numeric}, "\n";
^D
Splice = 3.55
Scalar = 3.55
$$ perl -V:'version'
version='5.8.6';
$ perl
use Devel::Peek;
$a = 3.55;
Devel::Peek::Dump($a);
$b = 2.5 * $a * 4.5;
Devel::Peek::Dump($a);
^D
SV = NV(0x180d38) at 0x17af28
REFCNT = 1
FLAGS = (NOK,pNOK)
NV = 3.55
SV = PVNV(0x19acc8) at 0x17af28
REFCNT = 1
FLAGS = (NOK,pIOK,pNOK)
IV = 3
NV = 3.55
PV = 0
$
Note: The pIOK is set for $a, even when $a is just used in the expr "$b = 2.5 *
$a * 4.5"
The same code when run under v5.6.1 does *not* set pIOK for $a
$ /usr/local/bin/perl -V:'version'
version='5.6.1';
$ /usr/local/bin/perl
use Devel::Peek;
$a = 3.55;
Devel::Peek::Dump($a);
$b = 2.5 * $a * 4.5;
Devel::Peek::Dump($a);
^D
SV = NV(0x11bc78) at 0x110934
REFCNT = 1
FLAGS = (NOK,pNOK)
NV = 3.55
SV = NV(0x11bc78) at 0x110934
REFCNT = 1
FLAGS = (NOK,pNOK)
NV = 3.55
$
RE: [ANNOUNCE] Archive::Tar 1.25
-Original Message- From: Rafael Garcia-Suarez [mailto:[EMAIL PROTECTED] Sent: 27 August 2005 17:59 To: Jos I. Boumans Cc: Perl 5 Porters Subject: Re: [ANNOUNCE] Archive::Tar 1.25 On 8/25/05, Jos I. Boumans <[EMAIL PROTECTED]> wrote: > Thanks, applied as 12201, with the following additions: > > * add pod to ptardiff so it gets a manpage I also just fixed a test failure when perl was built with -Dmksymlinks. I think this isn't a common configuration since nobody found it before. Patch at : http://public.activestate.com/cgi-bin/perlbrowse?patch=25333 - I don't think this is the best fix for this. Not only do I use -Dmksymlinks but I sometimes do: % sh ../perl-current/Configure -des -Dmksymlinks -Dusedevel % make all test % make distclean % sh Configure -des -Dusedevel -Duse64bitint -Dnoextensions=Encode This now fails the fixed Archive::Tar test. Better to create the required files as not links in Archive/Tar/t/00_setup.t See the attached patch; it is also necessary to do. % rm -rf lib/Archive/Tar/t/src/long/b lib/Archive/Tar/t/src/short/b Robin --- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Serco House, 16 Bartley Wood Business Park, Hook, Hampshire, United Kingdom RG27 9UY --- archivetar.patch Description: Binary data
Re: mentoring new perl 5 porters
Nicholas Clark wrote: One of the good ideas of the Google Summer of Code was to insist that every project has a mentor; an experienced person to advise and guide the grantee. I'm wondering whether we could embrace this idea for perl5-porters. We often feel rather thin on the ground, and there are many people who might start to help, but the general feeling I get is that most find the first step daunting. [...] Does this seem like a good idea? +1 -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://mailchannels.com
Re: [CRACK] build a better runloop
On Thu, Sep 01, 2005 at 04:45:54PM +0200, Rafael Garcia-Suarez wrote: > > > Correct me if I'm wrong, but the whole runloop is pluggable, and can be > > > replaced by any CPAN module. > > > > Right. > > The main problem being, how to replace the top level runloop. I'm not sure that would be necessary, at least not to start with. The new runops would just kick in the first time a loop was needed after the module was loaded. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: no 6;
On 9/1/05, Rafael Garcia-Suarez <[EMAIL PROTECTED]> wrote: > I just commited into bleadperl a patch that implements this : > > $ ./perl -e 'no 5' > Perls since v5.0.0 too modern--this is v5.9.3, stopped at -e line 1. > BEGIN failed--compilation aborted at -e line 1. > > That is, the exact opposite of the current "use VERSION" syntax. Does this mean that we have to implement perl4 compatability? perl5 -e 'no 5; print "[EMAIL PROTECTED]"'
no 6;
I just commited into bleadperl a patch that implements this : $ ./perl -e 'no 5' Perls since v5.0.0 too modern--this is v5.9.3, stopped at -e line 1. BEGIN failed--compilation aborted at -e line 1. That is, the exact opposite of the current "use VERSION" syntax. One of the uses I had in mind for it is to put "no 6" at the top of modules or programs that are too tightly bound to Perl 5 that there wouldn't be beneficial to port them to Perl 6. B::* or Safe come to mind. Of course, that would mean that Perl 6 should also recognize and handle the "no 6" idiom. That's why I'm cc:ing p6l. Comments ? The patch can be found at http://public.activestate.com/cgi-bin/perlbrowse?patch=25344
Re: mentoring new perl 5 porters
On 9/1/05, Nicholas Clark <[EMAIL PROTECTED]> wrote: > One of the good ideas of the Google Summer of Code was to insist that every > project has a mentor; an experienced person to advise and guide the grantee. > > I'm wondering whether we could embrace this idea for perl5-porters. We often > feel rather thin on the ground, and there are many people who might start to > help, but the general feeling I get is that most find the first step daunting. > > > Coupled with this I'm currently sitting at YAPC::EU, where there are lots of > lightning talk slots free tomorrow. > > > So I was wondering whether I should do a lightning talk about some of the > approachable pure-perl tasks in the perltoto, in the hope of gaining some > interest. But it would be more likely to succeed in its aim if there are > actually some people who would volunteer to consider the task. > > I wasn't going to name anyone in a talk. > People don't actually have to mentor anything - there's no shame in saying > you'd consider it and then realising that you can't do it (and no need to say > why) > You don't need to know C. Let alone the perl source. > Just have some confidence about how to go about tasks, and create well formed > patches. > > > > Does this seem like a good idea? Yes. I think it would be. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
Re: mentoring new perl 5 porters
On Thu, Sep 01, 2005 at 10:40:18AM +0100, Nicholas Clark wrote: > One of the good ideas of the Google Summer of Code was to insist that every > project has a mentor; an experienced person to advise and guide the grantee. > > I'm wondering whether we could embrace this idea for perl5-porters. We often > feel rather thin on the ground, and there are many people who might start to > help, but the general feeling I get is that most find the first step daunting. > > > Coupled with this I'm currently sitting at YAPC::EU, where there are lots of > lightning talk slots free tomorrow. > > > So I was wondering whether I should do a lightning talk about some of the > approachable pure-perl tasks in the perltoto, in the hope of gaining some > interest. But it would be more likely to succeed in its aim if there are > actually some people who would volunteer to consider the task. > > I wasn't going to name anyone in a talk. > People don't actually have to mentor anything - there's no shame in saying > you'd consider it and then realising that you can't do it (and no need to say > why) > You don't need to know C. Let alone the perl source. > Just have some confidence about how to go about tasks, and create well formed > patches. > > > > Does this seem like a good idea? > > Nicholas Clark One pure-Perl todo that's been discussed, although not in perltodo exactly, was the writing of TODO tests for perlbugs. No special knowledge is needed other than navigating through RT and creating patches for the various test files. Steve Peters [EMAIL PROTECTED]
Re: [CRACK] build a better runloop
Rafael Garcia-Suarez wrote: > Nicholas Clark wrote: > > Leo has just done a talk on parrot, where he showed a graph showing the > > relative speeds of runloops. The switch runloop is about 3-4 times faster > > What's a switch runloop ? What would it switch on ? PL_op->op_type ? > Would it be really faster than a function pointer call ? This was a rhetorical question. How would we know without benchmarks :) > > Correct me if I'm wrong, but the whole runloop is pluggable, and can be > > replaced by any CPAN module. > > Right. The main problem being, how to replace the top level runloop.
Re: [CRACK] build a better runloop
Nicholas Clark wrote: > Leo has just done a talk on parrot, where he showed a graph showing the > relative speeds of runloops. The switch runloop is about 3-4 times faster What's a switch runloop ? What would it switch on ? PL_op->op_type ? Would it be really faster than a function pointer call ? > Correct me if I'm wrong, but the whole runloop is pluggable, and can be > replaced by any CPAN module. Right.
[CRACK] build a better runloop
The perl 5 runloop is simple: http://public.activestate.com/cgi-bin/perlbrowse?file=run.c&blame=1 It's a tight loop, of about 8 instructions. It's also analogous to the simplest runloop in parrot Leo has just done a talk on parrot, where he showed a graph showing the relative speeds of runloops. The switch runloop is about 3-4 times faster Correct me if I'm wrong, but the whole runloop is pluggable, and can be replaced by any CPAN module. So I'm wondering if anyone wants to take this idea and see if they can create a replacement runloop module that makes existing perl faster. Nicholas Clark
Re: s///ge; consumes PL_tmps_stack in its loop
YAMASHINA Hio wrote:
> Hi.
>
> A large amount of s///ge; consumes PL_tmps_stack in its loop.
>
> This occues REPLACEMENT (right) part has statement ( eg. s//$x;$x/ge;).
>
> Patch is follows:
>
> diff -urN perl-5.8.7.orig/pp_ctl.c perl-5.8.7/pp_ctl.c
> --- perl-5.8.7.orig/pp_ctl.c2005-04-22 23:12:38.0 +0900
> +++ perl-5.8.7/pp_ctl.c 2005-08-30 10:55:05.0 +0900
> @@ -188,6 +188,11 @@
> if (!(cx->sb_rxtainted & 2) && SvTAINTED(TOPs))
> cx->sb_rxtainted |= 2;
> sv_catsv(dstr, POPs);
> + if( (cx->sb_iters&0x)==0 ) {
OK, so if I understand correctly, you're doing that every 65536th loop ?
Just trying to understand your patch a bit more.
> + /* shrink tmps stack */
> + FREETMPS;
> + SAVETMPS;
> + }
>
> /* Are we done */
> if (cx->sb_once || !CALLREGEXEC(aTHX_ rx, s, cx->sb_strend, orig,
Re: utf8::upgrade,utf8::encode and utf8::is_utf8 on EBCDIC platform
Hello.
I think it is correct.
On EBCDIC platforms, perl uses UTF-EBCDIC instead of UTF-8,
nevertheless perl calls it "utf8."
In general chr(0xFF) (equals to "\xFF") in EBCDIC encodings
corresponds to U+009F, that is a single-octet control character;
thus a single octet sequence "\xFF" is well-form in UTF-EBCDIC too.
If you want to convert an interger to a character according to
Unicode scalar values, you can use pack('U'), but not chr().
For example, pack('U', 0xFF) should correspond to U+00FF
(y with diaeresis), everywhere (both on ASCII and on EBCDIC).
Regards,
SADAHIRO Tomoyuki
> Hi,
>
> This are the tetstcase i'm runing on EBCDIC platform,
>
> my $b = chr(0x0FF);
> $p=utf8::upgrade($b);
> print "\n$p";
>
> utf8::upgarde returns the number of octets necessary
> to represent the string as UTF-X.
>
> EBCDIC output is 1 whereas ASCII platform output is 2.
> Is the return value i'm getting on EBCDIC is correct?
>
> my $c=chr(0x0FF);
> print "before $c\n";
> print "\n";
> utf8::encode($c);
> print "after $c\n";
> print length($c);
>
> On ASCII before is single octet repsentation and after
> encode is two byte , length is 2.
>
> On EBCDIC it is single before and after encode and
> length is 1.
>
> Is this correct on EBCDIC or is it a bug in code for
> EBCDIC ?
>
> utf::is_utf8 test whether STRING is in UTF-8, so 0x0FF
> is UTF-8 on EBCDIC?
utf8::upgrade,utf8::encode and utf8::is_utf8 on EBCDIC platform
Hi, This are the tetstcase i'm runing on EBCDIC platform, my $b = chr(0x0FF); $p=utf8::upgrade($b); print "\n$p"; utf8::upgarde returns the number of octets necessary to represent the string as UTF-X. EBCDIC output is 1 whereas ASCII platform output is 2. Is the return value i'm getting on EBCDIC is correct? my $c=chr(0x0FF); print "before $c\n"; print "\n"; utf8::encode($c); print "after $c\n"; print length($c); On ASCII before is single octet repsentation and after encode is two byte , length is 2. On EBCDIC it is single before and after encode and length is 1. Is this correct on EBCDIC or is it a bug in code for EBCDIC ? utf::is_utf8 test whether STRING is in UTF-8, so 0x0FF is UTF-8 on EBCDIC? __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail
Smoke [5.9.3] 25342 FAIL(XF) bsd/os 4.1 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25342 fixit.xs4all.nl: Pentium II (i386/1 cpu) onbsd/os - 4.1 using cc version egcs-2.91.66 19990314 (egcs-1.1.2 release) smoketime 3 hours 55 minutes (average 1 hour 57 minutes) Summary: FAIL(XF) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25342 Configuration (common) none --- - F F - - -Duse64bitint O X - - | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio] -Duse64bitint ../t/op/int.t...FAILED 11 [perlio] -Duse64bitint ../lib/Net/hostent.tFAILED 4-7 ../t/op/int.t...FAILED 11 [perlio] Inconsistent test results (between TEST and harness): ../lib/Net/hostent.tFAILED at test 4 -- Report by Test::Smoke v1.19_67 build 842 running on perl 5.00503 (Reporter v0.019 / Smoker v0.023)
mentoring new perl 5 porters
One of the good ideas of the Google Summer of Code was to insist that every project has a mentor; an experienced person to advise and guide the grantee. I'm wondering whether we could embrace this idea for perl5-porters. We often feel rather thin on the ground, and there are many people who might start to help, but the general feeling I get is that most find the first step daunting. Coupled with this I'm currently sitting at YAPC::EU, where there are lots of lightning talk slots free tomorrow. So I was wondering whether I should do a lightning talk about some of the approachable pure-perl tasks in the perltoto, in the hope of gaining some interest. But it would be more likely to succeed in its aim if there are actually some people who would volunteer to consider the task. I wasn't going to name anyone in a talk. People don't actually have to mentor anything - there's no shame in saying you'd consider it and then realising that you can't do it (and no need to say why) You don't need to know C. Let alone the perl source. Just have some confidence about how to go about tasks, and create well formed patches. Does this seem like a good idea? Nicholas Clark
Re: sort {$b cmp $a} and the peephole optimiser
On Thu, Sep 01, 2005 at 10:59:52AM +0200, Rafael Garcia-Suarez wrote: > Nicholas Clark wrote: > > I expected to see an ex-scmp in there. Is the cmp ever compiled to ops? > > yes, but it's freed in S_simplify_sort, called by ck_sort during optree > construction, i.e. before the peephole optimizer is called. Aha. This was what I was wondering, and also why the departure from perl's usual policy of not free-ing ops during optimisation. > Concise shows the DESC flag on the sort op that indicates this is a reverse > sort. and there are also NUM and now REVERSE (IIRC) Nicholas Clark
Re: sort {$b cmp $a} and the peephole optimiser
Nicholas Clark wrote:
> Where does the op for cmp go in this?
>
> $ perl -MO=Concise -e '@a = sort {$b cmp $a} @b'
>
> I see:
>
> c <@> leave[1 ref] vKP/REFC ->(end)
> 1 <0> enter ->2
> 2 <;> nextstate(main 2 -e:1) v ->3
> b <2> aassign[t2] vKS ->c
> -<1> ex-list lK ->8
> 3 <0> pushmark s ->4
> 7 <@> sort lK/DESC ->8
> 4 <0> pushmark s ->5
> 6 <1> rv2av[t3] lK/1 ->7
> 5 <$> gv(*b) s ->6
> -<1> ex-list lK ->b
> 8 <0> pushmark s ->9
> a <1> rv2av[t1] lKRM*/1 ->b
> 9 <$> gv(*a) s ->a
>
>
>
> I expected to see an ex-scmp in there. Is the cmp ever compiled to ops?
yes, but it's freed in S_simplify_sort, called by ck_sort during optree
construction, i.e. before the peephole optimizer is called.
Concise shows the DESC flag on the sort op that indicates this is a reverse
sort.
sort {$b cmp $a} and the peephole optimiser
Where does the op for cmp go in this?
$ perl -MO=Concise -e '@a = sort {$b cmp $a} @b'
I see:
c <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 2 -e:1) v ->3
b <2> aassign[t2] vKS ->c
-<1> ex-list lK ->8
3 <0> pushmark s ->4
7 <@> sort lK/DESC ->8
4 <0> pushmark s ->5
6 <1> rv2av[t3] lK/1 ->7
5 <$> gv(*b) s ->6
-<1> ex-list lK ->b
8 <0> pushmark s ->9
a <1> rv2av[t1] lKRM*/1 ->b
9 <$> gv(*a) s ->a
I expected to see an ex-scmp in there. Is the cmp ever compiled to ops?
Nicholas Clark
'
