August 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Nautilus questions

by stepharo

> > Le 20 aoÃ»t 2015 09:15, "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> a Ã©crit : > > > > For example why protocol get the same space than method. We could > split the protocol by half and use the space for > > soemthing useful. > > Protocol names can be long... > yes but 99% of the time you do not care. And methods are way more important. In fact protocol could just the tag (as in the catalog browser) after the method names. Stef > > > > > I would like the coding area to expand a bit when a method is too long. > > I do it all the time by hand. > > Yes, especially with Seaside renderOn: > > Phil > > > > > Stef > > > > > > Le 19/8/15 13:13, Thierry Goubier a Ã©crit : > >> > >> Hitting send too early :( > >> > >> 2015-08-19 11:59 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>>: > >>> > >>> > >>>> On 19 Aug 2015, at 11:50, Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>> wrote: > >>>> > >>>>> > >>>>> On 19 Aug 2015, at 11:44, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > >>>>> > >>>>>> <Screen Shot 2015-08-19 at 11.10.41.png> > >>>>>> > >>>>>> â¦ but arriving to it is not so easy. > >>>>>> > >>>>>> In conclusion: We are doing some right steps. It is not > finished, but we are not going to go back to older way :) > >>>>> > >>>>> > >>>>> Hi Esteban, > >>>>> > >>>>> My opinion is that you're still tied a lot to the Smalltalk 80's > way... Which is good: someone coming from 1980 would be able to use > Nautilus ;) > >>>>> > >>>>> My critics on that design: the tabs are nice and certainly help > see that a class has a class side. Overall look is more up to date. > Tabs headers, scroll bars, etc... take far too much space: work area > (the code area) is 39% of overall window size, and 68% counting in the > context (package, class, protocol and method) (Numbers are worse on a > small window, of course, but I guess some do work on small screens). > >>>>> > >>>>> It will be nice to see simpler / cleaner Nautilus code coming > along :) > >>>> > >>>> > >>>> yes, of course you are right :) > >>>> the GTools guys are working in a complete replacement, and Iâm > sure it will be a lot betterâ¦ but we will always need a backdoorâ¦ and > I would like to have a good browser even as a backdoor. > >> > >> I'm certainly looking forward for the GT-based system browser > results, while probably I won't be using it; some of the design / > implementation choices of the GT tools just don't fit the way I work, > and I feel down by just looking at how clumsy and slow I become when > using them. > >>>> > >>>> (also, our philosophy is incremental: we improve what we have > while we wait for the break-thru improvements) > >> > >> Agreed. I still miss a bit the OmniBrowser I started Pharo with... > Especially the code regularity and architecture. > >>>> > >>>> > >>>> Esteban > >>>> > >>>> ps: for me the âcode areaâ is not equivalent to the âwork areaâ: > I spend much more time understanding a problem than coding it, and for > that a view of the method *in the context* is better) > >> > >> That's why I added the 68% result: I do agree that the context > matter; I still think that the overhead is too high. > >> > >>> > >>> > >>> for example: I try your alt browser time to time, because I find > it has some good ideas. > >>> But since my workflow is usually: I dig a package, then I see the > classes inside and try to figure out how they work together, then I > read the comments, try to find examples, testsâ¦ then I finally go to > the method level, and even that often with an eye into the class it > belongs and even the packageâ¦ so the AltBrowser is useless for meâ¦ it > is really not confortable for me to useâ¦ and yes, it has a bigger code > area, but that is not really relevant (for me). > >>> â¦ and the traditional browser adapts a lot better to that way of > doing. > >> > >> > >> I think I more or less do the same, but with a slightly different > approach, with for example a lot of scoping (to a class, to a package, > implementors, senders, finder). I especially rely on the fact that I > stay in the browser task model (but with multiple windows) all the > time while doing that; I don't have to deal with disparate tools > (Spotter, Finder, MessageList). > >> > >> I also like the fact I can see both class and instance side methods > at the same time... > >> > >>> > >>> Nowâ¦ real question is: I work that way because fits better my > mind-model or my mind-model fits what the browser provides me? well, > who knowsâ¦ but back in my java days I also was using the âjava > browsing perspectiveâ of Eclipse, who resembles a Smalltalk browser. > >> > >> > >> The good question we have here is that our > search/exploration/understanding strategies are different, but based > on the same building blocks... So there is some Moldable issue there > as per the GT group, but not inside the tool as they are currently > doing, instead the tool itself has to be moldable (or what is the tool). > >> > >> Now, I'm so attuned to the Alt Browser tree view that I prefer it > in any case... even to the point that I can do short and fast > smalltalk edits directly on github through the web interface. > >> > >> Thierry > >> > >>> > >>> Esteban > >>> > >>>> > >>>>> > >>>>> Thierry > >>> > >>> > >> > > >

Aug. 20, 2015

Re: [Pharo-dev] Nautilus questions

by stepharo

Le 20/8/15 09:49, Franck Warlouzet a Ã©crit : > Maybe there is something to do with line numbers in the code area for > the assistant. > Something like : > - No ctiric, do not show anything > - Critic to show about a line -> activate the line numbers and put a > warning on this line in the left column. yes > > Franck > > ------------------------------------------------------------------------ > Date: Thu, 20 Aug 2015 09:13:09 +0200 > From: stepharo(a)free.fr > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] Nautilus questions > > Sorry but reading code is really important and now assistant is taking > too much space. > And your proposal does not take into account hierarchy and I use it > all the time. > The same way we use all the time variables. > > Stef > > Le 19/8/15 11:50, Esteban Lorenzano a Ã©crit : > > > On 19 Aug 2015, at 11:44, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> > wrote: > > <Screen Shot 2015-08-19 at 11.10.41.png> > > â¦ but arriving to it is not so easy. > > In conclusion: We are doing some right steps. It is not > finished, but we are not going to go back to older way :) > > > Hi Esteban, > > My opinion is that you're still tied a lot to the Smalltalk > 80's way... Which is good: someone coming from 1980 would be > able to use Nautilus ;) > > My critics on that design: the tabs are nice and certainly > help see that a class has a class side. Overall look is more > up to date. Tabs headers, scroll bars, etc... take far too > much space: work area (the code area) is 39% of overall window > size, and 68% counting in the context (package, class, > protocol and method) (Numbers are worse on a small window, of > course, but I guess some do work on small screens). > > It will be nice to see simpler / cleaner Nautilus code coming > along :) > > > yes, of course you are right :) > the GTools guys are working in a complete replacement, and Iâm > sure it will be a lot betterâ¦ but we will always need a backdoorâ¦ > and I would like to have a good browser even as a backdoor. > (also, our philosophy is incremental: we improve what we have > while we wait for the break-thru improvements) > > Esteban > > ps: for me the âcode areaâ is not equivalent to the âwork areaâ: I > spend much more time understanding a problem than coding it, and > for that a view of the method *in the context* is better) > > > Thierry > > >

Aug. 20, 2015

Re: [Pharo-dev] Nautilus questions

by Franck Warlouzet

Maybe there is something to do with line numbers in the code area for the assistant. Something like : - No ctiric, do not show anything - Critic to show about a line -> activate the line numbers and put a warning on this line in the left column. Franck Date: Thu, 20 Aug 2015 09:13:09 +0200 From: stepharo(a)free.fr To: pharo-dev(a)lists.pharo.org Subject: Re: [Pharo-dev] Nautilus questions Sorry but reading code is really important and now assistant is taking too much space. And your proposal does not take into account hierarchy and I use it all the time. The same way we use all the time variables. Stef Le 19/8/15 11:50, Esteban Lorenzano a Ã©crit : On 19 Aug 2015, at 11:44, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: <Screen Shot 2015-08-19 at 11.10.41.png> â¦ but arriving to it is not so easy. In conclusion: We are doing some right steps. It is not finished, but we are not going to go back to older way :) Hi Esteban, My opinion is that you're still tied a lot to the Smalltalk 80's way... Which is good: someone coming from 1980 would be able to use Nautilus ;) My critics on that design: the tabs are nice and certainly help see that a class has a class side. Overall look is more up to date. Tabs headers, scroll bars, etc... take far too much space: work area (the code area) is 39% of overall window size, and 68% counting in the context (package, class, protocol and method) (Numbers are worse on a small window, of course, but I guess some do work on small screens). It will be nice to see simpler / cleaner Nautilus code coming along :) yes, of course you are right :) the GTools guys are working in a complete replacement, and Iâm sure it will be a lot betterâ¦ but we will always need a backdoorâ¦ and I would like to have a good browser even as a backdoor. (also, our philosophy is incremental: we improve what we have while we wait for the break-thru improvements) Esteban ps: for me the âcode areaâ is not equivalent to the âwork areaâ: I spend much more time understanding a problem than coding it, and for that a view of the method *in the context* is better) Thierry

Aug. 20, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50249 Home: https://github.com/pharo-project/pharo-core

Aug. 20, 2015

[pharo-project/pharo-core] 4bca68: 50249

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 4bca68a4099599934cd08195ee2e4d0a986f1d84 https://github.com/pharo-project/pharo-core/commit/4bca68a4099599934cd08195… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-20 (Thu, 20 Aug 2015) Changed paths: M ConfigurationOfNautilusGroupAutoBuilder.package/ConfigurationOfNautilusGroupAutoBuilder.class/instance/symbolic versions/stable_.st A ConfigurationOfNautilusGroupAutoBuilder.package/ConfigurationOfNautilusGroupAutoBuilder.class/instance/versions/version11_.st M Flashback-Decompiler.package/FBDDecompiler.class/instance/data flow instructions/skipTemps_.st M Kernel.package/CompiledMethod.class/class/class initialization/initialize.st M Kernel.package/Date.class/instance/utils/addMonths_.st M NautilusGroupAutoBuilder.package/LoadedPackagesGroupCreatingCodeProvider.class/class/public access/configurationName_versionString_projectName_.st M NautilusGroupAutoBuilder.package/extension/CatalogBrowser/instance/onInstallAndCreateGroupFrom_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50248.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50249.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50248.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50249.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50249 16250 Activate new Encoders https://pharo.fogbugz.com/f/cases/16250 16295 Update NautilusGroupAutoBuilder https://pharo.fogbugz.com/f/cases/16295 16270 Rewrite ifTrue:ifFalse: using min: in Date>>#addMonths: https://pharo.fogbugz.com/f/cases/16270 http://files.pharo.org/image/50/50249.zip

Aug. 20, 2015

Re: [Pharo-dev] Nautilus questions

by phil＠highoctane.be

Le 20 aoÃ»t 2015 09:15, "stepharo" <stepharo(a)free.fr> a Ã©crit : > > For example why protocol get the same space than method. We could split the protocol by half and use the space for > soemthing useful. Protocol names can be long... > > I would like the coding area to expand a bit when a method is too long. > I do it all the time by hand. Yes, especially with Seaside renderOn: Phil > > Stef > > > Le 19/8/15 13:13, Thierry Goubier a Ã©crit : >> >> Hitting send too early :( >> >> 2015-08-19 11:59 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>> >>> >>>> On 19 Aug 2015, at 11:50, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>>> >>>>> On 19 Aug 2015, at 11:44, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>>>> >>>>>> <Screen Shot 2015-08-19 at 11.10.41.png> >>>>>> >>>>>> â¦ but arriving to it is not so easy. >>>>>> >>>>>> In conclusion: We are doing some right steps. It is not finished, but we are not going to go back to older way :) >>>>> >>>>> >>>>> Hi Esteban, >>>>> >>>>> My opinion is that you're still tied a lot to the Smalltalk 80's way... Which is good: someone coming from 1980 would be able to use Nautilus ;) >>>>> >>>>> My critics on that design: the tabs are nice and certainly help see that a class has a class side. Overall look is more up to date. Tabs headers, scroll bars, etc... take far too much space: work area (the code area) is 39% of overall window size, and 68% counting in the context (package, class, protocol and method) (Numbers are worse on a small window, of course, but I guess some do work on small screens). >>>>> >>>>> It will be nice to see simpler / cleaner Nautilus code coming along :) >>>> >>>> >>>> yes, of course you are right :) >>>> the GTools guys are working in a complete replacement, and Iâm sure it will be a lot betterâ¦ but we will always need a backdoorâ¦ and I would like to have a good browser even as a backdoor. >> >> I'm certainly looking forward for the GT-based system browser results, while probably I won't be using it; some of the design / implementation choices of the GT tools just don't fit the way I work, and I feel down by just looking at how clumsy and slow I become when using them. >>>> >>>> (also, our philosophy is incremental: we improve what we have while we wait for the break-thru improvements) >> >> Agreed. I still miss a bit the OmniBrowser I started Pharo with... Especially the code regularity and architecture. >>>> >>>> >>>> Esteban >>>> >>>> ps: for me the âcode areaâ is not equivalent to the âwork areaâ: I spend much more time understanding a problem than coding it, and for that a view of the method *in the context* is better) >> >> That's why I added the 68% result: I do agree that the context matter; I still think that the overhead is too high. >> >>> >>> >>> for example: I try your alt browser time to time, because I find it has some good ideas. >>> But since my workflow is usually: I dig a package, then I see the classes inside and try to figure out how they work together, then I read the comments, try to find examples, testsâ¦ then I finally go to the method level, and even that often with an eye into the class it belongs and even the packageâ¦ so the AltBrowser is useless for meâ¦ it is really not confortable for me to useâ¦ and yes, it has a bigger code area, but that is not really relevant (for me). >>> â¦ and the traditional browser adapts a lot better to that way of doing. >> >> >> I think I more or less do the same, but with a slightly different approach, with for example a lot of scoping (to a class, to a package, implementors, senders, finder). I especially rely on the fact that I stay in the browser task model (but with multiple windows) all the time while doing that; I don't have to deal with disparate tools (Spotter, Finder, MessageList). >> >> I also like the fact I can see both class and instance side methods at the same time... >> >>> >>> Nowâ¦ real question is: I work that way because fits better my mind-model or my mind-model fits what the browser provides me? well, who knowsâ¦ but back in my java days I also was using the âjava browsing perspectiveâ of Eclipse, who resembles a Smalltalk browser. >> >> >> The good question we have here is that our search/exploration/understanding strategies are different, but based on the same building blocks... So there is some Moldable issue there as per the GT group, but not inside the tool as they are currently doing, instead the tool itself has to be moldable (or what is the tool). >> >> Now, I'm so attuned to the Alt Browser tree view that I prefer it in any case... even to the point that I can do short and fast smalltalk edits directly on github through the web interface. >> >> Thierry >> >>> >>> Esteban >>> >>>> >>>>> >>>>> Thierry >>> >>> >> >

