# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #112666] # in the subject line of all future correspondence about this issue. # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=112666 >
<gfldex> i may have found another bug and you wont like that one :) <gfldex> r: https://gist.github.com/2519081 <p6eval> rakudo 2a962e: OUTPUT«0App::exit calledApp::exit called» <gfldex> r: https://gist.github.com/2519083 <p6eval> rakudo 2a962e: OUTPUT«App::exit called» <gfldex> the only difference of those two gists is in line 33 <gfldex> it should call App::exit twice for both <masak> please golf this, and I'll submit it. <gfldex> masak: that's as short as i can get it https://gist.github.com/2519182 <gfldex> masak: update: https://gist.github.com/2519182 * masak tries to golf it further <jnthn> .oO( and finally putts it in RT ) <masak> generally, if it contains 'use v6;', it's too long :P <gfldex> masak: i got it a little shorter myself <gfldex> https://gist.github.com/2519279 <masak> still very long. <masak> you can't see what's happening when it spans several lines like that. <gfldex> i can put it all on one line if you like :) <masak> and remove all the other cruft. <gfldex> masak: not even that, update: https://gist.github.com/2519279 <gfldex> where the heck does it take the @a from in the wrap({block}) ? <jnthn> I'm not really surprised that doesn't work... <jnthn> The @a would be the one in the static lexpad I guess... <jnthn> Whereas when the mainline actually runs, it gets a fresh @a <gfldex> so it should either work or complain that @a is not declared? <jnthn> But it is declared <jnthn> You're talking about two different @as <jnthn> Because of BEGIN time <jnthn> That trait_mod runs at BEGIN time. <masak> yes, it is BEGIN time. why does that make it two different @a ? <jnthn> sub foo() { my @a }; foo; foo; # how many @a ? <gfldex> if you add @a.elems; right before $r.wrap it works <jnthn> Hm <gfldex> and @a.elems is called at BEGIN indeed <jnthn> Yeah... <jnthn> That may well be a case of "works by accident" <jnthn> You actually vivify the @a then <jnthn> I guess you vivify the one in the static lexpad. <jnthn> And then it gets copied <gfldex> but why does it get copied instead of forming a closure? <jnthn> nom: sub foo() { my @a; BEGIN { @a = 1,2,3 }; say @a; }; foo(); foo(); <p6eval> rakudo 2a962e: OUTPUT«elements() not implemented in class 'Mu' [...] <jnthn> Wow. <masak> here we go. <masak> r: role R { has @.s is rw }; multi trait_mod:<is>($r, :$x!) { $r does R; sub h(|$){ for $r.s { &^m() } }; $r.wrap(&h) }; sub b is x {}; push &b.s, { say "OH HAI" }; b <p6eval> rakudo 2a962e: ( no output ) <masak> r: role R { has @.s is rw }; multi trait_mod:<is>($r, :$x!) { $r does R; $r.s; sub h(|$){ for $r.s { &^m() } }; $r.wrap(&h) }; sub b is x {}; push &b.s, { say "OH HAI" }; b <p6eval> rakudo 6c9661: OUTPUT«OH HAI» <masak> note. <masak> only difference. <masak> '$r.s' * masak submits rakudobug <jnthn> :/ <masak> whatever the cause or underlying subtleties with BEGIN time, that *shouldn't* happen. <jnthn> OK, maybe I should find a way to make this not work at all. <gfldex> but how do you carry state in a trait_mod:<is> then? <masak> jnthn: that sounds like a good start. *masak does another RT ticket of massive bookkeeping <masak> gfldex++ # extending our limits :) <gfldex> or to ask the question from a perl6user viewpoint: how do i do that correctly? <gfldex> it's funny how one can find bugs in a language by actually using that language :) <masak> how else would you find them? <gfldex> well, you have design by committee and then some magic <gfldex> that's at least what managers tend to believe <jnthn> masak: The bug you filed isn't to do with BEGIN time. <jnthn> It's to do with .clone not doing the right kinda thing with arrays. <jnthn> Just worked out what's going on. <masak> ok. <masak> I'm still editing it, so I can still change the subject line. :)
