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?

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.

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 <steph...@free.fr>
> 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 <guillermopol...@gmail.com>
>> >> 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
>> >> <s...@stfx.eu> escribió:
>> >>
>> >>> On 05 Jun 2015, at 18:20, stepharo <steph...@free.fr> 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.cas...@inria.fr>
>> >>>>> wrote:
>> >>>>>
>> >>>>>
>> >>>>> Guillermo Polito <guillermopol...@gmail.com> 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
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>> >
>>
>>
>

Reply via email to