You are right. But it is not Roassal alone ...from a User (f.e. a newcomer) perspective it is always bad, if things not work ...and if things not work, the "Pharo Ecosystem" so is not so cool anymore. So it is relates to "Pharo".

I like the pace the "Pharo" Development moves forward, but i am afraid you will lose potential users, if the things break all the time.

Volkert PS: Yes i love Pharo ... and i hope that one day i can make money with it :-)

On 24.09.2015 18:14, Peter Uhnák wrote:

Clicking on Proceed should install it, only examples will be broken.

This is currently being also discussed in another thread http://forum.world.st/Problem-Loading-Roassal-2-development-in-Pharo-4-td485...

Too bad that Pharo is so instable ...

I don't see how this is related to Pharo.

Peter

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On 24-09-15 21:33, phil@highoctane.be wrote:

Pharo is very stable. Running in production without problems.

It takes a while to get things working on a new version of course.

Pharo4.0 is out since just a couple of months, of course all packages aren't aligned.

I am using Pharo3.0 for commercial solutions and Pharo5.x for learning.

But you are right that configurations have to be rock solid.

I've found that #stable may not be so #stable and that it would be better to load '1.2.3' instead. The issue is that some dependencies are on #stable or similar symbols that change and are giving headaches.

NO. The problem is that the dependencies are specified as numbered versions instead of symbolic ones. That means that every change to a leave breaks all configurations above. That is what creates the brittleness, not the change itself. Why are GlamourCore and therefore Roassal2 depending on broken versions of Rubric?

Stephan

Easy.

BW, Volkert

On 24.09.2015 18:25, Alexandre Bergel wrote:

Hi Volkert,

I am currently traveling. I will have a close look at this

Alexandre

...

Le 24 sept. 2015 à 12:16, Volkert volkert@komponentenwerkstatt.de a écrit :

Roassal2 (stable) does not load into Pharo 4.0 anymore:-(

Too bad that Pharo is so instable ...

Volkert

<ijddbdgd.png> _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On 24.09.2015 20:25, stepharo wrote:

Sorry but this has nothing to do with Pharo. We migrated Moose (150 packages) from pharo 30 to 40 in two days. So pharo is not unstable! Repeat after me Pharo is not unstable.

Sorry, of course not Pharo. Pharo is perfect ... ;-)

Now if people do not maintain Roassal2 to load in several versions of Pharo this is the fault of Pharo.

I understand, it is Roassal2 and the way how dependencies are managed. But i have the feeling that with Glamour things are more complicated now ....

When my mac backup tool does not work on yosemite anymore I do not say that this is an objective-C problem.

When my SuperDuper-Pharo-Based-Tool does not work on Ubuntu anymore i do not say that this is an Pharo problem.

Stef

PS: why don't you try to find the latest version of Roassal that worked in Pharo40 and make sure that you use this one.

i thought when i "loadStable" it is the latest version that worked in Pharo40.

Volkert

...

Roassal2 (stable) does not load into Pharo 4.0 anymore:-(

Too bad that Pharo is so instable ...

Volkert

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Yes, it works now. Thanks a lot, Alex!

On Sep 24, 2015, at 19:30, Alexandre Bergel alexandre.bergel@me.com wrote:

Hi Volkert and Johan,

I think a wrong version of Roassal was chosen. I fixed the configuration. Try in Pharo 4.0:

Gofer it smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; configurationOf: 'Roassal2'; loadVersion: ‘1.15'

It should work. And you have even the example browser!

Cheers, Alexandre

...

On Sep 24, 2015, at 12:16 PM, Volkert volkert@komponentenwerkstatt.de wrote:

Roassal2 (stable) does not load into Pharo 4.0 anymore:-(

Too bad that Pharo is so instable ...

Volkert

<ijddbdgd.png> _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

On 25 Sep 2015, at 05:18, Volkert volkert@komponentenwerkstatt.de wrote:

But how do i figure out, which is the right Version for Pharo 4.0? I always thought loadStable is ok, as mentioned http://objectprofile.com/Roassal.html.

You are right, as an end user you should just use #stable on any supported platform and it should work.

The authors of the configuration can declare for each platform (Pharo 4, 5) which is the stable version.

Obviously someone made a mistake while moving forward, we are all humans after all.

Thanks for your patience, Volkert.

And thanks Alex for fixing the configuration.

Cheers, Doru

On Fri, Sep 25, 2015 at 10:30 AM, Volkert volkert@komponentenwerkstatt.de wrote:

On 25.09.2015 07:52, Sven Van Caekenberghe wrote:

...

On 25 Sep 2015, at 05:18, Volkert volkert@komponentenwerkstatt.de

...

wrote:

But how do i figure out, which is the right Version for Pharo 4.0? I always thought loadStable is ok, as mentioned http://objectprofile.com/Roassal.html.

You are right, as an end user you should just use #stable on any supported platform and it should work.

The authors of the configuration can declare for each platform (Pharo 4, 5) which is the stable version.

Obviously someone made a mistake while moving forward, we are all humans after all.

i have no intention to blame here someone ... i only try to understand how the things are connected ... and i have learned something new ...

Volkert

---

...

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On 25 Sep 2015, at 12:08, Peter Uhnák i.uhnak@gmail.com wrote:

There should be CI job for Roassal2 #stable and Pharo4. Especially if most of Roassal contributors/devs are in Pharo 5 and thus only end-users will notice it.

(with the multi-configuration job in Jenkins it's easy to setup custom matrix)

Yes, this is so useful, I can hardly imagine doing it without a CI (no one has time to do all the testing)

https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/

The cool thing is that there are also images as artefacts, which users can download when they have trouble building from source.

But there have to be project specific tests as well.

Peter

On Fri, Sep 25, 2015 at 11:37 AM, Tudor Girba tudor@tudorgirba.com wrote: Thanks for your patience, Volkert.

And thanks Alex for fixing the configuration.

Cheers, Doru

On Fri, Sep 25, 2015 at 10:30 AM, Volkert volkert@komponentenwerkstatt.de wrote: On 25.09.2015 07:52, Sven Van Caekenberghe wrote: On 25 Sep 2015, at 05:18, Volkert volkert@komponentenwerkstatt.de wrote:

But how do i figure out, which is the right Version for Pharo 4.0? I always thought loadStable is ok, as mentioned http://objectprofile.com/Roassal.html. You are right, as an end user you should just use #stable on any supported platform and it should work.

The authors of the configuration can declare for each platform (Pharo 4, 5) which is the stable version.

Obviously someone made a mistake while moving forward, we are all humans after all. i have no intention to blame here someone ... i only try to understand how the things are connected ... and i have learned something new ...

Volkert

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com

"Every thing has its own flow"

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

https://ci.inria.fr/moose/view/Moose%205.1/job/roassal2-pharo4/

CI job that loads roassal2 #stable on Pharo 4.

Cheers, Andrei

On Fri, Sep 25, 2015 at 1:10 PM, Peter Uhnák i.uhnak@gmail.com wrote:

On Fri, Sep 25, 2015 at 12:34 PM, Sven Van Caekenberghe sven@stfx.eu wrote:

...

...

On 25 Sep 2015, at 12:08, Peter Uhnák i.uhnak@gmail.com wrote:

There should be CI job for Roassal2 #stable and Pharo4. Especially if most of Roassal contributors/devs are in Pharo 5 and thus

only end-users will notice it.

...

(with the multi-configuration job in Jenkins it's easy to setup custom

matrix)

Yes, this is so useful, I can hardly imagine doing it without a CI (no one has time to do all the testing)

https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/

The cool thing is that there are also images as artefacts, which users can download when they have trouble building from source.

But there have to be project specific tests as well.

Roassal of course does have CI (just like the rest of the Moose), but it tests Pharo 5.

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Agree! Last week we had a workshop on our hackerspace and the Roassal2 examples on Pharo 4 were broken. If I run:

Gofer it smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; configurationOf: 'Roassal2'; loadStable.

on pharo 4, Roassal examples don't work, while running it with loadVersion: '1.15' works. Shouldn't loadStable point to '1.15' or the last version which works on Pharo 4?

Cheers,

Offray

On 25/09/15 05:08, Peter Uhnák wrote:

There should be CI job for Roassal2 #stable and Pharo4. Especially if most of Roassal contributors/devs are in Pharo 5 and thus only end-users will notice it.

(with the multi-configuration job in Jenkins it's easy to setup custom matrix)

Peter

On Fri, Sep 25, 2015 at 11:37 AM, Tudor Girba <tudor@tudorgirba.com mailto:tudor@tudorgirba.com> wrote:

Thanks for your patience, Volkert.

And thanks Alex for fixing the configuration.

Cheers,
Doru


On Fri, Sep 25, 2015 at 10:30 AM, Volkert
<volkert@komponentenwerkstatt.de
<mailto:volkert@komponentenwerkstatt.de>> wrote:

    On 25.09.2015 07 <tel:25.09.2015%2007>:52, Sven Van
    Caekenberghe wrote:

            On 25 Sep 2015, at 05:18, Volkert
            <volkert@komponentenwerkstatt.de
            <mailto:volkert@komponentenwerkstatt.de>> wrote:

            But how do i figure out, which is the right Version
            for Pharo 4.0? I always thought loadStable is ok, as
            mentioned http://objectprofile.com/Roassal.html.

        You are right, as an end user you should just use #stable
        on any supported platform and it should work.

        The authors of the configuration can declare for each
        platform (Pharo 4, 5) which is the stable version.

        Obviously someone made a mistake while moving forward, we
        are all humans after all.

    i have no intention to blame here someone ... i only try to
    understand how the things  are connected ... and i have
    learned something new ...

    Volkert



        _______________________________________________
        Moose-dev mailing list
        Moose-dev@iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
        https://www.iam.unibe.ch/mailman/listinfo/moose-dev


    _______________________________________________
    Moose-dev mailing list
    Moose-dev@iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
    https://www.iam.unibe.ch/mailman/listinfo/moose-dev




-- 
www.tudorgirba.com <http://www.tudorgirba.com>

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Yeah, it would be great to have this behavior. But no idea how.

I tried to have in ConfigurationOfRoassal2:

stable: spec <symbolicVersion: #'stable'>

spec for: #'common' version: '1.16'. spec for: #'pharo4.x' version: '1.15'. spec for: #'pharo3.x' version: '1.6'. spec for: #'pharo5.x' version: '1.16’.

But loading: Gofer it smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; configurationOf: 'Roassal2'; loadStable

in pharo 4 still produces the error.

Alexandre

On Sep 25, 2015, at 7:52 AM, Sven Van Caekenberghe sven@stfx.eu wrote:

...

On 25 Sep 2015, at 05:18, Volkert volkert@komponentenwerkstatt.de wrote:

But how do i figure out, which is the right Version for Pharo 4.0? I always thought loadStable is ok, as mentioned http://objectprofile.com/Roassal.html.

You are right, as an end user you should just use #stable on any supported platform and it should work.

The authors of the configuration can declare for each platform (Pharo 4, 5) which is the stable version.

Obviously someone made a mistake while moving forward, we are all humans after all. _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Same here.

On Wed, Sep 30, 2015 at 7:38 AM, Volkert volkert@komponentenwerkstatt.de wrote:

Now version 1.15 produce the warning as well :-(

On 28.09.2015 20:43, Alexandre Bergel wrote:

Yeah, it would be great to have this behavior. But no idea how.

I tried to have in ConfigurationOfRoassal2:

stable: spec <symbolicVersion: #'stable'>

spec for: #'common' version: '1.16'. spec for: #'pharo4.x' version: '1.15'. spec for: #'pharo3.x' version: '1.6'. spec for: #'pharo5.x' version: '1.16’.

But loading: Gofer it smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; configurationOf: 'Roassal2'; loadStable

in pharo 4 still produces the error.

Alexandre

On Sep 25, 2015, at 7:52 AM, Sven Van Caekenberghe sven@stfx.eu sven@stfx.eu wrote:

On 25 Sep 2015, at 05:18, Volkert volkert@komponentenwerkstatt.de volkert@komponentenwerkstatt.de wrote:

But how do i figure out, which is the right Version for Pharo 4.0? I always thought loadStable is ok, as mentioned http://objectprofile.com/Roassal.html.

You are right, as an end user you should just use #stable on any supported platform and it should work.

The authors of the configuration can declare for each platform (Pharo 4, 5) which is the stable version.

Obviously someone made a mistake while moving forward, we are all humans after all. _______________________________________________ Moose-dev mailing listMoose-dev@iam.unibe.chhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Now is fine again ... :-)

... i will try to understand how Configuration stuff works. Will first read "Deep into Pharo" today ...

BW, Volkert

On 30.09.2015 10:45, Alexandre Bergel wrote:

Sorry guys for this regression. I have reverted the configuration. It is really mysterious how it works.

So, in summary, to load Roassal on Pharo 4 you need to do: Gofer it smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; configurationOf: 'Roassal2'; loadVersion: '1.15'.

Cheers, Alexandre

...

On Sep 30, 2015, at 9:15 AM, phil@highoctane.be wrote:

Same here.

On Wed, Sep 30, 2015 at 7:38 AM, Volkert volkert@komponentenwerkstatt.de wrote: Now version 1.15 produce the warning as well :-(

<begfacfh.png>

On 28.09.2015 20:43, Alexandre Bergel wrote:

...

Yeah, it would be great to have this behavior. But no idea how.

I tried to have in ConfigurationOfRoassal2:

stable: spec <symbolicVersion: #'stable'>

spec for: #'common' version: '1.16'. spec for: #'pharo4.x' version: '1.15'. spec for: #'pharo3.x' version: '1.6'. spec for: #'pharo5.x' version: '1.16’.

But loading: Gofer it smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; configurationOf: 'Roassal2'; loadStable

in pharo 4 still produces the error.

Alexandre

...

On Sep 25, 2015, at 7:52 AM, Sven Van Caekenberghe sven@stfx.eu wrote:

...

On 25 Sep 2015, at 05:18, Volkert volkert@komponentenwerkstatt.de wrote:

But how do i figure out, which is the right Version for Pharo 4.0? I always thought loadStable is ok, as mentioned http://objectprofile.com/Roassal.html .

You are right, as an end user you should just use #stable on any supported platform and it should work.

The authors of the configuration can declare for each platform (Pharo 4, 5) which is the stable version.

Obviously someone made a mistake while moving forward, we are all humans after all. _______________________________________________ Moose-dev mailing list

Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On 30/09/15 15:10, phil@highoctane.be wrote:

Why not put a version of the config in the Pharo40Metarepo and leave it at that?

As the new stuff occurs in Pharo5, new configs should go in a Pharo50Metarepo and not affect anything in 4.0

Feeback welcome.

We will have a year of bug fixes in Pharo 4. The core development moves to Pharo 5, and not all other projects do the same. Lots of projects want to be a bit behind the bleeding edge, or even only build on released versions. A Configuration describes how to load things in each version of Pharo/Gemstone/Squeak (that the project wants to support). Projects that do not want to be on the bleeding edge still want bug fixes. That means they always want the latest version of every configurationOf they use (not necessarily the latest version found in that configurationOf, though).

If the development of a dependency happens in Pharo 5 and only bugfixes are backported to Pharo 4, it is fine to depend on the latest released version on Pharo 4 (that can be #'stable') as long as the bugfixes don't affect the api you use. This only works if that also goes for the dependencies of the dependency etc...

If the development of a dependency happens in Pharo 4 or both 4 and 5, the dependency needs to release a symbolic version that marks the version at the time of the Pharo 4 release. That can be updated with non-breaking fixes.

What we now see is GlamourCore depending on an old version of Rubric, and Roassal2 depending on GlamourCore. Three different projects are now hard connected to each other with the numbered versions. Breaking that hard dependency would help. That might need adding symbolic versions to Rubric.

Another issue is the old configurations in the Pharo 4 build. I'm not sure why they are not updated.

Stephan

Stephan