Re: [Flightgear-devel] Problems with JSBSim under Win32
re: AVOID #QNAN
I changed FGAuxilary.cpp in the following -
Uhmm... what problem were you having with this, there shouldn't be any
name clashes here. (There is only one global variable in JSBSim:
debug_lvl)
None. No 'problem' as such. I was chasing down an ellusive FPU 'explosion'
I got when using JSBSim. I found that one of the calculations used 'vw',
which was already blown. In seaching for 'vw', I found the class
definition and began looking at when/where 'vw' was set ...
This 'search' yielded several hits in FGAuxiliary.cpp. Since this was
not the 'global class item vw' I renamed them by adding a 'd' so these
local
yocals would not turn up again while I researched 'vw' ... that's all.
As a general rule I try not to use names that have a 'global' scope in
local routines, like -
class foo {
intiamit;
int iam2;
// etc ...
};
void foo::calcit( void )
{
intiamit = iam2 * iam2;
// later
iamit = wnorth*( sphi*stheta*cpsi - cphi*spsi ) +
weast*( sphi*stheta*spsi + cphi*cpsi ) +
wdown*sphi*ctheta;
}
I would be left pondering did the coder mean -
iamit = iam2 * iam2;
In fact I like the MS MFC 'push' to always use something like 'm_' on
class members, thus you would have
class foo {
intm_iamit;
int m_iam2;
// etc ...
};
void foo::calcit( void )
{
intiamit = m_iam2 * m_iam2;
// later
m_iamit = wnorth*( sphi*stheta*cpsi - cphi*spsi ) +
weast*( sphi*stheta*spsi + cphi*cpsi ) +
wdown*sphi*ctheta;
}
Then there can be no confusion when 'reviewing' the code ... but this
is only 'style', and what ever works for you is ok 2 ...
I did not find out why the QNAN ... maybe I should just do a cvs update,
and try JSBSim again. As mentioned YASim works fine ... well, with my
usual 'stuttering' win98 run ( 1 fps) ...
The defensive ...
FGInitialCondition.cxx -
! if( (f3 - f1) 0.0 )
!x2 = x1-d*d0*f1/(f3-f1); // zero checked
! else
!x2 = x1-d*d0*f1/1.0;// do least damage in error cond.
should NOT be required.
Rgds,
Geoff.
PS: Yes, I agree debug_lvl is indeed 'global'. As mentioned before
I found it 'strange' that I had to add the declaration of it in
FGJSBBase.cpp. How other compiler/linkers expose -
short FGJSBBase::debug_lvl = 0;
as a global variable is quite beyond me ...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Compile error latest CVS
Bernie Bright wrote: g++ 2.95.x lacks the Standard's ios_base class. One messy work around is demonstrated in simgear/misc/zfstream.hxx. FWIW I've been working on an alternative solution using namespaces that is much cleaner. It compiles with gcc 2.95.x and 3.0.x, Intel C++ and MSVC6. That sounds great. Nearly all target platforms! Could someone with MacOS X also test it? CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: ANSI C++ fixes; Compiling with G++ 3.x
This same error occurs using the latest Cygwin on Win2000. Is that based on G++ 2.95 or G++ 3.0? gcc 2.95. - Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Compile error latest CVS
Norman Vine writes: g++ 2.95.x lacks the Standard's ios_base class. One messy work around is demonstrated in simgear/misc/zfstream.hxx. FWIW I've been working on an alternative solution using namespaces that is much cleaner. It compiles with gcc 2.95.x and 3.0.x, Intel C++ and MSVC6. I believe that this should work [snip] And so it does, at least for G++ 3.0. I've committed Norm's change to the FlightGear and JSBSim CVS repositories. Please let me know if there are any further problems compiling with G++ 2.95 (or MSVC, etc.). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Compile error latest CVS
David Megginson wrote: And so it does, at least for G++ 3.0. I've committed Norm's change to the FlightGear and JSBSim CVS repositories. Please let me know if there are any further problems compiling with G++ 2.95 (or MSVC, etc.). I have to use long flags = cout.setf(ios::fixed); instead of ios::fmtflags flags = cout.setf(ios::fixed); for Irix/MipsPro but I wouldn't be suppriced if this was MipsPro speciffic. The compiler start to get out of date because of these types of errors. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Compile error latest CVS
David Megginson writes: Norman Vine writes: g++ 2.95.x lacks the Standard's ios_base class. One messy work around is demonstrated in simgear/misc/zfstream.hxx. FWIW I've been working on an alternative solution using namespaces that is much cleaner. It compiles with gcc 2.95.x and 3.0.x, Intel C++ and MSVC6. I believe that this should work [snip] And so it does, at least for G++ 3.0. FWIW The problem here stems from IMHO poor documentation methodology of OO languages in general and C++ in particular. ie EVERY DOC I have seen for the c++ standard iostreams refers to fmtflags as a member of ios_base, it is this, but by inheritance it is also a member of ios. ie click on the ios::setf() link on this page http://www.cplusplus.com/ref/iostream/ios/ and you are taken to the reference for ios_base::setf() and not ios::setf(). This makes it all to easy to miss the fact that ios has the methods setf() and flags() and also the data member fmtflags which are inherited from ios_base but are present in ios and can be referenced as ios::XXX I would really like to find a tool that walked up the object heirarchy and created the 'full' class definiton as seen by a C++ compiler ! Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FreeGLUT
James A. Treacy writes: On Sun, Jan 06, 2002 at 10:34:46PM +, Ross Golder wrote: It seems Mesa 4.0.1 doesn't come with glut, like 3.4. Has using freeglut been discussed before? I couldn't find anything in the archives. http://freeglut.sf.net/ Besides being maintained upstream, are there any benefits to freeglut? I ask because I maintain the glut package for Debian and have been considering packaging freeglut as well. James, You might find more knowledge on this subject if you post to the plib-devel mailing list (plib.sf.net). You'll at least find Steve Baker who has definite strong opinions on this subject (as well as many other subjects.) :-) As I understand it there are two primary issues: 1. The license terms of glut allow it to be redistributed freely, but not freely modified. Thus if we find issues with the code, there is nothing we can do to distribute a fix for them (legally.) 2. Glut is event driven and requires control over the main event loop. This is usually workable until you try to integrate something else that also expects complete control over the event loop. Freeglut gives you the option to maintain your own event loop. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Compile error latest CVS
Erik Hofman writes: David Megginson wrote: And so it does, at least for G++ 3.0. I've committed Norm's change to the FlightGear and JSBSim CVS repositories. Please let me know if there are any further problems compiling with G++ 2.95 (or MSVC, etc.). I have to use long flags = cout.setf(ios::fixed); instead of ios::fmtflags flags = cout.setf(ios::fixed); Good one :-) since the standard says #define unsigned long fmtflags I wouldn't be surprised if unsigned long flags = cout.setf(ios::fixed); would work on G++ 3.0 too ! It does with 2.95 Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Time
Thales de Lima Ferreira wrote: Hello, I still can´t set the time in the Flightgear... I tried using runfgfs --start-date-lat=1984:12:23:23:00:00 and also with flightgear.exe, as Erik Hofman suggested (thanks for the help by the way) but it didn´t work, all I got was a list of the time parameters I could use, the only one that worked was to synchronize real world time and flightgear time... Any other suggestions? This looks strange to me because this option should be available for quite some time now. Could you please give some more details: Which version of FlightGear are you using? Which Operating System (and version). Did you download a binary, or compiled it your self? Regards, Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Time
I´m using the 7.8 version, I´ve downloaded the binaries, and compiled myself, neither worked. I´m also using windows 98SE and compiling with MSVC6.0. Thanks. All the best. Thales Ferreira _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Time
Erik Hofman writes: Thales de Lima Ferreira wrote: I´m using the 7.8 version, I´ve downloaded the binaries, and compiled myself, neither worked. I´m also using windows 98SE and compiling with MSVC6.0. I was thinking, maybe the runfgfs.bat file is not working correct. You could try to run fgfs directly but then you would have to add the fg-root directive: i.e. fgfs --fg-root=c:\FlightGear The runfgfs.bat file screws up passing along the '=' and perhaps other characters. One thing to try is to embed the options right in the .bat file. Another thing to try is to enclose the option in double quotes, i.e. runfgfs --fg-root=c:\FlightGear Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] LWCE Booth assignment
I just received our booth assignment for LWCE '02. Booth # 10 between the etherboot project and FSF which, I beleive, is where we were slotted last time. FWIW the .org pavillion seems to have moved to the back wall, as opposed to being in the center of things. Last years org pavillion location is now the email garden. I have a feeling there are less exhibitors this time around, which should work to our advantage as far as getting press. TTYL John ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
