This project is mirrored from https://github.com/mantidproject/mantid.git.
Pull mirroring updated .
- Mar 20, 2020
-
-
Nick Draper authored
Also updated class_maker.py
-
Gigg, Martyn Anthony authored
Further work on applying cmake GenerateExportHeader
-
- Mar 19, 2020
-
-
Nick Draper authored
Remove Unused Original Engineering Diffraction GUI Code
-
Nick Draper authored
Fix all flake 3.7.9 warnings
-
Danny Hindson authored
-
Gagik Vardanyan authored
Remove Python 2 dependencies from developer packages
-
Gagik Vardanyan authored
Make incremental builds work for docs-qthelp target
-
Gagik Vardanyan authored
ISISIndirectBayes - Clear ADS after loading data or warn if we cant remove data
-
Gagik Vardanyan authored
Improve test reliability of jupyter console test
-
- Mar 18, 2020
-
-
Gigg, Martyn Anthony authored
reduce a error log message to warning when changing colour bar to log
-
David Fairbrother authored
Attempts to flush out the cause for the failing nightly clean build on Windows. This is periodically failing on both the release / master clean builds without any reason why.
-
Martyn Gigg authored
Also set minimum cmake version to that required in CMakeLists.txt
-
Dan Nixon authored
Fix TBB Threading issue
-
- Mar 17, 2020
-
-
Gigg, Martyn Anthony authored
Add FullprofPolynomial documentation
-
Danny Hindson authored
cmake add_custom_command is only run if any of the listed outputs is missing or if any of the dependencies are out of date. If any of the documentation .rst files is changed this didn't cause the custom command to run. I've changed this so the command always runs by adding an extra dummy output file that doesn't ever get created. The sphinx builder has some incremental build functionality inside it so this will identify whether any .rst files have changed Note - I also had to set the cmake source file property to SYMBOLIC to avoid the following Visual Studio warning which was added in Visual Studio 2019 (v16.4): warning MSB8065: Custom build for item XXXX succeeded, but specified output "c:\mantid\build\docs\dummyoutput_alwaysrun" has not been created. This may cause incremental build to work incorrectly.
-
Conor Finn authored
-
Conor Finn authored
-
Conor Finn authored
-
- Mar 16, 2020
-
-
David Fairbrother authored
Fixes all flake8 3.7.9 warnings as part of the Python 2->3 transition.
-
Simon Heybrock authored
Wrap mantiddoc Sphinx logger usage for version 1.2
-
Martyn Gigg authored
-
Nick Draper authored
-
Nick Draper authored
Replace final header guards with pragma once
-
Gigg, Martyn Anthony authored
Clang-tidy modernize-use-auto Qt
-
Danny Hindson authored
Apply change to insert export macros into class definition using cmake GenerateExportHeader feature to 3 more projects: API, Crystal and CurveFitting Have replaced DllExport with the cmake macro except in these places: a) class templates - the definitions of class template member functions need to be in the same unit as the declaration so dllimport gives a compilation error in the client code (C2491 in VS) eg SingleValueParameter, SingleValueParameterParser b) headers which are in a project but aren't included by any .cpp units in the project eg IBackgroundFunction.h, ICatalogInfoService.h. In these cases I've removed the DLLExport attribute completely For the API target there were a couple of special cases\extras: API has some conditional use of the extern keyword to control instantiation of template classes. This has been inserted into the automatically created dllconfig.h using a cmake switch that allows some custom content to be appended to the end of the file. Few of the targets require this so I've added a boolean parameter to the wrapper function to handle this GENERATE_MANTID_EXPORT_HEADER I also had to add explicit include directories to PythonInterfaceCore where it imports an API target header (in the unit ExtractWorkspace.h) without having API as a dependency
-
- Mar 13, 2020
-
-
WHITFIELDRE email authored
Change behavior of MatrixWorkspace::findY when value=NaN
-
Martyn Gigg authored
The sphinx.util.logging framework was not available in version 1.2 that is currently used by RHEL 7. This wraps the calls and chooses an appropriate implementation.
-
Nick Draper authored
Only find OpenGL if it is enabled
-
David Fairbrother authored
Replaces the deprecated scheduler_init with global_control. This should future proof us, and completely avoids all the threading issues we were seeing previously. The TBB_PREVIEW_GLOBAL_CONTROL macro is required until TBB 2019U4, or 11 internally. So for simplicity we will make platforms using an older version of TBB (RHEL7 and Ubuntu at writing) switch to scheduler init
-
Harriet Brown authored
This commit removes the final header guard that had been missed by the auto replacer. re: #28200
-
David Fairbrother authored
Fixes the following assertion thrown by TBB: Attempt to terminate non-local scheduler instance This took a significant amount of time to track down due to a number of factors. If your looking for a quick fix; set your tbb::task_scheduler_init to use thread local storage. This is caused by using Python multi-processing (in our case for the system tests). The process will spawn correctly (Windows), however Python will helpfully create seperate thread(s). I assume to observe. In this case the task_scheduler_init handle would then belong to one of these threads, as the act of importing our Python module would init the framework and TBB implicitly. When the tests run and TBBs scheduling is required it will "sign_on" in tbb's governor.cpp to handle scheduling. This works because the scheduler_init handle is process wide. However internally they then use thread local storage (TLS) for tracking the scheduler. As the main process goes to destruct it assumes that we must have a scheduler instance, since at process level we have done the init. But we cannot see any schedulers since they belong to a different thread. We have been getting away with this as the TLS returns NULL which effectively nops the destruction. But the assert correctly points out were getting this wrong. Marking each handle to the scheduler as thread local effectively ties the destruction of the thread to its init status. For most threads this effectively means we create a unique_ptr which isn't used. But for our main threads and weird edge case worker threads it keeps the thread state consistent. We've used a unique_ptr since we have an API which allows us to change the number of threads TBB can spin up. However, anyone else facing this issue would probably be fine with a thread local object allocated on the stack.
-
Nick Draper authored
Remove the dodgy passing of algorithms in *Dialog methods
-
David Fairbrother authored
-
Hahn, Steven authored
Signed-off-by:
Steven Hahn <hahnse@ornl.gov>
-
Dan Nixon authored
-
- Mar 12, 2020
-
-
Gigg, Martyn Anthony authored
-
Martyn Gigg authored
-
Martyn Gigg authored
-
Martyn Gigg authored
-
Nick Draper authored
Update logging calls so they work in sphinx v2.3
-