NSLogger – a flexible logging tool for OS X and iOS(github.com)
github.com
NSLogger – a flexible logging tool for OS X and iOS
https://github.com/fpillet/NSLogger
21 comments
When I used this tool, I found it exactly what I was looking for. Although at first looking at the name I didn't think it would do the job so renaming it to something that says "a network logger"
Examples: NLogger, CNLogger (Cocoa Network Logger), etc
Examples: NLogger, CNLogger (Cocoa Network Logger), etc
Side question: Did NS initially stand for NextStep, or am I completely off?
That's exactly what it is named.
From what I have read, the prefix used to be NX* in the NeXTSTEP days and was changed to NS* around the time OpenStep came on the scene.
Actually, I believe the actual prefix of NS originally meant Next/Sun whe Next was working with Sun Microsystems. But, who knows? We need one of the original developers to help clear this up.
[deleted]
The project itself is the only thing that uses the NS prefix. The classes within the project have the (rather long and safe) prefix of "Logger".
It's not really a prefix, though, because there's a struct called "Logger", and there are some enums that begin with 'k', and there's a #define called "ALLOW_COCOA_USE", just like something somebody might put in their own code.
If you're writing a library, you really need to prefix absolutely every last stupid symbol, right down to the header include guards. If you don't, even if they don't end up conflicting with something, you'll have people like me moaning about it. (But I don't moan about it because it's never caused me a problem in the past.)
Looks like a neat library though!
If you're writing a library, you really need to prefix absolutely every last stupid symbol, right down to the header include guards. If you don't, even if they don't end up conflicting with something, you'll have people like me moaning about it. (But I don't moan about it because it's never caused me a problem in the past.)
Looks like a neat library though!
I agree with Zev on this. There's no harm if the code itself doesn't use the `NS` prefix -- the concern in the rest of the comments is overblown.
The log viewer and query tools looks excellent.
Here are some (hopefully) constructive comments:
- As others have mentioned, change the NS prefix. Only Apple should be using that.
- The API is not canonical looking Objective-C/Cocoa. It looks like the programmer has a Windows/C++ background
- I only took a quick look but I didn't see logging macros that conditionally compile out logging for release builds
- Internally the logger uses pthreads. This is going to make it difficult on a client that uses Grand Central Dispatch to reason about code when they are debugging something. Consider using queues and operations rather than firing up worker threads. Take a look at CocoaLumberjack for their approach
- Create a Cocoapod to spur adoption
Here are some (hopefully) constructive comments:
- As others have mentioned, change the NS prefix. Only Apple should be using that.
- The API is not canonical looking Objective-C/Cocoa. It looks like the programmer has a Windows/C++ background
- I only took a quick look but I didn't see logging macros that conditionally compile out logging for release builds
- Internally the logger uses pthreads. This is going to make it difficult on a client that uses Grand Central Dispatch to reason about code when they are debugging something. Consider using queues and operations rather than firing up worker threads. Take a look at CocoaLumberjack for their approach
- Create a Cocoapod to spur adoption
Is there a good guide to writing canonical looking Objective-C /Cocoa APIs?
I read the .NET Framework Design Guidelines back when I was doing .NET and it was an excellent how to guide on writing APIs that behaved and felt like they were part of the BCL. Something like that for Objective-C and Cocoa would be a boon.
I read the .NET Framework Design Guidelines back when I was doing .NET and it was an excellent how to guide on writing APIs that behaved and felt like they were part of the BCL. Something like that for Objective-C and Cocoa would be a boon.
There's a .podspec file in the repository and a matching Cocoapod: https://github.com/fpillet/NSLogger
Damn, I have dreamt of something like this for a while, but never sat down to build it. I can't wait to try this out in my next project. A remote client is brilliant, and would have really saved my bacon about a year ago when testing an application in the real world.
I would agree, though, to avoid the "NS*" prefix, but that's been spelled out in a different thread.
I would agree, though, to avoid the "NS*" prefix, but that's been spelled out in a different thread.
Honest question: why does everybody seem to want to compile out logging on release builds? Yes, if you're "printf debugging" that probably shouldn't be in a release build. But I've found the ability to look at (optional, user-enabled) logs invaluable in tracking down some obscure bugs in production.
Performance concerns - whether warranted or not.
Have used this in combination with CocoaLumberjack on a good number of projects and it has come in VERY handy. Highly recommended.
Not too difficult to get it wired up with papertrailapp.com either - That combo makes it VERY handy
Not too difficult to get it wired up with papertrailapp.com either - That combo makes it VERY handy
From someone who hasn't used either, how does this compare to CocoaLumberjack?
I tried using NSLogger a couple months back, but ended up continuing to use CocoaLumberjack, probably because it's just more familiar to me. NSLogger requires one to write the macros that compile out debug logging, where as that's a feature of CocoaLumberjack, but the Desktop viewer I found immensely useful especially for the fact that it archives past logging sessions.
You can actually use CocoaLumberjack with NSLogger's Desktop Viewer though, by adding NSLogger as an adaptor[0], but you're pretty much stuck at the same issue of setting up less-than-trivial conditionals for compiling out the library and adaptor when building release versions. Not a huge issue in itself, but it doesn't lend itself for writing trivial applications.
[0]: https://github.com/steipete/NSLogger-CocoaLumberjack-connect...
You can actually use CocoaLumberjack with NSLogger's Desktop Viewer though, by adding NSLogger as an adaptor[0], but you're pretty much stuck at the same issue of setting up less-than-trivial conditionals for compiling out the library and adaptor when building release versions. Not a huge issue in itself, but it doesn't lend itself for writing trivial applications.
[0]: https://github.com/steipete/NSLogger-CocoaLumberjack-connect...
[deleted]
"Objective-C classes must be named uniquely not only within the code that you’re writing in a project, but also across any frameworks or bundles you might be including. As an example, you should avoid using generic class names like ViewController or TextParser because it’s possible a framework you include in your app may fail to follow conventions and create classes with the same names.
In order to keep class names unique, the convention is to use prefixes on all classes. You’ll have noticed that Cocoa and Cocoa Touch class names typically start either with NS or UI. Two-letter prefixes like these are reserved by Apple for use in framework classes...
Your own classes should use three letter prefixes. These might relate to a combination of your company name and your app name, or even a specific component within your app. As an example, if your company were called Whispering Oak, and you were developing a game called Zebra Surprise, you might choose WZS or WOZ as your class prefix."
http://developer.apple.com/library/ios/#documentation/cocoa/...
In practice many people use two letter prefixes for their classes, you should use a prefix with your classes!
The project looks great, I've been wishing for a more comprehensive logging system with filtering built in for a while now. Thanks!