debian/libdynamic-graph-doc.lintian-overrides

-#Suppresses the embedded javascript warning produced by doxygen embed of jquery.
-#See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736360
-libdynamic-graph-doc binary: embedded-javascript-library usr/share/doc/dynamic-graph/doxygen-html/jquery.js
\ No newline at end of file

debian/libdynamic-graph3.0.0.install

-usr/lib/*.so.*
-usr/lib/plugin/*.so
-usr/share/man/*
-usr/share/dynamic-graph/*
\ No newline at end of file

debian/libdynamic-graph3.0.0.triggers

-activate-noawait ldconfig
\ No newline at end of file

debian/rules

-#!/usr/bin/make -f
-# -*- makefile -*-
-# Sample debian/rules that uses debhelper.
-# This file was originally written by Joey Hess and Craig Small.
-# As a special exception, when this file is copied by dh-make into a
-# dh-make output file, you may use that output file without restriction.
-# This special exception was added by Craig Small in version 0.37 of dh-make.
-
-# Uncomment this to turn on verbose mode.
-export DH_VERBOSE=1
-export DEB_BUILD_MAINT_OPTIONS = hardening=+all
-
-DPKG_EXPORT_BUILDFLAGS = 1
-include /usr/share/dpkg/buildflags.mk
-CFLAGS+=$(CPPFLAGS)
-CXXFLAGS+=$(CPPFLAGS)
-
-
-override_dh_auto_configure:
-	dh_auto_configure -- -DGENERATE_DOC=ON
-
-override_dh_makeshlibs:
-	dh_makeshlibs --exclude=lib/plugin --noscripts
-
-override_dh_shlibdeps:
-	dh_shlibdeps --exclude=lib/plugin
-
-override_dh_installchangelogs:
-	dh_installchangelogs changelog
-
-%:
-	dh $@ 

debian/source/format

-3.0 (quilt)

debian/upstream/signing-key.asc

------BEGIN PGP PUBLIC KEY BLOCK-----
-Version: GnuPG v1.4.11 (GNU/Linux)
-
-mQINBFcWFgYBEAChZPmJhHIfP2TGMdp0+CrM3vnRzHvlr0mz+o7JFIq8Sq8dMkv0
-RuiD1DzSfPISctg1OMP/+neMoHnUvPLjnAHiMF0+URtT9D66spqg3opHBlyHecbw
-DFbaQDE/jOa50tK/DeDOEUoh0casavIwXhKJcJMlRjpfQY34b/IE09kP/wBCsBac
-k6wEx5DOntMmG8IbmjGqzNxTOqwSZWSs7ymqsVmkNSxOEFxjjUIZtsAL8D0PCLfB
-YkM38sR6bhj0V3RcT/Q3/U2g3Yd/KiRD0WpdFvkEshBtL80Nc0kfFTWbuYCaCHVe
-QUdMDRGD+kuVlvxybhejLo5d6ndZtn6+nQCIAWrHAI6LvkbeT4VMho37uIcKPZ5q
-dfpFOBvHo+BFA2KdZUUT0owV34nfFiBOuXGjrQ2AqoDuoG6nqkTTTnelk28qnZAo
-JfxgM0dKafLAbXsTte0ctpTMaEBm7WQkVtD/7zDhf0UzKpU4I7adQL/b2DlJe36V
-tu6ctHNRnV+D13o+1Tuze7mvn5SVIjurrnTqtKkF1KfWr6YCMmN+cPkCFf76xQgl
-Ab7XYWqZhqB4RTRhqZ0WqzBnjiw05cHGqx7FYqcV+KndTV7xGcuigO5tQ7nY/u8z
-q2802mOngkQTbJAI+Re4GObKXIp+4fk+aB0Y3ZUfab8PBbni3/ifTTPoXwARAQAB
-tCtSb2hhbiBCdWRoaXJhamEgPGJ1ZGhpcmFqYS5yb2hhbkBnbWFpbC5jb20+iQI4
-BBMBAgAiBQJXFhYGAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZKfzx
-xHE14dsyEACNJSEfQXwXrknITRrV7mDopI3EJTyZnaLILazzofgMJIVZ2ZDBx59Q
-ylj6MbZTMlJ6ery2OMMqXN0K6XMgGM+iXrYLlXkOscnq9dJQEqrsNFJxhwBuruoA
-SEPHjwd2nLHGnLOkhDA3Gz1JhfTjj7UOXdKm8n12tkHflWJQfKMt4BbngJpmyzWl
-I7vGWpjsYZAe8c9LfdTdFKAeLNHlwkdwDz46CnY4bOYcC6anvU2gKQCVD49OtVad
-TxbLNsv6BmcROYDmiu01yUsZN551zEpX8zq2w1IQ9xV3BrtPdHAIAmCAq40TVjfu
-QFWRL736B0vsCbEu4bpEP5VoFcQl5v/zLjFNLqgb9thxnCNPpuZ483ZNWBQrj0PF
-b9eTKHUl/2OCh0l74zYqweYX8c8gQGBUhSXQh6ff7uXCAAGrlOWJyP1e6YEwgx2a
-wPLG4f8B3M0vBkaPmVoXfelPnBbZetOFu8kNfRDqqkBEVbCjpTsY8a3c8e39FZX8
-wqNo84t9OEw9CGYJKxDYsx9ootBZUD2kx0CY2aNri2LU1E9J28mVxjFAr/4HLaGP
-Ujt3T/r1Tc2UomFgQfRCBcMJfquw0PZloxqLm5UkWsmCZxGS5TxhpeOjPO+T3xb4
-uiyk+Z1dZlOV+LgkECYbn5BFfslUU2KQ8EnvRuo+C4l3GfshMHCk/LkCDQRXFhYG
-ARAAsjYAtNpLg1F3Y+8uFVgAY3ZCLKQQF+W0BkNjO06iLe9AYyxm05YPrQNnih73
-w1VXDJYqcixbLYPUArccefyScGCCItI0O2hkto2t4EqwHZibCtDk+H00zvDcoLLo
-MNkk1ap5Y2WCPiBisOWJrF+O43V5OJNIf3CD/09/mgN1wQOYzWt2eIAJp8R05Vcl
-nzdUDk1sujDOah7zfTK494kD2sZCeCsT5+UR4VweycIvJyOmNe8TkLBui6lKuBUT
-GMTpFrGtUEftMWVW5rpLkB7r+yGLeMbpELu8ZB00SprRywQhdjw/JKTBjKAL+eGM
-3I39gz507TLxEdUPN08BZqflLM1QUpYjXxf2scvUXPwf7jGeUPw4a1Buv7brbkmZ
-Wn0upoPiGewwR45n0YVzgJTHShSuhOWburCtT75KMVP8f74jdtCdyVThgWyKSb0D
-d39czmE5LCyhnM/waETpV2dcc+1rGN25MY9CHXxMfdJA3ZqHko3/pp5TqgtT8075
-pXQub+nQtHJZfRcsvDHw6w86H0VSY7QFtXAoonY1Jen4gN3FL0a24gbL44odeIL+
-Kx2O22+X5rVZ3hDtPipwDSpQ6wTqREmmxptncyUs8NMV+WW/SU3tLxw3zYTzp00Z
-OQUthqx6HlT5EVskwKvlk37ZMURtQNYIlVr1HypIYXAcxkcAEQEAAYkCHwQYAQIA
-CQUCVxYWBgIbDAAKCRAZKfzxxHE14X7yEACLif+R0FjwNMbUH+QefXg/r+iN+hnr
-yIwFenlh0NPPS/93H2//EY6n1LVxYmtxdxNDod3E0Xrt2O1rVhDl+ZsUcBrvhJx5
-ULGLJak1Rb+dGYeWtzPck635qJ5WFKLvqkeDBxpyUtgF8sDHbKMMhPdRnt18rgMe
-MgHEkncgSxoTsmTFTygjCZ0ZtNAw/o4ZWHzzJWyb9W/JXSqj53zytEIeit2IIK19
-1C7rlJjWwR/C/QunTZykMqHiK0U27s420hhH//5xRN8KuWewjDskNz0n1+fPKXfQ
-FGEiQKnMO+8HXoCO4NQ5zbTsNWKmgGuPBmnvDA/1mZhfqXdhKkYfuXeigiSmD1PZ
-EmbwpJGLk5023uS+hs3IfqQGOOuM/sXmw9eMDvhRUeVwxuG5+g+SbFkHbrmDKTTx
-Jdv06lUT5AzrDrR5+u0Z0UIwVBii2wzVyi2k5gciKX0nBkcddu758SMbRK5W6wH1
-eKVaLvdJBJFTWgkO8jKSrXTRgr8pkVWzJAWVF24FzDw/meJbNcxRiny6nDUFFTKT
-sEaHed9Kau55jAEofZsSz0ZISFCSnsCIapDBOuGteAEw1AEVumQw9IO940PKAEof
-XSHj1EA2JENYYAXNVY+H+O2kBicoUZKiTTuEV2qVXw44Fng4MNmthHNTvbYNYJl8
-ZjNmUHOna0zViA==
-=nPA5
------END PGP PUBLIC KEY BLOCK-----

debian/watch

-version=3
-opts=filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/dynamic-graph-$1\.tar\.gz/,\
-pgpsigurlmangle=s/github.com/raw.githubusercontent.com/;\
-s/archive\/master/signatures/;\
-s/([^\/]+)\.tar\.gz/dynamic-graph-$1\.tar\.gz/;\
-s/$/.asc/ \
- https://github.com/proyan/dynamic-graph/releases .*/v?(\d\S*)\.tar\.gz
\ No newline at end of file

