[Flightgear-devel] Traffic Manager II
Hi All, Here's just a quick heads up regarding some future plans. I've been planning to work on a revamped traffic manager for quite some time now. Yesterday, with a big thunderstorm rolling in, I figured I had a good excuse to stay indoors and get some coding done. So what is traffic manager II? Well the main difference is that it will become a lot easier for users to develop their own traffic. Instead of going through a complicated procedure of compiling a sequence of flights into an xml file, the new version just requires a plain text file that specifies which aircraft are available and which flights are required to be operated. Traffic manager than automatically assigns flights to aircraft. In essence, the strict one-to-one coupling of Aircraft and routes is no longer there, but determined dynamically. The biggest advantages of this approach are twofold: 1) Easier User configurability, and 2) increased flexibility. At this stage, I cannot tell wether traffic manager II is going to be backward compatible with the currently existing xml files. I hope to be able to do that. I'm cross posting this message to both flightgear-devel and flightgear-users, because I know there are quite a few flightgear-users subscribers working on developing traffic plans. I will certainly take a few more weeks (maybe even a few months) before this will be production ready. However, if you are interested in the new format, feel free to drop you a note, and I'm happy to make a concept of the new format available. Many thanks go out to Gabor Toth, in this respect, for laying out the ground work for the new traffic format. Cheers, Durk - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/AI/Aircraft/KLAX-traffic - New directory
Hi Ron, On Sunday 27 July 2008 05:54, Ron Jensen wrote: Is this the right place to put this type of directory? It seems either AI/Airports/KLAX or AI/FlightPlans might be a better choice, as AI/Aircraft is already full of Aircraft directories. I would have been more strict if I hadn't had some indication that I don't expect to see a huge increase in xml based traffic in the base package anymore. See my Traffic Manager II post from earlier today in this respect. Had this not been the case, I would have agreed. Cheers, Durk - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] windows.h
(mostly for Fred, I guess) Whilst cleaning up various headers and includes, I've noticed quite a few files including windows.h, via a section like: #ifdef HAVE_WINDOWS_H # include windows.h #endif Many of these files have no obvious reason to be relying on platform specific code, and I think that the MSVC standard library is now good enough to pull in windows.h if it's required by support functions (hopefully never). I believe gl.h on Windows requires windows.h to be pulled in, but the osg/GL wrapper we're using now takes care of that. So, if someone with access to Win32 fancies doing a quick audit in FG and SG of these, feel free. My (optimistic) hope would be that they can *all* die, since virtually all of our platform code is now in osg, but I'm sure there will be a couple of exceptions. (Timing, maybe? Sockets?) In any case, it would be good to get windows.h out of all the headers, so it's at least only dragged in per compilation unit. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Antwoord bij afwezigheid
Ik ben momenteel op vakantie. Woensdag 13 augustus ben ik weer terug. -- I'm on holiday at the moment. I return home at wednesday 13 August. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Traffic Manager II
--- Durk Talsma [EMAIL PROTECTED] schrieb am So, 27.7.2008: Von: Durk Talsma [EMAIL PROTECTED] Betreff: [Flightgear-devel] Traffic Manager II An: flightgear-devel@lists.sourceforge.net, [EMAIL PROTECTED] Datum: Sonntag, 27. Juli 2008, 11:50 Hi All, Here's just a quick heads up regarding some future plans. I've been planning to work on a revamped traffic manager for quite some time now. Yesterday, with a big thunderstorm rolling in, I figured I had a good excuse to stay indoors and get some coding done. So what is traffic manager II? Well the main difference is that it will become a lot easier for users to develop their own traffic. Instead of going through a complicated procedure of compiling a sequence of flights into an xml file, the new version just requires a plain text file that specifies which aircraft are available and which flights are required to be operated. Traffic manager than automatically assigns flights to aircraft. In essence, the strict one-to-one coupling of Aircraft and routes is no longer there, but determined dynamically. The biggest advantages of this approach are twofold: 1) Easier User configurability, and 2) increased flexibility. At this stage, I cannot tell wether traffic manager II is going to be backward compatible with the currently existing xml files. I hope to be able to do that. I'm cross posting this message to both flightgear-devel and flightgear-users, because I know there are quite a few flightgear-users subscribers working on developing traffic plans. I will certainly take a few more weeks (maybe even a few months) before this will be production ready. However, if you are interested in the new format, feel free to drop you a note, and I'm happy to make a concept of the new format available. Many thanks go out to Gabor Toth, in this respect, for laying out the ground work for the new traffic format. Cheers, Durk Sounds good, but there is one question left for me cause I amybe did not understnad it right: Will it be still possible to create AI-Traffic after real timetables? Regards HHS __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Traffic Manager II
Hi Heiko, On Sunday 27 July 2008 13:24, Heiko Schulz wrote: Sounds good, but there is one question left for me cause I amybe did not understnad it right: Will it be still possible to create AI-Traffic after real timetables? Yes absolutely. Even more so than before, probably because of the added flexiblity in setting up irregularly repeating schedules (i.e. flights that only occur on mondays and thursdays, and not on other week days). Cheers, Durk - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
On Sun, Jul 27, 2008 at 5:03 AM, James Turner wrote:
(mostly for Fred, I guess)
Hi James,
I'll defer to Fred's expertise here, but I'm pretty sure that #include
windows.h does several magic things that are required for a clean compile
on the windows platform.
It wouldn't surprise me if the standard hello world example for windows is:
#include windows.h
main() {
printf(Hello world\n);
}
I'm pretty sure this can't go.
Curt.
Whilst cleaning up various headers and includes, I've noticed quite a
few files including windows.h, via a section like:
#ifdef HAVE_WINDOWS_H
# include windows.h
#endif
Many of these files have no obvious reason to be relying on platform
specific code, and I think that the MSVC standard library is now good
enough to pull in windows.h if it's required by support functions
(hopefully never). I believe gl.h on Windows requires windows.h to be
pulled in, but the osg/GL wrapper we're using now takes care of that.
So, if someone with access to Win32 fancies doing a quick audit in FG
and SG of these, feel free. My (optimistic) hope would be that they
can *all* die, since virtually all of our platform code is now in osg,
but I'm sure there will be a couple of exceptions. (Timing, maybe?
Sockets?)
In any case, it would be good to get windows.h out of all the headers,
so it's at least only dragged in per compilation unit.
Regards,
James
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Curtis Olson: http://baron.flightgear.org/~curt/
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
* Melchior FRANZ -- Sunday 27 July 2008: I don't see why the noisy include lines aren't then in config.h, rather than in every single code file. Ah, I remember, config.h is also loaded just conditionally. But that's really the root of the annoyance. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
Melchior FRANZ a écrit : * Curtis Olson -- Sunday 27 July 2008: It wouldn't surprise me if the standard hello world example for windows is: [...] Wouldn't surprise me either. But I don't see why the noisy include lines aren't then in config.h, rather than in every single code file. My next commit will please you. Most are gone. ;-) The real problem was unneeded inclusion of GLU.h and GL.h that required windows.h -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
* Curtis Olson -- Sunday 27 July 2008: It wouldn't surprise me if the standard hello world example for windows is: [...] Wouldn't surprise me either. But I don't see why the noisy include lines aren't then in config.h, rather than in every single code file. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
* Frederic Bouvier -- Sunday 27 July 2008: My next commit will please you. Most are gone. ;-) The real problem was unneeded inclusion of GLU.h and GL.h that required windows.h Sounds good. :-) I've always envisioned a system where every simgear code file includes simgear.hxx and every flightgear file flightgear.hxx. And these two headers would conditionally load config.h, compiler.h or windows.h. The conditional header loading just shouldn't be spread all over the code base. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
Melchior FRANZ a écrit : * Frederic Bouvier -- Sunday 27 July 2008: My next commit will please you. Most are gone. ;-) The real problem was unneeded inclusion of GLU.h and GL.h that required windows.h Sounds good. :-) I've always envisioned a system where every simgear code file includes simgear.hxx and every flightgear file flightgear.hxx. And these two headers would conditionally load config.h, compiler.h or windows.h. The conditional header loading just shouldn't be spread all over the code base. That would mean even longer compilation time. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
Oh, and while we are at it, this silliness should also disappear: #ifndef __cplusplus # error This library requires C++ #endif If anyone needs to be reminded that foo.hxx is a C++ file then there's no hope. It's just visual noise. I mean, foo.hxx isn't an image or a sound file either, and we don't add a warning for that. ;-) m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
* Frederic Bouvier -- Sunday 27 July 2008: That would mean even longer compilation time. Yes, a few milliseconds. Come on! The file is loaded into the file cache and then takes almost *no* time for loading, and not more time for parsing as if it's directly in the code file. Following that argument we shouldn't use *any* headers and just replace all preprocessor instructions with the final code. :-} m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
Melchior FRANZ a écrit : * Frederic Bouvier -- Sunday 27 July 2008: That would mean even longer compilation time. Yes, a few milliseconds. Come on! The file is loaded into the file cache and then takes almost *no* time for loading, and not more time for parsing as if it's directly in the code file. Following that argument we shouldn't use *any* headers and just replace all preprocessor instructions with the final code. :-} you have no idea about the cruft windows.h is dragging. It's more or less like if you included *every* files located in /usr/include -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
* Frederic Bouvier -- Sunday 27 July 2008: you have no idea about the cruft windows.h is dragging. True. But I had the impression that you were adding the #if ... #include windows.h #endif to every single file, anyway. :-) m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
Melchior FRANZ a écrit : * Frederic Bouvier -- Sunday 27 July 2008: you have no idea about the cruft windows.h is dragging. True. But I had the impression that you were adding the #if ... #include windows.h #endif to every single file, anyway. :-) You are misinformed. I was adding config.h. Look at the CVS log for the number I removed. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
On 27 Jul 2008, at 16:41, Frederic Bouvier wrote: you have no idea about the cruft windows.h is dragging. True. But I had the impression that you were adding the #if ... #include windows.h #endif to every single file, anyway. :-) You are misinformed. I was adding config.h. Look at the CVS log for the number I removed. A few observations: - there are some *header* files which drag in config.h, which is a major no-no. I'll get this one fixed - header inclusion is a very very real compilation time issue, especially for gcc since they're not shared (MSVC can do magic caching I believe). As I have time / boredom, I'm going to start reviewing header / source files in turn to do minimisation on their include trees. This will basically mean removing all the includes, seeing what breaks, and gradually adding them back in, but it's a bit more scientific than that. The golden rule is headers should be independent (pull in their dependencies) but minimal (not pull in anything they don't directly need). I'm also going to see if there's places where forward declarations in headers can replace actual includes. - config.h is optional, but compiler.h is not, and still exists. In the near future, the only thing it will do is silence some MSVC and MipsPro warnings, but it's still there, and can be hooked for other things. Generic includes of *heavy* headers is definitely not the way to go. And a question: - The sources erratically alternate between using the C-library wrappers and not, i.e include stdio.h vs include cstdio. Is this worth fixing, aside from neat-ness? AFAIK on every system cstdio is just a straight wrapper around stdio.h, so it's a not very useful and extremely noisy (in CVS) change to fix every string.h, stdio.h, stdlib.h and so on. Opinions on doing this? Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
Hi James, On Sunday 27 July 2008 18:06, James Turner wrote: - header inclusion is a very very real compilation time issue, especially for gcc since they're not shared (MSVC can do magic caching I believe). As I have time / boredom, I'm going to start reviewing header / source files in turn to do minimisation on their include trees. This will basically mean removing all the includes, seeing what breaks, and gradually adding them back in, but it's a bit more scientific than that. The golden rule is headers should be independent (pull in their dependencies) but minimal (not pull in anything they don't directly need). I'm also going to see if there's places where forward declarations in headers can replace actual includes. You might be interested in some work done by Thomas Foerster. Thomas has done a fairly detailed analysis of the current interdependencies in FlightGear's include files. IIRC, Thomas has a patched version of FlightGear that already removes most of the interdependencies. These updates are not publicly available yet. I had agreed to review his changes and commit them, as part of one of my current FlightGear priorities, but hadn't gotten around to do so yet. Cheers, Durk - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Header restructuring (was: windows.h)
I've now committed two patches provided by James Turner that does a lot of header and declaration cleanups; * SG_USING_STD is now replaced by: using std:: * SG_GL_H is replaced by osg/GL * SG_GLU_H is replaces by osg/GLU * All STL_* includes are replaced by their proper names As far as I can tell I didn't break anything in the process but Frederic just beat me with the windows.h commit :) Anyway, despite the fact that no user will ever notice any difference I highly appreciate the time James put into it since this *is* important every once in a while. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Header restructuring (was: windows.h)
* Erik Hofman -- Sunday 27 July 2008: I've now committed two patches provided by James Turner that does a lot of header and declaration cleanups; Excellent. As far as I can tell I didn't break anything in the process [...] Nope. Compiles and runs here. Just for the record: the old HUD will also be removed very soon, probably within the next two weeks. I only have to check what needs to get ported first. (The f16 is one such candidate. :-) m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Header restructuring
Melchior FRANZ wrote: Just for the record: the old HUD will also be removed very soon, probably within the next two weeks. I only have to check what needs to get ported first. (The f16 is one such candidate. :-) Yeah I know it uses the old HUD, but I didn't even know there was a new one.. :) If there is a proper replacement somewhere then it's fine by my to just point to the new HUD in the configuration file and remove the old data. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Header restructuring
* Erik Hofman -- Sunday 27 July 2008: Yeah I know it uses the old HUD, but I didn't even know there was a new one.. :) Oh, you did. You just forgot about it. The new one isn't *that* new, anyway. It's just a heavily cleaned up, slightly extended and much more flexible version of the old. It was work in progress when Mathias announced his plib-osg switch. That's why I stopped writing on it and never finished it. But it's fully usable and much better than the old one already. (You can see it in action when you use the Shift-i-key.) If there is a proper replacement somewhere then it's fine by my to just point to the new HUD in the configuration file and remove the old data. The replacement exists already and kind-of works here. But one of Curt's commits broke it (IIRC :-). Need to fix that first. I'll commit the change then once the result is equivalent. m. PS: sorry for not removing the (was: ...) parts in subjects. I *always* forget that. I even hacked my client to warn me in big red letters. No chance. :-) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
On 27 Jul 2008, at 17:24, Durk Talsma wrote: You might be interested in some work done by Thomas Foerster. Thomas has done a fairly detailed analysis of the current interdependencies in FlightGear's include files. IIRC, Thomas has a patched version of FlightGear that already removes most of the interdependencies. These updates are not publicly available yet. I had agreed to review his changes and commit them, as part of one of my current FlightGear priorities, but hadn't gotten around to do so yet. I'd be happy to review them, can't do the committing part. Incidentally, a minor rant - even in the past week, I've seen the 'XXX is being worked on, person YYY has lots of changes which they haven't committed for arbitrary (justifiable) reason ZZZ'. I'd like to get involved in hacking on some actual user-visible changes (see a future email for that), but right now I'm struggling to get a handle on, for example, which bits of the OSG code are being worked on and which aren't. Eg, I'd like to pitch in and remove lots of cruft in SimGear/scene (and screen) but for all I know someone already has done that work in their local tree. In a way I'm happy to go ahead and fix stuff - if people insist on keeping changes out of the tree, it's their problem when work gets done twice, but it's still frustrating and wasteful. Hmmm, I think I also have an upcoming email about (the difficulty of) getting a handle on who's doing what (i.e project tracking), but it's one of those ones I want to word quite carefully :) Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
James Turner wrote: On 27 Jul 2008, at 16:41, Frederic Bouvier wrote: you have no idea about the cruft windows.h is dragging. True. But I had the impression that you were adding the #if ... #include windows.h #endif to every single file, anyway. :-) You are misinformed. I was adding config.h. Look at the CVS log for the number I removed. A few observations: - there are some *header* files which drag in config.h, which is a major no-no. I'll get this one fixed - header inclusion is a very very real compilation time issue, especially for gcc since they're not shared (MSVC can do magic caching I believe). As I have time / boredom, I'm going to start reviewing header / source files in turn to do minimisation on their include trees. This will basically mean removing all the includes, seeing what breaks, and gradually adding them back in, but it's a bit more scientific than that. The golden rule is headers should be independent (pull in their dependencies) but minimal (not pull in anything they don't directly need). I'm also going to see if there's places where forward declarations in headers can replace actual includes. If you're doing that work, I'd like you to follow a *really* minimalist stance i.e., if a header file only contains pointers or references to another class or includes them as arguments in uninstantiated templates (e.g., osg::ref_ptrfoo), then that classe's include file should not be sucked in; a local class declaration should be made instead. This will generate more work for you, but is really the way to go in terms of reducing compiler dependencies. - config.h is optional, but compiler.h is not, and still exists. In the near future, the only thing it will do is silence some MSVC and MipsPro warnings, but it's still there, and can be hooked for other things. Generic includes of *heavy* headers is definitely not the way to go. And a question: - The sources erratically alternate between using the C-library wrappers and not, i.e include stdio.h vs include cstdio. Is this worth fixing, aside from neat-ness? AFAIK on every system cstdio is just a straight wrapper around stdio.h, so it's a not very useful and extremely noisy (in CVS) change to fix every string.h, stdio.h, stdlib.h and so on. Opinions on doing this In C++ code they should be cstring and friends in order to ensure that the functions are all declared in the std namespace. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
On 27 Jul 2008, at 21:02, Tim Moore wrote:
If you're doing that work, I'd like you to follow a *really*
minimalist stance
i.e., if a header file only contains pointers or references to
another class or
includes them as arguments in uninstantiated templates (e.g.,
osg::ref_ptrfoo), then that classe's include file should not be
sucked in; a
local class declaration should be made instead.
This will generate more work for you, but is really the way to go in
terms of
reducing compiler dependencies.
For pointers, a forward declaration works - for template, auto_ptr and
osg::ref_ptr, I'm not totally clear what you mean. With auto_ptr, the
following can cause problems with virtual destructors not being called
on older (MSVC6, I think) versions of visual studio:
[the following is from memory of several wasted days a couple of years
ago, stepping through the generated assembly of MSVC6. I think I have
the particular case right]
class foo;
class bar
{
// no explicit dtor!
auto_ptrfoo mFoo;
}
class wibble : public foo
{
virtual ~wibble()
{
// highly important stuff
}
}
{
bar a;
a.mFoo.reset(new wibble);
// a goes out out scope, its compiler-generated dtor gets run,
destroying mFoo
}
// error, wibble's dtor was not run
If we're requiring a never MSVC than that, I believe we're fine. And
perhaps you meant something else entirely?
In C++ code they should be cstring and friends in order to ensure
that the
functions are all declared in the std namespace.
Okay, when I'm bored I'll do the monster patches to fix that.
James
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] new Cockpit View Options dialog
--- On Sun, 27/7/08, Ron Jensen wrote: http://cvs.flightgear.org/viewvc/data/gui/menubar.xml?view=loghideattic=1 Log of /data/gui/menubar.xml Revision 1.80 - Wed Jun 11 21:20:43 2008 UTC (6 weeks, 3 days ago) by stuart Branch: MAIN Changes since 1.79: +2 -15 lines Collate Dynamic Cockpit view toggle with blackout and G-compression toggles into a new Cockpit View Options dialog. I can't find the cockpit view dialog box anywhere... That'll be because I forgot to commit the changes to the gui/dialogs/ directory. I've now committed them. Apologies for the inconvenience. -Stuart __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
James Turner wrote:
On 27 Jul 2008, at 21:02, Tim Moore wrote:
If you're doing that work, I'd like you to follow a *really*
minimalist stance
i.e., if a header file only contains pointers or references to
another class or
includes them as arguments in uninstantiated templates (e.g.,
osg::ref_ptrfoo), then that classe's include file should not be
sucked in; a
local class declaration should be made instead.
This will generate more work for you, but is really the way to go in
terms of
reducing compiler dependencies.
For pointers, a forward declaration works - for template, auto_ptr and
osg::ref_ptr, I'm not totally clear what you mean. With auto_ptr, the
The header file that defines the template should probably be included, although
a template declaration should suffice. But the argument to the template need
only be forward declared.
following can cause problems with virtual destructors not being called
on older (MSVC6, I think) versions of visual studio:
[the following is from memory of several wasted days a couple of years
ago, stepping through the generated assembly of MSVC6. I think I have
the particular case right]
class foo;
class bar
{
// no explicit dtor!
auto_ptrfoo mFoo;
}
class wibble : public foo
{
virtual ~wibble()
{
// highly important stuff
}
}
{
bar a;
a.mFoo.reset(new wibble);
// a goes out out scope, its compiler-generated dtor gets run,
destroying mFoo
}
// error, wibble's dtor was not run
I'm not sure what's going on in your example, as foo needs to be defined
somewhere in order for wibble to inherit from it. Otherwise there's serious bug
there.
If we're requiring a never MSVC than that, I believe we're fine. And
perhaps you meant something else entirely?
I'm comfortable saying that we need a more recent compiler than MSVC 6.
Tim
In C++ code they should be cstring and friends in order to ensure
that the
functions are all declared in the std namespace.
Okay, when I'm bored I'll do the monster patches to fix that.
James
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
