How can we deal with Message rot?
Hi all, This is a plea from a bug tracker for some guidance. People in the community know that code that does not stay in the image suffers from bit rot. That is it gets more and more incompatible with what is there. In my travels (thru code) I have come across a more pernicious decay. It can be best described a message rot. Basically a shared message loses its meaning. Or to be more exact is given different meanings by different Classes. The classes writen at different times or by different authors all disagree on the meaning and thus lose their polymorphism. People will not be surprised to hear that the example I have in mind is the meaning of forwardDirection, rotationDegrees and heading. And also position, referencePosition and centerOfRotation. You can look at the code and track implementers and senders to see how bad this problem has gotten. Any bug in there I want to fix seems to involve clearing up the whole tangle. My problem and the guidance I seek it this. A fix will break backward compatability. It has to because once a confusion has been introduced the patches for code use part of the confusion to patch around the more objectionable bugs. How do I get community approval? I need consensus amoung programmers it affects; Acceptance of the fixes by the release team (of whatever future version it is ready for.); And acceptance of the new understanding as a standard amoung future enhancers and maintainers of squeak. How is this best achieved? Yours in curiosity and service, --Jerome Peace Footnote: more details of the heading etc. confusion can be found mantis http://bugs.impara.de/view.php?id=5674 0005674: Why doesn't heading = forwardDirection + rotationDegrees for all morphs all the time? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
Jerome, thanks for the great introduction!
The 3.10 release is going to do something things that make the problem worse, and some things that make it better. The problem is how to make a system consistent when it is made out of lots of components and there is no longer a single monolithic image. One of the big advantages of an image is that it makes it easier to make sure that the system is consistent. As Jerome says, code that is not in the image doesn't get updated when the image changes. You can't do an "all senders" to discover that it needs updating. And you can't do an "all implementors" to look at all the methods to infer invariants. As more and more people work on a system, it gets harder and harder to make it consistent. Is it possible to have the same level of consistency in a system built from many componets developed by many people that you find in the orignial Smalltalk image? No, it isn't. A system built by a large group cannot be as consistent as a team built by a small group. However, it can be consistent enough. The 3.10 release is going to componentize Squeak. See my description of Pavel Krivanek's KernelImage at http://www.cincomsmalltalk.com/userblogs/ralph/blogView?showComments=true&entry=3342635112 The smallest image will be little more that what is necessary to run the compiler. It will have a text-based UI, i.e. Morphic is a loadable package. if we keep on ignoring code that is not part of the image and make the image very small, then Squeak will die. So, a major part of the 3.10 release will be an improved testing strategy. We will have a test server and a standard set of tests. All changes will have to pass the tests, which will involve loading lots of packages. So, if you make a change and ignore the standard packages, your change is unlikely to be accepted. There will be an easy way to load all the standard packages, so if you are working in a minimal image then you can make sure your changes will pass the tests by loading all the packages and testing the changes in an expanded image. Part of splitting the image into components involves having "official" and "unofficial" components. The official components are the ones that the release team will update. We'll have tests for them and make sure that changes do not break them. There will be a way for you to get a component accepted as official, basically by providing a test suite and having it pass all the existing tests. This doesn't really answer your question of how to make a fundamental change to Morphic. Morphic is short on automated tests, so changes to Morphic are more likely to cause trouble even though they pass the tests than changes to kernel classes. But the idea is the same as for any other system. Write tests that show what you want to do, and then make the changes, continually checking that you don't break anything else. Because Morphic is undertested, you'll probably have to write some tests for Morphic to prove to yourself (and us) that you didn't break anything. These will be valuable beyond your particular changes. Most people seem to agree that Squeak needs to be modularized. I think that most of us do not realize the difficulties this will cause. The integrity of Squeak has been enhanced by its lack of modularity, and we do not want to lose its integrity by modularizing it. I think that modularizing Squeak will lead to more tools to balance the tradeoffs between componentization and consistency. My goals as leader of the 3.10 release team are to modularize Squeak and to develop processes for making a release that will improve the quality of the software and make it easier to make a release. Improved testing will be a key part of this. I imagine that our first few attempts will show a lot of need for improvement, and that we will have to shift directions a few times until we come up with a good process. But these are the main things on my agenda. The final 3.10 release will have lots of improvements, including new packages, new tools, and new features. But for me, these will be icing on the cake, since my main goal is to figure out how to modularize Squeak without losing the advantages of an integrated image. -Ralph Johnson |
In reply to this post by Jerome Peace
On Dec 27, 2006, at 6:36 , Jerome Peace wrote:
> more details of the heading etc. confusion > can be found mantis > > http://bugs.impara.de/view.php?id=5674 > > 0005674: Why doesn't heading = forwardDirection + > rotationDegrees for all morphs all the time? As far as I know, rotation and animation (that is, LOGO-style turtle semantics) is only seriously used in Etoys. For most other UI users it's merely a gimmick, so you would not need to worry about backwards compatibility too much. Etoys uses a very small set of messages (manifest in the Player class). As long as you ensure this small protocol does not break, Etoys should be fine. Now, Player is very careful to always figure out the "right" morph to apply rotations to, depending on whether it wants to be "flexed" (in a TransformMorph) or if it handles rotation itself etc. This is why you see inconsistent behavior in the individual morph classes - in Etoys they are not used directly, but through the Player, and this is why your equation does not hold for each individual morph. I think you would have to eliminate TransformMorph completely, which might complicate other Morphs - until now, that "ugly" transformation stuff was factored out. - Bert - |
heading = forwardDirection + rotationDegrees (was Re:
How can we deal with Message rot?) Hi Bert, Thanks for your thought on this. >Bert Freudenberg bert at freudenbergs.de >Wed Dec 27 14:14:12 UTC 2006 wrote: > >On Dec 27, 2006, at 6:36 , Jerome Peace wrote: >> more details of the heading etc. confusion >> can be found mantis >> >> http://bugs.impara.de/view.php?id=5674 >> >> 0005674: Why doesn't heading = forwardDirection + >> rotationDegrees for all morphs all the time? > >As far as I know, rotation and animation (that is, >semantics) is only seriously used in Etoys. I think it only seems this way. First, I am making the assumption that by eToys you are refering to programming with tiles, Players etc. The larger realm of eToys also consists of morphs and their behavior (particular behavior in response to halo handles). So what affects programming with tiles spills over into morph considerations. >For most other UI users >it's merely a gimmick, so you would not need to worry about backwards >compatibility too much. Ok. thanx. >Etoys uses a very small set of messages >(manifest in the Player class). As long as you ensure this small >protocol does not break, Etoys should be fine. > >Now, Player is very careful to always figure out the "right" morph to >apply rotations to, depending on whether it wants to be "flexed" (in >a TransformMorph) or if it handles rotation itself etc. Etoys player would benifit greatly from knowing less about how a morph carries out its tilting responsibilities. That means establishing a consistent language and having all classes (and their programmers and maintainers) stick to it. This is the task of an oft promised but long overdue refactoring of morphic stuff. I haven't worked out the details but the notion I have is that it should be possible to say "player assuredFlexibleCostume heading: aHeading " and have the right thing happen. And maybe later "player assuredSimplestCostume" which would remove redundant renderers. >This is why >you see inconsistent behavior in the individual morph classes. But it shouldn't be that way. The responsibilities can be clearly defined and every morph would benifit. Many of the deep bugs I run into have the TransformationMorph decorator as their root. Lots of the gribble leaving problems come from a mismatch of assumptions between TfMorph ( which believes you can translate the origin into the 3rd quadrant) while every body else believes that truncate is the same as floor because all points are in the 1st quadrant. Clipping boxes get calculated wrong and are often of by one just when you need them not to be. Results: screen gribbles abound. >- inEtoys they are not used directly, but through the Player, and this is >why your equation does not hold for each individual morph. I think >you would have to eliminate TransformMorph completely, which might >complicate other Morphs - until now, that "ugly" transformation stuff >was factored out. As I look at the code I see constant attempts to worry about which morph is actually being talked to renderer or renderee. The code practically begs to be refactored. Its just a big job at the moment. I await enlightenment and inspiration. Meanwhile I am trying refactorings that lay the ground work for the simplification of the Tf mess. Yours in service, --Jerome Peace __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
On 2006 December 29 01:27, Jerome Peace wrote:
<<snip>> > Many of the deep bugs I run into have the > TransformationMorph decorator as their root. > Lots of the gribble leaving problems come from a > mismatch of assumptions between TfMorph ( which > believes you can translate the origin into the 3rd > quadrant) while every body else believes that truncate > is the same as floor because all points are in the > 1st quadrant. Clipping boxes get calculated wrong and > are often of by one just when you need them not to be. Jerome, Could you point out a few concrete examples (class, method) of this behaviour? I started work on a (exteremely limited) set of tests for etoys and morphic, and perhaps it would make sense to document what you found in a test; although documenting something that is (if I understand) considered broken may not be as valuable, it should be easy to convert the test code if/once the code under test is refactored. Thanks Milan > > > Results: screen gribbles abound. > > >- inEtoys they are not used directly, but through the > > Player, and this is > > >why your equation does not hold for each individual > > morph. I think > > >you would have to eliminate TransformMorph > > completely, which might > > >complicate other Morphs - until now, that "ugly" > > transformation stuff > > >was factored out. > > As I look at the code I see constant attempts to worry > about which morph is actually being talked to renderer > or renderee. The code practically begs to be > refactored. Its just a big job at the moment. > I await enlightenment and inspiration. Meanwhile I am > trying refactorings that lay the ground work for the > simplification of the Tf mess. > > Yours in service, --Jerome Peace > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com |
In reply to this post by Jerome Peace
Ralph,
I wish you much success. Your idea of defining behavior by tests is a good start. Good tests for Morphic will be hard to write, and there will obviously need to be a process for getting them (and any) tests accepted for inclusion in the official suite, which will need to accept additions, deletions, and edits over time. Beyond that, some things will need to break. Sometimes, it will be that a test fails when it should pass (overly aggressive assertions, etc.). In other areas (e.g. stream exhaustion), Squeak behaves very differently from other Smalltalks, and probably should be changed. I would further encourage you to draw an underscore in the sand at the same time. Modularization will involve some pain. When it's over, I would hope to see reasonable ANSI/cross-dialect compatibilty (including streams), and unrestricted use of underscores in source code and the compiler. Please note that the latter does not have to kill single-key assignment, which can be accomplished by optional editor behavior. I doubt there will ever be a better time to clean up loose ends. Bill Ralph Johnson wrote (much snipped): Part of splitting the image into components involves having "official" and "unofficial" components. The official components are the ones that the release team will update. We'll have tests for them and make sure that changes do not break them. There will be a way for you to get a component accepted as official, basically by providing a test suite and having it pass all the existing tests. This doesn't really answer your question of how to make a fundamental change to Morphic. Morphic is short on automated tests, so changes to Morphic are more likely to cause trouble even though they pass the tests than changes to kernel classes. But the idea is the same as for any other system. Write tests that show what you want to do, and then make the changes, continually checking that you don't break anything else. Because Morphic is undertested, you'll probably have to write some tests for Morphic to prove to yourself (and us) that you didn't break anything. These will be valuable beyond your particular changes. My goals as leader of the 3.10 release team are to modularize Squeak and to develop processes for making a release that will improve the quality of the software and make it easier to make a release. Improved testing will be a key part of this. I imagine that our first few attempts will show a lot of need for improvement, and that we will have to shift directions a few times until we come up with a good process. But these are the main things on my agenda. The final 3.10 release will have lots of improvements, including new packages, new tools, and new features. But for me, these will be icing on the cake, since my main goal is to figure out how to modularize Squeak without losing the advantages of an integrated image. Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 846-1285 FAX: (352) 392-7029 |
In reply to this post by Milan Zimmermann-2
So, last night, having been fighting Morphic for about 5 hours (trying to write a really, really simple example for my first class), I was about to write a flame "why I hate Morphic and what we should do about it". But I went to sleep instead. And now I notice this from Jerome: On 2 Jan 2007, at 6:33, Milan Zimmermann wrote:
Transformations are indeed the core of the problem. It has often seemed to me that all morphs should be able to take care of their own transformations, rather than having to be embedded in a TransformationMorph. Last night, I was trying to do a Morphic version of Adele Goldberg's "Joe the Box" as presented in Mark Guzdial's book. Because I have had students really confused by TransformationMorphs (which break the rule that every Morph is visible on the screen), I made a "BoxMorph" just a subclass of PolygonMorph with four vertices. This worked pretty well, except that rounding errors accumulate as you rotate the box; I couldn't think of a simple solution to that. Then I did NamedBoxMorph, which puts a text morph containing the Box's name (joe, jill, etc) in the center of the Polygon. Well, as you rotate the Box, the text inside does _not_ rotate. This is not what I expect from embedded submorphs. It turns out that there is no code in PolygonMorph to rotate the submorphs. I think that this is a bug, but writing the code involves more than I know. (I did try. Applying a MorphicTransformaiton to a point is easy, but applying it to a Morph --- that I couldn't figure out.) Also, as you rotate the PolygonMorph, and morph at its center refuses to stay at the center. It "precessses" towards the origin and back. Try it. (My code is in a publicly readable SqueakSource project at http://www.squeaksource.com/PSUCS520 . The package is called CS520-MorphicBoxes). So I gave up, and tried a different approach, which I have used previously. I made a BoxMorph2 a TransformationMorph, with a RectangleMorph inside it. Both of them the same size. Easy to set up, right? Just give them the same bounds. Wrong. Even before they are in any world, the TransformationMorph has resized itself and has changed it's scale factor to 1.7 I'm reduced to trial and error to find an initialization sequence that works. But when I find one, the BoxMorph2 can indeed be rotated. Then I put a TextMorph in the center (myBoxMorph2 addMorphCentered: aTextMorph). All hell breaks loose. The label is a couple of inches down and to the right of the box. blue-clicking on the box puts the halo around the label. I spend a long time looking for this bug, and find somewhere in the re-computation of the bounds that fullbounds of the BoxMorph2 has grown by a factor of 2 to 3 (but different factors in the x and y directions). I'm supposed to explain this to studnets when I have no idea waht is going on myself. What did Dan Ingalls write about "personal mastery?" I eventually get it working by embedding the TextMorph inside the RectangleMorph (which is inside the Transformation Morph). Why does it work this way around and not the other way? Beats me. The code is ugly because I use findA: to get hold of the internal RectangleMorph. (So, later I did see the comment that says: "TransformationMorphs are assumed to have only one submorph". If that's true, maybe one should get an error when an attempt is made to add a second one?) I keep on thinking that Morphic is really elegant and that all of this will one day make sense if only I can learn to squint in the right way. But I'm seriously beginning to wonder ... The good news is that the final code is really short and sweet, comparing well with the "draw on the raw screen" version that mark Guzdial puts in his book (Package "Boxes" in the same SqueakSource project, if you care to look). The bad news is that it is extremely brittle. I liek telling students to play with stuff an see what happens, and then to figure out why. I get the feeling that changing the order of two statements in this code might just as well precipitate the next revolution as change the stacking order of two Morphs ... and I have _no idea_ why. OK, so now I'm just venting. But I would really like to know if I'm the only one who feels this way. What to do about it? I think that getting rid of TransformationMorphs as wrappers (they are not really decorators, because they are not inserted into the Morphic hierarchy until something needs to be transformed) would help, and instead giving each Morph the ability to transform itself. This would involve a test, of course: myTransformation ifNotNi: [ ... ] which is a tad ugly. This is similar to what was done with Alignment a while back --- giving every Morph the ability to align its submorphs. (However, I think that that change may have been a mistake; adding a separate allignmentMorph to the hierarchy makes much more sense to me than adding a separate TransformationMorph. Moreover, we know that any 2-D affine transformation can be represented as a 3 x 2 matrix, so there can be a single universal implementation of transformations Andrew P. Black Department of Computer Science Portland State University +1 503 725 2411 |
Andrew P. Black skrev:
> > I keep on thinking that Morphic is really elegant and that all of this > will one day make sense if only I can learn to squint in the right > way. But I'm seriously beginning to wonder ... Morphic has it's flaws... > > The good news is that the final code is really short and sweet, > comparing well with the "draw on the raw screen" version that mark > Guzdial puts in his book (Package "Boxes" in the same SqueakSource > project, if you care to look). The bad news is that it is extremely > brittle. I liek telling students to play with stuff an see what > happens, and then to figure out why. I get the feeling that changing > the order of two statements in this code might just as well > precipitate the next revolution as change the stacking order of two > Morphs ... and I have _no idea_ why. > > OK, so now I'm just venting. But I would really like to know if I'm > the only one who feels this way. starts to show up. > > What to do about it? I think that getting rid of TransformationMorphs > as wrappers (they are not really decorators, because they are not > inserted into the Morphic hierarchy until something needs to be > transformed) would help, and instead giving each Morph the ability to > transform itself. This would involve a test, of course: > myTransformation ifNotNi: [ ... ] which is a tad ugly. This is > similar to what was done with Alignment a while back --- giving every > Morph the ability to align its submorphs. (However, I think that that > change may have been a mistake; adding a separate allignmentMorph to > the hierarchy makes much more sense to me than adding a separate > TransformationMorph. Moreover, we know that any 2-D affine > transformation can be represented as a 3 x 2 matrix, so there can be a > single universal implementation of transformations ages as no one found it compelling enough to refactor Morphic to handle transformations without using the TransformationMorph stuff. Tweak is next generation Morphic, and is written to handle transformation from the ground up, but it has less users and less documentation etc... Karl |
Free forum by Nabble | Edit this page |