Orocos Toolchain v2.3.0 released !

Submitted by peter on Tue, 2011-03-01 15:20

All the buzz was right, a new release was anxiously waiting to become official, only being released when all tests pass on all platforms. We got it rock-solid on various Linux flavors, Windows (Visual Studio) and Mac OS-X. Focusing on usability instead of features, it accumulates tons of suggestions and improvements offered by the community, translated in 262 patches alone for RTT between 2.2.0 and 2.3.0.

You can find all the relevant download links and documentation on this page: http://www.orocos.org/toolchain

Most notable enhancements are:

Bootstrapping in ROS and non-ROS environments is supported See http://www.orocos.org/wiki/orocos/toolchain/getting-started
Many improvements in the build system (UseOrocos-RTT.cmake)
Building components without depending on OCL
Full Win32 support on Visual Studio 2005 -> 2010
Multi-target builds work by setting an OROCOS_TARGET environment variable (optional), a multi-target runtime will always work, even without this variable set.
We support Xerces-2 and -3 now for reading property XML files

The most notable disruption in this release is that all (component) libraries are now by default installed in a 'target/' subdirectory of the orocos/ component directory. If you use the UseOrocos-RTT.cmake macros, this transition should be seamlessly. If you don't want such a target subdirectory, define the OROCOS_SUFFIX to the empty string in your CMake configurations.

This and other caveats and improvements can be read on this page: http://www.orocos.org/stable/documentation/rtt/v2.3.x/doc-xml/orocos-rtt-changes.html It is important to read this page first before you upgrade.

ROS users may also choose to wait until the orocos_toolchain_ros updates to this release, later this week.

Peter

[Announce] Orocos Toolchain v2.3.0 released !

Submitted by snrkiwi on Wed, 2011-03-02 12:00.

On Mar 1, 2011, at 10:18 , Peter Soetens wrote:

> All the buzz was right, a new release was anxiously waiting to become official,
> only being released when all tests pass on all platforms. We got it rock-solid
> on various Linux flavors, Windows (Visual Studio) and Mac OS-X. Focusing on
> usability instead of features, it accumulates tons of suggestions and
> improvements offered by the community, translated in 262 patches alone
> for RTT between 2.2.0 and 2.3.0.

