On Sun, Oct 8, 2017 at 6:47 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Hi Guille,

Le 08/10/2017 �� 18:24, Guillermo Polito a ��crit��:

For a really high-level explanation, check the slides in here:

https://www.slideshare.net/GuillePolito1/understanding-the-pharo-dev-process-79632181

Thanks for the pointers. I tried to do something in the Pharo4 days (I still have probably somewhere a start of baselines and package to add to a minimal pharo4 image, then the external project integration changed and this approach would have failed...)

Now, as Pavel says, minimal is an image with metacello (+ its dependencies of course).

This means that you could try to install packages on top of it using baselines.

Cool.

Still, lot of work to do in that front, mainly
��- modularisation of the minimal-image packages, so we can build even smaller images
��- modularisation and baselines for all full-image packages, so we can build incremental images on a per-user flavour

This is really interesting.

This means of course
��- cleaning/sorting initializations
��- refactoring packages
��- Uncovering hidden and runtime dependencies
��- making some analyses on how space is taken (most is methods, tons in kernel and collections ;))

What is not so clear yet from the top of my head: if we distribute minimal images, how can we distribute the pharo libraries that you can load on top of them easily. So far, people using pharo minimal are aware that they are using an alpha version. That means that if they want to load on top of it, let's say, Morphic, they will need to do something like

Metacello��new
baseline: 'Morphic';
repository: 'github://pharo-project/pharo:development/src';
load

But that means that we'll be loading the so called 'bleeding-edge' of it all the time, and that version may not correspond with the image they are using.

This makes me think we have at some point to revisit the release process so we can have releases internal of libraries such as morphic, athens, fuel, etc, more often.

I think I can suggest a solution. When building an image on the command line (as us Makefile users are keen to do), it is easy to customize the additional packages/baselines you load based on some internal state of
the image being built.

So, for example, if you tag the minimal image when built with, say v70123, then one can write on the command line:

pharo/pharo pharo/Pharo.image --no-default-preferences eval --save Metacello new baseline: \'Morphic\'\; repository: \'github://pharo-project/pharo:\'\, SystemVersion current buildNumber printString\, \'/src\'\; load

Et hop, voil��: you get the right Morphic for the minimal image with a minimum amount of distortion.

If not, then it could be enough to have the short commit ID of the pharo repository when the minimal image was built: it is enough to get a github:// url to work.

Well, if you keep naming your images like that:

Pharo7.0-metacello-32bit-d13eed2.image

