[perl #131696] [LTA] internal error for invalid native type in "is native"

[Zoffix Znet via RT]

Tests in 
https://github.com/rakudo/rakudo/blob/bfe2ad63f8ea17cbc11e836b7fcb1c8f35515cbd/t/04-nativecall/18-routine-sig-sanity.t#L95

[perl #132214] [LHF] `need` with version silently fails

[Zoffix Znet via RT]

On Tue, 03 Oct 2017 08:34:39 -0700, c...@zoffix.com wrote:
> If you `use` a v6.d, it causes language switch and will also complain
> if the version is too high.
> The same doesn't happen with `need`. It should probably fail in these
> cases, and `` should
> be just removed from the grammar[^1].
> 
> 15:26   m: need v6.c
> 15:26   camelia rakudo-moar f946bd: ( no output )
> 15:27   Zoffix  m: need v6.e
> 15:27   camelia rakudo-moar f946bd: ( no output )
> 15:32   Zoffix  m: need v6.d; say $*PERL.version
> 15:32   camelia rakudo-moar f946bd: OUTPUT: «v6.c␤»
> 
> [1]
> https://github.com/rakudo/rakudo/blob/f946bd35dca39af97983ec95d4da7fdd0416b73d/src/Perl6/Grammar.nqp#L1548


This appears to be fixed now:

 m: need v6.d
 rakudo-moar e7e91ecfb: OUTPUT: «===SORRY!=== Error while compiling 
␤In case of using pragma, use "use" instead (e.g., "use v6;", "use 
v6.c;").␤at :1␤--> need v6.d⏏␤»

[perl #132214] [LHF] `need` with version silently fails

[Zoffix Znet via RT]

On Tue, 03 Oct 2017 08:34:39 -0700, c...@zoffix.com wrote:
> If you `use` a v6.d, it causes language switch and will also complain
> if the version is too high.
> The same doesn't happen with `need`. It should probably fail in these
> cases, and `` should
> be just removed from the grammar[^1].
> 
> 15:26   m: need v6.c
> 15:26   camelia rakudo-moar f946bd: ( no output )
> 15:27   Zoffix  m: need v6.e
> 15:27   camelia rakudo-moar f946bd: ( no output )
> 15:32   Zoffix  m: need v6.d; say $*PERL.version
> 15:32   camelia rakudo-moar f946bd: OUTPUT: «v6.c␤»
> 
> [1]
> https://github.com/rakudo/rakudo/blob/f946bd35dca39af97983ec95d4da7fdd0416b73d/src/Perl6/Grammar.nqp#L1548


This appears to be fixed now:

 m: need v6.d
 rakudo-moar e7e91ecfb: OUTPUT: «===SORRY!=== Error while compiling 
␤In case of using pragma, use "use" instead (e.g., "use v6;", "use 
v6.c;").␤at :1␤--> need v6.d⏏␤»

[perl #127933] [REPL] int# bug

[Zoffix Znet via RT]

On Sun, 28 Aug 2016 09:40:51 -0700, barto...@gmx.de wrote:
> Just a note: This seems to be a specific problem with Moar:
> 
> $ ./perl6-j
> [...]
> > my int8 $i = 0x78;
> 120
> > my int8 $j = 0x78;
> 120
> >
> 
> I'm going to tag this ticket with [MoarVM]. Or should the ticket be
> moved to the Github repo for MoarVM?


Closing as the ticket now moved to GitHub: 
https://github.com/rakudo/rakudo/issues/2284

[perl #127933] [REPL] int# bug

[Zoffix Znet via RT]

On Sun, 28 Aug 2016 09:40:51 -0700, barto...@gmx.de wrote:
> Just a note: This seems to be a specific problem with Moar:
> 
> $ ./perl6-j
> [...]
> > my int8 $i = 0x78;
> 120
> > my int8 $j = 0x78;
> 120
> >
> 
> I'm going to tag this ticket with [MoarVM]. Or should the ticket be
> moved to the Github repo for MoarVM?


Closing as the ticket now moved to GitHub: 
https://github.com/rakudo/rakudo/issues/2284

[perl #131099] [LTA] is assoc('list') gives "MVMArray: Can't pop from an empty array"

[Zoffix Znet via RT]

> On Tue, 04 Apr 2017 11:05:05 -0700, c...@zoffix.com wrote:

> This is partially fixed now for `is equiv` with
> https://github.com/rakudo/rakudo/commit/f9f0883c6c and
> https://github.com/perl6/roast/commit/75f42755ec

FYI: with 6.d prep going on, I reverted[^1] that test for now

Don't want to spec the test's behaviour until this ticket and
behaviour in related tickets[^2] are entirely resolved/specced

[1] https://github.com/perl6/roast/commit/b9c2a956e1dbfe39603
[2] RT#132713, RT#132710, RT#132711, maybe more
https://rt.perl.org/Public/Bug/Display.html?id=132713
https://rt.perl.org/Public/Bug/Display.html?id=132710
https://rt.perl.org/Public/Bug/Display.html?id=132711

[perl #131099] [LTA] is assoc('list') gives "MVMArray: Can't pop from an empty array"

[Zoffix Znet via RT]

> On Tue, 04 Apr 2017 11:05:05 -0700, c...@zoffix.com wrote:

> This is partially fixed now for `is equiv` with
> https://github.com/rakudo/rakudo/commit/f9f0883c6c and
> https://github.com/perl6/roast/commit/75f42755ec

FYI: with 6.d prep going on, I reverted[^1] that test for now

Don't want to spec the test's behaviour until this ticket and
behaviour in related tickets[^2] are entirely resolved/specced

[1] https://github.com/perl6/roast/commit/b9c2a956e1dbfe39603
[2] RT#132713, RT#132710, RT#132711, maybe more
https://rt.perl.org/Public/Bug/Display.html?id=132713
https://rt.perl.org/Public/Bug/Display.html?id=132710
https://rt.perl.org/Public/Bug/Display.html?id=132711

[perl #133082] [LTA] precedence error !%foo:exists

[Zoffix Znet via RT]

Another user opened the same ticket on our primary tracker, so I'll close this 
one in favour of that one:https://github.com/rakudo/rakudo/issues/2098

[perl #132980] Coercion type apparently does not check the actual type of the coerced value

[Zoffix Znet via RT]

Re-opening this, as there's a much more common case where a typecheck of the 
coercion result would be desired and that's when coercion results in a Failure:

 m: multi sub foo(Int() $) { }; foo Inf
 rakudo-moar 5a6ff4073: ( no output )

[perl #132980] Coercion type apparently does not check the actual type of the coerced value

[Zoffix Znet via RT]

Re-opening this, as there's a much more common case where a typecheck of the 
coercion result would be desired and that's when coercion results in a Failure:

 m: multi sub foo(Int() $) { }; foo Inf
 rakudo-moar 5a6ff4073: ( no output )

[perl #133246] Possible bug in Perl 6 OO

[Zoffix Znet via RT]

On Sat, 09 Jun 2018 05:33:04 -0700, c...@zoffix.com wrote:
> when
> using implicit return:
> 
> 
> method var1() is rw { return$!var }
> method var2()   { return-rw $!var }

Correction, that should be:

method var1() is rw {   $!var }
method var2()   { return-rw $!var }

[perl #133246] Possible bug in Perl 6 OO

[Zoffix Znet via RT]

On Sat, 09 Jun 2018 05:33:04 -0700, c...@zoffix.com wrote:
> when
> using implicit return:
> 
> 
> method var1() is rw { return$!var }
> method var2()   { return-rw $!var }

Correction, that should be:

method var1() is rw {   $!var }
method var2()   { return-rw $!var }

[perl #133246] Possible bug in Perl 6 OO

[Zoffix Znet via RT]

On Mon, 04 Jun 2018 07:31:40 -0700, richard.hogab...@gmail.com wrote:
> Attached is an executable file that demos a possible Perl 6 OO bug if 
> attributes and method names are the same.  This includes some compile 
> time errors and an infinite loop.
> 

Thanks for the report, but there's no bug here.

The `has $.foo` attribute syntax is just a shorthand for writing `has $!foo; 
method foo { $!foo }`.
In other words, the compiler auto-generated an accessor method for you.

When you use `$.foo` syntax inside a method, it's a shorthand for `self.foo`; 
in other words, it's a
method call.

If you define a method with the same name as the attribute, then it signals to 
the compiler that you chose
to take care of accessor method yourself.

Also, to return a writeable container, you need to either use `return-rw` 
instead of plain `return` when
using explicit return, or apply the `is rw` trait to the method, when using 
implicit return:


method var1() is rw { return$!var }
method var2()   { return-rw $!var }

With that knowledge, you can see why the failing examples fail:

* EXAMPLE 3: You defined a method with the same name as attribute, so it'll 
function as the accessor. The body
 of that method is empty, so it returns `Nil` and hence the error 
about trying to assign to `Nil`
* EXAMPLE 4: Again, you defined your own accessor, but now you're also using 
`$.var` syntax inside, so the method
 infiniloops calling itself over and over. Hence the hang.
* EXAMPLE 5: You've used `return` instead of `return-rw`, so only a readonly 
value is returned instead of a
 writable container. Hence the error

> but shouldn't there be some type of prohibition/warning?

No, as it's perfectly fine to declare your own accessors. Of course, writing 
`has $.foo` instead of `has $!foo` is
pointless, in that case, but it serves as a hint to the programmer that it's a 
public attribute, so I don't think
warning about that is appropriate.

[perl #133246] Possible bug in Perl 6 OO

[Zoffix Znet via RT]

On Mon, 04 Jun 2018 07:31:40 -0700, richard.hogab...@gmail.com wrote:
> Attached is an executable file that demos a possible Perl 6 OO bug if 
> attributes and method names are the same.  This includes some compile 
> time errors and an infinite loop.
> 

Thanks for the report, but there's no bug here.

The `has $.foo` attribute syntax is just a shorthand for writing `has $!foo; 
method foo { $!foo }`.
In other words, the compiler auto-generated an accessor method for you.

When you use `$.foo` syntax inside a method, it's a shorthand for `self.foo`; 
in other words, it's a
method call.

If you define a method with the same name as the attribute, then it signals to 
the compiler that you chose
to take care of accessor method yourself.

Also, to return a writeable container, you need to either use `return-rw` 
instead of plain `return` when
using explicit return, or apply the `is rw` trait to the method, when using 
implicit return:


method var1() is rw { return$!var }
method var2()   { return-rw $!var }

With that knowledge, you can see why the failing examples fail:

* EXAMPLE 3: You defined a method with the same name as attribute, so it'll 
function as the accessor. The body
 of that method is empty, so it returns `Nil` and hence the error 
about trying to assign to `Nil`
* EXAMPLE 4: Again, you defined your own accessor, but now you're also using 
`$.var` syntax inside, so the method
 infiniloops calling itself over and over. Hence the hang.
* EXAMPLE 5: You've used `return` instead of `return-rw`, so only a readonly 
value is returned instead of a
 writable container. Hence the error

> but shouldn't there be some type of prohibition/warning?

No, as it's perfectly fine to declare your own accessors. Of course, writing 
`has $.foo` instead of `has $!foo` is
pointless, in that case, but it serves as a hint to the programmer that it's a 
public attribute, so I don't think
warning about that is appropriate.

[perl #133268] MoarVM with empty CONTROL {}

[Zoffix Znet via RT]

On Fri, 08 Jun 2018 15:24:32 -0700, alex.jakime...@gmail.com wrote:
> Golf:
> 
> CONTROL {}; warn 42
> 
> On 2018-06-08 15:11:08, comdog wrote:
> > While running this program I get a MoarVM panic:
> >
> > 2 + 2 = 4
> > 'two' is not numeric
> > MoarVM panic: Trying to unwind over wrong handler
> >
> > The program:
> >
> > sub add-two-things ( $first, $second ) {
> > CATCH {
> > when X::Str::Numeric {
> > fail q/One of the arguments wasn't a number/
> > }
> > }
> >
> > for $first, $second {
> > warn "'$_' is not numeric" unless val($_) ~~ Numeric;
> > }
> >
> > return $first + $second;
> > }
> >
> > my @items = < 2 2 3 two nine ten 1 37 0 0 >;
> >
> > for @items -> $first, $second {
> > CONTROL {}
> > my $sum = add-two-things( $first, $second );
> >
> > put $sum.defined ??
> > "$first + $second = $sum" !!
> > "You can't add $first and $second";
> > }
> >


This is a dupe of https://github.com/MoarVM/MoarVM/issues/572 (also filed in 
Rakudo's repo: https://github.com/rakudo/rakudo/issues/1605 )

Closing this ticket in favour of those Issues.

[perl #133268] MoarVM with empty CONTROL {}

[Zoffix Znet via RT]

On Fri, 08 Jun 2018 15:24:32 -0700, alex.jakime...@gmail.com wrote:
> Golf:
> 
> CONTROL {}; warn 42
> 
> On 2018-06-08 15:11:08, comdog wrote:
> > While running this program I get a MoarVM panic:
> >
> > 2 + 2 = 4
> > 'two' is not numeric
> > MoarVM panic: Trying to unwind over wrong handler
> >
> > The program:
> >
> > sub add-two-things ( $first, $second ) {
> > CATCH {
> > when X::Str::Numeric {
> > fail q/One of the arguments wasn't a number/
> > }
> > }
> >
> > for $first, $second {
> > warn "'$_' is not numeric" unless val($_) ~~ Numeric;
> > }
> >
> > return $first + $second;
> > }
> >
> > my @items = < 2 2 3 two nine ten 1 37 0 0 >;
> >
> > for @items -> $first, $second {
> > CONTROL {}
> > my $sum = add-two-things( $first, $second );
> >
> > put $sum.defined ??
> > "$first + $second = $sum" !!
> > "You can't add $first and $second";
> > }
> >


This is a dupe of https://github.com/MoarVM/MoarVM/issues/572 (also filed in 
Rakudo's repo: https://github.com/rakudo/rakudo/issues/1605 )

Closing this ticket in favour of those Issues.

[perl #130774] [BUG] Rational.REDUCE-ME has a data race

[Zoffix Znet via RT]

Data race is now fixed (in a post release branch):

Rakudo fix: 
https://github.com/rakudo/rakudo/commit/6dd20588b6dfb75a121e2207df5f8c89aad3e1ef
Test: https://github.com/perl6/roast/commit/1d10e9dc12

[perl #130774] [BUG] Rational.REDUCE-ME has a data race

[Zoffix Znet via RT]

Data race is now fixed (in a post release branch):

Rakudo fix: 
https://github.com/rakudo/rakudo/commit/6dd20588b6dfb75a121e2207df5f8c89aad3e1ef
Test: https://github.com/perl6/roast/commit/1d10e9dc12

[perl #124815] Roast rakudo skip/todo test:./S32-num/fatrat.t line:191 reason: 'unknown'

[Zoffix Znet via RT]

Test was incorrect.

Fixed in https://github.com/perl6/roast/commit/771a2bbeb1

[perl #124815] Roast rakudo skip/todo test:./S32-num/fatrat.t line:191 reason: 'unknown'

[Zoffix Znet via RT]

Test was incorrect.

Fixed in https://github.com/perl6/roast/commit/771a2bbeb1

[perl #124814] Roast rakudo skip/todo test:./S32-num/fatrat.t line:181 reason: 'FatRat arith + type objects'

[Zoffix Znet via RT]

Re-filed with more details on the issue in 
https://github.com/rakudo/rakudo/issues/1830

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

[Zoffix Znet via RT]

On Tue, 02 Aug 2016 09:51:31 -0700, zef...@fysh.org wrote:
> > (1180591620717411303424.0e0).Int
> 1180591620717411303424
> > (1180591620717411303424.0e0).perl.EVAL.Int
> 1180591620717409992704
> 
> The .perl.EVAL process ought to yield the same value we started with.
> It's coming back as a different Num value.
> 
> -zefram


Thank you for the report. This is now fixed.

Fix:  https://github.com/MoarVM/MoarVM/commit/067c0594103a025
  https://github.com/MoarVM/MoarVM/commit/8841c4241b4faa8
  https://github.com/MoarVM/MoarVM/commit/af2eb8a7f7d4344
  https://github.com/MoarVM/MoarVM/commit/4d3fc2818d0032b
  https://github.com/rakudo/rakudo/commit/8422d7b4e23678b
  https://github.com/rakudo/rakudo/commit/a2a2a745c4242d1
  https://github.com/rakudo/rakudo/commit/430266629f2e2a0
Test: https://github.com/perl6/roast/commit/dcdbcb31b43a0f6ec

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

[Zoffix Znet via RT]

On Tue, 02 Aug 2016 09:51:31 -0700, zef...@fysh.org wrote:
> > (1180591620717411303424.0e0).Int
> 1180591620717411303424
> > (1180591620717411303424.0e0).perl.EVAL.Int
> 1180591620717409992704
> 
> The .perl.EVAL process ought to yield the same value we started with.
> It's coming back as a different Num value.
> 
> -zefram


Thank you for the report. This is now fixed.

Fix:  https://github.com/MoarVM/MoarVM/commit/067c0594103a025
  https://github.com/MoarVM/MoarVM/commit/8841c4241b4faa8
  https://github.com/MoarVM/MoarVM/commit/af2eb8a7f7d4344
  https://github.com/MoarVM/MoarVM/commit/4d3fc2818d0032b
  https://github.com/rakudo/rakudo/commit/8422d7b4e23678b
  https://github.com/rakudo/rakudo/commit/a2a2a745c4242d1
  https://github.com/rakudo/rakudo/commit/430266629f2e2a0
Test: https://github.com/perl6/roast/commit/dcdbcb31b43a0f6ec

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

[Zoffix Znet via RT]

On Tue, 02 Aug 2016 10:44:50 -0700, zef...@fysh.org wrote:
> > my $a = 1180591620717411303424e0
> 1.18059162071741e+21
> > my $b = 1180591620717409992704e0
> 1.18059162071741e+21
> > $a.Int
> 1180591620717411303424
> > $b.Int
> 1180591620717409992704
> > $a == $b
> False
> > $a === $b
> False
> > $a.WHICH
> Num|1.18059162071741e+21
> > $b.WHICH
> Num|1.18059162071741e+21
> > $a.WHICH eq $b.WHICH
> True
> 
> These are distinct Num values, as seen by .Int, ==, and ===.  But .WHICH
> is erroneously saying that they're the same.  .WHICH should show distinct
> identities for these distinct values.
> 
> -zefram


Thank you for the report. This is now fixed.

Fix:  https://github.com/MoarVM/MoarVM/commit/067c0594103a025
  https://github.com/MoarVM/MoarVM/commit/8841c4241b4faa8
  https://github.com/MoarVM/MoarVM/commit/af2eb8a7f7d4344
  https://github.com/MoarVM/MoarVM/commit/4d3fc2818d0032b
  https://github.com/rakudo/rakudo/commit/8422d7b4e23678b
  https://github.com/rakudo/rakudo/commit/a2a2a745c4242d1
Test: https://github.com/perl6/roast/commit/3f0174e45563d641e

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

[Zoffix Znet via RT]

On Tue, 02 Aug 2016 10:44:50 -0700, zef...@fysh.org wrote:
> > my $a = 1180591620717411303424e0
> 1.18059162071741e+21
> > my $b = 1180591620717409992704e0
> 1.18059162071741e+21
> > $a.Int
> 1180591620717411303424
> > $b.Int
> 1180591620717409992704
> > $a == $b
> False
> > $a === $b
> False
> > $a.WHICH
> Num|1.18059162071741e+21
> > $b.WHICH
> Num|1.18059162071741e+21
> > $a.WHICH eq $b.WHICH
> True
> 
> These are distinct Num values, as seen by .Int, ==, and ===.  But .WHICH
> is erroneously saying that they're the same.  .WHICH should show distinct
> identities for these distinct values.
> 
> -zefram


Thank you for the report. This is now fixed.

Fix:  https://github.com/MoarVM/MoarVM/commit/067c0594103a025
  https://github.com/MoarVM/MoarVM/commit/8841c4241b4faa8
  https://github.com/MoarVM/MoarVM/commit/af2eb8a7f7d4344
  https://github.com/MoarVM/MoarVM/commit/4d3fc2818d0032b
  https://github.com/rakudo/rakudo/commit/8422d7b4e23678b
  https://github.com/rakudo/rakudo/commit/a2a2a745c4242d1
Test: https://github.com/perl6/roast/commit/3f0174e45563d641e

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

[Zoffix Znet via RT]

On Tue, 02 Aug 2016 10:55:34 -0700, zef...@fysh.org wrote:
> > 1180591620717411303424e0 == 1180591620717409992704e0
> True
> > 1180591620717411303424e0 === 1180591620717409992704e0
> True
> 
> Say what?  These are distinct Num values, differing by 10 ulp.
> 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
> > $a == $b
> False
> > $a === $b
> False
> 
> == and === give the right result when applied to $a and $b as here, or
> when applied to declared constants ("constant \A = 118...").  They also
> work fine when comparing a variable against a literal.  They go wrong when
> applied directly to two literal expressions.  They also go wrong with some
> more complex expressions that bring in both values as literals, such as if
> both sides are multiplied by 1.0e0 or by a variable containing that value.
> 
> -zefram

Thank you for the report. This is now fixed.

Fix:  https://github.com/MoarVM/MoarVM/commit/067c0594103a025
  https://github.com/MoarVM/MoarVM/commit/8841c4241b4faa8
  https://github.com/MoarVM/MoarVM/commit/af2eb8a7f7d4344
  https://github.com/MoarVM/MoarVM/commit/4d3fc2818d0032b
  https://github.com/rakudo/rakudo/commit/8422d7b4e23678b
  https://github.com/rakudo/rakudo/commit/a2a2a745c4242d1
Test: https://github.com/perl6/roast/commit/52c60ce5c283dd5b8
  https://github.com/perl6/roast/commit/bba5e9fdda431c9f4

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

[Zoffix Znet via RT]

On Tue, 02 Aug 2016 10:55:34 -0700, zef...@fysh.org wrote:
> > 1180591620717411303424e0 == 1180591620717409992704e0
> True
> > 1180591620717411303424e0 === 1180591620717409992704e0
> True
> 
> Say what?  These are distinct Num values, differing by 10 ulp.
> 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
> > $a == $b
> False
> > $a === $b
> False
> 
> == and === give the right result when applied to $a and $b as here, or
> when applied to declared constants ("constant \A = 118...").  They also
> work fine when comparing a variable against a literal.  They go wrong when
> applied directly to two literal expressions.  They also go wrong with some
> more complex expressions that bring in both values as literals, such as if
> both sides are multiplied by 1.0e0 or by a variable containing that value.
> 
> -zefram

Thank you for the report. This is now fixed.

Fix:  https://github.com/MoarVM/MoarVM/commit/067c0594103a025
  https://github.com/MoarVM/MoarVM/commit/8841c4241b4faa8
  https://github.com/MoarVM/MoarVM/commit/af2eb8a7f7d4344
  https://github.com/MoarVM/MoarVM/commit/4d3fc2818d0032b
  https://github.com/rakudo/rakudo/commit/8422d7b4e23678b
  https://github.com/rakudo/rakudo/commit/a2a2a745c4242d1
Test: https://github.com/perl6/roast/commit/52c60ce5c283dd5b8
  https://github.com/perl6/roast/commit/bba5e9fdda431c9f4

[perl #128914] [BUG] decimal->float conversion differs for literals and Str.Num

[Zoffix Znet via RT]

On Fri, 12 Aug 2016 10:24:48 -0700, zef...@fysh.org wrote:
> > "9.998e0".EVAL - "9.998e0".Num
> 1.77635683940025e-15
> 
> Observe that the same string yields different Num values when interpreted
> as a Num literal and when coerced.  Where the string is meaningful both
> ways, this is a bug.  Obviously there are some situations where the
> syntax of Perl 6 literals doesn't exactly match what one would expect of
> a Str.Num conversion, but that's not the case here.  Where the syntax
> matches, as it does in this case, or more generally where the same
> digits are presented with the same weights, one would expect the core
> decimal->float conversion to behave the same for both.
> 
> The conversions yielding different values implies that at least one
> of them is individually incorrect.  In this case, the coercion yields
> the correctly-rounded value, and the literal is getting it wrong.
> [perl #128912] is concerned with these conversions being incorrect per se,
> and my test case there used the conversion for literals.  The difference
> between the two forms of decimal->float conversion is not merely a matter
> of literals getting it wrong and coercion getting it right: there are also
> cases where the coercion gets it wrong.  In fact, coercion gets it wrong
> in the [perl #128912] test case: both literal interpretation and coercion
> get "9.999e-5" wrong in the same way.  I have not yet encountered a case
> where literal interpretation gets it right and coercion gets it wrong,
> but nor can I say that there isn't such a case.
> 
> -zefram


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/a760ac3cfc6426d9bd2fb00db
  https://github.com/MoarVM/MoarVM/commit/b735866ddee9bd719440e5c82
Test: https://github.com/perl6/roast/commit/4da5909f926e7eb42

[perl #128914] [BUG] decimal->float conversion differs for literals and Str.Num

[Zoffix Znet via RT]

On Fri, 12 Aug 2016 10:24:48 -0700, zef...@fysh.org wrote:
> > "9.998e0".EVAL - "9.998e0".Num
> 1.77635683940025e-15
> 
> Observe that the same string yields different Num values when interpreted
> as a Num literal and when coerced.  Where the string is meaningful both
> ways, this is a bug.  Obviously there are some situations where the
> syntax of Perl 6 literals doesn't exactly match what one would expect of
> a Str.Num conversion, but that's not the case here.  Where the syntax
> matches, as it does in this case, or more generally where the same
> digits are presented with the same weights, one would expect the core
> decimal->float conversion to behave the same for both.
> 
> The conversions yielding different values implies that at least one
> of them is individually incorrect.  In this case, the coercion yields
> the correctly-rounded value, and the literal is getting it wrong.
> [perl #128912] is concerned with these conversions being incorrect per se,
> and my test case there used the conversion for literals.  The difference
> between the two forms of decimal->float conversion is not merely a matter
> of literals getting it wrong and coercion getting it right: there are also
> cases where the coercion gets it wrong.  In fact, coercion gets it wrong
> in the [perl #128912] test case: both literal interpretation and coercion
> get "9.999e-5" wrong in the same way.  I have not yet encountered a case
> where literal interpretation gets it right and coercion gets it wrong,
> but nor can I say that there isn't such a case.
> 
> -zefram


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/a760ac3cfc6426d9bd2fb00db
  https://github.com/MoarVM/MoarVM/commit/b735866ddee9bd719440e5c82
Test: https://github.com/perl6/roast/commit/4da5909f926e7eb42

[perl #133107] LTA: require of non installed module

[Zoffix Znet via RT]

On Thu, 12 Apr 2018 23:34:43 -0700, mar...@senfdax.de wrote:
> requireing a non installed module leads to strange error if the name 
> starts with the name of a core module. e.g:
> 
> 
>  > perl6 -e 'require IO::Socket::Async::SSL'
> IO::Socket::Async::SSL is a builtin type, not an external module
>    in block  at -e line 1


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/4b2512a22236e09
Test: https://github.com/rakudo/rakudo/commit/4b2512a22236e09

[perl #133107] LTA: require of non installed module

[Zoffix Znet via RT]

On Thu, 12 Apr 2018 23:34:43 -0700, mar...@senfdax.de wrote:
> requireing a non installed module leads to strange error if the name 
> starts with the name of a core module. e.g:
> 
> 
>  > perl6 -e 'require IO::Socket::Async::SSL'
> IO::Socket::Async::SSL is a builtin type, not an external module
>    in block  at -e line 1


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/4b2512a22236e09
Test: https://github.com/rakudo/rakudo/commit/4b2512a22236e09

[perl #132329] [MATH] Rat → Num conversion isn’t monotonous

[Zoffix Znet via RT]

On Fri, 20 Oct 2017 07:34:04 -0700, victor.a...@derpymail.org wrote:
> How to reproduce
> 
> 
> perl6 -e 'my ($a, $b) = (0.7,
> 0.71); say $a <=> $b, " ", Num($a) <=> Num($b)'
> 
> Expected behavior
> -
> 
> Prints `Less Less`, or `Less Same`, depending on how rounding is done.
> 
> Actual behavior
> ---
> 
> Prints `Less More`. This seems inconsistent: $a is strictly smaller
> than $b, yet Num($a) is strictly larger than Num($b).
> 
> Version information
> ---
> 
> This is Rakudo version 2017.09 built on MoarVM version 2017.09.1
> implementing Perl 6.c.
> 
> This may be related to https://rt.perl.org/Public/Bug/Display.html?id=132313


Thank you for the report. This is now fixed (specifically, the Num version now 
gives "Same" as
there's not enough precision available to represent those Rats as different 
numbers)

Fix:  https://github.com/rakudo/rakudo/commit/a760ac3cfc6426d9bd2fb00db
  https://github.com/MoarVM/MoarVM/commit/b735866ddee9bd719440e5c82
Test: https://github.com/perl6/roast/commit/db0c58b5f763b085e


On Fri, 20 Oct 2017 17:44:40 -0700, c...@zoffix.com wrote:
> This appears to be not a bug but simply the goodness of floating point
> math. I get the same result in C:

You're wrong, 2017-Zoffix. The result you got in C is because you incorrectly 
used doubles to do the division.

[perl #132329] [MATH] Rat → Num conversion isn’t monotonous

[Zoffix Znet via RT]

On Fri, 20 Oct 2017 07:34:04 -0700, victor.a...@derpymail.org wrote:
> How to reproduce
> 
> 
> perl6 -e 'my ($a, $b) = (0.7,
> 0.71); say $a <=> $b, " ", Num($a) <=> Num($b)'
> 
> Expected behavior
> -
> 
> Prints `Less Less`, or `Less Same`, depending on how rounding is done.
> 
> Actual behavior
> ---
> 
> Prints `Less More`. This seems inconsistent: $a is strictly smaller
> than $b, yet Num($a) is strictly larger than Num($b).
> 
> Version information
> ---
> 
> This is Rakudo version 2017.09 built on MoarVM version 2017.09.1
> implementing Perl 6.c.
> 
> This may be related to https://rt.perl.org/Public/Bug/Display.html?id=132313


Thank you for the report. This is now fixed (specifically, the Num version now 
gives "Same" as
there's not enough precision available to represent those Rats as different 
numbers)

Fix:  https://github.com/rakudo/rakudo/commit/a760ac3cfc6426d9bd2fb00db
  https://github.com/MoarVM/MoarVM/commit/b735866ddee9bd719440e5c82
Test: https://github.com/perl6/roast/commit/db0c58b5f763b085e


On Fri, 20 Oct 2017 17:44:40 -0700, c...@zoffix.com wrote:
> This appears to be not a bug but simply the goodness of floating point
> math. I get the same result in C:

You're wrong, 2017-Zoffix. The result you got in C is because you incorrectly 
used doubles to do the division.

[perl #128913] [BUG] decimal->float non-monotonic conversion

[Zoffix Znet via RT]

On Fri, 12 Aug 2016 10:00:17 -0700, zef...@fysh.org wrote:
> > "9.9981e0".EVAL < "9.998e0".EVAL
> True
> 
> Observe that the literal with a greater nominal value yields a lower
> Num value.  (The .EVAL circumlocution is required to work around [perl
> #128820].)  This implies that at least one of the literals is getting
> incorrect rounding, which was the subject of [perl #128912].  (In fact
> the greater one is getting correct rounding and the lower one is not.
> The correct roundings of both are the same.)  But this case goes beyond
> the rounding merely being incorrect; with this behaviour the rounding
> isn't even self-consistent.
> 
> -zefram

Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/a760ac3cfc6426d9bd2fb00db
  https://github.com/MoarVM/MoarVM/commit/b735866ddee9bd719440e5c82
Test: https://github.com/perl6/roast/commit/07830c2042b998128

[perl #128913] [BUG] decimal->float non-monotonic conversion

[Zoffix Znet via RT]

On Fri, 12 Aug 2016 10:00:17 -0700, zef...@fysh.org wrote:
> > "9.9981e0".EVAL < "9.998e0".EVAL
> True
> 
> Observe that the literal with a greater nominal value yields a lower
> Num value.  (The .EVAL circumlocution is required to work around [perl
> #128820].)  This implies that at least one of the literals is getting
> incorrect rounding, which was the subject of [perl #128912].  (In fact
> the greater one is getting correct rounding and the lower one is not.
> The correct roundings of both are the same.)  But this case goes beyond
> the rounding merely being incorrect; with this behaviour the rounding
> isn't even self-consistent.
> 
> -zefram

Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/a760ac3cfc6426d9bd2fb00db
  https://github.com/MoarVM/MoarVM/commit/b735866ddee9bd719440e5c82
Test: https://github.com/perl6/roast/commit/07830c2042b998128

[perl #128624] Buf initialization error

[Zoffix Znet via RT]

On Sat, 15 Jul 2017 09:49:10 -0700, jan-olof.hen...@bredband.net wrote:
> On Fri, 15 Jul 2016 02:45:51 -0700, mt1...@gmail.com wrote:
> > Hi,
> >
> > Old code gives now error in Rakudo version 2016.06-234-g0189851 built
> > on
> > MoarVM version 2016.06-9-g8fc21d5.
> >
> > Code is
> >
> > sub encode-int32 ( Int:D $i --> Buf ) is export {
> >   my int $ni = $i;
> >   return Buf.new( $ni +& 0xFF, ($ni +> 0x08) +& 0xFF,
> >   ($ni +> 0x10) +& 0xFF, ($ni +> 0x18) +& 0xFF
> > );
> > }
> >
> > Fails at ' return Buf.new( $ni +& 0xFF, ' when argument $i=5 with
> > error
> >
> >
> > Type check failed in initializing element #0 to Buf; expected uint8
> > but
> > got Int (5)
> >   in any  at gen/moar/m-Metamodel.nqp line 1736
> >in sub encode-int32 at
> > /home/marcel/Languages/Perl6/Projects/BSON/lib/BSON/Document.pm6
> > (BSON::Document) line 948
> >in method encode at
> > /home/marcel/Languages/Perl6/Projects/BSON/lib/BSON/Document.pm6
> > (BSON::Document) line 696
> >   in block  at t/300-document.t line 10
> >
> > Actually thrown at:
> >in any  at gen/moar/m-Metamodel.nqp line 3055
> >in any  at gen/moar/m-Metamodel.nqp line 1736
> > in sub encode-int32 at
> >  /home/marcel/Languages/Perl6/Projects/BSON/lib/BSON/Document.pm6
> > (BSON::Document) line 948
> > in method encode at
> >  /home/marcel/Languages/Perl6/Projects/BSON/lib/BSON/Document.pm6
> > (BSON::Document) line 696
> >in block  at t/300-document.t line 10
> >
> >
> > In REPL golfed down to
> >
> >  > my int $i = 5
> >  > Buf.new($i +& 0xFF)
> > Type check failed in initializing element #0 to Buf; expected uint8
> > but
> > got Int (5)
> >   in any  at gen/moar/m-Metamodel.nqp line 1736
> >   in block  at  line 1
> >
> >
> > Neither $i or 0xFF on its own will trigger this error so its the
> > combination caused by the +& operator. Also 'Buf.new(|($i +& 0xFF))'
> > helps but is rather cumbersome for the programmer as well as the
> > compiler!
> >
> > greetings,
> >
> > Marcel
> >
> 
> The above works since
> https://github.com/rakudo/rakudo/commit/242baf256a210f1cb643cb6324916dbc76184c9f.
> Note however that the fix is marked as 'temporary', i.e. a workaround.



Fixed without a workaround in 
https://github.com/rakudo/rakudo/commit/29fdb75a3032bd922485d785e9faaec78fc37bb5#diff-260d1fea0c20b1e4f46564df2777fb11
Tests in 
https://github.com/perl6/roast/commit/32ac651062f3ba06f56aed0d8493b36f07f0dc76

[perl #128624] Buf initialization error

[Zoffix Znet via RT]

On Sat, 15 Jul 2017 09:49:10 -0700, jan-olof.hen...@bredband.net wrote:
> On Fri, 15 Jul 2016 02:45:51 -0700, mt1...@gmail.com wrote:
> > Hi,
> >
> > Old code gives now error in Rakudo version 2016.06-234-g0189851 built
> > on
> > MoarVM version 2016.06-9-g8fc21d5.
> >
> > Code is
> >
> > sub encode-int32 ( Int:D $i --> Buf ) is export {
> >   my int $ni = $i;
> >   return Buf.new( $ni +& 0xFF, ($ni +> 0x08) +& 0xFF,
> >   ($ni +> 0x10) +& 0xFF, ($ni +> 0x18) +& 0xFF
> > );
> > }
> >
> > Fails at ' return Buf.new( $ni +& 0xFF, ' when argument $i=5 with
> > error
> >
> >
> > Type check failed in initializing element #0 to Buf; expected uint8
> > but
> > got Int (5)
> >   in any  at gen/moar/m-Metamodel.nqp line 1736
> >in sub encode-int32 at
> > /home/marcel/Languages/Perl6/Projects/BSON/lib/BSON/Document.pm6
> > (BSON::Document) line 948
> >in method encode at
> > /home/marcel/Languages/Perl6/Projects/BSON/lib/BSON/Document.pm6
> > (BSON::Document) line 696
> >   in block  at t/300-document.t line 10
> >
> > Actually thrown at:
> >in any  at gen/moar/m-Metamodel.nqp line 3055
> >in any  at gen/moar/m-Metamodel.nqp line 1736
> > in sub encode-int32 at
> >  /home/marcel/Languages/Perl6/Projects/BSON/lib/BSON/Document.pm6
> > (BSON::Document) line 948
> > in method encode at
> >  /home/marcel/Languages/Perl6/Projects/BSON/lib/BSON/Document.pm6
> > (BSON::Document) line 696
> >in block  at t/300-document.t line 10
> >
> >
> > In REPL golfed down to
> >
> >  > my int $i = 5
> >  > Buf.new($i +& 0xFF)
> > Type check failed in initializing element #0 to Buf; expected uint8
> > but
> > got Int (5)
> >   in any  at gen/moar/m-Metamodel.nqp line 1736
> >   in block  at  line 1
> >
> >
> > Neither $i or 0xFF on its own will trigger this error so its the
> > combination caused by the +& operator. Also 'Buf.new(|($i +& 0xFF))'
> > helps but is rather cumbersome for the programmer as well as the
> > compiler!
> >
> > greetings,
> >
> > Marcel
> >
> 
> The above works since
> https://github.com/rakudo/rakudo/commit/242baf256a210f1cb643cb6324916dbc76184c9f.
> Note however that the fix is marked as 'temporary', i.e. a workaround.



Fixed without a workaround in 
https://github.com/rakudo/rakudo/commit/29fdb75a3032bd922485d785e9faaec78fc37bb5#diff-260d1fea0c20b1e4f46564df2777fb11
Tests in 
https://github.com/perl6/roast/commit/32ac651062f3ba06f56aed0d8493b36f07f0dc76

[perl #128914] [BUG] decimal->float conversion differs for literals and Str.Num

[Zoffix Znet via RT]

On Fri, 12 Aug 2016 10:24:48 -0700, zef...@fysh.org wrote:
> > "9.998e0".EVAL - "9.998e0".Num
> 1.77635683940025e-15
> 
> Observe that the same string yields different Num values when interpreted
> as a Num literal and when coerced.  Where the string is meaningful both
> ways, this is a bug.  Obviously there are some situations where the
> syntax of Perl 6 literals doesn't exactly match what one would expect of
> a Str.Num conversion, but that's not the case here.  Where the syntax
> matches, as it does in this case, or more generally where the same
> digits are presented with the same weights, one would expect the core
> decimal->float conversion to behave the same for both.
> 
> The conversions yielding different values implies that at least one
> of them is individually incorrect.  In this case, the coercion yields
> the correctly-rounded value, and the literal is getting it wrong.
> [perl #128912] is concerned with these conversions being incorrect per se,
> and my test case there used the conversion for literals.  The difference
> between the two forms of decimal->float conversion is not merely a matter
> of literals getting it wrong and coercion getting it right: there are also
> cases where the coercion gets it wrong.  In fact, coercion gets it wrong
> in the [perl #128912] test case: both literal interpretation and coercion
> get "9.999e-5" wrong in the same way.  I have not yet encountered a case
> where literal interpretation gets it right and coercion gets it wrong,
> but nor can I say that there isn't such a case.
> 
> -zefram

While OP's code snippet now shows there's no difference any more, it
appears that the reason is because both literal and coercion give wrong values 
now:

 m: dd [ "9.998e0".EVAL, "9.998e0".Num]
 rakudo-moar f48636011: OUTPUT: «[9.999e0, 9.999e0]␤»

A quick print out with C shows both values should be:

 m: say 9.99899988
 rakudo-moar f48636011: OUTPUT: «9.99899988␤»

And looks like our new approach of using nqp::div_In for coercion, literal 
parsing,
and Rat->Num degradation might be flawed (or there's a bug in that op), as this:

 m: dd 9.9981e0 == 9.998e0
 rakudo-moar f48636011: OUTPUT: «Bool::False␤»

after parsing eventually essentially becomes this:

 r: use nqp; dd nqp::div_In(99981, 
100_000_000_000_000_000) == nqp::div_In(9998, 
10_000_000_000_000_000)
 rakudo-jvm a92950fb4, rakudo-moar f48636011: OUTPUT: 
«Bool::False␤»

And it gives False, but in C, those two numbers are equal:

$ ccc 'printf("%d\n", 9.9981e0 == 9.998e0)'
1

[perl #128914] [BUG] decimal->float conversion differs for literals and Str.Num

[Zoffix Znet via RT]

On Fri, 12 Aug 2016 10:24:48 -0700, zef...@fysh.org wrote:
> > "9.998e0".EVAL - "9.998e0".Num
> 1.77635683940025e-15
> 
> Observe that the same string yields different Num values when interpreted
> as a Num literal and when coerced.  Where the string is meaningful both
> ways, this is a bug.  Obviously there are some situations where the
> syntax of Perl 6 literals doesn't exactly match what one would expect of
> a Str.Num conversion, but that's not the case here.  Where the syntax
> matches, as it does in this case, or more generally where the same
> digits are presented with the same weights, one would expect the core
> decimal->float conversion to behave the same for both.
> 
> The conversions yielding different values implies that at least one
> of them is individually incorrect.  In this case, the coercion yields
> the correctly-rounded value, and the literal is getting it wrong.
> [perl #128912] is concerned with these conversions being incorrect per se,
> and my test case there used the conversion for literals.  The difference
> between the two forms of decimal->float conversion is not merely a matter
> of literals getting it wrong and coercion getting it right: there are also
> cases where the coercion gets it wrong.  In fact, coercion gets it wrong
> in the [perl #128912] test case: both literal interpretation and coercion
> get "9.999e-5" wrong in the same way.  I have not yet encountered a case
> where literal interpretation gets it right and coercion gets it wrong,
> but nor can I say that there isn't such a case.
> 
> -zefram

While OP's code snippet now shows there's no difference any more, it
appears that the reason is because both literal and coercion give wrong values 
now:

 m: dd [ "9.998e0".EVAL, "9.998e0".Num]
 rakudo-moar f48636011: OUTPUT: «[9.999e0, 9.999e0]␤»

A quick print out with C shows both values should be:

 m: say 9.99899988
 rakudo-moar f48636011: OUTPUT: «9.99899988␤»

And looks like our new approach of using nqp::div_In for coercion, literal 
parsing,
and Rat->Num degradation might be flawed (or there's a bug in that op), as this:

 m: dd 9.9981e0 == 9.998e0
 rakudo-moar f48636011: OUTPUT: «Bool::False␤»

after parsing eventually essentially becomes this:

 r: use nqp; dd nqp::div_In(99981, 
100_000_000_000_000_000) == nqp::div_In(9998, 
10_000_000_000_000_000)
 rakudo-jvm a92950fb4, rakudo-moar f48636011: OUTPUT: 
«Bool::False␤»

And it gives False, but in C, those two numbers are equal:

$ ccc 'printf("%d\n", 9.9981e0 == 9.998e0)'
1

[perl #128912] [BUG] decimal->float bad rounding

[Zoffix Znet via RT]

On Fri, 12 Aug 2016 09:46:38 -0700, zef...@fysh.org wrote:
> > (9.999e-5 * 2e0**66).Int * 5**8 -  * 2**58
> 287369
> > (9.99895e-5 * 2e0**66).Int * 5**8 -  * 2**58
> -103256
> 
> The above computations show, scaled up, the difference between a Num value
> and the exact value 9.999e-5.  As you can see, the Num that arose from
> the "9.99895e-5" literal was slightly closer than the Num
> that arose from the "9.999e-5" literal.  The closer of these two is in
> fact the closest representable IEEE double precision value to 9.999e-5.
> Thus this literal "9.999e-5" has not yielded the closest available Num
> to its nominal value; this is a bug.  glibc's strtod() handles this case
> fine, yielding the closer value.
> 
> Note that the only rounding occurring in this test case is on the
> decimal->float conversion.  The multiplication by a power of two,
> conversion of integer-valued float to Int, and all the Int arithmetic,
> are all exact.
> 
> -zefram


Thank you for the report. This is now fixed.

Fix:  https://github.com/MoarVM/MoarVM/commit/067c0594103a025
  https://github.com/MoarVM/MoarVM/commit/8841c4241b4faa8
  https://github.com/MoarVM/MoarVM/commit/af2eb8a7f7d4344
  https://github.com/MoarVM/MoarVM/commit/4d3fc2818d0032b
  https://github.com/rakudo/rakudo/commit/8422d7b4e23678b
  https://github.com/rakudo/rakudo/commit/a2a2a745c4242d1
Test: https://github.com/perl6/roast/commit/7fdd5372b85172fcc

[perl #128912] [BUG] decimal->float bad rounding

[Zoffix Znet via RT]

On Fri, 12 Aug 2016 09:46:38 -0700, zef...@fysh.org wrote:
> > (9.999e-5 * 2e0**66).Int * 5**8 -  * 2**58
> 287369
> > (9.99895e-5 * 2e0**66).Int * 5**8 -  * 2**58
> -103256
> 
> The above computations show, scaled up, the difference between a Num value
> and the exact value 9.999e-5.  As you can see, the Num that arose from
> the "9.99895e-5" literal was slightly closer than the Num
> that arose from the "9.999e-5" literal.  The closer of these two is in
> fact the closest representable IEEE double precision value to 9.999e-5.
> Thus this literal "9.999e-5" has not yielded the closest available Num
> to its nominal value; this is a bug.  glibc's strtod() handles this case
> fine, yielding the closer value.
> 
> Note that the only rounding occurring in this test case is on the
> decimal->float conversion.  The multiplication by a power of two,
> conversion of integer-valued float to Int, and all the Int arithmetic,
> are all exact.
> 
> -zefram


Thank you for the report. This is now fixed.

Fix:  https://github.com/MoarVM/MoarVM/commit/067c0594103a025
  https://github.com/MoarVM/MoarVM/commit/8841c4241b4faa8
  https://github.com/MoarVM/MoarVM/commit/af2eb8a7f7d4344
  https://github.com/MoarVM/MoarVM/commit/4d3fc2818d0032b
  https://github.com/rakudo/rakudo/commit/8422d7b4e23678b
  https://github.com/rakudo/rakudo/commit/a2a2a745c4242d1
Test: https://github.com/perl6/roast/commit/7fdd5372b85172fcc

[perl #132268] [MATH] Floating point anomalies

[Zoffix Znet via RT]

On Wed, 11 Oct 2017 04:25:32 -0700, sisyphus wrote:
> Hi,
> Some anomalous rounding behaviour on Ubuntu-16.04 was noted at 
> http://www.perlmonks.org/?node_id=1200326
> 
> Here are the specifics:
> 
> $ perl6 --version
> This is Rakudo version 2017.07 built on MoarVM version 2017.07
> implementing Perl 6.c.
> 
> ===
> Issue 1
> ===
> 
> $ perl6  -e 'say Int(2e25);'
> 20001811939328
> $ perl6  -e 'say Int(20e24);'
> 19997516972032
> 
> That seems odd because 2e25 and 20e24 are exactly equivalent.
> 
> ===
> Issue 2
> ===
> 
> $ perl6 -e 'say "WTF" if 1.001e0 == 1e0;'
> WTF
> 
> That seems odd because 1.001e0 and 1e0 are quite different 
> double precision values. According to perl5:
> 
> $ perl -le 'print scalar reverse unpack "h*", pack "d<", 
> 1.001e0;'
> 3ff5
> $ perl -le 'print scalar reverse unpack "h*", pack "d<", 1e0;'
> 3ff0
> 
> Is it the intention of the perl6 developers that such discrepancies will be 
> addressed ?
> 
> Cheers,
> Rob


Thank you for the report. All the issues mentioned in the ticket are now fixed.

- The mentioned printf issues look to have been resolved as well,
  even though no work to printf itself was done.
- Somehow fixing Num stringification alone fixed the
`1.001e0 == 1e0` bug. That was surprising and I filed
https://github.com/rakudo/rakudo/issues/1647 to investigate that further
- Support for '%a' in sprintf was mentioned in the ticket, but I suggest
if there's real interest for that format, a separate ticket to be opened
- There a Num-involved precision issue with drift in Str->Num->Str chains,
filed as https://github.com/rakudo/rakudo/issues/1651


Fix:  https://github.com/MoarVM/MoarVM/commit/067c0594103a025
  https://github.com/MoarVM/MoarVM/commit/8841c4241b4faa8
  https://github.com/MoarVM/MoarVM/commit/af2eb8a7f7d4344
  https://github.com/MoarVM/MoarVM/commit/4d3fc2818d0032b
  https://github.com/rakudo/rakudo/commit/8422d7b4e23678b
  https://github.com/rakudo/rakudo/commit/a2a2a745c4242d1
Test: https://github.com/perl6/roast/commit/01d02dafb6
  https://github.com/perl6/roast/commit/b6d5364fe0
  https://github.com/perl6/roast/commit/855af84f82
  https://github.com/perl6/roast/commit/f4a6c635f4
  https://github.com/perl6/roast/commit/d1faf1d049

[perl #132268] [MATH] Floating point anomalies

[Zoffix Znet via RT]

On Wed, 11 Oct 2017 04:25:32 -0700, sisyphus wrote:
> Hi,
> Some anomalous rounding behaviour on Ubuntu-16.04 was noted at 
> http://www.perlmonks.org/?node_id=1200326
> 
> Here are the specifics:
> 
> $ perl6 --version
> This is Rakudo version 2017.07 built on MoarVM version 2017.07
> implementing Perl 6.c.
> 
> ===
> Issue 1
> ===
> 
> $ perl6  -e 'say Int(2e25);'
> 20001811939328
> $ perl6  -e 'say Int(20e24);'
> 19997516972032
> 
> That seems odd because 2e25 and 20e24 are exactly equivalent.
> 
> ===
> Issue 2
> ===
> 
> $ perl6 -e 'say "WTF" if 1.001e0 == 1e0;'
> WTF
> 
> That seems odd because 1.001e0 and 1e0 are quite different 
> double precision values. According to perl5:
> 
> $ perl -le 'print scalar reverse unpack "h*", pack "d<", 
> 1.001e0;'
> 3ff5
> $ perl -le 'print scalar reverse unpack "h*", pack "d<", 1e0;'
> 3ff0
> 
> Is it the intention of the perl6 developers that such discrepancies will be 
> addressed ?
> 
> Cheers,
> Rob


Thank you for the report. All the issues mentioned in the ticket are now fixed.

- The mentioned printf issues look to have been resolved as well,
  even though no work to printf itself was done.
- Somehow fixing Num stringification alone fixed the
`1.001e0 == 1e0` bug. That was surprising and I filed
https://github.com/rakudo/rakudo/issues/1647 to investigate that further
- Support for '%a' in sprintf was mentioned in the ticket, but I suggest
if there's real interest for that format, a separate ticket to be opened
- There a Num-involved precision issue with drift in Str->Num->Str chains,
filed as https://github.com/rakudo/rakudo/issues/1651


Fix:  https://github.com/MoarVM/MoarVM/commit/067c0594103a025
  https://github.com/MoarVM/MoarVM/commit/8841c4241b4faa8
  https://github.com/MoarVM/MoarVM/commit/af2eb8a7f7d4344
  https://github.com/MoarVM/MoarVM/commit/4d3fc2818d0032b
  https://github.com/rakudo/rakudo/commit/8422d7b4e23678b
  https://github.com/rakudo/rakudo/commit/a2a2a745c4242d1
Test: https://github.com/perl6/roast/commit/01d02dafb6
  https://github.com/perl6/roast/commit/b6d5364fe0
  https://github.com/perl6/roast/commit/855af84f82
  https://github.com/perl6/roast/commit/f4a6c635f4
  https://github.com/perl6/roast/commit/d1faf1d049

[perl #127184] [BUG] One digit short to correctly stringify a double

[Zoffix Znet via RT]

On Wed, 06 Jan 2016 04:47:03 -0800, dankogai wrote:
> Folks,
> 
> Rakudo needs to add one more digit for each Num it stringifies.
> 
> % perl6 -e 'pi.say'
> 3.14159265358979
> % ruby -e 'puts Math::PI'
> 3.141592653589793
> 
> As a result…
> 
> % perl6
> > 3.14159265358979 == pi
> False
> > 3.141592653589793 == pi
> True
> 
> I consider this more severe than perl5 because:
> 
> > ::('')(pi.perl) == pi
> False
> 
> FYI perl5 has the same problem.
> 
> https://rt.perl.org/Public/Bug/Display.html?id=127182
> 
> Please also consider adding hexadecimal floating point notation
> support (and make .perl happier).
> 
> Yours,
> 
> Dan the Bit-Picking Rakudo Monger


Thank you for the report. This is now fixed.

Fix:  https://github.com/MoarVM/MoarVM/commit/067c0594103a025
  https://github.com/MoarVM/MoarVM/commit/8841c4241b4faa8
  https://github.com/MoarVM/MoarVM/commit/af2eb8a7f7d4344
  https://github.com/MoarVM/MoarVM/commit/4d3fc2818d0032b
  https://github.com/rakudo/rakudo/commit/8422d7b4e23678b
  https://github.com/rakudo/rakudo/commit/a2a2a745c4242d1
Test: https://github.com/perl6/roast/commit/589e30a8e809bba7f

[perl #127184] [BUG] One digit short to correctly stringify a double

[Zoffix Znet via RT]

On Wed, 06 Jan 2016 04:47:03 -0800, dankogai wrote:
> Folks,
> 
> Rakudo needs to add one more digit for each Num it stringifies.
> 
> % perl6 -e 'pi.say'
> 3.14159265358979
> % ruby -e 'puts Math::PI'
> 3.141592653589793
> 
> As a result…
> 
> % perl6
> > 3.14159265358979 == pi
> False
> > 3.141592653589793 == pi
> True
> 
> I consider this more severe than perl5 because:
> 
> > ::('')(pi.perl) == pi
> False
> 
> FYI perl5 has the same problem.
> 
> https://rt.perl.org/Public/Bug/Display.html?id=127182
> 
> Please also consider adding hexadecimal floating point notation
> support (and make .perl happier).
> 
> Yours,
> 
> Dan the Bit-Picking Rakudo Monger


Thank you for the report. This is now fixed.

Fix:  https://github.com/MoarVM/MoarVM/commit/067c0594103a025
  https://github.com/MoarVM/MoarVM/commit/8841c4241b4faa8
  https://github.com/MoarVM/MoarVM/commit/af2eb8a7f7d4344
  https://github.com/MoarVM/MoarVM/commit/4d3fc2818d0032b
  https://github.com/rakudo/rakudo/commit/8422d7b4e23678b
  https://github.com/rakudo/rakudo/commit/a2a2a745c4242d1
Test: https://github.com/perl6/roast/commit/589e30a8e809bba7f

[perl #132980] Coercion type apparently does not check the actual type of the coerced value

[Zoffix Znet via RT]

On Wed, 14 Mar 2018 14:16:06 -0700, comdog wrote:
> I was playing with coercion types and wondered what would happen if
> a .Int method did not return the right sort of type:
> 
> class Foo {
> method Int ( --> Str ) { 'Hello' }
> }
> 
> put try-it( Foo.new );
> 
> sub try-it ( Int() $n ) { "Got <$n> of type <{$n.^name}>" }
> 
> Although the subroutine signature demanded an Int, it accepted
> something that claimed to be able to convert but actually didn't:
> 
> Got  of type 
> 
> I would have expected the runtime constraint to check the ultimate
> value against the type and this would have failed.
> 
> 

Thanks for the report.

We'll likely want to extend the features of the coercers, and include the return
type check, but not until 6.e or later language versions, when we have some
headroom with respect to performance.

I've documented[^1] that no check is currently performed on the result and there
are some extra proposed spec[^2] for coercers marked for 6.d review already, so 
I'll mark
this ticket as resolved. (though given 6.d is on already the horizon, the check 
of return
type would likely not make it into 6.d). The other feature we'd want to 
eventually implement
is coercing via `Target.new(Source)`, if not `Source.Target` method exists.

I've tried[^3] implementation[^4] of checking the final result in January and it
dropped performance of coercers by 8%. Given the marginal benefit offered by the
fix, we just can't afford to spend a 8% drop in a common feature at the moment.
So currently, it's just a "verbal" contract that method Foo returns object Foo,
similar how to `sub _foo` is a private method in Perl 5 by convention, despite 
it being public.

[1] https://github.com/perl6/doc/commit/ee34834195
[2] https://github.com/perl6/roast/blob/master/S12-coercion/coercion-types.t
[3] https://irclog.perlgeek.de/perl6-dev/2018-01-07#i_15661357
[4] https://gist.github.com/zoffixznet/6d0a2085bd343535b99f548d15547729

[perl #132980] Coercion type apparently does not check the actual type of the coerced value

[Zoffix Znet via RT]

On Wed, 14 Mar 2018 14:16:06 -0700, comdog wrote:
> I was playing with coercion types and wondered what would happen if
> a .Int method did not return the right sort of type:
> 
> class Foo {
> method Int ( --> Str ) { 'Hello' }
> }
> 
> put try-it( Foo.new );
> 
> sub try-it ( Int() $n ) { "Got <$n> of type <{$n.^name}>" }
> 
> Although the subroutine signature demanded an Int, it accepted
> something that claimed to be able to convert but actually didn't:
> 
> Got  of type 
> 
> I would have expected the runtime constraint to check the ultimate
> value against the type and this would have failed.
> 
> 

Thanks for the report.

We'll likely want to extend the features of the coercers, and include the return
type check, but not until 6.e or later language versions, when we have some
headroom with respect to performance.

I've documented[^1] that no check is currently performed on the result and there
are some extra proposed spec[^2] for coercers marked for 6.d review already, so 
I'll mark
this ticket as resolved. (though given 6.d is on already the horizon, the check 
of return
type would likely not make it into 6.d). The other feature we'd want to 
eventually implement
is coercing via `Target.new(Source)`, if not `Source.Target` method exists.

I've tried[^3] implementation[^4] of checking the final result in January and it
dropped performance of coercers by 8%. Given the marginal benefit offered by the
fix, we just can't afford to spend a 8% drop in a common feature at the moment.
So currently, it's just a "verbal" contract that method Foo returns object Foo,
similar how to `sub _foo` is a private method in Perl 5 by convention, despite 
it being public.

[1] https://github.com/perl6/doc/commit/ee34834195
[2] https://github.com/perl6/roast/blob/master/S12-coercion/coercion-types.t
[3] https://irclog.perlgeek.de/perl6-dev/2018-01-07#i_15661357
[4] https://gist.github.com/zoffixznet/6d0a2085bd343535b99f548d15547729

[perl #126855] [BUG] .WHAT does not allow spaces around the dot (42 . WHAT)

[Zoffix Znet via RT]

On Sun, 04 Jun 2017 11:19:57 -0700, c...@zoffix.com wrote:
> On Wed, 09 Dec 2015 08:12:00 -0800, alex.jakime...@gmail.com wrote:
> > Code:
> > say 42 .WHAT
> >
> > Result:
> > ===SORRY!===
> > Method call must either supply a name or have a child node that
> > evaluates
> > to the name
> >
> >
> > Well, I think that it should work. One practical use is ｢^42 .WHAT｣.
> >
> > Some explanation:
> >
> >  well, .WHAT anywhere in a space-y method call chain didn't
> > work with
> >  the original commit either
> >  so it's at least not a regression
> >  okay, interesting
> >  probably 'cause .WHAT doesn't go the normal
> >  QAST::Op(:op,...) route
> >  right, it's macro-Y
> >  which fits the error message, 'cause we apparently build such
> > an Op
> > but
> >  don't populate the children correctly, because .WHAT
> > isn't a
> > method
> >  that can be called with callmethod
> >
> >
> > Well, if it is not supposed to work, then at least the error message
> > should
> > be awesome. Right now it doesn't even mention the line number.
> 
> 
> +1 on fixing this or improving error message.
> 
> In my production code I encountered this bug while trying to test the
> term's type object
> and I added the space after the method to align stuff:
> 
> is make-temp-path.WHAT === IO::Path, *.not, 'made path is not ===
> IO::Path';
> is make-temp-dir .WHAT === IO::Path, *.not, 'made dir  is not ===
> IO::Path';
> 
> The second line crashed.
> 
> The current error doesn't even include a location, so it has the
> potential for a tedious bug hunt.


Hit on this bug again. Even while knowing you can't put spaces before .WHAT, it 
took me a couple of minutes trying to find where this error was coming from.

[perl #126855] [BUG] .WHAT does not allow spaces around the dot (42 . WHAT)

[Zoffix Znet via RT]

On Sun, 04 Jun 2017 11:19:57 -0700, c...@zoffix.com wrote:
> On Wed, 09 Dec 2015 08:12:00 -0800, alex.jakime...@gmail.com wrote:
> > Code:
> > say 42 .WHAT
> >
> > Result:
> > ===SORRY!===
> > Method call must either supply a name or have a child node that
> > evaluates
> > to the name
> >
> >
> > Well, I think that it should work. One practical use is ｢^42 .WHAT｣.
> >
> > Some explanation:
> >
> >  well, .WHAT anywhere in a space-y method call chain didn't
> > work with
> >  the original commit either
> >  so it's at least not a regression
> >  okay, interesting
> >  probably 'cause .WHAT doesn't go the normal
> >  QAST::Op(:op,...) route
> >  right, it's macro-Y
> >  which fits the error message, 'cause we apparently build such
> > an Op
> > but
> >  don't populate the children correctly, because .WHAT
> > isn't a
> > method
> >  that can be called with callmethod
> >
> >
> > Well, if it is not supposed to work, then at least the error message
> > should
> > be awesome. Right now it doesn't even mention the line number.
> 
> 
> +1 on fixing this or improving error message.
> 
> In my production code I encountered this bug while trying to test the
> term's type object
> and I added the space after the method to align stuff:
> 
> is make-temp-path.WHAT === IO::Path, *.not, 'made path is not ===
> IO::Path';
> is make-temp-dir .WHAT === IO::Path, *.not, 'made dir  is not ===
> IO::Path';
> 
> The second line crashed.
> 
> The current error doesn't even include a location, so it has the
> potential for a tedious bug hunt.


Hit on this bug again. Even while knowing you can't put spaces before .WHAT, it 
took me a couple of minutes trying to find where this error was coming from.

[perl #114554] [BUG] Definition of zero-length postfix operator wrongly allowed in Rakudo

[Zoffix Znet via RT]

On Thu, 07 Apr 2016 10:31:20 -0700, diakopter wrote:
> new behavior:
> 
> 13:30  m: sub postfix:{}($a) { say "$a bracey brace" };
> 42{}
> 13:30  rakudo-moar 61d231: OUTPUT«===SORRY!===␤Internal
> error: find_var_decl could not find $_␤»


Couple more glitches in the same area:

14:59   Zoffix  m: my $z:{:42foo}
14:59   camelia rakudo-moar 26522e8ac: OUTPUT: «5===SORRY!5=== Error 
while compiling ␤You can't adverb $z␤at :1␤--> 3my 
$z:{:42foo}7⏏5␤»
14:59   Zoffix  m: my \z:{:42foo}
14:59   camelia rakudo-moar 26522e8ac: OUTPUT: «===SORRY!===␤Cannot 
find method 'ast' on object of type NQPMu␤»

[perl #114554] [BUG] Definition of zero-length postfix operator wrongly allowed in Rakudo

[Zoffix Znet via RT]

On Thu, 07 Apr 2016 10:31:20 -0700, diakopter wrote:
> new behavior:
> 
> 13:30  m: sub postfix:{}($a) { say "$a bracey brace" };
> 42{}
> 13:30  rakudo-moar 61d231: OUTPUT«===SORRY!===␤Internal
> error: find_var_decl could not find $_␤»


Couple more glitches in the same area:

14:59   Zoffix  m: my $z:{:42foo}
14:59   camelia rakudo-moar 26522e8ac: OUTPUT: «5===SORRY!5=== Error 
while compiling ␤You can't adverb $z␤at :1␤--> 3my 
$z:{:42foo}7⏏5␤»
14:59   Zoffix  m: my \z:{:42foo}
14:59   camelia rakudo-moar 26522e8ac: OUTPUT: «===SORRY!===␤Cannot 
find method 'ast' on object of type NQPMu␤»

[perl #130688] [BUG] .subst/.subst-mutate with :g do not set $/ to all the matches

[Zoffix Znet via RT]

On Wed, 22 Mar 2017 13:58:22 -0700, c...@zoffix.com wrote:
> Also affects :x and :nth modifiers
> 
>  m: 'mmm'.subst: :x(1..3), /m/, 'g'; say WHAT $/
>  rakudo-moar 6a77cd: OUTPUT: «(Match)␤»
>  m: 'mmm'.subst: :nth(1..3), /m/, 'g'; say WHAT $/
>  rakudo-moar 6a77cd: OUTPUT: «(Match)␤»

Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/874fcdda2dc469f
Test: https://github.com/perl6/roast/commit/af02dd68eb7569b91

[perl #130688] [BUG] .subst/.subst-mutate with :g do not set $/ to all the matches

[Zoffix Znet via RT]

On Wed, 22 Mar 2017 13:58:22 -0700, c...@zoffix.com wrote:
> Also affects :x and :nth modifiers
> 
>  m: 'mmm'.subst: :x(1..3), /m/, 'g'; say WHAT $/
>  rakudo-moar 6a77cd: OUTPUT: «(Match)␤»
>  m: 'mmm'.subst: :nth(1..3), /m/, 'g'; say WHAT $/
>  rakudo-moar 6a77cd: OUTPUT: «(Match)␤»

Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/874fcdda2dc469f
Test: https://github.com/perl6/roast/commit/af02dd68eb7569b91

[perl #126897] [BUG] Slip objects deparse as List

[Zoffix Znet via RT]

On Sun, 13 Dec 2015 13:15:56 -0800, elizabeth wrote:
> so no
> further tests needed
> 
> 
> Liz

And in addition it's covered by tests for another slip bug:
https://github.com/perl6/roast/commit/7eea834e98090b1f571dabe719784eaa0b0207ff

Closing.

[perl #126897] [BUG] Slip objects deparse as List

[Zoffix Znet via RT]

On Sun, 13 Dec 2015 13:15:56 -0800, elizabeth wrote:
> so no
> further tests needed
> 
> 
> Liz

And in addition it's covered by tests for another slip bug:
https://github.com/perl6/roast/commit/7eea834e98090b1f571dabe719784eaa0b0207ff

Closing.

[perl #129912] [OPTIMIZER] Subset produces Cannot invoke this object (REPR: Null; VMNull)

[Zoffix Znet via RT]

On Wed, 14 Dec 2016 15:14:27 -0800, c...@zoffix.com wrote:
> Seems an optimizer bug. Running with --optimize=off does not have the
> issue present.


Fixed and tested as https://github.com/rakudo/rakudo/issues/1465

[perl #129912] [OPTIMIZER] Subset produces Cannot invoke this object (REPR: Null; VMNull)

[Zoffix Znet via RT]

On Wed, 14 Dec 2016 15:14:27 -0800, c...@zoffix.com wrote:
> Seems an optimizer bug. Running with --optimize=off does not have the
> issue present.


Fixed and tested as https://github.com/rakudo/rakudo/issues/1465

[perl #130892] t\spec\S32-io\IO-Socket-INET.t hangs

[Zoffix Znet via RT]

A Windows-specific skip-fudge now went in[^1] but the problem remains


[1] 
https://github.com/perl6/roast/commit/86abb5376bd331d9766212ce4d0c11c11dd5c5dd

[perl #130892] t\spec\S32-io\IO-Socket-INET.t hangs

[Zoffix Znet via RT]

A Windows-specific skip-fudge now went in[^1] but the problem remains


[1] 
https://github.com/perl6/roast/commit/86abb5376bd331d9766212ce4d0c11c11dd5c5dd

[perl #131508] [BUG] `state` with % is Sethash in whenever block ends up with a type object on second iteration

[Zoffix Znet via RT]

On Sun, 04 Jun 2017 07:12:25 -0700, c...@zoffix.com wrote:
> %goods here works as expected:
> 
>  m: my %goods is SetHash; react whenever Supply.interval(.3)
> { $++ > 3 and done; dd %goods; %goods++; }
>  rakudo-moar 3755c0: OUTPUT:
> «SetHash.new()␤SetHash.new("foo")␤SetHash.new("foo")␤SetHash.new("foo")␤»
> 
> On second iteration ends up being a type object:
> 
>  m: react whenever Supply.interval(.3) { state %goods is
> SetHash; $++ > 3 and done; dd %goods; %goods++; }
>  rakudo-moar 3755c0: OUTPUT: «SetHash.new()␤SetHash␤Tried to
> get the result of a broken Promise␤  in block  at  line
> 1␤␤Original exception:␤Cannot modify an immutable SetHash
> ((SetHash))␤  in block  at  line 1␤␤»

Another case:

```
 m: .grep: { (state %code-files is SetHash = ); LEAVE 
dd %code-files; }
 rakudo-moar dd2c90192: OUTPUT: 
«SetHash.new("foo","bar")␤SetHash␤SetHash␤»
```

[perl #131508] [BUG] `state` with % is Sethash in whenever block ends up with a type object on second iteration

[Zoffix Znet via RT]

On Sun, 04 Jun 2017 07:12:25 -0700, c...@zoffix.com wrote:
> %goods here works as expected:
> 
>  m: my %goods is SetHash; react whenever Supply.interval(.3)
> { $++ > 3 and done; dd %goods; %goods++; }
>  rakudo-moar 3755c0: OUTPUT:
> «SetHash.new()␤SetHash.new("foo")␤SetHash.new("foo")␤SetHash.new("foo")␤»
> 
> On second iteration ends up being a type object:
> 
>  m: react whenever Supply.interval(.3) { state %goods is
> SetHash; $++ > 3 and done; dd %goods; %goods++; }
>  rakudo-moar 3755c0: OUTPUT: «SetHash.new()␤SetHash␤Tried to
> get the result of a broken Promise␤  in block  at  line
> 1␤␤Original exception:␤Cannot modify an immutable SetHash
> ((SetHash))␤  in block  at  line 1␤␤»

Another case:

```
 m: .grep: { (state %code-files is SetHash = ); LEAVE 
dd %code-files; }
 rakudo-moar dd2c90192: OUTPUT: 
«SetHash.new("foo","bar")␤SetHash␤SetHash␤»
```

[perl #125466] [MATH][@LARRY] bitwise shift is inconsistent on int

[Zoffix Znet via RT]

On Sat, 07 Oct 2017 23:35:26 -0700, c...@zoffix.com wrote:
> Tests were added in https://github.com/perl6/roast/pull/344/files
> 
> There are three fudges where it's unknown what the proper behaviour
> should be (overflow or switch to Int?).
> 
> Someone Who Knows should review them and unfudge/correct.

Some comments on this: 
https://irclog.perlgeek.de/perl6-dev/2018-03-05#i_15887265

* TimToady  thinks people who are writing crypto codes want ways to keep 
everything native, if we make it default the other way

[perl #125466] [MATH][@LARRY] bitwise shift is inconsistent on int

[Zoffix Znet via RT]

On Sat, 07 Oct 2017 23:35:26 -0700, c...@zoffix.com wrote:
> Tests were added in https://github.com/perl6/roast/pull/344/files
> 
> There are three fudges where it's unknown what the proper behaviour
> should be (overflow or switch to Int?).
> 
> Someone Who Knows should review them and unfudge/correct.

Some comments on this: 
https://irclog.perlgeek.de/perl6-dev/2018-03-05#i_15887265

* TimToady  thinks people who are writing crypto codes want ways to keep 
everything native, if we make it default the other way

[perl #128520] [META][RT][RFC] Consider migrating from RT

[Zoffix Znet via RT]

On Wed, 11 Oct 2017 13:22:50 -0700, alex.jakime...@gmail.com wrote:
> Oh, and if rakudo/issues is opened, then for me all issues raised in this
> ticket will be resolved.

It was opened awhile ago.

…and based on the recent usage, seems GitHub's ticket tracker is preferred by 
users, so as far as this ticket goes, I think it can be closed.

[perl #128520] [META][RT][RFC] Consider migrating from RT

[Zoffix Znet via RT]

On Wed, 11 Oct 2017 13:22:50 -0700, alex.jakime...@gmail.com wrote:
> Oh, and if rakudo/issues is opened, then for me all issues raised in this
> ticket will be resolved.

It was opened awhile ago.

…and based on the recent usage, seems GitHub's ticket tracker is preferred by 
users, so as far as this ticket goes, I think it can be closed.

[perl #128655] [OPTIMIZER] Mixup in candidates through optimizer

[Zoffix Znet via RT]

On Sat, 15 Jul 2017 09:47:40 -0700, jan-olof.hen...@bredband.net wrote:
> On Sat, 15 Jul 2017 07:15:05 -0700, jan-olof.hen...@bredband.net
> wrote:
> > On Tue, 31 Jan 2017 09:05:52 -0800, c...@zoffix.com wrote:
> > > I dug at this bug a few months back, but lost my notes on my
> > > findings.
> > >
> > > As I recall it, the 128655 happens in BOOTSTRAP.nqp in
> > > find_best_dispatchee() the non-native candidate ends up being first
> > > in
> > > the list and that's why it's used instead of native candidates.
> > >
> > > I then went and wrote down the new rules for dispatch that would
> > > avoid
> > > that: https://rt.perl.org/Ticket/Display.html?id=129844
> > >
> > > Then jnthn++ explained (https://irclog.perlgeek.de/perl6-dev/2016-
> > > 10-
> > > 25#i_13462673 ) that I misunderstood the auto[un]boxing behaviour
> > > of
> > > natives, so the new rules are out of the window. But that's where
> > > my
> > > journey ended and never re-examined this ticket with my new
> > > understanding of boxing.
> >
> > It turns out that he part reported 'on behalf of dogbert17', se
> > above,
> > describes a
> > different problem which was fixed with
> > https://github.com/rakudo/rakudo/commit/c98b3a581f481756234758e474c255414a340c97
> 
> Also, the original problem has been 'temporarily' solved with
> https://github.com/rakudo/rakudo/commit/242baf256a210f1cb643cb6324916dbc76184c9f


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/29fdb75a30
  https://github.com/rakudo/rakudo/commit/3d7359755698458
Test: https://github.com/perl6/roast/commit/32ac651062f3ba06f

[perl #128655] [OPTIMIZER] Mixup in candidates through optimizer

[Zoffix Znet via RT]

On Sat, 15 Jul 2017 09:47:40 -0700, jan-olof.hen...@bredband.net wrote:
> On Sat, 15 Jul 2017 07:15:05 -0700, jan-olof.hen...@bredband.net
> wrote:
> > On Tue, 31 Jan 2017 09:05:52 -0800, c...@zoffix.com wrote:
> > > I dug at this bug a few months back, but lost my notes on my
> > > findings.
> > >
> > > As I recall it, the 128655 happens in BOOTSTRAP.nqp in
> > > find_best_dispatchee() the non-native candidate ends up being first
> > > in
> > > the list and that's why it's used instead of native candidates.
> > >
> > > I then went and wrote down the new rules for dispatch that would
> > > avoid
> > > that: https://rt.perl.org/Ticket/Display.html?id=129844
> > >
> > > Then jnthn++ explained (https://irclog.perlgeek.de/perl6-dev/2016-
> > > 10-
> > > 25#i_13462673 ) that I misunderstood the auto[un]boxing behaviour
> > > of
> > > natives, so the new rules are out of the window. But that's where
> > > my
> > > journey ended and never re-examined this ticket with my new
> > > understanding of boxing.
> >
> > It turns out that he part reported 'on behalf of dogbert17', se
> > above,
> > describes a
> > different problem which was fixed with
> > https://github.com/rakudo/rakudo/commit/c98b3a581f481756234758e474c255414a340c97
> 
> Also, the original problem has been 'temporarily' solved with
> https://github.com/rakudo/rakudo/commit/242baf256a210f1cb643cb6324916dbc76184c9f


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/29fdb75a30
  https://github.com/rakudo/rakudo/commit/3d7359755698458
Test: https://github.com/perl6/roast/commit/32ac651062f3ba06f

[perl #132511] Binary assignment Z+= fails if it's the last thing in for loop

[Zoffix Znet via RT]

On Mon, 04 Dec 2017 12:31:28 -0800, alex.jakime...@gmail.com wrote:
> FWIW it never worked:
> https://gist.github.com/Whateverable/d9dbebb0e985a3964845df2c8652cbdf
> 
> On 2017-11-27 17:36:22, comdog wrote:
> > I previously asked about this unexpected Z behavior on Stackoverflow
> > ( https://stackoverflow.com/q/45001820/2766176 ).
> >
> > I expected this to change several hash keys at once. It changes no keys:
> >
> > my $hash = %(
> > wallet => 100,
> > gave => 0,
> > received => 0,
> > );
> >
> > for ^1 { $hash Z+= <-1 1> }
> >
> > dd $hash;
> >
> > I get:
> >
> > Hash $hash = ${:gave(0), :received(0), :wallet(100)}
> >
> > If I change that to add another statement it works:
> >
> > for ^1 { $hash Z+= <-1 1>; True }
> >
> > It also works if I take out the binary assignment:
> >
> > for ^1 { $hash = $hash Z+ <-1 1> }


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/8a10fc17a319029
Test: https://github.com/perl6/roast/commit/01b59fba66bde1e61

[perl #132511] Binary assignment Z+= fails if it's the last thing in for loop

[Zoffix Znet via RT]

On Mon, 04 Dec 2017 12:31:28 -0800, alex.jakime...@gmail.com wrote:
> FWIW it never worked:
> https://gist.github.com/Whateverable/d9dbebb0e985a3964845df2c8652cbdf
> 
> On 2017-11-27 17:36:22, comdog wrote:
> > I previously asked about this unexpected Z behavior on Stackoverflow
> > ( https://stackoverflow.com/q/45001820/2766176 ).
> >
> > I expected this to change several hash keys at once. It changes no keys:
> >
> > my $hash = %(
> > wallet => 100,
> > gave => 0,
> > received => 0,
> > );
> >
> > for ^1 { $hash Z+= <-1 1> }
> >
> > dd $hash;
> >
> > I get:
> >
> > Hash $hash = ${:gave(0), :received(0), :wallet(100)}
> >
> > If I change that to add another statement it works:
> >
> > for ^1 { $hash Z+= <-1 1>; True }
> >
> > It also works if I take out the binary assignment:
> >
> > for ^1 { $hash = $hash Z+ <-1 1> }


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/8a10fc17a319029
Test: https://github.com/perl6/roast/commit/01b59fba66bde1e61

[perl #131622] [BUG] Failures don't get sunk when last in for loop

[Zoffix Znet via RT]

On Wed, 03 Jan 2018 10:51:49 -0800, c...@zoffix.com wrote:
> Related Issue: https://github.com/rakudo/rakudo/issues/1360

Fix: https://github.com/rakudo/rakudo/commit/4c5b81fedb7434b235
Test: 
https://github.com/perl6/roast/commit/01b59fba66bde1e616b91afbbfc0f89b7727f05a

[perl #132885] .next-handle seems to change handles but doesn't

[Zoffix Znet via RT]

On Mon, 19 Feb 2018 19:48:30 -0800, c...@zoffix.com wrote:
> On Mon, 19 Feb 2018 16:15:37 -0800, comdog wrote:
> > #!/Users/brian/bin/perl6s/perl6-latest
> >
> > I'm playing with .next-handle from IO::CatHandle. I'm
> > trying to create a situation where I can read just the first five
> > lines from each command line argument:
> >
> > quietly {
> > my $limit = 5;
> > for lines() {
> > state $lines = 1;
> > FIRST { $*ARGFILES.on-switch = { put "NEW FILE"; $lines = 1 }
> > }
> > if $lines > $limit {
> > $*ARGFILES.next-handle;
> > next;
> > }
> > put "{$*ARGFILES.path}:{$lines++} $_";
> > }
> > }
> >
> > Here's a test file:
> >
> > First
> > Second
> > Third
> > Fourth
> > Fifth
> > Six
> > Seventh
> >
> > With one or more command-line arguments I get this odd behavior (and
> > lots of warnings that I suppressed):
> >
> > test.txt:1 First
> > test.txt:2 Second
> > test.txt:3 Third
> > test.txt:4 Fourth
> > test.txt:5 Fifth
> > NEW FILE
> > :1 Seventh
> > read bytes requires an object with REPR MVMOSHandle (got VMNull
> > with REPR Null)
> >   in block  at lines-method.p6 line 5
> >
> > It does "switch" after five lines, but then it keeps reading from the
> > same handle while losing a line. Then there's a strange error at the
> > end that kills the whole thing.
> >
> > I expected that it would close the current handle, open a new one,
> > and
> > continue. If it gets to the end, it would simply not provide any more
> > lines() and things would end normally.
> >
> > The docs for .next-handle lets you keep changing it as long as you
> > like no matter how many
> >
> > -
> >
> > This is Rakudo Star version 2018.01 built on MoarVM version 2018.01
> > implementing Perl 6.c.
> 
> 
> This is because current implementation of IO::CatHandle.lines simply
> flattens
> a gather/taken .lines Seq from each handle, so it never expects the
> handles to
> get switched before each .lines Seq is fully-consumed. The .next-
> handle closes
> the previous handle, which is where the weird error comes from (it
> tries to use
> the now-nulled $!PIO to .read/.eof from). Pretty sure .words is
> similarly affected.
> 
> I think if we give IO::CatHandle!LINES and IO::CatHandle!WORDS their
> own
> iterators that basically do the same thing as IO::Handle ones and then
> make
> .next-handle also toss the remaining data in the $!decoder, then the
> OP code
> would work.
> 
> In the meantime, you can use `.get` instead:
> 
> my $limit := 3;
> my $lines = 1;
> with $*ARGFILES -> $af {
> while ($_ := $af.get) !=:= Nil {
> $lines == 1 and put "NEWFILE:";
> put "$af.path():{$lines++} $_";
> next unless $lines > $limit;
> $af.next-handle and $lines = 1;
> }
> }
> 
> I also noticed another deficiency: when trying to set .on-switch on
> $*ARGFILES,
> you always miss its very first call that's done by IO::CatHandle.new,
> since to give
>  you $*ARGFILES, .new has already been called.
> 
> Not sure what can be done about it, but I filed it as
> https://github.com/rakudo/rakudo/issues/1545 IO::CatHandle is not yet
> part of any
> language, so we have the ability to polish the rough edges.


Side note: it could be handy to be able to loop over IO::CatHandle's handles.
The OP code would just be:

for $*ARGFILES.handles -> $fh {
put "NEWFILE:";
put "$fh.path():$(++$) $_" for $fh.lines: 3;
}

Filed that as https://github.com/rakudo/rakudo/issues/1546

[perl #132885] .next-handle seems to change handles but doesn't

[Zoffix Znet via RT]

On Mon, 19 Feb 2018 19:48:30 -0800, c...@zoffix.com wrote:
> On Mon, 19 Feb 2018 16:15:37 -0800, comdog wrote:
> > #!/Users/brian/bin/perl6s/perl6-latest
> >
> > I'm playing with .next-handle from IO::CatHandle. I'm
> > trying to create a situation where I can read just the first five
> > lines from each command line argument:
> >
> > quietly {
> > my $limit = 5;
> > for lines() {
> > state $lines = 1;
> > FIRST { $*ARGFILES.on-switch = { put "NEW FILE"; $lines = 1 }
> > }
> > if $lines > $limit {
> > $*ARGFILES.next-handle;
> > next;
> > }
> > put "{$*ARGFILES.path}:{$lines++} $_";
> > }
> > }
> >
> > Here's a test file:
> >
> > First
> > Second
> > Third
> > Fourth
> > Fifth
> > Six
> > Seventh
> >
> > With one or more command-line arguments I get this odd behavior (and
> > lots of warnings that I suppressed):
> >
> > test.txt:1 First
> > test.txt:2 Second
> > test.txt:3 Third
> > test.txt:4 Fourth
> > test.txt:5 Fifth
> > NEW FILE
> > :1 Seventh
> > read bytes requires an object with REPR MVMOSHandle (got VMNull
> > with REPR Null)
> >   in block  at lines-method.p6 line 5
> >
> > It does "switch" after five lines, but then it keeps reading from the
> > same handle while losing a line. Then there's a strange error at the
> > end that kills the whole thing.
> >
> > I expected that it would close the current handle, open a new one,
> > and
> > continue. If it gets to the end, it would simply not provide any more
> > lines() and things would end normally.
> >
> > The docs for .next-handle lets you keep changing it as long as you
> > like no matter how many
> >
> > -
> >
> > This is Rakudo Star version 2018.01 built on MoarVM version 2018.01
> > implementing Perl 6.c.
> 
> 
> This is because current implementation of IO::CatHandle.lines simply
> flattens
> a gather/taken .lines Seq from each handle, so it never expects the
> handles to
> get switched before each .lines Seq is fully-consumed. The .next-
> handle closes
> the previous handle, which is where the weird error comes from (it
> tries to use
> the now-nulled $!PIO to .read/.eof from). Pretty sure .words is
> similarly affected.
> 
> I think if we give IO::CatHandle!LINES and IO::CatHandle!WORDS their
> own
> iterators that basically do the same thing as IO::Handle ones and then
> make
> .next-handle also toss the remaining data in the $!decoder, then the
> OP code
> would work.
> 
> In the meantime, you can use `.get` instead:
> 
> my $limit := 3;
> my $lines = 1;
> with $*ARGFILES -> $af {
> while ($_ := $af.get) !=:= Nil {
> $lines == 1 and put "NEWFILE:";
> put "$af.path():{$lines++} $_";
> next unless $lines > $limit;
> $af.next-handle and $lines = 1;
> }
> }
> 
> I also noticed another deficiency: when trying to set .on-switch on
> $*ARGFILES,
> you always miss its very first call that's done by IO::CatHandle.new,
> since to give
>  you $*ARGFILES, .new has already been called.
> 
> Not sure what can be done about it, but I filed it as
> https://github.com/rakudo/rakudo/issues/1545 IO::CatHandle is not yet
> part of any
> language, so we have the ability to polish the rough edges.


Side note: it could be handy to be able to loop over IO::CatHandle's handles.
The OP code would just be:

for $*ARGFILES.handles -> $fh {
put "NEWFILE:";
put "$fh.path():$(++$) $_" for $fh.lines: 3;
}

Filed that as https://github.com/rakudo/rakudo/issues/1546

[perl #132885] .next-handle seems to change handles but doesn't

[Zoffix Znet via RT]

On Mon, 19 Feb 2018 16:15:37 -0800, comdog wrote:
> #!/Users/brian/bin/perl6s/perl6-latest
> 
> I'm playing with .next-handle from IO::CatHandle. I'm
> trying to create a situation where I can read just the first five
> lines from each command line argument:
> 
> quietly {
> my $limit = 5;
> for lines() {
> state $lines = 1;
> FIRST { $*ARGFILES.on-switch = { put "NEW FILE"; $lines = 1 } }
> if $lines > $limit {
> $*ARGFILES.next-handle;
> next;
> }
> put "{$*ARGFILES.path}:{$lines++} $_";
> }
> }
> 
> Here's a test file:
> 
> First
> Second
> Third
> Fourth
> Fifth
> Six
> Seventh
> 
> With one or more command-line arguments I get this odd behavior (and
> lots of warnings that I suppressed):
> 
> test.txt:1 First
> test.txt:2 Second
> test.txt:3 Third
> test.txt:4 Fourth
> test.txt:5 Fifth
> NEW FILE
> :1 Seventh
> read bytes requires an object with REPR MVMOSHandle (got VMNull
> with REPR Null)
>   in block  at lines-method.p6 line 5
> 
> It does "switch" after five lines, but then it keeps reading from the
> same handle while losing a line. Then there's a strange error at the
> end that kills the whole thing.
> 
> I expected that it would close the current handle, open a new one, and
> continue. If it gets to the end, it would simply not provide any more
> lines() and things would end normally.
> 
> The docs for .next-handle lets you keep changing it as long as you
> like no matter how many
> 
> -
> 
> This is Rakudo Star version 2018.01 built on MoarVM version 2018.01
> implementing Perl 6.c.


This is because current implementation of IO::CatHandle.lines simply flattens
a gather/taken .lines Seq from each handle, so it never expects the handles to
get switched before each .lines Seq is fully-consumed. The .next-handle closes
the previous handle, which is where the weird error comes from (it tries to use
the now-nulled $!PIO to .read/.eof from). Pretty sure .words is similarly 
affected.

I think if we give IO::CatHandle!LINES and IO::CatHandle!WORDS their own
iterators that basically do the same thing as IO::Handle ones and then make
.next-handle also toss the remaining data in the $!decoder, then the OP code
would work.

In the meantime, you can use `.get` instead:

my $limit := 3;
my $lines = 1;
with $*ARGFILES -> $af {
while ($_ := $af.get) !=:= Nil {
$lines == 1 and put "NEWFILE:";
put "$af.path():{$lines++} $_";
next unless $lines > $limit;
$af.next-handle and $lines = 1;
}
}

I also noticed another deficiency: when trying to set .on-switch on $*ARGFILES,
you always miss its very first call that's done by IO::CatHandle.new, since to 
give
you $*ARGFILES, .new has already been called. 

Not sure what can be done about it, but I filed it as 
https://github.com/rakudo/rakudo/issues/1545 IO::CatHandle is not yet part of 
any
language, so we have the ability to polish the rough edges.

[perl #132885] .next-handle seems to change handles but doesn't

[Zoffix Znet via RT]

On Mon, 19 Feb 2018 16:15:37 -0800, comdog wrote:
> #!/Users/brian/bin/perl6s/perl6-latest
> 
> I'm playing with .next-handle from IO::CatHandle. I'm
> trying to create a situation where I can read just the first five
> lines from each command line argument:
> 
> quietly {
> my $limit = 5;
> for lines() {
> state $lines = 1;
> FIRST { $*ARGFILES.on-switch = { put "NEW FILE"; $lines = 1 } }
> if $lines > $limit {
> $*ARGFILES.next-handle;
> next;
> }
> put "{$*ARGFILES.path}:{$lines++} $_";
> }
> }
> 
> Here's a test file:
> 
> First
> Second
> Third
> Fourth
> Fifth
> Six
> Seventh
> 
> With one or more command-line arguments I get this odd behavior (and
> lots of warnings that I suppressed):
> 
> test.txt:1 First
> test.txt:2 Second
> test.txt:3 Third
> test.txt:4 Fourth
> test.txt:5 Fifth
> NEW FILE
> :1 Seventh
> read bytes requires an object with REPR MVMOSHandle (got VMNull
> with REPR Null)
>   in block  at lines-method.p6 line 5
> 
> It does "switch" after five lines, but then it keeps reading from the
> same handle while losing a line. Then there's a strange error at the
> end that kills the whole thing.
> 
> I expected that it would close the current handle, open a new one, and
> continue. If it gets to the end, it would simply not provide any more
> lines() and things would end normally.
> 
> The docs for .next-handle lets you keep changing it as long as you
> like no matter how many
> 
> -
> 
> This is Rakudo Star version 2018.01 built on MoarVM version 2018.01
> implementing Perl 6.c.


This is because current implementation of IO::CatHandle.lines simply flattens
a gather/taken .lines Seq from each handle, so it never expects the handles to
get switched before each .lines Seq is fully-consumed. The .next-handle closes
the previous handle, which is where the weird error comes from (it tries to use
the now-nulled $!PIO to .read/.eof from). Pretty sure .words is similarly 
affected.

I think if we give IO::CatHandle!LINES and IO::CatHandle!WORDS their own
iterators that basically do the same thing as IO::Handle ones and then make
.next-handle also toss the remaining data in the $!decoder, then the OP code
would work.

In the meantime, you can use `.get` instead:

my $limit := 3;
my $lines = 1;
with $*ARGFILES -> $af {
while ($_ := $af.get) !=:= Nil {
$lines == 1 and put "NEWFILE:";
put "$af.path():{$lines++} $_";
next unless $lines > $limit;
$af.next-handle and $lines = 1;
}
}

I also noticed another deficiency: when trying to set .on-switch on $*ARGFILES,
you always miss its very first call that's done by IO::CatHandle.new, since to 
give
you $*ARGFILES, .new has already been called. 

Not sure what can be done about it, but I filed it as 
https://github.com/rakudo/rakudo/issues/1545 IO::CatHandle is not yet part of 
any
language, so we have the ability to polish the rough edges.

[perl #132877] Confusing link to 'zef'

[Zoffix Znet via RT]

On Sat, 17 Feb 2018 12:55:45 -0800, lenw wrote:
> Rakudo Bug,
> 
> Please see a discussion of "more than one 'zef'"
>   at   .
> Bottom line is that  the link to 'zef' on your Rakudo Download page
> should be changed to 
> or  
> 
> Thanks,
> -LenW

Thanks.

Fixed on https://perl6.org/downloads/ (site will update in ~30m)
  on footer of https://perl6.org/ (site will update in ~30m)
  and on http://rakudo.org/how-to-get-rakudo/

[perl #132877] Confusing link to 'zef'

[Zoffix Znet via RT]

On Sat, 17 Feb 2018 12:55:45 -0800, lenw wrote:
> Rakudo Bug,
> 
> Please see a discussion of "more than one 'zef'"
>   at   .
> Bottom line is that  the link to 'zef' on your Rakudo Download page
> should be changed to 
> or  
> 
> Thanks,
> -LenW

Thanks.

Fixed on https://perl6.org/downloads/ (site will update in ~30m)
  on footer of https://perl6.org/ (site will update in ~30m)
  and on http://rakudo.org/how-to-get-rakudo/

[perl #132874] writing to utf16 handle gives write_fhb error

[Zoffix Znet via RT]

On Fri, 16 Feb 2018 00:56:27 -0800, comdog wrote:
> This little program:
> 
> my $fh = open 'test.txt', :w, :enc('utf16');
> put "filehandle is using {$fh.encoding}";
> $fh.put: 'Some text';
> 
> Gives this error:
> 
> filehandle is using utf16
> write_fhb requires a native array of uint8 or int8
> 
> 
> This is Rakudo Star version 2018.01 built on MoarVM version 2018.01
> implementing Perl 6.c


Looks like MoarVM doesn't fully support utf-16 yet (the exception is from 
MVM_io_read_bytes that just throws unless it's handed a 8-bit buf)

Slightly golfed version:

$ ./perl6 -e '"t.t".IO.open(:w :bin).write: utf16.new: 1, 2, 3'
write_fhb requires a native array of uint8 or int8
  in block  at -e line 1

$ ./perl6 -e '"t.t".IO.open(:w :bin).write: utf32.new: 1, 2, 3'
write_fhb requires a native array of uint8 or int8
  in block  at -e line 1

$ ./perl6 -e '"t.t".IO.open(:w :bin).write: buf32.new: 1, 2, 3'
write_fhb requires a native array of uint8 or int8
  in block  at -e line 1

Dies on read too, but with a more useful message:

$ ./perl6 -e '"LICENSE".IO.open(:enc).slurp.say'
Streaming decode NYI for encoding 4
  in block  at -e line 1

Works fine on JVM backend.

[perl #132874] writing to utf16 handle gives write_fhb error

[Zoffix Znet via RT]

On Fri, 16 Feb 2018 00:56:27 -0800, comdog wrote:
> This little program:
> 
> my $fh = open 'test.txt', :w, :enc('utf16');
> put "filehandle is using {$fh.encoding}";
> $fh.put: 'Some text';
> 
> Gives this error:
> 
> filehandle is using utf16
> write_fhb requires a native array of uint8 or int8
> 
> 
> This is Rakudo Star version 2018.01 built on MoarVM version 2018.01
> implementing Perl 6.c


Looks like MoarVM doesn't fully support utf-16 yet (the exception is from 
MVM_io_read_bytes that just throws unless it's handed a 8-bit buf)

Slightly golfed version:

$ ./perl6 -e '"t.t".IO.open(:w :bin).write: utf16.new: 1, 2, 3'
write_fhb requires a native array of uint8 or int8
  in block  at -e line 1

$ ./perl6 -e '"t.t".IO.open(:w :bin).write: utf32.new: 1, 2, 3'
write_fhb requires a native array of uint8 or int8
  in block  at -e line 1

$ ./perl6 -e '"t.t".IO.open(:w :bin).write: buf32.new: 1, 2, 3'
write_fhb requires a native array of uint8 or int8
  in block  at -e line 1

Dies on read too, but with a more useful message:

$ ./perl6 -e '"LICENSE".IO.open(:enc).slurp.say'
Streaming decode NYI for encoding 4
  in block  at -e line 1

Works fine on JVM backend.

[perl #130020] [RFC][@LARRY] Create a set of conventions to minimize impact internal changes to user's code

[Zoffix Znet via RT]

On Fri, 16 Feb 2018 05:52:09 -0800, elizabeth wrote:
> I propose we change all onlies in the core to multis after the release
> and see how this breaks things / makes things slower.

+1. Let's try.

[perl #130020] [RFC][@LARRY] Create a set of conventions to minimize impact internal changes to user's code

[Zoffix Znet via RT]

On Fri, 16 Feb 2018 05:52:09 -0800, elizabeth wrote:
> I propose we change all onlies in the core to multis after the release
> and see how this breaks things / makes things slower.

+1. Let's try.

[perl #130020] [RFC][@LARRY] Create a set of conventions to minimize impact internal changes to user's code

[Zoffix Znet via RT]

Spotted another case where there's impact: whether or not a routine is a multi 
can have large impact on user's code. For example here: 
https://stackoverflow.com/questions/48819031/where-did-my-perl-6-operator-go-after-i-defined-a-more-specific-multi/48827522

As part of conventions, we'd need to also figure out what we'll declare as 
multies and what as onlies.

[perl #130020] [RFC][@LARRY] Create a set of conventions to minimize impact internal changes to user's code

[Zoffix Znet via RT]

Spotted another case where there's impact: whether or not a routine is a multi 
can have large impact on user's code. For example here: 
https://stackoverflow.com/questions/48819031/where-did-my-perl-6-operator-go-after-i-defined-a-more-specific-multi/48827522

As part of conventions, we'd need to also figure out what we'll declare as 
multies and what as onlies.

[perl #130479] [BUG] Type coercion in signature gives warning on optional named arguments

[Zoffix Znet via RT]

On Wed, 17 Jan 2018 15:48:31 -0800, c...@zoffix.com wrote:
> On Sun, 01 Jan 2017 09:06:32 -0800, dougljenk...@gmail.com wrote:
> > I would expect this code to ignore the conversion of $foo if no value is
> > passed for it.
> > 
> > $ perl6 -e 'sub (Int(Cool) :$foo){}()'
> > 
> > Use of uninitialized value of type Cool in numeric context
> >   in sub  at -e line 1
> > 
> > IRC discussion: https://irclog.perlgeek.de/perl6/2017-01-01#i_13832608
> 
> 
> Thank you for the report. This is now fixed in branch `post-release`.
> 
> Fix:  https://github.com/rakudo/rakudo/commit/ae697080d2d5225
> Test: https://github.com/perl6/roast/commit/6457b4fab81809c5a


This has been reverted for now, in light of 
https://github.com/rakudo/rakudo/issues/1517
(and somewhat https://github.com/rakudo/rakudo/issues/1519 too)

We need to figure out how/whether handle the cases whether the two types of
the coercer aren't subclasses and I rather we don't push the original fix into
a release before we do that.

Keeping this Issue as resolved, with the problem being continued on 
https://github.com/rakudo/rakudo/issues/1517

[perl #130479] [BUG] Type coercion in signature gives warning on optional named arguments

[Zoffix Znet via RT]

On Wed, 17 Jan 2018 15:48:31 -0800, c...@zoffix.com wrote:
> On Sun, 01 Jan 2017 09:06:32 -0800, dougljenk...@gmail.com wrote:
> > I would expect this code to ignore the conversion of $foo if no value is
> > passed for it.
> > 
> > $ perl6 -e 'sub (Int(Cool) :$foo){}()'
> > 
> > Use of uninitialized value of type Cool in numeric context
> >   in sub  at -e line 1
> > 
> > IRC discussion: https://irclog.perlgeek.de/perl6/2017-01-01#i_13832608
> 
> 
> Thank you for the report. This is now fixed in branch `post-release`.
> 
> Fix:  https://github.com/rakudo/rakudo/commit/ae697080d2d5225
> Test: https://github.com/perl6/roast/commit/6457b4fab81809c5a


This has been reverted for now, in light of 
https://github.com/rakudo/rakudo/issues/1517
(and somewhat https://github.com/rakudo/rakudo/issues/1519 too)

We need to figure out how/whether handle the cases whether the two types of
the coercer aren't subclasses and I rather we don't push the original fix into
a release before we do that.

Keeping this Issue as resolved, with the problem being continued on 
https://github.com/rakudo/rakudo/issues/1517

[perl #125618] [REGEX] Positional capture of separator on ?% operator causes compiler error

[Zoffix Znet via RT]

On Wed, 15 Jul 2015 07:31:55 -0700, lue wrote:
>  m: say "ab" ~~ /^ a +% (b) $/
>  rakudo-moar e4077e: OUTPUT«Nil␤»
>  m: say "ab" ~~ /^ a *% (b) $/
>  rakudo-moar e4077e: OUTPUT«Nil␤»
>  m: say "ab" ~~ /^ a ?% (b) $/
>  rakudo-moar e4077e: OUTPUT«===SORRY!===␤QAST::Block with
> cuid cuid_1_1436969557.11546 has not appeared␤»
> 
> On JVM:
> 
>  j: say "ab" ~~ /^ a ?% (b) $/
>  rakudo-jvm e4077e: OUTPUT«===SORRY!===␤setcodeobj can only
> be used with a CodeRef␤»
> 
> And just to show that it's not just the ?% operator alone contributing
> to the issue, but the capture too:
> 
>  m: say "ab" ~~ /^ a ?% [b] $/
>  rakudo-moar e4077e: OUTPUT«Nil␤»


Made potential fix in branches in 
https://github.com/perl6/nqp/commit/ac3d5307f3 and 
https://github.com/perl6/roast/commit/f2b07afbba

The fix is to throw on `?`/`??` quantifiers used with `%`/`%%`.

It's blocked by 2 lines of 6.c tests that indirectly use this combination: 
https://github.com/perl6/roast/commit/aaa71d077431cd0a86be84bd386e1032a12e8697#diff-ae7b47444302486e790af6ee18121fabR16
 

I delegated it to the release manager whether to merge that stuff or to require 
a fix that leaves these working and then we fix the compilation error itself.

[perl #125618] [REGEX] Positional capture of separator on ?% operator causes compiler error

[Zoffix Znet via RT]

On Wed, 15 Jul 2015 07:31:55 -0700, lue wrote:
>  m: say "ab" ~~ /^ a +% (b) $/
>  rakudo-moar e4077e: OUTPUT«Nil␤»
>  m: say "ab" ~~ /^ a *% (b) $/
>  rakudo-moar e4077e: OUTPUT«Nil␤»
>  m: say "ab" ~~ /^ a ?% (b) $/
>  rakudo-moar e4077e: OUTPUT«===SORRY!===␤QAST::Block with
> cuid cuid_1_1436969557.11546 has not appeared␤»
> 
> On JVM:
> 
>  j: say "ab" ~~ /^ a ?% (b) $/
>  rakudo-jvm e4077e: OUTPUT«===SORRY!===␤setcodeobj can only
> be used with a CodeRef␤»
> 
> And just to show that it's not just the ?% operator alone contributing
> to the issue, but the capture too:
> 
>  m: say "ab" ~~ /^ a ?% [b] $/
>  rakudo-moar e4077e: OUTPUT«Nil␤»


Made potential fix in branches in 
https://github.com/perl6/nqp/commit/ac3d5307f3 and 
https://github.com/perl6/roast/commit/f2b07afbba

The fix is to throw on `?`/`??` quantifiers used with `%`/`%%`.

It's blocked by 2 lines of 6.c tests that indirectly use this combination: 
https://github.com/perl6/roast/commit/aaa71d077431cd0a86be84bd386e1032a12e8697#diff-ae7b47444302486e790af6ee18121fabR16
 

I delegated it to the release manager whether to merge that stuff or to require 
a fix that leaves these working and then we fix the compilation error itself.

[perl #128880] [BUG] Dead code in HyperWhatever, ｢.new｣ is not supposed to work but it does (HyperWhatever.new)

[Zoffix Znet via RT]

On Tue, 09 Aug 2016 15:25:11 -0700, alex.jakime...@gmail.com wrote:
> Let's look at the code in Rakudo! From src/core/Whatever.pm
> 
> my class HyperWhatever {
> multi method new(HyperWhatever:) { X::Cannot::New.new(class =>
> self).throw }
> …
> }
> 
> So it seems like it should throw a warning if we try to create a
> HyperWhatever
> object, right? Let's see!
> 
> Code:
> say HyperWhatever.new
> 
> Result:
> sub (*@_) { #`(Sub|54745104) ... }
> 
> 
> Apparently, the code in “.new” method of Whatever.pm is not being
> reached.


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/57a1aa7a87
Test: https://github.com/perl6/roast/commit/dbe43e171d7a


On Thu, 11 Aug 2016 20:41:53 -0700, c...@zoffix.com wrote:
> Bizarrely, SourceBaby points to the right place, so I don't get why it
> doesn't work:
> https://github.com/rakudo/rakudo/blob/c587b9d/src/core/Whatever.pm#L10

On Sun, 18 Dec 2016 13:18:36 -0800, c...@zoffix.com wrote:
> No idea if there's any easy way to make it DTRT, so I'm going to leave
> this for someone else...

It's OK, 2016-Zoffix. I got your back, bruh.
Took me like 3 minutes to figure out the fix.

[perl #128880] [BUG] Dead code in HyperWhatever, ｢.new｣ is not supposed to work but it does (HyperWhatever.new)

[Zoffix Znet via RT]

On Tue, 09 Aug 2016 15:25:11 -0700, alex.jakime...@gmail.com wrote:
> Let's look at the code in Rakudo! From src/core/Whatever.pm
> 
> my class HyperWhatever {
> multi method new(HyperWhatever:) { X::Cannot::New.new(class =>
> self).throw }
> …
> }
> 
> So it seems like it should throw a warning if we try to create a
> HyperWhatever
> object, right? Let's see!
> 
> Code:
> say HyperWhatever.new
> 
> Result:
> sub (*@_) { #`(Sub|54745104) ... }
> 
> 
> Apparently, the code in “.new” method of Whatever.pm is not being
> reached.


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/57a1aa7a87
Test: https://github.com/perl6/roast/commit/dbe43e171d7a


On Thu, 11 Aug 2016 20:41:53 -0700, c...@zoffix.com wrote:
> Bizarrely, SourceBaby points to the right place, so I don't get why it
> doesn't work:
> https://github.com/rakudo/rakudo/blob/c587b9d/src/core/Whatever.pm#L10

On Sun, 18 Dec 2016 13:18:36 -0800, c...@zoffix.com wrote:
> No idea if there's any easy way to make it DTRT, so I'm going to leave
> this for someone else...

It's OK, 2016-Zoffix. I got your back, bruh.
Took me like 3 minutes to figure out the fix.

[perl #132846] [Bug] Directive d not applicable for type Int

[Zoffix Znet via RT]

On Sat, 10 Feb 2018 11:38:50 -0800, juhimar...@gmail.com wrote:
> Hi,
> 
> When an Int variable gets undefined, lets say $i, then $i.fmt('%d') 
> throws a message 'Directive d not applicable for type Int'.
> 
> The message is not ok because %d is applicable! %f throws the same error 
> but %s does some conversion and throws the proper messages about 
> uninitialized values.
> 
> Secondly, it lacks a line number and stack dump. Same for %f but not for %s.
> 
> I haven't tested other directives.
> 
> Regards,
> Marcel
> 
> This is Rakudo version 2018.01-171-gc38764c61 built on MoarVM version 
> 2018.01-82-g296620e86 implementing Perl 6.c.


Thank you for the report. This is now fixed

Fixes: https://github.com/perl6/nqp/commit/2c51764e93
   https://github.com/rakudo/rakudo/commit/d419afe462
   https://github.com/rakudo/rakudo/commit/4ac67e7384
   https://github.com/rakudo/rakudo/commit/684b99eaa8
   https://github.com/rakudo/rakudo/commit/13406517ad
Tests: https://github.com/perl6/roast/commit/ceed491adb
   https://github.com/rakudo/rakudo/commit/13406517ad

[perl #132846] [Bug] Directive d not applicable for type Int

[Zoffix Znet via RT]

On Sat, 10 Feb 2018 11:38:50 -0800, juhimar...@gmail.com wrote:
> Hi,
> 
> When an Int variable gets undefined, lets say $i, then $i.fmt('%d') 
> throws a message 'Directive d not applicable for type Int'.
> 
> The message is not ok because %d is applicable! %f throws the same error 
> but %s does some conversion and throws the proper messages about 
> uninitialized values.
> 
> Secondly, it lacks a line number and stack dump. Same for %f but not for %s.
> 
> I haven't tested other directives.
> 
> Regards,
> Marcel
> 
> This is Rakudo version 2018.01-171-gc38764c61 built on MoarVM version 
> 2018.01-82-g296620e86 implementing Perl 6.c.


Thank you for the report. This is now fixed

Fixes: https://github.com/perl6/nqp/commit/2c51764e93
   https://github.com/rakudo/rakudo/commit/d419afe462
   https://github.com/rakudo/rakudo/commit/4ac67e7384
   https://github.com/rakudo/rakudo/commit/684b99eaa8
   https://github.com/rakudo/rakudo/commit/13406517ad
Tests: https://github.com/perl6/roast/commit/ceed491adb
   https://github.com/rakudo/rakudo/commit/13406517ad

[perl #105872] [BUG] 42, 44, 22 -> *@a { say @a.perl }

[Zoffix Znet via RT]

On Sat, 10 Dec 2011 18:37:03 -0800, jimmy.z...@gmail.com wrote:
> JimmyZ> nom: if 42 -> *@_ { say @_.perl }
> p6eval> nom 1f9310: OUTPUT«Array.new()␤»
> 
> JimmyZ> niecza: if 42, 44, 22 -> *@a { say @a.perl }
> p6eval> niecza v12-10-ga8ad0e9: OUTPUT«(42, 44, 22)␤»
> 
> JimmyZ>nom: if 42, 44, 22 -> *@a { say @a.perl }
> p6eval>nom 1f9310: OUTPUT«Array.new()␤»
> 
> jnthn> JimmyZ: oh, oddness...
> jnthn> JimmyZ: Anyway, I can probably fix it. Feel free to submit a ticket.
> 
> JimmyZ> nom: while 42, 44, 22 -> *@a { say @a.perl; last }
> p6eval> nom 70d715: OUTPUT«Array.new()␤»
> JimmyZ> niecza: while 42, 44, 22 -> *@a { say @a.perl; last }
> p6eval> niecza v12-11-g20a790d: OUTPUT«(42, 44, 22)␤»
> 

Thank you for the report. This is now fixed.

Fix:  https://github.com/perl6/nqp/commit/8e7201eb64
  https://github.com/rakudo/rakudo/commit/dfb6d951d7
  https://github.com/rakudo/rakudo/commit/ef1d22f4c1
Test: https://github.com/perl6/roast/commit/aa90737df1


On Mon, 11 Jan 2016 18:43:32 -0800, awwaiid wrote:
> Putting parens around the signature makes it work:
> 
> $ perl6 -e 'while 42, 44, 22 -> (*@a) { say @a.perl; last }'
> [42, 44, 22]
> 
> $ perl6 -e 'if 42, 44, 22 -> (*@a) { say @a.perl }'
> [42, 44, 22]
> 
> I don't know if the parenthesis SHOULD be required or not.

No, with parentheses you're taking a single positional arg and then unpacking 
its Capture.

[perl #105872] [BUG] 42, 44, 22 -> *@a { say @a.perl }

[Zoffix Znet via RT]

On Sat, 10 Dec 2011 18:37:03 -0800, jimmy.z...@gmail.com wrote:
> JimmyZ> nom: if 42 -> *@_ { say @_.perl }
> p6eval> nom 1f9310: OUTPUT«Array.new()␤»
> 
> JimmyZ> niecza: if 42, 44, 22 -> *@a { say @a.perl }
> p6eval> niecza v12-10-ga8ad0e9: OUTPUT«(42, 44, 22)␤»
> 
> JimmyZ>nom: if 42, 44, 22 -> *@a { say @a.perl }
> p6eval>nom 1f9310: OUTPUT«Array.new()␤»
> 
> jnthn> JimmyZ: oh, oddness...
> jnthn> JimmyZ: Anyway, I can probably fix it. Feel free to submit a ticket.
> 
> JimmyZ> nom: while 42, 44, 22 -> *@a { say @a.perl; last }
> p6eval> nom 70d715: OUTPUT«Array.new()␤»
> JimmyZ> niecza: while 42, 44, 22 -> *@a { say @a.perl; last }
> p6eval> niecza v12-11-g20a790d: OUTPUT«(42, 44, 22)␤»
> 

Thank you for the report. This is now fixed.

Fix:  https://github.com/perl6/nqp/commit/8e7201eb64
  https://github.com/rakudo/rakudo/commit/dfb6d951d7
  https://github.com/rakudo/rakudo/commit/ef1d22f4c1
Test: https://github.com/perl6/roast/commit/aa90737df1


On Mon, 11 Jan 2016 18:43:32 -0800, awwaiid wrote:
> Putting parens around the signature makes it work:
> 
> $ perl6 -e 'while 42, 44, 22 -> (*@a) { say @a.perl; last }'
> [42, 44, 22]
> 
> $ perl6 -e 'if 42, 44, 22 -> (*@a) { say @a.perl }'
> [42, 44, 22]
> 
> I don't know if the parenthesis SHOULD be required or not.

No, with parentheses you're taking a single positional arg and then unpacking 
its Capture.

[perl #131496] [BUG] Failure.perl doesn't roundrip `handled` flag

[Zoffix Znet via RT]

On Sat, 03 Jun 2017 04:35:14 -0700, c...@zoffix.com wrote:
> Handled Failures are explosive again, if they're .perl'ed:
> 
>  m: given Failure.new { .so; .handled.say;
> .perl.EVAL.handled.say }
>  rakudo-moar 61ecfd: OUTPUT: «True␤False␤»
> 
> Perhaps the `handled` flag should be a public attribute, settable via
> new?


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/b2a21fa96538e2f
Test: https://github.com/perl6/roast/commit/9625f78f3e925aa5d

[perl #131496] [BUG] Failure.perl doesn't roundrip `handled` flag

[Zoffix Znet via RT]

On Sat, 03 Jun 2017 04:35:14 -0700, c...@zoffix.com wrote:
> Handled Failures are explosive again, if they're .perl'ed:
> 
>  m: given Failure.new { .so; .handled.say;
> .perl.EVAL.handled.say }
>  rakudo-moar 61ecfd: OUTPUT: «True␤False␤»
> 
> Perhaps the `handled` flag should be a public attribute, settable via
> new?


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/b2a21fa96538e2f
Test: https://github.com/perl6/roast/commit/9625f78f3e925aa5d

[perl #131617] [BUG] Any.tail(Callable) violates Iterator protocol

[Zoffix Znet via RT]

On Wed, 21 Jun 2017 11:46:46 -0700, c...@zoffix.com wrote:
> The "Died" message should never occur:
> 
> m: my $s = Seq.new: class :: does Iterator { has @!stuff = ;
> has $!ded = 1; method pull-one { $!ded or die; @!stuff ?? shift
> @!stuff !! $!ded-- && IterationEnd } }.new; say $s.tail: *-10
> rakudo-moar 86e7b2: OUTPUT: «Died␤  in method pull-one at  line
> 1␤  in block  at  line 1␤␤»
> 
> Looks like a check that .skip-at-least was successful is missing[^1].
> 
> [1]
> https://github.com/rakudo/rakudo/blob/86e7b2bd25ed62ecd93d83a49b6e2cbfeeb1c24c/src/core/Any-
> iterable-methods.pm#L1889-L1890
> [2]
> https://github.com/rakudo/rakudo/blob/86e7b2bd25ed62ecd93d83a49b6e2cbfeeb1c24c/src/core/List.pm#L1289-
> L1298


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/2cc7b6317e98592
Test: https://github.com/perl6/roast/commit/3e60598fea0d92307

[perl #131617] [BUG] Any.tail(Callable) violates Iterator protocol

[Zoffix Znet via RT]

On Wed, 21 Jun 2017 11:46:46 -0700, c...@zoffix.com wrote:
> The "Died" message should never occur:
> 
> m: my $s = Seq.new: class :: does Iterator { has @!stuff = ;
> has $!ded = 1; method pull-one { $!ded or die; @!stuff ?? shift
> @!stuff !! $!ded-- && IterationEnd } }.new; say $s.tail: *-10
> rakudo-moar 86e7b2: OUTPUT: «Died␤  in method pull-one at  line
> 1␤  in block  at  line 1␤␤»
> 
> Looks like a check that .skip-at-least was successful is missing[^1].
> 
> [1]
> https://github.com/rakudo/rakudo/blob/86e7b2bd25ed62ecd93d83a49b6e2cbfeeb1c24c/src/core/Any-
> iterable-methods.pm#L1889-L1890
> [2]
> https://github.com/rakudo/rakudo/blob/86e7b2bd25ed62ecd93d83a49b6e2cbfeeb1c24c/src/core/List.pm#L1289-
> L1298


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/2cc7b6317e98592
Test: https://github.com/perl6/roast/commit/3e60598fea0d92307

[perl #130431] [REGRESSION] Subclassing an Int no longer works flawlessly (my Foo $a .= new(42))

[Zoffix Znet via RT]

On Thu, 29 Dec 2016 19:26:07 -0800, alex.jakime...@gmail.com wrote:
> Another case:
> 
> class MyInt is Int { method even(){ self %% 2 } }; say [1..4].map({
> MyInt.new($_) }).grep({.even})
> 
> 
> Seems like it is a common thing to try, but I'm not going to say that
> it should
> work. Maybe it should throw a warning or something? If the warning can
> give
> clear instructions on how to do this kind of stuff, then I'd say we
> provided
> enough cakes.
> 
> On 2016-12-28 18:58:00, alex.jakime...@gmail.com wrote:
> > Code:
> > class Mebibytes is Int { method Str { (self/1024/1024).Int ~ "M" } };
> > my Mebibytes $a .= new(183456783); $a.say; # fancy enough?
> >
> >
> > Result (2016.09):
> > 174M
> >
> >
> > Result (HEAD):
> > Type check failed in assignment to $a; expected Mebibytes but got Int
> > (183456783)
> > in block  at /tmp/4Vz0jddWQp line 1
> >
> >
> > Bisectable points to
> >
> https://github.com/rakudo/rakudo/commit/798c2e2dca34e5cf93da99d1f401eb161efca854
> >
> >
> >  AlexDaniel, please rakudobug it. I'll take a look tomorrow.
> > At least half of
> >
> https://github.com/rakudo/rakudo/commit/798c2e2dca34e5cf93da99d1f401eb161efca854
> > is wrong, because that comment lies; it doesn't give a "decoupled"
> > Int

This was already fixed awhile back and I'm 100% sure there are tests covering 
the issue as well (this was around when nqp::fromI_I was being introed to fix 
constant caching here)

[perl #130431] [REGRESSION] Subclassing an Int no longer works flawlessly (my Foo $a .= new(42))

[Zoffix Znet via RT]

On Thu, 29 Dec 2016 19:26:07 -0800, alex.jakime...@gmail.com wrote:
> Another case:
> 
> class MyInt is Int { method even(){ self %% 2 } }; say [1..4].map({
> MyInt.new($_) }).grep({.even})
> 
> 
> Seems like it is a common thing to try, but I'm not going to say that
> it should
> work. Maybe it should throw a warning or something? If the warning can
> give
> clear instructions on how to do this kind of stuff, then I'd say we
> provided
> enough cakes.
> 
> On 2016-12-28 18:58:00, alex.jakime...@gmail.com wrote:
> > Code:
> > class Mebibytes is Int { method Str { (self/1024/1024).Int ~ "M" } };
> > my Mebibytes $a .= new(183456783); $a.say; # fancy enough?
> >
> >
> > Result (2016.09):
> > 174M
> >
> >
> > Result (HEAD):
> > Type check failed in assignment to $a; expected Mebibytes but got Int
> > (183456783)
> > in block  at /tmp/4Vz0jddWQp line 1
> >
> >
> > Bisectable points to
> >
> https://github.com/rakudo/rakudo/commit/798c2e2dca34e5cf93da99d1f401eb161efca854
> >
> >
> >  AlexDaniel, please rakudobug it. I'll take a look tomorrow.
> > At least half of
> >
> https://github.com/rakudo/rakudo/commit/798c2e2dca34e5cf93da99d1f401eb161efca854
> > is wrong, because that comment lies; it doesn't give a "decoupled"
> > Int

This was already fixed awhile back and I'm 100% sure there are tests covering 
the issue as well (this was around when nqp::fromI_I was being introed to fix 
constant caching here)

[perl #130748] [BUG] weird error when accessing an attribute from a "where" of another attribute

[Zoffix Znet via RT]

On Wed, 08 Feb 2017 17:04:56 -0800, fernandocor...@gmail.com wrote:
> I’m getting a "VMNull type object” error when I try to access an
> attribute from the “where” of another attribute.
> 
> https://irclog.perlgeek.de/perl6/2017-02-09#i_14068796
> 
> 
>  Fernando Corrêa de Oliveira m: class C { has Int $.a =
> 42; has Str $.b where $!a }; say C.new : :b<42> #
> should it die with this error?
> 22:32 C<•camelia> rakudo-moar f85978: OUTPUT«Cannot look up attributes
> in a VMNull type object␤  in block  at  line 1␤␤»
> 22:32 S Fernando Corrêa de Oliveira m: class C { has Int
> $.a = 42; has Str $.b where $!a }; say C.new : :42b
> 22:32 C<•camelia> rakudo-moar f85978: OUTPUT«Type check failed in
> assignment to $!b; expected  but got Int (42)␤  in block 
> at  line 1␤␤»
> 22:33 S Fernando Corrêa de Oliveira m: class C { has Int
> $.a = 42; has Str $.b where $!a }; say C.new.a
> 22:33 C<•camelia> rakudo-moar f85978: OUTPUT«42␤»
>   22:33 → pierrot joined  ↔ pyrimidine popped in  ↔ Ven nipped out
> 22:47 S Fernando Corrêa de Oliveira m: class C { has Int
> $.a = 42; has Str $.b where $!a }; say C.new : :42a
> :42b
> 22:47 C<•camelia> rakudo-moar f85978: OUTPUT«Type check failed in
> assignment to $!b; expected  but got Int (42)␤  in block 
> at  line 1␤␤»
> 22:47 S Fernando Corrêa de Oliveira m: class C { has Int
> $.a = 42; has Int $.b where $!a }; say C.new : :42a
> :42b
> 22:47 C<•camelia> rakudo-moar f85978: OUTPUT«Cannot look up attributes
> in a VMNull type object␤  in block  at  line 1␤␤»


Thank you for the report. This is now fixed. Specifically, it now throws a 
useful error,
saying `self` is now available inside such a `where` clause.

Fix: https://github.com/rakudo/rakudo/commit/1c894e418d
Test: https://github.com/perl6/roast/commit/410a3982c5

[perl #130748] [BUG] weird error when accessing an attribute from a "where" of another attribute

[Zoffix Znet via RT]

On Wed, 08 Feb 2017 17:04:56 -0800, fernandocor...@gmail.com wrote:
> I’m getting a "VMNull type object” error when I try to access an
> attribute from the “where” of another attribute.
> 
> https://irclog.perlgeek.de/perl6/2017-02-09#i_14068796
> 
> 
>  Fernando Corrêa de Oliveira m: class C { has Int $.a =
> 42; has Str $.b where $!a }; say C.new : :b<42> #
> should it die with this error?
> 22:32 C<•camelia> rakudo-moar f85978: OUTPUT«Cannot look up attributes
> in a VMNull type object␤  in block  at  line 1␤␤»
> 22:32 S Fernando Corrêa de Oliveira m: class C { has Int
> $.a = 42; has Str $.b where $!a }; say C.new : :42b
> 22:32 C<•camelia> rakudo-moar f85978: OUTPUT«Type check failed in
> assignment to $!b; expected  but got Int (42)␤  in block 
> at  line 1␤␤»
> 22:33 S Fernando Corrêa de Oliveira m: class C { has Int
> $.a = 42; has Str $.b where $!a }; say C.new.a
> 22:33 C<•camelia> rakudo-moar f85978: OUTPUT«42␤»
>   22:33 → pierrot joined  ↔ pyrimidine popped in  ↔ Ven nipped out
> 22:47 S Fernando Corrêa de Oliveira m: class C { has Int
> $.a = 42; has Str $.b where $!a }; say C.new : :42a
> :42b
> 22:47 C<•camelia> rakudo-moar f85978: OUTPUT«Type check failed in
> assignment to $!b; expected  but got Int (42)␤  in block 
> at  line 1␤␤»
> 22:47 S Fernando Corrêa de Oliveira m: class C { has Int
> $.a = 42; has Int $.b where $!a }; say C.new : :42a
> :42b
> 22:47 C<•camelia> rakudo-moar f85978: OUTPUT«Cannot look up attributes
> in a VMNull type object␤  in block  at  line 1␤␤»


Thank you for the report. This is now fixed. Specifically, it now throws a 
useful error,
saying `self` is now available inside such a `where` clause.

Fix: https://github.com/rakudo/rakudo/commit/1c894e418d
Test: https://github.com/perl6/roast/commit/410a3982c5