Hi guys, I was trying to build a new image with latest Pharo 2.0 with all the frameworks I use. While installing, I get a dnu in: packageFromOrganizer: anRPackageOrganizer "This method returns the package this method belongs to. It takes into account classes and traits. If the method is in no package, returns nil by now" self flag: 'TODO: use anRPackageOrganizer, or better delegate to anRPackageOrganizer'. ^self origin packages detect: [ :each | (each includesSelector: self selector ofClassName: self origin theNonMetaClass originalName) or: [ each includesSelector: self selector ofMetaclassName: self origin theNonMetaClass originalName]] ifNone: [ nil ] because "each" (which was GRPackage) dnu #includesSelector:ofClassName: Problem is that "self origin" answers GRPackage. And GRPackage DOES implement a CLASS side method #packages that answers instances of GRPackage.....not RPackage... So...which one do we prefix? GRPackage class #packages to #greasePackages? BTW, there are yet more class side implementations of #packages, which are basically subclasses for the HelpSystem (CustomHelp). So we have for example SUnitAPIDocumentation, RegexAPIDocumentation, ProfStefAPIHelp, HelpAPIDocumentation, AnnouncementsAPIDocumentation. Guess we should update the HelpSystem as well? Let me know and I open issues/submit fixes. Cheers, -- Mariano http://marianopeck.wordpress.com
Anyone? On Wed, Aug 28, 2013 at 2:12 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi guys,
I was trying to build a new image with latest Pharo 2.0 with all the frameworks I use. While installing, I get a dnu in:
packageFromOrganizer: anRPackageOrganizer "This method returns the package this method belongs to. It takes into account classes and traits. If the method is in no package, returns nil by now" self flag: 'TODO: use anRPackageOrganizer, or better delegate to anRPackageOrganizer'. ^self origin packages detect: [ :each | (each includesSelector: self selector ofClassName: self origin theNonMetaClass originalName) or: [ each includesSelector: self selector ofMetaclassName: self origin theNonMetaClass originalName]] ifNone: [ nil ]
because "each" (which was GRPackage) dnu #includesSelector:ofClassName:
Problem is that "self origin" answers GRPackage. And GRPackage DOES implement a CLASS side method #packages that answers instances of GRPackage.....not RPackage...
So...which one do we prefix? GRPackage class #packages to #greasePackages?
BTW, there are yet more class side implementations of #packages, which are basically subclasses for the HelpSystem (CustomHelp). So we have for example SUnitAPIDocumentation, RegexAPIDocumentation, ProfStefAPIHelp, HelpAPIDocumentation, AnnouncementsAPIDocumentation.
Guess we should update the HelpSystem as well?
Let me know and I open issues/submit fixes.
Cheers,
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
I do not understand why it would be a GreasePackage What are grease package? if grease override the packages messages then I do not see why it would be a pharo bug. This is like if you redefine class and returns something else. Stef On Sep 6, 2013, at 3:21 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Anyone?
On Wed, Aug 28, 2013 at 2:12 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote: Hi guys,
I was trying to build a new image with latest Pharo 2.0 with all the frameworks I use. While installing, I get a dnu in:
packageFromOrganizer: anRPackageOrganizer "This method returns the package this method belongs to. It takes into account classes and traits. If the method is in no package, returns nil by now" self flag: 'TODO: use anRPackageOrganizer, or better delegate to anRPackageOrganizer'. ^self origin packages detect: [ :each | (each includesSelector: self selector ofClassName: self origin theNonMetaClass originalName) or: [ each includesSelector: self selector ofMetaclassName: self origin theNonMetaClass originalName]] ifNone: [ nil ]
because "each" (which was GRPackage) dnu #includesSelector:ofClassName:
Problem is that "self origin" answers GRPackage. And GRPackage DOES implement a CLASS side method #packages that answers instances of GRPackage.....not RPackage...
So...which one do we prefix? GRPackage class #packages to #greasePackages?
BTW, there are yet more class side implementations of #packages, which are basically subclasses for the HelpSystem (CustomHelp). So we have for example SUnitAPIDocumentation, RegexAPIDocumentation, ProfStefAPIHelp, HelpAPIDocumentation, AnnouncementsAPIDocumentation.
Guess we should update the HelpSystem as well?
Let me know and I open issues/submit fixes.
Cheers,
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
On Fri, Sep 20, 2013 at 7:53 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
I do not understand why it would be a GreasePackage What are grease package? if grease override the packages messages then I do not see why it would be a pharo bug. This is like if you redefine class and returns something else.
Indeed. It is as simple as that. Grease is overriding a class side method #packages which is a collision to Pharo core and hence fails the load because #packages for that class answers its own type of packages rather than the expected by Pharo. Again, a simply rename of GRPackage class >> packages would be enough. And it has only one sender (a test) in the image I have....
Stef
On Sep 6, 2013, at 3:21 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Anyone?
On Wed, Aug 28, 2013 at 2:12 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi guys,
I was trying to build a new image with latest Pharo 2.0 with all the frameworks I use. While installing, I get a dnu in:
packageFromOrganizer: anRPackageOrganizer "This method returns the package this method belongs to. It takes into account classes and traits. If the method is in no package, returns nil by now" self flag: 'TODO: use anRPackageOrganizer, or better delegate to anRPackageOrganizer'. ^self origin packages detect: [ :each | (each includesSelector: self selector ofClassName: self origin theNonMetaClass originalName) or: [ each includesSelector: self selector ofMetaclassName: self origin theNonMetaClass originalName]] ifNone: [ nil ]
because "each" (which was GRPackage) dnu #includesSelector:ofClassName:
Problem is that "self origin" answers GRPackage. And GRPackage DOES implement a CLASS side method #packages that answers instances of GRPackage.....not RPackage...
So...which one do we prefix? GRPackage class #packages to #greasePackages?
BTW, there are yet more class side implementations of #packages, which are basically subclasses for the HelpSystem (CustomHelp). So we have for example SUnitAPIDocumentation, RegexAPIDocumentation, ProfStefAPIHelp, HelpAPIDocumentation, AnnouncementsAPIDocumentation.
Guess we should update the HelpSystem as well?
Let me know and I open issues/submit fixes.
Cheers,
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
Hi mariano I have no idea what is a GRPackage.
packageFromOrganizer: anRPackageOrganizer "This method returns the package this method belongs to. It takes into account classes and traits. If the method is in no package, returns nil by now" self flag: 'TODO: use anRPackageOrganizer, or better delegate to anRPackageOrganizer'. ^self origin packages detect: [ :each | (each includesSelector: self selector ofClassName: self origin theNonMetaClass originalName) or: [ each includesSelector: self selector ofMetaclassName: self origin theNonMetaClass originalName]] ifNone: [ nil ]
because "each" (which was GRPackage) dnu #includesSelector:ofClassName:
Problem is that "self origin" answers GRPackage. And GRPackage DOES implement a CLASS side method #packages that answers instances of GRPackage.....not RPackage...
So...which one do we prefix? GRPackage class #packages to #greasePackages?
Yes.
BTW, there are yet more class side implementations of #packages, which are basically subclasses for the HelpSystem (CustomHelp). So we have for example SUnitAPIDocumentation, RegexAPIDocumentation, ProfStefAPIHelp, HelpAPIDocumentation, AnnouncementsAPIDocumentation.
Strange. This is probably a method clash. So yes Documentation should probably not redefine packages.
Guess we should update the HelpSystem as well?
Let me know and I open issues/submit fixes.
Cheers,
-- Mariano http://marianopeck.wordpress.com
participants (2)
-
Mariano Martinez Peck -
Stéphane Ducasse