Re: [R-pkg-devel] State of the art for UBSAN testing

[Ralf Stubner]

Thanks Gábor! If one checks the output, one can indeed find the UBSAN
error. Problem solved!

Ralf

On Thu, May 16, 2024 at 8:40 PM Gábor Csárdi  wrote:
>
> R-hub v2 has UBSAN testing, the clang-asan image also has UBSAN. [1]
>
> With the glitch that UBSAN errors do not fail the build because of a bug [2],
> so you'll need to look at the results even if the build has passed.
>
> Gabor
>
> [1] https://r-hub.github.io/containers/
> [2] https://github.com/r-hub/actions/issues/16
>
> On Thu, May 16, 2024 at 10:27 PM Ralf Stubner  wrote:
> >
> > Dear all,
> >
> > I have been asked to fix a UBSAN error in my dqrng package. The error
> > itself and the necessary fix are quite straight forward. However, I
> > want to make 100% sure that I am really fixing the error. In the past
> > I had used rhub for tasks like that. But it seems like the new rhub v2
> > offers only ASAN testing. I have also tried various docker images
> > (wch1/r-debug, old rhub images, rocker), but with none of them I was
> > able to reproduce the error seen on CRAN. What would you consider as
> > "state of the art" for reproducing UBSAN errors?
> >
> > Thanks
> > Ralf
> >
> > __
> > 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] State of the art for UBSAN testing

[Ralf Stubner]

Dear all,

I have been asked to fix a UBSAN error in my dqrng package. The error
itself and the necessary fix are quite straight forward. However, I
want to make 100% sure that I am really fixing the error. In the past
I had used rhub for tasks like that. But it seems like the new rhub v2
offers only ASAN testing. I have also tried various docker images
(wch1/r-debug, old rhub images, rocker), but with none of them I was
able to reproduce the error seen on CRAN. What would you consider as
"state of the art" for reproducing UBSAN errors?

Thanks
Ralf

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

Re: [R-pkg-devel] User defined RNG and code registration.

[Ralf Stubner]

On Sat, Sep 23, 2023 at 7:30 PM Ivan Krylov  wrote:
> You're right! Looking at the code, if R_useDynamicSymbols(dll, FALSE)
> has been called for a DLL, the branch that calls dlsym() or
> GetProcAddress() to find symbols from that library by their shared
> object symbol names gets completely disabled; only the registered
> function names known to R matter at this point.

Thanks Ivan for the investigations! That explains my experiences.

> It sounds unsatisfying, but if you register your user_unif_rand
> function with the right name and any of the ABIs supported by R, it
> sounds like it should work as long as you never call it using the
> .Call/.C/.Fortran ABI it's registered for.

That is indeed unsatisfying, but looks like the best workaround for now.

Ralf

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

Re: [R-pkg-devel] User defined RNG and code registration.

[Ralf Stubner]

On Sat, Sep 23, 2023 at 10:00 AM Duncan Murdoch
 wrote:

> I don't know the answer here, but section 6.16 of WRE suggests that you
> could explicitly make your functions visible even if they default to
> invisible.

Thanks Duncan. Unfortunately at least in my tests the visibility
settings did not alter whether R could find these routines.

Ralf

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

[R-pkg-devel] User defined RNG and code registration.

[Ralf Stubner]

Hi everybody,

Section 5.4 of WRE suggests to use `R_useDynamicSymbols(dll, FALSE);`
when registering C/C++ routines in R packages, and Rcpp does so
automatically. ?Random.user describes a way to hook a user- defined
RNG into R. However, it looks like these two things are not
compatible, i.e. `user_unif_rand` et al. are not found, if dynamic
symbols are not allowed. Or can one register these routines somehow
even though they are not following one of the standard calling
conventions?

Thanks
Ralf

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

Re: [R-pkg-devel] How to provide a finalized PDF file in a package?

[Ralf Stubner]

On Tue, Jan 21, 2020 at 5:50 PM Gábor Csárdi  wrote:
>
> While R.rsp is a great workaround, I wish we had a better solution for
> including a static PDF file in a package, one that does not require 6
> additional packages to leave a file exactly as it is

One can use a Sweave vignette and simply include the real PDF with the
pdfpages package, c.f.
https://github.com/RcppCore/Rcpp/blob/master/vignettes/Rcpp-introduction.Rnw

cheerio
ralf

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

Re: [R-pkg-devel] For reproducibility issue

[Ralf Stubner]

On Fri, Jan 17, 2020 at 2:56 PM ‫وليد خلف معوض المطيرى‬‎
 wrote:‬
> This might be because the RNG method used in random_number function is 
> different between the used version GCC 6 or less and the new ones GCC 8 or 
> greater.

This is quite likely correct. The current gfortran docs [1] list
xoshiro256** as the RNG used for RANDOM_NUMBER. This is a relatively
recent RNG [2], so older versions of gfortran must have used something
else, leading to different results even for identical seed values.
This explains the WRE excerpt quoted by Ivan: If you want reproducible
results, you must not use an external RNG which might change without
warning. The obvious solution would be to use R's RNG as suggested
before. If that is to slow for your application, you can use faster
RNGs that are provided by some packages. For example, my dqrng package
[3] includes xoshiro256+, though I have not tried to use this from
Fortran code.

Greetings
Ralf

[1] https://gcc.gnu.org/onlinedocs/gfortran/RANDOM_005fNUMBER.html
[2] https://arxiv.org/abs/1805.01407
[3] https://www.daqana.org/dqrng/

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

Re: [R-pkg-devel] Large Data Package CRAN Preferences

[Ralf Stubner]

On Sun, Dec 15, 2019 at 6:27 PM  wrote:
> Thanks for this information, and it makes sense to me.  Is there a preferred 
> way to cache the data locally?

Personally I like making an R package out of the data and hosting it
in an "AdditionalRepository". This is quite easy with the help of the
drat package. See
https://journal.r-project.org/archive/2017/RJ-2017-026/RJ-2017-026.pdf
for details of this approach.

cheerio
ralf

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

Re: [R-pkg-devel] Compiler warning using C versions of base R integrate function

[Ralf Stubner]

On Thu, Nov 21, 2019 at 7:25 PM Devin Incerti  wrote:
> I'm attempting to submit a very minor update to my package where I replaced
> a deprecated C++ function with an alternative. However, I'm receiving an
> unrelated warning "*array subscript -1 is outside array bounds of ‘double
> [52]’ [-Warray-bounds] *" on Debian during the CRAN pre-tests. I do not
> receive this warning on my local OS X, Ubuntu 16.04 (on Travis-CI), with
> Win-builder, or with R-hub builder. I also did not receive this warning on
> previous submissions to CRAN, but it does now show up on the most recent CRAN
> checks
> 

I cannot reproduce the warning with R 3.6.1 and GCC 9.2. It seems to
be an R-devel + new(ish) GCC issue since it also appears on the rather
new Windows + GCC 8 tests.

[...] .
> R source with function pointers replaced by C++ functors. These integration
> functions are needed so that the package can integrate at the C++ level.

Calling the integration functions from R's C API is no fun, indeed.
Have you considered using RcppNumerical
(https://github.com/yixuan/RcppNumerical) instead of copying code from
R?

cheerio
ralf

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

Re: [R-pkg-devel] Use LAPACK, BLAS and CBLAS paths in configure file

[Ralf Stubner]

On Tue, Nov 5, 2019 at 10:12 AM Sameh M. Abdulah
 wrote:
> 1- Use LAPACK, BLAS, and CBLAS paths in my configure file. What is the 
> command to use or what are the environment variables to read?

According to WRE [1] you should include "$(LAPACK_LIBS) $(BLAS_LIBS)
$(FLIBS)" in PKG_LIBS via src/Makevars. You can access these values
also via

R CMD config LAPACK_LIBS

etc. You cannot assume to have CBLAS installed.

[1] https://cran.r-project.org/doc/manuals/R-exts.html#Using-Makevars

> 2- Check if OpenBLAS is installed on the system or not. I tried to use 
> pkg-config but it doesn't work with CRAN servers, any alternatives?

You mean pkg-config does not work or does not find OpenBLAS? The
latter would be hardly surprising, since the CRAN machines most likely
use the (partial) reference BLAS/LAPACK that is included with R. Why
should they have OpenBLAS installed as well?

cheerio
ralf

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

Re: [R-pkg-devel] Package or namespace load failed: undefined symbol

[Ralf Stubner]

On Thu, Sep 26, 2019 at 3:41 PM Sameh M. Abdulah
 wrote:
>
> I am installing my dependencies including OpenBLAS during  the package 
> installation via the configure file.
> What is surprising me that even all dependencies are installed successfully. 
> R cannot load one of the library
> that depends on LAPACKE. My method is to install all my dependencies inside 
> the installation directory of my R package and
> set PKG_CONFIG_PATH to this path. Do I need to set any other paths so that R 
> can see my new OpenBLAS which include LAPACKE?

With PKG_CONFIGURE _PATH you enable finding the right compiler flags
for compilation. However, this does not help you with the necessary
run time linking, since you seem to be building dynamic libraries. One
way forward might be:

* Build a static version of LAPACKE
* Build a static version of your dependency
* Build your package linking with your static libs and BLAS/LAPACK as
described in WRE.

cheerio
ralf

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

Re: [R-pkg-devel] Package or namespace load failed: undefined symbol

[Ralf Stubner]

On Wed, Sep 25, 2019 at 10:29 AM Sameh M. Abdulah
 wrote:
> I am installing OpenBLAS because I need LAPACKE libraries which I cannot find 
> on the current version of OpenBLAS on CRAN.
>
> I add the libraries directory in my package to the PKG_CONFIG_PATH. Is this 
> enough for the system to use my OpenBLAS library?

I seem to be missing some context here. I might be able to help you if
provide a higher level description of what you are trying to achieve.
For example, why do you need LAPACKE instead of the C interface to
LAPACK provided by R_ext/Lapack.h? And if you really need LAPACKE, why
not include only that in your package and link with the BLAS/LAPACK
used by R?

cheerio
ralf

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

Re: [R-pkg-devel] Package or namespace load failed: undefined symbol

[Ralf Stubner]

On Tue, Sep 24, 2019 at 12:10 PM Sameh M. Abdulah
 wrote:
> I am uploading my R package to CRAN. One of the dynamic libraries the package 
> requires depends on LAPACKE library which usually integrated with BLAS and 
> CBLAS in the same .so file (as I understand). CRAN has OpenBLAS already 
> installed on the system. However, this OpenBLAS library does not maintain 
> implementation of LAPACKE library. Thus, I have modified my configure file to 
> install a standalone OpenBLAS library to use it.
>
> The problem that my installation has successfully passed, however, CRAN fails 
> in loading my package giving me this error:
>
> /srv/hornik/tmp/CRAN/exageostatr.Rcheck/exageostatr/lib/libcoreblas.so: 
> undefined symbol: LAPACKE_slarfb_work

This looks as if you are building OpenBLAS as a /dynamic/ library
installed in your package directory. This cannot work since the
run-time linker will not search your package directory for dynamic
libraries. You could build OpenBLAS as a /static/ library instead.
However, I am unsure why you want to build OpenBLAS in the first
place, since any R package can reliably link with the BLAS and LAPACK
versions used by R. See WRE on Makevars, BLAS_LIBS etc. for details.

cheerio
ralf

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

Re: [R-pkg-devel] Fwd: Reproducing CRAN pre-tests

[Ralf Stubner]

On Fri, Sep 20, 2019 at 11:44 AM Aravind J.
 wrote:
> However, the question remains, is there any way to replicate the CRAN
> pre-tests locally for future debugging, particularly in a windows
> environment?
>
> I had tried rhub platforms without any success.

I have found the docker image wch1/r-debug most helful for debugging
memory issues, c.f.
https://github.com/wch/r-debug/blob/master/debugging-r.md. I am not
using Windows myself, but since docker is available on Windows, this
image should be useable there as well.

cheerio
ralf

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

Re: [R-pkg-devel] set pkg_config for 3rd party software

[Ralf Stubner]

On Thu, Sep 5, 2019 at 6:36 PM Martin Maechler
 wrote:
> For me (on Fedora 30)
>
>   $ R CMD config LDFLAGS
>   -L/usr/lib64

This looks wrong. I would expect that /usr/lib64 is one of the
standard directories that are searched anyway. So why put it into the
very beginning of the search? BTW, this does not happen on Debian:

$ R CMD config LDFLAGS
-Wl,-z,relro

> Yes, on a machine with root permission I can hack around to get
> what I want,  but of course I'd really like   'R CMD INSTALL ..'
> to do the "right thing"
> just from my  configure  plus src/Makevars{.in}  files.
> Yes, I tried  'LDFLAGS = ' (to set it to "empty") in
> src/Makevars*  but that did not help either.

I see no way to correct this within a package. The only thing that
comes to mind is adding a test in `configure{.ac}` that will fail when
a to old version of libmpfr is actually used for linking. If the test
fails, one can at least give an informative message. Then either an
admin corrects the configuration or the user overwrites LDFLAS in
~/.R/Makevars.

cheerio
ralf

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

Re: [R-pkg-devel] set pkg_config for 3rd party software

[Ralf Stubner]

On Thu, Sep 5, 2019 at 12:27 PM Martin Maechler
 wrote:

> Now what is the officially / best way to have either 'configure'
> or  Makevars.{in,win}  use the 'pkg-config' information
> *dynamically*, i.e.,
> if I update my MPFR from 4.0.1 to 4.0.2  the newer 4.0.2 is found ?

I don't know what is best, but here are three alternatives:

* Use PKG_CHECK_MODULES which sets up default variables with _CFLAGS
and _LIBS suffix after searching for a library with pkg-config, c.f.
https://autotools.io/pkgconfig/pkg_check_modules.html
* Call pkg-config by hand in configure.ac (and hence configure).
Example: 
https://github.com/eddelbuettel/rcppredis/blob/master/configure.ac#L47-L60
* Call pkg-config within an "Anticonf" configure script. Example:
https://github.com/jeroen/curl/blob/master/configure#L16-L24

cheerio
ralf

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

Re: [R-pkg-devel] third part software dependency

[Ralf Stubner]

On Fri, Aug 30, 2019 at 11:10 AM Serguei Sokol  wrote:
> I am preparing a new package r2sundials for submission to cran. It
> depends on third part software
> (https://computing.llnl.gov/projects/sundials).

Are you aware of the sundialr package?
https://cran.r-project.org/package=sundialr

> This will be my first
> submission of the kind so I am wondering how it is supposed to be tested
> so that I can reliably check the box "tested on R-devel" during
> submission process?
> I suppose that sundials is not installed on windev. And even if it was,
> I need a particular option in this software (index size set to 32 bits)
> which is probably not activated in the hypothetical installation. So I
> cannot use win-builder.r-project.org.
> Am I supposed to install current r-devel version and test my package on
> it locally?

Besides Dirk's suggestions, you can also use a CI service like Travis.
there you can install additional dependencies before testing the
package itself.

However, the question remains how CRAN will test the package without
having sundials installed.

cheerio
ralf

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

Re: [R-pkg-devel] Difficulty installing my package from drat repository

[Ralf Stubner]

On Wed, Jul 10, 2019 at 11:54 AM Alex Hallam  wrote:

> My hunch is that this has to do with the tar ball being tracked with "git
> large file storage". This is because the file size of my tar ball is 154.9
> MB which exceeds github's 100 MB file size limit. What options can I try in
> this situation?

Downloading the file in question gives

ralf@barra:~$ curl
https://alexhallam.github.io/drat/src/contrib/cfsalesdata_0.0.1.1.tar.gz
version https://git-lfs.github.com/spec/v1
oid sha256:91cd243e7e65ee315419e70c8104a159aae64a629d180b29d38ed44646215101
size 162397527

So your hunch seems to be correct. Can you distribute the data over
two (or more) packages?

cheerio
ralf

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

Re: [R-pkg-devel] Reproducing address sanitizer errors

[Ralf Stubner]

On Sat, Jul 6, 2019 at 10:45 PM Ralf Stubner  wrote:
> I have been informed that the most recent upload of our swephR package
> triggers stack-buffer-overflow. See for example
> https://www.stats.ox.ac.uk/pub/bdr/memtests/clang-ASAN/swephR. The
> reason seems to be quite obvious (an array has been declared with 36
> instead of 37 elements), but I would like to be sure about that.
> However, I cannot reproduce the issue. I have tried
> "rhub::check_with_sanitizers()" as well as running the problematic
> code with RD from the docker image rocker/r-devel-ubsan-clang (with
> --cap-add SYS_PTRACE), but to no avail. Does any of you have some
> other possibility to reproduce ASAN errors?

The linked page is gone since I uploaded a fixed version of swephR today. In the
I was able to reproduce the error and check the  fix using
rocker/r-devel-ubsan-clang together with

export ASAN_OPTIONS='detect_leaks=0:detect_odr_violation=0'

cheerio
ralf

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

[R-pkg-devel] Reproducing address sanitizer errors

[Ralf Stubner]

Dear List,

I have been informed that the most recent upload of our swephR package
triggers stack-buffer-overflow. See for example
https://www.stats.ox.ac.uk/pub/bdr/memtests/clang-ASAN/swephR. The
reason seems to be quite obvious (an array has been declared with 36
instead of 37 elements), but I would like to be sure about that.
However, I cannot reproduce the issue. I have tried
"rhub::check_with_sanitizers()" as well as running the problematic
code with RD from the docker image rocker/r-devel-ubsan-clang (with
--cap-add SYS_PTRACE), but to no avail. Does any of you have some
other possibility to reproduce ASAN errors?

Thanks
Ralf

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

Re: [R-pkg-devel] Compilation used the "non-portable flag"

[Ralf Stubner]

On 10.05.19 22:32, Goldfeld, Keith wrote:
> I am submitting an update to my package ‘simstudy’, and the ran the rhub 
> checks. I received a note from one of the four platforms (the other three 
> passed). The Ubuntu Linux 16.04 objected to the compilation flags:
> 
> * checking compilation flags used ... NOTE
> Compilation used the following non-portable flag(s):
>   ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’

You can ignore these messages, c.f. https://github.com/r-hub/rhub/issues/264

> I did some searching and someone suggested I create a ‘Makevars’ in the ~/.R 
> directory (which is different from my package directory). This is what I 
> included in the Makevars file:

You cannot remove these compiler flags in a package's Makevars file.
Either ignore the warning (that's what I am doing when using rhub), or
ask the rhub maintainer to add a suitable ~/.R/Makevars file.

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] data in R package

[Ralf Stubner]

On 29.04.19 11:03, Raffaele Argiento wrote:
> we are developing a R package and we would like to include as an
> example  published data that we have taken from a paper. Is this
> allowed ? Where can I find the policy about distributing data through
> the R Package

From the CRAN policies
<https://cran.r-project.org/web/packages/policies.html>:

  Packages should be of the minimum necessary size. Reasonable
  compression should be used for data (not just .rda files) and PDF
  documentation: CRAN will if necessary pass the latter through qpdf.

  As a general rule, neither data nor documentation should exceed 5MB
  (which covers several books). A CRAN package is not an appropriate way
  to distribute course notes, and authors will be asked to trim their
  documentation to a maximum of 5MB.

  Where a large amount of data is required (even after compression),
  consideration should be given to a separate data-only package which
  can be updated only rarely (since older versions of packages are
  archived in perpetuity).

Besides these technical questions, one also has to consider legal
questions: Under which license may one distribute the data?

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] dtrti2 error on CRAN checks

[Ralf Stubner]

On 18.04.19 07:53, Benjamin Christoffersen wrote:
>> In short, you need to look more closely.
> Is there a way to tell which BLAS and LAPACK is used on the Debian
> machines on CRAN?

I am sure CRAN machines use BLAS and LAPACK as shipped with R, i.e. not
*any* variant of system BLAS/LAPACK.

cheerio
ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] Package suggested but not available for checking: 'rPeaks'; Additional_repositories

[Ralf Stubner]

On 16.04.19 03:15, Tan Zhou wrote:
> install.packages("rPeaks", repos = "https://jrminter.github.io/drat/;,
> type = "source")
> Warning in install.packages :
>   unable to access index for repository
> https://tankwin08.github.io/drat/src/contrib:
>   cannot open URL 'https://tankwin08.github.io/drat/src/contrib/PACKAGES'
> Warning in install.packages :
>   unable to access index for repository
> https://jrminter.github.io/drat/src/contrib:
>   cannot open URL 'https://jrminter.github.io/drat/src/contrib/PACKAGES'
> Installing package into ‘C:/Users/tank/Documents/R/win-library/3.4’
> (as ‘lib’ is unspecified)
> Warning in install.packages :
>   unable to access index for repository
> https://jrminter.github.io/drat/src/contrib:
>   cannot open URL 'https://jrminter.github.io/drat/src/contrib/PACKAGES'
> Warning in install.packages :
>   package ‘rPeaks’ is not available (for R version 3.4.3)

Either you or the rPeaks author should create a repository on GitHub
named 'drat', possibly by forking the original 'drat' repo. Please read
the corresponding vignette
https://cran.r-project.org/web/packages/drat/vignettes/DratForPackageAuthors.html
for the full details.

