ROOT Version 5.12/00 Release Notes

ROOT version 5.12/00 has been released July 11, 2006.

Binaries for all supported platforms are available at:
Versions for AFS have also been updated. See the list of supported platforms:

For more information, see:

The following people have contributed to this new version:
Mohammad Al-Turany,
Ilka Antcheva,
Maarten Ballintijn,
Bertrand Bellenot,
Denis Bertini,
Sebastian Boser,
Rene Brun,
Philippe Canal,
Federico Carminati,
Olivier Couet,
Christophe Delaere,
Giulio Eulisse,
Jan Fiete Grosse-Oetringhaus,
Valeri Fine,
Leo Franco,
Markus Frank,
Fabrizio Furano,
Gerri Ganis,
Andrei Gheata,
Mihaela Gheata,
Thorsten Glebe,
Andy Hanushevsky,
Andreas Hoecker,
Christian Holm Christensen,
Ivana Hrivnacova,
Jan Iwaszkiewicz,
Anna Kreshuk,
Daniele Kruse,
Wim Lavrijsen,
Sergei Linev,
Jose Lo,
Constantin Loizides,
Pere Mato,
Lorenzo Moneta,
Miroslav Morhac,
Andreas Morsch,
Axel Naumann,
Eddy Offermann,
Valeriy Onuchin,
Andreas Peters,
Timur Pocheptsov,
Witold Pokorski,
Xavier Prudent,
Fons Rademakers,
Stefan Roiser,
Paul Russo,
Abdelhalim Ssadik,
Joerg Stelzer,
Matevz Tadel,
Tim Tran,
Wouter Verkerke,
Helge Voss,
Kai Voss.

Improvements in the build system

Precompiled Headers

Precompiled headers are used on Windows with MS Visual C++ (any version), and GCC4, to decrease the compilation time. Currently, everything #included by TH1.h (and TH1.h itself) is precompiled.

Tools Changes

