Python in FlightGear: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 42: Line 42:


== Open Issues ==
== Open Issues ==
 
=== Dependency Hell ===
{{FGCquote
|1= Having the training session as a separate network app instead of being integrated into FG is going to put off a lot of less technically minded people. It requires that the user first install Python + pyao + pyogg + pyvorvis. Then they have to install the training packages and try to start FG together with the simulator. I'd much rather code it in Nasal have it part of the FG package itself or as an addon that can be unipped into the FG tree and run as is.
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/11415067/
  | title  = <nowiki>Re: [Flightgear-devel] Lessons in FlightGear</nowiki>
  | author = <nowiki>Paul Surgeon</nowiki>
  | date  = Jan 5th, 2006
  | added  = Jan 5th, 2006
  | script_version = 0.23
  }}
}}
=== Garbage Collection ===
=== Garbage Collection ===
{{FGCquote
{{FGCquote

Revision as of 22:02, 28 December 2015

This article is a stub. You can help the wiki by expanding it.

Background

Cquote1.png 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.
Cquote2.png

Status

RFC

Objective

Motivation

Cquote1.png 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)
Cquote2.png

Open Issues

Dependency Hell

Cquote1.png Having the training session as a separate network app instead of being integrated into FG is going to put off a lot of less technically minded people. It requires that the user first install Python + pyao + pyogg + pyvorvis. Then they have to install the training packages and try to start FG together with the simulator. I'd much rather code it in Nasal have it part of the FG package itself or as an addon that can be unipped into the FG tree and run as is.
— Paul Surgeon (Jan 5th, 2006). Re: [Flightgear-devel] Lessons in FlightGear.
(powered by Instant-Cquotes)
Cquote2.png

Garbage Collection

Cquote1.png 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)
Cquote2.png
Cquote1.png 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)
Cquote2.png

Replacing Nasal ?

Cquote1.png But changing current scripts would be a huge, huge project. And it'd would require much more maintenance than our tiny Nasal engine. It's a better option to improve the existing garbage collector (i.e. use reference counting, improve its speed, or make it happen less often). But that would also be a very complex change in a very sensitive area of our sources.
— ThorstenB (Mar 26th, 2011). Re: [Flightgear-devel] Stuttering at 1 Hz rate.
(powered by Instant-Cquotes)
Cquote2.png

Converting Scripts

Cquote1.png Such things may look simple at first. Easy to convert a simple "hello world". But it's very complex when supporting all the features of an interpreted script language. And the funny thing is: you'd still need to worry about automatic garbage collection and count references (though that'd be a lesser issue compared to many others then). So, time wake up...
— ThorstenB (Mar 26th, 2011). Re: [Flightgear-devel] Stuttering at 1 Hz rate.
(powered by Instant-Cquotes)
Cquote2.png