Functions | |
| MessageLogger Default Configuration and Control of Modes The issue is that we want the defaults | currently (as of 6/5/07) taken from MessageLogger.cfi to be hard-wired |
| analysis jobs want it to be The Plan To | address (1) |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode::To | address (3) |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode::To there should be an option to cmsRun of mode which takes values etc One of | these (likely grid) will be the default as well.Then at cmsRun time |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode::To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To | address (2) |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode::To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as then that list will be REPLACED by the one actually supplied Steps A Use of the MessageLoggerDefaults decide what is in the structure We should make this nested probably A2 Create the modes which must live in MessageLogger rather than MessageService A3 Write a ctor based on the existing cfi for the basic default mode A4 Modify | configure () and the like |
Variables | |
| MessageLogger Default Configuration and Control of Modes The issue is that we want the defaults such that jobs not mentioning the logger at all in configuration get these There are three difficulties that the plan presented here will | address |
| MessageLogger Default Configuration and Control of Modes The issue is that we want the defaults such that jobs not mentioning the logger at all in configuration get these There are three difficulties that the plan presented here will it will be a maintenance headache And the pace of change in requested defaults is non negligible The use of these defaults is scattered through the MessageLoggerScribe code This is one big file to wade through If it were broken into coherent | pieces |
| MessageLogger Default Configuration and Control of Modes The issue is that we want the defaults such that jobs not mentioning the logger at all in configuration get these There are three difficulties that the plan presented here will it will be a maintenance headache And the pace of change in requested defaults is non negligible The use of these defaults is scattered through the MessageLoggerScribe code This is one big file to wade through If it were broken into coherent then the problem would change to searching through multiple smaller | files |
| still a headache We still need to provide the flexibility currently offered by the cfg file In | particular |
| still a headache We still need to provide the flexibility currently offered by the cfg file In if a user wants to have completely different destination | outputs |
| still a headache We still need to provide the flexibility currently offered by the cfg file In if a user wants to have completely different destination we should not force upon her the default files as well This issue is highly relevant for unit | testing |
| still a headache We still need to provide the flexibility currently offered by the cfg file In if a user wants to have completely different destination we should not force upon her the default files as well This issue is highly relevant for unit and may be important in other situations too The appropriate defaults are in some instances defendant on the mode of running For | instance |
| still a headache We still need to provide the flexibility currently offered by the cfg file In if a user wants to have completely different destination we should not force upon her the default files as well This issue is highly relevant for unit and may be important in other situations too The appropriate defaults are in some instances defendant on the mode of running For batch reco or simulation jobs want reportEvery for FwkReport to be | one |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode::To there should be an option to cmsRun of mode which takes values | grid |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode::To there should be an option to cmsRun of mode which takes values | analysis |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode::To there should be an option to cmsRun of mode which takes values etc One of we check the mode | specified |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode::To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of | destinations |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode::To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as | follows |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode::To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as then that list will be REPLACED by the one actually supplied Steps A Use of the MessageLoggerDefaults | structure |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode::To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as then that list will be REPLACED by the one actually supplied Steps A Use of the MessageLoggerDefaults decide what is in the structure We should make this nested | classes |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode::To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as then that list will be REPLACED by the one actually supplied Steps A Use of the MessageLoggerDefaults decide what is in the structure We should make this nested probably A2 Create the modes | enum |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode::To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as then that list will be REPLACED by the one actually supplied Steps A Use of the MessageLoggerDefaults decide what is in the structure We should make this nested probably A2 Create the modes which must live in MessageLogger rather than MessageService A3 Write a ctor based on the existing cfi | file |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode::To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as then that list will be REPLACED by the one actually supplied Steps A Use of the MessageLoggerDefaults decide what is in the structure We should make this nested probably A2 Create the modes which must live in MessageLogger rather than MessageService A3 Write a ctor based on the existing cfi for the basic default mode A4 Modify to use these defaults Pay attention to the issue of empty or non empty destination list A5 Unit test make certain the behavior with and without the cfi file is identical This unit test can be written in parallel to A1 | A4 |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode::To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as then that list will be REPLACED by the one actually supplied Steps A Use of the MessageLoggerDefaults decide what is in the structure We should make this nested probably A2 Create the modes which must live in MessageLogger rather than MessageService A3 Write a ctor based on the existing cfi for the basic default mode A4 Modify to use these defaults Pay attention to the issue of empty or non empty destination list A5 Unit test make certain the behavior with and without the cfi file is identical This unit test can be written in parallel to A1 and ought to send various sorts of messages so as to exercise the various settings B Supply of mode B1 Create a MODE opcode for the | MessageLoggerQ |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode::To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as then that list will be REPLACED by the one actually supplied Steps A Use of the MessageLoggerDefaults decide what is in the structure We should make this nested probably A2 Create the modes which must live in MessageLogger rather than MessageService A3 Write a ctor based on the existing cfi for the basic default mode A4 Modify to use these defaults Pay attention to the issue of empty or non empty destination list A5 Unit test make certain the behavior with and without the cfi file is identical This unit test can be written in parallel to A1 and ought to send various sorts of messages so as to exercise the various settings B Supply of mode B1 Create a MODE opcode for the which causes the modes enum saved for use by so that other non cmsRun jobs won t be screwed up B3 Create a mode or m command line option in cmsRun which uses the MODE opcode B4 Re run the A5 Unit test C Aternative modes C1 Create at least one alternative | mode |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode:: To address | ( | 3 | ) |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode:: To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To address | ( | 2 | ) |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode:: To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as then that list will be REPLACED by the one actually supplied Steps A Use of the MessageLoggerDefaults decide what is in the structure We should make this nested probably A2 Create the modes which must live in MessageLogger rather than MessageService A3 Write a ctor based on the existing cfi for the basic default mode A4 Modify configure | ( | ) |
| MessageLogger Default Configuration and Control of Modes The issue is that we want the defaults currently | ( | as of 6/5/ | 07 | ) |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode:: To there should be an option to cmsRun of mode which takes values etc One of these | ( | likely | grid | ) |
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode:: To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as then that list will be REPLACED by the one actually supplied Steps A Use of the MessageLoggerDefaults decide what is in the structure We should make this nested probably A2 Create the modes which must live in MessageLogger rather than MessageService A3 Write a ctor based on the existing cfi for the basic default mode A4 Modify to use these defaults Pay attention to the issue of empty or non empty destination list A5 Unit test make certain the behavior with and without the cfi file is identical This unit test can be written in parallel to A1 A4 |
Definition at line 66 of file defaultsAndControl.txt.
| MessageLogger Default Configuration and Control of Modes The issue is that we want the defaults such that jobs not mentioning the logger at all in configuration get these There are three difficulties that the plan presented here will address |
Definition at line 9 of file defaultsAndControl.txt.
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode:: To there should be an option to cmsRun of mode which takes values analysis |
Definition at line 33 of file defaultsAndControl.txt.
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode:: To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as then that list will be REPLACED by the one actually supplied Steps A Use of the MessageLoggerDefaults decide what is in the structure We should make this nested classes |
Definition at line 40 of file defaultsAndControl.txt.
| 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 or destinations provided in the Extension package These destinations are places to store display the actual issues messages Each of the ordinary destinations is represented as a named ParameterSet object in destinations statistic destinations |
Definition at line 40 of file defaultsAndControl.txt.
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode:: To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as then that list will be REPLACED by the one actually supplied Steps A Use of the MessageLoggerDefaults decide what is in the structure We should make this nested probably A2 Create the modes enum |
Definition at line 40 of file defaultsAndControl.txt.
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode:: To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as then that list will be REPLACED by the one actually supplied Steps A Use of the MessageLoggerDefaults decide what is in the structure We should make this nested probably A2 Create the modes which must live in MessageLogger rather than MessageService A3 Write a ctor based on the existing cfi file |
Definition at line 40 of file defaultsAndControl.txt.
| MessageLogger Default Configuration and Control of Modes The issue is that we want the defaults such that jobs not mentioning the logger at all in configuration get these There are three difficulties that the plan presented here will it will be a maintenance headache And the pace of change in requested defaults is non negligible The use of these defaults is scattered through the MessageLoggerScribe code This is one big file to wade through If it were broken into coherent then the problem would change to searching through multiple smaller files |
Definition at line 9 of file defaultsAndControl.txt.
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode:: To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as follows |
Definition at line 40 of file defaultsAndControl.txt.
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode:: To there should be an option to cmsRun of mode which takes values grid |
Definition at line 33 of file defaultsAndControl.txt.
| still a headache We still need to provide the flexibility currently offered by the cfg file In if a user wants to have completely different destination we should not force upon her the default files as well This issue is highly relevant for unit and may be important in other situations too The appropriate defaults are in some instances defendant on the mode of running For instance |
Definition at line 18 of file defaultsAndControl.txt.
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode:: To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as then that list will be REPLACED by the one actually supplied Steps A Use of the MessageLoggerDefaults decide what is in the structure We should make this nested probably A2 Create the modes which must live in MessageLogger rather than MessageService A3 Write a ctor based on the existing cfi for the basic default mode A4 Modify to use these defaults Pay attention to the issue of empty or non empty destination list A5 Unit test make certain the behavior with and without the cfi file is identical This unit test can be written in parallel to A1 and ought to send various sorts of messages so as to exercise the various settings B Supply of mode B1 Create a MODE opcode for the MessageLoggerQ |
Definition at line 66 of file defaultsAndControl.txt.
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode:: To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as then that list will be REPLACED by the one actually supplied Steps A Use of the MessageLoggerDefaults decide what is in the structure We should make this nested probably A2 Create the modes which must live in MessageLogger rather than MessageService A3 Write a ctor based on the existing cfi for the basic default mode A4 Modify to use these defaults Pay attention to the issue of empty or non empty destination list A5 Unit test make certain the behavior with and without the cfi file is identical This unit test can be written in parallel to A1 and ought to send various sorts of messages so as to exercise the various settings B Supply of mode B1 Create a MODE opcode for the which causes the modes enum saved for use by so that other non cmsRun jobs won t be screwed up B3 Create a mode or m command line option in cmsRun which uses the MODE opcode B4 Re run the A5 Unit test C Aternative modes C1 Create at least one alternative mode |
Definition at line 86 of file defaultsAndControl.txt.
| still a headache We still need to provide the flexibility currently offered by the cfg file In if a user wants to have completely different destination we should not force upon her the default files as well This issue is highly relevant for unit and may be important in other situations too The appropriate defaults are in some instances defendant on the mode of running For batch reco or simulation jobs want reportEvery for FwkReport to be one |
Definition at line 18 of file defaultsAndControl.txt.
| still a headache We still need to provide the flexibility currently offered by the cfg file In if a user wants to have completely different destination outputs |
Definition at line 18 of file defaultsAndControl.txt.
| still a headache We still need to provide the flexibility currently offered by the cfg file In particular |
Definition at line 18 of file defaultsAndControl.txt.
| MessageLogger Default Configuration and Control of Modes The issue is that we want the defaults such that jobs not mentioning the logger at all in configuration get these There are three difficulties that the plan presented here will it will be a maintenance headache And the pace of change in requested defaults is non negligible The use of these defaults is scattered through the MessageLoggerScribe code This is one big file to wade through If it were broken into coherent pieces |
Definition at line 9 of file defaultsAndControl.txt.
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode:: To there should be an option to cmsRun of mode which takes values etc One of we check the mode specified |
Definition at line 36 of file defaultsAndControl.txt.
| analysis jobs want it to be The Plan To we should place the defaults into one structure which I will call MessageLoggerDefaults Its ctor should take as an argument an enum MessageLoggingMode:: To there should be an option to cmsRun of mode which takes values etc One of we check the mode and send a message to the scribe indicating that it will need to construct its defaults accordingly To we note that the only serious headaches from these defaults would be the issue of different sets of and potential inability to remove or modify one of the defaulted values The latter concern is not really problematic because any configuration settings that do appear will everride the defautls we are supplying The destination list issue should be resolved as then that list will be REPLACED by the one actually supplied Steps A Use of the MessageLoggerDefaults structure |
Definition at line 40 of file defaultsAndControl.txt.
| still a headache We still need to provide the flexibility currently offered by the cfg file In if a user wants to have completely different destination we should not force upon her the default files as well This issue is highly relevant for unit testing |
Definition at line 18 of file defaultsAndControl.txt.
1.8.11
