[R-pkg-devel] .gitkeep file to prevent folder from erasing when empty

[Luck Buttered]

Hello everyone:

I am working on a vignette for a package that outputs reports for users. As
part of the vignette, users can manually run eval=FALSE code that creates
example reports. These example reports that they create can be saved to an
output folder within extdata (extdata/OutputFolder).

When I submit to CRAN, I will be sure that OutputFolder is empty. However,
whenever I make it empty, the entire folder disappears. To combat this
problem, I have placed a .gitkeep file within the OutputFolder.

I *believe* the presence of the .gitkeep file works as intended (prevents
the automatic removal of the OutputFolder when empty). However, upon
running check(), I receive a note:

*checking for hidden files and directories ... NOTE*
*Found the following hidden files and directories:*
*  inst/extdata/OutputFiles/.gitkeep*
*These were most likely included in error. See section ‘Package*
*structure’ in the ‘Writing R Extensions’ manual.*

Does anyone have advice on how to effectively remove this note? Otherwise,
does my rationale above seem like a reasonable purpose for keeping the note?

Thank you for helping me approach this!

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] On implementing zero-overhead code reuse

[Dirk Eddelbuettel]

Kynn,

How much homework have you done researching any other "alternatives" to the
package system?  I know of at least one...

In short, just about everybody here believes in packages. And repositories.
And package management.  And version control (at the package level). And
maybe byte compilation.  And associated documentation.  And unit tests.  And
continuous integration.

You don't have to -- that's cool.  Different strokes for different folks.

But if think you need something different you may just have to build that
yourself.

Cheers, Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] On implementing zero-overhead code reuse

[Kynn Jones]

On Sun, Oct 2, 2016 at 8:01 PM, Kynn Jones  wrote:
> Hi Frederick,
>
> I described what I meant in the post I sent to R-help
> (https://stat.ethz.ch/pipermail/r-help/2016-September/442174.html),
> but in brief, by "zero overhead" I mean that the only thing needed for
> library code to be accessible to client code is for it to be located
> in designed directory.  No additional meta-files, packaging/compiling,
 

Sorry, I meant to write "designated".

> etc. are required.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] On implementing zero-overhead code reuse

[Kynn Jones]

Hi Frederick,

I described what I meant in the post I sent to R-help
(https://stat.ethz.ch/pipermail/r-help/2016-September/442174.html),
but in brief, by "zero overhead" I mean that the only thing needed for
library code to be accessible to client code is for it to be located
in designed directory.  No additional meta-files, packaging/compiling,
etc. are required.

Best,

G.

On Sun, Oct 2, 2016 at 7:09 PM,   wrote:
> Hi Kynn,
>
> Do you mind defining the term "zero-overhead model of code reuse"?
>
> I think I understand what you're getting at, but not sure.
>
> Thank you,
>
> Frederick
>
> On Sun, Oct 02, 2016 at 01:29:52PM -0400, Kynn Jones wrote:
>> I'm looking for a way to approximate the "zero-overhead" model of code
>> reuse available in languages like Python, Perl, etc.
>>
>> I've described this idea in more detail, and the motivation for this
>> question in an earlier post to R-help
>> (https://stat.ethz.ch/pipermail/r-help/2016-September/442174.html).
>>
>> (One of the responses I got advised that I post my question here instead.)
>>
>> The best I have so far is to configure my PROJ_R_LIB environment
>> variable to point to the directory with my shared code, and put a
>> function like the following in my .Rprofile file:
>>
>> import <- function(name){
>> ## usage:
>> ## import("foo")
>> ## foo$bar()
>> path <- file.path(Sys.getenv("PROJ_R_LIB"),paste0(name,".R"))
>> if(!file.exists(path)) stop('file "',path,'" does not exist')
>> mod <- new.env()
>> source(path,local=mod)
>> list2env(setNames(list(mod),list(name)),envir=parent.frame())
>> invisible()
>> }
>>
>> (NB: the idea above is an elaboration of the one I showed in my first post.)
>>
>> But this is very much of an R noob's solution.  I figure there may
>> already be more solid ways to achieve "zero-overhead" code reuse.
>>
>> I would appreciate any suggestions/critiques/pointers/comments.
>>
>> TIA!
>>
>> kj
>>
>> __
>> 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] On implementing zero-overhead code reuse

[frederik]

Hi Kynn,

Do you mind defining the term "zero-overhead model of code reuse"?

I think I understand what you're getting at, but not sure.

Thank you,

Frederick

On Sun, Oct 02, 2016 at 01:29:52PM -0400, Kynn Jones wrote:
> I'm looking for a way to approximate the "zero-overhead" model of code
> reuse available in languages like Python, Perl, etc.
> 
> I've described this idea in more detail, and the motivation for this
> question in an earlier post to R-help
> (https://stat.ethz.ch/pipermail/r-help/2016-September/442174.html).
> 
> (One of the responses I got advised that I post my question here instead.)
> 
> The best I have so far is to configure my PROJ_R_LIB environment
> variable to point to the directory with my shared code, and put a
> function like the following in my .Rprofile file:
> 
> import <- function(name){
> ## usage:
> ## import("foo")
> ## foo$bar()
> path <- file.path(Sys.getenv("PROJ_R_LIB"),paste0(name,".R"))
> if(!file.exists(path)) stop('file "',path,'" does not exist')
> mod <- new.env()
> source(path,local=mod)
> list2env(setNames(list(mod),list(name)),envir=parent.frame())
> invisible()
> }
> 
> (NB: the idea above is an elaboration of the one I showed in my first post.)
> 
> But this is very much of an R noob's solution.  I figure there may
> already be more solid ways to achieve "zero-overhead" code reuse.
> 
> I would appreciate any suggestions/critiques/pointers/comments.
> 
> TIA!
> 
> kj
> 
> __
> 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] grep

[Pi]

Hello.

It would be great if the grep function in R had the option to use the -m
parameter as the linux command does.
That would allow to stop a grep search as soon as something is found.
It would make many operations much faster.

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] Note and warning about subdirectory sizes

[Duncan Murdoch]

On 02/10/2016 4:05 PM, S johnson wrote:

Hi all,

I am running check() on an R package, and receive one note and one warning
(seem to be related):

* checking installed package size ... NOTE
  installed size is 25.9Mb
  sub-directories of 1Mb or more:

doc   3.4Mb
extdata  22.1Mb

* checking sizes of PDF files under ‘inst/doc’ ... WARNING
  ‘gs+qpdf’ made some significant size reductions:
 compacted ‘ePort.pdf’ from 1655Kb to 1076Kb
  consider running tools::compactPDF(gs_quality = "ebook") on these files

After pondering this note, I have three brief questions as follows,

1) When I run "du -hs" on the doc sub-directory, it lists its size as
only 10K. There is only one file inside the doc sub-directory, and
similarly, when I run "du -hs" on that one file, it lists its size as
only 10K. I wonder, then, why check() reports that this sub-directory
called doc is 3.4 Mb?


You are probably looking at the package source; the measurements are 
made after installation.  At that point the vignettes have been copied 
into the doc directory.




2) My extdata sub-directory is rather large. It is certainly over 1Mb.
This is due to a few dozen example images (.png files) that we feel is
important to include in the package. In general, do notes like these prevent
CRAN submission acceptance? If so, what would be an alternative? I
imagine there were other packages that had extdata subdirectory with
example components that are larger than 1Mb - and upon a Google search
that seems to be the case. Still, I wanted to seek your input!


There isn't a hard and fast rule.  If the data is necessary for the 
function of the package, then it will be allowed.  If it is not needed, 
then maybe not.  Often if the data is relatively stable but the code may 
be improved, you'll be asked to put them in separate packages, so that 
CRAN doesn't fill up with archived repetitions of the same data.




3) I am unfamiliar with what I should consider running compactPDF() on.
None of the files are PDF files. The doc sub-directory has one .R file, and
the extdata sub-directory has .R files, .png files (taking up the most
space), and .txt files.



That message is likely talking about a vignette.  See the help page 
?compactPDF for how to invoke it during a build.


Duncan Murdoch

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Note and warning about subdirectory sizes

[S johnson]

Hi all,

I am running check() on an R package, and receive one note and one warning
(seem to be related):

* checking installed package size ... NOTE
  installed size is 25.9Mb
  sub-directories of 1Mb or more:

doc   3.4Mb
extdata  22.1Mb

* checking sizes of PDF files under ‘inst/doc’ ... WARNING
  ‘gs+qpdf’ made some significant size reductions:
 compacted ‘ePort.pdf’ from 1655Kb to 1076Kb
  consider running tools::compactPDF(gs_quality = "ebook") on these files

After pondering this note, I have three brief questions as follows,

1) When I run "du -hs" on the doc sub-directory, it lists its size as
only 10K. There is only one file inside the doc sub-directory, and
similarly, when I run "du -hs" on that one file, it lists its size as
only 10K. I wonder, then, why check() reports that this sub-directory
called doc is 3.4 Mb?

2) My extdata sub-directory is rather large. It is certainly over 1Mb.
This is due to a few dozen example images (.png files) that we feel is
important to include in the package. In general, do notes like these prevent
CRAN submission acceptance? If so, what would be an alternative? I
imagine there were other packages that had extdata subdirectory with
example components that are larger than 1Mb - and upon a Google search
that seems to be the case. Still, I wanted to seek your input!

3) I am unfamiliar with what I should consider running compactPDF() on.
None of the files are PDF files. The doc sub-directory has one .R file, and
the extdata sub-directory has .R files, .png files (taking up the most
space), and .txt files.

Thank you!

[[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 Packages Never Finish Check

[Henrik Bengtsson]

I think R CMD check calls

res <- system2("du", "-k", TRUE, TRUE)

also on Windows, cf.
https://github.com/wch/r-source/blob/trunk/src/library/tools/R/check.R#L3859

It could be that you have a corrupt / different `du` tool on your
PATH.  As a first thing, try calling the above from within you package
directory.  You can also try it on the command line.   You should get
a list of sizes and paths.  If 'du' is doing something else, that
could be your answer.

As Peter says, it could also be that there's a link loop causing `du`
to never finish.  Now that link loop could either be in your package
source or in the temporary package source directory that R CMD check
sets up.  Troubleshooting the latter will be more tricky.

My $.02

Henrik

On Sat, Oct 1, 2016 at 3:02 AM, peter dalgaard  wrote:
>
>> On 30 Sep 2016, at 18:52 , Duncan Murdoch  wrote:
>>
>> On 30/09/2016 12:24 PM, Ortega, Cameron wrote:
>>> Hi,
>>>
>>> When I attempt to run Check on any package, the "checking installed package 
>>> size..." Check never finishes. This is across multiple versions of R and 
>>> RStudio, with every package I have attempted to run, including packages 
>>> confirmed to pass Check quickly and with no issues for others.
>>>
>>> I have attempted to run Check using the following methods:
>>> -Check under the Build tab of RStudio
>>> -Running devtools::check() from the RStudio console
>>> -Running R CMD check from the command line
>>>
>>> Has anyone experienced Check failing to progress on any step, or have any 
>>> ideas about what I should try next?
>>
>> I've never seen that, and I run R CMD check a lot, and devtools::check 
>> sometimes.  So you're probably stuck debugging it yourself.
>>
>> Do the usual debugging things:  simplify the process.  You're using 
>> devtools::check; see if the same thing happens in a terminal running R CMD 
>> check.  Depending on the answer to that, simplify the package down to almost 
>> nothing, and see if it still happens.
>>
>> If you're lucky, it will only happen in devtools::check, and then you can 
>> see what it is doing that's different than what R CMD check does.  If they 
>> both give the same problem, you might need to dive into the R sources to see 
>> what "* checking installed package size ..." really does, and try running 
>> code like that independently.
>>
>
> I think she said that she tried that...
>
> One more thing: when something "checks size" and loops forever, my 
> suspicicion goes in the direction of the file system (link loops and such); 
> perhaps try moving the build (or install) location? Also, our usual foe: 
> virus checkers, could be involved.
>
> Peter D.
>
>> Duncan Murdoch
>>
>>>
>>>
>>> This is my session info:
>>> R version 3.3.1 (2016-06-21)
>>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>>> Running under: Windows 7 x64 (build 7601) Service Pack 1
>>>
>>> locale:
>>> [1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United 
>>> States.1252
>>> [3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
>>> [5] LC_TIME=English_United States.1252
>>>
>>> attached base packages:
>>> [1] stats graphics  grDevices utils datasets  methods   base
>>>
>>> loaded via a namespace (and not attached):
>>> [1] tools_3.3.1
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> This is a print out from the RStudio Check:
>>> ==> devtools::check()
>>>
>>> Updating linkedata documentation
>>> Loading linkedata
>>> Writing NAMESPACE
>>> Writing linkedata.Rd
>>> Writing linke.Rd
>>> Setting env vars 
>>> ---
>>> CFLAGS  : -Wall -pedantic
>>> CXXFLAGS: -Wall -pedantic
>>> Building linkedata 
>>> -
>>> "C:/PROGRA~1/R/R-33~1.1/bin/x64/R" --no-site-file --no-environ --no-save  \
>>>   --no-restore --quiet CMD build  \
>>>   "C:\Users\caort\Documents\Subversion\rcode\lib\src\linkedata"  \
>>>   --no-resave-data --no-manual
>>>
>>> * checking for file 
>>> 'C:\Users\caort\Documents\Subversion\rcode\lib\src\linkedata/DESCRIPTION' 
>>> ... OK
>>> * preparing 'linkedata':
>>> * checking DESCRIPTION meta-information ... OK
>>> * checking for LF line-endings in source and make files
>>> * checking for empty or unneeded directories
>>> Removed empty directory 'linkedata/zipdta'
>>> * looking to see if a 'data/datalist' file should be added
>>> * building 'linkedata_0.1.0.tar.gz'
>>>
>>> Setting env vars 
>>> ---
>>> _R_CHECK_CRAN_INCOMING_ : FALSE
>>> _R_CHECK_FORCE_SUGGESTS_: FALSE
>>> Checking linkedata 
>>> -
>>> "C:/PROGRA~1/R/R-33~1.1/bin/x64/R" --no-site-file --no-environ --no-save  \
>>>   --no-restore --quiet CMD check  \
>>>   "C:\Users\caort\AppData\Local\Temp\Rtmp8EbYiM/linkedata_0.1.0.tar.gz"  \
>>>   --as-cran --timings --no-manual
>>>
>>> * using log directory 
>>> 

[Rd] On implementing zero-overhead code reuse

[Kynn Jones]

I'm looking for a way to approximate the "zero-overhead" model of code
reuse available in languages like Python, Perl, etc.

I've described this idea in more detail, and the motivation for this
question in an earlier post to R-help
(https://stat.ethz.ch/pipermail/r-help/2016-September/442174.html).

(One of the responses I got advised that I post my question here instead.)

The best I have so far is to configure my PROJ_R_LIB environment
variable to point to the directory with my shared code, and put a
function like the following in my .Rprofile file:

import <- function(name){
## usage:
## import("foo")
## foo$bar()
path <- file.path(Sys.getenv("PROJ_R_LIB"),paste0(name,".R"))
if(!file.exists(path)) stop('file "',path,'" does not exist')
mod <- new.env()
source(path,local=mod)
list2env(setNames(list(mod),list(name)),envir=parent.frame())
invisible()
}

(NB: the idea above is an elaboration of the one I showed in my first post.)

But this is very much of an R noob's solution.  I figure there may
already be more solid ways to achieve "zero-overhead" code reuse.

I would appreciate any suggestions/critiques/pointers/comments.

TIA!

kj

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] library() asks user to accept license of some built-in packages

[Prof Brian Ripley]

On 27/09/2016 10:49, Mikko Korpela wrote:

When 'getOption("checkPackageLicense")' is 'TRUE' and the user calls
'library(grid)' for the first time, R asks the user to either accept or
decline the package license. This should not be necessary as the package
license is "Part of R ..." with "..." denoting the R version number, and
R is free and open source.

The unnecessary license question is asked for the built-in packages
"compiler", "grid" and "parallel".

The source file where the checks happen is
"src/library/base/R/library.R". I think one solution could be to add
something like

if(identical(pkgInfo$DESCRIPTION[["Priority"]], "base")) return()

to the beginning of checkLicense(), or add more packages to the
hard-coded exemption list checked before calling checkLicense().


Rather, the analysis code has been told about the current licence for 
standard packages.



Also, in find.package(), the shortcut list of standard packages is
missing "compiler".


Which was intentional when the code was written (it is just a shortcut) 
but as 'compiler' is getting used more, it has been added.



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel