Re: [Flightgear-devel] A FGPythonSys implementation: The embedded Python interpreter as a FlightGear subsystem.

[Edward d'A. <tru...@gm...>]

On 26 January 2016 at 18:42, Thorsten Renk
<tho...@sc...> wrote:
>> If we look at it
>> from the standpoint of what toys do people wish to bring into the sandbox
>> to play with, then some of these technical arguments and demanding
>> answers to one's personal level of satisfaction seem a little silly.
>> Prove your
>> truck can haul more sand than the one we already have?  Prove your shovel
>> and bucket are better than mine?  Do you like yours only because it's red
>> plastic and not yellow?
>
> With all due respect, I think that's a little of an unfair a point to make.
>
> Lots of the discussion have been 'what if' scenarios. You've commented in
> the forum that bold research missions would never have flown if people
> would always ask that. But - when would you like to have these discussions
> instead? Would you really prefer that people invest a man year of work and
> then we all have a discussion whether it's going to be used or not? To me,
> it seems more productive to have them up-front, even when there are things
> we can not (yet) know.
>
> Also, personally I'd like to form an educated opinion. Which is why I ask
> (sometimes provocative) questions like 'why do we actually want this?'.
> I'd like to understand early how a change affects my experience both as
> contributor and as user - not when it's all too late and I suddenly
> discover I just got accidentially kicked out of the loop. It's true that a
> proposal to add n optional scripting languages integrated a certain way
> doesn't affect either my user or my contributor experience, but the
> close-by proposal of replacing Nasal does, and so does the optional
> scripting language integrated in a different way. I don't think it's
> unfair or silly to keep asking till I have a clear picture of what
> different people might envision and what that implies.
>
> Finally, I also don't think it's fundamentally silly to ask why people
> think any proposed change would be beneficial for FG and what problem
> they're trying to solve. If only because the discussion might reveal
> there's a better way to solve the same problem.

Hi Thorsten,

Like I've mentioned a few times, I have no interest in replacing
Nasal.  The code I've written cannot do this, I would probably be
against any suggestion in the future to do so.  This was only
mentioned in one post.

The code came about by chance, out of discussions with Curt about
problems he is working on with Python.  I wrote the property tree
object code to learn more about the Python object design.  Converting
the Python C/C++ module into FGPythonSys was trivial.  Then I offered
it here as an option that defaults to OFF in the CMake file.  There
are likely to be people who would benefit from this initial code,
including some core developers - hence the original post.  The code is
very clean and isolated, and I am quite capable of expanding on this
Python/C++ interface.  I have interest in learning more about the
internals of FlightGear, and adding a Python/C++ interface to each
component in the process.  I'm looking forward to some feedback and
Python code from Jean-Paul to start working on a NavDataCache
interface, to create a 'nav_data_cache' or 'navdb' Python C/C++
module.

I also had the idea of running this subsystem in a thread.  This
avoids adding more strain to the main loop, making FGPythonSys even
more inconspicuous.  And it has downstream benefits, in that I'll be
hitting many of the problems often discussed on this mailing list, and
hitting them very hard.  Asynchronous access to the navdb cache is one
such problem.  Racing is another - some parts of FlightGear uses
SGThreads (such as parts of the sound system).  With Python pushing on
the code paths prone to racing, with easy to write tests to put huge
amounts of strain on the system, I could help improve these parts.  I
see this as beneficial for the project, even if the Python initiative
goes nowhere.  Anyway, maybe this threaded subsystem idea is too
controversial.

However I believe that Python is one of the simplest languages to
learn.  And it regularly ranked in the top 5 programming languages.
Therefore I think this is attractive to include as an option for
students, researchers, and others interested in experimenting.  This
can give them a modular tool to leverage the lowest levels of
FlightGear, an angle that Nasal currently does not, and has no
intention to provide.  And this all comes back to the original point
the code was written for!

Regards,

Edward