Nasal HLA standalone

From FlightGear wiki
Revision as of 10:27, 26 May 2013 by Hooray (Talk | contribs) (

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


One of the things that is most frustrating and time consuming when working with Nasal scripts is the brute force and manual nature of testing the scripts. A simple misspelling in a custom script can take 5-10, or more, minutes to fix from the point of finding it (shut down FG, change script, startup FG and get back to a point in the sim where the code will execute). Obviously Nasal is tightly coupled to FG at this point and most scripts won't run without access to the property tree. That doesn't mean that it can't be done though.

A standalone interpreter

Providing a standalone Nasal binary that has its own property tree access would not be very difficult, it would be mostly copy/paste from SimGear/FlightGear. Philosopher is for example using a heavily customized standalone Nasal interpreter for development purposes that has many features which FG doesn't have (yet). But that doesn't make it any easier to develop scripts FOR FlightGear. Most scripts in FlightGear use a plethora of APIs and FG-specific modules, so FG has become a runtime dependency (APIs, data structures like the property tree, and "live" state),

You could definitely add the FG/SG property tree code to the standalone interpreter - it would not even be very difficult, if you know C++, it should only take a couple of hours to make it work, but that will just ensure that your scripts have their own property tree, it doesn't provide any of the other FG/Nasal APIs or subsystems, such as the autopilot etc.

Testing scripts is so time-consuming because of various issues: 1) Nasal being a dynamically typed language, where errors often only show up at runtime, 2) the lexer/parser is not particularly robust - so that error messages are not very informative, and may only show up fairly late. Philosopher has been working on improving things a little. 3) The main issue is FlightGear's way of loading Nasal scripts just once during startup, i.e. there's no design/mechanism in place to do Nasal housekeeping, so that the interpreter cannot be re-initialized at runtime, which is why most scripts are not safe to reload currently. You can only reload scripts manually if you explicitly design them to support this use-case, which includes releasing resources like running callbacks (loops, listeners, timers) or files and threads. Even if the FG design were to be fixed, I'd expect that most scripts would need to be changed.

Thus, a standalone Nasal interpreter in and of itself would not be particularly useful for developing/testing Nasal code for use in FlightGear, that would require some way of IPC - so that the interpreter can run in its own thread/process and still hook into the fgfs process.

Hight Level Architecture

At some point, the ongoing HLA work should facilitate a scripting API exposed via HLA, so that scripting languages like Nasal (or Python or any other language) would be able to call FG APIs (like extension functions) via HLA

Cquote1.png Another thing that would work well is to proxy all nasal script invocations to a Nasal helper thread - again this assumes scripts

basically interact with the sim via properties (which they already do) and that any system functions they call are thread safe - not very

hard to do. As more and more functions get moved to nasal, this might become a very easy way to balance the CPU usage.[1]
— James Turner

At the time of writing, The SimGear repository already contains all required HLA primitives to map the property tree and other C++ classes to HLA. For example, see:

More demo code at:

  1. James Turner (Fri, 03 Oct 2008 06:52:12 -0700). [Flightgear-devel] multi-threading / CPU usage.