Python in FlightGear: Difference between revisions
Jump to navigation
Jump to search
(http://forum.flightgear.org/viewtopic.php?f=6&t=28378) |
No edit summary |
||
| Line 29: | Line 29: | ||
== Motivation == | == Motivation == | ||
{{FGCquote | |||
|1= Python support would be a great feature I think. It is used in many products (e.g. in Blender) and that is a plus. However it's not guaranteed that it is free of such problems until you port all current Nasal scripts to Python and test it. What I am thinking about is a possibility to convert Nasal scripts to C or C++ and compile them as shared objects (.so .dll). Then we could load them dynamically at fgfs runtime. So in the end we get raw C/C++ performance to our modules. Is this possible or am I dreaming of something impossible here? What do you think? | |||
|2= {{cite web | |||
| url = http://sourceforge.net/p/flightgear/mailman/message/27261734/ | |||
| title = <nowiki>Re: [Flightgear-devel] Stuttering at 1 Hz rate</nowiki> | |||
| author = <nowiki>Robert</nowiki> | |||
| date = Mar 26th, 2011 | |||
| added = Mar 26th, 2011 | |||
| script_version = 0.23 | |||
}} | |||
}} | |||
== Open Issues == | |||
=== Garbage Collection === | |||
{{FGCquote | |||
|1= Does anybody of you know how garbage collectors of Java and Python and other GPL'd script engines compare to each other? (atomic step character) | |||
|2= {{cite web | |||
| url = http://sourceforge.net/p/flightgear/mailman/message/27345119/ | |||
| title = <nowiki>Re: [Flightgear-devel] Nasal Garbage Collector (was Stuttering at 1 | |||
Hz rate)</nowiki> | |||
| author = <nowiki>Robert</nowiki> | |||
| date = Apr 11th, 2011 | |||
| added = Apr 11th, 2011 | |||
| script_version = 0.23 | |||
}} | |||
}} | |||
{{FGCquote | |||
|1= Reference counting doesn't provide a strong performance advantage over conventional garbage collection, and a reference-counting scheme can take an unbounded amount of time. Reference counting schemes that do have real-time or bounded behavior are very complicated. I don't know much about our Nasal implementation, but I suspect that the garbage collector could be changed to trace only a portion of Nasal's heap at each invocation, at the risk of increased memory use. | |||
|2= {{cite web | |||
| url = http://sourceforge.net/p/flightgear/mailman/message/27262091/ | |||
| title = <nowiki>Re: [Flightgear-devel] Stuttering at 1 Hz rate</nowiki> | |||
| author = <nowiki>Tim Moore</nowiki> | |||
| date = Mar 26th, 2011 | |||
| added = Mar 26th, 2011 | |||
| script_version = 0.23 | |||
}} | |||
}} | |||
<references/> | <references/> | ||
Revision as of 21:59, 28 December 2015
| This article is a stub. You can help the wiki by expanding it. |
Background
|
This is a follow up of a discussion that I have with one of the devs at fg weekend 2015.
My propose is that we include python 3 as an alternative for nasal. This mean not that nasal is bad, but I can writing code in python faster than nasal. (this is only my opinion and experience) Another plus for python re can create a standalone interface that connect to fgfs or play a flight from an recode session for cockpit building or testing new code. What is your considers about Python as an nasal alternative? Sorry this is short post, more in the future.— www2 (Dec 28th, 2015). FGPython an propose for Python as an nasal alternative.
(powered by Instant-Cquotes) |
|
Status
RFC
Objective
Motivation
|
|
Python support would be a great feature I think. It is used in many products (e.g. in Blender) and that is a plus. However it's not guaranteed that it is free of such problems until you port all current Nasal scripts to Python and test it. What I am thinking about is a possibility to convert Nasal scripts to C or C++ and compile them as shared objects (.so .dll). Then we could load them dynamically at fgfs runtime. So in the end we get raw C/C++ performance to our modules. Is this possible or am I dreaming of something impossible here? What do you think? — Robert (Mar 26th, 2011). Re: [Flightgear-devel] Stuttering at 1 Hz rate.
(powered by Instant-Cquotes) |
|
Open Issues
Garbage Collection
|
|
Does anybody of you know how garbage collectors of Java and Python and other GPL'd script engines compare to each other? (atomic step character) — Robert (Apr 11th, 2011). Re: [Flightgear-devel] Nasal Garbage Collector (was Stuttering at 1
Hz rate).
(powered by Instant-Cquotes) |
|
|
|
Reference counting doesn't provide a strong performance advantage over conventional garbage collection, and a reference-counting scheme can take an unbounded amount of time. Reference counting schemes that do have real-time or bounded behavior are very complicated. I don't know much about our Nasal implementation, but I suspect that the garbage collector could be changed to trace only a portion of Nasal's heap at each invocation, at the risk of increased memory use. — Tim Moore (Mar 26th, 2011). Re: [Flightgear-devel] Stuttering at 1 Hz rate.
(powered by Instant-Cquotes) |
|