[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.
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
> <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
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich
-------------- 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