[squeak-dev] Re: Polymorph/Trunk issues (was: Re: Incompatible code between pharo and Squeak)

>
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Andreas Raab" <[hidden email]>
> To: "The general-purpose Squeak developers list"
> <[hidden email]>; <[hidden email]>
> Sent: Wednesday, August 26, 2009 4:36 AM
> Subject: Polymorph/Trunk issues (was: Re: Incompatible code between pharo
> and Squeak)
>
>
>> Hi Giuseppe -
>>
>> [cc: Gary for input on some of the issues below]
>>
>> Giuseppe Luigi Punzi Ruiz wrote:
>>> I started from
>>> http://squeakvm.org/win32/release/Squeak-3.10.2-trunk.zip, Load Code
>>> Updates.
>>> Then, I add the MC repository of Polymorph, and Load latest package of
>>> Polymorph-Widgets, then latest from Polymorph-Squeak-Widgets
>>>
>>> Title bar looks ugly, and If you open Preferences, click on Windows to
>>> get a MNU (and others strange behaviour).
>>
>> Let's start with the easy stuff. The issue of the ugly title bars are
>> caused by an age-old issue of trying to create a bold version of a font
>> that's already bold (and failing to do so in a visually pleasing way).
>> You can work around this issue by changing the window title font to a
>> non-bold font (or convincing Gary not to bolden the title font in the
>> SoftSqueak theme ;-)
>>
>> The preferences blow up has been fixed in the trunk, it resulted from the
>> use of custom view registries in Polymorph (but was my fault for not
>> properly supporting those).
>>
>> However, even after fixing that I got some errors about
>> BlockClosure>>isValid and BlockClosure>>asMinimalRepresentation. Looking
>> around in the Polymorph repository I found these in
>> Polymorph-EventEnhancements (but on BlockContext not on BlockClosure)
>> with a number of other extension methods and classes none of which seem
>> to be used by Polymorph-Widgets.
>>
>> Question for Gary: Is it enough to implement these methods on
>> BlockClosure and expect things to work without having to load
>> Polymorph-EventEnhancements, or is some or all of EventEnhancements
>> needed for Polymorph? If it's just the two methods I think we should put
>> them into the trunk with comments and get over it.
>
> Just those, the rest of EventEnhancements is used by the Diff Tools
> though.
> There was some discussion a while back (and, possibly on Mantis) about
> them.
>
>> The other package I looked at was Polymorph-Squeak-Widgets. There are
>> only two methods here; one in BorderedMorph that looks like an obvious
>> fix and should be added to the trunk. The other one (#handleDisabledKey:)
>> is on ParagraphEditor and effectively a no-op since we are switching to
>> the Cuis editors. Something will need to be added to TextEditor for this
>> purpose.
>>
>> Question for Gary: Should these be folded into Squeak proper or do you
>> prefer to keep them in Polymorph? Either way is fine by me but you might
>> have a preference.
>>
>> Then there is the issue of overrides. Polymorph contains a lot of them
>> which is understandable considering what it is doing but it means that
>> the code will be very brittle with regards to any changes in Morphic.
>>
>> Question for Gary: Do you think it would make sense to try to integrate
>> these overrides so that we avoid these brittle dependencies or is this
>> just going to create a maintenance nightmare for you (i.e., having
>> versions with and without overrides)?
>>
>
> Will need to be done eventually... with a patch package for Squeak3.9.
>
>
>> Lastly, performance. The image felt slow after loading Polymorph which I
>> attributed at first to the pretty gradients but when I switched to the
>> "StandardSqueak" theme (which is indistinguishable from the trunk's
>> current look) it still felt slow. So I ran a version of the "standard"
>> browser benchmark:
>>
>> | saveMorphs time |
>> [saveMorphs := World submorphs.
>>  World removeAllMorphs."heh, heh"
>>  time := [1 to: 10 do: [:i |
>> MorphicToolBuilder new open:
>>           (Browser new setClass: SystemDictionary selector: nil).
>> World doOneCycleNow].
>> World submorphs do: [:m | m delete. World doOneCycleNow].
>>   ] timeToRun] ensure:[World addAllMorphs: saveMorphs].
>>
>> I found that in the current trunk image the benchmark completes in less
>> than half the time (!) that it takes to run it in the same image with
>> Polymorph loaded (10401 msecs vs. 23297 msecs). Something is slowing down
>> with Polymorph and very much so.
>>
>> Question for Gary: Is there any intrinsic reason why the Polymorph image
>> would be so much slower? Have you done any serious performance analysis
>> and any insights what might be slowing it down? The benchmark was run
>> with all animations turned off yaddaya to get as close as possible to the
>> default Squeak look. I actually think that the above benchmark is a
>> smoking gun that you can increase performance of Polymorph by 2x if you
>> can find out what is slowing you down.
>
> This is mostly down to having correct scrollbar ranges. I've done some
> optimisation that narrows the gap (1900 for Squeak, 2200 in Pharo). Will
> put out in next update.
>
>>
>> All said and done the situation is this: Once you update from the trunk
>> you need to implement two methods on BlockClosure, that is
>> BlockClosure>>isValid (returns true) and
>> BlockClosure>>asMinimalRepresentation (returns self). Once this is done,
>> load Polymorph-Widgets and Polymorph will work. There is the outstanding
>> issue of ParagraphEditor but it won't cause any immediate harm and I'd
>> like to hear back from Gary before deciding on how to fix these issues.
>>
>> Cheers,
>>   - Andreas
>>
>