September 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] An idea about visual feedback in Athens

by StÃ©phane Ducasse

Yes we should really refactor this hierarchy. We should finish first the event model cleaning at VM/Image border then we work on this one. On Aug 31, 2012, at 9:21 PM, Igor Stasenko wrote: > and to give an idea, how current Morphic doing that, a starting point is > MorphicEventDispatcher > > personally, i find this code too complex to understand, given heavy > use of case statements and branches. > > But i figured out, that this method: > > > dispatchEvent: anEvent with: aMorph > "Dispatch the given event for a morph that has chosen the receiver to > dispatch its events. The method implements a shortcut for repeated > dispatches of events using the same dispatcher." > anEvent type == lastType ifTrue:[^self perform: lastDispatch with: > anEvent with: aMorph]. > "Otherwise classify" > lastType := anEvent type. > anEvent isMouse ifTrue:[ > anEvent isMouseDown ifTrue:[ > lastDispatch := #dispatchMouseDown:with:. > ^self dispatchMouseDown: anEvent with: aMorph]]. > anEvent type == #dropEvent ifTrue:[ > lastDispatch := #dispatchDropEvent:with:. > ^self dispatchDropEvent: anEvent with: aMorph]. > anEvent isWindowEvent ifTrue:[ > lastDispatch := #dispatchWindowEvent:with:. > ^self dispatchWindowEvent: anEvent with: aMorph]. > lastDispatch := #dispatchDefault:with:. > ^self dispatchDefault: anEvent with: aMorph > > --- > > actually can be replaced by one-liner: > > dispatchEvent: anEvent with: aMorph > morph := aMorph. > ^ anEvent sentTo: self > > .. yeah.. my favorite thing: double-dispatch. > > -- > Best regards, > Igor Stasenko. >

Sept. 2, 2012

Re: [Pharo-project] [Nautilus] Someone needs to learn how to work with weak references :) + [Enh] patch to object explorer

by Igor Stasenko

Actually, speaking about the problem of locating memory leaks, by filtering out useless stuff, it looks like quite simple to implement: you just need to trace path(s) from system root (such as Smalltalk global object) to the object of interest. A shortest path found, in most cases, will be the answer to problem. -- Best regards, Igor Stasenko.

Sept. 2, 2012

Re: [Pharo-project] [Nautilus] Someone needs to learn how to work with weak references :) + [Enh] patch to object explorer

by Igor Stasenko

On 2 September 2012 06:00, Lawson English <lenglish5(a)cox.net> wrote: > Igor, have you been following Craig Latta's work with Naev/Spoon? > > He's had to create some very interesting tools to track objects of various > kinds in the image. > Well, Spoon was one of the first things i learned besides squeak. I know Craig has some visualizations done for looking at object memory using human's eyes.. but without ways to filter out the noise (which requires some coding), any visualization is basically useless, because of the amount of information. > L > > > On 9/1/12 6:31 PM, Igor Stasenko wrote: >> >> my work image grown to 80Mb in size.. >> and i start growing suspicious about myself for forming a resource >> leak somewhere.. >> >> But as it appears, it is because of Nautilus. >> >> During my experiments with ObjC wrapper for NativeBoost, >> i used nautilus for showing more than 4000 Objective-C classes in >> browser.. >> >> Since all those objects are actually wrappers, they generated each >> time when i open a new browser window.. >> to explore an obj-c universe and to test bugs.. >> So i ended up with: >> ObjCClassWrapper allInstances size 31885 >> >> Now, about why cache doesn't cleaning up automatically: >> >> The only reference coming to particular instance of ObjC wrapper is >> from a ClassesIconCache class var, >> which is a weak key dictionary: >> >> {my class wrapper} -> [IconicButtonStateHolder] >> >> so, a {wrapper} is held weakly here, of course, while [its Icon] >> strongly, and so far so good. >> >> But the problem is that , [IconicButtonStateHolder] >> having following in it's arguments ivar: >> >> an Array(an ObjCClassWrapper), which is [my class wrapper], held strongly. >> >> of course, there is no way how it can disappear from system.. >> >> After doing "AbstractNautilusUI resetIconCaches" my image shrunk from >> 83Mb down to 43Mb, >> >> But i found that i still having a lot of ObjCClassWrapper hanging >> around and wonder why.. >> And this time, because one of the wrapper classes were held in >> HistoryCollection via Nautilus 'RecentClasses' classvar. >> I think, history should not keep a live object references.. but >> instead use symbolic names to refer to the target, >> because apparently you cannot go and browse the method/class if you >> deleted it from a system. >> >> So, after nilling out that class var, my image lost another 10Mb, down to >> 33Mb.. >> and Ben, you owe me a ... (o shit i don't drink beer ) oh ok.. you owe >> me 2 bug fixes in Nautilus :) >> >> P.S. i modified a pointer explorer to show only strong references to >> object(s), >> because weak ones are completely useless for fighting with resource >> leak problems and only add noise. >> With this change a lists produced by pointer explorer are much shorter >> and going straight to the point. >> So, i attaching .cs to the mail.. in case if someone find it useful. >> >> >> > > > -- > Squeak from the very start (introduction to Squeak and Pharo Smalltalk for > the (almost) complete and compleate beginner). > https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all > -- Best regards, Igor Stasenko.

