ROOT version 6.22/00 was released on June 14, 2020.
For more information, see:
The following people have contributed to this version:
Guilherme Amadio, CERN/SFT,
Bertrand Bellenot, CERN/SFT,
Jakob Blomer, CERN/SFT,
Rene Brun, CERN/SFT,
Philippe Canal, FNAL,
Olivier Couet, CERN/SFT,
Surya Dwivedi, GSOC/SFT,
Massimiliano Galli, CERN/SFT,
Andrei Gheata, CERN/SFT,
Hadrien Grasland, IJCLab/LAL,
Enrico Guiraud, CERN/SFT,
Claire Guyot, CERN/SFT,
Stephan Hageboeck, CERN/SFT,
Sergey Linev, GSI,
Pere Mato, CERN/SFT,
Lorenzo Moneta, CERN/SFT,
Alja Mrak-Tadel, UCSD/CMS,
Jan Musinsky, SAS Kosice,
Axel Naumann, CERN/SFT,
Vincenzo Eduardo Padulano, Bicocca/SFT,
Danilo Piparo, CERN/SFT,
Timur Pocheptsoff, Qt Company,
Renato Quagliani, LPNHE, CNRS/IN2P3, Sorbonne Université,
Fons Rademakers, CERN/SFT,
Oksana Shadura, UNL/CMS,
Enric Tejedor Saavedra, CERN/SFT,
Matevz Tadel, UCSD/CMS,
Vassil Vassilev, Princeton/CMS,
Wouter Verkerke, NIKHEF/Atlas,
Stefan Wunsch, CERN/SFT
ROOT::GetImplicitMTPoolSize
has been deprecated in
favor of the newly added ROOT::GetThreadPoolSize
and will
be removed in v6.24.TThreadedObject::fgMaxSlots
is
deprecated: TThreadedObject now increases the number of slots on-demand
rather than running out and throwing an exceptionACLiC
can be configured to pass options to the
rootcling
invocation by enabling in the
.rootrc
the ACLiC.ExtraRootclingFlags [-opts]
line.ROOT::EnableThreadSafety
is not required
before using TThreadExecutor
or
TTreeProcessorMT
anymoreTTreeProcessorMT
does not silently activate implicit
multi-threading features anymore. An explicit call to
ROOT::EnableImplicitMT
is required insteadTTreeProcessorMT
now has a constructor argument to set
the number of threads for its thread-poolTTree
:
kEntriesReshuffled
, which indicates a TTree
that is the output of the processing of another tree during which its
entry order has been changed (this can happen, for instance, when
processing a tree in a multi-thread application). To avoid silent entry
number mismatches, trees with this bit set cannot add friend trees nor
can be added as friends, unless the friend TTree
has an
appropriate TTreeIndex
.TTree::GetBranch
has been updated to execute its search
trough the set of branches breadth first instead of depth first. In some
cases this changes the branch that is returned. For example with: struct FloatInt {
float f;
int x;
};
and
= 1;
int x 2.1, 3};
FloatInt s{t("t", "t");
TTree t.Branch("i", &i); // Create a top level branch named "i" and a sub-branch name "x"
t.Branch("x", &x);
the old version of t.GetBranch("x")
was return the
i.x
sub-branch while the new version return the
x
top level branch.
TTree::GetBranch
was also upgraded to properly
handle being give a full branch name. In prior version, with the example
above, GetBranch("i.x")
would return nullptr. With the new
version it returns the address of the branch i.x
.
TChain
now properly carries from TTree
to TTree
, each TBranch MakeClass
(also known
as DecomposedObj[ect]
mode, if it was set (implicitly or
explicitly).
TTree::SetBranchAddress
and
TChain::SetBranchAddress
now automatically detect when a
branch needs to be switched to
MakeClass(also known as
DecomposedObj[ect]` mode).
TChain
now always checks the branch address; even in
the case the address is set before any TTree is loaded. Specifically in
addition to checking the address type in the case:
chain->LoadTree(0);
chain->SetBranchAdress(branch_name, &address);
now TChain
will also check the addresses in the
case:
chain->SetBranchAdress(branch_name, &address);
chain->LoadTree(0);
TTree
and TChain
no longet override user
provided sub-branch addresses. Prior to this release doing:// Not setting the top level branch address.
chain->SetBranchAdress(sub_branch_name, &address);
chain->GetEntry(0);
Resulted in the address set to be forgotten. Note that a work-around was:
// Not setting the top level branch address.
chain->GetEntry(0);
chain->SetBranchAdress(sub_branch_name, &address);
But also the address needed to (in most cases) also be set again after each new tree was loaded.
Note that, the following:
chain->SetBranchAdress(sub_branch_name, &address);
chain->SetBranchAdress(top_level_branch_name, &other_address);
chain->GetEntry(0);
will result (as one would expect) with the first SetBranchAddress being ignored/over-ridden.
RSnapshotOptions.fMode
is "UPDATE"
(i.e. the output file is opened in “UPDATE”
mode), Snapshot will refuse to write out a TTree if one with the same
name is already present in the output file. Users can set the new flag
RSnapshotOption::fOverwriteIfExists
to true
to
force the deletion of the TTree that is already present and the writing
of a new TTree with the same name. See ROOT-10573 for
more details.Higgs to two photons
,
W boson analysis
,
Higgs to four leptons
)MakeRootDataFrame
is now a safe way to construct RDFs.
It used to return RDFs with more limited functionality.W
(set
all bin errors to be equal to 1), renormalize the obtained fit parameter
errors using the obtained chi2 fit value. This is the same procedure
performed already when fitting a TGraph
.TDecompQRH
, QR decomposition in an orthogonal
matrix Q. Add a function TDecompQR::GetOrthogonalMatrix()
returning the Q matrix found by the decomposition.RooWorkspace.import()
cannot be used in Python, since it
is a reserved keyword. Users therefore had to resort to
getattr(workspace, 'import')(...)
Now,
workspace.Import(...)
has been defined for the new PyROOT, which makes calling the function easier.
RooFit’s categories were modernised. Previously, the class RooCatType was used to store category states. It stores two members, an integer for the category index, and up to 256 characters for a category name. Now, such states are stored only using an integer, and category names can have arbitrary length. This will use 4 instead of 288 bytes per category entry in a dataset, and paves the way for faster computations that rely on category states.
The interface to define or manipulate category states was also updated. Since categories are mappings from state names to state index, this is now reflected in the interface. Among others, this is now possible:
ROOT 6.22 | Before (still supported) |
---|---|
|
|
See also the Category reference guide or different RooFit tutorials, specifically rf404_categories.
RooFit’s proxy classes have been modernised. The class RooTemplateProxy
allows for access to other RooFit objects similarly to a smart pointer.
In older versions of RooFit, proxies would always hold pointers to very
abstract classes, e.g. RooAbsReal, although one wanted to work with a
PDF. Therefore, casting was frequently necessary. Further, one could
provoke runtime errors by storing an incompatible object in a proxy. For
example, one could store a variable RooRealVar
in a proxy
that was meant to store PDFs.
Now, RooFit classes that use proxies can be simplified as follows:
ROOT 6.22 | Before (still supported) | |
---|---|---|
Class definition |
|
|
Implementation |
|
|
Check the doxygen
reference guide for RooTemplateProxy
for more
information on how to modernise old code.
nullptr
instead of an incomplete
dataset.RooFormulaVar(... "x+y", x);
silently assumed that y
is zero and constant.ULong64_t, Long64_t, Short_t, UShort_t
.When defining HistFactory samples with statistical errors from C++, e.g.
Sample background1( "background1", "background1", InputFile );
background1.ActivateStatError();
statistical MC errors now default to Poisson instead of Gaussian constraints. This better reflects the uncertainty of the MC simulations, and now actually implements what is promised in the HistFactory paper. For large number of entries in a bin, this doesn’t make a difference, but for bins with low statistics, it better reflects the “counting” nature of bins. This can be reverted as follows:
// C++:
Channel chan("channel1");
chan.SetStatErrorConfig( 0.05, "Gauss" );
// Within a <Channel ... > XML:
<StatErrorConfig RelErrorThreshold="0.05" ConstraintType="Gauss" />
HistFactory was very verbose, writing to the terminal with lots of
cout
. Now, many HistFactory messages are going into RooFit’s
message stream number 2. The verbosity can therefore be adjusted
using
RooMsgService::instance().getStream(2).minLevel = RooFit::PROGRESS;
hist2workspace
is also much less verbose. The verbosity
can be restored with hist2workspace -v
for intermediate
verbosity or -vv
for what it printed previously.
MethodDNN
, defined by the
TMVA::kDNN
enumeration for building neural networks with
fully connected dense layers. It is replaced by MethodDL
(TMVA::kDL
)Architecture=Standard
for
MethodDL
. Have only CPU
or GPU
architecture options. When a BLAS implementation is not found use the
CPU architecture with matrix operations provided by the ROOT TMatrix
classes.MethodPyKeras
. Note that it requires still an independent
Keras installation with a Keras version >= 2.3TPad::RedrawAxis
to allow the
plot’s frame redrawing when erased.TCanvas::SetRealAspectRatio
to resize a
canvas so that the plot inside is shown in real aspect.When ROOT compiled with -Droot7=ON flag, one can enable geometry
drawing in web browser. Just apply –web option when starting root like:
root --web tutorials/geom/rootgeom.C
Not all features of
TGeoPainter are supported - only plain drawing of selected
TGeoVolume
ROOT 6.22 makes the new (experimental) PyROOT its default. This new PyROOT is designed on top of the new cppyy, which provides more and better support for modern C++. The documentation for cppyy and the new features it provides can be found here.
For what concerns new additions to PyROOT, this is the list:
ROOT.Numba.Declare
decorator provides a simple way
to call Python callables from C++. The Python callables are just-in-time
compiled with numba, which
ensures a runtime performance similar to a C++ implementation. The
feature is targeted to improve the performance of Python based analyses,
e.g., allows seamless integration into RDataFrame
workflows. See the tutorial pyroot004_NumbaDeclare.py
for further information.Build, Configuration and Testing Infrastructure
section).import ROOT
= False ROOT.PyConfig.ShutDown
On the other hand, there are some backwards-incompatible changes of the new PyROOT with respect to the new one, listed next:
> import ROOT
> ROOT.gInterpreter.Declare("""
template<typename T> T foo(T arg) { return arg; }
""")
> ROOT.foo['int'] # instantiation
cppyy template proxy (internal)
> ROOT.foo('int') # call (auto-instantiation from arg type)
'int'
Note that the above does not affect class templates, which can be instantiated either with parenthesis or square brackets:
> ROOT.std.vector['int'] # instantiation
<class cppyy.gbl.std.vector<int> at 0x5528378>
> ROOT.std.vector('int') # instantiation
<class cppyy.gbl.std.vector<int> at 0x5528378>
std::string
:(const char* s, size_t n) (1)
string (const string& str, size_t pos, size_t len = npos) (2) string
when invoking ROOT.std.string(s, len(s))
, where
s
is a Python string, the new PyROOT will pick (2) whereas
the old would pick (1).
None
and C++ pointer types is
not allowed anymore. Instead, ROOT.nullptr
should be
used:> ROOT.gInterpreter.Declare("""
class A {};
void foo(A* a) {}
""")
> ROOT.foo(ROOT.nullptr) # ok
> ROOT.foo(None) # fails
TypeError: void ::foo(A* a) =>
TypeError: could not convert argument 1
ROOT.Long
and ROOT.Double
to pass integer and floating point numbers by reference. In the new
PyROOT, ctypes
must be used instead.> ROOT.gInterpreter.Declare("""
void foo(int& i) { ++i; }
void foo(double& d) { ++d; }
""")
> import ctypes
> i = ctypes.c_int(1)
> d = ctypes.c_double(1.)
> ROOT.foo(i); i
2)
c_int(
> ROOT.foo(d); d
2.0) c_double(
> ROOT.gInterpreter.Declare('char MyWord[] = "Hello";')
> mw = ROOT.MyWord
> type(mw)
<class 'str'>
> mw # '\x00' is not part of the string
'Hello'
> ROOT.gInterpreter.Declare("class CppBase {};")
True
> class PyDerived(ROOT.CppBase): pass
Traceback (most recent call last):"<stdin>", line 1, in <module>
File TypeError: CppBase not an acceptable base: no virtual destructor
Old PyROOT/cppyy | New PyROOT/cppyy |
---|---|
cppyy.gbl.MakeNullPointer(klass) | cppyy.bind_object(0, klass) |
cppyy.gbl.BindObject / cppyy.bind_object | cppyy.bind_object |
cppyy.AsCObject | libcppyy.as_cobject |
cppyy.add_pythonization | cppyy.py.add_pythonization |
cppyy.compose_method | cppyy.py.compose_method |
cppyy.make_interface | cppyy.py.pin_type |
cppyy.gbl.nullptr | cppyy.nullptr |
cppyy.gbl.PyROOT.TPyException | cppyy.gbl.CPyCppyy.TPyException |
buffer.SetSize(N) | buffer.reshape((N,)) |
obj.__cppname__ | obj.__cpp_name__ |
obj._get_smart_ptr | obj.__smartptr__ |
callable._creates | callable.__creates__ |
callable._mempolicy | callable.__mempolicy__ |
callable._threaded | callable.__release_gil__ |
python my_script.py -b
, the
-b
argument will not be parsed by PyROOT, and therefore the
batch mode will not be activated. If the user wants to enable the PyROOT
argument parsing again, they can do so by starting their Python script
with:import ROOT
= False ROOT.PyConfig.IgnoreCommandLineOptions
addressof
should be used to retrieve the
address of fields in a struct, for example:> ROOT.gInterpreter.Declare("""
struct MyStruct {
int a;
float b;
};
""")
> s = ROOT.MyStruct()
> ROOT.addressof(s, 'a')
94015521402096L
> ROOT.addressof(s, 'b')
94015521402100L
> ROOT.addressof(s)
94015521402096L
In old PyROOT, AddressOf
could be used for that purpose
too, but its behaviour was inconsistent. AddressOf(o)
returned a buffer whose first position contained the address of object
o
, but Address(o, 'field')
returned a buffer
whose address was the address of the field, instead of such address
being contained in the first position of the buffer. Note that, in the
new PyROOT, AddressOf(o)
can still be invoked, and it still
returns a buffer whose first position contains the address of object
o
.
TPyMultiGenFunction
and TPyMultiGradFunction
which inherited from ROOT::Math::IMultiGenFunction
and
ROOT::Math::IMultiGradFunction
, respectively. The purpose
of these classes was to serve as a base class for Python classes that
wanted to inherit from the ROOT::Math classes. This allowed to define
Python functions that could be used for fitting in Fit::Fitter. In the
new PyROOT, TPyMultiGenFunction
and
TPyMultiGradFunction
do not exist anymore, since their
functionality is automatically provided by new cppyy: when a Python
class inherits from a C++ class, a wrapper C++ class is automatically
generated. That wrapper class will redirect any call from C++ to the
methods implemented by the Python class. Therefore, the user can make
their Python function classes inherit directly from the ROOT::Math C++
classes, for example:import ROOT
from array import array
class MyMultiGenFCN( ROOT.Math.IMultiGenFunction ):
def NDim( self ):
return 1
def DoEval( self, x ):
return (x[0] - 42) * (x[0] - 42)
def Clone( self ):
= MyMultiGenFCN()
x False)
ROOT.SetOwnership(x, return x
def main():
= ROOT.Fit.Fitter()
fitter = MyMultiGenFCN()
myMultiGenFCN = array('d', [1.])
params
fitter.FitFCN(myMultiGenFCN, params)True)
fitter.Result().Print(ROOT.std.cout,
if __name__ == '__main__':
main()
Fixed in 6.22/04, true for 6.22/00 and 6.22/02: Inheritance
of Python classes from C++ classes is not working in some cases. This is
described in ROOT-10789 and
ROOT-10582.
This affects the creation of GUIs from Python, e.g. in the Python GUI
tutorial, where the inheritance from TGMainFrame
is not
working at the moment. Future releases of ROOT will fix these issues and
provide a way to program GUIs from Python, including a replacement for
TPyDispatcher, which is no longer provided.
When iterating over an
std::vector<std::string>
from Python, the elements
returned by the iterator are no longer of type Python str
,
but cppyy.gbl.std.string
. This is an optimization to make
the iteration faster (copies are avoided) and it allows to call modifier
methods on the std::string
objects.
> import cppyy
> cppyy.cppdef('std::vector<std::string> foo() { return std::vector<std::string>{"foo","bar"};}')
> v = cppyy.gbl.foo()
> type(v)
<class cppyy.gbl.std.vector<string> at 0x4ad8220>
> for s in v:
print(type(s)) # s is no longer a Python string, but an std::string
...
...<class cppyy.gbl.std.string at 0x4cd41b0>
<class cppyy.gbl.std.string at 0x4cd41b0>
TMVA_Higgs_Classification.C
showing the usage of the
TMVA deep neural network in a typical classification problem,TMVA_CNN_Classification.C
showing the usage of CNN in
TMVA with MethodDL
and in PyMVA using
MethodPyKeras
,TMVA_RNN_Classification.C
showing the usage of RNN in
both TMVA and Keras.-Dbuiltin_xrootd=ON
is not necessary anymore to build ROOT
with xrootd support. Note that built-in xrootd requires a working
network connection.Added a build flag asan
that switches on address
sanitizer. It’s experimental, so expect problems. For example, when
building with gcc, manipulations in global variables in llvm will abort
the build. Such checks can be disabled using environment variables.
Check the address sanitizer documentation or the link below for details.
In clang, which allows to blacklist functions, the build will
continue.
See core/sanitizer for information.
Many (but intentionally not all) unused includes were removed from
ROOT header files. For instance, #include "TObjString.h"
and #include "ThreadLocalStorage.h"
were removed from
TClass.h
. Or #include "TDatime.h"
was removed
from TDirectory.h
header file . Or
#include "TDatime.h"
was removed from TFile.h
.
This change may cause errors during compilation of ROOT-based code. To
fix it, provide missing the includes where they are really required.
This improves compile times and reduces code inter-dependency; see
https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/WhyIWYU.md
for a good overview of the motivation.
Even more includes will be “hidden” when ROOT configured with
-Ddev=ON
build option. In that case ROOT uses
#ifdef R__LESS_INCLUDES
to replace unused includes by class
forward declarations. Such dev
builds can be used to verify
that ROOT-based code really includes all necessary ROOT headers.
In 6.22, the new (experimental) PyROOT is built by default. In order
to build with the old PyROOT instead, the option
-Dpyroot_legacy=ON
can be used. This is a summary of the
PyROOT options:
pyroot
: by default ON
, it enables the
build of PyROOT.pyroot_legacy
: by default OFF
, it allows
the user to select the old PyROOT (legacy) to be built instead of the
new one.pyroot_experimental
: this option is
deprecated in 6.22 and should no longer be used. If
used, it triggers a warning.This new PyROOT also introduces the possibility of building its libraries for both Python2 and Python3 in a single ROOT build (CMake >= 3.14 is required). If no option is specified, PyROOT will be built for the most recent Python3 and Python2 versions that CMake can find. If only one version can be found, PyROOT will be built for only that version. Moreover, for a given Python installation to be considered, it must provide both the Python interpreter (binary) and the development package.
The user can also choose to build ROOT only for a given Python
version, even if multiple installations exist in the system. For that
purpose, the option
-DPYTHON_EXECUTABLE=/path/to/python_exec
can be used to
point to the desired Python installation.
If the user wants to build PyROOT for both Python2 and Python3, but
not necessarily with the highest versions that are available on the
system, they can provide hints to CMake by using
-DPython2_ROOT_DIR=python2_dir
and/or
-DPython3_ROOT_DIR=python3_dir
to point to the root
directory of some desired Python installation. Similarly,
Python2_EXECUTABLE
and/or Python3_EXECUTABLE
can be used to point to particular Python executables.
When executing a Python script, the Python version used will
determine which version of the PyROOT libraries will be loaded.
Therefore, once the ROOT environment has been set (e.g. via
source $ROOTSYS/bin/thisroot.sh
), the user will be able to
use PyROOT from any of the Python versions it has been built for.
Regarding TPython
, its library is built only for the
highest Python version that PyROOT is built with. Therefore, in a
Python3-Python2 ROOT build, the Python code executed with
TPython
must be Python3-compliant.
RooNDKeysPdf
has no default constructor which causes a
crash when reading it from a workspaceRooSimultaneous
RooTreeDataStore
not Cloning the tree properly (and const
correctness)RooDataSet
reduce(Cut(mycut))
and
Draw(myvar,mycut)
give different resultsRooLinearVar
from a
RooWorkspace
RooDataSet::createHistogram
methodsRooFitResult
and
HypoTestInverterResult
from diskTH2
histogramTFile
from use of
TSystem
GetBinErrorUp
in
TH2D
TH2
FitSlicesX()
and TH3
FitSlicesZ()
don’t use the axis range set by userjsmva on
package util not foundTTreeProcessorMT
can’t deal with trees with different
names in the same TChain
RDataFrame
: sub-par diagnostics for interpreted
typesTClass::GetListOfMethods
does not include constructor for
std::hash
TChain::Add
and TChain::AddFile
broken with
URL that contains double slashesRooAbsPdf::chi2FitTo
overloads get lost in PyROOTRDataFrame
created from TChain
after calling
TChain::AddFriend()
crashes when trying to plot a variable
if MultiThread is enabledRooFit::CutRange
is buggy with multiple rangechi2FitTo
and fitTo
are not working properly
with multiple rangesTChain::AddFriend()
RDataFrame
Display()
crashes with column of
std::string
Error in <TClass::ReadRules()>: Cannot find rules etc/class.rules
.qqqqqq
does not exit rootRDataFrame
warns but does not throw when skipping files
after network glitchplotOn
normalization crazy and error message when doing
loops of toysEnableImplicitMT
onRDataFrame::Cache
fails when used with
RDataFrame::Alias
plotOn
reproducibly crashes when having done many
toys before, in a specific configurationSnapshot
fails to update TTree
if
Multithreading enabledpyroot_experimental
TMVA::Experimental
Intel compiler supportTH1::KolmogorovTest
when using option
XROOT::MakeRootDataFrame
-Dcuda=yes
when cudnn
not installedrootls -t
doesn’t work with multiple cycles for a
treeTH2::FitSlicesX
/Y
RooSimWSTool
RooFit
functionality due to
cppyy changes%jsroot on
copy_string=history.history.keys()[0]
RooArgSet::writeToStream
TTree
writingrootmv
doesn’t work with multiple cycles
TTrees
in TFiles
TTreeProcessorMT
leaves implicit multi-threading enabled
after a call to Process
-I
flags provided for dictionary compilationrootcling
produces uncompilable dictionary if class
depends on boost headersRooFit
with Asymptotically Correct approach will segfault
if RooRealVar
Name != Title
hesse
does not know which minimizer to useTTreeCache
from
TChain
RooDataSet
from TTree
with
cuts causes warningsRVec<bool>
comparison results in infinite loopcppyy
only provides addressof
, not
AddressOf
RVec
TDirectory::GetObject()
with wrong type leaks memoryTMultiGraph
with single
TGraphAsymErrors
different from single graph fit-Dmathmore=ON
TMultiGraph
RooStats::HypoTestInverterResult
TMath::Poisson(n,mu)
for n = 0
and
mu < 0
returns wrong value !fTree
in
TChain
destructorbool*
hadd
brokenRooAbsPdf
is distorted outside its “Range” used
previously with fitTo
TChain
+TEntryList
make_shared
/shared_ptr
RooAbsAnaConvPdf
crashes when being imported and
retrieved from RooWorkspace
FuncOps__::__le__
rootbrowse
freezes after startupstdexcept
Snapshot
into a directory also creates
a spurious TTree
outside of itSnapshot
of TClonesArrays
read via
TTreeReaderArray
is brokenEventLoop
packageclang::Sema::LookupSpecialMember
Rtypes.h
and
TGenericClassInfo.h
RVec
s of non-split branches can read from invalid
addressesROOT.py
hadd
crashes when slow merging file with multiple array
with same indexTHashTable
ULong64_t
RooNDKeysPDF
SPlot
crashes when yields are not the top level
fitparametersHistFactory
output is too verbose and cannot be
controlledHistFactory
HistoToWorkspaceFactoryFast
RooAbsData::getRange()
argument var should be constTFile::ReadProcessID
thread safePublished on August 17, 2020
TTrees
, RDataFrame’s
GetColumnNames
method returns multiple valid spellings for
a given column. For example, leaf "l"
under branch
"b"
might now be mentioned as "l"
as well as
"b.l"
, while only one of the two spellings might have been
recognized before.libNew.so
crashTVector3
pointersTBranchObject
MakeProxy
std::map<int,std::vector<double,*>>
RooArgSet
IsOnHeap
result incorrectTPython
documentation is gonestd::shared_ptr
in 6.22/00JupyROOT
with conda ROOTDisplay
actionchar*
branches is brokenRooCategory
doesn’t update its label when its state is
dirty.noRounding=true
RooSimultaneous
TBranchObjects
(e.g. branches
containing TH2F
)Published on an unlucky Friday, November 13, 2020, this release had a fatal issue in the I/O subsystem, which is why it was never announced. Please use 6.22/06 instead!
TGMainFrame
(see ROOT-10826);
such error is no longer there and GUIs can be programmed again from
Python, using the TPyDispatcher
class as before. Moreover,
the inheritance from TSelector
has been fixed too, which
makes it possible to extend TSelector
by directly
inheriting from it, instead of using the TPySelector
class
that was provided in the old PyROOT (see ROOT-11025).[ROOT-8173]
- RooStreamParser
not working for float number with
negative exponent
[ROOT-8331]
- Error in the member function
Multiply(const Double_t *vin, Double_t* vout, Double_t w)
in TEveTrans
of Eve package
[ROOT-9563] - [TreeProcMT] Trees in subdirectories are not supported (and their usage lead to a crash)
[ROOT-9674] - [DF] Wrong branch type inference in some cases
[ROOT-10152] - [DF] Cannot analyze friend trees in subdirectories with MT
[ROOT-10786] - Cling not intepreting using directive
[ROOT-10826] - Inheritance issue when creating GUI from Python
[ROOT-10849]
- Recursive ASTReader
assertion Fedora32 C++17
[ROOT-10862] - TMVA in ROOT 6.22/00 doesn’t use the built-in GSL library correctly
[ROOT-10886]
- 6.22/00 Build failure with Clang 7.0.0 on SL7 with
-Druntime_cxxmodules:BOOL=ON
[ROOT-10896]
- IMT Snapshot
segfault when TTree
switches
over multiple files
[ROOT-10935]
- RooDataSet::read()
no longer accepts
RooCategory
numbers
[ROOT-10942] - [DF] Regression in recognition of nested branch names
[ROOT-10993]
- ROOT fails in loading nlohmann/json
[ROOT-11000]
- rootcling
fails for Gaudi classes
[ROOT-11001]
- unable to create TChain
on ROOT file
[ROOT-11010] - PyROOT cross-inheritance fails to call proper constructor
[ROOT-11013]
- “Impossible code path” in TGenCollectionProxy.cxx
when
using rootcling
[ROOT-11015] - OpenGL rendering is incorrect for “pgon - pgon”
[ROOT-11025]
- Issue with automatic C++ wrapper during inheritance (to replace
TPySelector
)
[ROOT-11027] - Lxplus ROOT installation not showing graphics from Python
[ROOT-11030]
- pythonization segfault with derived TTree
class in
namespace
[ROOT-10844] - Check GUI-related PyROOT tutorials
[ROOT-10872] - cppyy tries to generate copy constructors for non copyable classes
#6529 -
segfault in RooWorkspace::import
#6408 -
Creating RooDataSet
causes SegFault
#6553 - TMVA Provide support in MethodPyKeras
for
tensorflow.keras
#6455 - [DF]
RDataSource
does not early-quit event loops when all Ranges
are exhausted
#6579 -
PyROOT:
AttributeError: Failed to get attribute TPyDispatcher from ROOT
#6435 - [DF]
Jitted Min
method breaks with RVec
columns
#6467 -
TChain
issue in PyROOT with conda
#6376 - vtable corruption in Python specialization of C++ classes
#6356 -
[JupyROOT][roottest] New nbconvert
versions break notebook
comparisons
#6482 -
TClass::GetListOfFunctions()
fails to enumerate using
decls.
#6359 -
python: interpreter/llvm/src/include/llvm/Support/Casting.h:106:
static bool llvm::isa_impl_cl<To, const From*>::doit(const From*)
[with To = clang::UsingDecl
; From =
clang::Decl
]: Assertion ‘Val && “isa<> used
on a null pointer”’ failed.
#6578 -
Using declaration of TGMainFrame
constructor not taken into
account
#6666 -
TClass::GetListOfDataMembers
returns an empty list
even-though the information is available.
#6725 -
rootpcm does not record TEnum
’s underlying type
#6726 -
TStreamerInfo::GenerateInfoForPair
generates the wrong
offset if an enum type is first.
#6670 -
segfault in TClass::InheritsFrom()
depending on linking
order
#6465 - ROOT signed-char convertion issue on AARCH64
#6443 - Spurrious auto-parsing (as seen with CMS file and libraries)
#6509 -
[ROOT I/O]
Warning: writing 1 byte into a region of size 0
Published on Friday, November 27, 2020.
This version supports macOS 11.0 (aka “Big Sur”), which required
several adjustments on ROOT’s side. Starting with this version, ROOT
also supports Apple’s ARM-architecture M1 processor (“Apple Silicon”).
Note that tbb
does not officially support Apple’s M1 chip.
ROOT will implement a workaround for this in an upcoming release.
TClass
for pair
sometimes have the wrong
offset/sizebuild/unix/compiledata.sh
assumes macOS will always have
major version 10TCling::UpdateListOfLoadedSharedLibraries()
Linux thread
safetyPublished on March 10, 2021
Due to false positive virus scanner reports, all previous Windows binaries of ROOT have been removed. These false positives were addressed by a trivial change to ROOT’s sources which is available since 6.22/08.
The following builtins have been updated:
-DVDT=OFF
These changes will be part of a future 6.22/10.