1. My Bits are Flipping (or, "Why Can't I Be Negative?")
Hello all!
I've seen something a little strange while working on Midgard, and I'm hoping
some of the other library wrapping folks out there can explain it to me, and
tell me how to fix it.
I'm currently working on mouse events in Midgard. When the mouse moves past
the left or top of the widget, the mouse position is given as a negative
number, reflecting the fact that the position is based on the widget's
coordinate system. This is to be expected, and is what happens in the shared
library part of the project.
The problem is with the Euphoria function that is being used as a callback.
The prototype for the callback function is:
-- MWidget is basically an atom.
function X(MWidget sender, integer x, integer y)
When either x or y receives a negative number from the shared library, its
picking up on the fact that the signed bit of the number is flagged.
However, it is seeing this not as a negative number, but as a huge positive
number, which of course is causing a Euphoria error because the number is too
big to be an integer.
How can I get this value, coming in from the C++ code side, to be seen by
Euphoria as a negative number? Or am I going to have to check the signed bit
manually?
Any help would be greatly appreciated!
Travis.
--
"Well," Brahma said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent man requires only two thousand five hundred."
-- The Mahabharata.
2. Re: My Bits are Flipping (or, "Why Can't I Be Negative?")
Travis Beaty wrote:
>
> The problem is with the Euphoria function that is being used as a callback.
> The prototype for the callback function is:
>
> -- MWidget is basically an atom.
> function X(MWidget sender, integer x, integer y)
>
<snip>
> How can I get this value, coming in from the C++ code side, to be seen by
> Euphoria as a negative number? Or am I going to have to check the signed bit
> manually?
>
Try:
function X(MWidget sender, atom x, atom y)
Matt Lewis
3. Re: My Bits are Flipping (or, "Why Can't I Be Negative?")
Hello Matt.
I tried that. It no longer causes an error as an atom, but I'm still getting
a huge positive number as opposed to a negative number, which is what I am
expecting.
I also threw some printf()'s in my C++ code, and it shows those values as
being negative.
Travis.
On Friday 27 August 2004 08:21 am, Matt Lewis wrote:
>
>
> posted by: Matt Lewis <matthewwalkerlewis at yahoo.com>
>
> Travis Beaty wrote:
> > The problem is with the Euphoria function that is being used as a
> > callback. The prototype for the callback function is:
> >
> > -- MWidget is basically an atom.
> > function X(MWidget sender, integer x, integer y)
>
> <snip>
>
> > How can I get this value, coming in from the C++ code side, to be seen by
> > Euphoria as a negative number? Or am I going to have to check the signed
> > bit manually?
>
> Try:
> }}}
<eucode>
> function X(MWidget sender, atom x, atom y)
> </eucode>
{{{
>
> Matt Lewis
--
Birds and bees have as much to do with the facts of life as black
nightgowns do with keeping warm.
-- Hester Mundis, "Powermom"
4. Re: My Bits are Flipping (or, "Why Can't I Be Negative?")
Travis Beaty wrote:
>
> Hello Matt.
>
> I tried that. It no longer causes an error as an atom, but I'm still getting
> a huge positive number as opposed to a negative number, which is what I am
> expecting.
>
> I also threw some printf()'s in my C++ code, and it shows those values as
> being negative.
>
Oh, yeah, I remember this now. Euphoria call_backs are always unsigned.
Here's what I've done where I've had this problem. I call the below
function on any parameters that need to be signed:
constant sptr = allocate(4)
function signed( atom unsigned )
poke4(sptr,unsigned)
return peek4s(sptr)
end function
Matt Lewis
5. Re: My Bits are Flipping (or, "Why Can't I Be Negative?")
Travis Beaty wrote:
>
> Hello Matt.
>
> I tried that. It no longer causes an error as an atom, but I'm still getting
> a huge positive number as opposed to a negative number, which is what I am
> expecting.
>
> I also threw some printf()'s in my C++ code, and it shows those values as
> being negative.
>
>
Callback values are always treated as unsigned. To get the negative number, do
this:
constant s4 = allocate(4) -- permanent allocation for speed
function X(MWidget sender, atom x, atom y)
poke4(s4,x)
x = peek4s(s4)
poke4(s4,y)
y = peek4s(s4)
-- x & y are now signed values
.. more code here ..
end function
6. Re: My Bits are Flipping (or, "Why Can't I Be Negative?")
- Posted by Travis Beaty <eucoder at travisbeaty.us>
Aug 27, 2004
-
Last edited Aug 28, 2004
Hello.
Arg. That's not going to be good at all. If this is the case, the user would
have to
1. Guess whether or not the value is negative.
2. Implement the poke/seek scenario every time they need the negative value.
Unfortunately, the C/Euphoria boundary in Midgard in quite close to the end
user, although I had figured that it was far enough away. The only way do
handle this would be to have a hard-coded handler within the library, and
then have a handler that is called from within the handler. I'm worried
about speghetti code with that strategy.
Derek, is this how win32lib deals with it?
Travis.
On Friday 27 August 2004 10:44 am, Andy Serpa wrote:
> Callback values are always treated as unsigned. To get the negative
> number, do this:
>
> constant s4 = allocate(4) -- permanent allocation for speed
> function X(MWidget sender, atom x, atom y)
>
> poke4(s4,x)
> x = peek4s(s4)
>
> poke4(s4,y)
> y = peek4s(s4)
>
> -- x & y are now signed values
>
> .. more code here ..
>
> end function
--
Windows - what do you want to crash today?
7. Re: My Bits are Flipping (or, "Why Can't I Be Negative?")
Travis Beaty wrote:
>
> Hello.
>
> Arg. That's not going to be good at all. If this is the case, the user would
>
> have to
>
> 1. Guess whether or not the value is negative.
> 2. Implement the poke/seek scenario every time they need the negative value.
>
It is not the difference between negative & positive per se -- it is the
difference between signed & unsigned values. The library either returns signed
or unsigned values. If it returns signed values, then you convert them. There
is no danger to it, and no guessing, unless you don't know what the library is
supposed to be giving you.
8. Re: My Bits are Flipping (or, "Why Can't I Be Negative?")
Hello Mr. Serpa ...
Well, actually, that's the problem. The value will be positive if the mouse
is *in* the widget, but will become negative if it crosses past the left or
top edge. This would happen, for instance, if the user has their left mouse
button pressed down and slides the mouse to the left. Therefore, we have a
situation where it's *probably* positive, but there is fairly decent chance
that it won't be.
The only other way I can think of doing it is giving the mouse's position in
turns of the global coordinate system, and allowing the user to convert to
the widget's coordinate system as necessary. The process of converting would
include peeking values, so that would fix the situation. But giving the
mouse coordinates in the global coordinate system when receiving the signal
from a widget would be a bit of a hack, and would not be expected behavior.
Or, I could throttle it from the C++ end, and make sure a negative value is
never passed: but if someone is expecting a negative value, and it dead ends
at zero, then again, unexpected behavior.
Mr. Craig, any possibility of putting the ability to detect signed values from
external libraries on the last-minute 2.5 wishlist? Or the first minute 2.6
one?
Thanks everyone for your help!!
Travis.
On Friday 27 August 2004 07:04 pm, Andy Serpa wrote:
> It is not the difference between negative & positive per se -- it is the
> difference between signed & unsigned values. The library either returns
> signed or unsigned values. If it returns signed values, then you convert
> them. There is no danger to it, and no guessing, unless you don't know
> what the library is supposed to be giving you.
--
Besides the device, the box should contain:
* Eight little rectangular snippets of paper that say "WARNING"
* A plastic packet containing four 5/17 inch pilfer grommets and two
club-ended 6/93 inch boxcar prawns.
YOU WILL NEED TO SUPPLY: a matrix wrench and 60,000 feet of tram cable.
IF ANYTHING IS DAMAGED OR MISSING: You IMMEDIATELY should turn to your spouse
and say: "Margaret, you know why this country can't make a car that can get
all the way through the drive-through at Burger King without a major
transmission overhaul? Because nobody cares, that's why."
WARNING: This is assuming your spouse's name is Margaret.
-- Dave Barry, "Read This First!"
9. Re: My Bits are Flipping (or, "Why Can't I Be Negative?")
Travis Beaty wrote:
> Well, actually, that's the problem. The value will be positive if the mouse
> is *in* the widget, but will become negative if it crosses past the left or
> top edge.
And what is the problem? Andy wrote about signed values. "signed" does
not mean, that the concerning values only can be negative. "signed"
values can be negative or positive.
<snip>
> Mr. Craig, any possibility of putting the ability to detect signed values from
> external libraries on the last-minute 2.5 wishlist? Or the first minute 2.6
> one?
There is no possibility to "detect" signed values from external
libraries at all. Only some bits are passed from external libraries to
Euphoria. Human beings (or software written by them) have to _decide_,
what a certain "collection of bits" should _mean_. By their "nature",
those values are neither signed nor unsigned.
Obviously in the past Rob had decided to _treat_ those values as
unsigned. When future versions of Euphoria would treat those values as
signed, this would not be backward compatible, so this is not
recommendable.
Converting unsigned values to signed values, or vice versa, using
functions like those that were posted here, is quite normal in
programming. Besides, the suggested functions are small and fast.
Since after my experience there are often problems in understanding
this point, I'll explain it more in detail. Because it's simpler, just
let's look at 8 bit rather than 32 bit.
One byte (= 8 bit) can hold 2^8 = 256 differnt values, that's a
technical fact. If we _interpret_ the bits in a byte in a way, that the
most significant bit acts as the "sign" bit, then a byte can hold any
value in the closed interval [-128, 127].
The reason why negative values for a byte might look somewhat unfamiliar
simply is, that the most widespread _convention_ concerning bytes is,
not to interpret the most significant bit as the "sign" bit. So a byte
normally is treated as an unsigned value in the closed interval [0, 255].
> Thanks everyone for your help!!
>
> Travis.
>
>
> On Friday 27 August 2004 07:04 pm, Andy Serpa wrote:
>> It is not the difference between negative & positive per se -- it is the
>> difference between signed & unsigned values. The library either returns
>> signed or unsigned values. If it returns signed values, then you convert
>> them. There is no danger to it, and no guessing, unless you don't know
>> what the library is supposed to be giving you.
[snipped garbage]
Hope this helps.
Regards,
Juergen
10. Re: My Bits are Flipping (or, "Why Can't I Be Negative?")
Juergen Luethje wrote:
>
> Travis Beaty wrote:
>
> > Well, actually, that's the problem. The value will be positive if the mouse
> > is *in* the widget, but will become negative if it crosses past the left or
> > top edge.
>
> And what is the problem? Andy wrote about signed values. "signed" does
> not mean, that the concerning values only can be negative. "signed"
> values can be negative or positive.
>
What he said. The proposed conversion will not affect your positive values
because the representation for unsigned positive values and signed positive
values is the same (assuming 32-bit values) as long as the value is in the range
[0,2147483647].
The ranges will be mapped like this:
unsigned [0,2147483647] => signed [0,2147483647] (sign is +)
unsigned [2147483648,4294967295] => signed [-2147483648,-1] (sign is -)
Please try it, I believe it will do exactly what you want, and the overhead is
very little (and unavoidable anyway).
Press Enter...
