[R-pkg-devel] current docker image for ASAN

[Steven Scott]

Greetings everyone, though I expect this message is mainly for Dirk.

CRAN checks of my bsts/Boom package generate an ASAN error that the CRAN
maintainers have asked me to look into.  I recall doing this before (this
error has been there for several years now) via a docker image that Dirk
had set up.  I have two questions.

1) Which docker image should I use?  I imagine it has been updated since
the last time I tried.
2) Is the image built with an asan-appropriate libc++?  I'm asking because
the last time I tried tracking down this error, ASAN identified that there
was an error, but pointed to an irrelevant section of code.  Brian thinks
libc++ is the culprit.

[[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] portability question

[Steven Scott]

I think Dirk was just showing me an example of how to branch on OS, which
would be relevant in the event that adding the 's' was harmful.  In this
case it sounds like adding the 's' is the right path forward, which is the
advice I was hoping for.  Thank you both!

On Wed, Dec 20, 2023 at 12:51 PM Simon Urbanek 
wrote:

> This has nothing to do with Steven's question since he is creating a
> *static* library whereas install_name_tool changes install name ID entry of
> a *dynamic* library. Also the data.table example is effectively a no-op,
> because changing the ID makes no difference as it can't be linked against
> directly anyway. [In general, taking advice from data.table regarding macOS
> doesn't strike me as wise given that the authors can't even get their
> package to work properly on macOS.]
>
> Cheers,
> Simon
>
>
> > On 21/12/2023, at 8:42 AM, Dirk Eddelbuettel  wrote:
> >
> >
> > On 20 December 2023 at 11:10, Steven Scott wrote:
> > | The Boom package builds a library against which other packages link.
> The
> > | library is built using the Makevars mechanism using the line
> > |
> > | ${AR} rc $@ $^
> > |
> > | A user has asked me to change 'rc' to 'rcs' so that 'ranlib' will be
> run on
> > | the archive.  This is apparently needed for certain flavors of macs.
> I'm
> > | hoping someone on this list can comment on the portability of that
> change
> > | and whether it would negatively affect other platforms.  Thank you.
> >
> > Just branch for macOS.  Here is a line I 'borrowed' years ago from
> data.table
> > and still use for packages needed to call install_name_tool on macOS.
> You
> > could have a simple 'true' branch of the test use 'rcs' and the 'false'
> > branch do what you have always done.  Without any portability concerns.
> >
> > From
> https://github.com/Rdatatable/data.table/blob/master/src/Makevars.in#L14
> > and indented here for clarity
> >
> >if [ "$(OS)" != "Windows_NT" ] && [ `uname -s` = 'Darwin' ]; then
> \
> >   install_name_tool -id data_table$(SHLIB_EXT)
> data_table$(SHLIB_EXT); \
> >fi
> >
> > Dirk
> >
> > --
> > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> >
> > __
> > 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] portability question

[Steven Scott]

The Boom package builds a library against which other packages link.  The
library is built using the Makevars mechanism using the line

${AR} rc $@ $^

A user has asked me to change 'rc' to 'rcs' so that 'ranlib' will be run on
the archive.  This is apparently needed for certain flavors of macs.  I'm
hoping someone on this list can comment on the portability of that change
and whether it would negatively affect other platforms.  Thank you.

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?

[Steven Scott]

Compiled code is another source of long names.  Some libraries are produced
by companies with style restrictions that demand LongDescriptiveNames for
functions and classes, and which expect file names to match the name of the
class contained within.  If you've got
Models/SpecificModelFamily/PosteriorSamplers/SpecificTypeOfPosteriorSampler.hpp
it leaves very little room (20 characters) for "C:\Users\..." etc up
front.

I solved my 'tar' problems with 'sed'.  In human readable code I keep the
long names.  In the code that gets submitted to CRAN I pass specific file
names through sed to rename the long files.  I have an install script with
lines like:

hdr="MvStateSpaceRegressionPosteriorSampler.hpp"
new_hdr="MVSSRPS.hpp"
mv "$ibase/$dbase/$hdr" "$ibase/$dbase/$new_hdr"
echo "replacing $dbase/$hdr with $dbase/$new_hdr"
grep -rl "$dbase/$hdr" "$BOOM_DIR/src/Models" | xargs $SED -i
"s|$dbase/$hdr|$dbase/$new_hdr|g"

This renames the files, and uses sed to replace #include references to file
names with the shorter file names.  The SED macro is because on mac 'sed'
is spelled 'gsed'.

I agree the system sucks.  It would be nice if one of the steps in
winbuilder took non-windows compliant TAR files and replaced them with ZIP
files or something similar.  We'd still have the Win32 character limit, but
256 > 100 so the problem wouldn't bite so hard.

On Thu, Dec 14, 2023 at 6:19 AM Vladimir Dergachev 
wrote:

>
>
> On Wed, 13 Dec 2023, McGrath, Justin M wrote:
>
> > On Windows, packages will be in "C:\Users\[User
> Name]\Documents\R\win-library\[R version]\[Package Name]".
> >
> > With a 150 byte limit, that leaves 70 bytes for the user name, R version
> > and package name. That seems more than sufficient. If people are
> > downloading the source files, that also leaves plenty of space
> > regardless where they choose to extract the files.
> >
>
> 70 bytes ?? My name is 18 characters long and there are plenty of people
> with longer names. I also saw practice on Windows systems to append the
> name of organization or department.
>
> Also, this restricts the length of package name which is arguably more
> important that internal package path names that the user never sees.
>
> That said, that Windows limitation is only for some programs, and the
> pertitent question is whether R and any software used by R has this
> limitation. I suspect the answer is no, but as all my systems are Linux
> I can not check.
>
> Vladimir Dergachev
>
> __
> 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] best LICENSE practices: AGPL-3 + LaTeX Project Public License

[Steven Scott]

I'll let others discuss the technical details of how to set up the licence
files.  I want to make sure you know that using AGPL is a good way to
ensure that nobody in tech uses your package.  Maybe that's intended, but
when I was at Google the ONLY software we were specifically prohibited from
using was code released under AGPL. I won't try to convince you of that
being a good or bad thing, but wanted to make sure you were aware of it.

On Tue, Jul 13, 2021 at 2:11 PM Ben Bolker  wrote:

>
>In the process of trying to get a package to build successfully on
> r-hub's Fedora platform, I had to add a whole bunch of LaTeX .sty files
> to the vignette directory.  One of these was collectbox.sty, which
> triggers the NOTE
>
> ---
> NOTE
> The following files contain a license that requires
> distribution of original sources:
>‘collectbox.sty’
> ---
>
>The licensing/copyright information in collectbox.sty is as follows:
>
>
> %% The original source files were:
> %%
> %% collectbox.dtx  (with options: `collectbox.sty')
> %%
> %% IMPORTANT NOTICE:
> %%
> %% For the copyright see the source file.
> %%
> %% Any modified versions of this file must be renamed
> %% with new filenames distinct from collectbox.sty.
> %%
> %% For distribution of the original source see the terms
> %% for copying and modification in the file collectbox.dtx.
> %%
> %% This generated file may be distributed as long as the
> %% original source files, as listed above, are part of the
> %% same distribution. (The sources need not necessarily be
> %% in the same archive or directory.)
> %% Copyright (C) 2012 by Martin Scharrer 
> %% 
> %% This work may be distributed and/or modified under the
> %% conditions of the LaTeX Project Public License, either version 1.3
> %% of this license or (at your option) any later version.
> %% The latest version of this license is in
> %%   http://www.latex-project.org/lppl.txt
> %% and version 1.3 or later is part of all distributions of LaTeX
> %% version 2005/12/01 or later.
>
> So I put collectbox.dtx into the inst/misc directory in the package.
> Fine.
>
>   Now, what do I need to do to (1) make sure that my DESCRIPTION file is
> correct and (2) hopefully, suppress the NOTE so I don't have to explain
> it to the CRAN maintainers every time?
>
> * Do I change the LICENCE line (which is currently AGPL-3)? According to
> https://cran.r-project.org/doc/manuals/R-exts.html#Licensing it would
> seem I would have to switch to "file LICENCE" (adding a
> "Licence_is_FOSS: yes"), where "LICENCE" contains something like
>
> package code licensed under AGPL-3; file vignettes/collectbox.sty is
> under the LaTeX Project Public License (source provided in
> misc/collectbox.dtx)
>
> ? Should it say "file LICENCE" or "AGPL-3 + file LICENCE" ?
>
> * Do I just include the files without comment, since I have complied (as
> far as I can tell) with the terms of the LPPL?
>
> * Is there a way to signal to R CMD check that I *have* complied with
> the terms?
>
>cheers
> Ben Bolker
>
> __
> 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] Problems with too much testing

[Steven Scott]

One of the basic principles of testing is "test interface, not
implementation."  Tests that violate this principle become "change detector
tests" instead of "correctness tests" and essentially prevent any
improvements to the code.  In C++ objects have "public" and "private"
methods, and the testing diktat is to test the public ones.  I hit this
issue a lot at Google when internal clients wrote change detector tests
effectively fencing in my tools.  My solution was to point out the
problematic tests and ask them not to do that.

The intent of R as a language is to be fast, lightweight, and flexible.  In
the interest of keeping it that way for users, it has grown large and
cumbersome for package authors.  If we try to tack on a "public/private"
object layout I'm afraid that would be yet another burden on package
authors.  The most obvious place I see to do this is in the NAMESPACE file,
which is already an ugly beast.  So while I agree with Duncan's
characterization of the problem, to my ears the "social solution" is the
cleanest one available, if we're talking about formal mechanisms.

Informally, both C++ and python use underscores in variable names to
suggest private data members.  You could just prefix "PRIVATE" to the name
of all the data members you don't want tested, where "PRIVATE" might become
"." or "_", or some other character.  I would argue against using
underscores, but I think I've already lost that battle.

On Fri, Apr 16, 2021 at 7:53 AM J C Nash  wrote:

> I'm generally in accord with Duncan on this. There are inevitably
> situations where general
> rules don't apply. Our challenge is to find practical ways to keep the
> overall workload of
> all participants in the process to a minimum.
>
> JN
>
> On 2021-04-16 10:18 a.m., Duncan Murdoch wrote:
> > On 16/04/2021 9:49 a.m., J C Nash wrote:
> >> Another approach is to change the responsibility.
> >>
> >> My feeling is that tests in the TESTING package should be modifiable by
> the maintainer of
> >> the TESTED package, with both packages suspended if the two maintainers
> cannot agree. We
> >> need to be able to move forward when legacy behaviour is outdated or
> just plain wrong. Or,
> >> in the case that I find affects me, when improvements in iterative
> schemes change iterates
> >> slightly. My guess is that Duncan's example is a case in point.
> >>
> >> I doubt this will ever occur, as it doesn't seem to be the R way.
> However, I do know that
> >> improvements in methods are not going to CRAN in some cases.
> >
> > In the cases I've been involved with the authors of the testing package
> have accepted suggested changes when I've made
> > them:  I think that's also part of "the R way".  However, this takes
> time for both of us:  I need to understand what
> > they are intending to test before I can suggest a change to it, and they
> need to understand my change before they can
> > decide if it is acceptable, or whether further changes would also be
> necessary.
> >
> > Github helps a lot with this:  if the testing package is there, I can
> quickly reproduce the issue, produce a fix, and
> > send it to the author, who can tweak it if I've set things up properly.
> >
> > For the kinds of changes you're making, I suspect relaxing a tolerance
> would often be enough, though if you switch
> > algorithms and record that in your results, the testing package may need
> to replace reference values.  I think I'd be
> > uncomfortable doing that.
> >
> > 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] incomplete gamma function Fortran subroutine

[Steven Scott]

You can often find this kind of code on netlib.org.  Just include it with
the fortran code in your package.

On Tue, Jul 21, 2020 at 11:22 AM Wang, Zhu  wrote:

> Sorry for not making myself clear: The Fortran subroutine in an R package
> needs to call incomplete gamma function.
>
> -Original Message-
> From: R-package-devel  On Behalf
> Of Ben Bolker
> Sent: Tuesday, July 21, 2020 12:54 PM
> To: r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] incomplete gamma function Fortran subroutine
>
>  Is there a reason not to use pgamma(), possibly adjusted by a
> (de-)normalizing constant?   (See detailed notes in ?pgamma)
>
> On 7/21/20 1:44 PM, Wang, Zhu wrote:
> > Hello,
> >
> > In an R function within a package, I would like to call a Fortran
> subroutine to compute lower gamma function. Any advice will be appreciated.
> >
> > Thanks!
> >
> > Zhu Wang
> >
> >   [[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
> __
> 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] [External] Re: Interpret feedback: not write testthat-tests in examples

[Steven Scott]

I agree with the consensus that documentation is for humans, while tests
are for computers.

On Thu, Jul 16, 2020, 8:41 PM  wrote:

> On Thu, 16 Jul 2020, Ben Bolker wrote:
>
> > FWIW/in defense of the OP, this is a *very* common idiom in the base R
> code
> > base.  There may be some false positives, but
> >
> >  find . -name "*.Rd" -exec grep -Fl "stopifnot(" {} \; | grep -v doc | wc
> >
> > lists 187 files, e.g. from src/library/utils/man/object.size.Rd
>
> And I probably wrote some of them, but I don't think I would now.
> As a rule, I think the documentation is clearer without the tests.
>
> On the other hand, we don't all agree on these things.
>
> >
> > stopifnot(identical( ## assert that all three are the same :
> >  unique(substr(as.vector(fsl), 1,5)),
> >  format(round(as.vector(sl)/1024, 1
> >
> >
> > On 7/16/20 2:02 PM, luke-tier...@uiowa.edu wrote:
> >> On Thu, 16 Jul 2020, Henrik Bengtsson wrote:
> >>
> >>> If the point of having, say,
> >>>
> >>> stopifnot(add(1, 2) == sum(c(1, 2))
> >>>
> >>> is to make it explicit to the reader that your add() function gives
> >>> the same results as sum(), then I argue that is valid to use in an
> >>> example.  I'm pretty sure I've used that in some of my examples.  For
> >>> the purpose, there should be no reason why you can't use other
> >>> "assert" functions for this purpose, e.g.
> >>>
> >>> testthat::expect_equal(add(1, 2), sum(c(1, 2))
> >>
> >> If the point is to communicate this to users I would write something
> like
> >>
> >> ## The following evaluates to TRUE:
> >> add(1, 2) == sum(c(1, 2)
> >>
> >> Using stopifnot just adds clutter that obscures the message for a
> >> human reader; testthat::expect_equal even more so.
> >>
> >> Best,
> >>
> >> luke
> >>
> >>>
> >>> Now, if the point of your "assert" statement is only to validate your
> >>> package/code, then I agree it should not be in the example code
> >>> because it adds clutter.  Such validation should be in a package test.
> >>>
> >>> So, if the former, I suggest you reply to the CRAN Team and explain
> this.
> >>>
> >>> /Henrik
> >>>
> >>> On Thu, Jul 16, 2020 at 6:28 AM Richel Bilderbeek
> >>>  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
> >>>
> >>> __
> >>> 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
> >
>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa  Phone: 319-335-3386
> Department of Statistics andFax:   319-335-3017
> Actuarial Science
> 241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
> __
> 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] package CatDataAnalysis

[Steven Scott]

Charlie,
The folks at CRAN try hard to serve everyone, but sometimes they wind up
making up rules as they go along.  I'd add another sentence or two about
the data, perhaps with an eye towards the wide world of "citizen data
scientists" who don't know about Alan's book.  Then resubmit the package
with a note that you've addressed their concerns the best you can, and see
what happens.
Steve

On Sun, Jun 28, 2020, 10:58 AM Charles Geyer  wrote:

> CRAN did not just ask for an expanded Description field.  They instructed
> "Tell the users what the datasets are about and what they contain so they
> can use them even when they haven't read your book".  AFAIK no CRAN package
> that goes with a book satisfies that.
>
> On Sun, Jun 28, 2020 at 12:52 PM Max Turgeon 
> wrote:
>
> > Fair enough. But CRAN is clearly asking for a more detailed Description
> > field. I simply offered one suggestion for expanding it. Keep in mind
> > that users will typically see the DESCRIPTION file first, and not the
> help
> > pages.
> >
> >
> > Max Turgeon
> > Assistant Professor
> > Department of Statistics
> > Department of Computer Science
> > University of Manitoba
> > maxturgeon.ca
> >
> >
> > --
> > *From:* Charles Geyer 
> > *Sent:* June 28, 2020 12:48:06 PM
> > *To:* Max Turgeon
> > *Cc:* R Package Development
> > *Subject:* Re: [R-pkg-devel] package CatDataAnalysis
> >
> > *Caution:* This message was sent from outside the University of Manitoba.
> > The link to Alan's web site is on every help page (in the source
> > section).  That's where the source is supposed to be.
> >
> > I have no problem with adding the source to the DESCRIPTION file, but
> that
> > is not what CRAN asked me to do.
> >
> > On Sun, Jun 28, 2020 at 12:16 PM Max Turgeon 
> > wrote:
> >
> >> For what it's worth, I'd be inclined to interpreting CRAN's response
> >> *very* literally, i.e. your Description field is not descriptive enough.
> >> According to what I can see in the Github repo, you only have
> >>
> >>
> >> "Datasets used in the book Categorical Data Analysis by Agresti but not
> >> printed in the book."
> >>
> >>
> >> Which is not much more than what the Title field says. One glaring
> >> omission (IMO) from the Description field is any mention of Agresti's
> >> website, where the data comes from.
> >>
> >>
> >> In contrast, looking at the "woolridge" package, I can see from the
> >> Description field that it contains 111 datasets (well, that's in the
> Title
> >> field), it's about econometrics, and the purpose of the package is to
> make
> >> it easier for students to work with these datasets.
> >>
> >>
> >> Max Turgeon
> >> Assistant Professor
> >> Department of Statistics
> >> Department of Computer Science
> >> University of Manitoba
> >> maxturgeon.ca
> >>
> >>
> >>
> >>
> >> --
> >> *From:* R-package-devel  on
> >> behalf of Charles Geyer 
> >> *Sent:* June 28, 2020 11:38 AM
> >> *To:* Neal Fultz
> >> *Cc:* R Package Development
> >> *Subject:* Re: [R-pkg-devel] package CatDataAnalysis
> >>
> >> 
> >> Caution: This message was sent from outside the University of Manitoba.
> >> 
> >>
> >> Actually the wooldridge package does not seem to satisfy any of the
> >> specific requests CRAN asked me for.  I have checked several other CRAN
> >> packages for textbooks and they don't seem to satisfy those requirements
> >> either.  So this seems to be a new idea from CRAN.
> >>
> >> On Sun, Jun 28, 2020 at 11:32 AM Neal Fultz  wrote:
> >>
> >> > I'm not sure exactly what cran is asking for, but the wooldridge
> >> > package is a good example of a text book data set package, so maybe
> >> > you can use the same format they did.
> >> >
> >> > https://cran.r-project.org/web/packages/wooldridge/index.html
> >> >
> >> > Best,
> >> >
> >> > Neal
> >> >
> >> > On Sun, Jun 28, 2020 at 9:08 AM Charles Geyer 
> >> > wrote:
> >> > >
> >> > > I have a package that has the datasets for Categorical Data Analysis
> >> by
> >> > > Agresti that do not appear in the book.  The whole package is a
> github
> >> > repo
> >> > > https://github.com/cjgeyer/CatDataAnalysis.  All of the data were
> >> > > translated mechanically using the R script foo.R included in the
> repo
> >> > (but
> >> > > not in the package) from Agresti's web site
> >> > > http://www.stat.ufl.edu/~aa/cda/data.html.
> >> > >
> >> > > This package seems to be a useful service to students and teachers.
> >> The
> >> > > data
> >> > > are much simpler to use with this package than trying to get the
> data
> >> > from
> >> > > Agresti's web page (foo.R has 277 lines of code).
> >> > >
> >> > > When I submitted the package to CRAN, I got the following response.
> >> > >
> >> > > > The Description field of the DESCRIPTION file is intended to be a
> >> (one
> >> > > > paragraph) description of what the package does and why it may be
> >> > >

Re: [R-pkg-devel] clang11 CRAN check and use of Eigen

[Steven Scott]

The errors are all around std::ostream.  My guess is that Eigen is missing
an #include.  The missing include was probably included transitively in
earlier versions of clang, but clang11 cleaned up some files that didn't
need that include themselves, and the downstream file got broken as a
result.

On Tue, May 12, 2020 at 6:51 PM Chris Paciorek 
wrote:

> As of some point recently (at least since January) our package
> (nimble) is being flagged by CRAN's clang11 check. The check reports
> various errors when compiling one of our C++ files that makes use of
> code from the Eigen C++ package, which we include with our package.
> Here's the report from CRAN:
> https://www.stats.ox.ac.uk/pub/bdr/clang11/nimble.log
>
> Similar errors are occurring for a few other packages on CRAN (some
> that directly include Eigen and others that do so via RcppEigen).
>
> 1) Does anyone happen to know why this problem with Eigen is occurring
> with clang11?
>
> 2) Given clang11 is not yet released, perhaps CRAN is simply flagging
> this for the future. I'm hoping we can still release our next version
> without addressing this, and I see that some of the other packages
> this affects have released recently (e.g., prophet) seemingly without
> addressing the issue. Does anyone know CRAN's policy in this regard?
>
> thanks,
> -Chris
>
> Adjunct Professor, Statistical Computing Consultant
> Department of Statistics
> UC Berkeley
>
> __
> 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] [FORGED] help with ASAN

[Steven Scott]

Rolf, I will strive to do better.

Please note that you load a package with library(...).  Just sayin'.

On Wed, Mar 25, 2020 at 6:16 PM Rolf Turner  wrote:

>
> On 26/03/20 10:17 am, Steven Scott wrote:
>
> > I'm trying to build an ASAN enabled version of my R library 
>
> 
>
> *PLEASE*!!!  Your R *package*!!!
>
> (A library is a *collection* of packages.)
>
> Correct terminology *does* matter, in that incorrect terminology can on
> occasion lead to confusion that that can on occasion have unfortunate
> consequences.
>
> cheers,
>
> Rolf Turner
>
> --
> Honorary Research Fellow
> Department of Statistics
> University of Auckland
> Phone: +64-9-373-7599 ext. 88276
>

[[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] help with ASAN

[Steven Scott]

Oohhh I didn't realize there was an RD.  That simplifies things a lot!
And for the record, I'm not surprised that my setup suggests that I don't
know what I'm doing viz-a-viz docker.  Everything was assembled by Google
search and spaghetti flinging, so I'm pleased to get some expert advice.

A grateful cheers and thank you for the help!

On Wed, Mar 25, 2020 at 5:21 PM Dirk Eddelbuettel  wrote:

>
> Steve,
>
> On 25 March 2020 at 16:48, Dirk Eddelbuettel wrote:
> | For ASAN/UBSAN to work you should use the same setting as the compiled
> | 'host'. As you benefit from a pre-made Docker container, its settings are
> |
> |   CC="clang -fsanitize=address,undefined
> -fno-sanitize=float-divide-by-zero -fno-omit-frame-pointer
> -fsanitize-address-use-after-scope" \
> |   CXX="clang++ -stdlib=libc++ -fsanitize=address,undefined
> -fno-sanitize=float-divide-by-zero -fno-omit-frame-pointer
> -fsanitize-address-use-after-scope" \
>
> Addendum / correction: Because R-devel in this container as been built with
> these settings, your package does NOT need to repeat them in its
> src/Makevars.
>
> Just invoke it via RD as in RD CMD INSTALL ... or RD CMD check ...
>
> Hth, 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] help with ASAN

[Steven Scott]

I'm trying to build an ASAN enabled version of my R library to help debug
errors found by CRAN on my last submission.  I'm tantalizingly close, but
need some help figuring out what's wrong with my configuration.

I'm using a docker container that I think contains a version of R built
with the right options.  I launch the docker container as so:

docker run --cap-add SYS_PTRACE -e PASSWORD= --rm -p 8787:8787 -v
/home/steve/code/BOOM:/home/steve/code/BOOM -it rocker/r-devel-ubsan-clang
/bin/bash

In this container I have added a ~/.R/Makevars file with the following
content:
CC= clang -std=c99 -fsanitize=address -fno-omit-frame-pointer
CXX= clang++ -std=c++11 -fsanitize=address -fno-omit-frame-pointer
CXX11= clang++ -std=c++11 -fsanitize=address -fno-omit-frame-pointer
FC = gfortran -fsanitize=address

When I build my package I get:
(... expected compiler output truncated except for final compile and link
step ... )
clang++ -std=c++11 -fsanitize=address -fno-omit-frame-pointer -std=gnu++11
-I"/usr/share/R/include" -DNDEBUG -I`/usr/lib/R/bin/Rscript -e
"cat(system.file(package='Boom'))"`/include -DADD_ -DR_NO_REMAP -DRLANGUAGE
-I"/usr/local/lib/R/site-library/Boom/include"   -fpic  -g -O2
-fdebug-prefix-map=/build/r-base-MP6Q4u/r-base-3.6.2=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -g  -c splines.cc -o splines.o
clang++ -std=c++11 -fsanitize=address -fno-omit-frame-pointer -std=gnu++11
-shared -L/usr/lib/R/lib -Wl,-z,relro -o BoomSpikeSlab.so
boom_spike_slab_init.o logit_spike_slab_wrapper.o mlm_spike_slab_wrapper.o
nested_regression_wrapper.o nnet_wrapper.o poisson_spike_slab_wrapper.o
probit_spike_slab_wrapper.o quantile_spike_wrapper.o
shrinkage_regression_wrapper.o spike_slab_wrapper.o splines.o
/usr/local/lib/R/site-library/Boom/lib/libboom.a -fsanitize=address
-L/usr/lib/R/lib -lR
installing to
/usr/local/lib/R/site-library/00LOCK-BoomSpikeSlab/00new/BoomSpikeSlab/libs
** R
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for ‘BoomSpikeSlab’ in
dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object
'/usr/local/lib/R/site-library/00LOCK-BoomSpikeSlab/00new/BoomSpikeSlab/libs/BoomSpikeSlab.so':

/usr/local/lib/R/site-library/00LOCK-BoomSpikeSlab/00new/BoomSpikeSlab/libs/BoomSpikeSlab.so:
undefined symbol: __asan_option_detect_stack_use_after_return
Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/usr/local/lib/R/site-library/BoomSpikeSlab’
* restoring previous ‘/usr/local/lib/R/site-library/BoomSpikeSlab’
PACKAGE = BoomSpikeSlab

[[alternative HTML version deleted]]

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

[R-pkg-devel] Need help building packages to track down ASAN error

[Steven Scott]

One of my packages (bsts) appears to have a memory error identified by ASAN.
I'm trying to build an ASAN-enabled R+bsts so that I can debug the error.

I'm using the rocker image rocker/r-devel-ubsan-clang, loaded and run as
follows:

docker run --cap-add SYS_PTRACE -e PASSWORD= --rm -p 8787:8787 -v
/home/steve/code/BOOM:/home/steve/code/BOOM -it rocker/r-devel-ubsan-clang
/bin/bash

This launches me into a bash shell.  At this point I think I need to build
and
install my package.  On this image the home directory is /root, and under
/root
I have installed /root/.R/Makevars with the following content (per section
4.3
of WRE).

CC = clang -std=c99 -fsanitize=address -fno-omit-frame-pointer
CXX = clang++ -std=c++11 -fsanitize=address -fno-omit-frame-pointer
FC = gfortran -fsanitize=address

When I run the scripts to build and install my packages (bsts + 2
dependencies,
named Boom and BoomSpikeSlab), I get output that looks like

g++ -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG
-I`/usr/lib/R/bin/Rscript -e "cat(system.file(package='Boom'))"`/include
-DADD_ -DR_NO_REMAP -DRLANGUAGE
-I"/usr/local/lib/R/site-library/Boom/include"   -fpic  -g -O2
-fdebug-prefix-map=/build/r-base-MP6Q4u/r-base-3.6.2=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -g  -c boom_spike_slab_init.cc -o boom_spike_slab_init.o
g++ -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG
-I`/usr/lib/R/bin/Rscript -e "cat(system.file(package='Boom'))"`/include
-DADD_ -DR_NO_REMAP -DRLANGUAGE
-I"/usr/local/lib/R/site-library/Boom/include"   -fpic  -g -O2
-fdebug-prefix-map=/build/r-base-MP6Q4u/r-base-3.6.2=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -g  -c logit_spike_slab_wrapper.cc -o
logit_spike_slab_wrapper.o


Here g++ is being used instad of the requested clang++ (I'm assuming R on
this
image was built with clang), and the important -fsanitize=address flag is
not
present.  So it seems that ~/.R/Makevars is being ignored.

The goal is to produce an ASAN-enabled package so that I can test for the
error.
Am I on the correct path to producing such a package, and if so what else
do I
need to do to get there?

Thank you.

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Linux Errors on RHub

[Steven Scott]

The examples are dual purpose.  They work like unit tests, and they show
humans how the code works.  If you have a separate unit testing section you
can mock out the parts that take a long time (e.g. "get data from...").
Then just put the slow bits in your .Rd files into \dontrun blocks.

On Tue, Apr 23, 2019 at 5:54 PM Roy Mendelssohn - NOAA Federal <
roy.mendelss...@noaa.gov> wrote:

> No C++ in my package,  but I think sf or rgdal may have c++.  I have
> graphics examples overlaying grids on maps using ggplot2.  trying to get
> those under 5 sec and still have a meaningful example is nigh impossible.
> I mean I can make up an example that will be under 5 sec,  but it will
> neither be illuminating nor testing of anything.  I have even included the
> test data in the package so that it is faster, (this package maps data from
> a package that downloads data from a web service)  but I am still not
> there.  Also the times I get at home are about half of what CRAN or RHub
> get.
>
> I have a similar problem with a package that downloads data from a web
> service.  Even the most minimal example takes more than 5 seconds.  I fully
> understand CRAN's position.  When you have 1000s of package to test on
> different OS,  if everything takes too long it would be a disaster.  At the
> same time,  basically the last three days I have been trying to figure out
> how to get the times down.
>
> -Roy
>
> On Apr 23, 2019, at 5:33 PM, Steven Scott 
> wrote:
>
> Roy, I don't have an answer for you, but I have a similar issue.
> Does your code happen to have a C++ component that takes a long time to
> compile?
>
> On Tue, Apr 23, 2019 at 5:11 PM Roy Mendelssohn - NOAA Federal via
> R-package-devel  wrote:
>
>
>
> -- Forwarded message --
> From: Roy Mendelssohn - NOAA Federal 
> To: Roy Mendelssohn - NOAA Federal via R-package-devel <
> r-package-devel@r-project.org>
> Cc:
> Bcc:
> Date: Tue, 23 Apr 2019 17:11:14 -0700
> Subject: Linux Errors on RHub
> Hi All:
>
> I am checking a package I am hoping to submit to CRAN on RHub.  The
> Windows and Fedora runs worked but the Ubuntu test ended because of the
> following:
>
> #> Warning messages:
> 3203#> 1: In i.p(...) : installation of package ‘rgdal’ had non-zero exit
> status
> 3204#> 2: In i.p(...) : installation of package ‘sf’ had non-zero exit
> status
> 3205#> 3: In i.p(...) :
>
>
> I have a few details to work out on Mac and Windows tests (capitalization,
> a note to CRAN that a spelling is correct, reduce times of examples),  but
> given that rgdal and sf are packages on CRAN if I can clean up the other
> items is it appropriate to go ahead and submit?
>
> Thanks,
>
> -Roy
>
>
> **
> "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK
> Jr.
>
>
>
>
> -- Forwarded message --
> From: Roy Mendelssohn - NOAA Federal via R-package-devel <
> r-package-devel@r-project.org>
> To: Roy Mendelssohn - NOAA Federal via R-package-devel <
> r-package-devel@r-project.org>
> Cc:
> Bcc:
> Date: Tue, 23 Apr 2019 17:11:14 -0700
> Subject: [R-pkg-devel] Linux Errors on RHub
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
> **
> "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK
> Jr.
>
>

[[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] Linux Errors on RHub

[Steven Scott]

Roy, I don't have an answer for you, but I have a similar issue.
Does your code happen to have a C++ component that takes a long time to
compile?

On Tue, Apr 23, 2019 at 5:11 PM Roy Mendelssohn - NOAA Federal via
R-package-devel  wrote:

>
>
>
> -- Forwarded message --
> From: Roy Mendelssohn - NOAA Federal 
> To: Roy Mendelssohn - NOAA Federal via R-package-devel <
> r-package-devel@r-project.org>
> Cc:
> Bcc:
> Date: Tue, 23 Apr 2019 17:11:14 -0700
> Subject: Linux Errors on RHub
> Hi All:
>
> I am checking a package I am hoping to submit to CRAN on RHub.  The
> Windows and Fedora runs worked but the Ubuntu test ended because of the
> following:
>
> > #> Warning messages:
> > 3203#> 1: In i.p(...) : installation of package ‘rgdal’ had non-zero
> exit status
> > 3204#> 2: In i.p(...) : installation of package ‘sf’ had non-zero exit
> status
> > 3205#> 3: In i.p(...) :
>
> I have a few details to work out on Mac and Windows tests (capitalization,
> a note to CRAN that a spelling is correct, reduce times of examples),  but
> given that rgdal and sf are packages on CRAN if I can clean up the other
> items is it appropriate to go ahead and submit?
>
> Thanks,
>
> -Roy
>
>
> **
> "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK
> Jr.
>
>
>
>
> -- Forwarded message --
> From: Roy Mendelssohn - NOAA Federal via R-package-devel <
> r-package-devel@r-project.org>
> To: Roy Mendelssohn - NOAA Federal via R-package-devel <
> r-package-devel@r-project.org>
> Cc:
> Bcc:
> Date: Tue, 23 Apr 2019 17:11:14 -0700
> Subject: [R-pkg-devel] Linux Errors on RHub
> __
> 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] long file names in tar

[Steven Scott]

Thanks Dirk,
Yes, I've done the same, and I agree the rules are the rules.  Rules should
be updated when they're no longer helpful, or when their cost outweighs
their benefit.  I'm curious whether that might be the case here.
Cheers,
Steve


On Thu, Apr 18, 2019 at 10:54 AM Dirk Eddelbuettel  wrote:

>
> On 18 April 2019 at 10:37, Steven Scott wrote:
> | My Boom package makes a C++ library available to package authors (mainly
> | me).  The wrapped library is used outside of R and must comply with
> | external style rules such as UseLongDescriptiveNames, and files must be
> | named for the class they contain.  From time to time a
> | LongDescriptiveFileName, when paired with its full directory path,
> exceeds
> | 100 characters.
> |
> | This creates a conflict with CRAN's rules about long file names, which
> | stems from tar.  I'm wondering what this community thinks about asking
> for
> | that rule to be relaxed.  Both gnu tar and posix tar now allow unlimited
> | length filenames, and the ustar format allows names up to 256 characters.
> |
> | I'm interested in the opinions of people on this list about whether this
> | rule has outlived its usefulness.  Thanks.
>
> There are no "opinions". There is CRAN Repo Policy.
>
> The BH package your Boom depends upon is actually named BH in part because
> having a two-letter name shrunk the set of files violating this very
> constraint.  Yet at every release I still get to renamed one file, and
> update
> one include statement.  All documented in the ChangeLog.
>
> So I would change the filenames, and move on.
>
> 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] long file names in tar

[Steven Scott]

My Boom package makes a C++ library available to package authors (mainly
me).  The wrapped library is used outside of R and must comply with
external style rules such as UseLongDescriptiveNames, and files must be
named for the class they contain.  From time to time a
LongDescriptiveFileName, when paired with its full directory path, exceeds
100 characters.

This creates a conflict with CRAN's rules about long file names, which
stems from tar.  I'm wondering what this community thinks about asking for
that rule to be relaxed.  Both gnu tar and posix tar now allow unlimited
length filenames, and the ustar format allows names up to 256 characters.

I'm interested in the opinions of people on this list about whether this
rule has outlived its usefulness.  Thanks.

[[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 whose unit tests sometimes fail because of server connections

[Steven Scott]

I'd mock the tests you want run on Cran and keep live fire tests that you
can run manually.  Just don't include the live fire stuff in the package.

On Tue, Apr 16, 2019, 10:57 AM Will  wrote:

> Hello everyone,
>
> I'm sorry to bother you, but I would like some help getting a package (
> *suppdata*; https://github.com/ropensci/suppdata) available through CRAN.
> The package downloads supplementary materials from papers and data
> repositories on the basis of their DOI, making reproducible analyses a
> little easier to share and create.
>
> The package's unit tests involve downloading data, and when multiple
> requests for the same resource are sent from a single machine (as seems to
> be done by CRAN's testing servers) the data hosts will sometimes refuse the
> connection and so the package's tests will fail. I emphasise that the tests
> pass at Travis-CI (https://travis-ci.org/ropensci/suppdata) and OpenCPU (
> https://ropensci.ocpu.io/suppdata/info); I am confident this is a
> connection issue but I would be grateful to be shown I am wrong. I am not
> sure how to solve this problem, and was hoping you might have some advice.
> Some things I have considered include:
>
>
>1. Skipping all unit tests on CRAN (using something like
>*testtht::skip_on_cran*). This would immediately fix the problem, and as
>a mitigating factor we report automated test result and coverage on the
>package's GitHub page (https://github.com/ropensci/suppdata).
>2. Using HTTP-mocking to avoid requiring a call to a server during tests
>at all. I would be uncomfortable relying solely on this for all tests,
>since if the data hosters changed things we wouldn't know. Thus I would
>still want the Internet-enabled tests, which would also have to be
> turned
>off for CRAN (see 1 above). This would also be a lot of additional work.
>3. Somehow bypassing the requirement for the unit tests to all pass
>before the package is checked by the CRAN maintainers. I have no idea if
>this is something CRAN would be willing to do, or if it is even
> possible.
>It would be the easiest option for me, but I don't want to create extra
>work for other people!
>4. Slowing the tests with something like *Sys.sleep*. This might work,
>but would slow the tests massively and so might that cause problems for
>CRAN?
>
> Does anyone have any advice as to which of the above would be the best
> option, or who I should email directly about this?
>
> Thank you for your help, and I apologise if I've missed some aspect of the
> documentation that already explains how to solve this,
>
> Will Pearse
>
> ---
>
> Need a phylogeny? Try phyloGenerator: original
>  or new version
> 
> Measuring phylogenetic structure? Try install.packages('pez')
>
> Will Pearse 
> Assistant Professor of Biology, Utah State University
> Office: +1-435-797-0831; Room LSB-333
> Skype: will.pearse
>
> [[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] bazel rules for testthat

[Steven Scott]

Is anyone on this list using bazel as a build system, and if so have you
found a good BUILD rule for unit tests based on testthat?  Thanks.

[[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 development

[Steven Scott]

Also, consider different names.  The convention in R is for a probability
distribution foo to have dfoo, pfoo, qfoo, and rfoo.  I'm not sure what S,
F and H stand for in your notation, so maybe consider giving them more
descriptive names?  If F is for Fisher then dFisherCor or something like
that.

On Tue, Jan 1, 2019 at 8:10 AM Duncan Murdoch 
wrote:

> On 01/01/2019 5:39 a.m., SOUVIK NATH wrote:
> > Dear CRAN maintainers and R package developers,
> >
> > Respected Sirs,
> >
> >
> >
> > I am interested in submitting a package which I created in RStudio,  that
> > contains functions to compute the PDF,CDF and critical region of the
> > distribution of sample correlation coeffecient :r. While running a R CMD
> > check , it shows a warning() as follows :
> >
> >
> >
> > Bad \usage lines found in documentation object 'Rcor':
> >
> >
> Spdf(r,rho,n),Fpdf(r,rho,n),Hpdf(r,rho,n),Fcdf(a,rho,n),Hcdf(r,rho,n)
> >
> >
> >
> > Functions with \usage entries need to have the appropriate \alias
> >
> >entries, and all their arguments documented.
> >
> >The \usage entries must correspond to syntactically valid R code.
> >
> >
> >
> >   Where the documentation for one of the R functions is given as follows
> :-
> >
> >
> >
> > #' PDF using Simulation
> >
> > #'
> >
> > #' @description used for computing the probability density functional
> value
> > for the bivariate normal sample correlation coeffecient
> >
> > #' @usage Spdf(r,rho,n)
> >
> > #' @param r  sample correlation coeffecient of the bivariate normal
> > distribution sample
> >
> > #' @param rho  population correlation coefficient of the bivariate normal
> > distribution
> >
> > #' @param n  sample size of the required Bivariate Normal Distribution
> >
> > #' @details uses Simulation to compute the PDF
> >
> > #' @return PDF of the sample correlation coeffecient distribution
> >
> > #' @author  Souvik Nath  ,Rituparna Sen
> >
> > #' @references Anderson,T.W.,(2003) An Introduction to Multivariate
> > Statistical Analysis.Third Edition ,Chapter 4, Page No 125. A JOHN WILEY
> > AND SONS,INC.,PUBLICATION
> >
> > #' @references DAVID,F.N.,(1954) TABLES OF THE ORDINATES AND THE
> > PROBABILITY INTEGRAL OF THE CORRELATION COEFFECIENT IN SMALL SAMPLES.
> > ISSUED BY THE BIOMETRIKA OFFICE,UNIVERSITY COLLEGE,LONDON
> >
> > #' @seealso Fpdf,Hpdf,Fcdf,Hcdf,FQcdf,HQcdf,Scdf,cconfint
> >
> > #' @examples ## If we want to calculate the pdf for "r=0.1,rho=0.1,n=3"
> >
> > #' @examples ## Spdf(0.1,0.1,3) # 0.306
> >
> > #' @import mvtnorm
> >
> > #' @export
> >
> >
> >
> > Please let me know what can be done in this case, regarding the
> > documentation. I have once submitted a copy of this package in CRAN few
> > weeks ago. I realize that the files may have been removed and I need to
> > resubmit them if required.
> >
>
> CRAN doesn't look at the Roxygen inputs, it looks at the .Rd files in
> the man directory.  From what you've posted, it is probably man/Rcor.Rd
> that you need to look at.  It will be up to you to make sure it follows
> the specification in Writing R Extensions to be a valid Rd file.  From
> the message, it appears you have a line
>
>
> Spdf(r,rho,n),Fpdf(r,rho,n),Hpdf(r,rho,n),Fcdf(a,rho,n),Hcdf(r,rho,n)
>
>
> in the file, and that is not valid in an Rd file.  It should perhaps be
> five lines,
>
> Spdf(r,rho,n)
> Fpdf(r,rho,n)
> Hpdf(r,rho,n)
> Fcdf(a,rho,n)
> Hcdf(r,rho,n)
>
> but without seeing the whole file we can't say for sure.
>
> 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] C++11 and deprecated warnings "noise" for auto_ptr

[Steven Scott]

Thanks Dirk,
This will cut down the size of my compilation logs dramatically.


On Thu, Jul 19, 2018 at 6:06 AM Iñaki Úcar  wrote:

> Great! Many thanks for sharing this, Dirk.
>
> Iñaki
> El jue., 19 jul. 2018 a las 14:37, Dirk Eddelbuettel
> () escribió:
> >
> >
> > As some of you may have noticed, or may have been told as well in kind
> "fix
> > this or else ..." email, 'R CMD check' now also marks g++-7 / g++-8
> warnings
> > of 'deprecated declarations'.
> >
> > This can of course be addressed in the code itself, or suppressed with
> the
> > '-Wno-deprecated-declarations' flag in compiler options in eg
> ~/.R/Makevars.
> >
> > A particularly annoying case is in all the code depending on Boost
> headers
> > and using eg our BH package. I just installed an updated new package from
> > CRAN and again had screens full of warnings for 'deprecated
> std::auto_ptr'.
> >
> > Looking at the Boost header file, it turns out that for this case one
> can use
> > the '-DBOOST_NO_AUTO_PTR' define and the compilation will be silent! So
> those
> > of us using Boost and BH could add the define to the headers.
> >
> > 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
>
>
>
> --
> Iñaki Úcar
> http://www.enchufa2.es
> @Enchufa2
>
> __
> 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] trying to understand an error

[Steven Scott]

Thanks Uwe.   Will do.

On Tue, Jun 5, 2018 at 1:55 PM, Uwe Ligges 
wrote:

> Please ask the Mac maintainer, Simon Urbanek, in such a case where it is
> not obvious what is going on.
>
> Best,
> Uwe Ligges
>
>
>
>
>
> On 05.06.2018 18:45, Steven Scott wrote:
>
>> If there's anyone willing to take a look at the build errors I would
>> appreciate it.  I'm trying to work a bug report from a downstream user,
>> and
>> I think the OSX build has an issue that I don't understand.
>> Thanks.
>>
>> On Thu, May 31, 2018 at 1:49 PM, Steven Scott <
>> steve.the.bayes...@gmail.com>
>> wrote:
>>
>> Looking at the Boom package results page, I see that it has errors on OSX
>>> and two flavors of Linux.
>>>
>>> The OSX install page is here:  https://www.r-project.
>>> org/nosvn/R.check/r-release-osx-x86_64/Boom-00install.html .
>>>
>>> I'm trying to understand the nature of the error.  The last lines say:
>>>
>>> clang++ -std=gnu++11 -I"/Library/Frameworks/R.framework/Resources/include"
>>> -DNDEBUG -I. -I../inst/include -IBmath -Imath/cephes
>>> -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-c
>>> apitan-x86_64/Rlib/3.5/BH/include" -I"/Volumes/SSD-Data/Builds/R-
>>> dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/RcppEigen/include"
>>> -I/usr/local/include   -fPIC  -Wall -g -O2 -c Models/TimeSeries/ArModel.cpp
>>> -o Models/TimeSeries/ArModel.o
>>> clang++ -std=gnu++11 -I"/Library/Frameworks/R.framework/Resources/include"
>>> -DNDEBUG -I. -I../inst/include -IBmath -Imath/cephes
>>> -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-c
>>> apitan-x86_64/Rlib/3.5/BH/include" -I"/Volumes/SSD-Data/Builds/R-
>>> dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/RcppEigen/include"
>>> -I/usr/local/include   -fPIC  -Wall -g -O2 -c 
>>> Models/TimeSeries/ArmaModel.cpp
>>> -o Models/TimeSeries/ArmaModel.o
>>> make: *** [Models/TimeSeries/ArmaModel.o] Interrupt: 2
>>> ERROR: compilation failed for package ‘Boom’
>>> * removing ‘/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-cap
>>> itan-x86_64/results/3.5/Boom.Rcheck/Boom’
>>>
>>>
>>> As I read this, it looks like there was no compiler error, but the build
>>> was interrupted for some reason.  Do others read it differently?  If I'm
>>> reading it right, what needs to happen to re-run the check to clear the
>>> OSX
>>> error status?
>>>
>>> Thanks,
>>>
>>> Steve
>>>
>>>
>> [[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] trying to understand an error

[Steven Scott]

If there's anyone willing to take a look at the build errors I would
appreciate it.  I'm trying to work a bug report from a downstream user, and
I think the OSX build has an issue that I don't understand.
Thanks.

On Thu, May 31, 2018 at 1:49 PM, Steven Scott 
wrote:

> Looking at the Boom package results page, I see that it has errors on OSX
> and two flavors of Linux.
>
> The OSX install page is here:  https://www.r-project.
> org/nosvn/R.check/r-release-osx-x86_64/Boom-00install.html .
>
> I'm trying to understand the nature of the error.  The last lines say:
>
> clang++ -std=gnu++11 -I"/Library/Frameworks/R.framework/Resources/include" 
> -DNDEBUG -I. -I../inst/include -IBmath -Imath/cephes  
> -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/BH/include"
>  
> -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/RcppEigen/include"
>  -I/usr/local/include   -fPIC  -Wall -g -O2 -c Models/TimeSeries/ArModel.cpp 
> -o Models/TimeSeries/ArModel.o
> clang++ -std=gnu++11 -I"/Library/Frameworks/R.framework/Resources/include" 
> -DNDEBUG -I. -I../inst/include -IBmath -Imath/cephes  
> -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/BH/include"
>  
> -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/RcppEigen/include"
>  -I/usr/local/include   -fPIC  -Wall -g -O2 -c 
> Models/TimeSeries/ArmaModel.cpp -o Models/TimeSeries/ArmaModel.o
> make: *** [Models/TimeSeries/ArmaModel.o] Interrupt: 2
> ERROR: compilation failed for package ‘Boom’
> * removing 
> ‘/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/results/3.5/Boom.Rcheck/Boom’
>
>
> As I read this, it looks like there was no compiler error, but the build
> was interrupted for some reason.  Do others read it differently?  If I'm
> reading it right, what needs to happen to re-run the check to clear the OSX
> error status?
>
> Thanks,
>
> Steve
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] trying to understand an error

[Steven Scott]

Looking at the Boom package results page, I see that it has errors on OSX
and two flavors of Linux.

The OSX install page is here:
https://www.r-project.org/nosvn/R.check/r-release-osx-x86_64/Boom-00install.html
.

I'm trying to understand the nature of the error.  The last lines say:

clang++ -std=gnu++11
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I.
-I../inst/include -IBmath -Imath/cephes
-I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/BH/include"
-I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/RcppEigen/include"
-I/usr/local/include   -fPIC  -Wall -g -O2 -c
Models/TimeSeries/ArModel.cpp -o Models/TimeSeries/ArModel.o
clang++ -std=gnu++11
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I.
-I../inst/include -IBmath -Imath/cephes
-I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/BH/include"
-I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/RcppEigen/include"
-I/usr/local/include   -fPIC  -Wall -g -O2 -c
Models/TimeSeries/ArmaModel.cpp -o Models/TimeSeries/ArmaModel.o
make: *** [Models/TimeSeries/ArmaModel.o] Interrupt: 2
ERROR: compilation failed for package ‘Boom’
* removing 
‘/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/results/3.5/Boom.Rcheck/Boom’


As I read this, it looks like there was no compiler error, but the build
was interrupted for some reason.  Do others read it differently?  If I'm
reading it right, what needs to happen to re-run the check to clear the OSX
error status?

Thanks,

Steve

[[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-pretest-archived] CRAN submission Boom 0.8

[Steven Scott]

Thanks Uwe.

On Sat, Apr 21, 2018 at 3:02 PM, Uwe Ligges  wrote:

>
>
> On 21.04.2018 20:06, Steven Scott wrote:
>
>> No word from the maintainers.
>>
>
> Only one maintainer is reading this list.
>
>
> I submitted a revised version of the package
>> just now (with an updated date in DESCRIPTION).
>>
>
> Thanks.
>
> If someone could look at it in the next few days I'd appreciate it.
>> Thanks.
>>
>
> We will do.
>
> Best,
> Uwe Ligges
>
>> On Wed, Apr 4, 2018 at 3:01 PM, Steven Scott <
>> steve.the.bayes...@gmail.com>
>> wrote:
>>
>> Thanks Dirk.  IMO the package is in good shape otherwise.  I'll wait hear
>>> from the CRAN maintainers.
>>> S
>>>
>>> On Wed, Apr 4, 2018 at 2:53 PM, Dirk Eddelbuettel 
>>> wrote:
>>>
>>>
>>>> On 4 April 2018 at 14:15, Steven Scott wrote:
>>>> | These appear to be caused by an ill formed std::set or std::function
>>>> in
>>>> the
>>>> | STL implementation of the host machine.  If I'm reading that wrong
>>>> someone
>>>> | please let me know.
>>>>
>>>> AFAICT it needs C++11 explicitly set which that machine (with a new
>>>> clang-6.0
>>>> installation) did not provide by default.  This has bitten a few other
>>>> compilations lately as well but should get sorted out in due course.
>>>>
>>>> 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
>>
>>

[[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-pretest-archived] CRAN submission Boom 0.8

[Steven Scott]

No word from the maintainers.  I submitted a revised version of the package
just now (with an updated date in DESCRIPTION).
If someone could look at it in the next few days I'd appreciate it.  Thanks.

On Wed, Apr 4, 2018 at 3:01 PM, Steven Scott 
wrote:

> Thanks Dirk.  IMO the package is in good shape otherwise.  I'll wait hear
> from the CRAN maintainers.
> S
>
> On Wed, Apr 4, 2018 at 2:53 PM, Dirk Eddelbuettel  wrote:
>
>>
>> On 4 April 2018 at 14:15, Steven Scott wrote:
>> | These appear to be caused by an ill formed std::set or std::function in
>> the
>> | STL implementation of the host machine.  If I'm reading that wrong
>> someone
>> | please let me know.
>>
>> AFAICT it needs C++11 explicitly set which that machine (with a new
>> clang-6.0
>> installation) did not provide by default.  This has bitten a few other
>> compilations lately as well but should get sorted out in due course.
>>
>> 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

Re: [R-pkg-devel] Fwd: [CRAN-pretest-archived] CRAN submission Boom 0.8

[Steven Scott]

Thanks Dirk.  IMO the package is in good shape otherwise.  I'll wait hear
from the CRAN maintainers.
S

On Wed, Apr 4, 2018 at 2:53 PM, Dirk Eddelbuettel  wrote:

>
> On 4 April 2018 at 14:15, Steven Scott wrote:
> | These appear to be caused by an ill formed std::set or std::function in
> the
> | STL implementation of the host machine.  If I'm reading that wrong
> someone
> | please let me know.
>
> AFAICT it needs C++11 explicitly set which that machine (with a new
> clang-6.0
> installation) did not provide by default.  This has bitten a few other
> compilations lately as well but should get sorted out in due course.
>
> 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] Fwd: [CRAN-pretest-archived] CRAN submission Boom 0.8

[Steven Scott]

I've been trying to update the Boom package to the next version, and it
hasn't been going so well.  Hoping someone can help me figure out what next
steps I should take.

I got the attached mail from auto-check.  From what I can tell the new
version of Boom (0.8.0) has two issues.  Some long path names, and a large
install size.  Both are pre-existing issues shared with previous Boom
versions.  Nothing can be done about the long path names (but they have
never caused a problem in the past), and the large install size has to do
with the -g flag passed by R CMD INSTALL, which I don't control.  In past
versions of Boom we've let both these issues go.

The auto-check script also flags an ERROR which seems to be related to
version 0.7.0 (the current version).  Clicking through to the compiler
errors (
https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/Boom-00install.html)
gives:

* installing to library
‘/home/hornik/tmp/R.check/r-devel-clang/Work/build/Packages’
* installing *source* package ‘Boom’ ...
** package ‘Boom’ successfully unpacked and MD5 sums checked
** libs
make[1]: Entering directory '/tmp/Rtmpnqufqi/R.INSTALL4d314a0b9495/Boom/src'
clang++-6.0  -I"/home/hornik/tmp/R.check/r-devel-clang/Work/build/include"
-DNDEBUG -I. -I../inst/include -IBmath -Imath/cephes
-DNO_BOOST_THREADS -DNO_BOOST_FILESYSTEM -DADD_ -DRLANGUAGE
-I"/home/hornik/tmp/R.check/r-devel-clang/Work/build/Packages/BH/include"
-I/usr/local/include   -fpic  -g -O3 -Wall -pedantic -mtune=native -c
Models/Bart/PoissonBartModel.cpp -o Models/Bart/PoissonBartModel.o
In file included from Models/Bart/PoissonBartModel.cpp:19:
In file included from ../inst/include/Models/Bart/PoissonBartModel.hpp:24:
In file included from ../inst/include/Models/Bart/Bart.hpp:22:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/set:60:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_tree.h:65:
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:545:9:
error: redefinition of '__not_overloaded<_Tp, _Up>'
struct __not_overloaded<_Tp, _Up> : __not_overloaded2<_Tp, _Up> { };
   ^~
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:531:9:
note: previous definition is here
struct __not_overloaded<_Tp, _Up, __void_t<
   ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:608:9:
error: redefinition of '__not_overloaded<_Tp, _Up>'
struct __not_overloaded<_Tp, _Up> : __not_overloaded2<_Tp, _Up> { };
   ^~
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:594:9:
note: previous definition is here
struct __not_overloaded<_Tp, _Up, __void_t<
   ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:671:9:
error: redefinition of '__not_overloaded<_Tp, _Up>'
struct __not_overloaded<_Tp, _Up> : __not_overloaded2<_Tp, _Up> { };
   ^~
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:657:9:
note: previous definition is here
struct __not_overloaded<_Tp, _Up, __void_t<
   ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:734:9:
error: redefinition of '__not_overloaded<_Tp, _Up>'
struct __not_overloaded<_Tp, _Up> : __not_overloaded2<_Tp, _Up> { };
   ^~
/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/stl_function.h:720:9:
note: previous definition is here
struct __not_overloaded<_Tp, _Up, __void_t<
   ^
4 errors generated.
/home/hornik/tmp/R.check/r-devel-clang/Work/build/etc/Makeconf:166:
recipe for target 'Models/Bart/PoissonBartModel.o' failed
make[1]: *** [Models/Bart/PoissonBartModel.o] Error 1
make[1]: Leaving directory '/tmp/Rtmpnqufqi/R.INSTALL4d314a0b9495/Boom/src'
ERROR: compilation failed for package ‘Boom’
* removing ‘/home/hornik/tmp/R.check/r-devel-clang/Work/build/Packages/Boom’

These appear to be caused by an ill formed std::set or std::function in the
STL implementation of the host machine.  If I'm reading that wrong someone
please let me know.

Thanks!
S

-- Forwarded message --
From: 
Date: Wed, Apr 4, 2018 at 1:21 PM
Subject: [CRAN-pretest-archived] CRAN submission Boom 0.8
To: steve.the.bayes...@gmail.com
Cc: cran-submissi...@r-project.org


Dear maintainer,

package Boom_0.8.tar.gz does not pass the incoming checks automatically,
please see the following pre-tests:
Windows: 
Status: 4 NOTEs
Debian: