gnc-trace module numbers

Tue Sep 27 05:17:16 EDT 2005

On Tuesday 27 September 2005 3:34 am, David Hampton wrote:
> > > Make gnc_log_modules (which is probably best as just a default) into a
> > > setup call for a GHashTable and dump gncModuleType altogether?
> >
> > Sure, that'd work.  Probably best to have module identifiers be strings
> > rather than numeric values (ints or shorts or whatever).
>
> Agreed.  Numeric values require coordination between applications.

I was hoping I could use strings instead of int!
:-)

I didn't suggest it initially in case there was a problem changing so many 
lines in so many files.

However, that's a change in the API and although gnotime doesn't use logging, 
pilot-qof does. I can (I think) sort that out so that the new mechanism gets 
into QOF 0.6.0. I've got pilot-qof 0.0.6 which will sort out the problem. I'm 
doing this only because the use of an integer type for this module is 
restrictive and it could be seen as a bug because it prevents non-GnuCash 
applications from using logging as intended. (Which is probably why GnoTime 
doesn't use it!)

> > But why does QOF need to reimplement a logging solution?  What about
> > using glib's logging instead?  Or log4c?
>
> I read Neil's question as one of what to log, not how to log.

Correct. All the existing mechanisms for logging will remain, all I want is 
that the decision on how to *select* / identify the sections to log becomes 
less specific to GnuCash.

It's only the identifiers that need to change but the easiest way to do that 
is to replace the gncModuleType enum (which is hard to extend) with a 
GHashTable.

> How to 
> log is clearly the g_log functions from glib that gnucash already uses.

Yes. 

The ENTER, PWARN etc. macros will be unchanged in substance and usage.

gnc_should_log will change to accept a char* instead of int as well as 
changing internally to lookup the hashtable instead of dereferencing the 
enum.

One bit of information I do need:

In G2, where is the equivalent section of code to this in CashUtil:

                gnc_set_logfile(f);
                gnc_log_init();
                gnc_set_log_level(MOD_BACKEND, GNC_LOG_DETAIL);
                gnc_set_log_level(MOD_ENGINE, GNC_LOG_DETAIL);
                gnc_set_log_level(MOD_IO, GNC_LOG_DETAIL);

I know it's not defined static like that and that gnucash can use command line 
options to specify the modules and log detail, I'm hoping it's not in the 
Scheme!

The reason is that normally when a GHashTable is initialised, the contents are 
NULL. This would mean that no modules would be pre-selected - only FATAL 
macros would generate log entries.

Log detail would be set at zero if not specified, which would set 
GNC_LOG_FATAL. That's OK because if someone wants debug output but doesn't 
set the level of detail to log, they shouldn't be expecting more than the 
most basic amount of log detail. Fatal hardly logs anything (hopefully).

At distribution / packaging time, do we want default logs? If so, which 
modules and to which level of detail? I'd rather implement those as 
gnc_set_log_level calls as in cashutil - gnc-trace itself should start with a 
completely blank canvas.

Are we happy to use only these two methods:
1. Use the gnucash command line to set your debug detail needs, and/or
2. Use gnc_set_log_level for all module selection requirements, runtime and 
development? (You can always call gnc_set_log_level from your own code if you 
want to temporarily add debug output or change the level during development.)

(The command line option only sets the log detail level, it doesn't currently 
change the selection of modules that are logged.)

I could add a function that provides a list or a foreach over known 
log_modules. Useful? (I may use it in pilot-qof to provide finer control over 
debug output - specifying which modules to log from the --debug option.)

We also need somewhere to place the #defines so that e.g. MOD_BACKEND still 
exists (as GNC_MOD_BACKEND or QOF_MOD_BACKEND, depending on the file.)

QOF_ prefix log_module strings would be part of the QOF API exposed via qof.h

#define GNC_MOD_BACKEND "gnc_backend"

needs to be in a header file so that multiple source files can all be logged 
as "the backend".

in each file:
static const char* module = GNC_MOD_BACKEND;

That header file can't be a QOF file (or we're back to square one) it needs to 
be a GnuCash header file. gnc-engine.h ? Only default modules would need to 
be listed - with this new method you can create arbitrary modules in the 
source and log them with or without reference to code outside the current  
directory. That cuts out one compile cycle - no need to recompile src/engine 
just to add or change a log_module.

All GnuCash log_modules should use a GNC_ prefix to their #defines and a gnc- 
prefix to the log_module string itself.

QOF would then have it's own log modules available via qof.h:
(namespaced for clarity)
QOF_MOD_BACKEND - qofbackend.c|h 
QOF_MOD_MERGE
QOF_MOD_QSF etc.

#define QOF_MOD_BACKEND "qof-backend"

GnoTime can use gttr, cashutil - cu, pilot-qof - pq.

The downside with all this is that the *list* of available log modules gets 
split into lots of files. That's inevitable with QOF being spun out but it 
may be preferable to only have two files: a list of all GnuCash-specific 
default log modules and a list of all QOF-only default log modules.

We also end up with more available log modules too.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050927/8a798ef4/attachment.bin