[Csp-commits] APPLICATIONS/SimData CHANGES.current,1.62,1.63 Makefile,1.16,1.17 README,1.6,1.7 TODO,1.5,1.6

[<mk...@us...>]

Update of /cvsroot/csp/APPLICATIONS/SimData
In directory sc8-pr-cvs1:/tmp/cvs-serv26895

Modified Files:
	CHANGES.current Makefile README TODO 
Log Message:


Index: CHANGES.current
===================================================================
RCS file: /cvsroot/csp/APPLICATIONS/SimData/CHANGES.current,v
retrieving revision 1.62
retrieving revision 1.63
diff -C2 -d -r1.62 -r1.63
*** CHANGES.current	7 Aug 2003 18:05:35 -0000	1.62
--- CHANGES.current	14 Aug 2003 12:19:12 -0000	1.63
***************
*** 2,5 ****
--- 2,65 ----
  ===========================
  
+ 2003-08-13: onsight
+             Complete rewrite of the Enumeration classes, using Enum
+ 	    templates, simdata::Ref, and an overall better design.  The
+ 	    new code allows the parent Enumerations to be bound to 
+ 	    member variable *types* duing static construction, so that
+ 	    the possible values for a type can be querried without
+ 	    instantiating the parent class.  This is very useful for
+ 	    introspecting classes, allowing a SimData XML editor to
+ 	    determine a list of possible values for an Enum directly
+ 	    from an ObjectInterface without creating an instance of
+ 	    the corresponding class.  The Python bindings for the
+ 	    Enum classes have also been redesigned and improved.
+ 
+ 	    Changed some DataArchive and hash methods to use
+ 	    std::string const& instead of const char*.
+ 
+ 	    Fixed some bugs in Date.h and Matrix.h that '-pedantic'
+ 	    uncovered.  Added more base class ctor calls to satisfy
+ 	    '-pedantic' as well.
+ 
+ 	    Added isSubclass() method to ObjectInterface (and the
+ 	    InterfaceProxy clases) to test the inherintance chain
+ 	    using interfaces without creating object instances.  The
+ 	    class relationships used in the test are based on the
+ 	    classes listed in the SIMDATA_XML_INTERFACE() macros, not
+ 	    the full C++ class hierarchy.
+ 
+ 	    Added SIMDATA_SUBEXCEPTION macro for creating exception
+ 	    hierarchies.
+ 
+ 	    Changed the default version string to report the build 
+ 	    date and time, which provides a helpful sanity check when
+ 	    more than one version of the SimData is in your library 
+ 	    search path.
+ 
+ 2003-08-10: onsight
+             Minor fixes/pragmas to reduce useless warning messages under
+ 	    VS 2003.
+ 
+ 	    Added support to the object registry, object interfaces,
+ 	    and member accessors for member variable type introspection.
+ 	    BaseTypes other than Object must now override typeString()
+ 	    to return a string identifier for their type (which should
+ 	    start with "type::").  Other prefix convensions are as
+ 	    follows:
+ 	      * Type strings for builtin types (like 'float') start with 
+ 	        'builtin::'.  See ObjectInterface.h for a complete list.
+               * Type strings for BaseTypes other than Object start with 
+ 	        'type::', followed by the name of the type (e.g. Date).
+ 	      * Type strings for Objects are just the classname of the 
+ 	        object.  
+ 	      * Type strings for std::vectors start with 'vector::'.  
+ 	      * Type strings for templated classes are followed by the 
+ 	        template type (e.g. type::Link::SomeObjectClass).
+ 
+ 	    Added object interface lookup based on object id to DataArchive
+ 	    and DataManager.  Given an object ID (or path) you can now
+ 	    determine the object class and introspect the member variables
+ 	    without creating an instance of the object.
+ 
  2003-08-07: onsight
              Added SIMDATA_EXPORT to classes in Random.h

Index: Makefile
===================================================================
RCS file: /cvsroot/csp/APPLICATIONS/SimData/Makefile,v
retrieving revision 1.16
retrieving revision 1.17
diff -C2 -d -r1.16 -r1.17
*** Makefile	6 Aug 2003 06:36:24 -0000	1.16
--- Makefile	14 Aug 2003 12:19:12 -0000	1.17
***************
*** 3,11 ****
  export PYTHON_INCLUDE := $(shell python setup.py python_include_path)
  
! export GDEBUGF = -g -Wall
! export GCFLAGS = -fPIC -O2 -pedantic# -march=athlon-tbird
  export GLDOPTS = -shared -lswigpy -ldl
  export GSWOPTS = -c -c++ -python -noexcept
! export CXX = g++-3.3
  export SWIG = swig 
  
--- 3,11 ----
  export PYTHON_INCLUDE := $(shell python setup.py python_include_path)
  
! export GDEBUGF = -g -W -Wall -Werror -pedantic
! export GCFLAGS = -fPIC -O2 # -march=athlon-tbird
  export GLDOPTS = -shared -lswigpy -ldl
  export GSWOPTS = -c -c++ -python -noexcept
! export CXX = g++
  export SWIG = swig 
  

Index: README
===================================================================
RCS file: /cvsroot/csp/APPLICATIONS/SimData/README,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** README	26 Jul 2003 19:44:26 -0000	1.6
--- README	14 Aug 2003 12:19:12 -0000	1.7
***************
*** 1,5 ****
  SimData - A library for efficient use of data XML in simulations.
  
! Release 0.3.2
  
  Copyright (C) 2002, 2003 Mark Rose <mr...@st...>
--- 1,5 ----
  SimData - A library for efficient use of data XML in simulations.
  
! Release 0.3.4
  
  Copyright (C) 2002, 2003 Mark Rose <mr...@st...>
***************
*** 7,18 ****
  See COPYING for details.
  
  ----------------------------------------------------------------------
  
  CAVEATS
  
! This library is ALPHA! Do not expect it to be polished in any way. It
! does work, at least under the proper conditions, which is why it has
! been released. Only through testing and use will it evolve into a robust
! and stable platform for utilizing XML data in simulations.
  
  SimData is written primarily for the Combat Simulator Project (CSP)
--- 7,20 ----
  See COPYING for details.
  
+ For documentation, updates, and information, visit the SimData wiki 
+ pages at http://csp.sourceforge.net/wiki/SimData
+ 
  ----------------------------------------------------------------------
  
  CAVEATS
  
! This library is BETA!  Do not expect it to be completely polished.
! Only through testing and use will it evolve into a robust and stable 
! platform for utilizing XML data in simulations.
  
  SimData is written primarily for the Combat Simulator Project (CSP)
***************
*** 22,31 ****
  
  SimData was initially developed under Linux using GCC 2.95 and 3.0.
! Current development occurs mainly under GCC 3.2. GCC 3.3 has also been
! tested and will soon become the primary development platform. The
! library also receives routine testing under MS VC6 and now .NET as part
! of the Combat Simulator Project. If you encounter problems, please
! report them (with patches if possible) to the CSP developer's forum at
! http://csp.sourceforge.net/forum.
  
  
--- 24,34 ----
  
  SimData was initially developed under Linux using GCC 2.95 and 3.0.
! Current development occurs mainly under GCC 3.3, although support for
! GCC 3.2 is still actively maintained.  The library also receives routine 
! testing under MS Visual Studio .NET 2003 as part of the Combat Simulator 
! Project.  Earlier versions of VS and MSVC are no longer supported. 
! 
! If you encounter problems, please report them (with patches if possible) 
! to the CSP developer's forum at http://csp.sourceforge.net/forum.
  
  
***************
*** 42,46 ****
  Linux are available from http://www.python.org.  Python version 2.2 or
  newer is required.  Under Windows, be sure to add the Python path to 
! your global path so that VC can find it.
  
  If you are using MS VC6 you will also need have at least SP5 installed
--- 45,49 ----
  Linux are available from http://www.python.org.  Python version 2.2 or
  newer is required.  Under Windows, be sure to add the Python path to 
! your global path so that Visual Studio can find it.
  
  If you are using MS VC6 you will also need have at least SP5 installed
***************
*** 106,115 ****
  
  
- As a quick test, change to the Source directory and run Python. Try
- typing "import SimData". You should see a line similar to "loaded @
- 0x4883012". If not, something went wrong... post to the CSP developer's
- forum and we can try to find the problem.
- 
- 
  INSTALLING AND USING SIMDATA
  
--- 109,112 ----
***************
*** 121,127 ****
  accomplish the same thing with 'python setup.py install'.
  
! Under Windows, run 'python setup.py make_install_win'.  Under XP
! you may need to have sufficient priviledges to write to the Python
! directories.
  
  To use the SimData headers for development, just add the usual Python
--- 118,124 ----
  accomplish the same thing with 'python setup.py install'.
  
! Under Windows, run 'python setup.py make_install_win'.  If you
! are running Windows XP you may need to have sufficient priviledges to 
! write to the Python directories.
  
  To use the SimData headers for development, just add the usual Python

Index: TODO
===================================================================
RCS file: /cvsroot/csp/APPLICATIONS/SimData/TODO,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** TODO	26 Jul 2003 19:44:26 -0000	1.5
--- TODO	14 Aug 2003 12:19:12 -0000	1.6
***************
*** 1,48 ****
  THE BIG PICTURE
! ----------------------------------------------------------------
  
! This version is incomplete in the sense of being ALPHA,
! but also in a more fundamental sense.
  
! The original concept for SimData relied on Python/SWIG
! (with special support for cross-language polymorphism) to 
! provide an interface for dynamically setting class member 
! variables as indicated by the source XML stream.  While 
! this approach worked, it forced the application using 
! SimData to wrap all classes that loaded external data 
! with SWIG.
  
! Somewhere (well) along the way, I thought of a less intrusive
! way to allow SimData to access class member variables in
! the target application.  The application still must define
! a minimal Python module in order to initialize the class
! interfaces, but this is much less onerous than the previous
! approach.  The downside is this new method relies on nested
! classes to provide XML interfaces.  Since SWIG does not
! currently support nested classes, it is no longer possible 
! to extend XML interfaces of application classes using 
! Python.  Also, much of the Python code found in SimData.py 
! which was intended to assist in such extension is now 
! obsolete.  Once a future version of SWIG supports nested 
! classes (which appears to be a priority for SWIG's developers), 
! new Python code will need to be written to replace much of 
! what is now in SimData.py.
  
! Recently (April 2003) I've been considering Boost::Python
! bindings as well.  Boost supports nested classes and poly-
! morphism, but requires more hands-on wrapping.  A new
! project called Pyste promises to provide much more automated
! wrapping capabilities to Boost, using an interface design
! that is very similar to SWIG.  This is still a bit too
! immature for use in SimData, but it may be a viable option
! before long.
  
  
  OTHER 
! ----------------------------------------------------------------
  
      * Improve the build on Linux and Windows.  This has already
        gotten considerably better, but there's always more work
        to do.
  
      * Eliminate unnecessary inline code from headers.
--- 1,51 ----
  THE BIG PICTURE
! -----------------------------------------------------------------------
  
! This version is incomplete in the sense of being BETA, but also in a
! more fundamental sense.
  
! The original concept for SimData relied on Python/SWIG (with special
! support for cross-language polymorphism) to provide an interface for
! dynamically setting class member variables as indicated by the source
! XML stream. While this approach worked, it forced the application using
! SimData to wrap all classes that loaded external data with SWIG.
  
! Somewhere (well) along the way, I thought of a less intrusive way to
! allow SimData to access class member variables in the target
! application. The application still must define a minimal Python module
! in order to initialize the class interfaces, but this is much less
! onerous than the previous approach. The downside is this new method
! relies on nested classes to provide XML interfaces. Since SWIG does not
! currently support nested classes, it is no longer possible to extend XML
! interfaces of application classes using Python. Also, much of the Python
! code developed to assist in such extension is now obsolete. Once a 
! future version of SWIG supports nested classes (which appears to be a 
! priority for SWIG's developers), new Python code will need to be written 
! to bridge the object interface and registry code into Python.
  
! Another option I've been considering is using Boost::Python to provide
! bindings. Boost supports nested classes and polymorphism, but requires
! more hands-on wrapping. A new project called Pyste promises to provide
! much more automated wrapping capabilities to Boost, using an interface
! design that is very similar to SWIG. This is still a bit too immature
! for use in SimData, but it may be a viable option before long.  On the
! downside, tests I've made with Boost generated wrappers that were as 
! much as 10 times larger than the SWIG equivalents.
  
  
  OTHER 
! -----------------------------------------------------------------------
  
      * Improve the build on Linux and Windows.  This has already
        gotten considerably better, but there's always more work
        to do.
+ 
+     * Refine and extend the data classes; improve the Python bindings
+ 
+     * Add examples to the doxygen file comments for each type class.
+ 
+     * Add doxygen comments to uncommented methods
+ 
+     * Improve the SimData wiki documentation
  
      * Eliminate unnecessary inline code from headers.