I am taking over a project which involves upgrading to the latest version of Rcpp and thus I have to upgrade all the old style API calls (which is compatible with the CLassic version I believe). As there is no full API documentation, I am having to do this by trial and error and noting any "undefined reference" errors on linking and then looking through the vignettes/examples. The compile works fine but the errors arise on linking against \inst\libs\RLink.dll. I have manged to convert a lot of the code (mainly using Rcpp::List to extract and pack incoming and outgoing function parameters) but I simply cannot get equivalents for the following:
Rprintf or Rf_error and forward_exception_to_r.
R_NilValue
Rf_install
I am using Code::Blocks 10.05 IDE with RTools installed and Mingw64 referenced explicitly in the toolchain with the GNU GCC Compiler selected. I'd be grateful for any heads up. Thanks.
edit:
I do have #include and before that and (there was a series of errors that were occuring because I had included iostream before Rcpp, which was strange.
Can you please provide some concrete examples, maybe even on the rcpp-devel list? The porting approach works, I too have ported legacy code from the 'classic' Rcpp API, and so have others on the list.
But you do not have to port. The short vignette in the RcppClassic package has details on how to use it in case you want to maintain the old API.
Related
I've been using .NetCore for some smaller projects and I generally love it, but there are a few issues, of which one has been irritating me quite a bit:
In this example a lot of the configuration stuff uses extension methods to hang extra features off of Json, Command Line, Object Binding etc... In these cases all of which live in separate packages. When you see some code examples which typically include one or more of them you naturally copy them into a project to try them out, giving you compile errors when you try to build them.
Asking VS for guidance (pressing good old Ctrl Dot), doesn't help and so you have to search for the relevant packages you need followed by more searches in Nuget installing each one as required.
So my question is (Drum Roll Please) am I missing something or is there a tool/setting or extension that can give me suggestions based on exported extension methods on Nuget's public packages when you press Ctrl Dot on the error much like suggestions on missing namespaces?
Regards
Lee
If you are targeting netcoreapp2.1 you can use the metapackage which will include all of "supported" packages from Microsoft.
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/metapackage-app?view=aspnetcore-2.1
the general questión would be how do I to use any library non-standar in Julia, e.g. libraries exported from C, specifically I downloaded the GNU Scientific Library from https://www.gnu.org/software/gsl/, according the Julia Manual I think it can be used, but I readed the INSTALL file from the GSL folder and I tried follow the steps, however I could not finish them because I did'nt understand some steps.
If anyone could give me some advice to use this library in Julia, I would appreciate it very much.
some details.
-OS: Windows10
-Julia version: 0.6
In the general case,
calling compiled code is done using ccall
For the case of GSL, for most operations you shouldn't be using GSL.
The (almost all) the functionality provided by GSL is well covered by the Julia standard library or by well maintained julia packages.
Mostly with implementation in pure julia.
Pure julia implementations will normally be basically as fast as the C/Fortran implementations.
Plus they will have other good features like working well with the optimiser,
and supporting custom types via multiple dispatch
For example supporting Dual numbers means that ForwardDiff.jl will just natively allow Auto differentiation to work with them.
For some code ducktyping will even let them work with things like TensorFlow..
As to how to install GSL, I think that is a seperate question from how to use GSL with julia.
Conviently though, if you are in a position you absolutely need to call GSL from julia,
there is already a julia package wrapping it. GSL.jl
And particularly conveniently, it will automatically download and install GSL for you when you run Pkg.add("GSL.jl"),
so you don't have to worry about installing it yourself.
If the package isn't working for you, raise an issue on their repo.
(Julia packages tend to be good like that, just installing all their dependencies so you don't have to fiddle around with things. I've been really impressed a few times when colleges have come to me saying "I love R library Foo but I can't using it on windows as I can't get the Fortran backend to work"; and I'll be like "Foo.jl does the same thing using the same fortran backend, also it automatically installs that backend, and does so in a way that just works even on windows.")
I just built installed from the Opam package manager, and am trying to learn how to use value analysis from the tutorial on the frama-c website. I'm currently unable to use the builtin.c file, it's not in my share folder and I cannot figure out how to use -val-builtin (if that's even appropriate).
Any ideas on how to get this going?
I installed the 20151002 release of Frama-c.
Thanks for the help!!
Frama-C "semi-builtins" such as Frama_C_interval no longer need an implementation to be analyzed by Value. Hence, most of builtin.c has been removed, and the rest has been inlined in other files. All mentions of builtin.c in the manual can be ignored, provided __fc_builtin.h is included instead. Similarly, builtin.h has been replaced by __fc_builtin.h. (But a warning is emitted to make the user aware of this fact.) We will update the manuals for Frama-C Aluminium to clarify this.
Regarding which version should be used, I strongly advise you to use Magnesium (20151002). There have been quite a few improvements through the years.
I'd like to get FreeRTOS running on an MSP430 processor using Code Composer Essentials v3.1. I found an example of just this at http://www.westmorelandengineering.com/toc.htm. Specifically I’m working with FreeRTOS_Demo.zip, the top one. When I try to open it with CCE I get an error that the workspace "was not created by this version of Code Composer". So I tried to import the project and I get an error "The Managed Make project could not be read because of the following error: Project type com.ti.ccstudio.managedbuild.ui.programTargetID not found. Managed Make functionality will not be available for this project."
I’m wondering what my problem is and how I can get the project to build, or should I go about this a different way?
FreeRTOS support many, many, many chips and many, many, many compilers. Anything that is not standard C code is kept in a port layer.
The next FreeRTOS release (V7, out in the next couple of weeks and already available in the SVN repository) includes a CCS4 port and demo for the MSP430F5438 (MSP430X core).
Regards.
I was told that TI's CCS compiler suite (used in CCE/CCS) will not build the FreeRTOS sources because the FreeRTOS sources include stuff written in gnu assembler syntax (file extension .s is common between CCS asm and Gnu asm, but syntax is not the same). Until FreeRTOS is "ported" to the CCS compiler suite, your best bet is to use the full CCS with the GCC compiler instead of the CCS compiler.
reviving a zombie thread... not sure if CCE is even relevant now... you can get CCS 5.3 with code-size limited free MSP430 support.
I recently ported FreeRTOS to the CC430 using the new MP430Ware driver library from TI and Code Composer Studio 5.3, get it here:
http://www.freertos.org/Interactive_Frames/Open_Frames.html?http://interactive.freertos.org/entries/22894958-cc430f5137-ccs-5-3
I come from UNIX world, I'm quite familiar with Linux, Solaris, Cygwin
and MinGW development. Recently I ported one of my
big projects (cppcms) to support MSVC,
including building static and dynamic libraries with CMake.
And I get all the time absolutely weird issues:
I had CMake build issues because Windows programming
lacks naming convention
for import and static libraries.
Now I discovered that I should use different versions of ICU (debug/release builds) according to the
actual build I do (Debug/RelWithDebInfo -- should use Debug ICU, Release release ICU) and so I should
change actual conventions for searching libraries according to debug/release mode only under MSVC.
Otherwise application just would not start giving a error on missing DLL.
I don't have any such issues under Mingw or Cygwin with GCC, Open Solaris with Sun Studio or Linux with gcc or intel compilers.
And I still have numerous wired issues and wired bugs and very strange behavior -- even some trivial things do not work
under MSVC builds, when everything works absolutely fine under Solaris/Linux/Cygwin/Mingw using GCC from 3.4 up to 4.4,
Sun Studio and Intel compilers). But not under MSVC.
To be honest, I have no idea how to deal with Last one! Because it looks like for me more like environment issues.
I know that the question is not really well defined. I think I'm quite experienced
developer and I know how to write portable and good C++ code. But using Microsoft native
tools drives me crazy with issues I just don't know how to solve.
Question: What should experienced Unix programmer with quite good base in Win32 API should know when it
starts using Genuine Microsoft Tools?
P.S.: Can someone explain why "Release With Debug Info" requires Debug version of MSVC runtime? And why there two versions of runtime exist at all?
P.P.S.: Please note I don't have issues with Win32 API, in fact Windows GCC build works absolutely fine.
Clarifications:
I'm looking for pitfalls that programmer that come from Unix world would may fall into.
For example, when moving from Linux to Solaris: make sure you compile code with -mt or
-pthreads when using multi threaded programs, linking with -lpthread is not enough.
P.S.: Can someone explain why "Release
With Debug Info" requires Debug
version of MSVC runtime?
It doesn't.
And why there
two versions of runtime exist at all?
Because the debug version does more error checking.
And I still have numerous wired issues
and wired bugs and very strange
behavior -- even some trivial things
do not work under MSVC builds,
* What am I doing wrong?
Not telling us what "wired issues and wired bugs and very strange behavior" you get.
* Where should I start?
By telling us the specific errors and problems you encounter.
* What do I miss?
Reading the documentation and learning the tools.
If your question is "What do I read to become a good Windows programmer?" then my answer is: Everything from Jeff Richter, as a start.
There is no magic bullet which will automatically make you an experienced Windows developer. Windows is a very different land compared to Unix. There are lots of quirks, weird behavior, and stuff which is just plain different. The only way to get out with your sanity intact is to tackle the transition one small problem at a time. Concentrate on a specific problem and try to understand the problem. Don't just "get it to work", but really understand what is happening. A good book about Windows programming will help.
There are huge amounts of Windows knowledge and experience accumulated in the SO community, but the only way to access it is to ask concrete questions about specific problems.
The release and debug versions of DLL's use different ways of allocating memory, that is why it is not advisable to mix release and debug versions. If you allocate something in a debug mode DLL and pass it back to the application which was compiled in release mode you may get into trouble.
In the case of your naming issues you may want to have different directories where you place your static / dll's. You can do do this in visual studio by using the configuration manager, not sure how it is under the express version.
I think you need to try and actually understand the new toolset rather than just try and squish it into your current understanding of your existing tools. For that, the best way, IMHO, is for you to try and start to use Visual Studio as Microsoft intended and then once you can build a simple project in the IDE you can move to building it using your preferred make system but do so with an understanding of how the IDE is using its make system to set things up for that build (which WILL work).
So, for example, for part 1 of your question you want to create a simple static library project and a simple dll project and look at the linker options tabs. Jump to the 'Command line' view and you'll see that a DLL uses the /OUT linker option to set the name and location of the dll file and the /LIB linker option to set the name and location of the import library. With a static library only the /OUT option is used and it indicates the name of the static lib. It's true that if you're building a static lib and a DLL from the same source and you have both the /LIB for the dll set to MyCrossPlatformCode.lib and /OUT set to MyCrossPlatformCode.dll then you may have problems if you also build a static lib with an /OUT switch of MyCrossPlatformCode.lib... Simply don't do that; either build the static libs to a different output directory (which is what OpenSSL does), or, better (IMHO), mangle the names somewhat so that you have MyCrossPlatformCode.lib/.dll and MyCrossPlatformCode_static.lib (which is what STLPort does).
Note that you might also want to mangle in (or account for) building with different versions of the Microsoft tool chain (so you might end up with stlport_vc8_x64d_static.5.1, perhaps).
An alternative approach, if you really can't face the thought of understanding your toolset, is that you could take a look at some of the popular open source systems that build quite fine on Windows and Unix systems; OpenSSL and STLPort for a start, perhaps.