<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 03 Jun 2016, at 12:30, Clément Bera <<a href="mailto:bera.clement@gmail.com" class="">bera.clement@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">The way I understand it the closure is shared between the original and the copied stack. If you change the closure outerContext to match the copied context, then non local returns / debugging won't work any more on the original stack.</div></div></div></blockquote><div><br class=""></div><div>That’s true, I didn’t think of that.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">As you mentioned, updating all the closures referencing the context as their outer context is non trivial. I believe you can do it lazily (at least that's my conclusion from the sista experience where I need to do that if the outer context is deoptimized). The only cases where the outerContext is used are non local returns and debugging. If a non local return fails, it calls the #cannotReturn: call-back. You can change the code there to do the right think if the outer context is not correct (like setting the correct outer context and retrying the non local return). You can also change the BlockClosure code to check at each outerContext in-image read if the outerContext is valid or not. I think that's much better than updating ahead of time all the closure instances.</div></div></div></blockquote><div><br class=""></div><div>I think I’ll have to do something like this, yes.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Alternatively, if you feel like it, you could try something like 'context becomeForward: copyOfContext’.</div></div></div></blockquote><div><br class=""></div><div>No, I don’t want to risk anything. Although it probably wouldn’t hurt in most cases.</div><div><br class=""></div><div>Thanks Clément.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jun 3, 2016 at 11:02 AM, Max Leske <span dir="ltr" class=""><<a href="mailto:maxleske@gmail.com" target="_blank" class="">maxleske@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
I see at least one problem: at the point where we make a copy of a context, the closures that reference it are either in callees or not on the stack at all. Therefore we would need to take note of all the closures we meet on the way and update the outer contexts only if we find them on the stack. That makes copying a whole lot harder.<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
Max<br class="">
</font></span><div class="HOEnZb"><div class="h5"><br class="">
> Hi,<br class="">
><br class="">
> Is anybody aware of a reason for why Context>>copyTo: should not update the home of closures (which is currently the case)? This behaviour becomes a problem when I want to simulate #stepThrough: on a copied stack, since the home of a closure will never be found on the stack.<br class="">
><br class="">
> My proposal is to implement<br class="">
><br class="">
> Context>>postCopy<br class="">
> closureOrNil ifNil: [ ^ self ].<br class="">
><br class="">
> closureOrNil outerContext: self<br class="">
><br class="">
> and<br class="">
><br class="">
> BlockClosure>>outerContext: aContext<br class="">
> outerContext := aContext<br class="">
><br class="">
><br class="">
> Thoughts?<br class="">
><br class="">
> Cheers,<br class="">
> Max<br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>