Running a Caffe2 C++ application produces these messages:
E0514 20:37:31.503541 26925 init_intrinsics_check.cc:43] CPU feature avx is present on your machine, but the Caffe2 binary is not compiled with it. It means you may not get the full speed of your CPU.
E0514 20:37:31.504768 26925 init_intrinsics_check.cc:43] CPU feature avx2 is present on your machine, but the Caffe2 binary is not compiled with it. It means you may not get the full speed of your CPU.
E0514 20:37:31.504787 26925 init_intrinsics_check.cc:43] CPU feature fma is present on your machine, but the Caffe2 binary is not compiled with it. It means you may not get the full speed of your CPU.
Caffe2 is informing that the Intel CPU being used has AVX, AVX2 and FMA acceleration features. However, Caffe2 has not been compiled with support for these features. Compiling Caffe2 with support to use these features would speedup training and inference using Caffe2.
To enable use of these features when compiling Caffe2, enable the USE_NATIVE_ARCH option like this:
I installed PyCharm (Community 2016.1) on an Ubuntu 14.04 system. Whenever it is started, it would show this warning:
IBus prior to 1.5.11 may cause input problems. See IDEA-78860 for details.
PyCharm and many other IDEs based on IntelliJ IDEA seem to give this warning on Ubuntu 14.04 which uses IBus 1.5.5. IBus is a framework to enter text in multiple languages in Linux. I guess that this warning goes away if an IBus version of 1.5.11 or later is installed. But since I do not type in any language other than English, I decided to turn off IBus itself.
In XUbuntu, I opened Settings Manager -> Language Support and changed the Keyboard input method system dropdown value from IBus to None. I had to restart the system for this to take effect. The PyCharm warning went away after changing this setting.
Shadow declarations are a major source of misunderstanding and bugs in C or C++ code. C and C++ allow shadow declarations, but this is one of those features that is better not used in production code that needs to be understood and maintained by multiple people.
Use the -Wshadow compiler option to be warned about shadow declarations.
Note that this option is not part of -Wall or -Wextra, so you will need to explicitly add this to your build.
You might find that header files you included from external libraries might throw this warning. (I have faced this with the OpenNI library.) In such a case, ignore this warning only for that particular header file inclusion by using diagnostic pragma, as described here .
When working with C++ code in Eclipse, you might see a Unresolved inclusion warning for some include header lines. This is indicated with a question-mark and an underline squiggle. On hovering the mouse over it, a tooltip is shown with the Unresolved inclusion message.
This is caused when the Eclipse indexer cannot find the header file you have included. This commonly happens when you have installed the library of that header file in a non-standard location.
Open the project Properties and go to C/C++ General -> Paths and Symbols.
In the Includes tab, go to the GNU C++, choose Add and add the path to the directory that contains the above header file.
After re-indexing the code of your project, this warning should be gone.
I have a Primesense camera plugged into USB port. Running any program linked with the OpenNI library throws this warning:
Warning: USB events thread - failed to set priority. This might cause loss of data
OpenNI tries to set the USB async thread priority to critical. This works on Linux only with root privileges. For a normal user, the program will throw this warning. To get rid of this warning, run the program as root.
For more details see ThirdParty/PSCommon/XnLib/Source/Linux/XnLinuxUSB.cpp in OpenNI source code here.
Tried with: Primesense RD1.09, OpenNI 2.2 and Ubuntu 14.04
PyDev can be configured to analyze your code to check if it complies with the PEP8 guidelines. It generates errors and warnings if the code does not comply. For example, E501 complains if a line is longer than 80 characters.
Sometimes, you may want to ignore some specific errors or warnings of PEP8. To do this, go to Windows -> Preferences -> PyDev -> Editor -> Code analysis -> PEP8.py. Here add an --ignore string with the error and warning numbers you want ignored. For example, --ignore=E501. Restart Eclipse for changes to take effect.
Tried with: PyDev 3.9.0, Python 3.4.0, Eclipse Luna 4.4.1 and Ubuntu 14.04
To learn how to install and use Syntastic, please see this post.
Syntastic should be able to detect the C++ compiler on your system and use it for syntax checking automatically. If you need to change it or set it explicitly, then add its command or full path to your .vimrc:
let g:syntastic_cpp_compiler = "g++"
You might want to enable some compiler options for Syntastic to apply on your code. For example, I like to add support for C++11 and also rigorously check for warnings, so I add this to my .vimrc:
let g:syntastic_cpp_compiler_options = "-std=c++11 -Wall -Wextra -Wpedantic"
The GCC and G++ compilers have many warning options that can be useful to improve the quality of your code. All the warning options are listed and described here.
Since the list of warnings is very long, GCC provides a few warning options that are a shortcut for enabling a larger bunch of warnings. These warning options are -Wall, -Wextra and -Wpedantic.
The warnings enabled by -Wall and -Wextra is listed along with their description. However, this is not provided for -Wpedantic. I went through the individual warning descriptions and found the warning options enabled by -Wpedantic:
Warning options enabled by -Wpedantic:
It can very useful to know which of the warning options are not enabled by -Wall, -Wextra and -Wpedantic. These are the options that might be useful for debugging or improving particular problems with your code. Again, I went through the individual warning descriptions and here they are:
In most scenarios, this warning is good since you find out that maybe this parameter is not being used currently, so it can be removed from the definition, declaration and the calls.
However, sometimes the function definition cannot be changed. For example, if the function is a callback that is required by a library. In such a case, the function signature cannot be changed even if you are not using that parameter inside your callback.
There is a simple solution for this scenario: remove the parameter name, just keep the parameter type. For example, to fix the function shown above, you could change its definition to:
string IntToString(int num, int)
// Code of function here
This keeps the function signature, so it still works with the library. But since the parameter name is gone, you no longer get the warning. 🙂