March 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Stephane Ducasse

Dale no private emails please. stef On Mon, Mar 5, 2018 at 6:57 PM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > Cyril, > > For development I tend to use Metacello locking instead of hard-wired > dependencies in the BaselineOf and that works very well --- it completely > avoids the need to edit a baseline for development purposes and this > approach works really well for me ... perhaps we can discuss this in more > detail in a separate thread or even private email? This all seems to be more > complicated for you guys than has been my experience and of course you guys > _appear_ to be completely ignoring the Metacello locking feature so I'm > curious why ... > > Dale > > > On 03/05/2018 08:02 AM, Cyril Ferlicot wrote: > > > On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: >> >> >> I still do not understand... Also I do not understand your usage of the >> term "the merge". Can somebody give a **concrete** scenario? >> > I'll try > For example the project MaterialDesignLite have two branches that are always > here: > - master > - development > Each commit on master is a stable release and end up with a tag as "v1.2.2". > Since it's stable, BaselineOfMaterialDesignLite should depend only on fixed > version of the dependencies. For example it should depend on > MaterialDesignColor "v1.0.0". > On the branch dev, we want to get the patches and possibly the minor > versions of the dependencies automatically. In the baseline we then want to > depend on MaterialDesignColor "v1.x.x". Thus, we follow the changes of > MaterialDesignColor while it's not a major release. > Because of this situation, BaselineOfMaterialDesignLite is different on the > two branches. Later, if I want to merge development into master in order to > release a new version, master will get the BaselineOfMaterialDesignLite with > semantic versionning dependencies instead of the fixed dependencies. Before > the release I'll need to change the Baseline to get fix dependencies once > again. > I hope I was clearer. :) > >> >> When you release a version, please do not move that version. You should >> then create new versions, with new numbers and new code. But never touch old >> versions with old numbers and old code. Like that I can download the same >> old code using the same old number to get the old version whenever I want >> :). >> >> You can try to do it with branches, tags, different repositories, or even >> with zipfiles in mails. I don't care. Just don't modify releases and I'm >> happy with it. >> >> >> > > > -- > Cyril Ferlicot > https://ferlicot.fr > >

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Dale Henrichs

On 03/05/2018 09:07 AM, Guillermo Polito wrote: > On the other side, there is the fact that Metacello baselines are so > far nice to describe release project dependencies, but they are not so > nice to describe subprojects/development dependencies that may get > edited along with the parent project. Kind of what we used to do with > #bleedingEdge. I feel this is a complex problem, that not even SBT or > maven that are there since years are capable of solving nicely... Tode > and Iceberg metacello integration try to solve this problem by > "ignoring the dependency and using the loaded repository" but this may > not be successful either... I have not been following this thread in detail, but this comment leads me to believe that the issue that you guys are running into has to do with trying to ongoing distributed development across multiple projects and multiple platform versions ... If so then I think that the moral equivalent of #bleedingEdge should be a branch structure along the lines of: Â master branch --- the project release that is known to work on all supported platform versions. Â dev_pharo6Â Â Â Â Â --- the current #bleedingEdge for Pharo6.0 Â dev_pharo7Â Â Â Â Â --- the current #bleedingEdge for Pharo7.0 In an image where you want to use the dev_pharo7 for a project, you do a Metacello lock on github://xxxx/xxx:dev_pharo7/src BEFORE loading the project ... if there are multiple projects that need to all coordinate development then you follow the same convention and use a Metacello lock for each of the projects ... Executing expressions to lock projects is tedious to use and manage. In tODE I started using project entries[1] that are downloaded to disk and shared by multiple images that allow a developer to specify what branch/tag/commit they are interested in using ... each image that is started up in a "cluster" uses the project entry to do a Metacello lock on the project "automagically"... if there is a series of projects where the developer needs to use dev_pharo6 they can arrange to edit the project entry to reflect the proper branches for the set of projects that need special _development_ treatment ... these .ston files can be shared amongst groups of developers ... of course once the local clones of these projects are on the local disk, then it is up to the developer (or a set of scripts) to periodically update to the latest development version of each of the projects ... To share a specific configuration of development git repos, you need to know that SHA anyway, so the image can produce a collection of project entries with the SHA of the commit and those project entries can be included in a bug report ... For Rowan[2], I am using a "load specification"[3], which is a second generation project entry .... the Rowan work is still evolving ... Anyway, I think that putting the control of what is being used for development completely in the developers hands and avoiding the need to edit baselines is a good thing ... and I think that the idea of having specifications that are shared by a cluster of images is a good way toÂ go ... Dale [1] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside32.ston [2] https://github.com/dalehenrich/Rowan [3] https://github.com/dalehenrich/Rowan/blob/master/specs/Rowan.ston

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Denis Kudriashov

