I know this thread is old... But for people that are looking for some simple logging by level functionality I have added basic logging levels to the default Go log package. You can find my changes here:
https://github.com/gologme/log In addition to adding Info, Warn, and Debug, users can also define their own arbitrary logging levels. Also, logging levels are enabled or disabled individually. So you can enable just Debug logs without getting Info and Warn. The enabling only impacts the new added logging levels, not the traditional Print and Fatal loggers. All of the original functionality still exists and is unchanged. Though, I did enable the ability for users to define the calldepth. Bret On Wednesday, May 13, 2015 at 2:06:48 PM UTC-6, Rob 'Commander' Pike wrote: > > Just call Output yourself with the right number. > > -rob > > > On Wed, May 13, 2015 at 12:32 PM, Christian Mauduit <uf...@ufoot.org > <javascript:>> wrote: > >> Hi all, >> >> I'm currently using log.Logger in a program >> (http://golang.org/pkg/log/#Logger), and it happens I encapsulated the >> call to Logger functions within another function. It's just a helper >> which avoids me to copy/paste sequences of similar code, I'm happy with >> it, but by doing this I always the same file/line informations popping >> in the log. Obviously I'm always calling Print or Printf from the same >> places, and having the log file full of "hey, I called you from the same >> callback than all other calls, but won't tell you who asked me to do it >> in the first place" is not helpful. >> >> Taking a look at https://github.com/golang/go/blob/master/src/log/log.go >> I see there's a calldepth passed to Output (by default, hardcoded 2) and >> was wondering wether this value could be "changeable". Typically make it >> an attribute of the class, have Calldepth and SetCalldepth to get/set >> it, and let it be user controlled that way. >> >> There are alternatives, I personnally feel any change to Print or Printf >> should be avoided at all costs (the typical function not to bloat...), I >> intuitively though storing this as a class attribute would be OK for >> most usages, but I might miss the (or some) point(s). >> >> What do you think, would I waste my time writing such a patch ? >> >> Thanks in advance and have a nice day, >> >> Christian. >> >> -- >> Christian Mauduit >> uf...@ufoot.org <javascript:> >> http://www.ufoot.org >> int q = (2 * b) || !(2 * b); >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
