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

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

by Eliot Miranda

On Sun, Sep 26, 2010 at 2:36 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > > > > > > 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? > > > > Hi eliot > > our vision is that we would like to have > - all the code of all the squeak and pharo version in a queryable > service available from the web. > for that we want a source code metamodel a la ginsu or famix > Use this metamodel to aggregate several meta models: pseudo > class/rb > make sure that when possible this model as a compative API with the > one of classes and friends => tools reuse > Veronica is working on that. > Hernan will probably join. > May be Colin should join. We could have a nice momentum. > > - for the changes we would like to have something else than a chunk > format > because invoking the parser to know if we are manipulating a class > definition is bad (with token at: 2 do that > and token at: 3 do that). > xml works for VisualWorks; it's the obvious choice. The great thing is that if you look at the VisualWorks schema you can learn from their mistakes. IIRC the schema for methods is broken because the selector is not a property (? I don't know xml terminology) of a method, e.g. in VW you see <method>this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method> but this would be much mire useful: <method selector="this:is:a:selector:">this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method> > > Again it will take time but we should have a good (why not 'exquise') > infrastructure so that we extend and build new tool > easily. > Its not a lot of work. ALso VW has a simple scheme for supporting both old chunk format and "new" xml format. BTW, now we have Igor's method trailers we can start playing with more than two source files, e.g. /not/ appending a Monticello package's source to the changes file, but merely adding it to a special directory, e.g. sources. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 26, 2010

[Pharo-project] Squeak/Pharo Talk

by DeNigris Sean

The presentation was great! There were about 10 Squeak/Pharo-ers there, from hobbyists to a surprise XEROX-PARC celebrity :) We had a dialogue, nudged along by a slideshow, which I posted at http://seandenigris.com/blog/?p=541 Sean

Sept. 26, 2010

Re: [Pharo-project] "A Mentoring Course on Smalltalk" Code License

by Serge Stinckwich

This is better to explicit put a MIT licence. If there is no licence, normally you can't do anything with the code. Le 26 sept. 2010 Ã 17:45, DeNigris Sean <sean(a)clipperadams.com> a Ã©crit : > I emailed Andres, the author, and he said "the code didn't have a license because I meant to put no restrictions on it... The MIT license is fine with me. In fact, I released the Hash Analysis Tool and Assessments under the MIT license already." > > Then he asked a great question: "Let me know what you need and I'll put it in. Or do you need that the book explicitly states the code mentioned therein is MIT?" > > I've been contacting many people to declare code as MIT. What "proof" is considered acceptable? I've been announcing it on the mailing list, so anyone could search back, contact me, and I could send them the email I received from the author, but that requires remembering the post, finding it, etc. What's the best way to go about this? License gurus? > > Sean > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2010

Re: [Pharo-project] [Vm-dev] VM Maker: VMMaker-oscog.33.mcz

by Mariano Martinez Peck

On Sun, Sep 26, 2010 at 1:45 PM, stephane ducasse < stephane.ducasse(a)gmail.com> wrote: > > Eliot > > I wanted to understand what: ' Have various places check for > isOopCOmpiledMethod: > rather than isCompiledMethod: to allow SmallIntegers to be used as > methods.' > means > in which circumstances do we want to have smalltalkIntegers used as > methods? > when we put an object instead of a compiled method and that by > accident this is an integer? > > Eliot, first of all, thanks A LOT!!! This is really important for us....wiiii we have TestCoverage again :) BTW, I think I found something related to what Stef says....In normal squeakVM : testAddNumbers self assert: (self add: 3 with: 4) = 7. self assert: (self perform: #add:with: withArguments: #(3 4)) = 7. this is ok, since (self perform: #add:with: withArguments: #(3 4)) answers 7. But with this new CogVM, there is a primitiveError. so...we can update the test to: self should: (self perform: #add:with: withArguments: #(3 4)) rise: Error. or something like that....but this test will fail with normal VM.. what we should do? thanks mariano > Stef > > > > > > > > Name: VMMaker-oscog.33 > > Author: eem > > Time: 25 September 2010, 7:13:51 am > > UUID: 733b7c50-b973-4ca0-9831-5c84d09032bf > > Ancestors: VMMaker-oscog.32 > > > > OSCogVM: > > Support object-as-method: > > Eagerly evaluate the interpreter version of a primitive > > to ease the object-as-method implementation and to > > improve interpreter performance. > > Refuse to enter anything that isn't a CompiledMethod > > into the method-lookup cache to avoid open PICs having > > to check for valid compiled methods. > > Have various places check for isOopCOmpiledMethod: > > rather than isCompiledMethod: to allow SmallIntegers to > > be used as methods. > > Interpreter: > > Have various places check for isOopCOmpiledMethod: > > rather than isCompiledMethod: to allow SmallIntegers to > > be used as methods. > > Slang: > > support super sends by expanding them at translation > > time. This allows CoInterpreter>>addMethodToCache > > to avoid cacheing non-compiled methods via a super > > send, avoiding duplicating SrackInterpreter's method. > > > >

Sept. 26, 2010

Re: [Pharo-project] systemNavigation cleaning

by Mariano Martinez Peck

On Sun, Sep 26, 2010 at 11:48 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> 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 <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 > > > > _______________________________________________ > > 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. 26, 2010

Re: [Pharo-project] which Shout repository should we use?

by Lukas Renggli

I thought I pushed my changes all to the official repos, no? Lukas 2010/9/26 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Lukas if we will use "your" Shout repository for the Dev images....I think > it would be nice (and not difficult to do) to have them in its own > repository and not in "unsorted". > > Thanks > > mariano > > On Tue, Aug 17, 2010 at 10:03 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> > Yes, that's good enough. My question was more general than this >> > particular situation. I wanted to discuss which repository Pharo official >> > images should use. >> >> why can't we use a configurationOfXX based on a pharoShout folder >> With Gofer we can script the pull from repositories. >> >> > >> > Cheers, >> > Doru >> > >> > >> > >> > On 16 Aug 2010, at 18:25, Lukas Renggli wrote: >> > >> > 2010/8/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> > >> > >> > On Sun, Aug 15, 2010 at 6:21 PM, StÃ©phane Ducasse >> > <stephane.ducasse(a)inria.fr> wrote: >> > >> > this is a good question. >> > for now I would just update the configuration to point for the repo of >> > lukas :) >> > >> > But now for example, I need to remove the style instVar in >> > PluggableShoutMorph because in Pharo 1.2 it has already such instVar. >> > But I don't know if I can commit or if Lukas would integrate such change >> > in >> > his repo beacuse that will break Shout to load in Pharo 1.1 (the image >> > he >> > uses) >> > >> > I will fix it as soon as the PharoCore 1.2 release candidate is out >> > and I am able to use the image. >> > >> > so... lukas what do you think we should do? >> > >> > So either fix it in Pharo or create your own 'temporary' version of >> > Shout in the repository where you keep all the versions for building >> > the images. >> > >> > 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 >> > >> > -- >> > www.tudorgirba.com >> > >> > "We cannot reach the flow of things unless we let go." >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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 > > > _______________________________________________ > 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. 26, 2010

