-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Ronald Garcia Sent: Wednesday, July 13, 2011 11:02 AM To: boost@lists.boost.org Subject: Re: [boost] logging

...

Hello,

Does anyone know when we can expect a blessed logging facility to make it into an official release of boost?

There seem to be 2 logging candidates: 1) one by Andrey Semashev (provisionally accepted 16 months ago in March 2010).

2)one by John Torjo that seems to have finished development 3 years ago at version 0.22.7 in Feb 2008. On John's blog it says it was up for review then. Then a post in May 2008 at

http://boost.2283326.n4.nabble.com/what-s-up-with-the-logging-libraries-

...

td2579613.html seems to indicate there will be another version with "quite a rewrite" and implying that may be the version to be reviewed.

Following the provisional acceptance of Andrey's library, John ceased development of his proposed library.

Did not know that.

Ron

So after 16 months and 2 releases, what is the plan?

...

Can someone give any update on either logger, and if there is any

plan

...

for getting them into boost?

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Gordon Woodhull Sent: Thursday, July 14, 2011 8:44 AM To: boost@lists.boost.org Subject: Re: [boost] logging

...

So after 16 months and 2 releases, what is the plan?

So, do you have another logging library to propose to Boost?

That is a joke I am certain. And since better people than me have written and stopped working on a boost logging library due to the simple fact that one has ALREADY BEEN ACCEPTED instead, I can laugh at the joke.

Seriously folks, yes it has been a long time, but the conditions on acceptance were pretty strong [1], including pretty much mandating Phoenix v3, which has only just been released. There's a thread from late March which explains all of this [2].

OK. I missed that thread. It is enlightening. It sort of looks like maybe a shadow of a plan: wait for Phoenix V3 to stabilize then refactor because the interface will likely change in significant ways. That is reasonable, though as others have articulated I too would question the wisdom of holding up a very useful library for TWO YEARS because you know that you will need to refactor some of it in the future. This is the larger question.

Speaking as someone who followed this review closely but found that others had already covered every point I could think of, it seems to me that Andrey chose an "everything including the kitchen sink" design (which I like) and it was bound to take a lot of work to bring it up to everyone's expectations. I urge patience.

I think waiting 16 months is a boat load of patience whether it is in doggie or computer years. And of course with this model of contribution there should be little expectation even after a contributor has submitted a library and it has been approved and others have stopped working on similar libraries because of that fact? It would seem the accepted answer to the original question ("When can we expect a blessed logging facility to make it into an official release of boost?") had been "after phoenix v3 is stable". So now that Phoenix V3 is in boost 1.47, Is there hope it will be in 1.48? Is hope a plan?

[1] http://lists.boost.org/boost-announce/2010/03/0256.php [2] http://comments.gmane.org/gmane.comp.lib.boost.devel/217266 _______________________________________________

On Jul 15, 2011, at 3:28 PM, Klaim - Joël Lamotte wrote:

Now am I wrong in thinking that the decision was made to wait because the transition to Phoenix3 would anyway have cost too much for the library developer(s) if not prepared "early"?

Sounds like it will change the external interface significantly for all the lamdbda-ish customization points, so it's better to standardize right away.

...

...

...

So after 16 months and 2 releases, what is the plan? So, do you have another logging library to propose to Boost?

That is a joke I am certain. And since better people than me have written and stopped working on a boost logging library due to the simple fact that one has ALREADY BEEN ACCEPTED instead, I can laugh at the joke.

A joke, but the point being, if you aren't putting in the effort yourself, what right do you really have to complain about other volunteers' efforts?

There is nothing stopping someone else from submitting their own

has died. Or even if it hasn't. (Sounds like a lot of people would

No right whatsoever... true enough. But others have put in effort (reviewers, early adapters). I am (just lightly) complaining because at some point (library acceptance?) is there not a duty to carry through (even if it simply means killing it to make way for something else or getting others involved to help)? I suppose the answer to that question is no. library if it really seems this one prefer a more lightweight

