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 <[email protected]> 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.
