- RootHistogramSink: avoid having a 'registry' for each instance,
  instead keep one shared constant global in an anonymous namespace
  so it is hidden from the linker
- JSONSink: use the fact that `ofstream` closes the corresponding file
  when going out of scope
- BaseSink: use `std::set` with dedicted comparison operator instead
  of `std::map` which saves a bit of memory
- MonitoringHub: avoid one level of indirection in the type erasure
  which will type-erased function arguments to be passed in registers
  instead of forcing them to be passed through main memory
- MonitoringHub: `m_typeIndex` is an invariant once constructed, and
  does not need a type-erased function to be determined 'on the fly'

Change `GaudiHandleArray` type from `list` to `MutableSequence` and
implement the storage as `dict`, which is guaranteed to be
insertion-ordered as of Python 3. This considerably improves the speed
of `append`.

`insert` is potentially a bit slower but that is rarely used.

Their usage is similar to standard histograms, names are prefixed with "Root" and at this stage only non profile, non weighted versions are provided, for dimensions 1,  and 3 only.
The main difference with standard histograms is that they compute statistical data on the input on top of the strict histogram, in particular they keep sum and sum of squares of all variables so that mean and standard_deviation of the original data can be computed.
This behavior mimics Root histograms, which allows to convert the new histograms to Root ones and have the expected behavior, while the Gaudi histograms had no statistical data and their conversion to Root was somehow recomputing them (Root did) based on the histogram content. Obviously the values obtained were not correct.

Remove `print_function`, `absolute_import` and `division` imports.

Remove remaining Python2 backwards-compatibilty code.

Appending to an empty default HandleArray was not possible. Fix and add
unit test.

Remove deprecated `OutStreamType` property from `ApplicationMgr` and
`MinimalEventLoopMgr`.

Make the printout of `set` properties reproducible. For GaudiConfig2,
this is done via the property `repr` itself. For the legacy
Configurables, only in the `str` printout.

For backwards compatibility, allow the following code:
```
   alg.MySetProperty = [1, 2, 3]
```

Change the Python type of `std::unordered_set` properties from `list` to `set`.
Parsers only required minor updates and special treatment of the empty
set, which can only be represented as `set()` in Python (`{}` is
reserved for dictionaries).

This will certainly break client code, i.e.
```
   MyAlg.ExtraInputs += ['foo']
```
will have to be updated to
```
  MyAlg.ExtraInputs.add('foo')
```

For the moment only `std::unordered_set` is mapped to a Python `set`.
Regular `std::set` remains as Python `list` to maintain insertion order.

Fix the cleanup function and extend the test to `dict` and `list`
proprties. Also migrate to `pytest` fixtures and exception handling.

- remove duplicated constructor
- add const
- add final
- do not inherit from SmartRef just to create dictionary instances
- prefer nullptr over 0

scott snyder authored 1 year ago and Marco Clemencic committed 1 year ago

GaudiHandleBase has a virtual destructor which is declared with `=default'.
However. in C++20 mode, clang will then try to instiantiate all the virtual
functions for classes derived from this whenever the declarations
for those classes are seen.  The upshot is that then using Gaudi handles
with forward-declared classes doesn't work (even if the handle is only
declared in the header but not used in any way).

It turns out that we can avoid this behavior by changing the declaration
of the base class destructor to say `{}' instead of `=default'.
(This is perhaps a clang bug, but the standard is not very clear
on exactly when virtual members of the templated class are required
to be or not to be implicitly instantiated.)

See also ATLINFR-5113.

Without `NamedRange_::operator==`, in the comparison between two
`NamedRange_` instances `nr1` and `nr2` C++20 would not be able to
choose between `(Range_&)nr1 == nr2` and `(Range_&)nr2 == nr1`.

Remove the property type added as a comment to the Conf.py files. It was
entirely cosmetic and often wrong (e.g. maps were annotated as `# list`).

Relates to issue #219.

Sebastien Ponce authored 1 year ago and Marco Clemencic committed 1 year ago

The problem was due to the use of deque, extremely slow for deleting when getting big.
The code was written that way supposing we would get ~100 entities (aka some human readable quantity), but we seem to reach > 100000...
So deque has been replaced by a map with entity's memory address as a key, and now the deletion is fast

Sebastien Ponce authored 1 year ago and Marco Clemencic committed 1 year ago

use std::promise/future instead of misusing std::condition_variable

Replicated from identical commit in LHCb FSRSink.cpp file (lhcb/LHCb@e4b7fdf9)

Sebastien Ponce authored 2 years ago and Marco Clemencic committed 1 year ago

In particuler :
  - made it a free function
  - fixed bad usage of move semantic in favor of references

Sebastien Ponce authored 2 years ago and Marco Clemencic committed 1 year ago

Also implemented a default, empty reset.

Sebastien Ponce authored 2 years ago and Marco Clemencic committed 1 year ago

The Sinks have now to implement a flush method, called both at the end (finalize) and regularly if auto flush is activated (via non 0 AutoFlushPeriod property).
Existing Sinks have been adapted.

Also added unit testing for BaseSink, both for the regular flushing and previous existing (and not yet tested) features.