Status: New Owner: ---- CC: cy.delau...@gmail.com, stephane...@gmail.com Labels: Type-Defect Priority-Critical Component-SmalltalkImporter Milestone-4.4
New issue 617 by tudor.gi...@gmail.com: 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/a...
Comment #1 on issue 617 by stephane...@gmail.com: RPackage has a self halt http://code.google.com/p/moose-technology/issues/detail?id=617
thanks I will have a look.
Comment #2 on issue 617 by stephane...@gmail.com: 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
Comment #3 on issue 617 by cy.delau...@gmail.com: 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
Comment #4 on issue 617 by cy.delau...@gmail.com: 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
Comment #5 on issue 617 by cy.delau...@gmail.com: 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 )
Comment #6 on issue 617 by tudor.gi...@gmail.com: RPackage has a self halt http://code.google.com/p/moose-technology/issues/detail?id=617
Indeed, I confirm that now Bifrost loads.
Updates: Status: Fixed
Comment #7 on issue 617 by tudor.gi...@gmail.com: RPackage has a self halt http://code.google.com/p/moose-technology/issues/detail?id=617
(No comment was entered for this change.)
-
moose-technology＠googlecode.com