[liblouis-liblouisxml] Re: Including the logging branch in master
- From: Bert Frees <bertfrees@xxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Tue, 13 May 2014 15:43:38 +0200
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:
