Hi Phil,
On Sat, Dec 31, 2016 at 10:14 AM, [email protected] <
[email protected]> wrote:
> Isn't there a typo in the first exptession?
>
> Also the list contains a lot of RB things. What purpose do they have in a
> bootstrap image?
>
Yes, that is because the bootstrap image contains the compiler. And the
compiler requires (amongst others) the AST, implemented initially as part
of the refactoring browser, and so it has the RB prefix.
However, the bootstrap does not contain the refactoring browser.
>
> Same for RelationSlot and X11 something.
>
RelationSlot belongs to the class builder package, which is needed to
create classes.
Of course RelationSlot is part of an 'Examples', and as such it could be
packaged separately, but this was not done yet.
Regarding the X11 thingy, this is probably X11Encoding that you're talking
about. This one belongs to the Multilingual-encondings package, and if we
are picky you'll see this package is required because it contains mainly
Unicode, which is required by the Kernel so far to do a lot of stuff. See
for example:
Character>>asLowercase
"If the receiver is uppercase, answer its matching lowercase Character."
^ self characterSet toLowercase: self
Character>>characterSet
^ EncodedCharSet charsetAt: self leadingChar
...
What lead to EncodedCharSet (and the default charset that is Unicode).
> Is there a scope and purpose statement for the bootstrap somewhere?
>
Not writen that I know of. Maybe we should do it. But from many discussions
here in the team I'd define the pharo bootstrap as a pharo environment that
is
- minimal (in the sense that it keeps only stuff required to run)
- clean (in the sense that there is the less dead code and dead
dependencies as possible)
- and is able to grow (in the sense that you can install new code on it).
Think that Pharo is not just the bootstrap. People will not accept a Pharo
without a development environment, without a debugger or a workspace.
These three points are a long term goal I woud say, and particularly the
last point is in big conflict with the first one. You can have an image
that executes code but has no compiler for example.
So making a trade-off but always going towards that goal, what we decided
with Christophe one year and a half ago to:
- select a minimal set of packages that would belong to the bootstrap
image
* To run, you need the Kernel.
* To be able to install new code you need some kind of I/O and some
way to transform the input as classes/methods. Thus we chose to put also
basic command line handlers, files, and the compiler. We discussed about
putting a flavour of Fuel (say Tanker) instead of the compiler, but Tanker
was not stable as it was only experimental and nobody used it for real; the
compiler was much more stable as we use it everyday; and besides, Tanker
was depending on the class builder, so it only allowed us to remove the
compiler but not the class builder.
* To be clean, we started looking at the dependencies of those
packages.
- We finished in a selection of about 53 packages. Remember that Pharo
itself has nowadays around 464 packages...
RPackageOrganizer default packages size "464"
So this was as good as a ~10% of the original image. Good enough to
have a first version.
- And we started working on dependency analyses on them. The following
report made by Christophe lists all the bootstrap packages and their
dependencies, and reports when a new dependency is introduced.
https://ci.inria.fr/pharo/view/6.0-Analysis/job/Pharo-6.0-DependencyAnalysis/Dependencies_HTML_Report/
See what the dependency graph looks of the bootstrap
https://ci.inria.fr/pharo/view/6.0-Analysis/job/Pharo-6.0-DependencyAnalysis/Dependencies_HTML_Report/
and extrapolate to the entire image :).
And that, after we worked a LOT to cut off/separate/untangle/decouple
those 53 packages from the rest, rewrite parts of the system (a big example
of it is the SessionManager).
Now, this is of course not the end. There are still lots of things to do.
- the kernel can be still cleaned up even more
- we could implement some sort of binary serializer specialized for
classes and methods to shrink even more the bootstrap
- the rest of the image has still to be cleaned. Nowadays on top of the
bootstrap Monticello and Metacello are bootstrapped using manual a approach
and afterwards, the rest of the image is loaded by using a Baseline
https://github.com/guillep/pharo-core/tree/66666949ceffbd806ff39188548d65797a1e8314/src/BaselineOfUI.package
That baseline can be enhanced, splitted in smaller baselines. This
require non-bootstrap packages to be revisited, have checked their
dependencies and so on...
So what you see in that list is the result of several decisions and a lot
of work. And the focus was to release something and not die in the process.
Hope that answers the question (I will copy past this and put it into some
wiki btw)
Guille
> Phil
>
> Le 31 déc. 2016 05:47, "Ben Coman" <[email protected]> a écrit :
>
>> So for curiosity...
>>
>> $ $PHARO bootstrap.image eval "Object allSubclasses size"
>> 1677
>>
>> $ $PHARO bootstrap.image eval "Object allSubclasses size"
>> 837
>>
>> $ $PHARO bootstrap.image eval "Object class printHierarchy" >
>> /tmp/60334-bootstrap-hierarchy.txt
>> (see attached)
>>
>> cheers -ben
>>
>>
>> On Sat, Dec 31, 2016 at 4:42 AM, Pavel Krivanek
>> <[email protected]> wrote:
>> > It is better to use smaller bootstrapped image without Monticello but
>> it is
>> > still quite big.
>> >
>> > https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-
>> Step-01-00-Bootstrap/lastSuccessfulBuild/artifact/bootstrap.zip
>> >
>> > -- Pavel
>> >
>> > 2016-12-30 18:13 GMT+01:00 Ben Coman <[email protected]>:
>> >>
>> >> On Fri, Dec 30, 2016 at 7:51 AM, James Ladd <[email protected]>
>> wrote:
>> >> > Hi Pharo People,
>> >> >
>> >> > I have continued work on Redline Smalltalk and I'm wanting to discuss
>> >> > what
>> >> > the absolute minimum
>> >> > set of Classes and method should be included in the Redline Runtime.
>> >> >
>> >> > Would anyone here like to participate in that discussion?
>> >> >
>> >> > - James.
>> >> > Redline Smalltalk <http://redline.st>
>> >>
>> >> Nice to hear you are continuing.
>> >> I'm not very knowledgable on this, but I'll show you how to pull some
>> >> data from the work on producing a minimal image.
>> >>
>> >> 1. From PharoLauncher > Templates > Pharo 6.0(beta)
>> >> download/create an image of build "60334-minimal".
>> >> 2. Right-click on the image and choose [Copy pathname]
>> >> 3. In a shell, change to that directory, and execute the following
>> >> $ ../../VMs/spur/pharo 60334-minimal.image eval "Object
>> allSubclasses
>> >> size"
>> >> ==> 2801
>> >> $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class
>> >> allSubclasses size"
>> >> ==> 1399.
>> >> $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class
>> >> printHierarchy" > /tmp/60334-minimal-class-hierarchy.txt
>> >>
>> >> I've attached the output of that last one.
>> >>
>> >> 4. For comparison, in a standard 60334 image,
>> >> Object allSubclasses size "==>11923".
>> >> Object class allSubclasses size "==>5959".
>> >>
>> >> Now in Pharo 6, the minimal image starts with a standard image and
>> >> strips these things out...
>> >>
>> >> https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Mini
>> mal/ws/output.txt
>> >>
>> >> In Pharo 7, there will be a new build system that it will start with a
>> >> minimal image and build it up to a normal image. So this may provide
>> >> a better way to understand the order that things need to be
>> >> implemented.
>> >>
>> >> cheers -ben
>> >
>> >
>>
>