Sept. 2, 2012

Re: [Pharo-project] [Nautilus] Someone needs to learn how to work with weak references :) + [Enh] patch to object explorer

by Lawson English

Igor, have you been following Craig Latta's work with Naev/Spoon? He's had to create some very interesting tools to track objects of various kinds in the image. L On 9/1/12 6:31 PM, Igor Stasenko wrote: > my work image grown to 80Mb in size.. > and i start growing suspicious about myself for forming a resource > leak somewhere.. > > But as it appears, it is because of Nautilus. > > During my experiments with ObjC wrapper for NativeBoost, > i used nautilus for showing more than 4000 Objective-C classes in browser.. > > Since all those objects are actually wrappers, they generated each > time when i open a new browser window.. > to explore an obj-c universe and to test bugs.. > So i ended up with: > ObjCClassWrapper allInstances size 31885 > > Now, about why cache doesn't cleaning up automatically: > > The only reference coming to particular instance of ObjC wrapper is > from a ClassesIconCache class var, > which is a weak key dictionary: > > {my class wrapper} -> [IconicButtonStateHolder] > > so, a {wrapper} is held weakly here, of course, while [its Icon] > strongly, and so far so good. > > But the problem is that , [IconicButtonStateHolder] > having following in it's arguments ivar: > > an Array(an ObjCClassWrapper), which is [my class wrapper], held strongly. > > of course, there is no way how it can disappear from system.. > > After doing "AbstractNautilusUI resetIconCaches" my image shrunk from > 83Mb down to 43Mb, > > But i found that i still having a lot of ObjCClassWrapper hanging > around and wonder why.. > And this time, because one of the wrapper classes were held in > HistoryCollection via Nautilus 'RecentClasses' classvar. > I think, history should not keep a live object references.. but > instead use symbolic names to refer to the target, > because apparently you cannot go and browse the method/class if you > deleted it from a system. > > So, after nilling out that class var, my image lost another 10Mb, down to 33Mb.. > and Ben, you owe me a ... (o shit i don't drink beer ) oh ok.. you owe > me 2 bug fixes in Nautilus :) > > P.S. i modified a pointer explorer to show only strong references to object(s), > because weak ones are completely useless for fighting with resource > leak problems and only add noise. > With this change a lists produced by pointer explorer are much shorter > and going straight to the point. > So, i attaching .cs to the mail.. in case if someone find it useful. > > > -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all

Sept. 2, 2012

Re: [Pharo-project] [Nautilus] Someone needs to learn how to work with weak references :) + [Enh] patch to object explorer

by Igor Stasenko

