Slack logo
Github logo

In this update

  1. Overview
  2. We need your help
  3. Issue of the month
  4. Debugging
  5. Support relaunch debug protocol
  6. DebugProtocol fixes
  7. BrighterScript
  8. Allow Additional v1 Syntax:
  9. Fix sourcemap comment and add file prop to map
  10. Add support for provideReferences in plugins
  11. Empty interfaces break the parser
  12. Community Tools
  13. bslint
  14. Support for latest BrighterScript alphas
  15. roku-deploy
  16. Retry the convertToSquashfs request given the HPE_INVALID_CONSTANT error
  17. Preview features
  18. BrighterScript v1
  19. Built-in Objects have their interfaces as members
  20. Do not do validation on dotted sets of AAs
  21. Changed adding invalid as arg to empty callfunc invocations by default
  22. Standardize AST Constructors
  23. Indexed get set multi index
  24. Simplify the plugin method signatures.
  25. Add rsgpalette to scraped docs
  26. Fix member hovers for classes, interfaces and enums
  27. Adds validation when trying to access a class member directly on a class name
  28. Adds validation for calling new on a non-class constructor
  29. Make All AST Props Readonly
  30. Modifies all SG AST constructors to use named properties in objects
  31. Thank you

Overview

Welcome to the February 2024 edition of “What’s New in RokuCommunity.” Please consider subscribing to stay up to date with what’s happening in RokuCommunity.

We need your help

The RokuCommunity projects are maintained by a relatively small group of developers (mostly volunteers), and we have a growing list 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:

Issue of the month

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 various RokuCommunity codebases.

This month, we’d like to highlight brighterscript#1062. A few years ago, Roku added the optional chaining operator. However, there’s a limitation where you can’t optionally call a function on its own with this operator. Here are some examples:

f = { g: function() print "hello world": end function }
print f?.g?() ' totally fine, prints "hello world"
f?.g?() ' Syntax Error

We’d love to add support for the f?.g?() example by transpiling it to an assignment instead: _ = f?.g?(). This would allow developers to safely optionally call their functions.

If you’re interested in working on this feature, please comment on the github issue or reach out to us on Slack

Debugging

Support relaunch debug protocol

One of the major issues we encountered during our debug protocol testing back in November was that the output logs would stop showing once you closed the app during a debug protocol session. This has now been fixed.

The underlying problem is that debug protocol sessions are terminated when you close the app, so we had no way of knowing when you re-launched the app since we had already disconnected. However, we discovered that Roku devices will print "Waiting for debugging connection" anytime you open a previously-sideloaded app using the debug protocol. That allowed us to scan the telnet logs for that entry, and auto-reconnect a new debug protocol session at that time.

While this is not the same as “remain connected”, it does simulate that behavior, and should be seamless to the user.

DebugProtocol fixes

We fixed a bug in the debug protocol that whenever the ThreadsRequest fails with error code 4, we try to suspend again. This has added significant stability to debug protocol sessions. There’s not much to show here, but just know debug sessions should crash and get into invalid states much less frequently

BrighterScript

Allow Additional v1 Syntax:

With the BrighterScript v1 alphas under heavy development, we found it was sometimes difficult to test new features while also maintaining existing codebases. To mitigate this, we have backported many of the new v1 syntax changes into the mainline v0 releases. This means you can write the new v1 syntax, which will transpile to normal code.

For example, one of the new features of v1 is that any assignment can support a type on the left-hand-side. So this syntax is now supported in the v0 releases (but without any validation support, you still need to use v1 for that).

class Foo
    node as roSGNode
end class

sub someFunc()
    myStr as string = "hello"
end sub

Fix sourcemap comment and add file prop to map

We fixed some quirks in the sourcemaps generated by brighterscript. All of these should allow for more stable sourcemap usage across various sourcemap tooling (such as source-map-visualization).

Here are the changes we made related to sourcemaps:

  • Adds the file prop to sourcemaps to better align with the spec.
  • fixes the filename in the sourceMappingUrl comment at the bottom of every file
  • moves the sourceMappingUrl entry to a new line to make the file more clean

Add support for provideReferences in plugins

Add support for plugins to contribute references when running as part of a language server. References are used by the “Get all references” option in the editor:

image

Empty interfaces break the parser

We fixed a bug where empty interfaces would cause exceptions in the brighterscript parser.

image

Community Tools

bslint

Support for latest BrighterScript alphas

This month we updated the bslint v1 alphas to support brighterscript v1.0.0-alpha.25 and v1.0.0-alpha.26. Please be sure to keep the bslint and brighterscript alpha versions in sync (i.e. when using bslint v1.0.0-alpha.26, be sure to install the same version of brighterscript).

roku-deploy

