Hi,
I just bought myself Mark Guzdials Blue Book and am thus using Squeak 2.8, I've usually been using 3.8.
Morphic in 2.8 gives me the impression to be a lot faster than in the 3.8 version, am I imagining this or can that actually be so?
Günther
Günther Schmidt wrote:
Hi,
I just bought myself Mark Guzdials Blue Book and am thus using Squeak 2.8, I've usually been using 3.8.
Morphic in 2.8 gives me the impression to be a lot faster than in the 3.8 version, am I imagining this or can that actually be so?
Günther
Depending on what kind of machine and how your UI is set up, the difference is about 6x on the out of the box configuration. Its not really a fair comparison though because of the newer eye candy. Changing to the ST80 theme in 3.8 brings it down to about 3X. The improvements in 3.9a should get the difference to about 2.5X in the ST80 theme and 4.5X in the out of the box theme. All this is using the 10 browser test on a p4-2.8ghz.
Other interesting notes, the VM has improved about 10% since 2.8, and LazyLists make PluggableLists considerably better (when working correctly anyway). The slowdowns include eye candy and internationalization, but I don't completely understand where all the time is going.
Eddie
On 25 août 05, at 04:18, Eddie Cottongim wrote:
Günther Schmidt wrote:
Hi,
I just bought myself Mark Guzdials Blue Book and am thus using Squeak 2.8, I've usually been using 3.8.
Morphic in 2.8 gives me the impression to be a lot faster than in the 3.8 version, am I imagining this or can that actually be so?
Günther
Depending on what kind of machine and how your UI is set up, the difference is about 6x on the out of the box configuration. Its not really a fair comparison though because of the newer eye candy. Changing to the ST80 theme in 3.8 brings it down to about 3X. The improvements in 3.9a should get the difference to about 2.5X in the ST80 theme and 4.5X in the out of the box theme. All this is using the 10 browser test on a p4-2.8ghz.
Eddie. we (with marcus) will really pay attention that all your efforts (thanks a lot) will not get lost. Believe us. 3.9 will rock. Keep going your cool work.
Other interesting notes, the VM has improved about 10% since 2.8, and LazyLists make PluggableLists considerably better (when working correctly anyway). The slowdowns include eye candy and internationalization, but I don't completely understand where all the time is going.
Eddie
Thanks all,
that's interesting news. I wasn't aware that there is indeed a problem with Morphics performance.
Stef, did I understand correctly that you presume this to be fixed in 3.9? Is there a web site on this subject, or at the moment this list only?
Günther
Hi Gunther
I presume nothing. I just want to make clear that marcus and I are paying attention that all the good fixes that improves the situation will really be considered and pushed if necessary in 3.9.
Our goal is to produce a much better environment so that everybody can create new wealth (multimedia, authoring, web dev...assets).
We are concerned that the overall quality of squeak should improve so that we can invent the future. So this is why we will introduce the new compiler, method annotation (but optimized), traits, networks, socket fixes, services, refactoring everywhere....... all the refactoring fixes,
Now if someone want to help there are plenty of room to help: - write tests - speed up Omnibrowser - clean and remove junk - clean up menus - if someone wants the menu bar of diego, he should extract it and fix the performance penalties.
at the end I can tell you that we want 3.9 to be an "enabler release".
On 25 août 05, at 12:48, Günther Schmidt wrote:
Thanks all,
that's interesting news. I wasn't aware that there is indeed a problem with Morphics performance.
Stef, did I understand correctly that you presume this to be fixed in 3.9? Is there a web site on this subject, or at the moment this list only?
Günther
On 25-Aug-05, at 11:48 AM, Günther Schmidt wrote:
Thanks all,
that's interesting news. I wasn't aware that there is indeed a problem with Morphics performance.
There are some very simplistic and non-scaling algorithms involved in Morphic displaying and updating. To observe this you need only open a couple of windows and then add a third; it will typically open fairly quickly. Now add another dozen. Watch how long the last one takes.
You can also experiment with turning off the deferred displaying to see just how much gets rendered when a top window is moved or closed. I strongly suspect that some careful consideration of the algorithms used might result in dramatic improvements.
Referring back to the comment that the VM is about 10% faster since 2.8 - it depends a lot on what you consider a suitable benchmark. For a general picture I wouldn't take any notice of anything less than the full Benchmark package. The trivial bytecode loop + recursive send tests are not much more meaningful than a slashdot poll. On my machine the latest VMs are nearly three >times< as fast as the 2.8 ones. I have no doubt that on some machines the difference might be minimal - it all depends on compilers and options used, OS version etc etc etc.
tim
Tim,
so, if the *right* people are working on it, Morphic can be made to go wooooosh?
I've been thinking of switching from Dolphin to Squeak for a couple of reasons, Morphic in particular, because I just can't see how you could do the things you can do in Morphic as easily in Dolphin.
There have been posts on this topic for some time now, so I guess it's something that resists fixing?
Well in short, I'm asking whether it's reasonable to presume that this issue will be resolved any time soon or rather not to depend on that?
Günther
On 25-Aug-05, at 6:26 PM, Günther Schmidt wrote:
Tim,
so, if the *right* people are working on it, Morphic can be made to go wooooosh?
Honestly, I don't know how much could be done; messing with morphic has not been my thing. I do strongly suspect that someone that knows plenty about morphic lower levels would be able to make a lot of cleanups. In my experience cleanups can make for very good performance improvements, so I'm hopeful. However I have to say that a lot of code in the image has become so staggeringly baroque, convoluted and mangulated that I have trouble imagining cleanups without massive work. Does anyone have the experience, interest and time to do it?
tim
tim Rowledge wrote:
Honestly, I don't know how much could be done; messing with morphic has not been my thing. I do strongly suspect that someone that knows plenty about morphic lower levels would be able to make a lot of cleanups. In my experience cleanups can make for very good performance improvements, so I'm hopeful. However I have to say that a lot of code in the image has become so staggeringly baroque, convoluted and mangulated that I have trouble imagining cleanups without massive work. Does anyone have the experience, interest and time to do it?
I have interest and time for this. my experience, however, is much more about programming with morphic than dealing with its internals.
so if someone could give me some pointers about the overall display engine structure and spots where to start looking at for improvement, I am willing to give it a try... I cannot promise any result though :)
Stef
There is not only a speed difference between 2.8 and 3.8; there is a notable difference between 3.6 and 3.7. With a profiler on it, one makes some observations (remember we are here in the basement of Morphic and the code gets run a lot): - a. recently some "aColl size = o" were replaced by "aColl isEmpty" : afaik the former is inlined and the latter is a message send. In some places this matters and I reverted them in my image. - b. similarly "aColl at:1' replaced by " aColl first" - c. The method pane in the browser was changed from a PluggableListMorph with StringMorphs to a PLM with a lazy list implementation. Splendid! However the advantage seems to be offset by the switch to the two-way scrollpane as the default which emphasizes the problem d.. The scrollers are calculated twice, once at initialization, once when the real morphs are known. - d. the liberal use of "extent:" triggers a layout every time (not a new problem).
It is said on the subject of code: "make it run, make it run correctly, make it fast", not "make it pretty"; making the code more readable at the expense of speed is not progress. The point is that changes to low level code should always be profiled?
Can we discuss this on the technical merits. An argument that everybody owns or should own a 2.4 GHz super something-or-other and that memory is cheap, is not to the point. On a recent trip in a rather poor part of the world in a small school I found Squeak running on an older machine ( a linux box with Squeak on a distro), because "Squeak delivers so much", a reputation we want keep.
tim Rowledge wrote:
On 25-Aug-05, at 6:26 PM, Günther Schmidt wrote:
Tim,
so, if the *right* people are working on it, Morphic can be made to go wooooosh?
Honestly, I don't know how much could be done; messing with morphic has not been my thing. I do strongly suspect that someone that knows plenty about morphic lower levels would be able to make a lot of cleanups. In my experience cleanups can make for very good performance improvements, so I'm hopeful. However I have to say that a lot of code in the image has become so staggeringly baroque, convoluted and mangulated that I have trouble imagining cleanups without massive work. Does anyone have the experience, interest and time to do it?
tim
On 26 août 05, at 19:01, frits swinkels wrote:
There is not only a speed difference between 2.8 and 3.8; there is a notable difference between 3.6 and 3.7. With a profiler on it, one makes some observations (remember we are here in the basement of Morphic and the code gets run a lot):
- a. recently some "aColl size = o" were replaced by "aColl
isEmpty" : afaik the former is inlined and the latter is a message send. In some places this matters and I reverted them in my image.
- b. similarly "aColl at:1' replaced by " aColl first"
frits
if you could produce some monticello preferrably (or cs) of your changes in a documented and organised manner, we could push that into 3.9a
- c. The method pane in the browser was changed from a
PluggableListMorph with StringMorphs to a PLM with a lazy list implementation. Splendid! However the advantage seems to be offset by the switch to the two-way scrollpane as the default which emphasizes the problem d.. The scrollers are calculated twice, once at initialization, once when the real morphs are known.
- d. the liberal use of "extent:" triggers a layout every time (not
a new problem).
It is said on the subject of code: "make it run, make it run correctly, make it fast", not "make it pretty"; making the code more readable at the expense of speed is not progress. The point is that changes to low level code should always be profiled?
You are right but may be having better profiling tools or culture could help there too. I think that the morphic cleaner was a good effort. Now we should learn from your experience.
Can we discuss this on the technical merits. An argument that everybody owns or should own a 2.4 GHz super something-or-other and that memory is cheap, is not to the point. On a recent trip in a rather poor part of the world in a small school I found Squeak running on an older machine ( a linux box with Squeak on a distro), because "Squeak delivers so much", a reputation we want keep.
we too but some parts of squeak are quite dirty and we should clean them else we will not be able to move. For example, the fileout is terrible (exporting to another dialect or format with a visitor should take 15 min and today I lost hours reading this mess and ended up with a code that is brittle).
Stef
A lot of the 3.6-3.7 delta is due to primitives broken or disused during the i8n effort. These include basic font printing and text layout. (Try editing a big paragraph in a workspace, its not pleasant) These issues have been reported and hopefully will be improved for 3.9.
Thanks for pointing out some specific issues. Its a lot easier to work on those than the general 'it feels slow' comment. If people see any specific UI operations that seem unduly slow, feel free to post them here. They tend to make good small projects.
It would be nice if the compiler could inline stuff like array first that boils down to a single send, I have no idea how the compiler works or if thats a sensible suggestion though. In some methods like the fallback character printing that are fixed-array access heavy, it makes around 25% difference between blah first second third etc and at:1 at:2 at:3 etc.
As for other ideas for speeding things up, there is about a 10% improvement possible by caching gradients. I haven't quite got it packaged up yet. The deal is, all those small 16 pixel icons with gradients each require a 512 element color array be generated, and most of them can be shared. i figured it would be easier to cache gradients rather than try to fix all the clients to share them manually. All those duplicated color maps also use a fair amount of space.
Eddie
frits swinkels wrote:
There is not only a speed difference between 2.8 and 3.8; there is a notable difference between 3.6 and 3.7. With a profiler on it, one makes some observations (remember we are here in the basement of Morphic and the code gets run a lot):
- a. recently some "aColl size = o" were replaced by "aColl isEmpty" :
afaik the former is inlined and the latter is a message send. In some places this matters and I reverted them in my image.
- b. similarly "aColl at:1' replaced by " aColl first"
- c. The method pane in the browser was changed from a
PluggableListMorph with StringMorphs to a PLM with a lazy list implementation. Splendid! However the advantage seems to be offset by the switch to the two-way scrollpane as the default which emphasizes the problem d.. The scrollers are calculated twice, once at initialization, once when the real morphs are known.
- d. the liberal use of "extent:" triggers a layout every time (not a
new problem).
It is said on the subject of code: "make it run, make it run correctly, make it fast", not "make it pretty"; making the code more readable at the expense of speed is not progress. The point is that changes to low level code should always be profiled?
Can we discuss this on the technical merits. An argument that everybody owns or should own a 2.4 GHz super something-or-other and that memory is cheap, is not to the point. On a recent trip in a rather poor part of the world in a small school I found Squeak running on an older machine ( a linux box with Squeak on a distro), because "Squeak delivers so much", a reputation we want keep.
tim Rowledge wrote:
On 25-Aug-05, at 6:26 PM, Günther Schmidt wrote:
Tim,
so, if the *right* people are working on it, Morphic can be made to go wooooosh?
Honestly, I don't know how much could be done; messing with morphic has not been my thing. I do strongly suspect that someone that knows plenty about morphic lower levels would be able to make a lot of cleanups. In my experience cleanups can make for very good performance improvements, so I'm hopeful. However I have to say that a lot of code in the image has become so staggeringly baroque, convoluted and mangulated that I have trouble imagining cleanups without massive work. Does anyone have the experience, interest and time to do it?
tim
Eddie Cottongim wrote:
A lot of the 3.6-3.7 delta is due to primitives broken or disused during the i8n effort. These include basic font printing and text layout. (Try editing a big paragraph in a workspace, its not pleasant) These issues have been reported and hopefully will be improved for 3.9.
These changes are not in 3.7 but only in 3.8 so speed differences between 3.6 and 3.7 are definitely not because of m17n changes.
As for other ideas for speeding things up, there is about a 10% improvement possible by caching gradients. I haven't quite got it packaged up yet. The deal is, all those small 16 pixel icons with gradients each require a 512 element color array be generated, and most of them can be shared. i figured it would be easier to cache gradients rather than try to fix all the clients to share them manually. All those duplicated color maps also use a fair amount of space.
An easier way to fix this issue might be to create smaller ramps - those 512s are worst case for (essentially) fullscreen gradients and Balloon can deal with any power of two here. I don't remember exactly how I did this in Morphic but in Tweak the size of the gradient is bounded by the size of the object to draw (see CGradientFill>>updateFrame: and its senders).
Cheers, - Andreqas
Andreas Raab wrote:
Eddie Cottongim wrote:
A lot of the 3.6-3.7 delta is due to primitives broken or disused during the i8n effort. These include basic font printing and text layout. (Try editing a big paragraph in a workspace, its not pleasant) These issues have been reported and hopefully will be improved for 3.9.
These changes are not in 3.7 but only in 3.8 so speed differences between 3.6 and 3.7 are definitely not because of m17n changes.
Oops, you are right. I referred to 3.7->3.8. The 3.6-3.7 delta is probably mostly because of eye candy. I ran some more 10browser tests on out of the box images:
2.8 -> 1531.3 3.6 -> 3398.3 3.7 -> 6100.6 3.8 -> 9921.6 3.9a 6681 -> 5698.3
So things are getting better, at least if you like opening a lot of browsers. I'm a little suprised at the size of the improvement for 3.9a, but I'll take it!
Eddie
(Again, a disclaimer, there are a lot of visual differences in the various image versions, and that benchmark seems to fluctuate by as much as 10%, but that shouldn't affect the trends.)
Eddie Cottongim writes:
It would be nice if the compiler could inline stuff like array first that boils down to a single send, I have no idea how the compiler works or if thats a sensible suggestion though. In some methods like the fallback character printing that are fixed-array access heavy, it makes around 25% difference between blah first second third etc and at:1 at:2 at:3 etc.
Full method inlining is, almost, the only major feature missing from Exupery for a 1.0 release. Compiling methods that create blocks is the other one. Both require specialised contexts for compiled methods so they're both really part of the same larger feature. With inlining hopefully Exupery will be faster than VisualWorks for sends as well as bytecodes.
Inlining with a native compiler isn't too hard. Doing so in a simple interpreter may be harder because there needs to be somewhere to place the inlined code. A more sophisticated interpreter such as one of Ian's Jitter's that has a threaded code cache could inline as easily as a native interpreter.
Bryce
Eddie,
A lot of the 3.6-3.7 delta is due to primitives broken or disused during the i8n effort. These include basic font printing and text layout. (Try editing a big paragraph in a workspace, its not pleasant) These issues have been reported and hopefully will be improved for 3.9.
I put a comment on http://bugs.impara.de/view.php?id=1650, but I think that the "editing a big paragraph" issue may be related to more the process scheduling than the failing primitives.
-- Yoshiki
(Also added this to Mantis). Here's why I think its the primitive:
Did the test, time profile for about 10 seconds holding down the 'g' key inserting into the 10,000 character paragraph. Here's what I got(summary, the full thing is on Mantis)
3.7: 33.8% into Delay, ~5% into CharacterScanner basicScanCharactersFr...stopConditions:kern: (hard to tell exactly since it doesn't take enough time to show up, i'm estimating from its callers) Most remaining time going into printing
3.8 9.4% into Delay 66.2% into CharacterScanner basicScanCharactersFr...stopConditions:kern:
This is why I think basicScan... performance has gone way downhill and the most likely cause I can see is the failing primitive which is not failing (in this case at least) in 3.7.
Eddie
Yoshiki Ohshima wrote:
Eddie,
A lot of the 3.6-3.7 delta is due to primitives broken or disused during the i8n effort. These include basic font printing and text layout. (Try editing a big paragraph in a workspace, its not pleasant) These issues have been reported and hopefully will be improved for 3.9.
I put a comment on http://bugs.impara.de/view.php?id=1650, but I think that the "editing a big paragraph" issue may be related to more the process scheduling than the failing primitives.
-- Yoshiki
Eddie,
Ok. I'm not exactly confortable with this patch, but it trys to do something clever to go to primitive when possible.
Can you run the benchmark that you reported the 3X, 6X differences with this installed into 3.8-6665 or similar image, and see what you get.
Thanks!
-- Yoshiki
It seems to have solved the big paragraph problem. It is very smooth now, appears to be as good as 3.7.
As for the browser test (which doesn't have much to do with this, no really big paragraphs, but I tried anyway) 3.8-6665 gets around a 10% improvement. 3.9a-6681 gets a smaller improvement, around 1% (less than the margin of error but it did seem to be repeatable). It might be because the default preferences are different, or because the other speed improvements in 3.9a cause this code to be exercised less. In either case its an improvement.
Sounds very promising!
Thanks, Eddie
Yoshiki Ohshima wrote:
Eddie,
Ok. I'm not exactly confortable with this patch, but it trys to do something clever to go to primitive when possible.
Can you run the benchmark that you reported the 3X, 6X differences with this installed into 3.8-6665 or similar image, and see what you get.
Thanks!
-- Yoshiki
Yoshiki,
One minor problem - it seems to break balloon help. All the balloons are empty.
The problem is somewhere in to the GrafPort displayScanner methods. I couldn't immediately figure out how to fix it without hurting the speed. Reverting those two methods will fix the balloons, but make editing slow again.
Oh, and I tried your change on a slow machine, and its a noticable improvement for text editing of any size there, not just monster paragraphs.
Thanks again, Eddie
Eddie Cottongim wrote:
It seems to have solved the big paragraph problem. It is very smooth now, appears to be as good as 3.7.
As for the browser test (which doesn't have much to do with this, no really big paragraphs, but I tried anyway) 3.8-6665 gets around a 10% improvement. 3.9a-6681 gets a smaller improvement, around 1% (less than the margin of error but it did seem to be repeatable). It might be because the default preferences are different, or because the other speed improvements in 3.9a cause this code to be exercised less. In either case its an improvement.
Sounds very promising!
Thanks, Eddie
Yoshiki Ohshima wrote:
Eddie,
Ok. I'm not exactly confortable with this patch, but it trys to do something clever to go to primitive when possible.
Can you run the benchmark that you reported the 3X, 6X differences with this installed into 3.8-6665 or similar image, and see what you get.
Thanks!
-- Yoshiki
One other thing, 3.9a has an optimized StrikeFontSet>>displayString: on: from: to: at: kern: baselineY: that makes a huge difference (factor of 2 or 3) and we don't want to lose it if possible. Something like the new morphs menu for example can take seconds to open without it.
Eddie Cottongim wrote:
Yoshiki,
One minor problem - it seems to break balloon help. All the balloons are empty.
The problem is somewhere in to the GrafPort displayScanner methods. I couldn't immediately figure out how to fix it without hurting the speed. Reverting those two methods will fix the balloons, but make editing slow again.
Oh, and I tried your change on a slow machine, and its a noticable improvement for text editing of any size there, not just monster paragraphs.
Thanks again, Eddie
Eddie Cottongim wrote:
It seems to have solved the big paragraph problem. It is very smooth now, appears to be as good as 3.7.
As for the browser test (which doesn't have much to do with this, no really big paragraphs, but I tried anyway) 3.8-6665 gets around a 10% improvement. 3.9a-6681 gets a smaller improvement, around 1% (less than the margin of error but it did seem to be repeatable). It might be because the default preferences are different, or because the other speed improvements in 3.9a cause this code to be exercised less. In either case its an improvement.
Sounds very promising!
Thanks, Eddie
Yoshiki Ohshima wrote:
Eddie,
Ok. I'm not exactly confortable with this patch, but it trys to do something clever to go to primitive when possible.
Can you run the benchmark that you reported the 3X, 6X differences with this installed into 3.8-6665 or similar image, and see what you get.
Thanks!
-- Yoshiki
Hello...
tR> Honestly, I don't know how much could be done; messing with tR> morphic has not been my thing. I do strongly suspect that someone tR> that knows plenty about morphic lower levels would be able to make tR> a lot of cleanups.
From my experience... some stuff will have to be broken before things
get better. But definitely yes: a huge lot of stuff to clean up. And it can be done. Been there, done that. In particular, with 2.8!
And I would also add that for something positive to happen, we must also have Commitment, Support, and Team Work. Without those my friend... it's useless.
Hi gunther
I would not switch from dolphin to morphic, just for morphic. But it depends what you are doing.
Morphic deserves a massive clean (may be coming back to pre etoy would be a good move). When Morph was only 300 methods. Now the problem is that people with the know how will not do it. Also the concurrency model of morphic is not really good.
Stef
On 25 août 05, at 19:26, Günther Schmidt wrote:
Tim,
so, if the *right* people are working on it, Morphic can be made to go wooooosh?
I've been thinking of switching from Dolphin to Squeak for a couple of reasons, Morphic in particular, because I just can't see how you could do the things you can do in Morphic as easily in Dolphin.
There have been posts on this topic for some time now, so I guess it's something that resists fixing?
Well in short, I'm asking whether it's reasonable to presume that this issue will be resolved any time soon or rather not to depend on that?
Günther
stéphane ducasse wrote:
Hi gunther
I would not switch from dolphin to morphic, just for morphic. But it depends what you are doing.
Morphic deserves a massive clean (may be coming back to pre etoy would be a good move).
Hi
(sorry for interfering)
Maybe also interesting: I do not know how these things worked in early Macs, but they had their own tricks to speed up rendering of windows and graphical elements.
http://www.folklore.org/StoryView.py?project=Macintosh&story=I_Still_Rem...
I do not really understand how it was realized, how should `drawOn:' work more effectively so that it heeds a given clipping region, but they apparently knew how to draw overlapping things fast.
(I have never neither worked nor programmed a Mac so I am not familiar with those mechanisms)
I only know that also in my morphs' onDraw: method I completely ignore the fact how much of it will be actually visible. I do not know how this could be handled conveniently (without breaking my head in investigating what parts of the morphs will visible and which will be out of sight). Now my (and surely many other morphs) simply draw everything. This is the case of PlotMorph2 as well.
When Morph was only 300 methods. Now the problem is that people with the know how will not do it. Also the concurrency model of morphic is not really good.
Stef
Long time ago someone liked the idea of Eveline http://map1.squeakfoundation.org/sm/package/1a0f534c-423b-4cfa-a0d5-17a428ec... (but I do not use it actively now) Maybe its "concurrency" model offered by mechanisms Entity after:schedule: Entity after:schedule:with: Entity after:schedule:with:with: Entity after:schedule:with:with:with: Entity after:schedule:withAll: Some time before, someone http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-July/062155.html noted that these mechanisms could be used also for Morphic. You can see for example:
City beginCall
It is an "event handler". It, among other things, schedules new event with
self after: (randomGenerator negExp: meanTimeBetweenCallAttempts) schedule: #beginCall.
They could replace the Morph step Morph stepTime These scheduling (thanks to usage of the BidirectionaLinkedList) --- i.e. adding a new event to a calendar of events --- has constant time complexity. So there is no penalty. And they are little bit more general than simple stepping.
But I think that easier way how to make Morphic things clear would be to implement it from scratch. Utilization of traits could also heal some inherent problems of single inheritance, which caused bloating of the Morph class just because of two Morph subclasses in unrelated subtrees required to share the same method(s), there was no other way but put it to their common ancestor---Morph. Even though for lot of other subclasses those methods were useless. So Morph growed and growed.
And I agree that this could not be done if there is no skilled one dedicated full time working days and nights, months and years on this.
On 25 août 05, at 19:26, Günther Schmidt wrote:
Tim,
so, if the *right* people are working on it, Morphic can be made to go wooooosh?
I've been thinking of switching from Dolphin to Squeak for a couple of reasons, Morphic in particular, because I just can't see how you could do the things you can do in Morphic as easily in Dolphin.
There have been posts on this topic for some time now, so I guess it's something that resists fixing?
Well in short, I'm asking whether it's reasonable to presume that this issue will be resolved any time soon or rather not to depend on that?
Günther
Hi Fellows,
The MorphicSplitters project is a first step towards this.
MorphicSplitters started with an Etoys-free Morphic image I made on 2004, based on 3.7. It was really easier to understand and could have been a good base for complete Morphic overhaul. At that time I was decided to fork Squeak for my own projects. To me having a clean Morphic is even more valuable that having the fixes and enhancements of the official version. (If somebody wants it, let me know).
But then, many people showed interest on this work. It became clear that although it was hard, it would be possible do this cleaning in the official version. So the MorphicSplitters project was born.
The mid-term objective of MorphicSplitters is to be able to unload Etoys from a standard image and have a smaller Morphic that works properly. The long term objective is to remove Etoys and other optional packages that use Morphic from the image, and have them in SqueakMap. And when all Etoys users switch to Tweak, just leave Etoys behind.
Anybody who wants to help with this project should wait until ToolBuilder and the first version of MorphicSplitters get into the official version. Then, cleaning Morphic could perhaps be more of a community work.
Cheers, Juan Vuletich
----- Original Message ----- From: "stéphane ducasse" ducasse@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Friday, August 26, 2005 4:49 AM Subject: Re: [Q] Speed comparison 2.8 vs 3.8
Hi gunther
I would not switch from dolphin to morphic, just for morphic. But it depends what you are doing.
Morphic deserves a massive clean (may be coming back to pre etoy would be a good move). When Morph was only 300 methods. Now the problem is that people with the know how will not do it. Also the concurrency model of morphic is not really good.
Stef
On 25 août 05, at 19:26, Günther Schmidt wrote:
Tim,
so, if the *right* people are working on it, Morphic can be made to go wooooosh?
I've been thinking of switching from Dolphin to Squeak for a couple of reasons, Morphic in particular, because I just can't see how you could do the things you can do in Morphic as easily in Dolphin.
There have been posts on this topic for some time now, so I guess it's something that resists fixing?
Well in short, I'm asking whether it's reasonable to presume that this issue will be resolved any time soon or rather not to depend on that?
Günther
On 26 août 05, at 19:14, Juan Vuletich wrote:
Hi Fellows,
The MorphicSplitters project is a first step towards this.
MorphicSplitters started with an Etoys-free Morphic image I made on 2004, based on 3.7. It was really easier to understand and could have been a good base for complete Morphic overhaul. At that time I was decided to fork Squeak for my own projects. To me having a clean Morphic is even more valuable that having the fixes and enhancements of the official version. (If somebody wants it, let me know).
Juan if you take the time to work and produce MC file for the 3.9 alpha version, we will pay attention that your changes get incorporated.
But then, many people showed interest on this work. It became clear that although it was hard, it would be possible do this cleaning in the official version. So the MorphicSplitters project was born.
The mid-term objective of MorphicSplitters is to be able to unload Etoys from a standard image and have a smaller Morphic that works properly.
which is an excellent idea.
The long term objective is to remove Etoys and other optional packages that use Morphic from the image, and have them in SqueakMap. And when all Etoys users switch to Tweak, just leave Etoys behind.
Anybody who wants to help with this project should wait until ToolBuilder and the first version of MorphicSplitters get into the official version. Then, cleaning Morphic could perhaps be more of a community work.
marcus worked on toolBuilder but got stuck because the produced image was strange. This is coming.
Stef
Cheers, Juan Vuletich
----- Original Message ----- From: "stéphane ducasse" ducasse@iam.unibe.ch To: "The general-purpose Squeak developers list" <squeak- dev@lists.squeakfoundation.org> Sent: Friday, August 26, 2005 4:49 AM Subject: Re: [Q] Speed comparison 2.8 vs 3.8
Hi gunther
I would not switch from dolphin to morphic, just for morphic. But it depends what you are doing.
Morphic deserves a massive clean (may be coming back to pre etoy would be a good move). When Morph was only 300 methods. Now the problem is that people with the know how will not do it. Also the concurrency model of morphic is not really good.
Stef
On 25 août 05, at 19:26, Günther Schmidt wrote:
Tim,
so, if the *right* people are working on it, Morphic can be made to go wooooosh?
I've been thinking of switching from Dolphin to Squeak for a couple of reasons, Morphic in particular, because I just can't see how you could do the things you can do in Morphic as easily in Dolphin.
There have been posts on this topic for some time now, so I guess it's something that resists fixing?
Well in short, I'm asking whether it's reasonable to presume that this issue will be resolved any time soon or rather not to depend on that?
Günther
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.14/79 - Release Date: 8/22/2005
Hi andreas
Thanks for proposing your help.
at esug with ported all the packages to 3.9alpha, checking all the conflicts. There was nothing serious. Now apparently this is just an order in the configuration files that messed up something. I do not know exactly what since marcus did it. So for now it does not seem a big problem just a pure lack of time... (papers, lectures, new job :)).
Once the toolbuilder is in 3.9a I guess that we will call for help to migrate code to the *Plus (for the unfamiliar widget rewrite that use ToolBuilder framework) classes because some of the classes wtih Plus have less functionality and we could get rid of having double class ie inspector inspectorPlus.
Stef
On 27 août 05, at 07:32, Andreas Raab wrote:
marcus worked on toolBuilder but got stuck because the produced image was strange.
Is there any way I can help?
Cheers,
- Andreas
Am 27.08.2005 um 10:05 schrieb stéphane ducasse:
Hi andreas
Thanks for proposing your help.
at esug with ported all the packages to 3.9alpha, checking all the conflicts. There was nothing serious. Now apparently this is just an order in the configuration files that messed up something. I do not know exactly what since marcus did it. So for now it does not seem a big problem just a pure lack of time... (papers, lectures, new job :)).
Yes, no problem with ToolBuilder. The alternate syntax cleanup needed some shuffling of the load-order to load. This now seems to work, but the resulting update 6681 strangely did not update three packages, so I want to re-build it and test it a bit before making it available. And now source.squeakfoundation.org is down...
Once the toolbuilder is in 3.9a I guess that we will call for help to migrate code to the *Plus (for the unfamiliar widget rewrite that use ToolBuilder framework) classes because some of the classes wtih Plus have less functionality and we could get rid of having double class ie inspector inspectorPlus.
The next steps will be:
-> puplish 6681 -> Merge ToolBuilder (just 24 conflicting method for both changesets, no problem to do) -> pushlish as 6682 -> Merge LookEnhancemetns -> pushlish as 6683
After that, the MorphicSplitters team hat the ball to merge in their work, and I'd like to have the toolrefactoring in, too.
Marcus
Is it reasonable to ask that LookEnhancements are not merged into the image but remain optional. This should be achievable in the packetized image? The reasoning is as follows. The aesthetic quality of an enhancement is in the eye of the beholder. I happen to be an admirer of Tufte's work and I strive for a sober and subdued look except for the important items and a look in which each item has to say something or not take up pixels. Other people may prefer a Heavy Metal look or whatever is currently fashionable in movie houses. It would be counterproductive if all these people had to remove laboriously some look enhancement to be able to apply their own poison ;) This fits with a base image that does just enough but no more.
Marcus Denker wrote:
Am 27.08.2005 um 10:05 schrieb stéphane ducasse:
Hi andreas
Thanks for proposing your help.
at esug with ported all the packages to 3.9alpha, checking all the conflicts. There was nothing serious. Now apparently this is just an order in the configuration files that messed up something. I do not know exactly what since marcus did it. So for now it does not seem a big problem just a pure lack of time... (papers, lectures, new job :)).
Yes, no problem with ToolBuilder. The alternate syntax cleanup needed some shuffling of the load-order to load. This now seems to work, but the resulting update 6681 strangely did not update three packages, so I want to re-build it and test it a bit before making it available. And now source.squeakfoundation.org is down...
Once the toolbuilder is in 3.9a I guess that we will call for help to migrate code to the *Plus (for the unfamiliar widget rewrite that use ToolBuilder framework) classes because some of the classes wtih Plus have less functionality and we could get rid of having double class ie inspector inspectorPlus.
The next steps will be:
-> puplish 6681 -> Merge ToolBuilder (just 24 conflicting method for both changesets, no problem to do) -> pushlish as 6682 -> Merge LookEnhancemetns -> pushlish as 6683
After that, the MorphicSplitters team hat the ball to merge in their work, and I'd like to have the toolrefactoring in, too.
Marcus
Am 28.08.2005 um 01:29 schrieb frits swinkels:
Is it reasonable to ask that LookEnhancements are not merged into the image but remain optional. This should be achievable in the packetized image?
No. For that, we would need to have a theme engine or something like that. The lookenhancements mcz is not a real package, it's a patch. It overrides lots of methods. Handeling packages with overrides will lead to a complete mess soon (just think about what happens when two packages override the same method, or when the original will be changed...)
The reasoning is as follows. The aesthetic quality of an enhancement is in the eye of the beholder. I happen to be an admirer of Tufte's work and I strive for a sober and subdued look except for the important items and a look in which each item has to say something or not take up pixels. Other people may prefer a Heavy Metal look or whatever is currently fashionable in movie houses. It would be counterproductive if all these people had to remove laboriously some look enhancement to be able to apply their own poison ;) This fits with a base image that does just enough but no more.
But he image right now does *not* do "just enough". I would argue that the enhancements actually provides a bit cleaner look that the look we have now. The only solution to this of course would be a real themable Squeak *and* one good theme done by a designer, not a programmer.
Marcus
Is there a repository where i can study this "patch"?
Marcus Denker wrote:
Am 28.08.2005 um 01:29 schrieb frits swinkels:
Is it reasonable to ask that LookEnhancements are not merged into the image but remain optional. This should be achievable in the packetized image?
No. For that, we would need to have a theme engine or something like that. The lookenhancements mcz is not a real package, it's a patch. It overrides lots of methods. Handeling packages with overrides will lead to a complete mess soon (just think about what happens when two packages override the same method, or when the original will be changed...)
The reasoning is as follows. The aesthetic quality of an enhancement is in the eye of the beholder. I happen to be an admirer of Tufte's work and I strive for a sober and subdued look except for the important items and a look in which each item has to say something or not take up pixels. Other people may prefer a Heavy Metal look or whatever is currently fashionable in movie houses. It would be counterproductive if all these people had to remove laboriously some look enhancement to be able to apply their own poison ;) This fits with a base image that does just enough but no more.
But he image right now does *not* do "just enough". I would argue that the enhancements actually provides a bit cleaner look that the look we have now. The only solution to this of course would be a real themable Squeak *and* one good theme done by a designer, not a programmer.
Marcus
Am 28.08.2005 um 17:14 schrieb frits swinkels:
Is there a repository where i can study this "patch"?
http://squeak.saltypicke.com project "LookEnhancements" It even has a screenshot.
Marcus
For me here on the westcoast of the amaerican continent, the site you quoted cannot be found.
Marcus Denker wrote:
Am 28.08.2005 um 17:14 schrieb frits swinkels:
Is there a repository where i can study this "patch"?
http://squeak.saltypicke.com project "LookEnhancements" It even has a screenshot.
Marcus
frits swinkels wrote:
For me here on the westcoast of the amaerican continent, the site you quoted cannot be found.
Small typo snuck in...
Michael
Hi Marcus -
The next steps will be:
-> puplish 6681 -> Merge ToolBuilder (just 24 conflicting method for both changesets, no problem to do)
BTW, when you do this, can you do me two favours?
* Move the methods in ToolBuilder-Specs out of the extension methods and into the appropriate classes. The "Specs package" is not intended as a package in its own right just as loose collection of methods that need some home and using extensions was the only reasonable way to manage them up until integration.
* Please do NOT include the ToolBuilder-Examples package since it conflicts with the PlusTools (and having these examples in a "basic" image seems overkill anyway).
Thanks, - Andreas
Am 28.08.2005 um 04:28 schrieb Andreas Raab:
Hi Marcus -
The next steps will be: -> puplish 6681 -> Merge ToolBuilder (just 24 conflicting method for both changesets, no problem to do)
BTW, when you do this, can you do me two favours?
- Move the methods in ToolBuilder-Specs out of the extension
methods and into the appropriate classes. The "Specs package" is not intended as a package in its own right just as loose collection of methods that need some home and using extensions was the only reasonable way to manage them up until integration.
- Please do NOT include the ToolBuilder-Examples package since it
conflicts with the PlusTools (and having these examples in a "basic" image seems overkill anyway).
Done.
Marcus
Juan Vuletich wrote: .....
The mid-term objective of MorphicSplitters is to be able to unload Etoys from a standard image and have a smaller Morphic that works properly. The long term objective is to remove Etoys and other optional packages that use Morphic from the image, and have them in SqueakMap. And when all Etoys users switch to Tweak, just leave Etoys behind.
And when all Morphic users switch to Tweak or wxSqueak, just leave Morphic behind. Or is there any specific reason to stay with Morphic?
To put it differently, why do you seem to think only Etoys users will switch to Tweak, or why should one who wants a 'morphic' UI not switch to Tweak?
regards, Martin
Hi Martin,
... And when all Morphic users switch to Tweak or wxSqueak, just leave Morphic behind. Or is there any specific reason to stay with Morphic?
Personally, I like Morphic and I'm not sure Tweak will replace it, at least for my needs. It's a matter of personal preference. The whole ToolBuilder idea is to be able to choose between different graphic frameworks, for example Tweak, Morphic and perhaps (not sure) MVC.
To put it differently, why do you seem to think only Etoys users will switch to Tweak,
As I understand it, the objective of Tweak is to replace Etoys.
or why should one who wants a 'morphic' UI not switch to Tweak? You answered the question yourself. Simply because Tweak is not 'morphic'.
regards, Martin
Cheers, Juan Vuletich
Hi Juan,
many people seem to think Tweak is the new Etoys. Why? All I can see indicates that it is the new Morphic. So, putting my question again in other words ;)
Why is Tweak not "morphic" ? I mean if there is a specific quality Morphic has that Tweak hasn't, perhaps it would be useful to make the Tweak team aware of it in time.
Other than that your effort is of course important for the many existing Squeak programs, that want to be used without consuming porting energies.
regards, Martin
Hi Martin,
... And when all Morphic users switch to Tweak or wxSqueak, just leave Morphic behind. Or is there any specific reason to stay with Morphic?
Personally, I like Morphic and I'm not sure Tweak will replace it, at least for my needs. It's a matter of personal preference. The whole ToolBuilder idea is to be able to choose between different graphic frameworks, for example Tweak, Morphic and perhaps (not sure) MVC.
To put it differently, why do you seem to think only Etoys users will switch to Tweak,
As I understand it, the objective of Tweak is to replace Etoys.
or why should one who wants a 'morphic' UI not switch to Tweak? You answered the question yourself. Simply because Tweak is not 'morphic'.
regards, Martin
Cheers, Juan Vuletich
Martin Wirblat wrote:
Hi Juan,
many people seem to think Tweak is the new Etoys. Why? All I can see indicates that it is the new Morphic. So, putting my question again in other words ;)
I agree with this. From what I see, Tweak is a new GUI upon which etoys, et al will be built. In the "Tweak Introduction" pdf it explicitly states that Tweak is intended to replace the Morphic UI in the future.
http://tweak.impara.de/TECHNOLOGY/Tutorials/
states:
""" Tweak started back in 2001 when it became obvious that the eToy architecture in Squeak had hit the wall in terms of what the Morphic infrastructure could provide. Here is the original memo that started it all. """
Why is Tweak not "morphic" ? I mean if there is a specific quality Morphic has that Tweak hasn't, perhaps it would be useful to make the Tweak team aware of it in time.
So it seems to me that Tweak learns from Morphic, builds and improves, not limits. So I agree. What does Morphic have that Tweak doesn't/won't?
Other than that your effort is of course important for the many existing Squeak programs, that want to be used without consuming porting energies.
[snip]
I agree that what the Morphic splitters is doing is a valuable service to many. It also may help any transition to Tweak by the Tweak people. I don't know. It would seem that a smaller set of items requiring porting to Tweak for a minimal image would be an advantage. I don't know.
However, I have nothing invested in learning Morphic. As such I look forward to Tweak and learning it for future projects.
Not trying to bring up any debate, but Tweak will also have a cleaner license heritage. It is under the MIT license and should have no obligation to any roaring mouse. :) (aka Disney)
Just my 2 centavos. :)
Jimmie
Hi Martin.
I believe that the Tweak folks know more about Morphic than me. There's nothing I could teach them.
I've just read the Tweak Introduction pdf. I believe it's just a matter of personal taste.
Cheers, Juan ----- Original Message ----- From: "Martin Wirblat" sql.mawi@t-link.de To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Friday, August 26, 2005 8:11 PM Subject: Re: [Q] Speed comparison 2.8 vs 3.8
Hi Juan,
many people seem to think Tweak is the new Etoys. Why? All I can see indicates that it is the new Morphic. So, putting my question again in other words ;)
Why is Tweak not "morphic" ? I mean if there is a specific quality Morphic has that Tweak hasn't, perhaps it would be useful to make the Tweak team aware of it in time.
Other than that your effort is of course important for the many existing Squeak programs, that want to be used without consuming porting energies.
regards, Martin
On 8/25/05, Günther Schmidt gue.schmidt@web.de wrote:
I've been thinking of switching from Dolphin to Squeak for a couple of reasons, Morphic in particular, because I just can't see how you could do the things you can do in Morphic as easily in Dolphin.
I wouldn't work from the assumption that Morphic will be cleaned up any time soon. Just the mere project of packaging Morphic has turned out to be a formidable task, and that's without even looking at what the code does :-).
Of course, you can ignore Morphic alltogether if your target platform is one of Mac/Win/Linux - modulo some quirks (but a whole lot less quirks than you'd encounter in Morphic), we found wxSqueak quite suitable for production work.
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Andres Valloud -
Bryce Kampjes -
Cees De Groot -
Eddie Cottongim -
frits swinkels -
Günther Schmidt -
Jimmie Houchin -
Juan Vuletich -
Marcus Denker -
Martin Wirblat -
Matej Košík -
Michael Rueger -
stéphane ducasse -
Stéphane Rollandin -
tim Rowledge -
Yoshiki Ohshima