September 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] In Smalltalk you can't loose code... hum

by Eliot Miranda

On Sat, Sep 25, 2010 at 12:53 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > On Sep 25, 2010, at 9:25 PM, FranÃ§ois Tanguy wrote: > > > Hi, > > > > the statement is true when the code is saved in the browser. > > But in a workspace or in the script manager that is not true. > > > > Actually it is a feature request: You can't loose code even when you are > working in the script browser. > > check if you can find a way and I'm sure that the maintainer of > scriptmanager will integrate it. > I always prefer to define methods so I never use script or workspace to > write anything useful. > > > > > Because in the script manager has a save capability, would it be > difficult to write the changes into the changes files ? > > the problem is that the change files logic is old and it works 'well' for > what it should but extending it will break other part. > This is why slowly we will have to think to get something better. > Do you mean improving the change scanner parsing or throwing away and going for something different? > > > > > Francois > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 25, 2010

Re: [Pharo-project] do we need handleDisabledKey:

by Guillermo Polito

I had a look at CUIS, and it doesn't use it neither. On Fri, Sep 24, 2010 at 3:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > hi gary > > do we need handleDisabledKey: because this is not defined on the new > editorHierarchy? > > http://code.google.com/p/pharo/issues/detail?id=3003 > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 25, 2010

Re: [Pharo-project] systemNavigation cleaning

by Lukas Renggli

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 <marianopeck(a)gmail.com>: > 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 <renggli(a)gmail.com> wrote: >> >> Refactoring-Spelling depends on Refactoring-Critics. >> Refactoring-Tests-Spelling depends on Refactoring-Tests-Critics. >> >> Lukas >> >> 2010/9/25 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> > >> > >> > 2010/9/5 Lukas Renggli <renggli(a)gmail.com> >> >> >> >> 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 <stephane.ducasse(a)inria.fr> >> >> 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 >> >> >> Pharo-project(a)lists.gforge.inria.fr >> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > >> >> > >> >> > _______________________________________________ >> >> > Pharo-project mailing list >> >> > Pharo-project(a)lists.gforge.inria.fr >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > >> >> >> >> >> >> >> >> -- >> >> Lukas Renggli >> >> www.lukas-renggli.ch >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Sept. 25, 2010

Re: [Pharo-project] systemNavigation cleaning

by Mariano Martinez Peck

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 <renggli(a)gmail.com> wrote: > Refactoring-Spelling depends on Refactoring-Critics. > Refactoring-Tests-Spelling depends on Refactoring-Tests-Critics. > > Lukas > > 2010/9/25 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > 2010/9/5 Lukas Renggli <renggli(a)gmail.com> > >> > >> 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 <stephane.ducasse(a)inria.fr> > >> 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 > >> >> Pharo-project(a)lists.gforge.inria.fr > >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > >> > > >> > _______________________________________________ > >> > Pharo-project mailing list > >> > Pharo-project(a)lists.gforge.inria.fr > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > >> > >> > >> > >> -- > >> Lukas Renggli > >> www.lukas-renggli.ch > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 25, 2010

Re: [Pharo-project] systemNavigation cleaning

by Lukas Renggli

Refactoring-Spelling depends on Refactoring-Critics. Refactoring-Tests-Spelling depends on Refactoring-Tests-Critics. Lukas 2010/9/25 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > 2010/9/5 Lukas Renggli <renggli(a)gmail.com> >> >> 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 <stephane.ducasse(a)inria.fr> >> 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 >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Sept. 25, 2010

Re: [Pharo-project] systemNavigation cleaning

by Mariano Martinez Peck

2010/9/5 Lukas Renggli <renggli(a)gmail.com> > 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 <stephane.ducasse(a)inria.fr> > 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 > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 25, 2010

Re: [Pharo-project] After loading a package...all changes with "revision changed"

by StÃ©phane Ducasse

