Board index FlightGear Development Nasal

Nasal must go

Nasal is the scripting language of FlightGear.

Nasal must go

Postby Beaver » Thu Oct 06, 2016 1:42 pm

I like FlightGear a lot, and have spent countless hours learning to fly various aircraft. I'm not involved in FlightGear development, so I might not be the best person to tell you this, but here goes:

Nasal must go!

Nasal is indeed a versatile scripting language and a great piece of work. At the time it was created, in 2003, it was arguably the best choice to go forward as a scripting language.

But times have changed. CPUs and GPUs have been getting faster. PCs have more than one core, Windows has become a serious operating system. Users have more than one device. Machine Learning has become a thing. "Scripting" languages like Javascript, Python and Lua have not only matured, and have gotten ridiculously faster, but they are now often used to run software in their own right, not just as extensions.

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

I know FlightGear can't just ditch Nasal. Bringing another scripting language into the fold would certainly be a big undertaking. I have done some experimentation around using Python's asyncio with the websocket API (which is faster than the telnet btw), and if I were to write an extension I would probably use this approach. It means I can use the whole scientific python stuff (for example GIS, but also machine learning), and have all my processing in a separate process. It's conceivable to implement AI planes, virtual instructors, missions and much more with this. Even for aircraft systems I see some advantages. I've been perpetually frustrated with setting up my input devices for flight gear, and thinking about writing scripts to circumvent the clumsy configuration system in FG. Using different configurations for different aircraft is also a pain point, but that's another story.

The GUI in FlightGear is crap. This is also understandable, since FlightGear is a very old multi-platform Application. Nasal doesn't have bindings to things like GTK, nor was GTK on Windows an option back then. WebUI wasn't a thing back then. Yet another thing which could be better, if FlightGear adopted a modern scripting language into the core, or a better integration with external programs.

The 3D software package Blender, as a comparison, is an open source project even older than FlightGear, plagued by very similar problems. It's mainly written in C, but it is under much more active and agile development than FlightGear. Part of this, of course, is that there are more commercial resources involved. But another big part is that Blender chose Python as its extension language, and with Python improving over 20 years, the C code base and Python extensions are a killer combination.

As a user of FlightGear and as a Python developer with the occasional improvement idea I find myself frustrated by having to shave too many yaks. One of my wishes would be 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.

Let me know what you think about it. Again, I don't want to bash on Nasal or the FlightGear project, I just wanted to vent some frustration and fantasize about a way out of it.
Beaver
 
Posts: 17
Joined: Mon Dec 21, 2015 3:27 pm

Re: Nasal must go

Postby Thorsten » Thu Oct 06, 2016 2:22 pm

Again, I don't want to bash on Nasal or the FlightGear project


Really? Then I must have misunderstood

Nasal must go!


In any case, arguments have been exchanged ad nauseam, please read them up before starting discussions from scratch.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Nasal must go

Postby Beaver » Thu Oct 06, 2016 2:41 pm

There may have been arguments. I did not find them in a superficial search of the topic. Typical forum arrogance like "we've discussed this before, shut up, new guy" is not a good argument I think. What's wrong with either pointing out the old threads or starting a new discussion?
Beaver
 
Posts: 17
Joined: Mon Dec 21, 2015 3:27 pm

Re: Nasal must go

Postby bugman » Thu Oct 06, 2016 3:29 pm

Beaver wrote in Thu Oct 06, 2016 1:42 pm:Machine Learning has become a thing.


I would say that machine learning came and went already. I remember support vector machines coming along and crushing neural networks. But that was many years ago and I haven't heard much about them since, despite all the promise and hype. Maybe you should be looking into new types of flight dynamics models using genetic algorithms instead ;)


"Scripting" languages like Javascript, Python and Lua have not only matured, and have gotten ridiculously faster...


My own personal experience is that Python is now much slower. Things were really much, much faster back in Python 1.5! I just ran this quick test:

Code: Select all
[edward@localhost ~]$ time python1.2 -c "for i in xrange(10000000): i+1"

real    0m2.050s
user    0m2.003s
sys     0m0.001s
[edward@localhost ~]$ time python1.3 -c "for i in xrange(10000000): i+1"

real    0m1.950s
user    0m1.946s
sys     0m0.001s
[edward@localhost ~]$ time python1.4 -c "for i in xrange(10000000): i+1"

real    0m1.505s
user    0m1.461s
sys     0m0.001s
[edward@localhost ~]$ time python1.5 -c "for i in xrange(10000000): i+1"

real    0m0.810s
user    0m0.810s
sys     0m0.001s
[edward@localhost ~]$ time python1.6 -c "for i in xrange(10000000): i+1"

real    0m0.909s
user    0m0.907s
sys     0m0.001s
[edward@localhost ~]$ time python2.0 -c "for i in xrange(10000000): i+1"

