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

Re: [Pharo-dev] could the size of Playground be reduced a bit

by Peter UhnÃ¡k

Â±1 The problem is that it is not only playground, but also an inspector. While I would like the window smaller in both dimensions (no script is that wide), it would sort of break "do it and go". One idea might be to increase it to the current size only when "do it and go" is executed (and the inspector is not opened yet). Because otherwise users of it would have to resize it manually very often - if it is the size of the original Workspace, the inspector is utterly useless. Peter

March 25, 2015

Re: [Pharo-dev] Update question

by Norbert Hartl

> Am 25.03.2015 um 19:45 schrieb Damien Cassou <damien.cassou(a)gmail.com>: > > In my opinion, the most important thing for you to do is to setup a continuous integration server. Then you can download ready made, up to date, and tested images every morning. You can download these images either with or without the launcher. > Thanks for the input. I'll may try that for other projects. I have a CI server for all of my projects. I need to load a lot of projects into one image in order to maintain changes among them. And I have adjustments to do for every image that are not done on the CI. You might argue that I could make configurations and scripts for all of these. Yes I could but I didn't. The next point is that I develop with pharo4 but the product needs to run on pharo3. So yes I could also build it for pharo3 and pharo4. I also have some workspaces with code snippets I need frequently. This I could script as well. Maybe I'll do all of this. At the moment I just want to update to have an actual pharo and test it and may give feedback. As it is not possible and the change of an image is a burden to me I just do not update. That's all. > If you want to try the launcher, you could symlink the launcher's managed images from each of your project directories. > That wouldn't work. I save my image often under a different image name because I tend to break the image or it crashes. With the changes log not working the only feasible way is to make a lot of copies of your images. So symlinking is not working that way. thanks anyway, Norbert > On Mar 24, 2015 3:37 PM, "Norbert Hartl" <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > > > Am 24.03.2015 um 12:41 schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>>: > > > > PharoLauncher manage all your images and dl new images directly from the CI server. PharoLauncher is written in Pharo and can be adapted to your own needs ;-) > > > So there is nothing to gain. My use cases are completely different. I don't want my images to be managen in one place. I have a lot of projects that have their own project folder where they live with other resources and they are organized in a directory structure that makes sense. > My point was preventing the installation of my stuff in a new image everytime. One project is a lot of stuff to load and adjust and for that I'd like to just update the image. So to me it appears PharoLauncher is just able to make my situation worse :) > > Norbert > > > > > Sent from my iPhone > > > >> On 24 mars 2015, at 12:38, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > >> > >> What would be better using PharoLauncher? > >> > >> Norbert > >> > >>> Am 24.03.2015 um 12:30 schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>>: > >>> > >>> Don't update use PharoLauncher instead ! I use PharoLauncher everyday for my work and I download new images every 2-3 days. > >>> > >>> Sent from my iPhone > >>> > >>>> On 24 mars 2015, at 11:13, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > >>>> > >>>> Today I wanted (again) to update my image and it can't find GT packages. So I'm interested how the community deals with that. Do you take fresh downloaded images regularly? Or you do not update? Is it just me? > >>>> > >>>> thanks, > >>>> > >>>> Norbert > >> > >> > > > >

March 25, 2015

Re: [Pharo-dev] collecting Pharo 4.0 Contributors

by Esteban Lorenzano

but you are already in the list ;) > On 25 Mar 2015, at 19:45, Damien Cassou <damien.cassou(a)gmail.com> wrote: > > I pair programmed with Jean-Christophe Bach on a few bug fixes. > > On Mar 24, 2015 3:39 PM, "Esteban Lorenzano" <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > Hi, > > Iâm collection the list of contributors for this version. > Since we detect contributors by author stamps: > > - some times who made the commit does not reflect all the people who worked on a problem, > - we consider contributors to Pharo all people who has contributed in any way: discussing things, commenting bugs, doing videos or any kind of documentation, etc. > > the list will be incomplete, so please look for yourself on it and let me know if you are missing: > > also, I would like to know who are this two guys: > - aaef > - monty > > (btwâ¦ we collected so far 76 contributorsâ¦ not bat at all, for a dead language ;) ) > > Clara Allende > Jean Baptiste Arnaud > Philippe Back > Clement Bera > Alexandre Bergel > Torsten Bergmann > Vincent Blondeau > Noury Bouraqadi > Santiago Bragagnolo > Johan Brichau > Sven Van Caekenberghe > Damien Cassou > Nicolas Cellier > Guido Chari > Dimitris Chloupis > Andrei Chis > Ben Coman > Bernardo Contreras > Tommaso Dal Sasso > Jan Van De Sandt > Christophe Demarey > Sean DeNigris > Marcus Denker > Martin Dias > Stephane Ducasse > Stephan Eggermont > Luc Fabresse > Johan Fabry > Hilaire Fernandes > Jerome Garcia > Tudor Girba > Thierry Goubier > Kris Gybels > Norbert Hartl > Dale Henrichs > Pablo Herrero > Nicolai Hess > Pavel Krivanek > Juraj Kubelka > Jan Kurs > Laurent Laffont > Jannik Laval > Kevin Lanvin > Max Leske > David Lewis > Diego Lont > Esteban Lorenzano > Esteban Maringolo > Stefan Marr > Tim Mackinnon > Max Mattone > Martin Mc Clure > Eliot Miranda > Sean De Nigris > Alain Plantec > Guillermo Polito > Damien Pollet > Stefan Reichhart > Mark Rizun > Udo Schneider > Ignacio Sniechowski > Henrik Sperre Johansen > Igor Stasenko > Aliaksei Syrel > Ciprian Teodorov > Camille Teruel > Sebastian Tleye > Yuriy Tymchuk > Peter Uhnak > Andres Valloud > Sven Van Caekenberghe > Thomas Vincent > Martin Walk > Richard Wettel > > thanks, > Esteban

