Typedefs | Functions | Variables
canvas/doc/PLUGIN_NOTES.txt File Reference
#include "canvas/Utilities/UnixSignalhandlers.h"
#include "canvas/Utilities/LoadAllDictionaries.h"
#include "canvas/Persistency/Common/InitRootHandlers.h"

Typedefs

using program.Plugins = ======Each module class must be defined in its own dynamic library, which must be named``lib_< module >_plugin.< suffix >``, where *< suffix > *is whatever is appropriate for the platform
 

Functions

EDFilter * makeFilter (string spec, ParameterSet p)
 
EDAnalyzer * makeAnalyzer (string spec, ParameterSet p)
 
*LibraryManager *::explicit LibraryManager (string pattern)
 
void * getSymbol (string spec, string symbol)
 
void getLoadableLibraries (string type, vector< string > &libnames)
 
Current Services files per event or module (not edm datafile)
 
inst presentToken () -> getParameterSets(psets)
 
 for (ParameterSets::iterator cur=psets.begin(), end=fillme.end();cur!=end;++cur)
 

Variables

 EDFilters
 
 EDAnalyzers
 
OutputModules and Sources **NOTE that will make much of the current OutputModules and Sources irrelevant When the framework executable starts up
 
OutputModules and Sources **NOTE that will make much of the current OutputModules and Sources irrelevant When the framework executable starts the class names for the modules and services to be loaded are obtained from the configuration A module *Factory *is used to create the modules Factory
 
OutputModules and Sources **NOTE that will make much of the current OutputModules and Sources irrelevant When the framework executable starts the class names for the modules and services to be loaded are obtained from the configuration A module *Factory *is used to create the modules the configuration will announce
 
OutputModules and Sources **NOTE that will make much of the current OutputModules and Sources irrelevant When the framework executable starts the class names for the modules and services to be loaded are obtained from the configuration A module *Factory *is used to create the modules the configuration will ParameterSet const & config
 
an exception should be thrown only if an ambiguous lookup is attempted It is an error to register more than one *factory function *for any long form name
 
the attempt to do so should result in an informative exception being thrown Before it is used to create modules the *Factory *must be loaded with the appropriate *factory **functions *This is done with the help of the *LibraryManager * LibraryManager
 
these are called *plugin *libraries Plugin libraries are loaded by the *LibraryManager *see above The source file in which a module is implemented must be named< module > _plugin cc It must contain an invocation of the *DEFINE_EDM_PLUGIN *macro The *DEFINE_EDM_PLUGIN *macro is responsible for writing the appropriate *factory **function * FactoryFunctions
 
these are called *plugin *libraries Plugin libraries are loaded by the *LibraryManager *see above The source file in which a module is implemented must be named< module > _plugin cc It must contain an invocation of the *DEFINE_EDM_PLUGIN *macro The *DEFINE_EDM_PLUGIN *macro is responsible for writing the appropriate *factory **function and that takes a const reference to a *ParameterSet *and that returns a newly created instance of the associated module type
 
