- cctbxbb - phenix-online.org

Race condition in bootstrap python installation
by markus.gerstel＠diamond.ac.uk 27 May '15

27 May '15

We have recently seen intermittent build failures with the bootstrap base installation at Diamond. These all occurred during the compilation of python and were usually of the form : gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Wl,-rpath=\$ORIGIN/../lib Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/pgenmain.o -lpthread -ldl -lutil -o Parser/pgen : Parser/node.o: file not recognized: File truncated : collect2: ld returned 1 exit status : make[1]: *** [Parser/pgen] Error 1 : make[1]: Leaving directory `/scratch/jenkins_slave/workspace/dials_bootstrap_platforms/compilationtarget/native/label/dials-ws154/build_dials/base_tmp/Python-2.7.8_cci' : make: *** [Include/graminit.h] Error 2 : make: *** Waiting for unfinished jobs.... Traceback (most recent call last): File "modules/cctbx_project/libtbx/auto_build/install_base_packages.py", line 1194, in <module> installer(args=sys.argv, log=sys.stdout) File "modules/cctbx_project/libtbx/auto_build/install_base_packages.py", line 184, in __init__ self.build_dependencies(packages=packages) File "modules/cctbx_project/libtbx/auto_build/install_base_packages.py", line 571, in build_dependencies getattr(self, 'build_%s'%i)() File "modules/cctbx_project/libtbx/auto_build/install_base_packages.py", line 622, in build_python self.call('make -j %s install'%(self.nproc), log=log, cwd=python_dir) File "modules/cctbx_project/libtbx/auto_build/install_base_packages.py", line 264, in call return call(args, log=log, verbose=self.verbose, **kwargs) File "/scratch/jenkins_slave/workspace/dials_bootstrap_platforms/compilationtarget/native/label/dials-ws154/build_dials/modules/cctbx_project/libtbx/auto_build/installer_utils.py", line 81, in call raise RuntimeError("Call to '%s' failed with exit code %d" % (args, rc)) RuntimeError: Call to 'make -j 4 install' failed with exit code 2 Other indicated errors are /usr/bin/ld: final link failed: File truncated or /usr/bin/ld: can not read symbols: File truncated I suspect that these errors are manifestations of a race condition in the python build process, which the bootstrap script now by default runs with a -j 4 parallel make. To test this we are now using --nproc=1 for the base installation step. We haven't seen these build failures since. I suggest we set the python compilation to never run with parallel make. Any other ideas? -Markus -- 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

2 2

Native python unittests for the libtbx testing framework
by markus.gerstel＠diamond.ac.uk 19 May '15

19 May '15

Dear cctbx developers and users, For a side-project of mine I experimented with native python unit tests (some information available on https://docs.python.org/2/library/unittest.html if you are not familiar with it). The python unittest framework has a couple of advantages over the libtbx testing world. I found that the two most immediate advantages are: Automated test discovery. There is no need to keep a complete list of test files in another python file, which is what we currently do in run_tests.py. Multiple test functions per python test file. At the moment we can run multiple tests via command line parameters to the python test files. This of course means that you need to keep a list of '(test file, parameter)' tuples in run_tests.py, and you need some boilerplate dispatcher in your test file. This can lead to two situations: you may have a number of tests with numeric parameters, and no one knows what the parameters stand for. One example of this can be found in DIALS, where tst_index.py is run with numeric parameters 1 to 4 and 7 to 15, but not 5 and 6. The alternative situation is that you end up with a massive test file, that tests the entire class under test, but figuring out what specifically went wrong is probably more time consuming than necessary. In contrast in Python unittests any function in the file that is named test_* will be identified and run as a separate test. I find that this automatically leads to smaller and thus more readable tests. I understand that libtbx has been developed before Python unittest was around, that there is a substantial amount of code around that relies on current libtbx behaviour, and that there is no pressing need to change anything. However I would like to be able to take advantage of the tools that are out there, so I wrote a function that uses Python unittest for test discovery, and can be placed in run_tests.py. With this function you can then use regular Python unittests and run them with either through libtbx, with the python unittest tools, or directly. In each case you end up with the test results reported in the way you would expect. What I would like to do is integrate this logic in libtbx directly, so that we can use it for all cctbx modules. Since it does not modify libtbx default behaviour and only becomes active after a change in the run_tests.py of the relevant module it should be fully backwards compatible with virtually no downsides. What do you think? -Markus run_tests.py previously: (..) tst_list = ( "$D/test/algorithms/profile_model/nave/tst_model.py", ) (..) run_tests.py new: (..) tst_list = ( "$D/test/algorithms/profile_model/nave/tst_model.py", ) + discover_unittests("dlstbx") (..) discover_unittests function: def discover_unittests(module, pattern='tst_*.py'): try: import inspect import os import sys import unittest except: return tuple([]) dist_dir = libtbx.env.dist_path(module) found_tests = unittest.defaultTestLoader.discover(dist_dir, pattern=pattern) def recursive_TestSuite_to_list(suite): list = [] for t in suite: if isinstance(t, unittest.TestSuite): list.extend(recursive_TestSuite_to_list(t)) elif isinstance(t, unittest.TestCase): module = t.__class__.__module__ if module == 'unittest.loader': # This indicates a loading error. # Regenerate file name and try to run file directly. path = t._testMethodName.replace('.', os.path.sep) list.append("$D/%s.py" % path) else: module = inspect.getsourcefile(sys.modules[module]) function = "%s.%s" % (t.__class__.__name__, t._testMethodName) list.append([module, function]) else: raise Exception("Unknown test object (%s)" % t) return list test_list = recursive_TestSuite_to_list(found_tests) return tuple(test_list) -- 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

3 2

Re: [cctbxbb] Native python unittests for the libtbx testing framework
by Jan Marten Simons 19 May '15

19 May '15

Am Freitag 15 Mai 2015 18:07:33 schrieb Pavel Afonine: > Hi Markus, > > lucky you, I wish I have time for side projects! > > I've been working on cctbx (and writing tests!) for the past 12 years > and can't name any problem using "libtbx testing world". Most tests are > written this way. Why I am not so keen to use an alternative? > - why introduce inconsistency for no obvious clear pressing reasons; > - I have no spare time to learn and get used to an alternative > framework (again, for no obvious clear pressing reason); > - some rare developers (mostly postdocs that come and go) used > Python test framework in the past on the code that I work too and that I > have to maintain when people are gone. I find it is an irritating > overhead for me dealing with these tests, so typically I bother to > re-write them to use libtbx tools. Hi Pavel, those are sound and valid reasons from your point of view. But please also consider this alternative view: Coming from other python projects people are likely to have experience with the python unit test framework. As cctbx is using its own testing functionality people might be put off from writing tests or at least have to overcome this additional barrier on entry. I'm a strong supporter of sticking/moving to standards like PEP0008 [1] or pip/whl* based installs as conforming to those helps people to quickly find their way into the code. * wouldn't it be great if one could simply tell people this: "To install cctbx simply type 'pip install cctbx' in your terminal."? [1] https://www.python.org/dev/peps/pep-0008/ With regards, Dipl. Phys. Jan M. Simons Institute of Crystallography RWTH Aachen University

4 3

Re: [cctbxbb] Fw: Build constraints in SConscript?
by Graeme.Winter＠diamond.ac.uk 15 May '15

15 May '15

Nigel If you export the environment variable I sent before before kicking off a build you should make fully portable binaries. We've been doing this in dials for a while. Best wishes Graeme On 15 May 2015 18:00, Nigel Moriarty <nwmoriarty(a)lbl.gov> wrote: Greame Did you try replacing 10.8 in the SConscript file with 10.7? Please do so and let me know if this works. I was working on getting the mechanism to be OS specific on the buildbot and bootstrap when Rob solved the problem independently. If you don't tell me if changing 10.8 to 10.7 works I will do something to get it working here and we can worry about your 2011 vintage OS next week. Cheers Nigel --- Nigel W. Moriarty Building 64R0246B, Physical Biosciences Division Lawrence Berkeley National Laboratory Berkeley, CA 94720-8235 Phone : 510-486-5709 Email : NWMoriarty(a)LBL.gov Fax : 510-486-5909 Web : CCI.LBL.gov<http://CCI.LBL.gov> On Fri, May 15, 2015 at 2:31 AM, <Graeme.Winter(a)diamond.ac.uk<mailto:[email protected]>> wrote: Dear Rob Given that the tests are currently not working right anyway, and there are no build / deployment tests for testing builds on an older version of OS X than they are compiled on, this is an easy problem to get in to. It's also a collaborative project where we're all working hard on making things work. This will happen from time to time. I had thought the same environment variable based mechanism for the builds was already in place for PHENIX - am surprised it is not! So, no worries. Perhaps I came across more grumpy than I meant to below. Occurs to me it would be very handy to have one email address for all cctbx related developers where (someone) could ask (something like this) and get an answer perhaps suggesting a more optimum solution? Thoughts anyone? (lots of mail lists in send: list!) Thanks & best wishes Graeme -----Original Message----- From: R.D. Oeffner [mailto:[email protected]<mailto:[email protected]>] Sent: 15 May 2015 10:26 To: Winter, Graeme (DLSLtd,RAL,LSCI); cctbxbb(a)phenix-online.org<mailto:[email protected]>; dials-support(a)lists.sourceforge.net<mailto:[email protected]>; dials-dev(a)cci.lbl.gov<mailto:[email protected]>; Nigel W Moriarty Subject: Re: Fw: Build constraints in SConscript? Dear Graeme, I'm sorry for the trouble my change caused and the time taken to identify it. Ironically we had the same issue as you with Phenix not installing on anything lower than OSX 10.9. As nothing appeared to be specified in our build system to that effect my change was a quick fix to address the problem. It was genuinely well intended. Nigel, I defer to you for implementing the minimum OSX platform for Phenix builds. Rob > FROM: Graeme.Winter(a)Diamond.ac.uk<mailto:[email protected]> > SENT: Friday, May 15, 2015 9:09 AM > TO: Graeme.Winter(a)Diamond.ac.uk<mailto:[email protected]> ; cctbxbb(a)phenix-online.org<mailto:[email protected]> ; > robert(a)oeffner.net<mailto:[email protected]> > CC: dials-support(a)lists.sourceforge.net<mailto:[email protected]> ; dials-dev(a)cci.lbl.gov<mailto:[email protected]> > SUBJECT: RE: Build constraints in SConscript? > > [gw56@ws133 libtbx]$ svn commit -m "Reverting with extreme prejudice > hard coded 10.8 requirement, build no longer works on 10.7 and > earlier; please use ENV VAR method to achieve this kind of constraint; > reverted revision=22202" SConscript > > Sending SConscript > > Transmitting file data . > > Committed revision 22223. > > Please use MACOSX_DEPLOYMENT_TARGET=(version) locally for your > personal requirement, export this before kicking off bootstrap.py > > Best wishes Graeme > > ==================== DIFFS FOLLOW ==================== > > Revision: 22223 > http://sourceforge.net/p/cctbx/code/22223 [1] > Author: graeme_winter > Date: 2015-05-15 08:06:10 +0000 (Fri, 15 May 2015) > Log Message: > ----------- > Reverting with extreme prejudice hard coded 10.8 requirement, build no > longer works on 10.7 and earlier; please use ENV VAR method to achieve > this kind of constraint; reverted revision=22202 > > Modified Paths: > -------------- > trunk/libtbx/SConscript > > Modified: trunk/libtbx/SConscript > =================================================================== > --- trunk/libtbx/SConscript 2015-05-15 02:13:42 UTC (rev 22222) > +++ trunk/libtbx/SConscript 2015-05-15 08:06:10 UTC (rev 22223) > @@ -803,7 +803,7 @@ > env_etc.static_libraries = 1 > env_etc.static_bpl = 0 > > - link_flags = ["-w", "-mmacosx-version-min=10.8"] # suppress > "source/lib does not exist" warning > + link_flags = ["-w"] # suppress "source/lib does not exist" warning > if libtbx.env.build_options.force_32bit: > if (env_etc.gcc_version and env_etc.gcc_version >= 40201) or > env_etc.clang_version: > link_flags.extend(["-arch", "i386"]) > @@ -811,8 +811,7 @@ > env_etc.c_link = "cc" > env_etc.ccflags_base = [ > "-fPIC", > - "-fno-strict-aliasing", > - "-mmacosx-version-min=10.8"] > + "-fno-strict-aliasing"] > if env_etc.clang_version: > setup_clang_warning(env_etc, libtbx.env.build_options.warning_level) > else: > @@ -828,7 +827,7 @@ > env_etc.ccflags_base.extend(["-no-cpp-precomp"]) > if (env_etc.gcc_version < 40201): > env_etc.ccflags_base.append("-Wno-long-double") > - env_etc.cxxflags_base = ["-mmacosx-version-min=10.8"] > + env_etc.cxxflags_base = [] > if env_etc.clang_version is None and env_etc.gcc_version < 40000: > env_etc.cxxflags_base.append("-fcoalesce-templates") > env_etc.cxxflags_base.append("-DBOOST_ALL_NO_LIB") > @@ -861,11 +860,10 @@ > if env_etc.apple_gcc_builds.gcc < 5646: > # fixed on 10.6 (Snow Leopard) whose Dev Tools start with that build > opts.insert(0, "-gstabs+") > - env_etc.shlinkflags = ["-mmacosx-version-min=10.8"] > + env_etc.shlinkflags = [] > env_etc.shlinkflags_bpl = [ > "-w", # suppress "source/lib does not exist" warning > - "-bundle", "-mmacosx-version-min=10.8", > - "-undefined", "dynamic_lookup"] > + "-bundle", "-undefined", "dynamic_lookup"] > if libtbx.env.build_options.force_32bit: > if (env_etc.gcc_version and env_etc.gcc_version >= 40201) or > env_etc.clang_version: > env_etc.ccflags_base.extend(["-arch", "i386"]) > > FROM: Graeme.Winter(a)diamond.ac.uk<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] > > SENT: 15 May 2015 09:01 > TO: cctbxbb(a)phenix-online.org<mailto:[email protected]>; robert(a)oeffner.net<mailto:[email protected]> > CC: dials-support(a)lists.sourceforge.net<mailto:[email protected]>; dials-dev(a)cci.lbl.gov<mailto:[email protected]> > SUBJECT: Build constraints in SConscript? > > Hi Folks > > A while back we worked on making DIALS work right built on 10.10 but > executed on 10.6 or later – this is very useful as lots of people > have 10.6/7 macs & are not keen to update. This is done by the very > flexible mechanism of exporting an environment variable prior to > compilation > > Then this commit appears > > env_etc.static_bpl = 0 > @@ -802,7 +803,7 @@ > env_etc.static_libraries = 1 > env_etc.static_bpl = 0 > > - link_flags = ["-w"] # suppress "source/lib does not exist" warning > + link_flags = ["-w", "-mmacosx-version-min=10.8"] # suppress > "source/lib does not exist" warning > if libtbx.env.build_options.force_32bit: > if (env_etc.gcc_version and env_etc.gcc_version >= 40201) or > env_etc.clang_version: > link_flags.extend(["-arch", "i386"]) > @@ -810,7 +811,8 @@ > env_etc.c_link = "cc" > env_etc.ccflags_base = [ > "-fPIC", > - "-fno-strict-aliasing"] > + "-fno-strict-aliasing", > + "-mmacosx-version-min=10.8"] > if env_etc.clang_version: > setup_clang_warning(env_etc, libtbx.env.build_options.warning_level) > else: > @@ -826,7 +828,7 @@ > env_etc.ccflags_base.extend(["-no-cpp-precomp"]) > if (env_etc.gcc_version < 40201): > env_etc.ccflags_base.append("-Wno-long-double") > - env_etc.cxxflags_base = [] > + env_etc.cxxflags_base = ["-mmacosx-version-min=10.8"] > if env_etc.clang_version is None and env_etc.gcc_version < 40000: > env_etc.cxxflags_base.append("-fcoalesce-templates") > env_etc.cxxflags_base.append("-DBOOST_ALL_NO_LIB") > @@ -859,10 +861,10 @@ > > to > > Modified Paths: > -------------- > trunk/libtbx/SConscript > > and now our build no longer works on 10.7. This is *REALLY* annoying. > The head of the commit message follows below. > > Please could someone fix this? The environment variable method is > *FAR* better, works for the dependencies and also allows dials to work > on older machines. You broke our build. Before this it worked fine. > > (we can’t automate this test as we are not supposed to deploy out of > support machines on lab network, so this was missed) > > Thanks Graeme > > EFFNER > > to cctbx-cvs > > May 13 > > Revision: 22202 > http://sourceforge.net/p/cctbx/code/22202 [2] > Author: oeffner > Date: 2015-05-13 15:48:24 +0000 (Wed, 13 May 2015) > Log Message: > ----------- > ensure installers can run on MacOSX 10.8 or higher > > -- > > 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 > > No virus found in this message. > Checked by AVG - www.avg.com<http://www.avg.com> [3] > Version: 2015.0.5941 / Virus Database: 4342/9780 - Release Date: > 05/15/15 > > Links: > ------ > [1] http://sourceforge.net/p/cctbx/code/22223 > [2] http://sourceforge.net/p/cctbx/code/22202 > [3] http://www.avg.com -- 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

1 0

Re: [cctbxbb] Fw: Build constraints in SConscript?
by Graeme.Winter＠diamond.ac.uk 15 May '15

15 May '15

Dear Rob Given that the tests are currently not working right anyway, and there are no build / deployment tests for testing builds on an older version of OS X than they are compiled on, this is an easy problem to get in to. It's also a collaborative project where we're all working hard on making things work. This will happen from time to time. I had thought the same environment variable based mechanism for the builds was already in place for PHENIX - am surprised it is not! So, no worries. Perhaps I came across more grumpy than I meant to below. Occurs to me it would be very handy to have one email address for all cctbx related developers where (someone) could ask (something like this) and get an answer perhaps suggesting a more optimum solution? Thoughts anyone? (lots of mail lists in send: list!) Thanks & best wishes Graeme -----Original Message----- From: R.D. Oeffner [mailto:[email protected]] Sent: 15 May 2015 10:26 To: Winter, Graeme (DLSLtd,RAL,LSCI); cctbxbb(a)phenix-online.org; dials-support(a)lists.sourceforge.net; dials-dev(a)cci.lbl.gov; Nigel W Moriarty Subject: Re: Fw: Build constraints in SConscript? Dear Graeme, I'm sorry for the trouble my change caused and the time taken to identify it. Ironically we had the same issue as you with Phenix not installing on anything lower than OSX 10.9. As nothing appeared to be specified in our build system to that effect my change was a quick fix to address the problem. It was genuinely well intended. Nigel, I defer to you for implementing the minimum OSX platform for Phenix builds. Rob > FROM: Graeme.Winter(a)Diamond.ac.uk > SENT: Friday, May 15, 2015 9:09 AM > TO: Graeme.Winter(a)Diamond.ac.uk ; cctbxbb(a)phenix-online.org ; > robert(a)oeffner.net > CC: dials-support(a)lists.sourceforge.net ; dials-dev(a)cci.lbl.gov > SUBJECT: RE: Build constraints in SConscript? > > [gw56@ws133 libtbx]$ svn commit -m "Reverting with extreme prejudice > hard coded 10.8 requirement, build no longer works on 10.7 and > earlier; please use ENV VAR method to achieve this kind of constraint; > reverted revision=22202" SConscript > > Sending SConscript > > Transmitting file data . > > Committed revision 22223. > > Please use MACOSX_DEPLOYMENT_TARGET=(version) locally for your > personal requirement, export this before kicking off bootstrap.py > > Best wishes Graeme > > ==================== DIFFS FOLLOW ==================== > > Revision: 22223 > http://sourceforge.net/p/cctbx/code/22223 [1] > Author: graeme_winter > Date: 2015-05-15 08:06:10 +0000 (Fri, 15 May 2015) > Log Message: > ----------- > Reverting with extreme prejudice hard coded 10.8 requirement, build no > longer works on 10.7 and earlier; please use ENV VAR method to achieve > this kind of constraint; reverted revision=22202 > > Modified Paths: > -------------- > trunk/libtbx/SConscript > > Modified: trunk/libtbx/SConscript > =================================================================== > --- trunk/libtbx/SConscript 2015-05-15 02:13:42 UTC (rev 22222) > +++ trunk/libtbx/SConscript 2015-05-15 08:06:10 UTC (rev 22223) > @@ -803,7 +803,7 @@ > env_etc.static_libraries = 1 > env_etc.static_bpl = 0 > > - link_flags = ["-w", "-mmacosx-version-min=10.8"] # suppress > "source/lib does not exist" warning > + link_flags = ["-w"] # suppress "source/lib does not exist" warning > if libtbx.env.build_options.force_32bit: > if (env_etc.gcc_version and env_etc.gcc_version >= 40201) or > env_etc.clang_version: > link_flags.extend(["-arch", "i386"]) > @@ -811,8 +811,7 @@ > env_etc.c_link = "cc" > env_etc.ccflags_base = [ > "-fPIC", > - "-fno-strict-aliasing", > - "-mmacosx-version-min=10.8"] > + "-fno-strict-aliasing"] > if env_etc.clang_version: > setup_clang_warning(env_etc, libtbx.env.build_options.warning_level) > else: > @@ -828,7 +827,7 @@ > env_etc.ccflags_base.extend(["-no-cpp-precomp"]) > if (env_etc.gcc_version < 40201): > env_etc.ccflags_base.append("-Wno-long-double") > - env_etc.cxxflags_base = ["-mmacosx-version-min=10.8"] > + env_etc.cxxflags_base = [] > if env_etc.clang_version is None and env_etc.gcc_version < 40000: > env_etc.cxxflags_base.append("-fcoalesce-templates") > env_etc.cxxflags_base.append("-DBOOST_ALL_NO_LIB") > @@ -861,11 +860,10 @@ > if env_etc.apple_gcc_builds.gcc < 5646: > # fixed on 10.6 (Snow Leopard) whose Dev Tools start with that build > opts.insert(0, "-gstabs+") > - env_etc.shlinkflags = ["-mmacosx-version-min=10.8"] > + env_etc.shlinkflags = [] > env_etc.shlinkflags_bpl = [ > "-w", # suppress "source/lib does not exist" warning > - "-bundle", "-mmacosx-version-min=10.8", > - "-undefined", "dynamic_lookup"] > + "-bundle", "-undefined", "dynamic_lookup"] > if libtbx.env.build_options.force_32bit: > if (env_etc.gcc_version and env_etc.gcc_version >= 40201) or > env_etc.clang_version: > env_etc.ccflags_base.extend(["-arch", "i386"]) > > FROM: Graeme.Winter(a)diamond.ac.uk [mailto:[email protected]] > > SENT: 15 May 2015 09:01 > TO: cctbxbb(a)phenix-online.org; robert(a)oeffner.net > CC: dials-support(a)lists.sourceforge.net; dials-dev(a)cci.lbl.gov > SUBJECT: Build constraints in SConscript? > > Hi Folks > > A while back we worked on making DIALS work right built on 10.10 but > executed on 10.6 or later – this is very useful as lots of people > have 10.6/7 macs & are not keen to update. This is done by the very > flexible mechanism of exporting an environment variable prior to > compilation > > Then this commit appears > > env_etc.static_bpl = 0 > @@ -802,7 +803,7 @@ > env_etc.static_libraries = 1 > env_etc.static_bpl = 0 > > - link_flags = ["-w"] # suppress "source/lib does not exist" warning > + link_flags = ["-w", "-mmacosx-version-min=10.8"] # suppress > "source/lib does not exist" warning > if libtbx.env.build_options.force_32bit: > if (env_etc.gcc_version and env_etc.gcc_version >= 40201) or > env_etc.clang_version: > link_flags.extend(["-arch", "i386"]) > @@ -810,7 +811,8 @@ > env_etc.c_link = "cc" > env_etc.ccflags_base = [ > "-fPIC", > - "-fno-strict-aliasing"] > + "-fno-strict-aliasing", > + "-mmacosx-version-min=10.8"] > if env_etc.clang_version: > setup_clang_warning(env_etc, libtbx.env.build_options.warning_level) > else: > @@ -826,7 +828,7 @@ > env_etc.ccflags_base.extend(["-no-cpp-precomp"]) > if (env_etc.gcc_version < 40201): > env_etc.ccflags_base.append("-Wno-long-double") > - env_etc.cxxflags_base = [] > + env_etc.cxxflags_base = ["-mmacosx-version-min=10.8"] > if env_etc.clang_version is None and env_etc.gcc_version < 40000: > env_etc.cxxflags_base.append("-fcoalesce-templates") > env_etc.cxxflags_base.append("-DBOOST_ALL_NO_LIB") > @@ -859,10 +861,10 @@ > > to > > Modified Paths: > -------------- > trunk/libtbx/SConscript > > and now our build no longer works on 10.7. This is *REALLY* annoying. > The head of the commit message follows below. > > Please could someone fix this? The environment variable method is > *FAR* better, works for the dependencies and also allows dials to work > on older machines. You broke our build. Before this it worked fine. > > (we can’t automate this test as we are not supposed to deploy out of > support machines on lab network, so this was missed) > > Thanks Graeme > > EFFNER > > to cctbx-cvs > > May 13 > > Revision: 22202 > http://sourceforge.net/p/cctbx/code/22202 [2] > Author: oeffner > Date: 2015-05-13 15:48:24 +0000 (Wed, 13 May 2015) > Log Message: > ----------- > ensure installers can run on MacOSX 10.8 or higher > > -- > > 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 > > No virus found in this message. > Checked by AVG - www.avg.com [3] > Version: 2015.0.5941 / Virus Database: 4342/9780 - Release Date: > 05/15/15 > > Links: > ------ > [1] http://sourceforge.net/p/cctbx/code/22223 > [2] http://sourceforge.net/p/cctbx/code/22202 > [3] http://www.avg.com -- 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

3 2

Build constraints in SConscript?
by Graeme.Winter＠diamond.ac.uk 15 May '15

15 May '15

Hi Folks A while back we worked on making DIALS work right built on 10.10 but executed on 10.6 or later - this is very useful as lots of people have 10.6/7 macs & are not keen to update. This is done by the very flexible mechanism of exporting an environment variable prior to compilation Then this commit appears env_etc.static_bpl = 0 @@ -802,7 +803,7 @@ env_etc.static_libraries = 1 env_etc.static_bpl = 0 - link_flags = ["-w"] # suppress "source/lib does not exist" warning + link_flags = ["-w", "-mmacosx-version-min=10.8"] # suppress "source/lib does not exist" warning if libtbx.env.build_options.force_32bit: if (env_etc.gcc_version and env_etc.gcc_version >= 40201) or env_etc.clang_version: link_flags.extend(["-arch", "i386"]) @@ -810,7 +811,8 @@ env_etc.c_link = "cc" env_etc.ccflags_base = [ "-fPIC", - "-fno-strict-aliasing"] + "-fno-strict-aliasing", + "-mmacosx-version-min=10.8"] if env_etc.clang_version: setup_clang_warning(env_etc, libtbx.env.build_options.warning_level) else: @@ -826,7 +828,7 @@ env_etc.ccflags_base.extend(["-no-cpp-precomp"]) if (env_etc.gcc_version < 40201): env_etc.ccflags_base.append("-Wno-long-double") - env_etc.cxxflags_base = [] + env_etc.cxxflags_base = ["-mmacosx-version-min=10.8"] if env_etc.clang_version is None and env_etc.gcc_version < 40000: env_etc.cxxflags_base.append("-fcoalesce-templates") env_etc.cxxflags_base.append("-DBOOST_ALL_NO_LIB") @@ -859,10 +861,10 @@ to Modified Paths: -------------- trunk/libtbx/SConscript and now our build no longer works on 10.7. This is *really* annoying. The head of the commit message follows below. Please could someone fix this? The environment variable method is *far* better, works for the dependencies and also allows dials to work on older machines. You broke our build. Before this it worked fine. (we can't automate this test as we are not supposed to deploy out of support machines on lab network, so this was missed) Thanks Graeme effner to cctbx-cvs [https://ssl.gstatic.com/bt/C3341AA7A1A076756462EE2E5CD71C11/2x/ic_expand_sm…] May 13 Revision: 22202 http://sourceforge.net/p/cctbx/code/22202 Author: oeffner Date: 2015-05-13 15:48:24 +0000 (Wed, 13 May 2015) Log Message: ----------- ensure installers can run on MacOSX 10.8 or higher -- 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

1 1

Does cctbx have an easy to access spherical harmonic table?
by Graeme.Winter＠diamond.ac.uk 10 May '15

10 May '15

Hi Folks, Looked and something is used from boost but they don’t appear to be clearly wrapped to Python. in scitbx.math.nss_spherical_harmonics found nearly what I was looking for but it seems to be for some other purpose & not really do what I want (and needs mystery things in constructor….) >>> _sh = sh(2, 1) Traceback (most recent call last): File "<stdin>", line 1, in <module> Boost.Python.ArgumentError: Python argument types in nss_spherical_harmonics.__init__(nss_spherical_harmonics, int, int) did not match C++ signature: __init__(_object*, int l_max, int mangle, scitbx::math::zernike::log_factorial_generator<double> lgf) Any clues would be welcome, else wise most sensible thing seems to be to wrap up to Python the boost spherical harmonic code… Thanks Graeme -- 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

3 3

bin data by a Miller index
by Mooers, Blaine H.M. (HSC) 24 Apr '15

24 Apr '15

Dear cctbxbb: I have a simple question. I have a data set with a strong off origin Patterson peak (0,0,0.11). I want to plot the average I/sig per zone l = n. I expect to see enhanced values at l=9n. How do you bin data by the L Miller index in iotbx? Best regards, Blaine Blaine Mooers, Ph.D. Assistant Professor Director of the Laboratory of Biomolecular Structure and Function Department of Biochemistry and Molecular Biology University of Oklahoma Health Sciences Center S.L. Young Biomedical Research Center Rm. 466 Shipping address: 975 NE 10th Street, BRC 466 Oklahoma City, OK 73104-5419 Letter address: P.O. Box 26901, BRC 466 Oklahoma City, OK 73190 office: (405) 271-8300 lab: (405) 271-8313 fax: (405) 271-3910 e-mail: blaine-mooers(a)ouhsc.edu Faculty webpage: http://www.oumedicine.com/department-of-biochemistry-and-molecular-biology/… Small Angle Scattering webpage: http://www.oumedicine.com/docs/default-source/ad-biochemistry-workfiles/sma… X-ray lab webpage: http://www.oumedicine.com/department-of-biochemistry-and-molecular-biology/…

2 1

scitbx test crashing on mac
by markus.gerstel＠diamond.ac.uk 14 Apr '15

14 Apr '15

Good morning, The test scitbx.rigid_body.proto.tst_singular has been failing consistently on our MacOS 10.10 system for a day now. Last known good svn rev. is 21989. It passes on the linux systems. Apologies if this is not the right place to report scitbx problems to. -Markus Stacktrace 11 Python 0x0000000100010d03 PyObject_Call + 99 10 libboost_python.dylib 0x0000000101a0f893 boost::python::objects::function_call(_object*, _object*, _object*) + 83 9 libboost_python.dylib 0x0000000101a147f1 boost::python::handle_exception_impl(boost::function0<void>) + 81 8 libboost_python.dylib 0x0000000101a0fe5a boost::detail::function::void_function_ref_invoker0<boost::python::objects::(anonymous namespace)::bind_return, void>::invoke(boost::detail::function::function_buffer&) + 26 7 libboost_python.dylib 0x0000000101a0db6a boost::python::objects::function::call(_object*, _object*) const + 826 6 scitbx_linalg_ext.so 0x000000010518b521 boost::python::objects::caller_py_function_impl<boost::python::detail::caller<scitbx::af::shared<double> (scitbx::matrix::eigensystem::real_symmetric<double>::*)() const, boost::python::default_call_policies, boost::mpl::vector2<scitbx::af::shared<double>, scitbx::matrix::eigensystem::real_symmetric<double>&> > >::operator()(_object*, _object*) + 65 5 scitbx_linalg_ext.so 0x000000010518b6be _object* boost::python::detail::invoke<boost::python::to_python_value<scitbx::af::shared<double> const&>, scitbx::af::shared<double> (scitbx::matrix::eigensystem::real_symmetric<double>::*)() const, boost::python::arg_from_python<scitbx::matrix::eigensystem::real_symmetric<double>&> >(boost::python::detail::invoke_tag_<false, true>, boost::python::to_python_value<scitbx::af::shared<double> const&> const&, scitbx::af::shared<double> (scitbx::matrix::eigensystem::real_symmetric<double>::*&)() const, boost::python::arg_from_python<scitbx::matrix::eigensystem::real_symmetric<double>&>&) + 46 4 ??? 0x000000010183fc20 0x0 + 4320394272 3 libsystem_platform.dylib 0x00007fff86f16f1a _sigtramp + 26 2 boost_python_meta_ext.so 0x00000001005bdf80 initboost_python_meta_ext + 0 Floating-point error (Python and libc call stacks above) This crash may be due to a problem in any imported Python module, including modules which are not part of the cctbx project. To disable the traps leading to this message, define these environment variables (e.g. assign the value 1): BOOST_ADAPTBX_FPE_DEFAULT BOOST_ADAPTBX_SIGNALS_DEFAULT This will NOT solve the problem, just mask it, but may allow you to proceed in case it is not critical. Standard Error show_stack(1): /Users/dlshudson/jenkins_slave/workspace/cctbx_tests_platforms/label/dials-mac-mini/build_dials/modules/cctbx_project/scitbx/rigid_body/proto/featherstone.py(38) generalized_inverse show_stack(2): /Users/dlshudson/jenkins_slave/workspace/cctbx_tests_platforms/label/dials-mac-mini/build_dials/modules/cctbx_project/scitbx/rigid_body/proto/featherstone.py(373) FDab show_stack(3): /Users/dlshudson/jenkins_slave/workspace/cctbx_tests_platforms/label/dials-mac-mini/build_dials/modules/cctbx_project/scitbx/rigid_body/proto/test_simulation.py(28) energies_and_accelerations_update show_stack(4): /Users/dlshudson/jenkins_slave/workspace/cctbx_tests_platforms/label/dials-mac-mini/build_dials/modules/cctbx_project/scitbx/rigid_body/proto/test_simulation.py(16) __init__ show_stack(5): /Users/dlshudson/jenkins_slave/workspace/cctbx_tests_platforms/label/dials-mac-mini/build_dials/modules/cctbx_project/scitbx/rigid_body/proto/tst_singular.py(72) exercise_six_dof show_stack(6): /Users/dlshudson/jenkins_slave/workspace/cctbx_tests_platforms/label/dials-mac-mini/build_dials/modules/cctbx_project/scitbx/rigid_body/proto/tst_singular.py(146) run show_stack(7): /Users/dlshudson/jenkins_slave/workspace/cctbx_tests_platforms/label/dials-mac-mini/build_dials/modules/cctbx_project/scitbx/rigid_body/proto/tst_singular.py(162) <module> libc backtrace (43 frames, most recent call last): 44 ??? 0x0000000000000003 0x0 + 3 43 Python 0x0000000100000d71 Python + 3441 42 Python 0x0000000100000e58 Python + 3672 41 Python 0x00000001000edd44 Py_Main + 3076 40 Python 0x00000001000d64a7 PyRun_SimpleFileExFlags + 711 39 Python 0x00000001000d6984 PyRun_FileExFlags + 164 38 Python 0x00000001000ad596 PyEval_EvalCode + 54 37 Python 0x00000001000adc22 PyEval_EvalCodeEx + 1666 36 Python 0x00000001000b179f PyEval_EvalFrameEx + 14111 35 Python 0x00000001000b5556 fast_function + 118 34 Python 0x00000001000adc22 PyEval_EvalCodeEx + 1666 33 Python 0x00000001000b179f PyEval_EvalFrameEx + 14111 32 Python 0x00000001000b5556 fast_function + 118 31 Python 0x00000001000adc22 PyEval_EvalCodeEx + 1666 30 Python 0x00000001000b295b PyEval_EvalFrameEx + 18651 29 Python 0x0000000100010d03 PyObject_Call + 99 28 Python 0x0000000100069e23 type_call + 339 27 Python 0x000000010006fccd slot_tp_init + 141 26 Python 0x0000000100010d03 PyObject_Call + 99 25 Python 0x000000010001e207 instancemethod_call + 247 24 Python 0x0000000100010d03 PyObject_Call + 99 23 Python 0x0000000100036a6c function_call + 364 22 Python 0x00000001000adc22 PyEval_EvalCodeEx + 1666 21 Python 0x00000001000b179f PyEval_EvalFrameEx + 14111 20 Python 0x00000001000b5556 fast_function + 118 19 Python 0x00000001000adc22 PyEval_EvalCodeEx + 1666 18 Python 0x00000001000b179f PyEval_EvalFrameEx + 14111 17 Python 0x00000001000b5556 fast_function + 118 16 Python 0x00000001000adc22 PyEval_EvalCodeEx + 1666 15 Python 0x00000001000b179f PyEval_EvalFrameEx + 14111 14 Python 0x00000001000b5556 fast_function + 118 13 Python 0x00000001000adc22 PyEval_EvalCodeEx + 1666 12 Python 0x00000001000b295b PyEval_EvalFrameEx + 18651 11 Python 0x0000000100010d03 PyObject_Call + 99 10 libboost_python.dylib 0x0000000101a0f893 boost::python::objects::function_call(_object*, _object*, _object*) + 83 9 libboost_python.dylib 0x0000000101a147f1 boost::python::handle_exception_impl(boost::function0<void>) + 81 8 libboost_python.dylib 0x0000000101a0fe5a boost::detail::function::void_function_ref_invoker0<boost::python::objects::(anonymous namespace)::bind_return, void>::invoke(boost::detail::function::function_buffer&) + 26 7 libboost_python.dylib 0x0000000101a0db6a boost::python::objects::function::call(_object*, _object*) const + 826 6 scitbx_linalg_ext.so 0x000000010518b521 boost::python::objects::caller_py_function_impl<boost::python::detail::caller<scitbx::af::shared<double> (scitbx::matrix::eigensystem::real_symmetric<double>::*)() const, boost::python::default_call_policies, boost::mpl::vector2<scitbx::af::shared<double>, scitbx::matrix::eigensystem::real_symmetric<double>&> > >::operator()(_object*, _object*) + 65 5 scitbx_linalg_ext.so 0x000000010518b6be _object* boost::python::detail::invoke<boost::python::to_python_value<scitbx::af::shared<double> const&>, scitbx::af::shared<double> (scitbx::matrix::eigensystem::real_symmetric<double>::*)() const, boost::python::arg_from_python<scitbx::matrix::eigensystem::real_symmetric<double>&> >(boost::python::detail::invoke_tag_<false, true>, boost::python::to_python_value<scitbx::af::shared<double> const&> const&, scitbx::af::shared<double> (scitbx::matrix::eigensystem::real_symmetric<double>::*&)() const, boost::python::arg_from_python<scitbx::matrix::eigensystem::real_symmetric<double>&>&) + 46 4 ??? 0x000000010183fc20 0x0 + 4320394272 3 libsystem_platform.dylib 0x00007fff86f16f1a _sigtramp + 26 2 boost_python_meta_ext.so 0x00000001005bdf80 initboost_python_meta_ext + 0 Floating-point error (Python and libc call stacks above) This crash may be due to a problem in any imported Python module, including modules which are not part of the cctbx project. To disable the traps leading to this message, define these environment variables (e.g. assign the value 1): BOOST_ADAPTBX_FPE_DEFAULT BOOST_ADAPTBX_SIGNALS_DEFAULT This will NOT solve the problem, just mask it, but may allow you to proceed in case it is not critical. -- 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

5 9

bootstrap script broken - more rotamer goodness
by markus.gerstel＠diamond.ac.uk 08 Apr '15

08 Apr '15

Hi, We received an error report from a dials user that he could not install dials from source. This appears to be caused by the mmtbx.rebuild_rotarama_cache command run after the compilation, which has been introduced in http://sourceforge.net/p/cctbx/code/21921/ I guess this needs either to be run conditional on the library being installed or be changed to fail gracefully. -Markus -- 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

2 3