I am about to close some old mantis reports.
There are two issues related to the vm and easy to solve ( I think).
http://bugs.squeak.org/view.php?id=7265
0007265: Bug in Matrix2x3Plugin okayIntValue: Method okayIntValue: value uses argument to compare with lower bound, m23ResultX for upper bound.
okayIntValue: value ^(value >= -1073741824 asFloat and:[m23ResultX <= 1073741823 asFloat])
should be: okayIntValue: value ^(value >= -1073741824 asFloat and:[value <= 1073741823 asFloat])
I looked at the Matrix2x3Plugin code, and the wrong comparsion is still there.
http://bugs.squeak.org/view.php?id=7756 0007756: InputSensor>>cursorPoint: uses primitive 91 (primitiveTestDisplayDepth)
Either we remove the code from InputSensor, or we add another new primitive for setting the mouse cursor. (Maybe we don't need this functionality or this is already possible with the hostwindow plugin?)
nicolai
On Sun, Sep 13, 2015 at 10:23:42PM +0200, Nicolai Hess wrote:
I am about to close some old mantis reports.
There are two issues related to the vm and easy to solve ( I think).
http://bugs.squeak.org/view.php?id=7265
0007265: Bug in Matrix2x3Plugin okayIntValue: Method okayIntValue: value uses argument to compare with lower bound, m23ResultX for upper bound.
okayIntValue: value ^(value >= -1073741824 asFloat and:[m23ResultX <= 1073741823 asFloat])
should be: okayIntValue: value ^(value >= -1073741824 asFloat and:[value <= 1073741823 asFloat])
I looked at the Matrix2x3Plugin code, and the wrong comparsion is still there.
I am quite sure you are right about this, just from looking at the code. But I do want to check - the method is from ar 1998, so it has been in all the VMs for a very long time. How did you find the problem? Is there a test or an example that shows the issue?
After fixing the method as you suggest, it will test for integer values with bit values in the range 11000000000000000000000000000000 through 00111111111111111111111111111111, which presumably maps to a range of acceptable values for use in the Matrix2x3Plugin floating point operations. So that looks quite reasonable, but I am puzzled that this check has been wrong since 1998, so that is why I ask.
Thanks!
Dave
On Sun, Sep 13, 2015 at 07:17:51PM -0400, David T. Lewis wrote:
On Sun, Sep 13, 2015 at 10:23:42PM +0200, Nicolai Hess wrote:
I am about to close some old mantis reports.
There are two issues related to the vm and easy to solve ( I think).
http://bugs.squeak.org/view.php?id=7265
0007265: Bug in Matrix2x3Plugin okayIntValue: Method okayIntValue: value uses argument to compare with lower bound, m23ResultX for upper bound.
okayIntValue: value ^(value >= -1073741824 asFloat and:[m23ResultX <= 1073741823 asFloat])
should be: okayIntValue: value ^(value >= -1073741824 asFloat and:[value <= 1073741823 asFloat])
I looked at the Matrix2x3Plugin code, and the wrong comparsion is still there.
I am quite sure you are right about this, just from looking at the code. But I do want to check - the method is from ar 1998, so it has been in all the VMs for a very long time. How did you find the problem? Is there a test or an example that shows the issue?
After fixing the method as you suggest, it will test for integer values with bit values in the range 11000000000000000000000000000000 through 00111111111111111111111111111111, which presumably maps to a range of acceptable values for use in the Matrix2x3Plugin floating point operations. So that looks quite reasonable, but I am puzzled that this check has been wrong since 1998, so that is why I ask.
I closed issue 7265. Eliot added your fix to Spur/Cog I did likewise for VMM trunk (interpreter VM).
Dave
Thanks!
2015-09-15 4:24 GMT+02:00 David T. Lewis lewis@mail.msen.com:
On Sun, Sep 13, 2015 at 07:17:51PM -0400, David T. Lewis wrote:
On Sun, Sep 13, 2015 at 10:23:42PM +0200, Nicolai Hess wrote:
I am about to close some old mantis reports.
There are two issues related to the vm and easy to solve ( I think).
http://bugs.squeak.org/view.php?id=7265
0007265: Bug in Matrix2x3Plugin okayIntValue: Method okayIntValue: value uses argument to compare with lower bound, m23ResultX for upper bound.
okayIntValue: value ^(value >= -1073741824 asFloat and:[m23ResultX <= 1073741823
asFloat])
should be: okayIntValue: value ^(value >= -1073741824 asFloat and:[value <= 1073741823 asFloat])
I looked at the Matrix2x3Plugin code, and the wrong comparsion is still there.
I am quite sure you are right about this, just from looking at the code. But I do want to check - the method is from ar 1998, so it has been in
all
the VMs for a very long time. How did you find the problem? Is there a test or an example that shows the issue?
After fixing the method as you suggest, it will test for integer values with bit values in the range 11000000000000000000000000000000 through 00111111111111111111111111111111, which presumably maps to a range of acceptable values for use in the Matrix2x3Plugin floating point
operations.
So that looks quite reasonable, but I am puzzled that this check has been wrong since 1998, so that is why I ask.
I closed issue 7265. Eliot added your fix to Spur/Cog I did likewise for VMM trunk (interpreter VM).
Dave
On Sun, Sep 13, 2015 at 10:23:42PM +0200, Nicolai Hess wrote:
http://bugs.squeak.org/view.php?id=7756 0007756: InputSensor>>cursorPoint: uses primitive 91 (primitiveTestDisplayDepth)
Either we remove the code from InputSensor, or we add another new primitive for setting the mouse cursor. (Maybe we don't need this functionality or this is already possible with the hostwindow plugin?)
The primitive number assignments are set in #initializePrimitiveTable in the VM code (VMMaker package). This shows:
(91 primitiveTestDisplayDepth) "Blue Book: primitiveCursorLocPut"
So this tells me that primitive 91 was originally used for a primitive that set the cursor location, but that this primitive was abandoned a long time ago, and eventually someone decide to use 91 for a different purpose (testing display depth).
That means that you are right in thinking that the InputSensor code is obsolete and should be removed or fixed. But I think that InputSensor itself has been replaced by EventSensor, and probably has no function in a modern Squeak image. It is referenced by class Controller (MVC) but the Sensor in an MVC project is an EventSensor, so I suspect that it may now be possible to remove InputSensor entirely.
I have not actually tried this yet, but the test would be to remove InputSensor and all of the references to it, then see if MVC still works.
Dave
vm-dev@lists.squeakfoundation.org
-
David T. Lewis -
Nicolai Hess