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

Re: [Pharo-dev] Some Memory Leak

by Sven Van Caekenberghe

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 Andrei Chis

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 Sven Van Caekenberghe

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] GTSpotter initial notice on dark theme

by Yuriy Tymchuk

I am just letting you know :) > On 25 Mar 2015, at 11:03, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > It's a bug :) > > Cheers, > Andrei > > On Wed, Mar 25, 2015 at 10:49 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > Did you notice, that initial notice is not readable on dark theme? > > <Screen Shot 2015-03-25 at 10.47.59.png> >

March 25, 2015

Re: [Pharo-dev] GTSpotter initial notice on dark theme

by Andrei Chis

It's a bug :) Cheers, Andrei On Wed, Mar 25, 2015 at 10:49 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Did you notice, that initial notice is not readable on dark theme? > >

March 25, 2015

GTSpotter initial notice on dark theme

by Yuriy Tymchuk

Did you notice, that initial notice is not readable on dark theme?

March 25, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Torsten Bergmann

Hi Tudor, stay serious: the methods you are talking about were introduced as GT extension following YOUR definition of an example. We could argue what/who was first with <example>, who discussed/patented it first, who has to change the most code now ... but would it move us forward? We do not need a long discussion, we need a solution. The situation is that we have a conflict in the usage of <example> Pragma: We wanted a way to find out the examples given in methods (often hidden in the image and external packages) and also remove the limitation that they have to start with exampleXXX. So I took action to be able to explicitly mark methods that are intended by the author as an "example" by using the <example> pragma. This was integrated in Pharo 4 and is also in use, not in the image but in loadable packages already. My definition of an example is "a general code example". You had another discussion in the context of GT Tools about renaming the <gtExample> into <example> and also meanwhile took action to use use <example>. But you also put the ADDITIONAL meaning behind the pragma that methods marked with <example> should always return an initialized object. And this last part is the only part where our point of views collide. There is no need to explain from your side that it is often valuable to have such example methods that return initialized instance. One can use them to construct other initialized instances, ... Anything I say is that not all "examples" and "example methods" are providing such example instances. So we can not (and should not) ignore the fact that not all methods intended by the author as "examples" follow this additional definition/requirement. So the only difference in our point of view is that you want to mark all of them equally with <example> and assume that all of them return an instance of the same class while I will not because not all examples do that. Some of them are just example methods to demonstrate how to use the class or combine objects or do some action where the return value of the method is uninteresting. So in your definition of <example> pragma you talk about the need for marking methods with "example instances" while I talk about more general examples (examples of code) that can but do not necessarily have to provide such initialized instances. So my proposal is simple and should satisfy both needs: ======================================================= 1. The <example> Pragma can used to mark a method as an "example" method. An example is a method that is intended as an "example of code": tryThisOut <example> Transcript show: 'An example on how to write to the transcript' 2. The <exampleInstance> Pragma can be used to mark methods that return an an example instance: anInstanceA <exampleInstance> ^$A This will solve the issue easily and it will be more clear as THE INTENTION OF THE PRAGMA in both cases FITS WITH THE NAME. Also a tool can query for one or both pragmas and decide if if it wants to inspect/display the result after performing the method or just run it. So this is my proposal to satisfy both POV's. You can argue agains it but not without making another proposal that satisfies both needs. Thanks T.

March 25, 2015

Re: [Pharo-dev] Some Memory Leak

by Tudor Girba

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] collecting Pharo 4.0 Contributors

by stepharo

monty should be the guy doing the xml parser improvements monty.os(a)engineer.com Stef Le 24/3/15 15:39, Esteban Lorenzano a Ã©crit : > 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] Some Memory Leak

by stepharo

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. > > >

March 25, 2015