[Pharo-dev] PharoMinimal ?

Thierry Goubier thierry.goubier at gmail.com
Sun Oct 8 13:06:01 EDT 2017


Le 08/10/2017 à 18:55, Guillermo Polito a écrit :
> That's still not enough ;)

That's close enough for me.

> That will work when the loaded package has no dependencies. Otherwise, 
> imagine projects A and B, and A depending on B's release. every time you 
> release B you need to release all dependencies...

Sort of. If when loading A, A has a correct reference to a stable B 
release, then that is ok.

However, if B is released before A has the time to prepare a compatible 
version to the latest B, then, yes, that will break, but that also means 
A isn't properly synchronized with B (which is my point about external 
projects having to be synchronized).

Then A may have in its baseline a check on the last B release known to 
be compatible...

> And, if you use a tag or exact committish to get the Baseline you want 
> to install, still that baseline needs to point to the exact 
> tag/committish of it's dependencies.

Agreed. You can still, in Metacello scripting, point to two (or more) 
repositories when loading the baseline (and then Metacello would pick 
the newest one), but: first, I don't know how to do it from inside a 
Baseline (dependencies), and, second, if filetree is used, then we loose 
the ability to tell which one is newest. (*)

> Or! If you know the dependencies of your baseline you can explicitly use 
> a Metacello's lock. I still believe this is an overkill and I'd like to 
> simplify it, but that's what we have right now.

As I said above, it seems possible if you create a level of indirection 
when fetching the baseline of a dependency.

And saying that, I know how to do it. Within the BaselineOf itself.

Thierry

> On Sun, Oct 8, 2017 at 6:47 PM, Thierry Goubier 
> <thierry.goubier at gmail.com <mailto:thierry.goubier at 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
>         <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 at gmail.com <mailto:thierry.goubier at gmail.com>
>         <mailto:thierry.goubier at gmail.com
>         <mailto:thierry.goubier at 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 at stfx.eu <mailto:sven at stfx.eu>
>                  <mailto:sven at stfx.eu <mailto:sven at stfx.eu>>
>         <mailto:sven at stfx.eu <mailto:sven at stfx.eu> <mailto:sven at stfx.eu
>         <mailto:sven at 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>
>                  <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>
>                  <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>>
>                      
>         <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>>
>                      
>         <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>>
>                  <http://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/>>
>                       <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 <tel:%2B33%2006%2052%2070%2066%2013>
> 
> 
> 
> 
> 
> 
> -- 
> 
> 	
> 
> 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
> 





More information about the Pharo-dev mailing list