win32 branch&patches merging

Submitted by peter on Fri, 2011-02-04 11:52

RTT-dev

Dear win32 testers,

I was looking in merging the outstanding win32 patches onto master, but some
changes on Jean's branch need more review. Especially this commit:

http://gitorious.org/orocos-toolchain/jsrengs-
rtt/commit/506a183a9a3c0e6c3a9220e6333812c1a04bc0c5

It quite heavily violates the coding style and rewrites a lot of whitespace on
lines that could have left untouched.

Next from the technical side: is this purely an add-on ? Ie, is any existing
behaviour changed in the CORBA transport ?

It also contains a hard-coded reference to TAO:

static bool 
toCorbaType(TAO::details::string_sequence_element<TAO::details::string_traits<char, 
dummy> >& dest, const StdType& src) {

That definately needs to be #ifdef'ed or written portably such that it works
with Omniorb as well.

We could replace it with for example:

      template<class dummy>
      static bool toCorbaType(dummy& dest, const StdType& src) {

Which compiles fine here (TAO+Omniorb on Linux), but I don't know if this will
still do as was intended ?

I could also apply Philippe's patches without much trouble. Are they the
definitive solutions for win32 ?

I pushed my results to
https://github.com/psoetens/orocos-rtt/tree/master-with-jsreng
for your reference.

Peter

win32 branch&patches merging

Submitted by jean.sreng on Tue, 2011-02-15 17:12.

On 04/02/2011 12:50, Peter Soetens wrote:
> Dear win32 testers,

I have a minor fix patch for Visual 2010 compilation (see attached, or
do you prefer if I directly push it in the master of orocos-rtt repo ?).

However, some unit tests (like task-test) randomly fail with some weird
heap corruption on Visual 2010 (I suspect something involving
multithreading and dtors). I have to investigate...

win32 branch&patches merging

Submitted by jean.sreng on Fri, 2011-02-18 18:48.

On 15/02/2011 17:31, Jean Sreng wrote:
> However, some unit tests (like task-test) randomly fail with some weird
> heap corruption on Visual 2010 (I suspect something involving
> multithreading and dtors). I have to investigate...

Problem solved by your last win32 patches !

win32 branch&patches merging

Submitted by phamelin on Fri, 2011-02-04 13:40.

Hi Peter,

> I was looking in merging the outstanding win32 patches onto master, but
> some
> changes on Jean's branch need more review. Especially this commit:
>

Thank you for spending some time on the win32 port of Orocos.

>
> I could also apply Philippe's patches without much trouble. Are they the
> definitive solutions for win32 ?
>
>
My first trial with Orocos 2.x on win32 was with Jean's branch. We did some
work to make it compile on our side with the patches that you merged.
However, Jean's branch was against 2.1 and we really needed 2.2. The idea
was to take only win32 related stuff from Jean's branch and not all the
stuff here. Unfortunately, we weren't able to find which commits were
related exclusively to the win32 port, so we decided to go directly with
2.2.0. We applied the same patches as we did in Jean's branch, plus some
others for OCL. We didn't look at unit tests yet, but our applications are
so far running fine. I will send in the next one or two hours the complete
set of patches against 2.2.0 for RTT and OCL. I will also try to run unit
tests to see what happen. Altough our applications run fine, I can't say if
this is a _definitive_ solution until all unit tests pass.

Philippe

win32 branch&patches merging

Submitted by peter on Fri, 2011-02-04 14:28.

On Friday 04 February 2011 14:38:14 Philippe Hamelin wrote:
> Hi Peter,
>
> > I was looking in merging the outstanding win32 patches onto master, but
> > some
>
> > changes on Jean's branch need more review. Especially this commit:
> Thank you for spending some time on the win32 port of Orocos.
>
> > I could also apply Philippe's patches without much trouble. Are they the
> > definitive solutions for win32 ?
>
> My first trial with Orocos 2.x on win32 was with Jean's branch. We did some
> work to make it compile on our side with the patches that you merged.
> However, Jean's branch was against 2.1 and we really needed 2.2. The idea
> was to take only win32 related stuff from Jean's branch and not all the
> stuff here. Unfortunately, we weren't able to find which commits were
> related exclusively to the win32 port, so we decided to go directly with
> 2.2.0. We applied the same patches as we did in Jean's branch, plus some
> others for OCL. We didn't look at unit tests yet, but our applications are
> so far running fine. I will send in the next one or two hours the complete
> set of patches against 2.2.0 for RTT and OCL. I will also try to run unit
> tests to see what happen. Altough our applications run fine, I can't say if
> this is a _definitive_ solution until all unit tests pass.

Hmm. I don't follow here. If you required 2.2 + Jean's patches, then you only
need to do:

Jean's master == toolchain-2.1 + some parts of 2.2 + his patches

So to get Jean's patches on 2.2, do:

git checkout toolchain-2.2 (latest stable)
git merge jsreng/master
+ apply your own patches.

What I did was:

git checkout master (will become toolchain-2.3)
git merge jsreng/master
+ apply your own patches.

I can confirm that most unit tests will fail if they can't find the typekits.
Setting ORO_LOGLEVEL=7 prior to starting the unit test should reveal where
it's looking for them. You can also set the RTT_COMPONENT_PATH to point to the
directory which contains the 'types'&'plugins' subdirs. This is most of the
time 'build/rtt'

Peter

win32 branch&patches merging

Submitted by phamelin on Fri, 2011-02-04 14:44.

2011/2/4 Peter Soetens <peter [..] ...>

> On Friday 04 February 2011 14:38:14 Philippe Hamelin wrote:
> > Hi Peter,
> >
> > > I was looking in merging the outstanding win32 patches onto master, but
> > > some
> >
> > > changes on Jean's branch need more review. Especially this commit:
> > Thank you for spending some time on the win32 port of Orocos.
> >
> > > I could also apply Philippe's patches without much trouble. Are they
> the
> > > definitive solutions for win32 ?
> >
> > My first trial with Orocos 2.x on win32 was with Jean's branch. We did
> some
> > work to make it compile on our side with the patches that you merged.
> > However, Jean's branch was against 2.1 and we really needed 2.2. The idea
> > was to take only win32 related stuff from Jean's branch and not all the
> > stuff here. Unfortunately, we weren't able to find which commits were
> > related exclusively to the win32 port, so we decided to go directly with
> > 2.2.0. We applied the same patches as we did in Jean's branch, plus some
> > others for OCL. We didn't look at unit tests yet, but our applications
> are
> > so far running fine. I will send in the next one or two hours the
> complete
> > set of patches against 2.2.0 for RTT and OCL. I will also try to run unit
> > tests to see what happen. Altough our applications run fine, I can't say
> if
> > this is a _definitive_ solution until all unit tests pass.
>
> Hmm. I don't follow here. If you required 2.2 + Jean's patches, then you
> only
> need to do:
>
> Jean's master == toolchain-2.1 + some parts of 2.2 + his patches
>
> So to get Jean's patches on 2.2, do:
>
> git checkout toolchain-2.2 (latest stable)
> git merge jsreng/master
> + apply your own patches.
>
> What I did was:
>
> git checkout master (will become toolchain-2.3)
> git merge jsreng/master
> + apply your own patches.
>
>
I could also do this, but I wasn't sure of the working state of Jean's
branch. I didn't had time to debug stuff unrelated to my work when porting
orocos 2.x on win32. I have about 5 more patches to submit for RTT and some
others for OCL. Do you prefer that I generate them against
https://github.com/psoetens/orocos-rtt/tree/master-with-jsreng ?

> I can confirm that most unit tests will fail if they can't find the
> typekits.
> Setting ORO_LOGLEVEL=7 prior to starting the unit test should reveal where
> it's looking for them. You can also set the RTT_COMPONENT_PATH to point to
> the
> directory which contains the 'types'&'plugins' subdirs. This is most of the
> time 'build/rtt'
>
>
We set RTT_COMPONENT_PATH correctly; all plugins/types are found.

Philippe

win32 branch&patches merging

Submitted by peter on Fri, 2011-02-04 14:56.

On Friday 04 February 2011 15:40:28 Philippe Hamelin wrote:
> 2011/2/4 Peter Soetens <peter [..] ...>
>
> > On Friday 04 February 2011 14:38:14 Philippe Hamelin wrote:
> > > Hi Peter,
> > >
> > > > I was looking in merging the outstanding win32 patches onto master,
> > > > but some
> > >
> > > > changes on Jean's branch need more review. Especially this commit:
> > > Thank you for spending some time on the win32 port of Orocos.
> > >
> > > > I could also apply Philippe's patches without much trouble. Are they
> >
> > the
> >
> > > > definitive solutions for win32 ?
> > >
> > > My first trial with Orocos 2.x on win32 was with Jean's branch. We did
> >
> > some
> >
> > > work to make it compile on our side with the patches that you merged.
> > > However, Jean's branch was against 2.1 and we really needed 2.2. The
> > > idea was to take only win32 related stuff from Jean's branch and not
> > > all the stuff here. Unfortunately, we weren't able to find which
> > > commits were related exclusively to the win32 port, so we decided to
> > > go directly with 2.2.0. We applied the same patches as we did in
> > > Jean's branch, plus some others for OCL. We didn't look at unit tests
> > > yet, but our applications
> >
> > are
> >
> > > so far running fine. I will send in the next one or two hours the
> >
> > complete
> >
> > > set of patches against 2.2.0 for RTT and OCL. I will also try to run
> > > unit tests to see what happen. Altough our applications run fine, I
> > > can't say
> >
> > if
> >
> > > this is a _definitive_ solution until all unit tests pass.
> >
> > Hmm. I don't follow here. If you required 2.2 + Jean's patches, then you
> > only
> > need to do:
> >
> > Jean's master == toolchain-2.1 + some parts of 2.2 + his patches
> >
> > So to get Jean's patches on 2.2, do:
> >
> > git checkout toolchain-2.2 (latest stable)
> > git merge jsreng/master
> > + apply your own patches.
> >
> > What I did was:
> >
> > git checkout master (will become toolchain-2.3)
> > git merge jsreng/master
> > + apply your own patches.
>
> I could also do this, but I wasn't sure of the working state of Jean's
> branch. I didn't had time to debug stuff unrelated to my work when porting
> orocos 2.x on win32.

When looking at another person's branch, I just fire up 'gitk jsreng/master'
for example. It nicely shows the merges done and where it branched etc. It
also has a powerful search feature.

> I have about 5 more patches to submit for RTT and some
> others for OCL. Do you prefer that I generate them against
> https://github.com/psoetens/orocos-rtt/tree/master-with-jsreng ?

I don't mind either way. Mostly, I use 'git am -3 patches...' which is able to
resolve most issues and does a 3-way merge of your patch instead of rejecting
it if it won't apply.

>
> > I can confirm that most unit tests will fail if they can't find the
> > typekits.
> > Setting ORO_LOGLEVEL=7 prior to starting the unit test should reveal
> > where it's looking for them. You can also set the RTT_COMPONENT_PATH to
> > point to the
> > directory which contains the 'types'&'plugins' subdirs. This is most of
> > the time 'build/rtt'
>
> We set RTT_COMPONENT_PATH correctly; all plugins/types are found.

OK.

Peter

win32 branch&patches merging

Submitted by phamelin on Fri, 2011-02-04 20:04.

2011/2/4 Peter Soetens <peter [..] ...>

> On Friday 04 February 2011 15:40:28 Philippe Hamelin wrote:
> > 2011/2/4 Peter Soetens <peter [..] ...>
> >
> > > On Friday 04 February 2011 14:38:14 Philippe Hamelin wrote:
> > > > Hi Peter,
> > > >
> > > > > I was looking in merging the outstanding win32 patches onto master,
> > > > > but some
> > > >
> > > > > changes on Jean's branch need more review. Especially this commit:
> > > > Thank you for spending some time on the win32 port of Orocos.
> > > >
> > > > > I could also apply Philippe's patches without much trouble. Are
> they
> > >
> > > the
> > >
> > > > > definitive solutions for win32 ?
> > > >
> > > > My first trial with Orocos 2.x on win32 was with Jean's branch. We
> did
> > >
> > > some
> > >
> > > > work to make it compile on our side with the patches that you merged.
> > > > However, Jean's branch was against 2.1 and we really needed 2.2. The
> > > > idea was to take only win32 related stuff from Jean's branch and not
> > > > all the stuff here. Unfortunately, we weren't able to find which
> > > > commits were related exclusively to the win32 port, so we decided to
> > > > go directly with 2.2.0. We applied the same patches as we did in
> > > > Jean's branch, plus some others for OCL. We didn't look at unit tests
> > > > yet, but our applications
> > >
> > > are
> > >
> > > > so far running fine. I will send in the next one or two hours the
> > >
> > > complete
> > >
> > > > set of patches against 2.2.0 for RTT and OCL. I will also try to run
> > > > unit tests to see what happen. Altough our applications run fine, I
> > > > can't say
> > >
> > > if
> > >
> > > > this is a _definitive_ solution until all unit tests pass.
> > >
> > > Hmm. I don't follow here. If you required 2.2 + Jean's patches, then
> you
> > > only
> > > need to do:
> > >
> > > Jean's master == toolchain-2.1 + some parts of 2.2 + his patches
> > >
> > > So to get Jean's patches on 2.2, do:
> > >
> > > git checkout toolchain-2.2 (latest stable)
> > > git merge jsreng/master
> > > + apply your own patches.
> > >
> > > What I did was:
> > >
> > > git checkout master (will become toolchain-2.3)
> > > git merge jsreng/master
> > > + apply your own patches.
> >
> > I could also do this, but I wasn't sure of the working state of Jean's
> > branch. I didn't had time to debug stuff unrelated to my work when
> porting
> > orocos 2.x on win32.
>
> When looking at another person's branch, I just fire up 'gitk
> jsreng/master'
> for example. It nicely shows the merges done and where it branched etc. It
> also has a powerful search feature.
>
> > I have about 5 more patches to submit for RTT and some
> > others for OCL. Do you prefer that I generate them against
> > https://github.com/psoetens/orocos-rtt/tree/master-with-jsreng ?
>
> I don't mind either way. Mostly, I use 'git am -3 patches...' which is able
> to
> resolve most issues and does a 3-way merge of your patch instead of
> rejecting
> it if it won't apply.
>
>
I pushed to my github account all the patches that we've made to make
RTT/OCL 2.2.0 work under windows :

https://github.com/phamelin/orocos-rtt/tree/master-win32-ready
https://github.com/phamelin/orocos-ocl/tree/master-win32-ready

Actually, three tests in RTT are failing to link on windows. They were all
compiling in 2.2.0 so I guess this is minor for the moment. I will give you
more info about the tests results later today or maybe next week.

Philippe

win32 branch&patches merging

Submitted by peter on Tue, 2011-02-08 09:44.

On Friday 04 February 2011 21:03:29 Philippe Hamelin wrote:
> 2011/2/4 Peter Soetens <peter [..] ...>
>
> > On Friday 04 February 2011 15:40:28 Philippe Hamelin wrote:
> > > 2011/2/4 Peter Soetens <peter [..] ...>
> > >
> > > > On Friday 04 February 2011 14:38:14 Philippe Hamelin wrote:
> > > > > Hi Peter,
> > > > >
> > > > > > I was looking in merging the outstanding win32 patches onto
> > > > > > master, but some
> > > > >
> > > > > > changes on Jean's branch need more review. Especially this commit:
> > > > > Thank you for spending some time on the win32 port of Orocos.
> > > > >
> > > > > > I could also apply Philippe's patches without much trouble. Are
> >
> > they
> >
> > > > the
> > > >
> > > > > > definitive solutions for win32 ?
> > > > >
> > > > > My first trial with Orocos 2.x on win32 was with Jean's branch. We
> >
> > did
> >
> > > > some
> > > >
> > > > > work to make it compile on our side with the patches that you
> > > > > merged. However, Jean's branch was against 2.1 and we really
> > > > > needed 2.2. The idea was to take only win32 related stuff from
> > > > > Jean's branch and not all the stuff here. Unfortunately, we
> > > > > weren't able to find which commits were related exclusively to the
> > > > > win32 port, so we decided to go directly with 2.2.0. We applied
> > > > > the same patches as we did in Jean's branch, plus some others for
> > > > > OCL. We didn't look at unit tests yet, but our applications
> > > >
> > > > are
> > > >
> > > > > so far running fine. I will send in the next one or two hours the
> > > >
> > > > complete
> > > >
> > > > > set of patches against 2.2.0 for RTT and OCL. I will also try to
> > > > > run unit tests to see what happen. Altough our applications run
> > > > > fine, I can't say
> > > >
> > > > if
> > > >
> > > > > this is a _definitive_ solution until all unit tests pass.
> > > >
> > > > Hmm. I don't follow here. If you required 2.2 + Jean's patches, then
> >
> > you
> >
> > > > only
> > > > need to do:
> > > >
> > > > Jean's master == toolchain-2.1 + some parts of 2.2 + his patches
> > > >
> > > > So to get Jean's patches on 2.2, do:
> > > >
> > > > git checkout toolchain-2.2 (latest stable)
> > > > git merge jsreng/master
> > > > + apply your own patches.
> > > >
> > > > What I did was:
> > > >
> > > > git checkout master (will become toolchain-2.3)
> > > > git merge jsreng/master
> > > > + apply your own patches.
> > >
> > > I could also do this, but I wasn't sure of the working state of Jean's
> > > branch. I didn't had time to debug stuff unrelated to my work when
> >
> > porting
> >
> > > orocos 2.x on win32.
> >
> > When looking at another person's branch, I just fire up 'gitk
> > jsreng/master'
> > for example. It nicely shows the merges done and where it branched etc.
> > It also has a powerful search feature.
> >
> > > I have about 5 more patches to submit for RTT and some
> > > others for OCL. Do you prefer that I generate them against
> > > https://github.com/psoetens/orocos-rtt/tree/master-with-jsreng ?
> >
> > I don't mind either way. Mostly, I use 'git am -3 patches...' which is
> > able to
> > resolve most issues and does a 3-way merge of your patch instead of
> > rejecting
> > it if it won't apply.
>
> I pushed to my github account all the patches that we've made to make
> RTT/OCL 2.2.0 work under windows :
>
> https://github.com/phamelin/orocos-rtt/tree/master-win32-ready
> https://github.com/phamelin/orocos-ocl/tree/master-win32-ready
>
> Actually, three tests in RTT are failing to link on windows. They were all
> compiling in 2.2.0 so I guess this is minor for the moment. I will give you
> more info about the tests results later today or maybe next week.

Thanks for this nice work. One remark:

You removed the RTT_CORBA_API decls from the AnyConversion<foo>
specialisations in RTTCorbaConversion.hpp : Is that because they are inlined
(all header) ? Won't this affect a build when the compiler decides not to
inline it ?

Peter

win32 branch&patches merging

Submitted by phamelin on Tue, 2011-02-08 14:00.

2011/2/8 Peter Soetens <peter [..] ...>

> On Friday 04 February 2011 21:03:29 Philippe Hamelin wrote:
> > 2011/2/4 Peter Soetens <peter [..] ...>
> >
> > > On Friday 04 February 2011 15:40:28 Philippe Hamelin wrote:
> > > > 2011/2/4 Peter Soetens <peter [..] ...>
> > > >
> > > > > On Friday 04 February 2011 14:38:14 Philippe Hamelin wrote:
> > > > > > Hi Peter,
> > > > > >
> > > > > > > I was looking in merging the outstanding win32 patches onto
> > > > > > > master, but some
> > > > > >
> > > > > > > changes on Jean's branch need more review. Especially this
> commit:
> > > > > > Thank you for spending some time on the win32 port of Orocos.
> > > > > >
> > > > > > > I could also apply Philippe's patches without much trouble. Are
> > >
> > > they
> > >
> > > > > the
> > > > >
> > > > > > > definitive solutions for win32 ?
> > > > > >
> > > > > > My first trial with Orocos 2.x on win32 was with Jean's branch.
> We
> > >
> > > did
> > >
> > > > > some
> > > > >
> > > > > > work to make it compile on our side with the patches that you
> > > > > > merged. However, Jean's branch was against 2.1 and we really
> > > > > > needed 2.2. The idea was to take only win32 related stuff from
> > > > > > Jean's branch and not all the stuff here. Unfortunately, we
> > > > > > weren't able to find which commits were related exclusively to
> the
> > > > > > win32 port, so we decided to go directly with 2.2.0. We applied
> > > > > > the same patches as we did in Jean's branch, plus some others for
> > > > > > OCL. We didn't look at unit tests yet, but our applications
> > > > >
> > > > > are
> > > > >
> > > > > > so far running fine. I will send in the next one or two hours the
> > > > >
> > > > > complete
> > > > >
> > > > > > set of patches against 2.2.0 for RTT and OCL. I will also try to
> > > > > > run unit tests to see what happen. Altough our applications run
> > > > > > fine, I can't say
> > > > >
> > > > > if
> > > > >
> > > > > > this is a _definitive_ solution until all unit tests pass.
> > > > >
> > > > > Hmm. I don't follow here. If you required 2.2 + Jean's patches,
> then
> > >
> > > you
> > >
> > > > > only
> > > > > need to do:
> > > > >
> > > > > Jean's master == toolchain-2.1 + some parts of 2.2 + his patches
> > > > >
> > > > > So to get Jean's patches on 2.2, do:
> > > > >
> > > > > git checkout toolchain-2.2 (latest stable)
> > > > > git merge jsreng/master
> > > > > + apply your own patches.
> > > > >
> > > > > What I did was:
> > > > >
> > > > > git checkout master (will become toolchain-2.3)
> > > > > git merge jsreng/master
> > > > > + apply your own patches.
> > > >
> > > > I could also do this, but I wasn't sure of the working state of
> Jean's
> > > > branch. I didn't had time to debug stuff unrelated to my work when
> > >
> > > porting
> > >
> > > > orocos 2.x on win32.
> > >
> > > When looking at another person's branch, I just fire up 'gitk
> > > jsreng/master'
> > > for example. It nicely shows the merges done and where it branched etc.
> > > It also has a powerful search feature.
> > >
> > > > I have about 5 more patches to submit for RTT and some
> > > > others for OCL. Do you prefer that I generate them against
> > > > https://github.com/psoetens/orocos-rtt/tree/master-with-jsreng ?
> > >
> > > I don't mind either way. Mostly, I use 'git am -3 patches...' which is
> > > able to
> > > resolve most issues and does a 3-way merge of your patch instead of
> > > rejecting
> > > it if it won't apply.
> >
> > I pushed to my github account all the patches that we've made to make
> > RTT/OCL 2.2.0 work under windows :
> >
> > https://github.com/phamelin/orocos-rtt/tree/master-win32-ready
> > https://github.com/phamelin/orocos-ocl/tree/master-win32-ready
> >
> > Actually, three tests in RTT are failing to link on windows. They were
> all
> > compiling in 2.2.0 so I guess this is minor for the moment. I will give
> you
> > more info about the tests results later today or maybe next week.
>
> Thanks for this nice work. One remark:
>
> You removed the RTT_CORBA_API decls from the AnyConversion<foo>
> specialisations in RTTCorbaConversion.hpp : Is that because they are
> inlined
> (all header) ? Won't this affect a build when the compiler decides not to
> inline it ?
>
>
I don't see how it can happens. The problem is that they were exported
(RTT_CORBA_API) but they weren't compiled in the shared library. Moreover,
these decls aren't used anywhere in the rtt-corba library so there's no
chance that the symbols were exported. When including this header file from
an other target, the linker was unsuccessfully looking for these symbol in
the rtt-corba shared lib since they were explicitly exported (and imported
from the other target side). The rule is that everytime we use
RTT_[CORBA_]API we should make sure that the corresponding symbols are
compiled and thus succesfully exported in the shared library. In other
words, we can export declarations only if the definitions are explicitely in
the shared library. GCC is usually able to deal with that, but that's
unfortunately not the case of MSVC.

Also, I pushed one more commit to solve all linking errors of tests in the
master branch:

https://github.com/phamelin/orocos-rtt/commit/1c8425e22e4769f44ba45d029b...

Today, I want to do one more QA pass on win32 (RTT and OCL) to make sure
that no patch is missing for the next release. Also, I will try to send a
short report on the current status of the win32 port such as unit tests
results. At this time, most of the tests pass, but there is always 4-5 tests
failing. Also, I don't know if the unit tests works "out of the box" since I
always do a make install before running them.

Philippe

win32 branch&patches merging

Submitted by phamelin on Tue, 2011-02-08 14:40.

2011/2/8 Philippe Hamelin <philippe [dot] hamelin [..] ...>

> 2011/2/8 Peter Soetens <peter [..] ...>
>
> On Friday 04 February 2011 21:03:29 Philippe Hamelin wrote:
>> > 2011/2/4 Peter Soetens <peter [..] ...>
>> >
>> > > On Friday 04 February 2011 15:40:28 Philippe Hamelin wrote:
>> > > > 2011/2/4 Peter Soetens <peter [..] ...>
>> > > >
>> > > > > On Friday 04 February 2011 14:38:14 Philippe Hamelin wrote:
>> > > > > > Hi Peter,
>> > > > > >
>> > > > > > > I was looking in merging the outstanding win32 patches onto
>> > > > > > > master, but some
>> > > > > >
>> > > > > > > changes on Jean's branch need more review. Especially this
>> commit:
>> > > > > > Thank you for spending some time on the win32 port of Orocos.
>> > > > > >
>> > > > > > > I could also apply Philippe's patches without much trouble.
>> Are
>> > >
>> > > they
>> > >
>> > > > > the
>> > > > >
>> > > > > > > definitive solutions for win32 ?
>> > > > > >
>> > > > > > My first trial with Orocos 2.x on win32 was with Jean's branch.
>> We
>> > >
>> > > did
>> > >
>> > > > > some
>> > > > >
>> > > > > > work to make it compile on our side with the patches that you
>> > > > > > merged. However, Jean's branch was against 2.1 and we really
>> > > > > > needed 2.2. The idea was to take only win32 related stuff from
>> > > > > > Jean's branch and not all the stuff here. Unfortunately, we
>> > > > > > weren't able to find which commits were related exclusively to
>> the
>> > > > > > win32 port, so we decided to go directly with 2.2.0. We applied
>> > > > > > the same patches as we did in Jean's branch, plus some others
>> for
>> > > > > > OCL. We didn't look at unit tests yet, but our applications
>> > > > >
>> > > > > are
>> > > > >
>> > > > > > so far running fine. I will send in the next one or two hours
>> the
>> > > > >
>> > > > > complete
>> > > > >
>> > > > > > set of patches against 2.2.0 for RTT and OCL. I will also try to
>> > > > > > run unit tests to see what happen. Altough our applications run
>> > > > > > fine, I can't say
>> > > > >
>> > > > > if
>> > > > >
>> > > > > > this is a _definitive_ solution until all unit tests pass.
>> > > > >
>> > > > > Hmm. I don't follow here. If you required 2.2 + Jean's patches,
>> then
>> > >
>> > > you
>> > >
>> > > > > only
>> > > > > need to do:
>> > > > >
>> > > > > Jean's master == toolchain-2.1 + some parts of 2.2 + his patches
>> > > > >
>> > > > > So to get Jean's patches on 2.2, do:
>> > > > >
>> > > > > git checkout toolchain-2.2 (latest stable)
>> > > > > git merge jsreng/master
>> > > > > + apply your own patches.
>> > > > >
>> > > > > What I did was:
>> > > > >
>> > > > > git checkout master (will become toolchain-2.3)
>> > > > > git merge jsreng/master
>> > > > > + apply your own patches.
>> > > >
>> > > > I could also do this, but I wasn't sure of the working state of
>> Jean's
>> > > > branch. I didn't had time to debug stuff unrelated to my work when
>> > >
>> > > porting
>> > >
>> > > > orocos 2.x on win32.
>> > >
>> > > When looking at another person's branch, I just fire up 'gitk
>> > > jsreng/master'
>> > > for example. It nicely shows the merges done and where it branched
>> etc.
>> > > It also has a powerful search feature.
>> > >
>> > > > I have about 5 more patches to submit for RTT and some
>> > > > others for OCL. Do you prefer that I generate them against
>> > > > https://github.com/psoetens/orocos-rtt/tree/master-with-jsreng ?
>> > >
>> > > I don't mind either way. Mostly, I use 'git am -3 patches...' which is
>> > > able to
>> > > resolve most issues and does a 3-way merge of your patch instead of
>> > > rejecting
>> > > it if it won't apply.
>> >
>> > I pushed to my github account all the patches that we've made to make
>> > RTT/OCL 2.2.0 work under windows :
>> >
>> > https://github.com/phamelin/orocos-rtt/tree/master-win32-ready
>> > https://github.com/phamelin/orocos-ocl/tree/master-win32-ready
>> >
>> > Actually, three tests in RTT are failing to link on windows. They were
>> all
>> > compiling in 2.2.0 so I guess this is minor for the moment. I will give
>> you
>> > more info about the tests results later today or maybe next week.
>>
>> Thanks for this nice work. One remark:
>>
>> You removed the RTT_CORBA_API decls from the AnyConversion<foo>
>> specialisations in RTTCorbaConversion.hpp : Is that because they are
>> inlined
>> (all header) ? Won't this affect a build when the compiler decides not to
>> inline it ?
>>
>>
> I don't see how it can happens. The problem is that they were exported
> (RTT_CORBA_API) but they weren't compiled in the shared library. Moreover,
> these decls aren't used anywhere in the rtt-corba library so there's no
> chance that the symbols were exported. When including this header file from
> an other target, the linker was unsuccessfully looking for these symbol in
> the rtt-corba shared lib since they were explicitly exported (and imported
> from the other target side). The rule is that everytime we use
> RTT_[CORBA_]API we should make sure that the corresponding symbols are
> compiled and thus succesfully exported in the shared library. In other
> words, we can export declarations only if the definitions are explicitely in
> the shared library. GCC is usually able to deal with that, but that's
> unfortunately not the case of MSVC.
>
> Also, I pushed one more commit to solve all linking errors of tests in the
> master branch:
>
>
> https://github.com/phamelin/orocos-rtt/commit/1c8425e22e4769f44ba45d029b...
>
> Today, I want to do one more QA pass on win32 (RTT and OCL) to make sure
> that no patch is missing for the next release. Also, I will try to send a
> short report on the current status of the win32 port such as unit tests
> results. At this time, most of the tests pass, but there is always 4-5 tests
> failing. Also, I don't know if the unit tests works "out of the box" since I
> always do a make install before running them.
>
>
>
My github branch is currently broken. OCL fails to configure with a lot of
these cmake errors:

CMake Error at /usr/local/lib/cmake/orocos-rtt/UseOROCOS-RTT.cmake:493
(ADD_CUSTOM_TARGET):
add_custom_target cannot create target "uninstall" because another target
with the same name already exists. The existing target is a custom target
created in source directory "/home/hamelinp/devroot/github/orocos-ocl".
See documentation for policy CMP0002 for more details.
Call Stack (most recent call first):
/usr/local/lib/cmake/orocos-rtt/UseOROCOS-RTT.cmake:601
(orocos_uninstall_target)
deployment/CMakeLists.txt:48 (orocos_generate_package)

It seems to have something to do with the new orocos_generate_package macro.
I guess my OCL is not up-to-date with RTT?

win32 branch&patches merging

Submitted by peter on Tue, 2011-02-08 14:52.

On Tuesday 08 February 2011 15:35:52 Philippe Hamelin wrote:
> 2011/2/8 Philippe Hamelin <philippe [dot] hamelin [..] ...>
>
> > 2011/2/8 Peter Soetens <peter [..] ...>
> >
> > On Friday 04 February 2011 21:03:29 Philippe Hamelin wrote:
> >> > 2011/2/4 Peter Soetens <peter [..] ...>
> >> >
> >> > > On Friday 04 February 2011 15:40:28 Philippe Hamelin wrote:
> >> > > > 2011/2/4 Peter Soetens <peter [..] ...>
> >> > > >
> >> > > > > On Friday 04 February 2011 14:38:14 Philippe Hamelin wrote:
> >> > > > > > Hi Peter,
> >> > > > > >
> >> > > > > > > I was looking in merging the outstanding win32 patches onto
> >> > > > > > > master, but some
> >> > > > > > >
> >> > > > > > > changes on Jean's branch need more review. Especially this
> >>
> >> commit:
> >> > > > > > Thank you for spending some time on the win32 port of Orocos.
> >> > > > > >
> >> > > > > > > I could also apply Philippe's patches without much trouble.
> >>
> >> Are
> >>
> >> > > they
> >> > >
> >> > > > > the
> >> > > > >
> >> > > > > > > definitive solutions for win32 ?
> >> > > > > >
> >> > > > > > My first trial with Orocos 2.x on win32 was with Jean's
> >> > > > > > branch.
> >>
> >> We
> >>
> >> > > did
> >> > >
> >> > > > > some
> >> > > > >
> >> > > > > > work to make it compile on our side with the patches that you
> >> > > > > > merged. However, Jean's branch was against 2.1 and we really
> >> > > > > > needed 2.2. The idea was to take only win32 related stuff from
> >> > > > > > Jean's branch and not all the stuff here. Unfortunately, we
> >> > > > > > weren't able to find which commits were related exclusively to
> >>
> >> the
> >>
> >> > > > > > win32 port, so we decided to go directly with 2.2.0. We
> >> > > > > > applied the same patches as we did in Jean's branch, plus
> >> > > > > > some others
> >>
> >> for
> >>
> >> > > > > > OCL. We didn't look at unit tests yet, but our applications
> >> > > > >
> >> > > > > are
> >> > > > >
> >> > > > > > so far running fine. I will send in the next one or two hours
> >>
> >> the
> >>
> >> > > > > complete
> >> > > > >
> >> > > > > > set of patches against 2.2.0 for RTT and OCL. I will also try
> >> > > > > > to run unit tests to see what happen. Altough our
> >> > > > > > applications run fine, I can't say
> >> > > > >
> >> > > > > if
> >> > > > >
> >> > > > > > this is a _definitive_ solution until all unit tests pass.
> >> > > > >
> >> > > > > Hmm. I don't follow here. If you required 2.2 + Jean's patches,
> >>
> >> then
> >>
> >> > > you
> >> > >
> >> > > > > only
> >> > > > > need to do:
> >> > > > >
> >> > > > > Jean's master == toolchain-2.1 + some parts of 2.2 + his patches
> >> > > > >
> >> > > > > So to get Jean's patches on 2.2, do:
> >> > > > >
> >> > > > > git checkout toolchain-2.2 (latest stable)
> >> > > > > git merge jsreng/master
> >> > > > > + apply your own patches.
> >> > > > >
> >> > > > > What I did was:
> >> > > > >
> >> > > > > git checkout master (will become toolchain-2.3)
> >> > > > > git merge jsreng/master
> >> > > > > + apply your own patches.
> >> > > >
> >> > > > I could also do this, but I wasn't sure of the working state of
> >>
> >> Jean's
> >>
> >> > > > branch. I didn't had time to debug stuff unrelated to my work when
> >> > >
> >> > > porting
> >> > >
> >> > > > orocos 2.x on win32.
> >> > >
> >> > > When looking at another person's branch, I just fire up 'gitk
> >> > > jsreng/master'
> >> > > for example. It nicely shows the merges done and where it branched
> >>
> >> etc.
> >>
> >> > > It also has a powerful search feature.
> >> > >
> >> > > > I have about 5 more patches to submit for RTT and some
> >> > > > others for OCL. Do you prefer that I generate them against
> >> > > > https://github.com/psoetens/orocos-rtt/tree/master-with-jsreng ?
> >> > >
> >> > > I don't mind either way. Mostly, I use 'git am -3 patches...' which
> >> > > is able to
> >> > > resolve most issues and does a 3-way merge of your patch instead of
> >> > > rejecting
> >> > > it if it won't apply.
> >> >
> >> > I pushed to my github account all the patches that we've made to make
> >> > RTT/OCL 2.2.0 work under windows :
> >> >
> >> > https://github.com/phamelin/orocos-rtt/tree/master-win32-ready
> >> > https://github.com/phamelin/orocos-ocl/tree/master-win32-ready
> >> >
> >> > Actually, three tests in RTT are failing to link on windows. They were
> >>
> >> all
> >>
> >> > compiling in 2.2.0 so I guess this is minor for the moment. I will
> >> > give
> >>
> >> you
> >>
> >> > more info about the tests results later today or maybe next week.
> >>
> >> Thanks for this nice work. One remark:
> >>
> >> You removed the RTT_CORBA_API decls from the AnyConversion<foo>
> >> specialisations in RTTCorbaConversion.hpp : Is that because they are
> >> inlined
> >> (all header) ? Won't this affect a build when the compiler decides not
> >> to inline it ?
> >
> > I don't see how it can happens. The problem is that they were exported
> > (RTT_CORBA_API) but they weren't compiled in the shared library.
> > Moreover, these decls aren't used anywhere in the rtt-corba library so
> > there's no chance that the symbols were exported. When including this
> > header file from an other target, the linker was unsuccessfully looking
> > for these symbol in the rtt-corba shared lib since they were explicitly
> > exported (and imported from the other target side). The rule is that
> > everytime we use
> > RTT_[CORBA_]API we should make sure that the corresponding symbols are
> > compiled and thus succesfully exported in the shared library. In other
> > words, we can export declarations only if the definitions are explicitely
> > in the shared library. GCC is usually able to deal with that, but that's
> > unfortunately not the case of MSVC.
> >
> > Also, I pushed one more commit to solve all linking errors of tests in
> > the master branch:
> >
> >
> > https://github.com/phamelin/orocos-rtt/commit/1c8425e22e4769f44ba45d029b2
> > 03654fb7f5f34
> >
> > Today, I want to do one more QA pass on win32 (RTT and OCL) to make sure
> > that no patch is missing for the next release. Also, I will try to send a
> > short report on the current status of the win32 port such as unit tests
> > results. At this time, most of the tests pass, but there is always 4-5
> > tests failing. Also, I don't know if the unit tests works "out of the
> > box" since I always do a make install before running them.
>
> My github branch is currently broken. OCL fails to configure with a lot of
> these cmake errors:
>
> CMake Error at /usr/local/lib/cmake/orocos-rtt/UseOROCOS-RTT.cmake:493
> (ADD_CUSTOM_TARGET):
> add_custom_target cannot create target "uninstall" because another target
> with the same name already exists. The existing target is a custom
> target created in source directory
> "/home/hamelinp/devroot/github/orocos-ocl". See documentation for policy
> CMP0002 for more details.
> Call Stack (most recent call first):
> /usr/local/lib/cmake/orocos-rtt/UseOROCOS-RTT.cmake:601
> (orocos_uninstall_target)
> deployment/CMakeLists.txt:48 (orocos_generate_package)
>
> It seems to have something to do with the new orocos_generate_package
> macro. I guess my OCL is not up-to-date with RTT?

Hmm it looks like the other way around: it's using an older version of RTT's
UseOrocos-RTT.cmake macro. Can you check that your UseOrocos-RTT.cmake file has
on line 487: if (NOT OROCOS_UNINSTALL_DONE AND NOT TARGET uninstall) ?

That's the check that should prevent this error.

Peter

win32 branch&patches merging

Submitted by phamelin on Tue, 2011-02-08 14:52.

2011/2/8 Peter Soetens <peter [..] ...>

> On Tuesday 08 February 2011 15:35:52 Philippe Hamelin wrote:
> > 2011/2/8 Philippe Hamelin <philippe [dot] hamelin [..] ...>
> >
> > > 2011/2/8 Peter Soetens <peter [..] ...>
> > >
> > > On Friday 04 February 2011 21:03:29 Philippe Hamelin wrote:
> > >> > 2011/2/4 Peter Soetens <peter [..] ...>
> > >> >
> > >> > > On Friday 04 February 2011 15:40:28 Philippe Hamelin wrote:
> > >> > > > 2011/2/4 Peter Soetens <peter [..] ...>
> > >> > > >
> > >> > > > > On Friday 04 February 2011 14:38:14 Philippe Hamelin wrote:
> > >> > > > > > Hi Peter,
> > >> > > > > >
> > >> > > > > > > I was looking in merging the outstanding win32 patches
> onto
> > >> > > > > > > master, but some
> > >> > > > > > >
> > >> > > > > > > changes on Jean's branch need more review. Especially this
> > >>
> > >> commit:
> > >> > > > > > Thank you for spending some time on the win32 port of
> Orocos.
> > >> > > > > >
> > >> > > > > > > I could also apply Philippe's patches without much
> trouble.
> > >>
> > >> Are
> > >>
> > >> > > they
> > >> > >
> > >> > > > > the
> > >> > > > >
> > >> > > > > > > definitive solutions for win32 ?
> > >> > > > > >
> > >> > > > > > My first trial with Orocos 2.x on win32 was with Jean's
> > >> > > > > > branch.
> > >>
> > >> We
> > >>
> > >> > > did
> > >> > >
> > >> > > > > some
> > >> > > > >
> > >> > > > > > work to make it compile on our side with the patches that
> you
> > >> > > > > > merged. However, Jean's branch was against 2.1 and we really
> > >> > > > > > needed 2.2. The idea was to take only win32 related stuff
> from
> > >> > > > > > Jean's branch and not all the stuff here. Unfortunately, we
> > >> > > > > > weren't able to find which commits were related exclusively
> to
> > >>
> > >> the
> > >>
> > >> > > > > > win32 port, so we decided to go directly with 2.2.0. We
> > >> > > > > > applied the same patches as we did in Jean's branch, plus
> > >> > > > > > some others
> > >>
> > >> for
> > >>
> > >> > > > > > OCL. We didn't look at unit tests yet, but our applications
> > >> > > > >
> > >> > > > > are
> > >> > > > >
> > >> > > > > > so far running fine. I will send in the next one or two
> hours
> > >>
> > >> the
> > >>
> > >> > > > > complete
> > >> > > > >
> > >> > > > > > set of patches against 2.2.0 for RTT and OCL. I will also
> try
> > >> > > > > > to run unit tests to see what happen. Altough our
> > >> > > > > > applications run fine, I can't say
> > >> > > > >
> > >> > > > > if
> > >> > > > >
> > >> > > > > > this is a _definitive_ solution until all unit tests pass.
> > >> > > > >
> > >> > > > > Hmm. I don't follow here. If you required 2.2 + Jean's
> patches,
> > >>
> > >> then
> > >>
> > >> > > you
> > >> > >
> > >> > > > > only
> > >> > > > > need to do:
> > >> > > > >
> > >> > > > > Jean's master == toolchain-2.1 + some parts of 2.2 + his
> patches
> > >> > > > >
> > >> > > > > So to get Jean's patches on 2.2, do:
> > >> > > > >
> > >> > > > > git checkout toolchain-2.2 (latest stable)
> > >> > > > > git merge jsreng/master
> > >> > > > > + apply your own patches.
> > >> > > > >
> > >> > > > > What I did was:
> > >> > > > >
> > >> > > > > git checkout master (will become toolchain-2.3)
> > >> > > > > git merge jsreng/master
> > >> > > > > + apply your own patches.
> > >> > > >
> > >> > > > I could also do this, but I wasn't sure of the working state of
> > >>
> > >> Jean's
> > >>
> > >> > > > branch. I didn't had time to debug stuff unrelated to my work
> when
> > >> > >
> > >> > > porting
> > >> > >
> > >> > > > orocos 2.x on win32.
> > >> > >
> > >> > > When looking at another person's branch, I just fire up 'gitk
> > >> > > jsreng/master'
> > >> > > for example. It nicely shows the merges done and where it branched
> > >>
> > >> etc.
> > >>
> > >> > > It also has a powerful search feature.
> > >> > >
> > >> > > > I have about 5 more patches to submit for RTT and some
> > >> > > > others for OCL. Do you prefer that I generate them against
> > >> > > > https://github.com/psoetens/orocos-rtt/tree/master-with-jsreng?
> > >> > >
> > >> > > I don't mind either way. Mostly, I use 'git am -3 patches...'
> which
> > >> > > is able to
> > >> > > resolve most issues and does a 3-way merge of your patch instead
> of
> > >> > > rejecting
> > >> > > it if it won't apply.
> > >> >
> > >> > I pushed to my github account all the patches that we've made to
> make
> > >> > RTT/OCL 2.2.0 work under windows :
> > >> >
> > >> > https://github.com/phamelin/orocos-rtt/tree/master-win32-ready
> > >> > https://github.com/phamelin/orocos-ocl/tree/master-win32-ready
> > >> >
> > >> > Actually, three tests in RTT are failing to link on windows. They
> were
> > >>
> > >> all
> > >>
> > >> > compiling in 2.2.0 so I guess this is minor for the moment. I will
> > >> > give
> > >>
> > >> you
> > >>
> > >> > more info about the tests results later today or maybe next week.
> > >>
> > >> Thanks for this nice work. One remark:
> > >>
> > >> You removed the RTT_CORBA_API decls from the AnyConversion<foo>
> > >> specialisations in RTTCorbaConversion.hpp : Is that because they are
> > >> inlined
> > >> (all header) ? Won't this affect a build when the compiler decides not
> > >> to inline it ?
> > >
> > > I don't see how it can happens. The problem is that they were exported
> > > (RTT_CORBA_API) but they weren't compiled in the shared library.
> > > Moreover, these decls aren't used anywhere in the rtt-corba library so
> > > there's no chance that the symbols were exported. When including this
> > > header file from an other target, the linker was unsuccessfully looking
> > > for these symbol in the rtt-corba shared lib since they were explicitly
> > > exported (and imported from the other target side). The rule is that
> > > everytime we use
> > > RTT_[CORBA_]API we should make sure that the corresponding symbols are
> > > compiled and thus succesfully exported in the shared library. In other
> > > words, we can export declarations only if the definitions are
> explicitely
> > > in the shared library. GCC is usually able to deal with that, but
> that's
> > > unfortunately not the case of MSVC.
> > >
> > > Also, I pushed one more commit to solve all linking errors of tests in
> > > the master branch:
> > >
> > >
> > >
> https://github.com/phamelin/orocos-rtt/commit/1c8425e22e4769f44ba45d029b2
> > > 03654fb7f5f34
> > >
> > > Today, I want to do one more QA pass on win32 (RTT and OCL) to make
> sure
> > > that no patch is missing for the next release. Also, I will try to send
> a
> > > short report on the current status of the win32 port such as unit tests
> > > results. At this time, most of the tests pass, but there is always 4-5
> > > tests failing. Also, I don't know if the unit tests works "out of the
> > > box" since I always do a make install before running them.
> >
> > My github branch is currently broken. OCL fails to configure with a lot
> of
> > these cmake errors:
> >
> > CMake Error at /usr/local/lib/cmake/orocos-rtt/UseOROCOS-RTT.cmake:493
> > (ADD_CUSTOM_TARGET):
> > add_custom_target cannot create target "uninstall" because another
> target
> > with the same name already exists. The existing target is a custom
> > target created in source directory
> > "/home/hamelinp/devroot/github/orocos-ocl". See documentation for policy
> > CMP0002 for more details.
> > Call Stack (most recent call first):
> > /usr/local/lib/cmake/orocos-rtt/UseOROCOS-RTT.cmake:601
> > (orocos_uninstall_target)
> > deployment/CMakeLists.txt:48 (orocos_generate_package)
> >
> > It seems to have something to do with the new orocos_generate_package
> > macro. I guess my OCL is not up-to-date with RTT?
>
> Hmm it looks like the other way around: it's using an older version of
> RTT's
> UseOrocos-RTT.cmake macro. Can you check that your UseOrocos-RTT.cmake file
> has
> on line 487: if (NOT OROCOS_UNINSTALL_DONE AND NOT TARGET uninstall) ?
>
> That's the check that should prevent this error.
>
>
Ok I will update my branch because I rather have: if (NOT
OROCOS_UNINSTALL_DONE).

win32 branch&patches merging

Submitted by phamelin on Tue, 2011-02-08 16:16.

2011/2/8 Philippe Hamelin <philippe [dot] hamelin [..] ...>

> 2011/2/8 Peter Soetens <peter [..] ...>
>
>> On Tuesday 08 February 2011 15:35:52 Philippe Hamelin wrote:
>> > 2011/2/8 Philippe Hamelin <philippe [dot] hamelin [..] ...>
>> >
>> > > 2011/2/8 Peter Soetens <peter [..] ...>
>> > >
>> > > On Friday 04 February 2011 21:03:29 Philippe Hamelin wrote:
>> > >> > 2011/2/4 Peter Soetens <peter [..] ...>
>> > >> >
>> > >> > > On Friday 04 February 2011 15:40:28 Philippe Hamelin wrote:
>> > >> > > > 2011/2/4 Peter Soetens <peter [..] ...>
>> > >> > > >
>> > >> > > > > On Friday 04 February 2011 14:38:14 Philippe Hamelin wrote:
>> > >> > > > > > Hi Peter,
>> > >> > > > > >
>> > >> > > > > > > I was looking in merging the outstanding win32 patches
>> onto
>> > >> > > > > > > master, but some
>> > >> > > > > > >
>> > >> > > > > > > changes on Jean's branch need more review. Especially
>> this
>> > >>
>> > >> commit:
>> > >> > > > > > Thank you for spending some time on the win32 port of
>> Orocos.
>> > >> > > > > >
>> > >> > > > > > > I could also apply Philippe's patches without much
>> trouble.
>> > >>
>> > >> Are
>> > >>
>> > >> > > they
>> > >> > >
>> > >> > > > > the
>> > >> > > > >
>> > >> > > > > > > definitive solutions for win32 ?
>> > >> > > > > >
>> > >> > > > > > My first trial with Orocos 2.x on win32 was with Jean's
>> > >> > > > > > branch.
>> > >>
>> > >> We
>> > >>
>> > >> > > did
>> > >> > >
>> > >> > > > > some
>> > >> > > > >
>> > >> > > > > > work to make it compile on our side with the patches that
>> you
>> > >> > > > > > merged. However, Jean's branch was against 2.1 and we
>> really
>> > >> > > > > > needed 2.2. The idea was to take only win32 related stuff
>> from
>> > >> > > > > > Jean's branch and not all the stuff here. Unfortunately, we
>> > >> > > > > > weren't able to find which commits were related exclusively
>> to
>> > >>
>> > >> the
>> > >>
>> > >> > > > > > win32 port, so we decided to go directly with 2.2.0. We
>> > >> > > > > > applied the same patches as we did in Jean's branch, plus
>> > >> > > > > > some others
>> > >>
>> > >> for
>> > >>
>> > >> > > > > > OCL. We didn't look at unit tests yet, but our applications
>> > >> > > > >
>> > >> > > > > are
>> > >> > > > >
>> > >> > > > > > so far running fine. I will send in the next one or two
>> hours
>> > >>
>> > >> the
>> > >>
>> > >> > > > > complete
>> > >> > > > >
>> > >> > > > > > set of patches against 2.2.0 for RTT and OCL. I will also
>> try
>> > >> > > > > > to run unit tests to see what happen. Altough our
>> > >> > > > > > applications run fine, I can't say
>> > >> > > > >
>> > >> > > > > if
>> > >> > > > >
>> > >> > > > > > this is a _definitive_ solution until all unit tests pass.
>> > >> > > > >
>> > >> > > > > Hmm. I don't follow here. If you required 2.2 + Jean's
>> patches,
>> > >>
>> > >> then
>> > >>
>> > >> > > you
>> > >> > >
>> > >> > > > > only
>> > >> > > > > need to do:
>> > >> > > > >
>> > >> > > > > Jean's master == toolchain-2.1 + some parts of 2.2 + his
>> patches
>> > >> > > > >
>> > >> > > > > So to get Jean's patches on 2.2, do:
>> > >> > > > >
>> > >> > > > > git checkout toolchain-2.2 (latest stable)
>> > >> > > > > git merge jsreng/master
>> > >> > > > > + apply your own patches.
>> > >> > > > >
>> > >> > > > > What I did was:
>> > >> > > > >
>> > >> > > > > git checkout master (will become toolchain-2.3)
>> > >> > > > > git merge jsreng/master
>> > >> > > > > + apply your own patches.
>> > >> > > >
>> > >> > > > I could also do this, but I wasn't sure of the working state of
>> > >>
>> > >> Jean's
>> > >>
>> > >> > > > branch. I didn't had time to debug stuff unrelated to my work
>> when
>> > >> > >
>> > >> > > porting
>> > >> > >
>> > >> > > > orocos 2.x on win32.
>> > >> > >
>> > >> > > When looking at another person's branch, I just fire up 'gitk
>> > >> > > jsreng/master'
>> > >> > > for example. It nicely shows the merges done and where it
>> branched
>> > >>
>> > >> etc.
>> > >>
>> > >> > > It also has a powerful search feature.
>> > >> > >
>> > >> > > > I have about 5 more patches to submit for RTT and some
>> > >> > > > others for OCL. Do you prefer that I generate them against
>> > >> > > > https://github.com/psoetens/orocos-rtt/tree/master-with-jsreng?
>> > >> > >
>> > >> > > I don't mind either way. Mostly, I use 'git am -3 patches...'
>> which
>> > >> > > is able to
>> > >> > > resolve most issues and does a 3-way merge of your patch instead
>> of
>> > >> > > rejecting
>> > >> > > it if it won't apply.
>> > >> >
>> > >> > I pushed to my github account all the patches that we've made to
>> make
>> > >> > RTT/OCL 2.2.0 work under windows :
>> > >> >
>> > >> > https://github.com/phamelin/orocos-rtt/tree/master-win32-ready
>> > >> > https://github.com/phamelin/orocos-ocl/tree/master-win32-ready
>> > >> >
>> > >> > Actually, three tests in RTT are failing to link on windows. They
>> were
>> > >>
>> > >> all
>> > >>
>> > >> > compiling in 2.2.0 so I guess this is minor for the moment. I will
>> > >> > give
>> > >>
>> > >> you
>> > >>
>> > >> > more info about the tests results later today or maybe next week.
>> > >>
>> > >> Thanks for this nice work. One remark:
>> > >>
>> > >> You removed the RTT_CORBA_API decls from the AnyConversion<foo>
>> > >> specialisations in RTTCorbaConversion.hpp : Is that because they are
>> > >> inlined
>> > >> (all header) ? Won't this affect a build when the compiler decides
>> not
>> > >> to inline it ?
>> > >
>> > > I don't see how it can happens. The problem is that they were exported
>> > > (RTT_CORBA_API) but they weren't compiled in the shared library.
>> > > Moreover, these decls aren't used anywhere in the rtt-corba library so
>> > > there's no chance that the symbols were exported. When including this
>> > > header file from an other target, the linker was unsuccessfully
>> looking
>> > > for these symbol in the rtt-corba shared lib since they were
>> explicitly
>> > > exported (and imported from the other target side). The rule is that
>> > > everytime we use
>> > > RTT_[CORBA_]API we should make sure that the corresponding symbols are
>> > > compiled and thus succesfully exported in the shared library. In other
>> > > words, we can export declarations only if the definitions are
>> explicitely
>> > > in the shared library. GCC is usually able to deal with that, but
>> that's
>> > > unfortunately not the case of MSVC.
>> > >
>> > > Also, I pushed one more commit to solve all linking errors of tests in
>> > > the master branch:
>> > >
>> > >
>> > >
>> https://github.com/phamelin/orocos-rtt/commit/1c8425e22e4769f44ba45d029b2
>> > > 03654fb7f5f34
>> > >
>> > > Today, I want to do one more QA pass on win32 (RTT and OCL) to make
>> sure
>> > > that no patch is missing for the next release. Also, I will try to
>> send a
>> > > short report on the current status of the win32 port such as unit
>> tests
>> > > results. At this time, most of the tests pass, but there is always 4-5
>> > > tests failing. Also, I don't know if the unit tests works "out of the
>> > > box" since I always do a make install before running them.
>> >
>> > My github branch is currently broken. OCL fails to configure with a lot
>> of
>> > these cmake errors:
>> >
>> > CMake Error at /usr/local/lib/cmake/orocos-rtt/UseOROCOS-RTT.cmake:493
>> > (ADD_CUSTOM_TARGET):
>> > add_custom_target cannot create target "uninstall" because another
>> target
>> > with the same name already exists. The existing target is a custom
>> > target created in source directory
>> > "/home/hamelinp/devroot/github/orocos-ocl". See documentation for policy
>> > CMP0002 for more details.
>> > Call Stack (most recent call first):
>> > /usr/local/lib/cmake/orocos-rtt/UseOROCOS-RTT.cmake:601
>> > (orocos_uninstall_target)
>> > deployment/CMakeLists.txt:48 (orocos_generate_package)
>> >
>> > It seems to have something to do with the new orocos_generate_package
>> > macro. I guess my OCL is not up-to-date with RTT?
>>
>> Hmm it looks like the other way around: it's using an older version of
>> RTT's
>> UseOrocos-RTT.cmake macro. Can you check that your UseOrocos-RTT.cmake
>> file has
>> on line 487: if (NOT OROCOS_UNINSTALL_DONE AND NOT TARGET uninstall) ?
>>
>> That's the check that should prevent this error.
>>
>>
> Ok I will update my branch because I rather have: if (NOT
> OROCOS_UNINSTALL_DONE).
>
>
Ok I updated my branches and did some tests. Actually, OCL doesn't compile:

bin/ctaskbrowser.cpp:42 ORO_xstr isn't defined.

I don't know how it could be found since it's defined
in bin/deployer-funcs.cpp. Do you mind if I let you fix that?

Philippe

win32 branch&patches merging

Submitted by peter on Wed, 2011-02-09 08:48.

On Tuesday 08 February 2011 17:13:15 Philippe Hamelin wrote:
> 2011/2/8 Philippe Hamelin <philippe [dot] hamelin [..] ...>
>
> > 2011/2/8 Peter Soetens <peter [..] ...>
> >
> >> On Tuesday 08 February 2011 15:35:52 Philippe Hamelin wrote:
> >> > 2011/2/8 Philippe Hamelin <philippe [dot] hamelin [..] ...>
> >> >
> >> > > 2011/2/8 Peter Soetens <peter [..] ...>
> >> > >
> >> > > On Friday 04 February 2011 21:03:29 Philippe Hamelin wrote:
> >> > >> > 2011/2/4 Peter Soetens <peter [..] ...>
> >> > >> >
> >> > >> > > On Friday 04 February 2011 15:40:28 Philippe Hamelin wrote:
> >> > >> > > > 2011/2/4 Peter Soetens <peter [..] ...>
> >> > >> > > >
> >> > >> > > > > On Friday 04 February 2011 14:38:14 Philippe Hamelin wrote:
> >> > >> > > > > > Hi Peter,
> >> > >> > > > > >
> >> > >> > > > > > > I was looking in merging the outstanding win32 patches
> >>
> >> onto
> >>
> >> > >> > > > > > > master, but some
> >> > >> > > > > > >
> >> > >> > > > > > > changes on Jean's branch need more review. Especially
> >>
> >> this
> >>
> >> > >> commit:
> >> > >> > > > > > Thank you for spending some time on the win32 port of
> >>
> >> Orocos.
> >>
> >> > >> > > > > > > I could also apply Philippe's patches without much
> >>
> >> trouble.
> >>
> >> > >> Are
> >> > >>
> >> > >> > > they
> >> > >> > >
> >> > >> > > > > the
> >> > >> > > > >
> >> > >> > > > > > > definitive solutions for win32 ?
> >> > >> > > > > >
> >> > >> > > > > > My first trial with Orocos 2.x on win32 was with Jean's
> >> > >> > > > > > branch.
> >> > >>
> >> > >> We
> >> > >>
> >> > >> > > did
> >> > >> > >
> >> > >> > > > > some
> >> > >> > > > >
> >> > >> > > > > > work to make it compile on our side with the patches that
> >>
> >> you
> >>
> >> > >> > > > > > merged. However, Jean's branch was against 2.1 and we
> >>
> >> really
> >>
> >> > >> > > > > > needed 2.2. The idea was to take only win32 related stuff
> >>
> >> from
> >>
> >> > >> > > > > > Jean's branch and not all the stuff here. Unfortunately,
> >> > >> > > > > > we weren't able to find which commits were related
> >> > >> > > > > > exclusively
> >>
> >> to
> >>
> >> > >> the
> >> > >>
> >> > >> > > > > > win32 port, so we decided to go directly with 2.2.0. We
> >> > >> > > > > > applied the same patches as we did in Jean's branch, plus
> >> > >> > > > > > some others
> >> > >>
> >> > >> for
> >> > >>
> >> > >> > > > > > OCL. We didn't look at unit tests yet, but our
> >> > >> > > > > > applications
> >> > >> > > > >
> >> > >> > > > > are
> >> > >> > > > >
> >> > >> > > > > > so far running fine. I will send in the next one or two
> >>
> >> hours
> >>
> >> > >> the
> >> > >>
> >> > >> > > > > complete
> >> > >> > > > >
> >> > >> > > > > > set of patches against 2.2.0 for RTT and OCL. I will also
> >>
> >> try
> >>
> >> > >> > > > > > to run unit tests to see what happen. Altough our
> >> > >> > > > > > applications run fine, I can't say
> >> > >> > > > >
> >> > >> > > > > if
> >> > >> > > > >
> >> > >> > > > > > this is a _definitive_ solution until all unit tests
> >> > >> > > > > > pass.
> >> > >> > > > >
> >> > >> > > > > Hmm. I don't follow here. If you required 2.2 + Jean's
> >>
> >> patches,
> >>
> >> > >> then
> >> > >>
> >> > >> > > you
> >> > >> > >
> >> > >> > > > > only
> >> > >> > > > > need to do:
> >> > >> > > > >
> >> > >> > > > > Jean's master == toolchain-2.1 + some parts of 2.2 + his
> >>
> >> patches
> >>
> >> > >> > > > > So to get Jean's patches on 2.2, do:
> >> > >> > > > >
> >> > >> > > > > git checkout toolchain-2.2 (latest stable)
> >> > >> > > > > git merge jsreng/master
> >> > >> > > > > + apply your own patches.
> >> > >> > > > >
> >> > >> > > > > What I did was:
> >> > >> > > > >
> >> > >> > > > > git checkout master (will become toolchain-2.3)
> >> > >> > > > > git merge jsreng/master
> >> > >> > > > > + apply your own patches.
> >> > >> > > >
> >> > >> > > > I could also do this, but I wasn't sure of the working state
> >> > >> > > > of
> >> > >>
> >> > >> Jean's
> >> > >>
> >> > >> > > > branch. I didn't had time to debug stuff unrelated to my work
> >>
> >> when
> >>
> >> > >> > > porting
> >> > >> > >
> >> > >> > > > orocos 2.x on win32.
> >> > >> > >
> >> > >> > > When looking at another person's branch, I just fire up 'gitk
> >> > >> > > jsreng/master'
> >> > >> > > for example. It nicely shows the merges done and where it
> >>
> >> branched
> >>
> >> > >> etc.
> >> > >>
> >> > >> > > It also has a powerful search feature.
> >> > >> > >
> >> > >> > > > I have about 5 more patches to submit for RTT and some
> >> > >> > > > others for OCL. Do you prefer that I generate them against
> >> > >> > > > https://github.com/psoetens/orocos-rtt/tree/master-with-jsren
> >> > >> > > > g?
> >> > >> > >
> >> > >> > > I don't mind either way. Mostly, I use 'git am -3 patches...'
> >>
> >> which
> >>
> >> > >> > > is able to
> >> > >> > > resolve most issues and does a 3-way merge of your patch
> >> > >> > > instead
> >>
> >> of
> >>
> >> > >> > > rejecting
> >> > >> > > it if it won't apply.
> >> > >> >
> >> > >> > I pushed to my github account all the patches that we've made to
> >>
> >> make
> >>
> >> > >> > RTT/OCL 2.2.0 work under windows :
> >> > >> >
> >> > >> > https://github.com/phamelin/orocos-rtt/tree/master-win32-ready
> >> > >> > https://github.com/phamelin/orocos-ocl/tree/master-win32-ready
> >> > >> >
> >> > >> > Actually, three tests in RTT are failing to link on windows. They
> >>
> >> were
> >>
> >> > >> all
> >> > >>
> >> > >> > compiling in 2.2.0 so I guess this is minor for the moment. I
> >> > >> > will give
> >> > >>
> >> > >> you
> >> > >>
> >> > >> > more info about the tests results later today or maybe next week.
> >> > >>
> >> > >> Thanks for this nice work. One remark:
> >> > >>
> >> > >> You removed the RTT_CORBA_API decls from the AnyConversion<foo>
> >> > >> specialisations in RTTCorbaConversion.hpp : Is that because they
> >> > >> are inlined
> >> > >> (all header) ? Won't this affect a build when the compiler decides
> >>
> >> not
> >>
> >> > >> to inline it ?
> >> > >
> >> > > I don't see how it can happens. The problem is that they were
> >> > > exported (RTT_CORBA_API) but they weren't compiled in the shared
> >> > > library. Moreover, these decls aren't used anywhere in the
> >> > > rtt-corba library so there's no chance that the symbols were
> >> > > exported. When including this header file from an other target, the
> >> > > linker was unsuccessfully
> >>
> >> looking
> >>
> >> > > for these symbol in the rtt-corba shared lib since they were
> >>
> >> explicitly
> >>
> >> > > exported (and imported from the other target side). The rule is that
> >> > > everytime we use
> >> > > RTT_[CORBA_]API we should make sure that the corresponding symbols
> >> > > are compiled and thus succesfully exported in the shared library.
> >> > > In other words, we can export declarations only if the definitions
> >> > > are
> >>
> >> explicitely
> >>
> >> > > in the shared library. GCC is usually able to deal with that, but
> >>
> >> that's
> >>
> >> > > unfortunately not the case of MSVC.
> >> > >
> >> > > Also, I pushed one more commit to solve all linking errors of tests
> >> > > in
> >>
> >> > > the master branch:
> >> https://github.com/phamelin/orocos-rtt/commit/1c8425e22e4769f44ba45d029b
> >> 2
> >>
> >> > > 03654fb7f5f34
> >> > >
> >> > > Today, I want to do one more QA pass on win32 (RTT and OCL) to make
> >>
> >> sure
> >>
> >> > > that no patch is missing for the next release. Also, I will try to
> >>
> >> send a
> >>
> >> > > short report on the current status of the win32 port such as unit
> >>
> >> tests
> >>
> >> > > results. At this time, most of the tests pass, but there is always
> >> > > 4-5 tests failing. Also, I don't know if the unit tests works "out
> >> > > of the box" since I always do a make install before running them.
> >> >
> >> > My github branch is currently broken. OCL fails to configure with a
> >> > lot
> >>
> >> of
> >>
> >> > these cmake errors:
> >> >
> >> > CMake Error at /usr/local/lib/cmake/orocos-rtt/UseOROCOS-RTT.cmake:493
> >> >
> >> > (ADD_CUSTOM_TARGET):
> >> > add_custom_target cannot create target "uninstall" because another
> >>
> >> target
> >>
> >> > with the same name already exists. The existing target is a custom
> >> >
> >> > target created in source directory
> >> > "/home/hamelinp/devroot/github/orocos-ocl". See documentation for
> >> > policy CMP0002 for more details.
> >> >
> >> > Call Stack (most recent call first):
> >> > /usr/local/lib/cmake/orocos-rtt/UseOROCOS-RTT.cmake:601
> >> >
> >> > (orocos_uninstall_target)
> >> >
> >> > deployment/CMakeLists.txt:48 (orocos_generate_package)
> >> >
> >> > It seems to have something to do with the new orocos_generate_package
> >> > macro. I guess my OCL is not up-to-date with RTT?
> >>
> >> Hmm it looks like the other way around: it's using an older version of
> >> RTT's
> >> UseOrocos-RTT.cmake macro. Can you check that your UseOrocos-RTT.cmake
> >> file has
> >> on line 487: if (NOT OROCOS_UNINSTALL_DONE AND NOT TARGET uninstall) ?
> >>
> >> That's the check that should prevent this error.
> >
> > Ok I will update my branch because I rather have: if (NOT
> > OROCOS_UNINSTALL_DONE).
>
> Ok I updated my branches and did some tests. Actually, OCL doesn't compile:
>
> bin/ctaskbrowser.cpp:42 ORO_xstr isn't defined.
>
> I don't know how it could be found since it's defined
> in bin/deployer-funcs.cpp. Do you mind if I let you fix that?

Oops.. pushed the fix.

Peter

win32 branch&patches merging

Submitted by phamelin on Fri, 2011-02-04 15:00.

2011/2/4 Peter Soetens <peter [..] ...>

> On Friday 04 February 2011 15:40:28 Philippe Hamelin wrote:
> > 2011/2/4 Peter Soetens <peter [..] ...>
> >
> > > On Friday 04 February 2011 14:38:14 Philippe Hamelin wrote:
> > > > Hi Peter,
> > > >
> > > > > I was looking in merging the outstanding win32 patches onto master,
> > > > > but some
> > > >
> > > > > changes on Jean's branch need more review. Especially this commit:
> > > > Thank you for spending some time on the win32 port of Orocos.
> > > >
> > > > > I could also apply Philippe's patches without much trouble. Are
> they
> > >
> > > the
> > >
> > > > > definitive solutions for win32 ?
> > > >
> > > > My first trial with Orocos 2.x on win32 was with Jean's branch. We
> did
> > >
> > > some
> > >
> > > > work to make it compile on our side with the patches that you merged.
> > > > However, Jean's branch was against 2.1 and we really needed 2.2. The
> > > > idea was to take only win32 related stuff from Jean's branch and not
> > > > all the stuff here. Unfortunately, we weren't able to find which
> > > > commits were related exclusively to the win32 port, so we decided to
> > > > go directly with 2.2.0. We applied the same patches as we did in
> > > > Jean's branch, plus some others for OCL. We didn't look at unit tests
> > > > yet, but our applications
> > >
> > > are
> > >
> > > > so far running fine. I will send in the next one or two hours the
> > >
> > > complete
> > >
> > > > set of patches against 2.2.0 for RTT and OCL. I will also try to run
> > > > unit tests to see what happen. Altough our applications run fine, I
> > > > can't say
> > >
> > > if
> > >
> > > > this is a _definitive_ solution until all unit tests pass.
> > >
> > > Hmm. I don't follow here. If you required 2.2 + Jean's patches, then
> you
> > > only
> > > need to do:
> > >
> > > Jean's master == toolchain-2.1 + some parts of 2.2 + his patches
> > >
> > > So to get Jean's patches on 2.2, do:
> > >
> > > git checkout toolchain-2.2 (latest stable)
> > > git merge jsreng/master
> > > + apply your own patches.
> > >
> > > What I did was:
> > >
> > > git checkout master (will become toolchain-2.3)
> > > git merge jsreng/master
> > > + apply your own patches.
> >
> > I could also do this, but I wasn't sure of the working state of Jean's
> > branch. I didn't had time to debug stuff unrelated to my work when
> porting
> > orocos 2.x on win32.
>
> When looking at another person's branch, I just fire up 'gitk
> jsreng/master'
> for example. It nicely shows the merges done and where it branched etc. It
> also has a powerful search feature.
>
>
GIT seems to be very powerful. I don't have so much time to spent on it
because we use subversion. I'm sorry if I'm giving you more troubles to
merge my patches.

> > I have about 5 more patches to submit for RTT and some
> > others for OCL. Do you prefer that I generate them against
> > https://github.com/psoetens/orocos-rtt/tree/master-with-jsreng ?
>
> I don't mind either way. Mostly, I use 'git am -3 patches...' which is able
> to
> resolve most issues and does a 3-way merge of your patch instead of
> rejecting
> it if it won't apply.
>
>
Gitorious doesn't allow http push (can't do SSH outside here...) so I will
create a github account, clone the orocos-rtt and commit patches against
master.

Philippe

win32 branch&patches merging

Submitted by jean.sreng on Fri, 2011-02-04 13:28.

Hi Peter,

On 04/02/2011 12:50, Peter Soetens wrote:
> I was looking in merging the outstanding win32 patches onto master, but some
> changes on Jean's branch need more review. Especially this commit:

I thank you for your efforts to try to merge the win32 patches onto
master. I was going to do that but unfortunately didn't have much time
to spend on that lately.

> http://gitorious.org/orocos-toolchain/jsrengs-
> rtt/commit/506a183a9a3c0e6c3a9220e6333812c1a04bc0c5
>
> It quite heavily violates the coding style and rewrites a lot of whitespace on
> lines that could have left untouched.

I agree, I should have filtered these unecessary changes. My bad.

> Next from the technical side: is this purely an add-on ? Ie, is any existing
> behaviour changed in the CORBA transport ?

There is no changes in the serialization of base types (non STL types).
This patches add "generic" serialization for STL types (for instance,
the previous specific implementation of the serialization of
std::vector<double> has been replaced with the new generic one).

> It also contains a hard-coded reference to TAO:
>
>

> static bool
> toCorbaType(TAO::details::string_sequence_element<TAO::details::string_traits<char,
> dummy>  >&  dest, const StdType&  src) {
>

This should not be necessary. After reviewing the code, I think this can
be replaced with (not tested)

static bool toCorbaType(sequence::element_type& dest, const StdType& src){

However, I don't know if the ::element_type is TAO specific or defined
by the standard CORBA spec.

> Which compiles fine here (TAO+Omniorb on Linux), but I don't know if this will
> still do as was intended ?

If this last version compiles on Omniorb, it should be Ok.

> I could also apply Philippe's patches without much trouble. Are they the
> definitive solutions for win32 ?

I don't know how "definitive" they will be, but in my view, it's Ok.

I will try (for real this time) to take some time to look into this
merge more deeply and validate the new master on win32 in our VR
applications (I promise, I will also try to release some more info on
that soon !)

win32 branch&patches merging

Submitted by jean.sreng on Fri, 2011-02-04 15:28.

On 04/02/2011 14:21, Jean Sreng wrote:
> I will try (for real this time) to take some time to look into this
> merge more deeply and validate the new master on win32 in our VR
> applications (I promise, I will also try to release some more info on
> that soon !)

First insight, we were recently allowed to publish this video which
illustrates a small part of the work we're doing here at the CEA.

Roughly, Orocos RTT is used here as the middleware between the physics
engine, 3D rendering, Kinect device and data processing (more detailed
presentation to come!)

http://www.youtube.com/watch?v=7-HOc696g6s

win32 branch&patches merging

Submitted by peter on Fri, 2011-02-04 14:24.

On Friday 04 February 2011 14:21:02 Jean Sreng wrote:
> Hi Peter,
>
> On 04/02/2011 12:50, Peter Soetens wrote:
> > I was looking in merging the outstanding win32 patches onto master, but
> > some
>
> > changes on Jean's branch need more review. Especially this commit:
> I thank you for your efforts to try to merge the win32 patches onto
> master. I was going to do that but unfortunately didn't have much time
> to spend on that lately.
>
> > http://gitorious.org/orocos-toolchain/jsrengs-
> > rtt/commit/506a183a9a3c0e6c3a9220e6333812c1a04bc0c5
> >
> > It quite heavily violates the coding style and rewrites a lot of
> > whitespace on lines that could have left untouched.
>
> I agree, I should have filtered these unecessary changes. My bad.
>
> > Next from the technical side: is this purely an add-on ? Ie, is any
> > existing behaviour changed in the CORBA transport ?
>
> There is no changes in the serialization of base types (non STL types).
> This patches add "generic" serialization for STL types (for instance,
> the previous specific implementation of the serialization of
> std::vector<double> has been replaced with the new generic one).

What is the proposed migration path for the users of vector<double> if they
were using the IDL API to communicate with their components ?

>
> > It also contains a hard-coded reference to TAO:
> >
> >

> > static bool
> > toCorbaType(TAO::details::string_sequence_element<TAO::details::string_tr
> > aits<char, dummy>  >&  dest, const StdType&  src) {
> >

>
> This should not be necessary. After reviewing the code, I think this can
> be replaced with (not tested)
>

> static bool toCorbaType(sequence::element_type& dest, const StdType& src){
>

>
> However, I don't know if the ::element_type is TAO specific or defined
> by the standard CORBA spec.

I tested it, it's also present in the OMNIORB code, so we'll assume it is and
accept this version of solution.

>
> > Which compiles fine here (TAO+Omniorb on Linux), but I don't know if this
> > will still do as was intended ?
>
> If this last version compiles on Omniorb, it should be Ok.

Ack.

>
> > I could also apply Philippe's patches without much trouble. Are they the
> > definitive solutions for win32 ?
>
> I don't know how "definitive" they will be, but in my view, it's Ok.
>
> I will try (for real this time) to take some time to look into this
> merge more deeply and validate the new master on win32 in our VR
> applications (I promise, I will also try to release some more info on
> that soon !)

We hardly can wait :-)

Peter

win32 branch&patches merging

Submitted by mathieu gautier on Fri, 2011-02-04 15:56.

Hi,

>> There is no changes in the serialization of base types (non STL types).
>> This patches add "generic" serialization for STL types (for instance,
>> the previous specific implementation of the serialization of
>> std::vector<double> has been replaced with the new generic one).
>
> What is the proposed migration path for the users of vector<double>
if they
> were using the IDL API to communicate with their components ?

The only difference between the two types is the module where they are
declared. Both types are generated from a sequence<double> (see
tao/DoubleSeq.pidl for TAO). The old implementation was declared in
module RTT/corba. The TAO one is declared in module CORBA. I don't know
corba enough to see the consequences of this change.

A compatible change would be to redeclare each basic sequences in
OrocosTypes.idl. But it's redundant with the sequences already provided
by TAO.

I think it's similar for OMNIORB.

win32 branch&patches merging

Submitted by peter on Tue, 2011-02-08 10:44.

On Friday 04 February 2011 16:38:03 Mathieu Gautier wrote:
> Hi,
>
> >> There is no changes in the serialization of base types (non STL types).
> >> This patches add "generic" serialization for STL types (for instance,
> >> the previous specific implementation of the serialization of
> >> std::vector<double> has been replaced with the new generic one).
> >
> > What is the proposed migration path for the users of vector<double>
>
> if they
>
> > were using the IDL API to communicate with their components ?
>
> The only difference between the two types is the module where they are
> declared. Both types are generated from a sequence<double> (see
> tao/DoubleSeq.pidl for TAO). The old implementation was declared in
> module RTT/corba. The TAO one is declared in module CORBA. I don't know
> corba enough to see the consequences of this change.
>
> A compatible change would be to redeclare each basic sequences in
> OrocosTypes.idl. But it's redundant with the sequences already provided
> by TAO.
>
> I think it's similar for OMNIORB.

I don't follow here. A 2.2 user would have written the code below to set new
values in a Property<vector syntax):

CDoubleSequence new_array(3);
new_array[0] = 1.0;
new_array[1] = 2.0;
new_array[2] = 3.0;
 
CORBA::Any any;
any <<= new_array;
 
// config is a CConfigurationInterface_var
config->setProperty("foo", any );

While your patch needs them to change that to:

CAnySequence new_array(3);
new_array[0] <<= 1.0;
new_array[1] <<= 2.0;
new_array[2] <<= 3.0;
 
CORBA::Any any;
any <<= new_array;
 
// config is a CConfigurationInterface_var
config->setProperty("foo", any );

So your change breaks all this existing code. I think the only way out is as
Sylvain proposed, to move the transports more in the hands of the user and
less in the hands of RTT. I would accept all your changes, except that the RTT
corba transport for vector<double> keeps using the CDoubleSequence and that
the user can disable that one in his rtt-corba-transport and generate his own,
based on your generic solution.

So to be clear: OrocosTypes.idl contains:

module RTT
{
  module corba
  {
    // Classical Orocos type for vector<double>:
    typedef sequence<double> CDoubleSequence;
 
    // use to convert std::pair
    struct Pair {
      any t1;
      any t2;
    };
 
    // Generic Orocos types:
    typedef sequence<any> CAnySequence;
    // use to convert std::map
    typedef sequence<Pair> PairSeq;
  };
};

You'd also have to rename 'Pair' to 'CPair' and 'PairSeq' to 'CPairSequence'
for naming consistency reasons. Your personal typekit uses the lower part of
this file, the default typekit of rtt keeps using the upper part, but can be
disabled at compile time (cmake).

Peter

win32 branch&patches merging

Submitted by mathieu gautier on Tue, 2011-02-08 12:36.

Hi,

> I don't follow here. A 2.2 user would have written the code below to set new

My explanations were too short.

In fact, with my patch and TAO, a vector<double> is serialized in a
CORBA::DoubleSeq. This sequence is provided with the TAO headers and is
exactly the CDoubleSequence defined in OrocosTypes.idl. Thus, you can
keep the actual syntax, except for the type CDoubleSequence which become
a CORBA::DoubleSeq.

The sequence used for the corba serialization is defined by the typedef
sequence in the AnyConversion specialization (see
RTTCorbaConversion.hpp), for example :

std::vector<double> -> CORBA::DoubleSeq defined by TAO

std::vector<float> -> CORBA::FloatSeq defined by TAO

std::vector<std::pair modified OrocosTypes.idl

std::vector<std::vector modified OrocosTypes.idl

The CAnySequence is then only used to serialize container of std
container such a vector<vector>. When other container will be
implemented such as set, list, etc. the CAnySequence would provide the
serialization for list<vector>, vector<set>, etc.

> So your change breaks all this existing code. I think the only way out is as
> Sylvain proposed, to move the transports more in the hands of the user and
> less in the hands of RTT. I would accept all your changes, except that the RTT
> corba transport for vector<double> keeps using the CDoubleSequence and that
> the user can disable that one in his rtt-corba-transport and generate his own,
> based on your generic solution.

For compatibility issues, we can use a simple typedef :

typedef CORBA::DoubleSeq CDoubleSequence;

and remove the CDoubleSequence definition from OrocosTypes.idl

>
> You'd also have to rename 'Pair' to 'CPair' and 'PairSeq' to 'CPairSequence'
> for naming consistency reasons. Your personal typekit uses the lower part of

Ok.

On OmniOrb compatibility, I just checked the last OmniOrb version, and
it provides sequences for base types (see idl/orbidl.idl) in a module
named CORBA with the same names as those of TAO. So, my patch must be
working with at least the last version of OmniOrb.

win32 branch&patches merging

Submitted by peter on Tue, 2011-02-08 13:12.

On Tuesday 08 February 2011 13:32:19 Mathieu Gautier wrote:
> Hi,
>
> > I don't follow here. A 2.2 user would have written the code below to set
> > new
>
> My explanations were too short.
>
> In fact, with my patch and TAO, a vector<double> is serialized in a
> CORBA::DoubleSeq. This sequence is provided with the TAO headers and is
> exactly the CDoubleSequence defined in OrocosTypes.idl. Thus, you can
> keep the actual syntax, except for the type CDoubleSequence which become
> a CORBA::DoubleSeq.
>
> The sequence used for the corba serialization is defined by the typedef
> sequence in the AnyConversion specialization (see
> RTTCorbaConversion.hpp), for example :
>
> std::vector<double> -> CORBA::DoubleSeq defined by TAO
>
> std::vector<float> -> CORBA::FloatSeq defined by TAO
>
> std::vector<std::pair > modified OrocosTypes.idl
>
> std::vector<std::vector > modified OrocosTypes.idl
>
> The CAnySequence is then only used to serialize container of std
> container such a vector<vector>. When other container will be
> implemented such as set, list, etc. the CAnySequence would provide the
> serialization for list<vector>, vector<set>, etc.
>
> > So your change breaks all this existing code. I think the only way out is
> > as Sylvain proposed, to move the transports more in the hands of the
> > user and less in the hands of RTT. I would accept all your changes,
> > except that the RTT corba transport for vector<double> keeps using the
> > CDoubleSequence and that the user can disable that one in his
> > rtt-corba-transport and generate his own, based on your generic
> > solution.
>
> For compatibility issues, we can use a simple typedef :
>
>

> typedef CORBA::DoubleSeq CDoubleSequence;
>

>
> and remove the CDoubleSequence definition from OrocosTypes.idl

Good ! Now I understand.

>
> > You'd also have to rename 'Pair' to 'CPair' and 'PairSeq' to
> > 'CPairSequence' for naming consistency reasons. Your personal typekit
> > uses the lower part of
>
> Ok.
>
> On OmniOrb compatibility, I just checked the last OmniOrb version, and
> it provides sequences for base types (see idl/orbidl.idl) in a module
> named CORBA with the same names as those of TAO. So, my patch must be
> working with at least the last version of OmniOrb.

Great. Then there's nothing in the way, except that you need to provide that
typedef and that the indentation is a bit-off in the CorbaConversion.hpp. Will
you submit a new patch that fixes these last issues ? Then I can merge your
work with what Philippe proposed and we'll have decent Win32 support in 2.3.

Peter

win32 branch&patches merging

Submitted by mathieu gautier on Tue, 2011-02-08 16:48.

>
> Great. Then there's nothing in the way, except that you need to provide that
> typedef and that the indentation is a bit-off in the CorbaConversion.hpp. Will
> you submit a new patch that fixes these last issues ? Then I can merge your
> work with what Philippe proposed and we'll have decent Win32 support in 2.3.

The current patch is in Jean's repository. Do you want this patch in his
repository, against the 2.2 branch or against the last version of your
master ?

win32 branch&patches merging

Submitted by peter on Wed, 2011-02-09 08:52.

On Tuesday 08 February 2011 17:46:07 Mathieu Gautier wrote:
> > Great. Then there's nothing in the way, except that you need to provide
> > that typedef and that the indentation is a bit-off in the
> > CorbaConversion.hpp. Will you submit a new patch that fixes these last
> > issues ? Then I can merge your work with what Philippe proposed and
> > we'll have decent Win32 support in 2.3.
>
> The current patch is in Jean's repository. Do you want this patch in his
> repository, against the 2.2 branch or against the last version of your
> master ?

I just pushed my latest master branches, including the merge of your previous
work. I didn't find your patch in jean's repository. I'm looking in:
git://gitorious.org/~jsreng/orocos-toolchain/jsrengs-rtt.git

I prefer to have it against master. For the 2.2 branch, only the 'minor'
patches from Philippe would be applied (includes some of your fixes too).

Peter

win32 branch&patches merging

Submitted by mathieu gautier on Tue, 2011-02-08 14:04.

> Great. Then there's nothing in the way, except that you need to provide that
> typedef and that the indentation is a bit-off in the CorbaConversion.hpp. Will

Indeed.

> you submit a new patch that fixes these last issues ? Then I can merge your
> work with what Philippe proposed and we'll have decent Win32 support in 2.3.

Ok, I try do it this week.

win32 branch&patches merging

Submitted by peter on Fri, 2011-02-04 14:32.

On Friday 04 February 2011 15:19:32 Peter Soetens wrote:
> On Friday 04 February 2011 14:21:02 Jean Sreng wrote:
> > Hi Peter,
> >
> > On 04/02/2011 12:50, Peter Soetens wrote:
> > > I was looking in merging the outstanding win32 patches onto master, but
> > > some
> >
> > > changes on Jean's branch need more review. Especially this commit:
> > I thank you for your efforts to try to merge the win32 patches onto
> > master. I was going to do that but unfortunately didn't have much time
> > to spend on that lately.
> >
> > > http://gitorious.org/orocos-toolchain/jsrengs-
> > > rtt/commit/506a183a9a3c0e6c3a9220e6333812c1a04bc0c5
> > >
> > > It quite heavily violates the coding style and rewrites a lot of
> > > whitespace on lines that could have left untouched.
> >
> > I agree, I should have filtered these unecessary changes. My bad.
> >
> > > Next from the technical side: is this purely an add-on ? Ie, is any
> > > existing behaviour changed in the CORBA transport ?
> >
> > There is no changes in the serialization of base types (non STL types).
> > This patches add "generic" serialization for STL types (for instance,
> > the previous specific implementation of the serialization of
> > std::vector<double> has been replaced with the new generic one).
>
> What is the proposed migration path for the users of vector<double> if they
> were using the IDL API to communicate with their components ?
>
> > > It also contains a hard-coded reference to TAO:
> > >
> > >

> > > static bool
> > > toCorbaType(TAO::details::string_sequence_element<TAO::details::string_
> > > tr aits<char, dummy>  >&  dest, const StdType&  src) {
> > >

> >
> > This should not be necessary. After reviewing the code, I think this can
> > be replaced with (not tested)
> >

> > static bool toCorbaType(sequence::element_type& dest, const StdType&
> > src){

> >
> > However, I don't know if the ::element_type is TAO specific or defined
> > by the standard CORBA spec.
>
> I tested it, it's also present in the OMNIORB code, so we'll assume it is
> and accept this version of solution.

Oh rats, it isn't compiling. We'll have to stick with my 'template' solution
which does work for both implementations.

Peter