Re: Is there sn ETA for the next Rakudo* ?

[Elizabeth Mattijsen]

> On 16 Jan 2021, at 00:27, Parrot Raiser <1parr...@gmail.com> wrote:
> I'm setting up a new machine, and I don't want to install something
> I'm going to have to update in a week.

In about a week, we will have a new Rakudo compiler release.  I think the 
Rakudo* people will wait for that.  So I would guess the next release of 
Rakudo* won't be for another 2 weeks or so.

Re: [perl #133762] Quanthashes should be parameterizable

[Elizabeth Mattijsen via RT]

Fixed for Bag/BagHash with https://github.com/rakudo/rakudo/commit/fe38bdba62

Fixed for Mix/MixHash with https://github.com/rakudo/rakudo/commit/bcc8054a4d

> On 13 Jan 2019, at 22:03, Elizabeth Mattijsen via RT 
>  wrote:
> 
> Fixed for Set/SetHash with https://github.com/rakudo/rakudo/commit/4bb5c33c72
> 
>> On 10 Jan 2019, at 18:22, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 (via RT) 
>>  wrote:
>> 
>> # New Ticket Created by  Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 
>> # Please include the string:  [perl #133762]
>> # in the subject line of all future correspondence about this issue. 
>> # https://rt.perl.org/Ticket/Display.html?id=133762 >
>> 
>> 
>> › rpm -qi rakudo | rg Version
>> Version : 2018.12
>> 
>> subset Foo of Str where .chars > 0;
>> my SetHash of Foo %f;
>> %f.elems.say;
>> 
>>   SetHash cannot be parameterized
>> 
>> subset Foo of Str where .chars > 0;
>> subset Foo-SetHash of SetHash where $_ ~~ Foo;
>> my Foo-SetHash $f;
>> $f.elems.say;
>> 
>>   Invocant of method 'elems' must be an object instance of type 'Setty', not 
>> a type object of type 'Foo-SetHash'.  Did you forget a '.new'?
>> 
>> subset Foo of Str where .chars > 0;
>> subset Foo-SetHash of SetHash where $_ ~~ Foo;
>> my $f = Foo-SetHash.new;
>> $f.elems.say;
>> 
>>   You cannot create an instance of this type (Foo-SetHash)

Re: [perl #133762] Quanthashes should be parameterizable

[Elizabeth Mattijsen]

Fixed for Bag/BagHash with https://github.com/rakudo/rakudo/commit/fe38bdba62

Fixed for Mix/MixHash with https://github.com/rakudo/rakudo/commit/bcc8054a4d

> On 13 Jan 2019, at 22:03, Elizabeth Mattijsen via RT 
>  wrote:
> 
> Fixed for Set/SetHash with https://github.com/rakudo/rakudo/commit/4bb5c33c72
> 
>> On 10 Jan 2019, at 18:22, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 (via RT) 
>>  wrote:
>> 
>> # New Ticket Created by  Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 
>> # Please include the string:  [perl #133762]
>> # in the subject line of all future correspondence about this issue. 
>> # https://rt.perl.org/Ticket/Display.html?id=133762 >
>> 
>> 
>> › rpm -qi rakudo | rg Version
>> Version : 2018.12
>> 
>> subset Foo of Str where .chars > 0;
>> my SetHash of Foo %f;
>> %f.elems.say;
>> 
>>   SetHash cannot be parameterized
>> 
>> subset Foo of Str where .chars > 0;
>> subset Foo-SetHash of SetHash where $_ ~~ Foo;
>> my Foo-SetHash $f;
>> $f.elems.say;
>> 
>>   Invocant of method 'elems' must be an object instance of type 'Setty', not 
>> a type object of type 'Foo-SetHash'.  Did you forget a '.new'?
>> 
>> subset Foo of Str where .chars > 0;
>> subset Foo-SetHash of SetHash where $_ ~~ Foo;
>> my $f = Foo-SetHash.new;
>> $f.elems.say;
>> 
>>   You cannot create an instance of this type (Foo-SetHash)

Re: [perl #133762] Quanthashes should be parameterizable

[Elizabeth Mattijsen]

Fixed for Set/SetHash with https://github.com/rakudo/rakudo/commit/4bb5c33c72

> On 10 Jan 2019, at 18:22, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 (via RT) 
>  wrote:
> 
> # New Ticket Created by  Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 
> # Please include the string:  [perl #133762]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=133762 >
> 
> 
> › rpm -qi rakudo | rg Version
> Version : 2018.12
> 
> subset Foo of Str where .chars > 0;
> my SetHash of Foo %f;
> %f.elems.say;
> 
>SetHash cannot be parameterized
> 
> subset Foo of Str where .chars > 0;
> subset Foo-SetHash of SetHash where $_ ~~ Foo;
> my Foo-SetHash $f;
> $f.elems.say;
> 
>Invocant of method 'elems' must be an object instance of type 'Setty', not 
> a type object of type 'Foo-SetHash'.  Did you forget a '.new'?
> 
> subset Foo of Str where .chars > 0;
> subset Foo-SetHash of SetHash where $_ ~~ Foo;
> my $f = Foo-SetHash.new;
> $f.elems.say;
> 
>You cannot create an instance of this type (Foo-SetHash)

Re: [perl #133762] Quanthashes should be parameterizable

[Elizabeth Mattijsen via RT]

Fixed for Set/SetHash with https://github.com/rakudo/rakudo/commit/4bb5c33c72

> On 10 Jan 2019, at 18:22, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 (via RT) 
>  wrote:
> 
> # New Ticket Created by  Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 
> # Please include the string:  [perl #133762]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=133762 >
> 
> 
> › rpm -qi rakudo | rg Version
> Version : 2018.12
> 
> subset Foo of Str where .chars > 0;
> my SetHash of Foo %f;
> %f.elems.say;
> 
>SetHash cannot be parameterized
> 
> subset Foo of Str where .chars > 0;
> subset Foo-SetHash of SetHash where $_ ~~ Foo;
> my Foo-SetHash $f;
> $f.elems.say;
> 
>Invocant of method 'elems' must be an object instance of type 'Setty', not 
> a type object of type 'Foo-SetHash'.  Did you forget a '.new'?
> 
> subset Foo of Str where .chars > 0;
> subset Foo-SetHash of SetHash where $_ ~~ Foo;
> my $f = Foo-SetHash.new;
> $f.elems.say;
> 
>You cannot create an instance of this type (Foo-SetHash)

Re: [perl #131599] [RFC] Allow a Callable for `is default` that will generate default values

[Elizabeth Mattijsen]

FWIW, with:

http://modules.perl6.org/dist/Hash::Restricted:cpan:ELIZABETH

one can restrict access to a hash to a certain set of keys:

use Hash::Restricted;

my %h is restricted = a => 42, b => 666;  # restrict to keys at initialization

my %h is restricted;  # restrict to keys a, b, c


> On 18 Jul 2018, at 17:32, Alastair Douglas via RT 
>  wrote:
> 
> On Mon, 19 Jun 2017 09:30:41 -0700, brad wrote:
>> The way Moose in Perl 5 works around this is to give it a subroutine
> 
>> there currently isn't as far as I know, a way to do what you intended.
> 
> I'd like this feature as well. I was in IRC asking about whether we could 
> restrict a hash in the same way python does, such that %hash 
> dies.
> 
> It was noted that one can do
> 
>  my %h is default(Failure.new);
> 
> This would put a Failure in anything that didn't exist, which would detonate 
> whenever accessed. Presumably, this would be the same Failure each time, but 
> that's probably OK.
> 
> It means there is no way of generating a default based on access. I think 
> that would look something like:
> 
>  my %h is default(-> $key { Failure.new("$key not provided") });
> 
> But then how would it know to run the Callable to generate the default, 
> rather than simply providing the Callable as the default? I have no answer 
> for that.

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

[Elizabeth Mattijsen via RT]

The problem is actually caused by the error reporting:

 
https://github.com/rakudo/rakudo/blob/08b951c8f33cfc702c308e64efcb44f3ec725117/src/core/Exception.pm6#L2969

The only heuristic I’ve been able to find so far that the value of $ns{$_} 
suddenly is no longer fully qualified if the namespace doesn’t exist.  I guess 
we can build some heuristic check on that, but it feels fragile.  Perhaps nine 
/ ugexe / jnthn have a better idea about that.

> On 13 Apr 2018, at 08:34, Martin Barth (via RT) 
>  wrote:
> 
> # New Ticket Created by  Martin Barth 
> # Please include the string:  [perl #133107]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=133107 >
> 
> 
> requireing a non installed module leads to strange error if the name 
> starts with the name of a core module. e.g:
> 
> 
>> perl6 -e 'require IO::Socket::Async::SSL'
> IO::Socket::Async::SSL is a builtin type, not an external module
>   in block  at -e line 1

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

[Elizabeth Mattijsen]

The problem is actually caused by the error reporting:

 
https://github.com/rakudo/rakudo/blob/08b951c8f33cfc702c308e64efcb44f3ec725117/src/core/Exception.pm6#L2969

The only heuristic I’ve been able to find so far that the value of $ns{$_} 
suddenly is no longer fully qualified if the namespace doesn’t exist.  I guess 
we can build some heuristic check on that, but it feels fragile.  Perhaps nine 
/ ugexe / jnthn have a better idea about that.

> On 13 Apr 2018, at 08:34, Martin Barth (via RT) 
>  wrote:
> 
> # New Ticket Created by  Martin Barth 
> # Please include the string:  [perl #133107]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=133107 >
> 
> 
> requireing a non installed module leads to strange error if the name 
> starts with the name of a core module. e.g:
> 
> 
>> perl6 -e 'require IO::Socket::Async::SSL'
> IO::Socket::Async::SSL is a builtin type, not an external module
>   in block  at -e line 1

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

[Elizabeth Mattijsen via RT]

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

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

[Elizabeth Mattijsen]

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

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

[Elizabeth Mattijsen]

yes, this can be rejected.  Unfortunately I don’t do RT so someone else will 
need to do that.

> On 13 Oct 2017, at 13:48, Aleks-Daniel Jakimenko-Aleksejev 
> <alex.jakime...@gmail.com> wrote:
> 
> Oh. I guess this has to be rejected then.
> 
> On Fri, Oct 13, 2017 at 2:46 PM, Elizabeth Mattijsen <l...@dijkmat.nl> wrote:
> 
> > On 13 Oct 2017, at 07:37, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
> > <perl6-bugs-follo...@perl.org> wrote:
> >
> > # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev
> > # Please include the string:  [perl #132281]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=132281 >
> >
> >
> > Code:
> > say "blogger".comb.Bag # if you want for all the letters
> >
> > ¦«2015.12»:
> > bag(r, l, g(2), b, e, o)
> >
> > ¦«2016.06»:
> > bag(r, l, g(2), b, e, o)
> >
> > ¦«2016.12»:
> > bag(r, l, g(2), b, e, o)
> >
> > ¦«2017.06»:
> > bag(e, l, b, g(2), o, r)
> >
> > ¦«f72be0f130cf»:
> > Bag(b, e, g(2), l, o, r)
> >
> >
> > Possible IRC discussion: 
> > https://irclog.perlgeek.de/perl6/2017-10-09#i_15278073
> >
> >
> > Bisectable: (2017-07-20) 
> > https://github.com/rakudo/rakudo/commit/21b9a720c75656b13805611544aa5ee64c4924ae
> >
> >
> > To be honest, I don't know if that's a reasonable ticket. I guess it 
> > doesn't really matter if it's bag or Bag, but I'm pretty sure that the 
> > change was unintentional so I'm submitting it as a ticket.
> >
> > Maybe “bag()” is better because it resembles an actual syntax. Kind of. 
> > Judge yourself.
> 
> The two are *not* the same.  Bag(foo) is the same as foo.Bag.  Which implies 
> taking all values as is.  Whereas bag() implies looking at the values in the 
> same way as “.new-from-pairs”.  Observe:
> 
> $ 6 'dd bag({a => 42}); dd Bag({ a => 42 })'
> (:a(42)).Bag
> ("a"=>42).Bag
> 

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

[Elizabeth Mattijsen via RT]

That does indeed look wrong to me, investigating

> On 23 Mar 2018, at 15:04, Nick Wellnhofer (via RT) 
>  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

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

[Elizabeth Mattijsen]

That does indeed look wrong to me, investigating

> On 23 Mar 2018, at 15:04, Nick Wellnhofer (via RT) 
>  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

Re: [perl #131684] Iterator and Supply might fail early if Nil is sent on a channel

[Elizabeth Mattijsen via RT]

Fixed with https://github.com/rakudo/rakudo/commit/bdd8143e6f, tests needed

> On 1 Jul 2017, at 15:20, Jan-Olof Hendig (via RT) 
>  wrote:
> 
> # New Ticket Created by  Jan-Olof Hendig 
> # Please include the string:  [perl #131684]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131684 >
> 
> 
> This is a vulnerability and should probably be fixed.
> 
> Discussion here: https://irclog.perlgeek.de/perl6-dev/2017-07-01#i_14812827

Re: [perl #131684] Iterator and Supply might fail early if Nil is sent on a channel

[Elizabeth Mattijsen]

Fixed with https://github.com/rakudo/rakudo/commit/bdd8143e6f, tests needed

> On 1 Jul 2017, at 15:20, Jan-Olof Hendig (via RT) 
>  wrote:
> 
> # New Ticket Created by  Jan-Olof Hendig 
> # Please include the string:  [perl #131684]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131684 >
> 
> 
> This is a vulnerability and should probably be fixed.
> 
> Discussion here: https://irclog.perlgeek.de/perl6-dev/2017-07-01#i_14812827

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

[Elizabeth Mattijsen via RT]

I propose we change all onlies in the core to multis after the release and see 
how this breaks things / makes things slower.

> On 16 Feb 2018, at 14:17, Zoffix Znet via RT  
> wrote:
> 
> Spotted another case where there's impact: whether or not a routine is a 
> multi can have large impact on user's code. For example here: 
> https://stackoverflow.com/questions/48819031/where-did-my-perl-6-operator-go-after-i-defined-a-more-specific-multi/48827522
> 
> As part of conventions, we'd need to also figure out what we'll declare as 
> multies and what as onlies.

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

[Elizabeth Mattijsen]

I propose we change all onlies in the core to multis after the release and see 
how this breaks things / makes things slower.

> On 16 Feb 2018, at 14:17, Zoffix Znet via RT  
> wrote:
> 
> Spotted another case where there's impact: whether or not a routine is a 
> multi can have large impact on user's code. For example here: 
> https://stackoverflow.com/questions/48819031/where-did-my-perl-6-operator-go-after-i-defined-a-more-specific-multi/48827522
> 
> As part of conventions, we'd need to also figure out what we'll declare as 
> multies and what as onlies.

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

[Elizabeth Mattijsen via RT]

> On 13 Jan 2018, at 22:38, Curt Tilmes (via RT)  
> wrote:
> 
> # New Ticket Created by  Curt Tilmes 
> # Please include the string:  [perl #132718]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132718 >
> 
> 
>  m: sub foo(int32 $x) { say "ok" if $x }; foo(12);
>  rakudo-moar f25fdbdf0: OUTPUT: «===SORRY!===␤Unhandled kind 3␤»

FWIW, this also happens for int8 and int16 with different Unhandled kind values 
(1 and 2 respectively).

Casual introspection shows that apparently no support for int8, int16 or int32 
has been added at this level.

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

[Elizabeth Mattijsen]

> On 13 Jan 2018, at 22:38, Curt Tilmes (via RT)  
> wrote:
> 
> # New Ticket Created by  Curt Tilmes 
> # Please include the string:  [perl #132718]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132718 >
> 
> 
>  m: sub foo(int32 $x) { say "ok" if $x }; foo(12);
>  rakudo-moar f25fdbdf0: OUTPUT: «===SORRY!===␤Unhandled kind 3␤»

FWIW, this also happens for int8 and int16 with different Unhandled kind values 
(1 and 2 respectively).

Casual introspection shows that apparently no support for int8, int16 or int32 
has been added at this level.

Re: [perl #132549] Can't put() any(): This type cannot unbox to a native string

[Elizabeth Mattijsen via RT]

> On 8 Dec 2017, at 19:21, Zoffix Znet via RT  
> wrote:
> 
> On Fri, 08 Dec 2017 08:28:32 -0800, comdog wrote:
>> This comes from an answer to a Perl 6 question on Stackoverflow that
>> showed a different bug:
>> 
>>https://stackoverflow.com/q/45527881/2766176
>> 
>> With put() it does not and gives a strange error:
> 
> I guess jnthn++ gets a score point for predicting[^1] this would happen:
> 
> Hmmm...not too keen on the Junction.Str patch
> Anything that (quite reasonably) does nqp::unbox_s($foo.Str) is now
>going to (quite rightly) explode
> clearly we have to build UNBOXABLE_STR :)
> No, it can just explode, and then I'll point people at this 
> commit. :P

Which would be me.

And as far as I recall atm, that was in response to making:

  $ 6 'dd "foo" ~ any(1,3,5) ~ "bar"'
  any("foo1bar", "foo3bar", "foo5bar”)

work.  If that shouldn’t work, or work differently, it can be ripped out / 
replaced.  If that should work, then we need to look at fixing -put-.


> If put() were made to work here, I'd expect it to junct and be equivalent to 
> `put 1`, `put 3`, `put 7` executed in random order, but the OP in that SO has 
> an entirely different expectation.

FWIW, I would also expect it to junct.

Re: [perl #132549] Can't put() any(): This type cannot unbox to a native string

[Elizabeth Mattijsen]

> On 8 Dec 2017, at 19:21, Zoffix Znet via RT  
> wrote:
> 
> On Fri, 08 Dec 2017 08:28:32 -0800, comdog wrote:
>> This comes from an answer to a Perl 6 question on Stackoverflow that
>> showed a different bug:
>> 
>>https://stackoverflow.com/q/45527881/2766176
>> 
>> With put() it does not and gives a strange error:
> 
> I guess jnthn++ gets a score point for predicting[^1] this would happen:
> 
> Hmmm...not too keen on the Junction.Str patch
> Anything that (quite reasonably) does nqp::unbox_s($foo.Str) is now
>going to (quite rightly) explode
> clearly we have to build UNBOXABLE_STR :)
> No, it can just explode, and then I'll point people at this 
> commit. :P

Which would be me.

And as far as I recall atm, that was in response to making:

  $ 6 'dd "foo" ~ any(1,3,5) ~ "bar"'
  any("foo1bar", "foo3bar", "foo5bar”)

work.  If that shouldn’t work, or work differently, it can be ripped out / 
replaced.  If that should work, then we need to look at fixing -put-.


> If put() were made to work here, I'd expect it to junct and be equivalent to 
> `put 1`, `put 3`, `put 7` executed in random order, but the OP in that SO has 
> an entirely different expectation.

FWIW, I would also expect it to junct.

Re: [perl #125398] with no strict temp does not autcreate hashes and hash elements

[Elizabeth Mattijsen via RT]

Properly fixed with e5b49ce , tests needed for container type / default value 
of auto-defined
variables.

> On 3 Dec 2017, at 04:45, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> Still reproducible (2017.11,HEAD(e5b660e))
> 
> On 2015-06-13 05:48:13, ronaldxs wrote:
>> From irc
>> 
>> http://irclog.perlgeek.de/perl6/2015-06-13#i_10744864
>> 
>> 12:16 mr_ron m: no strict; %h = 42; {temp %h = 8}
>> 12:16 camelia rakudo-moar af886d: OUTPUT«Type check failed
>> in binding cont; expected 'Any' but got 'Mu'␤ in block  at
>> /tmp/AYhNmfAB9o:1␤␤»
>> 12:17 mr_ron m: no strict; %h = 42;
>> 12:17 camelia rakudo-moar af886d: ( no output )
>> 12:17 mr_ron bug I think
>> 12:19 Ven m: temp %h = 8
>> 12:19 camelia rakudo-moar af886d: OUTPUT«5===SORRY!5===
>> Error while compiling /tmp/3g1OTkzVIM␤Variable '%h' is not declared␤at
>> /tmp/3g1OTkzVIM:1␤--> 3temp 7⏏5%h = 8␤»
>> 12:19 yqt joined #perl6
>> 12:19 Ven m: no strict; temp %h = 8
>> 12:19 camelia rakudo-moar af886d: OUTPUT«Type check failed
>> in binding cont; expected 'Any' but got 'Mu'␤ in block  at
>> /tmp/dvEGWzXNXu:1␤␤»
>> 12:19 Ven m: no strict; (temp %h) = 8
>> 12:19 camelia rakudo-moar af886d: ( no output )
>> 12:19 Ven mr_ron: I think that's the issue :)
>> 12:22 mr_ron Good golf anyway ...

Re: [perl #125398] with no strict temp does not autcreate hashes and hash elements

[Elizabeth Mattijsen]

Properly fixed with e5b49ce , tests needed for container type / default value 
of auto-defined
variables.

> On 3 Dec 2017, at 04:45, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> Still reproducible (2017.11,HEAD(e5b660e))
> 
> On 2015-06-13 05:48:13, ronaldxs wrote:
>> From irc
>> 
>> http://irclog.perlgeek.de/perl6/2015-06-13#i_10744864
>> 
>> 12:16 mr_ron m: no strict; %h = 42; {temp %h = 8}
>> 12:16 camelia rakudo-moar af886d: OUTPUT«Type check failed
>> in binding cont; expected 'Any' but got 'Mu'␤ in block  at
>> /tmp/AYhNmfAB9o:1␤␤»
>> 12:17 mr_ron m: no strict; %h = 42;
>> 12:17 camelia rakudo-moar af886d: ( no output )
>> 12:17 mr_ron bug I think
>> 12:19 Ven m: temp %h = 8
>> 12:19 camelia rakudo-moar af886d: OUTPUT«5===SORRY!5===
>> Error while compiling /tmp/3g1OTkzVIM␤Variable '%h' is not declared␤at
>> /tmp/3g1OTkzVIM:1␤--> 3temp 7⏏5%h = 8␤»
>> 12:19 yqt joined #perl6
>> 12:19 Ven m: no strict; temp %h = 8
>> 12:19 camelia rakudo-moar af886d: OUTPUT«Type check failed
>> in binding cont; expected 'Any' but got 'Mu'␤ in block  at
>> /tmp/dvEGWzXNXu:1␤␤»
>> 12:19 Ven m: no strict; (temp %h) = 8
>> 12:19 camelia rakudo-moar af886d: ( no output )
>> 12:19 Ven mr_ron: I think that's the issue :)
>> 12:22 mr_ron Good golf anyway ...

Re: [perl #125398] with no strict temp does not autcreate hashes and hash elements

[Elizabeth Mattijsen]

The problem with let/temp for this situation has been fixed with 
752299767bac3c49 . And tests are needed for that.

However, the underlying issue is that the default value of container 
descriptors created automatically with “no strict” are Mu rather than Any.  
This will need some deeper research.
Either this ticket should remain open, or we should create another issue for 
this.

> On 3 Dec 2017, at 04:45, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> Still reproducible (2017.11,HEAD(e5b660e))
> 
> On 2015-06-13 05:48:13, ronaldxs wrote:
>> From irc
>> 
>> http://irclog.perlgeek.de/perl6/2015-06-13#i_10744864
>> 
>> 12:16 mr_ron m: no strict; %h = 42; {temp %h = 8}
>> 12:16 camelia rakudo-moar af886d: OUTPUT«Type check failed
>> in binding cont; expected 'Any' but got 'Mu'␤ in block  at
>> /tmp/AYhNmfAB9o:1␤␤»
>> 12:17 mr_ron m: no strict; %h = 42;
>> 12:17 camelia rakudo-moar af886d: ( no output )
>> 12:17 mr_ron bug I think
>> 12:19 Ven m: temp %h = 8
>> 12:19 camelia rakudo-moar af886d: OUTPUT«5===SORRY!5===
>> Error while compiling /tmp/3g1OTkzVIM␤Variable '%h' is not declared␤at
>> /tmp/3g1OTkzVIM:1␤--> 3temp 7⏏5%h = 8␤»
>> 12:19 yqt joined #perl6
>> 12:19 Ven m: no strict; temp %h = 8
>> 12:19 camelia rakudo-moar af886d: OUTPUT«Type check failed
>> in binding cont; expected 'Any' but got 'Mu'␤ in block  at
>> /tmp/dvEGWzXNXu:1␤␤»
>> 12:19 Ven m: no strict; (temp %h) = 8
>> 12:19 camelia rakudo-moar af886d: ( no output )
>> 12:19 Ven mr_ron: I think that's the issue :)
>> 12:22 mr_ron Good golf anyway ...

Re: [perl #125398] with no strict temp does not autcreate hashes and hash elements

[Elizabeth Mattijsen via RT]

The problem with let/temp for this situation has been fixed with 
752299767bac3c49 . And tests are needed for that.

However, the underlying issue is that the default value of container 
descriptors created automatically with “no strict” are Mu rather than Any.  
This will need some deeper research.
Either this ticket should remain open, or we should create another issue for 
this.

> On 3 Dec 2017, at 04:45, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> Still reproducible (2017.11,HEAD(e5b660e))
> 
> On 2015-06-13 05:48:13, ronaldxs wrote:
>> From irc
>> 
>> http://irclog.perlgeek.de/perl6/2015-06-13#i_10744864
>> 
>> 12:16 mr_ron m: no strict; %h = 42; {temp %h = 8}
>> 12:16 camelia rakudo-moar af886d: OUTPUT«Type check failed
>> in binding cont; expected 'Any' but got 'Mu'␤ in block  at
>> /tmp/AYhNmfAB9o:1␤␤»
>> 12:17 mr_ron m: no strict; %h = 42;
>> 12:17 camelia rakudo-moar af886d: ( no output )
>> 12:17 mr_ron bug I think
>> 12:19 Ven m: temp %h = 8
>> 12:19 camelia rakudo-moar af886d: OUTPUT«5===SORRY!5===
>> Error while compiling /tmp/3g1OTkzVIM␤Variable '%h' is not declared␤at
>> /tmp/3g1OTkzVIM:1␤--> 3temp 7⏏5%h = 8␤»
>> 12:19 yqt joined #perl6
>> 12:19 Ven m: no strict; temp %h = 8
>> 12:19 camelia rakudo-moar af886d: OUTPUT«Type check failed
>> in binding cont; expected 'Any' but got 'Mu'␤ in block  at
>> /tmp/dvEGWzXNXu:1␤␤»
>> 12:19 Ven m: no strict; (temp %h) = 8
>> 12:19 camelia rakudo-moar af886d: ( no output )
>> 12:19 Ven mr_ron: I think that's the issue :)
>> 12:22 mr_ron Good golf anyway ...

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

[Elizabeth Mattijsen via RT]

If you normally create a class, the entry in GLOBAL:: is decontainerized:

$ 6 'class Test {}; use nqp; dd nqp::iscont(GLOBAL::)’
0

However, if you just assign to a key in GLOBAL::, the result *is* containerized:

$ 6 'BEGIN GLOBAL:: = class { }; use nqp; dd nqp::iscont(GLOBAL::)’
1

So maybe you should just bind to the key in GLOBAL:: ?

$ 6 'BEGIN GLOBAL:: := class { }; dd Test.new'
.new

Now, perhaps this can be fixed by having a nqp::decont() somewhere deep in the 
bowels for every reference to something in GLOBAL::  .  But I fear that, even 
if it only a little bit of overhead, it’s overhead we don’t need.

An alternate option would be to create a Stash.ASSIGN-KEY that would not create 
a container, but instead would bind.  But that also feels a bit too magical to 
me.

So I think we should mark this ticket as “DIHWIDT”, and point to the workaround 
of binding.


> On 3 Dec 2017, at 11:23, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> As of today (2017.11,HEAD(e5b660e)) it prints this:
> 
> Cannot call method 'new' on a null object
> in block  at -e line 1
> 
> Which is arguably reasonable, but I guess it's not good enough.
> 
> On 2014-09-24 04:03:12, masak wrote:
>>  m: BEGIN GLOBAL:: = class { }; Test.new;
>>  rakudo-moar 682e03: OUTPUT«===SORRY!===␤Object of type
>>  in QAST::WVal, but not in SC␤»
>>  nine: looks like a bug.
>>  masak: any idea how I can create a class with a fully qualified
>> name from an EVAL that's deep in some other namespace?
>>  masak: as in Inline::Perl5::Perl6PackageCreator::create runs an
>> EVAL that should create a class called Foo::Bar::Baz.
>>  nine: EVAL "class Foo::Bar::Baz {}" doesn't cut it ?
>>  alternately EVAL "class Foo { class Bar { class Baz {}}}' ?
>>  or actually, maybe both?
>>  lizmat: nope, that creates
>> Inline::Perl5::Perl6PackageCreator::Foo::Bar::Baz (what a handy name
>> ;)
>>  m: BEGIN GLOBAL:: := class { }; Test.new;
>>  rakudo-moar 682e03: ( no output )
>>  ah, := works, while = does not
>>  nine: Does class GLOBAL::Foo::Bar::Baz { } not do it?
>>  jnthn: no, the GLOBAL:: is pretty much ignored
>>  ah
>>  Maybe that wants fixing
>>  But afer dinner
>> * masak submits rakudobug
>>  jnthn: according to S10, GLOBAL:: should do it though
>>  nine: That's my feeling too

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

[Elizabeth Mattijsen]

If you normally create a class, the entry in GLOBAL:: is decontainerized:

$ 6 'class Test {}; use nqp; dd nqp::iscont(GLOBAL::)’
0

However, if you just assign to a key in GLOBAL::, the result *is* containerized:

$ 6 'BEGIN GLOBAL:: = class { }; use nqp; dd nqp::iscont(GLOBAL::)’
1

So maybe you should just bind to the key in GLOBAL:: ?

$ 6 'BEGIN GLOBAL:: := class { }; dd Test.new'
.new

Now, perhaps this can be fixed by having a nqp::decont() somewhere deep in the 
bowels for every reference to something in GLOBAL::  .  But I fear that, even 
if it only a little bit of overhead, it’s overhead we don’t need.

An alternate option would be to create a Stash.ASSIGN-KEY that would not create 
a container, but instead would bind.  But that also feels a bit too magical to 
me.

So I think we should mark this ticket as “DIHWIDT”, and point to the workaround 
of binding.


> On 3 Dec 2017, at 11:23, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> As of today (2017.11,HEAD(e5b660e)) it prints this:
> 
> Cannot call method 'new' on a null object
> in block  at -e line 1
> 
> Which is arguably reasonable, but I guess it's not good enough.
> 
> On 2014-09-24 04:03:12, masak wrote:
>>  m: BEGIN GLOBAL:: = class { }; Test.new;
>>  rakudo-moar 682e03: OUTPUT«===SORRY!===␤Object of type
>>  in QAST::WVal, but not in SC␤»
>>  nine: looks like a bug.
>>  masak: any idea how I can create a class with a fully qualified
>> name from an EVAL that's deep in some other namespace?
>>  masak: as in Inline::Perl5::Perl6PackageCreator::create runs an
>> EVAL that should create a class called Foo::Bar::Baz.
>>  nine: EVAL "class Foo::Bar::Baz {}" doesn't cut it ?
>>  alternately EVAL "class Foo { class Bar { class Baz {}}}' ?
>>  or actually, maybe both?
>>  lizmat: nope, that creates
>> Inline::Perl5::Perl6PackageCreator::Foo::Bar::Baz (what a handy name
>> ;)
>>  m: BEGIN GLOBAL:: := class { }; Test.new;
>>  rakudo-moar 682e03: ( no output )
>>  ah, := works, while = does not
>>  nine: Does class GLOBAL::Foo::Bar::Baz { } not do it?
>>  jnthn: no, the GLOBAL:: is pretty much ignored
>>  ah
>>  Maybe that wants fixing
>>  But afer dinner
>> * masak submits rakudobug
>>  jnthn: according to S10, GLOBAL:: should do it though
>>  nine: That's my feeling too

Re: [perl #125964] [LTA] assigning to AOB List elem does not hint right

[Elizabeth Mattijsen]

Fixed with c9699ab , tests needed.  Please note that this currently breaks 
tests 55-56 in S02-types/range.t which appear to be a little too specific for 
their own good.


> On 3 Dec 2017, at 05:28, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> Today (2017.11,HEAD(e5b660e)) it prints this message:
> 
> Cannot modify an immutable Str (Nil)
> in block  at -e line 1
> 
> Which is still LTA
> 
> On 2015-09-02 05:09:29, FROGGS.de wrote:
>> m: my $a = (1, 2, 3); $a[42] = 21
>> camelia rakudo-moar 00be1e: OUTPUT«Index out of range. Is: 42, should be
>> in 0..2␤ in block  at /tmp/nnTEvtevbH:1␤␤»
>> GLRelia rakudo-moar 467b79: OUTPUT«Attempted to STORE to Nil.␤ in block
>>  at /tmp/o9_DeZFRmB:1␤␤»
>> 
>> Both answers are far from ideal because you cannot assign to a List
>> anyway, even when you use an existing position.
>> 

Re: [perl #125964] [LTA] assigning to AOB List elem does not hint right

[Elizabeth Mattijsen via RT]

Fixed with c9699ab , tests needed.  Please note that this currently breaks 
tests 55-56 in S02-types/range.t which appear to be a little too specific for 
their own good.


> On 3 Dec 2017, at 05:28, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> Today (2017.11,HEAD(e5b660e)) it prints this message:
> 
> Cannot modify an immutable Str (Nil)
> in block  at -e line 1
> 
> Which is still LTA
> 
> On 2015-09-02 05:09:29, FROGGS.de wrote:
>> m: my $a = (1, 2, 3); $a[42] = 21
>> camelia rakudo-moar 00be1e: OUTPUT«Index out of range. Is: 42, should be
>> in 0..2␤ in block  at /tmp/nnTEvtevbH:1␤␤»
>> GLRelia rakudo-moar 467b79: OUTPUT«Attempted to STORE to Nil.␤ in block
>>  at /tmp/o9_DeZFRmB:1␤␤»
>> 
>> Both answers are far from ideal because you cannot assign to a List
>> anyway, even when you use an existing position.
>> 

Re: [perl #126099] [BUG] .WHICH fails for Block but True

[Elizabeth Mattijsen]

Can be golfed to “Block but True”.  Problem also existed for “Code but True”.  
Fixed with e31a414 .  Tests needed.

> On 3 Dec 2017, at 05:00, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> Still reproducible (2017.11,HEAD(e5b660e))
> 
> On 2015-09-18 12:12:49, zef...@fysh.org wrote:
>> Basic introspection methods fail on the value Block but True:
>> 
>> $ ./perl6 -e 'my $a = Block; say $a.WHICH; my $b = Block but True; say
>> $b.WHICH'
>> Block
>> Cannot look up attributes in a type object
>> in block  at -e:1
>> 
>> Methods other than .WHICH fail too, such as .WHAT and .perl. The
>> error
>> message is obviously not generally correct, because these methods do
>> work
>> on other type objects. Not only on unmodified ones such as Block in
>> the
>> example above, but also on but-True modified ones for other classes
>> such
>> as Mu.
>> 
>> -zefram

Re: [perl #126099] [BUG] .WHICH fails for Block but True

[Elizabeth Mattijsen via RT]

Can be golfed to “Block but True”.  Problem also existed for “Code but True”.  
Fixed with e31a414 .  Tests needed.

> On 3 Dec 2017, at 05:00, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> Still reproducible (2017.11,HEAD(e5b660e))
> 
> On 2015-09-18 12:12:49, zef...@fysh.org wrote:
>> Basic introspection methods fail on the value Block but True:
>> 
>> $ ./perl6 -e 'my $a = Block; say $a.WHICH; my $b = Block but True; say
>> $b.WHICH'
>> Block
>> Cannot look up attributes in a type object
>> in block  at -e:1
>> 
>> Methods other than .WHICH fail too, such as .WHAT and .perl. The
>> error
>> message is obviously not generally correct, because these methods do
>> work
>> on other type objects. Not only on unmodified ones such as Block in
>> the
>> example above, but also on but-True modified ones for other classes
>> such
>> as Mu.
>> 
>> -zefram

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

[Elizabeth Mattijsen]

Those are predecessors of the “react / whenever” syntax.  I think that 
therefore this ticket can be closed now.

> On 3 Dec 2017, at 04:58, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> what is `earliest`, `more` and `wait`?
> 
> On 2015-06-06 16:40:28, r...@hoelz.ro wrote:
>> The attached script reproduces the issue.
>> 
>> When I use earliest with a wait 0 block, I get the following error
>> message:
>> 
>> No exception handler located for last_label
>> 
>> Interestingly enough, if I increase 0 to some arbitrary timeout, this
>> affects the bug; I've found if I keep it below 220ms, it triggers the
>> bug. Going higher fixes the problem.

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

[Elizabeth Mattijsen via RT]

Those are predecessors of the “react / whenever” syntax.  I think that 
therefore this ticket can be closed now.

> On 3 Dec 2017, at 04:58, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> what is `earliest`, `more` and `wait`?
> 
> On 2015-06-06 16:40:28, r...@hoelz.ro wrote:
>> The attached script reproduces the issue.
>> 
>> When I use earliest with a wait 0 block, I get the following error
>> message:
>> 
>> No exception handler located for last_label
>> 
>> Interestingly enough, if I increase 0 to some arbitrary timeout, this
>> affects the bug; I've found if I keep it below 220ms, it triggers the
>> bug. Going higher fixes the problem.

Re: [perl #119521] [BUG] “ctxlexpad needs an MVMContext” when reaching too far out to get to the truth in Rakudo

[Elizabeth Mattijsen]

Fixed with cd24b1c55d0c798c8fd776f , tests needed (also for OUTERS::)

> On 2 Dec 2017, at 13:06, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> Still reproducible (2017.11, HEAD(5929887)) on MoarVM.
> 
> Code:
> $OUTER::OUTER::OUTER::OUTER::True
> 
> Result:
> ctxlexpad needs an MVMContext
> in block  at -e line 1

Re: [perl #130982] [PERF] "for $a..$b -> $i { ... }" loops are sometimes much slower than c-style loops

[Elizabeth Mattijsen via RT]

> On 22 Nov 2017, at 19:31, Timo Paulssen via RT  
> wrote:
> On Mon, 20 Nov 2017 12:13:47 -0800, ronaldxs wrote:
>> What about a native perl6 range loop?  Couldn't there be some way for
>> Perl 6 / Rakudo to generate code competitive on a small range with the
>> "native-loop" example?
>> 
>> perl6 -e '
>>{
>>my int ($a, $one, $three) = (42, 1, 3);
>>for ^10_000_000 { $a += $one + $a%$three };
>>say now - ENTER now;
>>say $a
>>}'
> 
> This code will actually be turned into a `loop` loop by the optimizer at 
> compile time. If you type the block to have a signature of `-> int $_ --> 
> Nil` it'll get faster.

So, is there a reason we don’t do this on all ^1 type loops that don’t 
expect the return value to be used?  Because in my benchmarks, this is 3x as 
fast!  With only 25% of the allocations, so a lot less GC churn!


> The optimizer doesn't do anything like that for the `^$limit` case, however.

That feels more that it needs a smarter spesh to me?



Liz

Re: [perl #130982] [PERF] "for $a..$b -> $i { ... }" loops are sometimes much slower than c-style loops

[Elizabeth Mattijsen]

> On 22 Nov 2017, at 19:31, Timo Paulssen via RT  
> wrote:
> On Mon, 20 Nov 2017 12:13:47 -0800, ronaldxs wrote:
>> What about a native perl6 range loop?  Couldn't there be some way for
>> Perl 6 / Rakudo to generate code competitive on a small range with the
>> "native-loop" example?
>> 
>> perl6 -e '
>>{
>>my int ($a, $one, $three) = (42, 1, 3);
>>for ^10_000_000 { $a += $one + $a%$three };
>>say now - ENTER now;
>>say $a
>>}'
> 
> This code will actually be turned into a `loop` loop by the optimizer at 
> compile time. If you type the block to have a signature of `-> int $_ --> 
> Nil` it'll get faster.

So, is there a reason we don’t do this on all ^1 type loops that don’t 
expect the return value to be used?  Because in my benchmarks, this is 3x as 
fast!  With only 25% of the allocations, so a lot less GC churn!


> The optimizer doesn't do anything like that for the `^$limit` case, however.

That feels more that it needs a smarter spesh to me?



Liz

Re: [perl #132352] Set operators unfriendly to mutable types

[Elizabeth Mattijsen via RT]

Hmmm…. I guess this one does…  good point!  :-)

> On 18 Nov 2017, at 17:57, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> Does it mean that this now needs tests?
> 
> On 2017-10-30 06:42:25, elizabeth wrote:
>>> On 24 Oct 2017, at 12:56, Zoffix Znet via RT >> follo...@perl.org> wrote:
>>> On Mon, 23 Oct 2017 09:12:58 -0700, sml...@gmail.com wrote:
 On Mon, 23 Oct 2017 05:23:55 -0700, c...@zoffix.com wrote:
 The "solution", IMO, would not be to make your quoted example work
 (by
 adding further special cases to the return types of the setty
 operators or otherwise), but rather to make the following variation
 of
 it work:
 
 my %days is SetHash = Date.today … Date.new: '2014-04-02';
 
 %days ∖= %days.grep: *.key.day-of-week > 5;
 
 %days{Date.today}:delete;
 
 ...and then promote %-sigiled SetHash variables as the recommended
 way
 to store SetHash'es.
 
 It should be possible to make this last example work by implementing
 `method STORE` for type SetHash, right?
 
 (That it currently doesn't, may well be an oversight rather than a
 design choice.)
>> 
>> Commit b6a4d5b20451c5c8a made this possible:
>> 
>> my %d is SetHash = Date.today .. Date.new("2017-11-30”);
>> %d .= grep: *.key.day-of-week > 5;
>> dd %d;
>> 
>> 
> SetHash.new(Date.new(2017,11,5),Date.new(2017,11,12),Date.new(2017,11,26),Date.new(2017,11,4),Date.new(2017,11,19),Date.new(2017,11,11),Date.new(2017,11,18),Date.new(2017,11,25))

Re: [perl #132352] Set operators unfriendly to mutable types

[Elizabeth Mattijsen]

Hmmm…. I guess this one does…  good point!  :-)

> On 18 Nov 2017, at 17:57, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> Does it mean that this now needs tests?
> 
> On 2017-10-30 06:42:25, elizabeth wrote:
>>> On 24 Oct 2017, at 12:56, Zoffix Znet via RT >> follo...@perl.org> wrote:
>>> On Mon, 23 Oct 2017 09:12:58 -0700, sml...@gmail.com wrote:
 On Mon, 23 Oct 2017 05:23:55 -0700, c...@zoffix.com wrote:
 The "solution", IMO, would not be to make your quoted example work
 (by
 adding further special cases to the return types of the setty
 operators or otherwise), but rather to make the following variation
 of
 it work:
 
 my %days is SetHash = Date.today … Date.new: '2014-04-02';
 
 %days ∖= %days.grep: *.key.day-of-week > 5;
 
 %days{Date.today}:delete;
 
 ...and then promote %-sigiled SetHash variables as the recommended
 way
 to store SetHash'es.
 
 It should be possible to make this last example work by implementing
 `method STORE` for type SetHash, right?
 
 (That it currently doesn't, may well be an oversight rather than a
 design choice.)
>> 
>> Commit b6a4d5b20451c5c8a made this possible:
>> 
>> my %d is SetHash = Date.today .. Date.new("2017-11-30”);
>> %d .= grep: *.key.day-of-week > 5;
>> dd %d;
>> 
>> 
> SetHash.new(Date.new(2017,11,5),Date.new(2017,11,12),Date.new(2017,11,26),Date.new(2017,11,4),Date.new(2017,11,19),Date.new(2017,11,11),Date.new(2017,11,18),Date.new(2017,11,25))

Re: [perl #132225] AutoReply: segmentation fault while concurrently updating SetHash

[Elizabeth Mattijsen]

Fixed with be9e19efd97755cfd , tests needed!

> On 10 Nov 2017, at 03:28, David Lowe  wrote:
> 
> This crash still occurs with rakudo 2017.10.
> 
> On Thu, Oct 5, 2017 at 9:10 PM, perl6 via RT  
> wrote:
> Greetings,
> 
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "segmentation fault while concurrently updating SetHash",
> 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 #132225].
> 
> Please include the string:
> 
>  [perl #132225]
> 
> 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
> 
> -
> This short program crashes reliably (with a segmentation fault) on my
> system:
> 
> ```
> #!/usr/bin/env perl6
> 
> use v6.c;
> 
> my $lock = Lock.new;
> my $set  = SetHash.new;
> await (^12).map: {
>start {
>   for (^1000) {
>  $lock.protect: { $set<1> = True  }
>  $lock.protect: { $set<1> = False }
>   }
>}
> }
> ```
> 
> More information:
> 
> ```
> $ perl6 --version
> This is Rakudo version 2017.09 built on MoarVM version 2017.09.1
> implementing Perl 6.c.
> ```
> 
> 

Re: [perl #132225] AutoReply: segmentation fault while concurrently updating SetHash

[Elizabeth Mattijsen via RT]

Fixed with be9e19efd97755cfd , tests needed!

> On 10 Nov 2017, at 03:28, David Lowe  wrote:
> 
> This crash still occurs with rakudo 2017.10.
> 
> On Thu, Oct 5, 2017 at 9:10 PM, perl6 via RT  
> wrote:
> Greetings,
> 
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "segmentation fault while concurrently updating SetHash",
> 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 #132225].
> 
> Please include the string:
> 
>  [perl #132225]
> 
> 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
> 
> -
> This short program crashes reliably (with a segmentation fault) on my
> system:
> 
> ```
> #!/usr/bin/env perl6
> 
> use v6.c;
> 
> my $lock = Lock.new;
> my $set  = SetHash.new;
> await (^12).map: {
>start {
>   for (^1000) {
>  $lock.protect: { $set<1> = True  }
>  $lock.protect: { $set<1> = False }
>   }
>}
> }
> ```
> 
> More information:
> 
> ```
> $ perl6 --version
> This is Rakudo version 2017.09 built on MoarVM version 2017.09.1
> implementing Perl 6.c.
> ```
> 
> 

Re: [perl #132225] AutoReply: segmentation fault while concurrently updating SetHash

[Elizabeth Mattijsen via RT]

Ah, indeed, so a workaround would be:

my $lock = Lock.new;
my $set  = SetHash.new;
await ^16 .map: {
   start {
  for ^1 {
 $lock.protect: { $set<1> = True; 1 }
 $lock.protect: { $set<1> = False; 1 }
  }
   }
}

So maybe a solution would be to test for Proxy of the return value of the 
block, and then sink it?

> On 14 Nov 2017, at 16:59, Timo Paulssen via RT <perl6-bugs-follo...@perl.org> 
> wrote:
> 
> I already figured out that it's about sinking the result of assigning to
> the SetHash. When you access it you get a proxy, that is the return
> value of the lock-protected block, and the proxy gets sunk outside of
> it, thus causing concurrent access to the SetHash.
> 
> 
> On 14/11/17 16:03, Elizabeth Mattijsen wrote:
>> reducing the code to:
>> 
>> use nqp;
>> my $lock = Lock.new;
>> my $hash := nqp::hash;
>> await ^16 .map: {
>>   start {
>>  for ^1000 {
>> $lock.protect: { nqp::bindkey($hash,"a",1) }
>> $lock.protect: { nqp::deletekey($hash,"a") }
>>  }
>>   }
>> }
>> 
>> does *not* make it crash.  So it would appear that it’s not the lowlevel 
>> hash access that’s to blame.  Looking at this with Telemetry.snapper, this 
>> *does* seem to eat a lot of memory very quickly.  With a slightly bigger 
>> version, and much longer running, growth to about 490MB is observed 
>> (starting from 69MB) in 35 seconds, then remaining constant for about 125 
>> seconds, after which a modest increase of only about 15KB per second was 
>> observed for the remainder of the run.
>> 
>> So the next maybe it’s something in handling Proxy. 
>> 
>> 
>>> On 10 Nov 2017, at 03:28, David Lowe <j.david.l...@gmail.com> wrote:
>>> 
>>> This crash still occurs with rakudo 2017.10.
>>> 
>>> On Thu, Oct 5, 2017 at 9:10 PM, perl6 via RT <perl6-bugs-follo...@perl.org> 
>>> wrote:
>>> Greetings,
>>> 
>>> This message has been automatically generated in response to the
>>> creation of a trouble ticket regarding:
>>>"segmentation fault while concurrently updating SetHash",
>>> 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 #132225].
>>> 
>>> Please include the string:
>>> 
>>> [perl #132225]
>>> 
>>> 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
>>> 
>>> -
>>> This short program crashes reliably (with a segmentation fault) on my
>>> system:
>>> 
>>> ```
>>> #!/usr/bin/env perl6
>>> 
>>> use v6.c;
>>> 
>>> my $lock = Lock.new;
>>> my $set  = SetHash.new;
>>> await (^12).map: {
>>>   start {
>>>  for (^1000) {
>>> $lock.protect: { $set<1> = True  }
>>> $lock.protect: { $set<1> = False }
>>>  }
>>>   }
>>> }
>>> ```
>>> 
>>> More information:
>>> 
>>> ```
>>> $ perl6 --version
>>> This is Rakudo version 2017.09 built on MoarVM version 2017.09.1
>>> implementing Perl 6.c.
>>> ```
>>> 
>>> 

Re: [perl #132225] AutoReply: segmentation fault while concurrently updating SetHash

[Elizabeth Mattijsen]

Ah, indeed, so a workaround would be:

my $lock = Lock.new;
my $set  = SetHash.new;
await ^16 .map: {
   start {
  for ^1 {
 $lock.protect: { $set<1> = True; 1 }
 $lock.protect: { $set<1> = False; 1 }
  }
   }
}

So maybe a solution would be to test for Proxy of the return value of the 
block, and then sink it?

> On 14 Nov 2017, at 16:59, Timo Paulssen via RT <perl6-bugs-follo...@perl.org> 
> wrote:
> 
> I already figured out that it's about sinking the result of assigning to
> the SetHash. When you access it you get a proxy, that is the return
> value of the lock-protected block, and the proxy gets sunk outside of
> it, thus causing concurrent access to the SetHash.
> 
> 
> On 14/11/17 16:03, Elizabeth Mattijsen wrote:
>> reducing the code to:
>> 
>> use nqp;
>> my $lock = Lock.new;
>> my $hash := nqp::hash;
>> await ^16 .map: {
>>   start {
>>  for ^1000 {
>> $lock.protect: { nqp::bindkey($hash,"a",1) }
>> $lock.protect: { nqp::deletekey($hash,"a") }
>>  }
>>   }
>> }
>> 
>> does *not* make it crash.  So it would appear that it’s not the lowlevel 
>> hash access that’s to blame.  Looking at this with Telemetry.snapper, this 
>> *does* seem to eat a lot of memory very quickly.  With a slightly bigger 
>> version, and much longer running, growth to about 490MB is observed 
>> (starting from 69MB) in 35 seconds, then remaining constant for about 125 
>> seconds, after which a modest increase of only about 15KB per second was 
>> observed for the remainder of the run.
>> 
>> So the next maybe it’s something in handling Proxy. 
>> 
>> 
>>> On 10 Nov 2017, at 03:28, David Lowe <j.david.l...@gmail.com> wrote:
>>> 
>>> This crash still occurs with rakudo 2017.10.
>>> 
>>> On Thu, Oct 5, 2017 at 9:10 PM, perl6 via RT <perl6-bugs-follo...@perl.org> 
>>> wrote:
>>> Greetings,
>>> 
>>> This message has been automatically generated in response to the
>>> creation of a trouble ticket regarding:
>>>"segmentation fault while concurrently updating SetHash",
>>> 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 #132225].
>>> 
>>> Please include the string:
>>> 
>>> [perl #132225]
>>> 
>>> 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
>>> 
>>> -
>>> This short program crashes reliably (with a segmentation fault) on my
>>> system:
>>> 
>>> ```
>>> #!/usr/bin/env perl6
>>> 
>>> use v6.c;
>>> 
>>> my $lock = Lock.new;
>>> my $set  = SetHash.new;
>>> await (^12).map: {
>>>   start {
>>>  for (^1000) {
>>> $lock.protect: { $set<1> = True  }
>>> $lock.protect: { $set<1> = False }
>>>  }
>>>   }
>>> }
>>> ```
>>> 
>>> More information:
>>> 
>>> ```
>>> $ perl6 --version
>>> This is Rakudo version 2017.09 built on MoarVM version 2017.09.1
>>> implementing Perl 6.c.
>>> ```
>>> 
>>> 

Re: [perl #132225] AutoReply: segmentation fault while concurrently updating SetHash

[Elizabeth Mattijsen]

reducing the code to:

use nqp;
my $lock = Lock.new;
my $hash := nqp::hash;
await ^16 .map: {
   start {
  for ^1000 {
 $lock.protect: { nqp::bindkey($hash,"a",1) }
 $lock.protect: { nqp::deletekey($hash,"a") }
  }
   }
}

does *not* make it crash.  So it would appear that it’s not the lowlevel hash 
access that’s to blame.  Looking at this with Telemetry.snapper, this *does* 
seem to eat a lot of memory very quickly.  With a slightly bigger version, and 
much longer running, growth to about 490MB is observed (starting from 69MB) in 
35 seconds, then remaining constant for about 125 seconds, after which a modest 
increase of only about 15KB per second was observed for the remainder of the 
run.

So the next maybe it’s something in handling Proxy. 


> On 10 Nov 2017, at 03:28, David Lowe  wrote:
> 
> This crash still occurs with rakudo 2017.10.
> 
> On Thu, Oct 5, 2017 at 9:10 PM, perl6 via RT  
> wrote:
> Greetings,
> 
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "segmentation fault while concurrently updating SetHash",
> 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 #132225].
> 
> Please include the string:
> 
>  [perl #132225]
> 
> 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
> 
> -
> This short program crashes reliably (with a segmentation fault) on my
> system:
> 
> ```
> #!/usr/bin/env perl6
> 
> use v6.c;
> 
> my $lock = Lock.new;
> my $set  = SetHash.new;
> await (^12).map: {
>start {
>   for (^1000) {
>  $lock.protect: { $set<1> = True  }
>  $lock.protect: { $set<1> = False }
>   }
>}
> }
> ```
> 
> More information:
> 
> ```
> $ perl6 --version
> This is Rakudo version 2017.09 built on MoarVM version 2017.09.1
> implementing Perl 6.c.
> ```
> 
> 

Re: [perl #132225] AutoReply: segmentation fault while concurrently updating SetHash

[Elizabeth Mattijsen via RT]

reducing the code to:

use nqp;
my $lock = Lock.new;
my $hash := nqp::hash;
await ^16 .map: {
   start {
  for ^1000 {
 $lock.protect: { nqp::bindkey($hash,"a",1) }
 $lock.protect: { nqp::deletekey($hash,"a") }
  }
   }
}

does *not* make it crash.  So it would appear that it’s not the lowlevel hash 
access that’s to blame.  Looking at this with Telemetry.snapper, this *does* 
seem to eat a lot of memory very quickly.  With a slightly bigger version, and 
much longer running, growth to about 490MB is observed (starting from 69MB) in 
35 seconds, then remaining constant for about 125 seconds, after which a modest 
increase of only about 15KB per second was observed for the remainder of the 
run.

So the next maybe it’s something in handling Proxy. 


> On 10 Nov 2017, at 03:28, David Lowe  wrote:
> 
> This crash still occurs with rakudo 2017.10.
> 
> On Thu, Oct 5, 2017 at 9:10 PM, perl6 via RT  
> wrote:
> Greetings,
> 
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "segmentation fault while concurrently updating SetHash",
> 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 #132225].
> 
> Please include the string:
> 
>  [perl #132225]
> 
> 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
> 
> -
> This short program crashes reliably (with a segmentation fault) on my
> system:
> 
> ```
> #!/usr/bin/env perl6
> 
> use v6.c;
> 
> my $lock = Lock.new;
> my $set  = SetHash.new;
> await (^12).map: {
>start {
>   for (^1000) {
>  $lock.protect: { $set<1> = True  }
>  $lock.protect: { $set<1> = False }
>   }
>}
> }
> ```
> 
> More information:
> 
> ```
> $ perl6 --version
> This is Rakudo version 2017.09 built on MoarVM version 2017.09.1
> implementing Perl 6.c.
> ```
> 
> 

Re: [perl #132225] AutoReply: segmentation fault while concurrently updating SetHash

[Elizabeth Mattijsen via RT]

This does not seem to appear if you add at least one key to the set before the 
await.  The segfault only appears to occur when adding a first or removing the 
last key from the SetHash.

> On 10 Nov 2017, at 03:28, David Lowe  wrote:
> 
> This crash still occurs with rakudo 2017.10.
> 
> On Thu, Oct 5, 2017 at 9:10 PM, perl6 via RT  
> wrote:
> Greetings,
> 
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "segmentation fault while concurrently updating SetHash",
> 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 #132225].
> 
> Please include the string:
> 
>  [perl #132225]
> 
> 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
> 
> -
> This short program crashes reliably (with a segmentation fault) on my
> system:
> 
> ```
> #!/usr/bin/env perl6
> 
> use v6.c;
> 
> my $lock = Lock.new;
> my $set  = SetHash.new;
> await (^12).map: {
>start {
>   for (^1000) {
>  $lock.protect: { $set<1> = True  }
>  $lock.protect: { $set<1> = False }
>   }
>}
> }
> ```
> 
> More information:
> 
> ```
> $ perl6 --version
> This is Rakudo version 2017.09 built on MoarVM version 2017.09.1
> implementing Perl 6.c.
> ```
> 
> 

Re: [perl #132225] AutoReply: segmentation fault while concurrently updating SetHash

[Elizabeth Mattijsen]

This does not seem to appear if you add at least one key to the set before the 
await.  The segfault only appears to occur when adding a first or removing the 
last key from the SetHash.

> On 10 Nov 2017, at 03:28, David Lowe  wrote:
> 
> This crash still occurs with rakudo 2017.10.
> 
> On Thu, Oct 5, 2017 at 9:10 PM, perl6 via RT  
> wrote:
> Greetings,
> 
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "segmentation fault while concurrently updating SetHash",
> 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 #132225].
> 
> Please include the string:
> 
>  [perl #132225]
> 
> 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
> 
> -
> This short program crashes reliably (with a segmentation fault) on my
> system:
> 
> ```
> #!/usr/bin/env perl6
> 
> use v6.c;
> 
> my $lock = Lock.new;
> my $set  = SetHash.new;
> await (^12).map: {
>start {
>   for (^1000) {
>  $lock.protect: { $set<1> = True  }
>  $lock.protect: { $set<1> = False }
>   }
>}
> }
> ```
> 
> More information:
> 
> ```
> $ perl6 --version
> This is Rakudo version 2017.09 built on MoarVM version 2017.09.1
> implementing Perl 6.c.
> ```
> 
> 

Re: [perl #131774] [PERF] Simple, if artificial, string concatenation example hogs memory and time

[Elizabeth Mattijsen via RT]

Same, but with the new Telemetry module so you can see better what’s going on:

$ perl6 -MTelemetry -e 'for (1, 10, 100, 1_000, 10_000, 100_000) -> $limit { 
snap; my $x; my $y = "x" x 100; $x ~= $y for 1..$limit }'

Telemetry Report of Process #79213 (2017-11-10T16:24:00Z)
Number of Snapshots: 7
No supervisor thread has been running
Initial Size:83236 Kbytes
Total Time:  37.40 seconds
Total CPU Usage: 37.37 seconds

wallclock  util%  max-rss
 1084  39.13  164
  124  25.20  192
  355  23.35  280
 6912  21.83 1940
   397311  12.4883628
 36996468  12.49  3993120
- -- 
 37402254  12.49  4079324

Legend:
wallclock  Number of microseconds elapsed
util%  Percentage of CPU utilization (0..100%)
  max-rss  Maximum resident set size (in Kbytes)

So, going from 1_000 -> 10_000 -> 100_000 seems to have a quadratic effect on 
memory and CPU usage (as shown in wallclock, with the 1 in 8 CPU’s being fully 
in use all of the time). 

Feels like a clear case of O² to me.


Liz

> On 10 Nov 2017, at 16:02, Daniel Green via RT  
> wrote:
> 
> On Sun, 30 Jul 2017 09:49:39 -0700, ronaldxs wrote:
>> On Thu, 20 Jul 2017 20:32:12 -0700, lloyd.fo...@gmail.com wrote:
>>> I did an experiment a while ago and found that string concatenation
>>> in a
>>> loop was Ο(n²) in rakudo. I asked about it on irc and jnthn explained
>>> to me
>>> that this was expected because strings are immutable (and therefore
>>> wasn't
>>> worth RTing):
>>> https://irclog.perlgeek.de/perl6/2015-12-15#i_11720228
>>> 
>> 
>> If the string is represented by an array and is immutable then each
>> append allocates a new array, copies in the existing prefix string and
>> copies the new appended string at the end, which is the sum of an
>> arithmetic sequence and so O(n ** 2).  Other languages have immutable
>> strings including Java, JavaScript and Python, and each has found ways
>> around the problem.  Perl 6 Str objects perform somewhat faster than
>> Java String objects (on my system – Java 8?) but Java has mutable
>> StringBuffer and StringBuilder classes.  Python v2.7 cheats by making
>> strings mutable for the case where a string has a reference count of 1
>> (http://blog.mclemon.io/python-efficient-string-concatenation-in-
>> python-2016-edition and see the comment in source stringobject.c for
>> _PyString_Resize).  For JavaScript FireFox/SpiderMonkey ropes seem to
>> solve the problem (https://stackoverflow.com/questions/7299010/why-is-
>> string-concatenation-faster-than-array-join) which is also solved in
>> other ways by V8 (Node JS) etc.  As noted on IRC the Perl 6 native
>> “str” also has an optimization for this case
>> (https://irclog.perlgeek.de/perl6-dev/2017-07-27#i_14930258 – sorry
>> about any confusion on ropes and V8).
>> 
>> The memory situation has improved since the ticket was open but at
>> 150_000 iterations or 15 million characters there is still a MoarVM
>> memory panic with ulimit of 4Gb.
> 
> 
> The numbers seem a little better now (though still non-linear):
> $ /usr/bin/time perl6 -e 'for (1, 10, 100, 1_000, 10_000, 100_000) -> $limit 
> {my $x; my $y = "x" x 100; $x ~= $y for (1..$limit); say "$limit: ", now - 
> ENTER now}'
> 1: 0.0045150
> 10: 0.0004916
> 100: 0.00096704
> 1000: 0.0077635
> 1: 0.4149077
> 10: 40.1284791
> 37.36user 3.66system 0:41.02elapsed 100%CPU (0avgtext+0avgdata 
> 3776812maxresident)k
> 
> $ perl6 --version
> This is Rakudo version 2017.10-146-gf8e1a5faa built on MoarVM version 
> 2017.10-64-g2ca7e8587

Re: [perl #131774] [PERF] Simple, if artificial, string concatenation example hogs memory and time

[Elizabeth Mattijsen]

Same, but with the new Telemetry module so you can see better what’s going on:

$ perl6 -MTelemetry -e 'for (1, 10, 100, 1_000, 10_000, 100_000) -> $limit { 
snap; my $x; my $y = "x" x 100; $x ~= $y for 1..$limit }'

Telemetry Report of Process #79213 (2017-11-10T16:24:00Z)
Number of Snapshots: 7
No supervisor thread has been running
Initial Size:83236 Kbytes
Total Time:  37.40 seconds
Total CPU Usage: 37.37 seconds

wallclock  util%  max-rss
 1084  39.13  164
  124  25.20  192
  355  23.35  280
 6912  21.83 1940
   397311  12.4883628
 36996468  12.49  3993120
- -- 
 37402254  12.49  4079324

Legend:
wallclock  Number of microseconds elapsed
util%  Percentage of CPU utilization (0..100%)
  max-rss  Maximum resident set size (in Kbytes)

So, going from 1_000 -> 10_000 -> 100_000 seems to have a quadratic effect on 
memory and CPU usage (as shown in wallclock, with the 1 in 8 CPU’s being fully 
in use all of the time). 

Feels like a clear case of O² to me.


Liz

> On 10 Nov 2017, at 16:02, Daniel Green via RT  
> wrote:
> 
> On Sun, 30 Jul 2017 09:49:39 -0700, ronaldxs wrote:
>> On Thu, 20 Jul 2017 20:32:12 -0700, lloyd.fo...@gmail.com wrote:
>>> I did an experiment a while ago and found that string concatenation
>>> in a
>>> loop was Ο(n²) in rakudo. I asked about it on irc and jnthn explained
>>> to me
>>> that this was expected because strings are immutable (and therefore
>>> wasn't
>>> worth RTing):
>>> https://irclog.perlgeek.de/perl6/2015-12-15#i_11720228
>>> 
>> 
>> If the string is represented by an array and is immutable then each
>> append allocates a new array, copies in the existing prefix string and
>> copies the new appended string at the end, which is the sum of an
>> arithmetic sequence and so O(n ** 2).  Other languages have immutable
>> strings including Java, JavaScript and Python, and each has found ways
>> around the problem.  Perl 6 Str objects perform somewhat faster than
>> Java String objects (on my system – Java 8?) but Java has mutable
>> StringBuffer and StringBuilder classes.  Python v2.7 cheats by making
>> strings mutable for the case where a string has a reference count of 1
>> (http://blog.mclemon.io/python-efficient-string-concatenation-in-
>> python-2016-edition and see the comment in source stringobject.c for
>> _PyString_Resize).  For JavaScript FireFox/SpiderMonkey ropes seem to
>> solve the problem (https://stackoverflow.com/questions/7299010/why-is-
>> string-concatenation-faster-than-array-join) which is also solved in
>> other ways by V8 (Node JS) etc.  As noted on IRC the Perl 6 native
>> “str” also has an optimization for this case
>> (https://irclog.perlgeek.de/perl6-dev/2017-07-27#i_14930258 – sorry
>> about any confusion on ropes and V8).
>> 
>> The memory situation has improved since the ticket was open but at
>> 150_000 iterations or 15 million characters there is still a MoarVM
>> memory panic with ulimit of 4Gb.
> 
> 
> The numbers seem a little better now (though still non-linear):
> $ /usr/bin/time perl6 -e 'for (1, 10, 100, 1_000, 10_000, 100_000) -> $limit 
> {my $x; my $y = "x" x 100; $x ~= $y for (1..$limit); say "$limit: ", now - 
> ENTER now}'
> 1: 0.0045150
> 10: 0.0004916
> 100: 0.00096704
> 1000: 0.0077635
> 1: 0.4149077
> 10: 40.1284791
> 37.36user 3.66system 0:41.02elapsed 100%CPU (0avgtext+0avgdata 
> 3776812maxresident)k
> 
> $ perl6 --version
> This is Rakudo version 2017.10-146-gf8e1a5faa built on MoarVM version 
> 2017.10-64-g2ca7e8587

Re: [perl #131846] [BUG] combinations not accepting Inf/Whatever as upper bound (Regression)

[Elizabeth Mattijsen via RT]

Fixed with bdc73563f484325cc544 , tests were already added, can be closed.

> On 6 Aug 2017, at 17:13, Joshua (via RT)  wrote:
> 
> # New Ticket Created by  Joshua 
> # Please include the string:  [perl #131846]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131846 >
> 
> 
> Previously this used to work
> 
> (1,2,3).combinations(2..*)
> 
> but now it fails with the error: Cannot determine integer bounds
> 
> Correct output should be all combinations of 2 or more, ie: ((1 2) (1 3) (2 
> 3) (1 2 3))
> 
> Bisectable points to this commit as the culprit: 
> 502fc77a68924a68115e739ffae64fdd10f3fbe9

Re: [perl #131846] [BUG] combinations not accepting Inf/Whatever as upper bound (Regression)

[Elizabeth Mattijsen]

Fixed with bdc73563f484325cc544 , tests were already added, can be closed.

> On 6 Aug 2017, at 17:13, Joshua (via RT)  wrote:
> 
> # New Ticket Created by  Joshua 
> # Please include the string:  [perl #131846]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131846 >
> 
> 
> Previously this used to work
> 
> (1,2,3).combinations(2..*)
> 
> but now it fails with the error: Cannot determine integer bounds
> 
> Correct output should be all combinations of 2 or more, ie: ((1 2) (1 3) (2 
> 3) (1 2 3))
> 
> Bisectable points to this commit as the culprit: 
> 502fc77a68924a68115e739ffae64fdd10f3fbe9

Re: [perl #132377] [BUG][POD] tables inside =begin/=end comment pairs cause exception

[Elizabeth Mattijsen via RT]

A —ll-exception stacktrace would be useful in such a case :-)

> On 30 Oct 2017, at 15:24, Tom Browder (via RT)  
> wrote:
> 
> # New Ticket Created by  Tom Browder 
> # Please include the string:  [perl #132377]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132377 >
> 
> 
> The following pod causes an exception
> 
> =begin comment
> =begin table
> a | b | c
> =end table
> =end comment
> 
> If the =begin/=end table lines are indented by one space the exception is
> not thrown

Re: [perl #132377] [BUG][POD] tables inside =begin/=end comment pairs cause exception

[Elizabeth Mattijsen]

A —ll-exception stacktrace would be useful in such a case :-)

> On 30 Oct 2017, at 15:24, Tom Browder (via RT)  
> wrote:
> 
> # New Ticket Created by  Tom Browder 
> # Please include the string:  [perl #132377]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132377 >
> 
> 
> The following pod causes an exception
> 
> =begin comment
> =begin table
> a | b | c
> =end table
> =end comment
> 
> If the =begin/=end table lines are indented by one space the exception is
> not thrown

Re: [perl #132353] [LTA] error with using meta assign ops with bound SetHash

[Elizabeth Mattijsen via RT]

Fixed with b6a4d5b20451c5c8a, this now DWIM, tests needed.

Error message being too long, fixed with 497e0582e6c64ccc04b2e9 .

> On 23 Oct 2017, at 14:28, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #132353]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132353 >
> 
> 
> This code produces an LTA error:
> 
>my %days := SetHash.new: Date.today … Date.new: '2030-04-02';
>%days ∖= %days.grep: *.key.day-of-week > 5;
> 
> First, the error reads "Cannot modify an immutable SetHash" which is 
> confusing,
> since SetHash is a mutable type.
> 
> Second, the error dumps all of the contents of the SetHash, so for this code,
> the user has to scroll several pages up just to get to the error itself.

FWIW, I think a more readable version of this is:

%days .= grep: *.key.day-of-week > 5;

Re: [perl #132353] [LTA] error with using meta assign ops with bound SetHash

[Elizabeth Mattijsen]

Fixed with b6a4d5b20451c5c8a, this now DWIM, tests needed.

Error message being too long, fixed with 497e0582e6c64ccc04b2e9 .

> On 23 Oct 2017, at 14:28, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #132353]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132353 >
> 
> 
> This code produces an LTA error:
> 
>my %days := SetHash.new: Date.today … Date.new: '2030-04-02';
>%days ∖= %days.grep: *.key.day-of-week > 5;
> 
> First, the error reads "Cannot modify an immutable SetHash" which is 
> confusing,
> since SetHash is a mutable type.
> 
> Second, the error dumps all of the contents of the SetHash, so for this code,
> the user has to scroll several pages up just to get to the error itself.

FWIW, I think a more readable version of this is:

%days .= grep: *.key.day-of-week > 5;

Re: [perl #132352] Set operators unfriendly to mutable types

[Elizabeth Mattijsen via RT]

> On 24 Oct 2017, at 12:56, Zoffix Znet via RT  
> wrote:
> On Mon, 23 Oct 2017 09:12:58 -0700, sml...@gmail.com wrote:
>> On Mon, 23 Oct 2017 05:23:55 -0700, c...@zoffix.com wrote:
>> The "solution", IMO, would not be to make your quoted example work (by
>> adding further special cases to the return types of the setty
>> operators or otherwise), but rather to make the following variation of
>> it work:
>> 
>> my %days is SetHash = Date.today … Date.new: '2014-04-02';
>> 
>> %days ∖= %days.grep: *.key.day-of-week > 5;
>> 
>> %days{Date.today}:delete;
>> 
>> ...and then promote %-sigiled SetHash variables as the recommended way
>> to store SetHash'es.
>> 
>> It should be possible to make this last example work by implementing
>> `method STORE` for type SetHash, right?
>> 
>> (That it currently doesn't, may well be an oversight rather than a
>> design choice.)

Commit b6a4d5b20451c5c8a made this possible:

my %d is SetHash = Date.today .. Date.new("2017-11-30”);
%d .= grep: *.key.day-of-week > 5;
dd %d;

SetHash.new(Date.new(2017,11,5),Date.new(2017,11,12),Date.new(2017,11,26),Date.new(2017,11,4),Date.new(2017,11,19),Date.new(2017,11,11),Date.new(2017,11,18),Date.new(2017,11,25))

Re: [perl #132352] Set operators unfriendly to mutable types

[Elizabeth Mattijsen]

> On 24 Oct 2017, at 12:56, Zoffix Znet via RT  
> wrote:
> On Mon, 23 Oct 2017 09:12:58 -0700, sml...@gmail.com wrote:
>> On Mon, 23 Oct 2017 05:23:55 -0700, c...@zoffix.com wrote:
>> The "solution", IMO, would not be to make your quoted example work (by
>> adding further special cases to the return types of the setty
>> operators or otherwise), but rather to make the following variation of
>> it work:
>> 
>> my %days is SetHash = Date.today … Date.new: '2014-04-02';
>> 
>> %days ∖= %days.grep: *.key.day-of-week > 5;
>> 
>> %days{Date.today}:delete;
>> 
>> ...and then promote %-sigiled SetHash variables as the recommended way
>> to store SetHash'es.
>> 
>> It should be possible to make this last example work by implementing
>> `method STORE` for type SetHash, right?
>> 
>> (That it currently doesn't, may well be an oversight rather than a
>> design choice.)

Commit b6a4d5b20451c5c8a made this possible:

my %d is SetHash = Date.today .. Date.new("2017-11-30”);
%d .= grep: *.key.day-of-week > 5;
dd %d;

SetHash.new(Date.new(2017,11,5),Date.new(2017,11,12),Date.new(2017,11,26),Date.new(2017,11,4),Date.new(2017,11,19),Date.new(2017,11,11),Date.new(2017,11,18),Date.new(2017,11,25))

Re: [perl #132330] Sets can be equal even though their elements aren’t

[Elizabeth Mattijsen]

Which goes back to the behaviour of nqp::unbox_n():

$ 6 'use nqp; say nqp::unbox_n(1e0); say nqp::unbox_n(1e0 + 4e-15)'
1
1


> On 21 Oct 2017, at 11:30, Elizabeth Mattijsen <l...@dijkmat.nl> wrote:
> 
> The problem is that both these values have the same .WHICH:
> 
> $ 6 'say 1e0.WHICH; say (1e0 + 4e-15).WHICH'
> Num|1
> Num|1
> 
> Nothing to do with Sets/Bags/Mixes/object hashes.
> 
>> On 20 Oct 2017, at 17:02, Victor ADAM (via RT) 
>> <perl6-bugs-follo...@perl.org> wrote:
>> 
>> # New Ticket Created by  Victor ADAM 
>> # Please include the string:  [perl #132330]
>> # in the subject line of all future correspondence about this issue. 
>> # https://rt.perl.org/Ticket/Display.html?id=132330 >
>> 
>> 
>> How to reproduce
>> 
>> 
>> perl6 -e 'my ($a, $b) = set(1e0), set(1e0 + 4e-15); say $a ~~ $b,
>> $a.keys »≅« $b.keys'
>> 
>> Expected behavior
>> -
>> 
>> Prints `False(False)`.
>> 
>> Actual behavior
>> ---
>> 
>> Prints `True(False)`.
>> 
>> This contradicts the documentation of the Setty ACCEPTS method:
>> “Returns True if $other and self contain all the same elements, and no
>> others.” The sets’ elements aren’t equal, or even approximately equal
>> (≅), and yet ACCEPTS (~~) returns `True`.
>> 
>> Note that other set methods show similar behavior: `1e0 ⊖ (1e0 +
>> 4e-15)` is the empty set, `set(1e0, 1e0 + 4e-15)` only has one
>> element…
>> 
>> Version information
>> ---
>> 
>> This is Rakudo version 2017.09 built on MoarVM version 2017.09.1
>> implementing Perl 6.c.

Re: [perl #132330] Sets can be equal even though their elements aren’t

[Elizabeth Mattijsen]

The problem is that both these values have the same .WHICH:

$ 6 'say 1e0.WHICH; say (1e0 + 4e-15).WHICH'
Num|1
Num|1

Nothing to do with Sets/Bags/Mixes/object hashes.

> On 20 Oct 2017, at 17:02, Victor ADAM (via RT)  
> wrote:
> 
> # New Ticket Created by  Victor ADAM 
> # Please include the string:  [perl #132330]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132330 >
> 
> 
> How to reproduce
> 
> 
> perl6 -e 'my ($a, $b) = set(1e0), set(1e0 + 4e-15); say $a ~~ $b,
> $a.keys »≅« $b.keys'
> 
> Expected behavior
> -
> 
> Prints `False(False)`.
> 
> Actual behavior
> ---
> 
> Prints `True(False)`.
> 
> This contradicts the documentation of the Setty ACCEPTS method:
> “Returns True if $other and self contain all the same elements, and no
> others.” The sets’ elements aren’t equal, or even approximately equal
> (≅), and yet ACCEPTS (~~) returns `True`.
> 
> Note that other set methods show similar behavior: `1e0 ⊖ (1e0 +
> 4e-15)` is the empty set, `set(1e0, 1e0 + 4e-15)` only has one
> element…
> 
> Version information
> ---
> 
> This is Rakudo version 2017.09 built on MoarVM version 2017.09.1
> implementing Perl 6.c.

Re: [perl #131300] [BUG] MoarVM panic if you check for membership in undefined Set

[Elizabeth Mattijsen via RT]

Fixed with 8a88d14905248526415 , unfudged tests, can be closed now.

> On 15 Oct 2017, at 08:54, Zoffix Znet via RT  
> wrote:
> 
> On Sat, 13 May 2017 01:24:28 -0700, elizabeth wrote:
>> All issues appear to be fixed with
>> https://github.com/rakudo/rakudo/commit/407bce1dc2 .
>> Tests are needed, also for the ⊇ and ⊉ and associated cases.
>> 
>>> On 12 May 2017, at 21:22, Zoffix Znet via RT >> follo...@perl.org> wrote:
>>> On Fri, 12 May 2017 12:07:11 -0700, c...@tilmes.org wrote:
 m: say 1 ∈ (Set) ?? 'present' !! 'not present';
 rakudo-moar dc5eec: OUTPUT: «MoarVM panic: Memory allocation failed;
 could
 not allocate 83968 bytes␤»
>>> 
>>> To add from https://irclog.perlgeek.de/perl6/2017-05-12#i_14573414
>>> 
>>> 19:16 Zoffix  it infini-loops in dispatch because Set.Set
>>> returns Set. And so far I see (elem), (cont), ∉, ∋, ∌ similarly
>>> affected. There might be more. Would you mind filing a bug for it?
>>> 19:20 Zoffix  And some ops like ⊇ and ⊉ crash with "can't
>>> look up attributes... " error. There's probably a meaning for type
>>> objects we could implement; like Set eqv set()
> 
> Tests committed[^1], but they show this ticket is not entirely resolved:
> 
>Still hangs for:   ∩  (&)  ⊍  (.)
> 
>Still have "Cannot lookup attributes in type object" for:   ∖  (-)  
> 
> The problematic tests are currently (manually) skip-fudged.
> 
> [1] https://github.com/perl6/roast/commit/87889891d1

Re: [perl #131300] [BUG] MoarVM panic if you check for membership in undefined Set

[Elizabeth Mattijsen]

Fixed with 8a88d14905248526415 , unfudged tests, can be closed now.

> On 15 Oct 2017, at 08:54, Zoffix Znet via RT  
> wrote:
> 
> On Sat, 13 May 2017 01:24:28 -0700, elizabeth wrote:
>> All issues appear to be fixed with
>> https://github.com/rakudo/rakudo/commit/407bce1dc2 .
>> Tests are needed, also for the ⊇ and ⊉ and associated cases.
>> 
>>> On 12 May 2017, at 21:22, Zoffix Znet via RT >> follo...@perl.org> wrote:
>>> On Fri, 12 May 2017 12:07:11 -0700, c...@tilmes.org wrote:
 m: say 1 ∈ (Set) ?? 'present' !! 'not present';
 rakudo-moar dc5eec: OUTPUT: «MoarVM panic: Memory allocation failed;
 could
 not allocate 83968 bytes␤»
>>> 
>>> To add from https://irclog.perlgeek.de/perl6/2017-05-12#i_14573414
>>> 
>>> 19:16 Zoffix  it infini-loops in dispatch because Set.Set
>>> returns Set. And so far I see (elem), (cont), ∉, ∋, ∌ similarly
>>> affected. There might be more. Would you mind filing a bug for it?
>>> 19:20 Zoffix  And some ops like ⊇ and ⊉ crash with "can't
>>> look up attributes... " error. There's probably a meaning for type
>>> objects we could implement; like Set eqv set()
> 
> Tests committed[^1], but they show this ticket is not entirely resolved:
> 
>Still hangs for:   ∩  (&)  ⊍  (.)
> 
>Still have "Cannot lookup attributes in type object" for:   ∖  (-)  
> 
> The problematic tests are currently (manually) skip-fudged.
> 
> [1] https://github.com/perl6/roast/commit/87889891d1

Re: [perl #132283] [REGRESSION] BUILDALL is listed as one of the methods, maybe that's not right (say $foo.^methods)

[Elizabeth Mattijsen via RT]

> On 13 Oct 2017, at 07:52, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #132283]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132283 >
> 
> 
> Code:
> class Foo { has $.bar }; my $f = Foo.new(bar=>'u'); say $f.^methods;
> 
> ¦«2015.12»:
> (bar)
> 
> ¦«2016.06»:
> (bar)
> 
> ¦«2016.12»:
> (bar)
> 
> ¦«2017.06»:
> (bar)
> 
> ¦«f72be0f130cf»:
> (bar BUILDALL)
> 
> 
> 
> Bisectable points at two relevant commits:
> First it was BUILDALL_UNDER_CONSTRUCTION after 
> https://github.com/rakudo/rakudo/commit/9837687d93c907ec232b1c7635776aa0c7faa6bc
> Now it is BUILDALL after 
> https://github.com/rakudo/rakudo/commit/63cf246fd4caa43c52a212054a98e9b450c54127
> 
> 
> I don't know if BUILDALL should be listed or not. My gut feeling says that it 
> shouldn't be, but feel free to argue otherwise. I'm just the messenger.

Well, it *is* an auto-generated method that is installed in the namespace.  
Just like “bar”. So either we should show both, or neither.  Or introduce a 
flag to include/exclude auto-generated methods.  But then we would need to mark 
those methods as auto-generated somehow.

Re: [perl #132283] [REGRESSION] BUILDALL is listed as one of the methods, maybe that's not right (say $foo.^methods)

[Elizabeth Mattijsen]

> On 13 Oct 2017, at 07:52, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #132283]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132283 >
> 
> 
> Code:
> class Foo { has $.bar }; my $f = Foo.new(bar=>'u'); say $f.^methods;
> 
> ¦«2015.12»:
> (bar)
> 
> ¦«2016.06»:
> (bar)
> 
> ¦«2016.12»:
> (bar)
> 
> ¦«2017.06»:
> (bar)
> 
> ¦«f72be0f130cf»:
> (bar BUILDALL)
> 
> 
> 
> Bisectable points at two relevant commits:
> First it was BUILDALL_UNDER_CONSTRUCTION after 
> https://github.com/rakudo/rakudo/commit/9837687d93c907ec232b1c7635776aa0c7faa6bc
> Now it is BUILDALL after 
> https://github.com/rakudo/rakudo/commit/63cf246fd4caa43c52a212054a98e9b450c54127
> 
> 
> I don't know if BUILDALL should be listed or not. My gut feeling says that it 
> shouldn't be, but feel free to argue otherwise. I'm just the messenger.

Well, it *is* an auto-generated method that is installed in the namespace.  
Just like “bar”. So either we should show both, or neither.  Or introduce a 
flag to include/exclude auto-generated methods.  But then we would need to mark 
those methods as auto-generated somehow.

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

[Elizabeth Mattijsen]

> On 13 Oct 2017, at 07:37, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #132281]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132281 >
> 
> 
> Code:
> say "blogger".comb.Bag # if you want for all the letters
> 
> ¦«2015.12»:
> bag(r, l, g(2), b, e, o)
> 
> ¦«2016.06»:
> bag(r, l, g(2), b, e, o)
> 
> ¦«2016.12»:
> bag(r, l, g(2), b, e, o)
> 
> ¦«2017.06»:
> bag(e, l, b, g(2), o, r)
> 
> ¦«f72be0f130cf»:
> Bag(b, e, g(2), l, o, r)
> 
> 
> Possible IRC discussion: 
> https://irclog.perlgeek.de/perl6/2017-10-09#i_15278073
> 
> 
> Bisectable: (2017-07-20) 
> https://github.com/rakudo/rakudo/commit/21b9a720c75656b13805611544aa5ee64c4924ae
> 
> 
> To be honest, I don't know if that's a reasonable ticket. I guess it doesn't 
> really matter if it's bag or Bag, but I'm pretty sure that the change was 
> unintentional so I'm submitting it as a ticket.
> 
> Maybe “bag()” is better because it resembles an actual syntax. Kind of. Judge 
> yourself.

The two are *not* the same.  Bag(foo) is the same as foo.Bag.  Which implies 
taking all values as is.  Whereas bag() implies looking at the values in the 
same way as “.new-from-pairs”.  Observe:

$ 6 'dd bag({a => 42}); dd Bag({ a => 42 })'
(:a(42)).Bag
("a"=>42).Bag

Re: [perl #132279] [REGRESSION][9999] BagHash.grab with huge values (("foo" => 10000000000000000000).BagHash.grab(1))

[Elizabeth Mattijsen]

Fixed with 975fcf6cfd8089bfc237 , tests needed

> On 13 Oct 2017, at 07:01, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #132279]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132279 >
> 
> 
> Code:
> ("foo" => 1000).BagHash.grab(1)
> 
> ¦«2015.12»:
> 
> 
> ¦«2016.06»:
> 
> 
> ¦«2016.12»:
> 
> 
> ¦«2017.06»:
> Cannot unbox 64 bit wide bigint into native integer
> in block  at 
> /home/bisectable/git/whateverable/data/regressionable/15290317/snippet line 1
> «exit code = 1»
> 
> ¦«f72be0f130cf»:
> Cannot unbox 64 bit wide bigint into native integer
> in block  at 
> /home/bisectable/git/whateverable/data/regressionable/15290317/snippet line 1
> «exit code = 1»
> 
> 
> Possible IRC discussion: 
> https://irclog.perlgeek.de/perl6/2017-10-11#i_15290317
> 
> Bisectable points at 
> https://github.com/rakudo/rakudo/commit/87a95fc1355e01972670895b55b02bc382797fc9

Re: [perl #132279] [REGRESSION][9999] BagHash.grab with huge values (("foo" => 10000000000000000000).BagHash.grab(1))

[Elizabeth Mattijsen via RT]

Fixed with 975fcf6cfd8089bfc237 , tests needed

> On 13 Oct 2017, at 07:01, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #132279]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132279 >
> 
> 
> Code:
> ("foo" => 1000).BagHash.grab(1)
> 
> ¦«2015.12»:
> 
> 
> ¦«2016.06»:
> 
> 
> ¦«2016.12»:
> 
> 
> ¦«2017.06»:
> Cannot unbox 64 bit wide bigint into native integer
> in block  at 
> /home/bisectable/git/whateverable/data/regressionable/15290317/snippet line 1
> «exit code = 1»
> 
> ¦«f72be0f130cf»:
> Cannot unbox 64 bit wide bigint into native integer
> in block  at 
> /home/bisectable/git/whateverable/data/regressionable/15290317/snippet line 1
> «exit code = 1»
> 
> 
> Possible IRC discussion: 
> https://irclog.perlgeek.de/perl6/2017-10-11#i_15290317
> 
> Bisectable points at 
> https://github.com/rakudo/rakudo/commit/87a95fc1355e01972670895b55b02bc382797fc9

Re: [perl #132236] Possible regression in Meta object construction

[Elizabeth Mattijsen via RT]

Fixed with dd943eded83edb3753 , tests needed.

> On 7 Oct 2017, at 15:52, (via RT)  wrote:
> 
> # New Ticket Created by   
> # Please include the string:  [perl #132236]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132236 >
> 
> 
> Hi,
> Given a module (Suptest.pm):
> 
>my package EXPORTHOW {
>   class SUPERSEDE::class is Metamodel::ClassHOW {
>   has $.foo;
>   }
>}
> 
> 
> Which is exercised with:
> 
>perl6 --ll-exception -I. -e 'use Suptest; class Bar {}'
> 
> This gives rise to:
> 
> Cannot find method 'EXPORTHOW::SUPERSEDE::class' on object of type 
> EXPORTHOW::SUPERSEDE::class
>   at gen/moar/BOOTSTRAP.nqp:3009  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/BOOTSTRAP.moarvm:)
> from gen/moar/stage2/NQPCORE.setting:521  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPCORE.setting.moarvm:BUILDALL)
> from gen/moar/Metamodel.nqp:3020  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Metamodel.moarvm:new)
> from gen/moar/Metamodel.nqp:3024  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Metamodel.moarvm:new_type)
> from src/Perl6/World.nqp:2868  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/World.moarvm:pkg_create_mo)
> from src/Perl6/Grammar.nqp:2369  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:)
> from src/Perl6/Grammar.nqp:2306  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:)
> from src/Perl6/Grammar.nqp:2300  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:package_def)
> from :1  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:package_declarator:sym)
> from gen/moar/stage2/QRegex.nqp:1721  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/QRegex.moarvm:!protoregex)
> from :1  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:package_declarator)
> from :1  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:term:sym)
> from gen/moar/stage2/QRegex.nqp:1721  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/QRegex.moarvm:!protoregex)
> from :1  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:term)
> from src/Perl6/Grammar.nqp:3940  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:termish)
> from gen/moar/stage2/NQPHLL.nqp:875  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:EXPR)
> from src/Perl6/Grammar.nqp:3980  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:EXPR)
> from src/Perl6/Grammar.nqp:1305  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statement)
> from src/Perl6/Grammar.nqp:1237  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statementlist)
> from gen/moar/stage2/NQPHLL.nqp:1105  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:LANG)
> from src/Perl6/Grammar.nqp:1676  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:FOREIGN_LANG)
> from src/Perl6/Grammar.nqp:1201  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:comp_unit)
> from src/Perl6/Grammar.nqp:508  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:TOP)
> from gen/moar/stage2/QRegex.nqp:2330  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/QRegex.moarvm:parse)
> from gen/moar/stage2/NQPHLL.nqp:1864  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:parse)
> from gen/moar/stage2/NQPHLL.nqp:1780  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:execute_stage)
> from gen/moar/stage2/NQPHLL.nqp:1813  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:run)
> from gen/moar/stage2/NQPHLL.nqp:1816  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:)
> from gen/moar/stage2/NQPHLL.nqp:1802  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:compile)
> from gen/moar/stage2/NQPHLL.nqp:1511  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:eval)
> from gen/moar/stage2/NQPHLL.nqp:1636  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:)
> from gen/moar/stage2/NQPHLL.nqp:1682  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:command_eval)
> from src/Perl6/Compiler.nqp:42  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Compiler.moarvm:command_eval)
> from gen/moar/stage2/NQPHLL.nqp:1617  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:command_line)
> from gen/moar/main.nqp:47  
> 

Re: [perl #132236] Possible regression in Meta object construction

[Elizabeth Mattijsen]

Fixed with dd943eded83edb3753 , tests needed.

> On 7 Oct 2017, at 15:52, (via RT)  wrote:
> 
> # New Ticket Created by   
> # Please include the string:  [perl #132236]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132236 >
> 
> 
> Hi,
> Given a module (Suptest.pm):
> 
>my package EXPORTHOW {
>   class SUPERSEDE::class is Metamodel::ClassHOW {
>   has $.foo;
>   }
>}
> 
> 
> Which is exercised with:
> 
>perl6 --ll-exception -I. -e 'use Suptest; class Bar {}'
> 
> This gives rise to:
> 
> Cannot find method 'EXPORTHOW::SUPERSEDE::class' on object of type 
> EXPORTHOW::SUPERSEDE::class
>   at gen/moar/BOOTSTRAP.nqp:3009  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/BOOTSTRAP.moarvm:)
> from gen/moar/stage2/NQPCORE.setting:521  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPCORE.setting.moarvm:BUILDALL)
> from gen/moar/Metamodel.nqp:3020  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Metamodel.moarvm:new)
> from gen/moar/Metamodel.nqp:3024  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Metamodel.moarvm:new_type)
> from src/Perl6/World.nqp:2868  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/World.moarvm:pkg_create_mo)
> from src/Perl6/Grammar.nqp:2369  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:)
> from src/Perl6/Grammar.nqp:2306  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:)
> from src/Perl6/Grammar.nqp:2300  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:package_def)
> from :1  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:package_declarator:sym)
> from gen/moar/stage2/QRegex.nqp:1721  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/QRegex.moarvm:!protoregex)
> from :1  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:package_declarator)
> from :1  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:term:sym)
> from gen/moar/stage2/QRegex.nqp:1721  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/QRegex.moarvm:!protoregex)
> from :1  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:term)
> from src/Perl6/Grammar.nqp:3940  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:termish)
> from gen/moar/stage2/NQPHLL.nqp:875  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:EXPR)
> from src/Perl6/Grammar.nqp:3980  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:EXPR)
> from src/Perl6/Grammar.nqp:1305  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statement)
> from src/Perl6/Grammar.nqp:1237  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statementlist)
> from gen/moar/stage2/NQPHLL.nqp:1105  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:LANG)
> from src/Perl6/Grammar.nqp:1676  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:FOREIGN_LANG)
> from src/Perl6/Grammar.nqp:1201  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:comp_unit)
> from src/Perl6/Grammar.nqp:508  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:TOP)
> from gen/moar/stage2/QRegex.nqp:2330  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/QRegex.moarvm:parse)
> from gen/moar/stage2/NQPHLL.nqp:1864  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:parse)
> from gen/moar/stage2/NQPHLL.nqp:1780  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:execute_stage)
> from gen/moar/stage2/NQPHLL.nqp:1813  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:run)
> from gen/moar/stage2/NQPHLL.nqp:1816  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:)
> from gen/moar/stage2/NQPHLL.nqp:1802  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:compile)
> from gen/moar/stage2/NQPHLL.nqp:1511  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:eval)
> from gen/moar/stage2/NQPHLL.nqp:1636  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:)
> from gen/moar/stage2/NQPHLL.nqp:1682  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:command_eval)
> from src/Perl6/Compiler.nqp:42  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Compiler.moarvm:command_eval)
> from gen/moar/stage2/NQPHLL.nqp:1617  
> (/home/jonathan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:command_line)
> from gen/moar/main.nqp:47  
> 

