On Friday 22 March 2013 13:50:53 Rene Rivera wrote:

You never need permission to merge to trunk. Unless you are asking the author of the library. And then just ask the author directly.

I'm the author. But ok, I thought I needed a permission. Thank you.

On Friday 22 March 2013 20:17:06 Daniel James wrote:

On 22 March 2013 18:56, Andrey Semashev wrote:

...

On Friday 22 March 2013 13:50:53 Rene Rivera wrote:

...

You never need permission to merge to trunk. Unless you are asking the author of the library. And then just ask the author directly.

I'm the author. But ok, I thought I needed a permission. Thank you.

You do need to meet the conditions set in the review. So I think you need the review manager's approval.

Vladimir, could you give your permission for Boost.Log inclusion into Boost? For your convenience I'm re-posting a few essential links: Review result: http://lists.boost.org/boost-announce/2010/03/0256.php My post with the actions taken on the issues in the review result: http://lists.boost.org/Archives/boost/2013/03/201623.php Library docs: http://boost-log.sourceforge.net/libs/log/doc/html/index.html Library code: svn co https://boost-log.svn.sourceforge.net/svnroot/boost-log/trunk/boost-log

On Thu, Mar 28, 2013 at 4:46 PM, Vladimir Prus wrote:

- Anybody who participated in Boost.Log discussion, or want to use it, or use it, please speak up.

I should do a review tonight or tomorrow. Should I answer the classic review questions or is there a mini-review specific question set? Joel Lamotte

Then I will write a brief summary of my point of view. First, I think boost.log is by far the best logging system I've used, simply because it don't impose anything on the way I want the logging to be setup. I have one project in development using it (I will use it soon in another project which is open source). It's a game, multi-threaded (using tbb and boost), multi-process (client/server even with one computer solo game). It's composed of a lot of dlls, one hosting basic system code, like logging. Note that so far I only compiled both my projects and boost.log on Visual Studio 2010 and 2012 (my project only compile with 2012). I intend to try with clang and gcc but will not be able to work on this for several months. In this project I simplified the use of logs a lot, so I don't really use channels and other filtering features. However, I do use heavy/complex formatting and multiple sinks (vs console, console, files) with different formatting. In my setup I have only one cpp file using boost.log, which have a logging function called by other external code ( a bit like the setup I've pushed into cpp-netlib: https://github.com/cpp-netlib/cpp-netlib/tree/master/logging/src ). The main reason was that when you have multiple dlls, you should link them all to one boost.log dll. I compile all boost as static libraries and didn't want to make an exception so I just used boost.log in one only dll which is used by other dlls. As I don't need boost.log in my interfaces, I can do that, but others would be forced to link all dlls to boost.log dlls if they use boost.log in their interfaces OR if they use it in headers. I'm explaining all that so that you understand that I'm not in a common setup, I have only one cpp using boost.log and configuring logging exactly it the way I want. This mean that I have no idea on the compilation performance of boost.log as I compile it only once for all the project. On the run-time performance, yesterday I removed totally the logging code and run the game again. I didn't see a difference. I'm using synced sinks for now, I don't think the asyncs would help (other than delaying the logs in the console). However, I didn't measure anything AND I am too early in the development of this game to have reached any visible bottleneck. Which means that apparently boost.log don't seem to impact my game's performance, but it's too early to be totally sure. I think there will not be more problem than any other logging library on the performance side, and if there is, it's really easy to tweak it. Note that in my context, logs are coming from a lot of different threads and simultaneously, so it don't seem to be a problem for boost.log. Configuring the logging system so that I get exactly what I want is not always easy/obvious, both because there is a lot of options and because of some syntax tricks (boost.parameter usage example) which help once you know them but are obscure when you don't. Obviously, reading most of the documentation clarify things a lot, but I fear that people not taking logging seriously and just wanting a log file out will not read more than a few page. This is, I guess, expected so it's not a real problem. Boost.Log seem to allow all setups I've seen so far in different projects in widely different companies with widely different kind of software which make me wish boost.log was part of the c++ standard. I also wish the syntax to setup the configuration wasn't so verbose, but I don't see any way to reduce it, and it's easy to isolate. Most of the issues I had were in v1 but they were not critical. Some were actually specific to the VC compilers and not specific to boost.log. I switched to V2 recently and seen no change other than the one I pointed in the previous thread (which are not big problems). About the core being a singleton instead of function interface, I think that's the right choice as I've been confronted to the case where terminate() is called and I need to log something before quitting. I don't remember all the details but the problem I had was that there were chances that the boost.log core was deleted at the point I wanted to log before exiting. To solve this, just taking a shared pointer to the core at the being in a system that I guaranteed to be alive until the end solved the problem. I think that's the kind of situation Andrey was talking about to justify the core to be an object instead of a set of functions. I used boost log in some basic test projects and the availability of the trivial logging was really helpful. One thing I'd like to see in the future is to have some helper code to setup multi-process logging. Basically, I think (using asio) a log_client sink and a log_server logger would be helpful. The first one would automatically convert a log_record to something that can be sent (in a cross-platform way) to the network and assume it will be received by an application keeping a log_server object which would receive this log_record, then push it in it's own boost.log core. Users can already do this themselves, but I think if it would be helpful to have such tools in a (certainly not soon) future ready in the library distribution, like the other helper functions provided. As it would involve boost.asio (in my case I use another network library) AND a specific log_record serialization (maybe I prefer a specific binary format), I think providing this solution would be helpful, like most boost.log helpers, but also a basic example to setup more specific or complex setup for multi-process logging. The helper functions helped me sometime understand how some setups were done. But really I don't assume such feature would be provided in the near future, so that's just a suggestion. I didn't check the binary size cost, with this project I don't really care. The current size of the binary using boost.log is 690kb and it include a lot of code. I think I've said it all, I can't wait for boost.log to be finally in a boost release! Joel Lamotte

On Sat, Mar 30, 2013 at 11:53 AM, Andrey Semashev

wrote:

The last issue you reported was a missing Boost.Phoenix include, IIRC. Are there other problems?

No, but as I said I don't think I'm a power user of boost.log yet, not for this project at least. The open source project I will add boost.log to will have a different, maybe more classic, setup which might point other problems, but it will take me at least a month from now to get to work on it. Joel Lamotte

To make a long story short: I'd love to see Boost.Log included into Boost. In fact, I've included it into our in-house distro (Windows only) for the past three or four years. It's used by my colleagues and by myself in a couple of projects (industrial production machines) where it works well without any noticable issues so far - even though we've probably not been pushing it to the limits. Need I say more?

Ciao, Dani

PS: the same applies to Boost.Atomic, too.

fyi, boost.atomic is official part of boost ...

On Thursday 28 March 2013 13:15:10 Charles_J_Wilson@Dell.com wrote:

On Thu, Mar 28, 2013 at 4:46 PM, Vladimir Prus wrote:

...

- Anybody who participated in Boost.Log discussion, or want to use it, or use it, please speak up.

Aside from an odd behavior with thread IDs log is functioning very well for us (log 2.0r854).

[snip]

They are showing up as six (6) digit hex instead of eight (8). Livable.

I'll have a look at it this weekend.

There is one thing that might impact the 'warnings as errors' crowd. There are phoenix warnings generated as a side-effect of using log. Who owns these issues, the library or the consumer? Charles Wilson Senior Software Development Engineer Dell | Enterprise Solutions Group

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev Sent: Monday, April 01, 2013 3:56 PM To: boost@lists.boost.org Subject: Re: [boost] Boost.Log: Any Comments? (Was: [log] Permission to merge to trunk)

On Mon, Apr 1, 2013 at 6:24 PM, wrote:

...

There is one thing that might impact the 'warnings as errors' crowd.

There are phoenix warnings generated as a side-effect of using log.

Who owns these issues, the library or the consumer?

I think, maintainers of each library are free to choose their own policy with regard to warnings. You can contact Boost.Phoenix authors for their opinion on this, or create a Trac ticket (preferably, with a patch).

Personally, I feel reluctant to maintain hard no-warnings guarantee in Boost.Log, simply because it's too tedious and most warnings on higher levels are bogus anyway and trying to avoid them only makes

the

code worse. I try to keep the code silent on normal levels, however.

Can you *suppress warnings* - some suggestions are at https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines Using push'n'pop around troublesome sections usually works, and isn't too tedious to implement. Of course warnings deep in Phoenix may be more difficult to avoid, but you still should be able to. Since there are shops that require use of higher warnings levels, or even warnings as errors, (despite what you might think about their decisions) you may make your reportedly excellent and very widely applicable log library unusable for them. This would be a pity? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines

On Apr 1, 2013, at 1:23 PM, Andrey Semashev wrote:

On Monday 01 April 2013 17:04:40 Paul A. Bristow wrote:

...

Using push'n'pop around troublesome sections usually works, and isn't too tedious to implement.

That's what I do currently, if it is possible to do so with blanket #pragmas. [snip] Also, I want to point out that simply turning warnings off globally in Boost.Log kind of defeats the purpose for turning these warnings on in the first place.

Using push and pop means you're not disabling the warnings globally.

...

Since there are shops that require use of higher warnings levels, or even warnings as errors, (despite what you might think about their decisions) you may make your reportedly excellent and very widely applicable log library unusable for them. This would be a pity?

Sure it would. However, this would be the result of counterproductive management decisions and not of particular flaws of Boost.Log, IMHO. One should fix the root of the problem.

That totally misses the point. Management decisions are often very difficult to alter. Those with such requirements would be unable to use your library, limiting its appeal, if you give up too easily due to that attitude. ___ Rob (Sent from my portable computation engine)

Le 01/04/13 16:24, Charles_J_Wilson@Dell.com a écrit :

There is one thing that might impact the 'warnings as errors' crowd.

There are phoenix warnings generated as a side-effect of using log.

Who owns these issues, the library or the consumer?

If you have a clear understanding on how to fix the warnings, fill a ticket to the library needed the changes. Otherwise fill a ticket for the library associated to the header with the warning and let the maintainer see where the fix must be done. HTH, Vicente

On Tuesday 09 April 2013 18:43:05 Alexander Arhipenko wrote:

This email about feature request. I've requested this "feature" (better to say - existing feature behaviour) several years ago and would like to repeat again.

It would be very nice to have rotation feature work the same way as in e.g. python logging library or Apache web server: * latest file has the name filename.log * previous file has the name filename.log.1 or filename.log.YYYY-MM-DD AFAIK, it's impossible to achieve in current implementation.

Andrey, what do you think about this?

The library does not provide this behavior out of the box. But the file sink uses a file collector object to collect rotated files. This collector can be implemented by the user (it should derive from sinks::file::collector interface) and it should be possible to implement it the way you describe. Would you like to submit such implementation?

On Thursday 28 March 2013 19:46:09 Vladimir Prus wrote:

Andrey,

thanks for asking. I am not sure I am much qualified to decide on my own. I see there was some discussion but it does not seem like many people commented. So how about this:

- Anybody who participated in Boost.Log discussion, or want to use it, or use it, please speak up.

- I will also take a look, w.r.t review results and your list of changes. I am travelling now, so won't be able to do this util start of next week.

- If we don't any objects mid next week, Boost.Log goes (into trunk).

Since noone objected, I've just merged Boost.Log to trunk. Thanks everyone who provided feedback.

On Saturday 13 April 2013 12:06:21 Jason Roehm wrote:

...

Since noone objected, I've just merged Boost.Log to trunk.

I'm not familiar with the details of the release-planning process. Does this mean that Boost.Log is subject for inclusion in 1.54? I'm trying to figure out whether I would need to use the trunk version or if I can wait for the next release.

AFAIK, there's little activity on 1.54 going on right now. So chances are I'll manage to clean up the possible outstanding issues and merge to release branch before it is frozen. If not, it'll be released with 1.55.

On Tue, Apr 16, 2013 at 7:38 AM, Ben Pope wrote:

On 13/04/13 20:34, Andrey Semashev wrote:

...

Since noone objected, I've just merged Boost.Log to trunk. Thanks everyone who provided feedback.

There doesn't seem to be any output on the tests: http://www.boost.org/**development/tests/trunk/**developer/summary.htmlhttp://www.boost.org/development/tests/trunk/developer/summary.html

Hmm, it seems it's not enough to just commit the library into Boost tree. I've also added it to status/Jamfile.v2, let's see if it helps. Also, I suspect there's something needed to be done to enable docs compilation. Does anyone know what needs to be done? Is there any page describing steps that need to be performed when adding a new library to Boost?

On Tue, Apr 16, 2013 at 11:53 AM, Daniel James wrote:

On 16 April 2013 08:26, Andrey Semashev wrote:

...

Also, I suspect there's something needed to be done to enable docs compilation.

If you want it to be part of the combined documentation at $BOOST/doc, you can add it to the jamfiles and boostbook in doc/src yourself. Or if you want built in 'libs/log/doc', I'll need to add it to my build script. Nowadays, I'd keep it in the library directory because it's easier to get images and links working if it's always built in the same place.

