[R-pkg-devel] ISNAN warning [-Wfloat-conversion]
Hi,
Please see below warning from GCC (rtools 4.0).
I know that the flag "-Wconversion" is not used by default when building
packages in R but I was wondering if the below warning can be avoided by
changing the ISNAN function in the R C API?
The functions R_IsNaN and R_IsNA do not generate these warnings but they
also have a different behaviour than ISNAN.
test_ISNAN = inline::cfunction(
verbose = TRUE,
language = "C",
cppargs = "-Wconversion",
sig = c(x = "SEXP"),
body = "
if (ISNAN(asReal(x))) {
Rprintf(\"Hello\");
}
return R_NilValue;
")
Setting PKG_CPPFLAGS to -Wconversion
Compilation argument:
C:/PROGRA~1/R/R-40~1.0/bin/x64/R CMD SHLIB filed40200e5009.c 2>
filed40200e5009.c.err.txt
"C:/rtools40/mingw64/bin/"gcc -I"C:/PROGRA~1/R/R-40~1.0/include" -DNDEBUG
-Wconversion -O2 -Wall -std=gnu99 -mfpmath=sse -msse2
-mstackrealign -c filed40200e5009.c -o filed40200e5009.o
In file included from C:/PROGRA~1/R/R-40~1.0/include/R.h:58,
from filed40200e5009.c:1:
filed40200e5009.c: In function 'filed40200e5009':
C:/PROGRA~1/R/R-40~1.0/include/Rinternals.h:1531:18: warning: conversion
from 'double' to 'float' may change value [-Wfloat-conversion]
#define asReal Rf_asReal
filed40200e5009.c:8:7: note: in expansion of macro 'ISNAN'
if (ISNAN(asReal(x))) {
^
filed40200e5009.c:8:13: note: in expansion of macro 'asReal'
if (ISNAN(asReal(x))) {
^~
C:/rtools40/mingw64/bin/gcc -shared -s -static-libgcc -o
filed40200e5009.dll tmp.def filed40200e5009.o
-LC:/PROGRA~1/R/R-40~1.0/bin/x64 -lR
Program source:
1: #include
2: #include
3: #include
4:
5:
6: SEXP filed40200e5009 ( SEXP x ) {
7:
8: if (ISNAN(asReal(x))) {
9: Rprintf("Hello");
10: }
11: return R_NilValue;
12:
13: warning("your C program does not return anything!");
14: return R_NilValue;
15: }
Thank you
Best regards,
Morgan
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Getting two independent packages with identical S3 generics to dispatch each other's methods
Dear All,
I would like to have two packages that do not depend on each other that
have an identical generic to be able to dispatch to each other's (non-
conflicting) methods. If it is of interest, the background for why this
is needed is given at the end of this e-mail.
As it is, it looks like two packages that do not depend on each other
both define a generic, they do not see each other's S3 methods.
For example, in the two attached minimal packages, which define and
export generic foo() (identical in both packages) and methods
foo.character() and foo.numeric() that are exported via S3method(), we
get,
> library(test.character)
> foo("a")
foo.character() called.
> library(test.numeric)
Attaching package: ‘test.numeric’
The following object is masked from ‘package:test.character’:
foo
> foo(1)
foo.numeric() called.
> foo("a")
Error in UseMethod("foo") :
no applicable method for 'foo' applied to an object of class "character"
That is, test.numeric::foo() doesn't "see"
test.character:::foo.character() and vice versa. Is there a way to make
them see each other?
This issue has arisen before, e.g. at
https://stackoverflow.com/questions/25251136/how-to-conditionally-define-a-generic-function-in-r-namespace
.
The "clean" solution is, of course, to create a third package to define
the generic that the two packages could import (and, if necessary,
reexport). However, that involves creating an almost-empty package that
then has to be submitted to CRAN, maintained, and add some amount of
storage and computational overhead. Is there another way to do this
that is transparent to the end user?
# Background
This arose as a result of two packages (lme4 and ergm) both wanting to
implement a simulate.formula() method, causing conflicts when the user
wanted to use both at the same time.
ergm has a mechanism for dispatching based on the class of the LHS of
the formula. It does so by defining a generic, simulate_formula() which
evaluates the formula's LHS and dispatches a method (e.g.,
simulate_formula.()) based on that.
Since lme4 and ergm generally use different LHSs, we are thinking of
resolving the conflict by copying the LHS dispatching mechanism from
ergm to lme4, and then defining our own summary_formula methods as
needed.
Thank you in advance,
Pavel
test.character_1.0.tar.gz
Description: application/compressed-tar
test.numeric_1.0.tar.gz
Description: application/compressed-tar
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Getting two independent packages with identical S3 generics to dispatch each other's methods
Perhaps:
https://cran.r-project.org/web/packages/generics/index.html
On July 10, 2020 4:51:52 PM PDT, "Pavel N. Krivitsky"
wrote:
>Dear All,
>
>I would like to have two packages that do not depend on each other that
>have an identical generic to be able to dispatch to each other's (non-
>conflicting) methods. If it is of interest, the background for why this
>is needed is given at the end of this e-mail.
>
>As it is, it looks like two packages that do not depend on each other
>both define a generic, they do not see each other's S3 methods.
>
>For example, in the two attached minimal packages, which define and
>export generic foo() (identical in both packages) and methods
>foo.character() and foo.numeric() that are exported via S3method(), we
>get,
>
>> library(test.character)
>> foo("a")
>foo.character() called.
>> library(test.numeric)
>Attaching package: ‘test.numeric’
>The following object is masked from ‘package:test.character’:
>foo
>> foo(1)
>foo.numeric() called.
>> foo("a")
>Error in UseMethod("foo") :
>no applicable method for 'foo' applied to an object of class
>"character"
>
>That is, test.numeric::foo() doesn't "see"
>test.character:::foo.character() and vice versa. Is there a way to make
>them see each other?
>
>This issue has arisen before, e.g. at
>https://stackoverflow.com/questions/25251136/how-to-conditionally-define-a-generic-function-in-r-namespace
>.
>
>The "clean" solution is, of course, to create a third package to define
>the generic that the two packages could import (and, if necessary,
>reexport). However, that involves creating an almost-empty package that
>then has to be submitted to CRAN, maintained, and add some amount of
>storage and computational overhead. Is there another way to do this
>that is transparent to the end user?
>
>
># Background
>
>This arose as a result of two packages (lme4 and ergm) both wanting to
>implement a simulate.formula() method, causing conflicts when the user
>wanted to use both at the same time.
>
>ergm has a mechanism for dispatching based on the class of the LHS of
>the formula. It does so by defining a generic, simulate_formula() which
>evaluates the formula's LHS and dispatches a method (e.g.,
>simulate_formula.()) based on that.
>
>Since lme4 and ergm generally use different LHSs, we are thinking of
>resolving the conflict by copying the LHS dispatching mechanism from
>ergm to lme4, and then defining our own summary_formula methods as
>needed.
>
> Thank you in advance,
> Pavel
--
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
Re: [R-pkg-devel] Getting two independent packages with identical S3 generics to dispatch each other's methods
Hi Pavel,
I asked essentially the same question a few weeks ago:
https://stat.ethz.ch/pipermail/r-package-devel/2020q2/005609.html
As Jeff already suggested, there is the generics package which might be of use.
Aside from this, I wasn't able to distill a workable solution from the
discussion that did not involve adding dependencies to (one of) the two
packages.
Best,
Wolfgang
On July 11, 2020 1:51:52 AM GMT+02:00, "Pavel N. Krivitsky"
wrote:
>Dear All,
>
>I would like to have two packages that do not depend on each other that
>have an identical generic to be able to dispatch to each other's (non-
>conflicting) methods. If it is of interest, the background for why this
>is needed is given at the end of this e-mail.
>
>As it is, it looks like two packages that do not depend on each other
>both define a generic, they do not see each other's S3 methods.
>
>For example, in the two attached minimal packages, which define and
>export generic foo() (identical in both packages) and methods
>foo.character() and foo.numeric() that are exported via S3method(), we
>get,
>
>> library(test.character)
>> foo("a")
>foo.character() called.
>> library(test.numeric)
>Attaching package: ‘test.numeric’
>The following object is masked from ‘package:test.character’:
>foo
>> foo(1)
>foo.numeric() called.
>> foo("a")
>Error in UseMethod("foo") :
>no applicable method for 'foo' applied to an object of class
>"character"
>
>That is, test.numeric::foo() doesn't "see"
>test.character:::foo.character() and vice versa. Is there a way to make
>them see each other?
>
>This issue has arisen before, e.g. at
>https://stackoverflow.com/questions/25251136/how-to-conditionally-define-a-generic-function-in-r-namespace
>.
>
>The "clean" solution is, of course, to create a third package to define
>the generic that the two packages could import (and, if necessary,
>reexport). However, that involves creating an almost-empty package that
>then has to be submitted to CRAN, maintained, and add some amount of
>storage and computational overhead. Is there another way to do this
>that is transparent to the end user?
>
>
># Background
>
>This arose as a result of two packages (lme4 and ergm) both wanting to
>implement a simulate.formula() method, causing conflicts when the user
>wanted to use both at the same time.
>
>ergm has a mechanism for dispatching based on the class of the LHS of
>the formula. It does so by defining a generic, simulate_formula() which
>evaluates the formula's LHS and dispatches a method (e.g.,
>simulate_formula.()) based on that.
>
>Since lme4 and ergm generally use different LHSs, we are thinking of
>resolving the conflict by copying the LHS dispatching mechanism from
>ergm to lme4, and then defining our own summary_formula methods as
>needed.
>
> Thank you in advance,
> Pavel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
