Board index FlightGear Development Nasal

Modular Nasal bootstrapping (again)

Nasal is the scripting language of FlightGear.

Re: Modular Nasal bootstrapping (again)

Postby Philosopher » Sun Oct 27, 2013 7:55 pm

I haven't touched anything other than the method of loading yet...
Philosopher wrote:[...] I would prefer to leave [the] changes [for early Nasal init] to you - you're experienced with the whole FlightGear code base, and unless I gain lots of knowledge, I wouldn't know how to change things.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Modular Nasal bootstrapping (again)

Postby Philosopher » Mon Oct 28, 2013 7:54 pm

P.S. Be warned that I `push -f` a lot to my extra branches! Like now!
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Modular Nasal bootstrapping (again)

Postby zakalawe » Mon Oct 28, 2013 9:44 pm

Okay, if you're rebasing / push -f branches then I will take a look with caution :)
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Modular Nasal bootstrapping (again)

Postby Philosopher » Sun Nov 03, 2013 2:12 am

I'm trying to recompile after flightgear/01de68e ("Use FG_NASAL_BOOTSTRAP flag"), and I use this flag to CMake (in addition to my usual):
Code: Select all
 -DFG_NASAL_BOOTSTRAP=ON

And I get this:
Code: Select all
CMake Warning:
  Manually-specified variables were not used by the project:

    FG_NASAL_BOOTSTRAP

Bootstrapping doesn't work then :(. What is the proper usage? (Mainly academic interest: I will change it to detect if nasal_bootstrap.nas exists tomorrow...)
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Modular Nasal bootstrapping (again)

Postby zakalawe » Sun Nov 03, 2013 6:31 am

Did you define the variable in CMakeLists.txt, and add a suitable placeholder to src/Include/config-cmake.in?
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Modular Nasal bootstrapping (again)

Postby Hooray » Sun Nov 03, 2013 1:32 pm

lol, just saw your commit - the required CMake changes are trivial, just look at any other build option - but your recent changes should work, too - and demonstrate that you are feeling quite at home in C++ space (rather than in CMake magic...)

Just make sure to add some surrounding comments explaining what you're doing (or, we'll see people adding code to your exception handler, which is basically "disabled")- and maybe a property switch to make enable/disable the change via fgGetBool()
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11321
Joined: Tue Mar 25, 2008 8:40 am

Re: Modular Nasal bootstrapping (again)

Postby Philosopher » Mon Nov 04, 2013 1:42 am

I really don't believe there should be an option to disable bootstrapping, it should just be an issue of matching FGData. Basically, if we have new-style scripts (i.e. using require() and deprecating "nasal-dir-initialized"), then we need a bootstrap script (because otherwise... we would have to reimplement the corresponding code in C++ space); else, we have old FGData (as I sometimes like to switch back to, to pursue other projects like the Nasal Browser) and we use the old C++ loading code.

I'm also thinking of removing the check once the changes become mainline – there's no sense in keeping the old policy around, I think. (See how many mismatched FG/FGData complaints we get, "what is this nasal_bootstrap.nas thinkgy?" ;-).)
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Modular Nasal bootstrapping (again)

Postby Hooray » Mon Nov 04, 2013 10:15 am

this is certainly true, especially given any FGData/Nasal changes resulting from this - but for testing purposes it may still be useful (and trivial). Afterwards, I agree that there's probably very little need.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11321
Joined: Tue Mar 25, 2008 8:40 am

Re: Modular Nasal bootstrapping (again)

Postby Hooray » Tue Nov 05, 2013 7:44 pm

Been lurking a bit and looking at your recent commits, here are some semi-random thoughts:

  • we generally suggest that *.nas files are to be put under $FG_ROOT/Nasal
  • however, in the case of the bootstrapping script, we clearly don't want it to be there :D
  • on the other hand, some people may still put it there accidentally
  • thus, I think it wouldn't be such a bad idea to use a non-default extension in this case, to prevent confusion and accidents
  • analogous to how Unix/Linux scripts often also don't have a *.sh suffix anymore
  • something like nasal.bootstrap should work in my opinion, and would make its purpose obvious, while reducing the risk for breakage
  • also, given the number of modding-related questions, I would even consider using fgGetStringValue("/nasal/bootstrap-script", "nasal.bootstrap");
  • that would allow people to easily override the script - I am thinking in terms of supporting experimental stuff here, without expecting people to mess with the main/official script
  • in general, I find it cleaner to support custom file names, instead of asking people to edit critical files like these (or preferences.xml)

Also, have you thought about preparing the bootstrapping script to optionally support some of your Nasal profiling/debugging extensions ? I realize that the profiling stuff in particular is still pretty experimental, but most of the debugging helpers seemed stable enough to be really useful to fgdata contributors, assuming that this would be stricly opt-in and only ever be enabled by "power users" (aka contributors) ?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11321
Joined: Tue Mar 25, 2008 8:40 am

Re: Modular Nasal bootstrapping (again)

Postby Philosopher » Sun Nov 17, 2013 10:54 pm

Currently pushing too many objects to Gitorious... :P

I'm working on your filename idea, seems like a good idea. For the prof-/debugging, that really wasn't in an acceptable state; it basically stopped FG from running faster than a frame a second. I have another idea for how to optimize it (got it through a talk with someone who knows more than I), but I have yet to test it out, and I'm even unsure it will make a noticeable difference. (It basically involves compiling strings into a buf and writing that out to a file, instead of concatenation and continuously storing that in memory.) I don't think SQLite is something I could implement, and I don't know if it would improve speed any.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Modular Nasal bootstrapping (again)

Postby Hooray » Mon Nov 18, 2013 2:49 pm

Philosopher wrote in Sun Nov 17, 2013 10:54 pm:instead of concatenation and continuously storing that in memory.) I don't think SQLite is something I could implement, and I don't know if it would improve speed any.


does NOT using ANY concatenation speed-up things significantly here ? In other words, it is worthwhile to investigate replacing this with something else ? Not sure if we need to use SQLite, but it should be straightforward if necessary because the bindings are there already - just not available in FG at the moment, however FG already uses SQLite for the navcache - so adding the scripting bindings would not even be an issue, because they are already linked it.

If the framerate is still severely affected, even when using empty processing callbacks, the bottleneck is somewhere else obviously. In FlightGear, you can use the profiler-start fgcommand to see what's going on.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11321
Joined: Tue Mar 25, 2008 8:40 am

Re: Modular Nasal bootstrapping (again)

Postby Hooray » Wed Jul 09, 2014 6:03 pm

Updating the wiki: http://wiki.flightgear.org/Initializing_Nasal_early

Referring to:
FGCanvas Experiments & Updates
Philosopher wrote:I'll revisit bootstrapping soon, because it's the only sane way to resolve dependencies (intra-module or even subsystem support).


Given my recent "FGCanvas" experiments (making ~60% of the subsystems optional), and successes there, I'd probably consider handing off control to a hard-coded Nasal script in FGNasalSys, even though we could make the file-name property-configurable, whereas it would default to something like "default.boot".

That would allow us to easily use --prop= (or a dedicated --mode=) parameter to override the bootstrapping script.
Once that is place, we could also move certain fg_init.cxx logic to Nasal space by using Zakalawe's add-subsystem/remove-subsystem fgcommands, which I already started extending to allow subsystems to be registered as SGSubsystemGroup instead of "just" SGSubsystem - which allows us to use groups as "containers" for specific subsystems, like "aircraft" (fdm, autopilot, route manager etc) or "audio" (fgcom, sound, voice). Making these entirely optional and runtime-configurable is becoming much more straightforward that way - also, because all the reset/re-init logic can be moved to each groups postinit/reinit methods.

Conceptually, that's straightforward to do, and apart from supporting different startup modes, we could even support "applications", i.e. stuff like running just the REPL, or just a canvas-map, or even just the Aircraft Center eventually.

So, I'd prefer to load a single property-defined Nasal script and delegate control to it in FGNasalSys:init(), so that we can handle both there, nasal bootstrapping, but also subsystems at some point.
At that point, initializing FGNasalSys should become more straightforward (still toying with it, but no major headaches so far)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11321
Joined: Tue Mar 25, 2008 8:40 am

Re: Modular Nasal bootstrapping (again)

Postby Philosopher » Wed Jul 09, 2014 6:23 pm

Yeah, that's basically the current state. I was trying to make it more configurable/flexible, which is where I got stuck (reimplementing the same behavior wasn't too hard).

Regarding initialization order of subsystems in Nasal: it is doable but maybe a little dangerous, because if it isn't done correctly it can crash FG. That's about the only comment I have, I'm not familiar with the init process....
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Modular Nasal bootstrapping (again)

Postby Hooray » Wed Jul 09, 2014 6:34 pm

Philosopher wrote in Wed Jul 09, 2014 6:23 pm:Regarding initialization order of subsystems in Nasal: it is doable but maybe a little dangerous, because if it isn't done correctly it can crash FG. That's about the only comment I have, I'm not familiar with the init process....


