doc/additionalDoc/doc-debug-real-time-logger.h

+/**
+\page subp_debug_rt_logger Real-time Logger
+
+ \section real_time_logger_quick_intro Quick introduction
+ Each entity has a protected logger_ object.
+ The simplest way to have information while running your graph is to initialize
+ it in the constructor, and then display information in the methods.
+
+ You can then change the level of information you want to display using
+ either the entity method setLoggerVerbosityLevel()
+ or the corresponding python bindings.
+
+ \section real_time_logger_modifying_entities Putting information in your
+entity.
+
+ It is possible to define the periodicity of the logger:
+ \code
+ logger_.setTimeSample(0.001);
+ \endcode
+
+ To define the periodicity at which one wants to print information:
+ \code
+ logger_.setStreamPrintPeriod(0.005);
+ \endcode
+
+ Several level of verbosity are possible:
+ \code
+ logger_.setVerbosity(VERBOSITY_ALL);
+ \endcode
+ The full list of options are:
+<ul>
+<li>VERBOSITY_ALL: Accept all messages</li>
+<li>VERBOSITY_INFO_WARNING_ERROR: Accept messages at minimum level : INFO,
+WARNING, ERROR</li> <li>VERBOSITY_WARNING_ERROR: Accept messages at minimum
+level : WARNING, ERROR</li> <li>VERBOSITY_ERROR: Accept messages at minimum
+level : ERROR</li>
+</ul>
+
+It is specified by the enum LoggerVerbosity
+
+ It is possible to display information according to various level of debug:
+ \code
+ sendMsg("This is a message of level MSG_TYPE_DEBUG", MSG_TYPE_DEBUG);
+ \endcode
+ or
+ \code
+ DYNAMIC_GRAPH_ENTITY_DEBUG   (*this) << "This is a message of level
+MSG_TYPE_DEBUG\n"; DYNAMIC_GRAPH_ENTITY_INFO    (*this) << "This is a message of
+level MSG_TYPE_INFO\n"; DYNAMIC_GRAPH_ENTITY_WARNING (*this) << "This is a
+message of level MSG_TYPE_WARNING\n"; DYNAMIC_GRAPH_ENTITY_ERROR   (*this) <<
+"This is a message of level MSG_TYPE_ERROR\n"; DYNAMIC_GRAPH_ENTITY_DEBUG_STREAM
+(*this) << "This is a message of level MSG_TYPE_DEBUG_STREAM\n";
+ DYNAMIC_GRAPH_ENTITY_INFO_STREAM    (*this) << "This is a message of level
+MSG_TYPE_INFO_STREAM\n"; DYNAMIC_GRAPH_ENTITY_WARNING_STREAM (*this) << "This is
+a message of level MSG_TYPE_WARNING_STREAM\n"; DYNAMIC_GRAPH_ENTITY_ERROR_STREAM
+(*this) << "This is a message of level MSG_TYPE_ERROR_STREAM\n"; \endcode
+
+
+   \note Thread safety. This class expects to have:
+   - only one reader: the one who take the log entries and write them somewhere.
+   - one writer at a time. Writing to the logs is **never** a blocking
+     operation. If the resource is busy, the log entry is discarded.
+*/

doc/additionalDoc/entity.h

+/**
+\page subpage_entities Entities
+
+\section section_entities Entities
+\subsection entity_definition General definition
+\image html entity.png
+
+Despite the fact that it looks very similar to a ROS node or a CORBA/OpenRTM
+server, an entity is simply a C++ object. The main idea is that this entity is
+providing mostly a data-driven functionnality working at very high rate (\f$ 200
+Hz\f$ or \f$ 1 kHz \f$) and should have a minimal computational time foot-print.
+
+For this \subpage subp_signals (or ports to use a more classical terminology)
+are providing a time dependency between data. To implement this, an output
+signal is linked with a method of the entity. The method calls input signals or
+use other means to get the needed data. It might be provided by the connection
+with remote computers through a middleware, or specific protocols, but in
+general the external data is based upon the sensor values provided by a "Device"
+entity. For this reason the signal evaluations are realized through the cascade
+of dependencies and start from the evaluation of an input signal of a periodic
+node (in general the device). This is realized inside a \b real-time thread.
+
+To add flexibility to a node, it is possible to add command with arguments to
+modify the internal behavior of the entity or get information from the entity.
+As a command is in general asynchronous and rare with respect to the data-flow
+scheme for the signals the command is in general executed in a \b none-real-time
+thread. For more details on command see \subpage subpage_command .
+
+\subsection entity_classes Entity class
+Entities are implemented as C++ classes and compiled as dynamic libraries. They
+can be loaded and instancied dynamically. It is therefore necessary to specify
+the location of their dynamical libraries. However given the time it might take
+to load the library, it is not advised to do that during a control-law
+computation. Entity instanciation also implies memory allocation which is also
+time consuming and thus not advised inside a real-time thread.
+
+The entities will be placed in ${PREFIX}/lib/dynamic-graph-plugin
+(since this may change, it is advised to check the install log or the
+CMakeLists.txt file to check the installation path).
+
+\subsection entities List of entities in this package
+Since most of the functionality in projects using the dynamic-graph framework
+is exposed from entities, here is a short description of all the entities
+contained in this package. Note that most entities are contained in a binary
+file that closely matches the entities' names in the scripts; loading this file
+with the plugin loader will enable creation of this entity through the factory.
+\li \ref tracerdoc
+\li \ref tracerrealtimedoc
+
+\subsection specific_semantics Specific semantics with entities
+
+It is possible to derive classes and apply specific semantic for the entities.
+In our case we are interested in specific control semantics: \li Tasks (more
+information <a
+href="http://stack-of-tasks.github.io/sot-core/doxygen/HEAD/a00089.html">here</a>)
+\li Features (more information <a
+href="http://stack-of-tasks.github.io/sot-core/doxygen/HEAD/a00030.html">here</a>)
+\li Solver (more information <a
+href="http://stack-of-tasks.github.io/sot-core/doxygen/HEAD/a00078.html">here</a>)
+
+*/

doc/additionalDoc/extension.h

