- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Major shrinks

by Marcus Denker

On Mar 23, 2010, at 2:53 PM, Marcus Denker wrote: > > In 1.1, I get 7.6MB. > > -> I added cleanUpForRelease as the last call before deleting the package in cleanUpForProduction. > -> I added the code code to empty the changeset after that. > > (I will put these fixes with Mariano's and Noury's (related to the logo) into the release today) > > Cleaning the changesets is *important* as they hold on to a lot of stuff... > In 11289: ScriptLoader new cleanUpForProduction -->7.6 MB Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 23, 2010

[Pharo-project] [update 1.1] #11289

by Marcus Denker

11289 ----- Issue 296: Logo inside Pharo window should be locked ... Issue 2196: Better cleanupForProduction -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 23, 2010

Re: [Pharo-project] Major shrinks

by Miguel Enrique CobÃ¡ Martinez

El mar, 23-03-2010 a las 15:04 +0100, Mariano Martinez Peck escribiÃ³: > > > 2010/3/23 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > El mar, 23-03-2010 a las 13:56 +0100, Mariano Martinez Peck > escribiÃ³: > > > > > > On Tue, Mar 23, 2010 at 1:52 PM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > > mariano > > > > cleanUp: true > > support agrresive cleanup = "shrink" > > > > > > > > > > Thanks...I didn't know. So...instead of cleanUp: aBoolean > why not > > to have a method called shrink ? or something better that > someone can > > think :) > > > Because not only shrinks the image, but also does other clean > up tasks > like resetting caches and similar. They have a shrink effect, > but mainly > are for cleaning things for example for release. > > You didn't understand me. When not to call it agressiveClean instead > of having a fac.. boolean and having to do > aBoolean ifTrue: [ blah blag] ifFalse: [ blah blah blah] > > There is something I don't see ? I would have: > > cleanUp > > agressiveCleanUp > > where this last one, may call cleanUp too > Oh, I see. No idea, that is how Keith (I think) and Andreas proposed the change for Squeak that Stef applied to Pharo. :) Cheers > > > > > > > Cheers > > > > Mariano > > > > > > On Mar 23, 2010, at 10:24 AM, Mariano Martinez Peck > wrote: > > > > > > > > > > > On Tue, Mar 23, 2010 at 10:19 AM, Lukas Renggli > > <renggli(a)gmail.com> wrote: > > > What I do on my build server is to unload the > tests: > > > > > > (MCWorkingCopy allManagers > > > inject: Gofer new > > > into: [ :gofer :each | > > > ((each packageName endsWith: > 'Test') or: > > [ each > > > packageName endsWith: 'Tests' ]) > > > ifTrue: [ gofer package: > each > > packageName ]. > > > gofer ]) > > > unload. > > > > > > > > > ScriptLoader >> cleanUpForProduction do that but > similary: > > > > > > #(#Tests #CollectionsTests #CompilerTests > #FreeTypeTests > > #GraphicsTests #KernelTests #MorphicTests > #MultilingualTests > > #NetworkTests #ToolsTest) > > > do: [ :each | (MCPackage named: each) > unload ]. > > "unload SUnit" > > > Smalltalk globals > > > at: #TestCase > > > ifPresent: [ :class | SystemChangeNotifier > > uniqueInstance noMoreNotificationsFor: class ]. > > > #(#SUnitGUI #SUnit) do: [ :each | (MCPackage > named: > > each) unload ]. > > > > > > > > > Maybe we you should change it ? > > > > > > > > > > Hi folks. I was playing a bit trying to shrink a > little a > > PharoCore image. > > > > My idea was to think a shrink that was be > acceptable for > > the most common > > > > scenario: a runtime (production) environment > where. Of > > course, some of the > > > > things I do in the shrinks has side effects, but > most of > > the times, you can > > > > deal with that in such scenarios. > > > > > > Shouldn't most of the code you publish be part of > the > > <cleanup> protocol? > > > > > > > > > You refere to the "new" cleanUp protocol ? > > > > > > The thing is that not everything is a cleanUp, but > a shrink. > > Suppose the code that zap all the > organizations...that's not a > > cleanUp. > > > So, maybe yes, but not all of them. > > > > > > Cheers > > > > > > Mariano > > > > > > > > > Lukas > > > > > > -- > > > Lukas Renggli > > > http://www.lukas-renggli.ch > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

