Re: [Pharo-dev] Grease conflicts #packages with RPackage
sorry, but I still do not understand why this is a problem. can you elaborate why it should not be more implementations? Esteban On Tue, Dec 3, 2013 at 3:25 PM, Stephan Eggermont step...@stack.nl wrote: I could copy the separate packages, but not the slice. Please note that the added test is expected to fail on all builds containing Grease-Core. Stephan
Re: [Pharo-dev] Grease conflicts #packages with RPackage
Because many times you sent class side #packages as part of RPackage framework. But...if you have other class side #packages that answer something different...then you are screw. See my original post: http://forum.world.st/Re-Grease-conflicts-packages-with-RPackage-td4706911.html On Wed, Dec 4, 2013 at 8:54 AM, Esteban Lorenzano esteba...@gmail.comwrote: sorry, but I still do not understand why this is a problem. can you elaborate why it should not be more implementations? Esteban On Tue, Dec 3, 2013 at 3:25 PM, Stephan Eggermont step...@stack.nlwrote: I could copy the separate packages, but not the slice. Please note that the added test is expected to fail on all builds containing Grease-Core. Stephan -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] Grease conflicts #packages with RPackage
and why is a problem for us and for grease? On Wed, Dec 4, 2013 at 1:09 PM, Mariano Martinez Peck marianop...@gmail.com wrote: Because many times you sent class side #packages as part of RPackage framework. But...if you have other class side #packages that answer something different...then you are screw. See my original post: http://forum.world.st/Re-Grease-conflicts-packages-with-RPackage-td4706911.html On Wed, Dec 4, 2013 at 8:54 AM, Esteban Lorenzano esteba...@gmail.comwrote: sorry, but I still do not understand why this is a problem. can you elaborate why it should not be more implementations? Esteban On Tue, Dec 3, 2013 at 3:25 PM, Stephan Eggermont step...@stack.nlwrote: I could copy the separate packages, but not the slice. Please note that the added test is expected to fail on all builds containing Grease-Core. Stephan -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] Grease conflicts #packages with RPackage
For us because there are 4 or 5 class side #packages IN PHARO, not grease. On Wed, Dec 4, 2013 at 9:11 AM, Esteban Lorenzano esteba...@gmail.comwrote: and why is a problem for us and for grease? On Wed, Dec 4, 2013 at 1:09 PM, Mariano Martinez Peck marianop...@gmail.com wrote: Because many times you sent class side #packages as part of RPackage framework. But...if you have other class side #packages that answer something different...then you are screw. See my original post: http://forum.world.st/Re-Grease-conflicts-packages-with-RPackage-td4706911.html On Wed, Dec 4, 2013 at 8:54 AM, Esteban Lorenzano esteba...@gmail.comwrote: sorry, but I still do not understand why this is a problem. can you elaborate why it should not be more implementations? Esteban On Tue, Dec 3, 2013 at 3:25 PM, Stephan Eggermont step...@stack.nlwrote: I could copy the separate packages, but not the slice. Please note that the added test is expected to fail on all builds containing Grease-Core. Stephan -- Mariano http://marianopeck.wordpress.com -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] Grease conflicts #packages with RPackage
On 04 Dec 2013, at 13:11, Esteban Lorenzano esteba...@gmail.com wrote: and why is a problem for us and for grease? because people want to say MyClass package and get back the RPackage that the class is in... On Wed, Dec 4, 2013 at 1:09 PM, Mariano Martinez Peck marianop...@gmail.com wrote: Because many times you sent class side #packages as part of RPackage framework. But...if you have other class side #packages that answer something different...then you are screw. See my original post: http://forum.world.st/Re-Grease-conflicts-packages-with-RPackage-td4706911.html On Wed, Dec 4, 2013 at 8:54 AM, Esteban Lorenzano esteba...@gmail.com wrote: sorry, but I still do not understand why this is a problem. can you elaborate why it should not be more implementations? Esteban On Tue, Dec 3, 2013 at 3:25 PM, Stephan Eggermont step...@stack.nl wrote: I could copy the separate packages, but not the slice. Please note that the added test is expected to fail on all builds containing Grease-Core. Stephan -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] Grease conflicts #packages with RPackage
Esteban wrote: sorry, but I still do not understand why this is a problem. can you elaborate why it should not be more implementations? It breaks the system. You can no longer use senders. So currently, all Moose and Seaside based 3.0 images are somewhat unusable. Stephan
Re: [Pharo-dev] Grease conflicts #packages with RPackage
senders of what? I can use senders. On Wed, Dec 4, 2013 at 1:34 PM, Stephan Eggermont step...@stack.nl wrote: Esteban wrote: sorry, but I still do not understand why this is a problem. can you elaborate why it should not be more implementations? It breaks the system. You can no longer use senders. So currently, all Moose and Seaside based 3.0 images are somewhat unusable. Stephan
Re: [Pharo-dev] Grease conflicts #packages with RPackage
Mariano wrote: You will only have problems with class side #packages. Are all those 35 class side? 5 out of 35. 4 of which are in Pharo 3 Stephan
Re: [Pharo-dev] Grease conflicts #packages with RPackage
The real problem is that a CLASS now responds to the packages message. Stef On Dec 3, 2013, at 11:10 AM, Stephan Eggermont step...@stack.nl wrote: Mariano wrote: You will only have problems with class side #packages. Are all those 35 class side? 5 out of 35. 4 of which are in Pharo 3 Stephan
Re: [Pharo-dev] Grease conflicts #packages with RPackage
Stef wrote: The real problem is that a CLASS now responds to the packages message. SUnitAPIDocumentation also implements packages class-side. If I try to add a instance side method #bla I get a debugger (but the method is added). Searching for implementors then also returns a debugger. I assume this problem wasn’t seen as the classes implementing packages class-side don’t have instance side behavior. The classes implementing packages class-side are SUnitAPIDocumentation AnnouncementsAPIDocumentation HelpAPIDocumentation ProfStefAPIHelp They all return an array of package name strings Stephan
Re: [Pharo-dev] Grease conflicts #packages with RPackage
I could copy the separate packages, but not the slice. Please note that the added test is expected to fail on all builds containing Grease-Core. Stephan
Re: [Pharo-dev] Grease conflicts #packages with RPackage
Stef wrote: Do you think that if an external library redefines the semantics of #class, it will be a Pharo bug? I don’t know. I know I have 35 implementers of #packages in my Moose image, and 191 senders. And I know that in Magritte 3 we changed from using #description to #magritteDescription to avoid polluting the namespace with a word that is commonly used for other things. At the same time I don’t exactly enjoy adding prefixes everywhere. DeprecationFinder tells me there are 60 projects on smalltalkhub using #packages. And I know I have to be careful about where I use #name. And when taking a look at the problem, I immediately run into lots of methods flagged #todo, a.o. (CompiledMethodpackageFromOrganizer:) that seems to suggest a different solution. I can imagine a more effective way of convincing Grease maintainers that they should switch API :) Stephan
Re: [Pharo-dev] Grease conflicts #packages with RPackage
On Mon, Dec 2, 2013 at 6:03 PM, Stephan Eggermont step...@stack.nl wrote: Stef wrote: Do you think that if an external library redefines the semantics of #class, it will be a Pharo bug? I don’t know. I know I have 35 implementers of #packages in my Moose image, and 191 senders. You will only have problems with class side #packages. Are all those 35 class side? Cheers, And I know that in Magritte 3 we changed from using #description to #magritteDescription to avoid polluting the namespace with a word that is commonly used for other things. At the same time I don’t exactly enjoy adding prefixes everywhere. DeprecationFinder tells me there are 60 projects on smalltalkhub using #packages. And I know I have to be careful about where I use #name. And when taking a look at the problem, I immediately run into lots of methods flagged #todo, a.o. (CompiledMethodpackageFromOrganizer:) that seems to suggest a different solution. I can imagine a more effective way of convincing Grease maintainers that they should switch API :) Stephan -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] Grease conflicts #packages with RPackage
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
Re: [Pharo-dev] Grease conflicts #packages with RPackage
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
