Hi,

> On Jan 10, 2016, at 10:51 AM, stepharo <steph...@free.fr> 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

As Mariano said, there is one already.


> - 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. 

Please, let’s be reasonable. This is a contextual action, and it is not at all 
unreasonable to have it as a contextual menu.


> - I found the icon on the right (the right mo

You did not finish this one.



> When do you think that the new debugger could be stable. 

What is needed from your point of view except from the labels on the buttons?


> Because we can try to see if we can change the lectures and change the 
> screenshots but first 
> we should finish the other ones. 

Thank you for wanting to find a solution.

Cheers,
Doru

> 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:
>> 
>> <Mail Attachment.png>
>> 
>> 
>> 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."
>> 
> 

--
www.tudorgirba.com
www.feenk.com

"We are all great at making mistakes."









Reply via email to