[Rock-dev] What's next in the ruby/typelib bridge
Sylvain Joyeux
sylvain.joyeux at m4x.org
Fri Jan 14 12:42:36 CET 2011
Short explanation
=================
In the near future (read: sometime next week), there will be a *real*
mapping between C++ and Ruby. What it means is that
my_struct.time
will no longer return something that has a #microseconds field, but a
Ruby Time.
In the same way,
rbs.position
will return a Ruby Eigen::Vector3d instead of something that has a #data
field.
And your scripts will be broken, but that's for the best.
When I do this migration, there will be a table on the package directory
pages showing all existing convertions.
Moreover, when using orocos.rb, the types will be made accessible
through Ruby namespaces, i.e. one will be able to do
v = Types::Base::Vector3d.new
instead of Orocos.registry.get('/base/Vector3d').new
Long explanation
================
As some of you may have read
http://rock-robotics.org/runtime/ruby_and_types.html
the Ruby/Typelib bridge has a way to add custom convertion/extensions
for types defined in an oroGen interface. The goal being that we can use
Ruby-defined types to manipulate the types we get to and we write from
Orocos components.
For instance, there is a default convertion to the Ruby Time class. It
means that
laser_sample.time
actually returns a Ruby Time. Which has all the methods you would expect
from a time class (i.e. adding a time and a number, substracting two
times, ...)
In the same way, I developped a small Eigen/Ruby binding that allows you
to have
rigid_body_state.orientation
return a feature-rich Eigen::Quaternion type instead of the basic C++ type.
However, until now, there was two things in place that are going to change.
The first one is that, when I introduced this mechanism, I kept backward
compatiblity. It meant that the value returned by laser_sample.time also
had #seconds and #microseconds methods, so that people could run the
scripts on /base/Time and on the "converted time" too. That's going to
be removed.
The second one is that, until now, the conversion was done "on the fly".
That means that if the Ruby-side Eigen::Vector3d had a normalize!()
method that *changes the vector instance*, then
rigid_body_state.position.normalize();
would actually *not* change the value of rigid_body_state.position. The
reason being that what is being done is
rigid_body_state.position => return copy converted to Eigen::Vector3d
This will be fixed, and made completely transparent. I.e.
rigid_body_state.position
will return always the same Eigen::Vector3d object. Idem for arrays
(converted when accessed) and std::vector (converted to Array).
Moreover, I fixed the "assign Ruby Array to Typelib Array" and "assign
Ruby Array to std::vector" bugs, i.e. will be able to do
my_type.array_of_time = [Time.now, Time.now]
Sylvain
More information about the Rock-dev
mailing list