Morning all
I would think putting the content directly onto the giithub page perhaps at
https://github.com/cctbx/cctbx_project/wiki
could be the way to go - a copy / paste job would still put us in a better position than we are now (assuming whatever commands are in there still work)
James - FWIW the tests I run are
libtbx.run_tests_parallel \
run_in_tmp_dir=true \
module=xia2 module=cctbx module=rstbx module=dxtbx module=dials \
module=dials_regression \
nproc=6
this should work for you… though you probably don’t want to bother with xia2 tests
Best wishes Graeme
On 6 Apr 2017, at 06:14, Pavel Afonine mailto:[email protected]> wrote:
Excellent idea! Let's do it! Who is in capacity to do it? Or shell we make a round or reading the document and updating it up to current realities?
Pavel
On 4/6/17 11:55, Paul Adams wrote:
To Pavel’s comment. Now that we have a new location for cctbx maybe we can add this document somewhere prominent on the web site.
On Apr 5, 2017, at 8:00 PM, Pavel Afonine mailto:[email protected]> wrote:
Not sure if that answers your questions but once upon a time we here at Berkeley tried to write a some sort of document that was supposed to answer questions like this. Attached. By no means it is complete, up-to-date, etc, but it might be worth reading for anyone who contributes to cctbx. (Even not sure if I'm sending the latest version).
Unfortunately, nobody bothered to put it in some central place.
Pavel
On 4/6/17 10:51, James Holton wrote:
Hey Billy,
On a related note. How do I run these regression tests before committing something into Git? Is there a document on dials regression testing I can't find?
-James
On Apr 5, 2017, at 3:38 PM, Billy Poon mailto:[email protected]> wrote:
Hi all,
I tested Boost 1.56 on our buildbot servers and got some new test failures with
cctbx_project/scitbx/array_family/boost_python/tst_flex.py
cctbx_project/scitbx/random/tests/tst_random.py
The full log for CentOS 6 can be found at
http://cci-vm-6.lbl.gov:8010/builders/phenix-nightly-intel-linux-2.6-x86_64-...
It looks like the errors are related to random number generation. For a given seed, would the sequence of numbers change when Boost is changed? I did a diff between Boost 1.56 and the current Boost and could not see any changes that immediately stood out as being related to random numbers.
Are these tests failing for others as well?
--
Billy K. Poon
Research Scientist, Molecular Biophysics and Integrated Bioimaging
Lawrence Berkeley National Laboratory
1 Cyclotron Road, M/S 33R0345
Berkeley, CA 94720
Tel: (510) 486-5709
Fax: (510) 486-5909
Web: https://phenix-online.org
On Wed, Apr 5, 2017 at 8:12 AM, Charles Ballard wrote:
FYI, we (CCP4) have been using 1.56 for building cctbx/phaser/dials for the last while with no issues. Don't know about 1.60, but 1.59 causes issues with the boost python make_getter and make_setter (initialisation of none const reference if the passed type is a temporary).
Charles
On 3 Apr 2017, at 14:31, Luc Bourhis wrote:
Hi all,
everybody seemed to agree but then it was proposed to move straight to Boost 1.60, and this caused troubles. Could we consider again to move to at least 1.56? As far as I can tell, this does not cause any issue and as stated one year ago, it would help me and Olex 2.
Thanks,
Luc
On 10 Feb 2016, at 15:17, Nicholas Sauter wrote:
Nigel, Billy & Aaron,
I completely endorse this move to Boost 1.56. Can we update our build?
Nick
Nicholas K. Sauter, Ph. D.
Computer Staff Scientist, Molecular Biophysics and Integrated Bioimaging Division
Lawrence Berkeley National Laboratory
1 Cyclotron Rd., Bldg. 33R0345
Berkeley, CA 94720
(510) 486-5713
On Wed, Feb 10, 2016 at 2:41 PM, Luc Bourhis wrote:
Hi,
I have improvements to the smtbx on their way to be committed which require Boost version 1.56. This is related to Boost.Threads, whose support I re-activated a few months ago on Nick’s request. I need the function boost::thread::physical_concurrency which returns the number of physical cores on the machine, as opposed to virtual cores when hyperthreading is enabled (which it is by default on any Intel machine). That function is not available in Boost 1.55 which is the version currently used in the nightly tests: it appeared in 1.56.
So, would it be possible to move to Boost 1.56? Otherwise, I will need to backport that function. Not too difficult but not thrilling.
Best wishes,
Luc
_______________________________________________
cctbxbb mailing list
[email protected]
http://phenix-online.org/mailman/listinfo/cctbxbb
_______________________________________________
cctbxbb mailing list
[email protected]
http://phenix-online.org/mailman/listinfo/cctbxbb
_______________________________________________
cctbxbb mailing list
[email protected]
http://phenix-online.org/mailman/listinfo/cctbxbb
_______________________________________________
cctbxbb mailing list
[email protected]
http://phenix-online.org/mailman/listinfo/cctbxbb
_______________________________________________
cctbxbb mailing list
[email protected]
http://phenix-online.org/mailman/listinfo/cctbxbb
_______________________________________________
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
_______________________________________________
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