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

Re: [Pharo-dev] WhatsUp from: 2015-08-17 until: 2015-08-31

by Denis Kudriashov

Hi 2015-08-20 6:54 GMT+03:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > >> Auto-completion in Pharo is really bad. It would be fantastic to improve >> it. >> >> > Yes indeed, my effort for now is focused in documenting it. I cannot > improve what I dont understand. Then will see if I can improve it, by > making it more customizable or making it a bit smarter. > I have crazy idea to integrate GTSpotter to autocompletion pane to allow immediate search on existed texts. What you think about this?

Aug. 20, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 20, 2015

[pharo-project/pharo-core] e81c8e: 50250

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: e81c8e9aac925961e485b8f96a390b09a0e2ea9d https://github.com/pharo-project/pharo-core/commit/e81c8e9aac925961e485b8f9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-20 (Thu, 20 Aug 2015) Changed paths: M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1181_.st R Nautilus.package/AbstractNautilusUI.class/class/menu/shiftedSourceCodeMenu_.st R Nautilus.package/AbstractNautilusUI.class/class/menu/sourceCodeMenuExtra_.st R Nautilus.package/AbstractNautilusUI.class/class/menu/sourceCodeMenu_.st M Nautilus.package/AbstractNautilusUI.class/instance/build ui text/buildNewCodeSourceAreaRubric.st M Nautilus.package/AbstractNautilusUI.class/instance/menu builder/sourceCodeMenu_shifted_.st M NautilusRefactoring.package/NautilusRefactoring.class/class/menu/sourceCodeRefactoringMenuHolder_.st M NautilusRefactoring.package/NautilusRefactoring.class/class/menu/sourceCodeRefactoringSubMenu_.st M NautilusRefactoring.package/extension/TClassDescription/instance/sourceCodeRefactoringMenu_.st M NautilusRefactoring.package/extension/TClassDescription/instance/sourceCodeRefactoring_.st A Rubric.package/RubScrolledTextModel.class/instance/undo-redo/clearUndoManager.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50249.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50250.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50249.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50250.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/TextModel.class/instance/api/beForCode.st M Spec-Core.package/TextModel.class/instance/api/beForText.st A Spec-Core.package/TextModel.class/instance/private/getMenu.st A Spec-MorphicAdapters.package/MorphicTextAdapter.class/instance/spec protocol/canChangeText.st A Spec-MorphicAdapters.package/MorphicTextAdapter.class/instance/spec protocol/selectFrom_to_.st A Spec-MorphicAdapters.package/MorphicTextAdapter.class/instance/spec protocol/selectionInterval.st Log Message: ----------- 50250 16305 Update configuration of Rubric https://pharo.fogbugz.com/f/cases/16305 16273 RubSmalltalkEditor(Object)>>doesNotUnderstand: #shiftedTextPaneMenuRequest https://pharo.fogbugz.com/f/cases/16273 http://files.pharo.org/image/50/50250.zip

Aug. 20, 2015

Re: [Pharo-dev] Nautilus questions

by Esteban Lorenzano

> On 20 Aug 2015, at 09:14, stepharo <stepharo(a)free.fr> wrote: > > 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. not just a bit: I would like a button (and a key combination) to expand the full area to occupy all browser space when needed. and not just the code area: the different panels too: no matter how much you reduce the size of protocols and/or packages, there will always be methods and classes with bigger namesâ¦ I think an âexpandâ function is better solution than arbitrary change panel sizes. Esteban > > 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 Esteban Lorenzano

> On 20 Aug 2015, at 09:13, stepharo <stepharo(a)free.fr> wrote: > > Sorry but reading code is really important and now assistant is taking too much space. for me code is as important as the other functionality. the size of the code area (and the default size of the browser) can be easily increased, if needed. > And your proposal does not take into account hierarchy and I use it all the time. my âproposalâ is just a fast sketch made to illustrate how I would like to show certain functionality, it does not take into account any other functionalityâ¦ If I finish my browser proposal ever, it will have a lot more buttons in the toolbar :) about hierarchy I think it should spawn a new browser, as beforeâ¦ but it is still something we need to play with it. > The same way we use all the time variables. *we* use them all the time, but most people does not use them never :) anyway: an option in a tab is one click, same as with a button: not hardâ¦ and we can play with the information we show in auxiliary panels better :) Esteban > > 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 Esteban Lorenzano

> On 19 Aug 2015, at 20:26, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > > > 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 ? no, you can select and then browse scoped : - multiple packages - groups (btw, current scoped button does not takes that into account) - a single class (you have to use the context menu on classes for it) it is really powerful :) Esteban >

Aug. 20, 2015

Re: [Pharo-dev] WhatsUp from: 2015-08-17 until: 2015-08-31

by Max Leske

> On 20 Aug 2015, at 03:45, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Just wondering, you need to have libssh2 working in order to get libgit2? > How far are we from getting this working? Not exactly, but we need libssh2 for ssh support which, in my opinion, is very important in this context (I use ssh with Git about 98% of the time). Itâs already working and has been for quite a while. Martin has been working with the libgit2 bindings for a couple of months and has been a great help in providing feedback. The question is more: how well is it working. I donât want people to use an unstable and buggy API. > > Cheers, > Alexandre > > >> On Aug 19, 2015, at 3:22 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >> - libgit2 and libssh2 now compile and link nicely on the Windows, Linux and Mac VMs >> - upgraded libgit2 to version 0.23 >> - Linux build for libgit2 is now green. Windows build exhibits some very strange problems with unzipping, will fix that later. >> - Discovered a possible bug in libssh2 on Linux which prevents libgit2 from working with ssh > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Aug. 20, 2015

Re: [Pharo-dev] Status of Tanker?

by Martin Dias

Hello HernÃ¡n, It's outdated, we were not taking care of Tanker. I've just updated some urls in the doc, and the Pharo versions in the Jenkins job (it was being run in 2.0 and 3.0!). BTW, have you loaded it from this repo? http://smalltalkhub.com/#!/~PharoExtras/Tanker (we moved from Mariano's repo, but the old one wasn't deleted). Cheers, MartÃn El jue., 20 ago. 2015 a las 8:24, HernÃ¡n Morales Durand (< hernan.morales(a)gmail.com>) escribiÃ³: > 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

2015-08-20 10:19 GMT+02:00 stepharo <stepharo(a)free.fr>: > > > 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... > > > yes but 99% of the time you do not care. > I'm not sure of that. On classes with a lot of methods (Object, Morph, any class with over 20 methods), I believe one rely on protocols to avoid being overwhelmed by the sheer number, and that most of them are irrelevant to the task at hand (the method you're writing and reading, and the same class methods it is using). I wonder if the fact Nautilus shows us by default the 'all' method list is not inciting us, by pure laziness, to disregard protocols... > And methods are way more important. > In fact protocol could just the tag (as in the catalog browser) after the > method names. > Then you could use the message list GUI instead of the system browser. Thierry > > 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>: > >>> > >>> > >>>> 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 Thierry Goubier

2015-08-20 9:14 GMT+02:00 stepharo <stepharo(a)free.fr>: > For example why protocol get the same space than method. We could split > the protocol by half and use the space for > soemthing useful. > An example to illustrate the empty space in the protocol area: [image: Images intÃ©grÃ©es 1] > I would like the coding area to expand a bit when a method is too long. > I do it all the time by hand. > Same example with AltBrowser, exact same bounds: [image: Images intÃ©grÃ©es 2] It's interesting to see the difference in displayed information between the two (which one gives the feeling the method is too long?). As shown, the second screenshot provides less context (i.e. no package name) but is this information available? Thierry > > 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