[Cuis-dev] Allow debugger to step into quick return methods

[Hernán Wilkinson]

This is so great!! It is a really important feature when doing TDD and the
first implementation of a method is a ^true or similar.
The only concern I have is the change in Process>>#resume, because that
impacts all the situations where #resume is sent... I know the impact is
low, but is it possible to restrict that change to the debugger only or not?

Cheers!
Hernan.

On Mon, Nov 13, 2023 at 8:28 PM Facundo Javier Gelatti via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> Hi!
> I attach some code to be able to step into quick return methods from the
> debugger, and there's also a demo video
> <https://drive.google.com/file/d/1Iv5-hJ4TNjmR0pG-qm02KpTxCvKzsDZC/view?usp=sharing>.
> Being able to step into a quick return method is very useful, especially in
> situations where we are doing TDD (because the first implementation of a
> method probably ends up being a quick return).
>
> Most of these changes were developed during the Camp Smalltalk event of
> the Smalltalks 2023 conference by me, Juan Vuletich and Felipe Zak (thank
> you guys!).
>
> I included automated tests for various debugging scenarios. The class
> QuickReturnDebuggingTest should probably be moved to an appropriate
> category (it's currently in the "Smalltalks 2023" category, just because
> the changes were developed during the conference) or be merged into another
> existing test class (I wasn't sure where to put it).
>
> ℹ️ Extra interesting info: there are other places in which we're currently
> treating quick return methods in a special way. See for example
> Debugger>>#contents:notifying:, which handles the special case of a
> normal method becoming a quick return method after saving the changes on
> the debugger (the stack frame is removed in that case, try it!). As a
> curiosity, another quirk related to quick returns is that you cannot debug
> an expression that will compile to a quick return (e.g. ^2), the debugger
> simply doesn't show up! None of this is modified on the code I'm submitting.
>
> I include a summary of the changes below, that could be useful during code
> review 👇
>
> Cheers!
> Facu
>
> ------------------------------
> 📝 Changes summary:
>
>    - Do not run a quick return as a primitive in
>    ContextPart>>#send:to:with:lookupIn:, treat it as a normal instruction
>    —before which we can stop— and create a new stack frame for it.
>    - Refactor: extracted an isPrimitive variable in
>    ContextPart>>#send:to:with:lookupIn:, to avoid having repeated code.
>    - Changed InstructionStream>>#willReturn to include quick returns
>    there. This ends up telling the debugger that it's possible to pause the
>    execution there.
>    - In Process>>#resume, resolve pending quick returns before running
>    #primitiveResume, so that the VM can resume the process without having
>    an unexpected stack frame (if you remove this, the VM crashes).
>    - Refactor: extracted the method Debugger class>>#newDebugging:, which
>    is useful for tests (because it does not open the debugger UI).
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>


-- 

*Hernán WilkinsonAgile Software Development, Teaching & Coaching*
*Phone: +54-011*-4893-2057
*Twitter: @HernanWilkinson*
*site: http://www.10Pines.com <http://www.10pines.com/>*
Address: Alem 896, Floor 6, Buenos Aires, Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20231114/7db5bc54/attachment-0001.htm>