real    0m0.863s
user    0m0.862s
sys     0m0.000s
[edward@localhost ~]$ time python2.1 -c "for i in xrange(10000000): i+1"

real    0m1.369s
user    0m1.002s
sys     0m0.001s
[edward@localhost ~]$ time python2.2 -c "for i in xrange(10000000): i+1"

real    0m1.196s
user    0m1.076s
sys     0m0.005s
[edward@localhost ~]$ time python2.3 -c "for i in xrange(10000000): i+1"
python2.3: error while loading shared libraries: libtermcap.so.2: cannot open shared object file: No such file or directory

real    0m0.001s
user    0m0.000s
sys     0m0.000s
[edward@localhost ~]$ time python2.4 -c "for i in xrange(10000000): i+1"

real    0m1.166s
user    0m0.703s
sys     0m0.002s
[edward@localhost ~]$ time python2.5 -c "for i in xrange(10000000): i+1"

real    0m0.875s
user    0m0.667s
sys     0m0.003s
[edward@localhost ~]$ time python2.6 -c "for i in xrange(10000000): i+1"

real    0m0.943s
user    0m0.745s
sys     0m0.002s
[edward@localhost ~]$ time python2.7 -c "for i in xrange(10000000): i+1"

real    0m0.891s
user    0m0.889s
sys     0m0.002s
[edward@localhost ~]$ time python3.0 -c "for i in range(10000000): i+1"

real    0m1.589s
user    0m0.975s
sys     0m0.009s
[edward@localhost ~]$ time python3.1 -c "for i in range(10000000): i+1"

real    0m1.236s
user    0m0.861s
sys     0m0.009s
[edward@localhost ~]$ time python3.2 -c "for i in range(10000000): i+1"

real    0m1.209s
user    0m0.841s
sys     0m0.010s
[edward@localhost ~]$ time python3.3 -c "for i in range(10000000): i+1"

real    0m1.011s
user    0m0.697s
sys     0m0.005s
[edward@localhost ~]$ time python3.4 -c "for i in range(10000000): i+1"

real    0m1.067s
user    0m0.985s
sys     0m0.007s
[edward@localhost ~]$ time python3.5 -c "for i in range(10000000): i+1"

real    0m1.383s
user    0m0.675s
sys     0m0.007s
[edward@localhost ~]$


Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Nasal must go

Postby Thorsten » Thu Oct 06, 2016 3:37 pm

Typical forum arrogance like "we've discussed this before, shut up, new guy" is not a good argument I think.


I'm not really interested in exchanging arguments with people who start their points with provocations like 'Nasal must go'. If you want to vent your frustration, please do it elsewhere.

As I said, long arguments have been exchanged both here and on the mailing list - just read them up.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Nasal must go

Postby Alant » Thu Oct 06, 2016 4:00 pm

Just Google flightgear python.

The first result is this http://wiki.flightgear.org/Python_in_FlightGear.

Also do you expect people to respond nicely to such a rudely worded post?
Alant
 
Posts: 1219
Joined: Wed Jun 23, 2010 6:58 am
Location: Portugal
Callsign: Tarnish99
Version: latest Git
OS: Windows 10/11

Re: Nasal must go

Postby Octal450 » Thu Oct 06, 2016 5:07 pm

I find Nasal to work quite well. I like it.
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Re: Nasal must go

Postby curt » Thu Oct 06, 2016 5:39 pm

Hi Thorsten,

i'm pretty sure the original poster was simply using an "eye catcher" technique for the subject. It's clear from his tone that he wishes to engage in a positive discussion of these topics. I think when you said "Then I must have misunderstood", you really did read the original message too hastily and really did misunderstand.

Maybe not everyone noticed that FlightGear's rudimentary gui is written all in opengl so it works fine in full screen and doesn't need tricky interactions with the underlying OS (the details of which often vary wildly from one OS or window system to the next.) Qt has taken great strides in lowering this barrier and James is a Qt expert, but it's still a massive amount of work with a lot of build/dependency implications to convert a whole gui system (and test all the edge cases.)

Python is a personal interest of mine. I have my own separate UAV autopilot app that used the FlightGear property system. Last winter I redesigned the property system to be based on python core code and built a C++ interface to the python-property system. In the process I took the opportunity to fork off my direction and make substantial changes to my own property system API. However, this required going and porting all my code to the new property system api and testing it. Recently I added json support so that the config files can be json instead of xml. This has some advantages and I found that json mapped a whole lot more naturally to my new python-based property system. The json load/parse/save code is probably half the lines of code compared to the equivalent xml load/parse/save code.

The advantage of a python-based property system is that now embedded python scripts have native access to the property tree and can run any time and read/write values directly. I find this has is a very very powerful approach that enables freely mixing C++ and python modules. It enables me to rewrite big chunks (non-performance critical chunks) of my flight controller in native python. That leads to maybe 50% code reduction, clearer code, simpler code, etc. I also discovered that python's standard library of tools is conceptually very similar to SimGear. For every SimGear library or module, there's almost always a similar if not equivalent python module available to import.

