Re: [Flightgear-devel] CVS compiling error CYGWIN
Have you tried adding -DNOMINMAX to your CFLAGS and CXXFLAGS?
Alternatively try adding
#ifdef HAVE_CONFIG_H
# include config.h
#endif
as the first include of each cxx or cpp file giving problems.
I'm not using Cygwin any more BTW, so I'm posting blind, but I'm pretty sure it
will turn out to be the old min/max redefinition problem again.
Cheers - Dave
Georg Vollnhals writes:
Hi,
after many!!! new builds without any problem I have got a new one over
the last days when trying to compile the newest CVS under Cygwin.
At last I even made a complete new Cygwin install and complete new
download of SimGear and FlightGear CVS and tried to compile the whole
stuff - same result: SimGear without problems, FlightGear compilation
does not work.
Any ideas? Thank you in advance!
Regards
Georg EDDW
In file included from
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/deque:71,
from
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/queue:74,
from ../FGJSBBase.h:47,
from FGFCSComponent.h:46,
from FGDeadBand.h:40,
from FGDeadBand.cpp:40:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_deque.h: In
member function `void std::_Deque_base_Tp,
_Alloc::_M_initialize_map(size_t)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_deque.h:446:
error: expected unqualified-id before '(' token
In file included from
...
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS compiling error CYGWIN
Hi David, your help did not only save the day but the rest of the week, thank you very much :-) I could compile the CVS and FG is running! Have you tried adding -DNOMINMAX to your CFLAGS and CXXFLAGS? Mmh, this was behind my scope. If you ever have some time then tell me please where I find these flags. Can I find something linke a config file anywhere? Alternatively try adding #ifdef HAVE_CONFIG_H # include config.h #endif as the first include of each cxx or cpp file giving problems. This solved the problem. I just put it into the following 4 files (I hope I did not forget one): FGDeadband.h ../FGJSBBase.h FGFCSComponent.h ../FGPropertyManager.h !! As I have not got the skills until now to create a diff file to the cvs and I am not sure whether I have placed the stuff at the position in the code where it should be in a professional manner I would ask anyone who can do it for changing these CVS files to prevent trouble for other friends using Cygwin/CVS. Thank you in advance! I'm not using Cygwin any more BTW, so I'm posting blind, but I'm pretty sure it will turn out to be the old min/max redefinition problem again. Cheers - Dave Ok, now blind but pretty well remembering the way to go from the days you could see :-) :-) Thank you once again, I am really happy now. Regards Georg EDDW ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS and PLIB
Jon Berndt wrote: Is there some kind of problem going on with downloading PLIB from CVS? Seems there's been a partial outage in progress on SF.net for weeks. I can't get plib from CVS, though ... I made a copy of the latest CVS available: ftp://ftp.uni-duisburg.de/FlightGear/Devel/plib-20051127.tar.gz Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS make error (Cygwin)
Hi, Kevin Jones wrote: Hi, CVS FG source at 2:30pm (UK time) Monday 7th November fails to make on Cygwin with the following error: make[2]: Entering directory blah/source/src/MultiPlayer make[2]: *** No rule to make target `tiny_xdr.cpp', needed by `tiny_xdr.o'. Stop. Can anyone help? Had the same error yesterday on Linux. You need to rerun ./autogen.sh in the FlightGear source root. Hope this helps, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS make error (Cygwin)
On Monday 07 November 2005 15:02, Kevin Jones wrote: CVS FG source at 2:30pm (UK time) Monday 7th November fails to make on Cygwin with the following error: make[2]: Entering directory blah/source/src/MultiPlayer make[2]: *** No rule to make target `tiny_xdr.cpp', needed by `tiny_xdr.o'. Stop. Not just on cygwin, lots of people (including me) will have been finding that. Try make distclean first. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS make error (Cygwin)
On Mon, 2005-11-07 at 15:02 +, Kevin Jones wrote: Hi, CVS FG source at 2:30pm (UK time) Monday 7th November fails to make on Cygwin with the following error: make[2]: Entering directory blah/source/src/MultiPlayer make[2]: *** No rule to make target `tiny_xdr.cpp', needed by `tiny_xdr.o'. Stop. Can anyone help? Kevin. Kevin, You need to do a make clean and re-./configure before building... The file tiny_xdr.cpp has been renamed tiny_xdr.cxx. George Patterson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS make error (Cygwin)
On Monday 07 November 2005 16:28, George Patterson wrote: On Mon, 2005-11-07 at 15:02 +, Kevin Jones wrote: Hi, CVS FG source at 2:30pm (UK time) Monday 7th November fails to make on Cygwin with the following error: make[2]: Entering directory blah/source/src/MultiPlayer make[2]: *** No rule to make target `tiny_xdr.cpp', needed by `tiny_xdr.o'. Stop. Can anyone help? Kevin. Kevin, You need to do a make clean and re-./configure before building... The file tiny_xdr.cpp has been renamed tiny_xdr.cxx. You can also just delete the .deps directory under src/MultiPlayer and rerun ./configure ; make. Saves you the long rebuild time. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS compiling error
David Luff wrote: Cygwin doesn't have HUGE, so change HUGE to HUGE_VAL and -HUGE to -HUGE_VAL and I suspect this should compile. Ok, I've committed a fix. I guess that we could do something in compiler.h along the lines of #ifdef __CYGWIN__ #define HUGE HUGE_VAL #define -HUGE -HUGE_VAL #endif or something like that. Erik? There is already an instance of this problem in TerraGear. Maybe someone has to convince the Cygwin developers to add it to the appropriate header files instead? I've seen several projects that have to make special cases just for this. It's better fixed at the root of the problem. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS compiling error
David Luff wrote: Fair point. Do you know if HUGE is part of a standard anywhere that definately should be supplied by Cygwin, or is it simply available from everyone else by unwritten convention? According to the IRIX header file it would be an ANSI definition. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS compiling error
Erik Hofman David Luff wrote: Fair point. Do you know if HUGE is part of a standard anywhere that definately should be supplied by Cygwin, or is it simply available from everyone else by unwritten convention? According to the IRIX header file it would be an ANSI definition. IRIX that is almost as compliant as MSDOS derivitaives where HUGE is a reserved word :-) This is an anachronism from mixed memory model programing on Intel Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS compiling error
The same problem is present using MSYS/Mingw with 5min old cvs.. Georg Vollnhals wrote: David Luff schrieb: Cygwin doesn't have HUGE, so change HUGE to HUGE_VAL and -HUGE to -HUGE_VAL and I suspect this should compile. Changing HUGE to HUGE_VAL in simple.cxx solved the problem! Thank you, thank you :-) Have just made a testflight with the new FG version! I guess that we could do something in compiler.h along the lines of #ifdef __CYGWIN__ #define HUGE HUGE_VAL #define -HUGE -HUGE_VAL #endif I tried this *before* I did the huge-change. I put it between two other #ifdef .. (Microsoft and Borland, as far as I remember) but it caused some other strange errors. May be it was my fault to put it the wrong place or the wrong file (there are two compiler.h files in my Cygwin folder, I changed the one in the SimGear-0.3 .. folder. BTW, Georg, CVS SimGear should compile on Cygwin 3.4.4 now, and CVS FlightGear will probably compile on it if you add #ifdef HAVE_CONFIG_H # include config.h #endif as the first include for every source (cxx or cpp) file where you get the strange error message you reported a while ago. Then send the output of cvs diff -u from the FlightGear directory to Erik, and the 3.4.4 problem should be sorted :-) Ok, this has to be done when I have a little more time than this evening, but I will go for it within the next days and report so that you have some feedback. Thank you once again, David, your help saved the day for me! Regards Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Frank Olaf Sem-Jacobsen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS compiling error
On 19/10/2005 at 12:05 Georg Vollnhals wrote: Hi Erik/Durk? Since your update of simple.cxx/hxx on the 18.10.05 the newest CVS version does not compile anymore :-( Error: simple.cxx: In member function `int FGGroundNetwork::findNearestNode(double, double)': simple.cxx:1331: error: `HUGE' undeclared (first use this function) simple.cxx:1331: error: (Each undeclared identifier is reported only once for each function it appears in.) make[2]: *** [simple.o] Fehler 1 make[1]: *** [all-recursive] Fehler 1 make: *** [all-recursive] Fehler 1 Any solution? Cygwin doesn't have HUGE, so change HUGE to HUGE_VAL and -HUGE to -HUGE_VAL and I suspect this should compile. I guess that we could do something in compiler.h along the lines of #ifdef __CYGWIN__ #define HUGE HUGE_VAL #define -HUGE -HUGE_VAL #endif or something like that. Erik? There is already an instance of this problem in TerraGear. BTW, Georg, CVS SimGear should compile on Cygwin 3.4.4 now, and CVS FlightGear will probably compile on it if you add #ifdef HAVE_CONFIG_H # include config.h #endif as the first include for every source (cxx or cpp) file where you get the strange error message you reported a while ago. Then send the output of cvs diff -u from the FlightGear directory to Erik, and the 3.4.4 problem should be sorted :-) Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS compiling error
Thank you David, now off to work, I'll try it this evening! Regards Georg David Luff schrieb: BTW, Georg, CVS SimGear should compile on Cygwin 3.4.4 now, and CVS FlightGear will probably compile on it if you add .. Then send the output of cvs diff -u from the FlightGear directory to Erik, and the 3.4.4 problem should be sorted :-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS compiling error
David Luff schrieb: Cygwin doesn't have HUGE, so change HUGE to HUGE_VAL and -HUGE to -HUGE_VAL and I suspect this should compile. Changing HUGE to HUGE_VAL in simple.cxx solved the problem! Thank you, thank you :-) Have just made a testflight with the new FG version! I guess that we could do something in compiler.h along the lines of #ifdef __CYGWIN__ #define HUGE HUGE_VAL #define -HUGE -HUGE_VAL #endif I tried this *before* I did the huge-change. I put it between two other #ifdef .. (Microsoft and Borland, as far as I remember) but it caused some other strange errors. May be it was my fault to put it the wrong place or the wrong file (there are two compiler.h files in my Cygwin folder, I changed the one in the SimGear-0.3 .. folder. BTW, Georg, CVS SimGear should compile on Cygwin 3.4.4 now, and CVS FlightGear will probably compile on it if you add #ifdef HAVE_CONFIG_H # include config.h #endif as the first include for every source (cxx or cpp) file where you get the strange error message you reported a while ago. Then send the output of cvs diff -u from the FlightGear directory to Erik, and the 3.4.4 problem should be sorted :-) Ok, this has to be done when I have a little more time than this evening, but I will go for it within the next days and report so that you have some feedback. Thank you once again, David, your help saved the day for me! Regards Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
Ampere K. Hardraade wrote: I have been wondering this for quite a while: will it be a good idea to provide weekly CVS snapshots? Do you mean replace the instant cvs snapshots with snapshots only taken at weekly intervals? :-) http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/source.tar.gz?tarball=1cvsroot=FlightGear-0.9 http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/data.tar.gz?tarball=1cvsroot=FlightGear-0.9 Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
On October 5, 2005 07:58 am, Curtis L. Olson wrote: Do you mean replace the instant cvs snapshots with snapshots only taken at weekly intervals? :-) By cvs snapshots, I mean binary-snapshots packed into .deb, .rpm, etc. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
Ampere K. Hardraade wrote: On October 5, 2005 07:58 am, Curtis L. Olson wrote: Do you mean replace the instant cvs snapshots with snapshots only taken at weekly intervals? :-) By cvs snapshots, I mean binary-snapshots packed into .deb, .rpm, etc. If someone wants to do this, and promises to keep up on it, I can put a link on the FG web site ... 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
On October 5, 2005 01:49 pm, Curtis L. Olson wrote: If someone wants to do this, and promises to keep up on it, I can put a link on the FG web site ... Curt. How should the version number progress? Should it be 0.9.9, 0.9.10, 0.9.11, etc. or 0.9.9.1, 0.9.9.2, 0.9.9.3, etc? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
Ampere K. Hardraade wrote: Curtis L. Olson wrote: Ampere K. Hardraade wrote: By cvs snapshots, I mean binary-snapshots packed into .deb, .rpm, etc. If someone wants to do this, and promises to keep up on it, I can put a link on the FG web site ... How should the version number progress? Should it be 0.9.9, 0.9.10, 0.9.11, etc. or 0.9.9.1, 0.9.9.2, 0.9.9.3, etc? Snapshot builds should generally be identified by their date. Alternatively, you can use a sequential build number, as is common with large commercial projects. But real version numbers typically indicate a distinct release, with a QA process, etc... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
Ampere K. Hardraade writes: On October 5, 2005 01:49 pm, Curtis L. Olson wrote: If someone wants to do this, and promises to keep up on it, I can put a link on the FG web site ... Curt. How should the version number progress? Should it be 0.9.9, 0.9.10, 0.9.11, etc. or 0.9.9.1, 0.9.9.2, 0.9.9.3, etc? Surely one done today would be 0.9.8-20051005 Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS - Cywin Problems
On Tuesday 30 August 2005 20:21, Vivian Meazza wrote: This behaviour has been confirmed by AJ on a similarly specified machine. I would maybe also just add that I was working with a different version of GCC (3.3.3) but obtained identical symptoms to what Vivian has already described. AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS
Neville van Deventer wrote: Hi List, Could anyone perhaps tell me how to connect to the cvs at cvs.flightgear.org without getting the following error Error validating location: I/O exception occurred: Connection refused: I HATE YOU I followed the Instructions on the web-site, and I get the same thing for simgear as well. Any suggestions on how I can connect to the CVS ?? Hmmm, that's not a very nice error message, I'm sure it wasn't meant literally. :-( If you tell me the exact time you tried to connect and what machine you connected from (name/ip) I could look in the server logs to see if there are any clues there. I haven't ever seen this message before so it's hard to say if it's coming from our server, or being generated locally by your cvs client. What platform are you running on? CVS involves the network, so I don't know if there could be some firewall in the middle that is blocking traffic. Do you get long time outs before the error message, or is it returned immediately? Do you have write access to your local cvs tree and enough disk space? That's all I can think of off the top of my head. 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS
Neville van Deventer Hi List, Could anyone perhaps tell me how to connect to the cvs at cvs.flightgear.org without getting the following error Error validating location: I/O exception occurred: Connection refused: I HATE YOU I followed the Instructions on the web-site, and I get the same thing for simgear as well. Any suggestions on how I can connect to the CVS ?? Thanks in Advance Neville van Deventer Works here. What _exactly_ are you doing? Any possibility that you have a virus on your system? Regards, Vivian P.S. Please use plain text on this list ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS
Thanks for the responses Vivian and Curtis, In Future I Will use Plain Text, my Appologies ... OK, Setup and what I'm Doing, I Just tried it now again, while writing this message so you can check the logs for the past 5 min's or so, I've been thying this most of the day, but with no success. I'm using the guest username and password as described on the Web Page. I'm running Windows XP Professional operating System, Eclipse IDE as my Dev Environment, I Currently have 5 other cvs repositories,( 1 local and 3 on the Net codehaus.org, objectweb.org, and sourceforge.net). My IP Address is 198.54.42.106 which my alternate is 198.54.42.107, we have a 256K line, connection is via a PIX Firewall. Host name is NEVILLE_HP, and it takes about 5 seconds after clicking connect to get the message. No Outgoing ports are blocked at this time and limited ports are allowed in. No Virus on my system, I Update regularely, using Norton corporate Edition. Disk space I Also thought might be a problem so I Cleared up some space (Currently I've got about 3.5G Free). I Think that's about it... Thanks in Advance for the Help. Neville PS: Sorry about not using plain text originally. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vivian Meazza Sent: 20 July 2005 06:04 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] CVS Works here. What _exactly_ are you doing? Any possibility that you have a virus on your system? Regards, Vivian P.S. Please use plain text on this list ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS
Neville van Deventer wrote: Error validating location: I/O exception occurred: Connection refused: I HATE YOU Heh, that's amusing. I googled this, and it turns out that I HATE YOU is the defined response in the CVS protocol for authentication failures. :) You may have a bad password in your .cvspass file. Try removing any flightgear.org lines, or removing the whole file. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS
Neville van Deventer Thanks for the responses Vivian and Curtis, In Future I Will use Plain Text, my Appologies ... OK, Setup and what I'm Doing, I Just tried it now again, while writing this message so you can check the logs for the past 5 min's or so, I've been thying this most of the day, but with no success. I'm using the guest username and password as described on the Web Page. This definitely works cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.9 login CVS password: guest I've just tried it. Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS
Done, Sorted, I've got a connection now, Thanks Nev -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Ross Sent: 20 July 2005 06:41 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] CVS Neville van Deventer wrote: Error validating location: I/O exception occurred: Connection refused: I HATE YOU Heh, that's amusing. I googled this, and it turns out that I HATE YOU is the defined response in the CVS protocol for authentication failures. :) You may have a bad password in your .cvspass file. Try removing any flightgear.org lines, or removing the whole file. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS for OpenAL
bass pumped wrote: Martin Spott wrote: bass pumped wrote: The website says the password is 'guest'. It doesn't work for me! just stalls!! Why do you yell at me !? I'm sorry... I didn't think I was yelling at you. But if u feel I did so, I sincerely apologize, that was not my intention. I know why The vertical bar with a dot at the bottom is called an exclamation point! When you use it (Like this!!!) it makes what you type very loud! While that might be fun, it makes it difficult for other people to understand your tone!!! Are you angry? Sad?? Or just exited?!?? See what I mean???!? Seriously, written communication is hard. Just like with verbal communication, calmly explaining a situation and nicely asking for help is more likely to get results than using chat room jargon and incomplete sentences. Remember that many of us are old enough to have been tought to read and write on paper, and honestly don't speak the same written language. Sticking to standard English will make it much easier for folks like me to understand U. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS for OpenAL
Simon Hollier wrote: Andy Ross wrote: [...] tought [...] ...and some of us were taught ; Oh, the irony! Mea culpa. But it would only have been ironic if I were criticizing spelling, not usage. You didn't punctuate your first sentence, by the way. Smileys don't count. And your usage of the ellipsis is non-standard; it should represent missing text. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS for OpenAL
Andy Ross wrote: Simon Hollier wrote: Andy Ross wrote: [...] tought [...] ...and some of us were taught ; Oh, the irony! Mea culpa. But it would only have been ironic if I were criticizing spelling, not usage. You didn't punctuate your first sentence, by the way. Smileys don't count. And your usage of the ellipsis is non-standard; it should represent missing text. It did represent missing text: Some of use were tought, Mea culpa. s/irony/pedantry/g Simon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS for OpenAL
Simon Hollier wrote: Andy Ross wrote: And your usage of the ellipsis is non-standard; it should represent missing text. It did represent missing text: Some of use were tought, Except that text wasn't missing. You quoted it, remember? And even if not, it was *my* text and can't be inserted into your sentence using an ellipsis. Just give up, you can't win. :) The original point was serious, by the way. Screaming at developers is a bad way to get tech support, and bass pumped didn't seem to understand why Martin was annoyed. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS for OpenAL
Andy Ross wrote: Simon Hollier wrote: Andy Ross wrote: And your usage of the ellipsis is non-standard; it should represent missing text. It did represent missing text: Some of use were tought, Except that text wasn't missing. You quoted it, remember? And even if not, it was *my* text and can't be inserted into your sentence using an ellipsis. Just give up, you can't win. :) Fair enough, but I could win ;) The original point was serious, by the way. Screaming at developers is a bad way to get tech support, and bass pumped didn't seem to understand why Martin was annoyed. Agreed! Simon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS for OpenAL
Simon Hollier Andy Ross wrote: Simon Hollier wrote: Andy Ross wrote: And your usage of the ellipsis is non-standard; it should represent missing text. It did represent missing text: Some of use were tought, Except that text wasn't missing. You quoted it, remember? And even if not, it was *my* text and can't be inserted into your sentence using an ellipsis. Just give up, you can't win. :) Fair enough, but I could win ;) The original point was serious, by the way. Screaming at developers is a bad way to get tech support, and bass pumped didn't seem to understand why Martin was annoyed. Agreed! Meanwhile, you are distracting Andy from updating the awaited supercharger code. Being careful with both syntax and spelling, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS for OpenAL
Point taken. Will correct. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS for OpenAL
I give up... could someone save me the suffering and mail me a tarball of openal they have to this address? I've decided cvs hates me lol... kind of reminds me of Martin's signature on all his posts!! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS for OpenAL
bass pumped wrote: Sorry to bother you guys... I know this is unrelated but I have to ask. Are you able to access CVS for OpenAL? Yes, I do this already for months at least since FlightGear uses OpenAL. I did the initial checkout using this command: cvs -d:pserver:[EMAIL PROTECTED]:/usr/local/cvs-repository co openal after doing a CVS login. I don't remember the password, though .. Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS for OpenAL
Yes, I do this already for months at least since FlightGear uses OpenAL. I did the initial checkout using this command: cvs -d:pserver:[EMAIL PROTECTED]:/usr/local/cvs-repository co openal after doing a CVS login. I don't remember the password, though .. The website says the password is 'guest'. It doesn't work for me! just stalls!! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS for OpenAL
cvs -d:pserver:[EMAIL PROTECTED]:/usr/local/cvs-repository co openal I tried this command too!! nothing happened. it just sits. Didn't even ask me for a password. I am using Fedora Core 2. Does this have anything to do with it? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS for OpenAL
bass pumped wrote: after doing a CVS login. I don't remember the password, though .. The website says the password is 'guest'. It doesn't work for me! just stalls!! Why do you yell at me !? Probably you are using a firewall which blocks your attempts - just an idea, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS for OpenAL
Why do you yell at me !? I'm sorry... I didn't think I was yelling at you. But if u feel I did so, I sincerely apologize, that was not my intention. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS for OpenAL
bass pumped wrote: The website says the password is 'guest'. It doesn't work for me! just stalls!! Try enter (no password). I works for me. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS for OpenAL
On Tue, 2005-06-28 at 08:23, bass pumped wrote: cvs -d:pserver:[EMAIL PROTECTED]:/usr/local/cvs-repository co openal I tried this command too!! nothing happened. it just sits. Didn't even ask me for a password. I am using Fedora Core 2. Does this have anything to do with it? It's not Fedora Core 2 per se. I checked out OpenAl a while back with no trouble on FC2. Not tried updating recently, but last time I did, that happened just fine too. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Quoting Curtis L. Olson : Time out here! There are two reasons two throttle frame rate. 1. Conserve CPU time and leave more cpu time for other tasks. Using sleep() calls you can put FG asleep for a short time if it gets done drawing a frame early, leaving those cycles for other tasks. 2. Accurately control frame rate. Here you want to run at a fixed precise frame rate to achieve smooth, jitter free rendering. For instance, if you can't quite sustain 60hz consistanty, you might want to throttle back to 30hz. The problem is that this new patch throws away the second reason in favor of the first. When I throttle to 20hz, I get 19hz. When I throttle to 30hz I get, ohh ... 28 or 29 depending. Putting the application to sleep does terrible things to timing accuracy, because typically the application can only wake up during a kernel trap, and if you miss the vertical refresh by even 1 millesecond, you drop a frame and get animation jitters. Maybe we need to figure out how to satisfy both needs, but we can't just blindly dispense with reason #2 when a new need comes along. Maybe we need separate options, such as --cpu-friendly-inaccurate-throttle-with-sleep-hz= and --frame-rate-accurate-throttle= Thoughts? I think we need to tread a bit more carefully on this one, especially since I have a side project that employs this option (well, used to employ this option) :-( to achieve accurate frame rate timing and smooth animation. Maybe it is doable to sleep for a millisecond less than computed and achieve the targeted framerate with the loop. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
I wrote:
Maybe it is doable to sleep for a millisecond less than computed and achieve
the
targeted framerate with the loop.
Could you try this patch :
cvs -z4 -q diff -u main.cxx (in directory
I:\FlightGear\cvs\FlightGear\src\Main\)
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.194
diff -u -r1.194 main.cxx
--- main.cxx9 Mar 2005 15:12:01 - 1.194
+++ main.cxx9 Mar 2005 16:53:34 -
@@ -233,12 +233,11 @@
double throttle_hz = fgGetDouble(/sim/frame-rate-throttle-hz, 0.0);
if ( throttle_hz 0.0 scenery_loaded ) {
-static double remainder = 0.0;
-
// simple frame rate throttle
-double dt = 100.0 / throttle_hz + remainder;
+double dt = 100.0 / throttle_hz;
int wait = dt / 1000;
-remainder = dt - ( wait * 1000.0 );
+if ( wait 0 )
+wait -= 1;
current_time_stamp.stamp();
int t_ms = (int) ( ( current_time_stamp - last_time_stamp ) / 1000 ) ;
/* Convert to ms */
@@ -246,6 +245,9 @@
ulMilliSecondSleep ( wait - t_ms ) ;
}
current_time_stamp.stamp();
+while ( current_time_stamp - last_time_stamp dt ) {
+current_time_stamp.stamp();
+}
} else {
// run as fast as the app will go
current_time_stamp.stamp();
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Frederic,
Your patch helps, but typically the semantics of sleep() commands is
they will sleep at least as long as the requested time (up to the kernel
trap timing resolution) so I am still seeing dropped frames, although
not nearly as bad. If the kernel timing resolution is different than
the monitor refresh resolution with no convenient multiples (i.e. 60hz
vs 100hz), it's always going to be imperfect.
Regards,
Curt.
Frederic Bouvier wrote:
Could you try this patch :
cvs -z4 -q diff -u main.cxx (in directory
I:\FlightGear\cvs\FlightGear\src\Main\)
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.194
diff -u -r1.194 main.cxx
--- main.cxx9 Mar 2005 15:12:01 - 1.194
+++ main.cxx9 Mar 2005 16:53:34 -
@@ -233,12 +233,11 @@
double throttle_hz = fgGetDouble(/sim/frame-rate-throttle-hz, 0.0);
if ( throttle_hz 0.0 scenery_loaded ) {
-static double remainder = 0.0;
-
// simple frame rate throttle
-double dt = 100.0 / throttle_hz + remainder;
+double dt = 100.0 / throttle_hz;
int wait = dt / 1000;
-remainder = dt - ( wait * 1000.0 );
+if ( wait 0 )
+wait -= 1;
current_time_stamp.stamp();
int t_ms = (int) ( ( current_time_stamp - last_time_stamp ) / 1000 ) ;
/* Convert to ms */
@@ -246,6 +245,9 @@
ulMilliSecondSleep ( wait - t_ms ) ;
}
current_time_stamp.stamp();
+while ( current_time_stamp - last_time_stamp dt ) {
+current_time_stamp.stamp();
+}
} else {
// run as fast as the app will go
current_time_stamp.stamp();
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Sorry to borrow this thread for my own purpose, but I'm trying to
achieve goal 1 with as little impact on goal 2 as possible. I tried
this patch with mixed results.
In Windows, adding this code did absolutely nothing to the processing
time...it remains at 99% usage whether I throttle back to 60, 30, or 1
Hz. However, in an effort to debug this problem, I switched the
compiler flags (VisualStudio) from 'release' to 'debug' mode. Once
iit was compiled in 'debug' mode, the throttle_frame_rate actually
yielded some processing ttime for other processes. It runs better,
but still not ideal. Anyway, does anyone have any hypotheses as to
what's causing this difference?
BTW, I was going to suggest having a 'cumulative' target time that
gaurantees an average frame time rather than a minimum frame time, but
it appears Fredric beat me to the punch. :)
Drew
On Wed, 09 Mar 2005 09:51:47 -0600, Curtis L. Olson
[EMAIL PROTECTED] wrote:
Time out here!
There are two reasons two throttle frame rate.
1. Conserve CPU time and leave more cpu time for other tasks. Using
sleep() calls you can put FG asleep for a short time if it gets done
drawing a frame early, leaving those cycles for other tasks.
2. Accurately control frame rate. Here you want to run at a fixed
precise frame rate to achieve smooth, jitter free rendering. For
instance, if you can't quite sustain 60hz consistanty, you might want to
throttle back to 30hz.
The problem is that this new patch throws away the second reason in
favor of the first. When I throttle to 20hz, I get 19hz. When I
throttle to 30hz I get, ohh ... 28 or 29 depending. Putting the
application to sleep does terrible things to timing accuracy, because
typically the application can only wake up during a kernel trap, and if
you miss the vertical refresh by even 1 millesecond, you drop a frame
and get animation jitters.
Maybe we need to figure out how to satisfy both needs, but we can't just
blindly dispense with reason #2 when a new need comes along.
Maybe we need separate options, such as
--cpu-friendly-inaccurate-throttle-with-sleep-hz= and
--frame-rate-accurate-throttle=
Thoughts? I think we need to tread a bit more carefully on this one,
especially since I have a side project that employs this option (well,
used to employ this option) :-( to achieve accurate frame rate timing
and smooth animation.
Curt.
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv28989
Modified Files:
main.cxx
Log Message:
Frederic Bouvier:
Norman Vine wrote :
Frederic Bouvier writes:
Quoting Andy Ross:
* Hopefully in a CPU-friendly way. I know that older versions of
the NVidia drivers did this by spinning in a polling loop
inside the driver. I'm not sure if this has been fixed or not.
From my experience, the latest non-beta Windows NVidia driver seems to
eat CPU
even with sync to vblank enabled. The CPU usage is always 100%.
Buried in the PPE sources is a 'hackish' but portable way to limit CPU
usage if the desired framerate is met
/*
Frame Rate Limiter.
This prevents any one 3D window from updating faster than
about 60Hz. This saves a ton of CPU time on fast machines.
! I THINK I MUNGED THE VALUE FOR ulMilliSecondSleep() NHV !
*/
static ulClock *ck = NULL ;
if ( frame_rate_limiter )
{
if ( ck == NULL )
{
ck = new ulClock ;
ck - update () ;
}
int t_ms = (int) ( ck-getDeltaTime() * 1000.0 ) ; /* Convert to ms */
if ( t_ms 16 )
ulMilliSecondSleep ( 16 - t_ms ) ;
}
I implemented the method pointed out by Norman. It works great on windows
and saves me a lot of CPU cycles. This way, I can get the same framerate in
moderately populated areas and have CPU idle 50% of the time instead of
wildly looping in the NVidia driver while waiting to sync on vblank.
It has been tested on Linux by Melchior. He saw the same gain in CPU cycles.
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.193
retrieving revision 1.194
diff -C2 -r1.193 -r1.194
*** main.cxx 5 Jan 2005 05:45:38 - 1.193
--- main.cxx 9 Mar 2005 15:12:01 - 1.194
***
*** 223,226
--- 223,228
SGCloudLayer::enable_bump_mapping =
fgGetBool(/sim/rendering/bump-mapping);
+ bool scenery_loaded = fgGetBool(sim/sceneryloaded) ||
fgGetBool(sim/sceneryloaded-override);
+
// Update the elapsed time.
static bool first_time = true;
***
*** 231,241
double throttle_hz = fgGetDouble(/sim/frame-rate-throttle-hz, 0.0);
! if ( throttle_hz 0.0 ) {
// simple frame rate throttle
! double dt = 100.0 / throttle_hz;
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Curtis L. Olson wrote: Frederic, Your patch helps, but typically the semantics of sleep() commands is they will sleep at least as long as the requested time (up to the kernel trap timing resolution) so I am still seeing dropped frames, although not nearly as bad. If the kernel timing resolution is different than the monitor refresh resolution with no convenient multiples (i.e. 60hz vs 100hz), it's always going to be imperfect. Here is some additional data. I note the requested sleep time, then measure the actual sleep time. If the sleep time is greater thanTimes are in milleseconds ... requested = 5 actual = 6.898 requested = 6 actual = 7.998 requested = 6 actual = 7.269 requested = 5 actual = 6.358 requested = 2 actual = 3.230 requested = 7 actual = 8.972 So it looks like at least on the linux kernel-2.6.x you can get pretty fine sleep resolution, but it's always a few milleseconds more than you asked for. Usually the sleep overshoot is 1,2, or even 3 milleseconds, but I did some tracking and saw it as high as 17 milleseconds on occasion. Backing off and sleeping 1 ms less than the target helped, but you'd probably have to back off 2-3 for more consistant results, and at least 17ms for perfect results. I don't think is possible to do accurate millesecond timing with a sleep command on consumer operating systems. You can get close, but not close enough, because if you drop even one frame a second, your eye can spot it and notice the animation jitter. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Curtis L. Olson wrote: Maybe we need separate options, such as --cpu-friendly-inaccurate-throttle-with-sleep-hz= and --frame-rate-accurate-throttle= Thoughts? I think we need to tread a bit more carefully on this one, especially since I have a side project that employs this option (well, used to employ this option) :-( to achieve accurate frame rate timing and smooth animation. What was the original bug report? Currently, FlightGear will look CPU-limited to the OS, which means that short running or I/O bound processes will get priority anyway. What is the application that needs extra CPU, and are we sure that it's not being performance limited in some other way? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
I asked: What is the application that needs extra CPU, and are we sure that it's not being performance limited in some other way? Aha! Drew wrote: In Windows, adding this code did absolutely nothing to the processing time...it remains at 99% usage whether I throttle back to 60, 30, or 1 Hz. [...] Once iit was compiled in 'debug' mode, the throttle_frame_rate actually yielded some processing ttime for other processes. It runs better, but still not ideal. Wait, that's not a bug report about processing time available for other proceses at all. That's a bug report about the total CPU usage being at 99%, which is irrelevant. If the CPU is available, then of course FlightGear should use it all; you can't save up cycles -- either use them now or let them go to waste. Which app are you running that is going too slow, and how much CPU do you think it needs? Those are the important questions. Your OS (yes, even windows) has an elaborate scheduler which is designed to make sure that all processes get the CPU they need to do their job. Sometimes you need to tweak things, but those circumstances are rare. I strongly suspect we're chasing a ghost on this one. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Wait, that's not a bug report about processing time available for other proceses at all. That's a bug report about the total CPU usage being at 99%, which is irrelevant. If the CPU is available, then of course FlightGear should use it all; you can't save up cycles -- either use them now or let them go to waste. I don't think anyone suggested there was a bug...I'm just trying to improve performance. I'm writing a simulator that interfaces with FlightGear, using FlightGear as the scenery generator on the same PC. The program runs great, it's just that FlightGear gets interrupted easily by other programs, and is jumpy in my particular application. If you open and close a window, you can see how FlightGear freezes momentarily. What I want to do is bump up the priority of FlightGear so that it is more robust. The problem I'm having is that once I do, everything else comes to a screeching halt. Therefore, I want FlightGear to be more conservative with its processor usage, so I can increase its priority without adversely affecting other processes. I don't understand what you mean about 'using them or let them go to waste'. If it takes FlightGear 10 ms to execute a frame, and I only need a frame time of 33 ms, what gain is there in FlightGear hijacking those other 23 ms, even if it is just idle time? Just because it's taking those cycles doesn't mean it's using them productively. Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Drew wrote: I don't think anyone suggested there was a bug...I'm just trying to improve performance. I'm writing a simulator that interfaces with FlightGear, using FlightGear as the scenery generator on the same PC. The program runs great, it's just that FlightGear gets interrupted easily by other programs, and is jumpy in my particular application. If you open and close a window, you can see how FlightGear freezes momentarily. Hi Drew, Typically, operating systems run their windows manager and user interface stuff at a high priority (which makes the operating system seem snappy and responsive.) So opening/closing windows, resizing them, moving them, etc. will kill performance of anything else you are running. That's usually ok and you never notice it if all you are doing is running email and web browsing and word processing type apps, but it's a killer if you are expecting to sustain performance of a real time 3d application at the same time. What I want to do is bump up the priority of FlightGear so that it is more robust. The problem I'm having is that once I do, everything else comes to a screeching halt. Therefore, I want FlightGear to be more conservative with its processor usage, so I can increase its priority without adversely affecting other processes. The proposed sleep() based frame rate throttling patch may help with that because it puts FG to sleep every frame (which should automatically yield the CPU to anything else in the run queue.) However, the proposed patch also messes up the consistancy of frame rates because the way sleep() is implimented, you can't actually sleep() for the exact time you want. You never sleep less than the requested amount but you often/usually sleep somewhat longer than the requested time. So if you are trying to eliminate frame rate jitter, this is not going to help you reach a perfect solution (but it may improve things under certain circumstances for certain people.) I don't understand what you mean about 'using them or let them go to waste'. If it takes FlightGear 10 ms to execute a frame, and I only need a frame time of 33 ms, what gain is there in FlightGear hijacking those other 23 ms, even if it is just idle time? Just because it's taking those cycles doesn't mean it's using them productively. The issue is that FG needs to hijack these CPU cycles to do precise timing and to know when to move on to work on the next frame. If you don't mind dropping frames right and left, a sleep() based solution will free up those cpu cycles for other apps to use, but you may sacrifice consistancy of frame rate (or at least you will never be able to achieve perfectly consistant frame rates.) I have a specific application that requires better timing than sleep() can provide, so I need the original busy-wait solution or something very close to it. I don't mind adding a sleep() based throttling mechanism as well, but people who use it need to realize it's limitations. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Thanks for the quick response. I have a specific application that requires better timing than sleep() can provide, so I need the original busy-wait solution or something very close to it. I don't mind adding a sleep() based throttling mechanism as well, but people who use it need to realize it's limitations. I understand that. I'm not looking to change the FlightGear baseline...just a solution that does what I need. How precise is the timing of the naitive-gui ? If I have my simulation use a blocking socket to receive messages, this can provide the interrupt to schedule my simulation. The only problem there would be that if a packet is dropped, the simulation will miss a frame (unlikely if they're on the same PC). Does native-gui run in its own thread, or is it limited to FlightGear's frame rate? I'm just brainstorming here...I still don't know what my ideal solution is. Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Drew wrote: The program runs great, it's just that FlightGear gets interrupted easily by other programs, and is jumpy in my particular application. If you open and close a window, you can see how FlightGear freezes momentarily. I don't wonder, though, if that isn't due to locking inside GDI (or VM swap -- how much memory do you have?) and not CPU usage. Applications doing 3D rendering don't coexist well with things that need to draw to the screen. Can you try something purely CPU intensive (like a perl script that counts to a few million) and see if you can notice the same behavior? My guess is that tuning FlightGear's CPU usage isn't going to get us much. Conversely, can you compare FlightGear to other spin on the cpu 3D applications like games? Do they exhibit the same issues? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
I don't wonder, though, if that isn't due to locking inside GDI (or VM swap -- how much memory do you have?) and not CPU usage. Applications doing 3D rendering don't coexist well with things that need to draw to the screen. Can you try something purely CPU intensive (like a perl script that counts to a few million) and see if you can notice the same behavior? My guess is that tuning FlightGear's CPU usage isn't going to get us much. Conversely, can you compare FlightGear to other spin on the cpu 3D applications like games? Do they exhibit the same issues? I don't know the answer to this. My computer has 512 megs, which is a lot more than FlightGear uses. I'm not really interested in how other 3D apps, including games, work...I have a specific application, and I want to optimize the code for this purpose, regardless of what the status quo is. FWIW, I've tried an interface with x-plane, and it doesn't have the same problem. Too bad it isn't open-source. Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Drew wrote: I don't know the answer to this. My computer has 512 megs, which is a lot more than FlightGear uses. I'm not really interested in how other 3D apps, including games, work...I have a specific application, and I want to optimize the code for this purpose, regardless of what the status quo is. FWIW, I've tried an interface with x-plane, and it doesn't have the same problem. Too bad it isn't open-source. Doesn't X-Plane run full screen, or does it now support running in a window. If you are running x-plane full screen you are probably comparing apples to oranges here. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Frederic,
I've been hacking on your patch a bit more and I see that we rarely
oversleep by more than 2ms. So backing off by 2ms (instead of 1ms)
seems to work pretty well here. I also switched to doing all the math
in microseconds rather than milleseconds (and converting at the latest
possible moment) in hopes that it would be slighty more accurate.
This is only tested on the 2.6.x kernels. I suspsect that usleep() will
be much less accurate on 2.4.x kernels. I don't know if anyone else is
using the frame rate throttling feature so it may not matter?
Regards,
Curt.
Frederic Bouvier wrote:
I wrote:
Maybe it is doable to sleep for a millisecond less than computed and achieve
the
targeted framerate with the loop.
Could you try this patch :
cvs -z4 -q diff -u main.cxx (in directory
I:\FlightGear\cvs\FlightGear\src\Main\)
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.194
diff -u -r1.194 main.cxx
--- main.cxx9 Mar 2005 15:12:01 - 1.194
+++ main.cxx9 Mar 2005 16:53:34 -
@@ -233,12 +233,11 @@
double throttle_hz = fgGetDouble(/sim/frame-rate-throttle-hz, 0.0);
if ( throttle_hz 0.0 scenery_loaded ) {
-static double remainder = 0.0;
-
// simple frame rate throttle
-double dt = 100.0 / throttle_hz + remainder;
+double dt = 100.0 / throttle_hz;
int wait = dt / 1000;
-remainder = dt - ( wait * 1000.0 );
+if ( wait 0 )
+wait -= 1;
current_time_stamp.stamp();
int t_ms = (int) ( ( current_time_stamp - last_time_stamp ) / 1000 ) ;
/* Convert to ms */
@@ -246,6 +245,9 @@
ulMilliSecondSleep ( wait - t_ms ) ;
}
current_time_stamp.stamp();
+while ( current_time_stamp - last_time_stamp dt ) {
+current_time_stamp.stamp();
+}
} else {
// run as fast as the app will go
current_time_stamp.stamp();
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Drew wrote: I'm not really interested in how other 3D apps, including games, work...I have a specific application, and I want to optimize the code for this purpose, regardless of what the status quo is. And the proper way to do that optimization is to figure out what the actual symptom is. Which requires testing a hypothesis (is it due to CPU usage?) by changing one parameter (open a window vs. run a looping perl script) at a time in order to isolate the symptom (complicated window system interaction vs. pure CPU usage). It seems to me that you have gone backwards: you picked a favorite fix before knowing what the problem is. The bottom line is that performance analysis is really complicated. You can't cook it down to a single number like CPU usage (or load -- a equally flawed Unix favorite) if you really want to fix a problem. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Curtis L. Olson wrote : Frederic, I've been hacking on your patch a bit more and I see that we rarely oversleep by more than 2ms. So backing off by 2ms (instead of 1ms) seems to work pretty well here. I also switched to doing all the math in microseconds rather than milleseconds (and converting at the latest possible moment) in hopes that it would be slighty more accurate. This is only tested on the 2.6.x kernels. I suspsect that usleep() will be much less accurate on 2.4.x kernels. I don't know if anyone else is using the frame rate throttling feature so it may not matter? Do you want to check it that way or do you want separated behavior : exact framerate vs CPU friendly ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
It seems to me that you have gone backwards: you picked a favorite fix before knowing what the problem is. The bottom line is that performance analysis is really complicated. You can't cook it down to a single number like CPU usage (or load -- a equally flawed Unix favorite) if you really want to fix a problem. Hey Andy, I know for a fact that FlightGear uses every available processor cycle. I also know that if I increase the priority of FlightGear, it takes cycles away from other processes. In my application, I need FlightGear to run at 640x480 res at 30 Hz (the output is a TV), but I've seen FlightGear run well at 1400x1050 and 60 Hz. Therefore, I *know* FlightGear is using much more CPU cycles than it needs, and I know that if there's a way to free up these extra cycles, I can run FlightGear at a higher priority without interrupting other processes. Does this not seem like a rational train of thought? I admit, I'm new to this type of performance optimization. What do *you* think the problem is? Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
X-Plane opens in a 1024x768 borderless window, which doesn't fill my laptop display at 1400x1050. However, when I reduce and restore windows, I can tell that the X-Plane process preempts the windows processes because the windows open slowly. X-Plane still yields some time to the windows, though, unlike what happens if I increase the priority of FlightGear. BTW, this patch with the Sleep calls still doesn't seem to be working for me...when I increase flightgear's priority it still completely takes over the system. Is there another thread that might be doing this? Drew On Wed, 09 Mar 2005 13:53:36 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: Drew wrote: I don't know the answer to this. My computer has 512 megs, which is a lot more than FlightGear uses. I'm not really interested in how other 3D apps, including games, work...I have a specific application, and I want to optimize the code for this purpose, regardless of what the status quo is. FWIW, I've tried an interface with x-plane, and it doesn't have the same problem. Too bad it isn't open-source. Doesn't X-Plane run full screen, or does it now support running in a window. If you are running x-plane full screen you are probably comparing apples to oranges here. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS Build on Cygwin
attached find my home grown Makefile to use copy it into $OPENAL/win and excute make You will have to figure out how to install it dll(s) go into $BIN .a(s) go into $LIB $OPENAL/include/AL/*.* go into $INCLUDE/AL -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Wojnaroski Sent: Friday, December 31, 2004 10:49 AM To: FlightGear developers discussions Subject: [Flightgear-devel] CVS Build on Cygwin Hi, Could not find any info on the OpenAL website regards building the libraries on Cygwin. So tried the linux build. Well, it built, but thinking the install is suspect and Simgear complains as well. The headers are in /usr/local/include and the .a library is in /usr/local/lib along with a .dll file Any hints, info, suggestions on fixing the problem... Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d GNUMakefile Description: Binary data ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Build on Cygwin
John Wojnaroski wrote: Any hints, info, suggestions on fixing the problem... I think there's already a working OpenAL package here: ftp://ftp.uni-duisburg.de:/FlightGear/Win32/openal_cyg.tgz Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Build on Cygwin
- Original Message - From: Norman Vine [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@flightgear.org Sent: Friday, December 31, 2004 8:09 AM Subject: RE: [Flightgear-devel] CVS Build on Cygwin attached find my home grown Makefile to use copy it into $OPENAL/win and excute make You will have to figure out how to install it dll(s) go into $BIN .a(s) go into $LIB $OPENAL/include/AL/*.* go into $INCLUDE/AL Okay, problem solved. Used the quicker version noted by Martin with built libraries. Need to download the DirectX SDK to get the header files like dsound.h to recompile. Do that later. Thanks John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS - Problem compiling under Cygwin
I wrote: This morning I updated FGFS cvs and tried to compile under Cygwin - it failed with configure: creating ./config.status config.status: creating \ .infig.status: error: cannot find input file: \ This evening I downloaded the whole file system to a new directory - same result. There are no other obvious faults: plib and SimGear are the correct versions. Any ideas? Or is cvs broken? Problem solved - I just did it all over (a couple of times). It finally gave in and compiled. Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Error?
John Wojnaroski wrote: Hi, I may have posted this late last night, but seems to have been lost. If a duplicate post, my apologies Compiling the CVS pre-release error in FGNozzle.cxx complaining about snprintf as implicit declaration at line #74 Currently running 0.9.5 Did I miss something skipping over 0.9.6? I believe Erik just synced the flightgear tree up with the latest JSBsim cvs, so there could be some portability issue that has crept in. I haven't had a chance to compile the latest cvs commits myself. With these sorts of errors I would do a man snprintf on your system. See what #includes the man page suggests. Add those to the offending file. Most likely the proper includes are not there. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS Error?
#include stdio.h #if defined(WIN32) !defined(__CYGWIN__) #define snprintf _snprintf #endif -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Wojnaroski Sent: Friday, December 17, 2004 11:33 AM To: FlightGear developers discussions Subject: [Flightgear-devel] CVS Error? Hi, I may have posted this late last night, but seems to have been lost. If a duplicate post, my apologies Compiling the CVS pre-release error in FGNozzle.cxx complaining about snprintf as implicit declaration at line #74 Currently running 0.9.5 Did I miss something skipping over 0.9.6? Regards JW ___ 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] CVS Error?
On Fri, 17 Dec 2004 10:49:56 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: I believe Erik just synced the flightgear tree up with the latest JSBsim cvs, so there could be some portability issue that has crept in. I haven't had a chance to compile the latest cvs commits myself. It's definitely not generic: I just synced to CVS and built on linux with no problem at all. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpLNwupCPY2F.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Error?
That was it. The other modules explicitly call out the include directive and ifdef, but they appear to be excluded in the JSBSim files ? seems like something is missing/mis-set on my system , if others are not having this problem. At any rate, adding it in for the complaining files will work for the interim Thanks John W. Norman Vine wrote: #include stdio.h #if defined(WIN32) !defined(__CYGWIN__) #define snprintf _snprintf #endif -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Wojnaroski Sent: Friday, December 17, 2004 11:33 AM To: FlightGear developers discussions Subject: [Flightgear-devel] CVS Error? Hi, I may have posted this late last night, but seems to have been lost. If a duplicate post, my apologies Compiling the CVS pre-release error in FGNozzle.cxx complaining about snprintf as implicit declaration at line #74 Currently running 0.9.5 Did I miss something skipping over 0.9.6? Regards JW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Error?
On Fri, 17 Dec 2004 11:35:24 -0800 John Wojnaroski [EMAIL PROTECTED] wrote: That was it. The other modules explicitly call out the include directive and ifdef, but they appear to be excluded in the JSBSim files ? seems like something is missing/mis-set on my system , if others are not having this problem. At any rate, adding it in for the complaining files will work for the interim Thanks John W. Thanks for pointing this out, and thanks to Norman for pointing out the fix. It looks like this was inadvertently removed at some point - probably by me. We need to work on eliminating the need for the snprintf function if it's not portable. Thanks, Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS and file moves
On Thu, 09 Dec 2004 09:32:46 +0100, Erik Hofman [EMAIL PROTECTED] wrote: Is there a clean way to move files in a CVS repository from one directory to another for a reorganization? No, that is one of the shortcomings of CVS. The only way is deleting it and adding it at the new location. In the case of SourceForge, that is probably true, unless Jon has shell access. If you have full filesystem access to the CVS repository, it is possible to move files around with a little work. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS and file moves
I've got shell access to SourceForge, but not to the cvs machine itself. I don't think I'd want to play with that, anyhow. This won't be a showstopper, just a minor inconvenience. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Megginson Sent: Thursday, December 09, 2004 8:01 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] CVS and file moves On Thu, 09 Dec 2004 09:32:46 +0100, Erik Hofman [EMAIL PROTECTED] wrote: Is there a clean way to move files in a CVS repository from one directory to another for a reorganization? No, that is one of the shortcomings of CVS. The only way is deleting it and adding it at the new location. In the case of SourceForge, that is probably true, unless Jon has shell access. If you have full filesystem access to the CVS repository, it is possible to move files around with a little work. All the best, David -- http://www.megginson.com/ ___ 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] CVS and file moves
On Donnerstag 09 Dezember 2004 00:51, Jon S Berndt wrote: Is there a clean way to move files in a CVS repository from one directory to another for a reorganization? Only by modifying the repository files itself. But you *need* to know what you are doing. What do you want to move? 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] CVS: source/src/Instrumentation mag_compass.cxx, 1.6, 1.7
On Sun, 7 Nov 2004 12:32:41 +0100, Roy Vegard Ovesen [EMAIL PROTECTED] wrote: My motivation for setting the serviceable property to true in the source code was that now that the instruments are configureable they can have an arbitrary name in the property tree. The compass could for example be named /Instrumentation/magnetic-heading-indicator-thingy. As I understood it the serviceable property used to (actually still does) be set to true in preferences.xml, where it is set for all instrumentation. If the source code modules force the property to true, it will override any settings provided by the user at startup or in a configuration file. It needs to be possible to start FlightGear with the mag compass U/S for some scenarios, just as we can start with the vacuum pump or alternator U/S. So setting it to true in preferences is would not be a good solution when (not if) aircraft designers decide to change the name of the instrumentation, remove instrumentation that are not applicable to that aircraft, and add more instrumentation for for example redundancy. Making the compass serviceable should be part of that. If the setting is in preferences.xml (or a separate startup config file), it can be overridden on the command line; if it is hard-coded in the C++, it will be set after the options have been read, and cannot be overridden. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: source/src/Instrumentation mag_compass.cxx, 1.6, 1.7
On Monday 08 November 2004 00:22, David Megginson wrote: If the source code modules force the property to true, it will override any settings provided by the user at startup or in a configuration file. I see. It needs to be possible to start FlightGear with the mag compass U/S for some scenarios, just as we can start with the vacuum pump or alternator U/S. Yes, that makes sense. Making the compass serviceable should be part of that. If the setting is in preferences.xml (or a separate startup config file), it can be overridden on the command line; if it is hard-coded in the C++, it will be set after the options have been read, and cannot be overridden. I thought (or rather hoped) that preferences.xml, *-set.xml or command line would set properties after the source code did. IIRC I added this to most instrumentation modules and system modules, so that has to be removed then. I still feel that the setting of the serviceable property for instrumentation and systems should be removed from preferences.xml into the *-set.xml files. Consider the cub for example when it gets it's own instrumentation and systems configuration files, most likely the adf, dme, gps, dg, vsi, vacuum system, and probably more would be removed. Having preferences.xml set the serviceable property would then lead to cluttering of the property tree with lots of subdirs that would only contain the serviceable property. I assume that such cluttering is undesirable, or else my argument would fall apart ;-) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
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] CVS and branch development
How does one create a branch? I know how to tag changed files locally: cvs tag -b JSB_New_XML FGAircraft.cpp FGAircraft.h Is that what you mean? This is for creating a branch. Then you have to tell that you are working on it by doing : cvs update -r JSB_New_XML FGAircraft.cpp FGAircraft.h check with : cvs status FGAircraft.cpp FGAircraft.h you should see JSB_New_XML as a sticky tag. -Fred I did that, and saw the sticky tag. I believe JSBSim CVS is now in a good state. I tagged my local copy of all the good files with PRIOR_TO_NEW_XML_FORMAT. Then, I copied into my local directories the new files that are being modified for the new XML capability, and tagged then with a branch tag (-b option) JSB_New_XML. Then, I did the cvs update as you specified. Now the question I have is how do I commit my local work so that it is on a branch in the CVS repository? If I simply do a cvs commit does that commit my local changed files (that have been tagged with a branch tag) into CVS on a branch - not on HEAD? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS and branch development
Jon Berndt wrote : How does one create a branch? I know how to tag changed files locally: cvs tag -b JSB_New_XML FGAircraft.cpp FGAircraft.h Is that what you mean? This is for creating a branch. Then you have to tell that you are working on it by doing : cvs update -r JSB_New_XML FGAircraft.cpp FGAircraft.h check with : cvs status FGAircraft.cpp FGAircraft.h you should see JSB_New_XML as a sticky tag. -Fred I did that, and saw the sticky tag. I believe JSBSim CVS is now in a good state. I tagged my local copy of all the good files with PRIOR_TO_NEW_XML_FORMAT. Then, I copied into my local directories the new files that are being modified for the new XML capability, and tagged then with a branch tag (-b option) JSB_New_XML. Then, I did the cvs update as you specified. Now the question I have is how do I commit my local work so that it is on a branch in the CVS repository? If I simply do a cvs commit does that commit my local changed files (that have been tagged with a branch tag) into CVS on a branch - not on HEAD? The commit will happened in the branch specified by the sticky tag you are seeing by doing cvs status. If you did cvs add in a directory, the file will get the last tag used to update or check out the directory. You are working on Windows, right ? So I advise you to use WinCVS instead of the bare command line tools. This way you'll see instantaneously what are the current sticky tags ( or date if you used the -D option ). You can download it at http://www.wincvs.org/ . It has dialog for all available option and is very easy to use, and doesn't prevent you to use the command line whenever you want. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS and branch development
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. 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. 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. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS and branch development
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. use the -f option for cvs update to get the head if the tag is not present. 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 developer account ( :ext2:... ) instead of the anonymous one ( :pserver: ) 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. Branches are tought so I preferably assign them to directory instead of simple files. Unfortunately, jsbsim files are located in the cvs root folder, not in an src folder. It is easy to create a mess when managing simple files, and this is why I recommend using a visual tool such as WinCVS or its counterpart on Linux or anything else. If I where you, I would tag the whole tree so that I wouldn't have to remember what are files that need to be in the branch and those that are not. cvs do a good job when adding or removing solely in the branch. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS and branch development
I incorrectly wrote: If I where you, ... Oops, bad english: I meant 'If I was you, ...' -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS and branch development
If I where you, I would tag the whole tree so that I wouldn't have to remember what are files that need to be in the branch and those that are not. cvs do a good job when adding or removing solely in the branch. Sounds like a good idea. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS and branch development
Just for the record: - Creating that new branch. How does one create a branch? I know how to tag changed files locally: cvs tag -b JSB_New_XML FGAircraft.cpp FGAircraft.h Is that what you mean? jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS and branch development
Hi Jon, On Sonntag 03 Oktober 2004 16:06, Jon Berndt wrote: I am trying to save to JSBSim CVS some files I have modified for reading the new JSBSim XML format. These files should not be part of the main (HEAD) branch at the moment. I'm not sure I have done this correctly. Can a CVS expert inform me what the correct procedure is to tag a subset of files with a branch tag, store them in CVS, and then commit changes as they are made? Also, I would need to know how to merge or commit changes from the branch to the main HEAD line upon completion of development. If I look at your last checkin, you already did that right. Something did not work correctly. All my commits went to the HEAD branch. Crap! I've got some stuff to undo, now. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS and branch development
Jon Berndt wrote: Just for the record: - Creating that new branch. How does one create a branch? I know how to tag changed files locally: cvs tag -b JSB_New_XML FGAircraft.cpp FGAircraft.h Is that what you mean? This is for creating a branch. Then you have to tell that you are working on it by doing : cvs update -r JSB_New_XML FGAircraft.cpp FGAircraft.h check with : cvs status FGAircraft.cpp FGAircraft.h you should see JSB_New_XML as a sticky tag. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS and branch development
Just for the record: - Creating that new branch. How does one create a branch? I know how to tag changed files locally: cvs tag -b JSB_New_XML FGAircraft.cpp FGAircraft.h Is that what you mean? This is for creating a branch. Then you have to tell that you are working on it by doing : cvs update -r JSB_New_XML FGAircraft.cpp FGAircraft.h check with : cvs status FGAircraft.cpp FGAircraft.h you should see JSB_New_XML as a sticky tag. -Fred Is there a good way to revert the HEAD branch of CVS to yesterday morning's set of files? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS and branch development
Jon Berndt wrote: Just for the record: - Creating that new branch. How does one create a branch? I know how to tag changed files locally: cvs tag -b JSB_New_XML FGAircraft.cpp FGAircraft.h Is that what you mean? This is for creating a branch. Then you have to tell that you are working on it by doing : cvs update -r JSB_New_XML FGAircraft.cpp FGAircraft.h check with : cvs status FGAircraft.cpp FGAircraft.h you should see JSB_New_XML as a sticky tag. -Fred Is there a good way to revert the HEAD branch of CVS to yesterday morning's set of files? If I recall correctly, cvs admin -orev filename will kill the so called rev revision. For example, cvs admin -o1.42 foo.cxx remove revision 1.42 of foo.cxx. But look at the cvs manual before proceeding -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS and branch development
On Mon, 4 Oct 2004 16:47:12 +0200, Frederic wrote in message [EMAIL PROTECTED]: Jon Berndt wrote: Just for the record: - Creating that new branch. How does one create a branch? I know how to tag changed files locally: cvs tag -b JSB_New_XML FGAircraft.cpp FGAircraft.h Is that what you mean? This is for creating a branch. Then you have to tell that you are working on it by doing : cvs update -r JSB_New_XML FGAircraft.cpp FGAircraft.h check with : cvs status FGAircraft.cpp FGAircraft.h you should see JSB_New_XML as a sticky tag. -Fred Is there a good way to revert the HEAD branch of CVS to yesterday morning's set of files? If I recall correctly, cvs admin -orev filename will kill the so calledrev revision. For example, cvs admin -o1.42 foo.cxx remove revision 1.42 of foo.cxx. But look at the cvs manual before proceeding ..meanwhile, is there a go-away flag that can be set to prevent us mortals and not from cvs co'ing known bad code trees? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS and branch development
Arnt Karlsen wrote: On Mon, 4 Oct 2004 16:47:12 +0200, Frederic wrote in message [EMAIL PROTECTED]: Jon Berndt wrote: Just for the record: - Creating that new branch. How does one create a branch? I know how to tag changed files locally: cvs tag -b JSB_New_XML FGAircraft.cpp FGAircraft.h Is that what you mean? This is for creating a branch. Then you have to tell that you are working on it by doing : cvs update -r JSB_New_XML FGAircraft.cpp FGAircraft.h check with : cvs status FGAircraft.cpp FGAircraft.h you should see JSB_New_XML as a sticky tag. -Fred Is there a good way to revert the HEAD branch of CVS to yesterday morning's set of files? If I recall correctly, cvs admin -orev filename will kill the so calledrev revision. For example, cvs admin -o1.42 foo.cxx remove revision 1.42 of foo.cxx. But look at the cvs manual before proceeding ..meanwhile, is there a go-away flag that can be set to prevent us mortals and not from cvs co'ing known bad code trees? No because this repository is located at Sourceforge and there is no way to shutdown the repository during this maintenance operation. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS and branch development
..meanwhile, is there a go-away flag that can be set to prevent us mortals and not from cvs co'ing known bad code trees? No because this repository is located at Sourceforge and there is no way to shutdown the repository during this maintenance operation. -Fred I'll try and get this fixed today. In teh meantime, checkout JSBSim CVS only based on data, from say, last Saturday night. That should be fine. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS and branch development
On Mon, 4 Oct 2004 11:16:28 -0500, Jon wrote in message [EMAIL PROTECTED]: ..meanwhile, is there a go-away flag that can be set to prevent us mortals and not from cvs co'ing known bad code trees? No because this repository is located at Sourceforge and there is no way to shutdown the repository during this maintenance operation. -Fred I'll try and get this fixed today. In teh meantime, checkout JSBSim CVS only based on data, from say, last Saturday night. That should be fine. ..ok. I'm asking because I'm pondering an automatic build script that I'd like to abort in situations like this, when cvs co, building etc is pointless. ..but the idea can be inverted: Maybe a cvs signature file to flag off stuff you're happy with? So I just set my script to check for that new flag file, and on its absense, just do cvs co to last Saturday night? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS and branch development
Arnt Karlsen wrote: ..but the idea can be inverted: Maybe a cvs signature file to flag off stuff you're happy with? So I just set my script to check for that new flag file, and on its absense, just do cvs co to last Saturday night? In situations like that one is way too busy fixing stuff to bother about others. Sorry about that. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS and branch development
On Mon, 04 Oct 2004 21:24:33 +0200, Erik wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: ..but the idea can be inverted: Maybe a cvs signature file to flag off stuff you're happy with? So I just set my script to check for that new flag file, and on its absense, just do cvs co to last Saturday night? In situations like that one is way too busy fixing stuff to bother about others. Sorry about that. ..I said on its absense, the idea is you fix stuff first, then set the new Ok, I'm happy flag. ..but true, another way could be chk whether or not any of you guys are working on the cvs server to fix stuff like this. ..it has to be automated anyway. Checking the history section in the manual. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS and branch development
Hi Jon, On Sonntag 03 Oktober 2004 16:06, Jon Berndt wrote: I am trying to save to JSBSim CVS some files I have modified for reading the new JSBSim XML format. These files should not be part of the main (HEAD) branch at the moment. I'm not sure I have done this correctly. Can a CVS expert inform me what the correct procedure is to tag a subset of files with a branch tag, store them in CVS, and then commit changes as they are made? Also, I would need to know how to merge or commit changes from the branch to the main HEAD line upon completion of development. If I look at your last checkin, you already did that right. Just for the record: - Creating that new branch. - Checking out the new branch with cvs co -r BRANCHNAME - Work as usual within that newly checked out directory. Everything you do in that directory is done on that branch (branch tags are sticky). For merging changes from HEAD I use the following procedure: First I create a tag in the HEAD branch when I did the past changes. You can do that in a directory with the checked out HEAD with: cvs tag LAST-MERGE-TO-XML This is an initial procedure which should be done with the HEAD revision used to create the new branch. When I merge, I create a temporary tag on HEAD with cvs tag LAST-MERGE-TO-XML-TMP In your development directory for the XML branch you can then leave most work to cvs. It will incorporate the changes between the tags LAST-MERGE-TO-XML and LAST-MERGE-TO-XML-TMP by cvs up -jLAST-MERGE-TO-XML -jLAST-MERGE-TO-XML-TMP cvs even cares for cvs add's of new files ... Check for conflicts, resolve them and check that in. Then I move the LAST-MERGE-TO-XML tag to the LAST-MERGE-TO-XML-TMP to get that right for the next time I will merge changes. Again in the directory with the HEAD branch checked out: cvs tag -d LAST-MERGE-TO-XML # remove old tag. cvs tag -r LAST-MERGE-TO-XML-TMP LAST-MERGE-TO-XML # tag where tmp tag is cvs tag -d LAST-MERGE-TO-XML-TMP # remove tmp tag Thats it. If you want to merge changes from the branch to HEAD. You can do the same with changed roles of the branches. 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] CVS and branch development
Hi Jon, If I look at your last checkin, you already did that right. Just for the record: - Creating that new branch. - Checking out the new branch with cvs co -r BRANCHNAME - Work as usual within that newly checked out directory. Everything you do in that directory is done on that branch (branch tags are sticky). For merging changes from HEAD I use the following procedure: First I create a tag in the HEAD branch when I did the past changes. You can do that in a directory with the checked out HEAD with: cvs tag LAST-MERGE-TO-XML Thanks. I will refer to this as time goes on. Now here's another question: If a person wants to check on the HEAD version, but wants the changed versions now also in the branch JSB_New_XML? I guess one would check out the HEAD version, then update from the JSB_New_XML branch? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS - Problems
Vivian Meazza wrote: On compiling the CVS download under Cygwin this morning I get the following error: tilemgr.cxx: In member function `void FGTileMgr::update_queues()': tilemgr.cxx:288: error: `size' undeclared (first use this function) tilemgr.cxx:288: error: (Each undeclared identifier is reported only once for each function it appears in.) make[2]: *** [tilemgr.o] Error 1 make[2]: Leaving directory `/flightgear-cvs/source/src/Scenery' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/flightgear-cvs/source/src' make: *** [install-recursive] Error 1 You will have to update SimGear also ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS - problem
Chris Metzler wrote
Sent: 31 July 2004 23:14
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] CVS - problem
On Sat, 31 Jul 2004 16:11:29 +0100
Vivian Meazza [EMAIL PROTECTED] wrote:
I downloaded FGFS cvs this morning. There appears to be an error in
gui.nas:
166 if(cap 1) { continue; }
I assume this to be a typo or corruption. I guess that it should be
166 if(cap = 0.1) { continue; }
ISR this having been mentioned at some time. Even if this line is
corrected, it doesn't seem to work with JBS models. Has an
old version
crept back in? Let's hope it's not in release 0.9.5,
although it's not
critical.
I have:
}# Hack, to ignore the ghost tanks created by the C++ code.
}if(cap 1) { continue; }
}
}title = tcell(fuelTable, text, i+1, 0);
that is, 1 rather than = 0.1.
Is that from a recent download? I updated again this morning, and still get
166 if(cap 1) { continue; }
1 still doesn't seem to work with JBS models.
Regards,
Vivian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS - problem
Vivian Meazza wrote:
Is that from a recent download? I updated again this morning, and still
get
166 if(cap 1) { continue; }
1 still doesn't seem to work with JBS models.
I also have 1. Are you dowloading with the cvs client or with
the flightgear.org viewcvs application. In the latter case, beware
that your browser might eator similar html reserved
character when exporting to text.
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS - problem
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Frederic Bouvier
Sent: 01 August 2004 09:24
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] CVS - problem
Vivian Meazza wrote:
Is that from a recent download? I updated again this morning, and
still
get
166 if(cap 1) { continue; }
1 still doesn't seem to work with JBS models.
I also have 1. Are you dowloading with the cvs client or
with the flightgear.org viewcvs application. In the latter
case, beware that your browser might eator similar
html reserved character when exporting to text.
-Fred
Cygwin cvs client. There are no other errors, and it was OK up to my update
yesterday. It's not a problem if only I am seeing it, beacause I can correct
it. I'd like to know why though.
I had to re-download from scratch to get -pre3 to run, so it looks as I'm
getting an earlier version, while you are keeping a later one. Not sur how
to run that one down though.
Regards,
Vivian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS - problem
Vivian Meazza writes:
Frederic Bouvier writes:
Is that from a recent download? I updated again this morning, and
still get
166 if(cap 1) { continue; }
1 still doesn't seem to work with JBS models.
I also have 1. Are you dowloading with the cvs client or
with the flightgear.org viewcvs application. In the latter
case, beware that your browser might eator similar
html reserved character when exporting to text.
Cygwin cvs client. There are no other errors, and it was OK up to my update
yesterday. It's not a problem if only I am seeing it, beacause I can correct
it. I'd like to know why though.
note the CVS history of any file can be inspected thru viewCVS
for example
http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/Nasal/gui.nas?cvsroot=FlightGear-0.9
indicates that line 166 last changed when it was introduced into gui.nas
version 1.3 , 2004/05/15 21:50:51
164 andy 1.3
165 # Hack, to ignore the ghost tanks created by the C++ code.
166 if(cap 1) { continue; }
which can be inspected here
http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/Nasal/gui.nas.diff?r1=1.2r2=1.3cvsroot=FlightGear-0.9
also note simce my 'data / nasal / gui.nas' code is the same as
what is in CVS and I also use Cygwin CVS to maintain my files
this 'sounds' as if somehow, this was a locally introduced problem
in general you might fine it helpful to check for local differences
from the CVS when you experience problems with your local files
with a command like
cvs -z3 diff -c 21 | tee local_diffs
note this can be issued from any level in your local tree
and can be limited to only compare specific files i.e.
cd data/Nasal
cvs -z3 diff gui.nas 21 | tee gui_nas.diff
which will both list local diffs to the console and create a 'local_diffs' file
HTH
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS - problem
166 if(cap 1) { continue; }
1 still doesn't seem to work with JBS models.
What? I could not figure out from the posts what wasn't working with the JSBSim models
(is
that what you meant by JBS Models?)
Jon
I also have 1. Are you dowloading with the cvs client or with
the flightgear.org viewcvs application. In the latter case, beware
that your browser might eator similar html reserved
character when exporting to text.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
