On Tue, Jan 24, 2017 at 12:14 AM, Clément Bera <[email protected]> wrote:
> > > 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. > 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 <[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, >>> >> >> >
