Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
January 2016
- 75 participants
- 1435 messages
Re: [Pharo-dev] gtdebugger in pharo 5.0
by Sven Van Caekenberghe
Very nice (also because of the Dark theme ;-)
> On 09 Jan 2016, at 11:01, Esteban Lorenzano <estebanlm(a)gmail.com> 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 <estebanlm(a)gmail.com> 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 <stepharo(a)free.fr> 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"?
>>>>
>>>
>>>
>>
>
Jan. 9, 2016
Re: [Pharo-dev] gtdebugger in pharo 5.0
by Sven Van Caekenberghe
Thanks for this wonderfully positive message !! That is the spirit.
> On 09 Jan 2016, at 10:49, Dimitris Chloupis <kilon.alios(a)gmail.com> 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 <btc(a)openinworld.com> wrote:
> On Sat, Jan 9, 2016 at 4:22 AM, stepharo <stepharo(a)free.fr> 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
> >
> >
>
Jan. 9, 2016
Re: [Pharo-dev] gtdebugger in pharo 5.0
by Dimitris Chloupis
any idea when that will happen ?
On Sat, Jan 9, 2016 at 12:19 PM Tudor Girba <tudor(a)tudorgirba.com> wrote:
> You get it in the Moose image until it gets integrated :).
>
> Doru
>
>
> > On Jan 9, 2016, at 12:11 PM, Dimitris Chloupis <kilon.alios(a)gmail.com>
> wrote:
> >
> > 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 <estebanlm(a)gmail.com>
> 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 <estebanlm(a)gmail.com>
> 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 <stepharo(a)free.fr> 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
>
> "In a world where everything is moving ever faster,
> one might have better chances to win by moving slower."
>
>
>
>
>
>
Jan. 9, 2016
Re: [Pharo-dev] Why pharo is going over squeaksource when saving code?
by Sven Van Caekenberghe
I saw that too, I choked in my coffee ;-)
> On 09 Jan 2016, at 10:07, stepharo <stepharo(a)free.fr> wrote:
>
> may be I'm dreaming this morning but when I saved code in the inbox I saw a query to www.squeaksource.com?
>
> Stef
>
Jan. 9, 2016
Re: [Pharo-dev] gtdebugger in pharo 5.0
by Nicolai Hess
No one said, dont integrale it.
Just not yet as the default Debugger.
Am 09.01.2016 10:51 vorm. schrieb "Dimitris Chloupis" <kilon.alios(a)gmail.com
>:
>
> 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 <btc(a)openinworld.com> wrote:
>>
>> On Sat, Jan 9, 2016 at 4:22 AM, stepharo <stepharo(a)free.fr> 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
>> >
>> >
>>
Jan. 9, 2016
Re: [Pharo-dev] gtdebugger in pharo 5.0
by Nicolai Hess
Am 09.01.2016 11:03 vorm. schrieb "Esteban Lorenzano" <estebanlm(a)gmail.com>:
>
> you have to confess that with text and icons looks a lot better than the
old one :P
>
Yes alot better
>> On 09 Jan 2016, at 11:01, Esteban Lorenzano <estebanlm(a)gmail.com> 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 <estebanlm(a)gmail.com> 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 <stepharo(a)free.fr> 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"?
>>>>>
>>>>
>>>>
>>>
>>
>
Jan. 9, 2016
Re: [Pharo-dev] gtdebugger in pharo 5.0
by Tudor Girba
You get it in the Moose image until it gets integrated :).
Doru
> On Jan 9, 2016, at 12:11 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote:
>
> 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 <estebanlm(a)gmail.com> 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 <estebanlm(a)gmail.com> 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 <stepharo(a)free.fr> 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
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
Jan. 9, 2016
Re: [Pharo-dev] About LayoutFrame>>fractions:offsets:
by Tudor Girba
Hi,
This issue is still pending:
https://pharo.fogbugz.com/f/cases/7077/LayoutFrame-refactoring
Let us fix the Glamour issues and then we can deprecate it.
Cheers,
Doru
> On Jan 9, 2016, at 11:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
>
> Stef,
>
> could you deprecate the use of fractions:offsets: ? It's a nice way of shooting oneself in the foot.
>
> Create a LayoutFrame taking all space:
>
> LayoutFrame fractions: (0@0 corner: 1@1)
>
> right?
>
> Create a layout frame taking all space with an inset of three, so an offset of +3 left and above, and -3 right and bottom:
>
> LayoutFrame fractions: (0@0 corner: 1@1) offsets: (3@3 extent: -3@ -3)
>
> Fail!
>
> See what I mean? You have to forbid the use of a rectangle for offsets!
>
> (Note: I think the easiest API is the one used by Spec and Morphic: Rectangle asLayoutFrame topOffset: / bottomOffset ...)
>
> Thierry
>
> Le 09/01/2016 09:56, stepharo a écrit :
>> Here is the new class comments I'm trying to write.
>> I hope that it will help people to understand the circumstances under
>> which they should use fractions:offset: creation API.
>>
>>
>>
>> I define a transformation frame relative to some rectangle. I'm basic
>> data structure used for graphics.
>> I represent two groups of distances:
>> - The fractional distance (between 0 and 1) to place the morph in its
>> owner's bounds
>> - Fixed pixel offset to apply after fractional positioning (e.g., "10
>> pixel right of the center of the owner")
>>
>> !! API usage
>> It is important to understand that it is better to use the fine grained
>> API using elementary distances (bottomFraction:, bottomOffset:,
>> leftFraction: ....) than the ones (historical) using points and
>> rectangles (fractions:offsets:)
>>
>> The reason is that the old API (fractions:offsets:) is only interesting
>> if you already have a rectangle and points at hand. If you need to
>> create new ones, then they are created for nothing because they will be
>> destructured to extract their information to be feed into the layoutFrame.
>> So please do not blindly copy and paste code!
>>
>> Example:
>> Favor
>>
>> (LayoutFrame identity
>> leftFraction: 0;
>> yourself);
>>
>> (LayoutFrame identity
>> leftFraction: 0.5;
>> rightFraction: 0.95;
>>
>> (LayoutFrame identity
>> topOffset: topHeight;
>> bottomFraction: 0;
>> bottomOffset: self buttonsBarHeight;
>> leftOffset: -1;
>> rightOffset: 1)
>> over
>>
>> (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1))
>>
>> because you are creating for nothing a new rectangle and some points.
>>
>>
>>
>> !! Implementation
>>
>> Instance variables:
>> The fractional distance (between 0 and 1) to place the morph in its
>> owner's bounds is represented by the following instance variables:
>> leftFraction
>> topFraction
>> rightFraction
>> bottomFraction <Float>
>>
>>
>> Fixed pixel offset to apply after fractional positioning (e.g., "10
>> pixel right of the center of the owner") is represented by the
>> following instance variables:
>> leftOffset
>> topOffset
>> rightOffset
>> bottomOffset <Integer>
>>
>>
>
>
--
www.tudorgirba.com
www.feenk.com
"The coherence of a trip is given by the clearness of the goal."
Jan. 9, 2016
Re: [Pharo-dev] gtdebugger in pharo 5.0
by Tudor Girba
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 <estebanlm(a)gmail.com> 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 <estebanlm(a)gmail.com> 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 <estebanlm(a)gmail.com> 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 <stepharo(a)free.fr> 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."
Jan. 9, 2016
Re: [Pharo-dev] gtdebugger in pharo 5.0
by Dimitris Chloupis
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 <estebanlm(a)gmail.com>
wrote:
> again re-send because of exceed limits with the image (thatâs new?)
>
> with a small tweak, texts (AND icons :P):
>
>
> [image: 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 <estebanlm(a)gmail.com> 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 <stepharo(a)free.fr> 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"?
>
>
>
>
>
Jan. 9, 2016