Re: [Flightgear-devel] CVS and branch development
Hmm, Sorry about that. I had a quick look into the cvs commit logs at the time you asked. It turned out to be too quick ... On Dienstag 05 Oktober 2004 16:48, Jon Berndt wrote: Well, I've just about had it with cvs branches. I tagged some files in a branch, then moved to a test directory and checked out that branch, but only got the branch-tagged files. I needed all of the files, except I wanted the updated files on the specified branch. Tag the whole tree. One thing that makes this difficult is that it seems as though cvs at sourceforge has a lag. What I check in is not what I can check until a few hours later. Use your usual cvs tools for getting information about the tree. This one uses the developer cvs server. I am trying to develop the new XML capability in JSBSim. There are some new files that I have checked in that are new and do not need to be on a new branch. But, there are some that are currently used and I do not want to commit these to the HEAD branch until the whole set of changes is done. However, CVS using branches is giving me a big headache - it seems to work differently than I expect it to. I'm not sure what to do. Suggestions welcome. Go back to that date you have started your work. Check out that version. You can do that with cvs co -D 'My start date of work' JSBSim Check that version into HEAD. Then create a new branch with for the *whole* tree. Check that out into a *seperate* directory. Do here your branch work. Use an other directory for doing non branch work. There is also useful information about cvs available at: https://ccvs.cvshome.org/fom//cache/1.html Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
John Wojnaroski wrote: Note: For now, you will have to install the TNL headers files by hand: the following script should work #!/bin/bash cd /usr/include mkdir tnl cd tnl [...] This could be easily solved by setting srcdir = .. in src/master/Makefile and, what you'll have to do in any case, fix the include statement in the source files, for example src/master/masterInterface.h, to #include tnl/tnlEventConnection.h #include tnl/tnlRPC.h But even then it won't compile on Solaris/Sparc: Making all in src make[1]: Entering directory `/usr/local/src/TNL-1.4/src' Making all in master make[2]: Entering directory `/usr/local/src/TNL-1.4/src/master' source='masterInterface.cpp' object='masterInterface.o' libtool=no \ depfile='.deps/masterInterface.Po' tmpdepfile='.deps/masterInterface.TPo' \ depmode=gcc /bin/sh ../../depcomp \ c++ -DPACKAGE=\TNL\ -DVERSION=\1.4\ -DHAVE_DAYLIGHT=1 -DHAVE_TIMEZONE=1 -DHAVE_LIBM=1 -DHAVE_LIBPTHREAD=1 -DHAVE_LIBX11=1 [...] -I. -I/opt/gnu/include -I/usr/local/include -I/opt/FlightGear/include -O3 -c -o masterInterface.o `test -f masterInterface.cpp || echo './'`masterInterface.cpp In file included from /usr/local/include/tnl/tnlNetBase.h:33, from /usr/local/include/tnl/tnlNetConnection.h:31, from /usr/local/include/tnl/tnlEventConnection.h:31, from masterInterface.h:30, from masterInterface.cpp:28: /usr/local/include/tnl/tnlTypes.h:271:4: #error TNL: Unsupported Operating System /usr/local/include/tnl/tnlTypes.h:307:4: #error TNL: Unsupported Target CPU [...] I wonder how they can claim cross-platform portability BTW, what is the relation between the files you placed on OpenATC and the OpenTNL project ? From there I could download only a '1.4.0rc4' source code package, the version on OpenATC carries the version 1.4 and the OpenTNL website claims they already reached version 1.4.3. All this doesn't fit together, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
Martin Spott wrote: John Wojnaroski wrote: Note: For now, you will have to install the TNL headers files by hand: the following script should work #!/bin/bash cd /usr/include mkdir tnl cd tnl [...] This could be easily solved by setting srcdir = .. in src/master/Makefile yes, even though a simple cp -R tnl /usr/include would have been okay, too ... But I think, we'll add a simple install target to that makefile and take of all that care within the makefile. and, what you'll have to do in any case, fix the include statement in the source files, for example src/master/masterInterface.h, to #include tnl/tnlEventConnection.h #include tnl/tnlRPC.h yes, right - I did change exactly that yesterday ... there are some other smaller changes, we'll upload a fixed set of files by tomorrow. But even then it won't compile on Solaris/Sparc: I wonder how they can claim cross-platform portability okay, that's indeed a bit weird ... BTW, what is the relation between the files you placed on OpenATC and the OpenTNL project ? From there I could download only a '1.4.0rc4' source code package, the version on OpenATC carries the version 1.4 and the OpenTNL website claims they already reached version 1.4.3. All this doesn't fit together, The openTNL headers/library sources on openatc.sf.net/test are merely a downstripped/reduced version of the actual sources, simply because John figured we wouldn't need most of the stuff ... -- Bori ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] hi res screen shots
Curtis L. Olson wrote: I just committed a set of changes to move the hi res screen capture feature back towards a useable state. The hires screenshot snapper now uses the same render code as the normal res screen shot snapper which uses the same render code as the main program. That should reduce code maintenance work and code rot in the future. And I've modified the SimGear code to define the jpgRenderFrame code itself (initialized to NULL) and made FlightGear initialize it to FGRenderer::update while FGRenderer is active. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
Boris Koenig wrote: yes, right - I did change exactly that yesterday ... there are some other smaller changes, we'll upload a fixed set of files by tomorrow. Would you mind trying to compile with a recent version of GCC before you post new files ? I'm using 3.4.2 on Solaris and I have the impression that that one is pretty picky. If you tell me it 'survives' compiling with 3.4.2 on Linux it simplifies determining which changes are specifically necessary for Solaris, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
Martin Spott wrote: Boris Koenig wrote: yes, right - I did change exactly that yesterday ... there are some other smaller changes, we'll upload a fixed set of files by tomorrow. Would you mind trying to compile with a recent version of GCC before you post new files ? I'm using 3.4.2 on Solaris and I have the impression that that one is pretty picky. If you tell me it 'survives' compiling with 3.4.2 on Linux it simplifies determining which changes are specifically necessary for Solaris, Hmm, the latest version that I have access to locally is: gcc (GCC) 3.3 - and actually, I wasn't going to recompile GCC ;-) I am not sure where exactly the TNL (lib) is incompatible with Solaris, but I guess that can only be fixed directly within the lib itself ... So, maybe you can resolve some issues by directly trying to build the STANDARD package from opentnl.org - possibly, there's even some info available specific to Solaris. The sources itself should actually not be too non-standard, John simply used the shipped opentnl examples to put a basic test framework together, so there's not even that much 'new' code ... Actually, pretty much all of it is simply derived from those examples. Let's see if the official version builds on Solaris or where exactly it fails. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
Boris Koenig wrote: So, maybe you can resolve some issues by directly trying to build the STANDARD package from opentnl.org - possibly, there's even some info available specific to Solaris. Huh ? I think: Features Multiple platform support * Windows 98, ME, NT, XP * Linux on x86 * Mac OS X says it all I'll try anyway but it might take some time (which I usually don't have available ). I think people usually say don't hold your breath :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
Martin Spott wrote: Boris Koenig wrote: So, maybe you can resolve some issues by directly trying to build the STANDARD package from opentnl.org - possibly, there's even some info available specific to Solaris. Huh ? I think: Features Multiple platform support * Windows 98, ME, NT, XP * Linux on x86 * Mac OS X says it all lol, Martin - I've got good news for you: quote The Torque Network Library runs on the Microsoft Windows, Mac OS X and Linux platforms. *A Microsoft XBox version is available seperately from GarageGames.com* and future support is planned for Sony's Playstation 2 platform. /quote Which essentially means: get an X-Box or Playstation 2 - instead of a solaris machine :-) Anyway, the following sounds rather encouraging: quote TNL compiles under either either Microsoft Visual C++ 6.0 or Microsoft Visual C++ .NET 2003 on Windows, XCode on Mac OS X and with makefiles and GCC on Linux. In addition, TNL is designed to be easily portable, with all platform specific code contained in a single module. /quote So far it seems to be somewhat X86 specific, which would explain why opentnl doesn't like to run on Solaris :-) I'll try anyway but it might take some time (which I usually don't have available ). I think people usually say don't hold your breath :-) I think they're running a mailing list, too - I might send them a short questions as to whether it's possible to make the opentnl run on Solaris EASILY, or not ... http://sourceforge.net/projects/opentnl -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
BTW, what is the relation between the files you placed on OpenATC and the OpenTNL project ? From there I could download only a '1.4.0rc4' source code package, the version on OpenATC carries the version 1.4 and the OpenTNL website claims they already reached version 1.4.3. All this doesn't fit together, The openTNL headers/library sources on openatc.sf.net/test are merely a downstripped/reduced version of the actual sources, simply because John figured we wouldn't need most of the stuff ... There was an update to OpenTNL at the end of September. The version currently used by ATC-0.1 is the 1.4.0 version prior to that update. The latest tagged revision, identified as HEAD, is the 1.4.3 version and it appears there are some binary files of the demo game zap tagged as 1.4.3. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
Boris Koenig wrote: I am not sure where exactly the TNL (lib) is incompatible with Solaris, but I guess that can only be fixed directly within the lib itself ... For GCC-3.4.2 I got this one: make[1]: Entering directory `/usr/local/src/tnl/tnl' g++ -g -DTNL_DEBUG -DTNL_ENABLE_LOGGING -I../libtomcrypt -c assert.cpp In file included from tnlUDP.h:35, from tnl.h:51, from assert.cpp:27: tnlVector.h: In member function `T TNL::VectorT::front()': tnlVector.h:301: error: there are no arguments to `begin' that depend on a template parameter, so a declaration of `begin' must be available tnlVector.h:301: error: (if you use `-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) tnlVector.h: In member function `const T TNL::VectorT::front() const': tnlVector.h:306: error: there are no arguments to `begin' that depend on a template parameter, so a declaration of `begin' must be available tnlVector.h: In member function `T TNL::VectorT::back()': tnlVector.h:311: error: there are no arguments to `end' that depend on a template parameter, so a declaration of `end' must be available tnlVector.h: In member function `const T TNL::VectorT::back() const': tnlVector.h:316: error: there are no arguments to `end' that depend on a template parameter, so a declaration of `end' must be available make[1]: *** [assert.o] Error 1 make[1]: Leaving directory `/usr/local/src/tnl/tnl' make: *** [default] Error 2 After dealing with that I got to this point: make[1]: Entering directory `/usr/local/src/tnl/tnl' g++ -g -DTNL_DEBUG -DTNL_ENABLE_LOGGING -fpermissive -I../libtomcrypt -c eventConnection.cpp In file included from tnlUDP.h:35, from tnl.h:51, from eventConnection.cpp:27: [...] In file included from tnlRPC.h:35, from tnlNetObject.h:39, from tnlNetInterface.h:41, from eventConnection.cpp:31: tnlMethodDispatch.h:194:2: #error Compiling RPC code without inline assembler support! You will need to implement RPCEvent::process() and co for your platform. In file included from tnlNetObject.h:39, from tnlNetInterface.h:41, from eventConnection.cpp:31: tnlRPC.h: At global scope: tnlRPC.h:167: error: expected `0' before tnlRPC.h:167: error: invalid initializer for virtual method `virtual bool TNL::RPCEvent::checkClassType(TNL::Object*)' tnlRPC.h:167: error: expected `;' before make[1]: *** [eventConnection.o] Error 1 make[1]: Leaving directory `/usr/local/src/tnl/tnl' make: *** [default] Error 2 Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
Boris Koenig wrote: So far it seems to be somewhat X86 specific, which would explain why opentnl doesn't like to run on Solaris :-) That would seem to indicate that nobody's bothered to make use of things like hton functions, which in turn indicates that they weren't being particularly platform neutral in the design, and that we can expect some horrible bodges in the platform specific code contained in a single module for any other platform. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
Boris Koenig wrote: Which essentially means: get an X-Box or Playstation 2 - instead of a solaris machine :-) Well, I'll ask our institute if they'd like to run their primary fileserver, EMail relay and the university's FTP-Server on a Playstation :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] File names?
Hmmm Hope this hasn't confused anyone. There is a file on the SF page called tnl_head.tgz. This is a tar file of the header files for the network test build. it is NOT the tar file tagged as *HEAD* on the OpenTNL website. Does anyone have a favorite network utility/packet sniffer? I'm looking at sniffit from the Debian package, but not all that happy with it. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] File names?
John Wojnaroski wrote: Hope this hasn't confused anyone. There is a file on the SF page called tnl_head.tgz. This is a tar file of the header files for the network test build. it is NOT the tar file tagged as *HEAD* on the OpenTNL website. That's pretty clear. I'm mostly confused because OpenTNL apparently doesn't meet the conventions of FlightGear concerning portability, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] File names?
John Wojnaroski wrote: Does anyone have a favorite network utility/packet sniffer? I'm looking at sniffit from the Debian package, but not all that happy with it. tcpdump -i interface -l -w dumpfile Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] File names?
John Wojnaroski wrote: Does anyone have a favorite network utility/packet sniffer? I'm looking at sniffit from the Debian package, but not all that happy with it. Ethereal but only on packets that transit through an ethernet card ( doesn't work on the loopback or on serial ppp ) -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] File names?
Martin Spott wrote: John Wojnaroski wrote: Hope this hasn't confused anyone. There is a file on the SF page called tnl_head.tgz. This is a tar file of the header files for the network test build. it is NOT the tar file tagged as *HEAD* on the OpenTNL website. That's pretty clear. I'm mostly confused because OpenTNL apparently doesn't meet the conventions of FlightGear concerning portability, Yes, it looks somewhat problematic right now, but otherwise it's not yet really a problem, as there hasn't been much code written as of now - we might have to check other open source multiplayer/networking libraries out, though. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] File names?
Fred wrote: John Wojnaroski wrote: Does anyone have a favorite network utility/packet sniffer? I'm looking at sniffit from the Debian package, but not all that happy with it. Ethereal but only on packets that transit through an ethernet card ( doesn't work on the loopback or on serial ppp ) neither does sniffit... trying to run some tests internally before going out on the Internet or a LAN Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] File names?
- Original Message - From: Boris Koenig [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 10:01 AM Subject: Re: [Flightgear-devel] File names? Martin Spott wrote: John Wojnaroski wrote: Hope this hasn't confused anyone. There is a file on the SF page called tnl_head.tgz. This is a tar file of the header files for the network test build. it is NOT the tar file tagged as *HEAD* on the OpenTNL website. That's pretty clear. I'm mostly confused because OpenTNL apparently doesn't meet the conventions of FlightGear concerning portability, Yes, it looks somewhat problematic right now, but otherwise it's not yet really a problem, as there hasn't been much code written as of now - we might have to check other open source multiplayer/networking libraries out, though. Suggest we take the positive road and make it work. From my perspective it looks d--- good and since it is open-source as well perhaps the TNL folks would be willing to work with us. But when it comes to cross-platform issues, I'll defer to the experts. There was an attempt to make FG multi-player, but that seems to have receded. I think the TNL library has a better foundation and capabilities... Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] File names?
John Wojnaroski wrote: Suggest we take the positive road and make it work. From my perspective it looks d--- good and since it is open-source as well perhaps the TNL folks would be willing to work with us. Yes, I suggested already to drop them a few lines and ask them for their feedback, maybe there's even some information about what exactly needs to be done to make it compile on other platforms, too. But when it comes to cross-platform issues, I'll defer to the experts. I've sent a short note to 'our volunteer experts', so that they can check out what's possible and what isn't. There was an attempt to make FG multi-player, but that seems to have receded. I think the TNL library has a better foundation and capabilities... This WAS my impression, too -otherwise FG runs definitely on MORE platforms than the TNL, so that would currently be a pretty limiting factor, I simply didn't look really into it, because the TNL support exactly those platforms that I use mainly ... -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] File names?
John Wojnaroski wrote: Fred wrote: John Wojnaroski wrote: Does anyone have a favorite network utility/packet sniffer? I'm looking at sniffit from the Debian package, but not all that happy with it. Ethereal but only on packets that transit through an ethernet card ( doesn't work on the loopback or on serial ppp ) neither does sniffit... trying to run some tests internally before going out on the Internet or a LAN How about snoop ? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] File names?
Erik Hofman wrote: John Wojnaroski wrote: Fred wrote: John Wojnaroski wrote: Does anyone have a favorite network utility/packet sniffer? I'm looking at sniffit from the Debian package, but not all that happy with it. Ethereal but only on packets that transit through an ethernet card ( doesn't work on the loopback or on serial ppp ) neither does sniffit... trying to run some tests internally before going out on the Internet or a LAN How about snoop ? I haven't been paying attention to this thread, but I seem to recall that it is not possible for a machine to fully sniff itself. If you are having technical problems with the tools you are trying, you might try snooping from an independent 3rd machine that is only listening to the net and not participating in the conversation. But, that may not work well either if you are plugged into a switch and not a hub ... depending on the nature of your network traffic. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] File names?
Curtis L. Olson wrote: I haven't been paying attention to this thread, but I seem to recall that it is not possible for a machine to fully sniff itself. If you are having technical problems with the tools you are trying, you might try snooping from an independent 3rd machine that is only listening to the net and not participating in the conversation. You might want to try 'tcpdump' the next time. I've been successfully using it on any kind of interface (Ethernet, ISDN-HDLC, ISDN-SyncPPP, Modem-AsyncPPP, ATM-LANE ) already for years, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d