Fwd: Last updates on rtt/master

---------- Forwarded message ----------
From: Steven Bellens <steven [dot] bellens [..] ...>
Date: 2011/2/12
Subject: Re: [Orocos-Dev] Last updates on rtt/master
To: Peter Soetens <peter [..] ...>

2011/2/9 Peter Soetens <peter [..] ...>:
> I have merged my last patches on master for rtt.
>
> These are the major changes:
>
> - All-round fixes for compiling with clang. This didn't break gcc builds, but
> It would be nice if the Win32 guys could check if it didn't break theirs
> - 'extern template' declarations for the RTT types in a Types.hpp header. I
> checked with Visual studio documentation, this should be supported.
> - Merged all win32 work I could get. The fix for CorbaConversion is still
> lacking.
>
> If anyone could assist me with setting up a hudson job for building
> automatically on win32, I'd be happy to include it in my workflow such that
> breakage could be sooner detected.
>
> Please test this version as the 2.3 release won't be much different than this.
> I pushed updates for rtt, ocl and log4cpp, all on master.

* Starting from a clean folder and up-to-date master branches, the ros
integration seems broken. Compilation is ok, but when starting the
deployer and importing one of the rtt_ros_integration libraries, the
deployer crashes:

"deployer-gnulinux:
/home/steven/src/svn/stacks/orocos_toolchain_ros/rtt_ros_integration_std_msgs/src/orocos/types/ros_std_msgs_transport.cpp:47:
virtual bool ros_integration::ROSstd_msgsPlugin::registerTransport(std::string,
RTT::types::TypeInfo*): Assertion `name == ti->getTypeName()' failed.
Aborted"

Am I missing something obvious here? What change may have caused this?

* The UseOrocos macro outputs warnings for every ROS package which
does not contain a .pc file, e.g:
[UseOrocos] roscpp does not provide a .pc file for exporting its
build/link flags (or one of it 'Requires' dependencies was not found).
Not that it's a major problem, but depending on a lot of ROS packages
will output a lot of overhead.

Steven

>
> Peter
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

Fwd: Last updates on rtt/master

On Sat, Feb 12, 2011 at 1:37 PM, Steven Bellens
<steven [dot] bellens [..] ...> wrote:
> ---------- Forwarded message ----------
> From: Steven Bellens <steven [dot] bellens [..] ...>
> Date: 2011/2/12
> Subject: Re: [Orocos-Dev] Last updates on rtt/master
> To: Peter Soetens <peter [..] ...>
>
>
> 2011/2/9 Peter Soetens <peter [..] ...>:
>> I have merged my last patches on master for rtt.
>>
>> These are the major changes:
>>
>> - All-round fixes for compiling with clang. This didn't break gcc builds, but
>> It would be nice if the Win32 guys could check if it didn't break theirs
>> - 'extern template' declarations for the RTT types in a Types.hpp header. I
>> checked with Visual studio documentation, this should be supported.
>> - Merged all win32 work I could get. The fix for CorbaConversion is still
>> lacking.
>>
>> If anyone could assist me with setting up a hudson job for building
>> automatically on win32, I'd be happy to include it in my workflow such that
>> breakage could be sooner detected.
>>
>> Please test this version as the 2.3 release won't be much different than this.
>> I pushed updates for rtt, ocl and log4cpp, all on master.
>
> * Starting from a clean folder and up-to-date master branches, the ros
> integration seems broken. Compilation is ok, but when starting the
> deployer and importing one of the rtt_ros_integration libraries, the
> deployer crashes:
>
> "deployer-gnulinux:
> /home/steven/src/svn/stacks/orocos_toolchain_ros/rtt_ros_integration_std_msgs/src/orocos/types/ros_std_msgs_transport.cpp:47:
> virtual bool ros_integration::ROSstd_msgsPlugin::registerTransport(std::string,
> RTT::types::TypeInfo*): Assertion `name == ti->getTypeName()' failed.
> Aborted"
>
> Am I missing something obvious here? What change may have caused this?

The assertion that fails is no longer true, since aliases exist now,
the name is no longer necessarily the same as the typename. Just
remove the assertion, the rest of the code looks correct and should
then work as before. This is in the file
ros_msg_transport_plugin.cpp.in.

>
> * The UseOrocos macro outputs warnings for every ROS package which
> does not contain a .pc file, e.g:
> [UseOrocos] roscpp does not provide a .pc file for exporting its
> build/link flags (or one of it 'Requires' dependencies was not found).
> Not that it's a major problem, but depending on a lot of ROS packages
> will output a lot of overhead.

Yeah, this was for early debugging purposes since lots of this .pc
file extraction is new, its more verbose than it should be. We could
control the output with a flag which defaults to off.

Peter

Fwd: Last updates on rtt/master

