Re: [R-pkg-devel] duplicate function during build

On Sat, 23 Jul 2016, ProfJCNash writes: > Thanks Sven. That indeed works. And if anyone has ideas how it could be > put into R so Windows users could benefit, I'm sure it would be useful > in checks of packages. You could use R functionality to rewrite the shell commands.

Re: [Rd] Model object, when generated in a function, saves entire environment when saved

Thanks so much for all this. The first solution is what I'm going with as I want the terms object to come along so that predict still works. On Wed, Jul 27, 2016 at 12:28 PM, William Dunlap via R-devel < r-devel@r-project.org> wrote: > Another solution is to only save the parts of the model

Re: [Rd] Model object, when generated in a function, saves entire environment when saved

Another solution is to only save the parts of the model object that interest you. As long as they don't include the formula (which is what drags along the environment it was created in), you will save space. E.g., tfun2 <- function(subset) { junk <- 1:1e6 list(subset=subset,

Re: [Bioc-devel] BiomartGeneRegionTrack question

A date would be helpful to figure out the latest version. Of course there could also just be the silent contract that the return vector is ordered from oldest to latest. Your Armadillo example below would only return Dasnov3.0, though. UCSC does not appear to include any of the older two

Re: [Rd] Model object, when generated in a function, saves entire environment when saved

One way around this problem is to make a new environment whose parent environment is .GlobalEnv and which contains only what the the call to lm() requires and to compute lm() in that environment. E.g., tfun1 <- function (subset) { junk <- 1:1e+06 env <- new.env(parent = globalenv())

[Rd] Model object, when generated in a function, saves entire environment when saved

In the below, I generate a model from an environment that isn't .GlobalEnv with a large object that is unrelated to the model generation. It seems to save the irrelevant object unnecessarily. In my actual use case, I am running and saving many models in a loop that each use a single large

Re: [Bioc-devel] bioconductor/metabolomics Docker image available

- Original Message - > From: "Steffen Neumann" > To: "Dan Tenenbaum" > Cc: "bioc-devel" > Sent: Wednesday, July 27, 2016 5:02:22 AM > Subject: bioconductor/metabolomics Docker image available > Hi Dan and BioC

Re: [Bioc-devel] [devteam-bioc] Segfault in Rsamtools when R built with static libz

Martin and Michael, It looks like I have been conflating two issues when trying to deal with these things. The problem of grabbing the system libz seems to have gone away in the Rsamtools case earlier than in the libR.so case during my process. wwI will check back in if something raises it's head

Re: [Bioc-devel] [devteam-bioc] Segfault in Rsamtools when R built with static libz

Maybe Gabe could share the linker line. I think (from the man page) as long as the directory with the static lib comes first with -L, it should find the static lib, not the shared object. On Wed, Jul 27, 2016 at 6:48 AM, Martin Morgan wrote: > Hi Gabe -- > > On

Re: [Bioc-devel] [devteam-bioc] Segfault in Rsamtools when R built with static libz

Hi Gabe -- On 07/21/2016 12:08 PM, Maintainer wrote: Hi all, I build the R installations on our research cluster. Unfortunately we are running an older OS so the system versions of various libraries (libz, bz2, pcre and libcurl, specifically) are not modern enough to build R with. For

Re: [Bioc-devel] "platforms" information not updated

Hi Dan, Thanks for fixing it. R. On Tue, 26-07-2016, at 21:27, Dan Tenenbaum wrote: > Hi Ramon, > > Thanks for letting us know about this. We've identified and fixed the problem. > > Dan > > > - Original Message - >> From: "Ramon Diaz-Uriarte"

Re: [Bioc-devel] BiomartGeneRegionTrack question

Hi Valerie, That sounds great! I guess that I would try to keep all the mappings in a single file the next time. The current code grew organically over time, and is not the nicest piece of software I have ever written ☺ Let me take a closer look at this again over the next couple of days, and I