Re: [perl #132248] Z Metaoperator bug

[Elizabeth Mattijsen via RT]

> On 9 Oct 2017, at 10:38, jn...@jnthn.net via RT 
>  wrote:
> 
> On Sun, 08 Oct 2017 19:13:34 -0700, ipatrol6...@yahoo.com wrote:
>> As per a discussion on the IRC channel, I am requesting that a
>> regression bug be filed regarding the incorrect handling of variables
>> referenced to packages by the Z and X meta-operators.
>> 
>> The behavior over time is detailed here:
>> https://gist.github.com/Whateverable/83ce4a1ea73a429131713367ee23542e
>> 
>> Of those, the result given from 2015.09 to 2015.11 is the correct and
>> desired behavior, considering the design documents.
>> 
>> Doing a bisection:
>> https://gist.github.com/Whateverable/0a73f0433cee989d7a82ce8a601bd465
>> 
>> The regression revision appears to be:
>> https://github.com/rakudo/rakudo/commit/234287170cb7dd234ffc90271d762b1c106bc57f
>> 
> I think Z and X are doing the right thing: treating something in a Scalar 
> container as a single item. This is done consistently across the language, so 
> you'll observe this behavior in many more constructs.
> 
> The surprise here is that we get a Scalar container in the first place:
> 
> $ perl6-m -e 'my @A::B = (1..8); say @A::B.VAR.WHAT; my @B = (1..8); say 
> @B.VAR.WHAT'
> (Scalar)
> (Array)
> 
> I suspect that's happening because a package's symbol table is a Stash, which 
> is just a subclass of Hash, and this code is relying on autovivification, 
> which always involves a Scalar container. It probably should instead, 
> somehow, be arranging than an Array is bound directly into the Stash. Then Z, 
> X, and plenty more things would work less surprisingly. A `my %A::B` is 
> likely exhibiting the same kind of problem at the moment too.

FWIW, I think this is not a matter of a Array being wrapped into a Scalar.

my @A::B and my %A::B *are* scalars, regardless of their sigil.  Feels like a 
case of sigil inspection on the last element of split ‘::’ on the full name, 
instead of on the first.

Re: [perl #132248] Z Metaoperator bug

[Elizabeth Mattijsen]

> On 9 Oct 2017, at 10:38, jn...@jnthn.net via RT 
>  wrote:
> 
> On Sun, 08 Oct 2017 19:13:34 -0700, ipatrol6...@yahoo.com wrote:
>> As per a discussion on the IRC channel, I am requesting that a
>> regression bug be filed regarding the incorrect handling of variables
>> referenced to packages by the Z and X meta-operators.
>> 
>> The behavior over time is detailed here:
>> https://gist.github.com/Whateverable/83ce4a1ea73a429131713367ee23542e
>> 
>> Of those, the result given from 2015.09 to 2015.11 is the correct and
>> desired behavior, considering the design documents.
>> 
>> Doing a bisection:
>> https://gist.github.com/Whateverable/0a73f0433cee989d7a82ce8a601bd465
>> 
>> The regression revision appears to be:
>> https://github.com/rakudo/rakudo/commit/234287170cb7dd234ffc90271d762b1c106bc57f
>> 
> I think Z and X are doing the right thing: treating something in a Scalar 
> container as a single item. This is done consistently across the language, so 
> you'll observe this behavior in many more constructs.
> 
> The surprise here is that we get a Scalar container in the first place:
> 
> $ perl6-m -e 'my @A::B = (1..8); say @A::B.VAR.WHAT; my @B = (1..8); say 
> @B.VAR.WHAT'
> (Scalar)
> (Array)
> 
> I suspect that's happening because a package's symbol table is a Stash, which 
> is just a subclass of Hash, and this code is relying on autovivification, 
> which always involves a Scalar container. It probably should instead, 
> somehow, be arranging than an Array is bound directly into the Stash. Then Z, 
> X, and plenty more things would work less surprisingly. A `my %A::B` is 
> likely exhibiting the same kind of problem at the moment too.

FWIW, I think this is not a matter of a Array being wrapped into a Scalar.

my @A::B and my %A::B *are* scalars, regardless of their sigil.  Feels like a 
case of sigil inspection on the last element of split ‘::’ on the full name, 
instead of on the first.

Re: [perl #132249] [LTA] use lib ‘’ spills guts (use lib ‘’)

[Elizabeth Mattijsen]

Fixed with 56eef6967b54b16c , tests needed

> On 9 Oct 2017, at 06:38, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #132249]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132249 >
> 
> 
> Code:
> use lib ‘’
> 
> Result:
> ===SORRY!===
> Too few positionals passed to 'repository-for-spec'; expected 3 arguments but 
> got 0
> 
> 
> Also there's no line number.

Re: [perl #132246] .pick and .roll return incorrect results for object hashes

[Elizabeth Mattijsen via RT]

Fixed with 12fcece494e12b , tests needed

> On 8 Oct 2017, at 13:18, Peter du Marchie van Voorthuysen (via RT) 
>  wrote:
> 
> # New Ticket Created by  Peter du Marchie van Voorthuysen 
> # Please include the string:  [perl #132246]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132246 >
> 
> 
> This is Rakudo version 2017.07 built on MoarVM version 2017.07
> implementing Perl 6.c.
> 
> For regular hashes the methods .pick and .roll return the expected results:
> 
>> use Test;
> Nil;
>> my %str = question => 42;
> {question => 42}
>> is %str.pick, %str.pairs.pick;
> ok 1 -
> True
>> is %str.roll, %str.pairs.roll;
> ok 2 -
> True
> 
> But these methods appear to be unaware of the object hash abstraction:
> 
>> my %obj{Any} = question => 42;
> {question => 42}
>> is %obj.pick, %obj.pairs.pick;
> not ok 3 -
> 
> # Failed test at  line 1
> # expected: 'question   42'
> #  got: 'Str|question   question42'
> False
>> is %obj.roll, %obj.pairs.roll;
> not ok 4 -
> 
> # Failed test at  line 1
> # expected: 'question   42'
> #  got: 'Str|question   question42'
> False

Re: [perl #132246] .pick and .roll return incorrect results for object hashes

[Elizabeth Mattijsen]

Fixed with 12fcece494e12b , tests needed

> On 8 Oct 2017, at 13:18, Peter du Marchie van Voorthuysen (via RT) 
>  wrote:
> 
> # New Ticket Created by  Peter du Marchie van Voorthuysen 
> # Please include the string:  [perl #132246]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132246 >
> 
> 
> This is Rakudo version 2017.07 built on MoarVM version 2017.07
> implementing Perl 6.c.
> 
> For regular hashes the methods .pick and .roll return the expected results:
> 
>> use Test;
> Nil;
>> my %str = question => 42;
> {question => 42}
>> is %str.pick, %str.pairs.pick;
> ok 1 -
> True
>> is %str.roll, %str.pairs.roll;
> ok 2 -
> True
> 
> But these methods appear to be unaware of the object hash abstraction:
> 
>> my %obj{Any} = question => 42;
> {question => 42}
>> is %obj.pick, %obj.pairs.pick;
> not ok 3 -
> 
> # Failed test at  line 1
> # expected: 'question   42'
> #  got: 'Str|question   question42'
> False
>> is %obj.roll, %obj.pairs.roll;
> not ok 4 -
> 
> # Failed test at  line 1
> # expected: 'question   42'
> #  got: 'Str|question   question42'
> False

Re: [perl #132156] [LTA] Suggest polymod for bases > 36 (9123607.base(37))

[Elizabeth Mattijsen via RT]

> On 25 Sep 2017, at 08:21, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #132156]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132156 >
> 
> 
> Code:
> say 9123607.base(37)
> 
> Result:
> base argument to base out of range. Is: 37, should be in 2..36
>  in block  at  line 1
> 
> 
> The error message can suggest .polymod, here is an example:
> 
> 9123607.polymod(37 xx *).reverse # (4 32 4 15 36)

Perhaps .base(37) should just use .polymod under the hood?

Re: [perl #132156] [LTA] Suggest polymod for bases > 36 (9123607.base(37))

[Elizabeth Mattijsen]

> On 25 Sep 2017, at 08:21, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #132156]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132156 >
> 
> 
> Code:
> say 9123607.base(37)
> 
> Result:
> base argument to base out of range. Is: 37, should be in 2..36
>  in block  at  line 1
> 
> 
> The error message can suggest .polymod, here is an example:
> 
> 9123607.polymod(37 xx *).reverse # (4 32 4 15 36)

Perhaps .base(37) should just use .polymod under the hood?

Re: [perl #132121] [REGEX] (RFC?) Overflow of writing to captures

[Elizabeth Mattijsen via RT]

> On 18 Sep 2017, at 19:45, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #132121]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132121 >
> 
> 
> Apparently it's possible to assign to capture variables to change what the 
> resultant Match will have.
> 
> The first question: is this actually something specced and supported? 
> Especially the fact that further captures continue their numbering from the 
> capture we wrote into:
> 
>m: say "hi hi ho" ~~ /(\w+) \s+ $10=[$0] \s+ (\w+)/
>rakudo-moar 476741: OUTPUT: «｢hi hi ho｣␤ 0 => ｢hi｣␤ 10 => ｢hi｣␤ 11 => 
> ｢ho｣␤»
> 
> 
> If it's not, it needs to be plugged up. And if it is, then it has this is the 
> bug with overflow:
> 
>m: say "hi" ~~ / 
> $10=(\w) (.)/
>rakudo-moar 476741: OUTPUT: «｢hi｣␤ -6917529027641081856 => ｢h｣␤ 0 => ｢i｣␤»

Odd.  One would expect something like:

$ 6 'use nqp; my $l := nqp::list; 
nqp::bindpos($l,10,42)'
Cannot unbox 203 bit wide bigint into native integer

for an error.

Re: [perl #132121] [REGEX] (RFC?) Overflow of writing to captures

[Elizabeth Mattijsen]

> On 18 Sep 2017, at 19:45, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #132121]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132121 >
> 
> 
> Apparently it's possible to assign to capture variables to change what the 
> resultant Match will have.
> 
> The first question: is this actually something specced and supported? 
> Especially the fact that further captures continue their numbering from the 
> capture we wrote into:
> 
>m: say "hi hi ho" ~~ /(\w+) \s+ $10=[$0] \s+ (\w+)/
>rakudo-moar 476741: OUTPUT: «｢hi hi ho｣␤ 0 => ｢hi｣␤ 10 => ｢hi｣␤ 11 => 
> ｢ho｣␤»
> 
> 
> If it's not, it needs to be plugged up. And if it is, then it has this is the 
> bug with overflow:
> 
>m: say "hi" ~~ / 
> $10=(\w) (.)/
>rakudo-moar 476741: OUTPUT: «｢hi｣␤ -6917529027641081856 => ｢h｣␤ 0 => ｢i｣␤»

Odd.  One would expect something like:

$ 6 'use nqp; my $l := nqp::list; 
nqp::bindpos($l,10,42)'
Cannot unbox 203 bit wide bigint into native integer

for an error.

Re: [perl #132117] [LTA] Error on `eqv` with lazy Lists

[Elizabeth Mattijsen via RT]

Fixed with 66c2d05f29 , tests need attention in S03-operators/eqv.t

> On 18 Sep 2017, at 14:51, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #132117]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132117 >
> 
> 
> If you `eqv` two lazy Seqs, you get a useful error:
> 
>m: say (lazy 1,) eqv (lazy 1,)
>rakudo-moar 9190a3: OUTPUT: «Cannot eqv lazy Sequences␤  in block  
> at  line 1␤␤»
> 
> But error is poor with lazy Lists:
> 
>m: say (lazy 1,).List eqv (lazy 1,).List
>rakudo-moar 9190a3: OUTPUT: «This type cannot unbox to a native integer: 
> P6opaque, Failure␤  in block  at  line 1␤␤»

Re: [perl #132117] [LTA] Error on `eqv` with lazy Lists

[Elizabeth Mattijsen]

Fixed with 66c2d05f29 , tests need attention in S03-operators/eqv.t

> On 18 Sep 2017, at 14:51, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #132117]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132117 >
> 
> 
> If you `eqv` two lazy Seqs, you get a useful error:
> 
>m: say (lazy 1,) eqv (lazy 1,)
>rakudo-moar 9190a3: OUTPUT: «Cannot eqv lazy Sequences␤  in block  
> at  line 1␤␤»
> 
> But error is poor with lazy Lists:
> 
>m: say (lazy 1,).List eqv (lazy 1,).List
>rakudo-moar 9190a3: OUTPUT: «This type cannot unbox to a native integer: 
> P6opaque, Failure␤  in block  at  line 1␤␤»

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

[Elizabeth Mattijsen via RT]

> On 18 Sep 2017, at 04:39, Brian S. Julin via RT 
>  wrote:
> 
> On Sun, 17 Sep 2017 08:44:47 -0700, c...@zoffix.com wrote:
>> More comments on similar issue: https://irclog.perlgeek.de/perl6/2017-
>> 09-17#i_15176823
>> 
>> Basically, a lot of core constructs aren't workable with user-land
>> subclasses.
> 
> Note on the performance concerns... if we had a faster-than-a-where-clause 
> type smiley
> (or other mechanism) that only accepted the exact type, not subclasses, then
> the core could provide very optimized implementations for core types as 
> separate
> candidates, and a more generic implementation for subclasses, which would be 
> slower
> but less likely to be affected by internals churn.

Technical note: that would mean internally using nqp::eqaddr vs nqp::istype.

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

[Elizabeth Mattijsen]

> On 18 Sep 2017, at 04:39, Brian S. Julin via RT 
>  wrote:
> 
> On Sun, 17 Sep 2017 08:44:47 -0700, c...@zoffix.com wrote:
>> More comments on similar issue: https://irclog.perlgeek.de/perl6/2017-
>> 09-17#i_15176823
>> 
>> Basically, a lot of core constructs aren't workable with user-land
>> subclasses.
> 
> Note on the performance concerns... if we had a faster-than-a-where-clause 
> type smiley
> (or other mechanism) that only accepted the exact type, not subclasses, then
> the core could provide very optimized implementations for core types as 
> separate
> candidates, and a more generic implementation for subclasses, which would be 
> slower
> but less likely to be affected by internals churn.

Technical note: that would mean internally using nqp::eqaddr vs nqp::istype.

Re: [perl #132109] [BUG] `.skip` on a sequence starting with a `Slip`, returns a corrupted `Seq`

[Elizabeth Mattijsen]

> On 17 Sep 2017, at 07:29, Sam S. (via RT)  
> wrote:
> 
> # New Ticket Created by  Sam S. 
> # Please include the string:  [perl #132109]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132109 >
> 
> 
> When calling `.skip` on a list which contains a `Slip` at the start, the 
> resulting `Seq` behaves in some cases as if *all* elements from that 
> `Slip` were skipped (instead of just the first one):
> 
> say (, ).map(|*).skip.perl;# ("d", "e").Seq
> say (, ).map(|*).skip.eager.perl;  # ("d", "e").Seq
> say (, ).map(|*).skip.eager.gist;  # (d e)
> say (, ).map(|*).skip.eager.join;  # de
> say (, ).map(|*).skip.cache.perl;  # ("d", "e")
> say (, ).map(|*).skip.cache.join;  # de
> say (, ).map(|*).skip.[*].gist;# (d e)
> 
> But it depends on how the returned `Seq` is iterated. In the following 
> cases it behaves correctly:
> 
> say (, ).map(|*).skip.gist;   # (b c d e)
> say (, ).map(|*).skip.join;   # bcde
> say (, ).map(|*).skip.cache.gist; # (b c d e)
> say (, ).map(|*).skip.[0..*].gist;# (b c d e)
> say (, ).map(|*).skip.iterator.pull-one;  # b
> 
> It looks like¹ this bug has existed ever since the `.skip` method was 
> implemented² in January 2017.
> 
> ---
> [1] https://gist.github.com/Whateverable/973c1b6cb09af28a2249b4ba33165885
> [2] https://github.com/rakudo/rakudo/commit/8a6bfc6

I think he problem here is in Seq.cache.  Investigating...

Re: [perl #132109] [BUG] `.skip` on a sequence starting with a `Slip`, returns a corrupted `Seq`

[Elizabeth Mattijsen via RT]

> On 17 Sep 2017, at 07:29, Sam S. (via RT)  
> wrote:
> 
> # New Ticket Created by  Sam S. 
> # Please include the string:  [perl #132109]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132109 >
> 
> 
> When calling `.skip` on a list which contains a `Slip` at the start, the 
> resulting `Seq` behaves in some cases as if *all* elements from that 
> `Slip` were skipped (instead of just the first one):
> 
> say (, ).map(|*).skip.perl;# ("d", "e").Seq
> say (, ).map(|*).skip.eager.perl;  # ("d", "e").Seq
> say (, ).map(|*).skip.eager.gist;  # (d e)
> say (, ).map(|*).skip.eager.join;  # de
> say (, ).map(|*).skip.cache.perl;  # ("d", "e")
> say (, ).map(|*).skip.cache.join;  # de
> say (, ).map(|*).skip.[*].gist;# (d e)
> 
> But it depends on how the returned `Seq` is iterated. In the following 
> cases it behaves correctly:
> 
> say (, ).map(|*).skip.gist;   # (b c d e)
> say (, ).map(|*).skip.join;   # bcde
> say (, ).map(|*).skip.cache.gist; # (b c d e)
> say (, ).map(|*).skip.[0..*].gist;# (b c d e)
> say (, ).map(|*).skip.iterator.pull-one;  # b
> 
> It looks like¹ this bug has existed ever since the `.skip` method was 
> implemented² in January 2017.
> 
> ---
> [1] https://gist.github.com/Whateverable/973c1b6cb09af28a2249b4ba33165885
> [2] https://github.com/rakudo/rakudo/commit/8a6bfc6

I think he problem here is in Seq.cache.  Investigating...

Re: [perl #132030] [REGRESSION] Broken Text::CSV tests and possibly other ecosystem fallout

[Elizabeth Mattijsen]

Fixed with 3c9cfdba88287e23e0ced8  (and further refined by later commits), 
tests needed.

> On 6 Sep 2017, at 15:38, jn...@jnthn.net via RT 
>  wrote:
> 
> On Tue, 05 Sep 2017 09:11:19 -0700, allber...@gmail.com wrote:
>> On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via RT <
>> perl6-bugs-follo...@perl.org> wrote:
>> 
>>> Failing to close output handles has been clearly documented (and yes,
>>> documented well before the recent buffering change) as something that can
>>> cause data loss. Default output buffering just makes it quite a lot more
>>> likely to show up.
>>> 
>>> While there will be some ecosystem fallout like this, unfortunately I
>>> don't think it's avoidable. If we whip out the patch that turns output
>>> buffering on by default for non-TTYs for this release, then when will we
>>> include it? The longer we leave it, the more painful it will be, because
>>> more code will be written that is careless with handles.
>>> 
>>> I don't think "leave it off by default" is a good option either, otherwise
>>> we get to spend the next decade hearing "Perl 6 I/O is slow" because it'd
>>> be one of the only languages that doesn't buffer its output without an
>>> explicit flag being passed to enable that (which nearly nobody doing quick
>>> benchmarks will know to use).
>>> 
>> 
>> Are we missing something to flush/close handles at exit? Leaving it to a GC
>> that may not finalize before exit is not really an option.
>> 
> To recap the IRC discussion yesterday: no, we haven't had this so far (except 
> for stdout/stderr), and have gotten away with it due to the lack of output 
> buffering. At present, we can either choose between:
> 
> 1) Start keeping a list of open files, and at exit close them (flushing is 
> already part of closing). This can be done at Perl 6 level, in the same place 
> we make sure to run END blocks.
> 
> 2) Having unclosed handles possible to GC, and closing them if/when they get 
> GC'd.
> 
> Today we are doing #2. We could switch to doing #1. We can't currently do 
> both, because the moment we start keeping a list of open handles then they 
> can't be GC'd, and so #2 can't happen.
> 
> My initial inclination was to preserve behavior #2, though others have 
> pointed out that behavior #1 is more useful for debugging in that it ensures 
> log files, for example, will be written in the event of a crash, and a 
> program relying on behavior #2 could already run out of handles today anyway 
> if it were less lucky with GC timing. This is a fair argument, and the 
> automatic close at exit might be softer on the ecosystem too (but would have 
> done nothing for the Text::CSV case, which is the original subject of this 
> ticket, because it wrote a file, didn't close it, then separately opened it 
> for reading).
> 
> There's probably enough consensus to switch to option #1, and lizmat++ 
> mentioned maybe looking into a patch to do that.
> 
> In the longer run, we can have both, but it depends on implementing weak 
> references. In terms of backend support, the JVM does have them, and it seems 
> there's an npm package [1] exposing v8 weak refs so a Node.js backend could 
> support that also. I'm OK with adding them to MoarVM in the future, but both 
> doing that and exposing weak references at Perl 6 level would be a non-small, 
> and certainly non-trivial, task.

Re: [perl #132030] [REGRESSION] Broken Text::CSV tests and possibly other ecosystem fallout

[Elizabeth Mattijsen via RT]

Fixed with 3c9cfdba88287e23e0ced8  (and further refined by later commits), 
tests needed.

> On 6 Sep 2017, at 15:38, jn...@jnthn.net via RT 
>  wrote:
> 
> On Tue, 05 Sep 2017 09:11:19 -0700, allber...@gmail.com wrote:
>> On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via RT <
>> perl6-bugs-follo...@perl.org> wrote:
>> 
>>> Failing to close output handles has been clearly documented (and yes,
>>> documented well before the recent buffering change) as something that can
>>> cause data loss. Default output buffering just makes it quite a lot more
>>> likely to show up.
>>> 
>>> While there will be some ecosystem fallout like this, unfortunately I
>>> don't think it's avoidable. If we whip out the patch that turns output
>>> buffering on by default for non-TTYs for this release, then when will we
>>> include it? The longer we leave it, the more painful it will be, because
>>> more code will be written that is careless with handles.
>>> 
>>> I don't think "leave it off by default" is a good option either, otherwise
>>> we get to spend the next decade hearing "Perl 6 I/O is slow" because it'd
>>> be one of the only languages that doesn't buffer its output without an
>>> explicit flag being passed to enable that (which nearly nobody doing quick
>>> benchmarks will know to use).
>>> 
>> 
>> Are we missing something to flush/close handles at exit? Leaving it to a GC
>> that may not finalize before exit is not really an option.
>> 
> To recap the IRC discussion yesterday: no, we haven't had this so far (except 
> for stdout/stderr), and have gotten away with it due to the lack of output 
> buffering. At present, we can either choose between:
> 
> 1) Start keeping a list of open files, and at exit close them (flushing is 
> already part of closing). This can be done at Perl 6 level, in the same place 
> we make sure to run END blocks.
> 
> 2) Having unclosed handles possible to GC, and closing them if/when they get 
> GC'd.
> 
> Today we are doing #2. We could switch to doing #1. We can't currently do 
> both, because the moment we start keeping a list of open handles then they 
> can't be GC'd, and so #2 can't happen.
> 
> My initial inclination was to preserve behavior #2, though others have 
> pointed out that behavior #1 is more useful for debugging in that it ensures 
> log files, for example, will be written in the event of a crash, and a 
> program relying on behavior #2 could already run out of handles today anyway 
> if it were less lucky with GC timing. This is a fair argument, and the 
> automatic close at exit might be softer on the ecosystem too (but would have 
> done nothing for the Text::CSV case, which is the original subject of this 
> ticket, because it wrote a file, didn't close it, then separately opened it 
> for reading).
> 
> There's probably enough consensus to switch to option #1, and lizmat++ 
> mentioned maybe looking into a patch to do that.
> 
> In the longer run, we can have both, but it depends on implementing weak 
> references. In terms of backend support, the JVM does have them, and it seems 
> there's an npm package [1] exposing v8 weak refs so a Node.js backend could 
> support that also. I'm OK with adding them to MoarVM in the future, but both 
> doing that and exposing weak references at Perl 6 level would be a non-small, 
> and certainly non-trivial, task.

Re: [perl #132042] [BUG] rakudo hangs while concurrently walking trees

[Elizabeth Mattijsen via RT]

> On 6 Sep 2017, at 22:46, J . David Lowe (via RT) 
>  wrote:
> 
> # New Ticket Created by  J . David Lowe 
> # Please include the string:  [perl #132042]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132042 >
> 
> 
> This short program hangs indefinitely on my system (after making progress.) 
> Tuning the number of threads and number of iterations can change how reliably 
> it hangs (down to 'never' when the number of threads is < 3, for me.)
> 
> ```
> #!/usr/bin/env perl6
> 
> use v6.c;
> 
> await (^6).map: -> $t {
>   start {
>  for (^500) -> $i {
> my $current = %( 1 => %( 2 => %( 3 => %() ) ) );
> my $index = 1;
> while $current{$index}:exists {
>say "$t $i $index";
>$current = $current{$index};
>++$index;
> }
>  }
>   }
> }
> ```
> 
> ... this is a distilled version of some tree-walking code that's misbehaving 
> for me IRL. It's possible that I'm doing something naughty here, but I don't 
> see how. Am I missing something? (I can eliminate the deadlock by 
> Lock.protect-ing the inner while loop, FWIW... but I don't see why that 
> should be necessary.)
> 
> More information:
> 
> ```
> $ perl6 --version
> This is Rakudo version 2017.07 built on MoarVM version 2017.07
> implementing Perl 6.c.
> ```

Could you try if this is still the case in 2017.08?  And possibly the latest 
development version?

Also, could you try and see if “use 6.d.PREVIEW” makes a difference?

Re: [perl #132042] [BUG] rakudo hangs while concurrently walking trees

[Elizabeth Mattijsen]

> On 6 Sep 2017, at 22:46, J . David Lowe (via RT) 
>  wrote:
> 
> # New Ticket Created by  J . David Lowe 
> # Please include the string:  [perl #132042]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132042 >
> 
> 
> This short program hangs indefinitely on my system (after making progress.) 
> Tuning the number of threads and number of iterations can change how reliably 
> it hangs (down to 'never' when the number of threads is < 3, for me.)
> 
> ```
> #!/usr/bin/env perl6
> 
> use v6.c;
> 
> await (^6).map: -> $t {
>   start {
>  for (^500) -> $i {
> my $current = %( 1 => %( 2 => %( 3 => %() ) ) );
> my $index = 1;
> while $current{$index}:exists {
>say "$t $i $index";
>$current = $current{$index};
>++$index;
> }
>  }
>   }
> }
> ```
> 
> ... this is a distilled version of some tree-walking code that's misbehaving 
> for me IRL. It's possible that I'm doing something naughty here, but I don't 
> see how. Am I missing something? (I can eliminate the deadlock by 
> Lock.protect-ing the inner while loop, FWIW... but I don't see why that 
> should be necessary.)
> 
> More information:
> 
> ```
> $ perl6 --version
> This is Rakudo version 2017.07 built on MoarVM version 2017.07
> implementing Perl 6.c.
> ```

Could you try if this is still the case in 2017.08?  And possibly the latest 
development version?

Also, could you try and see if “use 6.d.PREVIEW” makes a difference?

Re: [perl #132030] [REGRESSION] Broken Text::CSV tests and possibly other ecosystem fallout

[Elizabeth Mattijsen via RT]

> On 6 Sep 2017, at 15:38, jn...@jnthn.net via RT 
>  wrote:
> To recap the IRC discussion yesterday: no, we haven't had this so far (except 
> for stdout/stderr), and have gotten away with it due to the lack of output 
> buffering. At present, we can either choose between:
> 
> 1) Start keeping a list of open files, and at exit close them (flushing is 
> already part of closing). This can be done at Perl 6 level, in the same place 
> we make sure to run END blocks.
> 
> 2) Having unclosed handles possible to GC, and closing them if/when they get 
> GC'd.
> 
> Today we are doing #2. We could switch to doing #1. We can't currently do 
> both, because the moment we start keeping a list of open handles then they 
> can't be GC'd, and so #2 can't happen.
> 
> My initial inclination was to preserve behavior #2, though others have 
> pointed out that behavior #1 is more useful for debugging in that it ensures 
> log files, for example, will be written in the event of a crash, and a 
> program relying on behavior #2 could already run out of handles today anyway 
> if it were less lucky with GC timing. This is a fair argument, and the 
> automatic close at exit might be softer on the ecosystem too (but would have 
> done nothing for the Text::CSV case, which is the original subject of this 
> ticket, because it wrote a file, didn't close it, then separately opened it 
> for reading).
> 
> There's probably enough consensus to switch to option #1, and lizmat++ 
> mentioned maybe looking into a patch to do that.

FWIW, I have a patch, but it causes t/spec/S32-io/lock.t to hang in test #6.  
Trying to find out what is going on there right now.


Liz

Re: [perl #132030] [REGRESSION] Broken Text::CSV tests and possibly other ecosystem fallout

[Elizabeth Mattijsen]

> On 6 Sep 2017, at 15:38, jn...@jnthn.net via RT 
>  wrote:
> To recap the IRC discussion yesterday: no, we haven't had this so far (except 
> for stdout/stderr), and have gotten away with it due to the lack of output 
> buffering. At present, we can either choose between:
> 
> 1) Start keeping a list of open files, and at exit close them (flushing is 
> already part of closing). This can be done at Perl 6 level, in the same place 
> we make sure to run END blocks.
> 
> 2) Having unclosed handles possible to GC, and closing them if/when they get 
> GC'd.
> 
> Today we are doing #2. We could switch to doing #1. We can't currently do 
> both, because the moment we start keeping a list of open handles then they 
> can't be GC'd, and so #2 can't happen.
> 
> My initial inclination was to preserve behavior #2, though others have 
> pointed out that behavior #1 is more useful for debugging in that it ensures 
> log files, for example, will be written in the event of a crash, and a 
> program relying on behavior #2 could already run out of handles today anyway 
> if it were less lucky with GC timing. This is a fair argument, and the 
> automatic close at exit might be softer on the ecosystem too (but would have 
> done nothing for the Text::CSV case, which is the original subject of this 
> ticket, because it wrote a file, didn't close it, then separately opened it 
> for reading).
> 
> There's probably enough consensus to switch to option #1, and lizmat++ 
> mentioned maybe looking into a patch to do that.

FWIW, I have a patch, but it causes t/spec/S32-io/lock.t to hang in test #6.  
Trying to find out what is going on there right now.


Liz

Re: [perl #132029] Floppage of atomic tests

[Elizabeth Mattijsen via RT]

FWIW, I couldn’t get this to fail on my MBP *while* running make spectest with 
TEST_JOBS=8

Perhaps this is OS / CPU / compiler dependent?

> On 5 Sep 2017, at 09:17, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> Oh. A crude way to reproduce it is:
> 
> while :; do clear; PERL6LIB=lib ./perl6-m t/spec/S17-lowlevel/atomic-ops.t ||
> break; done
> 
> And just leave it running, it'll fail at some point. Get your system busy with
> something and it'll fail faster.
> 
> On 2017-09-05 00:14:11, alex.jakime...@gmail.com wrote:
>> Here's the output when it fails:
>> 
>> ok 1 - Can do an atomic fetch from a Scalar container
>> ok 2 - Can do an atomic assign to a Scalar container; returns new
>> value
>> ok 3 - Atomic fetch after atomic assign shows latest value
>> ok 4 - Updated value seen by non-atomic too
>> 1..2
>> ok 1 - code dies
>> ok 2 - right exception type (X::TypeCheck::Assignment)
>> ok 5 - Cannot atomic assign value of the wrong type
>> ok 6 - No hang due to incorrect lifting of atomic fetch out of loop
>> ok 7 - Can do an atomic fetch from an int container
>> ok 8 - Can do an atomic assign to an int container; returns new value
>> ok 9 - Atomic int fetch after atomic int assign shows latest value
>> ok 10 - Updated value seen by non-atomic too
>> A IntLexRef container does not know how to do an atomic load
>> in block  at t/spec/S17-lowlevel/atomic-ops.t line 41
>> 
>> # Looks like you planned 28 tests, but ran 10
>> 
>> 
>> I noticed that it fails more often when the system is under load (e.g.
>> when running the spectest). Other than that I don't have any info.

Re: [perl #132029] Floppage of atomic tests

[Elizabeth Mattijsen]

FWIW, I couldn’t get this to fail on my MBP *while* running make spectest with 
TEST_JOBS=8

Perhaps this is OS / CPU / compiler dependent?

> On 5 Sep 2017, at 09:17, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> Oh. A crude way to reproduce it is:
> 
> while :; do clear; PERL6LIB=lib ./perl6-m t/spec/S17-lowlevel/atomic-ops.t ||
> break; done
> 
> And just leave it running, it'll fail at some point. Get your system busy with
> something and it'll fail faster.
> 
> On 2017-09-05 00:14:11, alex.jakime...@gmail.com wrote:
>> Here's the output when it fails:
>> 
>> ok 1 - Can do an atomic fetch from a Scalar container
>> ok 2 - Can do an atomic assign to a Scalar container; returns new
>> value
>> ok 3 - Atomic fetch after atomic assign shows latest value
>> ok 4 - Updated value seen by non-atomic too
>> 1..2
>> ok 1 - code dies
>> ok 2 - right exception type (X::TypeCheck::Assignment)
>> ok 5 - Cannot atomic assign value of the wrong type
>> ok 6 - No hang due to incorrect lifting of atomic fetch out of loop
>> ok 7 - Can do an atomic fetch from an int container
>> ok 8 - Can do an atomic assign to an int container; returns new value
>> ok 9 - Atomic int fetch after atomic int assign shows latest value
>> ok 10 - Updated value seen by non-atomic too
>> A IntLexRef container does not know how to do an atomic load
>> in block  at t/spec/S17-lowlevel/atomic-ops.t line 41
>> 
>> # Looks like you planned 28 tests, but ran 10
>> 
>> 
>> I noticed that it fails more often when the system is under load (e.g.
>> when running the spectest). Other than that I don't have any info.

Re: [perl #132006] Instant.Instant is missing (say now.Instant)

[Elizabeth Mattijsen via RT]

Fixed with 51709e01c0788c466af , tests needed.

> On 31 Aug 2017, at 22:05, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #132006]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132006 >
> 
> 
> Code:
> say now.Instant
> 
> Result:
> No such method 'Instant' for invocant of type 'Instant'
>  in block  at  line 1
> 
> 
>  hmmm... that feels like an omission  :-)

Re: [perl #132006] Instant.Instant is missing (say now.Instant)

[Elizabeth Mattijsen]

Fixed with 51709e01c0788c466af , tests needed.

> On 31 Aug 2017, at 22:05, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #132006]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132006 >
> 
> 
> Code:
> say now.Instant
> 
> Result:
> No such method 'Instant' for invocant of type 'Instant'
>  in block  at  line 1
> 
> 
>  hmmm... that feels like an omission  :-)

Re: [perl #131962] [REGRESSION] `Pair.kv`/`.keys`/.`values` dies if either the key or the value is `Mu`

[Elizabeth Mattijsen via RT]

Fixed with a5014fd0855545cc083b3590 , tests needed.

> On 26 Aug 2017, at 13:10, Sam S. (via RT)  
> wrote:
> 
> # New Ticket Created by  Sam S. 
> # Please include the string:  [perl #131962]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131962 >
> 
> 
> ➜  say (4 => Mu).kv;
> Type check failed in binding to parameter 'val2';
> expected Any but got Mu (Mu)
> 
> ➜  say ((Mu) => 4).kv;
> Type check failed in binding to parameter 'val1';
> expected Any but got Mu (Mu)
> 
> ➜  say ((Mu) => Mu).kv;
> Type check failed in binding to parameter 'val1';
> expected Any but got Mu (Mu)
> 
> `Pair` methods that are affected:
> .kv
> .keys
> .values
> 
> `Pair` methods that NOT are affected:
> .key
> .value
> .pairs
> .antipairs
> .Str
> .gist
> .perl
> 
> bisectable finds that this was broken two weeks ago:
> 
> https://gist.github.com/Whateverable/03a10377df0b3e0409eaa69330750868
> 
> https://github.com/rakudo/rakudo/commit/30584dac2fe231038c5bea557946a41310e9fd0f

Re: [perl #131962] [REGRESSION] `Pair.kv`/`.keys`/.`values` dies if either the key or the value is `Mu`

[Elizabeth Mattijsen]

Fixed with a5014fd0855545cc083b3590 , tests needed.

> On 26 Aug 2017, at 13:10, Sam S. (via RT)  
> wrote:
> 
> # New Ticket Created by  Sam S. 
> # Please include the string:  [perl #131962]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131962 >
> 
> 
> ➜  say (4 => Mu).kv;
> Type check failed in binding to parameter 'val2';
> expected Any but got Mu (Mu)
> 
> ➜  say ((Mu) => 4).kv;
> Type check failed in binding to parameter 'val1';
> expected Any but got Mu (Mu)
> 
> ➜  say ((Mu) => Mu).kv;
> Type check failed in binding to parameter 'val1';
> expected Any but got Mu (Mu)
> 
> `Pair` methods that are affected:
> .kv
> .keys
> .values
> 
> `Pair` methods that NOT are affected:
> .key
> .value
> .pairs
> .antipairs
> .Str
> .gist
> .perl
> 
> bisectable finds that this was broken two weeks ago:
> 
> https://gist.github.com/Whateverable/03a10377df0b3e0409eaa69330750868
> 
> https://github.com/rakudo/rakudo/commit/30584dac2fe231038c5bea557946a41310e9fd0f

Re: [perl #126951] [BUG] Interpolating a typed hash into an argument list produces wrong keys

[Elizabeth Mattijsen]

Fixed with 6cec6b7218650aff1780a4dd , tests needed

> On 26 Aug 2017, at 10:35, Sam S. via RT  wrote:
> 
> Shorter test-case:
> 
>➜  say :{ a => 1, b => 2 }.FLATTENABLE_HASH;
>{Str|a => a => 1, Str|b => b => 2}
> 
> Compare to a normal Hash which works fine:
> 
>➜  say { a => 1, b => 2 }.FLATTENABLE_HASH;
>{a => 1, b => 2}

Re: [perl #126951] [BUG] Interpolating a typed hash into an argument list produces wrong keys

[Elizabeth Mattijsen via RT]

Fixed with 6cec6b7218650aff1780a4dd , tests needed

> On 26 Aug 2017, at 10:35, Sam S. via RT  wrote:
> 
> Shorter test-case:
> 
>➜  say :{ a => 1, b => 2 }.FLATTENABLE_HASH;
>{Str|a => a => 1, Str|b => b => 2}
> 
> Compare to a normal Hash which works fine:
> 
>➜  say { a => 1, b => 2 }.FLATTENABLE_HASH;
>{a => 1, b => 2}

Re: [perl #131919] [RFC] Returning Failure from failed P6-level .parse

[Elizabeth Mattijsen via RT]

> On 17 Aug 2017, at 18:11, Zoffix Znet via RT  
> wrote:
> 
> On Thu, 17 Aug 2017 08:50:48 -0700, alex.jakime...@gmail.com wrote:
>> See this...
> 
> See also timotimo++'s comment that TimToady cleared a revert if there were 
> fallout:
>  raschipi, gfldex, timtoady already said he'd retract the commit if 
> there's ecosystem fallout, which you just demonstrated
> 
> https://irclog.perlgeek.de/perl6/2017-08-17#i_15031866
> 
> 
>> Personally, I don't mind rereverting it afterwards for inclusion in
>> 2017.09
> 
> To me, it looks like a clear case for 6.d material. We made a promise to 
> users that we won't make changes that break 6.c-errata changes and IMO the 
> 6.c-errata roast changes due to this feature break that promise.

Hear hear!

Re: [perl #131919] [RFC] Returning Failure from failed P6-level .parse

[Elizabeth Mattijsen]

> On 17 Aug 2017, at 18:11, Zoffix Znet via RT  
> wrote:
> 
> On Thu, 17 Aug 2017 08:50:48 -0700, alex.jakime...@gmail.com wrote:
>> See this...
> 
> See also timotimo++'s comment that TimToady cleared a revert if there were 
> fallout:
>  raschipi, gfldex, timtoady already said he'd retract the commit if 
> there's ecosystem fallout, which you just demonstrated
> 
> https://irclog.perlgeek.de/perl6/2017-08-17#i_15031866
> 
> 
>> Personally, I don't mind rereverting it afterwards for inclusion in
>> 2017.09
> 
> To me, it looks like a clear case for 6.d material. We made a promise to 
> users that we won't make changes that break 6.c-errata changes and IMO the 
> 6.c-errata roast changes due to this feature break that promise.

Hear hear!

Re: [perl #131919] [RFC] Returning Failure from failed P6-level .parse

[Elizabeth Mattijsen]

> On 17 Aug 2017, at 17:50, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #131919]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131919 >
> 
> 
> See this commit: 
> https://github.com/rakudo/rakudo/commit/9501edae4f73a970e3270e3b0336a7b3045d3329
> 
> These roast commits:
> * 
> https://github.com/perl6/roast/commit/1fb68c4b7a7c975f26fc81ad79f000958d1b4afd
> * 
> https://github.com/perl6/roast/commit/b53616f8e67f9b19366008b3abf55400a3d6cd2b
> 
> And this justification:
> * https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994
> 
> This blog post noticing the breakage due to the change:
> * https://gfldex.wordpress.com/2017/08/17/parsing-nothing/
> 
> And these thoughts about postponing it to v6.d:
> * https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160
> 
> 
> I am confident that we will not be able to process this change and all 
> potential breakage associated with it in ≈3 days before the release, so the 
> revert is coming.
> 
> Personally, I don't mind rereverting it afterwards for inclusion in 2017.09, 
> assuming we make sure to fix all modules that were relying on Nils being 
> returned. However, I do see the point for postponing it till v6.d.
> 
> 
> So should we feel adventurous and push this change as early as we can (in 
> 2017.09, aftear at least one month)? Or is it better to be safe and wait for 
> v6.d? Please discuss.

My feeling is to put this towards 6.d.  And possibly have that coincide with 
2017.09.

The reason?  This feature, like other features such as “is default” working on 
attributes, can *still* not be used on any module in the ecosystem, because one 
cannot be sure it won’t get run by a version of 6.c that does not have that 
feature already: case in point, not gaining about 5% in performance in 
Text::CSV because we cannot use “has $!foo is default()”.

I think we’ve collected so many incompatible features by now that we need a 6.d 
earlier rather than later.  At least from the API point of view.  AKA, make 
things work for 6.d, then start optimizing again  :-)

Re: [perl #131919] [RFC] Returning Failure from failed P6-level .parse

[Elizabeth Mattijsen via RT]

> On 17 Aug 2017, at 17:50, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #131919]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131919 >
> 
> 
> See this commit: 
> https://github.com/rakudo/rakudo/commit/9501edae4f73a970e3270e3b0336a7b3045d3329
> 
> These roast commits:
> * 
> https://github.com/perl6/roast/commit/1fb68c4b7a7c975f26fc81ad79f000958d1b4afd
> * 
> https://github.com/perl6/roast/commit/b53616f8e67f9b19366008b3abf55400a3d6cd2b
> 
> And this justification:
> * https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994
> 
> This blog post noticing the breakage due to the change:
> * https://gfldex.wordpress.com/2017/08/17/parsing-nothing/
> 
> And these thoughts about postponing it to v6.d:
> * https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160
> 
> 
> I am confident that we will not be able to process this change and all 
> potential breakage associated with it in ≈3 days before the release, so the 
> revert is coming.
> 
> Personally, I don't mind rereverting it afterwards for inclusion in 2017.09, 
> assuming we make sure to fix all modules that were relying on Nils being 
> returned. However, I do see the point for postponing it till v6.d.
> 
> 
> So should we feel adventurous and push this change as early as we can (in 
> 2017.09, aftear at least one month)? Or is it better to be safe and wait for 
> v6.d? Please discuss.

My feeling is to put this towards 6.d.  And possibly have that coincide with 
2017.09.

The reason?  This feature, like other features such as “is default” working on 
attributes, can *still* not be used on any module in the ecosystem, because one 
cannot be sure it won’t get run by a version of 6.c that does not have that 
feature already: case in point, not gaining about 5% in performance in 
Text::CSV because we cannot use “has $!foo is default()”.

I think we’ve collected so many incompatible features by now that we need a 6.d 
earlier rather than later.  At least from the API point of view.  AKA, make 
things work for 6.d, then start optimizing again  :-)