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.goub...@gmail.com <mailto:thierry.goub...@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.goub...@gmail.com <mailto:thierry.goub...@gmail.com>
<mailto:thierry.goub...@gmail.com
<mailto:thierry.goub...@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
<s...@stfx.eu <mailto:s...@stfx.eu>
<mailto:s...@stfx.eu <mailto:s...@stfx.eu>>
<mailto:s...@stfx.eu <mailto:s...@stfx.eu> <mailto:s...@stfx.eu
<mailto:s...@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