|
No didn't realize that - thanks. The jdbm list has always been a bit goofy (it doesn't set the Reply-To header correctly).
I've applied your patch to HEAD. Those printlns definitely shouldn't have been left in there - thanks for the patch!
- K
----------------------- Original Message -----------------------
From: Chas Emerick <[email protected]>
Cc:
Date: Wed, 26 Aug 2009 10:43:11 -0400
Subject: Re: [Jdbm-general] spurious System.err.println calls?
Kevin,
Please find a patch attached. I made sure I steered clear of any of the explicitly reporting-related functionality, and only commented out what I would consider optimization/debugging printlns. (Personally, I'd just remove them entirely, but I'm trying to not step on any toes.) BTW, Kevin, do you realize you're not replying to the list? Thanks, - Chas On Aug 19, 2009, at 12:04 PM, Kevin Day wrote: > Unless any of the developers object, I am very open to this. If the > output is related to an error condition, we should be throwing > exceptions. If it's just performance printout garbage, that should > not be left in the code base. > > These calls must have been added to the code after the version that > we run in production, because we definitely don't get that sort of > output. I say: kill those lines :-) > > - K > > Kevin Day > > > ----------------------- Original Message ----------------------- > > From: Chas Emerick <[email protected]> > To: [email protected] > Cc: > Date: Tue, 18 Aug 2009 19:50:49 -0400 > Subject: [Jdbm-general] spurious System.err.println calls? > > Looks like jdbm emits a number of (what I would consider) spurious > System.err.println calls, which will just make a mess out of anyone's > log files. :-) > > This is being done in a variety of places (BaseRecordManager, > RecordFile, and Provider at the very least), leading to *lots* of > output like: > > serialization time: 14ms > deserialization time: 11ms > stickyOption:: jdbm.serializer=default > stickyOption:: jdbm.compressor=none > INFO: database exists: /Users/chas/....... > > Would a patch be accepted that eliminates such calls, or at the very > least, guards them with a DEBUG flag? > > Thanks, > > - Chas > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application codin g. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Jdbm-general mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jdbm-general > ------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________
Jdbm-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jdbm-general |
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________ Jdbm-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jdbm-general
