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.
(*) 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”.
“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?
“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.
“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” . 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” 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.
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
“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).
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.
“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.
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.
. It both requires significant work and is mostly about double type (or up-conversions thereof).