[Pharo-project] Fix to PackageOrganizer>>packageOfClass:
All, I was confused about the purpose of PackageInfo>>mostSpecificPackageOfMethod:ifNone: and PackageInfo>>mostSpecificPackageOfClass:ifNone: They seem to be a workaround to the bug that exist in #packageOfClass:ifNone: and #packageOfMethod:ifNone:? I propose this fix, after discussing it with Lukas: http://code.google.com/p/pharo/issues/detail?id=1752 Background of problem: In theory it should not be possible for packages to overlap. Every class, and every method should belong to only one Category. In reality packaging bugs and other actions does cause packages to be created that overlap. An example in PharoCore, 10505 is this: (PackageOrganizer default packageNamed: 'Collections' ifAbsent: [ self error: 'hmm']) includesClass: Text. " true " (PackageOrganizer default packageNamed: 'Collections-Text' ifAbsent: [ self error: 'hmm']) includesClass: Text. " also true! " In the old implementation, #packageOfClass: would have returned the first category that matches. It will now return the more specific 'Collections-Text'. I suggest that #mostSpecificPackageOfClass* and #mostSpecificPackageOfMethod* methods be removed as well? -- Danie Roux *shuffle* Adore Unix - http://danieroux.com
Would it prevent merging squeak/trunk Collection ? If yes, I suggest a status quo. Nicolas 2010/1/7 Danie Roux <lists+pharo@danieroux.com>:
All,
I was confused about the purpose of PackageInfo>>mostSpecificPackageOfMethod:ifNone: and PackageInfo>>mostSpecificPackageOfClass:ifNone:
They seem to be a workaround to the bug that exist in #packageOfClass:ifNone: and #packageOfMethod:ifNone:?
I propose this fix, after discussing it with Lukas: http://code.google.com/p/pharo/issues/detail?id=1752
Background of problem:
In theory it should not be possible for packages to overlap. Every class, and every method should belong to only one Category. In reality packaging bugs and other actions does cause packages to be created that overlap.
An example in PharoCore, 10505 is this:
(PackageOrganizer default packageNamed: Â 'Collections' ifAbsent: [ self error: 'hmm']) includesClass: Text. " true " (PackageOrganizer default packageNamed: Â 'Collections-Text' ifAbsent: [ self error: 'hmm']) includesClass: Text. " also true! "
In the old implementation, #packageOfClass: would have returned the first category that matches. It will now return the more specific 'Collections-Text'.
I suggest that #mostSpecificPackageOfClass* and #mostSpecificPackageOfMethod* methods be removed as well?
-- Danie Roux *shuffle* Adore Unix - http://danieroux.com
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, Jan 7, 2010 at 8:14 PM, Nicolas Cellier wrote:
Would it prevent merging squeak/trunk Collection ? If yes, I suggest a status quo.
No, I checked and could merge both ways (adding methods to Text on Squeak trunk, and Pharo, and "cherry-picking" them both ways). Monticello hangs on to the package name and index only by that - it does not infer it from the class or method. The same problem exists in my Squeak trunk image, btw. In this case only if the name of the shorter package is a symbol: (PackageOrganizer default packageNamed: #OB ifAbsent: [ self error: 'hmm']) includesClass: OBMorphBuilder. (PackageOrganizer default packageNamed: 'OB-Morphic' ifAbsent: [ self error: 'hmm']) includesClass: OBMorphBuilder. I guess there is a biggest issue to be fixed here, namely the proper maintenance of "PackageOrganizer default packages" :-) -- Danie Roux *shuffle* Adore Unix - http://danieroux.com
On Thu, Jan 7, 2010 at 8:14 PM, Nicolas Cellier wrote:
Would it prevent merging squeak/trunk Collection ? If yes, I suggest a status quo.
No, I checked and could merge both ways (adding methods to Text on Squeak trunk, and Pharo, and "cherry-picking" them both ways).
Monticello hangs on to the package name and index only by that - it does not infer it from the class or method.
The same problem exists in my Squeak trunk image, btw. In this case only if the name of the shorter package is a symbol:
(PackageOrganizer default packageNamed: #OB ifAbsent: [ self error: 'hmm']) includesClass: OBMorphBuilder. (PackageOrganizer default packageNamed: 'OB-Morphic' ifAbsent: [ self error: 'hmm']) includesClass: OBMorphBuilder.
I guess there is a biggest issue to be fixed here, namely the proper maintenance of "PackageOrganizer default packages" :-)
yes and imagine that I cleaned it because it was full of wrong and unused information.
In the old implementation, #packageOfClass: would have returned the first category that matches. It will now return the more specific 'Collections-Text'.
You mean with your fix?
On Thu, Jan 7, 2010 at 8:52 PM, Stéphane Ducasse wrote:
In the old implementation, #packageOfClass: would have returned the first category that matches. It will now return the more specific 'Collections-Text'.
You mean with your fix?
Yes, once that fix is applied it will return the more specific one. I apologise for the confusion :-) -- Danie Roux *shuffle* Adore Unix - http://danieroux.com
I think we should wrote somewhere how to submit an issue (It is nothing agains Danie, thank you VERY much for the submit!!!). I mean, all that stuff about the Slice, it's name and the trick of the dirty packages... And then we add that to the website as we did with the issue tracker. On Thu, Jan 7, 2010 at 7:55 PM, Danie Roux <lists+pharo@danieroux.com<lists%2Bpharo@danieroux.com>
wrote:
On Thu, Jan 7, 2010 at 8:52 PM, Stéphane Ducasse wrote:
In the old implementation, #packageOfClass: would have returned the first category that matches. It will now return the more specific 'Collections-Text'.
You mean with your fix?
Yes, once that fix is applied it will return the more specific one. I apologise for the confusion :-)
-- Danie Roux *shuffle* Adore Unix - http://danieroux.com
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/1/7 Mariano Martinez Peck :
I think we should wrote somewhere how to submit an issue
I followed http://code.google.com/p/pharo/wiki/HowToContribute :-) I missed the step to set the status to "Fixed" though.
it's name and the trick of the dirty packages...
"The trick of the dirty packages". Sounds like a crime novel. But seriously, what is this trick? -- Danie Roux *shuffle* Adore Unix - http://danieroux.com
On Jan 7, 2010, at 8:51 PM, Danie Roux wrote:
2010/1/7 Mariano Martinez Peck :
I think we should wrote somewhere how to submit an issue
I followed http://code.google.com/p/pharo/wiki/HowToContribute :-) I missed the step to set the status to "Fixed" though.
it's name and the trick of the dirty packages...
"The trick of the dirty packages". Sounds like a crime novel. But seriously, what is this trick?
once you created a slice you can if you want and it makes sense for your image get all the dirty packages as dependent of your slice and like that publish in one shot all the changes and me integrate them :)
-- Danie Roux *shuffle* Adore Unix - http://danieroux.com
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, Jan 7, 2010 at 8:51 PM, Danie Roux <lists+pharo@danieroux.com<lists%2Bpharo@danieroux.com>
wrote:
2010/1/7 Mariano Martinez Peck :
I think we should wrote somewhere how to submit an issue
I followed http://code.google.com/p/pharo/wiki/HowToContribute :-) I missed the step to set the status to "Fixed" though.
Thank you!!! I was looking for that link and I didn't find it.
it's name and the trick of the dirty packages...
"The trick of the dirty packages". Sounds like a crime novel. But seriously, what is this trick?
Sorry for the confusion, you did exactly the correct. The trick is the following (I think it is the same that is explained there...) When you have changed several packages, you have to create another package called SLICE-IssueXXX-DeCRIPTION and then, you have to put to that package, the packages that you modified, as "requierd". Then, when you commit the slice package, it also commits the requiered packages, and thus, all of them are loaded when someone else load that slice package in another image. The trick is that most of the times, all the requiered packages are those who you have modified. So, there is an option (right button in a package) which says "add dirty package as requiered". Dirty in this case means modified. That's all :) Thank you very much! Mariano
-- Danie Roux *shuffle* Adore Unix - http://danieroux.com
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, Jan 7, 2010 at 8:55 PM, Danie Roux <lists+pharo@danieroux.com> wrote:
On Thu, Jan 7, 2010 at 8:52 PM, Stéphane Ducasse wrote:
In the old implementation, #packageOfClass: would have returned the first category that matches. It will now return the more specific 'Collections-Text'.
You mean with your fix?
Yes, once that fix is applied it will return the more specific one. I apologise for the confusion :-)
May I be so bold to ask that this fix be integrated into the next batch? OB use #mostSpecificPackageOfClass and it would be better if is used #packageOfClass: instead. But then #packageOfClass: needs to have this fix of course :-) http://code.google.com/p/pharo/issues/detail?id=1752 -- Danie Roux *shuffle* Adore Unix - http://danieroux.com
hi danie why we did not integrate it so far (beside time)? I would like to understand its impact. Where packageOfClass: is used and soon. On Jan 18, 2010, at 3:54 PM, Danie Roux wrote:
On Thu, Jan 7, 2010 at 8:55 PM, Danie Roux <lists+pharo@danieroux.com> wrote:
On Thu, Jan 7, 2010 at 8:52 PM, Stéphane Ducasse wrote:
In the old implementation, #packageOfClass: would have returned the first category that matches. It will now return the more specific 'Collections-Text'.
You mean with your fix?
Yes, once that fix is applied it will return the more specific one. I apologise for the confusion :-)
May I be so bold to ask that this fix be integrated into the next batch? OB use #mostSpecificPackageOfClass and it would be better if is used #packageOfClass: instead. But then #packageOfClass: needs to have this fix of course :-)
http://code.google.com/p/pharo/issues/detail?id=1752
-- Danie Roux *shuffle* Adore Unix - http://danieroux.com
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Danie Roux -
Mariano Martinez Peck -
Nicolas Cellier -
Stéphane Ducasse