[perl #116096] [BUG] Set.new erroneously flattens arrays in Rakudo

2014-10-08 Thread Christian Bartolomaeus via RT
Arrays are no longer flattened by Set.new: > say set(([1, 2], [3, 4])).perl set([1, 2],[3, 4]) I added a test to S02-types/set.t with the following commit: https://github.com/perl6/roast/commit/e8fd9ec55d

[perl #113964] [BUG] LTA error message when passing to a typed slurpy array parameter in Rakudo

2014-10-08 Thread Christian Bartolomaeus via RT
The error message looks adequate now: $ perl6 -e 'sub foo(Int *@ints) {}' ===SORRY!=== Error while compiling -e Slurpy positionals with type constraints are not supported. at -e:1 --> sub foo(Int *@ints⏏) {} expecting any of: formal parameter constraint But as it was point

[perl #77738] [bug] is rw on slurpy parameters

2014-10-08 Thread Christian Bartolomaeus via RT
This works now: > sub incr1 (*@v is rw) { @v[0]++; @v[1]++; }; my ($a, $b) = (0, 0); incr1($a, > $b); say "incr1: $a, $b"; incr1: 1, 1 > sub incr2 (*@v is rw) { for @v { $_++} }; my ($a, $b) = (0, 0); incr2($a, > $b); say "incr2: $a, $b"; incr2: 1, 1 > sub incr3 (*@v is rw) { for @v -> $x is r

Re: bug in object.^attributes; on the git

2014-10-08 Thread Francis (Grizzly) Smit
On 09/10/14 00:20, Timo Paulssen wrote: On 08/10/14 15:05, Francis (Grizzly) Smit wrote: I have found this bug in the current git version of rakudo: 23:16:34 grizzlysmit@rakbat:~/Projects/perl/perl6/testing0$ perl6 --version This is perl6 version 2014.09-165-g19d2de5 built on MoarVM version 20

Re: bug in object.^attributes; on the git

2014-10-08 Thread Timo Paulssen
On 08/10/14 15:05, Francis (Grizzly) Smit wrote: I have found this bug in the current git version of rakudo: 23:16:34 grizzlysmit@rakbat:~/Projects/perl/perl6/testing0$ perl6 --version This is perl6 version 2014.09-165-g19d2de5 built on MoarVM version 2014.09-14-g0df2d6f 00:01:10 grizzlysmit

bug in object.^attributes; on the git

2014-10-08 Thread Francis (Grizzly) Smit
I have found this bug in the current git version of rakudo: 23:16:34 grizzlysmit@rakbat:~/Projects/perl/perl6/testing0$ perl6 --version This is perl6 version 2014.09-165-g19d2de5 built on MoarVM version 2014.09-14-g0df2d6f 00:01:10 grizzlysmit@rakbat:~/Projects/perl/perl6/testing0$ cat ./bug.p

[perl #116204] [BUG] Null PMC access when hitting 'last' in code block in regex in loop in Rakudo

2014-10-08 Thread Christian Bartolomaeus via RT
There is no longer a Null PMC access error when hitting 'last' in code block in regex in loop: $ perl6-m -e 'repeat while False { "foo" ~~ / "f" { say "got here" } "o" { last } / }; say "after the loop"' got here after the loop $ perl6-p -e 'repeat while False { "foo" ~~ / "f" { say "got here"

[perl #116314] [BUG] 'for' loops in phasers in 'for' loops don't run in Rakudo

2014-10-08 Thread Christian Bartolomaeus via RT
for loops in phasers in for loops are run now: > for 1..2 { ENTER { .say for }; .say} foo bar 1 foo bar 2 I added a test to S04-phasers/enter-leave.t with the following commit: https://github.com/perl6/roast/commit/0a2c9a8008

[perl #116695] [BUG] Wrong array length when Mu elements and delete interact in Rakudo

2014-10-08 Thread Christian Bartolomaeus via RT
It looks like deleting the last element of an array no longer deletes the undefined elements before it: > my $foo = [0,1,2,3,4]; say $foo.elems; say $foo.perl 5 [0, 1, 2, 3, 4] > $foo[4] = Any; $foo[3] = Any; say $foo.elems; say $foo.perl 5 [0, 1, 2, Any, Any] > $foo[4] :delete; say $foo.elems; s

[perl #115502] [BUG] 'try' at BEGIN time hangs in Rakudo

2014-10-08 Thread Christian Bartolomaeus via RT
This does no longer hang. $ perl6-m -e 'BEGIN { try 0 }; say "alive"' alive $ perl6-p -e 'BEGIN { try 0 }; say "alive"' alive $ perl6-j -e 'BEGIN { try 0 }; say "alive"' alive I added a test to S04-phasers/begin.t with the following commit: https://github.com/perl6/roast/commit/05bf75e3b6

[perl #77616] ~ operator in regexp reverts capture order, but it should not

2014-10-08 Thread Christian Bartolomaeus via RT
Current behaviour: > say so "abc" ~~ /a ~ (c) (b)/; say $0, $1 True 「b」 「c」 As I understand S05 the ~ operator basically rewrites the above regex to /a (b) (c)/ and only then matching and capturing happens. So the question seems to be, whether numbering of subpatterns should be done before the