Roku Developer Program

[amnon]

I wanted to build a simple logMessage function which looks like this:

'Simple logging with timestamp
sub logMessage(message as String)
	'Get local time
	date = CreateObject("roDateTime")
	date.toLocalTime()
	print date.asDateString("short-date") date.getHours() ":" date.getMinutes().toStr().trim() ":" date.getSeconds().toStr().trim() "." date.getMilliseconds().toStr().trim() " " message
end sub

I went through all the print statements I had and the application started breaking, because I had to turn all the special print string concatenations into "+", for example:

print "Hello" message

needs to be changed to

logMessage("Hello" + message)

Of course my troubles didn't end there, as anything which is not a string makes string concatenation with "+" fail so I had to add a bunch of

toStr()

calls for integers. But then I found that I had some boolean variables I wanted to output, and there isn't a

toStr()

for that so I had to add if statements.

My plan is to revert all of that and just convert my logMessage sub to a getTimeStamp sub which I will add to the print statements, but I really don't want to do that because I intended to extend the logMessage sub into a full blown logger - have log levels configured centrally and maybe even save to a file.

Is there a better way? Can someone from Roku comment on any plans to make string concatenations using "+" as capable as the print statement?

Thanks and Happy New Year,
Amnon

[destruk]

If you are logging stuff, it is a lot easier to simply send a message to your server and have it do the logging on the server side. That way you don't need to deal with individual timestamps from each roku device in different regions, and use your timestamp on the server for a more legible report. Typically, to do this you would only need to "AddParam" the action, a filename or video title, and an identifier for the specific roku and let the server do the rest.

If you insist on doing local end user based logging, remember you have 16KB to store in the registry for your dev key - to conserve that you'll need to wipe the log or entry and rewrite/update it before it fills up, and track your byte arrays to ensure it isn't overflowing or failing on writes. To do that you might want to consider simply saving the unix timestamp and converting it back to readable text on display, or save the date and sequence in the queue while ignoring the hours, minutes, seconds, and milliseconds and discard the time zone to make the write value take up less space.

With a local client side logging, you can't save it to a 'file' as none of the persistent filesystems are writable - you just have the roku registry, which is cleared on a factory reset.

[RokuMarkn]

The use of + rather than space to concatenate strings is a minor syntactical point, which shouldn't cause any issue except in the case you describe, where you are converting a print into a call. This probably doesn't warrant a change to the language. The requirement to explicitly convert to a string is handled different in different languages. For example, in Java an object is automatically converted to a string when necessary, while in Javascript and C++ an explicit conversion is required, like in Brightscript. I'm not aware of any plans to implement automatic string conversion in Brightscript. It might be reasonable to add an ifBoolean.ToStr() method, although this can easily be implemented as a simple one-line Brightscript function.

function BooleanToStr(b as Boolean) as String
    if b then return "true" else return "false"
end function

--Mark

[EnTerr]

"RokuMarkn" wrote:
The requirement to explicitly convert to a string is handled different in different languages. For example, in Java an object is automatically converted to a string when necessary, while in Javascript and C++ an explicit conversion is required, like in Brightscript.

Javascript does automatic type coercions, which is evil, see https://www.destroyallsoftware.com/talks/wat past the 1min mark (esp. the "nanananana watman" finale).
It leads to deeply mystifying bugs and should not be done, shows experience of language makers (alas too late for J/S).

OTOH, having `sprintf` equivalent might be good.