[update 1.2] #12188

12188
-----

- Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down.
- Issue 2875: PharoKernel Part 11. Thanks Pavel Krivanek and Nicolas Paes

Stef

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

El lun, 11-10-2010 a las 10:56 +0200, Stéphane Ducasse escribió:
> 12188
> -----
>
> - Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down.
> - Issue 2875: PharoKernel Part 11. Thanks Pavel Krivanek and Nicolas Paes
>

Now that John Maloney has released MicroSqueak as MIT
(http://web.media.mit.edu/~jmaloney/microsqueak/) shouldn't be worth to
analize it and see if that can be used as an alternative to build the
Pharo Kernel.

I know that Pavel (and now also Nicolas) have done a lot of work in
getting PharoCore stripped to a minimal kernel.
But as I understand, PharoKernel idea is to part from a core image,
reorganize packages, _unload_ what isn't needed and then shrink the
image to get a kernel image.

The approach of John Maloney's MicroSqueak is the inverse, parting from
a source code representation and from there to aggregate code until have
a full image.

Of course the image from John hasn't all the improvements that Squeak
and Pharo have made to the core classes and that will mean a lot of
effort to reapply in order to get a modern image.

But I wonder, and not meaning to discourage any possibility, if isn't
worth to discuss the technical effort required and the pros/cons of each
approach and if isn't possible a reutilization of knowledge for this
very wanted goal of Pharo.

Cheers

--
Miguel Cobá
http://miguel.leugim.com.mx


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

> Now that John Maloney has released MicroSqueak as MIT
> (http://web.media.mit.edu/~jmaloney/microsqueak/) shouldn't be worth to
> analize it and see if that can be used as an alternative to build the
> Pharo Kernel.

Yes we already started. Now I think that producing microsqueak for pharo should just be the easy part.
Because after you want to be able to load package and not a large mess.

So this is why we did the two in parallel since august
        - trying to recompile a kernel (for example as specified by pharo kernel) and fixing all the packages
        problems we could find. So we build
                                                        - tools to analyse the system
                                                        - read a GNU ST based bootstrap
                                                        - read chacharas (we did not read spoon because we could not find it)
       
        - We were thinking that in parallel we would use an approach like chacharas (dynamic creation of a kernel based on an expression definitively cool). gabriel started to have a look at to build a micro kernel. So now that we have one we will check it.

> I know that Pavel (and now also Nicolas) have done a lot of work in
> getting PharoCore stripped to a minimal kernel.
> But as I understand, PharoKernel idea is to part from a core image,
> reorganize packages, _unload_ what isn't needed and then shrink the
> image to get a kernel image.

Not necessarily. It was just starting somewhere.

> The approach of John Maloney's MicroSqueak is the inverse, parting from
> a source code representation and from there to aggregate code until have
> a full image.

I think that this is the way to go. But there is a middle man missing.

> Of course the image from John hasn't all the improvements that Squeak
> and Pharo have made to the core classes and that will mean a lot of
> effort to reapply in order to get a modern image.

It should not be that difficult.
The core image does not have to have everything. It can be simple and part of it can be overload/overridden.
Now the process to go from seed (microsqueak pharo name) to pharo kernel is really important because
we will find all kinds of dead skeleton in the drawers :)

> But I wonder, and not meaning to discourage any possibility, if isn't
> worth to discuss the technical effort required and the pros/cons of each
> approach and if isn't possible a reutilization of knowledge for this
> very wanted goal of Pharo.

We already did that :)
And we will continue to learn and build.

Stef

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

El lun, 11-10-2010 a las 22:56 +0200, Stéphane Ducasse escribió:
Ah, good to know. I will be very happy to someday take a 50k input, and
a script.st file containing a ConfigurationOfXXX load sentence and get a
fully featured custom image.
Keep the good job.

Cheers

--
Miguel Cobá
http://miguel.leugim.com.mx


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

>>
>
> Ah, good to know. I will be very happy to someday take a 50k input, and
> a script.st file containing a ConfigurationOfXXX load sentence and get a
> fully featured custom image.
> Keep the good job.

I hope :)
and ideally I would like to have binary loading instead of having the compiler loaded first :)
but it takes time.


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

Hi Stef--

> ...we did not read spoon because we could not find it

     Oh dear, it looks like the company that serves the Spoon files
changed names. I've updated http://netjam.org/spoon/.

     Please do let me know whenever there's trouble getting stuff
(apologies if you did and I didn't see it). I only recently started
reading the Pharo list.


     thanks again,

-C

--
Craig Latta
www.netjam.org
+ 31 020 894 6247
+  1 415 287 3547

THanks Graig. I could download it and run it :)

Thanks

Mariano