[QA] Debugger buttons explained
Locked
[QA] Debugger buttons explained
 
|
How will you describe these buttons in the debugger?
Here are proposals for tooltips, please fix it, I am sure there are better way to write it. Proceed Quit the debugger and resume the execution of the method. Restart Reset the local variable and restart stepping at the beginning of the method. Into Step in the highlighted message, i.e. follow the sent message in its method. Over Execute the highlighted message, i.e. do not follow the sent message in its method. Through Execute the highlighted message, when argument is a bloc to #do:, #collect:, #select: #detect: step in the bloc. https://pharo.fogbugz.com/f/cases/19654/Tooltips-with-description-of-the-over-and-through-debugger-buttons-actions -- Dr. Geo http://drgeo.eu |
Re: [QA] Debugger buttons explained
|
> On 6 Feb 2017, at 18:55, Hilaire <[hidden email]> wrote: > > How will you describe these buttons in the debugger? > Here are proposals for tooltips, please fix it, I am sure there are > better way to write it. > > Proceed > Quit the debugger and resume the execution of the method. > > Restart > Reset the local variable and restart stepping at the beginning of the > method. > > Into > Step in the highlighted message, i.e. follow the sent message in its method. > > Over > Execute the highlighted message, i.e. do not follow the sent message in > its method. > > Through > Execute the highlighted message, when argument is a bloc to #do:, > #collect:, #select: #detect: step in the bloc. That last one is not correct. It has nothing to do with specific iteration selectors. It means: stop when execution returns in one of the argument blocks. It also works for #on:error: #streamContents: or any other message that accepts blocks as argument - which is pretty cool. Consult DebugSession for good descriptions of the actions. This is my version/take, probably not perfect either. Into Step in the highlighted message, i.e. follow the sent message, taking debugger control in the method invoked. Over Step over the highlighted message, i.e. do not follow the sent message, taking debugger control after the method invoked returns. Through Step over the highlighted message, i.e. do not follow the sent message, taking debugger control after the method invoked returns or whenever execution should return inside a block used as an argument before that. Restart Go back the start of the current execution context, resetting all local variables and take debugger control. Continue Relinquish debugger control and proceed execution from the current point of debugger control. > https://pharo.fogbugz.com/f/cases/19654/Tooltips-with-description-of-the-over-and-through-debugger-buttons-actions > > -- > Dr. Geo > http://drgeo.eu > > |
Re: [QA] Debugger buttons explained
|
|
Thanks for the updated message.
Le 06/02/2017 à 19:39, Sven Van Caekenberghe a écrit : > That last one is not correct. It has nothing to do with specific iteration selectors. It means: stop when execution returns in one of the argument blocks. It also works for #on:error: #streamContents: or any other message that accepts blocks as argument - which is pretty cool. Strangely step over does not step in the bloc with #do: but does with #to:do: In the later case step over and through behave mostly the same, the stack looks a bit different though. Another question, I try to locate where the tooltips are set in the debugger. I can't find it with traditional browser tools (send, class use) and the finder: The finder tells me "Through" is used in SpecThroughDebugAction, but browser tells me there is no use case of this class. I see some pragma in class side method, did it... actionType <debuggingAction> <contextMenuDebuggingAction> No user of actionType, but I guess user or pragma, how do you guys track the logic from here -- Dr. Geo http://drgeo.eu |
Re: [QA] Debugger buttons explained
|
Administrator
|
In reply to this post by Sven Van Caekenberghe-2
How about...
Into Step into the highlighted message, i.e. dive the debugger into the method which handles it Over Step over the highlighted message, i.e. execute it, but keep the debugger focused on the current method Through Like stepping "Over", except step through block contents when executed Restart Rewind to the start of the current execution context, resetting all local variables Continue Relinquish debugger control and proceed with normal execution
Cheers,
Sean |
Re: [QA] Debugger buttons explained
|
|
In reply to this post by HilaireFernandes
Ok, give a look to SpecDebugActionButton, this class has no user, only
progma reference, not easy to track the logic. Never mind I test on a halt in its #update method. Nothing happen when opening the debugger. May be there is instance in memory, no idea under which name it is referenced, may be not. Inspecting the debugger window does not help, it is a kind of generic morph. Never mind, can try to look at the menu item "Debug it" in the playground window, I used to find the action there. Oops, get lost there, I see #debugSelection looks promising, see announcement. Get lost again. No idea, someone else should put these tooltips in the appropriate place. Le 06/02/2017 à 21:14, Hilaire a écrit : > No user of actionType, but I guess user or pragma, how do you guys track > the logic from here -- Dr. Geo http://drgeo.eu |
Re: [QA] Debugger buttons explained
|
|
In reply to this post by HilaireFernandes
On Mon, Feb 6, 2017 at 9:14 PM, Hilaire <[hidden email]> wrote: Thanks for the updated message. Seems that the logic for changing the tooltips is not that straightforward. If you ping me once you decided for a the text of the tooltip I can add them. If you want to look at it yourself here are some details: Each action in the debugger is modeled as a subclass of DebugAction. The Glamour interface of the debugger uses DebugAction>>#asGlamourAction to transform that into a Glamour action. This action is then rendered in GLMMorphicActionRenderer>>#render:. There the tooltip is set directly by concatenating the title and the shortcut of the action. Best solution would be to add a description attribute to DebugAction and GLMAction and then modify GLMMorphicActionRenderer>>#render: to use it. For the Spec interface of the debugger you need to adapt DebugAction>>#asMenuRegistrationIn: Cheers, Andrei |
Re: [QA] Debugger buttons explained
|
|
In reply to this post by Sean P. DeNigris
> On 6 Feb 2017, at 21:25, Sean P. DeNigris <[hidden email]> wrote: > > How about... > > Into > > Step into the highlighted message, i.e. dive the debugger into the method > which handles it > > Over > > Step over the highlighted message, i.e. execute it, but keep the debugger > focused on the current method > > Through > > Like stepping "Over", except step through block contents when executed > > Restart > > Rewind to the start of the current execution context, resetting all local > variables > > Continue > > Relinquish debugger control and proceed with normal execution Well simpler is of course better, but I think that the aspect of telling what the debugger will do, where it will stop is quite important. Unless it is clear for everybody that step implies to stop and having control return to the debugger. > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/QA-Debugger-buttons-explained-tp4933212p4933238.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
Re: [QA] Debugger buttons explained
|
|
In reply to this post by Sven Van Caekenberghe-2
Sven I do not get Step over the highlighted message, i.e. do not follow the sent message, taking debugger control after the method invoked returns or whenever execution should return inside a block used as an argument before that. in particular the taking debugger control may be give back debugger control? On Mon, Feb 6, 2017 at 7:39 PM, Sven Van Caekenberghe <[hidden email]> wrote:
|
Re: [QA] Debugger buttons explained
|
|
> On 7 Feb 2017, at 08:05, Stephane Ducasse <[hidden email]> wrote: > > Sven I do not get > > Step over the highlighted message, i.e. do not follow the sent message, taking debugger control after the method invoked returns or whenever execution should return inside a block used as an argument before that. > > in particular the taking debugger control > may be > > give back debugger control? Give back might be clearer than take back, I guess, I don't know. Maybe the 'before that' should be moved too, as in Step over the highlighted message, i.e. do not follow the sent message, give back debugger control after the method invoked returns or whenever before that execution should return inside a block used as an argument. > On Mon, Feb 6, 2017 at 7:39 PM, Sven Van Caekenberghe <[hidden email]> wrote: > > > On 6 Feb 2017, at 18:55, Hilaire <[hidden email]> wrote: > > > > How will you describe these buttons in the debugger? > > Here are proposals for tooltips, please fix it, I am sure there are > > better way to write it. > > > > Proceed > > Quit the debugger and resume the execution of the method. > > > > Restart > > Reset the local variable and restart stepping at the beginning of the > > method. > > > > Into > > Step in the highlighted message, i.e. follow the sent message in its method. > > > > Over > > Execute the highlighted message, i.e. do not follow the sent message in > > its method. > > > > Through > > Execute the highlighted message, when argument is a bloc to #do:, > > #collect:, #select: #detect: step in the bloc. > > That last one is not correct. It has nothing to do with specific iteration selectors. It means: stop when execution returns in one of the argument blocks. It also works for #on:error: #streamContents: or any other message that accepts blocks as argument - which is pretty cool. > > Consult DebugSession for good descriptions of the actions. > > > This is my version/take, probably not perfect either. > > > Into > > Step in the highlighted message, i.e. follow the sent message, taking debugger control in the method invoked. > > Over > > Step over the highlighted message, i.e. do not follow the sent message, taking debugger control after the method invoked returns. > > Through > > Step over the highlighted message, i.e. do not follow the sent message, taking debugger control after the method invoked returns or whenever execution should return inside a block used as an argument before that. > > Restart > > Go back the start of the current execution context, resetting all local variables and take debugger control. > > Continue > > Relinquish debugger control and proceed execution from the current point of debugger control. > > > > https://pharo.fogbugz.com/f/cases/19654/Tooltips-with-description-of-the-over-and-through-debugger-buttons-actions > > > > -- > > Dr. Geo > > http://drgeo.eu > > > > > > > |
Re: [QA] Debugger buttons explained
|
|
In reply to this post by HilaireFernandes
Hi Hilaire,
I find your use case interesting. It used to be the case, that one could discover an application commands by exploring the objects making up the GUI... Now, with Spec or Glamour, is that still the case? It seems not any more. Doru, can you confirm? Regards, Thierry 2017-02-06 21:48 GMT+01:00 Hilaire <[hidden email]>: Ok, give a look to SpecDebugActionButton, this class has no user, only |
Re: [QA] Debugger buttons explained
|
|
In reply to this post by Andrei Chis
Ok thanks for the tips.
As labes was use as tooltip too I have to set the balloon text as bellow which is not great but should help for the transition. setBalloonText: ((anAction help ifNil: [ anAction title]) , Character tab asString , anAction shortcutAsString) trimBoth; I will look at the tips text now. Le 06/02/2017 à 21:57, Andrei Chis a écrit : > The Glamour interface of the debugger uses DebugAction>>#asGlamourAction > to transform that into a Glamour action. This action is then rendered > in GLMMorphicActionRenderer>>#render:. > There the tooltip is set directly by concatenating the title and the > shortcut of the action. > Best solution would be to add a description attribute to DebugAction and > GLMAction and then > modify GLMMorphicActionRenderer>>#render: to use it. > For the Spec interface of the debugger you need to adapt > DebugAction>>#asMenuRegistrationIn: > -- Dr. Geo http://drgeo.eu |
Re: [QA] Debugger buttons explained
|
|
In reply to this post by Andrei Chis
Changed to the SpecDebugger in the method mentionned bellow does not
have action on newly debuggin session with SpecDebugger. This method is not call. Any idea? Le 06/02/2017 à 21:57, Andrei Chis a écrit : > For the Spec interface of the debugger you need to adapt > DebugAction>>#asMenuRegistrationIn: > -- Dr. Geo http://drgeo.eu |
Re: [QA] Debugger buttons explained
|
|
Seems that I made a small mistake before. DebugAction>>#asMenuRegistrationIn: is called only when creating the context menu.
SpecDebuggerDynamicToolbar is the class that builds the toolbar with the step buttons. Then each button will be an instance of SpecDebugActionButton. Andrei On Tue, Feb 7, 2017 at 8:29 PM, Hilaire <[hidden email]> wrote: Changed to the SpecDebugger in the method mentionned bellow does not |
Re: [QA] Debugger buttons explained
|
|
ok got it!
Le 07/02/2017 à 20:49, Andrei Chis a écrit : > Seems that I made a small mistake before. > DebugAction>>#asMenuRegistrationIn: is called only when creating the > context menu. > SpecDebuggerDynamicToolbar is the class that builds the toolbar with the > step buttons. Then each button will be an instance of SpecDebugActionButton. > -- Dr. Geo http://drgeo.eu |
Re: [QA] Debugger buttons explained
|
|
In reply to this post by Sean P. DeNigris
As we are here, what are your best proposals for these buttons:
Full stack Run to here Where is? Le 06/02/2017 à 21:25, Sean P. DeNigris a écrit : > How about... -- Dr. Geo http://drgeo.eu |
Re: [QA] Debugger buttons explained
|
|
In reply to this post by Sven Van Caekenberghe-2
looks good to me. On Tue, Feb 7, 2017 at 8:40 AM, Sven Van Caekenberghe <[hidden email]> wrote:
|
Re: [QA] Debugger buttons explained
|
|
In reply to this post by HilaireFernandes
Here my proposals. Please propose better alternative.
Le 07/02/2017 à 21:02, Hilaire a écrit : > Full stack I really don't know what to write there. > > Run to here Execute methods up to the text cursor position and return debugger control. > Where is? Show the next method to be executed (step) by the debugger. -- Dr. Geo http://drgeo.eu |
Re: [QA] Debugger buttons explained
|
|
On Wed, Feb 8, 2017 at 8:24 PM, Hilaire <[hidden email]> wrote: Here my proposals. Please propose better alternative. Show the complete stack. By default the stacks shows a limited number of stack frames.
yes.
This highlights where execution is within the selected stack frame. In case of the top context it's the method, assignment or return instruction that will be executed next. For the other contexts it's the method that is currently being executed. Cheers, Andrei |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |