I changed my working station to a new computer and installed R, Rtools, Rstudio and Rcpp, etc. When testing my installation, I simply created a new C++ file as this:
Then there will be a default C++ code to illustrate the use of Rcpp, but after I saved the file as test.cpp, the code diagnosis in Rstudio gave me the red mark:
This should not happen because I can compile the code and sourceCpp with no problem, and the function is correctional displayed in R. I was using the latest Rstudio, and then I changed to an older version, but the red mark still exited.
So I'm wondering how could that happen. I don't want to turn off the code diagnosis for C++ file since it's useful, but for sure I don't want every line of my code being marked. Does anyone know what's going wrong in my case?
Related
I first attempted this by getting the stock source from OpenSSL's website. That wasn't fun.
Then I clued in, and I got the source from here.
When I try to build from Xcode, it fails with several warnings and 1 error.
/Users/x/OpenSSL098-OpenSSL098-76.200.2/src/crypto/x509/x509_vfy_apple.c:29:10: Did not find header 'TrustEvaluationAgent.h' in framework 'TrustEvaluationAgent' (loaded from '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/PrivateFrameworks')
I had assumed that the patches included in this tarball were already applied, and when I attempt to run the bash script to do that, it complains that there is no (openssl) source tarball... that's ok (I think), there is already a populated src/ directory. I modified the bash script enough that it would ignore that, and indeed, when it goes to patch it gripes the patches are already applied. The README.rtf file (Apple's) is suggestive that this is only if I wish to use the patches against a later version of the source, which I'm not much interested in.
It's not clear to me if my Xcode is just mangled beyond recognition, if I'm missing some dependency, or if I don't know what I'm doing within the Xcode interface (much more comfortable on the command line).
I did find this, which seems like a related issue... but I cannot find the source code he suggests needs to be uncommented (nor how to remove the references from the project file).
Can anyone point me in the right direction?
But for the unclear English, the instructions in the second link are correct.
Delete the x509_vfy_apple.c file from the treeview on the left, it will be in the Source/crypto/x509 folder. Then in x509_vfy.c (same folder), there will be an #if directive near line 76. It's defined as...
#if __APPLE__
Make that...
#if 0
Somehow I brainfarted on this and made it #if 1 on the first try, and then dismissed the instructions as not working. Commenting this out would also work, or just nuking the entire directive for that matter.
Still seems to compile with a zillion warnings, but I'm not even sure that just isn't what you get with a 7 year old version of openssl.
I don't have formal VS training, and I usually use it to program simple tools for my research. (I'm a faculty member).
I'm currently working on a C++ library for Python using SWIG, so I followed the steps suggested in How to create a DLL with SWIG from Visual Studio 2010?
Step no. 25 says "You can't build the Debug version unless you build a debug version of Python itself", but I thought one should be able to build a debug version of the C++ stuff by writing a main that uses the library from C++ itself, without touching Python or involving Python at all. (Please let me know if I'm wrong.)
A while ago I tried creating two projects in one solution (one for the library, one for a testing app), but I wasn't quite convinced with the result, so I thought it was time to try configurations. I modified the Debug config for my SWIG project following the suggestions in Redifining C/C++ entry point in Microsoft Visual Studio 2015 and the comments (changed configuration type, extension, and entry point, and added additional dependencies vcruntimed.lib and ucrtd.lib, also excluded from build the .i and the _wrap.cxx files).
The project compiles and runs, but the methods/functions in the standard <random> C++ library are returning non-random numbers. Update/clarification: In the following code,
std::normal_distribution<double> rand::distn(0, 1);
std::uniform_real_distribution<double> rand::distu(0, 1);
std::mt19937_64 rand::generator;
void rand::init() {
generator.seed((unsigned long)time(NULL));
}
double rand::u01()
{
return distu(generator);
}
the function u01() returns 0.0 always, while when calling it from Python it works as expected.
I checked the code and the generator is being seeded correctly. Also the library is still working fine from Python, so I tend to think this is not a coding but a configuration issue.
I know this would make a better question if I posted a minimal working example, but before investing time (which I think I don't have) on it I was wandering if there is something obvious I'm missing, that a more knowledgeable VS user could easily spot. Please don't get me wrong, if I'm mistaken and the answer is not so apparent, I'll really try to make the time.
Thanks in advance.
Im working on Arduino Uno board recently im stuck with my code, i couldnt debug using print() in ArduinoIde.So i downloaded AtmelStudio 6.2 for debug purpose.
when i set the breakpoint and try to build .Im getting the warning
The breakpoint will not currently be hit. Unable to set requested breakpoint on target.The current selected deviceis unable to set breakpoints during runtime
please help me sort this issue
Following workarounds worked with the same problem using ATMega 168P on Atmel Studio 7 with Atmel-ICE.
1. Assembler
Insert the following assembler code where you want your breakpoint:
asm("break");
Please note, this is a really ugly solution and not suitable for all situations. It only works with DEBUGwire and makes your program stop in any case, even if no programmer is attached.
2. Create new project
Creating a new project at a different location helped as well. I copied all the required files to the new folder. The new location has a short path (C:\atmel\project...) and contains no spaces, no umlauts etc.
I had a similar problem, the difference was that I could only hit breakpoints in the original modules of my project (i.e. those already existent when I created the .cproj), any modules I added later wouldn't have the program stopped in breakpoints placed on them.
The solution (2) mentioned by #pafodie worked to solve this, but in the process I found a simpler way: just delete the .atsuo file. It will later be automatically recreated, and the problem disappears (at least until you add more modules). It seems AS6 caches something there that isn't updated when new files are added, or does it incorrectly.
I might've found a solution that works, for me at least! You need to disable compiler optimization. In Atmel Studio,
Hit Alt+F7 > ToolChain > Optimization {there are 2 Optimization
windows but only one fits the shoes} > Optimization level > None
I found it here, explained better than I did: https://www.microchip.com/webdoc/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD/index.html?GUID-8FF26BD2-DBFF-48DD-91FB-8585D91A938D figure 5
If using external Makefile, make sure the -g (debug) flag is set in CFLAGS.
Otherwise, Atmel Studio would have no idea how the source files correspond to the compiled binary.
I'm curious if anybody could help with a problem I'm having. I just downloaded and installed the SDL 2 framework, along with the example programs that come with it, from Mercurial (http://www.libsdl.org/hg.php) onto OSX Mavericks (10.9).
I am attempting to run the example native cocoa code in Xcode 5.1.1, which includes the files testnative.h, testnative.c, and testnativecocoa.m that come from the tests folder in the Mercurial download.
I am successfully able to build the program, but as soon as it hits the function SDL_CreateWindowFrom(native_window), the program crashes and highlights the following line of a file called SDL_cocoakeyboard.m:
nswindow = ((SDL_WindowData*)window->driverdata)->nswindow; Thread 1:EXC_BAD_ACCESS (code=1, address=0x8)
The only thing I did with the original files was change the include headers from SDL.h and SDL_syswm.h to SDL2/SDL.h and SDL2/SDL_syswm.h in testnative.h. I've included both the cocoa and SDL2 frameworks in the program, and I turned off automatic reference counting, which was necessary to get the example code running.
I have no idea where else I could be going wrong, since the code before the aforementioned line looks and runs fine (it's able to create the cocoa window before it crashes).
Any insight on this issue would be great. Thanks in advance!
I was wrong in the comment, driverdata is null (never initialized), some code like SDL_cocoawindow.m:SetupWindowData would be required, but SetupWindowData is static (not global) and adding a minimal initialization would require SDL_cocoawindow.h(but isn't public).
So, my guess (maybe I'm wrong) this testnative isn't working, at least not with current SDL2 (the wrong #include should have been a sign) but a fast look into SDL2 shown there's enough cocoa code to hope there are other ways to get a native window working.
A good start How to set up a SDL 2 project for OS X in Xcode 4
I am currently trying to calculate rigid transformation between two point sets so I tried to use the code given by the tutorial on pointclouds.org:
http://www.pointclouds.org/documentation/tutorials/iterative_closest_point.php#iterative-closest-point
For my case I only changed the part where the data is randomly generated to something that loads the point data I want to analyze. Everything else is exactly like in the tutorial...
(I also tried testing exactly the tutorial code with the random data, in case I had somethign wrong with reading my input data)
Since I work with Qt I integrated the PCL library, Eigen library and FLANN library to my project. It finds all headers and successfully compiles with MSVC 2008...
Unfortunately I always get a runtime error at
icp.setInputTarget(cloud_out);
saying:
Debug Assertion failed! Program:
...MSVC2008_Qt_SDK_Release\release\Project.exe File: c:\Program
Files\Microsoft VIsual Studio 10.0\CV\include\vector Line: 1200
Expression: vector erase iterator outside range
[..] ... check documentation ... [..]
Does anybody know what that means? The input clouds both have the same size and have filled values.
I would be thankful for any help!
UPDATE 1:
The error message shows some file path for MSVC 2010 (10.0) ... So I tried to uninstall Visual Studio 2010 since I don't really need it. But still, if I compile in Debug mode, it shows me an error message, but with Expression: vector iterators incompatible instead... If I now run it in Release mode, it just crashes at runtime (at the same line), but doesn't show that error message.
This seems so be a problem with the library you use. Assuming you have done a clean build, checked your PATH variable and everything and that Visual Studio 2010 is removed, this might be a problem with the library itself. Are you you using the right one?
The current Qt SDK has MSVC2008 in it, so I guess it takes everything from where it needs. But either the compiler in Qt or one of the libraries you use that might want the 2010 version...
Hope it helps!