[Pharo-project] CS in pharo
We have two important fixes: compiler fixes and trait that are in Changesets or cannot be loaded (in the case of the compiler with MC). I suggest for now to add them as changesets Then we should keep the Compiler package to evaluate if MC1.6 can be used. I asked matthew to see if he can load the package.
I still believe that having atomic loading in pharo is important.
Stef
Issue 167: Please check the traits fixes http://code.google.com/p/pharo/issues/detail?id=167
Comment #2 by adrian.lienhard: additionally remove caching of marker methods and make condensing work looks good now
how do we integrate this since it is a changeset?
Attachments: TraitsSharingCM-3.cs 14.6 KB
Hi Stef, Stéphane Ducasse wrote:
We have two important fixes: compiler fixes and trait that are in Changesets or cannot be loaded (in the case of the compiler with MC). I suggest for now to add them as changesets Then we should keep the Compiler package to evaluate if MC1.6 can be used. I asked matthew to see if he can load the package.
I still believe that having atomic loading in pharo is important. I had atomic loading working in Squeak ca. 10 years ago, and I'm currently getting it working in Pharo, because I need it for a project I'm working on. As I told you, I'm quite happy to give it to you if you want to use it.
Cheers -- Joseph Pelrine [ | ] MetaProg GmbH Email: jpelrine@metaprog.com Web: http://www.metaprog.com You don't become enormously successful without encountering some really interesting problems. - Mark Victor Hansen
Ok our concern is that we cannot throw away our current architecture squeaksource and so on. Since this is a really important communication medium within the squeak community. But we will see. Stef On Sep 19, 2008, at 10:06 AM, Joseph Pelrine wrote:
Hi Stef,
Stéphane Ducasse wrote:
We have two important fixes: compiler fixes and trait that are in Changesets or cannot be loaded (in the case of the compiler with MC). I suggest for now to add them as changesets Then we should keep the Compiler package to evaluate if MC1.6 can be used. I asked matthew to see if he can load the package.
I still believe that having atomic loading in pharo is important. I had atomic loading working in Squeak ca. 10 years ago, and I'm currently getting it working in Pharo, because I need it for a project I'm working on. As I told you, I'm quite happy to give it to you if you want to use it.
Cheers -- Joseph Pelrine [ | ] MetaProg GmbH Email: jpelrine@metaprog.com Web: http://www.metaprog.com
You don't become enormously successful without encountering some really interesting problems. - Mark Victor Hansen
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
what is the principal behind yoru atomic loading? - Another namespace - one become 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 bar. Stef On Sep 19, 2008, at 10:06 AM, Joseph Pelrine wrote:
Hi Stef,
Stéphane Ducasse wrote:
We have two important fixes: compiler fixes and trait that are in Changesets or cannot be loaded (in the case of the compiler with MC). I suggest for now to add them as changesets Then we should keep the Compiler package to evaluate if MC1.6 can be used. I asked matthew to see if he can load the package.
I still believe that having atomic loading in pharo is important. I had atomic loading working in Squeak ca. 10 years ago, and I'm currently getting it working in Pharo, because I need it for a project I'm working on. As I told you, I'm quite happy to give it to you if you want to use it.
Cheers -- Joseph Pelrine [ | ] MetaProg GmbH Email: jpelrine@metaprog.com Web: http://www.metaprog.com
You don't become enormously successful without encountering some really interesting problems. - Mark Victor Hansen
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
FYI, there is a working infrastructure for atomic loading here: http://source.wiresong.ca/mc/SystemEditor-mtf.69.mcz Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
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: jpelrine@metaprog.com Web: http://www.metaprog.com You don't become enormously successful without encountering some really interesting problems. - Mark Victor Hansen
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
participants (3)
-
Joseph Pelrine -
Lukas Renggli -
Stéphane Ducasse