In this update
We’ve made a lot of good progress this month, including WSL compatibility fixes, performance improvements across editing and debugging, stability fixes, BrighterScript bug fixes, and more!
Last month we introduced the new Device View panel, and the SceneGraph Inspector panel has been there for a while now. However, both of these views were broken when running the BrightScript Language extension for VSCode inside of Windows Subsystem for Linux (WSL). Well, we fixed it! Starting in v2.40.1 of the extension, you can now use all of these nifty features in WSL. (@georgejecook, this one’s for you 😉)
brighterscript#797 adds a small performance boost to the language server by optimizing the
AstNode.getSymbolTable() method. There are no changes to the way you code, but enjoy the free speed boost! This is available starting in BrighterScript v0.64.3 and BrightScript Language extension for VSCode v2.40.1
Many preprocessors such as BrighterScript or gulp plugins will generate sourcemaps alongside the generated files, which are a way to link a generated file, line, and column location back to its original location. The BrightScript language extension for VSCode fully supports reading these sourcemaps to improve the debugging experience with projects that leverage a preprocessor. However, sourcemaps are fairly large, sometimes even as large as the generated file itself.
Also, it seems that on-Roku compile times are slower anytiime sourcemaps are present (perhaps the Roku tries to parse the sourcemaps?), which results in measurably longer on-device compile times.
Thanks to roku-debug#145, the BrightScript Language extension for VSCode will now exclude sourceamps from sideloaded zips starting in v2.40.0 . This speeds up zip times, upload times, and compile times. Here are some timing results from a large brighterscript app. The results speak for themselves:
Packaging projects took: 3s180ms, Uploading zip took 7731ms, AppCompileComplete --------> Duration(5565ms) Packaging projects took: 2s912ms, Uploading zip took 7118ms, AppCompileComplete --------> Duration(5467ms) Packaging projects took: 2s907ms, Uploading zip took 7072ms, AppCompileComplete --------> Duration(5681ms)
Packaging projects took: 2s331ms, Uploading zip took 5927ms, AppCompileComplete --------> Duration(4143ms) Packaging projects took: 2s305ms, Uploading zip took 5899ms, AppCompileComplete --------> Duration(3959ms) Packaging projects took: 2s411ms, Uploading zip took 5920ms, AppCompileComplete --------> Duration(3972ms)
The BrightScript Language extension for VSCode has basic support for RALE integration. When enabled, the extension can auto-inject the RALE tracker task init code into your project by replacing a specific comment with the tracker task init logic. However, there was a bug where the debug session would crash with a very obscure message if
injectRaleTrackerTask was enabled but the file at
raleTrackerTaskFileLocation was missing or the property was omitted entirely.
As of vscode extension v2.40.0, this flow has been improved to now show a much more helpful error notification.
At the start of a debug session in VSCode, the BrightScript Language extension will validate and sanitize the selected
launch.json configuration. Sometimes a runtime exception can occur during this process. In the past, these crash stack traces weren’t avaiable to the developer. As of vscode extension v2.40.0, the entire launch config validation flow is now wrapped in a
catch so we can log exceptions to the output channel, which should give developers access to much more useful feedback for future crashes.
If you’ve been using the vscode extension for a while now, you’ve probably encountered situations where the debug session just randomly shuts down, with no warning or explanation. Starting in release v2.40.1, many of these crashes will now show a much more helpful error popup.
Rather than trying to remember several different IP addresses, another way of referencing your Rokus is by DNS name. Many routers allow statically assigning a host name to a device on the network. For example, Roku 192.168.1.25 could be given the name ”
roku-streaming-stick1”. At the start of a debug session, the vscode extension will do a DNS lookup and translate that DNS name back to its local IP address.
However, in some situations, that DNS lookup could fail, and we were not properly handling that failure and instead would crash the debug session. This has been fixed in v2.40.0 of the BrightScript Language extension for VSCode so that, if the DNS lookup fails, we’ll attempt to use the DNS name as-is, which sometimes still works.
If you’ve used the
const feature in BrighterScript (introduced in v0.53.0) and also bslint, you may have noticed that bslint would incorrectly show errors whenever you tried to reference those consts.
This has been fixed and is available starting in bslint v0.8.3
BrighterScript has a feature in nested namespaces where all the items in that same namespace can be referenced without needing to include the full leading namespace part. We call this “namespace inference”, which you can read about here. As a result of supporting this feature, certain names become unavailable for use as variable identifiers when they conflict with inferred namespace names. These variables are now properly flagged as errors starting in BrighterScript v0.64.0.
Semantic tokens are a way for the language server to enhance syntax highlighting for certain tokens, based on more complex language semantics that regex-based textmate grammar syntax highlighting isn’t capable of supporting. We’ve fixed several bugs in bsc v0.64.0 related to namespace semantic tokens when they’re used in assignment statements and function parameters.
TL;DR: namespaces are prettier now!
BrighterScript v0.64.2 fixed a validation bug that was incorrectly flagging namespace-inferred enum values as errors.
bsc v0.64.0 fixed several situations where enums and enum members were incorrectly handled as case sensitive, when they should both be handled case-INsensitive to align with standard brightscript language design.
markwpearce (Mark Pearce) has been making incredible progress on type tracking and validation in BrighterScript. We’re currently working on improving its performance. The validation flow has slowed down significantly as a result of all the new type tracking goodness we’re running, but we have some ideas on how to gain back most of that performance so stay tuned.
Also, for BrighterScript Plugin authors, be aware that there are some BREAKING CHANGES coming to the BrightScript AST. We’ve tried to keep them as minimal as possible and we hope to release them all at the same time when type tracking lands in the next month or two so that you can fix all of the errors at the same time. We’ll provide a full writeup of the changes once the feature lands.
Here are a few examples of some new validations that are coming soon:
You can follow our progress on type tracking in BrighterScript#783.
For developers who work on the BrighterScript compiler, we have a handy benchmarking tool that helps compare the current performance against the latest release. (#796) adds a
--profile cli flag that will generate a
.cpuprofile file that can be used to identify hot spots that need to be optimized. We also fixed some stability issues in the benchmark project (#795)
Last but certainly not least, a big Thank You to the following people who contributed this month:
Contributions to this month’s whats-new:
Contributions to vscode-brightscript-language:
Contributions to brighterscript:
Contributions to roku-deploy:
Contributions to roku-debug:
Contributions to bslint:
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.