In this update
Welcome to the July 2023 edition of “What’s New in RokuCommunity.” Please consider subscribing to stay up to date with what’s happening in RokuCommunity.
Whew! It’s been a busy month. We’ve added a busy spinner in vscode for you to know when the language server is doing work, added ECP rendezvous tracking, and bunch more! We (mostly Mark Pearce) also made some serious progress on the BrighterScript type tracking features in the latest v0.66 alphas.
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 brighterscript-formatter#23: Optional object comma. brighterscript-formatter is the project that powers the auto code formatting in the vscode extension for both BrighterScript and BrightScript code, so this feature will benefit every Roku developer, not just BrighterScript developers.
Commas in multiline object declarations are completely optional. Some teams prefer a trailing comma on every line to align the style with other languages like javascript or C#, while other teams prefer to omit the trailing commas because they’re not required. The formatter needs to be updated to automaticaly add/remove the commas based on a configuration option. Perhaps something like this:
aaCommaStyle: “trailing-required”
someAA = {
first: 1,
second: 2,
third: 3
}
aaCommaStyle: “no-trailing”
someAA = {
first: 1
second: 2
third: 3
}
If you’re interested in working on this feature, please comment on the github issue or reach out to us on Slack
We’ve added a spinner in the vscode statusbar to let you know when the language server is busy. Features like completions or hovers are blocked until the project finishes validating, so seeing the spinner should raise awareness of when validation is actually occurring and roughly how long it takes.
NOTE: We’ve seen a few instances where the spinner never stops running. If this is happening for you, please raise an issue on github.
Users of BrighterScript interfaces will be pleased to know that we’ve fixed a few syntax highlighting bugs for comments and methods in interface declarations:
fileLogging
option for debug sessionsWe’ve added a new launch.json
setting called fileLogging
. Here’s the default value:
"fileLogging":{
"dir": "${workspaceFolder}/logs",
"rokuDevice": {
"enabled": true,
"filename": "rokuDevice.log",
"mode": "session",
"logLimit": 5
},
"debugger": {
"enabled": true,
"filename": "debugger.log",
"mode": "session",
"logLimit": 5
}
}
rokuDevice
is for the telnet/output logs from the Roku device. This is the output from all your print statements, Roku’s beacon logs, compile timing, etc.
debugger
is for the RokuCommunity debug logging. These logs are typically used to help troubleshoot issues with our debugger logic in the VSCode extension. Turning on logLevel: "verbose"
and submitting these debugger logs will really help us to more easily detect issues, so please consider submitting these logs when you open github issues.
The "mode"
option specifies whether you want to generate a new log on every session. "session"
means generate a new log every session, while "append"
will append logs to the existing log file (or create a new one if it doesn’t exist yet). You can also set "logLimit"
to specify the max number of log files that should be created before the oldest one gets deleted.
We’ve also deprecated the logfilePath
and brightscript.extensionLogfilePath
options in favor of this new, more powerful option. They’ll still work for a while, but we suggest migrating to fileLogging
as soon as you can.
launch.json
We’ve added a new launch.json
option called deleteDevChannelBeforeInstall
that can delete the existing developer channel before starting a new debug session.
Roku OS 12.5 beta has been out for a few weeks now, and one of the updates caused issues with the VSCode extension’s debug session, so if you’re having issues, try enabling this option.
Historically, the VSCode extension has monitored rendezvous by monitoring the telnet logs for rendezvous entries (enabled by the logrendezvous port 8080 command). In Roku OS 11.5, Roku introduced a brand new ECP-based sgrendezvous service to improve rendezvous tracking for external tools (like the VSCode extension).
We’ve overhauled rendezvous tracking in the VSCode extension to merge the two systems (ECP and telnet) into a single launch.json setting called rendezvousTracking
. Setting it to true
will activate ECP tracking when possible, but fall back to telnet if not supported on your device. Setting it to false
will disable both the ECP and telnet/port8080 systems.
Known Issues:
If you’re a regular user of bslint, you may have experienced a bug where variables declared inside try
/catch
statements were not properly recognized in the code flow tracking logic. bslint##93 fixes this issue. Here’s the error before the fix:
We found some significant performance improvements (up to 20% faster) in by fixing a bug in the varTracking logic that was re-calculating the scope globals too frequently (for each file for each scope). Since the scope globals are shared across every file in that scope, we can lift that calculation so that it’s only run once per scope. (bslint#92)
This shaved off 1,300ms from the validation cycle of a large internal project
before
Validating project finished. (6s531.186ms)
after
Validating project finished. (5s224.474ms)
BrighterScript logs will now include a unique “project index” number next to the log entries. This will help when there are multiple projects running in the language server at the same time.
--profile
CLI flag for better profiling supportIn order to more easily identify bugs or performance bottlenecks in the brighterscript compiler and language server, we’ve added a new --profile
cli flag which activates the v8 javascript profiler. It’s probably only useful for brighterscript maintainers, but could be useful if you have a specific brighterscript build run that takes much longer than you would expect and want to figure out why.
To keep our dependencies light, this command will auto-install the v8-profiler-next
on-demand the first time you run with the --profile
cli flag.
To use it, just add the --profile
flag to the end of your brighterscript CLI command when running brighterscript, and then view the .cpuprifle
output in a tool like vscode.
bsc --project ./bsconfig.json --profile
Fixed a small bug in the BrighterScript compiler that would crash when a diagnostic was missing the range
property. It will now more gracefully recover and continue on its merry way validating and compiling apps! (see #832
)
beforeProgramDispose
plugin hookBrighterScript plugins can utilize the new beforeProgramDispose
plugin hook which will allow plugins to run code whenever a brighterscript program is about to be disposed.
We’ve fixed a bug in the plugin event system that was emitting the afterScopeCreate
event before the component itself was created, which was less than helpful. Now both the component scope and component classes are initialized before the afterScopeCreate
event is fired.
BrighterScript has a suite of benchmarks that can be used to evaluate how a code change has We converted the benchmarks
projects. We have converted the benchmark scaffolding from javascript to typescript in order to improve their development experience. This doesn’t really effect brighterscript users, but will improve that experience for brighterscript supporters. (see #835 for more informatoin)
This summer we’ve been hard at work adding a full-fledged type system to BrighterScript. We announced this last month, but we’ve made significant improvements since then. Here are some of the highlights:
We’ve tightened the range of some object property diagnostics so that they now only highlight the first property with the issue.
before
after
We’ve added much better validations around when functions are used as parameters to other functions. Specifically, we validate when a function is used as a parameter and also when non-functions passed as arguments.
as Object
passing in the manner of as Dynamic
We fixed some bugs in the type tracking related to as object
. Object
types can now properly be passed to any function type, just like dynamic. (see #850 for more info)
enums
as literal valuesWe no longer show a warning when passing enum values to functions expecting a compatible primitive type.
0.66.0
performance fixesAs we added new type tracking validations to BrighterScript, we noticed that performance was starting to slow down significantly. So we spent some time optimizing the internal logic in brighterscript to regain some of the lost performance. You can check out brighterscript#834 for the specific changes, but here’s an overview:
Overall improvement (to a large proprietary project):
Here are the various improvements made in this PR:
optimize util.getAllGottedGetParts
optimize util.getDottedGetPath
optimize util.getAllDottedGetPartsAsString
with old getAllDottedGetParts
with new getAllDottedGetParts
optimize cache.getOrAdd
to call super.has()
and super.get()
instead of this.\*
which eliminates some prototype lookups.
scope.buildNamespaceLookup()
enableTypeValidation
flagIn the first few releases of v0.66.0-alpha, we had added a enableTypeValidation
flag to help with performance issues. however, with the performance fixes mentioned above, there wasn’t much value in having the logic be separate (and it would complicate future work anyway), so we have now removed enableTypeValidation
as of v0.66.0-alpha.3.
const
values now can be composed of other const
values (#826)load
method to ProgramBuilder
for testing to decouple loading from running, mostly for testing, decouple loading from running by adding the load
method to ProgramBuilder
(#821)BrighterScript interfaces were introduced back in June 2021. However, for some reason we never created any documentation about the, so they were mostly discovered by word-of-mouth. Well we’ve fixed that this month by adding a dedicated documentation page about interfaces. Happy reading!
Last but certainly not least, a big Thank You to the following people who contributed this month:
Contributions to vscode-brightscript-language:
Contributions to brighterscript:
v8-profiler-next
on demand instead of being a dependency (PR #854)Contributions to roku-debug:
Contributions to bslint:
Legal notice
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.
Designed with @arturocuya, powered by Astro
by