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
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
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,
&
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
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:
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:
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
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.
>
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
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
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:
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
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
13 matches
Mail list logo
