- Can we have a setting to remove all the colors from the stack because
sometimes the hilighting
is more confusing than helping and especially for newbies
- the argument about run to here not being a button is not about logical
placement
is it about making things easy to use and discover.
- I found the icon on the right (the right mo
When do you think that the new debugger could be stable.
Because we can try to see if we can change the lectures and change the
screenshots but first
we should finish the other ones.
Stef
Le 9/1/16 22:35, Tudor Girba a écrit :
Hello everyone,
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 <[email protected]
<mailto:[email protected]>> 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?"
--
www.tudorgirba.com <http://www.tudorgirba.com>
www.feenk.com
"It's not how it is, it is how we see it."
