# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #112664] # in the subject line of all future correspondence about this issue. # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=112664 >
<gfldex> r: https://gist.github.com/2518066 <p6eval> rakudo a25e7d: OUTPUT«Null PMC access in find_method('slots') [...] <jnthn> Eek. That looks bad. * gfldex tries to find the line that triggers Null PMC <gfldex> i don't think i can golf it much * masak tries, then <moritz> the weird thing is, it explodes while invoking method pressed <gfldex> yes and it calls the wrong handle_call <moritz> but nothing seems to override its invoke/postcircumfix:<( )> <jnthn> That &wrap call means you are wrapping with the proto. <jnthn> And that trait_mod along with the multi, proto etc. has to be compiled "just in time" since the trait_mod runs at BEGIN time. <moritz> oh, erm, does .wrap on a method work at all? <jnthn> Yes, .wrap is defined on Routine. <gfldex> my guess is that the dispatcher is calling the wrong handle_call with a capture that is empty but not <jnthn> But a $m should be in scope and not null in either case. <gfldex> well, $m seamt to be null <jnthn> Yeah, it shouldn't be. <gfldex> i added say $m.elems; and it explodes <jnthn> I suspect it's some kind of lexical chaining issue. <jnthn> OK, it's the multi that is somehow to blame <masak> yeah, that feels like a lexpad outer chain corruption. <jnthn> https://gist.github.com/2518209 gets much further <jnthn> masak: Yeah, something along those lines. * masak submits rakudobug <jnthn> Now we know what it is, it's probably very golfable. <moritz> adding a proto also gets much further <jnthn> moritz: oh... <jnthn> moritz++ <jnthn> https://gist.github.com/2518235 <jnthn> gfldex: ^^ <gfldex> that makes sense <gfldex> but the compiler should be a bit more concerned without the proto :) <gfldex> but it still doesnt work how i would like it to <masak> r: role R { has $.x }; multi trait_mod:<is>($m, :$a!) { $m does R; multi y(|$) { say $m }; $m.wrap(&y) }; (class { method z is a {} }).z; <p6eval> rakudo a25e7d: OUTPUT«Null PMC access in find_method('gist') [...] <masak> golf'd. :) <jnthn> r: multi trait_mod:<is>($m, :$a!) { proto y(|$) { * }; multi y(|$) { say $m }; $m.wrap(&y) }; (class { method z is a {} }).z; <p6eval> rakudo a25e7d: OUTPUT«z» <jnthn> So it's everything to do with the auto-generated proto. <masak> r: multi trait_mod:<is>($m, :$a!) { multi y(|$) { say $m }; $m.wrap(&y) }; sub foo is a {}; foo <p6eval> rakudo a25e7d: OUTPUT«Null PMC access in find_method('gist') [...] <masak> yes. it's the auto-gen proto's the culprit. * masak concentrates this down into a simple bug report <jnthn> Derived dispatchers too if the patch I'm trying at the moment works. <jnthn> Yeah, I think I have a patch locally.
