In this update
June was a fairly slow month in terms of new releases, as many of us were on vacation or busy with behind-the-scenes features. However, we did fix a few bugs in BrighterScript, and we have an exciting announcement to make about type validation support in BrighterScript!
The RokuCommunity projects are maintained by a relatively small group of developers (mostly volunteers), and we have a growing list of of unresolved issues. We need your help! There are many different ways you can contribute. Whether it’s addressing bugs, improving documentation, introducing new features, or simply helping us manage our expanding list of GitHub issues, your involvement would be greatly appreciated. We are more than happy to guide you in finding the most suitable contribution method that aligns with your interests. To learn more about how you can contribute, feel free to reach out to us on Slack, or explore the existing GitHub issues:
In this section, we highlight a specific issue where we could benefit from the community’s assistance in finding a solution. These problems are generally straightforward to address, and serve as an excellent opportunity to become acquainted with the RokuCommunity codebases.
This month, we’d like to draw attention to vscode-brightscript-language#475: Add launch setting to manage Remote Control Mode.
The VSCode extension has a neat feature called “Remote Control Mode” that converts your entire keyboard into a roku remote. You can even type alphanumeric characters into text boxes on the Roku with this enabled. Remote Control Mode is activated by clicking the toggle button in the statusbar.
vscode-brightscript-language#475 will take that one step further by adding a new launch.json option to automatically enable Remote Control Mode when you start a debug session, and disable Remote Control Mode when you stop a debug session.
We’ve added a new
fileLogging launch option for debug sessions in the VSCode extension. Roku developers can enable this flag and then submit the debug logs with their github issues, which will greatly improve our ability to reproduce and fix bugs in the debugger.
We’ve fixed a bug in the BrighterScript transpiler so that it no longer injects a
super() call if one already exists in the
new() method. As long as you don’t reference
m, you can now have leading code before the call to
super(). Along with this fix, we now flag statements that reference
m before calling
super(). Available starting in email@example.com
We’ve been hard at work adding a type system to BrighterScript, and we’re super excited to announce alpha builds of these upcoming changes. All of the type tracking/validation will be included in the upcoming
v0.66.0 release, so we’ve started publishing alpha builds. v0.66.0.alpha-2 is the latest build in June (but there may be newer releases if you’re reading this from the future!). Shout out to @markwpearce (Mark Pearce) for all of the hard work on this effort.
The work done here in June has mostly been under-the-hood changes to prepare for much more advanced type validation logic. Keep an eye out for July’s what’s new writeup, as we will hopefully have much more practical and exciting type validations to show off then!
NOTE: v0.66.0 will include many breaking changes for brighterscript plugins. See this section for more details.
We will be creating a much more in-depth writeup of all the new features and changes once v0.66.0 is released out of alpha, but here are some highlights of the progress made this month:
sub main() value = (getValue() as integer).toStr() end sub function getValue() return 123 end function
To install the latest brighterscript alphas, you can run the following command:
npm install brighterscript@next
Then, if you want to use this version as a language server, set the following option in your vscode
settings.json file and restart vscode:
The BrighterScript v0.66.0 alphas have also made a few changes to the underlying BrighterScript APIs. We won’t get too detailed here, but we wanted to call out the high level changes so you know what to look for as you update your plugins to support the upcoming v0.66.0 release
We’ve refactored the XML ast structure to be more intuitive. This is mostly a behind-the-scenes change, but plugin authors will need update any of their XML ast logic (#799)
Converts all plugin event parameters to be a single event object rather than ordered parameters. (#824)
.kind property to AstNode, and an
AstNodeKind enum. (#799) This converts the reflection methods to check for
.kind instead of the
thing?.constructor?.name === 'Whatever' logic which was quite slow. Raw benchmarks show a 10-12 percent performance boost during validation:
Add a new AstNode class called
TypeExpression, which is the base AstNode for all future type expressions (#783)
Add a getType() method to the base
AstNode, which can then be overridden by all AstNode descendents.
SymbolTable to actually include the variable types (#783)
Validate all TypeExpression AstNodes to ensure they reference valid types that can be found in the symbol table (#783)
removed deprecated items from the code (#820)
Last but certainly not least, a big Thank You to the following people who contributed this month:
Contributions to brighterscript:
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.