Merging new branches in Orocos Toolchain/master branches

Submitted by peter on Tue, 2011-07-05 10:56

RTT-dev

I'm going to merge new stuff into master, causing an effective deviation from
the toolchain-2.4 branches and preparing 2.5.

For RTT, these topics are for merge:

- Use IS_ROS_PACKAGE macro instead of ROS_ROOT in useorocos.cmake macros. This
will fix building RTT,OCL, etc in non-ros package trees on systems where ROS is
installed and autoproj is used

- Removing the RTT::internal::Signal from ports. You'll be able to register
only one callback to a port, and the getNewDataEvent() function is gone. This
gives us a 10% reduction in code size and compensates the 2.3->2.4 regression
(but doesn't fix it !)

- Merge type primitives branch. This allows typekits to choose if a type is a
'full' type or a 'primitive' type. A primitive type can not be sent over a flow
port, for example, all int_xy_t types and sequence [] types in ROS-like
environments. This will reduce the compilation time of ROS typekits by about
30%. The ros typekits need to be adapted to use these new type info classes.

- Add support for fixed size arrays in the type system. ROS typekits need this
with fixed size messages.

- I also succeeded in building RTT + omniorb with clang 2.9

- We will also create an orocos_toolchain.git repository which has all the
orocos toolchain git repos as submodules.

I'm also looking at these branches, please reply with OK or comment if it is
for merging:
- snrkiwi/toolchain-next
- phamelin/v2.3.1-sm-win32-fixes
- lua stuff from markus, possible fixes for the type system not being able to
handle types as reported on the ML

For the other repositories, take a look at the master-ros-refactoring, which
changes how packages are built in ROS, using the same layout as autoproj.
These will be merged in their respective master branches as well.

I'm also a bit worried about all the tooling going on, being announced on the
ML and then not being included in releases, and not being easily found on the
website. We need a system similar/identical to the ROS package trees for
tracking this content. I wonder how easy it would be to (literally) copy the
ROS infrastructure and add 'Orocos' package repositories. We could also talk
to the ROS guys and ask them how they feel about it... using their
infrastructure directly (with an Orocos logo/branding) or copying it to our
own servers...

I looked at the rock package directory, but I'm missing the concepts of a
stack and a wiki to online edit the documentation. It would be neat if the
rock package directory could be part of this scheme though.

Peter

Re: Merging new branches in Orocos Toolchain/master branches

Submitted by Polch on Wed, 2011-07-13 16:23.

peter wrote:

- We will also create an orocos_toolchain.git repository which has all the orocos toolchain git repos as submodules.

Hello.

I try to manage my project with submodules and it's a bit tricky IMHO.

I know that Sylvain works on autoproj and i would like to ask him if he plan to integrate the submodule feature ?

At the first clone of a repository, there should not be too many problems.

But when we need to update, i see some differents options : (1) the user don't make any changes int the project

   (1-1) the sub-modules only update if they are indexed by the super-module :
          git pull
          git submodule update
   (1-2) the sub-modules should be updated even if the super-module isn't updated :
          git submodule foreach checkout master
          git submodule update

(2) the user is a developer and will make some changes use --rebase or --merge with submodule update ?

I don't find any good documentation that explain the submodules workflow with git (i find only complains on its usage...).

How will you use this feature ?

Merging new branches in Orocos Toolchain/master branches

Submitted by Charles Lesire-... on Wed, 2011-07-13 07:36.

2011/7/5 Peter Soetens <peter [..] ...>

good!

>
> - Removing the RTT::internal::Signal from ports. You'll be able to register
> only one callback to a port, and the getNewDataEvent() function is gone.
> This
> gives us a 10% reduction in code size and compensates the 2.3->2.4
> regression
> (but doesn't fix it !)
>
> - Merge type primitives branch. This allows typekits to choose if a type is
> a
> 'full' type or a 'primitive' type. A primitive type can not be sent over a
> flow
> port, for example, all int_xy_t types and sequence [] types in ROS-like
> environments. This will reduce the compilation time of ROS typekits by
> about
> 30%. The ros typekits need to be adapted to use these new type info
> classes.
>
> - Add support for fixed size arrays in the type system. ROS typekits need
> this
> with fixed size messages.
>

Have you started this development? At Onera, we have a a typekit for
std::array ; maybe I could discuss with Paul whether it could be released on
the Orocos-Toolchain project...

>
> - I also succeeded in building RTT + omniorb with clang 2.9
>
> - We will also create an orocos_toolchain.git repository which has all the
> orocos toolchain git repos as submodules.
>

Why do you want to do that? Is this related to the Orocos ROS stack?

Charles.

Merging new branches in Orocos Toolchain/master branches

Submitted by Sylvain Joyeux on Tue, 2011-07-12 09:24.

On 07/05/2011 12:54 PM, Peter Soetens wrote:
> I'm also a bit worried about all the tooling going on, being announced on the
> ML and then not being included in releases, and not being easily found on the
> website. We need a system similar/identical to the ROS package trees for
> tracking this content.
Could you be more specific as to what you are talking about ?

> I wonder how easy it would be to (literally) copy the
> ROS infrastructure and add 'Orocos' package repositories. We could also talk
> to the ROS guys and ask them how they feel about it... using their
> infrastructure directly (with an Orocos logo/branding) or copying it to our
> own servers...
The issue I have with the ROS infrastructure (and the reason why the
rock documentation is generated statically) is that you *need* a server.
Having been away for a whole week on the field, I can tell you that this
is NOT practical.

> I looked at the rock package directory, but I'm missing the concepts of a
> stack and a wiki to online edit the documentation. It would be neat if the
> rock package directory could be part of this scheme though.
The "concept" of a stack always eluded me. The closest autoproj has
about stacks are autoproj package sets. The next autoproj version will
also allow to group packages on a finer-grained basis that the package
sets themselves.

Merging new branches in Orocos Toolchain/master branches

Submitted by willy on Tue, 2011-07-12 09:32.

2011/7/12 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>

> On 07/05/2011 12:54 PM, Peter Soetens wrote:
> > I'm also a bit worried about all the tooling going on, being announced on
> the
> > ML and then not being included in releases, and not being easily found on
> the
> > website. We need a system similar/identical to the ROS package trees for
> > tracking this content.
> Could you be more specific as to what you are talking about ?
>
> > I wonder how easy it would be to (literally) copy the
> > ROS infrastructure and add 'Orocos' package repositories. We could also
> talk
> > to the ROS guys and ask them how they feel about it... using their
> > infrastructure directly (with an Orocos logo/branding) or copying it to
> our
> > own servers...
> The issue I have with the ROS infrastructure (and the reason why the
> rock documentation is generated statically) is that you *need* a server.
> Having been away for a whole week on the field, I can tell you that this
> is NOT practical.
>
> > I looked at the rock package directory, but I'm missing the concepts of a
> > stack and a wiki to online edit the documentation. It would be neat if
> the
> > rock package directory could be part of this scheme though.
> The "concept" of a stack always eluded me.

If I understood it correctly, a stack would be equivalent to an Orocos
"distribution" of component (includes src, docs, bin, ...), in the sense
that it's someone choosing a collection of usefull packages for a particular
purpose.

> The closest autoproj has
> about stacks are autoproj package sets. The next autoproj version will
> also allow to group packages on a finer-grained basis that the package
> sets themselves.
> --
> Sylvain Joyeux (Dr.Ing.)
> Space & Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

Merging new branches in Orocos Toolchain/master branches

Submitted by Sylvain Joyeux on Tue, 2011-07-12 09:36.

On 07/12/2011 11:28 AM, Willy Lambert wrote:
>
>
> 2011/7/12 Sylvain Joyeux <sylvain [dot] joyeux [..] ...
> <mailto:sylvain [dot] joyeux [..] ...>>
>
> On 07/05/2011 12:54 PM, Peter Soetens wrote:
> > I'm also a bit worried about all the tooling going on, being
> announced on the
> > ML and then not being included in releases, and not being easily
> found on the
> > website. We need a system similar/identical to the ROS package
> trees for
> > tracking this content.
> Could you be more specific as to what you are talking about ?
>
> > I wonder how easy it would be to (literally) copy the
> > ROS infrastructure and add 'Orocos' package repositories. We
> could also talk
> > to the ROS guys and ask them how they feel about it... using their
> > infrastructure directly (with an Orocos logo/branding) or copying
> it to our
> > own servers...
> The issue I have with the ROS infrastructure (and the reason why the
> rock documentation is generated statically) is that you *need* a server.
> Having been away for a whole week on the field, I can tell you that this
> is NOT practical.
>
> > I looked at the rock package directory, but I'm missing the
> concepts of a
> > stack and a wiki to online edit the documentation. It would be
> neat if the
> > rock package directory could be part of this scheme though.
> The "concept" of a stack always eluded me.
>
>
> If I understood it correctly, a stack would be equivalent to an Orocos
> "distribution" of component (includes src, docs, bin, ...), in the sense
> that it's someone choosing a collection of usefull packages for a
> particular purpose.
But we do agree that a single package could (and probably "should"), in
principle, be part of multiple stacks ?

Sylvain

Merging new branches in Orocos Toolchain/master branches

Submitted by willy on Tue, 2011-07-12 09:40.

2011/7/12 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>

> On 07/12/2011 11:28 AM, Willy Lambert wrote:
>
>>
>>
>> 2011/7/12 Sylvain Joyeux <sylvain [dot] joyeux [..] ...
>> <mailto:sylvain [dot] joyeux [..] ...**>>
>>
>>
>> On 07/05/2011 12:54 PM, Peter Soetens wrote:
>> > I'm also a bit worried about all the tooling going on, being
>> announced on the
>> > ML and then not being included in releases, and not being easily
>> found on the
>> > website. We need a system similar/identical to the ROS package
>> trees for
>> > tracking this content.
>> Could you be more specific as to what you are talking about ?
>>
>> > I wonder how easy it would be to (literally) copy the
>> > ROS infrastructure and add 'Orocos' package repositories. We
>> could also talk
>> > to the ROS guys and ask them how they feel about it... using their
>> > infrastructure directly (with an Orocos logo/branding) or copying
>> it to our
>> > own servers...
>> The issue I have with the ROS infrastructure (and the reason why the
>> rock documentation is generated statically) is that you *need* a
>> server.
>> Having been away for a whole week on the field, I can tell you that
>> this
>> is NOT practical.
>>
>> > I looked at the rock package directory, but I'm missing the
>> concepts of a
>> > stack and a wiki to online edit the documentation. It would be
>> neat if the
>> > rock package directory could be part of this scheme though.
>> The "concept" of a stack always eluded me.
>>
>>
>> If I understood it correctly, a stack would be equivalent to an Orocos
>> "distribution" of component (includes src, docs, bin, ...), in the sense
>> that it's someone choosing a collection of usefull packages for a
>> particular purpose.
>>
> But we do agree that a single package could (and probably "should"), in
> principle, be part of multiple stacks ?
>

For ROS it's the case. When you use it for your robot you'll probably create
your own stack with required packages. But it also happens that you take
premade stacks nexts to your own stack, and then it is a "ros distribution"
like is Diamondback, (the current "official" version).

Then the distinction beetween stacks and distribution is just for human
organization (afaik, i may be wrong on this). It would be a terrible mess if
you had all your packages in the same folder

>
> Sylvain
>

Merging new branches in Orocos Toolchain/master branches

Submitted by Sylvain Joyeux on Tue, 2011-07-12 09:44.

On 07/12/2011 11:38 AM, Willy Lambert wrote:
>
>
> 2011/7/12 Sylvain Joyeux <sylvain [dot] joyeux [..] ...
> <mailto:sylvain [dot] joyeux [..] ...>>
>
> On 07/12/2011 11:28 AM, Willy Lambert wrote:
>
>
>
> 2011/7/12 Sylvain Joyeux <sylvain [dot] joyeux [..] ...
> <mailto:sylvain [dot] joyeux [..] ...>
> <mailto:sylvain [dot] joyeux [..] ... sylvain [dot] joyeux [..] ...>__>>
>
>
> On 07/05/2011 12:54 PM, Peter Soetens wrote:
> > I'm also a bit worried about all the tooling going on, being
> announced on the
> > ML and then not being included in releases, and not being easily
> found on the
> > website. We need a system similar/identical to the ROS package
> trees for
> > tracking this content.
> Could you be more specific as to what you are talking about ?
>
> > I wonder how easy it would be to (literally) copy the
> > ROS infrastructure and add 'Orocos' package repositories. We
> could also talk
> > to the ROS guys and ask them how they feel about it... using
> their
> > infrastructure directly (with an Orocos logo/branding) or copying
> it to our
> > own servers...
> The issue I have with the ROS infrastructure (and the reason
> why the
> rock documentation is generated statically) is that you
> *need* a server.
> Having been away for a whole week on the field, I can tell
> you that this
> is NOT practical.
>
> > I looked at the rock package directory, but I'm missing the
> concepts of a
> > stack and a wiki to online edit the documentation. It would be
> neat if the
> > rock package directory could be part of this scheme though.
> The "concept" of a stack always eluded me.
>
>
> If I understood it correctly, a stack would be equivalent to an
> Orocos
> "distribution" of component (includes src, docs, bin, ...), in
> the sense
> that it's someone choosing a collection of usefull packages for a
> particular purpose.
>
> But we do agree that a single package could (and probably "should"),
> in principle, be part of multiple stacks ?
>
>
> For ROS it's the case. When you use it for your robot you'll probably
> create your own stack with required packages.
Said package is then built multiple times ? Or does ROS detect that it
is shared and builds it only once ?

> But it also happens that
> you take premade stacks nexts to your own stack, and then it is a "ros
> distribution" like is Diamondback, (the current "official" version).
In practice, in autoproj at DFKI, this happens naturally through
dependencies. People do is "well, I need to do this and that". They
select the packages they want to test in their manifest (and only that)
and autoproj takes care of installing the rest.

Now, as far as I understood, Peter's point was not so much about the
build part, but about the documentation (finding out what exists). Or am
I wrong, Peter ?

Merging new branches in Orocos Toolchain/master branches

Submitted by peter on Tue, 2011-07-12 12:32.

On Tuesday 12 July 2011 11:42:51 Sylvain Joyeux wrote:
> On 07/12/2011 11:38 AM, Willy Lambert wrote:
> > 2011/7/12 Sylvain Joyeux <sylvain [dot] joyeux [..] ...
> > <mailto:sylvain [dot] joyeux [..] ...>>
> >
> > On 07/12/2011 11:28 AM, Willy Lambert wrote:
> > 2011/7/12 Sylvain Joyeux <sylvain [dot] joyeux [..] ...
> > <mailto:sylvain [dot] joyeux [..] ...>
> > <mailto:sylvain [dot] joyeux [..] ...
> > <mailto:sylvain [dot] joyeux [..] ...>__>>
> >
> > On 07/05/2011 12:54 PM, Peter Soetens wrote:
> > > I'm also a bit worried about all the tooling going on, being
> > >
> > announced on the
> > >
> > > ML and then not being included in releases, and not being
> > > easily
> > >
> > found on the
> > >
> > > website. We need a system similar/identical to the ROS package
> > >
> > trees for
> > >
> > > tracking this content.
> > >
> > Could you be more specific as to what you are talking about ?
> > >
> > > I wonder how easy it would be to (literally) copy the
> > > ROS infrastructure and add 'Orocos' package repositories. We
> > >
> > could also talk
> > >
> > > to the ROS guys and ask them how they feel about it... using
> >
> > their
> >
> > > infrastructure directly (with an Orocos logo/branding) or
> > > copying
> > >
> > it to our
> > >
> > > own servers...
> > >
> > The issue I have with the ROS infrastructure (and the reason
> >
> > why the
> >
> > rock documentation is generated statically) is that you
> >
> > *need* a server.
> >
> > Having been away for a whole week on the field, I can tell
> >
> > you that this
> >
> > is NOT practical.
> > >
> > > I looked at the rock package directory, but I'm missing the
> > >
> > concepts of a
> > >
> > > stack and a wiki to online edit the documentation. It would be
> > >
> > neat if the
> > >
> > > rock package directory could be part of this scheme though.
> > >
> > The "concept" of a stack always eluded me.
> >
> > If I understood it correctly, a stack would be equivalent to an
> > Orocos
> > "distribution" of component (includes src, docs, bin, ...), in
> > the sense
> > that it's someone choosing a collection of usefull packages for a
> > particular purpose.
> >
> > But we do agree that a single package could (and probably "should"),
> > in principle, be part of multiple stacks ?
> >
> > For ROS it's the case. When you use it for your robot you'll probably
> > create your own stack with required packages.
>
> Said package is then built multiple times ? Or does ROS detect that it
> is shared and builds it only once ?

Willy is wrong. In ROS, a package belongs to one stack only. A stack is a
*very* thin concept: it 'names' a group packages. The stack is used to 1)
group the packages wrt documentation; the stack documents the group and then
you can click through to each package and 2) to release all packages together,
ie, they are dependent on each other and it's easier to release them at the
same time&give them the same version number. A ROS package does not have a
version number, a ros stack does (See the CMakeLists.txt file for the version
number next to the stack.xml file).

>
> > But it also happens that
> > you take premade stacks nexts to your own stack, and then it is a "ros
> > distribution" like is Diamondback, (the current "official" version).
>
> In practice, in autoproj at DFKI, this happens naturally through
> dependencies. People do is "well, I need to do this and that". They
> select the packages they want to test in their manifest (and only that)
> and autoproj takes care of installing the rest.
>
> Now, as far as I understood, Peter's point was not so much about the
> build part, but about the documentation (finding out what exists). Or am
> I wrong, Peter ?

You're right. I was worried about generating and finding documentation. The ROS
guys only need to add/put a single repository URL into a hudson job and
everything is automated from there on.

Peter

Merging new branches in Orocos Toolchain/master branches

Submitted by Sylvain Joyeux on Tue, 2011-07-12 15:52.

On 07/12/2011 02:31 PM, Peter Soetens wrote:
>> Said package is then built multiple times ? Or does ROS detect that it
>> is shared and builds it only once ?
>
> Willy is wrong. In ROS, a package belongs to one stack only. A stack is a
> *very* thin concept: it 'names' a group packages.
So, that would be related to the metapackage stuff (which I would be
happy to rename to stacks if it makes other people happy).

> The stack is used to 1)
> group the packages wrt documentation; the stack documents the group and then
> you can click through to each package
Already the case for package sets, will be generalized with metapackages

> and 2) to release all packages together,
> ie, they are dependent on each other and it's easier to release them at the
> same time&give them the same version number.
Yeeaaah. That's what package sets are about as well. Set of packages
maintained by a person/group, that goes updated together.

> A ROS package does not have a
> version number, a ros stack does (See the CMakeLists.txt file for the version
> number next to the stack.xml file).
Could version package sets / metapackages if that makes version-happy
people happier.

>>> But it also happens that
>>> you take premade stacks nexts to your own stack, and then it is a "ros
>>> distribution" like is Diamondback, (the current "official" version).
>>
>> In practice, in autoproj at DFKI, this happens naturally through
>> dependencies. People do is "well, I need to do this and that". They
>> select the packages they want to test in their manifest (and only that)
>> and autoproj takes care of installing the rest.
>>
>> Now, as far as I understood, Peter's point was not so much about the
>> build part, but about the documentation (finding out what exists). Or am
>> I wrong, Peter ?
>
> You're right. I was worried about generating and finding documentation. The ROS
> guys only need to add/put a single repository URL into a hudson job and
> everything is automated from there on.
So is the rock package directory. One thing I was planning to add is
that packages can have a doc/ directory with markdown files, that would
get integrated into the package directory (I liked that better than a
wiki, as the documentation is always coming with the package). Moreover,
I want to relayout the package directory to make it easier to find stuff.

