Possible Bug?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible Bug?

Jeremy L.
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.


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
Reply | Threaded
Open this post in threaded view
|

Re: Possible Bug?

Bert Freudenberg
Hi Jeremy,

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

Inline images 3

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.


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
Reply | Threaded
Open this post in threaded view
|

Re: Possible Bug?

Jeremy L.
I'll give that a shot, thanks.  I thought I had tried everything, but I guess staring at it for too long made me impervious to seeing my own mistakes.  I'm still learning ways to self-correct...

On Fri, Feb 2, 2018 at 5:58 AM, Bert Freudenberg <[hidden email]> wrote:
Hi Jeremy,

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

Inline images 3

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.


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



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