Re: [perl #122827] string append to Blob spins

[Elizabeth Mattijsen via RT]

On 22 Sep 2014, at 20:55, Paul Marquess (via RT) perl6-bugs-follo...@perl.org 
wrote:
 # New Ticket Created by  Paul Marquess 
 # Please include the string:  [perl #122827]
 # in the subject line of all future correspondence about this issue. 
 # URL: https://rt.perl.org/Ticket/Display.html?id=122827 
 
 
 The following one-liner cooks cpu for 24 seconds before killing itself
 
 $ time perl6 -e 'my Blob $x ; $x ~= pack V,1;'
 Killed
 
 real  0m24.019s
 user  0m7.980s
 sys   0m2.232s
 
 Running latest Rakudo star
 
 $ perl6 -v
 This is perl6 version 2014.08 built on MoarVM version 2014.08

Confirmed on HEAD.  This eats all available memory *very* quickly.  You were 
lucky your OOM-killer caught it as quickly as it did.



Liz

Re: [perl #127785] where constraint in blockless declaration causes spurious gobbling error

[Elizabeth Mattijsen via RT]

Perhaps we should disallow “unit” with -e?

> On 28 Mar 2016, at 20:18, Trey Ethan Harris <t...@cpan.org> wrote:
> 
> No, see S06-routines.pod:
> 
> As with module and class declarations, a sub declared
> with the C declarator (and ending in semicolon) is allowed at the 
> outermost
> file scope if it is the
> first such declaration, in which case the rest of the file is the body:
> 
> unit sub MAIN ($directory, :$verbose, *%other, *@filenames);
> for @filenames { ... }
> 
> This form is allowed only for simple subs named C that are intended
> to be run from the command line.
> 
> 
> On Sat, Mar 26, 2016 at 7:02 AM Elizabeth Mattijsen via RT 
> <perl6-bugs-follo...@perl.org> wrote:
> unit sub ???
> 
> I thought that unit was only supposed to be followed by a package like 
> declaration??
> 
> 
> > On 26 Mar 2016, at 02:10, Trey Harris (via RT) 
> > <perl6-bugs-follo...@perl.org> wrote:
> >
> > # New Ticket Created by  Trey Harris
> > # Please include the string:  [perl #127785]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=127785 >
> >
> >
> > Example:
> >
> > % perl6 -e 'sub MAIN ($x where { $^x > 1 } ) { say "big" }' 4
> > big
> > % perl6 -e 'sub MAIN ($x where { $^x > 1 } ) { say "big" }' 0
> > Usage:
> >  -e '...' 
> > % perl6 -e 'unit sub MAIN ($x where { $^x > 1 } );  say "big"'  4
> > ===SORRY!===
> > Expression needs parens to avoid gobbling block
> > at -e:1
> > --> unit sub MAIN ($x where { $^x > 1 }⏏ );  say "big"
> > Missing block (apparently claimed by expression)
> > at -e:1
> > --> unit sub MAIN ($x where { $^x > 1 } );⏏  say "big"
> >
> 
> 

Re: [perl #127879] [BUG] map subroutine ignores the sequence in the specific case

[Elizabeth Mattijsen via RT]

> On 11 Apr 2016, at 15:19, Itsuki Toyota (via RT) 
>  wrote:
> 
> # New Ticket Created by  Itsuki Toyota 
> # Please include the string:  [perl #127879]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=127879 >
> 
> 
> See the following results.
> 
> $ echo "h o g e" | perl6 -e 'for $*IN.lines -> $line { $line.split(" 
> ").map(-> $e { $e.perl.say; }) };' # map ignores the input
> $ echo "h o g e" | perl6 -e 'for $*IN.lines -> $line { $line.split(" 
> ").perl.say };' # ensure the input sequence
> ("h", "o", "g", "e")
> $ perl6 -e '("h", "o", "g", "e").map(->$e { $e.perl.say });' # ordinary case
> "h"
> "o"
> "g"
> "e"
> 
> 
> The 1st example seems that map subroutine ignores the input sequence. 
> I think that the 1st example should return the same result as the 3rd example.

I’m not sure.

$*IN.lines is lazy, the for is lazy, the split is lazy, the map is lazy, and 
apparently the sink is also lazy.  There’s nothing pulling values from the far 
end, so the whole chain is waiting for something to happen.

This should probably create a warning like “Useless use of split in sink 
context”.

If you make the split eager by storing its result, it works as you’d expect:

$ echo "h o g e" | perl6 -e 'for $*IN.lines -> $line { my @a = $line.split(" 
").map(-> $e { $e.perl.say; }) };'
"h"
"o"
"g"
“e"


So I would qualify this as *not a bug*, although one could argue that the lack 
of warning on the split in sink context *is* a bug.  And/or the lack of 
eagerness of the sink is a bug.



Liz

Re: [perl #127785] where constraint in blockless declaration causes spurious gobbling error

[Elizabeth Mattijsen via RT]

unit sub ???

I thought that unit was only supposed to be followed by a package like 
declaration??


> On 26 Mar 2016, at 02:10, Trey Harris (via RT)  
> wrote:
> 
> # New Ticket Created by  Trey Harris 
> # Please include the string:  [perl #127785]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=127785 >
> 
> 
> Example:
> 
> % perl6 -e 'sub MAIN ($x where { $^x > 1 } ) { say "big" }' 4
> big
> % perl6 -e 'sub MAIN ($x where { $^x > 1 } ) { say "big" }' 0
> Usage:
>  -e '...' 
> % perl6 -e 'unit sub MAIN ($x where { $^x > 1 } );  say "big"'  4
> ===SORRY!===
> Expression needs parens to avoid gobbling block
> at -e:1
> --> unit sub MAIN ($x where { $^x > 1 }⏏ );  say "big"
> Missing block (apparently claimed by expression)
> at -e:1
> --> unit sub MAIN ($x where { $^x > 1 } );⏏  say "big"
> 

Re: [perl #127793] The cmp operator for user-defined classes lacks consistency

[Elizabeth Mattijsen via RT]

> On 27 Mar 2016, at 16:05, Itsuki Toyota (via RT)  
> wrote:
> 
> # New Ticket Created by  Itsuki Toyota 
> # Please include the string:  [perl #127793]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=127793 >
> 
> 
> It seems that the cmp operator for user-defined classes lacks consistency.
> See the following commands.
> 
> $ perl6 -e 'class MyClass {}; my $foo = MyClass.new(); my $bar = 
> MyClass.new(); ($foo cmp $bar).perl.say'
> Order::Less
> $ perl6 -e 'class MyClass {}; my $foo = MyClass.new(); my $bar = 
> MyClass.new(); ($bar cmp $foo).perl.say'
> Order::More
> $ perl6 -e '(Str.new cmp Str.new).perl.say'
> Order::Same
> 
> Comparing two instances of the type object Str seems to check its type, but 
> comparing that of MyClass seems to check its address or something.
> 
> I think that it should return Order::Same or something Exception.

The default cmp calls .Stringy on the objects, so effectively the comparison 
becomes something like "MyClass<123345>" cmp "MyClass<234556>”.

I guess we *could* introspect the object for public attributes and start 
cmp-ing them (if they are of the same type, of course).  But I fear for the 
level of DWIM: it looks like becoming a WAT very fast.

Perhaps we should only check for address equality, and if not, return Nil 
(indicating we don’t know).

Re: [perl #128049] [BUG] "Cannot look up attributes in a type object" error has occurred in the context of using NativeCall

[Elizabeth Mattijsen via RT]

> On 01 May 2016, at 16:43, Itsuki Toyota (via RT) 
>  wrote:
> 
> # New Ticket Created by  Itsuki Toyota 
> # Please include the string:  [perl #128049]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=128049 >
> 
> 
> See the following results.
> 
> $ perl6 -MNativeCall -e 'class Foo { has $.piyo; method new() { my $fuga = 
> CArray[OpaquePointer]; $fuga[0] = OpaquePointer; $!piyo = $fuga[0]; } }; 
> Foo.new();'
> Cannot look up attributes in a type object
>  in method new at -e line 1
>  in block  at -e line 1
> 

This is not a bug and has nothing to do with NativeCall:

$ 6 'class A { has $!a; method a() { $!a = 42 } }; A.a'
Cannot look up attributes in a type object
  in method a at -e line 1
  in block  at -e line 1

The “self” in new is a type object, *not* an instance.

$ 6 'class A { has $!a; method a() { $!a = 42 } }; say A.new.a’
42

The default .new will return an instantiated object.


You should probably rename your method “new” to BUILD, so that the default 
.new() implementation can find it.



Liz

Re: [perl #130863] [LTA][BUG] Cannot extract partially dimensioned view of array from fixed-size array

[Elizabeth Mattijsen via RT]

> On 26 Feb 2017, at 07:06, Itsuki Toyota (via RT) 
>  wrote:
> 
> # New Ticket Created by  Itsuki Toyota 
> # Please include the string:  [perl #130863]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=130863 >
> 
> 
> See the following example:
> 
> $ perl6 -e 'my @a; @a = [[1, 2], [3, 4]]; @a[0;*].say;'
> (1 2)
> 
> $ perl6 -e 'my @a[2;2]; @a = [[1, 2], [3, 4]]; @a[0;*].say;'
> Partially dimensioned views of arrays not yet implemented. Sorry. 
>   in block  at -e line 1
> 
> 
> I'm not sure this is a bug or really not yet implemented as the 2nd example 
> says.
> However, "partially dimensioned views of arrays" seems implemented as the 1st 
> example shows.
> 
> 
> $ perl6 --version
> This is Rakudo version 2017.02-58-gd41b68e built on MoarVM version 
> 2017.02-7-g3d85900
> implementing Perl 6.c.

I guess the error at the moment is in the error message, which should read:

"Partially dimensioned views of shaped arrays not yet implemented. Sorry.”


Liz

Re: [perl #129104] [BUG] method rand (Range) ignores $!excludes-max flag

[Elizabeth Mattijsen via RT]

Welcome to the world of floating point accuracy.

This little program typically ends within 100 iterations for me:

$ 6 'my int $a = 0; $a++ while (1..^(1+10e-15)).rand < 1+10e-15; say $a’
96

Either we dismiss this bug as being caused by lack of floating point accuracy, 
or we build in something special in .rand for Num Ranges that will make sure 
that the returned value actually is less then upper range as indicated by “<“.

I would mark this RT as a @LARRY case.

> On 27 Aug 2016, at 08:31, Itsuki Toyota (via RT) 
>  wrote:
> 
> # New Ticket Created by  Itsuki Toyota 
> # Please include the string:  [perl #129104]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=129104 >
> 
> 
> See the following result
> 
> $ perl6 -e '(1..^(1+10e-15)).rand.say'
> 1.01
> 
> $ perl6 -e 'say 1.01 - (1+10e-15)'
> 0
> 
> $ perl6 -e '(1..^(1+10e-15)).excludes-max.say'
> True
> 
> I think that the 1st example it shouldn't return 1+10e-15, since 
> Range.excludes-max is True.
> 
> My Perl 6 version is
> $ perl6 --version
> This is Rakudo version 2016.07.1-199-gdd9b760 built on MoarVM version 
> 2016.07-17-g40948f6
> implementing Perl 6.c.

Re: [perl #130131] [LTA][BUG] sub MAIN cannot accept enum argument

[Elizabeth Mattijsen via RT]

The parameters received from the command line, are always Str (or IntStr if 
they look like an integer).  To allow direct matching / handling of this, we 
would need something like an EnumStr type.  I don’t think that’s going to 
happen soon.

I also tried some pre-processing on the @*ARGS array in an INIT block, but that 
fails because the default command line processing really expects something that 
works like a Str.

So, so far I’ve only been able to come up with this workaround:

sub MAIN(:$country! where (Country.enums{$_}:exists)) {
…
}

Unfortunately it will display the feedback on a wrong parameter like:

Usage:
  script.pl --country= 

but I guess that’s the best we have for this in the short-term.

> On 18 Nov 2016, at 15:40, Itsuki Toyota (via RT) 
>  wrote:
> 
> # New Ticket Created by  Itsuki Toyota 
> # Please include the string:  [perl #130131]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=130131 >
> 
> See the following results:
> 
> $ perl6 script.p6 --country=America
> Usage:
>   script.p6 --country= 
> 
> $ perl6 script.p6 --country=1
> Usage:
>   script.p6 --country= 
> 
> 
> script.p6:
> 
> use v6;
> 
> enum Country;
> 
> sub MAIN(Country :$country!) {
> say $country;
> }
> 
> 
> $ perl6 --version
> This is Rakudo version 2016.10-295-g85c7072 built on MoarVM version 
> 2016.10-71-g9d5c874
> implementing Perl 6.c.
> 
> 
> I think that if sub MAIN cannot accept enum argument, it should display any 
> error messages and die.

Re: [perl #130131] [LTA][BUG] sub MAIN cannot accept enum argument

[Elizabeth Mattijsen via RT]

After some more investigation it turned out to be not so difficult in the MAIN 
parameter
handling case.  So, fixed with 546dbd99b18425a42c8 .  Tests needed!

> On 18 Nov 2016, at 15:40, Itsuki Toyota (via RT) 
>  wrote:
> 
> # New Ticket Created by  Itsuki Toyota 
> # Please include the string:  [perl #130131]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=130131 >
> 
> 
> See the following results:
> 
> $ perl6 script.p6 --country=America
> Usage:
>   script.p6 --country= 
> 
> $ perl6 script.p6 --country=1
> Usage:
>   script.p6 --country= 
> 
> 
> script.p6:
> 
> use v6;
> 
> enum Country;
> 
> sub MAIN(Country :$country!) {
> say $country;
> }
> 
> 
> $ perl6 --version
> This is Rakudo version 2016.10-295-g85c7072 built on MoarVM version 
> 2016.10-71-g9d5c874
> implementing Perl 6.c.
> 
> 
> I think that if sub MAIN cannot accept enum argument, it should display any 
> error messages and die.
> 

Re: [perl #130396] [BUG] =:= operation aginst item contextualized object returns incorrect result

[Elizabeth Mattijsen via RT]

> On 24 Dec 2016, at 07:01, Itsuki Toyota (via RT) 
>  wrote:
> 
> # New Ticket Created by  Itsuki Toyota 
> # Please include the string:  [perl #130396]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=130396 >
> 
> 
> See the following results:
> 
> $ perl6 -e 'my @a = 1,2; my $b = @a.item; say $b =:= @a;'
> 
> False
> 
> $ perl6 -e 'my @a = 1,2; my $b = @a.item; $b.shift; say @a;'
> [2]
> 
> I think the 1st example should return True, because both $b and @a share the 
> same container.

No, they don’t share the same container.  The @a.item creates a new container, 
and the *assignment* to $b creates another new one.  Only if you would do my $b 
:= @a, would they share the same container:

$ perl6 -e 'my @a = 1,2; my $b := @a; say $b =:= @a;'
True


Rejecting this ticket as NOTABUG.

Re: [perl #131830] [BUG] [REGRESSION] postcircumfix:<[ ]> with NativeCall is ambiguous

[Elizabeth Mattijsen via RT]

This should be fixed with 7599e0c3ffb2c7ef29c2994c , which reverted a256c26d850

> On 2 Aug 2017, at 16:21, Александр Кирюхин (via RT) 
>  wrote:
> 
> # New Ticket Created by  Александр Кирюхин 
> # Please include the string:  [perl #131830]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131830 >
> 
> 
> I didn't tried to golf it yet, but since recent commits
> IO::Socket::Async::SSL started to fail its tests with such backtrace:
>> Ambiguous call to 'postcircumfix:<[ ]>'; these signatures all match:
>> :(\SELF, int $pos)
>> :(NativeCall::Types::CArray:D \array, $pos)
> 
> -- 
> --
> Alexander.

Re: [perl #131827] [BUG] Multi-value hash doesn't consider * as a Range

[Elizabeth Mattijsen via RT]

> On 1 Aug 2017, at 14:40, Александр Кирюхин (via RT) 
>  wrote:
> 
> # New Ticket Created by  Александр Кирюхин 
> # Please include the string:  [perl #131827]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131827 >
> 
> 
>> my %h = :a($("1", "3", "4"));
>> say %h[*];
>> P6opaque: no such attribute '$!todo' in type List when trying to get a
> value
>> in block  at  line 1

Fixed with https://github.com/rakudo/rakudo/commit/59ba9c025e


> The bug appeared after this commit, I guess: https://github.com/rakudo/
> rakudo/commit/a256c26d850c0e5ff986a6dfa1b1ef1ffaf55f40#diff-
> 73b320f44150e274a14987ce4e9f0fdaR220
> 
> The test will be something like:
>> is-deeply :a($("1", "3", "4"))[*], ('1', '3', '4'), '* is considered as
> a Range';
> 
> I can commit the test for sure, but I need to know where should I add it.

t/spec/S09-subscript/slice.t seems a good place, judging by the name.

Re: [perl #131900] [BUG] REPL issue defining new operator with Euro symbol

[Elizabeth Mattijsen via RT]

This appears to be forgetfulness of the REPL from one input to the next.  If 
you put it on the same line, it *does* work:

> sub postfix:<€> (Int $n) {2*$n}; say 42€
84

So this boils down to a much more generic issue, for which we already have 
tickets I believe.

> On 15 Aug 2017, at 14:25, Patrick Tonnerre (via RT) 
>  wrote:
> 
> # New Ticket Created by  Patrick Tonnerre 
> # Please include the string:  [perl #131900]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131900 >
> 
> 
> Hi,
> 
> context is :
> MBP running macOS Sierra 10.12.6
> RakudoStar dmg installed
> This is Rakudo version 2017.07 built on MoarVM version 2017.07
> implementing Perl 6.c.
> 
> When executing the following commands under REPL, i got that issue :
>> sub postfix:<€> (Int $n) {2*$n};
> sub postfix:<€> (Int $n) { #`(Sub+{Precedence}|140257667062944) ... }
>> say 21€
> ===SORRY!=== Error while compiling:
> Bogus postfix
> --> say 21⏏€
>expecting any of:
>infix
>infix stopper
>postfix
>statement end
>statement modifier
>statement modifier loop
> 
> Running the same statements into a script is working fine :
> #!/usr/bin/env perl6
> 
> sub postfix:<€> (Int $n) {2*$n}
> 
> say 21€;
> 
> ./operators.pl6 
> 42
> 
> Regards
> — 
> Patrick

Re: [perl #131900] [BUG] REPL issue defining new operator with Euro symbol

[Elizabeth Mattijsen via RT]

Further datapoints:

$ perl6
To exit type 'exit' or '^D'
> sub postfix:<€> (Int $n) {2*$n}; say 42€
84
> say postfix:<€>  (42)
84

So, the sub *does* survive from one call to the next.  It only loses the 
grammar adaptations that defining a sub postfix:<>  do.


> On 15 Aug 2017, at 21:06, Elizabeth Mattijsen  wrote:
> 
> This appears to be forgetfulness of the REPL from one input to the next.  If 
> you put it on the same line, it *does* work:
> 
>> sub postfix:<€> (Int $n) {2*$n}; say 42€
> 84
> 
> So this boils down to a much more generic issue, for which we already have 
> tickets I believe.
> 
>> On 15 Aug 2017, at 14:25, Patrick Tonnerre (via RT) 
>>  wrote:
>> 
>> # New Ticket Created by  Patrick Tonnerre 
>> # Please include the string:  [perl #131900]
>> # in the subject line of all future correspondence about this issue. 
>> # https://rt.perl.org/Ticket/Display.html?id=131900 >
>> 
>> 
>> Hi,
>> 
>> context is :
>> MBP running macOS Sierra 10.12.6
>> RakudoStar dmg installed
>> This is Rakudo version 2017.07 built on MoarVM version 2017.07
>> implementing Perl 6.c.
>> 
>> When executing the following commands under REPL, i got that issue :
>>> sub postfix:<€> (Int $n) {2*$n};
>> sub postfix:<€> (Int $n) { #`(Sub+{Precedence}|140257667062944) ... }
>>> say 21€
>> ===SORRY!=== Error while compiling:
>> Bogus postfix
>> --> say 21⏏€
>>   expecting any of:
>>   infix
>>   infix stopper
>>   postfix
>>   statement end
>>   statement modifier
>>   statement modifier loop
>> 
>> Running the same statements into a script is working fine :
>> #!/usr/bin/env perl6
>> 
>> sub postfix:<€> (Int $n) {2*$n}
>> 
>> say 21€;
>> 
>> ./operators.pl6 
>> 42
>> 
>> Regards
>> — 
>> Patrick

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

[Elizabeth Mattijsen via RT]

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

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

Re: [perl #131737] [BUG] WindowsOS: IO.dirname strips off drive name

[Elizabeth Mattijsen via RT]

> On 11 Jul 2017, at 15:34, Jarkko Haapalainen (via RT) 
>  wrote:
> 
> # New Ticket Created by  Jarkko Haapalainen 
> # Please include the string:  [perl #131737]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131737 >
> 
> 
> Problems running Perl6 programs on network drive and when using IO.dirname. 
> File paths get cluttered.
> Running examples on drive Z:
> EXAMPLE:
> my $path = 'c:\foo\bar\file.txt';
> say $path;
> say $path.IO.dirname;
> say $path.IO.absolute;
> say $path.IO.dirname.IO.absolute;
> OUTPUT:
> c:\foo\bar\file.txt
> \foo\bar
> C:\foo\bar\file.txt
> Z:\foo\bar

^^^  assume the Z is a typo here 

> EXPECTED RESULT:
> c:\foo\bar\file.txt
> c:\foo\bar
> C:\foo\bar\file.txt
> C:\foo\bar
> VERSION INFORMATION:
> perl6 -v
> This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-53-g66c6dda 
> implementing Perl 6.c.
> Best regards,
> 
> --
> Jarkko

Re: [perl #130285] [REGRESSION] Unhealthy overflow in .head and .tail with huge negative numbers ( (4,5,6).tail(-9999999999999999999) )

[Elizabeth Mattijsen via RT]

I’m inclined to WONTFIX, as other, much more common, indexing operation suffer 
from the same issue:

$ 6 'my @a; say @a[999]'
Cannot unbox 64 bit wide bigint into native integer

$ 6 'my @a[999]'
Illegal dimension in shape: 999. All dimensions must be 
integers bigger than 0

etc etc etc.

> On 7 Dec 2016, at 01:37, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #130285]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=130285 >
> 
> 
> Code:
> say (4,5,6).tail(-999)
> 
> Result HEAD:
> MoarVM panic: Memory allocation failed; could not allocate 
> 12233720368547758088 bytes
> 
> Result (2016.09):
> ()
> 
> 
> Code:
> say (4,5,6).head(-999)
> 
> Result HEAD:
> (4 5 6)
> 
> Result (2016.09):
> ()
> 
> 
> Bisectable points to these commits:
> * 
> https://github.com/rakudo/rakudo/commit/a3406cba841cd9ecdd3bda49b9a415381615961c
> * 
> https://github.com/rakudo/rakudo/commit/6996512e3c994fafa2d34e8c5c9bf9d25f0a0810

Re: [perl #131783] [LTA] :delete holes in Arrays get turned to Mus when coercing to List or Slip

[Elizabeth Mattijsen via RT]

> On 23 Jul 2017, at 03:48, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #131783]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131783 >
> 
> 
> The current behaviour kinda makes sense when you squint at it, but today we 
> had a user[^1]who was surprised by it, so I'm filing it as a ticket, if maybe 
> there's some Better Way this can be done with.
> 
> When you :delete an element from the Array, you get nqp::null stuffed into 
> the position, which gets converted to `is default` value when you look it up 
> again:
> 
> m: use nqp; my @a is default(42) = ; @a[1]:delete; dd @a
> rakudo-moar b14721: OUTPUT: «Array @a = ["a", 42, "c"]␤»
> 
> However, if you now convert that Array to a Slip or a List, the hole is left 
> as a bare Mu and doesn't get turned into a default value, which is lost:
> 
> m: use nqp; my @a is default(42) = ; @a[1]:delete; dd 
> @a.Slip
> rakudo-moar b14721: OUTPUT: «slip("a", Mu, "c")␤»
> 
> m: use nqp; my @a is default(42) = ; @a[1]:delete; dd 
> @a.List
> rakudo-moar b14721: OUTPUT: «("a", Mu, "c")␤»
> 
> So it makes sense that without `is default` you don't get an `is default` 
> value, but at the same time, Mu is not a great value to deal with...
> 
> [1] https://irclog.perlgeek.de/perl6/2017-07-22#i_14908846

The problem is really caused by the fact that an Array has a descriptor, which 
contains the default value and type information, and a List does not.  And 
since a Slip isa List, we lose the descriptor when Slipping an Array.

The same issue appears with:

  $ 6 'my @a; @a[2] = 42; dd (|@a)[0] = 44; dd @a'
  Cannot modify an immutable Str (Nil)

Which is because Slip is a List, it uses List.AT-POS, and that one doesn’t 
create a WHENCE with a container to be filled at a later time.

Which then goes back to: what is the use case of Slipping an Array?  When do 
you need that?

Perhaps slipping an Array should produce a warning?

Re: [perl #131789] LTA error message: unexpected argument

[Elizabeth Mattijsen via RT]

> On 24 Jul 2017, at 19:51, Zoffix Znet via RT  
> wrote:
> 
> On Mon, 24 Jul 2017 07:15:54 -0700, ju...@tnx.nl wrote:
>> It would be more awesome if "Unexected named argument 'foo' passed" was
>> supplemented with the name of the function to which it was passed.
>> 
>>sub xyzzy ($x, :$foo = False) { ... }
>>sub bar ($y) { ... }
>> 
>>xyzzy(
>>bar "aoeusnthaoeusnth",
>>:foo
>>)
>> 
>> If the error message includes the name 'bar', it's obvious that adding
>> parentheses will fix the problem.
> 
> But the error for that code does already say `in sub bar`:
> 
>m: sub bar {}; bar :42foo
>rakudo-moar 2fb8c7: OUTPUT: «Unexpected named argument 'foo' passed␤  in 
> sub bar at  line 1␤ 

Well, technically, that’s part of the backtrace, not of the message?

Re: [perl #131805] [REGRESSION] [PERF] .grep-ing with a code block is now almost twice slower ( .grep({/foo/}) )

[Elizabeth Mattijsen via RT]

Looking at the profile of

(^1).grep({!/1/}).elems.say

the first 5 entries (responsible for 70% of CPU in that example) have nothing 
to do with matching, but everything with trying to find the right dispatchee.  
And it looks like this is basically caused by:

$_ = 1; /1/

Because $_ contains an Int, this becomes a very slow path.  Compare this with:

(^1)>>.Str.grep({!/1/}).elems.say

which is 3x faster, even when using a sub-optimal hyper.

Investigating further...

> On 27 Jul 2017, at 04:06, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #131805]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131805 >
> 
> 
> See this benchable6 output: 
> https://gist.github.com/Whateverable/6001c5744e3c877d76928d465de31e46
> 
> If you look closely, benchable has not only built the graph across all 
> releases, but it also bisected the performance drop to the exact commit. Here 
> is that commit: 
> https://github.com/rakudo/rakudo/commit/b7201a8f22338a906f2d8027a21387e8f5c77f41
> 
> This was double-checked with committable6:
>  c: b7201a8^,b7201a8 (^9).grep({!/1/}).elems.say; say now - 
> BEGIN now
>  AlexDaniel, ¦b7201a8^: «59048␤5.0481256» ¦b7201a8: 
> «59048␤9.0262629»
> 
> So it is ≈5 seconds before vs ≈9 seconds after. A significant performance 
> drop even if we assume possible bench noise.
> 
> This was noticed because of this ticket: 
> https://github.com/perl6/doc/issues/1425
> 
> See also IRC discussion: 
> https://irclog.perlgeek.de/perl6/2017-07-27#i_14927626
> 
> And maybe coverable output on HEAD if it may help you: 
> https://gist.github.com/Whateverable/f3db9e924cebe9b96a71a2b4cd67ae9c
> 
> Note that whether it's {!/1/} or {/1/} doesn't really matter: 
> https://irclog.perlgeek.de/perl6/2017-07-27#i_14927789

Re: [perl #131805] [REGRESSION] [PERF] .grep-ing with a code block is now almost twice slower ( .grep({/foo/}) )

[Elizabeth Mattijsen via RT]

It’s really in the dispatch within Cool.  Note the difference between:

  for ^1 { 1.match(/1/) }

and:

  for ^1 { "1".match(/1/) }

I’m afraid this is really uncovering a basic dispatch caching issue.

I have tried a few things, but I’m afraid this is really an issue inside 
“find_best_dispatchee” in the bootstrap


> On 27 Jul 2017, at 09:37, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> 
> Oh! You're totally right!
> 
> Then, it's not as bad as it looks.
> 
> In fact, this commit actually *improved* the case when it has to match Str-s
> (more than 2x speedup).
> 
> So perhaps the slowdown is not so critical. After all, how often do people
> match thousands of Ints…
> 
> On 2017-07-26 23:55:21, elizabeth wrote:
>> Looking at the profile of
>> 
>> (^1).grep({!/1/}).elems.say
>> 
>> the first 5 entries (responsible for 70% of CPU in that example) have
>> nothing to do with matching, but everything with trying to find the
>> right dispatchee. And it looks like this is basically caused by:
>> 
>> $_ = 1; /1/
>> 
>> Because $_ contains an Int, this becomes a very slow path. Compare
>> this with:
>> 
>> (^1)>>.Str.grep({!/1/}).elems.say
>> 
>> which is 3x faster, even when using a sub-optimal hyper.
>> 
>> Investigating further...
>> 
>>> On 27 Jul 2017, at 04:06, Aleks-Daniel Jakimenko-Aleksejev (via RT)
>>>  wrote:
>>> 
>>> # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
>>> # Please include the string: [perl #131805]
>>> # in the subject line of all future correspondence about this issue.
>>> # https://rt.perl.org/Ticket/Display.html?id=131805 >
>>> 
>>> 
>>> See this benchable6 output:
>>> https://gist.github.com/Whateverable/6001c5744e3c877d76928d465de31e46
>>> 
>>> If you look closely, benchable has not only built the graph across
>>> all releases, but it also bisected the performance drop to the exact
>>> commit. Here is that commit:
>>> 
> https://github.com/rakudo/rakudo/commit/b7201a8f22338a906f2d8027a21387e8f5c77f41
>>> 
>>> This was double-checked with committable6:
>>>  c: b7201a8^,b7201a8 (^9).grep({!/1/}).elems.say; say
>>> now - BEGIN now
>>>  AlexDaniel, ¦b7201a8^: «59048␤5.0481256» ¦b7201a8:
>>> «59048␤9.0262629»
>>> 
>>> So it is ≈5 seconds before vs ≈9 seconds after. A significant
>>> performance drop even if we assume possible bench noise.
>>> 
>>> This was noticed because of this ticket:
>>> https://github.com/perl6/doc/issues/1425
>>> 
>>> See also IRC discussion: https://irclog.perlgeek.de/perl6/2017-07-
>>> 27#i_14927626
>>> 
>>> And maybe coverable output on HEAD if it may help you:
>>> https://gist.github.com/Whateverable/f3db9e924cebe9b96a71a2b4cd67ae9c
>>> 
>>> Note that whether it's {!/1/} or {/1/} doesn't really matter:
>>> https://irclog.perlgeek.de/perl6/2017-07-27#i_14927789

Re: [perl #131783] [LTA] :delete holes in Arrays get turned to Mus when coercing to List or Slip

[Elizabeth Mattijsen via RT]

> On 23 Jul 2017, at 22:27, Sam S. via RT  wrote:
> 
>> Which then goes back to: what is the use case of Slipping an Array?
> 
> Same as slipping any other type of Iterable: Fine-grained, elegant flattening 
> and concatenating.
> 
> Compare:
> 
>  my @all = flat $first, @rest;
> 
>  my @all = $first, |@rest;
> 
> When you *know* that $first is a Scalar and @rest is an Array, those two do 
> the same thing because `flat` doesn't descend into item containers.
> 
> But if those are, say, function parameters, then they can become bound to 
> other things, e.g. the calling code could pass a List to `@rest` which 
> *doesn't* have its elements itemized, so the version with `flat` would 
> destroy the elements' internal structure.
> 
> Even if that wasn't the case, I'd consider the `|` version more elegant than 
> the `flat` version, because it denotes very clearly to the reader *where* 
> exactly something is being flattened into the outer list.
> 
>> because Slip is a List, it uses List.AT-POS, and that one
>> doesn’t create a WHENCE with a container to be filled at a later time. 
> 
> Couldn't `@array.Slip` be made to properly iterate @array behind the scenes 
> (the same way that `@array.map` would iterate it), instead of reaching into 
> @array's guts and copying its elements in a way that misinterprets some of 
> them?

Which is exactly what 12d7d5b48add8347eb119 does.

So fixed, and tests needed!

Re: [perl #131699] [LTA] Errors indexing past the end of a List

[Elizabeth Mattijsen via RT]

> On 4 Jul 2017, at 16:05, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> On 2017-07-04 05:29:20, comdog wrote:
>> Accessing a List element beyond the end of the List returns Nil,
>> although accessing an element before the beginning returns an out of
>> bounds failure. I think there's two things that can be better here
>> since we know the size of the List.
>> 
>> my $list = < a b c >;
>> put "I have a {$list.^name}";
>> 
>> First, in the "before" case, we have more information than the error
>> message lets on. The index should be from 0 to 2:
>> 
>> {
>> my $i = -1;
>> $list[$i]; # Index out of range. Is: -1, should be in 0..^Inf
>> }
>> 
>> But this requires the change I think is more helpful. Since the List
>> size won't change, we can have the same out-of-bounds error on
>> accesses past the end. At the moment it's no warning:
>> 
>> {
>> my $i = $list.end + 1;
>> $list[$i]; # No warning
>> }
>> 
>> This would then be the error for assigning into a position beyond the
>> end. The existing error doesn't say what went wrong even though Perl 6
>> has enough information to figure that out:
>> 
>> {
>> my $i = $list.end + 1;
>> $list[$i] = 5; # Cannot modify an immutable Nil
>> }
> Hm. Wouldn't that make behavior of Lists and Arrays different?

No, because Lists are supposed to be immutable wrt to the number of elements.

That said, a List may not always be completely reified already.  So logically, 
a List may  have 100 elements, it could well be that only 42 of these elements 
exist already.  Which means that the underlying NQP array, which *is* mutable, 
only has 42 elements.  But it cannot know offhand whether those are all 
possible elements, as that depends on the iterator that is being used to fill 
the NQP array.

A complicating factor is that this is a very hot code path, so any changes 
there could affect general performance significantly.  My initial tests to 
generate a Failure on out of bounds value immediately results in 2 internal 
errors trying to generate backtrace  :-(

Anyways, I agree with brian’s feelings on this.  The challenge is now to make 
it so without making everything significantly slower.

FWIW, the code in question lives around line 480 in List.pm.


Liz

Re: [perl #131699] [LTA] Errors indexing past the end of a List

[Elizabeth Mattijsen via RT]

> On 4 Jul 2017, at 16:19, Elizabeth Mattijsen  wrote:
> That said, a List may not always be completely reified already.  So 
> logically, a List may  have 100 elements, it could well be that only 42 of 
> these elements exist already.  Which means that the underlying NQP array, 
> which *is* mutable, only has 42 elements.  But it cannot know offhand whether 
> those are all possible elements, as that depends on the iterator that is 
> being used to fill the NQP array.
> 
> A complicating factor is that this is a very hot code path, so any changes 
> there could affect general performance significantly.  My initial tests to 
> generate a Failure on out of bounds value immediately results in 2 internal 
> errors trying to generate backtrace  :-(
> 
> Anyways, I agree with brian’s feelings on this.  The challenge is now to make 
> it so without making everything significantly slower.
> 
> FWIW, the code in question lives around line 480 in List.pm.

An example of a List that will never be fully reified:

  $ 6 'my $l = ^Inf .list; dd $l.^name; dd $l[10]'
  "List"
  10


Liz

Re: [perl #131673] `is rw` on anon parameter causes "inconsistent bind result" error

[Elizabeth Mattijsen via RT]

Shouldn’t:

  sub ($ is rw) { }

be a compile-time error?  I mean, there is no way to actually assign to the 
anonymous variable, is there?  So there is no point in the “is rw”.  So most 
likely indicates a typo on the user side.

> On 29 Jun 2017, at 01:05, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #131673]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131673 >
> 
> 
> Works as expected:
>23:03  m: sub ($x is rw) {}(42)
>cameliarakudo-moar 2a8d1e: OUTPUT: «Parameter '$x' expected a 
> writable container, but got Int value␤  in sub  at  line 1␤  in 
> block  at  line 1␤␤»
> 
> Doesn't:
>23:04  m: sub ($ is rw) {}(42)
>23:04  camelia rakudo-moar 2a8d1e: OUTPUT: «Internal error: 
> inconsistent bind result␤  in sub  at  line 1␤  in block  at 
>  line 1␤␤»

Re: [perl #131842] [LTA] Error says wanted number of arguments is 1; passed 1

[Elizabeth Mattijsen via RT]

> On 5 Aug 2017, at 00:43, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #131842]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131842 >
> 
> 
> 20:49 ufobat  m: sub foo (|a, :%e) { a.perl.say }; foo(1, :e( a => 1))
> 20:49 camelia rakudo-moar abf1cf: OUTPUT: «Too many positionals passed to 
> 'foo'; expected 1 argument but got 1?  in sub foo at  line 1?  in block 
>  at  line 1??»

This should probably be a compile time error, as:

   $ 6 'sub foo (:%e, |a) { a.perl.say }; foo(1, :e( a => 1))'
   \(1)

works fine.  Well, fsvo  :)

Re: [perl #131826] Hash slice with structured list does not come out structured

[Elizabeth Mattijsen via RT]

> On 1 Aug 2017, at 14:36, Zoffix Znet via RT  
> wrote:
> 
> Turns out the rabbit hole goes deeper. Adverbs appear to not work if slice is 
> structured:
> 
>my %a = 'a'..'z';
>dd %a{, (, ('m', ('o')))}:kv; # OUTPUT: ()
>%a{, (, ('m', ('o')))}:delete;
>dd +%a.keys; # OUTPUT:  13
> 
> Shouldn't it give structured `kv` data back and delete at least some keys?

I wonder whether we shouldn’t make all of the slicing lazy.  So instead of 
returning a reified List, it would return a Seq.

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

[Elizabeth Mattijsen via RT]

reverted c63c57e9a823303e74c06 for now

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

Re: [perl #131855] Mix.roll doesn't work with fractional weights

[Elizabeth Mattijsen via RT]

Oops.  Caught by a copy-pasto.  Fixed with a91ad2da854831a7a38c1d , tests 
needed.

> On 7 Aug 2017, at 20:59, Brad Gilbert (via RT)  
> wrote:
> 
> # New Ticket Created by  Brad Gilbert 
> # Please include the string:  [perl #131855]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131855 >
> 
> 
> 
>> Mix( 'a' => 0.3 ).roll
> 
>Type check failed in binding; expected Int but got Rat (0.3)
>  in block  at  line 1
> 
> This worked prior to `Add R:Q.MIX-ROLL, make Mix.roll() about 2.5x as fast`[1]
> 
> 
> [1] 
> https://github.com/rakudo/rakudo/commit/a2602b9cee60f746b6012c87c146d68cb79b4bed

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

[Elizabeth Mattijsen via RT]

Added to my todo list

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

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 #131241] (Bag|Mix)Hash.values doesn't check validity of assigned values

[Elizabeth Mattijsen via RT]

Fixed for the .values case with c1bd844e2752799af8e and 0e0ac2fb8c51a82a0 .  
But this needs a more thorough fix.  To be forthcoming soon!

> On 1 May 2017, at 19:28, Elizabeth Mattijsen (via RT) 
> <perl6-bugs-follo...@perl.org> wrote:
> 
> # New Ticket Created by  Elizabeth Mattijsen 
> # Please include the string:  [perl #131241]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131241 >
> 
> 
>   m: my $b = .BagHash; $_ = 0 for $b.values; dd $b
>  rakudo-moar 1f80db: OUTPUT: «BagHash $b = 
> ("b"=>0,"a"=>0,"c"=>0).BagHash␤»
>   m: my $b = .BagHash; $_ = -1 for $b.values; dd $b
>  rakudo-moar 1f80db: OUTPUT: «BagHash $b = 
> ("b"=>-1,"a"=>-1,"c"=>-1).BagHash␤»
>   m: my $b = .MixHash; $_ = 0 for $b.values; dd $b
>  rakudo-moar 1f80db: OUTPUT: «MixHash $b = 
> ("b"=>0,"a"=>0,"c"=>0).MixHash␤»
> 
> All should empty out the BagHash/MixHash.

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

[Elizabeth Mattijsen via RT]

Fixed for (elem) and (cont) with 
https://github.com/rakudo/rakudo/commit/ba0581d75b .
Tests needed.

> On 12 May 2017, at 21:22, Zoffix Znet via RT  
> 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()

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

[Elizabeth Mattijsen via RT]

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

Re: [perl #131303] [BUG] [LTA] bag operation fails and leaks internal state

[Elizabeth Mattijsen via RT]

Argh.  This is waiting for the refactor of (-) .  Looking at how quickly I can 
do this while at the PTS.

> On 13 May 2017, at 12:27, Jan-Olof Hendig (via RT) 
>  wrote:
> 
> # New Ticket Created by  Jan-Olof Hendig 
> # Please include the string:  [perl #131303]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131303 >
> 
> 
> # the system
> dogbert@dogbert-VirtualBox ~/repos/rakudo $ ./perl6 -v
> This is Rakudo version 2017.04.3-238-g50d5ac327 built on MoarVM version 
> 2017.04-64-g6d5ea042
> implementing Perl 6.c.
> 
> # the problem
> dogbert@dogbert-VirtualBox ~/repos/rakudo $ ./perl6 -e 'say bag( d>) (-) bag() == bag()'
> P6opaque: get_boxed_ref could not unbox for the representation '20' of type 
> Scalar
>  in block  at -e line 1
> 
> # Alexdaniel++ quickly dug up the following
> 12:15:17  +bisectable6 | AlexDaniel, Bisecting by exit code (old=2015.12 
> new=50d5ac3). Old exit code: 0
> 12:15:26  +bisectable6 | AlexDaniel, bisect log: 
> https://gist.github.com/ea9b1f5cafac02e57b9a7d2d3eb01b8c
> 12:15:26  +bisectable6 | AlexDaniel, (2017-05-11) 
> https://github.com/rakudo/rakudo/commit/788e6de6dc6b90e2938451afbf80e31a591b1550
> 

Re: [perl #131303] [BUG] [LTA] bag operation fails and leaks internal state

[Elizabeth Mattijsen via RT]

The problem was actually in setting values in (Bag|Mix)Hash.  The problem could 
be golfed to:

  my $b = BagHash.new; $b = 42; $b.total

Fixed in https://github.com/rakudo/rakudo/commit/4c813666df .   Tests needed

> On 13 May 2017, at 12:27, Jan-Olof Hendig (via RT) 
>  wrote:
> 
> # New Ticket Created by  Jan-Olof Hendig 
> # Please include the string:  [perl #131303]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131303 >
> 
> 
> # the system
> dogbert@dogbert-VirtualBox ~/repos/rakudo $ ./perl6 -v
> This is Rakudo version 2017.04.3-238-g50d5ac327 built on MoarVM version 
> 2017.04-64-g6d5ea042
> implementing Perl 6.c.
> 
> # the problem
> dogbert@dogbert-VirtualBox ~/repos/rakudo $ ./perl6 -e 'say bag( d>) (-) bag() == bag()'
> P6opaque: get_boxed_ref could not unbox for the representation '20' of type 
> Scalar
>  in block  at -e line 1
> 
> # Alexdaniel++ quickly dug up the following
> 12:15:17  +bisectable6 | AlexDaniel, Bisecting by exit code (old=2015.12 
> new=50d5ac3). Old exit code: 0
> 12:15:26  +bisectable6 | AlexDaniel, bisect log: 
> https://gist.github.com/ea9b1f5cafac02e57b9a7d2d3eb01b8c
> 12:15:26  +bisectable6 | AlexDaniel, (2017-05-11) 
> https://github.com/rakudo/rakudo/commit/788e6de6dc6b90e2938451afbf80e31a591b1550
> 

Re: [perl #131290] is default() doesn't work on attributes

[Elizabeth Mattijsen via RT]

> On 13 May 2017, at 03:45, Brad Gilbert via RT  
> wrote:
> On Fri, 12 May 2017 03:04:46 -0700, elizabeth wrote:
>> m: class A { has Int $.a is default(42) }; dd A.new.a
>> # expected to see 42 there, not Int, so feels like "is default" on
>> attrs isn't implemented?
> 
> It does work if you add =Nil
> 
>class A { has Int $.a is rw is default(42) = Nil };
>dd A.new.a; # 42
>$_ = A.new(:a(34));
>.a = Nil;
>dd .a; # 42

The whole reason for me to look at this, was to prevent the explicit 
initialization, done by BUILDALL.  If you don’t, it still doesn’t work:

$ 6 'class A { has Int $.a is rw is default(42) = Nil }; say A.CREATE.a'
(Int)


:-(

Re: [perl #131332] [BUG] Hyper method call on typed Array returns "impossible" result

[Elizabeth Mattijsen via RT]

> On 20 May 2017, at 13:05, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #131332]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131332 >
> 
> 
> By hypering a method on an Array typed with Pair containing Pairs, it 
> magically turns into a typed Pair Array containing Str objects, which would 
> normally fail the type check:
> 
> m: my Pair @p = a => 1, b => 2; dd  @p».key
> rakudo-moar 316399: OUTPUT: «Array[Pair].new("a", "b")␤»

Shouldn’t this like, eh, return a .Seq ??

Re: [perl #131330] [PERF] for ^N { } got about 2.5x slower in 5401a1a

[Elizabeth Mattijsen via RT]

> On 19 May 2017, at 23:56, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #131330]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131330 >
> 
> 
> 
> Detective work points to 5401a1a[^1] as the culprit. See chat log:
> https://irclog.perlgeek.de/perl6-dev/2017-05-19#i_14609181
> 
> [1] 
> https://github.com/rakudo/rakudo/commit/5401a1aa8f12c360ccd3e4000dcdc65ad98c746a

FWIW, if you look at profiles with and without 5401a1a , you will see that the 
profile without basically hasn’t anything to profile (with one anonymous 
codeblock done 1M times), whereas the one with 5401a1a goes through the generic 
mapping iterator and does a pull-one 1M times.  The exclusive time for the 
generic mapping iterator accounts for almost all of the difference in 
performance.

Re: [perl #131333] use of undeclared attributes gives not useful line number in error

[Elizabeth Mattijsen via RT]

> On 20 May 2017, at 13:20, mt1957 (via RT)  
> wrote:
> 
> # New Ticket Created by  mt1957 
> # Please include the string:  [perl #131333]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131333 >
> 
> 
> in perl version 2017.04.3-287-g3e7675a built on MoarVM version 
> 2017.04-64-g6d5ea04
> implementing Perl 6.c I see the following error;
> 
> 
> t/120-Decimal128.t .. ===SORRY!=== Error while compiling 
> /home/marcel/Languages/Perl6/Projects/BSON/lib/BSON/Decimal128.pm6 
> (BSON::Decimal128)
> Attribute $!sstring not declared in class BSON::Decimal128
> at /home/marcel/Languages/Perl6/Projects/BSON/lib/BSON/Decimal128.pm6 
> (BSON::Decimal128):92
> 
> 
> This is  a writing error of course of attribute $!string. The line 
> number however, was at the end of the module and not at the (first) 
> location where it is used.

Fixing this would involve remembering where an attribute was first mentioned, 
as this is fully legal:

  class A { method a { $!a }; has $!a }

aka, specifying the attribute *after* it was mentioned.  So it wouldn’t know it 
wasn’t defined until it hit the end of the class.

Re: [perl #131364] concurrent quicksort from Damien gives different crashes each time

[Elizabeth Mattijsen via RT]

FWIW, I can’t get this to break on 2017.05.  Please note that a *LOT* of 
concurrency fixes landed after 2016.04.  I suggest you use a more current 
version, preferably 2017.05.  Unless this problem can be confirmed on a more 
recent Rakudo version, I suggest this ticket can be closed.

> On 25 May 2017, at 17:01, Sverre Eldøy (via RT) 
>  wrote:
> 
> # New Ticket Created by  Sverre Eldøy 
> # Please include the string:  [perl #131364]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131364 >
> 
> 
> Hi!
> 
> I was just playing around with the concurrent quicksort thing that Damien 
> made.. It's neat.. But problem is: It crashes in different ways each time... 
> Here's a couple of examples:
> 
> Run1:
> Illegal instruction: 4
> 
> Run2:
> Use of uninitialized value of type Any in string context
> Any of .^name, .perl, .gist, or .say can stringify undefined things, if 
> needed.Use of uninitialized value of type Any in string context
> Any of .^name, .perl, .gist, or .say can stringify undefined things, if 
> needed.  in whatevercode  at ./quicksort_concurrent.p6 line 10
> Use of uninitialized value  of type Any in string context
> Any of .^name, .perl, .gist, or .say can stringify undefined things, if 
> needed.Use of uninitialized value  of type Any in string context
> Any of .^name, .perl, .gist, or .say can stringify undefined things, if 
> needed.  in sub quicksort at ./quicksort_concurrent.p6 line 4
>  in whatevercode  at ./quicksort_concurrent.p6 line 10
> Use of uninitialized value $pivot of type Any in string context
> Any of .^name, .perl, .gist, or .say can stringify undefined things, if 
> needed.Use of uninitialized value $pivot of type Any in string context
> Any of .^name, .perl, .gist, or .say can stringify undefined things, if 
> needed.  in sub quicksort at ./quicksort_concurrent.p6 line 4
>  in whatevercode  at ./quicksort_concurrent.p6 line 10
> Use of uninitialized value $pivot of type Any in string context
> Any of .^name, .perl, .gist, or .say can stringify undefined things, if 
> needed.  in whatevercode  at ./quicksort_concurrent.p6 line 10
>  in sub quicksort at ./quicksort_concurrent.p6 line 4
> Use of uninitialized value $pivot of type Any in string context
> Any of .^name, .perl, .gist, or .say can stringify undefined things, if 
> needed.Use of uninitialized value $pivot of type Any in string context
> Any of .^name, .perl, .gist, or .say can stringify undefined things, if 
> needed.  in whatevercode  at ./quicksort_concurrent.p6 line 10
>  in sub quicksort at ./quicksort_concurrent.p6 line 4
> Use of uninitialized value $pivot of type Any in string context
> Any of .^name, .perl, .gist, or .say can stringify undefined things, if 
> needed.  in sub quicksort at ./quicksort_concurrent.p6 line 4
> This type does not support positional operations
>  in block  at ./quicksort_concurrent.p6 line 17
> 
> Run3:
> Segmentation fault: 11
> 
> Run4:
> This type does not support positional operations
>  in block  at ./quicksort_concurrent.p6 line 1
> 
> 
>  The code was just a slightly modified version of the example from 
> Damien.. And it runs if I take away some numbers.. So I suspect that there is 
> something weird going on.. Try it on your machines...
> 
> My environment is Mac os x (sierra) running 
> This is Rakudo version 2016.04 built on MoarVM version 2016.04
> implementing Perl 6.c.
> ... as that is what comes with brew these days... Not sure if the same thing 
> happens on bleeding edge..
> 
> Here's the code:
> #! /usr/bin/env perl6
> use v6;
> 
> multi quicksort(  []  ) { () };
> 
> multi quicksort( [$x] ) { $x };
> 
> multi quicksort( [$pivot, *@xs] ) {
>flat await
> start { quicksort @xs.grep: *  before $pivot },
> start { $pivot   },
> start { quicksort @xs.grep: * !before $pivot };
> }
> 
> say "output = { quicksort 
> [3,4,2,4,3,6,34589734,7,5,467,675,456,345,345,234,346,457,45,234,12,3123,3,9,8,7,6,7,8,9,8,7,6,7,8,9,8,7,7,6,5,5,5,4,4,4,444,9860,33,3,1,123,234,6,3,5,7,2,4543,2,342,143,234,234,234,4,36,234,324,5,234,457,678,3,1,4,1,5,9,2,6]
>  }";
> 
> 
> 
> 
> 
> 
> BR,
> Sverre

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

[Elizabeth Mattijsen via RT]

Thanks for the report!

Fixed with https://github.com/rakudo/rakudo/commit/87d0e0a39e .  Tests needed.

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

Re: [perl #131392] %() creates a Map

[Elizabeth Mattijsen via RT]

> On 28 May 2017, at 20:56, brian d foy (via RT)  
> wrote:
> 
> # New Ticket Created by  "brian d foy" 
> # Please include the string:  [perl #131392]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131392 >
> 
> 
> It looks like %() with no characters between the parens creates a
> Map, but if there's at least one character between the parens, it
> creates a Hash. I figure all of these should create a Hash:
> 
>my %hash = %();
>put '1: ', %hash.^name;  # 1: Hash
> 
>my $hash-empty = %();
>put '2: ', $hash-empty.^name;# 2: Map
> 
>my $hash-space = %( );
>put '3: ', $hash-space.^name;# 3: Hash

FWIW, I have not been able to reproduce it, not on 2017.04.3 or HEAD or even 
2015.12.  So I find all of this rather strange  :-)

Re: [perl #131372] [BUG] infix eqv may hang when comparing equivalent recursive arrays

[Elizabeth Mattijsen via RT]

> On 26 May 2017, at 12:59, Peter du Marchie van Voorthuysen (via RT) 
>  wrote:
> 
> # New Ticket Created by  Peter du Marchie van Voorthuysen 
> # Please include the string:  [perl #131372]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131372 >
> 
> 
> This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-53-g66c6dda
> implementing Perl 6.c.
> 
> The eqv implementation hangs when executing the following code:
> 
>my $a = [];
>$a[0] = $a;
> 
>my $b = [];
>$b[0] = $b;
> 
>$a eqv $b;
> 
> In the REPL a Ctrl-C won't terminate the evaluation. At first the memory
> footprint of the moar process grows quickly, but over time the pace of
> growth decreases while the CPU is kept busy.

This golfs to:

my @a = $(my @b); @b[0] = @a; @a eqv @b

Same problem exists with hashes BTW:

my %a = a => my %b; %b = %a; %a eqv %b

Seems we need something like perlseen for eqv as well.


Looking at it now.

Re: [perl #131392] %() creates a Map

[Elizabeth Mattijsen via RT]

> On 29 May 2017, at 18:26, brian d foy  wrote:
> I did pull my first example out of a slightly larger program I was
> playing with, but I thought that a match would surely have no effect.
> Stupid me, because I've been around long enough to know that
> assumption is almost always false. That "harmless" thing you leave out
> is the actual problem. Here's a complete program that reproduces it:
> 
>'abcdef' ~~ m/ cd /;
> 
>my $thingy = %();
>put $thingy.^name;  #Map

Well, do we consider the named matches of a match modifiable or not?  Feels to 
me having it as an (immutable) Map feels actually closer to the intent, rather 
than it being a (modifiable) Hash.  It also gives more opportunity for 
optimization.

So perhaps the Hashes should be considered the odd ones out?



Liz

Re: [perl #131395] Using a cross meta operator on an empty list complains about not supporting elems

[Elizabeth Mattijsen via RT]

> On 29 May 2017, at 19:06, Zoffix Znet via RT  
> wrote:
> 
> https://irclog.perlgeek.de/perl6/2017-05-29#i_14654174
> 
> 16:54 bisectable6 MasterDuke, bisect log: 
> https://gist.github.com/7d49ce1401bee0ab3127c5d1be2a919e
> 16:54 MasterDuke, (2017-01-16) 
> https://github.com/rakudo/rakudo/commit/8a3ff7b64b51a66e0e90437bbeb4793534a07026
> 
> 16:57 Zoffix  m: use nqp; nqp::elems(nqp::getattr((), List, '$!reified'))
> 16:57 camelia rakudo-moar a18c06: OUTPUT: «This type (Scalar) does not 
> support elems␤  in block  at  line 1␤␤»
> 
> 
> 17:00 m: use nqp; dd nqp::getattr((), List, '$!reified').^name; dd 
> nqp::getattr([], List, '$!reified').^name
> 17:00 camelia rakudo-moar a18c06: OUTPUT: «"Mu"␤"IterationBuffer"␤»
> 17:00 Zoffix  Both prolly should be the same? So this bug doesn't occur 
> elsewhere?

FWIW, I’m testing a fix.



Liz

Re: [perl #131408] Curious "Too many positionals" error from bail-out() with no positionals.

[Elizabeth Mattijsen via RT]

Fixed with cb82760625f6b8fec64a75 , tests needed.

> On 31 May 2017, at 07:20, brian d foy (via RT)  
> wrote:
> 
> # New Ticket Created by  "brian d foy" 
> # Please include the string:  [perl #131408]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131408 >
> 
> 
> I have this program:
> 
>#!/Applications/Rakudo/bin/perl6
> 
>use Test;
>bail-out();
> 
> When I run it, it complains about too many parameters:
> 
>$ prove -e 'perl6 -Ilib' t/bail.t
>t/bail.t .. Any
>Too many positionals passed; expected 1 argument but got 2
>  in sub bail-out at
> /Applications/Rakudo/share/perl6/sources/C712FE6969F786C9380D643DF17E85D06868219E
> (Test) line 258
>  in block  at t/bail.t line 4
> 
>t/bail.t .. Dubious, test returned 1 (wstat 256, 0x100)
>No subtests run
> 
>Test Summary Report
>---
>t/bail.t (Wstat: 256 Tests: 0 Failed: 0)
>  Non-zero exit status: 1
>  Parse errors: No plan found in TAP output
>Files=1, Tests=0,  2 wallclock secs ( 0.03 usr  0.01 sys +  2.14
> cusr  0.16 csys =  2.34 CPU)
>Result: FAIL
> 
> This is the section causing the problem:
> 
>256 sub bail-out ($desc?) is export {
>257 $output.put: join ' ', 'Bail out!', ( $desc ?? $desc !! '' );
>258 $done_testing_has_been_run = 1;
>259 exit 255;
>260 }
> 
> I made several changes to try to suss out the problem, but I couldn't
> make the error go away without removing line 257. When I check 
> "$output.^name",
> I get "Any".
> 
> Running without `prove` shows the same problem:
> 
>$ perl6 t/bail.t
>Too many positionals passed; expected 1 argument but got 2
>  in sub bail-out at
> /Applications/Rakudo/share/perl6/sources/C712FE6969F786C9380D643DF17E85D06868219E
> (Test) line 257
>  in block  at t/bail.t line 4
> 
> Running it in https://glot.io/new/perl6 shows the same thing.
> 
> Besides the actual error, the error message isn't great. I would have
> liked it to mention the method name and class causing the problem.
> 
> 
> This is:
> 
>$ perl6 -v
>This is Rakudo version 2017.04.3 built on MoarVM version 
> 2017.04-53-g66c6dda
>implementing Perl 6.c.

Re: [perl #131412] [BUG] Label.goto() not yet implemented

[Elizabeth Mattijsen via RT]

> On 31 May 2017, at 19:53, Kais Ben Salah (via RT) 
>  wrote:
> 
> # New Ticket Created by  Kais Ben Salah 
> # Please include the string:  [perl #131412]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131412 >
> 
> 
> Hello,
> 
> perl6 is showing "Label.goto() not yet implemented. Sorry.".
> 
> Further informations:
> perl6 -v
> This is Rakudo version 2016.12 built on MoarVM version 2016.12
> implementing Perl 6.c.

Please elaborate on how you got this message?  What you have reported now is 
akin to:

“My car doesn’t have a direction indicator”.


FWIW, if you were trying to execute the “goto” message on a Label object, the 
message is correct:  that still isn’t implemented, even on a more recent 
version like 2017.05.

Re: [perl #131561] [REGRESSION] dd (0 => 1, 0 => -1, 0 => 0).MixHash Does not delete the key

[Elizabeth Mattijsen via RT]

Thanks for the report!   Fixed with 
https://github.com/rakudo/rakudo/commit/bf95bcb6c0
Tests will be added shortly.

> On 13 Jun 2017, at 00:52, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #131561]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131561 >
> 
> 
> Detected by pre-release ecosystem toasting.
> 
> Clifford.pm6 module currently fails due List.MixHash coercer
> fails to delete the key when the final weight ends up being zero:
> 
> c: 2017.05,HEAD dd (0 => 1, 0 => -1, 0 => 0, ).MixHash
> Zoffix, ¦2017.05: «().MixHash» ¦HEAD(abfb52b): 
> «(0=>0).MixHash»
> 
> The issue only appears to happen the weights change from non-zero to zero 
> while going through Pairs:
> 
> c: 2017.05,HEAD dd (0 => 0, ).MixHash
> Zoffix, ¦2017.05,HEAD(abfb52b): «().MixHash»
> c: 2017.05,HEAD dd (0 => 0, 0 => 0,).MixHash
> Zoffix, ¦2017.05,HEAD(abfb52b): «().MixHash»

Re: [perl #131240] [BUG] SetHash retains container rather than object

[Elizabeth Mattijsen via RT]

Fixed with 551b8a69e0a83e2c34 , tests needed

> On 1 May 2017, at 13:24, Jan-Olof Hendig (via RT) 
>  wrote:
> 
> # New Ticket Created by  Jan-Olof Hendig 
> # Please include the string:  [perl #131240]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131240 >
> 
> 
> # these examples demonstrate the problem
> 
> dogbert@dogbert-VirtualBox ~ $ perl6 -v
> This is Rakudo version 2017.04.3-134-g69320e7fa built on MoarVM version 
> 2017.04-44-gf0db8822 implementing Perl 6.c.
> 
> # the problem
> dogbert@dogbert-VirtualBox ~ $ perl6 -e 'my SetHash $set = SetHash.new; my $i 
> = 1001; $set{$i} = True; dd $set; $i++; dd $set'
> SetHash $set = SetHash.new(1001)
> SetHash $set = SetHash.new(1002)
> 
> # compare with an older version
> dogbert@dogbert-VirtualBox ~ $ perl6 -v
> This is Rakudo version 2016.12 built on MoarVM version 2016.12 implementing 
> Perl 6.c.
> 
> dogbert@dogbert-VirtualBox ~ $ perl6 -e 'my SetHash $set = SetHash.new; my $i 
> = 1001; $set{$i} = True; dd $set; $i++; dd $set'
> SetHash $set = SetHash.new(1001)
> SetHash $set = SetHash.new(1001)

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

[Elizabeth Mattijsen via RT]

Fixed with 31be51284e70badd8ed , tests needed.

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

Re: [perl #131364] [RESOLVED] concurrent quicksort from Damien gives different crashes each time

[Elizabeth Mattijsen via RT]

Could you please retry on 2017.05?  I cannot reproduce the problem, even after 
1000 runs.

> On 30 May 2017, at 17:25, Sverre Eldøy  wrote:
> 
> Hi! Sorry for the late reply. I just tried it on 2017.04 ... and the problem 
> is still there.. So please reopen
> 
> 
>> On 29 May 2017, at 20:53, Will Coleda via RT  
>> wrote:
>> 
>> According to our records, your request regarding
>> "concurrent quicksort from Damien gives different crashes each time"
>> has been resolved.
>> 
>> If you have any further questions or concerns, please respond to this 
>> message.
>> 
>> For other topics, please create a new ticket.
>> 
>> https://rt.perl.org/Ticket/Display.html?id=131364 >
> 

Re: [perl #131515] [PERF] Performance loss in some commits

[Elizabeth Mattijsen via RT]

> On 5 Jun 2017, at 19:30, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #131515]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131515 >
> 
> 
> Recently, we have had about ~2.7% overall performance loss, when running 
> stresstest/spectest that a couple of devs noticed.
> Tux's bench also showed a slowdown.
> 
> Based on stresstest timings I post ( 
> https://irclog.perlgeek.de/perl6-dev/search/?nick==ZOFVM ), the slowdown 
> happened in
> some commits made between 2017-05-31 and 2017-06-01. I tried narrowing down 
> what brought the slowdown, but couldn't quite
> pinpoint it, because there's some randomness in timings of some tests. Here's 
> my results of test times:
> 
> SHA   Stresstest (s)  Spectest (s)
> aebd0fa   123 
> 01d948d   122 
> 2500e50   121 / 122   86
> 79b8ab9   119 / 118   83
> b879060   117 / 119   82 / 82
> 3f5cc5a   117 
> 3488914   118 
> fb7dd8a   119 
> 
> As you can see, the middle commits is where the slowage appears to occur, 
> with 2500e50 being the most likely culprit,
> even though, the code itself isn't something that would be even remotely hot.
> 
> I went and rewrote it in NQP (attached) to see if it drops the numbers at 
> all, and... it didn't really.
> I got a 120s stresstest and a 85s spectest.
> 
> I gave up with this.
> 
> I think we need some extensive bench without any random sleeps or delays in 
> it and comprehensive enough to test more than
> just a few text methods. Perhaps, something that can be cooked up with 
> https://map.perl6.party/
> 
> And with such a bench in hand, it might become easier to hunt commits that 
> slow stuff down considerably.

Generally, we don’t care about performance once we have an unrecoverable 
exception that needs to be reported.  If the stresstest regression is caused by 
trying to do Levenstein on method names (which can be a lot on some objects), 
then maybe the performance of spectest/stresstest can be accounted for by 
*just* the tests that throw Method Not Found errors?

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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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  
> 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  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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #131599] [RFC] Allow a Callable for `is default` that will generate default values

[Elizabeth Mattijsen via RT]

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