The Inbox: Monticello-nice.528.mcz
Locked
 
|
A new version of Monticello was added to project The Inbox:
http://source.squeak.org/inbox/Monticello-nice.528.mcz ==================== Summary ==================== Name: Monticello-nice.528 Author: nice Time: 22 January 2013, 3:42:35.787 pm UUID: 3bc3c4a2-2ec6-e942-9517-5da75b32bac5 Ancestors: Monticello-bf.527 Let MCTool inherit from Model. This is to avoid nasty garbage to survive in DependentsFields with kilo bytes of un-released MCDefinition cache. =============== Diff against Monticello-bf.527 =============== Item was changed: + Model subclass: #MCTool - Object subclass: #MCTool instanceVariableNames: 'morph label modal modalValue' classVariableNames: '' poolDictionaries: '' category: 'Monticello-UI'! Item was removed: - ----- Method: MCTool>>arrowKey:from: (in category 'morphic ui') ----- - arrowKey: aCharacter from: aPluggableListMorph - "backstop"! Item was removed: - ----- Method: MCTool>>postAcceptBrowseFor: (in category 'morphic ui') ----- - postAcceptBrowseFor: aModel - "Nothing to do."! Item was removed: - ----- Method: MCTool>>representsSameBrowseeAs: (in category 'morphic ui') ----- - representsSameBrowseeAs: anotherModel - ^ false! Item was removed: - ----- Method: MCTool>>step (in category 'morphic ui') ----- - step - ! |
Re: The Inbox: Monticello-nice.528.mcz
|
|
On 22.01.2013, at 14:42, [hidden email] wrote: > A new version of Monticello was added to project The Inbox: > http://source.squeak.org/inbox/Monticello-nice.528.mcz > > ==================== Summary ==================== > > Name: Monticello-nice.528 > Author: nice > Time: 22 January 2013, 3:42:35.787 pm > UUID: 3bc3c4a2-2ec6-e942-9517-5da75b32bac5 > Ancestors: Monticello-bf.527 > > Let MCTool inherit from Model. > This is to avoid nasty garbage to survive in DependentsFields with kilo bytes of un-released MCDefinition cache. Looks reasonable. Commit it and we'll find out soon if there are problems. - Bert - |
Re: The Inbox: Monticello-nice.528.mcz
|
|
Good Nicolas that you took the initiative to solve this long standing
issue of un-released MCDefinitions hanging around. --Hannes On 1/22/13, Bert Freudenberg <[hidden email]> wrote: > > On 22.01.2013, at 14:42, [hidden email] wrote: > >> A new version of Monticello was added to project The Inbox: >> http://source.squeak.org/inbox/Monticello-nice.528.mcz >> >> ==================== Summary ==================== >> >> Name: Monticello-nice.528 >> Author: nice >> Time: 22 January 2013, 3:42:35.787 pm >> UUID: 3bc3c4a2-2ec6-e942-9517-5da75b32bac5 >> Ancestors: Monticello-bf.527 >> >> Let MCTool inherit from Model. >> This is to avoid nasty garbage to survive in DependentsFields with kilo >> bytes of un-released MCDefinition cache. > > Looks reasonable. Commit it and we'll find out soon if there are problems. > > - Bert - > > > > |
Re: The Inbox: Monticello-nice.528.mcz
|
|
OK, I commited but...
This was a first guess, and now I think it was a wrong guess. DependentsFields key is weak AND DependentsFields value is a DependentsArray which weakly point to its variables too. So this is not the same case as http://bugs.squeak.org/view.php?id=7119 I finally found that the unreleased instances I saw were pointed by the docking bar 'windows' subMenu. When you close a window, the subMenu isn't rebuilt. So all the windows that existed when you last opened docking bar 'windows' menu will continue to exist until next time you open this menu. You usually open this menu when your screen is crowded, which tend to maximize the life of many garbage... The fact that the dependents are in Object DependentsFields only make them more visible, and my change just let them be less visible, so it was essentially useless... 2013/1/22 H. Hirzel <[hidden email]>: > Good Nicolas that you took the initiative to solve this long standing > issue of un-released MCDefinitions hanging around. > > --Hannes > > On 1/22/13, Bert Freudenberg <[hidden email]> wrote: >> >> On 22.01.2013, at 14:42, [hidden email] wrote: >> >>> A new version of Monticello was added to project The Inbox: >>> http://source.squeak.org/inbox/Monticello-nice.528.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: Monticello-nice.528 >>> Author: nice >>> Time: 22 January 2013, 3:42:35.787 pm >>> UUID: 3bc3c4a2-2ec6-e942-9517-5da75b32bac5 >>> Ancestors: Monticello-bf.527 >>> >>> Let MCTool inherit from Model. >>> This is to avoid nasty garbage to survive in DependentsFields with kilo >>> bytes of un-released MCDefinition cache. >> >> Looks reasonable. Commit it and we'll find out soon if there are problems. >> >> - Bert - >> >> >> >> > |
Re: The Inbox: Monticello-nice.528.mcz
|
|
On 1/22/13, Nicolas Cellier <[hidden email]> wrote:
> OK, I commited but... > This was a first guess, and now I think it was a wrong guess. A wrong guess in terms of getting rid of unreleased MCDefinition instances... But as a whole having Model subclass: #MCTool makes sense to me and seems to do no harm. > > DependentsFields key is weak AND DependentsFields value is a > DependentsArray which weakly point to its variables too. > So this is not the same case as http://bugs.squeak.org/view.php?id=7119 > > I finally found that the unreleased instances I saw were pointed by > the docking bar 'windows' subMenu. > When you close a window, the subMenu isn't rebuilt. > So all the windows that existed when you last opened docking bar > 'windows' menu will continue to exist until next time you open this > menu. > You usually open this menu when your screen is crowded, which tend to > maximize the life of many garbage... > > The fact that the dependents are in Object DependentsFields only make > them more visible, and my change just let them be less visible, so it > was essentially useless... But this analysis leads us further. It is very helpful. I have many Morphic projects and all have windows in it. So I now know a source why MCDefinition instances are not released. What should we do about the 'Windows' subMenu? Rebuild it any time a menu is called? Or rebuild it any time a window is closed? --Hannes > > 2013/1/22 H. Hirzel <[hidden email]>: >> Good Nicolas that you took the initiative to solve this long standing >> issue of un-released MCDefinitions hanging around. >> >> --Hannes >> >> On 1/22/13, Bert Freudenberg <[hidden email]> wrote: >>> >>> On 22.01.2013, at 14:42, [hidden email] wrote: >>> >>>> A new version of Monticello was added to project The Inbox: >>>> http://source.squeak.org/inbox/Monticello-nice.528.mcz >>>> >>>> ==================== Summary ==================== >>>> >>>> Name: Monticello-nice.528 >>>> Author: nice >>>> Time: 22 January 2013, 3:42:35.787 pm >>>> UUID: 3bc3c4a2-2ec6-e942-9517-5da75b32bac5 >>>> Ancestors: Monticello-bf.527 >>>> >>>> Let MCTool inherit from Model. >>>> This is to avoid nasty garbage to survive in DependentsFields with kilo >>>> bytes of un-released MCDefinition cache. >>> >>> Looks reasonable. Commit it and we'll find out soon if there are >>> problems. >>> >>> - Bert - >>> >>> >>> >>> >> > > |
Re: The Inbox: Monticello-nice.528.mcz
|
|
On 22.01.2013, at 13:31, "H. Hirzel" <[hidden email]> wrote: > What should we do about the 'Windows' subMenu? > > Rebuild it any time a menu is called? Or rebuild it any time a window is closed? Nil it out as soon as the window is closed. Perhaps like this? DockingBarUpdatingMenuMorph>>outOfWorld: aWorld self removeAllMorphs. "forget references held in menu items" ^super outOfWorld: aWorld - Bert - |
Re: The Inbox: Monticello-nice.528.mcz
|
|
If the menu points weakly, then it should be OK.
See Morphic-nice.635 in inbox. Nicolas 2013/1/22 Bert Freudenberg <[hidden email]>: > > On 22.01.2013, at 13:31, "H. Hirzel" <[hidden email]> wrote: >> What should we do about the 'Windows' subMenu? >> >> Rebuild it any time a menu is called? Or rebuild it any time a window is closed? > > > Nil it out as soon as the window is closed. Perhaps like this? > > DockingBarUpdatingMenuMorph>>outOfWorld: aWorld > self removeAllMorphs. "forget references held in menu items" > ^super outOfWorld: aWorld > > > - Bert - > > > |
Re: The Inbox: Monticello-nice.528.mcz
|
|
But it gets rebuilt every time it is shown anyway, so why bother making it weak?
- Bert - On 22.01.2013, at 13:58, Nicolas Cellier <[hidden email]> wrote: > If the menu points weakly, then it should be OK. > See Morphic-nice.635 in inbox. > > Nicolas > > 2013/1/22 Bert Freudenberg <[hidden email]>: >> >> On 22.01.2013, at 13:31, "H. Hirzel" <[hidden email]> wrote: >>> What should we do about the 'Windows' subMenu? >>> >>> Rebuild it any time a menu is called? Or rebuild it any time a window is closed? >> >> >> Nil it out as soon as the window is closed. Perhaps like this? >> >> DockingBarUpdatingMenuMorph>>outOfWorld: aWorld >> self removeAllMorphs. "forget references held in menu items" >> ^super outOfWorld: aWorld >> >> >> - Bert - >> >> >> > |
Re: The Inbox: Monticello-nice.528.mcz
|
|
Yes I answered too fast without reading your answer !
Your solution is by far simpler. I see that a DockingBarUpdatingMenuMorph always rebuild its menu as the name tells Nicolas 2013/1/22 Bert Freudenberg <[hidden email]>: > But it gets rebuilt every time it is shown anyway, so why bother making it weak? > > - Bert - > > On 22.01.2013, at 13:58, Nicolas Cellier <[hidden email]> wrote: > >> If the menu points weakly, then it should be OK. >> See Morphic-nice.635 in inbox. >> >> Nicolas >> >> 2013/1/22 Bert Freudenberg <[hidden email]>: >>> >>> On 22.01.2013, at 13:31, "H. Hirzel" <[hidden email]> wrote: >>>> What should we do about the 'Windows' subMenu? >>>> >>>> Rebuild it any time a menu is called? Or rebuild it any time a window is closed? >>> >>> >>> Nil it out as soon as the window is closed. Perhaps like this? >>> >>> DockingBarUpdatingMenuMorph>>outOfWorld: aWorld >>> self removeAllMorphs. "forget references held in menu items" >>> ^super outOfWorld: aWorld >>> >>> >>> - Bert - >>> >>> >>> >> > > > |
Re: The Inbox: Monticello-nice.528.mcz
|
|
Oh, I just saw an alternative wandering in the inbox:
http://source.squeak.org/inbox/Morphic-kb.619.diff Item was added: + ----- Method: DockingBarUpdatingMenuMorph>>delete (in category 'as yet unclassified') ----- + delete + + owner ifNotNil: [ + " When deleted remove my menu items, so I can avoid holding unwanted references to other objects. They will be updated anyway when I become visible again. " + " The owner notNil condition is necessary because MenuItemMorph >> select: sends delete before I become visible, but after the menu items are updated. " + self removeAllMorphs ]. + super delete! Nicolas 2013/1/22 Nicolas Cellier <[hidden email]>: > Yes I answered too fast without reading your answer ! > Your solution is by far simpler. > I see that a DockingBarUpdatingMenuMorph always rebuild its menu as > the name tells > > Nicolas > > 2013/1/22 Bert Freudenberg <[hidden email]>: >> But it gets rebuilt every time it is shown anyway, so why bother making it weak? >> >> - Bert - >> >> On 22.01.2013, at 13:58, Nicolas Cellier <[hidden email]> wrote: >> >>> If the menu points weakly, then it should be OK. >>> See Morphic-nice.635 in inbox. >>> >>> Nicolas >>> >>> 2013/1/22 Bert Freudenberg <[hidden email]>: >>>> >>>> On 22.01.2013, at 13:31, "H. Hirzel" <[hidden email]> wrote: >>>>> What should we do about the 'Windows' subMenu? >>>>> >>>>> Rebuild it any time a menu is called? Or rebuild it any time a window is closed? >>>> >>>> >>>> Nil it out as soon as the window is closed. Perhaps like this? >>>> >>>> DockingBarUpdatingMenuMorph>>outOfWorld: aWorld >>>> self removeAllMorphs. "forget references held in menu items" >>>> ^super outOfWorld: aWorld >>>> >>>> >>>> - Bert - >>>> >>>> >>>> >>> >> >> >> |
Re: The Inbox: Monticello-nice.528.mcz
|
|
Ah, I like this even better than my #outOfWorld: thing from Morphic-bf.635. I'll merge Ken's.
- Bert - On 23.01.2013, at 12:39, Nicolas Cellier <[hidden email]> wrote: > Oh, I just saw an alternative wandering in the inbox: > > http://source.squeak.org/inbox/Morphic-kb.619.diff > > Item was added: > + ----- Method: DockingBarUpdatingMenuMorph>>delete (in category 'as > yet unclassified') ----- > + delete > + > + owner ifNotNil: [ > + " When deleted remove my menu items, so I can avoid holding > unwanted references to other objects. They will be updated anyway when > I become visible again. " > + " The owner notNil condition is necessary because MenuItemMorph >> > select: sends delete before I become visible, but after the menu items > are updated. " > + self removeAllMorphs ]. > + super delete! > > Nicolas > > 2013/1/22 Nicolas Cellier <[hidden email]>: >> Yes I answered too fast without reading your answer ! >> Your solution is by far simpler. >> I see that a DockingBarUpdatingMenuMorph always rebuild its menu as >> the name tells >> >> Nicolas >> >> 2013/1/22 Bert Freudenberg <[hidden email]>: >>> But it gets rebuilt every time it is shown anyway, so why bother making it weak? >>> >>> - Bert - >>> >>> On 22.01.2013, at 13:58, Nicolas Cellier <[hidden email]> wrote: >>> >>>> If the menu points weakly, then it should be OK. >>>> See Morphic-nice.635 in inbox. >>>> >>>> Nicolas >>>> >>>> 2013/1/22 Bert Freudenberg <[hidden email]>: >>>>> >>>>> On 22.01.2013, at 13:31, "H. Hirzel" <[hidden email]> wrote: >>>>>> What should we do about the 'Windows' subMenu? >>>>>> >>>>>> Rebuild it any time a menu is called? Or rebuild it any time a window is closed? >>>>> >>>>> >>>>> Nil it out as soon as the window is closed. Perhaps like this? >>>>> >>>>> DockingBarUpdatingMenuMorph>>outOfWorld: aWorld >>>>> self removeAllMorphs. "forget references held in menu items" >>>>> ^super outOfWorld: aWorld >>>>> >>>>> >>>>> - Bert - |
Re: The Inbox: Monticello-nice.528.mcz
|
|
kb ?= Balazs Kosi
Nicolas 2013/1/23 Bert Freudenberg <[hidden email]>: > Ah, I like this even better than my #outOfWorld: thing from Morphic-bf.635. I'll merge Ken's. > > - Bert - > > On 23.01.2013, at 12:39, Nicolas Cellier <[hidden email]> wrote: > >> Oh, I just saw an alternative wandering in the inbox: >> >> http://source.squeak.org/inbox/Morphic-kb.619.diff >> >> Item was added: >> + ----- Method: DockingBarUpdatingMenuMorph>>delete (in category 'as >> yet unclassified') ----- >> + delete >> + >> + owner ifNotNil: [ >> + " When deleted remove my menu items, so I can avoid holding >> unwanted references to other objects. They will be updated anyway when >> I become visible again. " >> + " The owner notNil condition is necessary because MenuItemMorph >> >> select: sends delete before I become visible, but after the menu items >> are updated. " >> + self removeAllMorphs ]. >> + super delete! >> >> Nicolas >> >> 2013/1/22 Nicolas Cellier <[hidden email]>: >>> Yes I answered too fast without reading your answer ! >>> Your solution is by far simpler. >>> I see that a DockingBarUpdatingMenuMorph always rebuild its menu as >>> the name tells >>> >>> Nicolas >>> >>> 2013/1/22 Bert Freudenberg <[hidden email]>: >>>> But it gets rebuilt every time it is shown anyway, so why bother making it weak? >>>> >>>> - Bert - >>>> >>>> On 22.01.2013, at 13:58, Nicolas Cellier <[hidden email]> wrote: >>>> >>>>> If the menu points weakly, then it should be OK. >>>>> See Morphic-nice.635 in inbox. >>>>> >>>>> Nicolas >>>>> >>>>> 2013/1/22 Bert Freudenberg <[hidden email]>: >>>>>> >>>>>> On 22.01.2013, at 13:31, "H. Hirzel" <[hidden email]> wrote: >>>>>>> What should we do about the 'Windows' subMenu? >>>>>>> >>>>>>> Rebuild it any time a menu is called? Or rebuild it any time a window is closed? >>>>>> >>>>>> >>>>>> Nil it out as soon as the window is closed. Perhaps like this? >>>>>> >>>>>> DockingBarUpdatingMenuMorph>>outOfWorld: aWorld >>>>>> self removeAllMorphs. "forget references held in menu items" >>>>>> ^super outOfWorld: aWorld >>>>>> >>>>>> >>>>>> - Bert - > > > > |
Re: The Inbox: Monticello-nice.528.mcz
|
|
On 23.01.2013, at 14:11, Nicolas Cellier <[hidden email]> wrote: > kb ?= Balazs Kosi > > Nicolas Oh those Hungarians again ;) Sorry Balázs. - Bert - > > 2013/1/23 Bert Freudenberg <[hidden email]>: >> Ah, I like this even better than my #outOfWorld: thing from Morphic-bf.635. I'll merge Ken's. >> >> - Bert - >> >> On 23.01.2013, at 12:39, Nicolas Cellier <[hidden email]> wrote: >> >>> Oh, I just saw an alternative wandering in the inbox: >>> >>> http://source.squeak.org/inbox/Morphic-kb.619.diff >>> >>> Item was added: >>> + ----- Method: DockingBarUpdatingMenuMorph>>delete (in category 'as >>> yet unclassified') ----- >>> + delete >>> + >>> + owner ifNotNil: [ >>> + " When deleted remove my menu items, so I can avoid holding >>> unwanted references to other objects. They will be updated anyway when >>> I become visible again. " >>> + " The owner notNil condition is necessary because MenuItemMorph >> >>> select: sends delete before I become visible, but after the menu items >>> are updated. " >>> + self removeAllMorphs ]. >>> + super delete! >>> >>> Nicolas >>> >>> 2013/1/22 Nicolas Cellier <[hidden email]>: >>>> Yes I answered too fast without reading your answer ! >>>> Your solution is by far simpler. >>>> I see that a DockingBarUpdatingMenuMorph always rebuild its menu as >>>> the name tells >>>> >>>> Nicolas >>>> >>>> 2013/1/22 Bert Freudenberg <[hidden email]>: >>>>> But it gets rebuilt every time it is shown anyway, so why bother making it weak? >>>>> >>>>> - Bert - >>>>> >>>>> On 22.01.2013, at 13:58, Nicolas Cellier <[hidden email]> wrote: >>>>> >>>>>> If the menu points weakly, then it should be OK. >>>>>> See Morphic-nice.635 in inbox. >>>>>> >>>>>> Nicolas >>>>>> >>>>>> 2013/1/22 Bert Freudenberg <[hidden email]>: >>>>>>> >>>>>>> On 22.01.2013, at 13:31, "H. Hirzel" <[hidden email]> wrote: >>>>>>>> What should we do about the 'Windows' subMenu? >>>>>>>> >>>>>>>> Rebuild it any time a menu is called? Or rebuild it any time a window is closed? >>>>>>> >>>>>>> >>>>>>> Nil it out as soon as the window is closed. Perhaps like this? >>>>>>> >>>>>>> DockingBarUpdatingMenuMorph>>outOfWorld: aWorld >>>>>>> self removeAllMorphs. "forget references held in menu items" >>>>>>> ^super outOfWorld: aWorld >>>>>>> >>>>>>> >>>>>>> - Bert - >> >> >> >> > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |