[Gnucash-changes] r12999 - gnucash/trunk/lib/libqof/qof - Re-enable logging for GnuCash modules that haven't explicitly set their

[Chris Shoemaker]

On Sun, Jan 29, 2006 at 12:16:23AM +0000, Neil Williams wrote:
> On Saturday 28 January 2006 11:31 pm, Chris Shoemaker wrote:
> > *sigh* And _how_ exactly is the global loglevel supposed to effect the
> > loaded module?  Am I supposed to re-call qof_log_set_level_global
> > after every time that new code might have been loaded?
> 
> If the module runs it's own init it can read the existing config for that 
> value and set that. This is a process value, not a library value. It has no 
> business being a static in the qof library. 

Um, you _do_ realize that libraries are mapped into the process's
memory space, right?

<snip>

> > It's easy for you to break the API 
> 
> I have not broken the API.
> 
> > and then say, "well, it _would_ 
> > work if you'd only do such-and-such", (which it _wouldn't_ by the
> > way
> 
> Yes it will. It does. 

Why did you cut and ignore the part where I said "Show me the code?"

> Modules that are not meant to be logged in user-land in 
> pilot-qof are now logged when the output is completely meaningless to a user.

Complete B.S.  Either:

A) you don't realize that because the variable is initialized to zero,
NOT A SINGLE message will get logged that wasn't logged before in ANY
program ANYWHERE, _or_

B) you _do_ realize this and you're just making a big stink because
you don't want people modifying qof.

Either way, you're not really instilling confidence as the would-be
maintainer of a core piece of GnuCash.

> These modules only have log macros for my benefit and for others packaging 
> the program.
> 
> > > > There is _no_
> > > > other way to globally control the logging level in the presence of
> > > > dynamically loaded code.
> > >
> > > Read the code again. Dynamically loaded code (like a module) can
> > > initialise it's own logging - you don't need global control except to
> > > control the AMOUNT of logging, not the LIST of log modules.
> >
> > Why do you think every introduction of a logging module comes with an init?
> 
> So init the log and control the amount of logging by that module later. Or if 
> global has already been called, reference your context values (outside 
> libqof) and set the level in the new init.
> 
> > > You can even call qof_log_set_level from within a test function - you
> > > lose that ability if the list is hardcoded OR assumed.
> >
> > WHAT ARE YOU TALKING ABOUT?!?!  Eeeets BARROOOKE!  I'm FIXED it.
> 
> You broke it, not me.

?!?!  Fact: Logging for all testing functions now works with my patch.
Fact: Before my patch, almost none of the logging in test functions
worked.  We _are_ talking about the 'make check' tests, right?

> 
> > Show me ONE thing that my change broke - just one.
> 
> Enabling logging for modules that have not explicitly initialised their own 
> logging.
> 
> It breaks pilot-qof and 

B.S.  Unless you use negative loglevels, this is mathematically
impossible.  Just drop the charade and get back to the _real_ reason
you're complaining: You forked QOF, and the original maintainers won't
stop developing (and fixing) it like you told 'em to.

> it breaks the API which specifically states that ONLY 
> modules that initialise their own log levels will ever be logged.

Yes, the docs described a useless global loglevel that wasn't being
used globally.  We should fix that.

> > > OK - then help me see how it should be expressed in the docs and REVERT
> > > your broken patch, please.
> >
> > I think you misunderstand.  Please try again.
> 
> This is getting nowhere. The patch is broken, please revert it. If there is 
> any misunderstanding it is in the premise behind your patch. There is nothing 
> in lib/libqof to fix to enable logging of these gnucash modules - the 
> solution lies ONLY within the code below src/

Just because you moved it from src to lib at the same time you BROKE
LOGGING FOR GNUCASH doesn't mean I'm not going to fix it in lib.
Would you be happier if I moved logging back into src and then
reverted my fix to QOF?  

Neil, I'm tired of wasting time with this, so I want to be as crystal
clear as possible:

1) I _refuse_ to stop developing QOF just because you moved it into
lib.  I may change my mind someday, but not today.

2) I am _not_ sympathetic to your self-imposed hardship of having the
same code developed in svn and where-ever else you choose to develop
your forked code-base.

3) I am somewhat leary of the prospect of shipping 2.0 with an external
QOF enabled, but I'm deferring to the consensus of developers who
don't seem as hesitant as I.

4) I will _not_ rehash this flamewar everytime I fix something in
lib/libqof.

5) Please do not interpret any future lack of my response to this
subject as approval for or agreement with your desire that GnuCash
developers stop developing in lib/libqof.

-chris