loading ClosureBootstrap-08-11-14 in Pharo.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

loading ClosureBootstrap-08-11-14 in Pharo.

Stéphane Ducasse
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

hackstogettoclosure.3.cs (24K) Download Attachment
ClosureBootstrap-08-11-14-John-M-McIntosh-ALTERED.tar.zip (258K) Download Attachment
TempVariableNode-analyseClosure.st (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: loading ClosureBootstrap-08-11-14 in Pharo.

Rob Rothwell
I'm not an expert at MC and script loader, but as a "newbie" I have spent more time building images than actually programming, so I would be happy to help try things out if you need volunteers.  I am actually running the current pharo image with the new VM already just because I was wondering if it would work!

Rob

On Mon, Mar 9, 2009 at 2:34 PM, Stéphane Ducasse <[hidden email]> 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.








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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: loading ClosureBootstrap-08-11-14 in Pharo.

Stéphane Ducasse
In reply to this post 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: loading ClosureBootstrap-08-11-14 in Pharo.

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: loading ClosureBootstrap-08-11-14 in Pharo.

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: loading ClosureBootstrap-08-11-14 in Pharo.

Lukas Renggli
In reply to this post by Stéphane Ducasse
>        - 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: loading ClosureBootstrap-08-11-14 in Pharo.

Stéphane Ducasse
In reply to this post by Rob Rothwell
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 <[hidden email]
> > 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: loading ClosureBootstrap-08-11-14 in Pharo.

Stéphane Ducasse
In reply to this post by Lukas Renggli

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: loading ClosureBootstrap-08-11-14 in Pharo.

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
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: loading ClosureBootstrap-08-11-14 in Pharo.

Lukas Renggli
> One also needs to carefully check that the changes do not revert any
> fixes/modifications we did in Pharo.

I guess they do revert changes, because it affects so much code across
the whole system.

The ByteArray #[] tests amazingly still pass ;-)

This is also the reason why I am pushing the closure implementation.
As Pharo improves it becomes more and more difficult (if not
impossible) to load such low-level changes into the image.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: loading ClosureBootstrap-08-11-14 in Pharo.

Stéphane Ducasse
In reply to this post by Adrian Lienhard
Yes this was the idea

Stef
On Mar 9, 2009, at 10:08 PM, Adrian Lienhard wrote:

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: loading ClosureBootstrap-08-11-14 in Pharo.

Stéphane Ducasse
In reply to this post by Lukas Renggli
did you try to check the conflicts for each cs that the install loads?
It does not load if I remember correctly but just check for conflict.

Stef


On Mar 10, 2009, at 8:45 AM, Lukas Renggli wrote:

>> One also needs to carefully check that the changes do not revert any
>> fixes/modifications we did in Pharo.
>
> I guess they do revert changes, because it affects so much code across
> the whole system.
>
> The ByteArray #[] tests amazingly still pass ;-)
>
> This is also the reason why I am pushing the closure implementation.
> As Pharo improves it becomes more and more difficult (if not
> impossible) to load such low-level changes into the image.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: loading ClosureBootstrap-08-11-14 in Pharo.

Stéphane Ducasse
In reply to this post by Adrian Lienhard
ok how can we coordinate to give a try and make it working?
I'm away until wednesday evening.

Stef
On Mar 9, 2009, at 10:08 PM, Adrian Lienhard wrote:

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


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