p.p.p.s. perhaps we could add it as option "explore only strong references" in inspector menu -- Best regards, Igor Stasenko.

Sept. 2, 2012

[Pharo-project] [Nautilus] Someone needs to learn how to work with weak references :) + [Enh] patch to object explorer

by Igor Stasenko

my work image grown to 80Mb in size.. and i start growing suspicious about myself for forming a resource leak somewhere.. But as it appears, it is because of Nautilus. During my experiments with ObjC wrapper for NativeBoost, i used nautilus for showing more than 4000 Objective-C classes in browser.. Since all those objects are actually wrappers, they generated each time when i open a new browser window.. to explore an obj-c universe and to test bugs.. So i ended up with: ObjCClassWrapper allInstances size 31885 Now, about why cache doesn't cleaning up automatically: The only reference coming to particular instance of ObjC wrapper is from a ClassesIconCache class var, which is a weak key dictionary: {my class wrapper} -> [IconicButtonStateHolder] so, a {wrapper} is held weakly here, of course, while [its Icon] strongly, and so far so good. But the problem is that , [IconicButtonStateHolder] having following in it's arguments ivar: an Array(an ObjCClassWrapper), which is [my class wrapper], held strongly. of course, there is no way how it can disappear from system.. After doing "AbstractNautilusUI resetIconCaches" my image shrunk from 83Mb down to 43Mb, But i found that i still having a lot of ObjCClassWrapper hanging around and wonder why.. And this time, because one of the wrapper classes were held in HistoryCollection via Nautilus 'RecentClasses' classvar. I think, history should not keep a live object references.. but instead use symbolic names to refer to the target, because apparently you cannot go and browse the method/class if you deleted it from a system. So, after nilling out that class var, my image lost another 10Mb, down to 33Mb.. and Ben, you owe me a ... (o shit i don't drink beer ) oh ok.. you owe me 2 bug fixes in Nautilus :) P.S. i modified a pointer explorer to show only strong references to object(s), because weak ones are completely useless for fighting with resource leak problems and only add noise. With this change a lists produced by pointer explorer are much shorter and going straight to the point. So, i attaching .cs to the mail.. in case if someone find it useful. -- Best regards, Igor Stasenko.

Sept. 2, 2012

Re: [Pharo-project] ProgressBar improvements

by Igor Stasenko

i seen it in action, looks nice. -- Best regards, Igor Stasenko.

Sept. 1, 2012

Re: [Pharo-project] ProgressBar improvements

by Camillo Bruni

sssh it's secret https://code.google.com/p/pharo/issues/detail?id=5874 have fun On 2012-09-01, at 20:50, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Which slice ? > > Ben > > On Sep 1, 2012, at 8:48 PM, Camillo Bruni wrote: > >> Sean and I worked on a proof of concept for a new progress handling >> at ESUG. Over the last 2 days I refactored what we did and pushed >> it into a Slice on PharoInbox. >> >> At this time it would be nice if someone else could have a look at >> it and say what they think about it :). >> >> see: Job>>basicExample for more details. >> >> best >> cami >> > >

Sept. 1, 2012

Re: [Pharo-project] ProgressBar improvements

by Benjamin

Which slice ? Ben On Sep 1, 2012, at 8:48 PM, Camillo Bruni wrote: > Sean and I worked on a proof of concept for a new progress handling > at ESUG. Over the last 2 days I refactored what we did and pushed > it into a Slice on PharoInbox. > > At this time it would be nice if someone else could have a look at > it and say what they think about it :). > > see: Job>>basicExample for more details. > > best > cami >

Sept. 1, 2012

[Pharo-project] ProgressBar improvements

by Camillo Bruni

Sean and I worked on a proof of concept for a new progress handling at ESUG. Over the last 2 days I refactored what we did and pushed it into a Slice on PharoInbox. At this time it would be nice if someone else could have a look at it and say what they think about it :). see: Job>>basicExample for more details. best cami

Sept. 1, 2012