On Mon, Jun 8, 2015 at 4:08 PM, Guillermo Polito <guillermopolito@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 <btc@openinworld.com> escribió:
On Sat, Jun 6, 2015 at 5:26 PM, Guillermo Polito <guillermopolito@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