The directory /opt/www/bruyninckxh2/web/tmp/drutex-23369e1a8c7e17c70290d0b3b473b4b1-1 has been created.

Windows port

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.

- Peter mentioned using MinGW as the basis for a minimal port (I
presume instead of using the native Win API?)

- Jimmy mentioned already having RTT running under MinGW on Windows.

Would those mentioned above mind elaborating on their approach, and in
particular, what state is it in and what limitations does it suffer? I
can put some hours into assisting this port effort.

Cheers
Stephen

PS: Herman did mention custom IP protocols. This is not an option for
me - I am *not* building yet another custom IP protocol for this
(wasted enough of my career doing that already!)

Windows port

Hi Stephen,

sorry for this late reply. Hope that you can still use my comments.

Regarding my port
*it is based solely on mingw32, no msys or cygwin.
*it use native windows threads. No need for pthreads.
*only ports RTT, and currently without support for Corba
*it uses the fixes that Peter made regarding 'weak' symbol handling.
*4 out of 8 tests work. (ported CPPUnit to BOOST tests since CPPUnit requires the obnoxious automake )
*Priorities are supported on thread level, though creating new processes could help get better "realtime" support.
*CMake is used to generate the project: cmake -G"MinGW Makefiles" .

Cheers,
Jimmy

PS, patch is attached to bug 605. "https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=605"

Stupid Question time.

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...

Stupid Question time.

2009/2/10 <markgillespie [..] ...>:
> 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...
> --

I'm not sure about that, but maybe your anwser is here :

http://www.mingw.org/old/mingwfaq.shtml#faq-msvcdll

Please tell me if it works, because I will have to do that in the near futur :)

Philippe

Stupid Question time.

Have something sort of working under native Win32/Visual Studio 2003 using
the MinGW Compiled RTT (with the patches).

Using the info here: http://www.mingw.org/old/mingwfaq.shtml#faq-msvcdll

I managed to create DEF files, and use Microsofts LIB tool to turn the
library it into something MSVC likes.

I'm no CMake expert, and don't have the time to learn **another** build
scripting language, however I created the CMake files in the usual way,
built RTT and ensure it compiled cleanly. I hacked the created makefiles
by a search of my source tree for "--out-implib" and found that link.txt
that lives in build\src\CMakeFiles\orocos-rtt-dynamic_win32.dir had that
string in it. So I added the
--output-def,..\..\libs\liborocos-rtt-win32.dll.def, to create the def
file, and rebuilt RTT, this created the DEF file, I than ran it through the
Microsoft LIB tool as described.

I then created a MSVC project, added the library to my linker settings, and
made a very simply MSVC console application:

#include "rtt\os\main.h"
#include "rtt\rtt-config.h"

int ORO_main(int, char**)
{
return 0;
}

I also needed to setup my MSVC preprocessor definitions:

NDEBUG
_CONSOLE
__i386__
__MINGW32__
OROCOS_TARGET=win32
OROBLD_DISABLE_LOGGING

Note that I had to disable logging, because when I tried to link, I got the
following unknown externals:

Linking...
OrocosTest.obj : error LNK2019: unresolved external symbol "public:
__thiscall RTT::Logger::In::~In(void)" (??1In@Logger@RTT@@QAE@XZ)
referenced in function _main
OrocosTest.obj : error LNK2019: unresolved external symbol "public:
__thiscall RTT::Logger::In::In(class std::basic_string std::char_traits,class std::allocator > const &)"
(??0In@Logger@RTT@@QAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z)
referenced in function _main
Release/OrocosTest.exe : fatal error LNK1120: 2 unresolved externals

Hopefully I am now at a stage when I can actually start to evaluate RTT :-)
If anyone has any ideas on how to fix the logging, or how to properly get the CMakeList.txt to generate the DEF files without nasty post-CMake hacks, then I would love to hear it...

Stupid Question time.

Hi Mark,

On Tuesday 17 February 2009 13:06:40 markgillespie [..] ... wrote:
> Have something sort of working under native Win32/Visual Studio 2003 using
> the MinGW Compiled RTT (with the patches).
>
> Using the info here: http://www.mingw.org/old/mingwfaq.shtml#faq-msvcdll

Would you mind taking 10 minutes and extend the wiki here:
http://www.orocos.org/node/1040 ? (even if it's mostly copy/pasting)

I understand its a hack, but writing it down on an easy to find place might
help someone later for pointing out the right way to do it.

