In this update
Not much happened this month in terms of released features. However, behind the scenes, Bronley and Chris were hard at work on a massive overhaul of the debugger to improve testability and also to prepare for Roku’s spring 2023 OS release. You can read a little more about it here. We’ll go into more detail once the pull request is finally merged.
If you weren’t already aware, the debug protocol is a new binary socket-based debugger that Roku introduced in Roku OS 9.2. The debug protocol is much more stable and consistent than our regex-powered telnet debugger because instead of scraping text, we’re able to communicate with the Roku device directly using established data structures. You can enable the debug protocol by setting
"enableDebugProtocol": true" in your
launch.json in vscode.
The code in roku-debug is some of the oldest code in RokuCommunity, and has been historically very difficult to unit test because of how much it interacts with an actual Roku device. roku-debug#107 makes great strides in improving that experience by creating a fully functional mock server that imitates Roku’s debug protocol. This allows us to write much more extensive tests in our client code to ensure the binary data we’re sending to the roku is valid, as well as verifying that we properly handle the incoming data. These changes also include improvements to the debug protocol logic that align us more closely with what we expect to see in Roku OS 12 which is likely to launch this spring.
We’ll do a larger writeup on all of these features when feature lands (hopefully sometime in March or early April), but you can take a look at the pull request if you’re curious.
We’ve been hard at work designing the upcoming file API for BrighterScript. Currently in BrighterScript, only
.xml files are loaded into the program. All other files are copied as-is from
./staging. Even manifest files are only loaded in read-only mode and cannot be changed by plugins. The file API introduced in BrighterScript#408 will empower brighterscript plugins to process, transform, and even completely rewrite files of any type. We’re excited to see what the community will do with these new features, so hopefully we can get it finished up in the next few months.
Component statement is a proposal to the BrighterScript language that would allow developers to define SceneGraph components in brighterscript code instead of xml. It’s built off the foundations of the File API, and is being used to validate that the File API is functionally capable of its goals. You can read more about the Component Statmenet designs in this PR, and we’re hopeful to land this feature before summer.
Last but certainly not least, a big Thank You to the following people who contributed this month:
Contributions to roku-debug:
The views and opinions expressed in this website and all of its pages are those from within our open source community and do not represent the views or positions of Roku, Inc. or any entities they represent.