[Pharo-dev] GTDebugger variables table
btc at openinworld.com
Thu Feb 2 07:56:34 EST 2017
> On 02/02/2017 11:22, Denis Kudriashov wrote:
> Finally I force myself to report my bad feeling of merged variable table in
> 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
> 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 at 2 corner: 3 at 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
> 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
<nicolas.anquetil at inria.fr> 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
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
> but it is true that when there are many attributes/local variables, one gets
> easily annoyed too.
More information about the Pharo-dev