[perl #132668] [NATIVECALL][SEGV][SEVERE] OpenSSL PEM_write_bio_RSAPrivateKey

[Aleks-Daniel Jakimenko-Aleksejev via RT]

OK, so that's not an issue in Rakudo then. Closed.

On 2019-03-05 11:16:41, sortiz wrote:
> The problem is the PEM_write_bio_RSAPrivateKey signature used in the
> NativeCall declaration, it missed five arguments.
>
> From the manual:
>
> int PEM_write_bio_RSAPrivateKey(BIO *bp, RSA *x, const EVP_CIPHER
> *enc,
> unsigned char *kstr, int
> klen,
> pem_password_cb *cb, void
> *u);
>
> So when called it received random values.
>
> My modernized example attached that succeds.

[perl #130442] [REGRESSION] [LTA] redo without a loop no longer prints the line number, also claims it is a compile-time error (redo)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Moved to https://github.com/rakudo/rakudo/issues/2725

On 2016-12-29 14:43:03, alex.jakime...@gmail.com wrote:
> Of course, same thing with “next” and “last” (is there anything else?)
>
> On 2016-12-29 09:13:24, alex.jakime...@gmail.com wrote:
> > Code:
> > say 42; redo
> >
> >
> > Result (2015.12,2016.05):
> > 42
> > redo without loop construct
> > in block  at /tmp/rQ_1K_fvaD line 1
> >
> >
> > Result (2016.06,HEAD):
> > 42
> > ===SORRY!===
> > redo without loop construct
> >
> >
> > It should print the line number and it should not say “===SORRY!===”
> > because it is not a compile-time error.
> >
> > Bisectable gives a list of commits that could have caused this:
> > e609822f01b82608b1b1c869032c95e9641172ce
> > 615d30c39eba318f7449b94bbbd0295e2fd75387
> > 8beb87b415014254412409d56378afb3ed5f14d9
> > 05170e0c14969663c816ee1c5aaa019d70938247
> > 899e0fd4c1ce51bc492666ffc69627c502f657f7
> > e5443765d4bce0697c6191dd2b17db3044e027ab
> > fcd0093b43614ce91caeb8c23e2bbcff68d54f72
> > 04929feeb06fa851d77ef5efa6be35248301f88c
> > 7ee6578ce99aae069349c283012ae7e45dfd75ec
> > 519e76487ddd1546b319bfbd47661beac2417d61

[perl #131297] [PERF][REGEX] `|@a` is apparently-equivalent to just `@a` but is 70x slower

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Closing, explanation here: https://github.com/rakudo/rakudo/issues/2708

On 2017-05-12 07:52:34, c...@zoffix.com wrote:
> https://irclog.perlgeek.de/perl6-dev/2017-05-12#i_14572067
>
> 14:49 m: my @a = 1..12; for ('a' x 100 ~ " -- Jan-12-2017")
> xx 100 { when /'-- ' |@a '-' \d**2 '-' \d**4 / { } }; say now - INIT
> now
> 14:49 camelia rakudo-moar 94c4e7: OUTPUT: «4.269762␤»
> 14:49 Zoffix m: my @a = 1..12; for ('a' x 100 ~ " -- Jan-12-2017")
> xx 100 { when /'-- ' ||@a '-' \d**2 '-' \d**4 / { } }; say now - INIT
> now
> 14:49 camelia rakudo-moar 94c4e7: OUTPUT: «0.3336069␤»
> 14:49 Zoffix m: my @a = 1..12; for ('a' x 100 ~ " -- Jan-12-2017")
> xx 100 { when /'-- ' @a '-' \d**2 '-' \d**4 / { } }; say now - INIT
> now
> 14:49 camelia rakudo-moar 94c4e7: OUTPUT: «0.0607072␤»
> 14:49 Zoffix m: say 4.269762/0.0607072
> 14:49 camelia rakudo-moar 94c4e7: OUTPUT: «70.3337001␤»
> 14:49 Zoffix apparently-equivalent but 70x slower
> 14:50 timotimo well well, we still have a lot of
> opportunities to improve these things

[perl #125690] [BUG] Rakudo has stopped matching a regex, related to | vs. ||

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Ticket moved to https://github.com/rakudo/rakudo/issues/2697

On 2015-09-25 14:06:27, duff wrote:
> On Sat Jul 25 12:03:18 2015, moritz wrote:
> > This script here:
> >
> > # BEGIN SCRIPT
> > my grammar PgTokenizer {
> > token double_quote_normal { <-[\\"]>+ }
> > token double_quote_escape { [\\ . ]+ }
> > token double_quote {
> > \"
> > [
> > | <.double_quote_normal>
> > | <.double_quote_escape>
> > ]*
> > \"
> > }
> > token single_quote_normal { <-['\\]>+ }
> > token single_quote_escape { [ \'\' || \\ . ]+ }
> > token single_quote {
> > \'
> > [
> > | <.single_quote_normal>
> > | <.single_quote_escape>
> > ]*
> > \'
> > }
> > token placeholder { '?' }
> > token normal { <-[?"']>+ }
> >
> > token TOP {
> > ^
> > (
> > | 
> > | 
> > | 
> > | 
> > )*
> > $
> > }
> > }
> >
> > say PgTokenizer.parse(q['a\.b''cd?', "\"?", ?])
> > # END SCRIPT
> >
> > use to match successfully (and presumably did with 2015.06, otherwise
> > we'd have had rakudo star test failures), but doesn't match anymore
> > with
> > rakudo 2015.07.
> >
> > If one changes the || to | in single_quote_escape, it matches again.
> >
> > I think this is a bug, because the two alternatives are mutually
> > exclusive, and thus | vs || shouldn't matter.
> >
>
> For someone who has time to actually fix this in case I don't get to
> it:
>
> I bisected rakudo and got
>
https://github.com/rakudo/rakudo/commit/d3785097e46b45eb51e1039c2e3f725dbdcfdf7b
> as the commit that introduced the change. Since this just bumps the
> NQP version, further bisection of nqp showed that
> https://github.com/perl6/nqp/commit/583419120b0ec9a3c2fef1a61e2993526fbebcd5
> was the real culprit.
>
> that's all I've got for now.
>
>
> -Scott (PerlJam/perlpilot)

[perl #133791] perl 6 parser bugging out on a comment thinking it is a real var

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Usually this happens when you have an unclosed string somewhere earlier in your
code.

That is:

say "foo; ← oops! Forgot the closing "

# $a ← we think that this is a comment, but actually it's part of the string
above!
On 2019-01-23 01:27:08, warren.mu...@gmail.com wrote:
> Hello:
>
> I ran into this while setting up a post test for json
> in bailador. While compiling it flags the commented
> line at the end as bad when the fail should be on the
> check of request.body[0].
>
> It happened with the latest rakudo built from scratch
> as of Jan 23rd 2019 as well as rakudo-star 2018.10.
>
> Linux Mint system, 64 bit.
>
>
>
>
> # --->perl6 t1.pl6
> # ===SORRY!=== Error while compiling
> /home/userx/p6d/tests/latester/t1.pl6
> # Variable '%bb' is not declared
> # at /home/userx/p6d/tests/latester/t1.pl6:97
> # --> #pukes here #say ⏏%bb{"name"};
>
> # code snippet that causes the parser to think
> # the commented code below is not commented
> if request.body[0] == "{" { say "JSON"} else {say "NOTJSON"};
>
> # #my %bb = from-json(request.body);
> #
> # this one pukes
> #pukes here #say %bb{"name"};

[perl #75592] [LTA] Long running unclosed quotes trigger unhelpful message

[Aleks-Daniel Jakimenko-Aleksejev via RT]

I'm slightly confused by this ticket… isn't it resolved now? Nowadays you get
an error message like this:

Unable to parse expression in single quotes; couldn't find final "'"
(corresponding starter was at line 2)

So while it blows up at the end of the file, it still mentions where the quote
started. Sooo… fixed? I'm struggling to understand what these code samples were
supposed to demonstrate.

On 2010-06-07 14:23:47, cognominal wrote:
> I am probably a lousy programmer but I hit again and again that
> unhelpful message.
>
> How to reproduce :
>
> eval "{\n\n\n\n\'}"
>
> Unable to parse blockoid, couldn't find final '}' at line 1
>
> Note that the opening quotes are many lines below the start of the
> blockoid and there may be many statements between them.
> So the line number in the error is unhelpful.
>
> In the simplest case, the quote rules fails because the end of the
> file has been reached. I don't see the need
> to backtrack and to fail the blockoid.
>
> In more complicated cases, the quote rule reduces but it eats way more
> characters than the programmer intended
> inluding '}' chars that should terminate blockoids. The result is
> triggering the same message or some others. I don't know if there is a
> way to detect the true problem instead of emitting spurious messages.
> Probably we should indicate the
> reduced quotes involving many lines as suspicious when failing to
> reduce a blockoid. They are bad style anyway because
> heredocs are the preferred style for many lines quoted stuff. But
> heredocs are not implemented yet.
>
>
>
>
>

[perl #131392] [@LARRY] Remove magic $/ shortcuts %() and @()

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Further discussion on https://github.com/rakudo/rakudo/issues/1946

On 2017-05-28 21:20:08, c...@zoffix.com wrote:
> On Sun, 28 May 2017 18:18:14 -0700, raiph wrote:
> > If there hasn't been significant adoption of these tokens in extant
> > code then I'd personally +1 deprecation of them in v6.d in favor of
> > `%$/` and `@$/`.
>
> +1. Even knowing $() was special, it didn't occur to me %() and @()
> could be special too. While $() saves some typing, the %() vs %$/ are
> no win IMO.
>
> I listed removal as a proposal in 6.d doc:
> https://github.com/perl6/specs/blob/master/v6d.pod
>
> Renaming this ticket to @LARRY/6.d RFC

[perl #133268] MoarVM with empty CONTROL {}

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Golf:

CONTROL {}; warn 42

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

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

[Aleks-Daniel Jakimenko-Aleksejev via RT]

The issue with .unique was resolved in these commits

Rakudo:
https://github.com/rakudo/rakudo/commit/8cd70d1ee3e17fad78ae5daf0890d1cfb74c2deb
Roast:
https://github.com/perl6/roast/commit/ad38801161c518a3cf3bca9012db973851c4b0c3
Roast:
https://github.com/perl6/roast/commit/032ce8df8533da3c5ff85c22720fe01324dd5adf

On 2017-03-06 05:48:07, c...@zoffix.com wrote:
> Another issue the .REDUCE-ME thing causes:
>
> mscha │ m: say (1/2+1/2, 2/2).unique;
> +camelia │ rakudo-moar 9da50e: OUTPUT: «(1 1)␤»
>
> infix:<+> does not call .REDUCE-ME so the rats are different in this case

[perl #132281] [REGRESSION] .gist of a bag used to say “bag()”, now it says “Bag()” ("blogger".comb.Bag)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

https://github.com/rakudo/rakudo/pull/1722#issuecomment-380779444

On 2017-10-12 22:37:24, alex.jakime...@gmail.com wrote:
> Code:
> say "blogger".comb.Bag # if you want for all the letters
>
> ¦«2015.12»:
> bag(r, l, g(2), b, e, o)
>
> ¦«2016.06»:
> bag(r, l, g(2), b, e, o)
>
> ¦«2016.12»:
> bag(r, l, g(2), b, e, o)
>
> ¦«2017.06»:
> bag(e, l, b, g(2), o, r)
>
> ¦«f72be0f130cf»:
> Bag(b, e, g(2), l, o, r)
>
>
> Possible IRC discussion: https://irclog.perlgeek.de/perl6/2017-10-
> 09#i_15278073
>
>
> Bisectable: (2017-07-20)
>
https://github.com/rakudo/rakudo/commit/21b9a720c75656b13805611544aa5ee64c4924ae
>
>
> To be honest, I don't know if that's a reasonable ticket. I guess it
> doesn't really matter if it's bag or Bag, but I'm pretty sure that the
> change was unintentional so I'm submitting it as a ticket.
>
> Maybe “bag()” is better because it resembles an actual syntax. Kind
> of. Judge yourself.

[perl #122980] [BUG] LTA error message on fairly strange input, complaining about the lack of a semicolon when the semicolon's right there in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Tests were added in this PR: https://github.com/rakudo/rakudo/pull/1715

Closing

On 2017-12-02 04:17:46, alex.jakime...@gmail.com wrote:
> Not quite sure what to do with this ticket.
>
> The output varies across releases:
> https://gist.github.com/Whateverable/54e87afdbb2d88d2a959527b255681af
>
> So at some point it started complaining about “Invalid type smiley
> 'erator'”,
> and so it's no longer possible to reproduce the original issue. I
> tried some
> other things but I can't get it to print something similar.
>
> In any case, there are these two tickets RT#125596 RT#125674 which
> were
> resolved in
>
https://github.com/rakudo/rakudo/commit/5747bc7121ba68bea210d1a75bb0e197377b287c
>
> I think the original problem should no longer be there.
>
> Marking as ｢testneeded｣, maybe someone will come up with a way to
> reproduce it
> when writing tests.
>
> On 2015-03-11 07:50:45, barto...@gmx.de wrote:
> > Rakudo no longer complains about a missing semicolon, but fails with
> > X::Syntax::Confused.
> >
> > The error message differs from what STD complained about, though:
> >
> > $ perl6 -e 'Int:erator:$;'
> > ===SORRY!=== Error while compiling -e
> > Confused
> > at -e:1
> > --> Int:erator:$⏏;
> > expecting any of:
> > colon pair

[perl #126752] [BUG] $/ vs .hyper gets confused

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Test added in
https://github.com/perl6/roast/commit/1f171a9d2f0dd973a5e0d5c0c34a6f50b91da81f

Closing

On 2018-03-08 10:28:12, jan-olof.hen...@bredband.net wrote:
> On Fri, 27 Nov 2015 12:30:15 -0800, zengargo...@gmail.com wrote:
> > autarch noticed an oddness in File::Temp when used with .hyper:
> > https://gist.github.com/autarch/a701c62a40643169913f
> >
> > Seems to be golfable to this:
> >
> > sub foo() { my $x = "*" x 2; $x ~~ s/ "*" ** 1..* /{ "+" x $/.chars
> > }/; $x}; (1..100).map({say foo});
> >
> > Make that (1.100).hyper.map ... and bad things happen.
>
> Fixed with commits 739d1a3f1c48656daf418967089e74f5f280f518 and
> 61a77e60a7d936415503d8916fcc7546569e9135. Tests needed.

[perl #126394] [BUG] Assigning Failure to typed variable swallows Failure information

[Aleks-Daniel Jakimenko-Aleksejev via RT]

jmerelo++, tests added in
https://github.com/perl6/roast/commit/ce173d4c6602333fac3dc8c1c8c2ec1b0b07c0ae

Closing

On 2015-10-19 07:43:11, larry wrote:
> On Mon Oct 19 07:02:44 2015, elizabeth wrote:
> > Fixed with a31cc91a0d604a8a74529 . Tests are still needed
> >
> > > On 19 Oct 2015, at 03:42, Carsten Hartenfels (via RT)  > > follo...@perl.org> wrote:
> > >
> > > # New Ticket Created by Carsten Hartenfels
> > > # Please include the string: [perl #126394]
> > > # in the subject line of all future correspondence about this
> > > issue.
> > > # https://rt.perl.org/Ticket/Display.html?id=126394 >
> > >
> > >
> > > This bug is for Rakudo version 2015.09-419-gfae01fb built on MoarVM
> > > version 2015.09-79-gee9fc2b, according to `perl6 --version`.
> > >
> > > The following code, in `t.pl`:
> > >
> > > sub s { fail 'important failure message' }
> > > my Int $x = s();
> > > say $x;
> > >
> > > will output:
> > >
> > > Type check failed in assignment to $x; expected Int but got Failure
> > > in block  at t.pl:2
> > >
> > > But it omits the important failure message, as well as where it was
> > > actually thrown. Opposed to that, omitting the type:
> > >
> > > sub s { fail 'important failure message' }
> > > my $x = s();
> > > say $x;
> > >
> > > will output the much more useful message:
> > >
> > > important failure message
> > > in sub s at t.pl:1
> > > in block  at t.pl:2
> > >
> > > Actually thrown at:
> > > in block  at t.pl:3
> > >
> > > This seems to make typed variables much less useful, since they
> > > potentially eat failure messages every time you assign to them.
> > >
> > > Ideally, the type check message would include the failure
> > > information
> > > too, something like:
> > >
> > > Type check failed in assignment to $x; expected Int but got Failure
> > > important failure message
> > > in sub s at t.pl:1
> > > in block  at t.pl:2
>
>
> The existing 'method priors' wasn't working correctly due to a
> precedence error originally made by TimToady-- that ate the priors
> result as part of the ??!! conditional. Simply adding a "do" fixes
> that and renders the previous patch unnecessary. Fixed in
> 48a0888cced2e772d9b347460a69507fc822bd2d (tests still needed).

[perl #125384] Could not find symbol '' in installed module, local version works fine.

[Aleks-Daniel Jakimenko-Aleksejev via RT]

jmerelo++ brought this ticket to my attention during the squashathon and
suggested that this ticket can be closed.

I've tried reproducing the issue with the provided tarball and couldn't. In
fact, the Makefile in that tarball no longer works as expected because things
are very different now. Moreover, panda was replaced by zef.

I think an issue like this will be promptly noticed today, and chances are we
have tests for it already. I think after 3 years we can confidently say that
this particular ticket outlived itself.

Closing without tests, please file a new ticket if you see similar issues.

On 2017-12-02 20:04:23, alex.jakime...@gmail.com wrote:
> This is no longer reproducible (2017.11,HEAD(e5b660e)), and RT#122773
> seems to
> be resolved.
>
> Any chance we can have a test for it? If not, maybe we can close this
> particular ticket without tests…
>
> On 2015-06-10 19:52:34, r...@hoelz.ro wrote:
> > On Wed Jun 10 19:52:14 2015, r...@hoelz.ro wrote:
> > > On Wed Jun 10 19:45:42 2015, davidnmfarr...@gmail.com wrote:
> > > > When I clone my Perl 6 repo Pod::Perl5, and use it, it runs fine.
> > > > When
> > > > I install the module using panda and try to use it, I get an
> > > > error:
> > > >
> > > > "Could not find symbol ''
> > > > in block  at -e:1"
> > > >
> > > > Steps to reproduce
> > > > --
> > > > git clone https://github.com/dnmfarrell/Pod-Perl5
> > > > cd Pod-Perl5
> > > > perl6 -Ilib -MPod::Perl5 -e 'Pod::Perl5::parse-
> > > > string("=pod\n\n")'
> > > > panda install ./
> > > > perl6 -MPod::Perl5 -e 'Pod::Perl5::parse-string("=pod\n\n")'
> > >
> > > I managed to golf it down quite a bit; see the attached tarball.
> >
> > Sounds similar to https://rt.perl.org/Ticket/Display.html?id=122773

[perl #131858] [REGRESSION] default $.nl-in on IO::Handle does not correctly work in subclasses

[Aleks-Daniel Jakimenko-Aleksejev via RT]

There's now a regression test in
https://github.com/perl6/roast/commit/a7af87465e0dc593f4e008d6dcfe077f1bbff0f1

Closing (but please take a look at that roast commit)

On 2018-03-11 13:11:21, jan-olof.hen...@bredband.net wrote:
> On Tue, 08 Aug 2017 04:19:24 -0700, elizabeth wrote:
> > reverted c63c57e9a823303e74c06 for now
> >
> > > On 8 Aug 2017, at 12:21, Zoffix Znet (via RT)  > > follo...@perl.org> wrote:
> > >
> > > # New Ticket Created by Zoffix Znet
> > > # Please include the string: [perl #131858]
> > > # in the subject line of all future correspondence about this
> > > issue.
> > > # https://rt.perl.org/Ticket/Display.html?id=131858 >
> > >
> > >
> > > Currently, this causes breakage in IO::String
> > >
> > > zoffix@VirtualBox~$ perl6 -e 'class Z is IO::Handle { method x { dd
> > > $.nl-in } }.new.x;'
> > > $["\n"]
> > >
> > > zoffix@VirtualBox~$ perl6 -v
> > > This is Rakudo version 2017.07-138-ga91ad2d built on MoarVM version
> > > 2017.07-318-g604da4d
> > >
> > > Above, it should give the two-element array, with "\r\n" as another
> > > element.
> > >
> > > AlexDaniel bisected my original code[^1] to point to
> > > https://gist.github.com/Whateverable/b26f4103f5da0809e11749b50fdbabb4
> > > ¦c63c57e9a823^: «"hello,"» ¦c63c57e: «"hello,\r\nworld!\r\n"»
> > >
> > > I tried to golf it further, by taking all the relevant bits from
> > > IO::Handle into a custom class, but failed to reproduce the issue
> > > then.
> > >
> > > [1]
> > > https://gist.github.com/zoffixznet/0c2cbd7acaaf0d3b27d245ad2e2bc737
>
> It seems as if everything is still good after the revert
> ((2017-08-08)
>
https://github.com/rakudo/rakudo/commit/67455170ca50bb908f309b77e5ca579eaa21605c
> ),
> tests needed,

[perl #131623] [BUG] Range + detached method + map with = "Cannot find method 'count' on object of type NQPMu"

[Aleks-Daniel Jakimenko-Aleksejev via RT]

A test for this issue was already added in
https://github.com/rakudo/rakudo/commit/f3efe5e6b4a9ee5#diff-2aaee6bee3c5525182362ffdcbea1f2cR14

Closing.

On 2018-03-10 16:40:40, jan-olof.hen...@bredband.net wrote:
> On Thu, 22 Jun 2017 05:25:08 -0700, c...@zoffix.com wrote:
> > A WhateverCode detached map or a  undetached map works fine:
> > m: ^2 .map: *.say
> > rakudo-moar 86e7b2: OUTPUT: «0␤1␤»
> > m: (^2).map: 
> > rakudo-moar 86e7b2: OUTPUT: «0␤1␤»
> >
> > But explodes if you try to both detache and use the  map:
> > m: ^2 .map: 
> > rakudo-moar 86e7b2: OUTPUT: «===SORRY!===␤Cannot find method
> > 'count' on object of type NQPMu␤»
>
> Fixed with commit
>
https://github.com/rakudo/rakudo/commit/f3efe5e6b4a9ee59f71ca11cb90ef78539be45e3

[SPAM:##] [perl #126014] Too many repetitions with xx operator causes out of memory; should it work lazily?

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Tests in
https://github.com/perl6/roast/commit/b320464868d3b8da98c090ddc4b0d57604683e13

Closing

On 2018-03-10 11:25:06, jan-olof.hen...@bredband.net wrote:
> On Wed, 22 Feb 2017 03:59:05 -0800, elizabeth wrote:
> > > On 22 Feb 2017, at 12:41, jn...@jnthn.net via RT  > > follo...@perl.org> wrote:
> > > On Sat, 30 Apr 2016 03:42:00 -0700, alex.jakime...@gmail.com wrote:
> > >> OK, I said that it only segfaults on 32-bit systems, but I was
> > >> wrong.
> > >>
> > >> Code:
> > >> 42 xx (2 ** 62)
> > >>
> > >> Result:
> > >> Segmentation fault
> > >>
> > > This is patched in MoarVM HEAD just now and no longer SEGVs
> > > (reports
> > > the array is too long to allocate). So, no longer a SEGV bug.
> > >
> > > However, I'm a bit surprised that xx does not work lazily, and
> > > actually makes such a huge array up-front. Not sure if we want to
> > > re-
> > > purpose the ticket for that; I'll remove the SEGV from the title,
> > > however, since that is resolved.
> >
> > Ah, yes, I remember we discussed this. I’ll make it a Seq, although
> > the question then becomes: should it be lazy or not? If it is not
> > lazy, we would just be postponing the exception in some cases.
> >
> >
> > Liz
>
> Fixed with commit
>
https://github.com/rakudo/rakudo/commit/1eb7b1f796214870b53c7ed055907cb29076dc78

[perl #126312] [BUG] `for @a` is not creating containers for uninitialized elements

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Tests added in
https://github.com/perl6/roast/commit/d78f33966cf6a6ec6bc060d98dfc521ad59b6f75

Closing

On 2018-02-06 14:12:56, jan-olof.hen...@bredband.net wrote:
> On Sat, 07 May 2016 13:26:09 -0700, sml...@gmail.com wrote:
> > Confirmed on current Rakudo.
> >
> > Interestingly, it works if `for @a` is replaced with `for @a[*]`:
> >
> > ➜ my Int @a; @a[5] = 42; $_ = 100 for @a[*]; say @a;
> > [100 100 100 100 100 100]
>
> Seems to have been fixed with Rakudo commit
> 069b789af545dff30d450618fae82ccb82579346.
> Tests needed.

[SPAM:##] [perl #132030] [TESTNEEDED] [REGRESSION] Broken Text::CSV tests and possibly other ecosystem fallout (buffering)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Tests added in
https://github.com/perl6/roast/commit/40edf6d2c939fe095a848056db3489d7b1482a8a

I think we can close this.

On 2017-09-16 19:58:20, alex.jakime...@gmail.com wrote:
> Two of the mentioned modules have pending pull requests that add
> missing .close
> calls in tests. NCurses module is trickier, but arguably the failing
> test is a
> little bit wrong. See this discussion for more info:
> https://github.com/azawawi/perl6-ncurses/issues/16
>
> In other words, the ecosystem is fine. I'm still seeing some weirdness
> when
> running ｢prove｣, but hopefully that is unrelated.
> On 2017-09-13 23:06:58, alex.jakime...@gmail.com wrote:
> > CSS::Specification and CSS::Module:
> > https://github.com/p6-css/CSS-Specification-p6/issues/2
> >
> > That's basically it. We won't see any other affected modules from
> > toaster data.
> > On 2017-09-13 18:54:42, alex.jakime...@gmail.com wrote:
> > > NCurses, Term::Choose, Term::Choose::Util, and Term::TablePrint:
> > > https://github.com/azawawi/perl6-ncurses/issues/16
> > >
> > > This one is weird because it seems to be working unless you run it
> > > under prove.
> > > Perhaps the module is alright but it's the test that is broken.
> > >
> > > On 2017-09-13 18:16:56, alex.jakime...@gmail.com wrote:
> > > > FWIW there is still some ecosystem fallout (possibly very minor).
> > > > I'll be
> > > > linking issues here so that we have all things in one place.
> > > >
> > > > IO::MiddleMan and Lumberjack:
> > > > https://github.com/zoffixznet/perl6-IO-MiddleMan/issues/5
> > > > On 2017-09-11 04:18:39, elizabeth wrote:
> > > > > Fixed with 3c9cfdba88287e23e0ced8 (and further refined by later
> > > > > commits), tests needed.
> > > > >
> > > > > > On 6 Sep 2017, at 15:38, jn...@jnthn.net via RT  > > > > > follo...@perl.org> wrote:
> > > > > >
> > > > > > On Tue, 05 Sep 2017 09:11:19 -0700, allber...@gmail.com
> > > > > > wrote:
> > > > > >> On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via RT <
> > > > > >> perl6-bugs-follo...@perl.org> wrote:
> > > > > >>
> > > > > >>> Failing to close output handles has been clearly documented
> > > > > >>> (and
> > > > > >>> yes,
> > > > > >>> documented well before the recent buffering change) as
> > > > > >>> something
> > > > > >>> that can
> > > > > >>> cause data loss. Default output buffering just makes it
> > > > > >>> quite
> > > > > >>> a
> > > > > >>> lot
> > > > > >>> more
> > > > > >>> likely to show up.
> > > > > >>>
> > > > > >>> While there will be some ecosystem fallout like this,
> > > > > >>> unfortunately
> > > > > >>> I
> > > > > >>> don't think it's avoidable. If we whip out the patch that
> > > > > >>> turns
> > > > > >>> output
> > > > > >>> buffering on by default for non-TTYs for this release, then
> > > > > >>> when
> > > > > >>> will we
> > > > > >>> include it? The longer we leave it, the more painful it
> > > > > >>> will
> > > > > >>> be,
> > > > > >>> because
> > > > > >>> more code will be written that is careless with handles.
> > > > > >>>
> > > > > >>> I don't think "leave it off by default" is a good option
> > > > > >>> either,
> > > > > >>> otherwise
> > > > > >>> we get to spend the next decade hearing "Perl 6 I/O is
> > > > > >>> slow"
> > > > > >>> because it'd
> > > > > >>> be one of the only languages that doesn't buffer its output
> > > > > >>> without
> > > > > >>> an
> > > > > >>> explicit flag being passed to enable that (which nearly
> > > > > >>> nobody
> > > > > >>> doing quick
> > > > > >>> benchmarks will know to use).
> > > > > >>>
> > > > > >>
> > > > > >> Are we missing something to flush/close handles at exit?
> > > > > >> Leaving
> > > > > >> it
> > > > > >> to a GC
> > > > > >> that may not finalize before exit is not really an option.
> > > > > >>
> > > > > > To recap the IRC discussion yesterday: no, we haven't had
> > > > > > this
> > > > > > so
> > > > > > far
> > > > > > (except for stdout/stderr), and have gotten away with it due
> > > > > > to
> > > > > > the
> > > > > > lack of output buffering. At present, we can either choose
> > > > > > between:
> > > > > >
> > > > > > 1) Start keeping a list of open files, and at exit close them
> > > > > > (flushing is already part of closing). This can be done at
> > > > > > Perl
> > > > > > 6
> > > > > > level, in the same place we make sure to run END blocks.
> > > > > >
> > > > > > 2) Having unclosed handles possible to GC, and closing them
> > > > > > if/when
> > > > > > they get GC'd.
> > > > > >
> > > > > > Today we are doing #2. We could switch to doing #1. We can't
> > > > > > currently do both, because the moment we start keeping a list
> > > > > > of
> > > > > > open
> > > > > > handles then they can't be GC'd, and so #2 can't happen.
> > > > > >
> > > > > > My initial inclination was to preserve behavior #2, though
> > > > > > others
> > > > > > have pointed out that behavior #1 is more useful for
> > > > > > debugging
> > > > > > in
> > > > > > that it ensures log files, for example, will be written in
> > > > > > 

[perl #130941] infix: keeps containers around since October, resulting in confusing behaviour

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Tests in
https://github.com/perl6/roast/commit/1a42efd4ce0fdc695b16bbf64af92ecf0bca1866

On 2018-03-10 10:43:14, alex.jakime...@gmail.com wrote:
> This ticket now needs tests, further discussion related issues here:
> https://github.com/rakudo/rakudo/issues/1607
>
> On 2017-03-08 05:56:13, c...@zoffix.com wrote:
> > A temporary fix has been committed in
> >
>
https://github.com/rakudo/rakudo/commit/5b7b7fb5c942a3e74097b5eb94a22be262f74c9f

[perl #126490] [BUG] Control exception handling is inconsistent and broken across backends. (SEGV on moar, CX unrecognized on jvm)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Segfault mentioned above is already tested and the test was unfudged in
https://github.com/perl6/roast/commit/ef7b0da83d#diff-72b101ff62a0582672d4de2788ffa1bbL77

Closing
On 2018-03-12 08:29:49, jan-olof.hen...@bredband.net wrote:
> On Mon, 16 Oct 2017 13:04:48 -0700, barto...@gmx.de wrote:
> > On Sat, 16 Jul 2016 13:18:42 -0700, barto...@gmx.de wrote:
> > > I unfudged one test for this ticket in S04-statements/label.t with
> > > commit https://github.com/perl6/roast/commit/ef7b0da83d
> > >
> > > The code that used to segfault works fine now:
> > >
> > > $ perl6-m -e 'A: for 1 { for 1 { last A }; CONTROL { when CX::Last
> > > {
> > > say "last" }; default { .perl.say } } }'
> > > last
> > >
> > > $ perl6-j -e 'A: for 1 { for 1 { last A }; CONTROL { when CX::Last
> > > {
> > > say "last" }; default { .perl.say } } }'
> > > last
> > >
> > > The mentioned failing tests for rakudo-j are still a thing, tough.
> >
> > The remaining tests fudged with this ticket are passing with rakudo-j
> > now. I unfudged them with commit
> > https://github.com/perl6/roast/commit/07517a0006
>
> Fixed with commit
>
https://github.com/rakudo/rakudo/commit/1fbb8b4053cba722567b1e376c4a3f655b55e42b
> at least on MoarVM.

[SPAM:##] [perl #130505] [LTA] double SORRY (BEGIN (1, 2)[*-1])

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Tests in
https://github.com/perl6/roast/commit/79dff96fc9f383616dd192ef016725395323887b
and
https://github.com/perl6/roast/commit/82d3a883a52af23c8a67e46b88b313b3cf20b18d

On 2018-03-10 06:26:00, jan-olof.hen...@bredband.net wrote:
> On Wed, 04 Jan 2017 15:02:45 -0800, alex.jakime...@gmail.com wrote:
> > Code:
> > BEGIN (1, 2)[*-1]
> >
> > Result:
> > ===SORRY!=== Error while compiling 
> > An exception occurred while evaluating a BEGIN
> > at :1
> > Exception details:
> > ===SORRY!=== Error while compiling
> > Cannot invoke this object (REPR: Null; VMNull)
> > at :
> >
> >
> > Once is enough, especially given that it says “at : ” which is not
> > useful.
>
>
> Fixed with commit
>
https://github.com/rakudo/rakudo/commit/7c1f0b416d37415bb25a3a6974aaa3635f5d1225

[perl #126318] [BUG] trait 'is default' on attributes has no effect

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Tests in
https://github.com/perl6/roast/commit/ce1a5a2e6b5b199c0df69a83cf66f1b830ee47e8
and
https://github.com/perl6/roast/commit/38c9dc5fd5339ed434438eb58bae07e7fdd31a1d

Closing.

On 2018-03-12 06:59:31, jan-olof.hen...@bredband.net wrote:
> On Wed, 13 Sep 2017 19:17:16 -0700, b...@abrij.org wrote:
> > On Wed, 13 Sep 2017 19:15:36 -0700, b...@abrij.org wrote:
> > > On Fri, 16 Oct 2015 00:54:21 -0700, larry wrote:
> > > > On Sat Oct 10 08:33:13 2015, FROGGS.de wrote:
> > > > > say class { has Int $.foo is default(0) }.new.foo
> > > > > rakudo-moar 025ec1: OUTPUT«(Int)␤»
> > > > >
> > > > > class Foo { has Int $.foo is default(0) }; say Foo.new.foo
> > > > > rakudo-moar 025ec1: OUTPUT«(Int)␤»
> > > > >
> > > > > I would expect that foo is zero in both cases.
> > > >
> > > > Even less sensical, it violates its own :D here:
> > > > > p6 'say class { has Int:D $.foo is default(0) }.new.foo'
> > > > (Int:D)
> > >
> > > The first case was resolved with RT#131387
> > >
> > > The second case seems fixed.
> > >
> > > Tests specifically for the second case still needed.
> > >
> > >
> > >
> > >
> > > So maybe combine this with the latter and make a ruling on
> >
> >
> > Ignore that last sentence, I was going to suggest RT#126296 but...
>
> Second case fixed with commit
>
https://github.com/rakudo/rakudo/commit/148ba7f2e4de8f33e8436267a4b0c9042a171d82
> Testneeded

[perl #133017] First intermediate value of reduction with zip operator

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Some extra info:

Output on all releases (not a regression because the output was always wrong):
https://gist.github.com/b4b27b8088a230a6051d634dc7b2d13e

The change in behavior happened in (2017-03-21)
https://github.com/rakudo/rakudo/commit/16f950b30572e0fa584ddfab1e84e5ef0ca5dfc9

Which links to RT#131009 ( https://rt.perl.org/Ticket/Display.html?id=131009 )


Also, FYI, we also accept bug reports on github:
https://github.com/rakudo/rakudo/issues

On 2018-03-23 07:16:22, wellnho...@aevum.de wrote:
> When using a reduction operator with the "intermediate results" option
> combined with a zip operator, e.g. [\Z+], the first intermediate value
> is wrong:
>
> say [\Z+] (1, 2, 3), (10, 20, 30), (100, 200, 300);
> # got: ((6) (11 22 33) (111 222 333))
> # expected: ((1 2 3) (11 22 33) (111 222 333))
>
> Reduction with hyper operators like [\<<+>>] seems to work.
>
> Only tested online on tio.run
>
> Rakudo version 2017.12 built on MoarVM version 2017.12
> implementing Perl 6.c.
>
> and code-golf.io:
>
> Rakudo version 2018.03 built on MoarVM version 2018.03
> implementing Perl 6.c
>
> Nick

[perl #133016] Wrong set difference of Bag and List

[Aleks-Daniel Jakimenko-Aleksejev via RT]

FWIW bisectable points to (2017-06-25)
https://github.com/rakudo/rakudo/commit/a2133dbc6a00d1f87bb0644c829591144381d736

( before that it was giving bag(a, b) or bag(b, a) )

On 2018-03-24 01:43:59, elizabeth wrote:
> That does indeed look wrong to me, investigating
>
> > On 23 Mar 2018, at 15:04, Nick Wellnhofer (via RT)  > follo...@perl.org> wrote:
> >
> > # New Ticket Created by Nick Wellnhofer
> > # Please include the string: [perl #133016]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=133016 >
> >
> >
> > I get an unexpected result when subtracting a List from a Bag with
> > the set
> > difference operator (-). Subtracting Bags from Lists or Bags works
> > fine, as
> > does the baggy addition operator:
> >
> > say bag() (+) bag(); # Bag(a(3), b)
> > say bag() (+) ; # Bag(a(3), b)
> > say  (+) bag(); # Bag(a(3), b)
> >
> > say bag() (-) bag(); # Bag(a, b)
> > say bag() (-) ; # Bag(a(2), b) seems wrong
> > say  (-) bag(); # Bag(a, b)
> >
> > Only tested online on tio.run
> >
> > Rakudo version 2017.12 built on MoarVM version 2017.12
> > implementing Perl 6.c.
> >
> > and code-golf.io:
> >
> > Rakudo version 2018.03 built on MoarVM version 2018.03
> > implementing Perl 6.c
> >
> > Nick

[perl #126381] [CONC] Proc::Async has no way to get to a child's PID

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Closing this in favor of https://github.com/rakudo/rakudo/issues/1638

On 2015-10-17 06:27:53, r...@hoelz.ro wrote:
> As far as I can tell, MoarVM doesn't pass any information about a
> child process' PID to the caller of async proc operations; if it does,
> that information isn't exposed at the Perl 6 level. Having the PID
> handy is useful on Linux for things like inspecting a child's /proc
> entries.

[perl #126380] [NYI] Proc.pid

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Closing this in favor of https://github.com/rakudo/rakudo/issues/1638

On 2017-10-02 00:09:23, alex.jakime...@gmail.com wrote:
> Oh, actually, I noticed it too a few months ago. And removed it.
>
https://github.com/rakudo/rakudo/commit/5b8d4c2f4232dc0e5e9c62dc602fdcb74f7bdd24#diff-
> 7e0467c62428b3696cb555c69c52a4a0
>
> I guess this is NYI so we can keep it open. I don't know if we have
> any
> alternative to the non-existing ｢.pid｣.
>
> On 2015-10-17 06:25:15, r...@hoelz.ro wrote:
> > Looking at src/core/Proc.pm, and playing with run() in the REPL, it
> > seems that the pid attribute of Proc is never set.

[perl #130586] [REGEX] "Iteration Past End" with Empty Character Class that has unescaped space in it

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Further discussion on https://github.com/rakudo/rakudo/issues/1622.

On 2017-01-21 14:13:42, jn...@jnthn.net wrote:
> On Wed, 18 Jan 2017 18:16:20 -0800, c...@zoffix.com wrote:
> > the :sigspace adverb does not affect spaces inside character class.
> > Should it?
> >
> No, I don't think so. `<.ws>` can match any number of characters
> (including zero). A char class is defining something a matcher for a
> single character.
>
> > Note that having JUST space inside also causes a weird error to be
> > thrown:
> >
> >  m: say " " ~~ m:s/<-[ ]>/
> >  rakudo-moar 1aeea1: OUTPUT«===SORRY!===␤Iteration past end
> > of iterator␤»
> >
> That one's certainly a bug. Since whitespace in a charclass is not
> significant, then it should complain about an empty charclass,
> preferably with a hint about space.
>
> >  m: say " " ~~ m:s/<-[x ]>/
> >  rakudo-moar 1aeea1: OUTPUT«｢ ｣␤»
> This matches because it's the same as m:s/<-[x]>/. You'd need to write
> <-[x\ ]> to make the space significant.
>
> >  m: say " " ~~ m:s/<-[ x]>/
> >  rakudo-moar 1aeea1: OUTPUT«｢ ｣␤»
> Ditto.
>
> /jnthn

[perl #132909] [LTA?] Failure return from require when load fails

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Pretty sure this is a dup of https://github.com/rakudo/rakudo/issues/1515 , you
can follow the progress on the issue there. Let us know if your problem is
actually different.

Closing

On 2018-02-25 11:11:55, mt1...@gmail.com wrote:
> Hi,
>
> According to the documentation one should use the following to trap a
> failure when loading a module fails using require;
>
> try require ::('Foo');
> note ::('Foo').Str if ::('Foo') ~~ Failure;
>
> The problem with this is that it isn't visible what is going wrong.
> Using plain
>
> require ::('Foo');
>
> an exception is thrown with a proper error and stack dump. However
> when
> there are no errors in the module, there are other exceptions thrown
> with messages like
>
> WARNING: unhandled Failure detected in DESTROY. If you meant to ignore
> it, you can mark it as handled by
> calling .Bool, .so, .not, or .defined methods. The Failure was:
> No such symbol 'Foo'
> in block at ... (...) line ...
> ...
>
> This seems to me a bug. The only way to handle this properly is the
> following
>
> try {
> require ::('Foo');
>
> ...
>
> CATCH {
> .note;
> }
> }
>
>
>
> Perl6 version: 2018.01-195-g5ae1ca51f built on MoarVM version
> 2018.01-89-ga01cdb449 implementing Perl 6.c.
>
> Regards,
> Marcel

[perl #127093] gist missing for non-native typed array that doesn't get initialized

[Aleks-Daniel Jakimenko-Aleksejev via RT]

OK this issue is resolved with the commit mentioned above. Tests needed.

As for *int* native array having NaNs in it, that's not going to happen. It's
an array of native ints, it just can't and won't ever store any other type of a
value. A native int can't be NaN.

On 2016-01-02 06:34:50, lhermida wrote:
> On Sat Jan 02 06:31:40 2016, lhermida wrote:
> > On Sat Jan 02 04:14:47 2016, elizabeth wrote:
> > > > On 30 Dec 2015, at 19:41, Leandro Hermida (via RT)  > > > follo...@perl.org> wrote:
> > > >
> > > > # New Ticket Created by Leandro Hermida
> > > > # Please include the string: [perl #127093]
> > > > # in the subject line of all future correspondence about this
> > > > issue.
> > > > # https://rt.perl.org/Ticket/Display.html?id=127093 >
> > > >
> > > >
> > > >> my @a[4]
> > > > [(Any) (Any) (Any) (Any)]
> > > >> my Int @a[4] = 0..3
> > > > [0 1 2 3]
> > > >> my Int @a[4]
> > > > Method 'gist' not found for invocant of class 'NQPMu'
> > > >
> > > > I expected:
> > > > [(Int) (Int) (Int) (Int)]
> > > >
> > > > By defining native typed arrays do have a gist:
> > > >
> > > >> my int @a[4]
> > > > [0 0 0 0]
> > >
> > > Thanks for reporting!
> > >
> > > This was fixed, at least temporarily, with 42326d1b72f658f6dc5 .
> > > No
> > > tests have been added yet, in lieu of finding out how we’re going
> > > to
> > > do this post 6.c .
> > >
> > >
> > >
> > > Liz
> >
> >
> > Thanks Liz, another thing I forgot to ask about in the ticket, the
> > other unexpected behavior for me at least is when a native typed
> > array
> > is declared but not initialized each element of the array has a zero
> > where I would've expected it to be sized but not initialized and have
> > no value within each element. Is this part of spec?
> >
> > > my int @a[4]
> > [0 0 0 0]
>
> Sorry sent too fast, from what I read Perl 6 has no undef value I
> would expect the declaration of a native-typed numeric or integer
> array to be this:
>
> > my int @a[4]
> [NaN NaN NaN NaN]

[perl #131914] [REGRESSION] Rakudo/Moar taking more memory at launch.

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Interestingly, I can't reproduce it as well… But the numbers are still higher
than they were, so I guess the ticket is valid?

Here's the output on all releases:
https://gist.github.com/Whateverable/8687cceb1bfcf39e9818cef819d29391

I'd say we can close it once we go back to 50-ish.

On 2017-08-17 02:23:26, jn...@jnthn.net wrote:
> On Wed, 16 Aug 2017 14:53:05 -0700, alex.jakime...@gmail.com wrote:
> > Also, it's not any different on HEAD:
> >
> >  committable6test: 9658dd98c9dd8ec^^,9658dd98c9dd8ec,HEAD
> > say
> > "/proc/$*PID/statm".IO.lines[0].split(/\s/)[5] * 4096 / 1024
> >  AlexDaniel, ¦9658dd98c9dd8ec^^: «58628» ¦9658dd9:
> > «138220»
> > ¦HEAD(3e70d44): «136436»
> >
> > On 2017-08-16 14:27:37, alex.jakime...@gmail.com wrote:
> > > Note that the tests on 92bd7e4^ and 92bd7e4 are not very related to
> > > this
> > > particular issue.
> > >
> > > To put simply: it went from 58628 to 138220 because of changes
> > > related
> > > to this
> > > commit (or maybe one or two commits before it):
> > >
> >
https://github.com/rakudo/rakudo/commit/9658dd98c9dd8ecbefc606a08357e59718e328c2
> > >
> > > For Proc → Proc::Async issue see this ticket:
> > > https://rt.perl.org/m/ticket/show?id=131915
> > >
> > > Bisect logs:
> > > https://gist.github.com/6a7a6bfbc157bac3d06e9d2d58306846
> > > https://gist.github.com/5cf477671560bad21251207895708d94
> > >
> > >
> > > On 2017-08-16 14:21:25, scoli...@gmail.com wrote:
> > > > After some test against various release of rakudo it appear that
> > > > there
> > > > is a huge step in the memory taken by rakudo/moar at launch.
> > > > (after
> > > > 2017.05)
> > > > It's like up to 55Mb to 120Mb+
> > > >
> > > > It was tested by reading the memory info in /proc/pid/statm (the
> > > > number is in Kbytes)
> > > >
> > > >  committable6test:
> > > > 92bd7e4f54a9^,92bd7e4f54a9,9658dd98c9dd8ec^^,9658dd98c9dd8ec say
> > > > "/proc/$*PID/statm".IO.lines[0].split(/\s/)[5] * 4096 / 1024
> > > >  AlexDaniel, ¦92bd7e4f54a9^: «55752» ¦92bd7e4:
> > > > «55896» ¦9658dd98c9dd8ec^^: «58628» ¦9658dd9: «138220»
>
> I can't reproduce such an sizable increase at HEAD or
> MoarVM/NQP/Rakduo:
>
> $ ./perl6-m -e 'say "/proc/$*PID/statm".IO.lines[0].split(/\s/)[5] *
> 4096 / 1024'
> 79904

[perl #130493] [RFC][@LARRY] .sink of class not getting called, but Mu.sink is

[Aleks-Daniel Jakimenko-Aleksejev via RT]

I find the behavior surprising. Are there any examples of precedence thinkos
that are caught by this?

Added [RFC][@LARRY] tags, with just a little more information I think we'll be
able to close. Maybe.

On 2017-01-03 09:00:06, jn...@jnthn.net wrote:
> On Tue, 03 Jan 2017 04:54:52 -0800, elizabeth wrote:
> > $ 6 'class A { method sink() { say "goodbye" } }; A’
> > WARNINGS for -e:
> > Useless use of constant value A in sink context (line 1)
> >
> > I would expected this to say “goodbye” rather than being silent and
> > issuing a warning. The fact that a class has a specific .sink method
> > indicates that the developer had a plan for functioning in a sink
> > environment. So it should a. call that method and b. not issue a
> > warning.
> >
> I think we consciously decided that use of a type object in sink
> context would always warn (justification is that it's been known to
> catch the odd precedence thinko). Note that with an instance:
>
> $ perl6-m 'class A { method sink() { say "goodbye" } }; A.new'
> goodbye
>
> It does exactly what you expect.
>
> /jnthn

[perl #130616] Wrong source line number reported for misspelled private class attribute names

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still reproducible:

 6c: class Foo {␤ method foo {␤ say $!bad;␤ }␤ }␤
 AlexDaniel, ¦6c (28 commits): «===SORRY!=== Error while
compiling /tmp/Qj1o8IL3bG␤Attribute $!bad not declared in class Foo␤at
/tmp/Qj1o8IL3bG:6␤--> ⏏␤ «exit code = 1»»

On 2017-01-21 16:47:53, agen...@gmail.com wrote:
> Hi there
>
> I've just noted that Rakudo 2017.01 reports the wrong line number for
> any references of misspelled private class attributes. The minimal
> example to reproduce this is as follows:
>
> class Foo {
> method foo {
> say $!bad;
> }
> }
>
> Foo.foo();
>
> Rakudo reports the following:
>
> ===SORRY!=== Error while compiling /home/agentzh/a.p6
> Attribute $!bad not declared in class Foo
> at /home/agentzh/a.p6:7
> --> }⏏
>
> Note the line number is 7 while the offending line is at line 3. It
> seems that rakudo always reports the last line of the containing
> source file, which is never useful.
>
> I haven't tested any other Rakudo releases yet. So I'm not sure if
> it's a long standing issue or just a recent regression.
>
> Thanks for your attention!
>
> Best regards,
> -agentzh

[perl #130941] infix: keeps containers around since October, resulting in confusing behaviour

[Aleks-Daniel Jakimenko-Aleksejev via RT]

This ticket now needs tests, further discussion related issues here:
https://github.com/rakudo/rakudo/issues/1607

On 2017-03-08 05:56:13, c...@zoffix.com wrote:
> A temporary fix has been committed in
>
https://github.com/rakudo/rakudo/commit/5b7b7fb5c942a3e74097b5eb94a22be262f74c9f

[perl #126390] [BUG] await start {} hangs when using HTTP::UserAgent

[Aleks-Daniel Jakimenko-Aleksejev via RT]

FWIW it's not possible to reproduce the issue on older rakudos because it was
sweeped under the rug in the URI module itself:
https://github.com/perl6-community-modules/uri/issues/21

So yes, #126587 is a “testneeded” ticket for the underlying issue.

On 2018-03-09 12:58:27, jan-olof.hen...@bredband.net wrote:
> On Wed, 30 Dec 2015 09:12:25 -0800, c...@zoffix.com wrote:
> > To give an update on this. With Rakudo built on Dec 30, 2015, I no
> > longer get any hangs with neither
> > perl6 -MURI -e 'await start { say URI.new("http://localhost;) };'
> >
> > nor perl6 -MIETF::RFC_Grammar::URI -e "await Promise.in(1).then({
> > require IETF::RFC_Grammar::URI });"
> >
> > This is on Debian Wheezy. I tried both on 32bit 2-core and 64bit 1-
> > core boxes.
>
> This problem has been fixed. Part of the problem seems to have been the
> use of require in a thread, i.e. RT #126587.

[perl #126587] [SEGV] require inside thread segfault hang

[Aleks-Daniel Jakimenko-Aleksejev via RT]

dogbert++ noticed me that this issue is resolved (according to the provided
snippets). It is indeed so.

Second snippet may need this change:

-return 200, ['Content-Type' => 'text/plain'], 'we win';
+return 200, ['Content-Type' => 'text/plain'], ['we win'];

I can confirm that both issues are not reproducible using recent-ish rakudo,
but I can't tell when these problems were fixed. The first problem is not
really reproducible on any rakudo, even the one mentioned in the OP (huh??).
Also, there's some problem using HTTP::Server::Tiny on pre 2015.12 rakudos
(“Supplier” did not exist back then?).

Anyway, marking as ｢testneeded｣. If anybody wants to find what commit affected
these snippets, I'm pretty sure you'll have to bisect it manually without a
bot.

On 2015-11-08 01:11:45, lloyd.fo...@gmail.com wrote:
> Two async + require bugs. Replace LWP::Simple with whatever you like
> (except for builtins like Test which seem to work no matter what)
>
> 1. segfault
>
> Thread.start({ say "entering"; require LWP::Simple; say "leaving" })
> #both enters and leaves but segfault when it's done.
>
> 2. HTTP::Server::Tiny hangs
>
> use HTTP::Server::Tiny;
>
> HTTP::Server::Tiny.new(port => 8080).run: sub ($env) {
> note "requiring!";
> require LWP::Simple; # or whatever
> note "we got it!";
> return 200, ['Content-Type' => 'text/plain'], 'we win';
> };
>
> # then curl localhost:8080, you'll only get "requiring!".
>
> This is perl6 version 2015.10-220-g4988c70 built on MoarVM version
> 2015.10-61-g624d504
>
> Mac OSX

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

[Aleks-Daniel Jakimenko-Aleksejev via RT]

OK, there's now a follow-up ticket here:
https://github.com/rakudo/rakudo/issues/1598

On 2018-03-08 00:39:56, steve.myn...@gmail.com wrote:
> Maybe the ticket should be closed if/when the RT bug tracker is closed
> to new tickets itself and references to RT removed from all docs?
>
> S
>
> On 5 March 2018 at 17:50, Zoffix Znet via RT
>  wrote:
> > On Wed, 11 Oct 2017 13:22:50 -0700, alex.jakime...@gmail.com wrote:
> >> Oh, and if rakudo/issues is opened, then for me all issues raised in
> >> this
> >> ticket will be resolved.
> >
> > It was opened awhile ago.
> >
> > …and based on the recent usage, seems GitHub's ticket tracker is
> > preferred by users, so as far as this ticket goes, I think it can be
> > closed.

[perl #132012] [SEVERE] Numeric values of signals are wrong (say +SIGUSR1)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Further discussion on https://github.com/rakudo/rakudo/issues/1588

On 2017-10-18 03:46:20, c...@zoffix.com wrote:
> On Sat, 14 Oct 2017 08:29:50 -0700, c...@zoffix.com wrote:
> > Something fishy going on with the Signals enum. If that's fixed then
> > the
> > regression you pointed out will be fixed as well, as the new method
> > simply
> > uses enum's `.value` to get the signal number:
> >
> >  c: 79b8ab9d3f^,79b8ab9d3f,HEAD say SIGUSR1.Numeric; say
> > SIGUSR1.value; say $*KERNEL.signal: SIGUSR1
> >  Zoffix__, ¦79b8ab9d3f^: «30␤30␤10»
> > ¦79b8ab9,HEAD(cc6c055): «30␤30␤30»
>
>
> There's also a failing spectest on Windows that expects both of these
> to give same value (on and Linux, they do):
>
> C:\rakudo>perl6 -e "$*KERNEL.signal('SIGHUP').say"
> 3
>
> C:\rakudo>perl6 -e "$*KERNEL.signal(SIGHUP).say"
> 1

[perl #131626] [PERFTEST][PERF] ≥ and ≤ are 36x slower than Texas version; ≠ is 15x slower

[Aleks-Daniel Jakimenko-Aleksejev via RT]

It seems like it is fixed properly now. See this discussion:
https://irclog.perlgeek.de/perl6-dev/2018-03-01#i_15872426

On 2017-10-22 08:28:20, c...@zoffix.com wrote:
> On Tue, 26 Sep 2017 11:03:11 -0700, c...@zoffix.com wrote:
> > On Thu, 22 Jun 2017 10:29:59 -0700, c...@zoffix.com wrote:
> > > I'd expect the fancy Unicode versions of <=, >=, and != to perform
> > > equally well, instead the
> > > ≥ and ≤ are 36x slower than their Texas companions and ≠ is 15x
> > > slower.
> > >
> > > Here's the timings for >= vs ≥:
> > >
> > > m: my $x = rand; for ^1000_000 { $ = $x >= 1_000_000_000_000 }; say
> > > now - INIT now;
> > > rakudo-moar 43c176: OUTPUT: «0.74663187␤»
> > > m: my $x = rand; for ^1000_000 { $ = $x ≥ 1_000_000_000_000 }; say
> > > now
> > > - INIT now;
> > > rakudo-moar 43c176: OUTPUT: «(timeout)»
> > > m: my $x = rand; for ^1000_0 { $ = $x ≥ 1_000_000_000_000 }; say
> > > now
> > > -
> > > INIT now;
> > > rakudo-moar 43c176: OUTPUT: «0.2661272␤»
> > > m: say 0.2661272*100 / 0.729002
> > > rakudo-moar 43c176: OUTPUT: «36.505689␤»
> >
> >
> > So I made the static optimizer change Mexico ops to Texas versions,
> > so
> > this problem no longer exist. So, should the ticket be closed?
> >
> > Fixed in https://github.com/rakudo/rakudo/commit/6ec21cb473
> >
> > I tried writing a test, but couldn't get anything usable. My attempt
> > was this:
> >
> > use Test;
> > subtest 'performance of ≤, ≥, ≠ compared to Texas versions' => {
> > sub measure () { code for ^300; with now { code for
> > ^100_000;
> > now - $_ } }
> >
> > is-approx { rand ≤ rand }., { rand <= rand }., '≤',
> > :rel-tol<.5>;
> > is-approx { rand ≥ rand }., { rand >= rand }., '≥',
> > :rel-tol<.5>;
> > is-approx { rand ≠ rand }., { rand != rand }., '≠',
> > :rel-tol<.5>;
> > }
>
>
> So the optimizer fix didn't do a full job. There were still cases that
> ended up 86x slower:
>
> When chained:
>
>  m: $ = rand ≤ rand ≤ rand for ^100_000; say now - INIT now
>  rakudo-moar a042fd927: OUTPUT: «2.91023964␤»
>  m: $ = rand <= rand <= rand for ^100_000; say now - INIT
> now
>  rakudo-moar a042fd927: OUTPUT: «0.094577␤»
>
> Or when user defines their own version of the ASCII op:
>
>  m: $ = rand ≤ rand for ^100_000; say now - INIT now
>  rakudo-moar a042fd927: OUTPUT: «0.0474443␤»
>  m: class Foo {}; sub infix:«<=» (Foo, Foo) {}; $ = rand ≤
> rand for ^100_000; say now - INIT now
>  rakudo-moar a042fd927: OUTPUT: «1.94282032␤»
>
> Some proposed to substitute Unicode versions for Texas ones during
> parsing and codegen, but the only way I
> know how to do that would make user's use of `≠` use a custom `!=` op,
> if one exists.
>
> It's possible we *do* want to declare that we do such aliasing: a
> Unicode op is just a grammatical alias
> to the ASCII op and gets rewritten to it. If there's a consensus to do
> that, it should be done for all the ops,
> even ones that don't have this performance issue (which is due to
> capture slipping).
>
> For now, I basically restored lizmat++'s original fix adding whatever
> datish ops that were
> originally missing as well:
> https://github.com/rakudo/rakudo/commit/6ad06fad9f

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

[Aleks-Daniel Jakimenko-Aleksejev via RT]

On 2018-02-16 09:01:57, c...@zoffix.com wrote:
> On Fri, 16 Feb 2018 05:52:09 -0800, elizabeth wrote:
> > I propose we change all onlies in the core to multis after the release
> > and see how this breaks things / makes things slower.
>
> +1. Let's try.

Yeah, sounds good. +1

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

[Aleks-Daniel Jakimenko-Aleksejev via RT]

So I looked at this, and at very best the proposed error message is wrong. It
says that ? is useless when used with %%, but that's not the case:

 m: say ‘af’|‘a’|‘f’|‘’ ~~ /a? %% f/
 rakudo-moar 00af9ce27: OUTPUT: «｢af｣␤｢a｣␤｢f｣␤｢｣␤»
 m: say ‘af’|‘a’|‘f’|‘’ ~~ /a?f?/
 rakudo-moar 00af9ce27: OUTPUT: «｢af｣␤｢a｣␤｢f｣␤｢｣␤»

So yes, while in this case it is equivalent to just `a?f?`, it's not totally
useless. And I think it makes sense to allow this behavior to have all
quantifiers behaving consistently.

And according to this discussion, that particular fix will not go in:
https://irclog.perlgeek.de/perl6-dev/2018-02-11#i_15804761

On 2018-02-11 02:04:06, c...@zoffix.com wrote:
> On Wed, 15 Jul 2015 07:31:55 -0700, lue wrote:
> >  m: say "ab" ~~ /^ a +% (b) $/
> >  rakudo-moar e4077e: OUTPUT«Nil␤»
> >  m: say "ab" ~~ /^ a *% (b) $/
> >  rakudo-moar e4077e: OUTPUT«Nil␤»
> >  m: say "ab" ~~ /^ a ?% (b) $/
> >  rakudo-moar e4077e: OUTPUT«===SORRY!===␤QAST::Block with
> > cuid cuid_1_1436969557.11546 has not appeared␤»
> >
> > On JVM:
> >
> >  j: say "ab" ~~ /^ a ?% (b) $/
> >  rakudo-jvm e4077e: OUTPUT«===SORRY!===␤setcodeobj can only
> > be used with a CodeRef␤»
> >
> > And just to show that it's not just the ?% operator alone
> > contributing
> > to the issue, but the capture too:
> >
> >  m: say "ab" ~~ /^ a ?% [b] $/
> >  rakudo-moar e4077e: OUTPUT«Nil␤»
>
>
> Made potential fix in branches in
> https://github.com/perl6/nqp/commit/ac3d5307f3 and
> https://github.com/perl6/roast/commit/f2b07afbba
>
> The fix is to throw on `?`/`??` quantifiers used with `%`/`%%`.
>
> It's blocked by 2 lines of 6.c tests that indirectly use this
> combination:
>
https://github.com/perl6/roast/commit/aaa71d077431cd0a86be84bd386e1032a12e8697#diff-
> ae7b47444302486e790af6ee18121fabR16
>
> I delegated it to the release manager whether to merge that stuff or
> to require a fix that leaves these working and then we fix the
> compilation error itself.

[perl #129114] [BUG] state variable declared inside of a {} interpolation in a string, attaches to wrong scope

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Just to clarify, the last snippet now produces 0 0 0 0, which is indeed
correct.

There are tests for this change in general, but possibly not for that
particular case. Can we get it covered just in case?

｢testneeded｣

On 2018-02-06 05:51:23, jan-olof.hen...@bredband.net wrote:
> On Sun, 28 Aug 2016 02:56:47 -0700, sml...@gmail.com wrote:
> > This is how a state variable normally works:
> >
> > ➜ for ^2 { for ^2 { say (state $a)++ } }
> > 0
> > 1
> > 0
> > 1
> >
> > But when it is declared inside a {} interpolation in a string, it
> > misbehaves:
> >
> > ➜ for ^2 { for ^2 { say "{ (state $a)++ }" } }
> > 0
> > 1
> > 2
> > 3
> >
> > It's as if the state variable attaches to the scope of the outer loop
> > or mainline, instead of the inner loop like it should.
>
> Looks as if the code behaves as expected according to jnthn. See
> https://irclog.perlgeek.de/perl6-dev/2018-02-06#i_15783359
>
> Rejecting issue.

[perl #131813] Segfault with --profile

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Actually, I've been trying to reproduce it on the said revision with --profile,
--ll-exception and whatnot, and I can't. I think this is an issue on OS X and
therefore should be confirmed (and tested) on OS X also.

On 2018-01-06 12:59:07, jan-olof.hen...@bredband.net wrote:
> On Fri, 28 Jul 2017 15:52:53 -0700, timo wrote:
> > It could be that the commit i just pushed to moarvm fixes this,
> > please
> > verify (the code doesn't crash with the patch)
>
> Seems to work properly:
>
> dogbert@dogbert-VirtualBox ~/repos/rakudo $ ./perl6 -v
> This is Rakudo version 2017.12-124-g6a6470f9d built on MoarVM version
> 2017.12-20-g57103408
> implementing Perl 6.c.
> dogbert@dogbert-VirtualBox ~/repos/rakudo $ ./perl6 --profile -e 'my
> @a = (^1)>>.Str'
> Writing profiler output to profile-1515272304.87249.html
> dogbert@dogbert-VirtualBox ~/repos/rakudo $ ./perl6 --profile -e 'my
> @a = (^25000)>>.Str'
> Writing profiler output to profile-1515272310.68317.html
> dogbert@dogbert-VirtualBox ~/repos/rakudo $

[perl #132328] [SEGV][REGRESSION] DBIish tests are failing spectacularly (JIT compilation of native calls)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Honestly, I have no idea how to test this… maybe someone should attempt to golf
it, but given that the commit description is “JIT compile native calls”, I
guess it'd be a bit complicated.

… I'm fine with just delegating it to the DBIish test suite…

On 2017-10-20 08:12:41, alex.jakime...@gmail.com wrote:
> Offending commit reverted in
>
https://github.com/MoarVM/MoarVM/commit/1a9be0ad487bc6e2d21df54c6a12892e3f9c8259
>
> I tested it with moar HEAD and indeed the issue is no longer there. So
> it
> should work fine after moar and nqp bumps.
>
> ｢testneeded｣ ?
>
> On 2017-10-20 07:53:23, alex.jakime...@gmail.com wrote:
> > Moar bisected to
> >
>
https://github.com/MoarVM/MoarVM/commit/4eadf94599cc021ec7a9e0e49e198f5861468dc1
> >
> > On 2017-10-20 07:23:04, alex.jakime...@gmail.com wrote:
> > > DBIish tests started to fail (with segv) after this rakudo commit:
> > >
> >
>
https://github.com/rakudo/rakudo/commit/ff063e7b53ab41b79279ffc38e1740d3db2eae7d
> > >
> > > The bump itself brought these MoarVM changes:
> > > https://github.com/MoarVM/MoarVM/compare/2017.09.1-602-
> > > g676723d...2017.09.1-608-ge051ee3
> > >
> > >
> > > Committable output before and after:
> > > command: commit: ff063e7b53^,ff063e7b53
> > >
> >
>
https://gist.githubusercontent.com/AlexDaniel/13a57dbb993d624c877befc137c33ee6/raw/a575bf2e04e24ced60b35665a4ec5a3324369c47/dbiish.p6
> > > output: https://gist.github.com/e25c6a14d6078e99f6bb46de494565b1
> > >
> > > Not surprisingly there's no crash with MVM_JIT_DISABLE:
> > > command: commit: MVM_JIT_DISABLE=1 ff063e7b53^,ff063e7b53
> > >
> >
>
https://gist.githubusercontent.com/AlexDaniel/13a57dbb993d624c877befc137c33ee6/raw/a575bf2e04e24ced60b35665a4ec5a3324369c47/dbiish.p6
> > > output: https://gist.github.com/24319e448313c13c16d8b67d7961accb

[perl #129787] [CONC] die/CATCH inside a start-block with a channel heisenbugs

[Aleks-Daniel Jakimenko-Aleksejev via RT]

FWIW, this bug is somewhat similar in feel:
https://github.com/rakudo/rakudo/issues/1202

On 2017-10-15 03:14:02, c...@zoffix.com wrote:
> On Wed, 02 Nov 2016 07:13:26 -0700, jn...@jnthn.net wrote:
> > On Sun Oct 02 12:52:45 2016, gfldex wrote:
> > > sub f(){
> > > my $c = Channel.new;
> > >
> > > start {
> > > for 1..* {
> > > CATCH { default { note .Str } }
> > >
> > > $c.send($_);
> > > die 'bad';
> > > }
> > > }
> > >
> > > $c.list
> > > }
> > >
> > > .say for f;
> > >
> > > # sometimes it works
> > > # sometimes it counts to 20 and outputs:
> > > # Command terminated
> > > # sometimes it outputs some numbers and 'bad's end then some
> > > # unicode-garbage
> > > # sometimes it outputs a few 100s 'bad' and then stalls with one
> > > thread at
> > > # 100% CPU
> > > # heisenbug rate is about 1/3
> > > #
> > > # also it seams to eat up plenty of RAM while it's running without
> > > the
> > > # die/CATCH
> >
> > This one is yet another case of the long-standing issues with use of
> > handles across threads. The channel golfs away; you can get this bug
> > with just:
> >
> > start { for ^100 { note "hi" } }; for ^100 { say "oops" }
> >
> > /jnthn
>
>
> This is now fixed, but have no idea how to test it… On 2016.10, I can
> only repro this bug with STDERR/STDOUT set to a TTY terminal.

[perl #112986] [REPL] error 'Use of uninitialized $_ of type Any in numeric context" throws extra errors

[Aleks-Daniel Jakimenko-Aleksejev via RT]

 Test in
https://github.com/rakudo/rakudo/commit/4385e3fc0b5272a14c1c507ccf5846684c16453a

On 2017-08-28 13:58:57, alex.jakime...@gmail.com wrote:
> Currently it says this:
> Use of uninitialized value of type Any in numeric context
> in block  at  line 1
>
> As well as complains about sink context in non-repl:
> Useless use of "**" in expression "$_**2" in sink context (line 1)
>
> I see no problem with it. Except that it no longer says which variable
> caused
> the trouble. I guess it is less than awesome, but this part changed
> before
> 2014.01. I can't bisect there and it is irrelevant to this ticket.
>
> I'll mark this as ｢testneeded｣ in case someone can come up with a test
> for
> this, but otherwise it is a resolved ticket.
> On 2012-11-21 09:53:41, FROGGS.de wrote:
> > thats the expected behaviour, right?
> >
> > rakudo-2012-11$ install/bin/perl6
> > > $_**2;
> > use of uninitialized variable $_ of type Any in numeric context
> > 0
> > >
> >
> >

[perl #125299] [BUG] LTA error message when forgetting to close block inside string in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Tests here:
https://github.com/perl6/roast/commit/2dd5ee1b5935fce03eb815f8336ed26e019d4413

Resolved.

Further discussion on https://github.com/rakudo/rakudo/issues/1475

On 2017-12-02 14:39:07, alex.jakime...@gmail.com wrote:
> https://irclog.perlgeek.de/perl6/2017-12-02#i_15524141
>
> Marking as ｢testneeded｣
>
> On 2017-12-01 14:31:15, alex.jakime...@gmail.com wrote:
> > https://irclog.perlgeek.de/perl6/2017-12-01#i_15520545
> >
> > On 2015-06-01 04:26:37, masak wrote:
> > > On Mon Jun 01 01:15:07 2015, FROGGS.de wrote:
> > > > FROGGS: m: say "#={ 42 }" # DrForr: your ticket is invalid
> > > > camelia: rakudo-moar c2a57e: OUTPUT«#=42␤»
> > > > FROGGS: DrForr: I am closing your ticket now
> > > > DrForr: The error was about the closing quotes, not the
> > > > interpolation.
> > > > FROGGS: DrForr: you mean that '"' is mentioned in the error message?
> > > > DrForr: Yes.
> > > > FROGGS: ahh
> > > > * FROGGS adds that to the ticket
> > > >
> > > > So, we'd like to see that a closing curly is expected I think.
> > >
> > > Also, as long as we're wishing for ponies and butterflies in the error
> > > message: one thing that Perl 5 still does better is to say where the
> > > runaway thing *began*, in this case the block. Because it's often a
> > > mistake, the programmer may not be aware of which thing it is that is
> > > unbalanced.
> > >
> > > My ideal error message would look something like this:
> > >
> > > Opening curly without closing curly in string -- did you forget to
> > > close the block?
> > > Opening curly found at line 22, col 17
> > > Expected '"' line 58, col 5, found EOF

[perl #125985] [BUG] Internal error when a constant, unspace, and a map are involved in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Anyway, tests in
https://github.com/perl6/roast/commit/7557eef426fa4ea102d2d89b84c47dd5c1d3ab08

On 2018-02-03 14:40:09, alex.jakime...@gmail.com wrote:
> Ouch. It seems that one of my links is wrong, should've been this one
> I think:
> https://gist.github.com/Whateverable/cedc8ef783acc22e8f07afa98f5ad7d6
>
> On 2017-12-02 19:41:52, alex.jakime...@gmail.com wrote:
> > Not sure how it golfs down to that, because it never produced the
> > same
> > error
> > message. In any case, both issues are resolved.
> >
> > First: https://gist.github.com/76f318afe9a72a77d2bf0fecff46a555
> > (bisectable points at (2017-09-28)
> >
>
https://github.com/rakudo/rakudo/commit/6824e19282e19a0953fc64faf14445600d9b24e6
> > but that's not really the commit that resolved the issue completely,
> > it's a bit
> > more complicated than that)
> >
> >
> > Second:
> > https://gist.github.com/Whateverable/e503d4e068d70977512a1eb47b65a0a5
> > (2017-10-07)
> >
>
https://github.com/rakudo/rakudo/commit/f254e359d79b5953a019802fcd956421731282dc
> >
> >
> > Tests needed for both issues.
> >
> >
> > ｢testneeded｣
> >
> > On 2015-09-07 12:32:06, jn...@jnthn.net wrote:
> > > Further golfs to:
> > >
> > > constant nums = 1; my \fizzbuzz = nums\ .map({ $_ });
> > >
> > > But goes away with:
> > >
> > > constant nums = 1; my \fizzbuzz = nums\.map({ $_ });
> > >
> > > Somehow we treat it as a sub call rather than a term when there's
> > > actually space after the \. Much odd...

[perl #125985] [BUG] Internal error when a constant, unspace, and a map are involved in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Ouch. It seems that one of my links is wrong, should've been this one I think:
https://gist.github.com/Whateverable/cedc8ef783acc22e8f07afa98f5ad7d6

On 2017-12-02 19:41:52, alex.jakime...@gmail.com wrote:
> Not sure how it golfs down to that, because it never produced the same
> error
> message. In any case, both issues are resolved.
>
> First: https://gist.github.com/76f318afe9a72a77d2bf0fecff46a555
> (bisectable points at (2017-09-28)
>
https://github.com/rakudo/rakudo/commit/6824e19282e19a0953fc64faf14445600d9b24e6
> but that's not really the commit that resolved the issue completely,
> it's a bit
> more complicated than that)
>
>
> Second:
> https://gist.github.com/Whateverable/e503d4e068d70977512a1eb47b65a0a5
> (2017-10-07)
>
https://github.com/rakudo/rakudo/commit/f254e359d79b5953a019802fcd956421731282dc
>
>
> Tests needed for both issues.
>
>
> ｢testneeded｣
>
> On 2015-09-07 12:32:06, jn...@jnthn.net wrote:
> > Further golfs to:
> >
> > constant nums = 1; my \fizzbuzz = nums\ .map({ $_ });
> >
> > But goes away with:
> >
> > constant nums = 1; my \fizzbuzz = nums\.map({ $_ });
> >
> > Somehow we treat it as a sub call rather than a term when there's
> > actually space after the \. Much odd...

[perl #130261] [LTA] Error message for unclosed curly quote points to the last line of the file

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Tests in
https://github.com/perl6/roast/commit/ceabda6337364b5f1cec3c1c5bcb89787f9bcedf

On 2018-01-08 15:18:46, alex.jakime...@gmail.com wrote:
> Note that the error message is still LTA (says “corresponding starter”
> instead
> of mentioning “’”), for further progress see RT#125641.
>
> On 2018-01-08 15:16:47, alex.jakime...@gmail.com wrote:
> > Ah. This was fixed. Here's the pull request:
> > https://github.com/rakudo/rakudo/pull/1183
> > And here's the right commit:
> >
>
https://github.com/rakudo/rakudo/pull/1183/commits/6542bb8032e7203b8736655075dbd3452856bc93
> >
> > There should be tests for this already, I think.
> >
> > On 2016-12-04 10:22:37, alex.jakime...@gmail.com wrote:
> > > Code:
> > > say ‘hello';
> > > say 42;
> > > say 50;
> > >
> > > Result:
> > > == =SORRY!=== Error while compiling -e
> > > Unable to parse expression in smart single quotes; couldn't find
> > > final
> > > "’"
> > > at -e:3
> > > --> say 50;⏏
> > > expecting any of:
> > > argument list
> > > smart single quotes
> > > term
> > >
> > > While the error message is right, it would be better if it also
> > > printed some information on where the initial curly quote is. As an
> > > example, see what happens if you try to do the same thing with a
> > > multiline comment (RT #125247):
> > >
> > > Code:
> > > say #`‘hello';
> > > say 42;
> > > say 50;
> > >
> > > Result:
> > > == =SORRY!=== Error while compiling -e
> > > Couldn't find terminator ’ (corresponding ‘ was at line 1)
> > > at -e:3
> > > --> say 50;⏏
> > > expecting any of:
> > > ’

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

[Aleks-Daniel Jakimenko-Aleksejev via RT]

 Tests in
https://github.com/perl6/roast/commit/3ca315596c3283c8cd168428065f01062c4633a5

On 2016-11-18 10:51:38, alex.jakime...@gmail.com wrote:
> On 2016-11-18 10:38:48, coke wrote:
> > On Sun, 18 Sep 2016 03:14:30 -0700, elizabeth wrote:
> > > Fixed by reverting 1a03efe4e3b61a07b7df5 in 363a3a899f2cb342d1ca5 .
> >
> > Can we close the case?
>
>
> By the way, are there any tests now?

[perl #127100] [LTA] error message when specifying return type before parameters ( --> Bool, Int $x, Int $y )

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Tests in
https://github.com/perl6/roast/commit/3dab7c774587fbf8ae2afb561b02b3177659ace3

On 2017-10-07 15:55:27, alex.jakime...@gmail.com wrote:
> This was resolved in these commits:
> *
>
https://github.com/rakudo/rakudo/commit/ac97a4016196c1fb5c39365dfbe8980574fb929b
> *
>
https://github.com/rakudo/rakudo/commit/64b001a1464bf618fa4c0eed984e240fcf8b772b
>
> ｢testneeded｣
>
> Please try to cover various variants in tests, like:
> (--> Bool Int $x, Int $y)
> (--> Bool, Int $x, Int $y)
> ($x, --> Bool, Int $y)
> and so on.
> Maybe also test ; and ;; instead of commas, because these are also
> allowed as
> param separators.
>
>
>
> On 2015-12-30 17:42:24, alex.jakime...@gmail.com wrote:
> > Code:
> > sub foo (--> Bool Int $x, Int $y) { True }
> >
> > Result:
> > ===SORRY!=== Error while compiling -e
> > Type 'Bool' is not declared. Did you mean 'Cool'?
> > at -e:1
> > --> sub foo (--> Bool⏏ Int $x, Int $y) { True }
> >
> >
> > I know that I'm doing it wrong, but ｢Bool｣ IS declared! Come on!
> >
> > Actually, this is not the first time I see this, and in fact it is
> > not the
> > first time I report such LTA error. See
> > https://rt.perl.org/Public/Bug/Display.html?id=125902

[perl #127671] [EXOTICTEST] ｢dir｣ dies if weird unicode sequences are encountered (dir;)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Test added in
https://github.com/perl6/roast/commit/a7590d6543e1d29bc935377c727e4d15e38ee713

Note that the test *does create* files with weird names, but that's totally OK
in /tmp I think.

On 2017-03-02 07:06:54, c...@zoffix.com wrote:
> Explanation and ideas on IRC: https://irclog.perlgeek.de/moarvm/2017-
> 03-02#i_14193748
>
> - It's risky to be part of normal tests, lest the user won't be able
> to delete these weird dirs
> - Setup `make risky-test` target that would run these risky tests only
> when user asks (knowing they're on a system that can be trashed
> freely)

[perl #129882] [TESTNEEDED] [CONC] [IO] Proc with `.in.close` and `.out.slurp-rest` in different threads, hangs

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Test in
https://github.com/perl6/roast/commit/195227f779f7441de1678e12941550271da799b2

On 2017-07-09 19:40:57, alex.jakime...@gmail.com wrote:
> That's pretty good. But issues are not closed without tests, unless
> there's a
> good reason not to add a test. No reason was mentioned, therefore
> reopening
> this with “testneeded” tag.
>
> On 2017-07-09 15:49:46, jan-olof.hen...@bredband.net wrote:
> > On Wed, 19 Oct 2016 05:57:04 -0700, jn...@jnthn.net wrote:
> > > On Fri Oct 14 16:40:27 2016, sml...@gmail.com wrote:
> > > > The following code attempts to pipe a large Blob (larger than a
> > > > pipe's
> > > > buffer size) through an external command.
> > > > However, it hangs on the `.in.close` line and never finishes:
> > > >
> > > > my $proc = run «cat -», :in, :out, :bin;
> > > > my $input = ("a" x 100).encode;
> > > > my $promise = start {
> > > > $proc.in.write: $input;
> > > > $proc.in.close;
> > > > }
> > > > say $proc.out.slurp-rest(:close, :bin).bytes;
> > > > await $promise;
> > > >
> > > For now, if using threads, stick with Proc::Async (in the future,
> > > we'll probably re-implement Proc/run etc. in terms of Proc::Async).
> > >
> > > /jnthn
> >
> > jnthn recently made the above mentioned re-implementation so the code
> > shown in the report now works.
> >
> > Closing issue

[perl #125674] [LTA] error message prints wrong eject position (if True if { };)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Does not seem to be fixed at all. But I've added some todo-ed tests:
https://github.com/perl6/roast/commit/f9f5034a1e66e068bfe21227e35f100f3c1e3fef

On 2017-10-07 13:43:30, alex.jakime...@gmail.com wrote:
> Should be fixed in https://github.com/rakudo/rakudo/commit/5747bc7121
>
> Testneeded. Slightly relevant tests here:
> https://github.com/perl6/roast/commit/34577134e0
>
> On 2017-10-06 21:01:48, alex.jakime...@gmail.com wrote:
> > This one is a bit harder than it seems.
> >
> > So here is what throws:
> >
>
https://github.com/rakudo/rakudo/blob/f62ae60c48d1372df18b49aca44e10af44ead2d6/src/Perl6/Grammar.nqp#L315
> >
> > However, the cursor has wrong position for some reason. Looking at
> > the
> > lines
> > above, it may seem that doing this:
> >
> > self.'!cursor_pos'($pos);
> >
> > should fix the problem… but it doesn't! $pos variable is set
> > correctly, but
> > !cursor_pos does absolutely nothing. In fact, you can try setting it
> > to 0 or
> > any other value, no effect whatsoever.
> >
> > This suggests that the use of !cursor_pos in the same method does not
> > work too.
> > What is the right way to set the cursor?
> >
> > And why does the cursor even have the incorrect value there?
> >
> > As a bonus, this line seems to be unreachable:
> > self.missing("block (taken by some undeclared routine?)");
> >
> > I tried various things but nothing can trigger it. I found (via
> > google) some
> > code snippets that used to result in this error message, but nowadays
> > it simply
> > says “Missing block”. I bisected that change to
> >
>
https://github.com/rakudo/rakudo/commit/8a70c921e98ed260d3198d81b81b0960c8daa83b
> >
> >
> > On 2015-07-24 05:13:59, alex.jakime...@gmail.com wrote:
> > > Code:
> > > if True if { };
> > >
> > > ===SORRY!=== Error while compiling ./test.pl
> > > Missing block
> > > at ./test.pl:3
> > > --> if True if ⏏{ };
> > >
> > > Clearly the block is there. It seems like it expects a block before
> > > the
> > > second "if", but the cursor is placed incorrectly. STD gets it
> > > right:
> > >
> > > 15:03:25 std: if True if { };
> > > 15:03:26 std 28329a7: OUTPUT«===SORRY!===␤Missing block at
> > > /tmp/XbS0PJUJZo line 1:␤--> if True ⏏if { };␤Parse
> > > failed␤FAILED 00:00 135m␤»
> > >
> > > Similar problem with "unless", "while" and maybe some others.
> > >
> > > Tiny IRC discussion: http://irclog.perlgeek.de/perl6/2015-07-
> > > 24#i_10947603

[perl #132741] [BUILD] Broken on FreeBSD and OpenBSD

[Aleks-Daniel Jakimenko-Aleksejev via RT]

This was fixed, for more info see this still-open issue:
https://github.com/rakudo/rakudo/issues/1420

On 2018-01-19 07:30:48, steve.myn...@gmail.com wrote:
> MoarVM build broken on FreeBSD 11 and OpenBSD 6.2
>
> ..
>
> Configuring and building MoarVM ...
> /usr/local/bin/perl5 Configure.pl --optimize
> --prefix=/usr/home/steve/sandbox/perl6/rakudo/install --make-install
> Welcome to MoarVM!
>
> Updating submodules  OK
> Configuring native build environment ...
> trying to compile a simple C program ... sh: Syntax
> error: word unexpected (expecting ")")
> ERROR
>
> Can't compile simple C program.
> Failing command: CODE(0x802884d08) -o try.o -c try.c 2>&1
> Error:
>
> Fixed by reverting lines in
>
>
https://github.com/MoarVM/MoarVM/commit/28eaf97d05d18e6e4ce528f6d723022609e8338b#diff-
> 2a9806f1c161480015223272ecd41308L460

[perl #132306] [PERF] parameters, even if unused, make stuff slower ( f1($a, $, $, $, $, $) vs f2($a, $b, $c, $d, $e, $f) )

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Yes, it would be awesome to have warnings for unused params and variables.


On 2018-01-14 12:16:08, c...@zoffix.com wrote:
> On Sat, 14 Oct 2017 20:53:03 -0700, alex.jakime...@gmail.com wrote:
> > FWIW I made a throwaway script that looks for unused params, and
> > there
> > are many
> > of these in rakudo sources. Of course, most of these cases are not in
> > hot
> > paths, but the overall performance benefit may be very noticeable.
> >
> > There are also cases like this:
> > https://github.com/rakudo/rakudo/blob/nom/src/core/IO/Socket/Async.pm#L313-
> > L315
> > where named arg is present in the signature but does absolutely
> > nothing (or so
> > it seems?).
> >
> > Dunno if I should post the results. There are many false-positives
> > and
> > I guess
> > many cases are not caught at all, so a proper approach is needed if
> > we
> > really
> > want to replace all these with $.
>
> Wouldn't a warning about unused variables be more appropriate
> than silently rewriting them to `$`? Their names can be introspected
> and used for
> something by they user. We actually do do that in core (sub MAIN USAGE
> generation).
>
> That Proc::Async line you point out actually has a bug in it and a
> warning would've detected it.

[perl #132718] BUG: Unhandled kind 3 with int32 argument

[Aleks-Daniel Jakimenko-Aleksejev via RT]

FWIW it was “working” before this commit:
https://github.com/rakudo/rakudo/commit/ec18f24d27ce61fa71d177ab76c4044ee1d1a75e

But that's probably irrelevant because I'm pretty sure it was cheating with
something.
On 2018-01-13 13:56:54, elizabeth wrote:
>
> > On 13 Jan 2018, at 22:38, Curt Tilmes (via RT)  > follo...@perl.org> wrote:
> >
> > # New Ticket Created by Curt Tilmes
> > # Please include the string: [perl #132718]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=132718 >
> >
> >
> >  m: sub foo(int32 $x) { say "ok" if $x }; foo(12);
> >  rakudo-moar f25fdbdf0: OUTPUT: «===SORRY!===␤Unhandled kind
> > 3␤»
>
> FWIW, this also happens for int8 and int16 with different Unhandled
> kind values (1 and 2 respectively).
>
> Casual introspection shows that apparently no support for int8, int16
> or int32 has been added at this level.

[perl #132718] BUG: Unhandled kind 3 with int32 argument

[Aleks-Daniel Jakimenko-Aleksejev via RT]

FWIW it was “working” before this commit:
https://github.com/rakudo/rakudo/commit/ec18f24d27ce61fa71d177ab76c4044ee1d1a75e

But that's probably irrelevant because I'm pretty sure it was cheating with
something.
On 2018-01-13 13:56:54, elizabeth wrote:
>
> > On 13 Jan 2018, at 22:38, Curt Tilmes (via RT)  > follo...@perl.org> wrote:
> >
> > # New Ticket Created by Curt Tilmes
> > # Please include the string: [perl #132718]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=132718 >
> >
> >
> >  m: sub foo(int32 $x) { say "ok" if $x }; foo(12);
> >  rakudo-moar f25fdbdf0: OUTPUT: «===SORRY!===␤Unhandled kind
> > 3␤»
>
> FWIW, this also happens for int8 and int16 with different Unhandled
> kind values (1 and 2 respectively).
>
> Casual introspection shows that apparently no support for int8, int16
> or int32 has been added at this level.

[perl #130261] [LTA] Error message for unclosed curly quote points to the last line of the file

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Note that the error message is still LTA (says “corresponding starter” instead
of mentioning “’”), for further progress see RT#125641.

On 2018-01-08 15:16:47, alex.jakime...@gmail.com wrote:
> Ah. This was fixed. Here's the pull request:
> https://github.com/rakudo/rakudo/pull/1183
> And here's the right commit:
>
https://github.com/rakudo/rakudo/pull/1183/commits/6542bb8032e7203b8736655075dbd3452856bc93
>
> There should be tests for this already, I think.
>
> On 2016-12-04 10:22:37, alex.jakime...@gmail.com wrote:
> > Code:
> > say ‘hello';
> > say 42;
> > say 50;
> >
> > Result:
> > == =SORRY!=== Error while compiling -e
> > Unable to parse expression in smart single quotes; couldn't find
> > final
> > "’"
> > at -e:3
> > --> say 50;⏏
> > expecting any of:
> > argument list
> > smart single quotes
> > term
> >
> > While the error message is right, it would be better if it also
> > printed some information on where the initial curly quote is. As an
> > example, see what happens if you try to do the same thing with a
> > multiline comment (RT #125247):
> >
> > Code:
> > say #`‘hello';
> > say 42;
> > say 50;
> >
> > Result:
> > == =SORRY!=== Error while compiling -e
> > Couldn't find terminator ’ (corresponding ‘ was at line 1)
> > at -e:3
> > --> say 50;⏏
> > expecting any of:
> > ’

[perl #130261] [LTA] Error message for unclosed curly quote points to the last line of the file

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Ah. This was fixed. Here's the pull request:
https://github.com/rakudo/rakudo/pull/1183
And here's the right commit:
https://github.com/rakudo/rakudo/pull/1183/commits/6542bb8032e7203b8736655075dbd3452856bc93

There should be tests for this already, I think.

On 2016-12-04 10:22:37, alex.jakime...@gmail.com wrote:
> Code:
> say ‘hello';
> say 42;
> say 50;
>
> Result:
> == =SORRY!=== Error while compiling -e
> Unable to parse expression in smart single quotes; couldn't find final
> "’"
> at -e:3
> --> say 50;⏏
> expecting any of:
> argument list
> smart single quotes
> term
>
> While the error message is right, it would be better if it also
> printed some information on where the initial curly quote is. As an
> example, see what happens if you try to do the same thing with a
> multiline comment (RT #125247):
>
> Code:
> say #`‘hello';
> say 42;
> say 50;
>
> Result:
> == =SORRY!=== Error while compiling -e
> Couldn't find terminator ’ (corresponding ‘ was at line 1)
> at -e:3
> --> say 50;⏏
> expecting any of:
> ’

[perl #131813] Segfault with --profile

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Closable with rakudo tests then.

On 2018-01-06 12:59:07, jan-olof.hen...@bredband.net wrote:
> On Fri, 28 Jul 2017 15:52:53 -0700, timo wrote:
> > It could be that the commit i just pushed to moarvm fixes this,
> > please
> > verify (the code doesn't crash with the patch)
>
> Seems to work properly:
>
> dogbert@dogbert-VirtualBox ~/repos/rakudo $ ./perl6 -v
> This is Rakudo version 2017.12-124-g6a6470f9d built on MoarVM version
> 2017.12-20-g57103408
> implementing Perl 6.c.
> dogbert@dogbert-VirtualBox ~/repos/rakudo $ ./perl6 --profile -e 'my
> @a = (^1)>>.Str'
> Writing profiler output to profile-1515272304.87249.html
> dogbert@dogbert-VirtualBox ~/repos/rakudo $ ./perl6 --profile -e 'my
> @a = (^25000)>>.Str'
> Writing profiler output to profile-1515272310.68317.html
> dogbert@dogbert-VirtualBox ~/repos/rakudo $

[perl #124679] [@LARRY] Rakudo allows using '#`' (embedded comment) without following opening bracket, should not

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Ah. Now I see why.

Consider this:

#`| foo |

↑ that does not DWIM. And it's right to assume that you can do it because s|||
works just fine. So either it should understand stuff like this, or it can give
an error message as todo-ed.

So no, this is not rejectable. And the actual issue is about non-bracket
characters, I think.

On 2017-12-02 05:42:13, alex.jakime...@gmail.com wrote:
> But why? “#` foo” looks like a fine normal comment, why should it
> error out on
> a perfectly normal behavior?
>
> I think this ticket is rejectable. Someone with bigger whatever should
> reject
> it.
>
> On 2015-07-01 12:54:40, barto...@gmx.de wrote:
> > This ticket is about a failing test (fudged 'todo') in S32-
> > exceptions/misc.t. Rakudo does not complain about a plain '#`',
> > whereas STD does:
> >
> > $ perl6 -e '#`'
> > $ viv -e '#`'
> > ===SORRY!===
> > Opening bracket is required for #` comment at (eval) line 1:
> > --> #`⏏
> > Parse failed
> >
> > According to S02 '#`' has to be followed by an opening bracket
> > character: http://design.perl6.org/S02.html#Embedded_Comments

[perl #127881] [PERF] slow array slicing

[Aleks-Daniel Jakimenko-Aleksejev via RT]

FWIW this issue was noticed today:
https://irclog.perlgeek.de/perl6/2017-12-16#i_15587006

On 2016-04-11 20:40:43, ddgr...@gmail.com wrote:
> '@array[0, 3, 7]' is much slower than '(@array[0], @array[3], @array[7])'
>
>
> time perl6 -e 'my @a = ^500;my @f;my $s = @a.elems;loop (my $i1 = 0; $i1 <
> $s-1; $i1++) { loop (my $i2 = $i1+1; $i2 < $s; $i2++) { @f.push(@a[$i1,
> $i2]) } };'
>
> real 0m14.974s
> user 0m14.947s
> sys 0m0.017s
>
>
> time perl6 -e 'my @a = ^500;my @f;my $s = @a.elems;loop (my $i1 = 0; $i1 <
> $s-1; $i1++) { loop (my $i2 = $i1+1; $i2 < $s; $i2++) { @f.push((@a[$i1],
> @a[$i2])) } };'
>
> real 0m0.897s
> user 0m0.877s
> sys 0m0.017s
>
>
> With Rakudo version 2016.03 built on MoarVM version 2016.03
>
> Dan

[perl #127775] Declaring enums with Bools, IntStrs and maybe other things ( enum Foo (:Bar(1), :Baz(True) ))

[Aleks-Daniel Jakimenko-Aleksejev via RT]

I am pretty sure that this commit is relevant to this issue:
https://github.com/rakudo/rakudo/commit/fc52143beee3178c7f39d770f95c7d60b2a1a1e4

On 2017-10-07 17:20:37, alex.jakime...@gmail.com wrote:
> Zoffix++ pointed out that there is a problem with IntStr also:
>
> Code:
> enum Foo (:Bar(1), :Baz(<42>))
>
> Result:
> ===SORRY!===
> Incompatible MROs in P6opaque rebless for types IntStr and Foo
>
> On 2017-10-07 17:16:30, alex.jakime...@gmail.com wrote:
> > Actually, it's not about the error message. The whole thing can be
> > golfed to
> > this:
> >
> > enum Foo (:Bar(1), :Baz(True))
> >
> > And the error happens because:
> >
> > Code:
> > use nqp;
> > say so nqp::istype(True, Int);
> > nqp::rebless(True, Int)
> >
> > Result:
> > True
> > Incompatible MROs in P6opaque rebless for types Bool and Int
> > in block  at -e line 3
> >
> > Or something like that. So it is “istype” of something but you can't
> > rebless
> > it.
> >
> > The type is checked here:
> >
>
https://github.com/rakudo/rakudo/blob/de0533c4d4c9f425ce22432a8e4555ded27cba91/src/Perl6/Actions.nqp#L4621
> >
> > Rebless is here:
> >
>
https://github.com/rakudo/rakudo/blob/5144216f6ea723747cb25fea51f99861c1ea213a/src/Perl6/World.nqp#L3629
> >
> > IRC logs:
> > https://irclog.perlgeek.de/perl6/2017-10-07#i_15272313
> > https://irclog.perlgeek.de/perl6/2017-10-08#i_15272350
> >
> > I really don't know what to do about it. You cannot just .Int it
> > because
> > stringy enums exist (enum Foo (:Bar("foo")); say Bar). It's weird.
> >
> > On 2016-07-10 07:01:59, c...@zoffix.com wrote:
> > > Still present today on rakudo 89470a:
> > >
> > >  m: enum Foo <<:Bar(1) :Baz>>
> > >  rakudo-moar 89470a: OUTPUT«===SORRY!===␤Incompatible MROs
> > > in
> > > P6opaque rebless for types Bool and Foo␤»

[perl #132525] [REGRESSION][PRECOMP] type constraints to Array[Pair] don't work when precompiled

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Oh, by the way. The issue goes much farther than 2015.12, so the underlying
issue is not a regression.

On 2017-12-13 23:42:11, alex.jakime...@gmail.com wrote:
> We can, but I'd much rather have this particular case tested (and to
> make sure
> that it is, we'll close it with tests once the issue is resolved).
>
> For example, here's this interesting bit:
> https://github.com/rakudo/rakudo/blob/master/src/core/core_prologue.pm#L2
> :
>
> my class Pair { ... } # must be first for some reason
>
> I don't know if it's related to this issue, but Pairs are weird for
> some
> reason. Adding a test won't hurt for sure.
>
> On 2017-12-13 23:33:43, d...@zwell.net wrote:
> > Thanks for finding that. Can we close this duplicate bug? Issue
> > #128287 has
> > stronger steps to reproduce, and using that test case, I found this
> > bug
> > goes back to at least 2015.12.
> >
> > On Wed, Dec 13, 2017 at 11:56 PM Zoffix Znet via RT <
> > perl6-bugs-follo...@perl.org> wrote:
> >
> > > On Wed, 06 Dec 2017 01:59:42 -0800, d...@zwell.net wrote:
> > > > A git bisect showed that this error began in commit
> > > > 22b4ef05b1f72b50d63e4599d5e037bccf1f08ed, but there must be have
> > > > been
> > > > an
> > > > underlying problem that was already present, since this commit
> > > > did not
> > > > change the type system.
> > > >
> > > > On Fri, Dec 1, 2017 at 6:00 PM perl6 via RT  > > > follo...@perl.org>
> > > > wrote:
> > > >
> > > > > Greetings,
> > > > >
> > > > > This message has been automatically generated in response to
> > > > > the
> > > > > creation of a trouble ticket regarding:
> > > > > "[BUG] type constraints to Array[Pair] don't work when
> > > > > precompiled",
> > > > > a summary of which appears below.
> > > > >
> > > > > There is no need to reply to this message right now. Your
> > > > > ticket has
> > > > > been
> > > > > assigned an ID of [perl #132525].
> > > > >
> > > > > Please include the string:
> > > > >
> > > > > [perl #132525]
> > > > >
> > > > > in the subject line of all future correspondence about this
> > > > > issue. To
> > > > > do
> > > > > so,
> > > > > you may reply to this message.
> > > > >
> > > > > Thank you,
> > > > > perl6-bugs-follo...@perl.org
> > > > >
> > > > >
> > > -
> > > > > The following function runs fine when it's not defined in an
> > > > > external
> > > > > file:
> > > > >
> > > > > our sub get-array(--> Array[Pair]) {
> > > > > return my Pair @pairs;
> > > > > }
> > > > >
> > > > > But when if you put the above code in a module and run it with:
> > > > > perl6 -I. -MMyModule -e 'MyModule::get-array'
> > > > >
> > > > > The output is:
> > > > > Type check failed for return value; expected Array[Pair] but
> > > > > got
> > > > > Array[Pair].new()
> > > > > in sub get-array at MyModule.pm6 (MyModule) line 2
> > > > >
> > > > > Tested with:
> > > > > Rakudo version 2017.10 built on MoarVM version 2017.10
> > > > > Rakudo version 2017.10-196-gfff43fd70 built on MoarVM version
> > > > > 2017.10-77-gb9a01f75
> > > > >
> > > > >
> > >
> > >
> > > These two tickets have the same symptoms:
> > >
> > > https://rt.perl.org/Ticket/Display.html?id=128287#ticket-history
> > > https://rt.perl.org/Ticket/Display.html?id=127001#ticket-history
> > >

[perl #132525] [REGRESSION][PRECOMP] type constraints to Array[Pair] don't work when precompiled

[Aleks-Daniel Jakimenko-Aleksejev via RT]

We can, but I'd much rather have this particular case tested (and to make sure
that it is, we'll close it with tests once the issue is resolved).

For example, here's this interesting bit:
https://github.com/rakudo/rakudo/blob/master/src/core/core_prologue.pm#L2 :

my class Pair { ... } # must be first for some reason

I don't know if it's related to this issue, but Pairs are weird for some
reason. Adding a test won't hurt for sure.

On 2017-12-13 23:33:43, d...@zwell.net wrote:
> Thanks for finding that. Can we close this duplicate bug? Issue #128287 has
> stronger steps to reproduce, and using that test case, I found this bug
> goes back to at least 2015.12.
>
> On Wed, Dec 13, 2017 at 11:56 PM Zoffix Znet via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
> > On Wed, 06 Dec 2017 01:59:42 -0800, d...@zwell.net wrote:
> > > A git bisect showed that this error began in commit
> > > 22b4ef05b1f72b50d63e4599d5e037bccf1f08ed, but there must be have been
> > > an
> > > underlying problem that was already present, since this commit did not
> > > change the type system.
> > >
> > > On Fri, Dec 1, 2017 at 6:00 PM perl6 via RT  > > follo...@perl.org>
> > > wrote:
> > >
> > > > Greetings,
> > > >
> > > > This message has been automatically generated in response to the
> > > > creation of a trouble ticket regarding:
> > > > "[BUG] type constraints to Array[Pair] don't work when
> > > > precompiled",
> > > > a summary of which appears below.
> > > >
> > > > There is no need to reply to this message right now. Your ticket has
> > > > been
> > > > assigned an ID of [perl #132525].
> > > >
> > > > Please include the string:
> > > >
> > > > [perl #132525]
> > > >
> > > > in the subject line of all future correspondence about this issue. To
> > > > do
> > > > so,
> > > > you may reply to this message.
> > > >
> > > > Thank you,
> > > > perl6-bugs-follo...@perl.org
> > > >
> > > >
> > -
> > > > The following function runs fine when it's not defined in an external
> > > > file:
> > > >
> > > > our sub get-array(--> Array[Pair]) {
> > > > return my Pair @pairs;
> > > > }
> > > >
> > > > But when if you put the above code in a module and run it with:
> > > > perl6 -I. -MMyModule -e 'MyModule::get-array'
> > > >
> > > > The output is:
> > > > Type check failed for return value; expected Array[Pair] but got
> > > > Array[Pair].new()
> > > > in sub get-array at MyModule.pm6 (MyModule) line 2
> > > >
> > > > Tested with:
> > > > Rakudo version 2017.10 built on MoarVM version 2017.10
> > > > Rakudo version 2017.10-196-gfff43fd70 built on MoarVM version
> > > > 2017.10-77-gb9a01f75
> > > >
> > > >
> >
> >
> > These two tickets have the same symptoms:
> >
> > https://rt.perl.org/Ticket/Display.html?id=128287#ticket-history
> > https://rt.perl.org/Ticket/Display.html?id=127001#ticket-history
> >

[perl #87034] [BUG] Either binding an array to a list containing the array itself should work consistently or not at all in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

By the way, there is a pull request: https://github.com/rakudo/rakudo/pull/1020

But the work on it is kinda stalled.

On 2017-02-17 04:22:51, alex.jakime...@gmail.com wrote:
> Reopened for now.
>
> See RT #121807 and RT #125371 for more info. Basically, there will be
> no error
> after I'm done with everything.
>
> In case of binding, @foo will appear as Mu. Binding doesn't make much
> sense in
> this case, DIHWIDT.
>
> (Mu Z+ 5) will error out normally.
>
> On 2015-11-10 13:59:32, barto...@gmx.de wrote:
> > Since Rakudo commit 3754356d8e this fails with
> > X::Syntax::Variable::Initializer:
> >
> > $ perl6-m -e 'my @foo := 1..3, @foo; .say for @foo[^10]'
> > ===SORRY!=== Error while compiling -e
> > Cannot use variable @foo in declaration to initialize itself
> > at -e:1
> > --> my @foo := 1..3, @⏏foo; .say for @foo[^10]
> > expecting any of:
> > term
> >
> > In other words, binding an array to a list containing the array
> > itself
> > does not work at all. Therefore I'm closing this ticket as
> > 'resolved'.
> >
> > Test: https://github.com/perl6/roast/commit/dca1faef23

[perl #121987] Negated generic comparisons do not chain correctly

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Closing this ticket in favor of this one:
https://github.com/rakudo/rakudo/issues/1304

On 2017-12-01 11:03:43, alex.jakime...@gmail.com wrote:
> Still failing (2017.11, HEAD(5929887))
>
> On 2014-07-31 13:05:19, david.warring wrote:
> > I've added some fudged tests to S03-operators/relational.t. A couple
> > taken from the above test cases, also:
> >
> > is 3 !> 3 !> 1, 3 !> 3 && 3 !> 1, 'chained !>';
> > is 3 !< 3 !< 2, 3 !< 3 && 3 !< 2, 'chained !<';
> >
> > Both failing
> >
> > On Thu May 29 23:26:36 2014, thoughtstream wrote:
> > > As the following test program illustrates, !before and !after do not
> > > always chain correctly under Rakudo perl6 version 2014.04 built
> > > on MoarVM version 2014.04.
> > >
> > > Damian
> > >
> > > -cut--cut--cut--cut--
> > > cut--
> > > cut--cut-
> > >
> > > #! /usr/bin/env perl6
> > > use v6;
> > >
> > > use Test;
> > >
> > > for 1..3 X 1..3 X 1..3 -> $x, $y, $z {
> > >
> > > is $x before $y before $z,
> > > $x before $y && $y before $z, "$x before $y before $z";
> > >
> > > is $x !before $y !before $z,
> > > $x !before $y && $y !before $z, "$x !before $y !before $z";
> > >
> > > is $x after $y after $z,
> > > $x after $y && $y after $z, "$x after $y after $z";
> > >
> > > is $x !after $y !after $z,
> > > $x !after $y && $y !after $z, "$x !after $y !after $z";
> > > }
> > >
> > > done;
> > >
> > >
> > > -end--end--end--end--
> > > end--
> > > end--end-

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

[Aleks-Daniel Jakimenko-Aleksejev via RT]

FWIW it never worked:
https://gist.github.com/Whateverable/d9dbebb0e985a3964845df2c8652cbdf

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

[perl #132487] Accessing the native-descriptor() from a Proc output seems to break it.

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Some *able info, if anyone is interested:

Output on all releases:
https://gist.github.com/a68b094519839b939f8c70d66a80d8c0

Some possibly relevant commits:
https://github.com/rakudo/rakudo/commit/92bd7e4f54a92fa660f99b4d056d33a08fb98bd2
https://github.com/rakudo/rakudo/commit/6dae179a8418bd2fcf5cc4b23e0feb3727c794a1

On 2017-11-22 11:26:59, c...@tilmes.org wrote:
> % perl6 -e 'my $proc = run "cat", :in, :out; $proc.in.say: "test\n"; say
> $proc.out.get; $proc.in.close;'
> test
>
> % perl6 -e 'my $proc = run "cat", :in, :out; say
> $proc.out.native-descriptor; $proc.in.say: "test\n"; say $proc.out.get;
> $proc.in.close;'
> 28
> Nil

[perl #122972] [NYI] Proto regex with params isn't called correctly (possibly NYI) in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still NYI (2017.11,HEAD(e5b660e))

On 2014-10-14 01:02:45, masak wrote:
>  m: grammar Test { token TOP {  }; proto token
> Foo(Int) {*}; token Foo:sym(Int $a) { "a" }; token Foo:sym(Int
> $a) { "b" } }; say Test.parse("a");
>  rakudo-moar 8b3e8c: OUTPUT«Too few positionals passed;
> expected 2 arguments but got 1␤ in regex Foo:sym [...]
>  ven++ stumbled upon this
> * masak submits rakudobug
>  that should work, right?
>  yes.
>  It's very likely to be NYI, I think
>  huh
>  aren't we using something like that in rakudo's own grammar
> all the time?
>  A proto regex with params? Could be, but it'd be new to me
>  Also, Rakudo doesn't compile Rakudo's grammar. :-)

[perl #122992] [BUG] Declaring a 'my' array or hash typed with a type parameter ends up blowing up with a fixable error message about instantiating generics in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Seems to be reproducible (2017.11,HEAD(e5b660e))

On 2014-10-16 13:43:34, masak wrote:
> camelia was having some indigestion in the below backlog, which is why
> I'm reporting some local evals (from "This is perl6 version
> 2014.09-202-g8b3e8c2 built on MoarVM version 2014.09-54-g03ac9a7").
>
>  m: class A { my ::?CLASS @.foo }; A.foo.push(2)
>  rakudo-moar 86dc3c: OUTPUT«(timeout)»
>  locally, "Type check failed in .push; expected 'A' but got
> 'Int'"
>  (wow)
>  lizmat++ jnthn++, no doubt
>  masak: are they to blame for this? :)
>  timotimo: it's amazing! it recognizes `A` as the current
> class, *and* it typechecks against it on .push
>  timotimo: woot!
>  that *is* neat.
>  masak: Note it's more useful use is in roles, where ::?CLASS
> is generic.
>  jnthn: I'm just about to factor my current code into a role :>
>  aww.
>  ===SORRY!===
>  No such method 'instantiate_generic' for invocant of type
> 'Array[::?CLASS]'
>  Awww :(
>  m: role R { my ::?CLASS @.x }; class C does R {}; say "alive"
>  locally: "No such method 'instantiate_generic' for invocant of
> type 'Array[::?CLASS]'"
>  rakudo-moar 86dc3c: OUTPUT«(timeout)»
>  jnthn: any non-torment reason that shouldn't be possible?
>  m: role R { my ::?CLASS $.x }; class C does R {}; say "alive"
>  locally: "alive"
>  rakudo-moar 86dc3c: OUTPUT«(timeout)»
>  if I remove the ::?CLASS type constraint, using a role still
> works.
>  m: role R { has ::?CLASS @.x }; class C does R {}; say "alive"
>  locally: "alive"
>  rakudo-moar 86dc3c: OUTPUT«(timeout)»
>  so it's only in the very specific case of `my` + `::?CLASS` +
> `@` that it blows up...
>  oh, and `role`
>  masak: It's the "my" that does it
>  masak: I think it's fixable
>  nice.
> * masak submits rakuodbug
>  Well, I'd not say it'll be nice to fix, but... :P
>  m: sub foo(::T $x) { my T @a; }; foo(42)
>  rakudo-moar 86dc3c: OUTPUT«No such method
> 'instantiate_generic' for invocant of type 'Array[T]' [...]
>  Hah, gulf. :)
>  :)
>  but `my`, type parameter, and `@` sigil are still essential,
> yes?
>  Yes, but it can be a type parameter of a role or the sub
>  m: sub foo(::T $x) { my T %h; }; foo(42)
>  rakudo-moar 86dc3c: OUTPUT«(timeout)»
>  locally, "No such method 'instantiate_generic' for invocant of
> type 'Hash[T]'"

[perl #125200] [Bug] parametric role generic type not resolving early enough?

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still reproducible (2017.11,HEAD(e5b660e))

On 2015-05-15 11:25:07, jdv79 wrote:
> The first example there should have been:
>
> [jdv@wieldy ~]$ perl6 -e 'role Foo[::T] { has Int @.a }; say
> Foo[Int].new.a.WHAT'
> (Array[Int])
> [jdv@wieldy ~]$ perl6 -e 'role Foo[::T] { has T @.a }; say
> Foo[Int].new.a.WHAT'
> (Array[T])
> [jdv@wieldy ~]$
>
> Oops.
>
> On Fri May 15 11:20:36 2015, jdv79 wrote:
> > Some examples that I expected would be equivalent:
> >
> > 1. WHAT
> >
> > [jdv@wieldy ~]$ perl6 -e 'role Foo[::T] { has Int @.a }; say
> > Foo[Int].new.a.perl'
> > Array[Int].new()
> > [jdv@wieldy ~]$ perl6 -e 'role Foo[::T] { has T @.a }; say
> > Foo[Int].new.a.WHAT'
> > (Array[T])
> > [jdv@wieldy ~]$
> >
> > 2. method call on type obj
> >
> > [jdv@wieldy ~]$ perl6 -e 'role Foo[::T] { has Int @.a }; say
> > Foo[Int].new.a.perl'
> > Array[Int].new()
> > [jdv@wieldy ~]$ perl6 -e 'role Foo[::T] { has T @.a }; say
> > Foo[Int].new.a.perl'
> > Method 'perl' not found for invocant of class 'T'
> > in block  at -e:1

[perl #76744] [TODO] implement :dba adverbs in regexes

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Related doc ticket (with some discussion):
https://github.com/perl6/doc/issues/1695

On 2010-07-27 02:32:49, moritz wrote:
> alpha supported :dba('rule name'), current Rakudo doesn't, but should.

[perl #126030] Multi-dim hash loses track of leaf type

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still reproducible (2017.11,HEAD(e5b660e))

On 2015-09-09 22:28:41, larry wrote:
> 22:22 < TimToady> m: my Bool %hash{*;*}; %hash{"a"; "b"} = True;
> 22:22 <+camelia> rakudo-moar c54773: OUTPUT«Type check failed in assignment
> to '%hash'; expected 'Bool' but got 'Hash'␤ in block 
> at /tmp/NWldXMtkgi:1␤␤»

[perl #126116] [BUG] native type constraint inconsistently applied

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still reproducible (2017.11,HEAD(e5b660e))

On 2015-09-20 09:07:10, zef...@fysh.org wrote:
> Because a type object is an (undefined) instance of that type, it can
> in general be stored in a variable constrained to that type. We can
> demonstrate this with a subroutine taking a type parameter:
>
> $ ./perl6 -e 'sub aa (Mu:U ::T) { my T $a = T; say $a; }; aa(Any);
> aa(Int); aa(int)'
> (Any)
> (Int)
> (int)
>
> But if we try to do the same thing without the indirection of the
> subroutine, it behaves differently on native types:
>
> $ ./perl6 -e 'my Any $a = Any; say $a; my Int $b = Int; say $b; my int
> $c = int; say $c'
> (Any)
> (Int)
> Cannot unbox a type object
> in block  at -e:1
>
> This indirection shouldn't make such a visible difference. Obviously
> there's some connection here to the specialised representation implied
> by the int type, and the fact that that representation can't
> accommodate
> the int type object. It's fine for the specialised representation to
> be used in only one of these two cases, but that should be an
> invisible
> implementation detail. Perhaps the specialised representation should
> only be used where the variable is constrained to *defined* ints.
>
> Another inconsistency arises in how assignment of a boxed value to the
> variable is treated:
>
> $ ./perl6 -e 'sub aa (Mu:U ::T) { my T $a = 3; say $a.WHAT; };
> aa(Any); aa(Int); aa(int)'
> (Int)
> (Int)
> Type check failed in assignment to '$a'; expected 'int' but got 'Int'
> in sub aa at -e:1
> in block  at -e:1
> $ ./perl6 -e 'my Any $a = 3; say $a.WHAT; my Int $b = 3; say $b.WHAT;
> my int $c = 3; say $c.WHAT'
> (Int)
> (Int)
> (Int)
>
> -zefram

[perl #123903] [BUG] Some forms of "dynamic symbol lookup" syntax cause compiler error in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

As of today (2017.11,HEAD(e5b660e)) it gives this:

===SORRY!=== Error while compiling -e
Variable '$' is not declared
at -e:1
--> say defined ⏏$::


There was another ticket that had exactly the same change of an error message,
perhaps worth searching for it (ping me if you really want to find it).

On 2015-02-22 14:03:46, sml...@gmail.com wrote:
> The behavior is different for the various syntax forms for looking up
> symbols dynamically:
>
> A) The [sigil at the start; null pseudo-package; name in curly or
> angle brackets] form throws an "Index out of bounds" error:
>
>
> $ perl6-m -e 'say defined $::{"foo"}'
> ===SORRY!===
> MVMArray: Index out of bounds
>
> $ perl6-m -e 'say defined $::'
> ===SORRY!===
> MVMArray: Index out of bounds
>
> $ perl6-m -e 'say defined &::'
> ===SORRY!===
> MVMArray: Index out of bounds
>
> B) The [sigil at the start; *named* pseudo-package; name in curly or
> angle brackets] form fails with "Undeclared routine: " or similar
> if the sigil is &, but works fine for other sigils:
>
> say defined ::{"foo"}'
> ===SORRY!=== Error while compiling -e
> Undeclared routine:
>  used at line 1
>
> $ perl6-m -e 'say defined ::'
> ===SORRY!=== Error while compiling -e
> Undeclared routine:
>  used at line 1
>
> $ perl6-m -e 'say defined $MY::'
> False
>
> C) The remaining forms seem to work fine.
>
> In particular all the ones that use parens instead of curly/angle
> brackets to look up the name:
>
> $ perl6 -e 'say .defined for &::("foo"), ::("foo"), $MY::("foo")
> False
> False
> False
>
> As well as the ones that treat the sigil as part of the name:
>
> $ perl6 -e 'say .defined for ::<$foo>, ::<>, MY::<>'
> False
> False
> False

[perl #122838] [BUG] BEGIN GLOBAL:: assignment does not work in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

As of today (2017.11,HEAD(e5b660e)) it prints this:

Cannot call method 'new' on a null object
in block  at -e line 1

Which is arguably reasonable, but I guess it's not good enough.

On 2014-09-24 04:03:12, masak wrote:
>  m: BEGIN GLOBAL:: = class { }; Test.new;
>  rakudo-moar 682e03: OUTPUT«===SORRY!===␤Object of type
>  in QAST::WVal, but not in SC␤»
>  nine: looks like a bug.
>  masak: any idea how I can create a class with a fully qualified
> name from an EVAL that's deep in some other namespace?
>  masak: as in Inline::Perl5::Perl6PackageCreator::create runs an
> EVAL that should create a class called Foo::Bar::Baz.
>  nine: EVAL "class Foo::Bar::Baz {}" doesn't cut it ?
>  alternately EVAL "class Foo { class Bar { class Baz {}}}' ?
>  or actually, maybe both?
>  lizmat: nope, that creates
> Inline::Perl5::Perl6PackageCreator::Foo::Bar::Baz (what a handy name
> ;)
>  m: BEGIN GLOBAL:: := class { }; Test.new;
>  rakudo-moar 682e03: ( no output )
>  ah, := works, while = does not
>  nine: Does class GLOBAL::Foo::Bar::Baz { } not do it?
>  jnthn: no, the GLOBAL:: is pretty much ignored
>  ah
>  Maybe that wants fixing
>  But afer dinner
> * masak submits rakudobug
>  jnthn: according to S10, GLOBAL:: should do it though
>  nine: That's my feeling too

[perl #122991] [TODO] Implement 'handles' for 'my'-scoped (class) variables in classes

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still reproducible (2017.11,HEAD(e5b660e)) (complains about
trait_mod:)

On 2014-10-16 13:07:07, masak wrote:
>  m: class A { my @.foo handles  }; A.push("OH", "HAI");
> say A.foo
>  rakudo-moar a6f181: OUTPUT«(timeout)»
>  locally: "Cannot call 'trait_mod:'; none of these
> signatures match" (Attribute, Method)
>  am I greedy for wanting `my` + twigil + `handles` to work?
>  is that even theoretically possible?
>  it would be so awesome.
>  masak: my @.foo supporting handles is a cute idea at least.
> It's not entirely straightforward.
>  masak: But feasible with effort.
>  No objections to filing a TODO ticket for it.
>  developer torment? sounds like... a job for Perl 6! :P
>  what's the saying again: "tormenting developers just for the
> sake of it"
> * masak submits TODO ticket

[perl #126107] [BUG] "of" type constraint inconsistently applied

[Aleks-Daniel Jakimenko-Aleksejev via RT]

All of these were fixed (2017.11,HEAD(e5b660e)).

Strings give compile-time errors, putting Any into something results in an Int.
Curious minds can ask bisectable for details.

｢testneeded｣

On 2015-09-20 17:26:00, zef...@fysh.org wrote:
> Extended case: if the "of" clause comes after an "is default" clause,
> then the explicit default is not subjected to the type constraint.
> Other behaviour remains the same.
>
> $ ./perl6 -e 'my $a is default("foo") of Int; say $a'
> foo
> $ ./perl6 -e 'my $a is default("foo") of Int; $a = $a; say $a'
> Type check failed in assignment to '$a'; expected 'Int' but got 'Str'
> in block  at -e:1
> $ ./perl6 -e 'my $a is default("foo") of Int; $a = 3; say $a; $a =
> Nil; say $a'
> 3
> foo
>
> -zefram

[perl #123835] Cannot use 'is rw' on optional parameter

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still reproducible (2017.11,HEAD(e5b660e))

I don't know if it's NYI or @LARRY. I'd put LARRY first, and then one of the
LARRYs can turn it into a NYI.

On 2015-08-05 15:25:57, barto...@gmx.de wrote:
> The relevant sentences from the design docs (S06, introduced with
> commit 7846594ee4):
>
> "Since this option [is rw] forces an argument to be required, it
> cannot coexist with the ? mark to make an argument optional. (It may,
> however, be used with = indicating a default, but only if the default
> expression represents something that is nameable at compile time and
> that can bind as an lvalue, such as CALLER::<$/> or OUTER::<$_>.)"
>
> AFAIU the default value in question (= 60) does not qualify as a valid
> "is rw"-able expression according to S06.
>
> Rakudo makes no difference between parameters made optional with the ?
> mark or those made optional by providing a default value and simply
> disallows 'is rw' (introduced with commit 45c44bafbf), e.g.:
>
> $ perl6 -e 'sub f($x is rw = OUTER::<$_>) {$x++; say $x}; $_ = 41; f'
> ===SORRY!=== Error while compiling -e
> Cannot use 'is rw' on an optional parameter
> at -e:1

[perl #116783] [BUG] 'my' class in role should be generic in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Output on all releases:
https://gist.github.com/Whateverable/297882f4f84bb8362a0ce0523439c436

On 2013-02-16 09:14:04, masak wrote:
>  r: https://gist.github.com/TimToady/4963642
>  jnthn: that gets me an error Nominal type check failed for
> parameter '$payload'; expected T but got Int instead
>  but T is supposed to instantiate to Int
>  Sure is.
>  Any idea exactly which T it is?
>  the sig in post-insert
>  oh.
>  role DLL[::T] {
>  my class DLLE does DLL_Element[T] {}
>  You nested a class in a role.
>  I don't know how to do that otherwise
>  Roles aren't as macro-ish as you expected them...
>  It doesn't make a fresh class per role instance.
>  well, I guess I can instantiate in parallel, but it'd be
> nice if one could drive the other
>  And the one declaration sees the uninstantiated type variable,
> 'cus it comes into existence before the role is ever composed.
>  okay...have to think about it s'more
>  Does the spec make a call on what happens to packages declared
> inside roles? iirc, it doesn't call either way
>  I've always had it down as a grey area. :)
>  here be grey dragons...
>  I suspect we *could* find a way to make it work but by then
> we're pushing roles further into macro territory
>  .oO( TimToady: "Do I want this enough to change the spec so
> jnthn has to make it so ...?" :-) )
>  I just think it's kind of typical to want to instantiate a
> forest of classes together
>  TimToady: While you're on it, you may also wish to ponder this
> issue:
>  r: role Foo { our sub foo() { say 42 } }; Foo::foo()
> 22:31 <+p6eval> rakudo 1e85ff: OUTPUT«Could not find symbol ''
> [...]
>  That at first blush looks like it should work, but it doesn't
> at the moment.
>  The reason it doesn't is...
>  role Foo { }; role Foo[::T] { }
>  Roles are multiple dispatch
>  What's actually installed in Foo is not actually the role.
> It's basically a thingy that does a multi dispatch to pick a role.
>  Which gets a type object of its own.
>  ParametricRoleGroupHOW or so.
>  the downside to all this punning...
>  .oO( punning for the fjords...)
>  Yeah. Well, I've mentioned before just how many different
> forms roles come in :)
>  Which I don't see as a problem per se.
>  But the only sane way I found to implement all the things is
> to untangle the puns.
>  tbh, I think putting our scoped stuff inside something generic
> is crazy anyway...
> * TimToady imagines Foo as a search path of packages, and shudders
>  which is why I declared my inner class with 'my' :)
>  That is, I can imagine that if you try to install something
> our-scoped inside a role, we say "no, this won't end well" :)
>  Yeah. I can see what you wanted it to do. :)
>  I'm just asking if we really want the complexity of doing it
> :)
>  dunno; do Java generics have a story on this sort of thing?
>  It *is* the same machinary masak++ will want for declarations
> in macros, so in a sense we're gonna have to solve the problem anyway.
>  .oO(and you thought *monads* were hard to lift...)
>  Java generics are mostly an example of what not to do. :)
>  C# ones, otoh, are done properly.
>  so what do they do in this case?
>  In C#, if you write an inner class inside a generic class, it
> also becomes generic.
>  Hm, darn, I just said that's the proper thing to do, didn't
> I... :)
> * TimToady is not going to torment the implementors (much) more than
> they torment themselves
>  From the spec:
>  Any class nested inside a generic class declaration or a
> generic struct declaration (§25.2) is itself a generic class
> declaration, since type parameters for the containing type shall be
> supplied to create a constructed type.
>  We maybe don't want quite that factoring, since our type
> parameters are just lexical.
>  We just want to hang on to the class in a generic form and
> then reify it.
>  but an inner class that is dependent on T, like mine...
>  Well, I guess we'd treat any class inside a role as generic in
> some sense.
>  I suspect making it do what you expected is (a) possible, (b)
> least surprising, and (c) hard. :)
>  Which basically makes it a great candidate for a Perl 6
> feature. ;-)
>  vicarious suffering, and all that...
>  well, just because it's Friday doesn't mean you have to do
> it today :)
>  :)
>  Anyway, no objections if you want to spec it that way.
> * TimToady is not sure he understands it well enough yet to talk about
> it
>  TimToady, jnthn: could either of you golf an example of
> expected/actual behavior of a class nested in a generic role? then I
> can rakudobug it.
>  masak: here: https://gist.github.com/TimToady/4967666
>  r: role Foo[::T] { has T $.p = T }; role Bar[::T] { my class
> Fooey does Foo[T] {}; submethod BUILD { Fooey.new } }; class RatBar
> does Bar[Rat] {}; RatBar.new
>  rakudo 1e85ff: OUTPUT«Cannot type check against type variable
> T [...]
> * masak submits rakudobug
>  and yes, RatBar is an allusion to the Vorkosigan universe
> :)

[perl #110820] [BUG] Variable declaration inside statement_modifier for inside junction triggers bogus redeclaration error in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

This wasn't updated in a while. As of today (2017.11,HEAD(e5b660e)), it still
complains about final ) like mentioned in one of the recent comments. And yes,
this tickets seems to be rejectable.

On 2015-07-20 09:27:25, duff wrote:
> I'm not sure this is a bug. The postfix for is a statement modifier,
> and it's being used in an argument list context. For it to parse
> right, you'd have to do something like this:
>
> all( do { my $c for () } );
>
> or even
>
> all( (my $c for ()) );
>
> I didn't test the version with the balanced sub, but I guess it would
> require something similar.
>
> -Scott
>
> On Wed Feb 15 06:37:15 2012, masak wrote:
> >  nom: sub balanced { all((my $c += $_ eq "[" ?? 1 !! -1) < 0
> > for $^s.comb) && !$c }; .say when  for (^(2 **
> > 6))».fmt("%06b")».trans("01" => "[]")
> >  nom bd5adb: OUTPUT«===SORRY!===␤Redeclaration of symbol
> > $c␤at
> > /tmp/f7OZkWSnoP:1␤»
> >  huh.
> >  nom: all(my $c for ())
> >  nom bd5adb: OUTPUT«===SORRY!===␤Redeclaration of symbol
> > $c␤at
> > /tmp/XLWPyMzIwp:1␤»
> >  that's the shortest I can make it.
> > * masak submits rakudobug

[perl #124007] [BUG] method delegation doesn't work in roles

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still reproducible (2017.11,HEAD(e5b660e))

On 2015-03-06 14:35:06, rayd...@cyberuniverses.com wrote:
> As seen at http://irclog.perlgeek.de/perl6/2015-03-06#i_10237611 :
>
> r: role R { method foo () handles  { } }
> rakudo-moar 1b74e4: OUTPUT«===SORRY!=== Error while compiling
> /tmp/tmpfile␤Method 'add_method' not found for invocant of class
> 'Perl6::Metamodel::GenericHOW'␤at /tmp/tmpfile:1␤--> ␤»

[perl #125487] Possible MMD issue when binding nqp::null() ??

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still reproducible (2017.11,HEAD(e5b660e))

On 2015-06-26 02:25:27, elizabeth wrote:
> [10:57:16]  m: use nqp; my %h; %h := nqp::null()
> #h
> [10:57:16] <+camelia> rakudo-moar 3d645f: OUTPUT«Unexpected named
> parameter 'BIND' passed␤ in block  at /tmp/GYnIiEF0VO:1␤␤»
>
> This looks strange to me, as we have the right candidate for this
> case:
>
> multi sub postcircumfix:<{ }>( \SELF, \key ) is rw { # <— we fail
> here
> SELF.AT-KEY(key);
> }
> multi sub postcircumfix:<{ }>(\SELF, \key, Mu :$BIND! is parcel) is rw
> { # <— ok candidate??
> SELF.BIND-KEY(key, $BIND);
> }
>
> Oddly enough, it looks like BIND-KEY *can* handle the case well:
>
> $ 6 'use nqp; my %h; %h.BIND-KEY("a",nqp::null()); say %h.perl'
> {:a(Mu)}<>
>
>
> A similar issue exists with binding nqp::null() to array elements:
>
> $ 6 'use nqp; my @a; @a[0] := nqp::null()'
> Unexpected named parameter 'BIND' passed
> in block  at -e:1
> $ 6 'use nqp; my @a; @a.BIND-POS(0,nqp::null()); say @a.perl'
> [Mu]<>
>
>
> I guess the dispatcher cannot see the difference between the absence
> of a value and nqp::null()?
>
> If this is a case of DIHWIDT, then so be it. I was just trying to see
> if we could make the :delete adverb more sensical for arrays, by
> making it splice. And introduce a new :null adverbs that would have
> the current semantics on arrays, and similar semantics on hashes (aka,
> effectively turning the hash into a SetHash with keys only).
>
>
> Liz

[perl #120394] [BUG] Can't access private attributes through the ::('$!x') syntax in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still reproducible (2017.11,HEAD(e5b660e))

On 2013-10-28 02:49:38, masak wrote:
>  p: class A { has $!x = 42; method get() { ::('$!x') } }; say
> A.new.get
>  rakudo-parrot 3cef56: OUTPUT«No such symbol '$!x' [...]
>  should that work?
>  moritz: my first thought is "I don't see why it shouldn't".
>  masak: my first thought was "rakudobug"
> * masak submits rakudobug

[perl #121166] [BUG] LTA error message when assigning to lexical variables from inside a regex in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still reproducible (2017.11,HEAD(e5b660e)), almost identical error message.

On 2014-02-04 08:01:17, masak wrote:
>  m: my $x; 'abc' ~~ /$x=(ab)/; say $x
>  rakudo-moar 44ab3c: OUTPUT«===SORRY!===␤Error while
> compiling op bind: QAST::Block with cuid cuid_1_1391529188.76986 has
> not appeared␤»
>  std: my $x; 'abc' ~~ /$x=(ab)/; say $x
>  std 09dda5b: OUTPUT«ok 00:01 127m␤»
>  n: my $x; 'abc' ~~ /$x=(ab)/; say $x
>  niecza v24-109-g48a8de3: OUTPUT«===SORRY!===␤␤Non-Match
> bindings NYI at /tmp/2rh2e31Bkj line 1:␤--> my $x; 'abc' ~~
> /$x=(ab)⏏/; say $x␤␤Unhandled exception: Check failed [...]
>  r: my $x; 'abc' ~~ /$x=(ab)/; say $x
>  rakudo-moar 44ab3c: OUTPUT«===SORRY!===␤Error while
> compiling op bind: QAST::Block with cuid cuid_1_1391529311.00125 has
> not appeared␤»
>  ..rakudo-jvm 44ab3c: OUTPUT«===SORRY!===␤setcodeobj can only
> be used with a CodeRef␤»
>  ..rakudo-parrot 44ab3c: OUTPUT«===SORRY!===␤Could not find
> sub cuid_1_1391529308.45272␤»
>  time for a LTA rakudobug?
>  well, I believe it's specced to Just Work
>
> Ok, so this ticket basically has two goals:
>
> * To make the error message not LTA
> * To make the feature Just Work

[perl #117421] [BUG] Typing with ::SomeClass instead of SomeClass in 'has' declaration causes the wrong type object to end up in that attribute in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still reproducible (2017.11,HEAD(e5b660e))

On 2013-03-30 16:55:04, masak wrote:
>  r: class A { has ::B $.b }; class B {}; print B.new; print
> A.new.b.new
>  rakudo ba5e04: OUTPUT«B<-905822265>No such method 'new' for
> invocant of type 'B'␤ in block at /tmp/TluLYMLqwz:1␤␤»
>  masak: ^^ hmm
>  that looks wrong.
>  looks like it's retaining the stub, and not replacing it with
> the real B.
> * masak submits rakudobug
>  r: class B {}; class A { has B $.b }; print B.new; print
> A.new.b.new
>  rakudo ba5e04: OUTPUT«B<1785303324>B<1791592750>»
>  r: class B {}; class A { has ::B $.b }; print B.new; print
> A.new.b.new
>  rakudo ba5e04: OUTPUT«B<-931868390>No such method 'new' for
> invocant of type 'B'␤ in block at /tmp/ovh8hRY1hT:1␤␤»
>  interesting.
>  so it has nothing to do with forward references. only with ::

[perl #123507] Can't stat modules/debugger-ui-commandline/lib: No such file or directory

[Aleks-Daniel Jakimenko-Aleksejev via RT]

This is very old and nobody was complaining about this issue since then. I
guess the problem is no longer there, but we won't be able to track it.
Therefore, rejected (but I'm hoping that the underlying issue was actually
resolved).

On 2014-12-26 23:16:35, ga...@szabgab.com wrote:
> During the "make install" phase of Rakudo Start 2014.12.1 (but I think
> this is not new)
> I saw this message:
>
>
> Can't stat modules/debugger-ui-commandline/lib: No such file or directory
>
> at tools/build/module-install.pl line 24.

[perl #124226] [BUG] Opportunity to catch syntactically detectable calls to attribute-accessing methods on type objects in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still reproducible (2017.11,HEAD(e5b660e))

On 2015-04-01 13:19:33, masak wrote:
> <[Tux]> m: class C { has Int $!x; method foo { ($!x, my $b) =
> (1,2);}};C.foo
> 19:45 <+camelia> rakudo-moar 6caf1d: OUTPUT«Cannot look up attributes
> in a type object␤ in method foo [...]
> <[Tux]> is that explainable?
>  you're calling C.foo, the .foo method on the type object C
>  the type object doesn't really properly have an $!x
>  m: class C { has Int $!x; method foo { ($!x, my $b) =
> (1,2);}}; C.new.foo
>  rakudo-moar 6caf1d: ( no output )
>  that works.
>  "Cannot look up attributes in a type object" is an
> implementor-centric error message, not a user-centric one
>  TimToady: "Instance attribute used in non-instance method
> call"? :)
>  TimToady: actually, that error message could fail statically
> in this case.
>  since C is already resolved at compile time.
>  no need to make it survive until runtime and then fail.
> [...]
>  no-one else liked the idea of statically erroring out with
> "call will never work" for the C.foo case where C is already
> statically resolved?
>  masak: I do
>  masak: Could work, but can't methods be marked as instance-
> only?
>  masak: the earlier errors are reported the better
>  masak: How does the compiler decide that it will never work?
> and when?
>  Because then, any use of $!foo could simply mark the method as
> instance-only
>  And the error message could be simpler.
>  "Method foo can only be called on an instance of C, not on C
> itself."
>  (compiler hints)++ if we can reasonably have them.
>  I guess, if you declare the sig right, all the info is easy
> to get at. But without that, it seems like a bit of guessing for the
> compiler to do it.
>  PerlJam: compiler sees the call C.foo, and has already set a
> flag that the foo method in class C accesses an attribute. boom.
> * masak submits rakudobug
>  "Method foo can only be called on an instance of C, not on C
> itself, because C.foo accesses instance attribute $!x."
>  neat. +1
>  masak: flagging methods like that seems like quite a bit of
> bookkeeping for marginal benefit.
>  really? seems worth it to me...
>  it's a small hash somewhere in the compiler.
>  %accattr = True;
>  It could be a boolean flag (instance-only) and an array of
> further explanations
> <[Coke]> masak: I think you mean a compile-time static check, not a
> static static check. ;)
>  [Coke]: yes. thank you. I meant... that, what you said.

[perl #125343] [WEIRD] Using an earliest { ... wait 0 { ... } } causes

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Alright.

On 2017-12-03 00:53:04, elizabeth wrote:
> Those are predecessors of the “react / whenever” syntax. I think that
> therefore this ticket can be closed now.
>
> > On 3 Dec 2017, at 04:58, Aleks-Daniel Jakimenko-Aleksejev via RT
> > <perl6-bugs-follo...@perl.org> wrote:
> >
> > what is `earliest`, `more` and `wait`?
> >
> > On 2015-06-06 16:40:28, r...@hoelz.ro wrote:
> >> The attached script reproduces the issue.
> >>
> >> When I use earliest with a wait 0 block, I get the following error
> >> message:
> >>
> >> No exception handler located for last_label
> >>
> >> Interestingly enough, if I increase 0 to some arbitrary timeout,
> >> this
> >> affects the bug; I've found if I keep it below 220ms, it triggers
> >> the
> >> bug. Going higher fixes the problem.

[perl #124832] Roast rakudo skip/todo test:./S12-enums/basic.t line:24 reason: 'Cannot convert string to number'

[Aleks-Daniel Jakimenko-Aleksejev via RT]

This ticket is replaced with https://github.com/rakudo/rakudo/issues/1296

[perl #122289] [BUG] unexpected behaviour during EVAL()

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Hmmm… Parrot is in the past as of today, and I wish it was possible to try this
on MoarVM. What's the way to reproduce this issue?

On 2014-07-14 02:31:54, teodozjan wrote:
> Evaling objects won't work if code that eval was preompiled
> independently. In this case class Planet and Class SpaceStation are
> somewhat inaccesible in imported sub. Even though putting slurp $path
> as argument of eval will fail. It was working on parrot but before big
> changes that made parrot backend unusable (random issues) in my
> project.
>
> =begin pod
> #FAILS on MOAR
> @planets = from_file($path_planets);
> #the same as below
> # https://github.com/teodozjan/perl-
> store/blob/master/lib/PerlStore/FileStore.pm
> @stations = from_file($path_stations);
>
> =end pod
>
>
> #moar hack
> note 'Readin $path_planets';
> my $plan = slurp $path_planets;
> @planets = EVAL $plan;
>
> #moar hack
> note 'Readin $path_stations';
> my $stat = slurp $path_stations;
> @stations = EVAL $stat;
>
>
>
> >>> LOADING /home/kamil/dev/lacuna-cookbuk/bin/lacunacookbuk_client
> + /home/kamil/dev/lacuna-cookbuk/bin/lacunacookbuk_client (12 - 16)
> | multi sub MAIN(:$tasks!, Bool :$update?){
> |
> | my Client $client .= new;
> |
> | create_session;
> > r
> >>> LOADING EVAL_0
> >>> LOADING EVAL_1
> >>> LOADING EVAL_2
> + Uncaught Exception
> | Cannot invoke this object (REPR: Null, cs = 0)
> + /home/kamil/dev/lacuna-cookbuk/bin/lacunacookbuk_client (23 - 27)
> | BodyBuilder.process_all_bodies;
> | } else {
> | BodyBuilder.read;
> | }
> | for @todo -> $willdo {
> > q
> - Run END blocks (y/N)?
>
> $ perl6 --version
> This is perl6 version 2014.06-118-gb25b868 built on MoarVM version
> 2014.06-63-g0fb638b

[perl #124150] [BUG] Match.caps is inconsistent across backends

[Aleks-Daniel Jakimenko-Aleksejev via RT]

As of today (2017.11,HEAD(e5b660e)) it prints a *third* variant:

(ident => ｢a｣ alpha => ｢a｣ alnum => ｢a｣)

The change happened in (2017-02-22)
https://github.com/rakudo/rakudo/commit/1cafc67b1aad14eafa8d3e6431656524e4d0d5d3

To me it tells that it is just random.


On 2015-03-22 13:02:12, pesc...@gmail.com wrote:
> 19:57  j: say ("a" ~~ / &  & /).caps
> 19:57  rakudo-jvm 5778e8: OUTPUT«ident => ｢a｣ alnum => ｢a｣
> alpha => ｢a｣␤»
> 19:57  m: say ("a" ~~ / &  & /).caps
> 19:57  rakudo-moar 5778e8: OUTPUT«alpha => ｢a｣ ident => ｢a｣
> alnum => ｢a｣␤»
>
> I'm not sure what the correct result would be. S05 mentions that there
> should be a warning with overlapping bindings. Additionally, sorting
> of captures is supposed to be by the sub-Matches .from, but it's not
> clarified what happens to elements with the value for .from. In any
> case, the current behavior makes at least a few tests S05-
> capture/caps.t underspecific, e.g.
>
> not ok 36 - .caps & - multiple terms# TODO & caps on jvm
> use of uninitialized value of type Any in string context in sub
> proclaim at lib/Test.pm:466
>
>
> # Failed test '.caps & - multiple terms'
> # at lib/Test.pm line
> # expected: 'alpha:a|ident:a'
> # got: 'ident:a|alpha:a'

[perl #124341] Proxy object also works on non- "is rw" subs/methods

[Aleks-Daniel Jakimenko-Aleksejev via RT]

What is this thing about? Was there a code snippet that got lost?

On 2015-04-18 10:16:32, elizabeth wrote:
> [19:13:51]  if nothing else it showed that a Proxy leaks
> through a not-is-rw method
> [19:13:55] _mg_ (~anonymous@95.88.244.237) left IRC. (Client
> Quit)
> [19:13:57]  Yes, that's a bug.
> [19:14:50]  well, not any more
> [19:15:15]  lizmat: No, there's still a Rakudo bug that
> your work uncovered that needs fixing independent of what happens with
> .elems.

[perl #125732] Subsignatures of a capture param not used to sort MMD candidates

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still reproducible (2017.11,HEAD(e5b660e))

On 2015-07-31 19:09:17, b...@abrij.org wrote:
>
> # The following should all have the same result:
>
> $ perl6 -e 'multi a ($x) { 41.say }; multi a (@a) { 42.say; nextsame
> }; a([1,2]);'
> 42
> 41
> $ perl6 -e 'multi a (|c($x)) { 41.say }; multi a (|c(@a)) { 42.say;
> nextsame }; a([1,2]);'
> 41
>
>
> $ perl6 -e 'multi a ($a) { 41.say }; multi a (Int $a) { 42.say;
> nextsame }; a(3);'
> 42
> 41
> $ perl6 -e 'multi a (|c($a)) { 41.say }; multi a (|c(Int $a)) {
> 42.say; nextsame }; a(3);'
> 41
>
> ...actual binding failures will make such MMDs work, only preferential
> binding
> is not working.
>
> Tests are already in the new S06-multi/signature.t file (but it needs
> to be added to spectest.data.) I'll label them once I have an RT #
> for them,

[perl #125168] [NYI] a way to open files in "r+" mode in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Isn't it implemented as :update now? https://docs.perl6.org/routine/open

Or maybe you can even use :mode? (the documentation says that it will make
the universe implode, but perhaps it's worth a try?)

On 2015-05-13 02:11:06, masak wrote:
>  so, how do I open a file in update mode (fopen "r+", perl5 open
> "+<")?
>  cygx: what's missing that you need? preferably expressed as a
> call to open()
>  I need to do an fopen("file", "r+")
>  preferably witout going through nativecall ;)
> * masak submits rakudobug

[perl #126111] [BUG] coercive type constraint for variable inconsistently accepted

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still reproducible (2017.11,HEAD(e5b660e))

On 2015-09-19 11:15:43, zef...@fysh.org wrote:
> A coercive type constraint is not permitted on a variable:
>
> $ ./perl6 -e 'my Int() $a; say 1'
> ===SORRY!=== Error while compiling -e
> Coercion Int(Any) is insufficiently type-like to qualify a variable
> at -e:1
> --> my Int() $a^; say 1
> expecting any of:
> constraint
>
> But it *is* accepted if expressed in "of" form:
>
> $ ./perl6 -e 'my $a of Int(); say 1'
> 1
>
> But it doesn't actually work:
>
> $ ./perl6 -e 'my $a of Int(); $a = 3; say $a'
> Type check failed in assignment to '$a'; expected 'Int(Any)' but got 'Int'
> in block  at -e:1
>
> Presumably it should be forbidden in the "of" form just as it is forbidden
> in the prefix form.
>
> -zefram

[perl #125934] [BUG] &?ROUTINE changes to something else in gather in for loop

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still reproducible (2017.11,HEAD(e5b660e))

On 2015-08-28 10:05:31, FROGGS.de wrote:
> m: sub foo { say &?ROUTINE.perl; gather for 1 { say &?ROUTINE.perl; };
> gather for 1 { say &?ROUTINE.perl; } }; foo
> rakudo-moar 5fb81f: OUTPUT«sub foo () { #`(Sub|59748232) ...
> }␤Code.new␤Code.new␤»
> rakudo-moar 186223: OUTPUT«sub foo () { #`(Sub|53058688) ...
> }␤Code.new␤Code.new␤»
>
> m: sub foo { say &?ROUTINE.perl; for 1 { say &?ROUTINE.perl; }; gather
> for 1 { say &?ROUTINE.perl; } }; foo
> rakudo-moar 5fb81f: OUTPUT«sub foo () { #`(Sub|42434376) ... }␤sub foo
> () { #`(Sub|42434376) ... }␤Code.new␤»
> rakudo-moar 186223: OUTPUT«sub foo () { #`(Sub|54308288) ... }␤sub foo
> () { #`(Sub|54308288) ... }␤Code.new␤»
>
> m: sub foo($,$,$) { say &?ROUTINE.arity; for 1 { say &?ROUTINE.arity; };
> gather for 1 { say &?ROUTINE.arity; } }; foo 1, 2, 3
> rakudo-moar 5fb81f: OUTPUT«3␤3␤0␤»
> rakudo-moar 186223: OUTPUT«3␤3␤0␤»
>
> m: sub foo($,$,$) { say &?ROUTINE.arity; for 1 { say &?ROUTINE.arity; };
> gather for 1 { if 1 { say &?ROUTINE.arity } } }; foo 1, 2, 3
> rakudo-moar 5fb81f: OUTPUT«3␤3␤3␤»
> rakudo-moar 186223: OUTPUT«3␤3␤3␤»
>
> I expect that the &?ROUTINE in the gather also points to the foo subroutine.