>>> >> >> 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.
Why other should be stupid axiomatically? >> 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? > > 2. It tests if the registry is empty: Why would that be necessary in > an object-oriented implementation? > > 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. > > 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. > > 5. It iterates over all announcements, it doesn't even try to group > announcements of the same kind. > > 6. It wraps each announcement delivery into a curtailed block. It does > that even for those that are never actually announced. > > 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. > > 8. It then wraps the actual notification into an exception handler. > Again, this is rarely useful and should probably rather be something > pluggable. > > 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. > > 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 :-) Why did you discuss that with igor and henrik? I mean ***discuss*** not taking the working hypotheses that they are idiot writing dull code… >> 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. > We do not want to strip an image in the long but if to make sure that we can make progress we have to add stuff to the image we will. I added RB because we were thinking that I could have time to work on RPackage that we could load Nautilus but I got trapped by new duties. Still see my other mails. Stef
