boost python conversions help needed
Hi All, In the branch https://github.com/cctbx/cctbx_project/tree/fixed-width-int-types I am working to add a full range of fixed-width integer types to allow explicit reading of binary data without conversion from images (amongst other things) - mostly I’ve got something _working_ but tests fail because stdout / err contains Standard error: /Users/graeme/svn/cctbx/conda_base/python.app/Contents/lib/python3.6/importlib/_bootstrap.py:219: RuntimeWarning: to-Python converter for scitbx::af::shared<unsigned int> already registered; second conversion method ignored. has anyone got any hints where these may be registered? The details of the low level flex implementation seems to be minimally documented, and the error has no useful stack trace, so I am at a bit of a loss as to where the other unsigned int conversion is registered. Some pointers from someone who has delved into these in the past would be welcome - I have spent a couple days trying to find what I am doing wrong and have so far failed - hopefully someone on the list knows their way around in here Cheers Graeme -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
<bump>
Does anyone know about this stuff or am I on my own here?
Alternative of using numpy arrays to do the job has been suggested but would prefer keeping in the cctbx ecosystem
Thanks Graeme
On 28 Sep 2020, at 07:15, Winter, Graeme (DLSLtd,RAL,LSCI)
Hi Graeme, I am not sure how useful this is going to be, but here are two strategies to deal with this scenario: 1. You can query the Python converter registry to see that a converter for a particular type has been registered, e.g. as it is done here: https://github.com/cctbx/cctbx_project/blob/fcff45919ee0b5cdf9f12cc9ea9d2f9e... This is useful when you want to export something with a particular name, but share the implementation with something pre-existing (e.g. size_t being uint64). 2. You can uniquify the types you are exporting, e.g. as it is done here : https://github.com/cctbx/cctbx_project/blob/fcff45919ee0b5cdf9f12cc9ea9d2f9e... This is useful when you want to export a unique list, but the uniqueness depends on e.g. the architecture, as for size_t. Unfortunately, these are only useful when exports are centralised, as unconditional class_ statements will cause the same warning to be emitted. BW, Gabor On Wed, Sep 30, 2020 at 6:30 AM Winter, Graeme (DLSLtd,RAL,LSCI) < [email protected]> wrote:
<bump>
Does anyone know about this stuff or am I on my own here?
Alternative of using numpy arrays to do the job has been suggested but would prefer keeping in the cctbx ecosystem
Thanks Graeme
On 28 Sep 2020, at 07:15, Winter, Graeme (DLSLtd,RAL,LSCI) < [email protected]> wrote:
Hi All,
In the branch
https://github.com/cctbx/cctbx_project/tree/fixed-width-int-types
I am working to add a full range of fixed-width integer types to allow explicit reading of binary data without conversion from images (amongst other things) - mostly I’ve got something _working_ but tests fail because stdout / err contains
Standard error:
/Users/graeme/svn/cctbx/conda_base/python.app/Contents/lib/python3.6/importlib/_bootstrap.py:219: RuntimeWarning: to-Python converter for scitbx::af::shared<unsigned int> already registered; second conversion method ignored.
has anyone got any hints where these may be registered?
The details of the low level flex implementation seems to be minimally documented, and the error has no useful stack trace, so I am at a bit of a loss as to where the other unsigned int conversion is registered.
Some pointers from someone who has delved into these in the past would be welcome - I have spent a couple days trying to find what I am doing wrong and have so far failed - hopefully someone on the list knows their way around in here
Cheers Graeme
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
_______________________________________________ cctbxbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb
Hi Gabor,
Thanks for this - seems you’re on the right track here & by commenting out
wrap_flex_uint16_t();
//wrap_flex_uint32_t();
wrap_flex_int64_t();
wrap_flex_uint64_t();
the errors go away… now I need to figure what is aliasing uint32_t as a size_t is 64 bit … however this has now given me a hook into the mystery
Will look some more at this registry and what is going on in here…
Much thanks for this assistance!
All the best Graeme
On 30 Sep 2020, at 09:59, Gabor Bunkoczi
Is it just this one case? If so, it's probably wrap_flex_size_t() and wrap_flex_uint64_t - on 64-bit operating systems size_t is just an alias for uint64_t.
________________________________
From: [email protected]
participants (3)
-
Gabor Bunkoczi
-
Tristan Croll
-
Winter, Graeme (DLSLtd,RAL,LSCI)