On Fri, Feb 3, 2017 at 10:21 AM, Ben Coman <b...@openinworld.com> wrote:
> On Fri, Feb 3, 2017 at 12:28 AM, Denis Kudriashov <dionisi...@gmail.com> > wrote: > > > > 2017-02-02 17:16 GMT+01:00 John Brant <br...@refactoryworkers.com>: > >> > >> 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. > > 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... http://forum.world.st/magic-numbers-in-gtInspectorVariableValuePairs-tp4932831.html cheers -ben
