Smalltalk › Pharo › Pharo Smalltalk Developers

gtdebugger in pharo 5.0

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

86 messages Options

12345

Tudor Girba-2

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?"

kilon.alios

Re: [Moose-dev] gtdebugger in pharo 5.0

does the GTDebugger respect the pharo themes support or is it like GTSpotter ?

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

bytecode.png (376K) Download Attachment

Andrei Chis

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

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

kilon.alios

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

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

On Fri, Jan 8, 2016 at 3:20 PM Andrei Chis <[hidden email]> wrote:

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

Andrei Chis

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

On Fri, Jan 8, 2016 at 2:23 PM, Dimitris Chloupis <[hidden email]> 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 <[hidden email]> wrote:
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

abergel

Re: [Pharo-users] gtdebugger in pharo 5.0

In reply to this post by Tudor Girba-2

This is an excellent news! I have been waiting for that for long!

go go go!

Alexandre

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

On Jan 8, 2016, at 8:07 AM, 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:

<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?"

stepharo

Re: gtdebugger in pharo 5.0

In reply to this post by Tudor Girba-2

I'm sorry but this debugger should not be the default one.
MONDAY we are filming our mooc and we have to explain the debugger and
personally I do not see the gain:
- It looks a lot more complex to me and I do not want to have to
redo all the screenshots
of our lecture.
- Just that I have to learn the meaning of small icons.
- Why do we need a special pane for the evaluator
- Why there is a type column.
- Sorry but I'm not convinced about the moldable aspect behind the
story (no need to argue I know it)

I would like to avoid to be forced to use not the latest version of
Pharo for the mooc.

Such changes are arriving far too late in the release. We do not change
the debugger itself the day of code freeze.

We decided that the GTDebugger can be included but to me it never meant
that it should be the default one.
I think that experts can choose the debugger they want. The newbies don't.

Stef

Nicolai Hess-3-2

Re: gtdebugger in pharo 5.0

2016-01-08 21:22 GMT+01:00 stepharo <[hidden email]>:

I think that experts can choose the debugger they want. The newbies don't.

Stef

Ben Coman

Re: gtdebugger in pharo 5.0

In reply to this post by stepharo

On Sat, Jan 9, 2016 at 4:22 AM, stepharo <[hidden email]> wrote:

This also applies to UPBE. It would be good to get that out the door
matching Pharo 5 without too much rework.

cheers -ben

> I would like to avoid to be forced to use not the latest version of Pharo
> for the mooc.
>
> Such changes are arriving far too late in the release. We do not change the
> debugger itself the day of code freeze.
>
> We decided that the GTDebugger can be included but to me it never meant that
> it should be the default one.
> I think that experts can choose the debugger they want. The newbies don't.
>
> Stef
>
>

CyrilFerlicot

Re: gtdebugger in pharo 5.0

In reply to this post by stepharo

Le 08/01/2016 21:22, stepharo a écrit :

> I'm sorry but this debugger should not be the default one.
> MONDAY we are filming our mooc and we have to explain the debugger and
> personally I do not see the gain:
> - It looks a lot more complex to me and I do not want to have to
> redo all the screenshots
> of our lecture.
> - Just that I have to learn the meaning of small icons.
> - Why do we need a special pane for the evaluator
> - Why there is a type column.
> - Sorry but I'm not convinced about the moldable aspect behind the
> story (no need to argue I know it)
>
> I would like to avoid to be forced to use not the latest version of
> Pharo for the mooc.
>
> Such changes are arriving far too late in the release. We do not change
> the debugger itself the day of code freeze.
>
> We decided that the GTDebugger can be included but to me it never meant
> that it should be the default one.
> I think that experts can choose the debugger they want. The newbies don't.
>
> Stef
>
>

IMO the old debugger is way more intuitive.
When I used the debugger of Eclipse for java I was lost. When I used
Spec debugger I thought "Oh, this is not so hard in fact". And I lose
the feeling with GTDebugger. And the debugger is one of the main source
of interest for newbies.

Maybe we could have a button on the spec Debugger "Switch to GTDebugger"?

--
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France

signature.asc (836 bytes) Download Attachment

stepharo

Re: gtdebugger in pharo 5.0

Thanks for your testimony.

