[Pharo-dev] GTDebugger variables table
btc at openinworld.com
Thu Feb 2 22:33:27 EST 2017
On Fri, Feb 3, 2017 at 10:21 AM, Ben Coman <btc at openinworld.com> wrote:
> On Fri, Feb 3, 2017 at 12:28 AM, Denis Kudriashov <dionisiydk at gmail.com>
> > 2017-02-02 17:16 GMT+01:00 John Brant <brant at refactoryworkers.com>:
> >> I think my preference would be to have several tabs for the variables.
> >> 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
> >> appear after the inst vars).
> >> Interesting variables would show locals and inst vars used by the
> >> The locals would be limited to the ones that are still active at the
> >> location in the method. For example, if you are in a block, it would
> >> 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
> >> For example, if you debug "Array with: OrderedCollection new with: Set
> >> stepping over the "OrderedCollection new" immediately pushes the "Set"
> >> 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.
Actually you can try...
| stackValues stackDepth|
stackValues := OrderedCollection new.
stackDepth := self basicSize min: 21.
(stackDepth to: 1 by: -1) do: [ :index |
key := (index = stackDepth) ifTrue: ['Top'] ifFalse: [(stackDepth - index +
stackValues add: (key -> (self basicAt: index))
| stackValues |
stackValues := self stackValues.
^ (composite table)
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
And I don't know what the magic number 21 is, as I queried here...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev