Hi!
Maybe one of Deep into Pharo’s reader can write a review on:
http://www.amazon.com/Deep-into-Pharo-Alexandre-Bergel/dp/3952334162
This will help everybody by promoting our favorite language...
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Stef,
What exactly are you trying to achieve here?
Adding more flattened snapshots to the ConfigurationOfMoose
is i.m.o. not a good idea. I've never found snapshotted
versions useable for development. Within a week there
were incompatible changes that break the snapshot version.
Snapshots can be a valuable artifact, and should be separate
from configurations.
Stephan
Steph, please try this with ConfigurationOfPharo first.
You have much more control over that, and it will
allow you to break the tools fast without bothering
others. We use ConfigurationOfMoose.
>When you develop you want to always get the latest (and certainly not on
>project you have no control over).
You want to, but you can't. And you definitely don't want
to have to create all kinds of configuration versions of
packages outside your control just to be able to load.
I would like to include Torch. Doesn't work with latest.
Cleaning up of moose configuration is much appreciated.
You probably want to add some groups, so you can have your
tools.
Stephan
Hi
Usman found that mooseDSM depends on Moose and that Moose depends on DSM.
This shows a problem with the configurations in the Moose ecosystem.
After thinking about it, there are two kinds of configurations:
- first kind of a configuration should express the dependencies to
systems that are mandatory.
- the second kind represents "Full project" configurations that
express a complete "applications"
with all the subapplications. They do not express that the tool
must all the dependencies to be resolved to work.
For example, MooseAlgos are in Moose even if we do not use MooseAlgos.
Such full project should not be referred too.
=> So we should distinguish such different configurations.
For example Glamour as a UI builder should not depend on Roassal
But Glamour as a full project can depend on Roassal.
Then at the Moose or project level we can decide what to load.
Stef
Guille wrote
>Just a thought, maybe offtopic,
>but that goes in the modularity path...
>What about adding also a new ´moose´ tab
>to the configuration browser showing only
>moose sub-products?
configuration browser first needs something to be able to load Seaside with Magritte. We regularly get complaints about that. A separate tab for Moose doesn't make much sense. Configuration browser is for ease of use, so configurations should provide a list of sensible (to an end user) groups that the browser can use.
Stephan
Steph wrote:
>If necessary we will build a tool that does is automatically. Releasing
>a real fixed version is important.
>I'm sorry stefan but we want FULL reproducibility.
A snapshot is a separate concept from a configuration. Building a separate
tool to create snapshots is a good idea. A snapshot should know about
a configuration but not the other way around.
The problem we run into is that we use configuration A that depends
on version B1 of a configuration, and another configuration C that depends
on version B2. So we need to create a new configuration version of A,
even though A is not interested in C.
To make that work dependent configurations would need
to change at the sum of change rate of all the configurations they are
depending on. As long as we don't have global flow (in the lean sense) that is
unworkable.
>We cannot sign contracts when we maintain deployed systems by just
>saving images and preying.
Yes. Make snapshots. And a good experiment to get tools improved
would be to add a ConfigurationOfPharo build that creates a version for
each build. I suspect some scalability issues.
Stephan
Steph wrote:
> - make sure that all the configurations of external libraries are
>correctly defined.
> In particular we made sure that a version does not depend on a
>stable one but on a version specific.
I would recommend against using detailed numbered versions
for this. That couples you to bug fix patches/updates in the external
libraries and creates a very high versioning effort.
In Seaside we use release3 release30 release31 instead of stable.
Release3 introduced a different packaging, and 31 has some interface
changes. We can now safely promote a new version to stable without
having to update all configurations using seaside.
This reduces the versioning effort, at some loss in reproducibility.
For that, separate snapshots are perfect.
Cheers,
Stephan