Retry the convertToSquashfs request given the HPE_INVALID_CONSTANT error

We occasionally see the convertToSquashfs request fail in RokuDeploy. It seems to be caused by some specific set of zip sizes and filename length. The squashfs conversion appears to be successful, but for some reason the Roku returns a truncated response, preventing us from recognizing a successful operation.

To work around this, we send a second squashfs request any time we see the HPE_INVALID_CONSTANT error. If that response includes 'fileType': 'squashfs' then we return the result saying it succeeded.

Preview features

BrighterScript v1

We made a lot of progress on the brighterscript v1 alphas again this month. Here are some of the highlights:

Built-in Objects have their interfaces as members

Adds all the interfaces a built-in object has as accessible members.

image

Do not do validation on dotted sets of AAs

Since AAs can change and have their properties overwritten, there will be no validation on invalid types for dotted-set’s and dotted-gets of AAs

image

Changed adding invalid as arg to empty callfunc invocations by default

New bsconfig.json option:

"legacyCallfuncHandling": {
    "description": "Legacy RokuOS versions required at least a single argument in callfunc()
        invocations. Previous brighterscript versions handled this by inserting invalid as an argument when
        no other args are present. This is not necessary in modern RokuOS versions.",
    "type": "boolean",
    "default": false
}

Standardize AST Constructors

As part of the v1 release initiative, we needed to make some breaking changes that have been bugging us for a while. One such breaking change is related to the AstNode structure. Here are the changes:

  • take a single options object in the constructor
  • constructor options keys end in token if it is a token or an identifier
  • all tokens are accessible via a .tokens member on the node
  • optional and/or mandatory keyword tokens do not need to be included in the constructor
  • transpiles will just fill in a missing keyword if not included.

This was a fairly significant change, and plugins will absolutely be affected by this. So it is worth looking over brighterscript#1025 if you’re interested in knowing exactly what changed.

Indexed get set multi index

The mainline brighterscript branch received a fix in #1054 which added support for multi-indexed arrays (i.e. multiArray[[["hello"]]]). However, we did it in a backwards compatible way (see the new additionalIndexes property) but it wasn’t our preferred implementation. In order to conform to the new v1 AST Structure, we needed to refactor that again in a breaking way. So that has been merged into a single property called .indexes. This should only impacts plugin authors.

Simplify the plugin method signatures.

For plugin authors, we’ve improved the plugin signatures in our typescript type definition files. This should provide much better autocomplete support when writing brighterscript plugins.

Before:

beforeProgramCreate?: PluginHandler<BeforeProgramCreateEvent>;

event-signature

After:

beforeProgramCreate?(event: BeforeProgramCreateEvent): any;

event-signature-better

Add rsgpalette to scraped docs

We added rsgpalette to the standard library, which should fix the following type of error:

image

Fix member hovers for classes, interfaces and enums

We fixed bugs in the hover results that would show the incorrect variable name when showing the type.

Before: image

After:

Enums members image

Class Members (looks same as interfaces):

image

Adds validation when trying to access a class member directly on a class name

We’ve added a new diagnostic that prevents you from referencing class properties and methods on the class constructor. This would have always resulted in invalid anyway, and is probably not what you intended to do. These members are also now excluded from the completions on the constructor.

image

Adds validation for calling new on a non-class constructor

We added several new validations related to the new operator. You should see diagnostics anytime you call new on something that’s not a class.

image

image

Make All AST Props Readonly

In efforts to make plugin authorship easier, we’ve marked many AST properties as readonly, as they need to be manipulated by the AstEditor and not modified directly. Here are some of the changes

  • Makes all the AST Props readonly - both tokens and any expressions referenced.
  • Removes get BrsFile.functionCalls() - was not used… also removed tests associated with it
  • Re-worked some parsing code so it gathers all tokens/expressions before building the node — this has the consequence that there may be more diagnostics in some situations, because it doesn’t end parsing as early as before (eg. try catch blocks)
  • A few more small AST tweaks (like renaming ImportStatement.tokens.filePath - > ImportStatement.tokens.path)

Modifies all SG AST constructors to use named properties in objects

For plugin authors, we’ve modified all of the SceneGraph AST nodes to accept named properties in their constructors to align with the BrighterScript AST design.

Plugin authors will need to modify their SceneGraph node creation to things like this:

image

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. May 2024
  2. April 2024
  3. March 2024
  4. February 2024
  5. January 2024
  6. December 2023
  7. November 2023
  8. October 2023
  9. September 2023
  10. August 2023
  11. July 2023
  12. June 2023
  13. May 2023
  14. April 2023
  15. March 2023
  16. February 2023
  17. January 2023
  18. December 2022
  19. November 2022
  20. 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