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
