Re: [Flightgear-devel] nasal variables
Andy Ross wrote:
Hi Andy,
Ah, that did look like a lot of extra code to handle node-based variables.
That said, you really don't want to be designing your scripts around
raw, low-level performance issues. Write your code to be readable,
not blazingly fast. In general altitude is more readable than
altNode.getValue().
Of course, but I will optimize for performance wherever possible!
Not much readability difference between altitude and
altitude.getValue(), I'll pick the faster one.
ok, new question:
I see that after a File.RESET, the global variables (at nodes) get
reinitialized to the values they are set to in the nasal file, but the nasal
(pseudo-global-to-the-one-file) variables do not.
I would like to know how to reset the nasal variables.
I have rounded them up in a function called start_up
and tried adding start_up to the nasal section in the main-set.xml, but it
also is only run once.
Is is there an easier way to check for when to call it without putting it in
one of the main loops?
if (reinit_vars.getValue()) {
start_up();
}
Also, I find placing this at the top level in the nasal file isn't good enough.
How is it that the global.node variables get reset, but my if statement does
not get evaluated more than once? It seems any functions running after the
Reset, must be already running with settimer hooks.
Thanks,
Stewart
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal variables
Ah! I knew there was a simple answer, I need only to ask.
Thanks
Harald JOHNSEN wrote:
Check
http://wiki.flightgear.org/flightgear_wiki/index.php?title=Nasal_scripting_language.
You'll want to have a listener on the reset signal
setlistener(/sim/signals/reinit, func {
start_up();
});
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal variables
Stewart Andreason wrote: If accessing temp1 _is_ faster than .getValue, then at 2 or 3 accesses, I imagine it becomes faster to do the above? Yes, it's definitely faster, because there's less work to do. Evaluating the expression temp1 requires pushing the symbol value (a string) onto the stack, and executing OP_LOCAL which does a hash table lookup to find the value in the namespace list and leave it on the stack for the next bit of code to use. Evaluating node.getValue() requires: Pushing the symbol node onto the stack Executing OP_LOCAL to look it up Pushing the symbol getValue onto the stack Executing OP_MEMBER to look it up in the object Executing OP_CALL to call it as a function Finally (!) calling the C++ property node function Turn the output node into a Nasal object and leave it on the stack. That said, you really don't want to be designing your scripts around raw, low-level performance issues. Write your code to be readable, not blazingly fast. In general altitude is more readable than altNode.getValue(). Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal variables
Andy Ross wrote:
Stewart Andreason wrote:
Is there a preference for how variables are declared and used in nasal?
between the global type:
var some_name = 0;
which can be accessed and changed from any function,
That's a Nasal variable. It's not global in the sense that all
users will see the same value for name. It's part of the namespace
of the executing function (which might be the whole file), and is
visible only to the current function, and other func expressions
assigned during that execution.
Thanks for the clarification Andy, I meant global to the nasal file, and
available only to the functions defined within.
and using the nodes
var name =
props.globals.getNode(/sim/model/aircraftName/someDirectory/name,1);
and accessing with .getValue and .setValue.
That's *also* a Nasal variable, but it holds a reference to a property
node instead of an actual value. Interestingly, the property node,
unlike the variable above, *is* a global thing (i.e. every part of
FlightGear sees the same node for /sim/model/.../name).
The advantage to Nasal-space data is that it's fast and simple. If
the only thing that will care about the value is your script, they are
good choices.
Right.
When writing my nasal scripts, I imitated other available examples in
programming style. I'm just questioning if it is necessary, or faster
mostly, to define a local variable in a function for multiple accesses.
func {
var temp1 = globalVar.getValue();
if (temp1 0.5) { # typical usage seen
var x1 = temp1 + (temp1 * 4); # for a more intense example
etc.
or if it is more for filesize, and easier to read.
It would seem, if temp1 only gets accessed once past declaration, then
it would not be efficient.
If accessing temp1 _is_ faster than .getValue, then at 2 or 3 accesses,
I imagine it becomes faster to do the above?
Thanks,
Stewart
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal variables
Stewart Andreason wrote: Is there a preference for how variables are declared and used in nasal? between the global type: var some_name = 0; which can be accessed and changed from any function, That's a Nasal variable. It's not global in the sense that all users will see the same value for name. It's part of the namespace of the executing function (which might be the whole file), and is visible only to the current function, and other func expressions assigned during that execution. and using the nodes var name = props.globals.getNode(/sim/model/aircraftName/someDirectory/name,1); and accessing with .getValue and .setValue. That's *also* a Nasal variable, but it holds a reference to a property node instead of an actual value. Interestingly, the property node, unlike the variable above, *is* a global thing (i.e. every part of FlightGear sees the same node for /sim/model/.../name). The advantage to Nasal-space data is that it's fast and simple. If the only thing that will care about the value is your script, they are good choices. The property tree is a inter-subsystem communication thing. This is what you want if you want to share data with the C++ world (for example, YASim control-output tags write to properties -- they don't understand Nasal), or read in via configuration files. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
