[Pharo-users] [Moose-dev] Re: gtdebugger in pharo 5.0

Andrei Chis chisvasileandrei at gmail.com
Fri Jan 8 08:34:19 EST 2016


On Fri, Jan 8, 2016 at 2:23 PM, Dimitris Chloupis <kilon.alios at gmail.com>
wrote:

> is there any documentation about this ? or i just look at the relevant
> classes ?
>

Not really.  Now you'll need to look in UITheme>>styleContext:from:, but
I'll refactor that method shortly.



> On Fri, Jan 8, 2016 at 3:20 PM Andrei Chis <chisvasileandrei at gmail.com>
> wrote:
>
>> On Fri, Jan 8, 2016 at 2:09 PM, Dimitris Chloupis <kilon.alios at gmail.com>
>> wrote:
>>
>>> does the GTDebugger respect the pharo themes support or is it like
>>> GTSpotter ?
>>>
>>
>> It behaves just as GTInspector regrading the theme.  Just if you are
>> using a custom theme and want to have the coloring of the stack enabled you
>> need to provide the appropriate colors in your theme (styleContext:from:)
>>
>> Cheers,
>> Andrei
>>
>>
>>
>>>
>>> On Fri, Jan 8, 2016 at 1:08 PM Tudor Girba <tudor at 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:
>>>>
>>>>
>>>>
>>>> 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?"
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev at list.inf.unibe.ch
>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev at list.inf.unibe.ch
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>
>>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev at list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20160108/8dc119e5/attachment.html>


More information about the Pharo-users mailing list