Squeak 1.0 was released in 1996. In 1995 i puschased my first PC with 150MHz CPU! So, clearly, it was never targeted for platform with such low clock rate. I think even if you take Squeak 1.0 (the root ancestor of Pharo), you will experience problems running it on 50 MHz CPU. Saying that, i don't deny that there are places which can be improved. But we need two things for that: - a motive - a testbed for it you stated the problem(s) but not motives. Even today's handheld devices running at 1GHz clock rate. Also, who should provide a testbed with such constrained environment? Any ideas? As Marcus practically proved: everything which is not tested is broken. So, either we will have testing platform for issues you listed and strong motivation to fix that, or we just keep expanding our own sandbox in direction we see fit :) On 7 November 2011 00:00, Guido Stepken <gstepken@googlemail.com> wrote:
Reading was not a problem. But I have problems to understand what I am supposed to understand?
Norbert
You are just coder, no software architect, right?
Ever tried Pharo 1.3 on a older machine, e.g. P75 with 32 MBytes RAM, some load on Seaside? Funny effects occurring... machine hangs, crashes, spends lots of time in useless functions, unneccessarily locking resouces, memory pumping, eating up resources while waiting for e.g. database answer, spending increasing amount of time (up to 98%) in removing garbage ....
It's a good way of identifying unmatured software designs.
Colliding mental models (e.g. event driven vs. polling) Such things happen, when all members are just coding, fixing, refactoring, without bothering about algorithms, that still work reliable at low memory and high load.
Pharo at the moment is still very unreliable.
Sorry to say that! Think about, why FreeBSD works reliably even at a load of 50, whereas other OS stop working.
regards, Guido Stepken
-- Best regards, Igor Stasenko.