Skip Menu |

This queue is for tickets about the Moose CPAN distribution.

Report information
The Basics
Id: 131548
Status: rejected
Priority: 0/
Queue: Moose

People
Owner: Nobody in particular
Requestors: SHERRARDB [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 2.2012
Fixed in: (no value)



Subject: Moose enum triggers compile-time error when used in Kavorka signature
i'm not really sure that this is a Moose problem per-se, but the error seems to be generated from the inlined code from Moose::Meta::TypeConstraint::Enum. unfortunately, due to the compile-time nature of the problem, i have exhausted my ability to trace it, and i am hoping for some help, or direction. when using a Moose enum TypeConstraint in a Kavorka signature: fun print_color(ColorEnum :$color!) { print "$color\n"; } the code dies with: ~$ perl -I./lib -Mstrict -Mwarnings -mMy::Shapes -e exit Global symbol "%enums0" requires explicit package name at lib/My/Shapes.pm line 10. Compilation failed in require. BEGIN failed--compilation aborted. when switching the Kavorka Signature to use a Str subtype: fun print_color(ColorStr :$color!) { print "$color\n"; } the code loads and runs fine, and behaves as expected. ~$ perl -I./lib -Mstrict -Mwarnings -e 'use My::Shapes qw(); my $color = "black"; My::Shapes::print_color( color=> $color ); my $obj = My::Shapes->new( color=> $color ); print $obj->color()."\n"; ' black black ~/$ perl -I./lib -Mstrict -Mwarnings -e 'use My::Shapes qw(); my $color = "pink"; My::Shapes::print_color( color=> $color ); my $obj = My::Shapes->new( color=> $color ); print $obj->color()."\n"; ' Value "pink" did not pass type constraint "ColorStr" at lib/My/Shapes.pm line 10 Value "pink" did not pass type constraint "ColorStr" "ColorStr" is defined as: sub { package My::Shapes::TypeConstraints; /^(?:white|black|brown)$/; } the error produced seems to be related to the dynamic variable names used in the code generated for the validation routines. and i'm guessing that it is triggered by a scoping issue during some kind of dynamic loading of related modules during Kavorka parsing/initialization. but all of this is a semi-educated guess, based on poking around and inserting some debugging code. TIA
Subject: TypeConstraints.pm
package My::Shapes::TypeConstraints; use strict; use Kavorka qw(); use Moose::Util::TypeConstraints qw/ subtype as where enum /; enum 'ColorEnum' => [qw/ white black brown /]; subtype 'ColorStr', as 'Str', where { /^(?:white|black|brown)$/ }; 1;
not sure why the second attachment did not make it
Subject: Shapes.pm
package My::Shapes; use strict; use Kavorka qw( fun ); use My::Shapes::TypeConstraints qw(); use Moose qw( has ); has "color" => ( is=> "ro", isa=> "ColorEnum", required=> 1 ); fun print_color(ColorStr :$color!) { print "$color\n"; } __PACKAGE__->meta->make_immutable; 1;
On 2020-01-23 15:03:44, SHERRARDB wrote: Show quoted text
> ~$ perl -I./lib -Mstrict -Mwarnings -mMy::Shapes -e exit > Global symbol "%enums0" requires explicit package name at > lib/My/Shapes.pm line 10. > Compilation failed in require. > BEGIN failed--compilation aborted.
I'm nearly 100% sure this is a bug in Kavorka. Inlined type constraints from Moose may optionally provide a set of variable names & values that must be evaluated in the same scope as the code being evaluated. Failing to include those variables results in these sorts of error messages. I would report this bug to Kavorka.
Subject: Re: [rt.cpan.org #131548] Moose enum triggers compile-time error when used in Kavorka signature
Date: Thu, 23 Jan 2020 18:48:45 -0500
To: bug-Moose [...] rt.cpan.org
From: sherrardb <sherrardb [...] cpan.org>
Dave, i figured as much. i was hoping that one of the Moose pros could point me in the direction of the Moose-related bits of the problem so that i could nail down the Kavorka-related bits more firmly, and possibly whip up a PR (or a work-around). for example, can you point me to the place where all of these similarly-scoped variables "come together"? i can see that the snippet stored here my $inliner = sub { my $self = shift; my $val = shift; return 'defined(' . $val . ') ' . '&& !ref(' . $val . ') ' . '&& $' . $self->_inline_var_name . '{' . $val . '}'; }; ... $args{inlined} = $inliner; and here $args{inline_environment} = { '%' . $var_name => \%values }; are germane, but i have not been able to find the point where all of these things must converge. thanks again. On 1/23/20 4:41 PM, Dave Rolsky via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=131548 > > > On 2020-01-23 15:03:44, SHERRARDB wrote: >
>> ~$ perl -I./lib -Mstrict -Mwarnings -mMy::Shapes -e exit >> Global symbol "%enums0" requires explicit package name at >> lib/My/Shapes.pm line 10. >> Compilation failed in require. >> BEGIN failed--compilation aborted.
> > I'm nearly 100% sure this is a bug in Kavorka. Inlined type constraints from Moose may optionally provide a set of variable names & values that must be evaluated in the same scope as the code being evaluated. > > Failing to include those variables results in these sorts of error messages. I would report this bug to Kavorka. >
On 2020-01-23 17:55:48, SHERRARDB wrote: Show quoted text
> Dave, > i figured as much. i was hoping that one of the Moose pros could > point > me in the direction of the Moose-related bits of the problem so that > i > could nail down the Kavorka-related bits more firmly, and possibly > whip > up a PR (or a work-around). > > for example, can you point me to the place where all of these > similarly-scoped variables "come together"? i can see that the snippet > stored here > > my $inliner = sub { > my $self = shift; > my $val = shift; > > return 'defined(' . $val . ') ' > . '&& !ref(' . $val . ') ' > . '&& $' . $self->_inline_var_name . '{' . $val . '}'; > }; > ... > $args{inlined} = $inliner; > > and here > > $args{inline_environment} = { '%' . $var_name => \%values }; > > are germane, but i have not been able to find the point where all of > these things must converge. > > thanks again.
I'm not entirely clear what you're asking. Are you asking how this is used? See Moose::Meta::Attribute->_inline_check_constraint and ->_eval_environment in the same package for some examples.
Subject: Re: [rt.cpan.org #131548] Moose enum triggers compile-time error when used in Kavorka signature
Date: Fri, 24 Jan 2020 12:56:22 -0500
To: bug-Moose [...] rt.cpan.org
From: sherrardb <sherrardb [...] cpan.org>
On 1/24/20 12:01 PM, Dave Rolsky via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=131548 > > > On 2020-01-23 17:55:48, SHERRARDB wrote:
>> Dave, >> i figured as much. i was hoping that one of the Moose pros could >> point >> me in the direction of the Moose-related bits of the problem so that >> i >> could nail down the Kavorka-related bits more firmly, and possibly >> whip >> up a PR (or a work-around). >> >> for example, can you point me to the place where all of these >> similarly-scoped variables "come together"? i can see that the snippet >> stored here >> >> my $inliner = sub { >> my $self = shift; >> my $val = shift; >> >> return 'defined(' . $val . ') ' >> . '&& !ref(' . $val . ') ' >> . '&& $' . $self->_inline_var_name . '{' . $val . '}'; >> }; >> ... >> $args{inlined} = $inliner; >> >> and here >> >> $args{inline_environment} = { '%' . $var_name => \%values }; >> >> are germane, but i have not been able to find the point where all of >> these things must converge. >> >> thanks again.
> > I'm not entirely clear what you're asking. Are you asking how this is used? > > See Moose::Meta::Attribute->_inline_check_constraint and ->_eval_environment in the same package for some examples.
essentially. after groping around some more, and guided by a bug fix on Params::ValidationCompiler https://github.com/houseabsolute/Params-ValidationCompiler/issues/22 https://github.com/houseabsolute/Params-ValidationCompiler/commit/36a755cf35920b2f8826f441b615c3ab4d22c8c4 :-) i was able to get closer to where the problem is. i still haven't quite pinned down where the environment should be drawn in, but i'm hoping to find it shortly. thanks
likely bug in Kavorka and/or Type::Tiny
On 2020-01-24 09:56:41, SHERRARDB wrote: Show quoted text
> i was able to get closer to where the problem is. i still haven't > quite > pinned down where the environment should be drawn in, but i'm hoping > to > find it shortly. > > thanks
https://github.com/houseabsolute/Params-ValidationCompiler/commit/36a755cf35920b2f8826f441b615c3ab4d22c8c4