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 Sun, 1 Nov 2009 20:22:48 +0200, > Igor Stasenko wrote: >> >> > Â If "can be logged" means to have #canBeLogged method that returns >> > true, you could also say (given that you provide a default >> > implementation of #canBeLogged at a/the root): >> > >> > logblock := [:announcement | announcement canBeLogged ifTrue: [... ]]. >> > announcer on: Announcement do: logblock. >> > >> i dont want to nitpick , but since you subscribing to the Announcement class, >> this means that you need to put an extension method #canBeLogged into it. >> >> And we started this discussion from question: is Announcements >> framework is generic enough >> and won't require more coding. But extending it is already means 'more >> code' Â in base. > > Â Well, I said "if". Â And if you really don't want to have an > extension method in the base, you can say something like: > > Â (announcement instVarNames includes: 'canBeLogged') ifTrue: [...] > > or any other ways that don't require an extension method in the core. > The point was that you don't have to have all 35 classes listed upfront. > yes. >> > Loading a package with new subclasses of Announcement is not a >> > problem. Â And, a recipient ignoring an announcement that it doesn't >> > handle is somewhat common, when I used my own implementation for my >> > projects. >> > >> > Â If you implement an observer pattern to accommodate the new package >> > loading requirement, what would be the strategy to implement it? >> > >> Not necessarily a new package. The problem is, that i don't want to >> modify multiple places in system if i reconsider whether something can >> be logged or not, as well as i want to be sure that my code will >> handle all and any potential changes in future without the need of any >> modifications in my code. > > Â Ok... But announcement or not, you need a way to tell a notification > "can be logged". > Sure thing. >> Another question , which Stephane noted already, is the overhead of >> broadcasting. >> >> In Announcer>>announce: >> it iterating over all subscriptions to determine which one may want to >> receive an announcement or not. >> >> Â Â Â subscriptions keysAndValuesDo: [ :class :actions | >> Â Â Â Â Â Â Â (class handles: announcement) >> Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ actions valueWithArguments: (Array with: announcement) ] ]. >> >> but if we can't avoid iteration, then why ASKING but not TELLING to handle it: >> >> Â Â Â subscriptions do: [ :subscriber | subscriber handle: announcement ]. >> >> (subscriptions collection can be just a Set in this case) >> and then , a particular subscriber could decide whether he interested >> in given announcement or not, >> based on own criteria (such as #canBeLogged etc). >> >> And surely, we can provide a subscriber class, which can use the same >> logic, to determine if it interested in particular announcement, based >> on announcement class. >> This could make the whole thing more flexible. > > Â But the client side code will be more messy. Â An object will have > only one implementation of #handle:, and whenever you want to add a > new thing to be handled by the object, it ends up with adding a new if > clauses inside it. > the #handle: is an entry point, where subscriber could decide what to do with announcement. And of course, you can introduce messy testing code if you need. But its up to you, not up to Announcement framework. See the difference? My point is, that #isKindOf: test is not always single one or best one, which can be used to test the relevance of announcement to subscriber. We having a Traits, right? Now imagine that i could control, whether announcement can be logged or not, by simply using or not using a trait in my announcement subclasses. It can be even a trait with no methods, but i can use this information to check if given announcement is relevant to my subscriber. And as result: zero new methods, no extensions to core and very convenient way to promote announcement to be a logged one. Just one requirement: give me a way to define own means to check the relevance to subscriber :) > Â (Something more flexible and loose-coupling than Announcement would > be really good, I agree.) > > -- 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] About AXAnnouncements (was: some Announcements related questions)

by Yoshiki Ohshima

