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.
we have the same with the dependency browser. Christophe is adding some
logic to
get the messages sent but not implemented in a package and its dependents.
We are also adding dependencies to the packaege themselves.
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!)
So we are slowly adding metadata to package manifest.
Now packages are not added the Smalltalk namespace and I do not know if
this would be good to have.
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.
