MC 1.6 status?

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

MC 1.6 status?

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

Re: MC 1.6 status?

Stéphane Ducasse
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
> [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: MC 1.6 status?

Igor Stasenko
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 <[hidden email]>:

> 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
>> [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
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
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: MC 1.6 status?

Igor Stasenko
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 <[hidden email]>:

> 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 <[hidden email]>:
>> 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
>>> [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
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
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: MC 1.6 status?

keith1y
What more do you want?

_______________________________________________
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: MC 1.6 status?

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



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
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: MC 1.6 status?

keith1y

I am always want more :)

fair enough

Here the vision what i having:

- take a minimal kernel image (Pavel's works going in mind)

I always intended to do this, but I never got pavels images to work on mac osx.

- load LPF there, make it work, make sure that it could load any MC
packages after that

The normal minimal dependancy is on Network, and Compression, however if files are available locally it would only be compression, however the current implementation looks on squeaksource for things.

- use a version control for LPF script (put it on SVN somewhere)

In previous versions LPF.st needed to be updated in order to keep current. 
Now that Installer can grab the latest mcz and file in the source.st within, it can get the latest every time and is less in need of updating and explicit version control.

- continue efforts on making LPF become an extremely modular and
self-sufficient piece of software,

be my guest.

I have always maintained that it is the concept that is the important thing, if you can get buy in to the concept then the rest is easy.  I hope you succeed where I have failed.

Keith

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