doc/additionalDoc/debug-doc.h

+/**
+\page debug Debugging
+
+They are several ways to perform debugging in dynamic-graph depending on your
+needs or situation:
+- Programmatically inside the entity in C++, a logger will
+write inside a buffer in a
+different thread and output in a stream (either std::cout or a file). It is
+detailed in \subpage subp_debug_rt_logger.
+It provides 4 levels of messags :(DEBUG,INFO,
+WARNING, ERROR). It is described in details here: \subpage subp_logger
+
+- Programmatically in C++ to avoid overhead with macros and handling level as an
+int: \subpage subp_dbg_trace .
+- If you just need to collect informations from signals (like rosbag). You can
+use an entity called Tracer inside the graph:\subpage tracerdoc . <br> A real
+time version exists to write directly inside a memory buffer
+\subpage tracerrealtimedoc
+**/

doc/additionalDoc/debug-logger.h

+/**
+\page subp_logger Loggers
+
+\section sec_init_rt_logger Initialization of the logger
+
+\subsection subsec_init_rt_logger_hcpp Header and preprocessor variable
+
+In order to activate the logger you need to add the following lines:
+\code
+#define ENABLE_RT_LOG
+#include <dynamic-graph/logger.h>
+#include <dynamic-graph/real-time-logger.h>
+\endcode
+
+\subsection subsec_logger_ Initialize the output stream
+
+It is possible to set the output stream of the messages inside a file:
+\code
+  dynamicgraph::RealTimeLogger::instance();
+  of.open("/tmp/dg-LOGS.txt",std::ofstream::out|std::ofstream::app);
+  dgADD_OSTREAM_TO_RTLOG (of);
+
+  dynamicgraph::RealTimeLogger::destroy();
+\endcode
+
+\section sec_use_rt_logger Using the rt_logger
+
+
+\code
+// Somewhere in your library
+dgRTLOG() << "your message. Prefer to use \n than std::endl."
+\endcode
+
+
+Here the output file is "/tmp/dg-LOGS.txt".
+
+
+Specifying the file with __FILE__ and the line inside the file by __LINE__ are
+necessary for the STREAM messages. Indeed they are indexed using the two values.
+The default values "" and 0 for the counting are not well understood.
+*/

doc/additionalDoc/debug-trace-doc.h

+/**
+\page subp_dbg_trace Debugging with macros and level
+
+\section subp_dbg_trace_intro Introduction
+The idea of this class and collection of MACROS is to specify
+a level for a message, and record the message in a stream according to this
+level. In addition there are mechanisms allowing that no time is wasted in
+condition test. You can therefore let the debugging messages inside the code
+without impact on performances.
+
+\section subp_dbg_trace_set_on_macros Setting up dgDEBUG macros
+
+To allow message display the entity must be compiled with the macro
+\code
+#define VP_DEBUG 1
+\endcode
+Commenting or removing this macro disable all the messages specified
+by the following macros.
+
+The level up to which the messages are accepted for display is
+specified by:
+\code
+#define VP_DEBUG_MODE 50
+\endcode
+
+In the constructor of the entity, the file where all the messages
+are written is specified by:
+\code
+  dynamicgraph::dgDEBUGFLOW.openFile("/tmp/dynamic-graph-traces.txt");
+\endcode
+
+\section subp_dbg_trace_using_macros Using dgDEBUG macros
+
+To print that the beginning of a method is being executed use the following
+macros: \code dgDEBUGIN(5); \endcode 5 here specifies the minimum level that you
+be specified by VP_DEBUG_MODE for this message to be displayed.
+
+It will generate the following output:
+\code
+/path_to/dynamic-graph/tests/debug-trace.cpp: testDebugTrace(#46) :# In {
+\endcode
+The output displays the name of the source file, the name of the method,
+the line where is the macro, and the message itself.
+
+When going out of the method:
+\code
+    dgDEBUGOUT(5);
+\endcode
+
+This generates the following output:
+\code
+/path_to/dynamic-graph/tests/debug-trace.cpp: testDebugTrace(#54) :# Out }
+\endcode
+
+A message inside the code is written through:
+\code
+      dgDEBUG(5) << "Here is a test" << std::endl;
+\endcode
+
+This generates the following output:
+\code
+/path_to/dynamic-graph/tests/debug-trace.cpp: testDebugTrace(#52) :Here is a
+test \endcode
+
+\section subp_dbg_trace_wrk_exp Working example
+
+A full working example is given here:
+\include tests/debug-trace.cpp
+ */

