[Flightgear-devel] [OT] The End of Python
It looks like Python's days are numbered; I just read on Slashdot about a programming language that uses *only* whitespace: http://compsoc.dur.ac.uk/whitespace/ I expect that most current Python programmers will have switched over by the end of the year. Any die-hard fanatics left over will no doubt write a Punctuation programming language, using only the characters [EMAIL PROTECTED]*() (above 0-9 on the U.S. keyboard), as a pure act of spite to try to split the Perl community. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] The End of Python
David Megginson wrote: It looks like Python's days are numbered; I just read on Slashdot about a programming language that uses *only* whitespace: http://compsoc.dur.ac.uk/whitespace/ Knowing the python developer base a little, I think they might have implemented this in a couple of hours before they start thinking about it ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] The End of Python
I am waiting for the programming language for amateur radio operators, Morse. There is nothing like programming in dots and dashes! On Tuesday, April 1, 2003, at 06:11 AM, David Megginson wrote: It looks like Python's days are numbered; I just read on Slashdot about a programming language that uses *only* whitespace: http://compsoc.dur.ac.uk/whitespace/ I expect that most current Python programmers will have switched over by the end of the year. Any die-hard fanatics left over will no doubt write a Punctuation programming language, using only the characters [EMAIL PROTECTED]*() (above 0-9 on the U.S. keyboard), as a pure act of spite to try to split the Perl community. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] The End of Python
On Tue, 01 Apr 2003 14:39:22 +0200, Erik Hofman [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: David Megginson wrote: It looks like Python's days are numbered; I just read on Slashdot about a programming language that uses *only* whitespace: http://compsoc.dur.ac.uk/whitespace/ ..WTG, WTG. ;-) Knowing the python developer base a little, I think they might have implemented this in a couple of hours before they start thinking about it ... Erik ..should not be too hard, only 3 characters. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] The End of Python
I am waiting for the programming language for amateur radio operators, Morse. There is nothing like programming in dots and dashes! . -.-- --..-- - .- - .. ... -. .. -.-. . .-.-.- g. (kc7afe) On Tuesday, April 1, 2003, at 06:11 AM, David Megginson wrote: It looks like Python's days are numbered; I just read on Slashdot about a programming language that uses *only* whitespace: http://compsoc.dur.ac.uk/whitespace/ I expect that most current Python programmers will have switched over by the end of the year. Any die-hard fanatics left over will no doubt write a Punctuation programming language, using only the characters [EMAIL PROTECTED]*() (above 0-9 on the U.S. keyboard), as a pure act of spite to try to split the Perl community. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Rearranged /controls/ properties
Now that we're rearranging the /controls/ subtree, it might be a good
time to clean up the naming.
1. Consistency
--
Most of the property names use lower case and hyphens ('-') as word
separators. I suggest that we fix the following to be consistent:
/controls/flight/BLC
/controls/engines/engine[%d]/WEP
/controls/fuel/tank[%d]/fuel_selector
/controls/fuel/tank[%d]/to_engine
/controls/fuel/tank[%d]/to_tank
/controls/electric/APU-generator
/controls/pneumatic/APU-bleed
2. Units
In flightgear, we use suffixes for most property names to indicate the
units (such as /position/altitude-ft or /environment/wind-speed-kt).
Many of the control properties, however, are either normalized values
(0:1 or -1:1) or boolean flags.
Would it make sense to add suffixes to these as well?
/controls/flight/aileron-norm
/controls/gear/gear-down-flag
(or something similar)?
3. Switches
---
Note that Curt's electrical system has a /controls/switches subtree,
while the recent rewrite has a /controls/lighting subtree. We need to
choose one or the other.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rearranged /controls/ properties
David Megginson wrote:
Now that we're rearranging the /controls/ subtree, it might be a good
time to clean up the naming.
I am all for (property naming) consistency and I am for selecting the
tree layout now, and stick with it from now on.
There are a few property names I wouldn't have chosen, but I think it
would be of the greatest importance to pick one, and get over it ;-)
1. Consistency
--
Most of the property names use lower case and hyphens ('-') as word
separators. I suggest that we fix the following to be consistent:
/controls/flight/BLC
/controls/engines/engine[%d]/WEP
/controls/fuel/tank[%d]/fuel_selector
/controls/fuel/tank[%d]/to_engine
/controls/fuel/tank[%d]/to_tank
/controls/electric/APU-generator
/controls/pneumatic/APU-bleed
Sound good to me.
2. Units
In flightgear, we use suffixes for most property names to indicate the
units (such as /position/altitude-ft or /environment/wind-speed-kt).
Many of the control properties, however, are either normalized values
(0:1 or -1:1) or boolean flags.
Would it make sense to add suffixes to these as well?
/controls/flight/aileron-norm
/controls/gear/gear-down-flag
(or something similar)?
Maybe we shouldn't even make a distinction between flags and normalized
values and call every boolean -*-norm also.
3. Switches
---
Note that Curt's electrical system has a /controls/switches subtree,
while the recent rewrite has a /controls/lighting subtree. We need to
choose one or the other.
Stick with switches, I expect more switches will be available that are
non lighting related.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] The End of Python
On Tue, 1 Apr 2003 07:12:36 -0600, Jonathan Polley [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: On Tuesday, April 1, 2003, at 06:11 AM, David Megginson wrote: It looks like Python's days are numbered; I just read on Slashdot about a programming language that uses *only* whitespace: http://compsoc.dur.ac.uk/whitespace/ I expect that most current Python programmers will have switched over by the end of the year. Any die-hard fanatics left over will no doubt write a Punctuation programming language, using only the characters [EMAIL PROTECTED]*() (above 0-9 on the U.S. keyboard), as a pure act of spite to try to split the Perl community. I am waiting for the programming language for amateur radio operators, Morse. There is nothing like programming in dots and dashes! ..embedded, use space and tabs. Surplus line feed character can be used to change tape spool reel, see the tutorial. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] The End of Python
Jonathan Polley writes: I am waiting for the programming language for amateur radio operators, Morse. There is nothing like programming in dots and dashes! .. -.. --- -. - --. . - .. - All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] A bit of a mess
I am very happy that we are reorganizing the mess under /controls, but unfortunately, we've landed in a bit of a deeper mess that will need some fixing. The changes just committed for the base package are extremely incomplete: many of the YASim flight models under Aircraft-yasim/ and many of the joystick config files have not been updated. Some users won't be able to fly anything, while others will not be able to fly specific planes (like the DC-3 or the J3 Cub). Erik checked in the patches, but I don't remember who contributed them; we'll need to either roll them back out or (preferably) hunt down all of the problems. Here's an easy way to start: cd $FG_ROOT find . -name '*.xml' -print | xargs grep /controls/throttle find . -name '*.xml' -print | xargs grep /controls/elevator find . -name '*.xml' -print | xargs grep /controls/aileron find . -name '*.xml' -print | xargs grep /controls/mixture and so on. I find 62 references to /controls/throttle alone. I am willing to help. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] The End of Python
You could conceivably write any language in Morse, you just need to run a .- to ASCII converter over the source before the compiler. I suppose it would be called -.2a Richard -Original Message- From: Jonathan Polley [mailto:[EMAIL PROTECTED] Sent: 01 April 2003 2:13 pm To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] [OT] The End of Python I am waiting for the programming language for amateur radio operators, Morse. There is nothing like programming in dots and dashes! On Tuesday, April 1, 2003, at 06:11 AM, David Megginson wrote: It looks like Python's days are numbered; I just read on Slashdot about a programming language that uses *only* whitespace: http://compsoc.dur.ac.uk/whitespace/ I expect that most current Python programmers will have switched over by the end of the year. Any die-hard fanatics left over will no doubt write a Punctuation programming language, using only the characters [EMAIL PROTECTED]*() (above 0-9 on the U.S. keyboard), as a pure act of spite to try to split the Perl community. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A bit of a mess
For me, FlightGear just dies with the message FlightGear aborted for JSBSim models or simply Aborted for yasim models. :-( I'm totally dead in the water here. This needs to get resolved quickly. Curt. David Megginson writes: I am very happy that we are reorganizing the mess under /controls, but unfortunately, we've landed in a bit of a deeper mess that will need some fixing. The changes just committed for the base package are extremely incomplete: many of the YASim flight models under Aircraft-yasim/ and many of the joystick config files have not been updated. Some users won't be able to fly anything, while others will not be able to fly specific planes (like the DC-3 or the J3 Cub). Erik checked in the patches, but I don't remember who contributed them; we'll need to either roll them back out or (preferably) hunt down all of the problems. Here's an easy way to start: cd $FG_ROOT find . -name '*.xml' -print | xargs grep /controls/throttle find . -name '*.xml' -print | xargs grep /controls/elevator find . -name '*.xml' -print | xargs grep /controls/aileron find . -name '*.xml' -print | xargs grep /controls/mixture and so on. I find 62 references to /controls/throttle alone. I am willing to help. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rearranged /controls/ properties
David Megginson writes:
Now that we're rearranging the /controls/ subtree, it might be a good
time to clean up the naming.
1. Consistency
--
Most of the property names use lower case and hyphens ('-') as word
separators. I suggest that we fix the following to be consistent:
/controls/flight/BLC
/controls/engines/engine[%d]/WEP
/controls/fuel/tank[%d]/fuel_selector
/controls/fuel/tank[%d]/to_engine
/controls/fuel/tank[%d]/to_tank
/controls/electric/APU-generator
/controls/pneumatic/APU-bleed
This sounds reasonable.
2. Units
In flightgear, we use suffixes for most property names to indicate the
units (such as /position/altitude-ft or /environment/wind-speed-kt).
Many of the control properties, however, are either normalized values
(0:1 or -1:1) or boolean flags.
Would it make sense to add suffixes to these as well?
/controls/flight/aileron-norm
/controls/gear/gear-down-flag
(or something similar)?
This is a bit more verbose, but having the units at the end of the
name is a life saver ... I don't want to think about the number of
times I've had to go digging after a bug that turned out to be a
meters/feet conversion problem or some other units mixup. This won't
make all those problems magically go away, but it will help in many
cases.
3. Switches
---
Note that Curt's electrical system has a /controls/switches subtree,
while the recent rewrite has a /controls/lighting subtree. We need to
choose one or the other.
Electrical switches and circuit breakers can control a *lot* more
things than just lighting. I vote for /controls/switches/
Regards,
Curt.
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] The End of Python
David Megginson writes: It looks like Python's days are numbered; I just read on Slashdot about a programming language that uses *only* whitespace: http://compsoc.dur.ac.uk/whitespace/ I expect that most current Python programmers will have switched over by the end of the year. Any die-hard fanatics left over will no doubt write a Punctuation programming language, using only the characters [EMAIL PROTECTED]*() (above 0-9 on the U.S. keyboard), as a pure act of spite to try to split the Perl community. One real advantage of this langauge is that it's source files compress really well. This can save a lot of disk space, especially with a project the size of Flight/Sim/TerraGear. As soon as the wsfront utility is finished, we could seriously consider porting the entire project over. Compile times can really benefit too. WS doesn't use tokens as part of it's syntax, and a large portion of a typical compiler is devoted to parsing tokens, hashing them, and ultimately just translating them into a number anyway. WS skips this entire level of indirection which can be a huge performance boost and can drastically reduce the compiler's memory foot print. This also enables the programmer to write much more direct and straightforward code. The only issue I can see up front is on windows ... typically windows will misinterpret certain combinations of white space characters. This could be one slightly sticky problem, at least until MS fixes this bug. Speaking of which, WS sneakily avoids another major bug in windows. Because it doesn't directly use characters, it avoids windows problems with lack of case sensitivety, and isn't affected by it's tendency to change certain capitalizations. Best of all WS is intuitive and not encumbered by huge unwieldy standards bodies who drag their heels on every good idea or who try to lock you into proprietary solutions. Some groups are complaining that the name of this language isn't culturally neutral. They are suggesting perhaps BackSpace would be a better name since this is often the most frequently used character in the WhiteSpace language. We'll have to keep on eye on the development of this language. If nothing else we could use it as our default embedded scripting language. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A bit of a mess
David Megginson wrote: Unfortunatelly my ISP decided it would be funny to shut down my internet connection just after I uploaded the new files today. I presume you started to hunt them down already? I've been digging through a number of files as well, and think we should continue now. BAcking them out after problems like these means we probably never will be able to get some tough problems solved. So I say, go for it. If some one still spots a problem, please report. Erik I am very happy that we are reorganizing the mess under /controls, but unfortunately, we've landed in a bit of a deeper mess that will need some fixing. The changes just committed for the base package are extremely incomplete: many of the YASim flight models under Aircraft-yasim/ and many of the joystick config files have not been updated. Some users won't be able to fly anything, while others will not be able to fly specific planes (like the DC-3 or the J3 Cub). Erik checked in the patches, but I don't remember who contributed them; we'll need to either roll them back out or (preferably) hunt down all of the problems. Here's an easy way to start: cd $FG_ROOT find . -name '*.xml' -print | xargs grep /controls/throttle find . -name '*.xml' -print | xargs grep /controls/elevator find . -name '*.xml' -print | xargs grep /controls/aileron find . -name '*.xml' -print | xargs grep /controls/mixture and so on. I find 62 references to /controls/throttle alone. I am willing to help. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] The End of Python
I am waiting for the programming language for amateur radio operators, Morse. There is nothing like programming in dots and dashes! .. -.. --- -. - --. . - .. - uet? Eh? ITYM, --. ... . HTH, HAND! g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] The End of Python
Boy, talk about the ultimate in obfuscated C programming... On Tue, 1 Apr 2003, Richard Bytheway wrote: You could conceivably write any language in Morse, you just need to run a .- to ASCII converter over the source before the compiler. I suppose it would be called -.2a Richard -Original Message- From: Jonathan Polley [mailto:[EMAIL PROTECTED] Sent: 01 April 2003 2:13 pm To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] [OT] The End of Python I am waiting for the programming language for amateur radio operators, Morse. There is nothing like programming in dots and dashes! On Tuesday, April 1, 2003, at 06:11 AM, David Megginson wrote: It looks like Python's days are numbered; I just read on Slashdot about a programming language that uses *only* whitespace: http://compsoc.dur.ac.uk/whitespace/ I expect that most current Python programmers will have switched over by the end of the year. Any die-hard fanatics left over will no doubt write a Punctuation programming language, using only the characters [EMAIL PROTECTED]*() (above 0-9 on the U.S. keyboard), as a pure act of spite to try to split the Perl community. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A bit of a mess
Curtis L. Olson wrote: For me, FlightGear just dies with the message FlightGear aborted for JSBSim models or simply Aborted for yasim models. :-( I'm totally dead in the water here. This needs to get resolved quickly. The lates CVS version of the base package and FlightGear *and* a complete recompile gives me a running F-16 here. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A bit of a mess
On Tue, 01 Apr 2003 19:00:30 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Curtis L. Olson wrote: For me, FlightGear just dies with the message FlightGear aborted for JSBSim models or simply Aborted for yasim models. :-( I'm totally dead in the water here. This needs to get resolved quickly. The lates CVS version of the base package and FlightGear *and* a complete recompile gives me a running F-16 here. Try the X-15, the C-310, and the C-172, as well. I've always thought that there should be at least a minimal set of regression tests run before anything is committed to any CVS. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A bit of a mess
David Megginson [EMAIL PROTECTED] said: I am very happy that we are reorganizing the mess under /controls, but unfortunately, we've landed in a bit of a deeper mess that will need some fixing. The changes just committed for the base package are extremely incomplete: many of the YASim flight models under Aircraft-yasim/ and many of the joystick config files have not been updated. It isn't clear to me when an O/S project should consider the interests of users and third party developers (if there is such a thing). Obviously the base package should be updated, but wouldn't it make sense to provide some sort of backwards compatibility with an alias table or something like that? I am willing to help. So am I. I'll take the X45 joystick to start (since I have one) and for aircraft the A-4, 747, and what little there is on the p51d so far. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A bit of a mess
Jon S Berndt wrote: On Tue, 01 Apr 2003 19:00:30 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Curtis L. Olson wrote: For me, FlightGear just dies with the message FlightGear aborted for JSBSim models or simply Aborted for yasim models. :-( I'm totally dead in the water here. This needs to get resolved quickly. The lates CVS version of the base package and FlightGear *and* a complete recompile gives me a running F-16 here. Try the X-15, the C-310, and the C-172, as well. No problem here. I've always thought that there should be at least a minimal set of regression tests run before anything is committed to any CVS. Well, obviosuly I can't test everything when comitting a change like this. Eevn if it's just because I don't have all the hardware to test with (heck, my O2 doesn't even support joysticks). It was already a hughe task to get this stuff in, and thanks to David it worked out quite a bit faster. And I don't think it's fair to demand a painles recompile of the *developers* version of FlightGear every minute of the day. Erik. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A bit of a mess
Jim Wilson wrote: David Megginson [EMAIL PROTECTED] said: I am very happy that we are reorganizing the mess under /controls, but unfortunately, we've landed in a bit of a deeper mess that will need some fixing. The changes just committed for the base package are extremely incomplete: many of the YASim flight models under Aircraft-yasim/ and many of the joystick config files have not been updated. It isn't clear to me when an O/S project should consider the interests of users and third party developers (if there is such a thing). Obviously the base package should be updated, but wouldn't it make sense to provide some sort of backwards compatibility with an alias table or something like that? No one objected in advance. So am I. I'll take the X45 joystick to start (since I have one) and for aircraft the A-4, 747, and what little there is on the p51d so far. They should be okay already. Thanks for the willing to help. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A bit of a mess
Erik Hofman writes: Jon S Berndt wrote: On Tue, 01 Apr 2003 19:00:30 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Curtis L. Olson wrote: For me, FlightGear just dies with the message FlightGear aborted for JSBSim models or simply Aborted for yasim models. :-( I'm totally dead in the water here. This needs to get resolved quickly. The lates CVS version of the base package and FlightGear *and* a complete recompile gives me a running F-16 here. Try the X-15, the C-310, and the C-172, as well. No problem here. I'm still dead in the water. I appear to be dying somewhere in fgInitSubsystems() How the heck can I reenable debugging output?!? I see there is a --log-level option in options.cxx but it's not described in --help --verbose and using it seems to have no effect. Thanks, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] debugging output
How do I reenable debugging output? Thanks, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rearranged /controls/ properties
Erik Hofman writes: There are a few property names I wouldn't have chosen, but I think it would be of the greatest importance to pick one, and get over it ;-) Thanks for reminding me -- the propeller-pitch property is misnamed, and we should try to think of something more descriptive (it directly controls propeller speed, not pitch). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A bit of a mess
Curtis L. Olson writes: For me, FlightGear just dies with the message FlightGear aborted for JSBSim models or simply Aborted for yasim models. :-( I'm totally dead in the water here. This needs to get resolved quickly. Through the magic of Emacs and etags, I was able to replace zillions of property names this morning, mainly in the base package. Try a new checkout. All the best, David p.s. cd $FG_ROOT find . -name '*.xml' -print | xargs etags -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A bit of a mess
David Megginson writes: Curtis L. Olson writes: For me, FlightGear just dies with the message FlightGear aborted for JSBSim models or simply Aborted for yasim models. :-( I'm totally dead in the water here. This needs to get resolved quickly. Through the magic of Emacs and etags, I was able to replace zillions of property names this morning, mainly in the base package. Try a new checkout. I have done this every 5 minutes for the last hour ... I don't think that is it ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] debugging output
Curtis L. Olson writes:
How do I reenable debugging output?
maybe
main.cxx
static bool fgMainInit( int argc, char **argv ) {
// set default log levels
sglog().setLogLevels( SG_ALL, SG_INFO );
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Rearranged /controls/ properties
David Megginson writes: Thanks for reminding me -- the propeller-pitch property is misnamed, and we should try to think of something more descriptive (it directly controls propeller speed, not pitch). Not that we don't want a new name but aren't these two (pitch, propellor speed) the ~same~ thing assuming a variable pitch prop Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Rearranged /controls/ properties
On Tue, 2003-04-01 at 13:28, Norman Vine wrote: David Megginson writes: Thanks for reminding me -- the propeller-pitch property is misnamed, and we should try to think of something more descriptive (it directly controls propeller speed, not pitch). Not that we don't want a new name but aren't these two (pitch, propellor speed) the ~same~ thing assuming a variable pitch prop Why not call it propeller-governor? Same meaning, but clearer, IMHO. -Luke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] debugging output
Norman Vine wrote:
Curtis L. Olson writes:
How do I reenable debugging output?
maybe
main.cxx
static bool fgMainInit( int argc, char **argv ) {
// set default log levels
sglog().setLogLevels( SG_ALL, SG_INFO );
That was one of the things in the back of my head which needed to be
done some time.
Whta is happening is there is a pint where the --log-level option
actually starts working (inside fgMainLoop() ) but before that the log
level is set by the line Norman pointed out.
It's in CVS now.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A bit of a mess
Erik Hofman [EMAIL PROTECTED] said: Jim Wilson wrote: David Megginson [EMAIL PROTECTED] said: I am very happy that we are reorganizing the mess under /controls, but unfortunately, we've landed in a bit of a deeper mess that will need some fixing. The changes just committed for the base package are extremely incomplete: many of the YASim flight models under Aircraft-yasim/ and many of the joystick config files have not been updated. It isn't clear to me when an O/S project should consider the interests of users and third party developers (if there is such a thing). Obviously the base package should be updated, but wouldn't it make sense to provide some sort of backwards compatibility with an alias table or something like that? No one objected in advance. No one reading the list regularly, that is. This isn't intended to be an objection by any means, just something to think about. I really have no idea what impact this might have. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] camera.hpp
Greetings! I'm trying to install SimGear-0.3.0, but camera.hpp is missing. Would someone please post that file. I've searched the internet to no avail. Thanks! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] debugging output
Norman Vine writes:
Curtis L. Olson writes:
How do I reenable debugging output?
maybe
main.cxx
static bool fgMainInit( int argc, char **argv ) {
// set default log levels
sglog().setLogLevels( SG_ALL, SG_INFO );
Yes, but this was reworked so it could be done from the command line I
thought.
Curt.
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] controls-bind()
I tracked down my crash to controls-bind() There you will find a plethora of places where the code is sprintf'ing to a char[32] array, but the contents is often longer than 32 bytes. Might not have been crashing everyone else (building with -g?) but it was crashing with -O2. Fixed in cvs ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A bit of a mess
Curtis L. Olson wrote: I'm still dead in the water. I appear to be dying somewhere in fgInitSubsystems() How the heck can I reenable debugging output?!? I see there is a --log-level option in options.cxx but it's not described in --help --verbose and using it seems to have no effect. Do you use any special features or configuration files? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Rearranged /controls/ properties
Norman Vine writes: Not that we don't want a new name but aren't these two (pitch, propellor speed) the ~same~ thing assuming a variable pitch prop No. With a variable-pitch prop, the rpm will vary with both the pitch setting and the throttle setting, but those have not been in use for 70 years or so. With a constant-speed prop, the governor will attempt to maintain a constant RPM across a range of throttle settings by constantly varying the propeller pitch. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A bit of a mess
Erik Hofman [EMAIL PROTECTED] said: And I don't think it's fair to demand a painles recompile of the *developers* version of FlightGear every minute of the day. Agree with all you said, except maybe this. Demand is one thing, expect is another. It is fair to demand it. I'm not talking about you or this update, but a few minutes of short cutting by one can cause cummulative hours of trouble for other developers. And effectively shut down new work. On the other hand we shouldn't expect painless recompile, that just isn't realistic. I think that is probably what you meant. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] debugging output
Erik Hofman writes: Whta is happening is there is a pint where the --log-level option actually starts working (inside fgMainLoop() ) but before that the log level is set by the line Norman pointed out. We also seem to have a variety of ways to set logging. In main.cxx, there is code that uses the property /sim/log-level with an integer value. However, in fg_props.cxx, FlightGear also uses /sim/logging/priority /sim/logging/classes with string values (I added those a long time ago). I'm not sure how the two interact. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] controls-bind()
Curtis L. Olson wrote: I tracked down my crash to controls-bind() There you will find a plethora of places where the code is sprintf'ing to a char[32] array, but the contents is often longer than 32 bytes. Might not have been crashing everyone else (building with -g?) but it was crashing with -O2. Fixed in cvs ... Is there still no replacement function to do this kind of operation in a C++ string? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] debugging output
David Megginson wrote: We also seem to have a variety of ways to set logging. In main.cxx, there is code that uses the property /sim/log-level with an integer value. However, in fg_props.cxx, FlightGear also uses /sim/logging/priority /sim/logging/classes with string values (I added those a long time ago). I'm not sure how the two interact. I thought these were for property logging? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] re: [Flightgear-cvslogs] CVS: FlightGear/src/Controls controls.cxx,1.5,1.6
Curtis L. Olson writes:
You bastards! Writing property names to char arrays that are too short for
the data you are putting in it. :-( Fixed ...
for (index = 0; index MAX_ENGINES; index++) {
! char name[32];
sprintf(name, /controls/engines/engine[%d]/throttle, index);
fgTie(name, this, index,
--- 276,280
for (index = 0; index MAX_ENGINES; index++) {
! char name[MAX_NAME_LEN];
sprintf(name, /controls/engines/engine[%d]/throttle, index);
fgTie(name, this, index,
etc.
Note that there is no need to code things this way. Here's a cleaner
alternative, avoiding sprintf altogether:
for (index = 0; index MAX_ENGINES; index++) {
SGPropertyNode * node =
fgGetNode(/controls/engines/engine, index, true);
node-tie(throttle,
SGRawValueMethodsIndexed(this, index,
FGControls::get_throttle,
FGControls::set_throttle));
node-tie(mixture,
SGRawValueMethodsIndexed(this, index,
FGControls::get_mixture,
FGControls::set_mixture));
// and so on ...
}
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Rearranged /controls/ properties
David Megginson writes: With a constant-speed prop, the governor will attempt to maintain a constant RPM across a range of throttle settings by constantly varying the propeller pitch. I think you just uncovered your new name Note that 'constant-speed' is not mentioned in the original post Thanks for reminding me -- the propeller-pitch property is misnamed, and we should try to think of something more descriptive (it directly controls propeller speed, not pitch). FWIW - I still maintain that for a variable pitch prop propeller speed and pitch are the ~same~ Perhaps this is easier to think of as 'screw distance' or 'Work' Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Eye Candy
If you have a machine to run this on :-) http://www.daionet.gr.jp/~masa/rthdribl/index.html Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] A fun garage project ... (?)
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=2167383299 -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A bit of a mess
Jim Wilson wrote: Erik Hofman [EMAIL PROTECTED] said: And I don't think it's fair to demand a painles recompile of the *developers* version of FlightGear every minute of the day. Agree with all you said, except maybe this. Demand is one thing, expect is another. It is fair to demand it. I'm not talking about you or this update, but a few minutes of short cutting by one can cause cummulative hours of trouble for other developers. And effectively shut down new work. On the other hand we shouldn't expect painless recompile, that just isn't realistic. I think that is probably what you meant. Ehm, yes. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] debugging output
Erik Hofman writes: However, in fg_props.cxx, FlightGear also uses /sim/logging/priority /sim/logging/classes with string values (I added those a long time ago). I'm not sure how the two interact. I thought these were for property logging? No, that's controlled by logger.[ch]xx. You can set /sim/logging/priority to any of the following values: bulk debug info warn alert You can set /sim/logging/classes to a whitespace-separated list of any or all of the following values: terrain astro flight input gl view cockpit general math event aircraft autopilot io clipper network You can also use one of the values all or none. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] controls-bind()
Erik Hofman writes: Is there still no replacement function to do this kind of operation in a C++ string? strstream would do the trick, but not all compilers support it yet. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A fun garage project ... (?)
On Tue, 1 Apr 2003 13:16:19 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=2167383299 ..looks like a fellow modeller: http://cgi.ebay.com/ws/ebayISAPI.dll?MfcISAPICommand=ViewItemitem=2167383299indexURL=1photoDisplayType=2#ebaylargephotohosting -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rearranged /controls/ properties
On Tue, 2003-04-01 at 08:21, Erik Hofman wrote:
David Megginson wrote:
Now that we're rearranging the /controls/ subtree, it might be a good
time to clean up the naming.
I am all for (property naming) consistency and I am for selecting the
tree layout now, and stick with it from now on.
There are a few property names I wouldn't have chosen, but I think it
would be of the greatest importance to pick one, and get over it ;-)
1. Consistency
--
Most of the property names use lower case and hyphens ('-') as word
separators. I suggest that we fix the following to be consistent:
/controls/flight/BLC
/controls/engines/engine[%d]/WEP
/controls/fuel/tank[%d]/fuel_selector
/controls/fuel/tank[%d]/to_engine
/controls/fuel/tank[%d]/to_tank
/controls/electric/APU-generator
/controls/pneumatic/APU-bleed
Sound good to me.
2. Units
In flightgear, we use suffixes for most property names to indicate the
units (such as /position/altitude-ft or /environment/wind-speed-kt).
Many of the control properties, however, are either normalized values
(0:1 or -1:1) or boolean flags.
Would it make sense to add suffixes to these as well?
/controls/flight/aileron-norm
/controls/gear/gear-down-flag
(or something similar)?
Maybe we shouldn't even make a distinction between flags and normalized
values and call every boolean -*-norm also.
I'd prefer the -norm be left to values that continuously vary rather
than discretes.
3. Switches
---
Note that Curt's electrical system has a /controls/switches subtree,
while the recent rewrite has a /controls/lighting subtree. We need to
choose one or the other.
Stick with switches, I expect more switches will be available that are
non lighting related.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
Tony Peden [EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] The End of Python
On Tue, 2003-04-01 at 07:29, Curtis L. Olson wrote: David Megginson writes: It looks like Python's days are numbered; I just read on Slashdot about a programming language that uses *only* whitespace: http://compsoc.dur.ac.uk/whitespace/ I expect that most current Python programmers will have switched over by the end of the year. Any die-hard fanatics left over will no doubt write a Punctuation programming language, using only the characters [EMAIL PROTECTED]*() (above 0-9 on the U.S. keyboard), as a pure act of spite to try to split the Perl community. One real advantage of this langauge is that it's source files compress really well. This can save a lot of disk space, especially with a project the size of Flight/Sim/TerraGear. As soon as the wsfront utility is finished, we could seriously consider porting the entire project over. Compile times can really benefit too. WS doesn't use tokens as part of it's syntax, and a large portion of a typical compiler is devoted to parsing tokens, hashing them, and ultimately just translating them into a number anyway. WS skips this entire level of indirection which can be a huge performance boost and can drastically reduce the compiler's memory foot print. This also enables the programmer to write much more direct and straightforward code. The only issue I can see up front is on windows ... typically windows will misinterpret certain combinations of white space characters. This could be one slightly sticky problem, at least until MS fixes this bug. Speaking of which, WS sneakily avoids another major bug in windows. Because it doesn't directly use characters, it avoids windows problems with lack of case sensitivety, and isn't affected by it's tendency to change certain capitalizations. Best of all WS is intuitive and not encumbered by huge unwieldy standards bodies who drag their heels on every good idea or who try to lock you into proprietary solutions. Some groups are complaining that the name of this language isn't culturally neutral. They are suggesting perhaps BackSpace would be a better name since this is often the most frequently used character in the WhiteSpace language. We'll have to keep on eye on the development of this language. If nothing else we could use it as our default embedded scripting language. If this isn't incentive enough to keep FG cvs working I don't know what is. It's clear you've had entirely too much time on your hands today. ;-) Regards, Curt. -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: Gimp and small textures
On Mon 31. March 2003 19:53, you wrote: Martin Dressler wrote: I made some investigations in last days and find why my textures look so bad when scaled down to 128x128 textures compared to textures generated by perl scripts (writen by Andy?) Uh, once upon a time, yeah. They're terrible hacks; not exactly my best work. :) But works good, I only don't like, that it is perl :o) The problem isn't in scaling, because these scripts scale down too, but the diference is in how gimp render lines and ghostscript render lines. No, it's the scaling. Ghostscript doesn't do antialiasing at all, it just colors whole pixels. The scripts use gs to rasterize the image at 4x (or even 16x, to get the whole 8 bit gray range) resolution and then downsample to the target resolution using ImageMagick's mogrify program. So it mean that gimp use bad antialiasing or render lines in some bad way. Because Gimp scale with the same quality as ImageMagic. Is it posibble to change these scripts to produce dials with fully transparent background, or give them some texture to render on it. The original scripts hack in alpha by using a chroma key. If you draw anything in pure blue (I think), it'll come out transparent. This actually exploits Ghostscript's inability to do sub-pixel rendering. I think the alpha stuff was actually done with a tiny C program, but I forget. :) A tiny perl program. So if I delete background, It will render in white on pure blue and after scale down I will get transparent layer with white lines only. It is exactly what i wanted. I have one more question. Is it posible and how to specify color in postscript by RGB components? Thank, Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Question on tuesday's preferences.xml update
The magnetos are now defaulted to position 2 (Left) instead of 0 (Off). Was that intentional? Is there anything else in global preferences not mentioned in the log? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A bit of a mess
Jim Wilson writes: Erik Hofman [EMAIL PROTECTED] said: And I don't think it's fair to demand a painles recompile of the *developers* version of FlightGear every minute of the day. Agree with all you said, except maybe this. Demand is one thing, expect is another. It is fair to demand it. I'm not talking about you or this update, but a few minutes of short cutting by one can cause cummulative hours of trouble for other developers. And effectively shut down new work. On the other hand we shouldn't expect painless recompile, that just isn't realistic. I think that is probably what you meant. I just get panicy when things are broke, and the longer they stay broke the more paniced I get. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] debugging output
David Megginson wrote: Erik Hofman writes: However, in fg_props.cxx, FlightGear also uses /sim/logging/priority /sim/logging/classes with string values (I added those a long time ago). I'm not sure how the two interact. I thought these were for property logging? No, that's controlled by logger.[ch]xx. You can set /sim/logging/priority to any of the following values: You can set /sim/logging/classes to a whitespace-separated list of any or all of the following values: Okay, I'll keep that in mind. Whenever I find some time I'll change it. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] debugging output
* [EMAIL PROTECTED] (David Megginson) [2003.04.01 13:31]: You can set /sim/logging/classes to a whitespace-separated list of any or all of the following values: terrain astro flight input gl view cockpit general math event aircraft autopilot io clipper network You can also use one of the values all or none. Perhaps we could change to a comma-delimited list so we can read it directly in from the command-line line like: --log-classes=flight,aircraft,autopilot I guess it's simple enough to s/,/ /g but thought I'd poke my head out from behind my cubicle to cause some trouble. :-) -- Cameron Moore / I asked the librarian where the self-help section was. \ \ She said if she told me, it would defeat the purpose. / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
