[Rd] source definition for R_NilValue/return from TYPEOF(R_NilValue)
Hello, for reasons I want to know the return value of TYPEOF(R_NilValue), I expect it to be NILSXP, but I can't find this documented anywhere. Ideally, I'd like to see the source definition of R_NilValue, but after fair bit of searching I cannot find an obviously location for this. Would someone please point me in the right direction? thanks -- CRICOS provider code 00123M __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] source definition for R_NilValue/return from TYPEOF(R_NilValue)
It is in the source: https://github.com/wch/r-source/blob/ea8c13aef93058c71d647619583b561567856584/src/include/Rinternals.h#L110 https://github.com/wch/r-source/blob/ea8c13aef93058c71d647619583b561567856584/src/include/Rinternals.h#L1798 It could probably be in https://cran.r-project.org/doc/manuals/r-devel/R-lang.html#NULL-object Gabor On Mon, Dec 16, 2019 at 9:59 AM Dan Kortschak wrote: > > Hello, > > for reasons I want to know the return value of TYPEOF(R_NilValue), I > expect it to be NILSXP, but I can't find this documented anywhere. > Ideally, I'd like to see the source definition of R_NilValue, but after > fair bit of searching I cannot find an obviously location for this. > > Would someone please point me in the right direction? > > thanks > -- > CRICOS provider code 00123M > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] source definition for R_NilValue/return from TYPEOF(R_NilValue)
On Sun, 15 Dec 2019 10:47:11 + Dan Kortschak wrote: > I'd like to see the source definition of R_NilValue, but after > fair bit of searching I cannot find an obviously location for this. > > Would someone please point me in the right direction? As far as I understand, the assignment to R_NilValue happens in src/main/memory.c: https://github.com/wch/r-source/blob/776929704cb4f9398f52805f48f2c93582ec3d38/src/main/memory.c#L2186 (see the definition of GET_FREE_NODE(s) in the same file) Besides declaring R_NulValue as "extern" and assignments in void InitMemory(), there doesn't seem to be anything else. -- Best regards, Ivan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Windows check problems.
For reference, this has been addressed in R-devel, R now falls back to copy when symlinking of the package directory silently fails. Thanks to Duncan for his analysis and a patch that fixed this. Tomas On 12/11/19 5:22 PM, Duncan Murdoch wrote: The thread starting with this message: https://stat.ethz.ch/pipermail/r-package-devel/2019q4/004745.html described problems Rich Heiberger was having with package checking on Windows. It appeared that during the tests of examples, an old version of the package was loaded but the new tests were being run, causing lots of confusion and trouble. I reproduced the error, and I think I've found the cause. I had his package tarball on a network drive, with a local drive being used for the session temporary directory. The check code needs a copy of the package installed in the temporary directory, and already has one in the pkg.Rcheck directory where the check is taking place, so it tries to create a junction linking them. (On non-Windows systems it uses a symlink.) Apparently the junction creation silently fails: an empty directory appears on the temp dir. When R loads the package code, it doesn't find it in the temp dir, and goes looking in other libraries, where it found an older versions of the package. A workaround for this issue is to set the environment variable R_WIN_NO_JUNCTIONS=yes before doing the check. This causes the check code to copy all the files into the temp dir and things are fine. I don't know whether the junction creation should have succeeded, or whether it should have signalled an error when it didn't, but it might make sense for R to do a simple sanity check after trying to create the junction (e.g. test for the presence of DESCRIPTION in the newly created location), falling back to a copy if things didn't succeed. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
