Introduction

ROOT version 6.00/00 has been released on May 30, 2014. It introduces the new Cling C++11 interpreter, replacing CINT that has served ROOT well for many years.

For more information, see:

http://root.cern.ch

The following people have contributed to this new version:

Bertrand Bellenot, CERN/SFT,
Dario Berzano, CERN/SFT,
Rene Brun, CERN/SFT,
Ioan Gabriel Bucur, CERN/SFT
Philippe Canal, FNAL,
Cristina Cristescu, CERN/SFT,
Olivier Couet, CERN/SFT,
Kyle Cranmer, NYU, RooStats,
Anders Eie, NTNU,
Gerri Ganis, CERN/SFT,
Andrei Gheata, CERN/Alice,
Wim Lavrijsen, LBNL, PyRoot,
Sergey Linev, GSI, http,
Anna-Pia Lohfink,
Pere Mato, CERN/SFT,
Lorenzo Moneta, CERN/SFT,
Axel Naumann, CERN/SFT,
Danilo Piparo, CERN/SFT,
Timur Pocheptsov, CERN/SFT,
Fons Rademakers, CERN/SFT,
Paul Russo, FNAL,
Joerg Stelzer, DESY/Atlas, TMVA,
Alja Tadel, UCSD/CMS, Eve,
Matevz Tadel, UCSD/CMS, Eve,
Eckhard von Toerne, University Bonn, ATLAS, TMVA,
Vassil Vassilev, CERN/SFT
Wouter Verkerke, NIKHEF/Atlas, RooFit,
Yue Shi Lai, MIT

Platform Support

Temporarily for version 6.00/00, ROOT has a reduced set of supported platforms. Most notably Windows is not supported until at least 6.02. 6.00/00 supports only

More platforms are expected to be available later; the lack of support stems from Cling and Clang/LLVM not being ported to these platforms yet.

To aleviate the pain for Windows users who want to try ROOT 6 we provide a recipe on how to run ROOT 6 in a VM on Windows.

Building ROOT also requires a C++11 compatible compiler, so one needs to either have installed gcc >= 4.8 or Clang >= 3.4. On most lecagy platforms these newer compilers are available via a special install. See the build prerequisites page.

Despite that, an additional platform as been added: the x32 psAPI, called linuxx32gcc. It is a regular x86-64 ABI but with shorter pointers (4 bytes instead of 8). This reduces the addressable memory per process to 4GB - but that is usally sufficient. The advantages are reduced memory consumption (due to the smaller pointers) and increased performance compared to 32 bit applications due to the availability of the 64 bit instructions. The Clang developers mailing list archive contains a good comparison.

To build and run binaries compiled in x32, toolchain support is needed. That is available in the in binutils (2.22), GCC (4.8), glibc (2.16), Linux kernel (3.4) and even GDB (7.5). These versions are not available in regular distributions yet (except for this beta Gentoo distro built in x32); once they are, building and running x86-64 and x32 side-by-side will be possible.

Build System

ROOT 6.00/00 can be built either using the classic “./configure;make” method or using CMake. The CMake system has been completed for this version and should be functionally equivalent to the classic one. The detailed instructions are available. In upcoming releases the classic method will slowly be deprecated in favor of the CMake one.

Core Libraries

Cling vs CINT

Cling follows the C++ standard much more strictly than CINT. In particular some code that used to run with CINT will either issue new warnings or new compilation errors. For example when CINT was parsing Namespace::Symbol it would not only apply the C++ search rules but also search in the outer scopes and for this example could actually return ::Symbol instead of (as Cling now does) issuing a compilation error.

Template class names

Cling no longer supports refering to a class template instantiation of a class template that has all default template parameter without the <>. With:

   template <typename T = int> class templt {};

With Cling (and any standard compliant compiler), using *templt<>* is allowed (but *templt* is not).

Namespace prefix of template parameters

Given namespace N { class A; template <typename T> class B;}, the name N::B<N::A> is no longer “shortened” to N::B<A>. This affects the forward and backward compatibility of files.

Implicit dynamic up-casts

CINT would perform automatic upcasts to derived classes under certain contexts:

   TH1* h1 = hpx
   TH1F* h1f = h1;