Another note about the evaluation: an important part of Orocos is the dynamic
loading of type libraries and components, something which is in OCL and not
yet ported to Windows. Also missing is the TaskBrowser is the standard tool
that all new users use to interact with their components. We'd probably need
to setup a new wiki page to cover all aspects of OCL.

Thanks !

Peter

Not had much luck creating

Not had much luck creating .DEF files using that link, the CMake system seems to muddy the waters.

Can I ask anyone using the Win32 ports, how they use the RTT.. A sample VC Proj would be a massive help!!!

Not had much luck creating

Hy,

I have compiled RTT for Win32 using the "MSYS Generator" and Mingw GCC.
Of course resulting executables need mingw. Maybe you don't want that.

Sander.

> -----Original Message-----
> From: orocos-dev-bounces [..] ... [mailto:orocos-dev-
> bounces [..] ...] On Behalf Of markgillespie [..] ...
> Sent: maandag 16 februari 2009 16:06
> To: orocos-dev [..] ...
> Subject: [Orocos-Dev] Not had much luck creating
>
> Not had much luck creating .DEF files using that link, the CMake
system
> seems to muddy the waters.
>
> Can I ask anyone using the Win32 ports, how they use the RTT.. A
sample
> VC Proj would be a massive help!!!
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>
> ______________________________________________________________________
> This email has been scanned by the Email Security System.
> ______________________________________________________________________

Not had much luck creating

Hi,

The resulting executable should not depend on mingw. It's supposed to
be native win32. Maybe you are confusing MinGW with the Cygwin port?

Philippe

2009/2/18 Vandenbroucke Sander <Sander [dot] Vandenbroucke [..] ...>:
> Hy,
>
> I have compiled RTT for Win32 using the "MSYS Generator" and Mingw GCC.
> Of course resulting executables need mingw. Maybe you don't want that.
>
> Sander.
>
>> -----Original Message-----
>> From: orocos-dev-bounces [..] ... [mailto:orocos-dev-
>> bounces [..] ...] On Behalf Of markgillespie [..] ...
>> Sent: maandag 16 februari 2009 16:06
>> To: orocos-dev [..] ...
>> Subject: [Orocos-Dev] Not had much luck creating
>>
>> Not had much luck creating .DEF files using that link, the CMake
> system
>> seems to muddy the waters.
>>
>> Can I ask anyone using the Win32 ports, how they use the RTT.. A
> sample
>> VC Proj would be a massive help!!!
>>
>> --
>> Orocos-Dev mailing list
>> Orocos-Dev [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>>
>> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the Email Security System.
>> ______________________________________________________________________
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>

Not had much luck creating

> Hi,
>
> The resulting executable should not depend on mingw. It's supposed to
> be native win32. Maybe you are confusing MinGW with the Cygwin port?
>
Hi,

I did a port to a pthread lib for windows once. I used the MinGW-gcc
compiler, witch uses native windows (no cygwin). Also, the resulting
executable doesn't require Cygwin. To build it I used CMake with the
"MinGW Generator". To be crystal clear: I did not use any of the current
windows ports of OROCOS, they didn't exist yet.

Sander.

Initial patch

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.

Initial patch

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.

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

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...

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

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

Initial patch

On Jan 29, 2009, at 05:30 , Peter Soetens wrote:

> 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.
>
> &#10;&gt; --- tests/event_test.cpp      (revision 29869)&#10;&gt; +++ tests/event_test.cpp      (working copy)&#10;&gt; @@ -31,6 +31,10 @@&#10;&gt; #include &lt;boost/bind.hpp&gt;&#10;&gt; #include &lt;boost/scoped_ptr.hpp&gt;&#10;&gt;&#10;&gt; +#ifdef  OROPKG_OS_WIN32&#10;&gt; +#define sleep(x)    usleep((x) * 1000000L)&#10;&gt; +#endif&#10;&gt; +&#10;&gt; // Registers the fixture into the &#039;registry&#039;&#10;&gt; CPPUNIT_TEST_SUITE_REGISTRATION( EventTest );&#10;&gt;&#10;&gt;
>
> The sleep() redefinition should go in win32/fosi.h

I wondered where it should go.

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

See attached compile.log. The commented out code breaks stuff, and it
didn't seem to be needed once I got the tests built.

> Why change this include ? It won't work when the file is installed...
>
>
> &#10;&gt; --- src/os/oro_i386/oro_atomic.h      (revision 29869)&#10;&gt; +++ src/os/oro_i386/oro_atomic.h      (working copy)&#10;&gt; @@ -37,7 +37,7 @@&#10;&gt;&#10;&gt;&#10;&gt;&#10;&gt; -#include &quot;../../rtt-config.h&quot;&#10;&gt; +#include &quot;rtt-config.h&quot;&#10;&gt; #ifndef __ARCH_I386_ORO_ATOMIC__&#10;&gt; #define __ARCH_I386_ORO_ATOMIC__&#10;&gt;&#10;&gt;

Because MinGW doesn't support symlinks, and this was the only way I
found to get it to work. This was my primary concern in the initial
patch - that this would break something downstream. We need to find a
better solution.

> 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.

Most likely, yes.
S

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Initial patch

On Thursday 29 January 2009 14:21:35 S Roderick wrote:
>
> I wondered where it should go.
>
> > Why did you comment the __WIN32__ section in rtt-config.h.in ?
>
> See attached compile.log. The commented out code breaks stuff, and it
> didn't seem to be needed once I got the tests built.

It kind-of surprises me that it influences that line of code... The compiler
confuses the narrow function with the one in a base class. If you rename
AssignableDataSource::narrow to AssignableDataSource::narrowADS, the bug
should disappear. The 'narrow' bug 'sounds' familiar to me... which compiler
were you using ?

>
> > Why change this include ? It won't work when the file is installed...
> >
> >
> > &#10;&gt; &gt; --- src/os/oro_i386/oro_atomic.h (revision 29869)&#10;&gt; &gt; +++ src/os/oro_i386/oro_atomic.h (working copy)&#10;&gt; &gt; @@ -37,7 +37,7 @@&#10;&gt; &gt;&#10;&gt; &gt;&#10;&gt; &gt;&#10;&gt; &gt; -#include &quot;../../rtt-config.h&quot;&#10;&gt; &gt; +#include &quot;rtt-config.h&quot;&#10;&gt; &gt; #ifndef __ARCH_I386_ORO_ATOMIC__&#10;&gt; &gt; #define __ARCH_I386_ORO_ATOMIC__&#10;&gt; &gt;&#10;&gt; &gt;
>
> Because MinGW doesn't support symlinks, and this was the only way I
> found to get it to work. This was my primary concern in the initial
> patch - that this would break something downstream. We need to find a
> better solution.

I know how to fix this. You need to add ${PROJ_SOURCE_DIR}/src/os to your
global CMAKE include paths. It has nothing to do with symlinks. The symlink is
only for doxygen generation.

Peter

Initial patch

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

Initial patch

On Jan 29, 2009, at 05:11 , Peter Soetens wrote:

> 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 ?

Attached. I did use some of your patch, but didn't get around to the
type issues. I think the timing is broken, and had been concentrating
on things like that.

Cheers
S

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Worries with patch

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. :-)

