[Flightgear-devel] plib branch
We should now really think about making a plib branch for the data -- just named PLIB (no pointless date!). The old and unused plib branch (PRE_OSG_PLIB_20061029) could be removed. It doesn't contain anything useful. I guess it's safe to assume that no more plib based release will be made (except maybe a bugfix release with very few changes). m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] plib branch
* Stuart Buchanan -- Friday 18 January 2008: Of course, if we're not planning to make any further plib releases, then there is no need for a PLIB data branch :) . A plan is (only) a plan. We should keep the possibility to release a version 1.1 with the most annoying bugs of 1.0 fixed. Aircraft developers may want to maintain and improve 1.0-compatible versions of their aircraft for the lifetime of 1.0 and beyond. So a plib branch is mandatory. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug in native protocol was: simgear 1.0.0 crash
Hi all,
I think there is a bug when using the native protocol to link two instances of
FlightGear via network or when recording and playing back flights using
fgfs --native=file,out,20,fgfs.out
and
fgfs --native,file,in,20,fgfs.out --fdm=external
The external FlightGear crashes and after some investigation I think the
problem is a missing operator =() method in FDM/flight.hxx
The problem is:
In Network/native.cxx a buffer is read either from network of from a file
containing the previously written fdm state. The content of the buffer is
than assigned to the current fdm state by doing
*cur_fdm_state = buf;
both variables are of type FGInterface which currently lacks a operator =()
method, so the compiler uses a simple memcpy to copy one object to the other.
This is almost ok but for the ground_cache object. This is a complex object
containing a std::vectorFGGroundCache::Triangle. This vector seems to store
memory pointers to the Triangle-vertices. This is a very bad thing because
these pointers are invalid for any other FlightGear session and dereferencing
them causes a segmentation fault.
A very ugly - if not disgusting - workaround is adding the following to the
public methods of FGInterface in FDM/flight.hxx:
virtual const FGInterface operator = ( FGInterface src ) {
char * start = (char*)inited;
char * end = (char*)ground_cache;
memcpy( inited, src.inited, end-start );
prepare_ground_cache_m( 0, geodetic_position_v, 100.0 );
}
This gets called instead of a memcpy when assinging one FGInterface to another
and it does the memcpy for all member variables but the ground_cache. The
ground_cache itself is initialized for the recovered position with a fix
reference time of 0 and a radius of 100m.
At least this change fixes the segfault when replaying with the native
protocol, but I don't think this is the kind of code we want to see in
FlightGear for two reasons:
a) The pointer arithmetic assuming simple datatypes between the inited and
ground_cache variable
b) A constant used for reference time and the radius.
While a) may be circumnavigated by using explicit assignments for all
variables, I have no good idea for b). The radius might be saved when doing
the output, but I do not understand the idea of the reference time...
And there is one thing that is going round in my head: Curt reported, that he
does not have this problem at all and no one else (except tpalinkas) reported
this crash. Maybe this a a compiler/library problem?
Thanks for reading all that - any comment or help is appreciated.
Torsten
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] plib branch
--- Melchior FRANZ wrote: We should now really think about making a plib branch for the data -- just named PLIB (no pointless date!). The old and unused plib branch (PRE_OSG_PLIB_20061029) could be removed. It doesn't contain anything useful. I guess it's safe to assume that no more plib based release will be made (except maybe a bugfix release with very few changes). That sounds like a fine idea. Some of the random objects stuff I'm working on may require changes to the data tree that will be OSG-specific and probably not backwards-compatible with plib. Also, I have a generic G-force red/blackout feature (no more spheres over the pilot viewpoint!) available through the GUI, which again would be OSG-specific and have no effect on plib. Of course, if we're not planning to make any further plib releases, then there is no need for a PLIB data branch :) . However, I'd feel happier if we at least leave ourselves the option of a PLIB patch release, if required. -Stuart ___ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal error with YASim aircraft having 4 fuel tanks
On Fri, 18 Jan 2008 15:38:47 +0100 Melchior FRANZ wrote: * Chris Metzler -- Tuesday 08 January 2008: fgfs --aircraft=ufo is enough to give me the same } Nasal runtime error: props.setDoubleValue() with non-number } at /home/cmetzler/Projects/FlightGear-0.9/data//Nasal/props.nas, line 26 Can't reproduce that here, neither with fg/plib nor fg/osg. Well, I've since then done another CVS update/rebuild, and now I can't reproduce it either. Fixed? Do you still see it, Lee? -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear signature.asc Description: PGP signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] valgrind: diff no 1
hi all,
i've started to run fg through valgrind. i found this to be a nice option for
getting an overview over the code in flightgear.
i plan to prepare some patches to fix various issues reported by valgrind.
this is the first in (i hope) a series of several patches yet to follow. i
couldn't correct any serious issues so far (just small glitches and leaks).
when i get to know the code in flightgear a little better, there might be
more outcome.
this diff is against current cvs.
please apply and/or comment,
- till
Index: src/Autopilot/xmlauto.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Autopilot/xmlauto.cxx,v
retrieving revision 1.26
diff -u -3 -p -u -r1.26 xmlauto.cxx
--- src/Autopilot/xmlauto.cxx 9 Jul 2007 17:15:11 - 1.26
+++ src/Autopilot/xmlauto.cxx 18 Jan 2008 10:37:41 -
@@ -818,17 +818,13 @@ bool FGXMLAutopilot::build() {
string name = node-getName();
// cout name endl;
if ( name == pid-controller ) {
-FGXMLAutoComponent *c = new FGPIDController( node );
-components.push_back( c );
+components.push_back( new FGPIDController( node ) );
} else if ( name == pi-simple-controller ) {
-FGXMLAutoComponent *c = new FGPISimpleController( node );
-components.push_back( c );
+components.push_back( new FGPISimpleController( node ) );
} else if ( name == predict-simple ) {
-FGXMLAutoComponent *c = new FGPredictor( node );
-components.push_back( c );
+components.push_back( new FGPredictor( node ) );
} else if ( name == filter ) {
-FGXMLAutoComponent *c = new FGDigitalFilter( node );
-components.push_back( c );
+components.push_back( new FGDigitalFilter( node ) );
} else {
SG_LOG( SG_ALL, SG_ALERT, Unknown top level section:
name );
Index: src/Autopilot/xmlauto.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Autopilot/xmlauto.hxx,v
retrieving revision 1.14
diff -u -3 -p -u -r1.14 xmlauto.hxx
--- src/Autopilot/xmlauto.hxx 12 Jul 2006 15:11:47 - 1.14
+++ src/Autopilot/xmlauto.hxx 18 Jan 2008 10:37:41 -
@@ -52,7 +52,7 @@ SG_USING_STD(deque);
* Base class for other autopilot components
*/
-class FGXMLAutoComponent {
+class FGXMLAutoComponent : public SGReferenced {
protected:
@@ -275,7 +275,7 @@ public:
protected:
-typedef vectorFGXMLAutoComponent * comp_list;
+typedef vectorSGSharedPtrFGXMLAutoComponent comp_list;
private:
Index: src/GUI/dialog.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/GUI/dialog.cxx,v
retrieving revision 1.94
diff -u -3 -p -u -r1.94 dialog.cxx
--- src/GUI/dialog.cxx 3 Jul 2007 17:26:54 - 1.94
+++ src/GUI/dialog.cxx 18 Jan 2008 10:37:42 -
@@ -813,11 +813,11 @@ FGDialog::setColor(puObject * object, SG
if (type == textbox props-getBoolValue(editable))
type += -editable;
-FGColor *c = new FGColor(_gui-getColor(background));
-c-merge(_gui-getColor(type));
-c-merge(props-getNode(color));
-if (c-isValid())
-object-setColourScheme(c-red(), c-green(), c-blue(), c-alpha());
+FGColor c(_gui-getColor(background));
+c.merge(_gui-getColor(type));
+c.merge(props-getNode(color));
+if (c.isValid())
+object-setColourScheme(c.red(), c.green(), c.blue(), c.alpha());
const struct {
int mask;
@@ -840,20 +840,20 @@ FGDialog::setColor(puObject * object, SG
for (int i = 0; i numcol; i++) {
bool dirty = false;
-c-clear();
-c-setAlpha(1.0);
+c.clear();
+c.setAlpha(1.0);
-dirty |= c-merge(_gui-getColor(type + '-' + pucol[i].name));
+dirty |= c.merge(_gui-getColor(type + '-' + pucol[i].name));
if (which pucol[i].mask)
-dirty |= c-merge(props-getNode(color));
+dirty |= c.merge(props-getNode(color));
-if ((pucol[i].mask == LABEL) !c-isValid())
-dirty |= c-merge(_gui-getColor(label));
+if ((pucol[i].mask == LABEL) !c.isValid())
+dirty |= c.merge(_gui-getColor(label));
-dirty |= c-merge(props-getNode(pucol[i].cname));
+dirty |= c.merge(props-getNode(pucol[i].cname));
-if (c-isValid() dirty)
-object-setColor(pucol[i].id, c-red(), c-green(), c-blue(), c-alpha());
+if (c.isValid() dirty)
+object-setColor(pucol[i].id, c.red(), c.green(), c.blue(), c.alpha());
}
}
Index: src/Input/input.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Input/input.cxx,v
retrieving revision 1.99
diff -u -3 -p -u -r1.99 input.cxx
--- src/Input/input.cxx 1 Dec 2007 23:37:58 -
Re: [Flightgear-devel] valgrind: diff no 1
On 01/18/2008 09:05 AM, till busch wrote: i've started to run fg through valgrind. i found this to be a nice option for getting an overview over the code in flightgear. 1) This is important, valuable, and overdue. 2) It's going to be a lot of work. That's because 2a) Although it is easy to write valgrind-clean code, once somebody has written unclean code it is not necessarily easy to clean it up. 2b) Although some of the FGFS code is exemplary c++ code, some of it is not. Some of it is what we call c-- code compiled with the c++ compiler. The point is is, c++ is a different language from c--, and unfortunately some of FGFS code exhibits a deep non-understanding of the purpose and capabilities of the c++ language. This is related to the recent discussion (in another thread) of memory management. C++ is perfectly capable of automatic memory management, if allowed to do so. Sure, c++ gives folks enough rope to hang themselves (in contrast to e.g. java, which gives them less rope) but c++ does not /require/ anyone to hang themselves. As a simple guideline, with few exceptions, one should put new and delete in constructors and destructors, and then let the automatic memory management do its thing. Yeah, I know this is more work than manually newing and deleting things, but it makes the code vastly more reliable, more maintainable, more readable, more reusable, and more extensible. There's waaay too much c-- style manual memory management in FGFS, for no good reason ... and waaay too many memory leaks. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal error with YASim aircraft having 4 fuel tanks
* Chris Metzler -- Tuesday 08 January 2008: fgfs --aircraft=ufo is enough to give me the same } Nasal runtime error: props.setDoubleValue() with non-number } at /home/cmetzler/Projects/FlightGear-0.9/data//Nasal/props.nas, line 26 Can't reproduce that here, neither with fg/plib nor fg/osg. Of course, fgfs shouldn't create tanks. I'd consider that a bug. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal error with YASim aircraft having 4 fuel tanks
On Friday 18 January 2008 16:49, Chris Metzler wrote: On Fri, 18 Jan 2008 15:38:47 +0100 Melchior FRANZ wrote: * Chris Metzler -- Tuesday 08 January 2008: fgfs --aircraft=ufo is enough to give me the same } Nasal runtime error: props.setDoubleValue() with non-number } at /home/cmetzler/Projects/FlightGear-0.9/data//Nasal/props.nas, line 26 Can't reproduce that here, neither with fg/plib nor fg/osg. Well, I've since then done another CVS update/rebuild, and now I can't reproduce it either. Fixed? Do you still see it, Lee? -c I didn't look to see if I got the problem here with the ufo and because I _needed_ to check the cog with different fuel loads I just added a dummy tank to get around the problem until it's fixed. Incidentally, I didn't set up an index to the dummy tank entry and the dummy tank doesn't appear in the fuel dialogue, which works ok, but just shows the three real tanks. I'll update from cvs now but I'll be out later and won't be able to test it until tomorrow sometime - I'll confirm whether it still happens with YASim aircraft with 4 tanks then. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug#461399: simgear_1.0.0-1 (alpha/unstable): FTBFS: Unrecognized CPU architecture
Hi FlightGear developers. It looks like there are some portability issues in the current code... I got this report on the Debian packages. I could patch the missing ifdefs I guess (though it'd be nice if you fixed them for a future release), but could you comment on the 64-bit issue? Steve Langasek skrev: Package: simgear Version: 1.0.0-1 Severity: serious simgear is now failing to build on alpha, hppa, and s390 with the following error: if gcc -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -fPIC -pipe -g -O2 -D_REENTRANT -MT bitslib.o -MD -MP -MF .deps/bitslib.Tpo -c -o bitslib.o bitslib.c; \ then mv -f .deps/bitslib.Tpo .deps/bitslib.Po; else rm -f .deps/bitslib.Tpo; exit 1; fi In file included from nasal.h:7, from data.h:4, from bitslib.c:2: naref.h:20:3: error: #error Unrecognized CPU architecture [...] A full build log can be found at http://buildd.debian.org/fetch.cgi?pkg=simgeararch=alphaver=1.0.0-1stamp=1198415406file=logas=raw. The reason for this is the following code in naref.h: /* Rather than play elaborate and complicated games with * platform-dependent endianness headers, just detect the platforms we * support. This list is simpler and smaller, yet still quite * complete. */ #if (defined(__x86_64) defined(__linux__)) || defined(__sparcv9) || \ defined(__powerpc64__) /* Win64 and Irix should work with this too, but have not been * tested */ # define NASAL_NAN64 #elif defined(_M_IX86) || defined(i386)|| defined(__x86_64) || \ defined(__ia64__) || defined(_M_IA64) || defined(__ARMEL__) # define NASAL_LE #elif defined(__sparc) || defined(__ppc__) ||defined(__PPC) || \ defined(__mips) || defined(__ARMEB__) # define NASAL_BE #else # error Unrecognized CPU architecture #endif ... which is a cop-out, and a serious regression because the old code built and ran fine on all architectures. The above code should have __alpha__ added to the NASAL_LE list, and __hppa__, __s390__, and __s390x__ added to the NASAL_BE list. BTW, according to data.h, the NASAL_NAN64 option exists to support stupid union tricks: // On 64 bit systems, Nasal non-numeric references are stored with a // bitmask that sets the top 16 bits. As a double, this is a // signalling NaN that cannot itself be produced by normal numerics // code. The pointer value can be reconstructed if (and only if) we // are guaranteed that all memory that can be pointed to by a naRef // (i.e. all memory returned by naAlloc) lives in the bottom 48 bits // of memory. Linux on x86_64, Win64, Solaris and Irix all have such // policies with address spaces: [...] Linux doesn't document this rigorously, but testing // shows that it allows 47 bits of address space (and current x86_64 // implementations are limited to 48 bits of virtual space anyway). So // we choose 48 as the conservative compromise. So this assumes the kernel will never expose more than 48bits of address space to userspace processes -- a short-sighted and groundless assumption, the reason Linux hasn't documented this rigorously is because there is no such guarantee. The NASAL_NAN64 option should be thrown out for all Linux variants. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug#461399: simgear_1.0.0-1 (alpha/unstable): FTBFS: Unrecognized CPU architecture
Ove Kaaven wrote: It looks like there are some portability issues in the current code... On three platforms which don't have the CPU power (or GPU support!) to actually, y'know, run the software. :) Steve Langasek wrote: So this assumes the kernel will never expose more than 48bits of address space to userspace processes -- a short-sighted and groundless assumption, the reason Linux hasn't documented this rigorously is because there is no such guarantee. The NASAL_NAN64 option should be thrown out for all Linux variants. This is in the Nasal interpreter. Language interpreters routinely enjoy making some platform assumptions in the name of performance. In this case, that union trick chops the size of a naRef (and therefore the memory footprint of almost everything Nasal does) in half. I'm more than prepared to pay for this benefit in the form of the occasional dispeptic rant from uninformed distribution folks who are more interested in wagging their fingers at developers than they are in actually running the software [How's that for tone, Steve? I can flame with the best of them if you really want to throw down. Try a little less presumption next time.] As explained very clearly in the comments, all known platforms support this code just fine, and the benefits are very large. And I'm even conservative about refusing to compile on platforms on which I can't test, thus the #error (it's a feature, not a bug!). I'm happy to take patches, though. This support is trivially really easy to add, if Mr. Langasek is actually willing to help out a little. Just the output of echo | gcc -dM -E - on each of the platforms is sufficient. ... which is a cop-out, and a serious regression because the old code built and ran fine on all architectures. On all *debian* architectures. I had a ton of trouble getting the original stuff to work for everyone who wanted to use it. Manually enumerating architectures was the overwhelmingly simpler choice. I'm sorry you disagree. Andy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] configure/make/run on MacOS X
Hi all, is anyone successfully building and running fgfs under MacOS X using configure? It compiles and runs the splash screen and setups but then crashes applying a texture (don't know which). I'd just like to make sure it's actually a compilation problem and not some missing texture file. fgfs is awfully quiet, is there a way to enable debug output other than OSG_NOTIFY_LEVEL? I'm aware of the efforts using Xcode but I'm just more comfortable with 'configure' and a shell (call me a command line animal). Thanks, /uli - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
