I have also used, and recommend, CocoaLumberjack. I agree with Steph that losing the rolling file logger and log levels would be a bad thing. However, using any third party library is going to bring with it risk of things going wrong out of our control.
My concern with the XCGLogger issues is that the problem is with us, not with the logger. Yes, the crash we are getting should not be swallowed by the logger preventing us from handling it, but the crash is caused by, possibly, low memory or disk space, which is something we're going to suffer from even if we move to another logger. CocoaLumberjack, by providing a more sophisticated rolling file logger than we do may help solve this by managing our disk footprint better, but I think we should investigate why we are causing this particular log error before we blame the logger and just replace it with a new one. On 12 April 2016 at 14:38, Farhan Patel <fpa...@mozilla.com> wrote: > There is also https://github.com/emaloney/CleanroomLogger which does a > few optimizations to make sure performance in Production is good. It is > also written in swift. We also still get different levels of logging. But > it could also bring its own set of bugs. > The thing with using nslog is that because it runs on the main thread > there can be a small performance hit. I think most people recommend not > running nslog in production. > > On Tue, Apr 12, 2016 at 9:28 AM, Steph Leroux <sler...@mozilla.com> wrote: > >> What I am thinking now is this: we are having a lot of problems (crahses) >>> with XCGLogger. I’m thinkiing we should kill it completely. >> >> >> I agree. We seem to have crashes every release related to XCGLogger. >> >> Instead we will write logs with NSLog(), which is managed by the OS and >>> can be easily downloaded with the tool I just linked to >>> >> >> On the downside, we'll lose a couple of things such as: >> >> 1. File/console logging >> 2. Different levels of logging which we use extensively (debug, info, >> error, etc) >> 3. Our abstractions on top of XCGLogger such as the RollingFileLogger. >> >> I think either way we'll need something more than just NSLog to handle >> our logging needs. >> >> Another option I've used in the past is Lumberjack ( >> https://github.com/CocoaLumberjack/CocoaLumberjack). It not only >> contains a similar feature set as XCGLogger but is widely used, maintained, >> and even contains a more complex rolling file logger than we've built. It's >> also Carthage compliant so it could be pulled in with ease. >> >> On Mon, Apr 11, 2016 at 10:56 PM, Stefan Arentz <sare...@mozilla.com> >> wrote: >> >>> I just found http://lemonjar.com/iosconsole/ which is a wonderful >>> little tool that people can use to download both the console log and crash >>> reports from their devices. >>> >>> What I am thinking now is this: we are having a lot of problems >>> (crahses) with XCGLogger. I’m thinkiing we should kill it completely. >>> Instead we will write logs with NSLog(), which is managed by the OS and can >>> be easily downloaded with the tool I just linked to. No more special hacks >>> to get people to submit log files. All we need to do is use the standard >>> logger and tell people to run the app to grab them in case we need >>> diagnostics. >>> >>> S. >>> >>> >>> _______________________________________________ >>> mobile-firefox-dev mailing list >>> mobile-firefox-dev@mozilla.org >>> https://mail.mozilla.org/listinfo/mobile-firefox-dev >>> >>> >> >> _______________________________________________ >> mobile-firefox-dev mailing list >> mobile-firefox-dev@mozilla.org >> https://mail.mozilla.org/listinfo/mobile-firefox-dev >> >> > > _______________________________________________ > mobile-firefox-dev mailing list > mobile-firefox-dev@mozilla.org > https://mail.mozilla.org/listinfo/mobile-firefox-dev > >
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
