Hi, On Tue, Apr 24, 2018 at 4:10 PM, Nicholas Sauter wrote:

It was always the intention to support flex arrays in the absence of Numpy. If there is some refactoring to be done, this principle should be preserved: that Numpy is an optional rather than required dependency.

Good to know - some of this code seems a little crusty (and I've found a couple of bugs just trying to verify that it still works correctly). Not sure about the wording in your second sentence. At the time we

developed flex, branching was not a code development mechanism we used. Furthermore, not sure why you say Numpy is "exclusively" used in the flex constructors? Certainly there are numerous flex constructors that do not involve Numpy?

I meant a code branch e.g. "if", or a preprocessor "#ifdef" in this case. I think I've gotten confused by some of the indirection in the class definitions - the top level only adds the numpy constructor, and then everything else is put in several levels down - and in some of my tests it looked like the numpy routine was mistakenly doing all of the construction (which ended in much the same results). Nick

HI Rob I thought this rang a bell: https://github.com/cctbx/cctbx_project/issues/70 This same kind of issue? Cheers Graeme On 24 Apr 2018, at 17:43, Robert Oeffner mailto:[email protected]> wrote: Hi, I may be digressing here but my understanding is that newer versions of boost no longer contain the boost/python/numeric.hpp file and therefore the scitbx/array_family/boost_python/numpy_bridge.hpp cannot compile with newer versions of boost. I'm making very tiny steps compiling with the VS2017 compiler on Windows which I believe is required for C++11 compliance. So far the problem seems that older versions of boost do not like this compiler and scitbx (or rather numpy_bridge.hpp) do not like newer versions of boost. I guess that if numpy_bridge.hpp was adapted to not #include that would solve the problem. Rob On 24/04/2018 17:05, Nicholas Devenish wrote: Hi, On Tue, Apr 24, 2018 at 4:10 PM, Nicholas Sauter mailto:[email protected] mailto:[email protected]> wrote: It was always the intention to support flex arrays in the absence of Numpy. If there is some refactoring to be done, this principle should be preserved: that Numpy is an optional rather than required dependency. Good to know - some of this code seems a little crusty (and I've found a couple of bugs just trying to verify that it still works correctly). Not sure about the wording in your second sentence. At the time we developed flex, branching was not a code development mechanism we used. Furthermore, not sure why you say Numpy is "exclusively" used in the flex constructors? Certainly there are numerous flex constructors that do not involve Numpy? I meant a code branch e.g. "if", or a preprocessor "#ifdef" in this case. I think I've gotten confused by some of the indirection in the class definitions - the top level only adds the numpy constructor, and then everything else is put in several levels down - and in some of my tests it looked like the numpy routine was mistakenly doing all of the construction (which ended in much the same results). Nick _______________________________________________ cctbxbb mailing list [email protected]mailto:[email protected] http://phenix-online.org/mailman/listinfo/cctbxbb -- Robert Oeffner, Ph.D. Research Associate, The Read Group Department of Haematology, Cambridge Institute for Medical Research University of Cambridge Cambridge Biomedical Campus Wellcome Trust/MRC Building Hills Road Cambridge CB2 0XY www.cimr.cam.ac.uk/investigators/read/index.htmlhttp://www.cimr.cam.ac.uk/investigators/read/index.html tel: +44(0)1223 763234 _______________________________________________ cctbxbb mailing list [email protected]mailto:[email protected] http://phenix-online.org/mailman/listinfo/cctbxbb -- 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

Hmm actually looking cat ./scitbx/array_family/boost_python/numpy_bridge.hpp #include namespace scitbx { namespace af { namespace boost_python { #define SCITBX_LOC(pyname, ElementType) \ boost::python::object \ flex_##pyname##_as_numpy_array( \ ref > const& O, \ bool optional=false); \ \ versa >* \ flex_##pyname##_from_numpy_array( \ boost::python::numeric::array const& arr_obj); SCITBX_LOC(bool, bool) SCITBX_LOC(int, int) SCITBX_LOC(long, long) SCITBX_LOC(float, float) SCITBX_LOC(double, double) #define SCITBX_LOC2 std::complex<double> SCITBX_LOC(complex_double, SCITBX_LOC2) #undef SCITBX_LOC2 SCITBX_LOC(size_t, std::size_t) #undef SCITBX_LOC }}} // namespace scitbx::af::boost_python without so much leaning on preprocessor macros would probably make more sense, in my humble opinion (though is boiler plate) if we were to find a confident C++ expert would people be happy to have it rewritten to fit in with the numpy API in preference to the prehistoric numeric one (which went out like a decade ago?) (wider question) - does seem it would help out C++11 & Rob somewhat Cheers Graeme On 24 Apr 2018, at 21:40, Dr Robert Oeffner mailto:[email protected]> wrote: Yes this must be there same issue. numpy_bridge.hpp is only 27 lines of code. But I think it takes confident C++ expert to rewrite it. Rob Sent from my Windows 10 phone -- Robert Oeffner, Ph.D. Research Associate, The Read Group Department of Haematology, Cambridge Institute for Medical Research University of Cambridge Cambridge Biomedical Campus Wellcome Trust/MRC Building Hills Road Cambridge CB2 0XY www.cimr.cam.ac.uk/investigators/read/index.htmlhttp://www.cimr.cam.ac.uk/investigators/read/index.html tel: +44(0)1223 763234 mobile: +44(0)7712 887162 From: [email protected]mailto:[email protected] Sent: 24 April 2018 20:24 To: cctbx mailing listmailto:[email protected] Subject: Re: [cctbxbb] scitbx without numpy - still supported? HI Rob I thought this rang a bell: https://github.com/cctbx/cctbx_project/issues/70 This same kind of issue? Cheers Graeme On 24 Apr 2018, at 17:43, Robert Oeffner mailto:[email protected]mailto:[email protected]> wrote: Hi, I may be digressing here but my understanding is that newer versions of boost no longer contain the boost/python/numeric.hpp file and therefore the scitbx/array_family/boost_python/numpy_bridge.hpp cannot compile with newer versions of boost. I'm making very tiny steps compiling with the VS2017 compiler on Windows which I believe is required for C++11 compliance. So far the problem seems that older versions of boost do not like this compiler and scitbx (or rather numpy_bridge.hpp) do not like newer versions of boost. I guess that if numpy_bridge.hpp was adapted to not #include that would solve the problem. Rob On 24/04/2018 17:05, Nicholas Devenish wrote: Hi, On Tue, Apr 24, 2018 at 4:10 PM, Nicholas Sauter mailto:[email protected]mailto:[email protected] mailto:[email protected]> wrote: It was always the intention to support flex arrays in the absence of Numpy. If there is some refactoring to be done, this principle should be preserved: that Numpy is an optional rather than required dependency. Good to know - some of this code seems a little crusty (and I've found a couple of bugs just trying to verify that it still works correctly). Not sure about the wording in your second sentence. At the time we developed flex, branching was not a code development mechanism we used. Furthermore, not sure why you say Numpy is "exclusively" used in the flex constructors? Certainly there are numerous flex constructors that do not involve Numpy? I meant a code branch e.g. "if", or a preprocessor "#ifdef" in this case. I think I've gotten confused by some of the indirection in the class definitions - the top level only adds the numpy constructor, and then everything else is put in several levels down - and in some of my tests it looked like the numpy routine was mistakenly doing all of the construction (which ended in much the same results). Nick _______________________________________________ cctbxbb mailing list [email protected]mailto:[email protected]mailto:[email protected] http://phenix-online.org/mailman/listinfo/cctbxbb -- Robert Oeffner, Ph.D. Research Associate, The Read Group Department of Haematology, Cambridge Institute for Medical Research University of Cambridge Cambridge Biomedical Campus Wellcome Trust/MRC Building Hills Road Cambridge CB2 0XY www.cimr.cam.ac.uk/investigators/read/index.htmlhttp://www.cimr.cam.ac.uk/investigators/read/index.htmlhttp://www.cimr.cam.ac.uk/investigators/read/index.html tel: +44(0)1223 763234 _______________________________________________ cctbxbb mailing list [email protected]mailto:[email protected]mailto:[email protected] http://phenix-online.org/mailman/listinfo/cctbxbb -- 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]mailto:[email protected] http://phenix-online.org/mailman/listinfo/cctbxbb _______________________________________________ cctbxbb mailing list [email protected]mailto:[email protected] http://phenix-online.org/mailman/listinfo/cctbxbb