Smalltalk › Squeak › Squeak - Dev

two small bugs (vm related)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Nicolai Hess

two small bugs (vm related)

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

David T. Lewis

Mantis 0007265: Bug in Matrix2x3Plugin okayIntValue: (was: two small bugs (vm related))

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

David T. Lewis

Mantis 0007756: InputSensor>>cursorPoint: uses primitive 91 (primitiveTestDisplayDepth) (was: two small bugs (vm related))

In reply to this post by Nicolai Hess

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

David T. Lewis

Re: [Vm-dev] Mantis 0007265: Bug in Matrix2x3Plugin okayIntValue: (was: two small bugs (vm related))

In reply to this post by David T. Lewis

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

Nicolai Hess

Re: [Vm-dev] Mantis 0007265: Bug in Matrix2x3Plugin okayIntValue: (was: two small bugs (vm related))

Thanks!

2015-09-15 4:24 GMT+02:00 David T. Lewis <[hidden email]>:

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