Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Difference between revisions of "Talk:Nasal Initialization"

From FlightGear wiki
Jump to: navigation, search
m
(Custom modules: new section)
 
Line 1: Line 1:
 
== FGNasalSys init ==
 
== FGNasalSys init ==
 
Referring to your addition at [http://wiki.flightgear.org/index.php?title=Initializing_Nasal_early&diff=121300&oldid=121297], the FlightGear portion of the patch you can find at [[Initializing Nasal early]] is trivial, but it can be used to expose FlightGear's initialization to the property tree by using a so called [[Howto:Use Property Tree Objects|Property Object]]. That is exactly how the init sequence of fgfs has been documented on the article's talk page: [[Talk:Initializing_Nasal_early#Subsystem_Creation]]. To look at some of the original work, see the commits at [https://gitorious.org/fg/philosophers-flightgear?p=fg:philosophers-flightgear.git;a=commitdiff;h=c48b7aeb50765f38c589c544380eb9cd8e89a107]. In particular, you may want to take a look at the mechanism used to automatically dump the init sequence to a hash for inspection purposes [https://gitorious.org/fg/philosophers-flightgear?p=fg:philosophers-flightgear.git;a=commitdiff;h=cac82867615b03daaafd8f201ead6bde8eb06f6d]. In other words, if you'd like to understand parts of the current init sequence (nasal or not), this is a really straightforward approach - i.e. expose things via properties sg::PropertyObject<std::string> and then use a Nasal space listener to track all updates - at that point, you can automatically populate your wiki article, and don't need to manually do any reverse engineering, all you need to do is register a callback to track all loading of Nasal sources in sequential order, you can then use the CPP macros __FILE__, __FUNCTION__ and __LINE__ respectively to add useful information/pointers. That way, you end up with a self-documenting init sequence, which should also come in handy for stuff that bugman has been working on (regression testing and Python support). --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:34, 8 January 2020 (EST)
 
Referring to your addition at [http://wiki.flightgear.org/index.php?title=Initializing_Nasal_early&diff=121300&oldid=121297], the FlightGear portion of the patch you can find at [[Initializing Nasal early]] is trivial, but it can be used to expose FlightGear's initialization to the property tree by using a so called [[Howto:Use Property Tree Objects|Property Object]]. That is exactly how the init sequence of fgfs has been documented on the article's talk page: [[Talk:Initializing_Nasal_early#Subsystem_Creation]]. To look at some of the original work, see the commits at [https://gitorious.org/fg/philosophers-flightgear?p=fg:philosophers-flightgear.git;a=commitdiff;h=c48b7aeb50765f38c589c544380eb9cd8e89a107]. In particular, you may want to take a look at the mechanism used to automatically dump the init sequence to a hash for inspection purposes [https://gitorious.org/fg/philosophers-flightgear?p=fg:philosophers-flightgear.git;a=commitdiff;h=cac82867615b03daaafd8f201ead6bde8eb06f6d]. In other words, if you'd like to understand parts of the current init sequence (nasal or not), this is a really straightforward approach - i.e. expose things via properties sg::PropertyObject<std::string> and then use a Nasal space listener to track all updates - at that point, you can automatically populate your wiki article, and don't need to manually do any reverse engineering, all you need to do is register a callback to track all loading of Nasal sources in sequential order, you can then use the CPP macros __FILE__, __FUNCTION__ and __LINE__ respectively to add useful information/pointers. That way, you end up with a self-documenting init sequence, which should also come in handy for stuff that bugman has been working on (regression testing and Python support). --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:34, 8 January 2020 (EST)
 +
 +
== Custom modules ==
 +
 +
JSB, these aren't currently discussed in your article, but you may want to check out [[Creating_new_Nasal_scripts#Creating_new_Scripts]] (yes, that's in fact one of those evil articles mainly consisting of quotes collected from the devel list archives, containing pointers and information that isn't made available elsewhere, i.e. putting modules under $FG_HOME/Nasal). HTH --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:46, 9 January 2020 (EST)

Latest revision as of 14:46, 9 January 2020

FGNasalSys init

Referring to your addition at [1], the FlightGear portion of the patch you can find at Initializing Nasal early is trivial, but it can be used to expose FlightGear's initialization to the property tree by using a so called Property Object. That is exactly how the init sequence of fgfs has been documented on the article's talk page: Talk:Initializing_Nasal_early#Subsystem_Creation. To look at some of the original work, see the commits at [2]. In particular, you may want to take a look at the mechanism used to automatically dump the init sequence to a hash for inspection purposes [3]. In other words, if you'd like to understand parts of the current init sequence (nasal or not), this is a really straightforward approach - i.e. expose things via properties sg::PropertyObject<std::string> and then use a Nasal space listener to track all updates - at that point, you can automatically populate your wiki article, and don't need to manually do any reverse engineering, all you need to do is register a callback to track all loading of Nasal sources in sequential order, you can then use the CPP macros __FILE__, __FUNCTION__ and __LINE__ respectively to add useful information/pointers. That way, you end up with a self-documenting init sequence, which should also come in handy for stuff that bugman has been working on (regression testing and Python support). --Hooray (talk) 13:34, 8 January 2020 (EST)

Custom modules

JSB, these aren't currently discussed in your article, but you may want to check out Creating_new_Nasal_scripts#Creating_new_Scripts (yes, that's in fact one of those evil articles mainly consisting of quotes collected from the devel list archives, containing pointers and information that isn't made available elsewhere, i.e. putting modules under $FG_HOME/Nasal). HTH --Hooray (talk) 14:46, 9 January 2020 (EST)