[R-pkg-devel] C++11 requirements for package dependencies

2020-11-30 Thread Mark Clements 

[Apologies for cross-posting]

A colleague uses a package I maintain (rstpm2) as a dependency in their
package (rsimsum) with testing using GitHub Actions. They found that
testing failed against R versions 3.3, 3.4 and 3.5 because recent
versions of RcppArmadillo (which is a dependency in rstpm2) require
C++11. As a dependency diagram:

rsimsum --> rstpm2 --> RcppArmadillo

Should I update rstpm2 to include "CXX_STD = CXX11" in the Makevars and
Makevars.win files and add "SystemRequirements: C++11" to the
DESCRIPTION, or is there a simple way in GitHub Actions to use C++11 for
older versions of R?

Moreover, as a principle, should a package need to change the Makevars
and DESCRIPTION files to suit the most recent updates of their
dependencies? I would have thought that such a need would break many
packages.

Sincerely, Mark.



När du skickar e-post till Karolinska Institutet (KI) innebär detta att KI kommer att 
behandla dina personuppgifter. Här finns information om hur KI behandlar 
personuppgifter.


Sending email to Karolinska Institutet (KI) will result in KI processing your 
personal data. You can read more about KI’s processing of personal data 
here.

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

Re: [R-pkg-devel] C++11 requirements for package dependencies

2020-11-30 Thread Duncan Murdoch 
I think that C++11 isn't a requirement of RcppArmadillo, it's an option 
that is used if available.  (Assuming you are using the CRAN version, 
not an experimental/devel version.)  A user of the header file can include


#define ARMA_USE_CXX11

which would make it a system requirement of whatever package did that, 
even though it isn't a system requirement for RcppArmadillo.


But I could be wrong about this...

Duncan Murdoch

On 30/11/2020 11:06 a.m., Mark Clements wrote:

[Apologies for cross-posting]

A colleague uses a package I maintain (rstpm2) as a dependency in their
package (rsimsum) with testing using GitHub Actions. They found that
testing failed against R versions 3.3, 3.4 and 3.5 because recent
versions of RcppArmadillo (which is a dependency in rstpm2) require
C++11. As a dependency diagram:

rsimsum --> rstpm2 --> RcppArmadillo

Should I update rstpm2 to include "CXX_STD = CXX11" in the Makevars and
Makevars.win files and add "SystemRequirements: C++11" to the
DESCRIPTION, or is there a simple way in GitHub Actions to use C++11 for
older versions of R?

Moreover, as a principle, should a package need to change the Makevars
and DESCRIPTION files to suit the most recent updates of their
dependencies? I would have thought that such a need would break many
packages.

Sincerely, Mark.



När du skickar e-post till Karolinska Institutet (KI) innebär detta att KI kommer att 
behandla dina personuppgifter. Här finns information om hur KI behandlar 
personuppgifter.


Sending email to Karolinska Institutet (KI) will result in KI processing your 
personal data. You can read more about KI’s processing of personal data 
here.

__
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

Re: [R-pkg-devel] C++11 requirements for package dependencies

2020-11-30 Thread Dirk Eddelbuettel 


On 30 November 2020 at 17:06, Mark Clements wrote:
| [Apologies for cross-posting]
| 
| A colleague uses a package I maintain (rstpm2) as a dependency in their
| package (rsimsum) with testing using GitHub Actions. They found that
| testing failed against R versions 3.3, 3.4 and 3.5 because recent
| versions of RcppArmadillo (which is a dependency in rstpm2) require
| C++11. As a dependency diagram:
| 
| rsimsum --> rstpm2 --> RcppArmadillo
| 
| Should I update rstpm2 to include "CXX_STD = CXX11" in the Makevars and
| Makevars.win files and add "SystemRequirements: C++11" to the
| DESCRIPTION, or is there a simple way in GitHub Actions to use C++11 for
| older versions of R?

Yes.  Writing R Extension has the goods, as usual:

-

1.2.4 Using C++11 code
--

R can be built without a C++ compiler although one is available (but not
necessarily installed) on all known R platforms.  As from R 4.0.0 a C++
compiler will be selected only if it conforms to the 2011 standard
('C++11').  A minor update(1) ('C++14') was published in December 2014.
A revision ('C++17') was published in December 2017, and a further
revision ('C++20', with many new features) is scheduled for publication
in May 2020.

   What standard a C++ compiler aims to support can be hard to
determine: the value(2) of '__cplusplus' may help but some compilers use
it to denote a standard which is partially supported and some the latest
standard which is (almost) fully supported.

   The webpage  gives
some information on which compilers are known to support recent C++
features.  'g++' claims full C++11 support from version 4.8.1.

   As from version 3.6.2(3), R selects a default C++ compiler with
options that conform as far as possible(4) to C++11.  Packages which do
not specify 'R (>= 4.0)' in their 'DESCRIPTION' files need to explicitly
require C++11, hence the rest of this section.

   In order to specify C++11 code in a package to be used with R
versions from 3.1.0 but before 3.6.2, the package's 'Makevars' file (or
'Makevars.win' on Windows) should include the line

 CXX_STD = CXX11
Compilation and linking will then be done with the C++11 compiler (if
any).

   Packages without a 'src/Makevars' or 'src/Makefile' file may specify
that they require C++11 for code in the 'src' directory by including
'C++11' in the 'SystemRequirements' field of the 'DESCRIPTION' file,
e.g.

 SystemRequirements: C++11

   If a package does have a 'src/Makevars[.win]' file then setting the
make variable 'CXX_STD' is preferred, as it allows 'R CMD SHLIB' to work
correctly in the package's 'src' directory.

[... rest omitted ...]

-
 
| Moreover, as a principle, should a package need to change the Makevars
| and DESCRIPTION files to suit the most recent updates of their
| dependencies? I would have thought that such a need would break many
| packages.

I don't understand what you are trying to say.  R, as shown in the quote,
supports C++11 and even defaults to it.  What would break anywhere?

Dirk

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

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

Re: [R-pkg-devel] C++11 requirements for package dependencies

2020-11-30 Thread Dirk Eddelbuettel 


On 30 November 2020 at 11:27, Duncan Murdoch wrote:
| I think that C++11 isn't a requirement of RcppArmadillo, it's an option 

It is as of the 10.* series of Armadillo and hence RcppArmadillo 0.10.*

Dirk

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

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

Re: [R-pkg-devel] C++11 requirements for package dependencies

2020-11-30 Thread Duncan Murdoch 

On 30/11/2020 11:31 a.m., Dirk Eddelbuettel wrote:


On 30 November 2020 at 11:27, Duncan Murdoch wrote:
| I think that C++11 isn't a requirement of RcppArmadillo, it's an option

It is as of the 10.* series of Armadillo and hence RcppArmadillo 0.10.*


I was going to complain that you should include SystemRequirements: 
C++11, but on reading more closely, your Makevars.in specifies this in a 
different way.  So I guess the issue is with the Github Actions setup, 
which didn't spot the requirement.


Sorry for the noise...

Duncan Murdoch

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

Re: [R-pkg-devel] C++11 requirements for package dependencies

2020-11-30 Thread Dirk Eddelbuettel 


On 30 November 2020 at 11:54, Duncan Murdoch wrote:
| On 30/11/2020 11:31 a.m., Dirk Eddelbuettel wrote:
| > 
| > On 30 November 2020 at 11:27, Duncan Murdoch wrote:
| > | I think that C++11 isn't a requirement of RcppArmadillo, it's an option
| > 
| > It is as of the 10.* series of Armadillo and hence RcppArmadillo 0.10.*
| 
| I was going to complain that you should include SystemRequirements: 
| C++11, but on reading more closely, your Makevars.in specifies this in a 
| different way.  So I guess the issue is with the Github Actions setup, 
| which didn't spot the requirement.

Correct!  These are two different, and distinct, issues.

- CRAN checks for and uses _current_ packages with r-release and r-devel.
  C++11 is already a standard. Hence no change.

- OP had a problem because of a CI system that turns on older R versions for
  him. RcppArmadillo is a depends. And while RcppArmadillo has long allowed
  C++11, the (newer) dependency does not bubble up backwards from a dependee
  to the compiling package.  Hence the need to do it just as WRE describes.
 
| Sorry for the noise...

No worries.

Dirk

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

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

[R-pkg-devel] Conditional timeout for httr request when running R CMD check

2020-11-30 Thread Ayala Hernandez, Rafael 
Dear all,

My package openSkies includes a set of functions to retrieve information from 
the OpenSky API.

The examples for these functions can, on rare occassions, take anomously longer 
times to complete than usually because of issues on the API side.

I have already included a timeout parameter to prevent endless attempts to 
retrieve the result when, for example, the API is down for maintenance.

I have recently been asked by CRAN to reduce the execution time of each example 
to below 5 s. In order to do this, I can set the timeout parameter to something 
below 5s, and return NULL and a message indicating the resource is not 
currently available. However, I think this might not be the best option for 
examples that demonstrate important functionalities to users.

Therefore, I was wondering if there is anyway to set up the timeout parameter 
to a different value than usual based on the condition that examples are being 
run as part of R CMD check?

Thanks a lot in advance

Best wishes,

Rafa

[[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] Conditional timeout for httr request when running R CMD check

2020-11-30 Thread Jeff Newmiller 
Don't test against a live website for most of your testing... use recorded or 
simulated input. If your package functional interface doesn't allow for that, 
then re-factor it so it does.

For those tests that actually have to interact with the live website, only run 
them if you know you are not on CRAN. The testthat package has support for this 
if you don't want to roll your own.

On November 30, 2020 10:45:01 AM PST, "Ayala Hernandez, Rafael" 
 wrote:
>Dear all,
>
>My package openSkies includes a set of functions to retrieve
>information from the OpenSky API.
>
>The examples for these functions can, on rare occassions, take
>anomously longer times to complete than usually because of issues on
>the API side.
>
>I have already included a timeout parameter to prevent endless attempts
>to retrieve the result when, for example, the API is down for
>maintenance.
>
>I have recently been asked by CRAN to reduce the execution time of each
>example to below 5 s. In order to do this, I can set the timeout
>parameter to something below 5s, and return NULL and a message
>indicating the resource is not currently available. However, I think
>this might not be the best option for examples that demonstrate
>important functionalities to users.
>
>Therefore, I was wondering if there is anyway to set up the timeout
>parameter to a different value than usual based on the condition that
>examples are being run as part of R CMD check?
>
>Thanks a lot in advance
>
>Best wishes,
>
>Rafa
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

[R-pkg-devel] Windows R CMD check warning using Boost Beast

2020-11-30 Thread Florian Rupprecht 
Dear package development mailing list,

I am trying to publish my package httpgd (https://github.com/nx10/httpgd)
which includes Boost Beast to CRAN but I am struggling to solve a CMD check
warning:

* checking whether package 'httpgd' can be installed ... WARNING
Found the following significant warnings:
  lib/boost/beast/core/detail/char_buffer.hpp:39:21: warning: 'void*
memmove(void*, const void*, size_t)' forming offset
[-9223372036854771705, 4105] is out of the bounds [0, 4104] of object
'buf' with type 'boost::beast::detail::char_buffer<4096>'
[-Warray-bounds]


The warning is only shown under windows and deep inside the Boost Beast.

Thank you for any help you can provide,
Florian

[[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] Conditional timeout for httr request when running R CMD check

2020-11-30 Thread Henrik Bengtsson 
The problem here was regarding user facing example():s, not package tests.

In order to keep a neat example for the user to play with, I'd
probably wrap the example code in a \donttest{} statement.  Though, I
don't remember if CRAN tests with R CMD check --run-dontest, or not.
There's also \dontrun{}.

My $.02

/Henrik

On Mon, Nov 30, 2020 at 11:09 AM Jeff Newmiller
 wrote:
>
> Don't test against a live website for most of your testing... use recorded or 
> simulated input. If your package functional interface doesn't allow for that, 
> then re-factor it so it does.
>
> For those tests that actually have to interact with the live website, only 
> run them if you know you are not on CRAN. The testthat package has support 
> for this if you don't want to roll your own.
>
> On November 30, 2020 10:45:01 AM PST, "Ayala Hernandez, Rafael" 
>  wrote:
> >Dear all,
> >
> >My package openSkies includes a set of functions to retrieve
> >information from the OpenSky API.
> >
> >The examples for these functions can, on rare occassions, take
> >anomously longer times to complete than usually because of issues on
> >the API side.
> >
> >I have already included a timeout parameter to prevent endless attempts
> >to retrieve the result when, for example, the API is down for
> >maintenance.
> >
> >I have recently been asked by CRAN to reduce the execution time of each
> >example to below 5 s. In order to do this, I can set the timeout
> >parameter to something below 5s, and return NULL and a message
> >indicating the resource is not currently available. However, I think
> >this might not be the best option for examples that demonstrate
> >important functionalities to users.
> >
> >Therefore, I was wondering if there is anyway to set up the timeout
> >parameter to a different value than usual based on the condition that
> >examples are being run as part of R CMD check?
> >
> >Thanks a lot in advance
> >
> >Best wishes,
> >
> >Rafa
> >
> >   [[alternative HTML version deleted]]
> >
> >__
> >R-package-devel@r-project.org mailing list
> >https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> Sent from my phone. Please excuse my brevity.
>
> __
> 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

Re: [R-pkg-devel] Conditional timeout for httr request when running R CMD check

2020-11-30 Thread Ben Bolker 
  as pointed out to me the last time I was struggling with similar 
issues, if (interactive()) { ... } is another potential solution


On 11/30/20 2:48 PM, Henrik Bengtsson wrote:

The problem here was regarding user facing example():s, not package tests.

In order to keep a neat example for the user to play with, I'd
probably wrap the example code in a \donttest{} statement.  Though, I
don't remember if CRAN tests with R CMD check --run-dontest, or not.
There's also \dontrun{}.

My $.02

/Henrik

On Mon, Nov 30, 2020 at 11:09 AM Jeff Newmiller
 wrote:

Don't test against a live website for most of your testing... use recorded or 
simulated input. If your package functional interface doesn't allow for that, 
then re-factor it so it does.

For those tests that actually have to interact with the live website, only run 
them if you know you are not on CRAN. The testthat package has support for this 
if you don't want to roll your own.

On November 30, 2020 10:45:01 AM PST, "Ayala Hernandez, Rafael" 
 wrote:

Dear all,

My package openSkies includes a set of functions to retrieve
information from the OpenSky API.

The examples for these functions can, on rare occassions, take
anomously longer times to complete than usually because of issues on
the API side.

I have already included a timeout parameter to prevent endless attempts
to retrieve the result when, for example, the API is down for
maintenance.

I have recently been asked by CRAN to reduce the execution time of each
example to below 5 s. In order to do this, I can set the timeout
parameter to something below 5s, and return NULL and a message
indicating the resource is not currently available. However, I think
this might not be the best option for examples that demonstrate
important functionalities to users.

Therefore, I was wondering if there is anyway to set up the timeout
parameter to a different value than usual based on the condition that
examples are being run as part of R CMD check?

Thanks a lot in advance

Best wishes,

Rafa

   [[alternative HTML version deleted]]

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

--
Sent from my phone. Please excuse my brevity.

__
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

Re: [R-pkg-devel] C++11 requirements for package dependencies

2020-11-30 Thread Duncan Murdoch 

On 30/11/2020 11:54 a.m., Duncan Murdoch wrote:

On 30/11/2020 11:31 a.m., Dirk Eddelbuettel wrote:


On 30 November 2020 at 11:27, Duncan Murdoch wrote:
| I think that C++11 isn't a requirement of RcppArmadillo, it's an option

It is as of the 10.* series of Armadillo and hence RcppArmadillo 0.10.*


I was going to complain that you should include SystemRequirements:
C++11, but on reading more closely, your Makevars.in specifies this in a
different way.  So I guess the issue is with the Github Actions setup,
which didn't spot the requirement.

Sorry for the noise...


I think the remotes::system_requirements() function is used in setting 
up the Github Action files; it doesn't appear to recognize the need of 
RcppArmadillo for C++11.  I've posted this as an issue on Github. 
Hopefully I'm not wrong about this too...


Duncan Murdoch

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