similar to: How to build R without support for translations?

On 21 February 2017 at 18:45, Henrik Bengtsson wrote: | In Section 'Localization of messages' of R Installation and | Administration (R 3.3.2), it says: | | "R can be built without support for translations, but it is enabled | by default." | | How can this be done? Is this an option to 'configure', which I then | failed to identify, or via some environment variable

ISSUE: It looks like Rgui.exe never processes ~/.Renviron - only ./.Renviron. REPRODUCIBLE EXAMPLE: On Windows, create the following ~/.Renviron and ~/.Rprofile files: C:\Users\alice> Rscript -e "cat('FOO=123\n', file='~/.Renviron')" C:\Users\alice> Rscript -e "cat('print(Sys.getenv(\'FOO\'))', file='~/.Rprofile')" and launch

On 27 January 2017 at 21:54, G?bor Cs?rdi wrote: | On Fri, Jan 27, 2017 at 9:28 PM, Da Zheng <zhengda1936 at gmail.com> wrote: | > What major R platforms does this policy refer to? | > | | Linux, macOS, Windows. | | | > Currently, my package runs in Ubuntu. If it works on both Ubuntu and | > Redhat, does it count as two platforms? | > | | I think that Linux is just one. Is

I'd second Jim's feature request - it would be useful to be able to disable this in CI and elsewhere. The concept of using an "unusual" version component such as a very large number does a nice job of indicating "unusual" and serves as a blocker for submitting work-in-progress to CRAN by mistake (hence the validation in 'R CMD check'). Another point, which I

On Wed, Mar 18, 2020 at 8:04 PM Dirk Eddelbuettel <edd at debian.org> wrote: > > > On 18 March 2020 at 19:19, Henrik Bengtsson wrote: > | AFAIU, 'R CMD check --as-cran' tries to hide any site and user package > | libraries by setting R_LIBS_SITE and R_LIBS_USER. However, contrary > > What makes you think that? AFAIK --as-cran just sets a bunch of the (nearly

AFAIU, 'R CMD check --as-cran' tries to hide any site and user package libraries by setting R_LIBS_SITE and R_LIBS_USER. However, contrary to R_LIBS_SITE, it fails for R_LIBS_USER and the user's personal library is still available for test scripts. Should I revise my assumptions, or is that intentional? The short version. Shouldn't: $ R_LIBS_USER='' Rscript --vanilla -e

One other solution that's only a little crazy: you could have a R function within your package that generates the appropriate (portable) Makevars, and within the package `configure` script call that function. For example" R --vanilla --slave -e "source('R/makevars.R'); makevars()" And that 'makevars()' function could generate portable

Hi all, A problem with tests while building R. I'm packaging R for Sisyphus repository and package build environment, by design, doesn't have /etc/localtime file present. This causes failure with Sys.timeone during test run: [builder at localhost tests]$ ../bin/R --vanilla < reg-tests-1d.R > ## PR#17186 - Sys.timezone() on some Debian-derived platforms > (S.t <-

On Tue, Dec 20, 2016 at 7:39 AM, Karl Millar <kmillar at google.com> 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 references to such objects (which would be > hard to verify), it

Dear all, I'm working on a project that links to the BH package (http://cran.r-project.org/web/packages/BH/index.html). My packages doesn't call entry points which might terminate R nor write to stdout/stderr instead of to the console. However, it seems some of the codes in the BH package might. At any rate, when I include some boost headers such as boost/math/distributions/ through BH,

I knew I could work around. But this shouldn't happen. And yes. Same problem with your example. blurfle$ R --vanilla R version 3.6.3 (2020-02-29) -- "Holding the Windsock" Copyright (C) 2020 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain

Not that it brings closure, but there's also https://stat.ethz.ch/pipermail/r-devel/2017-June/074462.html Henrik On Sat, Aug 25, 2018, 06:40 Marc Schwartz via R-devel <r-devel at r-project.org> wrote: > On Aug 25, 2018, at 9:26 AM, Hadley Wickham <h.wickham at gmail.com> wrote: > > > > Hi all, > > > > Would someone mind pointing to me to the

On 10/15/07, Henrik Bengtsson <hb at maths.lth.se> wrote: > [As agreed, CC:ing r-devel since others might be interested in this as well.] > > Hi. > > On 10/15/07, Dirk Eddelbuettel <edd at debian.org> wrote: > > > > Hi Hadley, > > > > On 15 October 2007 at 09:51, hadley wickham wrote: > > | Would you consider making digest a generic

On 20 December 2016 at 17:40, Martin Maechler wrote: | >>>>> Steve Bronder <sbronder at stevebronder.com> | >>>>> on Tue, 20 Dec 2016 01:34:31 -0500 writes: | | > Thanks Henrik this is very helpful! I will try this out on our tests and | > see if gcDLLs() has a positive effect. | | > mlr currently has tests broken down by learner type

> Your best bet really to govern your .libPaths from your Rprofile.site and Renviron.site ... To do this for any version of R, one can add: R_LIBS_USER=~/.local/share/R/%p-library/%v to ~/.Renviron or the Renviron.site file. This automatically expands to the platform and R x.y version early on when R starts up, e.g. ~/.local/share/R/x86_64-pc-linux-gnu-library/4.2. > rather than asking a

Thanks Henrik this is very helpful! I will try this out on our tests and see if gcDLLs() has a positive effect. mlr currently has tests broken down by learner type such as classification, regression, forecasting, clustering, etc.. There are 83 classifiers alone so even when loading and unloading across learner types we can still hit the MAX_NUM_DLLS error, meaning we'll have to break them

On Fri, Jul 6, 2018 at 8:18 AM G?ran Brostr?m <goran.brostrom at umu.se> wrote: > > > > Den 2018-07-06 kl. 16:28, skrev Dirk Eddelbuettel: > > > > On 6 July 2018 at 12:31, Enrico Schumann wrote: | Just as one more > > datapoint: I cannot reproduce the segfault, with | R 3.5.1 on > > (L)Ubuntu 18.04. (I use the Ubuntu package, i.e. I did not | build >

As of today's commit r72375 all packages with native-routine registration of C or Fortran routines need to be reinstalled in R-devel (and that include some of the recommended packages in R itself which will not be reinstalled via make dependencies, so we advise a clean rebuild of R). We try to avoid such things, but now is a least bad time (before binary packages for pre-3.4.0 are built

On 6 July 2018 at 12:31, Enrico Schumann wrote: | Just as one more datapoint: I cannot reproduce the segfault, with | R 3.5.1 on (L)Ubuntu 18.04. (I use the Ubuntu package, i.e. I did not | build from source.) I have been a little too busy and have not yet upgraded to 18.04 so I can't attempt to replicate -- but it _looks_ just like a garden variety binary mismatch. We _know_ R 3.5.*

Corrected packages are now on the RRutter PPA ( https://launchpad.net/~marutter/+archive/ubuntu/rrutter) and soon on CRAN mirrors. If you have any issues or questions, please let me know. Michael On Fri, Sep 29, 2017 at 8:50 AM, Dirk Eddelbuettel <edd at debian.org> wrote: > > So I now have this on my laptop > > edd at brad:~$ apt-cache policy r-base-core >