I know nothing of what print_widechars does, its in test code anyway and we needed something in runtime code, hence logWidecharBuf. There may be some common code to extract but that will need to wait.
As for swapping lou_logPrint, I was waiting for more feedback before changing that, but as the logging API seems satisfactory now it might be time to start doing that change over. However it will have to wait as i am hunting out another bug.
Michael Whapples On 29/04/2014 10:13, Christian Egli wrote:
"Michael Whapples" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "mwhapples@xxxxxxx" for DMARC) writes:OK, done something slightly different, mainly because it seemed to make sense. This keeps the API slimmer than having a separate function for disabling logging. I am not sure it needed to be any more separate than setting the log level, it makes sense as well to put it there (well actually it was always there because of having log levels built in). If we feel happy with that I will see about updating the NEWS file (if needed).From what I can tell the api seems sensible. There are a few minor nits which I'll specify in response to the commit message. The one thing that struck me as a bit odd is that there is a new function 'logWidecharBuf'. Isn't it almost doing the same as 'print_widechars' in test/brl_check.c? Also should we not change all calls to lou_logPrint by lou_log? Otherwise you will never see these messages in the callback, will you? Thanks Christian
For a description of the software, to download it and links to project pages go to http://www.abilitiessoft.com
