Re: [R-pkg-devel] browseURL in examples

[Mark van der Loo]

Berry,

why not use

\href{[your link]}{[link text]}

in the documentation details[1]?

Best,
Mark
[1] https://cran.r-project.org/doc/manuals/R-exts.html#Marking-text



Op di 18 aug. 2015 om 13:21 schreef Duncan Murdoch :

> On 18/08/2015 6: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
>
> Using "if (interactive()) browseURL(...)" is a reasonable way.
>
> Duncan Murdoch
>
> >
> >
> > 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...
> >
> >
> > Thanks for any ideas and thoughts,
> > Berry
> >
> > [1]
> > https://cran.r-project.org/web/packages/policies.html
> >
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > 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
>

[[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] [[openmx-dev]] Re: [[openmx-dev]] Re: openmp

[Mark van der Loo]

At least on linux, CRAN builds using openMP. I got a valgrind report once
[shame on me btw] showing that 9 (out of 10) threads were running examples.


So my best guess is that it will do the same for Windows since it also has
openMP support according to WRE[1].  I wouldn't know why not, except for
the reasons Dirk already mentioned. It will not do this for OS X since WRE
states clearly that

OS X nowadays uses clang, and the Apple builds currently have no OpenMP
support.

so if nobody has openMP support on OS X, for sure CRAN doesn't have it.
/M

[1]https://cran.r-project.org/doc/manuals/R-exts.html#OpenMP-support



Op ma 24 aug. 2015 om 19:04 schreef Joshua N Pritikin :

> On Mon, Aug 24, 2015 at 09:57:05AM -0700, Zhian Kamvar wrote:
> > The way several packages have implemented OpenMP is to wrap it in
> > pre-compiler statements i.e.:
> >
> > // Include openMP if the compiler supports it
> > #ifdef _OPENMP
> > #include 
> > #endif
> >
> > This way, all compilers can build the code and those that have OpenMP
> > (even modified versions of clang: https://clang-omp.github.io/) can do
> > so in a parallel fashion.
>
> Yes, of course, but you're missing the point of my enquiry. My question
> is whether it is possible for CRAN to build and distribute openmp
> enabled binaries.
>
> --
> Joshua N. Pritikin
> Department of Psychology
> University of Virginia
> 485 McCormick Rd, Gilmer Hall Room 102
> Charlottesville, VA 22904
> http://people.virginia.edu/~jnp3bc
>
> __
> 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

Re: [R-pkg-devel] [[openmx-dev]] [[openmx-dev]] Re: [[openmx-dev]] Re: openmp

[Mark van der Loo]

If you want to distributed such binaries, I would suggest using the 'drat'
package to set up your own repo. I'm using it for beta versions of my
packages and I find it very useful and easy to use. The latest version of
'drat' also supports binaries.

Or, vote with your feet and switch to Linux ;-).

/M



Op ma 24 aug. 2015 om 23:44 schreef Michael Neale :

> Yes, well, we have support for our own parallel build of an OS X version
> of R package using OpenMP and gcc, but I don’t suppose that CRAN
> maintainers would be interested in also supporting OS X in this fashion.
> Supplying binaries seems the only option unless clang developers decide to
> support OpenMP, which seems unlikely since Apple wants to promote its own
> parallel computing tools.
>
> Michael Neale
> mcne...@mac.com
>
>
>
> On Aug 24, 2015, at 3:38 PM, Mark van der Loo 
> wrote:
>
>
> At least on linux, CRAN builds using openMP. I got a valgrind report once
> [shame on me btw] showing that 9 (out of 10) threads were running examples.
>
>
> So my best guess is that it will do the same for Windows since it also has
> openMP support according to WRE[1].  I wouldn't know why not, except for
> the reasons Dirk already mentioned. It will not do this for OS X since WRE
> states clearly that
>
> OS X nowadays uses clang, and the Apple builds currently have no OpenMP
> support.
>
> so if nobody has openMP support on OS X, for sure CRAN doesn't have it.
> /M
>
> [1]https://cran.r-project.org/doc/manuals/R-exts.html#OpenMP-support
>
>
>
> Op ma 24 aug. 2015 om 19:04 schreef Joshua N Pritikin  >:
>
>> On Mon, Aug 24, 2015 at 09:57:05AM -0700, Zhian Kamvar wrote:
>> > The way several packages have implemented OpenMP is to wrap it in
>> > pre-compiler statements i.e.:
>> >
>> > // Include openMP if the compiler supports it
>> > #ifdef _OPENMP
>> > #include 
>> > #endif
>> >
>> > This way, all compilers can build the code and those that have OpenMP
>> > (even modified versions of clang: https://clang-omp.github.io/) can do
>> > so in a parallel fashion.
>>
>> Yes, of course, but you're missing the point of my enquiry. My question
>> is whether it is possible for CRAN to build and distribute openmp
>> enabled binaries.
>>
>> --
>> Joshua N. Pritikin
>> Department of Psychology
>> University of Virginia
>> 485 McCormick Rd, Gilmer Hall Room 102
>> Charlottesville, VA 22904
>> http://people.virginia.edu/~jnp3bc
>>
>> __
>> 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

Re: [R-pkg-devel] why doesn't CRAN add -fopenmp to SHLIB_OPENMP_CXXFLAGS for Mac OS?

[Mark van der Loo]

It is not a question of whether the CRAN maintainers _could_ do it.
Technically anything's possible[1]. But, as is nicely pointed out[2]

"The time of the volunteers is CRAN’s most precious resource[...]"

If you ask me, the voluntary CRAN team is already supporting an amazing
range of architectures, which must be a huge job to maintain. Especially
since R and all its packages should behave consistently across all those
architectures.

I agree it is a pity that clang does not support openmp, but that's just
the way it is right now. (note: I use openmp in several packages).

You could contact the CRAN team and ask if they would be prepared to add
the gcc toolchain as an option for OSX. Or, you can contact the clang team
for openmp support.

Other options:
- Switch to C11/C++11 which has (lower-level) paralellization in the
standard and should be supported by any compiler that claims compliance.
- Use higher-level paralellization, such as offered by the parallel or
partools

Best,
Mark

[1] Well, one problem is: how would install.packages know what binary to
choose: the one compiled by clang or the one compiled by gcc?

[2] https://cran.r-project.org/web/packages/policies.html





Op vr 28 aug. 2015 om 15:26 schreef Joshua N Pritikin :

> For example, mvnfast CRAN binaries could take advantage of OpenMP.
>
> The OpenMx team has been building Mac OS binaries with openmp enabled
> for years. We compile with gcc and bundle the necessary openmp enabled
> libraries with the binary. Why couldn't CRAN do this?
>
> --
> Joshua N. Pritikin
> Department of Psychology
> University of Virginia
> 485 McCormick Rd, Gilmer Hall Room 102
> Charlottesville, VA 22904
> http://people.virginia.edu/~jnp3bc
>
> __
> 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

Re: [R-pkg-devel] extending a few functions from another package

[Mark van der Loo]

Implanting is indeed a dirty trick. You could contact the maintainers of
geoR and ask if your code can be added to the package. Or perhaps they can
export some of the functionality you need.

/M







Op vr 28 aug. 2015 om 16:58 schreef Facundo Muñoz :

> Dear list,
>
> I have built a package geoRcb (https://github.com/famuvie/geoRcb) which
> is an extension of package geoR.
> It provides some very specific additional functionality, in the form of
> new arguments for only 3 functions from geoR.
> It also has some original complementary functions, but otherwise keeps
> most of geoR untouched.
>
> To avoid forking the whole geoR package (and duplicating the vast
> majority of the code), I only packaged the modified (or original)
> functions. However, since these functions make use of some other
> internal functions, I used the dirty trick of *implanting* the modified
> functions within the geoR namespace
> (https://github.com/famuvie/geoRcb/blob/master/R/geoRcb.R)
>
> I understand that modifying another package's namespace is very bad.
> But I don't see how to proceed correctly in this case without forking
> the whole package.
>
> Thanks for your suggestions.
> ƒacu.-
>
> __
> 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

Re: [R-pkg-devel] Diagnosing error on CRAN's old R, old Windows

[Mark van der Loo]

I had the same problem recently. It was apparently a windows-only
oldrel-only problem (and a specific oldrel, I can't remember which one). I
opted to adjust the DESCRIPTION to depend on a higher R version. Main
reason was that I don't have access to the right type of Windows version to
test it locally and the winbuilder service only tests on the most recent
R-versions (current and R-devel).

These system-dependent problems pop up now and then, causing work on both
CRAN volunteer and developer side. Especially the work on the volunteer
side could/should be avoided. So here's a nudge-nudge wink-wink to the R
consortium to set up a builder service that fully emulates CRAN. It is
probably not trivial but I feel it would be of value. More ambitiously,
such a builder service could include (attempts to) build against other R
engines apart from the GNU implementation -- but I'm digressing.

Best,
Mark









Op do 8 okt. 2015 om 16:52 schreef Ben Bond-Lamberty :

> >Unfortunately the error diagnostics are not particularly helpful, only
> showing that four tests failed; the only common thread I see, maybe, is
> that all four tests--and no others--use R's file.size() function.
>
> Brief follow-up for completeness: it turns out that `file.size()`
> doesn't exist on Windows R 3.1.1 - instead need to use
> `file.info()$size`. So problem fixed, although I still don't know why
> no error message was appearing.
>
> B
>
> __
> 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

Re: [R-pkg-devel] install from github

[Mark van der Loo]

>> is someone aware of a way to easily install a package hosted on github
without using devtools::install_github?

Personally, I love Dirk's[1] drat package. It allows authors to set up a
personal CRAN-like system on their github pages. This means that the author
of the package can decide when a (beta) release of a package is ready for
use. I use it frequently, for example to allow people to confirm bug fixes
prior to resubmitting to CRAN.

>> Does anyone else ever need to avoid devtools?

I love devtools, but avoid install_github. Be aware that installing from
github does require some knowledge of the (directory) structure of the
repo, which not necessarily is that of a package. For example, in my
R-package repos, the package is always behind a pkg/[pkgname] folder. Besides
that you can't be sure that a package downloaded from github actually
builds (unless the author uses a build service), there are issues with
documentation. install_github for example presumes that all Rd files are in
the repo[2]. As these are nowadays mostly generated by Roxygen2, I feel
such files do not belong there and since the creation of Roxygen I've left
them out. Other authors might do the same.

I also wonder about the use case of install_github in an R-course. The
courses I teach never depend on software that are in an experimental stage
(there's enough to teach on CRAN)

>> Would something doing that be worth a package on CRAN?

I agree with the dependency issue, so in that sense yes. But to make it
robust, repo-owners probably need to adhere to either a pure R package
structure or start using makefiles for package building.


Best,
Mark

[1] When I say Dirk, I assume you know which one :-).
[2] At least, this used to be true. I haven't used it in a while.









Op do 3 dec. 2015 om 10:01 schreef Rainer M Krug :

> Berry Boessenkool  writes:
>
> > Hi,
> >
> > is someone aware of a way to easily install a package hosted on github
> without using devtools::install_github?
> > Does anyone else ever need to avoid devtools?
> Hi,
>
> Check out drat [https://github.com/eddelbuettel/drat]  and for a
> description check out
> [http://eddelbuettel.github.io/drat/DratForPackageAuthors.html].
>
> Be aware that I have never used it - but I should...
>
> Cheers,
>
> Rainer
>
>
> > Would something doing that be worth a package on CRAN?
> > Optional if no,yes,yes: Is my basic idea below any good at all?
> >
> > Thanks ahead,
> > Berry, Potsdam, Germany
> >
> > Details:
> >
> > devtools has so many dependencies that it takes quite some time to
> install on old computers or with slow internet. Not suitable for a quick
> demo in the R course I'm teaching, which I found out the hard way (thinking
> R had hung up, I terminated it, crashing Rstudio in the proces...).
> > Not finding anything and happy to postpone actual work, I wrote some
> (very!) basic code. I doubt it works across platforms and situations. I
> guess I'm doing useless stuff, but I had fun and learned a few new things...
> >
> >
> > instgithub <- function(
> >pk, # "user/package"
> >cleanup=TRUE, # remove downloaded zipfile and folder with source code
> >...) # Further arguments passed to install.packages, untested so far
> > {
> > pkn <- strsplit(pk, "/")[[1]][2] # package name part
> > download.file(url=paste0("https://github.com/
> ",pk,"/archive/master.zip"),
> >   destfile=paste0(pkn,".zip"))
> > unzip(paste0(pkn,".zip"))
> > file.rename(paste0(pkn,"-master"), pkn)
> > # Dependencies - really not elegant at all!
> > deps <- read.dcf(paste0(pkn, "/DESCRIPTION"), fields="Imports")
> > deps <- strsplit(deps, ", ")[[1]]
> > deps <- sapply(strsplit(deps, " ", fixed=T), "[", 1) # remove version
> restrictions
> > deps <- deps[!deps %in% rownames(installed.packages())] # install only
> new packages
> > # install dependencies
> > dummy <- lapply(na.omit(deps), install.packages, ...)
> > # actually install the package itself:
> > install.packages(pkn, repos=NULL, type="source", ...)
> > # clean up:
> > if(cleanup)
> >   {
> >   unlink(pkn, recursive=TRUE)
> >   unlink(paste0(pkn,".zip"))
> >   }
> > }
> >
> > # example test cases, work fine on windows 7 with current R3.2.2 + write
> permission at getwd:
> > if(FALSE){
> > instgithub(pk="brry/extremeStat")
> > library(extremeStat)
> > instgithub("talgalili/installr")
> > instgithub("hadley/readxl")
> > }
> >
> >
> >
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
> Biology, UCT), Dipl. Phys. (Germany)
>
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
>
> Tel :   +33 - (0)9 53 10 27 44
> Cell:   +33 - (0)6 85 62 59 98
> Fax :   +33 - (0)9 58 10 27 44
>
> Fax (D):+49 - (0)3 21 21 25 22 44
>
> email:  rai...@krugs.de
>

Re: [R-pkg-devel] Package was removed from CRAN "despite reminders" -- but I did not receive any such messages

[Mark van der Loo]

Mail the CRAN team.

On Wed, Jun 1, 2016, 10:24 Dean Attali  wrote:

> My package 'ddpcr' was accepted into CRAN in 2016-02-19 and then updated on
> 2016-03-17.  There were no errors or warnings or notes in my submission and
> it was accepted right away.
>
> I just tried going to its CRAN page and I found out that the package was
> removed a month ago.
> https://cran.r-project.org/web/packages/ddpcr/index.html
>
> The text on the page reads "Archived on 2016-05-02 as check problems were
> not corrected despite reminders."  I'm not sure what check problems it's
> referring to as I never received any communication from CRAN or from
> anybody else about this.  Neither did I receive any "reminders".
>
> Is there any way for me to see what problems exactly it was having?  Is it
> ok for me to try to just re-submit the package?
>
> Thanks
>
> ---
> http://deanattali.com
>
> [[alternative HTML version deleted]]
>
> __
> 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

Re: [R-pkg-devel] relation between vignettes and help files

[Mark van der Loo]

Afaik the only way to link to a vignette from the help file is to instruct
the reader to do something like

vignette('intro','mypkg')

On the R command-line.

In general, the Rd files describe the public API of your pkg. Each exported
function should have a help file that ideally can be read and understood in
isolation. The vignettes can provide walk-throughs for tasks that require a
sequence of functions to be called. This helps the user to get around the
package by focusing on tasks.

Although you will probably duplicate a little information, try to focus  on
subject matter in the vignette, while focusing on the technical aspects in
the Rd files.

Hope that helps,
Mark

On Wed, Jul 13, 2016, 21:29 Boylan, Ross  wrote:

> I have two questions, one substantive and one technical, about the
> relation between vignettes and help files.  By "help files" I mean the
> regular .Rd files.
>
> Substantively, to what extent should material be duplicated between the
> help files and the vignette?  For example, my vignette includes some output
> summarizing the analysis.  The output has many different kinds of
> information, and the details about what they mean are in the help for the
> function generating the output.  Any advice on how much of that information
> to put in the vignette?.  The vignette could, of course, say to see the
> help for the function for details.
>
> It seems natural to me  to have the information in both  places, except
> that doing so invites inconsistencies as the code changes, if not
> immediately.
>
> The leads to the the technical question: is there a way to provide links
> to the help from the vignette?  I'm using Sweave.  And, similarly, is there
> a way to reference the vignettes from the help?  In particular, it seems
> natural to reference the vignette from the package help.
>
> Thanks.
> Ross Boylan
> __
> 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] openMP/reduction statement causes build crash on travis-ci

[Mark van der Loo]

Dear pkg developers,


I'm working on a package using C code and openMP. The package builds and
tests fine on my own machine[1] and also on r-hub[2]. However on travis-ci
the build crashes[3] with the following message (plus a few similar):

gower.c:297:29: error: expected ‘+’, ‘*’, ‘-’, ‘&’, ‘^’, ‘|’, ‘&&’, or ‘||’
before ‘min’

The line in question is an #omp pragma statement:

  #pragma omp for reduction(min:imin), reduction(max:imax)


I am using #pragma omp statements all over the place and this is the only
type causing crashes. I'm guessing it has something to do with travis
building on a 12.04 ubuntu VM with a rather old  gcc (4.6.3).

So I have two questions:

1. Has anyone else seen this? Or am I missing something?
2. Is there a workaround, or should I just go for another build service
(which one)?

Cheers,
Mark


[1] Linux duvel 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux w/gcc 5.4.0, libgomp1.0.0
[2]
https://builder.r-hub.io/status/gower_0.0.1.tar.gz-8c487e92f4af364ee73f85ca8f59775c
[3] https://travis-ci.org/markvanderloo/gower#L619

[[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] Handling Not-Always-Needed Dependencies?

[Mark van der Loo]

After reading the link in Dirk's initial reply, how about adding
fields 'Recommends'
and 'Build-Depends' to DESCRIPTION as in Debian?

Recommends: only gets installed, can be used via if(requireNamespace())
from the package and in pkg tests[1]. [Debian: The Recommends field should
list packages that would be found together with this one in all but unusual
installations.]
Build-Depends: gets installed before build, removed after.
Suggests: only installed when requested at install.packages() and only used
in examples/vignettes.

If 'tons of packages' are using if(requireNamespace) in their package code
there seems to be a need for something like this. Compliance to the above
can be checked automatically and  a gradual implementation via
NOTE->WARNING->ERROR in R CMD check seems possible.

Perhaps more controversially a 'Breaks' field could be considered. There
are a few packages out there that have many, many, dependencies.
Implementing breaking updates currently depends on the willingness of many
authors to update their package or convincing the CRAN maintainers to allow
for (temporary) breakage.

The suggestion to have functions auto-install things is very inconvenient
for the good reasons pointed out by Thomas. Additionally, it is often based
on the wrong assumptions. Example: the RGtk2 package has this habit of
trying to install when libgtk2 is not on the path. But in my case that is
often exactly the case: it is just not on the path (libgtk2 is on the
network, the VM just doesn't know yet). So I'd rather have a proper and
accurate error message (which is good practice anyway).


Best,
Mark

[1] actually, once we know a pkg is Recommended, the 'if(requireNamespace)'
could even be absorbed in the :: operator.




Op wo 3 aug. 2016 om 01:46 schreef Duncan Murdoch :

> On 02/08/2016 6:34 PM, Dirk Eddelbuettel wrote:
> >
> > On 2 August 2016 at 18:13, Duncan Murdoch wrote:
> > | Okay, now I think I understand, but I agree with CRAN.  It is not
> > | feasible to tell if the test happened somewhere in the code unless we
> > | enforce a particular way of writing the test.
> >
> > Debian has well over 20k packages, and they are tested this way.  You
> just
> > need to show the will of testing in an _empty_ environment to ensure
> > _everything_ that is needed is loaded.
> >
> > | I would object if I had to write if (requireNamespace("foo")) multiple
> > | times just to satisfy CRAN's test, when any sane human could tell that
> > | the first test was sufficient.
> > |
> > | For example, if my package Suggests: foo, I should be able to write
> > |
> > | if (!requireNamespace("foo"))
> > |stop("Package foo is needed for this example")
> > |
> > | and then merrily call foo::bar() as many times as I like.
> > |
> > | Or am I still misunderstanding you?  What particular thing should CRAN
> > | change?
> >
> > You seem to misunderstand that both you and I want
> >
> >   if (!requireNamespace("foo"))
> >  stop("Package foo is needed for this example")
> >
> > (or alternative per-call tests) and that CRAN does not enforce either.
> >
> > CRAN, like Hadley, just closes its eyes, swallows hard, and then simply
> loads
> > everything treating Suggests as if it were Depends.
> >
> > But it ain't. Suggests != Depends.
> >
> > Now clearer?
>
>
> So really what you're suggesting is that CRAN should run tests with the
> suggested packages absent.  Presumably tests should also be run with
> them present.
>
> But if they did that, the code that I want to write would call stop()
> and fail.  So we'd need some way to say "Let the user know they need
> 'foo' to run this, but don't fail."  And we'd need to phase this in
> really gradually, because tons of packages are using code like my example.
>
> You volunteered to help CRAN package checking.  Why not put together
> code to implement your idea, and see how big the problem would be to
> phase it in, by seeing how many packages fail under it?
>
> Duncan Murdoch
>
> __
> 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

Re: [R-pkg-devel] Handling Not-Always-Needed Dependencies?

[Mark van der Loo]

>> Recommends: only gets installed, can be used via if(requireNamespace())
>> from the package and in pkg tests[1] [snip]
>> Build-Depends: gets installed before build, removed after.
>> Suggests: only installed when requested at install.packages() and only
>> used in examples/vignettes.

[snip]
>  I'd much rather
> have a way of declaring explicitly the different aspects of dependence
> on a package rather than bundling them up into cute labels,

Agreed

> but it's too late for that now.  However, we don't need to make things
worse.

Disagreed. We could follow the well-established practices of Debian (and
CRAN already does that, partially).


>> If 'tons of packages' are using if(requireNamespace) in their package
>> code there seems to be a need for something like this. [snip]

> I don't follow the argument here.  What problem are you solving?

Basically I'm trying to address the idea suggested by Thomas, who started
this conversation, and make it a bit more explicit. I felt that the
discussion went a little off-track there.

Right now, when package code (not examples) uses a suggested package, part
of that package will by default not work - at least that's how people use
it now. I would like it to work by default. For examples/vignettes you
could be more forgiving since running an example is not core functionality
of a package.

>> Perhaps more controversially a 'Breaks' field could be considered. [snip]

> This isn't controversial, it's just a bad idea.  Don't encourage people
> to break things.

Your reaction just proved my point about it being controversial. More
seriously, real progress is hardly ever possible without breaking things,
so I think at least people could have a serious discussion about it before
dismissing it simply as a bad idea. The Debian community obviously once
thought it was a good idea, so why not discuss it for R/CRAN? (discussions
are also an important way to progress even if no line of code is changed).
At the moment, I'm inclined against the idea, but I for one like to see me
proven wrong.


>> [1] actually, once we know a pkg is Recommended, the
>> 'if(requireNamespace)' could even be absorbed in the :: operator.

>I don't see how :: would be any different than it is now.  If you don't
>have foo available, and you try to use foo::bar(), what would happen
>other than an error?

I think you're right there. .

Best,
Mark


Op wo 3 aug. 2016 om 13:41 schreef Duncan Murdoch :

> On 03/08/2016 5:32 AM, Mark van der Loo wrote:
> >
> > After reading the link in Dirk's initial reply, how about adding fields
> > 'Recommends' and 'Build-Depends' to DESCRIPTION as in Debian?
> >
> > Recommends: only gets installed, can be used via if(requireNamespace())
> > from the package and in pkg tests[1]. [Debian: The Recommends field
> > should list packages that would be found together with this one in all
> > but unusual installations.]
> > Build-Depends: gets installed before build, removed after.
> > Suggests: only installed when requested at install.packages() and only
> > used in examples/vignettes.
>
> I think the distinction between Recommends and Suggests is too subtle
> here.  I already think it's a bad thing that we are using these words in
> ways that don't really correspond to English usage.  I'd much rather
> have a way of declaring explicitly the different aspects of dependence
> on a package rather than bundling them up into cute labels, but it's too
> late for that now.  However, we don't need to make things worse.
>
> >
> > If 'tons of packages' are using if(requireNamespace) in their package
> > code there seems to be a need for something like this. Compliance to the
> > above can be checked automatically and  a gradual implementation via
> > NOTE->WARNING->ERROR in R CMD check seems possible.
>
> I don't follow the argument here.  What problem are you solving?
>
> > Perhaps more controversially a 'Breaks' field could be considered. There
> > are a few packages out there that have many, many, dependencies.
> > Implementing breaking updates currently depends on the willingness of
> > many authors to update their package or convincing the CRAN maintainers
> > to allow for (temporary) breakage.
>
> This isn't controversial, it's just a bad idea.  Don't encourage people
> to break things.
>
> > The suggestion to have functions auto-install things is very
> > inconvenient for the good reasons pointed out by Thomas. Additionally,
> > it is often based on the wrong assumptions. Example: the RGtk2 package
> > 

Re: [R-pkg-devel] openMP/reduction statement causes build crash on travis-ci

[Mark van der Loo]

Thanks Dirk! that did it. I wasn't aware of the trusty 14.04 option.


Just adding

sudo: required
dist: trusty

at the top of my .travis.yaml solved it
https://docs.travis-ci.com/user/trusty-ci-environment/,


Cheers,
Mark



Op wo 3 aug. 2016 om 14:38 schreef Dirk Eddelbuettel :

>
> On 3 August 2016 at 08:13, Mark van der Loo wrote:
> | Dear pkg developers,
> |
> |
> | I'm working on a package using C code and openMP. The package builds and
> | tests fine on my own machine[1] and also on r-hub[2]. However on
> travis-ci
> | the build crashes[3] with the following message (plus a few similar):
> |
> | gower.c:297:29: error: expected ‘+’, ‘*’, ‘-’, ‘&’, ‘^’, ‘|’, ‘&&’, or
> ‘||’
> | before ‘min’
> |
> | The line in question is an #omp pragma statement:
> |
> |   #pragma omp for reduction(min:imin), reduction(max:imax)
> |
> |
> | I am using #pragma omp statements all over the place and this is the only
> | type causing crashes. I'm guessing it has something to do with travis
> | building on a 12.04 ubuntu VM with a rather old  gcc (4.6.3).
> |
> | So I have two questions:
> |
> | 1. Has anyone else seen this? Or am I missing something?
> | 2. Is there a workaround, or should I just go for another build service
> | (which one)?
>
> You can actually switch to 'Trusty' aka 14.04.
>
> That has been around for a bit, and AFAIK works with both the old scheme
> (ie
> r-travis) or the new scheme. [ I am partial to the old scheme which I now
> use
> via this fork http://eddelbuettel.github.io/r-travis/ -- and my drat and
> digest packages were the first to adopt it. ]
>
> We can take this off-line, but this should work.  I first used this when I
> needed g++-4.8 and I am pretty sure I have a .travis.yml somewhere using
> g++-4.9 because it was needed in one project.  "Yes we can."
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] Compiler choice on CRAN (R-windows-oldrel)

[Mark van der Loo]

Dear listers,


Compilation of my gower pkg fails on R-oldrel-windows. I am pretty sure
that this is because it uses gcc 4.6.3 which has limited support for OpenMP
(the errors are the same as I got on the old travis-ci build environment,
see my related question[1]).

Now, according to the Rtools page[2], since R3.2.2 "Both the gcc 4.6.3
toolchain and a toolchain based on gcc 4.9.3 and mingw-w64 v3 are now
included." Not sure what that says about CRAN, but I'm hoping/guessing it
uses Rtools the same way as we do.

So I guess I have the following options:

- make my package depend on R>=3.3
- Alter my code (as kindly suggested by Ott Toomet in [1])
- Tell CRAN to use the modern compiler.

Obviously, the latter would be easiest. Is this is even possible? For a
local installation I could set an environment variable[3], but how about
doing this at CRAN?

Thanks,
Mark


[1] https://stat.ethz.ch/pipermail/r-package-devel/2016q3/000983.html
[2] https://cran.r-project.org/bin/windows/Rtools/
[3]
https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation

[[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] Compiler choice on CRAN (R-windows-oldrel)

[Mark van der Loo]

Thank you Peter, good points.

Good to know for sure (or a.s.) that compiler specification at CRAN is not
an option. The 4th option is interesting as well. I may just do that.

Thanks again!
Mark









Op do 25 aug. 2016 om 12:17 schreef peter dalgaard :

> I don't have hard info on ABI compatibility between gcc versions, but
> there have been issues in the past, at least with with gfortran.
>
> Now, many people/schools will have R-3.2.x installed, built with gcc
> 4.6.y. We cannot retroactively recompile their installation, nor expect
> them to install a new version built with gcc 4.9.z. This raises a specific
> question and a generic one:
>
> - specific: Will a package binary of gower built with 4.9 work with R
> built with 4.6?
> - generic: Is is sufficiently likely that a given package if compiled with
> a different compiler version that CRAN would consider having a mechanism to
> specify a particular compiler version?
>
> I suspect that the answer to the second question is no.
>
> Whether to condition on R >= 3.3 is a good idea largely depends on two
> things
>
> - the user base (would they upgrade R anyways?)
> - are there other packages that depends on gower? (CRAN keeps only the
> newest version of a package so requiring a newer R could affect users with
> less aggressive update policies. This already happened when the pbkrtest
> package update rendered the car package unloadable.)
>
> You do have a 4th option: conditionalize the _code_ on the R version, then
> remove old-style code when 3.2.x becomes history.
>
> -pd
>
> On 25 Aug 2016, at 11:20 , Mark van der Loo 
> wrote:
>
> > Dear listers,
> >
> >
> > Compilation of my gower pkg fails on R-oldrel-windows. I am pretty sure
> > that this is because it uses gcc 4.6.3 which has limited support for
> OpenMP
> > (the errors are the same as I got on the old travis-ci build environment,
> > see my related question[1]).
> >
> > Now, according to the Rtools page[2], since R3.2.2 "Both the gcc 4.6.3
> > toolchain and a toolchain based on gcc 4.9.3 and mingw-w64 v3 are now
> > included." Not sure what that says about CRAN, but I'm hoping/guessing it
> > uses Rtools the same way as we do.
> >
> > So I guess I have the following options:
> >
> > - make my package depend on R>=3.3
> > - Alter my code (as kindly suggested by Ott Toomet in [1])
> > - Tell CRAN to use the modern compiler.
> >
> > Obviously, the latter would be easiest. Is this is even possible? For a
> > local installation I could set an environment variable[3], but how about
> > doing this at CRAN?
> >
> > Thanks,
> > Mark
> >
> >
> > [1] https://stat.ethz.ch/pipermail/r-package-devel/2016q3/000983.html
> > [2] https://cran.r-project.org/bin/windows/Rtools/
> > [3]
> >
> https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk  Priv: pda...@gmail.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] Compiler choice on CRAN (R-windows-oldrel)

[Mark van der Loo]

Thanks Uwe. Very clear.

I'll post the solution I chose, so people can find it later. The problem is
that GCC <= 4.6.3 (at least) does not implement OpenMP reduction statements.

So now I do something like this:

#ifdef _OPENMP
#include 
#endif

#ifdef __GNUC__
#if __GNUC__ <= 4 & __GNUC_MINOR__ <= 6
#else
#define HAS_REDUCTION
#endif
#endif

/* more code */

  #ifdef HAS_REDUCTION
  #pragma omp parallel for reduction(min:imin), reduction(max:imax)
  #endif
  for (int i=0; i:

>
>
> On 25.08.2016 13:14, Mark van der Loo wrote:
> > Thank you Peter, good points.
> >
> > Good to know for sure (or a.s.) that compiler specification at CRAN is
> not
> > an option. The 4th option is interesting as well. I may just do that.
> >
> > Thanks again!
> > Mark
>
> For Windows, indeed, you are tight to gcc 4.6.3 for R < 3.3.0 and to gcc
> 4.9.3 for R >= 3.3.0. If your package fails for gcc 4.6.3 we can live
> with it.
>
> Same for the other platform CRAN runs checks for, typically there is one
> compiler (as specified on the CRAN web pages).
>
> Best,
> Uwe Ligges
>
>
>
>
>
> >
> >
> >
> >
> >
> >
> >
> >
> > Op do 25 aug. 2016 om 12:17 schreef peter dalgaard :
> >
> >> I don't have hard info on ABI compatibility between gcc versions, but
> >> there have been issues in the past, at least with with gfortran.
> >>
> >> Now, many people/schools will have R-3.2.x installed, built with gcc
> >> 4.6.y. We cannot retroactively recompile their installation, nor expect
> >> them to install a new version built with gcc 4.9.z. This raises a
> specific
> >> question and a generic one:
> >>
> >> - specific: Will a package binary of gower built with 4.9 work with R
> >> built with 4.6?
> >> - generic: Is is sufficiently likely that a given package if compiled
> with
> >> a different compiler version that CRAN would consider having a
> mechanism to
> >> specify a particular compiler version?
> >>
> >> I suspect that the answer to the second question is no.
> >>
> >> Whether to condition on R >= 3.3 is a good idea largely depends on two
> >> things
> >>
> >> - the user base (would they upgrade R anyways?)
> >> - are there other packages that depends on gower? (CRAN keeps only the
> >> newest version of a package so requiring a newer R could affect users
> with
> >> less aggressive update policies. This already happened when the pbkrtest
> >> package update rendered the car package unloadable.)
> >>
> >> You do have a 4th option: conditionalize the _code_ on the R version,
> then
> >> remove old-style code when 3.2.x becomes history.
> >>
> >> -pd
> >>
> >> On 25 Aug 2016, at 11:20 , Mark van der Loo 
> >> wrote:
> >>
> >>> Dear listers,
> >>>
> >>>
> >>> Compilation of my gower pkg fails on R-oldrel-windows. I am pretty sure
> >>> that this is because it uses gcc 4.6.3 which has limited support for
> >> OpenMP
> >>> (the errors are the same as I got on the old travis-ci build
> environment,
> >>> see my related question[1]).
> >>>
> >>> Now, according to the Rtools page[2], since R3.2.2 "Both the gcc 4.6.3
> >>> toolchain and a toolchain based on gcc 4.9.3 and mingw-w64 v3 are now
> >>> included." Not sure what that says about CRAN, but I'm hoping/guessing
> it
> >>> uses Rtools the same way as we do.
> >>>
> >>> So I guess I have the following options:
> >>>
> >>> - make my package depend on R>=3.3
> >>> - Alter my code (as kindly suggested by Ott Toomet in [1])
> >>> - Tell CRAN to use the modern compiler.
> >>>
> >>> Obviously, the latter would be easiest. Is this is even possible? For a
> >>> local installation I could set an environment variable[3], but how
> about
> >>> doing this at CRAN?
> >>>
> >>> Thanks,
> >>> Mark
> >>>
> >>>
> >>> [1] https://stat.ethz.ch/pipermail/r-package-devel/2016q3/000983.html
> >>> [2] https://cran.r-project.org/bin/windows/Rtools/
> >>> [3]
> >>>
> >>
> https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation
> >>>
> >>>   [[alternative HTML version deleted]]
> >>>
> >>> __
> >>> R-package-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >> --
> >> Peter Dalgaard, Professor,
> >> Center for Statistics, Copenhagen Business School
> >> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> >> Phone: (+45)38153501
> >> Office: A 4.23
> >> Email: pd@cbs.dk  Priv: pda...@gmail.com
> >>
> >>
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > 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

Re: [R-pkg-devel] Delaporte: Test Errors on Sun Sparc

[Mark van der Loo]

Avraham,

I can't help you out directly but Jeroen Ooms has a VM image with Solaris &
R available: https://github.com/jeroenooms/solarisvm

best,
Mark



Op zo 5 feb. 2017 om 21:27 schreef Avraham Adler :

> I recently changed the back-end compiled code for the Delaporte
> package from C++ to Fortran/C, and after some birthing pains (and a
> lot of patience shown by CRAN), it's fully functional _except_ on
> sparc-sun-solaris2.10 [1]. There, 10 of the 44 tests return errors.
> I've done enough research to know that there may be endian issues
> involved, but I do not know how to address them.
>
> Interestingly, some of the errors look as if they are caused by
> returning the "ones-complement" (if that is a word, meaning returning
> 1 - x instead of x) in some cases. See tests 3, 4, 6, and 7 for
> examples. In the next version (which won't be posted to CRAN for at
> least a month 8-) ), I've expanded the number of tests from 44 to (at
> least) 86 to try to more cleanly isolate possible failures, but I
> don't have access to a sparc-based Sun server, nor is there one on
> Rhub and win-builder, so I cannot test it.
>
> Has anyone seen anything similar or does this ring any bells?
>
> Thank you,
>
> Avi
>
> [1] <
> https://www.r-project.org/nosvn/R.check/r-patched-solaris-sparc/Delaporte-00check.html
> >
>
> __
> 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

Re: [R-pkg-devel] UseR! Session: Making R easier to use (was: Navigating the jungle of R packages)

[Mark van der Loo]

Fwiw, there's also something called the awesome lists (
https://github.com/sindresorhus/awesome, and see the R list here:
https://github.com/qinwf/awesome-R), which is basically a kind of task
views for any language, and controlled via git pull requests.

Not sure if this would be a good alternative, but judging by the nr of gh
stars the awesome lists seem pretty popular.

Personally, I almost always use Google/Google scholar when I need
something. I use task views/awesome lists mainly when I get interested in
some field and want to have a quick browse to see what's there. Once in a
while I also need duckduckgo to escape the bubble.

-M

On Sun, Feb 12, 2017, 23:17 Spencer Graves <
spencer.gra...@effectivedefense.org> wrote:

>
> On 2017-02-11 7:39 AM, J C Nash wrote:
> > Certainly Google can be useful, but it can also be infuriatingly
> > time-wasting when one needs to sort out related tools that do slightly
> > different things. Then good, up-to-date task views are important, and
> > wrappers such as I and some others are trying to develop can be a way
> > to ease the chore of applying the tools or changing between related
> > ones where there isn't enough information on which is best.
> >
> > Perhaps Jim, Spencer, and I (others welcome!) can come up with some
> > small examples to show where Google / sos / other search tools and the
> > task views (Julia?) can be illustrated to provide guidance. After all,
> > the purpose of the UseR! session is to try to develop improved ways to
> > access R's packages.
>
>
>The sos vignette discusses searching for "Petal.Length" and
> "spline", combining different searches, and writing the result to an
> Excel workbook with sheets for a package summary, the individual help
> pages found, and documentation of the actual search.
>
>
>With luck, this session may catalyze the formation of a committee
> with a vision for how to improve what we have and the commitment to do it.
>
>
>Spencer
>
>
> p.s.  Someone complained that R was not a jungle.  I'm therefore
> proposing we consider changing the name of the session to something like
> "Making R easier to use".  John Nash thought the jungle analogy was
> good, because CRAN and a jungle are both resource rich but navigation poor.
>
> >
> > Cheers, John Nash
> >
> > On 2017-02-10 05:26 PM, Jim Lemon wrote:
> >> This discussion started me thinking about searching for a function or
> >> package, as many questions on the R help list indicate the that poster
> >> couldn't find (or hasn't searched for) what they want. I don't think I
> >> have ever used task views. If I haven't got a clue where to look for
> >> something, I use Google. I can't recall an occasion when I didn't get
> >> an answer, even if it was that what I wanted didn't exist. Perhaps we
> >> should ask why Google is so good at answering uninformed questions, in
> >> particular about R. I'm not the only person on the help list who
> >> advises the clueless to try Google.
> >>
> >> Jim
> >>
> >>
> >> On Sat, Feb 11, 2017 at 3:51 AM, Ben Bolker  wrote:
> >>>   I definitely read the task views and advise others to do so.  I
> >>> don't know how representative my little corner of the world is,
> >>> though.
> >>>
> >>>   I have an embryonic task view on mixed models at
> >>>
> https://github.com/bbolker/mixedmodels-misc/blob/master/MixedModels.ctv
> >>> but the perfect is the enemy of the good ...
>
>
>What do you think about converting the Task Views into a wiki?
>
>
>The Wikimedia rules do pretty well in inviting anyone to
> contribute material, quickly and easily deleting obvious vandalism,
> managing conflicts, and ensuring that the resulting articles are
> noteworthy and high quality -- and no one person has to be responsible
> for any specific thing.
>
>
>Spencer Graves
> >>>
> >>>
> >>> On Fri, Feb 10, 2017 at 9:56 AM, J C Nash 
> wrote:
>  We'd be more than happy to have you contribute directly. The goal
>  is not
>  just an
>  information session, but to get some movement to ways to make the
>  package
>  collection(s)
>  easier to use effectively. Note to selves: "effectively" is
>  important -- we
>  could make
>  things easy by only recommending a few packages.
> 
>  Best, JN
> 
> 
>  On 2017-02-10 09:29 AM, Michael Dewey wrote:
> >
> > Dear all
> >
> > That seems an interesting session. I am the maintainer of one of
> > the CRAN
> > Task Views (MetaAnalysis) and will attend
> > unless I am successful in the draw for Wimbledon tickets.
> >
> > Just in case I strike lucky one question I would have raised from the
> > floor if I were there would have been "Does anyone
> > read the Task Views?". Since I started mine I have received only a
> > couple
> > of suggestions for additions including a very
> > abrupt one about a package which had been included for months but
> > whose
> > author cle

Re: [R-pkg-devel] How do you discover and learn about R packages?

[Mark van der Loo]

Julia,

Just took the poll.

I think cranberries would deserve mention there as well. It is the only
continuous feed that reports in new pkgs and updates (that I know of).

Best,
Mark

On Mon, Mar 20, 2017, 14:57 Julia Silge  wrote:

> I am contributing to a session at userR 2017 this coming July that will
> focus on discovering and learning about R packages. This is an increasingly
> important issue for R users as we all decide which of the 10,000+ packages
> to invest time in understanding and then use in our work.
>
> To prepare for this session and gain some understanding, I am running an
> online survey about how R users currently discover and learn about R
> packages:
> http://doo.vote/a87ff60
>
> The question has one multiple select question about how you currently
> discover and learn about R packages. If you have other ways that you don’t
> feel were fairly covered in the survey options, feel free to reply to me or
> leave a comment here on my blog:
> http://juliasilge.com/blog/Package-Search/
>
> Thanks,
> Julia
>
> [[alternative HTML version deleted]]
>
> __
> 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

Re: [R-pkg-devel] Spell checking

[Mark van der Loo]

I had the same experience. Also recently I uploaded a pkg without a
vignette but with a vignette engine specified in the  DESCRIPTION. This
gave no error with R CMD check --as-cran (r-dev) but I did receive a
request to fix it.

-M

On Tue, Jun 20, 2017, 17:50 Thomas J. Leeper  wrote:

> I've now had two packages recently that had uncaught spelling errors
> (i.e., nothing on my local R CMD check --as-cran) that emerged only
> during CRAN submission. Is there a platform-specific component to the
> CRAN spellchecker or an option that must be specified explicitly to
> catch these?
>
> Thanks,
> -Thomas
>
> Thomas J. Leeper
>
> __
> 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

Re: [R-pkg-devel] problem with package_native_routine_registration_skeleton

[Mark van der Loo]

I have had no problems recently (having updated a pkg or two with this over
the last couple of weeks). Your question is not reproducible so its hard to
help...

best,
Mark

Op wo 21 jun. 2017 om 23:46 schreef Simon Barthelmé <
simon.barthe...@gipsa-lab.fr>:

> Dear list,
>
> Is anybody else having problems with
> tools::package_native_routine_registration_skeleton?
>
>  > tools::package_native_routine_registration_skeleton("~/Repos/imager")
>
> Error in native_routine_registration_db_from_ff_call_db(calls, dir,
> character_only) :
>no native symbols were extracted
>
> This used to work fine up until a few weeks ago, and I can't tell which
> update broke the function. Anybody else getting this?
>
> Many thanks, best
>
> Simon Barthelme
>
> __
> 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] Error on rhub/fedora not appearing on CRAN

[Mark van der Loo]

Dear list,


I'm getting some false 'R CMD check' positives on rhub / Fedora: errors
appearing on rhub that are not reproduced by CRAN. I have reported the
matter here:

https://github.com/r-hub/rhub/issues/92

It happens reproducibly for at least two of my packages: validate and
lumberjack (I haven't tested any other yet).

In short, knitr tries to open a png device while compiling a vignette and
fails as follows.

W checking re-building of vignette outputs
  Error in re-building vignettes: ...
Warning in (function (filename = "Rplot%03d.png", width = 480, height =
480, :
  unable to open connection to X11 display ''

It runs fine on R-devel, R-oldrel, R on windoze, solaris, centos, my own
machines,..., and also on CRAN so it seems tied to rhub/Fedora.

I have tried the following things already

- Check whether R is called with xvfb-run (to simulate the X11 environment)
in rhub's log. That's the case
- Set up a minimal package with several vignettes and knitr settings, but I
could not reproduce it minimally.

If anyone has similar experiences it'd be nice to hear about it. Either for
a workaround, or to gather some evidence that we can pass to Gabor, if it
indeed is an rhub issue.

Cheers,
Mark

[[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] Submitting a package to C-RAN

[Mark van der Loo]

I suggest you follow the link and check the notes..

On Sun, Sep 3, 2017, 1:06 PM Travers Ching  wrote:

> I am trying to submit a package to CRAN.  It did not pass the automated
> checks.  However, I don't understand what it is I am supposed to fix.
>
> I have run R CMD check ... -- as-cran and it seems to pass.  And I have
> also verified that it installs and works on ubuntu and windows.
>
> The message I get from the submission system is:
>
> Dear maintainer,
>
> package msgpack2R_0.1.tar.gz does not pass the incoming checks
> automatically, please see the pre-test at:
>  170903_030012_msgpack2R_01/00check.log>
> Status: 3 NOTEs
>
> It doesn't list any warnings or errors.
>
> [[alternative HTML version deleted]]
>
> __
> 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

Re: [R-pkg-devel] New Package Proposal: Feather with Matrix Notation ( [ , ] $ ) Access

[Mark van der Loo]

You could first have a look at the LaF packge. It does a lot of what you
want already.
-M

Op zo 17 sep. 2017 om 04:41 schreef Juan Telleria :

> Dear R Developers,
>
> I am writing as I would like to propose a github project for the creation
> of on-disk data.frames/tibbles.
>
> These new S3 class, could be based on feathers (which have a columnar
> structure for saving data), which would allow the use of matrix notation or
> $ symbols for individual column access, as if they where regular in-memory
> data.frames.
>
> The feather github project link is on the following page:
> https://github.com/wesm/feather
>
> SparkR Apache project, as I have been told in R-devel, offers a similar
> functionality, but the point is to extend it for feathers:
>
> https://spark.apache.org/docs/latest/sparkr.html
>
> Anyone would be interested in such project?
>
> Kind regards,
> Juan
>
> [[alternative HTML version deleted]]
>
> __
> 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

Re: [R-pkg-devel] Questions about third-party package distribution, especially with respect to security

[Mark van der Loo]

Dear Robert,

R supports package repositories out of the box. A repository is just a way
of organizing files. The most popular repositories are CRAN and
Bioconductor. There is even a package that allows you to set up your own
repository on Github (the drat package).

It depends on the repository maintainer if and how things are checked. My
experience is limited to CRAN, so I'll comment on that.

The main point of reference is the CRAN repository policy:
https://cran.r-project.org/web/packages/policies.html

Before a package is accepted, CRAN performs an extensive number of
automated checks, ranging from whether code is valid R, to running coded
examples and unit tests (if any). Also, some consistency between exported
functionality and documentation is enforced. When packages are submitted
the first time, there is also some manual checking regarding intellectual
property. Importantly, packages that are updated are not allowed to break
any package depending on them. This is checked as well.

For an introduction to CRAN it is also worth checking out Uwe Ligges'
keynote at this year's useR! conference.
https://channel9.msdn.com/Events/useR-international-R-User-conferences/useR-International-R-User-2017-Conference/KEYNOTE-20-years-of-CRAN


Best,
-M





Op zo 17 sep. 2017 om 21:56 schreef Robert Dodier :

> Hi, people other than the R developers can create packages which use R
> to do interesting things. I gather such packages are mostly
> distributed via CRAN, is that right? I am curious to know about the
> process for approving such packages.
>
> How much effort goes into reviewing and vetting packages? Is there any
> process for approving packages before publication? Have any security
> problems ever been encountered in third-party packages? Does the
> package distributor make any statements as to guarantees about
> security or the lack of them?
>
> The reason I ask these questions is that we are debating package
> distribution over in the Maxima project, and I would just like to
> check in and see what you have encountered and how it has been
> resolved. Thanks for any light you can shed on this topic.
>
> best,
>
> Robert Dodier
> Maxima project administrator and developer
>
> __
> 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

Re: [R-pkg-devel] CRAN policy on binary submission

[Mark van der Loo]

Dear Hugh, this question was asked earlier on this list:
http://r.789695.n4.nabble.com/executable-files-R-package-td4390488.html

See especially the answer of Duncan Murdoch.

Best,
Mark

Op di 9 jan. 2018 om 03:26 schreef Hugh Parsonage :

> On https://cran.r-project.org/ , it says
>
> > Note that we generally do not accept submissions of precompiled binaries
> due to security reasons
>
> I note it says 'generally', not 'always'. Are there any packages on
> CRAN which were submitted as precompiled binaries? Under what
> circumstances would CRAN accept binaries?
>
>
> 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

Re: [R-pkg-devel] Skipping tests on CRAN

[Mark van der Loo]

Hi Ott,

There is no documented way to detect whether you are running on CRAN. So
there is nothing to rely on, on that side.

You can only make your own machine detectable by the test code. For example
by setting an environment variable that identifies your machine and make
test execution depend on the value of that environment variable. This is
what tinytest does under the hood.

Best,
Mark





On Wed, Apr 21, 2021 at 7:17 AM Ott Toomet  wrote:

> Hi packagers,
>
> what is the best way to skip certain tests on CRAN?  So far I have included
> certain test files in .Rbuildignore and run the tests on the package
> directory.  But now when moving to Authors@R format, I get errors about
> missing maintainer etc.
>
> I know there are options in testthat, tinytest and such, are these the best
> options with least dependencies and assumptions built in?
>
> I sort of remember something in base R but cannot find anything when
> looking for it now.
>
> Cheers,
> Ott
>
> [[alternative HTML version deleted]]
>
> __
> 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

Re: [R-pkg-devel] library dlstats -> cran_stats()

[Mark van der Loo]

Knut

AFAIR the download statistics are limited to downloads from RStudio's cloud
service, so none of the other CRAN mirrors are included. I think there is
no separation between updates, re-installs, or installs done automatically
by CI-services, for example.


-Mark



Op vr 16 mrt. 2018 om 12:30 schreef Knut Krueger :

>
> Dear all,
>
> Does anybody know whether the statistics are counting also  updates?
> And if yes is it possible to get only the count of new installations?
>
> Kind regards Knut
>
>
> I
>
> __
> 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

Re: [R-pkg-devel] library dlstats -> cran_stats()

[Mark van der Loo]

unfortunately not.

In any case, it would depend on the willingness of each CRAN mirror
maintainer to record and publish such statistics.

-M

Op vr 16 mrt. 2018 om 16:57 schreef Knut Krueger :

> Am 16.03.2018 um 13:44 schrieb Spencer Graves:
> >
> >
> > On 2018-03-16 06:53, Mark van der Loo wrote:
> >> Knut
> >>
> >> AFAIR the download statistics are limited to downloads from RStudio's
> >> cloud
>
> are there any other statistics from cran available?
>
> Kind regards Knut
>
> __
> 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

Re: [R-pkg-devel] How to handle deprecated package dependency? 2 suggestions 1 question

[Mark van der Loo]

Dear Vincent,

I think this is little known, but you can get the CRAN result status of any
package from R, see tools::CRAN_check_results().

Best,
Mark


Op ma 25 jun. 2018 om 22:13 schreef Duncan Murdoch :

> On 25/06/2018 3:21 PM, Vincent van Hees wrote:
> > Dear all,
> >
> > One of my package dependencies was taken from CRAN a month ago, with
> > the CRAN message: "...check problems were not corrected despite
> > reminders" as displayed on the deprecated CRAN package page. I
> > immediately got in touch with the deprecated package maintainer and
> > learnt that he is trying to resolve the issue(s).
> >
> > My suggestions/questions:
> >
> > 1 - Would it be an idea for CRAN to inform reverse dependency package
> > maintainers when a package is at risk of being taken from CRAN? For
> > example, by cc-ing them in the warning message? I think such a
> > heads-up could have helped to prevent the situation.
> >
> > 2 - At the moment the CRAN page for the deprecated package does not
> > tell me what I can do to help fix the issue:
> >
> > "Package ‘GENEAread’ was removed from the CRAN repository.
> > Formerly available versions can be obtained from the archive.
> > Archived on 2018-05-25 as check problems were not corrected despite
> reminders >
> > Would it be an idea to display what those problems were to make it
> > easier for others, like me, to help fix the issue(s)?
>
> I don't know if it will remain indefinitely, but the CRAN check page for
> that package is still available, containing MacOS results:
>
> https://cran.r-project.org/web/checks/check_results_GENEAread.html
>
> It looks as though the required changes are quite trivial:  using
> requireNamespace instead of require() or library(), and declaring
> imports from base packages.
>
> >
> > 3 - Can you advise on how I can help address the situation, such that
> > I can upload a much needed update to my own CRAN package GGIR? The
> > approaches I can think of are: (A) Help the deprecated package
> > maintainer to fix their issues, which may not be easy, (B) copy the
> > old code of the deprecated package and create an entirely new but
> > fixed CRAN package from it myself stripped to only the functionality I
> > need, which is not ideal of course, or (C) Kindly ask CRAN to put the
> > deprecated package back online for a couple of months while we look
> > out for a better solution?
>
> Given how easy the fixes are, I'd go with (A).
>
> Duncan Murdoch
> >
> > Thanks,
> > Vincent
> >
> > __
> > 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
>

[[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] Questions about making a database package (Rpolyhedra)

[Mark van der Loo]

Hi Alejandro,

Brooke Anderson gave a nice talk at useR!2017 addressing this exact issue.
See
https://schd.ws/hosted_files/user2017/19/anderson-eddelbuettel-use_r_talk.pdf
for
the slides. The basic idea is to use an external CRAN-like repository for
the data back-end. Brooke used 'drat' to set up such a repo.

-Mark



Op do 28 jun. 2018 om 13:56 schreef alejandro baranek <
alejandrobara...@gmail.com>:

> Hi Joris:
>
> Thank you for your comments.
> Of course, we are using https for aditional downloads.
>
> For the moment it is not needed to use github LFS, but is an alternative we
> can explore after this short step: our immediate goal is to make the
> package lighter in CRAN. Now it's 35kb so I think we made it well.
>
> We are defining an XSD for exporting polyhedra in XML. After that, it will
> be possible to make an API with the polyhedra database and make the
> improvement you are saying. But with time, we have no funding yet for this
> project and want to implement some functionalities to make it more valuable
> first. But is in our roadmap to make it easy to port it to other languages.
> The interface we are using is really simple, probably it will be the API
> interface too.
>
> Best, Ale.
>
>
> 2018-06-28 5:23 GMT-03:00 Joris Meys :
>
> > Hi Ale,
> >
> > I'd personally use a more specific solution like github LFS (large file
> > storage) for a versioned database. You should also check with CRAN
> itself,
> > as they keep high standards for everything that's not a standard install.
> > More specifically (from CRAN policies) :
> >
> > Downloads of additional software or data as part of package installation
> > or startup should only use secure download mechanisms (e.g., ‘https’ or
> > ‘ftps’).
> >
> > Personally I would store that information in a public database somewhere
> > with a (minimal) API. This can then be extended without inflating the
> > download and would allow people to install only a subset of what they
> need.
> > That would also allow people to also port your work to other language by
> > simply writing a wrapper around the DB API. It's not a necessity, but I
> > thought it was worth mentioning as an option.
> >
> > Cheers
> > Joris
> >
> > On Wed, Jun 27, 2018 at 10:22 PM, alejandro baranek <
> > alejandrobara...@gmail.com> wrote:
> >
> >> By now, we are on that situation: +- 150 polyhedra published.
> >> But +800 able to publish and because of package size cannot publish all
> of
> >> them.
> >>
> >> It is not a problem on github, it's a problem on CRAN, with building
> >> (fixed
> >> testing timing with simple sample techniques) timing. I would like to
> hear
> >> more from experienced package developers about this issues, but we
> seemed
> >> to found a solution.
> >>
> >> We decided to make another github repo RpolyhedraDB. When you install
> the
> >> package, it downloads the database from the correct tag marked in the
> data
> >> folder of the package in a home directory of the user. So package will
> be
> >> minimal for CRAN, will be RR and will install database on first use (In
> >> case of TRAVIS or other qa/continuous integration, it will install it of
> >> course). It will be possible to setup different DB size using the TAGS,
> in
> >> case we find it preferable to the users.
> >>
> >>
> >> Best, Ale.
> >>
> >>
> >> 2018-03-29 4:43 GMT-03:00 Berry Boessenkool <
> berryboessenk...@hotmail.com
> >> >:
> >>
> >> >
> >> > I assume you cannot simply reduce the 150 to a few for demonstration
> >> > purposes?
> >> >
> >> >
> >> > I have seen people using DRAT packages on github for data, but gh is
> >> > limited in size restrictions as well...
> >> >
> >> >
> >> > No expert in this, but maybe this helps a little bit...
> >> >
> >> > Berry
> >> >
> >> >
> >> >
> >> > -
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > *From:* R-package-devel  on
> >> behalf
> >> > of alejandro baranek 
> >> > *Sent:* Tuesday, March 27, 2018 19:26
> >> > *To:* r-package-devel@r-project.org
> >> > *Subject:* [R-pkg-devel] Questions about making a database package
> >>
> >> > (Rpolyhedra)
> >> >
> >> > Hello group:
> >> >
> >> > We released Rpolyhedra V0.2 last month. It is able to scrape +800
> >> polyhedra
> >> > definitions from public sources. At V0.2.4 we are publishing only 150
> >> > because the time needed for scrape all the polyhedra, testing and the
> >> > resulting size of the package. The difference is a configuration in
> >> zzz.R,
> >> > very simple to change (Who wants to try it, can build the package for
> >> > themeselves)
> >> > Only the source files of polyhedra definitions are +12MB of size (We
> are
> >> > including it in the data folder for package self suficience).
> >> >
> >> > But we have doubts about good practices for publishing a database
> >> package.
> >> >
> >> > We think the solution is to split the package in an internal
> >> > Rpolyhedra-lib, opensource but not in CRAN, and Rpolyhedra with a
> >> catalog
> >> > sewhich enables to con

Re: [R-pkg-devel] Package builds, installs, and runs but does not pass devtools::check()

[Mark van der Loo]

Michael,

Just a small side-track here. I would avoid using the not-a-pipe operator
within functions or packages in general. It is great for interactive use,
but it does make debugging and hence long-term maintenance of functions
harder. There are two reasons for this. First, it hides intermediate
results, and second, it adds several layers to the call stack making the
output of functions like traceback() harder to interpret. I have documented
a simple example here: https://github.com/chriscardillo/norris/issues/1 (scroll
down a bit).

Regarding learning about quosures and so on. If the literal names of data
frames are known, you could consider replacing

some_var <-   next_data_frame %>% dplyr::select(-amount,...

with something simpler like

some_var <- next_data_frame[ names(next_data_frame) != c("amount", ... ) ]

which might also save you some dependencies.




Hope this helps,
Best,
Mark



Op di 17 jul. 2018 om 11:28 schreef Michael Hannon <
jmhannon.ucda...@gmail.com>:

> Thanks to John and Zhian for their recent and informative comments.
>
> Regarding check() and NSE: the moral seems to be that a little
> learning is a dangerous thing.  I'm off to try to bring quosure to
> this issue.
>
> -- Mike
>
>
> On Mon, Jul 16, 2018 at 2:38 PM, Zhian Kamvar  wrote:
> > Using dplyr like that is for exploratory data analysis. You'll want to
> refer
> > to dplyr's "Programming with dplyr" vignette for using dplyr in a
> package:
> >
> > https://cran.r-project.org/web/packages/dplyr/vignettes/programming.html
> >
> > Hope that helps.
> >
> > On Jul 16, 2018, at 22:13 , Michael Hannon 
> > wrote:
> >
> > Thanks, Georgi.  I've changed my approach and now do what I gather is
> > recommended practice: put all external package names into the
> > "Imports" section of the DESCRIPTION file and then use the
> > fully-qualified names for functions from those packages, as:
> >
> >dplyr::select()
> >
> > The "check" operation is still not entirely "happy" with me, but it
> > doesn't flag any errors, and the package builds and runs.
> >
> > BTW, one source of "complaints" from "check()" is evidently the use of
> > NSE in the tidyverse functions.  For instance, the line:
> >
> >next_data_frame %>% dplyr::select(-amount,
> >
> > generates the message:
> >
> >standardize_format: no visible binding for global variable ‘amount’
> >
> > where, of course, "amount" is one of the column headings in
> > "next_data_frame".  There seems to be no harm done by this, and I plan
> > to ignore such messages, but if there's some additional wisdom that
> > applies here, I'd be happy to receive it.
> >
> > -- Mike
> >
> >
> > On Sun, Jul 15, 2018 at 12:05 AM, Georgi Boshnakov
> >  wrote:
> >
> >
> > It seems that the R session used by 'check' doesn't look in the library
> used
> > by your interactive session. This discrepancy may happen since the check
> > tools do not load the same Renviron files as interactive sessions. This
> may
> > result in different libraries in interactive and 'check' sessions. See
> > ?Startup, especially section Note.
> > It is difficult to give more specific advice without details of your
> setup.
> >
> >
> > Hope this helps,
> > Georgi Boshnakov
> >
> >
> > 
> > From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf
> of
> > Michael Hannon [jmhannon.ucda...@gmail.com]
> > Sent: 15 July 2018 02:13
> > To: r-package-devel@r-project.org
> > Subject: [R-pkg-devel] Package builds, installs, and runs but does not
> pass
> > devtools::check()
> >
> > Greetings.  I'm working on a small package, and I'm using the devtools
> > functions to create, build, etc., the package.
> >
> > As indicated in the subject line, I get no errors when I do:
> >
> > build()
> > install()
> >
> >
> > When I run a separate R session and load the package, i.e.,
> >
> > library(my_pkg)
> >
> >
> > the package loads without error, and the two exported functions appear
> > to work as advertised.
> >
> > OTOH, if I include devtools::check() in the construction of the
> > package, I consistently get an error:
> >
> >* installing *source* package ‘my_pkg’ ...
> >** R
> >** preparing package for lazy loading
> >Error in loadNamespace(from, lib.loc = .library) :
> >  there is no package called ‘dplyr’
> >Error : unable to load R code in package 'my_pkg'
> >
> > Clearly there *is* a package called "dplyr" on my system (see the
> > session info below, for instance).  And, as I've mentioned, the code
> > *does* run, and I can watch it successfully reading CSV files.
> >
> > Here's the relevant part of my DESCRIPTION file:
> >
> >Depends: R (>= 3.4.4)
> >Imports: readr,
> >dplyr,
> >ggplot2,
> >purrr,
> >magrittr
> >
> > I suspect the problem may be that I'm misunderstanding something about
> > the `import::from()` function, which I'm using for the first time to
> > load required functions into my code.  In eac

Re: [R-pkg-devel] Package builds, installs, and runs but does not pass devtools::check()

[Mark van der Loo]

t or cannot implement,
or it can have something to do with performance for example. This does
indeed exclude much of the tidyverse almost automatically. Many tools in
tidyverse make already existing functionality easier for (interactive) use.
But since much of the functionality is already present in base R, and
because I find NSE hard to reason about in a programming context I have
until now not used any tidyverse packages as an Imports or Depends.


Hope this helps,
Best,
Mark














Op di 17 jul. 2018 om 23:10 schreef Michael Hannon <
jmhannon.ucda...@gmail.com>:

> Thanks, Mark.  Your points are well-taken, but I wouldn't refer to
> this as a "small side-track".  You don't say so, but this could be
> interpreted as a recommendation to avoid some or all of the
> "tidyverse" in developing packages.  I'm actually quite comfortable
> doing the base-R-style programming you recommend.  I've lately being
> trying to make a point of using the "tidy" stuff, as that's what I'm
> seeing almost exclusively from folks in my neighborhood these days.
> ("Resistance is few-tile...")
>
> Also, it would seem to be a corollary that if the ultimate goal is to
> make a package, then one shouldn't be using the convenience stuff
> (pipes, dplyr, etc., etc.), even during the development stages.  Can
> you comment?  Thanks.
>
> -- Mike
>
>
> On Tue, Jul 17, 2018 at 2:53 AM, Mark van der Loo
>  wrote:
> > Michael,
> >
> > Just a small side-track here. I would avoid using the not-a-pipe operator
> > within functions or packages in general. It is great for interactive use,
> > but it does make debugging and hence long-term maintenance of functions
> > harder. There are two reasons for this. First, it hides intermediate
> > results, and second, it adds several layers to the call stack making the
> > output of functions like traceback() harder to interpret. I have
> documented
> > a simple example here: https://github.com/chriscardillo/norris/issues/1
> > (scroll down a bit).
> >
> > Regarding learning about quosures and so on. If the literal names of data
> > frames are known, you could consider replacing
> >
> > some_var <-   next_data_frame %>% dplyr::select(-amount,...
> >
> > with something simpler like
> >
> > some_var <- next_data_frame[ names(next_data_frame) != c("amount", ... )
> ]
> >
> > which might also save you some dependencies.
> >
> >
> >
> >
> > Hope this helps,
> > Best,
> > Mark
> >
> >
> >
> > Op di 17 jul. 2018 om 11:28 schreef Michael Hannon
> > :
> >>
> >> Thanks to John and Zhian for their recent and informative comments.
> >>
> >> Regarding check() and NSE: the moral seems to be that a little
> >> learning is a dangerous thing.  I'm off to try to bring quosure to
> >> this issue.
> >>
> >> -- Mike
> >>
> >>
> >> On Mon, Jul 16, 2018 at 2:38 PM, Zhian Kamvar 
> wrote:
> >> > Using dplyr like that is for exploratory data analysis. You'll want to
> >> > refer
> >> > to dplyr's "Programming with dplyr" vignette for using dplyr in a
> >> > package:
> >> >
> >> >
> https://cran.r-project.org/web/packages/dplyr/vignettes/programming.html
> >> >
> >> > Hope that helps.
> >> >
> >> > On Jul 16, 2018, at 22:13 , Michael Hannon <
> jmhannon.ucda...@gmail.com>
> >> > wrote:
> >> >
> >> > Thanks, Georgi.  I've changed my approach and now do what I gather is
> >> > recommended practice: put all external package names into the
> >> > "Imports" section of the DESCRIPTION file and then use the
> >> > fully-qualified names for functions from those packages, as:
> >> >
> >> >dplyr::select()
> >> >
> >> > The "check" operation is still not entirely "happy" with me, but it
> >> > doesn't flag any errors, and the package builds and runs.
> >> >
> >> > BTW, one source of "complaints" from "check()" is evidently the use of
> >> > NSE in the tidyverse functions.  For instance, the line:
> >> >
> >> >next_data_frame %>% dplyr::select(-amount,
> >> >
> >> > generates the message:
> >> >
> >> >standardize_format: no visible binding for global variable ‘amount’
> >> >
> >> > where, of 

Re: [R-pkg-devel] Submitting CORELS (Certifiably Optimal Rule Lists) package with/without Windows support

[Mark van der Loo]

Dear Aditya,

You ask:

|  Am I able to submit this without Windows support, or could somebody help
us with supporting Windows?

The CRAN policy[1] is pretty clear about this:

"Package authors should make all reasonable efforts to provide
cross-platform portable code. Packages will not normally be accepted that
do not run on at least two of the major R platforms."

and also

"It should be normal for those without Windows machines of their own to use
the winbuilder service to check a package before submission. "


Best wishes,
Mark
[1] https://cran.r-project.org/web/packages/policies.html

On Thu, Dec 20, 2018 at 2:07 PM Ralf Stubner 
wrote:

> On 20.12.18 13:52, Aditya Saligrama wrote:
> > I was able to get the package to compile on Windows by emulating the way
> > the sbrl package builds in Windows support. However, when I try to run
> > the package on Windows, R completely crashes and exits to the desktop.
> >
> > Would you have any suggestions on how to debug or fix this?
>
> Start R from a command prompt. This way you might catch the error
> message when R exits. Alternatively you could run R (or Rgui) in the gdb
> debugger:
>
> cmd> gdb.exe Rgui.exe
> gdb> run
> R> ...
>
> See http://sourceware.org/gdb/current/onlinedocs/gdb/ for more info on
> gdb.
>
> Greetings
> Ralf
>
>
> --
> Ralf Stubner
> Senior Software Engineer / Trainer
>
> daqana GmbH
> Dortustraße 48
> 14467 Potsdam
>
> T: +49 331 23 61 93 11
> F: +49 331 23 61 93 90
> M: +49 162 20 91 196
> Mail: ralf.stub...@daqana.com
>
> Sitz: Potsdam
> Register: AG Potsdam HRB 27966
> Ust.-IdNr.: DE300072622
> Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze
>
> __
> 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

Re: [R-pkg-devel] CRAN student assistants

[Mark van der Loo]

For what it's worth,

I recently submitted a new package that was initially refused (with
comments) by CRAN. I updated number of them accordingly, but there were a
few that with good reasons I could not change. I explained this in the
comments when uploading a new version and it got accepted. So I don't see
the problem.

(The case here was a use of \dontrun{}. I had to switch an example off
because a warning was thrown which would upset R CMD check. But
demonstrating the warning was exactly the point of the example.)

All this aside. I think it is extremely unethical to publish privately sent
CRAN emails on GH, including personal details such as name and e-mail
address of the sender without their explicit consent.


Best,
Mark





On Wed, May 15, 2019 at 4:44 PM Jennifer Bryan 
wrote:

> Hello,
>
> Since this has turned into a worldwide code review, I will briefly address
> that, then reiterate the point of the original message.
>
> I am working on an initial release of a package. It reveals information to
> a user, sometimes in a print method-y way, sometimes in more of a verbose /
> debugging way that is under control of a documented option, which defaults
> to "off" or "quiet". For now, I have chosen to send all of this output
> through a single functions that, yes, uses cat(). I went this direction for
> an initial release to keep the package simple and accumulate some user
> experience. If the "debugging mode" proves to be useful, I will rework it,
> possibly using UI functionality that I believe our group might release in
> the future. Rest assured, I understand cat() vs message() and the various
> tradeoffs. I made mine and it is my impression that package maintainers
> have this level of freedom.
>
> The real point is: the currenrt CRAN submission process is designed for
> one-way communication and there's no guarantee of continuity of reviewer.
> If this type of implementation review is going to happen, it seems that
> many aspects of the process would need to change, to make sure these new
> standards are applied consistently to every submission and that existing
> package are brought up to current standards.
>
> To clarify something for Joris, I am not aware of any special channel of
> communication or influence between CRAN and the R Foundation (of which I am
> also a member). I think this is an aspect of CRAN vs R Foundation (vs R
> Core even) that is unclear to many. These entities operate quite
> independently, except for the fact that specific people belong to more than
> one. So RF members interact with CRAN the same way as any other of member
> of the community.
>
> -- Jenny
>
> On Wed, May 15, 2019 at 6:43 AM Jim Hester 
> wrote:
>
> > Sorry first sentence should read
> >
> > I agree that `message()` is ideally preferred, precisely because
> > of the reasons Martin stated, it is easily controlled by the user.
> >
> > On Wed, May 15, 2019 at 9:41 AM Jim Hester 
> > wrote:
> > >
> > > I agree that `message()` is in an ideally preferred, precisely because
> > > of the reasons Martin stated, it is easily controlled by the user.
> > >
> > > Unfortunately, in the real world, the windows R gui console and
> > > RStudio (which copied behavior) color messages, and anything on stderr
> > > in fact, in red, which confuses most users who are trained to treat
> > > messages in red as errors.
> > >
> > > This also makes using colored output (where available) more
> > > challenging when using `message()`.  You either have to accept the
> > > text as red, or unconditionally change the text color to black or
> > > similar, which can then be unreadable if the user is using a dark
> > > color theme.
> > >
> > > Jenny is an experienced package developer. She knew this tradeoff and
> > > the use of `cat()` in gargle was deliberate choice in an imperfect
> > > world. She did not make this decision out of ignorance of a better
> > > way.
> > >
> > > However there is no way for Jenny or any other package developers to
> > > have a dialog during a CRAN submission, the communication is only in
> > > one direction, if she resubmits explaining her rationale for the
> > > choice she may not even have the same reviewer the next time.
> > >
> > > Bioconductor seems to have a much better review process for
> > > submissions, with real dialog between the reviewer and package author,
> > > perhaps CRAN can learn from that process and improve the submission
> > > experience in the future.
> > >
> > > Jim
> > >
> > > On Wed, May 15, 2019 at 7:41 AM Martin Morgan  >
> > wrote:
> > > >
> > > > message() / warning() / stop() write to stderr whereas print() /
> cat()
> > write (by default) to stdout. Even without being able to suppress
> messages,
> > it is well-established practice (the story is that this is the reason why
> > 'stderr' was introduced into unix,
> >
> https://www.jstorimer.com/blogs/workingwithcode/7766119-when-to-use-stderr-instead-of-stdout
> > ) to separate diagnostic messages from program output. I agree 

Re: [R-pkg-devel] General considerations about vignettes

[Mark van der Loo]

At the cost of some level of reproducibility, you could use a static
vignette and be very clear about the package versions used in the
comparisons:
http://www.markvanderloo.eu/yaRb/2019/01/11/add-a-static-pdf-vignette-to-an-r-package/

As this does diminish the coherence of CRAN somewhat I'm not really
favoring it, but I can see cases where this may be useful (e.g. I use a
static vignette in one pkg to include a published paper).

-Mark

On Fri, Aug 30, 2019 at 5:00 PM Michael Dewey 
wrote:

> Comments in-line
>
> On 30/08/2019 14:59, Iñaki Ucar wrote:
> > On Fri, 30 Aug 2019 at 15:26, J C Nash  wrote:
> >>
> >> I'm seeking some general advice about including vignettes in my
> packages,
> >> which are largely for nonlinear estimation and function minimization
> (optimization).
> >> This means that my packages offer alternatives to many other tools, and
> the user
> >> then has the chore of deciding which is appropriate. Bad choices can be
> very
> >> costly in inappropriate results or computational efficiencies. Hence, I
> include
> >> vignettes to offer comparisons and examples of use.
> >>
> >> Unfortunately, as in a case this week, changes in the comparison
> packages break
> >> my package(s), and I get an email from CRAN telling me to fix it before
> some
> >> date not far in the future. This means a) work for me, possibly at an
> inopportune
> >> time; b) risk of loss of capability, in the present case in the nlsr
> package which
> >> offers some unique capabilities, and c) extra work for CRAN for what
> is, arguably,
> >> updating of peripheral documentation. Updating optimization packages on
> CRAN can be,
> >> I have discovered, a very time-consuming task. Package optimx took over
> 3 months
> >> to get updated.
> >>
> >> It should be noted in the present situation that just before I got the
> msg from
> >> CRAN I got a msg from the maintainer of the package that has changed
> and breaks
> >> the vignette with some suggestions on a fix. The issue is that his
> package has
> >> changed function syntax -- a situation all of us know is fraught with
> troubles,
> >> since improvements may cause breakage.
> >>
> >> I am NOT saying that my vignettes should not be updated. However, I'm
> wondering
> >> if I should set up a repository for my vignettes on Github/Gitlab or
> similar, and
> >> simply link to them. This would separate the updating of vignettes from
> the central
> >> packages. Their updating could be less strictly tied to CRAN
> activities, and could
> >> also be a task undertaken by others who are not listed as maintainer.
> >>
> >> I'd welcome some (hopefully constructive) comments. Would CRAN
> maintainers feel
> >> this to be helpful, or does it lower the value of official R packages?
> Do
> >> other maintainers experience the same requests, or do they just not
> include
> >> vignettes (and many do not)?
> >
> > My two cents:
> >
> > For me, as a user, vignettes are the most valuable form of
> > documentation in a package. Of course, this is personal opinion.
>
> Yes, but it is widely shared (in the sense that I think it too).
>
> I think the issue here is whether the intention is to compare with a
> particular implementation of a technique in which case you probably do
> need to do what you are currently doing or to compare with the technique
> in general terms. If the latter then Iñaki's solution seems perfect to
> me since even if the package interface changes it still implemented the
> same technique (I assume).
>
> Michael
>
>   But
> > these days with so many good packages out there, I don't have time to
> > install all of them and dive into the manual and the examples just to
> > decide which one is better for my use case. A good written vignette
> > most of the time is my driving factor (sometimes, if it's a small
> > package with one particular functionality, a good README is enough,
> > but that's not the case here).
> >
> > Thus, as a maintainer, I try to lead by example. It's time consuming,
> > but on the other hand, many times a help request by a user can be
> > resolved with "please, take a look at section x of vignette y".
> >
> > One thing I do to make them as maintainable as possible is to try to
> > avoid dependencies on third-party packages as much as possible. In
> > your case, comparing yourself with other alternatives may be
> > important. I'd suggest to set eval=FALSE for chunks with expensive
> > demonstrations of other packages, and then show a static figure with
> > the comparison that you made once, but doesn't need to be recreated
> > each time the vignette is built. In this way, issues like the one you
> > described won't affect your package, at least immediately. Until some
> > user reaches you to say, hey, I've tried the code in this vignette for
> > package x and it doesn't work for me. Then it's time to revisit that
> > code and rebuild the figure.
> >
> > You could have vignettes that you don't rebuild constantly in a
> > separate repo and link them from 

Re: [R-pkg-devel] CRAN policies with regards to runnable examples

[Mark van der Loo]

My experience is somewhat similar to that of Hong Ooi.

An initial submission got refused. During resubmission I explained the
necessity of \dontrun{} in certain cases and it was accepted. So the basic
policy here is 'comply or explain'.

>From now on, when I need to place a \dontrun{} anywhere, I will at initial
submission already use the 'Optional Comment' box to document why each
\dontrun{} is necessary. Based on my earlier experiences, this seems
reasonable and also the fastest way to publication.

Best,
Mark







On Wed, Oct 2, 2019 at 5:31 AM Hong Ooi via R-package-devel <
r-package-devel@r-project.org> wrote:

> Hm, up to now my AzureR packages haven't met with any issues, and they are
> basically API wrappers.
>
> I did have one reviewer ask for runnable examples when I submitted one
> package, but replying and pointing out the issues you mention cleared
> things up. I did cc Uwe Ligges in the reply, who approved the other
> packages in the first place -- the other reviewer probably just wasn't
> aware that I'd cleared things with Uwe previously.
>
>
> -Original Message-
> From: R-package-devel  On Behalf
> Of Jim Hester
> Sent: Wednesday, 2 October 2019 3:37 AM
> To: R Package Development 
> Subject: [R-pkg-devel] CRAN policies with regards to runnable examples
>
> CRAN reviewers have somewhat recently been requesting that new submissions
> have runnable examples. This is in general a good recommendation, but the
> reviewers seem to apply this policy unconditionally, and there are certain
> classes of packages where this is either extremely cumbersome or impossible
> to do.
>
> Two in particular are packages which wrap web APIs and packages containing
> shiny applications. Even the most robust APIs will inevitably have network
> failures, causing spurious failures on CRAN's machines, and often the APIs
> require credentials to access, which won't be available on the build
> machines. Shiny applications block the R process and require user
> interaction in a browser to function, they cannot really be run
> non-interactively.
>
> In these cases it seems appropriate to put examples in a `\dontrun{}` or
> `\donttest{}` block, and this is what is suggested by writing R extensions.
> However CRAN reviewers have refused to accept packages taking this approach.
>
> If these workarounds are not acceptable what _does_ CRAN want package
> authors to do in these cases?
>
> Jim
>
> __
> R-package-devel@r-project.org mailing list
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=02%7C01%7Chongooi%40microsoft.com%7C1ac67369474848bf7cdc08d746960dd9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637055482613833043&sdata=quC7BH5vtm3I7dWq%2Fhi6FtN54DxrUzO0Z1K9TRc%2FE3c%3D&reserved=0
>
> __
> 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

Re: [R-pkg-devel] License of pre-built vignettes

[Mark van der Loo]

Adding a static PDF vignette is very easy. I have written about it here:
http://www.markvanderloo.eu/yaRb/2019/01/11/add-a-static-pdf-vignette-to-an-r-package/

Best,
Mark

Op vr 25 okt. 2019 13:22 schreef Berry Boessenkool <
berryboessenk...@hotmail.com>:

>
> You could also consider a static vignette withh R.rsp:
>
> https://cran.r-project.org/web/packages/R.rsp/vignettes/R_packages-Static_PDF_and_HTML_vignettes.pdf
>
> Berry
>
>
> 
>
> > The vignettes contain code for simulations which causes the long
> > runtime. In examples of the man-pages we have -- much simpler ones -- in
> > \donttest{}. I think that one of the purposes of vignettes is to give
> > the user a more exhaustive description what can be done with certain
> > functions. The only way out would to have instead of the R-code plain
> > text. Runtimes close to zero but all -- rather useful -- formats lost.
> >
> > We will try to keep them and start a discussion with the team.
> >
> > Helmut
> >
>
>
> [[alternative HTML version deleted]]
>
> __
> 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

Re: [R-pkg-devel] Fwd: CRAN submission radsafer 2.1.0

[Mark van der Loo]

I am not sure which 'check result page' you mean, but presumably you mean
this one: https://cran.r-project.org/web/checks/check_results_radsafer.html

The e-mail you got asks you to confirm that you are the author of the
submitted package. After confirmation (and checking the boxes on the
confirmation page) the package will be staged for build and check at CRAN.
Once your package passes this stage, it is released on CRAN. After that it
takes some days before your package has been built and checked at the
different architectures listed on the CRAN check results page.


HTH,
Mark

On Wed, Dec 18, 2019 at 12:23 AM Mark Hogue 
wrote:

> This package is ready to submit, except I am concerned about one thing. The
> package version listed on the check result page is 2.0.1, whereas this
> version is 2.1.0. Should I go ahead and submit it, or is there some problem
> I need to fix?
>
>
> -- Forwarded message -
> From: Package Submission 
> Date: Tue, Dec 17, 2019 at 5:55 PM
> Subject: CRAN submission radsafer 2.1.0
> To: Mark Hogue 
>
>
> Dear Mark Hogue
> Someone has submitted the package radsafer to CRAN.
> You are receiving this email to confirm the submission as the maintainer of
> this package.
> To confirm the submission to CRAN, follow or copy & paste the following
> link into your browser:
>
>
> https://xmpalantir.wu.ac.at/cransubmit/conf_mail.php?code=c9a3cccd75150cf5bf6235645d8bee6b
>
> If you did not submit the package or do not wish for it to be submitted to
> CRAN, simply ignore this email
>
> Submission Information:
> Submitter: Mark Hogue 
> Package: radsafer
> Version: 2.1.0
> Title: Radiation Safety
> Author(s): Mark Hogue 
> Maintainer: Mark Hogue 
> Depends: R (>= 3.5.0)
> Suggests: testthat, scatterplot3d, beepr, knitr, rmarkdown
> Description: Provides functions for radiation safety, also known as
>   "radiation protection" and "radiological control". The
>   science of radiation protection is called "health physics"
>   and its engineering functions are called "radiological
>   engineering". Functions in this package cover many of the
>   computations needed by radiation safety professionals.
>   Examples include: obtaining updated calibration and source
>   check values for radiation monitors to account for
>   radioactive decay in a reference source, simulating
>   instrument readings to better understand measurement
>   uncertainty, correcting instrument readings for geometry and
>   ambient atmospheric conditions. Many of these functions are
>   described in Johnson and Kirby (2011, ISBN-13:
>   978-1609134198). Utilities are also included for developing
>   inputs and processing outputs with radiation transport codes,
>   such as MCNP, a general-purpose Monte Carlo N-Particle code
>   that can be used for neutron, photon, electron, or coupled
>   neutron/photon/electron transport (Werner et. al. (2018)
>   ).
> License: GPL-3
> Imports: ggplot2, readr, stats, graphics, RadData, stringr, magrittr,
>   dplyr, rlang
>
>
> Submitter's comment: ## Test environments
> * local Windows 10 home version
>   1809, R 3.6.2
> * ubuntu 16.04 and Fedora Linux (on
>   R-hub builder), R 3.6.2
>
> ## R CMD check results
> There
>   were no ERRORs or WARNINGs. There was one NOTE,
>   referring to non-standard files in the check
>   directory. These are output files resulting from
>   functions that provide text files to the user's
>   working or specified other directory.
>
> [[alternative HTML version deleted]]
>
> __
> 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

Re: [R-pkg-devel] Interpret feedback: not write testthat-tests in examples

[Mark van der Loo]

Dear Richel,

The comment itself is pretty clear I think: to be accepted on CRAN you
should not use testthat tests in your examples.

I can't speak for CRAN but I'm pretty convinced this is for testing in
general.

Tests are for testing, not for demonstration. Most users of your package
will probably have never heard of testthat because they are not package
authors. They also probably don't need testthat to use your package, so it
distracts them from learning how your package works. Packages like testthat
(and RUnit, unity and tinytest) are in the first place aimed at package
authors to make sure that their package works as it should and to avoid
re-introducing bugs (regressions).



Best,
Mark




On Thu, Jul 16, 2020 at 3:28 PM Richel Bilderbeek <
ric...@richelbilderbeek.nl> wrote:

> Dear R package developers,
>
> I would enjoy some help regarding some feedback I got on my package from a
> CRAN volunteer, as I am unsure how to interpret this correctly.
>
> This is the feedback I got (I added '[do]'):
>
> > Please [do] not write testthat-tests in your examples.
>
> I wonder if this is about using `testthat` or using tests in general.
>
> To simplify the context, say I wrote a package with a function called
> `add`, that adds two numbers. My example code would then be something like
> this:
>
> ```
> library(testthat)
>
> expect_equal(add(1, 2), 3)
> ```
>
> The first interpretation is about using `testthat`: maybe I should use
> base R (`stopifnot`) or another testing library (`testit`) or hand-craft it
> myself?
>
> The second interpretation is about using tests in example code. I like to
> actively demonstrate that my code works as expected. I checked the policies
> regarding examples, and I could not find a rule that I should refrain from
> doing so.
>
> What is the correct response to this feedback?
>
> Thanks for your guidance, Richel Bilderbeek
>
> __
> 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