similar to: Test suite failures in R-devel_2017-02-25_r72256

On 27/02/2017 09:30, Peter Simons wrote: > Hi, > > I tried compiling the latest pre-release for R 3.3.3 for the NixOS Linux > distribution [1], but the build fails during the "make check" phase > because of the following 2 issues: Hmm, R-devel (your subject line) is not a pre-release of R 3.3.3: it is 'R Under development' for what is planned as R 3.4.0.

>>>>> Peter Simons <simons at nospf.cryp.to> >>>>> on Mon, 27 Feb 2017 10:30:39 +0100 writes: > Hi, I tried compiling the latest pre-release for R 3.3.3 > for the NixOS Linux distribution [1], but the build fails > during the "make check" phase because of the following 2 > issues: > 1) The "tools" test

>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Mon, 26 Jan 2015 05:12:55 -0800 writes: > A isNamespaceLoaded() function would be a useful thing to > have in general if we are interested in readable code. An > efficient implementation would be just a bonus. Good point (readability), and thank you for the support! Note

We ran into a bug in our package that seems to boil down to isNamespaceLoaded() returning TRUE for namespaces that R is currently loading. We had something like this in an .onLoad function: if (isNamespaceLoaded("upstream")) { upstream::upstream_function() } Which seems OK, unless upstream (recursively) imports the package having this code. Should that happen, the loading of

isLoadedNamespace() sounds fine to me.. Thanks for addressing this, Michael On Mon, Jan 26, 2015 at 5:51 AM, Martin Maechler < maechler at lynne.stat.math.ethz.ch> wrote: > >>>>> Michael Lawrence <lawrence.michael at gene.com> > >>>>> on Mon, 26 Jan 2015 05:12:55 -0800 writes: > > > A isNamespaceLoaded() function would be a useful

>>>>> Winston Chang <winstonchang1 at gmail.com> >>>>> on Fri, 23 Jan 2015 10:15:53 -0600 writes: > I think you can simplify a little by replacing this: > pkg %in% loadedNamespaces() > with this: > .getNamespace(pkg) almost: It would be !is.null(.getNamespace(pkg)) > Whereas getNamespace(pkg) will load the

Dear all, I am using the CRAN_package_db function to determine whether the head versions of certain packages match those I need. The parallel package though, is missing from the database: > pdb <- tools:::CRAN_package_db() > pdb[pdb$Package=="parallel",]["Package"] [1] Package <0 rows> (or 0-length row.names) Is this a bug that needs to be reported (where?) ?

require() and library() both emit this message immediately before running library(): "Loading required package: %s" https://github.com/r-devel/r-svn/blob/4198a2941b702d965bb2374c2b908f48c369f40a/src/library/base/R/library.R#L967-L968 https://github.com/r-devel/r-svn/blob/4198a2941b702d965bb2374c2b908f48c369f40a/src/library/base/R/library.R#L684-L685 Shouldn't "Loading"

> I would appreciate any insights over compiling R 3.4 with Intel MKL -- I have been successful until R 3.3.3 but now it stops complaining about pcre though it worked without Intel MKL as follows, I successfully built R-rc_2017-04-19_r72555.tar.gz with icc & MKL on centos 7 with this: # https://software.intel.com/en-us/articles/build-r-301-with-intel-c-compiler-and-intel-mkl-on-linux#

Hi, I maintain the R packages in the NixOS Linux distribution [1]. A while ago, I attempted to update to version 3.1.1, but I ran into the following test suite failure: | Testing examples for package 'tools' | comparing 'tools-Ex.Rout' to 'tools-Ex.Rout.save' ... | 452c452 | < character(0) | --- | > [1] "Matrix" "nlme" "mgcv"

>>>>> Michael Chirico via R-devel >>>>> on Mon, 9 Jan 2023 12:25:46 -0800 writes: > require() and library() both emit this message immediately before > running library(): > "Loading required package: %s" > https://github.com/r-devel/r-svn/blob/4198a2941b702d965bb2374c2b908f48c369f40a/src/library/base/R/library.R#L967-L968

Hi Lu?s, The parallel package is built-in, and so is not distributed via cran. You'll see the same thing for all the built in packages, e.g., > pdb[pdb$Package=="stats",]["Package"] [1] Package <0 rows> (or 0-length row.names) > pdb[pdb$Package=="splines",]["Package"] [1] Package <0 rows> (or 0-length row.names) >

Hi, In the DESCRIPTION file the ByteCompile and LazyLoading arguments appear to accept any value. >From the manual the field should be a "logical field". However, authors interpret this in a variety of ways: unique(tools::CRAN_package_db()$ByteCompile) # [1] NA "TRUE" "yes" "true" "Yes" "no" #

Hi Dirk, > I have been doing for R for about 20 years (if you count the time I > assisted Doug Bates when he was still the maintainer) (and longer for > Debian), and you seem to follow the same model we set up years ago of > splitting the content of r-recommended (itself a virtual package) off > r-base-core. > > You simply need to do this in stages. I have packaged

I applied the patch Gene wrote here: https://github.com/triton/nixpkgs/commit/06e146b2ce5eaaa54ebea061dd5797f89ae2c37c The tree after that commit is entirely based on gcc5. In order to do a test with gcc4.9, I reverted: https://github.com/triton/nixpkgs/commit/8ccc1f121f379f4d66ce0a66f581c49d25fb4e15#diff-d7222640d82ff920625e9311d05a0137 and then built two images, one entirely based on gcc4.9

Duncan Murdoch writes: >> ./configure --without-recommended-packages && make && make check > > So you're getting paid to do what you do, but you want the volunteers > in R Core to do some work for you for free. You are jumping to conclusions. Nobody pays me a single cent to package R for Nix; I do that purely as a hobby. >> If no-one wants to make

Hi, Does anyone here have experience running Tinc on NixOS? I'm trying to run Tinc on a NixOS machine, using the similar configuration i had for Ubuntu. My home subnet is 192.168.1.0/24 and my work is 10.16.0.0/24. However, unlike ubuntu, when I start tincd on nixos, and try to 'ifconfig $INTERFACE 192.168.1.10 netmask 255.255.255.0' in my tinc-up, I loose network access on the box

I'm not trying to create a mirror of the CRAN. I also do not want to create a "subset" of CRAN packages. Sorry if my explanation was confusing. There are internal proprietary R packages that I would like to host on a private repo. I like the CRAN web pages that allow a user to browse the various packages from a browser without having to first install them. I want to duplicate the

Hi! I am running dovecot 2.1.16 on NixOS (http://nixos.org), and I have been fighting the dynamically loaded dovecot modules/plugins a bit. The problem is that in Nix/NixOS all packages are completely isolated from each other (each package has a separate /lib, /libexec, /bin etc, with only its own files in it). So dovecot has all its modules under

Hi, The recommended package matrix contains an empty file src/dummy.cpp which results in using g++ instead of gcc to link Matrix.so. What is the reason for that? Is there any difference between using g++ or gcc? (There are no other cpp files in the source) I asked the maintainers of the package (matrix-authors at r-project.org) 3 weeks ago but haven't received any answer. On my system (NixOS