[perl #127536] [BUG] UNIT:: dies horribly if used at compile time

[Jan-Olof Hendig via RT]

On Thu, 21 Jul 2016 19:43:35 -0700, c...@zoffix.com wrote:
> Still present in Rakudo version 2016.07.1-28-gd789da1 built on MoarVM
> version 2016.07-3-gc01472d
> 
> Interestingly, this doesn't happen on camelia running the same commit.
> 
> zoffix@VirtualBox:~/CPANPRC/rakudo$ ./perl6-m -e 'BEGIN { UNIT; Nil }'
> ===SORRY!=== Error while compiling -e
> An exception occurred while evaluating a BEGIN
> at -e:1
> Exception details:
> ===SORRY!=== Error while compiling
> ctxlexpad needs an MVMContext
> at :

Fixed with commit 
https://github.com/rakudo/rakudo/commit/1c7d15d73d6e06ab0e2660f64436ab447e90c581

testneeded

[perl #126945] [BUG] outer frame does not match expected static frame

[Jan-Olof Hendig via RT]

On Thu, 17 Dec 2015 03:37:17 -0800, lloyd.fo...@gmail.com wrote:
> should have mentioned:
> 
> When invoking cuid_1_1450351791.17598 '', provided outer frame
> 0x7fbeb3c409b0 (cuid_3_1450351791.17598 '') does not match expected
> static frame 0x7fbeb3c40ad0 (cuid_2_1450351791.17598 '')
>   in block  at -e:1
> 
> and that if you replace the () with 'do' it doesn't happen.
> 
> On Thu, Dec 17, 2015 at 10:35 PM perl6 via RT 
> wrote:
> 
> > Greetings,
> >
> > This message has been automatically generated in response to the
> > creation of a trouble ticket regarding:
> > "outer frame does not match expected static frame",
> > 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 #126945].
> >
> > Please include the string:
> >
> >  [perl #126945]
> >
> > 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
> >
> > -
> > perl6 -e '{ berp => "lerp", ( with "herp" { $_ => "derp" } ) }'
> >
> > This is Rakudo version 2015.11-593-g33ac495 built on MoarVM version
> > 2015.11-55-g49f10b9 implementing Perl 6.b.
> >
> >

Fixed with commit 
https://github.com/rakudo/rakudo/commit/31c8fda2878d091f54247f034fba3f63b0942e75

testneeded

[perl #130444] [REGRESSION] Hash value constraints are no longer working (Hash[Int].new(‘abc’ => 20..50))

[Jan-Olof Hendig via RT]

On Mon, 13 May 2019 10:28:25 -0700, jan-olof.hen...@bredband.net wrote:
> On Thu, 29 Dec 2016 13:26:17 -0800, alex.jakime...@gmail.com wrote:
> > Code:
> > say Hash[Int].new(‘abc’ => 20..50)
> >
> >
> > Result (2015.12):
> > Type check failed in binding $x; expected Int but got Range
> >   in block  at /tmp/CRJOhWZaTS line 1
> >  «exit code = 1»
> >
> >
> > Result (HEAD):
> > {abc => 20..50}
> >
> >
> > It should complain that it got a Range instead of an Int.
> >
> > Bisectable points to
> > https://github.com/rakudo/rakudo/commit/b2e57f697fad1617951561ff928e6d981b323386
> 
> Fixed with commit
> https://github.com/rakudo/rakudo/commit/9acbf000418cd716f532008a5a1704cccf684eae
> 
> testneeded

Turns out that this issue is the same as R#2348 which was fixed we the above 
commit.
Tests were added to roast with https://github.com/perl6/roast/commit/28301d7c5d

closing

[perl #130444] [REGRESSION] Hash value constraints are no longer working (Hash[Int].new(‘abc’ => 20..50))

[Jan-Olof Hendig via RT]

On Thu, 29 Dec 2016 13:26:17 -0800, alex.jakime...@gmail.com wrote:
> Code:
> say Hash[Int].new(‘abc’ => 20..50)
> 
> 
> Result (2015.12):
> Type check failed in binding $x; expected Int but got Range
>   in block  at /tmp/CRJOhWZaTS line 1
>  «exit code = 1»
> 
> 
> Result (HEAD):
> {abc => 20..50}
> 
> 
> It should complain that it got a Range instead of an Int.
> 
> Bisectable points to
> https://github.com/rakudo/rakudo/commit/b2e57f697fad1617951561ff928e6d981b323386

Fixed with commit 
https://github.com/rakudo/rakudo/commit/9acbf000418cd716f532008a5a1704cccf684eae

testneeded

[perl #131089] Different parsing of combined colonpairs

[Jan-Olof Hendig via RT]

On Sun, 02 Apr 2017 07:48:11 -0700, alex.jakime...@gmail.com wrote:
> I wonder, is it a dup of RT #124553 and RT #125353 ?
> 
> On 2017-04-02 04:50:15, c...@zoffix.com wrote:
> > If joined colonpairs are after a position arg, only the first
> > colonpair gets registered:
> >
> >  m: -> *@_, *%_ { dd [@_, %_] }("/", :r:w:d:x)
> >  rakudo-moar 1b9d53: OUTPUT: «[["/"], {:r}]␤»
> >
> > But if they're first in line, then all do:
> >
> >  m: -> *@_, *%_ { dd [@_, %_] }(:r:w:d:x, "/")
> >  rakudo-moar 1b9d53: OUTPUT: «[["/"], {:d, :r, :w, :x}]␤»
> >
> > When in a [], only first one is obtained as well:
> >  m: dd [:r:w:d:x]
> >  rakudo-moar 1b9d53: OUTPUT: «[:r]␤»
> >
> > And when in a {}, all are obtained, but only the first one gets value
> > True (related?)
> >  m: dd {:r:w:d:x}
> >  rakudo-moar 1b9d53: OUTPUT: «Hash % = {:d(1), :r, :w(1),
> > :x(1)}␤»

The examples given by Zoffix above seems to have been fixed by 
https://github.com/rakudo/rakudo/commit/91359141fb7501636b073ccaf6fb6598dc273bec

[perl #130069] [BUG] Unknown QAST error when creating List of Pairs

[Jan-Olof Hendig via RT]

On Thu, 04 May 2017 17:36:32 -0700, c...@zoffix.com wrote:
> On Thu, 10 Nov 2016 21:03:43 -0800, joshu...@gmail.com wrote:
> > Normally Rakudo is happy for you to omit comma when declaring pairs
> > with
> > the `:key(value)` syntax, however I found that it does not like this
> > syntax
> > is Rat's are used as the value, like this:
> >
> > > (:this(3.5) :that(5.3))
> > Unknown QAST node type NQPMu
> >
> 
> I took a stab at this one, but giving up for now.
> 
> Things discovered:
> - It's the second `:that(5.3)` that is the thing causing the issue
> - To repro the issue, instead of a Rat you can use a constant, e.g.
> `:that(pi)`
> - ASTs:
> - Working version has: QAST::WVal(Rat)  :statement_id
> 5.3
> - Broken version has: QAST::Want  (looks like it's missing
> stuff inside of it, which is what gives the error)
> - --target=parse:
> - Working version has EXPR => - 0: colonpair: (first)  - 1:
> colonpair: (second)
> - Broken version has EXPR => - 0: colonpair: (first)  -
> fake_infix:   - OPER:   - colonpair: (second)
> 
> So looks like the Actions for `statement` token needs to rake through
> `fake_infix` capture and generate proper colonpair instead of empty
> QAST::Want.
> 
> I gave up at that point, but hopefully my digging will be helpful to
> someone :)

Fixed with commit 
https://github.com/rakudo/rakudo/commit/91359141fb7501636b073ccaf6fb6598dc273bec

testneeded

[perl #130572] Parenthesized `for` loop is eager, even with `lazy` keyword

[Jan-Olof Hendig via RT]

On Sun, 12 May 2019 07:36:16 -0700, jan-olof.hen...@bredband.net wrote:
> On Sat, 26 Aug 2017 05:15:41 -0700, sml...@gmail.com wrote:
> > This bug is still present in
> >
> > Rakudo version 2017.08-8-g753c9a5ea built on MoarVM version
> > 2017.08.1-
> > 19-g151a2563
> > implementing Perl 6.c
> 
> As per commit
> https://github.com/rakudo/rakudo/commit/cf1673d9c20e82aad6291a8aa123c46e177edf34
> the second case now works as intended.

As for the first case, see 
https://colabti.org/irclogger/irclogger_log/perl6-dev?date=2019-05-12#l48

should be set to testneeded

[perl #130572] Parenthesized `for` loop is eager, even with `lazy` keyword

[Jan-Olof Hendig via RT]

On Sat, 26 Aug 2017 05:15:41 -0700, sml...@gmail.com wrote:
> This bug is still present in
> 
> Rakudo version 2017.08-8-g753c9a5ea built on MoarVM version 2017.08.1-
> 19-g151a2563
> implementing Perl 6.c

As per commit 
https://github.com/rakudo/rakudo/commit/cf1673d9c20e82aad6291a8aa123c46e177edf34
the second case now works as intended.

[perl #131395] [BUG] Cross meta operator on empty list complains "This type (Scalar) does not support elems"

[Jan-Olof Hendig via RT]

On Sat, 30 Sep 2017 12:40:59 -0700, sml...@gmail.com wrote:
> On Mon, 29 May 2017 11:36:49 -0700, c...@zoffix.com wrote:
> > On Mon, 29 May 2017 10:02:27 -0700, thunderg...@comcast.net wrote:
> > > Using a cross meta operator on an empty list complains "This type
> > > (Scalar) does not support elems".
> > >
> > > say (1,2).elems; say ().elems; say (1,2) X ();
> > >
> > > yields "2␤0␤This type (Scalar) does not support elems"
> > >
> > > Seems to work correctly with arrays instead of lists.
> > >
> > > say [1,2].elems; say [].elems; say [1,2] X [];
> > >
> > >
> > > Linux Mint 17.2
> > >
> > >  > perl6 -v
> > >  >  This is Rakudo version 2017.05 built on MoarVM version 2017.05
> > > implementing Perl 6.c.
> >
> >
> > Thank you for the report. lizmat++ fixed the issue.
> >
> > Fix: https://github.com/rakudo/rakudo/commit/9494cbd3b9
> > Test: https://github.com/perl6/roast/commit/0faf3c354f
> 
> Re-opening, because it hasn't been fixed for the Xop case yet:
> 
> ➜  say () X+ (1, 2);
> This type (Scalar) does not support elems
> 
> ➜  say (1,2) X~ ();
> This type (Scalar) does not support elems
> 
> ➜  say () X=> ();
> This type (Scalar) does not support elems
> 
> Bisectable¹ blames a commit² from January.
> 
> 
> ---
> [1]
> https://gist.github.com/Whateverable/f1b3066f1e2c45df7ab5e0aa7aeee3a7
> [2] https://github.com/rakudo/rakudo/commit/a26f51361
> 
> ---
> This is Rakudo version 2017.09-142-ga89add0bf built on MoarVM version
> 2017.09.1-49-gb3dd812a
> implementing Perl 6.c.

Fixed with commit 
https://github.com/rakudo/rakudo/commit/6c93fde85da027748bddd7cf75e295ed70ce3b05
Roast tests added with 
https://github.com/perl6/roast/commit/7d47580eb83fbf7c315e21411422fbc547f96399

Closing

[perl #132585] [REGRESSION] nested parameterized type names are truncated

[Jan-Olof Hendig via RT]

On Fri, 15 Dec 2017 01:18:46 -0800, d...@zwell.net wrote:
> The output of a hash of hashes of ints looks my Hash[Int] %nested-
> type;
> %nested-type.WHAT.say; # output: (Hash[Hash)
> 
> The type should be shown as: (Hash[Hash[Int]])
> 
> AlexDaniel did a bisect and found this was caused by:
> https://github.com/rakudo/rakudo/commit/1ed284e2953382744b02058a2ec548658d744786

Fixed with commit 
https://github.com/rakudo/rakudo/commit/ce08683fbf7dac2a1a37bf50fe336819f946c0c0
The above commit fixed the duplicate bug R#1606 to which tests where added in 
S02-names-vars/names.t

Closing

[perl #128047] [IO] Rakudo may crash if you use get() when -n is used (perl6 -ne 'say get' <<< 'hello')

[Jan-Olof Hendig via RT]

On Tue, 21 Feb 2017 11:05:15 -0800, c...@zoffix.com wrote:
> On Sun, 01 May 2016 04:12:34 -0700, alex.jakime...@gmail.com wrote:
> > This bug report is somewhat related to
> > https://rt.perl.org/Ticket/Display.html?id=128046
> >
> > get() crashes with a weird error if the stream has ended.
> >
> > Command:
> > perl6 -ne 'get' <<< $'hello\nworld\ntest'
> >
> > Result:
> > world
> > Nil
> > readline requires an object with REPR MVMOSHandle
> >   in block  at -e line 1
> >
> > But it works if the number of lines is even.
> >
> > Command:
> > perl6 -ne 'get' <<< $'hello\nworld'
> >
> > Result:
> > world
> >
> >
> > It should not crash.
> 
> lines() appears to have a similar affliction, though I don't see any
> difference if the number of lines is even.
> 
> $ cat foo.txt
> a
> b
> c
> 
> $ perl6 -ne '@ = lines' foo.txt
> readline requires an object with REPR MVMOSHandle
> in block  at -e line 1
> 
> 
> $ perl6 -ne 'lines.eager' foo.txt
> readline requires an object with REPR MVMOSHandle
> in block  at -e line 1
> 
> 

Behavior has changed, the examples above now fail with:

Cannot do 'get' on a handle in binary mode

[perl #131813] Segfault with --profile

[Jan-Olof Hendig via RT]

On Sun, 04 Feb 2018 02:40:44 -0800, alex.jakime...@gmail.com wrote:
> 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 $


Tested by Lizmat on OS X, see 
https://colabti.org/irclogger/irclogger_log/perl6-dev?date=2019-05-11#l61

[perl #129197] [BUG][IO] "Invalid free()" when passing the output of one Proc to the input of another

[Jan-Olof Hendig via RT]

On Sun, 04 Sep 2016 11:35:06 -0700, ddgr...@gmail.com wrote:
> When running the below code, using a moar built with --debug
> valgrind --trace-children=yes ~/Source/perl6/install/bin/perl6 -e 'for
> ^1000 { my $proc = run(:out, :bin, ‘tar’, ‘cf’, ‘-’, ‘--absolute-
> names’, ‘--’, "417d97ddcffcb4404aba396509bd06d0cf81f013-texas"); say
> "$_: created tar"; run(:in($proc.out), :bin, ‘lzop’, ‘-f’, ‘-q’, "-o",
> "4-texas.lzop"); say "$_: ran lzop"; }'
> 
> ==29941== Invalid free() / delete / delete[] / realloc()
> ==29941==at 0x4C2AD90: free (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==29941==by 0x4FC6C43: MVM_free (alloc.h:29)
> ==29941==by 0x4FC6C43: do_close (syncpipe.c:37)
> ==29941==by 0x4FC6C43: closefh (syncpipe.c:52)
> ==29941==by 0x4FC388A: MVM_io_close (io.c:28)
> ==29941==by 0x4F8F2E0: MVM_interp_run (interp.c:4361)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
> ==29941==  Address 0xffefffd40 is on thread 1's stack
>  ==29941==
> ==29941== Conditional jump or move depends on uninitialised value(s)
> ==29941==at 0x4FB7B58: MVM_intcache_get (intcache.c:40)
> ==29941==by 0x4F85C65: MVM_args_slurpy_positional (args.c:574)
> ==29941==by 0x4F9B6DB: MVM_interp_run (interp.c:1046)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
>  ==29941==
> ==29941== Conditional jump or move depends on uninitialised value(s)
> ==29941==at 0x4FEB3C0: set_int (P6bigint.c:73)
> ==29941==by 0x4F85E31: MVM_args_slurpy_positional (args.c:574)
> ==29941==by 0x4F9B6DB: MVM_interp_run (interp.c:1046)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
>  ==29941==
> ==29941== Conditional jump or move depends on uninitialised value(s)
> ==29941==at 0x4FB7B58: MVM_intcache_get (intcache.c:40)
> ==29941==by 0x4F842C8: MVM_args_get_pos_obj (args.c:297)
> ==29941==by 0x4F913C3: MVM_interp_run (interp.c:917)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
>  ==29941==
> ==29941== Conditional jump or move depends on uninitialised value(s)
> ==29941==at 0x4FEB3C0: set_int (P6bigint.c:73)
> ==29941==by 0x4F8434C: MVM_args_get_pos_obj (args.c:297)
> ==29941==by 0x4F913C3: MVM_interp_run (interp.c:917)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
>  ==29941==
> ==29941== Conditional jump or move depends on uninitialised value(s)
> ==29941==at 0x5048E0C: MVM_bigint_cmp (bigintops.c:479)
> ==29941==by 0x4F94259: MVM_interp_run (interp.c:3275)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
>  ==29941==
> ==29941== Conditional jump or move depends on uninitialised value(s)
> ==29941==at 0x4F94EDE: MVM_interp_run (interp.c:2858)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
>  ==29941==
> ==29941== Use of uninitialised value of size 8
> ==29941==at 0x4F94EE4: MVM_interp_run (interp.c:2858)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
>  ==29941==
> ==29941== Use of uninitialised value of size 8
> ==29941==at 0x4F94EEE: MVM_interp_run (interp.c:2858)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
>  ==29941==
> ==29941== Conditional jump or move depends on uninitialised value(s)
> ==29941==at 0x4FAEA0A: MVM_is_null (MVMNull.h:11)
> ==29941==by 0x4FAEA0A: MVM_coerce_istrue (coerce.c:31)
> ==29941==by 0x4F9BCF0: MVM_interp_run (interp.c:242)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
>  ==29941==
> ==29941== Conditional jump or move depends on uninitialised value(s)
> ==29941==at 0x4FAEA1D: MVM_is_null (MVMNull.h:11)
> ==29941==by 0x4FAEA1D: MVM_coerce_istrue (coerce.c:31)
> ==29941==by 0x4F9BCF0: MVM_interp_run (interp.c:242)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
>  ==29941==
> ==29941== Use of uninitialised value of size 8
> ==29941==at 0x4FAEA1F: MVM_coerce_istrue (coerce.c:32)
> ==29941==by 0x4F9BCF0: MVM_interp_run (interp.c:242)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
>  ==29941==
> ==29941== Use of uninitialised value of size 8
> ==29941==at 0x4FAEBB2: MVM_coerce_istrue (coerce.c:65)
> ==29941==by 0x4F9BCF0: MVM_interp_run (interp.c:242)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
>  ==29941==
> ==29941== Use of uninitialised value of size 8
> ==29941==at 0x4FDFAE0: MVM_p6opaque_real_data (P6opaque.h:108)
> ==29941==by 0x4FDFAE0: get_int 

[perl #125908] [BUG] duplicate triggers of .act when using parallel greps on an IO::Notification.watch_path supply

[Jan-Olof Hendig via RT]

On Tue, 03 Nov 2015 08:54:16 -0800, root+bitc...@retupmoca.com wrote:
> On Wed Aug 26 08:19:35 2015, mura...@pair.com wrote:
> > When two greps are used in parallel on one supply produced by
> > IO::Notification.watch_path, greps that match are triggered twice.
> > Run
> > the following code, then in the same directory `touch watchfile`.
> > Note
> > that I'm also using unique to filter things, as touching a file
> > produces
> > a number of FileChanged events.
> >
> > my $paths = IO::Notification.watch_path('.')\
> >  .grep(*.event.isa(FileChangeEvent::FileChanged))\
> >  .unique(:as(*.path), :expires(5))\
> >  .map(*.path);
> >
> > my $watch = $paths.grep(* ~~ /watchfile/)\
> >  .act(-> $x {
> >  say "got file change: " ~ $x.perl;
> >  });
> >
> > my $never = $paths.grep(* ~~ /shouldneverexecute/)\
> >  .act(-> $x {
> >  say "should never execute: " ~ $x.perl;
> >  });
> >
> > sleep;
> >
> > Output:
> >
> > got file change: "watchfile"
> > got file change: "watchfile"
> >
> > The expected output should be only a single line, not two. I also
> > noticed that each additional grep I add to the supply yields an
> > additional line of the same output.
> >
> > I tried this with a plain supply and could not reproduce the problem:
> >
> > my $s = Supply.new();
> >
> > my $watch = $s.grep(* ~~ /1/)\
> >  .act(-> $x {
> >  say "got one";
> >  });
> >
> > my $never = $s.grep(* ~~ /shouldneverexecute/)\
> >  .act(-> $x {
> >  say "should never execute";
> >  });
> >
> > $s.emit(1);
> > $s.emit(2);
> >
> > sleep;
> >
> > This outputs "got one" a single time, as expected.
> >
> > Perl6 version info: 2015.07.1-161-gf7cfe9d built on MoarVM version
> > 2015.07-57-gec051f5
> 
> I think this is a bug in Supply.unique:
> 
> 22:38 retupmoca m: my $s = Supply.new; my $s2 =
> $s.unique(:as({$_}), :expires(5)); $s2.act({say $_}); $s.emit(1);
> $s2.act({ say $_ * 2}); $s.emit(2); # re: #125908
> 22:38 camelia   rakudo-moar 273e89: OUTPUT«1␤2␤4␤2␤4␤»
> 22:38 retupmoca looks like a bug in unique?

$ perl6 -v
This is Rakudo version 2018.06-24-gc441d8d built on MoarVM version 2018.06
implementing Perl 6.c.

tried the original code example and it now only produces one event, i.e.

got file change: "watchfile"

It was suspected that the real problem was a bug in Supply.unique, and the
given example seems to confirm that. However, a lot of water have flowed under
the bridges since then and it seems as if the problem in 'unique' has been 
fixed.

I tried the following:

perl6 -e 'my $x = Supplier.new; my $s = $x.Supply; my $s2 = 
$s.unique(:as({$_}), :expires(5)); $s2.act({say $_}); $x.emit(1); $s2.act({ say 
$_ * 2}); $x.emit(2);'
1
2
4

Had to rewrite the example since the api for supplies has changed since the
original bug report.

Should possibly be marked as TESTNEEDED

[perl #114276] [BUG] Cannot return junctions from .classify blocks in Rakudo

[Jan-Olof Hendig via RT]

On Tue, 20 Oct 2015 23:06:02 -0700, barto...@gmx.de wrote:
> Current failure mode:
> 
> $ perl6-m -e 'say (1, 2).classify: -> $x { 1|2 }'
> P6opaque: no such attribute '$!reified'
>   in block  at -e:1
> 
> $ perl6-m --version
> This is perl6 version 2015.09-431-g5d83db3 built on MoarVM version
> 2015.09-79-gee9fc2b

Things have changed yet again:

$ perl6-m -e 'say (1, 2).classify: -> $x { 1|2 }'
{1 => [1 2], 2 => [1 2]}

$ perl6-m -v
This is Rakudo version 2018.06-24-gc441d8d built on MoarVM version 2018.06
implementing Perl 6.c.

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

[Jan-Olof Hendig via RT]

On Thu, 12 Apr 2018 07:21:53 -0700, elizabeth wrote:
> Fixed with 344a64e987 , tests needed
> 
> > On 24 Mar 2018, at 15:01, Aleks-Daniel Jakimenko-Aleksejev via RT
> >  wrote:
> >
> > 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

Test added in Roast commit 
https://github.com/perl6/roast/commit/2288d4a3c543d72f822164dad529066ed055a0aa

[perl #129142] [BUG] Parse error when coercing an enum from a coercion of an enum from an int

[Jan-Olof Hendig via RT]

On Fri, 16 Mar 2018 16:02:15 -0700, jan-olof.hen...@bredband.net wrote:
> On Tue, 30 Aug 2016 16:30:24 -0700, allber...@gmail.com wrote:
> > I think the problem is that there's already another syntax using that
> > sequence: coercion types. FF(FF(2)) is being parsed as a coercion
> > type from
> > FF to FF(... and then it falls over because it's not expecting nested
> > coercion types.
> >
> > On Tue, Aug 30, 2016 at 7:13 PM, Brian S. Julin <
> > perl6-bugs-follo...@perl.org> wrote:
> >
> > > # New Ticket Created by  "Brian S. Julin"
> > > # Please include the string:  [perl #129142]
> > > # in the subject line of all future correspondence about this
> > > issue.
> > > # https://rt.perl.org/Ticket/Display.html?id=129142 >
> > >
> > >
> > >
> > >
> > > $ perl6 -e 'enum FF ; FF(2).perl.say'
> > > FF::two
> > > $ perl6 -e 'enum FF ; FF(FF::two).perl.say'
> > > FF::two
> > > $ perl6 -e 'enum FF ; FF(two).perl.say'
> > > FF::two
> > > $ perl6 -e 'enum FF ; FF(abs(-2)).perl.say'
> > > FF::two
> > > $ perl6 -e 'enum FF ; FF(FF(2)).perl.say'
> > > ===SORRY!=== Error while compiling -e
> > > Unable to parse expression in typename; couldn't find final ')'
> > > at -e:1
> > > --> enum FF ; FF(FF(⏏2)).perl.say
> > >
> > >
> > > # o.O
> > > $ perl6 -e 'enum FF ; enum GG  > > fum>;
> > > FF(foo).perl.say'
> > > FF
> > >
> > > $ perl6 -e 'enum FF ; enum GG  > > fum>;
> > > FF(GG(foo)).perl.say'
> > > FF(GG(GG))
> > >
> > > $ perl6 -e 'enum FF ; enum GG  > > fum>;
> > > FF(GG(2)).perl.say'
> > > ===SORRY!=== Error while compiling -e
> > > Unable to parse expression in typename; couldn't find final ')'
> > > at -e:1
> > > --> hree>; enum GG ; FF(GG(⏏2)).perl.say
> > >
> >
> >
> >
> 
> Fixed with commit
> https://github.com/rakudo/rakudo/commit/c76d9324a9f67e4075683e38a63a9788161c17cc

Test added with commit 
https://github.com/perl6/roast/commit/3b1e5fb4f10ffb1ef384616013d89d117cc98a31

[perl #130494] [CONC] [PERF] Using Proc::Async with tap leads to memory leak

[Jan-Olof Hendig via RT]

On Mon, 20 Feb 2017 06:39:32 -0800, ronaldxs wrote:
> jnthn mentioned on irc awareness of at least one more leak
> (presumably) related to this ticket and so ticket waits on news of
> fixing further leak(s).

Running the example above one a 32-bit Linux VM I get:

This Rakudo version is 2018.03.136.g.768.cf.9.f.29 built on MoarVM version 
2018.03.58.g.0.aaea.3.c.4.f,
running on ubuntu (14.04.3.LTS.Trusty.Tahr) / linux (3.19.0.32.generic)


pmap after 0 iterations
 total   119328K
pmap after 2 iterations
 total   127940K
pmap after 10 iterations
 total   129200K
pmap after 1000 iterations
 total   168160K
pmap after 2000 iterations
 total   174984K
pmap after 3000 iterations
 total   182564K
pmap after 4000 iterations
 total   183984K
pmap after 5000 iterations
 total   183984K
pmap after 6000 iterations
 total   186788K
pmap after 7000 iterations
 total   189404K
pmap after 8000 iterations
 total   199460K
pmap after 9000 iterations
 total   199460K
line 

So it looks as if things have improved considerably

[perl #128758] Reduce with numeric ops does not numify things if only one arg is passed ([*] set(1,2,3))

[Jan-Olof Hendig via RT]

On Sun, 25 Mar 2018 08:43:30 -0700, jan-olof.hen...@bredband.net wrote:
> On Thu, 29 Jun 2017 12:50:43 -0700, sml...@gmail.com wrote:
> > It looks like this bug hasn't been *completely* fixed:
> >
> > dd :<+>( "2" );   # 2
> > dd :<*>( "2" );   # 2
> >
> > dd [*] "2"; # 2
> > dd [+] "2"; # 2
> >
> > dd reduce :<*>, "2";  # 2
> > dd reduce :<+>, "2";  # "2"
> >
> > i.e. it doesn't work when using the + operator with the functional
> > form of reduce, even though it works with other numeric operators and
> > with the meta-operator form.
> 
> Last example fixed with commit (2018-01-13)
> https://github.com/rakudo/rakudo/commit/0af3f4d1c37dddb8c6362c2eafb74d849c5d9ded

Test added with commit 
https://github.com/perl6/roast/commit/6b0fcc2b91909361e7f0fd07df4d9f6002aa889d

[perl #128758] Reduce with numeric ops does not numify things if only one arg is passed ([*] set(1,2,3))

[Jan-Olof Hendig via RT]

On Thu, 29 Jun 2017 12:50:43 -0700, sml...@gmail.com wrote:
> It looks like this bug hasn't been *completely* fixed:
> 
> dd :<+>( "2" );   # 2
> dd :<*>( "2" );   # 2
> 
> dd [*] "2"; # 2
> dd [+] "2"; # 2
> 
> dd reduce :<*>, "2";  # 2
> dd reduce :<+>, "2";  # "2"
> 
> i.e. it doesn't work when using the + operator with the functional
> form of reduce, even though it works with other numeric operators and
> with the meta-operator form.

Last example fixed with commit (2018-01-13) 
https://github.com/rakudo/rakudo/commit/0af3f4d1c37dddb8c6362c2eafb74d849c5d9ded

[perl #127352] [BUG] Behavior of Regular Expressions Contained in a Constant with a Sigil

[Jan-Olof Hendig via RT]

On Tue, 13 Mar 2018 14:50:17 -0700, jan-olof.hen...@bredband.net wrote:
> On Fri, 05 Aug 2016 18:04:36 -0700, c...@zoffix.com wrote:
> > Still present today:
> >
> >  m: my $sepreg = rx/(<[\\/]>)/; my $filenameW =
> > "c:\\g\\b.mp4"; $filenameW ~~ $sepreg; say $/;
> >  rakudo-moar 589061: OUTPUT«｢\｣␤ 0 => ｢\｣␤»
> >  m: constant $sepreg = rx/(<[\\/]>)/; my $filenameW =
> > "c:\\g\\b.mp4"; $filenameW ~~ $sepreg; say $/;
> >  rakudo-moar 589061: OUTPUT«Nil␤»
> >  m: constant sepreg = rx/(<[\\/]>)/; my $filenameW =
> > "c:\\g\\b.mp4"; $filenameW ~~ sepreg; say $/;
> >  rakudo-moar 589061: OUTPUT«｢\｣␤ 0 => ｢\｣␤»
> 
> Fixed with commit
> https://github.com/rakudo/rakudo/commit/5ac593ee098f204ea69ef57edd9ae0925c544ea4

Roast test added with commit 
https://github.com/perl6/roast/commit/f2d422f229f50b14f47d803362c7af8e73b8c13b

[perl #128512] [BUG] utf8-c8 mangles by NFC

[Jan-Olof Hendig via RT]

On Wed, 14 Mar 2018 13:28:05 -0700, jan-olof.hen...@bredband.net wrote:
> On Sun, 26 Feb 2017 23:01:18 -0800, zef...@fysh.org wrote:
> > This problem no longer occurs.
> >
> > -zefram
> >
> 
> Fixed with commit (2017-01-02)
> https://github.com/rakudo/rakudo/commit/7c8b705b3375522fc36304b771f82f50246afcf0

Test added with commit 
https://github.com/perl6/roast/commit/d0d46093e51de3b21dcdc0634b2717740f921001

[perl #128511] [BUG] utf8-c8 generates spurious NUL

[Jan-Olof Hendig via RT]

On Wed, 14 Mar 2018 13:26:11 -0700, jan-olof.hen...@bredband.net wrote:
> On Sun, 26 Feb 2017 23:02:00 -0800, zef...@fysh.org wrote:
> > This problem no longer occurs.
> >
> > -zefram
> >
> 
> This was fixed with commit (2017-01-02)
> https://github.com/rakudo/rakudo/commit/7c8b705b3375522fc36304b771f82f50246afcf0

Tests added with commit 
https://github.com/perl6/roast/commit/d0d46093e51de3b21dcdc0634b2717740f921001

[perl #130980] Thunked xx not calling pull-one deep enough?

[Jan-Olof Hendig via RT]

On Sat, 11 Mar 2017 03:02:39 -0800, elizabeth wrote:
> $ 6 'my $a = 0; ($a++,) Zxx 42; say $a’
> 0
> 
> $ 6 'my $a = 0; ($a++,) Xxx 42; say $a’
> 0
> 
> Before https://github.com/rakudo/rakudo/commit/1754dc5f7e , this would
> have yielded 42 in both cases.  However, this was a side-effect (pun
> intended) of thunk xx 42 being eager internally.  Since this commit,
> it is no longer, and this case the inner thunk does not get called
> when in a sink context.
> 
> This *could* be a bug, but I’m not sure.  Since the commit made 4
> spectests that assume the old behaviour fail, it seemed wise to make a
> ticket before fudging the tests.
> 
> Please close this bug report if it’s not a bug, and remove/adapt the
> associated tests.

Tests unfudged with roast commit 6e56c434f46dbb67f5c

[perl #130483] [UNI] Regex Unicode properties check string values before checking bool properties

[Jan-Olof Hendig via RT]

On Wed, 04 Jan 2017 21:27:05 -0800, samant...@posteo.net wrote:
> Also see this bisectable results:
> https://gist.github.com/Whateverable/50acf5fe072680085746459f144a106f
> 
> You can see how with the new commit, 'space' and 'White_Space' now
> resolve to the same property. Before 'space' resolved to the LF
> property, and magically worked. When this was fixed and 'space' ==
> 'White_Space', it broke. This bug will be considered close when:
> 
> use nqp; say nqp::unipropcode('space') ==
> nqp::unipropcode('White_Space') #> True
> and also must work doing: `'  ' ~~ /<:space>/; #> ｢  ｣`

Fixed with commit 
https://github.com/rakudo/rakudo/commit/49dce163e8182ee726cd1e512a03c29551cc16da

[perl #129142] [BUG] Parse error when coercing an enum from a coercion of an enum from an int

[Jan-Olof Hendig via RT]

On Tue, 30 Aug 2016 16:30:24 -0700, allber...@gmail.com wrote:
> I think the problem is that there's already another syntax using that
> sequence: coercion types. FF(FF(2)) is being parsed as a coercion type from
> FF to FF(... and then it falls over because it's not expecting nested
> coercion types.
> 
> On Tue, Aug 30, 2016 at 7:13 PM, Brian S. Julin <
> perl6-bugs-follo...@perl.org> wrote:
> 
> > # New Ticket Created by  "Brian S. Julin"
> > # Please include the string:  [perl #129142]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=129142 >
> >
> >
> >
> >
> > $ perl6 -e 'enum FF ; FF(2).perl.say'
> > FF::two
> > $ perl6 -e 'enum FF ; FF(FF::two).perl.say'
> > FF::two
> > $ perl6 -e 'enum FF ; FF(two).perl.say'
> > FF::two
> > $ perl6 -e 'enum FF ; FF(abs(-2)).perl.say'
> > FF::two
> > $ perl6 -e 'enum FF ; FF(FF(2)).perl.say'
> > ===SORRY!=== Error while compiling -e
> > Unable to parse expression in typename; couldn't find final ')'
> > at -e:1
> > --> enum FF ; FF(FF(⏏2)).perl.say
> >
> >
> > # o.O
> > $ perl6 -e 'enum FF ; enum GG ;
> > FF(foo).perl.say'
> > FF
> >
> > $ perl6 -e 'enum FF ; enum GG ;
> > FF(GG(foo)).perl.say'
> > FF(GG(GG))
> >
> > $ perl6 -e 'enum FF ; enum GG ;
> > FF(GG(2)).perl.say'
> > ===SORRY!=== Error while compiling -e
> > Unable to parse expression in typename; couldn't find final ')'
> > at -e:1
> > --> hree>; enum GG ; FF(GG(⏏2)).perl.say
> >
> 
> 
> 

Fixed with commit 
https://github.com/rakudo/rakudo/commit/c76d9324a9f67e4075683e38a63a9788161c17cc

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

[Jan-Olof Hendig via RT]

On Mon, 03 Jul 2017 14:16:58 -0700, allber...@gmail.com wrote:
> [03 21:03:27]  m: use NativeCall; sub foo(num $a) is
> native("foo") { * };
> [03 21:03:27]  rakudo-moar a7b230: OUTPUT: «===SORRY!=== Error
> while compiling ␤
> [03 21:03:27]  Cannot resolve caller infix:<==>(NQPMu, Int); none of these
> signatures match:␤
> [03 21:03:27]  ($?)␤
> [03 21:03:27]  (\a, \b)␤
> [03 21:03:27]  (Real \a, Real \b)␤
> [03 21:03:27]  (Int:D \a, Int:D \b)␤
> [03 21:03:27]  (int $a, int $b)␤
> [03 21:03:27]  (Num:D \a, Num:D \b …»
> [03 21:06:25]  now I think we have an LTA...
> [03 21:06:52]  m: use NativeCall; sub foo(num32 $a) is
> native("foo") { * };
> [03 21:06:53]  rakudo-moar a7b230: ( no output )
> [03 21:06:59]  LTA for a bad native type
> 

Testing with 
~ $ perl6 -v
This is Rakudo version 2018.02.1-164-g57af8b847 built on MoarVM version 
2018.02-171-geee5be412
implementing Perl 6.c.

the result looks quite a bit better:

~ $ perl6 -e 'use NativeCall; sub foo(num $a) is native("foo") { * }'
Potential difficulties:
In 'foo' routine declaration - Not an accepted NativeCall type for 
parameter [1] $a : num
 --> For Numerical type, use the appropriate int32/int64/num64...
at -e:1
--> use NativeCall; sub foo(num $a) ⏏is native("foo") { * }

[perl #130883] problem with RESOURCES and PERL6LIB env variable

[Jan-Olof Hendig via RT]

On Mon, 17 Jul 2017 10:50:55 -0700, ug...@cpan.org wrote:
> The %?RESOURCES bug was fixed in: https://github.com/rakudo/rakudo/pull/1106

ugexe, does that mean that the issue can be marked as resolved?

[perl #131790] [BUG] :delete silently fails on lazy Arrays

[Jan-Olof Hendig via RT]

On Mon, 24 Jul 2017 09:09:55 -0700, c...@zoffix.com wrote:
> m: my @a is default(42) = 1...*; @a[1]:delete; say @a[1]:exists; .say
> for @a[^10]
> rakudo-moar 2fb8c7: OUTPUT: «True␤1␤2␤3␤4␤5␤6␤7␤8␤9␤10␤»
> 
> Expected: reify until `1`, delete it, and have `@a[1]:exists` give
> False, and `.say for @a[^10]` give 42 for the second element.

This was fixed with commit 
https://github.com/rakudo/rakudo/commit/0385b2aa4554eca1421081968642a43f883889cd
Test was added with commit 
https://github.com/perl6/roast/commit/9cc47b28a9f4c7a6256a8521080620a50bed75a8

[perl #128512] [BUG] utf8-c8 mangles by NFC

[Jan-Olof Hendig via RT]

On Sun, 26 Feb 2017 23:01:18 -0800, zef...@fysh.org wrote:
> This problem no longer occurs.
> 
> -zefram
> 

Fixed with commit (2017-01-02) 
https://github.com/rakudo/rakudo/commit/7c8b705b3375522fc36304b771f82f50246afcf0

[perl #128511] [BUG] utf8-c8 generates spurious NUL

[Jan-Olof Hendig via RT]

On Sun, 26 Feb 2017 23:02:00 -0800, zef...@fysh.org wrote:
> This problem no longer occurs.
> 
> -zefram
> 

This was fixed with commit (2017-01-02) 
https://github.com/rakudo/rakudo/commit/7c8b705b3375522fc36304b771f82f50246afcf0

[perl #127352] [BUG] Behavior of Regular Expressions Contained in a Constant with a Sigil

[Jan-Olof Hendig via RT]

On Fri, 05 Aug 2016 18:04:36 -0700, c...@zoffix.com wrote:
> Still present today:
> 
>  m: my $sepreg = rx/(<[\\/]>)/; my $filenameW =
> "c:\\g\\b.mp4"; $filenameW ~~ $sepreg; say $/;
>  rakudo-moar 589061: OUTPUT«｢\｣␤ 0 => ｢\｣␤»
>  m: constant $sepreg = rx/(<[\\/]>)/; my $filenameW =
> "c:\\g\\b.mp4"; $filenameW ~~ $sepreg; say $/;
>  rakudo-moar 589061: OUTPUT«Nil␤»
>  m: constant sepreg = rx/(<[\\/]>)/; my $filenameW =
> "c:\\g\\b.mp4"; $filenameW ~~ sepreg; say $/;
>  rakudo-moar 589061: OUTPUT«｢\｣␤ 0 => ｢\｣␤»

Fixed with commit 
https://github.com/rakudo/rakudo/commit/5ac593ee098f204ea69ef57edd9ae0925c544ea4

[perl #126955] [BUG] more .perl string quoting problems

[Jan-Olof Hendig via RT]

On Mon, 21 Dec 2015 11:09:40 -0800, zef...@fysh.org wrote:
> Elizabeth Mattijsen via RT wrote:
> >All of that goodness now in 591783d116a56d4b2c54f .
> 
> You left a stray line in IO::Path.perl, which calls PERLIFY-STR in
> sink context.
> 
> >Indeed!   Now, if this had been in a Pull Request, I could have just
> >clicked on Merge, which would have been less work for me  :-)
> 
> But it being a Pull Request would involve me signing over my firstborn
> to github.
> 
> >Ever considered getting a commit bit ?
> 
> I think that would be a bad idea, for a number of reasons.  I'm suffering
> project overload as it is, and haven't used my Perl 5 commit bit in ages.
> You also know my overall opinion of Perl 6, and that doesn't make Rakudo
> an attractive bugfixing target for me.  It seems best that my involvement
> remain peripheral.
> 
> -zefram
> 

The stray line was removed with commit 34c4fe977e067b4e4eb02b5d. Test needed.

[perl #131887] [BUG] method freeze(Pair:D:) changes object identity

[Jan-Olof Hendig via RT]

On Sun, 13 Aug 2017 15:14:41 -0700, elizabeth wrote:
> Fixed with https://github.com/rakudo/rakudo/commit/c229022cb0 , tests
> needed
> 
> > On 12 Aug 2017, at 14:36, Peter du Marchie van Voorthuysen (via RT)
> >  wrote:
> >
> > # New Ticket Created by  Peter du Marchie van Voorthuysen
> > # Please include the string:  [perl #131887]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=131887 >
> >
> >
> > This is Rakudo version 2017.07 built on MoarVM version 2017.07
> > implementing Perl 6.c.
> >
> > If the value of a Pair is a Scalar container, then the Pair can be
> > modified, e.g.
> >
> >> my $value = 0;
> > 0
> >> my $pair = number => $value;
> > number => 0
> >> $pair.value = 1; $pair;
> > number => 1
> >
> > Method freeze make the value of the Pair read-only, by removing it
> > from its
> > Scalar container, and returns the value.
> >
> >> $pair.freeze;
> > 1
> >> $pair.value = 2;
> > Cannot modify an immutable Int (1)
> >   in block  at  line 1
> >
> > The problem is that freeze does more than that. It changes the object
> > identity as returned by WHICH as well:
> >
> >> $pair = number => $value;
> > number => 1
> >> $pair.WHICH;
> > Pair|127791728
> >> $pair.freeze;
> > 1
> >> $pair.WHICH;
> > Pair|Str|number|Int|1
> >
> > Now by itself having a 2-tuple that is identified by its two elements
> > is a
> > nice feature (if it would be documented). But _changing_ the object
> > identity is not consistent with the behavior of other built-in Perl 6
> > classes and actually breaks the implementation of some of these
> > classes.
> >
> > For example, a SetHash represents a mutable set. The Set method
> > returns a
> > _new_ object that is immutable:
> >
> >> $pair = number => $value;
> > number => 1
> >> my $set = SetHash.new($pair);
> > SetHash.new(number => 1)
> >> my $set2 = $set.Set;
> > set(number => 1)
> >> $set.WHICH;
> > SetHash|136539408
> >> $set2.WHICH;
> > Set|0EC3BFFD57719F5C6A3EE91A5EFAA5AEFE273964
> >
> > But because freezing a Pair changes the identity of the _original_
> > object
> > it's possible to add a second instance of the _same_ Pair to the
> > SetHash,
> > causing it to violate its contract:
> >
> >> $pair.freeze;
> > 1
> >> $set{$pair} = True;
> > True
> >> my ($a, $b) = $set.keys;
> > (number => 1 number => 1)
> >> $a === $b;
> > True
> >
> > I think it's clear that changing the identity of the original object
> > is not
> > correct. So I propose to remove the undocumented behavior of the
> > freeze
> > method that it changes the object identity.
> >
> > Now I can imagine that at some implementation level there are
> > benefits to
> > having a kind of Pair that is identified by its key _and_ value. I
> > also
> > think it could be generally useful to have a class implementing a
> > truly
> > immutable (2-)tuple that is identified by its elements. But that
> > should be
> > a separate class and the Pair class should provide a method to create
> > a
> > _new_ object of this class from a Pair object.

Test added with commit https://github.com/perl6/roast/commit/d7d42d6c37

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

[Jan-Olof Hendig via RT]

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. 

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

[Jan-Olof Hendig via RT]

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 #122137] Type object seem to bind in item or push

[Jan-Olof Hendig via RT]

On Mon, 18 Sep 2017 13:52:21 -0700, b...@abrij.org wrote:
> On Thu, 19 Jun 2014 17:45:23 -0700, elizabeth wrote:
> > Additional finds:
> > 
> > [19:24:52] m: my @a; my $c = 1; @a.push: $($c,1); $c =
> > "hi"; @a.push: $($c,2); say @a.perl
> > [19:24:53] <+camelia>rakudo-moar 8812ca: OUTPUT«Array.new($("hi",
> > 1), $("hi", 2))␤»
> > [19:25:09] it would appear the container of the $c is
> > being pushed, rather than the value?
> > [19:26:56] It's not the fact that it's being pushed,
> > it's the building of $($c, 1), isn't it?
> > [19:27:14] could very well be
> > [19:27:19] is that being done at compile-time perhaps?
> > [19:27:29] m: my $c = 1; my \b = $($c, 1); $c = Int; say
> > b.perl
> > [19:27:31] <+camelia>rakudo-moar 8812ca: OUTPUT«$(Int, 1)␤»
> > [19:27:39] m: my $c = 1; my $b = $($c, 1); $c = Int; say
> > $b.perl
> > [19:27:40] <+camelia>rakudo-moar 8812ca: OUTPUT«$(Int, 1)␤»
> > [19:28:22] no, the optimizer leaves that alone.
> > [19:29:22] m: my $c = 1; my $b = ($c, 1); $c = Int; say
> > $b.perl
> > [19:29:23] <+camelia>rakudo-moar 8812ca: OUTPUT«$(Int, 1)␤»
> > [19:29:30] m: my $c = 1; my $b = [$c, 1]; $c = Int; say
> > $b.perl
> > [19:29:31] <+camelia>rakudo-moar 8812ca: OUTPUT«[1, 1]␤»
> > [19:30:37] m: my $c = 1; my $b = Array.new($c, 1); $c =
> > Int; say $b.perl
> > [19:30:38] <+camelia>rakudo-moar 8812ca: OUTPUT«[Int, 1]␤»
> > [19:30:44] Many WTFs to be had
> > [19:31:33] p6: my $c = 1; my $b = Array.new($c, 1); $c =
> > Int; say $b.perl
> > [19:31:38] <+camelia>niecza v24-109-g48a8de3: OUTPUT«Unhandled
> > exception: Excess arguments to List.new, used 1 of 3 positionals␤  at
> > /home/p6eval/niecza/lib/CORE.setting line 0 (List.new @ 1) ␤  at
> > /tmp/tmpfile line 1 (mainline @ 4) ␤  at
> > /home/p6eval/niecza/lib/CORE.setting line 4595 (ANON @ 3) …»
> > [19:31:38] <+camelia>..rakudo-{parrot,jvm,moar} 8812ca:
> > OUTPUT«[Int, 1]␤»
> > [19:31:51] n: my $c = 1; my $b = ($c, 1); $c = Int; say
> > $b.perl
> > [19:31:53] <+camelia>niecza v24-109-g48a8de3: OUTPUT«$(Int, 1)␤»
> > [19:33:07] OTOH, ($c,) having the container is the only
> > way ($c, *) = * could work
> > [19:33:21] Other than special-casing
> > [19:34:32] that's true
> > [19:35:03] m: my $c; say $($c, 1).WHAT
> > [19:35:03] <+camelia>rakudo-moar 8812ca: OUTPUT«(Parcel)␤»
> > [19:35:07] ah, it's a parcel
> > [19:35:18] those are supposed to be internal-ish magic-
> > ish any way
> > [19:35:36] to be honest, i'd rather use [  ] for nested
> > structures
> > [20:39:20]  Mouq: it has nothing to do with .push (or
> > unshift): it has to do with Parcel generation:
> > [20:39:23]   r: my $c=42; my $a = $($c,1); $c=43; my $b =
> > $($c,2); .perl.say for $a, $b
> > [20:39:27] <+camelia>rakudo-{parrot,jvm,moar} 8812ca: OUTPUT«$(43,
> > 1)␤$(43, 2)␤»
> > [20:40:03]   r: my $c=42; my $a = $(+$c,1); $c=43; my $b =
> > $(+$c,2); .perl.say for $a, $b
> > [20:40:06] <+camelia>rakudo-{parrot,jvm,moar} 8812ca: OUTPUT«$(42,
> > 1)␤$(43, 2)␤»
> > [20:40:20]   r: my $c=42; my $a = $($c,1); $c=43; my $b =
> > $(+$c,2); .perl.say for $a, $b
> > [20:40:24] <+camelia>rakudo-{parrot,jvm,moar} 8812ca: OUTPUT«$(43,
> > 1)␤$(43, 2)␤»
> > [20:40:39]   r: my $c=42; my $a = $(+$c,1); $c=43; my $b =
> > $($c,2); .perl.say for $a, $b
> > [20:40:43] <+camelia>rakudo-{parrot,jvm,moar} 8812ca: OUTPUT«$(42,
> > 1)␤$(43, 2)␤»
> > [20:42:36]   ah, timotimo and Mouq already established
> > that  :-)
> 
> I don't see anything that looks out of sorts with our current
> post-GLR semantics.  Should this (very old) ticket just be retired now?

Very old bug. Closed after discussion with lizmat, see 
https://irclog.perlgeek.de/perl6-dev/2018-03-12#i_15911761

[perl #127030] [BUG] await start { qx/../ } doesn't wait

[Jan-Olof Hendig via RT]

On Sat, 26 Dec 2015 06:25:14 -0800, lloyd.fo...@gmail.com wrote:
> just to confirm. it works on my debian container:
> 
> root@84f1511728c6:~# perl6 -e 'say (await start { qx/echo foo/ }).perl'
> "foo\n"
> 
> 
> On Sat, Dec 26, 2015 at 10:41 PM Lloyd Fournier 
> wrote:
> 
> > Hey Timo. I'm afraid I'm interpreting it correctly:
> >
> > Lloyds-iMac:~ llfourn$ perl6 -e 'say (await start { qx/echo foo/ }).perl'
> > slip()
> >
> > Looks like we've got a mac bug:
> > Lloyds-iMac:~ llfourn$ perl6 -v
> > This is Rakudo version 2015.12 built on MoarVM version 2015.12
> > implementing Perl 6.c.
> >
> > On Sat, Dec 26, 2015 at 10:31 PM Timo Paulssen via RT <
> > perl6-bugs-follo...@perl.org> wrote:
> >
> >> On 12/26/2015 06:08 AM, Lloyd Fournier (via RT) wrote:
> >> >  perl6 -e 'say await start { qx/echo foo/ }'
> >> >
> >> > outputs an empty list. Pretty sure that's a bug.
> >>
> >> I can't reproduce this. Does this code give the same result on your
> >> machine as on mine?
> >>
> >> timo@schmetterling ~> perl6 -e 'say (await start { qx/echo foo/
> >> }).perl'
> >> "foo\n"
> >>
> >> I think you may have misinterpreted the output of that script you
> >> pasted, as it prints "foo" in one line, then an empty line.
> >>
> >>
> >>

It also work on Mac with 

This is Rakudo version 2018.02.1-146-g52e66ad30 built on MoarVM version 
2018.02-33-ge639691a7
implementing Perl 6.c.

see https://irclog.perlgeek.de/perl6-dev/2018-03-12#i_15911567

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

[Jan-Olof Hendig via RT]

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 #131871] [CONC] [REGEX] Regex code block closing over lexical variable, is not threadsafe

[Jan-Olof Hendig via RT]

On Wed, 09 Aug 2017 13:06:46 -0700, sml...@gmail.com wrote:
> This bug was found as a side-effect of RT #131870, but might be a 
> separate issue:
> 
>  ➜ await ^10 .map: -> $i { start { "".match(/ { say $i } /) } }
>  7
>  7
>  6
>  6
>  7
>  8
>  9
>  9
>  9
>  9
> 

Fixed with one or more of (better-sched)
7c18112c59d20413b82356e5c48b38d8a66fc7ea
c285b489c6629ccdf0c4cb11d2d695b9ef1f890c
7fcab1067de4757bfdf2fdd1c66893ce4ab06e1b
89b9ac7830bdc195cb303f5241641e0dbe0ebbde
683037be698d0bdc21b3c23588085b2d076d7a0a
b5605c2dd6d361b705a59136c8ad641f245a5da5
c50d35a90e66346157b31cd92643c2a64e801c24
de311f46a98f13a5b0211d2585fbd9b17ce1bf2c
340d8ed3bb4b45af85708771bea396cf862a7330
3b98fb9e396d040a8cb2c32d23cee54a5e88f878
596611c8fdc3baf119bc94a8ea30efc0a12cf673
80b49320cf854ac68a17cdd216575ee26e380325
61a77e60a7d936415503d8916fcc7546569e9135
> Somehow, multiple iterations see the same value for the closed-over 
> variable `$i`.
> 
> Without the `await` and `start`, it prints each number from 0 to 9 
> exactly once, like it should.
> 
> ---
> 
> Note that the problem is only with *code blocks* inside regexes. When a 
> lexical variable is interpolated into the top-level of a regex directly, 
> things seem to work fine:
> 
>  ➜ say await ^10 .map: -> $i { start { "0123456789".match(/ $i /) } }
>  (｢0｣ ｢1｣ ｢2｣ ｢3｣ ｢4｣ ｢5｣ ｢6｣ ｢7｣ ｢8｣ ｢9
> 
> ---
> 
> Bot-friendly version that reliably prints `False`, even though it should 
> print `True`:
> 
>  my $c = Channel.new;   (await ^100 .map: -> $i { start "".match(/ { 
> $c.send: $i } /) });   $c.close; say $c.sort.list eqv (^100).list;
> 
> According to bisectable6 and committable6 this prints `False` for all 
> past Perl 6 releases, so it's not a regression but rather an old bug.

[perl #131870] [CONC] [REGEX] Capture lookup inside regex is not threadsafe

[Jan-Olof Hendig via RT]

On Wed, 09 Aug 2017 13:32:58 -0700, sml...@gmail.com wrote:
> Heh, on further thought, they may be the same issue after all.
> 
> In  `/(...) { ... $i ... $0 ... }`,  both the $i and the $0 (or $/
> rather) are outer lexicals from the point of view of the curly block,
> right?
> 
> So it might be a general problem with the way that *code blocks inside
> regexes* access outer lexicals.
> 
> (It doesn't happen with code blocks *outside* of regexes, and as the
> other ticket demonstrates, also doesn't happen inside the regex-
> portion of regexes.)

It was initially broken with commit (2016-08-03) 
https://github.com/rakudo/rakudo/commit/08e39ee2653b1ae5144d4158a4f8ad03193e7024
and fixed with the better-sched merge, i.e.
7c18112c59d20413b82356e5c48b38d8a66fc7ea
c285b489c6629ccdf0c4cb11d2d695b9ef1f890c
7fcab1067de4757bfdf2fdd1c66893ce4ab06e1b
89b9ac7830bdc195cb303f5241641e0dbe0ebbde
683037be698d0bdc21b3c23588085b2d076d7a0a
b5605c2dd6d361b705a59136c8ad641f245a5da5
c50d35a90e66346157b31cd92643c2a64e801c24
de311f46a98f13a5b0211d2585fbd9b17ce1bf2c
340d8ed3bb4b45af85708771bea396cf862a7330
3b98fb9e396d040a8cb2c32d23cee54a5e88f878
596611c8fdc3baf119bc94a8ea30efc0a12cf673
80b49320cf854ac68a17cdd216575ee26e380325
61a77e60a7d936415503d8916fcc7546569e9135

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

[Jan-Olof Hendig via RT]

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

[perl #127974] [CONC] sprintf() not threadsafe/reentrant if the format tokens use explicit indices

[Jan-Olof Hendig via RT]

On Sun, 28 May 2017 02:34:13 -0700, sml...@gmail.com wrote:
> Still present in
> 
> Rakudo version 2017.05-272-gfa7aa1c36 built on MoarVM version 2017.05-
> 25-g62bc54e9
> implementing Perl 6.c.

Fixed, probably by one or more of the following commits:
7c18112c59d20413b82356e5c48b38d8a66fc7ea
c285b489c6629ccdf0c4cb11d2d695b9ef1f890c
7fcab1067de4757bfdf2fdd1c66893ce4ab06e1b
89b9ac7830bdc195cb303f5241641e0dbe0ebbde
683037be698d0bdc21b3c23588085b2d076d7a0a
b5605c2dd6d361b705a59136c8ad641f245a5da5
c50d35a90e66346157b31cd92643c2a64e801c24
de311f46a98f13a5b0211d2585fbd9b17ce1bf2c
340d8ed3bb4b45af85708771bea396cf862a7330
3b98fb9e396d040a8cb2c32d23cee54a5e88f878
596611c8fdc3baf119bc94a8ea30efc0a12cf673
80b49320cf854ac68a17cdd216575ee26e380325
61a77e60a7d936415503d8916fcc7546569e9135

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

[Jan-Olof Hendig via RT]

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 #131206] “Oops!!!” when using --target=ast (^…)

[Jan-Olof Hendig via RT]

On Mon, 24 Apr 2017 15:32:33 -0700, alex.jakime...@gmail.com wrote:
> Run this:
> perl6 --target=ast -e '^…'
> 
> And among normal lines from the output you will see these messages:
> 
> Oops!!! Cannot invoke this object (REPR: P6opaque; NQPMu)
> 
> I don't think it should happen.
> 
> 
> Full output here:
> 
> - QAST::CompUnit  :W :UNIT
>   [pre_deserialize]
>  - QAST::Stmt
>- QAST::Stmt
>  - QAST::Op(loadbytecode)
>- QAST::VM
> [jvm]
>- QAST::SVal(ModuleLoader.class)
> [moar]
>- QAST::SVal(ModuleLoader.moarvm)
>  - QAST::Op(callmethod load_module)
>- QAST::Op(gethllsym)
>  - QAST::SVal(nqp)
>  - QAST::SVal(ModuleLoader)
>- QAST::SVal(Perl6::ModuleLoader)
>- QAST::Op(forceouterctx)
>  - QAST::BVal(2)
>  - QAST::Op(callmethod load_setting)
>- QAST::Op(getcurhllsym)
>  - QAST::SVal(ModuleLoader)
>- QAST::SVal(CORE)
>   [post_deserialize]
>  - QAST::Stmts
>- QAST::Op(bind)
>  - QAST::Var(attribute $!do)
>- QAST::WVal(Block)
>- QAST::WVal(Code)
>  - QAST::BVal(1)
>  - QAST::Op(bindcurhllsym)
>- QAST::SVal(GLOBAL)
>- QAST::WVal(GLOBAL)
>   [load]
>  - QAST::Op(call)
>- QAST::BVal(2)
>   [children]
> - QAST::Block  :in_stmt_mod ^…
>- QAST::Var(local __args__ :decl(param))
> - QAST::Stmts
>- QAST::Op(call)
> - QAST::Block(:blocktype(declaration_static))
> :IN_DECL :in_stmt_mod :code_object :outer
> - QAST::Stmts
>  - QAST::Var(lexical $¢ :decl(contvar))
>  - QAST::Var(lexical $! :decl(contvar))
>  - QAST::Var(lexical $/ :decl(contvar))
>  - QAST::Var(lexical $_ :decl(contvar))
>  - QAST::Var(lexical GLOBALish :decl(static))
>  - QAST::Var(lexical EXPORT :decl(static))
>  - QAST::Var(lexical $?PACKAGE :decl(static))
>  - QAST::Var(lexical ::?PACKAGE :decl(static))
>  - QAST::Var(lexical $=finish :decl(static))
>  - QAST::Var(lexical $=pod :decl(static))
>   [value]
>  -
>  - QAST::Var(lexical !UNIT_MARKER :decl(static))
>- QAST::VM
> [jvm]
>- QAST::Op(null)
> [moar]
>- QAST::Op(null)
> [loadlibs]
>   - nqp_group nqp_ops perl6_ops bit_ops math_ops trans_ops
> io_ops obscure_ops os file sys_ops nqp_bigint_ops nqp_dyncall_ops
>- QAST::Stmts
>  - QAST::Op(bind)
>- QAST::Var(local ctxsave :decl(var))
>- QAST::Var(contextual $*CTXSAVE)
>  - QAST::Op(unless)
>- QAST::Op(isnull)
>  - QAST::Var(local ctxsave)
>- QAST::Op(if)
>  - QAST::Op(can)
>- QAST::Var(local ctxsave)
>- QAST::SVal(ctxsave)
>  - QAST::Op(callmethod ctxsave)
>- QAST::Var(local ctxsave)
>- QAST::Stmts
>  - QAST::WVal(Array)
> - QAST::Stmts  ^…
>   - QAST::Stmt  ^…
> - QAST::Want 
>   - QAST::Op(call :<^>)  :statement_id
> ^
> - QAST::Op(call )  …
>   - QAST::Op(callmethod new) 
> - QAST::WVal(X::StubCode) 
> Oops!!! Cannot invoke this object (REPR: P6opaque; NQPMu)
>   - v
>- QAST::Op(p6sink)
> - QAST::Op(call :<^>) 
> :statement_id ^
>   - QAST::Op(call )  …
> - QAST::Op(callmethod new) 
>   - QAST::WVal(X::StubCode) 
> Oops!!! Cannot invoke this object (REPR: P6opaque; NQPMu)
>  - QAST::WVal(Nil)

Fixed with commit 
https://github.com/rakudo/rakudo/commit/49dce163e8182ee726cd1e512a03c29551cc16da

Found by bisectbot++ using:
bisect: my $p = run :out, ; say 
$p.out.slurp-rest.contains: ‘Oops’ 

Tests should not be added to roast, rather 
https://github.com/rakudo/rakudo/tree/master/t

[perl #127869] [BUG] if my $match is True and False

[Jan-Olof Hendig via RT]

On Sun, 18 Dec 2016 15:36:31 -0800, c...@zoffix.com wrote:
> On Sun, 10 Apr 2016 07:56:38 -0700, mar...@senfdax.de wrote:
> > Hi there,
> >
> > following code dies in this line:
> >
> > if my $match = $r.match($meth, $uri) { die "What?!" unless $match }
> >
> > this happens on both moar-2015.12 and moar-2016.03
> >
> >
> >
> >
> >
> > class Abc {
> > has Str $.method;
> > has Regex $.path is required;
> >
> > method match (Str $method, Str $path) {
> > return False if $.method ne $method;
> > return $path ~~ $.path;
> > }
> > }
> >
> > my @routes = (
> > Abc.new(method => "GET", path => / ^ '/'foo $ / );
> > Abc.new(method => "POST", path => / ^ '/'bar $ /);
> > );
> >
> > sub foo($meth, $uri) {
> > for @routes -> $r {
> > if my $match = $r.match($meth, $uri) { die "What?!" unless
> > $match }
> > }
> > }
> >
> > my @hex = ('A'..'F', 'a'..'f', 0..9).flat;
> > for @hex -> $first {
> > for @hex -> $second {
> > foo("POST", 'http://127.0.0.1/utf8');
> > }
> > }
> >
> 
> Unable to reproduce this on This is Rakudo version 2016.12-10-g7a642f8
> built on MoarVM version 2016.12
> implementing Perl 6.c.

Fixed with commit 
https://github.com/rakudo/rakudo/commit/25e9fd76e85fabda20e263b6f87e27b0673f26e2

For reference:
https://github.com/perl6/nqp/compare/2016.07-140-g2df0a06...2016.07-177-gb416158
https://github.com/MoarVM/MoarVM/compare/2016.07-17-g40948f6...2016.07-24-g31eccd7

[perl #130843] [MOAR][IO] .seek(... SeekFromCurrent) seeks to incorrect place if called after .readchars

[Jan-Olof Hendig via RT]

On Wed, 22 Feb 2017 15:09:44 -0800, c...@zoffix.com wrote:
> If .seek(... SeekFromCurrent) is called after a call to .readchars,
> the position sought to appears to be way off target:
> 
> 22:54   IOninja m: "/tmp/Foo.pm6".IO.spurt: "I love you so very
> much"; with "/tmp/Foo.pm6".IO.open { .read(2); .seek: 1,
> SeekFromCurrent; .tell.say }
> 22:54   camelia rakudo-moar 5ec251: OUTPUT: «3␤»
> 22:55   IOninja m: "/tmp/Foo.pm6".IO.spurt: "I love you so very
> much"; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek: 1,
> SeekFromCurrent; .tell.say }
> 22:55   camelia rakudo-moar 5ec251: OUTPUT: «24␤»
> 22:55   IOninja looks .readchars messes up the current position as
> far as seekage is concerned (it's fine if you try to read more, for
> example)
> 
> After some discussion on IRC (https://irclog.perlgeek.de/perl6-
> dev/2017-02-22 ), one suggestion was that there's some sort of
> buffering involved:
> 
> 23:00   m: "/tmp/Foo.pm6".IO.spurt: "I love you\nso very
> much"; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek: 1,
> SeekFromCurrent; .tell.say }
> 23:00   camelia rakudo-moar 5ec251: OUTPUT: «24␤»
> 23:00   IOninja m: "/tmp/Foo.pm6".IO.spurt: "I love you\nso very
> much" x 100; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek: 1,
> SeekFromCurrent; .tell.say }
> 23:00   camelia rakudo-moar 5ec251: OUTPUT: «2301␤»
> 23:00   jnthn   Anyway, just sayin' that if it's off-by-one it's
> actually not lying :)
> 23:00   IOninja m: "/tmp/Foo.pm6".IO.spurt: "I love you\nso very
> much" x 1; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek: 1,
> SeekFromCurrent; .tell.say }
> 23:00   camelia rakudo-moar 5ec251: OUTPUT: «32769␤»
> 23:00   IOninja m: "/tmp/Foo.pm6".IO.spurt: "I love you\nso very
> much" x 2; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek: 1,
> SeekFromCurrent; .tell.say }
> 23:00   camelia rakudo-moar 5ec251: OUTPUT: «32769␤»
> 
> This behaviour is not present on JVM.

The fixes, and tests, made by Zoffix, when fixing 
https://rt.perl.org/Public/Bug/Display.html?id=131376
covers this bug as well.

[perl #131275] Str.comb returns a List instead of a Seq when matcher is a Regex

[Jan-Olof Hendig via RT]

On Sat, 10 Mar 2018 10:34:05 -0800, jan-olof.hen...@bredband.net wrote:
> On Mon, 08 May 2017 15:01:03 -0700, c...@zoffix.com wrote:
> > Filing per https://irclog.perlgeek.de/perl6-dev/2017-05-08#i_14551843
> > 
> >  m: say WHAT 'foo'.comb
> >  rakudo-moar 20cfd6: OUTPUT: «(Seq)␤»
> >  m: say WHAT 'foo'.comb: 1
> >  rakudo-moar 20cfd6: OUTPUT: «(Seq)␤»
> >  m: say WHAT 'foo'.comb: /1/
> >  rakudo-moar 20cfd6: OUTPUT: «(List)␤»
> > 
> > See also https://irclog.perlgeek.de/perl6-dev/2017-05-08#i_14552322
> 
> Dupe of G #1564

Full link: https://github.com/rakudo/rakudo/issues/1564

[perl #131275] Str.comb returns a List instead of a Seq when matcher is a Regex

[Jan-Olof Hendig via RT]

On Mon, 08 May 2017 15:01:03 -0700, c...@zoffix.com wrote:
> Filing per https://irclog.perlgeek.de/perl6-dev/2017-05-08#i_14551843
> 
>  m: say WHAT 'foo'.comb
>  rakudo-moar 20cfd6: OUTPUT: «(Seq)␤»
>  m: say WHAT 'foo'.comb: 1
>  rakudo-moar 20cfd6: OUTPUT: «(Seq)␤»
>  m: say WHAT 'foo'.comb: /1/
>  rakudo-moar 20cfd6: OUTPUT: «(List)␤»
> 
> See also https://irclog.perlgeek.de/perl6-dev/2017-05-08#i_14552322

Dupe of G #1564

[perl #126563] [BUG] 'X' meta-operator fails with RHS input from parenthesized output of another 'X'

[Jan-Olof Hendig via RT]

On Thu, 08 Mar 2018 09:52:50 -0800, jan-olof.hen...@bredband.net wrote:
> On Wed, 04 Nov 2015 12:43:18 -0800, dhoek...@gmail.com wrote:
> > In perl6 version 2015.10-158-gbccb16d built on MoarVM version
> > 2015.10-46-g5bf7e46:
> >
> > Looking at the code for Hamming numbers at Rosetta Code found this
> > problem:
> >
> > my @z = <1 2>;
> > say  @z X*  @z  X* @z;# OK
> > say (@z X*  @z) X* @z;# OK
> > say  @z X* (@z  X* @z).Array; # OK
> > say  @z X* (@z  X* @z);  # fails
> >
> > (1 2 2 4 2 4 4 8)
> > (1 2 2 4 2 4 4 8)
> > (1 2 2 4 2 4 4 8)
> > ===SORRY!===
> > Cannot invoke this object (REPR: Uninstantiable)
> >
> > Likewise fails for other arithmetic operations (+, -, /, **), as well
> > as:
> >
> > my @y = ;
> > say  @y X~ (@y  X~ @y);  # fails
> >
> > But ','  works with both @x and @y.
> 
> This was fixed with commit a26f51361bfea213fa59749d7a401e09c8f2ef31.
> Tests needed.

Tests added with roast commit https://github.com/perl6/roast/commit/b68073aa15

[perl #130502] [LTA] error message complains too much about Metamodel.nqp (Buf.new('0'))

[Jan-Olof Hendig via RT]

On Wed, 04 Jan 2017 14:21:15 -0800, alex.jakime...@gmail.com wrote:
> Code:
> say Buf.new('0')
> 
> Result:
> Type check failed in initializing element #0 to Buf; expected uint8
> but got Str ("0")
>   in any  at gen/moar/Metamodel.nqp line 1727
>   in block  at /tmp/9PmeQTevmg line 1
> 
> Actually thrown at:
>   in any  at gen/moar/Metamodel.nqp line 3072
>   in any  at gen/moar/Metamodel.nqp line 1727
> in block  at /tmp/9PmeQTevmg line 1
> 
> 

Fixed with commit 
https://github.com/rakudo/rakudo/commit/f230224d27bb6d47746de836113b07bf9a4ebcc0
> 
> It points three times to a line in Metamodel.nqp, and only once to the
> actual user file. Perhaps there is a way to improve it? Maybe not just
> for this case, but for any exception?

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

[Jan-Olof Hendig via RT]

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 #128553] [SEGV] multi method cache causes Base64 regression

[Jan-Olof Hendig via RT]

On Wed, 27 Jul 2016 17:43:48 -0700, lloyd.fo...@gmail.com wrote:
> By flag_map I mean ctx->callsite->arg_flags:
> 
> (lldb) p ctx->arg_flags
> (MVMCallsiteEntry *) $8 = 0x
> (lldb) p ctx->callsite->arg_flags
> (MVMCallsiteEntry *) $9 = 0x10a72533 ""
> 
> On Mon, Jul 11, 2016 at 3:59 AM Lloyd Fournier 
> wrote:
> 
> > I've been getting segfaults in this area recently. The trace is a bit
> > different but I guess it's related. It seems that flag_map in gc_mark
> > is no
> > longer allocated so I get segfault.
> >
> > (lldb) r
> > There is a running process, kill it and restart?: [Y/n] y
> > Process 75673 exited with status = 9 (0x0009)
> > Process 75691 launched: '/Users/llfourn/src/rakudo/install/bin/moar'
> > (x86_64)
> > Process 75691 stopped
> > * thread #1: tid = 0x23cfc68, 0x000100063ca4
> > libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> > data=, worklist=0x00010d27c1a0) + 84 at
> > MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
> > EXC_BAD_ACCESS (code=1, address=0x10a72533)
> > frame #0: 0x000100063ca4
> > libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> > data=, worklist=0x00010d27c1a0) + 84 at
> > MVMCallCapture.c:55
> >52  MVMuint16  count = ctx->arg_count;
> >53  MVMuint16  i, flag;
> >54  for (i = 0, flag = 0; i < count; i++, flag++) {
> > -> 55  if (flag_map[flag] & MVM_CALLSITE_ARG_NAMED) {
> >56  /* Current position is name, then next is
> > value. */
> >57  MVM_gc_worklist_add(tc, worklist, 
> > >args[i].s);
> >58  i++;
> > (lldb) bt
> > * thread #1: tid = 0x23cfc68, 0x000100063ca4
> > libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> > data=, worklist=0x00010d27c1a0) + 84 at
> > MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
> > EXC_BAD_ACCESS (code=1, address=0x10a72533)
> >   * frame #0: 0x000100063ca4
> > libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> > data=, worklist=0x00010d27c1a0) + 84 at
> > MVMCallCapture.c:55
> > frame #1: 0x00010003f002
> > libmoar.dylib`MVM_gc_mark_collectable(tc=,
> > worklist=, new_addr=) + 1714 at
> > collect.c:399
> > frame #2: 0x00010003e883
> > libmoar.dylib`process_worklist(tc=0x000100500290,
> > worklist=0x00010d27c1a0, wtp=0x7fff5fbff468, gen='\0') + 899
> > at
> > collect.c:313
> > frame #3: 0x00010003e324
> > libmoar.dylib`MVM_gc_collect(tc=0x000100500290,
> > what_to_do=, gen=) + 820 at collect.c:129
> > frame #4: 0x00010003b703
> > libmoar.dylib`run_gc(tc=0x000100500290, what_to_do='\0') + 131 at
> > orchestrate.c:304
> > frame #5: 0x00010003b4c8
> > libmoar.dylib`MVM_gc_enter_from_allocator(tc=0x000100500290) +
> > 984 at
> > orchestrate.c:438
> > frame #6: 0x00010003bca8 libmoar.dylib`MVM_gc_allocate_zeroed
> > [inlined] MVM_gc_allocate_nursery(tc=,
> > size=) +
> > 52 at allocation.c:32
> > frame #7: 0x00010003bc74 libmoar.dylib`MVM_gc_allocate_zeroed
> > [inlined] MVM_gc_allocate(tc=) + 23 at allocation.h:13
> > frame #8: 0x00010003bc5d
> > libmoar.dylib`MVM_gc_allocate_zeroed(tc=0x000100500290, size=40)
> > + 13
> > at allocation.c:49
> > frame #9: 0x00010003bf44
> > libmoar.dylib`MVM_gc_allocate_object(tc=0x000100500290,
> > st=) + 84 at allocation.c:86
> > frame #10: 0x00010005813f
> > libmoar.dylib`allocate(tc=,
> > st=) + 15 at P6opaque.c:60
> > frame #11: 0x000100050d27 libmoar.dylib`MVM_repr_box_str
> > [inlined]
> > MVM_repr_alloc_init(tc=0x000100500290, type=0x000101626fc0) +
> > 14 at
> > reprconv.c:13
> > frame #12: 0x000100050d19
> > libmoar.dylib`MVM_repr_box_str(tc=0x000100500290,
> > type=0x000101626fc0, val=) + 73 at reprconv.c:586
> > frame #13: 0x00019c07
> > libmoar.dylib`MVM_exception_backtrace(tc=0x000100500290,
> > ex_obj=) +  at exceptions.c:407
> > frame #14: 0x000100017488
> > libmoar.dylib`MVM_interp_run(tc=0x000100500290,
> > initial_invoke=, invoke_data=) + 47320 at
> > interp.c:3830
> > frame #15: 0x0001000c8305
> > libmoar.dylib`MVM_vm_run_file(instance=,
> > filename=) + 181 at moar.c:304
> > frame #16: 0x0001170a moar`main(argc=,
> > argv=0x7fff5fbff8e8) + 666 at main.c:191
> > frame #17: 0x7fff900c05ad libdyld.dylib`start + 1
> > frame #18: 0x7fff900c05ad libdyld.dylib`start + 1
> > (lldb) fr v
> > (MVMThreadContext *) tc = 0x000100500290
> > (MVMSTable *) st = 0x000101004f40
> > (void *) data = 
> >
> > (MVMGCWorklist *) worklist = 0x00010d27c1a0
> > (MVMCallCaptureBody *) body =  > optimized
> > out>
> >
> > (MVMArgProcContext *) ctx = 0x00010a6f3c00
> > (MVMuint16) flag = 0
> > (MVMuint16) i = 0
> > (MVMuint16) count = 
> >
> > (MVMuint8 *) flag_map = 

[perl #126297] [SEGV] filehandle read in a thead causes a segfault when the thread ends

[Jan-Olof Hendig via RT]

On Sat, 10 Oct 2015 06:03:52 -0700, nicholas wrote:
> On Thu, Oct 08, 2015 at 05:43:11AM -0700, Carlin Bingham wrote:
> 
> > Doesn't seem to happen if the main program thread is still running
> > when
> > the thread exits.
> >
> >
> > use v6;
> >
> > Thread.start({
> > my $fh = open('/dev/urandom');
> > say $fh.read(16);
> > say "alive";
> > });
> >
> > say "main program ending";
> 
> ASAN suggests that it's a "regular" SEGV - ie there are no bad memory
> accesses
> leading up to the crash:
> 
> $ ./perl6-m -Ilib 126297
> main program ending
> Buf[uint8]:0x<76 35 16 81 97 9f 8c 3f 77 f7 d4 02 00 ff bb 47>
> alive
> ASAN:SIGSEGV
> =
> ==17783==ERROR: AddressSanitizer: SEGV on unknown address
> 0x (pc 0x7fc605dfa929 sp 0x7fff1a3952e0 bp 0x7fff1a395310
> T0)
> #0 0x7fc605dfa928 in MVM_gc_root_add_temps_to_worklist
> src/gc/roots.c:171
> #1 0x7fc605dff068 in MVM_gc_collect src/gc/collect.c:103
> #2 0x7fc605df36fa in run_gc src/gc/orchestrate.c:292
> #3 0x7fc605df404f in MVM_gc_enter_from_allocator
> src/gc/orchestrate.c:427
> #4 0x7fc605da9ab7 in try_join src/core/threads.c:156
> #5 0x7fc605daa136 in MVM_thread_join_foreground
> src/core/threads.c:243
> #6 0x7fc605fd01e9 in MVM_vm_exit src/moar.c:263
> #7 0x401a82 in main src/main.c:198
> #8 0x7fc605563d5c in __libc_start_main (/lib64/libc.so.6+0x1ed5c)
> #9 0x401058 (/home/nicholas/Sandpit/moar-san/bin/moar+0x401058)
> 
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV src/gc/roots.c:171
> MVM_gc_root_add_temps_to_worklist
> ==17783==ABORTING
> 
> Nicholas Clark

Fixed as part of jnthn's reframe work in May 2016. Relevant commits are,
AlexDaniel++,
743e7a3dc9a46a2599663e0d448267071831c62c
925336ab25a2e6cd1b6865ce6bbdec97c5be85b8
cebcdd5031c6b6c6e866beee4b52a6a2fd23fcaa
260d5bd2ddd453c31a9e4f2cc9dc0c53bbdd5eea
8b6a4f1fc85846d8d017686a79257b88b165943e
1100877064943356599966c0a241a09b73c99b16

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

[Jan-Olof Hendig via RT]

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 #127011] [LTA] bad error when initialising Int var to Inf or NaN

[Jan-Olof Hendig via RT]

Duplicate of #126990 which has been resolved.

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

[Jan-Olof Hendig via RT]

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 #126563] [BUG] 'X' meta-operator fails with RHS input from parenthesized output of another 'X'

[Jan-Olof Hendig via RT]

On Wed, 04 Nov 2015 12:43:18 -0800, dhoek...@gmail.com wrote:
> In perl6 version 2015.10-158-gbccb16d built on MoarVM version
> 2015.10-46-g5bf7e46:
> 
> Looking at the code for Hamming numbers at Rosetta Code found this problem:
> 
> my @z = <1 2>;
> say  @z X*  @z  X* @z;# OK
> say (@z X*  @z) X* @z;# OK
> say  @z X* (@z  X* @z).Array; # OK
> say  @z X* (@z  X* @z);  # fails
> 
> (1 2 2 4 2 4 4 8)
> (1 2 2 4 2 4 4 8)
> (1 2 2 4 2 4 4 8)
> ===SORRY!===
> Cannot invoke this object (REPR: Uninstantiable)
> 
> Likewise fails for other arithmetic operations (+, -, /, **), as well as:
> 
> my @y = ;
> say  @y X~ (@y  X~ @y);  # fails
> 
> But ','  works with both @x and @y.

This was fixed with commit a26f51361bfea213fa59749d7a401e09c8f2ef31. Tests 
needed.

[perl #128895] [BUG] $*ARGFILES.words does not fallback to $*IN

[Jan-Olof Hendig via RT]

On Thu, 11 Aug 2016 00:41:39 -0700, elizabeth wrote:
> FWIW, this was fixed with the work on IO::CatHandle/CatPath
> (630a9b20f9e829bf1535 and later).  Unfortunately, we had to revert
> this until 6.d will come around.
> 
> > On 11 Aug 2016, at 01:42, Wenzel Peppmeyer (via RT)  > follo...@perl.org> wrote:
> >
> > # New Ticket Created by  Wenzel Peppmeyer
> > # Please include the string:  [perl #128895]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=128895 >
> >
> >
> > perl6 -e 'say $*ARGFILES.words'
> > # OUTPUT:
> > # read string requires an object with REPR MVMOSHandle
> > #  in block  at -e line 1
> >
> > # expected the same as $*ARGFILES.lines (falls back to $*IN)

This has been fixed by Zoffix++ as part of his IO-grant.
Full test coverage is available in roast for IO::CatHandle.
See https://irclog.perlgeek.de/perl6-dev/2018-03-06#i_15892238

[perl #122951] [BUG] negative lookahead doesn't LTM properly

[Jan-Olof Hendig via RT]

On Sat, 11 Oct 2014 05:05:48 -0700, pmichaud wrote:
> 11:55  r:  say "abcde" ~~ / ab  cde | ab.. /   # LTM
> fail
> 11:55  rakudo-{parrot,moar} fd017a: OUTPUT«｢abcd｣␤␤»
> 
> Correct should be "abcde", since he first alternation has a longer
> token to be matched.
> 
> Per S05:2887:
> 
> [...] So LTM completely ignores negative lookaheads, and
> continues to look for pure patterns in whatever follows the negative
> lookahead.  You might say that positive lookaheads are opaque to LTM,
> but negative lookaheads are transparent to LTM.
> 
> Pm

Still broken in Rakudo version 2018.02-12-ge3c4db732 built on MoarVM version 
2018.02

dogbert@dogbert-VirtualBox ~ $ perl6 -e 'say "abcde" ~~ / ab  cde | ab.. 
/ '
｢abcd｣

[perl #126423] [BUG] `if` block with slurpy parameter does not receive argument

[Jan-Olof Hendig via RT]

On Fri, 20 May 2016 14:34:25 -0700, sml...@gmail.com wrote:
> Happens with an explicitly declared slurpy, too - regardless of its name:
> 
> for 42 -> *@a { say @a };  [42]
> if  42 -> *@a { say @a };  []
> 
> ---
> (This is Rakudo version 2016.04-210-gc59e4dc built on MoarVM version 2016.05
> implementing Perl 6.c.)

Fixed by Zoffix++:

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

Test: https://github.com/perl6/roast/commit/aa90737df1

[perl #126703] Typed Shaped Arrays can't be initialized

[Jan-Olof Hendig via RT]

On Sat, 21 Nov 2015 06:48:27 -0800, timo wrote:
> Reproducing test:
> 
> my @a[3;3] = , , ; say @a; # works
> my Str @a[3;3] = , , ; say @a; # fails
> 
> 153852 jnthn │ m: say ((0 xx 10) xx 10).WHAT
> 153852  +camelia │ rakudo-moar : OUTPUT«(List)␤»
> 153857 jnthn │ Curious...
> 153933  timotimo │ how do you initialize the lists in your multidim 
> tests? :)
> 153935 jnthn │ Curious...I'd kinda have expected that to be a Seq...
> 153955 jnthn │ m: my @a[3;3] = , , ; say @a
> 153956  +camelia │ rakudo-moar : OUTPUT«[[a b c] [d e f] [g h i]]␤»
> 154002  timotimo │ mhh
> 154003 jnthn │ m: my @a[3;3] =  xx 3; say @a
> 154004  +camelia │ rakudo-moar : OUTPUT«[[a b c] [a b c] [a b c]]␤»
> 154014  timotimo │ m: my Str @a[3;3] = , , ; say @a
> 154014  +camelia │ rakudo-moar : OUTPUT«Type check failed in assignment 
> to ; expected Str but got List␤  in block
>   │  at /tmp/XObUYCKoZZ:1␤␤»
> 154023 jnthn │ m: my @a[3;3] = ('a' xx 3) xx 3; say @a
> 154023  +camelia │ rakudo-moar : OUTPUT«[[a a a] [a a a] [a a a]]␤»
> 154032 jnthn │ Oh...
> 154037  timotimo │ it's really the type annotation; the type check seems 
> to happen in a/the wrong place
> 154047 jnthn │ Yes, looks like it.
> 

Fixed with commit 131367c7daa89d. Test needed.

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

[Jan-Olof Hendig via RT]

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.

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

[Jan-Olof Hendig via RT]

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 #130327] MoarVM panic: Collectable 0x2aba12277918 in fromspace accessed

[Jan-Olof Hendig via RT]

On Mon, 12 Dec 2016 06:32:20 -0800, c...@zoffix.com wrote:
> Shows up in doc builds: https://travis-
> ci.org/perl6/doc/builds/183248892#L1224
> 
> https://irclog.perlgeek.de/perl6/2016-12-12#i_13726254
> 
> 14:30   jnthn   The message does indicate a legit bug, but yes, the
> (harmless, just not cheap) check should not have been compiled in by
> default.
> 14:30   forgot that one macro was not conditionally defined
> 14:31   Please file me an RT about it

I suspect that this should be closed. All checks of the kind described above 
are (now) conditional, i.e. dependent on the setting of the MVM_GC_DEBUG flag 
in MoarVM. 

[perl #131813] Segfault with --profile

[Jan-Olof Hendig via RT]

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 #132043] [IO] When IO::Notification is watching a file, the `path` attribute doubles the filename

[Jan-Olof Hendig via RT]

On Wed, 06 Sep 2017 16:08:08 -0700, c...@zoffix.com wrote:
> IRC: https://irclog.perlgeek.de/perl6/2017-09-06#i_15127587
> 
> Steps to repro. Create a file named "foo.p6" then run the following
> watcher in the directory and edit that file.
> The nofication reports a change in "foo.p6/foo.p6" instead of just
> "./foo.p6"
> 
> zoffix@VirtualBox/tmp/tmp.ckoExUdCEj$ perl6 -e 'react { whenever
> "foo.p6".IO.watch { dd $^file } }'
> IO::Notification::Change $file = IO::Notification::Change.new(path =>
> "/tmp/tmp.ckoExUdCEj/foo.p6/foo.p6", event =>
> FileChangeEvent::FileChanged)
> IO::Notification::Change $file = IO::Notification::Change.new(path =>
> "/tmp/tmp.ckoExUdCEj/foo.p6/foo.p6", event =>
> FileChangeEvent::FileChanged)
> ^C
> zoffix@VirtualBox/tmp/tmp.ckoExUdCEj$

Seems to have been fixed at some point. Tested the example code, with 'Rakudo 
version 2017.12-124-g6a6470f9d built on MoarVM version 2017.12-20-g571034087', 
and the filename only shows up once.

[perl #127973] [BUG] native strings not allowed to be as big as regular strings

[Jan-Olof Hendig via RT]

On my 32 bit Linux VM:

dogbert@dogbert-VirtualBox ~ $ perl6 -v
This is Rakudo version 2017.09-348-g830084430 built on MoarVM version 
2017.09.1-575-gd4e230a69
implementing Perl 6.c.
dogbert@dogbert-VirtualBox ~ $ time perl6 -e 'my str $a = "a" x 2**30; say 
$a.chars'
1073741824

real0m0.173s
user0m0.176s
sys 0m0.032s

Seems plenty fast.

[perl #127145] [BUG] explicitly-manage is doing something un thread-safe apparently

[Jan-Olof Hendig via RT]

This seems to have been fixed as far as I can tell. Unfortunately the bisectbot 
was unable to show which commit might have solved the issue.
Tried it several times on my 32 bit Linux VM with 'Rakudo version 
2017.09-348-g830084430 built on MoarVM version 2017.09.1-575-gd4e230a69' 
without any problems.

[perl #114124] open () error message is [LTA]

[Jan-Olof Hendig via RT]

Message still looks fine with 
'This is Rakudo version 2017.09-348-g830084430 built on MoarVM version 
2017.09.1-575-gd4e230a69'
perhaps this ticket should be closed.

[perl #127865] Throwing a control exception within Lock.protect causes [LTA] locking behavior

[Jan-Olof Hendig via RT]

Seems to work fine, on my 32 bit VM, with 'This is Rakudo version 
2017.09-348-g830084430 built on MoarVM version 2017.09.1-575-gd4e230a69'

[perl #126415] [BUG] WhateverCode loses its mind inside //=

[Jan-Olof Hendig via RT]

This seems to have been fixed with commit 
https://github.com/rakudo/rakudo/commit/d1c2e7649884a48a4733666c1425d8dcb4918120.
 There were tests added at the same time, i.e. 
https://github.com/perl6/roast/commit/e797f925515ac93f814fa34b6eef291a05fe8a46 
but I'm unsure if those tests cover this RT. If they do then this ticket can 
probably be marked as resolved.

[perl #125170] [BUG] Cannot read from a file opened with open(:rw) in Rakudo

[Jan-Olof Hendig via RT]

This was fixed ages ago which can be verified with

c: releases my $f = open("/tmp/dasdasdasdastest.txt", :r, :w); 
$f.write("hello".encode); $f.seek(0); say $f.read(5).decode

also, tests are present in t/spec/S32-io/open.t. Setting to resolved.

[perl #131375] [BUG] error initializing large array on Windows (64-bit)

[Jan-Olof Hendig via RT]

On Thu, 24 Aug 2017 08:14:07 -0700, ug...@cpan.org wrote:
> Largest I can initialize is 16777216.
> 
> https://stackoverflow.com/questions/12596695/why-does-a-float-
> variable-stop-incrementing-at-16777216-in-c

Should be fixed with commit 
https://github.com/MoarVM/MoarVM/commit/f9b65a9e37979ab39fd1283a65ad4e1351ca6058

[perl #129812] [OPTIMIZER] `is rw` candidates get called even if a non-rw argument is passed

[Jan-Olof Hendig via RT]

On Wed, 05 Oct 2016 14:23:57 -0700, c...@zoffix.com wrote:
> 
> This code shows the bug:
> 
>  zoffix@leliana:~$ perl6 -e 'm: multi foo ($) {"right" }; multi  
> foo ($ is rw) {"wrong"}; say foo "42"'
>  wrong
> 
> And if we turn off the optimizer, we get the right candidate called  
> (same would happen if we add more complex sub bodies, so possibly the  
> sub gets inlined):
> 
>  zoffix@leliana:~$ perl6 --optimize=off -e 'm: multi foo ($)  
> {"right" }; multi foo ($ is rw) {"wrong"}; say foo "42"'
>  right
> 

It would seem that this bug was fixed with 
https://github.com/rakudo/rakudo/commit/f8b3469439108fead043bab2bd27bde4bac50dca
Test(s) needed

[perl #127144] Native uint doesn't overflow on ++

[Jan-Olof Hendig via RT]

On Fri, 07 Apr 2017 19:16:17 -0700, alex.jakime...@gmail.com wrote:
> This no longer prints 256.
> 
> Bisectable points to
> https://github.com/rakudo/rakudo/commit/5401a1aa8f12c360ccd3e4000dcdc65ad98c746a
> 
> Is it actually resolved or not?
> 
> I will mark it testneeded for now (if it's not resolved, the tests
> should
> reveal it).
> 
> On 2016-01-04 04:14:49, FROGGS.de wrote:
> > That highlights the bug:
> >
> > m: my uint8 $x = 255; print $x, " -> "; $x = $x + 1; say $x;
> > rakudo-moar 0f26ae: OUTPUT«255 -> 0␤»
> >
> > m: my uint8 $x = 255; print $x, " -> "; $x++; say $x;
> > rakudo-moar 0f26ae: OUTPUT«255 -> 256␤»
> >
> > Am 04.01.2016 um 11:48 schrieb Elizabeth Mattijsen:
> > >> On 04 Jan 2016, at 00:25, Juerd Waalboer (via RT)  > >> follo...@perl.org> wrote:
> > >>
> > >> # New Ticket Created by Juerd Waalboer
> > >> # Please include the string: [perl #127144]
> > >> # in the subject line of all future correspondence about this
> > >> issue.
> > >> # https://rt.perl.org/Ticket/Display.html?id=127144 >
> > >>
> > >>
> > >> Bug:
> > >>
> > >>> my uint8 $x = 255; print $x, " -> "; $x = $x + 1; say $x;
> > >> 255 -> 0
> > > What is the bug here??? Looks to me it’s entirely doing what is
> > > expected?
> > >
> > >
> > >
> > > Liz

Turns out the the tests listed above where added to roast with 
https://github.com/perl6/roast/commit/c824a98985b739f2a0fa03aa144f2d7c7fb3606c
Closing issue

[perl #127845] [BUG] Making a parameter of a BUILD submethod a uint8 triggers a bytecode validation error in Rakudo

[Jan-Olof Hendig via RT]

On Wed, 06 Apr 2016 01:30:45 -0700, masak wrote:
>  m: class A { has uint8 $.x; submethod BUILD(:$!x) { } };
> A.new(:x(5)).perl.say # but..?
>  rakudo-moar c8ec5a: OUTPUT«Cannot modify an immutable uint8␤
>  in submethod BUILD [...]»
>  m: class A { has uint8 $.x; submethod BUILD(uint8 :$!x) { }
> }; A.new(:x(5)).perl.say
>  rakudo-moar c8ec5a: OUTPUT«Bytecode validation error at
> offset 102 [...]»
>  psch: I think the problem is that argument binding is
> *binding*, and you cannot bind to natively typed containers
>  or something along those lines
>  of course, that's LTA :/
>  especially with the roundabout binding hidden in the submethod
> invocation
>  that's gonna be a fun awesome error message to think up... :)
>  well, I'd hope that we can modify the argument binding to
> deal with native attributes properly
>  though I'm not nearly deep enough into the trench to know how
> feasible that is
> * masak submits rakudobug

Fixed with 
https://github.com/rakudo/rakudo/commit/77a2ff13d2828eb36daad9a8ce954173e06413ef.
Tests needed

[perl #126927] [BUG] Spurious warning when trying to smartmatch num64 against Num in Rakudo

[Jan-Olof Hendig via RT]

On Tue, 15 Dec 2015 12:36:13 -0800, steve.mynott+bitc...@gmail.com wrote:
> Bisected to f457007181bb6e2dcb6aefe857f36d648ae38401 

This was fixed with 
https://github.com/rakudo/rakudo/commit/cff3437de58ef36a9a2a84915ee9181643af4348.
Tests needed

[perl #126642] [BUG] UInt:D parameter fails in a multi

[Jan-Olof Hendig via RT]

On Sat, 14 Nov 2015 14:06:52 -0800, grond...@yahoo.fr wrote:
> $ perl6 --version
> This is perl6 version 2015.10-294-gcc1ba30 built on MoarVM version
> 2015.10-92-g0181385
> 
> $ perl6 -e 'multi f(UInt:D $) { say "ok" }; f(1);'
> ===SORRY!===
> Invocant requires an instance of type Int, but a type object was passed.
> Did you forget a .new?
> 
> See also IRC log for this day.

This was fixed with 
https://github.com/rakudo/rakudo/commit/68afa3f1e77862e4b61f9946103047103fff3c2c.
 
I'm not sure if the tests in S12-subset/subtypes.t covers this, if they do then 
this issue should be
closed.

[perl #126825] [BUG]Ambiguous duplicate signature conflict on Complex.round

[Jan-Olof Hendig via RT]

On Sat, 05 Dec 2015 15:35:20 -0800, thundergnat wrote:
> Tests added https://github.com/perl6/roast/commit/c02bf4bc79
> 
> 
> 
> On Sat Dec 05 15:00:52 2015, elizabeth wrote:
> > Fixed with fdec6278bf3dbcfa850a688, tests are still needed
> > 
> > > On 05 Dec 2015, at 22:21, Steve Schulze (via RT)  > > follo...@perl.org> wrote:
> > >
> > > # New Ticket Created by  Steve Schulze
> > > # Please include the string:  [perl #126825]
> > > # in the subject line of all future correspondence about this issue.
> > > # https://rt.perl.org/Ticket/Display.html?id=126825 >
> > >
> > >
> > > The Complex.round method gets an ambiguous signature error when a
> > > scale
> > > is specified.
> > >
> > > $ perl6 -e' say (5.123456789+5.987654321i).round '
> > > 5+6i
> > > $ perl6 -e' say (5.123456789+5.987654321i).round(.01) '
> > > Ambiguous call to 'round'; these signatures all match:
> > > :(Complex:D $: Real $scale, *%_)
> > > :(Complex:D $: Real $scale, *%_)
> > >   in block  at -e:1
> > >
> > >
> 
> 

Looks as if someone just forgot to close this considering that the bug was 
fixed and tests were added.
Closing.

[perl #131241] (Bag|Mix)Hash.values doesn't check validity of assigned values

[Jan-Olof Hendig via RT]

On Tue, 04 Jul 2017 14:52:31 -0700, alex.jakime...@gmail.com wrote:
> The fix for this ticket also fixed
> https://rt.perl.org/Public/Bug/Display.html?id=130366
> 
> However, we couldn't find any tests… are there any? If they, perhaps
> they also
> cover 130366.
> 
> On 2017-05-01 14:31:19, elizabeth wrote:
> > Fixed for the .values case with c1bd844e2752799af8e and
> > 0e0ac2fb8c51a82a0 . But this needs a more thorough fix. To be
> > forthcoming soon!
> >
> > > On 1 May 2017, at 19:28, Elizabeth Mattijsen (via RT)  > > follo...@perl.org> wrote:
> > >
> > > # New Ticket Created by Elizabeth Mattijsen
> > > # Please include the string: [perl #131241]
> > > # in the subject line of all future correspondence about this
> > > issue.
> > > # https://rt.perl.org/Ticket/Display.html?id=131241 >
> > >
> > >
> > >  m: my $b = .BagHash; $_ = 0 for $b.values;
> > > dd $b
> > >  rakudo-moar 1f80db: OUTPUT: «BagHash $b =
> > > ("b"=>0,"a"=>0,"c"=>0).BagHash␤»
> > >  m: my $b = .BagHash; $_ = -1 for
> > > $b.values; dd $b
> > >  rakudo-moar 1f80db: OUTPUT: «BagHash $b = ("b"=>-
> > > 1,"a"=>-1,"c"=>-1).BagHash␤»
> > >  m: my $b = .MixHash; $_ = 0 for $b.values;
> > > dd $b
> > >  rakudo-moar 1f80db: OUTPUT: «MixHash $b =
> > > ("b"=>0,"a"=>0,"c"=>0).MixHash␤»
> > >
> > > All should empty out the BagHash/MixHash.

The tests for 130366 covers part of this RT, The rest can be found in 
https://github.com/perl6/roast/commit/c2718dc4ece330bc3dd303089f4efd1d3d7f2b9d.

Closing issue.

[perl #130366] BagHash/MixHash values don't check for zeroness

[Jan-Olof Hendig via RT]

On Tue, 04 Jul 2017 14:53:26 -0700, alex.jakime...@gmail.com wrote:
> This was resolved together with
> https://rt.perl.org/Ticket/Display.html?id=131241
> 
> Tests needed, maybe. See other ticket for info on this.
> On 2016-12-17 01:42:04, elizabeth wrote:
> > $ 6 'my $b = .BagHash; $_-- for $b.values; dd $b'
> > BagHash $b = ("a"=>0,"c"=>0,"b"=>1,"e"=>0,"f"=>0,"d"=>0).BagHash
> > *SHOULD* be BagHash $b = ("b"=>1).BagHash
> >
> >
> > $ 6 'my $b = .BagHash; .value-- for $b.pairs; dd $b'
> > BagHash $b = ("a"=>0,"c"=>0,"b"=>1,"e"=>0,"f"=>0,"d"=>0).BagHash
> > *SHOULD* be BagHash $b = ("b"=>1).BagHash
> >
> >
> > $ 6 'my $b = .BagHash; $_ = 0 for $b.values; dd $b'
> > BagHash $b = ("a"=>0,"c"=>0,"b"=>0,"e"=>0,"f"=>0,"d"=>0).BagHash
> > *SHOULD* be BagHash $b = ("b"=>1).BagHash
> >
> >
> > Same for MixHash. Baggy/Mixy need to have the equivalent logic to
> > ISINSET from SetHash.
> >
> >
> > RTing this so it won’t fall through the cracks.

Tests added in 
https://github.com/perl6/roast/commit/75ee890be2f778b7bec19477f83bdcd0ef0893a8. 
Closing issue.

[perl #128624] Buf initialization error

[Jan-Olof Hendig via RT]

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

The above works since 
https://github.com/rakudo/rakudo/commit/242baf256a210f1cb643cb6324916dbc76184c9f.
 
Note however that the fix is marked as 'temporary', i.e. a workaround.

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

[Jan-Olof Hendig via RT]

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

Also, the original problem has been 'temporarily' solved with 
https://github.com/rakudo/rakudo/commit/242baf256a210f1cb643cb6324916dbc76184c9f

[perl #130883] problem with RESOURCES and PERL6LIB env variable

[Jan-Olof Hendig via RT]

On Sat, 15 Jul 2017 09:44:28 -0700, jan-olof.hen...@bredband.net wrote:
> On Mon, 27 Feb 2017 06:55:46 -0800, mt1...@gmail.com wrote:
> > Hi,
> >
> > In  Rakudo version 2017.02-56-g9f10434 built on MoarVM version
> > 2017.02-7-g3d85900
> > implementing Perl 6.c I observed the following;
> >
> > Assume that a distribution is at /x/y (on Unix) then;
> >
> > 1) when no environment variable PERL6LIB is set, the modules from the
> > /x/y/lib directory can not be found. This is normal.
> >
> > 2) when PERL6LIB is set to the empty string, suddenly it is able to
> > find
> > the modules. This is not ok. this is the same when a dot is in the
> > string ('.'), to find modules in the current directory. What also
> > happens is that the path to the resource is calculated wrong. Assume
> > /x/y/resources/a.b, %?RESOURCES returns /x/resources/a.b missing
> > the /y. When the bowels of the %?RESOURCES are displayed, the repo
> > key
> > misses the '/lib' at the end of its repository path.
> >
> > 3) when 'lib' is used in the PERL6LIB variable all is fine.
> >
> >
> > I was in the habit of using the string '.,lib' until perl6 choose the
> > dot over the 'lib' part and got faulty RESOURCES results in one of my
> > repositories.
> >
> > Thanks,
> > Marcel
> 
> A test for the PERL6LIB problem was added with
> https://github.com/perl6/roast/commit/10cf641e28dd7ba970082b36ece2ed2519fcf3a9

Also, the test was added because the PERL6LIB problem had been resolved 
(https://github.com/rakudo/rakudo/commit/075ddefa9b9366c0610632802eaf3c6fc9a6029f).

[perl #130883] problem with RESOURCES and PERL6LIB env variable

[Jan-Olof Hendig via RT]

On Mon, 27 Feb 2017 06:55:46 -0800, mt1...@gmail.com wrote:
> Hi,
> 
> In  Rakudo version 2017.02-56-g9f10434 built on MoarVM version 
> 2017.02-7-g3d85900
> implementing Perl 6.c I observed the following;
> 
> Assume that a distribution is at /x/y (on Unix) then;
> 
> 1) when no environment variable PERL6LIB is set, the modules from the 
> /x/y/lib directory can not be found. This is normal.
> 
> 2) when PERL6LIB is set to the empty string, suddenly it is able to find 
> the modules. This is not ok. this is the same when a dot is in the 
> string ('.'), to find modules in the current directory. What also 
> happens is that the path to the resource is calculated wrong. Assume 
> /x/y/resources/a.b, %?RESOURCES returns /x/resources/a.b missing 
> the /y. When the bowels of the %?RESOURCES are displayed, the repo key 
> misses the '/lib' at the end of its repository path.
> 
> 3) when 'lib' is used in the PERL6LIB variable all is fine.
> 
> 
> I was in the habit of using the string '.,lib' until perl6 choose the 
> dot over the 'lib' part and got faulty RESOURCES results in one of my 
> repositories.
> 
> Thanks,
> Marcel

A test for the PERL6LIB problem was added with 
https://github.com/perl6/roast/commit/10cf641e28dd7ba970082b36ece2ed2519fcf3a9

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

[Jan-Olof Hendig via RT]

On Tue, 31 Jan 2017 09:05:52 -0800, c...@zoffix.com wrote:
> I dug at this bug a few months back, but lost my notes on my findings.
> 
> As I recall it, the 128655 happens in BOOTSTRAP.nqp in
> find_best_dispatchee() the non-native candidate ends up being first in
> the list and that's why it's used instead of native candidates.
> 
> I then went and wrote down the new rules for dispatch that would avoid
> that: https://rt.perl.org/Ticket/Display.html?id=129844
> 
> Then jnthn++ explained (https://irclog.perlgeek.de/perl6-dev/2016-10-
> 25#i_13462673 ) that I misunderstood the auto[un]boxing behaviour of
> natives, so the new rules are out of the window. But that's where my
> journey ended and never re-examined this ticket with my new
> understanding of boxing.

It turns out that he part reported 'on behalf of dogbert17', se above, 
describes a
different problem which was fixed with 
https://github.com/rakudo/rakudo/commit/c98b3a581f481756234758e474c255414a340c97

[perl #130404] [OPTIMIZER] || with native int returns "1" instead of the int's value

[Jan-Olof Hendig via RT]

On Sun, 25 Dec 2016 09:50:17 -0800, c...@zoffix.com wrote:
> zoffix@VirtualBox:~$ perl6 -e 'my int $x = 4; say $x || 2'
> 1
> zoffix@VirtualBox:~$ perl6 --optimize=off -e 'my int $x = 4; say $x ||
> 2'
> 4
> zoffix@VirtualBox:~$ perl6 -v
> This is Rakudo version 2016.11-182-gea28845 built on MoarVM version
> 2016.11-41-gd2139b5
> implementing Perl 6.c.
> zoffix@VirtualBox:~$
> 
> 
> There's a pretty good chance that the optimizer evaluates the
> statement and encounters NQP bug involving ||:
> https://github.com/perl6/nqp/issues/332

Looks as if Zoffix fixed this with 
https://github.com/rakudo/rakudo/commit/83e157012da83e32b10d3739800cdc09e2287db1

[perl #127951] Probably removing a p6bool where it shouldn't

[Jan-Olof Hendig via RT]

On Fri, 14 Jul 2017 13:31:42 -0700, jan-olof.hen...@bredband.net wrote:
> On Fri, 07 Oct 2016 14:03:39 -0700, barto...@gmx.de wrote:
> > I think the p6bool is removed here:
> > https://github.com/rakudo/rakudo/blob/605f272881a76f0c5a9e352670a1e61eaa627ca6/src/Perl6/Optimizer.nqp#L1300
> >
> > As far as I understand, the following code shows the problem at a
> > lower level (no differentiation between optimize=(1|2) required -- it
> > happens on all levels):
> >
> > $ ./perl6-m --optimize=off -e 'use nqp; say
> > nqp::unless(nqp::p6bool(nqp::iseq_i(42,42)), False)'
> > True
> >
> > $ ./perl6-m --optimize=0 -e 'use nqp; say
> > nqp::unless(nqp::p6bool(nqp::iseq_i(42,42)), False)'
> > 1
> >
> > I have no idea how it can be fixed, though. Maybe it's not even
> > feasible to do what the comment above the relevant code block
> > promises?
> >
> > # Some ops have first boolean arg, and we may be able to get rid of
> > # a p6bool if there's already an integer result behind it.
> 
> Looks as if this was fixed with
> https://github.com/rakudo/rakudo/commit/f8b3469439108fead043bab2bd27bde4bac50dca.
> Tests needed.

Added in https://github.com/perl6/roast/commit/39802b5b2b. Closing issue.

[perl #127951] Probably removing a p6bool where it shouldn't

[Jan-Olof Hendig via RT]

On Fri, 07 Oct 2016 14:03:39 -0700, barto...@gmx.de wrote:
> I think the p6bool is removed here:
> https://github.com/rakudo/rakudo/blob/605f272881a76f0c5a9e352670a1e61eaa627ca6/src/Perl6/Optimizer.nqp#L1300
> 
> As far as I understand, the following code shows the problem at a
> lower level (no differentiation between optimize=(1|2) required -- it
> happens on all levels):
> 
> $ ./perl6-m --optimize=off -e 'use nqp; say
> nqp::unless(nqp::p6bool(nqp::iseq_i(42,42)), False)'
> True
> 
> $ ./perl6-m --optimize=0 -e 'use nqp; say
> nqp::unless(nqp::p6bool(nqp::iseq_i(42,42)), False)'
> 1
> 
> I have no idea how it can be fixed, though. Maybe it's not even
> feasible to do what the comment above the relevant code block
> promises?
> 
> # Some ops have first boolean arg, and we may be able to get rid of
> # a p6bool if there's already an integer result behind it.

Looks as if this was fixed with 
https://github.com/rakudo/rakudo/commit/f8b3469439108fead043bab2bd27bde4bac50dca.
 Tests needed.

[perl #129247] [CONC][BUG] Wait on a Supply after begin tap is hanging

[Jan-Olof Hendig via RT]

On Thu, 13 Jul 2017 16:49:00 -0700, ug...@cpan.org wrote:
> Resolved in: https://github.com/rakudo/rakudo/commit/32b72cd
> 
> Tests: https://github.com/perl6/roast/commit/927b026

Bug fixed and tests added, closing issue.

[perl #130919] [CONC] Supplier.done is only handled by first tap

[Jan-Olof Hendig via RT]

On Thu, 13 Jul 2017 10:54:27 -0700, ug...@cpan.org wrote:
> Resolved in: https://github.com/rakudo/rakudo/commit/32b72cd
> 
> Tests: https://github.com/perl6/roast/commit/927b026

Closing issue. ugexe++

[perl #128594] [SEGV] attempting to use :merge when run()ning an external command causes a core dump

[Jan-Olof Hendig via RT]

On Wed, 12 Jul 2017 15:30:33 -0700, ug...@cpan.org wrote:
> Resolved in https://github.com/rakudo/rakudo/commit/c86090e
> 
> `perl6 -e 'run("ls", :merge).out.slurp.say'`

Worls on OSX as well. The fudged test was unfudged by ugexe++. Closing issue.

[perl #126923] [BUG] printf %d pads with spaces instead of zeros with precision specifier

[Jan-Olof Hendig via RT]

On Tue, 15 Dec 2015 06:14:03 -0800, b...@abrij.org wrote:
> 
> 
> When the %d directive is given a decimal precision it should pad with
> zeroes, not spaces.
> 
> $ perl6 -e 'printf("%3.3d", 16)'
>  16
> $ perl -e 'printf("%3.3d\n", 16)'
> 016

This was fixed with 
https://github.com/rakudo/rakudo/commit/a1c7d01502249bd8bdae5a70ec85847609ca1aba.
 
Tests were added to t/spec/S32-str/sprintf.t, closing issue.

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

[Jan-Olof Hendig via RT]

On Thu, 25 Aug 2016 07:14:03 -0700, coke wrote:
> On Sat Jul 23 20:47:04 2016, c...@zoffix.com wrote:
> > Not even sure what causes that, but removing the `redo` avoids the
> > error.
> >
> > $ perl6 -e 'react { whenever supply { emit 42; redo } { .say } }'
> > 42
> > No such method 'CALL-ME' for invocant of type 'Bool'
> >   in block  at -e line 1
> >
> >
> 
> Behavior has changed:
> 
> $ perl6 -e 'react { whenever supply { emit 42; redo } { .say } }'
> 42
> Access denied to keep/break this Promise; already vowed
>   in any  at /Users/coke/.rakudobrew/moar-
> 2016.08.1/install/share/perl6/runtime/CORE.setting.moarvm line 1
>   in block  at -e line 1

Running it with a recent version gives the following result

dogbert@dogbert-VirtualBox ~ $ perl6 -e 'react { whenever supply { emit 42; 
redo } { .say } }'
42
===SORRY!===
redo without loop construct

If this message is correct then the original code snippet should never have 
worked in the first place. 
Rejecting issue. Reopen if you think this is a mistake.

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

[Jan-Olof Hendig via RT]

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 #123434] [SEGV] CounterMutexSingleton sample crashes

[Jan-Olof Hendig via RT]

On Thu, 23 Feb 2017 09:01:40 -0800, r...@bastic.net wrote:
> Indeed :) It was just a simple test case to demonstrate some things to
> ab5tract.
> 
> Thanks for your work!
> 
> On Thu, Feb 23, 2017 at 11:53 AM, Timo Paulssen via RT <
> perl6-bugs-follo...@perl.org> wrote:
> 
> > Hi,
> >
> > we've put in an improved error message for when libuv refuses to create an
> > eventloop for us (for example because you've surpassed your allowance of
> > file descriptors).
> >
> > Instead of segfaulting when accessing the NULL it returned instead of the
> > eventloop, we'll throw an exception for you.
> >
> > With the very latest moarvm, behaviour is now this:
> >
> > timo@schmand /tmp> perl6 CounterMutexSingleton.pl6 --num_threads=252
> > 252
> > timo@schmand /tmp> perl6 CounterMutexSingleton.pl6 --num_threads=253
> > Could not create a new Thread.
> >   in sub MAIN at CounterMutexSingleton.pl6 line 76
> >   in block  at CounterMutexSingleton.pl6 line 71
> >
> > Setting the default num_threads to 10 is ... quite optimistic to say
> > the least :)
> >

Closing issue, better late than never.

[perl #130920] [CONC] Tap's closing callback doesn't call back

[Jan-Olof Hendig via RT]

On Wed, 08 Mar 2017 13:25:56 -0800, elizabeth wrote:
> 
> > On 8 Mar 2017, at 18:09, jn...@jnthn.net via RT  > follo...@perl.org> wrote:
> >
> > On Sat, 04 Mar 2017 13:40:22 -0800, c...@zoffix.com wrote:
> >> On Sat, 04 Mar 2017 13:24:08 -0800, comdog wrote:
> >>> This is the example from the Tap docs. I expect the output to be
> >>> "Tap closed", but I get no output using 2017.01:
> >>>
> >>> my $s = Supplier.new;
> >>> my $tap = $s.Supply.tap(
> >>>-> $v { say "the value is $v" },
> >>>done=> { say "Supply is done" },
> >>>closing => { say "Tap closed" },
> >>>quit=> -> $ex { say "Supply finished with error $ex" },
> >>> );
> >>>
> >>> # later
> >>> $tap.close;
> >>
> >>
> >> I don't see `closing` param for that routine:
> >> https://github.com/rakudo/rakudo/blob/b597398/src/core/Supply.pm#L77
> >>
> >> Unless this was missed during pre-Christmas Supplies rework, this
> >> may
> >> be just a doc bug.
> >
> > It's a doc bug (and, yes, probably a left-behind from an earlier
> > design). The correct way is using `on-close`. Example:
> >
> > my $t = Supply.interval(0.5).on-close({ say "bye" }).tap();
> > sleep 3;
> > $t.close
> 
> I wonder whether these “public” functions should handle / warn about
> unknown named parameters being passed.

The docs have been updated in order to reflect current behavior, see for 
example:

https://docs.perl6.org/type/Supply#method_on-close

and

https://docs.perl6.org/type/Tap

Closing issue

[perl #131386] Regression in ().Bag AT-KEY

[Jan-Olof Hendig via RT]

On Sun, 28 May 2017 01:49:06 -0700, elizabeth wrote:
> Thanks for the report!
> 
> Fixed with https://github.com/rakudo/rakudo/commit/87d0e0a39e .  Tests
> needed.
> 
> > On 28 May 2017, at 03:46, hanenkamp (via RT)  > follo...@perl.org> wrote:
> >
> > # New Ticket Created by  hanenkamp
> > # Please include the string:  [perl #131386]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=131386 >
> >
> >
> > See http://colabti.org/irclogger/irclogger_log/perl6?date=2017-05-
> > 27#l799
> >
> > [23:24]  m: my %x := ().Bag; %x
> > [23:24]  rakudo-moar 0c5fe5: OUTPUT: 芦This type (Scalar)
> > does not
> > support associative operations鈵� in block  at  line 1鈵も悿禄
> > [23:25]  that's causing a regression in Hash::MultiValue, but
> > it
> > doesn't feel like a regression in my code but possibly in rakudo?
> > [23:25]  bisect: my %x := ().Bag; %x
> > [23:25]  MasterDuke, Bisecting by exit code (old=2015.12
> > new=0c5fe56). Old exit code: 0
> > [23:25]  MasterDuke, bisect log:
> > https://gist.github.com/d43a9bf6d1445203fa016afc790abbaf
> > [23:25]  MasterDuke, (2017-05-22)
> > https://github.com/rakudo/rakudo/commit/b43db636ab7c0f2bdeab310a86e1c6e96a530437
> > --
> > Sterling Hanenkamp
> > http://sterling.hanenkamp.com/stfl/
> > 785-370-4454

Tests added with 
https://github.com/perl6/roast/commit/e156d2a03d692dfd0e2baa15119575b73df61946. 
Resolving issue.

[perl #131272] .pickpairs .Int-ifes the argument, but .pick doesn't (say ^5 .BagHash.pick(2.5))

[Jan-Olof Hendig via RT]

On Mon, 08 May 2017 11:51:25 -0700, elizabeth wrote:
> Fixed with 31be51284e70badd8ed , tests needed.
> 
> > On 8 May 2017, at 20:25, Aleks-Daniel Jakimenko-Aleksejev (via RT)
> >  wrote:
> >
> > # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev
> > # Please include the string:  [perl #131272]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=131272 >
> >
> >
> > Code:
> > say ^5 .BagHash.pickpairs(2.5);
> >
> > Result:
> > (1 => 1 4 => 1)
> >
> >
> > Code:
> > say ^5 .BagHash.pick(2.5);
> >
> > Result:
> > count computed to 2.5, which cannot be used
> >  in block  at  line 1
> >
> >
> > I find it impossible to predict when non-Int args are alright and
> > when they are not. I would expect consistency of some sort.
> >
> > (same thing with .grab and .grabpairs)

Tests added with https://github.com/perl6/roast/commit/68d34de4b8. Resolving 
issue.