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" ... :-)
Leopard test results
Snow Leopard compile failures. I think that this is a boost problem.
If you set the types explicitly, the error still exists.
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" ... :-)
>
>
>
Seems I still need to polish my workflow :)
>
>
> Leopard test results
>
>
>
> Snow Leopard compile failures. I think that this is a boost problem. If you
> set the types explicitly, the error still exists.
>
>
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
>
>
> 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
>>
>>
>> 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
>>
>
> 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
+
boost_spirit
::contiguous
<
boost_spirit
::sequence
<
boost_spirit
::alpha_parser,boost_spirit::kleene_star<boost_spirit::chset
//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
boost_spirit
::alternative
<
boost_spirit
::alternative
<
boost_spirit
::alternative
<
boost_spirit
::alternative
/*typedef
alternative
}}}
>
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 ...
>
>
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 ...
>>
>>
>
> 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
Git pull on master says up-to-date.
Git pull on 2.x branch
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