FlightGear wiki

FGPythonSys: Difference between revisions

Page Discussion

FGPythonSys (view source)

Revision as of 11:17, 8 June 2019

18,781 bytes added ,  8 June 2019
m
Switch to the {{forum url}} and {{forum link}} templates for all forum links.
m (Switch to the {{forum url}} and {{forum link}} templates for all forum links.)
 
(27 intermediate revisions by one other user not shown)
Line 13: Line 13:
|status      = Under active development as of 01/2017
|status      = Under active development as of 01/2017
|maintainers = {{usr|bugman}}
|maintainers = {{usr|bugman}}
|developers  = bugman (since 01/2016)  
|developers  = bugman (since 01/2016), www2 <ref>{{forum url|p=274654}}</ref>
<!--
<!--
|changelog = {{Git File History|project=flightgear|path=/src/GUI/QtLauncher.cxx}}
|changelog = {{Git File History|project=flightgear|path=/src/GUI/QtLauncher.cxx}}
-->
-->
}}
}}
{{Main article|Modernizing FlightGear Scripting}}
The point of FGPythonSys is simply implementing something for fun - pretty much the same reason that most things in open source are done.  I find that justifying its existence is a little pointless.  Anyway, one interesting thing that could be designed would be a set of aircraft base classes in FGData implementing some basic functionality/instruments/systems, etc.  Then the aircraft can use OO (object oriented) inheritance to expand on the base class in an aircraft specific way.  Of course this could be done in Nasal, but Python's OO design is far more advanced, especially with GC (garbage collection).  Not that such arguments are relevant ;)
By the way, I'm thinking that aircraft/content Python would be a restricted subset of the full Python framework.  Anyway, all of this is in the realm of fantasy unless people are willing to get their hands dirty and play with C++  code.<ref>{{cite web
  |url    =  {{forum url|p=296255}}
  |title  =  <nowiki> Re: Nasal must go </nowiki>
  |author =  <nowiki> bugman </nowiki>
  |date  =  Oct 8th, 2016
  |added  =  Oct 8th, 2016
  |script_version = 0.40
  }}</ref>


== What is it ==
== What is it ==
Line 53: Line 66:


== Getting involved ==
== Getting involved ==
On Linux, you will want to make sure that the python3-dev package is installed, you can then set up remote tracking branches for the sg/fg and fgdata repositories, e.g.:
Talking about building something awesome, do you have coding skills?  If so, what is your opinion of code implementation via test suites?  If you are interested in converting your dreams into any type of reality, then join in the thread at {{forum link|p=289080}}, git check out my FGPythonSys branches (into clones of the official repositories), and start implementing awesome new features <ref>{{cite web
  |url    =  {{forum url|p=296226}}
  |title  =  <nowiki> Re: Nasal must go </nowiki>
  |author =  <nowiki> bugman </nowiki>
  |date  =  Oct 7th, 2016
  |added  =  Oct 7th, 2016
  |script_version = 0.40
  }}</ref>
 
 
