Roku Developer Program

[Emerica]

request = CreateObject("roTextureRequest",imageUrl)
 
print request.GetId()
-> 121639868

print str(request.GetId())
-> "1.216399e+08 "

I've been attempting to use the texture manager and the roTextureRequest object has a GetId() method which is returning large values such as those.

I'd like to use the returned id as an array key.
Problem is that I can't cast the int to a proper string, like above, the requests only increment by 1, so the result will give the same key for each request. I cannot use the url as they can duplicate on some regions, so only one region would be drawn.

My best work around so far is to store the first request id that I create and subtract it from any furture request id that is created. Those values cast fine (0,1,2,3....) There is a problem if the id's during a certain session were to overflow/or get set to a lower value than my start id.

Does anyone have any suggestions of casting the id properly or if the GetId() values can/will reset at a certain point during a session.
Or maybe even an alternate workaround to the subtract original method that might not be effected by an index reset. Thought I might be able to convert it to hex or something, but ave not found methods to do that.

Any thoughts would be appreciated
Thanks

[Emerica]

Happens at the rollover on 9,999,999 to 10,000,000

[EnTerr]

Try stri() instead:

BrightScript Debugger> s = stri(121639868): ? s, type(s)
 121639868           String

[Emerica]

Appreciated sir!

[RokuKC]

If you are targeting current firmware versions (i.e. 6.2), you can use StrI(n, 16) to format the integer key as a hex string.

Just an academic detail, but that would give a "more efficient" lookup key representation than the legacy StrI signed/padded decimal formatting.

http://sdkdocs.roku.com/display/sdkdoc/ ... erasString

[EnTerr]

"RokuKC" wrote:
If you are targeting current firmware versions (i.e. 6.2), you can use StrI(n, 16) to format the integer key as a hex string.
Just an academic detail, but that would give a "more efficient" lookup key representation than the legacy StrI signed/padded decimal formatting.

Yeah!
Funny, i thought about that yesterday but so it happened is was on a fw3 console and the radix form was not working and so i thought "how much more effective a hex form would be?" (not much at all, practically speaking). If swinging that way probably should should go all in and use base=36 for "even more compression"*:

BrightScript Debugger> ? stri(121639868, 36)
20f5x8
BrightScript Debugger> ? stri(121639868, 16)
74013bc

I thought about base64 too but trying to shove a long into roByteArray is not a pretty sight.

(*) And at this point i can feel RokuMarkn disapprovingly staring down both of us

PS. This is weird:

BrightScript Debugger> i = 2^31: ? stri(i, 9), stri(i, 10), stri(i, 11)
5478773672             -2147483648     a02220282

[RokuMarkn]

"EnTerr" wrote:

(*) And at this point i can feel RokuMarkn disapprovingly staring down both of us

Actually this is a case where the optimization doesn't bother me at all. If the choice is between using Stri(n,10) vs. Stri(n,36), I say go ahead and use the more efficient one. It doesn't affect the readability or maintainability of the code in the slightest bit, so in this case the optimization is essentially "free".

--Mark

[RokuKC]

"EnTerr" wrote:

PS. This is weird:

BrightScript Debugger> i = 2^31: ? stri(i, 9), stri(i, 10), stri(i, 11)
5478773672             -2147483648     a02220282

Assuming you are commenting on the negative value:

The BrightScript integer type logically represents a signed 32-bit integer.
For bases other than 10, however, the number is formatted by StrI as an unsigned value.
This was a design choice to accommodate common usage and expectations, e.g. for 32-bit hex value formatting.

Perhaps if there is demand for it, in the future API(s) will be provided with more formatting options.

[EnTerr]

"RokuKC" wrote:
The BrightScript integer type logically represents a signed 32-bit integer.
For bases other than 10, however, the number is formatted by StrI as an unsigned value.
This was a design choice to accommodate common usage and expectations, e.g. for 32-bit hex value formatting.

Perhaps if there is demand for it, in the future API(s) will be provided with more formatting options.

Changing stri(int, 10) to output unsigned decimal representation seems like great opportunity for that!
(a) it will bring the behavior for radix=10 in line with all other radixes, right now it's the "odd man out" (due to an extra "if"?).
(b) it will answer the complaints (i seem to recollect multiple such in the forum) there is no way to "stringize" big unsigned int-s
(c) current behavior for radix=10 is undocumented, so is "soft" (jello has not set in the mold) for a change to unsigned/unpadded proper
(d) there is no use case for stri with radix=10 as a signed string (other fn already do that, e.g. 123.toStr() for unpadded)

Would you consider "fixing" stri(int, 10) to be unsigned?

[RokuKC]

"EnTerr" wrote:
Changing stri(int, 10) to output unsigned decimal representation seems like great opportunity for that!
(a) it will bring the behavior for radix=10 in line with all other radixes, right now it's the "odd man out" (due to an extra "if"?).
(b) it will answer the complaints (i seem to recollect multiple such in the forum) there is no way to "stringize" big unsigned int-s
(c) current behavior for radix=10 is undocumented, so is "soft" (jello has not set in the mold) for a change to unsigned/unpadded proper
(d) there is no use case for stri with radix=10 as a signed string (other fn already do that, e.g. 123.toStr() for unpadded)

Would you consider "fixing" stri(int, 10) to be unsigned?

Having StrI(int, 10) format as signed is by design, and I don't anticipate that changing.
But again, I personally think that additional options or APIs should be provided for more formatting control.
E.g. printf-like control over padding, width, alignment, precision; and separator/decimal formatting including locale-specific support.