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

Thu Nov 16 04:49:08 PST 2023

Hi Hernán!

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.

📝 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.

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 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
>>
>
>
> --
>
> *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/20231116/95c89703/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ContextPart-runUntilErrorOrReturnFrom.st
Type: application/octet-stream
Size: 2114 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20231116/95c89703/attachment.obj>