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 <tu...@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?" > -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."
