Discussion:
[omniORB] CORBA::Double type corrouption issue in python omniORB
Amit Sharma
2013-04-19 00:03:11 UTC
Permalink
Hi,

I am running into an issue with OmniORB4.1.2 and python omniORB 3.2.
In python code I create a variable

level = -60.0

then make a call to server which is running ACE+TAO on ARM with level
passed in as variable. Client is my PC running x86.
python call:
remoteobj.Set(level)

The servers ends up with
1.53454e-314 as the value that it got.
Server has a limit check and throws the exception as limits are set for
upper_limit = -50.0 and lower_limit = -110.0
when the client gets the exception it prints the limits as corroupted but
the val = -60.0

I do not know why the Doubles are having trouble. Integers are ok, Booleans
are ok as well.

-Amit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20130418/4d2d4ffb/attachment.html>
Johnny Willemsen
2013-04-19 06:57:07 UTC
Permalink
Hi,

I do have seen problems recently with TAO on ARM where endianess is
causing problems. What is the value you get on the TAO side? Have you
run the ACE/TAO test suite on the target?

Best regards,

Johnny
Post by Amit Sharma
Hi,
I am running into an issue with OmniORB4.1.2 and python omniORB 3.2.
In python code I create a variable
level = -60.0
then make a call to server which is running ACE+TAO on ARM with level
passed in as variable. Client is my PC running x86.
remoteobj.Set(level)
The servers ends up with
1.53454e-314 as the value that it got.
Server has a limit check and throws the exception as limits are set for
upper_limit = -50.0 and lower_limit = -110.0
when the client gets the exception it prints the limits as corroupted
but the val = -60.0
I do not know why the Doubles are having trouble. Integers are ok,
Booleans are ok as well.
-Amit
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
Duncan Grisby
2013-04-19 08:57:06 UTC
Permalink
Post by Johnny Willemsen
I do have seen problems recently with TAO on ARM where endianess is
causing problems. What is the value you get on the TAO side? Have you
run the ACE/TAO test suite on the target?
Some ARMs have a bizarre mixed endian double, where the 64-bit double is
split into two 32-bit words in big-endian format but then the 32-bit
words are encoded in little-endian format.

omniORB has specific support for handling thes mixed endian doubles on
ARM. I don't know if TAO does, but I expect this is the cause of your
problem -- either you need to configure TAO to use mixed-endian doubles,
or TAO needs to grow support for them.

Cheers,

Duncan.
--
-- Duncan Grisby --
-- duncan at grisby.org --
-- http://www.grisby.org --
Johnny Willemsen
2013-04-19 08:58:51 UTC
Permalink
Hi,
Post by Duncan Grisby
Post by Johnny Willemsen
I do have seen problems recently with TAO on ARM where endianess is
causing problems. What is the value you get on the TAO side? Have you
run the ACE/TAO test suite on the target?
Some ARMs have a bizarre mixed endian double, where the 64-bit double is
split into two 32-bit words in big-endian format but then the 32-bit
words are encoded in little-endian format.
omniORB has specific support for handling thes mixed endian doubles on
ARM. I don't know if TAO does, but I expect this is the cause of your
problem -- either you need to configure TAO to use mixed-endian doubles,
or TAO needs to grow support for them.
I don't think we have support for that, it looks similar to problems I
have seen recently with the latest Android emulator. Do you know maybe
which defines are set when we compile for this bizarre mixed endian double?

Best regards,

Johnny
Johnny Willemsen
2013-04-19 11:11:52 UTC
Permalink
Hi,

Found the needed ARM documentation on the web. Looks TAO doesn't support
the mixed endian double on ARM. Amit, I would recommend you to run the
ACE tests/CDR_Array_Test on your target and see whether it works or not.

Best regards,

Johnny Willemsen
Remedy IT
http://www.theaceorb.nl
Post by Duncan Grisby
Post by Johnny Willemsen
I do have seen problems recently with TAO on ARM where endianess is
causing problems. What is the value you get on the TAO side? Have you
run the ACE/TAO test suite on the target?
Some ARMs have a bizarre mixed endian double, where the 64-bit double is
split into two 32-bit words in big-endian format but then the 32-bit
words are encoded in little-endian format.
omniORB has specific support for handling thes mixed endian doubles on
ARM. I don't know if TAO does, but I expect this is the cause of your
problem -- either you need to configure TAO to use mixed-endian doubles,
or TAO needs to grow support for them.
Cheers,
Duncan.
Amit
2013-04-19 12:02:25 UTC
Permalink
Thanks Jhonny and Duncan,

I will try the test, also I am going to run the server on x86 target and see how it behaves. So you guys might be right about it being an ACE TAO ARM problem.
If that is the case then is there a workaround you guys would suggest.
Regards,
Amit
Hi,
Found the needed ARM documentation on the web. Looks TAO doesn't support the mixed endian double on ARM. Amit, I would recommend you to run the ACE tests/CDR_Array_Test on your target and see whether it works or not.
Best regards,
Johnny Willemsen
Remedy IT
http://www.theaceorb.nl
Post by Duncan Grisby
Post by Johnny Willemsen
I do have seen problems recently with TAO on ARM where endianess is
causing problems. What is the value you get on the TAO side? Have you
run the ACE/TAO test suite on the target?
Some ARMs have a bizarre mixed endian double, where the 64-bit double is
split into two 32-bit words in big-endian format but then the 32-bit
words are encoded in little-endian format.
omniORB has specific support for handling thes mixed endian doubles on
ARM. I don't know if TAO does, but I expect this is the cause of your
problem -- either you need to configure TAO to use mixed-endian doubles,
or TAO needs to grow support for them.
Cheers,
Duncan.
Johnny Willemsen
2013-04-19 12:10:22 UTC
Permalink
Hi,
Post by Amit
I will try the test, also I am going to run the server on x86
target and see how it behaves. So you guys might be right about it being
an ACE TAO ARM problem.
Post by Amit
If that is the case then is there a workaround you guys would suggest.
The correct approach would be to port ACE/TAO to your target environment
which includes a full test of the suite to make sure it runs. The fact
that you have compiled something successfully doesn't mean it runs
perfect, there is no workaround for that.

Best regards,

Johnny
Amit
2013-04-19 12:13:43 UTC
Permalink
Thanks!

Will approach it from the test side and the see if I can get ACE TAO to comply if broken.

Regards,
Amit

Sent from my iPad
Hi,
Post by Amit
I will try the test, also I am going to run the server on x86 target and see how it behaves. So you guys might be right about it being an ACE TAO ARM problem.
If that is the case then is there a workaround you guys would suggest.
The correct approach would be to port ACE/TAO to your target environment which includes a full test of the suite to make sure it runs. The fact that you have compiled something successfully doesn't mean it runs perfect, there is no workaround for that.
Best regards,
Johnny
Johnny Willemsen
2013-04-19 12:16:30 UTC
Permalink
Hi,
Post by Amit
Will approach it from the test side and the see if I can get ACE TAO to comply if broken.
See http://www.theaceorb.nl for the services of the company I work for,
we can assist with this effort if needed.

Best regards,

Johnny
Post by Amit
Regards,
Amit
Sent from my iPad
Hi,
Post by Amit
I will try the test, also I am going to run the server on x86 target and see how it behaves. So you guys might be right about it being an ACE TAO ARM problem.
If that is the case then is there a workaround you guys would suggest.
The correct approach would be to port ACE/TAO to your target environment which includes a full test of the suite to make sure it runs. The fact that you have compiled something successfully doesn't mean it runs perfect, there is no workaround for that.
Best regards,
Johnny
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
Michael Powell
2013-04-19 12:21:52 UTC
Permalink
Haven't dealt much with Omni yet. A little with CORBA, mostly with WCF
and custom network layers.

