[Pharo-project] glamour and pharo

Lukas Renggli renggli at gmail.com
Mon Jan 2 04:42:03 EST 2012


>>> 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?

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 :-)

> 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




More information about the Pharo-dev mailing list