[Flightgear-devel] Re: Subsystem run-levels
* James Turner -- Tuesday 18 April 2006 17:22: [runlevel groups] Melchior is probably the best person to comment on how appropriate or not these are for the Nasal scripts he's written. I'm not aware of any Nasal module that really depends on a subsystem, although I haven't looked with this in mind. Most or all of them only wait for other Nasal modules, especially for globals.nas and props.nas. m. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Subsystem run-levels
Melchior FRANZ wrote: * James Turner -- Tuesday 18 April 2006 17:22: [runlevel groups] Melchior is probably the best person to comment on how appropriate or not these are for the Nasal scripts he's written. I'm not aware of any Nasal module that really depends on a subsystem, although I haven't looked with this in mind. Most or all of them only wait for other Nasal modules, especially for globals.nas and props.nas. How about isinited() instead of isrunning() ? None of these will technically be running during the initialization phase. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Subsystem run-levels
On 18 Apr 2006, at 10:07, Melchior FRANZ wrote:As you know, the reason for Nasal being the last of the subsystems is that it processes the files in $FG_ROOT/Nasal/ on initialization. And the idea was that these scripts should find all subsystems initialized, so that they can access some generated properties immediately (such as values added by the envirnoment subsystem etc.). But some of the subsystems do in turn need Nasal, which is why the postinit() method was introduced. To make things worse, some of the startup Nasal scripts need each other. Most require props.nas, for example. And this is why we need the "settimer(INIT, 0)" delay.I noticed most of the above, and some of that evolution was apparent from the comments, but it's good to see the whole progression in one place! Alternatively, the subsystems could set a 'signal'. This is a trivial but useful feature that I introduced not too long ago. Some events in fgfs simply set a bool property in /sim/signals/, for example: /sim/signals/reinit on reinitialization (Shift-Esc), or /sim/signals/exit on exit. That way Nasal code can attach listeners to the signal, and have code triggered by the event. A wrapper around that could look like this: what) { setlistener("/sim/signals/subsystem/" ~ which, what); } Then Nasal files that *really* want to wait for a subsystem, could say on_subsystem_init("environment", print_temperature); Or one could make the boolean become true on subsystem initialization, and false on subsystem destruction (useful for changing aircraft during an fgfs session, etc.) My 'run-level' idea is almost the same, but rather than a flag, I'd have a /sim/runlevel property, and have the listeners watch for it changing. Eg, have the listener fire when run level was 4 or 8, and stop when the run-level dropped lower again. Having separate signals for each subsystem seems like overkill, but what I am considering is naming the groups, and then having a /sim/signals/ or /sim/subsystems/ entry for each; of course we would need to introduce finer-grained groups but that's easy enough to do - the code already works with everything in just one flat group!As I say, I'm still trying to decide what approach is cleaner; 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 initialized). 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.HHJames
[Flightgear-devel] Re: Subsystem run-levels
* Melchior FRANZ -- Tuesday 18 April 2006 11:07: Then Nasal files that *really* want to wait for a subsystem, could say on_subsystem_init(environment, print_temperature); Umm ... but what if it wants to wait for more than one subsystem. While possible, that would quickly become disgusting. Better real Nasal dependency resolution then. :-| m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Subsystem run-levels
On 18 Apr 2006, at 10:31, Melchior FRANZ wrote:Umm ... but what if it wants to wait for more than one subsystem. While possible, that would quickly become disgusting. Better real Nasal dependency resolution then. :-| I think adding more groups and keying off them is much easier - I don't have any experience of messing with the C++ side of Nasal yet. Of course, SGSubsystemGroup is /also/ a SGSubsystem, so there's no real problem if you want to add support for real dependencies - depending on a group is just the same as depending on a single subsystem!HHJames
Re: [Flightgear-devel] Re: Subsystem run-levels
On 18 Apr 2006, at 11:36, Melchior FRANZ wrote:I think adding more groups and keying off them is much easier Sure. This wasn't meant as argument against your sublevel idea. (In my code I had added Nasal to the INIT group weeks ago, because this could have solved an exit problem that I had at that time.)Funnily enough, that's what I did last night to get things working - and then I moved the 'end' part of NasalSys::init (running the scripts) to postinit() to try and keep things working; I'm sure that's not really the correct solution but it got things limping along.snip Heh, but now I better stop talking about what Andy wants and doesn't want. He'll certainly tell us. :-) Yes indeed.HHJames
[Flightgear-devel] Re: Subsystem run-levels
* Melchior FRANZ -- Tuesday 18 April 2006 12:49: * James Turner -- Tuesday 18 April 2006 12:44: I moved the 'end' part of NasalSys::init (running the scripts) to postinit() to try and keep things working; I'm sure that's not really the correct solution but it got things limping along. It probably breaks joystick drivers [...] Umm, no. The end part?! This should be OK then. But it gets more and more fragile because of such manually resolved dependencies. m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: Subsystem run-levels
* Melchior FRANZ -- Tuesday 18 April 2006 12:53: * Melchior FRANZ -- Tuesday 18 April 2006 12:49: * James Turner -- Tuesday 18 April 2006 12:44: I moved the 'end' part of NasalSys::init (running the scripts) to postinit() It probably breaks joystick drivers [...] Umm, no. The end part?! This should be OK then. Note to myself: first think, then post ... The input subsystem's postinit() depends on the end part (loading of $FG_ROOT/Nasal/*.nas files) being done, because joystick drivers need globals.nas, props.nas and possibly others. Or are we going to move that into postpostinit()? :-} m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Subsystem run-levels
On 18 Apr 2006, at 11:53, Melchior FRANZ wrote:Umm, no. The "end part"?! This should be OK then. But it gets more and more fragile because of such manually resolved dependencies. Agreed - hence this discussion. Otherwise we'll end up with postpostpostinit(), or as I like to call it, 'run level 4' :)HHJames
