[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-ove... -- Dr. Geo http://drgeo.eu
On 6 Feb 2017, at 18:55, Hilaire <hilaire@drgeo.eu> 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-ove...
-- Dr. Geo http://drgeo.eu
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
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
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 <hilaire@drgeo.eu>:
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
On Mon, Feb 6, 2017 at 9:14 PM, Hilaire <hilaire@drgeo.eu> wrote:
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
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
-- Dr. Geo http://drgeo.eu
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
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
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 <hilaire@drgeo.eu> wrote:
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
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
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 -- 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.
On 6 Feb 2017, at 21:25, Sean P. DeNigris <sean@clipperadams.com> 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.
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
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
On Wed, Feb 8, 2017 at 8:24 PM, Hilaire <hilaire@drgeo.eu> wrote:
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.
Show the complete stack. By default the stacks shows a limited number of stack frames.
Run to here
Execute methods up to the text cursor position and return debugger control.
yes.
Where is?
Show the next method to be executed (step) by the debugger.
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
-- Dr. Geo http://drgeo.eu
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 <sven@stfx.eu> wrote:
On 6 Feb 2017, at 18:55, Hilaire <hilaire@drgeo.eu> 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
On 7 Feb 2017, at 08:05, Stephane Ducasse <stepharo.self@gmail.com> 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 <sven@stfx.eu> wrote:
On 6 Feb 2017, at 18:55, Hilaire <hilaire@drgeo.eu> 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-ove...
-- Dr. Geo http://drgeo.eu
looks good to me. On Tue, Feb 7, 2017 at 8:40 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 7 Feb 2017, at 08:05, Stephane Ducasse <stepharo.self@gmail.com> 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 <sven@stfx.eu> wrote:
On 6 Feb 2017, at 18:55, Hilaire <hilaire@drgeo.eu> 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
participants (6)
-
Andrei Chis -
Hilaire -
Sean P. DeNigris -
Stephane Ducasse -
Sven Van Caekenberghe -
Thierry Goubier