Re: [perl #127925] [BUG] Unicode handling on Windows command line

2017-02-10 Thread A. Sinan Unur 
I think my pull request has reached the point where it should work on
others' machines, too ;-)

Please try it out:

https://github.com/MoarVM/MoarVM/pull/528/files?diff=split

[perl #130725] [REGRESSION] (gather foo()).rotor($n, :partial) broken by fd8df7f2ad

2017-02-10 Thread Zoffix Znet via RT 
On Mon, 06 Feb 2017 04:04:16 -0800, consult...@jnthn.net wrote:
> Discovered this after some $dayjob code got busted by updating Rakudo.
> After bisecting, I got it down to this commit:
> 
> https://github.com/rakudo/rakudo/commit/fd8df7f2ad509689a64b8825e1c4bb622cf7486f
> 
> And from that thankfully could reduced the bug from the couple of
> thousand
> line app to the following code:
> 
> 11:50 < jnthn> m: sub foo() { for ^20 { take 'x' } }; for (gather
>foo()).rotor(3, :partial) { .say }
> 11:50 <+camelia> rakudo-moar c0a907: OUTPUT«(x x x)␤(x x x)␤(x x x)␤(x
> x
> x)␤(x
>  x x)␤(x x x)␤(x x)␤Cannot invoke this object (REPR:
>  Uninstantiable; Callable)␤  in block  at 
> line
> 1␤␤»
> 
> Note that putting a .list back in fixes it:
> 
> 11:50 < jnthn> m: sub foo() { for ^20 { take 'x' } }; for (gather
>foo()).list.rotor(3, :partial) { .say }
> 11:50 <+camelia> rakudo-moar c0a907: OUTPUT«(x x x)␤(x x x)␤(x x x)␤(x
> x
> x)␤(x
>  x x)␤(x x x)␤(x x)␤»
> 
> Bisectable also pointed to the same commit for this code, so it seems
> that's the culprit.

Thank you for the report. This is now fixed.

Fix: https://github.com/rakudo/rakudo/commit/bcd902a43e
Test: https://github.com/perl6/roast/commit/52668af6c5

[perl #127222] [GLR] Itemized empty list has wrong .perl stringification

2017-02-10 Thread Zoffix Znet via RT 
On Sat, 09 Jan 2016 05:05:06 -0800, lucasbuchala wrote:
> An itemized empty list is getting ".perl"-stringified as "$()", which
> I think is wrong since $() means some idiom using "$/". The fix should
> be just to make it stringify as "$( )" (with a space in the middle) or
> maybe "().item" for clarity. (Maybe in a future version of the
> language, the syntax "$()" could be made to really mean a itemized
> empty list.)
> 
> > say $( ).perl
> $()
> 
> > say ().item.perl
> $()
> 
> > 'foo' ~~ /o+/; say $()
> oo

Thank you for the report. This is now fixed.

Fix: https://github.com/rakudo/rakudo/commit/a148c70190
Test: https://github.com/perl6/roast/commit/dff2d90263

This also identified a wrong test in 6.c-errata:
Approval for change: https://irclog.perlgeek.de/perl6-dev/2017-02-10#i_14080972
Change in 6.c-errata: https://github.com/perl6/roast/commit/ca0ce9a5d7
Change in master: https://github.com/perl6/roast/commit/fc2f46ea02

[perl #125021] [JVM] Roast rakudo skip/todo test:./S05-modifier/perl5_5.t line:22 reason: nigh

2017-02-10 Thread Christian Bartolomaeus via RT 
The test in question is this:

is(("acdbcdbe" ~~ rx:P5/a(?:b|c|d){6,7}?(.)/ && $0), "e", 're_tests 617/1 
(801)');

It turns out that the problem is not related to P5, but happens with P6Regex as 
well:

  r: say ("ddd" ~~ / [ x | d ] **? 3 /)
   rakudo-jvm fb4f16: OUTPUT«｢d｣␤»
   ..rakudo-moar 637241: OUTPUT«｢ddd｣␤»

  r: say ("ddd" ~~ / [ x | d ] **? 2..3 /)
   rakudo-jvm fb4f16: OUTPUT«｢d｣␤»
   ..rakudo-moar 637241: OUTPUT«｢dd｣␤»

The greedy version works as expected:

 r: say ("ddd" ~~ / [ x | d ] ** 2..3 /)
 rakudo-moar 637241, rakudo-jvm fb4f16: OUTPUT«｢ddd｣␤»

I was unable to golf it further, so the alternation seems to be needed to 
produce the bug.

[perl #127682] [OSX] writing more than 8192 bytes to IO::Handle causes it to hang forever

2017-02-10 Thread Christian Bartolomaeus via RT 
FWIW that hangs on FreeBSD as well (maybe not too much a surprise, given the 
relationship of the OSes).