3.9Full

> With Squeak 3.9 now in beta, it would be good if the
> Meta-team (the board or team that creates new teams)
> started a 3.9Full team to determine what can go into
> the full version of squeak.
>
> It would be good to have someplace to get  decisions
> and guidance for candidates for inclusion.
>
> Also it gives a way of testing squeak under a heavy
> load.
>
> Yours in service, -- Jerome Peace
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>

>
> On May 13, 2006, at 11:36 PM, Ralph Johnson wrote:
>
>>>                 for dev I would like to have
>>>                         - RB engine + services integrated in OB  
>>> if possible
>>
>> Is anybody working on this?  I am unhappy with the current status of
>> the RB in Squeak, and want to fix the UI.  If OB is going to be the
>> standard, I'd like to see them integrated.
>
> I'm working on OB in general, and adding refactoring support is  
> certainly on my todo list. At the moment, I'm actually doing  
> refactoring - migrating the event propagation code to use  
> Announcements. I could bump it up the priority list if you want to  
> lend a hand.
>
> Colin
>

> So it would be good to build on top of what he did. This way we  
> could get the refactorings
> everywhere and not only in OB ;)
>
>
>
> On 14 mai 06, at 06:17, Colin Putney wrote:
>
>>
>> On May 13, 2006, at 11:36 PM, Ralph Johnson wrote:
>>
>>>>                 for dev I would like to have
>>>>                         - RB engine + services integrated in OB  
>>>> if possible
>>>
>>> Is anybody working on this?  I am unhappy with the current status of
>>> the RB in Squeak, and want to fix the UI.  If OB is going to be the
>>> standard, I'd like to see them integrated.
>>
>> I'm working on OB in general, and adding refactoring support is  
>> certainly on my todo list. At the moment, I'm actually doing  
>> refactoring - migrating the event propagation code to use  
>> Announcements. I could bump it up the priority list if you want to  
>> lend a hand.
>>
>> Colin
>>
>
>

>
> On May 14, 2006, at 4:11 AM, stéphane ducasse wrote:
>
>> Romain described all the refactorings with services, and he did an  
>> integration of RB in
>> OB. Romain?
>> I could not find your image anymore: the  http://www.inf.unisi.ch/ 
>> ~robbes/ does not seem to work.
>>
>> So it would be good to build on top of what he did. This way we  
>> could get the refactorings
>> everywhere and not only in OB ;)
>
> I tried that back when services were first released. There were a  
> couple of issues:
>
> - Services is tightly coupled to the keybindings and menu-bar work  
> that Romain did. Those things might be useful as well, but I want  
> to be able to get refactoring support in OB without changing my UI.
>
> - Services also relies on fetching and parsing the source code of  
> methods that call into it. This doesn't cause any immediate  
> problems, but it seems fragile, and I don't want to make OB depend  
> on that code.
>

>>> Romain described all the refactorings with services, and he did  
>>> an integration of RB in
>>> OB. Romain?
>>> I could not find your image anymore: the  http://www.inf.unisi.ch/ 
>>> ~robbes/ does not seem to work.
>>>
>>> So it would be good to build on top of what he did. This way we  
>>> could get the refactorings
>>> everywhere and not only in OB ;)
>>
>> I tried that back when services were first released. There were a  
>> couple of issues:
>>
>> - Services is tightly coupled to the keybindings and menu-bar work  
>> that Romain did. Those things might be useful as well, but I want  
>> to be able to get refactoring support in OB without changing my UI.
>>
>> - Services also relies on fetching and parsing the source code of  
>> methods that call into it. This doesn't cause any immediate  
>> problems, but it seems fragile, and I don't want to make OB depend  
>> on that code.
>>
>
> well, these problems are solved now. The source code fiddling was  
> not clean and is not needed anymore, and the menu-bar has been  
> taken out. The services used to depend on the Keymapping package,  
> but it does not anymore. A very lightweight shortcut manager is  
> included with it.
>
> To answers Stef's questions from another mail:
>
>> Romain could you clearly state
>> - what you did
>
> The framework is done and loaded in 7006 image.
> Tools built on top or adapted to services includes:
> - refactorings & related tools (lint, code finder)
> - a history mechanism supporting back and forward navigation in  
> browsers and in message lists
> - a way to store modified but not accepted yet code to ease navigation
> - a navigation mechanism allowing to select any code element and  
> navigate from it (as if every piece of code was a hyperlink). Now  
> it is triggered by a keyboard shortcut, and not double-click anymore
> - navigation from/to unit tests, and running tests (formerly known  
> as browseunit)
> - a "teleporting device"
>
>> - what is left
>
> - checking again in the latest image
> - the basic support is working in OB, which means that refactorings  
> and tools work. I haven't gotten around to implement a way to  
> programmatically change the method browsed by an OmniBrowser, so  
> the navigation support is limited
> - some of the navigation possibilities are not really mature yet,  
> but they could be left out of the base image
>
>
>> - so that people can see and possibly participate
>
> - I'll send a newer version soon so that people can try it out.  I  
> have troubles uploading back the image on my site, so I'm afraid  
> you will have to wait a bit ..
>
>
> Romain
>
>
>> That said, services does seem like a very good approach. It  
>> decouples the provider of the service from the mechanism for  
>> making it available to the user. It also fits in very nicely with  
>> OB's architecture. OB's actions could be generalized into  
>> services, and made available to other tools.
>>
>> Colin
>
> --
> Romain Robbes          http://www.inf.unisi.ch/~robbes/
>
>
>
>