The main aim of this bunch of patches is the ability to use OmniORB4 in
Orocos -- instead of TAO. TAO is huge, slow and very hard to
hand-compile (which sometime is something you have to do). Given that
people I know and trust are using OmniORB for robotic applications, I
wanted to give it a try.
The first patches (17-20) are actually generic fixes in the way the CORBA code
handles the 'nil' value (which is NULL on TAO, but does not have to be).
The second part (21-26) is really getting into the subject, making OmniORB a
compile-time option. I hope I broke nothing of the MacOS-X fixes that
came lately.
[git] supporting OmniORB4 instead of TAO
On Thursday 25 September 2008 19:10:50 Sylvain Joyeux wrote:
> The main aim of this bunch of patches is the ability to use OmniORB4 in
> Orocos -- instead of TAO. TAO is huge, slow and very hard to
> hand-compile (which sometime is something you have to do). Given that
> people I know and trust are using OmniORB for robotic applications, I
> wanted to give it a try.
>
> The first patches (17-20) are actually generic fixes in the way the CORBA
> code handles the 'nil' value (which is NULL on TAO, but does not have to
> be).
>
> The second part (21-26) is really getting into the subject, making OmniORB
> a compile-time option. I hope I broke nothing of the MacOS-X fixes that
> came lately.
I tried to apply these patches on my local git repository (with git-am), but
the whitespace changes are preventing them to apply. I tried to use
git-am -i --whitespace=fix ~/Mail/Orocos-patches.mbox
but I still get the same errors, while the patches apply mostly fine when
using patch -p1 -l on the raw patches.
Could you fix this locally and re-submit or do you know a better way to handle
whitespace changes ?
Peter
[git] supporting OmniORB4 instead of TAO
I guess, now that you are moving to git, would be to use github for that
instead of mailing lists ...
My two cents
Sylvain
supporting OmniORB4 instead of TAO
On Thursday 25 September 2008 19:10:50 Sylvain Joyeux wrote:
> The main aim of this bunch of patches is the ability to use OmniORB4 in
> Orocos -- instead of TAO. TAO is huge, slow and very hard to
> hand-compile (which sometime is something you have to do). Given that
> people I know and trust are using OmniORB for robotic applications, I
> wanted to give it a try.
>
> The first patches (17-20) are actually generic fixes in the way the CORBA
> code handles the 'nil' value (which is NULL on TAO, but does not have to
> be).
>
> The second part (21-26) is really getting into the subject, making OmniORB
> a compile-time option. I hope I broke nothing of the MacOS-X fixes that
> came lately.
That was more in the build system than any other place, so I don't expect
problems except there.
OmniORB support is very welcome as a 1.8.0 feature. I'll review and apply
asap.
Peter
supporting OmniORB4 instead of TAO
>On Thursday 25 September 2008 19:10:50 Sylvain Joyeux wrote:
>> The main aim of this bunch of patches is the ability to use OmniORB4 in
>> Orocos -- instead of TAO. TAO is huge, slow and very hard to
>> hand-compile (which sometime is something you have to do). Given that
>> people I know and trust are using OmniORB for robotic applications, I
>> wanted to give it a try.
>>
>> The first patches (17-20) are actually generic fixes in the way the CORBA
>> code handles the 'nil' value (which is NULL on TAO, but does not have to
>> be).
>>
>> The second part (21-26) is really getting into the subject, making >OmniORB
>> a compile-time option. I hope I broke nothing of the MacOS-X fixes that
>> came lately.
>That was more in the build system than any other place, so I don't expect
>problems except there.
>
>OmniORB support is very welcome as a 1.8.0 feature. I'll review and apply
>asap.
Are these patches already applied on trunk? Because i wanted to give this a try. (Macports offers only omniorb)
Ruben
supporting OmniORB4 instead of TAO
On Wednesday 03 December 2008 09:42:46 ruben [dot] smits [..] ... wrote:
> >OmniORB support is very welcome as a 1.8.0 feature. I'll review and apply
> >asap.
>
> Are these patches already applied on trunk? Because i wanted to give this a
> try. (Macports offers only omniorb)
See http://github.com/psoetens/orocos-rtt/tree/omniorb-port for the
location/status of the port.
To check out do:
git clone git://github.com/psoetens/orocos-rtt.git
cd orocos-rtt
Defaults to 'master' branch
Check out my omniorb-port branch:
git-checkout -b omniorb origin/omniorb-port
Which creates a local branch 'omniorb'.
You're now having 'experimental' omniorb support...
To get diffs, do:
git diff
then to commit all ('-a) your changes:
git-commit -a
To see what's your commit log:
git-log
To prepare the last three commits as patches for the ML, do:
git-format-patch HEAD~3
And mail them. git does not need |less or so it does this by itself...
Easy :-)
Peter
supporting OmniORB4 instead of TAO
On Wednesday 03 December 2008 09:42:46 ruben [dot] smits [..] ... wrote:
> >OmniORB support is very welcome as a 1.8.0 feature. I'll review and apply
> >asap.
>
> Are these patches already applied on trunk? Because i wanted to give this a
> try. (Macports offers only omniorb)
I have applied it locally on a git branch, bug because of the changes in the
CORBA cmake files due to the Mac OS-X port, the omniorb patches did not apply
cleanly for the build system. So compiling TAO and Omniorb are now broken on
that branch. I can publish what I have through my github account if you care.
Again it's a build system issue, not a code issue.
Peter