[log] init methods and named parameters
I've gotten a head start looking at the boost.log library that will be reviewed in a couple weeks. The utility methods utilize boost.parameter's named parameters. For example, boost::log::init_log_to_file. I would like to decide at runtime (via a config file) which set of parameters will listed. For example, rotation_size or rotation_interval or both. It is my first real use of boost.parameter so I may be missing something that is common knowledge. I don't see an easy way to do this. I thought maybe building a fusion sequence of parameters or something like that was the way to go... Looking for guidance. Thanks. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On 02/27/2010 11:26 PM, Michael Caisse wrote:
I've gotten a head start looking at the boost.log library that will be reviewed in a couple weeks.
The utility methods utilize boost.parameter's named parameters. For example, boost::log::init_log_to_file.
I would like to decide at runtime (via a config file) which set of parameters will listed. For example, rotation_size or rotation_interval or both.
It is my first real use of boost.parameter so I may be missing something that is common knowledge. I don't see an easy way to do this. I thought maybe building a fusion sequence of parameters or something like that was the way to go... Looking for guidance. Thanks.
Boost.Parameter is not suited well for run time parameter composition. Perhaps, what you're looking for is better achieved with init_from_stream or init_from_settings.
Andrey Semashev wrote:
Boost.Parameter is not suited well for run time parameter composition. Perhaps, what you're looking for is better achieved with init_from_stream or init_from_settings. _______________________________________________
Andrey - Thanks for the response. Let me start with mentioning that I have initially found this library useful. The trivial logging has satisfied many of my first usage patterns. However, I am finding it very difficult to follow the documentation. For example, the tutorial section is not complete enough to fabricate a working example. Specifically, the lack of header definitions has become mind numbing. If there was some macro include boost/log/log.hpp or something when you are starting out ... it would be very helpful. For a specific illustration, "Setting up sinks" calls a utility named init_log_to_file. It took me way too long to figure out which include file had this. I want to follow along in the tutorial and actually *try* the examples myself. Better yet, the documentation is generated via boostbook, utilize the feature to pull code examples directly from real working code. (see spirit docs for examples) This approach makes it easy for the user to follow along the tutorial and also ensures that your code examples are indeed correct and without flaw. The tutorials can all be compiled and checked just like regressions. And now for my latest documentation hiccup: init_from_stream and init_from_settings both look promising. I pull up the docs and take a look at each. I follow the basic_settings link. I poke around some more..... and now I'm getting frustrated again. Where do I find list of possible settings? Why isn't there a link in the docs to give me a hint of where to go? Thanks! I am looking forward to fully reviewing your library. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On 02/28/2010 02:16 AM, Michael Caisse wrote:
However, I am finding it very difficult to follow the documentation. For example, the tutorial section is not complete enough to fabricate a working example. Specifically, the lack of header definitions has become mind numbing. If there was some macro include boost/log/log.hpp or something when you are starting out ... it would be very helpful.
1. There is no boost/log/log.hpp that includes everything because it is not needed. You don't need all the library included everywhere you use logging. There are headers that include all sinks, all loggers, etc. 2. The tutorial is intended to give you an idea of the library usage. It is not intended to give you a working and meaningful example in the end. For that go to the examples directory. 3. Headers are defined in every section of the detailed feature description.
Better yet, the documentation is generated via boostbook, utilize the feature to pull code examples directly from real working code. (see spirit docs for examples) This approach makes it easy for the user to follow along the tutorial and also ensures that your code examples are indeed correct and without flaw. The tutorials can all be compiled and checked just like regressions.
I thought of that, but never got around to do it.
And now for my latest documentation hiccup: init_from_stream and init_from_settings both look promising. I pull up the docs and take a look at each. I follow the basic_settings link. I poke around some more..... and now I'm getting frustrated again. Where do I find list of possible settings? Why isn't there a link in the docs to give me a hint of where to go?
http://tinyurl.com/ybxzlec All parameters are described in tables, with an example in the end.
On Sun, Feb 28, 2010 at 11:14 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
And now for my latest documentation hiccup: init_from_stream and init_from_settings both look promising. I pull up the docs and take a look at each. I follow the basic_settings link. I poke around some more..... and now I'm getting frustrated again. Where do I find list of possible settings? Why isn't there a link in the docs to give me a hint of where to go?
All parameters are described in tables, with an example in the end.
From skimming the implementation I saw that you implemented parsing the configuration files yourself. Without knowing your code/requirements in detail, I wondered if the initialize by settings functionality couldn't be implemented by reusing boost.program_options [1] and therby reducing the amount of code to maintain in boost.log?
-- Christoph [1] http://bit.ly/94opNx
On 03/05/2010 04:37 PM, Christoph Heindl wrote:
On Sun, Feb 28, 2010 at 11:14 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
And now for my latest documentation hiccup: init_from_stream and init_from_settings both look promising. I pull up the docs and take a look at each. I follow the basic_settings link. I poke around some more..... and now I'm getting frustrated again. Where do I find list of possible settings? Why isn't there a link in the docs to give me a hint of where to go?
All parameters are described in tables, with an example in the end.
From skimming the implementation I saw that you implemented parsing the configuration files yourself. Without knowing your code/requirements in detail, I wondered if the initialize by settings functionality couldn't be implemented by reusing boost.program_options [1] and therby reducing the amount of code to maintain in boost.log?
I don't think so, from my knowledge of Boost.ProgramOptions. The problem is that in order to employ Boost.ProgramOptions I'd have to describe all options I expect in the file. IOW, the set of parameters is fixed. The current parser in Boost.Log, on the other hand, parses all options given and then acts accordingly. For example, a user may specify different sets of sinks (represented with sections in the settings file), and the library should register the sinks as specified in the file.
I don't think so, from my knowledge of Boost.ProgramOptions. The problem is that in order to employ Boost.ProgramOptions I'd have to describe all options I expect in the file. IOW, the set of parameters is fixed. The current parser in Boost.Log, on the other hand, parses all options given and then acts accordingly. For example, a user may specify different sets of sinks (represented with sections in the settings file), and the library should register the sinks as specified in the file.
As far as I remember boost.program_options allows you to parse unregistered options without throwing errors. http://bit.ly/a8L1O5 -- Christoph
On 03/05/2010 07:22 PM, Christoph Heindl wrote:
I don't think so, from my knowledge of Boost.ProgramOptions. The problem is that in order to employ Boost.ProgramOptions I'd have to describe all options I expect in the file. IOW, the set of parameters is fixed. The current parser in Boost.Log, on the other hand, parses all options given and then acts accordingly. For example, a user may specify different sets of sinks (represented with sections in the settings file), and the library should register the sinks as specified in the file.
As far as I remember boost.program_options allows you to parse unregistered options without throwing errors.
That's about command line parser. However, looking at the parse_config_file function reference I see there is some flag that hints that unknown options should be accepted. There are no docs on this feature, and the function interface is not described. It's also not clear how do I work with the result of this function. Given the fact I already have a working solution, I don't think there's enough reason to add yet more dependencies on other libraries to Boost.Log.
However, looking at the parse_config_file function reference I see there is some flag that hints that unknown options should be accepted. There are no docs on this feature, and the function interface is not described. It's also not clear how do I work with the result of this function.
something along the lines of std::ifstream ifs(config_file.c_str()); po::store(po::parse_config_file(ifs, desc, true), vm); ifs.close(); po::notify(vm); will do the parsing. The parsed variables can then be accessed from the variables map. -- Christoph
participants (3)
-
Andrey Semashev -
Christoph Heindl -
Michael Caisse