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.
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.
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.
Cheers
--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: [EMAIL PROTECTED]
Web: http://www.metaprog.com
You don't become enormously successful without encountering some really
interesting problems.
- Mark Victor Hansen
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
