[Proof] Remove PROOF

.github/CODEOWNERS

@@ -32,7 +32,6 @@ interpreter/cling/tools/packaging @vgvassilev
 /misc/ @dpiparo
 /montecarlo/ @dpiparo
 /net/ @gganis
-/proof/ @gganis
 /roofit/ @lmoneta @guitargeek
 /rootx/ @dpiparo
 /sql/ @pcanal @linev

CMakeLists.txt

@@ -409,9 +409,6 @@ add_subdirectory (misc)
 add_subdirectory (main)
 add_subdirectory (bindings)
 add_subdirectory (sql)
-if(proof)
-  add_subdirectory(proof)
-endif()
 if(tmva)
   add_subdirectory(tmva)
 endif()

README/README.AUTH

@@ -26,12 +26,7 @@ table (column Sfx) to the specified protocol: for example
 
   TFile *f = TFile::Open("roots://host.doma.in/~fserv/TheFile.root","read")
 
-requires the use of the SRP method, and
-
-  gROOT->Proof("proofk://lxplus079.cern.ch")
-
-asks for Kerberos authentication in starting a proof session on node
-lxplus079.cern.ch.
+requires the use of the SRP method.
 
 Defaults can be changed on {host, user} base via the file $HOME/.rootauthrc;
 the header of the file $ROOTSYS/etc/system.rootauthrc, automatically generated
@@ -77,52 +72,6 @@ the server sends back the list of the remaining methods accepted (if any); the
 client compares the server list with its own list of remaining methods and
 makes a new attempt if the overlap of the two lists is not empty; and so on.
 
-
-Slave/Data servers authentication during a PROOF session
-========================================================
-
-During a PROOF session there is the potential problem of Master/Slave or
-Slave/Data_Server authentication. For slaves, the list of methods to be tried
-is specified in the proof.conf file as a list of methods short names. However,
-before build the corresponding entry in THostAuth (see below) TProofServ checks
-that the method can be applied, i.e. that there exist valid credentials.
-The way the latter are transmitted depends on the method and on the
-Client/Master authentication method.
-
- * UsrPwd: to authenticate 'usrpwd' to slaves, the master needs the relevant
-           entry in the .netrc or .rootnetrc files; however, if the
-           client/master authentication was also 'usrpwd', the password is
-           already present on the master process and is used for later clear
-           authentications.
-
- * SRP:    to authenticate 'SRP' to slaves, the master needs the relevant entry
-           in the .netrc or .rootnetrc files; the syntax is the same as for
-           'usrpwd' authentication with the keyword 'secure' at the place of
-           'machine'. However, if the client/master authentication was also
-           'SRP', the master can receive the password from the client; the
-           password is sent encrypted with the internal RSA key generated for
-           the session. To use this option, set 'Proofd.SendSRPPwd 1' in your
-           .rootrc (default is 0).
-
- * Krb5/Globus  to authenticate Krb5/Globus to slaves, the master needs globus
-           credentials; this is possible (and automatic) only if the
-           client/master authentication was also Krb5/Globus.
-
- * UidGid  to authenticate 'uidgid' to slaves, the user must have the same
-           (uid,gid) on master and slaves.
-
-Negotiation is active also between master and slaves, so asking for 'uidgid'
-first may accelerate the authentication process if the server accepts it.
-
-The method actually used is listed by gProof->Print("a").
-
-If the slaves need to access data servers which are not part of the proof
-cluster, the login info vis-a-vis of these may be specified with the proofserv
-card in the .rootauthrc files (see below and etc/system.rootauthrc for
-details); the collected information is then transmitted to all the active
-slaves upon creation.
-
-
 Entries in .rootrc
 ==================
 
@@ -243,8 +192,6 @@ classes to display/modify/create THostAuth interactively.
       <opt> = "s" list of active security context (default)
               "h" the content of the instantiated THostAuth objects in
                   standard list
-              "p" the content of the instantiated THostAuth objects in
-                  the proof list
 
    Example:
 
@@ -308,13 +255,13 @@ Info in <THostAuth::Print>:  + Method: 1 (SRP) Ok:0 Ko:0 Dets:pt:no ru:1 us:gani
 Info in <THostAuth::Print>:  +------------------------------------------------------------------+
 Info in <::Print>:  +---------------------------- END ---------------------------------+
 
-  This is the list build following the 'proofserv' directives in .rootauthrc
+  This is the list build following the directives in .rootauthrc
 
  * THostAuth *TAuthenticate::GetHostAuth(<host_fqdn>,<user>,<opt>,<kExact>);
 
    Returns a pointer to the THostAuth object pertaining to (host,user) if it
    exist, 0 otherwise. If <opt>="R" (default) the search is performed in the