cheerio
ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] Package suggested but not available for checking: 'rPeaks'; Additional_repositories

[Ralf Stubner]

On 15.04.19 18:50, Tan Zhou wrote:
> I followed the suggestions based on
> https://stackoverflow.com/questions/29419776/r-package-dependencies-not-installed-from-additional-repositories
> .
> But it didn't work out for me. OR maybe I didn't set up it right.
> 
> My GitHub repository is https://github.com/tankwin08/waveformlidar.
> 
> My DESCRIPTION:
> Suggests:
> knitr,
> rPeaks
> Additional_repositories: https://github.com/jrminter/rPeaks/

The 'Additional_repositories' field is meant for additional CRAN-like
repositories, not for a git(hub) repository. A simple way to create such
a CRAN-like repository is given by the drat package, as mentioned in the
referenced SO answer. I am using that for the swephR package:

...
Suggests:
testthat,
swephRdata,
knitr,
rmarkdown
Encoding: UTF-8
URL: https://github.com/rstub/swephR/, http://www.astro.com/swisseph/
BugReports: https://github.com/rstub/swephR/issues/
Additional_repositories: https://rstub.github.io/drat
...


So while the 'swephRdata' can be found at
https://github.com/rstub/swephRdata/, the 'Additional_repositories'
field points to my drat repository.

In your case, you could either ask the rPeaks author to create a drat
repo or do that yourself (possibly with the author's consent).

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] CRAN review

[Ralf Stubner]

On 29.03.19 17:05, William Dunlap wrote:
> It looks like it is not boost but RcppEigen that has the call to
> std::rand() that volesti/src/rotating.cpp contains.
> 
> RcppEigen/include/Eigen/src/Core/MathFunctions.h:
>   static inline Scalar run(const Scalar& x, const Scalar& y)
>   {
> return x + (y-x) * Scalar(std::rand()) / Scalar(RAND_MAX);
>   }

The link between the two seems to be rounding.h which contains:

  // pick a random rotation
  MT R = MT::Random(n,n);

cheerio
ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] CRAN review

[Ralf Stubner]

On 29.03.19 17:27, Maxime Turgeon wrote:
> Maybe I'm missing something, but if RcppEigen were the cause of the NOTE, 
> wouldn't RcppEigen also get the same NOTE? However, it does not: 
> https://cran.r-project.org/web/checks/check_results_RcppEigen.html
> 
> And for what it's worth, neither does BH: 
> https://cran.r-project.org/web/checks/check_results_BH.html

Both RcppEigen and BH provide header only libraries which are only
compiled by packages making use of it. And the rand symbol is only
searched for in the resulting/compiled libraries.

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] What to do when a dependency falls off CRAN

[Ralf Stubner]

On 24.03.19 21:00, Neal Fultz wrote:
> 3) Adopt package, push fixed one to CRAN - not sure what the exact process
> is for un-orphaning, or if I would want to commit to maintaining it without
> knowing more about why it was dropped and how much work it is to get it
> passing. Eg if it were pathological solaris memory errors, I might have to
> pass. Are there ways to see old automated CRAN checks on a package that was
> abandoned? This approach obviously would benefit the community, but this is
> probably not billable work.

How about asking your client if they are willing to (partially) fund
somebody (does not have to be you) for getting the package back on CRAN?
They could be added to the DESCRIPTION in turn. And it might be cheaper
for them than rewriting the library or the application.

As for process: I think you basically upload a new version with higher
version number and updated "Maintainer" field. I have done this once for
tikzDevice, but that was only orphaned and not archived.

As for assessing the risks: Often the old checks are available for some
time after archiving, but I cannot find them in this case. Running "R
CMD check" on the two latest tarballs reveals only some NOTEs, though,
the most serious one from my point of view is usage of 'rand()' via
'random_shuffle()'
https://github.com/cran/maxent/blob/master/src/sgd.cpp#L77.

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] active bindings in package namespace

[Ralf Stubner]

On 24.03.19 18:27, Jack O. Wasey wrote:
> This is a good point. I would prefer to include all the data in the
> package, but CRAN has strict limitations on package and subdirectory
> size, which the potential data would easily exceed.

You could use a separate data package distributed via drat, c.f.
https://journal.r-project.org/archive/2017/RJ-2017-026/RJ-2017-026.pdf.
The original 'hurricaneexposure' package has meanwhile been archived.
However, I have successfully used this method in
https://cran.r-project.org/package=swephR.

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

[R-pkg-devel] Handling ERROR on Solaris

[Ralf Stubner]

Dear List,

my recent upload of dqrng v0.1.0 has triggered an ERROR on Solaris:¹ One
of the new tests results in a segmentation fault. During this test some
C++ code is compiled using Rcpp::sourceCpp and the resulting functions
are being called for different input.

Unfortunately I cannot reproduce the error on rhub's Solaris machine.² I
find it interesting that on both platforms a (IMO false positive)
warning is emitted by the compiler, but the wording is quite different.
Does this mean that the C++ compiler from Oracle Developer Studio is
used on CRAN? From
https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86 I had
gathered that g++ would be used for building packages that link with
Rcpp. But maybe that does not apply to code being compiled during tests
of such packages?

Anyway, I do not want to risk the package getting archived for failure
of fixing this cross-platform issue. Does anybody have suggestions for
reproducing such issues? Any other suggestions how to proceed?

Thanks
Ralf

[1] https://cran.r-project.org/web/checks/check_results_dqrng.html
[2]
https://artifacts.r-hub.io/dqrng_0.1.0.tar.gz-c6fb11ef8cef4098ba367bc6053a6e4d/dqrng.Rcheck/tests/testthat.Rout

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

[R-pkg-devel] How to handle UBSAN false positives

[Ralf Stubner]

Dear List,

in the last CRAN upload of my dqrng package I have enabled unit tests
for the C++ interface. Since then clang-UBSAN is listed under
"additional issues" on the CRAN check page [1]. I am fairly certain this
is a false positive, c.f. https://github.com/RcppCore/Rcpp/issues/832.

What would be best practice for handling this in the next upload?

1. Mention it in the upload comments as a false positive?
2. Disable the tests on CRAN?
3. Something else?

Thanks
Ralf

[1] https://cran.r-project.org/web/checks/check_results_dqrng.html
-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] Problem on rand() in packaging

[Ralf Stubner]

On 21.02.19 09:16, Uwe Ligges wrote:
> Use R's RNG, see Writing R Extensions.

Which can be conveniently used with R::runif and Rcpp::runif etc. when
using Rcpp.

cheerio
ralf

