On Mon, Jan 23, 2017 at 3:55 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:

I do not think that to have the package "Kernel" as the smallest system subset is the good way to go. The minimal system should be a set of well-structured packages so it still makes sense to have packages like Collections-* where some of them are supposed to be mandatory and others optional.

So: 1) not in that form

2) Kernel package deserves better modularization but in that case names

will be like Kernel-*

Ok. The problem with the names Collections-* and Kernel-* is that pkg-* currently means a different package tag inside a package and not a different package, while the dependency analyser tool analyse dependencies on packages not package tags. Right now it's difficult for me to keep the dependencies right for my package as the dependency analyser tool shows me a dependency on the whole Collection and Kernel packages while I need to enforce a dependency to a subset of these 2 packages. Now that I read my mail again I think the problem is not with the packages but with the dependency analyser tool. I should define a set of classes and enforce my package to depend only on those classes as the current packages are too wide and they won't be split in a way I need in the near future. Cheers

But of course we should discuss the best approach.

Cheers, -- Pavel

2017-01-23 15:36 GMT+01:00 Clément Bera <bera.clement@gmail.com>:

...

Hi everyone,

As I am working on an optimising JIT compiler for the Cog VM written in Smalltalk and partly running in the Smalltalk runtime, I am very careful about dependencies. I would like to limit the dependencies of the optimiser to the Kernel.

The main problem I have is that there are no collections in the Pharo Kernel except MethodDictionary and DependentsArray. The optimiser depends on Array, ByteArray, OrderedCollection, Set and Dictionary which are not part of the Kernel.

The second problem is that there are lots of things in the Kernel that the optimiser do not depend on even though everything is in the Kernel package, for example, the optimiser does not depend on anything related to Time/Chronology, on Numbers other than SmallIntegers or Protocol logic.

This leads to questions. I know that with the bootstrap incoming, some people have answers to these questions, but I would like to the conversation happening on the mailing list so everyone can contribute.

Question 1) Is there any plan to make a 'Kernel-Collection' package, which includes Array, ByteArray, OrderedCollection, Set and Dictionary, but not the rest of the collections ?

Question 2) Is there any plan to split the Kernel (or maybe the Kernel and all its dependencies ?) into smaller pieces, for example 'KernelCore', which includes the existing Kernel *but* other Numbers than SmallIntegers, Protocol logic and Time Chronology, which could be moved to 'KernelExtended' or something like that ?

I understand that those problems are not easy, but I would like to know if there is a generic plan so I can correctly decide on what dependencies I can have or not.

Thanks, cheers,

Hi, First, I'll make a not that is implicit in the conversation: the loading/deployment granularity in Pharo is the package, not the class. And as such, a dependency to a class will require the entire package, because we cannot load half a package. Okok, "yes, we can", but this is not the default behaviour of the system when we work with our current tools (monticello, metacello, iceberg, the dependency analyzer...). Now to extend a bit more on the answers already given: 1 - We already discussed about doing a split like that. Maybe not Kernel-Collections, but Collections-Kernel. Nowadays the collections package is not modularised in terms of usage, but in terms of implementation (ordered, unordered...). And here we see where the "meaningfulness" of a package/package name clashes with its deployment, because of a big deployment granularity. 2 - YES. I want to split all the time related stuff from the kernel. And make them System-Time or whatever. The other thing is that little tasks like these "clean this package", "split this other one", "fix the dependencies of this one" we have hundreds. And we chose the ones that will provide more impact in the short term with the little time we have to work on them... Clement, I think you should be able to use the dependency analyser to extract the exact list of classes your package depends on, and then validate that in a lint rule. Check with Christophe, he is the dependency analyser master. Guille On Mon, Jan 23, 2017 at 6:51 PM, Ben Coman <btc@openinworld.com> wrote:

On Tue, Jan 24, 2017 at 12:14 AM, Clément Bera <bera.clement@gmail.com> wrote:

...

On Mon, Jan 23, 2017 at 3:55 PM, Pavel Krivanek <pavel.krivanek@gmail.com

...

wrote:

...

I do not think that to have the package "Kernel" as the smallest system subset is the good way to go. The minimal system should be a set of well-structured packages so it still makes sense to have packages like Collections-* where some of them are supposed to be mandatory and others optional.

So: 1) not in that form

2) Kernel package deserves better modularization but in that case names

...

will be like Kernel-*

Ok.

The problem with the names Collections-* and Kernel-* is that pkg-* currently means a different package tag inside a package and not a different package, while the dependency analyser tool analyse dependencies on packages not package tags.

Right now it's difficult for me to keep the dependencies right for my package as the dependency analyser tool shows me a dependency on the whole Collection and Kernel packages while I need to enforce a dependency to a subset of these 2 packages.

Now that I read my mail again I think the problem is not with the packages but with the dependency analyser tool. I should define a set of classes and enforce my package to depend only on those classes as the current packages are too wide and they won't be split in a way I need in the near future.

Do you mean having a script that temporarily organises your subset of classes into MyProvidersPackage to you use that with Dependency Analyser? Or do you have some other method of feeding DA a subset of classes?

cheers -ben

...

Cheers

...

But of course we should discuss the best approach.

Cheers, -- Pavel

2017-01-23 15:36 GMT+01:00 Clément Bera <bera.clement@gmail.com>:

...

Hi everyone,

As I am working on an optimising JIT compiler for the Cog VM written in Smalltalk and partly running in the Smalltalk runtime, I am very careful about dependencies. I would like to limit the dependencies of the optimiser to the Kernel.

The main problem I have is that there are no collections in the Pharo Kernel except MethodDictionary and DependentsArray. The optimiser depends on Array, ByteArray, OrderedCollection, Set and Dictionary which are not part of the Kernel.

The second problem is that there are lots of things in the Kernel that the optimiser do not depend on even though everything is in the Kernel package, for example, the optimiser does not depend on anything related to Time/Chronology, on Numbers other than SmallIntegers or Protocol logic.

This leads to questions. I know that with the bootstrap incoming, some people have answers to these questions, but I would like to the conversation happening on the mailing list so everyone can contribute.

Question 1) Is there any plan to make a 'Kernel-Collection' package, which includes Array, ByteArray, OrderedCollection, Set and Dictionary, but not the rest of the collections ?

Question 2) Is there any plan to split the Kernel (or maybe the Kernel and all its dependencies ?) into smaller pieces, for example 'KernelCore', which includes the existing Kernel *but* other Numbers than SmallIntegers, Protocol logic and Time Chronology, which could be moved to 'KernelExtended' or something like that ?

I understand that those problems are not easy, but I would like to know if there is a generic plan so I can correctly decide on what dependencies I can have or not.

Thanks, cheers,