[Flightgear-devel] Header cleanups (was Re: windows.h)
On 28 Jul 2008, at 02:39, Tim Moore wrote: 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. Sorry, I probably reduced it down too much for brevity. Essentially it says 'if you forward declare a base class, when using it in an auto_ptr, then MSVC might not run a derived class' virtual dtor' - the fix was to include the header file for the base class, so MSVC 'saw' the explicit virtual dtor on the base, and generated a real destructor call. If you're happy that everyone is using a modern MSVC, fine. Also I suspect osg:::ref_ptr doesn't have this issue, because the base class (osg::Referenced) is visible to the osg::ref_ptr template. As a test, I tried (last night) doing this reduction on Aircraft/ aircraft.hxx and Aircraft/controls.hxx. The resulting patch is quite interesting - firstly both header files went from including others to pulling in either no 'real' headers (in the case of aircraft) or one (SGSubsystemMgr, for the base class) in the case of controls.hxx. The interest comes in what I had to 'fix' to then build - explicitly including controls.hxx or FDM/flight.hxx since aircraft.hxx didn't drag it in, fine. But I had to add fg_init.hxx includes to a couple of files, iostream to some others, and simgear/structure/ exception.hxx to another. So, this is probably something I'll pursue, at a background level. Picking one header, cleaning it out, and fixing the resulting breakage is a pretty manageable chunk of work, but there's a few to do. As I go I'll remove any #ifndef cplusplus nonsense and fix up C standard library includes. I'd like to collect a list of known beneficial (and worthwhile) improvements, so far it's: - ensure source files include config.h - ensure header files don't include config.h - remove pointless cplusplus guards - replace C-standard library includes with C++ wrappers - replace includes with forward class declarations where possible (in headers) - remove 'using std::foo' (or indeed an use of 'using') in header files - suggestions? - objections? I'll stay away from the FDM source, since my feeling is they're either external (JSBsim, UIUC) or more holistic chunks (yasim) than other parts of the code. 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] [Flightgear-users] Traffic Manager II
Durk Talsma wrote: 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. Hi Durk, My biggest problem with FlightGear's AI traffic is not the complexity of the XML files, nor the need to assign individual aircraft to flights (although anything that reduces that complexity is good). Instead, the biggest issue that I can see is that there is no way for FlightGear users to share their flight patterns with each other. For example, my local airport is Melbourne's Tullamarine (YMML), and I can create AI flights from Tullamarine to various Australian and international destinations. There are other FlightGear users modelling flights arriving at their local airports, some of which will correspond to the flights that I have modelled leaving from Tullamarine. There is no way for those users to access the flights that I have created. This means that each user creates their own AI traffic XML database, without the ability to share their efforts with other users. One solution to this problem is to create a shared database of every (well, every /regularly scheduled/) flight everywhere in the world. This idea is similar to FlightGear's world scenery database. That project claims to aim for world domination, so why not have the same aim for the AI traffic database? Of course, problems with this idea are that 1) maintaining the database is a huge job, 2) distributing it will be a large download, and 3) I don't want my CPU burning cycles to simulate traffic on the other side of the world. Another solution is similar to this, but to download only those flights for a specific airport -- or maybe for a specific region. A third idea is to download flights only for a set of airports (for example, only those airports that I frequent). Of course, what I really want is to fly from anywhere to anywhere, and to see all of the corresponding air traffic along the way. Updated automatically, and in real-time. Could you add that to your to-do list, please? :-) Regards, Greg Hawkes - 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] Project tracking
(here's a can of worms, please forgive any erroneous assumptions I'm making) As someone new coming to FG, it's pretty tricky to get a handle on what's going on, what's being worked on, what needs fixed and so on. Of course this is an issue for all software projects, and there's different solutions depending on the nature of the team, how many active contributors exist and so on. FG seems to have a few potential tracking 'points' - the Developer Wiki, the SourceForge tracker / bug system, some (mandated) files in CVS (ToDos) and the usual source code 'FIXME' annotations (which something like Doxygen can extract, if formatted suitably). Notably, there's a few questions for someone looking to get involved and some ancillary nice ones: - known broken things in current CVS - current tasks required for a release based upon OSG (or in general, the next planned release) - things that can be improved / fixed / cleaned up using OSG, but can wait (for whatever reason) - things that are being actively worked upon [the nice to have ones] - things that the aircraft / scenery modelling community would like to have in the near / medium / long term - long-standing bugs (and maybe why they're long-standing!) - potential quick tasks / re-factorings which could be undertaken by a new coder to the project - larger scale refactoring tasks From reading the code, the list, and watching CVS commits, plus the odd naiive email, it's possible to get partial answers to all of the above, but they are incomplete answers at best. A few of the questions, BTW, I'd like an actual concrete answer to (especially the 'tasks blocking an OSG release' one) but the main question is about visibility, i.e if there's a place any of the above is recorded by a working consensus (eg, 60%) of developers. Obviously I have my own preferred solution to the above list (use a tracking system like Bugzilla, Trac or the SF tracker) but I'm heavily biased by familiarity with such systems, and using them in other projects. I'm aware that they might not work for FG (no one is using the SF tracker, possibly because it's a bit of dog), and they definitely don't work unless enough people use them. Equally it's pointless (and harmful) in open-source coding to be dogmatic about work methodologies (which is not the same as not having any, either) S, comments on the above? Have I missed other sources of this sort of information? Am I overstating the need for it, or value of it, in a project such as FG? Are there incremental or experimental improvements to tracking the project that people would like to suggest? I'll say right now that I am pretty sceptical of the 'keep a wiki page up to date' approach to project tracking, though any system is only as good as the time people put into it. ToDo / BUGS files in CVS can work, in my experience. I'd be happy to setup a Bugzilla (eurgh) (or any sane alternative) on my DreamHost, as a slightly more usable alternative to the SF tracker, but if it's purely to indulge my masochistic tendencies, I'll stick with my current approach - many (virtual) yellow post-it notes with scrawl such as 'PROPS_STANDALONE can die' and 'why isn't magvar updated by the SGSubsystemMgr?'. 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
On Sunday 27 July 2008 21:24, James Turner wrote: 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. Yes, it seems like a lot the old school developers have gone into hibernation. I know first hand that a number of previously active developers are reluctant to contribute, due to a disproportionate amount of unconstructive negative criticism bestowed upon them by a small number of people on this list. Unfortunately, a significant proportion of well intended new contributers has undergone the same fate. Maybe this is a good opportunity to mention that I'm really pleased to see a number of familiar names frequently reappear on the list (you, Erik, Fred). I hope the rest of the old schoolers will follow. I also hope that this will be the return to a more open discussion of key development issues and the development of a new vision for the future of FlightGear. I also hope that this might be the start of a return to the nice friendly, cooperative and friendly place that this list once was. 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-users] Traffic Manager II
Greg Hawkes wrote: One solution to this problem is to create a shared database of every (well, every /regularly scheduled/) flight everywhere in the world. This idea is similar to FlightGear's world scenery database. That project claims to aim for world domination, so why not have the same aim for the AI traffic database? Of course, problems with this idea are that 1) maintaining the database is a huge job, [...] I certainly don't want to cross Durk's plans. Nevertheless, given the case that Durk _does_ come to the conclusion, that having such a shared database of AI flight plans is a solution, then I think we should manage to co-locate such a DB at the given infrastructure and share the workload of maintenance among the involved people Your name is noted ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - 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-users] Traffic Manager II
Martin Spott wrote: Greg Hawkes wrote: One solution to this problem is to create a shared database of every (well, every /regularly scheduled/) flight everywhere in the world. This idea is similar to FlightGear's world scenery database. That project claims to aim for world domination, so why not have the same aim for the AI traffic database? Of course, problems with this idea are that 1) maintaining the database is a huge job, [...] I certainly don't want to cross Durk's plans. Nevertheless, given the case that Durk _does_ come to the conclusion, that having such a shared database of AI flight plans is a solution, then I think we should manage to co-locate such a DB at the given infrastructure and share the workload of maintenance among the involved people Your name is noted ;-) I'd started work on a db based on the current traffic manager requirements, and it was all getting rather complex. The changes you've mentioned would appear to simplify the database requirements somewhat, so I'd be happy to add something onto the scenery db system to support it. I doubt I have the time to maintain it though, so if someone wants to volunteer to keep an eye on things and prod me when changes to the db structure or front end are required then it'll make best use of the time I have available. Jon - 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
