Board index FlightGear Development New features

FGPython an propose for Python as an nasal alternative

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Re: FGPython an propose for Python as an nasal alternative

Postby wkitty42 » Thu Jan 09, 2020 2:52 pm

i forget which python flavor this is for... python 2 or python 3? i ask because Py2 is frozen and being EoLed at some point in favor of Py3... i'm guessing Py3?
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Thu Jan 09, 2020 3:05 pm

Yep, in the CMake config I've set a minimum Python version of 3.3.

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

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Thu Jan 09, 2020 3:38 pm

It would be nice to see this getting committed, even just as an experimental build option to allow power users to tinker with it.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Thu Jan 09, 2020 6:10 pm

That might be an option. If it's not built by default and isn't part of the main distribution, it might sit better with the other core developers. The biggest impediments to it being turned on and in the core are:

  • Security: I'd probably need to fork Python and modify all file writing code paths to accept a filtering function (e.g. the simgear path checking function).
  • Listeners
  • Timers
  • $FG_ROOT/Nasal/*.nas: Either rewrite the lot in Python, or maybe add wrappers allowing Nasal to be run from Python?
  • No one else interested in contributing: This may, though very unlikely, be improved with some of the above being completed.

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

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Thu Jan 09, 2020 6:22 pm

how about, just remove/disable the controversial stuff for the time being, i.e. use a sandbox'ed environment ?
Also, while timers and listeners would undoubtedly come in handy, the first thing is probably property tree and fgcommand support
And since you're starting afresh it would then make more sense to use a 3rd party Python lib to do AJAX calls, since then you get all of this for free via Torsten's existing work, and it's even async
On top of that, it would be easy enough to add an Emesary layer to access the mongoose/httpd back-end to get/set properties, run fgcommands and then take it from there.

No need to reinvent the wheel or add stuff that we know is problematic - for instance, while the canvas stuff would undoubtedly be very handy, it'd be redundant to port/rewrite that, it'd make much more sense to fix up the C++ code to stop using that approach, as per the findings summed up at: http://wiki.flightgear.org/Canvas_Devel ... FlightGear

It doesn't make sense for us to continue adding more and more Nasal code that way, it would make much more sense to continue using the original approach via the property tree, because then all you need to use the canvas system is indeed property access (which I believe you have already) - and there is already an API to register new canvas elements from scripting space that way, so you can already instantiate/create and update a canvas without using any Nasal client-side, and even using a different thread/process - e.g. even just using telnet or a browser.

So, personally, I would be hesitant to make the same mistakes again - just provide an async property tree interface and a way to run fgcommands, at that point you can already use the Canvas system, even with python running in a worker thread
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Thu Jan 09, 2020 6:38 pm

Also, the very instant you have property tree and/or fgcommand support via Python, you can already run Nasal automatically - so I believe, that's the case, you just aren't aware of the details ?

Besides, the most logical thing to do at this point is not porting $FG_ROOT/Nasal, but looking at those areas in FlightGear that could highly benefit from this, and I think that's where Torsten's addon system would be the most shining example: it is straightforward to add a new "python mode" to it, so that new addons can be written in Python.

This could greatly benefit from the fact that there is backlog of missing features, it's just a new platform - i.e. it can be async by default and run outside the main loop, and it could even use the MPI approach that Emesary provides, which would give it a headstart over Nasal.

Another option might be allowing Python to be used to extend Phi (CGIs, scripting) - and then, there's the most obvious candidate: OSM2City, that contains so much Python code that the majority of contributors have been wanting to run inside fgfs for years, that it would be the lowest hanging fruit, if an async environment can be provided.

Nasal would be irrelevant here, and it would be hard to bring it up to par with Python here ... so that's what I'd consider talking about to be honest.

The way we've come to use $FG_ROOT/Nasal and how we've come to embed Nasal inside gui dialogs is hugely problematic, so there is more than just one lesson to be learnt here ... and personally, I would not even look at Nasal support for quite a while ... there are much lower hanging fruits, without having to do any grunt work.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Thu Jan 09, 2020 9:12 pm

Just quickly:

  • Async: This will never happen - the C++ property tree is not thread-safe and probably never will be (far, far too hard, far too much overhead, deadlocking nightmare, etc.)
  • I'm currently playing around with implementing listeners. This is simply for me to relearn the Python-C API.

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

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Thu Jan 09, 2020 9:17 pm

You missed my point, the point was not having an async property tree, but accessing the property tree from code that isn't running inside the main loop without threading issues, you can have that for free by using Torsten's mongoose work, are you familiar with the mongoosed/httpd interface to fetch/update properties and run fgcommands, this also works to run nasal code - so that timers and listeners are available automatically, too ?

Imagine it like the props/telnet mechanism, in other words you can use an arbitrary http library to implement out-of-process property tree access that way, got it ? :D

For the sandbox stuff, I'd suggest to check out

https://wiki.python.org/moin/Asking%20f ... Sandbox%29
https://wiki.python.org/moin/SandboxedPython


It might make sense to add some of these pointers to the wiki article so that relevant information is available there, too ?


PS: Feel free to merge my responses ;-)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Sun Jan 12, 2020 8:22 pm

To elaborate on this, for the time being Nasal is extensively used all over the place in FlightGear - and there are bindings for doing many things, so it would be difficult (and a ton of work) to provide a compelling Python alternative, even just to bring FGPythonSys up to par with Nasal.

However, Nasal has its shortcomings, too - especially the way it had to be integrated inside FlightGear at the time.

Thus, for FGPythonSys to "succeed", the point is providing a real incentive - so that people can use Python to do things for which they cannot use Nasal, but which they would normally have to patch/rebuild fgfs by using C++

In summary, the way Nasal is currently integrated inside FlightGear brings a number of restrictions with it, so if a FGPython environment were to address those, it could quickly become a pretty relevant option among people wanting to contribute to FlightGear, namely:

  • Nasal is currently restricted to a single global environment, i.e. there is no sandboxing for scripts running in different context (think aircraft scripts vs. scenery scripts vs. core/ui scripts)
  • Nasal cannot be used to extend the built-in telnet daemon to register new scripted telnet commands
  • Nasal cannot currently be used to register new canvas elements
  • it is not straightforward to run Nasal scripts outside the main loop
  • custom I/O protocols that require logic/heuristics (i.e. beyond what the generic protocol supports) cannot be implemented in Nasal, so that people use C++ instead
  • Nasal cannot be used for PagedLOD/scenery stuff, so that it would make sense to provide FGPython with such bindings
  • the Phi/mongoose back-end supports CGIs, but requires C++ to add such functionality, there is no support to run Nasal based CGIs to extend Phi server-side
  • addons are exclusively Nasal for the time being, but would provide an excellent opportunity to use Python inside FlightGear in future addons
  • An Emesary bridge would mean that PythonSys could access Nasal and vice versa

One of the lowest hanging fruits would be providing the equivalent of the addcommand() API so that Python functions can be registered as fgcommands.

So while Nasal is indeed almost everywhere, there are a number of places where it cannot be currently used, so that providing Python support there could be a huge technology enabler, even without having to port much/any of the existing functionality.

So there is no need to repeat all the mistakes that were made when Nasal got integrated, it makes much more sense to explore what it'd take to conquer those areas for which Nasal isn't currently available.

Being able to run parts of osm2city inside FlightGear via the addon API in a background thread would surely be a huge killer application for Python, and could very well spell the end of Nasal, if done properly ...
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Previous

Return to New features

Who is online

Users browsing this forum: No registered users and 7 guests