Hi Dale. Where to read about locking? 2018-03-05 18:57 GMT+01:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > Cyril, > > For development I tend to use Metacello locking instead of hard-wired > dependencies in the BaselineOf and that works very well --- it completely > avoids the need to edit a baseline for development purposes and this > approach works really well for me ... perhaps we can discuss this in more > detail in a separate thread or even private email? This all seems to be > more complicated for you guys than has been my experience and of course you > guys _appear_ to be completely ignoring the Metacello locking feature so > I'm curious why ... > > Dale > > On 03/05/2018 08:02 AM, Cyril Ferlicot wrote: > > > On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: >> >> >> I still do not understand... Also I do not understand your usage of the >> term "the merge". Can somebody give a **concrete** scenario? >> >> I'll try > For example the project MaterialDesignLite have two branches that are > always here: > - master > - development > Each commit on master is a stable release and end up with a tag as > "v1.2.2". Since it's stable, BaselineOfMaterialDesignLite should depend > only on fixed version of the dependencies. For example it should depend on > MaterialDesignColor "v1.0.0". > On the branch dev, we want to get the patches and possibly the minor > versions of the dependencies automatically. In the baseline we then want to > depend on MaterialDesignColor "v1.x.x". Thus, we follow the changes of > MaterialDesignColor while it's not a major release. > Because of this situation, BaselineOfMaterialDesignLite is different on > the two branches. Later, if I want to merge development into master in > order to release a new version, master will get the > BaselineOfMaterialDesignLite with semantic versionning dependencies instead > of the fixed dependencies. Before the release I'll need to change the > Baseline to get fix dependencies once again. > I hope I was clearer. :) > > >> When you release a version, please do not move that version. You should >> then create new versions, with new numbers and new code. But never touch >> old versions with old numbers and old code. Like that I can download the >> same old code using the same old number to get the old version whenever I >> want :). >> >> You can try to do it with branches, tags, different repositories, or even >> with zipfiles in mails. I don't care. Just don't modify releases and I'm >> happy with it. >> >> >> >> > > -- > Cyril Ferlicot > https://ferlicot.fr > > >

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Dale Henrichs

