About projects with Metacello
Locked
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About projects with Metacello
|
|
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 <[hidden email]>: > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About projects with Metacello
|
|
> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About projects with Metacello
|
|
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About projects with Metacello
|
|
In reply to this post by George Herolyants-3
On Sun, Dec 20, 2009 at 9:23 AM, George Herolyants <[hidden email]> wrote: Hi yes. This will reduce duplication of dependencies between projects. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About projects with Metacello
|
|
In reply to this post by Lukas Renggli
On Sun, Dec 20, 2009 at 9:32 AM, Lukas Renggli <[hidden email]> wrote:
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
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About projects with Metacello
|
|
>> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
I think that something like it could be arrange ... instead of #requires:, there's be #rejects:
Dale ----- "Stéphane Ducasse" <[hidden email]> 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 | > [hidden email] | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
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 < [hidden email] > 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: was "Re: About projects with Metacello"
|
|
On Sun, Dec 20, 2009 at 8:32 PM, <[hidden email]> wrote: I cannot find in the archives clues for that, so I'll ask here. Of course we can and I really would like that also...but..who do it ? -- _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Em 20/12/2009 17:50, Mariano Martinez Peck <[hidden email]> escreveu:
> On Sun, Dec 20, 2009 at 8:32 PM, <[hidden email]> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About projects with Metacello
|
|
In reply to this post by Stéphane Ducasse
On Sun, Dec 20, 2009 at 10:55 AM, Stéphane Ducasse
<[hidden email]> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: was "Re: About projects with Metacello"
|
|
In reply to this post by csrabak
On Sun, Dec 20, 2009 at 8:32 PM, <[hidden email]> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: was "Re: About projects with Metacello"
|
|
On Dec 21, 2009, at 3:12 PM, Damien Cassou wrote: > On Sun, Dec 20, 2009 at 8:32 PM, <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |