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 www2 » Thu Mar 24, 2016 12:45 am

Now it is more than a month after the last post and here is a update from me.
I have finish a small python module using python's c/c++ api call fg_geomath with the following functions:
geodtocart
carttogeod
GCDistence
GCbearing
GCdestination

The geodtocart and carttogeod are a direct port from nasal code and use a simaler interface as the counter part in nasal.
The GCDistence, GCbearing and GCdestination are Great Circle function for getting dissents or bearing from point a to b or get lat lon for point b using bearing and distance on point a.

bugman:
How's going the loop interface for python?

edit: here is my commit
www2
 
Posts: 319
Joined: Thu Apr 16, 2009 2:58 pm
OS: Ubuntu

Re: FGPython an propose for Python as an nasal alternative

Postby www2 » Fri Apr 22, 2016 11:43 am

A new update From me.
I start to test a simple interface for recurrent functions in python that using a simple api that I base on the Arduino/Genuino interface.
My plan is that this become a universal interface for python programs that running in Flight Gear regardless that the code run inside FG's main loop or a thread with minimal chance of the code by the user/developer.
www2
 
Posts: 319
Joined: Thu Apr 16, 2009 2:58 pm
OS: Ubuntu

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Fri Apr 22, 2016 7:11 pm

Sorry, I have recently been on a long holiday. I'm also battling with VS 2015 (msvc14) on a VirtualBox VM with Windows 7. I need to have this system up and running, because Windows support for FGPythonSys is essential.

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 www2 » Sat Apr 23, 2016 2:32 pm

Thx Edward for the update from you site.

In other news:
I think i found a possibly problem with execution python code from xml files for switches and buttons.
This is not a bad problem we can create an interface that can than handle nasal and python code or future scripting languages instate of using a nasal call to operate a function.
Last edited by bugman on Sat Apr 23, 2016 5:32 pm, edited 1 time in total.
Reason: Unnessesary quoting.
www2
 
Posts: 319
Joined: Thu Apr 16, 2009 2:58 pm
OS: Ubuntu

Re: FGPython an propose for Python as an nasal alternative

Postby Thorsten » Sat Apr 23, 2016 2:36 pm

I think i found a possibly problem with execution python code from xml files for switches and buttons.


Isn't that what Edward said the PYTHON project is *not* supposed to be about? Which is to say, an additional toolkit for power users, but no aircraft scripting that way?
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Sat Apr 23, 2016 2:57 pm

technically, there isn't much of a problem at all, see the "FGScriptingInterpreter" talks on the wiki.
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 Apr 26, 2016 11:25 am

I don't know this is a bug in python, ubuntu or in our code but fg crash on line 89 in PythonSys.cxx ( PyRun_SimpleString("import prop_tree"); ) after i upgrade to upgrade to Ubuntu 16.04
GDB traceback:
Code: Select all
#0  0x00007ffff22ea418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff22ec01a in __GI_abort () at abort.c:89
#2  0x00007ffff232c72a in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7ffff2443c7f "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff23cd89c in __GI___fortify_fail (msg=<optimized out>, msg@entry=0x7ffff2443c61 "stack smashing detected") at fortify_fail.c:37
#4  0x00007ffff23cd840 in __stack_chk_fail () at stack_chk_fail.c:28
#5  0x0000000000c0ac8c in Props_tp_init(Props*, _object*, _object*) ()
#6  0x00007ffff404cf66 in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#7  0x00007ffff412eace in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#8  0x00007ffff418fc3f in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#9  0x00007ffff421411c in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#10 0x00007ffff42141f3 in PyEval_EvalCodeEx () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#11 0x00007ffff418dcdb in PyEval_EvalCode () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#12 0x00007ffff41aaedf in PyRun_StringFlags () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#13 0x00007ffff41abf1b in PyRun_SimpleStringFlags () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#14 0x0000000000c052e0 in FGPythonSys::init() ()
#15 0x0000000000737e9b in fgPostInitSubsystems() ()
#16 0x000000000076485f in fgIdleFunction() ()
#17 0x0000000000ed9458 in fgOSMainLoop() ()
#18 0x00000000007666bd in fgMainInit(int, char**) ()
#19 0x000000000070fc82 in main ()

edit: i use current python/r6 form Edward branch
www2
 
Posts: 319
Joined: Thu Apr 16, 2009 2:58 pm
OS: Ubuntu

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Tue Apr 26, 2016 1:05 pm

I haven't seen that error before. Maybe it has something to do with changes in Python 3.5? I'll see if I can work out what is happening.

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 www2 » Tue Apr 26, 2016 6:19 pm

bugman I agree with you about the bug.
Before the crash i get is error *** stack smashing detected ***: ./fgfs terminated" and my early post is the GDB log.
And a weird thing is that Python/r5 run " normal " and Python/r6 have this bug
www2
 