I'm not against GTDebugger per se. I believe that we should have better
tools
but we should take time for building better tools (even if this is two
years that moosers use or not this new debugger).
I would appreciate a process where users can give real feedback and we
can simplify/shape our tools nicely.

Now for the mooc I will not present GTDebugger. So students will not use
Pharo 50

Stef

> Le 08/01/2016 21:22, stepharo a écrit :
>> I'm sorry but this debugger should not be the default one.
>> MONDAY we are filming our mooc and we have to explain the debugger and
>> personally I do not see the gain:
>> - It looks a lot more complex to me and I do not want to have to
>> redo all the screenshots
>> of our lecture.
>> - Just that I have to learn the meaning of small icons.
>> - Why do we need a special pane for the evaluator
>> - Why there is a type column.
>> - Sorry but I'm not convinced about the moldable aspect behind the
>> story (no need to argue I know it)
>>
>> I would like to avoid to be forced to use not the latest version of
>> Pharo for the mooc.
>>
>> Such changes are arriving far too late in the release. We do not change
>> the debugger itself the day of code freeze.
>>
>> We decided that the GTDebugger can be included but to me it never meant
>> that it should be the default one.
>> I think that experts can choose the debugger they want. The newbies don't.
>>
>> Stef
>>
>>
> IMO the old debugger is way more intuitive.
> When I used the debugger of Eclipse for java I was lost. When I used
> Spec debugger I thought "Oh, this is not so hard in fact". And I lose
> the feeling with GTDebugger. And the debugger is one of the main source
> of interest for newbies.
>
> Maybe we could have a button on the spec Debugger "Switch to GTDebugger"?
>

EstebanLM

Re: gtdebugger in pharo 5.0

(re-send because I exceeded limit.)

Hi,

let’s think positive.

the GTDebugger is a step forward… it allow a lot of better interactions and of course, it needs some iterations to make it appealing to everybody.

For instance, I took me 2’ to tweak the debugger presentation and to get this:

(I changed all available… is a trivial task)

and like IMO feels a lot better… and I think is a good compromise between the old and the new.

Reasons to suggest this approach:

- it keeps old approach who(I think) was good (I can see the stack, and the flow feels natural from top to down)

- it preserves “the important” (the code) as central.

- it gives space for adding columns (like the bytecode).

Now… I can understand you want icons with text, and that can be hacked too…

So… can we have an agreement?

Esteban

ps: btw… using GT with Fast Table we can also avoid those annoying paginated lists too

On 09 Jan 2016, at 08:53, stepharo <[hidden email]> wrote:

Thanks for your testimony.

I'm not against GTDebugger per se. I believe that we should have better tools
but we should take time for building better tools (even if this is two years that moosers use or not this new debugger).
I would appreciate a process where users can give real feedback and we can simplify/shape our tools nicely.

Now for the mooc I will not present GTDebugger. So students will not use Pharo 50

Stef

Le 08/01/2016 21:22, stepharo a écrit :
I'm sorry but this debugger should not be the default one.
MONDAY we are filming our mooc and we have to explain the debugger and
personally I do not see the gain:
    - It looks a lot more complex to me and I do not want to have to
redo all the screenshots
    of our lecture.
    - Just that I have to learn the meaning of small icons.
    - Why do we need a special pane for the evaluator
    - Why there is a type column.
    - Sorry but I'm not convinced about the moldable aspect behind the
story (no need to argue I know it)

I would like to avoid to be forced to use not the latest version of
Pharo for the mooc.

Such changes are arriving far too late in the release. We do not change
the debugger itself the day of code freeze.

We decided that the GTDebugger can be included but to me it never meant
that it should be the default one.
I think that experts can choose the debugger they want. The newbies don't.

Stef

IMO the old debugger is way more intuitive.
When I used the debugger of Eclipse for java I was lost. When I used
Spec debugger I thought "Oh, this is not so hard in fact". And I lose
the feeling with GTDebugger. And the debugger is one of the main source
of interest for newbies.

Maybe we could have a button on the spec Debugger "Switch to GTDebugger"?

Tudor Girba-2

Re: gtdebugger in pharo 5.0

Hi,

> On Jan 9, 2016, at 10:43 AM, Esteban Lorenzano <[hidden email]> wrote:
>
> (re-send because I exceeded limit.)
>
> Hi,
>
> let’s think positive.

Thanks :)

> the GTDebugger is a step forward… it allow a lot of better interactions and of course, it needs some iterations to make it appealing to everybody.
> For instance, I took me 2’ to tweak the debugger presentation and to get this:

Exactly :)

We should also remember that it uses GTInspector which should decrease the cost of maintenance for those parts.

> <Screen Shot 2016-01-09 at 09.29.59.png>
>
> (I changed all available… is a trivial task)
>
> and like IMO feels a lot better… and I think is a good compromise between the old and the new.
> Reasons to suggest this approach:
>
> - it keeps old approach who(I think) was good (I can see the stack, and the flow feels natural from top to down)
> - it preserves “the important” (the code) as central.
> - it gives space for adding columns (like the bytecode).

Yes, we played with this last night and we can adopt it for now.

> Now… I can understand you want icons with text, and that can be hacked too…
>
> So… can we have an agreement?
>
> Esteban
>
> ps: btw… using GT with Fast Table we can also avoid those annoying paginated lists too

Yes. I opened an issue for this:
https://pharo.fogbugz.com/f/cases/17362/GTDebugger-should-use-FastTable-to-show-the-stack

Cheers,
Doru

>> On 09 Jan 2016, at 08:53, stepharo <[hidden email]> wrote:
>>
>> Thanks for your testimony.
>>
>> I'm not against GTDebugger per se. I believe that we should have better tools
>> but we should take time for building better tools (even if this is two years that moosers use or not this new debugger).
>> I would appreciate a process where users can give real feedback and we can simplify/shape our tools nicely.
>>
>> Now for the mooc I will not present GTDebugger. So students will not use Pharo 50
>>
>> Stef
>>
>>> Le 08/01/2016 21:22, stepharo a écrit :
>>>> I'm sorry but this debugger should not be the default one.
>>>> MONDAY we are filming our mooc and we have to explain the debugger and
>>>> personally I do not see the gain:
>>>> - It looks a lot more complex to me and I do not want to have to
>>>> redo all the screenshots
>>>> of our lecture.
>>>> - Just that I have to learn the meaning of small icons.
>>>> - Why do we need a special pane for the evaluator
>>>> - Why there is a type column.
>>>> - Sorry but I'm not convinced about the moldable aspect behind the
>>>> story (no need to argue I know it)
>>>>
>>>> I would like to avoid to be forced to use not the latest version of
>>>> Pharo for the mooc.
>>>>
>>>> Such changes are arriving far too late in the release. We do not change
>>>> the debugger itself the day of code freeze.
>>>>
>>>> We decided that the GTDebugger can be included but to me it never meant
>>>> that it should be the default one.
>>>> I think that experts can choose the debugger they want. The newbies don't.
>>>>
>>>> Stef
>>>>
>>>>
>>> IMO the old debugger is way more intuitive.
>>> When I used the debugger of Eclipse for java I was lost. When I used
>>> Spec debugger I thought "Oh, this is not so hard in fact". And I lose
>>> the feeling with GTDebugger. And the debugger is one of the main source
>>> of interest for newbies.
>>>
>>> Maybe we could have a button on the spec Debugger "Switch to GTDebugger"?
>>>
>>
>>
>

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

"Don't give to get. Just give."

Tudor Girba-2

Re: gtdebugger in pharo 5.0

In reply to this post by CyrilFerlicot

Hi,

Could you be specific? What exactly do you find less intuitive? To be able to react, it is useful to get concrete points.

Cheers,
Doru

> On Jan 9, 2016, at 4:23 AM, Ferlicot D. Cyril <[hidden email]> wrote:
>
> Le 08/01/2016 21:22, stepharo a écrit :
>> I'm sorry but this debugger should not be the default one.
>> MONDAY we are filming our mooc and we have to explain the debugger and
>> personally I do not see the gain:
>> - It looks a lot more complex to me and I do not want to have to
>> redo all the screenshots
>> of our lecture.
>> - Just that I have to learn the meaning of small icons.
>> - Why do we need a special pane for the evaluator
>> - Why there is a type column.
>> - Sorry but I'm not convinced about the moldable aspect behind the
>> story (no need to argue I know it)
>>
>> I would like to avoid to be forced to use not the latest version of
>> Pharo for the mooc.
>>
>> Such changes are arriving far too late in the release. We do not change
>> the debugger itself the day of code freeze.
>>
>> We decided that the GTDebugger can be included but to me it never meant
>> that it should be the default one.
>> I think that experts can choose the debugger they want. The newbies don't.
>>
>> Stef
>>
>>
>
> IMO the old debugger is way more intuitive.
> When I used the debugger of Eclipse for java I was lost. When I used
> Spec debugger I thought "Oh, this is not so hard in fact". And I lose
> the feeling with GTDebugger. And the debugger is one of the main source
> of interest for newbies.
>
> Maybe we could have a button on the spec Debugger "Switch to GTDebugger"?
>
> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 165 Avenue Bretagne
> Lille 59000 France
>

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

