[liblouis-liblouisxml] Re: Including the logging branch in master
- From: Bert Frees <bertfrees@xxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Wed, 14 May 2014 11:28:41 +0200
Hi Michael,
I talked to Christian and we have a feeling that maybe not only
lou_logPrint but also lou_log should be removed from the public API. The
reasoning is that liblouis shouldn't be responsible for routing
liblouisutdml's (or others') log messages to the right place. Shouldn't
it be the other way around? Shouldn't the programs that use liblouis be
responsible for redirecting liblouis's messages?
In practice, this would mean that liblouisutdml would get it's own log
callback hook, and when e.g. BrailleBlaster would register a callback
with liblouisutdml, liblouisutdml would in his turn register that
callback with liblouis.
This seems much cleaner to me, but I'd like to know what you think. Can
we discuss this on friday on the channel when both Christian and me have
some more time (and have put some more thought into this)?
Other than that, the features seem pretty complete to me. I'd like to
have the documentation updated accordingly but if you want I can do
that.
Cheers,
Bert
Bert Frees writes:
> Hello Michael,
>
> Michael Whapples writes:
>
>> Hello,
>> I am feeling that in the way of features, unless anyone can think of
>> anything else then may be the logging branch is near complete and ready
>> for comments and final adjustments before inclusion in to master.
>>
>> Things of concern to me:
>> * I know that in the log method there is some ugly code to force MSVC
>> into loading floating point support. Unfortunately this seems to be
>> unavoidable, the floating point support is dynamically loaded when
>> needed, but due to the function taking varargs it is not possible for VC
>> to work this out automatically. The ugly code seems to be one of the
>> suggested solutions by Microsoft. Unless anyone can think of another
>> solution I say keep this code, may be more comments to explain why it is
>> as it is.
>> * There was a question over the code to log widechar strings, whether it
>> duplicates existing code. Unfortunately I cannot remember the file the
>> duplicate code is in, but it was certainly within tests and the
>> logWidecharBuf function is for library runtime not just test time, thus
>> the solution is not altering logging code but rather moving the test
>> code to use core code.
>> * Do we want to remove old log functions from the API? This would break
>> old applications. Also what functions should be removed (eg.
>> lou_logPrint I am sure should go, but the lou_logFile function might be
>> useful for configuring the default callback handler).
>
> If I understand correctly, these functions still work exactly as before,
> the only difference is that they are not used internally anymore (except
> lou_logPrint which is used as the default log handler). IMO that is the
> most important, and from now on we should only use the new logging
> functions internally.
>
> I'd rather wait with changing the API, because I think there are some
> other API changes in the pipeline, so we should combine all of them in
> one major version update.
>
>> Any thoughts on the above, or any other thoughts of what might need
>> changing?
>
> Maybe we should already remove the old log functions from the
> documentation though.
>
>> When might we look at merging this to master? How does one deal with
>> that with Git?
>
> Git is all about merging :) To merge a branch back onto master, you
> simply do:
>
> git checkout master
> git merge your_branch_name
>
> But you don't have to worry too much about merging stuff to
> master. Mesar, Christian or I can take care of that.
>
>
> /Bert
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
