developer will need to build and install these separately if they
don't have packages already installed by their system. See
README.metakit and README.zlib for more details.
As a convenience, pristine tarballs of the metakit and zlib source
code trees are included with the simgear distribution (and cvs.)
developer will need to build and install these separately if they don't
have packages already installed by their system. See README.metakit and
README.zlib for more details.
As a convenience, pristine tarballs of the metakit and zlib source code
trees are included with the simgear distribution (and cvs.)
- automake-1.4 sets default values for INCLUDES which we can't
overwrite.
- automake-1.5 renames this to DEFAULT_INCLUDES and leaves INCLUDES
open for the developer to use.
Thus for automake-1.4 we are forced to 'append' to INCLUDES and in
automake-1.5 we can just set the value to whatever we like.
Unfortunately, the behaviors of the two versions are mutually
incompatible.
The solution I am committing now works for both versions but
automake-1.5 generates a lot of spurious warning messages that are
annoying, but not fatal.
TRACE_READ - log a message whenever the property is read.
TRACE_WRITE - log a message whenever the property is written.
The second one works only when the property value is changed through
the property manager; tied variables and accessors are not polled for
value changes because of the performance hit.
These methods end up invoking private methods
SGPropertyNode::trace_read and SGPropertyNode::trace_write. By
setting breakpoints on these methods inside a debugger, it is possible
to debug property access and find what parts of a program are reading
or writing specific property values by doing a backtrace.
In the XML property files, users can use the attributes 'trace-read'
and 'trace-write' to control tracing; the value should be 'y' to
enable tracing or 'n' to disable it (the default).
model math blows up, the lat/lon could be nan. Thus updateLocal() could
potentially called with nan arguments if FlightGear is reiniting from a
blown up state. This is a bug in FlightGear, but I've added a simple
check to catch this so updateLocal() is robust if called under these
circumstances.
I can't find anything that addresses this in Stroustrup, but I also don't
see them doing this in any of their examples. So I have rewritten this
instance to use default arguments to accomplish the same thing. I imagine
there are other instances of this same sort of thing in other classes to
be fixed at a later date.
- changed return type of readXML from bool to void (uses an exception
to report problems now)
- removed XMLVisitor::error callback
- declared new readXML function that uses a path rather than a stream
- modified existing readXML function to take an optional path parameter
- implemented new readXML function with path instead of stream
- modified existing readXML function to use optional path parameter
- modified readXML to throw exceptions rather than returning a bool
value on error
file-name variant to invoke new readXML function
- readProperties and writeProperties will now throw exceptions if there
are file I/O problems
- replace error messages with exceptions
- tunnel sg_io_exception through from nested property read, since
the C-based Expat code cannot handle exceptions
