March 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Split System Category

by Michael Rueger

Hi all, SLICE-SplitSystemAndRenameTests is a config map that loads all split System-* packages as well as the System test packages renamed to Tests-System-xxx. The old System and Tests packages need to be removed manually or by a script? I'm still not really sure how to do these things... The config map already points to the changed package from the etoys cleanup slice. Michael

March 10, 2009

[Pharo-project] Fix for configuration browser

by Michael Rueger

Hi all, fix in inbox MonticelloConfigurations-michael_rueger.50 fixed missing parentheses in configuration browser Michael

March 10, 2009

[Pharo-project] more etoys cleanup slice

by Michael Rueger

Hi all, SLICE-removeBgPaintStickySketch-michael_rueger.1 includes a bit more etoys cleanup: - remove StickySketchMorph - remove the paint background halo on the world - remove related preferences and methods - removes empty Etoys system categories Affects packages Etoys, System and Morphic. Michael

March 10, 2009

Re: [Pharo-project] loading ClosureBootstrap-08-11-14 in Pharo.

by Adrian Lienhard

On Mar 9, 2009, at 21:48 , StÃ©phane Ducasse wrote: > > On Mar 9, 2009, at 9:45 PM, Lukas Renggli wrote: > >>> The only problem I see is that at some point you need to save, close >> and reopen the image. I guess this is necessary so that the VM >> forgets >> all the old contexts still lingering around. > > ok this means that we should create a new image and we cannot really > use the update > stream to upgrade existing image. I think it should be doable with the update stream, no? I would try to add the install.st at the beginning of the update and then load the most recent versions of the packages using ScriptLoader as usual (ignoring any existing changes). One also needs to carefully check that the changes do not revert any fixes/modifications we did in Pharo. Adrian

March 9, 2009

Re: [Pharo-project] loading ClosureBootstrap-08-11-14 in Pharo.

by StÃ©phane Ducasse

On Mar 9, 2009, at 9:45 PM, Lukas Renggli wrote: >> - produce a stream of cs and put it into the update stream >> - then produce the clean packages so that we are able to load >> incrementally (after the cs stream is loaded). >> the update streams. (but sometimes in the past we were not >> able to >> produce pakcages that >> could be loaded) > > Actually that stream is already contained in install.st. It loads all > the other cs in the right order. > > The only problem I see is that at some point you need to save, close > and reopen the image. I guess this is necessary so that the VM forgets > all the old contexts still lingering around. ok this means that we should create a new image and we cannot really use the update stream to upgrade existing image. > And of course the loading only works on a new VM. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch

March 9, 2009

Re: [Pharo-project] loading ClosureBootstrap-08-11-14 in Pharo.

by StÃ©phane Ducasse

no problem there are so many things I want to learn. Live will be too short I'm sure. Stef On Mar 9, 2009, at 9:26 PM, Rob Rothwell wrote: > Sounds like a lot of fun to learn, but it also sounds like you need > a lot more expert knowledge than I have! > > Take care, > > Rob > > On Mon, Mar 9, 2009 at 4:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > lukas > > >>> > >> I can load the code. > >> > >> However there is no way around loading around 30 change-sets in the > >> right order. Perform all kinds of manual actions, like restarting > >> the GUI process, saving the image and reopening it. > >> > >> After having loaded the change-sets dozens of packages are dirty, > >> from Compiler, Kernel, Collection, Morphic, ... I can publish > these, > >> but you won't be able to load them. Compiler, Encoder, > >> CompiledMethod, MethodContext, BlockContext, Debugger, ... there > are > >> many changes that can't just be loaded like that and that require > >> complicated object migration at the right points in time. > > I was more thinking > - produce a stream of cs and put it into the update stream > - then produce the clean packages so that we are able to load > incrementally (after the cs stream is loaded). > the update streams. (but sometimes in the past we were not > able to > produce pakcages that > could be loaded) > > This is clear that we still have a living system. > > Stef > > _______________________________________________ > 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 9, 2009

Re: [Pharo-project] loading ClosureBootstrap-08-11-14 in Pharo.

by Lukas Renggli

> Â Â Â Â - produce a stream of cs and put it into the update stream > Â Â Â Â - then produce the clean packages so that we are able to load > incrementally (after the cs stream is loaded). > Â Â Â Â the update streams. (but sometimes in the past we were not able to > produce pakcages that > Â Â Â Â could be loaded) Actually that stream is already contained in install.st. It loads all the other cs in the right order. The only problem I see is that at some point you need to save, close and reopen the image. I guess this is necessary so that the VM forgets all the old contexts still lingering around. And of course the loading only works on a new VM. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 9, 2009

