GTDebugger variables table
Locked
 
|
Hi.
Finally I force myself to report my bad feeling of merged variable table in GTDebugger. By "merged" I mean that debugger join temps and receiver state in one table. Sometimes I really not like it because it is difficult to find concrete variable. 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. For example try debug #expandBy: method: You will see rows: self, corner, delta, origin, thisContext, stackTop Maybe in this example it is not really bad. But it shows problem. And imaging that there are much more inst vars in receiver object like in morph or Spec. It is really difficult to find desired temp. Actually it is also difficult to find inst var which are really used in selected method. And usually methods use only few variables and few temps. And the rest variables in table are just waste. I think we can improve this part of debugger. My idea that variable table should show only used temp and variables. And "self" should be selected by default. With this main table will show only important information. And on the right pane we will see receiver state like in the old debuggers. What you think? |
Re: GTDebugger variables table
|
|
for what it is worth, Eclipse behaves more or less as described by Denis: you see only local variables (self being one) and if a variable contains an object (such as self), it expands in a three to show the attributes of this object. I sometimes find it a pain to have to expand "self" to see the
attributes, but it is true that when there are many
attributes/local variables, one gets easily annoyed too. nicolas On 02/02/2017 11:22, Denis Kudriashov
wrote:
-- Nicolas Anquetil -- MCF (HDR) Project-Team RMod |
|
|
> On 02/02/2017 11:22, Denis Kudriashov wrote:
> > Hi. > > Finally I force myself to report my bad feeling of merged variable table in > GTDebugger. > By "merged" I mean that debugger join temps and receiver state in one table. > Sometimes I really not like it because it is difficult to find concrete > variable. > > 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. > > For example try debug #expandBy: method: > > (1@2 corner: 3@4) expandBy: 10 > > You will see rows: self, corner, delta, origin, thisContext, stackTop > Maybe in this example it is not really bad. But it shows problem. > And imaging that there are much more inst vars in receiver object like in > morph or Spec. It is really difficult to find desired temp. > Actually it is also difficult to find inst var which are really used in > selected method. And usually methods use only few variables and few temps. > And the rest variables in table are just waste. > > I think we can improve this part of debugger. My idea that variable table > should show only used temp and variables. And "self" should be selected by > default. > With this main table will show only important information. And on the right > pane we will see receiver state like in the old debuggers. > > What you think? I think thats a really innovative approach. I've haven't been too bothered by this, but I imagine it would feel like an improvement. I'd like to try it. On Thu, Feb 2, 2017 at 7:00 PM, Nicolas Anquetil <[hidden email]> wrote: > for what it is worth, Eclipse behaves more or less as described by Denis: > > you see only local variables (self being one) and if a variable contains an > object (such as self), it expands in a three to show the attributes of this > object. in a tree? > > I sometimes find it a pain to have to expand "self" to see the attributes, but in this case it would be pre-selected and already showing in the second pane cheers -ben > but it is true that when there are many attributes/local variables, one gets > easily annoyed too. |
|
|
In reply to this post by Denis Kudriashov
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. > I think we can improve this part of debugger. My idea that variable > table should show only used temp and variables. And "self" should be > selected by default. > With this main table will show only important information. And on the > right pane we will see receiver state like in the old debuggers. > > What you think? 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. 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. 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 |
Re: GTDebugger variables table
|
|
2017-02-02 17:16 GMT+01:00 John Brant <[hidden email]>:
I want everything you suggest :) |
|
|
On Fri, Feb 3, 2017 at 12:28 AM, Denis Kudriashov <[hidden email]> wrote:
> > 2017-02-02 17:16 GMT+01:00 John Brant <[hidden email]>: >> >> 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. I'm not sure I'd like variables slipping in and out and rearranging the middle of the list I'm looking at. Perhaps scope could be indicated another way like greying out variables. It would be okay for block variables to be added at the bottom. >> Interesting variables should also do some analysis to see what accessor >> methods are used and show their corresponding variables. This is a nice idea. It need not only be for interesting variables. Ideally it would be a tab in the next pane to the right of the [Meta] tab, but I guess its difficult since that pane is concerned with the object, and linking back to the variable holding could be difficult. >> >> 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. I really miss this from my TurboPascal days. The difficulty of course is avoiding side effects. >> >> 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. Perhaps the stack could be another tab next to [Variables] ? Or maybe it [Stack] would be better as a tab of thisContext's next pane. >> >> >> 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. > > > I want everything you suggest :) So we should try in Pharo 7. cheers -ben |
|
|
On Fri, Feb 3, 2017 at 10:21 AM, Ben Coman <[hidden email]> wrote: On Fri, Feb 3, 2017 at 12:28 AM, Denis Kudriashov <[hidden email]> wrote: Actually you can try... Context>>stackValueMap | stackValues stackDepth| stackValues := OrderedCollection new. stackDepth := self basicSize min: 21. (stackDepth to: 1 by: -1) do: [ :index | |key| key := (index = stackDepth) ifTrue: ['Top'] ifFalse: [(stackDepth - index + 1) asString]. stackValues add: (key -> (self basicAt: index)) ]. ^stackValues Context>>gtInspectorStackValuesIn: composite <gtInspectorPresentationOrder: 40> | stackValues | stackValues := self stackValues. ^ (composite table) title: 'Stack'; display: [ self stackValueMap ]; column: 'Depth' evaluated: [ :assoc | assoc key ] width: 50; column: 'Item' evaluated: [ :assoc | GTObjectPrinter new asTruncatedTextFrom: assoc value ] I'm not sure whether the #stackValueMap is an appropriate name. Perhaps it should be #methodStackValueMap or something else? Similar for the tab name. And I don't know what the magic number 21 is, as I queried here... cheers -ben |
|
|
In reply to this post by John Brant-2
On Thu, 02 Feb 2017 17:16:49 +0100, John Brant
<[hidden email]> 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/ |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |