Re: [Rd] Hidden files in source packages
On 27-08-2012, at 09:46, Prof Brian Ripley wrote: R-devel has been warning for some time about hidden files (in the Unix sense, starting with a period) in source packages. We could get R CMD build and the CRAN incoming scripts to remove these *if* we knew that they were never needed. It seems clear that .Rapp.history .Rhistory .Rbuildindex.x inst/doc/.build.timestamp are R leftovers, ._.DS_store is from an Apple filesystem and .tex .log .aux .pdf .png are junk (as file names, not extensions). However, is there ever any reason for any of .Renviron .Rprofile .Rproj.user .backups .cvsignore .cproject .directory .dropbox .exrc .gdb.history .gitattributes .gitignore .gitmodules .hgignore .hqtags Isn't that .hgtags? .htaccess .latex2html-init .project .seed .settings to be in a source package tarball? (For some of these it is not clear where they come from since there are multiple possible origins.) You can add .tm_properties to this list (settings file of TextMate 2 on Mac OS X) Berend __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package datasets not exporting anything on a recent R-2.15.1-patched
On 26.08.2012 20:01, Laurent Gautier wrote:
On 2012-08-26 19:27, Prof Brian Ripley wrote:
On 26/08/2012 18:20, Laurent Gautier wrote:
On 2012-08-26 19:03, Prof Brian Ripley wrote:
On 26/08/2012 17:25, Laurent Gautier wrote:
Hi,
I just stumbled on the following apparent oddity: the package
datasets
does not appear to export anything out of its namespace:
ns_datasets - getNamespace('datasets')
getNamespaceExports(ns_datasets)
character(0)
Not the case with other packages (example here with utils):
ns_utils - getNamespace('utils')
head(getNamespaceExports(ns_utils))
[1] ?.DollarNames adistalarm apropos
[6] aregexec
Is this a temporary glitch, or is there something new and specific to
datasets ?
Not new, been so since R 2.14.0.
The package contains no R code: the only reason it has a namespace is
that since 2.14.0 all packages must have one.
There are other data-only packages, but not in base R.
Lazy-loaded data has not been part of the namespace for a long time:
they are directly in the package's environment. The reason is the
namespace scoping rules: if the package's datasets were in its
namespace, they would be found before any other dataset of that name
by the package's R functions.
Thanks for the quick answer and explanations. The last paragraph above
is leaving me with the wish to understand more before I comment on it.
Would you have an example of finding a dataset in a package's namespace
(before a dataset with the same name in an other package further down in
the search path) being a problem ?
It does not happen now, but for example MASS contains both datasets
and analysis functions and when the datasets were in the namespace you
got them before other datasets (e.g. modified versions) of the same name.
I am seeing two ways for datasets to be used:
A- as internal data for necessary to a function in a package (e.g,
conversion tables). Not very frequent, from my limited experience.
B- as example data, used in the documentation. The most frequent usage.
For A/, the user is not expected to modify the data.
In that case, you can provide the data as an object defined within the
/R directory, for example.
For B/, the data are typically passed to functions (to use an example
from MASS, huber(chem)).
In that case, you do not want to have it in your NAMESPACE, since you
just pass those data in a function call.
Uwe Ligges
I thought a bit about it, but still do no see where exactly this would
be a problem.
An other example available in R is the vector letters (in base). It
can be thought of as a dataset, yet it is
- in a namespace
letters %in% getNamespaceExports(getNamespace(base))
[1] TRUE
- probably used in the two situations A/ and B/ above.
Best,
Laurent
__
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] include dll in R-package
Jeff, Thanks for the reply. For explicit dependency, can dll and functions be specified in namespace and imported by the package automatically? or the user has to use dyn.load and is.loaded to load the dll and functions in R? If it is the former, could you point me to an example that I could learn? Thanks! Liying - 原始邮件 - 发件人: Jeff Ryan jeff.a.r...@gmail.com 收件人: Kasper Daniel Hansen kasperdanielhan...@gmail.com 抄送: r-devel@r-project.org, Dirk Eddelbuettel e...@debian.org 发送时间: 星期五, 2012年 8 月 24日 上午 10:28:50 主题: Re: [Rd] include dll in R-package Any package can link to external DLLs. You'll need to make that an explicit dependency, have some configure script and distribute the library somewhere else, but many packages on CRAN already do this. My RBerkeley uses a user installed Oracle Berkeley DB that is linked to at configure time, of course there are many other examples as well. And distributing _off_ CRAN is of course a reasonable alternative. HTH Jeff On Fri, Aug 24, 2012 at 9:21 AM, Kasper Daniel Hansen kasperdanielhan...@gmail.com wrote: On Fri, Aug 24, 2012 at 10:16 AM, Dirk Eddelbuettel e...@debian.org wrote: On 24 August 2012 at 09:06, LIYING HUANG wrote: | We have several projects in the center done by researchers over years | in Fortran, there are copy right issues etc to prevent us from | giving away the source codes, but a lot of social scientist are | interested to use the program. We tried to use dlls to make plugins | (available in our website) in various statistics platforms | (SAS, STATA and R) to make it available to general public. | | We used to be able to build R package using dll on version R-2.7.0, | , but failed to build with newer R version with the same source. | Any help is greatly appreciated. | | When I try to build R package for newer version of R, I could build | to get lcca_1.0.0.tar.gz, but when I R CMD check lcca_1.0.0.tar.gz, | I got error message as: | | * using log directory 'D:/project/LCCA/lcca.Rcheck' | * using R version 2.15.1 (2012-06-22) | * using platform: i386-pc-mingw32 (32-bit) | * using session charset: ISO8859-1 | * checking for file 'lcca/DESCRIPTION' ... OK | * checking extension type ... Package | * this is package 'lcca' version '1.0.0' | * checking package namespace information ... OK | * checking package dependencies ... OK | * checking if this is a source package ... OK | * checking if there is a namespace ... OK | * checking for executable files ... WARNING | Found the following executable file(s): | libs/lcca.dll | Source packages should not contain undeclared executable files. | See section 'Package structure' in the 'Writing R Extensions' manual. | * checking whether package 'lcca' can be installed ... ERROR This tells you that in order to have a proper package, you need to include the very source code you want to hide. This is a CRAN Policy decision enforced by current R versions (but not the rather old version you compared against), and there is now way around it. You could try to construct defunct packages lacking the DLLs and instruct the users to get them from somewhere else, but that is at the same rather error prone (as you will lack all the built-time checks you would have with source code, as well as a better assurrance that compatible tools are used) and distasteful as CRAN is about Open Source. So your best bet may be to go back to the copyright holders Dirk's comments are extremely relevant if you were hoping to host the package on CRAN (which you basically won't be allowed to). You can still distribute it from your institutions homepage I think. Kasper [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com __ 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] Package datasets not exporting anything on a recent R-2.15.1-patched
On 2012-08-27 11:32, Uwe Ligges wrote:
On 26.08.2012 20:01, Laurent Gautier wrote:
On 2012-08-26 19:27, Prof Brian Ripley wrote:
On 26/08/2012 18:20, Laurent Gautier wrote:
On 2012-08-26 19:03, Prof Brian Ripley wrote:
On 26/08/2012 17:25, Laurent Gautier wrote:
Hi,
I just stumbled on the following apparent oddity: the package
datasets
does not appear to export anything out of its namespace:
ns_datasets - getNamespace('datasets')
getNamespaceExports(ns_datasets)
character(0)
Not the case with other packages (example here with utils):
ns_utils - getNamespace('utils')
head(getNamespaceExports(ns_utils))
[1] ?.DollarNames adistalarm apropos
[6] aregexec
Is this a temporary glitch, or is there something new and
specific to
datasets ?
Not new, been so since R 2.14.0.
The package contains no R code: the only reason it has a namespace is
that since 2.14.0 all packages must have one.
There are other data-only packages, but not in base R.
Lazy-loaded data has not been part of the namespace for a long time:
they are directly in the package's environment. The reason is the
namespace scoping rules: if the package's datasets were in its
namespace, they would be found before any other dataset of that name
by the package's R functions.
Thanks for the quick answer and explanations. The last paragraph above
is leaving me with the wish to understand more before I comment on it.
Would you have an example of finding a dataset in a package's
namespace
(before a dataset with the same name in an other package further
down in
the search path) being a problem ?
It does not happen now, but for example MASS contains both datasets
and analysis functions and when the datasets were in the namespace you
got them before other datasets (e.g. modified versions) of the same
name.
I am seeing two ways for datasets to be used:
A- as internal data for necessary to a function in a package (e.g,
conversion tables). Not very frequent, from my limited experience.
B- as example data, used in the documentation. The most frequent usage.
For A/, the user is not expected to modify the data.
In that case, you can provide the data as an object defined within the
/R directory, for example.
Exactly. This is making us agree that datasets are indeed just objects
in a package.
For B/, the data are typically passed to functions (to use an example
from MASS, huber(chem)).
In that case, you do not want to have it in your NAMESPACE, since you
just pass those data in a function call.
Yet having it in a namespace would not cause any harm, wouldn't it ?
Having it in a namespace would also have the added benefits:
- loading up a dataset will not overwrite silently any existing dataset
currently in .GlobalEnv
- should an identical name for a dataset be found in several packages,
one could refer to it with the :: operator. I am aware of the argument
package to the function data(), but regret the apparent lack of
general rule.
- should one wish to list the objects defined (and eventually exported)
by a package the use of one function would be sufficient.
May be I am missing a fundamental point, but if my memory is correct the
package datasets used to list its data objects when
getNamespaceExports() was called.
Uwe Ligges
I thought a bit about it, but still do no see where exactly this would
be a problem.
An other example available in R is the vector letters (in base). It
can be thought of as a dataset, yet it is
- in a namespace
letters %in% getNamespaceExports(getNamespace(base))
[1] TRUE
- probably used in the two situations A/ and B/ above.
Best,
Laurent
__
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
[Rd] non portable filenames
I am including an external piece of software in an R package. This
software ships with its own configure script generated by
autoconf/automake, and this script is being run as part of the package
configure script.
The package contains a file
m4/lt~obsolete.m4
which - as far as I can see - is a standard file from the
autoconf/automake/m4 suite of programs. A warning is generated with R
CMD check about this filename being non-portable. Presumably because
of the ~ in the file name. The users is referred to the 'Package
structure' part of R-exts.
Reading the manual, I do not see ~ listed in the beginning of the
paragraph where non-allowed characters are described. Quoting:
To ensure that file names are valid across file systems and supported
operating system platforms, the ASCII control characters as well as
the characters ‘’, ‘*’, ‘:’, ‘/’, ‘’, ‘’, ‘?’, ‘\’, and ‘|’ are not
allowed in file names. In addition, files with names ‘con’, ‘prn’,
‘aux’, ‘clock$’, ‘nul’, ‘com1’ to ‘com9’, and ‘lpt1’ to ‘lpt9’ after
conversion to lower case and stripping possible “extensions” (e.g.,
‘lpt5.foo.bar’), are disallowed. Also, file names in the same
directory must not differ only by case (see the previous paragraph).
In addition, the basenames of ‘.Rd’ files may be used in URLs and so
must be ASCII and not contain %.
However, ~ is also not part of the next sentence where allowed
characters are listed. Quoting
For maximal portability filenames should only contain only ASCII
characters not excluded already (that is A-Za-z0-9._!#$%+,;=@^(){}'[]
— we exclude space as many utilities do not accept spaces in file
paths): non-English alphabetic characters cannot be guaranteed to be
supported in all locales. It would be good practice to avoid the shell
metacharacters (){}'[]$.
To me it looks a bit like this paragraph is not self-consistent, since
~ is not listed as one of the characters already excluded.
Now, I don't really know if ~ is portable. But I assume that the
autoconf/automake/m4 people has thought a bit about this. And I don't
really want to rename the file in question, as it is part of a lengthy
configure script. So I guess my question is, is R CMD check correct
in flagging the file? And what is recommended? I am tempted to
ignore this warning, but I know warnings sometimes become errors.
I assume other people might be in the same situation, since the
filename originates from autoconf/automake/m4.
Kasper
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] very minor typo in doc for embedFonts
in the Details section: It this is unset… should read If this is unset version _ platform x86_64-apple-darwin9.8.0 arch x86_64 os darwin9.8.0 system x86_64, darwin9.8.0 status Patched major 2 minor 15.1 year 2012 month 08 day26 svn rev60438 language R version.string R version 2.15.1 Patched (2012-08-26 r60438) nickname Roasted Marshmallows — Simon Jackman Simon Jackman, Depts of Political Science (by courtesy) Statistics, Stanford University, Stanford, CA 94305-6044, USA. http://jackman.stanford.edu Co-Principal Investigator, American National Election Studies cell: +1 (650) 387 3019 fax: +1 (650) 724-9095 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] very minor typo in doc for embedFonts
On 27/08/2012 3:43 PM, Simon Jackman wrote: in the Details section: It this is unset… should read If this is unset Thanks, will fix. Duncan Murdoch version _ platform x86_64-apple-darwin9.8.0 arch x86_64 os darwin9.8.0 system x86_64, darwin9.8.0 status Patched major 2 minor 15.1 year 2012 month 08 day26 svn rev60438 language R version.string R version 2.15.1 Patched (2012-08-26 r60438) nickname Roasted Marshmallows — Simon Jackman Simon Jackman, Depts of Political Science (by courtesy) Statistics, Stanford University, Stanford, CA 94305-6044, USA. http://jackman.stanford.edu Co-Principal Investigator, American National Election Studies cell: +1 (650) 387 3019 fax: +1 (650) 724-9095 __ 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
