[R-pkg-devel] Including a jar file in a package
We are developing a package that makes a call out to a Java program. We have placed a jar file for this program in inst/java and it works nicely. However, when we run R CMD check, it results in a NOTE: * checking installed package size ... NOTE installed size is 11.0Mb sub-directories of 1Mb or more: java 10.8Mb Is it likely that CRAN would accept a package that includes a large subdirectory like this? If not, what is the recommended way to do this? The nice thing about our current solution is that the user of our package does not need to separately install the Java program and deal with Java's classpath. Thanks for the advice. Barbara -- <http://www.getpostbox.com>Barbara Lerner Associate Professor Computer Science Department Mount Holyoke College <http://www.getpostbox.com><http://www.getpostbox.com> [[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] Including a jar file in a package
Thanks for this advice. The Java code was developed by our project and is not used by any other R packages. Barbara > Duncan Murdoch <mailto:murdoch.dun...@gmail.com> > August 23, 2017 at 12:56 PM > > > It likely depends on the circumstances. Did you write the Java code > in the jar file? If not, does any other CRAN package use the same jar > file? It doesn't really make sense for both of you to package it. > > Assuming the jar file isn't already on CRAN, and it really is > necessary for your package, and your package adds something to CRAN, > they'll probably allow it. You should include a comment with your > submission explaining why you need the exception. > > Duncan Murdoch > Barbara Lerner <mailto:bler...@mtholyoke.edu> > August 23, 2017 at 12:07 PM > We are developing a package that makes a call out to a Java program. > We have placed a jar file for this program in inst/java and it works > nicely. However, when we run R CMD check, it results in a NOTE: > > * checking installed package size ... NOTE > installed size is 11.0Mb > sub-directories of 1Mb or more: > java 10.8Mb > > Is it likely that CRAN would accept a package that includes a large > subdirectory like this? If not, what is the recommended way to do > this? The nice thing about our current solution is that the user of > our package does not need to separately install the Java program and > deal with Java's classpath. > > Thanks for the advice. > > Barbara > -- <http://www.getpostbox.com>Barbara Lerner Associate Professor Computer Science Department Mount Holyoke College <http://www.getpostbox.com><http://www.getpostbox.com> [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Saving provenance data to the file system
We are working on a package that collects provenance as an R script executes, saving the provenance to the file system. In reading the rules for submitting packages to CRAN, there is this rule: > Packages should not write in the users’ home filespace, 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). Installing into the system’s R > installation (e.g., scripts to its bin directory) is not allowed. > Limited exceptions may be allowed in interactive sessions if the > package obtains confirmation from the user. To use our package, the R programmer calls a function that has an optional parameter to specify where the provenance is saved. I have a few questions about whether this approach will pass CRAN or some other alternatives we have considered. 1. Currently, we save to the user's file space and provide an optional parameter to save the provenance somewhere else. Is this acceptable? 2. A second alternative would be to have the default location be the R session's temporary directory. To save in the user's file space, the user would need to provide a value for the optional parameter mention in #1. 3. A third alternative would be to do the same as #2 and also ask the user to confirm that they want to save the provenance before actually writing to the filesystem. 4. A fourth alternative would be to save the provenance in a database, which might or might not be on the user's computer. I would appreciate advice on which of these options is likely to pass CRAN's rules. Our package will be of little use if the provenance is not saved somewhere. Thanks for any advice. Barbara -- <http://www.getpostbox.com>Barbara Lerner Associate Professor Computer Science Department Mount Holyoke College <http://www.getpostbox.com><http://www.getpostbox.com> [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Package from non-mainstream repository
When checking my package with R-devel, I get the following notes. In the current and earlier versions of R, I got the same note concerning incoming feasibility, but the NOTE about the package not being available for checking did not occur. What do I need to do to get rid of that note? * checking CRAN incoming feasibility ... NOTE Maintainer: 'Barbara Lerner ' Suggests or Enhances not in mainstream repositories: rdt Availability using Additional_repositories specification: rdt yes https://end-to-end-provenance.github.io/drat/ * checking package namespace information ... OK * checking package dependencies ... NOTE Package suggested but not available for checking: 'rdt' Thanks for your help! Barbara -- <http://www.getpostbox.com>Barbara Lerner (she / her) Professor Computer Science Department Mount Holyoke College <http://www.getpostbox.com> [[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] Slowdown running examples since 4.2 on Windows
Thanks for these suggestions. I attempted to submit a slightly earlier version of my package a few weeks ago and saw the slowdown on winbuilder then, too. I did not look into any further at that point. I have tested it on a local Windows computer running 4.2.0 and I did not see the slowdown there. Here are those results: Name user system elapsed prov.json 1.11 0.24 2.19 prov.run 0.99 0.06 1.93 version R version 4.2.0 (2022-04-22 ucrt) os Windows 10 x64 (build 19044) system x86_64, mingw32 Tomas Kalibera wrote on 6/30/22 10:09 AM: > > On 6/29/22 22:25, Barbara Lerner wrote: >> I have a package that I want to submit an updated version for but the >> examples run too slowly on win-builder since 4.2 came out. I just >> submitted the exact same tar.gz file to all 3 versions of R available on >> win-builder and got the results shown below. Notice the dramatic >> slowdown from 4.1.3 to 4.2.1. >> >> I don't know how to go about tracking down the cause of this slowdown. >> The examples are quite small. I am reluctant to use \dontrun, but I am >> not sure what else to do. > > Could you perhaps submit to Winbuilder several times (with some > non-trivial delay between the runs) to see if the very long execution > is reproducible? > > If so, the next step could be trying on a Windows machine with > interactive access, to reproduce, and if it is still so slow, checking > where the time is spent, using an R profiler, using some C profiler > (e.g. VerySleepy is free), comparing possibly to 4.1.3. It might be > useful or necessary to also do the profiling with a debug build of > Windows and/or the package, while the performance numbers will be > skewed, one would see the symbol names. > > If you wanted specific help, please send a reproducible example - > instructions how to run the code and which code. > > Best > Tomas > >> >> June 29 2:33 PM - old release >> * using R version 4.1.3 (2022-03-10) >> i386 timings >> name user system elapsed >> prov.json 3.28 0.33 5.19 >> prov.run 2.70 0.27 4.18 >> >> x64 timings >> name user system elapsed >> prov.json 3.51 0.27 4.93 >> prov.run 3.05 0.28 4.48 >> >> >> June 29 2:19 PM - release >> * using R version 4.2.1 (2022-06-23 ucrt) >> * using platform: x86_64-w64-mingw32 (64-bit) >> name user system elapsed >> prov.json 16.98 8.81 26.82 >> prov.run 3.53 0.42 4.89 >> >> >> June 29 1:52 PM - devel >> * using R Under development (unstable) (2022-06-28 r82534 ucrt) >> * using platform: x86_64-w64-mingw32 (64-bit) >> name user system elapsed >> prov.json 16.60 9.09 26.66 >> prov.run 3.57 0.22 4.70 I then ran the same timing script as >> win-builder uses on my Mac, >> using Rscript and got these results: name user system elapsed >> prov.json 1.105 0.159 1.329 prov.run 0.890 0.103 >> 1.053 session_info reports: version R version 4.2.0 (2022-04-22) >> os macOS Catalina 10.15.7 system x86_64, darwin17.0 I then >> installed 4.2.1 on my Mac. The time is a little slower but nothing like >> the slowdown on Windows. >> name user system elapsed prov.json 1.286 0.230 3.080 >> prov.run 0.940 0.108 1.131 version R version 4.2.1 >> (2022-06-23) os macOS Catalina 10.15.7 system x86_64, >> darwin17.0 >> -- <http://www.getpostbox.com>Barbara Lerner (she / her) Professor Computer Science Department Mount Holyoke College <http://www.getpostbox.com> [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] R CMD check works but with devtools::check() examples fail
checking package namespace information ...
✔ checking package dependencies (3.1s)
✔ checking if this is a source package
✔ checking if there is a namespace
✔ checking for executable files (439ms)
N checking for hidden files and directories
Found the following hidden files and directories:
.commit
These were most likely included in error. See section ‘Package
structure’ in the ‘Writing R Extensions’ manual.
✔ checking for portable file names
✔ checking for sufficient/correct file permissions
✔ checking whether package ‘rdtLite’ can be installed (3s)
✔ checking installed package size ...
✔ checking package directory ...
✔ checking for future file timestamps ...
✔ checking DESCRIPTION meta-information ...
✔ checking top-level files
✔ checking for left-over files
✔ checking index information
✔ checking package subdirectories ...
✔ checking R files for non-ASCII characters ...
✔ checking R files for syntax errors ...
✔ checking whether the package can be loaded ...
✔ checking whether the package can be loaded with stated dependencies ...
✔ checking whether the package can be unloaded cleanly ...
✔ checking whether the namespace can be loaded with stated dependencies ...
✔ checking whether the namespace can be unloaded cleanly ...
✔ checking dependencies in R code (800ms)
✔ checking S3 generic/method consistency (760ms)
✔ checking replacement functions ...
✔ checking foreign function calls (437ms)
✔ checking R code for possible problems (5.5s)
✔ checking Rd files ...
✔ checking Rd metadata ...
✔ checking Rd line widths ...
✔ checking Rd cross-references ...
✔ checking for missing documentation entries ...
✔ checking for code/documentation mismatches (563ms)
✔ checking Rd \usage sections (879ms)
✔ checking Rd contents ...
✔ checking for unstated dependencies in examples ...
E checking examples (2s)
Running examples in ‘rdtLite-Ex.R’ failed
The error most likely occurred in:
> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> ### Name: prov.json
> ### Title: Provenance Access Functions
> ### Aliases: prov.json prov.dir prov.visualize prov.summarize
>
> ### ** Examples
>
> prov.init()
> a <- 1
--- FAILURE REPORT --
--- failure: length > 1 in coercion to logical ---
--- srcref ---
:
--- package (from environment) ---
rdtLite
--- call from context ---
.ddg.proc.node("Operation", cmd@abbrev, cmd@abbrev, functions.called
= cmd@functions.called,
cmd = cmd)
--- call from argument ---
!is.null(functions.called) && !is.na(functions.called)
--- R stacktrace ---
where 1: .ddg.proc.node("Operation", cmd@abbrev, cmd@abbrev,
functions.called = cmd@functions.called,
cmd = cmd)
where 2: .ddg.parse.commands(as.expression(task), environ = .GlobalEnv,
run.commands = FALSE)
where 3: (function (task, result, success, printed)
{
.ddg.parse.commands(as.expression(task), environ = .GlobalEnv,
run.commands = FALSE)
return(TRUE)
})(base::quote(a <- 1), 1, TRUE, FALSE)
--- value of length: 3 type: logical ---
[1] TRUE TRUE TRUE
more lines omitted ...
--- END OF FAILURE REPORT --
Fatal error: length > 1 in coercion to logical
✔ checking for unstated dependencies in ‘tests’ ...
─ checking tests ...
✔ Running ‘test-all.R’ (685ms)
--
<http://www.getpostbox.com>Barbara Lerner
Professor
Computer Science Department
Mount Holyoke College
<http://www.getpostbox.com>
[[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] R CMD check works but with devtools::check() examples fail
Hi Dirk,
This is very helpful, thank you! The R Internals document gave me the
clues that I need.
I am pretty certain that more things are being checked than before as
problems are being reported with code that has not changed. In
particular, it is checking if logical expressions are returning a vector
of length > 1. I had is.null tests where I wanted to check if a
variable was null. Unfortunately, when the variable contained a vector,
it was checking whether the members were null, which is not what I
intended. I understand the error reports now and can fix these.
Barbara
Dirk Eddelbuettel wrote on 5/16/19 11:36 AM:
> Hi Barbara
>
> Feel free to CC back to the list which dropped off.
>
> On 16 May 2019 at 10:56, Barbara Lerner wrote:
> | You are right --as-cran gives the same errors as devtools::check. When
> | it comes to running the examples, what is done differently with the
> | as-cran flag?
>
> Coarse level answer: we are asked to --as-cran per CRAN Repo Policy
>
> Finer level answer: it sets a few more tests, does remote check etc pp which
> is why it is not default. The fuller details are in the R manuals 'Writing R
> Extensions' and (oddly) in Section 8 of 'R Internals' (bad title, makes it as
> if we mortals were not supposed to look there) which details _all_ of the
> _many_ environment variables that can be turned on and off.
>
> From the top of my head, I am not sure why example would run/not run. That
> has not happened to me in 20+ years of writing / using / binary building
> packages. But I did not have time to dig -- could use/don't use suggested
> packages, could be honor/disregards \dontrun{} or \donttest{} flags. You will
> know your package better -- with some some digging I am sure you will get to
> it.
>
> Best, Dirk
>
--
<http://www.getpostbox.com>Barbara Lerner
Professor
Computer Science Department
Mount Holyoke College
<http://www.getpostbox.com>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
