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 » Mon Feb 08, 2016 6:12 pm

@bugman:

Referring to: http://sourceforge.net/p/flightgear/mai ... /34832057/
introduce a trust system, whereby the user specifies which sources and paths should be trusted, and then this is taken into account by the fgValidatePath() function (or this function is completely bypassed). Maybe there could be some options introduced, such as --trusted-paths and --writeable-paths?


This is basically how fgValidatePath() is already working, see $FG_ROOT/Nasal/IORules

http://wiki.flightgear.org/IOrules

It would be easy to extend this to support the startup options you mentioned
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 www2 » Tue Feb 09, 2016 12:25 am

Hooray wrote in Mon Feb 08, 2016 6:06 pm:The "python terminal" can be implemented using the plib netchat class, which is what we are using for the telnet/props daemons in FlightGear - so, implementing a corresponding netchat channel that provides a python terminal would be relatively straightforward


I mean some thing like nasal console or REPL Interpreter (REPL Interpreter can add on a later moment).
And one of the first things that i try to add was an python console but <command><python> don't work at this moment.
www2
 
Posts: 319
Joined: Thu Apr 16, 2009 2:58 pm
OS: Ubuntu

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Tue Feb 09, 2016 1:00 am

no, that cannot work at all - for a console to show up, you need to provide a GUI around it, i.e. something showing characters, and allowing input to be entered. The Nasal Console is not even interactive for that reason, only Philosopher's REPL is interactive, but it's using the Canvas system internally to accomplish that:

http://wiki.flightgear.org/Interactive_Nasal_Console
Image

Thus, the easiest way to proceed for you would be to look up the corresponding Nasal APIs used there (compile, call etc) and map those to their Python equivalents, and expose those to code running in the main loop (which would require synchronization obviously).

However, to be honest, I think you are trying to do too much at once - you gotta need to be able to walk before you even try to run, and there's still some groundwork/legwork to be done before certain features can be looked at, which is why I suggested to look at FGNasalSys, fgcommands etc - to be sure that you understand the main loop side to all this.

It may seem like I am posting here to have a monologue with myself, but all my postings were specifically in response to questions raised here, including some that you may not yet be aware of - i.e. showstoppers that will sooner or later become relevant, not so much due to Python but to the existing FG legacy code base
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 www2 » Tue Feb 09, 2016 1:16 am

@Hooray
My current my focus is adding python to fgcommands.
www2
 
Posts: 319
Joined: Thu Apr 16, 2009 2:58 pm
OS: Ubuntu

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Tue Feb 09, 2016 4:55 pm

doing the opposite will be easier for the time being
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 Feb 11, 2016 11:03 am

Just a quick update, now that I have a test suite up and running (I'll post full details on the devel mailing list), I'm now working on a 'fg_sys' Python module to supply 'sys' module equivalent functions. The initial aim of this basic infrastructure is to replace sys.stdout and sys.stderr so that this works through the SG_LOG() system, allowing all printouts and feedback to go through the normal FlightGear/SimGear IO channels.

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 Feb 11, 2016 12:43 pm

FYI: see the Nasal extension functions called logprint/printlog - however, given that you are hoping to implement entire subsystems in scripting space, it might make sense to also expose the log-class info, i.e. so that you can also register new logging classes for new subsystems.
That would require touching simgear and turning the whole thing into a class with a std::vector or a std::map for different subsystems and their "identifier"
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 Feb 11, 2016 3:47 pm

Hooray wrote in Thu Feb 11, 2016 12:43 pm:... however, given that you are hoping to implement entire subsystems in scripting space, it might make sense to also expose the log-class info, i.e. so that you can also register new logging classes for new subsystems.
That would require touching simgear and turning the whole thing into a class with a std::vector or a std::map for different subsystems and their "identifier"


This is a good point. Though rather than a std::vector, I'd probably leave the sgDebugClass enum as it is, but add a few extra entries for dynamic allocation. I'd then maybe convert the debugClassToString(sgDebugClass c) function switch contents into a std::map, so that the SG_LOG prepended names can be dynamically inserted to match the sgDebugClass enum allocation. Anyway, I'll sit on this idea until more FGPythonSys groundwork has been implemented.

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 » Thu Feb 11, 2016 4:56 pm

note that the log-level<->string conversion magic is found all over the place in the sg/fg repositories, i.e. not consistently implemented for the time being - last time I checked, there were at least a handful of locations where the code looked like it was copied & pasted verbatim
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 Feb 11, 2016 7:35 pm

By the way, I won't be taking the Nasal way of providing a logprint() and print() function. Instead I will be using IO redirection, and relying on the Python IO mechanisms (print(), sys.stdout.write(), sys.stderr.write(), raise, etc.). The Python sys.stdout object will be a buffered stream into SG_LOG(SG_PYTHON, SG_INFO, text). And sys.stderr will go into SG_LOG(SG_PYTHON, SG_ALERT, text). These will also be available in the 'fg_sys' module, as fg_sys.stdout and fg_sys.stderr, for developers to write to. I have already implemented all of this and am now looking at ways of capturing SG_LOG IO streams, for presenting detailed feedback for test suite failures. I'll wait until after the 2016.1.1 release, and then maybe I'll push out some new branches with the code.

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 Philosopher » Thu Feb 11, 2016 9:02 pm

Edward: my only concern with using SG_LOG is that it always appends a new line, but Python 3's print() function provides a way to change/remove the line separator, so always having a new line might mess up some formatting...
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Fri Feb 12, 2016 9:01 am

Philosopher wrote in Thu Feb 11, 2016 9:02 pm:Edward: my only concern with using SG_LOG is that it always appends a new line, but Python 3's print() function provides a way to change/remove the line separator, so always having a new line might mess up some formatting...


I noticed that, such a strange behaviour! The Python exception system has a tendency to send its output out in small blocks, not separated by '\n', so I was seeing some pretty mangled output in my test suite. So I introduced a buffer (as a char array carried within the IOStream class instances used to replace sys.stdout and sys.stderr, the default Python output streams). This buffer is flushed to SG_LOG whenever a newline character is seen, or when the buffer of 10000 characters is full. I have also implemented the IO stream object's flush() method so that this conforms to Python's default IO flushing mechanisms. Very basic textbook stuff, while working through such a textbook :) Did you have another idea in mind? I guess you meant the 'end' keyword argument for the print() function, so that the newline can be suppressed (essentially turning a print() call into a sys.stdout.write() call).

Cheers,
Edward


Edit: URL fix.
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 bugman » 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:


I have shifted everything around so that these branches are based on my test suite branches (u-edauvergne-flightgear cppunit/r4 and u-edauvergne-simgear cppunit/r3). This means that if you install the dependency-free CppUnit package and run "make test_suite", you will see 100% of FGPythonSys tested. This is via 242 passing tests, and one deliberately failing yet temporary test. I recommend that any Python developments based off my branches take full advantage of this infrastructure - creating tests for this infrastructure is very easy - and that the test suite remains at a 100% pass rate.

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 curt » Fri Feb 19, 2016 4:44 pm

I have a quick off topic report that is kind of related. Over the past few years I have developed a small UAS autopilot system that is largely built on FlightGear principles (property system, xml, the same xml-configurable autopilot system flying in real life, lots of borrowed simgear code, etc.) This is something that flies real small uav's in the real world (which among other things validates FlightGear's approach in many ways.)

This winter I have created a version of the property system written purely in python. I then created a C++ interface to the python-property system. Then I did this crazy thing where I replaced the entire C++ property system (which was the same as FlightGear used) with my new python property system which touched just about every line of code and every code and logic path in my entire autopilot system. The point of this was to move towards more of my own UAS autopilot system being written in native python. (If the code memory foot print is stable, and if the performance is fast enough, then what other reason is there to object?)

So I wanted to report that yesterday I went out and did two complete flights with the new python-based autopilot system. I logged about 49 minutes of total flight time and the new system was rock solid, now with a lot of python under the hood.

My real-life autopilot efforts are an offshoot of flightgear, and now headed in their own direction, but I just thought I'd mention it because it is semi-related, and maybe semi-interesting to a few people. If anyone cares to poke around in my code, it is all open-source and can be found here: https://github.com/AuraUAS It is still a work in progress and the current state is a stepping stone towards even better things, but every step takes time. My design philosophy for this autopilot is simplicity and readability (as long as I can fit the required functionality into the allowed memory and cpu budget, and right now that is defined as a beaglebone/raspberry pi caliber computer.)

Sorry Edward, I don't mean to hijack your thread ... but maybe this is at least loosely related. :-)
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 bugman » Fri Feb 19, 2016 5:01 pm

That's great that it worked flawlessly! I bet you were a little worried though ;) Python is often bashed as being slower than other languages, but well designed Python code can perform quite well, and in fact much better than poorly designed C/C++ or even FORTRAN code. Did you have to manually control the take off and landing?

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

PreviousNext

Return to New features

Who is online

Users browsing this forum: No registered users and 5 guests