Cling does not allow this anymore. We might add this feature later if demand exists (ROOT-4802).

Using symbols that are only available at runtime: load libFoo; foo()

CINT was processing macros line by line; Cling compiles code. When calling a function (or in general using a symbol) that is provided by a library loaded at runtime, Cling will in some cases report an unresolved symbol:

   #include "Event.h"
   void dynload() {
      gSystem->Load("libEvent");
      new Event();
   }

You will currently have to provide a rootmap file for libEvent (which also requires include guards for Event.h). This might get fixed in a later version (ROOT-4691).

Using identifiers that are only available at runtime: gROOT->LoadMacro(“foo.h”); foo()

CINT was processing macros line by line; Cling compiles code. During this compilation, Cling will not see identifiers provided by gROOT->LoadMacro(). While this will covered by dynamic scopes, they are currently too limited to handle this. Please #include the header instead.

TInterpreter

TInterpreter

TInterpreter::GetCurrentMacroName() has a slightly different behavior in ROOT 6 than in ROOT 5. In ROOT 5 it was a synonym for __FILE__ (so please use __FILE__ to get the old value); in ROOT 6 it returns the currently executing (.x) source file. For nested execution it returns the innermost one.

The following are no longer supported and are now only issuing error messages:

Use of Setgvp and Getgvp should be looked at carefully as they were use to control the behavior of the multiplexing CINT wrappers that were both wrapper the calls to operator new with and without placement and the constructor (and similarly for operator delete and the destructor). Cling does not support such a multiplexing wrapper and alternatively interface must be used (See TClass::New and TClass::Destructor for example).

The following interfaces are not yet available:

They might be re-implemented in a later version.

rootcling, rootcint and genreflex

rootcling is the successor to rootcint and it preserves its old commandline arguments and provides more (see help). The executable rootcint still exists but it is just a redirection to rootcling. The following backward incompatibilities are present between rootcint in version 5 and rootcling in version 6:

       Error: in this version of ROOT, the option '!' used in a linkdef file
              implies the actual existence of customized operators.
              The following declaration is now required:
          TBuffer &operator<<(TBuffer &,const THit *);

if the operator << declaration is missing.

To steer the parsing done during the execution of rootcling, a new macro: __ROOTCLING__ is now defined during the parsing. The macros __CINT__ and __MAKECINT__ are defined only when looking for #pragma statement.

The genreflex executable is still available, it preserves the same command line options as in version 5 and provides new ones. Old selection XML files are transparently usable by the new implementation. On the other hand some of the new functionalities can be hardly backported to version 5. See genreflex help for all the details about commandline switches and selection files. It is important to note that it is not anymore a python script interfaced to GCCXML but rather a wrapper around rootcling.

In order to specify the classes selection, three methods are available:

  1. Selection XML file. This file can be read by both genreflex and rootcling.
  2. LinkDef file. This file can be read by rootcling.
  3. Selection namespace (also called dictselection). Available both for rootcling and genreflex. See the documentation of the ROOT::Meta::Selection namespace for all the details.

Warning

It is important to note that during the parsing of the header files, rootcint no longer defines __CINT__ and genreflex no longer defines __GCCXML__. This means in particular that data members that were made transient by hiding them from rootcint or genreflex now must be explicitly marked as transient. For rootcint or rootcling use:

   sometype datamember; //! The exclamation mark signals the transientness

and for genreflex

   <class name="edm::Particle" >
      <field name="m_calculated" transient="true" />
   </class>

or

   <class name="edm::Particle" >
      <field name="m_calculated" persistent="false" />
   </class>

This new set of executables are responsible also for the generation of pcm files. These are crucial for the functioning of ROOT and must reside in the same directory of the libraries which contain the compiled dictionaries.

rlibmap

The tools used to generate rootmap files are rootcling and genreflex. The rlibmap tool is not present any more in ROOT starting from release 6.00.00.

Rootmap files

To enhance the set of functionalities offered by ROOT and its new interpreter, the format of the rootmaps evolved. Rootmap in the old format cannot be produced anymore but only read. The new rootmaps can be still be concatenated. A rootmap file now contains:

