RTT 1.10 branch 'release-ready' and misc.

I've spent the past two days cleaning and testing the rtt-1.10 branch[1]. It
looks in good shape (Debian etc) but I might have forgotten a few bits[2].
Feel free to run a make check on your platform (lxrt,win32,macosx prefered),
if there are no complaints, it goes out the door next monday, together with
ocl-1.10 [3]

The git rtt-2.0-mainline has the version number 1.91.0, and debian packages
appear to work too. I have on github / rtt-2.0-interproc an mqueue
'out-of-band' real-time data-flow transport working in a separate branch,
but it needs more testing with Xenomai before I merge it on the mainline.
Especially sending over std::vector<double> and variants will probably not
work out of the box yet.

I'm a bit behind schedule, but no serious problems seem to come up either.

Peter

[1] svn co http://svn.mech.kuleuven.be/repos/orocos/branches/rtt/rtt-1.10
[2] I vaguely remember something about a breakUpdateHook() patch
[3] svn co http://svn.mech.kuleuven.be/repos/orocos/branches/ocl/ocl-1.10

RTT 1.10 branch 'release-ready' and misc.

On Sep 11, 2009, at 05:15 , Peter Soetens wrote:

> I've spent the past two days cleaning and testing the rtt-1.10 branch
> [1]. It looks in good shape (Debian etc) but I might have forgotten
> a few bits[2]. Feel free to run a make check on your platform
> (lxrt,win32,macosx prefered), if there are no complaints, it goes
> out the door next monday, together with ocl-1.10 [3]
>
> The git rtt-2.0-mainline has the version number 1.91.0, and debian
> packages appear to work too. I have on github / rtt-2.0-interproc an
> mqueue 'out-of-band' real-time data-flow transport working in a
> separate branch, but it needs more testing with Xenomai before I
> merge it on the mainline. Especially sending over
> std::vector<double> and variants will probably not work out of the
> box yet.
>
> I'm a bit behind schedule, but no serious problems seem to come up
> either.
>
> Peter
>
> [1] svn co http://svn.mech.kuleuven.be/repos/orocos/branches/rtt/rtt-1.10
> [2] I vaguely remember something about a breakUpdateHook() patch
> [3] svn co http://svn.mech.kuleuven.be/repos/orocos/branches/ocl/ocl-1.10

The patch you sent out for [2]. This works for us.

I will test-build 1.10 on macosx (10.5 and 10.6) today. Will let you
know how it goes.
Stephen

RTT 1.10 branch 'release-ready' and misc.

On Sep 11, 2009, at 05:15 , Peter Soetens wrote:

> I've spent the past two days cleaning and testing the rtt-1.10 branch
> [1]. It looks in good shape (Debian etc) but I might have forgotten
> a few bits[2]. Feel free to run a make check on your platform
> (lxrt,win32,macosx prefered), if there are no complaints, it goes
> out the door next monday, together with ocl-1.10 [3]
>
> The git rtt-2.0-mainline has the version number 1.91.0, and debian
> packages appear to work too. I have on github / rtt-2.0-interproc an
> mqueue 'out-of-band' real-time data-flow transport working in a
> separate branch, but it needs more testing with Xenomai before I
> merge it on the mainline. Especially sending over
> std::vector<double> and variants will probably not work out of the
> box yet.
>
> I'm a bit behind schedule, but no serious problems seem to come up
> either.
>
> Peter
>
> [1] svn co http://svn.mech.kuleuven.be/repos/orocos/branches/rtt/rtt-1.10
> [2] I vaguely remember something about a breakUpdateHook() patch
> [3] svn co http://svn.mech.kuleuven.be/repos/orocos/branches/ocl/ocl-1.10

macosx leopard 10.5.8 plus boost v1.37, compiles fine. 2 tests fail -
results below
macosx snow leopard 10.6.1 plus boost v1.40 compiles libraries, but
fails to compile tests. Build results below.

You still need Tinne's patch for OmniORB

And is it "rtt-config.h" or rtt-config.hpp" ... :-)

Index: src/ArgumentDescription.hpp
===================================================================
--- src/ArgumentDescription.hpp	(revision 30519)
+++ src/ArgumentDescription.hpp	(working copy)
@@ -39,7 +39,7 @@
  #define ARGUMENTDESCRIPTION_HPP
 
  #include <string>
-#include "rtt-config.hpp"
+#include "rtt-config.h"
 
  namespace RTT
  {
Index: src/ConfigurationInterface.hpp
===================================================================
--- src/ConfigurationInterface.hpp	(revision 30519)
+++ src/ConfigurationInterface.hpp	(working copy)
@@ -38,7 +38,7 @@
  #ifndef CONFIGURATIONINTERFACE_HPP
  #define CONFIGURATIONINTERFACE_HPP
 
-#include "rtt-config.hpp"
+#include "rtt-config.h"
 
  namespace RTT
  {

Leopard test results

  4/ 11 Testing task-test
Test command: /opt/build/orocos/branches/rtt-1.10/tests/task-test
Test timeout computed to be: 9.99988e+06
Running 21 test cases...
/opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/tasks_test.cpp:282:  
error in "testOverrun": Failed to detect step overrun in Thread
/opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/tasks_test.cpp:284:  
error in "testOverrun": Failed to execute finalize in emergencyStop
2.515 [CRITICAL][PeriodicThread::stop] The ORThread thread seems to be  
blocked ( ret was 49 .)
 
*** 2 failures detected in test suite "Master Test Suite"
 
<snip>
 
   8/ 11 Testing program-test
Test command: /opt/build/orocos/branches/rtt-1.10/tests/program-test
Test timeout computed to be: 9.99988e+06
Running 19 test cases...
Asserted :0 with :Program script did not detect exported function  
failure.
/opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/function_test.cpp:334:  
error in "testFunctionFail": Runtime error encountered on line 12.
 
/opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/function_test.cpp:335:  
error in "testFunctionFail": Program stalled on line 12.
 
 
*** 2 failures detected in test suite "Master Test Suite"

Snow Leopard compile failures. I think that this is a boost problem.
If you set the types explicitly, the error still exists.

[ 86%] Building CXX object tests/CMakeFiles/core-test.dir/ 
time_test.cpp.o
/opt/local/include/boost/test/floating_point_comparison.hpp: In member  
function ‘boost::test_tools::predicate_result  
boost::test_tools::check_is_close_t::operator()(FPT1, FPT2,  
boost::test_tools::percent_tolerance_t<ToleranceBaseType>,  
boost::test_tools::floating_point_comparison_type) const [with FPT1 =  
long long int, FPT2 = long long int, ToleranceBaseType = int]:
/opt/local/include/boost/test/test_tools.hpp:523:   instantiated from  
‘bool boost::test_tools::tt_detail::check_frwd(Pred, const  
boost::unit_test::lazy_ostream&, boost::test_tools::const_string,  
size_t, boost::test_tools::tt_detail::tool_level,  
boost::test_tools::tt_detail::check_type, const Arg0&, const char*,  
const Arg1&, const char*, const Arg2&, const char*) [with Pred =  
boost::test_tools::check_is_close_t, Arg0 = RTT::nsecs, Arg1 = long  
long int, Arg2 = boost::test_tools::percent_tolerance_t<int>]/opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/time_test.cpp:113:    
instantiated from here
/opt/local/include/boost/test/floating_point_comparison.hpp:229:  
error: invalid application of ‘sizeof’ to incomplete type  
‘boost::STATIC_ASSERTION_FAILURE<false>’
make[2]: *** [tests/CMakeFiles/core-test.dir/time_test.cpp.o] Error 1
make[1]: *** [tests/CMakeFiles/core-test.dir/all] Error 2
make: *** [all] Error 2

RTT 1.10 branch 'release-ready' and misc.

On Fri, Sep 11, 2009 at 14:40, S Roderick <kiwi [dot] net [..] ...> wrote:

> On Sep 11, 2009, at 05:15 , Peter Soetens wrote:
>
> I've spent the past two days cleaning and testing the rtt-1.10 branch[1].
> It looks in good shape (Debian etc) but I might have forgotten a few
> bits[2]. Feel free to run a make check on your platform (lxrt,win32,macosx
> prefered), if there are no complaints, it goes out the door next monday,
> together with ocl-1.10 [3]
>
> The git rtt-2.0-mainline has the version number 1.91.0, and debian packages
> appear to work too. I have on github / rtt-2.0-interproc an mqueue
> 'out-of-band' real-time data-flow transport working in a separate branch,
> but it needs more testing with Xenomai before I merge it on the mainline.
> Especially sending over std::vector<double> and variants will probably not
> work out of the box yet.
>
> I'm a bit behind schedule, but no serious problems seem to come up either.
>
> Peter
>
> [1] svn co http://svn.mech.kuleuven.be/repos/orocos/branches/rtt/rtt-1.10
> [2] I vaguely remember something about a breakUpdateHook() patch
> [3] svn co http://svn.mech.kuleuven.be/repos/orocos/branches/ocl/ocl-1.10
>
>
> macosx leopard 10.5.8 plus boost v1.37, compiles fine. 2 tests fail -
> results below
> macosx snow leopard 10.6.1 plus boost v1.40 compiles libraries, but fails
> to compile tests. Build results below.
>
> You still need Tinne's patch for OmniORB
>

I had it in, but the inverse patch got accidentally applied too :-)

>
>
>
> And is it "rtt-config.h" or rtt-config.hpp" ... :-)
>
>

> Index: src/ArgumentDescription.hpp
> ===================================================================
> --- src/ArgumentDescription.hpp (revision 30519)
> +++ src/ArgumentDescription.hpp (working copy)
> @@ -39,7 +39,7 @@
>  #define ARGUMENTDESCRIPTION_HPP
>
>  #include <string>
> -#include "rtt-config.hpp"
> +#include "rtt-config.h"
>
>  namespace RTT
>  {
> Index: src/ConfigurationInterface.hpp
> ===================================================================
> --- src/ConfigurationInterface.hpp (revision 30519)
> +++ src/ConfigurationInterface.hpp (working copy)
> @@ -38,7 +38,7 @@
>  #ifndef CONFIGURATIONINTERFACE_HPP
>  #define CONFIGURATIONINTERFACE_HPP
>
> -#include "rtt-config.hpp"
> +#include "rtt-config.h"
>
>  namespace RTT
>  {
> 

>

Seems I still need to polish my workflow :)

>
>
> Leopard test results
>

>  4/ 11 Testing task-test
> Test command: /opt/build/orocos/branches/rtt-1.10/tests/task-test
> Test timeout computed to be: 9.99988e+06
> Running 21 test cases...
> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/tasks_test.cpp:282: error
> in "testOverrun": Failed to detect step overrun in Thread
> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/tasks_test.cpp:284: error
> in "testOverrun": Failed to execute finalize in emergencyStop
> 2.515 [CRITICAL][PeriodicThread::stop] The ORThread thread seems to be
> blocked ( ret was 49 .)
>
> *** 2 failures detected in test suite "Master Test Suite"
>
 
> <snip>
>
>   8/ 11 Testing program-test
> Test command: /opt/build/orocos/branches/rtt-1.10/tests/program-test
> Test timeout computed to be: 9.99988e+06
> Running 19 test cases...
> Asserted :0 with :Program script did not detect exported function failure.
> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/function_test.cpp:334:
> error in "testFunctionFail": Runtime error encountered on line 12.
>
> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/function_test.cpp:335:
> error in "testFunctionFail": Program stalled on line 12.
>
 
Com'on ! This was fixed ! Are we having a build system issue here ? can you
ldd program-test to check it links with the build dir's libs ?
 
 
>
>
> *** 2 failures detected in test suite "Master Test Suite"
> 

>
>
> Snow Leopard compile failures. I think that this is a boost problem. If you
> set the types explicitly, the error still exists.
>
> [ 86%] Building CXX object tests/CMakeFiles/core-test.dir/time_test.cpp.o
> /opt/local/include/boost/test/floating_point_comparison.hpp: In member
> function ‘boost::test_tools::predicate_result
> boost::test_tools::check_is_close_t::operator()(FPT1, FPT2,
> boost::test_tools::percent_tolerance_t<ToleranceBaseType>,
> boost::test_tools::floating_point_comparison_type) const [with FPT1 = long
> long int, FPT2 = long long int, ToleranceBaseType = int]:
> /opt/local/include/boost/test/test_tools.hpp:523:   instantiated from ‘bool
> boost::test_tools::tt_detail::check_frwd(Pred, const
> boost::unit_test::lazy_ostream&, boost::test_tools::const_string, size_t,
> boost::test_tools::tt_detail::tool_level,
> boost::test_tools::tt_detail::check_type, const Arg0&, const char*, const
> Arg1&, const char*, const Arg2&, const char*) [with Pred =
> boost::test_tools::check_is_close_t, Arg0 = RTT::nsecs, Arg1 = long long
> int, Arg2 = boost::test_tools::percent_tolerance_t<int>]> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/time_test.cpp:113:
> instantiated from here
> /opt/local/include/boost/test/floating_point_comparison.hpp:229: error:
> invalid application of ‘sizeof’ to incomplete type
> ‘boost::STATIC_ASSERTION_FAILURE<false>> make[2]: *** [tests/CMakeFiles/core-test.dir/time_test.cpp.o] Error 1
> make[1]: *** [tests/CMakeFiles/core-test.dir/all] Error 2
> make: *** [all] Error 2
> 

>

Maybe BOOST_REQUIRE_CLOSE only wants to work on floating point numbers, and
not on integers ?

Peter

RTT 1.10 branch 'release-ready' and misc.

On Sep 11, 2009, at 09:23 , Peter Soetens wrote:

> On Fri, Sep 11, 2009 at 14:40, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Sep 11, 2009, at 05:15 , Peter Soetens wrote:
>
>> I've spent the past two days cleaning and testing the rtt-1.10
>> branch[1]. It looks in good shape (Debian etc) but I might have
>> forgotten a few bits[2]. Feel free to run a make check on your
>> platform (lxrt,win32,macosx prefered), if there are no complaints,
>> it goes out the door next monday, together with ocl-1.10 [3]
>>
>> The git rtt-2.0-mainline has the version number 1.91.0, and debian
>> packages appear to work too. I have on github / rtt-2.0-interproc
>> an mqueue 'out-of-band' real-time data-flow transport working in a
>> separate branch, but it needs more testing with Xenomai before I
>> merge it on the mainline. Especially sending over
>> std::vector<double> and variants will probably not work out of the
>> box yet.
>>
>> I'm a bit behind schedule, but no serious problems seem to come up
>> either.
>>
>> Peter
>>
>> [1] svn co http://svn.mech.kuleuven.be/repos/orocos/branches/rtt/rtt-1.10
>> [2] I vaguely remember something about a breakUpdateHook() patch
>> [3] svn co http://svn.mech.kuleuven.be/repos/orocos/branches/ocl/ocl-1.10
>
> macosx leopard 10.5.8 plus boost v1.37, compiles fine. 2 tests fail
> - results below
> macosx snow leopard 10.6.1 plus boost v1.40 compiles libraries, but
> fails to compile tests. Build results below.
>

<sni

> Leopard test results
>

>  4/ 11 Testing task-test
> Test command: /opt/build/orocos/branches/rtt-1.10/tests/task-test
> Test timeout computed to be: 9.99988e+06
> Running 21 test cases...
> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/tasks_test.cpp:282:  
> error in "testOverrun": Failed to detect step overrun in Thread
> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/tasks_test.cpp:284:  
> error in "testOverrun": Failed to execute finalize in emergencyStop
> 2.515 [CRITICAL][PeriodicThread::stop] The ORThread thread seems to  
> be blocked ( ret was 49 .)
>
> *** 2 failures detected in test suite "Master Test Suite"
>
> <snip>
>
>   8/ 11 Testing program-test
> Test command: /opt/build/orocos/branches/rtt-1.10/tests/program-test
> Test timeout computed to be: 9.99988e+06
> Running 19 test cases...
> Asserted :0 with :Program script did not detect exported function  
> failure.
> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/function_test.cpp: 
> 334: error in "testFunctionFail": Runtime error encountered on line  
> 12.
>
> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/function_test.cpp: 
> 335: error in "testFunctionFail": Program stalled on line 12.
>
> Com'on ! This was fixed ! Are we having a build system issue here ?  
> can you ldd program-test to check it links with the build dir's libs ?
 
AWW CRAP!!! My fault! Damn DYLD_LIBRARY_PATH set to other install. Too  
many orocos installs ... all tests pass under Leopard now.
 
My workflow obviously needs polishing also ... :-)
 
 
>  Snow Leopard compile failures. I think that this is a boost  
> problem. If you set the types explicitly, the error still exists.
> <code>
> [ 86%] Building CXX object tests/CMakeFiles/core-test.dir/ 
> time_test.cpp.o
> /opt/local/include/boost/test/floating_point_comparison.hpp: In  
> member function ‘boost::test_tools::predicate_result  
> boost::test_tools::check_is_close_t::operator()(FPT1, FPT2,  
> boost::test_tools::percent_tolerance_t<ToleranceBaseType>,  
> boost::test_tools::floating_point_comparison_type) const [with FPT1  
> = long long int, FPT2 = long long int, ToleranceBaseType = int]:
> /opt/local/include/boost/test/test_tools.hpp:523:   instantiated  
> from ‘bool boost::test_tools::tt_detail::check_frwd(Pred, const  
> boost::unit_test::lazy_ostream&, boost::test_tools::const_string,  
> size_t, boost::test_tools::tt_detail::tool_level,  
> boost::test_tools::tt_detail::check_type, const Arg0&, const char*,  
> const Arg1&, const char*, const Arg2&, const char*) [with Pred =  
> boost::test_tools::check_is_close_t, Arg0 = RTT::nsecs, Arg1 = long  
> long int, Arg2 = boost::test_tools::percent_tolerance_t<int>]> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/time_test.cpp:113:    
> instantiated from here
> /opt/local/include/boost/test/floating_point_comparison.hpp:229:  
> error: invalid application of ‘sizeof’ to incomplete type  
> ‘boost::STATIC_ASSERTION_FAILURE<false>> make[2]: *** [tests/CMakeFiles/core-test.dir/time_test.cpp.o] Error 1
> make[1]: *** [tests/CMakeFiles/core-test.dir/all] Error 2
> make: *** [all] Error 2
> 

>
> Maybe BOOST_REQUIRE_CLOSE only wants to work on floating point
> numbers, and not on integers ?

I tried casting to (long long) and (double) and no luck. I'll look at
it again later today ... interestingly it is only complaining on one
of the several checks in that block.
S

RTT 1.10 branch 'release-ready' and misc.

On Sep 11, 2009, at 09:30 , Stephen Roderick wrote:

> On Sep 11, 2009, at 09:23 , Peter Soetens wrote:
>
>> On Fri, Sep 11, 2009 at 14:40, S Roderick <kiwi [dot] net [..] ...> wrote:
>> On Sep 11, 2009, at 05:15 , Peter Soetens wrote:
>>
>>> I've spent the past two days cleaning and testing the rtt-1.10
>>> branch[1]. It looks in good shape (Debian etc) but I might have
>>> forgotten a few bits[2]. Feel free to run a make check on your
>>> platform (lxrt,win32,macosx prefered), if there are no complaints,
>>> it goes out the door next monday, together with ocl-1.10 [3]
>>>
>>> The git rtt-2.0-mainline has the version number 1.91.0, and debian
>>> packages appear to work too. I have on github / rtt-2.0-interproc
>>> an mqueue 'out-of-band' real-time data-flow transport working in a
>>> separate branch, but it needs more testing with Xenomai before I
>>> merge it on the mainline. Especially sending over
>>> std::vector<double> and variants will probably not work out of the
>>> box yet.
>>>
>>> I'm a bit behind schedule, but no serious problems seem to come up
>>> either.
>>>
>>> Peter
>>>
>>> [1] svn co http://svn.mech.kuleuven.be/repos/orocos/branches/rtt/rtt-1.10
>>> [2] I vaguely remember something about a breakUpdateHook() patch
>>> [3] svn co http://svn.mech.kuleuven.be/repos/orocos/branches/ocl/ocl-1.10
>>
>> macosx leopard 10.5.8 plus boost v1.37, compiles fine. 2 tests fail
>> - results below
>> macosx snow leopard 10.6.1 plus boost v1.40 compiles libraries, but
>> fails to compile tests. Build results below.
>>
>
> <sni

>
>> Leopard test results
>>

>>  4/ 11 Testing task-test
>> Test command: /opt/build/orocos/branches/rtt-1.10/tests/task-test
>> Test timeout computed to be: 9.99988e+06
>> Running 21 test cases...
>> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/tasks_test.cpp:282:  
>> error in "testOverrun": Failed to detect step overrun in Thread
>> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/tasks_test.cpp:284:  
>> error in "testOverrun": Failed to execute finalize in emergencyStop
>> 2.515 [CRITICAL][PeriodicThread::stop] The ORThread thread seems to  
>> be blocked ( ret was 49 .)
>>
>> *** 2 failures detected in test suite "Master Test Suite"
>>
>> <snip>
>>
>>   8/ 11 Testing program-test
>> Test command: /opt/build/orocos/branches/rtt-1.10/tests/program-test
>> Test timeout computed to be: 9.99988e+06
>> Running 19 test cases...
>> Asserted :0 with :Program script did not detect exported function  
>> failure.
>> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/function_test.cpp: 
>> 334: error in "testFunctionFail": Runtime error encountered on line  
>> 12.
>>
>> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/function_test.cpp: 
>> 335: error in "testFunctionFail": Program stalled on line 12.
>>
>> Com'on ! This was fixed ! Are we having a build system issue here ?  
>> can you ldd program-test to check it links with the build dir's  
>> libs ?
>
> AWW CRAP!!! My fault! Damn DYLD_LIBRARY_PATH set to other install.  
> Too many orocos installs ... all tests pass under Leopard now.
>
> My workflow obviously needs polishing also ... :-)
>
>
>>  Snow Leopard compile failures. I think that this is a boost  
>> problem. If you set the types explicitly, the error still exists.
>> <code>
>> [ 86%] Building CXX object tests/CMakeFiles/core-test.dir/ 
>> time_test.cpp.o
>> /opt/local/include/boost/test/floating_point_comparison.hpp: In  
>> member function ‘boost::test_tools::predicate_result  
>> boost::test_tools::check_is_close_t::operator()(FPT1, FPT2,  
>> boost::test_tools::percent_tolerance_t<ToleranceBaseType>,  
>> boost::test_tools::floating_point_comparison_type) const [with FPT1  
>> = long long int, FPT2 = long long int, ToleranceBaseType = int]:
>> /opt/local/include/boost/test/test_tools.hpp:523:   instantiated  
>> from ‘bool boost::test_tools::tt_detail::check_frwd(Pred, const  
>> boost::unit_test::lazy_ostream&, boost::test_tools::const_string,  
>> size_t, boost::test_tools::tt_detail::tool_level,  
>> boost::test_tools::tt_detail::check_type, const Arg0&, const char*,  
>> const Arg1&, const char*, const Arg2&, const char*) [with Pred =  
>> boost::test_tools::check_is_close_t, Arg0 = RTT::nsecs, Arg1 = long  
>> long int, Arg2 = boost::test_tools::percent_tolerance_t<int>]>> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/time_test.cpp: 
>> 113:   instantiated from here
>> /opt/local/include/boost/test/floating_point_comparison.hpp:229:  
>> error: invalid application of ‘sizeof’ to incomplete type  
>> ‘boost::STATIC_ASSERTION_FAILURE<false>>> make[2]: *** [tests/CMakeFiles/core-test.dir/time_test.cpp.o] Error 1
>> make[1]: *** [tests/CMakeFiles/core-test.dir/all] Error 2
>> make: *** [all] Error 2
>> 

>>
>> Maybe BOOST_REQUIRE_CLOSE only wants to work on floating point
>> numbers, and not on integers ?
>
> I tried casting to (long long) and (double) and no luck. I'll look
> at it again later today ... interestingly it is only complaining on
> one of the several checks in that block.
> S

Additional patches

Prevent compiler warning
{{{
===================================================================
--- src/os/macosx/fosi.c (revision 30522)
+++ src/os/macosx/fosi.c (working copy)
@@ -46,7 +46,7 @@
va_start (list, fmt);
vsprintf(printkbuf, fmt, list);
va_end (list);
- return printf(printkbuf);
+ return printf("%s", printkbuf);
}

}}}

Fix boost trouble
{{{
Index: tests/time_test.cpp
===================================================================
--- tests/time_test.cpp (revision 30522)
+++ tests/time_test.cpp (working copy)
@@ -110,12 +110,12 @@
int margin = 1;
int small_margin = 10; // 10% of 10ns : allow a one-off.

- BOOST_REQUIRE_CLOSE( long_ns , TimeService::ticks2nsecs
( TimeService::nsecs2ticks( long_ns )), margin );
- BOOST_REQUIRE_CLOSE( normal_ns, TimeService::ticks2nsecs
( TimeService::nsecs2ticks( normal_ns )), margin );
- BOOST_REQUIRE_CLOSE( small_ns , TimeService::ticks2nsecs
( TimeService::nsecs2ticks( small_ns )), small_margin );
- BOOST_REQUIRE_CLOSE( long_t , TimeService::nsecs2ticks
( TimeService::ticks2nsecs( long_t )), margin );
- BOOST_REQUIRE_CLOSE( normal_t, TimeService::nsecs2ticks
( TimeService::ticks2nsecs( normal_t )), margin );
- BOOST_REQUIRE_CLOSE( small_t , TimeService::nsecs2ticks
( TimeService::ticks2nsecs( small_t )), small_margin );
+ BOOST_REQUIRE_CLOSE( (double)long_ns , (double)
TimeService::ticks2nsecs( TimeService::nsecs2ticks( long_ns )),
margin );
+ BOOST_REQUIRE_CLOSE( (double)normal_ns, (double)
TimeService::ticks2nsecs( TimeService::nsecs2ticks( normal_ns )),
margin );
+ BOOST_REQUIRE_CLOSE( (double)small_ns , (double)
TimeService::ticks2nsecs( TimeService::nsecs2ticks( small_ns )),
small_margin );
+ BOOST_REQUIRE_CLOSE( (double)long_t , (double)
TimeService::nsecs2ticks( TimeService::ticks2nsecs( long_t )), margin );
+ BOOST_REQUIRE_CLOSE( (double)normal_t, (double)
TimeService::nsecs2ticks( TimeService::ticks2nsecs( normal_t )),
margin );
+ BOOST_REQUIRE_CLOSE( (double)small_t , (double)
TimeService::nsecs2ticks( TimeService::ticks2nsecs( small_t )),
small_margin );
}

BOOST_AUTO_TEST_CASE( testTimeProgress )
}}}

RTT 1.10 branch 'release-ready' and misc.

On Sun, Sep 13, 2009 at 21:53, S Roderick <kiwi [dot] net [..] ...> wrote:
>
> On Sep 11, 2009, at 09:30 , Stephen Roderick wrote:
>
> On Sep 11, 2009, at 09:23 , Peter Soetens wrote:
>
> On Fri, Sep 11, 2009 at 14:40, S Roderick <kiwi [dot] net [..] ...> wrote:
>>
>> On Sep 11, 2009, at 05:15 , Peter Soetens wrote:
>>
>> I've spent the past two days cleaning and testing the rtt-1.10 branch[1]. It looks in good shape (Debian etc) but I might have forgotten a few bits[2]. Feel free to run a make check on your platform (lxrt,win32,macosx prefered), if there are no complaints, it goes out the door next monday, together with ocl-1.10 [3]
>>
>> The git rtt-2.0-mainline has the version number 1.91.0, and debian packages appear to work too. I have on github / rtt-2.0-interproc an mqueue 'out-of-band' real-time data-flow transport working in a separate branch, but it needs more testing with Xenomai before I merge it on the mainline. Especially sending over std::vector<double> and variants will probably not work out of the box yet.
>>
>> I'm a bit behind schedule, but no serious problems seem to come up either.
>>
>> Peter
>>
>> [1] svn co http://svn.mech.kuleuven.be/repos/orocos/branches/rtt/rtt-1.10
>> [2] I vaguely remember something about a breakUpdateHook() patch
>> [3] svn co http://svn.mech.kuleuven.be/repos/orocos/branches/ocl/ocl-1.10
>>
>> macosx leopard 10.5.8 plus boost v1.37, compiles fine. 2 tests fail - results below
>> macosx snow leopard 10.6.1 plus boost v1.40 compiles libraries, but fails to compile tests. Build results below.
>
> <sni

>>
>> Leopard test results
>>

>>  4/ 11 Testing task-test
>> Test command: /opt/build/orocos/branches/rtt-1.10/tests/task-test
>> Test timeout computed to be: 9.99988e+06
>> Running 21 test cases...
>> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/tasks_test.cpp:282: error in "testOverrun": Failed to detect step overrun in Thread
>> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/tasks_test.cpp:284: error in "testOverrun": Failed to execute finalize in emergencyStop
>> 2.515 [CRITICAL][PeriodicThread::stop] The ORThread thread seems to be blocked ( ret was 49 .)
>> *** 2 failures detected in test suite "Master Test Suite"
>>
>> <snip>
>>   8/ 11 Testing program-test
>> Test command: /opt/build/orocos/branches/rtt-1.10/tests/program-test
>> Test timeout computed to be: 9.99988e+06
>> Running 19 test cases...
>> Asserted :0 with :Program script did not detect exported function failure.
>> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/function_test.cpp:334: error in "testFunctionFail": Runtime error encountered on line 12.
>> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/function_test.cpp:335: error in "testFunctionFail": Program stalled on line 12.
>
> Com'on ! This was fixed ! Are we having a build system issue here ? can you ldd program-test to check it links with the build dir's libs ?
>
> AWW CRAP!!! My fault! Damn DYLD_LIBRARY_PATH set to other install. Too many orocos installs ... all tests pass under Leopard now.
> My workflow obviously needs polishing also ... :-)
>
>  Snow Leopard compile failures. I think that this is a boost problem. If you set the types explicitly, the error still exists.
>>
>> <code>
>> [ 86%] Building CXX object tests/CMakeFiles/core-test.dir/time_test.cpp.o
>> /opt/local/include/boost/test/floating_point_comparison.hpp: In member function ‘boost::test_tools::predicate_result boost::test_tools::check_is_close_t::operator()(FPT1, FPT2, boost::test_tools::percent_tolerance_t<ToleranceBaseType>, boost::test_tools::floating_point_comparison_type) const [with FPT1 = long long int, FPT2 = long long int, ToleranceBaseType = int]:
>> /opt/local/include/boost/test/test_tools.hpp:523:   instantiated from ‘bool boost::test_tools::tt_detail::check_frwd(Pred, const boost::unit_test::lazy_ostream&, boost::test_tools::const_string, size_t, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, const Arg0&, const char*, const Arg1&, const char*, const Arg2&, const char*) [with Pred = boost::test_tools::check_is_close_t, Arg0 = RTT::nsecs, Arg1 = long long int, Arg2 = boost::test_tools::percent_tolerance_t<int>]>> /opt/code/nrl/orocos/branch-1.10/rtt-1.10/tests/time_test.cpp:113:   instantiated from here
>> /opt/local/include/boost/test/floating_point_comparison.hpp:229: error: invalid application of ‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE<false>>> make[2]: *** [tests/CMakeFiles/core-test.dir/time_test.cpp.o] Error 1
>> make[1]: *** [tests/CMakeFiles/core-test.dir/all] Error 2
>> make: *** [all] Error 2
>> 

>
> Maybe BOOST_REQUIRE_CLOSE only wants to work on floating point numbers, and not on integers ?
>
> I tried casting to (long long) and (double) and no luck. I'll look at it again later today ... interestingly it is only complaining on one of the several checks in that block.
> S
>
> Additional patches
> Prevent compiler warning
> {{{
> ===================================================================
> --- src/os/macosx/fosi.c (revision 30522)
> +++ src/os/macosx/fosi.c (working copy)
> @@ -46,7 +46,7 @@
>      va_start (list, fmt);
>      vsprintf(printkbuf, fmt, list);
>      va_end (list);
> -    return printf(printkbuf);
> +    return printf("%s", printkbuf);
>  }
>
> }}}
> Fix boost trouble
> {{{
> Index: tests/time_test.cpp
> ===================================================================
> --- tests/time_test.cpp (revision 30522)
> +++ tests/time_test.cpp (working copy)
> @@ -110,12 +110,12 @@
>      int margin = 1;
>      int small_margin = 10; // 10% of 10ns : allow a one-off.
>
> -    BOOST_REQUIRE_CLOSE( long_ns  , TimeService::ticks2nsecs( TimeService::nsecs2ticks( long_ns )), margin );
> -    BOOST_REQUIRE_CLOSE( normal_ns, TimeService::ticks2nsecs( TimeService::nsecs2ticks( normal_ns )), margin );
> -    BOOST_REQUIRE_CLOSE( small_ns , TimeService::ticks2nsecs( TimeService::nsecs2ticks( small_ns )), small_margin );
> -    BOOST_REQUIRE_CLOSE( long_t  , TimeService::nsecs2ticks( TimeService::ticks2nsecs( long_t )), margin );
> -    BOOST_REQUIRE_CLOSE( normal_t, TimeService::nsecs2ticks( TimeService::ticks2nsecs( normal_t )), margin );
> -    BOOST_REQUIRE_CLOSE( small_t , TimeService::nsecs2ticks( TimeService::ticks2nsecs( small_t )), small_margin );
> +    BOOST_REQUIRE_CLOSE( (double)long_ns  , (double)TimeService::ticks2nsecs( TimeService::nsecs2ticks( long_ns )), margin );
> +    BOOST_REQUIRE_CLOSE( (double)normal_ns, (double)TimeService::ticks2nsecs( TimeService::nsecs2ticks( normal_ns )), margin );
> +    BOOST_REQUIRE_CLOSE( (double)small_ns , (double)TimeService::ticks2nsecs( TimeService::nsecs2ticks( small_ns )), small_margin );
> +    BOOST_REQUIRE_CLOSE( (double)long_t  , (double)TimeService::nsecs2ticks( TimeService::ticks2nsecs( long_t )), margin );
> +    BOOST_REQUIRE_CLOSE( (double)normal_t, (double)TimeService::nsecs2ticks( TimeService::ticks2nsecs( normal_t )), margin );
> +    BOOST_REQUIRE_CLOSE( (double)small_t , (double)TimeService::nsecs2ticks( TimeService::ticks2nsecs( small_t )), small_margin );
>  }
>
>  BOOST_AUTO_TEST_CASE( testTimeProgress )
> }}}

I fixed these, thanks. For the fosi.c, I removed the whole
implementation since it was dead code.

Peter

RTT 1.10 branch 'release-ready' and misc.

On Sep 14, 2009, at 04:47 , Peter Soetens wrote:

> On Sun, Sep 13, 2009 at 21:53, S Roderick <kiwi [dot] net [..] ...> wrote:
>>
>> On Sep 11, 2009, at 09:30 , Stephen Roderick wrote:
>>
>> On Sep 11, 2009, at 09:23 , Peter Soetens wrote:
>>
>> On Fri, Sep 11, 2009 at 14:40, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>
>>> On Sep 11, 2009, at 05:15 , Peter Soetens wrote:
>>>
>>> I've spent the past two days cleaning and testing the rtt-1.10
>>> branch[1]. It looks in good shape (Debian etc) but I might have
>>> forgotten a few bits[2]. Feel free to run a make check on your
>>> platform (lxrt,win32,macosx prefered), if there are no complaints,
>>> it goes out the door next monday, together with ocl-1.10 [3]
>>>
>>> The git rtt-2.0-mainline has the version number 1.91.0, and debian
>>> packages appear to work too. I have on github / rtt-2.0-interproc
>>> an mqueue 'out-of-band' real-time data-flow transport working in a
>>> separate branch, but it needs more testing with Xenomai before I
>>> merge it on the mainline. Especially sending over
>>> std::vector<double> and variants will probably not work out of the
>>> box yet.
>>>
>>> I'm a bit behind schedule, but no serious problems seem to come up
>>> either.
>>>
>>> Peter
>>>
>>> [1] svn co http://svn.mech.kuleuven.be/repos/orocos/branches/rtt/rtt-1.10
>>> [2] I vaguely remember something about a breakUpdateHook() patch
>>> [3] svn co http://svn.mech.kuleuven.be/repos/orocos/branches/ocl/ocl-1.10

Deal with boost >= v1.38 spirit namespace renaming ... tested with v1.40

{{{
diff --git a/src/scripting/Parser.cpp b/src/scripting/Parser.cpp
index a6d973a..9b39437 100644
--- a/src/scripting/Parser.cpp
+++ b/src/scripting/Parser.cpp
@@ -197,7 +197,7 @@ namespace RTT
CommandParser parser( tc, !dodispatch );
try
{
- boost::spirit::parse_info<iter_t> ret = parse( parsebegin,
parseend, parser.parser(), SKIP_PARSER );
+ boost_spirit::parse_info<iter_t> ret = parse( parsebegin,
parseend, parser.parser(), SKIP_PARSER );
if ( ! ret.hit )
throw parse_exception_parser_fail();
}
diff --git a/src/scripting/parser-types.hpp b/src/scripting/parser-
types.hpp
index 0aa1e83..82c610e 100644
--- a/src/scripting/parser-types.hpp
+++ b/src/scripting/parser-types.hpp
@@ -37,7 +37,15 @@
#ifndef PARSER_TYPES_HPP
#define PARSER_TYPES_HPP

+#include <boost/version.hp

+
+#if BOOST_VERSION >= 103800
+#include <boost/spirit/include/classic.hp

+namespace boost_spirit = boost::spirit::classic;
+#else
+namespace boost_spirit = boost::spirit;
#include <boost/spirit.hp

+#endif
#include "../CommandInterface.hpp"

namespace RTT
@@ -70,8 +78,8 @@ namespace RTT

- using namespace boost::spirit;
-
+ using namespace boost_spirit;
+
typedef std::string our_buffer_t;
typedef our_buffer_t::iterator our_iterator_t;
typedef position_iterator<our_iterator_t> our_pos_iter_t;
@@ -87,7 +95,7 @@ namespace RTT

//TODO: this typeof replaced by boost header might not work.
# define RULE( name, def ) \
-
boost
::spirit
::contiguous
<
boost
::spirit
::sequence
<
boost
::spirit
::alpha_parser,boost::spirit::kleene_star<boost::spirit::chset > > name = (def)
+
boost_spirit
::contiguous
<
boost_spirit
::sequence
<
boost_spirit
::alpha_parser,boost_spirit::kleene_star<boost_spirit::chset > name = (def)
//BOOST_TYPE_OF(( (def) ) name = (def)
// typeof is not a native c/c++ construct and is gcc specific
//__typeof__( (def) ) name = (def)
@@ -149,7 +157,7 @@ namespace RTT
//BOOST_TYPEOF_REGISTER_TYPE(X);
//TODO:
//typedef alternative<chlit<>, alternative<chlit<>,
alternative<chlit<>, alternative<chlit<>, chlit<> > > > > skip_parser_t;
- typedef
boost
::spirit
::alternative
<
boost
::spirit
::alternative
<
boost
::spirit
::alternative
<
boost
::spirit
::alternative<boost::spirit::confix_parser + typedef
boost_spirit
::alternative
<
boost_spirit
::alternative
<
boost_spirit
::alternative
<
boost_spirit
::alternative //typedef BOOST_TYPEOF( SKIP_PARSER ) skip_parser_t;
/*typedef
alternative sequence

}}}
>

RTT-examples-controller1-solution

Hi folks, once and again I came here with some basic questions...

I'm trying to run the example available on controller-1-solution but the
error below is reported. Are there anything to be implemented on this
example or I have anything wrong on my environment. I'm using rtt-1.8.5
and ocl-1.8.2 installed on /usr/local/

root@breno-HP:/home/breno/Desktop/rtt-exercises-1.8.1/controller-1-solution#
deployer-gnulinux --start deployment/application.cpf

0.009 [ ERROR ][DeploymentComponent::loadComponent] Unable to locate
Orocos plugin 'UseCase::Controller': unknown component type.
0.009 [ Warning][DeploymentComponent::loadComponents] Could not configure
'Controller': No such peer.
0.009 [ ERROR ][DeploymentComponent::loadComponent] Unable to locate
Orocos plugin 'UseCase::Plant': unknown component type.
0.009 [ Warning][DeploymentComponent::loadComponents] Could not configure
'Plant': No such peer.
0.009 [ ERROR ][DeploymentComponent::loadComponent] Unable to locate
Orocos plugin 'UseCase::Joystick': unknown component type.
0.009 [ Warning][DeploymentComponent::loadComponents] Could not configure
'Joystick': No such peer.
0.009 [ ERROR ][DeploymentComponent::loadComponent] Unable to locate
Orocos plugin 'UseCase::Automatic': unknown component type.
0.009 [ Warning][DeploymentComponent::loadComponents] Could not configure
'Automatic': No such peer.
0.010 [ ERROR ][deployer-gnulinux::main()] Failed to load a component:
aborting kick-start.

Thanks again for all,

Breno

RTT-examples-controller1-solution

On Mon, Sep 14, 2009 at 02:24, <breno [..] ...> wrote:
> Hi folks, once and again I came here with some basic questions...
>
> I'm trying to run the example available on controller-1-solution but the
> error below is reported. Are there anything to be implemented on this
> example or I have anything wrong on my environment. I'm using rtt-1.8.5
> and ocl-1.8.2 installed on /usr/local/
>
>
>
>
>
> root@breno-HP:/home/breno/Desktop/rtt-exercises-1.8.1/controller-1-solution#
> deployer-gnulinux --start deployment/application.cpf
>
>
>
> 0.009 [ ERROR  ][DeploymentComponent::loadComponent] Unable to locate
> Orocos plugin 'UseCase::Controller': unknown component type.

cd controller-1-solution
cmake .
make
deployer-gnulinux --start deployment/application.cpf

How hard can this be ?

Peter

RTT 1.10 branch 'release-ready' and misc.

On Oct 22, 2009, at 14:06 , Stephen Roderick wrote:

> On Sep 14, 2009, at 04:47 , Peter Soetens wrote:
>
>> On Sun, Sep 13, 2009 at 21:53, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>
>>> On Sep 11, 2009, at 09:30 , Stephen Roderick wrote:
>>>
>>> On Sep 11, 2009, at 09:23 , Peter Soetens wrote:
>>>
>>> On Fri, Sep 11, 2009 at 14:40, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>>
>>>> On Sep 11, 2009, at 05:15 , Peter Soetens wrote:
>>>>
>
> <sni

>
>>>>
>>> Fix boost trouble
>>> {{{
>>> Index: tests/time_test.cpp
>>> ===================================================================
>>> --- tests/time_test.cpp (revision 30522)
>>> +++ tests/time_test.cpp (working copy)
>>> @@ -110,12 +110,12 @@
>>> int margin = 1;
>>> int small_margin = 10; // 10% of 10ns : allow a one-off.
>>>
>>> - BOOST_REQUIRE_CLOSE( long_ns ,
>>> TimeService::ticks2nsecs( TimeService::nsecs2ticks( long_ns )),
>>> margin );
>>> - BOOST_REQUIRE_CLOSE( normal_ns,
>>> TimeService::ticks2nsecs( TimeService::nsecs2ticks( normal_ns )),
>>> margin );
>>> - BOOST_REQUIRE_CLOSE( small_ns ,
>>> TimeService::ticks2nsecs( TimeService::nsecs2ticks( small_ns )),
>>> small_margin );
>>> - BOOST_REQUIRE_CLOSE( long_t ,
>>> TimeService::nsecs2ticks( TimeService::ticks2nsecs( long_t )),
>>> margin );
>>> - BOOST_REQUIRE_CLOSE( normal_t,
>>> TimeService::nsecs2ticks( TimeService::ticks2nsecs( normal_t )),
>>> margin );
>>> - BOOST_REQUIRE_CLOSE( small_t ,
>>> TimeService::nsecs2ticks( TimeService::ticks2nsecs( small_t )),
>>> small_margin );
>>> + BOOST_REQUIRE_CLOSE( (double)long_ns ,
>>> (double
>>> )TimeService::ticks2nsecs( TimeService::nsecs2ticks( long_ns )),
>>> margin );
>>> + BOOST_REQUIRE_CLOSE( (double)normal_ns,
>>> (double
>>> )TimeService::ticks2nsecs( TimeService::nsecs2ticks( normal_ns )),
>>> margin );
>>> + BOOST_REQUIRE_CLOSE( (double)small_ns ,
>>> (double
>>> )TimeService::ticks2nsecs( TimeService::nsecs2ticks( small_ns )),
>>> small_margin );
>>> + BOOST_REQUIRE_CLOSE( (double)long_t ,
>>> (double
>>> )TimeService::nsecs2ticks( TimeService::ticks2nsecs( long_t )),
>>> margin );
>>> + BOOST_REQUIRE_CLOSE( (double)normal_t,
>>> (double
>>> )TimeService::nsecs2ticks( TimeService::ticks2nsecs( normal_t )),
>>> margin );
>>> + BOOST_REQUIRE_CLOSE( (double)small_t ,
>>> (double
>>> )TimeService::nsecs2ticks( TimeService::ticks2nsecs( small_t )),
>>> small_margin );
>>> }
>>>
>>> BOOST_AUTO_TEST_CASE( testTimeProgress )
>>> }}}
>>
>
> FYI my patch above causes a compile error under Ubuntu Jaunty with
> boost v1.34.1. I think boost changed something in between v1.34 and
> v1.39, where we started having problems. Haven't had a chance to dig
> any deeper yet ...
>
>

> /usr/include/boost/test/test_tools.hpp: In function 'void
> boost::test_tools::tt_detail::check_frwd(Pred,
> boost::wrap_stringstream&, boost::test_tools::const_string, size_t,
> boost::test_tools::tt_detail::tool_level,
> boost::test_tools::tt_detail::check_type, const Arg0&, const char*,
> const Arg1&, const char*, const Arg2&, const char*) [with Pred =
> boost::test_tools::check_is_close_t, Arg0 = double, Arg1 = long long
> int, Arg2 = boost::test_tools::percent_tolerance_t<int>]':
> /g/o/rtt/tests/time_test.cpp:113:   instantiated from here
> /usr/include/boost/test/test_tools.hpp:460: error: no match for call
> to '(boost::test_tools::check_is_close_t) (const double&, const long
> long int&, const boost::test_tools::percent_tolerance_t<int>&)'
> 

Attached patch fixes issues for earlier versions of boost. Somewhere
between 1.37 and 1.40, boost explicitly prevents using this floating
point comparison on integral types.

Tested on Ubuntu Jaunty with 1.37 and Snow Leopard with 1.40
S

RTT 1.10 branch 'release-ready' and misc.

On Tue, Oct 27, 2009 at 00:42, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Oct 22, 2009, at 14:06 , Stephen Roderick wrote:
>
>> On Sep 14, 2009, at 04:47 , Peter Soetens wrote:
>>
>>> On Sun, Sep 13, 2009 at 21:53, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>>
>>>> On Sep 11, 2009, at 09:30 , Stephen Roderick wrote:
>>>>
>>>> On Sep 11, 2009, at 09:23 , Peter Soetens wrote:
>>>>
>>>> On Fri, Sep 11, 2009 at 14:40, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>>>
>>>>> On Sep 11, 2009, at 05:15 , Peter Soetens wrote:
>>>>>
>>
>> <sni

>>
>>>>>
>>>> Fix boost trouble
>>>> {{{
>>>> Index: tests/time_test.cpp
>>>> ===================================================================
>>>> --- tests/time_test.cpp (revision 30522)
>>>> +++ tests/time_test.cpp (working copy)
>>>> @@ -110,12 +110,12 @@
>>>>    int margin = 1;
>>>>    int small_margin = 10; // 10% of 10ns : allow a one-off.
>>>>
>>>> -    BOOST_REQUIRE_CLOSE( long_ns  ,
>>>> TimeService::ticks2nsecs( TimeService::nsecs2ticks( long_ns )),
>>>> margin );
>>>> -    BOOST_REQUIRE_CLOSE( normal_ns,
>>>> TimeService::ticks2nsecs( TimeService::nsecs2ticks( normal_ns )),
>>>> margin );
>>>> -    BOOST_REQUIRE_CLOSE( small_ns ,
>>>> TimeService::ticks2nsecs( TimeService::nsecs2ticks( small_ns )),
>>>> small_margin );
>>>> -    BOOST_REQUIRE_CLOSE( long_t  ,
>>>> TimeService::nsecs2ticks( TimeService::ticks2nsecs( long_t )),
>>>> margin );
>>>> -    BOOST_REQUIRE_CLOSE( normal_t,
>>>> TimeService::nsecs2ticks( TimeService::ticks2nsecs( normal_t )),
>>>> margin );
>>>> -    BOOST_REQUIRE_CLOSE( small_t ,
>>>> TimeService::nsecs2ticks( TimeService::ticks2nsecs( small_t )),
>>>> small_margin );
>>>> +    BOOST_REQUIRE_CLOSE( (double)long_ns  ,
>>>> (double
>>>> )TimeService::ticks2nsecs( TimeService::nsecs2ticks( long_ns )),
>>>> margin );
>>>> +    BOOST_REQUIRE_CLOSE( (double)normal_ns,
>>>> (double
>>>> )TimeService::ticks2nsecs( TimeService::nsecs2ticks( normal_ns )),
>>>> margin );
>>>> +    BOOST_REQUIRE_CLOSE( (double)small_ns ,
>>>> (double
>>>> )TimeService::ticks2nsecs( TimeService::nsecs2ticks( small_ns )),
>>>> small_margin );
>>>> +    BOOST_REQUIRE_CLOSE( (double)long_t  ,
>>>> (double
>>>> )TimeService::nsecs2ticks( TimeService::ticks2nsecs( long_t )),
>>>> margin );
>>>> +    BOOST_REQUIRE_CLOSE( (double)normal_t,
>>>> (double
>>>> )TimeService::nsecs2ticks( TimeService::ticks2nsecs( normal_t )),
>>>> margin );
>>>> +    BOOST_REQUIRE_CLOSE( (double)small_t ,
>>>> (double
>>>> )TimeService::nsecs2ticks( TimeService::ticks2nsecs( small_t )),
>>>> small_margin );
>>>> }
>>>>
>>>> BOOST_AUTO_TEST_CASE( testTimeProgress )
>>>> }}}
>>>
>>
>> FYI my patch above causes a compile error under Ubuntu Jaunty with
>> boost v1.34.1. I think boost changed something in between v1.34 and
>> v1.39, where we started having problems. Haven't had a chance to dig
>> any deeper yet ...
>>
>>

>> /usr/include/boost/test/test_tools.hpp: In function 'void
>> boost::test_tools::tt_detail::check_frwd(Pred,
>> boost::wrap_stringstream&, boost::test_tools::const_string, size_t,
>> boost::test_tools::tt_detail::tool_level,
>> boost::test_tools::tt_detail::check_type, const Arg0&, const char*,
>> const Arg1&, const char*, const Arg2&, const char*) [with Pred =
>> boost::test_tools::check_is_close_t, Arg0 = double, Arg1 = long long
>> int, Arg2 = boost::test_tools::percent_tolerance_t<int>]':
>> /g/o/rtt/tests/time_test.cpp:113:   instantiated from here
>> /usr/include/boost/test/test_tools.hpp:460: error: no match for call
>> to '(boost::test_tools::check_is_close_t) (const double&, const long
>> long int&, const boost::test_tools::percent_tolerance_t<int>&)'
>> 

>
> Attached patch fixes issues for earlier versions of boost. Somewhere between
> 1.37 and 1.40, boost explicitly prevents using this floating point
> comparison on integral types.
>
> Tested on Ubuntu Jaunty with 1.37 and Snow Leopard with 1.40

Something is wrong with your local branch. This was already fixed on
September 14th on all branches.

Peter

RTT 1.10 branch 'release-ready' and misc.

On Oct 27, 2009, at 11:14 , Peter Soetens wrote:

> On Tue, Oct 27, 2009 at 00:42, S Roderick <kiwi [dot] net [..] ...> wrote:
>> On Oct 22, 2009, at 14:06 , Stephen Roderick wrote:
>>
>>> On Sep 14, 2009, at 04:47 , Peter Soetens wrote:
>>>
>>>> On Sun, Sep 13, 2009 at 21:53, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>>>
>>>>> On Sep 11, 2009, at 09:30 , Stephen Roderick wrote:
>>>>>
>>>>> On Sep 11, 2009, at 09:23 , Peter Soetens wrote:
>>>>>
>>>>> On Fri, Sep 11, 2009 at 14:40, S Roderick <kiwi [dot] net [..] ...>
>>>>> wrote:
>>>>>>
>>>>>> On Sep 11, 2009, at 05:15 , Peter Soetens wrote:
>>>>>>

<sni

>>>
>> Attached patch fixes issues for earlier versions of boost.
>> Somewhere between
>> 1.37 and 1.40, boost explicitly prevents using this floating point
>> comparison on integral types.
>>
>> Tested on Ubuntu Jaunty with 1.37 and Snow Leopard with 1.40
>
> Something is wrong with your local branch. This was already fixed on
> September 14th on all branches.
>
> Peter

Very likely is a problem at my end. The last change I see from you on
origin/master or origin/HEAD is
d74559df1f90cca9ed7267bc2cf9eaf3b98daba4 on 2009-07-23. I see activity
on origin/rtt-1.0-svn-updates in September, and activity in origin/
rtt-2.0-mainline just a few days ago.

My .git/config file is

[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
	ignorecase = true
[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = git://github.com/psoetens/orocos-rtt.git
[branch "master"]
	remote = origin
	merge = refs/heads/master
[branch "my-rtt-2.0-mainline"]
	remote = origin
	merge = refs/heads/rtt-2.0-mainline

Git pull on master says up-to-date.

Git pull on 2.x branch

$ git co my-rtt-2.0-mainline
Switched to branch 'my-rtt-2.0-mainline'
Your branch is ahead of 'origin/rtt-2.0-mainline' by 9 commits.
$ git pull origin HEAD
 From git://github.com/psoetens/orocos-rtt
  * branch            HEAD       -> FETCH_HEAD
Renaming src/corba/ApplicationServer.cpp => src/transports/corba/ 
ApplicationServer.cpp
Auto-merging src/transports/corba/ApplicationServer.cpp
CONFLICT (rename/modify): Merge conflict in src/transports/corba/ 
ApplicationServer.cpp
Renaming src/corba/CMakeLists.txt => src/transports/corba/CMakeLists.txt
 
<snip>
 
Auto-merging src/os/gnulinux/fosi.c
CONFLICT (content): Merge conflict in src/os/gnulinux/fosi.c
CONFLICT (delete/modify): src/targets/CMakeLists.txt deleted in HEAD  
and modified in d74559df1f90cca9ed7267bc2cf9eaf3b98daba4. Version  
d74559df1f90cca9ed7267bc2cf9eaf3b98daba4 of src/targets/CMakeLists.txt  
left in tree.
Automatic merge failed; fix conflicts and then commit the result.

So I will have to fix this.

But besides not getting updates on HEAD, I'm not seeing anything
wrong. I am new to git so I wouldn't be surprised if something is bust
at my end.

Got any ideas?
Stephen

RTT 1.10 branch 'release-ready' and misc.

On Tue, Oct 27, 2009 at 22:35, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
> On Oct 27, 2009, at 11:14 , Peter Soetens wrote:
>
>> On Tue, Oct 27, 2009 at 00:42, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>
>>> On Oct 22, 2009, at 14:06 , Stephen Roderick wrote:
>>>
>>>> On Sep 14, 2009, at 04:47 , Peter Soetens wrote:
>>>>
>>>>> On Sun, Sep 13, 2009 at 21:53, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>>>>
>>>>>> On Sep 11, 2009, at 09:30 , Stephen Roderick wrote:
>>>>>>
>>>>>> On Sep 11, 2009, at 09:23 , Peter Soetens wrote:
>>>>>>
>>>>>> On Fri, Sep 11, 2009 at 14:40, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>>>>>
>>>>>>> On Sep 11, 2009, at 05:15 , Peter Soetens wrote:
>>>>>>>
>
> <sni

>
>>>>
>>> Attached patch fixes issues for earlier versions of boost. Somewhere
>>> between
>>> 1.37 and 1.40, boost explicitly prevents using this floating point
>>> comparison on integral types.
>>>
>>> Tested on Ubuntu Jaunty with 1.37 and Snow Leopard with 1.40
>>
>> Something is wrong with your local branch. This was already fixed on
>> September 14th on all branches.
>>
>> Peter
>
> Very likely is a problem at my end. The last change I see from you on
> origin/master or origin/HEAD is d74559df1f90cca9ed7267bc2cf9eaf3b98daba4 on
> 2009-07-23. I see activity on origin/rtt-1.0-svn-updates in September, and
> activity in origin/rtt-2.0-mainline just a few days ago.

Oh god. When you said you were tracking, I though you were using the
svn trunk/branches for tracking 1.x using git-svn.. I'm seldomly
pushing the git branch (rtt-1.0-svn-patches) for 1.x, since I always
dcommit to svn and svn is the official trunk/branch. Also master is
indeed not used until 2.0 mainline is merged into master. You couldn't
know all that.

So leave your setup as is, and I'll repush rtt-1.0-svn-patches to git.
You'll need to rebase probably (I wouldn't merge if I were you because
this kind-of entangles your patches to the point where the merge
happended, while a rebase forces you to maintain and inspect the
differences with upstream.

Peter

RTT 1.10 branch 'release-ready' and misc.

On Oct 27, 2009, at 18:07 , Peter Soetens wrote:

> On Tue, Oct 27, 2009 at 22:35, Stephen Roderick <kiwi [dot] net [..] ...>
> wrote:
>> On Oct 27, 2009, at 11:14 , Peter Soetens wrote:
>>
>>> On Tue, Oct 27, 2009 at 00:42, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>>
>>>> On Oct 22, 2009, at 14:06 , Stephen Roderick wrote:
>>>>
>>>>> On Sep 14, 2009, at 04:47 , Peter Soetens wrote:
>>>>>
>>>>>> On Sun, Sep 13, 2009 at 21:53, S Roderick <kiwi [dot] net [..] ...>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Sep 11, 2009, at 09:30 , Stephen Roderick wrote:
>>>>>>>
>>>>>>> On Sep 11, 2009, at 09:23 , Peter Soetens wrote:
>>>>>>>
>>>>>>> On Fri, Sep 11, 2009 at 14:40, S Roderick <kiwi [dot] net [..] ...>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Sep 11, 2009, at 05:15 , Peter Soetens wrote:
>>>>>>>>
>>
>> <sni

>>
>>>>>
>>>> Attached patch fixes issues for earlier versions of boost.
>>>> Somewhere
>>>> between
>>>> 1.37 and 1.40, boost explicitly prevents using this floating point
>>>> comparison on integral types.
>>>>
>>>> Tested on Ubuntu Jaunty with 1.37 and Snow Leopard with 1.40
>>>
>>> Something is wrong with your local branch. This was already fixed on
>>> September 14th on all branches.
>>>
>>> Peter
>>
>> Very likely is a problem at my end. The last change I see from you on
>> origin/master or origin/HEAD is
>> d74559df1f90cca9ed7267bc2cf9eaf3b98daba4 on
>> 2009-07-23. I see activity on origin/rtt-1.0-svn-updates in
>> September, and
>> activity in origin/rtt-2.0-mainline just a few days ago.
>
> Oh god. When you said you were tracking, I though you were using the
> svn trunk/branches for tracking 1.x using git-svn.. I'm seldomly
> pushing the git branch (rtt-1.0-svn-patches) for 1.x, since I always
> dcommit to svn and svn is the official trunk/branch. Also master is
> indeed not used until 2.0 mainline is merged into master. You couldn't
> know all that.
>
> So leave your setup as is, and I'll repush rtt-1.0-svn-patches to git.
> You'll need to rebase probably (I wouldn't merge if I were you because
> this kind-of entangles your patches to the point where the merge
> happended, while a rebase forces you to maintain and inspect the
> differences with upstream.

Ok, that answers many questions I've had!! I'm git tracking the RTT
and OCL git repo's, and git-svn tracking KDL and BFL.

Am I better of git-svn tracking RTT and OCL from svn/trunk, for v1.x?
I don't want to make more work for you - you've got enough going on.
And I'm not exactly a "low volume" contributor ... ;-)

Cheers
Stephen

RTT 1.10 branch 'release-ready' and misc.

On Tue, Oct 27, 2009 at 23:37, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
> On Oct 27, 2009, at 18:07 , Peter Soetens wrote:
>
>> On Tue, Oct 27, 2009 at 22:35, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
>>>
>>> On Oct 27, 2009, at 11:14 , Peter Soetens wrote:
>>>
>>>> On Tue, Oct 27, 2009 at 00:42, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>>>
>>>>> On Oct 22, 2009, at 14:06 , Stephen Roderick wrote:
>>>>>
>>>>>> On Sep 14, 2009, at 04:47 , Peter Soetens wrote:
>>>>>>
>>>>>>> On Sun, Sep 13, 2009 at 21:53, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>>>>>>
>>>>>>>> On Sep 11, 2009, at 09:30 , Stephen Roderick wrote:
>>>>>>>>
>>>>>>>> On Sep 11, 2009, at 09:23 , Peter Soetens wrote:
>>>>>>>>
>>>>>>>> On Fri, Sep 11, 2009 at 14:40, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>>>>>>>
>>>>>>>>> On Sep 11, 2009, at 05:15 , Peter Soetens wrote:
>>>>>>>>>
>>>
>>> <sni

>>>
>>>>>>
>>>>> Attached patch fixes issues for earlier versions of boost. Somewhere
>>>>> between
>>>>> 1.37 and 1.40, boost explicitly prevents using this floating point
>>>>> comparison on integral types.
>>>>>
>>>>> Tested on Ubuntu Jaunty with 1.37 and Snow Leopard with 1.40
>>>>
>>>> Something is wrong with your local branch. This was already fixed on
>>>> September 14th on all branches.
>>>>
>>>> Peter
>>>
>>> Very likely is a problem at my end. The last change I see from you on
>>> origin/master or origin/HEAD is d74559df1f90cca9ed7267bc2cf9eaf3b98daba4
>>> on
>>> 2009-07-23. I see activity on origin/rtt-1.0-svn-updates in September,
>>> and
>>> activity in origin/rtt-2.0-mainline just a few days ago.
>>
>> Oh god. When you said you were tracking, I though you were using the
>> svn trunk/branches for tracking 1.x using git-svn.. I'm seldomly
>> pushing the git branch (rtt-1.0-svn-patches) for 1.x, since I always
>> dcommit to svn and svn is the official trunk/branch. Also master is
>> indeed not used until 2.0 mainline is merged into master. You couldn't
>> know all that.
>>
>> So leave your setup as is, and I'll repush rtt-1.0-svn-patches to git.
>> You'll need to rebase probably (I wouldn't merge if I were you because
>> this kind-of entangles your patches to the point where the merge
>> happended, while a rebase forces you to maintain and inspect the
>> differences with upstream.
>
> Ok, that answers many questions I've had!! I'm git tracking the RTT and OCL
> git repo's, and git-svn tracking KDL and BFL.
>
> Am I better of git-svn tracking RTT and OCL from svn/trunk, for v1.x? I
> don't want to make more work for you - you've got enough going on. And I'm
> not exactly a "low volume" contributor ... ;-)

Keep your setup. I'll modify my back/for porting scripts to do a git
push each time svn is updated.

Peter

RTT 1.10 branch 'release-ready' and misc.

On Oct 28, 2009, at 08:14 , Peter Soetens wrote:

> On Tue, Oct 27, 2009 at 23:37, Stephen Roderick <kiwi [dot] net [..] ...>
> wrote:
>> On Oct 27, 2009, at 18:07 , Peter Soetens wrote:
>>
>>> On Tue, Oct 27, 2009 at 22:35, Stephen Roderick <kiwi [dot] net [..] ...>
>>> wrote:
>>>>
>>>> On Oct 27, 2009, at 11:14 , Peter Soetens wrote:
>>>>
>>>>> On Tue, Oct 27, 2009 at 00:42, S Roderick <kiwi [dot] net [..] ...>
>>>>> wrote:
>>>>>>
>>>>>> On Oct 22, 2009, at 14:06 , Stephen Roderick wrote:
>>>>>>
>>>>>>> On Sep 14, 2009, at 04:47 , Peter Soetens wrote:
>>>>>>>
>>>>>>>> On Sun, Sep 13, 2009 at 21:53, S Roderick <kiwi [dot] net [..] ...>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Sep 11, 2009, at 09:30 , Stephen Roderick wrote:
>>>>>>>>>
>>>>>>>>> On Sep 11, 2009, at 09:23 , Peter Soetens wrote:
>>>>>>>>>
>>>>>>>>> On Fri, Sep 11, 2009 at 14:40, S Roderick <kiwi [dot] net [..] ...>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Sep 11, 2009, at 05:15 , Peter Soetens wrote:
>>>>>>>>>>
>>>>
>>>> <sni

>>>>
>>>>>>>
>>>>>> Attached patch fixes issues for earlier versions of boost.
>>>>>> Somewhere
>>>>>> between
>>>>>> 1.37 and 1.40, boost explicitly prevents using this floating
>>>>>> point
>>>>>> comparison on integral types.
>>>>>>
>>>>>> Tested on Ubuntu Jaunty with 1.37 and Snow Leopard with 1.40
>>>>>
>>>>> Something is wrong with your local branch. This was already
>>>>> fixed on
>>>>> September 14th on all branches.
>>>>>
>>>>> Peter
>>>>
>>>> Very likely is a problem at my end. The last change I see from
>>>> you on
>>>> origin/master or origin/HEAD is
>>>> d74559df1f90cca9ed7267bc2cf9eaf3b98daba4
>>>> on
>>>> 2009-07-23. I see activity on origin/rtt-1.0-svn-updates in
>>>> September,
>>>> and
>>>> activity in origin/rtt-2.0-mainline just a few days ago.
>>>
>>> Oh god. When you said you were tracking, I though you were using the
>>> svn trunk/branches for tracking 1.x using git-svn.. I'm seldomly
>>> pushing the git branch (rtt-1.0-svn-patches) for 1.x, since I always
>>> dcommit to svn and svn is the official trunk/branch. Also master is
>>> indeed not used until 2.0 mainline is merged into master. You
>>> couldn't
>>> know all that.
>>>
>>> So leave your setup as is, and I'll repush rtt-1.0-svn-patches to
>>> git.
>>> You'll need to rebase probably (I wouldn't merge if I were you
>>> because
>>> this kind-of entangles your patches to the point where the merge
>>> happended, while a rebase forces you to maintain and inspect the
>>> differences with upstream.
>>
>> Ok, that answers many questions I've had!! I'm git tracking the RTT
>> and OCL
>> git repo's, and git-svn tracking KDL and BFL.
>>
>> Am I better of git-svn tracking RTT and OCL from svn/trunk, for
>> v1.x? I
>> don't want to make more work for you - you've got enough going on.
>> And I'm
>> not exactly a "low volume" contributor ... ;-)
>
> Keep your setup. I'll modify my back/for porting scripts to do a git
> push each time svn is updated.

Done for RTT and OCL. Not too painful actually ...

Thanks, mate
Stephen

RTT-examples-controller1-solution

> On Mon, Sep 14, 2009 at 02:24, <breno [..] ...> wrote:
>> Hi folks, once and again I came here with some basic questions...
>>
>> I'm trying to run the example available on controller-1-solution but the
>> error below is reported. Are there anything to be implemented on this
>> example or I have anything wrong on my environment. I'm using rtt-1.8.5
>> and ocl-1.8.2 installed on /usr/local/
>>
>>
>>
>>
>>
>> root@breno-HP:/home/breno/Desktop/rtt-exercises-1.8.1/controller-1-solution#
>> deployer-gnulinux --start deployment/application.cpf
>>
>>
>>
>> 0.009 [ ERROR  ][DeploymentComponent::loadComponent] Unable to locate
>> Orocos plugin 'UseCase::Controller': unknown component type.
>
> cd controller-1-solution
> cmake .
> make
> deployer-gnulinux --start deployment/application.cpf
>
> How hard can this be ?
>
> Peter
>
Hi, thanks for you response and I trully hope you still have patience
because I need support from you.

I´m quite sure that I did ccmake .. and configured all paths needed.
Although I realized now that the system returned OCL >=1.4 not found. But
I trully have ocl installed on my system (\usr\local) because I runned all
others examples.
I could generate and executed make. Then deployer-gnulinux --start
deployment/application.cpf but the message returned was that showed
before.

I´m not expertise on all this stuff as you certainly are but it´s not so
hard to me. I´m doing by myself.

Thank you for any any word for support!!!!

Breno

RTT-examples-controller1-solution

On Tue, Sep 15, 2009 at 15:32, <breno [..] ...> wrote:
>> On Mon, Sep 14, 2009 at 02:24,  <breno [..] ...> wrote:
>>> Hi folks, once and again I came here with some basic questions...
>>>
>>> I'm trying to run the example available on controller-1-solution but the
>>> error below is reported. Are there anything to be implemented on this
>>> example or I have anything wrong on my environment. I'm using rtt-1.8.5
>>> and ocl-1.8.2 installed on /usr/local/
>>>
>>>
>>>
>>>
>>>
>>> root@breno-HP:/home/breno/Desktop/rtt-exercises-1.8.1/controller-1-solution#
>>> deployer-gnulinux --start deployment/application.cpf
>>>
>>>
>>>
>>> 0.009 [ ERROR  ][DeploymentComponent::loadComponent] Unable to locate
>>> Orocos plugin 'UseCase::Controller': unknown component type.
>>
>> cd controller-1-solution
>> cmake .
>> make
>> deployer-gnulinux --start deployment/application.cpf
>>
>> How hard can this be ?
>>
>> Peter
>>
> Hi, thanks for you response and I trully hope you still have patience
> because I need support from you.
>
> I´m quite sure that I did ccmake .. and configured all paths needed.
> Although I realized now that the system returned OCL >=1.4 not found. But
> I trully have ocl installed on my system (\usr\local) because I runned all
> others examples.
> I could generate and executed make. Then deployer-gnulinux --start
> deployment/application.cpf but the message returned was that showed
> before.
>
> I´m not expertise on all this stuff as you certainly are but it´s not so
> hard to me. I´m doing by myself.
>
> Thank you for any any word for support!!!!

Could you mail the orocos.log file that got generated during that run
? There must be a previous error that indicates why the imports
failed.

Peter

RTT-examples-controller1-solution

> On Tue, Sep 15, 2009 at 15:32, <breno [..] ...> wrote:
>>> On Mon, Sep 14, 2009 at 02:24,  <breno [..] ...> wrote:
>>>> Hi folks, once and again I came here with some basic questions...
>>>>
>>>> I'm trying to run the example available on controller-1-solution but
>>>> the
>>>> error below is reported. Are there anything to be implemented on this
>>>> example or I have anything wrong on my environment. I'm using
>>>> rtt-1.8.5
>>>> and ocl-1.8.2 installed on /usr/local/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> root@breno-HP:/home/breno/Desktop/rtt-exercises-1.8.1/controller-1-solution#
>>>> deployer-gnulinux --start deployment/application.cpf
>>>>
>>>>
>>>>
>>>> 0.009 [ ERROR  ][DeploymentComponent::loadComponent] Unable to locate
>>>> Orocos plugin 'UseCase::Controller': unknown component type.
>>>
>>> cd controller-1-solution
>>> cmake .
>>> make
>>> deployer-gnulinux --start deployment/application.cpf
>>>
>>> How hard can this be ?
>>>
>>> Peter
>>>
>> Hi, thanks for you response and I trully hope you still have patience
>> because I need support from you.
>>
>> I´m quite sure that I did ccmake .. and configured all paths needed.
>> Although I realized now that the system returned OCL >=1.4 not found.
>> But
>> I trully have ocl installed on my system (\usr\local) because I runned
>> all
>> others examples.
>> I could generate and executed make. Then deployer-gnulinux --start
>> deployment/application.cpf but the message returned was that showed
>> before.
>>
>> I´m not expertise on all this stuff as you certainly are but it´s not so
>> hard to me. I´m doing by myself.
>>
>> Thank you for any any word for support!!!!
>
> Could you mail the orocos.log file that got generated during that run
> ? There must be a previous error that indicates why the imports
> failed.
>
> Peter
>

Hi guys, I'm attaching my orocos.log...Actually I found out that the
application is looking for plugins on \usr\lib\rtt\gnulinux\plugins as you
can see on line 7 but all plugins were installed on
\usr\local\rtt\gnulinux\plugins...I'm trying now to figure out how to set
this variable to get it solved.

I think the error is there... Any tips are welcome!!!

Vielen Dank für alles,

Breno

RTT-examples-controller1-solution

On Sep 16, 2009, at 09:11 , breno [..] ... wrote:

>> On Tue, Sep 15, 2009 at 15:32, <breno [..] ...> wrote:
>>>> On Mon, Sep 14, 2009 at 02:24, <breno [..] ...> wrote:
>>>>> Hi folks, once and again I came here with some basic questions...
>>>>>
>>>>> I'm trying to run the example available on controller-1-solution
>>>>> but
>>>>> the
>>>>> error below is reported. Are there anything to be implemented on
>>>>> this
>>>>> example or I have anything wrong on my environment. I'm using
>>>>> rtt-1.8.5
>>>>> and ocl-1.8.2 installed on /usr/local/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> root@breno-HP:/home/breno/Desktop/rtt-exercises-1.8.1/
>>>>> controller-1-solution#
>>>>> deployer-gnulinux --start deployment/application.cpf
>>>>>
>>>>>
>>>>>
>>>>> 0.009 [ ERROR ][DeploymentComponent::loadComponent] Unable to
>>>>> locate
>>>>> Orocos plugin 'UseCase::Controller': unknown component type.
>>>>
>>>> cd controller-1-solution
>>>> cmake .
>>>> make
>>>> deployer-gnulinux --start deployment/application.cpf
>>>>
>>>> How hard can this be ?
>>>>
>>>> Peter
>>>>
>>> Hi, thanks for you response and I trully hope you still have
>>> patience
>>> because I need support from you.
>>>
>>> I´m quite sure that I did ccmake .. and configured all paths needed.
>>> Although I realized now that the system returned OCL >=1.4 not
>>> found.
>>> But
>>> I trully have ocl installed on my system (\usr\local) because I
>>> runned
>>> all
>>> others examples.
>>> I could generate and executed make. Then deployer-gnulinux --start
>>> deployment/application.cpf but the message returned was that showed
>>> before.
>>>
>>> I´m not expertise on all this stuff as you certainly are but it´s
>>> not so
>>> hard to me. I´m doing by myself.
>>>
>>> Thank you for any any word for support!!!!
>>
>> Could you mail the orocos.log file that got generated during that run
>> ? There must be a previous error that indicates why the imports
>> failed.
>>
>> Peter
>>
>
> Hi guys, I'm attaching my orocos.log...Actually I found out that the
> application is looking for plugins on \usr\lib\rtt\gnulinux\plugins
> as you
> can see on line 7 but all plugins were installed on
> \usr\local\rtt\gnulinux\plugins...I'm trying now to figure out how
> to set
> this variable to get it solved.
>
> I think the error is there... Any tips are welcome!!!

You need to tell the dynamic linker about your library path, with
something like the following for Linux

echo "\usr\local\rtt\gnulinux\plugins" | sudo tee -a /etc/ld.so.conf.d/
rtt-plugins.conf
sudo ldconfig

Another one for the FAQ ...

HTH
Stephen

RTT-examples-controller1-solution

> On Sep 16, 2009, at 09:11 , breno [..] ... wrote:
>
>>> On Tue, Sep 15, 2009 at 15:32, <breno [..] ...> wrote:
>>>>> On Mon, Sep 14, 2009 at 02:24, <breno [..] ...> wrote:
>>>>>> Hi folks, once and again I came here with some basic questions...
>>>>>>
>>>>>> I'm trying to run the example available on controller-1-solution
>>>>>> but
>>>>>> the
>>>>>> error below is reported. Are there anything to be implemented on
>>>>>> this
>>>>>> example or I have anything wrong on my environment. I'm using
>>>>>> rtt-1.8.5
>>>>>> and ocl-1.8.2 installed on /usr/local/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> root@breno-HP:/home/breno/Desktop/rtt-exercises-1.8.1/
>>>>>> controller-1-solution#
>>>>>> deployer-gnulinux --start deployment/application.cpf
>>>>>>
>>>>>>
>>>>>>
>>>>>> 0.009 [ ERROR ][DeploymentComponent::loadComponent] Unable to
>>>>>> locate
>>>>>> Orocos plugin 'UseCase::Controller': unknown component type.
>>>>>
>>>>> cd controller-1-solution
>>>>> cmake .
>>>>> make
>>>>> deployer-gnulinux --start deployment/application.cpf
>>>>>
>>>>> How hard can this be ?
>>>>>
>>>>> Peter
>>>>>
>>>> Hi, thanks for you response and I trully hope you still have
>>>> patience
>>>> because I need support from you.
>>>>
>>>> I´m quite sure that I did ccmake .. and configured all paths needed.
>>>> Although I realized now that the system returned OCL >=1.4 not
>>>> found.
>>>> But
>>>> I trully have ocl installed on my system (\usr\local) because I
>>>> runned
>>>> all
>>>> others examples.
>>>> I could generate and executed make. Then deployer-gnulinux --start
>>>> deployment/application.cpf but the message returned was that showed
>>>> before.
>>>>
>>>> I´m not expertise on all this stuff as you certainly are but it´s
>>>> not so
>>>> hard to me. I´m doing by myself.
>>>>
>>>> Thank you for any any word for support!!!!
>>>
>>> Could you mail the orocos.log file that got generated during that run
>>> ? There must be a previous error that indicates why the imports
>>> failed.
>>>
>>> Peter
>>>
>>
>> Hi guys, I'm attaching my orocos.log...Actually I found out that the
>> application is looking for plugins on \usr\lib\rtt\gnulinux\plugins
>> as you
>> can see on line 7 but all plugins were installed on
>> \usr\local\rtt\gnulinux\plugins...I'm trying now to figure out how
>> to set
>> this variable to get it solved.
>>
>> I think the error is there... Any tips are welcome!!!
>
>
> You need to tell the dynamic linker about your library path, with
> something like the following for Linux
>
> echo "\usr\local\rtt\gnulinux\plugins" | sudo tee -a /etc/ld.so.conf.d/
> rtt-plugins.conf
> sudo ldconfig
>
> Another one for the FAQ ...
>
> HTH
> Stephen

Hi, really sorry for being here again with the same issue...

I did all suggestions (thank you!!!) and I think the linker is looking for
libs correctly...However I think I have another problem that I mentioned a
long before about the message oroco-ocl-gnulinux >=1.4 not found after the
configure command on ccmake ..

That's odd to me because I do have ocl installed on \usr\local (version
1.8.2) and \usr\local\orocos (version 1.8.1). Could you figure out what is
missing? I could run all helloworld examples easier than that including
helloworld-deployment!!!

I'm attaching my .log again anyway!!!

Thanks,

Breno

RTT-examples-controller1-solution

breno [..] ... a écrit :
>> On Sep 16, 2009, at 09:11 , breno [..] ... wrote:
>>
>>
>>>> On Tue, Sep 15, 2009 at 15:32, <breno [..] ...> wrote:
>>>>
>>>>>> On Mon, Sep 14, 2009 at 02:24, <breno [..] ...> wrote:
>>>>>>
>>>>>>> Hi folks, once and again I came here with some basic questions...
>>>>>>>
>>>>>>> I'm trying to run the example available on controller-1-solution
>>>>>>> but
>>>>>>> the
>>>>>>> error below is reported. Are there anything to be implemented on
>>>>>>> this
>>>>>>> example or I have anything wrong on my environment. I'm using
>>>>>>> rtt-1.8.5
>>>>>>> and ocl-1.8.2 installed on /usr/local/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> root@breno-HP:/home/breno/Desktop/rtt-exercises-1.8.1/
>>>>>>> controller-1-solution#
>>>>>>> deployer-gnulinux --start deployment/application.cpf
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 0.009 [ ERROR ][DeploymentComponent::loadComponent] Unable to
>>>>>>> locate
>>>>>>> Orocos plugin 'UseCase::Controller': unknown component type.
>>>>>>>
>>>>>> cd controller-1-solution
>>>>>> cmake .
>>>>>> make
>>>>>> deployer-gnulinux --start deployment/application.cpf
>>>>>>
>>>>>> How hard can this be ?
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>>
>>>>> Hi, thanks for you response and I trully hope you still have
>>>>> patience
>>>>> because I need support from you.
>>>>>
>>>>> I´m quite sure that I did ccmake .. and configured all paths needed.
>>>>> Although I realized now that the system returned OCL >=1.4 not
>>>>> found.
>>>>> But
>>>>> I trully have ocl installed on my system (\usr\local) because I
>>>>> runned
>>>>> all
>>>>> others examples.
>>>>> I could generate and executed make. Then deployer-gnulinux --start
>>>>> deployment/application.cpf but the message returned was that showed
>>>>> before.
>>>>>
>>>>> I´m not expertise on all this stuff as you certainly are but it´s
>>>>> not so
>>>>> hard to me. I´m doing by myself.
>>>>>
>>>>> Thank you for any any word for support!!!!
>>>>>
>>>> Could you mail the orocos.log file that got generated during that run
>>>> ? There must be a previous error that indicates why the imports
>>>> failed.
>>>>
>>>> Peter
>>>>
>>>>
>>> Hi guys, I'm attaching my orocos.log...Actually I found out that the
>>> application is looking for plugins on \usr\lib\rtt\gnulinux\plugins
>>> as you
>>> can see on line 7 but all plugins were installed on
>>> \usr\local\rtt\gnulinux\plugins...I'm trying now to figure out how
>>> to set
>>> this variable to get it solved.
>>>
>>> I think the error is there... Any tips are welcome!!!
>>>
>> You need to tell the dynamic linker about your library path, with
>> something like the following for Linux
>>
>> echo "\usr\local\rtt\gnulinux\plugins" | sudo tee -a /etc/ld.so.conf.d/
>> rtt-plugins.conf
>> sudo ldconfig
>>
>> Another one for the FAQ ...
>>
>> HTH
>> Stephen
>>
>
>
> Hi, really sorry for being here again with the same issue...
>
> I did all suggestions (thank you!!!) and I think the linker is looking for
> libs correctly...However I think I have another problem that I mentioned a
> long before about the message oroco-ocl-gnulinux >=1.4 not found after the
> configure command on ccmake ..
>
> That's odd to me because I do have ocl installed on \usr\local (version
> 1.8.2) and \usr\local\orocos (version 1.8.1). Could you figure out what is
> missing? I could run all helloworld examples easier than that including
> helloworld-deployment!!!
>
> I'm attaching my .log again anyway!!!
>
> Thanks,
>
> Breno
Could you send the corresponding application.cpf file ?

RTT-examples-controller1-solution

> breno [..] ... a écrit :
>>> On Sep 16, 2009, at 09:11 , breno [..] ... wrote:
>>>
>>>
>>>>> On Tue, Sep 15, 2009 at 15:32, <breno [..] ...> wrote:
>>>>>
>>>>>>> On Mon, Sep 14, 2009 at 02:24, <breno [..] ...> wrote:
>>>>>>>
>>>>>>>> Hi folks, once and again I came here with some basic questions...
>>>>>>>>
>>>>>>>> I'm trying to run the example available on controller-1-solution
>>>>>>>> but
>>>>>>>> the
>>>>>>>> error below is reported. Are there anything to be implemented on
>>>>>>>> this
>>>>>>>> example or I have anything wrong on my environment. I'm using
>>>>>>>> rtt-1.8.5
>>>>>>>> and ocl-1.8.2 installed on /usr/local/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> root@breno-HP:/home/breno/Desktop/rtt-exercises-1.8.1/
>>>>>>>> controller-1-solution#
>>>>>>>> deployer-gnulinux --start deployment/application.cpf
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 0.009 [ ERROR ][DeploymentComponent::loadComponent] Unable to
>>>>>>>> locate
>>>>>>>> Orocos plugin 'UseCase::Controller': unknown component type.
>>>>>>>>
>>>>>>> cd controller-1-solution
>>>>>>> cmake .
>>>>>>> make
>>>>>>> deployer-gnulinux --start deployment/application.cpf
>>>>>>>
>>>>>>> How hard can this be ?
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>>>
>>>>>> Hi, thanks for you response and I trully hope you still have
>>>>>> patience
>>>>>> because I need support from you.
>>>>>>
>>>>>> I´m quite sure that I did ccmake .. and configured all paths needed.
>>>>>> Although I realized now that the system returned OCL >=1.4 not
>>>>>> found.
>>>>>> But
>>>>>> I trully have ocl installed on my system (\usr\local) because I
>>>>>> runned
>>>>>> all
>>>>>> others examples.
>>>>>> I could generate and executed make. Then deployer-gnulinux --start
>>>>>> deployment/application.cpf but the message returned was that showed
>>>>>> before.
>>>>>>
>>>>>> I´m not expertise on all this stuff as you certainly are but it´s
>>>>>> not so
>>>>>> hard to me. I´m doing by myself.
>>>>>>
>>>>>> Thank you for any any word for support!!!!
>>>>>>
>>>>> Could you mail the orocos.log file that got generated during that run
>>>>> ? There must be a previous error that indicates why the imports
>>>>> failed.
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>> Hi guys, I'm attaching my orocos.log...Actually I found out that the
>>>> application is looking for plugins on \usr\lib\rtt\gnulinux\plugins
>>>> as you
>>>> can see on line 7 but all plugins were installed on
>>>> \usr\local\rtt\gnulinux\plugins...I'm trying now to figure out how
>>>> to set
>>>> this variable to get it solved.
>>>>
>>>> I think the error is there... Any tips are welcome!!!
>>>>
>>> You need to tell the dynamic linker about your library path, with
>>> something like the following for Linux
>>>
>>> echo "\usr\local\rtt\gnulinux\plugins" | sudo tee -a /etc/ld.so.conf.d/
>>> rtt-plugins.conf
>>> sudo ldconfig
>>>
>>> Another one for the FAQ ...
>>>
>>> HTH
>>> Stephen
>>>
>>
>>
>> Hi, really sorry for being here again with the same issue...
>>
>> I did all suggestions (thank you!!!) and I think the linker is looking
>> for
>> libs correctly...However I think I have another problem that I mentioned
>> a
>> long before about the message oroco-ocl-gnulinux >=1.4 not found after
>> the
>> configure command on ccmake ..
>>
>> That's odd to me because I do have ocl installed on \usr\local (version
>> 1.8.2) and \usr\local\orocos (version 1.8.1). Could you figure out what
>> is
>> missing? I could run all helloworld examples easier than that including
>> helloworld-deployment!!!
>>
>> I'm attaching my .log again anyway!!!
>>
>> Thanks,
>>
>> Breno
> Could you send the corresponding application.cpf file ?
>

Hi, the file is attached.....

About the plugins.so I did a find . -iname plugins* in my \usr but nothing
was found....

I also inserted the import on application.cpf attached here!!!

Thanks,

Breno

RTT-examples-controller1-solution

>> Hi guys, I'm attaching my orocos.log...Actually I found out that the
>> application is looking for plugins on \usr\lib\rtt\gnulinux\plugins
>> as you
>> can see on line 7 but all plugins were installed on
>> \usr\local\rtt\gnulinux\plugins...I'm trying now to figure out how
>> to set
>> this variable to get it solved.
>>
>> I think the error is there... Any tips are welcome!!!
>
>
> You need to tell the dynamic linker about your library path, with
> something like the following for Linux
>
> echo "\usr\local\rtt\gnulinux\plugins" | sudo tee -a /etc/ld.so.conf.d/
> rtt-plugins.conf
> sudo ldconfig
>
> Another one for the FAQ ...
>
OR you can just add these plugins to the import statement

<simple name="Import"
type="string"><value>/usr/local/rtt/gnulinux/plugings<value><simple>

I do this all the time since since I work with different installations
of the same software with different versions of boost. In this case I
learned it is not a good idea to tell the linker about the different
installation paths since he will start mixing up different versions.
So an example of in import statement (also for a plugin) taken from my
application:
<simple name="Import"
type="string"><value>/home/fiep/orocos/dataAssociationBranch/install/lib/rtt/gnulinux/plugins/liborocos-bfl_toolkit-gnulinux.so<value><simple>

Good luck,

Tinne

RTT-examples-controller1-solution

You can also add this path to your LD_LIBRARY_PATH env. variable!

Charles.

Tinne De Laet a écrit :
>>> Hi guys, I'm attaching my orocos.log...Actually I found out that the
>>> application is looking for plugins on \usr\lib\rtt\gnulinux\plugins
>>> as you
>>> can see on line 7 but all plugins were installed on
>>> \usr\local\rtt\gnulinux\plugins...I'm trying now to figure out how
>>> to set
>>> this variable to get it solved.
>>>
>>> I think the error is there... Any tips are welcome!!!
>>>
>> You need to tell the dynamic linker about your library path, with
>> something like the following for Linux
>>
>> echo "\usr\local\rtt\gnulinux\plugins" | sudo tee -a /etc/ld.so.conf.d/
>> rtt-plugins.conf
>> sudo ldconfig
>>
>> Another one for the FAQ ...
>>
>>
> OR you can just add these plugins to the import statement
>
> <simple name="Import"
> type="string"><value>/usr/local/rtt/gnulinux/plugings<value><simple>
>
> I do this all the time since since I work with different installations
> of the same software with different versions of boost. In this case I
> learned it is not a good idea to tell the linker about the different
> installation paths since he will start mixing up different versions.
> So an example of in import statement (also for a plugin) taken from my
> application:
> <simple name="Import"
> type="string"><value>/home/fiep/orocos/dataAssociationBranch/install/lib/rtt/gnulinux/plugins/liborocos-bfl_toolkit-gnulinux.so<value><simple>
>
> Good luck,
>
> Tinne
>

RTT-examples-controller1-solution

On Sep 16, 2009, at 09:37 , Charles Lesire-Cabaniols wrote:

> You can also add this path to your LD_LIBRARY_PATH env. variable!

We've found inconsistencies in the use of LD_LIBRARY_PATH in certain
distro's these days (though I can't remember which ones, of the top of
my head). That's why we ended up using the /etc/ld.so.conf.d approach.

YMMV
Stephen

RTT-examples-controller1-solution

Well... it works on Ubuntu and Debian...

Stephen Roderick a écrit :
> On Sep 16, 2009, at 09:37 , Charles Lesire-Cabaniols wrote:
>
>
>> You can also add this path to your LD_LIBRARY_PATH env. variable!
>>
>
> We've found inconsistencies in the use of LD_LIBRARY_PATH in certain
> distro's these days (though I can't remember which ones, of the top of
> my head). That's why we ended up using the /etc/ld.so.conf.d approach.
>
> YMMV
> Stephen
>
>
>

RTT-examples-controller1-solution

On Sep 13, 2009, at 20:24 , breno [..] ... wrote:

> Hi folks, once and again I came here with some basic questions...
>
> I'm trying to run the example available on controller-1-solution but
> the
> error below is reported. Are there anything to be implemented on this
> example or I have anything wrong on my environment. I'm using
> rtt-1.8.5
> and ocl-1.8.2 installed on /usr/local/
>
>
>
>
>
> root@breno-HP:/home/breno/Desktop/rtt-exercises-1.8.1/controller-1-
> solution#
> deployer-gnulinux --start deployment/application.cpf

It would really help if you posted the file you are deploying. The
error is in there ...
S