Re: [Pharo-project] which Shout repository should we use?

by Mariano Martinez Peck

Lukas if we will use "your" Shout repository for the Dev images....I think it would be nice (and not difficult to do) to have them in its own repository and not in "unsorted". Thanks mariano On Tue, Aug 17, 2010 at 10:03 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > Yes, that's good enough. My question was more general than this > particular situation. I wanted to discuss which repository Pharo official > images should use. > > why can't we use a configurationOfXX based on a pharoShout folder > With Gofer we can script the pull from repositories. > > > > > Cheers, > > Doru > > > > > > > > On 16 Aug 2010, at 18:25, Lukas Renggli wrote: > > > > 2010/8/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > On Sun, Aug 15, 2010 at 6:21 PM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > > > > this is a good question. > > for now I would just update the configuration to point for the repo of > > lukas :) > > > > But now for example, I need to remove the style instVar in > > PluggableShoutMorph because in Pharo 1.2 it has already such instVar. > > But I don't know if I can commit or if Lukas would integrate such change > in > > his repo beacuse that will break Shout to load in Pharo 1.1 (the image he > > uses) > > > > I will fix it as soon as the PharoCore 1.2 release candidate is out > > and I am able to use the image. > > > > so... lukas what do you think we should do? > > > > So either fix it in Pharo or create your own 'temporary' version of > > Shout in the repository where you keep all the versions for building > > the images. > > > > 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 > > > > -- > > www.tudorgirba.com > > > > "We cannot reach the flow of things unless we let go." > > > > > > > > > > > > _______________________________________________ > > 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. 26, 2010

[Pharo-project] "A Mentoring Course on Smalltalk" Code License

by DeNigris Sean

I emailed Andres, the author, and he said "the code didn't have a license because I meant to put no restrictions on it... The MIT license is fine with me. In fact, I released the Hash Analysis Tool and Assessments under the MIT license already." Then he asked a great question: "Let me know what you need and I'll put it in. Or do you need that the book explicitly states the code mentioned therein is MIT?" I've been contacting many people to declare code as MIT. What "proof" is considered acceptable? I've been announcing it on the mailing list, so anyone could search back, contact me, and I could send them the email I received from the author, but that requires remembering the post, finding it, etc. What's the best way to go about this? License gurus? Sean

Sept. 26, 2010

Re: [Pharo-project] #copy and friends

by StÃ©phane Ducasse

+ 1 http://code.google.com/p/pharo/issues/detail?id=3004 Stef On Sep 26, 2010, at 2:21 AM, Levente Uzonyi wrote: > On Sat, 25 Sep 2010, Schwab,Wilhelm K wrote: > >> copy >> "Answer another instance just like the receiver. Subclasses typically override postCopy; they typically do not override shallowCopy. Copy is a template method in the sense of Design Patterns. So do not override it. Override shallowCopy instead. Pay attention that normally you should call postCopy of your superclass too." > > It should be: Override postCopy instead. > > > Levente > >> >> ^self shallowCopy postCopy >> >> >> >> shallowCopy >> "Answer a copy of the receiver which shares the receiver's instance variables. It should never be overridden. I'm invoked from the copy template method. Subclasses that need to specialize the copy should specialize the postCopy hook method." >> >> >> The references to #postCopy are probably valid, but the comments above can't both be correct. Right?? >> >> Bill >> >> >> _______________________________________________ >> 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. 26, 2010

Re: [Pharo-project] systemNavigation cleaning

by StÃ©phane Ducasse

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 <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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2010