So I like python for non-performance critical coding ... however ...

It is really important to note that in my small application which is probably 1/10 or 1/100th the size of FlightGear, this 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.

So discuss away, but keep in mind these changes (when done right) are a massive undertaking that will break flightgear at it's core until we emerge from the other side with everything working.
Aerospace Engineering and Mechanics
University of Minnesota
curt
Administrator
 
Posts: 1168
Joined: Thu Jan 01, 1970 1:00 am
Location: Minneapolis, MN

Re: Nasal must go

Postby Thorsten » Thu Oct 06, 2016 5:56 pm

It's clear from his tone that he wishes to engage in a positive discussion of these topics.


Forgive me for being wary of people with no strong track record of contributions telling everyone else exactly what needs to be done for FG - I've seen a fair share of them by now and I do not sense a positive discussion on the horizon.

On the subject of Python, I've said my piece several times elsewhere, and as you know I don't think it's a good idea for a couple of reasons.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Nasal must go

Postby bugman » Thu Oct 06, 2016 6:03 pm

Well, I would say that the focus of the efforts in my experimental FGPythonSys branches is more to provide a Python interface to core FlightGear programming rather than replace Nasal. For example one aim is to convert the whole of the SimGear programming interface (API) into a Python library. Another is to expose the subsystem interface to allow for Python modules to create new FlightGear subsystems. As a bizarre aside, if FGPythonSys was designed to replace Nasal, it would also be able to fully replace the XML parts of aircraft as well.

In any case, I have been a bit busy with RL and there is no one helping in the task of advancing FGPythonSys. So at this rate, replacing Nasal with Python will only be a pipe dream for a few content developers.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Nasal must go

Postby Octal450 » Thu Oct 06, 2016 6:04 pm

Plus removing nasal will destroy tons of hours of effort programming, and break every single plane in FGFS.

bugman
I'm all for that, as long as the props stay the same, so the planes keep working.

I actually think the GUI is not bad, I don't think how the menus and so on look is important. How the planes and the Sim look is much more important.
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Re: Nasal must go

Postby Richard » Thu Oct 06, 2016 6:19 pm

Beaver wrote in Thu Oct 06, 2016 1:42 pm:Nasal is indeed a versatile scripting language and a great piece of work. At the time it was created, in 2003, it was arguably the best choice to go forward as a scripting language.


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 I don't particularly like Nasal it is reasonably efficient and is very adapted to operations within FlightGear. I 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 I've 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. I'd argue that there is overuse of Nasal aircraft side but it is what it is and we can't change that.

Beaver wrote in Thu Oct 06, 2016 1:42 pm:...
One of my wishes would be 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.


This section is more interesting and not really related to Nasal.

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 -)
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Nasal must go

Postby bugman » Thu Oct 06, 2016 6:31 pm

Thorsten wrote in Thu Oct 06, 2016 5:56 pm:Forgive me for being wary of people with no strong track record of contributions telling everyone else exactly what needs to be done for FG - I've seen a fair share of them by now and I do not sense a positive discussion on the horizon.


People will always have fantasies. Unless they are willing to get their own hands dirty, you may as well leave them in their fantasy world ;) You never know though, maybe one day one of the day dreamers will stop fantasising and contribute something useful.

it0uchpods wrote in Thu Oct 06, 2016 6:04 pm:Plus removing nasal will destroy tons of hours of effort programming, and break every single plane in FGFS.


Well, the subject of such threads is in the realm of fantasy. So continuing along such a line, one could envisage an automatic Nasal -> Python conversion tool being implemented. Obviously such a tool will not give you the optimal Python code for your aircraft - you'd have to manually work on a more ideal solution yourself - but it would be functional.

I actually think the GUI is not bad, I don't think how the menus and so on look is important. How the planes and the Sim look is much more important.


The plan is that the GUI will eventually change from PUI to to Qt (it's only a question of when, rather than if). This is all rather cosmetic though, as you mention, and irrelevant to end users.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Nasal must go

Postby bugman » Thu Oct 06, 2016 6:34 pm

Richard wrote in Thu Oct 06, 2016 6:19 pm:Removing Nasal will break a lot of aircraft models so it's not an option that can be seriously considered without a migration path.


Continuing with the pure fantasy, you would have an on-the-fly Nasal to Python converter for legacy systems ;)

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Nasal must go

Postby Thorsten » Thu Oct 06, 2016 6:34 pm

Well, the subject of such threads is in the realm of fantasy. So continuing along such a line, one could envisage an automatic Nasal -> Python conversion tool being implemented.


Changing 40.000 lines of code I'm familiar with into 40.000 lines of unformated code I'm not familiar with and can no longer effectively maintain - thanks but no thanks...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Next

Return to Nasal

Who is online

Users browsing this forum: No registered users and 7 guests