"Value is always contextual."

kilon.alios

Re: gtdebugger in pharo 5.0

In reply to this post by Ben Coman

Since I am the mainn maintainer of UPBE and pretty much alone, I will have to disagree, I have expressed my dislike for GT tools in the past, I was quite vocal about my dislike about GTPlayground and especially the pages interface of GTInspector.

Yet even though I am the one that usually ends up keep pushing UPBE forward the most, I never said dont include this GT tool because I will have to document it.

As a matter of fact GT people are the rare breed of pharoers , close to extinction level, that bothers documenting its own tools making my job super easy and a matter of porting their blog posts to Pillar.

Also its important to note here that our dear beloved debugger is decades old, maybe just maybe its time to try something new even if we dont like it.

Afterall GT people were quick to adress my problems of Playground like the lack of copy paste in right click menu, the lack of tabs etc. We objected and criticised, they improved . End of story. None complains about the Playground anymore.

Its also important to note that they constantly pushing pharo forward.

On the matters of documentation I will accept zero excuses from this community. If one spent 10 minutes per week, I repeat 10 minutes per week, on contributing to UPBE we would have the following

1) a person even a slow typer, types at least 40 words per minute

2) in 10 minutes one can type 400 words

3) That is one page of UPBE (pdf version) in 10 minutes

4) thats 50 pages per year per person

5) if people who are experienced are at least 10, I think we can find 10 people who understand pharo deeply , thats 500 pages per year

we end up with the conclusion that the UPBE with extremely limited effort and extremely low amount of people would have by now the last 7 years that Pharo is around , 3500 pages of documentation.

But since 10 people is too few and there a lot more judging from the mailing list , I will say 100 people is more realistic which means 35.000 pages or to put it more in perspective , thats the total of 10 UPBE books

I repeat 10 UPBE BOOKS !!!!!

So no no no and NO dont exclude the new debugger because of the effort to document, I respect Stef he and Damien are the ones responsible for the existenve of UPBE and PBE in the first place, they also helped me alot with Dimitri to port many chapters to pharo 4. Plus I love Pillar for documentation its awesome even with its flaws.

But I say that GT people earned my trust, my trust that the have desire and visions to push Pharo forward and I say let them put the Debugger in who is going to hurt , it can be disabled and bring back the old one. Same story with Playground but seriously who bring back the old workspace ?

Let them take the criticism and improve the new debugger, its a new thing of course it will have its flaws. But I dont want a Pharo that works well, I want a Pharo that keeps going forward.

I have not the opportunity to download a new image because of my lack my connection is down and I use my mobile connection to do the minimum because it costs too much.

But even if I heavily dislike the debugger like I did the the Playground I know that GT people will listen and will improve it, for that I have zero doubts because I admire their efforts even when I disagree with them.

On Sat, Jan 9, 2016 at 4:19 AM Ben Coman <[hidden email]> wrote:

On Sat, Jan 9, 2016 at 4:22 AM, stepharo <[hidden email]> wrote:
> I'm sorry but this debugger should not be the default one.
> MONDAY we are filming our mooc and we have to explain the debugger and
> personally I do not see the gain:
> - It looks a lot more complex to me and I do not want to have to redo
> all the screenshots
> of our lecture.
> - Just that I have to learn the meaning of small icons.
> - Why do we need a special pane for the evaluator
> - Why there is a type column.
> - Sorry but I'm not convinced about the moldable aspect behind the story
> (no need to argue I know it)

This also applies to UPBE. It would be good to get that out the door
matching Pharo 5 without too much rework.

cheers -ben

> I would like to avoid to be forced to use not the latest version of Pharo
> for the mooc.
>
> Such changes are arriving far too late in the release. We do not change the
> debugger itself the day of code freeze.
>
> We decided that the GTDebugger can be included but to me it never meant that
> it should be the default one.
> I think that experts can choose the debugger they want. The newbies don't.
>
> Stef
>
>