Then we could even do it this way in the image building makefile (and you don't have anything to do)(*).

I'll have a try at it.

Thierry

(*) External projects would have to sort it out, still. But, IMHO, it is a duty of an external project to be in sync if it wants to stay external...

On Sun, Oct 8, 2017 at 4:34 PM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:

�� Hi Pavel,

�� I'd probably see some interest in building the
�� GitFileTree-MergeDriver with it. It only requires Monticello.

�� Thierry

�� Le 08/10/2017 �� 12:41, Pavel Krivanek a ��crit��:

�� Hi Sven,

�� 2017-10-07 16:18 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu
�� <mailto:sven@stfx.eu> <mailto:sven@stfx.eu <mailto:sven@stfx.eu>>>:

�� Hi,

�� What is the story around PharoMinimal and related images ?

�� Is there a writeup somewhere with instructions ?

�� Right now the minimal (Metacello) image based on Pharo 7 is used
�� only as intermediate step in building of the full Pharo and the
�� only real (successful) attempt to use it for something else is
�� PharoLambda (https://gitlab.com/macta/PharoLambda
�� <https://gitlab.com/macta/PharoLambda>).

�� In general it can be used for building of own (server)
�� applications. E.g. this way you can install and run Teapot on it:

�� ./pharo Pharo7.0-metacello-32bit-d13eed2.image config
�� http://smalltalkhub.com/mc/zeroflag/Teapot/main
�� <http://smalltalkhub.com/mc/zeroflag/Teapot/main>
�� ConfigurationOfTeapot --install=stable
�� ./pharo Pharo7.0-metacello-32bit-d13eed2.image eval --no-quit
�� "Teapot on GET: '/welcome' -> 'Hello World'; start."

�� You can load baselines from the Git repositories too but we
�� currently do not have any command line handler for it so you
�� need to do it using "eval" command or *.st flile. Something like
�� this:

�� Metacello new
�� baseline: 'Seaside3';
�� repository: 'github://SeasideSt/Seaside:master/repository';
�� load

�� To make it more usable we probably should extend it with SUnit
�� and Fuel. If you want to extend it with some packages from
�� vanilla Pharo, you should load them using FileTree from your
�� local Pharo repository clone.

�� Gofer it
�� url: 'filetree:///path-to-my-pharo-repository-clone/pharo/src';
�� package: 'Multilingual-OtherLanguages';
�� package: 'Multilingual-TextConverterOtherLanguages';
�� load.

�� It still needs some care. E.g. some classes from Zinc are not
�� properly initialized (I know about DigitalSignatureAlgorithm
�� MD5NonPrimitive RxMatcher RxParser RxsPredicate SHA1
�� ZnByteEncoder ZnConstants ZnMimeType ZnNetworkingUtils ZnServer
�� ZnSingleThreadedServer TextConstants TextAction TextStyle).

�� I tried to load Seaside into it today (from the example above)
�� and it failed (some strange error probalby related to Unicode
�� processing). But we will fix it. If you will tell me what
�� exactly you need we can make it work together as in case of
�� PharoLambda.

�� I see that we get **FANTASTIC** startup speed with it:

�� $ cat /etc/issue
�� Ubuntu 16.04.3 LTS

�� $ ./pharo --version
�� 5.0-201708271955�� Sun Aug 27 20:09:20 UTC 2017 gcc 4.6.3
�� [Production
�� Spur VM]
�� CoInterpreter VMMaker.oscog-eem.2265 uuid:
�� 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017
�� StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid:
�� 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017
�� VM: 201708271955
�� https://github.com/OpenSmalltalk/opensmalltalk-vm.git
�� <https://github.com/OpenSmalltalk/opensmalltalk-vm.git>
�� <https://github.com/OpenSmalltalk/opensmalltalk-vm.git
�� <https://github.com/OpenSmalltalk/opensmalltalk-vm.git>> $ Date: Sun
�� Aug 27 21:55:26 2017 +0200 $
�� Plugins: 201708271955
�� https://github.com/OpenSmalltalk/opensmalltalk-vm.git
�� <https://github.com/OpenSmalltalk/opensmalltalk-vm.git>
�� <https://github.com/OpenSmalltalk/opensmalltalk-vm.git
�� <https://github.com/OpenSmalltalk/opensmalltalk-vm.git>> $
�� Linux testing-gce-ebf45dd8-6a4c-43a5-abd0-e5d8673d05a4
�� 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24
�� 16:47:06 UTC
�� 2017 i686 i686 i386 GNU/Linux
�� plugin path:
�� /home/audio359/pharo7/pharo-vm/lib/pharo/5.0-201708271955
�� [default:
�� /home/audio359/pharo7/pharo-vm/lib/pharo/5.0-201708271955/]

�� $ curl get.pharo.org/70-minimal
�� <http://get.pharo.org/70-minimal>
�� <http://get.pharo.org/70-minimal

�� <http://get.pharo.org/70-minimal>> | bash

�� ...

�� $ ./pharo Pharo.image printVersion
�� [version] 'Pharo7.0'
�� 'Pharo-7.0+alpha.build.172.sha.d13eed2f80fe19f29fd85ede8c4809d6a6986d4f
�� (32 Bit)'

�� $ time ./pharo Pharo.image eval '5 factorial'
�� 120
�� real�� 0m0.083s
�� user�� 0m0.034s
�� sys�� 0m0.042s

�� That is less than 1/10 of a second on a simple server ! Wow.

�� Loading new code in that image seem hard though.

�� I see that in http://files.pharo.org/image/70/
�� <http://files.pharo.org/image/70/>
�� <http://files.pharo.org/image/70/
�� <http://files.pharo.org/image/70/>> there are Pharomonticello &
�� Pharometacello variants.

�� Any pointers on usage/meaning ?

�� Monticello is bootstrapped Pharo image with Monticello loaded.
�� This image then loads Metacello and the generated image is the
�� image that we call "minimal". It is minimal in sense minimal for
�� common usage.

�� During Pharo building process we generate:
�� - bootstrapped image
�� - image with Opal that is loaded as binary packages using Hermes
�� - Monticello with only local repositories support
�� - Monticello with network and remote repositories support
�� - Metacello
�� - full Pharo IDE (which is loaded as sequence of several
�� standalone baselines)

�� Cheers,
�� -- Pavel

�� Thx,

�� Sven

--

��

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - _http://www.cnrs.fr_

*Web:* _http://guillep.github.io_

*Phone: *+33 06 52 70 66 13

��	Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: +33 06 52 70 66 13