Re: [Rd] binary R packages for GNU/Linux

kages on any git-based version control platform (e.g. GitHub). R Universe is open source and a top-level project of the R Consortium. Cheers, Carl --- Carl Boettiger http://carlboettiger.info/ On Mon, Feb 10, 2025 at 5:30 AM Iñaki Ucar wrote: > On Mon, 10 Feb 2025 at 14:09, Dirk Edde

Re: [Rd] Correct use of tools::R_user_dir() in packages?

not required by policy, though maybe this is mostly my own confusion. The examples in this thread have definitely been helpful to me in understanding how others handle persistent data/config/cache mechanisms. Regards, Carl --- Carl Boettiger http://carlboettiger.info/ On Thu, Jun 29, 202

Re: [Rd] Correct use of tools::R_user_dir() in packages?

ns of `tools`.) Cheers, Carl --- Carl Boettiger http://carlboettiger.info/ On Wed, Jun 28, 2023 at 12:59 PM Simon Urbanek wrote: > > Carl, > > I think your statement is false, the whole point of R_user_dir() is for > packages to have a well-defined location that is allowed - from CRA

[Rd] Correct use of tools::R_user_dir() in packages?

n the call for every example, every unit test, and every vignette. Is this the recommended approach or is there a better technique? Thanks for any clarification! Regards, Carl --- Carl Boettiger http://carlboettiger.info/ __ R-devel@r-project.org mailing

Re: [Rd] Bias in R's random integers?

ark wrote: > >> > > The 53 bits only encode at most 2^{32} possible values, > >> because the > >> > > source of the float is the output of a 32-bit PRNG (the > >> obsolete > >> > version > >>

[Rd] Bias in R's random integers?

Dear list, It looks to me that R samples random integers using an intuitive but biased algorithm by going from a random number on [0,1) from the PRNG to a random integer, e.g. https://github.com/wch/r-source/blob/tags/R-3-5-1/src/main/RNG.c#L808 Many other languages use various rejection sampling

Re: [Rd] Where does L come from?

I always thought it meant "Long" (I'm assuming R's integers are long integers in C sense (iirrc one can declare 'long x', and it being common to refer to integers as "longs" in the same way we use "doubles" to mean double precision floating point). But pure speculation on my part, so I'm curious!

Re: [Rd] ggplot2/plyr interaction with latest R-devel?

n recent commits rings a bell. > > Works fine on R version 3.1.1 (except for a "ggplot2 built under > 3.2.0 warning"). > > Does anyone else see this or is it just something weird about my setup? > > Ben Bolker > >

Re: [Rd] Is using devtools::release no longer allowed?

______ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Carl Boettiger UC Santa Cruz http://carlboettiger.info/ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Preferred way to include internal data in package?

em in data/, then R CMD check >>>> asks me to document them but I’d prefer it if they floated beneath the >>>> surface, without the users awareness. >>> >>> Perhaps in sysdata.rda. See "Writing R Extensions". >> >> __

Re: [Rd] R CMD check for the R code from vignettes

at > whatever check does should be mandatory. > > That having been said, I think it can be argued that the fact that check > does this means that it IS in the R package vignette specification that all > vignettes must be such that their tangled code will run without errors. > &g

Re: [Rd] R CMD check for the R code from vignettes

t;> > >> So what do we really lose if we turn off tangle? We lose an R script > >> as a derivative from the source document, but we do not lose the code > >> evaluation. > > > > > > We lose *isolated* code e

Re: [Rd] R CMD check for the R code from vignettes

gle, considering >> Sweave() (or knitr::knit()) as the new "source()". Therefore >> eventually I tend to just drop tangle, but perhaps I missed something >> here, and I'd like to hear what other people think about it. >> >> Regards, >> Yihui >> -- >> Yihui Xie >> Web:

Re: [Rd] The case for freezing CRAN

___ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Gregory (Greg) L. Snow Ph.D. > 538...@gmail.com > > __ > R-devel@r-project.org mailing list > https://stat.eth

Re: [Rd] [RFC] A case for freezing CRAN

; >> The only objection I can see to this is that it requires extra work by >>> the >>> third party, rather than extra work by the CRAN team. I don't think the >>> total amount of work required is much different. I'm very unsympathetic >>> to >>> proposals to dump work on others. &