[Pharo-project] RPackage, Monticello and the removal of PackageInfo
Hi, As you know, we want to replace the old PackageInfo structure with RPackage. Last weeks Pharo 2.0 has been really unstable because of this effort, and it will be unstable yet a few days more, so I want to review the actions we are taking, so you know why this happnes and the result we want to obtain. So... first: Why replace PackageInfo and PackageOrganizer? The short answer is: because they suck :) The more or less long answer is: because their existence introduces a lot of penalties in the system, and forces to a lot of workarounds to manage what should be a simple system categories manager... take for instance the match MCPackage-PackageInfo-Class categories. Each MCPackage maps to a unique PackageInfo, but package info contains string pattern matched class categories. Tools uses this and well... performance is frankly disappointing in many case. Like this, there are lots of other reasons. So... RPackage will solve this by keeping a view of the system, not having to calculate it everytime. RPackage will keep also the list of classes, extension, etc. so tools can operate with them in a better/faster way. Question is: How to migrate in the less painful way? Attempt 1) Let each RPackage be one PackageInfo. We first thought this was the best path so, we spend some time moving in that direction. The advantage is that migration from Monticello and PackageInfo is trivial, but then the problems started to happen: PackageInfo (and current RPackage) contains N class categories so, there is an impedance mismatch between what we was seeing and what users/tools expect (they work with class categories, not with RPackage or PackageInfo). To solve that, we added class categories as RPackage tags (yep RPackage allows you to tag classes). But then we need to update in ver annoying ways the tools. And we also has now the fact that class categories are now a tag into an RPackage. Something really obscure and that was causing a lot of pain... So, we rolled back... Attempt 2) Let each Class Category be one RPackage. Ok, this is very simple (and that's the beauty on it)... each tools and conventions will match perfectly. Only problem here is that now, Monticello is not compatible anymore. So, we worked on the concept of RPackageSet, to replace PackageInfo use into Monticelo packages (we need them to load/save packages and stay compatible). RPackageSet is exactly what its name says: a set of RPackage instances (created on the fly, by pattern matching, so, is still some kind of a hack), that is polymorphic with PackageInfo in the monticello context. Thus, everything in the system can remain unchanged (or almost no change, the refactoring engine needs some adjusts). One extra bonus with this approach is that it let us think on more cool refactors in the future: we can for instance replace class categories (now a symbol) with an RPackage... and continue simplifying the system in several ways. ...and that's where we are now. We are working hard on stabilizing the system, but that will take still some days more... after that, we will be really close to the PackageInfo removal. PLEASE: PackageInfo users, take this into account: PackageInfo will pass away... and is one of the parts of the system that cannot be deprecated, they has to be completely removed, prepare your tools for the rise of RPackage :) Cheers, Esteban
I am also for the 2 option :) On Fri, Sep 7, 2012 at 6:13 PM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
Hi,
As you know, we want to replace the old PackageInfo structure with RPackage. Last weeks Pharo 2.0 has been really unstable because of this effort, and it will be unstable yet a few days more, so I want to review the actions we are taking, so you know why this happnes and the result we want to obtain. So... first: Why replace PackageInfo and PackageOrganizer? The short answer is: because they suck :) The more or less long answer is: because their existence introduces a lot of penalties in the system, and forces to a lot of workarounds to manage what should be a simple system categories manager... take for instance the match MCPackage-PackageInfo-Class categories. Each MCPackage maps to a unique PackageInfo, but package info contains string pattern matched class categories. Tools uses this and well... performance is frankly disappointing in many case. Like this, there are lots of other reasons. So... RPackage will solve this by keeping a view of the system, not having to calculate it everytime. RPackage will keep also the list of classes, extension, etc. so tools can operate with them in a better/faster way.
Question is: How to migrate in the less painful way?
Attempt 1) Let each RPackage be one PackageInfo.
We first thought this was the best path so, we spend some time moving in that direction. The advantage is that migration from Monticello and PackageInfo is trivial, but then the problems started to happen: PackageInfo (and current RPackage) contains N class categories so, there is an impedance mismatch between what we was seeing and what users/tools expect (they work with class categories, not with RPackage or PackageInfo). To solve that, we added class categories as RPackage tags (yep RPackage allows you to tag classes). But then we need to update in ver annoying ways the tools. And we also has now the fact that class categories are now a tag into an RPackage. Something really obscure and that was causing a lot of pain...
So, we rolled back...
Attempt 2) Let each Class Category be one RPackage.
Ok, this is very simple (and that's the beauty on it)... each tools and conventions will match perfectly. Only problem here is that now, Monticello is not compatible anymore. So, we worked on the concept of RPackageSet, to replace PackageInfo use into Monticelo packages (we need them to load/save packages and stay compatible). RPackageSet is exactly what its name says: a set of RPackage instances (created on the fly, by pattern matching, so, is still some kind of a hack), that is polymorphic with PackageInfo in the monticello context. Thus, everything in the system can remain unchanged (or almost no change, the refactoring engine needs some adjusts). One extra bonus with this approach is that it let us think on more cool refactors in the future: we can for instance replace class categories (now a symbol) with an RPackage... and continue simplifying the system in several ways.
...and that's where we are now. We are working hard on stabilizing the system, but that will take still some days more... after that, we will be really close to the PackageInfo removal.
PLEASE: PackageInfo users, take this into account: PackageInfo will pass away... and is one of the parts of the system that cannot be deprecated, they has to be completely removed, prepare your tools for the rise of RPackage :)
Cheers, Esteban
-- Mariano http://marianopeck.wordpress.com
2012/9/7 Mariano Martinez Peck <marianopeck@gmail.com>:
I am also for the 2 option :)
On Fri, Sep 7, 2012 at 6:13 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
As you know, we want to replace the old PackageInfo structure with RPackage. Last weeks Pharo 2.0 has been really unstable because of this effort, and it will be unstable yet a few days more, so I want to review the actions we are taking, so you know why this happnes and the result we want to obtain. So... first: Why replace PackageInfo and PackageOrganizer? The short answer is: because they suck :) The more or less long answer is: because their existence introduces a lot of penalties in the system, and forces to a lot of workarounds to manage what should be a simple system categories manager... take for instance the match MCPackage-PackageInfo-Class categories. Each MCPackage maps to a unique PackageInfo, but package info contains string pattern matched class categories. Tools uses this and well... performance is frankly disappointing in many case. Like this, there are lots of other reasons. So... RPackage will solve this by keeping a view of the system, not having to calculate it everytime. RPackage will keep also the list of classes, extension, etc. so tools can operate with them in a better/faster way.
Question is: How to migrate in the less painful way?
Attempt 1) Let each RPackage be one PackageInfo.
We first thought this was the best path so, we spend some time moving in that direction. The advantage is that migration from Monticello and PackageInfo is trivial, but then the problems started to happen: PackageInfo (and current RPackage) contains N class categories so, there is an impedance mismatch between what we was seeing and what users/tools expect (they work with class categories, not with RPackage or PackageInfo). To solve that, we added class categories as RPackage tags (yep RPackage allows you to tag classes). But then we need to update in ver annoying ways the tools. And we also has now the fact that class categories are now a tag into an RPackage. Something really obscure and that was causing a lot of pain...
Good thing to have a rationale for where you want to be going and why... It would be interesting to have it documented.For example: - A package is holding strong references to class/methods belonging to it or not? - Does a class know (directly point to) its package, or is it a service provided by some helper object? - Does a method know (directly point to) its package, or is it a service provided by some helper object? - Are there unpackaged classes/methods (pointing to nil?), is there a service to discover them? - What is the relation with st80 classification (class categories and method protocols)? Is it completely orthogonal? - Should class/methods have multi-classification (belong to several categories protocols)? You can call that tags if you want... pro/cons for each point Then it's another thing to tell how you will reach these goals, and if/how you will maintain compatibility with MC (a vital tool) or other tools (browsers nautilus RB change list/change sorter etc...) - which might be possible by faking categories/protocols. For french: Je dirai qu'on a l'eau à la bouche, mais qu'on reste un peu sur notre faim ;)
So, we rolled back...
Attempt 2) Let each Class Category be one RPackage.
Ok, this is very simple (and that's the beauty on it)... each tools and conventions will match perfectly. Only problem here is that now, Monticello is not compatible anymore. So, we worked on the concept of RPackageSet, to replace PackageInfo use into Monticelo packages (we need them to load/save packages and stay compatible). RPackageSet is exactly what its name says: a set of RPackage instances (created on the fly, by pattern matching, so, is still some kind of a hack), that is polymorphic with PackageInfo in the monticello context. Thus, everything in the system can remain unchanged (or almost no change, the refactoring engine needs some adjusts). One extra bonus with this approach is that it let us think on more cool refactors in the future: we can for instance replace class categories (now a symbol) with an RPackage... and continue simplifying the system in several ways.
...and that's where we are now. We are working hard on stabilizing the system, but that will take still some days more... after that, we will be really close to the PackageInfo removal.
Good, if the system was too complex in order to analyze all implications and completely planify the change path, then trial and error might be a solution, it's not a shame, but you have to write your goals to better remind them, and maybe make some amendments to your rationale because of some unanticipated features (and providing some degree of compatibility can lead to additional features).
PLEASE: PackageInfo users, take this into account: PackageInfo will pass away... and is one of the parts of the system that cannot be deprecated, they has to be completely removed, prepare your tools for the rise of RPackage :)
Cheers, Esteban
Such a change will require a stable and if possible well documented API (which should be quite straightforward once you have rationalized your design). Nicolas
-- Mariano http://marianopeck.wordpress.com
Good thing to have a rationale for where you want to be going and why... It would be interesting to have it documented.For example: - A package is holding strong references to class/methods belonging to it or not?
did you read the class comment of RPackage? Because this is explained normally. Now the answer a RPackage does not hold references to class or compiledMethod but to class names and selectors so that it could potentially be used for now working classes.
- Does a class know (directly point to) its package, or is it a service provided by some helper object?
RPackageOrganizer so far we did not modify class but manage the invariant class/package using announcement
- Does a method know (directly point to) its package, or is it a service provided by some helper object?
CompiledMethod package and this is manager by PackageOrganizer
- Are there unpackaged classes/methods (pointing to nil?), is there a service to discover them?
Not that I know.
- What is the relation with st80 classification (class categories and method protocols)? Is it completely orthogonal?
Totally.
- Should class/methods have multi-classification (belong to several categories protocols)?
A class belongs to only one packages Now you can have tags (I implemented it but may be we will not use it) to have virtual categories For methods packages are orthogonal to categories (now we are maintaining for the moment the * notation).
You can call that tags if you want... pro/cons for each point
Then it's another thing to tell how you will reach these goals, and if/how you will maintain compatibility with MC (a vital tool) or other tools (browsers nautilus RB change list/change sorter etc...) - which might be possible by faking categories/protocols.
the compatibility is first when you load -> * star notation in the mcz -> category announcement -> extension in the repackage saving -> we should check that the package and the categories get the same contents -> saving with * in category So for now we will maintain a compatibility and in the future we will see.
For french: Je dirai qu'on a l'eau à la bouche, mais qu'on reste un peu sur notre faim ;)
So, we rolled back...
Attempt 2) Let each Class Category be one RPackage.
Ok, this is very simple (and that's the beauty on it)... each tools and conventions will match perfectly. Only problem here is that now, Monticello is not compatible anymore. So, we worked on the concept of RPackageSet, to replace PackageInfo use into Monticelo packages (we need them to load/save packages and stay compatible). RPackageSet is exactly what its name says: a set of RPackage instances (created on the fly, by pattern matching, so, is still some kind of a hack), that is polymorphic with PackageInfo in the monticello context. Thus, everything in the system can remain unchanged (or almost no change, the refactoring engine needs some adjusts). One extra bonus with this approach is that it let us think on more cool refactors in the future: we can for instance replace class categories (now a symbol) with an RPackage... and continue simplifying the system in several ways.
...and that's where we are now. We are working hard on stabilizing the system, but that will take still some days more... after that, we will be really close to the PackageInfo removal.
Good, if the system was too complex in order to analyze all implications and completely planify the change path, then trial and error might be a solution, it's not a shame, but you have to write your goals to better remind them, and maybe make some amendments to your rationale because of some unanticipated features (and providing some degree of compatibility can lead to additional features).
Compatibitilty of MC and configurations will be maintain. If we could have got rid of the last one it would have solved a lot of our pain.
PLEASE: PackageInfo users, take this into account: PackageInfo will pass away... and is one of the parts of the system that cannot be deprecated, they has to be completely removed, prepare your tools for the rise of RPackage :)
Cheers, Esteban
Such a change will require a stable and if possible well documented API (which should be quite straightforward once you have rationalized your design).
Have a look at the RPackage class. It is really nice. The pain is not it, the pain is the system and the pattern matching and event and â¦. and having packages and categories. Stef
Nicolas
-- Mariano http://marianopeck.wordpress.com
Ok, It's good to know, because, for me, as I was / I am trying to track the changes in RPackage for the past two weeks, it seemed that RPackage was happily oscillating between 1 and 2, and, to add to the fun, backporting it's instability by creating spurious packages in Monticello on the way. Oh well, I almost managed to stabilize on 1), now I'll have to recode for 2). Should have stuck to PackageInfo :-(. Is there a plan to have clear semantics of the different matches planned (extension categories and sub categories, class category, package sub-category) ? Monticello has already set a few conventions (not case sensitive, for example) (and they are not respected by quite a few packages) and not a few of the RPackage bugs are linked to it not respecting it (i.e. some methods of package matching in RPackage are case sensitive, whereas they are not in MCWorkingCopy) ? Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Esteban Lorenzano [estebanlm@gmail.com] Date d'envoi : vendredi 7 septembre 2012 18:13 Ã : Pharo-project@lists.gforge.inria.fr Development Objet : [Pharo-project] RPackage, Monticello and the removal of PackageInfo Hi, As you know, we want to replace the old PackageInfo structure with RPackage. Last weeks Pharo 2.0 has been really unstable because of this effort, and it will be unstable yet a few days more, so I want to review the actions we are taking, so you know why this happnes and the result we want to obtain. So... first: Why replace PackageInfo and PackageOrganizer? The short answer is: because they suck :) The more or less long answer is: because their existence introduces a lot of penalties in the system, and forces to a lot of workarounds to manage what should be a simple system categories manager... take for instance the match MCPackage-PackageInfo-Class categories. Each MCPackage maps to a unique PackageInfo, but package info contains string pattern matched class categories. Tools uses this and well... performance is frankly disappointing in many case. Like this, there are lots of other reasons. So... RPackage will solve this by keeping a view of the system, not having to calculate it everytime. RPackage will keep also the list of classes, extension, etc. so tools can operate with them in a better/faster way. Question is: How to migrate in the less painful way? Attempt 1) Let each RPackage be one PackageInfo. We first thought this was the best path so, we spend some time moving in that direction. The advantage is that migration from Monticello and PackageInfo is trivial, but then the problems started to happen: PackageInfo (and current RPackage) contains N class categories so, there is an impedance mismatch between what we was seeing and what users/tools expect (they work with class categories, not with RPackage or PackageInfo). To solve that, we added class categories as RPackage tags (yep RPackage allows you to tag classes). But then we need to update in ver annoying ways the tools. And we also has now the fact that class categories are now a tag into an RPackage. Something really obscure and that was causing a lot of pain... So, we rolled back... Attempt 2) Let each Class Category be one RPackage. Ok, this is very simple (and that's the beauty on it)... each tools and conventions will match perfectly. Only problem here is that now, Monticello is not compatible anymore. So, we worked on the concept of RPackageSet, to replace PackageInfo use into Monticelo packages (we need them to load/save packages and stay compatible). RPackageSet is exactly what its name says: a set of RPackage instances (created on the fly, by pattern matching, so, is still some kind of a hack), that is polymorphic with PackageInfo in the monticello context. Thus, everything in the system can remain unchanged (or almost no change, the refactoring engine needs some adjusts). One extra bonus with this approach is that it let us think on more cool refactors in the future: we can for instance replace class categories (now a symbol) with an RPackage... and continue simplifying the system in several ways. ...and that's where we are now. We are working hard on stabilizing the system, but that will take still some days more... after that, we will be really close to the PackageInfo removal. PLEASE: PackageInfo users, take this into account: PackageInfo will pass away... and is one of the parts of the system that cannot be deprecated, they has to be completely removed, prepare your tools for the rise of RPackage :) Cheers, Esteban
On Sep 7, 2012, at 8:44 PM, GOUBIER Thierry wrote:
Ok,
It's good to know, because, for me, as I was / I am trying to track the changes in RPackage for the past two weeks, it seemed that RPackage was happily oscillating between 1 and 2, and, to add to the fun, backporting it's instability by creating spurious packages in Monticello on the way.
Oh well, I almost managed to stabilize on 1), now I'll have to recode for 2). Should have stuck to PackageInfo :-(.
you are not the only one. Benjamin too. Now we are fighting with it and this is just not for fun.
Is there a plan to have clear semantics of the different matches planned (extension categories and sub categories, class category, package sub-category) ?
Yes Ideally we want one MCPackage - one RPackage + tags Nothing more (no class category, no package info). Now we should be able to remove class categories. But this does not work easily because everybody would have to rewrite configurationOf for their projects (since each categories would be turned into a package). So may be when versionner will be working we can add a behavior to migrate automatically configuration. So esteban will see if his idea is working which leads to a first class category and we can in a second period go more towards one MCPackage - one RPackage with tagged classes.
Monticello has already set a few conventions (not case sensitive, for example) (and they are not respected by quite a few packages) and not a few of the RPackage bugs are linked to it not respecting it (i.e. some methods of package matching in RPackage are case sensitive, whereas they are not in MCWorkingCopy) ?
You forgot to add "crap in PackageOrganizer." So yes it would be good to clean all that. RPackage is totally agostic to naming conventions but we have to create them and support backward compatibility.
It's hard to converse with that Exchange webmail. Oh, Ok, here it goes. The one MCPackage _ One RPackage I'm Ok with, I made that working with my browser. But if this is the goal, then the current code is almost there and option 2) isn't needed ? A RPackage (the one with tags) clearly represent well what a MCPackage can be, bugs apart. (technically, it's a bit wider, since extension methods may belong to any protocol, not just the *PackageName : the AltBrowser consequently hides the extension name, which is interesting at the GUI level and works very well). The only thing needed is to make sure than when Monticello says X belongs to MCPackage A, that RPackageOrganizer doesn't say that X belongs to RPackage B instead, and the reverse. There is a fault in the RPackage introduction there, which is that both RPackageOrganizer and Monticello are tracking system announcements, and giving them different meanings (and RPackage propagate its changes to Monticello). I am at around 10 Pharo images I had to scrap because the damage done by those bugs was beyond repair. When you say force people to have one class category, one RPackage, that I do not understand why. As stated above, you have everything to handle multiple class categories in a RPackage. Why add a RPackageSet layer above ? Why make the transition break that ? (RPackage is not, in my opinion, naming agnostic. The main bugs I found in RPackage are because someone believe it is, where it isn't) One thing I would suggest is : remove Monticello from system announcements. Make RPackageOrganizer in charge of updating the MCWorkingCopy as needed (have a coherent view of the system). Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : vendredi 7 septembre 2012 21:37 à : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RPackage, Monticello and the removal of PackageInfo On Sep 7, 2012, at 8:44 PM, GOUBIER Thierry wrote:
Ok,
It's good to know, because, for me, as I was / I am trying to track the changes in RPackage for the past two weeks, it seemed that RPackage was happily oscillating between 1 and 2, and, to add to the fun, backporting it's instability by creating spurious packages in Monticello on the way.
Oh well, I almost managed to stabilize on 1), now I'll have to recode for 2). Should have stuck to PackageInfo :-(.
you are not the only one. Benjamin too. Now we are fighting with it and this is just not for fun.
Is there a plan to have clear semantics of the different matches planned (extension categories and sub categories, class category, package sub-category) ?
Yes Ideally we want one MCPackage - one RPackage + tags Nothing more (no class category, no package info). Now we should be able to remove class categories. But this does not work easily because everybody would have to rewrite configurationOf for their projects (since each categories would be turned into a package). So may be when versionner will be working we can add a behavior to migrate automatically configuration. So esteban will see if his idea is working which leads to a first class category and we can in a second period go more towards one MCPackage - one RPackage with tagged classes.
Monticello has already set a few conventions (not case sensitive, for example) (and they are not respected by quite a few packages) and not a few of the RPackage bugs are linked to it not respecting it (i.e. some methods of package matching in RPackage are case sensitive, whereas they are not in MCWorkingCopy) ?
You forgot to add "crap in PackageOrganizer." So yes it would be good to clean all that. RPackage is totally agostic to naming conventions but we have to create them and support backward compatibility.
Hi, On Sep 7, 2012, at 10:08 PM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
It's hard to converse with that Exchange webmail. Oh, Ok, here it goes.
The one MCPackage _ One RPackage I'm Ok with, I made that working with my browser. But if this is the goal, then the current code is almost there and option 2) isn't needed ? A RPackage (the one with tags) clearly represent well what a MCPackage can be, bugs apart. (technically, it's a bit wider, since extension methods may belong to any protocol, not just the *PackageName : the AltBrowser consequently hides the extension name, which is interesting at the GUI level and works very well).
That's not the goal... that *was* the goal. The goal is to have a good representation of the system with RPackage. And no, we were not close, we were very far away to be close. Here is the thing 1 MCPackage = 1 RPackage breaks everything. Tags are just tags and don't have coherence with Class Categories. Now, 1 MCPackage = N RPackage has much more sense because stresses a lot less the system. Now, what Stef is saying is that we wanted 1 to 1 correspondence, but a lot larger granularity... that means MCPackage matching current class categories. Not the opposite... but that means we need to ask everybody to adapt their monticello and configurations to match that vision, and that's something that it's not going to happen, not just because, for instance, Seaside has already tons of packages, do you imagine with the proposed granularity? Also, Versionner or other tools can help to reduce the fear to that granularity in the future, but that's not going to happen tomorrow. So, I'm really sorry your work was almost ported and we changed the rules... and I'm sorry that while looking for the best solution for everybody we some times break somethings, but that's are the risks of developing over bleeding edge :(
The only thing needed is to make sure than when Monticello says X belongs to MCPackage A, that RPackageOrganizer doesn't say that X belongs to RPackage B instead, and the reverse. There is a fault in the RPackage introduction there, which is that both RPackageOrganizer and Monticello are tracking system announcements, and giving them different meanings (and RPackage propagate its changes to Monticello). I am at around 10 Pharo images I had to scrap because the damage done by those bugs was beyond repair.
When you say force people to have one class category, one RPackage, that I do not understand why. As stated above, you have everything to handle multiple class categories in a RPackage. Why add a RPackageSet layer above ? Why make the transition break that ?
"Force" is a strong word. We don't force anyone... RPackage is a construction with a purpose, not a general malleable tool. It is not a tool to create your package with your desired format. Is a way to represent the fact that system is composed from classes, who are grouped in units called categories. Categories are there for the human eye, not for the system... now, the common convention around those categories is that you see them in class declaration, as class categories, and in browser "packages" panel. Monticello packages, in other term, are conceptually collections of class categories packaged together. So... for me is important to maintain that notion. Now, there are two point of views: 1) you have a new completely different infrastructure (aka RPackage+tags) to represent system, and then adapt (I can say "force" too) all the tools to this (which is a lot of work). For me it looks like a hack (we have something and we force the tools to show other thing, just because), and also no real necessity to do it, or 2) we took our new packaging system and make it work in the most simplest way possible, focusing on maintain the system as close to the eyes as possible. RPackageSet represents a notion for Monticello packages grouping packages (and btw, it can disappear in the future, because RPackageSet responsibility belongs most probably to regular MCPackages), and RPackage instances who matches to what users expect most probably about the organization categories in their system. Our error was trying to take approach 1 first... not take path approach 2 now... and it was an error because after one month of working on that direction, the system was more and more unstable and chaotic and complex, and not what it should happens, which was the opposite.
(RPackage is not, in my opinion, naming agnostic. The main bugs I found in RPackage are because someone believe it is, where it isn't)
you're right, it is not.
One thing I would suggest is : remove Monticello from system announcements. Make RPackageOrganizer in charge of updating the MCWorkingCopy as needed (have a coherent view of the system).
That just don't work. If we remove monticello from SA, monticello doesn't know what changed and needs to reconstruct every time its state... which also means that monticello gui cannot be updated either. Esteban
Thierry
________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : vendredi 7 septembre 2012 21:37 à : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RPackage, Monticello and the removal of PackageInfo
On Sep 7, 2012, at 8:44 PM, GOUBIER Thierry wrote:
Ok,
It's good to know, because, for me, as I was / I am trying to track the changes in RPackage for the past two weeks, it seemed that RPackage was happily oscillating between 1 and 2, and, to add to the fun, backporting it's instability by creating spurious packages in Monticello on the way.
Oh well, I almost managed to stabilize on 1), now I'll have to recode for 2). Should have stuck to PackageInfo :-(.
you are not the only one. Benjamin too. Now we are fighting with it and this is just not for fun.
Is there a plan to have clear semantics of the different matches planned (extension categories and sub categories, class category, package sub-category) ?
Yes Ideally we want one MCPackage - one RPackage + tags
Nothing more (no class category, no package info). Now we should be able to remove class categories. But this does not work easily because everybody would have to rewrite configurationOf for their projects (since each categories would be turned into a package). So may be when versionner will be working we can add a behavior to migrate automatically configuration.
So esteban will see if his idea is working which leads to a first class category and we can in a second period go more towards one MCPackage - one RPackage with tagged classes.
Monticello has already set a few conventions (not case sensitive, for example) (and they are not respected by quite a few packages) and not a few of the RPackage bugs are linked to it not respecting it (i.e. some methods of package matching in RPackage are case sensitive, whereas they are not in MCWorkingCopy) ?
You forgot to add "crap in PackageOrganizer." So yes it would be good to clean all that. RPackage is totally agostic to naming conventions but we have to create them and support backward compatibility.
I will be a bit harder to convince then. 1 MCPackage = N RPackage doesn't strike me as any better than 1 MCPackage = 1 RPackage with tags, apart from performance issues. Remember that I was using option 1 in depth and hitting bugs, but not that much. My opinion is that you don't really know what went wrong with option 1, except the implementation became unmanageable. So, I expect option 2 to be hardly better, sadly. And, as it promises breaking existing configurations, it will be a lot more fun ! By the way, if you enlarge the vision with RPackage, and think about the size of the overall system and how it has evolved a lot since the class categories of the beginning of Smalltalk, then your option 2 is, for me, already obsolete. You need more levels than the two you are promising with option 2. Scrolling throught thousands of categories is not fun; having packages which add hundreds of methods as an extension to a class is clearly not scalable and manageable. And scrolling through hundreds of package isn't either (or are you all working on 30" screens ? I'm not.).
That just don't work. If we remove monticello from SA, monticello doesn't know what changed and needs to >reconstruct every time its state... which also means that monticello gui cannot be updated either.
This is wrong, since RPackageOrganizer, being aware of the changes, could update monticello and maintain a coherent view. It would have made the situation a tiny bit better. Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Esteban Lorenzano [estebanlm@gmail.com] Date d'envoi : vendredi 7 septembre 2012 22:37 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : RPackage, Monticello and the removal of PackageInfo Hi, On Sep 7, 2012, at 10:08 PM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
It's hard to converse with that Exchange webmail. Oh, Ok, here it goes.
The one MCPackage _ One RPackage I'm Ok with, I made that working with my browser. But if this is the goal, then the current code is almost there and option 2) isn't needed ? A RPackage (the one with tags) clearly represent well what a MCPackage can be, bugs apart. (technically, it's a bit wider, since extension methods may belong to any protocol, not just the *PackageName : the AltBrowser consequently hides the extension name, which is interesting at the GUI level and works very well).
That's not the goal... that *was* the goal. The goal is to have a good representation of the system with RPackage. And no, we were not close, we were very far away to be close. Here is the thing 1 MCPackage = 1 RPackage breaks everything. Tags are just tags and don't have coherence with Class Categories. Now, 1 MCPackage = N RPackage has much more sense because stresses a lot less the system. Now, what Stef is saying is that we wanted 1 to 1 correspondence, but a lot larger granularity... that means MCPackage matching current class categories. Not the opposite... but that means we need to ask everybody to adapt their monticello and configurations to match that vision, and that's something that it's not going to happen, not just because, for instance, Seaside has already tons of packages, do you imagine with the proposed granularity? Also, Versionner or other tools can help to reduce the fear to that granularity in the future, but that's not going to happen tomorrow. So, I'm really sorry your work was almost ported and we changed the rules... and I'm sorry that while looking for the best solution for everybody we some times break somethings, but that's are the risks of developing over bleeding edge :(
The only thing needed is to make sure than when Monticello says X belongs to MCPackage A, that RPackageOrganizer doesn't say that X belongs to RPackage B instead, and the reverse. There is a fault in the RPackage introduction there, which is that both RPackageOrganizer and Monticello are tracking system announcements, and giving them different meanings (and RPackage propagate its changes to Monticello). I am at around 10 Pharo images I had to scrap because the damage done by those bugs was beyond repair.
When you say force people to have one class category, one RPackage, that I do not understand why. As stated above, you have everything to handle multiple class categories in a RPackage. Why add a RPackageSet layer above ? Why make the transition break that ?
"Force" is a strong word. We don't force anyone... RPackage is a construction with a purpose, not a general malleable tool. It is not a tool to create your package with your desired format. Is a way to represent the fact that system is composed from classes, who are grouped in units called categories. Categories are there for the human eye, not for the system... now, the common convention around those categories is that you see them in class declaration, as class categories, and in browser "packages" panel. Monticello packages, in other term, are conceptually collections of class categories packaged together. So... for me is important to maintain that notion. Now, there are two point of views: 1) you have a new completely different infrastructure (aka RPackage+tags) to represent system, and then adapt (I can say "force" too) all the tools to this (which is a lot of work). For me it looks like a hack (we have something and we force the tools to show other thing, just because), and also no real necessity to do it, or 2) we took our new packaging system and make it work in the most simplest way possible, focusing on maintain the system as close to the eyes as possible. RPackageSet represents a notion for Monticello packages grouping packages (and btw, it can disappear in the future, because RPackageSet responsibility belongs most probably to regular MCPackages), and RPackage instances who matches to what users expect most probably about the organization categories in their system. Our error was trying to take approach 1 first... not take path approach 2 now... and it was an error because after one month of working on that direction, the system was more and more unstable and chaotic and complex, and not what it should happens, which was the opposite.
(RPackage is not, in my opinion, naming agnostic. The main bugs I found in RPackage are because someone believe it is, where it isn't)
you're right, it is not.
One thing I would suggest is : remove Monticello from system announcements. Make RPackageOrganizer in charge of updating the MCWorkingCopy as needed (have a coherent view of the system).
That just don't work. If we remove monticello from SA, monticello doesn't know what changed and needs to reconstruct every time its state... which also means that monticello gui cannot be updated either. Esteban
Thierry
________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : vendredi 7 septembre 2012 21:37 à : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RPackage, Monticello and the removal of PackageInfo
On Sep 7, 2012, at 8:44 PM, GOUBIER Thierry wrote:
Ok,
It's good to know, because, for me, as I was / I am trying to track the changes in RPackage for the past two weeks, it seemed that RPackage was happily oscillating between 1 and 2, and, to add to the fun, backporting it's instability by creating spurious packages in Monticello on the way.
Oh well, I almost managed to stabilize on 1), now I'll have to recode for 2). Should have stuck to PackageInfo :-(.
you are not the only one. Benjamin too. Now we are fighting with it and this is just not for fun.
Is there a plan to have clear semantics of the different matches planned (extension categories and sub categories, class category, package sub-category) ?
Yes Ideally we want one MCPackage - one RPackage + tags
Nothing more (no class category, no package info). Now we should be able to remove class categories. But this does not work easily because everybody would have to rewrite configurationOf for their projects (since each categories would be turned into a package). So may be when versionner will be working we can add a behavior to migrate automatically configuration.
So esteban will see if his idea is working which leads to a first class category and we can in a second period go more towards one MCPackage - one RPackage with tagged classes.
Monticello has already set a few conventions (not case sensitive, for example) (and they are not respected by quite a few packages) and not a few of the RPackage bugs are linked to it not respecting it (i.e. some methods of package matching in RPackage are case sensitive, whereas they are not in MCWorkingCopy) ?
You forgot to add "crap in PackageOrganizer." So yes it would be good to clean all that. RPackage is totally agostic to naming conventions but we have to create them and support backward compatibility.
On Sep 7, 2012, at 11:04 PM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
I will be a bit harder to convince then. 1 MCPackage = N RPackage doesn't strike me as any better than 1 MCPackage = 1 RPackage with tags, apart from performance issues. Remember that I was using option 1 in depth and hitting bugs, but not that much.
My opinion is that you don't really know what went wrong with option 1, except the implementation became unmanageable. So, I expect option 2 to be hardly better, sadly. And, as it promises breaking existing configurations, it will be a lot more fun !
Yeah, probably I'm just not smart enough... I'm sorry not being at the required level, I just do my best. But then, this was largely discussed in the team, with Marcus, Guille, Camillo and Mariano (and also with Stef, btw)... we discussed the problem and together we decided the path to follow.
By the way, if you enlarge the vision with RPackage, and think about the size of the overall system and how it has evolved a lot since the class categories of the beginning of Smalltalk, then your option 2 is, for me, already obsolete. You need more levels than the two you are promising with option 2. Scrolling throught thousands of categories is not fun; having packages which add hundreds of methods as an extension to a class is clearly not scalable and manageable. And scrolling through hundreds of package isn't either (or are you all working on 30" screens ? I'm not.).
That just don't work. If we remove monticello from SA, monticello doesn't know what changed and needs to >reconstruct every time its state... which also means that monticello gui cannot be updated either.
This is wrong, since RPackageOrganizer, being aware of the changes, could update monticello and maintain a coherent view. It would have made the situation a tiny bit better.
By coupling RPackageOrganizer with Monticello. Nice piece of design :) Esteban
Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Esteban Lorenzano [estebanlm@gmail.com] Date d'envoi : vendredi 7 septembre 2012 22:37 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : RPackage, Monticello and the removal of PackageInfo
Hi,
On Sep 7, 2012, at 10:08 PM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
It's hard to converse with that Exchange webmail. Oh, Ok, here it goes.
The one MCPackage _ One RPackage I'm Ok with, I made that working with my browser. But if this is the goal, then the current code is almost there and option 2) isn't needed ? A RPackage (the one with tags) clearly represent well what a MCPackage can be, bugs apart. (technically, it's a bit wider, since extension methods may belong to any protocol, not just the *PackageName : the AltBrowser consequently hides the extension name, which is interesting at the GUI level and works very well).
That's not the goal... that *was* the goal. The goal is to have a good representation of the system with RPackage. And no, we were not close, we were very far away to be close. Here is the thing 1 MCPackage = 1 RPackage breaks everything. Tags are just tags and don't have coherence with Class Categories. Now, 1 MCPackage = N RPackage has much more sense because stresses a lot less the system.
Now, what Stef is saying is that we wanted 1 to 1 correspondence, but a lot larger granularity... that means MCPackage matching current class categories. Not the opposite... but that means we need to ask everybody to adapt their monticello and configurations to match that vision, and that's something that it's not going to happen, not just because, for instance, Seaside has already tons of packages, do you imagine with the proposed granularity? Also, Versionner or other tools can help to reduce the fear to that granularity in the future, but that's not going to happen tomorrow.
So, I'm really sorry your work was almost ported and we changed the rules... and I'm sorry that while looking for the best solution for everybody we some times break somethings, but that's are the risks of developing over bleeding edge :(
The only thing needed is to make sure than when Monticello says X belongs to MCPackage A, that RPackageOrganizer doesn't say that X belongs to RPackage B instead, and the reverse. There is a fault in the RPackage introduction there, which is that both RPackageOrganizer and Monticello are tracking system announcements, and giving them different meanings (and RPackage propagate its changes to Monticello). I am at around 10 Pharo images I had to scrap because the damage done by those bugs was beyond repair.
When you say force people to have one class category, one RPackage, that I do not understand why. As stated above, you have everything to handle multiple class categories in a RPackage. Why add a RPackageSet layer above ? Why make the transition break that ?
"Force" is a strong word. We don't force anyone... RPackage is a construction with a purpose, not a general malleable tool. It is not a tool to create your package with your desired format. Is a way to represent the fact that system is composed from classes, who are grouped in units called categories. Categories are there for the human eye, not for the system... now, the common convention around those categories is that you see them in class declaration, as class categories, and in browser "packages" panel. Monticello packages, in other term, are conceptually collections of class categories packaged together. So... for me is important to maintain that notion. Now, there are two point of views: 1) you have a new completely different infrastructure (aka RPackage+tags) to represent system, and then adapt (I can say "force" too) all the tools to this (which is a lot of work). For me it looks like a hack (we have something and we force the tools to show other thing, just because), and also no real necessity to do it, or 2) we took our new packaging system and make it work in the most simplest way possible, focusing on maintain the system as close to the eyes as possible. RPackageSet represents a notion for Monticello packages grouping packages (and btw, it can disappear in the future, because RPackageSet responsibility belongs most probably to regular MCPackages), and RPackage instances who matches to what users expect most probably about the organization categories in their system.
Our error was trying to take approach 1 first... not take path approach 2 now... and it was an error because after one month of working on that direction, the system was more and more unstable and chaotic and complex, and not what it should happens, which was the opposite.
(RPackage is not, in my opinion, naming agnostic. The main bugs I found in RPackage are because someone believe it is, where it isn't)
you're right, it is not.
One thing I would suggest is : remove Monticello from system announcements. Make RPackageOrganizer in charge of updating the MCWorkingCopy as needed (have a coherent view of the system).
That just don't work. If we remove monticello from SA, monticello doesn't know what changed and needs to reconstruct every time its state... which also means that monticello gui cannot be updated either.
Esteban
Thierry
________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : vendredi 7 septembre 2012 21:37 à : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RPackage, Monticello and the removal of PackageInfo
On Sep 7, 2012, at 8:44 PM, GOUBIER Thierry wrote:
Ok,
It's good to know, because, for me, as I was / I am trying to track the changes in RPackage for the past two weeks, it seemed that RPackage was happily oscillating between 1 and 2, and, to add to the fun, backporting it's instability by creating spurious packages in Monticello on the way.
Oh well, I almost managed to stabilize on 1), now I'll have to recode for 2). Should have stuck to PackageInfo :-(.
you are not the only one. Benjamin too. Now we are fighting with it and this is just not for fun.
Is there a plan to have clear semantics of the different matches planned (extension categories and sub categories, class category, package sub-category) ?
Yes Ideally we want one MCPackage - one RPackage + tags
Nothing more (no class category, no package info). Now we should be able to remove class categories. But this does not work easily because everybody would have to rewrite configurationOf for their projects (since each categories would be turned into a package). So may be when versionner will be working we can add a behavior to migrate automatically configuration.
So esteban will see if his idea is working which leads to a first class category and we can in a second period go more towards one MCPackage - one RPackage with tagged classes.
Monticello has already set a few conventions (not case sensitive, for example) (and they are not respected by quite a few packages) and not a few of the RPackage bugs are linked to it not respecting it (i.e. some methods of package matching in RPackage are case sensitive, whereas they are not in MCWorkingCopy) ?
You forgot to add "crap in PackageOrganizer." So yes it would be good to clean all that. RPackage is totally agostic to naming conventions but we have to create them and support backward compatibility.
:). RPackage and Monticello are already too coupled :) I believe some of the problems are in the way Monticello is working (as far as I can gather from tracing RPackage(1) bugs). In my opinion, there are two problems : 1 - Choosing between RPackage(1) and RPackage(2). RPackage(2) adds one level of organisation, if I understand correctly (RPackageSet contains RPackages which contains tags, no ?). Both are very similar, I'd judge RPackage(2) a bit better (one more level; I'd like to have more levels in truth). The thing is, if the problem with RPackage(1) is a hard one, then I don't see how RPackage(2) will solve it. 2 - Maintaining the same decisions as Monticello in RPackage(1) or RPackage(2) when it comes to classifying code. This is for me the hard one. Monticello has carefully, over apparently quite some time and many versions and implementations, fine tuned a way of matching unstructured, semi formal meta-data (Smalltalk categories and protocols) to "packages" (even with apparently overlapping packages ?). Reproducing that very same behavior in another structure-adding tool is a challenging task I would have considered as hard, up to very hard. There is also a body of adding additional hierarchy levels in MCPackages by carefully naming packages with well chosen prefixes and - (System-whatever for example), which points out to the fact packages developpers need at least one more level of hierarchy. (Remember that I wrote code extracting a hierarchical view of the full system out of both PackageInfo/Monticello and RPackage and it worked in both cases, even if RPackage was my favorite instead of trying to reproduce Monticello decisions) Now, there is the fact RPackage touches the core of the code management system, and that it intends to replace the for ever old classification system, and then... I'll keep a critic role, I'm not good enough :-) But I wish RPackage to succeed :) If you want to see how one could view the RPackage(1) world, try one of the latest AltBrowser versions. It looks and feel great, even if still buggy. That's why I would really be disappointed if it goes through the same pain a second time. Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Esteban Lorenzano [estebanlm@gmail.com] Date d'envoi : vendredi 7 septembre 2012 23:18 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : RE : RPackage, Monticello and the removal of PackageInfo On Sep 7, 2012, at 11:04 PM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
I will be a bit harder to convince then. 1 MCPackage = N RPackage doesn't strike me as any better than 1 MCPackage = 1 RPackage with tags, apart from performance issues. Remember that I was using option 1 in depth and hitting bugs, but not that much.
My opinion is that you don't really know what went wrong with option 1, except the implementation became unmanageable. So, I expect option 2 to be hardly better, sadly. And, as it promises breaking existing configurations, it will be a lot more fun !
Yeah, probably I'm just not smart enough... I'm sorry not being at the required level, I just do my best. But then, this was largely discussed in the team, with Marcus, Guille, Camillo and Mariano (and also with Stef, btw)... we discussed the problem and together we decided the path to follow.
By the way, if you enlarge the vision with RPackage, and think about the size of the overall system and how it has evolved a lot since the class categories of the beginning of Smalltalk, then your option 2 is, for me, already obsolete. You need more levels than the two you are promising with option 2. Scrolling throught thousands of categories is not fun; having packages which add hundreds of methods as an extension to a class is clearly not scalable and manageable. And scrolling through hundreds of package isn't either (or are you all working on 30" screens ? I'm not.).
That just don't work. If we remove monticello from SA, monticello doesn't know what changed and needs to >reconstruct every time its state... which also means that monticello gui cannot be updated either.
This is wrong, since RPackageOrganizer, being aware of the changes, could update monticello and maintain a coherent view. It would have made the situation a tiny bit better.
By coupling RPackageOrganizer with Monticello. Nice piece of design :) Esteban
Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Esteban Lorenzano [estebanlm@gmail.com] Date d'envoi : vendredi 7 septembre 2012 22:37 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : RPackage, Monticello and the removal of PackageInfo
Hi,
On Sep 7, 2012, at 10:08 PM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
It's hard to converse with that Exchange webmail. Oh, Ok, here it goes.
The one MCPackage _ One RPackage I'm Ok with, I made that working with my browser. But if this is the goal, then the current code is almost there and option 2) isn't needed ? A RPackage (the one with tags) clearly represent well what a MCPackage can be, bugs apart. (technically, it's a bit wider, since extension methods may belong to any protocol, not just the *PackageName : the AltBrowser consequently hides the extension name, which is interesting at the GUI level and works very well).
That's not the goal... that *was* the goal. The goal is to have a good representation of the system with RPackage. And no, we were not close, we were very far away to be close. Here is the thing 1 MCPackage = 1 RPackage breaks everything. Tags are just tags and don't have coherence with Class Categories. Now, 1 MCPackage = N RPackage has much more sense because stresses a lot less the system.
Now, what Stef is saying is that we wanted 1 to 1 correspondence, but a lot larger granularity... that means MCPackage matching current class categories. Not the opposite... but that means we need to ask everybody to adapt their monticello and configurations to match that vision, and that's something that it's not going to happen, not just because, for instance, Seaside has already tons of packages, do you imagine with the proposed granularity? Also, Versionner or other tools can help to reduce the fear to that granularity in the future, but that's not going to happen tomorrow.
So, I'm really sorry your work was almost ported and we changed the rules... and I'm sorry that while looking for the best solution for everybody we some times break somethings, but that's are the risks of developing over bleeding edge :(
The only thing needed is to make sure than when Monticello says X belongs to MCPackage A, that RPackageOrganizer doesn't say that X belongs to RPackage B instead, and the reverse. There is a fault in the RPackage introduction there, which is that both RPackageOrganizer and Monticello are tracking system announcements, and giving them different meanings (and RPackage propagate its changes to Monticello). I am at around 10 Pharo images I had to scrap because the damage done by those bugs was beyond repair.
When you say force people to have one class category, one RPackage, that I do not understand why. As stated above, you have everything to handle multiple class categories in a RPackage. Why add a RPackageSet layer above ? Why make the transition break that ?
"Force" is a strong word. We don't force anyone... RPackage is a construction with a purpose, not a general malleable tool. It is not a tool to create your package with your desired format. Is a way to represent the fact that system is composed from classes, who are grouped in units called categories. Categories are there for the human eye, not for the system... now, the common convention around those categories is that you see them in class declaration, as class categories, and in browser "packages" panel. Monticello packages, in other term, are conceptually collections of class categories packaged together. So... for me is important to maintain that notion. Now, there are two point of views: 1) you have a new completely different infrastructure (aka RPackage+tags) to represent system, and then adapt (I can say "force" too) all the tools to this (which is a lot of work). For me it looks like a hack (we have something and we force the tools to show other thing, just because), and also no real necessity to do it, or 2) we took our new packaging system and make it work in the most simplest way possible, focusing on maintain the system as close to the eyes as possible. RPackageSet represents a notion for Monticello packages grouping packages (and btw, it can disappear in the future, because RPackageSet responsibility belongs most probably to regular MCPackages), and RPackage instances who matches to what users expect most probably about the organization categories in their system.
Our error was trying to take approach 1 first... not take path approach 2 now... and it was an error because after one month of working on that direction, the system was more and more unstable and chaotic and complex, and not what it should happens, which was the opposite.
(RPackage is not, in my opinion, naming agnostic. The main bugs I found in RPackage are because someone believe it is, where it isn't)
you're right, it is not.
One thing I would suggest is : remove Monticello from system announcements. Make RPackageOrganizer in charge of updating the MCWorkingCopy as needed (have a coherent view of the system).
That just don't work. If we remove monticello from SA, monticello doesn't know what changed and needs to reconstruct every time its state... which also means that monticello gui cannot be updated either.
Esteban
Thierry
________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : vendredi 7 septembre 2012 21:37 à : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RPackage, Monticello and the removal of PackageInfo
On Sep 7, 2012, at 8:44 PM, GOUBIER Thierry wrote:
Ok,
It's good to know, because, for me, as I was / I am trying to track the changes in RPackage for the past two weeks, it seemed that RPackage was happily oscillating between 1 and 2, and, to add to the fun, backporting it's instability by creating spurious packages in Monticello on the way.
Oh well, I almost managed to stabilize on 1), now I'll have to recode for 2). Should have stuck to PackageInfo :-(.
you are not the only one. Benjamin too. Now we are fighting with it and this is just not for fun.
Is there a plan to have clear semantics of the different matches planned (extension categories and sub categories, class category, package sub-category) ?
Yes Ideally we want one MCPackage - one RPackage + tags
Nothing more (no class category, no package info). Now we should be able to remove class categories. But this does not work easily because everybody would have to rewrite configurationOf for their projects (since each categories would be turned into a package). So may be when versionner will be working we can add a behavior to migrate automatically configuration.
So esteban will see if his idea is working which leads to a first class category and we can in a second period go more towards one MCPackage - one RPackage with tagged classes.
Monticello has already set a few conventions (not case sensitive, for example) (and they are not respected by quite a few packages) and not a few of the RPackage bugs are linked to it not respecting it (i.e. some methods of package matching in RPackage are case sensitive, whereas they are not in MCWorkingCopy) ?
You forgot to add "crap in PackageOrganizer." So yes it would be good to clean all that. RPackage is totally agostic to naming conventions but we have to create them and support backward compatibility.
On Sep 8, 2012, at 12:41 AM, GOUBIER Thierry wrote:
:). RPackage and Monticello are already too coupled :)
No they are layered. Monticello RPackage and not the inverse.
I believe some of the problems are in the way Monticello is working (as far as I can gather from tracing RPackage(1) bugs).
In my opinion, there are two problems :
1 - Choosing between RPackage(1) and RPackage(2). RPackage(2) adds one level of organisation, if I understand correctly (RPackageSet contains RPackages which contains tags, no ?).
We would not need tags with this scenario. In scenario 2 RPackage are first class categories handling class extension.
Both are very similar, I'd judge RPackage(2) a bit better (one more level; I'd like to have more levels in truth). The thing is, if the problem with RPackage(1) is a hard one, then I don't see how RPackage(2) will solve it.
2 - Maintaining the same decisions as Monticello in RPackage(1) or RPackage(2) when it comes to classifying code. This is for me the hard one. Monticello has carefully, over apparently quite some time and many versions and implementations, fine tuned a way of matching unstructured, semi formal meta-data (Smalltalk categories and protocols) to "packages" (even with apparently overlapping packages ?). Reproducing that very same behavior in another structure-adding tool is a challenging task I would have considered as hard, up to very hard.
I do not think so. This is just that we decided to be backward compatible. Personnally I would have just throw away categories. We do not need them. But we are like poor people wanted to be rich, we do not have the money but we want more stuff.
There is also a body of adding additional hierarchy levels in MCPackages by carefully naming packages with well chosen prefixes and - (System-whatever for example), which points out to the fact packages developpers need at least one more level of hierarchy.
This is why in the first design we added tags.
(Remember that I wrote code extracting a hierarchical view of the full system out of both PackageInfo/Monticello and RPackage and it worked in both cases, even if RPackage was my favorite instead of trying to reproduce Monticello decisions)
Now, there is the fact RPackage touches the core of the code management system, and that it intends to replace the for ever old classification system, and then... I'll keep a critic role, I'm not good enough :-) But I wish RPackage to succeed :)
Thanks :)
If you want to see how one could view the RPackage(1) world, try one of the latest AltBrowser versions. It looks and feel great, even if still buggy. That's why I would really be disappointed if it goes through the same pain a second time.
I think that we should let esteban experiment and we will discuss again to see. Frankly I do not like the pattern-matching semantics and I understand that we do not want an explosion of packages so let us give a bit more time and see.
Thierry
________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Esteban Lorenzano [estebanlm@gmail.com] Date d'envoi : vendredi 7 septembre 2012 23:18 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : RE : RPackage, Monticello and the removal of PackageInfo
On Sep 7, 2012, at 11:04 PM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
I will be a bit harder to convince then. 1 MCPackage = N RPackage doesn't strike me as any better than 1 MCPackage = 1 RPackage with tags, apart from performance issues. Remember that I was using option 1 in depth and hitting bugs, but not that much.
My opinion is that you don't really know what went wrong with option 1, except the implementation became unmanageable. So, I expect option 2 to be hardly better, sadly. And, as it promises breaking existing configurations, it will be a lot more fun !
Yeah, probably I'm just not smart enough... I'm sorry not being at the required level, I just do my best. But then, this was largely discussed in the team, with Marcus, Guille, Camillo and Mariano (and also with Stef, btw)... we discussed the problem and together we decided the path to follow.
By the way, if you enlarge the vision with RPackage, and think about the size of the overall system and how it has evolved a lot since the class categories of the beginning of Smalltalk, then your option 2 is, for me, already obsolete. You need more levels than the two you are promising with option 2. Scrolling throught thousands of categories is not fun; having packages which add hundreds of methods as an extension to a class is clearly not scalable and manageable. And scrolling through hundreds of package isn't either (or are you all working on 30" screens ? I'm not.).
That just don't work. If we remove monticello from SA, monticello doesn't know what changed and needs to >reconstruct every time its state... which also means that monticello gui cannot be updated either.
This is wrong, since RPackageOrganizer, being aware of the changes, could update monticello and maintain a coherent view. It would have made the situation a tiny bit better.
By coupling RPackageOrganizer with Monticello. Nice piece of design :)
Esteban
Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Esteban Lorenzano [estebanlm@gmail.com] Date d'envoi : vendredi 7 septembre 2012 22:37 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : RPackage, Monticello and the removal of PackageInfo
Hi,
On Sep 7, 2012, at 10:08 PM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
It's hard to converse with that Exchange webmail. Oh, Ok, here it goes.
The one MCPackage _ One RPackage I'm Ok with, I made that working with my browser. But if this is the goal, then the current code is almost there and option 2) isn't needed ? A RPackage (the one with tags) clearly represent well what a MCPackage can be, bugs apart. (technically, it's a bit wider, since extension methods may belong to any protocol, not just the *PackageName : the AltBrowser consequently hides the extension name, which is interesting at the GUI level and works very well).
That's not the goal... that *was* the goal. The goal is to have a good representation of the system with RPackage. And no, we were not close, we were very far away to be close. Here is the thing 1 MCPackage = 1 RPackage breaks everything. Tags are just tags and don't have coherence with Class Categories. Now, 1 MCPackage = N RPackage has much more sense because stresses a lot less the system.
Now, what Stef is saying is that we wanted 1 to 1 correspondence, but a lot larger granularity... that means MCPackage matching current class categories. Not the opposite... but that means we need to ask everybody to adapt their monticello and configurations to match that vision, and that's something that it's not going to happen, not just because, for instance, Seaside has already tons of packages, do you imagine with the proposed granularity? Also, Versionner or other tools can help to reduce the fear to that granularity in the future, but that's not going to happen tomorrow.
So, I'm really sorry your work was almost ported and we changed the rules... and I'm sorry that while looking for the best solution for everybody we some times break somethings, but that's are the risks of developing over bleeding edge :(
The only thing needed is to make sure than when Monticello says X belongs to MCPackage A, that RPackageOrganizer doesn't say that X belongs to RPackage B instead, and the reverse. There is a fault in the RPackage introduction there, which is that both RPackageOrganizer and Monticello are tracking system announcements, and giving them different meanings (and RPackage propagate its changes to Monticello). I am at around 10 Pharo images I had to scrap because the damage done by those bugs was beyond repair.
When you say force people to have one class category, one RPackage, that I do not understand why. As stated above, you have everything to handle multiple class categories in a RPackage. Why add a RPackageSet layer above ? Why make the transition break that ?
"Force" is a strong word. We don't force anyone... RPackage is a construction with a purpose, not a general malleable tool. It is not a tool to create your package with your desired format. Is a way to represent the fact that system is composed from classes, who are grouped in units called categories. Categories are there for the human eye, not for the system... now, the common convention around those categories is that you see them in class declaration, as class categories, and in browser "packages" panel. Monticello packages, in other term, are conceptually collections of class categories packaged together. So... for me is important to maintain that notion. Now, there are two point of views: 1) you have a new completely different infrastructure (aka RPackage+tags) to represent system, and then adapt (I can say "force" too) all the tools to this (which is a lot of work). For me it looks like a hack (we have something and we force the tools to show other thing, just because), and also no real necessity to do it, or 2) we took our new packaging system and make it work in the most simplest way possible, focusing on maintain the system as close to the eyes as possible. RPackageSet represents a notion for Monticello packages grouping packages (and btw, it can disappear in the future, because RPackageSet responsibility belongs most probably to regular MCPackages), and RPackage instances who matches to what users expect most probably about the organization categories in their system.
Our error was trying to take approach 1 first... not take path approach 2 now... and it was an error because after one month of working on that direction, the system was more and more unstable and chaotic and complex, and not what it should happens, which was the opposite.
(RPackage is not, in my opinion, naming agnostic. The main bugs I found in RPackage are because someone believe it is, where it isn't)
you're right, it is not.
One thing I would suggest is : remove Monticello from system announcements. Make RPackageOrganizer in charge of updating the MCWorkingCopy as needed (have a coherent view of the system).
That just don't work. If we remove monticello from SA, monticello doesn't know what changed and needs to reconstruct every time its state... which also means that monticello gui cannot be updated either.
Esteban
Thierry
________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : vendredi 7 septembre 2012 21:37 à : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RPackage, Monticello and the removal of PackageInfo
On Sep 7, 2012, at 8:44 PM, GOUBIER Thierry wrote:
Ok,
It's good to know, because, for me, as I was / I am trying to track the changes in RPackage for the past two weeks, it seemed that RPackage was happily oscillating between 1 and 2, and, to add to the fun, backporting it's instability by creating spurious packages in Monticello on the way.
Oh well, I almost managed to stabilize on 1), now I'll have to recode for 2). Should have stuck to PackageInfo :-(.
you are not the only one. Benjamin too. Now we are fighting with it and this is just not for fun.
Is there a plan to have clear semantics of the different matches planned (extension categories and sub categories, class category, package sub-category) ?
Yes Ideally we want one MCPackage - one RPackage + tags
Nothing more (no class category, no package info). Now we should be able to remove class categories. But this does not work easily because everybody would have to rewrite configurationOf for their projects (since each categories would be turned into a package). So may be when versionner will be working we can add a behavior to migrate automatically configuration.
So esteban will see if his idea is working which leads to a first class category and we can in a second period go more towards one MCPackage - one RPackage with tagged classes.
Monticello has already set a few conventions (not case sensitive, for example) (and they are not respected by quite a few packages) and not a few of the RPackage bugs are linked to it not respecting it (i.e. some methods of package matching in RPackage are case sensitive, whereas they are not in MCWorkingCopy) ?
You forgot to add "crap in PackageOrganizer." So yes it would be good to clean all that. RPackage is totally agostic to naming conventions but we have to create them and support backward compatibility.
________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : samedi 8 septembre 2012 08:53 à : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : RE : RE : RPackage, Monticello and the removal of PackageInfo
No they are layered.
Monticello RPackage
and not the inverse.
They should be, you mean. In practice, they are not layered like that.
We would not need tags with this scenario. In scenario 2 RPackage are first class categories handling class extension.
Ok. I would like more to call them RGroup, then :-)
I do not think so. This is just that we decided to be backward compatible. Personnally I would have just throw away categories. We do not need them. But we are like poor people wanted to be rich, we do not have the money but we want more stuff.
:-) I want that too.
There is also a body of adding additional hierarchy levels in MCPackages by carefully naming packages with well chosen prefixes and - (System-whatever for example), which points out to the fact packages developpers need at least one more level of hierarchy.
This is why in the first design we added tags.
But tags would have worked inside todays MCPackage, not when multiple MCPackages are grouped together via a common prefix. And even then, it's too much. To make the base system understandable, I added two additional levels on top of the MCPackage.
I think that we should let esteban experiment and we will discuss again to see. Frankly I do not like the pattern-matching semantics and I understand that we do not want an explosion of packages so let us give a bit more time and see.
But could it be possible then to make the current one as stable as possible, to see if it can be made viable (and help correct bugs in both?). Moving a RPackage-based tool from RPackage+tags to RPackageSet + RPackage should not be too hard, once settled on a design choice (and trying to keep more or less the same API). Thierry
Thierry one of the problem we encountered is the following one with version 1 you have your package and tags MyPackage extensions methods... tagA classA classB tagB classC Now what do we do if the user change the category of the class. So we started to think that we should change class definition template so that we get category:'' -> package:'' tag: '' but this was implying to check in a lot of places. After we will see may be we will do it. The idea of esteban was to see if we can first get rid of PackageInfo, then in the future version of categories. Stef
Stéphane, I'll describe what I'll have done for AltBrowser processing the relevant announcement, according to what I know of the way MC maps packages and names : System announce class category change for classA, from catB to catC. In AltBrowser / class side - Find RPackage owning catB (matching Rpackage name + tag). - Find ClassA inside RPackage/catB representation - Remove my Alt object representing ClassA from class global structure. -- Announce to all AltBrowser instances to remove their Wrapper on Alt object for ClassA - Find RPackage owning catC - Find tag catC / create if needed - Create an Alt object representing ClassA inside RPackage (and catC if package has more than one tag). -- Announce to all AltBrowser instances to add the new object if appropriate This is the core of the code I have in the browser for each announcement, more or less. I was hoping RPackage would do the right thing, which is : As long as the system still has system categories, do any operation involving system categories according to the expected semantics (and MC is, for me, the judge of what those expected semantics may be). It would be nicer to be able to scrap directly the categories; for that, I would : build a new set of tools (RPackage-based system browser) disregarding categories. Disconnect that from MC except for an initial loading (not even querying MC for the related package, hey Nautilus!). Try to work in the system by removing everything that uses categories (return to basic, new, RPackage-based browsers). Have a reverse unload to MC (propagate all changes registered in RPackage back in MC when asked for it by the developper). Have only RPackageOrganizer or MC tracking changes, but not both. Reconnect both when all is stable. If you want, I can make an AltBrowser which would be a pure RPackage / tags only System Browser, no categories. Maybe RPackage is integrating too much too early in the system. Oh, as an aside since we're tracking unwanted instances, I wonder if there isn't a leak somewhere in dependencies / announcements (which would explain the more than one RPackageOrganizer instance bug cropping up). I'm leaking, and some instances of my browser don't garbage collect. Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : samedi 8 septembre 2012 08:58 à : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : RE : RPackage, Monticello and the removal of PackageInfo Thierry one of the problem we encountered is the following one with version 1 you have your package and tags MyPackage extensions methods... tagA classA classB tagB classC Now what do we do if the user change the category of the class. So we started to think that we should change class definition template so that we get category:'' -> package:'' tag: '' but this was implying to check in a lot of places. After we will see may be we will do it. The idea of esteban was to see if we can first get rid of PackageInfo, then in the future version of categories. Stef
As you explain it, I understand RPackage is nothing more than a cache maintained by virtue of SystemAnnoucements. That's a huge effort for a small revolution. I'm sure there are other goals behind, or were there postponed due to MC? aMCPackage is a set of RPackages whose name beginsWith: aMCPackage name A well known mess with MC is when aMCPackageA name beginsWith: aMCPackageB name, then aMCPackageA is included into aMCPackageB As long as, 1 RPackage = 1 category exactly, there is no such mess with RPackage, a class belongs to a single RPackage. Extension methods are less clear, and seem those in protocols that beginsWith: ('*' , aRPackage name) Possible mess this time aRPackageA name beginsWith: aRPackageB name the methods will belong to several RPackage? Now if I create protocols '*MyOwnCruft-core' then a new category ('MyOwnCruft'), I believe the organizer or the new RPackage must scan all existing protocols to catch extension methods... Does that happen? Nicolas 2012/9/7 Esteban Lorenzano <estebanlm@gmail.com>:
Hi,
On Sep 7, 2012, at 10:08 PM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
It's hard to converse with that Exchange webmail. Oh, Ok, here it goes.
The one MCPackage _ One RPackage I'm Ok with, I made that working with my browser. But if this is the goal, then the current code is almost there and option 2) isn't needed ? A RPackage (the one with tags) clearly represent well what a MCPackage can be, bugs apart. (technically, it's a bit wider, since extension methods may belong to any protocol, not just the *PackageName : the AltBrowser consequently hides the extension name, which is interesting at the GUI level and works very well).
That's not the goal... that *was* the goal. The goal is to have a good representation of the system with RPackage. And no, we were not close, we were very far away to be close. Here is the thing 1 MCPackage = 1 RPackage breaks everything. Tags are just tags and don't have coherence with Class Categories. Now, 1 MCPackage = N RPackage has much more sense because stresses a lot less the system.
Now, what Stef is saying is that we wanted 1 to 1 correspondence, but a lot larger granularity... that means MCPackage matching current class categories. Not the opposite... but that means we need to ask everybody to adapt their monticello and configurations to match that vision, and that's something that it's not going to happen, not just because, for instance, Seaside has already tons of packages, do you imagine with the proposed granularity? Also, Versionner or other tools can help to reduce the fear to that granularity in the future, but that's not going to happen tomorrow.
So, I'm really sorry your work was almost ported and we changed the rules... and I'm sorry that while looking for the best solution for everybody we some times break somethings, but that's are the risks of developing over bleeding edge :(
The only thing needed is to make sure than when Monticello says X belongs to MCPackage A, that RPackageOrganizer doesn't say that X belongs to RPackage B instead, and the reverse. There is a fault in the RPackage introduction there, which is that both RPackageOrganizer and Monticello are tracking system announcements, and giving them different meanings (and RPackage propagate its changes to Monticello). I am at around 10 Pharo images I had to scrap because the damage done by those bugs was beyond repair.
When you say force people to have one class category, one RPackage, that I do not understand why. As stated above, you have everything to handle multiple class categories in a RPackage. Why add a RPackageSet layer above ? Why make the transition break that ?
"Force" is a strong word. We don't force anyone... RPackage is a construction with a purpose, not a general malleable tool. It is not a tool to create your package with your desired format. Is a way to represent the fact that system is composed from classes, who are grouped in units called categories. Categories are there for the human eye, not for the system... now, the common convention around those categories is that you see them in class declaration, as class categories, and in browser "packages" panel. Monticello packages, in other term, are conceptually collections of class categories packaged together. So... for me is important to maintain that notion. Now, there are two point of views: 1) you have a new completely different infrastructure (aka RPackage+tags) to represent system, and then adapt (I can say "force" too) all the tools to this (which is a lot of work). For me it looks like a hack (we have something and we force the tools to show other thing, just because), and also no real necessity to do it, or 2) we took our new packaging system and make it work in the most simplest way possible, focusing on maintain the system as close to the eyes as possible. RPackageSet represents a notion for Monticello packages grouping packages (and btw, it can disappear in the future, because RPackageSet responsibility belongs most probably to regular MCPackages), and RPackage instances who matches to what users expect most probably about the organization categories in their system.
Our error was trying to take approach 1 first... not take path approach 2 now... and it was an error because after one month of working on that direction, the system was more and more unstable and chaotic and complex, and not what it should happens, which was the opposite.
(RPackage is not, in my opinion, naming agnostic. The main bugs I found in RPackage are because someone believe it is, where it isn't)
you're right, it is not.
One thing I would suggest is : remove Monticello from system announcements. Make RPackageOrganizer in charge of updating the MCWorkingCopy as needed (have a coherent view of the system).
That just don't work. If we remove monticello from SA, monticello doesn't know what changed and needs to reconstruct every time its state... which also means that monticello gui cannot be updated either.
Esteban
Thierry
________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : vendredi 7 septembre 2012 21:37 à : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RPackage, Monticello and the removal of PackageInfo
On Sep 7, 2012, at 8:44 PM, GOUBIER Thierry wrote:
Ok,
It's good to know, because, for me, as I was / I am trying to track the changes in RPackage for the past two weeks, it seemed that RPackage was happily oscillating between 1 and 2, and, to add to the fun, backporting it's instability by creating spurious packages in Monticello on the way.
Oh well, I almost managed to stabilize on 1), now I'll have to recode for 2). Should have stuck to PackageInfo :-(.
you are not the only one. Benjamin too. Now we are fighting with it and this is just not for fun.
Is there a plan to have clear semantics of the different matches planned (extension categories and sub categories, class category, package sub-category) ?
Yes Ideally we want one MCPackage - one RPackage + tags
Nothing more (no class category, no package info). Now we should be able to remove class categories. But this does not work easily because everybody would have to rewrite configurationOf for their projects (since each categories would be turned into a package). So may be when versionner will be working we can add a behavior to migrate automatically configuration.
So esteban will see if his idea is working which leads to a first class category and we can in a second period go more towards one MCPackage - one RPackage with tagged classes.
Monticello has already set a few conventions (not case sensitive, for example) (and they are not respected by quite a few packages) and not a few of the RPackage bugs are linked to it not respecting it (i.e. some methods of package matching in RPackage are case sensitive, whereas they are not in MCWorkingCopy) ?
You forgot to add "crap in PackageOrganizer." So yes it would be good to clean all that. RPackage is totally agostic to naming conventions but we have to create them and support backward compatibility.
(RPackage is not, in my opinion, naming agnostic. The main bugs I found in RPackage are because someone believe it is, where it isn't)
you're right, it is not.
No we can build a complete new system with RPackage without matching categories to RPackage and it will work. Now the import when loading a package match the categories to package just for the sake of backward compatibility. Stef
On Sep 7, 2012, at 10:08 PM, GOUBIER Thierry wrote:
It's hard to converse with that Exchange webmail. Oh, Ok, here it goes.
The one MCPackage _ One RPackage I'm Ok with, I made that working with my browser. But if this is the goal, then the current code is almost there and option 2) isn't needed ? A RPackage (the one with tags) clearly represent well what a MCPackage can be, bugs apart. (technically, it's a bit wider, since extension methods may belong to any protocol, not just the *PackageName : the AltBrowser consequently hides the extension name, which is interesting at the GUI level and works very well).
The problem is that even if we would have fixed nautilus to reflect Package - tags benjamin started to do that we are not sure that all the tools using categories will not produce bugs. So we decided to see how to stage the effort.
The only thing needed is to make sure than when Monticello says X belongs to MCPackage A, that RPackageOrganizer doesn't say that X belongs to RPackage B instead, and the reverse. There is a fault in the RPackage introduction there, which is that both RPackageOrganizer and Monticello are tracking system announcements, and giving them different meanings (and RPackage propagate its changes to Monticello). I am at around 10 Pharo images I had to scrap because the damage done by those bugs was beyond repair.
When you say force people to have one class category, one RPackage, that I do not understand why. As stated above, you have everything to handle multiple class categories in a RPackage. Why add a RPackageSet layer above ? Why make the transition break that ?
(RPackage is not, in my opinion, naming agnostic. The main bugs I found in RPackage are because someone believe it is, where it isn't)
One thing I would suggest is : remove Monticello from system announcements. Make RPackageOrganizer in charge of updating the MCWorkingCopy as needed (have a coherent view of the system).
Thierry
________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : vendredi 7 septembre 2012 21:37 à : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RPackage, Monticello and the removal of PackageInfo
On Sep 7, 2012, at 8:44 PM, GOUBIER Thierry wrote:
Ok,
It's good to know, because, for me, as I was / I am trying to track the changes in RPackage for the past two weeks, it seemed that RPackage was happily oscillating between 1 and 2, and, to add to the fun, backporting it's instability by creating spurious packages in Monticello on the way.
Oh well, I almost managed to stabilize on 1), now I'll have to recode for 2). Should have stuck to PackageInfo :-(.
you are not the only one. Benjamin too. Now we are fighting with it and this is just not for fun.
Is there a plan to have clear semantics of the different matches planned (extension categories and sub categories, class category, package sub-category) ?
Yes Ideally we want one MCPackage - one RPackage + tags
Nothing more (no class category, no package info). Now we should be able to remove class categories. But this does not work easily because everybody would have to rewrite configurationOf for their projects (since each categories would be turned into a package). So may be when versionner will be working we can add a behavior to migrate automatically configuration.
So esteban will see if his idea is working which leads to a first class category and we can in a second period go more towards one MCPackage - one RPackage with tagged classes.
Monticello has already set a few conventions (not case sensitive, for example) (and they are not respected by quite a few packages) and not a few of the RPackage bugs are linked to it not respecting it (i.e. some methods of package matching in RPackage are case sensitive, whereas they are not in MCWorkingCopy) ?
You forgot to add "crap in PackageOrganizer." So yes it would be good to clean all that. RPackage is totally agostic to naming conventions but we have to create them and support backward compatibility.
participants (5)
-
Esteban Lorenzano -
GOUBIER Thierry -
Mariano Martinez Peck -
Nicolas Cellier -
Stéphane Ducasse