<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p>Hi Eliot,</p>
<p><br>
</p>
<p>you're genius, thanks a lot for your answer! :-)</p>
<p><br>
</p>
<p>First, for convenience only, here is a snippet to reproduce the bug even simpler:</p>
<p><br>
</p>
<p></p>
</div>
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div>| ctxt |</div>
</div>
</div>
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div>ctxt := thisContext.</div>
</div>
</div>
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div>[thisContext swapSender: ctxt] value "step OVER this line to reproduce"</div>
</div>
</div>
</blockquote>
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div></div>
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<br>
</div>
I played a lot around with this issue during the last days, and I could not develop a perfect solution so far. But here are some considerations:</div>
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<br>
</div>
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
First, what exact behavior do we expect when stepping over some code that includes a sender swap, speaking in general? The current implementation wants to keep the process running until we return from the selected message - which is the desired behavior in
most cases. Just in this special case, our problem is that the selected message will never return.</div>
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
If I understand your goal definition correctly, the debugger would halt each time a sender swap occurs while the over button is pressed? I fear this could be inconvenient if you step over any method from a higher abstraction level that uses a generator in any deep
implementation details. So I would like to refine the goal rather as "when pressing over, the process should be resumed until the suspended context is in the stack of the original context (i. e. where the over button was pressed)". For illustration, neglecting
the whole optimization, Process >> #complete: should basically equal the pseudocode "self runUntil: [:ctxt | aContext = ctxt or: [aContext hasSender: ctxt]]". Would you agree so far?</div>
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<br>
</div>
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
Second, my approach was to modify #swapSender: to manually identify and transport these "essential" sender contexts. The
<b>attached </b><b>changeset</b> is really WIP, so it only works for the simplest examples, but it might give you an impression of my approach. It does not yet work properly for the following code, if you step over #contents, for example:</div>
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<br>
</div>
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div>(Generator on: [:stream |</div>
</div>
</div>
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div><span style="white-space:pre"></span>stream nextPut: #foo; nextPut: #bar]) contents.</div>
</div>
</div>
</blockquote>
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div><br>
</div>
<div>If you like the idea, I will try to fix that later.</div>
<div>I know that this approach is in O(n) whereas the current implementation has a constant complexity only, but to me, this appears inherent and inevitable complexity.</div>
<div><br>
</div>
<div>However, we would need this modification only for debugging. This leads me to my next concern:</div>
<div><span style="font-size: 12pt;">From an architectural point of view, I would like to put this modification into a decorator class (DebuggedContext) that is only installed
</span><span style="font-size: 12pt;">from</span><span style="font-size: 12pt;"> #runUntilErrorOrReturnFrom:</span><span style="font-size: 12pt;">.</span></div>
<div><span style="font-size: 12pt;">B</span><span style="font-size: 12pt;">ut it appears the VM does not like this, you cannot even do:</span><br>
</div>
<div><br>
</div>
</div>
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div><span>thisContext privSender: (thisContext sender changeClassTo: thisContext sender class newSubclass)</span></div>
</div>
</div>
</blockquote>
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div><span><br>
</span></div>
<div><span><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">(computation has been terminated), </span>unless you are
debugging. I'd guess that primitive 160 always allocates new memory for the receiver, which would be invisible for the image, but visible to the VM. But I don't have any clue of the actual implementation! Any chance to get around this limitation?</span></div>
<div><span><br>
</span></div>
<div><span>In general, how would you think about this approach? Do you have any better ideas? Looking forward to your opinion :-)</span></div>
<div><span><br>
</span></div>
<div><span>Best,</span></div>
<div><span>Christoph</span></div>
</div>
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p></p>
<p><br>
</p>
<div id="Signature">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="_rp_T4" id="Item.MessagePartBody">
<div class="_rp_U4 ms-font-weight-regular ms-font-color-neutralDark rpHighlightAllClass rpHighlightBodyClass" id="Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont"></font></div>
</div>
</font></div>
</div>
</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Eliot Miranda <eliot.miranda@gmail.com><br>
<b>Gesendet:</b> Dienstag, 24. Dezember 2019 03:57:12<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] BUG/REGRESSION while debugging Generator >> #nextPut:</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Hi Christophe,</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Dec 13, 2019 at 10:48 AM Thiede, Christoph <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de">Christoph.Thiede@student.hpi.uni-potsdam.de</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div id="gmail-m_-893075213057209812divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p>Hi all,</p>
<p><br>
</p>
<p>I discovered a bug when stepping over a call to Generator >> #nextPut:.</p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Apologies. I can now reproduce the bug. I was stupidly stepping over the block evaluation, not the send of nextPut:.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div id="gmail-m_-893075213057209812divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p>!! Save your image before trying the following !!</p>
<p><br>
</p>
<p></p>
<div>Generator</div>
<div><span style="white-space:pre-wrap"></span>on: [:stream | stream <span style="background-color:rgb(190,190,190)">
nextPut: #foo</span>]</div>
<br>
<p></p>
<p><img naturalheight="304" naturalwidth="654" size="43800" id="gmail-m_-893075213057209812img765834" style="max-width: 99.9%; user-select: none;" src="cid:16f35ae515df456b1e51"><br>
</p>
<p><br>
</p>
<p></p>
<ol style="margin-bottom:0px; margin-top:0px">
<li>Due to multiprocessing implementation of the Generator, pressing over will hang up the current process forever, because the generator is never queried.</li><li>If I press cmd-dot, I get an infinite number of debugger windows that show Context >> #<span>cannotReturn:. This will probably damage your image.</span></li></ol>
<div><br>
</div>
<div>The first is annoying for newcomers, but I see this behavior is reasonable and without the effect of the second, it wouldn't be a big problem.</div>
<div>The second, however, looks like a bigger issue to me. Actually, I think the most serious aspect is that in Squeak 5.1, the same procedure does not crash your image, but you are forwarded to the emergency debugger and can terminate the process:</div>
<div><br>
</div>
<div><img naturalheight="703" naturalwidth="1029" size="185254" id="gmail-m_-893075213057209812img183784" height="180" width="263" style="user-select: none;" src="cid:16f35ae515df456b1e52"> <img naturalheight="701" naturalwidth="1028" size="171961" id="gmail-m_-893075213057209812img805985" height="180" width="263" style="user-select: none;" src="cid:16f35ae515df456b1e53"><br>
</div>
<div><br>
</div>
<div>Also, this is not the first scenario <span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">
in the last time </span>where I got an infinite debugger chain. See <span><a href="http://forum.world.st/BUG-s-in-Context-control-jump-runUntilErrorOrReturnFrom-td5107263.html" target="_blank">[BUG(s)] in Context control (#jump, #runUntilErrorOrReturnFrom:)</a> for
a similar issue. And there were even more situations which I could not yet reproduce exactly.</span></div>
<div><span>I'm afraid that the recent changes to the debuggers might have weakened its ability to detect recursive errors. Can someone else tell about these problems?</span></div>
<div><span><br>
</span></div>
<div><span>I suppose we ignore a large number of recursive errors as in MorphicDebugger >> #<span>openOn:context:label:contents:fullView:, the uiBlock is often triggered as a separate UI message which will be executed after the recursion flag has been cleared
by the base class.</span></span></div>
<div><span><span><br>
</span></span></div>
<div><span><span>Would be great if someone could have a look at it or share more information :)</span></span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>So the issue seems to me to be the interaction between the block established in runUntilErrorOrReturnFrom: to catch unhandled errors (this one:</div>
<div>
<div>Context contextOn: UnhandledError do: [:ex |</div>
<div><span class="gmail-Apple-tab-span" style="white-space:pre"></span>error ifNil: [</div>
<div><span class="gmail-Apple-tab-span" style="white-space:pre"></span>error := ex exception.</div>
<div><span class="gmail-Apple-tab-span" style="white-space:pre"></span>topContext := thisContext.</div>
<div><span class="gmail-Apple-tab-span" style="white-space:pre"></span>ex resumeUnchecked: here jump]</div>
<div><span class="gmail-Apple-tab-span" style="white-space:pre"></span>ifNotNil: [ex pass]</div>
<div><span class="gmail-Apple-tab-span" style="white-space:pre"></span>]</div>
</div>
<div>)</div>
<div>and the swapSender: in Generator>>nextPut:. So after the swapSender: the Generator's continue variable refers to this BlockClosure>>on:do:. BlockClosure>>ensure: pair introduced by runUntilErrorOrReturnFrom:. What I don't understand was how the evaluateOnBehalfOf:
changes interact with that. But what I can say is that the Debugger is leaving the Generator (or any code that uses swapSender:) in an invalid state because </div>
<div>a) once the swapSender: occurs the protect blocks (the on:do:,ensure: pair) are no longer on the stack. What the swapSender should have been morphed into doing was preserving the protect blocks under the current context, or rather that swapSender should
have been persuaded to swap the senders of the protect blocks. Now when the debugger continues stepping it never gets to the protect blocks because they have been swapped out of the way, and execution proceeds all the way down to the fork in Generator>>reset.</div>
<div><br>
</div>
<div>You can observe this by</div>
<div>- stepping through "Generator on: [:stream | stream nextPut: #foo]" until at the send of #nextPut:</div>
<div>- inspecting the Debugger (via the Morphic tool handle menu "inspect model"</div>
<div>- debugging "self doStep" to step the Debugger through the send</div>
<div>- when you get to runUntilErrorOrReturnFrom: *ONLY STEP UP TO THE jump* *DO NOT STEP OVER THE jump*</div>
<div>- at the jump, step into, then do step into, and you'll find the debugger now in Generator>>nextPut:, with the stack still including the protect pair. But when you step over the swapSender: then, of course, they've gone missing, and the stack points back
to the fork in reset with nothing on the stack to stop execution (because there's no ensure: block which is what runUntilErrorOrReturnFrom: inserted to try and catch any attempt to return).</div>
<div><br>
</div>
<div>So to get to the point of the swapSender: you should see this:</div>
<div><br>
</div>
<div>
<div>Context>>jump</div>
<div>Context>>runUntilErrorOrReturnFrom:</div>
<div>[] in Process>>complete:</div>
<div>BlockClosure>>ensure:</div>
<div>Process>>evaluate:onBehalfOf:</div>
<div>Process>>complete:</div>
<div>Process>>completeStep:</div>
<div>[] in MorphicDebugger(Debugger)>>doStep</div>
<div>BlockClosure>>on:do:</div>
<div>MorphicDebugger(Debugger)>>handleLabelUpdatesIn:whenExecuting:</div>
<div>MorphicDebugger(Debugger)>>doStep</div>
</div>
<div><br>
</div>
<div>and the stack from the Context about to jump is</div>
<div><br>
</div>
<div>Generator>>nextPut:</div>
<div>BlockClosure>>on:do:</div>
<div>BlockClosure>>ensure:</div>
<div>[] in UndefinedObject>>DoIt</div>
<div>Generator>>fork</div>
<div>[] in Generator>>reset</div>
<div>Generator>>reset</div>
<div>Generator>>initializeOn:</div>
<div>Generator class>>on:</div>
<div>UndefinedObject>>DoIt ...<br>
</div>
<div><br>
</div>
<div>and the Generator's "continue" stack immediately before the swapSender: in Generator>>nextPut: is</div>
<div><br>
</div>
<div>Generator>>reset</div>
<div>Generator>>initializeOn:</div>
<div>Generator class>>on:</div>
<div>UndefinedObject>>DoIt<br>
</div>
<div><br>
</div>
<div>What we'd like to see after the swapSender: is the protect blocks moved to the continue stack:</div>
<div>Generator>>nextPut:</div>
<div>BlockClosure>>on:do:</div>
<div>BlockClosure>>ensure:<br>
</div>
<div>Generator>>reset</div>
<div>Generator>>initializeOn:</div>
<div>Generator class>>on:</div>
<div>UndefinedObject>>DoIt<br>
</div>
<div><br>
</div>
<div>and the new "continue" stack looking like this:</div>
<div>
<div>Generator>>fork</div>
<div>[] in Generator>>reset</div>
<div>Generator>>reset</div>
<div>Generator>>initializeOn:</div>
<div>Generator class>>on:</div>
<div>UndefinedObject>>DoIt ...</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div>What I don't know is how to fix this in the general case. This seems hard. The debugger is executing Smalltalk (i.e. *not* stepping bytecodes) in the context of runUntilErrorOrReturnFrom: and a swapSender: could happen at an arbitrarily deep point in
that execution and we want the protect blocks in runUntilErrorOrReturnFrom: to protect execution after a swapSender:. I have no idea how to do that.</div>
<div><br>
Now what's more likely is that I'm not seeing what's obviously wrong about the introduction of evaluate:onBehalfOf:. Why does this make any difference? It seems to me that the issue is with runUntilErrorOrReturnFrom: and swapSender:, not with evaluate:onBehalfOf:.
What am I missing?<br>
<br>
> Best,<br>
> Christoph<br>
<br>
</div>
</div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div><span style="font-size:small; border-collapse:separate">
<div>_,,,^..^,,,_<br>
</div>
<div>best, Eliot</div>
</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>