- Dec 21, 2016
-
-
Marco Clemencic authored
and postponed removal of deprecated code See merge request !264
-
Marco Clemencic authored
-
- Dec 19, 2016
-
-
Marco Clemencic authored
-
Marco Clemencic authored
See merge request !256
-
Marco Clemencic authored
Reverse the const enforcement if appropriate compile time flags are used. It also offers a compile time deprecation warning to identify problematic code. if compiled with `-DALLOW_TOOLHANDLE_NONCONSTNESS`, can call non-const methods of a Tool from a const ToolHandle. Also adds a `ToolHandle.unConst()` method which strips the constness of the ToolHandle, but prints a deprecation warning message at compile time. Requires `-DATLAS`. See merge request !253
-
Marco Clemencic authored
1. In all scenarios: * avoid repetitive data input/output declaration each time an algorithm instance is re-used in the graph of precedence rules; 2. In ATLAS MC data reconstruction scenario: * declare as a test; * hide all occurrences of '::' operator used by data types specifications (otherwise such data items are misinterpreted as alternatives); * remove in-place data modification pattern from the data flow graph (all such occurrences were in fact removed earlier, except one, which is now also removed) See merge request !262
-
Marco Clemencic authored
required by the pre-existing `init` method of `ConditionHandles` (ATLAS). See merge request !260
-
Marco Clemencic authored
the method is used in ATLAS code. See merge request !259
-
- Dec 17, 2016
-
-
Illya Shapoval authored
-
Illya Shapoval authored
-
Illya Shapoval authored
hide '::' operator in the ATLAS MC reco data flow graph (to avoid false creation of data alternatives)
-
Illya Shapoval authored
-
Illya Shapoval authored
precedence.py: avoid repetitive data input/output declaration each time an algorithm instance is re-used in the graph of precedence rules
-
- Dec 16, 2016
-
-
Charles Leggett authored
-
Charles Leggett authored
-
- Dec 15, 2016
-
-
Charles Leggett authored
-
Sebastien Ponce authored
-
Charles Leggett authored
-
- Dec 14, 2016
-
-
Marco Clemencic authored
See merge request !252
-
Marco Clemencic authored
-
Marco Clemencic authored
-
Marco Clemencic authored
-
Marco Clemencic authored
-
Benedikt Hegner authored
See merge request !251
-
Benedikt Hegner authored
See merge request !250
-
Benedikt Hegner authored
To be able to profit from vectorized code, we need to enable instructions for larger vector units. SSE4.2 instructions can be safely enabled not reducing the portability of binaries (LHCb would loose ~7% of CEs, all very old), but keeping the settings for gcc 4.9 will make the old machines still usable. Although the new settings are not really improving the performances of current code, not using them will prevent exploiting the larger vector units in vectorized code. We would also like to enable AVX2, but not being wide spread enough it would require a new binary tag (to be agreed at LIM/AF). See LBCORE-1227. See merge request !247
-
Marco Clemencic authored
default to sse4.2 for gcc > 5.0
-
Benedikt Hegner authored
In the last days I experimented a bit with teaching Gaudi how to build when only ROOT, Boost and TBB are available to it. This is the result. As far as I can tell the code builds in the same way as the current master branch when all possible externals are available. (All the ones available in a full ATLAS offline build at least.) And I'm also able to build the project in these modes: * On Ubuntu 16.04 with the system provided Boost and TBB versions, against a privately built ROOT 6 version. * On macOS Sierra against privately built Boost, ROOT and TBB versions. Both when building the project completely on its own, and when building it against an ATLAS externals project. Some notes: * The code uses C++14 expressions in quite a few places by now. So I raised the default C++ standard to C++14. This is the default in ATLAS builds since a while, I only saw this as an issue when building Gaudi "on its own" with a very minimal configuration command. * While the code advertises that it still has support for ROOT 5, it's not able to build against it since a wile. Since the updates I put in for TLS variables on macOS. (The macros used there are ROOT 6 only.) And this update makes things even worse. As the code now relies on not providing the definition of some classes to the dictionary generator in GaudiPython that are not available. (Because AIDA or XercesC is missing.) While ROOT 6 handles this with just a build warning, ROOT 5's genreflex treats this with an ERROR message. That I was unable to get rid of. So, extended testing is clearly necessary, the configuration code could definitely be fine tuned as I probably turned off the build of more source files than absolutely necessary, but I think we should move ahead with such a configuration organisation. See merge request !241
-
Benedikt Hegner authored
See merge request !248
-
- Dec 13, 2016
-
-
Sebastien Ponce authored
-
- Dec 12, 2016
-
-
Charles Leggett authored
if compiled with -DALLOW_TOOLHANDLE_NONCONSTNESS, can call non-const methods of a Tool from a const ToolHandle. adds a ToolHandle.unConst() method which strips the constness of the ToolHandle, but prints a deprecation warning message at compile time. Requires -DATLAS.
-
- Dec 09, 2016
-
-
Attila Krasznahorkay authored
Merged in the latest changes from the master branch. Resolving two conflicts that arose in GaudiAlg and GaudiKernel. Had to turn off the build of the new files in GaudiExamples/src/FunctionalAlgorithms/ when the Ranges_v3 headers are not available.
-
Sebastien Ponce authored
-
Sebastien Ponce authored
-
Marco Clemencic authored
-
Sebastien Ponce authored
-
Sebastien Ponce authored
Some lambda parameters needed to be copied rather than passed by reference to be safe
-
-
Marco Clemencic authored
-
- Dec 08, 2016
-
-
Marco Clemencic authored
-