Initializing Nasal early: Difference between revisions

Switch to {{gitorious url}} to fix the broken Gitorious links.
mNo edit summary
(Switch to {{gitorious url}} to fix the broken Gitorious links.)
(20 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{Non-stable|version=4.x|progress=30}}
{{Non-stable|version=4.x|progress=60}}


[[File:Nasal and Canvas initialized early.png|thumb|'''Towards [[FGCanvas]]''': Screen shot showing the [[Nasal]] and [[Canvas]] subsystems initialized early, so that both subsystems can be used to implement GUI launchers or more dynamic splash screens etc.]]
[[File:Nasal and Canvas initialized early.png|thumb|'''Towards [[FGCanvas]]''': Screen shot showing the [[Nasal]] and [[Canvas]] subsystems initialized early, so that both subsystems can be used to implement GUI launchers or more dynamic splash screens etc.]]
Line 5: Line 5:
{{infobox subsystem
{{infobox subsystem
|image =
|image =
|name = Nasal Bootstrapping
|name = [[File:Nasallogo5.png]] Bootstrapping
|started= 07/2014  
|started= 07/2014  
|description = scripted startup, as per [http://forum.flightgear.org/viewtopic.php?f=30&t=21083] and [http://forum.flightgear.org/viewtopic.php?f=71&t=23499]
|description = scripted startup, as per [http://forum.flightgear.org/viewtopic.php?f=30&t=21083] and [http://forum.flightgear.org/viewtopic.php?f=71&t=23499]
|status = Under active development as of 07/2014
|merge-requests = {{Merge-request|flightgear|1586}} {{Pending}}
|status = Under active development as of 07/2014 [http://forum.flightgear.org/viewtopic.php?f=71&t=23499&p=214576#p214576]
|developers = Hooray, Philosopher (since 07/2014),
|developers = Hooray, Philosopher (since 07/2014),
|topic-fg= {{Git link|gitorious|fg/philosophers-flightgear|topics/fgcanvas-experiments}}
|topic-fg= {{gitorious url|fg|philosophers-flightgear|branch=topics/fgcanvas|view=shortlog}}
|topic-fgdata= {{Git link|gitorious|fg/canvas-hackers-fgdata|topics/fgcanvas}}  
|topic-fgdata= {{gitorious url|fg|canvas-hackers-fgdata|branch=topics/fgcanvas|view=shortlog}}
}}
}}


{{Portability Navbar}}
{{Nasal Internals}}
{{Nasal Internals}}
{{FGCquote|1= I am delighted to have this cleaned up, and a way to incrementally init bits of Nasal|2= {{cite web  | url    = http://forum.flightgear.org/viewtopic.php?p=192734#p192734  | title  = <nowiki>Re: Modular Nasal bootstrapping (again)</nowiki>  | author = <nowiki>zakalawe</nowiki>  | date  = Oct 27th, 2013  }}}}
{{FGCquote
  |I would prefer to init Nasal earlier in startup, because I would like use [[Aircraft Center|Canvas-based UI for pieces such as aircraft-selection]] - but right now we have to load Nasal in postInit, which is seconds and seconds into startup. Most Nasal things that need FDM state already wait on fdm-initialized, so in ''theory'' the only fix required is to skip &lt;nasal&gt; evaluation in 'animation' XML files (apparently there is a long-standing assumption that such elements are skipped when loading an aircraft as the main one, i.e they are only run for AI / MP aircraft - this is a bad situation but changing it now could be a serious compatibility problem)
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192734#p192734
    |title=<nowiki>Re: Modular Nasal </nowiki>
    |author=<nowiki>zakalawe</nowiki>
    |date=<nowiki>Sun Oct 27</nowiki>
  }}
}}
{{FGCquote
  |The old ‘reset’, which does *not* restart Nasal, is now stripped down to the bare minimum of systems needed for repositioning (tele-porting). Since many aircraft Nasal scripts rely on /sim/signals/reinit to do work on being teleported, that behaviour was also retained.
In an ideal world, there would be a better API to inform aircraft and Nasal modules about a teleport, but for the meantime, the property you mentioned is the one. Eg, really we should have an API to distinguish on-ground vs in-air starts, and adjust the initial state of properties accordingly.
BTW, for the new reset process, the subsystem, including Nasal, is actually destroyed and re-created. This is intentionally to make it almost certain the behaviour after a reset is the same as after the first launch of the sim.
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33135215/
    |title=<nowiki>Re: [Flightgear-devel] Expected behavior on "reinit"</nowiki>
    |author=<nowiki>James Turner</nowiki>
    |date=<nowiki>2014-12-10</nowiki>
  }}
}}
{{cquote|The primary goals are:
* make startup more predictable and less hard-coded.
* allow running flightgear in a server/test mode with only some subsystems, and no rendering
Obviously supporting a standalone 'fgcanvas' would be quite a small extension from those. I'm not worrying about dynamic dependencies or automatic subsystem creation for the moment - I expect the user / defaults to have defined a set of subsystems that work without crashing  You're correct of course that Nasal has many assumptions about subsystems, but I think that can be improved incrementally on the Nasal side.
For the test mode, I really want to start Nasal-the-langauge very early, without loading all the modules in Nasal/ immediately. (Or maybe load a 'safe' subset). That's going to take some thought and I didn't get that far yet!<ref>{{cite web |url=http://forum.flightgear.org |title=incremental initialization of SGSubsystems|author=James Turner |date=Oct 01, 2012}}</ref>|James Turner}}
{{FGCquote|1= This is exactly what I added support for implementing new commands in Nasal, so that going forward we can correctly put custom dynamic things in commands. |2= {{cite web  | url    = http://forum.flightgear.org/viewtopic.php?p=191781#p191781  | title  = <nowiki>Re: Modular Nasal bootstrapping (again)</nowiki>  | author = <nowiki>zakalawe</nowiki>  | date  = Oct 14th, 2013  }}}}
{{FGCquote
|1= on the complexity of dependencies for Nasal scripts, I think again the answer is to have the running status of each subsystem stored somewhere, and exposed via the property tree. The trick will be picking good groups, so most things have one or two dependencies, and having some documentation somewhere stating what's in each group.
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/13175741/
  | title  = <nowiki>Re: [Flightgear-devel] Subsystem run-levels</nowiki>
  | author = <nowiki>James Turner</nowiki>
  | date  = Apr 18th, 2006
  | added  = Apr 18th, 2006
  | script_version = 0.25
  }}
}}
{{FGCquote
|1= the run-level concept is just one property, and nicely encapsulates the hierarchy of subsystems (if you're switching to level 8, all lower levels must already be initialied). But having names and separate flags makes the actual dependency clearer: 'this script depends on the aircraft subsystems' or 'this script depends on the environmental subsystems'. I guess it partly depends how complex the dependencies for any given script are in practice - hopefully they're actually quite simple.
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/13175705/
  | title  = <nowiki>Re: [Flightgear-devel] Re: Subsystem run-levels</nowiki>
  | author = <nowiki>James Turner</nowiki>
  | date  = Apr 18th, 2006
  | added  = Apr 18th, 2006
  | script_version = 0.25
  }}
}}


This is a summary of all discussions relating to:
This is a summary of all discussions relating to:
* initializing the Nasal scripting interpreter earlier {{Progressbar|30}}
* initializing the Nasal scripting interpreter earlier {{Progressbar|70}}
* moving $FG_ROOT/Nasal initialization out of C++ into scripting space (aka "bootstrapping") while introducing proper dependency resolution (inter- and intra-modular) {{Progressbar|20}}
* moving $FG_ROOT/Nasal initialization out of C++ into scripting space (aka "bootstrapping") while introducing proper dependency resolution (inter- and intra-modular) {{Progressbar|20}}
* moving subsystem-specific initialization of Nasal APIs into each subsystem's bind methods, as per [http://forum.flightgear.org/viewtopic.php?f=71&p=214436#p214436] {{Progressbar|50}}  
* auditing $FG_ROOT for any other cases of embedded Nasal code that may have implicit assumptions regarding other subsystems (e.g. dialog files) {{Not done}}
* moving subsystem-specific initialization of Nasal APIs into each subsystem's bind methods, as per [http://forum.flightgear.org/viewtopic.php?f=71&p=214436#p214436] {{Progressbar|70}}  
* extending [[Nasal/CppBind|cppbind]] to keep track of added symbols, to easily remove them on demand {{Pending}}
* extending [[Nasal/CppBind|cppbind]] to keep track of added symbols, to easily remove them on demand {{Pending}}
* moving subsystem-specific argument processing and fgcommand initialization into each subsystem  {{Not done}}
* providing an integrated GUI front-end/launcher using [[Canvas]] and [[Nasal]]: [[Aircraft Center]]  
* providing an integrated GUI front-end/launcher using [[Canvas]] and [[Nasal]]: [[Aircraft Center]]  
* decoupling FlightGear initialization such that certain subsystems can be optionally disabled right at the beginning (e.g. FDM, sound, replay, scenery) {{Progressbar|10}}
* decoupling FlightGear initialization such that certain subsystems can be optionally disabled right at the beginning (e.g. FDM, sound, replay, scenery) {{Progressbar|10}}
* simplifying the fg_init.cxx/main.cxx initialization logic and exposing it to scripting space {{Pending}}
* simplifying the fg_init.cxx/main.cxx initialization logic (fgCreateSubsystems) and exposing it to scripting space {{Progressbar|60}}
* allowing argument processing to be delegated to scripting space (e.g. options, startup position handling, presets etc.)
* allowing argument processing to be delegated to scripting space (e.g. options, startup position handling, presets etc.) {{Not done}}
* grouping related subsystems into '''SGSubsystemGroup''' instances to manage them holistically {{Progressbar|20}}  - analogous to [[FlightGear Run Levels|run-levels]], e.g.:
* grouping related subsystems into '''SGSubsystemGroup''' instances to manage them holistically {{Progressbar|20}}  - analogous to [[FlightGear Run Levels|run-levels]], e.g.:
** AUDIO: sound, voice (TTS), fgcom  
** AUDIO: sound, voice (TTS), fgcom  
Line 30: Line 90:
** VIDEO: gui, canvas, canvasGUI
** VIDEO: gui, canvas, canvasGUI
* making the initialization process/splash screen more responsive by using Nasal/Canvas instead of hard-coded GL code [http://forum.flightgear.org/viewtopic.php?f=71&t=23542] [http://forum.flightgear.org/viewtopic.php?f=71&t=22021] ({{Issue|1456}}) {{Pending}}
* making the initialization process/splash screen more responsive by using Nasal/Canvas instead of hard-coded GL code [http://forum.flightgear.org/viewtopic.php?f=71&t=23542] [http://forum.flightgear.org/viewtopic.php?f=71&t=22021] ({{Issue|1456}}) {{Pending}}
* allowing custom startup profiles/modes to be implemented via Nasal helper scripts, for example: {{Not done}}
* allowing custom startup profiles/modes to be implemented via Nasal helper scripts (which also touches the area of '[[Howto:Create_a_custom_version_of_FlightGear|modding]]'), for example: {{Not done}}
** [[FGCanvas]]
** [[FGCanvas]]
** running stand-alone Canvas applications, e.g. the [[Interactive Nasal REPL]] or a [[MapStructure]] map
** running stand-alone Canvas applications, e.g. the [[Interactive Nasal REPL]] or a [[MapStructure]] map
** [[FlightGear Benchmark]]
** [[FlightGear Benchmark]]
** [[FlightGear Headless]]
** [[FlightGear Headless]]
** [[FGViewer]]
** supporting stand-alone [[Nasal]]/[[Canvas]]-baased applications like a MapStructure-based moving map or a virtual [[Stand Alone ATC Control Development|ATC client]]
** supporting stand-alone [[Nasal]]/[[Canvas]]-baased applications like a MapStructure-based moving map or a virtual [[Stand Alone ATC Control Development|ATC client]]
** supporting a safe subset of subsystems for [[Howto:Optimizing FlightGear for mobile devices|mobile devices]]  
** supporting a safe subset of subsystems for [[Howto:Optimizing FlightGear for mobile devices|mobile devices]]  
Line 50: Line 111:


I anyone wants to work on this, it would be a self-contained function in position-init code, just ask here for any questions. All the pieces certainly exist - the taxiways, parking locations and runways for the airport are all accessible.<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/attachment/F69E014E-F15A-4EAB-B512-36B87CA3B2C5%40mac.com/1/|title= Aircraft positioning on the runway|author=James Turner |date=2013-11-12 10:32:27}}</ref>|James Turner}}
I anyone wants to work on this, it would be a self-contained function in position-init code, just ask here for any questions. All the pieces certainly exist - the taxiways, parking locations and runways for the airport are all accessible.<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/attachment/F69E014E-F15A-4EAB-B512-36B87CA3B2C5%40mac.com/1/|title= Aircraft positioning on the runway|author=James Turner |date=2013-11-12 10:32:27}}</ref>|James Turner}}
{{FGCquote
  |I would prefer to init Nasal earlier in startup, because I would like use [[Aircraft Center|Canvas-based UI for pieces such as aircraft-selection]] - but right now we have to load Nasal in postInit, which is seconds and seconds into startup. Most Nasal things that need FDM state already wait on fdm-initialized, so in ''theory'' the only fix required is to skip &lt;nasal&gt; evaluation in 'animation' XML files (apparently there is a long-standing assumption that such elements are skipped when loading an aircraft as the main one, i.e they are only run for AI / MP aircraft - this is a bad situation but changing it now could be a serious compatibility problem)
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192734#p192734
    |title=<nowiki>Re: Modular Nasal </nowiki>
    |author=<nowiki>zakalawe</nowiki>
    |date=<nowiki>Sun Oct 27</nowiki>
  }}
}}


{{FGCquote
{{FGCquote