Modernizing FlightGear Scripting

From FlightGear wiki
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.
WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.

Background

FlightGear has built-in scripting capabilities using a custom ECMAScript-based C-like language called Nasal. Over the last couple of years, we've seen some recurring debates in response to requests to provide support for additional scripting languages, possibly to replace Nasal scripting in its entirety.

Motivation

Nasal is de-facto unmaintained and has been unmaintained for several years meanwhile, Nasal is a niche language that is really only used by the FlightGear project, long-standing issues such as its garbage collector, which isn't suitable for a semi-realtime application/simulation like FlightGear, haven't been fixed in years.

In general, there are other, much better maintained, options for embedded scripting these days, such as e.g.:

  • Lua
  • Python
  • Perl

Today, Javascript, Python and Lua have surpassed Nasal capabilities in pretty much everything the FlightGear community cares about: performance (garbage collection, jit etc), concurrency, parallelism, bindings, language ecosystem, and especially the developer base.[1]


In addition, documentation and end-user support for more established/mainstream languages is obviously much better than anything we have for the custom FlightGear/Nasal interpreter.

Many people argue that a more standard scripting language (like e.g. Python) would also attract more potential contributors to FlightGear, also the sizable community with 3rd party modules, means that new functionality can be much more easily implemented ("batteries included", and "no yak shaving" needed).

Challenges

The paradigm of binding a C/C++ core to a scripting language has its own disadvantages, and that makes it very difficult to switch.[2]


FlightGear can't just ditch Nasal. Bringing another scripting language into the fold would certainly be a big undertaking.[3]


It is really important to note that in a small application which is probably 1/10 or 1/100th the sie of FlightGear, this (supporting Python) was a truly massive undertaking to make these changes ... on the order of 2-3 months of pretty much non-stop effort. For FlightGear it would be almost insurmountable. I think it's an interesting topic to discuss in theory. We can point to examples and all the good things that python could bring to the table. However, we can't get around the fact that this could be a multi-year effort to do the conversion in a way that truly modernizes FlightGear and truly leverages all the good aspects of Python ... and during that 'under construction' period of a year or more, most of FlightGear would be broken. Edward came up with an alternative scheme where he built a python interface to the existing C++ property tree and some hooks to run python scripts, but still ... dropping nasal and converting to python requries porting AND carefully testing all the scripts though all their code paths and edge cases. Just that would be a massive undertaking, and it wouldn't be fair to just port the core nasal, and hang all the aircraft and scenery developers out to flap in the wind to figure it out for themselves.[4]

The balance is that Nasal is used a little in the core program, GUI, advanced weather, etc.. and a very lot in aircraft models. Nasal works well enough and removing it would be a massive undertaking. Although many people don't particularly like Nasal it is reasonably efficient and is very adapted to operations within FlightGear. Most contributors simply have yet to see a compelling reason to change; concurrency isn't even relevant until we have a properly threaded core, and garbage collection is not something commonly seen as a problem.

Removing Nasal will break a lot of aircraft models so it's not an option that can be seriously considered without a migration path. Some core developers would argue that there is overuse of Nasal aircraft side but it is what it is and we can't change that.

[5]

Future options

Coming up with some kind of unifying platform: A modern launcher UI (maybe even as a webapp) which can launch FlightGear, configure certain stuff (during FG running) and arrange communications with third-party processes implemented in Python or other languages. These would then manage scenarios, AI, maybe even input devices and aircraft systems. Of course, this would need a better integration of remote protocols into FG. The user wouldn't notice anything of the hidden processes, because the launcher/manager takes care of everything, even the spawning and killing of the auxiliary processes.[6]


The http interface that Phi uses is where I'd see a unified API growing from; but someone's got to be interested enough to do this. The main problem with a unifying platform IME is that it sounds ground but really doesn't mean much. Concrete proposals and offers of development assistance are what's needed; but adding another scripting language into the run time isn't a great idea; if anything we need to be able to provide a fully featured API available over HTTP that can be called via any platform. Switching to use Phi for more is probably a good idea; and certainly exposing more of the API is going to permit more things to be done there; but a launcher webapp would obviously require a standalone HTTP server running all the time; anyone fancy writing a FlightGear apache module -)[7]

There is work that lies ahead that would benefit FGPythonSys and FGNasalSys at the same time - such as a strong IPC mechanism, like HLA, or even just Emesary via remote properties (asynchronous remote properties and fgcommands, as per Torsten's mongoose/Phi work) - Torsten basically proved that you don't need to use HLA to come up with async modules that can interface with the rest of FG - if this, his, approach were to be formalied, standardized and extened, many other subsystems could be using this, none of which would be facing the challenges that Nasal/Python are currently facing (or in fact any other SGSubsystem not using SGthread, too).[8]

And I think that's really what Richard is hinting at when he refers to Phi, i.e. its back-end, not the front-end part - and the back-end could, and arguably should, be also shared/used by other UIs, including possibly PUI and/or a Canvas-based GUI. Unfortunately, for the time being, providing an alternative to Nasal, or even replacing it in its entirety would provide you withero benefits, due to the legacy FlightGear architecture, which would require major re-architecting to make this a worthwhile goal.[9]

FGPythonSys could benefit FGNasalSys and vice versa - but for most of this to happen, many implicit dependencies need to be detangled and cleaned up - which is why being able to entirely disable Nasal, and only init some bits of it, is a crucial part of the equation - even if you never again want to run a single line of Nasal code in your fgfs process, you need to come up with a way to still "boot" into a mostly functional fgfs environment.

[10]

References

References
  1. Beaver  (Oct 6th, 2016).  Nasal must go .
  2. Beaver  (Oct 7th, 2016).  Re: Nasal must go .
  3. Beaver  (Oct 6th, 2016).  Nasal must go .
  4. curt  (Oct 6th, 2016).  Re: Nasal must go .
  5. Richard  (Oct 6th, 2016).  Re: Nasal must go .
  6. Beaver  (Oct 6th, 2016).  Nasal must go .
  7. Richard  (Oct 6th, 2016).  Re: Nasal must go .
  8. Hooray  (Oct 6th, 2016).  Re: Nasal must go .
  9. Hooray  (Oct 6th, 2016).  Re: Nasal must go .
  10. Hooray  (Oct 7th, 2016).  Re: Nasal must go .