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.html
tel: +44(0)1223 763234
mobile: +44(0)7712 887162
From: [email protected]
Sent: 24 April 2018 20:24
To: cctbx mailing list
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 <[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 <numeric.hpp> 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 <[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]>
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.html<http://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
_______________________________________________
cctbxbb mailing list
http://phenix-online.org/mailman/listinfo/cctbxbb