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

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Neil Williams-2
On Saturday 28 January 2006 5:17 pm, Chris Shoemaker wrote:
> Author: chris
> Modified:
>    gnucash/trunk/lib/libqof/qof/qoflog.c
> Log:
>    Re-enable logging for GnuCash modules that haven't explicitly set their
>    own levels.

Chris, the API for this is qof_log_set_global - please don't mess up the
log_check function because this breaks pilot-qof behaviour!

I would like this patch reverted and a call to qof_log_set_global set in
gnucash-bin.c (or somewhere else that is gnucash-specific).

Call qof_log_set_level_global to a default level and then set selected modules
to higher or lower levels.

If modules aren't being logged, it is not up to QOF to overrule the process.

> +static QofLogLevel global_default_loglevel = 0;

Incompatible with pilot-qof and other qof programs which ONLY enable --debug
when the option is explicitly added to the command line.

QOF does not log anything unless explicitly requested to do so. It must remain
so.

> - /* if log_module not found, do not log. */

This is the API.

I cannot accept this patch into QOF in this form.

--

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


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Chris Shoemaker
On Sat, Jan 28, 2006 at 06:02:55PM +0000, Neil Williams wrote:

> On Saturday 28 January 2006 5:17 pm, Chris Shoemaker wrote:
> > Author: chris
> > Modified:
> >    gnucash/trunk/lib/libqof/qof/qoflog.c
> > Log:
> >    Re-enable logging for GnuCash modules that haven't explicitly set their
> >    own levels.
>
> Chris, the API for this is qof_log_set_global - please don't mess up the
> log_check function because this breaks pilot-qof behaviour!

Neil, please read the code.  
1) qof_log_set_global doesn't exist.
2) qof_log_set_level_global does.
3) This patch actually changes qof_log_set_level_global, so I
obviously know about it.

> I would like this patch reverted and a call to qof_log_set_global set in
> gnucash-bin.c (or somewhere else that is gnucash-specific).

Umm, it's already been in gnucash-bin.c for quite a while.  It doesn't
do what you think it does.

> Call qof_log_set_level_global to a default level and then set selected modules
> to higher or lower levels.
>
> If modules aren't being logged, it is not up to QOF to overrule the process.
>
> > +static QofLogLevel global_default_loglevel = 0;
>
> Incompatible with pilot-qof and other qof programs which ONLY enable --debug
> when the option is explicitly added to the command line.

No, it's not incompatible with anything.

>
> QOF does not log anything unless explicitly requested to do so. It must remain
> so.
>
> > - /* if log_module not found, do not log. */
>
> This is the API.

That's broken.

> I cannot accept this patch into QOF in this form.

Logging is important for debugging.  FTR, you *BROKE* GnuCash's
logging facility when you decided to move it into libqof.  You had
plenty of time to fix it and you apparently don't care.  I'm *FIXING*
what you broke in a way that's completely compatible with your
intentions, even though I don't agree with your intentions.

If you break things and then tell people "This code is mine now.
Don't fix it" you're going to annoy a lot people.  

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

Neil Williams-2
On Saturday 28 January 2006 6:58 pm, Chris Shoemaker wrote:
> > Chris, the API for this is qof_log_set_global - please don't mess up the
> > log_check function because this breaks pilot-qof behaviour!
>
> Neil, please read the code.
> 1) qof_log_set_global doesn't exist.
> 2) qof_log_set_level_global does.

OK, typo in the email. Sorry.

> 3) This patch actually changes qof_log_set_level_global, so I
> obviously know about it.

Why should QOF support logging of modules that aren't explicitly set to log?

If a module is has no log level it should be completely ignored. Just because
it uses ENTER(" ") and has a QofLogModule declared static, why must it always
be set to log whenever qof_log_set_level_global is called?

> > I would like this patch reverted and a call to qof_log_set_global set in
> > gnucash-bin.c (or somewhere else that is gnucash-specific).
>
> Umm, it's already been in gnucash-bin.c for quite a while.  It doesn't
> do what you think it does.

It enables logging for modules that have not had their log levels set - it is
exactly what I didn't want. Mea culpa for not making that clear in the docs.

> > Incompatible with pilot-qof and other qof programs which ONLY enable
> > --debug when the option is explicitly added to the command line.
>
> No, it's not incompatible with anything.

It is, if a module has no log level set, it should be ignored by all log
requests. This allows finer control over logging during debugging. There are
lots and lots of files that are not being logged but which could be useful to
log only within a debugging environment - i.e. by us.

When it comes to the release, then the number of modules can be scaled down
without massive changes to the source code (e.g. removing all ENTER(" ")
macros).

There are also a large number of files that simply use GNC_MOD_GUI for their
log identification which is wasteful and cumbersome. By differentiating
between those log modules that are important at a user level and those that
are only useful in svn builds, I hoped to extend the previous usage.

I'm usually accused of being over-verbose but I accept that I did not make
this clear at the time.

> > QOF does not log anything unless explicitly requested to do so. It must
> > remain so.
> >
> > > - /* if log_module not found, do not log. */
> >
> > This is the API.
>
> That's broken.

