stack-of-tasks/dynamic-graph-python

Python bindings for dynamic-graph

dynamic-graph-python's Issues

Importing dynamic-graph python modules

When importing python modules, some libraries are in ${prefix}/lib/dynamic-graph-plugin. It forces users to add this directory in the LD_LIBRARY_PATH.
Would it be relevant to scan LD_LIBRARY_PATH in https://github.com/jrl-umi3218/jrl-cmakemodules/blob/master/dynamic_graph/submodule/__init__.py.cmake and to add subdirectories dynamic-graph-plugins to each path?

Fix maintainer name in package.xml

@nim65s following our previous discussion and regarding the current mail from ros building you probably should be the maintainer in the file package.xml

Call to matlab while not being here anymore.

dynamic-graph-python/src/dynamic_graph/script_shortcuts.py

Line 17 in 194cea8

from .matlab import matlab

Python 3

Hi,

This project has been written with PyCObject, which has been deprecated in python 2.7 & 3.1, and removed later, so we must switch to the new Capsules API.

References:
https://docs.python.org/3/howto/cporting.html#cobject-replaced-with-capsule
https://docs.python.org/3.7/extending/extending.html#providing-a-c-api-for-an-extension-module

Remove travis submodule

Dear all,
Travis is now useless as all the tests are done through gitlab.laas.fr
So travis will be removed soon.

Error on commit 45e684e7c ?

Hello

I have a problem with the commit 45e684e.
Because of this commit, I cannot run the kinematic example on romeo https://github.com/laas/sot-dyninv/blob/master/python/ros/ros-kineromeo.py
It crashes with the error:

% go
** On entry to DGESVD parameter number 9 had an illegal value

Reverting this commit suppress this issue though.
Do you mind if I revert it or is there some modification I should apply on the python script to correct this?

BTW: I am testing this on a Ubuntu 12.04 (64 bits) system, python 2.7, ros Fuerte.

François

Python interface for logger verbosity

In C++, it is possible to set an entity's logger verbosity with the method setLoggerVerbosityLevel(LoggerVerbosity). It would be nice to have a Python command for this, in order to be able to set this property easily and dynamically through Python.

Add check that `dg.plug` connects two signals

When using dynamic_graph.plug(a, b), a common bug is to pass an operator for a or b instead of a signal. It would be great if the underlying plug(...) function asserts the passed in objects derive from SignalBase.

Here is a python hack that helped me to track down a plugging bug:

import dynamic_graph as dg
plug_ = dg.plug

# Monkey patch it till you make it.
def dg_plug_dbg(sig0, sig1):
    def assert_signal(sig):
        if not isinstance(sig, dg.signal_base.SignalBase):
            raise ValueError('dynamic_graph.plug(): Passed in value is not a signal. sig=' + str(sig), sig)
    assert_signal(sig0)
    assert_signal(sig1)
    plug_(sig0, sig1)

dg.plug = dg_plug_dbg

\cc @MaximilienNaveau

BOOST_FILESYSTEM_VERSION=2 not supported in boost>=1.50

