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