20,741
edits
m (→Status 06/2013) |
|||
Line 49: | Line 49: | ||
To run it, open a shell (START/EXECUTE cmd/command) and go to the folder of the binary, add a simple Nasal script and run "nasal-bin script.nas" | To run it, open a shell (START/EXECUTE cmd/command) and go to the folder of the binary, add a simple Nasal script and run "nasal-bin script.nas" | ||
=== Roadmap === | |||
* get the stand-alone interpreter compiling and running against both windows and Linux (currently there are a bunch of libraries used that aren't available on Windows) {{done}} | |||
* build a set of Nasal scripts that provide stubs for native fg calls (getprop/setprop/etc) {{Not done}} | |||
* build out testing script with the ability to verify values and report failures to the console {{Not done}} | |||
It should be doable to teach the nasal-bin.exe to check $FG_ROOT, and use that if available to load a semi-plausible FG environment (API-wise) - using some fancy metaprogramming tricks, most of the default APIs could probably be wrapped, without too much manual work involved. Philosopher could be truly instrumental here, because he really has a deep understanding of some of the more esoteric tricks that can be done in Nasal space, referring to advanced uses of compile(), bind(), call(), closure() and caller() - which make metaprogramming a fantastic experience. Basically, familiarity with this handful of APIs, can save tons of time: http://plausible.org/nasal/ | |||
There's quite a lot of stuff possible in Nasal, that nobody ever used in FG - Philosopher has started writing a bunch of tutorials, for example see: http://wiki.flightgear.org/Nasal_Meta-Programming | |||
And you can take a look at some of the scripts in the standalone branch, which support fancy constructs like dependency resolution using import("foo"); but also completely sandboxed/wrapped environments: https://gitorious.org/~hooray/fg/hoorays-simgear/trees/topics/nasal-standalone/simgear/nasal/tests | |||
These are regression tests developed by the Nasal developer himself, so not true unit testing - but only regression tests for the interpreter itself. | |||
=== Contributing === | |||
If possible, new code should be contributed through gitorious, ideally even a branch of FG_ROOT, because that will make it easier to direclty integrate such a unit testing system with all the code we got in $FG_ROOT/Nasal. | |||
== Problem == | == Problem == |