Re: [Pharo-project] loading ClosureBootstrap-08-11-14 in Pharo.

by Rob Rothwell

Sounds like a lot of fun to learn, but it also sounds like you need a lot more expert knowledge than I have! Take care, Rob On Mon, Mar 9, 2009 at 4:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > lukas > > >>> > >> I can load the code. > >> > >> However there is no way around loading around 30 change-sets in the > >> right order. Perform all kinds of manual actions, like restarting > >> the GUI process, saving the image and reopening it. > >> > >> After having loaded the change-sets dozens of packages are dirty, > >> from Compiler, Kernel, Collection, Morphic, ... I can publish these, > >> but you won't be able to load them. Compiler, Encoder, > >> CompiledMethod, MethodContext, BlockContext, Debugger, ... there are > >> many changes that can't just be loaded like that and that require > >> complicated object migration at the right points in time. > > I was more thinking > - produce a stream of cs and put it into the update stream > - then produce the clean packages so that we are able to load > incrementally (after the cs stream is loaded). > the update streams. (but sometimes in the past we were not able to > produce pakcages that > could be loaded) > > This is clear that we still have a living system. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 9, 2009

Re: [Pharo-project] loading ClosureBootstrap-08-11-14 in Pharo.

by StÃ©phane Ducasse

lukas >>> >> I can load the code. >> >> However there is no way around loading around 30 change-sets in the >> right order. Perform all kinds of manual actions, like restarting >> the GUI process, saving the image and reopening it. >> >> After having loaded the change-sets dozens of packages are dirty, >> from Compiler, Kernel, Collection, Morphic, ... I can publish these, >> but you won't be able to load them. Compiler, Encoder, >> CompiledMethod, MethodContext, BlockContext, Debugger, ... there are >> many changes that can't just be loaded like that and that require >> complicated object migration at the right points in time. I was more thinking - produce a stream of cs and put it into the update stream - then produce the clean packages so that we are able to load incrementally (after the cs stream is loaded). the update streams. (but sometimes in the past we were not able to produce pakcages that could be loaded) This is clear that we still have a living system. Stef

March 9, 2009

Re: [Pharo-project] loading ClosureBootstrap-08-11-14 in Pharo.

by StÃ©phane Ducasse

Begin forwarded message: >> (1) you can load the code >> (2) publish package >> (3) load them? > > I can load the code. > > However there is no way around loading around 30 change-sets in the > right order. Perform all kinds of manual actions, like restarting > the GUI process, saving the image and reopening it. > > After having loaded the change-sets dozens of packages are dirty, > from Compiler, Kernel, Collection, Morphic, ... I can publish these, > but you won't be able to load them. Compiler, Encoder, > CompiledMethod, MethodContext, BlockContext, Debugger, ... there are > many changes that can't just be loaded like that and that require > complicated object migration at the right points in time. > > Lukas > > -- > Lukas Renggli, Seaside Core-Developer > http://www.lukas-renggli.ch > http://www.seaside.st > On Mar 9, 2009, at 7:34 PM, StÃ©phane Ducasse wrote: > Hi guys > > Here is an email of John related to closure for pharo. > We (the core) believe that it would be good to integrate really fast > the closure. > Now we need help > - we need to know if the vm are available and people can take care > of that > - we need some volunteer knowing MC and our script loader (lukas) > to check whether > (1) load the code > (2) publish package > (3) reload them > > Any suggestion how we could also proceed once the changes are pushed > in the stream > because the VM will not work. > > Stef > >> Ok, attached is a testing 4.0.0b1 macintosh carbon vm. It is not >> for public use yet because I've not included all the plugins and I >> need to cross check things >> for sanity. However you can use it to make a Pharo image with >> closure. >> >> To do this you need the hackstogettoclosure which gets you around >> some changes from squeak 3.9 to pharo. I've also altered the >> attached ClosureBootstrap-08-11-14-John-M-McIntosh-ALTERED.tar.zip >> a which is changed a bit from Eliot's version to remove some >> referrals to Morphic classes you have deleted in Pharo. >> >> If you follow the read me you should be able to take a >> Pharo0.1Core-10243 >> >> and end up with one complaint about TranslatedMethod being put in >> Undeclared, and 3 obsolete block contexts. and 3 Unbound Methods. >> >> If you can't get that far let me know. >> >> Obviously this is just a hack to see how far I could get, I'll >> assume you'll peer deeper because many of the change sets update >> code I'm sure you've altered for Pharo. >> >> >> >> >> > <hackstogettoclosure.3.cs><ClosureBootstrap-08-11-14-John-M-McIntosh- > ALTERED.tar.zip><TempVariableNode-analyseClosure.st> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 9, 2009