Home Community Blog Buy Now

Misty Community Forum

Precise description of JavaScript runtime?

I am trying to improve the workflow of JS skill development. To support this and to support Misty skill development in general, is there a precise description of the JavaScript runtime?

In particular (but not limited to),

  1. precisely which JavaScript language syntax is implemented?
  2. what global objects are available besides misty ?
  3. is there a maximum size of the uploaded JS file ? e.g., what happens if I upload a file that has size 64 MB?
  4. excellent feedback was given 1 year ago at https://community.mistyrobotics.com/t/thoughts-on-the-development-experience/1393. Were the comments addressed? Some are quite important, e.g., the comment that setInterval is not available.

Hi Scott,
Thanks for your questions, I’ll try to answer them in order.

Precisely which JavaScript language syntax is implemented?
The syntax is based off of EcmaScript 5, but it is a wrapper around that, so this isn’t ‘exactly’ JavaScript (I am sure this comes as no surprise to anyone using it). It is using the JavaScript syntax, but due to the limitations around single-threading and no browser or DOM, there are a number of differences.

What global objects are available besides misty ?
There are no other system global objects.

Is there a maximum size of the uploaded JS file ? e.g., what happens if I upload a file that has size 64 MB?
I don’t believe there is a limitation to the JavaScript file size other than potential IoT limitations.

As for the comments in the post you referenced…

My first attempt to work with Misty was with code.mistyskills.com – a (new?) interface to upload JavaScript directly to Misty…
code.mistyskills.com is not a Misty product. A community developer wrote their own client tool for writing and deploying scripts, so I can’t speak to the functionality of that tool.

Using let instead of var seemed to cause silent failures. Oddly portions of the module would execute, instead of simply getting a SyntaxError. But it wasn’t exactly an old version of JavaScript, as string interpolation was supported.
We have not seen this issue, so if this is still happening, please let us know and we can look into it.

The way callbacks work is unusual. From the docs, nothing like a normal callback is in the API, only named callbacks.
In the initial implementation of the JavaScript skill system it used normal callbacks as provided through the Chakra system, but it was not performant and blocked events from the robot while waiting for callbacks due to its single-threaded nature. The implementation we have is certainly a work around to that single-threaded functionality to allow it to handle asynchronous events that can come back at a rapid pace. We have discussed making an option for people that want to use real callbacks, but that would only work for certain types of skills that don’t expect immediate handling of events…

SetTimeout and setInterval aren’t available. Both myself and the person working next to me immediately wanted to use these functions, as it’s the natural way to do something that appears “autonomous”.
Since there is no browser and no DOM, setTimeout and setInterval are not implemented by default. We attempted to give you the same functionality with the timer events.

Implement console.log yourselves, it’s not a protected function, and you can implement it in terms of misty.Debug.
console.log prints data directly to the console. misty.Debug sends websocket events that a user must register for and process, so they aren’t actually the same thing since the code is not actually running in the browser.

I think I overheard this is using Chakra. Obviously not a great platform for the future since it’s deprecated. But even so, by translating the code appropriately using Babel you can make it look like normal JavaScript.
At the time of development, Chakra was supported on the IoT device (and Node was not) and it is actually the direction that Microsoft recommended. Unfortunately they have deprecated Chakra since then, which was a surprise for us as well. I am not familiar with Babel, and am not completely sure what they are recommending here, sorry.

You should be able to do better error catching at the JavaScript level too, to improve the debugging output. Careful use of try/catch can go a long ways.
I assume this was referring to examples on the community site and I agree. People should certainly use try/catch statements in your code where appropriate.

Use Promises for one-off asynchronous code (like misty.GetAudioList())
Promises have the same threading issue as the callbacks did on the robot. With a system that is receiving events all the time from the robot, it blocked the handling of those events until promises returned, causing skills to not work.

Use an addListener/removeListener style API for pubsub-like APIs.
If the current APIs reflect the underlying architecture, you can still probably simulate these more idiomatic APIs, so long as the JavaScript process is long-lived.
I believe this recommending changing the style to camelCase instead of PascalCase. It is certainly something we have discussed, but hasn’t made it to the top of the list yet.

The limitations we ran into while creating the JavaScript skill system on the IoT device are also the reasons why we recommend people to move more toward the C# skill system as it is multi-threaded, extremely performant, it is not a wrapper around the language like the JavaScript skill system needed to be for the performance required to handle events, and Microsoft has a free VS Community IDE that is fully functional (and in my opinion makes development much nicer). It also allows for users to write complete applications to run on the robot and interact with third party applications and nuget packages.

I hope this answered your questions, thanks!

1 Like

I guess I had not noticed it before, but you are actually recommending that we move toward the C# skill system and away from JavasScript skills?

Honestly, that is very disappointing as I am not using Microsoft Windows as my main day-to-day working OS. Furthermore, the “free VS community IDE” has restrictive licensing; it is “free” as in “no cost” but not “free” as in freedom. Other languages like JavaScript, Python, and C++ have high quality toolchains that are open source and cross-platform: ready and easily installed on Windows, macOS, and GNU/Linux. There are also excellent and diverse choices of IDEs, analysis tools, etc.

While the Misty REST API offers a general cross-platform interface, it requires an offboard controller, which is a significant constraint for many applications.

I know there is limited capacity for work-hours at any company, including Misty, but I did not purchase the Misty robot expecting to be tied to Windows.

Perhaps a productive conversation to start is how to support something besides C# as a skill language. What about making some parts of the Misty firmware open source, to better allow community-contributed extensions?

Hi Scott,
You certainly do not have to move toward C# if you can accomplish your goals with JavaScript. We continue to support and expand the JavaScript skill system with new commands as they are added and will continue to do so. I was just pointing out the limitations of the single-threaded nature of JavaScript while working with an asynchronous robot. We are looking into ways to support other languages like C++ and Python, but it will probably be some time before we can complete those.

1 Like

Not really interested in arguing about viability of JS here, just note that the limitations you cite are from your prior design choices and not JS per se. For example, “single-threaded nature” can be overcome with the Web Workers API that “makes it possible to run a script operation in a background thread separate from the main execution thread”.