March 23, 2010

Re: [Pharo-project] Major shrinks

by Mariano Martinez Peck

2010/3/23 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > El mar, 23-03-2010 a las 13:56 +0100, Mariano Martinez Peck escribiÃ³: > > > > > > On Tue, Mar 23, 2010 at 1:52 PM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > > mariano > > > > cleanUp: true > > support agrresive cleanup = "shrink" > > > > > > > > > > Thanks...I didn't know. So...instead of cleanUp: aBoolean why not > > to have a method called shrink ? or something better that someone can > > think :) > > Because not only shrinks the image, but also does other clean up tasks > like resetting caches and similar. They have a shrink effect, but mainly > are for cleaning things for example for release. > You didn't understand me. When not to call it agressiveClean instead of having a fac.. boolean and having to do aBoolean ifTrue: [ blah blag] ifFalse: [ blah blah blah] There is something I don't see ? I would have: cleanUp agressiveCleanUp where this last one, may call cleanUp too > > > > > > Cheers > > > > Mariano > > > > > > On Mar 23, 2010, at 10:24 AM, Mariano Martinez Peck wrote: > > > > > > > > > > > On Tue, Mar 23, 2010 at 10:19 AM, Lukas Renggli > > <renggli(a)gmail.com> wrote: > > > What I do on my build server is to unload the tests: > > > > > > (MCWorkingCopy allManagers > > > inject: Gofer new > > > into: [ :gofer :each | > > > ((each packageName endsWith: 'Test') or: > > [ each > > > packageName endsWith: 'Tests' ]) > > > ifTrue: [ gofer package: each > > packageName ]. > > > gofer ]) > > > unload. > > > > > > > > > ScriptLoader >> cleanUpForProduction do that but similary: > > > > > > #(#Tests #CollectionsTests #CompilerTests #FreeTypeTests > > #GraphicsTests #KernelTests #MorphicTests #MultilingualTests > > #NetworkTests #ToolsTest) > > > do: [ :each | (MCPackage named: each) unload ]. > > "unload SUnit" > > > Smalltalk globals > > > at: #TestCase > > > ifPresent: [ :class | SystemChangeNotifier > > uniqueInstance noMoreNotificationsFor: class ]. > > > #(#SUnitGUI #SUnit) do: [ :each | (MCPackage named: > > each) unload ]. > > > > > > > > > Maybe we you should change it ? > > > > > > > > > > Hi folks. I was playing a bit trying to shrink a little a > > PharoCore image. > > > > My idea was to think a shrink that was be acceptable for > > the most common > > > > scenario: a runtime (production) environment where. Of > > course, some of the > > > > things I do in the shrinks has side effects, but most of > > the times, you can > > > > deal with that in such scenarios. > > > > > > Shouldn't most of the code you publish be part of the > > <cleanup> protocol? > > > > > > > > > You refere to the "new" cleanUp protocol ? > > > > > > The thing is that not everything is a cleanUp, but a shrink. > > Suppose the code that zap all the organizations...that's not a > > cleanUp. > > > So, maybe yes, but not all of them. > > > > > > Cheers > > > > > > Mariano > > > > > > > > > Lukas > > > > > > -- > > > Lukas Renggli > > > http://www.lukas-renggli.ch > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2010

Re: [Pharo-project] Major shrinks

by Miguel Enrique CobÃ¡ Martinez