kilon.alios

Re: gtdebugger in pharo 5.0

Bad math, the correct is

35.000 word are:

I repeat 100 UPBE BOOKS !!!!!

On Sat, Jan 9, 2016 at 11:49 AM Dimitris Chloupis <[hidden email]> wrote:

Since I am the mainn maintainer of UPBE and pretty much alone, I will have to disagree, I have expressed my dislike for GT tools in the past, I was quite vocal about my dislike about GTPlayground and especially the pages interface of GTInspector.

Yet even though I am the one that usually ends up keep pushing UPBE forward the most, I never said dont include this GT tool because I will have to document it.

As a matter of fact GT people are the rare breed of pharoers , close to extinction level, that bothers documenting its own tools making my job super easy and a matter of porting their blog posts to Pillar.

Also its important to note here that our dear beloved debugger is decades old, maybe just maybe its time to try something new even if we dont like it.

Afterall GT people were quick to adress my problems of Playground like the lack of copy paste in right click menu, the lack of tabs etc. We objected and criticised, they improved . End of story. None complains about the Playground anymore.

Its also important to note that they constantly pushing pharo forward.

On the matters of documentation I will accept zero excuses from this community. If one spent 10 minutes per week, I repeat 10 minutes per week, on contributing to UPBE we would have the following

1) a person even a slow typer, types at least 40 words per minute
2) in 10 minutes one can type 400 words
3) That is one page of UPBE (pdf version) in 10 minutes
4) thats 50 pages per year per person
5) if people who are experienced are at least 10, I think we can find 10 people who understand pharo deeply , thats 500 pages per year

we end up with the conclusion that the UPBE with extremely limited effort and extremely low amount of people would have by now the last 7 years that Pharo is around , 3500 pages of documentation.

But since 10 people is too few and there a lot more judging from the mailing list , I will say 100 people is more realistic which means 35.000 pages or to put it more in perspective , thats the total of 10 UPBE books

I repeat 10 UPBE BOOKS !!!!!

So no no no and NO dont exclude the new debugger because of the effort to document, I respect Stef he and Damien are the ones responsible for the existenve of UPBE and PBE in the first place, they also helped me alot with Dimitri to port many chapters to pharo 4. Plus I love Pillar for documentation its awesome even with its flaws.

But I say that GT people earned my trust, my trust that the have desire and visions to push Pharo forward and I say let them put the Debugger in who is going to hurt , it can be disabled and bring back the old one. Same story with Playground but seriously who bring back the old workspace ?

Let them take the criticism and improve the new debugger, its a new thing of course it will have its flaws. But I dont want a Pharo that works well, I want a Pharo that keeps going forward.

I have not the opportunity to download a new image because of my lack my connection is down and I use my mobile connection to do the minimum because it costs too much.

But even if I heavily dislike the debugger like I did the the Playground I know that GT people will listen and will improve it, for that I have zero doubts because I admire their efforts even when I disagree with them.

On Sat, Jan 9, 2016 at 4:19 AM Ben Coman <[hidden email]> wrote:
On Sat, Jan 9, 2016 at 4:22 AM, stepharo <[hidden email]> wrote:
> I'm sorry but this debugger should not be the default one.
> MONDAY we are filming our mooc and we have to explain the debugger and
> personally I do not see the gain:
> - It looks a lot more complex to me and I do not want to have to redo
> all the screenshots
> of our lecture.
> - Just that I have to learn the meaning of small icons.
> - Why do we need a special pane for the evaluator
> - Why there is a type column.
> - Sorry but I'm not convinced about the moldable aspect behind the story
> (no need to argue I know it)

This also applies to UPBE. It would be good to get that out the door
matching Pharo 5 without too much rework.

cheers -ben

> I would like to avoid to be forced to use not the latest version of Pharo
> for the mooc.
>
> Such changes are arriving far too late in the release. We do not change the
> debugger itself the day of code freeze.
>
> We decided that the GTDebugger can be included but to me it never meant that
> it should be the default one.
> I think that experts can choose the debugger they want. The newbies don't.
>
> Stef
>
>

EstebanLM

Re: gtdebugger in pharo 5.0

In reply to this post by EstebanLM

