November 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Igor Stasenko

2009/11/2 Yoshiki Ohshima <yoshiki(a)vpri.org>: > At Mon, 2 Nov 2009 19:18:09 +0100, > Lukas Renggli wrote: >> >> > Please, can you elaborate, what you consider 'broken features' and why? >> > I am also not a fan of using flawed stuff. >> >> Weak objects are flawed in Pharo and Squeak. If you have an unbounded >> number of weak references it can quickly happen that the system spends >> 95% or more of the CPU cleaning up the weak references. For Seaside >> 2.8 we spent quite some time in getting rid of all weak references, >> afterwards we had a cleaner, easier to understand and much faster >> solution. > > Â Just to be clear. Â Is it because the need to process the dictionary > that registers the objects needs to be finalized, right? Â For this > case, these subscriptions objects don't have to be finalized, I > think. Â The subscriber holds onto a WeakArray of size one, and the > element just becomes nil. Â And when announcing something, you can just > skip (and remove) subscription objects who have nil subscribers. > Yes.. i came to same conclusion and started implementing it, but then backstabbed with impossibility to make block-based subscriptions weak. :) Since we expect that eventually there will be a new announcement, we could wipe weak entries during this cycle. Keeping a garbage entries until new announcement will come don't seem to be a big problem. > Â Or, is there actually a problem just having weak arrays? > No, i think the main issue is an overhead of squeak's finalization logic. > -- Yoshiki > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 2, 2009

Re: [Pharo-project] Fwd: MouseOverHandler

by Hernan Wilkinson

