www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Using glog's design for Phobos?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Hello,


At my workplace we're using Google's logging library glog 
(http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the 
more I use it, the more I like it. It's simple, to the point, and effective.

I was thinking it would be great to adapt a similar design into Phobos. 
There will be differences such as use of regular argument lists instead 
of << etc., but the spirit will be similar. What do you think?


Andrei
Aug 25 2010
next sibling parent reply Kagamin <spam here.lot> writes:
Andrei Alexandrescu Wrote:

 of << etc., but the spirit will be similar. What do you think?

What bugs me most in log4net - it doesn't delete old logs that can take up to gigabytes.
Aug 25 2010
parent reply simendsjo <simen.endsjo pandavre.com> writes:
Kagamin wrote:
 Andrei Alexandrescu Wrote:
 
 of << etc., but the spirit will be similar. What do you think?

What bugs me most in log4net - it doesn't delete old logs that can take up to gigabytes.

Tried RollingFileAppender?
Aug 26 2010
parent Kagamin <spam here.lot> writes:
simendsjo Wrote:

 Tried RollingFileAppender?

Ah, indeed... as I think of it... looks like I misconfigured it with the date pattern. x_x Thanks.
Aug 26 2010
prev sibling next sibling parent reply "Masahiro Nakagawa" <repeatedly gmail.com> writes:
On Thu, 26 Aug 2010 12:59:19 +0900, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Hello,
   At my workplace we're using Google's logging library glog  
 (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the  
 more I use it, the more I like it. It's simple, to the point, and  
 effective.
  I was thinking it would be great to adapt a similar design into Phobos.  
 There will be differences such as use of regular argument lists instead  
 of << etc., but the spirit will be similar. What do you think?

I am using glog and gtest in my project. These tools are very useful :) I think we need useful and handy logging module for Phobos. Yeah, glog is one of the candidates. Masahiro
Aug 26 2010
parent reply sybrandy <sybrandy gmail.com> writes:
 I am using glog and gtest in my project. These tools are very useful :)
 I think we need useful and handy logging module for Phobos.
 
 Yeah, glog is one of the candidates.
 
 
 Masahiro

Yeah, I started one that I at least plan on using. I've even offered to let Walter and the gang include it in Phobos if they like it enough. Not sure it's 100% yet, but it seems to work pretty well. As soon as I can, I'll upload my updates so people can see it here again. Casey
Aug 26 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/26/10 14:48 PDT, sybrandy wrote:
 I am using glog and gtest in my project. These tools are very useful :)
 I think we need useful and handy logging module for Phobos.

 Yeah, glog is one of the candidates.


 Masahiro

Yeah, I started one that I at least plan on using. I've even offered to let Walter and the gang include it in Phobos if they like it enough. Not sure it's 100% yet, but it seems to work pretty well. As soon as I can, I'll upload my updates so people can see it here again. Casey

Very interesting. Please do share here a link when you are done. Thanks, Andrei
Aug 26 2010
parent reply sybrandy <sybrandy gmail.com> writes:
 Very interesting. Please do share here a link when you are done.
 
 Thanks,
 
 Andrei

Thanks! Hopefully it'll be relatively soon. I just have to figure out everything I need to do to get ssh and public keys working properly under Linux. Worst case scenario, I'll post it directly to the newsgroup...it's only one file. Casey
Aug 27 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/27/10 16:23 PDT, sybrandy wrote:
 Very interesting. Please do share here a link when you are done.

 Thanks,

 Andrei

Thanks! Hopefully it'll be relatively soon. I just have to figure out everything I need to do to get ssh and public keys working properly under Linux. Worst case scenario, I'll post it directly to the newsgroup...it's only one file.

Don't forget: 7 symbols, then one toe goes off for every extra. Andrei
Aug 27 2010
parent reply sybrandy <sybrandy gmail.com> writes:
 Don't forget: 7 symbols, then one toe goes off for every extra.
 
 Andrei
 

IIRC, I have two constructors and the following: fatal, error, warning, debug, info, and trace. Since the discussion is going quite nicely, I'll try to get a copy of the file up here tonight. Casey
Aug 27 2010
parent reply sybrandy <sybrandy gmail.com> writes:
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Here's my current version of the logger.  All of the documentation
should be in the logger.d file.  I also provided a sample config file
(logger.conf) and a sample test file that I was using for benchmarking
(main.d).  Let me know if you have any questions.  Feedback on improving
this is also welcome.

The one thing I forgot to note in here is that the function that writes
to the log is passed into the second version of the constructor, which
needs to be used only once in the code.  A simple log writer is included
at the bottom of logger.d that does work.  The reason I did this was
when I initially asked for feedback, I got several ideas on how the
logger can be improved.  Also, I discussed this with a friend of mine
who stated that people may want to log to something other than a file,
such as syslog.  So, instead of trying to make the one "end all be all"
logger, I felt that by allowing it to accept a function as a parameter
to the constructor, the person can write to any type of log file,
database, whatever they want and the logger interface works the same no
matter what.

There currently is a bug somewhere that I don't understand.  Even though
I have "OwnerTerminated" as part of my receive statement, I still see
exceptions when the program closes.  However, it doesn't seem to affect
the execution of the logger.

Enjoy.

Casey
Aug 27 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/27/10 18:18 PDT, sybrandy wrote:
 Here's my current version of the logger.  All of the documentation
 should be in the logger.d file.  I also provided a sample config file
 (logger.conf) and a sample test file that I was using for benchmarking
 (main.d).  Let me know if you have any questions.  Feedback on improving
 this is also welcome.
 
 The one thing I forgot to note in here is that the function that writes
 to the log is passed into the second version of the constructor, which
 needs to be used only once in the code.  A simple log writer is included
 at the bottom of logger.d that does work.  The reason I did this was
 when I initially asked for feedback, I got several ideas on how the
 logger can be improved.  Also, I discussed this with a friend of mine
 who stated that people may want to log to something other than a file,
 such as syslog.  So, instead of trying to make the one "end all be all"
 logger, I felt that by allowing it to accept a function as a parameter
 to the constructor, the person can write to any type of log file,
 database, whatever they want and the logger interface works the same no
 matter what.
 
 There currently is a bug somewhere that I don't understand.  Even though
 I have "OwnerTerminated" as part of my receive statement, I still see
 exceptions when the program closes.  However, it doesn't seem to affect
 the execution of the logger.
 
 Enjoy.
 
 Casey

Thanks. I think we should establish a tradition for reviews on this forum. The Boost review model has functioned very well, in the sense that it has consistently produced two outcomes: excellent libraries and pulp-beaten library authors. So I'd opt if at all possible for a tough review process that produces good libraries as opposed to a nicey-nicey process that fosters a low barrier of entry. As I guess you suspected already, I have a few critical comments about the proposed libraries. In brief, the library as proposed: * does stuff that I don't care about (creation of logs, pluggable writers, overridable logging functions); * does not do the two fundamental things that all loggers should do. Those only two things are: 1. Configure logging level during compilation 2. Configure logging level during runtime If you want to have your library accepted in Phobos, I suggest you take a very close look at glog's interface and implementation. It's a simple and robust library used by two major companies that depend on good logging. To exaggerate a bit, "so"s seat-of-the pants sample code is closer to the ideal logging library than your current draft. But I am encouraged by the fact that you went through the aggravation to write the code and show it to everybody, so hopefully you'll have the willpower to push this through. Thanks, Andrei
Aug 27 2010
parent sybrandy <sybrandy gmail.com> writes:
 Thanks. I think we should establish a tradition for reviews on this
 forum. The Boost review model has functioned very well, in the sense
 that it has consistently produced two outcomes: excellent libraries and
 pulp-beaten library authors. So I'd opt if at all possible for a tough
 review process that produces good libraries as opposed to a nicey-nicey
 process that fosters a low barrier of entry.

Understood and accepted.
 
 As I guess you suspected already, I have a few critical comments about
 the proposed libraries. In brief, the library as proposed:
 
 * does stuff that I don't care about (creation of logs, pluggable
 writers, overridable logging functions);

Examining each one individually: 1) creation of logs - Do you mean having to specify a log file? I'm not 100% sure what you mean by this. 2) pluggable writers - Again, this was designed to be flexible as there are different situations where different types of log writers are useful and I didn't want to force one on the user. I forgot to state this before, my ideally I was hoping for several to be created and be part of the logging library if it made it to Phobos. This way several common options could be provided by the standard library, but if for some reason the user wanted something else, they could have it. Part of the reason for doing this was to not have people coming up with 20 different logging libraries that behave differently and have different interfaces just because the provided one doesn't work just the way they want it to. I felt it was a big step to allow the user to change the writing process if needed to whatever suited their needs and to keep how the logger was instantiated and used in code simple. If you have a different vision, I'd like to hear about it. Perhaps to make things a bit simpler, but still retain the power, we could have a default writer that will be used if no writer is specified. 3) overridable logging functions - If you don't mean the writer, then I didn't mean to do that.
 
 * does not do the two fundamental things that all loggers should do.
 
 Those only two things are:
 
 1. Configure logging level during compilation
 
 2. Configure logging level during runtime

Actually, yes, it does do this. If you change the log level in the config file, it will be picked up by the logging library and the level changed accordingly during execution. I have a background thread that checks the file very 10 seconds. This way if you're running a server, you can change the level as needed for debugging without stopping the server.
 
 If you want to have your library accepted in Phobos, I suggest you take
 a very close look at glog's interface and implementation. It's a simple
 and robust library used by two major companies that depend on good
 logging. To exaggerate a bit, "so"s seat-of-the pants sample code is
 closer to the ideal logging library than your current draft. But I am
 encouraged by the fact that you went through the aggravation to write
 the code and show it to everybody, so hopefully you'll have the
 willpower to push this through.

I will take a look at it and document the potential design first before rewriting my code. Casey
Aug 28 2010
prev sibling next sibling parent reply =?iso-8859-2?B?VG9tZWsgU293afFza2k=?= <just ask.me> writes:
Dnia 26-08-2010 o 05:59:19 Andrei Alexandrescu  =

