[Pharo-project] About projects with Metacello
Hi folks. Now that I am starting to write some configurations, I realized that we have a "change of concept" with Metacello. With Gofer or Installer (someone tell me if I am wrong) we are use to manage projects that are a certain repository of squeaksource or similar. And then we have the packages. So, for example we are talking about the RefactoringBrowser, you have: www.squeaksource.com/rb and the packages AST-Core, Refactoring-Core and Refactoring-Spelling. Then there is the project OB where you have also OB-Refactory and OB-Regex for example. At first, of course, I thought to have one ConfigurationOf per project. I mean, map one to one. But now...I was wondering that I can have a ConfigurationOfRefactoring for example, that can deals with ALL the things related to RB. In this case AST-Core, Refactoring-Core and Refactoring-Spelling from rb repo and OB-Refactory and OB-Regex from OB repo....and see all of them like a project. What do you think ? Do you have any thoughts with this? pors and cons? I would like to listen opinions. Cheers, Mariano
Hi I think it would be better to have ConfigurationOfRefactoring and two other: ConfigurationOfOB and ConfigurationOfO2, which have the former as a required project (and IIUC it was your first intention, right?). This will reduce duplication of dependencies between projects. 2009/12/19 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi folks. Now that I am starting to write some configurations, I realized that we have a "change of concept" with Metacello. With Gofer or Installer (someone tell me if I am wrong) we are use to manage projects that are a certain repository of squeaksource or similar. And then we have the packages. So, for example we are talking about the RefactoringBrowser, you have:
www.squeaksource.com/rb
and the packages AST-Core, Refactoring-Core and Refactoring-Spelling.
Then there is the project OB where you have also OB-Refactory and OB-Regex for example.
At first, of course, I thought to have one ConfigurationOf per project. I mean, map one to one. But now...I was wondering that I can have a ConfigurationOfRefactoring for example, that can deals with ALL the things related to RB. In this case AST-Core, Refactoring-Core and Refactoring-Spelling from rb repo and OB-Refactory and OB-Regex from OB repo....and see all of them like a project.
What do you think ? Do you have any thoughts with this? pors and cons? I would like to listen opinions.
Cheers,
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I think it would be better to have ConfigurationOfRefactoring and two other: ConfigurationOfOB and ConfigurationOfO2, which have the former as a required project (and IIUC it was your first intention, right?). This will reduce duplication of dependencies between projects.
O2 breaks OB, if both are loaded. I suggest that the configurations should trigger a conflict when somebody tries to load both. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
good idea! Dale? Do we have xor for configuration ;) ? On Dec 20, 2009, at 9:32 AM, Lukas Renggli wrote:
I think it would be better to have ConfigurationOfRefactoring and two other: ConfigurationOfOB and ConfigurationOfO2, which have the former as a required project (and IIUC it was your first intention, right?). This will reduce duplication of dependencies between projects.
O2 breaks OB, if both are loaded. I suggest that the configurations should trigger a conflict when somebody tries to load both.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I think that something like it could be arrange ... instead of #requires:, there's be #rejects: Dale ----- "Stéphane Ducasse" <stephane.ducasse@inria.fr> wrote: | good idea! | Dale? Do we have xor for configuration ;) ? | | On Dec 20, 2009, at 9:32 AM, Lukas Renggli wrote: | | >> I think it would be better to have ConfigurationOfRefactoring and | two | >> other: ConfigurationOfOB and ConfigurationOfO2, which have the | former | >> as a required project (and IIUC it was your first intention, | right?). | >> This will reduce duplication of dependencies between projects. | > | > O2 breaks OB, if both are loaded. I suggest that the configurations | > should trigger a conflict when somebody tries to load both. | > | > Lukas | > | > -- | > Lukas Renggli | > http://www.lukas-renggli.ch | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project@lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, Dec 20, 2009 at 10:55 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Dale? Do we have xor for configuration ;) ?
Even if it was the case, you asked me to install both. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
On Sun, Dec 20, 2009 at 9:32 AM, Lukas Renggli <renggli@gmail.com> wrote:
I think it would be better to have ConfigurationOfRefactoring and two other: ConfigurationOfOB and ConfigurationOfO2, which have the former as a required project (and IIUC it was your first intention, right?). This will reduce duplication of dependencies between projects.
O2 breaks OB, if both are loaded. I suggest that the configurations should trigger a conflict when somebody tries to load both.
Lukas. Could you give me more details please? Look. This is the part of the latest script we used to generate the dev image: Gofer new wiresong: 'ob'; addPackage: 'OmniBrowser'; addPackage: 'OB-Morphic'; addPackage: 'OB-Standard'; addPackage: 'OB-Refactory'; addPackage: 'OB-Regex'; addPackage: 'OB-SUnitIntegration'; addPackage: 'OB-Shout'; load. Gofer new squeaksource: 'EnhancedOB'; addPackage: 'OmniBrowser2'; addPackage: 'O2-Standard'; addPackage: 'O2-Morphic'; addPackage: 'O2-Enhancements'; addPackage: 'OCForO2'; addPackage: 'O2-Refactory'; load. And there we are loading things from OB and O2. And the image don't seems to be "broken". Thanks. Mariano
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
O2 breaks OB, if both are loaded. I suggest that the configurations should trigger a conflict when somebody tries to load both.
Lukas. Could you give me more details please? Look. This is the part of the latest script we used to generate the dev image:
It it not broken in the sense that there are many debuggers flying around, but OB is broken in the sense that ... - O2 still overrides methods of OB. If anybody commits something from an image where both are loaded these methods suddenly are missing (isClassOrganization was a recent example that caused a lot of confusion). - O2 still changes the menus in OB, and then people complain that the menus are messed up in OB. - O2 changes the refactoring engines, so that even when OB is selected sometimes O2 browser unexpectedly show up. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
I cannot find in the archives clues for that, so I'll ask here. Is there a reason we keep both O2 and OB in parallel? Can't we just get the best parts of one of the solutions and consider the other as the "trunk" or mainstream for Pharo? -- Cesar Rabak Em 20/12/2009 06:32, Lukas Renggli < renggli@gmail.com > escreveu:
I think it would be better to have ConfigurationOfRefactoring and two other: ConfigurationOfOB and ConfigurationOfO2, which have the former as a required project (and IIUC it was your first intention, right?). This will reduce duplication of dependencies between projects.
O2 breaks OB, if both are loaded. I suggest that the configurations should trigger a conflict when somebody tries to load both. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, Dec 20, 2009 at 8:32 PM, <csrabak@bol.com.br> wrote:
I cannot find in the archives clues for that, so I'll ask here.
Is there a reason we keep both O2 and OB in parallel? Can't we just get the best parts of one of the solutions and consider the other as the "trunk" or mainstream for Pharo?
Of course we can and I really would like that also...but..who do it ?
-- Cesar Rabak
Em 20/12/2009 06:32, Lukas Renggli < renggli@gmail.com > escreveu:
I think it would be better to have ConfigurationOfRefactoring and two other: ConfigurationOfOB and ConfigurationOfO2, which have the former as a required project (and IIUC it was your first intention, right?). This will reduce duplication of dependencies between projects.
O2 breaks OB, if both are loaded. I suggest that the configurations should trigger a conflict when somebody tries to load both.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Em 20/12/2009 17:50, Mariano Martinez Peck <marianopeck@gmail.com> escreveu:
On Sun, Dec 20, 2009 at 8:32 PM, <csrabak@bol.com.br> wrote:
I cannot find in the archives clues for that, so I'll ask here.
Is there a reason we keep both O2 and OB in parallel? Can't we just get the best parts of one of the solutions and consider the other as the "trunk" or mainstream for Pharo?
Of course we can and I really would like that also...but..who do it?
OK, Mariano! Before we engage in "who'll do it" we have to have a clear vision on the _what_ to do it! If the project participant's all agree with this, we can open an issue specific to table what should be kept from the incumbent browser[s] to the one considered to be the next thing®. I surmase correctly O2 is the one to be fully developed and we should scavenge the interesting ideas from the other available implementations (IIUC including Whisker). Then we can see if the desired features fit in the present architecture (still thinking of O2) or if we should start from a lower ground implementing all the new ideas using Glamor (for example). Once the all effort is more or less understood, we can look for ways of getting resources for it (including the funding for people working in it, or chopping the tasks in chunks small enough that via Sprints and programming parties we arrive at our objective). I think Pharo would be a nice "example" for the Smalltalk community if we can get this kind of 'disperse engineering' to work! my 0.019999.... -- Cesar Rabak
On Sun, Dec 20, 2009 at 8:32 PM, <csrabak@bol.com.br> wrote:
Is there a reason we keep both O2 and OB in parallel? Â Can't we just get the best parts of one of the solutions and consider the other as the "trunk" or mainstream for Pharo?
Pharo must have the notion of Packages. This is a prerequisite of a good package browser. Unless we have that, O2 will be slow and won't be the default. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
On Dec 21, 2009, at 3:12 PM, Damien Cassou wrote:
On Sun, Dec 20, 2009 at 8:32 PM, <csrabak@bol.com.br> wrote:
Is there a reason we keep both O2 and OB in parallel? Can't we just get the best parts of one of the solutions and consider the other as the "trunk" or mainstream for Pharo?
Pharo must have the notion of Packages.
I'm working on it have a look at RPackage in PharoTaskForces I took into account the feedback I got from lukas and now the tests are green again so I should be able to continue and start to work on the integration inside the system but if someone wants to help or read the code....
This is a prerequisite of a good package browser. Unless we have that, O2 will be slow and won't be the default.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, Dec 20, 2009 at 9:23 AM, George Herolyants < george.herolyants@gmail.com> wrote:
Hi
I think it would be better to have ConfigurationOfRefactoring and two other: ConfigurationOfOB and ConfigurationOfO2, which have the former as a required project (and IIUC it was your first intention, right?).
yes.
This will reduce duplication of dependencies between projects.
2009/12/19 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi folks. Now that I am starting to write some configurations, I realized that we have a "change of concept" with Metacello. With Gofer or Installer (someone tell me if I am wrong) we are use to manage projects that are a certain repository of squeaksource or similar. And then we have the packages. So, for example we are talking about the RefactoringBrowser, you have:
www.squeaksource.com/rb
and the packages AST-Core, Refactoring-Core and Refactoring-Spelling.
Then there is the project OB where you have also OB-Refactory and OB-Regex for example.
At first, of course, I thought to have one ConfigurationOf per project. I mean, map one to one. But now...I was wondering that I can have a ConfigurationOfRefactoring for example, that can deals with ALL the things related to RB. In this case AST-Core, Refactoring-Core and Refactoring-Spelling from rb repo and OB-Refactory and OB-Regex from OB repo....and see all of them like a project.
What do you think ? Do you have any thoughts with this? pors and cons? I would like to listen opinions.
Cheers,
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (7)
-
csrabak＠bol.com.br -
Dale Henrichs -
Damien Cassou -
George Herolyants -
Lukas Renggli -
Mariano Martinez Peck -
Stéphane Ducasse