[This is a post separated from the 'Re: [rfc] Gui library' thread.] Hi John.
And if I had to cast my vote for 'the most needed C++ library' it would be a good logging library and not the GUI one... :-) That is the one area where we have not been able to find a 'good enough' solution
He he ;) Please take a look at : http://torjo.com/log2/doc/html/
I'm really interested in your feedback !
Actually we have looked at your library. It looks very promising and we event closely followed its original boost review. It does seem to have what we need (according to the docs and related posts on this list) but for now we chose not to use it only because you seemed to have stopped developing it for a while and no one took over as an active developer. If we were to start using it in our projects, we'd gladly contribute to it but we just did not have the resources to completely take over the development which seemed to be dead. In production code for now we just stick with our own hacked up logging support. Has very few features, does not do most of the things we would like it to, but does the job 'just good enough', holds no surprises and is easy to maintain. Not counting yours, currently the log4cxx library looks the most promising to us. Seems to be most evolved and have a relatively active development. On the other hand, some parts of it are way too filled with bugs (e.g. async logging support) and we were trying to get a handle on those before using it in production code. I really hope you get your library to boost. And we will try to test it out to see we can use it as it is now but I am unsure of the time frame for that as real-life is not leaving us much free time at the moment. :-) Best regards, Jurko Gospodnetić
Hi Jurko,
He he ;) Please take a look at : http://torjo.com/log2/doc/html/
I'm really interested in your feedback !
Actually we have looked at your library. It looks very promising and we event closely followed its original boost review. It does seem to have what we need (according to the docs and related posts on this list) but for now we chose not to use it only because you seemed to have stopped developing it for a while and no one took over as an active developer.
Note that I've developed v2 from scratch, taking into account the feedback from the first version. So this one is waaay more flexible ;) Best, John -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
I have a question. Have you done efficiency tests on this? The reason I ask is the company I work for used log4cxx for our logging, and we found it to be far too slow for high performance apps where microseconds matter. It took up to 70 microseconds to log a message, and a large part of this was log4cxx's reliance on streams and generic formatters. As a consequence, we re-wrote our own logger, with similar concepts to log4cxx (including appenders and formatters), but at about 1/4 the speed impact (about 20 microseconds to log a message on the same test machine). Just by allowing things like a formatter that hard-codes the format instead of trying to interpret the format (eg. timestamp) made a lot of difference. I re-implemented this myself in my own open source project: http://www.neuromancy.net/fisheye/browse/mantra/trunk/Mantra-I/mantra/core/l... But the most important thing here is that it is flexible (you can create your own appenders, formatters, etc and register them with the system and they will act as if they were built in) and FAST. Plus it is configurable with boost::property_tree (which makes it easier for end-users to use). Anyway, my code might be worth a look - but coming back to my initial question have you done speed benchmarks? Or thought about not using streams? Preston On Tue, 23 Oct 2007 12:57:10 +0300, John Torjo wrote:
Hi Jurko,
He he ;) Please take a look at : http://torjo.com/log2/doc/html/
I'm really interested in your feedback !
Actually we have looked at your library. It looks very promising and we event closely followed its original boost review. It does seem to have what we need (according to the docs and related posts on this list) but for now we chose not to use it only because you seemed to have stopped developing it for a while and no one took over as an active developer.
Note that I've developed v2 from scratch, taking into account the feedback from the first version. So this one is waaay more flexible ;)
Best, John
But the most important thing here is that it is flexible (you can create your own appenders, formatters, etc and register them with the system and they will act as if they were built in) and FAST. Plus it is configurable
It certainly is extensible - quite a lot ;)
with boost::property_tree (which makes it easier for end-users to use).
Anyway, my code might be worth a look - but coming back to my initial question have you done speed benchmarks? Or thought about not using streams?
I haven't done speed benchmarks yet, but as a side-note, I want to create a class that will benchmark how long the app spends doing logging. Also, if you turn "compile fast" mode off, you'll avoid one virtual call. About using streams - this is really your call. It's all about gathering your data: http://torjo.com/log2/doc/html/workflow.html http://torjo.com/log2/doc/html/workflow.html#workflow_2a So gathering can happen using streams, or you can choose your own Log Syntax, avoiding streams. Note that logging can also become way faster if you do it on a dedicated thread (on_dedicated_thread.hpp class). I haven't yet tested this, but it's gonna be way faster than doing logging on the thread the message is logged. Basically, the only thing that happens in the current thread is gathering the message. Writing it (formatting it and then writing it to the destination(s)) will happen on the other thread. Thus, any destination you might have - can automatically become asynchronous as well ;) ) (note : your appenders = my destinations) I'd be curious to see how my lib benchmarks against what solution your company took ;) Best, John
Preston
On Tue, 23 Oct 2007 12:57:10 +0300, John Torjo wrote:
Hi Jurko,
He he ;) Please take a look at : http://torjo.com/log2/doc/html/
I'm really interested in your feedback !
Actually we have looked at your library. It looks very promising and we event closely followed its original boost review. It does seem to have what we need (according to the docs and related posts on this list) but for now we chose not to use it only because you seemed to have stopped developing it for a while and no one took over as an active developer.
Note that I've developed v2 from scratch, taking into account the feedback from the first version. So this one is waaay more flexible ;)
Best, John
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
On Thu, 01 Nov 2007 11:52:40 +0200, John Torjo wrote:
But the most important thing here is that it is flexible (you can create your own appenders, formatters, etc and register them with the system and they will act as if they were built in) and FAST. Plus it is configurable
It certainly is extensible - quite a lot ;)
I see that :)
Anyway, my code might be worth a look - but coming back to my initial question have you done speed benchmarks? Or thought about not using streams?
I haven't done speed benchmarks yet, but as a side-note, I want to create a class that will benchmark how long the app spends doing logging. Also, if you turn "compile fast" mode off, you'll avoid one virtual call.
About using streams - this is really your call. It's all about gathering your data: http://torjo.com/log2/doc/html/workflow.html http://torjo.com/log2/doc/html/workflow.html#workflow_2a
So gathering can happen using streams, or you can choose your own Log Syntax, avoiding streams. OK, but the default file appender is not using iostreams?
Note that logging can also become way faster if you do it on a dedicated thread (on_dedicated_thread.hpp class). I haven't yet tested this, but it's gonna be way faster than doing logging on the thread the message is logged. Basically, the only thing that happens in the current thread is gathering the message. Writing it (formatting it and then writing it to the destination(s)) will happen on the other thread. Thus, any destination you might have - can automatically become asynchronous as well ;) ) Yah, log4cxx and my logger also support async logging. But this is not possible where I work (large financial). If use async logging, you have a queue between your app thread and the logging thread. If your app crashes, anything in that queue is lost. This is hell on wheels for debugging. Plus some important information is lost ("Oops! We don't know which of the $30 million in trades were sent to the market and which weren't!"). So while I know Async logging is faster, it is not practical in any important application.
(note : your appenders = my destinations)
I'd be curious to see how my lib benchmarks against what solution your company took ;) I will see if I can grab your logger and benchmark it against mine - first using generic formatters, then using custom formatters (which increase efficiency dramatically).
PreZ :)
Note that logging can also become way faster if you do it on a dedicated thread (on_dedicated_thread.hpp class). I haven't yet tested this, but it's gonna be way faster than doing logging on the thread the message is logged. Basically, the only thing that happens in the current thread is gathering the message. Writing it (formatting it and then writing it to the destination(s)) will happen on the other thread. Thus, any destination you might have - can automatically become asynchronous as well ;) )
Yah, log4cxx and my logger also support async logging. But this is not possible where I work (large financial). If use async logging, you have a queue between your app thread and the logging thread. If your app crashes, anything in that queue is lost. This is hell on wheels for debugging. Plus some important information is lost ("Oops! We don't know which of the $30 million in trades were sent to the market and which weren't!"). So while I know Async logging is faster, it is not practical in any important application.
He he ;) Good point. Well, you can do something like this: - sync logging into a memory drive (thus, if app crashes, you can still read the drive) - this, in a rather raw form (not much formatting), - and async logging to other destination(s) - files, http, mail, whatever; with all the pretty formatting you wish
(note : your appenders = my destinations)
I'd be curious to see how my lib benchmarks against what solution your company took ;)
I will see if I can grab your logger and benchmark it against mine - first using generic formatters, then using custom formatters (which increase efficiency dramatically).
Coolio ;) Best, John
PreZ :)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
I re-implemented this myself in my own open source project: http://www.neuromancy.net/fisheye/browse/mantra/trunk/Mantra-I/mantra/core/l...
After looking at this for a bit, I believe my solution should be at least 50% faster :P Of course, you'd have to test it to see that's true.. Best, John -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
Hi John,
And if I had to cast my vote for 'the most needed C++ library' it would be a good logging library and not the GUI one... :-) That is the one area where we have not been able to find a 'good enough' solution
He he ;) Please take a look at : http://torjo.com/log2/doc/html/
I'm really interested in your feedback !
not sure whether you are also interested in my feedback as you ignored already two mails from me with simple patches. Nevertheless I attached my mail again ... Jens
Hi Jens,
not sure whether you are also interested in my feedback as you ignored already two mails from me with simple patches. Nevertheless I attached my mail again ...
Sorry 'bout that - it's not my fault - though I should have replied to the mailing list. The idea is I definitely took your comments into account - and you'll see that if you take a look at the latest sources. Here's the problem (when I replied to your email): This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: jensseidel@users.sf.net SMTP error from remote mail server after RCPT TO:<jensseidel@users.sf.net>: host mail.sourceforge.net [66.35.250.206]: 550-Postmaster verification failed while checking <john.code@torjo.com> 550-Called: 72.52.140.12 550-Sent: RCPT TO:<postmaster@torjo.com> 550-Response: 550 No such email address 550-Several RFCs state that you are required to have a postmaster 550-mailbox for each mail domain. This host does not accept mail 550-from domains whose servers reject the postmaster address. 550 Sender verify failed Here's the original message: Return-path: <john.code@torjo.com> Received: from [89.40.140.91] (port=2249) by europe.hosted4ever.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from <john.code@torjo.com>) id 1IiOav-00047P-Gd; Thu, 18 Oct 2007 09:11:00 +0300 Message-ID: <4716F8E9.3050504@torjo.com> Date: Thu, 18 Oct 2007 09:10:49 +0300 From: John Torjo <john.code@torjo.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jens Seidel <jensseidel@users.sf.net> Subject: Re: Comments to Boost.Log2 References: <20071017113038.GA31530@imkf-pc073.imkf.tu-freiberg.de> In-Reply-To: <20071017113038.GA31530@imkf-pc073.imkf.tu-freiberg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Jens,
Hi John,
I was very surprised to read today on your homepage that you continue
Thanks ;) It's been a crazy time for me, but I'm finally coping :)
working on Boost.log. Great! I suggest you announce it on the boost-user list.
Good point . First, I need to subscribe to it :)
On this list I recently posted a few comments for you, as I failed in the past to contact you (and considered the project death). See http://lists.boost.org/boost-users/2007/09/30970.php
I've seen them now - you're right about the levels stuff - I've corrected it in v2. I'm not maintaining v1 since v2 is sooooo much better!
OK, a few further comments to your new version 2: * The zip archive contains object files. Please remove these.
Sorry 'bout that - I think I've removed them already. Anyway, could you give me the file names, just to make sure I don't miss them in the future?
* Are you aware that the licenses of e.g. lib/logging/tests/template.cpp and boost/logging/defaults.hpp are different? Is this wanted?
* Some code contains: "See accompanying file LICENSE_1_0.txt". I miss this file in your archive.
done
* "generating the docs.txt" Please avoid using spaces in names. You are probably aware that a few filesystems are not able to store such files (e.g. ISO 9660 without Rock Ridge or Joliet extensions). It makes writing shell scripts also harder as a space is a word separator in most shells (e.g. bash) (for file in *; do ...).
done
* I attached a patch which allows your test code to be compiled by fixing errors and warnings. A single warning remains which I marked in the code in a comment.
Yup, thanks - fixed it.
I added a Makefile to simplify the task of compiling. Read it to see the compiler flags I used. Used compiler: $ /usr/lib/gcc-snapshot/bin/g++ --version g++ (Debian 20070916-1) 4.3.0 20070916 (experimental) [trunk revision 128522]
Thanks for the makefile - unfortunately I can't use it because boost uses jam - so I need to somehow make a jamfile to build the tests :) Note: the modifications are in SVN: http://svn.boost.org/svn/boost/sandbox/logging/ (I update the .zip file only once in a while - like, every 2 weeks or so :) ) Best, John And more info : http://torjo.blogspot.com/2007/10/email-hell.html Best, John -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
Hi John, On Tue, Oct 23, 2007 at 02:41:40PM +0300, John Torjo wrote:
Hi Jens,
not sure whether you are also interested in my feedback as you ignored already two mails from me with simple patches. Nevertheless I attached my mail again ...
Sorry 'bout that
ah, great to see you replying so fast ...
- it's not my fault
It is!
- though I should have replied to the mailing list.
The idea is I definitely took your comments into account - and you'll see that if you take a look at the latest sources.
Great, thanks!
Here's the problem (when I replied to your email):
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:
jensseidel@users.sf.net SMTP error from remote mail server after RCPT TO:<jensseidel@users.sf.net>: host mail.sourceforge.net [66.35.250.206]: 550-Postmaster verification failed while checking <john.code@torjo.com> 550-Called: 72.52.140.12 550-Sent: RCPT TO:<postmaster@torjo.com> 550-Response: 550 No such email address 550-Several RFCs state that you are required to have a postmaster 550-mailbox for each mail domain. This host does not accept mail 550-from domains whose servers reject the postmaster address.
550 Sender verify failed
Yep, that's a SPAM protection performed by SourceForge. I know about approximately one mail per year failing because of this, maybe there are many more rejected mails. Please create a postmaster mail account on your system! This will fix the problem on your side (just adding "postmaster: root" to /etc/aliases should be sufficient?).
Here's the original message:
On this list I recently posted a few comments for you, as I failed in the past to contact you (and considered the project death). See http://lists.boost.org/boost-users/2007/09/30970.php
I've seen them now - you're right about the levels stuff - I've corrected it in v2. I'm not maintaining v1 since v2 is sooooo much better!
Is v2 already stable enought for daily use?
OK, a few further comments to your new version 2: * The zip archive contains object files. Please remove these.
Sorry 'bout that - I think I've removed them already. Anyway, could you give me the file names, just to make sure I don't miss them in the future?
In lib/logging/tests/: test_multiple_simple_logs.o test_mul_lev_difflogs.o test_mul_lev_samelog.o test_ostream_like.o test_simple_dump_to_cout.o In lib/logging/tests/format/: test_format_write_ts.o test_manip_being_func.o test_manip_w_msgroute.o test_simple_formatter.o The latest zip archive still contains these files (just search for *.o).
* I attached a patch which allows your test code to be compiled by fixing errors and warnings. A single warning remains which I marked in the code in a comment.
Yup, thanks - fixed it.
Will check later whether you was able to remove the last warning :-)
I added a Makefile to simplify the task of compiling. Read it to see the compiler flags I used. Used compiler: $ /usr/lib/gcc-snapshot/bin/g++ --version g++ (Debian 20070916-1) 4.3.0 20070916 (experimental) [trunk revision 128522]
Thanks for the makefile - unfortunately I can't use it because boost uses jam - so I need to somehow make a jamfile to build the tests :)
Don't worry. It was just for me and I shared it with you to avoid putting the compiler flags into the mail. I prefer Makefiles over jam and will continue using these if possible for simplicity ...
(I update the .zip file only once in a while - like, every 2 weeks or so :) )
OK. I agree that this is sufficient. Jens
Please create a postmaster mail account on your system! This will fix the problem on your side (just adding "postmaster: root" to /etc/aliases should be sufficient?).
Not really - I asked my provider to setup a different account altogether. I expect a lot of spam on this address.
Is v2 already stable enought for daily use?
Should be within 2-3 weeks. I need to make it compile faster, and add TLS.
In lib/logging/tests/: test_multiple_simple_logs.o test_mul_lev_difflogs.o test_mul_lev_samelog.o test_ostream_like.o test_simple_dump_to_cout.o In lib/logging/tests/format/: test_format_write_ts.o test_manip_being_func.o test_manip_w_msgroute.o test_simple_formatter.o
The latest zip archive still contains these files (just search for *.o).
Are you sure you have the latest version. I just checked it on the net - and the latest version does not contain the .o files anymore. It's 112K in size
Will check later whether you was able to remove the last warning :-)
I removed the init_both altogether. Best, John -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
participants (4)
-
Jens Seidel -
John Torjo -
Jurko Gospodnetić -
Preston A. Elder