No, but maybe it's not documented clearly.
:-(

qof_log_set_level_global only operates on those log modules that are already
defined in the hash table. qof_log_set_level_global is for changing the level
of all *known* modules in one call - not setting the level of all *available*
modules even if they have not explicitly set a log level of their own.

My intention is for other processes to mimic the qof_log_set_default type call
in their own code to set the _user_level_ debug output modules - i.e. those
that produce verbose and intelligible debug output that may be of some use to
moderately advanced users.

Other files that produce lots of %p type output or describe detailed internal
errors can be left defined for us to use but leave ignored at release time.

Doing that would require changing only one or two lines of code - e.g. if
there was a gnc_log_set_gui_default() and gnc_log_set_register_default() then
we could also have a gnc_log_set_debug() which could be commented out prior
to release. Otherwise, it requires removing all the log macros and the
QofLogModule static.

At present, pilot-qof does have these modules and I don't want them logged for
real users, even in the debug output.

Equally, I don't want to make these modules use DEBUG, DETAIL or TRACE because
these are simply too verbose.

> > I cannot accept this patch into QOF in this form.
>
> Logging is important for debugging.  FTR, you *BROKE* GnuCash's
> logging facility when you decided to move it into libqof.  You had
> plenty of time to fix it and you apparently don't care.

I do care. (Been v.busy with paid employment due to sickness of various
co-workers).

I hoped to make debugging easier by allowing more fine control over exactly
which modules get logged.

> I'm *FIXING*
> what you broke in a way that's completely compatible with your
> intentions, even though I don't agree with your intentions.

Not sure - I don't think qof_log_set_level_global should even know about
modules that have not already set a log level.

I'll fix the docs first.

> If you break things and then tell people "This code is mine now.
> Don't fix it" you're going to annoy a lot people.

Not my intention, I merely want to preserve behaviour in the other programs
that use the API.

I apologise for not keeping the docs in line with my upstream usage.

--

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


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Neil Williams-2
In reply to this post by Chris Shoemaker
Actually, it was in the docs all along:
http://cvs.gnucash.org/docs/HEAD/group__Trace.html#ga7
void qof_log_set_level_global   (   QofLogLevel   level    )
     
   Set the logging level for all known log_modules.
Note: Unless a log_module has been registered using qof_log_set_level, it will
be unaffected by this change.

http://cvs.gnucash.org/docs/HEAD/group__Trace.html#ga14
void qof_log_module_foreach   (   QofLogCB   cb,
  gpointer   data
  )
     
   Iterate over each known log_module
 Only log_modules with log_levels set will be available.

http://cvs.gnucash.org/docs/HEAD/group__Trace.html#ga15
gint qof_log_module_count   (   void    )
     
   Number of log_modules registered


What that all means is that the API was not broken when it moved to libqof,
just clarified.

Where before there was an assumption (based on the explicit list of defined
modules in gnc-trace.h) that everything listed was logged - QOF now makes it
explicit that we start with a clean slate each time. You decide which modules
you want logged - QOF makes no such assumptions. Chris, your patch
reintroduces this assumption by the backdoor and undermines the API. Did you
look at the Doxygen output? Is it unclear? I'll gladly enhance the
documentation if you don't find it sufficiently useful.

Note that even with gnc-trace.h, if a module was not listed in the hardcoded
list, it was also ignored.

Instead of changing gnc-trace all the time, the API allows a more flexible
approach that automatically keeps what we had from the old lists synchronised
AND ensures that any new module can be defined for logging WITHOUT any
changes to any file below lib/libqof.

This was an essential step in the use of QOF outside gnucash because the hard
coded list was completely irrelevant for any non-gnucash process.

I accept I did not post to the list about the removal of this assumption -
instead I did clearly document the results in the Doxygen output by making it
explicit in the qoflog.h file.

Please, Chris, can we revert your change and ditch the assumption?

If there are issues you want clarified in the docs, I'll gladly do that, but
this patch is just plain wrong.

--

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


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Chris Shoemaker
On Sat, Jan 28, 2006 at 09:17:51PM +0000, Neil Williams wrote:
> Actually, it was in the docs all along:
> http://cvs.gnucash.org/docs/HEAD/group__Trace.html#ga7
> void qof_log_set_level_global   (   QofLogLevel   level    )
>      
>    Set the logging level for all known log_modules.
> Note: Unless a log_module has been registered using qof_log_set_level, it will
> be unaffected by this change.

Think about this.  _When_ is this function supposed to be called?

>
> http://cvs.gnucash.org/docs/HEAD/group__Trace.html#ga14
> void qof_log_module_foreach   (   QofLogCB   cb,
>   gpointer   data
>   )
>      
>    Iterate over each known log_module
>  Only log_modules with log_levels set will be available.
>
> http://cvs.gnucash.org/docs/HEAD/group__Trace.html#ga15
> gint qof_log_module_count   (   void    )
>      
>    Number of log_modules registered
>
>
> What that all means is that the API was not broken when it moved to libqof,
> just clarified.

The docs are clear that the API is broken.  Setting a global level
that has no effect on logging modules you don't explicitly register
MAKES ZERO SENSE!  It's USELESS!

> Where before there was an assumption (based on the explicit list of defined
> modules in gnc-trace.h) that everything listed was logged - QOF now makes it
> explicit that we start with a clean slate each time. You decide which modules
> you want logged - QOF makes no such assumptions. Chris, your patch
> reintroduces this assumption by the backdoor and undermines the API. Did you
> look at the Doxygen output? Is it unclear? I'll gladly enhance the
> documentation if you don't find it sufficiently useful.
>
> Note that even with gnc-trace.h, if a module was not listed in the hardcoded
> list, it was also ignored.

Ah, but they _were_ listed and they all WORKED.  You're breaking
things and making GnuCash _harder_ to debug with changes that aren't
even a good idea.  The logging system _needs_ to work.

> Instead of changing gnc-trace all the time, the API allows a more flexible
> approach that automatically keeps what we had from the old lists synchronised
> AND ensures that any new module can be defined for logging WITHOUT any
> changes to any file below lib/libqof.
>
> This was an essential step in the use of QOF outside gnucash because the hard
> coded list was completely irrelevant for any non-gnucash process.
>
> I accept I did not post to the list about the removal of this assumption -
> instead I did clearly document the results in the Doxygen output by making it
> explicit in the qoflog.h file.
>
> Please, Chris, can we revert your change and ditch the assumption?

No.  The assumption is sane and GnuCash depends on it.  There is _no_
other way to globally control the logging level in the presence of
dynamically loaded code.  

BTW, notice that the only way you could have kept GnuCash's logging
system working with this broken API would have been to collect all the
used logging modules into one place and register them before setting
the global level, which would have basically been trading the
gnc-trace.h for a bunch of function calls.  Not smart.

If anything should be reverted it's the commit that originally broke
the logging.  If you want to try to drastically change the way
gnucash's logging system works I suggest that you make your proposal
to gnucash-devel, build some consensus, and respond to constructive
criticism.

Your breaking things by making major changes with no approval is bad
enough.  Complaining when people fix things is BAD FORM.

> If there are issues you want clarified in the docs, I'll gladly do that, but
> this patch is just plain wrong.

The docs do need to be updated - to reflect this change.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

Neil Williams-2
On Saturday 28 January 2006 9:53 pm, Chris Shoemaker wrote:
> >    Set the logging level for all known log_modules.
> > Note: Unless a log_module has been registered using qof_log_set_level, it
> > will be unaffected by this change.
>
> Think about this.  _When_ is this function supposed to be called?

To modify the log levels _after_ initial (hard-coded) setup. The debug option
simply moderates the level of debugging of the modules identified as being
logged. This is exactly as it was before - global never did initialise the
modules for logging, that was done by the assumption in the lists. Global
simply moderated the AMOUNT of logging by tweaking the loglevel of each
module in the assumed list. It still does that, without the assumption.

1. Developers enter debug macros, ENTER(" "), LEAVE (" ");
2. Developers call qof_log_set_level wherever it is needed to initialise this
module for logging later.
3. Users set the amount to log by specifying --debug and/or specifying a debug
integer level. (Developers are free to add a default OUTSIDE lib/libqof)
4. If it's a dynamic module, put the  qof_log_set_level call in the init
function so that you don't need to include the #define from the header
anywhere else, you get logging if it's loaded and it's ignored if it is not.

> > What that all means is that the API was not broken when it moved to
> > libqof, just clarified.
>
> The docs are clear that the API is broken.

Nope. If the docs are unclear, I'll fix them but the API was fine until you
broke it.

> Setting a global level
> that has no effect on logging modules you don't explicitly register
> MAKES ZERO SENSE!  It's USELESS!

It's absolutely logical and sensible - plus it's flexible, scalable and
generic. We cannot hardcode modules into QOF, neither can we assume that such
lists of modules exist.

gnucash has to define those lists itself and the simplest way of doing that is
to keep a list of those modules in a function that initialises them for
logging. The --debug option can then accept an integer value that scales that
logging up through the levels.

You initialise this in the main init code, then you use global to moderate the
level at which those initialised modules are actually logged, should the user
require a different level of logs.

At no point did global actually initialise the list of modules - it simply
read the hard-coded assumption. This assumption had to die and it has. Global
still does what it did before - changes the log level for each registered
module in one call. The init was separate and is separate.

> > Note that even with gnc-trace.h, if a module was not listed in the
> > hardcoded list, it was also ignored.
>
> Ah, but they _were_ listed and they all WORKED.

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.

> You're breaking
> things and making GnuCash _harder_ to debug with changes that aren't
> even a good idea.  The logging system _needs_ to work.

It does work, when you setup the list to be logged - just as you had to with
the gnc-trace headers. It's just that this way it's more flexible and easier
to add new modules. (Because you can call qof_log_set_level anywhere in the
codebase.)

> > This was an essential step in the use of QOF outside gnucash because the
> > hard coded list was completely irrelevant for any non-gnucash process.
> >
> > I accept I did not post to the list about the removal of this assumption
> > - instead I did clearly document the results in the Doxygen output by
> > making it explicit in the qoflog.h file.
> >
> > Please, Chris, can we revert your change and ditch the assumption?
>
> No.  The assumption is
false

> sane and GnuCash depends on it.

Sorry, it does not. It cannot. Assumptions are BAD.

> 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.

In the init function for the dynamic code, put a call to qof_log_set_level -
easy. If the module is loaded, it's setup for logging. If it's not, nobody
cares.

> BTW, notice that the only way you could have kept GnuCash's logging
> system working with this broken API would have been to collect all the
> used logging modules into one place and register them before setting
> the global level, which would have basically been trading the
> gnc-trace.h for a bunch of function calls.  Not smart.

No, that was simply a shorthand method for the base level modules. You can
call qof_log_set_level anywhere you like. Feel free to move all those to more
relevant places if you need to do so. The shorthand was a temporary measure
that was useful during the transition.

You can even call qof_log_set_level from within a test function - you lose
that ability if the list is hardcoded OR assumed.

> If anything should be reverted it's the commit that originally broke
> the logging.  If you want to try to drastically change the way
> gnucash's logging system works I suggest that you make your proposal
> to gnucash-devel, build some consensus, and respond to constructive
> criticism.

I am responding - but the problem is that you're stuck on this false
assumption that will bite.

> Your breaking things by making major changes with no approval is bad
> enough.  Complaining when people fix things is BAD FORM.

You haven't fixed it, you've broken it.

It was fine before your patch - any lack of logging in gnucash was down to:
a) my lack of time to revisit the shorthand list
b) your misunderstanding of the API, without the assumption.

