[Flightgear-devel] SimGear and TerraGear CVS Browsing Links Broken [2]
Hi Curt, When doing some email cleaning, found, from my email of 4 Mar, that these are still broken... The TerraGear page - http://www.terragear.org/cvs.html shows a link for 'Interactive CVS log browsing' as - http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/?root=TerraGear-0.0 But this is broken! Through guess work I think it should now be :- http://cvs.terragear.org/viewvc/?root=TerraGear Likewise the SimGear page - http://www.simgear.org/cvs.html shows - http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/?root=SimGear-0.3 But guess it should be - http://cvs.simgear.org/viewvc/?root=SimGear Or maybe the flightgear cgi-bin/viewvc/viewvc.cgi could be corrected to go to the correct URL... But if my guess is correct, then attached are patches for the respective 'www' CVS sources files... Hope this helps. Regards, Geoff. attached: tgwww-01.patch and sgwww-01.patch Index: cvs.html === RCS file: /var/cvs/TerraGear-0.0/www/cvs.html,v retrieving revision 1.3 diff -u -r1.3 cvs.html --- cvs.html 25 Feb 2003 20:02:03 - 1.3 +++ cvs.html 8 Jul 2009 15:46:45 - @@ -35,7 +35,7 @@ H3View the CVS logs and differences online/H3 UL - LI A HREF=http://cvs.terragear.org/cgi-bin/viewcvs/viewcvs.cgi/?cvsroot=TerraGear-0.0; + LI A HREF=http://cvs.terragear.org/viewvc/?root=TerraGear; Interactive CVS log browser./A LI A HREF=http://cvs.terragear.org/cgi-bin/viewcvs/queryform.cgi?repository=/var/cvs/TerraGear-0.0; CVS query engine./A Index: cvs.html === RCS file: /var/cvs/SimGear-0.3/www/cvs.html,v retrieving revision 1.8 diff -u -r1.8 cvs.html --- cvs.html 17 Dec 2007 16:03:12 - 1.8 +++ cvs.html 8 Jul 2009 16:02:15 - @@ -42,7 +42,7 @@ UL !-- LI A HREF=http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/?root=SimGear-0.2; Interactively peruse the CVS logs, differences, and source code (Stable branch.)/A -- - LI A HREF=http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/?root=SimGear-0.3; + LI A HREF=http://cvs.simgear.org/viewvc/?root=SimGear; Interactively peruse the CVS logs, differences, and source code (Development branch.)/A /UL -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] gui/Dialogs/clouds.xml bugs
Hi, Please remove the livetrue/live lines from all combos in gui/Dialogs/clouds.xml They make it impossible to change cloudlayers through the dialog, as they are set back to their original value every time. Regards, Gijs _ Haal meer uit je leven met Windows Live http://www.microsoft.com/netherlands/windowslive/Views/index.aspx-- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
Hi Tim, On Sunday 05 July 2009 22:51:32 Tim Moore wrote: We can now rely on std::tr1:shared_ptr and its cousins, through Boost if need be, so perhaps we could come up with some nice templates to paper over the differences between OSG pointers an our own. Vote against. You will need two allocations for a new object that is used with the the std::shared_ptr implementation - one for the object and one for the reference count. I like to use that SGReferenced stuff for many small lightweight objects that should not take to much time to create and should not take too much space. That kind of the solution is the most lightweight one I can think of. Also you can no longer work with raw pointers passed around and use the reference count included in the object since the shared_ptr implementation has a separate count object. If you do so you will end up with two reference counts for the same object. The current implementation avoids that and make raw pointer based apis if required. So alltogether we have with the SG* version something that works equally well than the shared_ptr/weak_ptr pair and provides some extra features I would like to have. The SGAtomic counter could make use of the std::atomic at some point - if we add an additional case int the current implementation selection when we have that available. This could be done without loosing any of the features we have available in our current SharedPtr/WeakPtr implementation. Greetings Mathias -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] Dynamic plug-in interface for I/Omodules
Hi, So sorry for the long delay. On Wednesday 01 July 2009 16:29:23 Petr Gotthard wrote: The basic HLA standard (both DoD and IEEE variant) provides only a C++ API compatibility at a compile-level. There is a SISO standard that should assure dynamic link compatibility (DLC). However, some RTI libraries may not be compliant to the SISO standard. Ok. Regarding the different foms: I have seen your implementation and what I believe we can do more generic. Sure there is a part of your implementation that hard codes some attribute names of the foms into the binary. But this could be done in a more generic way, so that you can configure the attributes meanings at runtime instead. With this model, your two hardcoded implementaiton stubs for the those two fom's will be just a special configuration using the same c++ implementation. I've been thinking about this a lot. There is no simple mapping between FlightGear and FOM parameters. Sometimes it's necessary to translate units, geodetic/geocentric frames or perform other calculations. The generic mapping engine would have to be a very powerful scripting language like Nasal or Python. I've decided to start with a simple hardcoded interface and investigate all FOM attributes and interactions that may be supported by FlightGear/HLA. After we understand all possible features of the FlightGear/HLA interface, we will reconsider implementing the generic interface. Of course, unless somebody volunteers to implement it right now. ;-) Well, I have code here that would at least cover those cases that you have already hard coded in your two fom implementation backends. As soon as I have something ready to try I will send that to you. I am sure that such a thing is much more convenient to use with different foms than something you need to recompile. Regarding the different binaries, you will just need to have so much versions of flightgear compiled from the same source and with different rti's available than you have RTI's. And since changes in the handling of FOM's would not need a recompile at all, I can think of this being also more convenient for your use case. I for myself would like to have such a flexible implementation at hands. So all together I would prefer to include a more generic HLA/RTI implementaiton in flightgear than introduce a plugin mechanism. Yes, it would be nice to have a generic HLA/RTI implementation. From the cost-benefit ratio perspective, a plug-in mechanism will significantly simplify the use of the hardcoded interface, so the need for the generic implementation is not so urgent. And it's much easier to implement a plug-in mechanism, than the HLA/RTI interface. Not sure about that. I expect to have something in the not so far future. Greetings Mathias -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