El mar, 23-03-2010 a las 13:56 +0100, Mariano Martinez Peck escribiÃ³: > > > On Tue, Mar 23, 2010 at 1:52 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > mariano > > cleanUp: true > support agrresive cleanup = "shrink" > > > > > Thanks...I didn't know. So...instead of cleanUp: aBoolean why not > to have a method called shrink ? or something better that someone can > think :) Because not only shrinks the image, but also does other clean up tasks like resetting caches and similar. They have a shrink effect, but mainly are for cleaning things for example for release. > > Cheers > > Mariano > > > On Mar 23, 2010, at 10:24 AM, Mariano Martinez Peck wrote: > > > > > > > On Tue, Mar 23, 2010 at 10:19 AM, Lukas Renggli > <renggli(a)gmail.com> wrote: > > What I do on my build server is to unload the tests: > > > > (MCWorkingCopy allManagers > > inject: Gofer new > > into: [ :gofer :each | > > ((each packageName endsWith: 'Test') or: > [ each > > packageName endsWith: 'Tests' ]) > > ifTrue: [ gofer package: each > packageName ]. > > gofer ]) > > unload. > > > > > > ScriptLoader >> cleanUpForProduction do that but similary: > > > > #(#Tests #CollectionsTests #CompilerTests #FreeTypeTests > #GraphicsTests #KernelTests #MorphicTests #MultilingualTests > #NetworkTests #ToolsTest) > > do: [ :each | (MCPackage named: each) unload ]. > "unload SUnit" > > Smalltalk globals > > at: #TestCase > > ifPresent: [ :class | SystemChangeNotifier > uniqueInstance noMoreNotificationsFor: class ]. > > #(#SUnitGUI #SUnit) do: [ :each | (MCPackage named: > each) unload ]. > > > > > > Maybe we you should change it ? > > > > > > > Hi folks. I was playing a bit trying to shrink a little a > PharoCore image. > > > My idea was to think a shrink that was be acceptable for > the most common > > > scenario: a runtime (production) environment where. Of > course, some of the > > > things I do in the shrinks has side effects, but most of > the times, you can > > > deal with that in such scenarios. > > > > Shouldn't most of the code you publish be part of the > <cleanup> protocol? > > > > > > You refere to the "new" cleanUp protocol ? > > > > The thing is that not everything is a cleanUp, but a shrink. > Suppose the code that zap all the organizations...that's not a > cleanUp. > > So, maybe yes, but not all of them. > > > > Cheers > > > > Mariano > > > > > > Lukas > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

March 23, 2010

Re: [Pharo-project] Move MetaObjectTools from core to PharoDev

by Mariano Martinez Peck

Stef, I was thinking to put not only ProtocolCatcher but also all your stuff from ObjectAsMethodWrapper in the same ObjectMetaTools. That way we have a repository with cool stuff what do you think ? cheers Mariano On Sat, Mar 20, 2010 at 5:12 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sat, Mar 20, 2010 at 4:44 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Thanks I will do that! >> can you open a ticket because the list is starting to get long of the >> stuff to integrate after martin's changes. >> > > http://code.google.com/p/pharo/issues/detail?id=2180 > > >> BTW did you check if the other class besides ProtocolCatcher are working? >> >> > No. No time yet. > > > >> Stef >> >> On Mar 20, 2010, at 4:22 PM, Mariano Martinez Peck wrote: >> >> > This package should be removed from core but it should still be >> loadable. Thus, when needed, they can be easily installed. On the other >> hand, it could be in PharoDev image. >> > >> > - MetaObjectTools: This package is moved to PharoDev. It doesnt have >> any users in PharoCore >> > >> > To fix, evaluate: >> > >> > (MCPackage named: 'ObjectMetaTools') unload. >> > >> > I created and put such code in >> http://www.squeaksource.com/ObjectMetaTools >> > >> > To load it again in a Pharo image: >> > >> > Gofer new >> > squeaksource: 'ObjectMetaTools'; >> > package: 'ObjectMetaTools'; >> > load. >> > >> > During the week I will analyze the CUIS' ProtocolCatcher and see if it >> make sense to put it there too. >> > >> > Cheers >> > >> > Mariano >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