On 03/05/2018 08:48 AM, Stephan Eggermont wrote: > tesonep(a)gmail.com > <tesonep(a)gmail.com> wrote: >> Hello, >> i have seen in the latest version of Pharo baselines pointing to >> "floating" versions. A version that is not fixed. I want to know why this >> is like that? > Because that is the way it should be? It is hand-edited, so repeatable > builds are not the goal, just working software. Repeatable builds come from > recording what you loaded in what order. Repeatable builds with fixed > dependency versions don't help you with working software, as they block > your dependencies from getting patched. Never depend on hard-coded versions > of anything you don't control yourself. See the 5D paper > > Stephan Eggermont Stephan, For this approach to work it is important that people not make a practice of committing api-breaking changes and by definition each new release of pharo breaks the fundamental api ... I've been able to survive in this universe with Metacello over the years, because I make a point of ensuring that the latest version of Metacello works on all supported platform versions and my observation has been that most Pharo projects ignore older versions of pharo for as long as they can get away with it and this becomes the source of so many issues I've seen ... With github and travis-ci it is practical to support projects on multiple platform versions ... if you want to ... this approach means that when you move to a new platform version you have to use packaging to isolate your version-specific changes and you probably have to refactor your implementation to be able to manage these version-specific changes ... only when you make api-breaking changes is it necessary to start new branches or use a series of tags ... Dale

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Stephan Eggermont

Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > It is clear that we need both baselines for that case. > But because we will move Calypso to Pharo repo I think it is easy to manage > strong versions directly in Pharo loading script for now (in #loadCalypso > method). Easy for now, yes. And also a bad example for others to follow. And something that doesn't scale. Where is the increased modularity going to come from if we still manage everything as a monorepo? Stephan

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Dale Henrichs

Cyril, For development I tend to use Metacello locking instead of hard-wired dependencies in the BaselineOf and that works very well --- it completely avoids the need to edit a baseline for development purposes and this approach works really well for me ... perhaps we can discuss this in more detail in a separate thread or even private email? This all seems to be more complicated for you guys than has been my experience and of course you guys _appear_ to be completely ignoring the Metacello locking feature so I'm curious why ... Dale On 03/05/2018 08:02 AM, Cyril Ferlicot wrote: > > On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito > <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > > > I still do not understand... Also I do not understand your usage > of the term "the merge". Can somebody give a **concrete** scenario? > > I'll try > For example the project MaterialDesignLite have two branches that are > always here: > - master > - development > Each commit on master is a stable release and end up with a tag as > "v1.2.2". Since it's stable, BaselineOfMaterialDesignLite should > depend only on fixed version of the dependencies. For example it > should depend on MaterialDesignColor "v1.0.0". > On the branch dev, we want to get the patches and possibly the minor > versions of the dependencies automatically. In the baseline we then > want to depend on MaterialDesignColor "v1.x.x". Thus, we follow the > changes of MaterialDesignColor while it's not a major release. > Because of this situation, BaselineOfMaterialDesignLite is different > on the two branches. Later, if I want to merge development into master > in order to release a new version, master will get the > BaselineOfMaterialDesignLite with semantic versionning dependencies > instead of the fixed dependencies. Before the release I'll need to > change the Baseline to get fix dependencies once again. > I hope I was clearer. :) > > When you release a version, please do not move that version. You > should then create new versions, with new numbers and new code. > But never touch old versions with old numbers and old code. Like > that I can download the same old code using the same old number to > get the old version whenever I want :). > > You can try to do it with branches, tags, different repositories, > or even with zipfiles in mails. I don't care. Just don't modify > releases and I'm happy with it. > > > > > -- > Cyril Ferlicot > https://ferlicot.fr

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Denis Kudriashov

2018-03-05 18:23 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >... > > > > So yes, it may block upgrades, but until we have tools that allow us to > > cope with the complexity, I prefer to have reproducible versions where I > > can reproduce bugs in a reproducible way than an unpredictable version > > where I cannot grasp the cause of a problem :/. > > I strongly advice against using Baselines for that. They are supposed to be > edited from hand, and using them for reproducible versions will break other > projects, as we've seen earlier with Configurations. AFAIK Metacello can > register which versions were loaded in which order, so that information > should be recorded for reproducibility. > It is clear that we need both baselines for that case. But because we will move Calypso to Pharo repo I think it is easy to manage strong versions directly in Pharo loading script for now (in #loadCalypso method). > > Stephan > > > > > > > >

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Nicolas Cellier

2018-03-05 18:23 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >... > > > > So yes, it may block upgrades, but until we have tools that allow us to > > cope with the complexity, I prefer to have reproducible versions where I > > can reproduce bugs in a reproducible way than an unpredictable version > > where I cannot grasp the cause of a problem :/. > > I strongly advice against using Baselines for that. They are supposed to be > edited from hand, and using them for reproducible versions will break other > projects, as we've seen earlier with Configurations. AFAIK Metacello can > register which versions were loaded in which order, so that information > should be recorded for reproducibility. > > Stephan > > > I support the idea of Stephan to go thru a two steps process: - use Metacello to extract exact versions - store this information as the specification of the bootstrap version. Can Metacello perform a sort of dry run? If not, would be nice! Then a UI with such information would be nice too (to answer the question: what will be loaded exactly, and from where?).

March 5, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-26

by Stephane Ducasse

Thanks pavel such experiments are super interesting because they push us outside our confort zone. On Mon, Mar 5, 2018 at 10:29 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > Guille is working on the Iceberg improvements and he wanted to be able to > open a terminal window on top of the repository and interact with it via > the command line. So we looked at this issue because I already in December > made some experiments with the terminal emulation in Pharo. > > In past, the Squeak had a working terminal emulation that used > PseudoTTYPlugin. The VM is not built with this code for a long time but I > tried to replace it with a small C library and then wrote an FFI interface > to it. Together with that, I ported most of the old code Squeak code to > Pharo. > > With Guille we tried to avoid usage of such external library and wrote an > FFI interface to all the required LibC functions. We were successful but we > realized that there are several issues that are limiting us. > > When you want to execute a separate process for the program that you want > to open in terminal (typically the Bash), you need to redirect the standard > IO files, create a fork of your process, do some additional initialization > in it and call 'exec' on it. In the parent process, you change redirected > IO files back to the original values. > > But the problem is that between the FFI calls from Smalltalk the VM can do > a lot of things including garbage collection etc. On OS X the fork() > function has the following limitation described in man: > > "There are limits to what you can do in the child process. To be totally > safe you should restrict your yourself to only executing async-signal safe > operations until such time as one of the exec functions is called. All > APIs, including global data symbols, in any framework or library should be > assumed to be unsafe after a fork() unless explicitly documented to be safe > or async-signal safe. If you need to use these frameworks in the child > process, you must exec. In this > situation it is reasonable to exec your-self. yourself." > > > As the result in most cases (but not all) the fork() and exec() pair from > the Smalltalk side fails on OS X. Linux does not have this limitation > however even there we found an issue. It is bound to the fact that fork() > makes a fork of all the parent process that uses the same resources. As > soon as Pharo is opened in a window and X11 is involved (the window wants > to be repainted), it can lead to the VM crash. > > So we learned that unfortunately we currently cannot use image-only FFI > code for this task. We need a C library or VM plugin. > > The repository of the terminal emulator is here: https://github.com/pavel- > krivanek/terminal > > and can be loaded using the following code: > > Metacello new > baseline: 'TerminalEmulator'; > repository: 'github://pavel-krivanek/terminal/src'; > load. > > #TerminalEmulator asClass compileLibrary. > > > â > It compiles and links the small library with only one function using the > GCC so the machine needs to have a proper development environment. > > The terminal emulator is in very early stage and has a lot of issues like > processes cleanup, drawing, keyboard input etc. etc. If you are interested > in it, feel free to contribute. > > Cheers, > -- Pavel > > > > > > > >

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Stephan Eggermont

Guillermo Polito <guillermopolito(a)gmail.com> wrote: >... > > So yes, it may block upgrades, but until we have tools that allow us to > cope with the complexity, I prefer to have reproducible versions where I > can reproduce bugs in a reproducible way than an unpredictable version > where I cannot grasp the cause of a problem :/. I strongly advice against using Baselines for that. They are supposed to be edited from hand, and using them for reproducible versions will break other projects, as we've seen earlier with Configurations. AFAIK Metacello can register which versions were loaded in which order, so that information should be recorded for reproducibility. Stephan

March 5, 2018