Immediately flushing log statements using the Cocoa Lumberjack logging framework, the way NSLog flushes to console
Asked Answered
N

3

14

Many iOS developers have found the Cocoa Lumberjack Logging framework to fill a need that simple NSLog statements don't. It's reminiscent of Log4J in the Java world.

In any event, I have written my own custom formatter for Lumberjack, but what I don't see is any documentation on how to flush log statements immediately.

For example, if I'm walking through the debugger and I hit an NSLog() statement, it flushes the log statement to the console immediately. That's the behavior I'd like to get from a DDLogVerbose() call in Lumberjack.

Right now, I go back and change these statements to NSLog() statements if I want them to spit out immediately as I'm debugging a segment of code. With Lumberjack being so robust, I got to think there's a way to configure it to flush with no delay.

Anyone know how to make it so?

Necessarian answered 1/1, 2012 at 1:22 Comment(0)
N
28

I found the answer in the DDLog.h file. Lumberjack has the concept of asynchronous and synchronous logging. At initial read, it didn't hit me as to what this was for.

Basically, if you want the log statement to be output in sequence, one needs to make it synchronized (though, as Mike mentioned, this will slow down performance). So, this should only be done in a debugging situation. Ideally, I'll put another header together and/or some other pre-processor macro to ensure I don't leave the switch flipped on as synchronous.

Here's what you do:

  1. Open up DDLog.h
  2. Go to the line with #define LOG_ASYNC_ENABLED YES. You can change this to NO in one spot for synchronous logging across the board, or you can change individual levels, in the lines that follow.

Note that the header discourages changing the DDLog.h file itself. So, following the instructions on the Lumberjack wiki page link, they explain how to use a different header file to articulate these override customizations.

Using that, here's what I've successfully written and tested, as "MyAppLumberjack.h" header file that I import in my app's precompiled header:

#import "DDLog.h"
#import "DDASLLogger.h"
#import "DDTTYLogger.h"

// ========================= Overrides ========================================
// --> per https://github.com/robbiehanson/CocoaLumberjack/wiki/CustomLogLevels
// ----------------------------------------------------------------------------

// Are we in an optimized (i.e. Release) build?
#ifdef __OPTIMIZE__
    // YES: Nothing to do from the default. (You could simplify this by using #ifndef above instead)
#else
    // NO: We're in a Debug build. As such, let's configure logging to flush right away.
    // Undefine the asynchronous defaults:
    #undef LOG_ASYNC_VERBOSE
    #undef LOG_ASYNC_INFO
    #undef LOG_ASYNC_WARN

    // Define the logs levels to be synchronous:
    #define LOG_ASYNC_VERBOSE   (NO && LOG_ASYNC_ENABLED)   // Debug logging will be synchronous
    #define LOG_ASYNC_INFO      (NO && LOG_ASYNC_ENABLED)   // Info logging will be synchronous
    #define LOG_ASYNC_WARN      (NO && LOG_ASYNC_ENABLED)   // Warn logging will be synchronous
#endif
Necessarian answered 1/1, 2012 at 4:30 Comment(1)
while you were investigating and implementing this, did you notice if there is a way at run time of turning switching between synchronous and asynchronous logging?Dioxide
T
2

You can wait for the logging queue to finish with a timeout:

- (void)waitForLog {
  dispatch_semaphore_t sema = dispatch_semaphore_create(0);
  dispatch_async(DDLog.loggingQueue, ^{
    dispatch_semaphore_signal(sema);
  });
  dispatch_semaphore_wait(sema, dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1.0 * NSEC_PER_SEC)));
}
Tartaglia answered 29/1, 2016 at 1:26 Comment(0)
A
0

you could try adding fflush(stderr); at the bottom of the if (logMsg) in the - (void)logMessage:(DDLogMessage *)logMessage function in DDTTYLogger.m.

the downside to flushing on every log message is that you may experience a hit to performance, tho if you're using it for debugging it probably doesn't matter.

Arel answered 1/1, 2012 at 2:1 Comment(1)
Thanks Mike. This was a sensible supposition. It unfortunately didn't work. I tried flushing stdout too, but that didn't work either (which makes sense - the whole method seems to be building up output to stderr).Necessarian

© 2022 - 2024 — McMap. All rights reserved.