Nasal HLA standalone
|Memory Management (GC)|
- Last updated: 06/2013
- Contributors: Dbelcham, Callahanp, Hooray
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.
|I do like the idea of a stand-alone script interpreter communicating via HLA or some similar IPC, but we still have to consider fragments of script code embedded in models to create or enhance fancy animations. Not all script fragments make sense to run externally.
— curt (Dec 28th, 2015). Re: FGPython an propose for Python as an nasal alternative.
(powered by Instant-Cquotes)
|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 veryhard to do. As more and more functions get moved to nasal, this might become a very easy way to balance the CPU usage.
— James Turner
|you're all hoping for a better FG. A large redesign, so we can make use of multi-core systems, can even distribute parts across multiple
machines. Can separate the GUI. Get Nasal outside the main simulation loop.
- HLA property tree support Done
- standalone nasal interpreter Done
- modify the build system to link in the required libs Done
- add the f_setprop/f_getprop code from $FG_SRC/Scripting/NasalSys.cxx to the standalone interpreter Done
- add the HLA/OpenRTI boilerplate to the standalone interpreter so that it can use HLA and act as a federate (see $FG_SRC/Network/HLA/hla.cxx and $FG_SRC/utils/fgai)
- fgai::AIManager federate: flightgear/flightgear/next/utils/fgai/AIManager.hxx#l27
- fgviewer: flightgear/flightgear/next/utils/fgviewer/fgviewer.cxx#l212
- fgfs: flightgear/flightgear/next/src/Network/HLA/hla.cxx#l841
- ba-hla: https://github.com/chiemseesurfer/ba-hla
- next, add a simple "ScriptingHost" federate Not done
- setprop()/getprop() implemented through HLAPropertyDataElement
- $FG_SRC/Scripting/nasal-props.?xx wrapped through HLAPropertyDataElement Not done
- Extend cppbind to support HLA (HLAObjectInstance etc) Not done
- port nasal-props.cxx to use cppbind
- maybe support some more FG/Nasal APIs (see flightgear/flightgear/next/src/Scripting/NasalSys.cxx#l707 ) Not done
- know C++
- be able to build custom SG/FG versions
- use Git
- have a wiki account
- work through some of the HLA tutorials at FlightGear HLA support (High Level Architecture)#Resources
A standalone interpreter
Providing a standalone Nasal binary that has its own property tree instance would not be very difficult, it would be mostly copy/paste from SimGear/FlightGear ($SG_SRC/nasal and $FG_SRC/Scripting).
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.
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 Nasal modules ($FG_ROOT/Nasal), so FG has become a runtime dependency (APIs, data structures like the property tree, and "live" state),
Now, 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.
To reload Nasal scripts, the whole process must be terminated and restarted 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 (think CORBA or HLA)- so that the interpreter can run in its own thread/process and still hook into the fgfs process to access other subsystems, like the property tree.
High Level Architecture
We were recently talking about using HLA to support a standaloe Nasal interpreter it in another thread, and because Nasal has some performance issues (garbage collection) that are having an impact on framerate/latency under certain circumstances.
Thus, providing an option to run /some/ scripts separately, outside the main loop and connect things through HLA woul seem like a straightforward first step - especially because the SimGear machinery for exposing the full property tree through HLA is already in place (so not much coding needed, just understanding/applying) and there are some more low-level wrappers available in simgear/hla to expose C++ classes, objects etc - so basically it works a lot like CORBA/RPC through a central "broker" (openRTI).
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
Also, there's a standalone interpreter for unit testing: gitorious/fg/hoorays-simgear/HEAD
So we already do have a standalone Nasal interpreter that cannot currently talk to the fgfs process - making it talk to fgfs through HLA would be a first step, and the setprop/getprop APIs (or whole props module eventually) would be an obvious candidate, because the property tree infrastructure is already in place im simgear/hla (see HLAPropertyDataElement).
One of the goals could be to support multiple standalone Nasal processes which run setprop()/getprop(), which in turn is marshalled through HLA/OpenRTI to fgfs. That would not seem overly complicated, but like a pretty simple and useful first use-case to allow people to run certain stuff outside the main process
Obviously, one would need to expose other FG/Nasal APIs eventually, but we should probably learn to walk before we run
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:
Demo code at:
HLA support through cppbind
In the long run, one would need to implement the full interface of the HLAObjectClass, for example as part of the cppbind framework in simgear/nasal/cppbind- that way, cppbind APIs would become accessible through HLA, so that all cppbind APIs could also be used from a standalone interpreter that would not need to run inside the fgfs main loop anymore.
To add HLA support to cppbind, we'd need to provide corresponding from_nasal_helper() and to_nasal_helper() templates to convert various HLA types to their corresponding Nasal equivalents and vice versa.
All the SimGear machinery to help with marshalling should be in place in $SG_SRC/simgear/hla
Tom can probably help clarify what else may be missing currently ?
- James Turner (Fri, 03 Oct 2008 06:52:12 -0700). [Flightgear-devel] multi-threading / CPU usage.
- ThorstenB (Wed, 15 Jun 2011 16:06:00 -0700). Re: [Flightgear-devel] Heads up: scenery download / built-in.