Forum Discussion

renojim's avatar
renojim
Community Streaming Expert
9 years ago

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? I have some monotonically increasing values that I'm worried will eventually overflow 32-bits. Currently I store them in the registry using toStr() and then use toInt() to convert the string back to an integer. There's no toLongInt() that I've found.

When I ran across this issue with doubles, I used Eval. The same thing could be done for LongInts:
BrightScript Debugger> lintstr = "8589934592&"
BrightScript Debugger> Eval("x& = " + lintstr)
BrightScript Debugger> ?type(x&), x&
LongInteger      8589934592

Now I've been told that Eval has been deprecated and also leaks memory. So... am I missing something simple? Is there really a problem if I use Eval a half a dozen times or so at the beginning of my code and then never again until it exits?

-JT
Roku Developer Program

15 Replies

  • RokuKC's avatar
    RokuKC
    Roku Employee
    9 years ago
    You can use .ToStr() on LongIntegers and Doubles to get a fixed format decimal representation, but you are correct that there aren't currently any global Str() or Val() functions to work with them.

    You can however use FormatJson and ParseJson to get the functionality.
    (Note that ParseJson will only emit LongInteger for integer values that don't fit in Integer, and will only emit Double for floating point values that don't fit in Float).


    BrightScript Debugger> n&=5123456789

    BrightScript Debugger> s=n&.ToStr()
    BrightScript Debugger> var
    n&               LongInteger refcnt=1 val:5123456789 (&h13161BF15)
    s                roString (2.1 was String) refcnt=1 val:"5123456789"

    BrightScript Debugger> ss=FormatJson(n&)
    BrightScript Debugger> var
    n&               LongInteger refcnt=1 val:5123456789 (&h13161BF15)
    s                roString (2.1 was String) refcnt=1 val:"5123456789"
    ss               roString (2.1 was String) refcnt=1 val:"5123456789"

    BrightScript Debugger> nn&=ParseJson(s)
    BrightScript Debugger> var
    n&               LongInteger refcnt=1 val:5123456789 (&h13161BF15)
    s                roString (2.1 was String) refcnt=1 val:"5123456789"
    ss               roString (2.1 was String) refcnt=1 val:"5123456789"
    nn&              LongInteger refcnt=1 val:5123456789 (&h13161BF15)
  • renojim's avatar
    renojim
    Community Streaming Expert
    9 years ago
    Thanks! That should do nicely and probably a lot better than using Eval. I've always thought it's an oversight not to have ifStringOps akin to toInt() and toFloat() for Doubles and now LongIntegers, so I hope they're somewhere on a ToDo list.

    -JT
  • RokuKC's avatar
    RokuKC
    Roku Employee
    9 years ago
    "renojim" wrote:
    I've always thought it's an oversight not to have ifStringOps akin to toInt() and toFloat() for Doubles and now LongIntegers, so I hope they're somewhere on a ToDo list.
    -JT


    Bug report/enhancement request noted.
  • EnTerr's avatar
    EnTerr
    Roku Guru
    9 years ago
    The Str -> LongLong direction was the missing link.
    Using parseJson() as workaround is (in)genius!
  • renojim's avatar
    renojim
    Community Streaming Expert
    9 years ago
    This is mildly concerning:
    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
  • RokuKC's avatar
    RokuKC
    Roku Employee
    9 years ago
    "renojim" wrote:
    This is mildly concerning:
    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


    > Does it make sense to report a bug in a FW version that's less than the latest?

    In general it will only be fruitful to report bugs that occur in the current firmware, but if you are seeking advice / workarounds for older firmware that's valid too. 🙂
    There were definitely fixes in 7.2 with respect to numeric parsing etc.

    Just to confirm, your use case(s) works correctly on 7.2, right?

    > Keep in mind that there's still a good number of devices unable to update to v7.2.

    I can't speak to details, but my impression is that the Roku-branded 7.2 rollout should be nearing completion.
  • renojim's avatar
    renojim
    Community Streaming Expert
    9 years ago
    "RokuKC" wrote:
    There were definitely fixes in 7.2 with respect to numeric parsing etc.

    Just to confirm, your use case(s) works correctly on 7.2, right?

    Correct.

    "RokuKC" wrote:
    I can't speak to details, but my impression is that the Roku-branded 7.2 rollout should be nearing completion.

    I'm stilling seeing users on 7.0, so I'm wondering if they're going to jump to 7.2?
  • RokuKC's avatar
    RokuKC
    Roku Employee
    9 years ago
    "renojim" wrote:

    I'm still seeing users on 7.0, so I'm wondering if they're going to jump to 7.2?


    > Roku Stick running FW v7.1.0 build 4096-24

    If you are seeing a non-trivial #/percentage of active/ongoing reports of users with Roku Stick (platform 24) with firmware version < 7.2 that seems like a problem.

    If you have more other data with model #s / platform IDs, and country code if non-US, of your client devices reporting < 7.2 that you can share, I can forward it for investigation.
  • renojim's avatar
    renojim
    Community Streaming Expert
    9 years ago
    I can't say I'm seeing many Sticks. Most of what I'm seeing are Model 5000X (TVs). In the last week I've seen about 6% of all devices with FW < 7.2 and of those 85% are TVs. In addition, 17% of devices with FW < 7.2 have v7.0.x.

    -JT
  • EnTerr's avatar
    EnTerr
    Roku Guru
    9 years ago
    renojim -
    pray tell, why are you using LongLong?

    I suspect you are "making lemonade" but specifically what kind of thing is exceeding 32 bits? There might be other ways to juice it