Re: [R-pkg-devel] Solaris SPARC, Fortran, and logical errors?
On 15.03.2017 18:30, Ben Bolker wrote:
On 17-03-15 11:09 AM, J C Nash wrote:
Possibly tangential, but has there been any effort to set up a Sparc
testbed? It
seems we could use a network-available (virtual?) machine, since this
platform is
often the unfortunate one. Unless, of course, there's a sunset date.
For information, I mentioned SPARC at our local linux group, and
apparently there
are a couple of folk who have them running, but I didn't find out the
state of the
OS etc.
JN
The virtual machine platforms I know of (admittedly not a complete
list!) only support Solaris on x86, e.g.
Yes, you cannot emulate a Sparc in an efficient way on an amd64 platform.
I take the opportunity to repeat why testing on *Sparc Solaris* gives
many benefits:
- this way we cover big- and little-endian platforms (i.e. for future
stability so that it works on what appear to be still esoteric such as
ARM based architectures or so)
- we cover one of the commercial unixes, i.e. we see
+ how stuff works on the the typically rather old toolchains
+ and what happens in on gnu/gcc-setups and how much GNUisms are used
Best,
Uwe Ligges
https://community.oracle.com/thread/2569292
On 2017-03-15 10:40 AM, Avraham Adler wrote:
Hello.
The Delaporte package works properly on all R-core platforms except
Solaris SPARC, where it compiles properly but fails a number of its
tests [1]. Not having access to a SPARC testbed, I'm limited in what
kind of diagnostics I can do. One thing I have noticed is that a lot
of the failures occur when I am passing non-default logicals (like
lower tail or log). For example, the first failure at that link is
when "log = true" is supposed to be passed, but the SPARC answers are
the unlogged values. Of the 22 failed tests, 12 of them pass logicals.
I'll bring an example of how it is coded below, and if anyone
recognizes where SPARC specifically goes wrong, I'd appreciate. I
guess, if I absolutely had to, I could convert the logical to an
integer in C and pass the integer to Fortran which should work even
for SPARC, but I'd prefer not to if I could help it.
Thank you,
Avi
[1] https://cran.r-project.org/web/checks/check_results_Delaporte.html
*Example Code*
R code:
ddelap <- function(x, alpha, beta, lambda, log = FALSE){
if(!is.double(x)) {storage.mode(x) <- 'double'}
if(!is.double(alpha)) {storage.mode(alpha) <- 'double'}
if(!is.double(beta)) {storage.mode(beta) <- 'double'}
if(!is.double(lambda)) {storage.mode(lambda) <- 'double'}
if(any(x > floor(x))) {
warning("Non-integers passed to ddelap. These will have 0
probability.")
}
.Call(ddelap_C, x, alpha, beta, lambda, log)
}
C code:
void ddelap_f(double *x, int nx, double *a, int na, double *b, int nb,
double *l, int nl,
int *lg, double *ret);
extern SEXP ddelap_C(SEXP x, SEXP alpha, SEXP beta, SEXP lambda, SEXP
lg){
const int nx = LENGTH(x);
const int na = LENGTH(alpha);
const int nb = LENGTH(beta);
const int nl = LENGTH(lambda);
SEXP ret;
PROTECT(ret = allocVector(REALSXP, nx));
ddelap_f(REAL(x), nx, REAL(alpha), na, REAL(beta), nb, REAL(lambda),
nl, LOGICAL(lg), REAL(ret));
UNPROTECT(1);
return(ret);
}
Fortran: (not posting ddelap_f_s as that doesn't handle the logging)
subroutine ddelap_f(x, nx, a, na, b, nb, l, nl, lg, pmfv) bind(C,
name="ddelap_f")
integer(kind = c_int), intent(in), value :: nx, na, nb, nl
! Sizes
real(kind = c_double), intent(in), dimension(nx) :: x
! Observations
real(kind = c_double), intent(out), dimension(nx):: pmfv
! Result
real(kind = c_double), intent(in):: a(na), b(nb),
l(nl)! Parameters
logical(kind = c_bool), intent(in) :: lg
! Log flag
integer :: i
! Integer
!$omp parallel do default(shared) private(i)
do i = 1, nx
if (x(i) > floor(x(i))) then
pmfv(i) = ZERO
else
pmfv(i) = ddelap_f_s(x(i), a(mod(i - 1, na) + 1), &
b(mod(i - 1, nb) + 1), l(mod(i -
1, nl) + 1))
end if
end do
!$omp end parallel do
if (lg) then
pmfv = log(pmfv)
end if
end subroutine ddelap_f
__
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
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Solaris SPARC, Fortran, and logical errors?
I completely agree that testing on SPARC Solaris is valuable, however
much of a nuisance it is. But I also agree that it would be great if
we could find a way to provide a publicly accessible SPARC Solaris
testing framework.
On Thu, Mar 16, 2017 at 6:49 AM, Uwe Ligges
wrote:
>
>
> On 15.03.2017 18:30, Ben Bolker wrote:
>>
>>
>>
>> On 17-03-15 11:09 AM, J C Nash wrote:
>>>
>>> Possibly tangential, but has there been any effort to set up a Sparc
>>> testbed? It
>>> seems we could use a network-available (virtual?) machine, since this
>>> platform is
>>> often the unfortunate one. Unless, of course, there's a sunset date.
>>>
>>> For information, I mentioned SPARC at our local linux group, and
>>> apparently there
>>> are a couple of folk who have them running, but I didn't find out the
>>> state of the
>>> OS etc.
>>>
>>> JN
>>
>>
>> The virtual machine platforms I know of (admittedly not a complete
>> list!) only support Solaris on x86, e.g.
>
>
> Yes, you cannot emulate a Sparc in an efficient way on an amd64 platform.
>
> I take the opportunity to repeat why testing on *Sparc Solaris* gives many
> benefits:
>
> - this way we cover big- and little-endian platforms (i.e. for future
> stability so that it works on what appear to be still esoteric such as ARM
> based architectures or so)
> - we cover one of the commercial unixes, i.e. we see
> + how stuff works on the the typically rather old toolchains
> + and what happens in on gnu/gcc-setups and how much GNUisms are used
>
> Best,
> Uwe Ligges
>
>
>
>>
>> https://community.oracle.com/thread/2569292
>>
>>
>>
>>>
>>>
>>> On 2017-03-15 10:40 AM, Avraham Adler wrote:
Hello.
The Delaporte package works properly on all R-core platforms except
Solaris SPARC, where it compiles properly but fails a number of its
tests [1]. Not having access to a SPARC testbed, I'm limited in what
kind of diagnostics I can do. One thing I have noticed is that a lot
of the failures occur when I am passing non-default logicals (like
lower tail or log). For example, the first failure at that link is
when "log = true" is supposed to be passed, but the SPARC answers are
the unlogged values. Of the 22 failed tests, 12 of them pass logicals.
I'll bring an example of how it is coded below, and if anyone
recognizes where SPARC specifically goes wrong, I'd appreciate. I
guess, if I absolutely had to, I could convert the logical to an
integer in C and pass the integer to Fortran which should work even
for SPARC, but I'd prefer not to if I could help it.
Thank you,
Avi
[1] https://cran.r-project.org/web/checks/check_results_Delaporte.html
*Example Code*
R code:
ddelap <- function(x, alpha, beta, lambda, log = FALSE){
if(!is.double(x)) {storage.mode(x) <- 'double'}
if(!is.double(alpha)) {storage.mode(alpha) <- 'double'}
if(!is.double(beta)) {storage.mode(beta) <- 'double'}
if(!is.double(lambda)) {storage.mode(lambda) <- 'double'}
if(any(x > floor(x))) {
warning("Non-integers passed to ddelap. These will have 0
probability.")
}
.Call(ddelap_C, x, alpha, beta, lambda, log)
}
C code:
void ddelap_f(double *x, int nx, double *a, int na, double *b, int nb,
double *l, int nl,
int *lg, double *ret);
extern SEXP ddelap_C(SEXP x, SEXP alpha, SEXP beta, SEXP lambda, SEXP
lg){
const int nx = LENGTH(x);
const int na = LENGTH(alpha);
const int nb = LENGTH(beta);
const int nl = LENGTH(lambda);
SEXP ret;
PROTECT(ret = allocVector(REALSXP, nx));
ddelap_f(REAL(x), nx, REAL(alpha), na, REAL(beta), nb, REAL(lambda),
nl, LOGICAL(lg), REAL(ret));
UNPROTECT(1);
return(ret);
}
Fortran: (not posting ddelap_f_s as that doesn't handle the logging)
subroutine ddelap_f(x, nx, a, na, b, nb, l, nl, lg, pmfv) bind(C,
name="ddelap_f")
integer(kind = c_int), intent(in), value :: nx, na, nb, nl
! Sizes
real(kind = c_double), intent(in), dimension(nx) :: x
! Observations
real(kind = c_double), intent(out), dimension(nx):: pmfv
! Result
real(kind = c_double), intent(in):: a(na), b(nb),
l(nl)! Parameters
logical(kind = c_bool), intent(in) :: lg
! Log flag
integer :: i
! Integer
!$omp parallel do default(shared) private(i)
do i = 1, nx
if (x(i) > floor(x(i))) then
pmfv(i) = ZERO
else
pmfv(i) = ddelap_f_s(x(i), a(mod(i - 1, na) + 1), &
b(mod(i - 1, nb) + 1), l(mod(i -
1, nl) + 1))
end if
Re: [R-pkg-devel] Solaris SPARC, Fortran, and logical errors?
FWIW it appears that QEMU has an admittedly slow implementation that supports
some architectures beyond x86/amd64 and that there is recent activity. See
http://wiki.qemu-project.org/Documentation/Platforms/SPARC
An alternative might be to persuade Oracle to provide a Sparc-builder, since
they
advertise Oracle R Technologies at
http://www.oracle.com/technetwork/database/database-technologies/r/r-technologies/r-offerings-1566363.html
but dates on that page are from 2014. Perhaps someone has contacts at Oracle
and could at least raise
the possibility.
JN
On 2017-03-16 08:20 AM, Ben Bolker wrote:
I completely agree that testing on SPARC Solaris is valuable, however
much of a nuisance it is. But I also agree that it would be great if
we could find a way to provide a publicly accessible SPARC Solaris
testing framework.
On Thu, Mar 16, 2017 at 6:49 AM, Uwe Ligges
wrote:
On 15.03.2017 18:30, Ben Bolker wrote:
On 17-03-15 11:09 AM, J C Nash wrote:
Possibly tangential, but has there been any effort to set up a Sparc
testbed? It
seems we could use a network-available (virtual?) machine, since this
platform is
often the unfortunate one. Unless, of course, there's a sunset date.
For information, I mentioned SPARC at our local linux group, and
apparently there
are a couple of folk who have them running, but I didn't find out the
state of the
OS etc.
JN
The virtual machine platforms I know of (admittedly not a complete
list!) only support Solaris on x86, e.g.
Yes, you cannot emulate a Sparc in an efficient way on an amd64 platform.
I take the opportunity to repeat why testing on *Sparc Solaris* gives many
benefits:
- this way we cover big- and little-endian platforms (i.e. for future
stability so that it works on what appear to be still esoteric such as ARM
based architectures or so)
- we cover one of the commercial unixes, i.e. we see
+ how stuff works on the the typically rather old toolchains
+ and what happens in on gnu/gcc-setups and how much GNUisms are used
Best,
Uwe Ligges
https://community.oracle.com/thread/2569292
On 2017-03-15 10:40 AM, Avraham Adler wrote:
Hello.
The Delaporte package works properly on all R-core platforms except
Solaris SPARC, where it compiles properly but fails a number of its
tests [1]. Not having access to a SPARC testbed, I'm limited in what
kind of diagnostics I can do. One thing I have noticed is that a lot
of the failures occur when I am passing non-default logicals (like
lower tail or log). For example, the first failure at that link is
when "log = true" is supposed to be passed, but the SPARC answers are
the unlogged values. Of the 22 failed tests, 12 of them pass logicals.
I'll bring an example of how it is coded below, and if anyone
recognizes where SPARC specifically goes wrong, I'd appreciate. I
guess, if I absolutely had to, I could convert the logical to an
integer in C and pass the integer to Fortran which should work even
for SPARC, but I'd prefer not to if I could help it.
Thank you,
Avi
[1] https://cran.r-project.org/web/checks/check_results_Delaporte.html
*Example Code*
R code:
ddelap <- function(x, alpha, beta, lambda, log = FALSE){
if(!is.double(x)) {storage.mode(x) <- 'double'}
if(!is.double(alpha)) {storage.mode(alpha) <- 'double'}
if(!is.double(beta)) {storage.mode(beta) <- 'double'}
if(!is.double(lambda)) {storage.mode(lambda) <- 'double'}
if(any(x > floor(x))) {
warning("Non-integers passed to ddelap. These will have 0
probability.")
}
.Call(ddelap_C, x, alpha, beta, lambda, log)
}
C code:
void ddelap_f(double *x, int nx, double *a, int na, double *b, int nb,
double *l, int nl,
int *lg, double *ret);
extern SEXP ddelap_C(SEXP x, SEXP alpha, SEXP beta, SEXP lambda, SEXP
lg){
const int nx = LENGTH(x);
const int na = LENGTH(alpha);
const int nb = LENGTH(beta);
const int nl = LENGTH(lambda);
SEXP ret;
PROTECT(ret = allocVector(REALSXP, nx));
ddelap_f(REAL(x), nx, REAL(alpha), na, REAL(beta), nb, REAL(lambda),
nl, LOGICAL(lg), REAL(ret));
UNPROTECT(1);
return(ret);
}
Fortran: (not posting ddelap_f_s as that doesn't handle the logging)
subroutine ddelap_f(x, nx, a, na, b, nb, l, nl, lg, pmfv) bind(C,
name="ddelap_f")
integer(kind = c_int), intent(in), value :: nx, na, nb, nl
! Sizes
real(kind = c_double), intent(in), dimension(nx) :: x
! Observations
real(kind = c_double), intent(out), dimension(nx):: pmfv
! Result
real(kind = c_double), intent(in):: a(na), b(nb),
l(nl)! Parameters
logical(kind = c_bool), intent(in) :: lg
! Log flag
integer :: i
! Integer
!$omp parallel do default(shared) private(i)
do i = 1, nx
if (x(i) > floor(x(i))) then
pmfv(i) = ZERO
else
pmfv(i) = ddelap_f_s(x(i), a(mod(i - 1, na) + 1), &
b(
[R-pkg-devel] Windows specific compiler for CUDA builds
Greetings, Not sure if this should be on the Rcpp list but it isn't strictly related to Rcpp but to package building involving Rcpp so I am posting it here. I am often working on GPU packages that use either OpenCL or CUDA. OpenCL is nice because it doesn't require a special additional compiler and I can build it across platforms with relative ease. With CUDA, it requires the 'nvcc' compiler. This is where my problem comes in. On Windows the 'nvcc' requires the use of the 'cl' compiler within Visual Studio and the resulting object files, AFAIK, cannot be linked to object files created by g++ (via Rtools). Everything works great on Linux (where the same compiler is used for everything) but on a Windows system this is causing a lot of headaches. So, at the moment, my conclusion is that it is simply not possible to build a CUDA package that can be installed on a Windows system. To my knowledge, no CUDA based R package has a Windows installation functional (please state otherwise if I am wrong). My only thought would be if it would be possible to have the Windows build use 'cl' for the entire build process. Perhaps that would allow all the files to be linked together and create the necessary shared object at the end? Obviously the preference is to use Rtools but until NVIDIA updates their special compiler to support MinGW tools I don't think that is possible. Any insight would be appreciated, Charles [[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] Windows specific compiler for CUDA builds
On 16/03/2017 11:00 AM, Charles Determan wrote: Greetings, Not sure if this should be on the Rcpp list but it isn't strictly related to Rcpp but to package building involving Rcpp so I am posting it here. I am often working on GPU packages that use either OpenCL or CUDA. OpenCL is nice because it doesn't require a special additional compiler and I can build it across platforms with relative ease. With CUDA, it requires the 'nvcc' compiler. This is where my problem comes in. On Windows the 'nvcc' requires the use of the 'cl' compiler within Visual Studio and the resulting object files, AFAIK, cannot be linked to object files created by g++ (via Rtools). Everything works great on Linux (where the same compiler is used for everything) but on a Windows system this is causing a lot of headaches. So, at the moment, my conclusion is that it is simply not possible to build a CUDA package that can be installed on a Windows system. To my knowledge, no CUDA based R package has a Windows installation functional (please state otherwise if I am wrong). My only thought would be if it would be possible to have the Windows build use 'cl' for the entire build process. Perhaps that would allow all the files to be linked together and create the necessary shared object at the end? Obviously the preference is to use Rtools but until NVIDIA updates their special compiler to support MinGW tools I don't think that is possible. In principle it should be possible to use cl. In practice, it will require someone to work out the details of doing it and to maintain it (by testing R-devel regularly to make sure changes there don't cause trouble for it). There aren't a lot of people who know how to do that (e.g. I don't). If you are willing to volunteer to do this (or can recruit someone to do it), go ahead. Assuming you do a good job, we can put your patches into the base code. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Windows specific compiler for CUDA builds
Thanks Duncan, You say there aren't a lot of people that no how to do that. Do you know of anyone who would? I assume Dirk would be a likely person given the use of Rtools with Rcpp. I am happy to try and work at this as I have a vested interest in getting CUDA packages to become functional on Windows systems but I need somewhere to begin. Basically I'm just looking how to switch out the MinGW g++ with the VS cl compiler. On a Linux system I can create a .R/Makevars file to switch the CXX variable but I don't know how on Windows. Charles On Thu, Mar 16, 2017 at 10:41 AM, Duncan Murdoch wrote: > On 16/03/2017 11:00 AM, Charles Determan wrote: > >> Greetings, >> >> Not sure if this should be on the Rcpp list but it isn't strictly related >> to Rcpp but to package building involving Rcpp so I am posting it here. >> >> I am often working on GPU packages that use either OpenCL or CUDA. OpenCL >> is nice because it doesn't require a special additional compiler and I can >> build it across platforms with relative ease. With CUDA, it requires the >> 'nvcc' compiler. This is where my problem comes in. On Windows the >> 'nvcc' >> requires the use of the 'cl' compiler within Visual Studio and the >> resulting object files, AFAIK, cannot be linked to object files created by >> g++ (via Rtools). Everything works great on Linux (where the same >> compiler >> is used for everything) but on a Windows system this is causing a lot of >> headaches. >> >> So, at the moment, my conclusion is that it is simply not possible to >> build >> a CUDA package that can be installed on a Windows system. To my >> knowledge, >> no CUDA based R package has a Windows installation functional (please >> state >> otherwise if I am wrong). >> >> My only thought would be if it would be possible to have the Windows build >> use 'cl' for the entire build process. Perhaps that would allow all the >> files to be linked together and create the necessary shared object at the >> end? Obviously the preference is to use Rtools but until NVIDIA updates >> their special compiler to support MinGW tools I don't think that is >> possible. >> > > In principle it should be possible to use cl. In practice, it will > require someone to work out the details of doing it and to maintain it (by > testing R-devel regularly to make sure changes there don't cause trouble > for it). There aren't a lot of people who know how to do that (e.g. I > don't). If you are willing to volunteer to do this (or can recruit someone > to do it), go ahead. Assuming you do a good job, we can put your patches > into the base code. > > Duncan Murdoch > > > > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] R CMD check warning about .inc files.
Dear All, Since some C header files in a package I maintain have identical macro definitions (which have a different meanings, since other macro definitions differ), I tried to reduce code duplication to split the common macros into their own files, which don't get #included directly by any C files. To give a minimal example, in the following two header files, BEGIN foo1.h #define BAR 1 #define BAZ(x) ((x)+BAR) END foo1.h BEGIN foo2.h #define BAR 2 #define BAZ(x) ((x)+BAR) END foo2.h BAZ() macro has redundant definition. I'd like to get rid of the code duplication with the following three files: BEGIN foo1.h #define BAR 1 #include "foo_common.inc" END foo1.h BEGIN foo2.h #define BAR 2 #include "foo_common.inc" END foo2.h BEGIN foo_common.inc #define BAZ(x) ((x)+BAR) END foo_common.inc However, I get an R CMD check warning of the form Subdirectory ‘src’ contains: foo_common.inc Is there a way to tell R CMD check that .inc files are OK? Or, should I use a different extension? I don't want to use .c, because those files only contain macros and not anything that compiles to object code, and I don't want to use .h, because these are not meant to be included as header files by any C code. Thank you in advance, Pavel -- Pavel Krivitsky Lecturer in Statistics National Institute of Applied Statistics Research Australia (NIASRA) School of Mathematics and Applied Statistics | Building 39C Room 154 University of Wollongong NSW 2522 Australia T +61 2 4221 3713 Web (NIASRA): http://niasra.uow.edu.au/index.html Web (Personal): http://www.krivitsky.net/research ORCID: -0002-9101-3362 NOTICE: This email is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Please consider the environment before printing this email. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD check warning about .inc files.
I different extension is fine I think. I use .pmt (poor man's templates) for something very similar. Gabor On Thu, Mar 16, 2017 at 9:11 PM, Pavel Krivitsky wrote: > Dear All, > > Since some C header files in a package I maintain have identical macro > definitions (which have a different meanings, since other macro > definitions differ), I tried to reduce code duplication to split the > common macros into their own files, which don't get #included directly > by any C files. To give a minimal example, in the following two header > files, > > BEGIN foo1.h > > #define BAR 1 > #define BAZ(x) ((x)+BAR) > > END foo1.h > > BEGIN foo2.h > > #define BAR 2 > #define BAZ(x) ((x)+BAR) > > END foo2.h > > BAZ() macro has redundant definition. I'd like to get rid of the code > duplication with the following three files: > > BEGIN foo1.h > > #define BAR 1 > #include "foo_common.inc" > > END foo1.h > > BEGIN foo2.h > > #define BAR 2 > #include "foo_common.inc" > > END foo2.h > > BEGIN foo_common.inc > > #define BAZ(x) ((x)+BAR) > > END foo_common.inc > > However, I get an R CMD check warning of the form > > Subdirectory ‘src’ contains: > foo_common.inc > > Is there a way to tell R CMD check that .inc files are OK? Or, should I > use a different extension? I don't want to use .c, because those files > only contain macros and not anything that compiles to object code, and > I don't want to use .h, because these are not meant to be included as > header files by any C code. > > Thank you in advance, > Pavel > > -- > Pavel Krivitsky > Lecturer in Statistics > National Institute of Applied Statistics Research Australia (NIASRA) > School of Mathematics and Applied Statistics | Building 39C Room 154 > University of Wollongong NSW 2522 Australia > T +61 2 4221 3713 > Web (NIASRA): http://niasra.uow.edu.au/index.html > Web (Personal): http://www.krivitsky.net/research > ORCID: -0002-9101-3362 > > NOTICE: This email is intended for the addressee named and may contain > confidential information. If you are not the intended recipient, please > delete it and notify the sender. Please consider the environment before > printing this email. > __ > 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] R CMD check warning about .inc files.
On Thu, 2017-03-16 at 21:31 +, Gábor Csárdi wrote: > I different extension is fine I think. I use .pmt (poor man's > templates) for something very similar. No, both .pmt and .inc produce an R CMD check warning. (The package itself compiles correctly in either case.) Pavel > > Gabor > > On Thu, Mar 16, 2017 at 9:11 PM, Pavel Krivitsky > wrote: > > Dear All, > > > > Since some C header files in a package I maintain have identical > > macro > > definitions (which have a different meanings, since other macro > > definitions differ), I tried to reduce code duplication to split > > the > > common macros into their own files, which don't get #included > > directly > > by any C files. To give a minimal example, in the following two > > header > > files, > > > > BEGIN foo1.h > > > > #define BAR 1 > > #define BAZ(x) ((x)+BAR) > > > > END foo1.h > > > > BEGIN foo2.h > > > > #define BAR 2 > > #define BAZ(x) ((x)+BAR) > > > > END foo2.h > > > > BAZ() macro has redundant definition. I'd like to get rid of the > > code > > duplication with the following three files: > > > > BEGIN foo1.h > > > > #define BAR 1 > > #include "foo_common.inc" > > > > END foo1.h > > > > BEGIN foo2.h > > > > #define BAR 2 > > #include "foo_common.inc" > > > > END foo2.h > > > > BEGIN foo_common.inc > > > > #define BAZ(x) ((x)+BAR) > > > > END foo_common.inc > > > > However, I get an R CMD check warning of the form > > > > Subdirectory ‘src’ contains: > > foo_common.inc > > > > Is there a way to tell R CMD check that .inc files are OK? Or, > > should I > > use a different extension? I don't want to use .c, because those > > files > > only contain macros and not anything that compiles to object code, > > and > > I don't want to use .h, because these are not meant to be included > > as > > header files by any C code. > > > > Thank you in advance, > > Pavel > > > > -- > > Pavel Krivitsky > > Lecturer in Statistics > > National Institute of Applied Statistics Research Australia > > (NIASRA) > > School of Mathematics and Applied Statistics | Building 39C Room > > 154 > > University of Wollongong NSW 2522 Australia > > T +61 2 4221 3713 > > Web (NIASRA): http://niasra.uow.edu.au/index.html > > Web (Personal): http://www.krivitsky.net/research > > ORCID: -0002-9101-3362 > > > > NOTICE: This email is intended for the addressee named and may > > contain > > confidential information. If you are not the intended recipient, > > please > > delete it and notify the sender. Please consider the environment > > before > > printing this email. > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > -- Pavel Krivitsky Lecturer in Statistics National Institute of Applied Statistics Research Australia (NIASRA) School of Mathematics and Applied Statistics | Building 39C Room 154 University of Wollongong NSW 2522 Australia T +61 2 4221 3713 Web (NIASRA): http://niasra.uow.edu.au/index.html Web (Personal): http://www.krivitsky.net/research ORCID: -0002-9101-3362 NOTICE: This email is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Please consider the environment before printing this email. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD check warning about .inc files.
On Thu, Mar 16, 2017 at 10:12 PM, Pavel Krivitsky wrote: > On Thu, 2017-03-16 at 21:31 +, Gábor Csárdi wrote: >> I different extension is fine I think. I use .pmt (poor man's >> templates) for something very similar. > > No, both .pmt and .inc produce an R CMD check warning. (The package > itself compiles correctly in either case.) Interesting. Where are these files? igraph has had .pmt files in src/ for >10 years, and I never had any problems with them. They do not show up in recent checks, either: https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/igraph-00check.html Maybe you have them in a different directory? Gabor [...] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