doc/additionalDoc/doc-command.h

+/** \page subpage_command Commands
+
+\section subpage_command_intro Quick introduction
+
+Commands are allowing to expand the entities.
+It has no real interest in C++, and is mostly targeted to scripting languages
+used to manipulate the control graph.
+dynamic-graph-python provides a mecanism which is automatically binding command
+to python. The main interest for a programmer is that there is no additional
+lines to add. It is realized through CMake rules provided by the submodule
+jrl-cmakemodules.
+
+\section subpage_command_using Extending entities
+
+\subsection subpage_command_setters_and_getters Setters and getters
+
+To modify a quantity with a special method of your class, it is recommanded to
+use Setter.
+
+For instance to specify the size of the state in one entity and calls the
+method setStateSize it is possible to write:
+
+\code
+    docstring = "\n"
+                "    Set size of state vector\n"
+                "\n";
+    addCommand("resize", new command::Setter<Device, unsigned int>(
+                             *this, &Device::setStateSize, docstring));
+\endcode
+
+Getting the information of the member of the class can be realized with
+the following snippet:
+
+\code
+    addCommand("getTimeStep",
+               command::makeDirectGetter(
+                   *this, &this->timestep_,
+                   command::docDirectGetter("Time step", "double")));
+\endcode
+
+\subsubsection subsubpage_command_void_multiple_args Implementing a command
+
+Templates are provided to create commands returning no value, but with up to
+4 arguments.
+
+In order to call the following method:
+\code
+  void four_args(const int &, const int &, const int &, const int &) {
+    test_four_args_ = true;
+  }
+\endcode
+
+It is sufficient to add in the constructor:
+\code
+    addCommand("4_args",
+               makeCommandVoid4(
+                   *this, &CustomEntity::four_args,
+                   docCommandVoid4("four args", "int", "int", "int", "int")));
+\endcode
+
+The arguments are limited to the types provided by the class Value.
+
+\subsection subpage_command_void_multiple_args Commands returning a value
+
+The templates with the prefix makeCommandReturnType are allowing to return
+a type.
+
+For instance to add a command returning a type with two arguments:
+\code
+  std::string two_args_ret(const int &, const int &)
+  { test_two_args_ = true; return std::string("return");}
+\endcode
+
+In the constructor, the following snippet shows to create the command:
+\code
+    addCommand("2_args_r",
+               makeCommandReturnType2(
+                 *this, &CustomEntity::two_args_ret,
+                 docCommandVoid2("two args", "int","int")));
+\endcode
+
+\section section_calling_a_generic_command Calling a generic command
+
+Of course calling in C++ a command amounts to call directly the method.
+However in the context of writing a wrapper for another language,
+one may wants to find a command and build the call.
+
+All the commands of an entity are store in a map. The strings storing the
+commands name are the map keys.
+
+Therefore calling the previous command can be done with the following snippet:
+\code
+
+std::map<const std::string, Command *> aCommandMap =
+ this->getNewStyleCommandMap();
+
+std::string cmd_name = "4_args";
+
+std::map<const std::string, Command *>::iterator it_map;
+
+it_map = aCommandMap.find(cmd_name);
+if (it_map == aCommandMap.end())
+
+int first_arg = 1;
+Value aValue(first_arg);
+std::vector<Value> values;
+
+for (unsigned int i = 0; i < 4; i++)
+  values.push_back(aValue);
+
+it_map->second->setParameterValues(values);
+it_map->second->execute();
+it_map->second->owner();
+it_map->second->getDocstring();
+
+\endcode
+
+when returning a value the line with the call to execute is :
+\code
+Value aValue =it_map->second->execute();
+\endcode
+
+*/

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

