New step in Pharo modularity
Locked
New step in Pharo modularity
 
|
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 |
Re: New step in Pharo modularity
|
|
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 |
Re: New step in Pharo modularity
|
|
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 |
Re: New step in Pharo modularity
|
|
On Mon, Apr 5, 2010 at 3:27 PM, Alexandre Bergel <[hidden email]> wrote:
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 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, _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |