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