[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/threads SGThread.hxx, 1.4,
Erik Hofman wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/threads In directory baron:/tmp/cvs-serv22758 Modified Files: SGThread.hxx Log Message: Back out the shared mutex code [...] This is great - because it works for me :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Simgear-cvslogs]
Erik Hofman wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/model In directory baron:/tmp/cvs-serv31442 Modified Files: shadanim.cxx Log Message: Harald JOHNSEN: I have corrected a few bugs with the owner draw gauge, weather radar code and heat-haze effect. This is very nice because it compiles right out of the box on Solaris. Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/screen RenderTexture.cpp, 1.9, 1.10
Hi, On Samstag 10 September 2005 18:14, Ampere K. Hardraade wrote: Unfortunately, 3D clouds is still not working over here. I am still getting the RenderTexture Error: Couldn't find a suitable pixel format message everytime I start FlightGear. I am using ATI Radeon 9200 SE PCI version with the opensource driver from XFree. I see the same with my radeon mobile (radeon, not r200 driver). Well, I *guess* that the pbuffers are not completely supported by the r200 driver. In the early days I had these strange glx protocol errors resulting in an abort. I guess that they were originated by the sgixpbuffer extension. Now the glx 1.3's pbuffers are prefered if the client libraries contain the apprioriate symbols, but this one seems not to be supported. It seems that this way the abort is gone. But it still does not provide a valid pbuffer ... Since I do no longer have r200 hardware available, I can no longer verify that. *sigh* I would prefere everything open sourced over everything closed, but in this case, try the ati binary driver ... This one should do ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/screen RenderTexture.cpp, 1.9, 1.10
On September 11, 2005 12:19 pm, Mathias Fröhlich wrote: I would prefere everything open sourced over everything closed, but in this case, try the ati binary driver ... This one should do ... That's not an option for me. ATI's binary drivers don't support PCI card, and my graphic card is a PCI card. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/screen RenderTexture.cpp, 1.9, 1.10
On Sonntag 11 September 2005 19:07, Ampere K. Hardraade wrote: On September 11, 2005 12:19 pm, Mathias Fröhlich wrote: I would prefere everything open sourced over everything closed, but in this case, try the ati binary driver ... This one should do ... That's not an option for me. ATI's binary drivers don't support PCI card, and my graphic card is a PCI card. Sorry ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/screen RenderTexture.cpp, 1.9, 1.10
On September 6, 2005 02:33 pm, Mathias Fröhlich wrote: Yay! This brought back 3D-clouds which I've been missing for a long time (using XFree86 4.3 + ATI's proprietary driver for Mobility Radeon 9600) :-) Good to hear ... Thanks Mathias Unfortunately, 3D clouds is still not working over here. I am still getting the RenderTexture Error: Couldn't find a suitable pixel format message everytime I start FlightGear. I am using ATI Radeon 9200 SE PCI version with the opensource driver from XFree. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/screen RenderTexture.cpp, 1.9,1.10
Hi, Erik Hofman schrieb: Update of /var/cvs/SimGear-0.3/SimGear/simgear/screen In directory baron:/tmp/cvs-serv2961 Modified Files: RenderTexture.cpp extensions.cxx Log Message: Mathias Fröhlich: [SNIP] Then the render texture again ... glxQueryVersion turns out to return the minimum of the client libraries glx version and the servers glx version. *All* Xorg servers return 1.2 here. So we never get the glxPBuffer functions which are the only ones working with ati's drivers ... Reverted back to checking the required functions and just use them if they are there. Still prefering the glx standard variants since they work on ati's drivers ... Yay! This brought back 3D-clouds which I've been missing for a long time (using XFree86 4.3 + ATI's proprietary driver for Mobility Radeon 9600) :-) Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/screen RenderTexture.cpp, 1.9, 1.10
On Montag 05 September 2005 23:29, Ralf Gerlich wrote: Then the render texture again ... glxQueryVersion turns out to return the minimum of the client libraries glx version and the servers glx version. *All* Xorg servers return 1.2 here. So we never get the glxPBuffer functions which are the only ones working with ati's drivers ... Reverted back to checking the required functions and just use them if they are there. Still prefering the glx standard variants since they work on ati's drivers ... Yay! This brought back 3D-clouds which I've been missing for a long time (using XFree86 4.3 + ATI's proprietary driver for Mobility Radeon 9600) :-) Good to hear ... Thanks Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/scene/sky Makefile.am, 1.9,
Erik Hofman wrote:
Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/sky
In directory baron:/tmp/cvs-serv10162/scene/sky
Modified Files:
Makefile.am cloud.cxx cloud.hxx
Added Files:
bbcache.cxx bbcache.hxx cloudfield.cxx cloudfield.hxx
newcloud.cxx newcloud.hxx
Log Message:
Harald Johnson:
- new and updated sources for the new volumetric clouds
[...]
Any objections against the following patch ? 'sqrtf' doesn't exist on
Solaris:
--- SimGear/simgear/scene/sky/newcloud.cxx~ 2005-05-05 16:18:14.319996000
+0200
+++ SimGear/simgear/scene/sky/newcloud.cxx 2005-05-05 16:18:13.347644050
+0200
@@ -113,7 +113,7 @@
// cp is normalized (len==1)
static void CartToPolar3d(sgVec3 cp, sgVec3 polar) {
polar[0] = atan2(cp[1], cp[0]);
-polar[1] = SG_PI / 2.0f - atan2(sqrtf (cp[0] * cp[0] + cp[1] * cp[1]),
cp[2]);
+polar[1] = SG_PI / 2.0f - atan2(sqrt (cp[0] * cp[0] + cp[1] * cp[1]),
cp[2]);
polar[2] = 1.0f;
}
Martin
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/scene/sky Makefile.am, 1.9,
Martin Spott wrote:
Any objections against the following patch ? 'sqrtf' doesn't exist on
Solaris:
This should not cause any problems.
Erik
--- SimGear/simgear/scene/sky/newcloud.cxx~ 2005-05-05 16:18:14.319996000
+0200
+++ SimGear/simgear/scene/sky/newcloud.cxx 2005-05-05 16:18:13.347644050
+0200
@@ -113,7 +113,7 @@
// cp is normalized (len==1)
static void CartToPolar3d(sgVec3 cp, sgVec3 polar) {
polar[0] = atan2(cp[1], cp[0]);
-polar[1] = SG_PI / 2.0f - atan2(sqrtf (cp[0] * cp[0] + cp[1] * cp[1]),
cp[2]);
+polar[1] = SG_PI / 2.0f - atan2(sqrt (cp[0] * cp[0] + cp[1] * cp[1]),
cp[2]);
polar[2] = 1.0f;
}
Martin
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/screen texture.cxx, 1.24,
Hello Erik, Erik Hofman wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/screen In directory baron:/tmp/cvs-serv13251 Modified Files: texture.cxx Log Message: Use the double precission pow() function to get Solaris compiling. Thanks for the quick fix ! Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/screen texture.cxx, 1.24,
Martin Spott wrote: Hello Erik, Erik Hofman wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/screen In directory baron:/tmp/cvs-serv13251 Modified Files: texture.cxx Log Message: Use the double precission pow() function to get Solaris compiling. Thanks for the quick fix ! You're welcome. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/scene/sky/clouds3d
Erik Hofman wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/sky/clouds3d In directory baron:/tmp/cvs-serv18531 Modified Files: glut_shapes.c Log Message: Solaris fix. Very attentive - thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Simgear-cvslogs] Simgear cannot find OpenAL (on FreeBSD 5.3)
[EMAIL PROTECTED] wrote: I have a problem installing the newest (0.3.8-pre1) simgear sources on my FreeBSD 5.3 system. ./configure cannot find the openal libs, but the openal freebsd package (version 20040816) is installed. The libs are in /usr/local/lib. Last time I checked (23rd December) everything worked fine wirh current CVS - I don't have any idea if something relevant changed in the meantime. I typically use the OpenAL port and plib (plus the patches from the port), SimGear and FlightGear from CVS. I use this small script in order to configure the sources: ftp://ftp.uni-duisburg.de/FlightGear/configure and it works fine for me, Martin. P.S.: cvslogs typically is not the name of a mailing list for individual postings. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear configure.ac, 1.75, 1.76
Erik Hofman wrote: Update of /var/cvs/SimGear-0.3/SimGear In directory baron:/tmp/cvs-serv12391 Modified Files: configure.ac Log Message: This was too quick, now pthreads isn't detected on IRIX (and other platforms?) anymore. This needs some more thought. Index: configure.ac === RCS file: /var/cvs/SimGear-0.3/SimGear/configure.ac,v retrieving revision 1.75 retrieving revision 1.76 diff -C2 -r1.75 -r1.76 *** configure.ac8 Dec 2004 15:00:45 - 1.75 --- configure.ac8 Dec 2004 15:12:11 - 1.76 *** *** 166,169 --- 166,170 dnl Thread related checks AC_CHECK_HEADER(pthread.h) + AC_CHECK_LIB(pthread, pthread_exit) AC_SEARCH_LIBS(pthread_exit, pthread) You aint modify the 'thread_LIBS' section but instead simply add the single AC_SEARCH_LIBS(pthread_exit, pthread) line to the base_LIBS section. In your first patch you simply disabled the pthread test. My intention was to resolve missing symbols in the openal test. The patch I suggested works perfectly on my SGI at home, Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Simgear-cvslogs]
Hello Curt,
could you please revert this change and remove the whole FreeBSD
clause - it just makes life harder on the cuurrent FreeBSD RELEASE - or
change it. See below.
Curtis L. Olson wrote:
Update of /var/cvs/SimGear-0.3/source/simgear/sound
In directory baron:/tmp/cvs-serv27687/sound
Modified Files:
soundmgr_openal.cxx
Log Message:
I don't understand why FreeBSD doesn't see isnan() after including math.h
but it doesn't. Trying the apple approach to fixing isnan results in an
infinite loop (making me wonder what happens on OSX?) This is an alternative
approach to checking isnan() on freebsd ...
Index: soundmgr_openal.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/soundmgr_openal.cxx,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -r1.7 -r1.8
*** soundmgr_openal.cxx 19 Nov 2004 21:44:17 - 1.7
--- soundmgr_openal.cxx 21 Nov 2004 03:13:54 - 1.8
[...]
***
*** 47,50
--- 47,54
#endif
+ #if defined (__FreeBSD__)
+ inline int isnan(double r) { return !(r 0 || r 0); }
+ #endif
+
#include STL_IOSTREAM
An alternative to keep compatibility with older FreeBSD releases might
be to place such a clause:
#if defined (__FreeBSD__)
extern C {
#if __FreeBSD_version 50
inline int isnan(double r) { return !(r = 0 || r = 0); }
#endif
}
#endif
Thanks alot,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs]
Hi Martin,
Ok, this sounds reasonable. I assume this means that the isnan()
problems are fixed in newer versions of FreeBSD?
Thanks,
Curt.
Martin Spott wrote:
Hello Curt,
could you please revert this change and remove the whole FreeBSD
clause - it just makes life harder on the cuurrent FreeBSD RELEASE - or
change it. See below.
Curtis L. Olson wrote:
Update of /var/cvs/SimGear-0.3/source/simgear/sound
In directory baron:/tmp/cvs-serv27687/sound
Modified Files:
soundmgr_openal.cxx
Log Message:
I don't understand why FreeBSD doesn't see isnan() after including math.h
but it doesn't. Trying the apple approach to fixing isnan results in an
infinite loop (making me wonder what happens on OSX?) This is an alternative
approach to checking isnan() on freebsd ...
Index: soundmgr_openal.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/soundmgr_openal.cxx,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -r1.7 -r1.8
*** soundmgr_openal.cxx 19 Nov 2004 21:44:17 - 1.7
--- soundmgr_openal.cxx 21 Nov 2004 03:13:54 - 1.8
[...]
***
*** 47,50
--- 47,54
#endif
+ #if defined (__FreeBSD__)
+ inline int isnan(double r) { return !(r 0 || r 0); }
+ #endif
+
#include STL_IOSTREAM
An alternative to keep compatibility with older FreeBSD releases might
be to place such a clause:
#if defined (__FreeBSD__)
extern C {
#if __FreeBSD_version 50
inline int isnan(double r) { return !(r = 0 || r = 0); }
#endif
}
#endif
Thanks alot,
Martin.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs]
Curtis L. Olson wrote: Ok, this sounds reasonable. I assume this means that the isnan() problems are fixed in newer versions of FreeBSD? To be honest: I don't know if the current handling in FreeBSD-5.3 is _correct_, I just can state that the clause you introduced at this place annoyed the compiler :-) I got this error: g++ -march=pentiumpro -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/usr/local/include -I/opt/FlightGear/include -I/usr/X11R6/include -O3 -D_REENTRANT -c -o soundmgr_openal.o soundmgr_openal.cxx In file included from /usr/include/c++/3.4/cmath:52, from ../../simgear/math/point3d.hxx:48, from ../../simgear/math/sg_types.hxx:42, from ../../simgear/misc/sg_path.hxx:36, from soundmgr_openal.cxx:60: soundmgr_openal.cxx:52: error: previous declaration of `int isnan(double)' with C++ linkage /usr/include/math.h:266: error: conflicts with new declaration with C linkage *** Error code 1 BTW: The workaround wasn't my own idea, I borrowed it from the folks who patched PLIB for the FreeBSD port ;-) Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs]
Perhaps this is why it is OK with OSX?
-- Adam
From: Curtis L. Olson [EMAIL PROTECTED]
Reply-To: FlightGear developers discussions [EMAIL PROTECTED]
Date: Thu, 02 Dec 2004 09:02:16 -0600
To: FlightGear developers discussions [EMAIL PROTECTED], J.
Couch [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] Re: [Simgear-cvslogs]
Hi Martin,
Ok, this sounds reasonable. I assume this means that the isnan()
problems are fixed in newer versions of FreeBSD?
Thanks,
Curt.
Martin Spott wrote:
Hello Curt,
could you please revert this change and remove the whole FreeBSD
clause - it just makes life harder on the cuurrent FreeBSD RELEASE - or
change it. See below.
Curtis L. Olson wrote:
Update of /var/cvs/SimGear-0.3/source/simgear/sound
In directory baron:/tmp/cvs-serv27687/sound
Modified Files:
soundmgr_openal.cxx
Log Message:
I don't understand why FreeBSD doesn't see isnan() after including math.h
but it doesn't. Trying the apple approach to fixing isnan results in an
infinite loop (making me wonder what happens on OSX?) This is an
alternative
approach to checking isnan() on freebsd ...
Index: soundmgr_openal.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/soundmgr_openal.cxx,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -r1.7 -r1.8
*** soundmgr_openal.cxx 19 Nov 2004 21:44:17 - 1.7
--- soundmgr_openal.cxx 21 Nov 2004 03:13:54 - 1.8
[...]
***
*** 47,50
--- 47,54
#endif
+ #if defined (__FreeBSD__)
+ inline int isnan(double r) { return !(r 0 || r 0); }
+ #endif
+
#include STL_IOSTREAM
An alternative to keep compatibility with older FreeBSD releases might
be to place such a clause:
#if defined (__FreeBSD__)
extern C {
#if __FreeBSD_version 50
inline int isnan(double r) { return !(r = 0 || r = 0); }
#endif
}
#endif
Thanks alot,
Martin.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS:
Curtis L. Olson wrote: Jim Couch set up a freebsd machine and gave me an account on it. I don't know what release he installed, but it was running gcc-3.3.3 if that says anything to you. The current RELEASE has 3.4.2 as their default compiler, so yours is older. You can't do distinct determination of FreeBSD versions just by their compiler because your admin probably has installed a second compiler from the ports. Maybe you'd just want to try 'uname -r' ? ;-) Please remember that 5.x releases _before_ 5.3 are considered to be not ready for production use. Most parts are working fine - I've been using a FreeBSD-5.x based firewall for long time to shield our server at the institute in Duisburg - but some susbsystems might still be broken (especially when it comes to heavy I/O load on uncommon interfaces). You'd probably want update before digging into these issues. I think they won't allow me for a joystick or speakers at my customers office, so unfortunately I can't comment on PLIB or OpenAL I/O issues. I'm very sorry. Anyway, it's not perfect on FreeBSD, but it's a lot better than where we started yesterday. I didn't have a single crash yet. I heavily suspect your trouble stems from using an unstable FreeBSD release. Anyway I'm happy you had a try ! Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/sound soundmgr_openal.cxx,
Martin Spott wrote: Erik Hofman wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/sound In directory baron:/tmp/cvs-serv16290 Modified Files: soundmgr_openal.cxx xmlsound.cxx Log Message: Melchior FRANZ: At last I've found the reason why fgfs crashed routinely for me. When I still used KDE's artsdsp (preloads lib with OSS replacement functions) I saw this crash only occasionally. After letting OpenAl communicate with artsd directly (by means of ~/.openalrc setting), I got the crash always when I left fgfs. I'm not sure if this was a really clever fix ;-) At least it breaks the build on FreeBSD-5.3: g++ -march=pentiumpro -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/usr/local/include -I/usr/X11R6/include -O3 -lpthread -D_REENTRANT -c -o soundmgr_openal.o soundmgr_openal.cxx In file included from /usr/include/c++/3.4/cmath:52, from ../../simgear/math/point3d.hxx:48, from ../../simgear/math/sg_types.hxx:42, from ../../simgear/misc/sg_path.hxx:36, from soundmgr_openal.cxx:56: soundmgr_openal.cxx:50: error: previous declaration of `int isnan(double)' with C++ linkage /usr/include/math.h:266: error: conflicts with new declaration with C linkage *** Error code 1 Stop in /usr/local/src/SimGear/simgear/sound. Things are fine after reverting these two patches. This has nothing to do with _this_ patch, you must be referring to another one. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS:
Erik Hofman wrote: This has nothing to do with _this_ patch, you must be referring to another one. Hmmm, yes, it actually looked a bit strange to me, too, but I copied the patch from the posting and applied it to my copy of the tree. Maybe I picked the wrong file for patching confusion !?!? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS:
Erik Hofman wrote: This has nothing to do with _this_ patch, you must be referring to another one. You're absolutely right. I was juggling with several patches and as a result of my confusion I finally hit the wrong posting. Actually this one would have been correct: I don't understand why FreeBSD doesn't see isnan() after including math.h but it doesn't. Trying the apple approach to fixing isnan results in an infinite loop (making me wonder what happens on OSX?) This is an alternative approach to checking isnan() on freebsd ... Sorry, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS:
Martin Spott wrote: You're absolutely right. I was juggling with several patches and as a result of my confusion I finally hit the wrong posting. Actually this one would have been correct: I don't understand why FreeBSD doesn't see isnan() after including math.h but it doesn't. Trying the apple approach to fixing isnan results in an infinite loop (making me wonder what happens on OSX?) This is an alternative approach to checking isnan() on freebsd ... Sorry, No problem. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Simgear-cvslogs] CVS:
Martin Spott writes: I don't understand why FreeBSD doesn't see isnan() after including math.h but it doesn't. Trying the apple approach to fixing isnan results in an infinite loop (making me wonder what happens on OSX?) This is an alternative approach to checking isnan() on freebsd ... according to this http://www.delorie.com/gnu/docs/glibc/libc_404.html isnan() is only defined for BSD for ISO C99 alternative BSD funcs discussed at link above also see bottom of this page http://naranja.umh.es/~atg/B1098370398/C2036966428/ Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS:
Norman Vine wrote: according to this http://www.delorie.com/gnu/docs/glibc/libc_404.html isnan() is only defined for BSD for ISO C99 Might this be related to using different compilers? Curt uses GCC-3.3.3 and I have 3.4.2, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: source/simgear/sound soundmgr_openal.cxx, 1.7, 1.8
Curtis L. Olson schrieb:
Log Message:
I don't understand why FreeBSD doesn't see isnan() after including math.h
but it doesn't. Trying the apple approach to fixing isnan results in an
infinite loop (making me wonder what happens on OSX?) This is an alternative
approach to checking isnan() on freebsd ...
[...]
+ #if defined (__FreeBSD__)
+ inline int isnan(double r) { return !(r 0 || r 0); }
+ #endif
This test will break if r == 0
CU,
Christian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS:
Curtis L. Olson wrote: I don't think my first attempt at an isnan() fix worked ... I ended up in an infinite loop. I've tried a less elegant/brute force approach and that seems to work. We actually got FG up and running on a FreeBSD machine tonight (woohoo!) Yeah ! Welcome to a wonderful world ! Did you use the current RELEASE, did you use OpenAL and PLIB from the ports or did you build them yourselves ? OpenAL compiles wihtout hassle, PLIB needed some fixes - I think some joystick stuff. I avoided the trouble and took the port ;-) but I'll try to build PLIB CVS this week in order to get the 'crease'-patch working, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: source/simgear/sound soundmgr_openal.cxx, 1.7, 1.8
Christian Mayer wrote:
+ #if defined (__FreeBSD__)
+ inline int isnan(double r) { return !(r 0 || r 0); }
+ #endif
This test will break if r == 0
Oops, duhhh! Thanks!
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS:
Martin Spott wrote: Curtis L. Olson wrote: I don't think my first attempt at an isnan() fix worked ... I ended up in an infinite loop. I've tried a less elegant/brute force approach and that seems to work. We actually got FG up and running on a FreeBSD machine tonight (woohoo!) Yeah ! Welcome to a wonderful world ! Did you use the current RELEASE, did you use OpenAL and PLIB from the ports or did you build them yourselves ? OpenAL compiles wihtout hassle, PLIB needed some fixes - I think some joystick stuff. I avoided the trouble and took the port ;-) but I'll try to build PLIB CVS this week in order to get the 'crease'-patch working, Jim Couch set up a freebsd machine and gave me an account on it. I don't know what release he installed, but it was running gcc-3.3.3 if that says anything to you. If you tell me the magic command, I can check the release. He already had plib built (I think from ports). He also had openal already built ... I'm not sure where that came from (probably ports?) I don't have direct access to the machine, but Jim reports that plib doesn't detect his USB joystick on FreeBSD. Any ideas? The kernel is detecting it and logging an entry with the joystick name, but nothing shows up inside plib. We aren't sure if it's a FreeBSD issue or Plib issue at this point. OpenAL does not work correclty with FG on FreeBSD ... Jim reports getting some sound ... it's almost like the sound is played at the correct frequency, but compressed so that it comes out 20x too fast. We also saw FG crash more times than it worked on FreeBSD ... that's a little disconcerting ... I haven't had a chance to look into that yet. But we at least got it all to compile and did get it up and running a couple times. Anyway, it's not perfect on FreeBSD, but it's a lot better than where we started yesterday. Regads, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: source/simgear/sound soundmgr_openal.cxx, 1.7, 1.8
On Sonntag 21 November 2004 22:46, Curtis L. Olson wrote:
Christian Mayer wrote:
+ #if defined (__FreeBSD__)
+ inline int isnan(double r) { return !(r 0 || r 0); }
+ #endif
This test will break if r == 0
According to IEEE, NaN is the only fp value that is not equal to itself. That
is, the code snippet:
inline int isnan(double r) { return r != r; }
should work on any IEEE machine.
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: source/simgear/screen extensions.cxx, 1.9,
Curtis L. Olson wrote: Update of /var/cvs/SimGear-0.3/source/simgear/screen In directory baron:/tmp/cvs-serv29601 Modified Files: extensions.cxx Log Message: FreeBSD fix. Thank you! Would anyone mind to comment on the two proposed changes to SimGear and FlightGear that I posted this week: Adding '-lpthread' to the OpenAL test in Simgear 'configure.ac' and adding '-lusbhid' in FlightGear where 'libplibjs' gets linked into binaries ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: source/simgear/screen extensions.cxx, 1.9,
Martin Spott wrote: Curtis L. Olson wrote: Update of /var/cvs/SimGear-0.3/source/simgear/screen In directory baron:/tmp/cvs-serv29601 Modified Files: extensions.cxx Log Message: FreeBSD fix. Thank you! Would anyone mind to comment on the two proposed changes to SimGear and FlightGear that I posted this week: Adding '-lpthread' to the OpenAL test in Simgear 'configure.ac' and adding '-lusbhid' in FlightGear where 'libplibjs' gets linked into binaries ? I don't think my first attempt at an isnan() fix worked ... I ended up in an infinite loop. I've tried a less elegant/brute force approach and that seems to work. We actually got FG up and running on a FreeBSD machine tonight (woohoo!) I committed a couple more small changes to simgear and FlightGear. There seems to be a stray segfault though someplace in the FreeBSD build that is intermittent (or maybe I should say FG works only very intermittently.) There also seems like there could be some joystick/plib problem on FreeBSD? It could also be something at the OS level? js_demo fails to find any joysticks ... any one have their usb joystick running correctly with plib apps under FreeBSD? Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: source/simgear/scene Makefile.am, 1.4, 1.5
Curtis L. Olson wrote: Update of /var/cvs/SimGear-0.3/source/simgear/scene In directory baron:/tmp/cvs-serv10533/simgear/scene Modified Files: Makefile.am Log Message: Final 0.3.7 changes. Index: Makefile.am === RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/Makefile.am,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** Makefile.am 30 May 2003 15:16:26 - 1.4 --- Makefile.am 12 Oct 2004 14:35:42 - 1.5 *** *** 1,5 includedir = @includedir@/scene ! SUBDIRS = material model sky tgdb # lib_LIBRARIES = libsgscene.a --- 1,5 includedir = @includedir@/scene ! SUBDIRS = fgsg material model sky tgdb What is fgsg ? I can't see it in CVS. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: source/simgear/scene Makefile.am, 1.4, 1.5
Shoot, that is junk that probalby shouldn't be there. I don't think it actually causes a problem though. Curt. Frederic Bouvier wrote: Curtis L. Olson wrote: Update of /var/cvs/SimGear-0.3/source/simgear/scene In directory baron:/tmp/cvs-serv10533/simgear/scene Modified Files: Makefile.am Log Message: Final 0.3.7 changes. Index: Makefile.am === RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/Makefile.am,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** Makefile.am 30 May 2003 15:16:26 - 1.4 --- Makefile.am 12 Oct 2004 14:35:42 - 1.5 *** *** 1,5 includedir = @includedir@/scene ! SUBDIRS = material model sky tgdb # lib_LIBRARIES = libsgscene.a --- 1,5 includedir = @includedir@/scene ! SUBDIRS = fgsg material model sky tgdb What is fgsg ? I can't see it in CVS. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: source/simgear/scene Makefile.am, 1.4, 1.5
In the tarball, the directory is there with a Makefile.am with zero length and a Makefile.in. I didn't try to generate from the tarball. -Fred Curtis L. Olson wrote: Shoot, that is junk that probalby shouldn't be there. I don't think it actually causes a problem though. Curt. Frederic Bouvier wrote: Curtis L. Olson wrote: Update of /var/cvs/SimGear-0.3/source/simgear/scene In directory baron:/tmp/cvs-serv10533/simgear/scene Modified Files: Makefile.am Log Message: Final 0.3.7 changes. Index: Makefile.am === RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/Makefile.am,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** Makefile.am 30 May 2003 15:16:26 - 1.4 --- Makefile.am 12 Oct 2004 14:35:42 - 1.5 *** *** 1,5 includedir = @includedir@/scene ! SUBDIRS = material model sky tgdb # lib_LIBRARIES = libsgscene.a --- 1,5 includedir = @includedir@/scene ! SUBDIRS = fgsg material model sky tgdb What is fgsg ? I can't see it in CVS. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/scene/tgdb obj.cxx, 1.9, 1.10
Erik Hofman wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/tgdb In directory baron:/tmp/cvs-serv8740/tgdb Modified Files: obj.cxx Log Message: Frederic Bouvier: put all leaf is a seperated branch so that it is possible to use a pretrav callback to cull out terrain without culling out light or dynamic objects. It appears that plib is not calling the pretrav callback for leaves. Is there any chance local_terrain needs to be reffed in the code snippet below, so that it is still available when the scenery chunk needs to be reloaded? Erik Index: obj.cxx === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/tgdb/obj.cxx,v retrieving revision 1.9 retrieving revision 1.10 diff -C2 -r1.9 -r1.10 *** a/obj.cxx 30 Dec 2003 05:53:50 - 1.9 --- b/obj.cxx 2 Apr 2004 14:39:19 - 1.10 *** *** 328,331 --- 328,335 } + ssgBranch *local_terrain = new ssgBranch; + local_terrain-setName( LocalTerrain ); + geometry-addKid( local_terrain ); + geometry-setName( (char *)path.c_str() ); ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS:SimGear/simgear/scene/tgdb obj.cxx, 1.9, 1.10
Erik Hofman wrote: Erik Hofman wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/tgdb In directory baron:/tmp/cvs-serv8740/tgdb Modified Files: obj.cxx Log Message: Frederic Bouvier: put all leaf is a seperated branch so that it is possible to use a pretrav callback to cull out terrain without culling out light or dynamic objects. It appears that plib is not calling the pretrav callback for leaves. Is there any chance local_terrain needs to be reffed in the code snippet below, so that it is still available when the scenery chunk needs to be reloaded? I don't think so, because geometry already hold a ref to terrain_branch, and you don't want to delete geometry without terrain_branch ( geometry is the branch that hold the terrain, various light and the objects. -Fred Index: obj.cxx === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/tgdb/obj.cxx,v retrieving revision 1.9 retrieving revision 1.10 diff -C2 -r1.9 -r1.10 *** a/obj.cxx 30 Dec 2003 05:53:50 - 1.9 --- b/obj.cxx 2 Apr 2004 14:39:19 - 1.10 *** *** 328,331 --- 328,335 } + ssgBranch *local_terrain = new ssgBranch; + local_terrain-setName( LocalTerrain ); + geometry-addKid( local_terrain ); + geometry-setName( (char *)path.c_str() ); ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Simgear-cvslogs]CVS:SimGear/simgear/scene/tgdb obj.cxx, 1.9, 1.10
Frederic Bouvier wrote: Erik Hofman wrote: Erik Hofman wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/tgdb In directory baron:/tmp/cvs-serv8740/tgdb Modified Files: obj.cxx Log Message: Frederic Bouvier: put all leaf is a seperated branch so that it is possible to use a pretrav callback to cull out terrain without culling out light or dynamic objects. It appears that plib is not calling the pretrav callback for leaves. Is there any chance local_terrain needs to be reffed in the code snippet below, so that it is still available when the scenery chunk needs to be reloaded? I don't think so, because geometry already hold a ref to terrain_branch, and you don't want to delete geometry without terrain_branch ( geometry is the branch that hold the terrain, various light and the objects. This is not terrain_branch but local_terrain of course -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel]Re: [Simgear-cvslogs]CVS: SimGear/simgear/scene/sky/clouds3dglut_shapes.c, 1.1, 1.2 glut_shapes.h, 1.2, 1.3
On Mar 16, 2004, at 9:38 AM, Erik Hofman wrote: Innis Cunningham wrote: Hi Guys I don't know if this helps in any way but I did a complete rebuild(plib,simgear,flightgear) about 7 days ago under Cygwin on windows 98 and did not have any problem so unless the above area has been changed in the last 7 days it is not simgear or cygwin that is to blame. The problem is only visible when X11 is also installed on Cygwin. Actually, this is not the case. I was successfully building FlightGear under Cygwin last month, it only started failing recently. I deleted Cygwin and did a reinstall _without_ X11 and it still does not build. Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel]Re: [Simgear-cvslogs]CVS: SimGear/simgear/scene/sky/clouds3dglut_shapes.c, 1.1, 1.2 glut_shapes.h, 1.2, 1.3
On Mar 16, 2004, at 9:38 AM, Erik Hofman wrote: Innis Cunningham wrote: Hi Guys I don't know if this helps in any way but I did a complete rebuild(plib,simgear,flightgear) about 7 days ago under Cygwin on windows 98 and did not have any problem so unless the above area has been changed in the last 7 days it is not simgear or cygwin that is to blame. The problem is only visible when X11 is also installed on Cygwin. Actually, this is not the case. I was successfully building FlightGear under Cygwin last month, it only started failing recently. I deleted Cygwin and did a reinstall _without_ X11 and it still does not build. Jonathan Polley I had a similar problem compiling under Cygwin just a couple of weeks ago. I uninstalled and reinstalled Cygwin so many times I lost count. On my last install I decided to try older versions of the glut files. I'm not sure if this did any thing (or if it was a combination of other factors), but I was then able to compile flightgear. Robert Deters ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/scene/sky/clouds3d glut_shapes.h, 1.1, 1.2
Erik Hofman wrote: A : [EMAIL PROTECTED] Copie à : Objet : [Simgear-cvslogs] CVS: SimGear/simgear/scene/sky/clouds3d glut_shapes.h, 1.1, 1.2 Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/sky/clouds3d In directory baron:/tmp/cvs-serv14020 Modified Files: glut_shapes.h Log Message: Attempt to fix a nasty Cygwin problem. Sorry, but it seems to me this is the wrong fix. Windows.h **must** be included before gl.h It is done in glut_shapes.h if HAVE_WINDOWS_H is defined. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/scene/sky/clouds3d glut_shapes.c, 1.1, 1.2 glut_shapes.h, 1.2, 1.3
Erik Hofman wrote: Modified Files: glut_shapes.c glut_shapes.h Log Message: Further refinement of the Cygwin problem as suggested by Frederic. Well, I had the impression that the code was originally good but the configure step was failing to detect and set HAVE_WINDOWS_H That's why CXXFLAGS=-DHAVE_WINDOWS_H ./configure was working -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/scene/sky/clouds3d glut_shapes.c, 1.1, 1.2 glut_shapes.h, 1.2, 1.3
Frederic BOUVIER wrote: Erik Hofman wrote: Modified Files: glut_shapes.c glut_shapes.h Log Message: Further refinement of the Cygwin problem as suggested by Frederic. Well, I had the impression that the code was originally good but the configure step was failing to detect and set HAVE_WINDOWS_H That's why CXXFLAGS=-DHAVE_WINDOWS_H ./configure was working The code is now a direct copy of screen/extensions.hxx so it should work this way. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Simgear-cvslogs]CVS: SimGear/simgear/scene/sky/clouds3dglut_shapes.c, 1.1, 1.2 glut_shapes.h, 1.2, 1.3
Erik Hofman writes: Frederic BOUVIER wrote: Erik Hofman wrote: Modified Files: glut_shapes.c glut_shapes.h Log Message: Further refinement of the Cygwin problem as suggested by Frederic. Well, I had the impression that the code was originally good but the configure step was failing to detect and set HAVE_WINDOWS_H That's why CXXFLAGS=-DHAVE_WINDOWS_H ./configure was working The code is now a direct copy of screen/extensions.hxx so it should work this way. This is still wrong windows.h needs to be included *before* gl.h inorder for the the WINDOWS GL extensions and not the GLX extensions to be recognized so something like #if defined(__CYGWIN__) # !defined(USING_X) #define WIN32 #endif #if defined(WIN32) # MINGW and MSC predefine WIN32 # include windows.h #endif HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re:[Simgear-cvslogs]CVS: SimGear/simgear/scene/sky/clouds3dglut_shapes.c, 1.1, 1.2 glut_shapes.h, 1.2, 1.3
Norman Vine wrote: so something like #if defined(__CYGWIN__) # !defined(USING_X) #define WIN32 #endif #if defined(WIN32) # MINGW and MSC predefine WIN32 # include windows.h #endif HTH Arrgh ... of course I meant something like #if defined(__CYGWIN__) /* !defined(USING_X) */ #define WIN32 #endif #if defined(WIN32) /* MINGW and MSC predefine WIN32 */ # include windows.h #endif Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Simgear-cvslogs]CVS: SimGear/simgear/scene/sky/clouds3dglut_shapes.c, 1.1, 1.2 glut_shapes.h, 1.2, 1.3
Norman Vine wrote: This is still wrong windows.h needs to be included *before* gl.h inorder for the the WINDOWS GL extensions and not the GLX extensions to be recognized How do you explain that the extensions code does work this way. Did you read the code or just the CVS log message? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel]Re: [Simgear-cvslogs]CVS: SimGear/simgear/scene/sky/clouds3dglut_shapes.c, 1.1, 1.2 glut_shapes.h, 1.2, 1.3
Erik Hofman writes: Norman Vine wrote: This is still wrong windows.h needs to be included *before* gl.h inorder for the the WINDOWS GL extensions and not the GLX extensions to be recognized How do you explain that the extensions code does work this way. If it works then it is getting WIN32 predefined from someplace other then the compiler itself which will break a Cygwin compilation for GLX X windows OpenGL which is a separate issue AFAIK the *only* Windows compiler that does not #define WIN32 is Cygwin. This is in order to better support Unix emulation and alternative windowing systems My proposed solution should allow both Win32 and GLX OpenGL compilation Did you read the code or just the CVS log message? I read the code in the HTML CVS Viewer Did you test the code with a Cygwin compiler bith with and without an X Server installed ? Best Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel]Re: [Simgear-cvslogs]CVS: SimGear/simgear/scene/sky/clouds3dglut_shapes.c, 1.1, 1.2 glut_shapes.h, 1.2, 1.3
Norman Vine wrote: If it works then it is getting WIN32 predefined from someplace other then the compiler itself which will break a Cygwin compilation for GLX X windows OpenGL which is a separate issue AFAIK the *only* Windows compiler that does not #define WIN32 is Cygwin. This is in order to better support Unix emulation and alternative windowing systems So changing it to the following should work also: #if defined(WIN32) || defined(__CYGWIN__) !defined(__MINGW32__) # include windows.h #endif My proposed solution should allow both Win32 and GLX OpenGL compilation Did you read the code or just the CVS log message? I read the code in the HTML CVS Viewer Did you test the code with a Cygwin compiler bith with and without an X Server installed ? If you put it this way I might as well leave the Windows/Cygwin developers on their own. I'm not planning on doing so. And yes, windows.h *is* defined before GL/gl.h. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel]Re: [Simgear-cvslogs]CVS: SimGear/simgear/scene/sky/clouds3dglut_shapes.c, 1.1, 1.2 glut_shapes.h, 1.2, 1.3
Erik Hofman writes: Norman Vine wrote: If it works then it is getting WIN32 predefined from someplace other then the compiler itself which will break a Cygwin compilation for GLX X windows OpenGL which is a separate issue AFAIK the *only* Windows compiler that does not #define WIN32 is Cygwin. This is in order to better support Unix emulation and alternative windowing systems So changing it to the following should work also: #if defined(WIN32) || defined(__CYGWIN__) !defined(__MINGW32__) # include windows.h #endif Maybe but this is overly complicated as __CYGWIN__ and __MINGW32__ should never be both defined the compiler never will anyway and if __MINGW32__ is defined WIN32 will be defined unless you undefine it as the MingW32 compiler does this and when __CYGWIN__ is defined windows.h wants to be included unless you are compiling for 'X' Did you read the code or just the CVS log message? I read the code in the HTML CVS Viewer Did you test the code with a Cygwin compiler bith with and without an X Server installed ? If you put it this way I might as well leave the Windows/Cygwin developers on their own. I'm not planning on doing so. Sorry about that comment but in my defense asking if I had read the code probably 'pushed' a auto-response button when all I was trying todo was enlighten a non-Cygwin user as to some of the subtleties of using a 'system' that can exist both in the 'nix' and 'evil' empires :-) I still submit that what I proposed is a 'proper' solution and don't understand what you have against it as it only affects MingW and Cygwin users. Best Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel]Re: [Simgear-cvslogs]CVS: SimGear/simgear/scene/sky/clouds3dglut_shapes.c, 1.1, 1.2 glut_shapes.h, 1.2, 1.3
Norman Vine wrote: I still submit that what I proposed is a 'proper' solution and don't understand what you have against it as it only affects MingW and Cygwin users. I'm not against it. I just want to know why this was needed because obviously the extensions code needs the same update then. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel]Re: [Simgear-cvslogs]CVS: SimGear/simgear/scene/sky/clouds3dglut_shapes.c, 1.1, 1.2 glut_shapes.h, 1.2, 1.3
Hi Guys I don't know if this helps in any way but I did a complete rebuild(plib,simgear,flightgear) about 7 days ago under Cygwin on windows 98 and did not have any problem so unless the above area has been changed in the last 7 days it is not simgear or cygwin that is to blame. Cheers Innis _ Personalise your phone with chart ringtones and polyphonics. Go to http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel]Re: [Simgear-cvslogs]CVS: SimGear/simgear/scene/sky/clouds3dglut_shapes.c, 1.1, 1.2 glut_shapes.h, 1.2, 1.3
Innis Cunningham wrote: Hi Guys I don't know if this helps in any way but I did a complete rebuild(plib,simgear,flightgear) about 7 days ago under Cygwin on windows 98 and did not have any problem so unless the above area has been changed in the last 7 days it is not simgear or cygwin that is to blame. The problem is only visible when X11 is also installed on Cygwin. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel]Re:[Simgear-cvslogs]CVS: SimGear/simgear/scene/sky/clouds3dglut_shapes.c, 1.1, 1.2 glut_shapes.h, 1.2, 1.3
i uninstalled X11 but still can't run configure. john - Original Message - From: Erik Hofman [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 10:38 AM Subject: Re: [Flightgear-devel]Re:[Simgear-cvslogs]CVS: SimGear/simgear/scene/sky/clouds3dglut_shapes.c,1.1, 1.2 glut_shapes.h, 1.2, 1.3 Innis Cunningham wrote: Hi Guys I don't know if this helps in any way but I did a complete rebuild(plib,simgear,flightgear) about 7 days ago under Cygwin on windows 98 and did not have any problem so unless the above area has been changed in the last 7 days it is not simgear or cygwin that is to blame. The problem is only visible when X11 is also installed on Cygwin. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel]Re:[Simgear-cvslogs]CVS: SimGear/simgear/scene/sky/clouds3dglut_shapes.c, 1.1, 1.2 glut_shapes.h, 1.2, 1.3
Hi John You sure seem to have had your fair share of trouble doing the build.I assume you have a running version of FG from the binaries. You say you are a software engineer maybe this is part of the problem(I mean this in the nicest way). I have and had very little knowledge of building FG so I had to build cygwin, glut,zlib,plib,simgear,flightgear by the bouncing ball method.IE follow the manual step by step.I did this not knowing a thing that was happening and eventualy after losing some of my hair I got the thing to build. Now with cygwin my build is almost 12 months old and it came with g++ so if you have a current one it should work fine. I don't have a clue what Net.VC7 is but I don't have it on my system. As someone else has said it is your choice as to what tools you use to build with but if you use ones other than what is recommended and strike problems then it makes it hard for other people to help. The first build I did was about 5 days but 3 of those were taken up downloading Cygwin(nearly a GIG worth on dial up). As I said I am a complete dummy when it comes to this stuff.But I did a complete build 7 days ago with very little problem using my 12 month old cygwin,glut and zlib and the then current CVS versions of Plib,Simgear and Flightgear.So I would venture to say that there are no bugs in the system. My computer specs are windows 98 with cygwin on 850 duron with gf4mx420 graphics card and 256 meg memory. Hope this helps Cheers Innis _ Personalise your mobile chart ringtones and polyphonics. Go to http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/scene/material mat.cxx, 1.16, 1.17
Erik Hofman wrote: Silently ignore texture files that are not present. How about putting out a warning at a very low priority level, so that people can debug problems if they need to? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/scene/material mat.cxx, 1.16, 1.17
David Megginson wrote: Erik Hofman wrote: Silently ignore texture files that are not present. How about putting out a warning at a very low priority level, so that people can debug problems if they need to? That would be an option ... The thing is, we now can have more than one texture specification for every material, and I put a second highres texture to BuildupCover. I thought it would be best *not* to put a second lowres texture in the base package otherwise it might spoil the reason for the lowres texture directory. What happens in such a case it that only the first texture gets loaded when the Textures.high directory isn't found. Note however that if *no* texture is found for a material the code will attempt to load the unknown.rgb texture (which wouldn't be found BTW) and displays the default checkboard texture. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/environment metar.cxx, 1.2,
Erik Hofman wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/environment In directory baron:/tmp/cvs-serv28945 Modified Files: metar.cxx metar.hxx Log Message: Melchior FRANZ: Add proxy support to the metar class. Authorization is untested, but everything else works. Martin will have to tell us ... Thanks for your effort, be shure I'll tell you ;-) Index: metar.cxx === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/environment/metar.cxx,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** a/metar.cxx 23 Feb 2004 20:07:20 - 1.2 --- b/metar.cxx 26 Feb 2004 09:46:36 - 1.3 [...] --- 56,64 * delete m; * ! * SGMetar n(KSFO, proxy.provider.foo, 3128, proxy-password); ^^^ proxy-username ? _I_ can configure the proxy to not ask for authorization, but for the sake of completeness it would be nice if the user could supply a username for proxy-authorization. BTW, after reading the patch I didn't figure _where_ to place the information for proxy use but probably digging a bit further with a running binary I'll get the clue ... On Unix we have the '$http_proxy' environment. Is there any counterpart on Windows and MacOS ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/environment metar.cxx, 1.2,
Martin Spott wrote: Erik Hofman wrote: Index: metar.cxx === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/environment/metar.cxx,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** a/metar.cxx 23 Feb 2004 20:07:20 - 1.2 --- b/metar.cxx 26 Feb 2004 09:46:36 - 1.3 [...] --- 56,64 * delete m; * ! * SGMetar n(KSFO, proxy.provider.foo, 3128, proxy-password); ^^^ proxy-username ? When I use libcurl to do that, there is a single field called CURLOPT_PROXYUSERPWD and the format is 'username:passwd'. You should try that syntax with FG. _I_ can configure the proxy to not ask for authorization, but for the sake of completeness it would be nice if the user could supply a username for proxy-authorization. BTW, after reading the patch I didn't figure _where_ to place the information for proxy use but probably digging a bit further with a running binary I'll get the clue ... On Unix we have the '$http_proxy' environment. Is there any counterpart on Windows and MacOS ? Under windows, it should be in the registry, but I don't know where yet. The same parameter is used by Outlook Express and Internet Explorer and certainly by other apps. You can access it from the control panel. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/environment metar.cxx, 1.2,
* Martin Spott -- Thursday 26 February 2004 11:38:
BTW, after reading the patch I didn't figure _where_ to place the
information for proxy use
Erik added the missing parts today. You can now set proxy information
in /sim/presets/proxy/{host,port,authentication}
/sim/presets/proxy/host = localhost
/sim/presets/proxy/port = 3128
Username isn't supported yet, because it doesn't exist. :-) At least not
in RFC2068. I guess I'll have to explore some newer RFCs and set up my
proxy for authentication to try myself.
m.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/environment metar.cxx, 1.2,
Melchior FRANZ wrote:
* Martin Spott -- Thursday 26 February 2004 11:38:
BTW, after reading the patch I didn't figure _where_ to place the
information for proxy use
Erik added the missing parts today. You can now set proxy information
in /sim/presets/proxy/{host,port,authentication}
/sim/presets/proxy/host = localhost
/sim/presets/proxy/port = 3128
Username isn't supported yet, because it doesn't exist. :-) At least not
in RFC2068. I guess I'll have to explore some newer RFCs and set up my
proxy for authentication to try myself.
Try to put username:password in /sim/presets/proxy/authentication
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/environment metar.cxx, 1.2,
* Frederic BOUVIER -- Thursday 26 February 2004 12:15: When I use libcurl to do that, there is a single field called CURLOPT_PROXYUSERPWD and the format is 'username:passwd'. You should try that syntax with FG. Ahh. That sounds reasonable. It's possibly up to the proxy to decide how the authorization string should look like, and some may require that the user name is part of it. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs] CVS:
* Erik Hofman -- Thursday 26 February 2004 13:06: * Martin Spott wrote: * Frederic BOUVIER wrote: When I use libcurl to do that, there is a single field called CURLOPT_PROXYUSERPWD and the format is 'username:passwd'. You should try that syntax with FG. Sorry, this does not work, I get a TCP_DENIED on my squid This *is* the official syntax. For web server authentication, but AFAIK not for proxy authentication. Anyway, I'll set my local proxy up for authentication and investigate this. Expect a patch within the next days. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS:
Melchior FRANZ wrote : * Erik Hofman -- Thursday 26 February 2004 13:06: * Martin Spott wrote: * Frederic BOUVIER wrote: When I use libcurl to do that, there is a single field called CURLOPT_PROXYUSERPWD and the format is 'username:passwd'. You should try that syntax with FG. Sorry, this does not work, I get a TCP_DENIED on my squid This *is* the official syntax. For web server authentication, but AFAIK not for proxy authentication. Anyway, I'll set my local proxy up for authentication and investigate this. Expect a patch within the next days. The code in libcurl suggest that the syntax is : Proxy-authorization: Basic authorization Note the keyword 'Basic' I also read a message in their mailing list suggesting that the authorization is base64 encoded : http://curl.haxx.se/mail/lib-2003-09/0198.html -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS:
Frederic BOUVIER wrote:
Melchior FRANZ wrote :
* Erik Hofman -- Thursday 26 February 2004 13:06:
* Martin Spott wrote:
* Frederic BOUVIER wrote:
When I use libcurl to do that, there is a single field called
CURLOPT_PROXYUSERPWD
and the format is 'username:passwd'. You should try that syntax with FG.
Sorry, this does not work, I get a TCP_DENIED on my squid
This *is* the official syntax.
For web server authentication, but AFAIK not for proxy authentication.
Anyway, I'll set my local proxy up for authentication and investigate
this. Expect a patch within the next days.
The code in libcurl suggest that the syntax is :
Proxy-authorization: Basic authorization
Note the keyword 'Basic'
I also read a message in their mailing list suggesting that the authorization
is base64 encoded : http://curl.haxx.se/mail/lib-2003-09/0198.html
Melchior,
if you are still looking for the right rfc for this, I think rfc2617 should explain
the Basic stuff.
The code in cURL is :
/*
* Proxy authentication
*/
if(conn-bits.proxy_user_passwd) {
char *authorization;
snprintf(data-state.buffer, BUFSIZE, %s:%s,
data-state.proxyuser, data-state.proxypasswd);
if(Curl_base64_encode(data-state.buffer, strlen(data-state.buffer),
authorization) = 0) {
if(conn-allocptr.proxyuserpwd)
free(conn-allocptr.proxyuserpwd);
conn-allocptr.proxyuserpwd =
aprintf(Proxy-authorization: Basic %s\015\012, authorization);
free(authorization);
}
}
Pretty obvious : user and password seperated by colon ':', then base64
encoded and then prepended with 'Basic '. I read reports saying that 'basic '
(lower case), while permitted by the rfc, is rejected by some servers.
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs] CVS:
* Frederic BOUVIER -- Thursday 26 February 2004 16:03: Pretty obvious : user and password seperated by colon ':', then base64 encoded and then prepended with 'Basic '. I read reports saying that 'basic ' (lower case), while permitted by the rfc, is rejected by some servers. Thanks for the rfc link and the code snippet. I'll see how I implement that. But in fact you should already be able to use authentication now, because /sim/presets/proxy/authentication is sent as argument of the Proxy-Authorization header. IOW: you can use the following 'script' and write its output into the authentication property: $ perl -e 'use MIME::Base64;print Basic .encode_base64($ARGV[0]:$ARGV[1])' user password m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS:
Martin Spott wrote: Frederic BOUVIER wrote: Martin Spott wrote: proxy-username ? When I use libcurl to do that, there is a single field called CURLOPT_PROXYUSERPWD and the format is 'username:passwd'. You should try that syntax with FG. Sorry, this does not work, I get a TCP_DENIED on my squid This *is* the official syntax. I have been working on adding a --proxy=username:[EMAIL PROTECTED]:port option this morning. There are a few glitches but it should be ready soon. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS:
Frederic BOUVIER wrote: Martin Spott wrote: proxy-username ? When I use libcurl to do that, there is a single field called CURLOPT_PROXYUSERPWD and the format is 'username:passwd'. You should try that syntax with FG. Sorry, this does not work, I get a TCP_DENIED on my squid - but I'm not bothered, because I am myself the admin of the proxy server and I usually disable authentication for my workplace :-) I'm used to this syntax from password protected webservers where you use an URL like 'martin:password@www.companyname' When I recently implemented authorization of a Squid proxy server against an OpenLDAP user database I read a notice that told me you must have a recent web browser to get authorization running. Older Releases of Netscape (I assume before 3.x) are supposed not to work because they behave different on authorization requests from the proxy server. The 'lynx' I currently have at home (from Sunfreeware): foehn: 12:55:23 ~ lynx --version Lynx Version 2.8.3rel.1 (23 Apr 2000) Built on solaris2.8 Nov 21 2000 01:05:19 does _not_ authenticate correctly, although it asks the user for username and password. The lynx that ships with SuSE-8.2: isnix1: 12:56:24 ~ lynx --version Lynx Version 2.8.4rel.1 (17 Jul 2001) libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 0.9.6i Kompiliert auf linux, Mar 14 2003 02:27:59 ... _does_ work, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs]CVS: SimGear/simgear/scene/sky oursun.cxx, 1.9, 1.10
* Curtis L. Olson -- Friday 15 August 2003 19:56: I haven't looked into this issue very closely. I have an nvidia card and wasn't seeing anything odd, but perhaps I wasn't looking closely enough. Same for me: nvidia without having seen anything strange. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re:[Simgear-cvslogs]CVS: SimGear/simgear/scene/sky oursun.cxx, 1.9, 1.10
Melchior FRANZ wrote: * Curtis L. Olson -- Friday 15 August 2003 19:56: I haven't looked into this issue very closely. I have an nvidia card and wasn't seeing anything odd, but perhaps I wasn't looking closely enough. Same for me: nvidia without having seen anything strange. Here are some screenshots of what I was seeing after Erik's first change to oursun.cxx and before a workaround was checked yesterday evening ( B time ). Note you must have the sun and the terrain in sight at the same time to notice anything. Seeing the sun, standard visibility : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-fog-01.jpg Sun out of view, standard visibility : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-fog-02.jpg Seeing the sun, visibility increased : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-fog-03.jpg Sun out of view, visibility increased (same as previous ): http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-fog-04.jpg Seeing the sun, visibility decreased : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-fog-05.jpg Seeing the sun, the edge of the world is very apparent. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs] CVS:SimGear/simgear/scene/sky oursun.cxx, 1.9, 1.10
Erik, Using glGet() is considered a no-no in real time applications. That stalls out the pipeline and forces all pending operations to flush before the card can return with the correct answer. We might be able to get away with it in limited quantities, but this can *quickly* turn into a performance killer (probably varies signifantly from platform to platform.) Please consider an alternative approach! Thanks, Curt. Erik Hofman writes: Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/sky In directory baron:/tmp/cvs-serv29366 Modified Files: oursun.cxx Log Message: Add support for NVidia cards with a broken OpenGL implementation Index: oursun.cxx === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/sky/oursun.cxx,v retrieving revision 1.9 retrieving revision 1.10 diff -C2 -r1.9 -r1.10 *** oursun.cxx14 Aug 2003 12:32:58 - 1.9 --- oursun.cxx15 Aug 2003 17:19:22 - 1.10 *** *** 50,53 --- 50,61 #include oursun.hxx + // FIXME: This should not be needed, but at this time (08/15/2003) + //certain NVidia drivers don't seem to implement + //fgPushAttrib(FG_FOG_BIT) properly. The result is that + //there is not fog when looking at the sun. + #ifndef SG_PROPER_FOG_SUPPORT + static float curFogDensity; + #endif + // Set up sun rendering call backs *** *** 88,91 --- 96,103 if ( f - hasState () ) f-getState()-apply() ; + #ifndef SG_PROPER_FOG_SUPPORT + glGetFloatv( GL_FOG_DENSITY, curFogDensity ); + #endif + glPushAttrib( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_FOG_BIT ); // cout push error = glGetError() endl; *** *** 106,109 --- 118,125 // cout pop error = glGetError() endl; + #ifndef SG_PROPER_FOG_SUPPORT + glFogf( GL_FOG_DENSITY, curFogDensity ); + #endif + // glEnable( GL_DEPTH_TEST ); // glEnable( GL_FOG ); ___ Simgear-cvslogs mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/simgear-cvslogs -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] Re: [Simgear-cvslogs]CVS: SimGear/simgear/scene/sky oursun.cxx, 1.9, 1.10
Curtis L. Olson wrote: Erik, Using glGet() is considered a no-no in real time applications. That stalls out the pipeline and forces all pending operations to flush before the card can return with the correct answer. We might be able to get away with it in limited quantities, but this can *quickly* turn into a performance killer (probably varies signifantly from platform to platform.) Please consider an alternative approach! The only thing I can think of is not using glFogf() until this issue is resolved. Anybody else have a suggestion? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re:[Simgear-cvslogs]CVS: SimGear/simgear/scene/sky oursun.cxx, 1.9, 1.10
Erik Hofman wrote: Curtis L. Olson wrote: Erik, Using glGet() is considered a no-no in real time applications. That stalls out the pipeline and forces all pending operations to flush before the card can return with the correct answer. We might be able to get away with it in limited quantities, but this can *quickly* turn into a performance killer (probably varies signifantly from platform to platform.) Please consider an alternative approach! The only thing I can think of is not using glFogf() until this issue is resolved. Anybody else have a suggestion? My first proposal, while inelegant, doesn't use a glGet : --- main.cxx31 Jul 2003 14:47:56 - 1.117 +++ main.cxx14 Aug 2003 21:32:35 - @@ -736,6 +736,9 @@ // return to the desired diffuse color ssgGetLight( 0 ) - setColour( GL_DIFFUSE, l-scene_diffuse ); + +// return to normal fog density +glFogf ( GL_FOG_DENSITY, fog_exp2_density ); } // draw the ssg scene -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel]Re: [Simgear-cvslogs]CVS: SimGear/simgear/scene/skyoursun.cxx, 1.9, 1.10
Frederic Bouvier wrote: Erik Hofman wrote: Curtis L. Olson wrote: Erik, Using glGet() is considered a no-no in real time applications. That stalls out the pipeline and forces all pending operations to flush before the card can return with the correct answer. We might be able to get away with it in limited quantities, but this can *quickly* turn into a performance killer (probably varies signifantly from platform to platform.) Please consider an alternative approach! The only thing I can think of is not using glFogf() until this issue is resolved. Anybody else have a suggestion? My first proposal, while inelegant, doesn't use a glGet : There is not much choice. It's in CVS. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Simgear-cvslogs]CVS: SimGear/simgear/scene/sky oursun.cxx, 1.9, 1.10
Erik Hofman writes: Curtis L. Olson wrote: Erik, Using glGet() is considered a no-no in real time applications. That stalls out the pipeline and forces all pending operations to flush before the card can return with the correct answer. We might be able to get away with it in limited quantities, but this can *quickly* turn into a performance killer (probably varies signifantly from platform to platform.) Please consider an alternative approach! The only thing I can think of is not using glFogf() until this issue is resolved. Anybody else have a suggestion? I haven't looked into this issue very closely. I have an nvidia card and wasn't seeing anything odd, but perhaps I wasn't looking closely enough. My gut feeling is that it is less likely that we have found a bug in nvidia's opengl drivers and much more likely we are doing something slightly odd, or misunderstanding the nuances of the opengl calls we are using. ssg's lazy state evaulation mechanism is set up precisely so that we can minimize state changes by note reseting things that are already set correctly *and* avoid doing glGet()'s because the lazy state evaluator knows the current state of all the items it tracks. However, ssg only tracks a limited set of parameters which is why glPush and glPopAttrib() come in handy because they allow you to save, change, and then restore a particular item without actually querying it's original value. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] Re:[Simgear-cvslogs]CVS: SimGear/simgear/scene/sky oursun.cxx, 1.9, 1.10
Curtis L. Olson wrote: Erik Hofman writes: Curtis L. Olson wrote: Erik, Using glGet() is considered a no-no in real time applications. That stalls out the pipeline and forces all pending operations to flush before the card can return with the correct answer. We might be able to get away with it in limited quantities, but this can *quickly* turn into a performance killer (probably varies signifantly from platform to platform.) Please consider an alternative approach! The only thing I can think of is not using glFogf() until this issue is resolved. Anybody else have a suggestion? I haven't looked into this issue very closely. I have an nvidia card and wasn't seeing anything odd, but perhaps I wasn't looking closely enough. My gut feeling is that it is less likely that we have found a bug in nvidia's opengl drivers and much more likely we are doing something slightly odd, or misunderstanding the nuances of the opengl calls we are using. ssg's lazy state evaulation mechanism is set up precisely so that we can minimize state changes by note reseting things that are already set correctly *and* avoid doing glGet()'s because the lazy state evaluator knows the current state of all the items it tracks. However, ssg only tracks a limited set of parameters which is why glPush and glPopAttrib() come in handy because they allow you to save, change, and then restore a particular item without actually querying it's original value. In this case, there is a glPushAttrib in the preDraw routine and a glPopAttrib in the postDraw routine. When there is the glGet/glFog pair, things are OK, so the fog is not corrupted before the preDraw or after the postDraw. I have just checked the depth of the attrib stack before the push and after the pop, and the values are the same so there is unlikely a mismatch here. The only thing to be sure is to hack a small example program and see if it works or not. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs]
Curtis L. Olson [EMAIL PROTECTED] wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/screen In directory baron:/tmp/cvs-serv22511 Modified Files: texture.cxx texture.hxx Log Message: Attempt to get these files back to a compilable state. Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs]
Erik Hofman [EMAIL PROTECTED] wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/screen In directory baron:/tmp/cvs-serv16338/simgear/screen Modified Files: texture.cxx texture.hxx Log Message: Allow removing of the texture data after it is sent to OpenGL make[3]: Entering directory `/usr/local/src/SimGear/simgear/screen' if g++ -march=pentiumpro -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/opt/gnu/include -I/usr/local/include -I/usr/local/FlightGear/include -I/usr/X11R6/include -O3 -g -D_REENTRANT -MT texture.o -MD -MP -MF .deps/texture.Tpo \ -c -o texture.o `test -f 'texture.cxx' || echo './'`texture.cxx; \ then mv .deps/texture.Tpo .deps/texture.Po; \ else rm -f .deps/texture.Tpo; exit 1; \ fi texture.cxx: In member function `void SGTexture::set_pixel(unsigned int, unsigned int, float ()[3])': texture.cxx:343: warning: assignment to `unsigned char' from `float' texture.cxx:343: warning: argument to `unsigned char' from `float' texture.cxx:344: warning: assignment to `unsigned char' from `float' texture.cxx:344: warning: argument to `unsigned char' from `float' texture.cxx:345: warning: assignment to `unsigned char' from `float' texture.cxx:345: warning: argument to `unsigned char' from `float' texture.cxx: In member function `float (* SGTexture::get_pixel(unsigned int, unsigned int))[3]': texture.cxx:356: error: return-statement with no value, in function declared with a non-void return type make[3]: *** [texture.o] Fehler 1 make[3]: Leaving directory `/usr/local/src/SimGear/simgear/screen' make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/usr/local/src/SimGear/simgear' make[1]: *** [all] Fehler 2 make[1]: Leaving directory `/usr/local/src/SimGear/simgear' make: *** [all-recursive] Fehler 1 Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/screentexture.cxx,1.7,1.8
Erik Hofman [EMAIL PROTECTED] wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/screen In directory baron:/tmp/cvs-serv16734 Modified Files: texture.cxx Log Message: Don't use floats where ints are more appropriate Unfortunately this still does not fix it. The output almost looks the same as the previous one: make[3]: Entering directory `/usr/local/src/SimGear/simgear/screen' if g++ -mcpu=hypersparc -mtune=hypersparc -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/opt/gnu/include -I/usr/local/include -I/usr/local/FlightGear/include -O1 -D_REENTRANT -MT texture.o -MD -MP -MF .deps/texture.Tpo \ -c -o texture.o `test -f 'texture.cxx' || echo './'`texture.cxx; \ then mv -f .deps/texture.Tpo .deps/texture.Po; \ else rm -f .deps/texture.Tpo; exit 1; \ fi texture.cxx: In member function `void SGTexture::set_pixel(unsigned int, unsigned int, float ()[3])': texture.cxx:343: warning: assignment to `unsigned char' from `float' texture.cxx:343: warning: argument to `unsigned char' from `float' texture.cxx:344: warning: assignment to `unsigned char' from `float' texture.cxx:344: warning: argument to `unsigned char' from `float' texture.cxx:345: warning: assignment to `unsigned char' from `float' texture.cxx:345: warning: argument to `unsigned char' from `float' texture.cxx: In member function `float (* SGTexture::get_pixel(unsigned int, unsigned int))[3]': texture.cxx:356: error: return-statement with no value, in function declared with a non-void return type make[3]: *** [texture.o] Error 1 make[3]: Leaving directory `/usr/local/src/SimGear/simgear/screen' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/SimGear/simgear' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/local/src/SimGear/simgear' make: *** [all-recursive] Error 1 Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/screentexture.cxx,1.7,1.8
* Martin Spott -- Friday 11 July 2003 13:42: Unfortunately this still does not fix it. [...] texture.cxx: In member function `void SGTexture::set_pixel(unsigned int, unsigned int, float ()[3])': texture.cxx: In member function `float (* SGTexture::get_pixel(unsigned int, unsigned int))[3]': texture.cxx:356: error: return-statement with no value, in function declared with a non-void return type make[3]: *** [texture.o] Error 1 Of course not. Erik's crappy compiler doesn't seem to find it strange that a function doesn't return anything. :- m. diff -u -p -U0 -r1.8 texture.cxx --- texture.cxx 11 Jul 2003 10:55:17 - 1.8 +++ texture.cxx 11 Jul 2003 12:11:45 - @@ -356 +356 @@ SGTexture::get_pixel(GLuint x, GLuint y) -return; +return c; ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear configure.ac,1.35,1.36
Erik Hofman [EMAIL PROTECTED] wrote: Update of /var/cvs/SimGear-0.3/SimGear In directory baron:/tmp/cvs-serv13077 Modified Files: configure.ac Log Message: Back out a patch that never went in CVS ... This does not serve as a complete fix: quickstep: 16:54:30 /usr/local/src/SimGear grep SGTHREAD simgear/Makefile #SGTHREAD_DIR = threads SGTHREAD_DIR = $(SGTHREAD_DIR) \ Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RE: [Simgear-cvslogs] CVS: SimGear/simgear/sky Makefile.am,1.2,1.3
Michael Basler writes: I know it would come. I recall the (justified) discussion on options to disable certains FDMs in the build which would result in these FDMs soon beeing out of sync and forgotten. I fear this will be the fate of the 3D clouds (which I enjoyed very much), now. The FDM's have active owners though who address issues that come up, the 3d cloud code currently does not. :-( BTW, did you see my message on Metakit update as of Saturday, 8th (just that it doesn't get lost). I saw it, but haven't had a chance to think about it ... dropping email left and right due to perpetual high volumes ... :-( Curt. -- Curtis Olson IVLab / HumanFIRST Program 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] Re: [Simgear-cvslogs] CVS: SimGear/simgear/misc sg_path.cxx,1.2,1.3sg_path.hxx,1.2,1.3
On Wed, 26 Feb 2003 13:50:17 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/misc In directory seneca:/tmp/cvs-serv25218/simgear/misc Modified Files: sg_path.cxx sg_path.hxx Log Message: Add some convenience functions to the SGPath function. Could the file(), dir(), base() and extension() functions be made const member functions. As it stands they cannot be applied to const reference/pointer values which limits their usefulness. Many thanks, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/misc sg_path.cxx,1.2,1.3sg_path.hxx,1.2,1.3
Ok, sounds like a good idea. Curt. Bernie Bright writes: On Wed, 26 Feb 2003 13:50:17 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/misc In directory seneca:/tmp/cvs-serv25218/simgear/misc Modified Files: sg_path.cxx sg_path.hxx Log Message: Add some convenience functions to the SGPath function. Could the file(), dir(), base() and extension() functions be made const member functions. As it stands they cannot be applied to const reference/pointer values which limits their usefulness. Many thanks, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program 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] Re: [Simgear-cvslogs] CVS: SimGear/simgear/compatibility - Newdirectory
On Mon, 30 Dec 2002 15:32:53 -0600 David Megginson [EMAIL PROTECTED] wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/compatibility In directory seneca:/tmp/cvs-serv31511/simgear/compatibility Log Message: Directory /var/cvs/SimGear-0.3/SimGear/simgear/compatibility added to the repository Getting the following error trying to cvs update: cvs server: Updating simgear/compatibility cvs server: failed to create lock directory for `/var/cvs/SimGear-0.3/SimGear/simgear/compatibility' (/var/cvs/SimGear-0.3/SimGear/simgear/compatibility/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/var/cvs/SimGear-0.3/SimGear/simgear/compatibility' cvs [server aborted]: read lock failed - giving up This is on Mandrake 9.0 using cvs 1.11.2. I think this could be due to ownership/permission problems in the cvs repository. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
