Roku Developer Program

[EnTerr]

"RokuKC" wrote:
Having StrI(int, 10) format as signed is by design, and I don't anticipate that changing.

I am guessing you said "by design" to mean that the behavior comes from implementation where stri(intVal) has implied radix=10 from a general definition like

function stri(intVal as Integer, radix = 10 as Integer) as String

Bur RokuKC, why not improve on that design, if it bene-fits? Like so, change the default to -10:

function stri(intVal as Integer, radix = -10 as Integer) as String

And thus, calling stri with 2nd argument positive radix will give us unsigned representation and 10 will act as every other number in the 2..36 interval. Where calling w/o 2nd argument will give the signed decimal representation.

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.

That... that's "double trouble" 8-) . It both requires significant work and is mostly about double type (or up-conversions thereof).
Where unsigned int string representation is needed often in daily programming, so let's not leave it to a universal sprintf

[NewManLiving]

You can also use request.GetId().ToStr()

[EnTerr]

"NewManLiving" wrote:
You can also use request.GetId().ToStr()

`request.GetId().ToStr()` is virtually equivalent to `stri(request.GetId())` (the latter being a bit faster) in that it returns signed representation of the ints.

To refresh, two different things were discussed in the thread - first was about generating reliable/non-colliding AA keys from Integers - and that is covered by stri(), regardless if signed-int or unsigned-other-than-10-radix.

The second one was about externalizing unsigned Integer to a decimal string (say you have timestamp in milliseconds to send to a server) - for that there is no good/efficient solution in BrS.

[NewManLiving]

I always appreciate your posts EnTerr and also the many examples of your brilliant brain that is a benefit to all of us. I am waiting patiently for you to write a JIT Brightscript bytecode compiler. And while I completely agree with all you have recapped for us, the original question can be adequately addressed with a simple roInteger function

[EnTerr]

"NewManLiving" wrote:
I always appreciate your posts EnTerr and also the many examples of your brilliant brain that is a benefit to all of us. I am waiting patiently for you to write a JIT Brightscript bytecode compiler. ...

Ha-haa, that's entertaining thought. I probably would have done that - write a dialect of Python or Lua or JavaScript that compiled to bytecode and then ran as everything else B/S on Roku - not likely to happen though, since if anything, RokuCo are heading towards hiding the VM and not exposing it (i don't know if you remember once upon a time there was a `da` console command to see the p-code).

[NewManLiving]

No I did not know about that command. And yes it is an entertaining thought

[EnTerr]

Mind you, B/S is not a bad language. Quirky - yes, maybe like Perl but nothing as bad as PHP. The real problems lay with the libraries/components - behavior and documentation. Getting another language or VM won't help with that.

[EnTerr]

"RokuKC" wrote:
Having StrI(int, 10) format as signed is by design, and I don't anticipate that changing.

RokuKC -
can you however put a formal request to make Stri() able to output unsigned decimals?
Or is it that me failing to convince you personally, such request is dead in the water?

"EnTerr" wrote:
I am guessing you said "by design" to mean that the behavior comes from implementation where stri(intVal) has implied radix=10 from a general definition like

function stri(intVal as Integer, radix = 10 as Integer) as String

Bur RokuKC, why not improve on that design, if it bene-fits? Like so, change the default to -10:

function stri(intVal as Integer, radix = -10 as Integer) as String

And thus, calling stri with 2nd argument positive radix will give us unsigned representation and 10 will act as every other number in the 2..36 interval. Where calling w/o 2nd argument will give the signed decimal representation.

[RokuKC]

"EnTerr" wrote:

"RokuKC" wrote:
Having StrI(int, 10) format as signed is by design, and I don't anticipate that changing.

RokuKC -
can you however put a formal request to make Stri() able to output unsigned decimals?
Or is it that me failing to convince you personally, such request is dead in the water?

I can see a case for extending StrI to accept -10 as a radix value, as a backdoor way to get an unsigned print format, but it seems like a very low priority request to me, that I don't personally feel like arguing for it.
You're free to continue trying to convince me or others, but as I said, I don't anticipate that we would change the currently defined behavior.

Slightly as an aside, you could use the long integer support (firmware 7.0 or later) as a helper, if you wanted.

> i = -1: print (i and &hFFFFFFFF&).ToStr()
4294967295

[adamkaz]

I'd be wary about relying on functions introduced in version 7.0. Users with RokuTVs are still on 6.2 - Roku has not responded to my post about when they will be migrated to 7.0.