solution.)

Agreed. I recall some discussion about the fact that it would be ok if several loggers were in the library if each offered some distinctive value.

I hope that Andrey speaks up and lets us know how his library is coming along.

Me too. Many smart people spent time to review and voted to accept it, and the lib is certainly in use anyway. And logging is a big hole in the core boost functionality, exaggerated somewhat given some of the more recent and esoteric library additions. Andrey, I apologize for complaining but again, as I stated originally, I am simply interested in knowing if there is a plan and perhaps a target boost version.

There isn't any way to make him work on it. And I don't think deadlines make sense in a volunteer organization. So all we can do is enthusiastically plead with him to get it released and then keep it maintained, or to find other volunteers who can help.

Completely agree.

I'm having a few thoughts on a "simple" logging library - so for what it's worth: I think that it would be useful if a logging library relied on a minimum of c++ features that is not likely to "break" between platforms and compiler implementations, as one of the more valuable "features" would be the ability to log when things doesn't work as expected. While I really like libraries like log4j/Log4Net - I've also used ACE extensively, and I've been quite satisfied with the logging facilities provided by ACE. One way of using ACE_Log_Message enables me to log directly to a local logging service, which forwards log records to another service running on a central host for further processing - this ability is fairly high on my "requirement" list. Tracking problems with a distributed solution, is simplified when logging is dealt with centrally, and buffered locally. For a single process, logging is configured on a global or per thread basis, something that makes more sense in many situations then the approach followed by log4j and sibling implementations/work-a-likes. AFAIK ACE does not implement the following "feature" ( but it has a buffering mechanism, and extensibility hooks, that makes it relatively straight forward to simulate): Sometimes it's also useful if the logger follows the processing chain - like in a multithreaded application where a task may be handed from thread to thread in a processing pipeline. The log4j model does not lend itself to this kind of logging - the purpose would be to group output in the log, instead of interleaving output from parallel tasks/threads. This tends to make the log more readable. I'd also like to implement the "log record" as a continuous block of memory as in <fixed size header><variable length part> where the layout is binary compatible between platforms and compilers. Something along the lines of: enum message_data_type_t { message_data_type_unknown, message_data_type_message, message_data_type_host_name, message_data_type_process_name, message_data_type_user_name }; struct message_data_t { uint16_t size; uint16_t type; // a base set given by message_data_type_t, other values are user defined // Not necessarily byte oriented, just to indicate that data // for the message starts at this point. Encoding indicated by // log_record_t.encoding uint8_t data[0]; }; struct log_record_t { uint8_t byte_order; // If set - big-endian, else little-endian /* maybe uint8_t reserved, or something, to allow for word alignment? */ uint64_t time_stamp; // in number of milliseconds since 1/1/1970 ? uint32_t log_record_type; // probably something similar to ACE_Log_Priority uint32_t message_area_size; // Total size of the variable message area in bytes uint16_t encoding; // codepage for encoding/decoding messages uint16_t message_count; // Number of messages // the variable area starts here message_data_t message_data; }; This would at least allow for a set of reusable services to be implemented, facilitating routing of log records. Each thread will have a logger A thread may share it's logger with other threads The main thread creates the "root" logger. A spawned thread may be assigned an existing logger, or it creates its own logger, as a child of the logger for the spawning thread - ideally this would require a small change to the "thread" library, to ensure that the logger was the last object cleaned up on thread exit, and a way to pass information about the logger for the spawning thread. The logger for a thread is accessible through a static method, backed by thread local storage, like: boost::logging::logger::instance()->log(uint32_t log_record_type, char* fmt,...); boost::logging::logger::instance()->log(char* fmt, uint32_t log_record_type, va_list args); and boost::logging::logger::instance()->log(uint32_t log_record_type, wchar_t* fmt,...); boost::logging::logger::instance()->log(wchar_t * fmt, uint32_t log_record_type, va_list args); The above would add a message_data_type_message entry to the variable area - other entries could be added through an extensible interceptor like chain I'm sure I'd be able to implement it in a way that would provide for reuse by more "advanced" log processors based on features from many of the other libraries. Well, it's just a few thoughts based on a solution that I've found quite useful. Best regards Espen Harlinn Mobile:+47 92 60 11 90 mailto:espen@harlinn.no

