<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;">
<p>Hi Eliot, thanks for your message! :-)</p>
<p><br>
</p>
<p>> <span>It comes to mind that a similar trick might be usable to fix the swapSender:/runIUntilErrorOrReturmFrom: misinteraction.  One could change the class of the current context into one that overrides all sender setting methods (in particular swapSender:). 
 That could be a cool solution.</span></p>
<p><span><br>
</span></p>
<p><span>Yes, that is exactly what I proposed in <a href="http://forum.world.st/BUG-REGRESSION-while-debugging-Generator-nextPut-tp5108125p5109109.html" class="OWAAutoLink" id="LPlnk94686" previewremoved="true">http://forum.world.st/BUG-REGRESSION-while-debugging-Generator-nextPut-tp5108125p5109109.html</a>.
 The VM appears not to like this, but if we could ensure the lifespan of such a DebuggedContext is restricted to debugging time, this should be fine. The only advantage I could imagine at the moment would be that such a subclass would make it even harder to
 find errors in the "non-debugging" machinery.</span></p>
<p><span style="font-size: 12pt;">Btw, if you could take a look at the changeset I proposed there, it would be great!</span></p>
<p><span style="font-size: 12pt;"><br>
</span></p>
<p><span style="font-size: 12pt;">Apart from this, according to my original question of this thread, I would actually expect "Through" not to search for blocks only, but for any context activations. What about you?</span></p>
<p><span style="font-size: 12pt;">(However, from theory, </span><span style="font-size: 12pt;">we would only need to override #<span>doPrimitive:method:receiver:args:.)</span></span></p>
<p><span style="font-size: 12pt;"><span><br>
</span></span></p>
<p><span style="font-size: 12pt;"><span>Best,</span></span></p>
<p><span style="font-size: 12pt;"><span>Christoph</span></span></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><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> Montag, 6. Januar 2020 22:53:32<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] Debugger Through slow</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr">Hi Christoph,</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Sep 11, 2019 at 4:55 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_-1394943290630467919divtagdefaultwrapper" 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>take the following snippet, debug-it and press "Through":</p>
<p><span>SqueakMessageCategoriesHelp asHelpTopic.</span><br>
</p>
<p><span><br>
</span></p>
<p><span>For me, it makes the debugger hang really long time, as apparently the whole code execution is simulated, searching for the current context (#stepToHome:). "Over", in contrast, is faster by far, calling #completeStep: instead.</span></p>
<p><span>Can we speed up "Through" in any way? As the button is explained as "Step into a block", we could call #completeStep: internally if the selected message does not contain a block argument, for example.</span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>The way we did it in VisualWorks is to create subclasses of the various BlockClosure classes (in our case of BlockClosure and FullBlockClosure) that override the value[:value*] messages to call back into the debugger, and use adoptInstance: to convert
 the blocks created in the current activation into these "breaking" blocks.  </div>
<div><br>
</div>
<div>The first problem is identifying the set of blocks that need to be morphed into "through" breaking blocks (TBBs for the purposes of this email).</div>
<div>One way would be to simply use [Full]BlockClosure>>allInstances, selecting those whose home is the home context, but that could suck in large images.</div>
<div>Another way would be to somehow intercept block creation while stepping.sending and, say, maintain a dictionary in the debugger from home context to blocks whose home is that context.</div>
<div>IIRC, the VW implementation scanned the outgoing arguments at point of send (from a "through"), looking for blocks.  This is simple but misses cases where blocks are stored in variables, etc.</div>
<div><br>
</div>
<div>The second problem is when to do the morphing.  It should be done during the "through" processing, and undone on the "through" terminating, either by breaking or by finishing the "through" send.  It c an then be reapplied on every "through".</div>
<div><br>
</div>
<div>The final problem is what to do in the overridden value[:value*] methods.  These should call some common helper that contacts the debugger.  The debugger can then morph the block back into a normal block and step into its activation.</div>
<div><br>
</div>
<div>N.B.</div>
<div>It comes to mind that a similar trick might be usable to fix the swapSender:/runIUntilErrorOrReturmFrom: misinteraction.  One could change the class of the current context into one that overrides all sender setting methods (in particular swapSender:). 
 That could be a cool solution.  And tackling the two issues together (speeding up "through", and fixing stepping over/into Generators) might lead you to come up with a nice mini-framework for intercepting crucial execution transitions in the debugger.  Clearly
 a better solution to fork than killing simulation with primitive 19  is to open another debugger, or offer to open a new debugger, on the new process.  But one can see issues here.  There might be a rationale for a debugger with training wheels for learners
 exploring the system, and a "oh my god, it's covered in hair!" full featured debugger for us seasoned old hacks.</div>
<div><br>
</div>
<div>HTH</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_-1394943290630467919divtagdefaultwrapper" 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><span>Best,</span></p>
<p><span>Christoph</span></p>
</div>
</div>
</blockquote>
</div>
HNY
<div><br>
<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>
</body>
</html>