20,741
edits
FGPythonSys: Difference between revisions
Jump to navigation
Jump to search
→Nasal Issues
| Line 330: | Line 330: | ||
=== 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&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 = http://forum.flightgear.org/viewtopic.php?p=208878#p208878 | |||
| 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]] | ||