On 9/26/15 9:42 AM, Gilles wrote: > On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote: >> On 9/26/15 4:56 AM, Thomas Neidhart wrote: >>> On 09/26/2015 01:11 PM, Gilles wrote: >>>> On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote: >>>>> On 09/26/2015 02:33 AM, Gilles wrote: >>>>>> On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote: >>>>>>> On 25 September 2015 at 16:47, Gilles >>>>>>> <gil...@harfang.homelinux.org> >>>>>>> wrote: >>>>>>> >>>>>>>> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote: >>>>>>>> >>>>>>>>> On Fri, Sep 25, 2015 at 5:09 PM, Gilles >>>>>>>>> <gil...@harfang.homelinux.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote: >>>>>>>>>> On 9/25/15 7:03 AM, Gilles wrote: >>>>>>>>>>> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote: >>>>>>>>>>>> Hi Ole, >>>>>>>>>>>>> for a start, I think you are asking the wrong question. >>>>>>>>>>>>> First of all we need to agree that we want to add some >>>>>>>>>>>>> kind of >>>>>>>>>>>>> logging >>>>>>>>>>>>> facility to CM. >>>>>>>>>>>>> If the outcome is positive, there are a handful of >>>>>>>>>>>>> alternatives, >>>>>>>>>>>>> some of >>>>>>>>>>>>> them more viable than slf4j in the context of CM (e.g. >>>>>>>>>>>>> JUL or >>>>>>>>>>>>> commons-logging). >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Could someone summarize why those alternatives were >>>>>>>>>>>> deemed "more >>>>>>>>>>>> viable"? >>>>>>>>>>>> >>>>>>>>>>>> btw. the same discussion has been done for other commons >>>>>>>>>>>> >>>>>>>>>>>>> components as >>>>>>>>>>>>> well, and the result usually was: do not add logging >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> What was the rationale? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Look at the archives. We have discussed this multiple >>>>>>>>>>> times in the >>>>>>>>>>> past in [math] and each time came to the conclusion that >>>>>>>>>>> Thomas >>>>>>>>>>> succinctly states above. What has changed now? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> We also discussed several times to stick with Java 5. >>>>>>>>>> Fortunately, that has changed. [Although sticking with >>>>>>>>>> Java 7 is >>>>>>>>>> still >>>>>>>>>> a bad decision IMHO.] >>>>>>>>>> >>>>>>>>>> As for logging, IIRC, the sole argument was "no >>>>>>>>>> dependency" because >>>>>>>>>> (IIRC) of the potential "JAR hell". >>>>>>>>>> >>>>>>>>>> >>>>>>>>> that's not correct. The decision to not include any >>>>>>>>> dependencies has >>>>>>>>> nothing to do with "JAR hell". >>>>>>>>> >>>>>>>> Although I can't find it now, I'm pretty sure that I more >>>>>>>> than once >>>>>>>> got such an answer. >>>>>>>> >>>>>>>> In order to prevent JAR hell, commons components strictly >>>>>>>> stick to the >>>>>>>>> "Versioning guidelines" [1] >>>>>>>>> >>>>>>>> I can't see how it relates. >>>>>>>> But if you mean that no JAR hell can emerge from using a >>>>>>>> logging >>>>>>>> framework, >>>>>>>> then that's good news. >>>>>>>> >>>>>>>> The no-dependency rule is more related to the proposal of the >>>>>>>> component, >>>>>>>>> see [2] >>>>>>>>> >>>>>>>> Thanks for the reminder; in that document, we read: >>>>>>>> >>>>>>>> (1) Scope of the Package >>>>>>>> [...] >>>>>>>> 5. Limited dependencies. No external dependencies beyond >>>>>>>> Commons >>>>>>>> components and the JDK >>>>>>>> >>>>>>>> So we are fine if use "Log4j 2" as kindly offered by Gary. >>>>> log4j is not a commons component btw. >>>> Too bad for me. :-/ >>>> Case resolved, then, by the argument of authority? >>> I just pointed out that log4j is not a commons component and did >>> not >>> imply anything else. >>> >>>> "Commons" is OK but not another Apache project, by virtue of a >>>> document that still refers to "JDK 1.2", "CVS", "Bugzilla" (not to >>>> mention that the "scope" of CM currently goes well beyond "the >>>> most >>>> common practical problems not immediately available in the Java >>>> programming language")... >>>> >>>> What's the _technical_ rationale for accepting this dependency and >>>> not accepting that dependency? >>>> >>>>> I have not seen a single example of a useful logging message >>>>> that could >>>>> be added to commons-math, but we are already discussing which >>>>> framework >>>>> to use. >>>> If it is not useful to you, why would you conclude that it is not >>>> useful to others? >>>> >>>> At the cost of repeating myself, once more, the use-case is not >>>> primarily about debugging CM, but sometimes one could need to >>>> assess >>>> how a "non-obvious" CM algorithm responds to an application's >>>> request. >>>> I've clearly expressed that use-case in a previous message. >>>> >>>> Another example: I have a class that wraps a CM root solver; it is >>>> stuffed with log statements because the message contained in the >>>> "NoBracketingException" was utterly insufficient (and plainly >>>> misleading due the default formatting of numbers) to figure out >>>> why >>>> certain calls succeeded and others not. >>>> It's a problem (or a limitation) in the application, but in the >>>> absence of other clues, tracing the solver could help figure out a >>>> workaround. >>>> The alternative to the "logging" approach, would have been to >>>> include >>>> a precondition check before calling the solver, that would in >>>> effect >>>> duplicate the bracketing check done inside the solver. Given >>>> the vast >>>> amount of cases where the code ran smoothly, this is clearly a >>>> sub-optimal solution as compared to turning logging on and >>>> rerun the >>>> case that led to a crash. >>>> >>>> What can I say more about the usefulness (for a "low-tech" person >>>> like me) than the intro here: >>>> http://logging.apache.org/log4j/2.x/manual/index.html >>>> ? >>>> >>>>> The examples with println debugging are not valid imho, >>>>> because how do >>>>> you know in advance what you will need to log in order to >>>>> successfully >>>>> debug some piece of code and such low-level information should >>>>> not be >>>>> captured in logs anyway. >>>> Why are there several log levels? Low-level info can be routed to >>>> "DEBUG" or "TRACE". >>>> As Ole put it quite eloquently, logging is a safety net that we >>>> hope >>>> we'll never need, until we do. >>>> >>>> Each layer of an application has its own notion of what is the >>>> appropriate log level. What is "INFO" for some low-level library >>>> will very probably not be so for most applications that use the >>>> library. >>>> Setting levels per package or class takes care of that: it's the >>>> library's *user* who chooses what is useful in the current >>>> situation, >>>> not the library's developer. >>>> In the context of that asynchronous collaboration, the role of the >>>> library's developer is to carefully choose what *could* be >>>> interesting, if the need should arise. >>>> >>>> So, can we eventually discuss the _technical_ arguments against >>>> logging inside CM, rather than personal opinion? >>> again, what I want to see is an example what *should* be logged >>> in the >>> case of an algorithm. Take the LevenbergMarquardtOptimizer as an >>> example: >>> >>> * what did you log using System.out.println()? >>> * the algo computes a lot of internal data, which of these is >>> interesting for debugging problems or for general logging? >>> * there are various branches the algo can take, are just some >>> interesting to log, or all of them? >>> >>> the use-cases presented so far were mainly about debugging specific >>> problems, and I am *strongly* against adding logging information >>> just >>> for this purpose as you are clearly facing a dilemma here: >>> >>> you have to log *everything* an algo does as otherwise you >>> might miss >>> the part that creates problems >>> >>> but logging everything is not useful for a standard user of the >>> library >>> so it contradicts the original proposal to include logging >>> >>> Again, CM is not an application where you need to log what it is >>> doing, >>> but a bunch of algorithms and utility methods to perform certain >>> calculations. I fail to see the need to add logging. What could be >>> useful, and we had requests like that in the past, is to observe >>> the >>> state of a certain algorithm and to decide how to proceed in >>> certain cases. >>> >>> That is useful for users. >>> >>> Another useful addition would be to add more aggressive >>> assertions. If >>> one user encounters a problem, he/she could run the application >>> with >>> assertions enabled and spot potential problems e.g. due to wrong >>> input. >>> >>> Logging is a solution for a non existing problem imho. >>> Logging will not avoid the need to debug CM in case of problems >>> imho. >> >> +1 >> The other thing I would add is that the one place where it does make >> sense to dump text is in exception error messages, which is a place >> where I think we could really improve things. Fortunately, that is >> fairly easily done. >> >> I have seen nothing in this thread to convince me that adding >> logging in [math] will be net positive for either those of us who >> maintain the component or for users. If we are not providing clear >> exception error messages and/or APIs (with complete documentation) >> so that users can understand what they need to debug their >> applications, then we should focus on solving those problems. >> >> Phil > > First, you carefully do not reply to any of the concrete arguments > given in this thread, second you give a conclusion to an issue not > reported in this thread: exceptions and logging do not provide the > same service.
I am sorry, Gilles, but amidst all of the verbiage, I have not seen any concrete arguments showing any specific and compelling use case showing the need for logging. Somewhere above there is a reference to not being able to figure things out based on exception messages, so I mentioned that improving them could help. > > At least, I'd wish that people sharing their own opinion (it's > nothing more since _zero_ technical argument against logging have > been put forth) stop taking the collective "users" on their side. > As for *actual* users/maintainers, Ole and I have a need, while > Thomas and you haven't. Those are all the facts that exist until > now. I guess I am dense, but I still don't understand the need. Can you try to give a specific use case that says more than "I don't want to run a debugger and I need to see what the variables are?" Phil > > In such a situation, what do we do as a project; maintain the status > quo, or try for a change? > On numerous occasions over the years, the status quo was enforced; > and I don't see that it benefited the project in terms of new > contributors. > So I'm +1 for trying to change, for a change. > > > Gilles > >>> >>> Thomas >>> >>>>>>>> My long-standing mentioning of slf4j was only because of its >>>>>>>> "weightlessness" (thanks to the no-op implementation of its >>>>>>>> API). >>>>>>>> If "Log4j 2" has followed this path, good for everyone. >>>>>>>> >>>>>>>> No objection, then? >>>>>>> >>>>>>> I'm still not clear what log4j 2 adds -- most Apache java >>>>>>> projects >>>>>>> seem to >>>>>>> use log4j 1.2, seems to work well. -- H >>>>>>> >>>>>> I can only answer about "slf4j" where the "f" stands for >>>>>> facade: it's >>>>>> "only" >>>>>> an API, with bridges to several logging frameworks (log4j, >>>>>> logback, >>>>>> etc.). >>>>>> >>>>>> The separation of concerns (API vs one of several >>>>>> implementations to >>>>>> choose from) >>>>>> allows the top-level application to uniformly configure >>>>>> logging or to >>>>>> disable it >>>>>> completely (if choosing the "no-op" implementation). >>>>> That is virtually true for all logging frameworks, including >>>>> log4j, >>>>> slf4j, commons-logging. >>>> Has it always been true? >>>> I'm certainly no expert; I only try to stay clear of tools >>>> about which >>>> people complain a lot. A few years ago, that was the case of >>>> jcl and >>>> jul as compared to slf4j. >>>> >>>> >>>> Gilles >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> >>>> 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