<SeeWebsiteForEmail erdani.org> napisa=B3(a):

 At my workplace we're using Google's logging library glog  =

 (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the  =

 more I use it, the more I like it. It's simple, to the point, and  =

 effective.

 I was thinking it would be great to adapt a similar design into Phobos=

 There will be differences such as use of regular argument lists instea=

 of << etc., but the spirit will be similar. What do you think?

Hm.. why not. Some quick thoughts: * Only a subset of features needs to be ported, e.g. DLOG(...) =3D=3D version(debug) LOG(...) CHECK =3D=3D enforce() Also, I don't get the superlativeness of LOG_IF(INFO, pred) << ... = versus if (pred) LOG(INFO) << ... * Instead of LOG(INFO, msg), please go for Log.info(msg). * LOG_EVERY_N, LOG_FIRST_N, ... generalizes to Log.info!n_pred, where = n_pred is a function taking an int. I'm curious about the D implementation, though - how to pull off a = separate counter for every calling site? I can think only of mixins, I = mean the ugly ones. * Consider Log.errorf(msg, args, to, fill, in, holes, in, msg) - I know = = there's Log.error(msg, format(args...)), but formatted logging happens = often enough to justify *f variants. Besides, it rhymes nicely with = std.stdio.write(f). * VLOG seems unnecessary. From my experience it's hard enough to keep th= e = meaning of ordinary *named* levels consistent in an application dev'd by=
  =

1 programmers. Custom levels whose name is a nothing-saying integer? = Forget it, every one will log under his own lucky number. I'd say adding= = simply a VERBOSE level at the end of the scale would suffice. * Allow per-module fine grained level settings for ordinary levels = (info/warn/...) * Implement logging function body like this: void info(lazy string msg) { version(no_logs) else { ... }} So that flagging compilation with -version=3Dno_logs -inline would make = the = logging vanish from binaries. For hardcore people. Tomek
Aug 26 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 26 Aug 2010 18:19:24 -0400, Tomek Sowiński <just ask.me> wrote:

 Dnia 26-08-2010 o 05:59:19 Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> napisał(a):

 At my workplace we're using Google's logging library glog  
 (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the  
 more I use it, the more I like it. It's simple, to the point, and  
 effective.

 I was thinking it would be great to adapt a similar design into Phobos.  
 There will be differences such as use of regular argument lists instead  
 of << etc., but the spirit will be similar. What do you think?

Hm.. why not. Some quick thoughts: * Only a subset of features needs to be ported, e.g. DLOG(...) == version(debug) LOG(...) CHECK == enforce() Also, I don't get the superlativeness of LOG_IF(INFO, pred) << ... versus if (pred) LOG(INFO) << ...

I think I know why, without even looking at the code. A typical issue with logging is that you want to evaluate the log output level, which is always an O(1) operation, before evaluating any other items which may be expensive, such as a custom predicate or message. i.e. LOG_IF probably does this: if(log.level >= INFO && pred) This is one of the only reasons I think we need a macro system. Mixins can do this, but who wants to always write mixin when doing logging? lazy is traditionally used, but it has costs as well. The best solution is to have a macro that converts: log.info(msg); directly into: if(log.level >= info) log.output(msg); which doesn't require lazy and is exactly what you *should* write.
 * Instead of LOG(INFO, msg), please go for Log.info(msg).

Most likely, this is due to the same thing. -Steve
Aug 27 2010
next sibling parent Pelle <pelle.mansson gmail.com> writes:
On 08/27/2010 03:49 PM, Steven Schveighoffer wrote:
 On Thu, 26 Aug 2010 18:19:24 -0400, Tomek Sowiński <just ask.me> wrote:

 Dnia 26-08-2010 o 05:59:19 Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> napisał(a):

 At my workplace we're using Google's logging library glog
 (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the
 more I use it, the more I like it. It's simple, to the point, and
 effective.

 I was thinking it would be great to adapt a similar design into
 Phobos. There will be differences such as use of regular argument
 lists instead of << etc., but the spirit will be similar. What do you
 think?

Hm.. why not. Some quick thoughts: * Only a subset of features needs to be ported, e.g. DLOG(...) == version(debug) LOG(...) CHECK == enforce() Also, I don't get the superlativeness of LOG_IF(INFO, pred) << ... versus if (pred) LOG(INFO) << ...

I think I know why, without even looking at the code. A typical issue with logging is that you want to evaluate the log output level, which is always an O(1) operation, before evaluating any other items which may be expensive, such as a custom predicate or message. i.e. LOG_IF probably does this: if(log.level >= INFO && pred) This is one of the only reasons I think we need a macro system. Mixins can do this, but who wants to always write mixin when doing logging? lazy is traditionally used, but it has costs as well. The best solution is to have a macro that converts: log.info(msg); directly into: if(log.level >= info) log.output(msg); which doesn't require lazy and is exactly what you *should* write.
 * Instead of LOG(INFO, msg), please go for Log.info(msg).

Most likely, this is due to the same thing. -Steve

Since lazy is rarely needed, one could use non-lazy by default and have a lazy as well, like log.info.lazy(msg) or equivalent.
Aug 27 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/27/10 6:49 PDT, Steven Schveighoffer wrote:
 On Thu, 26 Aug 2010 18:19:24 -0400, Tomek Sowiński <just ask.me> wrote:

 Dnia 26-08-2010 o 05:59:19 Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> napisał(a):

 At my workplace we're using Google's logging library glog
 (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the
 more I use it, the more I like it. It's simple, to the point, and
 effective.

 I was thinking it would be great to adapt a similar design into
 Phobos. There will be differences such as use of regular argument
 lists instead of << etc., but the spirit will be similar. What do you
 think?

Hm.. why not. Some quick thoughts: * Only a subset of features needs to be ported, e.g. DLOG(...) == version(debug) LOG(...) CHECK == enforce() Also, I don't get the superlativeness of LOG_IF(INFO, pred) << ... versus if (pred) LOG(INFO) << ...

I think I know why, without even looking at the code. A typical issue with logging is that you want to evaluate the log output level, which is always an O(1) operation, before evaluating any other items which may be expensive, such as a custom predicate or message.

That, plus the ability to disable logging altogether statically. Andrei
Aug 27 2010
prev sibling next sibling parent Stanislav Blinov <blinov loniir.ru> writes:
  27.08.2010 17:49, Steven Schveighoffer wrote:
 i.e. LOG_IF probably does this:

 if(log.level >= INFO && pred)

 This is one of the only reasons I think we need a macro system.  
 Mixins can do this, but who wants to always write mixin when doing 
 logging?

 lazy is traditionally used, but it has costs as well.  The best 
 solution is to have a macro that converts:

 log.info(msg);

 directly into:

 if(log.level >= info) log.output(msg);

 which doesn't require lazy and is exactly what you *should* write.

--- import std.typecons; mixin(defineEnum!("LogLevel", "error", "info")); struct Log { LogLevel level; template isLogLevel(string m) { enum isLogLevel = __traits(hasMember, LogLevel, m); } void opDispatch(string m, Args...)(lazy Args a) if (Log.isLogLevel!(m)) { LogLevel l; enumFromString(m,l); if (level >= l) { writef("%s ", m); writefln(a); } } } void main() { Log log; log.level = LogLevel.error; log.error("Error!"); // printed log.info("Info!"); // not printed log.level = LogLevel.info; log.error("Error!"); // printed log.info("Info!"); // printed log.warning("Warning!"); // does not compile } --- It does however use lazy, but not mixins, and does not require any macros :) And it is safe.
Aug 27 2010
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Steven Schveighoffer <schveiguy yahoo.com> wrote:

 This is one of the only reasons I think we need a macro system.  Mixins  
 can do this, but who wants to always write mixin when doing logging?

 lazy is traditionally used, but it has costs as well.  The best solution  
 is to have a macro that converts:

 log.info(msg);

 directly into:

 if(log.level >= info) log.output(msg);

 which doesn't require lazy and is exactly what you *should* write.

This would, at least to an extent, be covered by my enhancement request at http://d.puremagic.com/issues/show_bug.cgi?id=3666. That said, proper macros is one of the things I want the most for D. -- Simen
Aug 27 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 At my workplace we're using Google's logging library glog 
 (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the 
 more I use it, the more I like it. It's simple, to the point, and 
 effective.
 
 I was thinking it would be great to adapt a similar design into Phobos. 
 There will be differences such as use of regular argument lists instead 
 of << etc., but the spirit will be similar. What do you think?

Ok, I'm going to get flamed for this, but, I don't get it I do logging all the time. It's usually customized to the particular problem I'm trying to solve, so it involves uncommenting the right printf's and then running it. Voila. Done. The logging libraries I've seen usually required more time spent installing the package, getting it to compile, reading the documentation, finding out it doesn't work, rereading the documentation, etc., etc., than just putting in a # $%^ printf, and Bang, it works, cut & print. Even worse, the logging libraries are loaded with a grab bag of trivial features to try and puff it up into looking impressive. They always seemed to me to be a solution in search of a problem. Shields up! what am I missing about this?
Aug 26 2010
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 Andrei Alexandrescu wrote:
 At my workplace we're using Google's logging library glog
 (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the
 more I use it, the more I like it. It's simple, to the point, and
 effective.

 I was thinking it would be great to adapt a similar design into Phobos.
 There will be differences such as use of regular argument lists instead
 of << etc., but the spirit will be similar. What do you think?

I don't get it I do logging all the time. It's usually customized to the particular problem I'm trying to solve, so it involves uncommenting the right printf's and then running it. Voila. Done. The logging libraries I've seen usually required more time spent installing the package, getting it to compile, reading the documentation, finding out it doesn't work, rereading the documentation, etc., etc., than just putting in a # $%^ printf, and Bang, it works, cut & print. Even worse, the logging libraries are loaded with a grab bag of trivial features to try and puff it up into looking impressive. They always seemed to me to be a solution in search of a problem. Shields up! what am I missing about this?

Relax, you've got some agreement on this. I've never looked seriously at logging libraries simply because I can't figure out what could possibly be better than just using std.stdio. Of course, I'm a new school programmer, so I use writeln(), not printf().
Aug 26 2010
prev sibling next sibling parent reply "Yao G." <yao.gomez spam.gmail.com> writes:
On Thu, 26 Aug 2010 20:34:43 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Ok, I'm going to get flamed for this, but,

      I don't get it

 I do logging all the time. It's usually customized to the particular  
 problem I'm trying to solve, so it involves uncommenting the right  
 printf's and then running it. Voila. Done.

 The logging libraries I've seen usually required more time spent  
 installing the package, getting it to compile, reading the  
 documentation, finding out it doesn't work, rereading the documentation,  
 etc., etc., than just putting in a # $%^ printf, and Bang, it works, cut  
 & print.

 Even worse, the logging libraries are loaded with a grab bag of trivial  
 features to try and puff it up into looking impressive. They always  
 seemed to me to be a solution in search of a problem.

 Shields up! what am I missing about this?

Using printf / writeln is perfectly fine, until you start to program in Windows, where there's no command line to display the text. Here's where I think a small logging library comes handy. I did a small one that logs to a file, and a variant that display the log messages to a independent window. -- Yao G.
Aug 26 2010
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Yao G. (yao.gomez spam.gmail.com)'s article
 On Thu, 26 Aug 2010 20:34:43 -0500, Walter Bright
 <newshound2 digitalmars.com> wrote:
 Ok, I'm going to get flamed for this, but,

      I don't get it

 I do logging all the time. It's usually customized to the particular
 problem I'm trying to solve, so it involves uncommenting the right
 printf's and then running it. Voila. Done.

 The logging libraries I've seen usually required more time spent
 installing the package, getting it to compile, reading the
 documentation, finding out it doesn't work, rereading the documentation,
 etc., etc., than just putting in a # $%^ printf, and Bang, it works, cut
 & print.

 Even worse, the logging libraries are loaded with a grab bag of trivial
 features to try and puff it up into looking impressive. They always
 seemed to me to be a solution in search of a problem.

 Shields up! what am I missing about this?

Windows, where there's no command line to display the text. Here's where I think a small logging library comes handy. I did a small one that logs to a file, and a variant that display the log messages to a independent window.

Ok, how about just having a global File object (in D2) that either points to a real disk file or stdout/stderr, depending on the circumstances?
Aug 26 2010
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Yao G. wrote:
 Using printf / writeln is perfectly fine, until you start to program in 
 Windows, where there's no command line to display the text.

fprintf(fplog, ...);
Aug 26 2010
prev sibling parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench robertmuench.de> writes:
On 2010-08-27 03:50:43 +0200, Yao G. said:

 Using printf / writeln is perfectly fine, until you start to program in 
 Windows, where there's no command line to display the text. Here's 
 where I think a small logging library comes handy. I did a small one 
 that logs to a file, and a variant that display the log messages to a 
 independent window.

void odprintf(const char *format, ...){ char buf[4096], *p = buf; va_list args; int n; va_start(args, format); #ifdef WIN32 n = _vsnprintf(p, sizeof buf - 3, format, args); // buf-3 is room for CR/LF/NUL #else n = vsnprintf(p, sizeof buf - 3, format, args); // buf-3 is room for CR/LF/NUL #endif va_end(args); p += (n < 0) ? sizeof buf - 3 : n; while ( p > buf && isspace(p[-1]) ) *--p = '\0'; *p++ = '\r'; *p++ = '\n'; *p = '\0'; #ifdef WIN32 OutputDebugString(buf); #else printf("%s", buf); #endif } Should do the trick and than sue something like debugview from ex-sysinternals. Works very well. -- Robert M. Mnch http://www.robertmuench.de
Aug 28 2010
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 27 Aug 2010 05:34:43 +0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Andrei Alexandrescu wrote:
 At my workplace we're using Google's logging library glog  
 (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the  
 more I use it, the more I like it. It's simple, to the point, and  
 effective.
  I was thinking it would be great to adapt a similar design into  
 Phobos. There will be differences such as use of regular argument lists  
 instead of << etc., but the spirit will be similar. What do you think?

Ok, I'm going to get flamed for this, but, I don't get it I do logging all the time. It's usually customized to the particular problem I'm trying to solve, so it involves uncommenting the right printf's and then running it. Voila. Done. The logging libraries I've seen usually required more time spent installing the package, getting it to compile, reading the documentation, finding out it doesn't work, rereading the documentation, etc., etc., than just putting in a # $%^ printf, and Bang, it works, cut & print. Even worse, the logging libraries are loaded with a grab bag of trivial features to try and puff it up into looking impressive. They always seemed to me to be a solution in search of a problem. Shields up! what am I missing about this?

Probably, that's because you don't write complex software with lots of independent modules that run for a long time. A good logging library is a must, alongside with a corresponding log parsing tool.
Aug 26 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Denis Koroskin:
 Probably, that's because you don't write complex software with lots of  
 independent modules that run for a long time.

Here "large systems that run for a long time" is the key, where long time may mean months or years. Logging is not just to debug. Recently I've seen languages that have even built-in logging features :-) Bye, bearophile
Aug 26 2010
prev sibling next sibling parent "Yao G." <yao.gomez spam.gmail.com> writes:
On Thu, 26 Aug 2010 20:53:30 -0500, dsimcha <dsimcha yahoo.com> wrote:

 [snip]

Ok, how about just having a global File object (in D2) that either points to a real disk file or stdout/stderr, depending on the circumstances?

That's a good idea but... How do I detect, at runtime, whether I'm running a console app or a window app? -- Yao G.
Aug 26 2010
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 The logging libraries I've seen usually required more time spent installing the
 package, getting it to compile, reading the documentation, finding out it
 doesn't work, rereading the documentation, etc., etc., than just putting in a
 # $%^ printf, and Bang, it works, cut & print.
 Even worse, the logging libraries are loaded with a grab bag of trivial
features
 to try and puff it up into looking impressive. They always seemed to me to be a
 solution in search of a problem.
 Shields up! what am I missing about this?

Just for fun: http://stackoverflow.com/questions/3580795/what-are-logging-libraries-for
Aug 26 2010
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Walter Bright Wrote:
 
 Shields up! what am I missing about this?

For server work, it's important that the amount of logging be dynamically configurable and that log lines which aren't printed consume as little overhead as possible. For some of the more advanced stuff in glog, there are times when I want to turn the log level way up to try and diagnose something occurring in production, but the amount of output this generates is such that if I can have some of the irrelevant stuff left out then so much the better. Trend analysis doesn't need to log every occurrence, thus the counter stuff, etc. One thing I did years ago for C++ was to create an ostream wrapper for the Windows Event Log. I still used std::log and std::err in my app, but a few lines of code redirecting output in main() and I could make log lines appear in the event log as messages instead. It would have been difficult to do this with printf, but a logging mechanism is generally not too difficult to configure this way.
Aug 26 2010
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Walter Bright wrote:

 Andrei Alexandrescu wrote:
 At my workplace we're using Google's logging library glog
 (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the
 more I use it, the more I like it. It's simple, to the point, and
 effective.
 
 I was thinking it would be great to adapt a similar design into Phobos.
 There will be differences such as use of regular argument lists instead
 of << etc., but the spirit will be similar. What do you think?

Ok, I'm going to get flamed for this, but, I don't get it I do logging all the time. It's usually customized to the particular problem I'm trying to solve, so it involves uncommenting the right printf's and then running it. Voila. Done.

One crucial step you require here is recompilation: that's not always an option.
 The logging libraries I've seen usually required more time spent installing
 the package, getting it to compile, reading the documentation, finding out it
 doesn't work, rereading the documentation, etc., etc., than just putting in a
 # $%^ printf, and Bang, it works, cut & print.

imho a logging library should have log(msg) as a base case that just works. On the other hand, if your requirements do not go beyond printf then it is only natural any investment feel somewhat pointless.
 Even worse, the logging libraries are loaded with a grab bag of trivial
 features to try and puff it up into looking impressive. They always seemed to
 me to be a solution in search of a problem.
 
 Shields up! what am I missing about this?

I think there are two basic requirements that logging libraries fulfill: - tuning the amount of info that is logged dynamically (no recompilation) - getting good log reports (rotating logs, nicely structured output, etc.) If you don't need this, then a log library does not give that much value.
Aug 27 2010
prev sibling next sibling parent Joe Greer <jgreer doubletake.com> writes:
Walter Bright <newshound2 digitalmars.com> wrote in
news:i574ns$11t2$1 digitalmars.com: 

 
 Ok, I'm going to get flamed for this, but,
 
      I don't get it
 
 I do logging all the time. It's usually customized to the particular
 problem I'm trying to solve, so it involves uncommenting the right
 printf's and then running it. Voila. Done.
 
 The logging libraries I've seen usually required more time spent
 installing the package, getting it to compile, reading the
 documentation, finding out it doesn't work, rereading the
 documentation, etc., etc., than just putting in a # $%^ printf, and
 Bang, it works, cut & print. 
 
 Even worse, the logging libraries are loaded with a grab bag of
 trivial features to try and puff it up into looking impressive. They
 always seemed to me to be a solution in search of a problem.
 
 Shields up! what am I missing about this?

In general, I would tend to agree that some logging libraries are pretty complicated and hard to just dive in and build what you need without spending a week learning the library. However, in commercial applications, espcially servers, there is often the need for standardized logging messages that are really part of the server's output and not just something for one off debugging. Think in terms of inetd, smtpd, or some commercial server. These need to continually log messages containing one or more of timestamp, location of where message originated, severity of message (note, error, warning, etc), thread id, and other things I am not thinking of at the moment. :) Furthermore, the output may get targeted to multiple streams such as console, debug out on windows, files, one of the system event logs. Furthermore, files may roll like the unix system log based on some criteria (size, date). Etc. There are a lot of things to consider. A good approachable library can make assembling the right combination of logs pretty simple. Many people consider it important to be able to turn the logging off and leave minimal overhead (I personally find that applications that need logging, really just want to leave it on, even if the programmer's don't think they do. Bugs are often time consuming to reproduce and your customer may not be thrilled with the prospect of helping you find your bug.) There are probably other things I am forgetting, but hopefully you get the idea. So, anyway, I can see the need for a logging construction kit of some sort. Ideally though, it would make things easy to construct a log that does what you need without spending a week learning the library. :) joe
Aug 27 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 26 Aug 2010 21:34:43 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Andrei Alexandrescu wrote:
 At my workplace we're using Google's logging library glog  
 (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the  
 more I use it, the more I like it. It's simple, to the point, and  
 effective.
  I was thinking it would be great to adapt a similar design into  
 Phobos. There will be differences such as use of regular argument lists  
 instead of << etc., but the spirit will be similar. What do you think?

Ok, I'm going to get flamed for this, but, I don't get it I do logging all the time. It's usually customized to the particular problem I'm trying to solve, so it involves uncommenting the right printf's and then running it. Voila. Done. The logging libraries I've seen usually required more time spent installing the package, getting it to compile, reading the documentation, finding out it doesn't work, rereading the documentation, etc., etc., than just putting in a # $%^ printf, and Bang, it works, cut & print. Even worse, the logging libraries are loaded with a grab bag of trivial features to try and puff it up into looking impressive. They always seemed to me to be a solution in search of a problem. Shields up! what am I missing about this?

Logging libraries are useful because they are configured at runtime, that means you can not only configure them without recompiling, but you can reconfigure them while actually running the code. This can be indispensable if you have a system that's acting funny. Just augment the log level and all of a sudden you get all the data you need, where as if you had to recompile and restart, the problem goes away. They traditionally are also not invasive, so if you configure them to not print something, the code isn't significantly lower performing. They are also useful not only in debug mode, but also for normal usage. I can't tell you how many times I had a technician tell me he didn't do something, and I can point at the log which recorded that he did. There's no argument, no goose-chasing some possible bug because some tech didn't want to admit he fucked up. It can also give you extremely valuable information of what happened leading up to a bug, in time-ordered fashion, so you can get an exact picture of what happens. This is important for those once-a-month bugs that you don't know when they are going to pop up. I had a server-client system that used tftp to download boot images to hundreds of computers. Because of the nature of the product I had to write my own tftp server. On the surface, it's not hard to implement, but when you have to start dealing with all the nuances of tftp *client* implementations that are sometimes part of a BIOS boot ROM, you find things that aren't in the RFC :) By changing one file, I can output every single tftp packet received and transmitted (and *only* that, another feature of logging -- levels can be selected per named log instance) and see exactly where the problem is. The second half of a logging library is the output part. Most log libraries provide a wealth of means to output logging data, from text files to network logging, to sticking things in the Windows event log. This is not trivial to implement, and is not easy to do with fprintf. I'll say that logging is mostly for applications that have an extended lifetime -- not ones that perform a specific task and exit. Compilers fall into that latter category, so maybe you haven't had the experience of how valuable logging can be. But you can still use them in such applications. Think of how valuable it is to just re-run the compiler with -v instead of recompiling the compiler with debug mode turned on. Especially true if you don't control the system where the compiler is running (gotta go build it, then copy it to the system, then run it, etc.) -Steve
Aug 27 2010
prev sibling next sibling parent so <so so.do> writes:
On Fri, 27 Aug 2010 05:34:50 +0300, bearophile <bearophileHUGS lycos.com>  
wrote:

 Denis Koroskin:
 Probably, that's because you don't write complex software with lots of
 independent modules that run for a long time.

Here "large systems that run for a long time" is the key, where long time may mean months or years. Logging is not just to debug. Recently I've seen languages that have even built-in logging features :-) Bye, bearophile

You can't expect a standard library do everything for you, if what you need is a specific and complex logging library, you should/will use that "specific" library, the kind of programs you mention should write their own :) -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Aug 27 2010
prev sibling next sibling parent reply so <so so.do> writes:
On Fri, 27 Aug 2010 04:34:43 +0300, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Andrei Alexandrescu wrote:
 At my workplace we're using Google's logging library glog  
 (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the  
 more I use it, the more I like it. It's simple, to the point, and  
 effective.
  I was thinking it would be great to adapt a similar design into  
 Phobos. There will be differences such as use of regular argument lists  
 instead of << etc., but the spirit will be similar. What do you think?

Ok, I'm going to get flamed for this, but, I don't get it I do logging all the time. It's usually customized to the particular problem I'm trying to solve, so it involves uncommenting the right printf's and then running it. Voila. Done. The logging libraries I've seen usually required more time spent installing the package, getting it to compile, reading the documentation, finding out it doesn't work, rereading the documentation, etc., etc., than just putting in a # $%^ printf, and Bang, it works, cut & print. Even worse, the logging libraries are loaded with a grab bag of trivial features to try and puff it up into looking impressive. They always seemed to me to be a solution in search of a problem. Shields up! what am I missing about this?

If D needs a standard logging library, it should but nothing more than... log_open("filename"); // somewhere at start, if possible hide this as well log(log_level_here, "doing this :", param0, ", and that", param1...); dlog(...); .... I dislike all lame logging libraries out there, where objects running around. Logger::init("filename"); Logger log(...); log(level etc, ...); Logger::tini(...); If one needs a complex logging system, he should find/write one. Thanks! -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Aug 27 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/27/10 14:44 PDT, so wrote:
 On Fri, 27 Aug 2010 04:34:43 +0300, Walter Bright
 <newshound2 digitalmars.com> wrote:

 Andrei Alexandrescu wrote:
 At my workplace we're using Google's logging library glog
 (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the
 more I use it, the more I like it. It's simple, to the point, and
 effective.
 I was thinking it would be great to adapt a similar design into
 Phobos. There will be differences such as use of regular argument
 lists instead of << etc., but the spirit will be similar. What do you
 think?

Ok, I'm going to get flamed for this, but, I don't get it I do logging all the time. It's usually customized to the particular problem I'm trying to solve, so it involves uncommenting the right printf's and then running it. Voila. Done. The logging libraries I've seen usually required more time spent installing the package, getting it to compile, reading the documentation, finding out it doesn't work, rereading the documentation, etc., etc., than just putting in a # $%^ printf, and Bang, it works, cut & print. Even worse, the logging libraries are loaded with a grab bag of trivial features to try and puff it up into looking impressive. They always seemed to me to be a solution in search of a problem. Shields up! what am I missing about this?

If D needs a standard logging library, it should but nothing more than... log_open("filename"); // somewhere at start, if possible hide this as well log(log_level_here, "doing this :", param0, ", and that", param1...); dlog(...); ..... I dislike all lame logging libraries out there, where objects running around. Logger::init("filename"); Logger log(...); log(level etc, ...); Logger::tini(...); If one needs a complex logging system, he should find/write one. Thanks!

Totally with you. My opinion: everything beyond 7 symbols plopped in std.stdio decays the likelihood of acceptance by half. Andrei
Aug 27 2010
prev sibling next sibling parent sybrandy <sybrandy gmail.com> writes:
 Ok, I'm going to get flamed for this, but,

 I don't get it

 I do logging all the time. It's usually customized to the particular
 problem I'm trying to solve, so it involves uncommenting the right
 printf's and then running it. Voila. Done.

 The logging libraries I've seen usually required more time spent
 installing the package, getting it to compile, reading the
 documentation, finding out it doesn't work, rereading the documentation,
 etc., etc., than just putting in a # $%^ printf, and Bang, it works, cut
 & print.

 Even worse, the logging libraries are loaded with a grab bag of trivial
 features to try and puff it up into looking impressive. They always
 seemed to me to be a solution in search of a problem.

 Shields up! what am I missing about this?

No, you're not. That's why for the one I've been working on, I've been aiming for simplicity. Basically, you can add as much logging as you like, but when you don't need it, you just recompile with a version switch to turn it off and it's like it was never there. Mine is also one file to import and a two-line config file. The main reason for the config file is just so you can change the logging level without stopping the program. Casey
Aug 27 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/26/10 18:34 PDT, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 At my workplace we're using Google's logging library glog
 (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the
 more I use it, the more I like it. It's simple, to the point, and
 effective.

 I was thinking it would be great to adapt a similar design into
 Phobos. There will be differences such as use of regular argument
 lists instead of << etc., but the spirit will be similar. What do you
 think?

Ok, I'm going to get flamed for this, but, I don't get it I do logging all the time. It's usually customized to the particular problem I'm trying to solve, so it involves uncommenting the right printf's and then running it. Voila. Done. The logging libraries I've seen usually required more time spent installing the package, getting it to compile, reading the documentation, finding out it doesn't work, rereading the documentation, etc., etc., than just putting in a # $%^ printf, and Bang, it works, cut & print. Even worse, the logging libraries are loaded with a grab bag of trivial features to try and puff it up into looking impressive. They always seemed to me to be a solution in search of a problem. Shields up! what am I missing about this?

I was curious to hear what others reply - great discussion! I won't add much to what was said, but I do want to emphasize a couple of points. Logging is something that 9 people do in 10 ways. As such, leaving it to everybody's whim will produce many incompatible logging styles, formats, and mechanisms, which is untenable in any corporation that has long-running programs on more than a few servers. I smile inside thinking what logging would look like if everybody at Facebook decided how to do their own logging on the many tens of thousands of running servers. You have already seen the value of standardizing on easy things that everybody does differently - so that's why D has things such as version, debug, and unittest as keywords. Most likely you have experienced first-hand the outcome of leaving such simple policy decisions to the whim of the user. It is easy to port that understanding and expertise to a matter that is very similar even though you haven't experienced it yourself. One problem with logging is that it's one of those "pure design" problems - it poses almost no algorithmic or systemic challenges. This unfortunately creates an opportunity for overblown designs to come forth and justify their own existence ("clearly you could do logging yourself easily, but it would take you a long time to implement all of this framework with all these features" etc), which in turn establishes a ratchet mechanism that brings up ever more intricate, feature-full designs. That's why I'm saying: keep the logging library nice and simple and never allow itself to take it too seriously. Andrei
Aug 27 2010
prev sibling next sibling parent so <so so.do> writes:
 I was curious to hear what others reply - great discussion! I won't add  
 much to what was said, but I do want to emphasize a couple of points.

 Logging is something that 9 people do in 10 ways. As such, leaving it to  
 everybody's whim will produce many incompatible logging styles, formats,  
 and mechanisms, which is untenable in any corporation that has  
 long-running programs on more than a few servers. I smile inside  
 thinking what logging would look like if everybody at Facebook decided  
 how to do their own logging on the many tens of thousands of running  
 servers.

 You have already seen the value of standardizing on easy things that  
 everybody does differently - so that's why D has things such as version,  
 debug, and unittest as keywords. Most likely you have experienced  
 first-hand the outcome of leaving such simple policy decisions to the  
 whim of the user. It is easy to port that understanding and expertise to  
 a matter that is very similar even though you haven't experienced it  
 yourself.

 One problem with logging is that it's one of those "pure design"  
 problems - it poses almost no algorithmic or systemic challenges. This  
 unfortunately creates an opportunity for overblown designs to come forth  
 and justify their own existence ("clearly you could do logging yourself  
 easily, but it would take you a long time to implement all of this  
 framework with all these features" etc), which in turn establishes a  
 ratchet mechanism that brings up ever more intricate, feature-full  
 designs.

 That's why I'm saying: keep the logging library nice and simple and  
 never allow itself to take it too seriously.


 Andrei

This is one thing people ignore or just purely don't understand, Walter in this ng always say that pushing complexity to compiler/library good thing and to user is a bad thing. We all can see it is true, i assume? For the case at hand, what would one expect from a logging library? 1 - 99% (i don't think this is an exaggeration) of the times, guess... logging to specific level! 2 - 1% state changes and redirection. What all if not most of the libraries out there want you to do? Each time you need to use it : You need to instantiate a logger object with, with level and file etc... // %0-1 part They sometimes go even further and want you call some internals... // another %0-1 part Then you need to do actual stuff... // yay! 99-100% part If one call this a design, i got nothing to say :) This is a good example of "one solution to every problem", "single paradigm" sickness. Thanks. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Aug 27 2010
prev sibling next sibling parent BCS <none anon.com> writes:
Hello Walter,

 Andrei Alexandrescu wrote:
 
 At my workplace we're using Google's logging library glog
 (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the
 more I use it, the more I like it. It's simple, to the point, and
 effective.
 
 I was thinking it would be great to adapt a similar design into
 Phobos. There will be differences such as use of regular argument
 lists instead of << etc., but the spirit will be similar. What do you
 think?
 

I don't get it I do logging all the time. It's usually customized to the particular problem I'm trying to solve, so it involves uncommenting the right printf's and then running it. Voila. Done. The logging libraries I've seen usually required more time spent installing the package, getting it to compile,

include std.logging; // done
 reading the documentation,

If it's done well, one page of exampls will get 90% of the people going.
 finding out it doesn't work,

That would be a bug.
 
 Even worse, the logging libraries are loaded with a grab bag of
 trivial features to try and puff it up into looking impressive.

That lib isn't and what we do dosn't need to be. -- ... <IXOYE><
Aug 28 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 27/08/2010 02:34, Walter Bright wrote:
 Even worse, the logging libraries are loaded with a grab bag of trivial
 features to try and puff it up into looking impressive. They always
 seemed to me to be a solution in search of a problem.

 Shields up! what am I missing about this?

People have already mentioned: * The need to configure log options dynamically (during runtime), or by restarting the program (but without recompilation or redeployment). * Most log analysis occurs with programs running in production, not in test environments, and as such performance is quite important. That's why you have log levels and not just a binary on-off option. Other useful stuff not mentioned already: * Ability to add log message metadata. That is the ability to log not only the log message, but associate metadata such as timestamp, date, current thread, source file location, etc., *in a configurable manner*. * An extensible mechanism to configure where the log message is sent. Just outputting to a file or console may not be enough. You might need to send logs through email, you might need to log them on some OS log mechanism, etc.. Ideally you should be able to create your own log message "handlers" (These are called Appenders in log4j lingo). * Some form of user defined "channels" feature (aka named logs): associate a log call with some name or "channel" which can be configured separately from other channels. Usually each channel corresponds to some user-defined logical module, behavior, aspect or component of the application. If your application has a huge number of these, you *will* want the ability to configure them separately. (again for performance, but also for easier log analysis) This is common in the Java server world, consider for example this call stack for a typical webapp using Spring, a popular Java webapp framework: http://ptrthomas.wordpress.com/2006/06/06/java-call-stack-from-http-upto-jdbc-as-a-picture/ -- Bruno Medeiros - Software Engineer
Oct 06 2010
prev sibling next sibling parent so <so so.do> writes:
On Sat, 28 Aug 2010 04:18:52 +0300, sybrandy <sybrandy gmail.com> wrote:

 Here's my current version of the logger.  All of the documentation
 should be in the logger.d file.  I also provided a sample config file
 (logger.conf) and a sample test file that I was using for benchmarking
 (main.d).  Let me know if you have any questions.  Feedback on improving
 this is also welcome.

 The one thing I forgot to note in here is that the function that writes
 to the log is passed into the second version of the constructor, which
 needs to be used only once in the code.  A simple log writer is included
 at the bottom of logger.d that does work.  The reason I did this was
 when I initially asked for feedback, I got several ideas on how the
 logger can be improved.  Also, I discussed this with a friend of mine
 who stated that people may want to log to something other than a file,
 such as syslog.  So, instead of trying to make the one "end all be all"
 logger, I felt that by allowing it to accept a function as a parameter
 to the constructor, the person can write to any type of log file,
 database, whatever they want and the logger interface works the same no
 matter what.

 There currently is a bug somewhere that I don't understand.  Even though
 I have "OwnerTerminated" as part of my receive statement, I still see
 exceptions when the program closes.  However, it doesn't seem to affect
 the execution of the logger.

 Enjoy.

 Casey

Hello? Couldn't it be just like this? enum log_level { note, // or info whatever warning, error, fatal, } string log_direct(string filename); // returns last log file directed. void log(A...)(A a) { if(typof(a[0]) == log_level) do_level_thingy(); ... // rest. } version(debug) void debug_log(A...)(A a) { log(a); } else void debug_log(A...)(A a) {} void main() { std::string old_file = log_direct(new_file); // if you like to change it that is log("log me pretty", arg1, ....); log(error, "log me pretty error", arg1, ...); log(warning, "log me pretty warning", arg1, ...); } Isn't that good/beautiful/flexible enough? Please don't start with instantiated loggers, they are ugly so ugly and unnecessary! Thanks. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Aug 27 2010
prev sibling next sibling parent so <so so.do> writes:
 Hello?
 Couldn't it be just like this?

 enum log_level {
    note, // or info whatever
    warning,
    error,
    fatal,
 }

 string log_direct(string filename); // returns last log file directed.
 void log(A...)(A a)
 {
    if(typof(a[0]) == log_level)
      do_level_thingy();

    ... // rest.
 }

 version(debug)  void debug_log(A...)(A a) { log(a); }
 else            void debug_log(A...)(A a) {}

 void main()
 {
    std::string old_file = log_direct(new_file); // if you like to change  
 it that is
    log("log me pretty", arg1, ....);
    log(error, "log me pretty error", arg1, ...);
    log(warning, "log me pretty warning", arg1, ...);
 }

 Isn't that good/beautiful/flexible enough?
 Please don't start with instantiated loggers, they are ugly so ugly and  
 unnecessary!

 Thanks.

Damn i should learn to read it a few times before posting! "Hello?" Hello! "ugly so ugly" one of them would do i guess :) -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Aug 27 2010
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 28 Aug 2010 05:54:40 +0400, so <so so.do> wrote:

 On Sat, 28 Aug 2010 04:18:52 +0300, sybrandy <sybrandy gmail.com> wrote:

 Here's my current version of the logger.  All of the documentation
 should be in the logger.d file.  I also provided a sample config file
 (logger.conf) and a sample test file that I was using for benchmarking
 (main.d).  Let me know if you have any questions.  Feedback on improving
 this is also welcome.

 The one thing I forgot to note in here is that the function that writes
 to the log is passed into the second version of the constructor, which
 needs to be used only once in the code.  A simple log writer is included
 at the bottom of logger.d that does work.  The reason I did this was
 when I initially asked for feedback, I got several ideas on how the
 logger can be improved.  Also, I discussed this with a friend of mine
 who stated that people may want to log to something other than a file,
 such as syslog.  So, instead of trying to make the one "end all be all"
 logger, I felt that by allowing it to accept a function as a parameter
 to the constructor, the person can write to any type of log file,
 database, whatever they want and the logger interface works the same no
 matter what.

 There currently is a bug somewhere that I don't understand.  Even though
 I have "OwnerTerminated" as part of my receive statement, I still see
 exceptions when the program closes.  However, it doesn't seem to affect
 the execution of the logger.

 Enjoy.

 Casey

Hello? Couldn't it be just like this? enum log_level { note, // or info whatever warning, error, fatal, } string log_direct(string filename); // returns last log file directed. void log(A...)(A a) { if(typof(a[0]) == log_level) do_level_thingy(); ... // rest. } version(debug) void debug_log(A...)(A a) { log(a); } else void debug_log(A...)(A a) {} void main() { std::string old_file = log_direct(new_file); // if you like to change it that is log("log me pretty", arg1, ....); log(error, "log me pretty error", arg1, ...); log(warning, "log me pretty warning", arg1, ...); } Isn't that good/beautiful/flexible enough? Please don't start with instantiated loggers, they are ugly so ugly and unnecessary! Thanks.

Why wouldn't you just keep using writefln for your logging? I'm afraid you misunderstand why people use logging libraries. I'll try to explain: once your project grows big, the amount of log it starts to generate may grow *HUGE*. Once there, you understand the importance of configuring every bit of the logger. Some logs needs to be disabled, some logs need to go to console, some logs need to file A, some to file B etc. That's why it is a standard practice to have *independent* loggers for most of your classes. I refuse to use anything that dumps all the logs into the same bin - it's a joke and not a logging framework.
Aug 27 2010
prev sibling next sibling parent so <so so.do> writes:
On Sat, 28 Aug 2010 05:29:53 +0300, Denis Koroskin <2korden gmail.com>  
wrote:

 On Sat, 28 Aug 2010 05:54:40 +0400, so <so so.do> wrote:

 On Sat, 28 Aug 2010 04:18:52 +0300, sybrandy <sybrandy gmail.com> wrote:

 Here's my current version of the logger.  All of the documentation
 should be in the logger.d file.  I also provided a sample config file
 (logger.conf) and a sample test file that I was using for benchmarking
 (main.d).  Let me know if you have any questions.  Feedback on  
 improving
 this is also welcome.

 The one thing I forgot to note in here is that the function that writes
 to the log is passed into the second version of the constructor, which
 needs to be used only once in the code.  A simple log writer is  
 included
 at the bottom of logger.d that does work.  The reason I did this was
 when I initially asked for feedback, I got several ideas on how the
 logger can be improved.  Also, I discussed this with a friend of mine
 who stated that people may want to log to something other than a file,
 such as syslog.  So, instead of trying to make the one "end all be all"
 logger, I felt that by allowing it to accept a function as a parameter
 to the constructor, the person can write to any type of log file,
 database, whatever they want and the logger interface works the same no
 matter what.

 There currently is a bug somewhere that I don't understand.  Even  
 though
 I have "OwnerTerminated" as part of my receive statement, I still see
 exceptions when the program closes.  However, it doesn't seem to affect
 the execution of the logger.

 Enjoy.

 Casey

Hello? Couldn't it be just like this? enum log_level { note, // or info whatever warning, error, fatal, } string log_direct(string filename); // returns last log file directed. void log(A...)(A a) { if(typof(a[0]) == log_level) do_level_thingy(); ... // rest. } version(debug) void debug_log(A...)(A a) { log(a); } else void debug_log(A...)(A a) {} void main() { std::string old_file = log_direct(new_file); // if you like to change it that is log("log me pretty", arg1, ....); log(error, "log me pretty error", arg1, ...); log(warning, "log me pretty warning", arg1, ...); } Isn't that good/beautiful/flexible enough? Please don't start with instantiated loggers, they are ugly so ugly and unnecessary! Thanks.

Why wouldn't you just keep using writefln for your logging? I'm afraid you misunderstand why people use logging libraries. I'll try to explain: once your project grows big, the amount of log it starts to generate may grow *HUGE*. Once there, you understand the importance of configuring every bit of the logger. Some logs needs to be disabled, some logs need to go to console, some logs need to file A, some to file B etc. That's why it is a standard practice to have *independent* loggers for most of your classes. I refuse to use anything that dumps all the logs into the same bin - it's a joke and not a logging framework.

There is not a thing in my example that says. "you should dump all the logs into the same bin". If you have a closer look at it, and try to be objective and don't take this serious but i can't find a better phrase for it... Stop being OOP centric. If you want me to write this retard extra line every time i want to log, just because in some company a guy needed this, i am not using your so clever/complex/... library, that is it. Logger log(new_file, log_level, ....); // wth? log(....); .... What is the big deal here? i just want to write a log to somewhere with the given level. 99% of the time you won't redirect it anyways. Am i wrong? log("this : ", that); log(warning, "this : ", that); Oh you want to redirect it? string old = log_direct(new, error); log(error, log(error, ... log_direct(old); // or just make a scoped object there and hide this as well... Is these so simple for your needs? Roll/write/buy your own, this is not a standard library issue. Thanks! -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Aug 27 2010
prev sibling next sibling parent so <so so.do> writes:
 That's why it is a standard practice to have *independent* loggers for  
 most of your classes. I refuse to use anything that dumps all the logs  
 into the same bin - it's a joke and not a logging framework.

Also if you want to see a real joke, take a closer look at the codes of big companies or big open source project codes. Over-engineering joke at best, just load a random source file. Oh what you get? Probably it contains 10 functions each contains 10 lines of code. Each of these 10 lines contains 2 lines to open/close a logger. You are not really logging there, Your whole program is a LOGGING framework, you certainly need a "complex" logger :) Sorry couldn't resist! -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Aug 27 2010
prev sibling next sibling parent BCS <none anon.com> writes:
Hello Andrei,

 Hello,
 
 At my workplace we're using Google's logging library glog
 (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the
 more I use it, the more I like it. It's simple, to the point, and
 effective.
 
 I was thinking it would be great to adapt a similar design into
 Phobos. There will be differences such as use of regular argument
 lists instead of << etc., but the spirit will be similar. What do you
 think?
 
 Andrei
 

If your looking for a Google lib to add/copy, do this one first: http://google-gflags.googlecode.com/svn/trunk/doc/gflags.html -- ... <IXOYE><
Aug 28 2010
prev sibling parent reply "Yao G." <yao.gomez spam.gmail.com> writes:
On Sat, 28 Aug 2010 13:44:34 -0500, BCS <none anon.com> wrote:

 If your looking for a Google lib to add/copy, do this one first:  
 http://google-gflags.googlecode.com/svn/trunk/doc/gflags.html

Isn't essentially what std.getopt does? -- Yao G.
Aug 28 2010
parent reply BCS <none anon.com> writes:
Hello Yao G.,

 On Sat, 28 Aug 2010 13:44:34 -0500, BCS <none anon.com> wrote:
 
 If your looking for a Google lib to add/copy, do this one first:
 http://google-gflags.googlecode.com/svn/trunk/doc/gflags.html
 


Far from it. getops requiters that all the flags be defined in the same place, gflags allows each module to define it's own flags. -- ... <IXOYE><
Aug 28 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/28/2010 03:11 PM, BCS wrote:
 Hello Yao G.,

 On Sat, 28 Aug 2010 13:44:34 -0500, BCS <none anon.com> wrote:

 If your looking for a Google lib to add/copy, do this one first:
 http://google-gflags.googlecode.com/svn/trunk/doc/gflags.html


Far from it. getops requiters that all the flags be defined in the same place, gflags allows each module to define it's own flags.

Gflags is nice indeed. At any rate, glog should be added regardless of gflags. Andrei
Aug 28 2010