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:
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
next sibling parent reply 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
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 parent reply "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
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 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 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=


d  =


 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
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 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.


Hmm... something like this can be done with opDispatch:

---

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 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 next 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 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 


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?


 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

 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,  

 & 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 reply 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,

 & 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.


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
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 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. Münch
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,  

 & 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 reply 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
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 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

 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



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

 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,  

 & 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 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,  

 & 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

 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,

 & 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 reply 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,

 & 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
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?
 


 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,


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 Zz <nospam nospam.com> writes:
looks interesting.

Other interesting libs to look at are:
Simple Log - Just plain straight forward
https://simple-log.dev.java.net/

Some of you might remember Matthew Wilson and he has Pantheios which looks
interesting,
http://www.pantheios.org/

Zz
Aug 27 2010
prev sibling next sibling parent reply 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
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
 


 Isn't essentially what std.getopt does?
 


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


 Isn't essentially what std.getopt does?


 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
prev sibling parent Kagamin <spam here.lot> writes:
simendsjo Wrote:


 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?


Hmm... now it renames old logs with date pattern leading to the same issue :-/

    <appender name="OneLogFile" type="log4net.Appender.RollingFileAppender">
      <File type="log4net.Util.PatternString" value="C:\Temp\my.log" />
      <AppendToFile value="false" />
      <StaticLogFileName value="true" />
      <MaxSizeRollBackups value="10" />
      <MaximumFileSize value="20MB" />
      <layout type="log4net.Layout.PatternLayout">
        <conversionPattern value="%date - %message" />
      </layout>
    </appender>
Sep 16 2010