20,741
edits
FGPythonSys: Difference between revisions
Jump to navigation
Jump to search
→Motivation
m (→Getting involved: http://forum.flightgear.org/viewtopic.php?f=6&t=28378&p=274342#p274342) |
|||
| Line 295: | Line 295: | ||
| date = Jan 26th, 2016 | | date = Jan 26th, 2016 | ||
| added = Jan 26th, 2016 | | added = Jan 26th, 2016 | ||
| script_version = 0.23 | |||
}} | |||
}} | |||
=== Nasal Issues === | |||
{{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]] | |||
In summary, the main challenges Nasal is facing in FlightGear (and where it is causing problems in FG) are these: | |||
* executed in the main loop, so that GC overhead affects frame rate | |||
* it is added/initialized way too late, so that it is not available for certain purposes (think scripted initialization, benchmarking etc) | |||
* it cannot be tested in isolation, and also cannot be easily disabled completely | |||
* there is the hard-coded assumption that the interpreter sees a "full" fgfs session, including bindings for all subsystems, which is incompatible with the ongoing reset/re-init work, but also with the add-subsystem/remove-subsystem fgcommands | |||
* at run-time, it is next to impossible to clearly separate scripts based on their scope/purpose, i.e. aircraft scripts should not affect scenery/core scripts and vice versa - imagine selectively disabling certain scripts and restarting them (think firefox task manager showing JavaScript callbacks) | |||
* there is the hard-coded assumption that there will only ever be a single Nasal interpreter active at all times | |||
* equally, it is not easily possible to look behind the scenes to tell which scripts are "heavy" in terms of CPU/RAM utilization or "GC pressure" - we also cannot easily disable scripts entirely (programmatically) | |||
* there is no proper dependency resolution - neither in scripting space, nor in C/C++ space (Nasal bindings that depend on C++ subsystems being around) | |||
* no concept of "run-levels" (think headless, core, scenery, fdm, aircraft etc), so that the globals namespace is a huge mess | |||
* so far, timers and listeners are the only "building blocks" (hacks) to integrate scripted code with the main loop, which inevitably violate the encapsulation that SGSubsystem/SGSubsystemMgr could provide - equally, many virtual methods are not even implemented for important simulator events (pause, resume, save/load etc) | |||
* lack of generic building blocks (think abstract base classes/interfaces) to help enable/ensure that contributions are sufficiently general in nature, i.e. are not specific to a single aircraft/instrument, GUI dialog or use-case, and which support multiple independent instances "by design". | |||
* poor formalization of crucial simulator events at the SGSubsystem level (booting, pausing, resuming, saving/loading), which applies even moreso to Nasal code | |||
* no tracking of VM overhead in terms of Nasal footprint for different code, so that most people unfamiliar with SG/FG internals are basically unable to troubleshoot issues that might be related to Nasal | |||
* existing C++ code in SG/FG that is not properly exposed to scripting space, so that people re-implement FDM/AP logic in scripting space (for example) | |||
* where existing C++ code can be dynamically toggled on/off or customized, it can only deal with a single instance of the class and not allocate new objects on demand (think having more than a single FDM/AP object "live" at the same time) - that is a restriction due to the way the subsystemFactory works | |||
* Nasal's threading support is extremely rudimentary, i.e. lacking concurrency primitives that make "tasking" more straightforward for less experienced contributors (think design patterns), so that race conditions would inevitably occur sooner or later, even without looking at the FG side of things. | |||
|2= {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=274262#p274262 | |||
| title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Jan 28th, 2016 | |||
| added = Jan 28th, 2016 | |||
| script_version = 0.23 | | script_version = 0.23 | ||
}} | }} | ||