Re: [Rd] Fwd: Re: RSiteSearch, sos, rdocumentation.org, ...?

Unfortunately, I am unable to get this search site working again. (The message below explains why I had to rebuild it.) The computer worked for the better part of a day downloading and installing all the help files from all CRAN packages. Somehow it failed to get the vignettes this time. But I

Re: [Rd] different compilers and mzR build fails

On 12/21/2016 01:56 PM, lejeczek wrote: I do this on a vanilla-clean R installation, simply: biocLite("mzR") it pulls some deps in which compile fine, only mzR fails. ... meanwhile... I grabbed devtools and comiled github master - still fails. Should I attach build log? One should not send

Re: [Rd] different compilers and mzR build fails

I do this on a vanilla-clean R installation, simply: > biocLite("mzR") it pulls some deps in which compile fine, only mzR fails. ... meanwhile... I grabbed devtools and comiled github master - still fails. Should I attach build log? One should not send attachments to the list.. I don't suppose?

Re: [Rd] Request: Increasing MAX_NUM_DLLS in Rdynload.c

On 21 December 2016 at 09:42, Karl Millar via R-devel wrote: | Currently what I do is to never unload DLLs. If I need to replace | one, then I just restart R. It's less convenient, but it's always | correct. Same here. Ever since we built littler in 2006 (!!) I have been doing tests at the

Re: [Rd] Request: Increasing MAX_NUM_DLLS in Rdynload.c

It does, but you'd still be relying on the R code ensuring that all of these objects are dead prior to unloading the DLL, otherwise they'll survive the GC. Maybe if the package counted how many such objects exist, it could work out when it's safe to remove the DLL. I'm not sure that it can be

Re: [Rd] Request: Increasing MAX_NUM_DLLS in Rdynload.c

On Tue, Dec 20, 2016 at 7:39 AM, Karl Millar wrote: > It's not always clear when it's safe to remove the DLL. > > The main problem that I'm aware of is that native objects with > finalizers might still exist (created by R_RegisterCFinalizer etc). > Even if there are no live

Re: [Rd] different compilers and mzR build fails

mzR is a Bioconductor package, so better to ask on the Bioconductor support forum https://support.bioconductor.org Oh, I see you did, and then the advice is to avoid cross-posting! The missing .o files would have been produced in an earlier compilation step; they likely failed in some way,

[Rd] different compilers and mzR build fails

I'm not sure if I should bother you team with this, apologies in case it's a bother. I'm trying gcc 6.2.1 (from devtoolset-6) with R, everything seems to work just fine, except for mzR. Here is failed build: g++ -m64 -shared -L/usr/lib64/R/lib -Wl,-z,relro -o mzR.so cramp.o ramp_base64.o

Re: [Rd] Very small numbers in hexadecimal notation parsed as zero

> Florent Angly > on Tue, 20 Dec 2016 13:26:36 +0100 writes: > Hi all, > I have noticed incorrect parsing of very small hexadecimal numbers > like "0x1.dp-987". Such a hexadecimal representation can > can be produced by sprintf()