Re: Hound dog departed
Posted: Thu Oct 06, 2016 4:26 pm
Also more users would know python which means more development
An independent forum for FlightGear users and developers
https://www.thejabberwocky.net/
Hi Thorsten,
i'm pretty sure the original poster was simply using an "eye catcher" technique for the subject. It's clear from his tone that he wishes to engage in a positive discussion of these topics. I think when you said "Then I must have misunderstood", you really did read the original message too hastily and really did misunderstand.
https://forum.flightgear.org/viewtopic.php?f=30&t=30606&p=296166#p296166
King George III wrote:Python is a personal interest of mine. I have my own separate UAV autopilot app that used the FlightGear property system. Last winter I redesigned the property system to be based on python core code and built a C++ interface to the python-property system. In the process I took the opportunity to fork off my direction and make substantial changes to my own property system API. However, this required going and porting all my code to the new property system api and testing it. Recently I added json support so that the config files can be json instead of xml. This has some advantages and I found that json mapped a whole lot more naturally to my new python-based property system. The json load/parse/save code is probably half the lines of code compared to the equivalent xml load/parse/save code.
The advantage of a python-based property system is that now embedded python scripts have native access to the property tree and can run any time and read/write values directly. I find this has is a very very powerful approach that enables freely mixing C++ and python modules. It enables me to rewrite big chunks (non-performance critical chunks) of my flight controller in native python. That leads to maybe 50% code reduction, clearer code, simpler code, etc. I also discovered that python's standard library of tools is conceptually very similar to SimGear. For every SimGear library or module, there's almost always a similar if not equivalent python module available to import.
So I like python for non-performance critical coding ... however ...
It is really important to note that in my small application which is probably 1/10 or 1/100th the size of FlightGear, this was a truly massive undertaking to make these changes ... on the order of 2-3 months of pretty much non-stop effort. For FlightGear it would be almost insurmountable...
IAHM-COL wrote:https://forum.flightgear.org/viewtopic.php?f=30&t=30606#p296166King George III wrote:Python is a personal interest of mine. I have my own separate UAV autopilot app that used the FlightGear property system. Last winter I redesigned the property system to be based on python core code and built a C++ interface to the python-property system. In the process I took the opportunity to fork off my direction and make substantial changes to my own property system API. However, this required going and porting all my code to the new property system api and testing it. Recently I added json support so that the config files can be json instead of xml. This has some advantages and I found that json mapped a whole lot more naturally to my new python-based property system. The json load/parse/save code is probably half the lines of code compared to the equivalent xml load/parse/save code.
The advantage of a python-based property system is that now embedded python scripts have native access to the property tree and can run any time and read/write values directly. I find this has is a very very powerful approach that enables freely mixing C++ and python modules. It enables me to rewrite big chunks (non-performance critical chunks) of my flight controller in native python. That leads to maybe 50% code reduction, clearer code, simpler code, etc. I also discovered that python's standard library of tools is conceptually very similar to SimGear. For every SimGear library or module, there's almost always a similar if not equivalent python module available to import.
So I like python for non-performance critical coding ... however ...
It is really important to note that in my small application which is probably 1/10 or 1/100th the size of FlightGear, this was a truly massive undertaking to make these changes ... on the order of 2-3 months of pretty much non-stop effort. For FlightGear it would be almost insurmountable...
The Real "WTF" moment, is
Why is curtis *(a core developer)* making such great contributions on a private fork he is keeping for himself?
Is it really unsurmountable for FG? It sounds like big-daddy gave up somehow on the feasibility of his project?