New step in Pharo modularity

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

New step in Pharo modularity

Mariano Martinez Peck
Stef, please correct me if I wrote something incorrect :)

Hi folks. It is since a couple of months that we have been discussing with Stef about the current Pharo architecture and the different kind of images we have. What we want to achieve, is to have a really small kernel and provide Metacello configurations so that people can easily load the rest of the stuff. Similar to what we are already doing with PharoCore and PharoDev. However, this still have limitations:

1) There are packages that should NOT be part of the core, but they are not also dev tools. For example, ObjectTracer, ObjectViewer, Morph examples, Sound, ImageSegment (?) etc. So...where do we put them ?

2) Most of the Pharo external packages that are loaded in a Dev image, are maintained by their own developers, not necessary "Pharo developers".

So, we want to define "something" that Pharo developers should maintain, but that are not part of the core, neither a dev tool. For example, suppose that we want to remove some messages, classes or whatever, when we look senders or references, we should do it now not only in the core, but also in this new image. This is because now Pharo developers, will take care also about this. We don't have yet a clear name for this image. Do you have?

We created a new repository called PharoNonCorePackages in squeaksource, and there we put all the packages that are part of this new concept. In addition, we created a Metacello configuration for that. With this, Pharo developers will be able to easily load that configuration in a PharoCore image. The name of such package is ConfigurationOfPharoCore, but I am not sure I like the name. Do you have a better one ?

Of course, the Dev image will also have this configuration as reference, it means, the dev image will also have this stuff.

We think this will let us have a smaller kernel, but still maintaining non core stuff in separate packages and easily loadable. It will also lower the "fear" when making a package external.

The last thought was how we can integrate Metacello to manage updates in the system update. This is still green, but would be cool to a future. The idea is to migrate the ScriptLoader stuff, and instead, releasing metacello versions. Then, the system update should be just to load the last metacello version.

So...what do you think ?

Cheers



_______________________________________________
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: New step in Pharo modularity

Michael Roberts-2
On Monday, April 5, 2010, Mariano Martinez Peck <[hidden email]> wrote:

> Stef, please correct me if I wrote something incorrect :)
>
> Hi folks. It is since a couple of months that we have been discussing with Stef about the current Pharo architecture and the different kind of images we have. What we want to achieve, is to have a really small kernel and provide Metacello configurations so that people can easily load the rest of the stuff. Similar to what we are already doing with PharoCore and PharoDev. However, this still have limitations:
>
> 1) There are packages that should NOT be part of the core, but they are not also dev tools. For example, ObjectTracer, ObjectViewer, Morph examples, Sound, ImageSegment (?) etc. So...where do we put them ?
>
> 2) Most of the Pharo external packages that are loaded in a Dev image, are maintained by their own developers, not necessary "Pharo developers".
>
> So, we want to define "something" that Pharo developers should maintain, but that are not part of the core, neither a dev tool. For example, suppose that we want to remove some messages, classes or whatever, when we look senders or references, we should do it now not only in the core, but also in this new image. This is because now Pharo developers, will take care also about this. We don't have yet a clear name for this image. Do you have?
>
> We created a new repository called PharoNonCorePackages in squeaksource,

Why not call it PharoExtras ?



> The last thought was how we can integrate Metacello to manage updates in the system update. This is still green, but would be cool to a future. The idea is to migrate the ScriptLoader stuff, and instead, releasing metacello versions. Then, the system update should be just to load the last metacello version.
>
> So...what do you think ?
>

I would like to see a metacello version for the core. It would make it
easier to review changes  before they are pushed into the update
stream.
Cheers mike

_______________________________________________
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: New step in Pharo modularity

Alexandre Bergel
In reply to this post by Mariano Martinez Peck
> 1) There are packages that should NOT be part of the core, but they  
> are not also dev tools. For example, ObjectTracer, ObjectViewer,  
> Morph examples, Sound, ImageSegment (?) etc. So...where do we put  
> them ?

I would imagine to have each package in a dedicated SqueakSource  
repository, pretty much the same way we have OB, RB, NewInspector.
 From what you wrote, I understand that you wish to create an  
intermediary layer, PharoNonCorePackages
In that case:
Pharo = PharoVeryCore + PharoNonCorePackages + PharoDev
Is this what you intend ? Ideally, I do not see a valid reason for  
PharoNonCorePackages to be: each package can happily live in its own  
SS rep. Moreover, this could easily create confusion. But for  
practical reason, it could make your life easier.

Cheers,
Alexandre


--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
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: New step in Pharo modularity

Mariano Martinez Peck


On Mon, Apr 5, 2010 at 3:27 PM, Alexandre Bergel <[hidden email]> wrote:
1) There are packages that should NOT be part of the core, but they are not also dev tools. For example, ObjectTracer, ObjectViewer, Morph examples, Sound, ImageSegment (?) etc. So...where do we put them ?

I would imagine to have each package in a dedicated SqueakSource repository, pretty much the same way we have OB, RB, NewInspector.

Yes, actually, the repository was alrady created in SqueakSource under the name of PharoNonCorePackages.
 
From what you wrote, I understand that you wish to create an intermediary layer, PharoNonCorePackages
In that case:
Pharo = PharoVeryCore + PharoNonCorePackages + PharoDev
Is this what you intend ?

Exactly.
 
Ideally, I do not see a valid reason for PharoNonCorePackages to be: each package can happily live in its own SS rep.

Yes, they can also live in their own repository. But I think it is easier to have the all together in the same repository. Mostly because I don't think there will be too much packages for the same repository. I mean, all those packages are little and seem not to be very related to each other...so it is not like a big project where you need a repository because you have a lot of packages for the same project. In this case we will probably have one package.
 
Moreover, this could easily create confusion.

Why ?  What is the difference with the Pharo repository for example ?
 
But for practical reason, it could make your life easier.


yes!
 
Cheers,
Alexandre


--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.







_______________________________________________
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