Tests fail on Mac OS X. Seems to be boost::utf related. :-(

(gdb) r
Starting program: /opt/sw/orocos/toolchain/build/rtt/tests/list-test 
bt
Reading symbols for shared libraries .+++++++++++........................ done
Running 2 test cases...
 
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x0000000103af4a4c in boost::unit_test::framework::get ()
(gdb) bt
#0  0x0000000103af4a4c in boost::unit_test::framework::get ()
#1  0x0000000103b3669a in boost::unit_test::traverse_test_tree ()
#2  0x0000000103affc8b in boost::unit_test::results_collector_t::test_unit_finish ()
#3  0x000000010006ee2d in boost::unit_test::framework_impl::test_suite_finish (this=0x1000fc380, ts=@0x103d093c0) at framework.ipp:192
#4  0x0000000100028da8 in boost::unit_test::traverse_test_tree (suite=@0x103d093c0, V=@0x1000fc380) at unit_test_suite.ipp:223
#5  0x0000000100028e98 in boost::unit_test::traverse_test_tree (id=2, V=@0x1000fc380) at unit_test_suite.ipp:234
#6  0x0000000100028ad6 in boost::unit_test::traverse_test_tree (suite=@0x103d09890, V=@0x1000fc380) at unit_test_suite.ipp:207
#7  0x0000000100028e98 in boost::unit_test::traverse_test_tree (id=1, V=@0x1000fc380) at unit_test_suite.ipp:234
#8  0x00000001000300c2 in boost::unit_test::framework::run (id=1, continue_test=true) at framework.ipp:442
#9  0x0000000100030425 in boost::unit_test::unit_test_main (init_func=0x10001d7c2 <init_unit_test_suite(int, char**)>, argc=1, argv=0x7fff5fbff548) at unit_test_main.ipp:185
#10 0x00000001000306ae in main (argc=1, argv=0x7fff5fbff548) at unit_test_main.ipp:237

[Announce] Orocos Toolchain v2.3.0 released !

Submitted by peter on Wed, 2011-03-02 15:52.

On Wednesday 02 March 2011 12:57:33 S Roderick wrote:
> On Mar 1, 2011, at 10:18 , Peter Soetens wrote:
> > All the buzz was right, a new release was anxiously waiting to become
> > official, only being released when all tests pass on all platforms. We
> > got it rock-solid on various Linux flavors, Windows (Visual Studio) and
> > Mac OS-X. Focusing on usability instead of features, it accumulates tons
> > of suggestions and improvements offered by the community, translated in
> > 262 patches alone for RTT between 2.2.0 and 2.3.0.
>
> Tests fail on Mac OS X. Seems to be boost::utf related. :-(

We have a custom/copied boost header in the tests/ directory to catch
exceptions in the test fixtures. This was pulled from boost 1.40, but I guess
you're using a newer version ? Could you copy your boost's
unit_test_suite.hpp file into your tests/ directory and recompile ?

>
>

> (gdb) r
> Starting program: /opt/sw/orocos/toolchain/build/rtt/tests/list-test
> bt
> Reading symbols for shared libraries .+++++++++++........................
> done Running 2 test cases...
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
> 0x0000000103af4a4c in boost::unit_test::framework::get ()
> (gdb) bt
> #0  0x0000000103af4a4c in boost::unit_test::framework::get ()
> #1  0x0000000103b3669a in boost::unit_test::traverse_test_tree ()
> #2  0x0000000103affc8b in
> boost::unit_test::results_collector_t::test_unit_finish () #3 
> 0x000000010006ee2d in boost::unit_test::framework_impl::test_suite_finish
> (this=0x1000fc380, ts=@0x103d093c0) at framework.ipp:192 #4 
> 0x0000000100028da8 in boost::unit_test::traverse_test_tree
> (suite=@0x103d093c0, V=@0x1000fc380) at unit_test_suite.ipp:223 #5 
> 0x0000000100028e98 in boost::unit_test::traverse_test_tree (id=2,
> V=@0x1000fc380) at unit_test_suite.ipp:234 #6  0x0000000100028ad6 in
> boost::unit_test::traverse_test_tree (suite=@0x103d09890, V=@0x1000fc380)
> at unit_test_suite.ipp:207 #7  0x0000000100028e98 in
> boost::unit_test::traverse_test_tree (id=1, V=@0x1000fc380) at
> unit_test_suite.ipp:234 #8  0x00000001000300c2 in
> boost::unit_test::framework::run (id=1, continue_test=true) at
> framework.ipp:442 #9  0x0000000100030425 in
> boost::unit_test::unit_test_main (init_func=0x10001d7c2
> <init_unit_test_suite(int, char**)>, argc=1, argv=0x7fff5fbff548) at
> unit_test_main.ipp:185 #10 0x00000001000306ae in main (argc=1,
> argv=0x7fff5fbff548) at unit_test_main.ipp:237

Another thing we should urgently work around is to link to boost.test instead
of using it header-only.

Peter

[Announce] Orocos Toolchain v2.3.0 released !

Submitted by snrkiwi on Wed, 2011-03-02 23:24.

On Mar 2, 2011, at 10:31 , Peter Soetens wrote:

> On Wednesday 02 March 2011 12:57:33 S Roderick wrote:
>> On Mar 1, 2011, at 10:18 , Peter Soetens wrote:
>>> All the buzz was right, a new release was anxiously waiting to become
>>> official, only being released when all tests pass on all platforms. We
>>> got it rock-solid on various Linux flavors, Windows (Visual Studio) and
>>> Mac OS-X. Focusing on usability instead of features, it accumulates tons
>>> of suggestions and improvements offered by the community, translated in
>>> 262 patches alone for RTT between 2.2.0 and 2.3.0.
>>
>> Tests fail on Mac OS X. Seems to be boost::utf related. :-(
>
> We have a custom/copied boost header in the tests/ directory to catch
> exceptions in the test fixtures. This was pulled from boost 1.40, but I guess
> you're using a newer version ? Could you copy your boost's
> unit_test_suite.hpp file into your tests/ directory and recompile ?

Same behavior. I'm at boost 1.42.0. I know that I don't need to tell you that having a custom file around like that is a recipe for disaster ... NB there was a bug in boost::utf a few months back that caused similar issues, but that got fixed. Wonder if something regressed ...?

The errors are similar between the few tests that I backtraced, but the call path is different. Log attached.

>> (gdb) r
>> Starting program: /opt/sw/orocos/toolchain/build/rtt/tests/list-test
>> bt
>> Reading symbols for shared libraries .+++++++++++........................
>> done Running 2 test cases...
>> 
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
>> 0x0000000103af4a4c in boost::unit_test::framework::get ()
>> (gdb) bt
>> #0  0x0000000103af4a4c in boost::unit_test::framework::get ()
>> #1  0x0000000103b3669a in boost::unit_test::traverse_test_tree ()
>> #2  0x0000000103affc8b in
>> boost::unit_test::results_collector_t::test_unit_finish () #3 
>> 0x000000010006ee2d in boost::unit_test::framework_impl::test_suite_finish
>> (this=0x1000fc380, ts=@0x103d093c0) at framework.ipp:192 #4 
>> 0x0000000100028da8 in boost::unit_test::traverse_test_tree
>> (suite=@0x103d093c0, V=@0x1000fc380) at unit_test_suite.ipp:223 #5 
>> 0x0000000100028e98 in boost::unit_test::traverse_test_tree (id=2,
>> V=@0x1000fc380) at unit_test_suite.ipp:234 #6  0x0000000100028ad6 in
>> boost::unit_test::traverse_test_tree (suite=@0x103d09890, V=@0x1000fc380)
>> at unit_test_suite.ipp:207 #7  0x0000000100028e98 in
>> boost::unit_test::traverse_test_tree (id=1, V=@0x1000fc380) at
>> unit_test_suite.ipp:234 #8  0x00000001000300c2 in
>> boost::unit_test::framework::run (id=1, continue_test=true) at
>> framework.ipp:442 #9  0x0000000100030425 in
>> boost::unit_test::unit_test_main (init_func=0x10001d7c2
>> <init_unit_test_suite(int, char**)>, argc=1, argv=0x7fff5fbff548) at
>> unit_test_main.ipp:185 #10 0x00000001000306ae in main (argc=1,
>> argv=0x7fff5fbff548) at unit_test_main.ipp:237

>
> Another thing we should urgently work around is to link to boost.test instead
> of using it header-only.

What will this do for us? Besides I imagine increase compilation speed.
S

[Announce] Orocos Toolchain v2.3.0 released !

Submitted by peter on Thu, 2011-03-03 20:40.

On Thu, Mar 3, 2011 at 12:21 AM, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
> On Mar 2, 2011, at 10:31 , Peter Soetens wrote:
>
>> On Wednesday 02 March 2011 12:57:33 S Roderick wrote:
>>> On Mar 1, 2011, at 10:18 , Peter Soetens wrote:
>>>> All the buzz was right, a new release was anxiously waiting to become
>>>> official, only being released when all tests pass on all platforms. We
>>>> got it rock-solid on various Linux flavors, Windows (Visual Studio) and
>>>> Mac OS-X. Focusing on usability instead of features, it accumulates tons
>>>> of suggestions and improvements offered by the community, translated in
>>>> 262 patches alone for RTT between 2.2.0 and 2.3.0.
>>>
>>> Tests fail on Mac OS X. Seems to be boost::utf related. :-(
>>
>> We have a custom/copied boost header in the tests/ directory to catch
>> exceptions in the test fixtures. This was pulled from boost 1.40, but I guess
>> you're using a newer version ? Could you copy your boost's
>> unit_test_suite.hpp file into your tests/ directory and recompile ?
>
> Same behavior. I'm at boost 1.42.0. I know that I don't need to tell you that having a custom file around like that is a recipe for disaster ... NB there was a bug in boost::utf a few months back that caused similar issues, but that got fixed. Wonder if something regressed ...?
>
> The errors are similar between the few tests that I backtraced, but the call path is different. Log attached.

Hmm can't make much out of it. I'll make this unit test file-crap
opt-in; such that only my test farm builds will use it...

>
>>>

>>> (gdb) r
>>> Starting program: /opt/sw/orocos/toolchain/build/rtt/tests/list-test
>>> bt
>>> Reading symbols for shared libraries .+++++++++++........................
>>> done Running 2 test cases...
>>>
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
>>> 0x0000000103af4a4c in boost::unit_test::framework::get ()
>>> (gdb) bt
>>> #0  0x0000000103af4a4c in boost::unit_test::framework::get ()
>>> #1  0x0000000103b3669a in boost::unit_test::traverse_test_tree ()
>>> #2  0x0000000103affc8b in
>>> boost::unit_test::results_collector_t::test_unit_finish () #3
>>> 0x000000010006ee2d in boost::unit_test::framework_impl::test_suite_finish
>>> (this=0x1000fc380, ts=@0x103d093c0) at framework.ipp:192 #4
>>> 0x0000000100028da8 in boost::unit_test::traverse_test_tree
>>> (suite=@0x103d093c0, V=@0x1000fc380) at unit_test_suite.ipp:223 #5
>>> 0x0000000100028e98 in boost::unit_test::traverse_test_tree (id=2,
>>> V=@0x1000fc380) at unit_test_suite.ipp:234 #6  0x0000000100028ad6 in
>>> boost::unit_test::traverse_test_tree (suite=@0x103d09890, V=@0x1000fc380)
>>> at unit_test_suite.ipp:207 #7  0x0000000100028e98 in
>>> boost::unit_test::traverse_test_tree (id=1, V=@0x1000fc380) at
>>> unit_test_suite.ipp:234 #8  0x00000001000300c2 in
>>> boost::unit_test::framework::run (id=1, continue_test=true) at
>>> framework.ipp:442 #9  0x0000000100030425 in
>>> boost::unit_test::unit_test_main (init_func=0x10001d7c2
>>> <init_unit_test_suite(int, char**)>, argc=1, argv=0x7fff5fbff548) at
>>> unit_test_main.ipp:185 #10 0x00000001000306ae in main (argc=1,
>>> argv=0x7fff5fbff548) at unit_test_main.ipp:237

>>
>> Another thing we should urgently work around is to link to boost.test instead
>> of using it header-only.
>
> What will this do for us? Besides I imagine increase compilation speed.

Correct. It's quite slow to compile test-runner.cpp for each unit test.

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

[Announce] Orocos Toolchain v2.3.0 released !

Submitted by snrkiwi on Wed, 2011-03-02 12:00.

On Mar 1, 2011, at 10:18 , Peter Soetens wrote:

Define __unix__ not defined on Mac OS X. Use __APPLE__ instead.

Peter, this solves the "extern template" problem we discussed, and allows RTT toolchain to build.
S

[Announce] Orocos Toolchain v2.3.0 released !

Submitted by snrkiwi on Wed, 2011-03-02 23:28.

On Mar 2, 2011, at 06:56 , S Roderick wrote:

> On Mar 1, 2011, at 10:18 , Peter Soetens wrote:
>
>> All the buzz was right, a new release was anxiously waiting to become official,
>> only being released when all tests pass on all platforms. We got it rock-solid
>> on various Linux flavors, Windows (Visual Studio) and Mac OS-X. Focusing on
>> usability instead of features, it accumulates tons of suggestions and
>> improvements offered by the community, translated in 262 patches alone
>> for RTT between 2.2.0 and 2.3.0.
>
> Define __unix__ not defined on Mac OS X. Use __APPLE__ instead.
>
> Peter, this solves the "extern template" problem we discussed, and allows RTT toolchain to build.
> S
>

[Announce] Orocos Toolchain v2.3.0 released !

Submitted by peter on Thu, 2011-03-03 20:44.

On Thu, Mar 3, 2011 at 12:25 AM, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Mar 2, 2011, at 06:56 , S Roderick wrote:
>
>> On Mar 1, 2011, at 10:18 , Peter Soetens wrote:
>>
>>> All the buzz was right, a new release was anxiously waiting to become official,
>>> only being released when all tests pass on all platforms. We got it rock-solid
>>> on various Linux flavors, Windows (Visual Studio) and Mac OS-X. Focusing on
>>> usability instead of features, it accumulates tons of suggestions and
>>> improvements offered by the community, translated in 262 patches alone
>>> for RTT between 2.2.0 and 2.3.0.
>>
>> Define __unix__ not defined on Mac OS X. Use __APPLE__ instead.
>>
>> Peter, this solves the "extern template" problem we discussed, and allows RTT toolchain to build.
>> S
>>
>> <0001-cmake-Check-for-__APPLE__-instead-of-__unix__-on-Mac.patch>--
>
> Missed one ...

The OCL has the same issues in ocl/ocl-config.h.in ... it's not
urgent...but it should be fixed sometime.

Peter

[Announce] Orocos Toolchain v2.3.0 released !

Submitted by peter on Wed, 2011-03-02 15:32.

On Wednesday 02 March 2011 12:56:27 S Roderick wrote:
> On Mar 1, 2011, at 10:18 , Peter Soetens wrote:
> > All the buzz was right, a new release was anxiously waiting to become
> > official, only being released when all tests pass on all platforms. We
> > got it rock-solid on various Linux flavors, Windows (Visual Studio) and
> > Mac OS-X. Focusing on usability instead of features, it accumulates tons
> > of suggestions and improvements offered by the community, translated in
> > 262 patches alone for RTT between 2.2.0 and 2.3.0.
>
> Define __unix__ not defined on Mac OS X. Use __APPLE__ instead.
>
> Peter, this solves the "extern template" problem we discussed, and allows
> RTT toolchain to build. S

Applied. Thank you very much !

Peter