+/**
+\page subp_how_to_use Using this package
+
+\section usecase How to use this package
+
+\subsection use_programmatically General introduction
+
+For control purposes the main use of this package is to create new entities and
+connect them through signals.
+
+Objects, which are derived from Entities (base class dynamicgraph::Entity), can
+be declared within the code and compiled as shared libraries (.so/.dll files).
+These libraries can be loaded at run-time using the PluginLoader methods,
+and at the same time register their class names to the Factory (see the
+examples in the <a
+href="http://projects.laas.fr/gepetto/doc/stack-of-tasks/sot-core/master/doxygen-html">sot-core
+documentation</a> for advanced control examples).
+
+The Factory can then create instances of these objects and subsequently
+register them in the Pool. From the pool they can be listed, accessed, and acted
+upon (see PoolStorage documentation). Basic commands defined by entities include
+signal connection graph file generation, help and name print, and signals.
+This is usually done through a scripting language such as python (see
+<a
+hef="https://github.com/stack-of-tasks/dynamic-graph-python">dynamic-graph-python</a>)
+
+The singletons made available by including the corresponding headers in this
+module are:
+\li dynamicgraph::FactoryStorage
+\li dynamicgraph::PoolStorage
+
+For an example of a program creating entities in C++, see the unit test
+test_pool.cpp (in your package source directory/tests).
+
+\subsection Tutorial
+A tutorial is available <a
+href="http://stack-of-tasks.github.io/dynamic-graph-tutorial/">here</a>. It is
+providing a step-by-step way of building an entity
+
+\section sec_htw_helpers Helpers
+
+
+When writing entities you might use some macros which are very useful to write
+your class.
+
+\subsection subsec_howto_typedef Entity helpers
+
+The header <b>entity-helper.h</b> is defining a type called EntityClassName
+
+\section sec_howto_macros_helpers Macro helpers
+
+\subsection subsec_howto_macros_helpers_ent Preprocessing macros for entities
+
+<ul>
+  <li> <b>DYNAMIC_GRAPH_ENTITY_DECL()</b>:
+  This macro creates a method <b>getClassName()</b> which returns the class
+name.</li> This macro <b>should</b> be used in the declaration of the class.
+  </li>
+  <li> <b>DYNAMICGRAPH_FACTORY_ENTITY_PLUGIN(classtype,classname)</b>
+  This macros creates the methods necessary to have a factory building the C++
+class <b>classtype</b> from the string <b>classname</b>. This macro
+<b>should</b> be used in the implementation of the class.
+  </li>
+</ul>
+
+\subsection subsec_howto_macros_helpers_sig Preprocessing macros for signals
+
+<ul>
+  <li>  Macro for input signals
+    <ul>
+      <li> <b>DECLARE_SIGNAL_IN(signal_name,type)</b>:
+      Declare an input time dependent signal as a field of the class with the
+following name: \code m_signal_nameSIN \endcode
+      </li>
+      <li> <b>CONSTRUCT_SIGNAL_IN(signal_name,type)</b>:
+      This macro is used in the constructor of the entity class handling this
+signal. It is calling the signal constructor and set the signal name to: \code
+      EntityClassName(entity-name)::input(type)::signal_name
+      \endcode
+    </ul>
+  </li>
+  <li>  Macro for output signals
+    <ul>
+      <li> <b>DECLARE_SIGNAL_OUT(signal_name,type)</b>:
+      Declare an output time dependent signal as a field of the class with the
+following name: \code m_signal_nameSOUT \endcode It also declares a method with
+the following pattern: \code type signal_nameSOUT_function(type &,int) \endcode
+      The second pattern is the time when calling the output.
+      </li>
+      <li> <b>CONSTRUCT_SIGNAL_OUT(signal_name,type)</b>
+      This macro is used in the constructor of the entity class handling this
+signal. It creates the binding to the method described previously, and set the
+signal name to: \code EntityClassName(entity_name)::output(type)::signal_name
+      \endcode
+      where entity_name is the name of the entity currently instanciated.
+      </li>
+
+      <li> <b>DEFINE_SIGNAL_OUT_FUNCTION(signal_name, type)</b>:
+      This macro is used when implementing the method specific to the output
+signal. It is used in the main body of the entity class to declare the header of
+the method with the following pattern: \code type
+EntityClassName::signal_nameSOUT_function(type &, int iter) \endcode
+      </li>
+
+    </ul>
+  <li>
+  </li> Inner signals
+    <ul>
+      <li> <b> DECLARE_SIGNAL_INNER(signal_name,type)</b>
+      Inner signal are signal that depend on a state of the entity and not on
+input signals. This macro declares an inner signal with the following pattern:
+      \code
+      m_signal_nameSINNER
+      \endcode
+      It also creates a member function with the following pattern:
+      \code
+      type & EntityClassName::nameSINNER_function(signal_name)(type &, int)
+      \endcode
+      </li>
+      <li> <b>DEFINE_SIGNAL_INNER_FUNCTION(signal_name,type)</b>
+      This macro is used to implement the method related to signal_name. More
+precisely it provides the header of the member function(i.e. method)
+declaration.
+      </li>
+      <li><b>DECLARE_SIGNAL_INNER_FUNCTION(signal_name,type)</b>
+      This macros declares the member function used to handle the access to this
+signal.
+      </li>
+    </ul>
+</ul>
+
+*/

doc/additionalDoc/factory.h

+/**
+\page subp_factory Factory
+\section sec_factory Factory
+
+The class \ref dynamicgraph::FactoryStorage is a singleton which register the
+entity classes and which is allowing the instancation of such classes.
+*/

doc/additionalDoc/graph.h

+/**
+\page p_graph Graph
+
+
+In this package, the graph considered are directed graphs.
+
+In dynamic-graph a graph is build with:
+- computational nodes which are entities \subpage subpage_entities.
+- directed edges which are created by connecting input and output signals
+\subpage subp_signals.
+- commands which are expanding the capabilities of the entity
+\subpage subpage_command
+- managing the nodes is done through a factory \subpage subp_factory providing
+classes and a way to create instances from this list of classes.
+- the instances of node are handled through a pool \subpage subp_pool
+
+We strongly recommend to use a scripting language such as Python to
+manage the graph.
+See <c>dynamic-graph-python</c> for more information on binding dynamic-graph
+with Python.
+
+It is possible to display the graph of entities \subpage writegraphdoc
+
+
+*/

doc/additionalDoc/installation.h

