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 Hooray » Fri Feb 19, 2016 5:07 pm

(If the code memory foot print is stable, and if the performance is fast enough, then what other reason is there to object?


what kind of latencies are you seeing using this approach - i.e. assuming everything is single-threaded and using the standard Python interpreter (GIL) - just asking because this kind of control problem (autopilot/PID stuff) is generally considered inappropriate for scripting where a non-deterministic garbage collection scheme may make things rather unpredictable - in fact, that is the reason why we generally recommend people not to use Nasal for this sort of thing, but instead opt for C++ code, or at least using property rules (which is basically C++ code on top of a property wrapper).

I realize that you are "just" using a native Python property tree here instead of David's original SGPropertyNode code - but I can't help but wonder why you have decided to move away from native code to scripting (for an actual/real UAV project), whereas the general recommendation for aircraft developers doing simulated aircraft is to use native code instead of scripted code - which kind of matches Thorsten's usual recommendation to look at where performance really matters and use the more accessible technologies otherwise...

You mentioned the code/memory footprint, whereas the most common use cases in FlightGear are adding roughly 16-20 MB of Nasal related memory footprint (all naPools() added up), and the real problem is one of runtime latency, and specifically the non-incremental mark/sweep GC.

In other words, depending on your findings, some of your work could translate into a shift of thinking when it comes to use of scripting in FlightGear - given that you are not just controlling a virtual aircraft but a real one using this scripted approach.
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 curt » Fri Feb 19, 2016 8:50 pm

Hi Hooray:

Latencies and determinism. I'm seeing a rock solid 100hz on the target hardware which is my goal. On a beaglebone I'm seeing about 20% cpu utilization (read lots of headroom if something does run a little long.) I have put a *lot* of thought and study into timing issues (these are a really huge issue at the University of Minnesota Aerospace Eng. department where I work. For some projects we can tolerate latency, but we can't tolerate time jitter or indeterminism.)

Memory footprint. The current footprint for the entire autopilot code (C + python) is 12,784 Kib (about 13Mb). This is roughly 2% of the beaglebone's available memory. This number never changes, never grows, even after running for a 100 hours straight. This is on a 32 bit cpu though, I imagine larger numbers on a 64 bit system.

My autopilot system is not threaded, but it is distributed. I pick those words very carefully and they are packed with meaning and implications. So all the things that normally would require hard real time (sensor IO and actuator IO) are handled on a separate cpu written with 'interrupt service routine' style code (arduino). The main autopilot code then simply has to make sure it fires off at exactly 100 hz and never over runs it's time allotment.

Speaking of my own feelings (and not expecting to convince others who feel differently): I believe for most situations, threads are a design "choice". They are not a need. There is a big downside and risk to threaded architectures when it comes to maintenance, understandability, new coders poking around inside, hiding bugs that are obscure and hard to reproduce, etc.

My system ('my' referring to origin, not ownership) is built on two simpler programs vs. one larger more complex threaded program. Much of this comes down to choices and design philosophy and I'm really trying to keep my system simple. If someone wants an extravagant autopilot architecture that supports every sensor, every embedded board, every idea, and does so with elaborate threading infrastructure, and elaborate layers upon layers, there are other better options to choose from. :-)

As an aside: heavily threaded systems often have many independent free running loops in the chain of information passing. This can lead to a large amount of indetermism and end-to-end latency no matter what language you are coding in. There are ways to address this ... like having each thread in the logical processing chain waiting for the thread before it to finish so it can get the intermediate result as quickly as possbile, but the danger there is that you may have just implemented a single thread architecture via a complex series of threads and wait condition ... which I've seen that exact thing done, and then argued that it was superior in every way because it was threaded, and all I could get out of my mouth was: "but, but, but ...." Sometimes the loud dogs rule real life, just like on the forums. :-)

So anyway, I probably have far less python than FlightGear has nasal, so I don't know if any of this translates over to FlightGear or not. It could still be apples to oranges. This would be a pretty poor data point to apply to the flightgear nasal vs. C vs. performance vs. cpu vs. graphics card vs. hooray vs. thorsten debate that remains unresolved.

I haven't seen the python garbage collector bite me in the same way that the nasal garbage collector injects stutter in flightgear's frame rates, but ... I haven't studied that exhaustively (?)

For me, in the end it boils down to can I do everything I need to do in a rigid 100hz time frame and so far the answer is yes, no problem. If I can expand my python usage and still have the answer be no problem, then that makes my code simpler and more flexible, and more accessible to others. (Python being the language of the gods as we all know.) I'm just kidding ... mostly. If someone asks, "but what if you end up in that other place", my response is that I'm also studying java. :-)

Please don't extrapolate too much of my little side experiment into the large FlightGear / Nasal performance analysis.

Regards,

Curt.
curt
Administrator
 
Posts: 1168
Joined: Thu Jan 01, 1970 1:00 am
Location: Minneapolis, MN

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Mon Feb 22, 2016 6:00 pm

bugman wrote in Fri Feb 19, 2016 2:57 pm:Just a quick update on the FGPythonSys experiment, I have pushed some new branches based on 2016.2.0


FWIW, with gitorious topic repositories being available again, I should still have an old topic branch that disabled FGNasalSys entirely - i.e. the fg_init.cxx, but also the roughly ~10 places where a handle (pointer) to the FGNasalSys instance in the SGSubsysmMgr is acquired to run some Nasal code on demand (think GUI, joystick, keyboard, AI/scenery stuff).

In and of itself, that will obviously not be particularly useful, because fgfs is rather "crippled" with so much of its (current) UI/aircraft functionality tied to Nasal code all over the place, but it may still be interesting for the FGPythonSys effort, because it provides a good baseline for fgfs performance without _any_ Nasal code running at all, including obviously GC issues - even if only to illustrate (and prove) that FlightGear is still suffering from resource leaks and race conditions that have nothing to do with Nasal.

In other words, this is something where FGPythonSys and FGNasalSys could benefit eachother in the near term, while providing benefits for FG in the long term.

If you are interested in that, I can dig out the topic branch/patches so that you can (optionally) disable Nasal in your FGPythonSys build (even if just for regression testing purposes).

IIRC, it's only touching ~10-12 files and 50 lines of code - i.e. anything accessing FGNasalSys* must do a NULL pointer check and then use SG_LOG(SG_NASAL, SG_ALERT, "Nasal disabled"), and fg_init.cxx must to a fgGetBool() check in the postInit hack to disable the creation of the FGNasalSys instance
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 » Mon Feb 22, 2016 6:16 pm

Sure, that could be quite useful for experimentation purposes, unit testing, and maybe coming up with a FGScriptingSys base class. I'm currently trying to set up a development environment in MS Windows 7 on a VM to make sure all of the cppunit/r* and python/r* branches are functional there too (which is unfortunately not the case yet). It's tough to do - most of the wiki instructions for the build environments are written for power-users rather than developers.

Cheers,
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 » Mon Feb 22, 2016 8:09 pm

Okay, I will look for the patches and rebase/update them if necessary, so that you can add a "non-Nasal" mode to your FGPythonSys branches.

Regarding FGScriptingSys, my suggestion would be to encapsulate common logic there, which may include the registration of APIs, i.e. those depending on certain subsystems being around (or not).

This may also include the registration of scripting-system specific folders in the base package (think $FG_ROOT/Nasal and $FG_ROOT/Python)

Ideally, we would not just have a startup mode with scripting disabled, but also with just scripting (and nothing else) running.

Concerning the larger issue of keeping unrelated scripts separated (i.e. for better reset/re-init and concurrency support), we could implement FGScriptingSys so that it provides APIs for different "scopes" of scripts (core/GUI, aircraft, scenery, others) - which in the case of FGPythonSys, may mean that different sub-interpreters are used (running in a separate thread)

PS: As far as I understand, most Windows folks tend to use the cmake Superbuild (wiki) to build FG
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 » Tue Feb 23, 2016 4:11 pm

Ok, I have added the patch to the wiki for now: http://wiki.flightgear.org/Howto:Disabl ... rely#Patch

This is fg-only, i.e. not fgdata patch - which means that there's no options.xml mapping - so that you can simply use a property to prevent the initialization/use of the FGNasalSys subsystem, e.g. via --prop:/sim/startup/disable-nasal=1

I ended up using that a while ago to do some performance related troubleshooting and to be on the safe side with regard to Nasal and particularly its GC.

It's simple enough and should be easy to extend, e.g. so that Nasal could be shut-down and restarted, too.
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 » Tue Feb 23, 2016 5:04 pm

That patch looks quite useful from a debugging perspective! If you're not going to do it, would you mind if I set it up later for a merge request? Apart from indentation, it looks pretty clean.

Regards,
Edward


Edit: I would suggest shifting the NASAL_DISABLED() macro into simgear though.
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 » Tue Feb 23, 2016 5:18 pm

I am not planning on coming up with any merge requests - the patch was intended really just for debugging purposes, it will be of little use to the average user - and I guess that probably not even most power users would have a use for it.
In its current form, all it will do is "cripple" FlightGear rather severely by disabling all Nasal initialization and any Nasal related features - I just used this as a "baseline" for performance related troubleshooting, so I didn't actually review the features I disabled - e.g. if there are any code paths that I missed - my sole motivation was removing Nasal to see if there are still certain problems without Nasal running at all.

So if this is put up for being merged, it would need be reviewed to ensure that I didn't break the default mode, i.e. with Nasal enabled - because that was never the focus of the patch, and I haven't looked at it in months (years) - I really just remembered when I was browsing through the restored gitorious branches lately, and thought that it could be helpful for FGPythonSys, but also any regression testing to "eleminate" Nasal from the equation - especially because there seems to be the knee-jerk reaction of always pointing to Nasal and its GC when performance problems show up.

So feel free to do with it whatever you want - no matter if that means cleaning up things (indentation) or moving macros around. I ended up putting the macro there so that it gets automatically included by all sources loading NasalSys.hxx - and it's self-contained that way.

If I were reviewing something like that, my suggestion would be to turn the whole thing into a function/method as part of SGSubsystem, so that arbitrary subsystems can be enabled - which would include moving the fgGetBool() logic to the constructor, too - i.e. by adding a simgear::propertyObject<bool> to the protected part of SGSubsystem - because there are clearly other subsystems that would benefit from being optional, not just Nasal.

Basically, whatever is using a subsystem pointer without doing a NULL pointer check first is buggy code in the context of reset/re-init and optional subsystems ...

Anyway, thanks for taking an interest - consider it being in the "public domain", regardless of what you want to do with it or not :lol:

PS: a merge request would need to include the options.cxx and fg_init.cxx logic to expose this as a startup option (like you did with FGPythonSys) - besides, zakalawe would probably want this to be updated to use his new templated subsystem helpers.

PPS: If this gets reviewed/updated and possibly merged, the init message should be extended to also suggest using telnet and/or Phi to interact with the simulator, because most PUI features are using embedded Nasal ATM - and that obviously also applies to Canvas stuff.
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 » Tue Feb 23, 2016 5:53 pm

I checked the patch, in its current form it cannot be committed "as is", because it does not deal with scenery/tile related Nasal hooks, i.e. those using NasalModelData* - which is primarily the scenery/tile manager code, AIBase and the CanvasMgr stuff.

Those are the locations that would need to also use a FGNasalSys NULL pointer check and skip the execution of the corresponding portions of the code.

I never ran into this because I used the minimal startup profile (as per the wiki) to do the corresponding troubleshooting, with AI and scenery/terrain stuff also disabled entirely.

Like I said, it wasn't really intended to be used "as is" - you definitely need to know what you're doing. Apart from that, someone using this "mode" would obviously also understand where a FGNasalSys related segfaults come from with Nasal disabled ;-)
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 » Tue Feb 23, 2016 6:20 pm

Actually my thinking is along these lines - these are exactly the same types of changes I was thinking of for fully decoupling all the various parts of FlightGear for use in a CppUnit-based test suite ;) Something for the future though.

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 » Tue Feb 23, 2016 6:45 pm

Indeed, this is something that David Megginson (property tree/SGSubsystem*) originally was planning according to the structure of SGSubsystem - ideally, many more subsystems would use this structure, while also becoming optional during initialization.

A while ago, James Turner was contemplating to introduce "run-levels", that was prior to his reset/re-init work: http://wiki.flightgear.org/FlightGear_Run_Levels

http://wiki.flightgear.org/FlightGear_R ... te_note-11
James Turner wrote:As an additional enhancement, subsystems could be notified of all run-level changes above their threshold. This would solve the Nasal issue; starting up the interpreter (the first part of FGNasalSys::init) can be done very early (and quickly), and the subsytem would then wait for a relatively high-valued 'init' call before running scripts (the part that needs all other properties to be defined).

In the even longer run, we'd actually want to associate the Nasal scripts with run-levels (/etc/rc.d, anyone?), since the frontend GUI might want a few scripts loaded, while I assume most are only relevant when actually flying. Such a change also makes postinit() unnecessary, I think - since the effect can always be achieved by having init() watch for a higher run-level.


Since then, he began implementing reset/-reinit and the subsystemFactory, which could be considered to be the foundation for "run-levels", i.e. by making subsystems better configurable and optional.

As you can see by the pointers on the wiki (quotes...), all this was originally motivated by the need for having an integrated UI - in fact, originally, the idea was Nasal, and later on Canvas, for that - which caused the creation of the Aircraft Center: http://wiki.flightgear.org/Aircraft_Center

As you know, quite a few things have changed since then, i.e. the addition of Qt5, so that Nasal/Canvas are no longer favored for this sort of thing - however, the reset/re-init, and the related subsystemFactory work remain relevant even if Qt5 were to be accepted as a mandatory build time depencency.

Sometime later, we discussed the idea of adopting Torsten's FGPanel approach, by coming up with something like "FGCanvas", i.e. a minimal subset of FlightGear subsystems and Nasal obviously, which was also inspired by James, with the difference of being a custom fgfs startup mode instead of a different/downstripped codebase: http://wiki.flightgear.org/FGCanvas

Subject: FGPanel: standalone panel rendering
zakalawe wrote:
Torsten wrote:fgpanel is the 2d-panel code from flightgear wrapped into a simple standalone application being able to display 2d instruments on very simple hardware with basic OpenGL support. Find my sources dropped here:
http://www.gitorious.org/flightgear-pmpt/panel

Off-topic, but I am going to be overhauls the 2D panels / displays code in the near future, and was planning to create exactly the same idea - a standalone app that can run a single panel - good to know the idea works! (I'm also planning to internally port the 2D panel code to the new system, but that should be invisible to most people)


James Turner wrote:http://www.mail-archive.com/flightgear- ... 17266.html
If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself - and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than sending per-frame pixel surfaces over shared memory or sockets / pipes.

http://www.mail-archive.com/flightgear- ... 37441.html
Creating a 'fgcanvas' client analogous to 'FGPanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend.

http://sourceforge.net/p/flightgear/mai ... /31380390/
more useful would be to get ARM working so we can run parts of the stack on Pis, Pandaboards and so on. This would be materially useful for various add-on functions, especially the canvas and fgcom. (I spend an increasing amount of my work time on OpenGL on ARM platforms, they have plenty of power to run graphics, depending on which GPU is on the SoC)


As you can see now, there's some kind of "holistic vision" that some people have been having for the better part of the last decade ... much/most of this never made it onto the "update project roadmap", but it's obviously been consistently worked towards over time, and given the degree of activity by those involved, it used to be pretty safe to "bet" on these developments.

these are exactly the same types of changes I was thinking of for fully decoupling all the various parts of FlightGear for use in a CppUnit-based test suite ;) Something for the future though.

James and others are definitely also interested in this sort of thing, for a collection of relevant pointers, see: http://wiki.flightgear.org/FlightGear_Headless

James Turner wrote:The position init code is a little complex, to allow for starting on a carrier and some other cases, and ideally we would do it from script, but unfortunately there's some technical limitations on doing that. (Not insurmountable, but not quick either). Adding more cases to the position-init code is certainly doable - one suggestion I made some time ago, is when MP is active, to default to starting at a free parking position instead of on a runway. (When no startup position is provided at all).


The remarks on using scripted initialization (rather than hard-coded logic in fg_init.cxx) is obviously in line with efforts to have better regression testing in FlightGear, making more subsystems optional/restartable (reset/re-init), and to make scripting available much earlier: http://wiki.flightgear.org/Initializing_Nasal_early

Thus, I think that none of this would necessarily be specific to just FGPythonSys (or FGNasalSys), it is definitely in line with long-standing ideas/wishes of some of the key contributors behind the project, e.g. referring to:

http://sourceforge.net/p/flightgear/mai ... /33226290/
I am wishing I could easily add tests for the route-path / GPS code, but anything that needs ‘globals’ is hard to test in isolation.


If done properly, you would ultimately end up with a codebase where "fgpanel", "fgviewer" (and possibly fgcanvas) would merely be "startup modes" of the same underlying fgfs binary using a combination of different subsystems - not unlike a Linux system with different "run-levels" :wink:


PS: I fixed up the patch on the wiki, but tested it only briefly at KSFO...
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 » Tue Feb 23, 2016 7:19 pm

Hooray wrote in Tue Feb 23, 2016 6:45 pm:Thus, I think that none of this would necessarily be specific to just FGPythonSys (or FGNasalSys), it is definitely in line with long-standing ideas/wishes of some of the key contributors behind the project, e.g. referring to...


That is why I have some Python-free cppunit/r* branches up and running. I'm slowly setting up for myself a Win64 VM msvc14 build environment to make sure that this runs on the major OSes, fixing up a few issues along the way, and then I'll offer it up on the mailing list. Such a test suite will really help catalyse these decoupling changes.

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 » Tue Feb 23, 2016 7:45 pm

Regarding the larger issue of building *for* Windows, we've been maintaining a separate article on the wiki with instructions on using a mingw/gcc cross compiler on Linux to provide Windows binaries - the focus there was primarily building osgEarth-based software, but mxe (on github) is definitely popular enough to also be turned into a jenkins compiler plugin.

Aside from that, I think you are right that this work could definitely help catalyze work that may seem otherwise unrelated at frst glance - e.g. we keep seeing statements on the devel list about people wanting to decouple/untangle subsystems to end up with a fast renderer-only main loop, despite the exact same people making changes that are basically conflicting with the corresponding groundwork to make that happen, i.e. stuff that makes reset/re-init and optional subsystem-reinitialization increasingly difficult (e.g. due to non-standard C++ constructors or weird inter-dependencies, lack of memory management/raw pointers etc).

It is a bit unfortunate realizing how the SGSubsystem* and SGPropertyNode groundwork was definitely prepared with the vision to make that all possible/happen (including the APIs to save/load and resume flights), whereas actual core development took place without any oversight that would ensure that these APIs are actually used, which even can be seen on the updated project policy document, which does not mention all the underlying groundwork that needs to take place before HLA can be considered a viable option.

For instance, the APIs to save/load and resume flights were actually disabled in response to new code (at the time) that broke that feature: http://wiki.flightgear.org/Fixing_Presets

Which is one of the reasons why some people have been contemplating to move the "presets" work to scripting space, i.e. help clean up fg_init.cxx and make scripting available much earlier.

Thus, it does make sense to look at these efforts without any particular feature like Nasal or Python - especially, because this important groundwork is really only handled by a single person primarily, and it may easily turn out to take yet another decade if that person should have to reconsider his FG involvement...
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 » Wed Feb 24, 2016 4:07 pm

Referring to (disabling Nasal entirely via a command-line switch): http://wiki.flightgear.org/Howto:Disabl ... rely#Patch

I have updated the patch to use the recently added template-based get_subsystem<SGSubsystemChildClass> getter and as far as I can tell, it is working correctly - if you, or anybody else, should run into issues - feel free to get in touch so that I can fix up the patch accordingly.

But like I said, in its current form, it is really just intended to help with troubleshooting/regression testing, and should probably not be made available to the average end-user (I would not document it via options.xml personally) - that may change however, if/when an additional scripting language (like FGPythonSys) becomes available - of if/when the existing UI scheme becomes sufficiently decoupled from Nasal and the implicit assumption of always having all subsystems available - right now, the FG UI is rather crippled without Nasal due to all the PUI/Nasal stuff no longer working obviously.

Torsten briefly touched on the underlying idea of coming up with abstract UI APIs and using message passing for that purpose:

Torsten wrote:https://sourceforge.net/p/flightgear/ma ... /32325866/
I know that James is working on an extension of the websocket interface
to allow get and set for properties.

https://sourceforge.net/p/flightgear/ma ... /34792963/
Communication with FGFS runs via websocket and the
http/fgcommand interface. I don't miss a single feature and everything
works as one would expect. I would assume, the same technique would be
possible with Python or any other scripting language that supports
websockets, http-get, http-post and has some support for JSON (python has,
ruby has, lua has).

https://sourceforge.net/p/flightgear/ma ... /34534324/
What I was talking about was to have most of the logic extracted out of the
UI implementation. How many properties do we have to write to to switch
from AW to BW? Nothing a UI should know about. A service
"GetAvailableWxEngines" and "SelectWxEngine" should do the job.


Given my familiarity with the Nasal, PUI and Canvas subsystems - this is something that would also work for the existing UI scheme, i.e. by dispatching fgcommands and setprop/getprop calls via websockets/AJAX and using only abstract interfaces otherwise - note that Nasal already has http access, i.e. that would be a good way to have a functional UI without necessarily requiring Nasal running in the main loop.

For FGPythonSys, this may be the most straightforward, and least invasive, way to hook up Python scripts to the main property tree and its main rpc mechanism (fgcommands), without having to worry about threading at all, because all those requests would be transparently dispatched by the underlying mongoose httpd engine - the good thing is that there are tons of websocket wrappers for Python available, and if I were doing this sort of thing, I would definitely consider adding the corresponding dependency to $FG_ROOT/Python, so that Python scripts can directly access properties via websockets and run fgcommands via RPC.

Personally, I think that this is the most compelling approach to integrate things without having to re-architect the FG main loop for now. And it would nicely align with ongoing efforts (Torsten's mongoose/Phi work), but also HLA, which is really just a different form of OOP-enabled RPC/IPC - in other words, if the FGPythonSys layer is using an interface class, the IPC mechanism could be easily updated/augmented or replaced at a later time.

For now, this may be the best way forward to allow people to tinker with Python support in FG without having any chance to introduce threading issues.

FGPythonSys would probably want to check if the mongoose stuff is running or not, and enable it on demand to make the property/fgcommand back-end available.

From a Nasal standpoint, most of this could be useful and ported "back" into something like FGScriptingSys so that it can be used by Nasal scripts, too.
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 » Wed Feb 24, 2016 11:25 pm

It turned out that you were right regarding the benefits of being able to disable subsystems - I ended up running into an interesting race condition where AIManager code was trying to access the non-existing FGNasalSys instance, from a background thread - i.e. the whole AIScenario stuff isn't currently disabled easily, and it's trying to run Nasal code by accessing the global FGNasalSys instance - it's fairly easy to reproduce this when trying to reset the simulator while the AIScenario stuff is still initializing.

Note that this even holds true if all AI related startup arguments and properties suggest that AI stuff will be disabled entirely.

Apart from that, there aren't any Nasal related segfaults when exiting the simulator.
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

PreviousNext

Return to New features

Who is online

Users browsing this forum: No registered users and 7 guests