these are called *plugin *libraries Plugin libraries are loaded by the *LibraryManager *see above The source file in which a module is implemented must be named< module > _plugin cc It must contain an invocation of the *DEFINE_EDM_PLUGIN *macro The *DEFINE_EDM_PLUGIN *macro is responsible for writing the appropriate *factory **function and that takes a const reference to a *ParameterSet *and that returns a newly created instance of the associated module initialized with the given *ParameterSet and wrapped in a smart pointer to the appropriate module base class e::g *EDProducer *EDFilter etc::extern C { std::auto_ptr<type> make(ParameterSet const&)
 
*EVERYTHING BELOW THIS POINT IS SUBJECT TO CHANGE * Interfaces
 
Current Services Qualities
 
API for accessing service parameters sets
 
ServiceRegistry * inst = ServiceRegistry::instance()
 
ParameterSets psets
 

Typedef Documentation

using program. Plugins = ====== Each module class must be defined in its own dynamic library, which must be named ``lib_<module>_plugin.<suffix>``, where *<suffix>* is whatever is appropriate for the platform

Definition at line 99 of file PLUGIN_NOTES.txt.

Function Documentation

for ( ParameterSets::iterator  cur = psets.begin(),
end  = fillme.end(); cur!=end;++cur 
)

Definition at line 218 of file PLUGIN_NOTES.txt.

220 {
221  cout << "service name = " << cur->get<std::string>("service_type") <<
222  "\n";
223  cur->put<int>("DebugLevel",10);
224 }
string
std::string string
Definition: nybbler.cc:12
dbjson.cur
cur
Definition: dbjson.py:21
cout
the ParameterSet object passed in for the configuration of a destination should be the only source that can affect the behavior of that destination This is to eliminate the dependencies of configuring a destination from multiple mostly from the defaults It suppresses possible glitches about changing the configuration file somewhere outside of a destination segament might still affect the behavior of that destination In the previous configuration for a specific the value of a certain e may come from following and have been suppressed It the configuring ParameterSet object for each destination will be required to carry a parameter list as complete as possible If a parameter still cannot be found in the ParameterSet the configuration code will go look for a hardwired default directly The model is a great simplicity comparing with the previous especially when looking for default values Another great advantage is most of the parameters now have very limited places that allows to appear Usually they can only appear at one certain level in a configuration file For in the old configuring model or in a default ParameterSet object inside of a or in a category or in a severity object This layout of multiple sources for a single parameter brings great confusion in both writing a configuration and in processing the configuration file Under the new the only allowed place for the parameter limit to appear is inside of a category which is inside of a destination object Other improvements simplify the meaning of a destination name In the old a destination name has multiple folds of meanings the e cout and cerr have the special meaning of logging messages to standard output or standard error the name also serves as the output filename if the destination is a file these names are also references to look up for detailed configurations in configuring the MessageFacility The multi purpose of the destination name might cause some unwanted behavior in either writing or parsing the configuration file To amend in the new model the destination name is now merely a name for a which might represent the literal purpose of this or just an id All other meanings of the destinations names now go into the destination ParameterSet as individual such as the type parameter and filename parameter Following is the deatiled rule for the new configuring Everything that is related with MessageFacility configuration must be wrapped in a single ParameterSet object with the name MessageFacility The MessageFacility ParameterSet object contains a series of top level parameters These parameters can be chosen a vector of string listing the name of debug enabled models Or use *to enable debug messages in all modules a vector of string a vector of string a vector of string a ParameterSet object containing the list of all destinations The destinations ParameterSet object is a combination of ParameterSet objects for individual destinations There are two types of destinations that you can insert in the destinations ParameterSet ordinary including cout
Definition: MessageFacilityAsStandAlonePackage.txt:82
void getLoadableLibraries ( string  type,
vector< string > &  libnames 
)
void* getSymbol ( string  spec,
string  symbol 
)
* LibraryManager* :: explicit LibraryManager ( string  pattern)
EDAnalyzer* makeAnalyzer ( string  spec,
ParameterSet  p 
)
EDFilter* makeFilter ( string  spec,
ParameterSet  p 
)
Current Services files per event or module ( not edm  datafile)
inst presentToken ( ) -> getParameterSets(psets)

Variable Documentation

OutputModules and Sources** NOTE that will make much of the current OutputModules and Sources irrelevant When the framework executable starts the class names for the modules and services to be loaded are obtained from the configuration A module* Factory* is used to create the modules the configuration will announce

Definition at line 16 of file PLUGIN_NOTES.txt.

these are called* plugin* libraries Plugin libraries are loaded by the* LibraryManager* see above The source file in which a module is implemented must be named<module> _plugin cc It must contain an invocation of the* DEFINE_EDM_PLUGIN* macro The* DEFINE_EDM_PLUGIN* macro is responsible for writing the appropriate* factory* * function and that takes a const reference to a* ParameterSet* and that returns a newly created instance of the associated module initialized with the given* ParameterSet and wrapped in a smart pointer to the appropriate module base class e::g* EDProducer * EDFilter etc :: extern C { std::auto_ptr<type> make(ParameterSet const&)

Definition at line 121 of file PLUGIN_NOTES.txt.

OutputModules and Sources** NOTE that will make much of the current OutputModules and Sources irrelevant When the framework executable starts the class names for the modules and services to be loaded are obtained from the configuration A module* Factory* is used to create the modules the configuration will ParameterSet const& config

Definition at line 16 of file PLUGIN_NOTES.txt.

EDAnalyzers

Definition at line 1 of file PLUGIN_NOTES.txt.

EDFilters

Definition at line 1 of file PLUGIN_NOTES.txt.

OutputModules and Sources** NOTE that will make much of the current OutputModules and Sources irrelevant When the framework executable starts the class names for the modules and services to be loaded are obtained from the configuration A module* Factory* is used to create the modules Factory
Initial value:
=======
For a given module
a
const double a
Definition: gUpMuFluxGen.cxx:164
module
Current Services files per event or module(not edm datafile)

Definition at line 16 of file PLUGIN_NOTES.txt.

these are called* plugin* libraries Plugin libraries are loaded by the* LibraryManager* see above The source file in which a module is implemented must be named<module> _plugin cc It must contain an invocation of the* DEFINE_EDM_PLUGIN* macro The* DEFINE_EDM_PLUGIN* macro is responsible for writing the appropriate* factory* * function* FactoryFunctions
Initial value:
================
The *factory* *function* is an ``extern "C"`` function named
make
is
it is part of the same thread as the issuing message Thus when it sets up that info is available for stuffing into the ErrorObj or use in deciding whether to react to a LogDebug The information provided is
Definition: Design_and_maintenance.txt:176
art::InputSourceFactory::make
unique_ptr< InputSource > make(ParameterSet const &conf, InputSourceDescription &desc)
Definition: InputSourceFactory.cc:23

Definition at line 112 of file PLUGIN_NOTES.txt.

ServiceRegistry* inst = ServiceRegistry::instance()

Definition at line 213 of file PLUGIN_NOTES.txt.

* EVERYTHING BELOW THIS POINT IS SUBJECT TO CHANGE* Interfaces
Initial value:
==========
*Factory*::
EDProducer* makeProducer(string spec, ParameterSet p)
ParameterSet
THREADING problem if a is a ParameterSetID and value is a ParameterSet
Definition: fhiclcpp_threading_notes_supporting_details.txt:762
Factory
OutputModules and Sources **NOTE that will make much of the current OutputModules and Sources irrelevant When the framework executable starts the class names for the modules and services to be loaded are obtained from the configuration A module *Factory *is used to create the modules Factory
Definition: PLUGIN_NOTES.txt:16
p
ParameterSet &ps const ParameterSet const * p
Definition: fhiclcpp_threading_notes_supporting_details.txt:734

Definition at line 127 of file PLUGIN_NOTES.txt.

the attempt to do so should result in an informative exception being thrown Before it is used to create modules the* Factory* must be loaded with the appropriate* factory* * functions* This is done with the help of the* LibraryManager* LibraryManager
Initial value:
==============
The *LibraryManager* is the class used to load dynamic libraries
containing the implementation of modules
and of services.
The *LibraryManager* is responsible for scanning ``LD_LIBRARY_PATH``
to find all dynamic libraries with names matching the file glob
"\*_plugin.<suffix>"
is
it is part of the same thread as the issuing message Thus when it sets up that info is available for stuffing into the ErrorObj or use in deciding whether to react to a LogDebug The information provided is
Definition: Design_and_maintenance.txt:176
names
and for the C binding for for a description of how the parameter values associated with these parameter names are available to C programs Top level names
Definition: PARAMETERS.txt:29
used
services supplied by experiments are configured by parameters in the contained table named *user *The suggested type for those parameters is *table which is beyond the scope of this document Names in the *source an *EmptySource *configured to deliver one event is constructed If a *source *table is the only parameter required names the type of source to be used
Definition: PARAMETERS.txt:126
of
another_number of
Definition: to_indented_string_annotated_test-ref.txt:6
LibraryManager
the attempt to do so should result in an informative exception being thrown Before it is used to create modules the *Factory *must be loaded with the appropriate *factory **functions *This is done with the help of the *LibraryManager * LibraryManager
Definition: PLUGIN_NOTES.txt:66
the
another_number the
Definition: to_indented_string_annotated_test-ref.txt:6
modules
the full set is shown in Appendix B the code for the module creates a class derived from for different sorts of modules
Definition: moduleTracking.txt:44
ValidateOpDetReco.all
dictionary all
Flash Comparison #.
Definition: ValidateOpDetReco.py:331
file
< separator(=)> module_type Type Source location< separator(-)> DummyAnalyzer analyzer< path > DummyAnalyzer_module cc DummyFilter filter< path > DummyFilter_module cc *DummyProducer producer< path > DummyProducer_module cc *DummyProducer producer< path > DummyProducer_module cc< separator(=)> The modules marked *above are degenerate i e specifying the short module_type value leads to an ambiguity In order to use a degenerate in your configuration file
Definition: BasicOptions_03-ref.txt:15
implementation
The use this makes sure that code that *calls *this function takes ownership of the newly created object With such an implementation
Definition: PointerGuidelines.txt:142

Definition at line 66 of file PLUGIN_NOTES.txt.

an exception should be thrown only if an ambiguous lookup is attempted It is an error to register more than one* factory function* for any long form name

Definition at line 55 of file PLUGIN_NOTES.txt.

ParameterSets psets

Definition at line 214 of file PLUGIN_NOTES.txt.

Current Services Qualities
Initial value:
===========================
All qualities are boolean. Here is the meaning of them:
* C = configuration can be given
* A = activity registry is needed for construction
* P = public interface is provided
* O = optional service
* D = output to console
are
these are all by getting the vString this is set to true if debugModules is non empty everyDebugEnabled_ is a global scope variable instantiated as false in MessageLogger cc In the ctor of this is set to true if nay one of debugModules is *debugEnabledModules_ contains the specified debugModules If debugEnabled is set to then the effect of LogDebug used during that module is to immediately return A subtlety arose concerning the MessageDrop in circumstances where the framework s event processing structure were not in play In if preModule were never then debugEnabled would remain whatever value it had on construction of the MessageDrop the value was left uninitialized Now it is initialized to true in the ctor for we change debugEnabled MessageDrop s debugEnabled to false Configuring Destinations The each destination has its own tables of what to do about each category and but we get various overall defaults fromm the cfg file as well The limit instructions at the MessageLogger level takes on forms in order of priority of these are
Definition: Design_and_maintenance.txt:216
is
it is part of the same thread as the issuing message Thus when it sets up that info is available for stuffing into the ErrorObj or use in deciding whether to react to a LogDebug The information provided is
Definition: Design_and_maintenance.txt:176
of
another_number of
Definition: to_indented_string_annotated_test-ref.txt:6
them
Gallery scripts No building is so no makefile is then we d need to add gallery as a product that dunetpc depends on To run them
Definition: README.txt:5
service
for in the course of each when the analysis path comes to this the including up to two for each service
Definition: moduleTracking.txt:74
the
another_number the
Definition: to_indented_string_annotated_test-ref.txt:6
output
Note that event though this is a statistics it goes into the map named destination we want to output
Definition: MakingNewDefaults.txt:124
provided
Making New Hardwired Defaults for the and how to create a specialized set of selectable by doing mute mode whateverNameYouChoose The MessageLogger has a set of hardwired for use when no MessageLogger configuration appears in the config file These match the contents of the MessageLogger cfi file Although these defaults are hardwired into it is recognized that changing circumstances and experience withthe framework will make necessary changes in the defaults the defaults are kept in a clean form in one for ease of modification Multiple sets of these defaults can be provided
Definition: MakingNewDefaults.txt:5
registry
return registry
Definition: fhiclcpp_threading_notes_supporting_details.txt:1496

Definition at line 154 of file PLUGIN_NOTES.txt.

API for accessing service parameters sets
Initial value:
=========================================
typedef std::vector<fhicl::ParameterSet> ParameterSets

Definition at line 210 of file PLUGIN_NOTES.txt.

these are called* plugin* libraries Plugin libraries are loaded by the* LibraryManager* see above The source file in which a module is implemented must be named<module> _plugin cc It must contain an invocation of the* DEFINE_EDM_PLUGIN* macro The* DEFINE_EDM_PLUGIN* macro is responsible for writing the appropriate* factory* * function and that takes a const reference to a* ParameterSet* and that returns a newly created instance of the associated module type

Definition at line 112 of file PLUGIN_NOTES.txt.

OutputModules and Sources** NOTE that will make much of the current OutputModules and Sources irrelevant When the framework executable starts up

Definition at line 1 of file PLUGIN_NOTES.txt.

Generated by   doxygen 1.8.11