Hello,
I'm trying to compile RTT (didn't try OCL yet) on win32 with VS 2008. First,
I had to make some modifications to be able to compile the main library:
- Replace "using detail" with "using RTT::detail" because it was ambigous
with "boost::detail" for MSVC.
- Add BOOST_ALL_NO_LIB in preprocessor definitions to disable auto-link for
boost (was mixing static vs. dynamic)
- Enable OS_NO_ASM (was disabled by default)
Then, I was able to compile orocos-rtt, orocos-rtt-corba and some units
tests. However, everything related to Corba has many linking errors.
Did someone has already tried to compile RTT 2.x on win32?
Also, many unit tests fail such as core-test, plugins_test, ports_test,
service_test, etc.
I'm using ACE&TAO 1.6 and Boost 1.39.
Philippe
Orocos Toolchain 2.2 broken on win32 ?
2011/1/12 Jean Sreng <jean [dot] sreng [..] ...>
> On 11/01/2011 23:28, Philippe Hamelin wrote:
>
>> Forget it. I was looking for a "win32 ready" branch, not in your master
>> branch. I will take a look.
>>
>> By the way, does the unit tests passed on your side with your master
>> branch?
>>
>
> Hello, all tests are working for me, except some times test related to
> released memory chunk for property bags (under windows memory chunks are 4
> bytes multiples instead of 1). You have to be careful to put the DLL in the
> right place for the tests to work.
>
>
I tested your master branch with the following setup:
- Windows XP (32 bits)
- Visual Studio 2008
- ACE & TAO 1.6
- Boost 1.44
To make it works I had to make the following modifications:
1. define BOOST_ALL_NO_LIB to disable Boost auto-linking on Windows
2. Compile in Release config because there's linking error in Debug mode
with ACE & TAO (I already have a simple patch for it but I didn't applied it
for this test)
Many test failed on my side. I had to copy all DLLs in the
build/tests/Release folder to make it work. Here is the (best) test results
I had :
Test project C:/Data/3rdparty-libs/orocos-toolchain-jsrengs-rtt/build/tests
Start 1: main-test
1/34 Test #1: main-test ........................ Passed 0.03 sec
Start 2: list-test
2/34 Test #2: list-test ........................ Passed 0.03 sec
Start 3: core-test
3/34 Test #3: core-test ........................ Passed 5.14 sec
Start 4: task-test
4/34 Test #4: task-test ........................***Failed 21.17 sec
Start 5: corba-test
5/34 Test #5: corba-test ....................... Passed 1.98 sec
Start 6: test-corba-main
6/34 Test #6: test-corba-main .................. Passed 1.11 sec
Start 7: buffers_test
7/34 Test #7: buffers_test ..................... Passed 0.03 sec
Start 8: method_test
8/34 Test #8: method_test ...................... Passed 0.08 sec
Start 9: remote_method_test
9/34 Test #9: remote_method_test ............... Passed 0.05 sec
Start 10: functors_test
10/34 Test #10: functors_test .................... Passed 0.05 sec
Start 11: service_test
11/34 Test #11: service_test ..................... Passed 0.05 sec
Start 12: service_port_test
12/34 Test #12: service_port_test ................ Passed 0.03 sec
Start 13: event_test
13/34 Test #13: event_test ....................... Passed 0.14 sec
Start 14: operation_test
14/34 Test #14: operation_test ................... Passed 0.05 sec
Start 15: taskstates_test
15/34 Test #15: taskstates_test ..................***Exception: SegFault
0.03 sec
Start 16: ports_test
16/34 Test #16: ports_test ....................... Passed 0.06 sec
Start 17: attributes_test
17/34 Test #17: attributes_test .................. Passed 0.05 sec
Start 18: dev_test
18/34 Test #18: dev_test .........................***Failed 0.02 sec
Start 19: scripting_test
19/34 Test #19: scripting_test ...................***Failed 0.06 sec
Start 20: types_test
20/34 Test #20: types_test .......................***Failed 0.05 sec
Start 21: program_test
21/34 Test #21: program_test .....................***Failed 0.06 sec
Start 22: state_test
22/34 Test #22: state_test .......................***Failed 0.08 sec
Start 23: function_test
23/34 Test #23: function_test ....................***Failed 0.08 sec
Start 24: marshalling_test
24/34 Test #24: marshalling_test .................***Failed 0.05 sec
Start 25: property_loader_test
25/34 Test #25: property_loader_test .............***Failed 0.03 sec
Start 26: property_marsh_test
26/34 Test #26: property_marsh_test ..............***Failed 0.03 sec
Start 27: property_test
27/34 Test #27: property_test ....................***Failed 0.03 sec
Start 28: type_discovery_test
28/34 Test #28: type_discovery_test .............. Passed 0.02 sec
Start 29: type_discovery_struct_test
29/34 Test #29: type_discovery_struct_test ....... Passed 0.03 sec
Start 30: type_discovery_container_test
30/34 Test #30: type_discovery_container_test .... Passed 0.02 sec
Start 31: enum_type_test
31/34 Test #31: enum_type_test ...................***Failed 0.03 sec
Start 32: datasource_test
32/34 Test #32: datasource_test .................. Passed 0.03 sec
Start 33: typekit_test
33/34 Test #33: typekit_test ..................... Passed 0.03 sec
Start 34: plugins_test
34/34 Test #34: plugins_test .....................***Failed 0.03 sec
59% tests passed, 14 tests failed out of 34
Total Test time (real) = 31.35 sec
The following tests FAILED:
4 - task-test (Failed)
15 - taskstates_test (SEGFAULT)
18 - dev_test (Failed)
19 - scripting_test (Failed)
20 - types_test (Failed)
21 - program_test (Failed)
22 - state_test (Failed)
23 - function_test (Failed)
24 - marshalling_test (Failed)
25 - property_loader_test (Failed)
26 - property_marsh_test (Failed)
27 - property_test (Failed)
31 - enum_type_test (Failed)
34 - plugins_test (Failed)
Errors while running CTest
I used (best) because I noticed that I had random behavior with some tests
(e.g., core-test, event_test). Sometimes it works, but sometimes they end in
a deadlock.
Also, please note that the corba-test passed but it generated a win32
unhandled exception.
Since all the tests passed on your side, do you have an idea if I did
something wrong? The only difference seems to be our ACE & TAO version but I
can't see how this can make all these tests fail.
Thank you,
Philippe
Orocos Toolchain 2.2 broken on win32 ?
On 12/01/2011 18:13, Philippe Hamelin wrote:
> I tested your master branch with the following setup:
>
> - Windows XP (32 bits)
> - Visual Studio 2008
> - ACE & TAO 1.6
> - Boost 1.44
>
> To make it works I had to make the following modifications:
>
> 1. define BOOST_ALL_NO_LIB to disable Boost auto-linking on Windows
Are you using DLL or static version of boost ? I did not have to set
BOOST_ALL_NO_LIB in my setup, but I use set(Boost_USE_STATIC_LIBS true)
> 2. Compile in Release config because there's linking error in Debug mode
> with ACE & TAO (I already have a simple patch for it but I didn't
> applied it for this test)
This is strange, I have no problem compiling with Debug versions of
ACE/TAO. Can you detail the problem ?
> The following tests FAILED:
> 4 - task-test (Failed)
> 15 - taskstates_test (SEGFAULT)
Can you post the test outputs of these two ?
> 18 - dev_test (Failed)
> 19 - scripting_test (Failed)
> 20 - types_test (Failed)
> 21 - program_test (Failed)
> 22 - state_test (Failed)
> 23 - function_test (Failed)
> 24 - marshalling_test (Failed)
> 25 - property_loader_test (Failed)
> 26 - property_marsh_test (Failed)
> 27 - property_test (Failed)
> 31 - enum_type_test (Failed)
> 34 - plugins_test (Failed)
All (or most) of those failing test are due to the plugin system no
working. Did you put the rtt-*.dll files in a dir "plugins" in your
execution path ?
A typical dir setup should look like:
/
+ YourApp.exe
+ orocos-rtt*.dll
+ ACE/TAO*.dll
+ [plugins]
+ rtt-*.dll (mashalling, scripting, transport-corba, typekit)
You can check the orocos.log for any related errors. You should see
lines like: Loaded RTT Plugin 'marshalling' from 'rtt-marshalling-win32'
> I used (best) because I noticed that I had random behavior with some
> tests (e.g., core-test, event_test). Sometimes it works, but sometimes
> they end in a deadlock.
This is quite strange. I never experienced such things... Did you
enable/disable ORO_NOASM ?
> Also, please note that the corba-test passed but it generated a win32
> unhandled exception.
Maybe due to missing ACE/TAO dlls. You can check your dependencies with
depends.exe
> Since all the tests passed on your side, do you have an idea if I did
> something wrong? The only difference seems to be our ACE & TAO version
> but I can't see how this can make all these tests fail.
The 1.6 should work. If any doubt, you can first try to run the tests
without CORBA enabled in the build.
Orocos Toolchain 2.2 broken on win32 ?
2011/1/14 Jean Sreng <jean [dot] sreng [..] ...>
> On 12/01/2011 18:13, Philippe Hamelin wrote:
>
>> I tested your master branch with the following setup:
>>
>> - Windows XP (32 bits)
>> - Visual Studio 2008
>> - ACE & TAO 1.6
>> - Boost 1.44
>>
>> To make it works I had to make the following modifications:
>>
>> 1. define BOOST_ALL_NO_LIB to disable Boost auto-linking on Windows
>>
>
> Are you using DLL or static version of boost ? I did not have to set
> BOOST_ALL_NO_LIB in my setup, but I use set(Boost_USE_STATIC_LIBS true)
>
>
I'm using the dynamic version of boost. Since auto-linking defaults to
static libs, this had not impact on your build. (see patch #0005)
>
> 2. Compile in Release config because there's linking error in Debug mode
>> with ACE & TAO (I already have a simple patch for it but I didn't
>> applied it for this test)
>>
>
> This is strange, I have no problem compiling with Debug versions of
> ACE/TAO. Can you detail the problem ?
>
>
When compiling in debug, CMake was trying to link with ACE/TAO release. In
addition to mixing Debug CRT and Release CRT, this caused linking error.
(see patch #0002)
>
> The following tests FAILED:
>> 4 - task-test (Failed)
>> 15 - taskstates_test (SEGFAULT)
>>
>
> Can you post the test outputs of these two ?
>
>
We moved to your git branch, so the test results are a bit different. Please
see below...
>
> 18 - dev_test (Failed)
>> 19 - scripting_test (Failed)
>> 20 - types_test (Failed)
>> 21 - program_test (Failed)
>> 22 - state_test (Failed)
>> 23 - function_test (Failed)
>> 24 - marshalling_test (Failed)
>> 25 - property_loader_test (Failed)
>> 26 - property_marsh_test (Failed)
>> 27 - property_test (Failed)
>> 31 - enum_type_test (Failed)
>> 34 - plugins_test (Failed)
>>
>
> All (or most) of those failing test are due to the plugin system no
> working. Did you put the rtt-*.dll files in a dir "plugins" in your
> execution path ?
> A typical dir setup should look like:
> /
> + YourApp.exe
> + orocos-rtt*.dll
> + ACE/TAO*.dll
> + [plugins]
> + rtt-*.dll (mashalling, scripting, transport-corba, typekit)
>
> You can check the orocos.log for any related errors. You should see lines
> like: Loaded RTT Plugin 'marshalling' from 'rtt-marshalling-win32'
>
>
You were right. It's now OK. In addition, we fixed the make install on
windows to copy the plugins DLL at the right place (see patch #0003).
>
> I used (best) because I noticed that I had random behavior with some
>> tests (e.g., core-test, event_test). Sometimes it works, but sometimes
>> they end in a deadlock.
>>
>
> This is quite strange. I never experienced such things... Did you
> enable/disable ORO_NOASM ?
>
>
ORO_NOASM is disabled.
>
> Also, please note that the corba-test passed but it generated a win32
>> unhandled exception.
>>
>
> Maybe due to missing ACE/TAO dlls. You can check your dependencies with
> depends.exe
>
>
We decided to not deal with corba for the moment.
>
> Since all the tests passed on your side, do you have an idea if I did
>> something wrong? The only difference seems to be our ACE & TAO version
>> but I can't see how this can make all these tests fail.
>>
>
> The 1.6 should work. If any doubt, you can first try to run the tests
> without CORBA enabled in the build.
>
> --
>
Using your master branch, the behavior was a bit different. We fixed some
things to make it works. We generated patch against your master git tree
(see attached files). Here is the tests result:
Start 1: main-test
1/32 Test #1: main-test ........................ Passed 0.09 sec
Start 2: list-test
2/32 Test #2: list-test ........................ Passed 0.06 sec
Start 3: core-test
3/32 Test #3: core-test ........................ Passed 5.20 sec
Start 4: task-test
4/32 Test #4: task-test ........................***Failed 2.86 sec
Start 5: buffers_test
5/32 Test #5: buffers_test ..................... Passed 0.28 sec
Start 6: method_test
6/32 Test #6: method_test ...................... Passed 0.80 sec
Start 7: remote_method_test
7/32 Test #7: remote_method_test ............... Passed 0.84 sec
Start 8: functors_test
8/32 Test #8: functors_test .................... Passed 1.22 sec
Start 9: service_test
9/32 Test #9: service_test ..................... Passed 0.28 sec
Start 10: service_port_test
10/32 Test #10: service_port_test ................ Passed 0.24 sec
Start 11: event_test
11/32 Test #11: event_test ....................... Passed 0.31 sec
Start 12: operation_test
12/32 Test #12: operation_test ................... Passed 1.06 sec
Start 13: taskstates_test
13/32 Test #13: taskstates_test ..................***Failed 0.39 sec
Start 14: ports_test
14/32 Test #14: ports_test ....................... Passed 68.65 sec
Start 15: attributes_test
15/32 Test #15: attributes_test .................. Passed 0.78 sec
Start 16: dev_test
16/32 Test #16: dev_test ......................... Passed 0.27 sec
Start 17: scripting_test
17/32 Test #17: scripting_test ................... Passed 1.28 sec
Start 18: types_test
18/32 Test #18: types_test ....................... Passed 2.42 sec
Start 19: program_test
19/32 Test #19: program_test ..................... Passed 1.81 sec
Start 20: state_test
20/32 Test #20: state_test ....................... Passed 9.20 sec
Start 21: function_test
21/32 Test #21: function_test .................... Passed 1.72 sec
Start 22: marshalling_test
22/32 Test #22: marshalling_test ................. Passed 0.31 sec
Start 23: property_loader_test
23/32 Test #23: property_loader_test ............. Passed 0.56 sec
Start 24: property_marsh_test
24/32 Test #24: property_marsh_test .............. Passed 0.34 sec
Start 25: property_test
25/32 Test #25: property_test .................... Passed 0.28 sec
Start 26: type_discovery_test
26/32 Test #26: type_discovery_test .............. Passed 0.39 sec
Start 27: type_discovery_struct_test
27/32 Test #27: type_discovery_struct_test ....... Passed 0.77 sec
Start 28: type_discovery_container_test
28/32 Test #28: type_discovery_container_test .... Passed 0.33 sec
Start 29: enum_type_test
29/32 Test #29: enum_type_test ................... Passed 0.25 sec
Start 30: datasource_test
30/32 Test #30: datasource_test .................. Passed 0.47 sec
Start 31: typekit_test
31/32 Test #31: typekit_test ..................... Passed 0.30 sec
Start 32: plugins_test
32/32 Test #32: plugins_test .....................***Failed 0.28 sec
91% tests passed, 3 tests failed out of 32
Some comments:
- ports_test passed, but if fact we (sometimes) have an exception: Debug
Assertion Failed (Expression: _CrtIsValidHeapPointer(pUserData)).
- this is the same behavior for taskstates_test, which randomly gives Debug
Assertion Failed (Expression: _CrtIsValidHeapPointer(pUserData)). .
- attributes_test also randomly fails.
- the plugins_test fail because it looks for plugins DLL files, while in
debug mode they end with the letter "d".
- There's less locking (usually in task_test), but there's a lot of memory
leak and heap coruption when running the tests in the debugger. I also see
some first chance std::bad_alloc exception. We weren't able to find the
problem yet, but the call stack usually shows calls to the Logger.
Here the output of some tests:
******************************
task_test.exe :
******************************
Running 17 test cases...
unknown location(0): fatal error in "testActivityNP": breakpoint
encountered
..\..\tests\tasks_test.cpp(345): last checkpoint
unknown location(0): fatal error in "testActivityBreakLoop": std::bad_alloc:
bad allocation
..\..\tests\tasks_test.cpp(345): last checkpoint
unknown location(0): fatal error in "testSelfRemove": std::bad_alloc: bad
allocation
..\..\tests\tasks_test.cpp(345): last checkpoint
(then locked!)
******************************
attributes_test.exe :
******************************
Running 2 test cases...
*** No errors detected
Detected memory leaks!
Dumping objects ->
{1392} normal block at 0x013FFF08, 12 bytes long.
Data: < ? > 00 00 1E 02 A8 F8 3F 01 00 00 00 00
{1213} normal block at 0x013FF8A8, 12 bytes long.
Data: < ? ? > 00 00 CD 01 08 F6 3F 01 08 FF 3F 01
{1008} normal block at 0x013FF608, 12 bytes long.
Data: < | X ? ? > 00 00 7C 01 58 F6 3F 01 A8 F8 3F 01
{794} normal block at 0x013FF658, 12 bytes long.
Data: < m ? ? > 00 00 6D 01 B8 FA 3F 01 08 F6 3F 01
{724} normal block at 0x013FFAB8, 12 bytes long.
Data: < N $ * X ? > 00 00 4E 01 24 11 2A 10 58 F6 3F 01
Object dump complete.
******************************
taskstates_task.exe :
******************************
Running 7 test cases...
C:\Data\3rdparty-libs\orocos-toolchain-win32-test\orocos-toolchain-jsrengs-rtt\b
uild\tests\Debug>taskstates_test.exe
Running 7 test cases...
../../tests/taskstates_test.cpp(231): error in "testTrigger": check
trigtc.updat
ecount == 0 failed [1 != 0]
*** 1 failure detected in test suite "Master Test Suite"
Detected memory leaks!
Dumping objects ->
{1433} normal block at 0x014E0888, 12 bytes long.
Data: < h)N > 00 00 1E 02 68 29 4E 01 00 00 00 00
{1254} normal block at 0x014E2968, 12 bytes long.
Data: < N N > 00 00 CD 01 B8 00 4E 01 88 08 4E 01
{1049} normal block at 0x014E00B8, 12 bytes long.
Data: < | ( N h)N > 00 00 7C 01 28 04 4E 01 68 29 4E 01
{835} normal block at 0x014E0428, 12 bytes long.
Data: < m ? N > 00 00 6D 01 E0 EB 3F 01 B8 00 4E 01
{765} normal block at 0x013FEBE0, 12 bytes long.
Data: < ^ $ * ( N > 00 00 5E 01 24 11 2A 10 28 04 4E 01
Object dump complete.
Did you run these tests in the debugger or in release mode? We didn't have
the same behavior for both configs.
Philippe
Orocos for Multi Agent Control Systems (@ UTwente)
For your information: a very interesting piece of evolution in the Orocos
ecosystem!
<http://www.ce.utwente.nl/rtweb/people/index.php?body=student_info&key=201&type=4>
<http://www.narcis.nl/publication/RecordID/oai:doc.utwente.nl:75273/Language/nl>
<http://www.ce.utwente.nl/rtweb/people/index.php?body=student_info&key=302&type=4>
Herman
PS It's a pity the students did not use the mailinglist more often, since
there are a lot of people in Leuven interested in this topic (and working
on it too)
Orocos for Multi Agent Control Systems (@ UTwente)
type: forum
tid: 54
status: 1
Orocos for Multi Agent Control Systems (@ UTwente)
On Mon, 17 Jan 2011, Vries, Theo J.A. de [imotec bv] wrote:
> This work has been done under my supervision.
I am not surprised! :-)
> I apologize for not having
> informed the list more often, will try to do so in the near future (some
> participation from our side has been there, though).
There is nothing to apologize for! But you might have missed some
interesting insights or contributions from this community :-)
I for one, am very interested in getting MACS functionality into Orocos,
even at the infrastructure (read "RTT") level: the way an Orocos component
should deal with the resources available at the infrastructure level
(memory, CPU, IO, hardware components,...) is, in my opinion, in the MACS
way. More in particular, we are working towards bringing the ideas of our
PROSA factory automation research (Paul Valckenaers and colleagues) into
robotics.
> For those interested: a PhD thesis on this work will appear in a few weeks
> (defense planned for Feb. 3); a downloadable pdf will be made public, I will
> make sure it gets listed here.
Thanks!
Herman
> The tools discussed in the references are not yet in a state that they can be
> used by others, we are working hard on that.
>
> Regards, Theo.
>
> P.S.
> I am not able to find this mailing list / forum via the orocos website??
>
> On 01/14/11 20:50, Herman Bruyninckx wrote:
>
> For your information: a very interesting piece of evolution in the Orocos
> ecosystem!
> <http://www.ce.utwente.nl/rtweb/people/index.php?body=student_info&key=201&typ
> e=4>
> <http://www.narcis.nl/publication/RecordID/oai:doc.utwente.nl:75273/Language/n
> l>
> <http://www.ce.utwente.nl/rtweb/people/index.php?body=student_info&key=302&typ
> e=4>
>
> Herman
>
> PS It's a pity the students did not use the mailinglist more often, since
> there are a lot of people in Leuven interested in this topic (and working
> on it too)
Herman
Orocos for Multi Agent Control Systems (@ UTwente)
Dear list,
Yesterday I defended my PhD thesis with the title "Safe-Guarded Multi-Agent
Control for Mechatronic Systems: Implementation Framework and Design
Patterns". I used the OROCOS framework to develop OROCOS-based
Implementation Framework for Multi-Agent Control Systems (OROMACS
framework).
For people who are interested in my work, it is the link that you can
download my thesis.
http://www.ce.utwente.nl/RTweb/publications/index.php?body=pub_titles&Ye...
I would like to say "thanks!" to OROCOS's developers for the useful
framework they have developed.
Best regards,
Phong
On Mon, Jan 17, 2011 at 6:08 PM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:
> On Mon, 17 Jan 2011, Vries, Theo J.A. de [imotec bv] wrote:
>
> > This work has been done under my supervision.
>
> I am not surprised! :-)
>
> > I apologize for not having
> > informed the list more often, will try to do so in the near future (some
> > participation from our side has been there, though).
>
> There is nothing to apologize for! But you might have missed some
> interesting insights or contributions from this community :-)
>
> I for one, am very interested in getting MACS functionality into Orocos,
> even at the infrastructure (read "RTT") level: the way an Orocos component
> should deal with the resources available at the infrastructure level
> (memory, CPU, IO, hardware components,...) is, in my opinion, in the MACS
> way. More in particular, we are working towards bringing the ideas of our
> PROSA factory automation research (Paul Valckenaers and colleagues) into
> robotics.
>
> > For those interested: a PhD thesis on this work will appear in a few
> weeks
> > (defense planned for Feb. 3); a downloadable pdf will be made public, I
> will
> > make sure it gets listed here.
>
> Thanks!
>
> Herman
>
> > The tools discussed in the references are not yet in a state that they
> can be
> > used by others, we are working hard on that.
> >
> > Regards, Theo.
> >
> > P.S.
> > I am not able to find this mailing list / forum via the orocos website??
> >
> > On 01/14/11 20:50, Herman Bruyninckx wrote:
> >
> > For your information: a very interesting piece of evolution in the Orocos
> > ecosystem!
> > <
> http://www.ce.utwente.nl/rtweb/people/index.php?body=student_info&key=20...
> > e=4>
> > <
> http://www.narcis.nl/publication/RecordID/oai:doc.utwente.nl:75273/Langu...
> > l>
> > <
> http://www.ce.utwente.nl/rtweb/people/index.php?body=student_info&key=30...
> > e=4>
> >
> > Herman
> >
> > PS It's a pity the students did not use the mailinglist more often, since
> > there are a lot of people in Leuven interested in this topic (and working
> > on it too)
>
> Herman
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
Orocos for Multi Agent Control Systems (@ UTwente)
On Fri, 4 Feb 2011, Dao Ba Phong wrote:
> Yesterday I defended my PhD thesis with the title "Safe-Guarded Multi-Agent
> Control for Mechatronic Systems: Implementation Framework and Design Patterns".
> I used the OROCOS framework to develop OROCOS-based Implementation Framework for
> Multi-Agent Control Systems (OROMACS framework).
>
> For people who are interested in my work, it is the link that you can download
> my thesis.
> http://www.ce.utwente.nl/RTweb/publications/index.php?body=pub_titles&Ye...
>
> I would like to say "thanks!" to OROCOS's developers for the useful framework
> they have developed.
Thank you for the information! And congratulations with your promotion :-)
It would be nice to now see some follow-up emails with concrete suggestions
about where Orocos can or should be improved :-)
For example, I read things in your thesis text such as "This work makes the
kind of composite components, which is currently not supported in the
OROCOS framework, available in the OROMACS framework in terms of composite
controller-agents." Which comes a bit as a surprise to me, since
composition _is_ possible in my opinion (but can always be improved, of
course), so what exactly was the problem you encountered, and solved? As
far as I can see, you solved it for "(system theoretic) controller
components" (in what is a good way, I think), but can lessons be learnt
from your work for composition in general?
It also looks like you have implemented the core of what we have been
planning (but never realised) since a long time already, and that is a
"Systems and Control Library" subproject. Patches in this respect are
highly welcome :-) By the way, a master student at TU Eindhoven is also
planning to work on that subject.
> Best regards,
> Phong
Herman
>
>
> On Mon, Jan 17, 2011 at 6:08 PM, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
> On Mon, 17 Jan 2011, Vries, Theo J.A. de [imotec bv] wrote:
>
> > This work has been done under my supervision.
>
> I am not surprised! :-)
>
> > I apologize for not having
> > informed the list more often, will try to do so in the near future (some
> > participation from our side has been there, though).
>
> There is nothing to apologize for! But you might have missed some
> interesting insights or contributions from this community :-)
>
> I for one, am very interested in getting MACS functionality into Orocos,
> even at the infrastructure (read "RTT") level: the way an Orocos component
> should deal with the resources available at the infrastructure level
> (memory, CPU, IO, hardware components,...) is, in my opinion, in the MACS
> way. More in particular, we are working towards bringing the ideas of our
> PROSA factory automation research (Paul Valckenaers and colleagues) into
> robotics.
>
> > For those interested: a PhD thesis on this work will appear in a few
> weeks
> > (defense planned for Feb. 3); a downloadable pdf will be made public, I
> will
> > make sure it gets listed here.
>
> Thanks!
>
> Herman
>
> > The tools discussed in the references are not yet in a state that they
> can be
> > used by others, we are working hard on that.
> >
> > Regards, Theo.
> >
> > P.S.
> > I am not able to find this mailing list / forum via the orocos website??
> >
> > On 01/14/11 20:50, Herman Bruyninckx wrote:
> >
> > For your information: a very interesting piece of evolution in the
> Orocos
> > ecosystem!
> >
> <http://www.ce.utwente.nl/rtweb/people/index.php?body=student_info&key=201&typ
> > e=4>
> >
> <http://www.narcis.nl/publication/RecordID/oai:doc.utwente.nl:75273/Language/n
> > l>
> >
> <http://www.ce.utwente.nl/rtweb/people/index.php?body=student_info&key=302&typ
> > e=4>
> >
> > Herman
> >
> > PS It's a pity the students did not use the mailinglist more often,
> since
> > there are a lot of people in Leuven interested in this topic (and
> working
> > on it too)
>
> Herman
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>
>
>
--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
Orocos for Multi Agent Control Systems (@ UTwente)
On Sun, Feb 6, 2011 at 1:43 PM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:
> On Fri, 4 Feb 2011, Dao Ba Phong wrote:
>
> Yesterday I defended my PhD thesis with the title "Safe-Guarded
>> Multi-Agent
>> Control for Mechatronic Systems: Implementation Framework and Design
>> Patterns".
>> I used the OROCOS framework to develop OROCOS-based Implementation
>> Framework for
>> Multi-Agent Control Systems (OROMACS framework).
>>
>> For people who are interested in my work, it is the link that you can
>> download
>> my thesis.
>>
>> http://www.ce.utwente.nl/RTweb/publications/index.php?body=pub_titles&Ye...
>>
>> I would like to say "thanks!" to OROCOS's developers for the useful
>> framework
>> they have developed.
>>
>
> Thank you for the information! And congratulations with your promotion :-)
>
> It would be nice to now see some follow-up emails with concrete suggestions
> about where Orocos can or should be improved :-)
>
> For example, I read things in your thesis text such as "This work makes the
> kind of composite components, which is currently not supported in the
> OROCOS framework, available in the OROMACS framework in terms of composite
> controller-agents." Which comes a bit as a surprise to me, since
> composition _is_ possible in my opinion (but can always be improved, of
> course), so what exactly was the problem you encountered, and solved? As
> far as I can see, you solved it for "(system theoretic) controller
> components" (in what is a good way, I think), but can lessons be learnt
> from your work for composition in general?
>
> It also looks like you have implemented the core of what we have been
> planning (but never realised) since a long time already, and that is a
> "Systems and Control Library" subproject. Patches in this respect are
> highly welcome :-) By the way, a master student at TU Eindhoven is also
> planning to work on that subject.
>
> Best regards,
>> Phong
>>
>
> Herman
>
>
The research on MACS has been started at the Control Engineering group of
the University of Twente since 1997 (even earlier). A PhD project was
completed in 2001 by Van Breemen (
http://www.ce.utwente.nl/rtweb/publications/2001/pdf-files/AJN%20van%20B...).
My research inherited and improved this previous work.
Our work has aimed at developing the hierarchically structured MACS, thus
the composite controller-agent type is required. However as I know, it is
not possible right now to create a hierarchically structured component with
the OROCOS framework (I believe that in the future this function will be
possible). So, we customized the OROCOS TaskContext to obtain composite
controller-agent.
However, the OROMACS framework is just the first work. To obtain a good
composability with respect to MACS design, we deployed polymorphism into
controller-agent. We have obtained polymorphic elementary/composite
controller-agent. Here, the polymorphism means "one Type with multiple
Specifications". This polymorphism approach provides a useful feature: the
content of a polymorphic controller-agent can be of varying complexity,
whereas its interface can be kept unchanged. In addition, the main point of
the polymorphism is that it enables "old code to call new code". In other
words, it makes "old code for new applications". It means that a polymorphic
controller-agent does data processing; the interface (i.e. Type) defines the
data that is required (inputs) and the data that is provided (outputs); the
internal implementation (i.e. Specification) can be changed based on
configuration and composition of polymorphic (sub)controller-agents. As a
result, multiple specifications of a polymorphic (sub)controller-agent can
be selected and assembled in various combinations to satisfy specific user
requirements without requiring modifications to its interface. This
polymorphism approach also has an important role in the control system
design patterns that I developed.
Best regards,
Phong
>
>
>>
>> On Mon, Jan 17, 2011 at 6:08 PM, Herman Bruyninckx
>> <Herman [dot] Bruyninckx [..] ...> wrote:
>> On Mon, 17 Jan 2011, Vries, Theo J.A. de [imotec bv] wrote:
>>
>> > This work has been done under my supervision.
>>
>> I am not surprised! :-)
>>
>> > I apologize for not having
>> > informed the list more often, will try to do so in the near future (some
>> > participation from our side has been there, though).
>>
>> There is nothing to apologize for! But you might have missed some
>> interesting insights or contributions from this community :-)
>>
>> I for one, am very interested in getting MACS functionality into Orocos,
>> even at the infrastructure (read "RTT") level: the way an Orocos component
>> should deal with the resources available at the infrastructure level
>> (memory, CPU, IO, hardware components,...) is, in my opinion, in the MACS
>> way. More in particular, we are working towards bringing the ideas of our
>> PROSA factory automation research (Paul Valckenaers and colleagues) into
>> robotics.
>>
>> > For those interested: a PhD thesis on this work will appear in a few
>> weeks
>> > (defense planned for Feb. 3); a downloadable pdf will be made public, I
>> will
>> > make sure it gets listed here.
>>
>> Thanks!
>>
>> Herman
>>
>> > The tools discussed in the references are not yet in a state that they
>> can be
>> > used by others, we are working hard on that.
>> >
>> > Regards, Theo.
>> >
>> > P.S.
>> > I am not able to find this mailing list / forum via the orocos website??
>> >
>> > On 01/14/11 20:50, Herman Bruyninckx wrote:
>> >
>> > For your information: a very interesting piece of evolution in the
>> Orocos
>> > ecosystem!
>> >
>> <
>> http://www.ce.utwente.nl/rtweb/people/index.php?body=student_info&key=20...
>> > e=4>
>> >
>> <
>> http://www.narcis.nl/publication/RecordID/oai:doc.utwente.nl:75273/Langu...
>> > l>
>> >
>> <
>> http://www.ce.utwente.nl/rtweb/people/index.php?body=student_info&key=30...
>> > e=4>
>> >
>> > Herman
>> >
>> > PS It's a pity the students did not use the mailinglist more often,
>> since
>> > there are a lot of people in Leuven interested in this topic (and
>> working
>> > on it too)
>>
>> Herman
>> --
>> Orocos-Dev mailing list
>> Orocos-Dev [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>>
>>
>>
>>
>>
> --
> K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> EURON Coordinator (European Robotics Research Network) <
> http://www.euron.org>
> Open Realtime Control Services <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
Orocos for Multi Agent Control Systems (@ UTwente)
On Sun, 6 Feb 2011, Dao Ba Phong wrote:
> On Sun, Feb 6, 2011 at 1:43 PM, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...Herman [dot] Bruyninckx [..] ...>> wrote:
> On Fri, 4 Feb 2011, Dao Ba Phong wrote:
>
> Yesterday I defended my PhD thesis with the title "Safe-Guarded Multi-Agent
> Control for Mechatronic Systems: Implementation Framework and Design Patterns".
> I used the OROCOS framework to develop OROCOS-based Implementation Framework for
> Multi-Agent Control Systems (OROMACS framework).
>
> For people who are interested in my work, it is the link that you can download
> my thesis.
> http://www.ce.utwente.nl/RTweb/publications/index.php?body=pub_titles&Ye...
>
> I would like to say "thanks!" to OROCOS's developers for the useful framework
> they have developed.
>
> Thank you for the information! And congratulations with your promotion :-)
>
> It would be nice to now see some follow-up emails with concrete suggestions
> about where Orocos can or should be improved :-)
>
> For example, I read things in your thesis text such as "This work makes the
> kind of composite components, which is currently not supported in the
> OROCOS framework, available in the OROMACS framework in terms of composite
> controller-agents." Which comes a bit as a surprise to me, since
> composition _is_ possible in my opinion (but can always be improved, of
> course), so what exactly was the problem you encountered, and solved? As
> far as I can see, you solved it for "(system theoretic) controller
> components" (in what is a good way, I think), but can lessons be learnt
> from your work for composition in general?
>
> It also looks like you have implemented the core of what we have been
> planning (but never realised) since a long time already, and that is a
> "Systems and Control Library" subproject. Patches in this respect are
> highly welcome :-) By the way, a master student at TU Eindhoven is also
> planning to work on that subject.
>
> Best regards,
> Phong
>
> Herman
>
>
> The research on MACS has been started at the Control Engineering group of the University of Twente since 1997 (even earlier). A PhD project was completed in 2001 by Van Breemen (http://www.ce.utwente.nl/rtweb/publications/2001/pdf-files/AJN%20van%20B...). My research inherited and improved this previous work.
>
> Our work has aimed at developing the hierarchically structured MACS, thus
> the composite controller-agent type is required. However as I know, it is
> not possible right now to create a hierarchically structured component
> with the OROCOS framework
> (I believe that in the future this function
> will be possible). So, we customized the OROCOS TaskContext to obtain
> composite controller-agent.
So, that's why I am asking to share at least the ideas and motivations, if
not the code, of this "customization". And to discuss its merits with the
core developers on this list.
> However, the OROMACS framework is just the first work. To obtain a good
> composability with respect to MACS design, we deployed polymorphism into
> controller-agent. We have obtained polymorphic elementary/composite
> controller-agent. Here, the polymorphism means "one Type with multiple
> Specifications". This polymorphism approach provides a useful feature:
> the content of a polymorphic controller-agent can be of varying
> complexity, whereas its interface can be kept unchanged. In addition, the
> main point of the polymorphism is that it enables "old code to call new
> code". In other words, it makes "old code for new applications". It means
> that a polymorphic controller-agent does data processing; the interface
> (i.e. Type) defines the data that is required (inputs) and the data that
> is provided (outputs); the internal implementation (i.e. Specification)
> can be changed based on configuration and composition of polymorphic
> (sub)controller-agents. As a result, multiple specifications of a
> polymorphic (sub)controller-agent can be selected and assembled in
> various combinations to satisfy specific user requirements without
> requiring modifications to its interface. This polymorphism approach also
> has an important role in the control system design patterns that I
> developed.
These are things I can also read in your thesis text, but that are rather
far away from concrete developers talk :-)
Anyway, in what sense is what you describe as "polymorphism" different from
a Communication component that Coordinates the message creation/processing
Computations via a simple FSM?
> Best regards,
> Phong
Herman
>Herman [dot] Bruyninckx [..] ...>> wrote:
> On Mon, Jan 17, 2011 at 6:08 PM, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...
> On Mon, 17 Jan 2011, Vries, Theo J.A. de [imotec bv] wrote:
>
> > This work has been done under my supervision.
>
> I am not surprised! :-)
>
>> I apologize for not having
>> informed the list more often, will try to do so in the near future (some
>> participation from our side has been there, though).
>
> There is nothing to apologize for! But you might have missed some
> interesting insights or contributions from this community :-)
>
> I for one, am very interested in getting MACS functionality into Orocos,
> even at the infrastructure (read "RTT") level: the way an Orocos component
> should deal with the resources available at the infrastructure level
> (memory, CPU, IO, hardware components,...) is, in my opinion, in the MACS
> way. More in particular, we are working towards bringing the ideas of our
> PROSA factory automation research (Paul Valckenaers and colleagues) into
> robotics.
>
>> For those interested: a PhD thesis on this work will appear in a few
> weeks
>> (defense planned for Feb. 3); a downloadable pdf will be made public, I
> will
>> make sure it gets listed here.
>
> Thanks!
>
> Herman
>
>> The tools discussed in the references are not yet in a state that they
> can be
>> used by others, we are working hard on that.
>>
>> Regards, Theo.
>>
>> P.S.
>> I am not able to find this mailing list / forum via the orocos website??
>>
>> On 01/14/11 20:50, Herman Bruyninckx wrote:
>>
>> For your information: a very interesting piece of evolution in the
> Orocos
>> ecosystem!
>>
> <http://www.ce.utwente.nl/rtweb/people/index.php?body=student_info&key=201&typ
>> e=4>
>>
> <http://www.narcis.nl/publication/RecordID/oai:doc.utwente.nl:75273/Language/n
>> l>
>>
> <http://www.ce.utwente.nl/rtweb/people/index.php?body=student_info&key=302&typ
>> e=4>
>>
>> Herman
>>
>> PS It's a pity the students did not use the mailinglist more often,
> since
>> there are a lot of people in Leuven interested in this topic (and
> working
>> on it too)
>
> Herman
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...<mailto:Orocos-Dev [..] ...>
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>
>
>
>
> --
> K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
> Open Realtime Control Services <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
>
>
Orocos for Multi Agent Control Systems (@ UTwente)
On Monday 17 January 2011 09:10:27 Vries, Theo J.A. de [imotec bv] wrote:
> This work has been done under my supervision. I apologize for not having
> informed the list more often, will try to do so in the near future (some
> participation from our side has been there, though).
>
> For those interested: a PhD thesis on this work will appear in a few weeks
> (defense planned for Feb. 3); a downloadable pdf will be made public, I
> will make sure it gets listed here.
>
> The tools discussed in the references are not yet in a state that they can
> be used by others, we are working hard on that.
>
> Regards, Theo.
>
> P.S.
> I am not able to find this mailing list / forum via the orocos website??
On the Orocos website, it's called 'rtt-dev'. Since KDL/BFL have their own -
dev fora.
Peter
Orocos Toolchain 2.2 broken on win32 ?
Hello,
On 16/12/2010 20:22, Philippe Hamelin wrote:
> I'm trying to compile RTT (didn't try OCL yet) on win32 with VS 2008.
> First, I had to make some modifications to be able to compile the main
> library:
>
> - Replace "using detail" with "using RTT::detail" because it was
> ambigous with "boost::detail" for MSVC.
This can also be related to your version of boost. I had similar issues
with boost .39
> - Add BOOST_ALL_NO_LIB in preprocessor definitions to disable auto-link
> for boost (was mixing static vs. dynamic)
> - Enable OS_NO_ASM (was disabled by default)
Should not be necessary as all intrinsics have been ported to win32.
> Then, I was able to compile orocos-rtt, orocos-rtt-corba and some units
> tests. However, everything related to Corba has many linking errors.
All the targets are fully operational on RTT 2.1, I don't know yet for
2.2. I'm on it.
> Did someone has already tried to compile RTT 2.x on win32?
I was "maintaining" the win32 port of RTT and I had time to provide
patches up to the RTT 2.1 (should be available on my gitorious clone).
I'm working to provide a RTT 2.2 merge request for win32 as soon as a
get enough time to work on it (ideally by middle of january).
I can have a quick look though to tackle the most obvious issues.
> Also, many unit tests fail such as core-test, plugins_test, ports_test,
> service_test, etc.
All the tests are working on RTT 2.1, should not be too hard to fix for
2.2 I hope.
> I'm using ACE&TAO 1.6 and Boost 1.39.
I'm currently using ACE/TAO 1.8.2 and Boost 1.44 (some namespace issues
and include path have changed since the previous versions).
Orocos Toolchain 2.2 broken on win32 ?
2011/1/3 Jean Sreng <jean [dot] sreng [..] ...>
>
> > Did someone has already tried to compile RTT 2.x on win32?
>
> I was "maintaining" the win32 port of RTT and I had time to provide
> patches up to the RTT 2.1 (should be available on my gitorious clone).
> I'm working to provide a RTT 2.2 merge request for win32 as soon as a
> get enough time to work on it (ideally by middle of january).
> I can have a quick look though to tackle the most obvious issues.
>
>
You mean that the patches for RTT-2.1-win32 are in your personal clone and
aren't merged into the orocos repository?
Philippe
Orocos Toolchain 2.2 broken on win32 ?
On 06/01/2011 21:52, Philippe Hamelin wrote:jean [dot] sreng [..] ...>>
> 2011/1/3 Jean Sreng <jean [dot] sreng [..] ...
> You mean that the patches for RTT-2.1-win32 are in your personal clone
> and aren't merged into the orocos repository?
Yes, the changes are not merged in the main repo. I had some issue to
make a clean merge resquest at the time. Moreover, I introduced some
changes in the corba serialization system that might need to be
discussed before merging.
That said, the actual 2.1 version of RTT which is the master branch of
my clone is "win32 ready". I'm working on the 2.2 version, I will try to
make a "clean" merge request as soon as I can.
Orocos Toolchain 2.2 broken on win32 ?
On Thursday 06 January 2011 21:52:48 Philippe Hamelin wrote:
> 2011/1/3 Jean Sreng <jean [dot] sreng [..] ...>
>
> > > Did someone has already tried to compile RTT 2.x on win32?
> >
> > I was "maintaining" the win32 port of RTT and I had time to provide
> > patches up to the RTT 2.1 (should be available on my gitorious clone).
> > I'm working to provide a RTT 2.2 merge request for win32 as soon as a
> > get enough time to work on it (ideally by middle of january).
> > I can have a quick look though to tackle the most obvious issues.
>
> You mean that the patches for RTT-2.1-win32 are in your personal clone and
> aren't merged into the orocos repository?
I didn't know this branch existed, so it was never merged.
Peter
Orocos Toolchain 2.2 broken on win32 ?
2011/1/3 Jean Sreng <jean [dot] sreng [..] ...>
> Hello,
>
> On 16/12/2010 20:22, Philippe Hamelin wrote:
> > I'm trying to compile RTT (didn't try OCL yet) on win32 with VS 2008.
> > First, I had to make some modifications to be able to compile the main
> > library:
> >
> > - Replace "using detail" with "using RTT::detail" because it was
> > ambigous with "boost::detail" for MSVC.
>
> This can also be related to your version of boost. I had similar issues
> with boost .39
>
> > - Add BOOST_ALL_NO_LIB in preprocessor definitions to disable auto-link
> > for boost (was mixing static vs. dynamic)
> > - Enable OS_NO_ASM (was disabled by default)
>
> Should not be necessary as all intrinsics have been ported to win32.
>
>
I will retry with Boost 1.44.
> > Then, I was able to compile orocos-rtt, orocos-rtt-corba and some units
> > tests. However, everything related to Corba has many linking errors.
>
> All the targets are fully operational on RTT 2.1, I don't know yet for
> 2.2. I'm on it.
>
>
My intern also tried 2.1 and wasn't able to compile too. I will have to
check this out too.
> > Did someone has already tried to compile RTT 2.x on win32?
>
> I was "maintaining" the win32 port of RTT and I had time to provide
> patches up to the RTT 2.1 (should be available on my gitorious clone).
> I'm working to provide a RTT 2.2 merge request for win32 as soon as a
> get enough time to work on it (ideally by middle of january).
> I can have a quick look though to tackle the most obvious issues.
>
> > Also, many unit tests fail such as core-test, plugins_test, ports_test,
> > service_test, etc.
>
> All the tests are working on RTT 2.1, should not be too hard to fix for
> 2.2 I hope.
>
> > I'm using ACE&TAO 1.6 and Boost 1.39.
>
> I'm currently using ACE/TAO 1.8.2 and Boost 1.44 (some namespace issues
> and include path have changed since the previous versions).
>
>
I'm using the latest official release of OCI (http://www.theaceorb.com/). I
think this should be a good idea to make it work with the OCI's release
instead of the "less" stable releases of Schmidt.
I will try to compile with your configuration to see what happens. I will
keep you in touch.
Philippe
Orocos Toolchain 2.2 broken on win32 ?
On Thursday 16 December 2010 20:22:01 Philippe Hamelin wrote:
> Hello,
>
> I'm trying to compile RTT (didn't try OCL yet) on win32 with VS 2008.
> First, I had to make some modifications to be able to compile the main
> library:
>
> - Replace "using detail" with "using RTT::detail" because it was ambigous
> with "boost::detail" for MSVC.
> - Add BOOST_ALL_NO_LIB in preprocessor definitions to disable auto-link for
> boost (was mixing static vs. dynamic)
> - Enable OS_NO_ASM (was disabled by default)
Can you provide a patch ?
>
> Then, I was able to compile orocos-rtt, orocos-rtt-corba and some units
> tests. However, everything related to Corba has many linking errors.
>
> Did someone has already tried to compile RTT 2.x on win32?
I know that Jean was working on porting 2.x to win32, but I could not confirm
myself that this target works.
>
> Also, many unit tests fail such as core-test, plugins_test, ports_test,
> service_test, etc.
>
> I'm using ACE&TAO 1.6 and Boost 1.39.
There were quite some changes from 1.x to 2.x. For example, the OS_NO_ASM flag
was no longer required because win32 'intrinsics' were used to do the
assembler/lock-free part. Also the threading/time functions were modified.
Maybe we should set up a task-force of people (with Jean involved if possible)
who wish to polish this target, since I believe that there is quite some
work/debugging to do to make it work.
Peter
Orocos Toolchain 2.2 broken on win32 ?
2010/12/20 Peter Soetens <peter [..] ...>
> On Thursday 16 December 2010 20:22:01 Philippe Hamelin wrote:
> > Hello,
> >
> > I'm trying to compile RTT (didn't try OCL yet) on win32 with VS 2008.
> > First, I had to make some modifications to be able to compile the main
> > library:
> >
> > - Replace "using detail" with "using RTT::detail" because it was ambigous
> > with "boost::detail" for MSVC.
> > - Add BOOST_ALL_NO_LIB in preprocessor definitions to disable auto-link
> for
> > boost (was mixing static vs. dynamic)
> > - Enable OS_NO_ASM (was disabled by default)
>
> Can you provide a patch ?
>
>
Some fixes weren't clean (e.g. don't know exactly where to put the
BOOST_ALL_NO_LIB). But I can provide a patch for things that I'm sure they
are clean. However, I will be back in the office only in january. I will put
this in my TODOs.
> >
> > Then, I was able to compile orocos-rtt, orocos-rtt-corba and some units
> > tests. However, everything related to Corba has many linking errors.
> >
> > Did someone has already tried to compile RTT 2.x on win32?
>
> I know that Jean was working on porting 2.x to win32, but I could not
> confirm
> myself that this target works.
>
>
I took a look at his gitorious clone, but I didn't found any local changes
related to win32.
> >
> > Also, many unit tests fail such as core-test, plugins_test, ports_test,
> > service_test, etc.
> >
> > I'm using ACE&TAO 1.6 and Boost 1.39.
>
> There were quite some changes from 1.x to 2.x. For example, the OS_NO_ASM
> flag
> was no longer required because win32 'intrinsics' were used to do the
> assembler/lock-free part. Also the threading/time functions were modified.
>
>
As I remember, when not using OS_NO_ASM, I had linking error in assembly
code.
> Maybe we should set up a task-force of people (with Jean involved if
> possible)
> who wish to polish this target, since I believe that there is quite some
> work/debugging to do to make it work.
>
>
We (i.e. me and/or my colleagues) will certainly have to put some work on
that since this is one of the crucial part of our next underwater vehicle
that will be designed in 2011. It will be used again in the GUIs, and we
want all the operations/service/port interface, so working just with IDLs is
not enough.
See you in january!
Philippe