March 23, 2010

Re: [Pharo-project] Major shrinks

by Adrian Lienhard

On Mar 23, 2010, at 14:53 , Marcus Denker wrote: > > On Mar 23, 2010, at 10:29 AM, Adrian Lienhard wrote: > >> Hi Mariano, >> >> Great to see further progress on this! I'll take a closer look at your script this evening. But what I wonder is why PharoCore 1.1 is so big and you only get down to 9MB (is this the size on disk?)? >> >> In a PharoCore 1.0 running #cleanUpForRelease, #cleanUpForProduction, deleting the class ScriptLoader and all changesets I get an image that is 8.1MB on disk. > > In 1.1, I get 7.6MB. > > -> I added cleanUpForRelease as the last call before deleting the package in cleanUpForProduction. > -> I added the code code to empty the changeset after that. > > (I will put these fixes with Mariano's and Noury's (related to the logo) into the release today) > > Cleaning the changesets is *important* as they hold on to a lot of stuff... Cool! We should also not forget to add and run the changeset cleaning to 1.0 before the release. Adrian > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 23, 2010

Re: [Pharo-project] Major shrinks

by Marcus Denker

On Mar 23, 2010, at 10:29 AM, Adrian Lienhard wrote: > Hi Mariano, > > Great to see further progress on this! I'll take a closer look at your script this evening. But what I wonder is why PharoCore 1.1 is so big and you only get down to 9MB (is this the size on disk?)? > > In a PharoCore 1.0 running #cleanUpForRelease, #cleanUpForProduction, deleting the class ScriptLoader and all changesets I get an image that is 8.1MB on disk. In 1.1, I get 7.6MB. -> I added cleanUpForRelease as the last call before deleting the package in cleanUpForProduction. -> I added the code code to empty the changeset after that. (I will put these fixes with Mariano's and Noury's (related to the logo) into the release today) Cleaning the changesets is *important* as they hold on to a lot of stuff... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 23, 2010

Re: [Pharo-project] Implementing MethodWrappers in Smalltalk

by Mariano Martinez Peck

On Mon, Mar 22, 2010 at 9:31 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Hi Mariano, > > I worked on a similar problem for a new code profiler. Spy is a framework > for easily performing program execution analysis. > A short tutorial, screenshots, and some examples are available on: > http://www.moosetechnology.org/tools/Spy > > If you're working in that direction, I would be delighted to collaborate. > > Hi Alexandre. I am not sure if it is in the same direction, but anyhow it is worth to look at it. I will try to do it this week and I will let you know. Basically, what i am investigating is: I want to develop a mechanism for Smalltalk that automatically can swap out objects that are not needed but still have objects pointing to them (otherwise the GC would take care), and bring them again when needed. So...image an image that can increase or decrease on demand and automatically. I have several steps, but the first one is how to detect those objects. I have different approaches in mind. For a first moment, I was trying to detect which classes and which methods were being used. Of course, the first approach (although it will probably not scale) was to create a method wrapper for that. Even almost the same as TestCoverage. Now I am looking at CUIS' ProtocolCatcher, which has a different approach. Cheers Mariano > Cheers, > Alexandre > > > > On 22 Mar 2010, at 12:51, Mariano Martinez Peck wrote: > > Hi folks. I was reading the PBE chapter about reflection where it talks a >> little about Method Wrappers. Then, I took a look at TestCoverage >> implementation. >> >> After that, I took a look at >> http://www.squeaksource.com/ObjectsAsMethodsWrap >> >> The main difference between both approaches are: >> >> TestCoverage >> - Just extends from ProtoObject, implement doesNotUnderstand: , run: >> aSelector with: anArray in: aReceiver , etc >> - To install and uninstall the wrappers uses methodDictionary at: xxx >> put: yyy >> - Just for test coverage. >> >> ObjectAsMethodWrapper >> - Is more generic, support pre and post closures, and you can subclass and >> create you own wrapper >> - To install and uninstall the wrappers it uses Class >> addSelector: self >> selector withMethod: self >> >> So...what I did ?? I created a TestCoverage but creating a subclass of >> ObjectAsMethodWrapper called TestCoverageMethodWrapper which just >> implements a 1 or 2 methods. I mean, I reused the generic >> ObjectAsMethodWrapper. It seems to work ok. >> >> I did some test running TestCoverage with both implementation and it seems >> mine (TestCoverageMethodWrapper) is 30% much slower than the original. >> Trying to understand why, I think it is because the original one uses just >> methodDictionary at: xxx put: yyy >> but mine uses Class >> addSelector: self selector withMethod: self. >> In this last method, there are all the notifications, add to >> localSelectors...etc >> >> Now...I have two questions: >> >> 1) For a generic approach to method wrappers, which of those two ways >> would you use ? should I care about notifying, adding to localSelectors, >> etc? Or at is just temporal, I don't care ? >> which are the pros and cons you see with each alternative ? >> >> 2) Do you think it make sense to the package ObjectsAsMethodsWrap in >> PharoCore as a "library" to create lightweight proxies ? It is just 4 >> classes and it would be cool to change TestCoverage to that implementation. >> Then, you only don't have the library, but also some real examples. Of >> course, this can be done if we eleiminate the 30% of slowleness. >> >> >> so...what do you think ? >> >> Cheers >> >> Mariano >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2010

