Smalltalk › Frameworks & Tools › Moose

RPackage issue ?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

33 messages Options

Tudor Girba

Re: RPackage issue ?

Hi Stef,

On 8 May 2011, at 14:25, Stéphane Ducasse wrote:

> 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/artifact/moose/*zip*/moose.zip
>>
>> 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

For example, look at RPackageMCSynchronisationTest>>testRemoveClassUpdateTheorganizer. This test is directly calling the deprecated RPackageOrganizer>>includesClass:

Cheers,
Doru

>>
>> 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:
>>>
>>>> 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 <[hidden email]>
>>>> 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 <[hidden email]>
>>>>>
>>>>> 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/artifact/moose/*zip*/moose.zip
>>>>>>>>
>>>>>>>> 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
>>>>>>>>>> [hidden email]
>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Moose-dev mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> 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
>>>>>>>> [hidden email]
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> [hidden email]
>>>>>>> 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
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> 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
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Value is always contextual."
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Yesterday is a fact.
Tomorrow is a possibility.
Today is a challenge."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stéphane Ducasse

Re: RPackage issue ?

In reply to this post by Tudor Girba

>
>
> 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
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stéphane Ducasse

Re: RPackage issue ?

In reply to this post by Tudor Girba

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:
>
>> 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/artifact/moose/*zip*/moose.zip
>>>
>>> 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
>
> For example, look at RPackageMCSynchronisationTest>>testRemoveClassUpdateTheorganizer. This test is directly calling the deprecated RPackageOrganizer>>includesClass:
>
> Cheers,
> Doru
>
>
>>>
>>> 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:
>>>>
>>>>> 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 <[hidden email]>
>>>>> 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 <[hidden email]>
>>>>>>
>>>>>> 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/artifact/moose/*zip*/moose.zip
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>> [hidden email]
>>>>>>>>>> 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
>>>>>>>>> [hidden email]
>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Moose-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> 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
>>>>>>> [hidden email]
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> 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
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Value is always contextual."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Yesterday is a fact.
> Tomorrow is a possibility.
> Today is a challenge."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stéphane Ducasse

Re: RPackage issue ?

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.
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stéphane Ducasse

Re: RPackage issue ?

In reply to this post by Tudor Girba

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:

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stéphane Ducasse

Re: RPackage issue ?

In reply to this post by Tudor Girba

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
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stéphane Ducasse

Re: RPackage issue ?

In reply to this post by Tudor Girba

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
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Tudor Girba

Re: RPackage issue ?

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
> [hidden email]
> 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
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Tudor Girba

Re: RPackage issue ?

In reply to this post by Stéphane Ducasse

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
> [hidden email]
> 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."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stéphane Ducasse

Re: RPackage issue ?

On May 8, 2011, at 5:58 PM, Tudor Girba wrote:

> 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?

Yes this is probably what we will have to do.... been more robust :(
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stéphane Ducasse

Re: RPackage issue ?

In reply to this post by Tudor Girba

> 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.

yes I know but I tried to load it to find the bug.
after that the image was fucked up

Stef
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Tudor Girba

Re: RPackage issue ?

On 8 May 2011, at 18:26, 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.
>
>
> yes I know but I tried to load it to find the bug.
> after that the image was fucked up

Ah yes. And sometimes, even if you can browse, you get a debugger when accepting a method :)

Cheers,
Doru

> Stef
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Value is always contextual."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

cdelaunay

Re: RPackage issue ?

In reply to this post by Tudor Girba

2011/5/8 Tudor Girba <[hidden email]>

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/artifact/moose/*zip*/moose.zip

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:

>
> 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 <[hidden email]>
>> 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 <[hidden email]>
>>>
>>> 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/artifact/moose/*zip*/moose.zip
>>>>>>
>>>>>> 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
>>>>>>>> [hidden email]
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> [hidden email]
>>>>>>> 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
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> 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
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> 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
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Value is always contextual."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev