[Flightgear-devel] Re: CVS: FlightGear/src/Instrumentation wxradar.cxx,1.6,1.7 wxradar.hxx,1.4,1.5
Melchior Franz writes: Update of /var/cvs/FlightGear-0.9/FlightGear/src/Instrumentation In directory baron:/tmp/cvs-serv8740 Modified Files: wxradar.cxx wxradar.hxx Log Message: make headers include headers they depend on, don't rely on the c(xx) file to do that. (This is a requirement for header precompiling.) i don't understand what you mean by precompiling but making the header file include unnecessary headers is wrong. i looked at this particular case, and it's okay to forward declare a class and include the header file in the c++ source file. you actually want to do this as it minimizes the amount of recompilation in case the base header files changes. i suspect all your changes are unnecessary (this one really looks like it) so i suggest you revert them. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: CVS: FlightGear/src/Instrumentation wxradar.cxx,1.6,1.7 wxradar.hxx,1.4,1.5
* Alex Romosan -- Monday 17 April 2006 16:15: i don't understand what you mean by precompiling http://en.wikipedia.org/wiki/Precompiled_header i looked at this particular case, and it's okay to forward declare a class and include the header file in the c++ source file. It's OK to forward declare classes that are referred to via *pointers*. But it is not OK to use class/type instances that are not known to the header, and relying on external code to make them known. How often would you say again changes plib/ssg.h? Per year? Once? 0.5 times? FYI: most of the fgfs code did it right already before my changes. Only some doesn't. so i suggest you revert them. Only if Curt or Erik ask me to. m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: CVS: FlightGear/src/Instrumentation wxradar.cxx,1.6,1.7 wxradar.hxx,1.4,1.5
Melchior FRANZ writes: It's OK to forward declare classes that are referred to via *pointers*. But it is not OK to use class/type instances that are not known to the header, and relying on external code to make them known. How often would you say again changes plib/ssg.h? Per year? Once? 0.5 times? the header itself might not change that often, but the time-stamp definitely changes every time you reinstall plib (because some other part got changed, and you recompiled it) and this will trigger needless recompilation. things are never that simple (and the header file dependency in flightgear/simgear is already messy enough as it is). if you feel like recompiling everything all the time, by all means, make as many changes as this as you want. what's the point of having fast computers if not to recompile code over and over again?! --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: CVS: FlightGear/src/Instrumentation wxradar.cxx,1.6,1.7 wxradar.hxx,1.4,1.5
* Alex Romosan -- Monday 17 April 2006 16:50: Melchior FRANZ writes: It's OK to forward declare classes that are referred to via *pointers*. But it is not OK to use class/type instances that are not known to the header, and relying on external code to make them known. Again: C(++) code depending on headers == GOOD (that's the idea behind headers) headers depending on C(++) code == BAD (that's IMHO perverted and wrong) This doesn't even have anything to do with precompiled headers. It's bad design without them, too. But I'm not keen to fight such fights, even less with one-time-contributors. If the official opinion is that FlightGear shall not support precompiled headers, then I'll keep the remaining changes local on my disk. It's not the only change by far. m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: FlightGear/src/Instrumentation wxradar.cxx,1.6,1.7 wxradar.hxx,1.4,1.5
On Monday 17 April 2006 16:50, Alex Romosan wrote: the header itself might not change that often, but the time-stamp definitely changes every time you reinstall plib To avoid changing timestamps of unchanged files you can use export INSTALL='/usr/bin/install -p' ./configure --whatever at configury time. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] gcc - precompiled headers
The good news: SimGear and FlightGear work with gcc's precompiled headers The not so good news: Some of the necessary changes are not in cvs The really bad news: Some of the necessary changes would have to be done in an associated project, and even if that were accepted, it couldn't be maintained there, and the capability soon be lost. I can't say if this compiler/linker feature is worth it at all, but the committed changes will at least hardly make compilation slower, or rather: a bit slower for some files, and a bit faster for others. Looks like this will be something to look at again when its time has come ... m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New MP servers
Robicd wrote: I tried to register yesterday and today at http://fgfs.i-net.hu/, and after submitting all informations asked the server replies me Could not register new user. as I wanted to reply the post asking for suggestions, I tried as Anonymous user, the server said to me *Anonymous* users can post new topics and replies to this forum, I type my response, and when I submit it, the server replies Could not insert forum post. Feedback: I registered without problems at all. Try later again, maybe it was just a temporary system glitch. I tried all the day long with no more succes than before :( seb --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New MP servers
This is odd, what i can do is register you and you can modify your password later on. What username would you like? (I'll ask KoverSrac to look into the issue.) Julien
[Flightgear-devel] Subsystem run-levels
I'm plotting to add support for startup GUIs in FlightGear itself, spurred on by recent issues with Mac GUI. My approach is to twiddle the order of initialisation so that at a critical point during the idle_state progression, the NewGUI subsystem is up, config options have been parsed, and the nav data has been read, but everything else is still 'off'. With the exclusion of nav-data, this point is reached very quickly, and I believe other work can improve the 10-20 seconds it takes to read the nav data.Happily enough, the current idle_state '4' almost corresponds to this; in my test code, at this point, I jump to a new, special idle_state, with the expectation of sitting there, showing some PUI dialogs driven by XML, filling in the property tree with settings for the current aircraft, airport, and so on, and then eventually resuming the idle_state progression. The only catch is, subsystems are initialised late, but I need a handful to be up before I can use the GUI dialogs; obviously the GUI subsystem itself, but also Nasal and a few others. (There are some issues with initialising nasal early, it is currently deliberately being done very late, but more on that later...)What would simplify this greatly is if subsystem registration was totally separated out from (re-)initialisation, and if sub-systems had run-level or priority associated with them. All the subsystems could be registered via add_subsystem, and then during fgInitSubsystems, the runlevel would gradually advance to the final value. This also means the dependencies between subsystems can be expressed (higher numbers depend on lower numbers), and might make things like reset more simple (lower the run-level back to some determined value, and the bring it back up again).As an additional enhancement, subsystems could be notified of all run-level changes above their threshold. This would solve the Nasal issue; starting up the interpreter (the first part of FGNasalSys::init) can be done very early (and quickly), and the subsytem would then wait for a relatively high-valued 'init' call before running scripts (the part that needs all other properties to be defined).In the even longer run, we'd actually want to associate the Nasal scripts with run-levels (/etc/rc.d, anyone?), since the frontend GUI might want a few scripts loaded, while I assume most are only relevant when actually flying. Such a change also makes postinit() unnecessary, I think - since the effect can always be achieved by having init() watch for a higher run-level.What do people think? I can have a patch for SimGear that adds support, and one for fg_init that establishes the existing behaviour, done in an hour or two.Feedback appreciated,James
Re: [Flightgear-devel] New MP servers
Julien Pierru wrote: This is odd, what i can do is register you and you can modify your password later on. What username would you like? (I'll ask KoverSrac to look into the issue.) Julien thank you for your offer: zacharov (mail: [EMAIL PROTECTED]) as a username would be great. thanks seb --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: gcc - precompiled headers
* James Turner -- Tuesday 18 April 2006 00:07: On 17 Apr 2006, at 21:31, Melchior FRANZ wrote: The really bad news: Some of the necessary changes would have to be done in an associated project, [...] What kind of changes? Not that many. It's JSBSim and it is a bit too generous with including headers. Took me a while to remove a few and replace others with forward declarations. The problem is maintenance. If the developers aren't interested, then it only takes a few weeks until someone adds stuff that breaks compilation again, without noticing. That's not maintainable that way. The biggest win for FG would probably come from pre-compiling the headers for PLIB and parts of SimGear, I guess. I didn't observe a big drop in compile time. Maybe (or hopefully) it's faster than without, but it was definitely slower than with ccache, so it doesn't justify the hassle. (Maybe it's because ccache doesn't understand *.hxx.gch files?) I'm surprised the code changes are so dramatic than you can't check them in and let people experiment They aren't dramatic. Some of them are recommendable in any case. It's just the resistance from the audience, the fear that fgfs might compile a few seconds longer if the dirty micro-optimization compile-time hacks are removed. It's hardly more than that. ccache *easily* compensates for the few extra seconds. By the way: several subdirs could be compiled without a single change: UIUC, YASim, LaRCSim, Scripting, Sounds, and a few others. Even Instrumentation could be compiled right away, with the only exception of wxradar.hxx! - MSVC has good pre-compiled header support, That's another thing why we aren't ready for precompiled headers: our autotools setup doesn't support it yet (although this would probably be easy to add). I'm using scons for SimGear and FlightGear, and here it was only one added 'tool' to get gch support. m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: simgear for Mac OS X Tiger
On Apr 6, 2006, at 2:09 AM, James Turner wrote:I'm trying to compile FlightGear 0.9.10-pre3 on my PowerBook, but the installation of simgear fails while "make" with following error messages:if g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/FlightGear/include -g -O2 -D_REENTRANT -MT visual_enviro.o -MD -MP -MF ".deps/visual_enviro.Tpo" -c -o visual_enviro.o visual_enviro.cxx; \then mv -f ".deps/visual_enviro.Tpo" ".deps/visual_enviro.Po"; else rm -f ".deps/visual_enviro.Tpo"; exit 1; fiIn file included from ../../simgear/scene/sky/bbcache.hxx:30, from ../../simgear/scene/sky/newcloud.hxx:31, from visual_enviro.cxx:36:../../simgear/screen/RenderTexture.h:343: error: 'CGLContextObj' is used as a type, but is not defined as a type.../../simgear/screen/RenderTexture.h:344: error: 'CGLPBufferObj' is used as a type, but is not defined as a type.../../simgear/screen/RenderTexture.h:346: error: 'CGLContextObj' is used as a type, but is not defined as a type.make[3]: *** [visual_enviro.o] Error 1make[2]: *** [all-recursive] Error 1make[1]: *** [all] Error 2I'm using Mac OS X.4.6 and Xcode 2.2.1. What am I doing wrong? What I need to do to finish building simgear and FlightGear on my machine? I'm a not so experienced programmer, or exactly, it's almost my first try to build a programm from source :-).Can you please help me? Ah, this is due to the render-texture code for OS-X code that was patched into SimGear; I had to fix an include to make it build, I'll send the (minor) patch for that to Erik once I get home; basically you need to pull in OpenGL/CGLTypes.h at the top of the file. The bigger problem is, the RenderTexture code doesn't work, and worse, is resetting the active GLContext to NULL when it fails, so I was getting errors from PLIB about no context being active during startup. I disabled the RenderTexture code in my local tree by adding an early return to the initialise() method.If you just want to fly, you can try the binary I posted yesterday, of course (works on PPC Tiger and Panther, but crashes under Rosetta)http://homepage.mac.com/zakalawe/.Public/flightgear-0.9.10-pre-osx.dmgRegards,James--All hail the hypno-toad! James,I just tried to build simgear from CVS and got a similar, but not identical error to the above:g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/Users/dersh/Programming/FlightGear/include -g -O2 -D_REENTRANT -c -o visual_enviro.o `test -f 'visual_enviro.cxx' || echo './'`visual_enviro.cxx../../simgear/screen/RenderTexture.h:343: error: 'CGLContextObj' does not name a type../../simgear/screen/RenderTexture.h:344: error: 'CGLPBufferObj' does not name a type../../simgear/screen/RenderTexture.h:346: error: 'CGLContextObj' does not name a typemake[2]: *** [visual_enviro.o] Error 1make[1]: *** [install-recursive] Error 1make: *** [install-recursive] Error 1Were you able to get the patch sent to Erik? Was there another change somewhere else that raised this similar error? Can you be a little more specific about your fix? Which file did you add CGLTypes.h to the top of?Thanks,--Adam
[Flightgear-devel] Re: gcc - precompiled headers
* Melchior FRANZ -- Tuesday 18 April 2006 00:51: I didn't observe a big drop in compile time. Maybe (or hopefully) it's faster than without, but it was definitely slower than with ccache, so it doesn't justify the hassle. Heh, no wonder. My setup is generating all the compiled headers, but it's not using them. Have to fix that before I can make benchmarks ... m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Fwd: Re: [Flightgear-devel] Aircraft repaint request]
On Mon, Apr 17, 2006 at 11:28:51PM -0600, Ron Jensen wrote: http://www.waterholes.com/~dennette/models/ww-ii/p-51/ http://www.mfarchive.modelstuff.co.uk/mf069/images/Daretuskegee536% 20P-51.jpg Stupid GUI driven e-mail client at my URL. Let's try it in MUTT: http://www.mfarchive.modelstuff.co.uk/mf069/images/Daretuskegee536%20P-51.jpg Ron --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
