Acknowledged

type casting and Error Name: Invalid Value

In resent SDKs some bugs were fixed

- Fix type casting with certain l-values

- Fix a bug where the if / else if block could clear member typing in the subsequent else / else if blocks

-...

but I can still see errors in ERA probably the same problems (not on my watch/sim, not for all users it ) - with arrays son right size

example 1

cons IC_NO_DATA = 86,//V

sepecial_icon =3;

....

var icon = IC_NO_DATA,

font = globalFont; // loaded on start

...

if(...)

{

  // tableOFdata is an array with mixed type elements - string, num etc

  // tableOFdata[sepecial_icon] keeps integer < 255

  icon = tableOFdata[sepecial_icon];

  font = fontIcon;// // fontIcon is loaded also on start

}

..

dc.drawText(IconX, IconY, font, icon.toChar(), 5); //Error Name: Invalid Value

example 2

var t1 = 12, t2 = "abc";

...

//reusing of t1/t2

t1 = [1224, 345];

if(...)

{

  t2 = t1[0]; //Error Name: Invalid Value

}

  • I think so... Because era log is bad (I will report soon new bug) I think something wrong is with prg or vm on some devices (usually apac).

  • I have code and build it twice with -l0 and -l3 (without any error). Will both prg be the same or different?

    Based on my understanding (and everything I said), I would expect the PRGs to be the same. If they're different, then my understanding is either wrong or incomplete.

    I tried the following experiment:

    - created new Device App from template (using "Monkey C: New Project")

    - without modifying the project, I built with -l 0 and made a copy of the PRG

    - built with -l 3

    - compared the two PRGs and they're binary identical

    I realize that doesn't prove anything, because hypothetically there could be a case where there's *some* program which is compiled differently for -l 0 and -l 3.

    But according the Garmin's documentation, Monkey Types performs compile-time checking only, which is why I believe there would not be any associated code changes due to type checking (whether it's a bug/bugfix in the type checker or it's change in the type check level).

    That's just my understanding and of course I could be wrong.

  • Fundamental question...

    I have code and build it twice with -l0 and -l3 (without any error). Will both prg be the same or different?

  • As I mentioned in another comment, the concept of a lexical type (for compile-time type checking) and the concept of a run-time type (for the existing run-time type system which knows nothing of Monkey Types) are two different things. They're related, but they're not the same.

    My understanding is that Monkey Types basically checks your types by their name in the source code, whereas the run-time type system uses a byte or two in each object to identify the run-time type.

  • type casting and Error Name: Invalid Value

    I haven't said bug is in type checker.

    But type casting is literally a feature that only affects the type checker and not the runtime. There is no runtime type casting in Monkey C. That's what I've been trying to say the whole time

    From sdk readme news

    - Fix a bug where the if / else if block could clear member typing in the subsequent else / else if blocks

    It means type of member/var is counted (rather in runtime as type checker doesn't change anything). 

    What you may be missing is that bug is referring to the type checker, not the runtime. They're talking about the "if splitting" feature in Monkey Types:

    [https://developer.garmin.com/connect-iq/monkey-c/monkey-types/#if-splitting]

    As far as I know, there's no way to "clear" an object's type at runtime. (Of course you can "convert an object's type" at runtime by using a function like toString() or toNumber(), but that's really just returning a new object, so it's not what the bug is referring to.)

    I think invalid value error means flag of type is

    - out of range allowed valves - but who put bad flag? (maybe if/else from bug above)

    - unknown - vm can't find a good type for value so put unknown

    Yeah but again, the if/else bug refers to the type checker. The type checker is not going to change the value of a variable and it's not going to change the runtime type of a variable because it can't.