I am using pkyeck / socket.IO-objc framework. It is very good, however I am unable to debug with the verbose logs it produces to the lldb, which makes the console constantly full with descriptions about traffic, which are useless to me at the moment. I couldn't find a way how to turn it OFF. Anybody knows how to do it? I just can't imagine myself commenting out all the lines with NSLog...
Found the solution. It is rather undesired to tinker with the source code of the framework - usually it is a good practice to take it AS-IS but since there wasn't any other way...
In the file SocketIO.m, locate line numbers 32 - 39:
#define DEBUG_LOGS 1
#define DEBUG_CERTIFICATE 1
#if DEBUG_LOGS
#define DEBUGLOG(...) NSLog(__VA_ARGS__)
#else
#define DEBUGLOG(...)
#endif
Naturally, everybody now knows what comes next - change the value of DEBUG_LOGS to 0.
That's it, done. I recommend adding a //TODO: to the line above in order not to forget for the next time, when debugging logs are desired.
Related
Here is my customized NSLog.
#define NSLog(fmt, ...) printf("🌳🌳🌳%s,%d\n %s\n\n", __PRETTY_FUNCTION__, __LINE__, [NSString stringWithFormat:fmt, ##__VA_ARGS__].UTF8String)
This log is work good on another project, but it occurred 4 error when compiler time in current project. If using __VA_ARGS__, like #define NSLog(...) NSLog(__VA_ARGS__), it's going to compile successful. I think that maybe caused in Building Setting.
It's anyone has any idea to help me to solve this.
Check that the header file declaring this imports Foundation. Check that you don't have NSLog defined somewhere else as well and finally, really not a good idea to redefine NSLog. You're probably better off adopting a logging framework or defining your own like this:
#define MELog(fmt, ...) NSLog("🌳🌳🌳%s,%d\n %s\ ....
Apptentive seems like a good addition to have. However it pollutes the Console with so many messages, that is unnecessary to see every time. It is distracting me from seeing important debug messages elsewhere.
Only an extract:
2015-05-10 10:15:45.134 xNews[34355:4228197] Loading ATSwizzle_NSObject_Bootstrap
2015-05-10 10:15:45.134 xNews[34355:4228197] Loading ATSwizzle_UIViewController_Bootstrap
According to the docs it's possible to disable them:
#import "ATConnect_Debugging.h"
[ATConnect sharedConnection].debuggingOptions = ATConnectDebuggingOptionsNone;
This doesn't work at all. I still get to see all those debug messages I don't care about. Any advice please?
The Apptentive debuggingOptions property does enable/disable some debug features, however it's true that we aren't tying that in with the log levels.
// #import "ATConnect_Debugging.h"
[ATConnect sharedConnection].debuggingOptions = ATConnectDebuggingOptionsNone;
I will make a note to add a new debuggingOptions option to silence all logging for an upcoming version of the SDK.
Apptentive does allow control over log levels via the ATLog.h file and preprocessor macros:
AT_LOGGING_ENABLED = 1
AT_LOGGING_LEVEL_INFO = 1
AT_LOGGING_LEVEL_DUBUG = 1
AT_LOGGING_LEVEL_WARNING = 1
AT_LOGGING_LEVEL_ERROR = 1
By default, release configuration of the Apptentive SDK will log only the warning and error log levels. Debug builds will log the more verbose info and debug levels.
In your Xcode project you should be able to set AT_LOGGING_ENABLED = 0 to silence all Apptentive warning. Or toggle the log levels as you see fit.
Thanks for using Apptentive! Let me know if you need any assistance with this.
It is unclear to me when using compiler directives which of the below two code snippets is correct/preferred and why. It seems that most developers and Open Source projects I've seen use the first but I have seen the second used frequently as well.
#ifdef DEBUG
[self doSomethingOnlyWhenDebugging];
#endif
VERSUS
#if DEBUG
[self doSomethingOnlyWhenDebugging];
#endif
Which of the above code snippets is preferable for running code only while debugging and why? My guess is that the first will run if DEBUG is defined as TRUE or FALSE where the second will run only if DEBUG is defined and set to TRUE. Is that correct?
You are correct. #if DEBUG will not evaluate if DEBUG is defined as 0.
As for when to use each, you can stick to using #ifdef for anything where you only need to add code if the preprocessor definition is present, such as adding debug logging. If you need to inspect the value and go down different compilation paths, then I would use a 0 or 1. A good example of that is TARGET_IPHONE_SIMULATOR, which is always defined for an iOS project, but only 1 if you’re compiling for the simulator.
As I know, the finest choice is:
#ifndef DEBUG
NSLog(#"-1");
#elif DEBUG == 0
NSLog(#"0");
#else
NSLog(#"%d", DEBUG);
#endif
then, you will know #ifndef DEBUG is preferred above all others.
There is a simpler choice:
#if DEBUG == 0 // DEBUG is not defined or defined to be 0
// do sth
#else
// do sth
#endif
However, if -Wundef compiler flag is on, there might be a warning with #if DEBUG == 0.
You need to look at the code where DEBUG gets defined or not defined, and write your code accordingly. With DEBUG, you will find that it is either not defined, or defined with a value of 1. So either #if DEBUG or #ifdef DEBUG will work.
For #define's that are under your control, I recommend that you always define them, either with a value of 0 or 1. You can then use #if to check for the value, but you can also use them directly in an ordinary if statement or in an expression, which may make your code more readable. And since it is always defined, you can use "Jump To Definition" in Xcode to go to the place where it is defined and check how and why it is set. If instead you either #define or not #define the value, and it is not defined, then Xcode will have no idea where in your source code it is not defined. It also gives you a chance to look for misspelled uses. If "Jump to Definition" doesn't work, then you know you have spelled it wrong.
BTW Within an #if directive, any macro that is not defined is replaced by 0. So #if DEBUG will work if DEBUG is not defined, or if DEBUG is defined as 0, and it will not compile if DEBUG is defined as nothing - which will tell you what is wrong so you can fix it. From that point of view, using #if is better unless it doesn't compile.
I want to disable NSLog() across all instances in an app. I found some code that does that:
#ifndef DEBUG
#define NSLog //
#endif
But adding this code to each file isn't good idea. How can I make it easier?
Xcode has a precompiled header file ({project-name}-Prefix.pch in the Supporting Files group by default) that is a great place to put code that will be used across every file in the project. For going a step further and improving the log message itself, see Is it true that one should not use NSLog() on production code?.
Add the following lines to your constants file:
#define DEBUGGING NO //or YES
#define NSLog if(DEBUGGING)NSLog
The two following sentences give the same results
#define NSLog
and
#define NSLog //
because all text that begin with // are deleted in a precompiling phase ("//" included)
What I do is put this in the precompiled header file (YourAppName.pch):
#define MyLog if(0); else NSLog
Then I change all NSLog to MyLog everywhere else in the app. It works as if it were NSLog. But when you want to disable NSLog, go back to the .pch file and change the 0 to 1 and presto, all logging stops.
This will also take care of the warnings that arise when using
#define NSLog //
The code:
#ifndef DEBUG
#define NSLog(...)
#endif
Just add the following lines when you do'"t need NSLOG to your constants file
#define NSLog //
and comment it when you need it.
I really like to temporary enable and disable code parts by commenting them this way:
/*
some code
/**/
(Mind the
/**/
instead of
*/
at the end)
However, XCode keeps giving me the warning:
/* within block comment
Is there any way to "custom-disable" specific warnings?
WHY? I will tell you why: Because I can easily take it in and out with only one character, without having to scroll down the block to take the "*/ in and out.
When I want to temporarily remove a block of code I use:
#if 0
somecode();
#endif
Which avoids this issue and is easy to spot later.
If I want to later temporarily re-enable that code, then I simply flip the 0 to 1:
#if 1
somecode();
#endif
However if this enable/disable needs to be more visible, and easier to control, then I use a constant defined at the top of the source file instead:
#define SOME_FANCY_FEATURE 1
...
#if SOME_FANCY_FEATURE
somecode();
#endif // SOME_FANCY_FEATURE
I found a very nice alternative to:
/*
some code
/**/
You can just use this variant:
/*
some code
//*/
to achieve the same goal without any Xcode warnings!
The real answer for me (just disabling an XCode warning, without changing any line in legacy code) is here: https://stackoverflow.com/a/21046102/540639
Apple LLVM 6.0 Custom Compiler Flags -> Other Warning Flags -> -Wno-comment