[cctbxbb] boost python conversions help needed

[Gabor Bunkoczi]

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/fcff45919ee0b5cdf9f12cc9ea9d2f9efa9a0681/boost_adaptbx/boost_range_python.hpp#L23

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/fcff45919ee0b5cdf9f12cc9ea9d2f9efa9a0681/boost_adaptbx/exporting.hpp#L56

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) <
Graeme.Winter at diamond.ac.uk> 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) <
> graeme.winter at diamond.ac.uk> 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
> cctbxbb at phenix-online.org
> http://phenix-online.org/mailman/listinfo/cctbxbb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/cctbxbb/attachments/20200930/60f53aa1/attachment.htm>