[perl #116595] [BUG] Nesting wrapping roles bind 'callsame' to the wrong recipient in Rakudo

[Will Coleda via RT]

On Wed, 30 Jan 2013 07:17:38 -0800, masak wrote:
>  rn: role F[$n] { method x { callsame; callsame until $.v % $n } 
> }; class S { has $.v is rw = 1; method x { ++$.v } }; my $s = S.new; for 
> ^3 { $s.x; say $s.v; $s = $s but F[$s.v] }
>  niecza v24-18-gaf64300: OUTPUT«2␤3␤5␤»
>  ..rakudo b3fc32: OUTPUT«(timeout)2␤3␤»
>  jnthn: this is as short as I'm able to golf it.
>  jnthn: the problem happens in the 'callsame' in the 'until' loop, 
> and the .x method in the S object never gets triggered. or rather, it 
> gets triggered in Niecza, but it gets waylaid in Rakudo.

Unchanged behavior in 2018.05-55-g95aa77c94
-- 
Will "Coke" Coleda

[perl #116595] [BUG] Nesting wrapping roles bind 'callsame' to the wrong recipient in Rakudo

[Will Coleda via RT]

On Wed, 30 Jan 2013 07:17:38 -0800, masak wrote:
>  rn: role F[$n] { method x { callsame; callsame until $.v % $n } 
> }; class S { has $.v is rw = 1; method x { ++$.v } }; my $s = S.new; for 
> ^3 { $s.x; say $s.v; $s = $s but F[$s.v] }
>  niecza v24-18-gaf64300: OUTPUT«2␤3␤5␤»
>  ..rakudo b3fc32: OUTPUT«(timeout)2␤3␤»
>  jnthn: this is as short as I'm able to golf it.
>  jnthn: the problem happens in the 'callsame' in the 'until' loop, 
> and the .x method in the S object never gets triggered. or rather, it 
> gets triggered in Niecza, but it gets waylaid in Rakudo.

Unchanged behavior in 2018.05-55-g95aa77c94
-- 
Will "Coke" Coleda

[perl #124998] [BUG] Type of $¢ is Any instead of Cursor

[Will Coleda via RT]

On Wed, 27 Jul 2016 12:29:11 -0700, coke wrote:
> Here's the test:
> 
> my $c;
> ok 'abc' ~~ /.{ $c = $¢ }/, 'current match state';
> #?rakudo todo 'Type of $¢ is Any instead of Cursor - RT #124998'
> is $c.WHAT, Cursor.WHAT,'got right type';
> 
> This might be a faulty test, however:
> 
> 19:28 < [Coke]> m: my $c; 'abc' ~~ /.{ say $¢.WHAT }/ ;
> 19:28 < camelia> rakudo-moar f0abe8: OUTPUT«Nil␤»
> 
> If the $¢ assignment in there is Nil, then $c is *going* to default to Any. 

This appears to be fixed; there's a test in roast (which I've re-added the RT # 
to), closing ticket.
-- 
Will "Coke" Coleda

[perl #124998] [BUG] Type of $¢ is Any instead of Cursor

[Will Coleda via RT]

On Wed, 27 Jul 2016 12:29:11 -0700, coke wrote:
> Here's the test:
> 
> my $c;
> ok 'abc' ~~ /.{ $c = $¢ }/, 'current match state';
> #?rakudo todo 'Type of $¢ is Any instead of Cursor - RT #124998'
> is $c.WHAT, Cursor.WHAT,'got right type';
> 
> This might be a faulty test, however:
> 
> 19:28 < [Coke]> m: my $c; 'abc' ~~ /.{ say $¢.WHAT }/ ;
> 19:28 < camelia> rakudo-moar f0abe8: OUTPUT«Nil␤»
> 
> If the $¢ assignment in there is Nil, then $c is *going* to default to Any. 

This appears to be fixed; there's a test in roast (which I've re-added the RT # 
to), closing ticket.
-- 
Will "Coke" Coleda

[perl #132349] [REGRESSION] $*IN.getc not blocking on macOS

[Will Coleda via RT]

On Sun, 22 Oct 2017 12:25:07 -0700, b...@post.pl wrote:
> There is no strace on macOS, I used dtruss (dtrace):
> 
> $ dtruss -p 1827
> SYSCALL(args)  = return
> fstat64(0x0, 0x7FFF5B18B2F0, 0x1)  = 0 0
> lseek(0x0, 0x0, 0x1)   = 54132 0
> write(0x1, "Nil\n\0", 0x4) = 4 0
> thread_selfid(0x0, 0x7F8252ED2090, 0x4)= 24710 0
> 
> 
> 

This behavior changed on 
https://github.com/rakudo/rakudo/commit/80bbfcdd47bcb27c21352a53a5156a6ecdd41e65

commit 80bbfcdd47bcb27c21352a53a5156a6ecdd41e65
Author: Jonathan Worthington 
Date:   Fri Jul 14 14:24:13 2017 +0200

Use same slow-path for getc and readchars.

This will allow fixing the common problem they have near the end of
the file in one place, as well as giving less code to maintain.


IRC chat noted the behavior of

perl6 -e '$*IN.eof.say' 

Is different on OS X and other platforms (True on mac, False elsewhere)

-- 
Will "Coke" Coleda

[perl #132349] [REGRESSION] $*IN.getc not blocking on macOS

[Will Coleda via RT]

On Sun, 22 Oct 2017 12:25:07 -0700, b...@post.pl wrote:
> There is no strace on macOS, I used dtruss (dtrace):
> 
> $ dtruss -p 1827
> SYSCALL(args)  = return
> fstat64(0x0, 0x7FFF5B18B2F0, 0x1)  = 0 0
> lseek(0x0, 0x0, 0x1)   = 54132 0
> write(0x1, "Nil\n\0", 0x4) = 4 0
> thread_selfid(0x0, 0x7F8252ED2090, 0x4)= 24710 0
> 
> 
> 

This behavior changed on 
https://github.com/rakudo/rakudo/commit/80bbfcdd47bcb27c21352a53a5156a6ecdd41e65

commit 80bbfcdd47bcb27c21352a53a5156a6ecdd41e65
Author: Jonathan Worthington 
Date:   Fri Jul 14 14:24:13 2017 +0200

Use same slow-path for getc and readchars.

This will allow fixing the common problem they have near the end of
the file in one place, as well as giving less code to maintain.


IRC chat noted the behavior of

perl6 -e '$*IN.eof.say' 

Is different on OS X and other platforms (True on mac, False elsewhere)

-- 
Will "Coke" Coleda

[perl #132108] [REGRESSION] Test output should not be buffered even for non-TTYs (prove -j 8 …)

[Will Coleda via RT]

See https://rt.cpan.org/Public/Bug/Display.html?id=108390 which was mentioned 
here: 

https://irclog.perlgeek.de/perl6/2017-09-13#i_15159739
-- 
Will "Coke" Coleda

[perl #132108] [REGRESSION] Test output should not be buffered even for non-TTYs (prove -j 8 …)

[Will Coleda via RT]

See https://rt.cpan.org/Public/Bug/Display.html?id=108390 which was mentioned 
here: 

https://irclog.perlgeek.de/perl6/2017-09-13#i_15159739
-- 
Will "Coke" Coleda

[perl #129878] [BUG][UNI] Stringifying a List adds in spaces between each item

[Will Coleda via RT]

On Fri, 14 Oct 2016 11:06:54 -0700, c...@cpan.org wrote:
> Cf
> 
> say ("\c[REGIONAL INDICATOR SYMBOL LETTER G]" x 2).chars #=> 2
> 
> vs
> 
> say ([~] "\c[REGIONAL INDICATOR SYMBOL LETTER G]" xx 2).chars #=> 1
> 

With a recent rakudo, these now both output 1

> say ("\c[REGIONAL INDICATOR SYMBOL LETTER G]" x 2).chars
1
> say ([~] "\c[REGIONAL INDICATOR SYMBOL LETTER G]" xx 2).chars
1
>

-- 
Will "Coke" Coleda

[perl #129878] [BUG][UNI] Stringifying a List adds in spaces between each item

[Will Coleda via RT]

On Fri, 14 Oct 2016 11:06:54 -0700, c...@cpan.org wrote:
> Cf
> 
> say ("\c[REGIONAL INDICATOR SYMBOL LETTER G]" x 2).chars #=> 2
> 
> vs
> 
> say ([~] "\c[REGIONAL INDICATOR SYMBOL LETTER G]" xx 2).chars #=> 1
> 

With a recent rakudo, these now both output 1

> say ("\c[REGIONAL INDICATOR SYMBOL LETTER G]" x 2).chars
1
> say ([~] "\c[REGIONAL INDICATOR SYMBOL LETTER G]" xx 2).chars
1
>

-- 
Will "Coke" Coleda

[perl #131997] New Rakudo Star Bug

[Will Coleda via RT]

On Wed, 30 Aug 2017 09:15:53 -0700, stephen.john@gmail.com wrote:
> This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-53-
> g66c6dda
> implementing Perl 6.c.
> 
> As mentioned on IRC #perl6 today 16:50.
> Apologies if this is down to newbie error - please do let me know if
> (& where) I messed up!

In future, please send files as attachments, makes it easier to test the code.

Please specify what the behavior you expected is, and what the behavior you see 
is.

The subject of "New Rakudo Star Bug" implies that this used to work differently 
in a previous version. Is that the case? Do you have a version of rakudo in 
which this worked differently?

-- 
Will "Coke" Coleda

[perl #131997] New Rakudo Star Bug

[Will Coleda via RT]

On Wed, 30 Aug 2017 09:15:53 -0700, stephen.john@gmail.com wrote:
> This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-53-
> g66c6dda
> implementing Perl 6.c.
> 
> As mentioned on IRC #perl6 today 16:50.
> Apologies if this is down to newbie error - please do let me know if
> (& where) I messed up!

In future, please send files as attachments, makes it easier to test the code.

Please specify what the behavior you expected is, and what the behavior you see 
is.

The subject of "New Rakudo Star Bug" implies that this used to work differently 
in a previous version. Is that the case? Do you have a version of rakudo in 
which this worked differently?

-- 
Will "Coke" Coleda

[perl #131973] [RFC] Backtracking modifiers on individual atoms fail to override a regex-global `:ratchet` modifier.

[Will Coleda via RT]

On Sun, 27 Aug 2017 10:03:52 -0700, sml...@gmail.com wrote:
> Based on S05, these test-cases should all pass:
> 
>  is "ab" ~~ / [ab | a ] b /, "ab", 'normal backtracking';
>  is "ab" ~~ / [ab | a ]: b /, Nil, 'locally disabled backtracking';
>  is "ab" ~~ / :r [ab | a ] b /, Nil, 'globally disabled backtracking';
>  is "ab" ~~ / :r [ab | a ]:! b /, "ab", 'globally disabled but 
> locally re-enabled backtracking';
> 
> In current Rakudo, the first three pass but the last one fails (it 
> refuses to backtrack into the alternation and thus returns no Match).
> 
> According to S05 that's a bug:
> 
> "The new :r or :ratchet modifier causes this regex to not backtrack by 
> default. [...] Explicit backtracking modifiers on quantified atoms[...] 
> will override this.
> -- http://design.perl6.org/S05.html#line_624
> 
> Related to RT #130117.

At this stage, something's presence in one of the SYN doesn't mandate that it 
needs to be present in rakudo.

Tagged ticket as RFC.

-- 
Will "Coke" Coleda

[perl #131973] [RFC] Backtracking modifiers on individual atoms fail to override a regex-global `:ratchet` modifier.

[Will Coleda via RT]

On Sun, 27 Aug 2017 10:03:52 -0700, sml...@gmail.com wrote:
> Based on S05, these test-cases should all pass:
> 
>  is "ab" ~~ / [ab | a ] b /, "ab", 'normal backtracking';
>  is "ab" ~~ / [ab | a ]: b /, Nil, 'locally disabled backtracking';
>  is "ab" ~~ / :r [ab | a ] b /, Nil, 'globally disabled backtracking';
>  is "ab" ~~ / :r [ab | a ]:! b /, "ab", 'globally disabled but 
> locally re-enabled backtracking';
> 
> In current Rakudo, the first three pass but the last one fails (it 
> refuses to backtrack into the alternation and thus returns no Match).
> 
> According to S05 that's a bug:
> 
> "The new :r or :ratchet modifier causes this regex to not backtrack by 
> default. [...] Explicit backtracking modifiers on quantified atoms[...] 
> will override this.
> -- http://design.perl6.org/S05.html#line_624
> 
> Related to RT #130117.

At this stage, something's presence in one of the SYN doesn't mandate that it 
needs to be present in rakudo.

Tagged ticket as RFC.

-- 
Will "Coke" Coleda

[perl #131781] :?smth should construct a truthy pair (say (:?foo))

[Will Coleda via RT]

On Sat, 22 Jul 2017 09:12:31 -0700, c...@zoffix.com wrote:
> On Sat, 22 Jul 2017 07:53:26 -0700, alex.jakime...@gmail.com wrote:
> > This should work:
> >
> > Code:
> > say (:?foo);
> >
> > Result:
> > ===SORRY!=== Error while compiling -e
> > Bogus statement
> > at -e:1
> > --> say (:⏏?foo);
> > expecting any of:
> > colon pair
> >
> >
> > Because these work:
> >
> > Code:
> > say (:foo);
> > say (:!foo);
> >
> > Result:
> > foo => True
> > foo => False
> 
> 
> -1 from me:
> 
> 1) Colonpairs are ubiquitous in the language, so there's large
> possibility of introducing some unwanted ambiguity somewhere and it's
> hard to predict where it might occur
> 2) Colonpairs are already one of the most complex syntax feature of
> the language, requiring beginners to learn a wealth of syntax to
> understand most of the common code.
> 3) Given (1) and (2), I'd expect any changes to extend their syntax to
> carry large benefits, however, the proposal offers literally zero
> practical use and the OP came up[^1] with this idea while trying to
> think of more cases to add to the catalog of colon uses in Rakudo. The
> `?` prefix op at least coerces the already-true arg to Bool (e.g.
> `?"foo" === True`) but in the case of the colonpair, there's nothing
> to coerce, so there's absolutely no point in typing the extra `?` and
> it's unlikely anyone would want to type it.

-1 from me as well, I agree with these first three points.

> 4) The OP makes the case that this syntax should exist solely for the
> sake of consistency, by interpreting the `!` in `:!foo` syntax to mean
> the `!` op, and there exists the `?` op. But if we follow that logic,
> it'd mean:
> *) `!! ??` should be allowed too, to mean reverse ternary
> *) `::!CLASS` should mean `anything but ::?CLASS`
> *) `has $?foo` should be an alternative to `has $!foo`
> *) `self?foo` should be an alternative to `self!foo`
> *) `:-42foo` should parse just as `:42foo` parses
> The point being that the current syntax is `":"` vs `":!"` not `":"`
> vs `":" + some op`. And things that have "!" in them do not
> necessarily need to have a "?" alternative.
> 
> In summation, there's no practical use of this feature and it is
> unlikely it'll ever be used in real programs. The colonpair syntax is
> used across the entire language and any changes to it have large
> impact. It's very hard to anticipate any problematic ambiguity cases
> introduction of `?` into colon syntax might have. And given lack of
> technical benefits of this feature, I do not think we should accept
> the risks.
> 
> 
> [1] https://irclog.perlgeek.de/perl6/2017-07-22#i_14907647


-- 
Will "Coke" Coleda

[perl #131781] :?smth should construct a truthy pair (say (:?foo))

[Will Coleda via RT]

On Sat, 22 Jul 2017 09:12:31 -0700, c...@zoffix.com wrote:
> On Sat, 22 Jul 2017 07:53:26 -0700, alex.jakime...@gmail.com wrote:
> > This should work:
> >
> > Code:
> > say (:?foo);
> >
> > Result:
> > ===SORRY!=== Error while compiling -e
> > Bogus statement
> > at -e:1
> > --> say (:⏏?foo);
> > expecting any of:
> > colon pair
> >
> >
> > Because these work:
> >
> > Code:
> > say (:foo);
> > say (:!foo);
> >
> > Result:
> > foo => True
> > foo => False
> 
> 
> -1 from me:
> 
> 1) Colonpairs are ubiquitous in the language, so there's large
> possibility of introducing some unwanted ambiguity somewhere and it's
> hard to predict where it might occur
> 2) Colonpairs are already one of the most complex syntax feature of
> the language, requiring beginners to learn a wealth of syntax to
> understand most of the common code.
> 3) Given (1) and (2), I'd expect any changes to extend their syntax to
> carry large benefits, however, the proposal offers literally zero
> practical use and the OP came up[^1] with this idea while trying to
> think of more cases to add to the catalog of colon uses in Rakudo. The
> `?` prefix op at least coerces the already-true arg to Bool (e.g.
> `?"foo" === True`) but in the case of the colonpair, there's nothing
> to coerce, so there's absolutely no point in typing the extra `?` and
> it's unlikely anyone would want to type it.

-1 from me as well, I agree with these first three points.

> 4) The OP makes the case that this syntax should exist solely for the
> sake of consistency, by interpreting the `!` in `:!foo` syntax to mean
> the `!` op, and there exists the `?` op. But if we follow that logic,
> it'd mean:
> *) `!! ??` should be allowed too, to mean reverse ternary
> *) `::!CLASS` should mean `anything but ::?CLASS`
> *) `has $?foo` should be an alternative to `has $!foo`
> *) `self?foo` should be an alternative to `self!foo`
> *) `:-42foo` should parse just as `:42foo` parses
> The point being that the current syntax is `":"` vs `":!"` not `":"`
> vs `":" + some op`. And things that have "!" in them do not
> necessarily need to have a "?" alternative.
> 
> In summation, there's no practical use of this feature and it is
> unlikely it'll ever be used in real programs. The colonpair syntax is
> used across the entire language and any changes to it have large
> impact. It's very hard to anticipate any problematic ambiguity cases
> introduction of `?` into colon syntax might have. And given lack of
> technical benefits of this feature, I do not think we should accept
> the risks.
> 
> 
> [1] https://irclog.perlgeek.de/perl6/2017-07-22#i_14907647


