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. It is part of the gnucash session context (which is woefully incomplete so far but will have to be completed before libqof2 when current_session is removed). pilot-qof does this. Works fine. > > If you replicate the intentions of that list in gnucash (only), then they > > will continue to work. What QOF cannot do is assume that such a list > > exists. > > Umm. There is no list. There is no such assumption. Precisely - there was and it was removed because assumptions are bad ideas. The intentions behind the list now need to be fully expanded within gnucash, not libqof. > 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. 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. 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. > 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 it breaks the API which specifically states that ONLY modules that initialise their own log levels will ever be logged. > > 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/ -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpuv69MpznLm.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