+/**
+\page subp_installation Installation
+
+\section sec_inst_dep Dependencies
+
+dynamic-graph depends on:
+<ul>
+<li> boost </li>
+<li> eigen </li>
+<li> cmake </li>
+</ul>
+
+\section sec_inst_get_src Getting the source
+
+The sources are available through github at the following URL:
+<a
+href="https://github.com/stack-of-tasks/dynamic-graph">https://github.com/stack-of-tasks/dynamic-graph</a>
+
+To clone:
+\code{.sh}
+git clone https://github.com/stack-of-tasks/dynamic-graph.git
+\endcode
+
+
+\section sec_inst_comp Compiling
+
+\code
+cd dynamic-graph
+mkdir _build
+cd _build
+cmake .. -DCMAKE_BUILD_TYPE=RELEASE
+make
+\endcode
+
+
+*/

doc/additionalDoc/introduction.h

+/**
+\page subp_concept_intro General introduction
+\section intro_dynamicGraph Introduction
+
+The dynamic-graph package is used to connect computation nodes, "entities"
+together using a graph system, akin to what Simulink does. Entities are
+connected through input and output signals. With the building blocks this
+package provides, you can easily create a full computation graph for a given
+problem. It is the basis for the stack of tasks operation.
+
+
+\subsection controlgraph Exemple: Real-time control
+
+<p>To give a more concrete example, the real-time control used by the Gepetto
+group for the humanoid robot HRP-2 is detailled.</p> <p> Real-time control
+system are usually driven by a cyclic computational node which needs to send a
+control reference value to each motors of a robot. To compute this control
+reference values, sensor values need to be provided. In the Stack-Of-Tasks
+special entities called Device are used to provide an abstract interface to the
+hardware.</p> A scheme of the real-time control graph used for the humanoid
+robot HRP-2 is depicted in the following figure:
+
+\image html Concept-Software-Fig.png
+
+You can find an example of a real example of control graph at \ref
+writegraphdoc.
+
+<p>The device therefore has a specific input which should contain the control
+vector. This control vector is the result of a computation solving a control
+problem. The entity in charge of solving this control problem is called "Solver"
+in the previous figure. In the SoT framework it is often cast as an optimization
+problem. This optimization problem is build using a control "Task" (not to be
+confused with the general word task). A control "Task" regulates the difference
+with a "Feature" computed on the current robot state and a "Desired Feature".
+For instance when walking, the regulated feature is the robot's Center-Of-Mass
+(CoM) position. The "Feature" is computed using a library using the robot model
+and the sensor value. The entity making this computation is "Dyn". A walking
+pattern generator using foot-steps position given in advance generates the
+desired value for the CoM. Note that the "Dyn" entity uses the sensor provided
+by the entity "Robot". </p>
+
+<p>
+From a pure computer science viewpoint we wish to avoid recomputing data such as
+articular Jacobians when this is unnecessary. Therefore the data generated by an
+entity through signals may have two types of dependencies: one dependency
+related to time and dependencies on other signals. Internally an entity does not
+recompute the data if no new information is available, it is simply providing
+the same information computed before. Please note that this package provides
+only the computational framework to realize the data dependency and the
+entities. Solvers, libraries to compute mechanical quantities are provided in
+different packages.
+</p>
+
+<p>
+Finally in order to dynamically create a graph, it is possible \b on-line to
+load classes of entities  and create instances of entities.</p>
+
+\subsection Functionnalities
+
+\li Support for extensions and modules using dynamic link libraries
+\li Template-based signal definition, independent
+\li Type-safe connection of input and output signals
+\li On-demand signal computation as well as a caching system for signal values
+allow fast computation of signal values, which is a critical point for real-time
+systems\n
+
+*/

doc/additionalDoc/package.h

 /*
  * Copyright 2010,
  * François Bleibel,
+ * Thomas Moulard,
  * Olivier Stasse,
  *
  * CNRS/AIST
  *
- * This file is part of dynamic-graph.
- * dynamic-graph is free software: you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public License
- * as published by the Free Software Foundation, either version 3 of
- * the License, or (at your option) any later version.
- * dynamic-graph is distributed in the hope that it will be
- * useful, but WITHOUT ANY WARRANTY; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU Lesser General Public License for more details.  You should
- * have received a copy of the GNU Lesser General Public License along
- * with dynamic-graph.  If not, see <http://www.gnu.org/licenses/>.
  */
 
 /**
 \mainpage
 
-\section intro_dynamicGraph Introduction
+The dynamic-graph aims at building computational graphs for real-time control.
+It provides the basic software functionnalities.
 
-The dynamic-graph package is used to connect computation nodes, "entities"
-together using a graph system, akin to what Simulink does. With the building
-blocks this package provides, you can easily create a full computation graph
-for a given problem. It is the basis for the stack of tasks operation.
+A more detailed introduction is available at \subpage subp_concept_intro.
 
-\section overview Code overview
-This code implements the factory design pattern, making creation of entities
-available to packages depending on the dynamic-graph API.
+The installation instruction are given at \subpage subp_installation.
 
-Objects, which are derived from Entities, can be
- declared within the code and compiled to shared libraries (.so/.dll files).
-These libraries can be loaded at run-time using the PluginLoader methods,
-and at the same time register their class names to the Factory (see the
-examples in the SOT documentation to learn how).
+The software graph structure is detailled in \subpage p_graph
 
-The Factory can then create instances of these objects and subsequently
-register them in the Pool, where they can be listed, accessed, and acted upon
-(see sotPoolStorage documentation). Basic commands defined by entities include
-signal connection graph file generation, help and name print, and signals.
+For debugging your entities detailed instructions are given in \subpage debug
 
-Finally, a shell (command-line) interface is made available thanks to the
-Interpreter class (see the file test_shell.cpp for an example). Objects deriving from
-Entity can expose their own commands by overriding the Entity's default
-commandLine() method. It is possible to load a plugin to register custom
-shell commands; see shell-functions and shell-procedure for an example.
+For citing the software in your research work please refer to
+\subpage subp_references
 
-Some basic shell functions, and support for procedures, are also included.
-For a complete list of those, load the plugin shell-functions.so and type 'help'
-at the command line.
+\namespace dynamicgraph This is the namespace where every object and class of
+this library is located.
 
-The public static objects (singletons) made available by including the
-corresponding headers in this module are:
-\li g_factory: FactoryStorage
-\li g_pool: PoolStorage
-\li g_shell: Interpreter
+\defgroup debug Debugging
 
-\image html pictures/use-case.svg
-
-.
 \defgroup dgraph Core classes and objects
-\defgroup signals Signals
-
-\ingroup dgraph
 @{
 
-Classes that make up the core of the dynamic-graph library are listed here.
+Classes, entities and binaries that make up the core of the dynamic-graph
+library are listed here.
 @}
-\ingroup signals
+
+\defgroup signals Signals
 @{
 This part provides the mechanism to transfer information
-from one feature to another. There are three main types of signals,
+from one entity to another. There are three main types of signals,
 all deriving from the common class dynamicgraph::SignalBase :
-\li dynamicgraph::Signal
-\li dynamicgraph::SignalPtr
-\li dynamicgraph::SignalTimeDependent
+\li dynamicgraph::Signal : a "normal" signal, passing data around \b by \b value
+\li dynamicgraph::SignalPtr : a signal used for efficient passing of large data,
+by reference (or rather, C pointers)* \li dynamicgraph::SignalTimeDependent : a
+signal that enforces a time dependency between other signals, making sure its
+inputs are up to date on access, using a incrementing time tick as reference.
+
+\n* Note: this may cause a problem if this package is used in a multithreaded
+program.
 
 Signals can be grouped together using dynamicgraph::SignalArray.
 
 Signals implement a caching mechanism by storing the last computation time tick.
-Signals can be plug into one another or set through shell commands.
-@}
 
-\namespace dynamicgraph This is the namespace where every object and class of this library is located.
+For more information, please see the individual signal pages.
+
+\b Samples
+
+\li The following code ensures the jacobian output signal uses up-to-date values
+for its computations, when accessed.
+
+\code
+  // This signal returns the Jacobian of the current value
+  //  according to the robot state
+  dg::SignalTimeDependent<ml::Matrix,int> jacobianSOUT;
+
+  (...)
+
+  jacobianSOUT.addDependency( positionSIN );
+  jacobianSOUT.addDependency( articularJacobianSIN );
+
+\endcode
+
+@}
 
 */

doc/additionalDoc/pool.h

+/**
+\page subp_pool Pool
+\section pool Pool
+The class \ref dynamicgraph::PoolStorage keeps track of the entities
+instanciated with the factory. The entities are the graph nodes. Signals are
+constructed during the class instanciation, they do not live independently from
+the entities. Signals are the directed edges of the graph. The pool can write a
+file representing the graph of entities.
+*/

doc/additionalDoc/references.h

