similar to: Installing package fails at "testing if installed package can be loaded from temporary location"

Il 30/04/20 03:39, Dirk Eddelbuettel ha scritto: > > On 30 April 2020 at 03:26, Samuele Carcagno wrote: > | I'm not familiar with the internals of `viridisLite`, so I'm not sure > | I'd be able to help there. I could open a bug report on the > | `viridisLite` repo and see if the author has suggestions on how to > | narrow down the issue. > > It would help if

Dear All, I am building R from source[1], following what is done in "rules" for building Debian's R. But the R I generate, in contrast to the standard Debian's R, will not change the BLAS and LAPACK libraries it uses when I change them via "update-alternatives". I have no idea what I am doing wrong (but, somehow, I've been quite capable of making the same

I run Fedora 22 R package. It is build with --with-lapack \ --with-blas \ --enable-R-shlib \. As the machine will act as a server with lots of R data computing, I try to optimize my R package. At first, I installed parallel_studio_xe_2016 with a free one year licence. Then, I build a package for R with Intel MKL and compiler. This took me lots of time as it was my first .rmp build. I finally

Thank you very much Dirk! Le mer. 13 mai 2020 ? 14:59, Dirk Eddelbuettel <edd at debian.org> a ?crit : > > Salut Adrien, > > It appears to be a bad OpenMP and and OpenBLAS interaction you can (for > now) > avoid) by replacing the 'pthread' variant of OpenBLAS with the OpenMP > version > (see the thread for details). Doing > > sudo apt install

Thanks Dirk.? That is what I thought, and sessionInfo() returns: Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3.10.3 LAPACK: /usr/lib/x86_64-linux-gnu/atlas/liblapack.so.3.10.3 locale: ?[1] LC_CTYPE=en_US.UTF-8?????? LC_NUMERIC=C ?[3] LC_TIME=en_US.UTF-8??????? LC_COLLATE=en_US.UTF-8 ?[5] LC_MONETARY=en_US.UTF-8??? LC_MESSAGES=en_US.UTF-8 ?[7]

Hello, I thought that I should try openblas when building a CRAN package containing lots of old (twentieth century) C-code with frequent calls to blas and lapack routines. I have the following options on my Ubuntu 20.04 machine: Selection Path Priority Status ------------------------------------------------------------ * 0

Hi, After loading R 4.0.0 on Ubuntu 20.04. R version 4.0.0 (2020-04-24) -- "Arbor Day" Copyright (C) 2020 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()'

Hello To update from R 2.6 to 2.8 (on Ubuntu 8.04 both) I had to install new tcl and liblapack packages (excuse me it is in french): > sudo apt-get install r-base-dev > Lecture des listes de paquets... Fait > Construction de l'arbre des d?pendances > Lecture des informations d'?tat... Fait > Les paquets suppl?mentaires suivants seront install?s : >

Hello R-sig-debian and (hopefully) Dirk: On Debian wheezy, I have the R packaging that CRAN (you) provide. I run into a little trouble while trying to fiddle with alternative BLAS. I know you and I went around on this last year and I think perhaps I've found something wrong in the framework, or I've just done something wrong. I installed the packages openblas-base and openblas-dev, and

On 2020-07-15 14:36, Dirk Eddelbuettel wrote: > > G?ran, > > This is not an easy email to reply to because it _contains nothing > reproducible_. Thanks Dirk, Sorry about that, but my real question was (see below): "Is the problem that openblas uses C versions of blas?" That is, do I need to change F77_CALL(name)(...); to cblas_name(...); everywhere? And if so, is

Hi, I'm using Ubuntu Hardy i386, and the R 2.7.1 Ubuntu packages from CRAN. The CRAN r-base-dev package depends on refblas3-dev or atlas3-base-dev, but octave3.0-headers depends on libblas-dev. The two blas packages seem to conflict, so r-base-dev and octave3.0-headers can't be installed together. Is this a known issue? Thanks, Gad $ sudo apt-get install octave3.0-headers Reading

dear debian-R group: I am using the stock ubuntu binary R 3.0.1 for ubuntu raring but on cinnamon mint olivia 15. I read dirk's gcbd paper from a couple of years ago. it suggests that stock blas is pretty bad compared to the four main alternatives. of course, dirk also maintains the binaries for debian/ubuntu R, so he probably knows the answer off hand. I installed libatlas3-base

On 30 April 2020 at 16:40, Samuele Carcagno wrote: | after some further investigation I found out that the issue was related | to some calls to the `solve` function in `make.rgb`, and indeed running | `example(solve)` would hang my R session. After I changed the default | BLAS with: | | sudo update-alternatives --config libblas.so.3-x86_64-linux-gnu | | the problem disappeared. The BLAS

On Wed, 27 May 2020 at 21:40, Gavin Simpson <ucfagls at gmail.com> wrote: > > Thanks I?aki, that is exactly what i was looking for, esp the last > option which I have now configured as an alias for easy remembering. > > I can answer the question re USE_LOCKING=1. I think that using both > those options is required to get thread-safety even if openblas was > compiled for

Il 30/04/20 03:14, Dirk Eddelbuettel ha scritto: > > On 30 April 2020 at 03:05, Samuele Carcagno wrote: > | Il 30/04/20 01:39, Dirk Eddelbuettel ha scritto: > | > Keep. It. Simple. And. Concise. > | > > | > And reproducible. > | > | I've attached a script that triggers the bug on my system. It's just two > | lines, one to load `viridisLite`, and one to

Hi, I tried to compile R with openblas on a ubuntu 12.04 machine. I have to say that I normally use the package system and that I have no experience with compiling R. I did the following: ./configure --enable-BLAS-shlib --enable-R-shlib LIBnn=lib --with-blas="-L/usr/lib/openblas-base/ -lopenblas" --enable-memory-profiling --with-x=yes go the output: R is now configured for

Just in case anyone cares or is hitting the same problem: to install current mgcv (1.0-5) on 1.9.0 on Knoppix/Debian unstable I had to: # cd /usr/lib # ln -s /usr/lib/atlas/libblas.so.3 libblas-3.so # ln -s /usr/lib/atlas/liblapack.so.3 liblapack-3.so Otherwise compilation couldn't find -lblas-3 or -llapack-3 (I could have gotten away with the links in /usr/lib/atlas instead of /usr/lib,

Greetings; I've posted the following to R's bug tracking system (at https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17210 ) and Martin Maechler requested that I post to this list as well. If I start R from the command line with --vanilla, then repeatedly execute the following line: det(matrix(nrow=10,ncol=10)) ... I eventually get a crash, with error: *** Error in

Dear All, Summary: ======== To test some packages, I want to build R-3.1.0 (current R devel). However, when I use the default libblas, make check fails with running code in 'reg-BLAS.R' ...make[3]: *** [reg-BLAS.Rout] Error 1 It does not fail, however, if I use libatlas3 or libopenblas. The same thing happens with the current R patched. I've google around and cannot find

What is the correct way to globally configure R to default to single (or at least, << NUM_CPUS) threaded operation? Using R 3.3.1 (both in debian unstable or using the CRAN repository for xenial) with OpenBLAS (0.2.18) defaults to using one thread per available CPU, which isn't ideal for machines more than a couple of CPUs. Setting the environment (OMP_NUM_THREADS or