Improving Nasal: Difference between revisions

Jump to navigation Jump to search

Improving Nasal (view source)

Revision as of 17:36, 26 July 2013

2,965 bytes removed ,  26 July 2013
m
→‎Cleaning up FGNasalSys::init(): moved to Nasal Maintenance
Line 14: Line 14:
= Explicit loading order and reset support =
= Explicit loading order and reset support =
See [http://flightgear.org/forums/viewtopic.php?f=30&t=19487].
See [http://flightgear.org/forums/viewtopic.php?f=30&t=19487].
= Cleaning up FGNasalSys::init() =
If you're looking for a structured environment here, what about a cppbind port of SGSubsystem for Nasal? I.e. with .init, .postinit, .reinit, .update, etc.? That would be structured  It might also help with Nasal loading as an alternative to require() --
We once discussed the idea a long time ago, and it would actually be great if all Nasal code were using such an established and structured interface. It would be much easier to support simulator resets/re-initialization that way, if all scripts (core sim, GUI, aircraft) would follow a standard interface.
But first of all, one would need to provide such a wrapper, and then document it extensively and illustrate its benefits - i.e. in some of the default aircraft (c172p), so that developers are motivated to actually do all the porting work.
Overall, it would definitely align well with the reset/reinit work done by ThorstenB & James, because they're trying to solve the problem in a brute-force fashion by simply shutting down everything and starting over. Personally, I have come to the conclusion that NasalSys::init() is a huge troublemaker actually - it would be so much more simpler/elegant if that stuff was done in Nasal.
NasalSys::init() should really only handle the necessary C++/internal side (i.e. cppbind stuff) and just load a single script with will in turn load the others through Andy's original import() magic. It might also help by keeping everything under a single naContext, but I dunno if that is good or bad (I would suspect good).
And I am actually thinking of having more than just $FG_ROOT/Nasal - i.e. different folders for different modules, not just sub modules - but hierarchies that handle dependencies. For example, props.nas would be one of the first modules to be loaded, while gui.nas would only be available in a "GUI" run-level, i.e. after the sim is up and running. The current init code is incredibly messy.
In the FGRadar/Nasal code, Icecode_GL actually introduced another folder for unit testing purposes, that would be loaded/executed prior to anything else, where you would then simply add unit tests - which would all need to succeed first.
These things would be all good to have, but they don't need to be implemented in C++ space. That doesn't mean that mapping SGSubsystem to Nasal space would not be useful - I actually like the idea a lot, because we definitely have a bunch of REAL subsystems implemented in Nasal, such as bombable or advanced weather - these would ideally use a real SGSubsystem interface, possibly even SGSubsystemGroups (basically vectors of related subsystems) to ensure that the design supports reset/reinit and other important stuff without shutting down the whole beast.
The current way of developing Nasal code and just drupping it into $FG_ROOT/Nasal or $FG_AIRCRAFT simply isn't overly scalable, while also being really fragile and difficult to provide opportunities for code reuse.


= Improve the garbage collector =
= Improve the garbage collector =
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/61827"

Navigation menu