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