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
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
(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
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
--- 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
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
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
* 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.
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
* 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.
* 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
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
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
* 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
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
* 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.
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
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
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
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
* 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
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
* 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
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
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
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
--- 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
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.,
28 matches
Mail list logo
