Some time ago I enabled Clang diagnostics in Rstudio for Rcpp.
I don't remember exactly how, but it was some line to start it for either here or on another site.
Now every time I edit Rcpp code I get constant Clang updates in the console such as:
clang version 5.0.2 (tags/RELEASE_502/final)
Target: x86_64-pc-windows-msvc
TOTAL MEMORY: 41 mb (cpp1exception.cpp)
PERFORMANCE 285 ms (cpp1exception.cpp)
The real problem is that this diagnostic seems to slow down input. I type something, anything, and the the GUI, Rstudio seems to pause, until the Clang output finishes.
So I simply want to turn of the Diagnostics or make it how it was before.
Update:
The code to turn it on was found here: Rstudio no autocomplete with Rcpp Armadillo?
Specifically the line .rs.setClangDiagnostics(2).
Once I found that I used .rs.setClangDiagnostics(2) after some searching I found that I need to simply use:
.rs.setClangDiagnostics(0)
To turn it off, and it did.
Related
Since some years ago I started using Qt in both Windows 7 as well as in Linux Ubuntu and it would always compile fast with MinGW being used for Windows. But in the last couple of years or so, maybe thanks to updates in the version of both Qt and MinGW, I started detecting a slow down in the compiling speed inside Windows. I did some research trying to find why MinGW had started to become so slow compared to Linux (it wasn't before!) and everything people told me was that MinGW was slower in Windows and that it would be better, if possible, to just use Linux.
Since I wanted to continue my project, I followed the suggestion and since I've being using Linux with relatively no problems. The situation now is that I must go back to Windows (now updated to Windows 10) to make visual corrections for this OS and I need to once again work with MinGW having to face the same problem as before.
But for some reason it seems that the slowness of MinGW became even worse! While before I at least was able to compile the app in around 4 minutes, now the last time I tried it took 38 minutes before I gave up and went to sleep - and this is for a project that takes only 1:03 minute to be compiled in Linux [under the same compile configuration]!
Well I'm still aware about the slowness of MinGW, but as a quick research around this problem on the web reveals, that is just too slow: all backtesting one can find in other threads here on SO reveals at best 2x-3x more time to compile a project, not 38x+!!
So I would like to know what kind of possible problems I might have in my Windows for this exaggerated slowness to happen. I know I ended up installing at least 4 different versions of MinGW; could this have brought the problem?
It's interesting also to notice that when compiling using the -j option and watching the Compile Output log in Qt Creator alongside Process Explorer, there are moments when the compiling simple pauses for 10 seconds or more and the CPU usage drops from its ~100% to close to 5% with nothing happening till it suddenly continues the compilation process. I'm sure this constant pauses are part of the above average time, but I have no idea why MinGW is showing this behaviour.
You might want to check where the time is spent.
There a lot of tools that allow you to capture what a certain process is doing, I name just two of them:
ProcMon
XPerf or its successor
But to analyze the reports generated by these tools you need a rather deep understanding. If this doesn't help temporarily disable other running services and program step-by-step (if you want to know which program causes the problem) or disable all of them at once.
Looking at the spikes of cpu usage that TaskManager or Procexp by sysinternals show might help too to identify those components that block your cpu.
If your antivirus is the cause of the collision that makes the compile so slow you can define exceptions, then the antivirus will not scan certain programs or paths.
So perhaps it is easier to first try the compilation process with a disabled antivirus software or even from a clean live boot Windows CD.
I have a GCC 3.4.3 toolchain built for ARM (arm-elf) here in my Windows 7 (64bits) setup. We use this to build our software product to a specific hardware.
Recently, we have been experiencing some problems with this particular toolchain.
First, when we try to call arm-elf-gcc to build each source file (there are lots of them), it complained about it not being able to allocate enough heap.
Then, I thought it was some problem with the outdated cygwin DLL distributed by the hardware vendor. So I replaced it with a more recent version (1.7.35). The problem stopped and the build does go ok but now it is incredibly SLOW (it took about 40s to build a single .c source file).
Does anyone has experienced this problem before? How can I debug and fix it?
Thanks in advance.
Sounds like you have had a similar problem to me and might be worth trying this. When i first encountered this, I had to install cygserver and then run this (make sure you right click admin):
Previous solution
However, the problem resumed and I simultaneously couldn't install/uninstall some problems. Eventually I resolved this by terminating SearchIndexer.exe in Task Manager. Indeed, I have gone in to Control Panel / Searach Indexing and pulled it back from doing any indexing. My installation taking 1hr took 3 more seconds. The change to Cygwin was instantaneous.
Cygwin is now flying!
I've had an issue with slow execution of builds for a while on cygwin, using make and a proprietary compiler that "isn't gcc, honest...", but has very similar error returns.
I was forced to update yesterday and ran into the issue of rebaseall simply failing to execute. This forced me to dig into other things and I found a report that Trusteer Rapport/End Point Protection has been known to cause issues with rebaseall,and slow response times. So I removed it. This fixed the rebaseall, but has also massively increased the speed of my build. Worth checking to see if you have it installed, try removing it. AV packages in general are reputed to interfere and may be the cause.
I am trying to debug a few C++ applications with KDevelop 4.0.1(on KDE 4.4.5 and gdb 7.0.1) on Debian 6.0.6. Irrespective of what part of the code I break into, the debugger detaches automatically after stepping through a few instructions. I didn't find anything on this topic on any forums. I tried a few things below.
Debugging using gdb on shell works perfectly fine.
Tried debugging multiple applications, but the issue is seen.
Reinstalling KDevelop did not help.
Am I missing some configuration that could cause this behavior?
(I am new to kdevelop)
Thanks for any help.
My guess is that is related to pretty printing of an uninitialized variable.
Lots of fixes have been applied to KDevelop and gdb, you should consider updating to a more recent version.
first off, I really need to make a 64bit version of glfwdll.a and glfw.dll (so I can hopefully finally succeed in getting the Go glfw bindings to work under Windows ... was a breeeeze under Linux!)
Seems like I now succeeded in compiling 64bit versions of glfwdll.a and glfw.dll using mingw64, MSYS and their make scripts, even though I did get a couple of error messages along the lines of "maincrt entry point not found, using default 0xsomehexnumber instead" or some such. Entry points of course refer to executables, in this case those in the examples directory.
And indeed, most of them don't work! All got built however. The following executables work:
listmodes.exe mtbench.exe mthello.exe and particles.exe -- the latter being the only graphical (3d gfx) example working for me (the former ones just outputting some test infos onto the console window).
Now what's the issue with the other ones? They don't crash, they don't report anything to the console... I run them, they return immediately, silently.
Is my GLFW build broken? How to fix? What's the big difference between the 4 examples that work and the others that don't?
This is a fairly new, vanilla Win7 64bit installation. No crapware, everything up to date, UAC and Themes are off, not a lot of software installed at all, Nvidia GPU driver updated (GPU Caps Viewer and the likes run fine, so OpenGL is there).
I'm not yet allowed to add comments, so I'll post this as an answer.
The issue you're having is due to three separate bug in GLFW. I fixed them today and the fixes will be included in GLFW 2.7.6. Until then, you can use trunk from the GLFW Subversion repository.
To be sure that you really have no DLL-hell issues with the opengl32.dll, glu32.dll, glut32.dll etc., check out the Event Viewer tool and see if there are some warnings or errors for you app.
This is my thought because you are only able to run the mtbench and mthello which have nothing in common with the "real" OpenGL API.
No clue about particles.exe though - maybe GLFW checks for errors internally and call the exit() routine ? Check the %errorlevel% also.
Also take a look here:
http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/examples/pong3d.c?revision=1110&view=markup
There is a GameMenu() function which may exit silently if "!glfwGetWindowParam( GLFW_OPENED )", which obviously means that OpenGL was not initialized.
The same function serves as an exit flag here
http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/examples/wave.c?revision=1110&view=markup
Once again, double-check the DLLs !
I believe that you are experienced not to make "advanced" mistakes in the build process, so there just might be some funny thing happening at the "user level".
And another suggestion:
http://sourceforge.net/projects/glfw/forums/forum/247562/topic/3868944
Some parameters might not work exactly for you.
To "fix" the samples try commenting out the glfwGetWindowParam call.
I can't find a way for cgdb to disassemble a binary and show the assembly code with the current instruction in the code window. Is this possible and what command should I use? I'm using Mac OS X and got cgdb from the homebrew repository.
display/i $pc shows disassembly always for the current instruction, in the console window.
To show disassembly for more instructions, prefix i with the number of instructions.
For example,
display/5i $pc
shows disassembly always for the next 5 instructions.
A recent update (Feb 2017) to cgdb makes it possible to do this. You will need cgdb version 0.7.0 or newer. (At the time of writing this is the latest release). You may need to compile this from source yourself given how recent it is.
More details on adding disassembly support can be found here:
https://github.com/cgdb/cgdb/issues/44
To view the disassembly in cgdb hit esc and type :set disenter.
To go back to the source (if available), repeat this, except type :set nodis.
I am working on MacOS to defuse a binary bomb and find "gdb -tui" will be helpful. Than I found "cgdb" can make code colorful. But what we want to see is show disassembled code on the code window, the answer above only show the code line by line or only changeless lines.
Unfortunately, I find a post said that "the cgdb does not support assembly display (yet)."
https://groups.google.com/forum/#!topic/cgdb-users/E-jZCJiBAQQ
Sorry guys, cgdb does not support assembly display (yet). It's a
frequently requested feature, and when we get a little more time to
work on cgdb we will probably add this.
Starting cgdb with the -tui option is a bad idea -- the TUI (text user
interface) is an alternative curses interface to gdb, not a part of
cgdb. It will not play nice with cgdb.
Mike
--
Mike Mueller
Well, it's 12/11/15, but it seems still couldn't show the assembly code on code window like gdb in tui mode.