At ROOT startup, a check is performed on autoload keys. If the same key (which is not a template instantiation) refers to two different libraries (or sets of libraries) a warning is issued. A typical Rootmap file look like:

{ decls }
fwd declaration 1;
fwd declaration 2;
[...]
fwd declaration N;

[ libraryName1 libraryName2 ... ]
class className1
class className2
...
typedef typedefName1
typedef typedefName2
...
header headerName1
header headerName2
...

TROOT

The list returned by GetListOfTypes is no longer filled when the dictionary are loaded but instead are filled on demand, when the user explicitly (directly or indirectly) request each typedef. In particular this means that

   gROOT->GetListOfTypes()->ls(); // or Print()

no longer prints the list of all available typedef but instead list only the typedefs that have been previously accessed throught the list (plus the builtins types).

ACliC

ACLiC has the following backward incompatibilities:

Collection

New collection TListOfTypes that implements on demand creation of the TDataType describing a typedef.

TUnixSystem

TMacOSXSystem

TColor

TAttText

TAttFill

TAttMarker

TAttLine

TAttAxis

I/O Libraries

I/O Behavior change.

Classes with custom streamer

Classes for which a Streamer function was externally provided are no longer split; they were split in v5 if the dictionary was generated via rootcint but were not split if the dictionary was generated via genreflex.

Classes with a custom Streamer function and classes with an older, non StreamerInfo based automatic streamer are also no longer split.

To force the splitting of those classes, thus by-passing the custom Streamer, when storing the object in a TTree and in a collection object, use:

       TClass::GetClass(classname)->SetCanSplit(true);

I/O Schema Checksum

The algorithm used to calculate a single number giving an indication on whether the schema layout has changed (i.e. if two StreamerInfo are equivalent) have been update to

The algorithm that checks whether two StreamerInfo are equal even-though their checksum is different has been significantly enhanced in particular to also check the base classes.

TFileMerger

       TFileMerger::AddObjectNames(const char *names)

This method can be called several times to add object names. Several names can be added with one call separated by single blancs (no blanc at the end). Directory names are accepted, applying the merging selection to all content. Two new options are being supported for partial merging:

       TFileMerger::PartialMerge(flags | kOnlyListed)

This will merge only the objects in the files having the names in the specified list. If a folder is specified, it whole content will be merged

        TFileMerger::PartialMerge(flags | kSkipListed)

This will skip merging for the specified objects. If a folder is specified, its whole content will be skipped

Important note: The kOnlyListed and kSkipListed flags have to be bitwise OR-ed on top of the merging defaults: kAll | kIncremental (as in the example $ROOTSYS/tutorials/io/mergeSelective.C)

Networking Libraries

A new class TS3WebFile has been introduced. The new class TS3WebFile is an extension of TWebFile and belongs to the net module. The name TS3WebFile reflects better the fact that this solution is intended to be generic to several S3 servers and not limited to Amazon’s, in addition to the fact that it actually extends the capabilities of TWebFile.

Compared to the current support of S3 in ROOT (basically the class TAS3File), the modifications include the improvements below:

Here are some examples of usages from the end user perspective:

       TFile* f = TFile::Open("s3://s3.amazonaws.com/mybucket/path/to/my/file", "AUTH=<accessKey>:<secretKey> NOPROXY")
       TFile* f = TFile::Open("s3://s3.amazonaws.com/mybucket/path/to/my/file")   // Uses environmental variables for retrieving credentials

Limitations:

The TAS3File class will be removed and should not have been used directly by users anyway as it was only accessed via the plugin manager in TFile::Open().

New HTTP Server package

A new HTTP Server package has been introduced. The idea behind such server is to provide direct access to the data from a running ROOT application. Any object can be streamed when requested and delivered to the browser.

Starting HTTP server

To start http server, at any time create instance of the THttpServer class like:

serv = new THttpServer("http:8080");

This will start civetweb-based http server on port 8080. Then, one should be able to open address “http://localhost:8080” in any modern browser and browse objects created in application. By default, the server can access files, canvases and histograms via gROOT. All such objects can be displayed with JSRootIO graphics.

At any time one could register other objects with the command:

    TGraph* gr = new TGraph(10);
    gr->SetName("gr1");
    serv->Register("graphs/subfolder", gr);

