Support os_log

[tombogle]

I'm brand new to this project, so I apologize if I've missed something, but it appears that anything logged using XCLogger does not show up in Console for iOS 10+. It looks like they've deprecated NSLog in favor of the new os_log approach. Could XCGLogger be made to detect the iOS version at runtime and issue the log via os_log so it would still appear in Console, perhaps using an approach like the one described here: http://blog.safedk.com/technology/nslog-os_log-multiple-ios-versions/

[phimage]

The code coud be something like that

import os.log

open class OSLogDestination: BaseQueuedDestination {

    private var _log: AnyObject?
    @available(iOS 10.0, macOS 10.12, tvOS 10.0, watchOS 3.0, *)
    public var log: OSLog {
        get {
            return _log as? OSLog ?? OSLog.default
        }
        set {
            _log = newValue
        }
    }
    
    open override func output(logDetails: LogDetails, message: String) {
        var logDetails = logDetails
        var message = message
        
        // Apply filters, if any indicate we should drop the message, we abort before doing the actual logging
        if self.shouldExclude(logDetails: &logDetails, message: &message) {
            return
        }
        
        self.applyFormatters(logDetails: &logDetails, message: &message)
        
        if #available(iOS 10.0, macOS 10.12, tvOS 10.0, watchOS 3.0, *) {
            os_log("%@", log: log, type: logDetails.level.osLogType, message)
        } else {
            NSLog("%@", message)
        }
    }
}
@available(iOS 10.0, macOS 10.12, tvOS 10.0, watchOS 3.0, *)
extension XCGLogger.Level {
    var osLogType: OSLogType {
        switch self {
        case .info, .warning: /* warning as info, could be also error*/
            return .info
        case .error, .severe:
            return .error
        case .debug, .verbose:
            return .debug
        case .none:
            return .default
        }
    }
}

[fassko]

@phimage Could you make a PR for that? Maybe that can speed up adoption of this feature.

[phimage]

@fassko as you can see here

• https://github.com/DaveWoodCom/XCGLogger/pulls
• https://github.com/DaveWoodCom/XCGLogger/pulls?q=is%3Apr+is%3Aclosed

PR are not merged often

(I will be glad to help to manage issues and PR as I do for many other projects. I already ask for that and for creating a github organisation, but no answer)

[fassko]

@phimage I'm just worried that Info and Debug messages go to memory only. Maybe using Default at least for Info?

[fassko]

@DaveWoodCom maybe you can give access to @phimage to help out. I can also help with reviewing PRs as I'm using this library in one of my apps in production.

[DaveWoodCom]

@phimage Hi Eric.

I don't see any advantage of setting up a GitHub organization. I'd be interested to hear what the benefits would be.

I usually commit useful PRs and fix issues that are pressing in a timely manner, but I try not to push updates more often than are needed. I find it annoying when a library is constantly changing and so I try and keep this one pretty stable and only push out updates sporadically.

I've been saving the os_log feature as a bonus for patreons https://www.patreon.com/DaveWoodX but so far that hasn't earned a single dollar from XCGLogger users. Right now I have to focus on revenue generating projects (I like to eat). Once I ship the upcoming Launch Center Pro, and All the Rings updates, I'll have some time to add additional features here.

[fassko]

@DaveWoodCom I think @phimage mentioned to get access to review and merge PR's to help out with workload what you described in previous comment. I can offer my help as well.

[DaveWoodCom]

@fassko I'd be open to granting access, but I think I'd want to audit code/PRs first. I think it would be irresponsible to blindly grant access to people I don't know and trust. That's how open source libraries are compromised. I know XCGLogger is used in several major applications, including banking apps, so I'm extra careful about every change made to the library.

[phimage]

Hi @DaveWoodCom ,

I do not like to talk on a subject different from the original one I just wanted to justify why I will not PR :p

---

I have emailed you about the benefit of organisation a long time ago and how to manage the access. (but maybe I have used a wrong email address ;( )

---

For organisation the main point is to maintain access to third party log destination project (FireBase, Logentries, loggly, etc..., or nslog), in a same place. (also extract ObjcExceptionBridging in an other project) Then it add some credibility to a project. (remove some fears to adopt it) People want to participate more often.

I am not for giving access to everybody that make a PR, as done by Moya following https://github.com/Moya/contributors , but with all configuration available on github it seems to work pretty well

Grant access to a project do not give access to the code necessarily. You can allow to only manage issues (close it, ...) for the beginning

You can forbid to commit in main branch so review all the code if you need it. You can allow PR only on develop branch, merge only in it, etc... So nothing will be in the main branch without your approbation (Even if you allow commit in main branch, there is no tagged release but if people use "head" code...)

Finally you can see the github profile of people which want access.

[chkpnt]

@phimage I'd rather overwrite func write(message: String) instead of func output(logDetails: LogDetails, message: String) as otherwise, the logQueue isn't used at all, which is inherent for BaseQueueDestination. EDIT: Oh, I see... then you don't have access to LogDetails.