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 bugman » Mon Oct 24, 2016 7:27 pm

I also see the smashed stack issue when I compile my own Python-3.5.2 version (edit: in my Ubuntu 16.04 VM). I tracked this down to a bug in Python itself - in the PyArg_ParseTupleAndKeywords() function where the "p" argument format is not correctly converted into a C bool type, and fixed it in the python/r9 branch. Could you check if this now works?

Cheers,
Edward

Edit2: Note that the gdb backtrace is much more informative if you compile your own Python version as described earlier:

Code: Select all
#0  0x00007ffff640f418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff641101a in __GI_abort () at abort.c:89
#2  0x00007ffff645172a in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7ffff6568c7f "*** %s ***: %s terminated\n")
    at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff64f289c in __GI___fortify_fail (msg=<optimized out>, msg@entry=0x7ffff6568c61 "stack smashing detected") at fortify_fail.c:37
#4  0x00007ffff64f2840 in __stack_chk_fail () at stack_chk_fail.c:28
#5  0x0000000000489758 in Props_tp_init (self=0x934d80, args=0x722ae8, keywords=0x8765e8)
    at /home/edward/src/flightgear/src/Python/prop_tree.cxx:1525
#6  0x00007ffff711e6d6 in type_call (type=<optimized out>, args=0x722ae8, kwds=0x8765e8) at Objects/typeobject.c:905
#7  0x00007ffff70b270a in PyObject_Call (func=0x70af20 <Props_type>, arg=<optimized out>, kw=<optimized out>) at Objects/abstract.c:2165
#8  0x00007ffff7195c32 in do_call (nk=<optimized out>, na=<optimized out>, pp_stack=0x7fffffffc0b0, func=<optimized out>) at Python/ceval.c:4936
#9  call_function (oparg=<optimized out>, pp_stack=0x7fffffffc0b0) at Python/ceval.c:4732
#10 PyEval_EvalFrameEx (f=f@entry=0x888ae8, throwflag=throwflag@entry=0) at Python/ceval.c:3236
#11 0x00007ffff719d804 in _PyEval_EvalCodeWithName (_co=_co@entry=0x95bb70, globals=globals@entry=0x7a4868, locals=locals@entry=0x7a4868,
    args=args@entry=0x0, argcount=argcount@entry=0, kws=kws@entry=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0,
    qualname=0x0) at Python/ceval.c:4018
#12 0x00007ffff719d8e3 in PyEval_EvalCodeEx (_co=_co@entry=0x95bb70, globals=globals@entry=0x7a4868, locals=locals@entry=0x7a4868,
    args=args@entry=0x0, argcount=argcount@entry=0, kws=kws@entry=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0)
    at Python/ceval.c:4039
#13 0x00007ffff719d90b in PyEval_EvalCode (co=co@entry=0x95bb70, globals=globals@entry=0x7a4868, locals=locals@entry=0x7a4868) at Python/ceval.c:777
#14 0x00007ffff71c606f in run_mod (arena=0x82edb0, flags=0x8a71a0, locals=0x7a4868, globals=0x7a4868, filename=0x8a71a0, mod=<optimized out>)
    at Python/pythonrun.c:976
#15 PyRun_StringFlags (str=str@entry=0x4dcd30 "builtins.props = prop_tree.Props(new_tree=False)", start=start@entry=257, globals=0x7a4868,
    locals=0x7a4868, flags=flags@entry=0x0) at Python/pythonrun.c:900
#16 0x00007ffff71c60fb in PyRun_SimpleStringFlags (command=0x4dcd30 "builtins.props = prop_tree.Props(new_tree=False)", flags=0x0)
    at Python/pythonrun.c:421
#17 0x0000000000483af4 in FGPythonSys::init (this=0x721100) at /home/edward/src/flightgear/src/Python/PythonSys.cxx:95
#18 0x0000000000477648 in PropTreeTestCase::setUp (this=0x720770) at /home/edward/src/flightgear/test_suite/unit_tests/Python/test_prop_tree.cxx:710
#19 0x00000000004771f7 in CppUnit::TestCaller<PropTreeTestCase>::setUp (this=0x7207b0) at /usr/include/cppunit/TestCaller.h:177
#20 0x00007ffff7bbb292 in CppUnit::TestCaseMethodFunctor::operator()() const () from /usr/lib/x86_64-linux-gnu/libcppunit-1.13.so.0
#21 0x00007ffff7bb1b93 in CppUnit::DefaultProtector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) ()
   from /usr/lib/x86_64-linux-gnu/libcppunit-1.13.so.0
#22 0x00007ffff7bb84c2 in CppUnit::ProtectorChain::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) ()
   from /usr/lib/x86_64-linux-gnu/libcppunit-1.13.so.0
#23 0x00007ffff7bc0b30 in CppUnit::TestResult::protect(CppUnit::Functor const&, CppUnit::Test*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib/x86_64-linux-gnu/libcppunit-1.13.so.0
#24 0x00007ffff7bbaff4 in CppUnit::TestCase::run(CppUnit::TestResult*) () from /usr/lib/x86_64-linux-gnu/libcppunit-1.13.so.0
#25 0x00007ffff7bbb5c3 in CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) () from /usr/lib/x86_64-linux-gnu/libcppunit-1.13.so.0
#26 0x00007ffff7bbb4de in CppUnit::TestComposite::run(CppUnit::TestResult*) () from /usr/lib/x86_64-linux-gnu/libcppunit-1.13.so.0
#27 0x00007ffff7bbb5c3 in CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) () from /usr/lib/x86_64-linux-gnu/libcppunit-1.13.so.0
#28 0x00007ffff7bbb4de in CppUnit::TestComposite::run(CppUnit::TestResult*) () from /usr/lib/x86_64-linux-gnu/libcppunit-1.13.so.0
#29 0x00007ffff7bc0a52 in CppUnit::TestResult::runTest(CppUnit::Test*) () from /usr/lib/x86_64-linux-gnu/libcppunit-1.13.so.0
#30 0x00007ffff7bc315e in CppUnit::TestRunner::run(CppUnit::TestResult&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib/x86_64-linux-gnu/libcppunit-1.13.so.0
#31 0x00007ffff7bc4f50 in CppUnit::TextTestRunner::run(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, bool, bool) () from /usr/lib/x86_64-linux-gnu/libcppunit-1.13.so.0
---Type <return> to continue, or q <return> to quit---
#32 0x000000000048b063 in unitTestRunner () at /home/edward/src/flightgear/test_suite/unit_tests/fgUnitTestRunner.cxx:56
#33 0x000000000048f302 in main () at /home/edward/src/flightgear/test_suite/testSuite.cxx:76
bugman
Moderator
 
Posts: 1582
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: FGPython an propose for Python as an nasal alternative

Postby www2 » Mon Oct 24, 2016 9:41 pm

This one works there is another "Segmentation fault" on closing but this have a low priority for now (happens on exit)
Code: Select all
Thread 1 "fgfs" received signal SIGSEGV, Segmentation fault.
0x0000000000000021 in ?? ()
(gdb) backtrace
#0  0x0000000000000021 in ?? ()
#1  0x0000000002058a80 in logstream::~logstream (this=0x2b0b7e0,
    __in_chrg=<optimized out>)
    at /home/jean-paul/fgfs2/simgear/simgear/debug/logstream.cxx:463
#2  0x0000000002058fe8 in simgear::shutdownLogging ()
    at /home/jean-paul/fgfs2/simgear/simgear/debug/logstream.cxx:630
#3  0x00000000013dd2bb in fgExitCleanup ()
    at /home/jean-paul/fgfs2/flightgear/src/Main/bootstrap.cxx:286
#4  0x00007ffff2081fe8 in __run_exit_handlers (status=0,
    listp=0x7ffff240b5f8 <__exit_funcs>,
    run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#5  0x00007ffff2082035 in __GI_exit (status=<optimized out>) at exit.c:104
#6  0x00007ffff2068837 in __libc_start_main (
    main=0x13dcb3d <main(int, char**)>, argc=2, argv=0x7fffffffdc98,
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
    stack_end=0x7fffffffdc88) at ../csu/libc-start.c:325
#7  0x00000000013dc7a9 in _start ()
www2
 
Posts: 235
Joined: Thu Apr 16, 2009 1:58 pm

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Tue Oct 25, 2016 10:38 am

I also see a segfault with the 'next' branches. Do you see this too? I wonder if it is the same problem? I have modified the logstreams in the 'cppunit' branches for better control of the IO, so it might be related to that and James' recent changes to the logstream.

Cheers,
Edward
bugman
Moderator
 
Posts: 1582
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: FGPython an propose for Python as an nasal alternative

Postby www2 » Tue Oct 25, 2016 1:14 pm

I can confirm this segfault. I test later today with gdb.
www2
 
Posts: 235
Joined: Thu Apr 16, 2009 1:58 pm

Re: FGPython an propose for Python as an nasal alternative

Postby www2 » Tue Oct 25, 2016 3:19 pm

Look like that the segfault in next is fix.
www2
 
Posts: 235
Joined: Thu Apr 16, 2009 1:58 pm

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Tue Oct 25, 2016 7:23 pm

Are you sure you've updated to the current version of the 'next' branches? I currently cannot compile these, after James' C++11 changes.

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

Re: FGPython an propose for Python as an nasal alternative

Postby wkitty42 » Tue Oct 25, 2016 7:56 pm

you're stuck with the cmake v3.1 enforcement, too? i haven't yet tested rebecca's update to the dnc script that pulls cmake from their repo and compiles it... i plan to, though... first i have to do something about merging my fixed debug option into the new stuff... i guess i should delete my old merge requests and then do a new one after i do that...
"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: 5146
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Tue Oct 25, 2016 8:05 pm

C++11, cmake 3.xx - these things should really be more carefully discussed on the devel list, and put up for review/voting among all contributors, especially those building from source who may not be able to always use the latest bleeding edge ... having a wiki article, even just a RFC topic would have been a good idea.

It's not like this will ever affect me personally, but we're locking out potential, and existing, contributors by letting people decide these things without asking for community feedback first - especially in the light of the download numbers recently posted by Curt and Torsten.

If this was discussed during one of the hangouts, it should have been made much more prominent, and a newsletter announcement should have been added soliciting feedback for at least 6-12 months before going "all in" on changes that may lock out people who are not C++/cmake/git/Linux, whatever, experts
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: 11298
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby www2 » Tue Oct 25, 2016 9:44 pm

Edward
Yes i am on current next commit
simgear: commit dd52b6af50acc293a0b5db1886f2896e1f745d95
Flightgear: commit 8e451a05f111a7cfdba305452156f7c2acfab46d
www2
 
Posts: 235
Joined: Thu Apr 16, 2009 1:58 pm

Re: FGPython an propose for Python as an nasal alternative

Postby wkitty42 » Tue Oct 25, 2016 11:10 pm

@hooray, there was some talk in the dev list but i cannot tell you which topic to look at to read it... i can try to search my local email archives and find it, if you like... something about new features and capabilities that cmake 3.1 brings... i know that smartpointers were mentioned but that may be a c++11 thing...
"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: 5146
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Mon Mar 05, 2018 9:07 am

I have made another update to my FGPythonSys branches. These have been rebased to the 2018.2.0 development branches (close to the start of the branching point). There have been no significant changes to FGPythonSys itself, however the base CppUnit test suite branches have had a lot of work.


Again these are based on the CppUnit test suite branches:


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

Re: FGPython an propose for Python as an nasal alternative

Postby legoboyvdlp » Mon Mar 05, 2018 10:54 am

This is quite interesting...
I saw a proposal on the FFFS forum for a pythonized approach to aircraft development: IH-COL posted the following example:
Code: Select all
import engine from FS.propertyTree #would get the Engine class for the flight simulator.
                    #the class Engine would be ready for the mods.
                                                     
Class 727engines(Engine):
   def __init__:
      enginesStack=[Engine() for engines in range(3)]
           #Now we created three engines in the stack for the initialization as a list
        def  toggleFastRevThrust(self):
               for engine in enginesStack:
                        engine.reverser=1
                        engine.throtle-rev=0.5
                        engine.reverser-angle-rad=3.14

##Now we can create our stack and run the functions declared

engines=727engines( ) 
engines.toggleFastRevThrust( )


While I agree with what Richard posted that JSBSIM is probably the best way to go for coding things like this, python is a very interesting alternative, look forward to seeing what you accomplish.
User avatar
legoboyvdlp
 
Posts: 6415
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Mon Mar 05, 2018 1:45 pm

I just saw that thread. I don't see any advantage over Nasal here, to be honest. OO Python or OO Nasal (OO = object oriented) will give you roughly the same thing. There might be an advantage with garbage collection (gc) but until there are real tests comparing the two, the gc nasal issues are pure speculation.

The advantage here will be different. I see FGPythonSys as being used more in the core. I would like to expose the subsystem infrastructure via Python, so you can write your own subsystem in pure Python. Sure Python could be used on the content side to replace Nasal (and XML, if you so wish), but that is not the aim.

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

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Tue Mar 06, 2018 3:15 pm

Realistically, without a full-featured IPC framework in use, there is hardly any benefit at all - i.e. either there's SGSubsystem-induced constraints imposed on the main loop, or you really need an IPC mechanism to run stuff outside the main loop.

At this point, the only logical thing to do would be for FGPythonSys to get involved in the addon department and provide python support there.
If that's a no-goal, and HLA/RTI remains pie-in-the-sky, the only remaining option is not to wait for theoretical infrastructure that may be added in the future, and simply use Torsten's AJAX/JSON mongoose interface (used by Phi)

People thinking that Python support brings advantages over Nasal, are deluding themselves because they don't appreciate where, why and how most Nasal code is causing performance issue (even totally unrelated to the single-threaded mark/sweep GC), i.e. the main bottleneck is the way FGNasalSys it is integrated in the main loop as a SGSubsystem, so that Nasal doing e.g. tons of property I/O, adds up at runtime

Running Python out-of-process is way more involved than proxy'ing Nasal scripts to run in worker threads and only use an MPI-like mechanism like Emesary to talk to the rest of the sim.

Finally, there's certainl overlapping requirements when it comes to scripting integration - no matter if scripts are supposed to run in the main loop or not, a common baseclass providing the corresponding interface and infrastructure would definitely make sense.

(I am myself not at all opposed to Python, however a number of core devs -e.g. Torsten- cited some valid concerns, and it would be foolish to disregard those, but also foolish not to took at Nasal and its integration/shortcomings).

PS: Having FGPythonSys integrated and available as per bugman's comments would also mean that most of James' Qt5 launcher work could become entirely obsolete, because we could simply use an existing Python-based launcher, e.g. FGo!

http://wiki.flightgear.org/FGo!
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: 11298
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby curt » Tue Mar 06, 2018 4:28 pm

I like python too (quite a lot), but nasal is amazing and brilliant for it's small size. It offers tremendous functionality for just a small number of lines of interpreter code. The in-memory footprint is also really small. For anyone who values doing a *lot* with a few lines of code, Andy is a genius and and artist all in one. The language is straightforward and mixes elements of other popular languages, so it is quite easy to learn. There are many dimensions to a decision matrix. It is easy to focus on one aspect you don't like as much and forget about all the other details that went into the original thought process. From a big picture perspective, it would be easy to do worse than nasal, much harder to do better.

For anyone who still really wants to explore python scripting from within FlightGear, grab Edward's patches and have fun experimenting. The footprint and performance of python on modern computers (as well as a rich ecosystem of support libraries) makes it attractive and compelling.
Aerospace Engineering and Mechanics
University of Minnesota
curt
Administrator
 
Posts: 1147
Joined: Thu Jan 01, 1970 12:00 am
Location: Minneapolis, MN

PreviousNext

Return to New features

Who is online

Users browsing this forum: No registered users and 1 guest