[perl #131498] [BUG] Code typed argument makes signature matching unresolvable

[Zoffix Znet via RT]

On Sat, 03 Jun 2017 06:24:02 -0700, cookbook_...@yahoo.co.jp wrote:
> See the following codes and results:
> 
> $ perl6 -e 'class A { multi method f(:$vert!, Code : = {;}){}; multi
> method f(:$func!, Code : = {;}){}; }; my $a = A.new;
> $a.f(:func(10));'
> Cannot resolve caller f(A: :func(Int)); none of these signatures
> match:
>     (A $: :$vert!, Code : = { ... }, *%_)
>     (A $: :$func!, Code : = { ... }, *%_)
>   in block  at -e line 1
> 
> 
> $ perl6 -e 'class A { multi method f(:$vert!, : = {;}){}; multi
> method f(:$func!, : = {;}){
> }; }; my $a = A.new; $a.f(:func(10));' # works
> 
> 
> I think the 1st example should work same as the 2nd example.
> 
> 
> $ perl6 --version
> This is Rakudo version 2017.05-315-g160de7e built on MoarVM version
> 2017.05-25-g62bc54e
> implementing Perl 6.c.


Thank you for the report. However, this is not a bug.

The `&` sigil already carries a meaning that the parameter is type-constrained 
to Callable type.

`Code :` means `:$c` parameter expects a Callable[Code] type; a `Callable`, 
parameterized with `Code`.

The same, for example, applies with `Int :@stuff`. The `Int` is a 
parametarization of the Positional role,
and the parameter expects a `Positional[Int]` argument.

Your second version is correct. Just remove `Code`. If you insist on `Code` 
type, then remove the `&` sigil and use the `$` sigil

[perl #131498] [BUG] Code typed argument makes signature matching unresolvable

[Zoffix Znet via RT]

On Sat, 03 Jun 2017 06:24:02 -0700, cookbook_...@yahoo.co.jp wrote:
> See the following codes and results:
> 
> $ perl6 -e 'class A { multi method f(:$vert!, Code : = {;}){}; multi
> method f(:$func!, Code : = {;}){}; }; my $a = A.new;
> $a.f(:func(10));'
> Cannot resolve caller f(A: :func(Int)); none of these signatures
> match:
>     (A $: :$vert!, Code : = { ... }, *%_)
>     (A $: :$func!, Code : = { ... }, *%_)
>   in block  at -e line 1
> 
> 
> $ perl6 -e 'class A { multi method f(:$vert!, : = {;}){}; multi
> method f(:$func!, : = {;}){
> }; }; my $a = A.new; $a.f(:func(10));' # works
> 
> 
> I think the 1st example should work same as the 2nd example.
> 
> 
> $ perl6 --version
> This is Rakudo version 2017.05-315-g160de7e built on MoarVM version
> 2017.05-25-g62bc54e
> implementing Perl 6.c.


Thank you for the report. However, this is not a bug.

The `&` sigil already carries a meaning that the parameter is type-constrained 
to Callable type.

`Code :` means `:$c` parameter expects a Callable[Code] type; a `Callable`, 
parameterized with `Code`.

The same, for example, applies with `Int :@stuff`. The `Int` is a 
parametarization of the Positional role,
and the parameter expects a `Positional[Int]` argument.

Your second version is correct. Just remove `Code`. If you insist on `Code` 
type, then remove the `&` sigil and use the `$` sigil