> Best,
> Uwe Ligges
> 
> 
> On 21.02.2019 07:52, Chu-Lan Kao wrote:
>> Dear Sir,
>>
>> I've got a Rcpp code in the form like the following in my uploaded
>> package:
>>
>> inline double runiforminline(){
>>    std::default_random_engine generator(rand());
>>    std::uniform_real_distribution distribution (0.0, 1.0);
>>    return (distribution(generator));
>> }
>>
>> But as I uploaded, the system ask me to remove rand(). Various attempt
>> has
>> been tried, but all of them result in no randomness at all. Not sure
>> how to
>> fix it. Kindly appreciate all helps.
>>
>> Sincerely,
>>
>> Chu-Lan Kao ( 高竹嵐 Michael )
>> *http://chulankao.blogspot.com / <http://chulankao.blogspot.com/>*
>> chulan...@gmail.com
>> <http://chulankao.blogspot.com%20/%20chulan...@gmail.com> / 0956242509
>>
>> Assist. Prof. in Statistics, National Chiao-Tung University
>> Music Director for dramAcappella Theater
>> <https://www.facebook.com/dramAcappella>
>> Composer, Taipei Philaharmonic Chorus <http://www.tpf.org.tw/index.php>
>> Gamer Consultant and Designer
>>
>> [[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

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] use g++ instead of clang++ on Mac OS

[Ralf Stubner]

On 24.01.19 16:50, Jan Wijffels wrote:
> Thank you for the input. Does that mean also using a configure script
> would not work to make it use g++ instead of clang++ on Mac OS?
Yes, that also affects configure scripts. You might achieve this
compiler switch by using src/Makefile, since that fie is included after
R_HOME/etc/Makeconf. But I have never tried that and it is strongly
discouraged in WRE. I would expect that a package doing something like
that will not pass the CRAN checks.

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] use g++ instead of clang++ on Mac OS

[Ralf Stubner]

> The manual on R extensions at
> https://cran.r-project.org/doc/manuals/R-exts.html#Using-C_002b_002b11-code
> mentions that
> 
>> It is possible to specify ‘CXX11’ to be a distinct compiler just for
>> C++11–using packages, e.g. g++ on Solaris.
> 
> I tried to set such a directive in my src/Makevars file but appartently
> failed to set it correctly. How do I set in the src/Makevars such that the
> compilation is done using g++ instead of clang++

It is not possible to alter the compiler via src/Makevars, c.f.
https://stat.ethz.ch/pipermail/r-package-devel/2017q4/002087.html. You
have to use $HOME/.R/Makevars or $R_HOME/etc/Makeconf for that.

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] Incorporating external library licensces (zstd license) within package

[Ralf Stubner]

On 09.01.19 20:18, Travers Ching wrote:
> * Use of the AGPL-3 license which seems to be able to cover the ZSTD
> BSD licensce.

ZSTD is dual license BSD and GPL-2. So AGPL-3 is fine, as would be GPL-2
or GPL-3.

> * Attach APGL-3 notice to all my source code files (excluding
> auto-generated Rcpp source code).

Ok.

> * Add Facebook as author/contributor and add copyright notice for the
> ZSTD library -- should I add the main ZSTD contributor/author (Yann
> Collet)?  (Attached at the bottom is my DESCRIPTION file).

I would use Yann Collet as author/contributor and Facebook only as
copyright holder.

> License: AGPL-3 | file LICENSE

What is the content of the LICENSE file? My suggestion would be
something like this:

Files: src/ZSTD/*
Copyright: 
License: BSD or GPL-2
URL: ...

Files: *
Copyright: 2019 Travers Ching
License: 

(c.f. https://github.com/daqana/dqrng/blob/master/LICENSE)

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] Submitting CORELS (Certifiably Optimal Rule Lists) package with/without Windows support

[Ralf Stubner]

On 20.12.18 13:52, Aditya Saligrama wrote:
> I was able to get the package to compile on Windows by emulating the way
> the sbrl package builds in Windows support. However, when I try to run
> the package on Windows, R completely crashes and exits to the desktop.
> 
> Would you have any suggestions on how to debug or fix this?

Start R from a command prompt. This way you might catch the error
message when R exits. Alternatively you could run R (or Rgui) in the gdb
debugger:

cmd> gdb.exe Rgui.exe
gdb> run
R> ...

See http://sourceware.org/gdb/current/onlinedocs/gdb/ for more info on gdb.

Greetings
Ralf


-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] Submitting CORELS (Certifiably Optimal Rule Lists) package with/without Windows support

[Ralf Stubner]

On 20.12.18 02:54, Aditya Saligrama wrote:
> I am trying to submit an R interface for CORELS (Certifiably Optimal Rule 
> Lists). However, I've had a lot of difficulty getting this to compile and run 
> on Windows. In its current state, it compiles on Windows but crashes when I 
> try to run it. Am I able to submit this without Windows support, or could 
> somebody help us with supporting Windows?
> The code is at https://github.com/saligrama/rcorels, and the main project is 
> available at https://corels.eecs.harvard.edu.

What errors doe you get? Your package seems to require GMP and GSL
libraries, which can impose problems on Windows if not handled
correctly. Have a look at CRAN for how other packages using these
libraries handle it.

Greetinga
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] FOSS license and restricted use by further dependence

[Ralf Stubner]

Hi Javier,

the ERROR does not come from the license but from the installation failure:

On 22.11.18 10:49, Javier García-Pintado wrote:
> * checking whether package ‘rDAF’ can be installed ... [2s/2s] ERROR
> Installation failed.
> See ‘/srv/hornik/tmp/CRAN/rDAF.Rcheck/00install.out’ for details.

cheerio
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] R package submission: does not pass the incoming checks automatically,

[Ralf Stubner]

Hi Bernd,

On 10/1/18 2:39 PM, Müller, Bernd wrote:
> * checking CRAN incoming feasibility ... NOTE
> Maintainer: ‘Bernd Mueller ’

This NOTE is expected for a new package. It acts as a reminder to THE
CRAN team to look at the package manually.

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966 P
Ust.-IdNr.: DE300072622
Geschäftsführer: Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] Submission to CRAN when package needs personal data (API key)

[Ralf Stubner]

On 07.09.2018 15:52, Iñaki Ucar wrote:
> For the record, this is what the testthat paper in the R Journal says:
> 
> "[...] I recommend storing your tests in inst/tests/ (so users also
> have access to them), then including one file in tests/ that runs all
> of the package tests. The test_package(package_name) function makes
> this easy. [...] This setup has the additional advantage that users
> can make sure your package works correctly in their run-time
> environment."

Tests in 'inst/test' got deprecated later on:

https://github.com/r-lib/testthat/commit/0a7d27bb9ea545be7da1a10e511962928d888302

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966 P
Ust.-IdNr.: DE300072622
Geschäftsführer: Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] Lapack: undefined symbol: zgbsv_

[Ralf Stubner]

On 14.02.2018 05:12, Baptiste Auguie wrote:
> It would make sense to test for internal vs external Lapack and decide
> based on that (regardless of the OS); as you say, the results should be
> essentially identical to what happens when the same user installs
> RcppArmadillo on their machine. Unfortunately I don't know how to
> proceed. I copied RcppArmadillo's configure.ac <http://configure.ac>
> script and tried to extract just the Lapack testing bits, but these
> macro and configure concepts are totally foreign to me. I believe it
> would be helpful to have a minimal example of this type of configuration
> for the dummy isolve package (https://github.com/baptiste/isolve
> <https://github.com/baptiste/isolve>), if someone with such expertise
> and a linux machine is willing to help.

Have a look at https://github.com/baptiste/isolve/pull/1 for one way to
do this. With this change it works in my test Docker image together with
the dev version(!) of RcppArmadillo.

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

R Institute GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 70 81 66
F: +49 331 23 70 81 67
M: +49 162 20 91 196

Mail: ralf.stub...@r-institute.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966 P
Ust.-IdNr.: DE300072622
Geschäftsführer: Prof. Dr. Dr. Karl-Kuno Kunze

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

Re: [R-pkg-devel] Lapack: undefined symbol: zgbsv_

[Ralf Stubner]

On 13.02.2018 05:49, Baptiste Auguie wrote:
> On 13 February 2018 at 01:05, Dirk Eddelbuettel <e...@debian.org
> <mailto:e...@debian.org>> wrote:
> Maybe we are setting a more global "no advanced lapack" for Windows that
> assures success when we assume that the other system will always
> have it.
> 
> 
> it sounds plausible, but it would be nice to know for sure.

It is the case, c.f.
https://github.com/RcppCore/RcppArmadillo/blob/master/inst/include/RcppArmadilloConfig.h#L96-L106

> In
> particular, it doesn't explain why the external Lapack on linux appears
> to be missing these symbols (they're not very recent, as far as I can
> tell). I don't really know how to figure this out, but it seems to be key.

My understanding:

* On Windows internal LAPACK is used but it is not affected due to the
defines quoted above.
* At least Debian & Co but probably also other Linux distributions
compile R with external LAPACK and are not affected.
* CRAN (and probably r-hub) use R compiled with internal LAPACK and is
therefore affected.
* I do not understand why Mac OS is not affected. The FAQ [1] implies
that by default the internal BLAS/LAPACK is used. But then I do not see
the mentioned alternative libRblas.vecLib.dylib on a test system.

[1]
https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#Which-BLAS-is-used-and-how-can-it-be-changed_003f


> Or, be brutal, and set '#define ARMA_CRIPPLED_LAPACK 1' everywhere.  See
> lines 67 to 95 of RcppArmadillo's configure.ac <http://configure.ac>:
> https://github.com/RcppCore/RcppArmadillo/blob/master/configure.ac#L67-L95
> 
> while this might solve the CRAN problem, it doesn't feel right to
> enforce the use of suboptimal routines throughout and on all platforms,
> including those that do in fact provide a full-fledged external Lapack. 

You could use this as a first step to get the package back into CRAN.
Later on you can try to only set the flag when an internal LAPACK is
detected, similar to the way RcppArmadillo does it. If my understanding
above is correct, the number of users with ARMA_CRIPPLED_LAPACK in your
package but not in RcppArmadillo will be quite small.

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

R Institute GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 70 81 66
F: +49 331 23 70 81 67
M: +49 162 20 91 196

Mail: ralf.stub...@r-institute.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966 P
Ust.-IdNr.: DE300072622
Geschäftsführer: Prof. Dr. Dr. Karl-Kuno Kunze

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