Merging new branches in Orocos Toolchain/master branches

Submitted by Sylvain Joyeux on Tue, 2011-07-12 09:32.

On 07/12/2011 11:22 AM, Sylvain Joyeux wrote:
>> I wonder how easy it would be to (literally) copy the
>> ROS infrastructure and add 'Orocos' package repositories. We could also talk
>> to the ROS guys and ask them how they feel about it... using their
>> infrastructure directly (with an Orocos logo/branding) or copying it to our
>> own servers...
> The issue I have with the ROS infrastructure (and the reason why the
> rock documentation is generated statically) is that you *need* a server.
> Having been away for a whole week on the field, I can tell you that this
> is NOT practical.
On an implementation point of view, the rock package set is first
generated into a minimal markup language (markdown) and then generated
using webgen. If your wiki implementation allows to load markdown from
files, then you have your wiki integration.

Merging new branches in Orocos Toolchain/master branches

Submitted by Charles Lesire-... on Thu, 2011-07-07 10:24.

2011/7/5 Peter Soetens <peter [..] ...>

> I'm going to merge new stuff into master, causing an effective deviation
> from
> the toolchain-2.4 branches and preparing 2.5.
>
> For RTT, these topics are for merge:
>
> - Use IS_ROS_PACKAGE macro instead of ROS_ROOT in useorocos.cmake macros.
> This
> will fix building RTT,OCL, etc in non-ros package trees on systems where
> ROS is
> installed and autoproj is used
>
> - Removing the RTT::internal::Signal from ports. You'll be able to register
> only one callback to a port, and the getNewDataEvent() function is gone.
> This
> gives us a 10% reduction in code size and compensates the 2.3->2.4
> regression
> (but doesn't fix it !)
>
> - Merge type primitives branch. This allows typekits to choose if a type is
> a
> 'full' type or a 'primitive' type. A primitive type can not be sent over a
> flow
> port, for example, all int_xy_t types and sequence [] types in ROS-like
> environments. This will reduce the compilation time of ROS typekits by
> about
> 30%. The ros typekits need to be adapted to use these new type info
> classes.
>
> - Add support for fixed size arrays in the type system. ROS typekits need
> this
> with fixed size messages.
>
> - I also succeeded in building RTT + omniorb with clang 2.9
>
> - We will also create an orocos_toolchain.git repository which has all the
> orocos toolchain git repos as submodules.
>
> I'm also looking at these branches, please reply with OK or comment if it
> is
> for merging:
> - snrkiwi/toolchain-next
> - phamelin/v2.3.1-sm-win32-fixes
> - lua stuff from markus, possible fixes for the type system not being able
> to
> handle types as reported on the ML
>
> For the other repositories, take a look at the master-ros-refactoring,
> which
> changes how packages are built in ROS, using the same layout as autoproj.
> These will be merged in their respective master branches as well.
>
> I'm also a bit worried about all the tooling going on, being announced on
> the
> ML and then not being included in releases, and not being easily found on
> the
> website. We need a system similar/identical to the ROS package trees for
> tracking this content. I wonder how easy it would be to (literally) copy
> the
> ROS infrastructure and add 'Orocos' package repositories. We could also
> talk
> to the ROS guys and ask them how they feel about it... using their
> infrastructure directly (with an Orocos logo/branding) or copying it to our
> own servers...
>
> I looked at the rock package directory, but I'm missing the concepts of a
> stack and a wiki to online edit the documentation. It would be neat if the
> rock package directory could be part of this scheme though.
>
>

What about the stdint-typekit package: do you plan to integrate it to the
toolchain-2.5 release?
It is not extensively tested...

Charles.

Merging new branches in Orocos Toolchain/master branches

Submitted by peter on Thu, 2011-07-07 10:36.

On Thu, Jul 7, 2011 at 12:23 PM, Charles Lesire-Cabaniols
<charles [dot] lesire [..] ...> wrote:
>
>
> 2011/7/5 Peter Soetens <peter [..] ...>
>>
>> I'm going to merge new stuff into master, causing an effective deviation
>> from
>> the toolchain-2.4 branches and preparing 2.5.
>>
>> For RTT, these topics are for merge:
>>
>> - Use IS_ROS_PACKAGE macro instead of ROS_ROOT in useorocos.cmake macros.
>> This
>> will fix building RTT,OCL, etc in non-ros package trees on systems where
>> ROS is
>> installed and autoproj is used
>>
>> - Removing the RTT::internal::Signal from ports. You'll be able to
>> register
>> only one callback to a port, and the getNewDataEvent() function is gone.
>> This
>> gives us a 10% reduction in code size and compensates the 2.3->2.4
>> regression
>> (but doesn't fix it !)
>>
>> - Merge type primitives branch. This allows typekits to choose if a type
>> is a
>> 'full' type or a 'primitive' type. A primitive type can not be sent over a
>> flow
>> port, for example, all int_xy_t types and sequence [] types in ROS-like
>> environments. This will reduce the compilation time of ROS typekits by
>> about
>> 30%. The ros typekits need to be adapted to use these new type info
>> classes.
>>
>> - Add support for fixed size arrays in the type system. ROS typekits need
>> this
>> with fixed size messages.
>>
>> - I also succeeded in building RTT + omniorb with clang 2.9
>>
>> - We will also create an orocos_toolchain.git repository which has all the
>> orocos toolchain git repos as submodules.
>>
>> I'm also looking at these branches, please reply with OK or comment if it
>> is
>> for merging:
>> - snrkiwi/toolchain-next
>> - phamelin/v2.3.1-sm-win32-fixes
>> - lua stuff from markus, possible fixes for the type system not being able
>> to
>> handle types as reported on the ML
>>
>> For the other repositories, take a look at the master-ros-refactoring,
>> which
>> changes how packages are built in ROS, using the same layout as autoproj.
>> These will be merged in their respective master branches as well.
>>
>> I'm also a bit worried about all the tooling going on, being announced on
>> the
>> ML and then not being included in releases, and not being easily found on
>> the
>> website. We need a system similar/identical to the ROS package trees for
>> tracking this content. I wonder how easy it would be to (literally) copy
>> the
>> ROS infrastructure and add 'Orocos' package repositories. We could also
>> talk
>> to the ROS guys and ask them how they feel about it... using their
>> infrastructure directly (with an Orocos logo/branding) or copying it to
>> our
>> own servers...
>>
>> I looked at the rock package directory, but I'm missing the concepts of a
>> stack and a wiki to online edit the documentation. It would be neat if the
>> rock package directory could be part of this scheme though.
>>
>
>
> What about the stdint-typekit package: do you plan to integrate it to the
> toolchain-2.5 release?
> It is not extensively tested...

I'll include it. Since it's an add-on without extra dependencies, it's
easy to test. Unofficial policy dictates that the package name may
only contain an underscore instead of a dash. So you should create a
new git repos called 'stdint_typekit' and remove the old one.

Peter

Merging new branches in Orocos Toolchain/master branches

Submitted by phamelin on Tue, 2011-07-05 11:56.

2011/7/5 Peter Soetens <peter [..] ...>

> - Merge type primitives branch. This allows typekits to choose if a type is
> a
> 'full' type or a 'primitive' type. A primitive type can not be sent over a
> flow
> port, for example, all int_xy_t types and sequence [] types in ROS-like
> environments. This will reduce the compilation time of ROS typekits by
> about
> 30%. The ros typekits need to be adapted to use these new type info
> classes.
>
> - Add support for fixed size arrays in the type system. ROS typekits need
> this
> with fixed size messages.
>
> - I also succeeded in building RTT + omniorb with clang 2.9
>
> - We will also create an orocos_toolchain.git repository which has all the
> orocos toolchain git repos as submodules.
>
> I'm also looking at these branches, please reply with OK or comment if it
> is
> for merging:
> - snrkiwi/toolchain-next
> - phamelin/v2.3.1-sm-win32-fixes
>

OK for RTT and OCL.

> - lua stuff from markus, possible fixes for the type system not being able
> to
> handle types as reported on the ML
>
> For the other repositories, take a look at the master-ros-refactoring,
> which
> changes how packages are built in ROS, using the same layout as autoproj.
> These will be merged in their respective master branches as well.
>
> I'm also a bit worried about all the tooling going on, being announced on
> the
> ML and then not being included in releases, and not being easily found on
> the
> website. We need a system similar/identical to the ROS package trees for
> tracking this content. I wonder how easy it would be to (literally) copy
> the
> ROS infrastructure and add 'Orocos' package repositories. We could also
> talk
> to the ROS guys and ask them how they feel about it... using their
> infrastructure directly (with an Orocos logo/branding) or copying it to our
> own servers...
>
> I looked at the rock package directory, but I'm missing the concepts of a
> stack and a wiki to online edit the documentation. It would be neat if the
> rock package directory could be part of this scheme though.
>
> Peter
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

Merging new branches in Orocos Toolchain/master branches

Submitted by phamelin on Tue, 2011-07-05 12:40.

2011/7/5 Philippe Hamelin <philippe [dot] hamelin [..] ...>

> 2011/7/5 Peter Soetens <peter [..] ...>
>
>> I'm going to merge new stuff into master, causing an effective deviation
>> from
>> the toolchain-2.4 branches and preparing 2.5.
>>
>> For RTT, these topics are for merge:
>>
>> - Use IS_ROS_PACKAGE macro instead of ROS_ROOT in useorocos.cmake macros.
>> This
>> will fix building RTT,OCL, etc in non-ros package trees on systems where
>> ROS is
>> installed and autoproj is used
>>
>> - Removing the RTT::internal::Signal from ports. You'll be able to
>> register
>> only one callback to a port, and the getNewDataEvent() function is gone.
>> This
>> gives us a 10% reduction in code size and compensates the 2.3->2.4
>> regression
>> (but doesn't fix it !)
>>
>>
> :| We extensively use the 'getNewDataOnPortEvent' method in one of
> our applications. I guess we will have to code our own observer pattern on
> top of the single callback.
>
>
>> - Merge type primitives branch. This allows typekits to choose if a type
>> is a
>> 'full' type or a 'primitive' type. A primitive type can not be sent over a
>> flow
>> port, for example, all int_xy_t types and sequence [] types in ROS-like
>> environments. This will reduce the compilation time of ROS typekits by
>> about
>> 30%. The ros typekits need to be adapted to use these new type info
>> classes.
>>
>> - Add support for fixed size arrays in the type system. ROS typekits need
>> this
>> with fixed size messages.
>>
>> - I also succeeded in building RTT + omniorb with clang 2.9
>>
>> - We will also create an orocos_toolchain.git repository which has all the
>> orocos toolchain git repos as submodules.
>>
>> I'm also looking at these branches, please reply with OK or comment if it
>> is
>> for merging:
>> - snrkiwi/toolchain-next
>> - phamelin/v2.3.1-sm-win32-fixes
>>
>
> OK for RTT and OCL.
>
>

Sorry I have one more commit to merge related to bug #804 (
http://bugs.orocos.org/show_bug.cgi?id=804). Until now, I just forgot to
push it to my branch on github. Here it is :

https://github.com/phamelin/orocos-ocl/commit/ec806c7f5adb1f1bf2deb13369...

Philippe

Merging new branches in Orocos Toolchain/master branches

Submitted by peter on Tue, 2011-07-05 12:08.

On Tuesday 05 July 2011 13:52:18 Philippe Hamelin wrote:
> 2011/7/5 Peter Soetens <peter [..] ...>
>
> > I'm going to merge new stuff into master, causing an effective deviation
> > from
> > the toolchain-2.4 branches and preparing 2.5.
> >
> > For RTT, these topics are for merge:
> >
> > - Use IS_ROS_PACKAGE macro instead of ROS_ROOT in useorocos.cmake macros.
> > This
> > will fix building RTT,OCL, etc in non-ros package trees on systems where
> > ROS is
> > installed and autoproj is used
> >
> > - Removing the RTT::internal::Signal from ports. You'll be able to
> > register only one callback to a port, and the getNewDataEvent() function
> > is gone. This
> > gives us a 10% reduction in code size and compensates the 2.3->2.4
> > regression
> > (but doesn't fix it !)
> >
> :| We extensively use the 'getNewDataOnPortEvent' method in one of
>
> our applications. I guess we will have to code our own observer pattern on
> top of the single callback.

For clarity, the Signal class has not been removed from RTT. Also the callback
signature remained the same. You can attach multiple observers by writing:

// class member variable:
RTT::internal::Signal<void(PortInterface*)> myobserver;
// return my observer
RTT::internal::Signal<void(PortInterface*)>* getNewDataOnPortEvent() { return 
myobserver; }
 
// During addEventPort:
addEventPort( port, boost::bind( port.getNewDataOnPortEvent(), 
RTT::internal::Signal<void(PortInterface*)>::emit, _1) )

and put this code in a subclass from InputPort which you use through your
components. You'll have to add callbacks to myobserver, just like you did with
getNewDataOnPortEvent().

Note that for 2.5, you can still build it with the 'ORO_SIGNALLING_PORTS'
build flag on, which enables the 2.4 code as-was. We didn't remove the code, we
#ifdef'ed it.

Why do you need to add multiple callbacks to one port ?

Peter

Merging new branches in Orocos Toolchain/master branches

Submitted by phamelin on Tue, 2011-07-05 12:24.

2011/7/5 Peter Soetens <peter [..] ...>

> On Tuesday 05 July 2011 13:52:18 Philippe Hamelin wrote:
> > 2011/7/5 Peter Soetens <peter [..] ...>
> >
> > > I'm going to merge new stuff into master, causing an effective
> deviation
> > > from
> > > the toolchain-2.4 branches and preparing 2.5.
> > >
> > > For RTT, these topics are for merge:
> > >
> > > - Use IS_ROS_PACKAGE macro instead of ROS_ROOT in useorocos.cmake
> macros.
> > > This
> > > will fix building RTT,OCL, etc in non-ros package trees on systems
> where
> > > ROS is
> > > installed and autoproj is used
> > >
> > > - Removing the RTT::internal::Signal from ports. You'll be able to
> > > register only one callback to a port, and the getNewDataEvent()
> function
> > > is gone. This
> > > gives us a 10% reduction in code size and compensates the 2.3->2.4
> > > regression
> > > (but doesn't fix it !)
> > >
> > :| We extensively use the 'getNewDataOnPortEvent' method in one of
> >
> > our applications. I guess we will have to code our own observer pattern
> on
> > top of the single callback.
>
> For clarity, the Signal class has not been removed from RTT. Also the
> callback
> signature remained the same. You can attach multiple observers by writing:
>

> // class member variable:
> RTT::internal::Signal<void(PortInterface*)> myobserver;
> // return my observer
> RTT::internal::Signal<void(PortInterface*)>* getNewDataOnPortEvent() {
> return
> myobserver; }
>
> // During addEventPort:
> addEventPort( port, boost::bind( port.getNewDataOnPortEvent(),
> RTT::internal::Signal<void(PortInterface*)>::emit, _1) )
>

>
> and put this code in a subclass from InputPort which you use through your
> components. You'll have to add callbacks to myobserver, just like you did
> with
> getNewDataOnPortEvent().
>
> Note that for 2.5, you can still build it with the 'ORO_SIGNALLING_PORTS'
> build flag on, which enables the 2.4 code as-was. We didn't remove the
> code, we
> #ifdef'ed it.
>
> Why do you need to add multiple callbacks to one port ?
>
>
We use that in our GUIs. This is something like a Model-View-Controler (MVC)
model, where the 'Model' is a single(ton) Orocos component connected to many
others on the network. The different 'Views' are thus observers of the ports
in the 'Model'. So we have one callback per view and the data is distributed
through QT signals/slot inside to the widgets a 'View'. We also coded
something similar for (asynchronous) operation calls, where a 'View' can be
an observer (callback) of the return value of an operation. We would also
like to allow synchronous operations, but we really miss a timed out
collect() :-(. This GUI/QT toolkit allows us, with only a few templated
wrapper classes, to encapsulate the complexity of Orocos when developing
GUIs and centralize the connection/deconnection/timeout management.

Merging new branches in Orocos Toolchain/master branches

Submitted by markus.klotzbuecher on Tue, 2011-07-05 11:08.

On Tue, Jul 05, 2011 at 12:54:08PM +0200, Peter Soetens wrote:
> I'm going to merge new stuff into master, causing an effective deviation from
> the toolchain-2.4 branches and preparing 2.5.
>
> For RTT, these topics are for merge:
>
> - Use IS_ROS_PACKAGE macro instead of ROS_ROOT in useorocos.cmake macros. This
> will fix building RTT,OCL, etc in non-ros package trees on systems where ROS is
> installed and autoproj is used
>
> - Removing the RTT::internal::Signal from ports. You'll be able to register
> only one callback to a port, and the getNewDataEvent() function is gone. This
> gives us a 10% reduction in code size and compensates the 2.3->2.4 regression
> (but doesn't fix it !)
>
> - Merge type primitives branch. This allows typekits to choose if a type is a
> 'full' type or a 'primitive' type. A primitive type can not be sent over a flow
> port, for example, all int_xy_t types and sequence [] types in ROS-like
> environments. This will reduce the compilation time of ROS typekits by about
> 30%. The ros typekits need to be adapted to use these new type info classes.
>
> - Add support for fixed size arrays in the type system. ROS typekits need this
> with fixed size messages.
>
> - I also succeeded in building RTT + omniorb with clang 2.9
>
> - We will also create an orocos_toolchain.git repository which has all the
> orocos toolchain git repos as submodules.
>
> I'm also looking at these branches, please reply with OK or comment if it is
> for merging:
> - snrkiwi/toolchain-next
> - phamelin/v2.3.1-sm-win32-fixes
> - lua stuff from markus, possible fixes for the type system not being able to
> handle types as reported on the ML

I'm currently testing this. I'll give you feedback ASAP.

> For the other repositories, take a look at the master-ros-refactoring, which
> changes how packages are built in ROS, using the same layout as autoproj.
> These will be merged in their respective master branches as well.
>
> I'm also a bit worried about all the tooling going on, being announced on the
> ML and then not being included in releases, and not being easily found on the
> website. We need a system similar/identical to the ROS package trees for
> tracking this content. I wonder how easy it would be to (literally) copy the
> ROS infrastructure and add 'Orocos' package repositories. We could also talk
> to the ROS guys and ask them how they feel about it... using their
> infrastructure directly (with an Orocos logo/branding) or copying it to our
> own servers...
>
> I looked at the rock package directory, but I'm missing the concepts of a
> stack and a wiki to online edit the documentation. It would be neat if the
> rock package directory could be part of this scheme though.

Markus

Merging new branches in Orocos Toolchain/master branches

Submitted by snrkiwi on Tue, 2011-07-05 11:04.

On Jul 5, 2011, at 06:54 , Peter Soetens wrote:

> I'm going to merge new stuff into master, causing an effective deviation from
> the toolchain-2.4 branches and preparing 2.5.
>
> For RTT, these topics are for merge:
>
> - Use IS_ROS_PACKAGE macro instead of ROS_ROOT in useorocos.cmake macros. This
> will fix building RTT,OCL, etc in non-ros package trees on systems where ROS is
> installed and autoproj is used
>
> - Removing the RTT::internal::Signal from ports. You'll be able to register
> only one callback to a port, and the getNewDataEvent() function is gone. This
> gives us a 10% reduction in code size and compensates the 2.3->2.4 regression
> (but doesn't fix it !)
>
> - Merge type primitives branch. This allows typekits to choose if a type is a
> 'full' type or a 'primitive' type. A primitive type can not be sent over a flow
> port, for example, all int_xy_t types and sequence [] types in ROS-like
> environments. This will reduce the compilation time of ROS typekits by about
> 30%. The ros typekits need to be adapted to use these new type info classes.
>
> - Add support for fixed size arrays in the type system. ROS typekits need this
> with fixed size messages.
>
> - I also succeeded in building RTT + omniorb with clang 2.9

Linux? I've never been able to get RTT to build with clang 2.9 on the Mac ...

> - We will also create an orocos_toolchain.git repository which has all the
> orocos toolchain git repos as submodules.
>
> I'm also looking at these branches, please reply with OK or comment if it is
> for merging:
> - snrkiwi/toolchain-next

Ok for RTT and OCL.

> - phamelin/v2.3.1-sm-win32-fixes
> - lua stuff from markus, possible fixes for the type system not being able to
> handle types as reported on the ML
>
> For the other repositories, take a look at the master-ros-refactoring, which
> changes how packages are built in ROS, using the same layout as autoproj.
> These will be merged in their respective master branches as well.
>
> I'm also a bit worried about all the tooling going on, being announced on the
> ML and then not being included in releases, and not being easily found on the
> website. We need a system similar/identical to the ROS package trees for

What is an example of what you are worried about?

> tracking this content. I wonder how easy it would be to (literally) copy the
> ROS infrastructure and add 'Orocos' package repositories. We could also talk
> to the ROS guys and ask them how they feel about it... using their
> infrastructure directly (with an Orocos logo/branding) or copying it to our
> own servers...
>
> I looked at the rock package directory, but I'm missing the concepts of a
> stack and a wiki to online edit the documentation. It would be neat if the
> rock package directory could be part of this scheme though.
>
> Peter

Cheers
S