6 May
2011
6 May
'11
3:25 p.m.
Hi,
I think to have a bug with RPackage.
I used MooseScripts>>createModelForMoose.
This method works fine.
then I removed 3 methods useless for Moose (see issue 614)
When I rerun MooseScripts>>createModelForMoose, there is an error key not found.
The cache of RPackage is not updated.
Any solution ?
Jannik
6 May
6 May
4:33 p.m.
I bumped into the very same problem.
Killing the MooseModel does not help neither.
Alexandre
On 6 May 2011, at 09:25, jannik.laval wrote:
Hi,
I think to have a bug with RPackage.
I used MooseScripts>>createModelForMoose.
This method works fine.
then I removed 3 methods useless for Moose (see issue 614)
When I rerun MooseScripts>>createModelForMoose, there is an error key not found.
The cache of RPackage is not updated.
Any solution ?
Jannik
_______________________________________________
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
3:37 p.m.
You should do manually "RPackageOrganizer initializeDefault".
It rebuild the PackageCache.
It seems that RPackage does not react to all announcements.
Jannik
On May 6, 2011, at 16:33 , Alexandre Bergel wrote:
I bumped into the very same problem.
Killing the MooseModel does not help neither.
Alexandre
On 6 May 2011, at 09:25, jannik.laval wrote:
Hi,
I think to have a bug with RPackage.
I used MooseScripts>>createModelForMoose.
This method works fine.
then I removed 3 methods useless for Moose (see issue 614)
When I rerun MooseScripts>>createModelForMoose, there is an error key not found.
The cache of RPackage is not updated.
Any solution ?
Jannik
_______________________________________________
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
3:47 p.m.
Indeed there is a bug. I will look at that. In fact it seems to react, but
not well :(
2011/5/6 jannik.laval <jannik.laval(a)gmail.com>
You should do manually "RPackageOrganizer
initializeDefault".
It rebuild the PackageCache.
It seems that RPackage does not react to all announcements.
Jannik
On May 6, 2011, at 16:33 , Alexandre Bergel wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I bumped into the very same problem.
Killing the MooseModel does not help neither.
Alexandre
On 6 May 2011, at 09:25, jannik.laval wrote:
> Hi,
>
> I think to have a bug with RPackage.
>
> I used MooseScripts>>createModelForMoose.
> This method works fine.
>
> then I removed 3 methods useless for Moose (see issue 614)
>
> When I rerun MooseScripts>>createModelForMoose, there is an error key
not found.
The cache
of RPackage is not updated.
Any solution ?
Jannik
_______________________________________________
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:49 p.m.
Thanks for the tip.
Alexandre
On 6 May 2011, at 09:37, jannik.laval wrote:
You should do manually "RPackageOrganizer
initializeDefault".
It rebuild the PackageCache.
It seems that RPackage does not react to all announcements.
Jannik
On May 6, 2011, at 16:33 , Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I bumped into the very same problem.
Killing the MooseModel does not help neither.
Alexandre
On 6 May 2011, at 09:25, jannik.laval wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi,
I think to have a bug with RPackage.
I used MooseScripts>>createModelForMoose.
This method works fine.
then I removed 3 methods useless for Moose (see issue 614)
When I rerun MooseScripts>>createModelForMoose, there is an error key not found.
The cache of RPackage is not updated.
Any solution ?
Jannik
_______________________________________________
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:05 p.m.
It was indeed a problem from RPackage , that was surely the source of other
strange behaviours i already saw with RPackage some times ago. So it was
cool to have this concrete example pointing the problem;) The changes I made
should be integrated in the last version of RPackage soon.
2011/5/6 Alexandre Bergel <alexandre.bergel(a)me.com>
Thanks for the tip.
Alexandre
On 6 May 2011, at 09:37, jannik.laval wrote:
_______________________________________________
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
You should do manually "RPackageOrganizer
initializeDefault".
It rebuild the PackageCache.
It seems that RPackage does not react to all announcements.
Jannik
On May 6, 2011, at 16:33 , Alexandre Bergel wrote:
> I bumped into the very same problem.
> Killing the MooseModel does not help neither.
>
> Alexandre
>
>
> On 6 May 2011, at 09:25, jannik.laval wrote:
>
>> Hi,
>>
>> I think to have a bug with RPackage.
>>
>> I used MooseScripts>>createModelForMoose.
>> This method works fine.
>>
>> then I removed 3 methods useless for Moose (see issue 614)
>>
>> When I rerun MooseScripts>>createModelForMoose, there is an error key
not found.
The cache of RPackage is not updated.
Any solution ?
Jannik
_______________________________________________
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:08 p.m.
Pay attention that we use a stable version, not the default version of RPackage.
Jannik
On May 6, 2011, at 17:05 , Cyrille Delaunay wrote:
It was indeed a problem from RPackage , that was
surely the source of other strange behaviours i already saw with RPackage some times ago.
So it was cool to have this concrete example pointing the problem;) The changes I made
should be integrated in the last version of RPackage soon.
2011/5/6 Alexandre Bergel <alexandre.bergel(a)me.com>
Thanks for the tip.
Alexandre
On 6 May 2011, at 09:37, jannik.laval wrote:
You should do manually "RPackageOrganizer
initializeDefault".
It rebuild the PackageCache.
It seems that RPackage does not react to all announcements.
Jannik
On May 6, 2011, at 16:33 , Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
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 I bumped into the very same problem.
Killing the MooseModel does not help neither.
Alexandre
On 6 May 2011, at 09:25, jannik.laval wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi,
I think to have a bug with RPackage.
I used MooseScripts>>createModelForMoose.
This method works fine.
then I removed 3 methods useless for Moose (see issue 614)
When I rerun MooseScripts>>createModelForMoose, there is an error key not found.
The cache of RPackage is not updated.
Any solution ?
Jannik
_______________________________________________
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
7 May
7 May
10:42 a.m.
+1 Jannik
I could not understand what is your problem and without that I will not be able to fix
it.
Stef
On May 6, 2011, at 5:05 PM, Cyrille Delaunay wrote:
It was indeed a problem from RPackage , that was
surely the source of other strange behaviours i already saw with RPackage some times ago.
So it was cool to have this concrete example pointing the problem;) The changes I made
should be integrated in the last version of RPackage soon.
2011/5/6 Alexandre Bergel <alexandre.bergel(a)me.com>
Thanks for the tip.
Alexandre
On 6 May 2011, at 09:37, jannik.laval wrote:
You should do manually "RPackageOrganizer
initializeDefault".
It rebuild the PackageCache.
It seems that RPackage does not react to all announcements.
Jannik
On May 6, 2011, at 16:33 , Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
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 I bumped into the very same problem.
Killing the MooseModel does not help neither.
Alexandre
On 6 May 2011, at 09:25, jannik.laval wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi,
I think to have a bug with RPackage.
I used MooseScripts>>createModelForMoose.
This method works fine.
then I removed 3 methods useless for Moose (see issue 614)
When I rerun MooseScripts>>createModelForMoose, there is an error key not found.
The cache of RPackage is not updated.
Any solution ?
Jannik
_______________________________________________
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
10:50 a.m.
Cyrille, should we understand that you fixed it?
Cheers,
Doru
On 7 May 2011, at 10:42, Stéphane Ducasse wrote:
+1 Jannik
I could not understand what is your problem and without that I will not be able to fix
it.
Stef
On May 6, 2011, at 5:05 PM, Cyrille Delaunay wrote:
--
www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
It was indeed a problem from RPackage , that was
surely the source of other strange behaviours i already saw with RPackage some times ago.
So it was cool to have this concrete example pointing the problem;) The changes I made
should be integrated in the last version of RPackage soon.
2011/5/6 Alexandre Bergel <alexandre.bergel(a)me.com>
Thanks for the tip.
Alexandre
On 6 May 2011, at 09:37, jannik.laval wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev You should do manually "RPackageOrganizer
initializeDefault".
It rebuild the PackageCache.
It seems that RPackage does not react to all announcements.
Jannik
On May 6, 2011, at 16:33 , Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
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 I bumped into the very same problem.
Killing the MooseModel does not help neither.
Alexandre
On 6 May 2011, at 09:25, jannik.laval wrote:
> Hi,
>
> I think to have a bug with RPackage.
>
> I used MooseScripts>>createModelForMoose.
> This method works fine.
>
> then I removed 3 methods useless for Moose (see issue 614)
>
> When I rerun MooseScripts>>createModelForMoose, there is an error key not
found.
> The cache of RPackage is not updated.
>
> Any solution ?
>
> Jannik
> _______________________________________________
> 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
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
11:15 a.m.
On May 6, 2011, at 3:25 PM, jannik.laval wrote:
Hi,
I think to have a bug with RPackage.
I used MooseScripts>>createModelForMoose.
This method works fine.
then I removed 3 methods useless for Moose (see issue 614)
When I rerun MooseScripts>>createModelForMoose, there is an error key not found.
The cache of RPackage is not updated.
what cache?
Any solution ?
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:21 a.m.
The issue is that the Organizer gets out of sync. I do not know when, but I saw it
happening. It is what I sent to the pharo mailing list:
---quote---
ConfigurationOfRPackage 1.0 seems to go out of sync with the image after a while. For
example, download the following Moose image:
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
and try
RPackage organizer packageNamed: 'Famix-Core'
---
Cheers,
Doru
On 7 May 2011, at 11:15, Stéphane Ducasse wrote:
On May 6, 2011, at 3:25 PM, jannik.laval wrote:
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Hi,
I think to have a bug with RPackage.
I used MooseScripts>>createModelForMoose.
This method works fine.
then I removed 3 methods useless for Moose (see issue 614)
When I rerun MooseScripts>>createModelForMoose, there is an error key not found.
The cache of RPackage is not updated.
what cache?
Any solution ?
Jannik
_______________________________________________
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
11:49 a.m.
I do not get it.
Don't you use the 3.0 version?
Because I do not know what is the 1.0 especially since you loaded latest so this measn
that I have no clue
what version is really loaded and I will not have a look because I cannot spend time
reverse engineer
working set of packages.
We started to sync with cyrille yesterday and I will merge his changes and produce a new
3.0 and a stable tag.
So that people can load stable and we can continue to work on the integration.
Stef
On May 7, 2011, at 11:21 AM, Tudor Girba wrote:
The issue is that the Organizer gets out of sync. I do
not know when, but I saw it happening. It is what I sent to the pharo mailing list:
---quote---
ConfigurationOfRPackage 1.0 seems to go out of sync with the image after a while. For
example, download the following Moose image:
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
and try
RPackage organizer packageNamed: 'Famix-Core'
---
Cheers,
Doru
On 7 May 2011, at 11:15, Stéphane Ducasse wrote:
On May 6, 2011, at 3:25 PM, jannik.laval wrote:
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi,
I think to have a bug with RPackage.
I used MooseScripts>>createModelForMoose.
This method works fine.
then I removed 3 methods useless for Moose (see issue 614)
When I rerun MooseScripts>>createModelForMoose, there is an error key not found.
The cache of RPackage is not updated.
what cache?
Any solution ?
Jannik
_______________________________________________
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
11:59 a.m.
Stef, you told us to load #stable and this is what we are loading, and currently #stable
loads '1.0'.
That is why I asked on the Pharo mailing list if 3.0 is stable, so that #stable should
point to it rather than to '1.0'. If you want this versioning scheme to work, you
have to take into account the energy to maintain the configuration. Otherwise, feedback
will always be out of date, and the dialog not very constructive.
However, I did some more tests and it seems that some desynchronization appears in 3.0 as
well, only I do not know how to reproduce the problem because I do not know where it comes
from.
Cyrille, could you detail your finding for documentation purpose?
Cheers,
Doru
On 7 May 2011, at 11:49, Stéphane Ducasse wrote:
I do not get it.
Don't you use the 3.0 version?
Because I do not know what is the 1.0 especially since you loaded latest so this measn
that I have no clue
what version is really loaded and I will not have a look because I cannot spend time
reverse engineer
working set of packages.
We started to sync with cyrille yesterday and I will merge his changes and produce a new
3.0 and a stable tag.
So that people can load stable and we can continue to work on the integration.
Stef
On May 7, 2011, at 11:21 AM, Tudor Girba wrote:
--
www.tudorgirba.com
"Sometimes the best solution is not the best solution."
The issue is that the Organizer gets out of sync.
I do not know when, but I saw it happening. It is what I sent to the pharo mailing list:
---quote---
ConfigurationOfRPackage 1.0 seems to go out of sync with the image after a while. For
example, download the following Moose image:
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
and try
RPackage organizer packageNamed: 'Famix-Core'
---
Cheers,
Doru
On 7 May 2011, at 11:15, Stéphane Ducasse wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On May 6, 2011, at 3:25 PM, jannik.laval wrote:
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi,
I think to have a bug with RPackage.
I used MooseScripts>>createModelForMoose.
This method works fine.
then I removed 3 methods useless for Moose (see issue 614)
When I rerun MooseScripts>>createModelForMoose, there is an error key not found.
The cache of RPackage is not updated.
what cache?
Any solution ?
Jannik
_______________________________________________
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:07 p.m.
On May 7, 2011, at 11:59 AM, Tudor Girba wrote:
Stef, you told us to load #stable and this is what we
are loading, and currently #stable loads '1.0'.
ok good then
That is why I asked on the Pharo mailing list if 3.0
is stable, so that #stable should point to it rather than to '1.0'.
ah ok yes I think that it is more stable
If you want this versioning scheme to work, you have
to take into account the energy to maintain the configuration. Otherwise, feedback will
always be out of date, and the dialog not very constructive.
Yes I maintain it do not worry.
However, I did some more tests and it seems that some desynchronization appears in 3.0 as
well, only I do not know how to reproduce the problem because I do not know where it comes
from.
Ok
I would like to know that too.
Cyrille, could you detail your finding for
documentation purpose?
Cheers,
Doru
On 7 May 2011, at 11:49, Stéphane Ducasse wrote:
I do not get it.
Don't you use the 3.0 version?
Because I do not know what is the 1.0 especially since you loaded latest so this measn
that I have no clue
what version is really loaded and I will not have a look because I cannot spend time
reverse engineer
working set of packages.
We started to sync with cyrille yesterday and I will merge his changes and produce a new
3.0 and a stable tag.
So that people can load stable and we can continue to work on the integration.
Stef
On May 7, 2011, at 11:21 AM, Tudor Girba wrote:
--
www.tudorgirba.com
"Sometimes the best solution is not the best solution."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev The issue is that the Organizer gets out of sync.
I do not know when, but I saw it happening. It is what I sent to the pharo mailing list:
---quote---
ConfigurationOfRPackage 1.0 seems to go out of sync with the image after a while. For
example, download the following Moose image:
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
and try
RPackage organizer packageNamed: 'Famix-Core'
---
Cheers,
Doru
On 7 May 2011, at 11:15, Stéphane Ducasse wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On May 6, 2011, at 3:25 PM, jannik.laval wrote:
> Hi,
>
> I think to have a bug with RPackage.
>
> I used MooseScripts>>createModelForMoose.
> This method works fine.
>
> then I removed 3 methods useless for Moose (see issue 614)
>
> When I rerun MooseScripts>>createModelForMoose, there is an error key not
found.
> The cache of RPackage is not updated.
what cache?
>
> Any solution ?
>
> Jannik
> _______________________________________________
> 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
"From an abstract enough point of view, any two things are similar."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:51 p.m.
Yes I fixed the bug. just left to modify the version of RPackage to load the
correct version of the modified package. I think stephane will do it while
looking at my changes.
2011/5/7 Stéphane Ducasse <stephane.ducasse(a)inria.fr>
On May 7, 2011, at 11:59 AM, Tudor Girba wrote:
Stef, you told us to load #stable and this is
what we are loading, and
currently #stable loads '1.0'.
ok good then
That is why I asked on the Pharo mailing list if
3.0 is stable, so that
#stable should point to it rather than to '1.0'.
ah ok yes I think that it is more stable
If you want this versioning scheme to work, you
have to take into account
the energy to maintain the configuration. Otherwise,
feedback will always be
out of date, and the dialog not very constructive.
Yes I maintain it do not worry.
However, I did some more tests and it seems that some desynchronization
appears in
3.0 as well, only I do not know how to reproduce the problem
because I do not know where it comes from.
Ok
I would like to know that too.
Cyrille, could you detail your finding for
documentation purpose?
Cheers,
Doru
On 7 May 2011, at 11:49, Stéphane Ducasse wrote:
> I do not get it.
> Don't you use the 3.0 version?
> Because I do not know what is the 1.0 especially since you loaded latest
so
this measn that I have no clue
> what version is really loaded and I will not
have a look because I
cannot spend time reverse engineer
> working set of packages.
> We started to sync with cyrille yesterday and I will merge his changes
and
produce a new 3.0 and a stable tag.
> So that people can load stable and we can
continue to work on the
integration.
>
> Stef
> On May 7, 2011, at 11:21 AM, Tudor Girba wrote:
>
>> The issue is that the Organizer gets out of sync. I do not know when,
but
I saw it happening. It is what I sent to the pharo mailing list:
>>
>> ---quote---
>>
>> ConfigurationOfRPackage 1.0 seems to go out of sync with the image
after a
while. For example, download the following Moose image:
>>
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
>>
>>> and try
>>> RPackage organizer packageNamed: 'Famix-Core'
>>
>>> ---
>>
>>> Cheers,
>>> Doru
>>
>>> On 7 May 2011, at
11:15, Stéphane Ducasse wrote:
>>
>>>>
>>>> On May 6, 2011, at 3:25 PM, jannik.laval wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I think to have a bug with RPackage.
>>>>>
>>>>> I used MooseScripts>>createModelForMoose.
>>>>> This method works fine.
>>>>>
>>>>> then I removed 3 methods useless for Moose (see issue 614)
>>>>>
>>>>> When I rerun MooseScripts>>createModelForMoose, there is an
error key
not found.
>>>>> The cache of RPackage is not updated.
>>>>
>>>> what cache?
>>>>>
>>>>> Any solution ?
>>>>>
>>>>> Jannik
>>>>> _______________________________________________
>>>>> 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
>>
>>> "From an
abstract enough point of view, any two things are similar."
>>
>>
>>
>>
>>>
_______________________________________________
>>> 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
>
> "Sometimes the best solution is not the best solution."
>
>
> _______________________________________________
> 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
5:26 p.m.
Hi,
Could you tell us what the bug was? It would be good to know just in case in the future we
encounter something similar.
Cheers,
Doru
On 7 May 2011, at 16:51, Cyrille Delaunay wrote:
Yes I fixed the bug. just left to modify the version
of RPackage to load the correct version of the modified package. I think stephane will do
it while looking at my changes.
2011/5/7 Stéphane Ducasse <stephane.ducasse(a)inria.fr>
On May 7, 2011, at 11:59 AM, Tudor Girba wrote:
--
www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the right
one."
Stef, you told us to load #stable and this is
what we are loading, and currently #stable loads '1.0'.
ok good then
That is why I asked on the Pharo mailing list if
3.0 is stable, so that #stable should point to it rather than to '1.0'.
ah ok yes I think that it is more stable
If you want this versioning scheme to work, you
have to take into account the energy to maintain the configuration. Otherwise, feedback
will always be out of date, and the dialog not very constructive.
Yes I maintain it do not worry.
However, I did some more tests and it seems that some desynchronization appears in 3.0 as
well, only I do not know how to reproduce the problem because I do not know where it comes
from.
Ok
I would like to know that too.
Cyrille, could you detail your finding for
documentation purpose?
Cheers,
Doru
On 7 May 2011, at 11:49, Stéphane Ducasse wrote:
_______________________________________________
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 I do not get it.
Don't you use the 3.0 version?
Because I do not know what is the 1.0 especially since you loaded latest so this measn
that I have no clue
what version is really loaded and I will not have a look because I cannot spend time
reverse engineer
working set of packages.
We started to sync with cyrille yesterday and I will merge his changes and produce a new
3.0 and a stable tag.
So that people can load stable and we can continue to work on the integration.
Stef
On May 7, 2011, at 11:21 AM, Tudor Girba wrote:
--
www.tudorgirba.com
"Sometimes the best solution is not the best solution."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev The issue is that the Organizer gets out of sync.
I do not know when, but I saw it happening. It is what I sent to the pharo mailing list:
---quote---
ConfigurationOfRPackage 1.0 seems to go out of sync with the image after a while. For
example, download the following Moose image:
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
and try
RPackage organizer packageNamed: 'Famix-Core'
---
Cheers,
Doru
On 7 May 2011, at 11:15, Stéphane Ducasse wrote:
>
> On May 6, 2011, at 3:25 PM, jannik.laval wrote:
>
>> Hi,
>>
>> I think to have a bug with RPackage.
>>
>> I used MooseScripts>>createModelForMoose.
>> This method works fine.
>>
>> then I removed 3 methods useless for Moose (see issue 614)
>>
>> When I rerun MooseScripts>>createModelForMoose, there is an error key not
found.
>> The cache of RPackage is not updated.
>
> what cache?
>>
>> Any solution ?
>>
>> Jannik
>> _______________________________________________
>> 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
"From an abstract enough point of view, any two things are similar."
_______________________________________________
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:49 p.m.
The bug appeared when removing two extensions methods (from the same
extending package) for a same class.
in RPackage >> removeMethod: , when removing an extension method, we were
telling the organizer to remove the extending package for the class
concerned. This was wrong, because even if one extension from this package
has been removed, some others can still exist. And the organizer should keep
the this package as extending package for the class.
So removing the first extension method worked correctly, but then removing a
second or more methods from the same package was raising some errors
2011/5/7 Tudor Girba <tudor.girba(a)gmail.com>
Hi,
Could you tell us what the bug was? It would be good to know just in case
in the future we encounter something similar.
Cheers,
Doru
On 7 May 2011, at 16:51, Cyrille Delaunay wrote:
Yes I fixed the bug. just left to modify the
version of RPackage to load
the correct version of the modified package. I think
stephane will do it
while looking at my changes.
2011/5/7 Stéphane Ducasse <stephane.ducasse(a)inria.fr>
On May 7, 2011, at 11:59 AM, Tudor Girba wrote:
> Stef, you told us to load #stable and this is what we are loading, and
currently #stable loads '1.0'.
ok good then
> That is why I asked on the Pharo mailing list if 3.0 is stable, so that
#stable should point to it rather than to '1.0'.
ah ok yes I think that it is more stable
> If you want this versioning scheme to work, you have to take into
account the
energy to maintain the configuration. Otherwise, feedback will
always be out of date, and the dialog not very constructive.
Yes I maintain it do not worry.
>
> However, I did some more tests and it seems that some desynchronization
appears in 3.0 as well, only I do not know how to reproduce the problem
because I do not know where it comes from.
Ok
I would like to know that too.
> Cyrille, could you detail your finding for documentation purpose?
>
> Cheers,
> Doru
>
>
> On 7 May 2011, at 11:49, Stéphane Ducasse wrote:
>
>> I do not get it.
>> Don't you use the 3.0 version?
>> Because I do not know what is the 1.0 especially since you loaded
latest
so this measn that I have no clue
>> what version is really loaded and I will
not have a look because I
cannot spend time reverse engineer
>> working set of packages.
>> We started to sync with cyrille yesterday and I will merge his changes
and produce a new 3.0 and a stable tag.
>> So that people can load stable and we
can continue to work on the
integration.
>>
>> Stef
>> On May 7, 2011, at 11:21 AM, Tudor Girba wrote:
>>
>>> The issue is that the Organizer gets out of sync. I do not know when,
but I saw it happening. It is what I sent to the pharo mailing list:
>>>
>>> ---quote---
>>>
>>> ConfigurationOfRPackage 1.0 seems to go out of sync with the image
after a while. For example, download the following Moose image:
>>>
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
>>>
> >>> and try
> >>> RPackage organizer packageNamed: 'Famix-Core'
>>>
> >>> ---
>>>
> >>> Cheers,
> >>> Doru
>>>
> >>> On 7 May
2011, at 11:15, Stéphane Ducasse wrote:
>>>
> >>>>
> >>>> On May 6, 2011, at 3:25 PM, jannik.laval wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I think to have a bug with RPackage.
> >>>>>
> >>>>> I used MooseScripts>>createModelForMoose.
> >>>>> This method works fine.
> >>>>>
> >>>>> then I removed 3 methods useless for Moose (see issue 614)
> >>>>>
> >>>>> When I rerun MooseScripts>>createModelForMoose, there is
an error
key not found.
> >>>>> The cache of RPackage is not updated.
> >>>>
> >>>> what cache?
> >>>>>
> >>>>> Any solution ?
> >>>>>
> >>>>> Jannik
> >>>>> _______________________________________________
> >>>>> 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
>>>
> >>> "From
an abstract enough point of view, any two things are similar."
>>>
>>>
>>>
>>>
> >>>
_______________________________________________
> >>> 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
> >
> > "Sometimes the best solution is not the best solution."
> >
> >
> > _______________________________________________
> > 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
--
www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the
right one."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:03 p.m.
On May 7, 2011, at 10:49 PM, Cyrille Delaunay wrote:
The bug appeared when removing two extensions methods
(from the same extending package) for a same class.
in RPackage >> removeMethod: , when removing an extension method, we were telling
the organizer to remove the extending package for the class concerned. This was wrong,
because even if one extension from this package has been removed, some others can still
exist. And the organizer should keep the this package as extending package for the class.
So removing the first extension method worked correctly, but then removing a second or
more methods from the same package was raising some errors
Thanks we should write a test for that.
Stef
2011/5/7 Tudor Girba <tudor.girba(a)gmail.com>
Hi,
Could you tell us what the bug was? It would be good to know just in case in the future
we encounter something similar.
Cheers,
Doru
On 7 May 2011, at 16:51, Cyrille Delaunay wrote:
Yes I fixed the bug. just left to modify the
version of RPackage to load the correct version of the modified package. I think stephane
will do it while looking at my changes.
2011/5/7 Stéphane Ducasse <stephane.ducasse(a)inria.fr>
On May 7, 2011, at 11:59 AM, Tudor Girba wrote:
--
www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the
right one."
_______________________________________________
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 Stef, you told us to load #stable and this is
what we are loading, and currently #stable loads '1.0'.
ok good then
That is why I asked on the Pharo mailing list if
3.0 is stable, so that #stable should point to it rather than to '1.0'.
ah ok yes I think that it is more stable
If you want this versioning scheme to work, you
have to take into account the energy to maintain the configuration. Otherwise, feedback
will always be out of date, and the dialog not very constructive.
Yes I maintain it do not worry.
However, I did some more tests and it seems that some desynchronization appears in 3.0 as
well, only I do not know how to reproduce the problem because I do not know where it comes
from.
Ok
I would like to know that too.
Cyrille, could you detail your finding for
documentation purpose?
Cheers,
Doru
On 7 May 2011, at 11:49, Stéphane Ducasse wrote:
_______________________________________________
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 I do not get it.
Don't you use the 3.0 version?
Because I do not know what is the 1.0 especially since you loaded latest so this measn
that I have no clue
what version is really loaded and I will not have a look because I cannot spend time
reverse engineer
working set of packages.
We started to sync with cyrille yesterday and I will merge his changes and produce a new
3.0 and a stable tag.
So that people can load stable and we can continue to work on the integration.
Stef
On May 7, 2011, at 11:21 AM, Tudor Girba wrote:
> The issue is that the Organizer gets out of sync. I do not know when, but I saw it
happening. It is what I sent to the pharo mailing list:
>
> ---quote---
>
> ConfigurationOfRPackage 1.0 seems to go out of sync with the image after a while. For
example, download the following Moose image:
>
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
>
> and try
> RPackage organizer packageNamed: 'Famix-Core'
>
> ---
>
> Cheers,
> Doru
>
> On 7 May 2011, at 11:15, Stéphane Ducasse wrote:
>
>>
>> On May 6, 2011, at 3:25 PM, jannik.laval wrote:
>>
>>> Hi,
>>>
>>> I think to have a bug with RPackage.
>>>
>>> I used MooseScripts>>createModelForMoose.
>>> This method works fine.
>>>
>>> then I removed 3 methods useless for Moose (see issue 614)
>>>
>>> When I rerun MooseScripts>>createModelForMoose, there is an error key
not found.
>>> The cache of RPackage is not updated.
>>
>> what cache?
>>>
>>> Any solution ?
>>>
>>> Jannik
>>> _______________________________________________
>>> 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
>
> "From an abstract enough point of view, any two things are similar."
>
>
>
>
> _______________________________________________
> 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
"Sometimes the best solution is not the best solution."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8 May
8 May
11:54 a.m.
Hi,
RPackage 3.0 is not stable :(.
1. there is a self halt in CompiledMethod>>packageFromOrganizer:
According to the flag, this self halt should not be reached. However, try loading the
following code after RPackage is loaded and you will see that the self halt is reached.
Gofer new
squeaksource: 'bifrost';
package: 'ConfigurationOfBifrost';
load.
(Smalltalk at: #ConfigurationOfBifrost)
perform: #loadDefault.
You can try to execute the above code in the latest moose-dev which already has the latest
3.0:
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
2. I tried to run the tests, and there are 3 errors
3. More important is that when running the tests you run several times into a deprecation
message related to RPackageOrganizer>>includesClass: being deprecated.
This shows me that the tests were not run in a while.
We cannot release Moose without RPackage. Please let us work on this.
Cheers,
Doru
On 7 May 2011, at 23:03, Stéphane Ducasse wrote:
On May 7, 2011, at 10:49 PM, Cyrille Delaunay wrote:
--
www.tudorgirba.com
"Value is always contextual."
The bug appeared when removing two extensions
methods (from the same extending package) for a same class.
in RPackage >> removeMethod: , when removing an extension method, we were telling
the organizer to remove the extending package for the class concerned. This was wrong,
because even if one extension from this package has been removed, some others can still
exist. And the organizer should keep the this package as extending package for the class.
So removing the first extension method worked correctly, but then removing a second or
more methods from the same package was raising some errors
Thanks we should write a test for that.
Stef
2011/5/7 Tudor Girba <tudor.girba(a)gmail.com>
Hi,
Could you tell us what the bug was? It would be good to know just in case in the future
we encounter something similar.
Cheers,
Doru
On 7 May 2011, at 16:51, Cyrille Delaunay wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Yes I fixed the bug. just left to modify the
version of RPackage to load the correct version of the modified package. I think stephane
will do it while looking at my changes.
2011/5/7 Stéphane Ducasse <stephane.ducasse(a)inria.fr>
On May 7, 2011, at 11:59 AM, Tudor Girba wrote:
--
www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the
right one."
_______________________________________________
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 Stef, you told us to load #stable and this is
what we are loading, and currently #stable loads '1.0'.
ok good then
That is why I asked on the Pharo mailing list if
3.0 is stable, so that #stable should point to it rather than to '1.0'.
ah ok yes I think that it is more stable
If you want this versioning scheme to work, you
have to take into account the energy to maintain the configuration. Otherwise, feedback
will always be out of date, and the dialog not very constructive.
Yes I maintain it do not worry.
However, I did some more tests and it seems that some desynchronization appears in 3.0 as
well, only I do not know how to reproduce the problem because I do not know where it comes
from.
Ok
I would like to know that too.
Cyrille, could you detail your finding for
documentation purpose?
Cheers,
Doru
On 7 May 2011, at 11:49, Stéphane Ducasse wrote:
> I do not get it.
> Don't you use the 3.0 version?
> Because I do not know what is the 1.0 especially since you loaded latest so this
measn that I have no clue
> what version is really loaded and I will not have a look because I cannot spend time
reverse engineer
> working set of packages.
> We started to sync with cyrille yesterday and I will merge his changes and produce a
new 3.0 and a stable tag.
> So that people can load stable and we can continue to work on the integration.
>
> Stef
> On May 7, 2011, at 11:21 AM, Tudor Girba wrote:
>
>> The issue is that the Organizer gets out of sync. I do not know when, but I saw
it happening. It is what I sent to the pharo mailing list:
>>
>> ---quote---
>>
>> ConfigurationOfRPackage 1.0 seems to go out of sync with the image after a while.
For example, download the following Moose image:
>>
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
>>
>> and try
>> RPackage organizer packageNamed: 'Famix-Core'
>>
>> ---
>>
>> Cheers,
>> Doru
>>
>> On 7 May 2011, at 11:15, Stéphane Ducasse wrote:
>>
>>>
>>> On May 6, 2011, at 3:25 PM, jannik.laval wrote:
>>>
>>>> Hi,
>>>>
>>>> I think to have a bug with RPackage.
>>>>
>>>> I used MooseScripts>>createModelForMoose.
>>>> This method works fine.
>>>>
>>>> then I removed 3 methods useless for Moose (see issue 614)
>>>>
>>>> When I rerun MooseScripts>>createModelForMoose, there is an error
key not found.
>>>> The cache of RPackage is not updated.
>>>
>>> what cache?
>>>>
>>>> Any solution ?
>>>>
>>>> Jannik
>>>> _______________________________________________
>>>> 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
>>
>> "From an abstract enough point of view, any two things are similar."
>>
>>
>>
>>
>> _______________________________________________
>> 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
"Sometimes the best solution is not the best solution."
_______________________________________________
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
2:25 p.m.
I can revert to 1.0 if this is simpler for you
RPackage 3.0 is not stable :(.
1. there is a self halt in CompiledMethod>>packageFromOrganizer:
According to the flag, this self halt should not be reached. However, try loading the
following code after RPackage is loaded and you will see that the self halt is reached.
Gofer new
squeaksource: 'bifrost';
package: 'ConfigurationOfBifrost';
load.
(Smalltalk at: #ConfigurationOfBifrost)
perform: #loadDefault.
You can try to execute the above code in the latest moose-dev which already has the
latest 3.0:
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
2. I tried to run the tests, and there are 3 errors
3. More important is that when running the tests you run several times into a deprecation
message related to RPackageOrganizer>>includesClass: being deprecated.
I do not understand why because when I take the latest pharo I do not see it.
I will fix that
This shows me that the tests were not run in a while.
We cannot release Moose without RPackage. Please let us work on this.
Cheers,
Doru
On 7 May 2011, at 23:03, Stéphane Ducasse wrote:
On May 7, 2011, at 10:49 PM, Cyrille Delaunay wrote:
--
www.tudorgirba.com
"Value is always contextual."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev The bug appeared when removing two extensions
methods (from the same extending package) for a same class.
in RPackage >> removeMethod: , when removing an extension method, we were telling
the organizer to remove the extending package for the class concerned. This was wrong,
because even if one extension from this package has been removed, some others can still
exist. And the organizer should keep the this package as extending package for the class.
So removing the first extension method worked correctly, but then removing a second or
more methods from the same package was raising some errors
Thanks we should write a test for that.
Stef
2011/5/7 Tudor Girba <tudor.girba(a)gmail.com>
Hi,
Could you tell us what the bug was? It would be good to know just in case in the future
we encounter something similar.
Cheers,
Doru
On 7 May 2011, at 16:51, Cyrille Delaunay wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Yes I fixed the bug. just left to modify the
version of RPackage to load the correct version of the modified package. I think stephane
will do it while looking at my changes.
2011/5/7 Stéphane Ducasse <stephane.ducasse(a)inria.fr>
On May 7, 2011, at 11:59 AM, Tudor Girba wrote:
> Stef, you told us to load #stable and this is what we are loading, and currently
#stable loads '1.0'.
ok good then
> That is why I asked on the Pharo mailing list if 3.0 is stable, so that #stable
should point to it rather than to '1.0'.
ah ok yes I think that it is more stable
> If you want this versioning scheme to work, you have to take into account the energy
to maintain the configuration. Otherwise, feedback will always be out of date, and the
dialog not very constructive.
Yes I maintain it do not worry.
>
> However, I did some more tests and it seems that some desynchronization appears in
3.0 as well, only I do not know how to reproduce the problem because I do not know where
it comes from.
Ok
I would like to know that too.
> Cyrille, could you detail your finding for documentation purpose?
>
> Cheers,
> Doru
>
>
> On 7 May 2011, at 11:49, Stéphane Ducasse wrote:
>
>> I do not get it.
>> Don't you use the 3.0 version?
>> Because I do not know what is the 1.0 especially since you loaded latest so this
measn that I have no clue
>> what version is really loaded and I will not have a look because I cannot spend
time reverse engineer
>> working set of packages.
>> We started to sync with cyrille yesterday and I will merge his changes and
produce a new 3.0 and a stable tag.
>> So that people can load stable and we can continue to work on the integration.
>>
>> Stef
>> On May 7, 2011, at 11:21 AM, Tudor Girba wrote:
>>
>>> The issue is that the Organizer gets out of sync. I do not know when, but I
saw it happening. It is what I sent to the pharo mailing list:
>>>
>>> ---quote---
>>>
>>> ConfigurationOfRPackage 1.0 seems to go out of sync with the image after a
while. For example, download the following Moose image:
>>>
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
>>>
>>> and try
>>> RPackage organizer packageNamed: 'Famix-Core'
>>>
>>> ---
>>>
>>> Cheers,
>>> Doru
>>>
>>> On 7 May 2011, at 11:15, Stéphane Ducasse wrote:
>>>
>>>>
>>>> On May 6, 2011, at 3:25 PM, jannik.laval wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I think to have a bug with RPackage.
>>>>>
>>>>> I used MooseScripts>>createModelForMoose.
>>>>> This method works fine.
>>>>>
>>>>> then I removed 3 methods useless for Moose (see issue 614)
>>>>>
>>>>> When I rerun MooseScripts>>createModelForMoose, there is an
error key not found.
>>>>> The cache of RPackage is not updated.
>>>>
>>>> what cache?
>>>>>
>>>>> Any solution ?
>>>>>
>>>>> Jannik
>>>>> _______________________________________________
>>>>> 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
>>>
>>> "From an abstract enough point of view, any two things are
similar."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> "Sometimes the best solution is not the best solution."
>
>
> _______________________________________________
> 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
--
www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the
right one."
_______________________________________________
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
2:38 p.m.
Hi Stef,
On 8 May 2011, at 14:25, Stéphane Ducasse wrote:
For example, look at
RPackageMCSynchronisationTest>>testRemoveClassUpdateTheorganizer. This test is
directly calling the deprecated RPackageOrganizer>>includesClass:
Cheers,
Doru
--
www.tudorgirba.com
"Yesterday is a fact.
Tomorrow is a possibility.
Today is a challenge."
I can revert to 1.0 if this is simpler for you
1.0 is broken as well as mentioned before. So, it looks like we are stuck :(.
RPackage 3.0
is not stable :(.
1. there is a self halt in CompiledMethod>>packageFromOrganizer:
According to the flag, this self halt should not be reached. However, try loading the
following code after RPackage is loaded and you will see that the self halt is reached.
Gofer new
squeaksource: 'bifrost';
package: 'ConfigurationOfBifrost';
load.
(Smalltalk at: #ConfigurationOfBifrost)
perform: #loadDefault.
You can try to execute the above code in the latest moose-dev which already has the
latest 3.0:
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
2. I tried to run the tests, and there are 3 errors
3. More important is that when running the tests you run several times into a deprecation
message related to RPackageOrganizer>>includesClass: being deprecated.
I do not understand why because when I take the latest pharo I do not see it.
I will fix that
This shows me that the tests were not run in a while.
We cannot release Moose without RPackage. Please let us work on this.
Cheers,
Doru
On 7 May 2011, at 23:03, Stéphane Ducasse wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On May 7, 2011, at 10:49 PM, Cyrille Delaunay wrote:
--
www.tudorgirba.com
"Value is always contextual."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev The bug appeared when removing two extensions
methods (from the same extending package) for a same class.
in RPackage >> removeMethod: , when removing an extension method, we were telling
the organizer to remove the extending package for the class concerned. This was wrong,
because even if one extension from this package has been removed, some others can still
exist. And the organizer should keep the this package as extending package for the class.
So removing the first extension method worked correctly, but then removing a second or
more methods from the same package was raising some errors
Thanks we should write a test for that.
Stef
2011/5/7 Tudor Girba <tudor.girba(a)gmail.com>
Hi,
Could you tell us what the bug was? It would be good to know just in case in the future
we encounter something similar.
Cheers,
Doru
On 7 May 2011, at 16:51, Cyrille Delaunay wrote:
> Yes I fixed the bug. just left to modify the version of RPackage to load the correct
version of the modified package. I think stephane will do it while looking at my changes.
>
> 2011/5/7 Stéphane Ducasse <stephane.ducasse(a)inria.fr>
>
> On May 7, 2011, at 11:59 AM, Tudor Girba wrote:
>
>> Stef, you told us to load #stable and this is what we are loading, and currently
#stable loads '1.0'.
>
> ok good then
>
>> That is why I asked on the Pharo mailing list if 3.0 is stable, so that #stable
should point to it rather than to '1.0'.
>
> ah ok yes I think that it is more stable
>
>> If you want this versioning scheme to work, you have to take into account the
energy to maintain the configuration. Otherwise, feedback will always be out of date, and
the dialog not very constructive.
>
> Yes I maintain it do not worry.
>
>>
>> However, I did some more tests and it seems that some desynchronization appears
in 3.0 as well, only I do not know how to reproduce the problem because I do not know
where it comes from.
>
> Ok
> I would like to know that too.
>
>> Cyrille, could you detail your finding for documentation purpose?
>>
>> Cheers,
>> Doru
>>
>>
>> On 7 May 2011, at 11:49, Stéphane Ducasse wrote:
>>
>>> I do not get it.
>>> Don't you use the 3.0 version?
>>> Because I do not know what is the 1.0 especially since you loaded latest so
this measn that I have no clue
>>> what version is really loaded and I will not have a look because I cannot
spend time reverse engineer
>>> working set of packages.
>>> We started to sync with cyrille yesterday and I will merge his changes and
produce a new 3.0 and a stable tag.
>>> So that people can load stable and we can continue to work on the
integration.
>>>
>>> Stef
>>> On May 7, 2011, at 11:21 AM, Tudor Girba wrote:
>>>
>>>> The issue is that the Organizer gets out of sync. I do not know when, but
I saw it happening. It is what I sent to the pharo mailing list:
>>>>
>>>> ---quote---
>>>>
>>>> ConfigurationOfRPackage 1.0 seems to go out of sync with the image after
a while. For example, download the following Moose image:
>>>>
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
>>>>
>>>> and try
>>>> RPackage organizer packageNamed: 'Famix-Core'
>>>>
>>>> ---
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>> On 7 May 2011, at 11:15, Stéphane Ducasse wrote:
>>>>
>>>>>
>>>>> On May 6, 2011, at 3:25 PM, jannik.laval wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I think to have a bug with RPackage.
>>>>>>
>>>>>> I used MooseScripts>>createModelForMoose.
>>>>>> This method works fine.
>>>>>>
>>>>>> then I removed 3 methods useless for Moose (see issue 614)
>>>>>>
>>>>>> When I rerun MooseScripts>>createModelForMoose, there is an
error key not found.
>>>>>> The cache of RPackage is not updated.
>>>>>
>>>>> what cache?
>>>>>>
>>>>>> Any solution ?
>>>>>>
>>>>>> Jannik
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>> "From an abstract enough point of view, any two things are
similar."
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> "Sometimes the best solution is not the best solution."
>>
>>
>> _______________________________________________
>> 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
--
www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the
right one."
_______________________________________________
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:18 p.m.
Doru
I fixed the deprecation and I'm starting to investigate the problems. I will focus on
- RPAckageOrganizer better unregisterAPI
- biforst problem
- writing tests for
"The bug appeared when removing two extensions methods (from the same extending
package) for a
same class. in RPackage >> removeMethod: , when removing an extension method, we
were telling the
organizer to remove the extending package for the class concerned. This was wrong,
because even if one
extension from this package has been removed, some others can still exist. And the
organizer should keep
the this package as extending package for the class. So removing the first extension
method worked
correctly, but then removing a second or more methods from the same package was raising
some errors "
- CompiledMethod>>packageFromOrganizer:
Stef
On May 8, 2011, at 2:38 PM, Tudor Girba wrote:
Hi Stef,
On 8 May 2011, at 14:25, Stéphane Ducasse wrote:
For example, look at
RPackageMCSynchronisationTest>>testRemoveClassUpdateTheorganizer. This test is
directly calling the deprecated RPackageOrganizer>>includesClass:
Cheers,
Doru
--
www.tudorgirba.com
"Yesterday is a fact.
Tomorrow is a possibility.
Today is a challenge."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I can revert to 1.0 if this is simpler for you
1.0 is broken as well as mentioned before. So, it looks like we are stuck :(.
RPackage
3.0 is not stable :(.
1. there is a self halt in CompiledMethod>>packageFromOrganizer:
According to the flag, this self halt should not be reached. However, try loading the
following code after RPackage is loaded and you will see that the self halt is reached.
Gofer new
squeaksource: 'bifrost';
package: 'ConfigurationOfBifrost';
load.
(Smalltalk at: #ConfigurationOfBifrost)
perform: #loadDefault.
You can try to execute the above code in the latest moose-dev which already has the
latest 3.0:
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
2. I tried to run the tests, and there are 3 errors
3. More important is that when running the tests you run several times into a deprecation
message related to RPackageOrganizer>>includesClass: being deprecated.
I do not understand why because when I take the latest pharo I do not see it.
I will fix that
This shows me that the tests were not run in a while.
We cannot release Moose without RPackage. Please let us work on this.
Cheers,
Doru
On 7 May 2011, at 23:03, Stéphane Ducasse wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On May 7, 2011, at 10:49 PM, Cyrille Delaunay wrote:
> The bug appeared when removing two extensions methods (from the same extending
package) for a same class.
> in RPackage >> removeMethod: , when removing an extension method, we were
telling the organizer to remove the extending package for the class concerned. This was
wrong, because even if one extension from this package has been removed, some others can
still exist. And the organizer should keep the this package as extending package for the
class.
> So removing the first extension method worked correctly, but then removing a second
or more methods from the same package was raising some errors
Thanks we should write a test for that.
Stef
>
> 2011/5/7 Tudor Girba <tudor.girba(a)gmail.com>
> Hi,
>
> Could you tell us what the bug was? It would be good to know just in case in the
future we encounter something similar.
>
> Cheers,
> Doru
>
>
> On 7 May 2011, at 16:51, Cyrille Delaunay wrote:
>
>> Yes I fixed the bug. just left to modify the version of RPackage to load the
correct version of the modified package. I think stephane will do it while looking at my
changes.
>>
>> 2011/5/7 Stéphane Ducasse <stephane.ducasse(a)inria.fr>
>>
>> On May 7, 2011, at 11:59 AM, Tudor Girba wrote:
>>
>>> Stef, you told us to load #stable and this is what we are loading, and
currently #stable loads '1.0'.
>>
>> ok good then
>>
>>> That is why I asked on the Pharo mailing list if 3.0 is stable, so that
#stable should point to it rather than to '1.0'.
>>
>> ah ok yes I think that it is more stable
>>
>>> If you want this versioning scheme to work, you have to take into account the
energy to maintain the configuration. Otherwise, feedback will always be out of date, and
the dialog not very constructive.
>>
>> Yes I maintain it do not worry.
>>
>>>
>>> However, I did some more tests and it seems that some desynchronization
appears in 3.0 as well, only I do not know how to reproduce the problem because I do not
know where it comes from.
>>
>> Ok
>> I would like to know that too.
>>
>>> Cyrille, could you detail your finding for documentation purpose?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> On 7 May 2011, at 11:49, Stéphane Ducasse wrote:
>>>
>>>> I do not get it.
>>>> Don't you use the 3.0 version?
>>>> Because I do not know what is the 1.0 especially since you loaded latest
so this measn that I have no clue
>>>> what version is really loaded and I will not have a look because I cannot
spend time reverse engineer
>>>> working set of packages.
>>>> We started to sync with cyrille yesterday and I will merge his changes
and produce a new 3.0 and a stable tag.
>>>> So that people can load stable and we can continue to work on the
integration.
>>>>
>>>> Stef
>>>> On May 7, 2011, at 11:21 AM, Tudor Girba wrote:
>>>>
>>>>> The issue is that the Organizer gets out of sync. I do not know when,
but I saw it happening. It is what I sent to the pharo mailing list:
>>>>>
>>>>> ---quote---
>>>>>
>>>>> ConfigurationOfRPackage 1.0 seems to go out of sync with the image
after a while. For example, download the following Moose image:
>>>>>
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
>>>>>
>>>>> and try
>>>>> RPackage organizer packageNamed: 'Famix-Core'
>>>>>
>>>>> ---
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>> On 7 May 2011, at 11:15, Stéphane Ducasse wrote:
>>>>>
>>>>>>
>>>>>> On May 6, 2011, at 3:25 PM, jannik.laval wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I think to have a bug with RPackage.
>>>>>>>
>>>>>>> I used MooseScripts>>createModelForMoose.
>>>>>>> This method works fine.
>>>>>>>
>>>>>>> then I removed 3 methods useless for Moose (see issue 614)
>>>>>>>
>>>>>>> When I rerun MooseScripts>>createModelForMoose, there
is an error key not found.
>>>>>>> The cache of RPackage is not updated.
>>>>>>
>>>>>> what cache?
>>>>>>>
>>>>>>> Any solution ?
>>>>>>>
>>>>>>> Jannik
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>> "From an abstract enough point of view, any two things are
similar."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> "Sometimes the best solution is not the best solution."
>>>
>>>
>>> _______________________________________________
>>> 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
>
> --
> www.tudorgirba.com
>
> "Every now and then stop and ask yourself if the war you're fighting is the
right one."
>
>
>
>
> _______________________________________________
> 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
--
www.tudorgirba.com
"Value is always contextual."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:42 p.m.
On May 8, 2011, at 4:18 PM, Stéphane Ducasse wrote:
>>> Gofer new
>>> squeaksource: 'bifrost';
>>> package: 'ConfigurationOfBifrost';
>>> load.
>>> (Smalltalk at: #ConfigurationOfBifrost)
>>> perform: #loadDefault.
Ok I will load Rpackage in moose and see.
This package depends on the following classes:
GLMBrowserTemplate
You must resolve these dependencies before you will be able to load these definitions:
BFAllMetaObjectsBrowser
BFAllMetaObjectsBrowser>>buildBrowser
BFMetaObjectBrowser
BFMetaObjectBrowser>>buildBrowser
BFObjectMethodsBrowser
BFObjectMethodsBrowser>>buildBrowser
Select Proceed to continue, or close this window to cancel the operation.
5:01 p.m.
It may be due to overrides made by *ast-compiler-overrides.
The unfound method compilerClass is defined in *ast-compiler-overrides.
Since overrides are broken in MC, RPackage does not deal with them.
Now we should see what we should do but again all the crap of MC will flow into
RPackage....
bad bad bad idea.
Stef
On May 8, 2011, at 2:38 PM, Tudor Girba wrote:
Hi Stef,
On 8 May 2011, at 14:25, Stéphane Ducasse wrote:
For example, look at
RPackageMCSynchronisationTest>>testRemoveClassUpdateTheorganizer. This test is
directly calling the deprecated RPackageOrganizer>>includesClass:
Cheers,
Doru
--
www.tudorgirba.com
"Yesterday is a fact.
Tomorrow is a possibility.
Today is a challenge."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I can revert to 1.0 if this is simpler for you
1.0 is broken as well as mentioned before. So, it looks like we are stuck :(.
RPackage
3.0 is not stable :(.
1. there is a self halt in CompiledMethod>>packageFromOrganizer:
According to the flag, this self halt should not be reached. However, try loading the
following code after RPackage is loaded and you will see that the self halt is reached.
Gofer new
squeaksource: 'bifrost';
package: 'ConfigurationOfBifrost';
load.
(Smalltalk at: #ConfigurationOfBifrost)
perform: #loadDefault.
You can try to execute the above code in the latest moose-dev which already has the
latest 3.0:
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
2. I tried to run the tests, and there are 3 errors
3. More important is that when running the tests you run several times into a deprecation
message related to RPackageOrganizer>>includesClass: being deprecated.
I do not understand why because when I take the latest pharo I do not see it.
I will fix that
This shows me that the tests were not run in a while.
We cannot release Moose without RPackage. Please let us work on this.
Cheers,
Doru
On 7 May 2011, at 23:03, Stéphane Ducasse wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On May 7, 2011, at 10:49 PM, Cyrille Delaunay wrote:
> The bug appeared when removing two extensions methods (from the same extending
package) for a same class.
> in RPackage >> removeMethod: , when removing an extension method, we were
telling the organizer to remove the extending package for the class concerned. This was
wrong, because even if one extension from this package has been removed, some others can
still exist. And the organizer should keep the this package as extending package for the
class.
> So removing the first extension method worked correctly, but then removing a second
or more methods from the same package was raising some errors
Thanks we should write a test for that.
Stef
>
> 2011/5/7 Tudor Girba <tudor.girba(a)gmail.com>
> Hi,
>
> Could you tell us what the bug was? It would be good to know just in case in the
future we encounter something similar.
>
> Cheers,
> Doru
>
>
> On 7 May 2011, at 16:51, Cyrille Delaunay wrote:
>
>> Yes I fixed the bug. just left to modify the version of RPackage to load the
correct version of the modified package. I think stephane will do it while looking at my
changes.
>>
>> 2011/5/7 Stéphane Ducasse <stephane.ducasse(a)inria.fr>
>>
>> On May 7, 2011, at 11:59 AM, Tudor Girba wrote:
>>
>>> Stef, you told us to load #stable and this is what we are loading, and
currently #stable loads '1.0'.
>>
>> ok good then
>>
>>> That is why I asked on the Pharo mailing list if 3.0 is stable, so that
#stable should point to it rather than to '1.0'.
>>
>> ah ok yes I think that it is more stable
>>
>>> If you want this versioning scheme to work, you have to take into account the
energy to maintain the configuration. Otherwise, feedback will always be out of date, and
the dialog not very constructive.
>>
>> Yes I maintain it do not worry.
>>
>>>
>>> However, I did some more tests and it seems that some desynchronization
appears in 3.0 as well, only I do not know how to reproduce the problem because I do not
know where it comes from.
>>
>> Ok
>> I would like to know that too.
>>
>>> Cyrille, could you detail your finding for documentation purpose?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> On 7 May 2011, at 11:49, Stéphane Ducasse wrote:
>>>
>>>> I do not get it.
>>>> Don't you use the 3.0 version?
>>>> Because I do not know what is the 1.0 especially since you loaded latest
so this measn that I have no clue
>>>> what version is really loaded and I will not have a look because I cannot
spend time reverse engineer
>>>> working set of packages.
>>>> We started to sync with cyrille yesterday and I will merge his changes
and produce a new 3.0 and a stable tag.
>>>> So that people can load stable and we can continue to work on the
integration.
>>>>
>>>> Stef
>>>> On May 7, 2011, at 11:21 AM, Tudor Girba wrote:
>>>>
>>>>> The issue is that the Organizer gets out of sync. I do not know when,
but I saw it happening. It is what I sent to the pharo mailing list:
>>>>>
>>>>> ---quote---
>>>>>
>>>>> ConfigurationOfRPackage 1.0 seems to go out of sync with the image
after a while. For example, download the following Moose image:
>>>>>
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
>>>>>
>>>>> and try
>>>>> RPackage organizer packageNamed: 'Famix-Core'
>>>>>
>>>>> ---
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>> On 7 May 2011, at 11:15, Stéphane Ducasse wrote:
>>>>>
>>>>>>
>>>>>> On May 6, 2011, at 3:25 PM, jannik.laval wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I think to have a bug with RPackage.
>>>>>>>
>>>>>>> I used MooseScripts>>createModelForMoose.
>>>>>>> This method works fine.
>>>>>>>
>>>>>>> then I removed 3 methods useless for Moose (see issue 614)
>>>>>>>
>>>>>>> When I rerun MooseScripts>>createModelForMoose, there
is an error key not found.
>>>>>>> The cache of RPackage is not updated.
>>>>>>
>>>>>> what cache?
>>>>>>>
>>>>>>> Any solution ?
>>>>>>>
>>>>>>> Jannik
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>> "From an abstract enough point of view, any two things are
similar."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> "Sometimes the best solution is not the best solution."
>>>
>>>
>>> _______________________________________________
>>> 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
>
> --
> www.tudorgirba.com
>
> "Every now and then stop and ask yourself if the war you're fighting is the
right one."
>
>
>
>
> _______________________________________________
> 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
--
www.tudorgirba.com
"Value is always contextual."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:04 p.m.
In MC we have
- AST-Core
- AST-Semantic
but no
- AST-Compiler- whatever
so when we get *AST-Compiler-Overrides..... clearly this is a problem.
How RPackage should magically guess?
I will try to provide a better report first.
I will see but we should probably code a little tool to validate all the packages in
Pharo.
Stef
5:58 p.m.
Hi,
On 8 May 2011, at 17:04, Stéphane Ducasse wrote:
In MC we have
- AST-Core
- AST-Semantic
but no
- AST-Compiler- whatever
so when we get *AST-Compiler-Overrides..... clearly this is a problem.
I see.
How RPackage should magically guess?
Good question :). What is wrong with treating AST-Compiler-Overrides as an RPackage?
Cheers,
Doru
I will try to provide a better report first.
I will see but we should probably code a little tool to validate all the packages in
Pharo.
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Relationships are of two kinds: those we choose and those that happen. They both
matter."
6:25 p.m.
On May 8, 2011, at 5:58 PM, Tudor Girba wrote:
Hi,
On 8 May 2011, at 17:04, Stéphane Ducasse wrote:
Yes this is probably what we will have to do.... been more robust :(
In MC we have
- AST-Core
- AST-Semantic
but no
- AST-Compiler- whatever
so when we get *AST-Compiler-Overrides..... clearly this is a problem.
I see.
How RPackage should magically guess?
Good question :). What is wrong with treating AST-Compiler-Overrides as an RPackage?
5:45 p.m.
Hi doru
in fact with the Moose image I cannot even browse a package. I think that this has nothing
to
do with RPackage.
Apparently RBMethodNode>>resetCache has a nil category but I'm wondering if this
is not just in Bifrost.
So I will create a check for that too.
Stef
5:54 p.m.
Hi Stef,
On 8 May 2011, at 17:45, Stéphane Ducasse wrote:
Hi doru
in fact with the Moose image I cannot even browse a package. I think that this has
nothing to
do with RPackage.
What do you mean? I can browse everything well in the original moose-dev.
Apparently RBMethodNode>>resetCache has a nil
category but I'm wondering if this is not just in Bifrost.
So I will create a check for that too.
Bifrost is not loaded in moose-dev.
Cheers,
Doru
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
6:26 p.m.
Hi doru
yes I know but I tried to load it to find the bug.
after that the image was fucked up
Stef
in fact with the Moose image I cannot even browse a package. I think that this has
nothing to
do with RPackage.
What do you mean? I can browse everything well in the original moose-dev.
Apparently RBMethodNode>>resetCache has a
nil category but I'm wondering if this is not just in Bifrost.
So I will create a check for that too.
Bifrost is not loaded in moose-dev.
6:28 p.m.
On 8 May 2011, at 18:26, Stéphane Ducasse wrote:
Ah yes. And sometimes, even if you can browse, you get a debugger when accepting a method
:)
Cheers,
Doru
Hi doru
yes I know but I tried to load it to find the bug.
after that the image was fucked up
in fact with the Moose image I cannot even browse a package. I think that this has
nothing to
do with RPackage.
What do you mean? I can browse everything well in the original moose-dev.
Apparently RBMethodNode>>resetCache has a
nil category but I'm wondering if this is not just in Bifrost.
So I will create a check for that too.
Bifrost is not loaded in moose-dev. Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Value is always contextual."
4:13 p.m.
3. More important is that when running the tests you run several times into a deprecation
message related to RPackageOrganizer>>includesClass: being deprecated.
This shows me that the tests were not run in a while.
The tests are always run. I do not publish without releasing and I do not start to work if
they are not green.
Now this problem is easy and fixed.
Stef
9 May
9 May
6:16 p.m.
2011/5/8 Tudor Girba <tudor.girba(a)gmail.com>
Hi,
RPackage 3.0 is not stable :(.
1. there is a self halt in CompiledMethod>>packageFromOrganizer:
According to the flag, this self halt should not be reached. However, try
loading the following code after RPackage is loaded and you will see that
the self halt is reached.
Gofer new
squeaksource: 'bifrost';
package: 'ConfigurationOfBifrost';
load.
(Smalltalk at: #ConfigurationOfBifrost)
perform: #loadDefault.
You can try to execute the above code in the latest moose-dev which already
has the latest 3.0:
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
2. I tried to run the tests, and there are 3 errors
Those 3 errors are linked to the change in the announcemments implementation
in 1.3. They are green in 1.3
3. More important is that when running the tests you run several times into
a deprecation message related to RPackageOrganizer>>includesClass: being
deprecated.
This shows me that the tests were not run in a while.
We cannot release Moose without RPackage. Please let us work on this.
Cheers,
Doru
On 7 May 2011, at 23:03, Stéphane Ducasse wrote:
--
www.tudorgirba.com
"Value is always contextual."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On May 7, 2011, at 10:49 PM, Cyrille Delaunay wrote:
> The bug appeared when removing two extensions methods (from the same
extending
package) for a same class.
> in RPackage >> removeMethod: , when
removing an extension method, we
were telling the organizer to remove the extending
package for the class
concerned. This was wrong, because even if one extension from this package
has been removed, some others can still exist. And the organizer should keep
the this package as extending package for the class.
> So removing the first extension method worked
correctly, but then
removing a second or more methods from the same package was
raising some
errors
Thanks we should write a test for that.
Stef
>
> 2011/5/7 Tudor Girba <tudor.girba(a)gmail.com>
> Hi,
>
> Could you tell us what the bug was? It would be good to know just in
case in
the future we encounter something similar.
>
> Cheers,
> Doru
>
>
> On 7 May 2011, at 16:51, Cyrille Delaunay wrote:
>
>> Yes I fixed the bug. just left to modify the version of RPackage to
load
the correct version of the modified package. I think stephane will do
it while looking at my changes.
>>
>> 2011/5/7 Stéphane Ducasse <stephane.ducasse(a)inria.fr>
>>
>> On May 7, 2011, at 11:59 AM, Tudor Girba wrote:
>>
>>> Stef, you told us to load #stable and this is what we are loading, and
currently #stable loads '1.0'.
>>
>> ok good then
>>
>>> That is why I asked on the Pharo mailing list if 3.0 is stable, so
that #stable should point to it rather than to '1.0'.
>>
>> ah ok yes I think that it is more stable
>>
>>> If you want this versioning scheme to work, you have to take into
account the energy to maintain the configuration. Otherwise, feedback will
always be out of date, and the dialog not very constructive.
>>
>> Yes I maintain it do not worry.
>>
>>>
>>> However, I did some more tests and it seems that some
desynchronization appears in 3.0 as well, only I do not know how to
reproduce the problem because I do not know where it comes from.
>>
>> Ok
>> I would like to know that too.
>>
>>> Cyrille, could you detail your finding for documentation purpose?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> On 7 May 2011, at 11:49, Stéphane Ducasse wrote:
>>>
>>>> I do not get it.
>>>> Don't you use the 3.0 version?
>>>> Because I do not know what is the 1.0 especially since you loaded
latest so this measn that I have no clue
>>>> what version is really loaded and
I will not have a look because I
cannot spend time reverse engineer
>>>> working set of packages.
>>>> We started to sync with cyrille yesterday and I will merge his
changes and produce a new 3.0 and a stable tag.
>>>> So that people can load stable
and we can continue to work on the
integration.
>>>>
>>>> Stef
>>>> On May 7, 2011, at 11:21 AM, Tudor Girba wrote:
>>>>
>>>>> The issue is that the Organizer gets out of sync. I do not know
when, but I saw it happening. It is what I sent to the pharo mailing list:
>>>>>
>>>>> ---quote---
>>>>>
>>>>> ConfigurationOfRPackage 1.0 seems to go out of sync with the image
after a while. For example, download the following Moose image:
>>>>>
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
>>>>>
>>>>>> and try
>>>>>> RPackage organizer packageNamed: 'Famix-Core'
>>>>>
>>>>>> ---
>>>>>
>>>>>> Cheers,
>>>>>> Doru
>>>>>
>>>>>> On 7 May 2011, at 11:15, Stéphane Ducasse wrote:
>>>>>
>>>>>>>
>>>>>>> On May 6, 2011, at 3:25 PM, jannik.laval wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I think to have a bug with RPackage.
>>>>>>>>
>>>>>>>> I used MooseScripts>>createModelForMoose.
>>>>>>>> This method works fine.
>>>>>>>>
>>>>>>>> then I removed 3 methods useless for Moose (see issue
614)
>>>>>>>>
>>>>>>>> When I rerun MooseScripts>>createModelForMoose,
there is an error
key not found.
>>>>>>>> The cache of RPackage is not updated.
>>>>>>>
>>>>>>> what cache?
>>>>>>>>
>>>>>>>> Any solution ?
>>>>>>>>
>>>>>>>> Jannik
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>
>>>>>> "From an abstract enough point of view, any two things are
similar."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>> "Sometimes the best solution is not the best solution."
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> --
>> www.tudorgirba.com
>>
>> "Every now and then stop and ask yourself if the war you're fighting
is
the right one."
_______________________________________________
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
4976
days inactive
4979
days old
32 comments
5 participants
participants (5)
-
Alexandre Bergel -
Cyrille Delaunay -
jannik.laval -
Stéphane Ducasse -
Tudor Girba