Issue 617 in moose-technology: RPackage has a self halt

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue 617 in moose-technology: RPackage has a self halt

moose-technology
Status: New
Owner: ----
CC: [hidden email],  [hidden email]
Labels: Type-Defect Priority-Critical Component-SmalltalkImporter  
Milestone-4.4

New issue 617 by [hidden email]: RPackage has a self halt
http://code.google.com/p/moose-technology/issues/detail?id=617

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


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue 617 in moose-technology: RPackage has a self halt

moose-technology

Comment #1 on issue 617 by [hidden email]: RPackage has a self halt
http://code.google.com/p/moose-technology/issues/detail?id=617

thanks I will have a look.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue 617 in moose-technology: RPackage has a self halt

moose-technology

Comment #2 on issue 617 by [hidden email]: RPackage has a self halt
http://code.google.com/p/moose-technology/issues/detail?id=617

Yes this implementation smells bad because we should not reemit new  
announcement.
This is on my radar

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue 617 in moose-technology: RPackage has a self halt

moose-technology

Comment #3 on issue 617 by [hidden email]: RPackage has a self halt
http://code.google.com/p/moose-technology/issues/detail?id=617

It seems that even at the beginning, the organizer  is not well initialized.
If you just evaluate (Behavior >> #compilerClass) packageFromOrganizer:  
RPackageOrganizer default

you have the halt

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue 617 in moose-technology: RPackage has a self halt

moose-technology

Comment #4 on issue 617 by [hidden email]: RPackage has a self halt
http://code.google.com/p/moose-technology/issues/detail?id=617

The last 3.0 version should provide a solution, that do not completly solve  
the problem, but that enable to load the package above. So we can use it  
till we completly fix the problem

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue 617 in moose-technology: RPackage has a self halt

moose-technology

Comment #5 on issue 617 by [hidden email]: RPackage has a self halt
http://code.google.com/p/moose-technology/issues/detail?id=617

I think I found where was coming from the problem, but I 'm not sure about  
the solution to give.
Currently in RPackage, if a compiledMethod in a class is coming from a  
trait, we do not add it to the package of the class.
The consequence is that such methods have no parent RPackage , which is  
wrong (and which is the problem , see (Behavior >> #compilerClass)  
packageFromOrganizer: RPackageOrganizer default).

The reason I deal with such methods like that,  is that PackageInfo >>  
methods does not return those methods, and then Monticello is expecting  
this behavior. Monticello needs to retrieve methods only coming from the  
class.

The solutions I was thinking about are :
- let RPackage not registering methods from traits but modify  
CompiledMethod >> packageFromOrganizer: to return the package of the trait
- or modify RPackage to register those method. I guess we should add them  
in a new specific dictionary (classDefinedSelectorsFromTrait .. ). Then we  
would be able to filter them. The 'hard' work for this solution, would be  
to keep updated this dictionary (knowing that when we recompile a method  
coming from trait,it become a method from the class )

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue 617 in moose-technology: RPackage has a self halt

moose-technology

Comment #6 on issue 617 by [hidden email]: RPackage has a self halt
http://code.google.com/p/moose-technology/issues/detail?id=617

Indeed, I confirm that now Bifrost loads.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue 617 in moose-technology: RPackage has a self halt

moose-technology
Updates:
        Status: Fixed

Comment #7 on issue 617 by [hidden email]: RPackage has a self halt
http://code.google.com/p/moose-technology/issues/detail?id=617

(No comment was entered for this change.)

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