Posts: 319
Joined: Thu Apr 16, 2009 2:58 pm
OS: Ubuntu

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Tue Apr 26, 2016 6:34 pm

I'm checking if my local python/r7 branch has the same problem (and simgear python/r5). Maybe I should rebase these against next and push them, so we are closer to the head, and then create new local branches. Unfortunately the msvc14 problems are really eating away at my development time! Once that is running, I will fix the cppunit test suite to work on Windows, submit the cppunit test suite branches without Python, get FGPythonSys running happily on Windows, and then start looking at fgcommands.

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 May 12, 2016 3:00 pm

bugman wrote in Sat Jan 23, 2016 3:04 pm:The more I look into the Nasal timer code, the more I develop a deep down sick feeling. Note that the FGPythonSys subsystem is not bound by this design, and I do not intend it to be.


With Richard's Emesary system now being ported to Nasal, it would actually make sense to look at it with a focus on FGPythonSys, i.e. how this could be moved to C++ space, and reused by the whole FGScriptingSys interface we've been talking about, because that could make timers, and listeners, entirely unnecessary - while providing the option to run scripts asynchronously from the main loop.

It would even be possible to come up with a Canvas mode where a Canvas (FBO) is only updated using an Emesary transmitter, which would mean that these updates could be processed in a background thread, and that OSG could be also much more aggressive about updating Canvas elements/FBOs concurrently.

Note that there is nothing Nasal specific about Emesary - it's just a way to come up with a decoupled design that lets components act with eachother without having to know much/anything about their internals, and this kind of decoupling would also be useful for any HLA efforts, because HLA would be just one kind of transport, and one that could greatly benefit from having this separation in place.

http://wiki.flightgear.org/Emesary
Image
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 » Sun Jun 19, 2016 7:42 am

To keep the FGPythonSys experiment current, I have pushed another set of branches rebased on the main repositories, as of today:

These are based on the CppUnit test suite branches:


With CppUnit on your system, using the same compilation directory as usual, you can test the FGPythonSys with:

Code: Select all
make test_suite


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 bugman » Mon Oct 17, 2016 6:51 pm

Here is another update for the FGPythonSys code. I have rebased the branches on the current 2016.4.0 flightgear/simgear/fgdata branches. Not only that, but the branches now work on MS Windows. As these worked on GNU/Linux previously, and Mac OS X should just work, the branches should now be functional on all operating systems! Note though that only the CppUnit code needed updating to work on MS Windows, the Python code worked without modification. The branches are:

As before, these are based on the CppUnit test suite branches:


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 www2 » Thu Oct 20, 2016 4:17 pm

He bugman i get a segfault with python/r9
gdb backtrace:
Code: Select all
#0  0x00007ffff1fcc418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff1fce01a in __GI_abort () at abort.c:89
#2  0x00007ffff200e72a in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7ffff2125c7f "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff20af89c in __GI___fortify_fail (msg=<optimized out>, msg@entry=0x7ffff2125c61 "stack smashing detected") at fortify_fail.c:37
#4  0x00007ffff20af840 in __stack_chk_fail () at stack_chk_fail.c:28
#5  0x0000000000c16efc in Props_tp_init(Props*, _object*, _object*) ()
#6  0x00007ffff3d2f276 in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#7  0x00007ffff3e258ee in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#8  0x00007ffff3e607ff in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#9  0x00007ffff3ef6c0c in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#10 0x00007ffff3ef6ce3 in PyEval_EvalCodeEx () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#11 0x00007ffff3e5e89b in PyEval_EvalCode () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#12 0x00007ffff3e7bd3f in PyRun_StringFlags () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#13 0x00007ffff3e7cd7b in PyRun_SimpleStringFlags () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#14 0x0000000000c14b79 in FGPythonSys::init() ()
#15 0x000000000073f4bf in fgPostInitSubsystems() ()
#16 0x000000000076ec5f in fgIdleFunction() ()
#17 0x0000000000ee50b8 in fgOSMainLoop() ()
#18 0x000000000076bc86 in fgMainInit(int, char**) ()
#19 0x0000000000718c12 in main ()
www2
 
Posts: 319
Joined: Thu Apr 16, 2009 2:58 pm
OS: Ubuntu

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Thu Oct 20, 2016 4:48 pm

I have no idea what is happening with that segfault! For me this compiles and runs without issue on all operating systems. I'm wondering if it is the Python version (3.5 for 64-bit Linux). When I run CMake, it finds and links to /usr/lib64/libpython3.4m.so. I have all versions of Python from 1.0 to 3.5 installed on my system, so I'll see if I can link to Python 3.5 and test. Oh, how is Python installed on your system?

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 7 guests