Stéphane Ducasse wrote:
what is the principal behind yoru atomic loading?
- Another namespace
- one become
Are you kidding? That's a pretty reckless way to do things. What I
do is a mix of the techniques used in ENVY and Team/V.
which is?
When we talk about atomic loading we mean that we should be able to
change the code
of a compiler while this one is currently compiling the changes
that should loaded.
Similarly, we should be able to modify the method that is currently
been executed and showing the progress
Ah, now I see. Our definition of atomic loading is not the same. For
me, atomic loading is a transaction-based load and modification of
semantic elements in the image. It either succeeds or it doesn't, in
which case rolls back, and the image is in the state it was before
the load.
For us atomic loading is also a transaction approach. But we MUST be
able to load code that modifies the compiler or the UI. Especially
until
we do not have a bootstrappable system. Else we would simply modify
the code and and rebuild the image from scratch.
Your approach only work for parts that are not defining in the loading
process itself.
For us atomic loading means that we can change deep aspects of the
system because we must. Changing the compiler or UI element is not
something
that we do because we are idiot researchers. So think twice.
Your approach is good once we will have bootstrappable system.
To answer your other statement, I can support multiple simultaneous
compilers, remote and local, although whether that makes sense is
another question.
I think the main difference in our thinking is that Pharo seems to
me to be a research project, while I'm just building the things I
need and am accustomed to from VA, VW, ENVY, etc., so that I can
develop software.
Come on. Developping applications is different than maintaining a core
of a smalltalk system. We can manage Seaside application
without problems in MC. Now maintaining and changing an image with
living objects being executing during the update mechanism is another
story
especially when you do not to rely on changeset.
Where pharo is a research project? Joseph seriously you do not know
what research is. Do not bash us.
Atomic loading is really needed and not for fun. I could show you
things that are research and this is clearly not what we are
doing in pharo (have a look at changebox that completely changes the
lookup of messages or classboxes. This is research and
this will not be put in pharo).
Now we have compiler fixes that cannot be loaded in a package system
without atomic loading because the compiler needs to run to install
the changes.
May be duplicating the compiler is a solution, may be loading bytecode
is another one, or using become.
Duplicating the compiler is just a hack because we cannot duplicate
morphic when we must changing a morphic method.
Stef
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
