[cctbxbb] scitbx without numpy - still supported?

Tue Apr 24 13:40:01 PDT 2018

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: Graeme.Winter at diamond.ac.uk
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 <rdo20 at cam.ac.uk<mailto:rdo20 at cam.ac.uk>> 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 <nksauter at lbl.gov<mailto:nksauter at lbl.gov> <mailto:nksauter at lbl.gov>> 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
cctbxbb at phenix-online.org<mailto:cctbxbb at phenix-online.org>
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
cctbxbb at phenix-online.org<mailto:cctbxbb at phenix-online.org>
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
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/20180424/e6bd81d6/attachment.htm>