Aug. 20, 2015

Re: [Pharo-dev] Nautilus questions

by stepharo

For example why protocol get the same space than method. We could split the protocol by half and use the space for soemthing useful. I would like the coding area to expand a bit when a method is too long. I do it all the time by hand. Stef Le 19/8/15 13:13, Thierry Goubier a Ã©crit : > Hitting send too early :( > > 2015-08-19 11:59 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>>: > > >> On 19 Aug 2015, at 11:50, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> >>> >>> On 19 Aug 2015, at 11:44, Thierry Goubier >>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> >>> wrote: >>> >>> <Screen Shot 2015-08-19 at 11.10.41.png> >>> >>> â¦ but arriving to it is not so easy. >>> >>> In conclusion: We are doing some right steps. It is not >>> finished, but we are not going to go back to older way :) >>> >>> >>> Hi Esteban, >>> >>> My opinion is that you're still tied a lot to the Smalltalk 80's >>> way... Which is good: someone coming from 1980 would be able to >>> use Nautilus ;) >>> >>> My critics on that design: the tabs are nice and certainly help >>> see that a class has a class side. Overall look is more up to >>> date. Tabs headers, scroll bars, etc... take far too much space: >>> work area (the code area) is 39% of overall window size, and 68% >>> counting in the context (package, class, protocol and method) >>> (Numbers are worse on a small window, of course, but I guess >>> some do work on small screens). >>> >>> It will be nice to see simpler / cleaner Nautilus code coming >>> along :) >> >> yes, of course you are right :) >> the GTools guys are working in a complete replacement, and Iâm >> sure it will be a lot betterâ¦ but we will always need a backdoorâ¦ >> and I would like to have a good browser even as a backdoor. > > I'm certainly looking forward for the GT-based system browser results, > while probably I won't be using it; some of the design / > implementation choices of the GT tools just don't fit the way I work, > and I feel down by just looking at how clumsy and slow I become when > using them. > >> (also, our philosophy is incremental: we improve what we have >> while we wait for the break-thru improvements) > > Agreed. I still miss a bit the OmniBrowser I started Pharo with... > Especially the code regularity and architecture. > >> >> Esteban >> >> ps: for me the âcode areaâ is not equivalent to the âwork areaâ: >> I spend much more time understanding a problem than coding it, >> and for that a view of the method *in the context* is better) > > That's why I added the 68% result: I do agree that the context matter; > I still think that the overhead is too high. > > > for example: I try your alt browser time to time, because I find > it has some good ideas. > But since my workflow is usually: I dig a package, then I see the > classes inside and try to figure out how they work together, then > I read the comments, try to find examples, testsâ¦ then I finally > go to the method level, and even that often with an eye into the > class it belongs and even the packageâ¦ so the AltBrowser is > useless for meâ¦ it is really not confortable for me to useâ¦ and > yes, it has a bigger code area, but that is not really relevant > (for me). > â¦ and the traditional browser adapts a lot better to that way of > doing. > > > I think I more or less do the same, but with a slightly different > approach, with for example a lot of scoping (to a class, to a package, > implementors, senders, finder). I especially rely on the fact that I > stay in the browser task model (but with multiple windows) all the > time while doing that; I don't have to deal with disparate tools > (Spotter, Finder, MessageList). > > I also like the fact I can see both class and instance side methods at > the same time... > > Nowâ¦ real question is: I work that way because fits better my > mind-model or my mind-model fits what the browser provides me? > well, who knowsâ¦ but back in my java days I also was using the > âjava browsing perspectiveâ of Eclipse, who resembles a Smalltalk > browser. > > > The good question we have here is that our > search/exploration/understanding strategies are different, but based > on the same building blocks... So there is some Moldable issue there > as per the GT group, but not inside the tool as they are currently > doing, instead the tool itself has to be moldable (or what is the tool). > > Now, I'm so attuned to the Alt Browser tree view that I prefer it in > any case... even to the point that I can do short and fast smalltalk > edits directly on github through the web interface. > > Thierry > > > Esteban > >> >>> >>> Thierry > >

