[omniORB] CORBA::Double type corrouption issue in python omniORB

[Michael Powell]

That is excellent news. Glad I could help you navigate through it.

On Tue, Apr 30, 2013 at 6:26 PM, Amit Sharma <amitrksharma at gmail.com> wrote:
> 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
>
> On Apr 19, 2013, at 8:51 PM, Michael Powell <mwpowellhtx at gmail.com> wrote:
>
>> 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.
>>
>> On Fri, Apr 19, 2013 at 8:32 PM, Amit <amitrksharma at gmail.com> wrote:
>>> 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
>>>
>>> On Apr 19, 2013, at 8:10 AM, Johnny Willemsen <jwillemsen at remedy.nl> wrote:
>>>
>>>> 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
>>>>
>>>> On 04/19/2013 02:46 PM, Johnny Willemsen wrote:
>>>>> Hi,
>>>>>
>>>>>>   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
>>>>>
>>>>>>
>>>>>> Amit
>>>>>>
>>>>>> Sent from my iPad
>>>>>>
>>>>>> On Apr 19, 2013, at 7:21 AM, Michael Powell <mwpowellhtx at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> 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
>>>>>>> <jwillemsen at remedy.nl> wrote:
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>> On 04/19/2013 10:57 AM, Duncan Grisby wrote:
>>>>>>>>>
>>>>>>>>> On Fri, 2013-04-19 at 08:57 +0200, Johnny Willemsen wrote:
>>>>>>>>>
>>>>>>>>>> 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