-- 
Will "Coke" Coleda

[perl #131704] Can't use unknown trait 'is export' in a regex declaration

[Will Coleda via RT]

On Tue, 04 Jul 2017 22:27:14 -0700, lloyd.fo...@gmail.com wrote:
> perl6 -e 'constant $foo is export = /foo/;'
> 
>  seems to be being called on the regex rather than the variable??

Please include: perl6 version; the result of the command, and the expected 
result.

Thanks.
-- 
Will "Coke" Coleda

[perl #131708] [BUILD]. Rakudo Star build instructions incomplete

[Will Coleda via RT]

On Wed, 05 Jul 2017 09:16:44 -0700, tbrowder wrote:
> Given this invocation for a new installation of rakudo:
> 
>   perl Configure.pl  --backend=moar --gen-moar --prefix=/some/dir
> 
> /some/dir needs to exist and belong to the user attempting the
> installation.  That usually forces the user to be root just to configure
> and build rakudo.  Then the build directory is polluted with root-owned
> files.
> 
> Clearly the configure and build steps need to be usable as an ordinary user
> as most Linux packages are.  Then the install command can require root so
> that the desired directory can be created if necessary, and the correct
> permissions created for the various files and directories as they are
> copied into place.
> 
> Until that problem is solved, the installation instructions need to detail
> the current requirements of an installation outside the build directory.

This is the wrong queue for this ticket; please re-open at github's rakudo/star 
queue.

Regards.

-- 
Will "Coke" Coleda

[perl #131708] [BUILD]. Rakudo Star build instructions incomplete

[Will Coleda via RT]

On Wed, 05 Jul 2017 09:16:44 -0700, tbrowder wrote:
> Given this invocation for a new installation of rakudo:
> 
>   perl Configure.pl  --backend=moar --gen-moar --prefix=/some/dir
> 
> /some/dir needs to exist and belong to the user attempting the
> installation.  That usually forces the user to be root just to configure
> and build rakudo.  Then the build directory is polluted with root-owned
> files.
> 
> Clearly the configure and build steps need to be usable as an ordinary user
> as most Linux packages are.  Then the install command can require root so
> that the desired directory can be created if necessary, and the correct
> permissions created for the various files and directories as they are
> copied into place.
> 
> Until that problem is solved, the installation instructions need to detail
> the current requirements of an installation outside the build directory.

This is the wrong queue for this ticket; please re-open at github's rakudo/star 
queue.

Regards.

-- 
Will "Coke" Coleda

[perl #131709] [BUILD] rakudo installation page dooesn't tell where to report star bugs

[Will Coleda via RT]

This queue is for rakudo perl6 compiler bugs.

This ticket probably belongs in the github rakudo/star queue.

Regards.

-- 
Will "Coke" Coleda

[perl #131709] [BUILD] rakudo installation page dooesn't tell where to report star bugs

[Will Coleda via RT]

This queue is for rakudo perl6 compiler bugs.

This ticket probably belongs in the github rakudo/star queue.

Regards.

-- 
Will "Coke" Coleda

[perl #125656] [CONC] Creating too many Proc::Async objects fills the file descriptor table, which causes libuv to abort()

[Will Coleda via RT]

On Mon, 20 Jul 2015 20:09:39 -0700, r...@hoelz.ro wrote:
> See the attached script.

Still dying with version 2017.06-13-g6b634a369 built on MoarVM version 
2017.06-2-gcc27eebf

-- 
Will "Coke" Coleda

[perl #125656] [CONC] Creating too many Proc::Async objects fills the file descriptor table, which causes libuv to abort()

[Will Coleda via RT]

On Mon, 20 Jul 2015 20:09:39 -0700, r...@hoelz.ro wrote:
> See the attached script.

Still dying with version 2017.06-13-g6b634a369 built on MoarVM version 
2017.06-2-gcc27eebf

-- 
Will "Coke" Coleda

[perl #131492] Camelia produces different error message from commandline

[Will Coleda via RT]

On Wed, 07 Jun 2017 11:46:03 -0700, ben-goldb...@hotmail.com wrote:
> On Monday, June 05, 2017 5:05 PM, Will Coleda via RT  wrote:
> > On Fri, 02 Jun 2017 23:29:40 -0700, ben-goldb...@hotmail.com wrote:
> > > On #perl6 IRC, I typed this:
> > >
> > >  m: my \foo = Callable but role :: { };
> > > <+camelia> rakudo-moar ef9872: OUTPUT: «X::Method::NotFound
> > > exception
> > > produced no message␤  in block  at  line 1␤␤»
> > >
> > > If, at my command prompt, I type perl6 –e “my \foo = Callable but
> > > role
> > > :: { };”
> > > I get instead:
> > >
> > > No such method 'mixin' for invocant of type
> > > 'Perl6::Metamodel::ParametricRoleGroupHOW'
> > >   in block  at -e line 1
> > >
> > >
> > > Including, oddly, an extra blank line after the error and before my
> > > prompt.
> >
> >
> > Please provide the version of rakudo you're running locally so we can
> > rule
> > out any version skew.
> >
> 
> C:\Users\Ben (user)>perl6 -v
> This is Rakudo version 2017.01 built on MoarVM version 2017.01
> implementing Perl 6.c.
> 

This was a temporary change: 

23:42 < [Coke]> committable6: 2017.01 my \foo = Callable but role :: { };
23:42 <+committable6> [Coke], ¦2017.01: «No such method 'mixin' for invocant of
  type 'Perl6::Metamodel::ParametricRoleGroupHOW'␤  in
  block  at /tmp/hYc6hABV7m line 1␤ «exit code = 1»»
23:42 < Juerd> ugexe: "use lib 'lib';" is in example code at
   https://docs.perl6.org/language/modules
23:42 < [Coke]> committable6: 2017.05 my \foo = Callable but role :: { };
23:42 <+committable6> [Coke], ¦2017.05: «No such method 'mixin' for invocant of
  type 'Perl6::Metamodel::ParametricRoleGroupHOW'␤  in
  block  at /tmp/2usM18Vu7J line 1␤ «exit code = 1»»
23:42 < [Coke]> m: my \foo = Callable but role :: { };
23:42 <+camelia> rakudo-moar f0c3bf: OUTPUT: «No such method 'mixin' for
 invocant of type 'Perl6::Metamodel::ParametricRoleGroupHOW'.
 Did you mean 'min'?␤  in block  at  line 1␤␤»
23:43 < [Coke]> committable6: ef9872 my \foo = Callable but role :: { };
23:43 <+committable6> [Coke], ¦ef9872: «X::Method::NotFound exception produced
  no message␤  in block  at /tmp/djXVvvjcMC line 1␤
  «exit code = 1»»

Note that 2017.01, 2017.05 and f0c3fb all give the same output.

Checking the specific version you reported earlier, I see the difference.


-- 
Will "Coke" Coleda

[perl #131492] Camelia produces different error message from commandline

[Will Coleda via RT]

On Wed, 07 Jun 2017 11:46:03 -0700, ben-goldb...@hotmail.com wrote:
> On Monday, June 05, 2017 5:05 PM, Will Coleda via RT  wrote:
> > On Fri, 02 Jun 2017 23:29:40 -0700, ben-goldb...@hotmail.com wrote:
> > > On #perl6 IRC, I typed this:
> > >
> > >  m: my \foo = Callable but role :: { };
> > > <+camelia> rakudo-moar ef9872: OUTPUT: «X::Method::NotFound
> > > exception
> > > produced no message␤  in block  at  line 1␤␤»
> > >
> > > If, at my command prompt, I type perl6 –e “my \foo = Callable but
> > > role
> > > :: { };”
> > > I get instead:
> > >
> > > No such method 'mixin' for invocant of type
> > > 'Perl6::Metamodel::ParametricRoleGroupHOW'
> > >   in block  at -e line 1
> > >
> > >
> > > Including, oddly, an extra blank line after the error and before my
> > > prompt.
> >
> >
> > Please provide the version of rakudo you're running locally so we can
> > rule
> > out any version skew.
> >
> 
> C:\Users\Ben (user)>perl6 -v
> This is Rakudo version 2017.01 built on MoarVM version 2017.01
> implementing Perl 6.c.
> 

This was a temporary change: 

23:42 < [Coke]> committable6: 2017.01 my \foo = Callable but role :: { };
23:42 <+committable6> [Coke], ¦2017.01: «No such method 'mixin' for invocant of
  type 'Perl6::Metamodel::ParametricRoleGroupHOW'␤  in
  block  at /tmp/hYc6hABV7m line 1␤ «exit code = 1»»
23:42 < Juerd> ugexe: "use lib 'lib';" is in example code at
   https://docs.perl6.org/language/modules
23:42 < [Coke]> committable6: 2017.05 my \foo = Callable but role :: { };
23:42 <+committable6> [Coke], ¦2017.05: «No such method 'mixin' for invocant of
  type 'Perl6::Metamodel::ParametricRoleGroupHOW'␤  in
  block  at /tmp/2usM18Vu7J line 1␤ «exit code = 1»»
23:42 < [Coke]> m: my \foo = Callable but role :: { };
23:42 <+camelia> rakudo-moar f0c3bf: OUTPUT: «No such method 'mixin' for
 invocant of type 'Perl6::Metamodel::ParametricRoleGroupHOW'.
 Did you mean 'min'?␤  in block  at  line 1␤␤»
23:43 < [Coke]> committable6: ef9872 my \foo = Callable but role :: { };
23:43 <+committable6> [Coke], ¦ef9872: «X::Method::NotFound exception produced
  no message␤  in block  at /tmp/djXVvvjcMC line 1␤
  «exit code = 1»»

Note that 2017.01, 2017.05 and f0c3fb all give the same output.

Checking the specific version you reported earlier, I see the difference.


-- 
Will "Coke" Coleda

Re: [perl #131481] [BUG] No perl6-debug

[Will Coleda via RT]

TBD there indicates that the documentation is yet to be done.

On Thu, Jun 8, 2017 at 4:38 AM, Richard Hainsworth
 wrote:
> Thanks for feedback. A follow up:
>
> 
>>
>> Yes, use `no precompilation` pragma.
>>
>>
> So I would have in the topmost program:
>
> use v6.c;
> no precompilation;
>
> In the documentation (https://docs.perl6.org/language/pragmas),
> precompilation is labelled [TBD]
>
> So is it ignored ?
>
> Regards,
> Richard



-- 
Will "Coke" Coleda

[perl #131492] Camelia produces different error message from commandline

[Will Coleda via RT]

On Fri, 02 Jun 2017 23:29:40 -0700, ben-goldb...@hotmail.com wrote:
> On #perl6 IRC, I typed this:
> 
>  m: my \foo = Callable but role :: { };
> <+camelia> rakudo-moar ef9872: OUTPUT: «X::Method::NotFound exception
> produced no message␤  in block  at  line 1␤␤»
> 
> If, at my command prompt, I type perl6 –e “my \foo = Callable but role
> :: { };”
> I get instead:
> 
> No such method 'mixin' for invocant of type
> 'Perl6::Metamodel::ParametricRoleGroupHOW'
>   in block  at -e line 1
> 
> 
> Including, oddly, an extra blank line after the error and before my
> prompt.
> 


Please provide the version of rakudo you're running locally so we can rule out 
any version skew.

-- 
Will "Coke" Coleda

[perl #131492] Camelia produces different error message from commandline

[Will Coleda via RT]

On Fri, 02 Jun 2017 23:29:40 -0700, ben-goldb...@hotmail.com wrote:
> On #perl6 IRC, I typed this:
> 
>  m: my \foo = Callable but role :: { };
> <+camelia> rakudo-moar ef9872: OUTPUT: «X::Method::NotFound exception
> produced no message␤  in block  at  line 1␤␤»
> 
> If, at my command prompt, I type perl6 –e “my \foo = Callable but role
> :: { };”
> I get instead:
> 
> No such method 'mixin' for invocant of type
> 'Perl6::Metamodel::ParametricRoleGroupHOW'
>   in block  at -e line 1
> 
> 
> Including, oddly, an extra blank line after the error and before my
> prompt.
> 


Please provide the version of rakudo you're running locally so we can rule out 
any version skew.

-- 
Will "Coke" Coleda

[perl #131505] [@LARRY] Special case allomorph coercion everywhere

[Will Coleda via RT]

On Sat, 03 Jun 2017 21:20:49 -0700, c...@zoffix.com wrote:
> (found in discussion in
> https://rt.perl.org/Ticket/Display.html?id=131493 )
> 
> 
> We have some special casing for coercion of allomorphs in some
> instances, which
> is done so there'd be some way to force one of the two types to fall
> out of it,
> since we have types where to whom object identity matters a bunch:
> 
>  m: <1>.Str.^name.say
>  rakudo-moar 7344a3: OUTPUT: «Str␤»
>  m: <1>.Int.^name.say
>  rakudo-moar 3755c0: OUTPUT: «Int␤»
> 
> However, allomorphs don't get coerced with parameter coercers and
> possibly some
> other places. There's no special casing here done. The coercer coerces
> to Str type
> and IntStr allomorph is already it.
> 
>  m: -> Str() $_ { .^name.say }(<1>)
>  rakudo-moar 7344a3: OUTPUT: «IntStr␤»
>  m: -> Int() $_ { .^name.say }(<1>)
>  rakudo-moar 7344a3: OUTPUT: «IntStr␤»
> 
> 
> So the question becomes: do we special case allomorphs everywhere?

No. The current behavior seems correct to me.

> - If yes, any place we special case them will have a caveat and
> surprising behaviour
> where type don't get coerced to exact asked type if it's a
> subclass of it

If you want something coerced to the exact type, this can be done outside of 
the signature.

I would just document the behavior for coercions clearly, in that if the value 
already satisfy the type in the coercer, your value is passed through 
unchanged. 

> - If no, we get surprising special cased behaviour like above, but
> only in one case
> - Or we could remove the coercion to one of the two types and have
> <1>.Str return the same
>IntStr; in that case I'm unsure what would be a way to "collapse"
> an allomorph into
>numeric or string parts, since many ops use these methods to coerce
> stuff.




--
Will "Coke" Coleda

[perl #131505] [@LARRY] Special case allomorph coercion everywhere

[Will Coleda via RT]

On Sat, 03 Jun 2017 21:20:49 -0700, c...@zoffix.com wrote:
> (found in discussion in
> https://rt.perl.org/Ticket/Display.html?id=131493 )
> 
> 
> We have some special casing for coercion of allomorphs in some
> instances, which
> is done so there'd be some way to force one of the two types to fall
> out of it,
> since we have types where to whom object identity matters a bunch:
> 
>  m: <1>.Str.^name.say
>  rakudo-moar 7344a3: OUTPUT: «Str␤»
>  m: <1>.Int.^name.say
>  rakudo-moar 3755c0: OUTPUT: «Int␤»
> 
> However, allomorphs don't get coerced with parameter coercers and
> possibly some
> other places. There's no special casing here done. The coercer coerces
> to Str type
> and IntStr allomorph is already it.
> 
>  m: -> Str() $_ { .^name.say }(<1>)
>  rakudo-moar 7344a3: OUTPUT: «IntStr␤»
>  m: -> Int() $_ { .^name.say }(<1>)
>  rakudo-moar 7344a3: OUTPUT: «IntStr␤»
> 
> 
> So the question becomes: do we special case allomorphs everywhere?

No. The current behavior seems correct to me.

> - If yes, any place we special case them will have a caveat and
> surprising behaviour
> where type don't get coerced to exact asked type if it's a
> subclass of it

If you want something coerced to the exact type, this can be done outside of 
the signature.

I would just document the behavior for coercions clearly, in that if the value 
already satisfy the type in the coercer, your value is passed through 
unchanged. 

> - If no, we get surprising special cased behaviour like above, but
> only in one case
> - Or we could remove the coercion to one of the two types and have
> <1>.Str return the same
>IntStr; in that case I'm unsure what would be a way to "collapse"
> an allomorph into
>numeric or string parts, since many ops use these methods to coerce
> stuff.




--
Will "Coke" Coleda

[perl #131385] NQP converts large integers to floats when it shouldn't/doesn't need to

[Will Coleda via RT]

Moved ticket to

https://github.com/perl6/nqp/issues/363

in the NQP issues queue.

-- 
Will "Coke" Coleda

[perl #131385] NQP converts large integers to floats when it shouldn't/doesn't need to

[Will Coleda via RT]

Moved ticket to

https://github.com/perl6/nqp/issues/363

in the NQP issues queue.

-- 
Will "Coke" Coleda

[perl #130603] Test (module) fails while all tests return ok

[Will Coleda via RT]

On Fri, 20 Jan 2017 06:09:00 -0800, mt1...@gmail.com wrote:
> Hi,
> 
> Since using Log::Async in MongoDB I get problems while testing. All 
> tests run ok but at the end the Test returns failure
> 
> 
> ...
> 
> ok 6 - Testing explain and performance using hint
> 
> 2017-01-20 13:04:40.783616 [I] 1: Test 
> /home/travis/build/MARTIMM/mongo-perl6-driver/t/450-find.t stop
> 
> 1..6
> 
> Failed 3/6 subtests
> 
> ... other test programs ... Test Summary Report
> 
> ---
> 
> t/450-find.t (Wstat: 0 Tests: 3 Failed: 0)
> 
> Parse errors: Tests out of sequence. Found (3) but expected (1)
> 
> Tests out of sequence. Found (5) but expected (2)
> 
> Tests out of sequence. Found (6) but expected (3)
> 
> Bad plan. You planned 6 tests but ran 3.
> 
> Files=11, Tests=42, 228 wallclock secs ( 0.14 usr 0.02 sys + 208.76 cusr 
> 9.47 csys = 218.39 CPU)
> 
> Result: FAIL
> 
> 
> 
> You can see complete report on Travis-ci at 
> https://travis-ci.org/MARTIMM/mongo-perl6-driver.
> 
> This is Rakudo version 2016.10-239-g0cf7b36 built on MoarVM version 
> 2016.10-43-gb4cd2a6
> implementing Perl 6.c.
> 
> Marcel
> 

This is a failure on an ecosystem module, not core rakudo.

Unless there's an example of how this is explicitly a rakudo bug, this should 
be reported on https://github.com/MARTIMM/mongo-perl6-driver/issues

Regards.
-- 
Will "Coke" Coleda

[perl #130590] HyperWhatever does not work with reduction metaop ([+] **)

[Will Coleda via RT]

On Thu, 19 Jan 2017 18:10:27 -0800, alex.jakime...@gmail.com wrote:

> I guess it is supposed to work?

Why?

-- 
Will "Coke" Coleda

[perl #130419] |, ^, and & character class set operators aren't parseable

[Will Coleda via RT]

On Fri, 30 Dec 2016 13:36:03 -0800, jn...@jnthn.net wrote:
> On Tue, 27 Dec 2016 14:32:45 -0800, comdog wrote:
> > These are documented in https://docs.perl6.org/language/regexes but
> > are
> > not marked as "not implemented" or something similar.
> 
> I doubt they'll be implemented particularly soon; I suggest they are
> removed from the docs.

Opened a docs ticket to cover it.

https://github.com/perl6/doc/issues/1093

Rejecting this ticket.

-- 
Will "Coke" Coleda

[perl #130294] [SEGV] native 2d array example SEGV's

[Will Coleda via RT]

Attaching gistfile to ticket

-- 
Will "Coke" Coleda
use v6;
my $size = 3001;
my int @mat[$size; $size];

init-array(0, $size - 1, $size * $size);
say 'done';
sub init-array($r, $c, $val) {
  @mat[$r; $c] = $val;
  if $c - 1 >= 0
  { # left
init-array($r, $c - 1, $val - 1);
  }
  elsif $r + 1 < $size
  { # down
init-array($r + 1, $c, $val - 1);
  }
}

[perl #130377] [BUG] write on closed socket not failing as it should

[Will Coleda via RT]

On Mon, 19 Dec 2016 14:38:09 -0800, bradl...@dal.ca wrote:
> This is Rakudo version 2016.11 built on MoarVM version 2016.11
> implementing Perl 6.c.
> 
> Here is a program that demonstrates the problem.
> 
> use v6;
> 
> my $s = IO::Socket::INET.new(:host('irc.freenode.net'), :port(6667));
> $s.print("QUIT\r\n");
> for $s.lines { say $_; }
> say so $s.print("this should fail");
> 

Note that if you explicitly close the socket, this works as expected.

use v6;

my $s = IO::Socket::INET.new(:host('irc.freenode.net'), :port(6667));
$s.print("QUIT\r\n");
for $s.lines { say $_; }
$s.close;
say so $s.print("this should fail");

:rajaniemi.freenode.net NOTICE * :*** Looking up your hostname...
:rajaniemi.freenode.net NOTICE * :*** Checking Ident
:rajaniemi.freenode.net NOTICE * :*** Couldn't look up your hostname
:rajaniemi.freenode.net NOTICE * :*** No Ident response
ERROR :Closing Link: 127.0.0.1 (Client Quit)
False

-- 
Will "Coke" Coleda

[perl #130253] [NYI] Coercion type in variable declarations

[Will Coleda via RT]

On Sat, 03 Dec 2016 11:31:59 -0800, pe...@mscha.org wrote:
> Coercion type works quite nicely in signatures, e.g.
> 
>  sub foo(Int(Cool) $f) {
>  say $f.WHAT;
>  }
>  foo "42";# (Int)
> 
> but it doesn't work yet in variable declarations, e.g.
> 
>  my Int(Cool) $x; $x = "42"; # Coercion Int(Cool) is insufficiently 
> type-like to qualify a variable
> 
> 
> Using Rakudo Star 2016.11:
> This is Rakudo version 2016.11 built on MoarVM version 2016.11
> implementing Perl 6.c.
> 

Can you point to where the specification test suite (roast), old design docs, 
IRC, or the docs site indicating where this was planned?

Thanks.
-- 
Will "Coke" Coleda

[perl #130231] [LTA] Nil.chrs complains about the use of Nil in numeric context, but isn't it a string context? (Nil.chrs)

[Will Coleda via RT]

On Thu, 01 Dec 2016 15:11:31 -0800, alex.jakime...@gmail.com wrote:
> Code:
> Nil.chrs
> 
> Result:
> Use of Nil in numeric context
>   in block  at -e line 1
> 
> 
> At the same time:
> 
> Code:
> Nil.ords
> 
> Result:
> Use of Nil in string context
>   in block  at -e line 1
> 
> 
> I think that both should say that it is in string context.


chrs takes an array of Ints and returns a Str; it's trying to use Nil in a 
numeric context to get a number to work with.

ords takes a Str and returns an array of ints - it's trying to use Nil in a 
string context to get character to work with.

Seems fine. Rejecting ticket.

-- 
Will "Coke" Coleda

[perl #130216] Does Perl 6 support POSIX character classes?

[Will Coleda via RT]

On Tue, 29 Nov 2016 12:33:21 -0800, comdog wrote:
> On https://docs.perl6.org/language/regexes , it says "POSIX character
> classes", then lists the names of the POSIX character classes. When I
> try these, they don't seem to respect the locale (see
> http://stackoverflow.com/q/40863736/2766176).
> 
> If they don't respect the locale, then we shouldn't call them "POSIX"
> since people will expect them to at as POSIX documents them.
> 

It doesn't actually say POSIX as of sometime earlier today, already updated as 
a result of that SO question.

Closing ticket. (doc tickets can be opened on 
https://github.com/perl6/doc/issues).
-- 
Will "Coke" Coleda

[perl #129296] [REGRESSION] Splitting non-binary handles no longer works (run(:out, "ls").out.split: 0.chr)

[Will Coleda via RT]

On Sun, 18 Sep 2016 03:14:30 -0700, elizabeth wrote:
> Fixed by reverting 1a03efe4e3b61a07b7df5 in 363a3a899f2cb342d1ca5 .

Can we close the case?

-- 
Will "Coke" Coleda

[perl #126828] [BUG] .narrow now fails on a Complex with a zero real part.

[Will Coleda via RT]

On Wed, 09 Dec 2015 00:08:19 -0800, moritz wrote:
> On Sat Dec 05 17:12:49 2015, thunderg...@comcast.net wrote:
> > Complex.narrow fails when the real part is zero.
> > 
> >  $ perl6 -e' say 0+1i.narrow '
> >  Attempt to divide 1 by zero using /
> >in block  at -e:1
> > 
> >  Actually thrown at:
> >in block  at -e:1
> 
> 
> Fixed, and tests fixed, expanded and unfudged: 
> https://github.com/perl6/roast/commit/66d8f6c6c9
> 
> Cheers,
> Moritz

... So, closing ticket (11 months later)

-- 
Will "Coke" Coleda

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

[Will Coleda 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

as of b5aa3c5, these both output 287369 now.


-- 
Will "Coke" Coleda

[perl #130050] placement of use statement

[Will Coleda via RT]

On Tue, 08 Nov 2016 04:42:32 -0800, mt1...@gmail.com wrote:
> Hi,
> 
> in rakudo 2016.10-249-gb84158c built on MoarVM version 
> 2016.10-37-gf769569 implementing Perl 6.c, I've seen the following problem.
> 
> When a use statement was placed as the first one, the class was not 
> recognized and I got the following error(in this case MongoDB::Client 
> which is loaded with 'use MongoDB::Client'):
> 
> ===SORRY!=== Error while compiling 
> /home/marcel/Languages/Perl6/Projects/mongo-perl6-driver/t/Test-support.pm6 
> (Test-support)
> Type 'MongoDB::Client' is not declared
> at 
> /home/marcel/Languages/Perl6/Projects/mongo-perl6-driver/t/Test-support.pm6 
> (Test-support):119
> --> n ( Int :$server = 1 --> MongoDB::Client⏏ ) {
> 
> When I move the statement one line below another use statement the error 
> still comes back. Only when the line is below all other use statements 
> the error disappears as if the other use statements cancels out the the 
> MongoDB::Client definition.
> 
> This is a situation which I've not seen anywhere else and I do not know 
> if there is something wrong in the code or not, Maybe it has something 
> to do with the recent changes in lexical module loading.
> 
> Anyways, the statement is placed somewhere else and the project can 
> continue.
> 
> Regards,
> Marcel
> 

Can you provide a code sample showing the issue?


-- 
Will "Coke" Coleda

[perl #122447] Cannot precompile sub with params returning a proxy

[Will Coleda via RT]

On Tue Oct 07 11:21:19 2014, david.warring wrote:
> I just tried that on perl6 version 2014.09-161-gc24537e. Seems to now
> work on all backends without errors.
> 
> Tests have been added to S10-packages/precompilation.t

Can we close the ticket, then?

-- 
Will "Coke" Coleda

[perl #129948] [BUG] repl error

[Will Coleda via RT]

On Sun Oct 23 15:00:57 2016, gordmi...@gmail.com wrote:
> I'm using perl 6, version "This is Rakudo version 2016.10 built on MoarVM
> version 2016.10
> implementing Perl 6.c.".
> 
> When I launch perl6 as repl it prints an error message:
> "I ran into a problem while trying to set up Readline: Earlier failures:
>  Failed to find
> '/home/ogneslav/.perl6/sources/CF6C9C08E71FA4F33C4C67EDA924776963F4F7BF'
> while trying to do '.modified'
>   in any interactive at src/Perl6/Compiler.nqp line 55
> 
> Final error:
>  Cannot resolve caller load(CompUnit::PrecompilationRepository::Default:
> CompUnit::PrecompilationId,
> :precomp-stores(Array[CompUnit::PrecompilationStore]), :Failure); none of
> these signatures match:
> (CompUnit::PrecompilationRepository::Default $: Str $id, Instant
> :$since, CompUnit::PrecompilationStore :@precomp-stores = { ... }, *%_)
> (CompUnit::PrecompilationRepository::Default $:
> CompUnit::PrecompilationId $id, Instant :$since,
> CompUnit::PrecompilationStore :@precomp-stores = { ... }, *%_)
> Falling back to Linenoise (if present)"
> 
> Before it works fine, but after Readline module was installed and when
> delited this error mesage comes.
> 
> With regards,
> Mikhail Gordeev

How did you delete the Readline module?

-- 
Will "Coke" Coleda

[perl #123700] [BUG] mysterious subset failures

[Will Coleda via RT]

On Fri Oct 23 13:29:12 2015, barto...@gmx.de wrote:

> Did you report the issue with precomp? If so, this ticket can be
> closed.
> 
> Christian

This was 2015; precompilation has undergone a lot of changes since then. If you 
are still experiencing issues, please open a new ticket.

-- 
Will "Coke" Coleda

[perl #64766] Possibly inconsistent behaviour in mixing-in of 'handles'

[Will Coleda via RT]

On Fri Dec 18 08:26:09 2015, jn...@jnthn.net wrote:
> On Thu Apr 16 06:23:35 2009, masak wrote:
> > OH HAI from NPW::2009.
> >
> > In Rakudo 2c13d6c, the 'handles' instruction on attributes in roles
> > don't override those of the class it mixes in.
> >
> > $ perl6 -e 'class A { method foo { say "OH HAI" }; method aie { say
> > "AIE!" } }; role B { has A $.bar handles * }; class C does B { has A
> > $.bar handles "foo" }; C.new.aie'
> > Could not locate a method 'aie' to invoke on class 'C'.
> > [...]
> >
> > I don't think that the above case is mentioned in the spec, but by
> > the
> > principle of mixins adding attributes consistent with the existing
> > ones, the above should dispatch to A.aie(), instead of failing.
> >
> > By the same token, I guess the following should actually be an error:
> >
> > $ perl6 -e 'class A { method foo { say "OH HAI" }; method aie { say
> > "AIE!" } }; role B { has A $.bar handles "aie" }; class C does B {
> > has
> > A $.bar handles "foo" }; C.new.aie'
> > AIE!
> >
> > Finally, if the two 'handles' RHSes were regular expressions instead
> > of strings, I guess all bets are off and we should fail just in case.
> > At least unless we can introspect regexes.
> 
> The reasoning is a bit off here. Attributes declared in roles are
> meant to behave much like if they were declared in the class itself.
> That means that you'd be declaring two attributes $!bar in both of
> these examples. This today does indeed correctly report a conflict -
> for both of the code examples.
> 
> That did leave the issue that we had no tests for if wildcard and
> literal handles on attributes in roles took effect. I wrote some tests
> to check they do, and indeed that works out. See the tests added to
> S14-roles/composition.t in 5a0c386 for the details.

Tests fail on JVM - re-opening ticket, marking JVM only. Fudged test.

-- 
Will "Coke" Coleda

[perl #128579] [JVM] ver and auth meta methods not present on packages

[Will Coleda via RT]

The tests added as part of the ticket rejection fail on the JVM; re-opening 
until they pass.

-- 
Will "Coke" Coleda

[perl #127215] Negative codepoint in .comb + /:m/

[Will Coleda via RT]

On Fri Jan 08 21:03:49 2016, ju...@tnx.nl wrote:
> $ perl6 -e'say "hello".comb(/:m <[o]>/)'
> ===SORRY!===
> chr codepoint cannot be negative
> 


-- 
Will "Coke" Coleda

I can no longer duplicate this:

$ perl6 --version
This is Rakudo version 2016.08.1 built on MoarVM version 2016.08
implementing Perl 6.c.
$  perl6 -e'say "hello".comb(/:m <[o]>/)'
(o)

Closable with tests.

[perl #125331] [BUG] Match on undefined value returns twodifferent warning messages

[Will Coleda via RT]

On Fri Jun 05 02:00:55 2015, ppab...@implix.com wrote:
> $ perl6 -e 'loop { $_ ~~ /.+/ }'
> 
> While it runs two different error messages are returned:
> 
> 1. Use of uninitialized value of type Any in string context  in block
> at -e:1
> 2. Use of uninitialized value of type Any in string context  in method
> Str at /home/ppabian/.rakudobrew/moar-
> 2015.05/install/share/perl6/runtime/CORE.setting.moarvm:1
> 
> $ perl6 --version
> This is perl6 version 2015.05 built on MoarVM version 2015.05
> 
> 
> —
> Pawel Pabian
> Senior Perl Developer
> GetResponse
> 
> www.getresponse.com

Still happening in 2016.08.1

-- 
Will "Coke" Coleda

[perl #129252] [RFC] routines sprintf and printf need auto newline capability

[Will Coleda via RT]

On Sun Sep 11 13:48:04 2016, tbrowder wrote:
> Both routines need an alias (or adverb) so that a newline is
> automatically appended to the output.  I would like to see something
> like:
> 
> sprintfn
> printfn
> 
> or
> 
> sprintf-n
> printf-n
> 
> or
> 
> sprintf-nl
> printf-nl

-1 from me.

-- 
Will "Coke" Coleda

[perl #129162] .IO.l does not work on dangling symlinks

[Will Coleda via RT]

On Thu Sep 01 10:05:03 2016, gfldex wrote:
> perl6 -e "dd 'stale-symlink'.IO.l"
> # OUTPUT Failure.new(exception => X::IO::DoesNotExist.new(path =>
> "stale-symlink", trying => "l", os-error => Any), backtrace =>
> Backtrace.new)
> 
> # .IO.l should return true and .IO.e should return false on dangling
> symlinks

Did you do anything in particular at the OS level before running this perl 6 
code? Or are you implying that this is to be run on a non-existent file?
-- 
Will "Coke" Coleda

[perl #118607] [LTA] Suggest multi in "redeclaration of sub foo" error

[Will Coleda via RT]

On Tue Aug 30 10:07:57 2016, ddgr...@gmail.com wrote:
> On Sun Jun 23 04:26:36 2013, Ayiko wrote:
> > use v6;
> > sub foo() { say 'hi'; };
> > sub foo($i) { say "hi $i"; };
> > foo();
> > 
> > Gives as error
> > ===SORRY!===
> > Redeclaration of routine foo
> > at test2.pl:3
> > --> sub foo($i) { say "hi 2"; };
> >  expecting any of:
> >  postfix
> >  statement end
> >  statement modifier
> >  statement modifier loop
> >  horizontal whitespace
> > 
> > Maybe it should mention "multi sub" as a possible fix?
> > 
> > I'm also not sure the "expecting any of" part is helping much in this
> > case...
> 
> Implemented in Rakudo PR 854 (https://github.com/rakudo/rakudo/pull/854).
> Tests added in roast PR 148 (https://github.com/perl6/roast/pull/148).

Looks like both of these were merged. Closing ticket.
-- 
Will "Coke" Coleda

[perl #114388] LTA error when using s[] = "rea"

[Will Coleda via RT]

On Fri Apr 17 03:58:32 2015, barto...@gmx.de wrote:
> The first evaluation fails again (no method 'subst-mutate' nowadays),
> so I'm re-opening this ticket.
> 
> $ perl6 -e 's[ea] = "rea";'
> Method 'subst-mutate' not found for invocant of class 'Any'
>   in block  at -e:1
> 
> We're back to "We could improve the error, but what should it say"
> (moritz, 2012) and "Maybe it should mention $_ somewhere, since it
> tries to call subst on $_" (FROGGS, 2013).

Message changed again:

13:40 < [Coke]> m: s[ea] = "rea"; # RT #114388
13:40 < camelia> rakudo-moar af4c2e: OUTPUT«Method 'match' not found for
 invocant of class 'Any'␤  in block  at  line 1␤␤»


-- 
Will "Coke" Coleda

[perl #127099] [CONC] hyper messes up order of the results (i.e. @result !~~ @result.sort)

[Will Coleda via RT]

On Wed Dec 30 16:00:38 2015, alex.jakime...@gmail.com wrote:
> Code:
> my @result = ^1000 .hyper.map: * + 10;
> say @result ~~ @result.sort
> 
> Result:
> False
> 
> ｢hyper｣ is supposed to give results in the original order.
> “The order of elements is preserved.” (http://doc.perl6.org/routine/hyper)
> 
> However, the order is definitely messed up.
> 
> Here is an example on camelia:
> 
>  m: my @result = ^10 .hyper(:1batch).map: *+0; say [@result,
> @result.sort]
>  rakudo-moar eca5df: OUTPUT«[[0 2 1 3 4 5 6 8 9 7] (0 1 2 3 4 5 6
> 7 8 9)]␤»
> 
> The output is not consistent, every time you run it you can get a new
> result.

This is working with a recent rakudo, and is closable with tests.

-- 
Will "Coke" Coleda

[perl #126473] [STAR] Unhandled exception: failed to load library 'dynext/libperl6_ops_moar.dylib'

[Will Coleda via RT]

On Wed Oct 28 02:37:08 2015, christian.aperg...@lidil.univ-mrs.fr wrote:
> To avoid this bug, in rakudo 2015.7 we just start rakudo-star-2015.07/perl6
> 
> In the new release rakudo-star-2015.09, this shell is no more present, 
> and starting rakudo-star-2015.09/rakudo/perl6
> returns this message :
> 
> Unhandled exception: failed to load library 'dynext/libperl6_ops_moar.dylib'
> 
> What is the solution ?
> 
> Thanks
> 
> Regards.
> 

These errors predate our first official release in 2015.12  -can you try again 
with a recent star (e.g. 2016.07) and let us know if these errors are still 
occurring? If so, please also let us know which OS you're running.

-- 
Will "Coke" Coleda

[perl #126536] [BUG] error message borked for infix:<< <=> >> and numeric coersion

[Will Coleda via RT]

On Mon Nov 02 03:42:01 2015, gfldex wrote:
> say 'a' <=> 'b';
> # OUTPUT«X::Multi::NoMatch exception produced no message in block 
>  at /tmp/Pc4rxu0Uv1:1»

Works fine now:

$ perl6 -e "say 'a' <=> 'b';"
Cannot convert string to number: base-10 number must begin with valid digits or 
'.' in '⏏a' (indicated by ⏏)
  in block  at -e line 1

Actually thrown at:
  in block  at -e line 1

Closable with tests.
-- 
Will "Coke" Coleda

[perl #128718] Strange error when attempting to redo a supply block

[Will Coleda via RT]

On Sat Jul 23 20:47:04 2016, c...@zoffix.com wrote:
> Not even sure what causes that, but removing the `redo` avoids the error.
> 
> $ perl6 -e 'react { whenever supply { emit 42; redo } { .say } }'
> 42
> No such method 'CALL-ME' for invocant of type 'Bool'
>   in block  at -e line 1
> 
> 

Behavior has changed:

$ perl6 -e 'react { whenever supply { emit 42; redo } { .say } }'
42
Access denied to keep/break this Promise; already vowed
  in any  at 
/Users/coke/.rakudobrew/moar-2016.08.1/install/share/perl6/runtime/CORE.setting.moarvm
 line 1
  in block  at -e line 1

-- 
Will "Coke" Coleda

[perl #81278] Can't defer to return()

[Will Coleda via RT]

On Wed Jul 08 09:55:39 2015, coke wrote:
> On Fri Jan 04 04:38:30 2013, bbkr wrote:
> > On 2012.12:
> >
> >  r: sub f($x) { multi return($nv) { nextwith($nv /2); };
> > return $x; }; say f 6
> >rakudo 70262f: OUTPUT«===SORRY!===␤Method 'is_dispatcher'
> > not found for
> > invocant of class 'Block'␤»
> 
> Pretty much unchanged:
> 
> $ perl6 -e 'sub f($x) { multi return($nv) { nextwith($nv /2); };
> return $x; }; say f 6'
> ===SORRY!===
> Cannot find method 'is_dispatcher'
> $ perl6 --version
> This is perl6 version 2015.06-217-g3776723 built on MoarVM version
> 2015.06-48-g017d184

Updated behavior:

$ perl6 -e 'sub f($x) { multi return($nv) { nextwith($nv /2); }; return $x; }; 
say f 6'
Attempt to return outside of any Routine
  in any call_with_args at gen/moar/m-Metamodel.nqp line 3906
  in sub return at -e line 1
  in sub f at -e line 1
  in block  at -e line 1



-- 
Will "Coke" Coleda

[perl #127889] rakudo build failure for ppc64 archi

[Will Coleda via RT]

On Wed Apr 13 05:09:55 2016, norm...@linux.vnet.ibm.com wrote:
> rakudo build failure for ppc64 archi
> 
> As reported by (1) failure with last tried version rakudo 2016.01
> while the last working version was rakudo 2015.05
> 
> Probably big-endian specific because no failure with ppc64le archi.
> 
> I assume this is related to nqp build failure as reported by (2)
> with version nqp 2016.01
> while last working version was nqp 2015.05
> 
> (1)
> https://build.opensuse.org/package/show/openSUSE:Factory:PowerPC/rakudo
> ===
> [   18s] + /usr/bin/mkdir -p /home/abuild/rpmbuild/BUILDROOT
> [   18s] + /usr/bin/mkdir /home/abuild/rpmbuild/BUILDROOT/rakudo-
> 2016.01-1.1.ppc64
> [   18s] + cd rakudo-2016.01
> [   18s] + perl Configure.pl --prefix=/usr
> [   18s] Found /usr/bin/nqp-m (backend moar)
> [   18s] Unhandled exception: Unsupported serialization format version
> 15 (current version is 16)
> [   18s]at :1
> (/usr/lib64/moar/share/nqp/lib/ModuleLoader.moarvm::16)
> [   18s]  from :1
> (/usr/lib64/moar/share/nqp/lib/nqp.moarvm::6)
>  [   18s]
> [   18s] ===SORRY!===
> [   18s] Unable to read configuration from NQP on MoarVM
> ===
> 
> (2)
> https://build.opensuse.org/package/show/openSUSE:Factory:PowerPC/nqp
> ===
> [  117s] Test Summary Report
> [  117s] ---
> [  117s] t/nqp/59-nqpop.t(Wstat: 0 Tests: 251
> Failed: 1)
> [  117s]   Failed test:  211
> [  117s] Files=112, Tests=4498, 25 wallclock secs ( 0.85 usr  0.26 sys
> + 23.54 cusr  0.66 csys = 25.31 CPU)
> [  117s] Result: FAIL
> [  117s] Makefile:408: recipe for target 'm-test' failed
> ===

Can you try this with this months release of nqp, 2016.08.1  ?

-- 
Will "Coke" Coleda

[perl #128203] S06-advanced/wrap.t in 6.c-errata roast branch fails a test

[Will Coleda via RT]

On Tue Jun 14 19:51:08 2016, c...@zoffix.com wrote:
> It's just a bad test that relies too much on the internal
> implementation of subtest(). The explanation is here (esp. last few
> lines with jnthn++'s explanation):
> https://github.com/rakudo/rakudo/pull/743#issuecomment-210489723

So can we close this RT?

-- 
Will "Coke" Coleda

[perl #127538] BEGIN require Test <>;

[Will Coleda via RT]

On Sat Feb 13 16:21:50 2016, lloyd.fo...@gmail.com wrote:
> BEGIN require Test <>;
> 
> Lexical with name '' does not exist in this frame

Note that this works:

> BEGIN { require Test ""}
(Test)

-- 
Will "Coke" Coleda

[perl #127569] [BUG] lexical packages leak into SETTING::

[Will Coleda via RT]

On Thu Feb 18 18:38:20 2016, lloyd.fo...@gmail.com wrote:
> When a package already exists in an outer scope, any package declared
> will
> insert itself into it even if it's meant to be lexically scoped. This
> includes the SETTING(s) (the most outer scopes). It is also
> problematic for
> our scoped things which manage to transcend the compunit interface's
> encapsulation of their globalish symbols.
> 
> This leads to a number of problems and inconsistencies. I believe it
> will
> be even more relevant when we try and implement jnthn++'s versioning
> design:
> 
> https://6guts.wordpress.com/2016/02/09/a-few-words-on-perl-6-
> versioning-and-compatibility/
> 
> Some examples:
> 
> ## 1 leak out of lexical scope
> {
>my module Cool::Utils { }
> }
> say Cool::Utils;
> 
> ## 2 runtime symbol refers to something different to compile time
> symbol
> with same name
> sub leaked-into {
>   my class Cool::Utils { method doit { "one" } }
>   say Cool::Utils.doit; #->one
>   say ::("Cool::Utils").doit; #->two
> }
> 
> {
>   my class Cool::Utils { method doit { "two" } }
>   leaked-into();
> }
> 
> ## 3 our scoped packages are not available for introspecting in
> CompUnit::Handle.globalish-package;
> 
> # lib/Cool/Utils.pm
> class Cool::Utils {}
> class Foo { };
> 
> # main.pl
> my $cu =
> $*REPO.need(CompUnit::DependencySpecification.new(:short-
> name("Cool::Utils"));
> say $cu.handle.globalish-package.WHO.keys; #-> (Foo)
> 
> # This was one of the things I didn't consider ( and isn't tested in
> require.t -- will do now) which caused problems with my patch.
> # see https://github.com/rakudo/rakudo/pull/714 ugexe's comment.
> 
> 
> 
> Another problem with our scoped packages inserting themselves into the
> setting is that when we have multiple settings which one of them does
> it
> insert it into?
> 
> What if a module like IO::Socket::SSL has 'use v6.c', so it never sees
> the
> 6.d setting. Then someone does:
> 
> use v6.d;
> use IO::Socket::SSL;
> 
> If the 6.c-IO::Socket.WHO === 6.d-IO::Socket.WHO everything will be
> fine,
> but if not IO::Socket::SSL won't be visible to the 6.d code. It could
> copy
> itself to all the settings but that seems ugly to me.
> 
> The solution could be to create a special type of package used for
> declaring sub-packages of packages that already exist in an outer
> scope
> which could search it's own .WHO for the symbol before delegating to
> the
> outer scope package's WHO.

Not all the original code still compiles; can you revisit the request with new 
examples showing the issue?

-- 
Will "Coke" Coleda

[perl #127485] "panda look SomeModule" makes perl6 hang (!!)

[Will Coleda via RT]

Closing ticket since no longer reproducible; adding a test would be nice, but 
probably very difficult.

-- 
Will "Coke" Coleda

[perl #127264] [BUG] Inconsistent file information

[Will Coleda via RT]

On Thu Jan 14 03:33:28 2016, nadim.khe...@gmail.com wrote:
> $?FILE is the path and file name
> 
> callsframe.file returns the file name only

This is no longer an issue in at least 2016.07.1

Closable with tests.

-- 
Will "Coke" Coleda

[perl #126238] LTM does not seem to apply within metaoperators, or does not take new operators in account.

[Will Coleda via RT]

On Thu Oct 01 09:21:34 2015, cognominal wrote:
> LTM does not seem to apply within metaoperators, or does not take new
> operators in account.
> Discussion http://irclog.perlgeek.de/perl6/2015-10-01#i_11304291
> 
> cognominal  m: my token infix:sym<--\>> { "$^a -> $^b\n" }; [~]
> 'a' X[-->] 
> camelia rakudo-moar 92be57: OUTPUT«5===SORRY!5=== Error while
> compiling /tmp/XLcJTzbXjy␤Prefix -- requires an argument, but no valid
> term found␤a/XLcJTzbXjy:1␤--> 3m<--\>> { "$^a -> $^b\n" }; [~] 'a'
> X[--7⏏5>] ␤expecting any of:␤prefix␤»
> moritz  aka "no" :-)
> m:  sub arrow { "$^a -> $^b\n" }; [~] 'a' X[] 
> camelia rakudo-moar 92be57: ( no output )
> cognominal  m:  sub arrow { "$^a -> $^b\n" }; say [~] 'a'
> X[] 
> camelia rakudo-moar 92be57: OUTPUT«a -> b␤a -> c␤␤»
> lichtkind   moritz: something like problem-solver-tutorial ? so we
> have still ame spaces for other tuts
> lizmat  m: my token infix:sym«-->» { "$^a -> $^b\n" }; [~] 'a' X[-->]
> 
> camelia rakudo-moar 92be57: OUTPUT«5===SORRY!5=== Error while
> compiling /tmp/geTg5LpEb8␤Prefix -- requires an argument, but no valid
> term found␤a/geTg5LpEb8:1␤--> 3ym«-->» { "$^a -> $^b\n" }; [~] 'a'
> X[--7⏏5>] ␤expecting any of:␤prefix␤»
> lizmat  cognominal: feels like a rakudobuggable thing to me

FYI, same error with:

18:30 < [Coke]> m: sub infix:sym<--\>> { "$^a -> $^b\n" }; [~] 'a' X[-->] 
# RT #126238
18:30 < synopsebot6> Link:
 https://rt.perl.org/rt3//Public/Bug/Display.html?id=126238
18:30 <+camelia> rakudo-moar 998e2b: OUTPUT«===SORRY!=== Error while compiling
 ␤Prefix -- requires an argument, but no valid term
 found␤at :1␤--> m<--\>> { "$^a -> $^b\n" }; [~] 'a'
 X[--⏏>]  # RT #126238␤expecting any of:␤
 prefix␤»

-- 
Will "Coke" Coleda

[perl #125412] [BUG] using syntax "@a of Int" (multiple times) leads to weird type check errors

[Will Coleda via RT]

On Mon Jun 15 01:43:52 2015, andr...@gmail.com wrote:
> % perl6 -v
> This is perl6 version 2015.05-197-g28a7697 built on MoarVM version
> 2015.05-79-g458940f
> 
> 
> > sub x() returns Array of Int { my @x of Int = 1,2,3 };
> sub x ( --> Array[Int]) { #`(Sub|42347328) ... }
> > x().WHAT.say
> Type check failed for return value; expected 'Array[Int]' but got
> 'Array[Int]'
>   in any return_error at src/vm/moar/Perl6/Ops.nqp:639
>   in sub x at :1
>   in block  at :1
> 
> Redeclaration of routine in REPL causes the following
> 
> > sub x() returns Array of Int { return my @x of Int = 1,2,3 };
> > x().WHAT.say
> Type check failed for return value; expected 'Array[Int]' but got
> 'Array[Int]'
>   in any return_error at src/vm/moar/Perl6/Ops.nqp:639
>   in sub x at :1
>   in block  at :1
> 
> > sub x() returns Array of Int { return my @x of Int = 1,2,3 };
> > x().WHAT.say
> Type check failed for return value; expected 'Array[Int][Int]' but got
> 'Array[Int][Int]'
>   in any return_error at src/vm/moar/Perl6/Ops.nqp:639
>   in sub x at :1
>   in block  at :1
> 
> > sub x() returns Array of Int { return my @x of Int = 1,2,3 };
> > x().WHAT.say
> Type check failed for return value; expected 'Array[Int][Int][Int]'
> but got 'Array[Int][Int][Int]'
>   in any return_error at src/vm/moar/Perl6/Ops.nqp:639
>   in sub x at :1
>   in block  at :1
> 
> > sub x() returns Array of Int { return my @x of Int = 1,2,3 };
> > x().WHAT.say
> Type check failed for return value; expected
> 'Array[Int][Int][Int][Int]' but got 'Array[Int][Int][Int][Int]'
>   in any return_error at src/vm/moar/Perl6/Ops.nqp:639
>   in sub x at :1
>   in block  at :1
> 
> > sub x() returns Array of Int { return my @x of Int = 1,2,3 };
> > x().WHAT.say
> Type check failed for return value; expected
> 'Array[Int][Int][Int][Int][Int]' but got
> 'Array[Int][Int][Int][Int][Int]'
>   in any return_error at src/vm/moar/Perl6/Ops.nqp:639
>   in sub x at :1
>   in block  at :1

This is fine with 2016.07.1 - Closable with tests.
-- 
Will "Coke" Coleda

[perl #125680] [BUG] "..." produces a low-level backtrace; running code from file and with -e is different

[Will Coleda via RT]

On Fri Jul 24 11:26:41 2015, alex.jakime...@gmail.com wrote:
> Code:
> ...
> 
> Result:
> Unhandled exception: Stub code executed
>at :1
> (/home/alex/git/rakudobrew/moar-
> nom/install/share/perl6/runtime/CORE.setting.moarvm:throw:4294967295)
>  from src/gen/m-CORE.setting:17505
> (/home/alex/git/rakudobrew/moar-
> nom/install/share/perl6/runtime/CORE.setting.moarvm:throw:39)
>  from src/gen/m-CORE.setting:17531
> (/home/alex/git/rakudobrew/moar-
> nom/install/share/perl6/runtime/CORE.setting.moarvm:sink:33)
>  from src/gen/m-main.nqp:41
> (/home/alex/git/rakudobrew/moar-
> nom/install/share/perl6/runtime/perl6.moarvm:MAIN:40)
>  from src/gen/m-main.nqp:35
> (/home/alex/git/rakudobrew/moar-
> nom/install/share/perl6/runtime/perl6.moarvm::197)
>  from :1
> (/home/alex/git/rakudobrew/moar-
> nom/install/share/perl6/runtime/perl6.moarvm::8)
>  from :1
> (/home/alex/git/rakudobrew/moar-
> nom/install/share/perl6/runtime/perl6.moarvm::9)
> 
> 
> It seems like I should not see that backtrace. There is no such
> problem
> when using !!! and ???.
> 
> But it goes even further:
> $ perl6 -e '...; 1'
> Stub code executed
>   in block  at -e:1
> 
> Actually thrown at:
>   in block  at -e:1
> 
> 
> As you can see, no stacktrace when running it with -e. However, the
> same
> code (...; 1) running from file gives a backtrace.
> 
> jnthn and moritz discussed that problem a little bit, check out IRC
> log:
> http://irclog.perlgeek.de/perl6/2015-07-24#i_10949235

This no longer behaves differently in a file version on the command line, both 
giving:

Useless use of constant integer 1 in sink context (line 1)
Stub code executed
  in any  at 
/Users/williamcoleda/.rakudobrew/moar-2016.07.1/install/share/perl6/runtime/CORE.setting.moarvm
 line 1
  in block  at -e line 1

Marking test needed.

-- 
Will "Coke" Coleda

[perl #122346] [@LARRY] "nom regression" behavior of lexicals/invoking sub before they are defined changed

[Will Coleda via RT]

On Sun Jul 20 10:33:13 2014, coke wrote:
> S02-names-vars/variables-and-packages.t has several TODO'd tests of
> this sort:
> 
> {
>   nok foo().defined, "get variable not yet declared using a sub (1)";
>   is foo(), 1, "get variable not yet declared using a sub (2)";
>   is foo(), 2, "get variable not yet declared using a sub (3)";
> 
> my $a;
> sub foo { $a++ }
> }
> 
> Where the expectation is that the first call to the foo will return an
> undefined value; in nom, it returns 0.

This behavior has been in place for years now, since before Christmas.

Tagging [@LARRY] to get a ruling on whether the test is any good.

-- 
Will "Coke" Coleda

[perl #128485] "Weird node visited"

[Will Coleda via RT]

On Sun Jun 26 11:42:10 2016, raiph wrote:
> What I did
> ==
> 
> use experimental :macros;
> macro m { quasi {} }
> m
> 
> What I got
> ==
> 
> rakudo-moar e071e4: OUTPUT«Weird node visited: QAST::BVal␤»
> 
> What I expected
> ===
> 
> No output or Nil used in sink context or somesuch.
> 
> Why the message appears
> ===
> 
> TimToady added this error message to Rakudo's Optimizer.nqp as part of
> his Great Sink Refactor commit
> https://github.com/rakudo/rakudo/commit/f95c14402a706579ed49abb72e749dd9fb452cf1
> 
> The error message is the last else in an if/elsif chain that deals
> with all but two -- BVal and CompUnit -- of the 15 QAST node types
> mentioned in
> https://github.com/perl6/nqp/blob/66da2a28b644f0a535f448fb62b4720b0b1201c4/docs/qast.markdown
> 
> Perhaps we just need to add BVal and CompUnit to the final elsif at
> https://github.com/rakudo/rakudo/commit/f95c14402a706579ed49abb72e749dd9fb452cf1#diff-
> c6d4338f0fe083856631860c53453281R1943
> 
> Or perhaps proper sink handling requires one or both of these to be
> individually processed.

macros are experimental and development on them is currently stalled.

Marking ticket as 'stalled'

-- 
Will "Coke" Coleda

[perl #126979] [BUG] Infinite loop on 'my @a[;];'

[Will Coleda via RT]

On Fri Aug 19 10:54:53 2016, coke wrote:
> On Mon Dec 21 06:11:11 2015, andrew.stan...@smoothwall.net wrote:
> > Hi
> > 
> > This statement causes an infinite loop in REPL
> > my @a[;];
> > 
> > This is Rakudo version 2015.11-706-g8622b90 built on MoarVM version
> > 2015.11-113-gbd56e2e
> > implementing Perl 6.b.
> > 
> > Running on Debian8.
> > 
> > Also reproduced on a colleagues computer running Ubuntu.
> > 
> > Thanks
> > Andrew Stanton
> > 
> 
> This isn't a REPL issue, happens with command line as well.

Was still broken in 2016.07.1, but is fixed on rakudo HEAD.

Closable with tests.

-- 
Will "Coke" Coleda

[perl #102994] State variables are never initialized if the first call of the containing block does not reach them

[Will Coleda via RT]

On Sat Nov 05 09:12:36 2011, moritz wrote:
> 16:28 < moritz> perl6: sub f($x) { return if $x == 1; state %h = a => 1;
> say
> %h.perl }; f 1; f 2;
> 16:28 <+p6eval> niecza v11-20-gb962c2f: OUTPUT«{"a" => 1}.hash␤»
> 16:28 <+p6eval> ..pugs b927740: OUTPUT«{("a" => 1),}␤»
> 16:28 <+p6eval> ..rakudo 9c2880: OUTPUT«().hash␤»
> 
> I'm pretty sure that's a bug (and not limited to hashes, same for scalar
> state vars).
> 
> I've added a test to S04-declarations/state.t

Bug still present in rakudo-moar 079da9

-- 
Will "Coke" Coleda

[perl #126979] [BUG] Infinite loop on 'my @a[;];'

[Will Coleda via RT]

On Mon Dec 21 06:11:11 2015, andrew.stan...@smoothwall.net wrote:
> Hi
> 
> This statement causes an infinite loop in REPL
>   my @a[;];
> 
> This is Rakudo version 2015.11-706-g8622b90 built on MoarVM version
> 2015.11-113-gbd56e2e
> implementing Perl 6.b.
> 
> Running on Debian8.
> 
> Also reproduced on a colleagues computer running Ubuntu.
> 
> Thanks
> Andrew Stanton
> 

This isn't a REPL issue, happens with command line as well.

-- 
Will "Coke" Coleda

[perl #125628] x and xx operators are too different

[Will Coleda via RT]

On Sat Jul 18 09:58:45 2015, elizabeth wrote:
> Fixed the “a” x Inf case with 059dac9f0be8c563f1a, tests needed
> 
> Did *not* fix the “a” x *, as per discussion at:
>   http://irclog.perlgeek.de/perl6/2015-07-18#i_10918034
> 
> > On 16 Jul 2015, at 12:59, Alex Jakimenko (via RT)  > follo...@perl.org> wrote:
> >
> > # New Ticket Created by  Alex Jakimenko
> > # Please include the string:  [perl #125628]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=125628 >
> >
> >
> > IRC log: http://irclog.perlgeek.de/perl6/2015-07-16#i_10907791
> >
> > xx throws an error for Inf, -Inf, NaN, but x does not. I believe that
> > these
> > operators should behave similarly in such edge cases.

Based on liz's comment, marking closable with tests.

-- 
Will "Coke" Coleda

[perl #124219] [BUG] Potential missing error text

[Will Coleda via RT]

On Tue Mar 31 12:50:50 2015, drf...@pobox.com wrote:
> OS: Ubuntu Linux 14.04 LTS in VirtualBox
> Host: Windows 8
> Rakudo version: git pull from 25/3/2015
> 
> Issue 1: Are we missing the line:
> 
> -->   token TOP { ⏏ % \n }
> 
> in the error message?
> 
> Issue 2: Should the quantifier be required?
> 
> Assume you're debugging this grammar fragment: " token top-level { 
> * % \, } token list { [  |  ]* % \, } " - A fairly 
> simple (albeit left-recursive) fragment of a common grammar pattern.
> If you're allowed to temporarily delete the quantifiers, $/ 
> is an array reference to a single $/ match, and your actions get 
> what they're expecting, an array.
> If you're not allowed to delete the quantifiers, you get " token 
> top-level {  } token list { [  |  ] } " and 
> $/ is simply a $/, and not $/[0] as your 
> actions expect. So you have to change the actions as well.
> 
> Error:
> --cut here--
> perl6 ~/bug.t
> ===SORRY!=== Error while compiling /home/jgoff/bug.t
> Missing quantifier on the left argument of %
> at /home/jgoff/bug.t:3
> --cut here--
> 
> --cut here--
> grammar Bug {
>token term { a }
>token TOP {  % \n }
> }
> Bug.parse( 'a' );
> --cut here--

This is fixed, and closable with tests.

$ perl6 /tmp/a.p6
===SORRY!=== Error while compiling /tmp/a.p6
Missing quantifier on the left argument of %
at /tmp/a.p6:3
-->token TOP {  %⏏ \n }

-- 
Will "Coke" Coleda

[perl #118407] Importing sub using require causes Null PMC access

[Will Coleda via RT]

On Mon Jun 10 00:32:33 2013, dagurval wrote:
> > say slurp("/tmp/a.pm6")
> sub abc() is export { say "hello" }
> 
> This works (given that it's NYI)
> > require("/tmp/a.pm6") "";
> abc();
> Trying to import symbols  from '/tmp/a.pm6', but it does not export
> anything
> 
> Without the ampersand however,
> > require("/tmp/a.pm6") "abc"; abc();
> Error while compiling block  (source text: "require(\"/tmp/a.pm6\")
> \"abc\"; abc();\n"): Error while compiling op call: Error while compiling
> block : Error while compiling op call: Null PMC access in
> find_method('handle')

This now works, and is closable with tests.
-- 
Will "Coke" Coleda

[perl #127108] [PRECOMP] Inexplicable failure of grammar post-CURI branch

[Will Coleda via RT]

On Tue Jan 19 11:20:59 2016, coke wrote:
> On Tue Jan 19 10:12:08 2016, coke wrote:
> > On Mon Jan 04 11:53:44 2016, coke wrote:
> > > On Thu Dec 31 05:04:23 2015, lue wrote:
> > > > There's unfortunately no real diagnostic I can provide for the
> > > > error
> > > > specifically, since the result of the bug is a failed grammar
> > > > parse.
> > > >
> > > > The grammar of my SUPERNOVA project
> > > > (https://github.com/ShimmerFairy/SUPERNOVA) has been failing
> > > > since
> > > > the
> > > > CURI branch was merged into mainline rakudo, for reasons that are
> > > > unclear. I can verify that switching to a pre-CURI-merge commit
> > > > (e.g.
> > > > 6d9d0f11aba8e2f465c2958a9311d9d4016017ff, the last commit before
> > > > the
> > > > fast-forward merge of CURI) will allow the grammar to work again,
> > > > with
> > > > no changes to SUPERNOVA, thus it's an issue with rakudo.
> > > >
> > > > My attempt to bisect rakudo led to commit
> > > > ac7b2a5a8381d5f255906437d1980c9c3b77e2a5
> > > > (https://github.com/rakudo/rakudo/commit/ac7b2a5a8381d5f255906437d1980c9c3b77e2a5),
> > > > however as you can see the reason why _this_ commit should break
> > > > grammar parsing is a complete mystery. (I may try bisecting again
> > > > sometime to confirm the result.)
> > > >
> > > > Like I said, there's absolutely nothing I provide in terms of
> > > > errors,
> > > > since the only indicator is just the grammar suddenly failing to
> > > > match
> > > > a valid string. It seems to be centered around the "directive"
> > > > multi
> > > > token in my grammar, however I don't have any more specific info
> > > > on
> > > > the location of the issue.
> > >
> > > Even if some golfed code isn't possible, providing explicit
> > > instructions about how to see the breakage would be helpful, e.g.
> > > "check out from this repo, checkout this specific version, run this
> > > specific code, get this result, expect this other result." That
> > > will
> > > at least give others the change to try to golf the problem.
> >
> > Note that bisecting this pre and post Christmas is also difficult
> > because SUPERNOVA depends on Grammar::Parsefail - which you'd
> > normally
> > install with panda, and the behavior here intentionally changed as
> > part of the CURI merge.
> >
> > So a full bisect would involve finding an appropriate version of
> > panda
> > to go with the rakudo commit (and, btw, removing the install
> > directory
> > after each bisect step to insure you're using the version of nqp or
> > moar that goes with that commit.) This makes it very difficult to
> > track down via a bisect. (Not to mention tracking the version of any
> > modules like Grammar::Parsefail over that period)
> >
> > Golfing the test.p6 script (reported elsewhere as a canary for this
> > problem) is probably the easiest way forward at this point.
> 
> Although it's hard to tell since test.p6 isn't a test file, per se, I
> believe that if you apply this patch, you can avoid the bug and
> continue working. Presumbably the CURI branch exposed an already
> existing precompilation issue.
> 
> There might be another RT that already tracks the underlying cause.
> 
> $ git diff
> diff --git a/lib/Grammar.pm6 b/lib/Grammar.pm6
> index df3b332..2f4141f 100644
> --- a/lib/Grammar.pm6
> +++ b/lib/Grammar.pm6
> @@ -1,6 +1,7 @@
>  # Grammar.pm6 --- Pod6 Grammar
> 
> use v6;
> +no precompilation;
> 
> # since this will eventually be plugged into the rakudo
> grammar/actions setup,
> # we need to be as NQP-y as can be reasonably done. Why not just write
> it in NQP
> @@ -1360,4 +1361,4 @@ grammar Pod6::Grammar is Grammar::Parsefail {
>  [ | ]
>]
> }
> -}
> \ No newline at end of file
> +}

Can you retest this (without the no precompilation hack suggested above) with a 
current rakudo and see if you're still having the issue?

-- 
Will "Coke" Coleda

[perl #128947] [BUG] Pair.WHICH confused by "|"s

[Will Coleda via RT]

Closing as a duplicate of the referenced tickets.

-- 
Will "Coke" Coleda

[perl #120443] error message is not compete

[Will Coleda via RT]

On Sun Jul 12 15:10:34 2015, equinox wrote:
> On 7/9/2015 8:30 PM, Will Coleda via RT wrote:
> > On Sat Nov 02 10:31:21 2013, equinox wrote:
> >> C:\rakudo\bin>perl6 -I D:\m\p6\perl6grammer\nqp\src -I
> >> D:\m\p6\perl6grammer  D:\m\p6\perl6grammer\Perl6\Grammar.pm6
> >> [18:20:12] [jaffa4] ===SORRY!===
> >> [18:20:12] [jaffa4] Could not find QRegex in any of:
> >> D:\m\p6\perl6grammer, D:\m\p6\perl6grammer\nqp\src,
> >> C:/rakudo/lib/parrot/5.9.0/languages/
> >>
> >> I report the fact that the error message doesn't give line and file.
> > Can you verify that this is still an issue with a recent rakudo, and
> > also provide a full test  - this appears to depend on files not
> > attached to the ticket.
> >
> Not getting this error in current version.
> 
> test:
> use QRegex:from;
> use NQPP6QRegex:from;
> use NQPP5QRegex:from;
> 
> 
> Jaffa4

This doesn't error for me using 

$ perl6 --version
This is Rakudo version 2016.07.1 built on MoarVM version 2016.07
implementing Perl 6.c.

-- 
Will "Coke" Coleda

[perl #126477] [glr] .assuming on sub with is copy parameter fails

[Will Coleda via RT]

On Wed Oct 28 13:40:45 2015, gfldex wrote:
> sub foo(@a is copy, :$flag){ say @a };
>  my @a = 1,2;
> ((:flag))(@a);
> 
> # OUTPUT«replace this Array is copy logic␤  in sub __PRIMED_ANON at
> EVAL_2:2␤  in sub __PRIMED_ANON at
> EVAL_2:1␤  in block  at /tmp/TlcJQPUFbc:1␤

Coming from:

src/Perl6/Metamodel/BOOTSTRAP.nqp
435:nqp::die('replace this Array is copy logic');

Which is right below a

# XXX GLR

which appears 8 times in rakudo's src/ dir.


-- 
Will "Coke" Coleda

[perl #116186] [GLR] Complex Recursive Sequences

[Will Coleda via RT]

On Sun Dec 23 16:28:31 2012, TimTom wrote:
> 
> Rakudo Version: 2012.12-38-gc8de2eb
> 
> 
> Story:
> 
> 
> I was attempting to write a different solution to the Collatz Sequence
> problem in this years Advent Calendar.  I figured it was a sequence of
> numbers, the sequence operation should be able to rock this problem
> efficiently.  I'm not sure if this is supposed to be supported by the
> implementation, but if it is, I believe the problem comes down to
> Rakudo not liking to vivify later elements in the sequence in order to
> vivify the current element.
> 
> 
> Works:
> my @collatz;
> @collatz := Inf, 1, (2 .. *).map: -> $n {@collatz[$n - 1] + 1}
> say @collatz[0 .. 5]
> > Inf 1 2 3 4 5
> 
> 
> Doesn't Work:
> my @collatz;
> @collatz := Inf, 1, (2 .. *).map -> $n { $n %% 2 ?? @collatz[$n div 2]
> !! @colatz[3 * $n + 1] }
> say @collatz[0 .. 5]
> splice() not implemented in class 'Mu'
>   in method reify at src/gen/CORE.setting:5409
>   in method reify at src/gen/CORE.setting:5407
>   in method gimme at src/gen/CORE.setting:5797
>   in method exists at src/gen/CORE.setting:5786
>   in method at_pos at src/gen/CORE.setting:5766
>   in method postcircumfix:<[ ]> at src/gen/CORE.setting:1337
>   in method postcircumfix:<[ ]> at src/gen/CORE.setting:1384
>   in method postcircumfix:<[ ]> at src/gen/CORE.setting:5042
> 
> 
> -Tim
> irc: Tim-Tom
> 

Neither of these work now (2016.07.1)

The first outputs:

(Inf 1 (...) Nil Nil Nil)

And the second

===SORRY!=== Error while compiling /Users/coke/p6
Unexpected block in infix position (missing statement control word before the 
expression?)
at /Users/coke/p6:2
--> @collatz := Inf, 1, (2 .. *).map⏏ -> $n { $n %% 2 ?? @collatz[$n div 2] 
!
expecting any of:
infix
infix stopper


-- 
Will "Coke" Coleda

[perl #122174] [BUG] Debugger crash!

[Will Coleda via RT]

On Wed Jul 27 10:44:19 2016, coke wrote:
> On Tue Jun 24 05:34:19 2014, andynpar...@googlemail.com wrote:
> > Hello!
> >
> > I am running a syntactically correct program, but the debugger fails
> > giving a large call stack output; see attached.
> >
> > The Perl6 version is:rakudo-star-2014.04/install/bin/perl6-debug-p
> >
> >
> > Andrew Parker
> >
> >
> 
> Hi - sorry no one has replied to your ticket yet; can you verify that
> this is still an issue with Rakudo 2016.07.1, the latest release?

Closing ticket; if this problem persists, please re-open (and include the 
source of the file that caused the issue so we can reproduce it here.)
-- 
Will "Coke" Coleda

[perl #121940] [@LARRY] say True but False # should be 'True' (advent2010-day19)

[Will Coleda via RT]

On Wed May 21 13:36:58 2014, david.warring wrote:
> [08:09]  r: my $value = True but False; say $value
> [08:09] <+camelia> rakudo-jvm 196b4f: OUTPUT«(timeout)»
> [08:09] <+camelia> ..rakudo-{parrot,moar} 196b4f: OUTPUT«False␤»
> ...
> [08:10]  rakudo-jvm is all "WARNING. PARADOX. MUST OVERHEAT."
> [08:11] * dwarring heh
> ...
> [08:11]  I'll put in an rakudobug
> ...
> [08:18]  dwarring: just be aware, camelia has been known to
> timeout on rakudo-jvm.
> [08:18]  dwarring: so it might just be an artifact.
> [08:21]  n: my $value = True but False; say $value
> [08:21] <+camelia> niecza v24-109-g48a8de3: OUTPUT«True␤»
> [08:21]  m: my $value = True but False; say $value
> [08:21] <+camelia> rakudo-moar 196b4f: OUTPUT«False␤»
> [08:21]  I guess it is about that
> [08:22]  this expects 'True' -
> http://perl6advent.wordpress.com/2010/12/19/day-19-false-truth/
> [08:24]  I kind of expect True, too.
> [08:24] == ajr_ [~quas...@96-44-210-169.ip.tor.radiant.net] has quit
> [Ping timeout: 240 seconds]
> [08:25]  r: my $value = True but False; say ?$value
> [08:25] <+camelia> rakudo-{parrot,jvm,moar} 196b4f: OUTPUT«False␤»
> [08:25]  because the *value* is still True, kind of. it's just
> the boolean aspect of it that has been overridden.
> [08:25]  n: my $value = True but False; say ?$value
> [08:25] <+camelia> niecza v24-109-g48a8de3: OUTPUT«False␤»
> [08:25]  niecza++

This is from an old advent post that was pre-Christmas; is this actually a bug 
in current rakudo we should fix, or is the advent post out of date?

-- 
Will "Coke" Coleda

[perl #126818] [PRECOMP] on "is cached" subs: getlex: outer index out of range

[Will Coleda via RT]

On Mon Jan 18 21:22:44 2016, lloyd.fo...@gmail.com wrote:
> This bug just hit me :\. It should go away with 'no precompilation'.
> 
> I believe it's closely related to:
> 
> https://rt.perl.org/Public/Bug/Display.html?id=125634
> 
> On Tue, Dec 8, 2015 at 2:43 AM Zoffix Znet 
> wrote:
> 
> > # New Ticket Created by  Zoffix Znet
> > # Please include the string:  [perl #126818]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=126818 >
> >
> >
> > Steps to reproduce:
> > #
> > $ cat > Foo.pm;
> > unit module Foo;
> > our sub foo () is cached { 42 }
> > $ perl6 -I. -MFoo -e 'say Foo::foo'
> > getlex: outer index out of range
> >   in any enter at gen/moar/m-Metamodel.nqp:3763
> >   in block  at -e:1
> > #
> >
> > The problem goes away if "is cached" trait is removed.
> >

Have to add "use experimental :cached" to Foo.pm to get it to compile these 
days. Then the example dies with:

$ perl6 -I. -MFoo -e 'no precompilation; say Foo::foo'
Cannot invoke this object (REPR: Null; VMNull)
  in block  at 
/Users/coke/.rakudobrew/moar-2016.07.1/install/share/perl6/sources/AAC61C0EC6F88780427830443A057030CAA33846
 (experimental) line 10
  in any enter at gen/moar/m-Metamodel.nqp line 3963
  in block  at -e line 1

The bug goes away when adding "no precompilation;" to Foo.pm

-- 
Will "Coke" Coleda

[perl #128830] [LTA] Error on while (0){}

[Will Coleda via RT]

Re-opening, marking testneeded.
-- 
Will "Coke" Coleda

[perl #128766] Useless use of $a in sink context is spurious

[Will Coleda via RT]

Re-opening, marking testneeded.

-- 
Will "Coke" Coleda

[perl #128749] [RT] Emails sent to perl6-bugs-follo...@perl.org do not replicate on RT ticket

[Will Coleda via RT]

On Thu Jul 28 03:07:13 2016, lloyd.fo...@gmail.com wrote:
> It seems like someone has just done some cleaning of this spam queue
> because responses I sent to
> https://rt.perl.org/Public/Bug/Display.html?id=128553 a couple of weeks ago
> just came through.


There was a subtle race condition in the config processing the mailing list 
that caused some messages to be held - 36 messages hit this issue.

All of them were freed and have been processed.

Closing this ticket.

-- 
Will "Coke" Coleda

[perl #124998] Type of $¢ is Any instead of Cursor

[Will Coleda via RT]

Here's the test:

my $c;
ok 'abc' ~~ /.{ $c = $¢ }/, 'current match state';
#?rakudo todo 'Type of $¢ is Any instead of Cursor - RT #124998'
is $c.WHAT, Cursor.WHAT,'got right type';

This might be a faulty test, however:

19:28 < [Coke]> m: my $c; 'abc' ~~ /.{ say $¢.WHAT }/ ;
19:28 < camelia> rakudo-moar f0abe8: OUTPUT«Nil␤»

If the $¢ assignment in there is Nil, then $c is *going* to default to Any. 

-- 
Will "Coke" Coleda

[perl #124788] Roast rakudo skip/todo test:./S32-io/mkdir_rmdir.t line:12 reason: mkdir rmdir [NYI]

[Will Coleda via RT]

There are many skipped tests for this in 

S32-io/mkdir_rmdir.t

which can be safely unfudged (probably not all, though)

-- 
Will "Coke" Coleda

[perl #125071] Roast rakudo skip/todo test:./S15-unicode-information/uniname.t line:44 reason: :either and :one NYI

[Will Coleda via RT]

This ticket duplicates the individual :one & :either tickets, rejecting.

-- 
Will "Coke" Coleda

[perl #126664] .roll on a Range of Num ain't random

[Will Coleda via RT]

On Fri Nov 27 09:22:20 2015, elizabeth wrote:
> So implemented with  61ea661d8dfc04acabf1eb46c
> 
> 
> Liz
> 
> > On 27 Nov 2015, at 17:17, Patrick R. Michaud 
> > wrote:
> >
> > The standard meaning of ".roll" is to randomly select elements
> > from a list.  So I'd expect .roll on a Range to first convert the
> > Range to a list of values and then select from those.
> >
> > If the intent is to select from the values 0.1, 0.2, 0.3, I'd expect
> > the programmer to write:
> >
> > (0.1, 0.2, 0.3).roll(6)
> >
> > If the intent is to select from a range of values incrementing by
> > 0.1, then:
> >
> > (0.1, 0.2 ... 10.1).roll(6)
> >
> > If the intent is to generate six random Num values from a Range,
> > then it should probably be (I suspect this isn't implemented yet):
> >
> > (0.1 .. 0.3).rand xx 6
> >
> > Pm
> >
> >
> > On Thu, Nov 26, 2015 at 03:36:49PM +0100, Wenzel P. P. Peppmeyer
> > wrote:
> >>
> >> On Thu, 26 Nov 2015, Elizabeth Mattijsen via RT wrote:
> >>
>  (0.1 .. 0.3).roll(10).say;
> >>
> >>> What did you expect?  a selection of 0.1, 0.2, 0.3 ??  or 10 random
> >>> values between 0.1 and 0.3 inclusive?
> >>
> >> I would (naive) expect 10x a value between 0.1 and 0.3 . Analog to:
> >>
> >> (0.1, 0.2, 0.3).roll(10).say;
> >> # OUTPUT«(0.3 0.2 0.1 0.2 0.1 0.2 0.3 0.2 0.2 0.1)␤»
> >>
> >> However, S03 is quite clear how Range is iterating.
> >>
> >> 0.1.succ == 1.1;
> >>
> >> So incrementing by 0.1 can't work. It may be reasonable to fail as
> >> early as
> >> possible for Range.roll on any Range that is neither Int nor Str on
> >> both end
> >> points.
> >>
> >> mfgwp
> >

17:37   [Coke]  lizmat: you last touched 
https://rt.perl.org/Ticket/Display.html?id=126664 - is that closable now?
18:31 < lizmat> [Coke]: probably needs tests still

marking testneeded.
-- 
Will "Coke" Coleda

[perl #123434] [SEGV] CounterMutexSingleton sample crashes

[Will Coleda via RT]

On Fri Oct 30 06:54:00 2015, coke wrote:
> On Mon Dec 15 03:50:26 2014, r...@bastic.net wrote:
> > Hi,
> >
> > please see github.com/rbastic/CounterMutexSingleton
> >
> > This code crashes consistently on the latest MoarVM on Mac OS X
> > 10.9.5
> >
> > It does not crash with the JVM.
> >
> > ab5tract has also helped to work on this and reproduce it FWIW. We
> > can
> > probably provide more details if needed.
> 
> What kind of crash? Please attach the test script here, along with the
> expected results, and the actual results.
> 
> It would be nice if you could reduce the amount of code from 87 lines,
> but I understand this isn't always possible.

Verified, segfault:

$ git clone https://github.com/rbastic/CounterMutexSingleton
...
$ perl6 -v
This is Rakudo version 2016.07.1 built on MoarVM version 2016.07
implementing Perl 6.c.
$ perl6 CounterMutexSingleton.pl6
Segmentation fault: 11

-- 
Will "Coke" Coleda

[perl #122839] Rakudo* 2014:08 panda doesn't see bundled modules

[Will Coleda via RT]

On Sun Feb 08 04:52:40 2015, pmqs wrote:
> Issue is still present in star 2015.01
Many changes in panda and rakudo since then; can you test this with the latest 
rakudo star from 2016.07?

(resend to hit email list)
-- 
Will "Coke" Coleda

[perl #122839] Rakudo* 2014:08 panda doesn't see bundled modules

[Will Coleda via RT]

On Sun Feb 08 04:52:40 2015, pmqs wrote:
> Issue is still present in star 2015.01
Many changes in panda and rakudo since then; can you test this with the latest 
rakudo star from 2016.07?

(resend to hit email list)
-- 
Will "Coke" Coleda

[perl #122839] Rakudo* 2014:08 panda doesn't see bundled modules

[Will Coleda via RT]

On Sun Feb 08 04:52:40 2015, pmqs wrote:
> Issue is still present in star 2015.01

Many changes in panda and rakudo since then; can you test this with the latest 
rakudo star from 2016.07?

-- 
Will "Coke" Coleda

[perl #125501] rakudo moar does not compile on Windows using latest git

[Will Coleda via RT]

On Wed Jul 27 06:06:00 2016, coke wrote:
> Normally when I find an old ticket that says "doesn't build", I'm able
> to close it out, but not today!
> 
> I installed the latest Strawberry Perl 5.24.0.1 (64bit), and used the
> git bash shell to checkout a copy of rakudo (using the https protocol
> and setting my http/https proxy env vars).
> 
> The configure failed for me in about the same place, because the
> "install" directory was not created. After manually creating the
> folder, I reran the original Configure.pl script, which now got to
> building moar, which then died with:
> 
> "unknown OS 'msys'"
> 
> So, two different issues using Strawberry/git bash
> 
> I know that jnthn (core developer) works on windows all the time, but
> uses the MS compiler to build.
> 
> On Sun Jun 28 02:51:11 2015, equinox wrote:
> > Hi,,
> >
> > Using latest git. The rakudo does not compile.
> >
> > L:\rakudo>C:\strawberry16_2\perl\bin\perl.exe Configure.pl
> > --prefix=L:\rakudo\install --backends=moar --make-install
> > --git-protocol=https --gen-moar
> > '"L:\rakudo\install/bin/nqp-m.bat"' is not recognized as an internal
> > or
> > external command,
> > operable program or batch file.
> > M   Configure.pl
> > HEAD is now at a5d6dda... bump moar for nqp::shell/nqp::spawn
> > improvements
> > Building NQP ...
> > C:\strawberry16_2\perl\bin\perl.exe Configure.pl
> > --prefix=L:\rakudo\install --backends=moar --make-install
> > --git-protocol=https --gen-moar
> > Found L:\rakudo\install/bin/moar.exe version 2015.06-44-g2c96984,
> > which
> > is new enough.
> > Cleaning up ...
> >
> > Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
> > Copyright (C) Microsoft Corporation.  All rights reserved.
> >
> >
> > Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
> > Copyright (C) Microsoft Corporation.  All rights reserved.
> >
> > C:\strawberry16_2\perl\bin\perl.exe -MExtUtils::Command -e
> > mkpath gen\moar\stage1\gen
> > C:\strawberry16_2\perl\bin\perl.exe tools\build\gen-cat.pl moar
> > src\how\Archetypes.nqp src\how\RoleToRoleApplier.nqp
> > src\how\NQPConcreteRoleHOW.nqp src\how\RoleToClassApplier.nqp
> > src\how\NQPCurr
> > RoleHOW.nqp  src\how\NQPClassHOW.nqp src\how\NQPNativeHOW.nqp
> > src\how\NQPAttribute.nqp src\how\NQPModuleHOW.nqp
> > src\how\EXPORTHOW.nqp
> >  > gen\moar\stage1\nqpmo.nqp
> > L:\rakudo\install\bin\moar --libpath=src\vm\moar\stage0
> > src\vm\moar\stage0\nqp.moarvm --bootstrap --setting=NULL --no-regex-
> > lib
> > --target=mbc  --output=gen\moar\stage1\nqpmo.moarvm gen\moar\stage1\
> > NMAKE : fatal error U1077: 'L:\rakudo\install\bin\moar.EXE' : return
> > code '0xc005'
> > Stop.
> > Command failed (status 512): nmake
> > Command failed (status 512): C:\strawberry16_2\perl\bin\perl.exe
> > Configure.pl --prefix=L:\rakudo\install --backends=moar --make-
> > install
> > --git-protocol=https --gen-moar
> >
> > Jaffa4
> >

So, maybe we can close this out with some documentation updates on our 
recommend toolchain on windows with strawberry on one side, and the MS tools on 
the other.
-- 
Will "Coke" Coleda

[perl #122174] Debugger crash!

[Will Coleda via RT]

On Tue Jun 24 05:34:19 2014, andynpar...@googlemail.com wrote:
> Hello!
> 
> I am running a syntactically correct program, but the debugger fails
> giving a large call stack output; see attached.
> 
> The Perl6 version is:rakudo-star-2014.04/install/bin/perl6-debug-p
> 
> 
> Andrew Parker
> 
> 

Hi - sorry no one has replied to your ticket yet; can you verify that this is 
still an issue with Rakudo 2016.07.1, the latest release?

-- 
Will "Coke" Coleda

[perl #121117] Dispatch weirdness in REPL

[Will Coleda via RT]

On Thu Jan 30 07:15:52 2014, pmichaud wrote:
> On Wed, Jan 29, 2014 at 06:14:38PM -0800, Mark E. Shoulson wrote:
> >  Consider:
> >
> > multi sub f1(Any $x) { "Any $x" }
> > multi sub f2(Any $x) { f1($x) }
> > multi sub f1(Rat $x) { "Rat $x" }
> >
> > say f2("a");
> > say f2(1.9);
> > say f1(1.9);
> 
> The way the REPL works is that each line of entered input
> ends up in its own (nested) lexical scope.  We've yet to
> find a good solution around this -- in order to complete
> compilation and execution of a line, we kinda have to make
> the current lexical scope concrete.  This is at least
> implied in several sections of the synopses, where the lexical
> symbol table is considered static after compilation completes
> ("CHECK" time, I believe).
> 
> Thus when the lines above are entered one at a time,
> the REPL treats it as:
> 
>{ 
>  multi sub f1(Any $x) { "Any $x" }
> 
>  { 
>multi sub f2(Any $x) { f1($x) }
> 
>{ 
>  multi sub f1(Rat $x) { "Rat $x" }
> 
>  { 
>say f2("a");
> 
>{ 
>  say f2(1.9);
> 
>  { 
>say f1(1.9);
>  }
>}
>  }
>}
>  }
>}
> 
> So, when f2() is executed, the f1(Rat) multi isn't in scope and
> never gets called.
> 
> To think of it another way -- each line of input to the REPL
> is treated like a nested EVAL, thus resulting in its own lexical
> scope.
> 
> At the moment I'm inclined to reject this ticket as "not a bug",
> since Perl 6.0 design seems to constrain anything REPL-like to
> work this way.  But perhaps someone sees a way to have lexical
> scopes that can be more dynamic/interactive, so I'll give time
> for other opinions before closing this.
> 
> Pm

Rejecting ticket.

-- 
Will "Coke" Coleda

[perl #127913] Different implementation of nqp::index for Moar and [JVM] (negative startposition)

[Will Coleda via RT]

On Sun Apr 17 12:51:27 2016, barto...@gmx.de wrote:
> Sorry, I got a bit confused:
> 
> The different behavior for routines index and rindex with negative
> startposition between rakudo-moar and rakudo-jvm was fixed (see
> https://rt.perl.org/Ticket/Display.html?id=126700).
> 
> What's still relevant is the different implementation of nqp::index:
> 
> $ perl6-m -e 'use nqp; say nqp::index("xxy","y",-1)'
> -1
> 
> $ perl6-j -e 'use nqp; say nqp::index("xxy","y",-1)'
> 2
> 
> Output generated with Rakudo version 2016.03-110-g5bfc8fb.

As this has been reduced to a pure NQP issue, I've migrated this ticket to the 
nqp issue tracker, here:

https://github.com/perl6/nqp/issues/301

Please follow the progress of this ticket there.
-- 
Will "Coke" Coleda