March 25, 2015

Re: [Pharo-dev] Update question

by Damien Cassou

In my opinion, the most important thing for you to do is to setup a continuous integration server. Then you can download ready made, up to date, and tested images every morning. You can download these images either with or without the launcher. If you want to try the launcher, you could symlink the launcher's managed images from each of your project directories. On Mar 24, 2015 3:37 PM, "Norbert Hartl" <norbert(a)hartl.name> wrote: > > > Am 24.03.2015 um 12:41 schrieb Serge Stinckwich < > serge.stinckwich(a)gmail.com>: > > > > PharoLauncher manage all your images and dl new images directly from the > CI server. PharoLauncher is written in Pharo and can be adapted to your own > needs ;-) > > > So there is nothing to gain. My use cases are completely different. I > don't want my images to be managen in one place. I have a lot of projects > that have their own project folder where they live with other resources and > they are organized in a directory structure that makes sense. > My point was preventing the installation of my stuff in a new image > everytime. One project is a lot of stuff to load and adjust and for that > I'd like to just update the image. So to me it appears PharoLauncher is > just able to make my situation worse :) > > Norbert > > > > > Sent from my iPhone > > > >> On 24 mars 2015, at 12:38, Norbert Hartl <norbert(a)hartl.name> wrote: > >> > >> What would be better using PharoLauncher? > >> > >> Norbert > >> > >>> Am 24.03.2015 um 12:30 schrieb Serge Stinckwich < > serge.stinckwich(a)gmail.com>: > >>> > >>> Don't update use PharoLauncher instead ! I use PharoLauncher everyday > for my work and I download new images every 2-3 days. > >>> > >>> Sent from my iPhone > >>> > >>>> On 24 mars 2015, at 11:13, Norbert Hartl <norbert(a)hartl.name> wrote: > >>>> > >>>> Today I wanted (again) to update my image and it can't find GT > packages. So I'm interested how the community deals with that. Do you take > fresh downloaded images regularly? Or you do not update? Is it just me? > >>>> > >>>> thanks, > >>>> > >>>> Norbert > >> > >> > > > > >

March 25, 2015

Re: [Pharo-dev] collecting Pharo 4.0 Contributors

by Damien Cassou

I pair programmed with Jean-Christophe Bach on a few bug fixes. On Mar 24, 2015 3:39 PM, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > Hi, > > I'm collection the list of contributors for this version. > Since we detect contributors by author stamps: > > - some times who made the commit does not reflect all the people who > worked on a problem, > - we consider contributors to Pharo all people who has contributed in any > way: discussing things, commenting bugs, doing videos or any kind of > documentation, etc. > > the list will be incomplete, so please look for yourself on it and let me > know if you are missing: > > also, I would like to know who are this two guys: > - aaef > - monty > > (btw... we collected so far 76 contributors... not bat at all, for a dead > language ;) ) > > Clara Allende > Jean Baptiste Arnaud > Philippe Back > Clement Bera > Alexandre Bergel > Torsten Bergmann > Vincent Blondeau > Noury Bouraqadi > Santiago Bragagnolo > Johan Brichau > Sven Van Caekenberghe > Damien Cassou > Nicolas Cellier > Guido Chari > Dimitris Chloupis > Andrei Chis > Ben Coman > Bernardo Contreras > Tommaso Dal Sasso > Jan Van De Sandt > Christophe Demarey > Sean DeNigris > Marcus Denker > Martin Dias > Stephane Ducasse > Stephan Eggermont > Luc Fabresse > Johan Fabry > Hilaire Fernandes > Jerome Garcia > Tudor Girba > Thierry Goubier > Kris Gybels > Norbert Hartl > Dale Henrichs > Pablo Herrero > Nicolai Hess > Pavel Krivanek > Juraj Kubelka > Jan Kurs > Laurent Laffont > Jannik Laval > Kevin Lanvin > Max Leske > David Lewis > Diego Lont > Esteban Lorenzano > Esteban Maringolo > Stefan Marr > Tim Mackinnon > Max Mattone > Martin Mc Clure > Eliot Miranda > Sean De Nigris > Alain Plantec > Guillermo Polito > Damien Pollet > Stefan Reichhart > Mark Rizun > Udo Schneider > Ignacio Sniechowski > Henrik Sperre Johansen > Igor Stasenko > Aliaksei Syrel > Ciprian Teodorov > Camille Teruel > Sebastian Tleye > Yuriy Tymchuk > Peter Uhnak > Andres Valloud > Sven Van Caekenberghe > Thomas Vincent > Martin Walk > Richard Wettel > > thanks, > Esteban >

