systemNavigation cleaning
Locked
 
|
Hi all
I'm cleaning SystemNavigation (no comment). Now I really SystemNavigation to be able to navigate a given environment (instance of SystemDictionary). Therefore I introduced an analyzedEnvironment and I will funnel most methods to use it. Now some queries are doing memory scanning (allBehaviorDo:) so I would like to use the following semantics for the method names all* will refer to methods that are not respecting the analyzedEnvironment but could scan the complete memory and I would like to introduce their pendant to convey the fact that they only take as input a given environment. Example allClasses vs classes This would allow us to have in place a nice infrastructure to load and analyse code in a separate environment and do atomica loading. This was done like that in VW30. What do you think. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Sep 3, 2010, at 1:01 PM, Stéphane Ducasse wrote: > Hi all > > I'm cleaning SystemNavigation (no comment). > Now I really SystemNavigation to be able to navigate a given environment (instance of SystemDictionary). > Therefore I introduced an analyzedEnvironment and I will funnel most methods to use it. > > Now some queries are doing memory scanning (allBehaviorDo:) so > I would like to use the following semantics for the method names > all* will refer to methods that are not respecting the analyzedEnvironment but could scan the complete memory > and I would like to introduce their pendant to convey the fact that they only take as input a given environment. > > Example > allClasses > vs classes > > This would allow us to have in place a nice infrastructure to load and analyse code in a separate environment and > do atomica loading. This was done like that in VW30. > > What do you think. This is a very good change and was one of the issues faced with the namespace work. James > Stef > > _______________________________________________ > 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 Stéphane Ducasse
I agree that SystemNavigation is ugly, but *a lot* of existing code
depends on it. Why not just use BrowserEnvironment if you need something convenient and nice? And at some point integrate that into PharoCore? Lukas On 3 September 2010 22:01, Stéphane Ducasse <[hidden email]> wrote: > Hi all > > I'm cleaning SystemNavigation (no comment). > Now I really SystemNavigation to be able to navigate a given environment (instance of SystemDictionary). > Therefore I introduced an analyzedEnvironment and I will funnel most methods to use it. > > Now some queries are doing memory scanning (allBehaviorDo:) so > I would like to use the following semantics for the method names > all* will refer to methods that are not respecting the analyzedEnvironment but could scan the complete memory > and I would like to introduce their pendant to convey the fact that they only take as input a given environment. > > Example > allClasses > vs classes > > This would allow us to have in place a nice infrastructure to load and analyse code in a separate environment and > do atomica loading. This was done like that in VW30. > > What do you think. > > Stef > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: systemNavigation cleaning
|
|
On Sep 3, 2010, at 11:04 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? Also fixing the system is the best way to make sure that it is always running. Look at it nearly nobody looked at my rewrite of packages (ok three people, henrik, you and doru), nearly nobody looked at a the new update streamer (cyrille uses it but did not look at it), ... > Why not just use BrowserEnvironment if you need something convenient > and nice? And at some point integrate that into PharoCore? This is the idea. But I think that system navigation is a superset of Now since BrowserEnvironment is in RB this brings the problem of how do I integrate that. So cleaning first systemNavigation would be a way to have a better pictures of what is working duplicated.... or not. 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) Stef > > Lukas > > On 3 September 2010 22:01, Stéphane Ducasse <[hidden email]> wrote: >> Hi all >> >> I'm cleaning SystemNavigation (no comment). >> Now I really SystemNavigation to be able to navigate a given environment (instance of SystemDictionary). >> Therefore I introduced an analyzedEnvironment and I will funnel most methods to use it. >> >> Now some queries are doing memory scanning (allBehaviorDo:) so >> I would like to use the following semantics for the method names >> all* will refer to methods that are not respecting the analyzedEnvironment but could scan the complete memory >> and I would like to introduce their pendant to convey the fact that they only take as input a given environment. >> >> Example >> allClasses >> vs classes >> >> This would allow us to have in place a nice infrastructure to load and analyse code in a separate environment and >> do atomica loading. This was done like that in VW30. >> >> What do you think. >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > 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 |
|
|
>> 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 Refactoring-Core, but would work independently) Refactoring-Changes (this is currently part of Refactoring-Core, but would work independently) 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. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: systemNavigation cleaning
|
|
On Sat, Sep 4, 2010 at 1:08 PM, Lukas Renggli <[hidden email]> wrote:
If you finally do this Lukas, let me know so that I update ConfigurationOf ... Lukas _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: systemNavigation cleaning
|
|
In reply to this post by Lukas Renggli
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 > [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 |
About using RB changes in Gaucho and Pharo
|
|
When i started working on the new Gaucho, i tried to use/understand the current change model without success. So i chose to use the RB engine ( thanks lukas for nicely maintaining it!)
In the soon to be released Gaucho1.1 i'm using RB changes to record every change made to the system, changes that take part during a Gaucho development session. So i will be able to provide an insight to the feasability of using RB changes to record and persist sessions, and easily provide undo's . Maybe this work could be plugged into a new Pharo changes system! Fernando pd: BTW, i enhanced the RB changes with AddPackageRefactoring and others related to the UI, ( in this way i'm also recording every UI event ). After the ESUG i will try to integrate the relevant ones to RB. > >> 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. > _______________________________________________ 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'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. 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 <[hidden email]> 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 >> [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 > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
rb-dependencies.png (106K)
Re: About using RB changes in Gaucho and Pharo
|
|
In reply to this post by Fernando olivero-2
On Sep 5, 2010, at 9:45 AM, Fernando olivero wrote: > When i started working on the new Gaucho, i tried to use/understand the current change model without success. yes we can all forget. This part is ugly and brittle > So i chose to use the RB engine ( thanks lukas for nicely maintaining it!) > > In the soon to be released Gaucho1.1 i'm using RB changes to record every change made to the system, changes that take part during a Gaucho development session. > So i will be able to provide an insight to the feasability of using RB changes to record and persist sessions, and easily provide undo's . Maybe this work could be plugged into a new Pharo changes system! Yes we plan to use RBChange as a foundation infrastructure. I with veronica plan to also have a declarative code model so that we can do decent recentChanges and the rest. BTW there is a nice Undo framework of a couple of classes in sophie I added a first fileout to the bug entry. > > > Fernando > > pd: > BTW, i enhanced the RB changes with AddPackageRefactoring and others related to the UI, ( in this way i'm also recording every UI event ). After the ESUG i will try to integrate the relevant ones to RB. what are the UI event? because I would like to replacement SystemChangeNotifier events by announcements (check systemAnnouncement) as in ConfigurationOfRPackage. > > >> >>> 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. >> > > > _______________________________________________ > 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: systemNavigation cleaning
|
|
In reply to this post by Lukas Renggli
2010/9/5 Lukas Renggli <[hidden email]> I've split the refactoring model into various packages as outlined in 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Refactoring-Spelling depends on Refactoring-Critics.
Refactoring-Tests-Spelling depends on Refactoring-Tests-Critics. Lukas 2010/9/25 Mariano Martinez Peck <[hidden email]>: > > > 2010/9/5 Lukas Renggli <[hidden email]> >> >> 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 <[hidden email]> >> 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 >> >> [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 >> > >> >> >> >> -- >> Lukas Renggli >> 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 > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: systemNavigation cleaning
|
|
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 <[hidden email]> wrote: Refactoring-Spelling depends on Refactoring-Critics. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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). Lukas 2010/9/25 Mariano Martinez Peck <[hidden email]>: > 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 <[hidden email]> wrote: >> >> Refactoring-Spelling depends on Refactoring-Critics. >> Refactoring-Tests-Spelling depends on Refactoring-Tests-Critics. >> >> Lukas >> >> 2010/9/25 Mariano Martinez Peck <[hidden email]>: >> > >> > >> > 2010/9/5 Lukas Renggli <[hidden email]> >> >> >> >> 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 <[hidden email]> >> >> 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 >> >> >> [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 >> >> > >> >> >> >> >> >> >> >> -- >> >> Lukas Renggli >> >> 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 >> > >> >> >> >> -- >> Lukas Renggli >> 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 > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: systemNavigation cleaning
|
|
In reply to this post by Mariano Martinez Peck
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 <[hidden email]>: >> 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 <[hidden email]> wrote: >>> >>> Refactoring-Spelling depends on Refactoring-Critics. >>> Refactoring-Tests-Spelling depends on Refactoring-Tests-Critics. >>> >>> Lukas >>> >>> 2010/9/25 Mariano Martinez Peck <[hidden email]>: >>>> >>>> >>>> 2010/9/5 Lukas Renggli <[hidden email]> >>>>> >>>>> 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 <[hidden email]> >>>>> 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 >>>>>>> [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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Lukas Renggli >>>>> 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 >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> 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 >> > > > > -- > Lukas Renggli > 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: systemNavigation cleaning
|
|
On Sun, Sep 26, 2010 at 11:48 AM, Stéphane Ducasse <[hidden email]> wrote:
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!
_______________________________________________ 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 |