> > If there are issues you want clarified in the docs, I'll gladly do that,
> > but this patch is just plain wrong.
>
> The docs do need to be updated - to reflect this change.

OK - then help me see how it should be expressed in the docs and REVERT your
broken patch, please.

--

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


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Chris Shoemaker
On Sat, Jan 28, 2006 at 10:40:36PM +0000, Neil Williams wrote:

> On Saturday 28 January 2006 9:53 pm, Chris Shoemaker wrote:
> > >    Set the logging level for all known log_modules.
> > > Note: Unless a log_module has been registered using qof_log_set_level, it
> > > will be unaffected by this change.
> >
> > Think about this.  _When_ is this function supposed to be called?
>
> To modify the log levels _after_ initial (hard-coded) setup. The debug option
> simply moderates the level of debugging of the modules identified as being
> logged. This is exactly as it was before - global never did initialise the
> modules for logging, that was done by the assumption in the lists. Global
> simply moderated the AMOUNT of logging by tweaking the loglevel of each
> module in the assumed list. It still does that, without the assumption.
>
> 1. Developers enter debug macros, ENTER(" "), LEAVE (" ");
> 2. Developers call qof_log_set_level wherever it is needed to initialise this
> module for logging later.
> 3. Users set the amount to log by specifying --debug and/or specifying a debug
> integer level. (Developers are free to add a default OUTSIDE lib/libqof)
> 4. If it's a dynamic module, put the  qof_log_set_level call in the init
> function so that you don't need to include the #define from the header
> anywhere else, you get logging if it's loaded and it's ignored if it is not.

*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 you still think the API isn't broken then maybe the only way you'll
understand this is if you try to restore the logging functionality in
GnuCash.  Go for it.

> > > What that all means is that the API was not broken when it moved to
> > > libqof, just clarified.
> >
> > The docs are clear that the API is broken.
>
> Nope. If the docs are unclear, I'll fix them but the API was fine until you
> broke it.
>
> > Setting a global level
> > that has no effect on logging modules you don't explicitly register
> > MAKES ZERO SENSE!  It's USELESS!
>
> It's absolutely logical and sensible - plus it's flexible, scalable and
> generic. We cannot hardcode modules into QOF, neither can we assume that such
> lists of modules exist.
>
> gnucash has to define those lists itself and the simplest way of doing that is
> to keep a list of those modules in a function that initialises them for
> logging. The --debug option can then accept an integer value that scales that
> logging up through the levels.
>
> You initialise this in the main init code, then you use global to moderate the
> level at which those initialised modules are actually logged, should the user
> require a different level of logs.
>
> At no point did global actually initialise the list of modules - it simply
> read the hard-coded assumption. This assumption had to die and it has. Global
> still does what it did before - changes the log level for each registered
> module in one call. The init was separate and is separate.
>
> > > Note that even with gnc-trace.h, if a module was not listed in the
> > > hardcoded list, it was also ignored.
> >
> > Ah, but they _were_ listed and they all WORKED.
>
> 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.

> > You're breaking
> > things and making GnuCash _harder_ to debug with changes that aren't
> > even a good idea.  The logging system _needs_ to work.
>
> It does work, when you setup the list to be logged - just as you had to with
> the gnc-trace headers. It's just that this way it's more flexible and easier
> to add new modules. (Because you can call qof_log_set_level anywhere in the
> codebase.)

It's easy for you to break the API and then say, "well, it _would_
work if you'd only do such-and-such", (which it _wouldn't_ by the
way).  I'm saying, "it worked before, you broke it, it works again."
If you have a better solution for making it work, let's see the code.
Until then, we need logging to _work_.

> > > This was an essential step in the use of QOF outside gnucash because the
> > > hard coded list was completely irrelevant for any non-gnucash process.
> > >
> > > I accept I did not post to the list about the removal of this assumption
> > > - instead I did clearly document the results in the Doxygen output by
> > > making it explicit in the qoflog.h file.
> > >
> > > Please, Chris, can we revert your change and ditch the assumption?
> >
> > No.  The assumption is
>
> false
>
> > sane and GnuCash depends on it.
>
> Sorry, it does not. It cannot. Assumptions are BAD.

Assumptions are why you use an API.  You assume it works.  It's not
bad.  It's a convenient substitute for doing everything yourself.

> > 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?

> In the init function for the dynamic code, put a call to qof_log_set_level -
> easy. If the module is loaded, it's setup for logging. If it's not, nobody
> cares.
>
> > BTW, notice that the only way you could have kept GnuCash's logging
> > system working with this broken API would have been to collect all the
> > used logging modules into one place and register them before setting
> > the global level, which would have basically been trading the
> > gnc-trace.h for a bunch of function calls.  Not smart.
>
> No, that was simply a shorthand method for the base level modules. You can
> call qof_log_set_level anywhere you like. Feel free to move all those to more
> relevant places if you need to do so. The shorthand was a temporary measure
> that was useful during the transition.
>
> 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.  

> > If anything should be reverted it's the commit that originally broke
> > the logging.  If you want to try to drastically change the way
> > gnucash's logging system works I suggest that you make your proposal
> > to gnucash-devel, build some consensus, and respond to constructive
> > criticism.
>
> I am responding - but the problem is that you're stuck on this false
> assumption that will bite.
>
> > Your breaking things by making major changes with no approval is bad
> > enough.  Complaining when people fix things is BAD FORM.
>
> You haven't fixed it, you've broken it.

Show me ONE thing that my change broke - just one.
 

> It was fine before your patch - any lack of logging in gnucash was down to:
> a) my lack of time to revisit the shorthand list
> b) your misunderstanding of the API, without the assumption.
>
> > > If there are issues you want clarified in the docs, I'll gladly do that,
> > > but this patch is just plain wrong.
> >
> > The docs do need to be updated - to reflect this change.
>
> 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.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

Neil Williams-2
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/


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [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
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

Neil Williams-2
On Sunday 29 January 2006 2:07 am, Chris Shoemaker wrote:
> On Sun, Jan 29, 2006 at 12:16:23AM +0000, Neil Williams wrote:
> > 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?

Yes, but that's no reason to have a default value in the library that enables
logging where the module has NOT explicitly done so.

> > 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:

No - modules that have not explicitly set their log level are NOT to be
logged, anyway, anyhow. Set the explicit log level and THEN work on them.

> 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_

Wrong. Your modification to qof_log_check means that even if a module is NOT
listed in the hashtable, the check returns TRUE even if loglevel is zero.
That's plain wrong. Only modules in the hashtable should be logged. There can
be no else{} statement. Zero is not "do not log", zero is GNC_LOG_FATAL which
still results in some logging.

Your modification means that qof_log_check returns true every time for
GNC_LOG_FATAL and that simply isn't acceptable.

If         log_string = (gchar*)g_hash_table_lookup(log_table, log_module);
returns non-NULL, then we can test if the loglevel is sufficient. When it
returns NULL, log_check MUST return FALSE.

I cannot accept this modification:
        /* if log_module not found, use default. */
it is simply wrong. There can be no default in the library, only in the
application, if you want it.

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

Not true. I didn't appreciate your last change that happened days after the
release, despite me highlighting the imminent release here a few days before.
I have nothing against modification of qof - those changes will be in the
next release - I DO have a problem with patches that override the API for the
sole benefit of one program.

> ?!?!  Fact: Logging for all testing functions now works with my patch.

test code can simply call qof_log_set_level for whichever modules it needs -
the macros can be copied if you'd rather not include the remote header file.

> Fact: Before my patch, almost none of the logging in test functions
> worked.  We _are_ talking about the 'make check' tests, right?

You tell me, that's the first you've mentioned about WHICH modules you wanted
to actually enable.

> B.S.  Unless you use negative loglevels, this is mathematically
> impossible.

Not true. I'd prefer if a log level of zero HAD been defined as a no-op but it
isn't and until libqof2 I can't change that. So the way to prevent logging of
certain "developer-only" or "testing" modules is simply to NOT have that
module name in the hash table. You've broken that. If your global variable is
allowed to remain, then every module is log enabled whether or not it is
listed in the hashtable - I simply cannot accept that.

It's fine for gnucash to have the attitude that everything should be logged
but other applications do NOT require such treatment and only ever want to
log when explicitly requested to do so by the user.

To achieve this, the code must include the ENTER(" ") etc. macros and have a
QofLogModule but NOT have a log level explicitly set, i.e. no entry in the
hashtable. Your patch enables logging for precisely these modules when they
should be silent.

It's fine that --debug enables logging for some modules and not for others -
that is the API and - despite what you may think - has always been the API
because the old enum was gnucash-specific and other applications HAD to use
their own methods.

> Just drop the charade and get back to the _real_ reason
> you're complaining: You forked QOF

I did not fork QOF, QOF has not been forked. It's a spin-out, not a fork.

> , and the original maintainers won't
> stop developing (and fixing) it like you told 'em to.

Not true. Please see a world beyond the narrow confines of gnucash where
modules are logged only if explicitly requested and where the "log
everything" mentality is simply unacceptable.

This is especially true in embedded systems where the logs should only ever be
created when absolutely necessary due to the tiny resource limits.

You may think diskspace is cheap and infinite but QOF has to be able to turn
everything off for those environments where temporary files are bad news.

Even logging fatal errors is unacceptable unless specifically enabled.

> > 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.

It is used globally if you follow the API instead of breaking it. Initialise
the modules you want logged explicitly, THEN you can set the log level for
each one using the global routine should the level need to be changed from
the initial value.

It's the same metaphor as QofObject - you have to register the object before
you can do any foreach work with it.

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

I don't have a problem with that, my problem is that you often fail to take
account of the uses of QOF outside gnucash. I have to take those aspects into
account and I will NOT accept patches that are gnucash-specific.

> 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.

It is not forked.

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

Good, then maybe we can make some progress.

> 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.

All I have ever wanted is for you to consider the role of QOF outside gnucash
and to consider that other processes may have different requirements. Drop
the blinkers and I'm happy. I don't want people to consider lib/libqof
"off-limits", just that changes in lib/libqof must NOT be gnucash specific.

--

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


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bock@step.polymtl.ca
In reply to this post by Chris Shoemaker
God dammit, I swore I wouldn't get involved in this, but that's enough.

> 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.

Even if there was only one copy in GnuCash SVN, Neil would still try to keep
it usable for other projects.  Code reuse is one of the main points of FOSS.  
He has shown his commitment to this, you have not.  That alone would make
having a single copy politically impossible.  That code is no longuer used
only by GnuCash, no matter where the code lives.  If it weren't for Neil's
patience, we'd have a fork on our hand (and we'd be responsable for it).

Neil is trying to make your job easier in this process, but you refuse to even
acknowledge that keeping the code generic is important (which is basically
all he is asking of you).

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

Neil has always been polite and argued with you on technical grounds.

But it seems that in every two messages you write you have to put some sniping
remark about Neil's skill level, or some other Ad Hominem.  This just isn't
acceptable.  But Neil doesn't attack you back, he dutifully ignores those
parts, extracts the technical content, and responds.  Guess who looks more
mature looking from the outside?  Neil has shown his willingness to bend over
backwards to help make changes in QOF as unobtrusive as possible for
GnuCash's development process, despite being frequently treated like an
unimportant incompetent.

His patient responses certainly earned my respect.  If I had been treated like
that when I joined GnuCash, I would have left long before I contributed
anything usefull.  I don't know how good his code is/isn't, and right now I
don't care, he still deserves to be treated with respect.

> 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.

Fine, but you'll most likely lose the argument.

--
Benoit Grégoire, http://benoitg.coeus.ca/

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Chris Shoemaker
In reply to this post by Neil Williams-2

First, reread what you wrote:

On Sun, Jan 29, 2006 at 03:58:28PM +0000, Neil Williams wrote:

>
> > 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_
>
> Wrong. Your modification to qof_log_check means that even if a module is NOT
> listed in the hashtable, the check returns TRUE even if loglevel is zero.
> That's plain wrong. Only modules in the hashtable should be logged. There can
> be no else{} statement. Zero is not "do not log", zero is GNC_LOG_FATAL which
> still results in some logging.
>
> Your modification means that qof_log_check returns true every time for
> GNC_LOG_FATAL and that simply isn't acceptable.
>
> If         log_string = (gchar*)g_hash_table_lookup(log_table, log_module);
> returns non-NULL, then we can test if the loglevel is sufficient. When it
> returns NULL, log_check MUST return FALSE.

Now read the code:

gboolean
qof_log_check(QofLogModule log_module, QofLogLevel log_level)
{
        gchar* log_string;
        QofLogLevel maximum; /* Any log_level less than this will be logged. */

        log_string = NULL;                     /* vvvvvvvv  LOOK HERE, NEIL! */
        if(!log_table || log_module == NULL || log_level == 0)
              { return FALSE; }
        log_string = (gchar*)g_hash_table_lookup(log_table, log_module);
...


Is it really possible you didn't read this before starting this tirade?

This is just astounding.  If you really didn't get this then I
apologize for my harsh tone.  This is why there's just no substitute
for really looking at the code and making it work.  You _incorrect_
assumptions are exposed, which is a good thing.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

Chris Shoemaker
In reply to this post by Bugzilla from bock@step.polymtl.ca
On Sun, Jan 29, 2006 at 02:13:50PM -0500, Benoit Grégoire wrote:
> Neil has always been polite and argued with you on technical grounds.
>

I agree that Neil's public emails have a certain tone of civility
that I can't bring myself to reciprocate.  I also recognize that to a
casual observer this may appear to be a technical discussion.  I
assure you it is not.  It is completely political.  Anyone who desires
can verify this for themselves.  I made a precise and concrete claim
about the behavior of code that I modified.  The function is correct C
code with well defined behavior.  Its return value if completely
determined by its input.  Is this claim important to Neil?  Apparently
not, as he consistently ignores it and argues as if I had changed the
bahavior of some external programs.  Why would he do this?  Because
whether or not the function returns TRUE or FALSE given input of ZERO
for an unregistered logging module is IRRELEVANT to Neil's point.
That would be a technical discussion quickly resolved upon a simple
reading of the line:

     if(!log_table || log_module == NULL || log_level == 0) { return FALSE; }

But it simply doesn't matter.  So, consider please, if this doesn't
matter, then _what_ is this whole flamewar about?  It's not about
compatibility.  It's about control.  I gave careful thought to a
solution that would fix the brokenness Neil created while leaving all
other programs unaffected.  What more could Neil want?  It's clear
that he doesn want _something_ more, and it's pretty clear to me that
I'm not willing to give it up.

> But it seems that in every two messages you write you have to put some sniping
> remark about Neil's skill level, or some other Ad Hominem.  This just isn't
> acceptable.  But Neil doesn't attack you back, he dutifully ignores those
> parts, extracts the technical content, and responds.  Guess who looks more
> mature looking from the outside?  

I'll leave that for the observer to judge.

> Neil has shown his willingness to bend over
> backwards to help make changes in QOF as unobtrusive as possible for
> GnuCash's development process,

This is simply not true.  How is disabling GnuCash's logging facility
and leaving it broken for months "as unobtrusive as possible"?

> despite being frequently treated like an unimportant incompetent.
>
> His patient responses certainly earned my respect.  If I had been treated like
> that when I joined GnuCash, I would have left long before I contributed
> anything usefull.  I don't know how good his code is/isn't, and right now I
> don't care, he still deserves to be treated with respect.

I completely agree that Neil deserves to be treated with respect.  I
even would say that that respect doesn't need to be "earned" but
should be afforded to anyone by default!  But, that needs to be
balanced against the benefit to the users of GnuCash.  Neil's recent
behavior has been to make rather invasive changes that were not
approved of by any other developers, and which broke functionality and
introduced subtle data corruption bugs.  Now, he's using the _ruse_ of
maintaining library compatibility to claim exclusive ownership of QOF.

So, how would you balance Neil's deserving of respect in this case
with the user's deserving a GnuCash whose core is developed by more
than one person?  I struggle with this question, so if you have a
suggestion I'm interested.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Finishing the neverending QOF flamewar

Bugzilla from bock@step.polymtl.ca
On January 29, 2006 04:58 pm, Chris Shoemaker wrote:
> On Sun, Jan 29, 2006 at 02:13:50PM -0500, Benoit Grégoire wrote:
> > Neil has always been polite and argued with you on technical grounds.
>
> I agree that Neil's public emails have a certain tone of civility
> that I can't bring myself to reciprocate.  I also recognize that to a
> casual observer this may appear to be a technical discussion.  I
> assure you it is not.  It is completely political.

Ok, I admit I oversimplified trying to show the argumentative pattern the two
of you are following.  I did not even try to follow the specific technical
issues.  I don't know which one of you is right.  I unfortunately lack the
time to follow gnucash developement closely for the time being, but I try to
not completely disconnect.

> > Neil has shown his willingness to bend over
> > backwards to help make changes in QOF as unobtrusive as possible for
> > GnuCash's development process,
>
> This is simply not true.  How is disabling GnuCash's logging facility
> and leaving it broken for months "as unobtrusive as possible"?

Abstracting a core part of a software package to make it independently usable
from other applications is inevitably going to cause a short term loss of
efficiency for the original software.  Sometimes (some would say most of the
time) that loss is never recuperated by the original project in the form of
long term benefits.  

So what "as unobtrusive as possible" means in this context is open for debate.  
But it clearly doesn't mean "doesn't change the way we do things or add any
additional overhead".

I don't know how loging got broken, and who is right.

> I completely agree that Neil deserves to be treated with respect.  I
> even would say that that respect doesn't need to be "earned" but
> should be afforded to anyone by default!  But, that needs to be
> balanced against the benefit to the users of GnuCash.  Neil's recent
> behavior has been to make rather invasive changes that were not
> approved of by any other developers, and which broke functionality and
> introduced subtle data corruption bugs.  Now, he's using the _ruse_ of
> maintaining library compatibility to claim exclusive ownership of QOF.

Well, he is trying to assert maintainership over that piece of code, I didn't
feel he made any secrets about it.  Furthermore no one has offered to do it
in his place.

> So, how would you balance Neil's deserving of respect in this case
> with the user's deserving a GnuCash whose core is developed by more
> than one person?  I struggle with this question, so if you have a
> suggestion I'm interested.

Well, while it's no magic solution,  I'll try to bluntly list the real issues
the two of you have as I perceive them.

First issue:  The GnuCash project didn't make a clear commitement that it
would maintain QOF as an independent library, with it's own release schedule,
causing a lack of trust by Neil and other users of QOF that their needs are
goind to be given due consideration.  Normally, we'd have to chose between:  

1-The GnuCash project maintains QOF as an independent library in the gnuCash
repository (that means giving equal merit to the needs of other projects,
maintaining a separate build system, accepting patches in a timely manner,
giving commit access to people who would commit frequently to QOF even if
they never even build GnuCash, etc.) Then we can expect everyone else to sync
to our copy.

2-Developpement occurs elsewhere, we are just one of the stakeholders, and we
sync to "their" copy.

3-We don't give a rat's ass about cooperation with other projects, we tell
those who want to use QOF good luck, take it, we never want to hear about you
again.

Normally those three things would be mutually exclusive.  Lucky for us, we
also seem to have:

4-One crazy person commits to keeping two repositories in sync to allow
everyone to develop where it's natural for them to do, giving some of the
benefits of 1 and 2 at the same time.  That's a very hard job, and it
requires that the participants of both repositories at least agree that QOF
is to be considered a self contained, generic library.

That's a political and philosophical issue.

Second issue: Keeping QOF usable by other project requires additional work to
be performed, delaying 2.0 by some unknown amount of time.  That's an
inevitable consequence of the first issue if 1, 2 or 4 is chosen.  A fork is
an inevitable consequence or 3.

Third issue:  How to handle code quality while QOF undergoes this transition.  
This is a trust, time and communication issue.  Neil may or may not have the
necessary skills and experience to maintain and sync QOF on his own.  If he
does, he's still just a human being, and keping large codebases maintained in
two places will inevitably causes glitches, especially during API changes.  
If he doesn't, there's still only two things that can be done: replace him or
help him.  

Fourth issue (that received surprisingly little attention), is exactly where
QOF starts and end.  Some features of QOF may not really belong in the core
QOF library, conversely some issues may be resolved by moving services into
QOF.  That's an architecture issue.

Fift issue is the specific mechanics of cooperation.  How often do we sync
changes, how large the syncs should be, how do we handle the build issues,
release schedules, etc.  That's a process issue.  I tought a reasonably clear
process was outlined, but it may be worth writing a step by step list.

The two of you seem to have spoken or unspoken disagreements on all five, and
probably most other developers have (or had) disagreement on at least one.

There should probably be a discussion of each one individually to reach a
consensus, and settle with some sort of vote if there if one isn't reached.

We can then move back to real technical issues in a productive climate.
--
Benoit Grégoire, http://benoitg.coeus.ca/

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Finishing the neverending QOF flamewar

Neil Williams-2
On Monday 30 January 2006 6:01 am, Benoit Grégoire wrote:

(I agree with all the points Benoit raised.)

> There should probably be a discussion of each one individually to reach a
> consensus, and settle with some sort of vote if there if one isn't reached.

If I can just receive a little consideration for my admittedly crazy decision
to implement option 4, we can have this discussion in a measured and relaxed
manner once gnucash2.0 is out. I will try to keep the two in sync and to keep
both ends happy but this whole issue needs to be put to bed until the other
developers have time to get involved.

I know it's wasted several days of my time that could have been spent
investigating horrid little bugs in the Business objects in G2.

> We can then move back to real technical issues in a productive climate.

Yes please.

--

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


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Finishing the neverending QOF flamewar

Chris Shoemaker
In reply to this post by Bugzilla from bock@step.polymtl.ca

FTR, I want to clarify some things:

  I am _glad_ Neil wants to work on QOF.  I think that an external
QOF, of a certain design, and at a certain time, is a desirable thing.

  Relatively speaking, I am _not_ bothered by Neil breaking logging.
I think it was an honest mistake due to some lack of testing, and it
was easy to fix.

  In fixing it, I improved the logging API, without affecting any
existing QOF program.  Not a single message of any type, anywhere, is
logged with my patch that wasn't logged before, nor vice-versa.  There
is simply no technical disadvantage to my change.  It is 100%
compatible with every existing usage with no change, and it makes a
useless function useful.

  If I'm not allowed to make _that_ kind of change, then how can I be
considered a QOF developer?  I have _no_ hope of fixing bugs that
actually _do_ change behavior (like the fact that qof-log silently
drops all FATAL log messages!)  I _am_ bothered by that.

  Why should I be satisfied with that?  Does it serve the interests of
GnuCash users?  QOF users?  I don't think so.

> > I completely agree that Neil deserves to be treated with respect.  I
> > even would say that that respect doesn't need to be "earned" but
> > should be afforded to anyone by default!  But, that needs to be
> > balanced against the benefit to the users of GnuCash.  Neil's recent
> > behavior has been to make rather invasive changes that were not
> > approved of by any other developers, and which broke functionality and
> > introduced subtle data corruption bugs.  Now, he's using the _ruse_ of
> > maintaining library compatibility to claim exclusive ownership of QOF.
>
> Well, he is trying to assert maintainership over that piece of code, I didn't
> feel he made any secrets about it.  Furthermore no one has offered to do it
> in his place.

  I don't have _any_ problem with Neil being the maintainer of QOF.
None at all.  Using a false justification of incompatibility to revert
of peopele's changes is a claim to _exclusive_ maintainership.  I _do_
have a problem with that.

> > So, how would you balance Neil's deserving of respect in this case
> > with the user's deserving a GnuCash whose core is developed by more
> > than one person?  I struggle with this question, so if you have a
> > suggestion I'm interested.
>
> Well, while it's no magic solution,  I'll try to bluntly list the real issues
> the two of you have as I perceive them.
>

> First issue: The GnuCash project didn't make a clear commitement
> that it would maintain QOF as an independent library, with it's own
> release schedule, causing a lack of trust by Neil and other users of
> QOF that their needs are goind to be given due consideration.
> Normally, we'd have to chose between:
>
> 1-The GnuCash project maintains QOF as an independent library in the
> gnuCash repository (that means giving equal merit to the needs of
> other projects, maintaining a separate build system, accepting
> patches in a timely manner, giving commit access to people who would
> commit frequently to QOF even if they never even build GnuCash,
> etc.) Then we can expect everyone else to sync to our copy.

FTR, this offer has been made by Derek and declined.

> 2-Developpement occurs elsewhere, we are just one of the
> stakeholders, and we sync to "their" copy.

This is pretty unpopular.

> 3-We don't give a rat's ass about cooperation with other projects, we tell
> those who want to use QOF good luck, take it, we never want to hear about you
> again.
>
> Normally those three things would be mutually exclusive.  Lucky for us, we
> also seem to have:
>
> 4-One crazy person commits to keeping two repositories in sync to allow
> everyone to develop where it's natural for them to do, giving some of the
> benefits of 1 and 2 at the same time.  That's a very hard job, and it
> requires that the participants of both repositories at least agree that QOF
> is to be considered a self contained, generic library.

... and agree on who has permission to make changes.  I honestly don't
see why Neil thinks it's more natural to develop QOF on his own rather
than in GnuCash's repo, but I don't have _any_ problem with his doing
so.  I just don't think that should mean that I can't change QOF anymore.

   BTW, there is another option.  I think that Neil has placed _way_
too much emphasis on packaging QOF - to the detriment of true
collaboration and sharing of QOF code.  An obvious option is to
continue devloping QOF where it has been developed until it's really
ready to stand on it's own.  And, until then, to sync the QOF code
into the trees of QOF programs.  I _guarantee_ this is less work than
option 4.  And the downside?  One redundant .so for any system that
happens to use two QOF programs?  

In reality even this isn't a downside, because I would expect that the
tree where QOF is developed would be constantly releasing with a QOF
version later than had been copied to the other programs.  And that's
_good_.  It means that QOF can continue to develop with changes that
aren't 100% backward API-compatible because no external programs will
use the newer version until they sync with the development tree.  At
that point, they can adjust for any changes in API.

   _OR_ If Neil really wants those other QOF programs to use external
libraries, he can always package libraries from the development tree.
The point is, QOF is not mature enough to stand on it's own.  It needs
to mature within a development community larger than 1, and
practically speaking, that means that development on QOF within
GnuCash _must_ continue.  

   Furthermore, because QOF is not mature enough to have a stable API,
we must be free to make changes that are not backward compatible.
That means that releasing a library of QOF is no different than
copying the source -- every release may require changes to the QOF
programs.  Any other QOF programs that use an external library should
lock to the one version they have been tested with.

   Personally, I think the external library thing is premature and
creates more problems than it's worth.

> That's a political and philosophical issue.
>
> Second issue: Keeping QOF usable by other project requires additional work to
> be performed, delaying 2.0 by some unknown amount of time.  That's an
> inevitable consequence of the first issue if 1, 2 or 4 is chosen.  

There are different degrees of additional work required by the
different options.  We're certainly not taking the easiest and least
disruptive approach to sharing code with other QOF programs.

> A fork is an inevitable consequence or 3.

Forks are good.  Every commit is the merging of a (small) fork.  We're
all working on different copies of the source, so our developements
are always forks from the common source until we merge them.  Making a
copy of the source to work on is _good_.  Neil has choosen to keep a
copy in such a way that makes it difficult for him to merge his
changes with the common source that has been developing in GnuCash's
repo.  It's completely understandable why he wants to revert
improvements to lib/libqof.  Every change makes more work for him.
Forks are good, and merging is _better_.  When you revert changes
because merging is too hard, it's time to change your tools.

> Third issue: How to handle code quality while QOF undergoes this
> transition.  This is a trust, time and communication issue.  Neil
> may or may not have the necessary skills and experience to maintain
> and sync QOF on his own.  If he does, he's still just a human being,
> and keping large codebases maintained in two places will inevitably
> causes glitches, especially during API changes.  If he doesn't,
> there's still only two things that can be done: replace him or help
> him.

I think I can speak (with great caution) for all the GnuCash
developers in saying that we want to _help_ Neil, not replace him.
But it's very difficult to help him when his development is in
isolation.  Even the infrequent commits to SF CVS are too far removed
from the people who can help.  We _want_ to help - we want to help
_here_, not at SF.

> Fourth issue (that received surprisingly little attention), is exactly where
> QOF starts and end.  Some features of QOF may not really belong in the core
> QOF library, conversely some issues may be resolved by moving services into
> QOF.  That's an architecture issue.

This is a HUGE issue.  It's the MAIN issue why I'm unconfortable with
GnuCash using an external QOF.  It seems that the decision boundary
for what moved to qof was something like "whatever code could be used
by multiple projects."  That's a poor way to build a library.  I think
more than 50% of what's in libqof doesn't belong.  I also thing that
the querying infrastructure and the serialization probably don't
belong together.

> Fift issue is the specific mechanics of cooperation.  How often do
> we sync changes, how large the syncs should be, how do we handle the
> build issues, release schedules, etc.  That's a process issue.  I
> tought a reasonably clear process was outlined, but it may be worth
> writing a step by step list.

I thought the process was:

1) Gnucash developers can still develop QOF.

