Regards, Gary
----- Original Message ----- From: "Gary Chambers" gazzaguru2@btinternet.com To: "Andreas Raab" andreas.raab@gmx.de Sent: Wednesday, August 26, 2009 2:51 PM Subject: Re: Polymorph/Trunk issues (was: Re: Incompatible code between pharo and Squeak)
Regards, Gary
----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org; gazzaguru2@btinternet.com 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
squeak-dev@lists.squeakfoundation.org