Another important aspect, which i missed. That LPF is a script. Its intentionally made so, that you could try adopt it and load MC into very obscure environment. Let me remind you, that our 'holy grail' of modularity is to have a minimal kernel with basic classes and compiler, while rest is optional. In this terms, LPF project is a highly valuable piece, which fits just well with such concept: you can build an image from first principles starting from kernel and then up to the image which could load MC packages and up to an image which having the rest in the squeak world. So, i really hope, that efforts which took by Keith and Matthew and other contributors will not be put in vane. And therefore making a call to a anyone who could volunteer to support and maintain this project for the benefit of both Pharo and Squeak communities, and many other forks. 2009/10/21 Igor Stasenko <siguctua@gmail.com>:

I had chat with Matthew today, and he said that he could turn his head back on MC 1.6 for a bit. But he doesn't guarantees that he can spend much time on it, so i asked him first, to write the small report - an overview, which lists the problems its having and in what way they can be solved.

Then, i hope, someone could pick up the task and make it available.

Next thing is a clarification about LPF from its respectible developer(s): LPF is an 'MC 1.6' , in terms that its a main tool which provides means to load & install MC 1.6 in *your image*.

By *your image* i meant that LPF is not targeted for a particular squeak version or its fork - it attempts to target as many of them as possible. And this means, that LPF (along with MC 1.6) could serve as a common ground for many existing squeak versions and its forks.

And this means, in own turn, that it is in our best interests to make it adopted. :)

In a future, i suggest to use a better naming for a projects, like LPF, or make name to be more elaborate (like LPF - the MC 1.6 bootstrapper) because its confusing the people up to the point that they don't understand why it is so good to have it.

2009/10/21 Stéphane Ducasse <stephane.ducasse@inria.fr>:

...

I would love to have that. I started to migrate some 1.5 code (fast loading) from MC15 to pharo MC15 but nobody have a look at the slice I published

Stef

...

Hello people,

i'd like to see some answers about the fate of MC 1.6. and its current situation.

1. I think everyone wants to have an atomic loading. But according to my knowledge, MC 1.6. has some problems with Traits, which prevets us from using it & fully replace the older version.

2. Besides of that, are there any other reasons to not have it?

So, please, can we disscuss (friendly & constructive), what we might need to have it integrated in Squeak and in Pharo, so we could benefit from having an atomic loading?

-- Best regards, Igor Stasenko AKA sig.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

-- Best regards, Igor Stasenko AKA sig.

2009/10/22 keith <keith_hodges@yahoo.co.uk>:

What more do you want?

I am always want more :) Here the vision what i having: - take a minimal kernel image (Pavel's works going in mind) - load LPF there, make it work, make sure that it could load any MC packages after that - use a version control for LPF script (put it on SVN somewhere) - continue efforts on making LPF become an extremely modular and self-sufficient piece of software, with very small dependencies from environment (only basic classes, like collections and most basic I/O - files and/or sockets)

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.