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 » Sat Jan 23, 2016 2:04 pm

Hooray wrote in Sat Jan 23, 2016 9:03 am:@bugman:


Hi! This is quite a post, I'll see if I can respond. I suggest that for better input into the developments, to have shorter messages that focus on a single point.

Wow, that's quite an accomplishment for someone just recently claiming not to be a C++ programmer ;-)


Well, once you know a few languages, learning to speak another is much easier. I have written a lot of code, mainly the software relax consisting of a trunk SLOC count of 141,331 lines of code (with an enforced ~30% comment ratio).

I haven't actually built your branches, but went through your commits/patches and read your comments on the devel list.


You should give it a go. This would enable you to make more valuable contributions ;)


So take my comments with a grain of salt (of course...), I am making them specifically with a focus on 1) the way Nasal scripting currently works in FlightGear (and the challenges resulting from that), and 2) your comments to hopefully provide Python support as a viable alternative for "software prototyping" and adopting HLA via scripting.


I have plenty experience, so I have built up a large reserve of salt!

That being said, here's some feedback:


Despite the salt, all feedback is good. Cheers! Note that there have been a number of private and the official developer Google Hangout discussions about the topics you cover below.

  • to bring the Python interface up to par with Nasal, timers and listeners would be useful - because those are currently the main building blocks to trigger scripted code in the FlightGear main loop.


Let me get back to that one. Note - I think timers are a hack.

  • Over time, this has become a bit problematic in FlightGear - and the core developers have come to the conclusion that RAII is needed for timer/listener management - which is to say that you would want to look at the OOP maketimer() API in FGNasalSys and explore having two similar APIs for wrapping timer/listener functionality in a makelistener() fashion.


  • 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.

  • One of the issues causing Nasal code to be a real challenge compared to its C++ counterpart is that none of the Nasal code is using the existing SGSubsystem interface - so if your comments on "software prototyping" were/are serious, we would probably want to look at exposing SGSubsystem as a base class which can be inherited from in Python space to register new subsystems that are implemented in Python.


  • Those comments are serious. The idea of a base class for spawning SGSubsystems and talking to them via HLA has already been discussed "behind the scenes" (not really behind the scenes, but just not visible from this forum).

  • Like you mentioned on the devel list, many things like the property tree/subsystems would ideally be using some form of IPC (like HLA) to interface with the rest of the simulation - but the logical first step is exposing conventional bindings for the property tree and subsystems.


  • From my coding experience I can say that this is not how it's done. It's more like this - serve up a concrete problem to solve, with code, data, scripts, etc., and that problem will be solved.

    The way your code is currently structured, it seems that you pretty much used FGNasalSys as a template, using copy & paste. As you probably noticed already, there is quite a bit of overlapping code/functionality, so that it /might/ make sense to introduce a common base class in the form of FGScriptingHost that inherit from SGSubsystem, from which FGPythonSys/FGNasalSys could then inherit their own child-classes, so that shared functionality can reside in the parent class (or customized/overridden accordingly).


    There was a lot of copy and paste. That's not hidden. But I would like to diverge significantly from where Nasal has gone. Therefore I do not intend on sharing any of this Nasal infrastructure. Remember - this is in no way designed to be a Nasal replacement. And this clean slate development is in no way bound by the Nasal design decisions.

    Otherwise, I do applaud your effort to make the whole thing compatible with the ongoing reset/re-init work, because that could be cosidered a key part of the whole HLA thing, and most core developers continue to make commits that are basically incompatible with reset/re-init, i.e. complicating matters for Zakalawe tremendously (on the other hand, his reset/re-init and headless work admittedly didn't even make it to the "updated roadmap" either).


    Cheers! After working with this, I can see that this work is still in flux. Modularlisation, isolation, and standardisation of the FG codebase is very much WIP. This is being pushed hard from 2 directions - James with the reinit() and Stuart with HLA. Note my CppUnit comment on the mailing list - if this takes off, then this process will be massively accelerated.

    Another issue that FGNasalSys is suffering from is that it is designed to be a singleton - and it seems FGPythonSys is sharing this limitation. You may want to reconsider if that is ultimately what you are aiming for - simply because in FG, the whole thing of a scripting session depends largely on the "context" - and here FGNasalSys has become a rather messy part of FlightGear, because we don't even differentiate between different "types" of scripts (think aircraft vs. scenery vs. GUI vs. core etc).

    I do think that this could also help address the security issues that Rebecca briefly touched on the devel list, and which I mentioned a few weeks ago on the forum, too ;-)

    Had FGNasalSys been designed to support independent instances, we could have multiple Nasal interpreters running independently for different script types, and could also grant them different permissions ($FG_HOME, $FG_AIRCRAFT, $FG_SCENERY)

    That is something that would greatly help simplify state management for reset/re-init, including use-cases where people may want to save/resume flights (in fact arbitrary simulator state).

    For the time being, this is not possible and causing tons of Nasal related challenges for reset/re-init.

    Equally, there is the very long standing issue of the Nasal interpreter not being available earlier, despite it being potentially useful.

    As you can see on the wiki ("Initializing Nasal earlier"), James, Melchior and others were once contemplating to change that so that FlightGear scripting would become available sooner.

    The main thing that prevents this currently for the Nasal VM is the fact that it has a plethora of SGSubsystem-specific "bindings" (basically subsystem-specific APIs) that are dumped into the globals context, and subsequently assumed to be available "automatically".

    This is a fragile/broken assumption in an increasingly multi-threaded environment, especially because of the ongoing reset/re-init work, where subsystems may be shut down/restarted "on demand", i.e. their availability may change dynamically.

    Like I mentioned previously in this thread, we can easily work around this issue by using the ::bind() and ::unbind() methods to register/remove certain API symbols that depend on other subsystems.

    With Nasal it is kinda "too late" unfortunately, because of the plethora of APIs and subsystems currently exposed - for FGPythonSys, this may be much more straightforward, because it's still in its infancy.


    Well, you can only have one instance of the Python interpreter running, and it is bound by its global interpreter lock (GIL). Note though that there is sub-interpreter support. The current FGPythonSys subsystem can be initialised at any point and I intend to keep it that way. If I can set up the CppUnit tests then initialising just this subsystem, with absolutely nothing else, will be locked into stone!

    In layman's terms that basically means that an API like maketimer() will depends on the events subsystem (in the case of Nasal), whereas maketimer() would depend on the property tree being around, and navDB related APIs would obviously depend on the navDB.

    By the way, when it comes to main loop timers, you may want to consider having your own "python-events" subsystem to ensure that Nasal and Python related timers show up in different subsystems (i.e. in the performance monitor stats).


    I do not intend on using timers or maketimer(). I find such a design to be very much non-ideal. There are much better ways of solving the same problem.

    You may also want to provide a startup option to entirely disable Python to help ensure that people can troubleshoot issues and determine if they are affected by Python being active or not - i.e. Python being built-in but adding the subsystem is determined conditionally using a fgGetBool() and or logic in $FG_SRC/Main/options.cxx

    I am just suggesting that because we have seen countless of posting where Nasal (and its GC) were said to be the culprit, and only when we walked people through removing all Nasal code from the aircraft (think Su15), they finally realized that Nasal was not the issue at all.


    Any ideas how?

    That is also one of the reasons why I believe that the whole "Singleton" assumption will become problematic over time, because if something like FGPythonSys is not a singleton, we can also much more easily stress-test it - while also being able to deal with scripts differently, i.e. depending on their "context" (scope) being aircraft/scenery or GUI related.


    The signleton is already built into the embedded Python interpreter, with the exception of sub-interpreters. It should be possible to work around though, as countless other programs with embedded Python have.

    Equally, a FGPythonSys interpreter that is up and running very early could become really helpeful for debugging/troubleshooting purposes, but also help us implement benchmarking support.


    True, but an interface to the relevant C++ parts will be needed.

    Overall, my suggestion would really be to closely look at where Nasal "failed", and for which reasons - and try to learn from these lessons.


    Timers sounds like the biggest of those failures. Do you have any others you can list?

    Incremental re-initialization and saving/loading state really is a crucial part of the simulation, and it would go a long way to come up with a new scripting option that does not suffer from certain restrictions, especially in an increasingly multi-threaded and distributed environment like HLA.

    Finally, you did an outstanding job there with all the unit testing you implemented, which is another thing where Nasal failed.


    Cheers! Now I just need to hardcode this into a proper test suite.

    Again, your mileage may vary - so if in doubt, raise any of this with some of the folks on the devel list who are willing to help review/commit your patches - my priorities are obviously biased due to my own experiences with FGNasalSys :D


    We'll see. This is currently just a big experiment. Who knows what will come next ;)

    Regards,

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

    Re: FGPython an propose for Python as an nasal alternative

    Postby www2 » Sat Jan 23, 2016 2:34 pm

    @bugman
    Can you a the patch that i have post here above (add $FG_root/Python to PYTHONPATH)
    And add the canvas api as _canvas or canvas_raw
    I start to work on porting some nasal libs to python.
    www2
     
    Posts: 260
    Joined: Thu Apr 16, 2009 1:58 pm

    Re: FGPython an propose for Python as an nasal alternative

    Postby bugman » Sat Jan 23, 2016 2:58 pm

    www2 wrote in Sat Jan 23, 2016 12:37 am:
    to:
    Code: Select all
    # check required dependencies
    set(Python_ADDITIONAL_VERSIONS 3.4)


    Does this still work if only 3 is used, instead of 3.4?

    Cheers,

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

    Re: FGPython an propose for Python as an nasal alternative

    Postby www2 » Sat Jan 23, 2016 3:06 pm

    bugman wrote in Sat Jan 23, 2016 2:58 pm:
    www2 wrote in Sat Jan 23, 2016 12:37 am:
    to:
    Code: Select all
    # check required dependencies
    set(Python_ADDITIONAL_VERSIONS 3.4)


    Does this still work if only 3 is used, instead of 3.4?

    Cheers,

    Edward

    I found out this is a bug with my distro cmake [1][2]
    [1] https://bugs.launchpad.net/ubuntu/+sour ... ug/1323559
    [2] http://askubuntu.com/questions/479260/c ... pythonlibs
    www2
     
    Posts: 260
    Joined: Thu Apr 16, 2009 1:58 pm

    Re: FGPython an propose for Python as an nasal alternative

    Postby bugman » Sat Jan 23, 2016 3:21 pm

    @www2:

    Actually, the following might be better:

    Code: Select all
    diff --git a/CMakeLists.txt b/CMakeLists.txt
    index be91fb6..ec56ed3 100644
    --- a/CMakeLists.txt
    +++ b/CMakeLists.txt
    @@ -315,7 +315,7 @@ endif (ENABLE_QT)
     ## Python setup
     if(ENABLE_PYTHON)
         message(STATUS "Embedded Python enabled, checking for the Python headers")
    -    find_package(PythonLibs REQUIRED)
    +    find_package(PythonLibs 3 REQUIRED)
         include_directories( ${PYTHON_INCLUDE_DIRS} )
         set(HAVE_PYTHON 1)
     endif()


    This diff is for the python/r3 branch. I have both Python 2 and 3 developement packages installed, and CMake defaults to py3k as it should. With this change, from cmake I see:

    Code: Select all
    -- Found PythonLibs: /usr/lib64/libpython3.4m.so (found suitable version "3.4.3", minimum required is "3")


    Does this work for your system?

    Cheers,

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

    Re: FGPython an propose for Python as an nasal alternative

    Postby www2 » Sat Jan 23, 2016 3:33 pm

    I work on ubuntu 14.04
    and here is a work around:


    The problem seems to be that Ubuntu 14.04 installs Python 3.4 by default and the CMake version from Ubuntu ( 2.8 ) only searches up to Python 3.3. A workaround is to add set(Python_ADDITIONAL_VERSIONS 3.4) before the find_package statement. Note that I filed a bug about this issue.

    Since CMake 3.0, CMake searches up to Python 3.4, so installing that version manually should also fix the problem.


    source: http://askubuntu.com/a/515485
    www2
     
    Posts: 260
    Joined: Thu Apr 16, 2009 1:58 pm

    Re: FGPython an propose for Python as an nasal alternative

    Postby bugman » Sat Jan 23, 2016 3:57 pm

    Ok, I understand the CMake issue. Does this change work for you? It should set the minimum Python version to 3, as well as work around the CMake bug.

    Code: Select all
    diff --git a/CMakeLists.txt b/CMakeLists.txt
    index be91fb6..8c1a782 100644
    --- a/CMakeLists.txt
    +++ b/CMakeLists.txt
    @@ -315,7 +315,8 @@ endif (ENABLE_QT)
     ## Python setup
     if(ENABLE_PYTHON)
         message(STATUS "Embedded Python enabled, checking for the Python headers")
    -    find_package(PythonLibs REQUIRED)
    +    set(Python_ADDITIONAL_VERSIONS 3.4 3.5)    # CMake 2.8 bug workaround.
    +    find_package(PythonLibs 3 REQUIRED)
         include_directories( ${PYTHON_INCLUDE_DIRS} )
         set(HAVE_PYTHON 1)
     endif()


    Cheers,

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

    Re: FGPython an propose for Python as an nasal alternative

    Postby www2 » Sat Jan 23, 2016 5:23 pm

    that fix my problem.
    www2
     
    Posts: 260
    Joined: Thu Apr 16, 2009 1:58 pm

    Re: FGPython an propose for Python as an nasal alternative

    Postby bugman » Mon Jan 25, 2016 10:18 am

    www2 wrote in Sat Jan 23, 2016 2:39 am:This is a historic moment for python in FG:


    It is a good feeling, seeing this running so well :)

    Code: Select all
    diff --git a/src/Python/PythonSys.cxx b/src/Python/PythonSys.cxx
    index 4b654af..2f49ec1 100644
    --- a/src/Python/PythonSys.cxx
    +++ b/src/Python/PythonSys.cxx
    @@ -17,6 +17,7 @@
      * along with this program.  If not, see <http://www.gnu.org/licenses/>.
      */
     
    +
     #include <Python.h>
     
     #include <simgear/props/props.hxx>
    @@ -81,6 +82,12 @@ void FGPythonSys::init()
             PyRun_SimpleString("builtins.props = prop_tree.Props()");
             PyRun_SimpleString("del prop_tree");
             PyRun_SimpleString("del builtins");
    +        //add FGhome/Python
    +        PyRun_SimpleString("import sys");
    +        char FGpythonPath[512] = "";
    +        snprintf(FGpythonPath, 512,"sys.path.append('%s/Python')",globals->get_fg_root().c_str());
    +        PyRun_SimpleString(FGpythonPath);
    +        PyRun_SimpleString("del sys");
         }
     
         // Load all the scripts out of the property tree.



    I would like to now incorporate your patch. But I would like you to provide me with a commit that I can cherry-pick ;) For this, I have some code clean up suggestions:

      - An empty line before the comment.
      - Improved comment (start with capital, end with full stop, better description such as "Expand the Python module search path to include $FG_ROOT/Python.".
      - 512 seems a little short for a file path. Who knows where end users will put FGData. Maybe 1024? And put this in an all-caps variable in PythonSys.hxx.
      - Spaces after commas.

    It would be awesome if you could fork the main flightgear repository to your personal SourceForge account, track my python/r3 branch, create a new branch for this change, and push the branch. This way your contributions will be far more valuable to the advancement of FGPythonSys, and we could work in a much better collaboration.

    Cheers,

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

    Re: FGPython an propose for Python as an nasal alternative

    Postby www2 » Mon Jan 25, 2016 11:56 pm

    Thx for the feed back and soon i create an .
    I think to up scale the size from 512 to 4096.
    Be site this i start to work to port first nasal library to python (geo.nas) under fgstd.geo

    BTW how soon i can except canvas, settimer and navdb api in python?
    www2
     
    Posts: 260
    Joined: Thu Apr 16, 2009 1:58 pm

    Re: FGPython an propose for Python as an nasal alternative

    Postby Hooray » Tue Jan 26, 2016 9:20 am

    how soon i can except canvas, settimer and navdb api in python?


    Regarding settimer(), see bugman's comments on timers, which he considers a "hack" (workaround) that he would like to get rid of.
    However, keep in mind that there are certain hard-coded restrictions due to the way FlightGear's main loop is structured, so that timers and listeners may be the most straightforward mechanisms to implement a simple form of "scheduling" short of redesigning FlightGear's main loop altogether (think HLA/IPC).

    Also, like I mentioned previously, you would almost certainly want to use maketimer() or makelistener() to provide an OO interface that supports RAII.

    Regarding Canvas and the NavDB, I suggest to refer to the devel list comments, where a number of core developers are fairly outspoken against the idea of re-implementing Nasal functionality for Python.

    Regarding the whole RPC/IPC route for properties (non-HLA), I suggest to refer to Erik's original Remote Properties proposal, where subsystems would own a private property tree, of which certain state would be "mounted" in the global tree so that read/write requests would be dispatched to the owner of the corresponding sub-property tree branch (think /ai, /models, /autopilot etc), so that race conditions would never be an issue, even if each SGSubsystem would be running in its own thread.

    Equally, a number of other core developers have been contemplating a similar system:
    http://wiki.flightgear.org/Property_threading
    http://wiki.flightgear.org/Distributed_ ... FlightGear

    So you don't necessarily need HLA to do something like this - and the shared memory route does not have the latencies considered problematic by some people.


    Also, number of shortcomings linked to Nasal are not even remotely related to Nasal but are due to the way the FG main loop is working and the way extension functions are called - the fact being, Nasal is designed to be threadsafe in contrast to Python (no GIL in Nasal at all).

    The whole "setprop() bug" never was a bug at all, and we fixed it still (in fact, Torsten committed a patch that I provided, so I am familiar with that issue) - and at the end of the day, that was never about Nasal but about mis-using a FlightGear-specific extension function.

    To be honest, there's a lot to be said in the context of this discussion because the amount of ill-informed statements made by some very experienced contributors is a little discouraging. And the whole discussion we are currently seeing demonstrates fairly well that scripting in FlightGear is not just about being familiar with "a" scripting language, but primarily about being familiar with the main loop and reset/re-initialization process.

    As long as people don't understand these details, they may end up with a working python integration that will simply cause tons of race conditions.
    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: 11340
    Joined: Tue Mar 25, 2008 8:40 am

    Re: FGPython an propose for Python as an nasal alternative

    Postby bugman » Tue Jan 26, 2016 9:34 am

    www2 wrote in Mon Jan 25, 2016 11:56 pm:Thx for the feed back and soon i create an .
    I think to up scale the size from 512 to 4096.
    Be site this i start to work to port first nasal library to python (geo.nas) under fgstd.geo


    Great! I look forward to seeing your private branches, and to start pulling them into mine :) If this works well, then maybe I can set up a FGPythonSys development team on SourceForge, with a bug tracker and other open source infrastructure set up. Be prepared for a lot of feedback, as my Python coding standards are very high ;) To have Python accepted, we should aim for very well commented, documented, and nicely formatted code! I suggest we aim at about 30% documentation/comments, as I did with the py-ogel test.py file. The standard for acceptance should be set much higher than if you code normally.

    BTW how soon i can except canvas, settimer and navdb api in python?


    This is a difficult question, as this is not planned yet. I am looking into the timer concept, but this looks like a hack (and in private discussions, it has been labelled as a hack by some core developers as well). Therefore I am thinking of a better way to update aircraft. This is really the time to eliminate timers and come up with a far superior solution! If you have ideas, we should discuss this on the mailing list. I might send my aircraft as a subsystem ideas there for some feedback. For geo.nas, how would you like to use timers? Could you write some test Python code for this?

    For implementing a minor feature, the best would be if you wrote a Python test like I did with the py-ogel. So for example with the navdb, write a single unit test that performs a single operation. If you could write a test_*() Python function for each individual feature you would like, that would be ideal! I hope to take all of these tests and integrate them into a CppUnit test suite for FlightGear. If we have unit tests for each small bit of functionality you'd like implemented (ideally a few tests for each), then FGPythonSys would very quickly become the most stable and reliable part of FG - by far.

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

    Re: FGPython an propose for Python as an nasal alternative

    Postby Hooray » Tue Jan 26, 2016 9:42 am

    I am looking into the timer concept, but this looks like a hack (and in private discussions, it has been labelled as a hack by some core developers as well). Therefore I am thinking of a better way to update aircraft. This is really the time to eliminate timers and come up with a far superior solution! If you have ideas, we should discuss this on the mailing list.


    even if you had a true scheduling mechanism supported by the language itself, it would obviously need to be supported by the fgfs host application - like I said, Nasal outside fgfs is thread-safe, and designed to be thread-safe from the get-go. The threading related restrictions are entirely because of 1) the single-threaded main loop, 2) the way Nasal callbacks are invoked by fgfs (and vice versa), 3) none of the FG specific extension functions being designed/maintained with thread-safety in mind.

    In fact, if you were to use pure Nasal library calls (no FG specific stuff), you will have an object-oriented scripting language in FlightGear that supports multi-threading using a C-like syntax, heavily based on concepts borrowed from ECMAScript..

    the very instant you solve the threading issue at hand, you are also solving the GC issue too, because at that point, the GC would almost certainly no longer be running in the fgfs main loop. And that is not a thing that is specific to Python or Nasal.

    Which is why the comments on having IPC/RPC-enabled components using a mechanism like HLA were spot-on - sooner or later, you will ineviably want to share state beyond just messages, i.e. by havig arrays/vectors, classes, ADTs, objects etc - at that point you are likely to reinvent CORBA/DIS/HLA anyway
    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: 11340
    Joined: Tue Mar 25, 2008 8:40 am

    Re: FGPython an propose for Python as an nasal alternative

    Postby Hooray » Wed Jan 27, 2016 11:40 am

    bugman (on making FGPythonSys entirely optional) wrote:Any ideas how?


    Well, like I said, you really only need to look at $FG_SRC/Main/options.cxx - where you can add a --disable-python startup option that sets a boolean property.
    In fg_init.cxx you would then wrap your existing code which is already using a build switch:

    Code: Select all
    #ifdef HAVE_PYTHON
        ////////////////////////////////////////////////////////////////////////
        // Initialize the Python interpreter.
        ////////////////////////////////////////////////////////////////////////
    if (fgGetBool("/sim/startup/python-enabled", true)) {
        FGPythonSys* python = new FGPythonSys();
        globals->add_subsystem("python", python, SGSubsystemMgr::INIT);
        python->init();
        SG_LOG(SG_GENERAL, SG_INFO, "Python init took:" << st.elapsedMSec());
    } else
        SG_LOG(SG_GENERAL, SG_ALERT, "Integrated Python support disabled !");

    #endif


    Even without editing options.cxx you can test this by using the --prop: argument to set that property and make Python entirely optional.

    At run-time, you will probably want to make sure that reset/re-init works using the dedicated fgcommands that James added, e.g. using the helper script from:

    http://wiki.flightgear.org/Howto:Reset/ ... leshooting
    Image

    However, do note that you need to review/augment $FG_SRC/Main/subsystemFactory.cxx for that to work correctly, refer to the wiki article for details:

    http://wiki.flightgear.org/Howto:Create ... s%20on/off
    Another increasingly important consideration is designing your subsystem such that it can be safely re-initialized at runtime, using the subsystemFactory wrappers in $FG_SRC/Main and the corresponding fgcommands:

    - add-subsystem
    - remove-subsystem

    See this commit for more details: FlightGear commit 8608a480.

    Finally, you will also want to edit globals.?xx to ensure that your new subsystem is added to the destructor, so that it will be properly freed upon program termination.



    http://sourceforge.net/u/edauvergne/fli ... actory.cxx

    Once FGPythonSys is able to dynamically shutdown/restart using the corresponding fgcommands, and once it can be entirely disabled during startup, it would already be in a much better shape than 99% of the existing SGSubsystems in FlightGear, including recent additions made by core developers who are not overly aware of reset/re-init or HLA/RTI.

    Keep in mind that this could be considered the prerequisites for saving/loading sessions (flights) and for being able to load different aircraft at run-time - many of these features were crippled by the original "presets" work (prior to which was the last time saving/loading worked correctly), and got never fixed subsequently: http://wiki.flightgear.org/Fixing_Presets

    These days, new subsystems really need to be added with reset/re-init functionality in mind, which includes the capability to dynamically remove/add subsystems "on demand".
    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: 11340
    Joined: Tue Mar 25, 2008 8:40 am

    Re: FGPython an propose for Python as an nasal alternative

    Postby Hooray » Wed Jan 27, 2016 6:57 pm

    Regarding your fg_init.cxx commits: Note that you will need to wrap ALL your Python related changes in between #ifdef HAVE_PYTHON/#endif, including the python inclusion and the reset handling/python cleanup code etc - otherwise, people disabling Python support will end up with a broken build.

    Therefore I do not intend on sharing any of this Nasal infrastructure.

    You misunderstood, I was specifically referring to the interface you are duplicating right now - i.e. in terms of abstract methods like "loadPropertyScripts()", "resetInterpreter()" - none of the code would be identical, but the methods/abstract interface would stay the same, regardless of the scripting back-end, which is why FGNasalSys and FGPythonSys could basically inherit from a common "FGScriptingSystem" base class, which in turn inherits from SGSubsystem - at which point, the fg_init.cxx logic could be simplified for any/all scripting solutions supported by FG (imagine someone adding support for Lua, who could also use the same base class/interface).


    The idea of a base class for spawning SGSubsystems and talking to them via HLA has already been discussed "behind the scenes" (not really behind the scenes, but just not visible from this forum).


    to make that work, you would need to register a new extension function along the lines of "registerSubsystem()" and "unregisterSubsystem()", which takes a Python class as ist argument that inherits from the equivalent of the SGSubsystem/Mgr parent class, i.e. with init(), update(), reinit() etc methods

    The registerSubsystem() API would then look pretty much like what you have added to fg_init.cxx, but you would need to manually/expicitly initialize such classes, because intialization is likely to have completed already by then.

    From my coding experience I can say that this is not how it's done. It's more like this - serve up a concrete problem to solve, with code, data, scripts, etc., and that problem will be solved.

    right, that's exactly how Nasal ended up with timers and listeners for integrating code into the main loop, which -realistically- you cannot easily move away from short of redesigning the FlightGear design in a pretty invasive fashion (akin to HLA/RTI integration).

    Anyway, most of the OSM2City* stuff would seem to be of interest then, because it is entirely written in Python, and people have been wanting to use that functionality directly: http://wiki.flightgear.org/Using_OSM_Ve ... FlightGear

    Subject: OSM buidings EHLE
    zakalawe wrote:
    radi wrote in Wed Oct 23, 2013 11:49 am:Osm2city is smart enough to not place OSM buildings if there's a static one nearby. So if Julien's buildings are in terrasync, they should mix well.

    Ah fantastic, that sounds good indeed.

    A thought occurs - this is much more blue-sky, could we run a C++ version of the script in real-time? As an alternative / replacement for random-buildings. This relies on two assumptions: that the input data per tile is sensible sized (tens of kbytes, or worst case a hundred for centre of really built up city), and that the script could run in 'almost real time' on the OSG Pager thread.

    So we'd add the outline data as an additional file in each Objects/foo/foo/dir, and if this mode is enabled, look for the file and run the buildings creation script at that time.
    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: 11340
    Joined: Tue Mar 25, 2008 8:40 am

    PreviousNext

    Return to New features

    Who is online

    Users browsing this forum: No registered users and 0 guests