I'd prefer to keep the library docs in 'libs/log/doc', if possible. Do I need to do something in this case? I used my own script to build the docs before, and this script left the docs in 'libs/log/doc/html' but it did so by copying some files around. I don't have the script at hand right now, but as I remember the script invoked bjam from Boost root and then moved the built docs from 'doc/html' (I think) to 'libs/log/doc/html'. Is this the way your script works as well? If not, then how does it work so I can test docs compilation locally?

On Tuesday 16 April 2013 10:45:45 Daniel James wrote:

No, I just run b2 in 'libs/logs/doc'.

I tried this in trunk and it doesn't work. The build log ends with this: quickbook.quickbook-to-boostbook ../../../bin.v2/libs/log/doc/gcc-4.7/debug/log_doc.xml Generating Output File: ../../../bin.v2/libs/log/doc/gcc-4.7/debug/log_doc.xml ...skipped log_doc.docbook for lack of log_doc.xml... ...skipped <phtml>log_HTML.manifest for lack of log_doc.docbook... ...skipped 2 targets... ...updated 52 targets... The bin.v2/libs/log/doc/gcc-4.7/debug/log_doc.xml is present. I get similar result if I try to build from Boost root, but the docs build fine in release branch. What could be the problem?

On Tuesday 16 April 2013 12:17:48 Steven Watanabe wrote:

AMDG

On 04/16/2013 11:36 AM, Andrey Semashev wrote:

...

On Tuesday 16 April 2013 10:45:45 Daniel James wrote:

...

No, I just run b2 in 'libs/logs/doc'.

I tried this in trunk and it doesn't work. The build log ends with this:

quickbook.quickbook-to-boostbook ../../../bin.v2/libs/log/doc/gcc-4.7/debug/log_doc.xml Generating Output File: ../../../bin.v2/libs/log/doc/gcc-4.7/debug/log_doc.xml ...skipped log_doc.docbook for lack of log_doc.xml... ...skipped <phtml>log_HTML.manifest for lack of log_doc.docbook... ...skipped 2 targets... ...updated 52 targets...

The bin.v2/libs/log/doc/gcc-4.7/debug/log_doc.xml is present. I get similar result if I try to build from Boost root, but the docs build fine in release branch. What could be the problem?

This looks like a side effect of another bug fix... Are you using trunk b2?

That was it, I was using a prebuilt bjam. With trunk bjam it worked, thanks.

On Tuesday 16 April 2013 22:27:53 Daniel James wrote:

You can see the results at:

http://boost-sandbox.sourceforge.net/libs/log/doc/html/index.html

I've been having problems with sourceforge, so I might move them in the near future.

Thanks a lot! Looks great except there is a missing image in the Design section and no "= delete" and "= default" function markers in the reference. The missing image is likely my fault, it should probably be copied by the Jamfile. I'll see into it this evening. The defaulted and deleted functions require the latest trunk and Doxygen to appear. Do you use an older (than 1.8.2) Doxygen by any chance?

Also, I run inspect (a tool for checking for possible issues), you can see the log results at:

http://boost.cowic.de/rc/docs-inspect-trunk.html#log

Ok, thanks. I'll sort these warnings out in the coming days.

On Saturday 20 April 2013 11:53:08 Vicente J. Botet Escriba wrote:

Le 17/04/13 05:27, Andrey Semashev a écrit :

Hi Andrey,

I'm seen a lot of errors on the regression tests http://www.boost.org/development/tests/trunk/developer/log.html

How is wrong?

The main problem was linking problems because there was some inconsistency in the jamfiles of the library and tests. I've fixed it and most of the tests on gcc and clang went green. The last thing left is that apparently testers don't specify threading environment and by default it's threading=single. One test (util_once_block) is targeted for threading=multi, so it failed. I'll fix it today. I will also make tests to build for threading=multi by default as this configuration is the one I'm interested in most. There is still some problem with MSVC, and the build logs only contain a bunch of "inconsistent dll linkage" warnings and "definition of dllimport function not allowed" errors for Boost.Test. I'm not sure what to make out of it ATM.

On 16/04/13 15:26, Andrey Semashev wrote:

On Tue, Apr 16, 2013 at 7:38 AM, Ben Pope wrote:

...

There doesn't seem to be any output on the tests: http://www.boost.org/**development/tests/trunk/**developer/summary.htmlhttp://www.boost.org/development/tests/trunk/developer/summary.html

Hmm, it seems it's not enough to just commit the library into Boost tree. I've also added it to status/Jamfile.v2, let's see if it helps.

Log is now being built on my test runner, so hopefully it's good to go. Ben