Wiki instructions

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

Wiki instructions

Why do you build CMake from source instead of just downloading the installer for Windows?<br><br>Philippe<br><br><div class="gmail_quote">2009/1/28 <span dir="ltr">&lt;<a href="http://kiwi.net">kiwi.net</a>@<a href="http://mac.com">mac.com</a>&gt;</span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Some instructions on how I got this all to work is at <a href="http://www.orocos.org/node/1040" target="_blank">http://www.orocos.org/node/1040</a><br>

<font color="#888888">--<br>
Orocos-Dev mailing list<br>
<a href="mailto:Orocos-Dev [..] ...">Orocos-Dev [..] ...</a><br>
<a href="http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev" target="_blank">http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev</a><br>
<br>
Disclaimer: <a href="http://www.kuleuven.be/cwis/email_disclaimer.htm" target="_blank">http://www.kuleuven.be/cwis/email_disclaimer.htm</a><br>
<br>
</font></blockquote></div><br>

Wiki instructions

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I wasn't sure of the interaction of something specifically built for the Windows world, and something compiled from source in MinGW. So I went with what I felt with the safest option.&nbsp;<div><br></div><div>YMMV</div><div>S</div><div><br><div><div>On Jan 28, 2009, at 16:40 , Philippe Hamelin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Why do you build CMake from source instead of just downloading the installer for Windows?<br><br>Philippe<br><br><div class="gmail_quote">2009/1/28 <span dir="ltr">&lt;<a href="http://kiwi.net">kiwi.net</a>@<a href="http://mac.com">mac.com</a>></span><br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Some instructions on how I got this all to work is at <a href="http://www.orocos.org/node/1040" target="_blank">http://www.orocos.org/node/1040</a><br> <font color="#888888">--<br> Orocos-Dev mailing list<br> <a href="mailto:Orocos-Dev [..] ...">Orocos-Dev [..] ...</a><br> <a href="http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev" target="_blank">http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev</a><br> <br> Disclaimer: <a href="http://www.kuleuven.be/cwis/email_disclaimer.htm" target="_blank">http://www.kuleuven.be/cwis/email_disclaimer.htm</a><br> <br> </font></blockquote></div><br></blockquote></div><br></div></body></html>