-   standard list, if <opt>="P" in the proof list. The last argument <kExact>
+   standard list. The last argument <kExact>
    is a pointer to an integer: if defined (.ne. 0) the pointed location is
    filled with 1 if the match is exact, with 0 if an matching entry with wild
    cards was found.

README/README.SELECTOR

@@ -10,32 +10,17 @@ derives from the TSelector class and implements the member functions
 with specific analysis algorithms. When running the analysis, ROOT
 calls the member functions in a well defined sequence and with well
 defined arguments. By following the model this analysis class can be
-used to process data sequentialy on a local workstation and in batch
-or in parallel using PROOF.
+used to process data sequentially.
 
 ROOT can generate a skeleton class for a given TTree. This skeleton
 class is a good a starting point for the analysis class. It is
 recommended that users follow this method.
 
-When running with PROOF a number of "slave" processes are used to
-analyze the events. The user creates a PROOF session from the client
-workstation which allocates a number of slaves. The slaves instantiate
-an object of the users analysis class. Each slave processes a fraction
-of the events as determined by the relative performance of the servers
-on which the slaves are running. The PROOF system takes care of distributing
-the work. It calls the TSelector functions in each slave. It also
-distributes the input list to the slaves. This is a TList with streamable
-objects provided in the client. After processing the events PROOF combines
-the partial results of the slaves and returns the consolidated objects
-(e.g. histograms) to the client session.
-
 The two sequences below show the order in which the TSelector member
 functions are called when either processing a tree or chain on a single
-workstation or when using PROOF to process trees or collections of keyed
-objects on a distributed system. When running on a sequential query
-the user calls TTree::Process() and TChain::Process(), when using PROOF
-the user calls TDSet::Process() (a few other entry points are available
-as well). Each of the member functions is described in detail after the
+workstation. When running on a sequential query
+the user calls TTree::Process() and TChain::Process().
+Each of the member functions is described in detail after the
 call sequences.
 
 
@@ -57,29 +42,6 @@ Init()
 SlaveTerminate()
 Terminate()
 
-
-Distributed, parallel query, using PROOF:
-
-++ CLIENT Session ++       ++ (n) SLAVES ++
-Begin()
-                           SlaveBegin()
-                           Init()
-                              Notify()
-                                 Process()
-                                 ...
-                                 Process()
-                           ...
-                           Init()
-                              Notify()
-                                 Process()
-                                 ...
-                                 Process()
-                           ...
-                           SlaveTerminate()
-Terminate()
-
-
-
 ==============================================================================
 Main Framework Functions
 ==============================================================================
@@ -89,18 +51,12 @@ The Begin() and SlaveBegin() member functions
 
 The Begin() function is called at the start of the query. It always runs
 in the client ROOT session. The SlaveBegin() function is either called
-in the client or when running with PROOF, on each of the slaves.
+in the client.
 All initialization that is needed for Process() (see below) must therefore
 be put in SlaveBegin(). Code which needs to access the local client
 environment, e.g. graphics or the filesystem must be put in Begin().
-When running with PROOF the input list (fInput) is distributed to the
-slaves after Begin() returns and before SlaveBegin() is called.
-This way objects on the client can be made available to the
-TSelector instances in the slaves.
 
-The tree argument is deprecated. (In the case of PROOF the tree is not
-available on the client and 0 will be passed. The Init() function should
-be used to implement operations depending on the tree)
+The tree argument is deprecated.
 
 Signature:
 
@@ -115,8 +71,7 @@ The Init() member function
 The Init() function is called when the selector needs to initialize
 a new tree or chain. Typically here the branch addresses of the tree
 will be set. It is normally not necessary to make changes to the generated
-code, but the routine can be extended by the user if needed. Init() will
-be called many times when running with PROOF.
+code, but the routine can be extended by the user if needed.
 
 Signature:
 
@@ -127,8 +82,8 @@ The Notify() member function
 ----------------------------
 
 The Notify() function is called when a new file is opened. This can be either
-for a new TTree in a TChain or when when a new TTree is started when using
-PROOF. Typically here the branch pointers will be retrieved. It is normaly
+for a new TTree in a TChain.
+Typically here the branch pointers will be retrieved. It is normally
 not necessary to make changes to the generated code, but the routine
 can be extended by the user if needed.
 
@@ -140,13 +95,11 @@ Signature:
 The Process() member function
 -----------------------------
 
-The Process() function is called for each entry in the tree (or possibly
-keyed object in the case of PROOF) to be processed. The entry argument
+The Process() function is called for each entry in the tree 
+to be processed. The entry argument
 specifies which entry in the currently loaded tree is to be processed.
 It can be passed to either TTree::GetEntry() or TBranch::GetEntry()