Aug. 20, 2015

Re: [Pharo-dev] Nautilus questions

by stepharo

Sorry but reading code is really important and now assistant is taking too much space. And your proposal does not take into account hierarchy and I use it all the time. The same way we use all the time variables. Stef Le 19/8/15 11:50, Esteban Lorenzano a Ã©crit : > >> On 19 Aug 2015, at 11:44, Thierry Goubier <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com>> wrote: >> >> <Screen Shot 2015-08-19 at 11.10.41.png> >> >> â¦ but arriving to it is not so easy. >> >> In conclusion: We are doing some right steps. It is not finished, >> but we are not going to go back to older way :) >> >> >> Hi Esteban, >> >> My opinion is that you're still tied a lot to the Smalltalk 80's >> way... Which is good: someone coming from 1980 would be able to use >> Nautilus ;) >> >> My critics on that design: the tabs are nice and certainly help see >> that a class has a class side. Overall look is more up to date. Tabs >> headers, scroll bars, etc... take far too much space: work area (the >> code area) is 39% of overall window size, and 68% counting in the >> context (package, class, protocol and method) (Numbers are worse on a >> small window, of course, but I guess some do work on small screens). >> >> It will be nice to see simpler / cleaner Nautilus code coming along :) > > yes, of course you are right :) > the GTools guys are working in a complete replacement, and Iâm sure it > will be a lot betterâ¦ but we will always need a backdoorâ¦ and I would > like to have a good browser even as a backdoor. > (also, our philosophy is incremental: we improve what we have while we > wait for the break-thru improvements) > > Esteban > > ps: for me the âcode areaâ is not equivalent to the âwork areaâ: I > spend much more time understanding a problem than coding it, and for > that a view of the method *in the context* is better) > >> >> Thierry >

Aug. 20, 2015

Status of Tanker?

by HernÃ¡n Morales Durand

Hello, What is the status of Tanker? I tried to loadDevelopment in Pharo 4 but there are references to PackageInfo, and tests fails. Cheers, HernÃ¡n

Aug. 20, 2015

Re: [Pharo-dev] Nautilus questions

by Thierry Goubier

Le 19/08/2015 20:26, Dimitris Chloupis a Ã©crit : > > > On Wed, Aug 19, 2015 at 5:51 PM Sean P. DeNigris <sean(a)clipperadams.com > <mailto:sean@clipperadams.com>> wrote: > > kilon.alios wrote > > > For example, let's say your project has a class that implements a > generically-named method, like #asMorph. If you try to rename that > method > via Refactoring, Pharo will try to rename all #asMorph methods, and > update > all senders, in the entire system, not just yours. But if you scope the > browser first to your package or class, you can restrict the > environment to > which the refactoring is applied > > > This sounds useful indeed. Is just the browser aware of the scope or is > also the pharo environment aware of the scope too ? It would be nice if > the scope could expand to include multiple packages , or is this > something left to groups ? What is happening is that many commands linked to the IDE (refactorings, searches) have an environment entity. By default, this environment is Smalltalk, but it can be a subset of it, and any subset of it. Have a look into the RBBrowserEnvironment class and subclasses and you will see all the variants. For example, a RBPackageEnvironment will scope to one or multiple packages. Thierry

Aug. 20, 2015