[perl #127671] [EXOTICTEST] 「dir」 dies if weird unicode sequences are encountered (dir;)

2018-02-02 Thread Aleks-Daniel Jakimenko-Aleksejev via RT
Test added in
https://github.com/perl6/roast/commit/a7590d6543e1d29bc935377c727e4d15e38ee713

Note that the test *does create* files with weird names, but that's totally OK
in /tmp I think.

On 2017-03-02 07:06:54, c...@zoffix.com wrote:
> Explanation and ideas on IRC: https://irclog.perlgeek.de/moarvm/2017-
> 03-02#i_14193748
>
> - It's risky to be part of normal tests, lest the user won't be able
> to delete these weird dirs
> - Setup `make risky-test` target that would run these risky tests only
> when user asks (knowing they're on a system that can be trashed
> freely)



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

2018-02-02 Thread Aleks-Daniel Jakimenko-Aleksejev via RT
Test in
https://github.com/perl6/roast/commit/195227f779f7441de1678e12941550271da799b2

On 2017-07-09 19:40:57, alex.jakime...@gmail.com wrote:
> That's pretty good. But issues are not closed without tests, unless
> there's a
> good reason not to add a test. No reason was mentioned, therefore
> reopening
> this with “testneeded” tag.
>
> On 2017-07-09 15:49:46, jan-olof.hen...@bredband.net wrote:
> > On Wed, 19 Oct 2016 05:57:04 -0700, jn...@jnthn.net wrote:
> > > On Fri Oct 14 16:40:27 2016, sml...@gmail.com wrote:
> > > > The following code attempts to pipe a large Blob (larger than a
> > > > pipe's
> > > > buffer size) through an external command.
> > > > However, it hangs on the `.in.close` line and never finishes:
> > > >
> > > > my $proc = run «cat -», :in, :out, :bin;
> > > > my $input = ("a" x 100).encode;
> > > > my $promise = start {
> > > > $proc.in.write: $input;
> > > > $proc.in.close;
> > > > }
> > > > say $proc.out.slurp-rest(:close, :bin).bytes;
> > > > await $promise;
> > > >
> > > For now, if using threads, stick with Proc::Async (in the future,
> > > we'll probably re-implement Proc/run etc. in terms of Proc::Async).
> > >
> > > /jnthn
> >
> > jnthn recently made the above mentioned re-implementation so the code
> > shown in the report now works.
> >
> > Closing issue



[perl #125674] [LTA] error message prints wrong eject position (if True if { };)

2018-02-02 Thread Aleks-Daniel Jakimenko-Aleksejev via RT
Does not seem to be fixed at all. But I've added some todo-ed tests:
https://github.com/perl6/roast/commit/f9f5034a1e66e068bfe21227e35f100f3c1e3fef

On 2017-10-07 13:43:30, alex.jakime...@gmail.com wrote:
> Should be fixed in https://github.com/rakudo/rakudo/commit/5747bc7121
>
> Testneeded. Slightly relevant tests here:
> https://github.com/perl6/roast/commit/34577134e0
>
> On 2017-10-06 21:01:48, alex.jakime...@gmail.com wrote:
> > This one is a bit harder than it seems.
> >
> > So here is what throws:
> >
>
https://github.com/rakudo/rakudo/blob/f62ae60c48d1372df18b49aca44e10af44ead2d6/src/Perl6/Grammar.nqp#L315
> >
> > However, the cursor has wrong position for some reason. Looking at
> > the
> > lines
> > above, it may seem that doing this:
> >
> > self.'!cursor_pos'($pos);
> >
> > should fix the problem… but it doesn't! $pos variable is set
> > correctly, but
> > !cursor_pos does absolutely nothing. In fact, you can try setting it
> > to 0 or
> > any other value, no effect whatsoever.
> >
> > This suggests that the use of !cursor_pos in the same method does not
> > work too.
> > What is the right way to set the cursor?
> >
> > And why does the cursor even have the incorrect value there?
> >
> > As a bonus, this line seems to be unreachable:
> > self.missing("block (taken by some undeclared routine?)");
> >
> > I tried various things but nothing can trigger it. I found (via
> > google) some
> > code snippets that used to result in this error message, but nowadays
> > it simply
> > says “Missing block”. I bisected that change to
> >
>
https://github.com/rakudo/rakudo/commit/8a70c921e98ed260d3198d81b81b0960c8daa83b
> >
> >
> > On 2015-07-24 05:13:59, alex.jakime...@gmail.com wrote:
> > > Code:
> > > if True if { };
> > >
> > > ===SORRY!=== Error while compiling ./test.pl
> > > Missing block
> > > at ./test.pl:3
> > > --> if True if ⏏{ };
> > >
> > > Clearly the block is there. It seems like it expects a block before
> > > the
> > > second "if", but the cursor is placed incorrectly. STD gets it
> > > right:
> > >
> > > 15:03:25 std: if True if { };
> > > 15:03:26 std 28329a7: OUTPUT«===SORRY!===␤Missing block at
> > > /tmp/XbS0PJUJZo line 1:␤--> if True ⏏if { };␤Parse
> > > failed␤FAILED 00:00 135m␤»
> > >
> > > Similar problem with "unless", "while" and maybe some others.
> > >
> > > Tiny IRC discussion: http://irclog.perlgeek.de/perl6/2015-07-
> > > 24#i_10947603



[perl #123776] Binding a variable at BEGIN time doesn't stick aruond for runtime

2018-02-02 Thread Zoffix Znet via RT
On Tue, 30 Jan 2018 19:03:13 -0800, c...@zoffix.com wrote:
> On Tue, 30 Jan 2018 15:08:38 -0800, c...@zoffix.com wrote:
> > On Fri, 01 Dec 2017 12:09:05 -0800, alex.jakime...@gmail.com wrote:
> > > Still reproducible (2017.11, HEAD(5929887)), but is supposed to
> > > work?
> >
> > Don't see any reason why that'd be questionable.
> >
> > > On 2015-02-09 17:43:52, rayd...@cyberuniverses.com wrote:
> > > > m: my $a; BEGIN { $a := 1; say $a; }; say $a;
> > > > rakudo-{parrot,moar} 0cb22e: OUTPUT«1␤(Any)␤»
> > > >
> > > > m: my $a; BEGIN { $a = 1; say $a; }; say $a; # works with
> > > > assignment
> > > > rakudo-{parrot,moar} 0cb22e: OUTPUT«1␤1␤»
> >
> >
> > Another manifestation of the same bug:
> >
> >  m: BEGIN { my $a1 := 42; say $a1; }
> >  rakudo-moar deffe54b8: OUTPUT: «42␤»
> >  m: BEGIN { my $a1 = 42; say $a1; }
> >  rakudo-moar deffe54b8: OUTPUT: «42␤»
> >  m: BEGIN my $a1 = 42; say $a1;
> >  rakudo-moar deffe54b8: OUTPUT: «42␤»
> >  m: BEGIN my $a1 := 42; say $a1;
> >  rakudo-moar deffe54b8: OUTPUT: «(Mu)␤»
> 
> 
> 
> Tracked this to Perl6::World.compile_in_context but leaving it there,
> as it's getting too hard.
> Need to gain a few levels first.
> 
> The comment in the method reads:
># Create outer lexical contexts with all symbols visible. Maybe
># we can be a bit smarter here some day. But for now we just make a
># single frame and copy all the visible things into it.
> 
> So I imagine the binding gets made to this faked out block and never
> propagates back to the source where all the lexicals were copied from.


More comments: https://irclog.perlgeek.de/perl6/2018-02-02#i_15769787

15:11   jnthn   Zoffix: Yeah. Lexpads are immutable, and when we compile a 
BEGIN we obviously haven't finished the outer block yet, so we have to fake 
something up. But what? Containers are cloned from a "prototype", and the fake 
lexpad contains the static container. Thus what's actually happening is that on 
entry to the scope post-compilation, the Scalar is cloned complete with the 
value set in the prototype.
15:12   Of course, binding doesn't have that level of indirection so 
there's no way it can work.
15:12   We should perhaps detect it at compile time and say it can't 
work. Or...we could try diffing the scope after each BEGIN block and trying to 
somehow propagate bindings.


[perl #131409] whatever auto closure fails with smartmatch with regex

2018-02-02 Thread Zoffix Znet via RT
On Wed, 31 May 2017 03:31:49 -0700, zengargo...@gmail.com wrote:
> When using smartmatch against a regex, auto-whatever closure generation
> does not work whereas manual pointy closure does work.
> 
> A '{ * eq $match}' behaves differently than a '{ * ~~ /<$match>/}'.
> However, '-> $x { $x ~~ <$match>}' behaves as expected.
> 
> For a test case:
> https://gist.github.com/zengargoyle/5a14f01a35918f6c3391b90e9b85a22a
> 
> 
> zengargoyle


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/d80fc376d201056
Test: https://github.com/perl6/roast/commit/323a2b65948f05d62



[perl #131409] whatever auto closure fails with smartmatch with regex

2018-02-02 Thread Zoffix Znet via RT
On Wed, 31 May 2017 03:31:49 -0700, zengargo...@gmail.com wrote:
> When using smartmatch against a regex, auto-whatever closure generation
> does not work whereas manual pointy closure does work.
> 
> A '{ * eq $match}' behaves differently than a '{ * ~~ /<$match>/}'.
> However, '-> $x { $x ~~ <$match>}' behaves as expected.
> 
> For a test case:
> https://gist.github.com/zengargoyle/5a14f01a35918f6c3391b90e9b85a22a
> 
> 
> zengargoyle


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/d80fc376d201056
Test: https://github.com/perl6/roast/commit/323a2b65948f05d62