Oughtn't there be an option to have logging for developers? If you'd like to use it, feel free; if not, don't. Including log4j (or slf or commons-logging, so on) doesn't add too much weight to the jar -- one file, a small properties file, and 4-lines in the pom file. If there is interest, I can submit a patch adding log4j and log4j.properties to JIRA. Let me know? -- H
On 25 September 2015 at 16:26, Gilles <gil...@harfang.homelinux.org> wrote: > On Fri, 25 Sep 2015 13:06:43 -0700, Phil Steitz wrote: > > I say something like: "I had to fork some CM class to insert > log statements." > You say something like: "No, you don't; write test or inspect > the code." > > You had been more constructive: > http://markmail.org/thread/a5jl6fkjjtm5qbsw > > Even if Ole may have picked the wrong example with Tomcat, the > actual request is to be able to follow the execution of a fairly > complex algorithm, like an optimizer, when applied to a fairly > complex user's code, in order to figure out whether there is a > problem; and if so, where it is (in the user's model, in the > call, in the optimizer, whether there is a mismatch between the > user's expectations and the capability of the selected algorithm, > etc.) > > Ole's first example with an excerpt of the Levenberg-Marquardt > implementation is actually a hit: a few years ago, a bug was found > somewhere right around that same code: > https://issues.apache.org/jira/browse/MATH-406 > It's an example where logging is a valuable help in debugging. > Another is the poor man's logging fiddling to track the cause of > the erratic behaviour of one of the CI machines. > > Gilles > > > On 9/25/15 11:01 AM, Ole Ersoy wrote: >> >>> >>> >>> On 09/25/2015 11:34 AM, Phil Steitz wrote: >>> >>>> I disagree. Good tests, API contracts, exception management and >>>> documentation can and should eliminate the need for cluttering >>>> low-level library code with debug logging. >>>> >>> >>> Logging could be viewed as clutter. Constructed the right way, >>> the logging statements could also be viewed as comments. >>> >>> I agree that good tests, API contracts, and in general keeping the >>> design as minimalistic and simple as possible should be the first >>> criteria to review before introducing logging. When the code is >>> trivial I leave logging out, unless I need to put in a few >>> statements in order to track collaboration between components in >>> an algorithm. >>> Other times the method is as simple as it gets and I have to have >>> logging. For example take the LevenbergMarquardtOptimizer >>> optimize() method. It's atomic in the sense that what's in the >>> method belongs in the method. There are several loops within the >>> main loop, etc. and tracking what's going, even with a observer >>> being notified on each increment, would be far from elegant. >>> >> >> Why, exactly do you need to "track what is going on?" If you need >> to do that as a user of the code, some kind of listener or API to >> give you the information that you need is appropriate. Dumping text >> to an external resource to "solve" this usually indicates smelliness >> somewhere - either in the library API or the client code. >> >> >>> For example perhaps we want to see what's going on with the >>> parameters in this small (5% of the method size) section of code: >>> >> >> What parameters and where did they come from? If from the client, >> the client can validate them. If the library needs to validate or >> confirm suitability, then it should do that in code or via tests. >> >>> >>> // compute the scaled predicted reduction >>> // and the scaled directional derivative >>> for (int j = 0; j < solvedCols; ++j) { >>> int pj = permutation[j]; >>> double dirJ = lmDir[pj]; >>> work1[j] = 0; >>> for (int i = 0; i <= j; ++i) { >>> work1[i] += weightedJacobian[i][pj] * dirJ; >>> } >>> } >>> >>> If there is something wrong with this in production, the shortest >>> path to figuring that out is reviewing a trace. The longer path >>> is to stop the server. Grab the data. Open up a debugger. Run >>> the data. >>> >>> If we wanted to observe this section of code the observer would be >>> looking at sub loops of of the optimize method. So that's doable, >>> but it creates an interface design for the observer that's >>> cluttered with events corresponding to various low level algorithm >>> details. >>> >>> >>> Several times, I've been obliged to create a modified version of CM >>>>> to introduce "print" statements (poor man's logging!) in order to >>>>> figure out why my code did not do what it was supposed to. >>>>> >>>> >>> It's pretty tragic that anyone of us should have to do this. It's >>> also wasteful, because if Gilles has to do this, then there's a >>> good chance that others have to do it to. The reason Tomcat logs >>> at various levels is so that we can see what's going on in >>> production and track down bugs. >>> >> >> No. Have a look at the Tomcat logging code. It is mostly >> initialization, shutdown and exceptions or warnings. This is >> necessary because tomcat is a container - there is no client >> application to catch exceptions or get API results back. The analog >> for the kind of instrumentation you are proposing inside [math] >> would be like tomcat larding itself up with debug logging throughout >> the request processing lifecycle, which it does not do. It is a >> bad analogy in any case, because Tomcat is a container, which is 2 >> big steps up the processing chain from a low-level library. >> >> Phil >> >> Lets become one with the logging and make it into something that >>> strengthens both code integrity and comprehensibility. Everyone >>> take take out your Feng Shui mat and do some deep breathing right >>> now. >>> >>> Here again, tests, good design, code inspection are the way to go in >>>> low-level components. I have also spent a lot of time researching >>>> bugs in [math], other Commons components and other complex systems. >>>> My experience is a little different: excessive logging / debug code >>>> for code that contains it often just tends to get in the way, >>>> >>> It's a very good point. Sometimes we come across logging >>> statements that are just noise. Given how rigorous we are about >>> reviewing everything though, I think a win win would be to limit >>> the noise during code review, and pledge not to "Call our mom" in >>> the middle of the code, etc. >>> >>> especially after it has rotted a bit. Rather than adding more code >>>> to maintain so that you can have less conceptual control over the >>>> functional code, it is better, IMNSHO, to focus on making the >>>> functional code as simple as possible with clean well-documented, >>>> test-validated API contracts. >>>> >>> >>> Totally agree. I think this should be the first priority, and >>> that logging should be used when there are no simple clean >>> alternatives. >>> >>> >>>> It also makes a code easier to debug while developing or >>>>> modifying it >>>>> (without resorting to poor man's logging, then deleting the >>>>> "print", >>>>> then reinstating them, then deleting them again, ad nauseam). >>>>> >>>> Pretty sure we have all been here. >>> >>> Cheers, >>> - Ole >>> >>> >>> >>>>> Gilles >>>>> >>>>> [1] No quality or complexity judgment implied. >>>>> >>>>> Phil >>>>>> >>>>>>> >>>>>>> Gilles >>>>>>> >>>>>>> Thomas >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ole.er...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>>> >>>>>>>>> We have been discussing various ways to view what's happening >>>>>>>>> internally >>>>>>>>> with algorithms, and the topic of including SLF4J has come up. >>>>>>>>> I know that >>>>>>>>> this was discussed earlier and it was decided that CM is a low >>>>>>>>> level >>>>>>>>> dependency, therefore it should minimize the transitive >>>>>>>>> dependencies that >>>>>>>>> it introduces. The Java community has adopted many means of >>>>>>>>> dealing with >>>>>>>>> potential logging conflicts, so I'm requesting that we use >>>>>>>>> SLF4J >>>>>>>>> for >>>>>>>>> logging. >>>>>>>>> >>>>>>>>> I know that JBoss introduced its own logging system, and this >>>>>>>>> made me a >>>>>>>>> bit nervous about this suggestion, so I looked up strategies >>>>>>>>> for >>>>>>>>> switching >>>>>>>>> their logger out with SLF4J: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The general process I go through when working with many >>>>>>>>> dependencies that >>>>>>>>> might use commons-logging instead of SLF4J looks something like >>>>>>>>> this: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> With JDK9 individual modules can define their own isolated >>>>>>>>> set of >>>>>>>>> dependencies. At this point the fix should be a permanent. If >>>>>>>>> someone has >>>>>>>>> has a very intricate scenario that we have not yet seen, they >>>>>>>>> could use >>>>>>>>> (And probably should use) OSGi to isolate dependencies. >>>>>>>>> >>>>>>>>> WDYT? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> - Ole >>>>>>>>> >>>>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> . >>>>> >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- OpenPGP: https://hasan.d8u.us/gpg.key Sent from my mobile device Envoyé de mon portable
