January 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ifError: implementation is bad

by Denis Kudriashov

2016-01-08 21:17 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)icloud.com>: > Hi, > > 8. 1. 2016 v 17:11, Tudor Girba <tudor(a)tudorgirba.com>: > > > Hi, > > > > Denis says that right now, to use ifError: you do: > > > > [...] ifError: [:msg :rcv | â¦ ] > > > > and he would like to write this: > > > > [...] ifError: [:error | â¦ ] > > But for this we have on:do: message, right? > Do we need ifError:? > It is nice convenient method for the case when you don't care what exact error happens. It is very useful for scripting. sum := 0. #(1 asd 4534 5423 sdfs) do: [:each | [sum := sum + each] ifError: []] Actually I never use argument version of block. But it definitely should be error instance and not of one of it properties.

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Mariano Martinez Peck

I wanted to say that I also like more the distribution that Esteban built instead of the original one of GT Debugger. So.. +1 for that. And yes, I also like the text besides the buttons since unfortunately the buttons are not extremely intuitive. +1 for that too. Stef, as for the bydecode debugger, if I remember, you had to explicitly switch to a bytecode debugger. In the normal debugger a normal user will use, the bytecode pane was not there. On Sat, Jan 9, 2016 at 11:08 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Dont do it for me , what I did with ChronosManager is only the tip of the > iceberg, I will be redesigning the whole Pharo GUI from scratch. After I > release ChronosManager 0.2 my next victim will be Nautilus, then inspector > and finally debugger. So I will be building my own GUI for the debugger > anyway, in similar style to ChronosManager, completely custom made , static > and icon based. It wont happen tommorow but slowly and steadily I will > make my own Pharo GUI, obviously radically different to what we have now. > > I merely mentioned this to represent a voice of reason over icon based > interfaces that dominate software market anyway. > > On Sat, Jan 9, 2016 at 3:49 PM Christophe Demarey < > Christophe.Demarey(a)inria.fr> wrote: > >> 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"? >>> >>> >>> >>> >>> >>> -- Mariano http://marianopeck.wordpress.com

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Esteban Lorenzano

thatâs just an example, default debugger does not have it :) I will commit my changes as soon as I can sit and clean itâ¦ the actions need to be changed to make explicit if you want text/icon/both so we can keep all behaviours (and keep compatible). Esteban > On 09 Jan 2016, at 14:08, stepharo <stepharo(a)free.fr> wrote: > > 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: >> >> <Mail Attachment.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 < <mailto:stepharo@free.fr>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

Re: [Pharo-dev] ifError: implementation is bad

by Denis Kudriashov

2016-01-08 21:11 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Denis says that right now, to use ifError: you do: > > [...] ifError: [:msg :rcv | â¦ ] > > and he would like to write this: > > [...] ifError: [:error | â¦ ] > > I agree with him. The problem is that this might generate a bit of ripple > effects in external code. This is when Stephan came in and said that if we > would have a way to investigate all external repositories that are open we > could do such refactorings more boldly. > > Does it make more sense now? Or did I get it wrong? > Exactly Tudor. My cry was about why man who implement it decides to deincapsulate error state.

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Dimitris Chloupis

Dont do it for me , what I did with ChronosManager is only the tip of the iceberg, I will be redesigning the whole Pharo GUI from scratch. After I release ChronosManager 0.2 my next victim will be Nautilus, then inspector and finally debugger. So I will be building my own GUI for the debugger anyway, in similar style to ChronosManager, completely custom made , static and icon based. It wont happen tommorow but slowly and steadily I will make my own Pharo GUI, obviously radically different to what we have now. I merely mentioned this to represent a voice of reason over icon based interfaces that dominate software market anyway. On Sat, Jan 9, 2016 at 3:49 PM Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > 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] 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