On Sep 25, 2010, at 9:13 PM, Mariano Martinez Peck wrote: > > > On Sat, Sep 25, 2010 at 9:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Sep 25, 2010, at 8:25 PM, Mariano Martinez Peck wrote: > > > Hi. I am having a probem with Glorp and I really have no idea what can be. The problem is that I load the package Glorp and just after loading, I do a "changes" in the MC Browser and I see a lot of classes with a lot of changes and all of them like "revison changed". This is annoying since it doesn't let me easily see what I have really changed. > > > > To reproduce: > > > > - Load the package "Glorp" from http://www.squeaksource.com/SqueakDBX > > - Open a MC Browser, select Glorp package and press the "Changes" button agains the ss repo. And you will see :) > > May be the image used to save the package got a problem and changed the timestamp of the methods. > So when you merge you get changed methods. > > I've just tried commiting and load them in a clean image...same problem. > > And if it were what you say...is there a solution? I do not know. I would like to know whether the change propagates. can you do the following: - load the package - modify one method - save it - reload it in another image and you get them all dirty? In which image? do you see changes related to methodReference or timestamp? I know that the SUnit code niall sent us does not contain all the source code and that the binary is different from the source code. we should investigate that. Stef > > thanks > > mariano > > > > > > Any help is really appreaciated. > > > > Thanks > > > > Mariano > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 25, 2010

Re: [Pharo-project] In Smalltalk you can't loose code... hum

by StÃ©phane Ducasse

On Sep 25, 2010, at 9:25 PM, FranÃ§ois Tanguy wrote: > Hi, > > the statement is true when the code is saved in the browser. > But in a workspace or in the script manager that is not true. > > Actually it is a feature request: You can't loose code even when you are working in the script browser. check if you can find a way and I'm sure that the maintainer of scriptmanager will integrate it. I always prefer to define methods so I never use script or workspace to write anything useful. > > Because in the script manager has a save capability, would it be difficult to write the changes into the changes files ? the problem is that the change files logic is old and it works 'well' for what it should but extending it will break other part. This is why slowly we will have to think to get something better. > > Francois > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 25, 2010

Re: [Pharo-project] In Smalltalk you can't loose code... hum

by George Herolyants

Hi, 2010/9/25 FranÃ§ois Tanguy <francois.tanguy(a)gmail.com>: > Hi, > > the statement is true when the code is saved in the browser. > But in a workspace or in the script manager that is not true. You can save a workspace into a file and it will be renewed each time you press Cmd+S.

Sept. 25, 2010

Re: [Pharo-project] NativeBoost callbacks: double return values?

by Igor Stasenko

2010/9/25 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Sat, Sep 25, 2010 at 12:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 25 September 2010 21:45, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >> wrote: >> > Sig, >> > >> > Something that I would very much like to go on not really >> > understanding<g> is that complexity of returning a double, and its further >> > impact on callbacks. Â Aside from the usual myriad uses, my biggest interest >> > in callbacks is for numerical analysis where double return values are very >> > common. Â Is that something that you can make work by near magic? Â I don't >> > really care if they require special handling, but it would be very nice if >> > they are at least not very difficult to set up. >> > >> In short: yes. >> >> In long: you can always create own numeric type (like MyDouble) in >> smalltalk with its own storage format/fields. >> And with NativeBoost you can implement C<->smalltalk coercions for >> instances of this class. >> >> NativeBoost type lookup logic allows you to control types and/or >> aliases on a per-class basis. >> So, you can still use 'double' in function specification, and then >> make it to use MyDouble instances, instead of default Float. >> >> Btw, in Squeak Float using same storage size (64 bits) as C double, >> except that it stores them in big-endian format. >> In Cog VM, they are stored in little-endian, since cog runs on >> little-endian machines. > > Um, no. Â In Cog they are stored in the format of the host machine. Â The Cog > Stack interpreter is not x86-specific. Â If you compile it on SPARC or > big-endian PowerPC you'll find that floats are stored big-endian there-on. > cheers > Eliot > Thanks for clarification. In NB, apparently i have to be aware if it runs on Cog or Squeak, since in squeak Floats are always big-endian, and as you said, on Cog they using a host platform endian format. >> >> > Bill >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 25, 2010