Yep, this is the way to go. :) Thanks!
On Wed, Jan 2, 2013 at 5:14 PM, Ted Dunning <[email protected]> wrote: > Debug-level logging is the better option. > > We should also consider replacing our dependency on slf4j-jcl with > something like slf4j-log4j or logback to make this kind of configuration > easier. > > Our libraries should generally not impose a logging framework. Our > top-level may do so since it is an application. > > > On Wed, Jan 2, 2013 at 6:47 AM, Sean Owen <[email protected]> wrote: > >> Ideally, make them debug-level log statements and then enable/disable >> them at runtime as needed. In practice that means configuring the JDK >> logger, since that's what SLF4J is using underneath (currently). I >> always have to fiddle a bit to figure out how to do it. >> >> Or: put in whatever you want for debugging and delete it / comment it >> out before committing. >> >> On Wed, Jan 2, 2013 at 2:43 PM, Dan Filimon <[email protected]> >> wrote: >> > What I'm looking for, is a way of collecting runtime stats without >> > having 2 versions of the code (one that prints it out and one that >> > doesn't). >> > How could I do this without logging? >> > >> > On Wed, Jan 2, 2013 at 4:40 PM, Ted Dunning <[email protected]> >> wrote: >> >> The normal answer is that we use slf4j. If you log at debug or info >> level, >> >> then your conditionals shouldn't be necessary. >> >> >> >> Returning the log as a stream is pretty unusual, but some high >> performance >> >> systems can't handle the overhead of even something like slf4j. >> Typically, >> >> this is because these systems need to make the decision about logging >> level >> >> somewhat after the fact ... i.e. they need to log at a substantial >> level, >> >> but only store the results if something goes wrong. >> >> >> >> I don't think that streaming k-means is in this category. >> >> >> >> On Wed, Jan 2, 2013 at 4:05 AM, Dan Filimon < >> [email protected]>wrote: >> >> >> >>> I can add a Logger as a member variable and log the progress there, or >> >>> can just to printfs (which seems really dirty). >> >>> >> >>> What's the best way of doing this? I'd prefer having the output, at >> >>> least when evaluating the quality of the code, but on the other hand >> >>> it'd be nice to disable logging when running in production. >> >>> >> >>> I'm thinking of adding Logger progressLogger and a boolean >> >>> enableLogging variables to the algorithm classes to control this. >> >>> >> >>> But then, it'd also be nice to return the log as a stream when the >> >>> algorithm is done. So, there'd be a getLog() method. >> >>> >>
