Lessons learnt from been an integrator

stéphane ducasse ducasse at iam.unibe.ch
Wed Aug 25 19:23:03 UTC 2004


Hi nady

I agree but the code of the browser is crappy, buggy, fragile.
And we **all** need a browser that can change, evolve to meet our needs.
There are a lot of things that are really slwo to do with this browser 
and 25 years
of good services may be enough.

Stef

On Aug 25, 2004, at 11:00 AM, Andrew Tween wrote:

> Hi,
> Replacing the default Browser with OmniBrowser *might* make things 
> easier.
> However; the default browser would still need to be available, and if 
> it is
> available then Shout should still work with it.
> So, whether the default browser remains part of the image, or is split 
> out
> into a package, the problem of integrating with it remains the same.
> Then there is mvc - I don't know if OmniBrowser works under mvc (or 
> could be
> made to work)??
>
> Although I have come up with one solution, for Shout, using 
> AppRegistry,  it
> may not be the best solution.
> We should take some time to consider the options before making changes 
> to
> the kernel.
> Perhaps an event model would be more flexible, for instance?
>     Browser triggers #needsCodeMorph , #needsCodeView, #builtMVCView,
> #builtMorphicView , etc. events.
>     And anything can handle those events and change the Browser's 
> behaviour.
>
> I am not familiar with Services, I'll take a look.
>
> The big danger in all this is that we introduce a framework that leads 
> to as
> many bugs as would be caused by simply allowing packages included in 
> the
> full image to override kernel methods.
> So; we need to make kernel changes; but we need to consider carefully 
> what
> those changes should be.
> If we are aiming to acheive this for 3.9, then there is no great rush.
> Cheers,
> Andy
>
> ----- Original Message -----
> From: "stéphane ducasse" <ducasse at iam.unibe.ch>
> To: "The general-purpose Squeak developers list"
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Wednesday, August 25, 2004 6:48 AM
> Subject: Re: Lessons learnt from been an integrator
>
>
> Hi andy
>
> We really think that we should really prepare 3.9 so that the system is
> made better to get new tool like yours.
>
> One possibility would also be to throw away the default browser and
> replace it by omnibrowser. If it is ready for that. Colin what do you
> think?
>
> So the first step is really to send the fix that can go in the kernel,
> thne identify what should be done at the kernel level, have you got a
> look at the services package because this would be really a good basis
> to support RB, shout integration.
> Stef
>
>
>
> On Aug 24, 2004, at 7:27 PM, Andrew Tween wrote:
>
>> With regard to the Full image / Shout / overridden methods ...
>>
>> I have done some work on splitting Shout into ...
>>     1. a changeset of base image changes.
>>         including an MvcTextEditor subclass of AppRegistry (similar to
>> MorphicTextEdtior, but for MVC)
>>
>>     2. a package that makes no changes to existing base image methods.
>>        (Although it does add new methods to base classes)
>>
>> I have achieved the above (see attached files).
>> However; I am not happy with they way the code is looking at the
>> moment.
>> There is a lot of duplication where I have had to create subclasses of
>> some
>> base classes, and some nasty hacks.
>>
>> So, it needs some further work; and a lot of testing - particularly in
>> mvc.
>> But I thought I'd  post what I have so far.
>>
>> Thanks to all who are working on the full image - which, in the
>> future, will
>> be even fuller ;>)
>> Cheers,
>> Andy
>>
>> ----- Original Message -----
>> From: "Marcus Denker" <denker at iam.unibe.ch>
>> To: "The general-purpose Squeak developers list"
>> <squeak-dev at lists.squeakfoundation.org>
>> Sent: Tuesday, August 24, 2004 3:51 PM
>> Subject: Re: Lessons learnt from been an integrator
>>
>>
>>
>> Am 24.08.2004 um 15:57 schrieb Hannes Hirzel:
>>
>>> Hello,
>>>
>>> stéphane ducasse wrote:
>>>> Hi all
>>>>
>>>> here are the lessons we learnt while building the 3.7 image. We
>>>> wanted
>>>> to have shout, rb, connector
>>>> morph in 3.7 but there were too much patches.
>>>
>>> What do you mean by this? Did the packages not load? Or did they
>>> overwrite
>>> important methods?
>> They overwrite many methods. It makes no sense at all to have a system
>> in beta for 4 Months and then change stuff a week before a release.
>>
>>> How did you find out?
>>>
>> By looking at the code?
>>
>>>
>>> Thank you Stef for this report.
>>>
>>> I learn that it is not possible to integrate Ned's connector morphs.
>>> What is the reason? Did you contact Ned? He is often amazing how fast
>>> he fixes things. I remember that he recently put out a new release.
>>> As SM is down currently I cannot check.
>>>
>> Ned posted *a lot* of fixed for morphic to the list. Many of those are
>> required
>> for Connectors, but not all of them got added to 3.7.
>>
>>> It would be very nice to have the connector morphs in 3.7 full. Or
>>> perhaps
>>> it is not a good idea to integrate something which
>>> has not been retested. I would be willing to retest 3.7 full with
>>> Ned's
>>> connector morphs included. However this will surely add a few days
>>> more.
>>>
>>
>> There is no way to add connectors to 3.7, as we can't add all the
>> patches.
>>
>> Maybe people should have put some effort into integrating all the 
>> stuff
>> into 3.7
>> when it was possible, but somehow nobody wanted to do that back then. 
>> I
>> wrote
>> lots of mails to the list that there is work to be done with regard to
>> harvesting, but
>> everyone seems to be thinking that it is not important.
>>
>>      Marcus
>>
>>
>>
>>
>>
>> ---
>> Outgoing mail is certified Virus Free.
>> Checked by AVG anti-virus system (http://www.grisoft.com).
>> Version: 6.0.716 / Virus Database: 472 - Release Date: 06/07/2004
>> <CodeEditorsUseAppRegistry.4.cs><Shout.3.15-tween.8.mcz>
>
>
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.716 / Virus Database: 472 - Release Date: 05/07/2004
>




More information about the Squeak-dev mailing list