Re: [Pharo-project] Major shrinks

by Mariano Martinez Peck

On Tue, Mar 23, 2010 at 1:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > mariano > > cleanUp: true > support agrresive cleanup = "shrink" > > Thanks...I didn't know. So...instead of cleanUp: aBoolean why not to have a method called shrink ? or something better that someone can think :) Cheers Mariano > On Mar 23, 2010, at 10:24 AM, Mariano Martinez Peck wrote: > > > > > > > On Tue, Mar 23, 2010 at 10:19 AM, Lukas Renggli <renggli(a)gmail.com> > wrote: > > What I do on my build server is to unload the tests: > > > > (MCWorkingCopy allManagers > > inject: Gofer new > > into: [ :gofer :each | > > ((each packageName endsWith: 'Test') or: [ each > > packageName endsWith: 'Tests' ]) > > ifTrue: [ gofer package: each packageName ]. > > gofer ]) > > unload. > > > > > > ScriptLoader >> cleanUpForProduction do that but similary: > > > > #(#Tests #CollectionsTests #CompilerTests #FreeTypeTests #GraphicsTests > #KernelTests #MorphicTests #MultilingualTests #NetworkTests #ToolsTest) > > do: [ :each | (MCPackage named: each) unload ]. "unload SUnit" > > Smalltalk globals > > at: #TestCase > > ifPresent: [ :class | SystemChangeNotifier uniqueInstance > noMoreNotificationsFor: class ]. > > #(#SUnitGUI #SUnit) do: [ :each | (MCPackage named: each) unload ]. > > > > > > Maybe we you should change it ? > > > > > > > Hi folks. I was playing a bit trying to shrink a little a PharoCore > image. > > > My idea was to think a shrink that was be acceptable for the most > common > > > scenario: a runtime (production) environment where. Of course, some of > the > > > things I do in the shrinks has side effects, but most of the times, you > can > > > deal with that in such scenarios. > > > > Shouldn't most of the code you publish be part of the <cleanup> protocol? > > > > > > You refere to the "new" cleanUp protocol ? > > > > The thing is that not everything is a cleanUp, but a shrink. Suppose the > code that zap all the organizations...that's not a cleanUp. > > So, maybe yes, but not all of them. > > > > Cheers > > > > Mariano > > > > > > Lukas > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2010