If the object content is changing in the application, like for example histograms being continuously filled, one could enable the monitoring flag in the browser, then the object view will be regularly updated.

SQL Libraries

Tree Libraries

TTreeReader

ROOT offers a new class TTreeReader that gives simple, safe and fast access to the content of a TTree. Using it is trivial:

#include "TFile.h"
#include "TH1F.h"
#include "TTreeReader.h"
#include "TTreeReaderValue.h"

void hsimpleReader() {
   TH1F *myHist = new TH1F("h1","ntuple",100,-4,4);
   TFile *myFile = TFile::Open("hsimple.root");

   // Create a TTreeReader for the tree, for instance by passing the
   // TTree's name and the TDirectory / TFile it is in.
   TTreeReader myReader("ntuple", myFile);

   // The branch "px" contains floats; access them as myPx.
   TTreeReaderValue<Float_t> myPx(myReader, "px");
   // The branch "py" contains floats, too; access those as myPy.
   TTreeReaderValue<Float_t> myPy(myReader, "py");

   // Loop over all entries of the TTree or TChain.
   while (myReader.Next()) {
      // Just access the data as if myPx and myPy were iterators (note the '*'
      // in front of them):
      myHist->Fill(*myPx + *myPy);
   }

   myHist->Draw();
}

TTreeReader checks whether the type that you expect can be extracted from the tree’s branch and will clearly complain if not. It reads on demand: only data that are actually needed are read, there is no need for SetBranchStatus(), SetBranchAddress(), LoadTree() or anything alike. It uses the memory management of TTree, removing possible double deletions or memory leaks and relieveing you from the need to manage the memory yourself. It turns on the tree cache, accelerating the reading of data. It has been extensively tested on all known types of TTree branches and is thus a generic, fits-all access method for data stored in TTrees.

TTreePlayer

PROOF System

All the fixes and improvements in the PROOF system occured since the release of 5.34/00 are available both in the latest 5.34 tags and in 6.00/00. The following is a summary of the major modifications since 5.34 .

New developments/functionality

    $ xpdtest [options]
       --help, -h
              Gives a short list of options avaliable, and exit
       -t <test>
              type of test to be run:
                  0       ping the daemon (includes process existence check if pid specified; see below)
                  1       ping the daemon and check connection for default user
                  2       ping the daemon and check connection for the default user and all recent users
...
    root[] p = TProof::Open("master", "igprof-pp")

Bug fixes

Several consolidation fixes in several parts of the system (see the 5.34 patch release notes for details). In particular, those for ‘xproofd’ were provided by B. Butler and M. Swiatlowski and greatly contributed to consolidate the daemon.

Histogram Libraries

THistPainter

TGraphPainter

TPaletteAxis

TAxis

TH1

TH2, TH3

TGraph

TGraph2D

TMultiGraph

THStack

TH2Poly

TF1

TF2, TF3

TFractionFitter, TBinomialFitter

Python Bindings

The Python bindings are fully supported in ROOT 6.

Ruby Bindings

The Ruby bindings have not been ported yet to the new interpreter interface in ROOT 6. We hope to have this fixed in a future release.

Math Libraries

Minuit2

All other changes in the Math packages have been applied also in the 5.34 patched versions of ROOT. See their release notes for the detailed list of applied improvements.

RooFit Package

TMVA Package

Geometry Libraries

MonteCarlo Libraries

GUI Libraries

Attributes editors

Object editing on canvas

Saving Files

ROOT browser and pad editor

2D Graphics Libraries

TASImage

TPDF and TPostScript

TImageDump

TSVG

New class TTeXDump: Graphics interface to TeX

This class allow to generate PGF/TikZ vector graphics output which can be included in TeX and LaTeX documents.

PGF is a TeX macro package for generating graphics. It is platform and format-independent and works together with the most important TeX backend drivers, including pdftex and dvips. It comes with a user-friedly syntax layer called TikZ.

To generate a such file it is enough to do:

   gStyle->SetPaperSize(10.,10.);
   hpx->Draw();
   gPad->Print("hpx.tex");

