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

Reply via email to