2) Neil's in charge of copying code from svn to where ever he releases
libraries from.

3) If we make non-backward compatible changes to QOF, Neil would have
to reflect that in his library version numbers.

One thing that I don't think was hammered out was should Gnucash 2.0
use external QOF.  Neil has asserted that it should.  I'm a bit
uncomfortable with this because of lack of testing.  The dilemma I see
is:

1) We shouldn't release 2.0 with external QOF unless we've tested it
extensively with the version we're depending on.

2) We can't test with external QOF because we're frequently making
changes to QOF that aren't backward-compatible.

The responsible options are either:

a) Stop internal QOF development, depend on external QOF, test with
external QOF, release with external QOF.

or

b) Continue interal QOF development, build with only internal QOF,
test with internal QOF, release with internal QOF.

Since we have to build, test and release with internal QOF _anyway_ to
support all platforms, and since I don't think Gnucash developers
shoud stop QOF development, (b) seems like an obvious choice.

Note that this _doesn't_ preclude sharing QOF code with other
projects, even in the form of an external library.  It's just a
question of whether or not _GnuCash_ should depend on an external
library for QOF functionality.

> The two of you seem to have spoken or unspoken disagreements on all
> five, and probably most other developers have (or had) disagreement
> on at least one.  There should probably be a discussion of each one
> individually to reach a consensus, and settle with some sort of vote
> if there if one isn't reached.  We can then move back to real
> technical issues in a productive climate.

I think you can tell that most developers are steering clear for now.

It might be because they don't approve of my assertive tone.  It's
probably because they'd rather write code than argue.  So would I.
However, I'm concerned that our continued silence leads to
misunderstanding and a sort of "squatter's rights" about QOF.

Neil's words say that I'm free to develop QOF, but his actions are
that 100% compatible improvements to the API are reverted.

I think it would be appropriate to have some _public_ discussion on
this point.  I'll post a question in a new thread to attempt to leave
some of the baggage of this thread behind.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Finishing the neverending QOF flamewar

Neil Williams-2
On Monday 30 January 2006 4:54 pm, Chris Shoemaker wrote:
>   Relatively speaking, I am _not_ bothered by Neil breaking logging.

(I didn't break it, let's not start all that again. Change the record.)

There is actually NO reason to discuss all this now - this should all wait
until after G2 is out. That is MY priority right now and this discussion is
wasting ever more of my time. Please can we drop this!

> I think it was an honest mistake due to some lack of testing, and it
> was easy to fix.

You're still missing the point. It was the default and the else{} that was
wrong.

>   In fixing it, I improved the logging API, without affecting any
> existing QOF program.

Once again, Chris, that is inaccurate. Implementing logging for modules that
do not explicitly set their own log level DOES break functionality in other
programs because those programs want to use selective logging. This is the
opposite of the "log-everything" habit of gnucash. If a module does not set
it's own log level, the library supports ignoring that module completely.
Your change to _global meant that once _global was called with a real
log-level value, all those silent modules would be silently enabled.

I accept _global needs to be renamed but that does not mean it is right to
close off selective logging. It is incredibly powerful in debugging -
something that I should have been doing these last two days instead of
answering your increasingly desperate posts.

> Not a single message of any type, anywhere, is
> logged with my patch that wasn't logged before, nor vice-versa.

You have no evidence for such a statement. I attest that messages ARE logged
that should not be logged because of the change - or would have been if I'd
implemented it in QOF CVS.

(If the change made no change to logging, why all the fuss?)

> There
> is simply no technical disadvantage to my change.  It is 100%
> compatible with every existing usage with no change, and it makes a
> useless function useful.

Wrong. The "useless" function you refer to is probably _global which, I
accept, is misleading named but still functional. If I'd actually had time to
fix this instead of wasting time on these endless discussions, I could have
made some progress this week. As it is, your incessant posts have meant that
I will get no further work done this week due to pressing commitments
elsewhere. Thanks a lot.

>   I don't have _any_ problem with Neil being the maintainer of QOF.
> None at all.  Using a false justification of incompatibility to revert
> of peopele's changes is a claim to _exclusive_ maintainership.  I _do_
> have a problem with that.

The title of this thread was to finish this waste of time. You are just
perpetuating it.

FINISH THIS. NOW.

I propose there should be no further discussion of this whole area until AFTER
G2 is out. I'll manage as best I can in the meantime and release libqof1 at
such points as are necessary for the external programs and for gnucash
releases. Beyond that, the matter MUST rest until gnucash 2.0.0 is OUT.

> > 4-One crazy person commits to keeping two repositories in sync to allow
> > everyone to develop where it's natural for them to do, giving some of the
> > benefits of 1 and 2 at the same time.  That's a very hard job, and it
> > requires that the participants of both repositories at least agree that
> > QOF is to be considered a self contained, generic library.
>
> ... and agree on who has permission to make changes.  I honestly don't
> see why Neil thinks it's more natural to develop QOF on his own rather
> than in GnuCash's repo, but I don't have _any_ problem with his doing
> so.  I just don't think that should mean that I can't change QOF anymore.
As long as you are willing to accept that there are other uses of these
functions that are beyond their purpose in gnucash.

>    BTW, there is another option.  I think that Neil has placed _way_
> too much emphasis on packaging QOF - to the detriment of true
> collaboration and sharing of QOF code.  An obvious option is to
> continue devloping QOF where it has been developed until it's really
> ready to stand on it's own.

(It already is ready.)

> In reality even this isn't a downside, because I would expect that the
> tree where QOF is developed would be constantly releasing with a QOF
> version later than had been copied to the other programs.  And that's
> _good_.  It means that QOF can continue to develop with changes that
> aren't 100% backward API-compatible because no external programs will
> use the newer version until they sync with the development tree.  At
> that point, they can adjust for any changes in API.

Unmanageable. The SONAME would be pushed beyond any reasonable limits. Do you
want libqof32 ?

>    _OR_ If Neil really wants those other QOF programs to use external
> libraries, he can always package libraries from the development tree.
> The point is, QOF is not mature enough to stand on it's own.  It needs
> to mature within a development community larger than 1, and
> practically speaking, that means that development on QOF within
> GnuCash _must_ continue.

As long as the needs of other programs is considered.

>    Furthermore, because QOF is not mature enough to have a stable API,

It does have a stable API and will remain so until libqof2 when all this
deprecated stuff will be removed.

> we must be free to make changes that are not backward compatible.

Not true. Adding interfaces is acceptable, as is deprecating old ones, but the
old ones must remain and the library must still be usable by older programs.

> That means that releasing a library of QOF is no different than
> copying the source -- every release may require changes to the QOF
> programs.

This is exactly the nightmare that we had when Linas packaged QOF. It is
unmanageable and irresponsible. Not a good way of sharing code.

> Any other QOF programs that use an external library should
> lock to the one version they have been tested with.

!!! Have you ANY idea how difficult that becomes !!!

> > Second issue: Keeping QOF usable by other project requires additional
> > work to be performed, delaying 2.0 by some unknown amount of time.
> > That's an inevitable consequence of the first issue if 1, 2 or 4 is
> > chosen.
>
> There are different degrees of additional work required by the
> different options.  We're certainly not taking the easiest and least
> disruptive approach to sharing code with other QOF programs.

For whom?

> > A fork is an inevitable consequence or 3.
>
> Forks are good.

Forks are bad. Forks prevent sharing, sharing is the essence of free software.
If we can't share we might as well all give up right now.

> Neil has choosen to keep a
> copy in such a way that makes it difficult for him to merge his
> changes with the common source that has been developing in GnuCash's
> repo.

Not true. A little copy and paste is all it needs. Besides, nearly all QOF
development now happens outside the gnucash tree. There is no good reason to
reverse that.

Building gnucash takes FOREVER and testing changes becomes an interminable
minefield of frustration and twiddling thumbs. That is why I started doing
translations and the website - something to DO whilst waiting for gnucash to
build.

Building QOF is fast, I can make, test, build and distribute changes in a
matter of hours. GnuCash takes months.

> It's completely understandable why he wants to revert
> improvements to lib/libqof.  Every change makes more work for him.

Wrong, I will gladly accept changes in qof that consider the needs of the
other programs and which are not gnucash-specific.

It is very little work to copy changes between the two trees - the work comes
in getting others to understand why gnucash ideals will NOT work for external
programs.

> I think I can speak (with great caution) for all the GnuCash
> developers in saying that we want to _help_ Neil, not replace him.
> But it's very difficult to help him when his development is in
> isolation.  Even the infrequent commits to SF CVS are too far removed
> from the people who can help.  We _want_ to help - we want to help
> _here_, not at SF.

