24 Sep
2015
24 Sep
'15
5:16 p.m.
Roassal2 (stable) does not load into Pharo 4.0 anymore:-(
Too bad that Pharo is so instable ...
Volkert
24 Sep
24 Sep
6:14 p.m.
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-td48…
Too bad that Pharo is so instable ...
I don't see how this is related to Pharo.
Peter
7:14 p.m.
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-td48…
Too bad that Pharo is so instable ...
I don't see how this is related to Pharo.
Peter
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:33 p.m.
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.
Phil
On Thu, Sep 24, 2015 at 7:14 PM, Volkert <volkert(a)komponentenwerkstatt.de>
wrote:
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-td48…
Too bad that Pharo is so instable ...
I don't see how this is related to Pharo.
Peter
_______________________________________________
Moose-dev mailing
listMoose-dev@iam.unibe.chhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
25 Sep
25 Sep
12:26 a.m.
On 24-09-15 21:33, phil(a)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
24 Sep
24 Sep
6:25 p.m.
Hi Volkert,
I am currently traveling. I will have a close look at this
Alexandre
Le 24 sept. 2015 à 12:16, Volkert
<volkert(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
7:15 p.m.
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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
8:25 p.m.
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.
Now if people do not maintain Roassal2 to load in several versions of
Pharo this is the
fault of Pharo.
When my mac backup tool does not work on yosemite anymore I do not say
that this is an objective-C 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.
Roassal2 (stable) does not load into Pharo 4.0
anymore:-(
Too bad that Pharo is so instable ...
Volkert
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:54 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
25 Sep
25 Sep
12:30 a.m.
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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
1:30 a.m.
Yes, it works now. Thanks a lot, Alex!
On Sep 24, 2015, at 19:30, Alexandre Bergel
<alexandre.bergel(a)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
---> 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 Sep 24, 2015, at 12:16 PM, Volkert
<volkert(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
5:18 a.m.
Yes, this Version works. Thank you.
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.
BW,
Volkert
PS: Roassal is so cooooool.
On 25.09.2015 00:30, Alexandre Bergel 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(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
7:52 a.m.
On 25 Sep 2015, at 05:18, Volkert
<volkert(a)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.
10:30 a.m.
On 25.09.2015 07:52, Sven Van Caekenberghe wrote:
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
On 25 Sep
2015, at 05:18, Volkert <volkert(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:37 a.m.
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(a)komponentenwerkstatt.de>
wrote:
On 25.09.2015 07:52, Sven Van Caekenberghe wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
On 25 Sep 2015, at 05:18, Volkert
<volkert(a)komponentenwerkstatt.de>
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
_______________________________________________
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
12:08 p.m.
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(a)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(a)komponentenwerkstatt.de
wrote:
On 25.09.2015 07:52, Sven Van Caekenberghe
wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 25 Sep 2015, at 05:18, Volkert
<volkert(a)komponentenwerkstatt.de>
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
_______________________________________________
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
12:34 p.m.
On 25 Sep 2015, at 12:08, Peter Uhnák
<i.uhnak(a)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(a)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(a)komponentenwerkstatt.de> wrote:
On 25.09.2015 07:52, Sven Van Caekenberghe wrote:
On 25 Sep 2015, at 05:18, Volkert <volkert(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:10 p.m.
On Fri, Sep 25, 2015 at 12:34 PM, Sven Van Caekenberghe <sven(a)stfx.eu>
wrote:
Roassal of course does have CI (just like the rest of the Moose), but it
tests Pharo 5.
On 25 Sep 2015, at 12:08, Peter Uhnák
<i.uhnak(a)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.
2:08 p.m.
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(a)gmail.com> wrote:
On Fri, Sep 25, 2015 at 12:34 PM, Sven Van Caekenberghe <sven(a)stfx.eu>
wrote:
Roassal of course does have CI (just like the rest of the Moose), but it
tests Pharo 5.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 25 Sep 2015, at 12:08, Peter Uhnák
<i.uhnak(a)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.
2:19 p.m.
On 25 Sep 2015, at 14:08, Andrei Chis
<chisvasileandrei(a)gmail.com> wrote:
https://ci.inria.fr/moose/view/Moose%205.1/job/roassal2-pharo4/
CI job that loads roassal2 #stable on Pharo 4.
Cool !
Cheers,
Andrei
On Fri, Sep 25, 2015 at 1:10 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
On Fri, Sep 25, 2015 at 12:34 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote:
On 25 Sep 2015, at 12:08, Peter Uhnák
<i.uhnak(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
28 Sep
28 Sep
5:23 p.m.
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(a)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(a)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(a)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(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:15 p.m.
I have no idea how to do it. I have tried:
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 28, 2015, at 5:23 PM, Offray Vladimir Luna
Cárdenas <offray(a)riseup.net> wrote:
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:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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(a)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(a)komponentenwerkstatt.de> wrote:
On 25.09.2015 07:52, Sven Van Caekenberghe wrote:
On 25 Sep 2015, at 05:18, Volkert <volkert(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:43 p.m.
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(a)stfx.eu> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 25 Sep 2015, at 05:18, Volkert
<volkert(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
30 Sep
30 Sep
7:38 a.m.
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(a)stfx.eu> wrote:
>
>
>> On 25 Sep 2015, at 05:18, Volkert <volkert(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:15 a.m.
Same here.
On Wed, Sep 30, 2015 at 7:38 AM, Volkert <volkert(a)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(a)stfx.eu>
<sven(a)stfx.eu> wrote:
On 25 Sep 2015, at 05:18, Volkert <volkert(a)komponentenwerkstatt.de>
<volkert(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:45 a.m.
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(a)highoctane.be
wrote:
Same here.
On Wed, Sep 30, 2015 at 7:38 AM, Volkert <volkert(a)komponentenwerkstatt.de> wrote:
Now version 1.15 produce the warning as well :-(
<begfacfh.png>
On 28.09.2015 20:43, Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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(a)stfx.eu>
> wrote:
>
>
>
>> On 25 Sep 2015, at 05:18, Volkert <volkert(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:57 a.m.
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(a)highoctane.be wrote:
>
> Same here.
>
> On Wed, Sep 30, 2015 at 7:38 AM, Volkert <volkert(a)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(a)stfx.eu>
>>> wrote:
>>>
>>>
>>>
>>>> On 25 Sep 2015, at 05:18, Volkert
<volkert(a)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(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3:10 p.m.
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.
Phil
On Wed, Sep 30, 2015 at 10:57 AM, Volkert <volkert(a)komponentenwerkstatt.de>
wrote:
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(a)highoctane.be wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)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(a)stfx.eu>
> wrote:
>
>
>
> On 25 Sep 2015, at 05:18, Volkert <volkert(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:15 p.m.
On 30/09/15 15:10, phil(a)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
28 Sep
28 Sep
5:11 p.m.
Thanks Alexandre, I can confirm this works! Now I have examples back :-)
Cheers,
Offray
On 24/09/15 17:30, Alexandre Bergel 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(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3124
days inactive
3130
days old
29 comments
12 participants
participants (12)
-
Alexandre Bergel -
Andrei Chis -
Johan Fabry -
Offray Vladimir Luna Cárdenas -
Peter Uhnák -
phil＠highoctane.be -
stephan -
Stephan Eggermont
-
stepharo -
Sven Van Caekenberghe -
Tudor Girba -
Volkert