[perl #128824] [BUG] promise bug

# New Ticket Created by 刘刊 # Please include the string: [perl #128824] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128824 > liukan@candor:~/Code$ cat p1.pl6 use v6; my $p = Promise.start: { sleep 1; 42 }; $p.then: { say

[perl #128823] Perl6 note outputs an extra "True"

# New Ticket Created by Malcolm # Please include the string: [perl #128823] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128823 > I downloaded my first (the latest I assume) Rakudo today on my windows 7 64 bit PC,

Re: [perl #128818] [BUG] sprintf %f bogus rounding

Patrick R. Michaud wrote: >But that's a language >specification call that someone outside of Rakudo probably needs >to make. doc/Type/Str.pod (which I checked before reporting the bug) says it's "mostly identical to the C library sprintf function", and

Re: [perl #128818] [BUG] sprintf %f bogus rounding

On Tue, Aug 02, 2016 at 07:46:20PM +0100, Zefram wrote: > > sprintf("%f", 2e0**70) > 118059162071741000.00 > > >In particular, the true value is *not* always available, > > By "true value" I meant the value represented in floating point. My apologies, I did not catch this meaning of

Re: [perl #128817] [BUG] Num.perl doesn't round-trip numeric value

On Tue, Aug 02, 2016 at 07:32:56PM +0100, Zefram wrote: > Patrick R. Michaud via RT wrote: > >I don't know that we should expect .perl or any other operation on Num > >values to be preserving more precision than that. > > I'd expect .perl to preserve whatever precision is there. Accurately >

Re: [perl #128820] [BUG] == on Num literals produces bogus answer

Patrick R. Michaud via RT wrote: >It's not universally true that Num literals like these "work fine >in other contexts" -- the pair of literals in the example given "work" >because they differ in the fifteenth decimal digit of precision. Once again, you're mistakenly supposing my complaint to be

[perl #128805] run does not die on signals

# New Ticket Created by sla...@rezic.de # Please include the string: [perl #128805] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128805 > If an external command called by run dies with an signal, then there's no exception:

[perl #128815] Make nativecall CPPStruct accept unmapped attributes.

# New Ticket Created by Vladimir Marek # Please include the string: [perl #128815] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128815 > class A is repr{ has $x; } I don't want $x mapped to C++ object attribute, I want

Re: [perl #128818] [BUG] sprintf %f bogus rounding

Patrick R. Michaud via RT wrote: >Nums hold only 15-17 digits of precision, so sprintf("%f") >likely has this one correct. No, it does not have this correct. The value represented in the Num is exactly 2**70, and the .Int accurately reflects that. It is the sprintf that is failing to show the

Re: [perl #128820] [BUG] == on Num literals produces bogus answer

On Tue, Aug 02, 2016 at 10:55:34AM -0700, Zefram wrote: > These literals work fine in other contexts: > > > my $a = 1180591620717411303424e0 > 1.18059162071741e+21 > > my $b = 1180591620717409992704e0 > 1.18059162071741e+21 > > $a.Int > 1180591620717411303424 > > $b.Int > 1180591620717409992704 >

Re: [perl #128817] [BUG] Num.perl doesn't round-trip numeric value

Patrick R. Michaud via RT wrote: >I don't know that we should expect .perl or any other operation on Num >values to be preserving more precision than that. I'd expect .perl to preserve whatever precision is there. Accurately representing the value, in a form understandable by .EVAL, is its

Re: [perl #128818] [BUG] sprintf %f bogus rounding

On Tue, Aug 02, 2016 at 09:56:38AM -0700, Zefram wrote: > > (1180591620717411303424.0e0).Int > 1180591620717411303424 > > sprintf("%f", 1180591620717411303424.0e0) > 118059162071741000.00 > > sprintf %f is not showing the true value of this Num, which it should. > The .Int coercion is

[perl #128821] sprintf %f on -0e0 omits sign

# New Ticket Created by Zefram # Please include the string: [perl #128821] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128821 > > 0e0.perl 0e0 > (-0e0.perl) -0 > sprintf("%f", 0e0) 0.00 > sprintf("%f", -0e0) 0.00

[perl #128820] [BUG] == on Num literals produces bogus answer

# New Ticket Created by Zefram # Please include the string: [perl #128820] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128820 > > 1180591620717411303424e0 == 1180591620717409992704e0 True > 1180591620717411303424e0 ===

[perl #128819] [BUG] Num.WHICH doesn't discriminate enough

# New Ticket Created by Zefram # Please include the string: [perl #128819] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128819 > > my $a = 1180591620717411303424e0 1.18059162071741e+21 > my $b = 1180591620717409992704e0

Re: [perl #128702] Range in container coerced to Num inside array subscript

Any time someone expects something other than the defined result, it suggests a need to clarify the documentation. (Unless they just haven't RTFM.) On 7/23/16, jn...@jnthn.net via RT wrote: > On Fri Jul 22 15:34:02 2016, gfldex wrote: >> my @numbers = <4 8 15 16 23

[perl #128818] [BUG] sprintf %f bogus rounding

# New Ticket Created by Zefram # Please include the string: [perl #128818] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128818 > > (1180591620717411303424.0e0).Int 1180591620717411303424 > sprintf("%f",

[perl #128817] [BUG] Num.perl doesn't round-trip numeric value

# New Ticket Created by Zefram # Please include the string: [perl #128817] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128817 > > (1180591620717411303424.0e0).Int 1180591620717411303424 >

[perl #128811] non-associatives are somehow getting treated as list associatives

We've split the non-associative exceptions into the base class, X::Syntax::NonAssociative, with a subclass off X::Syntax::NonListAssociative. nqp's EXPR now calls a different method to fail list associativity, and rakudo provides the alternate method to get the appropriate message. nqp fix in

Re: [perl #128804] [LTA] error message talks about 2/-1 fractional chars (:35)

On Mon, Aug 01, 2016 at 12:46:52PM -0700, Aleks-Daniel Jakimenko-Aleksejev wrote: > Code: > say :35 > > Result: > ===SORRY!=== Error while compiling -e > Couldn't process entire number: 2/6 int chars, 2/-1 fractional chars > at -e:1 > --> say :35⏏ This one is quite awesome too: $