again re-send because of exceed limits with the image (that’s new?)

with a small tweak, texts (AND icons :P):

would that be aceptable for you?

cheers!

Esteban

On 09 Jan 2016, at 09:43, Esteban Lorenzano <[hidden email]> wrote:

(re-send because I exceeded limit.)

Hi,

let’s think positive.
the GTDebugger is a step forward… it allow a lot of better interactions and of course, it needs some iterations to make it appealing to everybody.
For instance, I took me 2’ to tweak the debugger presentation and to get this:

<Screen Shot 2016-01-09 at 09.29.59.png>

(I changed all available… is a trivial task)

and like IMO feels a lot better… and I think is a good compromise between the old and the new.
Reasons to suggest this approach:

- it keeps old approach who(I think) was good (I can see the stack, and the flow feels natural from top to down)
- it preserves “the important” (the code) as central.
- it gives space for adding columns (like the bytecode).

Now… I can understand you want icons with text, and that can be hacked too…

So… can we have an agreement?

Esteban

ps: btw… using GT with Fast Table we can also avoid those annoying paginated lists too

On 09 Jan 2016, at 08:53, stepharo <[hidden email]> wrote:

Thanks for your testimony.

I'm not against GTDebugger per se. I believe that we should have better tools
but we should take time for building better tools (even if this is two years that moosers use or not this new debugger).
I would appreciate a process where users can give real feedback and we can simplify/shape our tools nicely.

Now for the mooc I will not present GTDebugger. So students will not use Pharo 50

Stef

Le 08/01/2016 21:22, stepharo a écrit :
I'm sorry but this debugger should not be the default one.
MONDAY we are filming our mooc and we have to explain the debugger and
personally I do not see the gain:
    - It looks a lot more complex to me and I do not want to have to
redo all the screenshots
    of our lecture.
    - Just that I have to learn the meaning of small icons.
    - Why do we need a special pane for the evaluator
    - Why there is a type column.
    - Sorry but I'm not convinced about the moldable aspect behind the
story (no need to argue I know it)

I would like to avoid to be forced to use not the latest version of
Pharo for the mooc.

Such changes are arriving far too late in the release. We do not change
the debugger itself the day of code freeze.

We decided that the GTDebugger can be included but to me it never meant
that it should be the default one.
I think that experts can choose the debugger they want. The newbies don't.

Stef

IMO the old debugger is way more intuitive.
When I used the debugger of Eclipse for java I was lost. When I used
Spec debugger I thought "Oh, this is not so hard in fact". And I lose
the feeling with GTDebugger. And the debugger is one of the main source
of interest for newbies.

Maybe we could have a button on the spec Debugger "Switch to GTDebugger"?

EstebanLM

Re: gtdebugger in pharo 5.0

you have to confess that with text and icons looks a lot better than the old one :P

On 09 Jan 2016, at 11:01, Esteban Lorenzano <[hidden email]> wrote:

again re-send because of exceed limits with the image (that’s new?)

with a small tweak, texts (AND icons :P):

<Screen Shot 2016-01-09 at 10.59.20.png>

would that be aceptable for you?

cheers!
Esteban

On 09 Jan 2016, at 09:43, Esteban Lorenzano <[hidden email]> wrote:

(re-send because I exceeded limit.)

Hi,

let’s think positive.
the GTDebugger is a step forward… it allow a lot of better interactions and of course, it needs some iterations to make it appealing to everybody.
For instance, I took me 2’ to tweak the debugger presentation and to get this:

<Screen Shot 2016-01-09 at 09.29.59.png>

(I changed all available… is a trivial task)

and like IMO feels a lot better… and I think is a good compromise between the old and the new.
Reasons to suggest this approach:

- it keeps old approach who(I think) was good (I can see the stack, and the flow feels natural from top to down)
- it preserves “the important” (the code) as central.
- it gives space for adding columns (like the bytecode).

Now… I can understand you want icons with text, and that can be hacked too…

So… can we have an agreement?

Esteban

ps: btw… using GT with Fast Table we can also avoid those annoying paginated lists too

On 09 Jan 2016, at 08:53, stepharo <[hidden email]> wrote:

Thanks for your testimony.

I'm not against GTDebugger per se. I believe that we should have better tools
but we should take time for building better tools (even if this is two years that moosers use or not this new debugger).
I would appreciate a process where users can give real feedback and we can simplify/shape our tools nicely.

