Slack logo
Github logo

In this update

  1. Overview
  2. Editor
  3. Device View and SceneGraph Inspector now works in WSL!
  4. Small language server performance boost
  5. Debugging
  6. Exclude sourcemaps when sideloading
  7. Better error handling for RALE integration
  8. Better error reporting for launch.json validation crashes
  9. Add better error for failed session starts
  10. Wrap the dnsLookup for host in a try/catch
  11. BrighterScript
  12. bslint now works with const
  13. Fix namespace-inferred items
  14. Fix semantic tokens for namespaces
  15. Fix namespace-inferred enum value
  16. Enum member lookups are now case INsensitive
  17. Type tracking coming soon
  18. Misc
  19. Fix some more github status badges
  20. For Contributors
  21. Add cpuprofile ability to BrighterScript benchmarks
  22. Thank you

Overview

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!

Editor

Device View and SceneGraph Inspector now works in WSL!

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 😉)

image

In addition to the WSL fixes, we also made a few performance improvements and UI tweaks to the SceneGraph Inspector that should make it nicer to use.

Small language server performance boost

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

Before:

image

After:

image

Debugging

Exclude sourcemaps when sideloading

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.

image

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:

Sourcemaps INCLUDED:

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)

Sourcemaps EXCLUDED:

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)

Better error handling for RALE integration

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.

image

Better error reporting for launch.json validation crashes

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 try/catch so we can log exceptions to the output channel, which should give developers access to much more useful feedback for future crashes.

image

Add better error for failed session starts

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.

Wrap the dnsLookup for host in a try/catch

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.

BrighterScript

bslint now works with const

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.

image

This has been fixed and is available starting in bslint v0.8.3

image

Fix namespace-inferred items

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.

image

Fix semantic tokens for namespaces

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!

image

Fix namespace-inferred enum value

BrighterScript v0.64.2 fixed a validation bug that was incorrectly flagging namespace-inferred enum values as errors.

Before: image

After: image

Enum member lookups are now case INsensitive

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.

Before: image

After:

image

Type tracking coming soon

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: image

You can follow our progress on type tracking in BrighterScript#783.

Misc

Fix some more github status badges

Last month we fixed most of our github status badges, but we made a few mistakes, which have now been corrected. (roku-deploy, vscode-brightscript-language)

image

For Contributors

Add cpuprofile ability to BrighterScript benchmarks

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)

Thank you

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:

Contributions to roku-deploy:

Contributions to roku-debug:

Contributions to bslint:

Updates

  1. December 2023
  2. November 2023
  3. October 2023
  4. September 2023
  5. August 2023
  6. July 2023
  7. June 2023
  8. May 2023
  9. April 2023
  10. March 2023
  11. February 2023
  12. January 2023
  13. December 2022
  14. November 2022
  15. October 2022
Home What's new Slack channel Newsletter Edit this website on Github

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 favorite by @arturocuya, powered by Astro