March 25, 2015

Re: [Pharo-dev] could the size of Playground be reduced a bit

by Esteban A. Maringolo

+1 There are many of us who still have WXGA resolutions at ~100ppi Esteban A. Maringolo 2015-03-25 15:24 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: > > > Am 25.03.2015 um 18:57 schrieb stepharo <stepharo(a)free.fr>: > > > > Because it is a bit large now even on a 27 inch screen. > > > > +1 > > Norbert > >

March 25, 2015

Re: [Pharo-dev] could the size of Playground be reduced a bit

by Norbert Hartl

> Am 25.03.2015 um 18:57 schrieb stepharo <stepharo(a)free.fr>: > > Because it is a bit large now even on a 27 inch screen. > +1 Norbert

March 25, 2015

Re: [Pharo-dev] could the size of Playground be reduced a bit

by Johan Fabry

+1 on that. Please make it less tall. Itâs been a subconscious bother to me and now that Stef voiced it I realized it. > On Mar 25, 2015, at 14:57, stepharo <stepharo(a)free.fr> wrote: > > Because it is a bit large now even on a 27 inch screen. > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

March 25, 2015

Re: [Pharo-dev] Some Memory Leak

by stepharo

+1 Le 25/3/15 11:52, Sven Van Caekenberghe a Ã©crit : > YES! > > My image went from 65Mb to 34Mb (it contains Seaside/Bootstrap and several resources). > > Thanks a lot, you guys (and everybody else who contributes) rock! > > Let's hope this solves the issue. > >> On 25 Mar 2015, at 11:26, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: >> >> To load the latest version in an image execute: >> >> { { 'ConfigurationOfRubric'. 'AlainPlantec'. 'Rubric' }. >> { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. >> { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. >> { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. >> { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. >> { 'ConfigurationOfGToolkitCore'. 'Moose'. 'GToolkit' }. >> } do: [ :spec | >> Gofer new >> smalltalkhubUser: spec second project: spec third; >> package: spec first; >> load ]. >> ConfigurationOfGToolkitCore loadDevelopment. >> >> Then run cleanUp: >> >> Smalltalk cleanUp: true except: #() confirming: false. >> >> Now only the latest instance of playground/spotter is not garbaged collected, but that would be fixed very soon. >> >> >> Cheers, >> Andrei >> >> >> >> >> On Wed, Mar 25, 2015 at 11:21 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Please tell us when this gets integrated so that we can test the effect. >> >> Or to go faster, please give some instructions (an executable expression) that we can execute in the latest image to load the relevant changes. >> >> We need more eyeballs. >> >>> On 25 Mar 2015, at 09:50, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Up to now, we identified two issues that lead to objects not being garbage collected: >>> >>> - GLMHintableActionButtonBrick triggers a singleton asynctask that was not cleaned after the task was ready. Now, that problem should be solved in GT. >>> >>> - RubFindReplaceService has a Singleton class variable. At the same time, RubFindReplaceService also keeps a reference to the textArea which is part of the morph tree and will prevent the whole UI that includes it to be garbage collected. We are working on dealing with this issue. >>> >>> There might be other issues. We need to keep looking. >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Wed, Mar 25, 2015 at 8:52 AM, stepharo <stepharo(a)free.fr> wrote: >>> Hi henrik >>> >>> your analyses are great. >>> What do you think about >>> >>> GTSpotterStep>>#candidates >>> >>> ^ candidates ifNil: [ >>> candidates := GTSpotterCandidatesList new. >>> candidates announcer weak subscribe: GTSpotterCandidateAdded do: [ self candidates hasOnlyOneItem ifTrue: [ self selectFirst ] ]. >>> candidates announcer weak subscribe: GTSpotterAllCandidatesAdded do: [ self selectFirst ]. >>> candidates announcer weak subscribe: GTSpotterAllCandidatesRemoved do: [ self selected: nil ]. >>> candidates ] >>> >>> Le 24/3/15 21:38, Henrik Sperre Johansen a Ã©crit : >>> >>> A tiny bit of code review while I'm at it... >>> >>> GTSpotterResultsBrick >> initialize >>> super initialize >>> self band hSpaceFill. >>> self announcer weak subscribe: GLMBrickScrollPositionChanged send: >>> #onScrolled to: self >>> >>> This is a tempting, but sneaky anti-pattern, you should never, ever, ever >>> have to subscribe to your own announcer: >>> The reason for calling it an anti-pattern is; if your code actually depends >>> on this, it means other sources might invoke changes in you indirectly >>> through your announcer, which quickly becomes debugging hell if you allow >>> it, and something screws up. (I speak from experience) >>> >>> It's much easier to understand when done directly, in this case that means >>> extending the super method where announcement is made: >>> >>> GTSpotterResultsBrick >> privateScrollPosition:anInteger >>> super privateScrollPosition:anInteger. >>> self onScrolled >>> >>> Cheers, >>> Henry >>> >>> P.S. Announcements are objects, they are intended to hold the data >>> subscribers might be interested in. >>> Whenever you find yourself writing something like: >>> someAnnouncer announce: SomeAnnouncement new >>> ask yourself twice if that may lead to subscribers accessing state that >>> would more naturally be part of the announcement through other channels >>> (such as keeping extra instvars, etc). >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/Some-Memory-Leak-tp4814779p4814912.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> >> > >

