- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GTDebugger (case 17341 Integrate GTools version 3.3)

by stepharo

Why do we need thisContext? Le 8/1/16 23:16, Nicolai Hess a Ã©crit : > > > 2016-01-08 22:55 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com > <mailto:nicolaihess@gmail.com>>: > > > > 2016-01-08 22:48 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com > <mailto:nicolaihess@gmail.com>>: > > > > 2016-01-08 16:43 GMT+01:00 Andrei Chis > <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>>: > > Hi Nicolai, > > Thanks for the feedback. > Some issues I'll manage to fix until we integrate. > For those that I do not manage please open bug reports. > > On Thu, Jan 7, 2016 at 9:13 PM, Nicolai Hess > <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: > > Some feedback on GTDebugger > > - The inspector pane is great, we can inspect, > evaluate code, and easily show/ inspect the code (for > thisContext). > although the evaluator pane has a bad text mode (for > the thisContext). > > > Can you give me more details? Maybe it's obvious but I'm > missing what's wrong :) > > > Hm, I can not reproduce it anymore. > > > Ok, now it happened again. See screenshot, the thisContext > evaluator pane is wrong. And it does > not go away (every debugger now shows this text, even if I debug a > totally different method) > > > How to reporduce: > > select some code and debugIt > in the debugger select > thisContex > select the Evaluator pane, now select the Source pane > close debugger > open debugger again > select Evaluator pane > -> it will always show the last source pane text in the Evaluator pane > > > > > Cheers, > Andrei > > - I think the buttons are too small and the icon for > "stop over" is misleading, it looks like a "step out" > - the shortcuts (neither ctrl+t nor cmd+t) aren't working > - I find it totally annoying and useless that the > context pane inspector scrolls away if you select a > value in > the rightmost pane. The context inspector should be > fixed. > - I really miss the "List Methods using 'varname'/List > Methods storing into 'varname' > - the stacklist entry for block closures prints the > block closure code, this is confusing (too much text > for such a small widget). > > nicolai > > > > >

Jan. 9, 2016

Re: [Pharo-dev] GTDebugger (case 17341 Integrate GTools version 3.3)

by stepharo

I like that you report bug and not me. Le 8/1/16 22:55, Nicolai Hess a Ã©crit : > > > 2016-01-08 22:48 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com > <mailto:nicolaihess@gmail.com>>: > > > > 2016-01-08 16:43 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com > <mailto:chisvasileandrei@gmail.com>>: > > Hi Nicolai, > > Thanks for the feedback. > Some issues I'll manage to fix until we integrate. > For those that I do not manage please open bug reports. > > On Thu, Jan 7, 2016 at 9:13 PM, Nicolai Hess > <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: > > Some feedback on GTDebugger > > - The inspector pane is great, we can inspect, evaluate > code, and easily show/ inspect the code (for thisContext). > although the evaluator pane has a bad text mode (for the > thisContext). > > > Can you give me more details? Maybe it's obvious but I'm > missing what's wrong :) > > > Hm, I can not reproduce it anymore. > > > Ok, now it happened again. See screenshot, the thisContext evaluator > pane is wrong. And it does > not go away (every debugger now shows this text, even if I debug a > totally different method) > > > > > Cheers, > Andrei > > - I think the buttons are too small and the icon for "stop > over" is misleading, it looks like a "step out" > - the shortcuts (neither ctrl+t nor cmd+t) aren't working > - I find it totally annoying and useless that the context > pane inspector scrolls away if you select a value in > the rightmost pane. The context inspector should be fixed. > - I really miss the "List Methods using 'varname'/List > Methods storing into 'varname' > - the stacklist entry for block closures prints the block > closure code, this is confusing (too much text for such a > small widget). > > nicolai > > > >

Jan. 9, 2016

Re: [Pharo-dev] GTDebugger (case 17341 Integrate GTools version 3.3)

by stepharo

+1 Stef Le 7/1/16 21:13, Nicolai Hess a Ã©crit : > Some feedback on GTDebugger > > - The inspector pane is great, we can inspect, evaluate code, and > easily show/ inspect the code (for thisContext). > although the evaluator pane has a bad text mode (for the thisContext). > - I think the buttons are too small and the icon for "stop over" is > misleading, it looks like a "step out" > - the shortcuts (neither ctrl+t nor cmd+t) aren't working > - I find it totally annoying and useless that the context pane > inspector scrolls away if you select a value in > the rightmost pane. The context inspector should be fixed. > - I really miss the "List Methods using 'varname'/List Methods storing > into 'varname' > - the stacklist entry for block closures prints the block closure > code, this is confusing (too much text for such a small widget). > > nicolai

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Christophe Demarey

