On Mon, Jun 8, 2015 at 4:08 PM, Guillermo Polito <guillermopol...@gmail.com> wrote: > Hi Ben! > > I answer between lines. If the discussion continues maybe we should move to > another thread also ^^.
I don't have much to add, but a new thread none the less. > El sáb., 6 de jun. de 2015 a la(s) 12:39 p. m., Ben Coman > <b...@openinworld.com> escribió: >> >> On Sat, Jun 6, 2015 at 5:26 PM, Guillermo Polito >> <guillermopol...@gmail.com> wrote: >> > Actually we just want to have a kind of split in: >> > >> > - essential >> > - non-essential >> >> I guess you have scripts outside the image to shrink the image and >> then bootstrap it. However these are not necessarily visible to >> >> everyone and I am wondering once the bootstrap goal is achieved >> you will handle the entropy of ongoing development by many others >> accidentally introducing dependencies that breaks the bootstrap? > > > Well no. I try to not do that. Currently what I have working is: > > - a metacello configuration describing the packages+versions that > will be part of the built kernel > > - a simple script that will create the initial objects of an image before > class creation (e.g., create Smalltalk, initialize the symbol table, etc). I > want this guy to be the smallest as possible to avoid what you > describe above Ahhh. That is real nice to know. Very cool. > - a script to initialize the image after class creation. e.g., create the > first process, and execute some class side initialize. > > Then again, the ad-hoc bootstrap scripts try to be minimal to avoid > being impacted. Of course they could be impacted by changes of > APIs, but I think it is still controllable in the size of the scripts :). > And then, that is why I try to push as many "modularity" concerns to > Pharo itself, to keep these scripts small. > >> >> >> Also what I have seen is classes being moved out of their current >> packaging (sorry I forget the details, but I think it was moved out of >> System) into a new top-level package, which I think loses something >> in structure and might pollute the top-level packages. > > > Yes, mea culpa there. Some times when extracting classes from one > package I didn't put the new package under the System-* or > whatever top level package. > > However, I believe also that the agreement on what are the top-level > packages is kind of implicit and obscure to me. I remember some > discussions in the list with the Alt browser from Thierry using the idea > of top level packages, and others talking about the navigation of the > system. I check the latest Pharo Image and I found: > - AST (should be system?) > - Announcements (should be system?) > - Collections (should be system?) > - Files (should be system?) > - Networking (should be system?) > ... Also we should consider whether its possible/desirable for packages AsmJit, Athens, ConfigurationXxxx, Filesystem, Glamour, Graphics, etc to have just one top-level entry each. > And then if we check what is inside the System top-level package > today I'd say it is a sack full of random things, with no evident criteria. > So maybe we should discuss and agree on how to name packages > and top-level packages! Probably a bit hard to do across a mail list. Maybe an initial stab at this could be done during a sprint? > >> >> So considering the recent discussion of package tags, I wonder if >> somehow we could have a "Bootstrap" tag and realtime critics that >> complain if Bootstrap-tagged-class references any >> non-Bootstrap-tagged-class. There might even be several levels of >> Bootstrap tags. This would improve ongoing visibility of the >> bootstrap structure and help the rest of us to not shoot it in the >> foot. >> >> I wonder also if tags might also be extended to method protocols, so >> you can have a method with the "accessors" tag and also the >> "bootstrap" tag, so that even a Bootstrap-tagged-class can be further >> minimised by the methods it needs during bootstrap. Otherwise I >> guess to minimise the methods in a Bootstrap-tagged-class, later >> extension by another package could not add methods to the >> "accessors" protocol. > > > That would be amazing if I could add meta-data to packages to only > install specific classes. Because we could keep a coarser granularity > of packages while keeping the bootstrap small. > > However, the problem is that you cannot predict what > classes/methods the bootstrap will use. Maybe at certain points of the bootstrap you add the pragma <bootstrap> to all methods currently in the image. This would become a form of documentation, but also perhaps for the next bootstrap build, you scan for the <bootstrap> methods to install into the bootstrap image, and the classes get installed merely as a consequence of being a dependency to allow <bootstrap> methods to be installed. cheers -ben > So far, I'm using the class > builder to build classes in the bootstrap. In such way, I ensure that > all classes that I create will honor the same invariants as a normal > class and I don't have to duplicate the creation code :). > > That means that we can change the internals of the class builder as > long as we don't change the API + preconditions and the bootstrap > will continue working. > > Guille
