Re: [Flightgear-devel] FlightGear Manager...
Hi Gene, On Wednesday, June 15, 2011 21:43:36 Gene Buckle wrote: In thinking about it a bit and being reminded of the existing HLA interface that FlightGear has, I'm leaning toward proposing something built with Python and the PyQT4 GUI library. Both components are cross-platform and there is a Python binding for the CERTI HLA library (PyHLA). Well you can use PyHLA - That should just work with any RTI-1.3 library. But, did you try OpenRTI? There is a python binding included for the newer rti1516 standard. And in fact I have some python glue code that makes it easy to do python clients with that binding. We have run all this at LinuxTag. Including a small python script that prvides an ogle doing cirgles around a fixed point just as a demo how this could be achieved. Also a very simple radar application using pyside (qt binding) was running there. I have not published yet, this stuff since I do not think that the interfaces to the glue are already settled and because I wanted to avoid that backwardcompatibility problems at this time. I can provide this to you if you want. The idea here is to create a stand-alone application that replaces all the built-in GUI functionality and communicates with FlightGear via the HLA interface. When the manager application meets that goal, the existing GUI can be either removed completely or simply unbound at compile time so it's not available. Yes, in the long term this could be kind of a plan. I can see several components in this area: The viewer. That was the original reason I started fgviewer. I want to have a pure viewer application that does not do any simulation. The simulated aircraft. This includes *all* subsystems that belong to this particular aircraft. This must be done in a way that you can run several of these in a single federation. The weather module. That needs to provide wind and atmosphereic parameters for all simulation entities. The AI module. Provides all the AI traffic that is around. A manager. Probably without any gui. Is responsible to give unique startup positions and such. Using the unique object names that are owned by exactly one federate this will be easy to do. A multiplayer gateway. Currently I am talking about a local federation that should help runnning in a paralell environment and for things like the LinuxTag booth. Components might need to be coupled with a hard time syncronization. At least carefully selected components. Since this would just hang the whole federation if one of the federates hangs, this is impossible to do for the multiplayer part over the wide internet. Therefore the multiplayer server needs to be coupled loosely into the local federation. That is what this is for in the longer term. And many more that make sense to move into its own component. The above additional AI ogle with a nice, easy to adapt may be python scripted logic Here we need to start thinking carefully. And this is the reason I ask for OpenRTI. I have started this project, because I found that setup of the usual rti libraries is way to complex. So OpenRTI provides one mode where you can just access a process local federation from multiple threads. There is no network configuration needed and you do not setup any server in this operation mode (sure it also provides the usual networking mode). So the plan is to use this mode as an aid to parallellize flightgear on a local machine. The basic advantage is that each federate is strictly programmed single threadad. All the thread syncronization is handled by the rti library and hidden in that thing. The trick is that each of these threads must be done in a way that you can just compile that alternatively in a single standalone binary and run the same component in a networked rti - the LinuxTag booth for example. Now I start returning to your initial question. From my point of view, such a gui manager application must be included somehow in the basic set of functionality that is still running in the threaded mode. You would just control your simulation with that component. May be restart with a different aircraft by just shutting down the running federate and start up a new one with a different fdm. And as such, doing this core component in python is something I am not sure about. So, python in the area of *optional* rti components, is a great tool. If I remember well, you do have some bigger install at home that might benefit from such components very much! And in fact this is one reasons I am pushing this direction. Python also has one major problem with threads. There is the big interpreter lock in python which makes python essentially single threaded. While this is not a problem when such a component runs in its own process, python in core components that need to run in threaded mode is essentially a no go. OTOH, I am very curious what creative people will do with that easy python stuff once we can easily integrate that
Re: [Flightgear-devel] Heads up: scenery download /built-interrasync
On 25.06.2011 01:31, Vivian Meazza wrote: But isn't this a function of libsvn and we are talking about external svn and libsvn not present? I'm currently testing another fix without libsvn functions. Thanks, Torsten - well done. This is true. But using Fred's MSVC9 solution files as provided it is not possible to switch off the libsvn stuff AFAIKS. That's not good, of course. libsvn should be optional, but no idea how we do such options for MSVC9. But it's certainly optional for any other build system - and it's good that it is. As I said way back - we seem to have at least 3 overlapping scenery download methods. I'm not entirely clear on the relative merits of the internal and external svn options. D'oh. I'm giving up... Tired of repeating. I think we also need svn_path_uri_encode() in the internal path to allow download directories paths to have spaces. Usually, white-spaces are a particular issue when calling external command-lines utilities. The entire command-line is constructed as single string - and then needs to be parsed by the command-line processor into separate parmeters. That's where things go wrong with white-spaces in paths - since such paths get split into several parameters (rather than one parameter with a white-space). No one has reported any issues with white-spaces with libsvn. I remember reports that white-spaces were even working with internal SVN on Windows (it certainly does for the other OS). cheers, Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download /built-interrasync
- ThorstenB a écrit : This is true. But using Fred's MSVC9 solution files as provided it is not possible to switch off the libsvn stuff AFAIKS. That's not good, of course. libsvn should be optional, but no idea how we do such options for MSVC9. But it's certainly optional for any other build system - and it's good that it is. Simple, build your win32 binaries yourself. This is the only thing possible as long as it is a build option Regards, -Fred -- Frédéric Bouvier http://www.youtube.com/user/fgfred64 Videos -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Manager...
On Sat, 25 Jun 2011, Mathias Fröhlich wrote: Hi Gene, On Wednesday, June 15, 2011 21:43:36 Gene Buckle wrote: In thinking about it a bit and being reminded of the existing HLA interface that FlightGear has, I'm leaning toward proposing something built with Python and the PyQT4 GUI library. Both components are cross-platform and there is a Python binding for the CERTI HLA library (PyHLA). Well you can use PyHLA - That should just work with any RTI-1.3 library. But, did you try OpenRTI? I haven't tried anything yet. I'm still tossing the idea around in my head and trying to decide if I want to learn yet _another_ toolkit (PyQT4, PyGUI or whatever else). My main issue is that I'm primarily a Windows developer and I don't have much interest in cross-platform anything. :) There is a python binding included for the newer rti1516 standard. And in fact I have some python glue code that makes it easy to do python clients with that binding. We have run all this at LinuxTag. Including a small python script that prvides an ogle doing cirgles around a fixed point just as a demo how this What's an ogle? The idea here is to create a stand-alone application that replaces all the built-in GUI functionality and communicates with FlightGear via the HLA interface. When the manager application meets that goal, the existing GUI can be either removed completely or simply unbound at compile time so it's not available. Yes, in the long term this could be kind of a plan. I can see several components in this area: The viewer. That was the original reason I started fgviewer. I want to have a pure viewer application that does not do any simulation. I've never used fgviewer so I'm not sure what it does. The simulated aircraft. This includes *all* subsystems that belong to this particular aircraft. This must be done in a way that you can run several of these in a single federation. The management application wouldn't be running any of the sub-systems, just observing them. One of the issues that caught me up short was the requirement to sift through the chosen aircrafts configuration and Nasal files in order to take into account all the little custom menu items and controls that would have to be replicated on the manager interface. That was pretty discouraging all by itself. I think the scope of what you've got in mind and what I've got in mind are widely seperated. :) My initial concept would essentially perform the same functions as the instructor console in a commercial FFS. You could tweak any parameter of the simulator from that point, including aircraft selection, position, configuration, etc. This app wouldn't be running on the same machine as the simulator scene generator itself. (What would be neat is a three machine setup - one for the scene generator, one for the flight/systems model and one for the instructor/manager console.) I think I need to sit down and do a proper outline of what I see going into this and where it could go. I'd rather not create something like this organically. It could get ugly quick that way. Thanks for the detailed info Mathias! g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end.-- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download /built-interrasync
Torsten Am 24.06.11 23:59, schrieb Torsten Dreyer: Is this built-in function: svn_path_uri_encode() any help? Yup, does the trick - no need for fancy formatting. I'll see if I can do a damned merge request this side of Monday. Vivian But isn't this a function of libsvn and we are talking about external svn and libsvn not present? I'm currently testing another fix without libsvn functions. Torsten Here you go: simgear commit d36170879c9394064b37fc9acb3d12d451f2be82 makes whitespaces in the command _and_ the target directory work for me. Tested on Linux, MacOS and WinXP/VS2008. Please pull simgear and rebuild simgear+flightgear and test if it works for you. All options work exactly as they should: Internal and External, with / or \ and with or without white spaces. I would never have guessed that double double quotes would do the trick, but they clearly do. svn_path_uri_encode() also does the trick, but this is a more robust solution. Thanks for all your effort in clearing this bug. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Shaders and ATI Radeon HD 4670
Hi all, I cannot use material shaders on my iMac (late 2009 model) equipped with an ATI graphics card (ATI Radeon HD 4670 256 MB VRAM). I only get a few fps standing on ground at an isolated airfield. There is almost no objects. Every 10 times I get 60 fps in cockpit view with no changes except restarting flightgear. Toggling through different view gives different frame rates where the tower views always gives around 60 fps and the others give 2-5 fps (except the occasional 60 fps I get in the cockpit view). In cases when I get 60 fps in cockpit view my computer maintains 60 fps with 3D clouds and skydome scattering turned on. The frame rate is stable even flying through the magnificently rendered clouds. If I turn of material shaders I always get 60 fps in all different views. (Is 60 fps a maximum reading, I never seem to get higher readings?) On my Macbook Pro (early 2008) model, I always get 60 fps staying away from the 3D clouds but the frame rate drops to 20 fps when I fly through clouds. The MBP has a GeForce 8600M GT 256 MB VRAM. The test on my iMac was done on yesterdays source from the various repositories and everything is compiled with -g -O3 (-O2 gives the same numbers). I have also tested a couple of Tat's git snapshots from the macflightgear site and they give similar negative shader effect. I read through many posts on flightgear and shaders on the web but nothing has resolved my issue. Is the above a flightgear issues or is it my hardware? I haven't noticed anything strange with my iMac and Apples extended hardware test does not report anything. Cheers, Jari -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and ATI Radeon HD 4670
Jari I cannot use material shaders on my iMac (late 2009 model) equipped with an ATI graphics card (ATI Radeon HD 4670 256 MB VRAM). I only get a few fps standing on ground at an isolated airfield. There is almost no objects. Every 10 times I get 60 fps in cockpit view with no changes except restarting flightgear. Toggling through different view gives different frame rates where the tower views always gives around 60 fps and the others give 2-5 fps (except the occasional 60 fps I get in the cockpit view). In cases when I get 60 fps in cockpit view my computer maintains 60 fps with 3D clouds and skydome scattering turned on. The frame rate is stable even flying through the magnificently rendered clouds. If I turn of material shaders I always get 60 fps in all different views. (Is 60 fps a maximum reading, I never seem to get higher readings?) On my Macbook Pro (early 2008) model, I always get 60 fps staying away from the 3D clouds but the frame rate drops to 20 fps when I fly through clouds. The MBP has a GeForce 8600M GT 256 MB VRAM. The test on my iMac was done on yesterdays source from the various repositories and everything is compiled with -g -O3 (-O2 gives the same numbers). I have also tested a couple of Tat's git snapshots from the macflightgear site and they give similar negative shader effect. I read through many posts on flightgear and shaders on the web but nothing has resolved my issue. Is the above a flightgear issues or is it my hardware? I haven't noticed anything strange with my iMac and Apples extended hardware test does not report anything. The most _likely_ cause is the ATI Radeon HD 4670/256 MB VRAM. The GeForce 8600M GT is known to be better at handling shaders. 256 Mb VRAM is in both cases a bit small for FG nowadays. There are other possible contributors to a low framerate - AI traffic is one. 60 fps could be a maximum if you are using this option - --prop:/sim/frame-rate-throttle-hz=60 It might well be on by default. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and ATI Radeon HD 4670
On Sat, 25 Jun 2011, Vivian Meazza wrote: The most _likely_ cause is the ATI Radeon HD 4670/256 MB VRAM. The GeForce 8600M GT is known to be better at handling shaders. 256 Mb VRAM is in both cases a bit small for FG nowadays. There are other possible contributors to a low framerate - AI traffic is one. Wow. That's an incredibly small amount of video RAM for a video card that new. Can you upgrade it to something with more RAM? g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and ATI Radeon HD 4670
On 2011-06-25 17.34, Gene Buckle wrote: On Sat, 25 Jun 2011, Vivian Meazza wrote: The most _likely_ cause is the ATI Radeon HD 4670/256 MB VRAM. The GeForce 8600M GT is known to be better at handling shaders. 256 Mb VRAM is in both cases a bit small for FG nowadays. There are other possible contributors to a low framerate - AI traffic is one. Wow. That's an incredibly small amount of video RAM for a video card that new. Can you upgrade it to something with more RAM? Otherworldcomputing.com has two options; ATI Radeon HD 5670/512MB (USD180) and ATI Radeon HD 5750/1GB (USD400). 400 is a lot, will the cheaper 512MB card make a noticeable difference? And, opening an iMac isn't for the faint-hearted. Jari -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and ATI Radeon HD 4670
On 2011-06-25 16.06, Vivian Meazza wrote: The most _likely_ cause is the ATI Radeon HD 4670/256 MB VRAM. The GeForce 8600M GT is known to be better at handling shaders. 256 Mb VRAM is in both cases a bit small for FG nowadays. There are other possible contributors to a low framerate - AI traffic is one. 60 fps could be a maximum if you are using this option - --prop:/sim/frame-rate-throttle-hz=60 It might well be on by default. I am not using the frame-rate-throttle option but I tried it with a lower limit. This will naturally decrease the frame rate so it seems like 60 is a limiting number. I have to decide if the 3D clouds are worth a graphics card upgrade. Thanks for the response. Jari -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and ATI Radeon HD 4670
Am 25.06.11 17:59, schrieb Jari Häkkinen: Otherworldcomputing.com has two options; ATI Radeon HD 5670/512MB (USD180) and ATI Radeon HD 5750/1GB (USD400). 400 is a lot, will the cheaper 512MB card make a noticeable difference? And, opening an iMac isn't for the faint-hearted. Jari Hi Jari I have a ATI Radeon 5750 with 1 GB and the only difference is that (still remaining) shader issues on OSX with ATI are rendered faster. Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Manager...
On Sat, 2011-06-25 at 05:48 -0700, Gene Buckle wrote: On Sat, 25 Jun 2011, Mathias Fröhlich wrote: Hi Gene, On Wednesday, June 15, 2011 21:43:36 Gene Buckle wrote: In thinking about it a bit and being reminded of the existing HLA interface that FlightGear has, I'm leaning toward proposing something built with Python and the PyQT4 GUI library. Both components are cross-platform and there is a Python binding for the CERTI HLA library (PyHLA). Well you can use PyHLA - That should just work with any RTI-1.3 library. But, did you try OpenRTI? I haven't tried anything yet. I'm still tossing the idea around in my head and trying to decide if I want to learn yet _another_ toolkit (PyQT4, PyGUI or whatever else). My main issue is that I'm primarily a Windows developer and I don't have much interest in cross-platform anything. :) There is a python binding included for the newer rti1516 standard. And in fact I have some python glue code that makes it easy to do python clients with that binding. We have run all this at LinuxTag. Including a small python script that prvides an ogle doing cirgles around a fixed point just as a demo how this What's an ogle? An ogle is very similar in many respects to the aircraft of which you are the proud owner. Major difference is that it is assembled out of platic bricks made by a famous Danish manufacturer (hint: anagram ogle) Try fgfs --aircraft=ogle. :) Regards, Alasdair -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and ATI Radeon HD 4670
On Saturday, June 25, 2011 09:04:30 AM Jari Häkkinen wrote: On 2011-06-25 16.06, Vivian Meazza wrote: The most _likely_ cause is the ATI Radeon HD 4670/256 MB VRAM. The GeForce 8600M GT is known to be better at handling shaders. 256 Mb VRAM is in both cases a bit small for FG nowadays. There are other possible contributors to a low framerate - AI traffic is one. 60 fps could be a maximum if you are using this option - --prop:/sim/frame-rate-throttle-hz=60 It might well be on by default. I am not using the frame-rate-throttle option but I tried it with a lower limit. This will naturally decrease the frame rate so it seems like 60 is a limiting number. I have to decide if the 3D clouds are worth a graphics card upgrade. Thanks for the response. Jari The 60 FPM limit is probably because the diver is syncing to the vblank signal from the monitor. For most LCD type monitors with will either be 60Hz or 120Hz. For the nvidia X11 drivers you can turn sync to vblank on and off. I generally have mine on since there is no reason to have the video card produce a frame rate higher than the monitor refresh rate. I don't know if this is configurable in the OS/X video drivers. Hal --- --- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Manager...
On Sat, 2011-06-25 at 17:25 +0100, Alasdair Campbell wrote: On Sat, 2011-06-25 at 05:48 -0700, Gene Buckle wrote: On Sat, 25 Jun 2011, Mathias Fröhlich wrote: Hi Gene, On Wednesday, June 15, 2011 21:43:36 Gene Buckle wrote: In thinking about it a bit and being reminded of the existing HLA interface that FlightGear has, I'm leaning toward proposing something built with Python and the PyQT4 GUI library. Both components are cross-platform and there is a Python binding for the CERTI HLA library (PyHLA). Well you can use PyHLA - That should just work with any RTI-1.3 library. But, did you try OpenRTI? I haven't tried anything yet. I'm still tossing the idea around in my head and trying to decide if I want to learn yet _another_ toolkit (PyQT4, PyGUI or whatever else). My main issue is that I'm primarily a Windows developer and I don't have much interest in cross-platform anything. :) There is a python binding included for the newer rti1516 standard. And in fact I have some python glue code that makes it easy to do python clients with that binding. We have run all this at LinuxTag. Including a small python script that prvides an ogle doing cirgles around a fixed point just as a demo how this What's an ogle? An ogle is very similar in many respects to the aircraft of which you are the proud owner. Major difference is that it is assembled out of platic bricks made by a famous Danish manufacturer (hint: anagram ogle) Try fgfs --aircraft=ogle. :) Regards, Alasdair Apologies, please change all my references to ogle by ogel ..AC -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Manager...
On Sat, 25 Jun 2011, Alasdair Campbell wrote: in fact I have some python glue code that makes it easy to do python clients with that binding. We have run all this at LinuxTag. Including a small python script that prvides an ogle doing cirgles around a fixed point just as a demo how this What's an ogle? An ogle is very similar in many respects to the aircraft of which you are the proud owner. Major difference is that it is assembled out of platic bricks made by a famous Danish manufacturer (hint: anagram ogle) Try fgfs --aircraft=ogle. :) Hehe. Neat. :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Hi, Currently I do not even have a working fg on my machine, but I continue to peek at the flightgear-devel list occasionally. Today I saw this discussion of moving the aircraft directories to individual SVN repos instead of git. My experience with both svn and git is both minimal and old, and I may be misinterpreting what the problem is that needs solving. However, if you're going to consider creating separate repos in SVN for each aircraft, when everything else has been converted to git now, perhaps you should consider instead using fossil, which is very git-like in some ways (clone,push,pull) but also like a traditional centralized VCS in some other ways. In particular, fossil's repository is a single, sqlite file. Although cloning is the normal method for copying it, you can copy that file just fine (as long as no one else is updating it at that instant) and it works fine. Afterwards, updating a local repo, using pull, involves an rsync-like protocol so it's fast. Fossil repositories can be converted to/from git repositories with a one-liner. (However I don't know how you would isolate, say, just the c172p directory from all the rest of the stuff in git.) If anyone thinks this might be relevant, just take a look at https://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki This is a living instance of a fossil repository, BTW: the fossil binary, statically-linked except for libz, is ~900KB. Yet it includes a simple wiki, a *very* nice issue-tracking system, and a tiny web-server(!). Normally a developer interacts with fossil from the commandline, but the built-in web-server makes *exploring* what is in the repository, as well as creating bug reports and some documentation, a joy. Just for fun, and understanding that this would have to be done properly by someone with access to the full git repo with all its history, I yum-installed FlightGear-data on my Fedora system, and then did cp -r /usr/share/FlightGear/Aircraft /tmp and created Fossil repos for each of the included directories: shrdlu tmp $ ls Aircraft 777-200 bo105 dhc2 Generic j3cub ufo A6M2 c172p Dragonfly Instruments SenecaII UIUC b1900d CitationX f-14b Instruments-3d sopwithCamel ZLT-NT shrdlu tmp $ mkdir Repos shrdlu tmp $ cd Aircraft shrdlu Aircraft $ for i in * do echo $i: fossil new ../Repos/$i.fossil cd $i fossil open ../../Repos/$i.fossil fossil add . fossil commit -m Initial checkin fossil close cd .. done #Five times it paused to ask a question like this: # ./Models/Liveries/KLM.xml contains CR/NL line endings; commit anyhow (yes/no/all)?all #Otherwise it would have taken perhaps 30 seconds for all 18 repositories, #on my 5-year-old machine. shrdlu Aircraft $ cd .. shrdlu tmp $ du -sh Aircraft 12M Aircraft/777-200 4.5MAircraft/A6M2 6.0MAircraft/b1900d 3.0MAircraft/bo105 17M Aircraft/c172p 5.8MAircraft/CitationX 5.9MAircraft/dhc2 1.6MAircraft/Dragonfly 23M Aircraft/f-14b 816KAircraft/Generic 14M Aircraft/Instruments 11M Aircraft/Instruments-3d 1.1MAircraft/j3cub 6.6MAircraft/SenecaII 22M Aircraft/sopwithCamel 216KAircraft/ufo 8.2MAircraft/UIUC 4.1MAircraft/ZLT-NT shrdlu tmp $ ls -lh Repos total 68M -rw-r--r-- 1 dns dns 7.5M Jun 25 13:43 777-200.fossil -rw-r--r-- 1 dns dns 1.6M Jun 25 13:43 A6M2.fossil -rw-r--r-- 1 dns dns 3.3M Jun 25 13:43 b1900d.fossil -rw-r--r-- 1 dns dns 1.4M Jun 25 13:43 bo105.fossil -rw-r--r-- 1 dns dns 11M Jun 25 13:43 c172p.fossil -rw-r--r-- 1 dns dns 3.4M Jun 25 13:43 CitationX.fossil -rw-r--r-- 1 dns dns 3.2M Jun 25 13:43 dhc2.fossil -rw-r--r-- 1 dns dns 836K Jun 25 13:43 Dragonfly.fossil -rw-r--r-- 1 dns dns 11M Jun 25 13:44 f-14b.fossil -rw-r--r-- 1 dns dns 464K Jun 25 13:44 Generic.fossil -rw-r--r-- 1 dns dns 3.9M Jun 25 13:44 Instruments-3d.fossil -rw-r--r-- 1 dns dns 5.4M Jun 25 13:44 Instruments.fossil -rw-r--r-- 1 dns dns 457K Jun 25 13:44 j3cub.fossil -rw-r--r-- 1 dns dns 2.4M Jun 25 13:44 SenecaII.fossil -rw-r--r-- 1 dns dns 8.7M Jun 25 13:44 sopwithCamel.fossil -rw-r--r-- 1 dns dns 96K Jun 25 13:44 ufo.fossil -rw-r--r-- 1 dns dns 2.8M Jun 25 13:44 UIUC.fossil -rw-r--r-- 1 dns dns 1.4M Jun 25 13:44 ZLT-NT.fossil shrdlu tmp $ file Repos/777-200.fossil Repos/777-200.fossil: SQLite 3.x database shrdlu tmp $ du -sh Aircraft Repos 144MAircraft 68M Repos shrdlu tmp $ Of course this is equivalent to just the tip of the git repository. Fossil uses deltas for versions internally, so it ought to be competitive on the full history, but only an experiment will prove that. Perhaps this is of some interest. If not, just ignore me. david. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Saturday 25 June 2011 12:28:14 David Slocombe wrote: Hi, Currently I do not even have a working fg on my machine, but I continue to peek at the flightgear-devel list occasionally. Today I saw this discussion of moving the aircraft directories to individual SVN repos instead of git. The major drawback of GIT over CVS and SVN in this instance is GIT treats the repository as an atomic whole. CVS and SVN have the ability to provide partial checkouts, that is you could update a single directory or even just a single file without updating the whole thing. This becomes important when the repository grows into the multigigabyte size range. Ron -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Fri, Jun 24, 2011 at 6:51 AM, Scott scott.hamil...@popplanet.biz wrote: Using SVN so you can download stuff on the fly is ridiculous, The most popular and platform agnostic way to do downloading from multiple locations, with caching and automatic updates, is HTTP these days. Does anybody know offhand how much trouble it would be for our source code to have all loaders of aircraft files go through a library that understands what a relative URL is? If we can cut that over, anybody can develop and host an airplane simply by sticking some static files on the web somewhere. Which can reference components of other airplanes. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Putting map data on SVN made incremental updates feasible. Both for maintainer uploads, and user caches. A similar argument applies to the aircraft, with the complications that (a) there are more maintainers with less coordination, and (b) the dependency graph between directories is not trivial. On the other hand, we don't need streaming on-demand retrieval since few pilots are expected to change aircraft in mid-flight. 8-) Those two complications mean that either we have to do a whole checkout (in which case we might as well use GIT) or maintainers have to mark up their directories with dependency metadata to support automated update tools (in which case SVN would work but not be ideal). I think the critical question is whether maintainers are willing to do that. Suppose they are. A post-commit hook collects all the dependency data, sprinkled across the directories, into a single self-consistent file. The client side utility does a single update to get that file, and then whatever additional updates it specifies for the desired aircraft. SVN would work well enough. We would know the total bandwidth cost for each aircraft (before caching). Supposing we continue to use GIT for development and whole-repository replication, and replace SVN with HTTP for people who want to do quick and incremental aircraft downloads. We can easily prototype the HTTP version by selecting a 1GB subset of the archive for demonstration using AppEngine free quota ... while the community evaluates that prototype. The replica of GIT head in appengine is about $2/month. Add about $1 for any user who chooses to use HTTP to replicate the entire repository instead of using GIT (but we can discourage that). Assuming most individual aircraft are a tiny fraction of the repository (especially after allowing for texture reuse), the true expenses are probably quite manageable. http://code.google.com/appengine/docs/billing.html There are probably cheaper static web hosting options out there, but I figured these numbers are a useful starting point. Personally, I don't see a value in offering HTTP per-file instead of SVN per-directory, but others may do. Hence the discussion above. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Alex wrote Putting map data on SVN made incremental updates feasible. Both for maintainer uploads, and user caches. A similar argument applies to the aircraft, with the complications that (a) there are more maintainers with less coordination, and (b) the dependency graph between directories is not trivial. On the other hand, we don't need streaming on-demand retrieval since few pilots are expected to change aircraft in mid-flight. 8-) Those two complications mean that either we have to do a whole checkout (in which case we might as well use GIT) or maintainers have to mark up their directories with dependency metadata to support automated update tools (in which case SVN would work but not be ideal). I think the critical question is whether maintainers are willing to do that. Suppose they are. A post-commit hook collects all the dependency data, sprinkled across the directories, into a single self-consistent file. The client side utility does a single update to get that file, and then whatever additional updates it specifies for the desired aircraft. SVN would work well enough. We would know the total bandwidth cost for each aircraft (before caching). Supposing we continue to use GIT for development and whole-repository replication, and replace SVN with HTTP for people who want to do quick and incremental aircraft downloads. We can easily prototype the HTTP version by selecting a 1GB subset of the archive for demonstration using AppEngine free quota ... while the community evaluates that prototype. The replica of GIT head in appengine is about $2/month. Add about $1 for any user who chooses to use HTTP to replicate the entire repository instead of using GIT (but we can discourage that). Assuming most individual aircraft are a tiny fraction of the repository (especially after allowing for texture reuse), the true expenses are probably quite manageable. http://code.google.com/appengine/docs/billing.html There are probably cheaper static web hosting options out there, but I figured these numbers are a useful starting point. Personally, I don't see a value in offering HTTP per-file instead of SVN per-directory, but others may do. Hence the discussion above. The main problem right now is that Git cannot cope with the size of the data, and it's getting worse by the day. The Git data repo on Gitorious is no longer fit for purpose as currently configured. Streaming was mentioned (perhaps as a nice-to-have) in the context of Multiplayer. If you didn't have a particular model then it might be streamed instead of showing the rocket propelled blue and yellow glider. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Sat, Jun 25, 2011 at 4:01 PM, Vivian Meazza vivian.mea...@lineone.net wrote: Personally, I don't see a value in offering HTTP per-file instead of SVN per-directory, but others may do. Hence the discussion above. The main problem right now is that Git cannot cope with the size of the data, and it's getting worse by the day. The Git data repo on Gitorious is no longer fit for purpose as currently configured. I'm not trying to defend staying on single-Git, but I think the first step is to implement on-demand loading of individual aircraft (and dependencies) and prove that it works. Otherwise we'll be exposing end users to a lot of breakage. Once we can demand load reliably, breaking the repo into many pieces is relatively trivial. Streaming was mentioned (perhaps as a nice-to-have) in the context of Multiplayer. If you didn't have a particular model then it might be streamed instead of showing the rocket propelled blue and yellow glider. That's an excellent point, thank you. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
