On Sep 25, 2010, at 10:45 PM, Lukas Renggli wrote: > I think people want all packages by default. > > This package separation is more to make it possible to replace some > parts of PharoCore with the more modern and powerful mechanisms from > the refactoring engline, e.g. SystemNavigation -> BrowserEnvironment, > (e.g. SystemNavigation -> BrowserEnvironemnt and ChangeRecord -> > RefactoryChange).
yes! > > Lukas > > 2010/9/25 Mariano Martinez Peck <[email protected]>: >> Thanks. And do you have an idea of better groups that the basic ones I have >> defined? (look at the end). >> I mean, imagine groups of packages that it is likely a user will load only >> them, and all together >> >> >> >> >> spec for: #pharo do: [ >> spec repository: 'http://www.squeaksource.com/rb'. >> spec >> package: 'AST-Core'; >> package: 'AST-Tests-Core' with: [ spec requires: 'AST-Core' ]; >> >> package: 'AST-Semantic' with: [ spec requires: 'AST-Core' ]; >> package: 'AST-Tests-Semantic' with: [ spec requires: >> 'AST-Semantic' ]; >> >> package: 'Refactoring-Environment' with: [ spec requires: >> 'AST-Core' ]; >> package: 'Refactoring-Tests-Environment' with: [ spec requires: >> 'Refactoring-Environment' ]; >> >> package: 'Refactoring-Changes' with: [ spec requires: >> 'Refactoring-Environment' ]; >> package: 'Refactoring-Tests-Changes' with: [ spec requires: >> 'Refactoring-Changes' ]; >> >> package: 'Refactoring-Core' with: [ spec requires: >> 'Refactoring-Changes' ]; >> package: 'Refactoring-Tests-Core' with: [ spec requires: >> 'Refactoring-Core' ]; >> >> package: 'Refactoring-Critics' with: [ spec requires: >> 'Refactoring-Changes' ]; >> package: 'Refactoring-Tests-Critics' with: [ spec requires: >> 'Refactoring-Critics' ]; >> >> package: 'Refactoring-Spelling' with: [ >> spec requires: 'Refactoring-Critics'. >> spec postLoadDoIt: #postLoadRBSpelling ]; >> package: 'Refactoring-Tests-Spelling' with: [ spec requires: >> 'Refactoring-Tests-Critics'. ]. >> >> spec >> group: 'default' with: #('Core' ); >> group: 'Core' with: #( 'AST-Core' 'AST-Semantic' >> 'Refactoring-Environment' 'Refactoring-Changes' 'Refactoring-Core' >> 'Refactoring-Critics' 'Refactoring-Spelling' ); >> group: 'Tests' with: #( 'AST-Tests-Core' 'AST-Tests-Semantic' >> 'Refactoring-Tests-Environment' 'Refactoring-Tests-Changes' >> 'Refactoring-Tests-Core' 'Refactoring-Tests-Critics' >> 'Refactoring-Tests-Spelling' ); >> group: 'Core Tests' with: #('Core' 'Tests' ); >> >> >> >> cheers >> >> mariano >> >> >> On Sat, Sep 25, 2010 at 10:18 PM, Lukas Renggli <[email protected]> wrote: >>> >>> Refactoring-Spelling depends on Refactoring-Critics. >>> Refactoring-Tests-Spelling depends on Refactoring-Tests-Critics. >>> >>> Lukas >>> >>> 2010/9/25 Mariano Martinez Peck <[email protected]>: >>>> >>>> >>>> 2010/9/5 Lukas Renggli <[email protected]> >>>>> >>>>> I've split the refactoring model into various packages as outlined in >>>>> the previous mail. >>>>> >>>>> The dependencies between the tests are slightly problematic, but will >>>>> eventually be fixed as depicted in red in the attached dependency >>>>> graph. It shouldn't matter for loading, so there is no hurry. >>>>> >>>> >>>> Lukas, and what happens with 'Refactoring-Spelling' ?? >>>> >>>> is this still valid? >>>> >>>> package: 'Refactoring-Spelling' with: [ >>>> spec requires: 'Refactoring-Core'. >>>> spec postLoadDoIt: #postLoadRBSpelling ]; >>>> package: 'Refactoring-Tests-Spelling' with: [ spec requires: >>>> 'Refactoring-Spelling'. ]. >>>> >>>> >>>> thanks >>>> >>>> mariano >>>> >>>> >>>>> >>>>> Thank you for updating the configuration Mariano. Note that >>>>> OB-Refactory depends on all the non-test packages. >>>>> >>>>> Lukas >>>>> >>>>> On 4 September 2010 14:01, Stéphane Ducasse <[email protected]> >>>>> wrote: >>>>>> >>>>>> On Sep 4, 2010, at 1:08 PM, Lukas Renggli wrote: >>>>>> >>>>>>>>> I agree that SystemNavigation is ugly, but *a lot* of existing >>>>>>>>> code >>>>>>>>> depends on it. >>>>>>>> >>>>>>>> Well if I start forking all the classes that we should fix because >>>>>>>> there are used it will be endless. >>>>>>>> I was thinking to start also to look at senders and use deprecate. >>>>>>>> >>>>>>>> do you have a lot of external tools that use it? >>>>>>> >>>>>>> Yes, all tools use it: >>>>>>> >>>>>>> Monticello, Paragraph Editor (new and old), OmniBrowser, >>>>>>> eCompletion, Refactoring Engine. >>>>>>> >>>>>>> Now I removed its use from the BrowserEnvironment in the refactoring >>>>>>> engine itself. There are still a couple of references though, where >>>>>>> people used the wrong abstraction layer when implementing stuff >>>>>>> (platform code instead of the abstraction of the refactoring >>>>>>> engine). >>>>>>> >>>>>>>> So what do you suggest? >>>>>>>> Separating BrowserEnvironment and its superclass from RB and >>>>>>>> starting >>>>>>>> to >>>>>>>> - check its api >>>>>>>> - improve it >>>>>>>> - migrate caller of systemNavigation -> BrowserEnvironment >>>>>>>> (rename browserEnvironment) >>>>>>> >>>>>>> Yeah, maybe one step would be to split the refactoring engine into >>>>>>> smaller and independent packages: >>>>>>> >>>>>>> AST-Core (that already is separate) >>>>>>> Refactoring-Environment (this is currently part of >>>>>> >>>>>> yes this would be good so that we can start do the idea with the >>>>>> integration related to systemDictionary been a potential leave of the >>>>>> composition >>>>>> tree we talked last time you visit us. >>>>>> >>>>>>> Refactoring-Core, but would work independently) >>>>>>> Refactoring-Changes (this is currently part of Refactoring-Core, >>>>>>> but would work independently) >>>>>> >>>>>> yes I'm curious to see if/how we could use changes to represent >>>>>> changeset. >>>>>> >>>>>> >>>>>>> Refactoring-Refactorings (this is currently part of >>>>>>> Refactoring-Core and depends on all of the above) >>>>>>> Refactoring-Lint (this is currently part of Refactoring-Core and >>>>>>> depends on all of the above) >>>>>>> >>>>>>> Like this Pharo could integrate Refactoring-Environment and >>>>>>> Refactoring-Changes independently. >>>>>> >>>>>> :) >>>>>> >>>>>>> I'll see if I can repackage the refactoring browser a bit, might >>>>>>> take >>>>>>> a while though because the tests are not that nicely separated. >>>>>> >>>>>> I imagine. >>>>>> Now incremental changes is the only way for us :) >>>>>>> >>>>>>> Lukas >>>>>>> >>>>>>> -- >>>>>>> Lukas Renggli >>>>>>> www.lukas-renggli.ch >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> [email protected] >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> [email protected] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Lukas Renggli >>>>> www.lukas-renggli.ch >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [email protected] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
