Boosters, the formal review of the Boost.Log library, written by Andrey Semashev, will start in a week from now, on March 8, 2010 and will run through March 17, 2010. The documentation for the current version is available at: http://boost-log.sourceforge.net The downloads at at: http://sourceforge.net/projects/boost-log Because the library is relatively big and important, you might want to take a look in advance, without waiting for the formal review. Please note that reports of real-world usage will be particularly appreciated -- even if you don't have the time to to do everything formal review checklist requires please still report your experiences. To clarify timelines, the formal reviews are accepted from 23:59, March 7, PST = 2:59, March 8, EST = 7:59 March 8, GMT = 10:59, March 8 MSK until 23:59, March 17, PST = 2:59, March 18, EST = 7:59 March 18, GMT = 10:59, March 18 MSK Reviews submitted outside of this frame are not guaranteed to be processed. Thanks, Volodya
Vladimir Prus skrev:
Boosters,
the formal review of the Boost.Log library, written by Andrey Semashev, will start in a week from now, on March 8, 2010 and will run through March 17, 2010.
The documentation for the current version is available at:
Hi Andrey, I looked at the documentation, and couldn't find any comparison with other libraries besides a small log4j comparison. Therefore I wonder if such a comparison has been made, and if so, how it guided the design decisions. In particular, I would like to see a quite detailed comparison with Pantheios: http://www.pantheios.org/ It would also be good if you could use this library as one to benchmark against. I would also like to know how your library differs from the one that was rejected by John Torjo, and how your library adresses the issue that was found with that library? Thanks for your work so far -Thorsten
Vladimir Prus wrote:
Boosters,
the formal review of the Boost.Log library, written by Andrey Semashev, will start in a week from now, on March 8, 2010 and will run through March 17, 2010.
The documentation for the current version is available at:
http://boost-log.sourceforge.net
The downloads at at:
http://sourceforge.net/projects/boost-log
Because the library is relatively big and important, you might want to take a look in advance, without waiting for the formal review. Please note that reports of real-world usage will be particularly appreciated -- even if you don't have the time to to do everything formal review checklist requires please still report your experiences.
To clarify timelines, the formal reviews are accepted from
23:59, March 7, PST = 2:59, March 8, EST = 7:59 March 8, GMT = 10:59, March 8 MSK
until
23:59, March 17, PST = 2:59, March 18, EST = 7:59 March 18, GMT = 10:59, March 18 MSK
Reviews submitted outside of this frame are not guaranteed to be processed.
Whatever happened to the other logging library earlier submitted by John Torjo ? Has it just been rejected completely or what ?
Edward Diener wrote:
Vladimir Prus wrote:
Boosters,
the formal review of the Boost.Log library, written by Andrey Semashev, will start in a week from now, on March 8, 2010 and will run through March 17, 2010.
Whatever happened to the other logging library earlier submitted by John Torjo ? Has it just been rejected completely or what ?
It has been rejected. Then, it was submitted again, and is in the review queue, but without a date or review manager. I don't know more than that. - Volodya
Vladimir Prus wrote:
Edward Diener wrote:
Vladimir Prus wrote:
Boosters,
the formal review of the Boost.Log library, written by Andrey Semashev, will start in a week from now, on March 8, 2010 and will run through March 17, 2010.
Whatever happened to the other logging library earlier submitted by John Torjo ? Has it just been rejected completely or what ?
It has been rejected. Then, it was submitted again, and is in the review queue, but without a date or review manager. I don't know more than that.
I think it would be very helpful if both logging libraries were reviewed at the same time.
On Mar 1, 2010, at 2:58 PM, Edward Diener
Vladimir Prus wrote:
Edward Diener wrote:
Vladimir Prus wrote:
Boosters,
the formal review of the Boost.Log library, written by Andrey Semashev, will start in a week from now, on March 8, 2010 and will run through March 17, 2010.
Whatever happened to the other logging library earlier submitted by John Torjo ? Has it just been rejected completely or what ? It has been rejected. Then, it was submitted again, and is in the review queue, but without a date or review manager. I don't know more than that.
I think it would be very helpful if both logging libraries were reviewed at the same time.
AFAIK the author is not around anymore and no work has been done on the library in a long time, but i could be wrong. Zach
Edward Diener wrote:
Vladimir Prus wrote:
Edward Diener wrote:
Vladimir Prus wrote:
Boosters,
the formal review of the Boost.Log library, written by Andrey Semashev, will start in a week from now, on March 8, 2010 and will run through March 17, 2010.
Whatever happened to the other logging library earlier submitted by John Torjo ? Has it just been rejected completely or what ?
It has been rejected. Then, it was submitted again, and is in the review queue, but without a date or review manager. I don't know more than that.
I think it would be very helpful if both logging libraries were reviewed at the same time.
Maybe. Unfortunately, it seems unlikely that in the week that remains you will be able to revive the discussion about simultaneous reviews that we had some time ago, lead it to a resolution, find a review manager for John's logging library, and arrange a time slot. And it's even less likely that this timeslot will be Marth 8 - March 17. - Volodya
Vladimir Prus wrote:
Boosters,
the formal review of the Boost.Log library, written by Andrey Semashev, will start in a week from now, on March 8, 2010 and will run through March 17, 2010.
The documentation for the current version is available at:
http://boost-log.sourceforge.net
The downloads at at:
Andrey, most of what I see looks very nice to me. What I'd like to know is: Isn't there a way to get rid of the MACROS? Personally I'd like to see the code the compiler sees. For instance, instead of BOOST_LOG_SEV(slg, normal) << "A regular message"; I'd like to use something like slg.log(normal) << "A regular message"; Or maybe even shorter: slg(normal) << "A regular message"; Regards, Roland
Roland Bock wrote:
For instance, instead of
BOOST_LOG_SEV(slg, normal) << "A regular message";
I'd like to use something like
slg.log(normal) << "A regular message";
Pretty sure that's done for performance, so that if the thing being logged is a complex expression, but yet could be trivially filtered, it is not evaluated.
I just took a look at the documentation, and I must say this looks great, I am looking forward to testing it out. A few things I noticed in the docs:
From the macro documentation page, it is unclear as to whether the build system will make any attempt to detect the platform you are on and enable BOOST_LOG_USE_WINNT6_API if you are on a Vista+ machine. I am guessing not, but that could be made clearer.
You solved a problem that I saw with previous versions of logging libraries here- you made the simple case of just putting severity levels on a message and putting it somewhere easy, without a lot of set up required. However, I feel a better name for the macros would be BOOST_LOG_SIMPLE, not BOOST_LOG_TRIVIAL. Its shorter, which is always nice, especially considering intellisense tends not to deal with macros so well in my experience, and I guess I have a bit of PTSD from being in university and often having professors gloss over details in lectures because they are supposed to be trivial, and they... were not. Whether I am being overly picky/quirky or not, you can decide. The biggest thing missing from the page is performance comparisons with other libraries, notably log4j/log4cxx, and throughput numbers with various features enabled. For my project, this is pretty much a dealbreaker that would prevent me from using the library, at least not before doing lots of tedious testing (which considering I am already using log4cxx and it works, I would not waste time doing). Performance is tremendously important for our applications, and excessive logging is too often a cause of performance problems, as well as getting too fancy with certain features (log4cxx takes a large hit to performance if you include the class name in the logging output, which IIRC is due to RTTI being used), if there are similar gotchas here, they should be noted. -Kevin -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Eric J. Holtman Sent: Monday, March 01, 2010 8:38 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Boost.Log formal review upcoming Roland Bock wrote:
For instance, instead of
BOOST_LOG_SEV(slg, normal) << "A regular message";
I'd like to use something like
slg.log(normal) << "A regular message";
Pretty sure that's done for performance, so that if the thing being logged is a complex expression, but yet could be trivially filtered, it is not evaluated. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. _______________________________________________
Eric J. Holtman wrote:
Roland Bock wrote:
For instance, instead of
BOOST_LOG_SEV(slg, normal) << "A regular message";
I'd like to use something like
slg.log(normal) << "A regular message";
Pretty sure that's done for performance, so that if the thing being logged is a complex expression, but yet could be trivially filtered, it is not evaluated.
Oh, you mean if I use some #define MINIMUM_LOG_LEVEL 3 then some of these lines are not evaluated? If the respective parts were header only, I wonder if the same could not be done without the MACROS (but with compiler optimization). Regards, Roland
Roland Bock wrote:
If the respective parts were header only, I wonder if the same could not be done without the MACROS (but with compiler optimization).
No. If you have a line like log (level) << Some_Expression (); there's no compiler optimization (well, probably no optimization) that can prevent Some_Expression() from being evaluated. But the macro expands to something along the lines of if (log.is_filtered (level)) {} else log.streamer () so if the line can get trivially filtered, Some_Expression (in the else clause) never gets evaluated. Assuming the filtering is fast enough, this allows you to leave TRACE level logging in a production build, and only turn it on when you really want it.
Eric J. Holtman wrote:
Roland Bock wrote:
If the respective parts were header only, I wonder if the same could not be done without the MACROS (but with compiler optimization).
No. If you have a line like
log (level) << Some_Expression ();
there's no compiler optimization (well, probably no optimization) that can prevent Some_Expression() from being evaluated.
But the macro expands to something along the lines of
if (log.is_filtered (level)) {} else log.streamer ()
OK, got it. Thanks for the explanation :-) Regards, Roland
participants (7)
-
Edward Diener -
Eric J. Holtman -
Kevin.Stevens＠barclayscapital.com -
Roland Bock -
Thorsten Ottosen -
Vladimir Prus -
Zachary Turner