On 29.06.2009, at 22:19, Hernan Wilkinson wrote:
>
> there are two answers:
> in Squeak the changes file gets full too quickly
>
> Ups, I did not know about that. what is the limit? why?
>
Smalltalk was originally realized for a *very* resource contrained
machine.
(a self-build, very impressive design. Amazing for the time and in
some aspects
even today). But: Lots of design desicions had to be made that where
purely driven
by resource constraints.
So for the sources and changes this meant:
a) changes and sources use the same mechanism.
b) they are not nicely object-oriented in the image but outside.
c) the way this is done is a wonderful ugly hack.
The last bytecodes of any method are not bytecodes at all, but instead
they form a pointer
to the sources and changes files. The end of the story is that this
means that both can be
max. 32MB in size. Plenty even 10 years ago, not enough to update from
3.8 to 3.9 today.
(changes file needs to be reseted at some point).
I personally think that with today's resources (my laptop has 4GB of
Ram, not 256Kb), we should
rethink some of the design-desicions taken 30 years ago. But many
people are violently against
this, fighting a battle by citing "embedded systems". If one manages
to convince them
that "embedded" these days does not equal "small", they mumble about
"smart dust" and obscure things
just to be able to fight for hacks not needed these days...
Exploring new ways with the resources we have today does not mean that
everything needs to live in the
image. It means that one can affort to invest resources into very
general, reusable solution to problems
like this.
One interesting aspect of the source/changes "outside the image" is
that this problem of data that is
not used often and thus can live on disk vs. memory is a general one.
Hacking it into the system just
for the sources is just that: a hack. Providing a general, scalable
way to let objects live on disk
that are not needed is much better, as everyone can than use it. The
system can use it for other resources
(fonts, images...). Programmers can use it to keep their domain data
on disk automatically.
Marcus
--
Marcus Denker - http://marcusdenker.de
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
