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

Facundo Javier Gelatti javiergelatti at gmail.com
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!

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>

More information about the Cuis-dev mailing list