Then, the generated file (hpx.tex) can be included in a LaTeX document (simple.tex) in the following way:

\documentclass{article}
\usepackage{tikz}
\usetikzlibrary{patterns}
\title{A simple LaTeX example}
\date{July 2013}
\begin{document}
\maketitle
The following image as been generated using the TTeXDump class:
\par
\input{hpx.tex}
\end{document}

Note the two directive needed at the top of the LaTeX file:

\usepackage{tikz}
\usetikzlibrary{patterns}

Then including the picture in the document is done with the \input directive.

The command pdflatex simple.tex will generate the corresponding pdf file simple.pdf.

X11 fonts

TCanvas and TPad

TGaxis and TAxis

...
   TGaxis::SetMaxDigits(2);
   TGaxis::SetExponentOffset(-0.01, 0.01, "y"); // X and Y offset for Y axis
   TGaxis::SetExponentOffset(-0.05, 0.01, "x"); // Y and Y offset for X axis
...
   hist->Draw();

TLegend

TPie

TLine

TMathText

    {
       TMathText l;
       l.SetTextAlign(23);
       l.SetTextSize(0.06);
       l.DrawMathText(0.50, 1.000, "\\prod_{j\\ge0} \\left(\\sum_{k\\ge0} a_{jk}z^k\\right) = \\sum_{n\\ge0} z^n \\left(\\sum_{k_0,k_1,\\ldots\\ge0\\atop k_0+k_1+\\cdots=n} a_{0k_0}a_{1k_1} \\cdots \\right)");
       l.DrawMathText(0.50, 0.800, "W_{\\delta_1\\rho_1\\sigma_2}^{3\\beta} = U_{\\delta_1\\rho_1\\sigma_2}^{3\\beta} + {1\\over 8\\pi^2} \\int_{\\alpha_1}^{\\alpha_2} d\\alpha_2^\\prime \\left[ {U_{\\delta_1\\rho_1}^{2\\beta} - \\alpha_2^\\prime U_{\\rho_1\\sigma_2}^{1\\beta} \\over U_{\\rho_1\\sigma_2}^{0\\beta}} \\right]");
       l.DrawMathText(0.50, 0.600, "d\\Gamma = {1\\over 2m_A} \\left( \\prod_f {d^3p_f\\over (2\\pi)^3} {1\\over 2E_f} \\right) \\left| \\mathscr{M} \\left(m_A - \\left\\{p_f\\right\\} \\right) \\right|^2 (2\\pi)^4 \\delta^{(4)} \\left(p_A - \\sum p_f \\right)");
       l.DrawMathText(0.50, 0.425, "4\\mathrm{Re}\\left\\{{2\\over 1-\\Delta\\alpha} \\chi(s) \\left[ \\^{g}_\\nu^e \\^{g}_\\nu^f (1 + \\cos^2\\theta) + \\^{g}_a^e \\^{g}_a^f \\cos\\theta \\right] \\right\\}");
       l.DrawMathText(0.50, 0.330, "p(n) = {1\\over\\pi\\sqrt{2}} \\sum_{k = 1}^\\infty \\sqrt{k} A_k(n) {d\\over dn} {\\sinh \\left\\{ {\\pi\\over k} \\sqrt{2\\over 3} \\sqrt{n - {1\\over 24}} \\right\\} \\over \\sqrt{n - {1\\over 24}}}");
       l.DrawMathText(0.13, 0.150, "{(\\ell+1)C_{\\ell}^{TE} \\over 2\\pi}");
       l.DrawMathText(0.27, 0.110, "\\mathbb{N} \\subset \\mathbb{R}");
       l.DrawMathText(0.63, 0.100, "\\hbox{RHIC スピン物理 Нью-Йорк}");
    }
TMathText example

TMathText example

TLatex

       TLatex t; t.DrawLatex( 0.1,0.1,"text   #Lambda" )

TPave

TLinearGradient and TRadialGradient

TRadialGradient example

TRadialGradient example

TLinearGradient example

TLinearGradient example

Gradient example

Gradient example

TGCocoa and TGQuartz

3D Graphics Libraries

Gl in Pad

Html Generator

Misc Packages

Tutorials

ROOT page - Class index - Top of the page