Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Changes

Jump to: navigation, search

Howto:Exposing Subsystems to Nasal

1,267 bytes added, 21:26, 8 February 2016
Background
Unfortunately, these two mechanisms are also rather low-level and tedious/error-prone to use correctly, so that code (Nasal callbacks) may be triggered accidently, and unnecessarily, which ultimately eats up considerable resources while creating a frame, sooner or later causing frame stuttering.
 
This would typically be the case when a function is invoked "too often", i.e. more often than necessary, without the programmer being aware of it - e.g. consider callbacks that are registered to be invoked multiple times:
 
<syntaxhighlight lang="nasal">
var foo = func() {
settimer(foo, 0);
settimer(foo, 0);
}
foo();
</syntaxhighlight>
 
While the example shown above is trivial, and straightforward to fix, the underlynig problem is a very common one in scripted FlightGear code.
 
Equally, listeners are a constant source of trouble, because people tend to register callbacks too often (i.e. spread across multiple functions/files):
<syntaxhighlight lang="nasal">
 
var foo = func() {
}
setlistener("/sim/signals/fdm-initialized", foo);
setlistener("/sim/signals/fdm-initialized", foo);
setlistener("/sim/signals/fdm-initialized", foo);
</syntaxhighlight>
 
What this will do, is execute the function 3 times whenever the property is modified.
 
What needs to be kept in mind here that these are very much contrived examples, and that the code in question is often much more complex, and that such bugs may depend on certain features being in use - e.g. when using reset/re-init, many modules won't behave properly, so that redundant listeners may be registered.
 
Even more unfortunate is the fact that FlightGear does not currently provide any mechanisms/APIs to look behind the scenes, i.e. to see how often a callback is actually executed, and where the callback is registered to be executed.
18,232
edits

Navigation menu