<div dir="ltr">Hi Graeme,<div><br></div><div>I am not sure how useful this is going to be, but here are two strategies to deal with this scenario:</div><div><br></div><div>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:</div><div><br></div><div><a href="https://github.com/cctbx/cctbx_project/blob/fcff45919ee0b5cdf9f12cc9ea9d2f9efa9a0681/boost_adaptbx/boost_range_python.hpp#L23">https://github.com/cctbx/cctbx_project/blob/fcff45919ee0b5cdf9f12cc9ea9d2f9efa9a0681/boost_adaptbx/boost_range_python.hpp#L23</a></div><div> </div><div>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).</div><div><br></div><div>2. You can uniquify the types you are exporting, e.g. as it is done here :</div><div><br></div><div><a href="https://github.com/cctbx/cctbx_project/blob/fcff45919ee0b5cdf9f12cc9ea9d2f9efa9a0681/boost_adaptbx/exporting.hpp#L56">https://github.com/cctbx/cctbx_project/blob/fcff45919ee0b5cdf9f12cc9ea9d2f9efa9a0681/boost_adaptbx/exporting.hpp#L56</a><br></div><div><br></div><div>This is useful when you want to export a unique list, but the uniqueness depends on e.g. the architecture, as for size_t.</div><div><br></div><div>Unfortunately, these are only useful when exports are centralised, as unconditional class_ statements will cause the same warning to be emitted.</div><div><br></div><div>BW, Gabor</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 30, 2020 at 6:30 AM Winter, Graeme (DLSLtd,RAL,LSCI) <<a href="mailto:Graeme.Winter@diamond.ac.uk">Graeme.Winter@diamond.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;">
<bump>
<div><br>
</div>
<div>Does anyone know about this stuff or am I on my own here?</div>
<div><br>
</div>
<div>Alternative of using numpy arrays to do the job has been suggested but would prefer keeping in the cctbx ecosystem</div>
<div><br>
</div>
<div>Thanks Graeme<br>
<div><br>
<blockquote type="cite">
<div>On 28 Sep 2020, at 07:15, Winter, Graeme (DLSLtd,RAL,LSCI) <<a href="mailto:graeme.winter@diamond.ac.uk" target="_blank">graeme.winter@diamond.ac.uk</a>> wrote:</div>
<br>
<div>
<div style="overflow-wrap: break-word;">
Hi All,
<div><br>
</div>
<div>In the branch </div>
<div><br>
</div>
<div><a href="https://github.com/cctbx/cctbx_project/tree/fixed-width-int-types" target="_blank">https://github.com/cctbx/cctbx_project/tree/fixed-width-int-types</a></div>
<div><br>
</div>
<div>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</div>
<div><br>
</div>
<div> Standard error:<br>
/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.</div>
<div><br>
</div>
<div>has anyone got any hints where these may be registered?</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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</div>
<div><br>
</div>
<div>Cheers Graeme</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<p align="justify"> </p>
<p align="justify">-- </p>
<p align="justify">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.<br>Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. <br>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.<br>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<br> </p></div>
_______________________________________________<br>
cctbxbb mailing list<br>
<a href="mailto:cctbxbb@phenix-online.org" target="_blank">cctbxbb@phenix-online.org</a><br>
<a href="http://phenix-online.org/mailman/listinfo/cctbxbb" rel="noreferrer" target="_blank">http://phenix-online.org/mailman/listinfo/cctbxbb</a><br>
</blockquote></div>