[Pharo-dev] GTDebugger variables table
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
> 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