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 (249)
149 additional commits have been omitted to prevent performance issues.
Hide whitespace changes
Inline Side-by-side
Showing
with 1194 additions and 269 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 @ db1c58f5
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
cmake_minimum_required(VERSION 3.1)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
# 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}")
INCLUDE(cmake/base.cmake)
INCLUDE(cmake/boost.cmake)
INCLUDE(cmake/eigen.cmake)
INCLUDE(cmake/pthread.cmake)
# Project options
option(SUFFIX_SO_VERSION "Suffix library name with its version" ON)
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")
# Project configuration
set(PROJECT_USE_CMAKE_EXPORT TRUE)
set(CUSTOM_HEADER_DIR ${PROJECT_NAME})
set(CXX_DISABLE_WERROR TRUE)
SET(CUSTOM_HEADER_DIR "${PROJECT_NAME}")
# Doxygen setup
set(DOXYGEN_USE_MATHJAX YES)
set(DOXYGEN_USE_TEMPLATE_CSS YES)
SET(DOXYGEN_USE_MATHJAX YES)
# JRL-cmakemodule setup
include(cmake/base.cmake)
include(cmake/boost.cmake)
# Defines paths.
SET(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/lib)
# Project definition
compute_project_args(PROJECT_ARGS LANGUAGES CXX)
project(${PROJECT_NAME} ${PROJECT_ARGS})
check_minimal_cxx_standard(14 ENFORCE)
SETUP_PROJECT()
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.
SET(BOOST_COMPONENTS serialization system unit_test_framework thread)
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()
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 f34901f143d843b48dfdb8d9e904503ed96e2310
Subproject commit 47c0cbf0b29433060682377dcb28266e8dc38995
doc/Doxyfile.extra.in
View file @ 2e7a70d5
INPUT = @CMAKE_SOURCE_DIR@/include \
@CMAKE_SOURCE_DIR@/doc/additionalDoc
IMAGE_PATH = @CMAKE_SOURCE_DIR@/doc/pictures \
@CMAKE_SOURCE_DIR@/doc/figures
# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
# inherited members of a class in the documentation of that class as if those
# members were ordinary class members. Constructors, destructors and assignment
# operators of the base classes will not be shown.
FILE_PATTERNS = *.cc *.cpp *.h *.hh *.hxx
INLINE_INHERITED_MEMB = NO
TAGFILES = \
"@CMAKE_INSTALL_PREFIX@/share/doc/dynamic-graph-python.doxytag = @CMAKE_INSTALL_PREFIX@/share/doc/dynamic-graph-python"
\ No newline at end of file
# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
# (but less readable) file names. This can be useful is your file systems
# doesn't support long names like on DOS, Mac, or CD-ROM.
SHORT_NAMES = NO
# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
# will interpret the first line (until the first dot) of a JavaDoc-style
# comment as the brief description. If set to NO, the JavaDoc
# comments will behave just like regular Qt-style comments
# (thus requiring an explicit @brief command for a brief description.)
JAVADOC_AUTOBRIEF = NO
# If MARKDOWN_SUPPORT is enabled (the default) then doxygen pre-processes all
# comments according to the Markdown format, which allows for more readable
# documentation. See http://daringfireball.net/projects/markdown/ for details.
# The output of markdown processing is further processed by doxygen, so you
# can mix doxygen, HTML, and XML commands with Markdown formatting.
# Disable only in case of backward compatibilities issues.
MARKDOWN_SUPPORT = YES
# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and
# unions are shown inside the group in which they are included (e.g. using
# @ingroup) instead of on a separate page (for HTML and Man pages) or
# section (for LaTeX and RTF).
INLINE_GROUPED_CLASSES = NO
# When TYPEDEF_HIDES_STRUCT is enabled, a typedef of a struct, union, or enum
# is documented as struct, union, or enum with the name of the typedef. So
# typedef struct TypeS {} TypeT, will appear in the documentation as a struct
# with name TypeT. When disabled the typedef will appear as a member of a file,
# namespace, or class. And the struct will be named TypeS. This can typically
# be useful for C code in case the coding convention dictates that all compound
# types are typedef'ed and only the typedef is referenced, never the tag name.
TYPEDEF_HIDES_STRUCT = NO
# Similar to the SYMBOL_CACHE_SIZE the size of the symbol lookup cache can be
# set using LOOKUP_CACHE_SIZE. This cache is used to resolve symbols given
# their name and scope. Since this can be an expensive process and often the
# same symbol appear multiple times in the code, doxygen keeps a cache of
# pre-resolved symbols. If the cache is too small doxygen will become slower.
# If the cache is too large, memory is wasted. The cache size is given by this
# formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range is 0..9, the default is 0,
# corresponding to a cache size of 2^16 = 65536 symbols.
LOOKUP_CACHE_SIZE = 0
#---------------------------------------------------------------------------
# Build related configuration options
#---------------------------------------------------------------------------
# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
# documentation are documented, even if no documentation was available.
# Private class members and static file members will be hidden unless
# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
EXTRACT_ALL = NO
# If the EXTRACT_PRIVATE tag is set to YES all private members of a class
# will be included in the documentation.
EXTRACT_PRIVATE = NO
# If the EXTRACT_STATIC tag is set to YES all static members of a file
# will be included in the documentation.
EXTRACT_STATIC = YES
# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
# defined locally in source files will be included in the documentation.
# If set to NO only classes defined in header files are included.
EXTRACT_LOCAL_CLASSES = YES
# If the EXTRACT_PACKAGE tag is set to YES all members with package or internal scope will be included in the documentation.
EXTRACT_PACKAGE = NO
# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
# undocumented members of documented classes, files or namespaces.
# If set to NO (the default) these members will be included in the
# various overviews, but no documentation section is generated.
# This option has no effect if EXTRACT_ALL is enabled.
HIDE_UNDOC_MEMBERS = NO
# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
# undocumented classes that are normally visible in the class hierarchy.
# If set to NO (the default) these classes will be included in the various
# overviews. This option has no effect if EXTRACT_ALL is enabled.
HIDE_UNDOC_CLASSES = NO
# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
# friend (class|struct|union) declarations.
# If set to NO (the default) these declarations will be included in the
# documentation.
#HIDE_FRIEND_COMPOUNDS = NO
# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
# documentation blocks found inside the body of a function.
# If set to NO (the default) these blocks will be appended to the
# function's detailed documentation block.
HIDE_IN_BODY_DOCS = NO
# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
# file names in lower-case letters. If set to YES upper-case letters are also
# allowed. This is useful if you have classes or files whose names only differ
# in case and if your file system supports case sensitive file names. Windows
# and Mac users are advised to set this option to NO.
CASE_SENSE_NAMES = YES
# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen
# will show members with their full class and namespace scopes in the
# documentation. If set to YES the scope will be hidden.
HIDE_SCOPE_NAMES = YES
# The INTERNAL_DOCS tag determines if documentation
# that is typed after a \internal command is included. If the tag is set
# to NO (the default) then the documentation will be excluded.
# Set it to YES to include the internal documentation.
INTERNAL_DOCS = YES
# The ENABLED_SECTIONS tag can be used to enable conditional
# documentation sections, marked by \if sectionname ... \endif.
ENABLED_SECTIONS = DEV
# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen
# will sort the (detailed) documentation of file and class members
# alphabetically by member name. If set to NO the members will appear in
# declaration order.
SORT_MEMBER_DOCS = YES
# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the
# brief documentation of file, namespace and class members alphabetically
# by member name. If set to NO (the default) the members will appear in
# declaration order.
SORT_BRIEF_DOCS = YES
# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen
# will sort the (brief and detailed) documentation of class members so that
# constructors and destructors are listed first. If set to NO (the default)
# the constructors will appear in the respective orders defined by
# SORT_MEMBER_DOCS and SORT_BRIEF_DOCS.
# This tag will be ignored for brief docs if SORT_BRIEF_DOCS is set to NO
# and ignored for detailed docs if SORT_MEMBER_DOCS is set to NO.
SORT_MEMBERS_CTORS_1ST = YES
# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to
# do proper type resolution of all parameters of a function it will reject a
# match between the prototype and the implementation of a member function even
# if there is only one candidate or it is obvious which candidate to choose
# by doing a simple string match. By disabling STRICT_PROTO_MATCHING doxygen
# will still accept a match between prototype and implementation in such cases.
STRICT_PROTO_MATCHING = NO
# The GENERATE_TESTLIST tag can be used to enable (YES) or
# disable (NO) the test list. This list is created by putting \test
# commands in the documentation.
GENERATE_TESTLIST = YES
# The GENERATE_BUGLIST tag can be used to enable (YES) or
# disable (NO) the bug list. This list is created by putting \bug
# commands in the documentation.
GENERATE_BUGLIST = YES
# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
# disable (NO) the deprecated list. This list is created by putting
# \deprecated commands in the documentation.
GENERATE_DEPRECATEDLIST= YES
# The MAX_INITIALIZER_LINES tag determines the maximum number of lines
# the initial value of a variable or define consists of for it to appear in
# the documentation. If the initializer consists of more lines than specified
# here it will be hidden. Use a value of 0 to hide initializers completely.
# The appearance of the initializer of individual variables and defines in the
# documentation can be controlled using \showinitializer or \hideinitializer
# command in the documentation regardless of this setting.
MAX_INITIALIZER_LINES = 30
# Set the SHOW_USED_FILES tag to NO to disable the list of files generated
# at the bottom of the documentation of classes and structs. If set to YES the
# list will mention the files that were used to generate the documentation.
SHOW_USED_FILES = YES
# Set the SHOW_NAMESPACES tag to NO to disable the generation of the
# Namespaces page.
# This will remove the Namespaces entry from the Quick Index
# and from the Folder Tree View (if specified). The default is YES.
SHOW_NAMESPACES = YES
# Set the SHOW_FILES tag to NO to disable the generation of the Files page.
# This will remove the Files entry from the Quick Index and from the
# Folder Tree View (if specified). The default is YES.
SHOW_FILES = YES
# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
# by doxygen. The layout file controls the global structure of the generated
# output files in an output format independent way. To create the layout file
# that represents doxygen's defaults, run doxygen with the -l option.
# You can optionally specify a file name after the option, if omitted
# DoxygenLayout.xml will be used as the name of the layout file.
LAYOUT_FILE =
#---------------------------------------------------------------------------
# configuration options related to warning and progress messages
#---------------------------------------------------------------------------
# The QUIET tag can be used to turn on/off the messages that are generated
# by doxygen. Possible values are YES and NO. If left blank NO is used.
QUIET = NO
# The WARNINGS tag can be used to turn on/off the warning messages that are
# generated by doxygen. Possible values are YES and NO. If left blank
# NO is used.
WARNINGS = YES
# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
# for undocumented members. If EXTRACT_ALL is set to YES then this flag will
# automatically be disabled.
WARN_IF_UNDOCUMENTED = NO
# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
# potential errors in the documentation, such as not documenting some
# parameters in a documented function, or documenting parameters that
# don't exist or using markup commands wrongly.
WARN_IF_DOC_ERROR = YES
# The WARN_NO_PARAMDOC option can be enabled to get warnings for
# functions that are documented, but have no documentation for their parameters
# or return value. If set to NO (the default) doxygen will only warn about
# wrong or incomplete parameter documentation, but not about the absence of
# documentation.
WARN_NO_PARAMDOC = NO
# The WARN_FORMAT tag determines the format of the warning messages that
# doxygen can produce. The string should contain the $file, $line, and $text
# tags, which will be replaced by the file and line number from which the
# warning originated and the warning text. Optionally the format may contain
# $version, which will be replaced by the version of the file (if it could
# be obtained via FILE_VERSION_FILTER)
WARN_FORMAT = "$file:$line: $text"
# The WARN_LOGFILE tag can be used to specify a file to which warning
# and error messages should be written. If left blank the output is written
# to stderr.
WARN_LOGFILE = @CMAKE_BINARY_DIR@/doc/doxygen.log
#---------------------------------------------------------------------------
# configuration options related to the input files
#---------------------------------------------------------------------------
# The INPUT tag can be used to specify the files and/or directories that contain
# documented source files. You may enter file names like "myfile.cpp" or
# directories like "/usr/src/myproject". Separate the files or directories
# with spaces.
INPUT = @CMAKE_SOURCE_DIR@/include \
@CMAKE_SOURCE_DIR@/doc/additionalDoc
# The RECURSIVE tag can be used to turn specify whether or not subdirectories
# should be searched for input files as well. Possible values are YES and NO.
# If left blank NO is used.
RECURSIVE = YES
# If the value of the INPUT tag contains directories, you can use the
# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
# and *.h) to filter out the source-files in the directories. If left
# blank the following patterns are tested:
# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx
# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py *.f90
FILE_PATTERNS = *.cc *.cpp *.h *.hpp *.hh *.dox *.md *.py
# The EXCLUDE tag can be used to specify files and/or directories that should be
# excluded from the INPUT source files. This way you can easily exclude a
# subdirectory from a directory tree whose root is specified with the INPUT tag.
# Note that relative paths are relative to the directory from which doxygen is
# run.
EXCLUDE = @CMAKE_SOURCE_DIR@/doc/d-practical-exercises/src
# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
# directories that are symbolic links (a Unix file system feature) are excluded
# from the input.
EXCLUDE_SYMLINKS = YES
# If the value of the INPUT tag contains directories, you can use the
# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
# certain files from those directories. Note that the wildcards are matched
# against the file with absolute path, so to exclude all test directories
# for example use the pattern */test/*
EXCLUDE_PATTERNS += CMake* \
*.txt \
*.sh \
*.orig \
*.diff \
diff \
*~ \
*. \
*.sln \
*.sdf \
*.tmp \
*.vcxproj \
*.filters \
*.user \
*.suo
# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
# (namespaces, classes, functions, etc.) that should be excluded from the
# output. The symbol name can be a fully qualified name, a word, or if the
# wildcard * is used, a substring. Examples: ANamespace, AClass,
# AClass::ANamespace, ANamespace::*Test
EXCLUDE_SYMBOLS = internal::* \
*Visitor
# The IMAGE_PATH tag can be used to specify one or more files or
# directories that contain image that are included in the documentation (see
# the \image command).
IMAGE_PATH = @CMAKE_SOURCE_DIR@/doc/pictures
#---------------------------------------------------------------------------
# configuration options related to source browsing
#---------------------------------------------------------------------------
# If the SOURCE_BROWSER tag is set to YES then a list of source files will
# be generated. Documented entities will be cross-referenced with these sources.
# Note: To get rid of all source code in the generated output, make sure also
# VERBATIM_HEADERS is set to NO.
SOURCE_BROWSER = YES
# Setting the INLINE_SOURCES tag to YES will include the body
# of functions and classes directly in the documentation.
INLINE_SOURCES = NO
# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
# will generate a verbatim copy of the header file for each class for
# which an include is specified. Set to NO to disable this.
VERBATIM_HEADERS = YES
#---------------------------------------------------------------------------
# configuration options related to the alphabetical class index
#---------------------------------------------------------------------------
# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index
# of all compounds will be generated. Enable this if the project
# contains a lot of classes, structs, unions or interfaces.
ALPHABETICAL_INDEX = YES
# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then
# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
# in which this list will be split (can be a number in the range [1..20])
COLS_IN_ALPHA_INDEX = 4
#---------------------------------------------------------------------------
# configuration options related to the HTML output
#---------------------------------------------------------------------------
# With the PROJECT_LOGO tag one can specify an logo or icon that is
# included in the documentation. The maximum height of the logo should not
# exceed 55 pixels and the maximum width should not exceed 200 pixels.
# Doxygen will copy the logo to the output directory.
PROJECT_LOGO = @PROJECT_SOURCE_DIR@/doc/pictures/sot.png
HTML_EXTRA_FILES += @PROJECT_SOURCE_DIR@/doc/pictures/sot.png
# The HTML_HEADER tag can be used to specify a personal HTML header for
# each generated HTML page. If it is left blank doxygen will generate a
# standard header. Note that when using a custom header you are responsible
# for the proper inclusion of any scripts and style sheets that doxygen
# needs, which is dependent on the configuration options used.
# It is advised to generate a default header using "doxygen -w html
# header.html footer.html stylesheet.css YourConfigFile" and then modify
# that header. Note that the header is subject to change so you typically
# have to redo this when upgrading to a newer version of doxygen or when
# changing the value of configuration settings such as GENERATE_TREEVIEW!
HTML_HEADER = @PROJECT_SOURCE_DIR@/doc/header.html
HTML_EXTRA_FILES += @PROJECT_SOURCE_DIR@/doc/pictures/sot.ico
# The HTML_FOOTER tag can be used to specify a personal HTML footer for
# each generated HTML page. If it is left blank doxygen will generate a
# standard footer.
HTML_FOOTER =
# The HTML_STYLESHEET tag can be used to specify a user-defined cascading
# style sheet that is used by each HTML page. It can be used to
# fine-tune the look of the HTML output. If the tag is left blank doxygen
# will generate a default style sheet. Note that doxygen will try to copy
# the style sheet file to the HTML output directory, so don't put your own
# style sheet in the HTML output directory as well, or it will be erased!
# NOTE: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag,
# as it is more robust and this tag (HTML_STYLESHEET)
# will in the future become obsolete.
#HTML_STYLESHEET = @PROJECT_SOURCE_DIR@/doc/package.css
# The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-defined
# cascading style sheets that are included after the standard style sheets
# created by doxygen. Using this option one can overrule certain style aspects.
# This is preferred over using HTML_STYLESHEET since it does not replace
# the standard style sheet and is therefore more robust against future updates.
# Doxygen will copy the style sheet files to the output directory.
HTML_EXTRA_STYLESHEET = @PROJECT_SOURCE_DIR@/doc/customdoxygen.css
# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output.
# Doxygen will adjust the colors in the style sheet and background images
# according to this color. Hue is specified as an angle on a colorwheel,
# see http://en.wikipedia.org/wiki/Hue for more information.
# For instance the value 0 represents red, 60 is yellow, 120 is green,
# 180 is cyan, 240 is blue, 300 purple, and 360 is red again.
# The allowed range is 0 to 359.
# The default is 220.
HTML_COLORSTYLE_HUE = 220
# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of
# the colors in the HTML output. For a value of 0 the output will use
# grayscales only. A value of 255 will produce the most vivid colors.
HTML_COLORSTYLE_SAT = 100
# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to
# the luminance component of the colors in the HTML output. Values below
# 100 gradually make the output lighter, whereas values above 100 make
# the output darker. The value divided by 100 is the actual gamma applied,
# so 80 represents a gamma of 0.8, The value 220 represents a gamma of 2.2,
# and 100 does not change the gamma.
HTML_COLORSTYLE_GAMMA = 80
# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
# documentation will contain sections that can be hidden and shown after the
# page has loaded. For this to work a browser that supports
# JavaScript and DHTML is required (for instance Mozilla 1.0+, Firefox
# Netscape 6.0+, Internet explorer 5.0+, Konqueror, or Safari).
HTML_DYNAMIC_SECTIONS = NO
# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of
# entries shown in the various tree structured indices initially; the user
# can expand and collapse entries dynamically later on. Doxygen will expand
# the tree to such a level that at most the specified number of entries are
# visible (unless a fully collapsed tree already exceeds this amount).
# So setting the number of entries 1 will produce a full collapsed tree by
# default. 0 is a special value representing an infinite number of entries
# and will result in a full expanded tree by default.
HTML_INDEX_NUM_ENTRIES = 100
# When GENERATE_DOCSET tag is set to YES, this tag specifies a string that
# should uniquely identify the documentation set bundle. This should be a
# reverse domain-name style string, e.g. com.mycompany.MyDocSet. Doxygen
# will append .docset to the name.
DOCSET_BUNDLE_ID = org.doxygen.@PACKAGE_NAME@
# When GENERATE_PUBLISHER_ID tag specifies a string that should uniquely identify
# the documentation publisher. This should be a reverse domain-name style
# string, e.g. com.mycompany.MyDocSet.documentation.
DOCSET_PUBLISHER_ID = fr.laas.gepetto
# The GENERATE_PUBLISHER_NAME tag identifies the documentation publisher.
DOCSET_PUBLISHER_NAME = Gepetto
# The QHP_NAMESPACE tag specifies the namespace to use when generating
# Qt Help Project output. For more information please see
# http://doc.trolltech.com/qthelpproject.html#namespace
QHP_NAMESPACE = org.doxygen.@PACKAGE_NAME@
# A unique identifier for the eclipse help plugin. When installing the plugin
# the directory name containing the HTML and XML files should also have
# this name.
ECLIPSE_DOC_ID = org.doxygen.@PACKAGE_NAME@
# The DISABLE_INDEX tag can be used to turn on/off the condensed index at
# top of each HTML page. The value NO (the default) enables the index and
# the value YES disables it.
DISABLE_INDEX = YES
# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
# structure should be generated to display hierarchical information.
# If the tag value is set to YES, a side panel will be generated
# containing a tree-like index structure (just like the one that
# is generated for HTML Help). For this to work a browser that supports
# JavaScript, DHTML, CSS and frames is required (i.e. any modern browser).
# Windows users are probably better off using the HTML help feature.
# Since the tree basically has the same information as the tab index you
# could consider to set DISABLE_INDEX to NO when enabling this option.
GENERATE_TREEVIEW = YES
# Use this tag to change the font size of Latex formulas included
# as images in the HTML documentation. The default is 10. Note that
# when you change the font size after a successful doxygen run you need
# to manually remove any form_*.png images from the HTML output directory
# to force them to be regenerated.
FORMULA_FONTSIZE = 12
#---------------------------------------------------------------------------
# configuration options related to the LaTeX output
#---------------------------------------------------------------------------
# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will
# generate Latex output.
GENERATE_LATEX = NO
# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX
# packages that should be included in the LaTeX output.
EXTRA_PACKAGES +=
#---------------------------------------------------------------------------
# Configuration options related to the preprocessor
#---------------------------------------------------------------------------
# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will
# evaluate all C-preprocessor directives found in the sources and include
# files.
ENABLE_PREPROCESSING = YES
# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro
# names in the source code. If set to NO (the default) only conditional
# compilation will be performed. Macro expansion can be done in a controlled
# way by setting EXPAND_ONLY_PREDEF to YES.
MACRO_EXPANSION = YES
# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
# then the macro expansion is limited to the macros specified with the
# PREDEFINED and EXPAND_AS_DEFINED tags.
EXPAND_ONLY_PREDEF = YES
# The PREDEFINED tag can be used to specify one or more macro names that
# are defined before the preprocessor is started (similar to the -D option of
# gcc). The argument of the tag is a list of macros of the form: name
# or name=definition (no spaces). If the definition and the = are
# omitted =1 is assumed. To prevent a macro definition from being
# undefined via #undef or recursively expanded use the := operator
# instead of the = operator.
PREDEFINED += EIGEN_MAKE_ALIGNED_OPERATOR_NEW \
EIGEN_STRONG_INLINE=inline
# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
# this tag can be used to specify a list of macro names that should be expanded.
# The macro definition that is found in the sources will be used.
# Use the PREDEFINED tag if you want to use a different macro definition that
# overrules the definition found in the source code.
EXPAND_AS_DEFINED =
# The INCLUDE_PATH tag can be used to specify one or more directories that
# contain include files that are not input files but should be processed by
# the preprocessor.
INCLUDE_PATH = @PROJECT_SOURCE_DIR@/src
#---------------------------------------------------------------------------
# Configuration::additions related to external references
#---------------------------------------------------------------------------
# The TAGFILES option can be used to specify one or more tagfiles.
# Optionally an initial location of the external documentation
# can be added for each tagfile. The format of a tag file without
# this location is as follows:
#
# TAGFILES = file1 file2 ...
# Adding location for the tag files is done as follows:
#
# TAGFILES = file1=loc1 "file2 = loc2" ...
# where "loc1" and "loc2" can be relative or absolute paths or
# URLs. If a location is present for each tag, the installdox tool
# does not have to be run to correct the links.
# Note that each tag file must have a unique name
# (where the name does NOT include the path)
# If a tag file is not located in the directory in which doxygen
# is run, you must also specify the path to the tagfile here.
TAGFILES = \
"@CMAKE_INSTALL_PREFIX@/share/doc/dynamic-graph-python.doxytag = @CMAKE_INSTALL_PREFIX@/share/doc/dynamic-graph-python"
EXAMPLE_PATH = @CMAKE_SOURCE_DIR@/tests
# A dedicated BIB_PATH would be preferable
EXAMPLE_PATH += @PROJECT_SOURCE_DIR@/doc/bib
# Enable the USE_MATHJAX option to render $\mbox{\LaTeX}$ formulas using
# MathJax (see http://www.mathjax.org) which uses client side Javascript for
# the rendering instead of using pre-rendered bitmaps. Use this if you do not
# have $\mbox{\LaTeX}$ installed or if you want to formulas look prettier in
# the HTML output. When enabled you may also need to install MathJax separately
# and configure the path to it using the MATHJAX_RELPATH option.
USE_MATHJAX = YES
MATHJAX_RELPATH = MathJax/
# When MathJax is enabled you can set the default output format to be used for
# the MathJax output. See the MathJax site for more details. Possible values
# are: HTML-CSS (which is slower, but has the best compatibility), NativeMML
# (i.e. MathML) and SVG. The default value is: HTML-CSS. This tag requires that
# the tag USE_MATHJAX is set to YES.
MATHJAX_FORMAT = SVG
#---------------------------------------------------------------------------
# Aliases
#---------------------------------------------------------------------------
ALIASES += "cheatsheet=\xrefitem cheatsheet \"Remarkable identity\" \"Cheat sheet\""
CITE_BIB_FILES += @CMAKE_SOURCE_DIR@/doc/sot.bib
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:
- Programmatically inside the entity in C++ 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.
- Programmatically inside the entity in C++ using a member of the entities and the previous real-time mechanism.
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
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
View file @ 2e7a70d5
/**
\page subp_logger Loggers
\section sec_logger Initialization of the logger
\section sec_init_rt_logger Initialization of the logger
\subsection subsec_logger_hcpp Header and preprocessor variable
\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/real-time-logger.h>
#include <dynamic-graph/logger.h>
#include <dynamic-graph/real-time-logger.h>
\endcode
\subsection subsec_logger_ Initialize the output stream
......@@ -22,51 +22,20 @@ It is possible to set the output stream of the messages inside a file:
dynamicgraph::RealTimeLogger::destroy();
\endcode
Here the file is "/tmp/dg-LOGS.txt".
\subsection subsec_logger_init Initialization of the logger
\section sec_use_rt_logger Using the rt_logger
Inside the constructor of the entity:
\code
logger_.setTimeSample(0.001);
logger_.setStreamPrintPeriod(0.005);
logger_.setVerbosity(VERBOSITY_ALL);
LoggerVerbosity alv = logger_.getVerbosity();
// Somewhere in your library
dgRTLOG() << "your message. Prefer to use \n than std::endl."
\endcode
The first line sets the frequency at which the logger will be updated.<br>
The second line specifies at which frequency the STREAM messages should be
printed.<br>
The third line specifies the level of message to accept.<br>
The fourth line returns the level of verbosity.
In this case, all messages are accepted and the STREAM message are displayed on the output streams once on five. <br>
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>
Here the output file is "/tmp/dg-LOGS.txt".
\section sec_logger_tests Displaying messages
Here is some example on how to display or record some information.
\code
sendMsg("This is a message of level MSG_TYPE_DEBUG",MSG_TYPE_DEBUG, __FILE__,__LINE__);
sendMsg("This is a message of level MSG_TYPE_INFO",MSG_TYPE_INFO, __FILE__,__LINE__);
sendMsg("This is a message of level MSG_TYPE_WARNING",MSG_TYPE_WARNING, __FILE__,__LINE__);
sendMsg("This is a message of level MSG_TYPE_ERROR",MSG_TYPE_ERROR, __FILE__,__LINE__);
sendMsg("This is a message of level MSG_TYPE_DEBUG_STREAM",MSG_TYPE_DEBUG_STREAM, __FILE__,__LINE__);
sendMsg("This is a message of level MSG_TYPE_INFO_STREAM",MSG_TYPE_INFO_STREAM, __FILE__,__LINE__);
sendMsg("This is a message of level MSG_TYPE_WARNING_STREAM",MSG_TYPE_WARNING_STREAM, __FILE__,__LINE__);
sendMsg("This is a message of level MSG_TYPE_ERROR_STREAM",MSG_TYPE_ERROR_STREAM, __FILE__,__LINE__);
logger_.countdown();
\endcode
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. As the default value are "" and 0
the counting will be confused.
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-real-time-logger.h deleted 100644 → 0
View file @ db1c58f5
/**
\page subp_debug_rt_logger Real-time Logger
It is intended to be used like this:
\code
#define ENABLE_RT_LOG
#include <dynamic-graph/real-time-logger.h>
// Somewhere in the main function of your executable
int main (int argc, char** argv) {
dgADD_OSTREAM_TO_RTLOG (std::cout);
}
// Somewhere in your library
dgRTLOG() << "your message. Prefer to use \n than std::endl."
\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/debug-trace-doc.h
View file @ 2e7a70d5
......@@ -3,10 +3,10 @@
\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.
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,12 +31,9 @@ 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
......@@ -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,45 +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
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 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
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
......@@ -5,21 +5,24 @@
\subsection use_programmatically General introduction
For control purposes the main use of this package is to create new entities and connect them through signals.
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).
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
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
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:
......@@ -30,13 +33,15 @@ 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
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.
When writing entities you might use some macros which are very useful to write
your class.
\subsection subsec_howto_typedef Entity helpers
......@@ -48,13 +53,13 @@ The header <b>entity-helper.h</b> is defining a type called EntityClassName
<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.
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.
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>
......@@ -64,15 +69,12 @@ The header <b>entity-helper.h</b> is defining a type called EntityClassName
<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
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
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>
......@@ -80,32 +82,24 @@ The header <b>entity-helper.h</b> is defining a type called EntityClassName
<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
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
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
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>
......@@ -113,8 +107,8 @@ The header <b>entity-helper.h</b> is defining a type called EntityClassName
</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:
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
......@@ -124,11 +118,13 @@ The header <b>entity-helper.h</b> is defining a type called EntityClassName
\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.
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.
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,6 +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.
*/