Re: [perl #129346] [BUG] Whatever being called on where-blocked subroutine cannot handle the sigilless values correctly

2016-09-24 Thread Larry Wall via RT
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

2016-09-24 Thread Jan-Olof Hendig
Here's what I found in S32:

deepmap

 multi method deepmap ( @values: Code *&expression --> 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

2016-09-24 Thread Larry Wall
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

2016-09-24 Thread Zoffix Znet via RT
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 #129349] [BUG] Autovification with Junctioned key spills guts

2016-09-24 Thread via RT
# New Ticket Created by  Zoffix Znet 
# Please include the string:  [perl #129349]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=129349 >


 m: my %h; %h{ any ^2 }.push: 42
 rakudo-moar e4e823: OUTPUT«Cannot assign to a readonly variable or a 
value␤  in any  at gen/moar/m-Metamodel.nqp line 3173␤  in block  at 
 line 1␤␤»


[perl #129291] [BUG] [SEGV] problems when run()ning two procs and passing the :out of one to the :in of the other

2016-09-24 Thread Zoffix Znet via RT
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

2016-09-24 Thread Patrick R. Michaud via RT
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

2016-09-24 Thread Patrick R. Michaud
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

2016-09-24 Thread Lloyd Fournier
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 &process-item, @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

2016-09-24 Thread Lloyd Fournier via RT
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 *.&WHAT === Int ) { say "Hello"; }; foo(10); #
works

using the &WHAT 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

2016-09-24 Thread Lloyd Fournier
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 *.&WHAT === Int ) { say "Hello"; }; foo(10); #
works

using the &WHAT 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.
>