I do work with ARM on a daily basis though. Floating point is an issue
on ARM, whether it is soft, hard, or softfp. We have soft I think.

Without addressing the ORB itself, could you work around it and custom
marshal, say a byte array (unsigned char) from your doubles?

That or possibly prefer floats to doubles. Or avoid floating point
altogether if you don't need them.

HTH
Hi,
Found the needed ARM documentation on the web. Looks TAO doesn't support the
mixed endian double on ARM. Amit, I would recommend you to run the ACE
tests/CDR_Array_Test on your target and see whether it works or not.
Best regards,
Johnny Willemsen
Remedy IT
http://www.theaceorb.nl
Post by Duncan Grisby
Post by Johnny Willemsen
I do have seen problems recently with TAO on ARM where endianess is
causing problems. What is the value you get on the TAO side? Have you
run the ACE/TAO test suite on the target?
Some ARMs have a bizarre mixed endian double, where the 64-bit double is
split into two 32-bit words in big-endian format but then the 32-bit
words are encoded in little-endian format.
omniORB has specific support for handling thes mixed endian doubles on
ARM. I don't know if TAO does, but I expect this is the cause of your
problem -- either you need to configure TAO to use mixed-endian doubles,
or TAO needs to grow support for them.
Cheers,
Duncan.
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
Amit
2013-04-19 12:39:36 UTC
Permalink
Thanks

This is a good idea. I will define an internal object class that works with floats and see how that goes.

Amit

Sent from my iPad
Post by Michael Powell
Haven't dealt much with Omni yet. A little with CORBA, mostly with WCF
and custom network layers.
I do work with ARM on a daily basis though. Floating point is an issue
on ARM, whether it is soft, hard, or softfp. We have soft I think.
Without addressing the ORB itself, could you work around it and custom
marshal, say a byte array (unsigned char) from your doubles?
That or possibly prefer floats to doubles. Or avoid floating point
altogether if you don't need them.
HTH
Hi,
Found the needed ARM documentation on the web. Looks TAO doesn't support the
mixed endian double on ARM. Amit, I would recommend you to run the ACE
tests/CDR_Array_Test on your target and see whether it works or not.
Best regards,
Johnny Willemsen
Remedy IT
http://www.theaceorb.nl
Post by Duncan Grisby
Post by Johnny Willemsen
I do have seen problems recently with TAO on ARM where endianess is
causing problems. What is the value you get on the TAO side? Have you
run the ACE/TAO test suite on the target?
Some ARMs have a bizarre mixed endian double, where the 64-bit double is
split into two 32-bit words in big-endian format but then the 32-bit
words are encoded in little-endian format.
omniORB has specific support for handling thes mixed endian doubles on
ARM. I don't know if TAO does, but I expect this is the cause of your
problem -- either you need to configure TAO to use mixed-endian doubles,
or TAO needs to grow support for them.
Cheers,
Duncan.
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
Johnny Willemsen
2013-04-19 12:46:32 UTC
Permalink
Hi,
Post by Amit
This is a good idea. I will define an internal object class that
works with floats and see how that goes.

If you have a real mixed endian ARM target than I think there are much
more problems than just the double, running all tests will probably show
that.

Best regards,

Johnny
Post by Amit
Amit
Sent from my iPad
Post by Michael Powell
Haven't dealt much with Omni yet. A little with CORBA, mostly with WCF
and custom network layers.
I do work with ARM on a daily basis though. Floating point is an issue
on ARM, whether it is soft, hard, or softfp. We have soft I think.
Without addressing the ORB itself, could you work around it and custom
marshal, say a byte array (unsigned char) from your doubles?
That or possibly prefer floats to doubles. Or avoid floating point
altogether if you don't need them.
HTH
Hi,
Found the needed ARM documentation on the web. Looks TAO doesn't support the
mixed endian double on ARM. Amit, I would recommend you to run the ACE
tests/CDR_Array_Test on your target and see whether it works or not.
Best regards,
Johnny Willemsen
Remedy IT
http://www.theaceorb.nl
Post by Duncan Grisby
Post by Johnny Willemsen
I do have seen problems recently with TAO on ARM where endianess is
causing problems. What is the value you get on the TAO side? Have you
run the ACE/TAO test suite on the target?
Some ARMs have a bizarre mixed endian double, where the 64-bit double is
split into two 32-bit words in big-endian format but then the 32-bit
words are encoded in little-endian format.
omniORB has specific support for handling thes mixed endian doubles on
ARM. I don't know if TAO does, but I expect this is the cause of your
problem -- either you need to configure TAO to use mixed-endian doubles,
or TAO needs to grow support for them.
Cheers,
Duncan.
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
Johnny Willemsen
2013-04-19 13:10:37 UTC
Permalink
Hi,

It could be that your issue is fixed in the latest TAO version which is
TAO 2.1.8. I merged in some changes the last months for getting TAO to
run on the Beaglebone.

Best regards,

Johnny
Post by Amit
Hi,
Post by Amit
This is a good idea. I will define an internal object class that
works with floats and see how that goes.
If you have a real mixed endian ARM target than I think there are much
more problems than just the double, running all tests will probably show
that.
Best regards,
Johnny
Post by Amit
Amit
Sent from my iPad
Post by Michael Powell
Haven't dealt much with Omni yet. A little with CORBA, mostly with WCF
and custom network layers.
I do work with ARM on a daily basis though. Floating point is an issue
on ARM, whether it is soft, hard, or softfp. We have soft I think.
Without addressing the ORB itself, could you work around it and custom
marshal, say a byte array (unsigned char) from your doubles?
That or possibly prefer floats to doubles. Or avoid floating point
altogether if you don't need them.
HTH
On Fri, Apr 19, 2013 at 6:11 AM, Johnny Willemsen
Hi,
Found the needed ARM documentation on the web. Looks TAO doesn't support the
mixed endian double on ARM. Amit, I would recommend you to run the ACE
tests/CDR_Array_Test on your target and see whether it works or not.
Best regards,
Johnny Willemsen
Remedy IT
http://www.theaceorb.nl
Post by Duncan Grisby
Post by Johnny Willemsen
I do have seen problems recently with TAO on ARM where endianess is
causing problems. What is the value you get on the TAO side? Have you
run the ACE/TAO test suite on the target?
Some ARMs have a bizarre mixed endian double, where the 64-bit double is
split into two 32-bit words in big-endian format but then the 32-bit
words are encoded in little-endian format.
omniORB has specific support for handling thes mixed endian doubles on
ARM. I don't know if TAO does, but I expect this is the cause of your
problem -- either you need to configure TAO to use mixed-endian doubles,
or TAO needs to grow support for them.
Cheers,
Duncan.
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
Amit
2013-04-20 01:32:26 UTC
Permalink
Hi
I was able to create float type class for our objects and that seem to work. So floats work.

Now I started the build/cross compile of latest TAO for arm had to build x86 then got the ARM one done but our app also has dependency on OpenDDS so am building that for both x86 and arm.
This will help us internally move to the latest versions of those anyways. I will get to try it Monday to see if the latest version has the mixed double issue resolved in TAO

Thanks for the help,
Amit

Sent from my iPad
Hi,
It could be that your issue is fixed in the latest TAO version which is TAO 2.1.8. I merged in some changes the last months for getting TAO to run on the Beaglebone.
Best regards,
Johnny
Post by Amit
Hi,
Post by Amit
This is a good idea. I will define an internal object class that
works with floats and see how that goes.
If you have a real mixed endian ARM target than I think there are much
more problems than just the double, running all tests will probably show
that.
Best regards,
Johnny
Post by Amit
Amit
Sent from my iPad
Post by Michael Powell
Haven't dealt much with Omni yet. A little with CORBA, mostly with WCF
and custom network layers.
I do work with ARM on a daily basis though. Floating point is an issue
on ARM, whether it is soft, hard, or softfp. We have soft I think.
Without addressing the ORB itself, could you work around it and custom
marshal, say a byte array (unsigned char) from your doubles?
That or possibly prefer floats to doubles. Or avoid floating point
altogether if you don't need them.
HTH
On Fri, Apr 19, 2013 at 6:11 AM, Johnny Willemsen
Hi,
Found the needed ARM documentation on the web. Looks TAO doesn't support the
mixed endian double on ARM. Amit, I would recommend you to run the ACE
tests/CDR_Array_Test on your target and see whether it works or not.
Best regards,
Johnny Willemsen
Remedy IT
http://www.theaceorb.nl
Post by Duncan Grisby
Post by Johnny Willemsen
I do have seen problems recently with TAO on ARM where endianess is
causing problems. What is the value you get on the TAO side? Have you
run the ACE/TAO test suite on the target?
Some ARMs have a bizarre mixed endian double, where the 64-bit double is
split into two 32-bit words in big-endian format but then the 32-bit
words are encoded in little-endian format.
omniORB has specific support for handling thes mixed endian doubles on
ARM. I don't know if TAO does, but I expect this is the cause of your
problem -- either you need to configure TAO to use mixed-endian doubles,
or TAO needs to grow support for them.
Cheers,
Duncan.
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
Michael Powell
2013-04-20 01:51:50 UTC
Permalink
We deal a lot in a boost::tuple<float, float, float, float> issue.
Most of the time we're looking at vectors of these short int based
(16-bit) values. But we will also frequently be manipulating them,
scaling them, etc. So float seems to have been a pretty good fit so
far. It's only 32-bits in memory double that of short int, and the
endianness doesn't seem to be an issue for float (at least not yet).
Anywho, glad it's working for you. That's good to know.
Post by Amit
Hi
I was able to create float type class for our objects and that seem to work. So floats work.
Now I started the build/cross compile of latest TAO for arm had to build x86 then got the ARM one done but our app also has dependency on OpenDDS so am building that for both x86 and arm.
This will help us internally move to the latest versions of those anyways. I will get to try it Monday to see if the latest version has the mixed double issue resolved in TAO
Thanks for the help,
Amit
Sent from my iPad
Hi,
It could be that your issue is fixed in the latest TAO version which is TAO 2.1.8. I merged in some changes the last months for getting TAO to run on the Beaglebone.
Best regards,
Johnny
Post by Amit
Hi,
Post by Amit
This is a good idea. I will define an internal object class that
works with floats and see how that goes.
If you have a real mixed endian ARM target than I think there are much
more problems than just the double, running all tests will probably show
that.
Best regards,
Johnny
Post by Amit
Amit
Sent from my iPad
Post by Michael Powell
Haven't dealt much with Omni yet. A little with CORBA, mostly with WCF
and custom network layers.
I do work with ARM on a daily basis though. Floating point is an issue
on ARM, whether it is soft, hard, or softfp. We have soft I think.
Without addressing the ORB itself, could you work around it and custom
marshal, say a byte array (unsigned char) from your doubles?
That or possibly prefer floats to doubles. Or avoid floating point
altogether if you don't need them.
HTH
On Fri, Apr 19, 2013 at 6:11 AM, Johnny Willemsen
Hi,
Found the needed ARM documentation on the web. Looks TAO doesn't support the
mixed endian double on ARM. Amit, I would recommend you to run the ACE
tests/CDR_Array_Test on your target and see whether it works or not.
Best regards,
Johnny Willemsen
Remedy IT
http://www.theaceorb.nl
Post by Duncan Grisby
Post by Johnny Willemsen
I do have seen problems recently with TAO on ARM where endianess is
causing problems. What is the value you get on the TAO side? Have you
run the ACE/TAO test suite on the target?
Some ARMs have a bizarre mixed endian double, where the 64-bit double is
split into two 32-bit words in big-endian format but then the 32-bit
words are encoded in little-endian format.
omniORB has specific support for handling thes mixed endian doubles on
ARM. I don't know if TAO does, but I expect this is the cause of your
problem -- either you need to configure TAO to use mixed-endian doubles,
or TAO needs to grow support for them.
Cheers,
Duncan.
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
Amit Sharma
2013-04-30 23:26:48 UTC
Permalink
This is an update so that if anyone else runs into it might help them.
The latest version of ACE-TAO has this bug resolved.
My double type access works fine from python when talking to ARM target running ace-tao.
Thanks again for all the help
Amit

Sent from my iPhone
Post by Michael Powell
We deal a lot in a boost::tuple<float, float, float, float> issue.
Most of the time we're looking at vectors of these short int based
(16-bit) values. But we will also frequently be manipulating them,
scaling them, etc. So float seems to have been a pretty good fit so
far. It's only 32-bits in memory double that of short int, and the
endianness doesn't seem to be an issue for float (at least not yet).
Anywho, glad it's working for you. That's good to know.
Post by Amit
Hi
I was able to create float type class for our objects and that seem to work. So floats work.
Now I started the build/cross compile of latest TAO for arm had to build x86 then got the ARM one done but our app also has dependency on OpenDDS so am building that for both x86 and arm.
This will help us internally move to the latest versions of those anyways. I will get to try it Monday to see if the latest version has the mixed double issue resolved in TAO
Thanks for the help,
Amit
Sent from my iPad
Hi,
It could be that your issue is fixed in the latest TAO version which is TAO 2.1.8. I merged in some changes the last months for getting TAO to run on the Beaglebone.
Best regards,
Johnny
Post by Amit
Hi,
Post by Amit
This is a good idea. I will define an internal object class that
works with floats and see how that goes.
If you have a real mixed endian ARM target than I think there are much
more problems than just the double, running all tests will probably show
that.
Best regards,
Johnny
Post by Amit
Amit
Sent from my iPad
Post by Michael Powell
Haven't dealt much with Omni yet. A little with CORBA, mostly with WCF
and custom network layers.
I do work with ARM on a daily basis though. Floating point is an issue
on ARM, whether it is soft, hard, or softfp. We have soft I think.
Without addressing the ORB itself, could you work around it and custom
marshal, say a byte array (unsigned char) from your doubles?
That or possibly prefer floats to doubles. Or avoid floating point
altogether if you don't need them.
HTH
On Fri, Apr 19, 2013 at 6:11 AM, Johnny Willemsen
Hi,
Found the needed ARM documentation on the web. Looks TAO doesn't support the
mixed endian double on ARM. Amit, I would recommend you to run the ACE
tests/CDR_Array_Test on your target and see whether it works or not.
Best regards,
Johnny Willemsen
Remedy IT
http://www.theaceorb.nl
Post by Duncan Grisby
Post by Johnny Willemsen
I do have seen problems recently with TAO on ARM where endianess is
causing problems. What is the value you get on the TAO side? Have you
run the ACE/TAO test suite on the target?
Some ARMs have a bizarre mixed endian double, where the 64-bit double is
split into two 32-bit words in big-endian format but then the 32-bit
words are encoded in little-endian format.
omniORB has specific support for handling thes mixed endian doubles on
ARM. I don't know if TAO does, but I expect this is the cause of your
problem -- either you need to configure TAO to use mixed-endian doubles,
or TAO needs to grow support for them.
Cheers,
Duncan.
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
Michael Powell
2013-04-30 23:58:54 UTC
Permalink
That is excellent news. Glad I could help you navigate through it.
Post by Amit Sharma
This is an update so that if anyone else runs into it might help them.
The latest version of ACE-TAO has this bug resolved.
My double type access works fine from python when talking to ARM target running ace-tao.
Thanks again for all the help
Amit
Sent from my iPhone
Post by Michael Powell
We deal a lot in a boost::tuple<float, float, float, float> issue.
Most of the time we're looking at vectors of these short int based
(16-bit) values. But we will also frequently be manipulating them,
scaling them, etc. So float seems to have been a pretty good fit so
far. It's only 32-bits in memory double that of short int, and the
endianness doesn't seem to be an issue for float (at least not yet).
Anywho, glad it's working for you. That's good to know.
Post by Amit
Hi
I was able to create float type class for our objects and that seem to work. So floats work.
Now I started the build/cross compile of latest TAO for arm had to build x86 then got the ARM one done but our app also has dependency on OpenDDS so am building that for both x86 and arm.
This will help us internally move to the latest versions of those anyways. I will get to try it Monday to see if the latest version has the mixed double issue resolved in TAO
Thanks for the help,
Amit
Sent from my iPad
Hi,
It could be that your issue is fixed in the latest TAO version which is TAO 2.1.8. I merged in some changes the last months for getting TAO to run on the Beaglebone.
Best regards,
Johnny
Post by Amit
Hi,
Post by Amit
This is a good idea. I will define an internal object class that
works with floats and see how that goes.
If you have a real mixed endian ARM target than I think there are much
more problems than just the double, running all tests will probably show
that.
Best regards,
Johnny
Post by Amit
Amit
Sent from my iPad
Post by Michael Powell
Haven't dealt much with Omni yet. A little with CORBA, mostly with WCF
and custom network layers.
I do work with ARM on a daily basis though. Floating point is an issue
on ARM, whether it is soft, hard, or softfp. We have soft I think.
Without addressing the ORB itself, could you work around it and custom
marshal, say a byte array (unsigned char) from your doubles?
That or possibly prefer floats to doubles. Or avoid floating point
altogether if you don't need them.
HTH
On Fri, Apr 19, 2013 at 6:11 AM, Johnny Willemsen
Hi,
Found the needed ARM documentation on the web. Looks TAO doesn't support the
mixed endian double on ARM. Amit, I would recommend you to run the ACE
tests/CDR_Array_Test on your target and see whether it works or not.
Best regards,
Johnny Willemsen
Remedy IT
http://www.theaceorb.nl
Post by Duncan Grisby
Post by Johnny Willemsen
I do have seen problems recently with TAO on ARM where endianess is
causing problems. What is the value you get on the TAO side? Have you
run the ACE/TAO test suite on the target?
Some ARMs have a bizarre mixed endian double, where the 64-bit double is
split into two 32-bit words in big-endian format but then the 32-bit
words are encoded in little-endian format.
omniORB has specific support for handling thes mixed endian doubles on
ARM. I don't know if TAO does, but I expect this is the cause of your
problem -- either you need to configure TAO to use mixed-endian doubles,
or TAO needs to grow support for them.
Cheers,
Duncan.
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
Johnny Willemsen
2013-05-01 10:42:29 UTC
Permalink
Hi,
Post by Amit Sharma
This is an update so that if anyone else runs into it might help them.
The latest version of ACE-TAO has this bug resolved.
My double type access works fine from python when talking to ARM target running ace-tao.
Thanks again for all the help
Ok, thanks for the update, so you can even remove your type access and
just use the plain types without problems?

Regards,

Johnny
Amit Sharma
2013-05-01 11:46:34 UTC
Permalink
Yes, plain types are ok.

Sent from my iPhone
Hi,
Post by Amit Sharma
This is an update so that if anyone else runs into it might help them.
The latest version of ACE-TAO has this bug resolved.
My double type access works fine from python when talking to ARM target running ace-tao.
Thanks again for all the help
Ok, thanks for the update, so you can even remove your type access and just use the plain types without problems?
Regards,
Johnny
Loading...