20,741
edits
Line 84: | Line 84: | ||
| date = Dec 31st, 2015 | | date = Dec 31st, 2015 | ||
| added = Dec 31st, 2015 | | added = Dec 31st, 2015 | ||
| script_version = 0.23 | |||
}} | |||
}} | |||
== Approach == | |||
{{FGCquote | |||
|1= The first thing is to embed the interpreter. The second is to access the property tree. The third might be to wait for a HLA compatible solution for the property tree to be added to FG, then hooking the Python interpreter into that. I also don't understand the HLA push here, because HLA is a slow technology (just like most multi-processor solutions). I have extensive experience with clustering, and I am well aware of the disadvantages of HLA. However certain built-in modules could provide HLA access to certain functionality. This can all be done down the line - planning for it now is really too much. | |||
Finally, this would all have to be done in C. From the main program, you interact with embedded Python only using C code, via the embedded Python C interface. Therefore the person implementing this needs to either know C, or is willing to learn C. | |||
|2= {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=270666#p270666 | |||
| title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | |||
| author = <nowiki>bugman</nowiki> | |||
| date = Dec 30th, 2015 | |||
| added = Dec 30th, 2015 | |||
| script_version = 0.23 | | script_version = 0.23 | ||
}} | }} |