March 25, 2015

Re: [Pharo-dev] Some Memory Leak

by stepharo

Thanks! Thanks! Thanks! Le 25/3/15 09:50, Tudor Girba a Ã©crit : > Up to now, we identified two issues that lead to objects not being > garbage collected: > > - GLMHintableActionButtonBrick triggers a singleton asynctask that was > not cleaned after the task was ready. Now, that problem should be > solved in GT. > > - RubFindReplaceService has a Singleton class variable. At the same > time, RubFindReplaceService also keeps a reference to the textArea > which is part of the morph tree and will prevent the whole UI that > includes it to be garbage collected. We are working on dealing with > this issue. > > There might be other issues. We need to keep looking. > > Cheers, > Doru > > > > On Wed, Mar 25, 2015 at 8:52 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi henrik > > your analyses are great. > What do you think about > > GTSpotterStep>>#candidates > > ^ candidates ifNil: [ > candidates := GTSpotterCandidatesList new. > candidates announcer weak subscribe: > GTSpotterCandidateAdded do: [ self candidates hasOnlyOneItem > ifTrue: [ self selectFirst ] ]. > candidates announcer weak subscribe: > GTSpotterAllCandidatesAdded do: [ self selectFirst ]. > candidates announcer weak subscribe: > GTSpotterAllCandidatesRemoved do: [ self selected: nil ]. > candidates ] > > Le 24/3/15 21:38, Henrik Sperre Johansen a Ã©crit : > > A tiny bit of code review while I'm at it... > > GTSpotterResultsBrick >> initialize > super initialize > self band hSpaceFill. > self announcer weak subscribe: > GLMBrickScrollPositionChanged send: > #onScrolled to: self > > This is a tempting, but sneaky anti-pattern, you should never, > ever, ever > have to subscribe to your own announcer: > The reason for calling it an anti-pattern is; if your code > actually depends > on this, it means other sources might invoke changes in you > indirectly > through your announcer, which quickly becomes debugging hell > if you allow > it, and something screws up. (I speak from experience) > > It's much easier to understand when done directly, in this > case that means > extending the super method where announcement is made: > > GTSpotterResultsBrick >> privateScrollPosition:anInteger > super privateScrollPosition:anInteger. > self onScrolled > > Cheers, > Henry > > P.S. Announcements are objects, they are intended to hold the data > subscribers might be interested in. > Whenever you find yourself writing something like: > someAnnouncer announce: SomeAnnouncement new > ask yourself twice if that may lead to subscribers accessing > state that > would more naturally be part of the announcement through other > channels > (such as keeping extra instvars, etc). > > > > -- > View this message in context: > http://forum.world.st/Some-Memory-Leak-tp4814779p4814912.html > Sent from the Pharo Smalltalk Developers mailing list archive > at Nabble.com. > > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

March 25, 2015