On 07/18/2016 03:45 PM, Andrew Piskorski wrote:
I saw a warning from R that I don't fully understand. Here's one way
to reproduce it:
$ /usr/local/pkg/R-3.2-branch-20160718/bin/R --version | head -n 3
R version 3.2.5 Patched (2016-05-05 r70929) -- "Very, Very Secure Dishes"
Copyright (C) 2016 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu/x86_64 (64-bit)
$ /usr/local/pkg/R-3.2-branch-20160718/bin/R --vanilla --no-restore
--no-save --silent
> splitString <- function(...) { print("Test, do nothing") }
> invisible(tools::toTitleCase)
Warning message:
failed to assign RegisteredNativeSymbol for splitString to splitString since
splitString is already defined in the 'tools' namespace
Another way to trigger that warning is by loading the knitr package, e.g.:
or
splitString = NULL; loadNamespace("tools")
Thanks, it's a bug fixed with
------------------------------------------------------------------------
r70933 | morgan | 2016-07-18 16:35:39 -0400 (Mon, 18 Jul 2016) | 5 lines
assignNativeRoutines looks only in package namespace
- previously looked for symbols in inherited environments
- https://stat.ethz.ch/pipermail/r-devel/2016-July/072909.html
------------------------------------------------------------------------
> require("knitr")
Loading required package: knitr
Warning: failed to assign RegisteredNativeSymbol for splitString to
splitString since splitString is already defined in the 'tools' namespace
The warning only happens the FIRST time I run any code that triggers it.
To get it to happen again, I need to restart R.
R 3.1.0 and all earlier versions do not throw that warning, because
they do not have any splitString C function (see below) at all. R
3.2.5 does throw the warning, and I believe 3.3 and all later versions
of R do also (but I cannot currently test that on this machine).
In my case, normally I start R without "--vanilla", and load various
custom libraries of my own, one of which contained an R function
"splitString". That gave the exact same symptoms as the simpler way
of reproducing the warning above. In practice, I solved the problem
by renaming my "splitString" function to something else. But I still
wonder what exactly was going on with that warning.
I noticed that the toTitleCase() R code calls .Call() with a bare
splitString identifier, no quotes around it:
$ grep -n splitString R-3-[234]*/src/library/tools/R/utils.R
R-3-2-branch/src/library/tools/R/utils.R:1988: xx <- .Call(splitString, x,
' -/"()')
R-3-3-branch/src/library/tools/R/utils.R:2074: xx <- .Call(splitString, x,
' -/"()\n')
R-3-4-trunk/src/library/tools/R/utils.R:2074: xx <- .Call(splitString, x,
' -/"()\n')
$ find R-3-4-trunk -name .svn -prune -o -type f -print0 | xargs -0 grep -n
splitString
R-3-4-trunk/src/library/tools/R/utils.R:2074: xx <- .Call(splitString, x,
' -/"()\n')
R-3-4-trunk/src/library/tools/src/text.c:264:SEXP splitString(SEXP string,
SEXP delims)
R-3-4-trunk/src/library/tools/src/tools.h:45:SEXP splitString(SEXP string,
SEXP delims);
R-3-4-trunk/src/library/tools/src/init.c:53: CALLDEF(splitString, 2),
Doing that is perfectly legal according to help(".Call"), and
interestingly, it apparently does NOT matter whether that code puts
quotes around the splitString or not - I tried it, and it made no
difference.
Is it generally the case the users MUST NOT define R functions with
the same names as "registered" C functions? Will something break if
we do?
This email message may contain legally privileged and/or...{{dropped:2}}
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