+/**
+\page subp_references References
+
+\section sec_refer References
+Please when referencing the Stack-Of-Tasks use the following reference:
+
+\anchor Mansard2009
+
+<b> <a href="https://hal-lirmm.ccsd.cnrs.fr/lirmm-00796736/document">
+"A versatile Generalized Inverted Kinematics implementation for collaborative
+working humanoid robots: The Stack Of Tasks"</a>
+</b>,
+<em>N. Mansard, O. Stasse, P. Evrard, A. Kheddar,</em>
+Int. Conf. on Autonomous Robots, ICAR, 2009
+
+\anchor Mansard2007
+
+<b>"Task sequencing for sensor-based control"</b>,
+<em>N. Mansard, F. Chaumette,</em>
+IEEE Trans. on Robotics, 23(1):60-72, February 2007
+
+*/

doc/additionalDoc/signal.h

+/**
+\page subp_signals Signals
+\section sec_sigintro Signals
+
+Entities can output different types of signals. To guarante real-time
+perforamces, signals are implemented using C++ and mecanism which have a low
+time foot-print. All signals are templated by a Time tick type parameter (which
+is used in the caching of signals) - usually \c int. Signals are also templated
+after the type of data they accept or provide. For example: (example) For a more
+detailed programmer-oriented description of signals, please see \ref signals
+*/

doc/additionalDoc/tracer-real-timedoc.h

+/**
+\page tracerrealtimedoc TracerRealTime
+
+\section tracerrealtimedoc_description Description
+The \b TracerRealTime entity monitors a set of signals with real-time
+constraints; its function is very similar to the Tracer, except that all traces
+are recorded to a memory buffer, which can be emptied at any time.
+
+\section tracerrealtimedoc_commands Commands
+The \b commands that this entity exposes are:
+\code
+empty (discards all buffers)
+getBufferSize (gets buffer size for recording)
+setBufferSize (sets buffer size for recording)
+\endcode
+Plus all the commands exposed by \ref tracerdoc
+\n
+For more information on the signals exposed by this entity, please check the
+code documentation of the dynamicgraph::Tracer class.
+
+\section tracerrealtimedoc_sample Sample usage
+See \ref tracerdoc for a code sample of using TracerRealTime.
+
+\section tracerrealtimedoc_addi Additional information
+See doxygen documentation for the class dynamicgraph::TracerRealTime
+
+\section tracerrealtimedoc_generates Generated plugin file
+tracer-real-time.dll or tracer-real-time.so.
+*/

doc/additionalDoc/tracerdoc.h

+/**
+\page tracerdoc Tracer
+\section tracerdoc_description Description
+The \b Tracer entity monitors a set of signals. With an input change on the
+entity's [trigger] signal, the tracked signal values are recorded and traced to
+a file. The behavior of the trace-to-file function can be changed, from printing
+to a file immediately after recording, to printing out only when asked
+explicitly.
+
+\section tracerdoc_commands Commands
+The \b commands that this entity exposes are:
+\code
+open, close (a file);
+add (a signal)
+clear (recorded values);
+record (signal values)
+trace (doesn't do anything)
+start, stop (traces)
+\endcode
+\n
+For more information on the signals exposed by this entity, please check the
+code documentation of the dynamicgraph::Tracer class.
+\n\n
+
+\section tracerdoc_sample Sample usage
+The following code creates a TracerRealTime entity and sets the tracing buffer
+size to 80MB. It then tells the tracer to create files with names of the form:
+/tmp/dg_XXX.dat where XXX is the signal name, and call the signal
+after the device has evaluated the control law:
+\code
+robot.tracer = TracerRealTime("com_tracer")
+robot.tracer.setBufferSize(80*(2**20))
+robot.tracer.open('/tmp','dg_','.dat')
+robot.device.after.addSignal('{0}.triger'.format(robot.tracer.name))
+\endcode
+
+\section tracerdoc_addi Additional information
+See doxygen documentation for the class dynamicgraph::Tracer
+
+\section tracerdoc_generates Generated plugin file
+tracer.dll or tracer.so.
+*/

doc/additionalDoc/writeGraph.h

