--- On Tue, 5/24/11, Bert Freudenberg <bert at freudenbergs.de> wrote:

> From: Bert Freudenberg <bert at freudenbergs.de>
> Subject: Re: [squeak-dev] The Inbox: Graphics-wiz.183.mcz
> To: "Jerome Peace" <peace_the_dreamer at yahoo.com>, "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
> Date: Tuesday, May 24, 2011, 5:47 AM
> Hi Jerome,
> 
> since BitBlt only works on integer coordinates anyway, and
> even accepts nil instead ints, why should you want to spend
> all that effort of converting Fractions to Floats?
> 
Hi Bert,

As is the case with most of my debugging I have to do it in a context of learning as I go. Some of my design decisions are aimed at maximizing that learning.

The goal here was to fix one bug in the right place. The primitive will fail if it receives a class Fraction but not if it receives the same number as a float. I don't wish to touch the primitive. I am not about to learn enough today to know how. I can make copyBits take responsibility for insuring the primitive is happy with the parameters it receives. The minimum I need to do is translate fractions when I get them into floats before they get to the primitive. The primitive handles floats on its own. I don't have to second guess or take responsibility away from it.

As a rule it is always better not to increase entropy. I.E don't erase information. Rounding is doing that. It is also doing it in the dark. I don't know what the user intended. Also I don't want to filter anything I don't have to. Else I would never be able to test how the primitive handles fractions. For example, one curiosity is which pixels will it paint if I tell it x is 0.75 and the width is 4.5 ? I don't know the answer and I want to leave myself a way of finding out. Part of what I did was to leave in place ways of testing. 

If somebody creates a fractional send I need only guarantee it works. If I do that then if one of the 130 users of copyBits pulls information out of the Grafport or BitBlt I have not changed the essence of that information. I don't know and I don't have time to check how people are using or misusing things in squeak. The same logic goes for not forcing people to round to integers at a higher level. Once this fix is in place we can begin to tackle all the places that do that rounding inappropriately.

This example you give may or may not be doing things correctly. To avoid the class fraction bug it may have skewed its design in favor of rounding/truncating to an integer. I am not ready to test or judge that yet. I want a way to do that when the time comes. If you look at roundVariables you see why I am cautious. I expect to find errors in others peoples code. I tested what happened when the error message was commented out androundVariables was invoked. I am still trying to explain why I saw what I saw.

Cunningham's do the simplest thing that might work applies here. Once we gain experience with this fix we will know if we have to try something else. Fixes are incremental.

I had enough time yesterday to produce this fix. As I learn more I might go farther.

The asNonFraction stuff is not really more work but less. I learned to do that after writing asNonFractionalPoint. At some point I will be able to rewrite my first attempt using the new method in place of clumsy type checking. Using it means I don't have to change anything unless really necessary. Deferring any rounding decisions to the primitive. copyBits only needs to adjust extents if one is undefined or unacceptable. Ditto origins and clipRange. If I profile when changes are needed then I can get a picture of how the users of copyBits are using it and more importantly misusing it.  

So I made design decisions with their usefulness to future work in mind. 

Part of the reason for stopping here is the fix was needed quickly to head of a worse fix that I am trying to convince Dave to revert. Part of being careful is years of experience tracking down the cause of gribbles and off by one pixel errors.

Unfortunately squeak has a lot of sloppy maintainers. I have a right to say this. I have seen and cleaned up a good deal of graphic sloppiness. I have also seen a lot of graphic sloppiness that is not yet possible to clean up. This fix, exactly the way it is, will help towards the next step in that clean up process.

I hope you will now support this fix and my general effort to reduce graphic bugs.

Yours in curiosity and service, --Jerome Peace

P.S thanks for sending me a personal copy of your post. Makes it easier for me to respond on thread. Cheers -Jer