On Mon, Jan 23, 2017 at 3:55 PM, Pavel Krivanek <[email protected]> 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 <[email protected]>: > >> 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, >> > >
