sanhozay wrote in Sun Sep 27, 2015 8:10 pm:Ideally this would be done in the C++ code that drives the route manager, or using property rules in the autopilot. It is possible to do it in Nasal, and I have a script that does so, but I was told, rightly so, that a general Nasal sclution would not be accepted into FGDATA because of garbage collection issues with Nasal running so intensively. Many aircraft do it this way, however.
I don't know who you were talking to - but the main issue is running FDM/AP-coupled Nasal code, because that may trigger the Nasal GC several times per frame possibly, while it can currently only be triggered once per frame (well, in theory).
In general, the idea is to use C++ delegates so that performance-critical stuff takes place in C++ space - and once you look at the code in question, you will see that this is pretty much what it is doing already. So it would be straightforward to map the control logic to Nasal space, so that Nasal would never be running the logic, but just control the undelying "mode" to be used - which could be implemented in AP/RM space, but also via property rules.
The real issue here is not so much that Nasal's GC scheme sucks big time, but that we have much better systems available in C++ space, which are simply not properly exposed to scripting space - so that aircraft developers tend to come up with all sorts of ugly workarounds, that reflect badly upon Nasal, its GC and fgfs as a whole.
If the people involved in the AP/property rule and RM subsystems spent less time complaining about the Nasal GC and its issues, and instead focused on exposing this to property tree space, the whole issue would be solved once and for all, because Nasal would only ever be used to configure/switch modes and control logic, but never run any performance critical code at frame rate, let alone, FDM rate.
For some context, I suggest to look at what others have previously stated in this particular context, especially core developers (Torsten:autopilot/property rules and James: route-manager/Nasal delegates), and those doing related work:
Subject: 2 Questions: vacuum & electrical
Torsten wrote:I think, performance of Nasal code and XML based property rules is pretty close. The big advantage of the property rules is that they don't produce garbage that a garbage collector has to clean up. But as nothing in life comes for free (except FlightGear, of course) XML tends to be much more verbose - as you correctly stated.
My personal guideline for using one or the other system is:
- Computing properties from a well defined set of other properties once per frame: use a property rule.
- If there is no other way to get it done: use Nasal.
Torsten wrote in Thu Feb 02, 2012 10:08 pm:especially if these configurations could be instantiated at run time
Great minds think alike. I have recently committed some code to allow runtime loading of <strike>autopilots</strike> property rules and have a Nasal binding for that in mind. This _might_ end up in something like
- Code: Select all
var myPid = pidController.new();
myPid.Td = 0.0001;
myPid.Ti = 123.4;
myPid.Kp = 0.2;
myPid.input = "/foo";
myPid.reference = "/bar";
myPid.output = "/baz";
etc, etc.
But that's probably a little off topic now.
http://flightgear.org/forums/viewtopic. ... 99#p128052
zakalawe wrote in Tue Jun 21, 2011 12:48 pm:scotth1 wrote in Tue Jun 21, 2011 10:35 am:One thing I would add is that the existing waypoints don't seem to contain enough information, I've written some more Nasal classes to handle SID/STAR/IAP, Top of Climb and Top of Descent pseudo waypoints and Altitude constraints versus FMS calculated altitudes etc.
Right, and that's the next question - I don't want to hard-code that kind of logic in C++, if I can avoid it - but we need to work out a way for Nasal to set the values into the route-manager or GPS data, so the ND can pick it up - especially all the cruise/phase-of-flight/altitude/energy stuff. I apologise for being lazy, but can you remind me where the relevant Nasal code is? Then we can have a discussion (possibly involving some other people) about which parts can be in C++, and some standard locations the ND can look for Nasal-computed value, and so on.
Subject: Route manager leg modes
Hooray wrote:Personally, I am not convinced that we should continue with a hard-coded route manager, implemented in C++, at all - especially given that quite a few aircraft have begun implementing their own scripted variants - in the mid term, I would hope that there's simply a RM infrastructure in place that can be augmented via Nasal delegates (e.g. via cppbind). The route manager currently being a singleton "by accident" is another unnecessary issue, that is preventing people from using it elsewhere (e.g. for AI traffic).
Subject: Route manager leg modes
Alant wrote:Nasal does have an advantage in that it is easier to tailor to specific requirements. So, providing that the CPU overhead is acceptable, this may be a preferable method for many aircraft.
A C++ coded module is fixed in stone, but nasal and xml modules are far easier to modify/overload on a per-aircraft basis.
As I am modelling a 1960´s military bomber I have quite a number of (very) aircraft specific requirements which are not met by the current RM/GPS code which is targeted at present day commercial usage.
Thus, the real problem is not Nasal or its GC, but it is existing C++ code that is simply not exposed to Nasal space, so that aircraft developers have to reinvent the wheel.
And in all fairness, the most recent memory leak (and segfault!) was route manager/routePath related, and it could have never happened in Nasal space - simply due to it using a GC.