+/**
+\page writegraphdoc Displaying the graph of entities
+\section description Description
+It is possible to view the graph of entities currently instanciated.
+The format used by dynamic-graph is dot.
+Using the python interpreter the following command
+\code
+from dynamic_graph import *
+writeGraph('/tmp/my_dynamic_graph.dot')
+\endcode
+is writing the <b>my_dynamic_graph.dot</b> in the <b>/tmp</b> directory
+
+\section fromdottopdf Viewing as a PDF file
+To view the dot file you can simply use:
+\code
+dot -Tpdf /tmp/my_dynamic_graph.dot > /tmp/my_dynamic_graph.pdf
+\endcode
+
+It provides the following output:
+\image html my_dynamic_graph.png
+
+\section fromdottojs Viewing in a browser
+To view the dot file you can simply use the view_sot_dg.html file.
+Click on the "Choose File" to specify the filem and click on "Rendering" to
+display the graph.
+
+*/

doc/cmake_install.cmake

-# Install script for directory: /home/blue/sot-devel/dg/doc
-
-# Set the install prefix
-IF(NOT DEFINED CMAKE_INSTALL_PREFIX)
-  SET(CMAKE_INSTALL_PREFIX "/home/blue/sot-lib")
-ENDIF(NOT DEFINED CMAKE_INSTALL_PREFIX)
-STRING(REGEX REPLACE "/$" "" CMAKE_INSTALL_PREFIX "${CMAKE_INSTALL_PREFIX}")
-
-# Set the install configuration name.
-IF(NOT DEFINED CMAKE_INSTALL_CONFIG_NAME)
-  IF(BUILD_TYPE)
-    STRING(REGEX REPLACE "^[^A-Za-z0-9_]+" ""
-           CMAKE_INSTALL_CONFIG_NAME "${BUILD_TYPE}")
-  ELSE(BUILD_TYPE)
-    SET(CMAKE_INSTALL_CONFIG_NAME "")
-  ENDIF(BUILD_TYPE)
-  MESSAGE(STATUS "Install configuration: \"${CMAKE_INSTALL_CONFIG_NAME}\"")
-ENDIF(NOT DEFINED CMAKE_INSTALL_CONFIG_NAME)
-
-# Set the component getting installed.
-IF(NOT CMAKE_INSTALL_COMPONENT)
-  IF(COMPONENT)
-    MESSAGE(STATUS "Install component: \"${COMPONENT}\"")
-    SET(CMAKE_INSTALL_COMPONENT "${COMPONENT}")
-  ELSE(COMPONENT)
-    SET(CMAKE_INSTALL_COMPONENT)
-  ENDIF(COMPONENT)
-ENDIF(NOT CMAKE_INSTALL_COMPONENT)
-
-# Install shared libraries without execute permission?
-IF(NOT DEFINED CMAKE_INSTALL_SO_NO_EXE)
-  SET(CMAKE_INSTALL_SO_NO_EXE "1")
-ENDIF(NOT DEFINED CMAKE_INSTALL_SO_NO_EXE)
-
-IF(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL "Unspecified")
-  FILE(INSTALL DESTINATION "/home/blue/sot-lib/share/doc/dynamic-graph" TYPE DIRECTORY FILES "/home/blue/sot-devel/dg/doc/html")
-ENDIF(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL "Unspecified")
-
-IF(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL "Unspecified")
-  FILE(INSTALL DESTINATION "/home/blue/sot-lib/share/doc/dynamic-graph/html" TYPE FILE FILES "/home/blue/sot-devel/dg/doc/dynamic-graph.doxytag")
-ENDIF(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL "Unspecified")
-
-IF(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL "Unspecified")
-  FILE(INSTALL DESTINATION "/home/blue/sot-lib/share/doc/dynamic-graph/html" TYPE DIRECTORY FILES "/home/blue/sot-devel/dg/doc/pictures")
-ENDIF(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL "Unspecified")
-

doc/customdoxygen.css

+/* Customizing Doxygen output */
+
+/* Needed to allow line breaks in tables*/
+.memberdecls {
+  table-layout: fixed;
+  width: 100%;
+}
+
+/* Needed to break long template names*/
+.memTemplItemLeft {
+  white-space: normal !important;
+  word-wrap: break-word;
+}
+
+/* Needed to break long template names*/
+.memItemLeft {
+  white-space: normal !important;
+  word-wrap: break-word;
+}

doc/dg-shell-plugin.pod.in

-=head1 NAME
-
-dg-shell-plugin - Stack of tasks shell with all plug-ins loaded
-
-
-=head1 SYNOPSIS
-
-dg-shell-plugin
-
-
-=head1 DESCRIPTION
-
-Start the stack of tasks with all core plug-ins loaded.
-
-=head1 AUTHORS
-
-This software has been developed at CNRS/AIST and LAAS-CNRS laboratories.
-
-See <@CMAKE_INSTALL_PREFIX@/share/doc/libdg-middleware-dev/AUTHORS> to
-see the list of all contributors.
-
-
-=head1 SEE ALSO
-       dg-shell(1)
-
-See also <@PROJECT_URL@> for additional resources.

doc/dg-shell.pod.in

-=head1 NAME
-
-dg-shell - Stack of tasks shell
-
-
-=head1 SYNOPSIS
-
-dg-shell [FILE]
-
-
-=head1 DESCRIPTION
-
-Start the stack of tasks and provides to the user an interactive shell
-to control the data-flow.
-
-Optionally, a file which will be interpreted at start-up can be given
-to the program.
-
-
-=head1 AUTHORS
-
-This software has been developed at CNRS/AIST and LAAS-CNRS laboratories.
-
-See <@CMAKE_INSTALL_PREFIX@/share/doc/libdg-middleware-dev/AUTHORS> to
-see the list of all contributors.
-
-
-=head1 SEE ALSO
-       dg-shell-plugin(1)
-
-See also <@PROJECT_URL@> for additional resources.

doc/footer.html

- <br><br>
- <hr>
- <center>
- <img src="./pictures/footer.jpg" Height=100>
- <br>dynamicGraph library documentation</br>
- </center>
- <hr>
- </center>
- </body>
- </head>
-

doc/header.html

-<HTML>
-    <HEAD>
-      <TITLE>dynamicGraph library documentation</TITLE>
-      <LINK HREF="package.css" REL="stylesheet" TYPE="text/css">
-    </HEAD>
-    <BODY>
+<!-- HTML header for doxygen 1.8.11-->
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
+<meta http-equiv="X-UA-Compatible" content="IE=9"/>
+<meta name="generator" content="Doxygen $doxygenversion"/>
+<!--BEGIN PROJECT_NAME--><title>$projectname: $title</title><!--END PROJECT_NAME-->
+<!--BEGIN !PROJECT_NAME--><title>$title</title><!--END !PROJECT_NAME-->
+<link href="$relpath^tabs.css" rel="stylesheet" type="text/css"/>
+<link href="$relpath^sot.ico" rel="icon" type="image/x-icon">
+<script type="text/javascript" src="$relpath^jquery.js"></script>
+<script type="text/javascript" src="$relpath^dynsections.js"></script>
+$treeview
+$search
+$mathjax
+<link href="$relpath^$stylesheet" rel="stylesheet" type="text/css" />
+$extrastylesheet
+</head>
+<body>
+<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
 
+<!--BEGIN TITLEAREA-->
+<div id="titlearea">
+<table cellspacing="0" cellpadding="0">
+ <tbody>
+ <tr style="height: 56px;">
+  <!--BEGIN PROJECT_LOGO-->
+  <td id="projectlogo"><img alt="Logo" src="$relpath^$projectlogo"/></td>
+  <!--END PROJECT_LOGO-->
+  <!--BEGIN PROJECT_NAME-->
+  <td id="projectalign" style="padding-left: 0.5em;">
+   <div id="projectname">$projectname
+   <!--BEGIN PROJECT_NUMBER-->&#160;<span id="projectnumber">$projectnumber</span><!--END PROJECT_NUMBER-->
+   </div>
+   <!--BEGIN PROJECT_BRIEF--><div id="projectbrief">$projectbrief</div><!--END PROJECT_BRIEF-->
+  </td>
+  <!--END PROJECT_NAME-->
+  <!--BEGIN !PROJECT_NAME-->
+   <!--BEGIN PROJECT_BRIEF-->
+    <td style="padding-left: 0.5em;">
+    <div id="projectbrief">$projectbrief</div>
+    </td>
+   <!--END PROJECT_BRIEF-->
+  <!--END !PROJECT_NAME-->
+  <!--BEGIN DISABLE_INDEX-->
+   <!--BEGIN SEARCHENGINE-->
+   <td>$searchbox</td>
+   <!--END SEARCHENGINE-->
+  <!--END DISABLE_INDEX-->
+ </tr>
+ </tbody>
+</table>
+</div>
+<!--END TITLEAREA-->
+<!-- end header part -->