>
> Lukas
>
> 2010/9/25 Mariano Martinez Peck <
marianopeck@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@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@gmail.com>:
>>>>
>>>>
>>>> 2010/9/5 Lukas Renggli <
renggli@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@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@lists.gforge.inria.fr
>>>>>>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pharo-project mailing list
>>>>>>
Pharo-project@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@lists.gforge.inria.fr
>>>>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>>
Pharo-project@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@lists.gforge.inria.fr
>>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>>
Pharo-project@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@lists.gforge.inria.fr
>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project