Re: [perl #129346] [BUG] Whatever being called on where-blocked subroutine cannot handle the sigilless values correctly
On Fri, Sep 23, 2016 at 11:42:20PM -0700, Itsuki Toyota wrote:
: # New Ticket Created by Itsuki Toyota
: # Please include the string: [perl #129346]
: # in the subject line of all future correspondence about this issue.
: # https://rt.perl.org/Ticket/Display.html?id=129346 >
:
:
: See the following results
:
: $ perl6 -e 'sub foo(\a where { *.WHAT === Int } ) { say "Hello"; }; foo(10);'
: Constraint type check failed for parameter 'a'
: in sub foo at -e line 1
: in block at -e line 1
Even if .WHAT were not special, this wouldn't ever work, because you've got
a double-closure there, one from the curlies, and the other from the *. So
the outer closure would return the inner closure, which would always evaluate
to true.
: $ perl6 -e 'sub foo(\a where -> \e { \e.WHAT === Int } ) { say "Hello"; };
foo(10);'
: Constraint type check failed for parameter 'a'
: in sub foo at -e line 1
: in block at -e line 1
This will never work because \e.WHAT returns a Capture object, which will never
=== Int.
: $ perl6 -e 'sub foo(\a where -> \e { e.WHAT === Int } ) { say "Hello"; };
foo(10);'
: Hello
That is, in fact, a correct way to write it.
: It seems that "Whatever *" cannot handle sigilless values correctly.
The sigilless variable isn't declared yet, so a.WHAT doesn't work either. But
this is another correct way to write it:
$ perl6 -e 'sub foo(\a where { .WHAT === Int } ) { say "Hello"; }; foo(10);'
Hello
Larry
RE: [perl #129321] [BUG] deepmap can recurse indefinitely under some circumstances
Here's what I found in S32:
deepmap
multi method deepmap ( @values: Code * --> Any )
multi deepmap ( Code $expression, *@values --> Any )
Like map and duckmap, deepmap evaluates the expression for each of the
values you give it. Unlike map and duckmap, an element is considered a value
only if it does not do the Iterable role. If the element is iterable, the
algorithm recurses to produce an identical structure to its input. Elements
that are not iterable are considered leaf values and mapped through the
supplied expression.
Because deepmap is defined as a recursive implicit loop, loop controls
apply only to the current level of the tree.
/dogbert17
-Original Message-
From: Zoffix Znet via RT [mailto:perl6-bugs-follo...@perl.org]
Sent: den 23 september 2016 18:39
To: jan-olof.hen...@bredband.net
Subject: [perl #129321] [BUG] deepmap can recurse indefinitely under some
circumstances
On Tue Sep 20 13:54:33 2016, jan-olof.hen...@bredband.net wrote:
> # tested with
>
> dogbert@dogbert-VirtualBox ~ $ perl6 -v This is Rakudo version
> 2016.09-19-g8be36b1 built on MoarVM version 2016.09 implementing Perl
> 6.c
>
> # the following two examples behave quite differently
>
> dogbert@dogbert-VirtualBox ~ $ perl6 -e 'my @a = [1,[2,3],4]; dd
> @a.duckmap({ $_ ~~ Int ?? $_ !! Any })' # this works as expected
> (1, (2, 3), 4)
>
> dogbert@dogbert-VirtualBox ~ $ perl6 -e 'my @a = [1,[2,3],"a"]; dd
> @a.duckmap({ $_ ~~ Int ?? $_ !! Any })' # this will hang or return
> 'Memory allocation failed; could not allocate xx bytes'
>
> /dogbert17
>
I see why the issue occurs, but have no idea what the correct behaviour should
be.
The docs for .duckmap read "For undefined return values, duckmap will try to
descend into the element if that element implements Iterable." but when would
an undefined Iterable would ever be descendable?
The hang itself happens here:
https://github.com/rakudo/rakudo/blob/e12ebb9/src/core/metaops.pm#L685
The Any returned from your condition is undefined, so duckmap calls the block
with it again, resulting in an infiniloop.
Based on the docs, a check for an Iterable is missing, but it feels wrong to me
that we'd be attempting to "descend" into an undefined Iterable :S
Re: [perl #129346] [BUG] Whatever being called on where-blocked subroutine cannot handle the sigilless values correctly
On Fri, Sep 23, 2016 at 11:42:20PM -0700, Itsuki Toyota wrote:
: # New Ticket Created by Itsuki Toyota
: # Please include the string: [perl #129346]
: # in the subject line of all future correspondence about this issue.
: # https://rt.perl.org/Ticket/Display.html?id=129346 >
:
:
: See the following results
:
: $ perl6 -e 'sub foo(\a where { *.WHAT === Int } ) { say "Hello"; }; foo(10);'
: Constraint type check failed for parameter 'a'
: in sub foo at -e line 1
: in block at -e line 1
Even if .WHAT were not special, this wouldn't ever work, because you've got
a double-closure there, one from the curlies, and the other from the *. So
the outer closure would return the inner closure, which would always evaluate
to true.
: $ perl6 -e 'sub foo(\a where -> \e { \e.WHAT === Int } ) { say "Hello"; };
foo(10);'
: Constraint type check failed for parameter 'a'
: in sub foo at -e line 1
: in block at -e line 1
This will never work because \e.WHAT returns a Capture object, which will never
=== Int.
: $ perl6 -e 'sub foo(\a where -> \e { e.WHAT === Int } ) { say "Hello"; };
foo(10);'
: Hello
That is, in fact, a correct way to write it.
: It seems that "Whatever *" cannot handle sigilless values correctly.
The sigilless variable isn't declared yet, so a.WHAT doesn't work either. But
this is another correct way to write it:
$ perl6 -e 'sub foo(\a where { .WHAT === Int } ) { say "Hello"; }; foo(10);'
Hello
Larry
[perl #125923] [BUG] .classify-list doesn't work with BagHash in Rakudo
Fixed in https://github.com/rakudo/rakudo/commit/8f2279b155
Tests added in https://github.com/perl6/roast/commit/816b913d98
On Thu Aug 27 04:25:26 2015, masak wrote:
> m: my %b := BagHash.new(); %b.classify-list( {.comb}, 20..40
> ); say %b.perl
> rakudo-moar a46b09: OUTPUT«postcircumfix:<{ }> not defined
> for type Int [...]
> masak: ^^
> * masak submits rakudobug
> m: my %b; %b.classify-list( {.comb}, 20..40 ); say %b.perl
> rakudo-moar a46b09: OUTPUT«{"2" => {"0" => [20], "1" =>
> [21], "2" => [22], "3" => [23], "4" => [24], "5" => [25], "6" => [26],
> "7" => [27], "8" => [28], "9" => [29]}, "3" => {"0" => [30], "1" =>
> [31], "2" => [32], "3" => [33], "4" => [34], "5" => [35], "6" => [36],
> "7" => [37], "8" …»
> m: my %b := BagHash.new(); say %b{'foo'}
> rakudo-moar a46b09: OUTPUT«0»
>
> Notice how postcircumfix:<{ }> is defined on BagHash, as seen in that
> last eval. But something must go wrong inside .classify-list such that
> .{} gets called on an Int instead of on the BagHash itself.
[perl #129291] [BUG] [SEGV] problems when run()ning two procs and passing the :out of one to the :in of the other
On Wed Sep 21 19:37:06 2016, ddgr...@gmail.com wrote: > Test added in https://github.com/perl6/roast/commit/6cc1a85cf4 This ticket still needs tests for Windows.
Re: [perl #129346] [BUG] Whatever being called on where-blocked subroutine cannot handle the sigilless values correctly
On Sat, Sep 24, 2016 at 07:37:52AM +, Lloyd Fournier wrote: > I think this is because .WHAT is a special case. It's not really a method > which is what you need to make *.method work. *.WHAT will always return > (Whatever) immediately. You're correct that .WHAT is a special case. From S12, "Introspection": These should all be considered built-in language primitives, not true operators or methods, even if a given implementation happens to implement one or more of them that way. I suppose it's possible that *.WHAT should generate a WhateverCode object... but I'm a little disinclined to that. A bit later S12 continues: In general, use of these uppercased accessors in ordinary code should be a red flag that Something Very Strange is going on. (Hence the allcaps.) Most code should use Perl 6's operators that make use of this information implicitly. For instance, instead of $obj.WHAT === Dog ... you usually just want: $obj ~~ Dog So I'd say this isn't actually a bug. Pm
Re: [perl #129346] [BUG] Whatever being called on where-blocked subroutine cannot handle the sigilless values correctly
On Sat, Sep 24, 2016 at 07:37:52AM +, Lloyd Fournier wrote: > I think this is because .WHAT is a special case. It's not really a method > which is what you need to make *.method work. *.WHAT will always return > (Whatever) immediately. You're correct that .WHAT is a special case. From S12, "Introspection": These should all be considered built-in language primitives, not true operators or methods, even if a given implementation happens to implement one or more of them that way. I suppose it's possible that *.WHAT should generate a WhateverCode object... but I'm a little disinclined to that. A bit later S12 continues: In general, use of these uppercased accessors in ordinary code should be a red flag that Something Very Strange is going on. (Hence the allcaps.) Most code should use Perl 6's operators that make use of this information implicitly. For instance, instead of $obj.WHAT === Dog ... you usually just want: $obj ~~ Dog So I'd say this isn't actually a bug. Pm
Re: [perl #129344] [BUG] "my" variable in a recursive subroutine leaks to callers scope
Reproduced. Looks like you shouldn't nest subs inside recursive functions
atm :S.
More golfed with just $level being used to demonstrate:
sub process-list (@items, $level = 0) {
multi sub process-item ($item) {
('=' x $level) ~ $item;
}
multi sub process-item (@array) {
process-list(@array, $level + 1)
}
join "\n", map , @items;
}
my @a = 'a', 'b';
put process-list([ 9, @a, 7, 6, @a, 15, 11 ]);
-
9
=a
=b
=7
=6
==a
==b
==15
==11
^ It is never incremented/re-assigned but $level is still +1 after the call
has finished.
On Sat, Sep 24, 2016 at 8:07 AM Steve Schulze
wrote:
> # New Ticket Created by Steve Schulze
> # Please include the string: [perl #129344]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=129344 >
>
>
> I have a subroutine that may recurse, that contains a "my" counter
> variable. Each recursion gets its own copy of the variable, but it seems
> that when the "inner" recursion returns, the "outer" version of the
> variable gets the contents from the "inner" routine.
>
> See cut down snippet:
>
>
>
> sub process-list (@items, $level = 0) {
>
> my $count = 1; # leaks on recursion?
>
> multi sub process-item ($item, $level) { '' x $level ~
> $count++ ~ ') ' ~ $item }
>
> multi sub process-item (@array, $level) { process-list(@array,
> $level + 1) }
>
> join "\n", map { process-item($_, $level) }, @items;
> }
>
> my @a = 'a', 'b';
> put process-list([ 9, @a, 7, 6, @a, 15, 11 ]);
>
>
>
> Output:
>
> Got
>
> 1) 9
> 1) a
> 2) b
> 3) 7
> 4) 6
> 1) a
> 2) b
> 3) 15
> 4) 11
>
> Expected:
>
> 1) 9
> 1) a
> 2) b
> 2) 7
> 3) 6
> 1) a
> 2) b
> 4) 15
> 5) 11
>
>
>
Re: [perl #129346] [BUG] Whatever being called on where-blocked subroutine cannot handle the sigilless values correctly
I think this is because .WHAT is a special case. It's not really a method
which is what you need to make *.method work. *.WHAT will always return
(Whatever) immediately.
There is an odd what of working around this:
perl6 -e 'sub foo(\a where *. === Int ) { say "Hello"; }; foo(10); #
works
using the sub with postfix syntax you get around the special casing.
I'm not sure if .WHAT special casing is considered a bug. I haven't been
able to find a pre-existing ticket wrt to it.
On Sat, Sep 24, 2016 at 4:42 PM Itsuki Toyota
wrote:
> # New Ticket Created by Itsuki Toyota
> # Please include the string: [perl #129346]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=129346 >
>
>
> See the following results
>
> $ perl6 -e 'sub foo(\a where { *.WHAT === Int } ) { say "Hello"; };
> foo(10);'
> Constraint type check failed for parameter 'a'
> in sub foo at -e line 1
> in block at -e line 1
>
> $ perl6 -e 'sub foo(\a where -> \e { \e.WHAT === Int } ) { say "Hello"; };
> foo(10);'
> Constraint type check failed for parameter 'a'
> in sub foo at -e line 1
> in block at -e line 1
>
> $ perl6 -e 'sub foo(\a where -> \e { e.WHAT === Int } ) { say "Hello"; };
> foo(10);'
> Hello
>
> It seems that "Whatever *" cannot handle sigilless values correctly.
> I think that the 1st example should return the same result as the 3rd
> example.
>
>
>
> $ perl6 --version
> This is Rakudo version 2016.08.1-202-g78393dd built on MoarVM version
> 2016.08-47-g2eedba8
> implementing Perl 6.c.
>
Re: [perl #129346] [BUG] Whatever being called on where-blocked subroutine cannot handle the sigilless values correctly
I think this is because .WHAT is a special case. It's not really a method
which is what you need to make *.method work. *.WHAT will always return
(Whatever) immediately.
There is an odd what of working around this:
perl6 -e 'sub foo(\a where *. === Int ) { say "Hello"; }; foo(10); #
works
using the sub with postfix syntax you get around the special casing.
I'm not sure if .WHAT special casing is considered a bug. I haven't been
able to find a pre-existing ticket wrt to it.
On Sat, Sep 24, 2016 at 4:42 PM Itsuki Toyota
wrote:
> # New Ticket Created by Itsuki Toyota
> # Please include the string: [perl #129346]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=129346 >
>
>
> See the following results
>
> $ perl6 -e 'sub foo(\a where { *.WHAT === Int } ) { say "Hello"; };
> foo(10);'
> Constraint type check failed for parameter 'a'
> in sub foo at -e line 1
> in block at -e line 1
>
> $ perl6 -e 'sub foo(\a where -> \e { \e.WHAT === Int } ) { say "Hello"; };
> foo(10);'
> Constraint type check failed for parameter 'a'
> in sub foo at -e line 1
> in block at -e line 1
>
> $ perl6 -e 'sub foo(\a where -> \e { e.WHAT === Int } ) { say "Hello"; };
> foo(10);'
> Hello
>
> It seems that "Whatever *" cannot handle sigilless values correctly.
> I think that the 1st example should return the same result as the 3rd
> example.
>
>
>
> $ perl6 --version
> This is Rakudo version 2016.08.1-202-g78393dd built on MoarVM version
> 2016.08-47-g2eedba8
> implementing Perl 6.c.
>
[perl #129346] [BUG] Whatever being called on where-blocked subroutine cannot handle the sigilless values correctly
# New Ticket Created by Itsuki Toyota
# Please include the string: [perl #129346]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=129346 >
See the following results
$ perl6 -e 'sub foo(\a where { *.WHAT === Int } ) { say "Hello"; }; foo(10);'
Constraint type check failed for parameter 'a'
in sub foo at -e line 1
in block at -e line 1
$ perl6 -e 'sub foo(\a where -> \e { \e.WHAT === Int } ) { say "Hello"; };
foo(10);'
Constraint type check failed for parameter 'a'
in sub foo at -e line 1
in block at -e line 1
$ perl6 -e 'sub foo(\a where -> \e { e.WHAT === Int } ) { say "Hello"; };
foo(10);'
Hello
It seems that "Whatever *" cannot handle sigilless values correctly.
I think that the 1st example should return the same result as the 3rd example.
$ perl6 --version
This is Rakudo version 2016.08.1-202-g78393dd built on MoarVM version
2016.08-47-g2eedba8
implementing Perl 6.c.
