[Pharo-dev] [IMPORTANT] Following changes in the bootstrapping process

Eliot Miranda eliot.miranda at gmail.com
Tue Aug 1 13:59:20 EDT 2017


Hi Guille,

> On Aug 1, 2017, at 4:29 AM, Guillermo Polito <guillermopolito at gmail.com> wrote:
> 
> 
> 
>> On Tue, Aug 1, 2017 at 12:57 PM, philippe.back at highoctane.be <philippe.back at gmail.com> wrote:
>> Massive.
>> 
>> What is in the super small image?
>> Is Hermes going to be a generic binary content loader?
> 
> There is still work to do in this front. 
>  - Hermes only works for 32bits format. We should adapt it to 64 bits (immediate floats and so on...)
>  - There is no format validation. We should add one for safety.

Will Hermes be able to save on 32-bits and load on 64-bits and vice verse?

Does Hermes use the Parcels/Fuel architecture of saving nodes, grouped by class, followed by the arcs?

If yes to both of these, are you willing to keep it in Monticello and collaborate with the Squeak & Cuis communities in developing Hermes?
>  
>> Phil
>> 
>>> On Aug 1, 2017 12:36, "Stephane Ducasse" <stepharo.self at gmail.com> wrote:
>>> Hi Pavel
>>> 
>>> This is super excellent! IMPRESSIVE. An image without the compiler and
>>> a reloadable compiler.
>>> Super cool.
>>> 
>>> Stef
>>> 
>>> 
>>> On Tue, Aug 1, 2017 at 11:57 AM, Pavel Krivanek
>>> <pavel.krivanek at gmail.com> wrote:
>>> > Hello,
>>> >
>>> > we are checking a huge pull request #177
>>> > (https://github.com/pharo-project/pharo/pull/177) that will change some
>>> > basics of the bootstrap process:
>>> >
>>> > Now we will bootstrap a smaller image that will not include compiler/parser.
>>> > Compiler and related packages are exported and loaded using a binary
>>> > exporter named Hermes.
>>> > The compiler is then used to load FileSystem and Monticello. The rest of the
>>> > bootstrap process will be the same as before.
>>> > As the result we will have faster bootstrap and better system modularization
>>> > and possibilities.
>>> >
>>> > It required some modularization efforts:
>>> >
>>> > - simplified initialization scripts
>>> > - Use Zinc converters and encoders instead of FilePathEncoder and old
>>> > TextConverter
>>> > - Use Stdio instead of FileStream
>>> > - Using File instead of FileSystem
>>> > - Deprecated FileStream & childs (Moved to Deprecated70)
>>> > - Extracted Path classes to their on package: FileSystem-Path
>>> > - Moved OpalEncoders to their own package. They are required by the runtime
>>> > (not only for compilation)
>>> > - Introduced AsciiCharset in the kernel to answer to #isLetter #isUppercase
>>> > and so on without requiring full Unicode tables from the beginning
>>> > - Cleaning up a bit the full exception logging infrastructure (streams,
>>> > transcript, files, stack printing...)
>>> > - Split Ring methods required for system navigation to the Ring-Navigation
>>> > package
>>> > - Remove usages of #translated in the kernel
>>> > - Refactored the bootstrapping classes to remove duplications
>>> > - Cleaning up dependencies in CompiledMethod>>printOn:
>>> > - fix path printing
>>> >
>>> > We need to merge these changes at once and of course it can cause some
>>> > conflicts with the existing pull requests or external code. Anyway, we need
>>> > to merge it as soon as possible.
>>> >
>>> > So please, try to look at the PR and test the resultant image [1] to avoid
>>> > some major problems.
>>> >
>>> > [1]
>>> > https://ci.inria.fr/pharo/view/7.0/job/70-PR-Check-Load/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-9c0691d.zip
>>> >
>>> > Cheers,
>>> > -- Pavel
>>> >
>>> 
> 
> -- 
>    
> Guille Polito
> 
> Research Engineer
> French National Center for Scientific Research - http://www.cnrs.fr
> 
> 
> Web: http://guillep.github.io
> Phone: +33 06 52 70 66 13
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20170801/06888304/attachment.html>


More information about the Pharo-dev mailing list