gtdebugger in pharo 5.0

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
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

On Fri, Jan 8, 2016 at 2:09 PM, Dimitris Chloupis <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

> On 10 Jan 2016, at 21:14, Ferlicot D. Cyril <[hidden email]> wrote:
>
> Le 08/01/2016 12:07, Tudor Girba a écrit :
>> 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 <http://www.tudorgirba.com>
>> www.feenk.com
>>
>> "What is more important: To be happy, or to make happy?"
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>
> Hi,
>
> An other thing that came in my mind is that, for now, GTDebugger lack
> documentation.
> Some classes have no documentation and the class with a comment only
> have 1 line and don't follow the template.
>
> It's good that people takes time to add documentation but if the new
> classes that Pharo include does not have a proper documentation (class
> doc + comments in complex methods) we will never be able to have a
> version of Pharo with a good documentation.
>
> I think that we should not integrate new classes if they don't have a
> class comment that follow the template.

+100

I can understand that when prototype, hacking, being generally productive inside Pharo, you don't write comments at first. But once you go public, after some iterations, and especially if you want to be integrated into Pharo itself, there is no excuse. We need proper class comments, and comments for the main non-trivial public methods.

Sven

> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 165 Avenue Bretagne
> Lille 59000 France
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

I cant understand it not having comments in the first place because i forget so easily , especially when the code grow larger. But yeah class comments would be the best feature that pharo can ever have. It would make coding 1000 times easier.

On Sun, Jan 10, 2016 at 10:25 PM Sven Van Caekenberghe <[hidden email]> wrote:

> On 10 Jan 2016, at 21:14, Ferlicot D. Cyril <[hidden email]> wrote:
>
> Le 08/01/2016 12:07, Tudor Girba a écrit :
>> 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 <http://www.tudorgirba.com>
>> www.feenk.com
>>
>> "What is more important: To be happy, or to make happy?"
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>
> Hi,
>
> An other thing that came in my mind is that, for now, GTDebugger lack
> documentation.
> Some classes have no documentation and the class with a comment only
> have 1 line and don't follow the template.
>
> It's good that people takes time to add documentation but if the new
> classes that Pharo include does not have a proper documentation (class
> doc + comments in complex methods) we will never be able to have a
> version of Pharo with a good documentation.
>
> I think that we should not integrate new classes if they don't have a
> class comment that follow the template.

+100

I can understand that when prototype, hacking, being generally productive inside Pharo, you don't write comments at first. But once you go public, after some iterations, and especially if you want to be integrated into Pharo itself, there is no excuse. We need proper class comments, and comments for the main non-trivial public methods.

Sven

> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 165 Avenue Bretagne
> Lille 59000 France
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

I see the motivation, but things should go incrementally. If code should be highly documented, with a high test coverage, friendly to API migration then well.. not much happens…

Cheers,
Alexandre


> On Jan 10, 2016, at 5:24 PM, Sven Van Caekenberghe <[hidden email]> wrote:
>
>> I think that we should not integrate new classes if they don't have a
>> class comment that follow the template.
>
> +100
>
> I can understand that when prototype, hacking, being generally productive inside Pharo, you don't write comments at first. But once you go public, after some iterations, and especially if you want to be integrated into Pharo itself, there is no excuse. We need proper class comments, and comments for the main non-trivial public methods.

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev