Possible Bug?

Hi Jeremy,

it looks to me as if it works fine if you remove the second line in this script:

You might also try to replace it with setting bottom instead of y.

The source of this is likely that in Etoys y goes up but in Squeak it goes down, so in various places of the system it has to be inverted. That causes truncation to sometimes round up or down. Which apparently accumulates some error. Not trivial to fix.

- Bert -

On 26 January 2018 at 22:49, Jeremy Landry <[hidden email]> wrote:

I haven't investigated it into the Etoys source, but I found this bizarre bug, likely appearing due to a number being turned into an integer when it's odd, but I cannot figure out why it would be called at all...

Included is a project that demonstrates this bug.  I looked at the individual pieces and they aren't 'personally' responsible, but when working as a unit, they then exhibit the bug.

​

 custom window demos.013.pr

​

Basically what seems to cause it is resizing nested playfields via script.  R​​esizing with morphic handles works fine, but when sending an Etoys 'LENGTH' change, somewhere along the line, things go wrong.  Again, my guess is that some number is getting changed into an integer from a floating point, and thus getting rounded up, which would shift it up when it's not a floating point number any longer.  However, this doesn't explain why it doesn't have the same symptom when changing WIDTH.

Thanks for any insight into dealing with this.  I'm not exactly sure where to begin looking within the Etoys Source to make things work as expected since there's likely 30 reasons (read: random object methods) why this might occur and only for vertical change/LENGTH change.

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland