Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

Hello,

on a previous e-mail, I asked if anyone has already developed a toolkit for
Eigen types. I had two answers about that.

On on hand, Sylvain Joyeux told me that it was hard with RTT dataflow to
guarantee the alignment required by Eigen types. So, we have to create
intermediate types which are able to translate from Eigen types and so forth
(e.g. [1]).

On the other hand, Tinne De Laet just implemented a toolkit (see [2]) and,
as far I can see, without using intermediate types.

At this time, I just want to clarify the difference between both
alternatives. Could we just push Matrix elements in a property bags when
coding the Corba transport and XML marshalling, or the alignment problem
also arises when just using an Eigen type in a Property, Attribute or Ports
(without corba transport) ?

Sorry for these questions. I'm not very familiar with this alignment problem
and even with RTT dataflow internals. My only goal is to implemented as best
as possible an Eigen toolkit with Corba transport that could be usable by
everyone.

Thank you,

Philippe Hamelin

[1] http://github.com/doudou/base/blob/imoby/base/linear_algebra.h
[2]
http://svn.mech.kuleuven.be/repos/orocos/trunk/kul-ros-pkg/iTaSC/src/eig...

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

On 10/15/2010 03:19 PM, Philippe Hamelin wrote:
> Hello,
>
> on a previous e-mail, I asked if anyone has already developed a toolkit
> for Eigen types. I had two answers about that.
>
> On on hand, Sylvain Joyeux told me that it was hard with RTT dataflow to
> guarantee the alignment required by Eigen types. So, we have to create
> intermediate types which are able to translate from Eigen types and so
> forth (e.g. [1]).
>
> On the other hand, Tinne De Laet just implemented a toolkit (see [2])
> and, as far I can see, without using intermediate types.
>
> At this time, I just want to clarify the difference between both
> alternatives. Could we just push Matrix elements in a property bags when
> coding the Corba transport and XML marshalling, or the alignment problem
> also arises when just using an Eigen type in a Property, Attribute or
> Ports (without corba transport) ?
>
> Sorry for these questions. I'm not very familiar with this alignment
> problem and even with RTT dataflow internals. My only goal is to
> implemented as best as possible an Eigen toolkit with Corba transport
> that could be usable by everyone.

The problem might arise as soon as you put the types on a port,
property, attribute and so on as they get saved into std::vector<>. If
there was no such problem, orogen could handle them without any problem.

Beware: it is not that it never works, but that it is fragile. For
instance, it might work for some data structures but not for others. It
will probably work fine with dynamic matrices. It will work less well on
32bit machines than on 64bit (as the latter "naturally" align on bigger
multiples than the former).

I just had an algorithm that worked fine for a year or so until one of
my colleagues ran it today on 32bit and an "exotic distribution" ... and
hit the misalignment assertion.

I'm thinking about a way to manage that in orogen/typegen where orogen
would autoconvert the eigen-enabled types to valid wrappers at the port
level ... i.e. create a specialization of
RTT::OutputPort<EigenEnabledType> that is actually a
RTT::OutputPort<WrapperType> without asking for user intervention.

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

On Fri, 15 Oct 2010, Sylvain Joyeux wrote:

> On 10/15/2010 03:19 PM, Philippe Hamelin wrote:
>> Hello,
>>
>> on a previous e-mail, I asked if anyone has already developed a toolkit
>> for Eigen types. I had two answers about that.
>>
>> On on hand, Sylvain Joyeux told me that it was hard with RTT dataflow to
>> guarantee the alignment required by Eigen types. So, we have to create
>> intermediate types which are able to translate from Eigen types and so
>> forth (e.g. [1]).
>>
>> On the other hand, Tinne De Laet just implemented a toolkit (see [2])
>> and, as far I can see, without using intermediate types.
>>
>> At this time, I just want to clarify the difference between both
>> alternatives. Could we just push Matrix elements in a property bags when
>> coding the Corba transport and XML marshalling, or the alignment problem
>> also arises when just using an Eigen type in a Property, Attribute or
>> Ports (without corba transport) ?
>>
>> Sorry for these questions. I'm not very familiar with this alignment
>> problem and even with RTT dataflow internals. My only goal is to
>> implemented as best as possible an Eigen toolkit with Corba transport
>> that could be usable by everyone.
>
> The problem might arise as soon as you put the types on a port,
> property, attribute and so on as they get saved into std::vector<>. If
> there was no such problem, orogen could handle them without any problem.
>
> Beware: it is not that it never works, but that it is fragile. For
> instance, it might work for some data structures but not for others. It
> will probably work fine with dynamic matrices. It will work less well on
> 32bit machines than on 64bit (as the latter "naturally" align on bigger
> multiples than the former).
>
> I just had an algorithm that worked fine for a year or so until one of
> my colleagues ran it today on 32bit and an "exotic distribution" ... and
> hit the misalignment assertion.
>
> I'm thinking about a way to manage that in orogen/typegen where orogen
> would autoconvert the eigen-enabled types to valid wrappers at the port
> level ... i.e. create a specialization of
> RTT::OutputPort<EigenEnabledType> that is actually a
> RTT::OutputPort<WrapperType> without asking for user intervention.

Please, don't reinvent the wheel! There are very mature projects around
that solve all these problems, for years already; e.g., NetCDF:
<http://www.unidata.ucar.edu/software/netcdf />
Read these as starters:
<http://www.unidata.ucar.edu/software/netcdf/docs/faq.html#whatisit>
<http://en.wikipedia.org/wiki/Netcdf>
The way they solve it is by introducing a _mathematical model_ layer, that
is agnostic of word sizes, byte alignments, ....
The merger with HFD5 <http://en.wikipedia.org/wiki/HDF5> has been realised.

These things have orders of magnitude more support than we have, have been
matured since more than a decade, so I really see no reason to start doing
the same things again... Do you?

The conversion to specific data types in specific libraries (like Eigen)
should then _first_ (and _only_!) been done towards NetCDF; then NetCDF is
used for transport; and then the data is unpacked from NetCDF to the
specific library that uses that data (need not be Eigen at the other end at
all).

Herman

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

On 10/15/2010 03:54 PM, Herman Bruyninckx wrote:
> On Fri, 15 Oct 2010, Sylvain Joyeux wrote:
>
>> On 10/15/2010 03:19 PM, Philippe Hamelin wrote:
>>> Hello,
>>>
>>> on a previous e-mail, I asked if anyone has already developed a toolkit
>>> for Eigen types. I had two answers about that.
>>>
>>> On on hand, Sylvain Joyeux told me that it was hard with RTT dataflow to
>>> guarantee the alignment required by Eigen types. So, we have to create
>>> intermediate types which are able to translate from Eigen types and so
>>> forth (e.g. [1]).
>>>
>>> On the other hand, Tinne De Laet just implemented a toolkit (see [2])
>>> and, as far I can see, without using intermediate types.
>>>
>>> At this time, I just want to clarify the difference between both
>>> alternatives. Could we just push Matrix elements in a property bags when
>>> coding the Corba transport and XML marshalling, or the alignment problem
>>> also arises when just using an Eigen type in a Property, Attribute or
>>> Ports (without corba transport) ?
>>>
>>> Sorry for these questions. I'm not very familiar with this alignment
>>> problem and even with RTT dataflow internals. My only goal is to
>>> implemented as best as possible an Eigen toolkit with Corba transport
>>> that could be usable by everyone.
>>
>> The problem might arise as soon as you put the types on a port,
>> property, attribute and so on as they get saved into std::vector<>. If
>> there was no such problem, orogen could handle them without any problem.
>>
>> Beware: it is not that it never works, but that it is fragile. For
>> instance, it might work for some data structures but not for others. It
>> will probably work fine with dynamic matrices. It will work less well on
>> 32bit machines than on 64bit (as the latter "naturally" align on bigger
>> multiples than the former).
>>
>> I just had an algorithm that worked fine for a year or so until one of
>> my colleagues ran it today on 32bit and an "exotic distribution" ... and
>> hit the misalignment assertion.
>>
>> I'm thinking about a way to manage that in orogen/typegen where orogen
>> would autoconvert the eigen-enabled types to valid wrappers at the port
>> level ... i.e. create a specialization of
>> RTT::OutputPort<EigenEnabledType> that is actually a
>> RTT::OutputPort<WrapperType> without asking for user intervention.
>
> Please, don't reinvent the wheel! There are very mature projects around
> that solve all these problems, for years already; e.g., NetCDF:
> <http://www.unidata.ucar.edu/software/netcdf />
> Read these as starters:
> <http://www.unidata.ucar.edu/software/netcdf/docs/faq.html#whatisit>
> <http://en.wikipedia.org/wiki/Netcdf>
> The way they solve it is by introducing a _mathematical model_ layer, that
> is agnostic of word sizes, byte alignments, ....
> The merger with HFD5 <http://en.wikipedia.org/wiki/HDF5> has been realised.
>
> These things have orders of magnitude more support than we have, have been
> matured since more than a decade, so I really see no reason to start doing
> the same things again... Do you?
>
> The conversion to specific data types in specific libraries (like Eigen)
> should then _first_ (and _only_!) been done towards NetCDF; then NetCDF is
> used for transport; and then the data is unpacked from NetCDF to the
> specific library that uses that data (need not be Eigen at the other end at
> all).
This whole discussion is not about any form of
marshalling/demarshalling/transport at all. The issue with Eigen is that
eigen types cannot be put on the C++ part of the dataflow BEFORE any
marshalling/demarshalling is done to it.

