[Flightgear-devel] SimGear Build Problem under MacOS X
It seems as if MacOS X does not have isnan(), or at least by
default. From wading trough the headers (I see isnan in there, so
I'm not sure why it is not being used), I made the following change
to cloudfield.cxx. My guess is that this will only work on the Mac,
since it appears as if ISNAN gets converted to max or min float.
Are any other Mac users seeing this?
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/sky/cloudfield.cxx,v
retrieving revision 1.7
diff -r1.7 cloudfield.cxx
163c163
if ( isnan(course) ) {
---
if ( (course -360.0) || (course 360.0) ) {
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear Build Problem Under MacOS 10.4
For some reason, the c172_aero.c file in src/FDM/LaRCsim generates a link error. There is a variable, called simply 'b' that conflicts with a symbol in MacOS 10.4's OpenGL library (go figure). Without making it static (or changing its name), I get the following link error: ld: ../../src/FDM/LaRCsim/libLaRCsim.a(c172_aero.o) illegal reference to symbol: _b defined in indirectly referenced dynamic library / System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ libGLImage.dylib For now, I have made the 'b' variable static and then FlightGear links just fine. It does not complete its initialization, but I probably have a messed up config file (it has been a while since I have build FlightGear). Jonathan Polley ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Scratch Build Problem
I was having a problem getting FlightGear to link, so I decided to do a complete uninstall and delete of the development directories. After a clean fetch from CVS, I was able to rebuild SimGear, but FlightGear won't even configure. I get the following error: configure: error: cannot run /bin/sh ./config.sub and config.sub was not generated by ./autogen.sh. Any ideas as to what needs to be done? Thanks, Jonathan Polley ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling Flightgear 0.9 from CVS on Mac OS X
I am using MacOS X 10.3 and don't remember having to upgrade the automake tools, but I have updated to the most recent Xcode release. On Thursday, March 03, 2005, at 08:38AM, Arthur Wiebe [EMAIL PROTECTED] wrote: I don't know if anyone is aware of this but a document on building from source for Mac OS X is located at http://sourceforge.net/docman/display_doc.php?docid=26350group_id=126825 And for myself, I upgraded autoconf and automake in order to run autogen.sh from the FGFS CVS. For some reason Apple's versions don't work. On Thu, 3 Mar 2005 08:35:00 -, Giles Robertson [EMAIL PROTECTED] wrote: g++ -g -O2 -D_REENTRANT -L/FlightGear/lib -o test-up test-up.o -lsgmath -lsgxml -lsgmisc -lsgdebug -lsgstructure -lsgtiming -lplibsg -lplibul -lz ld: can't locate file for: -lsgmath make[1]: *** [test-up] Error 1 make: *** [all-recursive] Error 1 That's failed to find the first SimGear library. Check that you installed (make install) SimGear after you built it, and that ./configure has detected the directory where it's installed. Giles Robertson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Arthur/ - http://artooro.blogspot.com (Weblog) - http://sourceforge.net/users/artooro/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] link to my homepage
On Saturday, January 22, 2005, at 09:27AM, Curtis L. Olson [EMAIL PROTECTED] wrote: Let's not lose sight of a couple facts: 1. This is all regarding the Mac OS X package. 2. The author has already agreed to make some changes to his package. 3. This package is distributed on a source forge project page registered and maintained by this same developer. 4. The objectionable file is inside the mac package. 5. No one else has volunteered to make a mac friendly package. I strongly disagree with #5 as I have been building the last two releases of the MacOS X version of FlightGear, but they haven't been picked up and moved to the FlightGear web page. Because I don't have infinite storage, Ican't keep them around forever. This is mainly becasue I was asked to include the base packages as a part of the release. If someone would be willing to take the update, I can have a version ready this afternoon. Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle Available
Arthur, Considering the problems some people have been having in running the Mac version, have you added instructions to the .dmg file? I was able to host the previous version (0.9.6) on my .mac account, but it was less than 125 MB (which is my limit). Jonathan Polley On Friday, December 17, 2004, at 03:56PM, Arthur Wiebe [EMAIL PROTECTED] wrote: I have built an application bundle of FlightGear for Mac OS X. It's a rather large application because it includes everything such as the base data, fgfs, etc. Compressed it's a total of 132 MB. I have no place to host such large files so I've made it available via BitTorrent. I've attached it to this email. Hopefully we can get some more people seeding. Now it would be really nice if you could switch aircraft from in the simulator! :) -- Arthur/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle Available
That is not necessarily the case. I have had a heck of a time explaining to users how to get the application to run. On Dec 17, 2004, at 6:04 PM, Arthur Wiebe wrote: It's a single application in a disk image. No instructions included. I figured anyone downloading FlightGear would know what to do with it. By the way Curt, it's done uploading. On Fri, 17 Dec 2004 17:50:23 -0600, Jonathan Polley [EMAIL PROTECTED] wrote: Arthur, Considering the problems some people have been having in running the Mac version, have you added instructions to the .dmg file? I was able to host the previous version (0.9.6) on my .mac account, but it was less than 125 MB (which is my limit). 0.9.6 is the current version is it not? My package is built from CVS 2004-12-17 so I named the version 0.9.6+. Jonathan Polley On Friday, December 17, 2004, at 03:56PM, Arthur Wiebe [EMAIL PROTECTED] wrote: I have built an application bundle of FlightGear for Mac OS X. It's a rather large application because it includes everything such as the base data, fgfs, etc. Compressed it's a total of 132 MB. I have no place to host such large files so I've made it available via BitTorrent. I've attached it to this email. Hopefully we can get some more people seeding. Now it would be really nice if you could switch aircraft from in the simulator! :) -- Arthur/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Arthur/ - http://artooro.blogspot.com (Weblog) - http://machcms.sourceforge.net (MachCMS Project) - http://acalproj.sourceforge.net (Calendar Project) ___ 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] FlightGear Mac OS X Application Bundle Available
Double-clicking the icon isn't the problem. In many cases, getting the .fgfsrc file properly installed was the problem. For my next release, I was going to include a python script that would set up the file and modify the default resource file. Many Mac users that subscribe to the Users mailing list are not UNIX literate. This is a problem for me since I am use to dealing with UNIX types and don't know how to write for a person who isn't. It really is a change in thinking. Jonathan Polley On Dec 17, 2004, at 6:09 PM, Arthur Wiebe wrote: lol, How many different ways can you explain to somebody how to double click an icon. On Fri, 17 Dec 2004 18:07:26 -0600, Jonathan Polley [EMAIL PROTECTED] wrote: That is not necessarily the case. I have had a heck of a time explaining to users how to get the application to run. On Dec 17, 2004, at 6:04 PM, Arthur Wiebe wrote: It's a single application in a disk image. No instructions included. I figured anyone downloading FlightGear would know what to do with it. By the way Curt, it's done uploading. On Fri, 17 Dec 2004 17:50:23 -0600, Jonathan Polley [EMAIL PROTECTED] wrote: Arthur, Considering the problems some people have been having in running the Mac version, have you added instructions to the .dmg file? I was able to host the previous version (0.9.6) on my .mac account, but it was less than 125 MB (which is my limit). 0.9.6 is the current version is it not? My package is built from CVS 2004-12-17 so I named the version 0.9.6+. Jonathan Polley On Friday, December 17, 2004, at 03:56PM, Arthur Wiebe [EMAIL PROTECTED] wrote: I have built an application bundle of FlightGear for Mac OS X. It's a rather large application because it includes everything such as the base data, fgfs, etc. Compressed it's a total of 132 MB. I have no place to host such large files so I've made it available via BitTorrent. I've attached it to this email. Hopefully we can get some more people seeding. Now it would be really nice if you could switch aircraft from in the simulator! :) -- Arthur/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Arthur/ - http://artooro.blogspot.com (Weblog) - http://machcms.sourceforge.net (MachCMS Project) - http://acalproj.sourceforge.net (Calendar Project) ___ 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 -- Arthur/ - http://artooro.blogspot.com (Weblog) - http://machcms.sourceforge.net (MachCMS Project) - http://acalproj.sourceforge.net (Calendar Project) ___ 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] Broadcast Address
One thing to be concerned about is that pinging your broadcast address may not be as meaningful as you'd like. Pinging 224.0.0.1 will probably yield the same results, as all multicast aware computers should respond to a ping at that address. I don't use multicast very much, in fact I try to avoid it when possible. Broadcast packets tend to live too long on a network (as long as standard unicast messages, which almost got me into trouble once...). Since I don't use broadcast, I'm not sure why you are getting an error binding to the broadcast address. Jonathan Polley On Thursday, December 09, 2004, at 03:38PM, John Wojnaroski [EMAIL PROTECTED] wrote: - Original Message - From: Jonathan Polley [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, December 09, 2004 1:00 PM Subject: Re: [Flightgear-devel] Broadcast Address You will want to use multicast. The multicast address range is 224.0.0.0 thru 239.255.255.255. 224.0.0.0 is reserved, so don't use it. Also, multicast has a default time to live (TTL) of 1 hop, so it will be limited to devices on the same subnet. I don't know if FlightGear handles receiving multicast, tho. Jonathan Polley Ooops, should have been a bit more expicit. The machines are running on a private LAN that supports my 747 sim. All four machines require FG data. While two machines require a full set of data (plus what I've added from JSBSim) the remaining two require a smaller subset and I'll probably add a fifth to run the MCDUs which requires even a smaller set. Plus there is additional data using the opengc protocol which is also redundant. Was not conptemplating the idea of going onto the Internet... Running Debian with linux-2.4.26 on all machines. The network configuration appears okay, in that a ping 192.168.2.255 from any and all machines generates a response from all machines Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Build Problem Under MacOS X 10.3
I tried building with the latest MacOS changes from CVS and found one problem. When compiler.h gets generated, the symbol SG_GLUT_H gets defined to be OpenGL/glut.h when it needs to be defined as GLUT/glut.h. It is a part of the GLUT framework and not the OpenGL framework. Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] how to interface with flightgear
In the network area (http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Network/?cvsroot=FlightGear-0.9) there is a data structure defined in net_ctrls.hxx that contains the data you want, but I don't think that it is being filled in by any of the FDMs. Jonathan Polley On Wednesday, October 20, 2004, at 12:34PM, [EMAIL PROTECTED] wrote: I am working on a autopilot project and we need a flight simulator to prove our control method before use it on a real aircraft. Is there any interface to get the attitude of aircraft from and send control data to flightgear. I mean get the altitude, rate, accelerate and so on from it and send rudder, elevator, aileron and throttle data to flightgear to control a aircraft. Thanks ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Latest CVS Aborts
I just updated tonight and FlightGear no longer runs on the Mac. As of last night, everything ran just file, but after updating everything (SimGear, FlightGear, and base packages) I get an abort. The gdb backtrace is: Using Mac OS X hack for initializing C++ stdio... Failed to find runway 28R at airport KSEA Initializing OpenAL sound manager Program received signal SIGABRT, Aborted. 0x900429ac in kill () (gdb) backtrace #0 0x900429ac in kill () #1 0x9009eb1c in abort () #2 0x00370794 in __cxxabiv1::__terminate(void (*)()) () at ssg.h:632 #3 0x003707d8 in std::terminate() () at ssg.h:632 #4 0x003792c4 in __cxa_throw () at ssg.h:632 #5 0x0032d5c0 in readXML(std::string const, XMLVisitor) ([EMAIL PROTECTED], [EMAIL PROTECTED]) at /usr/include/gcc/darwin/3.3/c++/bits/stl_alloc.h:656 #6 0x002a8f28 in FGTrafficManager::startElement(char const*, XMLAttributes const) (this=0x1837d4a0, name=0x0, [EMAIL PROTECTED]) at TrafficMgr.cxx:114 #7 0x0032cc5c in start_element(void*, char const*, char const**) (userData=0x183da3e8, name=0xf9f5a14 traffic, atts=0x183dd130) at easyxml.cxx:133 #8 0x0032ecec in doContent (parser=0x1837d270, startTagLevel=-1073764536, enc=0x5e2dd0, s=0xbfffadb7 traffic include=\KLM/KLM.xml\/\n traffic include=\UAL/UAL.xml\/\n!-- traffic include=\test.xml\/ --\n/trafficlist, end=0x55d10c , nextPtr=0x55d10c) at xmlparse.c:1296 #9 0x003303ec in prologProcessor (parser=0x1837d270, s=0xbfffada6 trafficlist\n traffic include=\KLM/KLM.xml\/\n traffic include=\UAL/UAL.xml\/\n!-- traffic include=\test.xml\/ --\n/trafficlist, end=0xbfffae33 , nextPtr=0xbfffad20) at xmlparse.c:2031 #10 0x0032df20 in XML_Parse (parser=0x1837d270, s=0xbfffad90 ?xml version=\1.0\?\ntrafficlist\n traffic include=\KLM/KLM.xml\/\n traffic include=\UAL/UAL.xml\/\n!-- traffic include=\test.xml\/ --\n/trafficlist, len=163, isFinal=-1073762765) at xmlparse.c:780 #11 0x0032ce74 in readXML(std::istream, XMLVisitor, std::string const) ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at /usr/include/gcc/darwin/3.3/c++/istream:236 #12 0x0032d2b8 in readXML(std::string const, XMLVisitor) ([EMAIL PROTECTED], [EMAIL PROTECTED]) at easyxml.cxx:261 #13 0x0001fb58 in fgInitSubsystems() () at /usr/include/gcc/darwin/3.3/c++/bits/stl_alloc.h:652 #14 0xec10 in fgIdleFunction() () at main.cxx:1423 #15 0x87521e18 in -[GLUTApplication run] () #16 0x8753bd28 in glutMainLoop () #17 0x00010d4c in fgMainInit(int, char**) (argc=1, argv=0x55d10c) at main.cxx:1795 #18 0xa8fc in main (argc=1, argv=0xbfffeef8) at bootstrap.cxx:175 Any pointers? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem on exiting ( was: Next release ofFlightGear )
That patch worked just fine. Hopefully it can be rolled into CVS
before the release.
Thanks!
Jonathan Polley
On Jul 18, 2004, at 7:40 AM, Frederic Bouvier wrote:
Frederic Bouvier wrote:
Jonathan Polley wrote:
Fred,
It turns out that the problem should exist on every FlightGear
system, not just the Mac. On exit(), fgExitCleanup() is called which
deletes the globals class and then calls fgOSExit(). The only thing
that fgOSExit() does is turn around and call exit(), which repeats
the
process. I changed fgExitCleanup() in main.cxx to be as follows:
void fgExitCleanup() {
delete globals;
//fgOSExit(0);
}
This prevented the recursive call to exit(), but will not work if
someone is using the fg_os_sld.cxx module, but it works for me.
I was suspecting that but was not able to reproduce this behavior on
windows.
What about this instead :
void fgExitCleanup() {
if ( globals ) {
delete globals;
globals = 0;
fgOSExit(0);
}
}
It will allow to call the function twice safely. Can you test that.
And what about this that might be better.
-Fred
--- main.cxx 15 Jul 2004 18:07:03 - 1.170
+++ main.cxx 18 Jul 2004 12:38:52 -
@@ -1495,7 +1495,6 @@
// which happens in the sound manager destructor.
void fgExitCleanup() {
delete globals;
-fgOSExit(0);
}
--- util.cxx 16 Mar 2004 20:19:08 - 1.7
+++ util.cxx 18 Jul 2004 12:35:38 -
@@ -27,6 +27,7 @@
#include simgear/debug/logstream.hxx
+#include fg_os.hxx
#include fg_io.hxx
#include fg_props.hxx
#include globals.hxx
@@ -107,7 +108,7 @@
SG_LOG(SG_GENERAL, SG_INFO, Exiting FlightGear with status
status);
globals-get_io()-shutdown_all();
-exit(status);
+fgOSExit(status);
}
___
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] Next release of FlightGear
Since there is a new release coming, I decided to bring the Mac version back up to date (I've been busy otherwise). When I exit FlightGear, I get the following errors (and crash). *** malloc[8626]: Deallocation of a pointer not malloced: 0x18bef000; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug *** malloc[8626]: Deallocation of a pointer not malloced: 0x18d8d000; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug *** malloc[8626]: Deallocation of a pointer not malloced: 0x141794c0; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug Using gdb gives me the following stack dump. Any ideas? Program received signal EXC_BAD_ACCESS, Could not access memory. 0x0002bec8 in FGGlobals::~FGGlobals() (this=0x6b3e830, __in_chrg=3) at globals.cxx:92 92 delete subsystem_mgr; (gdb) backtrace #0 0x0002bec8 in FGGlobals::~FGGlobals() (this=0x6b3e830, __in_chrg=3) at globals.cxx:92 #1 0xf178 in fgExitCleanup() () at main.cxx:1497 #2 0x9002c7b8 in exit () #3 0x00011224 in fgOSExit(int) (code=112624448) at fg_os.cxx:148 #4 0x9002c7b8 in exit () #5 0x0003d284 in fgExit(int) (status=0) at util.cxx:110 #6 0x00026c20 in do_exit(SGPropertyNode const*) (arg=0x55d070) at fg_commands.cxx:193 #7 0x00235178 in FGBinding::fire() const (this=0x2) at input.cxx:122 #8 0x00220de4 in action_callback(puObject*) (object=0x6b68340) at /usr/include/gcc/darwin/3.3/c++/bits/stl_vector.h:511 #9 0x00382d7c in puOneShot::doHit(int, int, int, int) (this=0x0, button=0, updown=1000, x=2013490264, y=0) at puOneShot.cxx:32 #10 0x0037d370 in puObject::checkHit(int, int, int, int) (this=0x19969a10, button=0, updown=1, x=429300720, y=2) at puObject.cxx:508 #11 0x0037a46c in puGroup::checkHit(int, int, int, int) (this=0x199697f0, button=0, updown=1, x=102, y=23) at puGroup.cxx:218 #12 0x0037a46c in puGroup::checkHit(int, int, int, int) (this=0x199683c0, button=0, updown=1, x=102, y=23) at puGroup.cxx:218 #13 0x0035c8a8 in puMouse(int, int, int, int) (button=0, updown=1, x=364, y=316) at pu.cxx:365 #14 0x00235ed4 in FGInput::doMouseClick(int, int, int, int) (this=0x18b85000, b=0, updown=1, x=364, y=316) at input.cxx:282 #15 0x875270e8 in -[GLUTView _commonMouseUp:] () #16 0x92e02cfc in -[NSWindow sendEvent:] () #17 0x87542600 in -[GLUTWindow sendEvent:] () #18 0x92df5324 in -[NSApplication sendEvent:] () #19 0x87521cc4 in -[GLUTApplication _runMainLoopUntilDate:autoreleasePool:] () #20 0x87521df4 in -[GLUTApplication run] () #21 0x8753bd28 in glutMainLoop () #22 0x00010b54 in fgMainInit(int, char**) (argc=1, argv=0x4ff198) at main.cxx:1779 #23 0xa8fc in main (argc=1, argv=0x8756216c) at bootstrap.cxx:175 Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Fred,
It turns out that the problem should exist on every FlightGear
system, not just the Mac. On exit(), fgExitCleanup() is called which
deletes the globals class and then calls fgOSExit(). The only thing
that fgOSExit() does is turn around and call exit(), which repeats the
process. I changed fgExitCleanup() in main.cxx to be as follows:
void fgExitCleanup() {
delete globals;
//fgOSExit(0);
}
This prevented the recursive call to exit(), but will not work if
someone is using the fg_os_sld.cxx module, but it works for me.
Thanks,
Jonathan Polley
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Fwd: Mac OS package problem]
Curt, I have fixed my inability to spell and the new archive can be gotten from: http://homepage.mac.com/eq_fidget/FlightGear-0.9.4.tgz Jonathan Polley On Jun 14, 2004, at 9:13 AM, Curtis L. Olson wrote: Forwarded to the devel list in hopes that a Mac developer can resolve this ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d From: Zulli, Louis P [EMAIL PROTECTED]> Date: June 11, 2004 4:03:56 AM CDT To: [EMAIL PROTECTED] Subject: Mac OS package problem Hi, I just downloaded the Mac OS X FlightGear package. The name of the resource file is spelled incorrectly, so unless the name is also spelled incorrectly in the symbolic link, the link is broken. Until I noticed the spelling error and corrected it, the app crashed at startup. Now all is well. So please change FlightGear_Resoruce to FlightGear_Resource in the distribution, and things should go more smoothly for Mac users. Thanks, L. Zulli ___ 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] Apple compilers
Jon, I couldn't find a reference to it in stdlib.h, or anywhere else in /usr/include. Jonathan Polley On May 25, 2004, at 3:45 PM, Jon S Berndt wrote: I'm not an Apple guy, so I can't test this for sure, but can someone tell me if it is still true that some Apple compilers that are used by FlightGear developers still do not have this function: inline char* gcvt (double value, int ndigits, char *buf) ?? Thanks, Jon ___ 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] Apple compilers
Oops, I also use gcc 3.3 under MacOS X 10.3.3 On May 25, 2004, at 6:17 PM, Jonathan Polley wrote: Jon, I couldn't find a reference to it in stdlib.h, or anywhere else in /usr/include. Jonathan Polley On May 25, 2004, at 3:45 PM, Jon S Berndt wrote: I'm not an Apple guy, so I can't test this for sure, but can someone tell me if it is still true that some Apple compilers that are used by FlightGear developers still do not have this function: inline char* gcvt (double value, int ndigits, char *buf) ?? Thanks, Jon ___ 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Mac OS version of 0.9.4 is Ready
Curt, I was able to find a clean Mac on which to try the FlightGear.app and it worked. I have uploaded a .tgz file containing the application, a sample resource file, a README file, and the base packages to my web page. It is 76MB and can be downloaded from http://homepage.mac.com/eq_fidget/FlightGear-0.9.4.tgz Let me know when it has been captured so I can reclaim the space. Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac OS version of 0.9.4
I would prefer to distribute the .app version, but I need someone to verify it for me. Just because it works for me does not mean that I created it properly. Come on Mac users, give it a try! :) When I use FlightGear, I have no choice but to use the .fgfsrc file. Unfortunately, because OS X is BSD based, all files that start with a dot are hidden by the Finder. I don't know of a good way to create the file and let people know how to edit it (what I did was create a file called FlightGear_Config and then make a symbolic link to it called .fgfsrc). If I create a disk image, I can put a README file in there along with the executable. I *MAY* be able to create a disk image that contains both the FlightGear application and the base package, but it will be close (I notice that the Win32 version is 82+ MB and I only have 100 MB of storage). Jonathan Polley On Tuesday, March 30, 2004, at 01:52PM, Curtis L. Olson [EMAIL PROTECTED] wrote: Jonathan, Thanks, please let me know when you think these are ready to copy to ftp server. Would it be preferable to just distribute the .app version? Is there any problems for poeple if we leave the file compressed? I assume they need to still download and install the base package (and specify it's location when they run fgfs.) How hard would it be to bundle up a mac version that includes the base package and the executable and is all self extracting/installing? Thanks, Curt. Jonathan Polley wrote: I am putting two FlightGear executables on my web page. The first is a standard UNIX-style executable and the second uses a .app wrapper (probably as close as I can come to an installer under MacOS, since it really doesn't use them). They were built under MacOS X 10.3.3. http://homepage.mac.com/eq_fidget/fgfs/fgfs.tgz http://homepage.mac.com/eq_fidget/fgfs/FlightGear.app.tgz I would really appreciate it if someone were to download both of them and give them a try. It's not that I am paranoid or anything :) Jonathan Polley On Mar 29, 2004, at 4:22 PM, Curtis L. Olson wrote: Jonathan Polley wrote: Curt, I just built one last night. I can strip it and put on my web space for you to pick up. Ok, thanks! By the way, do you or any other Mac developers have any thoughts on packaging FG in a MacOSX friendly installer (kind of like what we do for most of the other platforms?) Right now, most Mac people have a pretty tough time dealing with a binary that has to be executed from command line with command line options. It would be nice to get the fgrun launcher going on the Mac platform as well. This and better packaging could go a *long* ways towards making FG more Mac friendly. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ 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 -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac OS version of 0.9.4
Curt, I just built one last night. I can strip it and put on my web space for you to pick up. Jonathan Polley On Monday, March 29, 2004, at 03:19PM, Curtis L. Olson [EMAIL PROTECTED] wrote: Has anyone build a MacOS version of FG-0.9.4? Thanks, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac OS version of 0.9.4
I am putting two FlightGear executables on my web page. The first is a standard UNIX-style executable and the second uses a .app wrapper (probably as close as I can come to an installer under MacOS, since it really doesn't use them). They were built under MacOS X 10.3.3. http://homepage.mac.com/eq_fidget/fgfs/fgfs.tgz http://homepage.mac.com/eq_fidget/fgfs/FlightGear.app.tgz I would really appreciate it if someone were to download both of them and give them a try. It's not that I am paranoid or anything :) Jonathan Polley On Mar 29, 2004, at 4:22 PM, Curtis L. Olson wrote: Jonathan Polley wrote: Curt, I just built one last night. I can strip it and put on my web space for you to pick up. Ok, thanks! By the way, do you or any other Mac developers have any thoughts on packaging FG in a MacOSX friendly installer (kind of like what we do for most of the other platforms?) Right now, most Mac people have a pretty tough time dealing with a binary that has to be executed from command line with command line options. It would be nice to get the fgrun launcher going on the Mac platform as well. This and better packaging could go a *long* ways towards making FG more Mac friendly. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ 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
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] Cygwin Simgear issues
Norman,
That seemed to fix my problem. Off to finish the build.
Thanks!
Jonathan Polley
On Wednesday, March 17, 2004, at 11:30AM, Norman Vine [EMAIL PROTECTED] wrote:
$ cvs diff -u extensions.hxx 21 | tee diffs
Index: extensions.hxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/screen/extensions.hxx,v
retrieving revision 1.10
diff -u -r1.10 extensions.hxx
--- a/extensions.hxx17 Mar 2004 10:31:35 - 1.10
+++ b/extensions.hxx17 Mar 2004 17:24:30 -
@@ -24,10 +24,6 @@
#ifndef __SG_EXTENSIONS_HXX
#define __SG_EXTENSIONS_HXX 1
-#if !defined(WIN32)
-# include dlfcn.h
-#endif
-
#if defined(__CYGWIN__) /* !defined(USING_X) */
#define WIN32
#endif
@@ -36,6 +32,10 @@
# include windows.h
#endif
+#if !defined(WIN32)
+# include dlfcn.h
+#endif
+
#include GL/gl.h
@@ -57,7 +57,7 @@
inline void (*SGLookupFunction(const char *func))()
{
-#if defined( WIN32 ) !defined(__CYGWIN__) !defined(__MINGW32__)
+#if defined( WIN32 )
return (void (*)()) wglGetProcAddress(func);
#elif defined( __APPLE__ )
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Of COURSE they can do that. They're engineers!
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Problem Under Cygwin
I just updated to the latest changes in CVS. I got by my previous build error, only to have it crop up in xgl.c: make[3]: Leaving directory `/home/jwpolley/fgfs/SimGear/simgear/timing' Making all in xgl make[3]: Entering directory `/home/jwpolley/fgfs/SimGear/simgear/xgl' if gcc -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/sw/include -g -O2 -D _REENTRANT -MT xgl.o -MD -MP -MF .deps/xgl.Tpo \ -c -o xgl.o `test -f 'xgl.c' || echo './'`xgl.c; \ then mv -f .deps/xgl.Tpo .deps/xgl.Po; \ else rm -f .deps/xgl.Tpo; exit 1; \ fi In file included from xgl.h:14, from xgl.c:9: /usr/include/w32api/GL/glu.h:230: error: syntax error before '*' token make[3]: *** [xgl.o] Error 1 make[3]: Leaving directory `/home/jwpolley/fgfs/SimGear/simgear/xgl' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jwpolley/fgfs/SimGear/simgear' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/jwpolley/fgfs/SimGear/simgear' make: *** [all-recursive] Error 1 Thanks, Jonathan Polley On Tuesday, March 16, 2004, at 03:24AM, Erik Hofman [EMAIL PROTECTED] wrote: David Luff wrote: On 3/15/04 at 8:41 PM Jonathan Polley wrote: I just tried to build FlightGear under Cygwin. When I build, I get the following: In file included from glut_shapes.c:59: /usr/include/w32api/GL/glu.h:230: error: syntax error before '*' token In file included from glut_shapes.c:61: glut_shapes.h:12:1: warning: APIENTRY redefined I just comment the offending line in glut.h out, and it compiles fine then. I'm sure that's not the, erm, 'proper' solution though! I think I've put a proper patch in CVS. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Build Problem Under Cygwin
I just tried to build FlightGear under Cygwin. When I build, I get the following: In file included from glut_shapes.c:59: /usr/include/w32api/GL/glu.h:230: error: syntax error before '*' token In file included from glut_shapes.c:61: glut_shapes.h:12:1: warning: APIENTRY redefined In file included from /usr/include/w32api/GL/glu.h:37, from glut_shapes.c:59: /usr/include/w32api/GL/gl.h:80:1: warning: this is the location of the previous definition make[5]: *** [glut_shapes.o] Error 1 make[5]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear/scene/sky/cloud s3d' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear/scene/sky' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear/scene' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear' make: *** [all-recursive] Error 1 This is true even after I do a make clean. Thanks, Jonathan Polley Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Problem Under Cygwin
I deleted my cygwin installation and started from scratch (somehow, I had X installed previously). Unfortunately, even though I made sure that X11 was not installed, the problem didn't go away. plib builds just fine, it is just SimGear that is having a problem. I will try to fiddle around a bit more tomorrow. Thanks for the help, Jonathan Polley On Mar 15, 2004, at 9:46 PM, Jon Berndt wrote: Hopefully someone who knows the answer will jump in and correct me if I'm wrong, but this sounds like the errors people were getting when they installed the cygwin X11 packages. These provide conflicting versions of the opengl headers which cause the build to fail. I think the current solution is to uninstall the X11 packages (and possibly send a nice note off to the cygwin development team informing them that this needs to be addressed some day.) I don't recall running into this one, but it would not surprise me if something like this was the case. I've gotten some strange things happening with CygWin if I have KDE or the X11 packages installed AND I also have the DISPLAY environment variable set to something. It's been a long time, so I don't remember exactly what the case was. Jon ___ 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
[Flightgear-devel] Displaying FlightGear on a Plasma Display
I will be using FlightGear to give a demo, shortly. Unfortunately, the only display that I will have access to will be a plasma display (I am assuming that it is a plasma TV) rather than a projector. Can anyone give me an idea of how to configure the display portion of FlightGear so that it will not look stretched on the screen? Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaying FlightGear on a Plasma Display
Plasma TVs tend to be 1280x1024 at a 16:9 aspect ratio, rather than the 4:3 (or 1:1) that it would normally expect. I am assuming that I can just adjust the field of view, but will that only adjust the horizontal field or will it adjust the vertical as well? Thanks, Jonathan Polley On Mar 8, 2004, at 10:40 AM, Curtis L. Olson wrote: Jonathan Polley wrote: I will be using FlightGear to give a demo, shortly. Unfortunately, the only display that I will have access to will be a plasma display (I am assuming that it is a plasma TV) rather than a projector. Can anyone give me an idea of how to configure the display portion of FlightGear so that it will not look stretched on the screen? Assuming that a 100x100 pixel square on the screen looks square (i.e. your pixels are about the same height and width) then FG should take care of all of this for you. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ 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] Displaying FlightGear on a Plasma Display
Thanks for the input. I am on vacation this week and will try when I head back into work. Since we will be using a Windows PC, my range of options is limited. Jonathan Polley On Mar 8, 2004, at 11:35 AM, Erik Hofman wrote: Jonathan Polley wrote: Plasma TVs tend to be 1280x1024 at a 16:9 aspect ratio, rather than the 4:3 (or 1:1) that it would normally expect. I am assuming that I can just adjust the field of view, but will that only adjust the horizontal field or will it adjust the vertical as well? Use --geometry=1280x720 to set it to 16:9. I've used this on an of on my O2 and it works as expected. 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
[Flightgear-devel] MacOS X isnan() Fix
The fix for the MacOS isnan problem didn't compile. I changed it to be
inline int (isinf)(double r) { return isinf(r); }
inline int (isnan)(double r) { return isnan(r); }
and it worked just fine (it was Real r instead of double). Real wasn't
defined.
Thanks,
Jonathan Polley
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Not Building for MacOS X Because of isnan()
I have gotten back to updating FlightGear for MacOS X 10.3 and it appears as if there is a problem with isnan(). source='cloud.cxx' object='cloud.o' libtool=no \ depfile='.deps/cloud.Po' tmpdepfile='.deps/cloud.TPo' \ depmode=gcc3 /bin/sh ../../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../../simgear -I../../.. -I/sw/include -g -O2 -D_REENTRANT -c -o cloud.o `test -f 'cloud.cxx' || echo './'`cloud.cxx cloud.cxx: In member function `bool SGCloudLayer::reposition(float*, float*, double, double, double, double)': cloud.cxx:373: error: `isnan' undeclared (first use this function) cloud.cxx:373: error: (Each undeclared identifier is reported only once for each function it appears in.) make[5]: *** [cloud.o] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 For some reason, when iostream is included, it messes with the #include of math.h by undefining isnan(0, no matter the order of the include. In order for me to get cloud.cxx to build, I had to add the following lines after the #include of math.h #if defined (__APPLE__) #define isnan(x) (0) #endif As far as I can tell, isnan() is defined via math.h, but as soon as I include iostream things go south. I'm sure that this will cause me some problems in the future, but at least I have a build. Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.9.3 Mac OS X Build Available
Without that change, Local.h won't build under Panther, but it built just fine under Janguar (10.2). Unfortunately, the Mac on which I had both 10.1 and 10.2 installed is with my brother. If someone thinks it is important, I can *try* to walk him through the build process. Jonathan Polley On Sunday, November 23, 2003, at 01:05PM, Darrell Walisser [EMAIL PROTECTED] wrote: On Nov 23, 2003, at 1:01 PM, [EMAIL PROTECTED] wrote: === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/metar/Local.h,v retrieving revision 1.2 diff -u -r1.2 Local.h --- simgear/metar/Local.h 23 Jul 2003 09:59:39 - 1.2 +++ simgear/metar/Local.h 23 Nov 2003 01:38:09 - @@ -1107,7 +1107,7 @@ char *rptfmt(char *); char *rptfmti(char *, unsigned short int); -#ifndef __FreeBSD__ // strnstr is already defined on FreeBSD +#if !defined(__FreeBSD__) !defined(__APPLE__) // strnstr is already defined on FreeBSD / Darwin char *strnstr(char *, char *, size_t); #endif are you sure this one still works on previous versions of MacOS ? Not 100% sure, but pretty sure. Most of the unix layer in Mac OS X comes directly from BSD so I presume it had this function going all the way back to 10.0. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AI aircraft carrier
I did some playing around and made my aircraft model be the carrier. It looks kind of odd having that big ship flying around KSFO! Jonathan Polley On Saturday, November 15, 2003, at 08:15AM, David Culp [EMAIL PROTECTED] wrote: Ok, I got the Saratoga moving across San Fransisco bay at 30 knots. http://home.comcast.net/~davidculp2/saratoga_SFO_bay.jpg It can't be landed on because the deck is not solid (however you can fly inside and grab lunch). Is there a way to solidify the deck? Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Terrain Following
I have a need to develop a simulation of a terrain following system. The system is presented a flight corridor (start point, end point, and corridor width) and need to return the location, and elivation, of the highest point in that corridor. I remember seeing some discussion a while back concerning how to get the terrain elevation for random points, but didn't follow it too closely. Can anyone give me some information as to where I can start looking? On a related point (really, it is), if a company wanted to pay to have modifications made to FlightGear, is there anyone in the community that does this? The primary interest is for the terrain following system, but I would love to eventually have JSBSim modified so I could use it to drive some GPS and inertial simulations. First, I will need to test the water with the terrain system. Thanks, Jonathan Polley Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac OSX 10.3 (Panther) Build
I am using the standard makefiles to build the application. I was able to get FlightGear to run, but the change points to a compiler issue. Inside /simgear/scene/mataerial/matlib.cxx, there is a nested loop (for i= and then for j=) in the function gen_vasi_light_map(). When I put a printf after each for statement, FlightGear ran just fine. I am going to do some more experimentation to see what it really takes to get this to work. Jonathan Polley On Oct 28, 2003, at 3:12 AM, James Turner wrote: On Tuesday, October 28, 2003, at 04:57 AM, Jonathan Polley wrote: Oops, I sent this to the Users list instead. For those of us who use Macs, I just installed Panther on my machine. Just the OS upgrade increased my frame rate by about 15%. I am currently working through some compiler issues with Xcode and will let you know how well the new compiler works. I assume you're using your own project files? I've locally set up project files for PLIB, SimGear and FlightGear, and it all compiles, but it's dieing even earlier than you are, in glut initialization. Oh, and I'm still on Jaguar : I will rebuild once my copy of Jaguar turns up. I'm also still waiting to get my framework changes into PLIB ... HH James ___ 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
[Flightgear-devel] Mac OSX 10.3 (Panther) Build
Oops, I sent this to the Users list instead. For those of us who use Macs, I just installed Panther on my machine. Just the OS upgrade increased my frame rate by about 15%. I am currently working through some compiler issues with Xcode and will let you know how well the new compiler works. Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac OSX 10.3 (Panther) Build
Well, I got it built under Panther only to have it crash during
initialization. This is what I am seeing, can anyone give me an idea
as to what may be wrong? I cleaned everything via a 'make uninstall'
and 'make clean' before attempting to rebuild.
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x00298bd4 in gen_vasi_light_map() () at matlib.cxx:184
184 for ( int i = 0; i env_tex_res; ++i ) {
(gdb) backtrace
#0 0x00298bd4 in gen_vasi_light_map() () at matlib.cxx:184
#1 0x0029c868 in SGMaterialLib::load(std::string const, std::string
const) (this=0x5d1c4b0, [EMAIL PROTECTED], [EMAIL PROTECTED]) at
matlib.cxx:528
#2 0x000186e4 in fgInitSubsystems() () at
/sw/include/simgear/misc/sg_path.hxx:116
#3 0x64d0 in fgIdleFunction() () at main.cxx:1321
#4 0x87521e18 in -[GLUTApplication run] ()
#5 0x8753bd28 in glutMainLoop ()
#6 0x8b94 in fgMainInit(int, char**) (argc=1, argv=0x4f81f0) at
main.cxx:1761
#7 0x28b8 in main (argc=1, argv=0x5d1c4b0) at bootstrap.cxx:139
Thanks in advance,
Jonathan Polley
On Oct 27, 2003, at 10:57 PM, Jonathan Polley wrote:
Oops, I sent this to the Users list instead.
For those of us who use Macs, I just installed Panther on my machine.
Just the OS upgrade increased my frame rate by about 15%. I am
currently working through some compiler issues with Xcode and will let
you know how well the new compiler works.
Jonathan Polley
___
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] Question of Frame Rates
Actually, it is the buildings that cause a MAJOR throughput hit. Does anyone know how to turn them off (disabling random objects does not disable buildings)? If I use [EMAIL PROTECTED] as a benchmark, the new machine is about 3x faster than the old one. This is a G5 PowerMac with a Radeon 9600 Pro (64 MB RAM). My previous benchmark was to fly around Seattle, but I haven't transferred any of the terrain data to the new machine. FlightGear has always been a bad performer, IMHO, on the Mac and I don't have any of Darrell's performance improvement patches applied. I am curious to know what other people get for frame rates (both with and without buildigs). Jonathan Polley On Sunday, October 19, 2003, at 07:50 AM, Jim Wilson wrote: There are a lot of variables that can affect frame rate. The amount of video memory available is one of them. Within flightgear the type of aircraft and it's detail make some difference. You'll also see a drop (as I do) when the downtown area is within the view frustrum. If you want to compare notes with others you might want to specify your hardware and specific aircraft and view locations and directions. At startup with the aircraft sitting on the threshold you will notice changes in frame rate by changing the view direction to the right and left. Judging by the numbers I take it you are not running a GFX5800 on a 3Ghz P4. If you are, something is _really_ wrong :-) Best, Jim ___ 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] Question of Frame Rates
Fred, That does help my frame rates (the worst case rate went from 8FPS to 14), but I still have the structures being drawn. What I would like is something like --disable-structures (I looked and couldn't find one). Jonathan Polley p.s., I also had to set the LOD to be tiny (detailed=15, rough=90, bare=300) in order to get better rates. On Sunday, October 19, 2003, at 11:59 AM, Frederic Bouvier wrote: Jonathan Polley wrote: Actually, it is the buildings that cause a MAJOR throughput hit. Does anyone know how to turn them off (disabling random objects does not disable buildings)? You can tweak the following properties in preferences.xml : /sim/rendering/static-lod/detailed /sim/rendering/static-lod/rough /sim/rendering/static-lod/bare to modify the maximun distance detailed, rough or bare models are displayed. You must keep 0 detailed rough bare After the bare distance, nothing is displayed. Lower those values ( actually 1500, 9000 and 3 meters ) to improve framerate, increase them to get more details at distance. -Fred ___ 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] Question of Frame Rates
I had to re-login to my old machine to finish transferring some files. Here are the frame rates that the old Mac was giving (it is a single processor G4 running at 867 MHz, with 1 GB RAM, GeForce3 with 64 MB RAM). On tarmac = 8 FPS (compared to 20 with the new machine) Flying at the end of the runway = 23 FPS (as compared to 50 FPS) Heading right to follow the road = 8 FPS (as compared to 13) Crossing the hill = 4 FPS (as compared to 9) Flying through the city, toward the buildings = 3 FPS, worst case (as compared to 8) While these number are definitely better than the old machine, I am still curious about what PC and Linux people see (with buildings turned on, of course). Jonathan Polley p.s., these numbers match what I was seeing with [EMAIL PROTECTED] It is nice seeing two benchmarks yield similar results. On Sunday, October 19, 2003, at 04:32PM, Jonathan Polley [EMAIL PROTECTED] wrote: Fred, That does help my frame rates (the worst case rate went from 8FPS to 14), but I still have the structures being drawn. What I would like is something like --disable-structures (I looked and couldn't find one). Jonathan Polley p.s., I also had to set the LOD to be tiny (detailed=15, rough=90, bare=300) in order to get better rates. On Sunday, October 19, 2003, at 11:59 AM, Frederic Bouvier wrote: Jonathan Polley wrote: Actually, it is the buildings that cause a MAJOR throughput hit. Does anyone know how to turn them off (disabling random objects does not disable buildings)? You can tweak the following properties in preferences.xml : /sim/rendering/static-lod/detailed /sim/rendering/static-lod/rough /sim/rendering/static-lod/bare to modify the maximun distance detailed, rough or bare models are displayed. You must keep 0 detailed rough bare After the bare distance, nothing is displayed. Lower those values ( actually 1500, 9000 and 3 meters ) to improve framerate, increase them to get more details at distance. -Fred ___ 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 Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question of Frame Rates
Fred, I just ran FlightGear on my PC (built with cygwin under Windows) and got some numbers similar to yours (I was running at 800x600 window size). That leads me to ask for some clarification, when I say buildings, I mean this (http://homepage.mac.com/eq_fidget/mac_fgfs.jpg) and not this (http://homepage.mac.com/eq_fidget/win_fgfs.jpg). Do you have the same definition? I know how to eliminate buildings in the later case (--disable-random-objects) but not the former. Jonathan Polley On Sunday, October 19, 2003, at 05:38 PM, Frederic Bouvier wrote: Jonathan Polley wrote: I had to re-login to my old machine to finish transferring some files. Here are the frame rates that the old Mac was giving (it is a single processor G4 running at 867 MHz, with 1 GB RAM, GeForce3 with 64 MB RAM). On tarmac = 8 FPS (compared to 20 with the new machine) Flying at the end of the runway = 23 FPS (as compared to 50 FPS) Heading right to follow the road = 8 FPS (as compared to 13) Crossing the hill = 4 FPS (as compared to 9) Flying through the city, toward the buildings = 3 FPS, worst case (as compared to 8) While these number are definitely better than the old machine, I am still curious about what PC and Linux people see (with buildings turned on, of course). With an Athlon XP2400+ and a GeFX5900, I get 23fps on the city, with 2d clouds. It was 21fps with Athlon XP1800+ and Ge3 Ti200 The screen size is 1280x1024 with defaut lod settings. -Fred ___ 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
[Flightgear-devel] CygWin Build Failure
After a short break, I decided to try to rebuild FlightGear under CygWin. While building SimGear, I got the following errors: /sw/lib/libplibnet.a(netSocket.o.b)(.eh_frame+0x11): In function `_ZN10netAddressC1EPKci': /home/Jonathan Polley/fgdev/plib/src/net/netSocket.cxx:59: undefined reference to `___gxx_personality_v0' I deleted everything (plib, SimGear source and all installed headers and libraries) and built from scratch. I still have the problem. Any ideas? Thanks, Jonathan Polley Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MacOS X port, and linuxworld
I keep FlightGear built for my Mac and the only changes required against CVS are all in plib (and have to do with the joystick interface). Let me know and I'll email the files to you. cvs server: Updating src/js M src/js/js.h M src/js/jsMacOSX.cxx Darrell Walisser is the official maintainer of the OS X port, and he has been working on getting ProjectBuilder projects put together for FlightGear and I'm not sure of its current state. You can use the standard Apple development tools to build FlightGear just as you would on any Linux platform. Jonathan Polley On Friday, August 22, 2003, at 09:20 PM, Randy Locklair wrote: Hey there. My name's Randy Locklair, I'm a student pilot and a long time developer and I joined the list to find out a couple of things. First of all I'd like to know what the status is of the MacOS port. I mainly use os X lately and I'd like to get involved. If no one is running the show I'd be happy to take over. Also, I read somewhere about you guys being at the .org pavillion at LinuxWorld. I don't know who organizes that or if anyone is planning to for January 2004 in New York, but I'd be happy to organize/help with that too. Nice to meet you all and hopefully I can get involved soon! Who ever is involved with the two above things get in touch with me on this email address or on the list :) Randy ___ 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] MacOS X port, and linuxworld
On Friday, August 22, 2003, at 10:01PM, Curtis L. Olson [EMAIL PROTECTED] wrote: Randy Locklair writes: My name's Randy Locklair, I'm a student pilot and a long time developer and I joined the list to find out a couple of things. Hi Randy, First of all I'd like to know what the status is of the MacOS port. I mainly use os X lately and I'd like to get involved. If no one is running the show I'd be happy to take over. The last Mac OS X build that I'm aware of was for version 0.8.0. Right now we are at version 0.9.2 for the most recent official release, but I haven't seen a Mac build yet. :-( Darrel Walliser submitted a link to the MacOS X version of 0.9.2 on June 19 (http://seneca.me.umn.edu/pipermail/flightgear-devel/2003-June/018246.html) You can pull down the application from his web page (http://homepage.mac.com/walisser). Its under the Free Downloads section. Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Build Problem for MacOS X
I have been remiss in my duties of keeping FlightGear up to date under MacOS X (something to do with work). I finally had a chance to build everything again and hit a problem with the 3D cloud code. After much gnashing of teeth, I was able to get simgear/scene/sky/clouds3d/SkyContext.cpp to build. Here are the differences. SkyContext.dif Description: video/dv The last time I tried the 3D cloud code on the Mac, there seemed to be an endian issue. Does anyone know if the problem still exists? Should I give it a try and see if it blows up? I haven't gotten to the point of getting FlightGear up and running again (I just started a little while ago), but I'll yell if there are any problems. Thanks, Jonathan Polley___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Problem for MacOS X
Well, I got FlightGear to build and run again so I tried the 3d clouds. I got the
following backtrace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x0027d884 in SkySceneLoader::Load(SGPath, double, double) (this=0x1017dac0,
filename=Cannot access memory at address 0x642900b0
{path = {static npos = 4294967295, _M_dataplus = {allocatorchar = {No data
fields}, _M_p = 0x642900b0 Address 0x642900b0 out of bounds}, static
_S_empty_rep_storage = {0, 0, 193, 0}}}, latitude=37.611701420942723,
longitude=-122.35840743978396) at SkySingleton.hpp:125
125 static T* InstancePtr() { assert(s_pInstance); return s_pInstance; }
(gdb) backtrace
#0 0x0027d884 in SkySceneLoader::Load(SGPath, double, double) (this=0x1017dac0,
filename={path = {static npos = 4294967295, _M_dataplus = {allocatorchar = {No
data fields}, _M_p = 0x642900b0 Address 0x642900b0 out of bounds}, static
_S_empty_rep_storage = {0, 0, 193, 0}}}, latitude=37.611701420942723,
longitude=-122.35840743978396) at SkySingleton.hpp:125
Cannot access memory at address 0x642900b0
Can anyone help me to determine what is going wrong (why _M_p has a bad value)?
Thanks,
Jonathan Polley
On Monday, August 18, 2003, at 10:26PM, Jonathan Polley [EMAIL PROTECTED] wrote:
The last time I tried the 3D cloud code on the Mac, there seemed to be
an endian issue. Does anyone know if the problem still exists? Should
I give it a try and see if it blows up?
Of COURSE they can do that. They're engineers!
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Networking
Paul, I have used the UDP interface for the remote display, but I believe that it can use either. I realy prefer UDP since it has let network overhead, and if a packet gets lost you won't be held up waiting for the retransmission. That said, if you are on a noisy network you may have to use TCP. Jonathan Polley On Sunday, August 03, 2003, at 04:06PM, Paul Morriss [EMAIL PROTECTED] wrote: Hi all, Does flightgear use UDP (connection-less) or connect oriented in the networking code? Also do you feel that UDP is good enough for network gaming. Thanks Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Networking
If you are on a local network I would say go head and use UDP. If you need to span a corporate or university network (or the internet) then the chance for packet loss gets too high for my comfort and would revert back to TCP. When I have used UDP it has been isolated to a single subnet or well controlled set of subnets. Also, look at the network loading. IMHO, if your network loading is 30% then I would mark it as unreliable for UDP. Jonathan Polley p.s. for CDMA networks (10base2, 10base5, and 10baseT using a hub), the rule of thumb was: if your wire is 20% loaded it is saturated. On Sunday, August 3, 2003, at 04:43 PM, Paul Morriss wrote: I was think considering the choice of network protocol for a scenario server I am considering (see old posts for more details), I am not sure if fire it and hope for the best is the best system for a scenario server. I would have suggested broadcasting but I found a higher probability of network storms in prior implementations. Thoughts? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MacOS X binaries (was Win32 binaries)
On Tuesday, July 01, 2003, at 02:19PM, Curtis L. Olson [EMAIL PROTECTED] wrote: The MacOS X version is severly lagging though ... it is still back at 0.8.0. Are there any MacOS developers out there who would be willing to build a 0.9.2 version for MacOS X? Darrell has a 10.2 application built (reference http://seneca.me.umn.edu/pipermail/flightgear-devel/2003-June/018246.html). He has sent me his modified files so I can build the 10.1 version of FlightGear. Now if I can just find the time... Jonathan Polley Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] native-ctrls wire format ?
On Tuesday, June 24, 2003, at 11:53AM, Martin Spott [EMAIL PROTECTED] wrote: Curtis L. Olson [EMAIL PROTECTED] wrote: The structure is defined in src/Network/net_ctrls.hxx Yep, I already read this, but I'm not shure about the the data format of the values I have to put in there. I assume the bools have exactly one bit anytime but how large are the variable values or with other words: Won't I have to worry about the platform FlightGear is currently running on ? I suspect 'double' and 'int' will differ and the whole stuff depends on the CPU's byte order, so I have to take serious bit-shifting into account, when running the application on different platforms. By default, everything that is transferred is done so in network format (big-endian). IMNSHO, sending data in any other format is asking for trouble (i.e., how can I send data from my PowerPC to my x86 box if it is not in network format). Look at source/src/Network/native_ctrls.cxx to see how the data is processed. The sizes are: Boolean = 8-bits Integer = 32-bits Float = 32-bits Double = 64-bits Don't forget data elignment. The C/C++ compiler will pad data so that is alighed per the processor's architecture. This means that an array of three bytes that is followed by an integer will *MOST LIKELY* have a hidden fourth byte applied after the array and before the integer. The compiler will align data on its native boundary (i.e., 32-bit numbers will start on a 32-bit boundary). Is an EOL the correct ending of a set of control data over a socket or serial line ? Don't send any line termination. What is being received over the network is a stream of bytes, not text. When the receiver has enough data, it will be processed. Jonathan Polley Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] screen/extensions.cxx Does not Build
When I try to build under both MacOS X and Windows, I get the following errors in screen/extensions.cxx In file included from extensions.cxx:31: extensions.hxx: In function `void (* SGLookupFunction(const char*))()': extensions.hxx:58: `glXGetProcAddressARB' undeclared (first use this function) extensions.hxx:58: (Each undeclared identifier is reported only once for each function it appears in.) Could someone put the non-GLX version of GetProcAddressARB in the file? Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 64-Bit Question
Now that 64-bit processors are becoming more available, does anyone know of any problems that FlightGear may have running on a 64-bit processor (Opteron or PowerPC 970)? I am assuming that those areas that would be sensitive to data sizes (i.e., file formats) are safe? Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Cygwin Build Problem
I just updated to the latest SimGear and had to make a mod to
simgear/scene/tgdb/obj.cxx. I had to add a #define of NOMINMAX before the #include of
simgear/bucket/newbucket.hxx, otherwise I got the following error:
In file included from /usr/include/c++/3.2/bits/locale_facets.tcc:43,
from /usr/include/c++/3.2/locale:46,
from /usr/include/c++/3.2/bits/ostream.tcc:37,
from /usr/include/c++/3.2/ostream:275,
from /usr/include/c++/3.2/iostream:45,
from ../../../simgear/bucket/newbucket.hxx:44,
from obj.cxx:33:
/usr/include/c++/3.2/limits:942:22: macro min requires 2 arguments, but only 1
given
In file included from /usr/include/c++/3.2/bits/locale_facets.tcc:43,
from /usr/include/c++/3.2/locale:46,
from /usr/include/c++/3.2/bits/ostream.tcc:37,
from /usr/include/c++/3.2/ostream:275,
from /usr/include/c++/3.2/iostream:45,
from ../../../simgear/bucket/newbucket.hxx:44,
from obj.cxx:36:
/usr/include/c++/3.2/limits:942: parse error before `throw'
/usr/include/c++/3.2/limits:943:22: macro max requires 2 arguments, but only 1 given
/usr/include/c++/3.2/limits:943: ISO C++ forbids defining types within return type
/usr/include/c++/3.2/limits:943: syntax error before `throw'
/usr/include/c++/3.2/limits:943: syntax error before `throw'
/usr/include/c++/3.2/limits:944: syntax error before `(' token
/usr/include/c++/3.2/limits:945: syntax error before `(' token
/usr/include/c++/3.2/limits:946: syntax error before `(' token
/usr/include/c++/3.2/limits:947: syntax error before `(' token
/usr/include/c++/3.2/limits:948: syntax error before `(' token
/usr/include/c++/3.2/limits:949: syntax error before `(' token
/usr/include/c++/3.2/limits:956: `numeric_limits' is not a template
/usr/include/c++/3.2/limits:957: confused by earlier errors, bailing out
make: *** [obj.o] Error 1
Tha MacOS X version built just fine.
Jonathan Polley
Of COURSE they can do that. They're engineers!
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Visual C++ 6.0, some problem's with metakit
Bodo, Are you building from CVS or are you building the last release tarball? I have an older CVS snapshot of FlightGear (about a month old) and can't find that file. What is the path to the file? Jonathan Polley On Friday, April 11, 2003, at 04:38 PM, [EMAIL PROTECTED] wrote: Jonathan Polley [EMAIL PROTECTED] schrieb am 11.04.2003, 23:12:06: Bodo, Make sure that you are running service pack 3 or later. The older service packs have a few issues. Jonathan Polley Jonathan, thank you very much. I downloaded Service Pack 5, and got a liitle further... I got now an error message that the function max is not a member of the namespace std ( Filename : fgjsbase.h, line 75 ) Thank's again Bodo ___ 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] [OT] The End of Python
I am waiting for the programming language for amateur radio operators, Morse. There is nothing like programming in dots and dashes! On Tuesday, April 1, 2003, at 06:11 AM, David Megginson wrote: It looks like Python's days are numbered; I just read on Slashdot about a programming language that uses *only* whitespace: http://compsoc.dur.ac.uk/whitespace/ I expect that most current Python programmers will have switched over by the end of the year. Any die-hard fanatics left over will no doubt write a Punctuation programming language, using only the characters [EMAIL PROTECTED]*() (above 0-9 on the U.S. keyboard), as a pure act of spite to try to split the Perl community. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ 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] where in the world is glut.h
What is your system? If you have Windows then you will need to build GLUT on your own. GLUT should come with MESA (or the OpenGL drivers of your video card) under Linux (at least that's how I get it). Jonathan Polley On Wednesday, March 26, 2003, at 11:02 PM, Howell Caton wrote: Hi! I'm having a few teething problems installing Flightgear. Right now I'm puzzled because I don't have glut.h on my system. Shouldn't it come with glut3.7-8. thanks! ___ 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
[Flightgear-devel] Future MacOS X Support
I don't mean to scare anybody, but this has to do with the upcoming Panther release (10.3). With the release of Panther, I will be dumping my 10.1 partition and won't be building FlightGear for MacOS X 10.1, although I don't keep it current right now, in favor of maintaining 10.2 and 10.3 partitions. Will we be dropping official support for 10.1 at that time (or any time soon)? Just curious, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Disabling the 3D Panel
Now that I have FlightGear linking, I have found another problem that has cropped up recently (I'm not sure when, exactly). It seems as if the 3D panel is always active. Since I always run FlightGear with the --disable-panel in my .fgfsrc file, this causes problems. If I don't run with --disable-panel, I get the same behavior. I have verified that options.cxx still processes --disable-panel. If I toggle the 2D panel from within FlightGear, I get the 2D panel placed in front of the 3D panel. Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Still linker error in today's FlightGear
In my case, I don't want any of the multi-pilot code in my build. For some reason, as of yesterday, src/MultiPlayer is required for the build (--with-network is defaulted to yes). If it requires that I build with --with-network-olk then this is a very bad thing (IMHO) because I don't believe that code works on all platforms. At the very least, it would be nice if all the required switches were defaulted to the same values. Jonathan Polley On Thursday, March 20, 2003, at 11:26 PM, Martin Spott wrote: Hello Erik, Erik Hofman [EMAIL PROTECTED] wrote: Martin Spott wrote: Hello, today I encountered linker errors on SuSE-8.1/i386. As I understand this does not depend on the tool chain: Did you already try this: You will either have to do a make clean or remove the following files by hand: Oh, I'm no more a newbie in pushing other people's stuff through the compiler ;-) I even remade the whole build directory (including those of metakit, plib and SimGear). You can assume that I built everything from current CVS before reporting an error. Obviously some of the linker errors I posted result of missing references in the NetworkOLK stuff. Probably something resides outside the NetworkOLK directory and now it misses references because it does not get disabled at compile time like the rest of this stuff. I'll see what happens if I include NetworkOLK, 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 mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Build Problem with MultiPlayer Code
Under MacOS X (and I assume other OSes as well), both multiplaytxmgr.cxx and multiplayrxmgr.cxx need to include sys/types.h before including sys/socket.h. Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Problem with MultiPlayer Code
Oh, and it will not link because of the following missing symbols: ld: Undefined symbols: _FGFS_host fg_net_init(ssgRoot*) fgd_send_com(char*, char*) _fgd_mcp_ip _head _net_is_registered _other _tail _net_hud_display net_hud_update() NewNetIdInit() NewNetFGDInit() NewCallSign(puObject*) net_fgd_scan(puObject*) Could someone either back out the changes or add the files needed to get it running again? Thanks, Jonathan Polley On Wednesday, March 19, 2003, at 10:38 PM, Jonathan Polley wrote: Under MacOS X (and I assume other OSes as well), both multiplaytxmgr.cxx and multiplayrxmgr.cxx need to include sys/types.h before including sys/socket.h. Jonathan Polley ___ 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] Speed Bottlenecks in FlightGear
I have been using the remote display interface for quite some time, using a proprietary aircraft model. Since the frame rates were basically the same as when I was using an internal model, I expected that the CPU usage was not impacted by that component. Does anyone know if it is the actual rendering of the display that is taking the time, or is it the math required to process the scene graph? Would using SSE/SSE2/AltiVec for the matrix operations make much of a difference? Jonathan Polley On Monday, February 24, 2003, at 03:04AM, Erik Hofman [EMAIL PROTECTED] wrote: Jonathan Polley wrote: Hello all, I am asking this question from the standpoint of the benefits of a dual-processor computer in running FlightGear. Enabling threading will yield more stable frame rates, but how much work can be offloaded onto the second processor? Is it save to guess that if I were to move all non-display processing to its own processor that I wouldn't see much, if any, improvement in frame rate? That being said, What would it take to squeeze the last bit of FPS out of FlightGear? This is related to your graphics hardware. If the hardware is able to do everything hardware accelerated, I don't see much speed improvement in splitting up tasks between processors. One thing you could try is running JSBSim on the same machine in stand alone mode and connect it to FlightGear using the network interface (is this already possible)? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Speed Bottlenecks in FlightGear
Hello all, I am asking this question from the standpoint of the benefits of a dual-processor computer in running FlightGear. Enabling threading will yield more stable frame rates, but how much work can be offloaded onto the second processor? Is it save to guess that if I were to move all non-display processing to its own processor that I wouldn't see much, if any, improvement in frame rate? That being said, What would it take to squeeze the last bit of FPS out of FlightGear? Just some idle thoughts, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate Symbols in FGTurbine?
I did a make distclean; autogen.sh; ./configure; make and I still have the problem. I'm not too worried since I am using the UFO FDM and it does not prevent me from getting an executable. It is odd that the problem even showed up, but we'll see. Maybe Apple will upgrade their developer tools to gcc 3.2 on the next release. Thanks for the help, Jonathan Polley On Monday, February 10, 2003, at 09:39 PM, Norman Vine wrote: Jonathan Polley writes: It beats me. I did a make clean and make distclean and both yielded the same results as before. The current development tools contain gcc 3.1. Is anyone else running that version of gcc, or has everyone jumped to 3.2? Hmm... You could try deleting the JSBSim directory then try the desparate man's approach % cvs up % autogen.sh; ./configure; make if that doesn't work then you have got me stumped too Norman ___ 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: xml property documentation
I tried adding comments to the preferences.xml file, but they were not rolled into CVS. The problem, and I believe why my edits didn't make CVS, is that commenting each attribute causes diff to believe the entire file has changed. This makes it difficult for those people who have tailored .xml files. I would really like the .xml files to be fully commented (I'm strange that way), but I'm not going to hold my breath. Jonathan Polley On Monday, February 10, 2003, at 08:01 AM, Erez Boym wrote: Hi, Did anyone start to document these properties in another way, or do we have no documentation about these xml properties ? Erez We had a discussion about this subject a few weeks back and came to the conclusion that automatic generation of the property lists probably won't give the desired result. If you insist on using this approach, you can find the xml parser in the simgear/xml directory of SimGear (esp. easyxml.?xx). Erik __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ 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
[Flightgear-devel] Duplicate Symbols in FGTurbine?
When building on MacOS X, I got the following warnings. Since I don't use JSBSim too much, I wasn't too worried. Jonathan Polley ranlib: same symbol defined in more than one member in: libJSBSim.a (table of contents will not be sorted) ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine11doBleedDuctEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine11doBleedDuctEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine11doCombustorEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine11doCombustorEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine12doCompressorEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine12doCompressorEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine12doTransitionEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine12doTransitionEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine18doConvergingNozzleEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine18doConvergingNozzleEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine22ThrottleToPowerCommandEd ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine22ThrottleToPowerCommandEd ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine4LoadEPNS_12FGConfigFileE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine4LoadEPNS_12FGConfigFileE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine4rtauEd ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine4rtauEd ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine5DebugEi ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine5DebugEi ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine7doInletEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine7doInletEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine8PowerLagEdd ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine8PowerLagEdd ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine9CalculateEd ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine9CalculateEd ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine9doTurbineEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine9doTurbineEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineC1EPNS_9FGFDMExecEPNS_12FGConfigFileE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineC1EPNS_9FGFDMExecEPNS_12FGConfigFileE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineC2EPNS_9FGFDMExecEPNS_12FGConfigFileE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineC2EPNS_9FGFDMExecEPNS_12FGConfigFileE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineC4EPNS_9FGFDMExecEPNS_12FGConfigFileE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineC4EPNS_9FGFDMExecEPNS_12FGConfigFileE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineD0Ev ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineD0Ev ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineD1Ev ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineD1Ev ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineD2Ev ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineD2Ev ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineD4Ev ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineD4Ev ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZTVN6JSBSim9FGTurbineE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZTVN6JSBSim9FGTurbineE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate Symbols in FGTurbine?
I have the latest and greatest from CVS. I ran ./autogen.sh and ./configure, without any change. Is there something that I can do to force a rebuild (aside from deleting the Makefiles by hand, that is). Thanks, Jonathan Polley On Monday, February 10, 2003, at 08:11 PM, Jon Berndt wrote: When building on MacOS X, I got the following warnings. Since I don't use JSBSim too much, I wasn't too worried. Jonathan Polley ranlib: same symbol defined in more than one member in: libJSBSim.a (table of contents will not be sorted) ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine11doBleedDuctEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine11doBleedDuctEv I'm wondering if you have a Makefile that is correct ... ? Jon JON S. BERNDT Coordinator, JSBSim Project www.JSBSim.org [EMAIL PROTECTED] smime.p7s ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate Symbols in FGTurbine?
It beats me. I did a make clean and make distclean and both yielded the same results as before. The current development tools contain gcc 3.1. Is anyone else running that version of gcc, or has everyone jumped to 3.2? Thanks, Jonathan Polley On Monday, February 10, 2003, at 09:04 PM, Norman Vine wrote: Jon Berndt writes: I have the latest and greatest from CVS. I ran ./autogen.sh and ./configure, without any change. Is there something that I can do to force a rebuild (aside from deleting the Makefiles by hand, that is). Delete all the .o files, and the libJSBSim.a, and libfiltersjb.a files. This will cause a rebuild of the JSBSim code. If you want to rebuild the make files ... I don't know. try % make distclean % autogen.sh % ./configure % make Norman ___ 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] CVS FlightGear and plib 1.6 (was Mac OS X: at a loss)
Hmm, that's odd. Out of the box, the version of the Mac joystick code that is in CVS does not compile. As I reported to the plib group, if I incorporate the non-CVS versions of jsMacOSX.cxx and js.h, I get the following errors in the FlightGear joystick code: ld: Undefined symbols: jsJoystick::read(int*, float*) _CFArrayApplyFunction _CFArrayGetCount _CFArrayGetTypeID _CFDictionaryGetTypeID _CFDictionaryGetValue _CFGetTypeID _CFNumberGetValue _CFRelease _CFStringGetCString _CFStringGetSystemEncoding _CFUUIDGetConstantUUIDWithBytes _CFUUIDGetUUIDBytes _IOCreatePlugInInterfaceForService _IOIteratorNext _IOIteratorReset _IOMasterPort _IOObjectRelease _IORegistryEntryCreateCFProperties _IOServiceGetMatchingServices _IOServiceMatching ___CFStringMakeConstantString _kCFAllocatorDefault I've been trying to help David Drum get his FlightGear to build and he discovered that adding -framework Carbon to the Makefile reduces the link errors down to ld: /Users/david/FlightGear/FlightGear-CVS/lib/libplibjs.a(jsMacOSX.o) illegal reference to symbol: _IOCreatePlugInInterfaceForService defined in indirectly referenced dynamic library /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit If I restore the plib code back to 1.6, then I can finally get a link. Since I don't use a joystick, that works for me. Jonathan Polley On Wednesday, February 5, 2003, at 07:48 AM, James Turner wrote: On Wednesday, February 5, 2003, at 01:22 pm, Jonathan Polley wrote: The solution, for me at least, was to revert back to the CVS version of plib and overwrite the src/js directory with plib 1.6's (as the current Mac joystick code is in a major broken state). Hopefully, David will have a chance to see if it fixes his build problem as well. Err, the JS code is fine for me now (and for Ima too, I think), once you replace js.h and jsMacOSX.cxx with the ones I posted to plib-devel a few days ago. If these do not fix any problems you're having, then **please** post something to plib-devel or email me directly. Since getting things checked into plib CVS seems to be rather slow, I'd rather get the files confirmed working for people before requesting another commit. FWIW, CVS of 'everything' is working on my iBook, updated today, but I have a bunch of local mods to simgear/flightgear (in addition to the plib JS updates) : let me know if you want them. (I'll start feeding them to Curt / David soonish anyway I think) HH James -- They are laughing with me, not at me. ___ 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] Question about Mac os X 10.2 fg development
Ima, I would use version 1.6 of plib. I have not been able to get the latest CVS to build for me (there is a problem with the new joystick code for MacOS X). The only other change I have is a minor tweak to src/ssg/ssgVtxTable.cxx for some performance improvements. I have never tried to build Atlas, so I'm not sure of its status WTR MacOS 1X 10.2. It wouldn't surprise me if there were problems. Jonathan Polley On Friday, January 17, 2003, at 09:23 PM, Ima Sudonim wrote: Is the new version of PLIB required or optional for the fg source downloaded from cvs by the latest changes? Are there any changes to the SL directory that are required by flightgear? Also, does anyone know where I can find Atlas (specifically the atlas viewer) binaries to work with fg? Or whether I can use the opengl and GLUT support in macos x 10.2 with atlas source from atlas.sourceforge.net? The atlas configure script can't seem to find it and I don't know how to point it in the right direction (building from the command line using gcc 2.95) Thanks, Ima ___ 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] Build Problem with MSVC 6.0
Dave, Worked like a champ. A few more instances of this have turned up, and I can supply diffs if you are interested. Thanks, Jonathan Polley On Friday, January 17, 2003, at 10:39 AM, David Luff wrote: Jonathan, I've got behind reading my mail from this list, and I've only just read this mail from a while ago about this and the later error you had in ATCVoice.cxx. I've commited Norman's fixes for both files to the cvs, so if you could do a clean checkout of the ATC subdirectory and check I haven't missed anything that would be great. Cheers - Dave Norman Vine writes: Jonathan Polley writes: Second, I got an error in src/ATC/tower.hxx. typedef list TowerPlaneRec* tower_plane_rec_list_type; typedef list TowerPlaneRec* ::iterator tower_plane_rec_list_iterator; typedef list TowerPlaneRec* ::const_iterator tower_plane_rec_list_const_iterator; generates: c:\fgdev\flightgear\src\atc\tower.hxx(72) : error C2653: 'listclass TowerPlaneRec *,class std::allocatorclass TowerPlaneRec * ' : is not a class or namespace name c:\fgdev\flightgear\src\atc\tower.hxx(72) : error C2146: syntax error : missing ';' before identifier 'tower_plane_rec_list_iterator' Yes, I know that MSVC has its share of problems with templates, but is there a work around for this? here is a shot in the dark typedef list TowerPlaneRec* tower_plane_rec_list_type; typedef tower_plane_rec_list_type::iterator tower_plane_rec_list_iterator; typedef tower_plane_rec_list_type::const_iterator tower_plane_rec_list_const_iterator; HTH Norman ___ 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] MSVC Build Problems in src/Main/main.cxx
For those who may care, I fixed the MacOS problems. It turns out that the OpenGL Extension that FlightGear are referencing have ARB extensions rather than EXT. I.e., glPointParameterfvEXT glPointParameterfEXT becomes glPointParameterfvARB glPointParameterfARB Jonathan Polley Here is the CVS diff. Index: main.cxx === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v retrieving revision 1.53 diff -r1.53 main.cxx 53a54,58 #if defined (__APPLE__) #define GL_SGIS_point_parameters 1 #include OpenGL/glext.h #endif 748a754,757 #if defined (__APPLE__) glPointParameterfvARB(GL_DISTANCE_ATTENUATION_EXT, quadratic); glPointParameterfARB(GL_POINT_SIZE_MIN_EXT, 1.0); #else 750c759,760 glPointParameterfEXT(GL_POINT_SIZE_MIN_EXT, 1.0); --- glPointParameterfEXT(GL_POINT_SIZE_MIN_EXT, 1.0); #endif 792a803,806 #if defined (__APPLE__) glPointParameterfvARB(GL_DISTANCE_ATTENUATION_EXT, default_attenuation); #else 794a809 #endif ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Another MSVC Problem
I just did a rebuild after updating to, and incorporating, the latest extgl.* changes. MSVC is now complaining about the 'SG_USING_STD(find)' line in src\Model\modelmgr.cxx. c:\fgdev\flightgear\src\model\modelmgr.cxx(136) : error C2653: 'vectorstruct FGModelMgr::Instance *,class std::allocatorstruct FGModelMgr::Instance * ' : is not a class or namespace name c:\fgdev\flightgear\src\model\modelmgr.cxx(136) : error C2065: 'iterator' : undeclared identifier c:\fgdev\flightgear\src\model\modelmgr.cxx(136) : error C2146: syntax error : missing ';' before identifier 'it' c:\fgdev\flightgear\src\model\modelmgr.cxx(136) : error C2065: 'it' : undeclared identifier c:\fgdev\flightgear\src\model\modelmgr.cxx(137) : error C2440: '=' : cannot convert from 'struct FGModelMgr::Instance ** ' to 'int' This conversion requires a reinterpret_cast, a C-style cast or function-style cast c:\fgdev\flightgear\src\model\modelmgr.cxx(137) : error C2446: '!=' : no conversion from 'struct FGModelMgr::Instance ** ' to 'int' This conversion requires a reinterpret_cast, a C-style cast or function-style cast c:\fgdev\flightgear\src\model\modelmgr.cxx(137) : error C2040: '!=' : 'int' differs in levels of indirection from 'struct FGModelMgr::Instance ** ' c:\fgdev\flightgear\src\model\modelmgr.cxx(138) : error C2100: illegal indirection c:\fgdev\flightgear\src\model\modelmgr.cxx(138) : error C2446: '==' : no conversion from 'struct FGModelMgr::Instance *' to 'int' This conversion requires a reinterpret_cast, a C-style cast or function-style cast c:\fgdev\flightgear\src\model\modelmgr.cxx(138) : error C2040: '==' : 'int' differs in levels of indirection from 'struct FGModelMgr::Instance *' Backing up to version 1.3 of the file generates the following errors c:\fgdev\flightgear\src\model\modelmgr.cxx(14) : error C2039: 'find' : is not a member of 'std' c:\fgdev\flightgear\src\model\modelmgr.cxx(14) : error C2873: 'find' : symbol cannot be used in a using-declaration c:\fgdev\flightgear\src\model\modelmgr.cxx(138) : error C2065: 'find' : undeclared identifier If I remove the 'SG_USING_STD(find)' line (from 1.3), the error changes to c:\fgdev\flightgear\src\model\modelmgr.cxx(138) : error C2065: 'find' : undeclared identifier Thanks, Jonathan Polley Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC Build Problems in src/Main/main.cxx
I just noticed that the problem also exists for MacOS 10.2(.3), which I believe is at least OpenGL 1.3 (and 10.2.3 is OpenGL 1.4). Any ideas as to what is missing? Thanks, Jonathan Polley On Wednesday, January 1, 2003, at 10:25 AM, Norman Vine wrote: Jonathan Polley writes: The latest updat to src/Main/main.cxx is generating the following errors for MSVC 6.0 (and I assume for all Windows compilers). c:\fgdev\flightgear\src\main\main.cxx(749) : error C2065: 'GL_DISTANCE_ATTENUATION_EXT' : undeclared identifier c:\fgdev\flightgear\src\main\main.cxx(750) : error C2065: 'GL_POINT_SIZE_MIN_EXT' : undeclared identifier AFAIK these are post OpenGL version 1.1 hence not supported by the M$oft headers and require including the equivalant of extgl.h or just defining them ourselves #ifndef GL_EXT_point_parameters #define GL_EXT_point_parameters 1 #define GL_POINT_SIZE_MIN_EXT 0x8126 #define GL_POINT_SIZE_MAX_EXT 0x8127 #define GL_POINT_FADE_THRESHOLD_SIZE_EXT0x8128 #define GL_DISTANCE_ATTENUATION_EXT 0x8129 typedef void (APIENTRY * glPointParameterfEXTPROC) (GLenum pname, GLfloat param); typedef void (APIENTRY * glPointParameterfvEXTPROC) (GLenum pname, const GLfloat *params); extern glPointParameterfEXTPROC glPointParameterfEXT; extern glPointParameterfvEXTPROC glPointParameterfvEXT; #endif /* GL_EXT_point_parameters */ HTH Norman ___ 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
[Flightgear-devel] SimGear CVS Problem
I noticed this last night while trying to update SimGear: % cvs update -dP cvs server: Updating . P configure.ac cvs server: Updating simgear P simgear/Makefile.am P simgear/compiler.h cvs server: Updating simgear/bucket 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 Any thoughts? I assume that this is a CVS server issue since I have the problem under both MacOS and Windows. Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] MSVC Build Problems in src/Main/main.cxx
The latest updat to src/Main/main.cxx is generating the following errors for MSVC 6.0 (and I assume for all Windows compilers). c:\fgdev\flightgear\src\main\main.cxx(749) : error C2065: 'GL_DISTANCE_ATTENUATION_EXT' : undeclared identifier c:\fgdev\flightgear\src\main\main.cxx(750) : error C2065: 'GL_POINT_SIZE_MIN_EXT' : undeclared identifier Thanks, Jonathan Polley Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Problem with MSVC 6.0
Norman, Thanks, that fixed it. The changes that I tried were it that general direction, but not far enough. Jonathan Polley On Friday, Dec 20, 2002, at 11:03PM, Norman Vine [EMAIL PROTECTED] wrote: Jonathan Polley writes: Any more ideas? maybe $ cvs diff ATCVoice.cxx Index: ATCVoice.cxx === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/ATC/ATCVoice.cxx,v retrieving revision 1.2 diff -r1.2 ATCVoice.cxx 96a97,98 typedef list string tokenList_type; typedef tokenList_type::iterator tokenListItr_type; 105,106c107,108 list string tokenList; list string ::iterator tokenListItr; --- tokenList_type tokenList; tokenListItr_type tokenListItr; HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Build Problem with MSVC 6.0
I finally get my ISP straightened out and was able to update to CVS again (Ya!). Unfortunately, I came across a couple of problems. First, the macro GLUT_H does not seem to be defined anywhere. Where is that suppose to be (I stuck it in the appropriate config.h)? Second, I got an error in src/ATC/tower.hxx. typedef list TowerPlaneRec* tower_plane_rec_list_type; typedef list TowerPlaneRec* ::iterator tower_plane_rec_list_iterator; typedef list TowerPlaneRec* ::const_iterator tower_plane_rec_list_const_iterator; generates: c:\fgdev\flightgear\src\atc\tower.hxx(72) : error C2653: 'listclass TowerPlaneRec *,class std::allocatorclass TowerPlaneRec * ' : is not a class or namespace name c:\fgdev\flightgear\src\atc\tower.hxx(72) : error C2146: syntax error : missing ';' before identifier 'tower_plane_rec_list_iterator' Yes, I know that MSVC has its share of problems with templates, but is there a work around for this? Thanks, Jonathan Polley Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Problem with MSVC 6.0
Norman, That change worked fine. It uncovered a similar problem in src\ATC\ATCVoice.cxx. Making a similar change there was not successful. unsigned char* FGATCVoice::WriteMessage had the following lines: list string tokenList; list string ::iterator tokenListItr; which generated: c:\fgdev\flightgear\src\atc\atcvoice.cxx(106) : error C2653: 'listclass std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar ,class std::allocatorclass std::basic_stringchar,struct std::char_traitschar,class std::all ocatorchar ' : is not a class or namespace name c:\fgdev\flightgear\src\atc\atcvoice.cxx(106) : error C2065: 'iterator' : undeclared identifier c:\fgdev\flightgear\src\atc\atcvoice.cxx(106) : error C2146: syntax error : missing ';' before identifier 'tokenListItr' c:\fgdev\flightgear\src\atc\atcvoice.cxx(106) : error C2065: 'tokenListItr' : undeclared identifier Any more ideas? Thanks again for the help, Jonathan Polley Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac OS X 0.9.1 build available
I just got the MacOS X 10.1 version of FlightGear build and submitted to Darrell. The compiler used by 10.1 REALLY doesn't like the GL* type warnings that are present in the 3D cloud subsystem. It always aborted the build, even though they were warnings instead of errors. Any idea as to how long MacOS X 10.1 should be supported? Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.9.1 for Mac OS X
David, Since I am having some minor ISP problems, I downloaded the 0.9.1 tarballs last night and will try to build them for both 10.1 and 10.2 this weekend. Just to verify out build environments, what version of MacOS are you running? Also which versions of automake and autoconf do you have? I see you are linking against Xll (-L/usr/X11R6/lib), is that xfree86 (I have that installed as well)? I'll send you an email when I get everything built. Jonathan Polley On Friday, Dec 13, 2002, at 04:17PM, David Drum [EMAIL PROTECTED] wrote: Quoth Curtis L. Olson: If 0.9.1 is too much of a hassle to get running, please feel free to submit changes relative to current CVS, and we can do a 0.9.2 release and get a good Mac build for that. I removed the clouds3d code per a post of Curt's, and changed the tests in configure per a previous post of mine. The final link and resulting error message are below. I haven't had any luck changing the order of arguments to ld; if anyone can suggest an approach I would appreciate it. I have checked src/Objects/libObjects.a and it contains obj.o, which should contain gen_leaf. Likewise with ssgVtxTable in plib. g++ -DPKGLIBDIR=\/Users/david/FlightGear/FlightGear-0.9.1/lib/FlightGear\ -g -O2 -L/sw/lib -L/Users/david/FlightGear/FlightGear-0.9.1/lib -L/usr/X11R6/lib -o fgfs main.o fg_commands.o fg_init.o fg_io.o fg_props.o fgfs.o globals.o logger.o options.o splash.o util.o viewer.o viewmgr.o location.o ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/Network/libNetwork.a ../../src/NetworkOLK/libNetworkOLK.a ../../src/Objects/libObjects.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Environment/libEnvironment.a -lsgroute -lsgsky -lsgephem -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lmk4 -lz -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lpthread -lm -framework OpenGL -framework GLUT -lobjc -lplibsl -lplibsm -framework Carbon -lm ld: Undefined symbols: ssgVtxTable::ssgVtxTable[in-charge](unsigned, ssgVertexArray*, ssgNormalArray*, ssgTexCoordArray*, ssgColourArray*) gen_leaf(std::basic_stringchar, std::char_traitschar, std::allocatorchar const, unsigned long, std::basic_stringchar, std::char_traitschar, std::allocatorchar const, std::vectorPoint3D, std::allocatorPoint3D const, std::vectorPoint3D, std::allocatorPoint3D const, std::vectorPoint3D, std::allocatorPoint3D const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint const, bool, ssgVertexArray*) Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.9.1 for Mac OS X 10.1.5
I have a build for MacOS X 10.2 and will try to get a 10.1 version built tomorrow. The routine FGATCVoice::LoadVoice does not seem to work on the Mac as it game me a runtime error while loading the voice file. I'm not sure what isn't liked, but modifying the file to immediately return with 'false' allow me to run. Jonathan Polley On Wednesday, December 11, 2002, at 02:31 PM, Curtis L. Olson wrote: Has anyone built FlightGear 0.9.1 for Mac OS X yet? I'd like to be able to add the mac version to the downloads section at some point. Thanks, 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 mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.9.1 for Mac OS X 10.1.5
It turns out that my problem resides with my ISP. It turns out that they are moving everyone from IP_ADDR.mchsi.com to IP_ADDR.clients.mcshi.com and don't have their DNS servers set up for this new configuration. The result is that I fail the CVS server's validity check (the host name gotten via looking up my IP address does not exist). Curt was able to point this out to me. DSL is looking better and better. Jonathan Polley On Thursday, December 12, 2002, at 12:43 AM, John Check wrote: On Wednesday 11 December 2002 9:05 pm, Jonathan Polley wrote: On Wednesday, December 11, 2002, at 06:25 PM, John Check wrote: On Wednesday 11 December 2002 6:30 pm, Jonathan Polley wrote: I would really like to build it, but since I haven't been able to access CVS since the roll out of 0.9.1, I can't. It's odd that only the CVS FlightGear and SimGear don't work (plib works just great). If someone would like to help me get CVS access again, I would love to build the MacOS 10.1 version. I know that CVS access is not strictly required to get the Mac version to build, but it makes things much easier for me to submit the required changes. Check the FGFS and simgear sites. When Curt split the dev and stable branches he did it with separate repositories, so the log in changed. I have looked at both sites and they still show 0.8/0.9 (FlightGear) and 0.2/0.3 (SimGear). Those be them. Sorry. ___ 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] 0.9.1 for Mac OS X 10.1.5
I would really like to build it, but since I haven't been able to access CVS since the roll out of 0.9.1, I can't. It's odd that only the CVS FlightGear and SimGear don't work (plib works just great). If someone would like to help me get CVS access again, I would love to build the MacOS 10.1 version. I know that CVS access is not strictly required to get the Mac version to build, but it makes things much easier for me to submit the required changes. Jonathan Polley On Wednesday, Dec 11, 2002, at 02:31PM, Curtis L. Olson [EMAIL PROTECTED] wrote: Has anyone built FlightGear 0.9.1 for Mac OS X yet? I'd like to be able to add the mac version to the downloads section at some point. Thanks, 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 Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.9.1 for Mac OS X 10.1.5
On Wednesday, December 11, 2002, at 06:25 PM, John Check wrote: On Wednesday 11 December 2002 6:30 pm, Jonathan Polley wrote: I would really like to build it, but since I haven't been able to access CVS since the roll out of 0.9.1, I can't. It's odd that only the CVS FlightGear and SimGear don't work (plib works just great). If someone would like to help me get CVS access again, I would love to build the MacOS 10.1 version. I know that CVS access is not strictly required to get the Mac version to build, but it makes things much easier for me to submit the required changes. Check the FGFS and simgear sites. When Curt split the dev and stable branches he did it with separate repositories, so the log in changed. I have looked at both sites and they still show 0.8/0.9 (FlightGear) and 0.2/0.3 (SimGear). I have tried logging into SimGear 0.3.1 and FlightGear 0.9.1 but both fail in the same manner. What is the proper repository? Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.9.1 for Mac OS X
On Wednesday, December 11, 2002, at 06:49 PM, darrell.l.walisser.1 wrote: The end result of these changes is a sort-of running version. The clouds3d option doesn't work. It doesn't crash, but eats up huge quantities of memory (300MB+) after running(during fgfs startup) for a few minutes at which point I give up on it. I'm pretty sure none of my changes could have caused this. I saw the same problem with the 3D clouds earlier. It appeared to be an endian issue as the offending value was 0x200 (or something similar). Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CVS Still Unavailable
I am still unable to connect to either the FlightGear or SimGear CVS repositories. I can not login to either the stable or development branches, but I can use the web browser for the repositories (and FlightGear shows 0.8 and 0.9 rather than 0.8.1 and 0.9.1, so I am assuming that nothing has changed in the CVS structure). Has the magic changed since the last release? Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CVS Problems
I have been unable to connect to CVS for the past two days (Connection reset by peer). Is anyone else having this problem? I can connect to plib just fine. Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
On Wednesday, December 4, 2002, at 03:00 AM, Erik Hofman wrote: Norman Vine wrote: Jonathan Polley writes: I would like to see if this solves a similar problem I have with OS X's threading. I really prefer the threaded tile loader as it gives me a much smoother frame rate. Interesting that this problem exists on OS X also. Could the automatic cleanup of threads at exit() be a Linux extension to Posix threads ??? http://www.opengroup.org/onlinepubs/007908799/xsh/threads.html Well, IRIX doesn't have this problem, so at least it's not not just a Linux extension. Erik Actually, MacOS X has had some known issues with pthreads, although 10.2 is much better than 10.1. Although I can now build with threading, using ESC hangs at the end. If I select the Quit menu item, it shuts down just fine. I would expect that the behavior of exit() is very well defined and, in my case, OS X's implementation is still lacking. I'll try the updates out this weekend. Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
Norman, Will you be rolling this change into the baseline any time soon? I would like to see if this solves a similar problem I have with OS X's threading. I really prefer the threaded tile loader as it gives me a much smoother frame rate. Thanks, Jonathan Polley On Tuesday, December 3, 2002, at 07:29 PM, Norman Vine wrote: I have updated this tarball to a version that does NOT have a problem exiting. The way I fixed the 'thread not receiving a cancel event' was to make the global_tile_mgr a pointer to an allocated instance of a FGTileMgr and its FGTileLoader member an allocated object also. Then deletiing the global_tile_mgr at exit time automagically destroys the threads :-) This begs the question How do we want to handle 'Singleton Objects' like this The static nature they currently have is I believe a leftover from the pre C++ era My instinct is that all of these should be moved into the fgGlobals class and be allocated objects derived from an abstract Singleton class Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
Norman, Which pthread library did you use? The RedHat one (http://sources.redhat.com/pthreads-win32/) or something else? Jonathan Polley On Monday, Dec 02, 2002, at 04:57PM, Norman Vine [EMAIL PROTECTED] wrote: Hi all I have placed a MingW32 native win32 fgfs executable compiled from yesterday's CVS files at http://rockfish.net/~nhv/fgfs/fgfs_ming_thread.tgz This uses the threaded tile pager and I have included a pthread.dll that must be kept in the same directory as the executable This will require the CVS version of the base files There is a 'known' problem exiting the program with the pager thread not getting a 'quit' mesage I just use 'ctrl-c' in the console window and this seems to work This also uses Andy's 3D HUD for the normal HUD and the previous minimal 2D HUD The only other change is I am testing a 'modified' tilemanager and would 'appreciate' feedback on any tile-boundary problems ie wierd crashes, spurious height above ground readings ect Enjoy Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
Good, that is the one I have at home so I can play with your multi-threaded .exe. On Monday, December 2, 2002, at 05:35 PM, Norman Vine wrote: Jonathan Polley writes: Norman, Which pthread library did you use? The RedHat one (http://sources.redhat.com/pthreads-win32/) or something else? Yes that's the one. Norman ___ 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] WIN32 threaded binary
I loaded the threaded Win32 FlightGear and gave it a try. Aside from the know problem, which is EXACTLY how my Mac works when I build with threading ;), the only thing I noticed was a slight (10% or so) reduction in frame rate and, the to be expected, garbled output on the console. Good work! Jonathan Polley On Monday, December 2, 2002, at 04:57 PM, Norman Vine wrote: Hi all I have placed a MingW32 native win32 fgfs executable compiled from yesterday's CVS files at http://rockfish.net/~nhv/fgfs/fgfs_ming_thread.tgz This uses the threaded tile pager and I have included a pthread.dll that must be kept in the same directory as the executable This will require the CVS version of the base files There is a 'known' problem exiting the program with the pager thread not getting a 'quit' mesage I just use 'ctrl-c' in the console window and this seems to work This also uses Andy's 3D HUD for the normal HUD and the previous minimal 2D HUD The only other change is I am testing a 'modified' tilemanager and would 'appreciate' feedback on any tile-boundary problems ie wierd crashes, spurious height above ground readings ect Enjoy Norman ___ 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] ATI vs. Linux
I had to chuckle at the line Through our various feedback mechanisms... It's nice (?) to see that something like /. is considered a feedback mechanism. ) On Friday, November 29, 2002, at 03:12 PM, Andy Ross wrote: Martin Spott wrote: Andy Ross wrote: Probably most of you noticed last week that ATI has released a unified linux driver package for all of their 8x00/9x00 cards. [...] Wohoo, you made it into /. with this article. I would not wonder if this boosts FlightGear popularity :-) Yikes. My wife saw this first* and called me in this morning. Good grief. I hadn't planned on using up my 15 minutes of fame so soon, nor for such a silly purpose. * Yes, I have a wife who reads slashdot. Phear me! No wait, this is a post to flightgear-devel. Never mind. :) I was hoping to see some interest in FlightGear in all the responses, but most of it was the standard slashdot nonsense**. Curt will have to tell us if he sees any new mailing list subscriptions. The statistics at http://seneca.me.umn.edu show a little peak over the past few days and about 6000 hits on the slashdot link, but not a whole lot of change. ** Linux vs. Windows (no! FreeDOS!). NVidia vs. ATI (no! Matrox!). More than a few people called me an idiot. More than a few of those hadn't bothered to read the link. Whee. But let it not be said that all was in vain. I just received the following from Terry Makedon at ATI. These guys understood the problem and fixed it withing a day after the slashdot article appeared. It looks like it really was just an honest mistake. Now I feel guilty for the frothing mess remark. :) Andy Hi there, Last week we posted a set of unified Linux drivers. These drivers were only loading up on Built by ATI cards. Through our various feedback mechanisms we have determined that there is a large community of Powered by ATI Linux users that did not benefit from our Linux drivers. At this point we are happy to announce an update to our Linux driver (ver. 2.5.1) which will work on both Powered by and Built by. ATI's driver and software strategy is firmly based on responsiveness and we greatly appreciate the feedback our Linux users have provided. Please use http://apps.ati.com/linuxDfeedback/ for a direct feedback line to ATI. Thanks again for the feedback, Terry Makedon Sr. Product Manager - Software ATI Technologies -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ 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] Latest CVS Crashes
Curt, I updated plib, SimGear, and FlightGear before rebuilding. I cleaned everything on Windows because there were some changes to plib headers (MSVC isn't always smart enough to properly handle header changes if they are not in YOUR project). I haven't cleaned the MacOS build because gcc hasn't had such problems. Jonathan Polley On Tuesday, November 12, 2002, at 06:43 AM, Curtis L. Olson wrote: Just to double check, David made a change to SimGear and to the some of the aircraft config files yesterday. Without the change to simgear, flightgear will crash on startup. If that's not it, then we'll have to take a closer look, although your line numbers don't make sense in your back trace ... Regards, Curt. Jonathan Polley writes: I just updated from CVS for both the Mac and Windows and got the same error when I tried to run. The Mac traceback is as follows: Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0006 Thread 0 Crashed: #0 0x000525f8 in ssgContext::forceBasicState() (ssgContext.cxx:103) #1 0x00038464 in ssgCullAndDraw(ssgBranch*) (ssg.cxx:273) #2 0x427c in fgRenderFrame() (main.cxx:2143) #3 0x6284 in fgMainLoop() (main.cxx:271) #4 0x90163888 in __CFRunLoopDoTimer #5 0x901493e0 in __CFRunLoopRun #6 0x9018157c in CFRunLoopRunSpecific #7 0x92ba34cc in RunCurrentEventLoopInMode #8 0x92bb32f4 in ReceiveNextEventCommon #9 0x92bda280 in BlockUntilNextEventMatchingListInMode #10 0x93082184 in _DPSNextEvent #11 0x930ccf84 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] #12 0x930ca500 in -[NSApplication run] #13 0x94fd9110 in glutMainLoop #14 0x8c7c in mainLoop(int, char**) (main.cxx:1746) #15 0x8dd4 in main (main.cxx:1834) #16 0x2b5c in _start (crt.c:267) #17 0x29dc in start The error was in the same routine, so I am assuming that there is something uninitialized somewhere. The bad pointer was in slightly different lines of code, though: if ( ovState != NULL ) ovState - force () ; --- Windows Crashes else basicState - force () ; --- Mac Crashes Windows died where it did because ovState contained the Windows non-zero invalid pointer value (0xcacacaca). Jonathan Polley ___ 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 mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest CVS Crashes
Andy, That fixed the problem. Thanks! Jonathan Polley On Tuesday, November 12, 2002, at 03:21 PM, Andy Ross wrote: Jonathan Polley wrote: I updated plib, SimGear, and FlightGear before rebuilding. I cleaned everything on Windows because there were some changes to plib headers (MSVC isn't always smart enough to properly handle header changes if they are not in YOUR project). I haven't cleaned the MacOS build because gcc hasn't had such problems. I just got bitten by this too after a CVS update. Your diagnosis was correct; it's a plib bug. Changes that Steve made two days ago introduced an new variable without a default initialization. Here's the note I just sent to the plib list: The most recent changes have an uninitialized data bug. The new ssgContext member ovState is never assigned to a default value in the constructor, but is nonetheless tested against NULL at runtime. Trivial patch follows. Andy diff -u -r1.19 ssgContext.cxx --- ssgContext.cxx 10 Nov 2002 17:12:13 - 1.19 +++ ssgContext.cxx 12 Nov 2002 21:14:07 - @@ -48,6 +48,7 @@ cullFace = TRUE ; ovTexture= FALSE ; ovCullface = FALSE ; + ovState = NULL ; sgCopyMat4 ( cameraMatrix, _ssgOpenGLAxisSwapMatrix ) ; Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ 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
[Flightgear-devel] Latest CVS Crashes
I just updated from CVS for both the Mac and Windows and got the same error when I tried to run. The Mac traceback is as follows: Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0006 Thread 0 Crashed: #0 0x000525f8 in ssgContext::forceBasicState() (ssgContext.cxx:103) #1 0x00038464 in ssgCullAndDraw(ssgBranch*) (ssg.cxx:273) #2 0x427c in fgRenderFrame() (main.cxx:2143) #3 0x6284 in fgMainLoop() (main.cxx:271) #4 0x90163888 in __CFRunLoopDoTimer #5 0x901493e0 in __CFRunLoopRun #6 0x9018157c in CFRunLoopRunSpecific #7 0x92ba34cc in RunCurrentEventLoopInMode #8 0x92bb32f4 in ReceiveNextEventCommon #9 0x92bda280 in BlockUntilNextEventMatchingListInMode #10 0x93082184 in _DPSNextEvent #11 0x930ccf84 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] #12 0x930ca500 in -[NSApplication run] #13 0x94fd9110 in glutMainLoop #14 0x8c7c in mainLoop(int, char**) (main.cxx:1746) #15 0x8dd4 in main (main.cxx:1834) #16 0x2b5c in _start (crt.c:267) #17 0x29dc in start The error was in the same routine, so I am assuming that there is something uninitialized somewhere. The bad pointer was in slightly different lines of code, though: if ( ovState != NULL ) ovState - force () ; --- Windows Crashes else basicState - force () ; --- Mac Crashes Windows died where it did because ovState contained the Windows non-zero invalid pointer value (0xcacacaca). Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: XML Question
On Tuesday, October 29, 2002, at 04:42 AM, David Megginson wrote: Jonathan Polley writes: Any recommendations? This is not an immediate need since I have a temporary work around for my type definition problem, but I would like a better long-term solution. My main recommendation is to build an abstract library on top of the XML, like our property manager (only perhaps simpler) -- that way, XML parsing is completely separate from program logic, and if you need to change the XML details, you can do it all in one place. For the vast majority of what will be using XML, that was the approach I was planning to take. This will be used to configure the application so I was hoping to load the XML file, extract the desired information, then purge the file fro memory. The FlightGear property manager is most definitely overkill for what I need done. The big problem will be with the data structure definitions. I think Norman's XML-RPC link will provide a good starting point. The only problem is that I need to match a preexisting, packed, data structure (it contains 8- and 16-bit integers along with some other nasties). My final language will be C, but using python reduces the code-link-damn cycle down to just code-damn. Well, that and it is just easier to work with. Thanks for your help! Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OT: XML Question
I know this is off topic, but XML *is* used quite a bit in FlightGear. Maybe this question is aimed at David Megginson, bit I would like to hear other opinions as well. My end goal is to use XML to define the configuration files for a series of applications. The first application may have the most complicated configuration file. I need the file to contain type and instance declarations. Some of the type information is easy to define: position latitude type=double/latitude longitude type=double/longitude altitude type=double/altitude /position attitude pitch type=double/pitch roll type=double/roll yaw type=double/yaw /attitude However, I would like to take these type definitions and use them to build larger types (something like) aircraft_reference position type=position/position orientation type=attitude/orientation aircraft_reference or use them to define data aircraft_position type=position latitude42.032/latitude longitude-91.642/longitude altitude940.0/altitude /aircraft_position The other applications will have a very flat configuration file definition. No nested types, mostly key/value pairs. I *think* that XMl may be a solution to my problem, but I don't have the experience that this group has. In the 30 seconds, or so, of free time that I have each day, I am reading through the O'Reilly book Python and XML (it is easier for me to do new things like this under python). Any recommendations? This is not an immediate need since I have a temporary work around for my type definition problem, but I would like a better long-term solution. Thanks, Jonathan Polley p.s., I know my XML examples are wrong, I am trying to give the flavor of why I am trying to do. p.p.s., David, were you aware that http://www.saxproject.org/ has expired? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
