- Pharo-dev - lists.pharo.org

Examples accessible within the World Menu?

by Alexandre Bergel

Hi! Is there a way to easily have some examples accessible within a world menu? That would be so much convenientâ¦ Does GTExample do something in that direction? Cheers, Alexandre

Aug. 30, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Thierry Goubier

2016-08-30 11:12 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-08-30 10:35 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> >> 2016-08-30 10:28 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> >>> 2016-08-30 10:21 GMT+02:00 Guille Polito <guillermopolito(a)gmail.com>: >>> >>>> Hi, >>>> >>>> From the top of my head: I would understand that systems where there >>>> are hundreds of thousands of events per second, maybe one does not want to >>>> pay the overhead of announcements... >>>> >>>> But, How many events are produced from a morph per second? One? Two? >>>> Five? Is it really the case of morphs the one that require optimization? >>>> >>> >>> I have similar feeling. But maybe Spec is nice example which could >>> improved by such optimizations >>> >> >> No. Announcers are not the problem in Spec >> > > I just saw that every property in Spec model's is kind of ValueHolder with > announcer instance inside. And it is huge number. But I think in case of > Spec they are always used. So laziness will not helps here. But > optimisation for single subscriber could. > You're right. But I would consider making the value holder itself lazy (leaving it nil unless the model manipulates that property) so that you don't have to subscribe to a property which is never changed (and on the fly subscribe to it if it is lazily created by the model manipulation... could be a tad complex that one). Thierry

Aug. 30, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Denis Kudriashov

2016-08-30 10:35 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > 2016-08-30 10:28 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> 2016-08-30 10:21 GMT+02:00 Guille Polito <guillermopolito(a)gmail.com>: >> >>> Hi, >>> >>> From the top of my head: I would understand that systems where there are >>> hundreds of thousands of events per second, maybe one does not want to pay >>> the overhead of announcements... >>> >>> But, How many events are produced from a morph per second? One? Two? >>> Five? Is it really the case of morphs the one that require optimization? >>> >> >> I have similar feeling. But maybe Spec is nice example which could >> improved by such optimizations >> > > No. Announcers are not the problem in Spec > I just saw that every property in Spec model's is kind of ValueHolder with announcer instance inside. And it is huge number. But I think in case of Spec they are always used. So laziness will not helps here. But optimisation for single subscriber could.

Aug. 30, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Thierry Goubier

2016-08-30 10:41 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > > Am 30.08.2016 um 09:44 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hi > > 2016-08-30 8:52 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > >> I think for the 0 case we should think about instantiating the >> SubscriptionRegistry lazily. This would also mitigate the effect that if a >> lot of announcers are created they create only a single object instead of >> two until used. Of course this depends on the probability of having a lot >> of announcers where only a few are used. >> The #announce: method looks like it has been lazy before. >> >> Announcer>>#announce: anAnnouncement >> >> | announcement | >> announcement := anAnnouncement asAnnouncement. >> registry ifNotNil: [ >> registry deliver: announcement >> ]. >> ^ announcement >> >> checks for #ifNotNil: but registry is created in #initialize. So >> #ifNotEmpty: would be right here but #deliver: checks that, too. >> > > We always hide announcer instance inside owner. So it could instantiate > announcer lazily if such optimization really needed. > > > That prevents creating an announcer until someone creates the announcer > lazily. That does not mean there is a subscription, especially if there are > announcements sent. Announcements are such a central component (we made it > that way) that every useful optimization should be considered! > Agreed. The slightly tricky part is effectively to ensure that sending an announcement doesn't lazily create the announcer. But, overall, the code isn't that complex, so it is worth optimising for it (IMHO). The software engineering issue is that the optimisation is done in the code using the announcer object (for example, Morph) and not in the Announcer instance itself, which would make the optimisation applied everywhere. However, the benefit is that you do it only in places where you think it is necessary, not everywhere for everybody. This optimisation will have a cost for some operations (*), and so it may not be suitable everywhere. Thierry (*) I'm thinking of subscriptions removal there. Useless to optimise that for Morphs, for example (it would be very rare to see an object subscribe to a Morph, then unsubscribe). However, for the system announcer, given the number of objects subscribing / unsubscribing to it, don't try to optimise the no subscribers case! > > Norbert > >

Aug. 30, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Guille Polito

One Morph <----> One Announcer sounds bad in terms of memory consumption, yes. Maybe it makes more sense something like One Widged <----> One Announcer But the problem is that today the line between Morphs and Widgets is not clearly set. I hope Bloc/Bric helps on this. -------- Original Message -------- > > > 2016-08-30 10:28 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>>: > > > 2016-08-30 10:21 GMT+02:00 Guille Polito > <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: > > Hi, > > From the top of my head: I would understand that systems where > there are hundreds of thousands of events per second, maybe > one does not want to pay the overhead of announcements... > > But, How many events are produced from a morph per second? > One? Two? Five? Is it really the case of morphs the one that > require optimization? > > > I have similar feeling. But maybe Spec is nice example which could > improved by such optimizations > > > No. Announcers are not the problem in Spec > > Thierry >

Aug. 30, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Norbert Hartl

> Am 30.08.2016 um 09:44 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hi > > 2016-08-30 8:52 GMT+02:00 Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>>: > I think for the 0 case we should think about instantiating the SubscriptionRegistry lazily. This would also mitigate the effect that if a lot of announcers are created they create only a single object instead of two until used. Of course this depends on the probability of having a lot of announcers where only a few are used. > The #announce: method looks like it has been lazy before. > > Announcer>>#announce: anAnnouncement > > | announcement | > announcement := anAnnouncement asAnnouncement. > registry ifNotNil: [ > registry deliver: announcement > ]. > ^ announcement > > checks for #ifNotNil: but registry is created in #initialize. So #ifNotEmpty: would be right here but #deliver: checks that, too. > > We always hide announcer instance inside owner. So it could instantiate announcer lazily if such optimization really needed. That prevents creating an announcer until someone creates the announcer lazily. That does not mean there is a subscription, especially if there are announcements sent. Announcements are such a central component (we made it that way) that every useful optimization should be considered! Norbert

Aug. 30, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Thierry Goubier

2016-08-30 10:28 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-08-30 10:21 GMT+02:00 Guille Polito <guillermopolito(a)gmail.com>: > >> Hi, >> >> From the top of my head: I would understand that systems where there are >> hundreds of thousands of events per second, maybe one does not want to pay >> the overhead of announcements... >> >> But, How many events are produced from a morph per second? One? Two? >> Five? Is it really the case of morphs the one that require optimization? >> > > I have similar feeling. But maybe Spec is nice example which could > improved by such optimizations > No. Announcers are not the problem in Spec Thierry

Aug. 30, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Denis Kudriashov

2016-08-30 10:21 GMT+02:00 Guille Polito <guillermopolito(a)gmail.com>: > Hi, > > From the top of my head: I would understand that systems where there are > hundreds of thousands of events per second, maybe one does not want to pay > the overhead of announcements... > > But, How many events are produced from a morph per second? One? Two? Five? > Is it really the case of morphs the one that require optimization? > I have similar feeling. But maybe Spec is nice example which could improved by such optimizations

Aug. 30, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Guille Polito

Hi, From the top of my head: I would understand that systems where there are hundreds of thousands of events per second, maybe one does not want to pay the overhead of announcements... But, How many events are produced from a morph per second? One? Two? Five? Is it really the case of morphs the one that require optimization? -------- Original Message -------- > > > 2016-08-30 9:44 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>>: > > Hi > > 2016-08-30 8:52 GMT+02:00 Norbert Hartl <norbert(a)hartl.name > <mailto:norbert@hartl.name>>: > > I think for the 0 case we should think about instantiating the > SubscriptionRegistry lazily. This would also mitigate the > effect that if a lot of announcers are created they create > only a single object instead of two until used. Of course this > depends on the probability of having a lot of announcers where > only a few are used. > The #announce: method looks like it has been lazy before. > > Announcer>>#announce: anAnnouncement > > | announcement | > announcement := anAnnouncement asAnnouncement. > registry ifNotNil: [ > registry deliver: announcement > ]. > ^ announcement > > checks for #ifNotNil: but registry is created in #initialize. > So #ifNotEmpty: would be right here but #deliver: checks that, > too. > > > We always hide announcer instance inside owner. So it could > instantiate announcer lazily if such optimization really needed. > > > I remember making sure this was the case for Morph instances. If no > subscriber, no announcer and make sure announcing something doesn't > create the announcer lazily. > > Thierry

Aug. 30, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Thierry Goubier

2016-08-30 9:44 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi > > 2016-08-30 8:52 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > >> I think for the 0 case we should think about instantiating the >> SubscriptionRegistry lazily. This would also mitigate the effect that if a >> lot of announcers are created they create only a single object instead of >> two until used. Of course this depends on the probability of having a lot >> of announcers where only a few are used. >> The #announce: method looks like it has been lazy before. >> >> Announcer>>#announce: anAnnouncement >> >> | announcement | >> announcement := anAnnouncement asAnnouncement. >> registry ifNotNil: [ >> registry deliver: announcement >> ]. >> ^ announcement >> >> checks for #ifNotNil: but registry is created in #initialize. So >> #ifNotEmpty: would be right here but #deliver: checks that, too. >> > > We always hide announcer instance inside owner. So it could instantiate > announcer lazily if such optimization really needed. > I remember making sure this was the case for Morph instances. If no subscriber, no announcer and make sure announcing something doesn't create the announcer lazily. Thierry

Aug. 30, 2016