[Flightgear-devel] Re: [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
* Vassilii Khachaturov -- Friday 25 November 2005 22:57: The following are still in * the exception classes were lacking the copy ctors and assignment operators, but the default ones for them were unusable as the string instance members are not suitable for byte-by-byte copying! But ... classes without copy/assignment operator aren't copied byte-by-byte, but member-by-member[1]. So, for string members the string copy constructor is used. Again, the code looks right to me as it is. m. [0] Bjarne Stroustrup, The C++ Programming Language, 2nd edition, p. 582, r.12.8 Copying Class Objects ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
But ... classes without copy/assignment operator aren't copied
byte-by-byte, but member-by-member[1]. So, for string members the
string copy constructor is used. Again, the code looks right to me
as it is.
m.
[0] Bjarne Stroustrup, The C++ Programming Language, 2nd edition,
p. 582, r.12.8 Copying Class Objects
It's a pity I am at home sick, and without the book. I don't know
what is written in the section you refer to.
Therefore the only
thing I can do is try to code it and see what's happening. I tried to
amend the snippet with a 3rd case, which crashes on my machine, and,
AFAIU, precisely because the default member copy semantics is byte-by-byte
on my gcc (now it could well be that this is not the std, but I was pretty
happy about gcc compliance so far). What do you think?
BTW, maybe you meant to say that if I don't provide a copy ctor
in the derived class, then the parent's copy ctor is nevertheless
involved on the parent portion? I know *that*, but it doesn't cover
copying of the derived class' instance data.
#include exception
#include iostream
#include string
using namespace std;
struct E : exception {
E() : _msg(DEFAULT) { cout E::E() endl; }
E(const char* s) : _msg(s) {
cout E::E(const char* s ) endl; }
E(const E e) : _msg(e._msg + (clone)) {
cout E::E(const E e._msg ) endl; }
E operator=(const E e) {
cout E::operator=( e._msg ) assigned over _msg
endl;
_msg = e._msg + (assigned);
return *this;
}
virtual ~E() throw() { cout E::~E() _msg endl; }
const char* what() const throw() { _msg.c_str(); }
string _msg;
};
struct EE {
E e;
EE(const char* s) : e(s) { cout EE::EE( s ) endl;}
virtual ~EE() throw() { cout EE::~EE( e._msg ) endl;}
};
void foo(int i) throw(exception)
{
cout foo entering endl;
E unused(xUNUSED);
switch (i) {
case 0:
break;
case 1:
throw E(x1);
case 2: {
E weird(x2);
throw weird;
}
case 3: {
EE default_cloned(x3);
throw default_cloned; // CRASH as EE::e is never cloned
properly
}
}
cout foo exiting endl;
}
int main()
{
for (int i = 0; i 4; i++) {
try {
foo(i);
}
catch (E e) {
cout Caught e.what() endl;
}
}
return 0;
}
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Gear animation tutorial
Josh Babcock I just made up a tutorial about making gear retraction animations run smoothly with complicated landing gears. It's still missing the final animation code, but I thought I'd throw it up to see what everybody thinks. It's got lots of in-line images, so be warned. I'm considering changing this to in-line thumbnails hotlinked to the full sized images. Please give feedback. http://jrbabcock.home.comcast.net/gear-tutorial/gear-tutorial.html Gosh, Josh, what an effort. Well done. Couple of points. First, I model the gear with the oleos extended, which helps with getting the compression right. Most drawings show the gear with the oleos at some intermediate compression. Some interpretation/intelligent guesswork is usually required. Second, sometimes the movement of jacks and draglinks etc. is too difficult to model well, so I cheat and hide them once they can no longer be seen readily (I do that anyway to save vertices). And one typo: separate. I'm impressed! Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
* Vassilii Khachaturov -- Saturday 26 November 2005 11:02:
But ... classes without copy/assignment operator aren't copied
byte-by-byte, but member-by-member[1].
It's a pity I am at home sick, and without the book. I don't know
what is written in the section you refer to.
There's written what I said: that classes without copy/assignment
operator aren't copied byte-by-byte, but member-by-member. I'm
not going to cite the whole book. You have to trust me. :-P
Therefore the only
thing I can do is try to code it and see what's happening. I tried to
amend the snippet with a 3rd case, which crashes on my machine,
No, it doesn't crash your machine. It calls std::unexpected()
because you throw an exception that you *explicitly* disallowed.
That's a feature! :-)
What do you think?
I think that I should debug fgfs/sg, not your code snippets,
but anyway:
void foo(int i) throw(exception)
Here you say that only class exception and its derivatives are
allowed.
struct EE {
E e;
EE(const char* s) : e(s) { cout EE::EE( s ) endl;}
virtual ~EE() throw() { cout EE::~EE( e._msg ) endl;}
};
But you don't make EE a derivative of exception:
struct EE : public exception { ...
m.
PS: FlightGear/SimGear doesn't use Exception Specifications, so the
bug in your test program can't really happen.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
Hi Melchior, thanks for the help. * Vassilii Khachaturov -- Saturday 26 November 2005 11:02: But ... classes without copy/assignment operator aren't copied byte-by-byte, but member-by-member[1]. It's a pity I am at home sick, and without the book. I don't know what is written in the section you refer to. There's written what I said: that classes without copy/assignment operator aren't copied byte-by-byte, but member-by-member. I'm not going to cite the whole book. You have to trust me. :-P sure... Since now I see the code behaves that way, too :) Therefore the only thing I can do is try to code it and see what's happening. I tried to amend the snippet with a 3rd case, which crashes on my machine, No, it doesn't crash your machine. It calls std::unexpected() because you throw an exception that you *explicitly* disallowed. That's a feature! :-) yeah, right... and I never added a handler catching EE in the catch loop, so it aborts even w/o the exception specification. Fixing those shows (e.g. by adding EE's inheritance from exception (as you suggested), and catching an exception instead of E) that everything works, and that the E's copy ctor does auto-fire when the EE gets cloned via the default copy ctor semantics - it's fixed at http://www.tarunz.org/~vassilii/locally-created-exceptions.cpp What do you think? I think that I should debug fgfs/sg, not your code snippets, ...which of course have no relation to fgfs/sg debugging :-))) [snip] thanks for catching this one. I'll 1) go to sleep and hope that the flu will go away enough to get thinking sanely again 2) will try not to submit lengthy patches coded up when being sick before reviewing them myself being sane 3) re-read the BS book ASAP in case I forgot smth else out of C++ V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Gear animation tutorial
On Saturday 26 November 2005 03:09, Josh Babcock wrote: I just made up a tutorial about making gear retraction animations run smoothly with complicated landing gears. It's still missing the final animation code, but I thought I'd throw it up to see what everybody thinks. You have no idea how good your timing is on this one :-) I've been putting off doing the gear animation on my Lightning for a while now, but with this sort of insight I'm certain the job will be much quicker. Like so many other things in the modelling process, a step by step example can save so many hours of slaving away learning the hard way. It's got lots of in-line images, so be warned. I'm considering changing this to in-line thumbnails hotlinked to the full sized images. I like it just as it is, myself - I find that having to open bigger pictures from in-line thumbnails is just a nuisance when trying to juggle several open windows or browser tabs, even with a sane window management setup. Of course, having had broadband available here for less than a year I remember well the plight of the dial-up user; but even then, for tutorials I just downloaded the whole lot and _then_ read them; saved time and bandwidth in the long run. The full-size in-line pictures probably make that process even simpler, if anything. Please give feedback. OK, it's great - thanks! Obviously the final animation code will be nice to finish it off, but as it stands it looks excellent. I'll let you know if I get baffled at any point once I start working through it. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft Download/Install App
On Saturday 26 November 2005 14:25, Arthur Wiebe wrote: The idea is for an aircraft application. This application would download (preferrably an XML file) from a server, parse, and through a GUI have the ability to select aircraft, see details including previews, press a button to download and install. The application would guess the most likely places for where to install. But let the user change it of course. The application would be written in C++ using the wxWidgets framework so that it will look and work right on all platforms. This hypothetical application sounds very much to me like an extension to the existing fgrun... But there's no way I'm going to take it on myself. /me sick of that. So any takers? Or is it a rotten idea I should never have posted about? Or perhaps even something already discussed. Personally, I think it's a good idea, particularly for a certain class of users who often seem to have absolutely no concept of what goes on behind those mesmerising icons. At the moment, they either flood the users list with the same old repetitive emails (which is part of what it's there for, of course), or much worse, just give up on FG as being over their heads. Apps with similar facilities are not uncommon; I'm sure it could be done fairly easily. But again, not by me since I'm not a C/C++ programmer and have enough to work on as it is, even with fgfs related things... It maybe sounds about right for a project idea for undergraduate students, as has been requested here recently... Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Aircraft Download/Install App
* AJ MacLeod -- Saturday 26 November 2005 15:50: This hypothetical application sounds very much to me like an extension to the existing fgrun... ... and we could call it ... *pause* ... fgadmin! m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Gear animation tutorial
Vivian Meazza wrote: Josh Babcock I just made up a tutorial about making gear retraction animations run smoothly with complicated landing gears. It's still missing the final animation code, but I thought I'd throw it up to see what everybody thinks. It's got lots of in-line images, so be warned. I'm considering changing this to in-line thumbnails hotlinked to the full sized images. Please give feedback. http://jrbabcock.home.comcast.net/gear-tutorial/gear-tutorial.html Gosh, Josh, what an effort. Well done. Couple of points. First, I model the gear with the oleos extended, which helps with getting the compression right. Most drawings show the gear with the oleos at some intermediate compression. Some interpretation/intelligent guesswork is usually required. Second, sometimes the movement of jacks and draglinks etc. is too difficult to model well, so I cheat and hide them once they can no longer be seen readily (I do that anyway to save vertices). And one typo: separate. I'm impressed! Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Good point. I also do this, but because this model has knees (not sure what to call them) instead of oleos, I skipped it. Still, it should be extended to that it is below the ground in its resting pos. I will add this, and a section for dealing with gear-compression-norm and gear-compression-m. I'll also add a LOD section. The neat thing about this method is that it's so east to get everything in the right position, so you don't really need to hide it until you close the doors. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Gear animation tutorial
AJ MacLeod wrote: I like it just as it is, myself - I find that having to open bigger pictures from in-line thumbnails is just a nuisance when trying to juggle several open windows or browser tabs, even with a sane window management setup. Of course, having had broadband available here for less than a year I remember well the plight of the dial-up user; but even then, for tutorials I just downloaded the whole lot and _then_ read them; saved time and bandwidth in the long run. The full-size in-line pictures probably make that process even simpler, if anything. Maybe I can compromise, and interlace the images. Can png images be interlaced, or would I have to use jpgs? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft Download/Install App
Arthur Wiebe wrote: This is an idea that's been floating around in my head for awhile, mainly because there is currently no *very easy* way for a newbie to install new aircraft in FlightGear. Unless that user is used to going through Program\ Files in Windows and through package contents on OSX. The idea is for an aircraft application. This application would download (preferrably an XML file) from a server, parse, and through a GUI have the ability to select aircraft, see details including previews, press a button to download and install. The application would guess the most likely places for where to install. But let the user change it of course. The application would be written in C++ using the wxWidgets framework so that it will look and work right on all platforms. But there's no way I'm going to take it on myself. /me sick of that. So any takers? Or is it a rotten idea I should never have posted about? Or perhaps even something already discussed. -- Arthur/ - http://sourceforge.net/users/artooro/ - http://artooro.blogspot.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d And maybe it would also be a good idea to package aircraft and scenery in rpm or deb format. That way you don't have to worry about dependencies like how so many planes use the p51 instruments. fgadmin could run it's own rpm or deb database. Not sure how this would work on non-unix platforms, but I don't see any showstoppers. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgadmin missing files (was: Re: Aircraft Download/Install App)
On Saturday 26 November 2005 16:20, Melchior FRANZ wrote: * AJ MacLeod -- Saturday 26 November 2005 15:50: This hypothetical application sounds very much to me like an extension to the existing fgrun... ... and we could call it ... *pause* ... fgadmin! Speaking of which: Inspired by your message, I tried building fgadmin from within utils/fgadmin: utils/fgadmin ./autogen.sh Host info: Linux i686 automake: 1.9.5 (19) Running aclocal /usr/share/aclocal/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal /usr/share/aclocal/pstoedit.m4:7: warning: underquoted definition of AM_PATH_PSTOEDIT Running autoheader Running automake --add-missing Makefile.am: required file `./NEWS' not found Makefile.am: required file `./README' not found Makefile.am: required file `./AUTHORS' not found Makefile.am: required file `./ChangeLog' not found Running autoconf After creating these missing files everything build just fine. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Gear animation tutorial
Josh Babcock wrote: Vivian Meazza wrote: Josh Babcock I just made up a tutorial about making gear retraction animations run smoothly with complicated landing gears. It's still missing the final animation code, but I thought I'd throw it up to see what everybody thinks. It's got lots of in-line images, so be warned. I'm considering changing this to in-line thumbnails hotlinked to the full sized images. Please give feedback. http://jrbabcock.home.comcast.net/gear-tutorial/gear-tutorial.html Gosh, Josh, what an effort. Well done. Couple of points. First, I model the gear with the oleos extended, which helps with getting the compression right. Most drawings show the gear with the oleos at some intermediate compression. Some interpretation/intelligent guesswork is usually required. Second, sometimes the movement of jacks and draglinks etc. is too difficult to model well, so I cheat and hide them once they can no longer be seen readily (I do that anyway to save vertices). And one typo: separate. I'm impressed! Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Good point. I also do this, but because this model has knees (not sure what to call them) instead of oleos, I skipped it. Still, it should be extended to that it is below the ground in its resting pos. I will add this, and a section for dealing with gear-compression-norm and gear-compression-m. I'll also add a LOD section. The neat thing about this method is that it's so east to get everything in the right position, so you don't really need to hide it until you close the doors. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d OK, here's a new draft. I need to get a screenshot from FG, as well as the distance that the gear compresses, which is a bit of a problem right now. Putting in the rest of the code and the second missing image should happen today. It is now in the right place: http://jrbabcock.home.comcast.net/flightgear/gear-tutorial/gear-tutorial.html Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Airport of Hell?
fgfs --airport=EGLL --aircraft=ufo
...puts you in a mysterious place with thick fog, where ground level is
about 6 million m below sea level. This must be the airport of Hell.
While trying to investigate this, I found the following peculiar logic in
FDM/groundcache.cxx, line 364:
if (0 sgdScalarProductVec3( off, down ) || !found_ground) {
found_ground = true;
Which reads if ground is not found, then ground must be found. ?:-P
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft Download/Install App
And maybe it would also be a good idea to package aircraft and scenery in rpm or deb format. That way you don't have to worry about dependencies like how so many planes use the p51 instruments. fgadmin could run it's own rpm or deb database. Not sure how this would work on non-unix platforms, but I don't see any showstoppers. Josh At first I thought you were joking. But I guess it would work. ... and we could call it ... *pause* ... fgadmin! I tried fgadmin (just now actually) and couldn't figure out how to use it right away. Clicking Select All or Deselect All did nothing. Didn't even get a notice. The GUI is really bad I have to say. But as it seems to be a bad idea, I guess we can forget this thread. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport of Hell?
On Samstag 26 November 2005 19:47, Joacim Persson wrote:
fgfs --airport=EGLL --aircraft=ufo
...puts you in a mysterious place with thick fog, where ground level is
about 6 million m below sea level. This must be the airport of Hell.
While trying to investigate this, I found the following peculiar logic in
FDM/groundcache.cxx, line 364:
if (0 sgdScalarProductVec3( off, down ) || !found_ground) {
found_ground = true;
Which reads if ground is not found, then ground must be found. ?:-P
Well that must be logic from hell ...
Seriously, I can reproduce, I am currently investigating ...
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport of Hell?
On Samstag 26 November 2005 20:30, Mathias Fröhlich wrote:
On Samstag 26 November 2005 19:47, Joacim Persson wrote:
fgfs --airport=EGLL --aircraft=ufo
...puts you in a mysterious place with thick fog, where ground level is
about 6 million m below sea level. This must be the airport of Hell.
While trying to investigate this, I found the following peculiar logic in
FDM/groundcache.cxx, line 364:
if (0 sgdScalarProductVec3( off, down ) || !found_ground) {
found_ground = true;
Which reads if ground is not found, then ground must be found. ?:-P
Well that must be logic from hell ...
Seriously, I can reproduce, I am currently investigating ...
Hmm, was too fast, I had some changes because of your mail in this area. These
changes made me able to 'reproduce'.
That is:
I have no problem with this.
The logic you found strange makes indeed some sense. Even if one might find an
other solution to that too ...
That check is only made if the line from the aircraft intersects some triangle
in the scenegraph. The found_ground value is used together with that altitude
value computed at this point as a fallback value if the aircraft is not near
the ground so that we still have some ground elevation even if the small ball
around the aircraft does not contain ground triangles.
For initialization we need some ground level even if the initial altitude is
0ft like it is at the moment. That is: accept any ground level we can find
even if the aircraft is actually below.
So, since I do not see that problem:
Do you have any modifications in your local tree?
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] fg hanging
Looks like the latest CVS version of FG is hanging:
open(/usr/local/share/FlightGear/data/Navaids/carrier_nav.dat,
O_RDONLY) = -1 ENOENT (No such file or directory)
open(/usr/local/share/FlightGear/data/Navaids/carrier_nav.dat.gz,
O_RDONLY) = 9
fstat64(9, {st_mode=S_IFREG|0644, st_size=145, ...}) = 0
mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xab46d000
read(9, \37\213\10\10\277\206\205C\0\3carrier_nav.dat\00034RP\260...,
131072) = 145
read(9, , 131072) = 0
_llseek(9, 0, [145], SEEK_CUR) = 0
read(9, , 131072) = 0
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 3), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f39000
write(1, /usr/local/share/FlightGear/data...,
56/usr/local/share/FlightGear/data/Navaids/TACAN_freq.dat
) = 56
open(/usr/local/share/FlightGear/data/Navaids/TACAN_freq.dat,
O_RDONLY) = -1 ENOENT (No such file or directory)
open(/usr/local/share/FlightGear/data/Navaids/TACAN_freq.dat.gz,
O_RDONLY) = 10
fstat64(10, {st_mode=S_IFREG|0755, st_size=956, ...}) = 0
mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xab3eb000
read(10, [EMAIL PROTECTED]...,
131072) = 956
read(10, , 131072)= 0
_llseek(10, 0, [956], SEEK_CUR) = 0
read(10, , 131072)= 0
close(10) = 0
munmap(0xab3eb000, 131072) = 0
close(9)= 0
munmap(0xab46d000, 131072) = 0
close(8)= 0
munmap(0xab42c000, 131072) = 0
open(/usr/local/share/FlightGear/data/Navaids/fix.dat, O_RDONLY) = 8
fstat64(8, {st_mode=S_IFREG|0644, st_size=419280, ...}) = 0
mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xab46d000
read(8, 00MKK\n00UPP\n03MCT\n04BDT\n04THT\n06..., 131072) = 131072
_llseek(8, 0, [131072], SEEK_CUR) = 0
It just sits there at aroung 98-99% utilization. Doesn't respond to sig
11 except for this:
--- SIGTERM (Terminated) @ 0 (0) ---
rt_sigaction(SIGTERM, {0xb7eb3d10, [TERM], SA_RESTART}, {0xb7eb3d10,
[TERM], SA_RESTART}, 8) = 0
sigreturn() = ? (mask now [])
Anybody else seeing this?
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Airport of Hell?
* Mathias Fröhlich -- Saturday 26 November 2005 20:59: On Samstag 26 November 2005 19:47, Joacim Persson wrote: fgfs --airport=EGLL --aircraft=ufo So, since I do not see that problem: Do you have any modifications in your local tree? Doesn't work for me either. This works ... $ fgfs --aircraft=ufo --airport=EGLL --offset-distance=0.0134 and this doesn't: $ fgfs --aircraft=ufo --airport=EGLL --offset-distance=0.0133 only grey soup. And this point seems to be exactly the airport boundary. I'm just not aware of any recent changes that could have this effect. :-| m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport of Hell?
On Sat, 26 Nov 2005, Mathias Fröhlich wrote: Seriously, I can reproduce, I am currently investigating ... Hmm, was too fast, I had some changes because of your mail in this area. These changes made me able to 'reproduce'. That is: I have no problem with this. I have no idea if that line had something to do with it. It just looked odd to me. I then had a go with mutating it (|| to and !found_ground to found_ground), thinking it may be a typo, but the result was the same, so that particular line is probably not the problem, however odd it looks. ;). I suspect there is something wrong with the EGLL scenery file. If I take the ch47, I even get a sigsegv (down in yasim someplace, but it's being fed nonsense numbers from above). But only if I set Heathrow as --airport and only if I don't specify a runway. Inspecting EGLL in daylight setting, I saw some flickering triangles on runway 9R--27L, at five places, the largest one just by the landing line mark at the 9R end. Perhaps that has something to do with it? But even so, if EGLL has scenery bugs which causes this, FG should catch it and point it out. So, since I do not see that problem: Do you have any modifications in your local tree? None on the source tree that cvs reports about. The scenery I get with terrasync.___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 0.9.8 references non-existentplacementtrans.hxx
Thats Odd, I must have mixed something up... I worked 150 + hours over the past two weeks so I am a bit burnt. I will refresh my dev environment sometime in early December, that way I will use 0.9.9 after the first round of bugs. Thanks for your help. Paul -- Original Message -- From: Mathias Fr?ch [EMAIL PROTECTED] Reply-To: FlightGear developers discussions flightgear-devel@flightgear.org Date: Fri, 25 Nov 2005 21:06:56 +0100 Hi, On Freitag 25 November 2005 00:11, pmaclean wrote: Thank you for your reply. I am new to Flightgear so please bear with me. I am not sure how unref is applicable here. Sorry, I thought of reference counting in the scenegraph ... Also, I thought 0.9.8 was the latest release other than 0.9.9 which was released 8 days ago? The simgear site indicates that the latest csv is 0.3.9 and is paired with the 0.9.9 release of flightgear. Yes. But that simgear I have downloaded from ftp.de.flightgear.org to doublecheck includes that file. Greetings Mathias -- Mathias Fr?ch, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d __ Is your .com Auracom? Best access rates on the web http://exclusive.auracom.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Airport of Hell?
On Sat, 26 Nov 2005, Melchior FRANZ wrote: boundary. I'm just not aware of any recent changes that could have this effect. :-| Probably not a /new/ bug, rather an old one which hasn't propagated before. I've had problems with EGLL before. Night approach and fps drops to 7 or something. (not sure I can reproduce that now) Thought that was due to the fancy taxiways on it; that it was too much for my graphics card.. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FGSF Gear Animation
On Sat, 26 Nov 2005 05:18:01 -0600, you wrote: I just made up a tutorial about making gear retraction animations run smoothly with complicated landing gears. It's still missing the final Josh, thanks. I need to learn how to animate parts, so your tutorial is welcome. I am just starting out with Blender, moving my models out of GMAX (a chore). I've had to strip off my textures and animations moving to Blender and FlightGear from MSFS/GMAX. I just posted my experiences and some helpful material on the FlightGear wiki under 3D Modeling. They are not quite complete, but should be helpful to someone in my situation and will make a start on an exporting/importing guide. Please consider adding your tutorial to the wiki as well as the FG docs. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FGSF Gear Animation
Steve Knoblock wrote: On Sat, 26 Nov 2005 05:18:01 -0600, you wrote: I just made up a tutorial about making gear retraction animations run smoothly with complicated landing gears. It's still missing the final Josh, thanks. I need to learn how to animate parts, so your tutorial is welcome. I am just starting out with Blender, moving my models out of GMAX (a chore). I've had to strip off my textures and animations moving to Blender and FlightGear from MSFS/GMAX. I just posted my experiences and some helpful material on the FlightGear wiki under 3D Modeling. They are not quite complete, but should be helpful to someone in my situation and will make a start on an exporting/importing guide. Please consider adding your tutorial to the wiki as well as the FG docs. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d That's the intention. I have to complete it first, then I will put it up. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
I finally managed to compile Xorg from source today and managed to get more information from gdb. I have also filed a bug report with Xorg: https://bugs.freedesktop.org/show_bug.cgi?id=5142 Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
