loading ClosureBootstrap-08-11-14 in Pharo.

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.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project