right, but it's not like people are going to touch those parts just because they're exposed. I mean, how many people do we have who regularly use closure/compile/call - or even just recently added fgcommands ?

Crashing the sim is already possible using various means/APIs, including those two fgcommands in particular (there's no validation taking place at all, use/miss an argument, and boom). But that's not a critical thing, because people aren't using those fgcommands.

The way I see this, there's going to be a single "default" mode re-implementing the existing fg_init.cxx init order - that won't be touched, and if so, only by people who know what they're doing.
Everybody else, e.g .interested in alternate startup modes (Nasal standalone/FGCanvas, headless, weather, AI etc) would obviously have to provide their own *.boot script to disable what they don't need and ensure that their needed subsystems work with the remaining subset of systems.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11321
Joined: Tue Mar 25, 2008 8:40 am

Re: Modular Nasal bootstrapping (again)

Postby Hooray » Wed Jul 09, 2014 7:28 pm

Philosopher wrote in Wed Jul 09, 2014 6:23 pm:Yeah, that's basically the current state. I was trying to make it more configurable/flexible, which is where I got stuck (reimplementing the same behavior wasn't too hard).


I haven't looked at your original C++ changes in a while, but for FGCanvas-testing, I just used a slightly-extended version of this:
Code: Select all
diff --git a/src/Main/options.cxx b/src/Main/options.cxx
index 0389faa..26eac9c 100644
--- a/src/Main/options.cxx
+++ b/src/Main/options.cxx
@@ -1434,8 +1434,9 @@ struct OptionDesc {
     int (*func)( const char * );
     } fgOptionArray[] = {
 
+    {"mode",                   true,  OPTION_STRING, "/sim/startup/boot-script", false, "default", 0 },
     {"language",                     true,  OPTION_IGNORE, "", false, "", 0 },
-   {"console",                      false, OPTION_IGNORE,   "", false, "", 0 },
+    {"console",                      false, OPTION_IGNORE,   "", false, "", 0 },
     {"disable-rembrandt",            false, OPTION_BOOL,   "/sim/rendering/rembrandt/enabled", false, "", 0 },
     {"enable-rembrandt",             false, OPTION_BOOL,   "/sim/rendering/rembrandt/enabled", true, "", 0 },
     {"renderer",                     true,  OPTION_STRING, "/sim/rendering/rembrandt/renderer", false, "", 0 },
diff --git a/src/Scripting/NasalSys.cxx b/src/Scripting/NasalSys.cxx
index fde6319..b8c2114 100644
--- a/src/Scripting/NasalSys.cxx
+++ b/src/Scripting/NasalSys.cxx
@@ -833,6 +833,7 @@ void FGNasalSys::init()
       .member("singleShot", &TimerObj::isSingleShot, &TimerObj::setSingleShot)
       .member("isRunning", &TimerObj::isRunning);
 
+#if 0
     // Now load the various source files in the Nasal directory
     simgear::Dir nasalDir(SGPath(globals->get_fg_root(), "Nasal"));
     loadScriptDirectory(nasalDir);
@@ -845,6 +846,20 @@ void FGNasalSys::init()
         simgear::PathList scripts = dir.children(simgear::Dir::TYPE_FILE, ".nas");
         addModule(directories[i].file(), scripts);
     }
+#endif
+
+    const char* boot_script = fgGetString("/sim/startup/boot-script", "default");
+    SGPath fullpath(globals->get_fg_root(), "Boot");
+    fullpath.append(boot_script);
+    fullpath.concat(".boot");
+
+
+    SG_LOG(SG_NASAL, SG_INFO, "Using boot script:" << fullpath);
+    SGPath file = fullpath.file();
+    if(!loadModule(fullpath, "boot")) {
+       SG_LOG(SG_NASAL, SG_ALERT, "Error could not load boot script:" << fullpath);
+    exit(-1);
+    }
 
     // set signal and remove node to avoid restoring at reinit
     const char *s = "nasal-dir-initialized";



As you can see, the file name of the "boot script" defaults to $FG_ROOT/Boot/default.boot but can be easily overridden to add custom modes.
Which is kinda where we could now add your bootstrap.nas logic and review the necessary C++ changes to make it work.
For testing purposes, I used io.nas as the template for my own boot script, i.e. to load globals.nas, props.nas etc

Once the hard-coded functionality is re-implemented, we can explore making things better configurable, i.e. more optional, over time.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11321
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Nasal

Who is online

Users browsing this forum: No registered users and 1 guest