2011/2/12 Peter Soetens <peter [..] ...>:
> On Sat, Feb 12, 2011 at 1:37 PM, Steven Bellens
> <steven [dot] bellens [..] ...> wrote:
>> ---------- Forwarded message ----------
>> From: Steven Bellens <steven [dot] bellens [..] ...>
>> Date: 2011/2/12
>> Subject: Re: [Orocos-Dev] Last updates on rtt/master
>> To: Peter Soetens <peter [..] ...>
>>
>>
>> 2011/2/9 Peter Soetens <peter [..] ...>:
>>> I have merged my last patches on master for rtt.
>>>
>>> These are the major changes:
>>>
>>> - All-round fixes for compiling with clang. This didn't break gcc builds, but
>>> It would be nice if the Win32 guys could check if it didn't break theirs
>>> - 'extern template' declarations for the RTT types in a Types.hpp header. I
>>> checked with Visual studio documentation, this should be supported.
>>> - Merged all win32 work I could get. The fix for CorbaConversion is still
>>> lacking.
>>>
>>> If anyone could assist me with setting up a hudson job for building
>>> automatically on win32, I'd be happy to include it in my workflow such that
>>> breakage could be sooner detected.
>>>
>>> Please test this version as the 2.3 release won't be much different than this.
>>> I pushed updates for rtt, ocl and log4cpp, all on master.
>>
>> * Starting from a clean folder and up-to-date master branches, the ros
>> integration seems broken. Compilation is ok, but when starting the
>> deployer and importing one of the rtt_ros_integration libraries, the
>> deployer crashes:
>>
>> "deployer-gnulinux:
>> /home/steven/src/svn/stacks/orocos_toolchain_ros/rtt_ros_integration_std_msgs/src/orocos/types/ros_std_msgs_transport.cpp:47:
>> virtual bool ros_integration::ROSstd_msgsPlugin::registerTransport(std::string,
>> RTT::types::TypeInfo*): Assertion `name == ti->getTypeName()' failed.
>> Aborted"
>>
>> Am I missing something obvious here? What change may have caused this?
>
> The assertion that fails is no longer true, since aliases exist now,
> the name is no longer necessarily the same as the typename. Just
> remove the assertion, the rest of the code looks correct and should
> then work as before. This is in the file
> ros_msg_transport_plugin.cpp.in.

What about the compatibility?
Will removing the assert still keep the code working on older versions?

Steven

>
>>
>> * The UseOrocos macro outputs warnings for every ROS package which
>> does not contain a .pc file, e.g:
>> [UseOrocos] roscpp does not provide a .pc file for exporting its
>> build/link flags (or one of it 'Requires' dependencies was not found).
>> Not that it's a major problem, but depending on a lot of ROS packages
>> will output a lot of overhead.
>
> Yeah, this was for early debugging purposes since lots of this .pc
> file extraction is new, its more verbose than it should be. We could
> control the output with a flag which defaults to off.
>
> Peter
>

Fwd: Last updates on rtt/master

On Sat, Feb 12, 2011 at 11:19 PM, Steven Bellens
<steven [dot] bellens [..] ...> wrote:
> 2011/2/12 Peter Soetens <peter [..] ...>:
>> On Sat, Feb 12, 2011 at 1:37 PM, Steven Bellens
>> <steven [dot] bellens [..] ...> wrote:
>>> ---------- Forwarded message ----------
>>> From: Steven Bellens <steven [dot] bellens [..] ...>
>>> Date: 2011/2/12
>>> Subject: Re: [Orocos-Dev] Last updates on rtt/master
>>> To: Peter Soetens <peter [..] ...>
>>>
>>>
>>> 2011/2/9 Peter Soetens <peter [..] ...>:
>>>> I have merged my last patches on master for rtt.
>>>>
>>>> These are the major changes:
>>>>
>>>> - All-round fixes for compiling with clang. This didn't break gcc builds, but
>>>> It would be nice if the Win32 guys could check if it didn't break theirs
>>>> - 'extern template' declarations for the RTT types in a Types.hpp header. I
>>>> checked with Visual studio documentation, this should be supported.
>>>> - Merged all win32 work I could get. The fix for CorbaConversion is still
>>>> lacking.
>>>>
>>>> If anyone could assist me with setting up a hudson job for building
>>>> automatically on win32, I'd be happy to include it in my workflow such that
>>>> breakage could be sooner detected.
>>>>
>>>> Please test this version as the 2.3 release won't be much different than this.
>>>> I pushed updates for rtt, ocl and log4cpp, all on master.
>>>
>>> * Starting from a clean folder and up-to-date master branches, the ros
>>> integration seems broken. Compilation is ok, but when starting the
>>> deployer and importing one of the rtt_ros_integration libraries, the
>>> deployer crashes:
>>>
>>> "deployer-gnulinux:
>>> /home/steven/src/svn/stacks/orocos_toolchain_ros/rtt_ros_integration_std_msgs/src/orocos/types/ros_std_msgs_transport.cpp:47:
>>> virtual bool ros_integration::ROSstd_msgsPlugin::registerTransport(std::string,
>>> RTT::types::TypeInfo*): Assertion `name == ti->getTypeName()' failed.
>>> Aborted"
>>>
>>> Am I missing something obvious here? What change may have caused this?
>>
>> The assertion that fails is no longer true, since aliases exist now,
>> the name is no longer necessarily the same as the typename. Just
>> remove the assertion, the rest of the code looks correct and should
>> then work as before. This is in the file
>> ros_msg_transport_plugin.cpp.in.
>
> What about the compatibility?
> Will removing the assert still keep the code working on older versions?

Of course. The assert has no influence on the behavior of the function, it
may be safely removed without breaking any old/new code.
Removing an assert must never alter the behavior of a function for that matter.

Peter

>
> Steven
>
>>
>>>
>>> * The UseOrocos macro outputs warnings for every ROS package which
>>> does not contain a .pc file, e.g:
>>> [UseOrocos] roscpp does not provide a .pc file for exporting its
>>> build/link flags (or one of it 'Requires' dependencies was not found).
>>> Not that it's a major problem, but depending on a lot of ROS packages
>>> will output a lot of overhead.
>>
>> Yeah, this was for early debugging purposes since lots of this .pc
>> file extraction is new, its more verbose than it should be. We could
>> control the output with a flag which defaults to off.
>>
>> Peter
>>
>