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

Juan Vuletich juan at cuis.st
Tue Nov 21 11:36:25 PST 2023

Hi Folks,

Great work!

WRT Hernáns concern about modifying #resume, I agree, and suggest 
modifying #resumeProcess instead, so that the modified line reads:

         interruptedProcess resolvePendingQuickReturns; resume ].

WRT the fix to the problem shown by Hernán's example, it looks OK to me.

If you both agreen, I'm willing to push the changes to GitHub.


On 11/18/2023 7:05 PM, Hernán Wilkinson via Cuis-dev wrote:
> Hi Facu,
>     I'm looking into it—these errors are really tough to debug!
>     The problem arises when you try to debug an exception: in your
>     code example, Customer class>>#importCustomers throws an exception
>     because the file input.txt does not exist, therefore line is nil.
> oh! that is because I forgot to send you the file, but create a file 
> called input.txt or replace the file with a ReadStream. That is not 
> the problem I had.
> Replace the opening of the file with:
> inputStream := ReadStream on: 'C,a,b,d,1122'.
> That will help you reproduce the error. You have to step over until 
> the [ line notNil ]
>     📝 Here's what I've found so far:
>     In my previous changeset, I changed the
>     InstructionStream>>#willReturn method so that it'll stop before
>     actually performing a quick return once you step into it. This is
>     used from ContextPart>>#stepToSendOrReturn (👈 notice the message
>     name).
>     While I was debugging this issue, I realized that there's also
>     another place where something similar is done:
>     ContextPart>>#runUntilErrorOrReturnFrom:. This is used, for
>     example, when you perform a "through" action. As a quick return
>     method can only return an object, I changed
>     #runUntilErrorOrReturnFrom: to just do that instead of going
>     through the rest of the logic.
>     I attach a fileout of the changes to
>     ContextPart>>#runUntilErrorOrReturnFrom:. It should be filed-in
>     after having applied the original changeset, and it should fix the
>     problem.
>     I don't think this is an elegant solution, but I want you to try
>     it to see if it works on your tests or if you find more problems.
> With this fix, the problem I describe above is gone, so it fixes 
> the issue.
> Cheers!
> Hernan.
>     I'll keep looking into it!
>     Cheers!
>     Facu
>     El mar, 14 nov 2023 a las 9:35, Hernán Wilkinson
>     (<hernan.wilkinson at 10pines.com
>     <mailto:hernan.wilkinson at 10pines.com>>) escribió:
>         Hi Facu,
>          there is an error with this change. I do not know exactly
>         what it is, but you can reproduce it by filing in the
>         attached file and debugging importCustomers from Customer
>         class (it is a class method). The error happens when doing
>         step over in [ line notNil ] whileTrue: ...
>         On Tue, Nov 14, 2023 at 8:07 AM Hernán Wilkinson
>         <hernan.wilkinson at 10pines.com
>         <mailto:hernan.wilkinson at 10pines.com>> wrote:
>             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
>             <mailto: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 <mailto:Cuis-dev at lists.cuis.st>
>                 https://lists.cuis.st/mailman/listinfo/cuis-dev
>             -- 
>             *Hernán Wilkinson
>             Agile 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
>         -- 
>         *Hernán Wilkinson
>         Agile 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
> -- 
> *Hernán Wilkinson
> Agile 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

Juan Vuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20231121/87a759a3/attachment-0001.htm>

More information about the Cuis-dev mailing list