As expected, there was some feedback. Here is a
summary:
1. The layout should mirror the classic debugger
- The previous layout was chosen to show more of the
stack and to make use of the screen real estate.
- But, as that is not an essential component of
GTDebugger, the current implementation of the generic stack
debugger looks like this now:
2. it would be interesting if the buttons would have
text
- This is something we need to work on
3. Why is there bytecode shown?
- There is none by default :). This only appears
when the developer explicitly chooses the Bytecode debugger
4. why is there a _thisContext _stackTop?
- Because this is what the SpecDebugger offers as
well :).
- But, we removed them for now from the list.
- There would be a possibility to add them to the
context menu of the stack or to add them to bottom of the list
5. why is there a Type column in the inspector
- Because we want to know what kind of variable we
are dealing with (parameter, instvar, temp). This is not
explicit in other debuggers.
- Furthermore, you can filter the variables by
clicking on the type tag. This can be particularly useful when
we deal with large states.
Please let me know if I missed anything. Of these
only point 2 requires work.
Cheers,
Doru
On Jan 8, 2016, at 1:07 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a�significant change that might affect your workflow, here is some background information to help you deal�with the change.
First, you should know that the change is not irreversible and it is easily possible to disabled the new�debugger through a setting. However, please do take the time to provide us feedback if something does not�work out for you. We want to know what can be improved and we try to react as fast as we can.
A practical change comes from the fact that the variables are manipulated through a GTInspector, which�makes it cheaper to maintain in the longer run.
While the first thing that will capture the attention is the default generic interface, the real power comes from�the moldable nature of the debugger. Like all other GT tools, GTDebugger is also moldable by design. This�means that we can construct custom debuggers for specific libraries at small costs (often measured in a�couple of hundred lines of code).
For example, the core configuration includes also the SUnit and the bytecode debugger. These are around�150 lines of code. Here is how the bytecode debugger looks like:
<bytecode.png>
You can find more information in an introductory overview blog post that also includes some links for further�reading:
http://www.humane-assessment.com/blog/gtdebugger-in-pharo/
Please let us know what you think.
Cheers,
Doru
--
www.tudorgirba.com
www.feenk.com
"What is more important: To be happy, or to make happy?"