On Fri, Sep 20, 2013 at 7:53 AM, Stéphane Ducasse <stephane.duca...@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 <marianop...@gmail.com> > wrote: > > Anyone? > > > On Wed, Aug 28, 2013 at 2:12 PM, Mariano Martinez Peck < > marianop...@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
