On Sun, Jan 10, 2016 at 5:51 AM, stepharo <[email protected]> wrote: > - 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 > > There is a setting for this which allows you to disable it. Maybe we should disable it by default (thought I would enable it for myself)
> - 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]> 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." > > > -- Mariano http://marianopeck.wordpress.com
