August 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ann] pillar support in gtinspector

by Alexandre Bergel

Hi! Having a spell checker would be fantasticâ¦ Any chance to have this? Alexandre > On Aug 29, 2016, at 4:41 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > I updated the Pillar support in GTInspector. Some of the extensions already exist in the default Pillar #development version. If you want to play with the full support, you can load it like this: > > Gofer new > smalltalkhubUser: 'Moose' project: 'PetitParser'; > package: 'PetitAnalyzer'; > package: 'PetitIndent'; > package: 'PetitIslands'; > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'GT-InspectorExtensions-Pillar'; > load > > Then you can just inspect a book folder and you get this: > > <inspector-pillar.png> > > I did not integrate this in the main Pillar yet because this is an older implementation based on a limited island parser. As now Pillar has a full parser based on PetitParser, the next step is to move the highlighting logic to use this parser instead of the island parser. From my measurements, the speed of the two parsers is about the same, so from a user perspective there will be not much changes. > > It pains me that we are editing Pillar in outside tools, and now we should no longer have to do that. Of course, this is not the most ideal tool support for Pillar but I think it is a reasonable start. > > Cheers, > Doru > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > > >

Aug. 30, 2016

Re: [Pharo-dev] wish for Iceberg

by Alexandre Bergel

> So in the meantime I can build a tool to convert a git metacello-downloaded MCRepository to an Iceberg repository in a simple way. Do you think it would be useful? No idea. It looks interesting! Anyway, keep pushing! This is so exciting to see this happening! Alexandre

Aug. 30, 2016

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

by Henrik Johansen

> On 29 Aug 2016, at 6:39 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > And now question is why SubscriptionRegistry manages subscriptions as IdentitySet instead of OrderedCollection? 1) Performance of remove operation is the main reason. Sure, registration has a larger constant overhead than using an OrderedCollection, but it's still a theta(1) operation.Removal however, is theta(1)'ish, while with OrderedCollection, it would be theta(n/2). So for a general implementation where the usage pattern is unknown, it gives more balanced performance considering all use cases. * 2) Lessen chance of user relying on delivery order implied by registration order. And yes, it's possible to create much better performing announcers for specific use patterns, such as a (short-lived) announcer where there's a period of registration, followed by a period of delivery, before eventual garbage collection of the announcer rather than explicit deregistration. Personally, I think the (original) announcer pattern, where subscription collection is copied at registration, then replaced atomically, would be a better alternative. You'd still need a mutex for the copy->add part to keep it thread-safe, but delivery would have much less overhead (no copy needed to avoid mutex guarding against mutation) I'd be *very* wary of adding announcers that do not have thread-safe interaction between registration and delivery, though one suited for registration limited to a single thread may be a valid scenario. Cheers, Henry

Aug. 30, 2016

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