Samuele Carcagno
2020-Apr-30 01:26 UTC
[R-sig-Debian] problem with `viridis` on Ubuntu 20.04
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 call the `viridis` > | function. I've also attached the output of `sessionInfo`. > | > | To sum up all the additional info in my previous e-mail: the bug occurs > | on Ubuntu 20.04 with R 4.0.0, but does not occur on Debian, Windows, or > | Mac using the same version of R (R 4.0.0), and the same version of > | viridisLite. > > Can you decompose it to see if the data generation is the problem (likely R) > or the drawing (maybe a change in graphics ?)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.> > What does capabilities() say? Anything missing? On 19.10 I havebelow is the output of `capabilities()` from my system: > capabilities() jpeg png tiff tcltk X11 aqua TRUE TRUE TRUE TRUE TRUE FALSE http/ftp sockets libxml fifo cledit iconv TRUE TRUE TRUE TRUE TRUE TRUE NLS profmem cairo ICU long.double libcurl TRUE TRUE TRUE TRUE TRUE TRUE> > R> capabilities() > jpeg png tiff tcltk X11 > TRUE TRUE TRUE TRUE TRUE > aqua http/ftp sockets libxml fifo > FALSE TRUE TRUE TRUE TRUE > cledit iconv NLS profmem cairo > FALSE TRUE TRUE TRUE TRUE > ICU long.double libcurl > TRUE TRUE TRUE > R> > > Dirk >
Dirk Eddelbuettel
2020-Apr-30 01:39 UTC
[R-sig-Debian] problem with `viridis` on Ubuntu 20.04
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 someone running Ubuntu 20.04 could reproduce. I realized I had a prebuilt version as a Docker image here -- it predates the actual 20.04 release by just a bit. But in that too, viridisLite installs fine and the call viridis(3) works as well. So I have no further pointers, and no reproduced bug. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
Samuele Carcagno
2020-Apr-30 10:02 UTC
[R-sig-Debian] problem with `viridis` on Ubuntu 20.04
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.after some further investigation I've found out that on my system the bug is triggered by a call to the `convertColor` function in `grDevices`. The following three lines of code, taken from the `convertColor` documentation are sufficient to trigger the bug: ## -------------------- ab <- expand.grid(a = (-10:15)*10, b = (-15:10)*10) Lab <- cbind(L = 20, ab) srgb <- convertColor(Lab, from = "Lab", to = "sRGB", clip = NA) ## ---------------------> > It would help if someone running Ubuntu 20.04 could reproduce.to be precise I'm running Kubuntu 20.04 rather than Ubuntu, but I don't think that should make a difference. Best, Sam
Samuele Carcagno
2020-Apr-30 14:40 UTC
[R-sig-Debian] problem with `viridis` on Ubuntu 20.04
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 someone running Ubuntu 20.04 could reproduce. >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 output of `sessionInfo` now that `solve` is working is: Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0 LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/liblapack.so.3 while before when `solve` was not working it was: Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3 LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/liblapack.so.3 so it seems the issue is with the Ubuntu package `libopenblas0-pthread` and has nothing to do with R. I don't know why openblas-pthread was the default BLAS on my system. Thank you for your help. Best, Sam
Dirk Eddelbuettel
2020-May-01 12:01 UTC
[R-sig-Debian] problem with `viridis` on Ubuntu 20.04
On 1 May 2020 at 06:34, May, William C wrote: | I'm running Ubuntu 20.04 with the cran40 repository and I'm not able to | reproduce this. | | I'm pasting the output of my R session and sessionInfo() below. They're | pretty close but not identical. Sam has a pthread version of blas and | lapack as opposed to the default blas version I have. I think that's | the difference most likely to cause mysterious problems. Thanks -- Well reasoned and yes, we arrived at the same issue. Which is the real problem. Replacing openblas-pthread with openblas-openmp fixes that. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org