Ben Coman wrote > On Sat, Jun 6, 2015 at 5:26 PM, Guillermo Polito > <
> guillermopolito@ > > 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? > > 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. > > 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. One of the things I really like about ENVY (as found in VA Smalltalk) is that packages are formally modelled and are distinct from method categories. (Another is that a method can have multiple categories.) And by formally modelling packages, one can easily include proper dependency relationships and more easily detect references to behaviours outside a packages prerequisites chain. I realize that is a huge departure from current Squeak and Pharo practice. But, I hope it's one that will get consideration. (Given all the other first class modelling you've been adding to Pharo, I think this would be consistent with the current philosophy!) > 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. > > P.S. I know I do a lot of wondering, and of course divergent thought > is easier than concrete answers. > cheers -ben > > >> >> Then the bootstrap will include essential packages at the beginning and >> non-essential will be just loaded on top. >> >> The rationale is: the smaller the kernel, the fastest the bootstrap, and >> with it the feedback loop we have. >> >> That's why I was working on the File abstractions, and splitting some >> other >> kernel package. >> >> El vie., 5 de jun. de 2015 a la(s) 7:35 p. m., stepharo < > stepharo@ > > >> escribió: >>> >>> Yes sven but with guille we are working on a really small kernel. So we >>> can duplicate just the classes we need but I would prefer not >>> but we can do it. The size is important for us because it takes time to >>> bootstrap. >>> >>> Stef >>> >>> Le 5/6/15 19:06, Sven Van Caekenberghe a écrit : >>> >> On 05 Jun 2015, at 18:43, Guillermo Polito < > guillermopolito@ > > >>> >> wrote: >>> >> >>> >> The only encoder that makes a bit of noise to me is the ZnByteEncoder >>> >> that contains a lot of mapping tables for mostly unused encodings >>> > 67 encoding specifications, each a 128 array. The method constant is >>> > shared when used. >>> > In the beginning there were only a couple, one day I added many more, >>> > some people need them. >>> > For me, the cost is reasonable. >>> > >>> >> (plus methods with metadata to recreate them)... >>> > That is just two method (which is pretty cool, I love spec based >>> > programming). >>> > >>> >> El vie., 5 de jun. de 2015 a la(s) 6:30 p. m., Sven Van Caekenberghe >>> >> < > sven@ > > escribió: >>> >> >>> >>> On 05 Jun 2015, at 18:20, stepharo < > stepharo@ > > wrote: >>> >>> >>> >>> Sven >>> >>> >>> >>> we were talking about splitting your package into two parts :) >>> >>> Would you be ok to get the basic encoders in a separate package? >>> >> Zinc-Character-Encoding is already a separate package, it depends on >>> >> nothing. >>> >> Zinc-Resource-Meta is next up (containing URL and Mime-Type). >>> >> Both are completely independent of any HTTP stuff. >>> >> All this is by design. >>> >> >>> >> You probably mean that you want a separate config ? Right now they >>> are >>> >> just a groups. >>> >> >>> >>> We were also thinking that NullEncoder could be called AsciiEncoder? >>> >> Maybe, maybe not, let me think about that a bit. >>> >> >>> >>> Stef >>> >>> >>> >>>>> On 05 Jun 2015, at 18:09, Damien Cassou < > damien.cassou@ > > >>> >>>>> wrote: >>> >>>>> >>> >>>>> >>> >>>>> Guillermo Polito < > guillermopolito@ > > writes: >>> >>>>> >>> >>>>>> Well, I made a cleaner implementation at the side with >>> >>>>>> >>> >>>>>> - a simple File object that is a sequential File as we all know >>> >>>>>> - a binary File stream on top of it that is composable with Zn >>> >>>>>> encoders and >>> >>>>>> other decorators >>> >>>>>> - a new interface to access Stdio streams >>> >>>>> that's really good news Guillermo. >>> >>>> Yes it is (need time to look at this in detail) >>> >>>> >>> >>>>> Is it ok to make File reading depend >>> >>>>> on Zinc? This sounds strange. Wouldn't that make bootstrapping >>> >>>>> harder? >>> >>>> It does not depend on the HTTP part, but on the Encoding part below >>> >>>> it, so that should be OK. >>> >>>> >>> >>>>> -- >>> >>>>> Damien Cassou >>> >>>>> http://damiencassou.seasidehosting.st >>> >>>>> >>> >>>>> "Success is the ability to go from one failure to another without >>> >>>>> losing enthusiasm." --Winston Churchill >>> >>>>> >>> >>>> >>> >>> >>> >> >>> > >>> > >>> >>> >> -- View this message in context: http://forum.world.st/Refactoring-File-Package-tp4830625p4830987.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
