Bug with IF statement??

More info

Here is the console debug output:

stepProgress < 1 - Value:3.000000
Step Progress: 2.588000
stepProgress < 1 - Value:3.000000
Step Progress: 2.628000
stepProgress < 1 - Value:3.000000
Step Progress: 2.668000
stepProgress < 1 - Value:3.000000
Step Progress: 2.708000
stepProgress < 1 - Value:3.000000
Step Progress: 2.748200

What happens if you have:

if (stepProgress >1.0) {

What happens if you have:

if (stepProgress >1.0) {

Thanks for your answer. Still going to the "else" code.

More info:
The code is in the "draw" function of a Drawable class.

Also tried with:

if (1.0 < stepProgress)

After restarting simulator & eclipse, same error.

I haven't done anything with widgets, but was just playing around a bit.

I took the ActivityTracker sample widget and added in the following code.

// Handle the update event
function onUpdate(dc) {
dc.setColor(Gfx.COLOR_BLACK, Gfx.COLOR_BLACK);
dc.clear();
// Insert Code from Here...
var stepProgress = 0;
Sys.println("stepProgress: " + stepProgress);
if (3.0>1.0) {
Sys.println("Doing Something");
}
// ...to here
var info = Act.getInfo();

This produced the following output.

...
stepProgress: 0
Doing Something
...

Then if I just change the var stepProgress line to the following

// Insert Code from Here...
var stepProgress = (Act.getInfo().steps*1.0)/(Act.getInfo().stepGoal*1.0);
Sys.println("stepProgress: " + stepProgress);
if (3.0>1.0) {
Sys.println("Doing Something");
}
// ...to here

This produced the following output. (It's not going inside the If statement like I would expect)

...
stepProgress: 0.000000
...

It seems to not like floats with >, <, >=, or <= after that var stepProgress line of code.

It works correctly if I made the following change.

// Insert Code from Here...
var stepProgress = (Act.getInfo().steps*1.0)/(Act.getInfo().stepGoal*1.0);
Sys.println("stepProgress: " + stepProgress);
if ((3.0).toNumber()>(1.0).toNumber()) {
Sys.println("Doing Something");
}
// ...to here

This makes the output below like I'd expect.

...
stepProgress: 0.000000
Doing Something
...

Incidentally, the following code seems to work like I'd expect.

// Insert Code from Here...
var info = Act.getInfo();
var stepProgress = (info.steps.toFloat() / info.stepGoal.toFloat());
Sys.println("stepProgress: " + stepProgress);
if (3.0>1.0) {
Sys.println("Doing Something");
}
// ...to here


I was just playing around with this. It's not clear to me why it's acting like this. It seems like something is getting stepped on in the background when 2 getInfo() calls are made in the same line. Sorry if I've just added confusion, but I thought maybe some of this would be helpful. It does smell like there's a bug somewhere here.

Good catch dude. This is interesting. If you use this test code, the problem still occurs...

var stepProgress = ActivityMonitor.getInfo().steps;
//Sys.println(stepProgress);

var stepGoal = ActivityMonitor.getInfo().stepGoal;
//Sys.println(stepGoal);

stepProgress = (stepProgress * 1.0) / stepGoal; // this line is special

if (stepProgress > 1.0) {


and disassemble it (by compiling with -g), you see this (emphasis mine)...

# stepProgress=(stepProgress*1.0)/stepGoal;
source_TestApp_mc_22_8:
lgetv 2
fpush 1.0
mulv
lgetv 3
divv
lputv 2


If you change the floating-point constant to double precision...

stepProgress = (stepProgress * 1.0d) / stepGoal; // this line is special


The only change in the assembly is this...

lgetv 2
dpush 1.0
mulv


This code works.

I'm not sure what is happening, but it looks like the correct opcodes are being generated, but the instructions themselves (probably the gt instruction, or maybe bf) is just misbehaving (i.e., it seems that this is a vm bug and not a compiler bug).

source_TestApp_mc_24_8_if:
lgetv 2
fpush 1.0
gt
bf @source_TestApp_mc_24_8_else
source_TestApp_mc_24_32_start:


Travis

This is a weird one! Looking at the code I sure didn't see anything.

Another simple work around would be to use this for the if statement (no floats or doubles involved):

if(Act.getInfo().steps>Act.getInfo().stepGoal) {

Hey everyone. Thanks for the heads up. I was also able to reproduce this. I've started a ticket for this to be looked at.

Thanks,
Coleman

and disassemble it (by compiling with -g), you see this (emphasis mine)...

Cool, didn't know that flag.