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

Tue Nov 21 12:45:19 PST 2023

I agree!

On Tue, Nov 21, 2023 at 4:36 PM Juan Vuletich <juan at cuis.st> wrote:

> 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.
>
> Thanks!
>
> 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>) 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> 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> 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 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 Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>
>

-- 

*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/20231121/99ed8b0f/attachment-0001.htm>