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

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

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]. >

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

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]. >

[perl #127933] [REPL] int# bug

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

[perl #127933] [REPL] int# bug

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

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

> 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

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

> 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

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

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

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

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

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

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

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

[perl #133246] Possible bug in Perl 6 OO

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

[perl #133268] MoarVM with empty CONTROL {}

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 > >

[perl #133268] MoarVM with empty CONTROL {}

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 > >

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

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

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'

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'

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'

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

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

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

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

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

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 > >

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

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 > >

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

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

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

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

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

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 >

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

[perl #128624] Buf initialization error

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

[perl #128624] Buf initialization error

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

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

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 >

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

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 >

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

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

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

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

[perl #132268] [MATH] Floating point anomalies

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 >

[perl #132268] [MATH] Floating point anomalies

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 >

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

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 > >

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

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 > >

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

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

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

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

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

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 > > > > > >

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

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 > > > > > >

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

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:

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

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:

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

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)␤»

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

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)␤»

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

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

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)

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)

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

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

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

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: >

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

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: >

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

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

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

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

[perl #128520] [META][RT][RFC] Consider migrating from 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

[perl #128520] [META][RT][RFC] Consider migrating from 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

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

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. > >

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

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. > >

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

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 > > (

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

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 > > (

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

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

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

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

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

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

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

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

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

[perl #132877] Confusing link to 'zef'

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

[perl #132877] Confusing link to 'zef'

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ->

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

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 ->

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

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

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

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

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

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 >

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

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 >

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

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

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

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

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

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 {

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

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 {

  1   2   3   4   5   6   7   8   9   10   >