And I'm the one acting as the gopher between the two. That's fine, I committed
to that some time ago. That hasn't changed. I don't like svn, I do like SF.
If you want to help me, let me work with tools that I actually like to use.

> > Fourth issue (that received surprisingly little attention), is exactly
> > where QOF starts and end.  Some features of QOF may not really belong in
> > the core QOF library, conversely some issues may be resolved by moving
> > services into QOF.  That's an architecture issue.

FTR, I'm perfectly happy with what is in libqof1. If you look at the actual
Makefiles, there are some files that are no built but these are not used in
gnucash either. All the rest is as fundamentally important to the external
programs as to gnucash.

gnucash is another qof process - I try and deal with each equally but that
means that the needs of gnucash do NOT take priority.

> This is a HUGE issue.  It's the MAIN issue why I'm unconfortable with
> GnuCash using an external QOF.  It seems that the decision boundary
> for what moved to qof was something like "whatever code could be used
> by multiple projects."

That's a good way to share code - it means pilot-qof and gpe can get the
benefits of what began in the gnucash engine without the overhead and without
extraneous code. Every part of QOF is used by these external programs.

> That's a poor way to build a library.  I think
> more than 50% of what's in libqof doesn't belong.  I also thing that
> the querying infrastructure and the serialization probably don't
> belong together.

By serialisation do you mean QSF? Other serialisation code within QOF is no
longer built either in gnucash or libqof1.

> 1) Gnucash developers can still develop QOF.
>
> 2) Neil's in charge of copying code from svn to where ever he releases
> libraries from.
>
> 3) If we make non-backward compatible changes to QOF, Neil would have
> to reflect that in his library version numbers.
>
> One thing that I don't think was hammered out was should Gnucash 2.0
> use external QOF.  Neil has asserted that it should.
I'd like it to do so and I will do what I can to allow it to do so but it
isn't compulsory. It is, however, eminently sensible.

> 1) We shouldn't release 2.0 with external QOF unless we've tested it
> extensively with the version we're depending on.

Any version of libqof1 will be compatible. There are bug fixes in 0.6.1 and
0.6.2 which mean gnucash will function better with those versions, hence I
bumped the configure version to 0.6.2. You cannot fix an application to a
specific version of a library because it breaks all the packaging systems. I
want gnucash to be able to release, as far as bugs allow, independently of
libqof1 and vice-versa.

> 2) We can't test with external QOF because we're frequently making
> changes to QOF that aren't backward-compatible.

Frequently? Two changes since this whole wrangle started?

If you had taken head of my notice of imminent release of QOF 0.6.1 then we
could be using libqof1 0.6.1 NOW, for this upcoming gnucash release.

All I needed was a little email from you saying "I'm working on something that
is in lib/libqof and hope to commit soon." then I could have delayed the
release by a matter of a few days and included your CACHE_REMOVE change. No
problems with that, none whatsoever.

> Note that this _doesn't_ preclude sharing QOF code with other
> projects, even in the form of an external library.  It's just a
> question of whether or not _GnuCash_ should depend on an external
> library for QOF functionality.

If you ever want to use libqof1 externally there does remain some need to
coordinate with external qof development and consider the needs of external
programs.

> It might be because they don't approve of my assertive tone.  It's
> probably because they'd rather write code than argue.  So would I.

And I. PLEASE can we stop this nonsense until AFTER G2. How many times do I
have to ask! Stop wasting my time!

> Neil's words say that I'm free to develop QOF, but his actions are
> that 100% compatible improvements to the API are reverted.

Your else{} block is not compatible. It does not allow modules to be ignored
for selective logging.

> I think it would be appropriate to have some _public_ discussion on
> this point.

Just not NOW please!

> I'll post a question in a new thread to attempt to leave
> some of the baggage of this thread behind.

It would have been better for everyone if you would simply drop the entire
issue and let everyone else actually do the IMPORTANT things in life, like
fix bugs in G2.

Drop this!

--

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


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Finishing the neverending QOF flamewar

Chris Shoemaker
On Mon, Jan 30, 2006 at 07:59:27PM +0000, Neil Williams wrote:
> > Not a single message of any type, anywhere, is
> > logged with my patch that wasn't logged before, nor vice-versa.
>
> You have no evidence for such a statement. I attest that messages ARE logged
> that should not be logged because of the change - or would have been if I'd
> implemented it in QOF CVS.

?!? You are willing to believe that I would adamantly assert something
which I just made up?  ...???...

Then why didn't you just CHECK?  Don't you think it would have shut me up
to show what an idiot I was to have made such a claim so adamantly and
be wrong about it?  No one would be able to trust me.  Do you think I
would be so reckless with my reputation?

Proof:

  a) global_default_loglevel is initialized to zero.

  static QofLogLevel global_default_loglevel = 0;

  b) It is only ever changed in one place:

void qof_log_set_level_global(QofLogLevel level)
{
        gchar* level_string;

        if(!log_table || level == 0) { return; }
        global_default_loglevel = level;
        level_string = g_strdup(QofLogLevelasString(level));
        g_hash_table_foreach(log_table, log_module_foreach, level_string);
}

  c) That code path is never reached in any application other than GnuCash:

$ grep -sRI qof_log_set_level_global pilot-qof-0.0.7 gnotime-2.2.2 qof-gen
$
  d) The "else" statement is not reached when log_level==0.

gboolean qof_log_check(QofLogModule log_module, QofLogLevel log_level)
{
       log_string = NULL;
       if(!log_table || log_module == NULL || log_level == 0) {
                return FALSE; }        
       log_string = (gchar*)g_hash_table_lookup(log_table, log_module);
       /* if log_module not found, use default. */
       if (log_string)
           maximum = QofLogLevelfromString(log_string);
       else
           maximum = global_default_loglevel;
        if(log_level <= maximum) { return TRUE; }
        return FALSE;
}
  e) When c) is TRUE and log_level > 0 and log_string == NULL then
this function returns TRUE iff log_level <= 0.  I.e. never.  Q.E.D.

Why on _earth_ would I make this stuff up?

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Finishing the neverending QOF flamewar

Pierre THIERRY
In reply to this post by Neil Williams-2
Scribit Neil Williams dies 30/01/2006 hora 19:59:
> > In fixing it, I improved the logging API, without affecting any
> > existing QOF program.
> Once again, Chris, that is inaccurate. Implementing logging for
> modules that do not explicitly set their own log level DOES break
> functionality in other programs

Naive question from a lurker: is there any sort of unit testing in the
code that could tell us in a purely logic way if anything is or is not
broken wrt this problem?

I don't think a ping/pong of "it's broken", "no it's not" will
eventually lead to anything useful...

Peacefully,
Nowhere man
--
[hidden email]
OpenPGP 0xD9D50D8A

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Finishing the neverending QOF flamewar

Derek Atkins
Quoting Pierre THIERRY <[hidden email]>:

> Scribit Neil Williams dies 30/01/2006 hora 19:59:
>> > In fixing it, I improved the logging API, without affecting any
>> > existing QOF program.
>> Once again, Chris, that is inaccurate. Implementing logging for
>> modules that do not explicitly set their own log level DOES break
>> functionality in other programs
>
> Naive question from a lurker: is there any sort of unit testing in the
> code that could tell us in a purely logic way if anything is or is not
> broken wrt this problem?

unfortunately no, it's not an objective thing.  The argument is a question
about the specification of the API and how it should work, not whether
the API matches any particular spec.  There's just disagreement about
how it should work, not whether it's working "correctly".

> I don't think a ping/pong of "it's broken", "no it's not" will
> eventually lead to anything useful...

Well, I suppose I could put my foot down, but frankly we've got a "workaround"
that IMHO solves the problem from GnuCash and leaves the API in the state
Neil wants, so in the short term I think we can just end this thread
and say "it's been fixed."

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel