LHCb merge requestshttps://gitlab.cern.ch/lhcb/LHCb/-/merge_requests2020-02-04T22:52:15+01:00https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2218Fix remaining gcc9 warnings2020-02-04T22:52:15+01:00Gerhard RavenFix remaining gcc9 warningsadd some explicitly defined `operator=` to match the explicitly defined copy constructors, and where that is not appropriate, add a few #pragma to silence the (correct!) warnings... add some explicitly defined `operator=` to match the explicitly defined copy constructors, and where that is not appropriate, add a few #pragma to silence the (correct!) warnings... Christopher Rob Jonesjonesc@hep.phy.cam.ac.ukChristopher Rob Jonesjonesc@hep.phy.cam.ac.ukhttps://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2237Define comparator decorator for LHCb::ParticleProperty objects.2020-02-04T22:37:04+01:00Alex PearceDefine comparator decorator for LHCb::ParticleProperty objects.Closes #66.
This doesn't fix what I'd consider to be the 'underlying' cause, that the `operator<` method isn't being used in the Python bindings for `LHCb::ParticleProperty`, but that's a deeper issue that'll take longer to figure out. ...Closes #66.
This doesn't fix what I'd consider to be the 'underlying' cause, that the `operator<` method isn't being used in the Python bindings for `LHCb::ParticleProperty`, but that's a deeper issue that'll take longer to figure out. Fixing _that_ problem would be great, because then one wouldn't need to import `PartProp.decorators` to pick up this fix.
/cc @jonrob @gravenhttps://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2247Workaround for Gaudi::Application not popping the output queue2020-02-04T22:32:30+01:00Niklas Stefan NolteWorkaround for Gaudi::Application not popping the output queueAt the moment nobody pops from the async scheduler queue, so it grows infinitely (which is obv. bad). This fixes that by `pop`ing from the queue.
This is just a temporary "fix" (eg for the throughput nightlies), and this MR will be cl...At the moment nobody pops from the async scheduler queue, so it grows infinitely (which is obv. bad). This fixes that by `pop`ing from the queue.
This is just a temporary "fix" (eg for the throughput nightlies), and this MR will be closed as soon as the `Gaudi::Application` does the popping for us. The issue is that we run the multithreaded Gaudi using a *main* that is not aware of multithreaded applications, i.e. we call `Gaudi::Application::run()` which calls `HLTControlFlowMgr::executeRun()`. While we should call something that calls `HLTControlFlowMgr::push(...)` and `HLTControlFlowMgr::pop()`.
Since `HLTControlFlowMgr::executeRun()` is itself calling `HLTControlFlowMgr::push(...)`, an easy work around is to add `HLTControlFlowMgr::pop()` there, but we need to think about a way of moving the `push`/`pop` up into a `Gaudi::Application`.https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2258LoKi::ToCpp - Explicitly instanciate array<string,4> to work around clang/pyt...2019-12-12T14:05:30+01:00Christopher Rob Jonesjonesc@hep.phy.cam.ac.ukLoKi::ToCpp - Explicitly instanciate array<string,4> to work around clang/python/cling/ROOT issueThe primary purpose of this MR is to address the clang LHCb test failures, e.g. those at
https://lhcb-nightlies.cern.ch/nightly/lhcb-head/build/2458/
```
IncrementalExecutor::executeFunction: symbol '_ZNSt5arrayINSt7__cxx1112basic_stri...The primary purpose of this MR is to address the clang LHCb test failures, e.g. those at
https://lhcb-nightlies.cern.ch/nightly/lhcb-head/build/2458/
```
IncrementalExecutor::executeFunction: symbol '_ZNSt5arrayINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEELm4EED1Ev' unresolved while linking function '_GLOBAL__sub_I_cling_module_406'!
You are probably missing the definition of std::array<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, 4ul>::~array()
Maybe you need to load the corresponding shared library?
```
The most minimal reproducer I have found for this is, from python
```
from LoKiCore.basic import std, LoKi
x = LoKi.Functor(std.vector('double'), 'double')
```
The issue, as far as I have been able to get investigating it, is something to do with the std::tuple overload of `toCpp`
```
template <typename Tuple, std::size_t... I>
std::string toCpp( const Tuple& t, std::index_sequence<I...> ) {
std::array<std::string, sizeof...( I )> strs{Gaudi::Utils::toCpp( std::get<I>( t ) )...};
return boost::algorithm::join( strs, " , " );
}
```
However, I have not be fully able to pin it down to exactly what. An LHCb issue, ROOT ?, cling ? or something else, I am not sure.
This MR adds a clang specific workaround, to explicitly instantiate the type `std::array<std::string, 4ul>` from `LoKi/ToCpp.h`.
I acknowledge this is really more a workaround than a fix, but at least it cleans up the nightlies, which is my aim here...https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2308Always write out new ref if different from old2020-02-04T17:48:03+01:00Rosen MatevAlways write out new ref if different from oldPreviously a new ref was only written if the validation failed. Now it is always written if different.
In addition, add a check whether the preprocessor is idempotent (might lead to failures in downstream projects if dedicated problemat...Previously a new ref was only written if the validation failed. Now it is always written if different.
In addition, add a check whether the preprocessor is idempotent (might lead to failures in downstream projects if dedicated problematic preprocessors are used).
Also, add workaround for gaudi/Gaudi#108 which is a follow up from !2260 (the bug got manifested in the `brunel-upgrade-paramKalman-auxiliaries` test)https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2330Get libgit2 sources from LHCb repository2020-11-13T12:44:24+01:00Marco Clemencicmarco.clemencic@cern.chGet libgit2 sources from LHCb repositoryTo build the Git CondDB access library (GitEntityResolver) in old branches we download the sources of `libgit2` from the official repository.
Unfortunately one of the build machines (lblhcbpr13) does not have external connectivity, an...To build the Git CondDB access library (GitEntityResolver) in old branches we download the sources of `libgit2` from the official repository.
Unfortunately one of the build machines (lblhcbpr13) does not have external connectivity, and cannot access the official `libgit2` repository, so I copied the tar file to the LHCb repository created for LBCORE-1808, so that it can be downloaded from any build machine.
This change should be propagated to the other branches that require downloading of `libgit2`.https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2388Workaround for ROOT/Cling problem with Boost small_vector2020-03-16T14:53:37+01:00Rosen MatevWorkaround for ROOT/Cling problem with Boost small_vectorExtends the workaround introduced in 25e5092d1 to work with
Boost 1.72.
see lhcb/LHCb#75Extends the workaround introduced in 25e5092d1 to work with
Boost 1.72.
see lhcb/LHCb#75https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2406Get libgit2 sources from LHCb repository (@clemenci)2020-03-02T16:30:26+01:00Marco CattaneoGet libgit2 sources from LHCb repository (@clemenci)See merge request lhcb/LHCb!2330 (cherry picked from commit fd4c2f23a371395232d89c0bc9ca47a23385849d)
To build the Git CondDB access library (GitEntityResolver) in old branches we download the sources of `libgit2` from the official repo...See merge request lhcb/LHCb!2330 (cherry picked from commit fd4c2f23a371395232d89c0bc9ca47a23385849d)
To build the Git CondDB access library (GitEntityResolver) in old branches we download the sources of `libgit2` from the official repository.
Unfortunately one of the build machines (lblhcbpr13) does not have external connectivity, and cannot access the official `libgit2` repository, so I copied the tar file to the LHCb repository created for LBCORE-1808, so that it can be downloaded from any build machine.https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2407Get libgit2 sources from LHCb repository (@clemenci)2020-03-02T16:30:26+01:00Marco CattaneoGet libgit2 sources from LHCb repository (@clemenci)See merge request lhcb/LHCb!2330 (cherry picked from commit fd4c2f23a371395232d89c0bc9ca47a23385849d)
To build the Git CondDB access library (GitEntityResolver) in old branches we download the sources of `libgit2` from the official re...See merge request lhcb/LHCb!2330 (cherry picked from commit fd4c2f23a371395232d89c0bc9ca47a23385849d)
To build the Git CondDB access library (GitEntityResolver) in old branches we download the sources of `libgit2` from the official repository.
Unfortunately one of the build machines (lblhcbpr13) does not have external connectivity, and cannot access the official `libgit2` repository, so I copied the tar file to the LHCb repository created for LBCORE-1808, so that it can be downloaded from any build machine.https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2416Get libgit2 sources from LHCb repository (@clemenci)2020-03-02T16:30:27+01:00Marco CattaneoGet libgit2 sources from LHCb repository (@clemenci)See merge request lhcb/LHCb!2330 (cherry picked from commit fd4c2f23a371395232d89c0bc9ca47a23385849d)See merge request lhcb/LHCb!2330 (cherry picked from commit fd4c2f23a371395232d89c0bc9ca47a23385849d)https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2417Get libgit2 sources from LHCb repository (@clemenci)2020-02-29T13:24:54+01:00Marco CattaneoGet libgit2 sources from LHCb repository (@clemenci)See merge request lhcb/LHCb!2330 (cherry picked from commit fd4c2f23a371395232d89c0bc9ca47a23385849d)See merge request lhcb/LHCb!2330 (cherry picked from commit fd4c2f23a371395232d89c0bc9ca47a23385849d)https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2418Get libgit2 sources from LHCb repository (@clemenci)2020-02-29T13:24:21+01:00Marco CattaneoGet libgit2 sources from LHCb repository (@clemenci)See merge request lhcb/LHCb!2330 (cherry picked from commit fd4c2f23a371395232d89c0bc9ca47a23385849d)
To build the Git CondDB access library (GitEntityResolver) in old branches we download the sources of `libgit2` from the official re...See merge request lhcb/LHCb!2330 (cherry picked from commit fd4c2f23a371395232d89c0bc9ca47a23385849d)
To build the Git CondDB access library (GitEntityResolver) in old branches we download the sources of `libgit2` from the official repository.
Unfortunately one of the build machines (lblhcbpr13) does not have external connectivity, and cannot access the official `libgit2` repository, so I copied the tar file to the LHCb repository created for LBCORE-1808, so that it can be downloaded from any build machine.
This change should be propagated to the other branches that require downloading of `libgit2`.https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2419Ignore unchecked status codes2020-03-11T13:41:27+01:00Marco Clemencicmarco.clemencic@cern.chIgnore unchecked status codesSupersede !1524
I just regenerated the patch I proposed some time ago, this time, with special comments that can be used to distinguish a legitimate `.ignore()` from one introduced automatically.
As a reminder, some of the uncheck...Supersede !1524
I just regenerated the patch I proposed some time ago, this time, with special comments that can be used to distinguish a legitimate `.ignore()` from one introduced automatically.
As a reminder, some of the unchecked StatusCodes must be checked, but this change has the benefit of preserving the old behaviour.
See gaudi/Gaudi!763https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2425Get libgit2 sources from LHCb repository (@clemenci)2020-03-17T09:06:19+01:00Marco CattaneoGet libgit2 sources from LHCb repository (@clemenci)See merge request lhcb/LHCb!2418 (cherry picked from commit 985fe05cbef1d3bc73552790de819918cfc9fb8b)
To build the Git CondDB access library (GitEntityResolver) in old branches we download the sources of `libgit2` from the official re...See merge request lhcb/LHCb!2418 (cherry picked from commit 985fe05cbef1d3bc73552790de819918cfc9fb8b)
To build the Git CondDB access library (GitEntityResolver) in old branches we download the sources of `libgit2` from the official repository.
Unfortunately one of the build machines (lblhcbpr13) does not have external connectivity, and cannot access the official `libgit2` repository, so I copied the tar file to the LHCb repository created for LBCORE-1808, so that it can be downloaded from any build machine.
This change should be propagated to the other branches that require downloading of `libgit2`.https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2426Get libgit2 sources from LHCb repository2020-03-09T11:17:48+01:00Marco Clemencicmarco.clemencic@cern.chGet libgit2 sources from LHCb repositoryThis is the CMT version of lhcb/LHCb!2330, needed to be able to build on machines not connected to the external network.This is the CMT version of lhcb/LHCb!2330, needed to be able to build on machines not connected to the external network.https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2427Get libgit2 sources from LHCb repository (@clemenci)2020-03-03T08:53:06+01:00Marco CattaneoGet libgit2 sources from LHCb repository (@clemenci)
See merge request lhcb/LHCb!2330 (cherry picked from commit fd4c2f23a371395232d89c0bc9ca47a23385849d)
To build the Git CondDB access library (GitEntityResolver) in old branches we download the sources of `libgit2` from the official rep...
See merge request lhcb/LHCb!2330 (cherry picked from commit fd4c2f23a371395232d89c0bc9ca47a23385849d)
To build the Git CondDB access library (GitEntityResolver) in old branches we download the sources of `libgit2` from the official repository.
Unfortunately one of the build machines (lblhcbpr13) does not have external connectivity, and cannot access the official `libgit2` repository, so I copied the tar file to the LHCb repository created for LBCORE-1808, so that it can be downloaded from any build machine.https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2435Ignore unchecked status codes2020-03-12T11:41:29+01:00Marco Clemencicmarco.clemencic@cern.chIgnore unchecked status codesPort to run2-patches of !2419
As a reminder, some of the unchecked StatusCodes must be checked, but this change has the benefit of preserving the old behaviour.
See gaudi/Gaudi!763Port to run2-patches of !2419
As a reminder, some of the unchecked StatusCodes must be checked, but this change has the benefit of preserving the old behaviour.
See gaudi/Gaudi!763https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2438Workaround for gaudi/Gaudi#1172020-06-15T12:45:33+02:00Rosen MatevWorkaround for gaudi/Gaudi#117By default gaudirun.py expands environment variables in job options,
which prevents the functor cache to be built/used correctly.
This is a temporary workaround until a better solution is found for
gaudi/Gaudi#117.By default gaudirun.py expands environment variables in job options,
which prevents the functor cache to be built/used correctly.
This is a temporary workaround until a better solution is found for
gaudi/Gaudi#117.https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2443Get libgit2 sources from LHCb repository (@clemenci)2020-03-10T11:51:49+01:00Marco CattaneoGet libgit2 sources from LHCb repository (@clemenci)This is the CMT version of lhcb/LHCb!2330, needed to be able to build on machines not connected to the external network.
See merge request lhcb/LHCb!2426 (cherry picked from commit 8642c93fc63305f266defc957464956b26a88c79)This is the CMT version of lhcb/LHCb!2330, needed to be able to build on machines not connected to the external network.
See merge request lhcb/LHCb!2426 (cherry picked from commit 8642c93fc63305f266defc957464956b26a88c79)https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2454Fixed usage of small_vector in conjunction with cling2020-03-30T15:52:14+02:00Sebastien PonceFixed usage of small_vector in conjunction with clingThe fix is similar to the one in !2388, but this case had not appeared up to now, and the Calo cleanup (Rec!1998)
see #75 The fix is similar to the one in !2388, but this case had not appeared up to now, and the Calo cleanup (Rec!1998)
see #75