Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • cberge/dynamic-graph
  • ostasse/dynamic-graph
  • gsaurel/dynamic-graph
  • stack-of-tasks/dynamic-graph
4 results
Show changes
Commits on Source (312)
212 additional commits have been omitted to prevent performance issues.
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 1307 additions and 194 deletions
.git-blame-ignore-revs 0 → 100644
View file @ 2e7a70d5
# pre-commit run -a (Guilhem Saurel, 2022-07-27)
e9a222fb0a1f236e534e21c66cb623fd8d25b8d6
# pre-commit: details (Guilhem Saurel, 2022-04-14)
1c0f3cc1048a8b2a8206510a51a237b2f1e68a34
# pre-commit run -a (Guilhem Saurel, 2022-03-30)
0c1e6fb50735d4d6cc93e15d3bef202392d47c5b
# clang format defaults + pre-commit (Guilhem Saurel, 2022-03-30)
b6fc5d81e645a84fa8f4d656371adfb27c2b2b23
# [value] Clang format. (Olivier Stasse, 2022-01-09)
b852eef0d56de04ae91a43b1ddbd837ec69ddbe6
# linters: fix clang-check-12 (Guilhem Saurel, 2021-09-14)
ca1b2fc51540b4fcb2cd0b4fccaa33b02738af41
# reformat for clang-format-12 (Guilhem Saurel, 2021-09-07)
ed5899076b7b11c16d9517295e3826dd9b9d80d2
# format (Guilhem Saurel, 2020-11-13)
c54add29f80f6bcd1d05ca741d472491cf74c180
# format (Guilhem Saurel, 2020-07-22)
f4def3bfeaf0f9c9a6d5c5eb01c3a3b2fbb04b2f
# clang format. (Olivier Stasse, 2020-02-03)
70864112c87365af645f0404f881edf36c1ec734
# [clang] Update format. (Olivier Stasse, 2019-08-26)
384b2078e4962d762db4293bf3396be17df4e5c7
# [clang-format] Comply to Google style. (Olivier Stasse, 2019-08-20)
df48199dd436ba8341ae93c7b1f87eb30d0f457a
.gitignore
View file @ 2e7a70d5
_build*
*~
\ No newline at end of file
.~
compile_commands.json
.gitmodules
View file @ 2e7a70d5
[submodule "jrl-cmakemodules"]
path = jrl-cmakemodules
url = git://github.com/jrl-umi3218/jrl-cmakemodules.git
[submodule "cmake"]
path = cmake
url = git://github.com/jrl-umi3218/jrl-cmakemodules.git
[submodule ".travis"]
path = .travis
url = git://github.com/jrl-umi3218/jrl-travis.git
url = https://github.com/jrl-umi3218/jrl-cmakemodules.git
.pre-commit-config.yaml 0 → 100644
View file @ 2e7a70d5
ci:
autoupdate_branch: 'devel'
repos:
- repo: https://github.com/pre-commit/mirrors-clang-format
rev: v14.0.6
hooks:
- id: clang-format
args: [--style=Google]
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.3.0
hooks:
- id: check-added-large-files
- id: check-ast
- id: check-executables-have-shebangs
- id: check-json
- id: check-merge-conflict
- id: check-symlinks
- id: check-toml
- id: check-yaml
- id: debug-statements
- id: destroyed-symlinks
- id: detect-private-key
- id: end-of-file-fixer
- id: fix-byte-order-marker
- id: mixed-line-ending
- id: trailing-whitespace
- repo: https://github.com/cheshirekow/cmake-format-precommit
rev: v0.6.13
hooks:
- id: cmake-format
.travis @ 083fa2cb
Compare 083fa2cb...083fa2cb
Subproject commit 083fa2cb0fa4ad594926d9bb3d246075e62ce9ee
.travis.yml deleted 100644 → 0
View file @ 52ebaecc
language: cpp
sudo: required
compiler:
- gcc
- clang
env:
global:
- DEBSIGN_KEYID=5AE5CD75
- secure: "lEJYxth3fNsmvNS7Ern9+kEpHk4X3Tjo51GBUQBNL6g+YyZJKm4xwBEfwK+sewlmhY3oLUds+5H/2zE27q517kIcpP2Tlp4sRfooJfnBS7YYyF+1boxbvOXrZ2aqev3rzkyvKKMBg0UJTvAiSf7JgVCkMv33GeAX3/I+djEh23U="
- secure: "QTw5QQDaeQWBz6APcUCyl9P9UPI/T3j1++9o9fPxygS9R/7bQYNCrSH++owcAVCJgUI5oY3RmnYk/PjVygOLM0vbFqB2mMySibAhO/U3pSLtZ/HyPjqI9fX0TV/Cf7ji7soeXKk8p6kI2InMILpODLBaLdfm/jgCdAfecr5sGQI="
- secure: "JEcGQsUgEND64cAGVEHSxg8j7SlwofuYtLamANszs/h8FGYZ82rEjmG7r2zqSfBj/i1WsnSbTSsh8WJuXzvV8fw8enkcLEuJG9scQJzuzY8hnLe81o1fhEkclML0SLkLQ2Fu6rIqlKKeYwmJFFhSIj69ESRIkDhkjA1OrV7szzc="
- APT_DEPENDENCIES="doxygen libboost-dev libboost-test-dev libboost-filesystem-dev libboost-system-dev libboost-thread-dev libboost-program-options-dev liblapack-dev gfortran libeigen3-dev"
- GIT_DEPENDENCIES="jrl-umi3218/jrl-mathtools jrl-umi3218/jrl-mal"
- PPA_URI="stack-of-tasks/snapshot"
- NSIQCPPSTYLE_FILEFILTERPATH=cmake/filefilter.txt
notifications:
hipchat:
rooms:
- secure: "SP8KX6gPzBT0BCpcL3ybK4Cgx7a7rmK3Hv/fD2lIf/RUdTwtzLh/J/l9xSYuMZisLe1tM+12vfP7r6t1RNdXrB7pSpYvFRNIWmyfBC7KnUFVn5rwxUnDPhKY3D/XaJ1cycbBJqJdUjYjFKCGEm4x6cpRRN61Ii66RAUvm1h9aHQ="
email:
- hpp-source@laas.fr
branches:
only:
- master
- debian
script: ./.travis/run build
after_success: ./.travis/run after_success
after_failure: ./.travis/run after_failure
before_install: ./.travis/run before_install
matrix:
allow_failures:
- compiler: clang
CMakeLists.txt
View file @ 2e7a70d5
# Copyright 2010, Olivier Stasse, JRL, 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
# General Lesser 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/>.
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
INCLUDE(cmake/base.cmake)
INCLUDE(cmake/boost.cmake)
INCLUDE(cmake/eigen.cmake)
INCLUDE(cmake/pthread.cmake)
INCLUDE(cmake/cpack.cmake)
SET(PROJECT_ORG stack-of-tasks)
SET(PROJECT_NAME dynamic-graph)
SET(PROJECT_DESCRIPTION "Dynamic graph library")
SET(PROJECT_URL "http://github.com/${PROJECT_ORG}/${PROJECT_NAME}")
SET(PROJECT_SUFFIX "-v3")
SET(CUSTOM_HEADER_DIR "${PROJECT_NAME}")
SET(DOXYGEN_USE_MATHJAX YES)
# Defines paths.
SET(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/lib)
SETUP_PROJECT()
cmake_minimum_required(VERSION 3.1)
# Project properties
set(PROJECT_ORG stack-of-tasks)
set(PROJECT_NAME dynamic-graph)
set(PROJECT_DESCRIPTION "Dynamic graph library")
set(PROJECT_URL "https://github.com/${PROJECT_ORG}/${PROJECT_NAME}")
# Project options
option(SUFFIX_SO_VERSION "Suffix library name with its version" ON)
# Project configuration
set(PROJECT_USE_CMAKE_EXPORT TRUE)
set(CUSTOM_HEADER_DIR ${PROJECT_NAME})
set(CXX_DISABLE_WERROR TRUE)
# Doxygen setup
set(DOXYGEN_USE_MATHJAX YES)
set(DOXYGEN_USE_TEMPLATE_CSS YES)
# JRL-cmakemodule setup
include(cmake/base.cmake)
include(cmake/boost.cmake)
# Project definition
compute_project_args(PROJECT_ARGS LANGUAGES CXX)
project(${PROJECT_NAME} ${PROJECT_ARGS})
check_minimal_cxx_standard(14 ENFORCE)
include(cmake/pthread.cmake) # needs to be included after the CXX definition
# Project dependencies
if(BUILD_TESTING)
find_package(Boost REQUIRED COMPONENTS unit_test_framework)
endif()
add_project_dependency(Boost REQUIRED COMPONENTS serialization system thread)
add_project_dependency(Eigen3 REQUIRED)
search_for_pthread()
if(Boost_VERSION GREATER 107299 OR Boost_VERSION_MACRO GREATER 107299)
# Silence a warning about a deprecated use of boost bind by boost >= 1.73
# without dropping support for boost < 1.73
add_definitions(-DBOOST_BIND_GLOBAL_PLACEHOLDERS)
endif()
# Add configuration headers for plug-ins.
GENERATE_CONFIGURATION_HEADER(
${HEADER_DIR} config-tracer.hh DG_TRACER tracer_EXPORTS)
GENERATE_CONFIGURATION_HEADER(
${HEADER_DIR}
config-tracer-real-time.hh DG_TRACERREALTIME tracer_real_time_EXPORTS)
generate_configuration_header(${HEADER_DIR} config-tracer.hh DG_TRACER
tracer_EXPORTS)
generate_configuration_header(${HEADER_DIR} config-tracer-real-time.hh
DG_TRACERREALTIME tracer_real_time_EXPORTS)
# Verbosity level
if(NOT (\"${CMAKE_VERBOSITY_LEVEL}\" STREQUAL \"\"))
add_definitions(-DVP_DEBUG_MODE=${CMAKE_VERBOSITY_LEVEL} -DVP_DEBUG)
endif(NOT (\"${CMAKE_VERBOSITY_LEVEL}\" STREQUAL \"\"))
# Main Library
set(${PROJECT_NAME}_HEADERS
include/${CUSTOM_HEADER_DIR}/fwd.hh
include/${CUSTOM_HEADER_DIR}/debug.h
include/${CUSTOM_HEADER_DIR}/real-time-logger.h
include/${CUSTOM_HEADER_DIR}/real-time-logger-def.h
include/${CUSTOM_HEADER_DIR}/dynamic-graph-api.h
include/${CUSTOM_HEADER_DIR}/entity.h
include/${CUSTOM_HEADER_DIR}/factory.h
include/${CUSTOM_HEADER_DIR}/pool.h
include/${CUSTOM_HEADER_DIR}/exception-abstract.h
include/${CUSTOM_HEADER_DIR}/exception-factory.h
include/${CUSTOM_HEADER_DIR}/exception-signal.h
include/${CUSTOM_HEADER_DIR}/exception-traces.h
include/${CUSTOM_HEADER_DIR}/signal.h
include/${CUSTOM_HEADER_DIR}/signal-array.h
include/${CUSTOM_HEADER_DIR}/signal-base.h
include/${CUSTOM_HEADER_DIR}/signal-ptr.h
include/${CUSTOM_HEADER_DIR}/signal-time-dependent.h
include/${CUSTOM_HEADER_DIR}/signal-ptr.t.cpp
include/${CUSTOM_HEADER_DIR}/signal.t.cpp
include/${CUSTOM_HEADER_DIR}/time-dependency.h
include/${CUSTOM_HEADER_DIR}/time-dependency.t.cpp
# Kept for a brittle backward compatiblity.
include/${CUSTOM_HEADER_DIR}/signal-caster.h
include/${CUSTOM_HEADER_DIR}/signal-cast-helper.h
include/${CUSTOM_HEADER_DIR}/all-signals.h
include/${CUSTOM_HEADER_DIR}/signal-helper.h
include/${CUSTOM_HEADER_DIR}/entity-helper.h
include/${CUSTOM_HEADER_DIR}/tracer.h
include/${CUSTOM_HEADER_DIR}/tracer-real-time.h
include/${CUSTOM_HEADER_DIR}/command.h
include/${CUSTOM_HEADER_DIR}/eigen-io.h
include/${CUSTOM_HEADER_DIR}/linear-algebra.h
include/${CUSTOM_HEADER_DIR}/value.h
include/${CUSTOM_HEADER_DIR}/command-setter.h
include/${CUSTOM_HEADER_DIR}/command-setter.t.cpp
include/${CUSTOM_HEADER_DIR}/command-getter.h
include/${CUSTOM_HEADER_DIR}/command-getter.t.cpp
include/${CUSTOM_HEADER_DIR}/command-direct-getter.h
include/${CUSTOM_HEADER_DIR}/command-direct-setter.h
include/${CUSTOM_HEADER_DIR}/command-bind.h
include/${CUSTOM_HEADER_DIR}/all-commands.h
include/${CUSTOM_HEADER_DIR}/logger.h)
set(${PROJECT_NAME}_SOURCES
src/debug/debug.cpp
src/debug/real-time-logger.cpp
src/debug/logger.cpp
src/dgraph/entity.cpp
src/dgraph/factory.cpp
src/dgraph/pool.cpp
src/exception/exception-abstract.cpp
src/exception/exception-factory.cpp
src/exception/exception-signal.cpp
src/exception/exception-traces.cpp
src/mt/process-list.cpp
src/signal/signal-array.cpp
src/command/value.cpp
src/command/command.cpp)
# FIXME: to be changed into lib/dynamic-graph
# to avoid name collision when installing dynamic-graph in /usr.
SET(PLUGINDIR "${CMAKE_INSTALL_FULL_LIBDIR}/plugin")
add_library(${PROJECT_NAME} SHARED ${${PROJECT_NAME}_SOURCES}
${${PROJECT_NAME}_HEADERS})
modernize_target_link_libraries(
${PROJECT_NAME}
SCOPE
PUBLIC
TARGETS
Eigen3::Eigen
INCLUDE_DIRS
${EIGEN3_INCLUDE_DIR})
target_include_directories(${PROJECT_NAME} PUBLIC $<INSTALL_INTERFACE:include>)
target_link_libraries(${PROJECT_NAME} PUBLIC Boost::serialization Boost::system
Boost::thread)
# Add extra keys to pkg-config file to export the location of the
# plug-in directory in a robust manner.
SET(PKG_CONFIG_EXTRA "plugindir=${PLUGINDIR}")
if(UNIX)
target_link_libraries(${PROJECT_NAME} PUBLIC ${CMAKE_DL_LIBS} pthread)
endif(UNIX)
# Add dependency toward dynamic graph library in pkg-config file.
PKG_CONFIG_APPEND_LIBS(${PROJECT_NAME})
if(SUFFIX_SO_VERSION)
set_target_properties(${PROJECT_NAME} PROPERTIES SOVERSION ${PROJECT_VERSION})
endif(SUFFIX_SO_VERSION)
# Search for Boost.
SEARCH_FOR_BOOST()
SEARCH_FOR_PTHREAD()
install(
TARGETS ${PROJECT_NAME}
EXPORT ${TARGETS_EXPORT_NAME}
DESTINATION lib)
# Search for Boost.
SEARCH_FOR_EIGEN()
set(DYNAMIC_GRAPH_PLUGINDIR "lib/${PROJECT_NAME}-plugins")
set(PACKAGE_EXTRA_MACROS
"set(DYNAMIC_GRAPH_PLUGINDIR ${DYNAMIC_GRAPH_PLUGINDIR})")
set(PKG_CONFIG_EXTRA "plugindir=${DYNAMIC_GRAPH_PLUGINDIR}")
ADD_SUBDIRECTORY(src)
ADD_SUBDIRECTORY(include/${PROJECT_NAME})
ADD_SUBDIRECTORY(tests)
add_subdirectory(src)
if(BUILD_TESTING)
add_subdirectory(tests)
endif(BUILD_TESTING)
SETUP_PROJECT_FINALIZE()
SETUP_PROJECT_CPACK()
pkg_config_append_libs(${PROJECT_NAME})
install(FILES package.xml DESTINATION share/${PROJECT_NAME})
NEWS
View file @ 2e7a70d5
......@@ -129,4 +129,3 @@ stasse (3):
Reinforce the dependant->dependent policy. Merge the florent branch. Makes the test_depend.cpp test works.
Reinforce the dependant->dependent policy.
Adding documentation to cmdPlug.
README.md
View file @ 2e7a70d5
dynamic-graph
=============
[![Building Status](https://travis-ci.org/stack-of-tasks/dynamic-graph.svg?branch=master)](https://travis-ci.org/stack-of-tasks/dynamic-graph)
[![Pipeline status](https://gepgitlab.laas.fr/stack-of-tasks/dynamic-graph/badges/master/pipeline.svg)](https://gepgitlab.laas.fr/stack-of-tasks/dynamic-graph/commits/master)
[![Coverage report](https://gepgitlab.laas.fr/stack-of-tasks/dynamic-graph/badges/master/coverage.svg?job=doc-coverage)](http://projects.laas.fr/stack-of-tasks/doc/stack-of-tasks/dynamic-graph/master/coverage/)
[![Building status](https://gitlab.laas.fr/stack-of-tasks/dynamic-graph/badges/master/pipeline.svg)](https://gitlab.laas.fr/stack-of-tasks/dynamic-graph/commits/master)
[![Coverage report](https://gitlab.laas.fr/stack-of-tasks/dynamic-graph/badges/master/coverage.svg?job=doc-coverage)](http://projects.laas.fr/stack-of-tasks/doc/stack-of-tasks/dynamic-graph/master/coverage/)
[![License](https://img.shields.io/badge/License-BSD%202--Clause-green.svg)](https://opensource.org/licenses/BSD-2-Clause)
[![pre-commit.ci status](https://results.pre-commit.ci/badge/github/stack-of-tasks/dynamic-graph/master.svg)](https://results.pre-commit.ci/latest/github/stack-of-tasks/dynamic-graph)
This software provides an efficient way to modelize a C++ data-flow.
......@@ -42,10 +43,7 @@ located in the `$prefix/share/doc/dynamic-graph` directoy where
Getting Help
------------
Support is provided through:
* the HPP mailing-list: hpp@laas.fr
* the following HipChat room: http://www.hipchat.com/gh4wQrZeV
Support is provided through issues on the github interface.
How can I install dynamic-graph?
--------------------------------
......@@ -57,13 +55,9 @@ have to be available on your machine.
- Libraries:
- [Boost][] (>= 1.40)
Its detection is controlled by the `BOOST_ROOT` variable, see next section
for more information.
- [Lapack][] library
Use the generic purpose `CMAKE_CXX_FLAGS` and `CMAKE_EXE_LINKER_FLAGS`
to insert the flags required for the compiler to find your Lapack library
if it is installed in a non-standard directory.
- [jrl-mal][] library
- Doxygen
- Eigen3
- pthread
- System tools:
- [CMake][] (>=2.6)
- [pkg-config][]
......@@ -143,15 +137,12 @@ This package authors are credited in the [AUTHORS](AUTHORS) file.
Available Packages
------------------
* RobotPkg (Release 2.5.3r1):
* RobotPkg :
http://robotpkg.openrobots.org/robotpkg/motion/dynamic-graph/index.html
[doxygen-documentation]: http://stack-of-tasks.github.io/dynamic-graph/doxygen/HEAD/
[jrl-mathtools]: https://github.com/jrl-umi3218/jrl-mathtools
[jrl-mal]: https://github.com/jrl-umi3218/jrl-mal
[git-submodules]: http://git-scm.com/book/en/Git-Tools-Submodules
[Boost]: http://www.boost.org/
......@@ -159,7 +150,6 @@ Available Packages
[Doxygen]: http://www.stack.nl/~dimitri/doxygen/
[Eigen]: http://eigen.tuxfamily.org/
[Git]: http://git-scm.com/
[Lapack]: http://www.netlib.org/lapack/
[Libtool]: https://www.gnu.org/software/libtool/
[RobotPkg]: http://robotpkg.openrobots.org/
[log4cxx]: https://logging.apache.org/log4cxx/
......
cmake @ 47c0cbf0
Subproject commit d128cc2965a7878dc38acf8f4395e1899aa505cb
Subproject commit 47c0cbf0b29433060682377dcb28266e8dc38995
doc/Doxyfile.extra.in
View file @ 2e7a70d5
This diff is collapsed.
doc/additionalDoc/debug-doc.h
View file @ 2e7a70d5
/**
\page debug Debugging
They are several ways to perform debugging in dynamic-graph depending on your needs or situation:
- If you just need to collect informations from signals (like rosbag). You can use
an entity called Tracer inside the graph:\subpage tracerdoc
- programmatically in C++ with macros \subpage subp_dbg_trace
- programmatically inside the entity in C++ using member of the entities:
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 0 → 100644
View file @ 2e7a70d5
/**
\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
View file @ 2e7a70d5
......@@ -2,11 +2,11 @@
\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.
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
......@@ -31,18 +31,15 @@ are written is specified by:
\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.
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 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:
......@@ -62,11 +59,11 @@ A message inside the code is written through:
This generates the following output:
\code
/path_to/dynamic-graph/tests/debug-trace.cpp: testDebugTrace(#52) :Here is a test
\endcode
/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
\include tests/debug-trace.cpp
*/
doc/additionalDoc/doc-command.h 0 → 100644
View file @ 2e7a70d5
/** \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 0 → 100644
View file @ 2e7a70d5
/**
\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
View file @ 2e7a70d5
......@@ -5,46 +5,57 @@
\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 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.
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.
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).
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.
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>)
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
View file @ 2e7a70d5
......@@ -4,19 +4,25 @@
\section usecase How to use this package
\subsection use_programmatically General introduction
Objects, which are derived from Entities (base class dynamicgraph::Entity), can be
declared within the code and compiled to shared libraries (.so/.dll files).
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).
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, where they can be listed, accessed, and acted upon
(see PoolStorage documentation). Basic commands defined by entities include
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>)
<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:
......@@ -27,12 +33,100 @@ 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>
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.
They are given also in the <a href="http://projects.laas.fr/gepetto/doc/stack-of-tasks/sot-core/master/doxygen-html">sot-core</a> package as well.
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
View file @ 2e7a70d5
......@@ -2,5 +2,6 @@
\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.
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
View file @ 2e7a70d5
......@@ -6,13 +6,18 @@ 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.
- managing the nodes is done through a factory \subpage subp_factory providing classes and a way to create instances from this list of classes.
- 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
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.
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
......