On Sun, Sep 26, 2010 at 11:48 AM, Stéphane Ducasse < [email protected]> wrote:
> > 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! > > Ok, excellent. I let those naive groups for the moment. Once those packages are integrated in PharoCore (maybe 1.2 or 1.3) I can just add conditional loading to the conf and wala! > > > > 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 >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
