Re: [R-pkg-devel] How to reduce examples in a package that takes more than 5 seconds to run?
On 12/15/22 08:34, Ismail Otoakhia wrote: The R package 'ardl.nardl' has some examples that take more than 5 seconds to run. I was advised by the CRAN team to reduce the run time to less than 5 seconds. How can this be achieved? - you can lower the amount of data in the example - you can use a faster method than your default method - you can wrap the example in a dontrun tag so it will not run during checking __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] NOTE in r-devel-linux-x86_64-fedora-clang
On Fri, 2020-08-07 at 15:46 +0100, Gábor Csárdi wrote: > If you want to link to a package in the documentation, you'll have to > add it to Suggests. This doesn't make any sense. If you don't use the code from that package anywhere, then a cross-reference to that package should not require the extra dependency in Suggests. Cross references should be able to point to other functionality that might be useful to the user, or might add extra depth of understanding to a concept. If the user doesn't have the package installed, no worries, it is just a cross reference. The requirement you are suggesting is also not discussed in Writing R Extensions: https://cran.r-project.org/doc/manuals/r-patched/R-exts.html#Cross_002dreferences In fact, it explicitly allows links to potentially uninstalled packages. Regards, Brian __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Help with Error Messages
On Mon, 2020-03-30 at 10:18 -0400, Kelsey Chetnik wrote: > Hi, > > I am submitting a package to CRAN for the first time and I am not > sure what > the following error means and how to solve it: > https://win-builder.r-project.org/incoming_pretest/MetaClean_0.1.0_20200330_150936/Windows/00install.out > > Could someone please help me with this? > The link will go away, so here is the error: ** byte-compile and prepare package for lazy loading Error: .onLoad failed in loadNamespace() for 'S4Vectors', details: call: validObject(.Object) error: invalid class "LLint" object: superclass "integer_OR_LLint" not defined in the environment of the object's class Execution halted ERROR: lazy loading failed for package 'MetaClean' Does your package compile and run locally? Is the 'S4Vectors' package properly listed in 'Imports' ? This error might be related to S4Vectors, and unrelated to you directly. Check on other Winbuilder architectures, R-Hub, etc, and see if the error is replicated there. Regards, Brian __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Winbuilder 'experimental' toolchain 4-5x slower than all other architectures
For every other architecture, Travis-CI and R-Hub take approximately 10-12 minutes to build and check PerformanceAnalytics. On the Windows Rtools4 experimental toolchain, the build/check on Winbuilder and R-Hub take over an hour, sometimes as much as an hour and a half. Non-trivial example timings are similarly 4-5x slower on the Windows experimental toolchain. Brian On Wed, 2020-02-05 at 14:59 +, Gábor Csárdi wrote: > Can you please show some numbers? > > Thanks, > Gabor > > On Wed, Feb 5, 2020 at 2:40 PM Brian G. Peterson > wrote: > > We've noticed over the past week that Winbuilder/R-Hub's > > 'experimental' > > Rtools4 toolchain images for Windows are approximately 4-5x slower > > than > > all other containers to build and check several packages we > > maintain. > > > > This affects everything, including example timings, where this > > architecture is the only architecture that shows any example run- > > times > > over 5 seconds. (including Windows under the older toolchain). > > > > Does CRAN expect us to optimize our code for the clearly non- > > performant > > 'experimental' Windows toolchain? > > > > I'd like to send a new version of our package PerformanceAnalytics > > to > > CRAN, but the Windows experimental toolchain is preventing a 100% > > clean > > set of checks. > > > > > > Regards, > > > > Brian > > > > -- > > Brian G. Peterson > > ph: +1.773.459.4973 > > im: bgpbraverock > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Brian G. Peterson ph: +1.773.459.4973 im: bgpbraverock __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Winbuilder 'experimental' toolchain 4-5x slower than all other architectures
We've noticed over the past week that Winbuilder/R-Hub's 'experimental' Rtools4 toolchain images for Windows are approximately 4-5x slower than all other containers to build and check several packages we maintain. This affects everything, including example timings, where this architecture is the only architecture that shows any example run-times over 5 seconds. (including Windows under the older toolchain). Does CRAN expect us to optimize our code for the clearly non-performant 'experimental' Windows toolchain? I'd like to send a new version of our package PerformanceAnalytics to CRAN, but the Windows experimental toolchain is preventing a 100% clean set of checks. Regards, Brian -- Brian G. Peterson ph: +1.773.459.4973 im: bgpbraverock __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R package which creates a directory in the user home dir
On Thu, 2019-10-17 at 14:29 +0200, Sigbert Klinke wrote: > Hi, > > I'am developing a package that circumvents the R package size > limitation > for data sets. For this I store the data set in the internet > (currently > GitHub) and download if it is requested. > > To avoid unnecessary downloads and internet connections I create a > directory in the users home directory to store the data there. > However, > this violates the "CRAN Repository Policy" which says > > - Packages should not write in the user’s home filespace (including > clipboards), nor anywhere else on the file system apart from the R > session’s temporary directory (or during installation in the > location > pointed to by TMPDIR: and such usage should be cleaned up). > > Do I have any chance to get the package to CRAN, if I submit it? To be sure, you'd need to ask the CRAN staff, but probably not. You could probably add an option that defaults to FALSE to persist the data. Then wrap that in a check. if persist=TRUE, check to see if the file exists. if it exists in the subdirectory of the working directory, then load it. otherwise create the subdirectory of the current working directory, load from the internet, and save the data locally. In this way you've had the user explicitly direct the function to save data to disk, which is (usually) OK. Regards, Brian -- Brian G. Peterson ph: +1.773.459.4973 im: bgpbraverock __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Linking with OpenBLAS complains lapacke not found
On Sun, 2019-09-08 at 10:04 +, Sameh M. Abdulah wrote: > I am linking my package against openblas but it complains that > lapacke is not found which I need for the installation. > > I have another alternative to linking against MKL but I cannot find > it using MKLROOT variable on CRAN servers. It isn't entirely clear what your question is, but shouldn't you just be linking to the BLAS and leave the choice of BLAS to the individual installation? In most cases you should probably not be statically linking to the BLAS. Here is an old paper by Dirk with more information that might help you sort it out. https://cran.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf Regards, Brian -- Brian G. Peterson ph: +1.773.459.4973 im: bgpbraverock __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] why can't we importFrom 'methods' ?
newer versions of R require importFrom for functions from 'stats', 'graphics' and many other packages that used to be assumed to be on the search path and thus available. 'methods' continues to have seemingly different treatment. If you try to use importFrom to import a single function (in this case 'hasArg') from methods, you receive an ERROR from R CMD check Namespace dependency not required : 'methods' but without the importFrom, you see a number of NOTE's no visible global function definition for 'hasArg' I don't want to import all of 'methods', as I only need one function. What am I doing wrong? Regards, Brian -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] GPL + other licence
I'm not a lawyer, but I don't see why the entire package can't be released under GPL, while also respecting the QHull license for the QHull code and the derived QHull portions. Many existing R packages released under GPL, and R itself, include BSD and MIT licensed code. The QHull license is a very permissive license, basically BSD or MIT- like in its permissions. BSD and MIT code may be included in GPL'd code, as long as its license (inclusion of the copyright notice, etc.) is also included where required. GPL applies to the entire work, in this case the R package. I think you should discuss this with the CRAN maintainers and release the package under GPL. Regards, Brian -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock On Tue, 2018-04-10 at 11:45 +0200, Kasper Daniel Hansen wrote: > There are 3 solutions. (1) You (get permission) to change the > library to > GPL. (2) You get permission to change the license of the R code to > whatever license the library is released under. (3) you split the > package. > > You have investigated (1) and it does not work. I would suggest > thinking > about (2) provided the license of the library is decent. This is > what we > did with Rgraphviz some years ago; Graphviz itself is licensed under > the > Eclipse public license and there was no way I could get a company to > change > the license of that code. > > I would do whatever I can to avoid splitting the package. > > Best, > Kasper > > On Fri, Apr 6, 2018 at 8:44 PM, David C Sterratt <david.c.sterratt@ed > .ac.uk> > wrote: > > > Dear all, > > > > I'd appreciate help with a licence conundrum I have with the > > geometry > > package (https://davidcsterratt.github.io/geometry/) that I > > maintain. > > > > The geometry package contains some functions (e.g. convhulln(), > > delaunayn()) that wrap the Qhull library (http://www.qhull.org), > > which > > has its own, non-GPL, licence. The geometry package includes this > > source > > code, and wraps it in C files that have GPL licence headers. > > > > The geometry package also has functions that are not derived from > > Qhull > > code and which are licensed under GPL, including a number of > > functions > > that are ports of the Matlab distmesh package, and some other > > useful > > functions to do with triangulation and coordinate systems (e.g. > > tsearch() and cart2bary()). > > > > I inherited this situation when I took over maintaining the package > > 8 > > years ago, though I have added functions to both Qhull-derived and > > GPL > > categories. > > > > In October last year I submitted the latest version of the geometry > > package, which adds quite a bit of useful functionality: > > https://github.com/davidcsterratt/geometry/blob/master/pkg/NEWS > > > > I received the following response from the CRAN maintainers: > > > > For the license. It is CRAN policy that a package has to have a > > single > > license. Can you manage to convince all copyright hoders (e.g. of > > Qhull) to relicense under GPL? > > > > I tried persuading the author of Qhull. He replied: > > > > There's only one license and that's the one included with the > > code > > (COPYING.txt). Several years ago, I tried to clarify the license > > with > > the Univ. of Minn. but had no success. So I think the best > > approach is > > to keep the original license as is. It has not been an issue so > > far. > > > > At the same time as I wrote to the Qhull maintainer, I wrote to the > > CRAN > > maintainers: > > > > I have written to the Qhull maintainer, but I doubt he will want > > to > > change the license, since Qhull is used in proprietary software > > such > > as MATLAB. Assuming this is the case, we'll have to create a new > > package - I would need help with managing the change for > > dependent > > packages. > > > > The CRAN maintainers replied: > > > > Please try to find out how this can work. > > > > In principle I could create a package containing only the functions > > derived from Qhull (but still with GPL headers in the wrapper C > > files, > > see e.g., > > https://github.com/davidcsterratt/geometry/blob/ > > master/pkg/src/Rconvhulln.c > > But wouldn't this package still have to have two licenses, due to > > the > > GPL headers? > > > > I don't want to start on any package splitting without having a > > plan > > agreed that I know will be OK for CR
Re: [R-pkg-devel] Very large packages in Additional_repositories
Why not add an install function to foyer that would get the large data package? Have examples and vignette use a small test data set, so only end users would actually install the large data set. Regards, Brian --Brian G. Peterson ph: 773-459-4973im: bgpbraverockSent from my mobile, please excuse my brevity. Original message From: Hugh Parsonage <hugh.parson...@gmail.com> Date: 3/19/18 07:11 (GMT-06:00) To: R-package-devel <r-package-devel@r-project.org> Subject: [R-pkg-devel] Very large packages in Additional_repositories Dear list, I'm considering submitting a package to CRAN. The package would be a 'foyer' or API to a much larger package (>1GB tarball) containing geographical data that the 'foyer' package would use to perform tasks like geocoding. The foyer package would be usable, though quite limited, as a standalone package, and I can technically pass an R CMD check by placing the 1 GB package in Suggests and using an Additional_repository, but it takes a long time to retrieve and install from the Additional_repository. While I believe the downside of long install times would be acceptable for end-users (who would only need to install the package once a year), for CRAN it could occupy a large part of the check farm and have to occur much more frequently. The package once installed makes good use of lazy loading; in particular, it would be basically unusable if the CRAN package had to connect and download the necessary pieces from the large package each time it was required. I thought about breaking up the package into lots of little packages; however, even though the package is not strictly atomic, its indivisible elements would still be too large for CRAN. My questions are: would this 'foyer' package be acceptable to CRAN? and, if so, what can I do so that the foyer package doesn't eat up CRAN's computing resources (either on submission or once accepted) when checking Suggests: Best, Hugh. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] apparent S3 methods exported but not registered
I'm preparing a new release of PerformanceAnalytics, and as usual this
brings the host of CRAN checks.
I get this note:
* checking S3 generic/method consistency ... NOTE
Found the following apparent S3 methods exported but not registered:
mean.LCL mean.UCL mean.geometric mean.stderr
See section 'Registering S3 methods' in the 'Writing R Extensions'
manual.
these are not S3 methods for 'mean', but rather helper functions that
do other things related to means.
These functions have been in the package for over a decade, are used in
coursework at a number of universities, and we assume are in user code.
So it seems that changing them would be disruptive.
Now, all that said, what to do about it?
We could register them as S3method{} , and I think calling them
explicitly will still work, though this seems inelegant.
I can't find any way to tell R that these *aren't* S3 methods ...
Any insight would be greatly appreciated.
Regards,
Brian
--
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Licensing of an R package
Chris, on C) even commercial packages have licenses. If the commercial package contains a linkable software library, that license is very important in this discussion, because it tells you (us) what you can do with that library. It may say that you can distribute binary code you build with that library, or that you can link other proprietary software to it, or that you can do neither of those things. So the exact license of 'bar' is important to this discussion as well. There are a number of R packages on CRAN that link to commercial libraries or require a commercial library to be available (such as optimization routines), but the exact license of the commercial library needs to be known, and the desired behavior needs to be permitted. Regards, Brian On 01/19/2018 04:19 AM, Chris Brien wrote: Hi Stefan, Here are the answers: A) No, I am simply calling routines. B) By proprietary I mean that it is a commercial package. C) No, it seemed better to use short, distinctive names for the two packages and to focus on the essential issues, namely that `bar' is a commercial package and that `foo' is not. Thanks for your interest. Cheers, Chris From: stefan.mckinnon.edwa...@gmail.com [mailto:stefan.mckinnon.edwa...@gmail.com] On Behalf Of Stefan McKinnon Høj-Edwards Sent: Friday, 19 January 2018 7:58 PM To: Chris Brien Cc: r-package-devel@r-project.org Subject: Re: [R-pkg-devel] Licensing of an R package Hi Chris, Just for clarification, there are at least two aspects that affect how you can license your package. A) Do you distribute `bar` with your package, or are you simply calling routines in `bar`? B) What is the exact license of `bar`? C) Is there a reason for this secrecy of `bar`? If we knew what it was, somebody on this list might have experience with it or similar. If `bar` is not freely available, it doesn't seem your package would be accepted to CRAN (do correct me if I am wrong). Kindly, Stefan McKinnon Hoj-Edwards Stefan McKinnon Høj-Edwards ph.d. Genetics +44 (0)776 231 2464 +45 2888 6598 Skype: stefan_edwards 2018-01-19 8:31 GMT+00:00 Chris Brien <chris.br...@unisa.edu.au>: Dear list members, I have come to realize that my understanding of free software licensing was somewhat naïve. The problem is that I now find that, in spite of spending quite a bit of time reading about various licenses on the web, I have been unable to identify a suitable license for the situation that I have with one of my packages. I am solely responsible for the development of my package, `foo' say. However, most functions in `foo' call functions from a proprietary package, `bar' say , the latter not being available from an online software repository and consisting of R functions that call routines in a library. That is, `foo' enhances `bar'. I had thought that a GPL licence was appropriate because (1) `foo' is free software and (ii) I do not distribute `bar' with `foo'. That is, I am distributing only free software. However, I have come to understand that this is not the case because a free software package linked with a proprietary package does not satisfy the requirements to be GPL. I have found it difficult to work out a license that might cover my package because much of the discussion online covers cases that are the opposite of mine i.e. cases where `foo' is proprietary and `bar' is freeware. I can appreciate why this needs to be avoided. I can also understand that a disadvantage of what I am doing is that it tends to entrench the use of such software. While I agree that it is desirable that `bar' be replaced with free software, unfortunately `bar' has functionality that is currently infeasible to replace with free software. At least I am not profiting from the enhancements that I have made. I am hoping that someone more experienced in software development and licensing issues can suggest a license type that might be suitable for `foo' such that at least the enhancements that it incorporates remain `free'? Cheers, Chris Brien Adjunct Senior Lecturer in Statistics - Phenomics and Bioinformatics Research Centre University of South Australia GPO Box 2471 ADELAIDE 5001 South Australia Phone: +61 8 8302 5535 Fax: +61 8 8302 5785 Email: chris.br...@unisa.edu.au WEB page: <http://people.unisa.edu.au/Chris.Brien> CRICOS No 00121B __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] issues with SOfun - package upload
I think you should be using: Additional_repositories: https://github.com/mrdwab/SOfun since that is the actual repository. Regards, Brian On Wed, 2017-11-08 at 17:01 +0100, LUCA BELMONTE wrote: > Good evening, > > I am trying to upload my package, called PdPDB 2.0. > When building and checking the package with R-studio with --as-cran > option > selected, everything looks ok but, once I tried to upload the package > to > CRAN I had the following reply: > > *"Strong dependencies not in mainstream repositories:* > * SOfun* > ** checking package namespace information ... OK* > ** checking package dependencies ... ERROR* > *Package required but not available: 'SOfun'"* > > I understand the issue it with SOfun that is a package I downloaded > and > installed from this github url: https://github.com/mrdwab/SOfun > > I came back to CARN policies and I have read: > > > *"Packages on which a CRAN package depends should be available from a > mainstream repository: if any mentioned in ‘Suggests’ or ‘Enhances’ > fields > are not from such a repository, where to obtain them at a repository > should > be specified in an ‘Additional_repositories’ field of the DESCRIPTION > file > (as a comma-separated list of repository URLs) or for other means of > access, described in the ‘Description’ field."* > > So, I updated the DESCRIPTION file as follows: > Additional_repositories: http://news.mrdwab.com/install_github.R > > Before to proceed to submission, I would like to know if this is the > right > way to proceed or I misinterpreted the submission procedure. > > Thank you for reading this email, > Best, > __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN upload and prechecking confusion
On 08/24/2017 02:28 AM, Johannes Graumann wrote: Hello, I'm trying to submit a new version (0.10.2) of my package (multipanelfigure) to CRAN and have received the following email: Dear maintainer, package multipanelfigure_0.10.2.tar.gz does not pass the incoming checks automatically, please see the pre-test at: <https://win-builder.r-project.org/incoming_pretest/170824_085724_mul tipanelfigure_0102/00check.log> Status: 2 NOTEs Current CRAN status: ERROR: 1, OK: 10 See: <https://CRAN.R-project.org/web/checks/check_results_multipanelf igure.html> This is confusing. What's the deal breaker? The 2 Notes (which are timing issues related to drawing grid graphics) or the Error on x86_64-apple-darwin15.6.0 which is based on the fact that gridGraphics is unavailable for that platform and even more confungsingly seems to be based on the former version (0.9.0) of the package ... The URL's you've referenced have both expired. I would suggest re-running your package checks using R-devel on RHub and Winbuilder first, and copying any output you receive. Then it will be easier for others to help you. Regards, Brian -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD check not finding my vignettes
sion deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] no visible global function definition for ‘par’
The error you reference below is pretty clear, I think.
You need to add imports for all the functions you're using from other
packages.
See: https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Speci
fying-imports-and-exports
Regards,
Brian
On Mon, 2017-01-30 at 10:39 -0600, Cathy Lee Gierke wrote:
> Yes, that seemed to get rid of the NOTEbut it doesn't seem to
> make much difference other than that. i.e., it seems to process the
> same using CATkit vs CATkit_2.06.tar.gz!
>
> Here is the main error that I am getting. I just upgraded to the
> latest R version, fyi.
>
> Everything was fine, a few minor warnings...now this. Description
> and namespace are proper. These pkgs should all be part of the R
> base, aren't they? Anyone know why I should get these errors?
> Thanks!
>
> * checking R code for possible problems ... NOTE
> Actogram: no visible global function definition for ‘par’
> Actogram: no visible global function definition for ‘barplot’
> Actogram: no visible global function definition for ‘box’
> Actogram: no visible global function definition for ‘text’
> Actogram: no visible global function definition for ‘mtext’
> Actogram: no visible binding for global variable ‘end’
> AutoCorr: no visible global function definition for ‘par’
> AutoCorr: no visible global function definition for ‘layout’
> AutoCorr: no visible global function definition for ‘acf’
> AutoCorr: no visible global function definition for ‘abline’
> AutoCorr: no visible global function definition for ‘title’
> AutoCorr: no visible global function definition for ‘mtext’
> AutoCorr: no visible global function definition for ‘var’
> AutoCorr: no visible binding for global variable ‘end’
> CATCosinor: no visible global function definition for ‘par’
> CATCosinor: no visible global function definition for ‘pdf’
> CATCosinor: no visible global function definition for ‘jpeg’
> CATCosinor: no visible global function definition for ‘png’
> CATCosinor: no visible global function definition for ‘tiff’
> . A zillion more for every function I have..
> periCosinor: no visible global function definition for ‘par’
> periCosinor: no visible global function definition for ‘fft’
> Undefined global functions or variables:
> TukeyHSD abline acf aov as.raster axis barplot box boxplot ccf
> coefficients dev.cur dev.off drop1 end fft gray heat.colors image
> jpeg layout legend lines median model.tables mtext na.action
> na.omit
> palette par pdf pf plot plot.new png points rainbow rasterImage
> read.table str strwidth tail terrain.colors text tiff title ts var
> write.table
> Consider adding
> importFrom("grDevices", "as.raster", "dev.cur", "dev.off", "gray",
> "heat.colors", "jpeg", "palette", "pdf", "png",
> "rainbow",
> "terrain.colors", "tiff")
> importFrom("graphics", "abline", "axis", "barplot", "box",
> "boxplot",
> "image", "layout", "legend", "lines", "mtext", "par",
> "plot", "plot.new", "points", "rasterImage", "strwidth",
> "text", "title")
> importFrom("stats", "TukeyHSD", "acf", "aov", "ccf",
> "coefficients",
> "drop1", "end", "fft", "median", "model.tables",
> "na.action", "na.omit", "pf", "ts", "var")
> importFrom("utils", "read.table", "str", "tail", "write.table")
> to your NAMESPACE file.
>
> Cathy Lee Gierke
> “Darkness cannot drive out darkness: only light can do that. Hate
> cannot drive out hate: only love can do that.”
>
> “The arc of the moral universe is long, but it bends towards
> justice.”
> “Nothing in the world is more dangerous than sincere ignorance and
> conscientious stupidity.”
> “Never forget that everything Hitler did in Germany was legal.”
> “Forgiveness is not an occasional act, it is a constant attitude.”
> “Injustice anywhere is a threat to justice everywhere.”
>
>
> ―
> Martin Luther King Jr.
>
>
>
> On Mon, Jan 30, 2017 at 10:05 AM, Brian G. Peterson <brian@braverock.
> com> wrote:
> > On Mon, 2017-01-30 at 09:45 -0600, Cathy Lee Gierke wrote:
> >
> > > building ‘CATkit_2.06.tar.gz’
> >
> >
> >
> > R CMD build creates a tarball
> >
> >
> >
> > > x-134-84-0-217:CATkit user$ *R CMD check CATkit*
> >
> >
> >
> > but you are checknig the directory, not the tarball.
> >
> >
> >
> > do
> >
> >
> >
> > R CMD check CATkit_2.06.tar.gz
> >
> >
> >
> > instead.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Brian
> >
> >
--
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Description Meta Information Note
On Mon, 2017-01-30 at 09:45 -0600, Cathy Lee Gierke wrote: > building ‘CATkit_2.06.tar.gz’ R CMD build creates a tarball > x-134-84-0-217:CATkit user$ *R CMD check CATkit* but you are checknig the directory, not the tarball. do R CMD check CATkit_2.06.tar.gz instead. Regards, Brian __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Nit-picky vignette questions
In the text of a vignette, I always refer to them with links, just like
I would in other documentation:
\code{\link[xts]{to.period}}
and if I want to be explicit to the reader (who my be reading a format
where the links don't resolve, I would say something like:
see \code{\link[xts]{to.period}} in the \code{xts} package.
In code examples in the vignette, I would use
xts::to.period()
unless I had done a library() or require() call.
Regards,
Brian
On Thu, 2016-12-08 at 12:43 -0800, Roy Mendelssohn - NOAA Federal
wrote:
> Hi All:
>
> In writing a vignette and referring to a function in another
> package, say the function info() in the rerddap package, it it
> better to refer to it as the "rerddap function info()" or as
> "rerddap::info()". This is for the vignette, not what I do
> internally.
>
> Similarly in a code example in a vignette, if I am using the ggplot2
> function ggplot(), which would preferable (this is a non-working
> example just to show the alternative)
>
> require(ggplot2)
> junk <- ggplot()
>
>
> or
>
> junk <- ggplot2::ggplot()
>
> Yes these are nitpicky questions, but as long as I am doing a
> vignette, I might as well try to do all of it in a way that is
> recommended or preferable.
>
> Thanks for any thoughts,
>
> -Roy
>
> PS - Is there something like the Python related program flake8 for R
> code? I have both Google and Hadley's style recommendations, but
> it is nice (though tedious and painful) to have a program that
> points out any inconsistencies from a recommended standard
>
> **
> "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice"
> -MLK Jr.
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Understanding notes from win-builder
In your examples section, do something like this:
\donttest{
Sys.sleep(100) # long running example code here
}
--
Brian
On Mon, 2016-10-03 at 10:44 -0700, Roy Mendelssohn - NOAA Federal wrote:
> Hi Hadley:
>
> > You can use \donttest{} to tell CRAN to not run it as part of their
> > automated tests.
> >
> > Hadley
> >
>
> Thank you for the responses. On the response above, \donttest{} goes where?
> Is that in each R files where I have an example, or somewhere else?
>
> -Roy
>
> **
> "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new address and phone***
> 110 Shaffer Road
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK Jr.
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Build fails at Travis CI
On 06/04/2016 03:13 PM, Daniel Marcelino wrote: I wonder if anyone has experienced this issue with Travis CI. The package I'm committing is just fine, it passes all the CRAN devel checks, but fails at Travis building checks. I realized that if I git commit without the "Collate" section, it passes. However, I've no clue why. I will appreciate any help on this. I have roxygen set to not Collate on all my development machines. Unless you're using S4 with complicated inheritance, you shouldn't need it, and it has caused me many headaches. Regards, Brian -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Data-generating scripts in R packages
On Tue, 2016-03-22 at 08:52 -0400, Kevin Coombes wrote: > I'm currently developing an R package that includes a small data set > along with the functions that I want to export. I have an R script that > generates the data set; the computation time is long (well, relative to > the size of the data set). So, my plan is to run the script and save() > the data set as an *.rda file that I can put in the data directory. (It > is possible that some users of the package will _only_ be interested in > the data set.) > > But, I'd like to keep the script with the package, both because it shows > how to use some of the functions and because I might want to modify how > the data set is generated in the future. My question: What is the "best > practice" for where in the package directory structure to store such a > script? I'd probably put the script in the 'demo' directory so that it would be easy for a user to run it. My team has taken to documenting things like that as RStudio notebooks (.R files with rmarkdown comments that may be compiled as an annotated document), but that's just a suggestion and certainly not necessary. The other place things like this could go would be in the inst/ directory. We have a package that includes several 'parser' scripts for different data providers, and we chose to include these in a directory under inst/ Regards, Brian __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] browseURL in examples
On 08/18/2015 05:12 AM, Berry Boessenkool wrote: Hi all, In the CRAN package policies [1], it says Packages should not start external software (such as PDF viewers or browsers) during examples or tests unless that specific instance of the software is explicitly closed afterwards. If I want to refer to a website with browseURL in the examples, what's the most elegant way to do it? \dontrun -- obtrusive ## not run parts, confuse new R-users # browseURL(www.link.html) -- user must uncomment things Or do you think links should only be used in Vignettes / References section? In this case, it's a reference to a statistical method, and yes, I slightly feel like I'm misusing the examples section. But I think that's where most people explore function usage... I don't see how popping up browser windows for anything other than a demonstration of rendering something to HTML would ever make sense. I think most people explore functions by typing ?functionName Why not just put the links in the documentation for your function? -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD check package subdirectory warning on filenames
On Thu, 2015-06-18 at 09:14 -0400, Ben Bolker wrote: (I didn't know that browsers had trouble accessing file names that started with a digit?) They don't. the relevant rfc, I think, is this one: https://www.ietf.org/rfc/rfc3986.txt the 'unreserved' (allowed) characters are unreserved = ALPHA / DIGIT / - / . / _ / ~ (RFC3986, p. 12) One would assume that R should also allow all unreserved characters in file names for documents, vignettes, etc. Regards, Brian -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
