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
Cheers
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project