[Pharo-project] I would like to clean the inbox! Please read
So I will harvest what I can - collection - MC enh - copyright and I will move the rest to treated. Except I you shout and tell me that your code is ready for integration. Can somebody (lukas for example) have a look at the code of noury on package renaming. Noury told me that it worked since years but lukas told me that renaming is not supported in MC so I'm puzzled. Damien. P is your fix Name: System-damien.pollet.169 Author: damien.pollet Time: 26 October 2008, 6:31:21 pm UUID: 8baf2159-f018-43d3-b746- 5310f264ee81 Ancestors: System-damien.pollet.168 Set initials at the same time as name to avoid the infinite loop of Author>>initials ready? What is the status of the networkTests and Network submissions? Should I harvest them Stef
Can somebody (lukas for example) have a look at the code of noury on package renaming. Noury told me that it worked since years but lukas told me that renaming is not supported in MC so I'm puzzled.
In what package is that? Lukas -- Lukas Renggli http://www.lukas-renggli.ch
this is renaming... in inbox Tx lukas On Nov 7, 2008, at 6:54 PM, Lukas Renggli wrote:
Can somebody (lukas for example) have a look at the code of noury on package renaming. Noury told me that it worked since years but lukas told me that renaming is not supported in MC so I'm puzzled.
In what package is that?
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
The package MonticelloPackageRenaming-Noury.1 introduces 2 new menu items into the Monticello Browser, by overriding and extending several methods in Monticello. If this code is included with Pharo, it should become part of Monticello itself. There are 4 test cases included. Below I review the two new functionalities independently: 1. Replace Classes Prefix: This functionality is useful, however the implementation depends on the presence of the Refactoring Browser. Furthermore this functionality is already present in the Refactoring Browser (OB-Regex) in a more generic fashion. Open | Rewrite Class allows one to batch rename, batch copy and batch create a set of classes using regular expressions. 2. Rename Package: This functionality renames class categories and method protocols to match the new package name. The code also takes care of the dependencies and removing traces of the old package in the Monticello Browser. It does not depend on external functionality. There are however 3 major problems with the implementation: (1) Class extensions extinct if they do not match the package names in a case-sensitive way. PackageInfo treats class categories case-sensitive, but protocols are handled case-insensitive. (2) Packages that share the same prefix are wrongly renamed, even if PackageInfo does not consider them to be from the same package (for example Morphic and MorphicExtras). (3) The ancestry of the renamed package is not preserved, what makes merging packages across renaming impossible. Though, I don't know if such a functionality would be possible with Monticello at all? Given the number of problems I don't suggest to include these extensions for now. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
thanks lukas On Nov 7, 2008, at 10:26 PM, Lukas Renggli wrote:
The package MonticelloPackageRenaming-Noury.1 introduces 2 new menu items into the Monticello Browser, by overriding and extending several methods in Monticello. If this code is included with Pharo, it should become part of Monticello itself. There are 4 test cases included.
Below I review the two new functionalities independently:
1. Replace Classes Prefix: This functionality is useful, however the implementation depends on the presence of the Refactoring Browser. Furthermore this functionality is already present in the Refactoring Browser (OB-Regex) in a more generic fashion. Open | Rewrite Class allows one to batch rename, batch copy and batch create a set of classes using regular expressions.
2. Rename Package: This functionality renames class categories and method protocols to match the new package name. The code also takes care of the dependencies and removing traces of the old package in the Monticello Browser. It does not depend on external functionality. There are however 3 major problems with the implementation: (1) Class extensions extinct if they do not match the package names in a case-sensitive way. PackageInfo treats class categories case-sensitive, but protocols are handled case-insensitive. (2) Packages that share the same prefix are wrongly renamed, even if PackageInfo does not consider them to be from the same package (for example Morphic and MorphicExtras). (3) The ancestry of the renamed package is not preserved, what makes merging packages across renaming impossible. Though, I don't know if such a functionality would be possible with Monticello at all?
Given the number of problems I don't suggest to include these extensions for now.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, Nov 7, 2008 at 5:29 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I will move the rest to treated. Except I you shout and tell me that your code is ready for integration.
Does it mean you will ignore everything but these 3 fixes? I don't understand why. If you don't have time, just don't harvest them. -- Damien Cassou http://damiencassou.seasidehosting.st
Thanks Lukas for the feedback. Now I have some questions: -For fuctionality 1 : Because of the dependency with the RefactoringBrowser, which obviously shouldn't be in the core image. Does it make sense to have it in an external package ? It's handy to avoid using multiple tools when renaming a Monticello Package and the corresponding class prefixes. But, may be should I reimplement without reusing the RefactoringBrowser ? -Is fuctionality 2 useful for other people than me ? Fixing the issues you identified wouldn't be a big challenge. Noury On 7 nov. 08, at 22:26, Lukas Renggli wrote:
The package MonticelloPackageRenaming-Noury.1 introduces 2 new menu items into the Monticello Browser, by overriding and extending several methods in Monticello. If this code is included with Pharo, it should become part of Monticello itself. There are 4 test cases included.
Below I review the two new functionalities independently:
1. Replace Classes Prefix: This functionality is useful, however the implementation depends on the presence of the Refactoring Browser. Furthermore this functionality is already present in the Refactoring Browser (OB-Regex) in a more generic fashion. Open | Rewrite Class allows one to batch rename, batch copy and batch create a set of classes using regular expressions.
2. Rename Package: This functionality renames class categories and method protocols to match the new package name. The code also takes care of the dependencies and removing traces of the old package in the Monticello Browser. It does not depend on external functionality. There are however 3 major problems with the implementation: (1) Class extensions extinct if they do not match the package names in a case-sensitive way. PackageInfo treats class categories case-sensitive, but protocols are handled case-insensitive. (2) Packages that share the same prefix are wrongly renamed, even if PackageInfo does not consider them to be from the same package (for example Morphic and MorphicExtras). (3) The ancestry of the renamed package is not preserved, what makes merging packages across renaming impossible. Though, I don't know if such a functionality would be possible with Monticello at all?
Given the number of problems I don't suggest to include these extensions for now.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Noury Bouraqadi ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------
No totally I just clean what I could. For example, I asked you if you could redo your embedded world. because with the changes lukas did we got a lot of noise. Again I repeat it, when we open the pharoinbox this is difficult for us (even if the merging of MC helps a lot) to know what is the slice for, its importance, impact...
Except I you shout and tell me that your code is ready for integration.
Does it mean you will ignore everything but these 3 fixes? I don't understand why.
No I'm cleaning. There were old submissions hanging around.
If you don't have time, just don't harvest them.
this is not the point.
-- Damien Cassou http://damiencassou.seasidehosting.st
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks Lukas for the feedback. Now I have some questions:
-For fuctionality 1 : Because of the dependency with the RefactoringBrowser, which obviously shouldn't be in the core image. Does it make sense to have it in an external package ? It's handy to avoid using multiple tools when renaming a Monticello Package and the corresponding class prefixes. But, may be should I reimplement without reusing the RefactoringBrowser ?
My feeling is that the RBengine should be in the system (not core) at the same time the browsers are in. Because renaming a class in the refactoring way is just the way to go since 10 years or more.
-Is fuctionality 2 useful for other people than me ? Fixing the issues you identified wouldn't be a big challenge.
Yes renaming a package would be cool.
Noury On 7 nov. 08, at 22:26, Lukas Renggli wrote:
The package MonticelloPackageRenaming-Noury.1 introduces 2 new menu items into the Monticello Browser, by overriding and extending several methods in Monticello. If this code is included with Pharo, it should become part of Monticello itself. There are 4 test cases included.
Below I review the two new functionalities independently:
1. Replace Classes Prefix: This functionality is useful, however the implementation depends on the presence of the Refactoring Browser. Furthermore this functionality is already present in the Refactoring Browser (OB-Regex) in a more generic fashion. Open | Rewrite Class allows one to batch rename, batch copy and batch create a set of classes using regular expressions.
2. Rename Package: This functionality renames class categories and method protocols to match the new package name. The code also takes care of the dependencies and removing traces of the old package in the Monticello Browser. It does not depend on external functionality. There are however 3 major problems with the implementation: (1) Class extensions extinct if they do not match the package names in a case-sensitive way. PackageInfo treats class categories case-sensitive, but protocols are handled case-insensitive. (2) Packages that share the same prefix are wrongly renamed, even if PackageInfo does not consider them to be from the same package (for example Morphic and MorphicExtras). (3) The ancestry of the renamed package is not preserved, what makes merging packages across renaming impossible. Though, I don't know if such a functionality would be possible with Monticello at all?
Given the number of problems I don't suggest to include these extensions for now.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Noury Bouraqadi ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury
European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
by the way damien can you reply for the network and networktest? did you check what was done? Stef On Nov 8, 2008, at 11:08 AM, Damien Cassou wrote:
On Fri, Nov 7, 2008 at 5:29 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I will move the rest to treated. Except I you shout and tell me that your code is ready for integration.
Does it mean you will ignore everything but these 3 fixes? I don't understand why. If you don't have time, just don't harvest them.
-- Damien Cassou http://damiencassou.seasidehosting.st
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 11/8/08, Noury Bouraqadi <bouraqadi@ensm-douai.fr> wrote:
Thanks Lukas for the feedback. Now I have some questions:
-For fuctionality 1 : Because of the dependency with the RefactoringBrowser, which obviously shouldn't be in the core image. Does it make sense to have it in an external package ? It's handy to avoid using multiple tools when renaming a Monticello Package and the corresponding class prefixes. But, may be should I reimplement without reusing the RefactoringBrowser ?
Renaming all classes of a package doesn't really make sense without fixing all references automatically. It is certainly a pain to do without the refactoring tools. But, as I said, this functionality is already part of the OB refactoring tools.
-Is fuctionality 2 useful for other people than me ?
It is definitely useful. For the Seaside 2.9 repackaging effort we had to rename sevaral packages manually. A solid tool would be a huge advantage. Cheers, Lukas Fixing the issues
you identified wouldn't be a big challenge.
Noury On 7 nov. 08, at 22:26, Lukas Renggli wrote:
The package MonticelloPackageRenaming-Noury.1 introduces 2 new menu items into the Monticello Browser, by overriding and extending several methods in Monticello. If this code is included with Pharo, it should become part of Monticello itself. There are 4 test cases included.
Below I review the two new functionalities independently:
1. Replace Classes Prefix: This functionality is useful, however the implementation depends on the presence of the Refactoring Browser. Furthermore this functionality is already present in the Refactoring Browser (OB-Regex) in a more generic fashion. Open | Rewrite Class allows one to batch rename, batch copy and batch create a set of classes using regular expressions.
2. Rename Package: This functionality renames class categories and method protocols to match the new package name. The code also takes care of the dependencies and removing traces of the old package in the Monticello Browser. It does not depend on external functionality. There are however 3 major problems with the implementation: (1) Class extensions extinct if they do not match the package names in a case-sensitive way. PackageInfo treats class categories case-sensitive, but protocols are handled case-insensitive. (2) Packages that share the same prefix are wrongly renamed, even if PackageInfo does not consider them to be from the same package (for example Morphic and MorphicExtras). (3) The ancestry of the renamed package is not preserved, what makes merging packages across renaming impossible. Though, I don't know if such a functionality would be possible with Monticello at all?
Given the number of problems I don't suggest to include these extensions for now.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Noury Bouraqadi ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury
European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
For package renaming, in the past I have temporarily borrowed the #copyAll function in order that all packages and their history are renamed as they are transferred from one repository to another. Keith
On Sat, Nov 8, 2008 at 1:45 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
No totally I just clean what I could. For example, I asked you if you could redo your embedded world. because with the changes lukas did we got a lot of noise.
Sorry, I was not registered to the issue. I am now and will republish. -- Damien Cassou http://damiencassou.seasidehosting.st
excellent! Stef On Nov 9, 2008, at 12:20 PM, Damien Cassou wrote:
On Sat, Nov 8, 2008 at 1:45 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
No totally I just clean what I could. For example, I asked you if you could redo your embedded world. because with the changes lukas did we got a lot of noise.
Sorry, I was not registered to the issue. I am now and will republish.
-- Damien Cassou http://damiencassou.seasidehosting.st
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sat, Nov 8, 2008 at 1:45 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
For example, I asked you if you could redo your embedded world.
Please review http://code.google.com/p/pharo/issues/detail?id=273. -- Damien Cassou http://damiencassou.seasidehosting.st
Thanks I will have a look at it after kids readings :) Stef On Nov 11, 2008, at 7:51 PM, Damien Cassou wrote:
On Sat, Nov 8, 2008 at 1:45 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
For example, I asked you if you could redo your embedded world.
Please review http://code.google.com/p/pharo/issues/detail?id=273.
-- Damien Cassou http://damiencassou.seasidehosting.st
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Damien Cassou -
Keith Hodges -
Lukas Renggli -
Noury Bouraqadi -
Stéphane Ducasse