-to read either all or the required parts of the data. When processing
-keyed objects with PROOF, the object is already loaded and is available
-via the fObject pointer.
+to read either all or the required parts of the data.
 
 This function should contain the "body" of the analysis. It can contain
 simple or elaborate selection criteria, run algorithms on the data
@@ -161,11 +114,7 @@ The SlaveTerminate() and Terminate() member functions
 -----------------------------------------------------
 
 The SlaveTerminate() function is called after all entries or objects
-have been processed. When running with PROOF it is executed by
-each of the slaves. It can be used to do post processing before the
-partial results of the slaves are merged. After SlaveTerminate()
-the objects in the fOutput lists in the slaves are combined by the
-PROOF system and returned to the client ROOT session.
+have been processed.
 The Terminate() function is the last function to be called during
 a query. It always runs on the client, it can be used to present
 the results graphically or save the results to file.
@@ -198,8 +147,7 @@ Signature:
 The SetInputList() member function
 ----------------------------------
 
-Setter for the input list of objects to be transfered to the
-remote PROOF servers. The input list is transfered after the execution
+The input list is transfered after the execution
 of the Begin() function, so objects can still be added in Begin() to
 this list. These objects are then available during the selection process
 (e.g. predefined histograms, etc.). Does not transfer ownership.
@@ -214,10 +162,8 @@ The GetOutputList() member function
 
 Getter for the output list of objects to be transfered back to the
 client. The output list on each slave is transfered back to the client
-session after the execution of the SlaveTerminate() function. The PROOF
-master server merges the objects from the slave output lists in a single
-output list (merging partial objects into a single one). Ownership remains
-with the selector. Each query will clear this list.
+session after the execution of the SlaveTerminate() function.
+Ownership remains with the selector. Each query will clear this list.
 
 Signature:
 

README/ReleaseNotes/empty.md

@@ -69,62 +69,24 @@ The following people have contributed to this new version:
 
 ## Deprecation and Removal
 
+## Python Interface
 
-## Core Libraries
+## I/O
 
+## Core
 
-## I/O Libraries
+## Histograms
 
+## Math
 
-## TTree Libraries
+## RooFit
 
+## Graphics and GUI
 
-## Histogram Libraries
+## Geometry
 
+## Documentation and Examples
 
-## Math Libraries
-
-
-## RooFit Libraries
-
-## Graphics Backends
-
-## 2D Graphics Libraries
-
-
-## 3D Graphics Libraries
-
-
-## Geometry Libraries
-
-
-## Database Libraries
-
-
-## Networking Libraries
-
-
-## GUI Libraries
-
-
-## Montecarlo Libraries
-
-
-## PROOF Libraries
-
-
-## Language Bindings
-
-
-## JavaScript ROOT
-
-
-## Tutorials
-
-
-## Class Reference Guide
-
-
-## Build, Configuration and Testing Infrastructure
+## Build, Configuration and Testing
 
 

README/ReleaseNotes/v638/index.md

@@ -5,6 +5,7 @@
 * The build options `mysql`, `odbc` and `pgsql`, that were deprecated in ROOT 6.36, are now removed.
 * The `TGLWSIncludes.h` header is deprecated and will be removed in ROOT 6.40
 * The `ROOT::Math::TDataPointN` class that can be used with the `ROOT::Math::KDETree` was removed. Use the templated `TDataPoint<N>` instead.
+* The Parallel ROOT Facility, `PROOF`, has been removed from the repository.
 
 ## Core Libraries
 * Behavior change: when selecting a template instantiation for a dictionary, all the template arguments have to be fully defined - the forward declarations are not enough any more. The error prompted by the dictionary generator will be `Warning: Unused class rule: MyTemplate<MyFwdDeclaredClass>`.

bindings/jupyroot/python/JupyROOT/helpers/cppcompleter.py

@@ -13,9 +13,9 @@
 # For the list of contributors see $ROOTSYS/README/CREDITS.                    #
 ################################################################################
 
 from JupyROOT.helpers import utils
 import platform
 import ROOT
 
 # Jit a wrapper for the ttabcom
 _TTabComHookCode = """
@@ -86,7 +86,6 @@
     TROOT::IsLineProcessing
     TROOT::IsModified
     TROOT::IsOnHeap
-    TROOT::IsProofServ
     TROOT::IsRootFile
     TROOT::IsSortable
     TROOT::IsWebDisplay
@@ -138,7 +137,7 @@
         suggestions = [ str(s) for s in self._getSuggestions(line) ]
         suggestions = filter(lambda s: len(s.strip()) != 0, suggestions)
         suggestions = sorted(suggestions)
         if not suggestions: return []
         # Remove combinations of opening and closing brackets and just opening
         # brackets at the end of a line. Jupyter seems to expect functions
         # without these brackets to work properly. The brackets of'operator()'