I personally don't care about the transport, I leave that subject to
other people. I'm trying to reduce the pain of producing the glue code
between the C++ libraries and the transport of choice.

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

2010/10/15 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>

> On 10/15/2010 03:54 PM, Herman Bruyninckx wrote:
>
>> On Fri, 15 Oct 2010, Sylvain Joyeux wrote:
>>
>> On 10/15/2010 03:19 PM, Philippe Hamelin wrote:
>>>
>>>> Hello,
>>>>
>>>> on a previous e-mail, I asked if anyone has already developed a toolkit
>>>> for Eigen types. I had two answers about that.
>>>>
>>>> On on hand, Sylvain Joyeux told me that it was hard with RTT dataflow to
>>>> guarantee the alignment required by Eigen types. So, we have to create
>>>> intermediate types which are able to translate from Eigen types and so
>>>> forth (e.g. [1]).
>>>>
>>>> On the other hand, Tinne De Laet just implemented a toolkit (see [2])
>>>> and, as far I can see, without using intermediate types.
>>>>
>>>> At this time, I just want to clarify the difference between both
>>>> alternatives. Could we just push Matrix elements in a property bags when
>>>> coding the Corba transport and XML marshalling, or the alignment problem
>>>> also arises when just using an Eigen type in a Property, Attribute or
>>>> Ports (without corba transport) ?
>>>>
>>>> Sorry for these questions. I'm not very familiar with this alignment
>>>> problem and even with RTT dataflow internals. My only goal is to
>>>> implemented as best as possible an Eigen toolkit with Corba transport
>>>> that could be usable by everyone.
>>>>
>>>
>>> The problem might arise as soon as you put the types on a port,
>>> property, attribute and so on as they get saved into std::vector<>. If
>>> there was no such problem, orogen could handle them without any problem.
>>>
>>> Beware: it is not that it never works, but that it is fragile. For
>>> instance, it might work for some data structures but not for others. It
>>> will probably work fine with dynamic matrices. It will work less well on
>>> 32bit machines than on 64bit (as the latter "naturally" align on bigger
>>> multiples than the former).
>>>
>>> I just had an algorithm that worked fine for a year or so until one of
>>> my colleagues ran it today on 32bit and an "exotic distribution" ... and
>>> hit the misalignment assertion.
>>>
>>> I'm thinking about a way to manage that in orogen/typegen where orogen
>>> would autoconvert the eigen-enabled types to valid wrappers at the port
>>> level ... i.e. create a specialization of
>>> RTT::OutputPort<EigenEnabledType> that is actually a
>>> RTT::OutputPort<WrapperType> without asking for user intervention.
>>>
>>
>> Please, don't reinvent the wheel! There are very mature projects around
>> that solve all these problems, for years already; e.g., NetCDF:
>> <http://www.unidata.ucar.edu/software/netcdf />
>> Read these as starters:
>> <http://www.unidata.ucar.edu/software/netcdf/docs/faq.html#whatisit>
>> <http://en.wikipedia.org/wiki/Netcdf>
>> The way they solve it is by introducing a _mathematical model_ layer, that
>> is agnostic of word sizes, byte alignments, ....
>> The merger with HFD5 <http://en.wikipedia.org/wiki/HDF5> has been
>> realised.
>>
>> These things have orders of magnitude more support than we have, have been
>> matured since more than a decade, so I really see no reason to start doing
>> the same things again... Do you?
>>
>> The conversion to specific data types in specific libraries (like Eigen)
>> should then _first_ (and _only_!) been done towards NetCDF; then NetCDF is
>> used for transport; and then the data is unpacked from NetCDF to the
>> specific library that uses that data (need not be Eigen at the other end
>> at
>> all).
>>
> This whole discussion is not about any form of
> marshalling/demarshalling/transport at all. The issue with Eigen is that
> eigen types cannot be put on the C++ part of the dataflow BEFORE any
> marshalling/demarshalling is done to it.
>
>
That's what I was to answer. The problem with Eigen is that it doesn't even
work with dataflow on the same address space, so we have anyway to use an
intermediate type. So, the _intelligent_ translation from/to NetCDF has to
be done in all cases, even when using data ports on the same process.