It seems that the use of BOOST_FILESYSTEM_VERSION 2 is a problem for some install (see http://robotpkg.openrobots.org/rbulk/robotpkg/motion/py-dynamic-graph/index.html#py27-dynamic-graph-2.5.5 for details).
A patch proposes by A. Mallet is the following:

Don't force BOOST_FILESYSTEM_VERSION=2, this is not supported in boost>=1.50

--- CMakeLists.txt~ 2013-03-05 21:54:50.000000000 +0100
+++ CMakeLists.txt 2013-03-08 23:16:10.000000000 +0100
@@ -45,8 +45,9 @@
 # Search for Boost.
 SEARCH_FOR_BOOST()

-# Make sure Boost.Filesystem v2 is used.
-ADD_DEFINITIONS(-DBOOST_FILESYSTEM_VERSION=2)
+# XXX Make sure Boost.Filesystem v2 is used.
+# Boost.Filesystem v2 is not supported anymore
+# ADD_DEFINITIONS(-DBOOST_FILESYSTEM_VERSION=2)

 ADD_SUBDIRECTORY(src)
 ADD_SUBDIRECTORY(include)
=======================================================

Would you let me know if it is ok to insert this patch in the distribution (so that won't be a patch anymore) ? I don't know if that could break something elsewhere... Any commentary and suggestion are very welcome.
Thanks
Aurélie

Redirecting logger stream

In C++, the logger stream can be redirected to any stream through macro dgADD_OSTREAM_TO_RTLOG .
For instance to a file:

  std::ofstream of;
  of.open("/tmp/dg-LOGS.txt",std::ofstream::out|std::ofstream::app);
  dgADD_OSTREAM_TO_RTLOG (of);

Or to std::cout:

dgADD_OSTREAM_TO_RTLOG (std::cout);

It would be nice to have a nice Python interface to exploit this functionality. There is no need of creating bindings for the stream objects themselves. I am thinking of simple methods like logToStdCout(), logToStdCerr() and logToFile(string filename) which will internally take care of the streams.

Release of dynamic-graph-python

Integration of cmake-exports best practices.
Integration in robotpkg

I'll take care of the format issue in another PR

I'll take care of the format issue in another PR

Originally posted by @nim65s in #84 (review)

Python3 embeded python terminal

I found a weird bug using the python3 embeded terminal and the dg_completer.
The interpreter get stuck upon import readline or from rlcompleter import Completer.

It is a shame as the completion is a huge bonus in the client terminal.
This Issue is also in reference to the dynamic-graph-bridge python client of course.

Let me know if there is something I am missing.

Are you using the dynamic-graph-bridge already with python3?
If yes how do you do? (Maybe this question is for dynamic-graph-bridge)
I personnaly did a small C++ client using the ros-service and bound it pybind11.
So I can use ROS in python2 and 3 seemlessly.

Exception on command call.

A command call which used to work is broken by the latest changes (related to Python 3 support).
I get the following error:

  File "/opt/openrobots/lib/python2.7/dist-packages/dynamic_graph/entity.py", line 218, in commandBind
    return wrap.entity_execute_command(self.obj, name, arg)
SystemError: error return without exception set

The arguments are:

• self.obj: a IntegratorEuler object (seen as a dynamic_graph.Entity in Python)
• name: initialize
• arg: an empty tuple.

Any idea of what is going on ?

SignalBase no longer constructable from Python

Hi there,

in our code we used to create new SignalBase for our overloading of python operations 1. With the latest release of dynamic-graph-python the constructor to SignalBase is no longer available from python.

Is there any chance to bring it back to python?

Best,
Julian

\cc @MaximilienNaveau

python history is not working anymore

There is no history anymore.

Bindings of setLoggerVerbosityLevel

The following code snippets

from dynamic_graph.tracer import Tracer
t = Tracer('t')
t.setLoggerVerbosityLevel(0)

gives

SystemError                               Traceback (most recent call last)
SystemError: ../Objects/longobject.c:244: bad argument to internal function

Switching to BSD v2

Dear all,
We will soon switch to BSD License v2.0 to ease our collaborations.
Let me know if there is a problem with this.
Cheers,
Olivier.

Provide basic double, vector and matrix operations on signals

At this point doing basic algebraic operations with signals like adding two vector-signals or slicing a matrix requires using matrix/operator entities from sot-core 1. For convenience it would be great to have basic operators like addition, substraction, multiplication (including matrix-vector products etc) work on the python signals class directly. Like

slider_a = robot.device.slider_values[1] # Return a signal of type double
dg.plug([1, 1] * slider_a, pd.Kp)

etc.

Does this sounds like a good idea? It would required to move the sot-core matrix/operators into this repo.

Update REAMDE.md

Informations in the README.md file should be updated.

Interpreter does not seem multi-threadable

The interpreter cannot handle well the fact that several instances of the method python (https://github.com/stack-of-tasks/dynamic-graph-python/blob/master/src/interpreter.cc#L161-L162) are run simultaneously.

This appears for example when using the rosservice RunCommand
(https://github.com/stack-of-tasks/dynamic_graph_bridge_msgs/blob/master/srv/RunCommand.srv)
at too close range. In this case at some point, the interpreter may crash (with an error difficult to read).

New release

I recommend a new release including the devel branch, so that the new policy of dist-packages vs site-packages is enforced.
devel differs from the current release for two commits only, including the cmake update and some changes concerning sphinx.
Once the release is made, master should be made equal to the release (this is not the case right now).
Together with the new release, it should be checked that the other packages generating Python submodules of dynamic_graph also update their cmake.