[perl #131493] changed type of variable

[Zoffix Znet via RT]

On Sat, 03 Jun 2017 07:52:09 -0700, mt1...@gmail.com wrote:
> this bug can be closed

OK. Closing.

On Sat, 03 Jun 2017 02:36:12 -0700, alex.jakime...@gmail.com wrote:
> Well,
> 
> say IntStr ~~ Str # True
> 
> In other words, IntStr *is* a Str.
> 
> What I find interesting, however, is this difference:
> 
> sub s (Str() :$str) {say $str.WHAT}; s(:str<1>) # IntStr
> sub s (Str :$str) {say $str.Str.WHAT}; s(:str<1>) # Str
> 
> I would have expected the same output in both cases.

It's a bit involved. I opened a separate @LARRY ticket:
https://rt.perl.org/Ticket/Display.html?id=131505

[perl #131493] changed type of variable

[Zoffix Znet via RT]

On Sat, 03 Jun 2017 07:52:09 -0700, mt1...@gmail.com wrote:
> this bug can be closed

OK. Closing.

On Sat, 03 Jun 2017 02:36:12 -0700, alex.jakime...@gmail.com wrote:
> Well,
> 
> say IntStr ~~ Str # True
> 
> In other words, IntStr *is* a Str.
> 
> What I find interesting, however, is this difference:
> 
> sub s (Str() :$str) {say $str.WHAT}; s(:str<1>) # IntStr
> sub s (Str :$str) {say $str.Str.WHAT}; s(:str<1>) # Str
> 
> I would have expected the same output in both cases.

It's a bit involved. I opened a separate @LARRY ticket:
https://rt.perl.org/Ticket/Display.html?id=131505

[perl #131505] [@LARRY] Special case allomorph coercion everywhere

[via RT]

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


(found in discussion in https://rt.perl.org/Ticket/Display.html?id=131493 )


We have some special casing for coercion of allomorphs in some instances, which
is done so there'd be some way to force one of the two types to fall out of it,
since we have types where to whom object identity matters a bunch:

 m: <1>.Str.^name.say
 rakudo-moar 7344a3: OUTPUT: «Str␤»
 m: <1>.Int.^name.say
 rakudo-moar 3755c0: OUTPUT: «Int␤»

However, allomorphs don't get coerced with parameter coercers and possibly some
other places. There's no special casing here done. The coercer coerces to Str 
type
and IntStr allomorph is already it.

 m: -> Str() $_ { .^name.say }(<1>)
 rakudo-moar 7344a3: OUTPUT: «IntStr␤»
 m: -> Int() $_ { .^name.say }(<1>)
 rakudo-moar 7344a3: OUTPUT: «IntStr␤»


So the question becomes: do we special case allomorphs everywhere?

- If yes, any place we special case them will have a caveat and surprising 
behaviour
where type don't get coerced to exact asked type if it's a subclass of it
- If no, we get surprising special cased behaviour like above, but only in one 
case
- Or we could remove the coercion to one of the two types and have <1>.Str 
return the same
   IntStr; in that case I'm unsure what would be a way to "collapse" an 
allomorph into
   numeric or string parts, since many ops use these methods to coerce stuff.

Re: Is there a linter for Perl 6? (like Perl::Critic or pylint)

[Gabor Szabo]

I think that runs perl6 -c, right?
Then no, I did not mean that.
I mean a tool for static analysis like Perl::Critic in Perl 5 that
would point out potential bugs,
or recommend better practices.

I've added a very naive implementation of checking for "use v6;"
https://github.com/Bailador/Bailador/blob/main/t/00-lint.t

regards
Gabor

On Thu, Jun 1, 2017 at 2:50 PM, Ahmad Zawawi  wrote:
> Hi Gabor,
>
> Like https://atom.io/packages/atom-perl6-editor-tools for instance or
> project-level linting?
>
> Regards,
> Ahmad
>
>
> On Thu, Jun 1, 2017 at 9:02 AM, Gabor Szabo  wrote:
>>
>> e.g. I'd like to check that every pl pm and t file in our project has a
>> "use v6;" at the beginning.
>>
>> regards
>>Gabor
>
>

[perl #131412] [NYI] Label.goto() not yet implemented

[Zoffix Znet via RT]

On Fri, 02 Jun 2017 09:53:58 -0700, kai...@protonmail.com wrote:
> For further providing you with informations about how to reproduce this NYI 
> bug

Thank you for the report. It *is* known that goto is not yet implemented.
That's what the error message is trying to tell you.

> which means that Perl6 has missed a feature from Perl5.

It's more difficult to implement it in Perl 6, because we have proper threads 
and stuff.

I don't think think anyone is currently actively trying to implement it, so it
may take a while before you'll see this feature.

P.S.: you should upgrade your perl6. It's ancient. While you won't see goto in 
latest and
greatest compiler, you'll get a whole ton of bug fixes and performance 
improvements. You
can get the latest version at http://rakudo.org/downloads/star/

[perl #131412] [NYI] Label.goto() not yet implemented

[Zoffix Znet via RT]

On Fri, 02 Jun 2017 09:53:58 -0700, kai...@protonmail.com wrote:
> For further providing you with informations about how to reproduce this NYI 
> bug

Thank you for the report. It *is* known that goto is not yet implemented.
That's what the error message is trying to tell you.

> which means that Perl6 has missed a feature from Perl5.

It's more difficult to implement it in Perl 6, because we have proper threads 
and stuff.

I don't think think anyone is currently actively trying to implement it, so it
may take a while before you'll see this feature.

P.S.: you should upgrade your perl6. It's ancient. While you won't see goto in 
latest and
greatest compiler, you'll get a whole ton of bug fixes and performance 
improvements. You
can get the latest version at http://rakudo.org/downloads/star/

[perl #131503] [BUG] '-'.IO.slurp crashes

[Zoffix Znet via RT]

On Sat, 03 Jun 2017 12:47:03 -0700, rightf...@gmail.com wrote:
> '-'.IO behaves as $*IN in some cases, like expected, but crashes with 
> slurp. '-'.IO.spurt works as expected; writing to $*OUT. It appears also 
> that '-'.IO is not very well tested in roast, and it is not documented 
> in the API documentation of IO::Path either, so maybe those points 
> should be addressed as well.
> 
>   $ perl6 --version
>   This is Rakudo version 2017.04.3 built on MoarVM version
> 2017.04-53-g66c6dda
>   implementing Perl 6.c.
>   $ perl6
>   To exit type 'exit' or '^D'
>   > '-'.IO.slurp
>   P6opaque: no such attribute '$!PIO' in type IO::Handle when trying
> to get a value
> in block  at  line 1


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/90d129de8e7ae627
Test: https://github.com/perl6/roast/commit/60a7a88e479dceb902

[perl #131503] [BUG] '-'.IO.slurp crashes

[Zoffix Znet via RT]

On Sat, 03 Jun 2017 12:47:03 -0700, rightf...@gmail.com wrote:
> '-'.IO behaves as $*IN in some cases, like expected, but crashes with 
> slurp. '-'.IO.spurt works as expected; writing to $*OUT. It appears also 
> that '-'.IO is not very well tested in roast, and it is not documented 
> in the API documentation of IO::Path either, so maybe those points 
> should be addressed as well.
> 
>   $ perl6 --version
>   This is Rakudo version 2017.04.3 built on MoarVM version
> 2017.04-53-g66c6dda
>   implementing Perl 6.c.
>   $ perl6
>   To exit type 'exit' or '^D'
>   > '-'.IO.slurp
>   P6opaque: no such attribute '$!PIO' in type IO::Handle when trying
> to get a value
> in block  at  line 1


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/90d129de8e7ae627
Test: https://github.com/perl6/roast/commit/60a7a88e479dceb902

Re: [perl #131481] [BUG] No perl6-debug

[Brandon Allbery]

I would argue that perl6-debug shouldn't exist; if you are debugging, you
pretty much need to know the specific backend that's involved. Which is
likely why rakudobrew killed the generic one (the directory listing, while
mangled, *did* show perl6-debug-m).

On Sun, Jun 4, 2017 at 2:12 AM, Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Thu, 01 Jun 2017 22:25:55 -0700, rnhainswo...@gmail.com wrote:
> > Here is a copy of my session. No perl6-debug.
> >
> > All the documentation implies I should have the executable. I'm running
> > Ubuntu 16.04
>
> Which documentation, out of curiosity? rakudobrew is mostly for core
> hackers, not end users, so it'd likely be best to remove that documentation.
>
> As for the perl6-debug. It's likely called perl6-debug-m
>
> However, it bitrotted a bit and even if you find it, it won't work ATM.
> Hoping someone will find tuits to fix it before next release.
>



-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: [perl #131481] [BUG] No perl6-debug

[Brandon Allbery via RT]

I would argue that perl6-debug shouldn't exist; if you are debugging, you
pretty much need to know the specific backend that's involved. Which is
likely why rakudobrew killed the generic one (the directory listing, while
mangled, *did* show perl6-debug-m).

On Sun, Jun 4, 2017 at 2:12 AM, Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Thu, 01 Jun 2017 22:25:55 -0700, rnhainswo...@gmail.com wrote:
> > Here is a copy of my session. No perl6-debug.
> >
> > All the documentation implies I should have the executable. I'm running
> > Ubuntu 16.04
>
> Which documentation, out of curiosity? rakudobrew is mostly for core
> hackers, not end users, so it'd likely be best to remove that documentation.
>
> As for the perl6-debug. It's likely called perl6-debug-m
>
> However, it bitrotted a bit and even if you find it, it won't work ATM.
> Hoping someone will find tuits to fix it before next release.
>



-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

[perl #131481] [BUG] No perl6-debug

[Zoffix Znet via RT]

On Thu, 01 Jun 2017 22:25:55 -0700, rnhainswo...@gmail.com wrote:
> Here is a copy of my session. No perl6-debug.
> 
> All the documentation implies I should have the executable. I'm running 
> Ubuntu 16.04

Which documentation, out of curiosity? rakudobrew is mostly for core hackers, 
not end users, so it'd likely be best to remove that documentation.

As for the perl6-debug. It's likely called perl6-debug-m

However, it bitrotted a bit and even if you find it, it won't work ATM. Hoping 
someone will find tuits to fix it before next release.

[perl #131481] [BUG] No perl6-debug

[Zoffix Znet via RT]

On Thu, 01 Jun 2017 22:25:55 -0700, rnhainswo...@gmail.com wrote:
> Here is a copy of my session. No perl6-debug.
> 
> All the documentation implies I should have the executable. I'm running 
> Ubuntu 16.04

Which documentation, out of curiosity? rakudobrew is mostly for core hackers, 
not end users, so it'd likely be best to remove that documentation.

As for the perl6-debug. It's likely called perl6-debug-m

However, it bitrotted a bit and even if you find it, it won't work ATM. Hoping 
someone will find tuits to fix it before next release.

[perl #131481] [BUG] No perl6-debug

[via RT]

# New Ticket Created by  Richard Hainsworth 
# Please include the string:  [perl #131481]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131481 >


Here is a copy of my session. No perl6-debug.

All the documentation implies I should have the executable. I'm running 
Ubuntu 16.04


$ rakudobrew build moar



Rakudo has been built and installed.
Updating shims
Done, moar-nom built

$ perl6-debug
perl6-debug: command not found

$ perl6 -v
This is Rakudo version 2017.05-332-gb667e81 built on MoarVM version 
2017.05-25-g62bc54e
implementing Perl 6.c.

$cd ~/.rakudobrew
$ ls bin
lwp-download.pllwp-get.pl-j  nqp-m  panda-build-m 
panda-fetchpanda-install-j  panda-testperl6-debug-m 
rakudobrew  zef-m
lwp-download.pl-j  lwp-get.pl-m  panda  panda-cpanize 
panda-fetch-j  panda-install-m  panda-test-j  perl6-gdb-m rakudobrew.bat
lwp-download.pl-m  moar  panda-buildpanda-cpanize-j 
panda-fetch-m  panda-j  panda-test-m  perl6-m zef
lwp-get.pl nqp   panda-build-j  panda-cpanize-m 
panda-install  panda-m  perl6 perl6-valgrind-m zef-j

[perl #131412] [NYI] Label.goto() not yet implemented

[Kais Ben Salah via RT]

The attached script below, is meant for a Perl5 goto support, works fine - 
which means that Perl6 has missed a feature from Perl5.
#!/usr/bin/perl

my $i = 0;

itr:
$i++;
print "$i\n";
goto itr if ($i < 10);

print "$i\n"; #shall output 10

[perl #131412] [NYI] Label.goto() not yet implemented

[Kais Ben Salah via RT]

For further providing you with informations about how to reproduce this NYI 
bug, I've attached a perl script, that you can test perl6 with.
#!/usr/bin/perl6

my $i = 0;

itr:
$i++;
goto itr if ($i < 10);

say $i; #shall output 10

[perl #131504] [LTA] . form differs from foo($_) when routine throws control exceptions

[via RT]

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


I assumed the . form was just a nicer way of writing foo($_), however they 
differ in that
the thrown control exception doesn't go far enough in . form and it doesn't 
actually
return from the routine with things like . and .

 m: sub { 'foo'. 42 }().^name.say
 rakudo-moar 64e898: OUTPUT: «foo␤  in sub  at  line 1␤  in 
block  at  line 1␤␤Actually thrown at:␤  in sub  at  line 1␤  
in block  at  line 1␤␤»
 m: sub { fail 'foo'; 42 }().^name.say
 rakudo-moar 64e898: OUTPUT: «Failure␤»

 m: sub { return 'foo'; 42 }().^name.say
 rakudo-moar 64e898: OUTPUT: «Str␤»
 m: sub { 'foo'. 42 }().^name.say
 rakudo-moar 64e898: OUTPUT: «Int␤»

[perl #131503] [BUG] '-'.IO.slurp crashes

[via RT]

# New Ticket Created by  rightfold 
# Please include the string:  [perl #131503]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131503 >


'-'.IO behaves as $*IN in some cases, like expected, but crashes with 
slurp. '-'.IO.spurt works as expected; writing to $*OUT. It appears also 
that '-'.IO is not very well tested in roast, and it is not documented 
in the API documentation of IO::Path either, so maybe those points 
should be addressed as well.

  $ perl6 --version
  This is Rakudo version 2017.04.3 built on MoarVM version
2017.04-53-g66c6dda
  implementing Perl 6.c.
  $ perl6
  To exit type 'exit' or '^D'
  > '-'.IO.slurp
  P6opaque: no such attribute '$!PIO' in type IO::Handle when trying
to get a value
in block  at  line 1

[perl #131502] [BUG] Incorrect useless use warning when WhateverCode is passed as arg to Callable

[Zoffix Znet via RT]

Oops. Long day. I meant WhateverCode is passed, not Junction.

[perl #131502] [BUG] Incorrect useless use warning when WhateverCode is passed as arg to Callable

[Zoffix Znet via RT]

Oops. Long day. I meant WhateverCode is passed, not Junction.

[perl #131502] [BUG] Incorrect useless use warning when Junction is passed as arg to Callable

[via RT]

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



The warning lies; this use isn't useless:

 m: -> +@foo { say @foo.head.(41) }(* == 42)
 rakudo-moar 64e898: OUTPUT: «WARNINGS for :␤Useless use of 
"==" in expression "* == 42" in sink context (line 1)␤False␤»
 m: -> +@foo { say @foo.head.(42) }(* == 42)
 rakudo-moar 64e898: OUTPUT: «WARNINGS for :␤Useless use of 
"==" in expression "* == 42" in sink context (line 1)␤True␤»


Appears to only happen when the Callable is invoked right away; this version is 
fine:

 m: sub foo (+@foo) { say @foo.head.(42) };  foo(* == 42)
 rakudo-moar 64e898: OUTPUT: «True␤»

[perl #131501] [BUG] meta-forms of andthen, notandthen, and orelse leak thunks when Slips given as args

[via RT]

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


There were some fixes[^1] to prevent these ops from leaking thunks, and it 
looks like the routines
that handle meta forms need similar treatment, perhaps adding their own meta 
routines for these ops:


 m: sub { [andthen] |(), 42 }().perl.say
 rakudo-moar 64e898: OUTPUT: «-> ;; $_ is raw { #`(Block|44721392) 
... }␤»
 m: sub { [andthen] 42 }().perl.say
 rakudo-moar 64e898: OUTPUT: «42␤»
 m: sub { [andthen] |() }().perl.say
 rakudo-moar 64e898: OUTPUT: «Bool::True␤»
 m: sub { [notandthen] |(), 42 }().perl.say
 rakudo-moar 64e898: OUTPUT: «-> ;; $_ is raw { #`(Block|44971280) 
... }␤»
 m: sub { [orelsee] |(), 42 }().perl.say
 rakudo-moar 64e898: OUTPUT: «===SORRY!=== Error while compiling 
␤Undeclared routine:␤orelsee used at line 1␤␤»
 m: sub { [orelse] |(), 42 }().perl.say
 rakudo-moar 64e898: OUTPUT: «-> ;; $_ is raw { #`(Block|37405936) 
... }␤»
 m: sub { [\orelse] |(), 42 }().perl.say
 rakudo-moar 64e898: OUTPUT: «(-> ;; $_ is raw { 
#`(Block|51258872) ... },).Seq␤»
 m: sub { [\andthen] |(), 42 }().perl.say
 rakudo-moar 64e898: OUTPUT: «(-> ;; $_ is raw { 
#`(Block|57165304) ... },).Seq␤»
 m: sub { [\notandthen] |(), 42 }().perl.say
 rakudo-moar 64e898: OUTPUT: «(-> ;; $_ is raw { 
#`(Block|35411480) ... },).Seq␤»


[1] 
https://github.com/rakudo/rakudo/commit/3c8822e80d39c6c37d1059517e444e4295f24a30

Re: [perl #131493] changed type of variable

[mt1957 via RT]

After some discussion I've understood that I have to do some homework 
and that this bug can be closed. Thanks Jnhtn and Araraloren for your help

Regards,
Marcel

Re: [perl #131493] changed type of variable

[Marcel Timmerman]

After some discussion I've understood that I have to do some homework 
and that this bug can be closed. Thanks Jnhtn and Araraloren for your help


Regards,
Marcel

[perl #131500] [BUG] Loose ops in argument list cause parse failures in some cases

[via RT]

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


Using loose ops works fine some times:

 m: say (Int andthen 42)
 rakudo-moar 64e898: OUTPUT: «()␤»
 m: say (Int orelse 42)
 rakudo-moar 64e898: OUTPUT: «42␤»
 m: say (42 orelse 42)
 rakudo-moar 64e898: OUTPUT: «42␤»

But not other times; not in particular how `andthen` fails below, yet with 
different arguments above, succeeds.

 m: say(70 notandthen 42)
 rakudo-moar 64e898: OUTPUT: «===SORRY!=== Error while compiling 
␤Unable to parse expression in argument list; couldn't find final ')' ␤at 
:1␤--> say(70⏏ notandthen 42)␤expecting any of:␤infix␤ 
   infix stopper␤»
 m: say(70 andthen 42)
 rakudo-moar 64e898: OUTPUT: «===SORRY!=== Error while compiling 
␤Unable to parse expression in argument list; couldn't find final ')' ␤at 
:1␤--> say(70⏏ andthen 42)␤expecting any of:␤infix␤
infix stopper␤»

[perl #131499] [BUG] Incorrect useless use warning in `andthen`/`notandthen`/`orelse`

[via RT]

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


In none of these cases is the use of variables actually useless:

 m: my ($sensor1, $sensor2, $sensor3); $sensor1 notandthen $sensor2 
notandthen $sensor3 notandthen 'did not find a working sensor!'.say;
 rakudo-moar 64e898: OUTPUT: «WARNINGS for :␤Useless use of 
$sensor3 in sink context (line 1)␤Useless use of $sensor2 in sink context (line 
1)␤did not find a working sensor!␤»

 m: my ($sensor1, $sensor2, $sensor3) := (1, 2, 3); $sensor1 andthen 
$sensor2 andthen $sensor3 andthen 'did not find a working sensor!'.say;
 rakudo-moar 64e898: OUTPUT: «WARNINGS for :␤Useless use of 
$sensor3 in sink context (line 1)␤Useless use of $sensor2 in sink context (line 
1)␤did not find a working sensor!␤»

 m: m: my ($sensor1, $sensor2, $sensor3); $sensor1 orelse $sensor2 
orelse $sensor3 orelse 'did not find a working sensor!'.say;
 rakudo-moar 64e898: OUTPUT: «WARNINGS for :␤Useless use of 
$sensor3 in sink context (line 1)␤Useless use of $sensor2 in sink context (line 
1)␤did not find a working sensor!␤»

[perl #131498] Code typed argument makes signature matching unresolvable

[via RT]

# New Ticket Created by  Itsuki Toyota 
# Please include the string:  [perl #131498]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131498 >


See the following codes and results:

$ perl6 -e 'class A { multi method f(:$vert!, Code : = {;}){}; multi method 
f(:$func!, Code : = {;}){}; }; my $a = A.new; $a.f(:func(10));'
Cannot resolve caller f(A: :func(Int)); none of these signatures match:
    (A $: :$vert!, Code : = { ... }, *%_)
    (A $: :$func!, Code : = { ... }, *%_)
  in block  at -e line 1


$ perl6 -e 'class A { multi method f(:$vert!, : = {;}){}; multi method 
f(:$func!, : = {;}){
}; }; my $a = A.new; $a.f(:func(10));' # works


I think the 1st example should work same as the 2nd example.


$ perl6 --version
This is Rakudo version 2017.05-315-g160de7e built on MoarVM version 
2017.05-25-g62bc54e
implementing Perl 6.c.

[perl #131496] [BUG] Failure.perl doesn't roundrip `handled` flag

[via RT]

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


Handled Failures are explosive again, if they're .perl'ed:

 m: given Failure.new { .so; .handled.say; .perl.EVAL.handled.say 
}
 rakudo-moar 61ecfd: OUTPUT: «True␤False␤»

Perhaps the `handled` flag should be a public attribute, settable via new?

Re: [perl #131493] changed type of variable

[mt1957 via RT]

On 06/03/2017 11:36 AM, Aleks-Daniel Jakimenko-Aleksejev via RT wrote:
> sub s (Str() :$str) {say $str.WHAT}; s(:str<1>) # IntStr
> sub s (Str :$str) {say $str.Str.WHAT}; s(:str<1>) # Str

I think the last one is coerced explicitly. Btw I didn't know about 
'Str() :$str' specification. What does it do?


The previous mail about the type test 'say Str ~~ IntStr' I meant that 
this is the test what the coercion to Str should force isn't it?

Marcel

Re: [perl #131493] changed type of variable

[Marcel Timmerman]

On 06/03/2017 11:36 AM, Aleks-Daniel Jakimenko-Aleksejev via RT wrote:

sub s (Str() :$str) {say $str.WHAT}; s(:str<1>) # IntStr
sub s (Str :$str) {say $str.Str.WHAT}; s(:str<1>) # Str


I think the last one is coerced explicitly. Btw I didn't know about 
'Str() :$str' specification. What does it do?



The previous mail about the type test 'say Str ~~ IntStr' I meant that 
this is the test what the coercion to Str should force isn't it?


Marcel

Re: [perl #131493] changed type of variable

[Marcel Timmerman]

On 06/03/2017 11:36 AM, Aleks-Daniel Jakimenko-Aleksejev via RT wrote:

say IntStr ~~ Str


> say Str ~~ IntStr
False

Re: [perl #131493] changed type of variable

[mt1957 via RT]

On 06/03/2017 11:36 AM, Aleks-Daniel Jakimenko-Aleksejev via RT wrote:
> say IntStr ~~ Str

 > say Str ~~ IntStr
False

[perl #131495] QAST and MAST errors from my code

[via RT]

# New Ticket Created by  Benjamin Goldberg 
# Please include the string:  [perl #131495]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131495 >


The code in this gist: 
https://gist.github.com/BenGoldberg1/19e6e8b70cc5c838a15d72ea1dd182c9/edit
Produces the following error message when run:

===SORRY!===
QAST::Block with cuid 21 has not appeared

Various minor changes produce a different number instead of 21 – sometimes 1 or 
9 occur instead – which
makes me wonder if memory is getting corrupted somewhere.

If this same code is put into a file name Callback.pm, and then you run perl6 
–I. –e “use Callback;” it errors with:

===SORRY!===
Expected MAST::Frame, but didn't get one

[perl #131493] changed type of variable

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Well,

say IntStr ~~ Str # True

In other words, IntStr *is* a Str.

What I find interesting, however, is this difference:

sub s (Str() :$str) {say $str.WHAT}; s(:str<1>) # IntStr
sub s (Str :$str) {say $str.Str.WHAT}; s(:str<1>) # Str

I would have expected the same output in both cases.

On 2017-06-03 02:05:49, mt1...@gmail.com wrote:
> Hi,
>
> In Rakudo version 2017.05-338-gaca1929 built on MoarVM version
> 2017.05-25-g62bc54e
> implementing Perl 6.c I saw that a type could be changed through an
> assignment which It should not do. In REPL;
>
>
> > my Str $s = IntStr.new(12,'12');
> 12
> > $s.WHAT
> (IntStr)
> >
>
> The type IntStr should be coerced into Str. A second example happened in
> my code and golfed in REPL
>
>
>
> > sub s (Str :$str) {say $str.WHAT}
> sub s (Str :$str) { #`(Sub|89412592) ... }
> > s(:str<1>)
> (IntStr)
> > s(:str)
> (Str)
>
>
> The type should stay as it was defined I think.
> Marcel

[perl #131493] changed type of variable

[via RT]

# New Ticket Created by  mt1957 
# Please include the string:  [perl #131493]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131493 >


Hi,

In Rakudo version 2017.05-338-gaca1929 built on MoarVM version 
2017.05-25-g62bc54e
implementing Perl 6.c I saw that a type could be changed through an 
assignment which It should not do. In REPL;


 > my Str $s = IntStr.new(12,'12');
12
 > $s.WHAT
(IntStr)
 >

The type IntStr should be coerced into Str. A second example happened in 
my code and golfed in REPL



 > sub s (Str :$str) {say $str.WHAT}
sub s (Str :$str) { #`(Sub|89412592) ... }
 > s(:str<1>)
(IntStr)
 > s(:str)
(Str)


The type should stay as it was defined I think.
Marcel

[perl #131492] Camelia produces different error message from commandline

[via RT]

# New Ticket Created by  Benjamin Goldberg 
# Please include the string:  [perl #131492]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131492 >


On #perl6 IRC, I typed this:

 m: my \foo = Callable but role :: { };
<+camelia> rakudo-moar ef9872: OUTPUT: «X::Method::NotFound exception produced 
no message␤  in block  at  line 1␤␤»

If, at my command prompt, I type perl6 –e “my \foo = Callable but role :: { };”
I get instead:

No such method 'mixin' for invocant of type 
'Perl6::Metamodel::ParametricRoleGroupHOW'
  in block  at -e line 1


Including, oddly, an extra blank line after the error and before my prompt.