Wow!
> On 26 Mar 2015, at 14:24, Andrei Chis <chisvasileand...@gmail.com> wrote:
>
> Now, with Alain's help, also the memory leak from Rubric is solved.
> All fixes will be in the next version, which will hopefully be ready today.
>
> Cheers,
> Andrei
>
> On Wed, Mar 25, 2015 at 7:05 PM, stepharo <steph...@free.fr> wrote:
> +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 <chisvasileand...@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 <s...@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 <tu...@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 <steph...@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"
>
>
>
>
>
>
>
