Re: OpenBlas Pthread issue with R

Hi Mo, On 28 May 2020 at 03:40, Mo Zhou wrote: | Hi edd, It's Dirk, actually. 'edd' is just the account handle. | I still cannot reproduce the issue in a Sid chroot with R-4.0.0. It "We know". Seb was referring to the same problem, as I understand it. | seems that the trigger of the

Re: OpenBlas Pthread issue with R

> 1) We provide extra shared objects, libopenblasp, libopenblaso, etc >and let R link against libopenblaso (o=openmp) > >Drawback: too ugly and makes the blas ecosystem overly complex. >Also breaks the alternative mechanism > > 2) Add RPATH=/usr/lib/<..>/blas-pthread/ to all the

Re: OpenBlas Pthread issue with R

Hi edd, I still cannot reproduce the issue in a Sid chroot with R-4.0.0. It seems that the trigger of the problem remains to be unveiled. According to the previous discussions, there are several possible preliminary solutions to the problem 1) We provide extra shared objects, libopenblasp,

Re: OpenBlas Pthread issue with R

Hi Seb, On 1 May 2020 at 14:18, Sébastien Villemot wrote: | Le vendredi 01 mai 2020 à 07:05 -0500, Dirk Eddelbuettel a écrit : | > On 1 May 2020 at 05:16, Mo Zhou wrote: | > > On Thu, Apr 30, 2020 at 11:26:23PM -0500, Dirk Eddelbuettel wrote: | > > > Switching to libopenblas0-openmp works but

Bug#961670: ITP: gftl -- Containers and iterators for Fortran

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-de...@lists.debian.org, debian-science@lists.debian.org Control: block 961667 by -1 Control: block 961668 by -1 Control: block 961669 by -1 * Package name: gftl Version : 1.2.5 Upstream Author : Tom Clune

Bug#961669: ITP: gftl-shared -- Common gFTL containers for Fortran intrinsic types

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-de...@lists.debian.org, debian-science@lists.debian.org Control: block 961667 by -1 Control: block 961668 by -1 * Package name: gftl-shared Version : 0.9.5 Upstream Author : Tom Clune * URL :

Bug#961668: ITP: fargparse -- Command line argument parsing for Fortran

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-de...@lists.debian.org, debian-science@lists.debian.org Control: block 961667 by -1 * Package name: fargparse Version : 0.9.5 Upstream Author : Tom Clune * URL :

Bug#961667: ITP: pfunit -- Parallel Fortran Unit Testing Framework

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-de...@lists.debian.org, debian-science@lists.debian.org * Package name: pfunit Version : 4.1.8 Upstream Author : Tom Clune * URL : https://github.com/Goddard-Fortran-Ecosystem/pFUnit * License

Re: catching 32/64 bit integer mixing

Thanks again, Thomas. Upstream is on gitlab and already runs CI testing, so sounds like lgtm ought to work for them. I'll point them at this message thread for details. Drew On 2020-05-27 16:19, Thomas Schiex wrote: Hello Drew, I have used LGTM for one of my open source projects. If the

Re: catching 32/64 bit integer mixing

Hello Drew, I have used LGTM for one of my open source projects. If the sources are deposited on GitHub (or Gitlab) for example, this is immediate to use: create an account under lgtm.com, create a project and point it to the git repo. It will fetch sources and start the analysis. The results