similar to: Windows gcc toolchain for R 3.2.0

Duncan, ----- Original Message ----- > From: "Duncan Murdoch" <murdoch.duncan at gmail.com> > To: "R-devel at r-project.org" <r-devel at r-project.org>, rcpp-devel at r-forge.wu-wien.ac.at > Sent: Wednesday, March 18, 2015 6:27:26 AM > Subject: [Rcpp-devel] Windows gcc toolchain for R 3.2.0 > > To anyone following the Windows toolchain saga: >

To anyone following the Windows toolchain saga: The gcc 4.9.2 toolchain that is currently in Rtools33 has too many incompatibilities with existing code, so we won't be using it in the R 3.2.0 build. I will soon be uploading to CRAN a new version of Rtools33 that is very similar to Rtools32, containing gcc 4.6.3. We are continuing to work on the new toolchain, and hope to have it ready

My apologies for cross-posting. I found this site, after I had posted on stack-overflow. I need to compile several static libraries (C & Fortran) which will later be linked with an R package. Rtools33 directory includes /i686-w64-mingw32 directory which I understand creates 32 bit binaries. Yet, there are other 64 bit directories as well. I have three related questions: 1. Can

On 30/05/2015 13:14, Duncan Murdoch wrote: > On 29/05/2015 4:16 PM, Sue McDonald wrote: >> My apologies for cross-posting. I found this site, after I had posted on >> stack-overflow. >> >> I need to compile several static libraries (C & Fortran) which will later >> be linked with an R package. Rtools33 directory includes /i686-w64-mingw32 >> directory

On Tue, Mar 10, 2015 at 4:07 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 09/03/2015 11:02 PM, Hsiu-Khuern Tang wrote: >> Hi Duncan, >> >> On Mon, Mar 9, 2015 at 10:40 AM, Duncan Murdoch >> <murdoch.duncan at gmail.com> wrote: >>> On 09/03/2015 11:07 AM, Hsiu-Khuern Tang wrote: >>>> >>>> On Mon, Mar 9, 2015 at

Hi Duncan, On Mon, Mar 9, 2015 at 10:40 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 09/03/2015 11:07 AM, Hsiu-Khuern Tang wrote: >> >> On Mon, Mar 9, 2015 at 3:50 AM, Duncan Murdoch <murdoch.duncan at gmail.com> >> wrote: >> > On 08/03/2015 10:02 PM, Hsiu-Khuern Tang wrote: >> >> Hi, >> >> >> >> [This

On Mon, Mar 9, 2015 at 3:50 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 08/03/2015 10:02 PM, Hsiu-Khuern Tang wrote: >> Hi, >> >> [This is a follow-up to the "New version of Rtools for Windows" thread >> in January, but I just subscribed and don't know how to reply to an >> old thread -- my apologies.] > > I am planning to

On 29/05/2015 4:16 PM, Sue McDonald wrote: > My apologies for cross-posting. I found this site, after I had posted on > stack-overflow. > > I need to compile several static libraries (C & Fortran) which will later > be linked with an R package. Rtools33 directory includes /i686-w64-mingw32 > directory which I understand creates 32 bit binaries. Yet, there are other > 64

On 11/03/2015 3:09 PM, Dan Tenenbaum wrote: > > ----- Original Message ----- > > From: "Duncan Murdoch" <murdoch.duncan at gmail.com> > > To: "Dan Tenenbaum" <dtenenba at fredhutch.org> > > Cc: r-devel at r-project.org > > Sent: Wednesday, March 11, 2015 12:06:48 PM > > Subject: Re: [Rd] Notes on building a gcc toolchain for

On 09/03/2015 11:02 PM, Hsiu-Khuern Tang wrote: > Hi Duncan, > > On Mon, Mar 9, 2015 at 10:40 AM, Duncan Murdoch > <murdoch.duncan at gmail.com> wrote: >> On 09/03/2015 11:07 AM, Hsiu-Khuern Tang wrote: >>> >>> On Mon, Mar 9, 2015 at 3:50 AM, Duncan Murdoch <murdoch.duncan at gmail.com> >>> wrote: >>>> On 08/03/2015 10:02 PM,

WRE explains that R_alloc() can be used to allocate memory which automatically gets released by R at the end of a .C, .Call or .External, even in the case of an error or interruption. This is a really great feature to prevent memory leaks. I was wondering if there is a way to extend this mechanism to allow for automatically running UNPROTECT and custom finalizers at the end of a .Call as well.

Hello! I (try to) convert the external R header files to Pascal (Delphi). At one place I stumbled over a macro that uses a method that is not declared in a LGPL header file: In Rinternals.h: #define error_return(msg) { Rf_error(msg); return R_NilValue; } #define errorcall_return(cl,msg){ Rf_errorcall(cl, msg); return R_NilValue; } ~~~~~~~~

I was debugging a problem reported to me regarding PL/R, and found that I can duplicate it using only R sources. It might be characterized as possibly a misuse of the findFun() function, but I leave that for the R devel experts to decide. The below results are all with R-2.5.1 (I can't seem to download r-patched at the moment, but didn't see anything in the 2.5.1-patched release

The Bioconductor build for a package DirichletMultinomial on R Under development (unstable) (2013-02-26 r62077) -- "Unsuffered Consequences" at http://bioconductor.org/checkResults/devel/bioc-LATEST/DirichletMultinomial/george2-buildsrc.html shows * creating vignettes ... ERROR ... Error: processing vignette ?DirichletMultinomial.Rnw? failed with diagnostics: chunk 21 (label

Dear R-devel, My g++ complains about the first argument to Rprintf being non-const char *. For example when compiling the line Rprintf("hello world\n"); the following warning is emitted: warning: deprecated conversion from string constant to 'char*' Is there a reason for the non-const? It is curious that Rf_error, which is similar to RPrintf, is const. If there is a need

On Wed, 2015-03-18 at 07:55 -0700, Dan Tenenbaum wrote: > Is it not considered a "known problem" that C++ libraries linked > against by R packages need to be rebuilt with g++ 4.9.2 in order for > the R packages to install/load? This could well be due to incompatible thread models (win32 vs posix). See the thread "V8 crashes..." on the Rcpp-devel mailing list. We have

On Tue, Nov 24, 2015 at 12:10:12AM +0100, Jeroen Ooms wrote: > Currently it is all to easy for package authors to introduce a memory > leak or stack imbalance by calling Rf_error() or > R_CheckUserInterrupt() in a way that skips over the usual cleanup > steps. I have a more modest request: Please improve the documentation of exactly what Rf_error() does and how it should be used!

Hi, we have installed R-2.8.1 using the current pgi compiler (8.0.2) for AMD64 on a SLES9 system. When I try to install "Matrix" everything is fine until the last step. make[1]: Leaving directory `/tmp/R.INSTALL.TW3399/Matrix/src/AMD' pgCC -L/usr/lib64 -L/usr/X11R6/lib64 -pgf90libs -o Matrix.so CHMfactor.o Csparse.o TMatrix_as.o Tsparse.o init.o Mutils.o chm_common.o

I am trying to get R 1.0 running on the Mac. The main target is MacX. Anyone else working on that? For the recent Macintosh system, I am trying to compile R using MachTen. The R core compiles and runs without any changes, using the Unix make files. The libraries give some problems, presumably due to handling of shared libraries. It seems I am missing something to link. Before I spend my time

And remove the cast on the return value of R_GETCCallable. And check that your function is found before using it. #include <R.h> #include <Rinternals.h> #include <R_ext/Rdynload.h> void bdsmatrix_prod4(int nrow, int nblock, int *bsize, double *bmat, double *rmat, int nfrail, double *y) { DL_FUNC fun = NULL; if (fun==NULL)