Many scripts (, window's, etc) are replaced by direct invocations, speeding up the build. bindexplib now supports symbol names of arbitrary length.

Windows Debug

By default, ROOT now uses the debug runtime libraries when building a debug version on Windows. This can be changed with the "--disable-winrtdebug" configure switch.

New Supported Compilers


Macros Assert, Check and ForEach

To avoid possible clashes with user defined header files, we have replaced the internal use of macros Assert, Check and ForEach by R__ASSERT, R__CHECK and R__FOR_EACH respectively. The old definitions are still kept until the production release later this year.

WARNING!!. We urge users of these macros to replace them by the new version asap.


One can now silence ROOT by setting "Root.System.BeepDuration: 0" in .rootrc, making it fully usable within meetings; see TSystem::Beep() for details. Windows now uses the sound card, not the system speaker.

Stack Trace

Implemented stack trace for Windows, covering all threads, which is triggered by unhandled exceptions or "fatal" signals.

MSI installer added for Windows (make distmsi); needs WiX binaries, version 3.0.1719.0 from 2006-01-19.

CINT Improvements

CINT parser

Cint / TCint Performance

Improve performance of TCint::UpdateListOfGlobalFunctions, which is called e.g. by TROOT::GetListOfGlobalFunctions(). Improve speed of Cint's G__defined_tagname a bit.

Other improvements

Several parsing improvements, in particular this includes support for distinguish (from the string based interface) a template of Double32_t from a template of double.

Note that the compiler still can not distinguish the 2 forms and thus only 'string' based interface will be able to handle this distinction.

The Qtcint interface

CINT has a new build option to generate the dictionary for the Qt classes. This dictionary is not built by default in the binary distribution files because the resulting library is quite large (>2 Mbytes). You can build it from source via
make qtcint

Performance improvements when reading/writing remote files

A set of new classes TFileCacheWrite, TFileCacheRead and TTreeCache have been added to the system. These classes support read and write caches that may reduce considerably the number of transactions on a network and therefore drastically improve the performance in case of a network with high latency. Thanks to TTreeCache it becomes possible to read a remote file containing a large Tree. We have modified the rootd daemon as well as the httpd server to extend the protocol to support this cache. The xrootd server is currently being modified to also take advantage of this new feature. When reading a Tree, the read cache is automatically activated. The cache has a learning phase to discover automatically the branches of the Tree really used, then it can prefetch all the branch buffers in one single transaction (up to the maximum buffer size). You can disable it by calling
The table below shows the performance gain when executing a query reading a total of 6.9 Mbytes on a 280 Mbytes file at CERN accessed from various client machines with different network bandwidth and latency. The ROOT remote server is either rootd (access via TNetFile) or a web server (TWebFile). No noticeable performance differences have been observed between the two servers.
     client     cachesize=0   cachesize=64KB   cachesize=10MB
      A             3.4             3.4               3.4
      B            22.0             6.0               4.0
      C            11.6             5.6               4.9
      D           124.7            12.3               9.0
      E           230.9            11.7               8.4
      F           743.7            48.3              28.0
It is interesting to notice that in all these tests, the network bandwidth was not the limiting factor, but the latency was/is.

When reading TKey objects, the cache is not activated by default. If you have an application looping on many TKeys,you can get a substantial performance improvement by informing the system about the keys to be buffered in one single transaction. An example of code is shown below.

   TFileCacheRead *cache=0;

   void PreFetchKeys(TDirectory *dir) {
      TIter next(dir->GetListOfKeys());
      TKey *key;
      while ((key = (TKey*)next())) {
   TFile *f = TFile::Open("root://");
   //cache = new TFileCacheRead(f,10000000);  //uncomment this line to enable the cache
   if (cache) PreFetchKeys(f);
   TIter next(f->GetListOfKeys());
   TKey *key;
   while ((key = (TKey*)next())) {
      //TObject *obj = key->ReadObj();
      //process object
We are still working on further improvements to reduce the latency problem (parallel transfers and read-ahead with multi-threading on the servers). The interesting message is that the http protocol is becoming interesting to read remote files like calibrations, monitoring, mag-fields, etc. It is probably more economical to read central files via the http protocol
 TFile *f = TFile::Open("");
than making multiple copies of these files on the analysis/production sites. To use the http protocol with ROOT, you need a plugin for the Apache (or Apache-like web servers). For more info, see:

TTree and I/O

Asynchronous open functionality in TFile

A framework to support asynchronous file open functionality has been implemented. An async open request is submitted using the new static methods TFile::AsyncOpen. This method takes the same arguments as the known TFile::Open, but it never blocks returning an opaque handle, an instance of the new class TFileOpenHandle. The handle contains all the relevant information about the request and can be used to check the status of the request and to retrieve the pointer to the file instance once the file is ready to be used. To make handling of the 'opaque file handles' more user-friendly, a static list of pending open requests is kept internally and methods to identify them by filename are provided.
Example of usage:
       TString fname = "root://dserv.dom.ain//data001/myfile.root";
TFile *f = 0;
// Submit the request (does not block)
// Do something else while waiting for open readiness
EAsyncOpenStatus aos = 0;
while ((aos = TFile::GetAsyncOpenStatus(fname)) == TFile::kAOSInProgress) {
// Do something else
// Attach to the file if ready ... or open it if the asynchronous
// open functionality is not supported
if (aos == TFile::kAOSSuccess || aos == TFile::kAOSNotAsync) {
// Attach to the file
f = TFile::Open(fname);
// Analyse it ...
} else {
// Failure
Currently only TXNetFile (remote file access via XROOTD) is supporting asynchronous file opening. A call to TFile::AsyncOpen for TFile implementations not supporting asynchronous open functionality fills the handle with the parameters needed by a normal TFile::Open, so that the above example works in all cases. The real URL of the file - e.g. the URL where the XROOTD redirector redirects the client - is available after TFile::AsyncOpen via the new method
          const TUrl *TFile::GetEndpointUrl(const char *filepath)

I/O for template instance using Double32_t

The ROOT I/O nows supports the ability to store as float the data member of a template class instance which depends on the template parameter and this parameter is 'Double32_t' (previously they were stored as double). Note that currently (and until the C++ compiler implement the notion of 'opaque typedef') the compiler can not distinguish between a mytemp and a mytemp and thus only the string based interface will properly store the datamember as float.
A consequence of this limitation is that the dictionary for mytemp< double>and mytemp<Double32_t> must be generated in two different dictionary files.

Fast cloning and merging of TTrees

Resolved an issue that prevented the cloning/merging of TTrees using the fast method when the basket were not all ordered (This can happens for a file with many AutoSave).

Schema Evolution

TStreamerInfo::BuildCheck error messages

The checksum calculation used to check the integrety of a class definition was not using a consistent class name for the STL containers. This lead to the appeareance of error messages like:
   Warning in :
                The StreamerInfo of class FitResult read from file t1.root
                has the same version (=1) as the active class but a
                different checksum.
                You should update the version to ClassDef(FitResult,2).
                Do not try to write objects with the current class definition,
                the files will not be readable.
When the 'only' difference was wether or not the dictionary for the stl container was loaded.
The fix for this problem might lead to similar messages in other cases (where the full typename was used for object already on file). The solution in thoses cases is to increase the version number of the class (This solution is __not__ an option for the above mentioned cases (where the difference is the presence or not of a dictionary for the stl container)

Changes in $ROOTSYS/bin/hadd

.New options have been added to this program. hadd adds histograms and trees from a list of root files and write them to a target root file. The target file is newly created and must not be identical to one of the source files.

       hadd targetfile source1 source2 ...
       hadd -f targetfile source1 source2 ...
         (targetfile is overwritten if it exists)
When -the -f option is specified, one can also specify the compression level of the target file. By default the compression level is 1, but For example assume 3 files f1, f2, f3 containing histograms hn and Trees Tn the result of
     hadd -f x.root f1.root f2.root f3.root
will be a file x.root with with h1 h2 h3 h4 h5 T1 T2, where h1 will be the sum of the 2 histograms in f1 and f2, T1 will be the merge of the Trees in f1 and f2 The files may contain sub-directories. If the source files contains histograms and Trees, one can skip the Trees with
       hadd -T targetfile source1 source2 ...
If the sources and and target compression levels are identical (default), the program uses the TChain::Merge function with option "fast", ie the merge will be done without unzipping or unstreaming the baskets (i.e. direct copy of the raw byte on disk). The "fast" mode is typically 5 times faster than the mode unzipping and unstreaming the baskets.
Note that in versions 5.08 and 5.10, the merged files with hadd could show some problem in case of large files when the tree header had been saved multiple times. This was due to a bug in TChain::Merge now fixed in this release.

WARNING: Backward incompatible change in the SavePrimitive functions

If you implement a function in your class, be aware of the new API (change ofstream to ostream).

Generic Mechanism for Object References

References are a well known mechanism to support persistency of entities, which in C++ typically are represented as pointers. The generic mechanism allows clients to supply hooks to the ROOT framework in interactive mode in order to dereference these objects and access the objects pointed to by the reference objects. Implementations are supplied for ROOT owns reference mechanism based on instances of the TRef and the TRefArray class. To support generality this mechanism was implemented using a proxy mechanism, which shields the concrete implementation of the reference classes from ROOT. Hence, this mechanism also works for references as they are supported by the POOL persistent framework and by frameworks like Gaudi.


Given the well known test Event example (from $ROOTSYS/test) it is directly possible to scan or draw a tree with object references:
 root [0] gSystem->Load("libEvent.dll");
 root [1] TFile::Open("Event.root")
 root [2] T->Scan("fLastTrack.GetPx():fLastTrack.fPx");
    *    Row   * fLastTrac * fLastTrac *
    *        0 * -0.599649 * -0.599649 *
    *        1 * 0.0955979 * 0.0955979 *
The values shown are equivalent to the result of: ((Track*)event->fLastTrack->GetObject())->fPx (or ...GetPx()) Of course this is also equivalent to:
 root [3]   T->Scan("fTracks[fTracks@.size()-1].GetPx():fTracks[fTracks@.size()-1].fPx")
    *    Row   * fTracks[f * fTracks[f *
    *        0 * -0.599649 * -0.599649 *
    *        1 * 0.0955979 * 0.0955979 *
For reference arrays (a type of reference collection) either a specific element of the collections may be specified like:
 root [4] T->Scan("fTracks[0].GetPx():fTracks[0].fPx");
    *    Row   * fTracks[0 * fTracks[0 *
    *        0 * 0.5103191 * 0.5103191 *
    *        1 * 1.9513020 * 1.9513020 *
or the entire collection may be scanned. In this case all elements of the collection contribute to the selection (aka foreach(...):
 root [5] T->Scan("fTracks.GetPx():fTracks.fPx");
    *    Row   * Instance * fTracks.G * fTracks.f *
    *        0 *        0 * 0.5103191 * 0.5103191 *
    *        0 *        1 * 0.8531729 * 0.8531729 *
    *        0 *      599 * -0.599649 * -0.599649 *
    *        1 *        0 * 1.9513020 * 1.9513020 *
Clearly visible is the beginning of the next "event" after having scanned 600 tracks. The dereferrence mechanism even works across distributed files:
 root[6] T->Scan("fWebHistogram->GetRMS()")
will access a remote file, which is accessed using the http protocol. operator "@": The operator @ applied to a reference object allows to access internals of the reference object itself:
 root[6] T->Scan("fLastTrack.GetUniqueID():fLastTrack.GetUniqueID()&0xFFFF:fLastTrack@.GetUniqueID()");
fLastTrack.GetUniqueID() shows the datamember fUniqueID of the Track object
fLastTrack@.GetUniqueID() shows the datamember fUniqueID of the TRef pointing to the Track.
and as crosscheck: fLastTrack.GetUniqueID()&0xFFFF == fLastTrack@.GetUniqueID() There is a small caveat concerning TRefArrays and TRefs: ROOT must know the object type in order to interprete the formula passed. Hence "empty" reference objects in the first few rows cause trouble ie. the formula cannot be executed resulting in errors like:
root [6]   T->Scan("fMuons[0].GetPx():fMuons[0].fPx");
    Error in : index 0 out of bounds (size: 0, this: 0x0636a6e0)
    Error in : index 0 out of bounds (size: 0, this: 0x0636a6e0)

Technical details

To enable reference support a concrete sub-classed instance of the TVirtualRefProxy base class must be attached to the TClass instance representing the reference itself. Please see the header- and implementation file TRefProxy.h/cxx for details. For ROOT's own references this is done simply by a call like:
#include "TROOT.h"
#include "TClass.h"
#include "TRefProxy.h"

   gROOT->GetClass("TRef")->AdoptReferenceProxy(new TRefProxy());
The actual work is done inside a call to:
void* TRefProxy::GetObject(TFormLeafInfoReference* info, void* data, int)  
   if ( data )  {
      TRef*      ref    = (TRef*)((char*)data + info->GetOffset());
      // Dereference TRef and return pointer to object
      void* obj = ref->GetObject();
      if ( obj )  {         return obj;      }

   ... else handle error or implement failover ....
Note: For ROOT's TRef references it is mandatory to to enable the reference table object. Hence after creating the tree call:


See the new tutorial $ROOTSYS/tutorials/references.C for a complete example.


The new version of XROOTD includes the first port of the client on Windows VC++, completing the set of platforms where TXNetFile is available. In addition, on the client side, there have been several improvements and bug fixes, in particular in the asynchronous functionalities. The modifications to support the new caching techniques described above have also been integrated.
On the server side, the most relevant additions are:
  • support for background (daemon) mode;
  • support for multi-port;
  • support for super-user running.
  • support for vector buffer reading (need by the new caching techniques)
These improvements allow to use a standard startup script for xrootd, to use the same daemon to run concurrently data servers and PROOF servers on the standard ROOT ports (1094 and 1093), and to run the servers under 'root' privileges, required in certain cases.


The major additions are: the Windows porting of the XProof client; the file upload facility and the a bulk of new admin functionality for the XrdProofd server plug-in. More details about the usage of the new functionality are given below. In addition there have been several bug fixes - in particular, one potentially causing a huge memory leak on worker nodes - and improvements in the treatment of interrupt and error conditions. A new static method TProof::Reset(const char *url) has been added to reset client's sessions of the cluster: in particular this allows to cleanup all zombie proofserv instances without server-side intervention. Also, it is now possible to temporarly deactivate a worker with TProof::DeactivateWorker(const char *ord) and re-activate it with TProof::ActivateWorker(const char *ord) .

File upload facility

A facility to upload files to a PROOF cluster is improved. Support for public datasets is provided. Public datasets are datasets that are accessible to other users. They are saved in "public" subdirectory of "datasets" directory in owner's sandbox. Only the owner can modify a dataset.
User can only upload files to the directory dedicated for her/him or it's subdirectory. Thus, destination directory in upload functions (UploadDataSet and UploadDataSetFromFile) is now relative to <datapool>/<username> and does not have to be specified. As a consequence of this default value, the arguments order is changed in upload functions! Destination directory is third after dataset name and list of files!
Two new methods are added:
  •  Int_t TProof::UploadDataSet(const char *dataset, TList *files, 
    const char *dest,

    Int_t opt, TList *skippedFiles);

    It's the main method used by other upload methods.
    Uploads a set of files described by 'files' (TList of TFileInfo objects) and saves the list of TFileInfo objects describing new file locations by name 'dataset'; The string 'dataset' is of form [public/]dataSetName. The information is saved in the sandbox on the master as a list of TFileInfo objects. 'dest' is a path relative to <datapool>/<username>.
    The mask 'opt' is a combination of EUploadOpt:
             kAppend             (0x1)   if set true files will be appended to
    the dataset existing by given name
    kOverwriteDataSet (0x2) if dataset with given name exited it
    would be overwritten
    kNoOverwriteDataSet (0x4) do not overwrite if the dataset exists
    kOverwriteAllFiles (0x8) overwrite all files that may exist
    kOverwriteNoFiles (0x10) overwrite none
    kAskUser (0x0) ask user before overwriting dataset/files
    The default value is kAskUser. The user will be asked to confirm overwriting dataset or files unless specified 'opt' provides the answer! If kOverwriteNoFiles is set, then a pointer to TList must be passed as 'skippedFiles' argument. This list will be filled with TFileInfo objects describing all files that existed on the cluster and were not uploaded.
    The method returns the number of files uploaded if successful; otherwise it returns -1;
  •  Int_t TProof::CreateDataSet(const char *dataset, TList *files, Int_t opt = kAskUser);

    This method simply saves the list of TFileInfos - 'files' as a 'dataset' on the cluster, assuming that the files are already on the cluster.
    On success, the method returns the number of files described in 'files'; otherwise it returns -1;
Methods designed for listing datasets have 'dir' argument added to allow them access of public datasets.
With 'dir' undefined - just ls contents of ~/proof/datasets.
With 'dir' == "public" - ls ~/proof/datasets/public.
With 'dir' == "~username/public" - ls ~username/datasets/public.
  • TList *TProof::GetDataSets(const char *dir = NULL)
    Get TList of TObjStrings with the names of all datasets available on the master (list contents of SandBox/datasets)
  • void TProof::ShowDataSets(const char *dir = NULL)
    Show all datasets available in the specified directory on the master.
Methods for accessing and verifying the datasets now accept 'dataSet' argument of form: "[[~user/]public/]dataSetName".
The TProof::RemoveDataSet(const char *dataset) method accepts 'dataset' of form "[public/]dataSetName"

Improvements in the XrdProofdProtocol plug-in

Several additions have been made to the XrdProofdProtocol plugin mainly to facilitate the administration of a cluster. The cluster administration may have now full control on the PROOF session composition, the number and priority of sessions, as described below. The be active, the following directives must be present in the configuration file used at xrootd startup. Except when explicitly indicated, all the following directives support an optional 'if pattern' condition at the end of the line, e.g.
       xpd.rootsys /opt/root   if lxb*
xpd.rootsys /usr/local if lxp*
Patterns may contain any number of wild cards; the best match is retained (max number of matching chars; if two are equal, the last specified wins).
  • Load the XrdProofd protocol:
    i. if the ROOT lib paths are known by the linker/loader
        xrd.protocol xproofd:1093
    ii. using absolute paths (ROOT_sys with the path to the ROOT distribution)
        xrd.protocol xproofd:1093 ROOT_sys/lib/ rootsys:ROOT_sys
  • ROOTSYS path (alternative to rootsys: above)
        xpd.rootsys /opt/root 
  • Image name of this server [node name]
        xpd.image image
  • Working directory for sessions (aka sandbox) [User_Home/proof]
        xpd.workdir work_dir
  • Resource finder. This directive allows to control the way the information about the worker list is obtained.
    The only available implementation is "static", i.e. using a config file;
        xpd.resource static [cfg_file] [ucfg:user_cfg_opt] [wmx:max_workers] [selopt:selection_mode]
    Options are
    • cfg_file: path alternative config file [$ROOTSYS/proof/etc/proof.conf]
    • user_cfg_opt: if "yes": enable user private config files at $HOME/.proof.conf or $HOME/.usr_def, where usr_cfg is the second argument to TProof::Open("master","usr_cfg") ["no"]
    • max_workers: Maximum number of workers to be assigned to user session [-1, i.e. all]
    • selection_mode :
      If max_workers != -1, specify the way workers are chosen:
        "roundrobin"  round-robin selection in bunches of n(=max_workers) workers.
      Example: N = 10 (available workers), n = 4:
      1st (session): 1-4, 2nd: 5-8, 3rd: 9,10,1,2, 4th: 3-6, ...
      "random" random choice (a worker is not assigned twice)
    If this directive is missing, the standard behavior with a (possibly user-defined) config file is obtained.
    (NB: 'if pattern' not supported for this directive).
  • Master(s) allowed to connect. Directive active only for Worker or Submaster session requests.
    Multiple 'allow' directives can be specified. By default all connections are allowed.
  • Server role (master, submaster, worker, any) [any]. Allows to control the cluster structure.
    The following example will set lxb6041 as master, and all the others lxb* as workers
         xpd.role worker if lxb*
         xpd.role master if
  • Action when no clients are connected any longer. By default the session is shutdown if idle or prepared to shutdown as soon as idle. It is possible to delay the action by a given amount of time counted from the moment at which the session becomes idle. It is also possible to act when the disconnection takes place, no matter the running state. Finally it is also possible to leave the session running. The following example shutdowns a session when all clients are gone after 20 minutes of being idle:
         xpd.shutdown 1 20m
 The file $ROOTSYS/etc/daemons/ describes all the avilable options.

SQL interface(s): Many improvements by Sergei Linev

Improvements of TSQLServer class

  • Error handling is introduced. Now TSQLServer returns error code - GetErrorCode() and message - GetErrorMsg() of last operation. If desired, error output can be suppressed. Correspondent changes done for Oracle, MySQL, ODBC.
  • New methods for transactions control: StartTransaction() / Commit() / Rollback(). As default implementation sql queries "START TRANSACTION", "COMMIT" & "ROLLBACK" are used. For Oracle, MySQL and ODBC specific code was implemented.
  • New method IsSupportStatement() - return kTRUE if plugin has TSQLStatement implementation
  • New method GetMaxIdentifierLength() - return maximum allowed length of identifiers

New abstract class TSQLStatement

SQL statements are a feature which allows queries to be submitted in bulk to the DB server and thereby gaining up to several orders of magnitude in performance. The TSQLStatement is currenctly implemented for Oracle and MySQL (version >= 4.1.x). SQL statements are an alternative to TSQLServer::Query() method, which allows only pure text queries and pure text result in TSQLResult classes. TSQLStatement is designed to support following features:
  • usage of basic data type (like int or double) as parameters in SQL statements
  • bulk operation when inserting/updating/selecting data in data base
  • usage of basic data types when accessing result set of executed query

Much more detail can be found in the description of the TSQLStatement class.

ODBC interface: New package

New ODBC driver that allows generic access to many DB's. This version should also compile on Windows for access to MS DB's (Access, SQLServer). For this driver to compile one needs either to install unixODBC ( or iODBC ( On Mac OS X it also works with the system installed iODBC libraries.

To open a connection to a ODBC server. The db arguments can be:

  • Form "odbc://[user[:passwd]@][:][/][?Driver]", e.g.: "odbc://". Driver argument specifies ODBC driver, which should be used for connection. By default, MyODBC driver name is used. The uid is the username and pw the password that should be used for the connection. If uid and pw are not specified (==0), user and passwd arguments from URL will be used. Works only with MySQL ODBC, probably with PostrSQL ODBC.
  • Form "odbcd://DRIVER={MyODBC};;DATABASE=test;USER=user;PASSWORD=pass;OPTION=3;PORT=3306;" This is a form, which is accepted by SQLDriverConnect function of ODBC. Here some other arguments can be specified, which are not included in standard URL format.
  • Form "odbcn://MySpecialConfig", where MySpecialConfig is entry, defined in user DSN (user data source). Here uid and pw should be always specified.

Much more detail in the setup and usage of ODBC can be found in the description of the TODBCServer class.

MonaLisa Monitoring Interface

The TMonaLisaReader object is used to read monitoring information from a MonaLisa server using the ML web service client package ( / SOAP client). The MonaLisa web service client library for C++ can be downloaded from the MonaLisa web site. The current version is ml-gsoapclient-1.0.0.tar.gz.

The TMonaLisaWriter object is used to send monitoring information to a MonaLisa server using the ML ApMon package ( packets). The MonaLisa ApMon library for C++ can be downloaded from the MonaLisa web site. The current version is ApMon_c-2.2.0.tar.gz.

The ROOT implementation is primary optimized for process/job monitoring, although all other generic MonaLisa ApMon functionality can be exploited through the ApMon class directly via dynamic_cast(gMonitoringWriter)->GetApMon().

Both the MonaLisa reader and writer classes derive from the abstract monitoring classes TVirtualMonitoringReader and TVirtualMonitoringWriter. Once the TMonaLisaXXXX objects are created they can be accessed via the global symbols gMonitoringReader and gMonitoringWriter.

Fitting enhancements and bug fixes

  • A bug was fixed in TH1::Fit when the function was called with the option "L". The value computed for the equivalent chisquare was not taking correctly into account the histogram errors.

FFTW: Fast Fourier Tranform: New package

This package contains an interface to the FFTW library of Fast Fourier Transforms ( It consists of the following classes:
  • TFFTComplex - for complex input/output Discrete Fourier Tranforms in one or more dimensions
  • TFFTRealComplex - for real input/complex output Discrete Fourier Transforms in one or more dimensions
  • TFFTComplexReal - inverse to the above transform (complex input/real output)
  • TFFTReal
    • Real input/complex output transforms and their inverses with the complex part in halfcomplex format
    • Discrete Hartley Transforms
    • Sine and cosine transforms of types I-IV
Only basic interface of FFTW is implemented (no "advanced" or "guru" features). How to install this package:
  • Install the FFTW library, version 3.0.1 and higher
  • Configure ROOT
        --with-fftw3-incdir = "the directory where fftw3.h is"
        --with-fftw3-libdir = "the directory where the fftw library is"
        --with-fftw3-incdir=$HOME/fftw-3.1.1/api \

New class TVirtualFFT

This class provides an abstract interface to FFT transforms. The default library is FFTW3. See class description and tutorial FFT.C for details on how to use it.

Changes in TH1 related to FFTW

Two functions added to class TH1:
 *  virtual TH1 *FFT(TH1* h_output, Option_t *option);
 *  static TH1 *TransformHisto(TVirtualFFT *fft, TH1* h_output, Option_t
The first function allows to do a discrete Fourier transform of a histogram, the second function returns a histogram of the output (different options available) for an existing transform.


The Toolkit for Multivariate Analysis (TMVA) provides an environment for the parallel processing and evaluation of MVA techniques to discriminate signal from background samples. It presently includes (ranked by complexity):

  • Rectangular cut optimisation
  • Correlated likelihood estimator (PDE approach)
  • Multi-dimensional likelihood estimator (PDE - range-search approach)
  • Fisher (and Mahalanobis) discriminant
  • H-Matrix (chi-squared) estimator
  • Artificial Neural Network (two different implementations)
  • Boosted Decision Trees

The TMVA package includes an implementation for each of these discrimination techniques, their training and testing (performance evaluation). In addition all these methods can be tested in parallel, and hence their performance on a particular data set may easily be compared. For the comparison of the efficiency and background rejection of all the different methods, the analysis job gives some tabulated efficiency / background values in the log file, as well as the efficiency vs. background rejection curves along with detailed other evaluation information (like ranking, correlation matrixes and alike) in a ROOT file. These results can then be easily displayed using the ROOT macros provided with TMVA.

Performance comparison between the different multivariate analyser methods that are implemented in TMVA. The MVAs were trained on an academic toy-data sample consisting of four linearly correlated Gaussian-distributed variables.


Each method that is trained writes the training results to individual "weight" files, which can be in either text or ROOT format. A class TMVA::Reader serves to use the MVAs in a specific analysis context. Within an event loop, a vector is filled that corresponds to the variables that were used to train the MVA(s) during the training stage. This vector is transfered to the Reader, who takes care of interpreting the weight file of the MVA of choice, and to return the MVA's output. This is then used by the user for further analysis.


Special emphasis has been put on the comparative performance assessment of the various MVA methods. The training, testing and evaluation phases are performed in parallel for the various methods (through a factory). The evaluation accomodates several numerical performance estimators as well as various ROOT plots. ROOT scripts to conveniently access these plots are provided.

A more detailed description of the methods can be found at this location.

Improvements in the Random Numbers

Several improvements have been done in this release for the ROOT random numbers, in particular the generators in TRandom and TRandom2 have been replaced and a new class TRandom1, based on the Ranlux random generator has been introduced. The changes in detail are:


A new linear congruential random generator has been introduced to implement this random number. This generator is based on the BSD random number and is known to have BAD random quality, in particular its period is too short (10**9) and can be exhausted in just few seconds. It is introduced only for backward compatibility since it's having a state of only one 32 bit integer. It must NOT be used for any statistical study.


New random number generator based on the Ranlux engine, and is based on the Fortran implementation of F. James. This engine has mathematically proven random proprieties and a long period of about 10**171. Various luxury level are provided (1,2,3,4). The level 3 is the default where any theoretical possible correlation has very small chance of being detected. The generator uses a state of 24 words. Its main disadvantage is that is much slower than the others (see timing table)


This generator is base now on the maximally equidistributed combined Tausworthe generator by L'Ecuyer. It uses only 3 words for the state and it has a period of about 10**26. It is fast and given its small states, it is recommended in application which require a very small random number size.


This is the default ROOT generator and the recommended one (it is the one used in gRandom). It is based on the Mersenne and Twister engine, it is very fast and has a very long period of 10**6000. The disadvantage is that it uses a rather large state of 624 words.

The following figure shows an estimate of PI obtained generating a pair of random numbers. One sees that when generating an order of 10**10 random numbers, the period for TRandom is exhausted. The figures also show the time (in ns) for generating a random number

Seeding the Generators

A consistent way of seeding the generators has been put in place for this release. The seeds can be set in the TRandom classes constructor or by using the SetSeed method. When no value is given the generator default seed is used, for example 4357 for TRandom3. In this case identical sequence will be generated every time the application is run. When the 0 value is used as seed, then a unique seed is generated using a TUUID, for TRandom1, TRandom2 and TRandom3. For TRandom(0), the seed is generated using only the machine clock, which has a resolution of about 1 sec. Therefore identical sequences will be generated if the elapsed time is less than a second.

// use default seed (same random numbers will be generated each time)
TRandom3 r; // generate a number in interval ]0,1] (0 is excluded)
double x[100];
r.RndmArray(100,x) // generate an array of random numbers in ]0,1]
TRandom3 rdm(111) // construct with a user-defined seed
// use zero as seed: a unique seed (different every time) will be automatically generated using TUUID
TRandom1 r1(0);
TRandom2 r2(0);
TRandom3 r3(0);
// use a seed generated using machine clock (different every second)
TRandom r0(0); 

Improvements Random Distributions

TRandom::Poisson has been corrected to provide correct Poisson random numbers also for large mu. A rejection algorithm, using a Lorentzian distribution is used. The new algorithm is faster than the previous one for mu between 25 and 88 and it is correct also for mu larger than 88, while before the Gaussian approximation was used.

TRandom::Landau and TRandom::Sphere: some improvement in the performances. have been applied.

The following values are obtained now for the various distributions and engines, running the tutorial testrandom.C on a 2.Ghx Intel Core Duo running MacOSX and compiled with gcc 4.0:

Distribution            microseconds/call
                    TRandom  TRandom1 TRandom2 TRandom3
Rndm..............    0.030    0.130    0.030    0.040
RndmArray.........    0.010    0.130    0.020    0.020
Gaus..............    0.250    0.460    0.250    0.270
Landau............    0.070    0.170    0.070    0.080
Binomial(5,0.5)...    0.160    0.700    0.180    0.200
Binomial(15,0.5)..    0.430    2.060    0.490    0.590
Poisson(3)........    0.220    0.650    0.240    0.260
Poisson(10).......    0.460    1.610    0.490    0.570
Poisson(70).......    1.260    1.670    1.290    1.310
Poisson(100)......    1.280    1.680    1.300    1.320
GausTF1...........    0.210    0.330    0.210    0.220
LandauTF1.........    0.210    0.330    0.210    0.220



The major changes are the addition of an extra template parameters for the DisplacementVector3D and PositionVector3D classes. The new parameter is the Coordinate System Tag and can be used to specify different vector types according to the type of coordinate systems. For example one type of vectors for a global coordinate system and a different type for a local coordinate system. The classes have a default tag, which gives backward compatibility, and is used when one does not need the functionality to specify a coordinate system tag.

The rotation and transformation classes have been modified accordingly to provide, and in the case of the Transform3D class, the possibility to transform from one vector in one coordinate tag to a new coordinate tag.

In addition, this release contains a bug fix in the inversion of EulerAngles class

Some additional methods like energy() and mass() have been added to the LorentzVector class to satisfy a request from CMS. Typedef's to cartesian Vector and Point have been added in the Plane3D and the Transform3D classes on requests from LHCb. This allow a generic use of the use of the Plane3D and Transform3D classes.

Dictionary is now generated also for some 3D Vector types (based on Cartesian and Cylindrical-Eta coordinates) and for LorentzVector using the Double32_t type, for I/O.

A mechanism has been put in place to generate easily the dictionary for other types of template instantiations not present in the provided library. An example on how to generate this required dictionary is provided in the tutorial mathcoreVectorFloatIO.C (in $ROOTSYS/tutorials).

More detailed description of the current release can be found at this location.


Addition of a C++ wrapper to the GSL random number engines and to the distributions. A template class, ROOT::Math::Random has been added with an API similar to the ROOT class TRandom. The class is template on the Random Engine type. Here is an example on how to use this new Random class:

using namespace ROOT::Math;

Random<GSLRngMT>         r1;      // random based on GSL Mersenne and Twister engine (mt19937)
Random<GSLRngCMRG>       r2;      // random based on GSL CMRG engine (gsl_rng_cmrg)
double x =     r1.Uniform();      // generate uniform random numbers
int n    =     r1.Poisson(mu);    //  generate Poisson random numbers with average mu  
The main GSL random number generators are available as C++ type to use for the Random template parameters. In addition the most commonly used random distributions are implemented as methods in the Random classes. Detailed information is available in the reference documentation. A further addition in mathmore is the quartic analytic solver. The routine which is part of the GSL CVS, but not yet released is included now in mathmore. It can be use it from the C++ Polynomial class, as shown in the following example:
// create the polynomial x**4 -50 x**3 + 35 x **2 - 10 *x + 1
ROOT::Math::Polynomial  p(1,-10,35,-50,24)         
// find the Real Roots of p 
std::vector r = p.FindRealRoots(); 
// p will have contains all the 4 real roots (1,2,3,4) 

From this release mathmore does not contain anymore a built-in version of GSL. MathMore requires GSL installed somewhere externally. The GSL install location is detected at compile time either using the gsl-config script (provided by GSL) or specifying the include and library GSL location with

./configure --with-gsl-incdir=........... --with-gsl-libdir=...........

GSL can be easly built and installed on Unix machines using ./configure and make after having downloaded the tar file of GSL. A tar file for the latest version, 1.8, is available here. Binaries for GSL exists at CERN for various platforms (including Windows) in the /afs area (/afs/ ) and see also here). Binary of GSL for Windows, version 1.8, compiled with Visual Studio 7.1 can be downloaded from this location.

Reference documentation of mathmore for the current release can be found at this location.


Removed some warning messages and improved the error reporting in the TFitterMinuit class. Fixed a bug in the fitter when fitting in an defined range specified by the function. A small change in Fumili to break the iterations when they do not improve sufficiently the convergence towards the minimum point.

More information on Minuit2, the new C++ version of MINUIT, can be found on the MINUIT Web Site and reference documentation at this location.



The main changes with respect to the previous versions (5.10) are the followings:

  • Change the storage of the offset for the indexes for the symmetric matrices. Use a static struct containing the offsets, which is created the first time a symmetric matrix is constructed. The offsets are calculated at that time. The specialized structures containing the offsets for matrices up to size 10 are removed since there are not needed anymore. A pointer to the offset structure is kept in the symmetric matrix.
  • The matrix expressions have been modified to use also indexes i and j. This speed up the operations like matrix multiplication and transpose.
  • Use references in the BinaryOp and UnaryOp classes and add different classes when dealing with constants in binary operations, since in that case the constant object needs to be kept by value. Doing this, better performances are obtained in binary operations since no copy of the matrix or expression objects is needed now and the problem observed previously on Windows when using references in BinaryOp with constants is fixed.
  • Add a function AssignSym::Evaluate to be able to force the assignment from general to symmetric matrices. This is used in the Similarity function with symmetric matrices.
  • Add a copy constructor from a symmetric matrix to a standard matrix.
  • Correctly take into account the case of symmetric matrices, when inserting (or retriving) a sub-matrix in (from) a matrix.
  • Change syntax in constructing a matrix from iterators. There is a fix for symmetric matrices from iterator and add the possibility now to create a matrix from the upper/lower triagonal data block.
  • Add a SMatrix::SetDiagonal to set the values of a diagonal matrix from a vector
  • Improvements in the inversion for normal square and symmetric matrices with size larger than 6x6. The same inversion algorithms of CLHEP Matrix are used: LU factorization for squared one (from the CERNLIB dinv) and Bunch-Kaufman factorization for the symmetric matrix. The improvements in speed, as shown in the stressOperations, are more than a factor of 2 for large size ( >= 7) matrices.
  • A new function, ROOT::Math::TensorProd, has been added for computing the tensor product of two vector
  • add SVector::SetElements(begin,end) and SMatrix::SetElements(begin,end) to set all vector/matrix elements using a generic iterator.
  • Add operator *= and /= for the multiplication and divison of all the matrix elements with a scalar. Add also the operator *= for matrix-matrix multiplication
  • Fix a problem with the operators += and -=. Now works correctly for matrix-scalar and matrix-matrix operations.
  • Remove implicit conversion from SVector to a scalar value. Add instead explicit conversion from SVector and SMatrix of dimension 1 to a scalar.
  • Rename the global / operator for matrices ( element-wise operation: c(i,j) = a(i,j)/b(i,j) ) to the function ROOT::Math::Div.
  • Add operator()(unsigned int i) to the Vector expression object (class ROOT::Math::VectExpr)
  • Generate the dictionary for the double, float and Double32_t vector, symmetric and square matrices up to dimension 7 (the test program smatrix/test/testIO.cxx provides an example of storing matrix classes based both on double and Double32_t.

Reference documentation of the SMatrix package can be found at this location.

TMatrix improvements

In this release additional functionality has been added :
  • Like for symmetric matrices (TMatrixTSym), we have added the similarity operation between vector and matrix in TMatrixT : v * M * v^T
  • A global switch has been added : Int_t gMatrixCheck . When set to 1 (default) checking of matrix/vector shapes and validity is performed before each operation . When its value is 0, these checks are not done which results in some speed gain . Note that switching off these checks can lead to catastrophic events like reading/writing out-of-bounds . The user should always run the code once with gMatrixCheck=1 .
Some new operations have been added to improve speed by not creating temporary objects :

TMatrix or Smatrix: Which one to use?

The Smatrix package is designed for small matrices (less than 7x7) and when the sizes of the matrices are known at compile time. It avoids creation of temporary objects in arithmetic operations and it is faster than TMatrix in this case. For large matrices TMatrix is recommended since it is faster and the compilation time Smatrix increases rapidly. We provide a small test program comparing the respective performance of the two packages (see stressOperations and stressKalman in the source directory $ROOTSYS/smatrix/test). If you compile and run these tests programs, you will experience a very long compilation time due to the fact that the Smatrix package is fully contained in header files. The size of the compiled code may become extremely large if this class is used in many user classes. We would appreciate comments from users of this new class concerning their experience with the functionality, speed improvements or degradation, compilation time and code size. Note that if you want to do I/O or use the interpreter (CINT or Python) with this templated class, you must generate the dictionary yourself for the concrete instances that you use. The TMatrix package is a complete Linear Algebra package that includes much more functionality than Smatrix. It can be used automatically with the interpreters and for I/O.



  • PostScript output for surfaces and lego plots using gl2ps.
  • Add the code to generate PostScript output from OpenGL scenes drawn in a pad.
  • StartEmbeddedPS and CloseEmbeddedPS print an Info() message to make clear when gl2ps starts and finishes.

New set of classes dedicated to event visualisation

  • TGLObject: base-class for direct GL renderers
  • TAttBBox: interface, helps maintain/calculate bounding-box needed for TGLObject (see TPointSet3D and TPointSet3DGL)
  • TPointSet3D: a demo class for direct GL rendering
  • TPointSet3DGL.


Small fix for selection/manipulators for multiple viewers case.


  • Provide correct implementations of TVirtualHistPainter::SetShowProjectionX, Y functions
  • Zooming/panning added for legos/surfaces;


  • Changes in TGLEditor, TGLColorEditor, TGLGeometryEditor and TGLSAViewer. The graphical user interface is modified. The old clip editor and lights editor are replaced by TGLViewerEditor. This new GUI is now the same as the TPad and GLViewer one. If one select TGLViewer (shift + left click on a free scene space), the TGLViewerEditor is displayed. If one select an object in GL scene, the color editor and geometry editor for this object are displayed (color and geometry editors work only in standalone viewer now). The TGLViewerEditor can be used in a pad and in a TGLSAFrame.
  • Implement the "Apply to Family" widget/functionality.
  • TGLViewerEditor - TGLViewer's editor for pad (lights/clipping/guides manipulation).


  • Keyboard events are now correctly processed.
  • Process mouse wheel events. It implied also minor changes in TRootCanvas.


  • Fixing wrong clipping parameters.
  • TGLPixmap is replaced by TGLViewer (most of the TGLViewer functionality is available in pad now);
  • TVirtualViewer3D: changes in interface for TGLManager (win32 implementation of TGLManager requires some functions and cannot be dependant from TGLViewer)
  • Added class TVirtualGLManipulator (base for TGLManip) required by TGWin32GL.
  • Complete the "File" menu in the GL viewer (Save, and Quit ROOT)




New hist-painter infrastructure. The first version of TGLLegoPainter, support the following options:
        gl + lego(1)/lego2 + pol/cyl/sph
        gl + lego3
They can be use the following way:
       hpxpy->Draw("gl lego1");
       hpxpy->Draw("gl lego1 pol");
       etc ...
IMPORTANT: this lego painter is still experimantal and works only if it's enabled in system.rootrc. By default, TGLHistPainter is used now. To enable this new system the line:
   Plugin.TGLHistPainter: * TGLHistPainter RGL "TGLHistPainter(TH1*)"
Must be replaced with:
   Plugin.TGLHistPainter: * TGLPadHistPainter RGL "TGLPadHistPainter(TH1*)"
in $ROOTSYS/etc/system.rootrc

Basic graphics


  • A new way to handle the text fonts allowing to include directly the ROOT PDF files into LaTeX documents (compiled with pdflatex). Here is an example showing how to use ROOT PDF file in LaTeX document.
  • Take into account gStyle->GetLineScalePS()

New class TGraphPolar

New class TGraphPolar (from Sebastian Boser), to draw graphs in polar coordinates. This is a first version. It needs many improvements which will appear in the coming releases. An example illustrating TGraphPolar usage can be found in $ROOTSYS/tutorials/graphpolar.C.

TGraph "exclusion zone"

The exclusion zone is "closed" when the first and last points of the graph are the same. Later we can add an option to force the graph closing.


Two new methods SetVertical() and SetHorizontal() to force the line to be drawn vertically or horizontally. It makes fX[Y]2 equal to fX[Y]1. The line length is kept. TArrow and TGaxis also get these functions by inheritance.

Escape mechanism

When ESC is pressed in a canvas, the current graphics editing is canceled. That's a convenient way to avoid unwanted changes or moves.


  • The stats and fit box is now drawn for TH3 like for TH1 and TH2. A clean draw of the under/overflows still need to be implemented.
  • Protection added in TPostScript: In case of very long file name the PS directive %%Title did not fit on one line and generated a wrong PS file.
  • On Windows, time axis now take into account the summer time.


  • Change TGraph::SetPoint to call only gPad->Modified() when changing/adding points instead of deleting the intermediate histogram.
  • When a graph is painted with the option "C" or "L" it is now possible to draw a filled area on one side of the line. This is useful to show exclusion zones. This drawing mode is activated when the absolute value of the graph line width (set thanks to SetLineWidth) is greater than 99. In that case the line width number is interpreted as 100*ff+ll = ffll. The two digits number "ll" represent the normal line width whereas "ff" is the filled area width. The sign of "ffll" allows to flip the filled area from one side of the line to the other. The current fill area attributes are used to draw the hatched zone.
    This new functionality is implemented thanks to the new method TGraph::PaintPolylineHatches().

    $ROOTSYS/tutorials/exclusiongraph.C, $ROOTSYS/tutorials/exclusiongraph2.C:


Protection added to make sure that the line width is positive and smaller than 100.


The special case introduced in revision 1.9 to change the line color in case of hatch styles (3100->3999), is now removed. This case is now handled in TPad::PaintFillAreaHatches, with the other line attributes.


Fix a bug in TGraphQQ::Quartiles when nx=ny


  • In TGraphDelaunay::ComputeZ: Wrong zeros may appeared when points sit on a regular grid. This problem is now fixed. It showed when a TGraph2D was plotted with option "surf1" for instance. Some peaks were visible in random places on the surface.
  • In TGraphPainter::PaintLevels: make sure the z (zo and z2) values are not greater than fZmax or smaller than fZmin. Weird plots were produced (with option TRI1) wihtout this protection.


In TLegend::SavePrimitive save also the border size


In PaintFillAreaHatches the line attributes are now propelly saved before the hatches painting, and restored after.


A canvas internal parameter was not correctly set when the TCanvas::SetCanvasSize method was called. Because of that images generated in batch mode had a wrong size.


Change in TLatex::Analyse(). The method GetTextExtent() was called each time TLatex::Analyse() was called (twice for each LaTex string). It appeared that the call to GetTextExtent() can be ommitted when Analyse() is called to draw the string. This save 5% of the time spent in TLatex drawing.


Remove repeated checks on which font's set should be used (either MS ttf or the free alternatives). These unwanted checks deteriorate the performances.

Canvas in grayscale mode

void TCanvas::SetGrayscale(Bool_t set /*= kTRUE*/) set whether a canvas should be painted in grayscale, and re-paint it if necessary.

One can toggle between a grayscale preview and the regular colored mode using TColor::SetGrayscale(). Note that in grayscale mode, access via RGB will return grayscale values according to ITU standards (and close to b&w printer grayscales), while access via HLS returns de-saturated grayscales.

TCanvas::SetGrayScale is available via the TCanvas context menu.


Implement TPave::DistancetoPrimitive, overloading TBox::DistancetoPrimitive such that picking in a TPave with no fill style is now possible.


  • TH3

    When the mouse is moved in a pad containing a 3-d view of an histogram a second canvas shows a projection type given as option. To stop the generation of the projections, delete the canvas containing the projection. The option can be a combination of the characters x,y,z,e

     option = "x" return the x projection into a TH1D histogram
            option = "y" return the y projection into a TH1D histogram
            option = "z" return the z projection into a TH1D histogram
            option = "xy" return the x versus y projection into a TH2D histogram
            option = "yx" return the y versus x projection into a TH2D histogram
            option = "xz" return the x versus z projection into a TH2D histogram
            option = "zx" return the z versus x projection into a TH2D histogram
            option = "yz" return the y versus z projection into a TH2D histogram
            option = "zy" return the z versus y projection into a TH2D histogram
    the option can also include the drawing option for the projection, eg to draw the xy projection using the draw option "box" do:
            myhist.SetShowProjection("xy box");
    This function is typically called from the context menu. Note that this function is only partially implemented. It works only for the option "xy".

    Thanks to Tim Tran ( for collaborating to this implementation.

  • TH2

    Two new functions can be selected via the TH2 context menu. They are a full implementation of the tutorial DynamicSlices.C

    • void TH2::SetShowProjectionX(): When the mouse is moved in a pad containing a 2-d view of this histogram a second canvas shows the projection along X corresponding to the mouse position along Y. To stop the generation of the projections, delete the canvas containing the projection.
    • void TH2::SetShowProjectionY(): When the mouse is moved in a pad containing a 2-d view of this histogram a second canvas shows the projection along Y corresponding to the mouse position along X. To stop the generation of the projections, delete the canvas containing the projection.


The fit panel opened on the TGraph produced by the following lines, had buttons with no text inside.
          TGraph *g = new TGraph;


A bug introduced after "coding conventions mods" has been fixed.


TShape::Paint was dummy. This method is not needed for TShapes sitting in a TNode. But having it dummy prevent the TShapes outside a TNode to be painted. The following example shows the problem:
            c1 = new TCanvas("c1","Geometry Shapes",200,10,700,500);
            view = new TView(1);
            brik = new TBRIK("BRIK","BRIK","void",200,150,150);

Tutorials and tests

  • tutorials/graph2derrorsfit.C: dte was drawn with the wrong option ("axis" instead of "same")
  • stressGraphics: First version of a new stress program: stressGraphics.cxx. After having typed "make" in the $ROOTSYS/test directory, the executable "stressGraphics" is available. Starting it with option "-h" gives:
    > stressGraphics -h
              Usage: stressGraphics [-h] [-r]
                -r : Generate de reference output.
                     Redirect the output in the file "stressGraphics.ref"
                     to redefine the reference file.
                -h : Print usage
  • The macro tutorials/rose_image.C didn't work when executed using AClic.


  • THistPainter::DistancetoPrimitive finds the x and y axis in case of options "x+" or "y+".
  • Recent improvements in 3D stacks painting have been extended to the options: CYL, POL, SPH & PSR


  • Solve a problem when printing partially hidden (by an OS window) canvas to a gif or jpg file.
  • Streamer method: fix memory leak when reading vector images.
  • Draw method: fix for drawing small images.
  • FromPad method: fix the creation of weird images from shaddowed/overlapped TCanvases.
  • Implement support for zooming non TASImage primitives.


SavePrimitive Methods

  • All existing signals/slots connections are saved in the generated GUI code via SavePrimitive methods. Executing the macro brings back the GUI layout and the action handling for the common case of signals/slots connections with no or one argument.
  • The variable names used in the generated code keep information of its GUI class. The name 'frame' is used as a default name for some service classes.
  • Generate code for Tool tips of text and number entries.
  • Any color parameter has a unique name and allows the generated code to be compiled.
  • New implemented methods in TGLineStyleComboBox, TGLineWidthComboBox, TGNumberEntyField, TGTextView classes.
  • Improved TGListTree::SavePrimitive for saving the entire list tree structure.

Spliter Clases

Added a pixmap on TGHSplitter and TGVSplitter to make them better visible.


  • Added a new parameter in the constructor that allows settings of message text alignment (according to the ETextJustification types: kTextLeft, kTextRight, kTextCenterX, kTextTop, kTextBottom, kTextCenterY).
  • Added new options/buttons requred by PROOF GUI: "Yes to All", "Not to All", "Newer Only", "Appendto All".


New method ChangeText(const char *title) of TGTextButton.


  • Allows selection of any font available for the system environment.
  • New methods: SetFont(TGFont *font), SetColor(Pixel_t color), SetAlign(Int_t align), EnableAlign(Bool_t on).
  • New signal methods: FontSelected(char *font), AlignSelected(Int_t a), ColorSelected(Pixel_t color).


New method SortByName() of TGListBox provides an easy way to sort listbox entries by name/value.


New methods AddPage(), RemovePage(), RenamePage(), Selected().


A simple text editor that uses the TGTextEdit widget. It provides all functionalities of TGTextEdit as copy, paste, cut, search, go to a given line number. In addition, it allows compiling, executing or interrupting a running macro. This class can be used in following ways:
- with file name as argument:

   new TGTextEditor("hsimple.C");
- with a TMacro* as argument:
   TMacro *macro = new TMacro("hsimple.C");
   new TGTextEditor(macro);

  • New Document - To create a new blank document, select File menu / New, or click the New toolbar button. It will create a new instance of TGTextEditor.
  • Open/Save File - To open a file, select File menu / Open or click on the Open toolbar button. This will bring up the standard File Dialog for opening files. If the current document has not been saved yet, you will be asked either to save or abandon the changes. To save the file using the same name, select File menu / Save or the toolbar Save button. To change the file name use File menu / Save As... or corresponding SaveAs button on the toolbar.
  • Text Selection - You can move the cursor by simply clicking on the desired location with the left mouse button. To highlight some text, press the mouse and drag the mouse while holding the left button pressed. To select a word, double-click on it; to select the text line - triple-click on it; to select all do quadruple-click.
  • Cut, Copy, Paste - After selecting some text, you can cut or copy it to the clipboard. A subsequent paste operation will insert the contents of the clipboard at the current cursor location.
  • Text Search - The editor uses a standard Search dialog. You can specify a forward or backward search direction starting from the current cursor location according to the selection made of a case sensitive mode or not. The last search can be repeated by pressing F3.
  • Text Font - You can change the text font by selecting Edit menu / Set Font. The Font Dialog pops up and shows the Name, Style, and Size of any available font. The selected font sample is shown in the preview area.
  • Executing Macros - You can execute the currently loaded macro in the editor by selecting Tools menu / Execute Macro; by clicking on the corresponding toolbar button, or by using Ctrl+F5 accelerator keys. This is identical to the command ".x macro.C" in the root prompt command line.
  • Compiling Macros - The currently loaded macro can be compiled with ACLiC if you select Tools menu / Compile Macro; by clicking on the corresponding toolbar button, or by using Ctrl+F7 accelerator keys. This is identical to the command ".L macro.C++" in the root prompt command line.
  • Interrupting a Running Macro - You can interrupt a running macro by selecting the Tools menu / Interrupt; by clicking on the corresponding toolbar button, or by using Shift+F5 accelerator keys.
  • Interface to CINT Interpreter - Any command entered in the Command combo box will be passed to the CINT interpreter. This combo box will keep the commands history and will allow you to re-execute the same commands during an editor session.
  • See the Help for the list of the keyboard shortcuts and accelerator keys.

Line Editor

Line Editor is adapted to the new TGraph's line width convention.

Graph Editor

The user interface of Graph editor is modified for handling the TGraph's Exclusion Zone:
  • '+-' check button sets on which side of the line the exclusion zone will be drawn
  • the combo box defines the width of the zone.


The user interface provided by this new editor shows up if you select TF1 objects in the canvas window (after left-mouse click on it). It shows the function title, the number of function parameters (if any), number of points used for the function graphics and the function range.

  • The check button 'Update' allows you to set immediate update of the function graphics after any interactive action via this interface.
  • The button 'SetParameters..." will pop up a dialog showing the settings of function parameters (as values, parameter limits and parameter status (fixed or not).
  • The 'Points' number entry allows you to change the number of points used for the function graphics.
  • The slider allows you to change the function range along the x-axis.


This new class provides a dialog for function parameters' settings. It appears when you click on the SetParameters... button.

  • Name - All assigned parameters' names appear in this vertical column. In this first prototype any parameter field only shows the parameter name and does not allow editing.
  • Fix check button - If selected, it sets the corresponding parameter as fixed. The parameter limits become equal to the parameter value and the slider is not available.
  • Value - All fields in this vertical column shows the current parameters' values of which the function graphics was drawn. A tooltip appears on each Value field showing only the parameter name for faster re-call and check-in. You can change the parameter value in two ways: 1/ by entering the new value using the keyboard or editing selected numbers 'on place'; 2/ by using the up/down spin buttons of the number entry field by scrolling through a small set of predefined choices. When a parameter value reaches one of the already set upper or lower parameter limits, the corresponding bound changes to the new parameter value set by this field. The parameter value field became non-editable when the parameter is set to fixed. The scrolling step size can be changed with control and shift keys:
    • Shift - medium step (10 units/factor of 10);
    • Control - large step (100 units/factor of 30);
    • Shift-Control - huge step (1000 units/factor of 100).
  • Min and Max - All fields in these vertical columns show the lower and upper parameter bounds setting. If there were no parameter limits set (i.e. both were equal to zero), the values set in these fields were calculated following way:
    • if the parameter has an error:
      min_value = par_value - 3*par_error
      max_value = par_value + 3*par_error
    • if the parameter has no error:
      min_value = par_value - 0.1*par_value
      max_value = par_value + 0.1*par_value
    • if the parameter value is 0:
      min_value = max_value = 1.
    You can change the Min and Max field by entering the new value using the keyboard or editing some selected numbers 'on place'. To apply your change you need to hit Enter key in the end.
  • Set Range sliders - Every function parameter has an assosiated slider to the parameter value and limits. The slider allows you to change interactively the parameter value by dragging the slider pointer to a new position. You can also change the parameter limits by pressing the left-mouse button near to the left slider edge for the lower parameter bound, or by pressing the left-mouse button near to the right slider edge for the upper parameter bound. To change both values you can press the left-mouse button near to the slider center and to drag it to a new position.
  • Immediate preview button - Select this check button if you want to see immediate update of the function graphics following any parameter change you perform. We do not recomend to do that for functions that require heavy calculations. In that case leave the button unselected and use the Apply button.
  • Apply button - Pressing it, you require an update of the function graphics according to the changes you have made in this dialog. The new settings were used but at that point they were not set to the function parameters. To do that you must click on the OK button.
  • Reset Button - Clicking on it you can reset all fields to the parameters' values at the moment the dialog was invoked. This is useful if you want to discard some changes you have already applied. The Reset button returns you to the beginning and you could start changing the parameters' values in another way.
  • OK button - Applies the current parameters' settings, updates the function graphics (if Apply button was not used before) and closes this dialog.
  • Cancel button - Discards any parameter changes and closes this dialog.
  • Close [x] button of Window Manager - When closing the dialog via [x] button on the top right corner and some parameters' values were changed, a message "Do you want to apply last parameters" setting?" will be displayed with Yes, No and Cancel buttons.
    • Yes - applies the parameter settings, updates the function graphics; closes the message box and the dialog window.
    • No - discards all changes and closes the message box and the dialog window.
    • Cancel - closes the message box giving you the possibilities to perform new parameters' settings in the dialog.

Qt BNL Interface

  • Qt layer code cleaned up by removing several redundant classes and Win32 dependencies.
  • Implemented keyboard navigation.
  • Added Qt4 CPP compilation flag for future transition to Qt4.
  • For "pure" Qt GUI application ROOT prompt, ROOT terminal input handler and CTRL-C signal handler is disabled "by default". To get the ROOT interactive command mode back you need to include in your .rootrc file the statement:
     Gui.Prompt       true 

GSI QtRoot

The Qt Interface developed at the GSI is a light weight  interface that enables the user to write a Qt 3 application which can use ROOT. The Native Qt 4 support is planned and will be available very soon.  Furthermore, existing Qt 3 Application can use this interface to have almost full access to the Root functionality (see "Create the Main file for the project" below). Using this interface a full access to both ROOT and Qt widgets is possible in one application.

An Embedded Root canvas can be set inside any Qt widget either by C++ calls or using the Qt designer. To use the Qt 3.x designer to make ROOT applications with Qt GUI's see below:  

I. Add the TQRootCanvas to the Qt Designer:

1. Start the designer
2. In the designer menu choose tools->custom->Edit Custom Widget
3. In the Edit Custom Widget window choose "Load Description"
4. From GSI Qt-Root interface directory load the file ""



    Now you will see the TQRootCanvas in the Class field, you will also
    see all other parameters, signals, slots and properties of the TQRootCanvas.

    Now we are ready use the TQRootCanvas within the Qt 3.x designer.

    II. Create a new Project in the designer

    1. Choose "File->New"
    2. Select C++ Project 
    3. create the Project in a directory of your choice 

        The project setting:

    1. Select Project->Setting from the designer main windows 

    2. in The Project setting window select the C++ tab 

    3. to the Libs line you have to add the Root libraries and the GSI Qt-Root interface  for example:

        -L(ROOTSYS)/lib -lCore -lCint -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lnsl -lm -ldl -rdynamic  -lqtgsi

    4. to the Includepath line add:    $(ROOTSYS)/include 

    these setting will be saved in file and the qmake will generate the Makefile
    according to these settings.

    III. Now you can create your own widgets in the designer and add them to the project


    IV. Create the Main file for the project

    The main file should look like:

    #include "TQtApplication.h"
    #include "TQtRootApplication.h"

    #include "MyWidget1.h"

    int main( int argc, char ** argv ){

        TQRootApplication a( argc, argv, 0);
        TQApplication app("uno",&argc,argv);

        MyWidget1 *w = new Mywidget1;
        a.connect( &a, SIGNAL( lastWindowClosed() ), &a, SLOT( quit() ) );
        return a.exec();

    in blue are the differences to a standard Qt main file.

  •       Examples:

    1.  The first example shows how to use Qt3 and root without the Qt designer. This program has three different "modes" .ie.
                  * mode 0 : type `./qtroot 0' (Qtroot alone)
                  * mode 1 : type `./qtroot 1' (QtROOT + TBrowser)
                  * mode 2 : type `./qtroot 2' (QtROOT + TBrowser + Guitest (ROOT GUI"S examples))

    2. The second example shows how to use the Qt designer as described above to create Qt - Root applications.

    GUI Builder

    The ROOT GUI builder provides graphical user-interface (GUI) tools for developing user interfaces based on the ROOT GUI classes. It includes over 30 advanced widgets and has as a goal to offer the complete set of features needed for developing the GUI projects. It gives developers an effective object-oriented development environment and accelerates the GUI development life cycles. The new version of the GUI builder has a new look and better appearance.

    Improved Functionality

    • New functionality added via menus and the tool bar.
    • Drag/Drop of selected frames.
    • Copy/Paste/Cut of selected widget.
    • Open/Save of the designed GUI in a macro.
    • Easy layout settings and widget alignment.
    • Improved keyboard navigation.
    • Widget's attributes can be changed via dynamically created context menus or activated edit dialogs.
    • Many new widgets were added to the widgets' palette as the next picture shows.

    • New "grabbing" features by using Enter (Return) key: if there is a lasso drawn, a new composite frame is created and all frames inside the lasso are adopted as children of this container frame. If a lasso is not drawn and selected frame is a container frame, it becomes the container of a new TGCanvas widget. The Ctrl+Enter keys provide the reverce "ungrab action". All frames inside the grabbed frame are "dropped" into the underlying frame and the grabbed frame is deleted. If selected/grabbed frame is TGCanvas widget (scrolled frame), the TGCanvas is deleted and container frame becomes a child of the frame in edit mode.
    • Introduced following EEditMode bit flags in TGWindow for simplifying the design process:
      	   enum  EEditMode {
      	      kEditEnable        = 0,         // allow edit
      	      kEditDisable       = BIT(0),    // disable edit
      	      kEditDisableEvents = BIT(1),    // window events cannot be edited
      	      kEditDisableGrab   = BIT(2),    // window grab cannot be edited
      	      kEditDisableLayout = BIT(3),    // window layout cannot be edited
      	      kEditDisableResize = BIT(4),    // window size cannot be edited
      	      kEditDisableHeight = BIT(5),    // window height cannot be edited
      	      kEditDisableWidth  = BIT(6)     // window width cannon be edited
    • Any ROOT GUI application can be switched to the editable mode allowing already existing user interface elements in container frames to be just drag-and-drop to another main frame.
    The user interface elements can be selected, positioned, and grouped, laid out in the main application frame. According to the selected widget, a dynamically created context menu provides detailed control of widget attributes’ settings.

    Starting the Builder

    Select GUI builder from the canvas Inspect menu of from the ROOT Object browser (TBrowser) File menu. On the ROOT prompt line you can enter:

    root[] new TGuiBuilder

    The Builder Interface

    • Opening an Existing User Interface
      • Click the Open button on the toolbar of the main builder window. This will bring up a File Open dialog.
      • Use the File Open dialog to navigate within your directory structure. When you locate the file of your choice, select it and then press Open button.
    • Saving Your User Interface
      • Click the Save button on the toolbar of the main builder window. This will bring up a File Save As dialog.
      • Navigate within your directory structure and when you locate the place of your choice, save your interface in a file by pressing the Save button.
      • If you want to save only a selected container frame, double-click on it. This will generate a macro and will execute it (showing up "what is really created into the generated code").
    • Steps of creating the interface:
      • Click on Project button in the Widget's Palette (the first icon). By this, a window is created which will form the main window of your GUI.
      • Turn the edit mode ON for that window.
      • Add different widgets to your main frame: text entry, buttons, list box, etc.

      • The frame layout can be changed by using Property editor on the right.

      • Once the frame is successfully created, the designed GUI can be saved in a macro.
      • The generated macro can be opened in the GUI builder and additional widgets can be added to the previously saved main farme. For that you do not need to edit the code using an external text editor - just create your new design and save it again in a macro. This macro can be run separatelly in a ROOT session.

    New features in the Geometry classes


    The visualization manager for TGeo objects (TGeoPainter) fully using geometry iterators (TGeoIterator). The main advantages are that: the painter does not need to change the top volume for TGeoManager and the loops are not longer recursive. This makes painting a process that does not affect any more the manager class. It makes possible having parallel views of different parts of a geometry (or different geometries). New features:
    • Visualisation options can be set at the level of volumes and there are new methods accessible from the context menu of TGeoVolume:
      • TGeoVolume::SetVisContainers: draw all containers
      • TGeoVolume::SetVisLeaves : draw only leaves
      • TGeoVolume::SetVisOnly : draw only this volume
      These options are operational only for the current drawn volume, which is accesible even from the pad when approaching the right edge with the mouse.
    • The manager class can also be accessed from the pad approaching the top right corner (40x40 pixels).
    • Possibility to draw individual shapes:


    • New method allowing automatic replacement of virtual container volumes with assemblies:
        TGeoManager::TransformVolumeToAssembly(const char *vname);
      The method will create an assembly for each volume named VNAME in the geometry and replace it.
    • Improvements of the overlap checker: assembly content now checked + improvement in performance when assemblies are involved
    • Geometry locking possible. This prevents loading or creating a new geometry while the current one is in lock state. It also prevents calling TGeoPhysicalNode::Align() while in lock state.
        TGeoManager::LockGeometry(); // to lock
        TGeoManager::UnlockGeometry(); // to unlock
        Bool_t TGeoManager::IsLocked(); // to check


    • Navigation in assembly + MANY do not post warnings anymore
    • Fixes in SavePrimitive (by Mihaela Gheata) for TGeoHMatrix and TGeoVolume when having several with the same name. Assemblies now supported when exporting the geometry as C macro.
    • TGeoPgon::DistFromInside() fixed precision problem
    • Precision problems fixed for navigation within divided volumes
    • TGeoXtru shape can now be defined with polygone vertices both clockwise or anticlockwise in the XY plane
    • Corrected computation of the bounding box of assemblies in some particular cases.

    Geometry graphics user interface

    The new geombuilder package allows creation and editing geometries based on TGeo classes. The package usage is documented at pages 336-340 of the Users Guide. The package provides a library of all GUI classes related to geometry. It allows editing the parameters of existing geometry objects, as well as creating new shapes, materials, matrices, volumes and connecting them in a geometry structure.
    The geometry manager editor
    In the current release, the following functionality is provided:
    • Editing an existing geometry. The following objects are editable:
      • Volumes and volume assemblies
      Volume editor
      • Shapes: most primitive shapes except, Arb8, polygonal extrusions and composite shapes.
      • Matrices: translations, rotations and combinations of these.
      • Materials (no mixtures yet).
      • Media.
    • Creating the above geometry objects and positioning volumes.

    Shape editor
    Material editor
    Medium editor
    Matrix editor
    • Few steps for creating a geometry:
      1. Create a new geometry manager and start the editor:
    root[] TGeoManager *geom = new TGeoManager(“MyGeom”, “Test builder”);
    root[] geom->Edit(Option_t *option=””);

      1. Create at least one material from the "Materials" shutter item category. Generally, for creating objects, the interface is always in the TGeoManagerEditor in different categories - one should just provide a name and requested parameters.
      2. Create a shape that will be used for the top volume within the "Shapes" category. For the moment, the shapes that have editors are Box, Para, Trd1, Trd2, Tube, Tube segment, Cone, Cone segment, Hype, Pcon, Torus and Sphere.
      3. Create a medium from one of the existing materials from the "Medium" category. You will notice that some categories as "Volume" and "Medium" are inactive at the beginning because at that time there is no material yet (for making a medium) and no shape (for making a volume). These categories are dynamically activated once all the required components are defined.
      4. Create a volume from the "Volumes" category. You will notice that contrary to the other editors, the volume editor is opened in a tab, not transient - this is because it is more complex.
      5. Go back to "General" category and select the newly created volume as the top one (you can do it also from the volume category). This is just for starting. To create some hierarchy, one has to create several other volumes and the matrices to position them. Once this is done, use the volume editor interface to:
    • Add/remove daughters, change shape, edit position of daughters
    • Change visualization settings
    • Divide the volume (only if there are no daughters yet)
      1. Close the geometry from the “General” category.
    • More details on how to start editing geometry, how to use editors and how to create geometry structures can be found in the Users Guide.


    New Features

    • Add possibility to hard code the type of a data member with the selection.xml mechanism with the attribute "iotype". Eg.
         <class name="TrackD32" > 
           <field name="fCov" iotype="ROOT:Math::SMatrix<Double32_t,5,5>" > 
    • New optional argument for function "ROOT::Reflex::Type ROOT::Reflex::Type::ToType(unsigned int mod = 0)". The argument accepts ROOT::Reflex::FINAL which will resolve to the final type in case of a typedef
    • Bug (wish) #14487 overview: Reflex dictionary generation using typedefs in XML Adding possibility to select classes/structs through the xml selection mechanism by their typedef name
    • New feature for Cpp selection mechanism. If a class in the Cpp selection namespace contains a member of type "NO_SELF_AUTOSELECT", then this class will NOT be selected for dictionary generation (but dictionaries for any member types etc. in this class will be generated)
    • New function Tools::FundamentalType(const Type &) which returns an enum representing the fundamental types passed in
    • New static function Scope::GlobalScope() which returns the Scope representation of the global namespace
    • Type::ToType will return the current type if a modifier (e.g. FINAL) was passed as argument. This behaviour will change for the forthcoming release. Probably making FinalType an extra function
    • Adding possibility to get ref access to properties. The access has to be done via the address (otherwise one receives a copy)
    • Adding using directives (add/get) to the Scope


    • Fix bug #15232 overview: Reflex dictionary does not compile for classes with overloaded new operator Two new functions (each) added for the direct binding of the "new" and "new []" operator which can be used if only one of the new operators (placement or non placement) is overloaded. The generated dictionary source code will bind to these new functions if only one of the new operators is overloaded (calling the global new for the other case)
    • If a type is forward declared in the unnamed namespace and subsequently used as a type, the internal name given by gcc to the unnamed namespace, has to be stripped off from the type name.
    • Changing stub functions to handle conversion operators to pointers to member function. In this case a typedef for the function type is needed (e.g. when generating a dictionary for boost::shared_ptr)
    • Fix for shadow class generation. In case of a templated class which is template instantiated on a function pointer and contains a member of type T, the name of the member has to appear outside the type.
    • Fix for shadow class generation: In case of a member and a type having the same string representation in the same scope the type needs to be addressed with the type (e.g. "struct") prepended.



    There are several improvements for specific python coding idioms, to the pythonization of ROOT classes, a few optimizations, and some re-wiring for the benefit of PyCintex.

    Interpreter environment

    Global functions can now be used anywhere as drop-in replacements for python functions, the __repr__ printout of proxy objects has been prettified, variables of builtin types can be assigned directly in the ROOT module and be available to CINT, diagnostics for unset errors have been improved, const globals and enums are made read-only, pointer/class based object comparison has been added. The module shutdown sequence has been made explicitly to prevent cycles that can not be handled by the garbage collector during shutdown. Batch mode can be set by first importing gROOT before anything else, and then switching to batch.

    C++ language and pythonization

    Overloading of functions has been improved with a priority scheme that favors classes with known dictionaries and penalizes void* arguments, and some more boundary checks for builtin types have been added. Unloaded, but known, namespaces are now normally accessible, (builtin) types can be used for template type parameters, and use of return-by-ref assignments from operator() is supported through operator[] with equivalent arguments. New pythonizations are: support for smart pointer dereferencing, a TClass.StaticCast with expected semantics, return type casting on TClass.DynamicCast, direct lookup in TFile objects, and looping over TTree and TTree derived classes. Method object carry a "disp" method that allows explicit selection of an overload, using its signature.


    Although still not recommended for use, "from ROOT import *" now scales as expected, and its overhead compared to "import ROOT" has been minimized. Class lookup has been improved by using a cache, primarily for the benefit of object returns.


    New style, new functionality:

    • new beautification engine marking keywords, strings, comments.
    • header files are now beautified, too
    • layouts CSS steered for easy customization
    • comments picked up in header files, for inline and pure virtual methods:
      class A {
      // doc for f
      void f() = 0;
      inline void f2();
      // doc for f2
      void A::f2() {}

    Changes in the test directory and new tests

    • New stress/benchmark program stressFit. This test program tests a variety of difficult minimization cases. It can be invoked with the Minuit or Minuit2 minimization classes (default is Minuit). The program is automatically built by the test Makefile. To run it:
         stressFit      (use Minuit by default)
         stressFit Minuit2
    • The test program stressgeom has been renamed stressShapes to be consistent with the names of the other stress programs.
    • A new geometry test program has been added stressGeometry. The program uses the geometry for severa large detectors (Alice, Atlas, CMS, Lhcb, Babar, CDF, Brahms, Aleph). It computes "where am I" , distance to next bounday, total number of radiation lengths up to the exit of the detector and compares the results with a reference file for each detector.
    • New graphics test suite stressGraphics. This program tests all the basic graphics primitives, high level primitives like TGraph, TH1, TF1, etc with all possible options. A postscript file is created for each test. Its length is compared with a reference value.

    New tutorials

    • gltf3.C
    • exclusiongraph.C
    • exclusiongraph2.C
    • FFT.C
    • geomBrahms.C
    • geomAlice.C
    • geomAlice_itsv.C
    • geomAtlas.C
    • graphpolar.C
    • xmlreadfile.C
    • xmlnewfile.C
    • testrandom.C
    • references.C
    • mathcoreVectorFloatIO.C

    ROOT page - Class index - Top of the page