Hi, It is impossible to satisfy everyone. What I would suggest is to have text + icons as default and a preference to only have icons. Christophe Le 9 janv. 2016 Ã 14:30, Dimitris Chloupis a Ã©crit : > Which brings us to my question, where did tooltips go ? Squeak had them and then they were gone in pharo. > > Personally I dont see the point of having an icon to have text next to it. Seriously how much time it takes you to learn what each icon does ? > > and the debugger is not exactly a tool you will be using once per month, so the chance of forgeting gets pretty low after the first week. > > So my vote goes to get rid of text, it wastes valuable gui space in an environment where windows fight for space. And even on my 27'' monitor I rather have as compact as possible GUI. > > On Sat, Jan 9, 2016 at 3:05 PM stepharo <stepharo(a)free.fr> wrote: > > > Le 9/1/16 11:01, Esteban Lorenzano a Ã©crit : >> again re-send because of exceed limits with the image (thatâs new?) >> >> with a small tweak, texts (AND icons :P): > > And text. I asked that during two years in GT but I was told it was not possible. > Like that I do not have to learn these icons > What is the Where is? > >> >> >> <PiÃ¨ce jointe Mail.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] Why pharo is going over squeaksource when saving code?

by Thierry Goubier

Le 9 janv. 2016 2:06 PM, "Dimitris Chloupis" <kilon.alios(a)gmail.com> a Ã©crit : > > why it has to check for version conflicts ? once I tell pharo to install a package thats what I want it to do. Is this practice really necessary ? This is because Monticello needs to check all repositories to choose a version number higher by one to all version numbers of that package in all repositories. Of course, this could fail if you don't check all mc repositories in the whole world... Of course, this has no meaning for gitfiletree repositories... Thierry > On Sat, Jan 9, 2016 at 2:58 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> it is a combination of 2 things: the repo must 1st be defined and used by a package, then there is this odd behaviour of checking all repos for version conflicts. >> >> so it depends on what you have loaded. >> >> > On 09 Jan 2016, at 12:34, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >> > >> > eeeehhh that was happening forever at least the last 2 years I am around. How come you guys just noticed ? >> > >> > On Sat, Jan 9, 2016 at 1:01 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > 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 Dimitris Chloupis

Which brings us to my question, where did tooltips go ? Squeak had them and then they were gone in pharo. Personally I dont see the point of having an icon to have text next to it. Seriously how much time it takes you to learn what each icon does ? and the debugger is not exactly a tool you will be using once per month, so the chance of forgeting gets pretty low after the first week. So my vote goes to get rid of text, it wastes valuable gui space in an environment where windows fight for space. And even on my 27'' monitor I rather have as compact as possible GUI. On Sat, Jan 9, 2016 at 3:05 PM stepharo <stepharo(a)free.fr> wrote: > > > Le 9/1/16 11:01, Esteban Lorenzano a Ã©crit : > > again re-send because of exceed limits with the image (thatâs new?) > > with a small tweak, texts (AND icons :P): > > > And text. I asked that during two years in GT but I was told it was not > possible. > Like that I do not have to learn these icons > What is the Where is? > > > > > 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 Christophe Demarey

Not yet tested but looks good. I just noticed it misses the "run to here" action. Le 9 janv. 2016 Ã 11:01, Esteban Lorenzano a Ã©crit : > 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] Why pharo is going over squeaksource when saving code?

by Dimitris Chloupis

Slow is definetly not what your are, neither stupid because pharo will not be in a state that it is and neither slow to implement things because pharo would not be so rapidly moving forward as it is. But then by using smalltalk you basically cheat , but thats our common secret ,no need to get out of this community ;) On Sat, Jan 9, 2016 at 3:04 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > why it has to check for version conflicts ? once I tell pharo to install a > package thats what I want it to do. Is this practice really necessary ? > > On Sat, Jan 9, 2016 at 2:58 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> it is a combination of 2 things: the repo must 1st be defined and used by >> a package, then there is this odd behaviour of checking all repos for >> version conflicts. >> >> so it depends on what you have loaded. >> >> > On 09 Jan 2016, at 12:34, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> > >> > eeeehhh that was happening forever at least the last 2 years I am >> around. How come you guys just noticed ? >> > >> > On Sat, Jan 9, 2016 at 1:01 PM Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> > 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 stepharo

Can you remove this useless _stack top and _thisContext? Who needs that? And also the bytecode and also the Step glamour that freezes by image and the Step petitParser So you see what I mean? Something that normal people can use...

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by stepharo

Why do we get bytecodes? Do you think that normal developpers do not care about bytecodes? Do you want me to show that to students? Seriously? Stef > > 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 <stepharo(a)free.fr >> <mailto:stepharo@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