> I personally don't care about the transport, I leave that subject to other
> people. I'm trying to reduce the pain of producing the glue code between the
> C++ libraries and the transport of choice.
>
> --
> Sylvain Joyeux (Dr. Ing.)
> Researcher - Space and Security Robotics
> DFKI Robotics Innovation Center
> Bremen, Robert-Hooke-Straße 5, 28359 Bremen, Germany
>
> Phone: +49 421 218-64136
> Fax: +49 421 218-64150
> Email: sylvain [dot] joyeux [..] ...
>
> Weitere Informationen: http://www.dfki.de
>

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

On Fri, 15 Oct 2010, Philippe Hamelin wrote:

>
> 2010/10/15 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> On 10/15/2010 03:54 PM, Herman Bruyninckx wrote:
> On Fri, 15 Oct 2010, Sylvain Joyeux wrote:
>
> On 10/15/2010 03:19 PM, Philippe Hamelin
> wrote:
> Hello,
>
> on a previous e-mail, I asked if
> anyone has already developed a
> toolkit
> for Eigen types. I had two answers
> about that.
>
> On on hand, Sylvain Joyeux told me
> that it was hard with RTT dataflow
> to
> guarantee the alignment required
> by Eigen types. So, we have to
> create
> intermediate types which are able
> to translate from Eigen types and
> so
> forth (e.g. [1]).
>
> On the other hand, Tinne De Laet
> just implemented a toolkit (see
> [2])
> and, as far I can see, without
> using intermediate types.
>
> At this time, I just want to
> clarify the difference between
> both
> alternatives. Could we just push
> Matrix elements in a property bags
> when
> coding the Corba transport and XML
> marshalling, or the alignment
> problem
> also arises when just using an
> Eigen type in a Property,
> Attribute or
> Ports (without corba transport) ?
>
> Sorry for these questions. I'm not
> very familiar with this alignment
> problem and even with RTT dataflow
> internals. My only goal is to
> implemented as best as possible an
> Eigen toolkit with Corba transport
> that could be usable by everyone.
>
>
> The problem might arise as soon as you put the
> types on a port,
> property, attribute and so on as they get
> saved into std::vector<>. If
> there was no such problem, orogen could handle
> them without any problem.
>
> Beware: it is not that it never works, but
> that it is fragile. For
> instance, it might work for some data
> structures but not for others. It
> will probably work fine with dynamic matrices.
> It will work less well on
> 32bit machines than on 64bit (as the latter
> "naturally" align on bigger
> multiples than the former).
>
> I just had an algorithm that worked fine for a
> year or so until one of
> my colleagues ran it today on 32bit and an
> "exotic distribution" ... and
> hit the misalignment assertion.
>
> I'm thinking about a way to manage that in
> orogen/typegen where orogen
> would autoconvert the eigen-enabled types to
> valid wrappers at the port
> level ... i.e. create a specialization of
> RTT::OutputPort<EigenEnabledType> that is
> actually a
> RTT::OutputPort<WrapperType> without asking
> for user intervention.
>
>
> Please, don't reinvent the wheel! There are very mature
> projects around
> that solve all these problems, for years already; e.g.,
> NetCDF:
> <http://www.unidata.ucar.edu/software/netcdf />
> Read these as starters:
> <http://www.unidata.ucar.edu/software/netcdf/docs/faq.html#whatisit>
> <http://en.wikipedia.org/wiki/Netcdf>
> The way they solve it is by introducing a _mathematical
> model_ layer, that
> is agnostic of word sizes, byte alignments, ....
> The merger with HFD5 <http://en.wikipedia.org/wiki/HDF5>
> has been realised.
>
> These things have orders of magnitude more support than we
> have, have been
> matured since more than a decade, so I really see no
> reason to start doing
> the same things again... Do you?
>
> The conversion to specific data types in specific
> libraries (like Eigen)
> should then _first_ (and _only_!) been done towards
> NetCDF; then NetCDF is
> used for transport; and then the data is unpacked from
> NetCDF to the
> specific library that uses that data (need not be Eigen at
> the other end at
> all).
>
> This whole discussion is not about any form of
> marshalling/demarshalling/transport at all. The issue with Eigen is
> that eigen types cannot be put on the C++ part of the dataflow BEFORE
> any marshalling/demarshalling is done to it.
>
> That's what I was to answer. The problem with Eigen is that it doesn't even
> work with dataflow on the same address space, so we have anyway to use an
> intermediate type. So, the _intelligent_ translation from/to NetCDF has to
> be done in all cases, even when using data ports on the same process.

