Re: [Flightgear-devel] updates to nav.dat.gz
On 23.04.2012 13:52, Christian Schmitt wrote: We could, if the xml parser would not simply discard any new runways that are not already in the apt.dat file. If I understood a comment of James in the bug tracker correctly, this, however, always has been and still is the normal behaviour, since these XML files were only intended to provide updated airport info, not introduce completely new ones (so it's not a new bug, as someone suggested). Also see below. The xml files are small, can be distributed easily and are very fine- grained, meaning that FG only has to parse the data it really needs for the current scenery path, instead of parsing a close-to 100 MB file on every startup (only for the apt data). I think we need the complete airport data in many places, i.e. when mapping the given start airport code to a starting position, to display the list of available airports in the selection dialog, to have data for the route manager, data for scheduling AI traffic, and for the Nasal interface to nav/airport data (which James is just updating these days). These probably all rely on a complete airport list being available straight away. So, we probably can't restrict things to the current display area. What may make sense is a better, non-compressed file format though, where we only load basic data (airport names/position/runways/...) at start-up, which would probably only require a few 100K. Later, we could go back into the (database) file and load additional data on demand, such as taxiway information, etc. (Which reminds of this http://developer.x-plane.com/2009/09/scalability-and-apt-dat/ ). If data needs to be loaded anyway (airport codes/positions), then distributing it to tons of individual files may not help with start-up delays either. James really needs to comment on nav data things though, since I never touched this area. Terrasync already syncs a global /Models directory, so terrasync scenery can use newer or updated models. We could do the same for nav data. You mean to put small apt.dat/nav.dat parts into these directories? Large even. This wasn't meant as a revolution to nav data handling. But it'd be one line of change to tell terrasync to sync another directory, and probably another one or two to change the search directory for apt.dat/nav.dat, so the terrasync directory was considered before the base package. This would only help with keeping terrasync scenery/nav data in sync. It wouldn't help with individual scenery packages. But I'm not sure if mixing nav data from different scenery packages is a good idea in the first place. At least I would like to have _one_ set of consistent, preferably very latest nav data available in FG. cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] GIT as of today unstable
I've just pulled and compiled simgear and flightgear and pulled a fresh FGData to start package the next lightfield shader version, but it turns out the resulting binary is unstable. I get segfaults about 10 seconds after startup with the master branch, no other errors written to the console, apparently independent on what I do or how I set options on startup. Memory consumption in the system monitor looks normal, reverting back to the old version pulled two weeks ago restores stability, so it's not just some fluke of my machine. Anyone else seeing this? * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
On 24 Apr 2012, at 09:04, Renk Thorsten wrote: I've just pulled and compiled simgear and flightgear and pulled a fresh FGData to start package the next lightfield shader version, but it turns out the resulting binary is unstable. I get segfaults about 10 seconds after startup with the master branch, no other errors written to the console, apparently independent on what I do or how I set options on startup. Memory consumption in the system monitor looks normal, reverting back to the old version pulled two weeks ago restores stability, so it's not just some fluke of my machine. Can you get a backtrace? I've made a change to the startup sequence, yesterday, but I would expect it to crash later (after scenery loading), ten seconds sounds too early. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Am 23.04.12 17:40, schrieb Stuart Buchanan: On Mon, Apr 23, 2012 at 1:17 AM, HB-GRAL wrote: Just a small question because I’m currently looking to OSM street data and try to use it for scenery creation ... in your last screenshot of your improvements I still see buildings on streets (not the streets on urban textures, I mean the real roads coming originally from road line shapefiles). Will it be possible not to cover/overlap roads with random buildings, or is this planned anyway and I missed this point? Yes - this is part of the plan. I now have a solution for this, and also avoiding overlaps between buildings and the existing random objects. Unfortunately I don't yet have a solution for the custom objects from the scenery DB. -Stuart -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Maybe just another dumb question, but wouldn’t it be possible to dynamically create a generalized mask with .stg point coords from the custom objects? -Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Lazy traffic startup
Just so people know, I made a change to how AI traffic is started (so you can ignore this email if you run with traffic turned off) to avoid the long pause during 'initialising subsytems' when all the XML schedules are parsed and loaded. This has a few effects - the app doesn't go unresponsive during startup, and traffic schedule loading happens in parallel with scenery loading - probably a good thing for efficiency for most people. It means AI traffic doesn't appear for a few seconds - typically 10-15 seconds after the splash screen disappears for me. There is however, a problem - there's a final step in starting traffic which still takes a couple of seconds, and that's now occurring during some random update frame, when the file loading has completed. Which gives a nasty user experience, so I need to further break up that step - which I'll do later today. In the meantime, any feedback on this would be welcome - either happy that perceived startup time is reduced, or problems that traffic isn't 'already there' when the splash screen comes down, or anything else. This is still at the 'hack' state, it's be trivial to revert to the old method. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
On 24 Apr 2012, at 08:28, ThorstenB wrote: If data needs to be loaded anyway (airport codes/positions), then distributing it to tons of individual files may not help with start-up delays either. James really needs to comment on nav data things though, since I never touched this area. The quick answer is, we need a lot of data *available* at startup for position init. Parsing it from apt.dat and nav.dat is 'slow', but has been optimised over the years. (Parsing 20MB of text data each launch is still kind of crazy, though) Collecting it from many XML files would also be slow, but there's a general point that we should be decoupling *availability* from *loading*. I've had (in the past, it's bit-rotted now) a binary cache of the navdata and airport-data (stored into $FG_HOME), so that assuming the stat() data on files hasn't changed, no time is spent rebuilding the cache on launch - which makes the FGFS launch time dramatically better, for me. Having such a cache takes a major constraint off how the data is structured and parsed, so I think it needs to be revisited. (Quite a lot of the structuring of FGPositioned and related classes is to make such a scheme possible, especially the fact everything is ref-counted - another benefit of the cache is not needing to have every airport, navaid, runway and taxiway from apt.dat in RAM) To repeat what I said in some other places - on the C++ side I can tolerate (and am happy to write the code!) to deal with nearly any format - XML files in the scenery, single files in XML or the X-plane 810 or 850 format - whatever. It's not that hard, I understand the issues and we have plenty of supporting code. My concern is that 'the community' agree a design that fits most people's needs. (And can generate / get / maintain the data!) Thorsten's point about matching apt.dat and nav.dat into TerraSync makes a lot of sense to me, for example. I'd also be happy looking for navaids in the scenery structure (in the w010n040 dirs?), looking for *all* airport data in the Airports/E/G/P/ structure, or anything else. I really don't mind, and I can support several approaches with some schemes taking precedence, but deciding what design is right, I have not much clue about :) James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
Hi Thorsten, Can you get a backtrace? I can try if you tell me what I need to do... I've made a change to the startup sequence, yesterday, but I would expect it to crash later (after scenery loading), ten seconds sounds too early. Misunderstanding: After scenery loading and I find myself in the cockpit, I have 10 seconds to look around, then comes the crash. I had similar problem this weekend, and a full rebuild (simgear + flightgear) solved the issue. I have the sentiment that changes to SGReferenced (in simgear) could have created this instability Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
On 24 Apr 2012, at 09:20, Renk Thorsten wrote: Can you get a backtrace? I can try if you tell me what I need to do... (re-)Build fgfs with debug symbols: -DCMAKE_BUILD_TYPE=Debug when running cmake, might need to make clean + make again then run fgfs gdb fgfs run --log-level=info --airport=KSFO --some-other-options-to-fgfs wait for the crash ... bt copy and paste what gets spewed out into email I've made a change to the startup sequence, yesterday, but I would expect it to crash later (after scenery loading), ten seconds sounds too early. Misunderstanding: After scenery loading and I find myself in the cockpit, I have 10 seconds to look around, then comes the crash. That's much more likely to be me - does disabling traffic stop the crash? (And does re-winding Git to yesterday morning also stop it?) James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Lazy traffic startup
On 24 Apr 2012, at 10:24, James Turner wrote: This is still at the 'hack' state, it's be trivial to revert to the old method. I'll have a look at it later today. I guess this change was slowly but increasingly becoming necessary. I'll let you know if I see any undesirable side effects. Cheers, Durk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
I had similar problem this weekend, and a full rebuild (simgear + flightgear) solved the issue. I have the sentiment that changes to SGReferenced (in simgear) could have created this instability I pulled everything fresh and compiled both simgear and flightgear new, so things shouldn't be out of sync... That's much more likely to be me - does disabling traffic stop the crash? The problem does occur despite --prop=/sim/traffic-manager/enabled=false in the commandline. It appears rather regular though, so there's not much scattering in the timescale associated. (re-)Build fgfs with debug symbols: -DCMAKE_BUILD_TYPE=Debug when running cmake, might need to make clean + make again then run fgfs gdb fgfs run --log-level=info --airport=KSFO --some-other-options-to-fgfs wait for the crash ... bt copy and paste what gets spewed out into email I will have a look at that, but that takes more time than I have on my hands right now :-( * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
Hi Thorsten, ThorstenB wrote: On 23.04.2012 13:52, Christian Schmitt wrote: We could, if the xml parser would not simply discard any new runways that are not already in the apt.dat file. If I understood a comment of James in the bug tracker correctly, this, however, always has been and still is the normal behaviour, since these XML files were only intended to provide updated airport info, not introduce completely new ones (so it's not a new bug, as someone suggested). Indeed, the XML structure was primarily meant to override incorrect values of pre-existing airfields. Anyhow it's by far flexible enough to add additional features wherever it makes sense. Thus, for the cases you outlined, I don't see the need for distributing yet another set of files carrying almost redundant data. The xml files are small, can be distributed easily and are very fine- grained, meaning that FG only has to parse the data it really needs for the current scenery path, instead of parsing a close-to 100 MB file on every startup (only for the apt data). I think we need the complete airport data in many places, i.e. when mapping the given start airport code to a starting position, to display the list of available airports in the selection dialog, to have data for the route manager, data for scheduling AI traffic, and for the Nasal interface to nav/airport data (which James is just updating these days). These probably all rely on a complete airport list being available straight away. A complete airport list in the meaning of a list containing all airports, a list containing all features of an airport or a list containing all features of all airports ? That's quite a huge difference :-) The Scenery/Airports/ layout was designed with minimal overhead in mind. First there's a plain-text file index.txt, sufficient to build a simple geographical index of all airfields. After the relevant airfields of interest (AoI's ;-) have been identified, quick access if provided by the one-letter XML directory structure. So, we probably can't restrict things to the current display area. What may make sense is a better, non-compressed file format though, where we only load basic data (airport names/position/runways/...) at start-up, which would probably only require a few 100K. Later, we could go back into the (database) file and load additional data on demand, such as taxiway information, etc. (Which reminds of this http://developer.x-plane.com/2009/09/scalability-and-apt-dat/ ). If data needs to be loaded anyway (airport codes/positions), then distributing it to tons of individual files may not help with start-up delays either. Given the above structure theres no need neither to parse huge apt.dat files nor to load tons of individual files. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
Martin Spott wrote: Indeed, the XML structure was primarily meant to override incorrect values of pre-existing airfields. BTW, here's the initial announcement: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17407.html Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Lazy traffic startup
On 24 Apr 2012, at 09:45, Durk Talsma wrote: I'll have a look at it later today. I guess this change was slowly but increasingly becoming necessary. I'll let you know if I see any undesirable side effects. Well, the main thing needed is to break apart the 'finishInit' into more steps, to avoid the remaining pause. I think that can be done by traversing the scheduled aircraft list in batches. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
Can you get a backtrace? Okay, following your instructions I did make clean in any of my build folders, ran cmake with -DCMAKE_BUILD_TYPE=Debug added, recompiled simgear and flightgear, and did gdb ./fgfs run --log-level=info --airport=KSFO --disable-real-weather-fetch --disable-fullscreen --geometry=1200x900 There follows a long log of essentially normal status messages (which I can also get you if your really like), terminating rather suddenly with (...) Loading tile 942040.stg Generating ocean tile Loading tile 942072.stg Loading stg file /home/fgfs/FGData/fgdata/Scenery/Terrain/w130n30/w123n37/942072.stg Loading tile 958424.stg Loading stg file /home/fgfs/FGData/fgdata/Scenery/Objects/w130n30/w122n37/958424.stg Program received signal SIGSEGV, Segmentation fault. 0x5e3d9a08 in ?? () Missing separate debuginfos, use: debuginfo-install e2fsprogs.i386 gcc.i386 glibc.i686 libICE.i386 libSM.i386 libX11.i386 libXau.i386 libXcursor.i386 libXdmcp.i386 libXext.i386 libXfixes.i386 libXrender.i386 libjpeg.i386 libpng.i386 libxcb.i386 mesa.i386 zlib.i386 Not sure that helps... certainly doesn't look very telling to me... Cheers, * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
On 24 Apr 2012, at 11:31, Renk Thorsten wrote: Program received signal SIGSEGV, Segmentation fault. 0x5e3d9a08 in ?? () Missing separate debuginfos, use: debuginfo-install e2fsprogs.i386 gcc.i386 glibc.i686 libICE.i386 libSM.i386 libX11.i386 libXau.i386 libXcursor.i386 libXdmcp.i386 libXext.i386 libXfixes.i386 libXrender.i386 libjpeg.i386 libpng.i386 libxcb.i386 mesa.i386 zlib.i386 Not sure that helps... certainly doesn't look very telling to me... Okay, if you type 'bt' at that point you should get the backtrace, which should help. Although the fact you're getting '??()' is slightly worrying that your fgfs lacks debug information. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
Oops, missed that part of the instructions *blush*
Here's the output:
(gdb) bt
#0 0x5e3d9a08 in ?? ()
#1 0x088dd542 in hashForAirport (c=0x13bedd28, apt=0xdcd3988)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:113
#2 0x088ddc29 in f_airportinfo (c=0x13bedd28, me=
{num = nan(0xf6789), ref = {ptr = {obj = 0x0, str = 0x0, vec = 0
x0, hash = 0x0, code = 0x0, func = 0x0, ccode = 0x0, ghost = 0x0}, reftag = 2147
444617}}, argc=0, args=0x13bee934)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:416
#3 0x08c89a55 in setupFuncall (ctx=0x13bedd28, nargs=0, mcall=0, named=0)
at /home/fgfs/CMake/simgear/simgear/nasal/code.c:316
#4 0x08c8ca02 in run (ctx=0x13bedd28)
at /home/fgfs/CMake/simgear/simgear/nasal/code.c:681
#5 0x08c8d4e0 in naCall (ctx=0x13bedd28, func=
{num = nan(0xf6789151a161c), ref = {ptr = {obj = 0x151a161c, str = 0x151
a161c, vec = 0x151a161c, hash = 0x151a161c, code = 0x151a161c, func = 0x151a161c
, ccode = 0x151a161c, ghost = 0x151a161c}, reftag = 2147444617}}, argc=0,
args=0x0, obj=
{num = nan(0xf6789), ref = {ptr = {obj = 0x0, str = 0x0, vec = 0
x0, hash = 0x0, code = 0x0, func = 0x0, ccode = 0x0, ghost = 0x0}, reftag = 2147
444617}}, locals=
{num = nan(0xf67891503efc0), ref = {ptr = {obj = 0x1503efc0, str = 0x150
3efc0, vec = 0x1503efc0, hash = 0x1503efc0, code = 0x1503efc0, func = 0x1503efc0
, ccode = 0x1503efc0, ghost = 0x1503efc0}, reftag = 2147444617}})
---Type return to continue, or q return to quit---
at /home/fgfs/CMake/simgear/simgear/nasal/code.c:846
#6 0x088cba4b in FGNasalSys::call (this=0x13f77098, code=
{num = nan(0xf6789151a161c), ref = {ptr = {obj = 0x151a161c, str =
0x151a161c, vec = 0x151a161c, hash = 0x151a161c, code = 0x15
1a161c, func = 0x151a161c, ccode = 0x151a161c, ghost = 0x151a161c}, reftag =
2147444617}}, argc=0,
args=0x0, locals=
{num = nan(0xf6789), ref = {ptr = {obj = 0x0, str = 0x0, vec =
0x0, hash = 0x0, code = 0x0, func = 0x0, ccode = 0x0, gh
ost = 0x0}, reftag = 2147444617}}) at
/home/fgfs/CMake/flightgear/src/Scripting/NasalSys.cxx:113
#7 0x088cbe27 in FGNasalSys::handleTimer (this=0x13f77098, t=0xa115d1a8)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalSys.cxx:879
#8 0x088cbe5d in FGNasalSys::NasalTimer::timerExpired (this=0xa115d1a8)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalSys.cxx:897
#9 0x088cfbb3 in SGMethodCallbackFGNasalSys::NasalTimer*, void
(FGNasalSys::NasalTimer::*)()::operator() (this=0xa115d1e0)
at /home/fgfs/FG/include/simgear/structure/callback.hxx:117
#10 0x08cfd50a in SGTimer::run (this=0xa115d1f8)
at /home/fgfs/CMake/simgear/simgear/structure/event_mgr.cxx:38
#11 0x08cfdd4a in SGTimerQueue::update (this=0xaca3824,
deltaSecs=0.1)
at /home/fgfs/CMake/simgear/simgear/structure/event_mgr.cxx:112
#12 0x08cfe07d in SGEventMgr::update (this=0xaca37f0,
delta_time_sec=0.1)
---Type return to continue, or q return to quit---
at /home/fgfs/CMake/simgear/simgear/structure/event_mgr.cxx:43
#13 0x08d01252 in SGSubsystemGroup::Member::update (this=0x12e496d8,
delta_time_sec=0.1)
at /home/fgfs/CMake/simgear/simgear/structure/subsystem_mgr.cxx:361
#14 0x08d01a18 in SGSubsystemGroup::update (this=0xaca3780,
delta_time_sec=0.1)
at /home/fgfs/CMake/simgear/simgear/structure/subsystem_mgr.cxx:221
#15 0x08cffb94 in SGSubsystemMgr::update (this=0xaca3650,
delta_time_sec=0.1)
at /home/fgfs/CMake/simgear/simgear/structure/subsystem_mgr.cxx:448
#16 0x08577c44 in fgMainLoop ()
at /home/fgfs/CMake/flightgear/src/Main/main.cxx:220
#17 0x0855c69f in fgOSMainLoop ()
at /home/fgfs/CMake/flightgear/src/Main/fg_os_osgviewer.cxx:284
#18 0x08575979 in fgMainInit (argc=6, argv=0xbf8aba94)
at /home/fgfs/CMake/flightgear/src/Main/main.cxx:549
#19 0x08541a33 in main (argc=6, argv=0xbf8aba94)
at /home/fgfs/CMake/flightgear/src/Main/bootstrap.cxx:252
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
On 24 Apr 2012, at 11:41, Renk Thorsten wrote:
Here's the output:
(gdb) bt
#0 0x5e3d9a08 in ?? ()
#1 0x088dd542 in hashForAirport (c=0x13bedd28, apt=0xdcd3988)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:113
#2 0x088ddc29 in f_airportinfo (c=0x13bedd28, me=
{num = nan(0xf6789), ref = {ptr = {obj = 0x0, str = 0x0, vec = 0
x0, hash = 0x0, code = 0x0, func = 0x0, ccode = 0x0, ghost = 0x0}, reftag =
2147
444617}}, argc=0, args=0x13bee934)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:416
#3 0x08c89a55 in setupFuncall (ctx=0x13bedd28, nargs=0, mcall=0, named=0)
Okay, this is my fault, but I don't know why / how it's crashing for you.
Presumably you have some aircraft or nasal that makes additional airportinfo()
calls, and you've managed to find a test-case that my testing has not
encountered. Unfortunately we need to find out the relevant bit of Nasal I
guess.
I can see it's an airportinfo() call with no arguments, which location are you
at? KSFO right? H.
If I launch at KSFO, I get no crash, and I can make airportinfo() calls in the
Nasal console with no problems.
Just to check, you have updated simgear as well? There's a bugfix in there I
applied at the same time.
James
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
Okay, this is my fault, but I don't know why / how it's crashing for you. Presumably you have some aircraft or nasal that makes additional airportinfo() calls, and you've managed to find a test-case that my testing has not encountered. Unfortunately we need to find out the relevant bit of Nasal I guess. I can see it's an airportinfo() call with no arguments, which location are you at? KSFO right? H. It doesn't depend - I got a crash at TNCM as well, also using both c172p and the ufo. So this must be something more generic. Just to check, you have updated simgear as well? There's a bugfix in there I applied at the same time. I did pull simgear, when I retry now I get 'Already up-to-date.' and I did recompile both simgear and flightgear after 'make clean' in both build directories using the same procedures I've been using since we migrated to cmake. So to my best ability to tell, my simgear is up to date. * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
On 24 Apr 2012, at 08:28, ThorstenB wrote: If data needs to be loaded anyway (airport codes/positions), then distributing it to tons of individual files may not help with start-up delays either. James really needs to comment on nav data things though, since I never touched this area. The quick answer is, we need a lot of data *available* at startup for position init. Parsing it from apt.dat and nav.dat is 'slow', but has been optimised over the years. (Parsing 20MB of text data each launch is still kind of crazy, though) Collecting it from many XML files would also be slow, but there's a general point that we should be decoupling *availability* from *loading*. I've had (in the past, it's bit-rotted now) a binary cache of the navdata and airport-data (stored into $FG_HOME), so that assuming the stat() data on files hasn't changed, no time is spent rebuilding the cache on launch - which makes the FGFS launch time dramatically better, for me. Having such a cache takes a major constraint off how the data is structured and parsed, so I think it needs to be revisited. (Quite a lot of the structuring of FGPositioned and related classes is to make such a scheme possible, especially the fact everything is ref-counted - another benefit of the cache is not needing to have every airport, navaid, runway and taxiway from apt.dat in RAM) To repeat what I said in some other places - on the C++ side I can tolerate (and am happy to write the code!) to deal with nearly any format - XML files in the scenery, single files in XML or the X-plane 810 or 850 format - whatever. It's not that hard, I understand the issues and we have plenty of supporting code. My concern is that 'the community' agree a design that fits most people's needs. (And can generate / get / maintain the data!) Thorsten's point about matching apt.dat and nav.dat into TerraSync makes a lot of sense to me, for example. I'd also be happy looking for navaids in the scenery structure (in the w010n040 dirs?), looking for *all* airport data in the Airports/E/G/P/ structure, or anything else. I really don't mind, and I can support several approaches with some schemes taking precedence, but deciding what design is right, I have not much clue about :) James Hi James Maybe its also worth to compare whats in FGx here. A lot of all this C++ code is already in. The cache, a very fast apt.dat parser, a xml parser etc. Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
Hi Thorsten, ThorstenB wrote: On 23.04.2012 13:52, Christian Schmitt wrote: We could, if the xml parser would not simply discard any new runways that are not already in the apt.dat file. If I understood a comment of James in the bug tracker correctly, this, however, always has been and still is the normal behaviour, since these XML files were only intended to provide updated airport info, not introduce completely new ones (so it's not a new bug, as someone suggested). Indeed, the XML structure was primarily meant to override incorrect values of pre-existing airfields. Anyhow it's by far flexible enough to add additional features wherever it makes sense. Thus, for the cases you outlined, I don't see the need for distributing yet another set of files carrying almost redundant data. Hi Martin Is the code/the queries to produce the xml output from the postgres apt/nav.dat database available for public somewhere? Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
On 24 Apr 2012, at 12:07, Renk Thorsten wrote: It doesn't depend - I got a crash at TNCM as well, also using both c172p and the ufo. So this must be something more generic. Just to check, you have updated simgear as well? There's a bugfix in there I applied at the same time. I did pull simgear, when I retry now I get 'Already up-to-date.' and I did recompile both simgear and flightgear after 'make clean' in both build directories using the same procedures I've been using since we migrated to cmake. So to my best ability to tell, my simgear is up to date. Okay, then I realise this isn't useful for you, but I'm stumped why it crashes for you. In particular, the hashForAirport function is being passed something that looks like a valid pointer (I think), and it crashing on a line that should only really happen if the pointer is invalid, or there's other memory corruption going on. Again, I realise this doesn't help you, I'm just confused by the failure mode. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
On Tue, Apr 24, 2012 at 7:39 AM, James Turner zakal...@mac.com wrote: On 24 Apr 2012, at 12:07, Renk Thorsten wrote: It doesn't depend - I got a crash at TNCM as well, also using both c172p and the ufo. So this must be something more generic. Just to check, you have updated simgear as well? There's a bugfix in there I applied at the same time. I did pull simgear, when I retry now I get 'Already up-to-date.' and I did recompile both simgear and flightgear after 'make clean' in both build directories using the same procedures I've been using since we migrated to cmake. So to my best ability to tell, my simgear is up to date. Okay, then I realise this isn't useful for you, but I'm stumped why it crashes for you. In particular, the hashForAirport function is being passed something that looks like a valid pointer (I think), and it crashing on a line that should only really happen if the pointer is invalid, or there's other memory corruption going on. Again, I realise this doesn't help you, I'm just confused by the failure mode. For what it's worth, I'm seeing nearly the same thing ... similar back trace-- crashing in hashforairport() about 10-15 seconds after the splash screen has been removed and the sim presented for use. Linux, fedora 15, nvidia graphics ... Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
On 24 Apr 2012, at 14:39, Curtis Olson wrote: For what it's worth, I'm seeing nearly the same thing ... similar back trace-- crashing in hashforairport() about 10-15 seconds after the splash screen has been removed and the sim presented for use. Okay, that's good news since it rules out something Thorsten specific. Can you see if the FGAirport* being passed to hashForAirport looks like a valid pointer? James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On Tue, Apr 24, 2012 at 9:19 AM, HB-GRALwrote: Maybe just another dumb question, but wouldn’t it be possible to dynamically create a generalized mask with .stg point coords from the custom objects? Yes, but the current architecture separates the .stg loading from the .btg loading in such a way that the .stg information is not available at the point I'm creating the random buildings. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
See if this makes sense??
(gdb) frame 1
#1 0x0088fb79 in
hashForAirport (c=0x19e62860, apt=0x6a128d0) at
/home/scotth/Download/Flightgear/git-repo/flightgear/src/Scripting/NasalPositioned.cxx:113
113
std::string name = apt-name();
(gdb) print apt
$1 = (const FGAirport
*) 0x6a128d0
(gdb) print c
$2 = (Context *) 0x19e62860
(gdb) print
apt-name
$3 = {const std::string (const FGAirport * const)} 0x6609c0
(gdb) print apt-name()
Program received signal SIGSEGV, Segmentation
fault.0x006609c0 in ?? ()
The program being debugged was
signaled while in a function called from GDB.
GDB remains in the frame
where the signal was received.
To change this behavior use set
unwindonsignal on.
Evaluation of the expression containing the
function(at 0x0x6609c0) will be abandoned.
When the function is done
executing, GDB will silently stop.
(gdb)
S.
On Tue, 24 Apr 2012
14:45:17 +0100, James Turner wrote:
On 24 Apr 2012, at 14:39, Curtis
Olson wrote:
For what it's worth, I'm seeing nearly the same thing
... similar back trace-- crashing in hashforairport() about 10-15
seconds after the splash screen has been removed and the sim presented
for use.
Okay, that's good news since it rules out something Thorsten
specific. Can you see if the FGAirport* being passed to hashForAirport
looks like a valid pointer? James
--
Live Security Virtual Conference Exclusive live event will cover all
the ways today's security and threat landscape has changed and how IT
managers can respond. Discussions will include endpoint security, mobile
security and the latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ [1]
___ Flightgear-devel mailing
list Flightgear-devel@lists.sourceforge.net [2]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel [3]
Links:
--
[1]
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
[2]
mailto:Flightgear-devel@lists.sourceforge.net
[3]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
Hi James, Here is a bit more information. I added some printf's before the call to findClosest(pos, maxRange, filter) in f_airportinfo() The first time through, this seems to work, it returns a valid pointer, which gets passed to hashForAirport(c, apt) a few lines later. In hashForAirport() I also printed the name and id that FGAirport *apt points to. The first time through it prints id = 58Q name = Mazza The crash happens on the second time through this call sequence. The second call to f_airportinfo() seems to follow the same logic and get the same answer. The FGAirport *apt pointer returned by findClosest() is the same value as previously. However when passing this to hashForAirport() it appears that the references it apt-ident() and apt-name() trigger a segfault. I tried running with valgrind and the error didn't happen -- hmmm... Trying it again, but a valgrind startup is excruciatingly slow ... Curt. On Tue, Apr 24, 2012 at 8:45 AM, James Turner zakal...@mac.com wrote: On 24 Apr 2012, at 14:39, Curtis Olson wrote: For what it's worth, I'm seeing nearly the same thing ... similar back trace-- crashing in hashforairport() about 10-15 seconds after the splash screen has been removed and the sim presented for use. Okay, that's good news since it rules out something Thorsten specific. Can you see if the FGAirport* being passed to hashForAirport looks like a valid pointer? James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
On 24 Apr 2012, at 15:57, Curtis Olson wrote: I tried running with valgrind and the error didn't happen -- hmmm... Trying it again, but a valgrind startup is excruciatingly slow ... It's probably a reference counting issue. FGAirport is a FGPositioned and hence reference counted. The Nasal Ghost is supposed to deal with this - when we create a ghost around the airport, we take a reference (SGReferenced::get) and when Nasal garbage-collects the ghost, the reference count is decremented. (SGReferenced::put) If the reference count hits zero, the airport will be freed, leading to the issue you see. But that would imply there's nothing else holding a reference to the airport, and that's not the case, because the the spatial index (the octree) in positioned.cxx holds a reference to everything at the moment. If I'd screwed up the ref-counting logic completely, I'd expect it to be crashing for me exactly the same, and it's not. Very weird. So likely I have made a subtle screw-up that only affects Linux. You could test this by commenting out the call to SGreferencd::put() in sgrefGhostDestroy - references will be leaked, but if it stops the crash then we can be sure it's a ref-counting bug. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
On Tue, Apr 24, 2012 at 10:06 AM, James Turner zakal...@mac.com wrote: It's probably a reference counting issue. FGAirport is a FGPositioned and hence reference counted. The Nasal Ghost is supposed to deal with this - when we create a ghost around the airport, we take a reference (SGReferenced::get) and when Nasal garbage-collects the ghost, the reference count is decremented. (SGReferenced::put) If the reference count hits zero, the airport will be freed, leading to the issue you see. But that would imply there's nothing else holding a reference to the airport, and that's not the case, because the the spatial index (the octree) in positioned.cxx holds a reference to everything at the moment. If I'd screwed up the ref-counting logic completely, I'd expect it to be crashing for me exactly the same, and it's not. Very weird. So likely I have made a subtle screw-up that only affects Linux. You could test this by commenting out the call to SGreferencd::put() in sgrefGhostDestroy - references will be leaked, but if it stops the crash then we can be sure it's a ref-counting bug. Hi James, Based on two runs with out crashing, that seems to prevent the crash ... Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
On 24 Apr 2012, at 16:31, Curtis Olson wrote: Based on two runs with out crashing, that seems to prevent the crash ... Okay, so that's good but leaves me wondering why it doesn't crash on Mac the same way. And also, how I've got the ref-counting wrong. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
On Tue, Apr 24, 2012 at 10:35 AM, James Turner zakal...@mac.com wrote: On 24 Apr 2012, at 16:31, Curtis Olson wrote: Based on two runs with out crashing, that seems to prevent the crash ... Okay, so that's good but leaves me wondering why it doesn't crash on Mac the same way. And also, how I've got the ref-counting wrong. If an FGAirport object was ref-counted and deleted because the ref-count went to zero, then why would FGAirport::findClosest() still be returning a pointer to it it as the closest airport? Is it not getting fully/properly deleted or removed from the list and you just getting lucky on the Mac that it's not segfaulting? Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
Hi James, just a guess here, but in the past, I had to fix issues brought when converting raw pointers to smart pointers and ending up deleting the pointer given by the smart pointer explicitly. For example : SGSharedPtrMyClass myPtr = new MyClass; then delete myPtr; or delete myPtr.get(); afterward, the destructor of SGSharedPtrMyClass does another delete on the same memory and may crash, depending the system and the memory layout Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
flightg...@sablonier.ch wrote: Is the code/the queries to produce the xml output from the postgres apt/nav.dat database available for public somewhere? It's a simple Bash/PostgreSQL proof of concept which has seen 'evolutionary' development, looping through the list of ICAO codes, collecting the relevant data and echoing hand-crafted XML. Now I know it works as planned, I'd use Perl XML::Writer to do it again, probably saving more than 50 % of code lines ;-) http://mapserver.flightgear.org/git/gitweb.pl?p=sceneryweb;a=blob;f=mapserver/Threshold_ILS_TWR.sh Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
On 24 Apr 2012, at 16:50, Curtis Olson wrote: If an FGAirport object was ref-counted and deleted because the ref-count went to zero, then why would FGAirport::findClosest() still be returning a pointer to it it as the closest airport? Is it not getting fully/properly deleted or removed from the list and you just getting lucky on the Mac that it's not segfaulting? As far as the FGPositioned Octree is concerned (which is what findClosest uses internally), it's holding an owning ref and hence things can't be removed from it, for the moment. So what I guess is happening, is that I'm breaking the ref-counting scheme *somehow*, and hence the Octree is left holding a dead reference as you say. And somehow how I get away with this on Mac. But this feels a little implausible, since in other similar scenarios the Mac crashes quite happily! James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
On Tue, Apr 24, 2012 at 11:09 AM, James Turner wrote: As far as the FGPositioned Octree is concerned (which is what findClosest uses internally), it's holding an owning ref and hence things can't be removed from it, for the moment. So what I guess is happening, is that I'm breaking the ref-counting scheme *somehow*, and hence the Octree is left holding a dead reference as you say. And somehow how I get away with this on Mac. But this feels a little implausible, since in other similar scenarios the Mac crashes quite happily! I've manage to have a run or two on Linux that didn't crash if that makes you feel any better. :-) But I'll give you that it's much easier to fix a problem that you can observe versus one you can't observe. Perhaps the ref counting problem isn't getting triggered on your Mac for some other subtle reason? Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
Im assuming my crash is related, but it only happens when i open the route-manager dialog... Syd On Tue, Apr 24, 2012 at 10:24 AM, Curtis Olson curtol...@gmail.com wrote: On Tue, Apr 24, 2012 at 11:09 AM, James Turner wrote: As far as the FGPositioned Octree is concerned (which is what findClosest uses internally), it's holding an owning ref and hence things can't be removed from it, for the moment. So what I guess is happening, is that I'm breaking the ref-counting scheme *somehow*, and hence the Octree is left holding a dead reference as you say. And somehow how I get away with this on Mac. But this feels a little implausible, since in other similar scenarios the Mac crashes quite happily! I've manage to have a run or two on Linux that didn't crash if that makes you feel any better. :-) But I'll give you that it's much easier to fix a problem that you can observe versus one you can't observe. Perhaps the ref counting problem isn't getting triggered on your Mac for some other subtle reason? Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Multiplayer, Open RTI/ HAL and online future..
I want to ask the question of what is the future with Multiplayer? Its sems that the flavour and future is openRTI? but what is that about... So where are we going with the multiplayer stuff? Is there a plan, is there a vatsim replace? Whats the MP protocl, or is it Open/RTI ? are there json feeds and flightplans, and network and all.. live ATC in brazil ? Where are we going? is ther any scenario where we can use OpenRTI .. eg radar for kids ? got the severs, got the data,, how do we play with it ?? pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
Now this is really interesting..
http://mapserver.flightgear.org/git/gitweb.pl?p=sceneryweb;a=blob;f=mapserver/Threshold_ILS_TWR.sh
I'm kinda moving into django land after lots of screaming and whining to
myself.. but it does seem to be a platform of sorts.. and sql alchemy
compat etc..
So can I throw into the mix here the concept of having a kinda API and
structure and content (the grolaw coverage on Oracles vs Goggles spring to
mind).. ie the structure and content of the API ???
the the structure and content.. argument is simple.. and anyone would
figure that out to be..
/airport/code/ and all the data...
So the trend is towards more machine to machine interpolation and
networks.. etc.. and end points an api of data...
To create a mass distributed system which is what FG is, we need to
simply uncouple the master and create and index server with the meta
data... and the local info..
for that we need an API.. and we need AIP data from online.. and active..
update latest.. and this is head..
To make sure it HEAD is need and upvote or confirmation and maybe even
locks on data delegated to upstream.. == send up.. then it comes back
down.. thats the ONLY way it works.. send up ad it comes back down.. ..
That is the reality check is the AIP, eg eurocontrol and icao.. and this is
there..
The BIG snag is that the initial download is huge... so to break it down
and install only the part required would be a huge advantage IMHO..
We can simply break it down into the main zones..
eg UK, switzerland.. cool for montains, glaasgow has montains..
or USA.. need the rockies and LA and stuff..
The caribeam.. and every island...
So what I am suggesting is that thaer is an are of interest, and long
foreign trip are ocassional maaybe.. or curiosity...
But if I need data and a quick map of the locatio and terrain and the
enviroment etc..
So I think what we need to have Hard look at is the FlightGear.api and
create a nice cool eniroment fo anyone to play in..
By the Flighgear.API I mean all the interfaces online and instances and all
chatting to each other and all machines and mobiles and rasberry pi
etc...ie the SIM platform of sorts..
Some of the stuff is quite simple eg AIP info retured in json, downlading
latest png.. or even better. sending my shot and an u tube vid tgo via
facebook account .. a plugin... somewhat..
But is OpenRTI the patform.. so we need to build a virtual system so kids
can play together and chat on a platfrom... Lets face it .. its ceerntainly
no real controls atmo.. eg could be subject dos attacks etc.. and I hope
that never happens...
So the API ?
print Airport(EGLL)-runways()
or alike..
Something to thing about...
eg aptdat_2_XXX as staric functions
BIG PROBLEM..
is the api defs..so I am indeed thinkng yaml format is the solutions.. cos
its machine and human edible..
eg
aiport: EGLL
naaame: JOHN WAYNE INT
name: Johh Wayne Airport
runways: [
09R-27L: {etc ..etc}}
We need to get into more mass distribution and and api to install on your
spare sever and hobby.. and a simple access point to join in..
Thats my vision.. cannot work as a centralised system ever.. so that fat
must be realised..
How we shard the data.. but probalby icao sytle maaybe
some thoughts
aairports-KSFO..
We REALLY REALLY need to clean this data up and make it fast for a newbie..
The data pile of waypoint and aptdat will constantly get bigger forever..
so we need to shard and index a buit..
But will relly on one of 2 circumstance..
1) we need to build and index and that needs to be online
2) we need to run an index of voice server and live ATC
3) we need some maap.fgx.xhmaass cashes and please clone me..
For aall of that we need a statergy.. eg I got a spaaare web spaace.. and
unused etc..
Then yes that is what we want... some spare spaace on your online paace..
and we can say.. ok well stick the images on you server and done.. he he ..
that is precisely it..
. maybe a new idea..
pete
On Tue, Apr 24, 2012 at 4:56 PM, Martin Spott martin.sp...@mgras.netwrote:
flightg...@sablonier.ch wrote:
Is the code/the queries to produce the xml output from the postgres
apt/nav.dat database available for public somewhere?
It's a simple Bash/PostgreSQL proof of concept which has seen
'evolutionary' development, looping through the list of ICAO codes,
collecting the relevant data and echoing hand-crafted XML. Now I know
it works as planned, I'd use Perl XML::Writer to do it again, probably
saving more than 50 % of code lines ;-)
http://mapserver.flightgear.org/git/gitweb.pl?p=sceneryweb;a=blob;f=mapserver/Threshold_ILS_TWR.sh
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security
[Flightgear-devel] FG-api
To add furtheer.. http://mapserver.flightgear.org/git/gitweb.pl?p=sceneryweb;a=blob;f=mapserver/Threshold_ILS_TWR.sh Were all reinventing a wheel.. I think there is a lo of data in blobs, and we converting one blob to another.. Indeed after some reasearch.. robin sppol out the apt table with a last updated which is the last airport in the list.. +YAML++ Yamls is a nice format cos it machine readable.. But to store the values correct eg aa heaging of 200.1999 degrees and alike.. we will need some fefinitions in the guide.. We can then stash the yaml file as the latest.. and everything after that will be updated vias a transmit.. As does the Real world.. the only stuff will be the changes.. which is what we are interested in.. delta.. So its easy from my eyes.. Create a model.. as a core and inherit a sql postgres layer.. and sub quiries as objects.. whether in python, php etc et all.. we need to promote local stuff more.. and create an index based scenario.. pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
James, I wasn't affected by a crash until I realized that hashForAirport was never called. Then I enabled animated jetways and the segfault came, after few successful calls. I am not able to tell why though HTH -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
The initial commit of the random buildings is now available in git. To enable this, you'll need to set /sim/rendiner/random-buildings=true. This is available through the Rendering Options dialog, and requires the scenery tile to be reloaded to take effect (via the Reload Scenery button on that dialog). A couple of notes: - At present, the building placements add significantly to the scenery generation time - particularly if you start increasing the building density (/sim/rending/building-density). I need to spend some time looking at alternative algorithms for this. - The buildings do not use the Effects system yet. An obvious enhancement would be to add a night-time texture with some emissive properties and use some effect to simulate night illumination of the buildings. - Placement works well against other buildings, landclass edges (though there are sometimes very small overlaps (~1m), but not against custom scenery. - I've modified Effects/urban.eff so that the existing urban shader is disabled when random buildings are enabled. Unfortunately I can't mask the buildings in such a way that they don't collide with the urban shader generated buildings, so they don't work well together. - The texture used for the buildings (Textures/buildings.png) is pretty simplistic. If someone has the time and interest in improving it, they are very welcome - textures aren't my forte. Feedback is welcome as always. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
Hi, On Tuesday, April 24, 2012 13:39:59 James Turner wrote: Okay, then I realise this isn't useful for you, but I'm stumped why it crashes for you. In particular, the hashForAirport function is being passed something that looks like a valid pointer (I think), and it crashing on a line that should only really happen if the pointer is invalid, or there's other memory corruption going on. Just stepping into this discussion somehow. I could by the length of the thread not exactly find what is going wrong and how to reproduce this. But jut having a quick look at NasalPositiond.cxx, I can see that this does not match the intented use of SGReferenced. I have checked in what is needed to match how it's intented to be used. Given that you seem to experience dangling pointers and now things are actually deleted when the reference count drops to zero - that did not happen before, I guess that this makes things worse at first. But you might be able to find the real cause of the problem a little better now. Else, I am online again tomorrow evening. Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
On 24 Apr 2012, at 22:33, Mathias Fröhlich wrote: I could by the length of the thread not exactly find what is going wrong and how to reproduce this. But jut having a quick look at NasalPositiond.cxx, I can see that this does not match the intented use of SGReferenced. I have checked in what is needed to match how it's intented to be used. Given that you seem to experience dangling pointers and now things are actually deleted when the reference count drops to zero - that did not happen before, I guess that this makes things worse at first. But you might be able to find the real cause of the problem a little better now. Else, I am online again tomorrow evening. Okay, I guess I was assuming I can use SGreferenced the same way I use release/retain in Cocoa, or addRef/decRef in COM/XPCOM. But it seems as if this is not the case, from looking at your commit - I can't use SGreferenced as a virtual base, and I have to make the delete call by hand. I guess this is to avoid virtual method overhead on SGreferenced? James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sanitizing materials.xml
On Thu, Apr 19, 2012 at 9:11 PM, Stuart Buchanan wrote: On Fri, Feb 24, 2012 at 7:38 PM, Stuart Buchanan wrote: On Fri, Feb 24, 2012 at 8:42 AM, Torsten Dreyer wrote: What about having a sub-subdirectory structure to avoid name mangeling, like Materials/base/ (contains all common files and includes) Materials/default/ (contains the default definitions and textures) Materials/dds/ (contains the dds definitions and textures) Excellent idea. Will do! I'm going to leave the existing materials[-dds],xml files unchanged for now so people can easily go back to them if they find bugs in the new versions of the files. 2 months is long enough for the new files to have bedded in :) Unless there are major objections, I'll merge the changes that have been made subsequently to data/materials.xml and data/materials-dds.xml into the data/Materials/[default|dds]/materials.xml files and retired the old files tomorrow evening GMT. That has (belatedly) been done. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On Tue, Apr 24, 2012 at 10:09 PM, Stuart Buchanan wrote: The initial commit of the random buildings is now available in git. One thing I forgot to mention: you need to be running with data/materials/default/materials.xml or data/materials/dds/materials.xml. The data/materials[-dds],xml are obselete and will be removed shortly. -Stuart Hi Stuart Maybe this is the point now to change something in scenery creation process? AFAIK towns are still (?) point features ... maybe this could be switched now to polygon features, using random buildings code later instead of this unique village models ? What do you think about towns and random buildings ? Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ..mapserver_Threshold_ILS_TWR.sh-en (English comments), was: updates to nav.dat.gz
On Tue, 24 Apr 2012 15:56:50 + (UTC), Martin wrote in message jn6ig2$n84o$1...@osprey.mgras.de: flightg...@sablonier.ch wrote: Is the code/the queries to produce the xml output from the postgres apt/nav.dat database available for public somewhere? It's a simple Bash/PostgreSQL proof of concept which has seen 'evolutionary' development, looping through the list of ICAO codes, collecting the relevant data and echoing hand-crafted XML. Now I know it works as planned, I'd use Perl XML::Writer to do it again, probably saving more than 50 % of code lines ;-) http://mapserver.flightgear.org/git/gitweb.pl?p=sceneryweb;a=blob;f=mapserver/Threshold_ILS_TWR.sh Cheers, Martin. ..I appended Google's English translation to Martin's (German) comments in mapserver_Threshold_ILS_TWR.sh and attached it all here as mapserver_Threshold_ILS_TWR.sh-en, in case it helps: arnt@celsius:~$ md5sum mapserver_Threshold_ILS_TWR.sh 33f3f45d3550004bd6328f0ccfa89782 mapserver_Threshold_ILS_TWR.sh arnt@celsius:~$ -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...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. mapserver_Threshold_ILS_TWR.sh-en Description: Binary data -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Yves: Towns are not point features. The vmap0 represents towns as points, but these particular points are parsed by terragear and turned into 1km by 1km polygons which are burned into the terrain. That gives the square appearance in the default scenery. In custom scenery, medium to low density urbanized is typically mapped to town. In any case in my opinion materials.xml should represent the cs_ layers on the mapserver in order to increase flexibility for scenery generation. Thanks John -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
As an aside: When working on the codebase, I maintain a local script that launches FGFS by disabling whatever features prevent the simulation from being flyable on my development machine. When I am unable to turn off features that prevent the simulator from running, and disabling them in source isn't clean enough to maintain as a local patch, I stop working on the project until the next time I buy a machine ... at which point I revisit the script. Flyability includes being able to sustain at least 3 FPS. It would probably make things a lot simpler for the average user if FGFS included a wizard that automatically identified which combinations of features would be usable on a specific installation. Using that result as constraining logic in the menus would allow unusable features to be kept disabled and trivially cheap features (for the given hardware) to be kept enabled. On Wed, Apr 18, 2012 at 2:36 AM, Erik Hofman e...@ehofman.com wrote: On Wed, 2012-04-18 at 09:46 +0100, Vic Marriott wrote: It's probably not so much about memory consuming but more about resource consuming. But be assured that most new options are easily turned off. Sorry, but I think the point is being missed here. Where is the sense in making very impressive advancements to FG, if the average user has to turn most of them off in order to get a usable fps. Why does anybody always expect the most imressive results on their old Intel 486DX? Advances in quality always requires more resources. Period. If your hardware doesn't support it, bad for you but be grateful FlightGear at least provides an option to turn to less nifty rendering. Erik -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
Hi,
On Tuesday, April 24, 2012 22:51:34 James Turner wrote:
Okay, I guess I was assuming I can use SGreferenced the same way I use
release/retain in Cocoa, or addRef/decRef in COM/XPCOM. But it seems as if
this is not the case, from looking at your commit - I can't use
SGreferenced as a virtual base, and I have to make the delete call by hand.
I guess this is to avoid virtual method overhead on SGreferenced?
Yes.
SGReferenced should exactly *not* contain any virtual table. This is supposed
to be the helper class for reference counting, but it should be as lightweight
as possible. Imagine we want at some time have a variable size mathematical
vector container that works with a copy on write semantics, I definitely want
to use SGReferenced there and have no vtable at all.
If you want something that you can just use a general base class for
heavyweight stuff, invent a class derived from SGReferenced or better
SGWeakReferenced that introduces this vtable stuff. And since we are looking
then for something more heavy, I would tend to use SGWeakReferenced as base
class for an SGObject
class SGObject : public SGWeakReferenced {
public:
virtual ~SGObject() {}
}
The weak referenced class provides the ability to have weak pointers to such a
WeakReferenced derived class. That are pointers that know about when the last
reference to the instance it points to is deleted and provides a
SGSharedPtrT SGWeakPtrT::lock() method that atomically and thread safe
returns either a valid shared pointer to the still alive object or a null
pointer since the objects reference count was already zero and the object is
at least being deleted or already dead.
If you want the destructor protected, I need to backport something more from
OpenRTI and stuff to simgear.
What about the mentioned problems? Better? Worse?
Mathias
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