Ruben Smits's picture

Windows port

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.

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)

Ruben

CORBA+Python based generic Web Interface

> 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

Ruben Smits's picture

CORBA+Python based generic Web Interface

On Friday 06 February 2009 14:06:55 marc [dot] bodmer [..] ... wrote:
> > 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?

Of course it will :), I expect some results by the end of March, I will report
and comment on the mailinglist if I get my hand on some presentable results.
So stay tuned ;)

Ruben

Windows port

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

Windows port

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 ?

> > 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.

I use cmake in cygwin to generate makefiles.

I omitted any notion of priorities (all threads run in the same priority
level).

I ported only RTT, not OCL

I favour a win32 API port.

Peter

Windows port

<div class="gmail_quote">2009/1/23 Peter Soetens <span dir="ltr">&lt;<a href="mailto:peter [dot] soetens [..] ...">peter [dot] soetens [..] ...</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Thursday 22 January 2009 15:18:08 S Roderick wrote:<br>
&gt; I&#39;ve recently been tasked with controlling one or more Orocos-based<br>
&gt; Linux robot control computers, from a Windoze box. :-(<br>
<br>
</div>How does the Windows system communicate with the hardware ? What was the<br>
motivation tyo switch ?<br>
<div class="Ih2E3d"><br>
&gt; &gt; I would prefer<br>
&gt; to follow our project&#39;s existing GUI approach using Orocos ports/<br>
&gt; methods/command/proxies/... and CORBA, which would involve getting<br>
&gt; Orocos working under Windows (non-RT of course). I am open to other<br>
&gt; options though ... so from discussions in the past few months it<br>
&gt; appears that options are:<br>
&gt;<br>
&gt; - Ruben mentioned some Python extensions to access components, and use<br>
&gt; CORBA.<br>
&gt;<br>
&gt; - Peter mentioned using MinGW as the basis for a minimal port (I<br>
&gt; presume instead of using the native Win API?)<br>
<br>
</div>My ideas were earlier posted on this list, but anyway...<br>
<br>
I used the mingw posix api. The hard part was the difference between DLL and<br>
.so files on how they handle &#39;weak&#39; symbols, of which we have plenty because of<br>
the C++ templates. I fixed this by using a new system for looking up types,<br>
which works for both DLL and .so files. It&#39;s in the patch.<br>
</blockquote><div><br>So you compiled RTT with MinGW under Cygwin? This means you are dependent of the Cygwin DLL ? My idea is that we should use MinGW for win32 (not the Cygwin POSIX version) to have better performances.<br>
&nbsp;<br>Philippe<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
I use cmake in cygwin to generate makefiles.<br>
<br>
I omitted any notion of priorities (all threads run in the same priority<br>
level).<br>
<br>
I ported only RTT, not OCL<br>
<br>
I favour a win32 API port.<br>
<br>
Peter<br>
<font color="#888888">--<br>
Peter Soetens -- FMTC -- &lt;<a href="http://www.fmtc.be" target="_blank">http://www.fmtc.be</a>&gt;<br>
</font><div><div></div><div class="Wj3C7c">--<br>
Orocos-Dev mailing list<br>
<a href="mailto:Orocos-Dev [..] ...">Orocos-Dev [..] ...</a><br>
<a href="http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev" target="_blank">http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev</a><br>
<br>
Disclaimer: <a href="http://www.kuleuven.be/cwis/email_disclaimer.htm" target="_blank">http://www.kuleuven.be/cwis/email_disclaimer.htm</a><br>
<br>
</div></div></blockquote></div><br>

Windows port

On Friday 23 January 2009 15:13:24 Philippe Hamelin wrote:
> >
> > 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.
>
> So you compiled RTT with MinGW under Cygwin? This means you are dependent
> of the Cygwin DLL ? My idea is that we should use MinGW for win32 (not the
> Cygwin POSIX version) to have better performances.

My mistake. I Did gcc/cygwin port. And I favour mingw+win32.

Peter

Windows port

On Jan 23, 2009, at 10:03 , Peter Soetens wrote:

> On Friday 23 January 2009 15:13:24 Philippe Hamelin wrote:
>>>
>>> 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.
>>
>> So you compiled RTT with MinGW under Cygwin? This means you are
>> dependent
>> of the Cygwin DLL ? My idea is that we should use MinGW for win32
>> (not the
>> Cygwin POSIX version) to have better performances.
>
> My mistake. I Did gcc/cygwin port. And I favour mingw+win32.

You had my hopes up for a second there ... :-)
S

Windows port

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

Windows port

On Friday 23 January 2009 14:14:45 Stephen Roderick wrote:
> >
> > 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?

Bug #605.

>
> > 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.

So what I mean is win32 api + mingw.

>
> 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?

Whoops. That was a typo. I used gcc under cygwin, not mingw. So I only
did the 'slow'/2h work port.

Peter

Windows port

On Jan 23, 2009, at 10:02 , Peter Soetens wrote:

> On Friday 23 January 2009 14:14:45 Stephen Roderick wrote:
>>>
>>> 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?
>
> Bug #605.

Thanks

>>> 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.
>
> So what I mean is win32 api + mingw.

I'm aiming for mingw + pthreads-win32 (which uses win32 api
underneath). If this isn't exactly what you mean, then I think it
would be a start ...

>> 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?
>
> Whoops. That was a typo. I used gcc under cygwin, not mingw. So I only
> did the 'slow'/2h work port.

I'm working on the mingw side of things. I'm *hopeful* that with
pthreads-win32 involved, it might be more like 2 days than 2 weeks to
achieve RTT. Hoping ... ;-)

S

Windows port

<br><br><div class="gmail_quote">2009/1/23 Stephen Roderick <span dir="ltr">&lt;<a href="http://kiwi.net">kiwi.net</a>@<a href="http://mac.com">mac.com</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Jan 23, 2009, at 10:02 , Peter Soetens wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Friday 23 January 2009 14:14:45 Stephen Roderick wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
I used the mingw posix api. The hard part was the difference between<br>
DLL and<br>
.so files on how they handle &#39;weak&#39; symbols, of which we have plenty<br>
because of<br>
the C++ templates. I fixed this by using a new system for looking up<br>
types,<br>
which works for both DLL and .so files. It&#39;s in the patch.<br>
</blockquote>
<br>
Patch, what patch?<br>
</blockquote>
<br>
Bug #605.<br>
</blockquote>
<br></div>
Thanks<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I use cmake in cygwin to generate makefiles.<br>
<br>
I omitted any notion of priorities (all threads run in the same<br>
priority<br>
level).<br>
</blockquote>
<br>
I would do the same. We won&#39;t actually be using TaskContext&#39;s at all,<br>
just proxy ports/commands/etc.<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I ported only RTT, not OCL<br>
</blockquote>
<br>
Works for me.<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I favour a win32 API port.<br>
</blockquote></blockquote>
<br>
So what I mean is win32 api + mingw.<br>
</blockquote>
<br></div>
I&#39;m aiming for mingw + pthreads-win32 (which uses win32 api underneath). &nbsp;If this isn&#39;t exactly what you mean, then I think it would be a start ...<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Yuck! :-) I was strongly leaning towards the mingw/posix API approach,<br>
given our needs. You mixed cygwin in with mingw as well? Did cmake not<br>
work under mingw? Did you get up to the point of using CORBA?<br>
</blockquote>
<br>
Whoops. That was a typo. I used gcc under cygwin, not mingw. So I only<br>
did the &#39;slow&#39;/2h work port.<br>
</blockquote>
<br></div>
I&#39;m working on the mingw side of things. I&#39;m *hopeful* that with pthreads-win32 involved, it might be more like 2 days than 2 weeks to achieve RTT. Hoping ... ;-)<br><font color="#888888">
</font></blockquote><div><br>Well, if you send a patch within 2 days for the win32 port of RTT+CORBA I will gratefully send you a postcard :-)<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font color="#888888"><br>
S</font><div><div></div><div class="Wj3C7c"><br>
-- <br>
Orocos-Dev mailing list<br>
<a href="mailto:Orocos-Dev [..] ..." target="_blank">Orocos-Dev [..] ...</a><br>
<a href="http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev" target="_blank">http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev</a><br>
<br>
Disclaimer: <a href="http://www.kuleuven.be/cwis/email_disclaimer.htm" target="_blank">http://www.kuleuven.be/cwis/email_disclaimer.htm</a><br>
<br>
</div></div></blockquote></div><br><br>