On Linux, you will want to make sure that the python3-dev and cppunit packages are installed (e.g. <code>sudo apt-get install python3-dev cppunit</code>, you can then set up remote tracking branches for the sg/fg and fgdata repositories, e.g.:


<pre>
<pre>
Line 62: Line 85:


{{FGCquote
{{FGCquote
|1= The code is in the branches:
|1= Just a quick update on the FGPythonSys experiment, I have push some new branches based on 2016.2.0:
* [https://sourceforge.net/u/edauvergne/flightgear/ci/python/r3/~/tree/ https://sourceforge.net/u/edauvergne/flightgear/ci/python/r3/~/tree/]
[https://sourceforge.net/u/edauvergne/flightgear/ci/python/r6/~/tree/ u-edauvergne-flightgear python/r6 branch]
* [https://sourceforge.net/u/edauvergne/simgear/ci/python/r2/~/tree/ https://sourceforge.net/u/edauvergne/simgear/ci/python/r2/~/tree/]
 
* https://sourceforge.net/u/edauvergne/fgdata/ci/python/r1/~/tree/
[https://sourceforge.net/u/edauvergne/simgear/ci/python/r4/~/tree/ u-edauvergne-simgear python/r4 branch]
 
[https://sourceforge.net/u/edauvergne/fgdata/ci/python/r2/~/tree/ u-edauvergne-fgdata python/r2 branch]
I have shifted everything around so that these branches are based on my test suite branches ([https://sourceforge.net/u/edauvergne/flightgear/ci/cppunit/r4/~/tree/ u-edauvergne-flightgear cppunit/r4] and [https://sourceforge.net/u/edauvergne/simgear/ci/cppunit/r3/~/tree/ u-edauvergne-simgear cppunit/r3]).  This means that if you install the dependency-free [https://wiki.freedesktop.org/www/Software/cppunit/ CppUnit] package and run "make test_suite", you will see 100% of FGPythonSys tested.  This is via 242 passing tests, and one deliberately failing yet temporary test.  I recommend that any Python developments based off my branches take full advantage of this infrastructure - creating tests for this infrastructure is very easy - and that the test suite remains at a 100% pass rate.
 
 
|2= {{cite web
|2= {{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=273758#p273758
   | url    = {{forum url|p=276624}}
   | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
   | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
   | author = <nowiki>bugman</nowiki>
   | author = <nowiki>bugman</nowiki>
  | date  = Feb 19th, 2016
  | added  = Feb 19th, 2016
  | script_version = 0.25
  }}
}}
{{FGCquote
|1= there is a test aircraft - the py-ogeL, a copy of Torsten's ogeL with <python> tags and scripts added: https://sourceforge.net/u/edauvergne/code-py-ogel/ci/python/tree/ The py-ogel included test.py Python script is a complete test suite of the current state of the Python property tree
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34787850/
  | title  = <nowiki>[Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem.</nowiki>
  | author = <nowiki>Edward d'Auvergne</nowiki>
   | date  = Jan 22nd, 2016
   | date  = Jan 22nd, 2016
  | added  = Jan 22nd, 2016
  | script_version = 0.23
   }}
   }}
}}
}}
Line 79: Line 118:
|1= It would be awesome if you could fork the main flightgear repository to your personal SourceForge account, track my python/r3 branch, create a new branch for this change, and push the branch.  This way your contributions will be far more valuable to the advancement of FGPythonSys, and we could work in a much better collaboration.
|1= It would be awesome if you could fork the main flightgear repository to your personal SourceForge account, track my python/r3 branch, create a new branch for this change, and push the branch.  This way your contributions will be far more valuable to the advancement of FGPythonSys, and we could work in a much better collaboration.
|2= {{cite web
|2= {{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=273989#p273989
   | url    = {{forum url|p=273989}}
   | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
   | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
   | author = <nowiki>bugman</nowiki>
   | author = <nowiki>bugman</nowiki>
Line 91: Line 130:
|1= I look forward to seeing your private branches, and to start pulling them into mine :)  If this works well, then maybe I can set up a FGPythonSys development team on SourceForge, with a bug tracker and other open source infrastructure set up.  Be prepared for a lot of feedback, as [http://www.nmr-relax.com/manual/Coding_conventions.html my Python coding standards are very high] ;)  To have Python accepted, we should aim for very well commented, documented, and nicely formatted code!  I suggest we aim at about 30% documentation/comments, as I did with the [https://sourceforge.net/u/edauvergne/code-py-ogel/ci/python/tree/test.py py-ogel test.py file].  The standard for acceptance should be set much higher than if you code normally.
|1= I look forward to seeing your private branches, and to start pulling them into mine :)  If this works well, then maybe I can set up a FGPythonSys development team on SourceForge, with a bug tracker and other open source infrastructure set up.  Be prepared for a lot of feedback, as [http://www.nmr-relax.com/manual/Coding_conventions.html my Python coding standards are very high] ;)  To have Python accepted, we should aim for very well commented, documented, and nicely formatted code!  I suggest we aim at about 30% documentation/comments, as I did with the [https://sourceforge.net/u/edauvergne/code-py-ogel/ci/python/tree/test.py py-ogel test.py file].  The standard for acceptance should be set much higher than if you code normally.
|2= {{cite web
|2= {{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=274097#p274097
   | url    = {{forum url|p=274097}}
   | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
   | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
   | author = <nowiki>bugman</nowiki>
   | author = <nowiki>bugman</nowiki>
Line 103: Line 142:
|1= For implementing a minor feature, the best would be if you wrote [https://sourceforge.net/u/edauvergne/code-py-ogel/ci/python/tree/test.py a Python test like I did with the py-ogel].  So for example with the navdb, write a single unit test that performs a single operation.  If you could write a test_*() Python function for each individual feature you would like, that would be ideal!  I hope to take all of these tests and integrate them into a CppUnit test suite for FlightGear.  If we have unit tests for each small bit of functionality you'd like implemented (ideally a few tests for each), then FGPythonSys would very quickly become the most stable and reliable part of FG - by far.
|1= For implementing a minor feature, the best would be if you wrote [https://sourceforge.net/u/edauvergne/code-py-ogel/ci/python/tree/test.py a Python test like I did with the py-ogel].  So for example with the navdb, write a single unit test that performs a single operation.  If you could write a test_*() Python function for each individual feature you would like, that would be ideal!  I hope to take all of these tests and integrate them into a CppUnit test suite for FlightGear.  If we have unit tests for each small bit of functionality you'd like implemented (ideally a few tests for each), then FGPythonSys would very quickly become the most stable and reliable part of FG - by far.
|2= {{cite web
|2= {{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=274097#p274097
   | url    = {{forum url|p=274097}}
   | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
   | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
   | author = <nowiki>bugman</nowiki>
   | author = <nowiki>bugman</nowiki>
Line 113: Line 152:


== Vision ==
== Vision ==
{{FGCquote
|1= I like the idea of being able to use Python directly in FG. As many others, I have a bad intuition concerning the security implications if this were open to general aircraft scripting (even though I would love using Python instead of Nasal for that)
|2= {{cite web
  | url    = {{forum url|p=275923}}
  | title  = <nowiki>Re: Announcing FFGo: a new FlightGear launcher</nowiki>
  | author = <nowiki>rominet</nowiki>
  | date  = Feb 12th, 2016
  | added  = Feb 12th, 2016
  | script_version = 0.23
  }}
}}
{{FGCquote
{{FGCquote
|1= 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!
|1= 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!
Line 190: Line 241:
|1= Contrary to FGo! up to 1.5.5, it requires Python 3.4 or later, not Python 2. Because of this and the new dependency on [http://people.via.ecp.fr/~flo/projects/CondConfigParser/ CondConfigParser], the software requirements are a bit different from those of FGo!
|1= Contrary to FGo! up to 1.5.5, it requires Python 3.4 or later, not Python 2. Because of this and the new dependency on [http://people.via.ecp.fr/~flo/projects/CondConfigParser/ CondConfigParser], the software requirements are a bit different from those of FGo!
|2= {{cite web
|2= {{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=253044#p253044
   | url    = {{forum url|p=253044}}
   | title  = <nowiki>Announcing </nowiki>
   | title  = <nowiki>Announcing </nowiki>
   | author = <nowiki>rominet</nowiki>
   | author = <nowiki>rominet</nowiki>
   | date  = Aug 4th, 2015
   | date  = Aug 4th, 2015
   | added  = Aug 4th, 2015
   | added  = Aug 4th, 2015
  | script_version = 0.23
  }}
}}
{{FGCquote
|1= The built-in launcher that James is writing would seem to me to be a good candidate for doing things in Python (assuming there are good bindings to the C++ data structures): you need high-level access to FG aircraft and airport data, it is not performance critical, the need for threading is certainly rather limited, the code does not come from a random hangar and can be audited just like the C++ code when committed, probably by more people actually. Add to this that PyQt works very well (I have had a very pleasant experience with PyQt 3&amp;4 under Python 2&amp;3, and if I get enough time, I'll maybe port FFGo to PyQt---Tk is useful, clearly, but frustrating; for example Qt's QAbstractItemModel and QAbstractItemView were great to manage non-trivial tablular data; with Tk, table/tree cells are just strings and your program has to manage on its own to link that to the nice high-level Python data structures).
|2= {{cite web
  | url    = {{forum url|p=275923}}
  | title  = <nowiki>Re: Announcing FFGo: a new FlightGear launcher</nowiki>
  | author = <nowiki>rominet</nowiki>
  | date  = Feb 12th, 2016
  | added  = Feb 12th, 2016
  | script_version = 0.23
  }}
}}
{{FGCquote
|1= depending on how much progress bugman is going to make with his "python-integration-in-FlightGear" experiments  (FGPythonSys), we may at some point even be able to ship FFGo as part of FGData (e.g. $FG_ROOT/Python/Apps/FFGo) and run it via FGPythonSys directly
|2= {{cite web
  | url    = {{forum url|p=275910}}
  | title  = <nowiki>Re: Announcing FFGo: a new FlightGear launcher</nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date  = Feb 12th, 2016
  | added  = Feb 12th, 2016
  | script_version = 0.23
  }}
}}
{{FGCquote
|1= One interesting thing that FGPythonSys could probably bring to FFGo would be, I think, FG-compliant parsing of aircraft data. For now, I haven't done that because I found that the interesting metadata (e.g., aircraft radius) is not necessarily in the -set file, but may be included from a different one. And maybe a correct parser for these things must also handle conditions in the XML data, etc. So, despite knowing the declared radius of parking positions, I haven't provided any hint yet in comparison to the selected aircraft's radius for these reasons (and lack of time).
|2= {{cite web
  | url    = {{forum url|p=275923}}
  | title  = <nowiki>Re: Announcing FFGo: a new FlightGear launcher</nowiki>
  | author = <nowiki>rominet</nowiki>
  | date  = Feb 12th, 2016
  | added  = Feb 12th, 2016
   | script_version = 0.23
   | script_version = 0.23
   }}
   }}
Line 205: Line 293:
|1= If I were to start writing terragear today, I would definitely start down that path in python.  Obviously we can't do anything too intensive per-frame in a scripting language.
|1= If I were to start writing terragear today, I would definitely start down that path in python.  Obviously we can't do anything too intensive per-frame in a scripting language.
|2= {{cite web
|2= {{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=270386#p270386
   | url    = {{forum url|p=270386}}
   | title  = <nowiki>Re: FGPython an propose for </nowiki>
   | title  = <nowiki>Re: FGPython an propose for </nowiki>
   | author = <nowiki>curt</nowiki>
   | author = <nowiki>curt</nowiki>
Line 215: Line 303:


=== OSM2City ===
=== OSM2City ===
{{See also|Project3000}}
{{FGCquote
{{FGCquote
|1= could we run a C++ version of the script in real-time? As an alternative / replacement for random-buildings. This relies on two assumptions: that the input data per tile is sensible sied (tens of kbytes, or worst case a hundred for centre of really built up city), and that the script could run in 'almost real time' on the OSG Pager thread.
|1= could we run a C++ version of the script in real-time? As an alternative / replacement for random-buildings. This relies on two assumptions: that the input data per tile is sensible sied (tens of kbytes, or worst case a hundred for centre of really built up city), and that the script could run in 'almost real time' on the OSG Pager thread.
So we'd add the outline data as an additional file in each Objects/foo/foo/dir, and if this mode is enabled, look for the file and run the buildings creation script at that time.
So we'd add the outline data as an additional file in each Objects/foo/foo/dir, and if this mode is enabled, look for the file and run the buildings creation script at that time.
|2= {{cite web
|2= {{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=192380#p192380
   | url    = {{forum url|p=192380}}
   | title  = <nowiki>Re: OSM buidings EHLE</nowiki>
   | title  = <nowiki>Re: OSM buidings EHLE</nowiki>
   | author = <nowiki>zakalawe</nowiki>
   | author = <nowiki>zakalawe</nowiki>
Line 229: Line 318:


== Development ==
== Development ==
=== Testing ===
Edward d'Auvergne has been implementing a test suite infrastructure using CppUnit for flightgear itself (not simgear) as part of his FGPythonSys experiments [1], and noticed that modularisation is problematic due to the dependency of globals and everything that then brings in. I wonder if coming up with a way of breaking the dependency on globals.hxx - passing the data structure (or a mimic in the case of a functional test) into the subsystem using the new subsystem infrastructure, using property subtrees and synchronisation, etc. would allow the subsystems to be truly independent. <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35516739/
  |title  =  <nowiki> Re: [Flightgear-devel] RFC: Improving FlightGear's modularity </nowiki>
  |author =  <nowiki> Edward d'Auvergne </nowiki>
  |date  =  Nov 27th, 2016
  |added  =  Nov 27th, 2016
  |script_version = 0.40
  }}</ref>
Edward developed this as part of his FGPythonSys experiments to have full system test coverage [1]. The test suite is based on the venerable, yet old CppUnit framework [2]. Edward d'Auvergne has spun this out into its own standalone branches rebased to 2016.4.0 and made independent of embedded Python [3]. The test suite is an almost direct Python->C++ translation my own comprehensive test suite for one of my own software projects [4]. The benefits of such a framework, assuming a good test coverage, include: - Enabling quick and brutal refactorisation of the entire code base - ensuring that the end result works perfectly well. - Interest in independence and modularisation of all FlightGear components to simplify tests. - If all subsystems are tested for standalone creation, destruction, init(), reinit(), shutdown(), etc., then repetitive resetting of FlightGear should work flawlessly. - Allow valgrind and other heavy tools to be run on the absolute minimal code paths, by running individual tests. The functionality of the test suite can be very much expanded in the future [5]. For example there are CppUnit classes for XML output, rather than text, so this test suite is ideal for automated testing and presenting the results through web pages (e.g. Jenkins).<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35661026/
  |title  =  <nowiki> [Flightgear-devel] A FlightGear test suite using CppUnit. </nowiki>
  |author =  <nowiki> Edward d'Auvergne </nowiki>
  |date  =  Feb 11th, 2017
  |added  =  Feb 11th, 2017
  |script_version = 0.40
  }}</ref>


=== Reset/re-init ===
=== Reset/re-init ===
Line 234: Line 342:
|1= Once FGPythonSys is able to dynamically shutdown/restart using the corresponding fgcommands, and once it can be entirely disabled during startup, it would already be in a much better shape than 99% of the existing SGSubsystems in FlightGear
|1= Once FGPythonSys is able to dynamically shutdown/restart using the corresponding fgcommands, and once it can be entirely disabled during startup, it would already be in a much better shape than 99% of the existing SGSubsystems in FlightGear
|2= {{cite web
|2= {{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=274199#p274199
   | url    = {{forum url|p=274199}}
   | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
   | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
   | author = <nowiki>Hooray</nowiki>
   | author = <nowiki>Hooray</nowiki>
Line 248: Line 356:
The registerSubsystem() API would then look pretty much like what you have added to fg_init.cxx, but you would need to manually/expicitly initialie such classes, because intialization is likely to have completed already by then.
The registerSubsystem() API would then look pretty much like what you have added to fg_init.cxx, but you would need to manually/expicitly initialie such classes, because intialization is likely to have completed already by then.
|2= {{cite web
|2= {{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=274234#p274234
   | url    = {{forum url|p=274234}}
   | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
   | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
   | author = <nowiki>Hooray</nowiki>
   | author = <nowiki>Hooray</nowiki>
Line 256: Line 364:
   }}
   }}
}}
}}
=== Understanding Nasal APIs ===
{{FGCquote
|1= I can construct powerful Python/C API interfaces very quickly, something I cannot do with Nasal.
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34793466/
  | title  = <nowiki>Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem.</nowiki>
  | author = <nowiki>Edward d'Auvergne</nowiki>
  | date  = Jan 25th, 2016
  | added  = Jan 25th, 2016
  | script_version = 0.23
  }}
}}
The Nasal C APIs are pretty straightforward actually (especially for people familiar with C and embedded scripting), and it may make sense to look at the corresponding docs - even if just to learn how to port existing Nasal APIs to Python:
* [[Howto:Extend Nasal]]
* [[Nasal/CppBind]]


== Status ==
== Status ==
the focus of the efforts in my experimental {{forum link|hilit=python|p=289080|text=FGPythonSys branches}} is more to provide a Python interface to core FlightGear programming rather than replace Nasal.  For example one aim is to convert the whole of the SimGear programming interface (API) into a Python library.  Another is to expose the subsystem interface to allow for Python modules to create new FlightGear subsystems.  As a biarre aside, if FGPythonSys was designed to replace Nasal, it would also be able to fully replace the XML parts of aircraft as well.
In any case, I have been a bit busy with RL and there is no one helping in the task of advancing FGPythonSys.  So at this rate, replacing Nasal with Python will only be a pipe dream for a few content developers.<ref>{{cite web
  |url    =  {{forum url|p=296170}}
  |title  =  <nowiki> Re: Nasal must go </nowiki>
  |author =  <nowiki> bugman </nowiki>
  |date  =  Oct 6th, 2016
  |added  =  Oct 6th, 2016
  |script_version = 0.40
  }}</ref>
Here is another update for the FGPythonSys code.  I have rebased the branches on the current 2016.4.0 flightgear/simgear/fgdata branches.  Not only that, but the branches now work on MS Windows.  As these worked on GNU/Linux previously, and Mac OS X should just work, the branches should now be functional on all operating systems!  Note though that only the CppUnit code needed updating to work on MS Windows, the Python code worked without modification.  The branches are:
* [https://sourceforge.net/u/edauvergne/flightgear/ci/python/r9/~/tree/ u-edauvergne-flightgear python/r9 branch]
* [https://sourceforge.net/u/edauvergne/simgear/ci/python/r6/~/tree/ u-edauvergne-simgear python/r6 branch]
* [https://sourceforge.net/u/edauvergne/fgdata/ci/python/r4/~/tree/ u-edauvergne-fgdata python/r4 branch]
As before, these are based on the CppUnit test suite branches:
* [https://sourceforge.net/u/edauvergne/flightgear/ci/cppunit/r6/~/tree/ u-edauvergne-flightgear cppunit/r6 branch]
* [https://sourceforge.net/u/edauvergne/simgear/ci/cppunit/r5/~/tree/ u-edauvergne-simgear cppunit/r5 branch]<ref>{{cite web
  |url    =  {{forum url|p=296873}}
  |title  =  <nowiki> Re: FGPython an propose for Python as an nasal alternative </nowiki>
  |author =  <nowiki> bugman </nowiki>
  |date  =  Oct 17th, 2016
  |added  =  Oct 17th, 2016
  |script_version = 0.40
  }}</ref>
{{FGCquote
|1= I'm also battling with VS 2015 (msvc14) on a VirtualBox VM with Windows 7.  I need to have this system up and running, because Windows support for FGPythonSys is essential.
|2= {{cite web
  | url    = {{forum url|p=283183}}
  | title  = <nowiki>Re: FGPython an propose for </nowiki>
  | author = <nowiki>bugman</nowiki>
  | date  = Apr 22nd, 2016
  | added  = Apr 22nd, 2016
  | script_version = 0.25
  }}
}}
{{FGCquote
|1= Just a quick update, now that I have a test suite up and running (I'll post full details on the devel mailing list), I'm now working on a 'fg_sys' Python module to supply 'sys' module equivalent functions.  The initial aim of this basic infrastructure is to replace sys.stdout and sys.stderr so that this works through the SG_LOG() system, allowing all printouts and feedback to go through the normal FlightGear/SimGear IO channels.
|2= {{cite web
  | url    = {{forum url|p=275754}}
  | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
  | author = <nowiki>bugman</nowiki>
  | date  = Feb 11th, 2016
  | added  = Feb 11th, 2016
  | script_version = 0.23
  }}
}}
https://sourceforge.net/u/edauvergne/flightgear/ci/521679677be33afa61860abbc1cdb17a50468267/log/?path=


== Motivation ==
== Motivation ==
Line 300: Line 479:


=== Nasal Issues ===
=== Nasal Issues ===
{{FGCquote
|1= the problem is that Nasal, despite being a high-level scripting language, may still be too low-level for most people - i.e. because resources like timers and listeners will typically need to be managed explicitly. Likewise, support for reset/re-init needs to be manually implemented.
And even complete "subsystems" are implemented on top of concepts like timers and listeners instead of having a more rigid framework-structure that encourages and requires a more conventional design.
We do have some fairly "large" systems implemented entirely in scripting space, that still only use a subset of the language's features - often in a copy&amp;paste fashion. And this is causing problems in other places. So I am not sure if we really need a proper OOP framework or even a DSL, but some way to encourage and enforce "best practices" in order not to break other simulator features would be pretty crucial sooner or later.
Things that would need to be covered would probably include:
*  logging/debugging (printlog/die)
*  providing a subsystem interface (SGSubsystem)
*  supporting reset/re-init
*  saving/loading/resuming flights
*  resource management (timers, listeners - and possibly threads)
*  split-frame loop management
*  support suspending/reloading code from disk (RAD)
*  formalie multi-instance synchronization, no matter if it's between multiple MP instances or a multi-instance multi-screen setup: we need a way to sync/replicate certain state across Nasal-based subsystems to provide a consistent experience
Currently, many of these things need to be separately implemented by people, and are typically not at all supported by scripting space subsystems. But currently we're seeing an increasing number of subsystems implemented in scripting space, and even most C++ code isn't prepared to handle these requirements properly. But the manpower is currently not in core development, but in base package/middleware development.
|2= {{cite web
  | url    = {{forum url|p=208878}}
  | title  = <nowiki>Re: </nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date  = May 10th, 2014
  | added  = May 10th, 2014
  | script_version = 0.23
  }}
}}
{{FGCquote
{{FGCquote
|1= timers are not all that bad given the design constraints of the FlightGear main loop - there are plenty other issues even apart from timers - and you really only need to look at comments from those core developers more familiar with Nasal internals to get a pretty complete picture - for instance, refer to the core developer comments quoted at: [[Initializing Nasal early]]
|1= timers are not all that bad given the design constraints of the FlightGear main loop - there are plenty other issues even apart from timers - and you really only need to look at comments from those core developers more familiar with Nasal internals to get a pretty complete picture - for instance, refer to the core developer comments quoted at: [[Initializing Nasal early]]
Line 322: Line 531:


|2= {{cite web
|2= {{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=274262#p274262
   | url    = {{forum url|p=274262}}
   | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
   | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
   | author = <nowiki>Hooray</nowiki>
   | author = <nowiki>Hooray</nowiki>
   | date  = Jan 28th, 2016
   | date  = Jan 28th, 2016
   | added  = Jan 28th, 2016
   | added  = Jan 28th, 2016
  | script_version = 0.23
  }}
}}
{{FGCquote
|1= There is a lot of Nasal/Nasal GC bashing going on, but in most cases we've seen so far, it's really improper use of lower-level APIs like timers and listeners that are not properly managed by aircraft developers - which is unlikely to show up on powerful systems, unless you keep FG running for a long time - because the only thing that is really happening is that callbacks (=code) is triggered more often than necessary.
Imagine it like configuring your mobile phone to check your eMail inbox once per hour - in FlightGear, there is no notion of a "scheduler" to do  this correctly, instead "timers" and "listeners" are used to associate callbacks (=code routines) with certain events, such as a timer expiring (e.g. after a few seconds) or a certain property changing (or any combination of these, i.e. by triggering listeners to be registered when a timer expires and vice versa).
What is happening behind the scenes is a bit obscure, but that has nothing to do with Nasal or its garbage collection (GC) scheme, it has more to do with the low-level nature of the functions provided by core developers to "manage" such callbacks, i.e. the settimer() and setlistener() APIs are particularly tedious to manage properly - but the de facto practice is to use those as the main building blocks to write/integrate full subsystems into the FlightGear main loop - tiny coding errors may not have much of an effect, but under certain circumstances, those coding errors will add up (i.e. over time), so that the original "task" of checking your inbox once per hour, ends up being executed hundreds of times per second - the underlying code would still be correct though, it's just the event handling code that is not written correctly, which is often the case when using reset/re-init or when changing locations - because the simulator hasn't been designed, developed and maintained with these requirements in mind.
Furthermore, there's not introspection facility provided that would allow people to look behind the scenes of the simulator to understand just how often a certain timer/listener is registered and triggered, so that the whole thing is extremely obscure  - but like I said, this is not a problem inherent to Nasal coding, it also happens/happened at the C++ level - e.g. look at Torsten's fix for the effects code, which was also leaking/re-running listeners like cray (unnecessarily) - thus, it's redundant work that is getting re-scheduled to over and over again due to buggy code - the problem is not necessarily the buggy code though (writing broken code is part of the whole process), the real problem is that we don't provide any functionality that would allow people to look at where their resources (CPU, RAM, VRAM, GPU) are utilized, so that uninformed conclusions are drawn by some people (like "Nasal is bad ... and needs to be replaced with .... ").
Thus, what you can do is to overload the corresponding APIs (extension functions) and treat the id() of the callback as the key for a hash lookup to gather data on how many timers/listeners are registered, and sample those over time.
You will almost certainly end up seeing dozens of unnecessary callbacks being invoked by certain code - even though that may not necessarily be restricted to Nasal code, like I said.
|2= {{cite web
  | url    = {{forum url|p=274633}}
  | title  = <nowiki>Re: 777 freezes and FPS loss</nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date  = Jan 31st, 2016
  | added  = Jan 31st, 2016
   | script_version = 0.23
   | script_version = 0.23
   }}
   }}
Line 653: Line 880:


== High Level Architecture (HLA) ==
== High Level Architecture (HLA) ==
{{Main article|High-Level Architecture}}
{{FGCquote
{{FGCquote
|1= HLA is important here but not at the property level.
|1= HLA is important here but not at the property level.
Line 731: Line 959:
|1= I hope we get Mathias' HLA interface productive soon, so we can add a detailed weather simulation outside the main loop...
|1= I hope we get Mathias' HLA interface productive soon, so we can add a detailed weather simulation outside the main loop...
|2= {{cite web
|2= {{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=144989#p144989
   | url    = {{forum url|p=144989}}
   | title  = <nowiki>Re: NOAA GFS </nowiki>
   | title  = <nowiki>Re: NOAA GFS </nowiki>
   | author = <nowiki>Torsten</nowiki>
   | author = <nowiki>Torsten</nowiki>
Line 756: Line 984:
|1= I'm hopeful that the work I'm doing on HLA will allow us to run Nasal in a separate thread from the FDM and display, so Nasal GC no-longer can impact frame-rates.  It would also allow for writing a weather simulation completely external to the FlightGear instance, which could be quite neat.
|1= I'm hopeful that the work I'm doing on HLA will allow us to run Nasal in a separate thread from the FDM and display, so Nasal GC no-longer can impact frame-rates.  It would also allow for writing a weather simulation completely external to the FlightGear instance, which could be quite neat.
|2= {{cite web
|2= {{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=265721#p265721
   | url    = {{forum url|p=265721}}
   | title  = <nowiki>Re: the real cost of the Nasal Garbage Collector</nowiki>
   | title  = <nowiki>Re: the real cost of the Nasal Garbage Collector</nowiki>
   | author = <nowiki>stuart</nowiki>
   | author = <nowiki>stuart</nowiki>
Line 768: Line 996:
|1= HLA being that different tasks are run by separate programs which all talk to a central controller unit... that will make the GUI interface (not the menu as some are want to call it) rendering one separate module while all the other stuff like AI craft and weather and such are in other modules which all talk to a central module... think of it like a central server with various clients getting and giving information while the GUI interface simply renders what it is told is available to render...
|1= HLA being that different tasks are run by separate programs which all talk to a central controller unit... that will make the GUI interface (not the menu as some are want to call it) rendering one separate module while all the other stuff like AI craft and weather and such are in other modules which all talk to a central module... think of it like a central server with various clients getting and giving information while the GUI interface simply renders what it is told is available to render...
|2= {{cite web
|2= {{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=271072#p271072
   | url    = {{forum url|p=271072}}
   | title  = <nowiki>Re: 3.7 no smoke</nowiki>
   | title  = <nowiki>Re: 3.7 no smoke</nowiki>
   | author = <nowiki>wkitty42</nowiki>
   | author = <nowiki>wkitty42</nowiki>
Line 782: Line 1,010:
Or parsing Global Forecast System data for more realistic weather simulator using pygrib. ([https://github.com/jswhit/pygrib https://github.com/jswhit/pygrib])
Or parsing Global Forecast System data for more realistic weather simulator using pygrib. ([https://github.com/jswhit/pygrib https://github.com/jswhit/pygrib])
|2= {{cite web
|2= {{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=270375#p270375
   | url    = {{forum url|p=270375}}
   | title  = <nowiki>Re: FGPython an propose for </nowiki>
   | title  = <nowiki>Re: FGPython an propose for </nowiki>
   | author = <nowiki>www2</nowiki>
   | author = <nowiki>www2</nowiki>
Line 790: Line 1,018:
   }}
   }}
}}
}}
== References ==
{{Appendix}}


[[Category:Core development projects]]
[[Category:Core development projects]]
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/92083...118867"