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:
$ ./perl6-m
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
# 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
> (1180591620717411303424.0e0).perl.E
# 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", 118059162071741130342
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 42>; my $range = 0..2; .say fo
# 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
1.18
# 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 === 1180
# 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
T
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 corr
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
raison
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
>
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 Nu
# 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
# 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:
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 f
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
> repr
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 "tru
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 d
# 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,
rakudo-st
# New Ticket Created by Malcolm
# Please include the string: [perl #128822]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128822 >
I downloaded my first (the latest I assume) Rakudo today on my windows 7
64 bit PC,
rakudo-st
This is because of how the REPL decides whether to output the result of
a function or not.
When something outputs stuff on stdout (like say does), it'll notice
that and suppress the return value printing.
note, however, outputs on stderr, which the REPL doesn't inspect for output.
I think this b
This turns out to be a fascinating bug, not the usual "useless use of useless
use".
We were cloning a closure twice because we were calling EXPR twice on the same
expression, namely inside the 'for' rule that looks for a C-style for loop. It
was doing this inside a because it was just conject
# 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 .r
23 matches
Mail list logo