Fine! Which makes the "NetCDF approach" even more relevant. Or am I still
missing something? :-)

> I personally don't care about the transport, I leave that
> subject to other people. I'm trying to reduce the pain of
> producing the glue code between the C++ libraries and the
> transport of choice.

Wouldn't it be possible to solve both problems at the same time? Because,
from the point of view of an algorithm that uses Eigen, the glue code
translation towards C++ has the same challenges as the one to translate to
a "communication middleware".

Herman

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

Hi,

Sylvain, may you explain more in detail what you are saying about misalignment
assertion, I have a lot of difficulties to handle it...

I don't know Eigen, but I made several toolkits in for rtt 1.8.

What I had understand is:

Rtt-toolkit :
1. Converts type to propertyBag and vice-versa
2. Output type to the console

Corba Toolkit:
1. Converts to Corba type in order to transport it over the network

>From what I saw and understand, I see no reason why misalignement appears
using toolkit. The reason why I'm saying this is because :
1. Attribute,Property,DataPort uses Copy constructor that are defined by
eigen

I may see reason about crashes or misalignements.
The problem can happen because of thread-safety problems on
attributes,Properties. May you try somethings like this :

Property<string> myprop("name", "description",
AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
) ) ;

I think that we are hiding a "thread safety problem" with wrapper class.

Simon

On Fri, Oct 15, 2010 at 10:53 AM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:

> On Fri, 15 Oct 2010, Philippe Hamelin wrote:
>
> >
> > 2010/10/15 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> > On 10/15/2010 03:54 PM, Herman Bruyninckx wrote:
> > On Fri, 15 Oct 2010, Sylvain Joyeux wrote:
> >
> > On 10/15/2010 03:19 PM, Philippe Hamelin
> > wrote:
> > Hello,
> >
> > on a previous e-mail, I asked if
> > anyone has already developed a
> > toolkit
> > for Eigen types. I had two answers
> > about that.
> >
> > On on hand, Sylvain Joyeux told me
> > that it was hard with RTT dataflow
> > to
> > guarantee the alignment required
> > by Eigen types. So, we have to
> > create
> > intermediate types which are able
> > to translate from Eigen types and
> > so
> > forth (e.g. [1]).
> >
> > On the other hand, Tinne De Laet
> > just implemented a toolkit (see
> > [2])
> > and, as far I can see, without
> > using intermediate types.
> >
> > At this time, I just want to
> > clarify the difference between
> > both
> > alternatives. Could we just push
> > Matrix elements in a property bags
> > when
> > coding the Corba transport and XML
> > marshalling, or the alignment
> > problem
> > also arises when just using an
> > Eigen type in a Property,
> > Attribute or
> > Ports (without corba transport) ?
> >
> > Sorry for these questions. I'm not
> > very familiar with this alignment
> > problem and even with RTT dataflow
> > internals. My only goal is to
> > implemented as best as possible an
> > Eigen toolkit with Corba transport
> > that could be usable by everyone.
> >
> >
> > The problem might arise as soon as you put the
> > types on a port,
> > property, attribute and so on as they get
> > saved into std::vector<>. If
> > there was no such problem, orogen could handle
> > them without any problem.
> >
> > Beware: it is not that it never works, but
> > that it is fragile. For
> > instance, it might work for some data
> > structures but not for others. It
> > will probably work fine with dynamic matrices.
> > It will work less well on
> > 32bit machines than on 64bit (as the latter
> > "naturally" align on bigger
> > multiples than the former).
> >
> > I just had an algorithm that worked fine for a
> > year or so until one of
> > my colleagues ran it today on 32bit and an
> > "exotic distribution" ... and
> > hit the misalignment assertion.
> >
> > I'm thinking about a way to manage that in
> > orogen/typegen where orogen
> > would autoconvert the eigen-enabled types to
> > valid wrappers at the port
> > level ... i.e. create a specialization of
> > RTT::OutputPort<EigenEnabledType> that is
> > actually a
> > RTT::OutputPort<WrapperType> without asking
> > for user intervention.
> >
> >
> > Please, don't reinvent the wheel! There are very mature
> > projects around
> > that solve all these problems, for years already; e.g.,
> > NetCDF:
> > <http://www.unidata.ucar.edu/software/netcdf />
> > Read these as starters:
> > <
> http://www.unidata.ucar.edu/software/netcdf/docs/faq.html#whatisit>
> > <http://en.wikipedia.org/wiki/Netcdf>
> > The way they solve it is by introducing a _mathematical
> > model_ layer, that
> > is agnostic of word sizes, byte alignments, ....
> > The merger with HFD5 <http://en.wikipedia.org/wiki/HDF5>
> > has been realised.
> >
> > These things have orders of magnitude more support than we
> > have, have been
> > matured since more than a decade, so I really see no
> > reason to start doing
> > the same things again... Do you?
> >
> > The conversion to specific data types in specific
> > libraries (like Eigen)
> > should then _first_ (and _only_!) been done towards
> > NetCDF; then NetCDF is
> > used for transport; and then the data is unpacked from
> > NetCDF to the
> > specific library that uses that data (need not be Eigen at
> > the other end at
> > all).
> >
> > This whole discussion is not about any form of
> > marshalling/demarshalling/transport at all. The issue with Eigen is
> > that eigen types cannot be put on the C++ part of the dataflow BEFORE
> > any marshalling/demarshalling is done to it.
> >
> > That's what I was to answer. The problem with Eigen is that it doesn't
> even
> > work with dataflow on the same address space, so we have anyway to use an
> > intermediate type. So, the _intelligent_ translation from/to NetCDF has
> to
> > be done in all cases, even when using data ports on the same process.
>
> Fine! Which makes the "NetCDF approach" even more relevant. Or am I still
> missing something? :-)
>
> > I personally don't care about the transport, I leave that
> > subject to other people. I'm trying to reduce the pain of
> > producing the glue code between the C++ libraries and the
> > transport of choice.
>
> Wouldn't it be possible to solve both problems at the same time? Because,
> from the point of view of an algorithm that uses Eigen, the glue code
> translation towards C++ has the same challenges as the one to translate to
> a "communication middleware".
>
> Herman
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
> I may see reason about crashes or misalignements.
> The problem can happen because of thread-safety problems on
> attributes,Properties. May you try somethings like this :
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> I think that we are hiding a "thread safety problem" with wrapper class.
Thread safey has nothing to do with it. When you write a property, port,
..., the data sample gets stored somewhere. Therefore, you would need a
way to ensure that the eigen-enabled types get properly aligned when
they get "stored" in these storage objects.

For some of the storage, they are members of the class (i.e. one would
need the storage object to have EIGEN_MAKE_ALIGNED or something), for
others they are std::vector -- would need to use the eigen wrappers for
vector alignment.

In neither cases did I find a good way to robustly ensure that the
alignment requirements are met.

However, forcing the use of smart pointers for every eigen-enabled types
would actually work. But I personally don't feel it is a viable solution
either.

Sylvain

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?

Plugin/Toolkit for Eigen2 or Eigen3 types [revisited]

>
> On 10/18/2010 03:29 PM, Simon Pelletier-Thibault wrote:
>
>
> Property<string> myprop("name", "description",
> AssignableDataSource<string>::shared_ptr(new DataObjectLocked<string>("name")
> ) ) ;
>
> Sorry for that newbie question, but does someone can give me a brief
explanation of how this line can make the Property thread-safe?