Appreciate this is a dev list, not a users list, but I suppose this is a dev-users question :-)

I have the Win32 MinGW port compiled, and trying to actually use the RTT libraries from Visual Studio (2003).

How do I get the interfaces? I'm not that familiar with unix compilers. I am assuming that .a files are library files

MinGW gave me the following files:

liborocos-rtt-win32.a
liborocos-rtt-win32.dll
liborocos-rtt-win32.dll.a

I have tried using both of the .a files in my linker "Additional Dependencies", one gives me tonnes of unresolved externals, the other gives me unresolved externals on public: __thiscall RTT::Logger::In::~In(void)

What header file(s) should I be including in my project to use RTT? What file should I be linking to?

Thanks, and apologies for the dumb questions from a Windows programmer...

On Wednesday 28 January 2009 14:54:00 kiwi [dot] net [..] ... wrote:
> Passes 4 of 8 RTT tests. Primarily based on mix of GNULinux and Mac OS X
> pthreads functionality (hence relies on pthreads-win32 package). Build
> details on wiki page to follow shortly.

--- tests/event_test.cpp	(revision 29869)
+++ tests/event_test.cpp	(working copy)
@@ -31,6 +31,10 @@
 #include <boost/bind.hpp>
 #include <boost/scoped_ptr.hpp>
 
+#ifdef  OROPKG_OS_WIN32
+#define sleep(x)    usleep((x) * 1000000L)
+#endif
+
 // Registers the fixture into the 'registry'
 CPPUNIT_TEST_SUITE_REGISTRATION( EventTest );
 

The sleep() redefinition should go in win32/fosi.h

Why did you comment the __WIN32__ section in rtt-config.h.in ?

Why change this include ? It won't work when the file is installed...

--- src/os/oro_i386/oro_atomic.h	(revision 29869)
+++ src/os/oro_i386/oro_atomic.h	(working copy)
@@ -37,7 +37,7 @@
 
 
 
-#include "../../rtt-config.h"
+#include "rtt-config.h"
 #ifndef __ARCH_I386_ORO_ATOMIC__
 #define __ARCH_I386_ORO_ATOMIC__
 

Your patch will definately need parts of my patch which modify the type system
to use typeid. It solves the 'unknown type' errors, which makes most unit
tests fail.

Peter

On Wednesday 28 January 2009 14:54:00 kiwi [dot] net [..] ... wrote:
> Passes 4 of 8 RTT tests. Primarily based on mix of GNULinux and Mac OS X
> pthreads functionality (hence relies on pthreads-win32 package). Build
> details on wiki page to follow shortly.

Thanks !

Could you post a full listing of the output of the tests ? Such that we can
see which tests fail ? Did you consider my patch, which includes fixes for the
type system when using DLLs ?

Peter

Forgot to add this to the post ...

As MinGW doesn't support symlinks at all, I had to change a couple of the ''#include'' statements in RTT. I did not test their affect on Linux/OS-X systems. This is a primary cause of concern with the patch ... well, along with the fact that the patch isn't complete as all tests don't pass. :-)

Some instructions on how I got this all to work is at http://www.orocos.org/node/1040

> We used this kind of communication to do some visualisation > in Blender. I have
> a student working now on a generic configurable web-based interface using the
> same idea (python+CORBA)

We are planning to create a python+CORBA based web interface for our OROCOS application too. Will this students effort be publicly available or even be part of OROCOS?

regards
Marc

On Jan 23, 2009, at 07:36 , Ruben Smits wrote:

> On Thursday 22 January 2009 15:18:08 S Roderick wrote:
>> I've recently been tasked with controlling one or more Orocos-based
>> Linux robot control computers, from a Windoze box. :-( I would prefer
>> to follow our project's existing GUI approach using Orocos ports/
>> methods/command/proxies/... and CORBA, which would involve getting
>> Orocos working under Windows (non-RT of course). I am open to other
>> options though ... so from discussions in the past few months it
>> appears that options are:
>>
>> - Ruben mentioned some Python extensions to access components, and
>> use
>> CORBA.
>
> I used the python bindings from omniORB to communicate with a remote
> OROCOS
> component. The python part was non-OROCOS, the only thing i used
> from rtt was
> the idl-files, to get the available CORBA-interface for the
> components.
> I could have used C++ too on the remote side, but python was easier
> to do some
> quick testing. On the python-side i only had the functionality
> which was
> defined in the idl-files. It is off-course nothing like a real RTT-
> TaskContext.

Ok, understood. Thanks for the info. The approach certainly has merit
for prototyping and would probably work for the scenario we have in
mind, however, I'm working with scientists and not engineers and I
think there heads would come completely off if I asked to shoe-horn
Python into their application. :-)

> We used this kind of communication to do some visualisation in
> Blender. I have
> a student working now on a generic configurable web-based interface
> using the
> same idea (python+CORBA)

Interesting idea ... so controlling a robot through a web interface?
S

On Jan 23, 2009, at 07:14 , Peter Soetens wrote:

> On Thursday 22 January 2009 15:18:08 S Roderick wrote:
>> I've recently been tasked with controlling one or more Orocos-based
>> Linux robot control computers, from a Windoze box. :-(
>
> How does the Windows system communicate with the hardware ? What was
> the
> motivation tyo switch ?

Windoze computer <--> Linux computer <--> Robot

Windows communicates with Linux/Orocos box that is actually talking to
the robot. They are just adding another level of control.

>>> I would prefer
>> to follow our project's existing GUI approach using Orocos ports/
>> methods/command/proxies/... and CORBA, which would involve getting
>> Orocos working under Windows (non-RT of course). I am open to other
>> options though ... so from discussions in the past few months it
>> appears that options are:
>>
>> - Ruben mentioned some Python extensions to access components, and
>> use
>> CORBA.
>>
>> - Peter mentioned using MinGW as the basis for a minimal port (I
>> presume instead of using the native Win API?)
>
> My ideas were earlier posted on this list, but anyway...
>
> I used the mingw posix api. The hard part was the difference between
> DLL and
> .so files on how they handle 'weak' symbols, of which we have plenty
> because of
> the C++ templates. I fixed this by using a new system for looking up
> types,
> which works for both DLL and .so files. It's in the patch.

Patch, what patch?

> I use cmake in cygwin to generate makefiles.
>
> I omitted any notion of priorities (all threads run in the same
> priority
> level).

I would do the same. We won't actually be using TaskContext's at all,
just proxy ports/commands/etc.

> I ported only RTT, not OCL

Works for me.

> I favour a win32 API port.

Yuck! :-) I was strongly leaning towards the mingw/posix API approach,
given our needs. You mixed cygwin in with mingw as well? Did cmake not
work under mingw? Did you get up to the point of using CORBA?

Thanks
Stephen