September 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] CS in pharo

by StÃ©phane Ducasse

> 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

Sept. 19, 2008

Re: [Pharo-project] [ANN] first one-click image

by Damien Cassou

On Fri, Sep 19, 2008 at 11:17 AM, Marcus Denker <denker(a)iam.unibe.ch> wrote: > => more testing on Linux Works perfectly on Ubuntu 8.04 32bits. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 19, 2008

Re: [Pharo-project] Copyright inside one click is strange

by Damien Cassou

I think this is because the one-click image template comes from the Sophie project. Seaside developers basically just replaced the image in the zip. On Fri, Sep 19, 2008 at 8:38 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > it says > > Distribution based on Sophie http://www.sophieproject.org/ Seaside > http://www.seaside.st > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 19, 2008

Re: [Pharo-project] Image size

by StÃ©phane Ducasse

> > SMSqueakMap default purge > > --> 12.2MB > > that is, SqueakMap keep 1.5MB of data in the image. > We should remove it. > > >> Is there a reason why the cleanup code resides in ScriptLoader? >> > > No. > -- But where you will put it? Stef

Sept. 19, 2008

Re: [Pharo-project] [ANN] first one-click image

by StÃ©phane Ducasse

excellent! Stef On Sep 19, 2008, at 11:17 AM, Marcus Denker wrote: > Hi, > > There is now a first one-click image. This uses the packaging > invented by Impara for Plopp, > which later was used by Sophie and then even Seaside: > > https://gforge.inria.fr/frs/download.php/7078/Pharo0.1-10072-oneclick.zip > > on the Mac, this is an executable. On windows, this is a directory > with an .exe, for linux, > there is a pharo.sh. > > This has only been tested on Mac and Linux right now. > > Notes: > => COPYRIGHT needs to be fixed > => needs to be tested on Windows > => more testing on Linux > => fix icon for windows > => Icon is not yet final > => we need to add the truetype plugins / recompiled VM > > The idea behing this is that it should be very simple to get it > running for new people. > Those with lots of knowledge then can take the package appart and > use it like they want. > > The idea is that the one-click will have more tools later (syntax > highlighting, Refactoring, things > like that). In addtion there will be a .zip with a "core" image that > has the bare minimum for > deployment. The "download" link of the pharo website will point to > the one-click destribution. > > Marcus > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 19, 2008

Re: [Pharo-project] [ANN] update 10073

by Adrian Lienhard

On Sep 18, 2008, at 21:08 , StÃ©phane Ducasse wrote: >> >>> I would like to define some tests also to cover that CM are really >>> duplicated. >> >> btw., I'm in the process of making http://code.google.com/p/pharo/issues/detail?id=167 >> work correctly... > > why > It was broken? no, but it was not completely finished (like the effect of these changes on the sources/changes condensing procedure) Stef, in http://code.google.com/p/pharo/issues/detail?id=167 you removed that method properties are copied when we copy a compiled method (this is in #copyWithTrailerBytes:). I am not sure what the expected behavior actually is. What was your rationale? Adrian

Sept. 19, 2008

Re: [Pharo-project] Image size

by Marcus Denker

On 19.09.2008, at 11:19, Norbert Hartl wrote: > > SMSqueakMap default clearCaches. > > might be a candidate to add. > SMSqueakMap default purge --> 12.2MB that is, SqueakMap keep 1.5MB of data in the image. We should remove it. > Is there a reason why the cleanup code resides in ScriptLoader? > No. -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 19, 2008

Re: [Pharo-project] CS in pharo

by Joseph Pelrine

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(a)metaprog.com Web: http://www.metaprog.com You don't become enormously successful without encountering some really interesting problems. - Mark Victor Hansen

Sept. 19, 2008

Re: [Pharo-project] Image size

by Norbert Hartl

On Fri, 2008-09-19 at 11:06 +0200, Marcus Denker wrote: > On 19.09.2008, at 10:42, StÃ©phane Ducasse wrote: > > > did you flush the changesets ? > > That's important. Adrian lienhard sent this around some time > ago some cleanup code. Here is an updated version: > > > ScriptLoader new cleaningCS. > RequiredSelectors initialize. > ProvidedSelectors initialize. > LocalSends initialize. > Utilities cleanseOtherworldlySteppers. > Smalltalk organization removeEmptyCategories. > SystemBrowser removeObsolete. > TheWorldMenu removeObsolete. > AppRegistry removeObsolete. > MCFileBasedRepository flushAllCaches. > MCDefinition clearInstances. > Symbol compactSymbolTable. > Set rehashAllSets. > Smalltalk cleanOutUndeclared. > Smalltalk garbageCollect. > > --> 13.7 MB > 3.9 was 15.6 MB > > > There is more code for cleaning in the "cleaning" category of > ScriptLoader. > #initialCleanup and #finalCleanup. > (we should merge the code above in the cleanup methods) > > The changesets are the majority of the space, another 100K or so comes > from rehashing the sets. This is I think > because the methodDictionaries are degenerating very fast when adding / > replacing methods. > I had a look at it and SMSqueakMap default clearCaches. might be a candidate to add. Is there a reason why the cleanup code resides in ScriptLoader? Norbert

Sept. 19, 2008

[Pharo-project] [ANN] first one-click image

by Marcus Denker

Hi, There is now a first one-click image. This uses the packaging invented by Impara for Plopp, which later was used by Sophie and then even Seaside: https://gforge.inria.fr/frs/download.php/7078/Pharo0.1-10072-oneclick.zip on the Mac, this is an executable. On windows, this is a directory with an .exe, for linux, there is a pharo.sh. This has only been tested on Mac and Linux right now. Notes: => COPYRIGHT needs to be fixed => needs to be tested on Windows => more testing on Linux => fix icon for windows => Icon is not yet final => we need to add the truetype plugins / recompiled VM The idea behing this is that it should be very simple to get it running for new people. Those with lots of knowledge then can take the package appart and use it like they want. The idea is that the one-click will have more tools later (syntax highlighting, Refactoring, things like that). In addtion there will be a .zip with a "core" image that has the bare minimum for deployment. The "download" link of the pharo website will point to the one-click destribution. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 19, 2008