Now for the mooc I will not present GTDebugger. So students will not use Pharo 50

Stef

Le 08/01/2016 21:22, stepharo a écrit :
I'm sorry but this debugger should not be the default one.
MONDAY we are filming our mooc and we have to explain the debugger and
personally I do not see the gain:
    - It looks a lot more complex to me and I do not want to have to
redo all the screenshots
    of our lecture.
    - Just that I have to learn the meaning of small icons.
    - Why do we need a special pane for the evaluator
    - Why there is a type column.
    - Sorry but I'm not convinced about the moldable aspect behind the
story (no need to argue I know it)

I would like to avoid to be forced to use not the latest version of
Pharo for the mooc.

Such changes are arriving far too late in the release. We do not change
the debugger itself the day of code freeze.

We decided that the GTDebugger can be included but to me it never meant
that it should be the default one.
I think that experts can choose the debugger they want. The newbies don't.

Stef

IMO the old debugger is way more intuitive.
When I used the debugger of Eclipse for java I was lost. When I used
Spec debugger I thought "Oh, this is not so hard in fact". And I lose
the feeling with GTDebugger. And the debugger is one of the main source
of interest for newbies.

Maybe we could have a button on the spec Debugger "Switch to GTDebugger"?

kilon.alios

Re: gtdebugger in pharo 5.0

In reply to this post by EstebanLM

looks lovely

Is there a way to add the new debugger to my existing image ? How I get the new debugger, I downloaded the latest image and is not in it,

On Sat, Jan 9, 2016 at 12:02 PM Esteban Lorenzano <[hidden email]> wrote:

again re-send because of exceed limits with the image (that’s new?)

with a small tweak, texts (AND icons :P):

would that be aceptable for you?

cheers!
Esteban
On 09 Jan 2016, at 09:43, Esteban Lorenzano <[hidden email]> wrote:

(re-send because I exceeded limit.)

Hi,

let’s think positive.
the GTDebugger is a step forward… it allow a lot of better interactions and of course, it needs some iterations to make it appealing to everybody.
For instance, I took me 2’ to tweak the debugger presentation and to get this:

<Screen Shot 2016-01-09 at 09.29.59.png>

(I changed all available… is a trivial task)

and like IMO feels a lot better… and I think is a good compromise between the old and the new.
Reasons to suggest this approach:

- it keeps old approach who(I think) was good (I can see the stack, and the flow feels natural from top to down)
- it preserves “the important” (the code) as central.
- it gives space for adding columns (like the bytecode).

Now… I can understand you want icons with text, and that can be hacked too…

So… can we have an agreement?

Esteban

ps: btw… using GT with Fast Table we can also avoid those annoying paginated lists too

On 09 Jan 2016, at 08:53, stepharo <[hidden email]> wrote:

Thanks for your testimony.

I'm not against GTDebugger per se. I believe that we should have better tools
but we should take time for building better tools (even if this is two years that moosers use or not this new debugger).
I would appreciate a process where users can give real feedback and we can simplify/shape our tools nicely.

Now for the mooc I will not present GTDebugger. So students will not use Pharo 50

Stef

Le 08/01/2016 21:22, stepharo a écrit :
I'm sorry but this debugger should not be the default one.
MONDAY we are filming our mooc and we have to explain the debugger and
personally I do not see the gain:
    - It looks a lot more complex to me and I do not want to have to
redo all the screenshots
    of our lecture.
    - Just that I have to learn the meaning of small icons.
    - Why do we need a special pane for the evaluator
    - Why there is a type column.
    - Sorry but I'm not convinced about the moldable aspect behind the
story (no need to argue I know it)

I would like to avoid to be forced to use not the latest version of
Pharo for the mooc.

Such changes are arriving far too late in the release. We do not change
the debugger itself the day of code freeze.

We decided that the GTDebugger can be included but to me it never meant
that it should be the default one.
I think that experts can choose the debugger they want. The newbies don't.

Stef

IMO the old debugger is way more intuitive.
When I used the debugger of Eclipse for java I was lost. When I used
Spec debugger I thought "Oh, this is not so hard in fact". And I lose
the feeling with GTDebugger. And the debugger is one of the main source
of interest for newbies.

Maybe we could have a button on the spec Debugger "Switch to GTDebugger"?

