Hi Eliot, thanks for your message! :-)
> 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.
Yes, that is exactly what I proposed in http://forum.world.st/BUG-REGRESSION-while-debugging-Generator-nextPut-tp5108125p5109109.html. 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.
Btw, if you could take a look at the changeset I proposed there, it would be great!
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?
(However, from theory, we would only need to override #doPrimitive:method:receiver:args:.)
Best,
Christoph
Hi all,
take the following snippet, debug-it and press "Through":
SqueakMessageCategoriesHelp asHelpTopic.
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.
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.
Best,
Christoph