I compleatly agree, and I had a version that saves a dump when that happened because it is imposible to find it out just reading the code... On Mon, Nov 2, 2009 at 5:27 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Hi gary > do you think that it make sense to have it in general (my gut feeling > is saying yes but I'm not thread-safe) > > If yes, yes we are interested for 1.1 > > BTW hernan I integrated your changes now it would be interesting to > understand from where this nil is coming. > > Stef > On Nov 2, 2009, at 8:58 PM, Gary Chambers wrote: > > > Yet the cause is unexplained. I still think it is due to non-ui > > processes fiddling with morphs (likely delettion or creation). > > The Morphic event loop remains non-thread safe. We have some > > modifications to ensure thread safety, based on a generalised > > synchronisation protocol if anyone is interested. > > > > Regards, Gary > > ----- Original Message ----- > > From: Hernan Wilkinson > > To: Pharo-project(a)lists.gforge.inria.fr > > Sent: Monday, November 02, 2009 7:45 PM > > Subject: Re: [Pharo-project] Fwd: MouseOverHandler > > > > Hi Adrian, > > the current implementation has problems, ie. send messages to nil, > > and it bothers a lot when that happens because it comes from > > nowhere... > > I've been using this implementation for a long time in my images > > and I did not get those problems anymore (and it is more readable...) > > > > On Sat, Oct 31, 2009 at 2:41 PM, Adrian Lienhard <adi(a)netstyle.ch> > > wrote: > > Hi Hernan, > > > > The reason this was not integrated is that nobody marked it as 'fixed' > > nor tagged it as 1.0. > > > > Is this critical for 1.0? > > > > Cheers, > > Adrian > > > > BTW, if anybody sees changes/fixes not being integrated please ask on > > the mailing list. > > > > > > On Oct 31, 2009, at 14:29 , StÃ©phane Ducasse wrote: > > > > > > > > > > > Begin forwarded message: > > > > > >> From: Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > > >> Date: October 29, 2009 2:02:32 PM GMT+01:00 > > >> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > >> Subject: MouseOverHandler > > >> > > >> Hi Stef, > > >> do you know why the MouseOverHandler version I made is not in the > > >> main image? the current version is not working well, under heavy > > >> use it generates exceptions... > > >> I'm attaching the version I wrote that I'm using without > > problem... > > >> > > >> Hernan. > > > <MouseOverHandler.st> > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 2, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Alain Plantec

Igor Stasenko wrote: > 2009/11/1 Tudor Girba <tudor.girba(a)gmail.com>: > >> Indeed, the main and only goal of Announcement is to provide an object- >> oriented (Exception-like) way to handle notifications. >> >> I have used the Announcements implementation of Lukas on several >> occasions and I did not feel the need for anything else. >> >> You indeed should subclass Announcement for any specific announcement, >> but that is not a drawback, it is a nice feature. If you want to have >> an announcement that you want to identify by a special single field, >> you are free to implement that in one announcement class on top. >> >> > > Thanks Doru. Indeed, its a feature, but not a rule which everyone should follow. > Hi Igor and all, just reading this interesting thread... > In other thread, I had proposed to use field to identify an event type > instead of class, and someone said > that i'm doing it wrong. > I guess you speak about my remark in the "ClassOrganizer oddities" thread. Here is what I said: ------------------------------------- > You defined a set of announcement classes, each one is for a particular > kind of event. > So, no need for #changeKind and #parameters dictionary instance variable > (please no!). -------- end---------- just to be clear, the "please no!" was for the dictionary because it can make the code difficult to maintain (Morph properties ...). why not the #changeKind variable even I prefer expressing them by subclasses. > While i thinking that the way how the framework identifies events > kinds (by default) not always best one, and as i illustrated its not > good for everything. > yes and having a well defined announce hierarchy is not so easy. Cheers Alain

Nov. 2, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Yoshiki Ohshima

At Mon, 2 Nov 2009 19:18:09 +0100, Lukas Renggli wrote: > > > Please, can you elaborate, what you consider 'broken features' and why? > > I am also not a fan of using flawed stuff. > > Weak objects are flawed in Pharo and Squeak. If you have an unbounded > number of weak references it can quickly happen that the system spends > 95% or more of the CPU cleaning up the weak references. For Seaside > 2.8 we spent quite some time in getting rid of all weak references, > afterwards we had a cleaner, easier to understand and much faster > solution. Just to be clear. Is it because the need to process the dictionary that registers the objects needs to be finalized, right? For this case, these subscriptions objects don't have to be finalized, I think. The subscriber holds onto a WeakArray of size one, and the element just becomes nil. And when announcing something, you can just skip (and remove) subscription objects who have nil subscribers. Or, is there actually a problem just having weak arrays? -- Yoshiki

Nov. 2, 2009

Re: [Pharo-project] Making packages shipped with Pharo ready for 1.0

by Adrian Lienhard

Damien, I checked the problem below again in the new Pharo 09.11.1 image but it still contains the old method OBMethodNode>>dropOnClass:, which references InputSensor. Maybe you need to sync with Lukas to get the latest version of OB? Thanks Adrian On Oct 27, 2009, at 17:36 , Lukas Renggli wrote: >> - #dropOnClass: references InputSensor (this class does not exist >> anymore!) > > That was fixed a long time ago. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > <rb.pdf>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 2, 2009

Re: [Pharo-project] Fwd: MouseOverHandler

by StÃ©phane Ducasse

Hi gary do you think that it make sense to have it in general (my gut feeling is saying yes but I'm not thread-safe) If yes, yes we are interested for 1.1 BTW hernan I integrated your changes now it would be interesting to understand from where this nil is coming. Stef On Nov 2, 2009, at 8:58 PM, Gary Chambers wrote: > Yet the cause is unexplained. I still think it is due to non-ui > processes fiddling with morphs (likely delettion or creation). > The Morphic event loop remains non-thread safe. We have some > modifications to ensure thread safety, based on a generalised > synchronisation protocol if anyone is interested. > > Regards, Gary > ----- Original Message ----- > From: Hernan Wilkinson > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Monday, November 02, 2009 7:45 PM > Subject: Re: [Pharo-project] Fwd: MouseOverHandler > > Hi Adrian, > the current implementation has problems, ie. send messages to nil, > and it bothers a lot when that happens because it comes from > nowhere... > I've been using this implementation for a long time in my images > and I did not get those problems anymore (and it is more readable...) > > On Sat, Oct 31, 2009 at 2:41 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > Hi Hernan, > > The reason this was not integrated is that nobody marked it as 'fixed' > nor tagged it as 1.0. > > Is this critical for 1.0? > > Cheers, > Adrian > > BTW, if anybody sees changes/fixes not being integrated please ask on > the mailing list. > > > On Oct 31, 2009, at 14:29 , StÃ©phane Ducasse wrote: > > > > > > > Begin forwarded message: > > > >> From: Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > >> Date: October 29, 2009 2:02:32 PM GMT+01:00 > >> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> Subject: MouseOverHandler > >> > >> Hi Stef, > >> do you know why the MouseOverHandler version I made is not in the > >> main image? the current version is not working well, under heavy > >> use it generates exceptions... > >> I'm attaching the version I wrote that I'm using without > problem... > >> > >> Hernan. > > <MouseOverHandler.st> > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 2, 2009

Re: [Pharo-project] http://www.pharo-project.org/ seems to be down

by Mariano Martinez Peck

Ups...sorry then On Mon, Nov 2, 2009 at 4:17 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > We had a scheduled maintenance downtime of 1h last night. > > Adrian > > On Nov 2, 2009, at 00:23 , Mariano Martinez Peck wrote: > > > http://downforeveryoneorjustme.com/http://www.pharo-project.org/ > > > > best, > > > > Mariano > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 2, 2009

Re: [Pharo-project] Problem with low-space watcher

by Igor Stasenko

2009/11/2 Gary Chambers <gazzaguru2(a)btinternet.com>: > Project interruptName: labelString preemptedProcess: theInterruptedProcess > > sends #offList to the return value of suspend of the preempted process > (which answers a LinkedList). > The message is not understood but does not cause a debugger to open, Alt-. > shows the stack trace in the end. > Just remove the #offList send, its obsolete and no longer needed. > One way to replicate: > > (Object allSubInstances select: [:o | o dependents notEmpty]) collect: [:o | > Â o dependents size] > > Was just mulling things in light of Announcement discussions as to whether > the dependency could have a single subscriber (most common case) for > possible performance gains, a collection if additonal subscribers get added. > > > Regards, Gary > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 2, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Igor Stasenko

2009/11/2 Lukas Renggli <renggli(a)gmail.com>: >>>> I implemented a new announcer, which covers all functionality of the >>>> original one >>>> (all tests is green) but in addition enables you to subscribe directly via >>>> #subscribe: >>>> and receive #handle: message in case of announcements. >>>> Of course, the decision whether to handle or ignore announcement is up >>>> to subscriber. >>> >>> Can you give an example? I don't get it. >> >> you can subscribe using: >> >> announcer subscribe: object. >> >> and unsubscribe using: >> >> announcer unsubscribe: object. > > Ok, now I get it. > > I wonder why this would be useful? > > Also it looks to me like very bad programming style, as the > specification of what to handle and the handler itself are merged. there is no specification what to handle, because in my implementation the Announcer doesn't having any knowledge about nature of subscriptions. Its only task is to broadcast the announcement to all subscribers without any extraneous logic - consider an observer pattern in its purest form. Then there are a special kind of subscription, which handling announcements in style which were originally made for Announcer. And finally, i could turn your own argument back to you: why its Announcement deciding whether subscriber interested in it or not, by implementing checks in #handles: method at class side? Isn't this a mixing of 'what to handle' and 'handler' roles? > You > can do that also with the original API, but it is less encouraging > because you have to hand in twice the same object into #on:do:. > passing twice? I think you meant passing once, i.e.: announcer on: Announcement do: self which can be a roughly equivalent to announcer subcscribe: self. except that this case you will need to implement own #valueWithArguments: and #receiver methods while in my variant - #handle: , and except that current framework will do unnecessary #isKindOf: checks before delivering announcement to such handler. > Also, have a look at the Exception API. Announcements solve a similar > problem and provide a similar API. It would be a pity to break that > similarity. I've never seen a single project that extended the > exception API, there the simple message #on:do: is enough for > everybody. > but there is #on:do:! So, if one think its enough for him - no problem just use it, and forget about #subscribe:. How it breaks the similarity (which i find good myself btw), when it providing same functionality as current one? By enabling more generic form of subscription? Oh cmon... >> Please, can you elaborate, what you consider 'broken features' and why? >> I am also not a fan of using flawed stuff. > > Weak objects are flawed in Pharo and Squeak. If you have an unbounded > number of weak references it can quickly happen that the system spends > 95% or more of the CPU cleaning up the weak references. For Seaside > 2.8 we spent quite some time in getting rid of all weak references, > afterwards we had a cleaner, easier to understand and much faster > solution. > i don't expect too many subscribers to a single announcer (do you?), and the number of weak ones could be even less than that. I think that if announcer keeps more than 10-20 subscribers, it will already a signal that you start abusing framework. :) So i don't think that cleaning it up will be an issue or bottleneck in this case. And of course i am aware of potential pitfalls of weak finalization in squeak. But hey: we don't care about managing memory in smalltalk, why we should abandon idea to have an automatically managed weak subscriptions? Since you usually never send #dispose/#free for each corresponding #new, it is logical to have an option to never send #unsubscribe: for each corresponding #subscribe: , isnt? It imples some discipline? Yeah. As well as #new does, because if you attempt to allocate memory in a run-away fashion, you will end-up with memory overflow. >> That's why i talking about limitations of weak block subscriptions. >> While weak message subscriptions is easy to provide, using >> WeakMessageSend. > > I guess you could copy the BlockClosure, no? > This will give nothing. The problem that BlockClosure holding all references strongly, as well as any context object. And even worse - the real subscriber (our object of interest) is not held directly by a closure, but by its home context object. And there is no guarantees that given context's state keeps reference to subscriber only in 'receiver' slot. It could be kept in temps or temps could reference the receiver etc etc. And you can't hold a BlockClosure weakly, because it will vanish once you exit from #on:do: method. So, the only solution is to keep it strongly as long as receiver are referenced strongly by something outside the BlockClosure references subgraph. This is what ephemeron does, but its impossible to implement using weak refs. > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 2, 2009

Re: [Pharo-project] Fwd: MouseOverHandler

by Gary Chambers

Yet the cause is unexplained. I still think it is due to non-ui processes fiddling with morphs (likely delettion or creation). The Morphic event loop remains non-thread safe. We have some modifications to ensure thread safety, based on a generalised synchronisation protocol if anyone is interested. Regards, Gary ----- Original Message ----- From: Hernan Wilkinson To: Pharo-project(a)lists.gforge.inria.fr Sent: Monday, November 02, 2009 7:45 PM Subject: Re: [Pharo-project] Fwd: MouseOverHandler Hi Adrian, the current implementation has problems, ie. send messages to nil, and it bothers a lot when that happens because it comes from nowhere... I've been using this implementation for a long time in my images and I did not get those problems anymore (and it is more readable...) On Sat, Oct 31, 2009 at 2:41 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: Hi Hernan, The reason this was not integrated is that nobody marked it as 'fixed' nor tagged it as 1.0. Is this critical for 1.0? Cheers, Adrian BTW, if anybody sees changes/fixes not being integrated please ask on the mailing list. On Oct 31, 2009, at 14:29 , StÃ©phane Ducasse wrote: > > > Begin forwarded message: > >> From: Hernan Wilkinson <hernan.wilkinson(a)gmail.com> >> Date: October 29, 2009 2:02:32 PM GMT+01:00 >> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> Subject: MouseOverHandler >> >> Hi Stef, >> do you know why the MouseOverHandler version I made is not in the >> main image? the current version is not working well, under heavy >> use it generates exceptions... >> I'm attaching the version I wrote that I'm using without problem... >> >> Hernan. > <MouseOverHandler.st> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ------------------------------------------------------------------------------ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 2, 2009