Roku Developer Program

[Rek]

"belltown" wrote:
Does your channel continue to work when you unplug your ethernet cable if you remove the Print statements?

Does your channel continue to work when you unplug your ethernet cable if you have not previously opened port 8085 to view the console log?

Once you open port 8085, e.g. using Telnet, to examine your log activity, the Roku appears to open a port for transmitting log messages to your Telnet client. If the communication link between the Roku and the Telnet client terminates, it seems that after a while (perhaps when the internal console buffer fills), the channel hangs. When the connection to the Telnet client restarts, the channel resumes, all the logs that were being held in the console buffer are sent to the Telnet client, followed by any new log entries. The log timestamps will show the delay while the channel was hung.

I've seen this behavior a lot when debugging a channel from my laptop. When I put the laptop to sleep (thus severing the network connection between the Roku and the Telnet client), the channel continues to run for a little while then hangs. After I resume my laptop the console log spews forth a bunch of stored log messages then the channel continues. I don't get this behavior if I exit from Telnet before putting the laptop to sleep.

I just read RokuMarkn's comment. I think he's saying the same thing.

Ah, okay. I've confirmed that this is the same behaviour I'm seeing. So as long as the logs are stripped from production, and the user isn't connected through telnet it'll stay responsive. Cheers!

[belltown]

"Rek" wrote:
Ah, okay. I've confirmed that this is the same behaviour I'm seeing. So as long as the logs are stripped from production, and the user isn't connected through telnet it'll stay responsive. Cheers!

Someone correct me if I'm wrong, but ... The Print statements only do anything in a side-loaded development channel. Once you're done with testing and have uploaded the channel to the Channel Store (even if as a Private Channel), then the Print statements aren't actually logging anything anywhere, so there's no real need to strip them out in a production version.

[Rek]

"belltown" wrote:

"Rek" wrote:
Ah, okay. I've confirmed that this is the same behaviour I'm seeing. So as long as the logs are stripped from production, and the user isn't connected through telnet it'll stay responsive. Cheers!

Someone correct me if I'm wrong, but ... The Print statements only do anything in a side-loaded development channel. Once you're done with testing and have uploaded the channel to the Channel Store (even if as a Private Channel), then the Print statements aren't actually logging anything anywhere, so there's no real need to strip them out in a production version.

We strip them because we have a lot of logging, and it often has work associated with it:

' Several function calls here. getDebugString() builds a string with an int, so it's not very quick.
' Plus there's an extra intToStr and string concat in the message itself.
' By stripping this line entirely, we save a lot of execution, even if the final `print` wouldn't 
' have done anything anyways.
log_e(m.getDebugString(), "The value is: "+extValueToStr(x))

[Komag]

I have noticed that heavy printing really slows down some operations, sometimes a LOT, but I don't know if that translates to a completed channel (private or public) - I always assumed it would.

[Romans_I_XVI]

Same here komag. I think "Roku probably ignores print in a .BRS", but just for safekeeping I comment out all my print statements anyway before I publish.

Better safe than slow.

[TheEndless]

"Romans_I_XVI" wrote:
Same here komag. I think "Roku probably ignores print in a .BRS", but just for safekeeping I comment out all my print statements anyway before I publish.

Better safe than slow.

Actually, I don't think this is the case. I'm 99% sure the published version of the channel is identical to the side-loaded version, and I've actually had crashes in published channels that were the result of invalid objects in a "print" statement. You probably should, as a best practice, always reduce the debug output before publishing a channel.

[Komag]

In another mod I did, I used to have ALL my print commands actually call another print function:
Instead of

PRINT("Printing some test feedback text")

I would have something like

doPrint("Printing some test feedback text", sy)

and have the following:

FUNCTION doPrint(text, sy) ' sy stands for "system associative array" with important keys/values
IF sy.printOn THEN PRINT(text)
END FUNCTION

Then just before release you can simply set sy.printOn to FALSE

[renojim]

I've never removed prints from any of my channels. No adverse effects. Trying to print an invalid object will cause a crash, but I've never seen any other problem. A slew of prints may have an impact on speed in a published channel, but I haven't done any measurements and I've never had a need for that many prints.

-JT

[TheEndless]

"renojim" wrote:
I've never removed prints from any of my channels. No adverse effects. Trying to print an invalid object will cause a crash, but I've never seen any other problem. A slew of prints may have an impact on speed in a published channel, but I haven't done any measurements and I've never had a need for that many prints.

-JT

It tends to have a more significant impact when using the 2D API when higher framerate is important.

[EnTerr]

"belltown" wrote:
Someone correct me if I'm wrong, but ... The Print statements only do anything in a side-loaded development channel. Once you're done with testing and have uploaded the channel to the Channel Store (even if as a Private Channel), then the Print statements aren't actually logging anything anywhere, so there's no real need to strip them out in a production version.

I suspect prints in non-side-loaded app get redirected to log file, which gets uploaded to Roku heavens asynchronously. Dog forbid that being done synchronously, it would cause freezes like the described on buffer full and network down. That latter theory should be easy to check with network sniffer.