Tudor Girba-2

Re: gtdebugger in pharo 5.0

In reply to this post by EstebanLM

Hi,

Thanks!

Could you publish the code and then we can iterate over it?

Cheers,
Doru

> On Jan 9, 2016, at 12:02 PM, Esteban Lorenzano <[hidden email]> wrote:
>
> you have to confess that with text and icons looks a lot better than the old one :P
>
>> On 09 Jan 2016, at 11:01, Esteban Lorenzano <[hidden email]> wrote:
>>
>> again re-send because of exceed limits with the image (that’s new?)
>>
>> with a small tweak, texts (AND icons :P):
>>
>>
>> <Screen Shot 2016-01-09 at 10.59.20.png>
>>
>> would that be aceptable for you?
>>
>> cheers!
>> Esteban
>>
>>> On 09 Jan 2016, at 09:43, Esteban Lorenzano <[hidden email]> wrote:
>>>
>>> (re-send because I exceeded limit.)
>>>
>>> Hi,
>>>
>>> let’s think positive.
>>> the GTDebugger is a step forward… it allow a lot of better interactions and of course, it needs some iterations to make it appealing to everybody.
>>> For instance, I took me 2’ to tweak the debugger presentation and to get this:
>>>
>>> <Screen Shot 2016-01-09 at 09.29.59.png>
>>>
>>> (I changed all available… is a trivial task)
>>>
>>> and like IMO feels a lot better… and I think is a good compromise between the old and the new.
>>> Reasons to suggest this approach:
>>>
>>> - it keeps old approach who(I think) was good (I can see the stack, and the flow feels natural from top to down)
>>> - it preserves “the important” (the code) as central.
>>> - it gives space for adding columns (like the bytecode).
>>>
>>> Now… I can understand you want icons with text, and that can be hacked too…
>>>
>>> So… can we have an agreement?
>>>
>>> Esteban
>>>
>>> ps: btw… using GT with Fast Table we can also avoid those annoying paginated lists too
>>>
>>>> On 09 Jan 2016, at 08:53, stepharo <[hidden email]> wrote:
>>>>
>>>> Thanks for your testimony.
>>>>
>>>> I'm not against GTDebugger per se. I believe that we should have better tools
>>>> but we should take time for building better tools (even if this is two years that moosers use or not this new debugger).
>>>> I would appreciate a process where users can give real feedback and we can simplify/shape our tools nicely.
>>>>
>>>> Now for the mooc I will not present GTDebugger. So students will not use Pharo 50
>>>>
>>>> Stef
>>>>
>>>>> Le 08/01/2016 21:22, stepharo a écrit :
>>>>>> I'm sorry but this debugger should not be the default one.
>>>>>> MONDAY we are filming our mooc and we have to explain the debugger and
>>>>>> personally I do not see the gain:
>>>>>> - It looks a lot more complex to me and I do not want to have to
>>>>>> redo all the screenshots
>>>>>> of our lecture.
>>>>>> - Just that I have to learn the meaning of small icons.
>>>>>> - Why do we need a special pane for the evaluator
>>>>>> - Why there is a type column.
>>>>>> - Sorry but I'm not convinced about the moldable aspect behind the
>>>>>> story (no need to argue I know it)
>>>>>>
>>>>>> I would like to avoid to be forced to use not the latest version of
>>>>>> Pharo for the mooc.
>>>>>>
>>>>>> Such changes are arriving far too late in the release. We do not change
>>>>>> the debugger itself the day of code freeze.
>>>>>>
>>>>>> We decided that the GTDebugger can be included but to me it never meant
>>>>>> that it should be the default one.
>>>>>> I think that experts can choose the debugger they want. The newbies don't.
>>>>>>
>>>>>> Stef
>>>>>>
>>>>>>
>>>>> IMO the old debugger is way more intuitive.
>>>>> When I used the debugger of Eclipse for java I was lost. When I used
>>>>> Spec debugger I thought "Oh, this is not so hard in fact". And I lose
>>>>> the feeling with GTDebugger. And the debugger is one of the main source
>>>>> of interest for newbies.
>>>>>
>>>>> Maybe we could have a button on the spec Debugger "Switch to GTDebugger"?
>>>>>
>>>>
>>>>
>>>
>>
>

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

"Speaking louder won't make the point worthier."

12345