[Pharo-dev] GTDebugger variables table

stepharong stepharong at free.fr
Sat Feb 4 09:20:43 EST 2017


On Thu, 02 Feb 2017 17:16:49 +0100, John Brant  
<brant at refactoryworkers.com> wrote:

> On 02/02/2017 04:22 AM, Denis Kudriashov wrote:
>
>> Now I think I realized main reason of my confusion. Temps and receiver
>> vars are not just in single table but they are also sorted by name all
>> together.
>
> I'm not a fan of this either. While I can filter by the type of variable  
> to limit the list, the next time I step the debugger, the whole list  
> resets. The list filter and selection should be kept across steps in the  
> debugger (if possible).
>
> Some might argue that you should have fewer variables so the list would  
> be easier to use in the debugger. However, if you are using the  
> debugger, likely you are still in the "make it work" phase and haven't  
> performed the factoring from the "make it right" phase.

+ 1 and under stress


> I think my preference would be to have several tabs for the variables.  
> In addition to the one tab that we have now that shows all variables, I  
> can think of tabs for locals, inst vars, interesting variables, watched  
> variables/expressions, and stack variables. Locals would show just the  
> method/block arguments and any temps defined in the method. Inst vars  
> would show the object's inst vars (and maybe class vars, however these  
> would only appear after the inst vars).
>
> Interesting variables would show locals and inst vars used by the  
> method. The locals would be limited to the ones that are still active at  
> the current location in the method. For example, if you are in a block,  
> it would only show variables used in the block. Also, if you are  
> before(/after) the first(/final) use of the variable, it wouldn't show  
> in the interesting list. Interesting variables should also do some  
> analysis to see what accessor methods are used and show their  
> corresponding variables.

I like that

>
> Watched variables/expressions would be user controlled. The user could  
> add/remove variables or expressions. These variables/expressions would  
> remain across different methods. If a variable didn't exist in the other  
> method, "Invalid" could be displayed.
>
> Finally, stack variables would display the whole stack and not just the  
> top item. I like the ability to see the stack top, but it really doesn't  
> work if you want to see the first argument of a two argument message  
> send. For example, if you debug "Array with: OrderedCollection new with:  
> Set new", stepping over the "OrderedCollection new" immediately pushes  
> the "Set" class on the stack so you can't see the "OrderedCollection  
> new" object.

I like that now when we have too many tabs it often happens that
only two are useful.
>
>
> BTW, the current variable list sometimes shows 'error obtaining field  
> value' for temporaries when stepping through a method. I'm not sure why  
> it occurs, but it should always be able to display the temp variables.
>
>
> John Brant
>


-- 
Using Opera's mail client: http://www.opera.com/mail/



More information about the Pharo-dev mailing list