On 16/07/11 17:18, Andrey Semashev wrote:

On 07/15/2011 11:46 PM, Gordon Woodhull wrote:

...

I hope that Andrey speaks up and lets us know how his library is coming along.

Well, it's not going as fast as I'd prefer. Due to various matters I have little time to work on v2 lately but I'm still eager to bring this library to Boost. Right now I'm refactoring sink frontends to move record formatting to the sink frontend level. Also, the async frontend will use a new lock-free queue, which should improve performance. There are a few design decisions to make and quite some time to experiment with the new code, that's why it's taking so long.

Your efforts are appreciated. I think the reason for much of the interest is that many of us are actually using your library 'as-is' today. For those that are, we're going to have to refactor once a new version is available. In that regard we'll have to deal with breaking changes anyway.

Also there is much to do left, including the mentioned port to Phoenix v3. I didn't look into it yet, so I can't estimate how long it will take. Taking the chance, I wouldn't mind if someone wants to provide patches in this area.

Not sure if this was mentioned or not, but do you have a public repo with your latest code so interested early adopters can help contribute patches against the that?

There are other things planned, some of which were mentioned during the review (trivial logging issues, channel name changing, etc.), some were identified by users (problems with initialization from settings, boundless record queue in async sink). And of course, docs need updating (although this is partially done).

It sounds like it might be worth getting the library to a 'stable enough' state for an addition to boost and simply make it clear in the docs that certain interfaces might be deprecated in a later revision? Like I said many are using it now and the wider exposure might prompt more volunteer help.

Sorry, I know it takes too long, the review took place more than a year ago. I hope I can do better in the coming days.

Good luck! I had quite a few reservations during the review as I recall but I am using your library because I do think it is a good library and as I said all the work you've put into it is very much appreciated. I'm looking forward to seeing some of the improvements you've made.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hello, I've been lurking about and following the logging discussions off and on. I'm saddened to see it hasn't made it into 1.47 which means I must get a compatible patch from svn and compile it into my packages (on opensuse build service) and cannot rely on distro maintainers boost packages. Andrey, if you're reading this, consider getting it in if only to end the limbo of logging in the cross-platform c++ environment and improving things from there. Boost.Log is plenty fast (at least for my work which is composed of threads and soft-RT stuff for which async logging helps with latencies) and I trust it more than other libraries. From the examples I was also able to make it pretty easy to use in my code environment. As a user I'd say it's ready to use and it would be hard to find a better library. Best, Jason On Wed, Jul 13, 2011 at 9:01 AM, Ronald Garcia <rxg@cs.cmu.edu> wrote:

On Jul 13, 2011, at 10:15 AM, Jeff Graham wrote:

...

Hello,

Does anyone know when we can expect a blessed logging facility to make it into an official release of boost?

There seem to be 2 logging candidates: 1) one by Andrey Semashev (provisionally accepted 16 months ago in March 2010).

2)one by John Torjo that seems to have finished development 3 years ago at version 0.22.7 in Feb 2008. On John's blog it says it was up for review then. Then a post in May 2008 at http://boost.2283326.n4.nabble.com/what-s-up-with-the-logging-libraries- td2579613.html seems to indicate there will be another version with "quite a rewrite" and implying that may be the version to be reviewed.

Following the provisional acceptance of Andrey's library, John ceased development of his proposed library.

Ron

...

Can someone give any update on either logger, and if there is any plan for getting them into boost?

Thanks _______________________________________________ Unsubscribe & other changes:

http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost