[perl #128935] [BUG] "where" clauses are parsed, but not enforced, in "my" expressions
On Sun, 04 Dec 2016 01:21:56 -0800, c...@zoffix.com wrote: > On Sun, 14 Aug 2016 18:19:44 -0700, timo wrote: > > > > gfldex: m: dd my ($i, $k where * == 4) = (1,3); dd $i, $k > > +camelia: rakudo-moar ee8a25: OUTPUT«(1, 3)Int $i = 1Int $k = 3» > > > > Shouldn't allow $k to be bound to any value that doesn't numify to 4, > > but it does. > > > > Alternatively (or "in the mean time") it should probably complain > > that > > it's NYI. > > > > It is implemented and works for single variables. The bug occurs > whenever the my is done on several variables. > > And I can't get it to dump the parse tree, as it hangs (perhaps > related to the bug?): > > This is the shortest hanging golf I got: > > ./perl6 --target=parse -e 'my ($, $)' Using fix: Fix postconstraints in `my (...)` being ignored Using test: Test postconstraints in `my (...)` Thank you for the report. This is now fixed in branch `post-release`. Fix: https://github.com/rakudo/rakudo/commit/3745eff13a21ad8 Test: https://github.com/perl6/roast/commit/4ce0fc56db432b52b
[perl #128935] [BUG] "where" clauses are parsed, but not enforced, in "my" expressions
On Sun, 04 Dec 2016 01:21:56 -0800, c...@zoffix.com wrote: > On Sun, 14 Aug 2016 18:19:44 -0700, timo wrote: > > > > gfldex: m: dd my ($i, $k where * == 4) = (1,3); dd $i, $k > > +camelia: rakudo-moar ee8a25: OUTPUT«(1, 3)Int $i = 1Int $k = 3» > > > > Shouldn't allow $k to be bound to any value that doesn't numify to 4, > > but it does. > > > > Alternatively (or "in the mean time") it should probably complain > > that > > it's NYI. > > > > It is implemented and works for single variables. The bug occurs > whenever the my is done on several variables. > > And I can't get it to dump the parse tree, as it hangs (perhaps > related to the bug?): > > This is the shortest hanging golf I got: > > ./perl6 --target=parse -e 'my ($, $)' Using fix: Fix postconstraints in `my (...)` being ignored Using test: Test postconstraints in `my (...)` Thank you for the report. This is now fixed in branch `post-release`. Fix: https://github.com/rakudo/rakudo/commit/3745eff13a21ad8 Test: https://github.com/perl6/roast/commit/4ce0fc56db432b52b
[perl #129790] [OPTIMIZER] Giving a sub to a map fails
On Sat, 14 Oct 2017 18:38:47 -0700, alex.jakime...@gmail.com wrote:
> Maybe it is worth noting that this is pretty much a regression (even
> though an
> old one, and caused by a non-optimizer change).
>
> (2016-08-09)
> https://github.com/rakudo/rakudo/commit/328402599c16077e182bb38baf68e435b8bc1082
>
> Output before and after:
> https://gist.github.com/75b15f93438bd038cf0bec26c43eaa9f
>
> On 2016-10-03 01:32:09, barto...@gmx.de wrote:
> > Playing around I found that the following change made your examples
> > work as expected:
> >
> > diff --git a/src/Perl6/Optimizer.nqp b/src/Perl6/Optimizer.nqp
> > index 12398ba..9102b7f 100644
> > --- a/src/Perl6/Optimizer.nqp
> > +++ b/src/Perl6/Optimizer.nqp
> > @@ -1082,7 +1082,8 @@ class Perl6::Optimizer {
> > || nqp::istype($op[0][0], QAST::Stmts) &&
> > nqp::istype(($c1 := $op[0][0][0]), QAST::Op)
> > &&
> > nqp::existskey(%range_bounds, $c1.name)) &&
> > - $!symbols.is_from_core($c1.name) {
> > + $!symbols.is_from_core($c1.name) &&
> > + nqp::defined($op[0][1].ann('code_object')) {
> > self.optimize_for_range($op, $op[0][1], $c1);
> > self.visit_op_children($op);
> > return $op;
> >
> > $ ./perl6 -e '^4 .map: {};'
> > Cannot map a Range to a Hash.
> > Did you mean to add a stub ({...}) or did you mean to .classify?
> > in block at -e line 1
> >
> > $ ./perl6 -e '^4 .map: 42;'
> > Cannot resolve caller map(Range: Int); none of these signatures
> > match:
> > ($: Hash \h, *%_)
> > (\SELF: █; :$label, :$item, *%_)
> > (HyperIterable:D $: █; :$label, *%_)
> > in block at -e line 1
> >
> > $ ./perl6 -e 'sub foo ($) {say "meow"}; ^4 .map: &foo;'
> > meow
> > meow
> > meow
> > meow
> >
> > The original error came from the first two lines in 'method
> > optimize_for_ranges' in src/Perl6/Optimizer.nqp. For some reason
> > $callee.ann('code_object') did not return a code object as expected.
> >
> > method optimize_for_range($op, $callee, $c2) {
> > my $code := $callee.ann('code_object');
> > my $count := $code.count;
> >
> > Now, I have no idea whether my change from above makes sense or
> > whether the annotation for 'code_object' was wrong in the first
> > place.
Thank you for the report. This is now fixed in branch `post-release`.
Fix: https://github.com/rakudo/rakudo/commit/f3efe5e6b4a9ee5
Test: https://github.com/rakudo/rakudo/commit/f3efe5e6b4a9ee5
[perl #129790] [OPTIMIZER] Giving a sub to a map fails
On Sat, 14 Oct 2017 18:38:47 -0700, alex.jakime...@gmail.com wrote:
> Maybe it is worth noting that this is pretty much a regression (even
> though an
> old one, and caused by a non-optimizer change).
>
> (2016-08-09)
> https://github.com/rakudo/rakudo/commit/328402599c16077e182bb38baf68e435b8bc1082
>
> Output before and after:
> https://gist.github.com/75b15f93438bd038cf0bec26c43eaa9f
>
> On 2016-10-03 01:32:09, barto...@gmx.de wrote:
> > Playing around I found that the following change made your examples
> > work as expected:
> >
> > diff --git a/src/Perl6/Optimizer.nqp b/src/Perl6/Optimizer.nqp
> > index 12398ba..9102b7f 100644
> > --- a/src/Perl6/Optimizer.nqp
> > +++ b/src/Perl6/Optimizer.nqp
> > @@ -1082,7 +1082,8 @@ class Perl6::Optimizer {
> > || nqp::istype($op[0][0], QAST::Stmts) &&
> > nqp::istype(($c1 := $op[0][0][0]), QAST::Op)
> > &&
> > nqp::existskey(%range_bounds, $c1.name)) &&
> > - $!symbols.is_from_core($c1.name) {
> > + $!symbols.is_from_core($c1.name) &&
> > + nqp::defined($op[0][1].ann('code_object')) {
> > self.optimize_for_range($op, $op[0][1], $c1);
> > self.visit_op_children($op);
> > return $op;
> >
> > $ ./perl6 -e '^4 .map: {};'
> > Cannot map a Range to a Hash.
> > Did you mean to add a stub ({...}) or did you mean to .classify?
> > in block at -e line 1
> >
> > $ ./perl6 -e '^4 .map: 42;'
> > Cannot resolve caller map(Range: Int); none of these signatures
> > match:
> > ($: Hash \h, *%_)
> > (\SELF: █; :$label, :$item, *%_)
> > (HyperIterable:D $: █; :$label, *%_)
> > in block at -e line 1
> >
> > $ ./perl6 -e 'sub foo ($) {say "meow"}; ^4 .map: &foo;'
> > meow
> > meow
> > meow
> > meow
> >
> > The original error came from the first two lines in 'method
> > optimize_for_ranges' in src/Perl6/Optimizer.nqp. For some reason
> > $callee.ann('code_object') did not return a code object as expected.
> >
> > method optimize_for_range($op, $callee, $c2) {
> > my $code := $callee.ann('code_object');
> > my $count := $code.count;
> >
> > Now, I have no idea whether my change from above makes sense or
> > whether the annotation for 'code_object' was wrong in the first
> > place.
Thank you for the report. This is now fixed in branch `post-release`.
Fix: https://github.com/rakudo/rakudo/commit/f3efe5e6b4a9ee5
Test: https://github.com/rakudo/rakudo/commit/f3efe5e6b4a9ee5
[perl #130086] [BUG] multiple eof-s support on $*IN
On Sun, 13 Nov 2016 08:07:34 -0800, vivids...@gmail.com wrote: > Hello > > It is expected to be able to pass multiple eof-s (by pressing Ctrl+D). > > working p5 script: multiple-eof.pl > and two variants of p6 scripts, which falls to endless loop after > first "eof". > > Rakudo version 2016.10 built on MoarVM version 2016.10 implementing > Perl 6.c. Thanks for the report. Ironically, what you describe is the current behaviour I see with $*IN.lines (but not .Supply), however *that* is the bug, not the endless loop. I'm guessing Perl 5's readline simply behaves like C's read() does, hence why you can spam it with EOFs and still get it to try to read more. In our handles, however, we know when we've already reached EOF even for non-seekable handles. I rather we don't special case [some] IO::Handle read methods to ignore EOF for TTYs, so I unified[^1](https://github.com/rakudo/rakudo/commit/359efef709) IO::Handle.get (and by extension IO::Handle.lines) to behave the same as .read and related methods and not attempt to read if we've reached EOF. (I wrote the tests to cover that, but even with our convoluted `run-with-tty` test routine they did not cover the bug, so I just left it without tests). As far as replicating Perl 5's behaviour, I can imagine situtations where that'd be handy and it would be nice to have a non-NQP way to achieve it. I think nqp::getstdin() (and *out/*err) should reset the handles. So they'd flush buffers, if any, set byte_position and eof_reported to zero. This way, the end user could just do `$*IN.=open` if they require to "reset" the $*IN and attempt to read from STDIN again. I filed that as https://github.com/rakudo/rakudo/issues/1424
[perl #130086] [BUG] multiple eof-s support on $*IN
On Sun, 13 Nov 2016 08:07:34 -0800, vivids...@gmail.com wrote: > Hello > > It is expected to be able to pass multiple eof-s (by pressing Ctrl+D). > > working p5 script: multiple-eof.pl > and two variants of p6 scripts, which falls to endless loop after > first "eof". > > Rakudo version 2016.10 built on MoarVM version 2016.10 implementing > Perl 6.c. Thanks for the report. Ironically, what you describe is the current behaviour I see with $*IN.lines (but not .Supply), however *that* is the bug, not the endless loop. I'm guessing Perl 5's readline simply behaves like C's read() does, hence why you can spam it with EOFs and still get it to try to read more. In our handles, however, we know when we've already reached EOF even for non-seekable handles. I rather we don't special case [some] IO::Handle read methods to ignore EOF for TTYs, so I unified[^1](https://github.com/rakudo/rakudo/commit/359efef709) IO::Handle.get (and by extension IO::Handle.lines) to behave the same as .read and related methods and not attempt to read if we've reached EOF. (I wrote the tests to cover that, but even with our convoluted `run-with-tty` test routine they did not cover the bug, so I just left it without tests). As far as replicating Perl 5's behaviour, I can imagine situtations where that'd be handy and it would be nice to have a non-NQP way to achieve it. I think nqp::getstdin() (and *out/*err) should reset the handles. So they'd flush buffers, if any, set byte_position and eof_reported to zero. This way, the end user could just do `$*IN.=open` if they require to "reset" the $*IN and attempt to read from STDIN again. I filed that as https://github.com/rakudo/rakudo/issues/1424