@@ -6,202 +6,35 @@
  *
  * 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
 
+The dynamic-graph aims at building computational graphs for real-time control.
+It provides the basic software functionnalities.
 
+A more detailed introduction is available at \subpage subp_concept_intro.
 
-\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
-
-<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 Built-in scripting language* for fast prototyping and testing of computational graph
-\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
-See \ref scriptingabout
-
-\section entity Computational Entity
-\image html entity.png
-
-\subsection entity_definition General definition
-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 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.
-
-\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/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>)
-
-\section sigintro Signals
-
-Entities can output different types of signals. 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
-
-\section graph Graph
-
-In this package, the graph considered are directed graphs.
-
-\subsection factory Factory
-
-The class \ref dynamicgraph::FactoryStorage is a singleton which register the entity classes and which is allowing the instancation of such classes.
-
-\subsection 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.
-
-\subsection scriptingabout Building the graph
-
-This package provides a scripting language allows entities to define their own commands, and
-provides a basic framework to build dynamically the computational graph.
-However bindings have been created with python in the <a href="https://github.com/stack-of-tasks/dynamic-graph-python">dynamic-graph-python package</a>
-and we strongly recommend to use this package instead of the in-house scripting language.
-
-\section usecase How to use this package
-\subsection use_programmtically Programmatically
-Objects, which are derived from Entities (base class dynamicgraph::Entity), 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 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 PoolStorage documentation). Basic commands defined by entities include
-signal connection graph file generation, help and name print, and signals.
-
-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/unitTesting).
-
-\subsection Tutorial
-A tutorial is available <a href="http://stack-of-tasks.github.io/dynamic-graph-tutorial/">here</a>
-\section references References
-\anchor Mansard2009
-
-<b> "A versatile Generalized Inverted Kinematics implementation for collaborative working humanoid robots: The Stack Of Tasks"</b>,
-<em>N. Mansard, O. Stasse, P. Evrard, A. Kheddar,</em>
-Int. Conf. on Autonomous Robots, ICAR, 2009
-
-\anchor Mansard2007
+The installation instruction are given at \subpage subp_installation.
 
-<b>"Task sequencing for sensor-based control"</b>,
-<em>N. Mansard, F. Chaumette,</em>
-IEEE Trans. on Robotics, 23(1):60-72, February 2007
+The software graph structure is detailled in \subpage p_graph
 
-\namespace dynamicgraph This is the namespace where every object and class of this library is located.
+For debugging your entities detailed instructions are given in \subpage debug
+
+For citing the software in your research work please refer to
+\subpage subp_references
+
+\namespace dynamicgraph This is the namespace where every object and class of
+this library is located.
+
+\defgroup debug Debugging
 
 \defgroup dgraph Core classes and objects
 @{
 
-Classes, entities and binaries 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.
 @}
 
 \defgroup signals Signals
@@ -210,11 +43,13 @@ This part provides the mechanism to transfer information
 from one entity to another. There are three main types of signals,
 all deriving from the common class dynamicgraph::SignalBase :
 \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.
+\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.
+\n* Note: this may cause a problem if this package is used in a multithreaded
+program.
 
 Signals can be grouped together using dynamicgraph::SignalArray.
 
@@ -224,8 +59,8 @@ 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.
+\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