Working with LongInteger
I'm just taking a look at roLongInteger. As far as I can tell, it suffers from the same shortcoming as roDouble. Namely, there's no way to go back and forth to/from strings. Am I missing something?...
Forum Discussion
This is mildly concerning:
The specifics of the bug aren't important. Suffice it to say that some values > &h80000000 work and some don't.
Now why it's mildly concerning:
That was taken from a Roku Stick running FW v7.1.0 build 4096-24. The same test on a Roku 3 with FW v7.2.0 build 4091-04 works just fine.
Does it make sense to report a bug in a FW version that's less than the latest? Keep in mind that there's still a good number of devices unable to update to v7.2.
For my purposes, I can either set the minimum firmware version to 7.2 or just leave it at 7.0 (when LongInteger appeared) since my counters aren't likely to need more than 32 bits for quite some time and, even if one does overflow, it's completely harmless. I'll probably go with the latter.
-JT
BrightScript Debugger> x& = &h80000001&
BrightScript Debugger> y& = ParseJson(x&.toStr())
BrightScript Debugger> var
x& LongInteger refcnt=1 val:2147483649 (&h80000001)
y& LongInteger refcnt=1 val:2147483648 (&h80000000)
The specifics of the bug aren't important. Suffice it to say that some values > &h80000000 work and some don't.
Now why it's mildly concerning:
That was taken from a Roku Stick running FW v7.1.0 build 4096-24. The same test on a Roku 3 with FW v7.2.0 build 4091-04 works just fine.
Does it make sense to report a bug in a FW version that's less than the latest? Keep in mind that there's still a good number of devices unable to update to v7.2.
For my purposes, I can either set the minimum firmware version to 7.2 or just leave it at 7.0 (when LongInteger appeared) since my counters aren't likely to need more than 32 bits for quite some time and, even if one does overflow, it's completely harmless. I'll probably go with the latter.
-JT
