Re: [R-pkg-devel] First CRAN submission - quick feedback

[Zhian Kamvar]

Generally you will want to use an application directory for storing these
files (a la rappdirs) and, importantly, allow the user to consent to these
files being downloaded and installed, which should not be done on load.


On Sun, Mar 12, 2023 at 13:24 Ronald Bergmann  wrote:

> Hi r-package-devel,
>
> we'll soon make our first submission to CRAN (hopefully). While there's
> still stuff to do* and while we're waiting for an update to one of the
> dependencies I'd kindly like to ask if anyone would mind taking a quick
> look at the repository to assess if the overall structure seems fine.
>
> Here's the repo: https://github.com/haganjam/FW_invert_biomass_allometry
>
> One thing is that the package requires a couple of database files, which
> are about 20 MB in size and rather growing than shrinking. A standalone
> data package didn't seem like a good solution to me, so I added a zzz.R
> file to load the required files on install time (well, initialization /
> load time, it is). Makes sense to me but I don't know if this will be fine
> with CRAN.
>
> Thanks a lot in advance and have a great week!
> Cheers
>
>
> * pipelines are pretty much copypasta and failing
> * waiting for fixes in one of the dependencies
> * tests need some love
> * still gotta test file path resolution / whether to drop here
>
> __
> 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] Current recommendations re. GitHub Action?

[Zhian Kamvar]

This warning says to update to v2 of the action from r-lib:

Warning: r-lib/actions/setup-r@v1 is deprecated. Please update your
> workflow to use the 'v2' version. Also look at the examples at
> https://github.com/r-lib/actions/tree/v2/examples because '@v2' workflows
> are much simpler than 'v1' workflows.


We ran into a similar problem and switching to v2 did the trick.

Best,
Zhian

On Mon, Jan 2, 2023 at 10:20 AM Spencer Graves <
spencer.gra...@effectivedefense.org> wrote:

> Hello, All:
>
>
>   What are current recommendations for GitHub Action?
>
>
>   My most recent change to "sos" generated "Failed to get R" for
> ubuntu-latest (release, devel, and oldrel-1).
>
>
> https://github.com/sbgraves237/sos/actions/runs/3820307473/jobs/6498527786
>
>
>   I would happily rtfm if I only knew which fmtr.
>
>
>   Thanks,
>   Spencer Graves
>
> __
> 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] check cross-references error: Non-file package-anchored link(s)

[Zhian Kamvar]

Hello,

I noticed a strange error pop up for R-devel (2020-06-12 r78687) check on 
travis: 
https://travis-ci.org/github/grunwaldlab/poppr/jobs/697831376#L4653-L4654

* checking Rd cross-references ... WARNING
Non-file package-anchored link(s) in documentation object 'aboot.Rd':
  ‘[ape:phylo]{ape::phylo()}’

I looked at the Cross-reference section of WRE, but I couldn't find any mention 
of non-file package-anchored links being a problem: 
https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Cross_002dreferences

Is this a new policy?

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

Re: [R-pkg-devel] Proper way to ask a user to set permanent variables?

[Zhian Kamvar]

Options are not persistent between sessions unless the user wants them to
be. You can have users set the options in their .Rprofile either in the
working directory of the project or their home directory. This is the
method that the {usethis} package has for storing default names. The only
downside to this is that any R scripts associated will not be reproducible
unless paired with the .Rprofile file.

Best,
Zhian

On Fri, Jan 17, 2020 at 8:01 AM Rainer M Krug  wrote:

> Hi Dirk,
>
> The package-local environment is definitely a good approach (I use it
> myself an a few packages). And the options() are nice as they represent a
> standardised interface in R (Note to myself: I should use these more in my
> packages).
>
> But unless I am missing something, these are not persistent between
> sessions? I assume, that is not an issue in your case?
>
> Cheers,
>
> Rainer
>
>
> > On 15 Jan 2020, at 23:47, Dirk Eddelbuettel  wrote:
> >
> >
> > Jonathan,
> >
> > In all but one (maybe two?) of my packages I found relying on options()
> > sufficient. I usually follow the somewhat-common pattern of creating a
> > package-local environment in R/init.R or R/zzz.R. I then fill it with
> values
> > reflecting options() (often under a tag starting with the package name)
> > and/or environment variables, and sometime also provide 'setters' to
> update
> > the environment values. That have proven to be both good enough and
> rather
> > robust and, as an added benefit, does not depend on anything further.
> >
> > Cheers, Dirk
> >
> > --
> > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> >
> > __
> > 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)
>
> Orcid ID: -0002-7490-0066
>
> Department of Evolutionary Biology and Environmental Studies
> University of Zürich
> Office Y34-J-74
> Winterthurerstrasse 190
> 8075 Zürich
> Switzerland
>
> Office: +41 (0)44 635 47 64
> Cell:   +41 (0)78 630 66 57
> email:  rainer.k...@uzh.ch
> rai...@krugs.de
> Skype: RMkrug
>
> PGP: 0x0F52F982
>
>
>
>
> [[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] potential memory leak using openMP

[Zhian Kamvar]

I've had a problem like this before and I also thought that it was due to
some weird magic in OpenMP, but it turned out to be a fence-post error on
my part [1]. Unfortunately, the valgrind output is not as helpful as
something like ASAN. My suggestion would be to go through that section of
the code with a debugger and manually check for any weird behaviors (full
disclosure: I haven't done this with parallel code). My blog [1] has a
short version of Kevin Ushey's post on debugging with lldb [2], so those
might be good starting points.

[1]: https://zkamvar.netlify.com/post/2018-01-14-i-c-bugs/i-c-bugs/
[2]: http://kevinushey.github.io/blog/2015/04/13/debugging-with-lldb/

Hope that helps.

Best,
Zhian

On Fri, Nov 15, 2019 at 4:50 PM Marcin Jurek 
wrote:

> Hello everyone, so my package was rejected from CRAN because of the
> following error:
>
> ==29416== 640 bytes in 2 blocks are possibly lost in loss record 162 of
> 2,089
> ==29416==at 0x4837B65: calloc
> (coregrind/m_replacemalloc/vg_replace_malloc.c:762)
> ==29416==by 0x40118B1: allocate_dtv
> (/build/glibc-suXNNi/glibc-2.29/elf/../elf/dl-tls.c:286)
> ==29416==by 0x40121FD: _dl_allocate_tls
> (/build/glibc-suXNNi/glibc-2.29/elf/../elf/dl-tls.c:532)
> ==29416==by 0x5684BDD: allocate_stack
> (/build/glibc-suXNNi/glibc-2.29/nptl/allocatestack.c:621)
> ==29416==by 0x5684BDD: pthread_create@@GLIBC_2.2.5
> (/build/glibc-suXNNi/glibc-2.29/nptl/pthread_create.c:669)
> ==29416==by 0x565DF65: ??? (in
> /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
> ==29416==by 0x5654A3C: GOMP_parallel (in
> /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
> ==29416==by 0x1DBACEBA: U_NZentries(int, int, arma::Mat const&,
> arma::Mat const&, arma::Mat const&, arma::Col
> const&, arma::Col const&, std::__cxx11::basic_string std::char_traits, std::allocator >,  arma::Col)
>
> (/home/Hornik/tmp/CRAN/GPvecchia.Rcheck/00_pkg_src/GPvecchia/src/U_NZentries.cpp:225)
> ==29416==by 0x1DBA3B90: _GPvecchia_U_NZentries
>
> (/home/Hornik/tmp/CRAN/GPvecchia.Rcheck/00_pkg_src/GPvecchia/src/RcppExports.cpp:78)
>
> First, I don't know how to reproduce it because running
> R CMD check  --use-valgrind
> does not produce any errors on my machine.
>
> Second, see below the relevant part of the U_NZentries function (with the
> offending line marked with (***).
>
> *** #pragma omp parallel for
> shared(locs,revNNarray,revCondOnLatent,nuggets, nnp,m,Lentries,COV)
> private(k,dist,onevec,covmat,nug,n0,inds,revCon_row,inds00)
>  schedule(static)
>
>   for (k = 0; k < nnp; k++) {
> inds=revNNarray.row(k).t();
> revCon_row=revCondOnLatent.row(k).t();
> n0 = get_nonzero_count_general(inds); // for general case
> inds00 = get_idx_vals_general(n0, inds);
> nug=nuggets.elem(inds00) % (ones(n0)-revCon_row(span(m+1-n0,m))); //
> vec is vec, cannot convert to mat
> dist = calcPWD(locs.rows(inds00));
> #pragma omp critical
> {
>   if( COV=="matern"){
> covmat= MaternFun(dist,covparms) + diagmat(nug) ; // summation from
> arma
>   } else if(COV=="esqe") {
> covmat= EsqeFun(dist,covparms) + diagmat(nug) ; // summation from
> arma
>   }
> }
> onevec.resize(n0);
> onevec = zeros(n0);
> onevec[n0-1] = 1;
> arma::vec M=solve(chol(covmat,"upper"),onevec);
> // save the entries to matrix
> Lentries(k,span(0,n0-1)) = M.t();
>   }
>
> I have googled around and some people are saying that what valgrind reports
> is an unavoidable consequence of using openMP (for example here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36298 and here:
>
> https://stackoverflow.com/questions/6973489/valgrind-and-openmp-still-reachable-and-possibly-lost-is-that-bad
> ).
>
> Three questions: 1) what should I do to reproduce the error? 2) is it worth
> trying to do so? 3) why does it come up?
>
> Thanks a lot everyone!
>
> Marcin
>
> [[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] R package manual failing only on R-devel-linux-x86_64-debian-gcc

[Zhian Kamvar]

For the curious, an update from Uwe Ligges:

Kurt Hornik found:
>
> <
> https://tex.stackexchange.com/questions/1522/pdfendlink-ended-up-in-different-nesting-level-than-pdfstartlink
> >
>
> and you shoudl be able to reproduce via
>
>R_PAPERSIZE=a4 R CMD Rd2pdf /path/to/poppr
>
> Suggestion:
>
> Add a blank line before
>
>Examples of analyses are available in a primer written by Niklaus
> J. Grünwald, Zhian N. Kamvar, and Sydney E.  Everhart at
> \url{http://grunwaldlab.github.io/Population_Genetics_in_R}.}
>


Zhian

On Tue, Jun 18, 2019 at 4:22 PM Zhian Kamvar  wrote:

> Thank you for the the insights, Gabor and Hugh! Line 186 happens to be a
> \begin{itemize} in the package documentation section (which is chock-full
> of links), I didn't change that, but I did expand the DESCRIPTION, so I
> guess it makes sense that one of those links have slid down and gotten
> stuck between the pages.
>
> Now if only I had a reliable way of reproducing the error -_-
>
> Thank you both for the quick responses!
> Zhian
>
> On Tue, Jun 18, 2019 at 4:00 PM Hugh Parsonage 
> wrote:
>
>> Unfortunately this error is caused by a hyperlink straddling a page, so
>> it’s difficult to solve uniformly.
>>
>> The LaTeX error message provides a clue as to where the hyperlink might
>> be (near an \item near a \code) but no exact location.
>>
>> My advice would be to look where you have hyperlinks (including cross
>> references) in your documentation and either reword the documentation or
>> omit hyperlinks until you can produce a full pdf manual. Then, examine
>> where the hyperlink might have straddled two pages and more surgically
>> reword that paragraph/list to enable the original intent to be typeset.
>>
>> The hyperlink may also occur in a bibliography where you may have to make
>> more drastic omissions or additions in order for compilation to succeed.
>>
>> On Wed, 19 Jun 2019 at 12:37 am, Zhian Kamvar  wrote:
>>
>>> Hello,
>>>
>>> I'm having a really strange problem that I cannot reproduce locally
>>> (Ubuntu
>>> bionic) or on Rhub. I've run into an issue where the R package manual is
>>> failing only on this platform with ancient LaTeX runes that I struggle to
>>> decipher [0]
>>>
>>> > * checking PDF version of manual ... WARNING
>>> > LaTeX errors when creating PDF version.
>>> > This typically indicates Rd problems.
>>> > LaTeX errors found:
>>> > ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level
>>> than \pd
>>> > fstartlink.
>>> > \AtBegShi@Output ...ipout \box \AtBeginShipoutBox
>>> >   \fi \fi
>>> > l.186 \item \code
>>> > !  ==> Fatal error occurred, no output PDF file produced!
>>> > * checking PDF version of manual without hyperrefs or index ... OK
>>> > * checking for non-standard things in the check directory ... NOTE
>>> > Found the following files/directories:
>>> >   ‘poppr-manual.tex’
>>> >
>>> >
>>> The only information I could find on the error was a question with
>>> answers
>>> that were more questions: https://stackoverflow.com/q/2765229/2752888
>>>
>>> Uwe Ligges was kind enough to trigger a second build to see if this was
>>> an
>>> anomaly, but the same incantation appeared again. I've tried building
>>> this
>>> on Rhub debian-devel-gcc, but could not reproduce the error [1] and no
>>> other platform does this.
>>>
>>> Has anyone seen this before?
>>>
>>> Thanks,
>>> Zhian
>>>
>>> [0]:
>>>
>>> https://win-builder.r-project.org/incoming_pretest/poppr_2.8.3_20190618_151346/Debian/00check.log
>>> [1]:
>>>
>>> https://builder.r-hub.io/status/original/poppr_2.8.3.tar.gz-130d92cdeb2c4c46b94d8cc13b8921b9
>>>
>>> [[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] R package manual failing only on R-devel-linux-x86_64-debian-gcc

[Zhian Kamvar]

Thank you for the the insights, Gabor and Hugh! Line 186 happens to be a
\begin{itemize} in the package documentation section (which is chock-full
of links), I didn't change that, but I did expand the DESCRIPTION, so I
guess it makes sense that one of those links have slid down and gotten
stuck between the pages.

Now if only I had a reliable way of reproducing the error -_-

Thank you both for the quick responses!
Zhian

On Tue, Jun 18, 2019 at 4:00 PM Hugh Parsonage 
wrote:

> Unfortunately this error is caused by a hyperlink straddling a page, so
> it’s difficult to solve uniformly.
>
> The LaTeX error message provides a clue as to where the hyperlink might be
> (near an \item near a \code) but no exact location.
>
> My advice would be to look where you have hyperlinks (including cross
> references) in your documentation and either reword the documentation or
> omit hyperlinks until you can produce a full pdf manual. Then, examine
> where the hyperlink might have straddled two pages and more surgically
> reword that paragraph/list to enable the original intent to be typeset.
>
> The hyperlink may also occur in a bibliography where you may have to make
> more drastic omissions or additions in order for compilation to succeed.
>
> On Wed, 19 Jun 2019 at 12:37 am, Zhian Kamvar  wrote:
>
>> Hello,
>>
>> I'm having a really strange problem that I cannot reproduce locally
>> (Ubuntu
>> bionic) or on Rhub. I've run into an issue where the R package manual is
>> failing only on this platform with ancient LaTeX runes that I struggle to
>> decipher [0]
>>
>> > * checking PDF version of manual ... WARNING
>> > LaTeX errors when creating PDF version.
>> > This typically indicates Rd problems.
>> > LaTeX errors found:
>> > ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level
>> than \pd
>> > fstartlink.
>> > \AtBegShi@Output ...ipout \box \AtBeginShipoutBox
>> >   \fi \fi
>> > l.186 \item \code
>> > !  ==> Fatal error occurred, no output PDF file produced!
>> > * checking PDF version of manual without hyperrefs or index ... OK
>> > * checking for non-standard things in the check directory ... NOTE
>> > Found the following files/directories:
>> >   ‘poppr-manual.tex’
>> >
>> >
>> The only information I could find on the error was a question with answers
>> that were more questions: https://stackoverflow.com/q/2765229/2752888
>>
>> Uwe Ligges was kind enough to trigger a second build to see if this was an
>> anomaly, but the same incantation appeared again. I've tried building this
>> on Rhub debian-devel-gcc, but could not reproduce the error [1] and no
>> other platform does this.
>>
>> Has anyone seen this before?
>>
>> Thanks,
>> Zhian
>>
>> [0]:
>>
>> https://win-builder.r-project.org/incoming_pretest/poppr_2.8.3_20190618_151346/Debian/00check.log
>> [1]:
>>
>> https://builder.r-hub.io/status/original/poppr_2.8.3.tar.gz-130d92cdeb2c4c46b94d8cc13b8921b9
>>
>> [[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

[R-pkg-devel] R package manual failing only on R-devel-linux-x86_64-debian-gcc

[Zhian Kamvar]

Hello,

I'm having a really strange problem that I cannot reproduce locally (Ubuntu
bionic) or on Rhub. I've run into an issue where the R package manual is
failing only on this platform with ancient LaTeX runes that I struggle to
decipher [0]

> * checking PDF version of manual ... WARNING
> LaTeX errors when creating PDF version.
> This typically indicates Rd problems.
> LaTeX errors found:
> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than 
> \pd
> fstartlink.
> \AtBegShi@Output ...ipout \box \AtBeginShipoutBox
>   \fi \fi
> l.186 \item \code
> !  ==> Fatal error occurred, no output PDF file produced!
> * checking PDF version of manual without hyperrefs or index ... OK
> * checking for non-standard things in the check directory ... NOTE
> Found the following files/directories:
>   ‘poppr-manual.tex’
>
>
The only information I could find on the error was a question with answers
that were more questions: https://stackoverflow.com/q/2765229/2752888

Uwe Ligges was kind enough to trigger a second build to see if this was an
anomaly, but the same incantation appeared again. I've tried building this
on Rhub debian-devel-gcc, but could not reproduce the error [1] and no
other platform does this.

Has anyone seen this before?

Thanks,
Zhian

[0]:
https://win-builder.r-project.org/incoming_pretest/poppr_2.8.3_20190618_151346/Debian/00check.log
[1]:
https://builder.r-hub.io/status/original/poppr_2.8.3.tar.gz-130d92cdeb2c4c46b94d8cc13b8921b9

[[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] Proper way to document helper functions not accessible by user.

[Zhian Kamvar]

You can add

#' @noRd

to those functions and roxygen2 will not generate .Rd files for those
entries.

On Mon, Aug 13, 2018 at 2:08 PM Eggleston, Barry  wrote:

> Hello,
>
> I am working through my first submission and making good progress with the
> CRAN review system, but now I need to understand the best practice for
> dealing with helper functions.  I am building a package that only exports
> 12 functions for direct user access, but it has many helper functions not
> directly accessible to the user.  In my R code I am using roxygen2 to write
> my help pages.  I have written roxygen2 notes to create help pages for
> every function, but for all the helper functions I am using the keyword
> 'internal' so they don't show up in the index of help pages and available
> functions.  In future releases I may export these functions for direct
> access, but for now I want to keep them internal.  Within each help page of
> these non-accessible helper functions, I have placed '#None' in the
> @examples section, since nobody will be able to call the functions
> directly.  In my submission review I was asked to give examples for these
> functions, because my package still has the .Rd files f
>  or these helper functions in the submitted .tar.gz file.  How do I proper
> handle documentation of these helper functions?  Can I remove the roxygen2
> notes that create the .Rd files for these helper functions, so the package
> does not contain .Rd files for them?
>
> Thanks,
> Barry
>
> [[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] Printing examples conditionally on another package in Suggests

[Zhian Kamvar]

This was what I was looking for! Thank you!

I apologize for my insufficient google-fu today.

On Fri, Aug 10, 2018 at 12:55 PM Georgi Boshnakov <
georgi.boshna...@manchester.ac.uk> wrote:

> Maybe  Martin Maechler's post in response to a similar question answers
> your question:
>
> https://stat.ethz.ch/pipermail/r-package-devel/2018q2/002780.html
>
> In summary, wrap the code in:
>
>   if (requireNamespace("MASS", quietly = TRUE)) withAutoprint({
>
>   your code
>
>   })
>
>
> Georgi Boshnakov
>
> -Original Message-
> From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
> Behalf Of Zhian Kamvar
> Sent: 10 August 2018 12:26
> To: Alexandre Courtiol
> Cc: R-list Package Devel
> Subject: Re: [R-pkg-devel] Printing examples conditionally on another
> package in Suggests
>
> Thanks, but my use of print here is really a toy example, not necessarily
> the end-goal. This strategy would fail if I were to attempt load a data set
> from some_package or use any functions from some_package.
>
> A more specific example of what I'm dealing with is here:
>
> http://www.repidemicsconsortium.org/incidence/reference/get_counts.html#examples
> .
> This is what the user would see if they were to use example(get_counts).
>
> On Fri, Aug 10, 2018 at 12:14 PM Alexandre Courtiol <
> alexandre.court...@gmail.com> wrote:
>
> > Perhaps then something like:
> > Print <- function(x) if (requireNamespace("some.package", quietly =
> TRUE))
> > print(x)
> > Print("Hi")
> > Print("Hello")
> > Print("Goodbye")
> >
> >
> >
> > On Fri, 10 Aug 2018 at 12:33, Zhian Kamvar  wrote:
> >
> >> Mainly, I would like to see the value printed after the print statement
> >> like it would appear in a normal R session:
> >>
> >> print("Hi")
> >> #> [1] "Hi"
> >> print("Hello")
> >> #> [1] "Hello"
> >> print("Goodbye")
> >> #> [1] "Goodbye"
> >>
> >>
> >> On Fri, Aug 10, 2018 at 11:28 AM Alexandre Courtiol <
> >> alexandre.court...@gmail.com> wrote:
> >>
> >>> Hi Zhian,
> >>> Could you please explain what behaviour you would like to obtain?
> >>> I really don't understand what your problem is from your description...
> >>> Alex
> >>>
> >>> On Fri, 10 Aug 2018 at 12:18, Zhian Kamvar  wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> I know it's good practice to use
> >>>>
> >>>> if (require("some_package")) {
> >>>>   # some code that needs some_package
> >>>> }
> >>>>
> >>>> In R examples that needs a package listed in Suggests.
> >>>>
> >>>> The problem with this approach is that if there are any print
> statements
> >>>> within this structure, then they only get printed after the braces and
> >>>> not
> >>>> after the lines like so:
> >>>>
> >>>> if (TRUE) {
> >>>>   print("Hi")
> >>>>   print("Hello")
> >>>>   print("Goodbye")
> >>>> }
> >>>> #> [1] "Hi"
> >>>> #> [1] "Hello"
> >>>> #> [1] "Goodbye"
> >>>>
> >>>> The only way I can think of circumventing this is by replacing the if
> >>>> statement with a stopifnot statement:
> >>>>
> >>>> stopifnot(require("some_package"))
> >>>> # some code that needs some_package
> >>>>
> >>>> But, I'm not sure if that's okay to do in a function example. Does
> >>>> anyone
> >>>> have any ideas or suggestions on how to help with this kind of thing?
> >>>>
> >>>> Cheers,
> >>>> Zhian
> >>>>
> >>>> [[alternative HTML version deleted]]
> >>>>
> >>>> __
> >>>> R-package-devel@r-project.org mailing list
> >>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>>>
> >>>
> >>>
> >>> --
> >>> Alexandre Courtiol
> >>>
> >>> http://sites.google.com/site/alexandrecourtiol/home
> >>>
> >>> *"Science is the belief in the ignorance of experts"*, R. Feynman
> >>>
> >>
> >
> > --
> > Alexandre Courtiol
> >
> > http://sites.google.com/site/alexandrecourtiol/home
> >
> > *"Science is the belief in the ignorance of experts"*, R. Feynman
> >
>
> [[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] Printing examples conditionally on another package in Suggests

[Zhian Kamvar]

Thanks, but my use of print here is really a toy example, not necessarily
the end-goal. This strategy would fail if I were to attempt load a data set
from some_package or use any functions from some_package.

A more specific example of what I'm dealing with is here:
http://www.repidemicsconsortium.org/incidence/reference/get_counts.html#examples.
This is what the user would see if they were to use example(get_counts).

On Fri, Aug 10, 2018 at 12:14 PM Alexandre Courtiol <
alexandre.court...@gmail.com> wrote:

> Perhaps then something like:
> Print <- function(x) if (requireNamespace("some.package", quietly = TRUE))
> print(x)
> Print("Hi")
> Print("Hello")
> Print("Goodbye")
>
>
>
> On Fri, 10 Aug 2018 at 12:33, Zhian Kamvar  wrote:
>
>> Mainly, I would like to see the value printed after the print statement
>> like it would appear in a normal R session:
>>
>> print("Hi")
>> #> [1] "Hi"
>> print("Hello")
>> #> [1] "Hello"
>> print("Goodbye")
>> #> [1] "Goodbye"
>>
>>
>> On Fri, Aug 10, 2018 at 11:28 AM Alexandre Courtiol <
>> alexandre.court...@gmail.com> wrote:
>>
>>> Hi Zhian,
>>> Could you please explain what behaviour you would like to obtain?
>>> I really don't understand what your problem is from your description...
>>> Alex
>>>
>>> On Fri, 10 Aug 2018 at 12:18, Zhian Kamvar  wrote:
>>>
>>>> Hello,
>>>>
>>>> I know it's good practice to use
>>>>
>>>> if (require("some_package")) {
>>>>   # some code that needs some_package
>>>> }
>>>>
>>>> In R examples that needs a package listed in Suggests.
>>>>
>>>> The problem with this approach is that if there are any print statements
>>>> within this structure, then they only get printed after the braces and
>>>> not
>>>> after the lines like so:
>>>>
>>>> if (TRUE) {
>>>>   print("Hi")
>>>>   print("Hello")
>>>>   print("Goodbye")
>>>> }
>>>> #> [1] "Hi"
>>>> #> [1] "Hello"
>>>> #> [1] "Goodbye"
>>>>
>>>> The only way I can think of circumventing this is by replacing the if
>>>> statement with a stopifnot statement:
>>>>
>>>> stopifnot(require("some_package"))
>>>> # some code that needs some_package
>>>>
>>>> But, I'm not sure if that's okay to do in a function example. Does
>>>> anyone
>>>> have any ideas or suggestions on how to help with this kind of thing?
>>>>
>>>> Cheers,
>>>> Zhian
>>>>
>>>> [[alternative HTML version deleted]]
>>>>
>>>> __
>>>> R-package-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>
>>>
>>>
>>> --
>>> Alexandre Courtiol
>>>
>>> http://sites.google.com/site/alexandrecourtiol/home
>>>
>>> *"Science is the belief in the ignorance of experts"*, R. Feynman
>>>
>>
>
> --
> Alexandre Courtiol
>
> http://sites.google.com/site/alexandrecourtiol/home
>
> *"Science is the belief in the ignorance of experts"*, R. Feynman
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] Printing examples conditionally on another package in Suggests

[Zhian Kamvar]

Hello,

I know it's good practice to use

if (require("some_package")) {
  # some code that needs some_package
}

In R examples that needs a package listed in Suggests.

The problem with this approach is that if there are any print statements
within this structure, then they only get printed after the braces and not
after the lines like so:

if (TRUE) {
  print("Hi")
  print("Hello")
  print("Goodbye")
}
#> [1] "Hi"
#> [1] "Hello"
#> [1] "Goodbye"

The only way I can think of circumventing this is by replacing the if
statement with a stopifnot statement:

stopifnot(require("some_package"))
# some code that needs some_package

But, I'm not sure if that's okay to do in a function example. Does anyone
have any ideas or suggestions on how to help with this kind of thing?

Cheers,
Zhian

[[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] Can Submission Failure

[Zhian Kamvar]

Copy this output into a file called .Rbuildignore at the top of the directory:

>  .DS_Store
>  .RData
>  .Rhistory
>  ._*
>  .gitignore
>  .travis.yml
>  R/.DS_Store
>  R/._*
>  data/.DS_Store
>  data/.Rapp.history
>  man/.Rapp.history
>  vignettes/._*
>  vignettes/.gitignore
>  .Rproj.user
>  .git

Hope that helps,
Zhian

> On Aug 7, 2018, at 17:27 , Ossenbruggen, Paul  
> wrote:
> 
> I am new to CRAN submissions and need assistance.
> 
> I received this set of error messages previously. I removed all these hidden 
> files before resubmitting my package. They are back.
> Question #1 How do I prevent this this?
> 
> PJO:Desktop PJO$ tar -zcvf Basic.tar.gz Basic
> Found the following hidden files and directories:
> 
>  .DS_Store
>  .RData
>  .Rhistory
>  ._NAMESPACE
>  .gitignore
>  .travis.yml
>  R/.DS_Store
>  R/._brkdelay.R
>  R/._brkdelay3.R
>  R/._brktrials3.R
>  R/._brktrials3setup.R
>  R/._merge.R
>  R/._merge3.R
>  R/._mergedemo.R
>  R/._plotdesire3.R
>  R/._plotmerge3.R
>  R/._run.R
>  R/._trajectoryab3.R
>  R/._tuxvfix3.R
>  R/._vehid.R
>  R/._xabmerge.R
>  R/._xabmerge3.R
>  data/.DS_Store
>  data/.Rapp.history
>  man/.Rapp.history
>  vignettes/._cartools.Rmd
>  vignettes/.gitignore
>  .Rproj.user
>  .git
> 
> 
> Finding an answer to this question will be a big help.
> 
> 
> I performed R CMD check and devtools::build_win() before I submitted the 
> above. For completeness, here are my submit statements.
> 
> 
> From: CRAN submission 
> mailto:cran-sysad...@xmpalantir.wu.ac.at>>
> Subject: CRAN submission Basic 0.1.0
> Date: August 7, 2018 at 11:29:34 AM EDT
> To: CRAN 
> mailto:cran-submissi...@r-project.org>>
> Reply-To: Paul J. Ossenbruggen mailto:p...@unh.edu>>
> 
> 
> The maintainer confirms that he or she
> has read and agrees to the CRAN policies.
> 
> Submitter's comment: This submittal passes these checks. However, I am
> uncertain that my submittal succeed. See #1, #2, #3,
> #4 and #5.
> 
> R CMD check results
> 0 errors | 0
> warnings | 0 notes
> R CMD check succeeded
> 
> 
> devtools::build_win()
> Building windows version of
> cartools for R-devel with
> win-builder.r-project.org.
> 
> #1. Warning:
> ‘inst/doc’ files
>   ‘cartools.Rmd’,
> ‘cartools.html’, ‘cartools.R’
> ignored as
> vignettes have been rebuilt.
> Run R CMD build with
> --no-build-vignettes to prevent rebuilding.
> *
> checking for LF line-endings in source and make files
> and shell scripts
> * checking for empty or unneeded
> directories
> * looking to see if a
> ‘data/datalist’ file should be added
> #2.
> *
> building ‘cartools_0.1.0.tar.gz’
> I don't understand what this file is for. I am uploading:  Basic.tar.gz.
> 
> #3
> I have instructed the following
> folder to be ignored:  .Rproj.user
> It is not ignored
> in GitHub. It contains items that I did not
> create.
> This does not seem correct,
> 
> #4. I
> receievd a win-builder email stating:
> Possibly
> mis-spelled words in DESCRIPTION: cartools
> (3:8)
> Unknown, possibly mis-spelled, fields in
> DESCRIPTION: 'Remotes'
> The above items are
> false/postives.
> 
> I don't understand the following
> statement.
> The Title field is just the package name:
> provide a real title.
> 
> #5. I am a subscriber but my
> questions to r-packages-devel bounce.
> 
> 
> 
> 
> 
> =
> 
> Original content of DESCRIPTION file:
> 
> Package: Basic
> Type: Package
> Title: CARTOOLS Package
> Version: 0.1.0
> Author: person("Paul", "Ossenbruggen", email = 
> "p...@unh.edu", role = c("aut", "cre"))
> Maintainer: "Paul J. Ossenbruggen" mailto:p...@unh.edu>>
> Description: The cartools package is designed for college students studying 
> transportation engineering and for transportation professionals and 
> researchers interested in understanding the complex relationships associated 
> with freeway performance and traffic breakdown. Emphasis is placed on: (1) 
> Traffic noise or volatility; (2) Driver behavior and safety; and (3) 
> Stochastic modeling, models that explain breakdown and performance.
> License: MIT + file LICENSE
> Encoding: UTF-8
> LazyData: true
> Depends: R (>= 2.10)
> RoxygenNote: 6.1.0
> Remotes: pjossenbruggen/Basic
> Imports:
>   animation,
>   devtools,
>   dplyr,
>   gapminder,
>   ggplot2,
>   graphics,
>   grDevices,
>   knitr,
>   rlist,
>   rmarkdown,
>   roxygen2,
>   sde,
>   shiny,
>   stats,
>   tidyverse,
>   usethis,
>   utils
> Suggests:
> VignetteBuilder: knitr
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



signature.asc
Description: Message signed with OpenPGP
__
R-package-devel@r-project.org mailing list

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

[Zhian Kamvar]

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 each of the three files that
>> use dplyr I have the line:
>> 
>>import::from(dplyr, mutate, filter, rename, select, setdiff, slice, "%>%")
>> 
>> I've tried:
>> 
>>(1) putting that line in just one of the files (the lexically first one)
>>(2) including different subsets of dplyr functions, as needed, in
>> the various files
>> 
>> Needless to say, I haven't seen any improvement with any of the above
>> (or any of the other thrashing I've done).
>> 
>> If you can point me in the right direction, I'd appreciate it.  Thanks.
>> 
>> -- Mike
>> 
>> 
>>> session_info()
>> Session info 
>> --
>> setting  value
>> version  R version 3.4.4 (2018-03-15)
>> system   x86_64, linux-gnu
>> ui   X11
>> language en_US
>> collate  en_US.UTF-8
>> tz   America/Los_Angeles
>> date 2018-07-14
>> 
>> Packages 
>> --
>> package* version date   source
>> assertthat   0.2.0   2017-04-11 CRAN (R 3.3.3)
>> base   * 3.4.4   2018-03-16 local
>> bindr0.1.1   2018-03-13 CRAN (R 3.4.3)
>> bindrcpp 0.2.2   2018-03-29 CRAN (R 3.4.4)
>> compiler 3.4.4   2018-03-16 local
>> crayon   1.3.4   2017-09-16 CRAN (R 3.4.1)
>> datasets   * 3.4.4   2018-03-16 local
>> devtools   * 1.13.6  

Re: [R-pkg-devel] Issue with including vignettes without building package

[Zhian Kamvar]

Perhaps you could add a Makefile with a rule that compiles the vignettes into 
the inst/doc directory? This might avoid the build process.

-
Zhian N. Kamvar, Ph. D.
Postdoctoral Researcher (Everhart Lab)
Department of Plant Pathology
University of Nebraska-Lincoln



> On Apr 20, 2017, at 15:30 , Alexandre Courtiol  
> wrote:
> 
> Thanks but I don't think so, that would imply them to rebuild the
> vignettes, which is exactly what I want to avoid.
> Without knitr cached chunk it would take forever on their laptops and they
> would also need to install tons of packages...
> ++
> 
> On 20 April 2017 at 21:01, Sven E Templer  > wrote:
> 
>> Hi Alex,
>> 
>> 
>> what if you run
>> 
>> devtools::install_github(build_vignettes = TRUE)
>> 
>> on your students computer?
>> 
>> See ?devtools::install
>> 
>> 
>> Best,
>> 
>> Sven
>> 
>> 
>>> On 20. Apr 2017, at 15:09, Alexandre Courtiol <
>> alexandre.court...@gmail.com> wrote:
>>> 
>>> Dear all,
>>> 
>>> I am using a package for teaching:
>>> my slides are html vignettes, and it is convenient for students to
>> control
>>> which packages they must install, provide code and datasets.
>>> 
>>> As I am often editing the package live during the course, it would be
>> great
>>> if I could just push to github and that the student would just have to
>> run
>>> a devtools::install_github() to get my updated vignettes. I would rather
>>> not to have to build the package before pushing to save time.
>>> 
>>> The issues is that I do not want to build the vignettes on install as
>> they
>>> are very slow to build. On my computer however it is quick because I have
>>> cached the knitr chunks output. So I was hoping to just have to run
>>> devtools::build_vignettes() on my machine before pushing the files
>> thereby
>>> created (./inst/doc) and that the student could just
>>> devtools::install_github().
>>> 
>>> I cannot make this work: no vignettes are found after install. When I do
>>> check the repository beeing installed on their computers, the html, Rmd
>> and
>>> R files corresponding to the vignettes are present in ./doc, so it is not
>>> an issue of having the wrong .gitgnore configuration.
>>> 
>>> I have read about many vignettes related issues on the net, but I did not
>>> find something dealing with this precise issue.
>>> 
>>> PS: I know about the R.rsp hack, but I would prefer to find a solution
>> more
>>> direct.
>>> 
>>> Best,
>>> 
>>> Alex
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Alexandre Courtiol
>>> 
>>> http://sites.google.com/site/alexandrecourtiol/home
>>> 
>>> *"Science is the belief in the ignorance of experts"*, R. Feynman
>>> 
>>>  [[alternative HTML version deleted]]
>>> 
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
>> 
> 
> 
> -- 
> Alexandre Courtiol
> 
> http://sites.google.com/site/alexandrecourtiol/home 
> 
> 
> *"Science is the belief in the ignorance of experts"*, R. Feynman
> 
>   [[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] [[openmx-dev]] Re: [[openmx-dev]] Re: openmp

[Zhian Kamvar]

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 omp.h
#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.

 On Aug 24, 2015, at 08:46 , Joshua N Pritikin jpriti...@pobox.com wrote:
 
 On Mon, Aug 24, 2015 at 10:14:10AM -0500, Dirk Eddelbuettel wrote:
 On 24 August 2015 at 11:02, Joshua N Pritikin wrote:
 | Currently, we have a configure script for package OpenMx that only 
 | enables openmp if gcc is the compiler (OS X only). Nice to hear that 
 | openmp is supported on Windows.
 
 Interesting that you opt to ignore OpenMP support on the platform that
 probably supports it best ...
 
 Do you mean Linux? Yeah, we do enable OpenMP on gcc+Linux but CRAN 
 doesn't compile binaries for Linux so it's up to the user to have things 
 set up properly.
 
 -- 
 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

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