- Pharo-dev - lists.pharo.org

[Pharo-project] roadmap

by Tudor Girba

Hi, Lukas and Stefan (Marr) both raised the topic of the roadmap. From Lukas: > This leads me to the question: Did anybody ever sketch an architecture > of where Pharo should be heading to? I created a simplified one based > on my own understanding of the current proposals: http://bit.ly/vpnAf1 > (Google Docs). I think too that they have a point. Stef answered: > We should because we know where we want to go. I think that at the very least it is a communication issue. From outside it is unclear in what order should the efforts be spent. We have a ton of wishes, but not an understanding of where we want to get and how. Please, let's discuss this roadmap. Not listing wishes, but actionable points. I start with some questions: - beside RB and Announcements, are there other things that could be problematic - how do we approach the RB problem? Is it Ok to get it out of the image and have Jenkins build the Pharo distribution by loading the head? Cheers, Doru -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

Jan. 2, 2012

Re: [Pharo-project] About announcements

by StÃ©phane Ducasse

> Thanks Lukas for the detailed points. These are great because they are to the point and they lead to hands-on solutions. > > And, thanks Igor for picking it up. If Henrik would join the discussion we would have all parties involved and action can just start. > > And it was so easy. indeed constructivist feedback (even negative). We were working on event and it also seems that Monitor in announcement was causing some problems. Now I would really like to know if the Monitor implementation is good. Stef > > Cheers, > Doru > > > > On 2 Jan 2012, at 14:45, Igor Stasenko wrote: > >> On 2 January 2012 10:42, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>>> To you, the current Pharo image is the Pharo Core and you are unhappy that it is too big (for example because RB is there). >>>>> >>>>> The size is the least problem. >>>>> >>>>> More annoying is that the code quickly gets out of sync and >>>>> non-changes are added to the history. Both of these problems are >>>>> already visible today. >>>>> >>>>> Additionally, over time people will change/add/remove features that >>>>> get integrated without proper review. I just had a look at the >>>>> announcement framework in Pharo 1.4 today, it is unbelievable how a >>>>> tiny framework could degrade to a bloated, untested and dead slow pile >>>>> of mud in just a few years :-( >>>> >>>> I think your are unfair here. The new features might be untested (current coverage is at 56%), but the changes were meant to provide working weak announcements. And they do work. >>> >>> Nice argument for your students reading this thread: >>> http://memegenerator.net/instance/12779750. >>> >>>> But, what do you mean by slow? How did you benchmark it? >>> >>> No, but if you look at the code you will see many extra steps: >>> >>> 1. It tests if a registry is there: Why would that be necessary in an >>> object-oriented implementation? >>> >> this should be cleaned up. >> i think it is a leftover from migration code from old Announcer class (pre 1.3) >> to a new one. >> We did things incrementally, and had code to migrate all instances >> from old format to a new one, >> without losing subscription and without stopping working. >> >>> 2. It tests if the registry is empty: Why would that be necessary in >>> an object-oriented implementation? >>> >> not necessary. looks like a optimization. >> >>> 3. It enters a critical section of a monitor: This is rarely useful >>> and the slowest kind of concurrency control available in Pharo (a >>> Mutex would be enough for what it is used for, and instantiate >>> multiple semaphores and queues), and btw the lazy initialization of >>> the monitor is the prime example of a race condition. >>> >> agreed here. I would even leave a semaphore. >> I think it is overlooked by Henrik. >> It also don't needs a lazy initialization in #protected: , since in >> #initialize it can just create a ready for use fresh >> synchronization object. >> >>> 4. It creates a copy of the collection of all the subscriptions: This >>> is rarely useful and wouldn't be necessary if an immutable data >>> structure was used. >>> >> propose better solution how to deal with situation when during >> handling an announcement, >> your handler unsubscribing from announcer. >> >>> 5. It iterates over all announcements, it doesn't even try to group >>> announcements of the same kind. >>> >> it is pointless to group them, and makes no real difference. >> Because announcer doesn't knows what kinds of announcements will be >> announcement, >> and it knows only about subscriptions. >> Suppose i have a subscription to Announcement. And i announcing >> AnnouncementA (a subclass of it). >> >> Now it is still have to iterate over inheritance chain in order to >> determine if given subscription should receive it or not. >> Of course you can put all subscriptions to Announcement into one >> group, so you don't need to check it for every subscription: >> >> dict at: Announcement put: group. >> .... >> so you can do: >> >> group do: [:subscription | subscripton deliver: announcement ]. >> >> but that imposing that you have a fixed model for announcement relationship, >> while with #handles: i can simply make it so, that my announcement >> class are not inherits from its superclass >> and so, even if you subscribe to Announcement, you won't receive an >> announcements of my kind, because >> it simply doesn't walks an inheritance chain in its #handles: method. >> >> also, in the end i don't think it matters. Grouping is more optimal >> (potentially), but you won't see any difference unless you >> have hundreds of subscriptions, so i think it is not a big deal. >> Usually there are few subscriptions held by announcer. And so there is >> simply no need to bother and grouping them. >> I cannot imagine an announcer holding hundreds or thousands of subscriptions. >> >> Announcer allSubInstances collect: [:e | e numberOfSubscriptions ] >> an OrderedCollection(0 0 1 0) >> >>> 6. It wraps each announcement delivery into a curtailed block. It does >>> that even for those that are never actually announced. >>> >> yeah, this can be optimized >> >>> 7. It then tests each announcement if it matches, again it doesn't >>> even try to group the announcements of the same kind. Aside, the match >>> test was changed so that it doesn't allow instance-based announcements >>> anymore, breaking some of my code. >>> >> what is instance-based announcements? >> >> you can use any object as a subscription selector, just make sure it >> understands #handles: message. >> i.e. >> >> announcer on: myObject do: [ ... ] >> where myObject can be any object, not just Announcement (sub)class. >> >> >>> 8. It then wraps the actual notification into an exception handler. >>> Again, this is rarely useful and should probably rather be something >>> pluggable. >>> >> perhaps we can add even more 'bloat' to have 'safe' and 'unsafe' announcers :) >> But for things like SystemAnnouncer, this is not a question that >> exception handler must be present >> and delivery must be guaranteed. >> >>> 9. It then culls the announcement and announcer into the block. Not >>> sure why the announcer is useful, after all the block was registered >>> with the announcer at some point. >>> >> cull there is for passing optional arguments. >> >>> So all these 9 steps are not really necessary (or even wanted) in most >>> case. I doubt that any of them makes the code faster. I am glad that >>> the code works for you even if all of this new functionality is >>> untested. And good luck with the race condition :-) >>> >>>> There is a point in here. But, as I said, I thought that the point is to produce the core by having jenkins strip away unwanted material. Of course, the other way would be to start from the core as a seed and have jenkins produce the current image. >>> >>> Do you really believe that stripping away unwanted material works? No >>> other open source project in the whole world does it like that, >>> everybody builds distributions on top of a smaller core: Linux, GCC, >>> Gnome, FireFox, ... Even in the supermarket, you typically don't get a >>> vegetable hamper if you just want a some potatoes. >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- > www.tudorgirba.com > > "Some battles are better lost than fought." > > > >

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by StÃ©phane Ducasse

> >>> As discussed previously, I >>> don't think that the refactoring engine provides the right model for >>> this task; but should it turn out otherwise, why not adapt it at that >>> time? Also I don't see why Pharo would want to have remote editing >>> functionality in all images. Shouldn't that better be a completely >>> separate project? >> >> Lukas we want only one compiler but we should be able to edit its code. >> RIght now marcus has the old compiler as a fallback and this is annoying. >> We should be able to run two compilers side by side (this is why Opal should be parametrized by environment (smalltalk) but also >> object environment (nil trueâ¦.) so that we can bootstrap it with itself. > > I don't understand what you write, but I guess it boils down to having > namespaces that allows one to load and use different variations of the > same code at once. Not only but nearly. we should even be able to say from which class literal true is and potentially have two different ones. > This would also solve my problem with the > refactoring engine: Pharo could depend on one version, I could use > another one. Yes this is what we want for pharo and this is why we are cleaning everything too . but for that it means that all the tools chain should be parametrized by environment. Compiler, senders, implementors, test and refactoring is one of them. Remote is just one case. And since Nick needs it, this is a way to get momentum. > Seems to me quite a central kind of functionality to make progress. We are working on it regularly. SystemNavigation was fixed, then we get some problems with TestRunner. Because we should be able to run tests defined in another one. So this poses the question of late bound classes. So before getting there we should be able to experiment. And for that we need to have a parametrized environment. > Again to make the analogy with Linux: This seems to be the virtual > machines that allow one to easy test and run other kernels aside. Yes this is the vision. We think about that since a couple of year with marcus. The bootstrap is also part of the story. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Jan. 2, 2012

[Pharo-project] Experience with Monitor

by StÃ©phane Ducasse

I remember reading somewhere that Monitor was broken in Pharo/Squeak? I do not remember where. Does anybody have experience with bad monitor behavior? Because we got some bad experience with Monitor. THe funny part is that now doing self inform: freezes to death our image. Stef

Jan. 2, 2012

Re: [Pharo-project] About announcements

by Tudor Girba

Thanks Lukas for the detailed points. These are great because they are to the point and they lead to hands-on solutions. And, thanks Igor for picking it up. If Henrik would join the discussion we would have all parties involved and action can just start. And it was so easy. Cheers, Doru On 2 Jan 2012, at 14:45, Igor Stasenko wrote: > On 2 January 2012 10:42, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>> To you, the current Pharo image is the Pharo Core and you are unhappy that it is too big (for example because RB is there). >>>> >>>> The size is the least problem. >>>> >>>> More annoying is that the code quickly gets out of sync and >>>> non-changes are added to the history. Both of these problems are >>>> already visible today. >>>> >>>> Additionally, over time people will change/add/remove features that >>>> get integrated without proper review. I just had a look at the >>>> announcement framework in Pharo 1.4 today, it is unbelievable how a >>>> tiny framework could degrade to a bloated, untested and dead slow pile >>>> of mud in just a few years :-( >>> >>> I think your are unfair here. The new features might be untested (current coverage is at 56%), but the changes were meant to provide working weak announcements. And they do work. >> >> Nice argument for your students reading this thread: >> http://memegenerator.net/instance/12779750. >> >>> But, what do you mean by slow? How did you benchmark it? >> >> No, but if you look at the code you will see many extra steps: >> >> 1. It tests if a registry is there: Why would that be necessary in an >> object-oriented implementation? >> > this should be cleaned up. > i think it is a leftover from migration code from old Announcer class (pre 1.3) > to a new one. > We did things incrementally, and had code to migrate all instances > from old format to a new one, > without losing subscription and without stopping working. > >> 2. It tests if the registry is empty: Why would that be necessary in >> an object-oriented implementation? >> > not necessary. looks like a optimization. > >> 3. It enters a critical section of a monitor: This is rarely useful >> and the slowest kind of concurrency control available in Pharo (a >> Mutex would be enough for what it is used for, and instantiate >> multiple semaphores and queues), and btw the lazy initialization of >> the monitor is the prime example of a race condition. >> > agreed here. I would even leave a semaphore. > I think it is overlooked by Henrik. > It also don't needs a lazy initialization in #protected: , since in > #initialize it can just create a ready for use fresh > synchronization object. > >> 4. It creates a copy of the collection of all the subscriptions: This >> is rarely useful and wouldn't be necessary if an immutable data >> structure was used. >> > propose better solution how to deal with situation when during > handling an announcement, > your handler unsubscribing from announcer. > >> 5. It iterates over all announcements, it doesn't even try to group >> announcements of the same kind. >> > it is pointless to group them, and makes no real difference. > Because announcer doesn't knows what kinds of announcements will be > announcement, > and it knows only about subscriptions. > Suppose i have a subscription to Announcement. And i announcing > AnnouncementA (a subclass of it). > > Now it is still have to iterate over inheritance chain in order to > determine if given subscription should receive it or not. > Of course you can put all subscriptions to Announcement into one > group, so you don't need to check it for every subscription: > > dict at: Announcement put: group. > .... > so you can do: > > group do: [:subscription | subscripton deliver: announcement ]. > > but that imposing that you have a fixed model for announcement relationship, > while with #handles: i can simply make it so, that my announcement > class are not inherits from its superclass > and so, even if you subscribe to Announcement, you won't receive an > announcements of my kind, because > it simply doesn't walks an inheritance chain in its #handles: method. > > also, in the end i don't think it matters. Grouping is more optimal > (potentially), but you won't see any difference unless you > have hundreds of subscriptions, so i think it is not a big deal. > Usually there are few subscriptions held by announcer. And so there is > simply no need to bother and grouping them. > I cannot imagine an announcer holding hundreds or thousands of subscriptions. > > Announcer allSubInstances collect: [:e | e numberOfSubscriptions ] > an OrderedCollection(0 0 1 0) > >> 6. It wraps each announcement delivery into a curtailed block. It does >> that even for those that are never actually announced. >> > yeah, this can be optimized > >> 7. It then tests each announcement if it matches, again it doesn't >> even try to group the announcements of the same kind. Aside, the match >> test was changed so that it doesn't allow instance-based announcements >> anymore, breaking some of my code. >> > what is instance-based announcements? > > you can use any object as a subscription selector, just make sure it > understands #handles: message. > i.e. > > announcer on: myObject do: [ ... ] > where myObject can be any object, not just Announcement (sub)class. > > >> 8. It then wraps the actual notification into an exception handler. >> Again, this is rarely useful and should probably rather be something >> pluggable. >> > perhaps we can add even more 'bloat' to have 'safe' and 'unsafe' announcers :) > But for things like SystemAnnouncer, this is not a question that > exception handler must be present > and delivery must be guaranteed. > >> 9. It then culls the announcement and announcer into the block. Not >> sure why the announcer is useful, after all the block was registered >> with the announcer at some point. >> > cull there is for passing optional arguments. > >> So all these 9 steps are not really necessary (or even wanted) in most >> case. I doubt that any of them makes the code faster. I am glad that >> the code works for you even if all of this new functionality is >> untested. And good luck with the race condition :-) >> >>> There is a point in here. But, as I said, I thought that the point is to produce the core by having jenkins strip away unwanted material. Of course, the other way would be to start from the core as a seed and have jenkins produce the current image. >> >> Do you really believe that stripping away unwanted material works? No >> other open source project in the whole world does it like that, >> everybody builds distributions on top of a smaller core: Linux, GCC, >> Gnome, FireFox, ... Even in the supermarket, you typically don't get a >> vegetable hamper if you just want a some potatoes. >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > Best regards, > Igor Stasenko. > -- www.tudorgirba.com "Some battles are better lost than fought."

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by Esteban Lorenzano

Hi, Stepping into this conversation :) ...and just to point one thing: IMHO, Pharo can never be just what Lukas propose: just a kernel, like linux, allowing different distributions. I think Pharo needs to be Kernel+Development Tools. Now, real objective is to make dev tools modules that you can load/unload, so you can have Kernel+Morphic Tools, Kernel+Glamoroust, Kernel+OB, etc. So, questions arise: 1) How do we achieve the objective of being real modular? 2) Which "dev tools" will be "blessed" (and maintained in the long way) by Pharo? I think right now we are trying to solve (1), so it has sense to want the simplest dev tools possible (That's how I interpret Stef requirements of not-on-top-of-yet-another-package)... But that will work for some time, once we have a modular kernel, Pharo needs powerful tools. It will be Glamouroust? I really don't know... I like it, but what I would like is to discuss what Glamour needs to be the tool we need, because other way, we will end with yet-another-tool-builder, and yet-another-discussion about which one adopt. What needs to be done in glamour to reach our goals? well... that's another discussion (and I'm agree, right now It can't be integrated as Pharo main distribution, but it could once Glamoroust is ready)... but this is my list: 1) drag&drop support 2) better menu handling/building (is too unflexible, now) well... I can keep talking about glamoroust tools, but non-sense right now :) best, Esteban El 02/01/2012, a las 10:37a.m., StÃ©phane Ducasse escribiÃ³: > > On Jan 2, 2012, at 2:18 PM, Lukas Renggli wrote: > >>>> and fork from Pharo 1.3? I guess this is only >>>> way, because with the inclusion of RB into Pharo 1.4 people that want >>>> to use the original version and everything that depends on it (maybe >>>> this is just me?) are locked out. >>> >>> Not totally true :). I could merge the code each time you publish a new version but this is tedious. >>> So how do we collaborate? :). >>> First I will update the RB version. >> >> I looked at the ConfigurationOfRefactoringEngine today, and I could >> not figure out how to update it: > > I will look at it once we beat the event crashing bug because I hate it. > BTW something I would like is > > - we have a core > - when working on coreA, we load all the system in another core > - from this other core we hack with rb and other tools the coreA > - we publish changes to coreA > - without having to touch core and we produce coreA without interference > > Because I loaded RB in Core because we crawl in mud all the time and I do everything by hand. > Now the problem is that also we cannot scope the changes. > > >> - There is now a package Refactoring-Pharo-Platform that should be >> loaded together with Refactoring-Core. >> >> - There seems to be some code moved between the packages in Pharo 1.4, >> so I don't see how the head can be merged with that code. > > Strange it should not. >> >> - There are parts for GemStone and Squeak in the configuration, that I >> don't know how to deal with. > > Me too :) > > >>> You see it works with zinc and zinc is even more central because sometimes I cannot update the system anymore :). >> >> Zinc is something else. Zinc is a clean replacement for HTTPSocket. It >> is backward compatible by providing the old and ugly HTTPSocket >> interface. >> >> The refactoring engine is something entirely new that you think you >> might want to use in the future for remote images. Now that sounds to >> me more like a research project that should be done aside, without >> inflicting on the current development. > > Now see above this is not research. I cannot publish anything on that. > >> As discussed previously, I >> don't think that the refactoring engine provides the right model for >> this task; but should it turn out otherwise, why not adapt it at that >> time? Also I don't see why Pharo would want to have remote editing >> functionality in all images. Shouldn't that better be a completely >> separate project? > > Lukas we want only one compiler but we should be able to edit its code. > RIght now marcus has the old compiler as a fallback and this is annoying. > We should be able to run two compilers side by side (this is why Opal should be parametrized by environment (smalltalk) but also > object environment (nil trueâ¦.) so that we can bootstrap it with itself. > > >> This leads me to the question: Did anybody ever sketch an architecture >> of where Pharo should be heading to? I created a simplified one based >> on my own understanding of the current proposals: http://bit.ly/vpnAf1 >> (Google Docs). > > We should because we know where we want to go. > >> I think Pharo should concentrate only one the blue squares, eventually >> only on the dark-blue one. Everything else should be a distribution on >> top. Kernel developers might want/need to use a distribution on top of >> the kernel themselves. Although it has been argued in the past that >> this doesn't work, I don't see a reason why not. In any other open >> source project (i.e. a Linux kernel hacker might as well use Emacs or >> Gnome, even if they are not part of the kernel) people work like this, >> why not in Pharo too? > > Probably. > >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > >

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by Lukas Renggli

>> The refactoring engine is something entirely new that you think you >> might want to use in the future for remote images. Now that sounds to >> me more like a research project that should be done aside, without >> inflicting on the current development. > > Now see above this is not research. I cannot publish anything on that. Ok, then be it a separate open-source project that Pharo does not need to depend on. >> As discussed previously, I >> don't think that the refactoring engine provides the right model for >> this task; but should it turn out otherwise, why not adapt it at that >> time? Also I don't see why Pharo would want to have remote editing >> functionality in all images. Shouldn't that better be a completely >> separate project? > > Lukas we want only one compiler but we should be able to edit its code. > RIght now marcus has the old compiler as a fallback and this is annoying. > We should be able to run two compilers side by side (this is why Opal should be parametrized by environment (smalltalk) but also > object environment (nil trueâ¦.) so that we can bootstrap it with itself. I don't understand what you write, but I guess it boils down to having namespaces that allows one to load and use different variations of the same code at once. This would also solve my problem with the refactoring engine: Pharo could depend on one version, I could use another one. Seems to me quite a central kind of functionality to make progress. Again to make the analogy with Linux: This seems to be the virtual machines that allow one to easy test and run other kernels aside. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 2, 2012

Re: [Pharo-project] About announcements

by StÃ©phane Ducasse

Ok I suggest that we wait for henrik feedback and turn these points in bug entry issue. On Jan 2, 2012, at 2:45 PM, Igor Stasenko wrote: > On 2 January 2012 10:42, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>> To you, the current Pharo image is the Pharo Core and you are unhappy that it is too big (for example because RB is there). >>>> >>>> The size is the least problem. >>>> >>>> More annoying is that the code quickly gets out of sync and >>>> non-changes are added to the history. Both of these problems are >>>> already visible today. >>>> >>>> Additionally, over time people will change/add/remove features that >>>> get integrated without proper review. I just had a look at the >>>> announcement framework in Pharo 1.4 today, it is unbelievable how a >>>> tiny framework could degrade to a bloated, untested and dead slow pile >>>> of mud in just a few years :-( >>> >>> I think your are unfair here. The new features might be untested (current coverage is at 56%), but the changes were meant to provide working weak announcements. And they do work. >> >> Nice argument for your students reading this thread: >> http://memegenerator.net/instance/12779750. >> >>> But, what do you mean by slow? How did you benchmark it? >> >> No, but if you look at the code you will see many extra steps: >> >> 1. It tests if a registry is there: Why would that be necessary in an >> object-oriented implementation? >> > this should be cleaned up. > i think it is a leftover from migration code from old Announcer class (pre 1.3) > to a new one. > We did things incrementally, and had code to migrate all instances > from old format to a new one, > without losing subscription and without stopping working. > >> 2. It tests if the registry is empty: Why would that be necessary in >> an object-oriented implementation? >> > not necessary. looks like a optimization. > >> 3. It enters a critical section of a monitor: This is rarely useful >> and the slowest kind of concurrency control available in Pharo (a >> Mutex would be enough for what it is used for, and instantiate >> multiple semaphores and queues), and btw the lazy initialization of >> the monitor is the prime example of a race condition. >> > agreed here. I would even leave a semaphore. > I think it is overlooked by Henrik. > It also don't needs a lazy initialization in #protected: , since in > #initialize it can just create a ready for use fresh > synchronization object. > >> 4. It creates a copy of the collection of all the subscriptions: This >> is rarely useful and wouldn't be necessary if an immutable data >> structure was used. >> > propose better solution how to deal with situation when during > handling an announcement, > your handler unsubscribing from announcer. > >> 5. It iterates over all announcements, it doesn't even try to group >> announcements of the same kind. >> > it is pointless to group them, and makes no real difference. > Because announcer doesn't knows what kinds of announcements will be > announcement, > and it knows only about subscriptions. > Suppose i have a subscription to Announcement. And i announcing > AnnouncementA (a subclass of it). > > Now it is still have to iterate over inheritance chain in order to > determine if given subscription should receive it or not. > Of course you can put all subscriptions to Announcement into one > group, so you don't need to check it for every subscription: > > dict at: Announcement put: group. > .... > so you can do: > > group do: [:subscription | subscripton deliver: announcement ]. > > but that imposing that you have a fixed model for announcement relationship, > while with #handles: i can simply make it so, that my announcement > class are not inherits from its superclass > and so, even if you subscribe to Announcement, you won't receive an > announcements of my kind, because > it simply doesn't walks an inheritance chain in its #handles: method. > > also, in the end i don't think it matters. Grouping is more optimal > (potentially), but you won't see any difference unless you > have hundreds of subscriptions, so i think it is not a big deal. > Usually there are few subscriptions held by announcer. And so there is > simply no need to bother and grouping them. > I cannot imagine an announcer holding hundreds or thousands of subscriptions. > > Announcer allSubInstances collect: [:e | e numberOfSubscriptions ] > an OrderedCollection(0 0 1 0) > >> 6. It wraps each announcement delivery into a curtailed block. It does >> that even for those that are never actually announced. >> > yeah, this can be optimized > >> 7. It then tests each announcement if it matches, again it doesn't >> even try to group the announcements of the same kind. Aside, the match >> test was changed so that it doesn't allow instance-based announcements >> anymore, breaking some of my code. >> > what is instance-based announcements? > > you can use any object as a subscription selector, just make sure it > understands #handles: message. > i.e. > > announcer on: myObject do: [ ... ] > where myObject can be any object, not just Announcement (sub)class. > > >> 8. It then wraps the actual notification into an exception handler. >> Again, this is rarely useful and should probably rather be something >> pluggable. >> > perhaps we can add even more 'bloat' to have 'safe' and 'unsafe' announcers :) > But for things like SystemAnnouncer, this is not a question that > exception handler must be present > and delivery must be guaranteed. > >> 9. It then culls the announcement and announcer into the block. Not >> sure why the announcer is useful, after all the block was registered >> with the announcer at some point. >> > cull there is for passing optional arguments. > >> So all these 9 steps are not really necessary (or even wanted) in most >> case. I doubt that any of them makes the code faster. I am glad that >> the code works for you even if all of this new functionality is >> untested. And good luck with the race condition :-) >> >>> There is a point in here. But, as I said, I thought that the point is to produce the core by having jenkins strip away unwanted material. Of course, the other way would be to start from the core as a seed and have jenkins produce the current image. >> >> Do you really believe that stripping away unwanted material works? No >> other open source project in the whole world does it like that, >> everybody builds distributions on top of a smaller core: Linux, GCC, >> Gnome, FireFox, ... Even in the supermarket, you typically don't get a >> vegetable hamper if you just want a some potatoes. >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > Best regards, > Igor Stasenko. >

Jan. 2, 2012

[Pharo-project] About announcements

by Igor Stasenko

On 2 January 2012 10:42, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> To you, the current Pharo image is the Pharo Core and you are unhappy that it is too big (for example because RB is there). >>> >>> The size is the least problem. >>> >>> More annoying is that the code quickly gets out of sync and >>> non-changes are added to the history. Both of these problems are >>> already visible today. >>> >>> Additionally, over time people will change/add/remove features that >>> get integrated without proper review. I just had a look at the >>> announcement framework in Pharo 1.4 today, it is unbelievable how a >>> tiny framework could degrade to a bloated, untested and dead slow pile >>> of mud in just a few years :-( >> >> I think your are unfair here. The new features might be untested (current coverage is at 56%), but the changes were meant to provide working weak announcements. And they do work. > > Nice argument for your students reading this thread: > http://memegenerator.net/instance/12779750. > >> But, what do you mean by slow? How did you benchmark it? > > No, but if you look at the code you will see many extra steps: > > 1. It tests if a registry is there: Why would that be necessary in an > object-oriented implementation? > this should be cleaned up. i think it is a leftover from migration code from old Announcer class (pre 1.3) to a new one. We did things incrementally, and had code to migrate all instances from old format to a new one, without losing subscription and without stopping working. > 2. It tests if the registry is empty: Why would that be necessary in > an object-oriented implementation? > not necessary. looks like a optimization. > 3. It enters a critical section of a monitor: This is rarely useful > and the slowest kind of concurrency control available in Pharo (a > Mutex would be enough for what it is used for, and instantiate > multiple semaphores and queues), and btw the lazy initialization of > the monitor is the prime example of a race condition. > agreed here. I would even leave a semaphore. I think it is overlooked by Henrik. It also don't needs a lazy initialization in #protected: , since in #initialize it can just create a ready for use fresh synchronization object. > 4. It creates a copy of the collection of all the subscriptions: This > is rarely useful and wouldn't be necessary if an immutable data > structure was used. > propose better solution how to deal with situation when during handling an announcement, your handler unsubscribing from announcer. > 5. It iterates over all announcements, it doesn't even try to group > announcements of the same kind. > it is pointless to group them, and makes no real difference. Because announcer doesn't knows what kinds of announcements will be announcement, and it knows only about subscriptions. Suppose i have a subscription to Announcement. And i announcing AnnouncementA (a subclass of it). Now it is still have to iterate over inheritance chain in order to determine if given subscription should receive it or not. Of course you can put all subscriptions to Announcement into one group, so you don't need to check it for every subscription: dict at: Announcement put: group. .... so you can do: group do: [:subscription | subscripton deliver: announcement ]. but that imposing that you have a fixed model for announcement relationship, while with #handles: i can simply make it so, that my announcement class are not inherits from its superclass and so, even if you subscribe to Announcement, you won't receive an announcements of my kind, because it simply doesn't walks an inheritance chain in its #handles: method. also, in the end i don't think it matters. Grouping is more optimal (potentially), but you won't see any difference unless you have hundreds of subscriptions, so i think it is not a big deal. Usually there are few subscriptions held by announcer. And so there is simply no need to bother and grouping them. I cannot imagine an announcer holding hundreds or thousands of subscriptions. Announcer allSubInstances collect: [:e | e numberOfSubscriptions ] an OrderedCollection(0 0 1 0) > 6. It wraps each announcement delivery into a curtailed block. It does > that even for those that are never actually announced. > yeah, this can be optimized > 7. It then tests each announcement if it matches, again it doesn't > even try to group the announcements of the same kind. Aside, the match > test was changed so that it doesn't allow instance-based announcements > anymore, breaking some of my code. > what is instance-based announcements? you can use any object as a subscription selector, just make sure it understands #handles: message. i.e. announcer on: myObject do: [ ... ] where myObject can be any object, not just Announcement (sub)class. > 8. It then wraps the actual notification into an exception handler. > Again, this is rarely useful and should probably rather be something > pluggable. > perhaps we can add even more 'bloat' to have 'safe' and 'unsafe' announcers :) But for things like SystemAnnouncer, this is not a question that exception handler must be present and delivery must be guaranteed. > 9. It then culls the announcement and announcer into the block. Not > sure why the announcer is useful, after all the block was registered > with the announcer at some point. > cull there is for passing optional arguments. > So all these 9 steps are not really necessary (or even wanted) in most > case. I doubt that any of them makes the code faster. I am glad that > the code works for you even if all of this new functionality is > untested. And good luck with the race condition :-) > >> There is a point in here. But, as I said, I thought that the point is to produce the core by having jenkins strip away unwanted material. Of course, the other way would be to start from the core as a seed and have jenkins produce the current image. > > Do you really believe that stripping away unwanted material works? No > other open source project in the whole world does it like that, > everybody builds distributions on top of a smaller core: Linux, GCC, > Gnome, FireFox, ... Even in the supermarket, you typically don't get a > vegetable hamper if you just want a some potatoes. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Best regards, Igor Stasenko.

Jan. 2, 2012

Re: [Pharo-project] Image input sensors blocked

by StÃ©phane Ducasse

Nicolas will come to work at lille with us on JS and we really want to see if we can get a symbiotic kernel with amber :) But this is right now in the limbo. Stef

Jan. 2, 2012