date:20190913

Re: [R-pkg-devel] Number of cores in examples

2019-09-13 Thread Uwe Ligges





On 14.09.2019 03:33, John Harrold wrote:

Hello,

I recently submitted a package for consideration in CRAN. One of the
comments was:

Please ensure that you do not use more than 2 cores in your examples.

I do not believe my package does this. Is this a general comment for a
package that requires doParallel or was this triggered because one of my
examples actually used more than 2 cores?


The latter. In examples, vignettes and tests you must not start more 
than 2 workers as resources for CRAN checks are limited.


Best,
Uwe Ligges




Thanks
John



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

[R-pkg-devel] Number of cores in examples

2019-09-13 Thread John Harrold

Hello,

I recently submitted a package for consideration in CRAN. One of the
comments was:

Please ensure that you do not use more than 2 cores in your examples.

I do not believe my package does this. Is this a general comment for a
package that requires doParallel or was this triggered because one of my
examples actually used more than 2 cores?

Thanks
John
-- 
John
:wq

[[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] How reproduce CRAN check

2019-09-13 Thread Iñaki Ucar

On Fri, 13 Sep 2019 at 16:16, Cristiane Hayumi Taniguti
 wrote:
>
> ...twopts_f2.cpp:101:7: runtime error: nan is
> outside the range of representable values of type 'int'
> onemap.Rcheck/onemap-Ex.Rout:twopts_f2.cpp:101:26: runtime error: nan is
> outside the range of representable values of type 'int'

Here: 
https://github.com/augusto-garcia/onemap/blob/master/src/twopts_f2.cpp#L101
-> k1=segreg_type(i); k2=segreg_type(j);

k1 and k2 are vectors of integers, but segreg_type is a NumericVector
(double), which may contain NaN.

Iñaki

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

Re: [R-pkg-devel] How reproduce CRAN check

2019-09-13 Thread Henrik Bengtsson

As first step of being able to reproduce the error, have a look at
R-Hub (https://blog.r-hub.io/2019/03/26/why-care/).  It'll allow you
to use their servers to test your package on many different
configurations.  It helped me several times. You can launch it all
from you local R prompt, e.g.

> rhub::check()

── Choose build platform

 1: Debian Linux, R-devel, clang, ISO-8859-15 locale (debian-clang-devel)
 2: Debian Linux, R-devel, GCC (debian-gcc-devel)
 3: Debian Linux, R-devel, GCC, no long double (debian-gcc-devel-nold)
 4: Debian Linux, R-patched, GCC (debian-gcc-patched)
 5: Debian Linux, R-release, GCC (debian-gcc-release)
 6: Fedora Linux, R-devel, clang, gfortran (fedora-clang-devel)
 7: Fedora Linux, R-devel, GCC (fedora-gcc-devel)
 8: CentOS 6, stock R from EPEL (linux-x86_64-centos6-epel)
 9: CentOS 6 with Redhat Developer Toolset, R from EPEL
(linux-x86_64-centos6-epel-rdt)
10: Debian Linux, R-devel, GCC ASAN/UBSAN (linux-x86_64-rocker-gcc-san)
11: macOS 10.11 El Capitan, R-release (experimental) (macos-elcapitan-release)
12: Oracle Solaris 10, x86, 32 bit, R-patched (experimental)
(solaris-x86-patched)
13: Ubuntu Linux 16.04 LTS, R-devel, GCC (ubuntu-gcc-devel)
14: Ubuntu Linux 16.04 LTS, R-release, GCC (ubuntu-gcc-release)
15: Ubuntu Linux 16.04 LTS, R-devel with rchk (ubuntu-rchk)
16: Windows Server 2008 R2 SP1, R-devel, 32/64 bit (windows-x86_64-devel)
17: Windows Server 2012, R-devel, Rtools4.0, 32/64 bit (experimental)
(windows-x86_64-devel-rtools4)
18: Windows Server 2008 R2 SP1, R-oldrel, 32/64 bit (windows-x86_64-oldrel)
19: Windows Server 2008 R2 SP1, R-patched, 32/64 bit (windows-x86_64-patched)
20: Windows Server 2008 R2 SP1, R-release, 32/64 bit (windows-x86_64-release)

Selection: 10

/Henrik

PS. "Google Drive"; the sooner you migrate to Git and an online Git
repos (GitHub, Gitlab, Bitbucket, ...) the sooner you'll thank
yourself for doing so and saving yourself lots of time. The world of
continuous integration (read "automagic instant R CMD check on Linux,
macOS, WIndows - for free in the cloud") will also open up to you.

On Fri, Sep 13, 2019 at 7:15 AM Cristiane Hayumi Taniguti
 wrote:
>
> I'm having difficulties updating my package onemap: When I run standard
> checks as --as-cran in linux, winbuilder and using docker images everything
> is fine, but 'CRAN-submissions' reports this problem in my c++ code:
>
> onemap.Rcheck/onemap-Ex.Rout:
> .../usr/local/bin/../include/c++/v1/memory:1825:35: runtime
> error: nan is outside the range of representable values of type 'int'
> onemap.Rcheck/onemap-Ex.Rout:twopts_out.cpp:147:7: runtime error: nan is
> outside the range of representable values of type 'int'
> onemap.Rcheck/onemap-Ex.Rout:twopts_out.cpp:147:26: runtime error: nan
> is outside the range of representable values of type 'int'
> onemap.Rcheck/onemap-Ex.Rout:
> ...twopts_f2.cpp:101:7: runtime error: nan is
> outside the range of representable values of type 'int'
> onemap.Rcheck/onemap-Ex.Rout:twopts_f2.cpp:101:26: runtime error: nan is
> outside the range of representable values of type 'int'
>
> This problem was there in the last CRAN version of my package too  <
> https://www.stats.ox.ac.uk/pub/bdr/memtests/clang-UBSAN/onemap>
>
> I am having a hard time trying to reproduce this error "at home" and fix
> the problem. Without reproduce this I am not able to find what is causing
> the nan in my code.
>
> Here  is
> the new version source package
>
> Any help is much appreciated.
>
> Cris
>
> [[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

Re: [R-pkg-devel] How reproduce CRAN check

2019-09-13 Thread Duncan Murdoch


On 13/09/2019 10:15 a.m., Cristiane Hayumi Taniguti wrote:

I'm having difficulties updating my package onemap: When I run standard
checks as --as-cran in linux, winbuilder and using docker images everything
is fine, but 'CRAN-submissions' reports this problem in my c++ code:

onemap.Rcheck/onemap-Ex.Rout:
.../usr/local/bin/../include/c++/v1/memory:1825:35: runtime
error: nan is outside the range of representable values of type 'int'
onemap.Rcheck/onemap-Ex.Rout:twopts_out.cpp:147:7: runtime error: nan is
outside the range of representable values of type 'int'
onemap.Rcheck/onemap-Ex.Rout:twopts_out.cpp:147:26: runtime error: nan
is outside the range of representable values of type 'int'
onemap.Rcheck/onemap-Ex.Rout:
...twopts_f2.cpp:101:7: runtime error: nan is
outside the range of representable values of type 'int'
onemap.Rcheck/onemap-Ex.Rout:twopts_f2.cpp:101:26: runtime error: nan is
outside the range of representable values of type 'int'

This problem was there in the last CRAN version of my package too  <
https://www.stats.ox.ac.uk/pub/bdr/memtests/clang-UBSAN/onemap>

I am having a hard time trying to reproduce this error "at home" and fix
the problem. Without reproduce this I am not able to find what is causing
the nan in my code.

Here  is
the new version source package


I would add some kind of Rprintf statement near line 101 of 
twopts_f2.cpp to show the value that you are apparently trying to coerce 
to int at that point.  Apparently it is sometimes equal to NaN, and this 
is being caught in the CRAN checks, but not in yours.  That might be 
because they are doing more stringent checks (UBSAN is very stringent), 
or it might be that the value is actually different on their system.


Duncan Murdoch

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

[R-pkg-devel] How reproduce CRAN check

2019-09-13 Thread Cristiane Hayumi Taniguti

I'm having difficulties updating my package onemap: When I run standard
checks as --as-cran in linux, winbuilder and using docker images everything
is fine, but 'CRAN-submissions' reports this problem in my c++ code:

onemap.Rcheck/onemap-Ex.Rout:
.../usr/local/bin/../include/c++/v1/memory:1825:35: runtime
error: nan is outside the range of representable values of type 'int'
onemap.Rcheck/onemap-Ex.Rout:twopts_out.cpp:147:7: runtime error: nan is
outside the range of representable values of type 'int'
onemap.Rcheck/onemap-Ex.Rout:twopts_out.cpp:147:26: runtime error: nan
is outside the range of representable values of type 'int'
onemap.Rcheck/onemap-Ex.Rout:
...twopts_f2.cpp:101:7: runtime error: nan is
outside the range of representable values of type 'int'
onemap.Rcheck/onemap-Ex.Rout:twopts_f2.cpp:101:26: runtime error: nan is
outside the range of representable values of type 'int'

This problem was there in the last CRAN version of my package too  <
https://www.stats.ox.ac.uk/pub/bdr/memtests/clang-UBSAN/onemap>

I am having a hard time trying to reproduce this error "at home" and fix
the problem. Without reproduce this I am not able to find what is causing
the nan in my code.

Here  is
the new version source package

Any help is much appreciated.

Cris

[[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] My test passes in OSx on Travis, but not in OSx on CRAN

2019-09-13 Thread Vincent van Hees

Thanks Tomas for your quick response, that sounds like a very plausible
explanation.
I will make those corrections and will start prepare a new release.
Best, Vincent



On Fri, 13 Sep 2019 at 13:30, Tomas Kalibera 
wrote:

> The error seems to be because you are trying to write to the user's home
> directory. This is not allowed. Probably by accident your test creates
> "~/testcsv4.csv" (the same problem is present for other test files).
>
> Best
> Tomas
>
> On 9/13/19 1:21 PM, Vincent van Hees wrote:
> > Dear all,
> >
> > I have a test in my R package that passes in OSx on Travis-CI, but it
> does
> > not pass in OSx on CRAN. What does pass on both CRAN and Travis are the
> > Linux tests. Also, on CRAN the Windows flavor passes. So, there seems to
> be
> > an issue specific to the combination OSx and CRAN.
> >
> > The easiest solution for me would be to add 'skip_on_cran()' at the top
> of
> > the test, but that would blind me for serious issues (if any). I already
> > made sure that the seeds are set before random number generators and that
> > value checks are limited to 3 decimal places to deal machine precision
> > issues. Does anyone have suggestions for me on what else I can do to
> > investigate this?
> >
> > Link
> > <
> https://github.com/wadpac/GGIR/blob/master/tests/testthat/test_read.myacc.csv.R
> >
> > to the specific test on GitHub. The function that is being tested first
> > creates dummy csv-files with random data and then checks that my wrapper
> > function around data.table() is able to read and interpret those dummy
> > files.
> > Link  to
> > CRAN results
> > Link  to Travis-CI page for the
> package
> >
> > I have a local Windows and Linux machine, but for OSx testing I depend on
> > Travis-CI.
> >
> > Thanks,
> > Vincent
> >
> >   [[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] My test passes in OSx on Travis, but not in OSx on CRAN

2019-09-13 Thread Tomas Kalibera

The error seems to be because you are trying to write to the user's home 
directory. This is not allowed. Probably by accident your test creates 
"~/testcsv4.csv" (the same problem is present for other test files).


Best
Tomas

On 9/13/19 1:21 PM, Vincent van Hees wrote:

Dear all,

I have a test in my R package that passes in OSx on Travis-CI, but it does
not pass in OSx on CRAN. What does pass on both CRAN and Travis are the
Linux tests. Also, on CRAN the Windows flavor passes. So, there seems to be
an issue specific to the combination OSx and CRAN.

The easiest solution for me would be to add 'skip_on_cran()' at the top of
the test, but that would blind me for serious issues (if any). I already
made sure that the seeds are set before random number generators and that
value checks are limited to 3 decimal places to deal machine precision
issues. Does anyone have suggestions for me on what else I can do to
investigate this?

Link

to the specific test on GitHub. The function that is being tested first
creates dummy csv-files with random data and then checks that my wrapper
function around data.table() is able to read and interpret those dummy
files.
Link  to
CRAN results
Link  to Travis-CI page for the package

I have a local Windows and Linux machine, but for OSx testing I depend on
Travis-CI.

Thanks,
Vincent

[[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-pkg-devel] My test passes in OSx on Travis, but not in OSx on CRAN

2019-09-13 Thread Vincent van Hees

Dear all,

I have a test in my R package that passes in OSx on Travis-CI, but it does
not pass in OSx on CRAN. What does pass on both CRAN and Travis are the
Linux tests. Also, on CRAN the Windows flavor passes. So, there seems to be
an issue specific to the combination OSx and CRAN.

The easiest solution for me would be to add 'skip_on_cran()' at the top of
the test, but that would blind me for serious issues (if any). I already
made sure that the seeds are set before random number generators and that
value checks are limited to 3 decimal places to deal machine precision
issues. Does anyone have suggestions for me on what else I can do to
investigate this?

Link

to the specific test on GitHub. The function that is being tested first
creates dummy csv-files with random data and then checks that my wrapper
function around data.table() is able to read and interpret those dummy
files.
Link  to
CRAN results
Link  to Travis-CI page for the package

I have a local Windows and Linux machine, but for OSx testing I depend on
Travis-CI.

Thanks,
Vincent

[[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, BLAS, and FCLEN (solved)

2019-09-13 Thread Göran Broström

Dear Tomas,

your explanation matches exactly my expectation, but not my experience. 
I uploaded (to CRAN) version 2.7.5 yesterday, and there I use, in  the 
Fortran function gmlfun, directly called by .Fortran:

  call cdgemv(trans, nn, antcov, one, covar, nn, beta, ione, one,
 & score, ione)

that is, the C wrapper of dgemv (my home-brew)

No warnings from R-devel CMD check --as-cran, and when installed it runs 
fine.

However, if I change that call to

   call dgemv(trans, nn, antcov, one, covar, nn, beta, ione, one,
 & score, ione)

that is, a direct call to the Fortran subroutine dgemv, I get, from 
R-devel CMD check --as-cran,

gmlfun.f:224:1: warning: type of ‘dgemv’ does not match original 
declaration [-Wlto-type-mismatch]

  & score, ione)
 ^
/home/gobr0002/R/src/R-devel/include/R_ext/BLAS.h:107:1: note: type 
mismatch in parameter 12

 F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
 ^

and when I install and run, I get error:

> library(eha)
Loading required package: survival
> fit <- coxreg(Surv(enter, exit, event) ~ ses, data = mort, geometric 
= TRUE)

Error in geome.fit(X, Y, rs, strats, offset, init, max.survs, method,  :
  BLAS/LAPACK routine 'DGEMV ' gave error code -1
>
> sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 19.04
...
Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.8.0
...
Other attached packages:
[1] eha_2.7.5.1000survival_2.44-1.1
-

To summarize: The calls from C code are fixed and work fine. Direct call 
from fortran "level 1" gives error, from "level 2" is fine. "level 1" is 
fortran code directly called by .Fortran, "level 2" is fortran code 
called from fortran code called by .Fortran.

This was done with

R Under development (unstable) (2019-08-31 r77115). I could try a more 
recent version of R-devel.

About a 'small reproducible example': It is not that easy to shrink the 
eha package to include only the relevant fortran code, since there are 
subtle interdependencies in the package code. It would take a 
considerable amount of time (for me) to create that package.

I can make eha_2.7.5.tar.gz available, but it was sent in to CRAN yesterday.

Göran

On 2019-09-13 11:07, Tomas Kalibera wrote:

Dear Göran,

I can reproduce the problem with eha version 2.6.0. The reason for the 
type mismatch, and hence the LTO warning, is _not_ the calls to dgemv 
from Fortran code, but the calls to dgemv from the C code from the other 
source files in your package. There is no need to go through wrappers 
when calling dgemv from Fortran (as long as both modules are compiled 
with the same compiler, or with compatible compilers).

When you fix all the calls to dgemv in your C source files to use 
"FCONE", as documented in WRE, the warning about the call to dgemv from 
geomsup.f will go away (yes, the warnings from the LTO linker/compiler 
are confusing). There is no need for creating any wrappers for 
BLAS/LAPACK calls.

One can check that the generated calls from the Fortran are correct e.g. 
via compiling with -fdump-tree-all and then dumping

$ egrep -e '(^;;)|(dgemv)' eha.so.ltrans0.232t.optimized | grep dgemv -B1
(the file name above will depend on the exact version of your compiler)

;; Function d2_loglik_ph (d2_loglik_ph, funcdef_no=77, decl_uid=4474, 
cgraph_uid=103, symbol_order=990)
   dgemv_ (, mb_497(D), nn_499(D), , z_502(D), mb_497(D), 
b_503(D), , _beta, ezb_501, );

--
;; Function d2_loglik_phexp (d2_loglik_phexp, funcdef_no=87, 
decl_uid=4470, cgraph_uid=100, symbol_order=1108)
   dgemv_ (, mb_253(D), nn_255(D), , z_258(D), mb_253(D), 
b_259(D), , _beta, ezb_257, );

--
;; Function gmlfun (gmlfun_, funcdef_no=98, decl_uid=4484, 
cgraph_uid=108, symbol_order=874)
   dgemv_ (&"N"[1]{lb: 1 sz: 1}, nn_68(D), antcov_63(D), , 
covar_83(D), nn_68(D), beta_84(D), , , score_81(D), 
, 1);

--
;; Function geomsup (geomsup_, funcdef_no=116, decl_uid=4498, 
cgraph_uid=117, symbol_order=823)
   dgemv_ (&"N"[1]{lb: 1 sz: 1}, nn_55(D), antcov_51(D), , 
covar_89(D), nn_55(D), startbeta_83(D), , , score_87(D), 
, 1);

--
;; Function sup (sup, funcdef_no=128, decl_uid=4335, cgraph_uid=7, 
symbol_order=1772)
   dgemv_ (, , , , covar_281(D), , beta_340(D), , 
, score_230, );

You can see that the calls to dgemv from gmlfun and geomsup are fine 
(from Fortran code), the other are bad (from C code).  Indeed, one would 
have found out also by creating a minimal reproducible example - it is 
always useful, even when not attempting to report a bug.

Best
Tomas

On 9/13/19 12:07 AM, Göran Broström wrote:

On 2019-09-12 09:13, Martin Maechler wrote:

Göran Broström
 on Wed, 11 Sep 2019 13:36:40 +0200 writes:

 > A followup question: Is it possible to call a BLAS/LAPACK 
subroutine,
 > where one parameter is character, from FORTRAN (77) code 
called by

 >

Re: [R-pkg-devel] R, BLAS, and FCLEN (solved)

2019-09-13 Thread Tomas Kalibera

Dear Göran,

I can reproduce the problem with eha version 2.6.0. The reason for the 
type mismatch, and hence the LTO warning, is _not_ the calls to dgemv 
from Fortran code, but the calls to dgemv from the C code from the other 
source files in your package. There is no need to go through wrappers 
when calling dgemv from Fortran (as long as both modules are compiled 
with the same compiler, or with compatible compilers).

When you fix all the calls to dgemv in your C source files to use 
"FCONE", as documented in WRE, the warning about the call to dgemv from 
geomsup.f will go away (yes, the warnings from the LTO linker/compiler 
are confusing). There is no need for creating any wrappers for 
BLAS/LAPACK calls.

One can check that the generated calls from the Fortran are correct e.g. 
via compiling with -fdump-tree-all and then dumping

$ egrep -e '(^;;)|(dgemv)' eha.so.ltrans0.232t.optimized | grep dgemv -B1
(the file name above will depend on the exact version of your compiler)

;; Function d2_loglik_ph (d2_loglik_ph, funcdef_no=77, decl_uid=4474, 
cgraph_uid=103, symbol_order=990)
  dgemv_ (, mb_497(D), nn_499(D), , z_502(D), mb_497(D), 
b_503(D), , _beta, ezb_501, );

--
;; Function d2_loglik_phexp (d2_loglik_phexp, funcdef_no=87, 
decl_uid=4470, cgraph_uid=100, symbol_order=1108)
  dgemv_ (, mb_253(D), nn_255(D), , z_258(D), mb_253(D), 
b_259(D), , _beta, ezb_257, );

--
;; Function gmlfun (gmlfun_, funcdef_no=98, decl_uid=4484, 
cgraph_uid=108, symbol_order=874)
  dgemv_ (&"N"[1]{lb: 1 sz: 1}, nn_68(D), antcov_63(D), , 
covar_83(D), nn_68(D), beta_84(D), , , score_81(D), 
, 1);

--
;; Function geomsup (geomsup_, funcdef_no=116, decl_uid=4498, 
cgraph_uid=117, symbol_order=823)
  dgemv_ (&"N"[1]{lb: 1 sz: 1}, nn_55(D), antcov_51(D), , 
covar_89(D), nn_55(D), startbeta_83(D), , , score_87(D), 
, 1);

--
;; Function sup (sup, funcdef_no=128, decl_uid=4335, cgraph_uid=7, 
symbol_order=1772)
  dgemv_ (, , , , covar_281(D), , beta_340(D), , 
, score_230, );

You can see that the calls to dgemv from gmlfun and geomsup are fine 
(from Fortran code), the other are bad (from C code).  Indeed, one would 
have found out also by creating a minimal reproducible example - it is 
always useful, even when not attempting to report a bug.

Best
Tomas

On 9/13/19 12:07 AM, Göran Broström wrote:

On 2019-09-12 09:13, Martin Maechler wrote:

Göran Broström
 on Wed, 11 Sep 2019 13:36:40 +0200 writes:

 > A followup question: Is it possible to call a BLAS/LAPACK 
subroutine,
 > where one parameter is character, from FORTRAN (77) code 
called by

 > .Fortran? (No problem "in the past".)

[as there wasn't a reply till now : ]

Yes, that should continue to be possible.

 > And if yes, how?

I'm sorry I don't know (and currently lack the time to try to find 
out)...

I solved it by writing a C wrapper (for the BLAS subroutine dgemv) 
cdgemv:

#define USE_FC_LEN_T
#include 
#include 
#ifndef FCONE
# define FCONE
#endif
#include 
#include "cdgemv.h"

void F77_SUB(cdgemv)(const int *trans, const int *m, const int *n,
 const double *alpha, const double *a,
 const int *lda,
 const double *x, const int *incx,
 const double *beta,
 double *y, const int *incy){
   char trams;

   if (*trans == 1){
  trams = 'N';
  F77_CALL(dgemv)(, m, n, alpha, a, lda, x, incx, beta, y,
  incy FCONE);
   }else
  Rprintf("trans has wrong value\n");
   }
}

which I call from Fortran. Curiously, a Fortran wrapper also seems to 
work.

G,

Martin

 >   Documentation describes calls from C to Fortran and
 > vice versa, but not this situation (AFAICS).

 > Yes, I know that .Fortran is not well seen these days, but my 
fortran
 > code is ancient, from the before-R era, and I would like to 
leave it as-is.

 > G,

 > Den 2019-09-01 kl. 21:46, skrev Göran Broström:
 >>
 >>
 >> On 2019-08-31 18:47, Göran Broström wrote:
 >>> I'm having difficulties updating my package eha: When I run 
standard
 >>> checks 'at home' everything is fine, but 'CRAN-submissions' 
reports

 >>> (among other things):
 >>>
 >>> geomsup.f:324:9: warning: type of ‘dgemv’ does not match 
original

 >>> declaration [-Wlto-type-mismatch]
 >>>    324 |  & one, score, ione)
 >>>    | ^
 >>> /home/tmp/R-d-gcc-LTO/include/R_ext/BLAS.h:107:1: note: type 
mismatch

 >>> in parameter 12
 >>>    107 | F77_NAME(dgemv)(const char *trans, const int *m, 
const int *n,

 >>>    | ^
 >>>
 >>> This is odd since the LAPACK subroutine dgemv takes only 11
 >>> parameters. However, in include/R_ext/BLAS.h we have
 >>>
 >>> F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
 >>>  const double *alpha, const double *a, const int *lda,
 >>>  const double *x, const int *incx, const double *beta,
 >>>

Re: [R-pkg-devel] please help understand an error in openMP statements

2019-09-13 Thread Ivan Krylov

On Thu, 12 Sep 2019 16:12:17 -0500
Marcin Jurek  wrote:

> U_NZentries.cpp:258:19: error: ‘covparms’ not specified in enclosing 
> ‘parallel’
>   258 |  covmat= MaternFun(dist,covparms) + diagmat(nug) ; // summation from 
> arma
>   |  ~^~~

This might be a compiler bug: const arma::vec covparms from the
argument list should have been automatically predetermined "shared". If
you try to specify #pragma omp shared(...,covparams) manually, you might
hit another error: "covparams" is predetermined "shared" for "shared".
In a similar case, I couldn't find a good workaround and had to switch
to default(shared).

> U_NZentries.cpp:271:12: error: ‘none’ not specified in enclosing ‘parallel’
>   271 | M=solve(chol(covmat,"upper"),onevec);
>   |   ~^

This is probably about the temporary returned from
chol(covmat,"upper"). Declare a variable for it inside the loop, and
the compiler will understand that it's private. Again, this shouldn't
be happening, so what I'm offering is a workaround.

What I find really strange is that gcc-4.9.3/mingw_32/bin/g++.exe
doesn't have any problems with this code, while supposedly newer g++-9
does.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] please help understand an error in openMP statements

2019-09-13 Thread Serguei Sokol


On 12/09/2019 23:12, Marcin Jurek wrote:

Hello everyone, I'm submitting a package to CRAN which I tested locally, on
Travis CI, R-hub and win builder. It worked no problem in all these
environments. However, after submission, I keep getting the error described
here:


https://win-builder.r-project.org/incoming_pretest/GPvecchia_0.1.0_20190912_201702/Debian/00install.out

One obvious error is pretty well described by the compiler:

U_NZentries.cpp:258:19: error: ‘covparms’ not specified in enclosing 
‘parallel’
  258 |  covmat= MaternFun(dist,covparms) + diagmat(nug) ; // summation 
from arma

  |  ~^~~
U_NZentries.cpp:230:11: error: enclosing ‘parallel’
  230 |   #pragma omp parallel for 
shared(locs,revNNarray,revCondOnLatent,nuggets, nnp,m,Lentries,COV) 
private(k,M,dist,onevec,covmat,nug,n0,inds,revCon_row,inds00,succ,attempt) 
default(none) schedule(static)


It simply stets that you should add 'covparms' either to private() or to 
shared() list on line 230.


I have no idea for other messages complaining about 'none'.

Best Serguei.





I'm not a pro when it comes to openMP but since all previous tests
completed successfully, I thought things were alright. Could you help me
understand what's wrong and how to fix it? Source code of the package can
be found at http://github.com/katzfuss-group/GPvecchia Thanks a lot!


Marcin

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

Re: [R-pkg-devel] Number of cores in examples

[R-pkg-devel] Number of cores in examples

Re: [R-pkg-devel] How reproduce CRAN check

Re: [R-pkg-devel] How reproduce CRAN check

Re: [R-pkg-devel] How reproduce CRAN check

[R-pkg-devel] How reproduce CRAN check

Re: [R-pkg-devel] My test passes in OSx on Travis, but not in OSx on CRAN

Re: [R-pkg-devel] My test passes in OSx on Travis, but not in OSx on CRAN

[R-pkg-devel] My test passes in OSx on Travis, but not in OSx on CRAN

Re: [R-pkg-devel] R, BLAS, and FCLEN (solved)

Re: [R-pkg-devel] R, BLAS, and FCLEN (solved)

Re: [R-pkg-devel] please help understand an error in openMP statements

Re: [R-pkg-devel] please help understand an error in openMP statements

13 matches

Site Navigation

Mail list logo

Footer information