Explanation of changes in patch ah-container-nopy
=================================================

- bin/Makefile.am 

  - install the program rivet-nopy since it's useful
	for debugging code 
  
- bin/rivet-nopy.cc 

  - Add more options to make it more compatible with the python
    script. 
  - Add help output 
  - Allow logging from the application it self 
  - Make a progress meter 
  - Allow multiple input sources 
  - Use Rivet::Run for steering run
  - Allow user to specify output (or no output)
  
- include/Rivet/AnalysisHandler.hh 
  src/Core/AnalysisHandler.cc
  
  - Use a std::vector (rather than a std::set) to store the analyses
    objects in. 
	
	std::set is an ordered container.  In the current implementation
    of Rivet, this ordering is done on the address of the analyses
    objects which is entirely random.
	
	At a minimum, that makes the capabilities of std::set totally
    superfluous since the ordering is anyway random and fluctuates
    from run to run (in a platform dependent way).
	
	But perhaps even more important, it does not allow the user to
    specify in which order the analysis should be executed.
	
	The patch changes the container type to be a std::vector which
    means the analyses objects will be executed in the order given by
    the user.
	
	This is useful, for example, if one uses an analyses object to
    set-up cuts which other analyses may pick up.  A real use case is
    given by centrality calibrations in AA collisions.  In general,
    a centrality calibration depends on the collision system and
    energy, and the model and model tune used.  Hence, we need
    different calibrations for each of these combinations.  The _only_
    way to do that in Rivet currently is to have a  collision system and
    energy, and the model and model tune dependent analysis object
    that set's up the calibrations which subsequent analyses may then
    pick up via a static shared_ptr.  See for example 
	
	  https://gitlab.cern.ch/cholm/alice-rivet
	 
    Now, of course, if there was some way for an analysis object to
    pick up external data in some robust way, this would not be
    needed.  Clearly, an analysis object can open _any_ stream it
    likes, but without mechanisms for it in Rivet makes it
    error-prone. 
	
	Another way to ensure ordering of analyses execution would be to
    assign some sort of priority to each analysis object.  That is, an
    analysis writer may want a particular analysis to run last, and
    would then do 
	
		virtual unsigned int priority() const { return RunLast; }
		
	or perhaps some 'dont-care' value 
	
		virtual unsigned int priority() const { return UNDEFINED; }
		
	The sorting function of the std::set should then use these
    priorities to order the analyses objects properly.  Analyses
    objects with the same priority could be sorted alphabetically or
    the like. 
	
Yours,

Christian