[QA] Debugger buttons explained

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[QA] Debugger buttons explained

HilaireFernandes
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

Sven Van Caekenberghe-2

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

HilaireFernandes
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

Sean P. DeNigris
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

HilaireFernandes
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

Andrei Chis
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.

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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

Sven Van Caekenberghe-2
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.
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

Stephane Ducasse-3
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:

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

Sven Van Caekenberghe-2

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

Thierry Goubier
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
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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

HilaireFernandes
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

HilaireFernandes
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

Andrei Chis
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
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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

HilaireFernandes
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

HilaireFernandes
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

Stephane Ducasse-3
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:

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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

HilaireFernandes
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [QA] Debugger buttons explained

Andrei Chis


On Wed, Feb 8, 2017 at 8:24 PM, Hilaire <[hidden email]> 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



Loading...