20,741
edits
Nasal HLA standalone: Difference between revisions
Jump to navigation
Jump to search
m
→A standalone interpreter
m (→Problem) |
|||
| Line 13: | Line 13: | ||
== A standalone interpreter == | == A standalone interpreter == | ||
Providing a standalone Nasal binary that has its own property tree | Providing a standalone Nasal binary that has its own property tree instance would not be very difficult, it would be mostly copy/paste from SimGear/FlightGear ($SG_SRC/nasal and $FG_SRC/Scripting). | ||
You could definitely add the FG/SG property tree code to the standalone interpreter - it would not even be very difficult, if you know C++, it should only take a couple of hours to make it work, but that will just ensure that your scripts have their own property tree, it doesn't provide any of the other FG/Nasal APIs or subsystems, such as the autopilot etc. | You could definitely add the FG/SG property tree code to the standalone interpreter - it would not even be very difficult, if you know C++, it should only take a couple of hours to make it work, but that will just ensure that your scripts have their own property tree, it doesn't provide any of the other FG/Nasal APIs or subsystems, such as the autopilot etc. | ||
Philosopher is for example using a heavily customized standalone Nasal interpreter for development purposes that has many features which FG doesn't have (yet). But that doesn't make it any easier to develop scripts FOR FlightGear. Most scripts in FlightGear use a plethora of APIs and FG-specific Nasal modules ($FG_ROOT/Nasal), so FG has become a runtime dependency (APIs, data structures like the property tree, and "live" state), | |||
Thus, a standalone Nasal interpreter in and of itself would not be particularly useful for developing/testing Nasal code for use in FlightGear, that would require some way of IPC - so that the interpreter can run in its own thread/process and still hook into the fgfs process. | Now, testing scripts is so time-consuming because of various issues: 1) Nasal being a dynamically typed language, where errors often only show up at runtime, 2) the lexer/parser is not particularly robust - so that error messages are not very informative, and may only show up fairly late. Philosopher has been working on improving things a little. 3) The main issue is FlightGear's way of loading Nasal scripts just once during startup, i.e. there's no design/mechanism in place to do Nasal housekeeping, so that the interpreter cannot be re-initialized at runtime, which is why most scripts are not safe to reload currently. | ||
To reload Nasal scripts, the whole process must be terminated and restarted currently. You can only reload scripts manually if you explicitly design them to support this use-case, which includes releasing resources like running callbacks (loops, listeners, timers) or files and threads. Even if the FG design were to be fixed, I'd expect that most scripts would need to be changed. | |||
Thus, a standalone Nasal interpreter in and of itself would not be particularly useful for developing/testing Nasal code for use in FlightGear, that would require some way of IPC (think CORBA or HLA)- so that the interpreter can run in its own thread/process and still hook into the fgfs process to access other subsystems, like the property tree. | |||
== Hight Level Architecture == | == Hight Level Architecture == | ||