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,