At Sun, 1 Nov 2009 20:22:48 +0200, Igor Stasenko wrote: > > > Â If "can be logged" means to have #canBeLogged method that returns > > true, you could also say (given that you provide a default > > implementation of #canBeLogged at a/the root): > > > > logblock := [:announcement | announcement canBeLogged ifTrue: [... ]]. > > announcer on: Announcement do: logblock. > > > i dont want to nitpick , but since you subscribing to the Announcement class, > this means that you need to put an extension method #canBeLogged into it. > > And we started this discussion from question: is Announcements > framework is generic enough > and won't require more coding. But extending it is already means 'more > code' in base. Well, I said "if". And if you really don't want to have an extension method in the base, you can say something like: (announcement instVarNames includes: 'canBeLogged') ifTrue: [...] or any other ways that don't require an extension method in the core. The point was that you don't have to have all 35 classes listed upfront. > > Loading a package with new subclasses of Announcement is not a > > problem. Â And, a recipient ignoring an announcement that it doesn't > > handle is somewhat common, when I used my own implementation for my > > projects. > > > > Â If you implement an observer pattern to accommodate the new package > > loading requirement, what would be the strategy to implement it? > > > Not necessarily a new package. The problem is, that i don't want to > modify multiple places in system if i reconsider whether something can > be logged or not, as well as i want to be sure that my code will > handle all and any potential changes in future without the need of any > modifications in my code. Ok... But announcement or not, you need a way to tell a notification "can be logged". > Another question , which Stephane noted already, is the overhead of > broadcasting. > > In Announcer>>announce: > it iterating over all subscriptions to determine which one may want to > receive an announcement or not. > > subscriptions keysAndValuesDo: [ :class :actions | > (class handles: announcement) > ifTrue: [ actions valueWithArguments: (Array with: announcement) ] ]. > > but if we can't avoid iteration, then why ASKING but not TELLING to handle it: > > subscriptions do: [ :subscriber | subscriber handle: announcement ]. > > (subscriptions collection can be just a Set in this case) > and then , a particular subscriber could decide whether he interested > in given announcement or not, > based on own criteria (such as #canBeLogged etc). > > And surely, we can provide a subscriber class, which can use the same > logic, to determine if it interested in particular announcement, based > on announcement class. > This could make the whole thing more flexible. But the client side code will be more messy. An object will have only one implementation of #handle:, and whenever you want to add a new thing to be handled by the object, it ends up with adding a new if clauses inside it. (Something more flexible and loose-coupling than Announcement would be really good, I agree.) -- Yoshiki

Nov. 1, 2009

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

by Mariano Martinez Peck

http://downforeveryoneorjustme.com/http://www.pharo-project.org/ best, Mariano

Nov. 1, 2009

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

by Igor Stasenko

2009/11/2 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/11/1 Igor Stasenko <siguctua(a)gmail.com>: >> 2009/11/1 Lukas Renggli <renggli(a)gmail.com>: >>>> Another question , which Stephane noted already, is the overhead of >>>> broadcasting. >>> >>> First of all, announcements are magnitudes faster than the ancient >>> change-update and trigger frameworks. >>> >> >> i having zero interest in ancient stuff. This topic is about announcements. >> >>> The problem of broadcasting does not apply to announcements, because >>> the observer only registers and receives events he is interested in. >>> >> nope. this problem applies to announcements as well. As soon as you >> having multiple subscribers >> listening for same event, sending this event to all of them is called >> broadcasting. >> Please tell me if this definition is wrong. >> >> But in addition, announcer also iterates even over those subscribers >> who would never want to receive some announcements. >> I thought that Stephane talking about this overhead, not about some >> dusty, ancient code which i never seen. >> > > Igor, even if you open a shiny new Pharo image, I'm afraid you'll have > to contemplate plenty of ancient code. > Note sure the most ancient the most dusty though ;). > > FIY, st80 MVC was broadcasting to 99% of ignorers with a long chain of > this kind: > self changed: aSymbol SENT FROM THE MODEL > -> self changed:with: > --> self changed:with:from: > ---> update:with:from: BROADCAST IN EACH dependents (each subview was > potentially) > --> update:with: > -> update: > Oh yeah, i seen that code, and Dependents class var in Object class, which is a dictionary of dictionaries... This model, as well as morphic extensions, takes roots from Self's morphic, where you can easily extend any object state by adding new slots to it. In smalltalk we don't have dynamic named slots, and thus we having such ugly crutches :) > I hope we don't replicate this scheme, I had understood Announcements > did not thanks to explicit subscription. > Anyway, a bit of archeology is always helpfull when cleaning Smalltalk... > It is strange, i have a feeling that people think i am being short-sighted or don't understand things, while i'm trying to show the potentional bottlenecks of Announcements framework itself... > Nicolas > -- Best regards, Igor Stasenko AKA sig.

Nov. 1, 2009

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

by David T. Lewis

On Sun, Nov 01, 2009 at 10:07:59PM +0100, Lukas Renggli wrote: > > Another question , which Stephane noted already, is the overhead of > > broadcasting. > > First of all, announcements are magnitudes faster than the ancient > change-update and trigger frameworks. Is this true? I would expect announcements to be magnitudes faster than the trigger framework, and similar in performance to change-update. Dave

Nov. 1, 2009

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

by Nicolas Cellier

2009/11/1 Igor Stasenko <siguctua(a)gmail.com>: > 2009/11/1 Lukas Renggli <renggli(a)gmail.com>: >>> Another question , which Stephane noted already, is the overhead of >>> broadcasting. >> >> First of all, announcements are magnitudes faster than the ancient >> change-update and trigger frameworks. >> > > i having zero interest in ancient stuff. This topic is about announcements. > >> The problem of broadcasting does not apply to announcements, because >> the observer only registers and receives events he is interested in. >> > nope. this problem applies to announcements as well. As soon as you > having multiple subscribers > listening for same event, sending this event to all of them is called > broadcasting. > Please tell me if this definition is wrong. > > But in addition, announcer also iterates even over those subscribers > who would never want to receive some announcements. > I thought that Stephane talking about this overhead, not about some > dusty, ancient code which i never seen. > Igor, even if you open a shiny new Pharo image, I'm afraid you'll have to contemplate plenty of ancient code. Note sure the most ancient the most dusty though ;). FIY, st80 MVC was broadcasting to 99% of ignorers with a long chain of this kind: self changed: aSymbol SENT FROM THE MODEL -> self changed:with: --> self changed:with:from: ---> update:with:from: BROADCAST IN EACH dependents (each subview was potentially) --> update:with: -> update: I hope we don't replicate this scheme, I had understood Announcements did not thanks to explicit subscription. Anyway, a bit of archeology is always helpfull when cleaning Smalltalk... Nicolas >> Please read the blog posts of Vassily. >> > > Thanks, i'm already read his blog. > >> 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 1, 2009

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

by Igor Stasenko

2009/11/1 Lukas Renggli <renggli(a)gmail.com>: >> Another question , which Stephane noted already, is the overhead of >> broadcasting. > > First of all, announcements are magnitudes faster than the ancient > change-update and trigger frameworks. > i having zero interest in ancient stuff. This topic is about announcements. > The problem of broadcasting does not apply to announcements, because > the observer only registers and receives events he is interested in. > nope. this problem applies to announcements as well. As soon as you having multiple subscribers listening for same event, sending this event to all of them is called broadcasting. Please tell me if this definition is wrong. But in addition, announcer also iterates even over those subscribers who would never want to receive some announcements. I thought that Stephane talking about this overhead, not about some dusty, ancient code which i never seen. > Please read the blog posts of Vassily. > Thanks, i'm already read his blog. > 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. 1, 2009

Re: [Pharo-project] about Issue 860: Accelerate MulitByteFileStream

by Nicolas Cellier

2009/11/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Nicolas > > I was wondering why TextConverter>> initialize > was calling nextPut: to Stream: which is abstract. > which initialize ? initializeLatin1MapAndEncodings ? yes, it is intended for concrete subclass only and triggered by lazy initialization. > So I imagine that only subclasses are invoking this behavior. > > So I was trying to understand the speed up idea but I failed (because > I did not know the speed up of andreas). > > Stef > > MultiByteFileStream iterate Character by Character which is sloooow... The idea is that most ASCII characters won't need a conversion. Andreas trick is to do a fast scan of the String for detecting chunks not requiring translation (there are fast primitives to do that on a ByteString). This enables putting these chunks of String without translations directly on the stream... I generalized this to any format (not only UTF8) I generalized this to lineEndConventions (for converting CR/LF, MultiByteFileStream iterates char by char too) That's for writting only. Maybe someday we should also speed reading up. Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 1, 2009

[Pharo-project] lastKeystroke: ???

by StÃ©phane Ducasse

Hi guys apparently typing a character on the world -> DNU lastKeystroke: from PasteUpMorph is not there. Apparently the senders was integrated by me on 26 of October but I could not find its trace. So does anybody know from where this bug is coming? Stef

Nov. 1, 2009

[Pharo-project] [update 1.1] #11029

by StÃ©phane Ducasse

11029 ----- - Issue 1378: annoying MC Transcript log "Warning: pane summary not found" - Issue 1370: Issues with Integer>>isPrime good harvesting for today :)

Nov. 1, 2009