I've hit a bug on Ubuntu 20.04. The issue occurred both with the R version that shipped with Ubuntu last week, and it is occurring now with the CRAN packages from one of the mirros (deb http://cran.mirror.garr.it/mirrors/CRAN/bin/linux/ubuntu/ focal-cran40/). The issue occurs whether I use the deb package for viridis in the Ubuntu repos, or I install it with `install.packages()` in R. The issue is that when I call a function from the 'viridis' package (e.g. running the first example in the `viridis` vignette: https://cran.r-project.org/web/packages/viridis/vignettes/intro-to-viridis.html) R gets stuck indefinitely; the system monitor shows the R process using CPU resources but nothing happens at the terminal and I'm also unable to stop the function with Ctrl-C. I did a little digging and simply calling the function `viridis` from the `viridisLite` package causes the same problem, execution gets stuck at the line: cols <- fn_cols(seq(begin, end, length.out = n)) / 255 which is line 177 here: https://github.com/sjmgarnier/viridisLite/blob/master/R/viridis.R#L177 I'm dual booting Debian Buster on the same machine and no such issue occurs with R 4.0.0 and the same versions of the `viridis` and `viridisLite` packages. Also no such issue occurs on Windows 10 or on a Mac both with R 4.0.0 and the latest versions of `viridis` and `viridisLite`. I was not sure where should I report the bug, so I thought of asking for advice here first. Best, Sam
problem with `viridis` on Ubuntu 20.04
10 messages · Dirk Eddelbuettel, Samuele Carcagno
On 30 April 2020 at 01:24, Samuele Carcagno wrote:
| I've hit a bug on Ubuntu 20.04. The issue occurred both with the R | version that shipped with Ubuntu last week, and it is occurring now with | the CRAN packages from one of the mirros (deb | http://cran.mirror.garr.it/mirrors/CRAN/bin/linux/ubuntu/ | focal-cran40/). The issue occurs whether I use the deb package for | viridis in the Ubuntu repos, or I install it with `install.packages()` in R. | | The issue is that when I call a function from the 'viridis' package | (e.g. running the first example in the `viridis` vignette: | https://cran.r-project.org/web/packages/viridis/vignettes/intro-to-viridis.html) | R gets stuck indefinitely; the system monitor shows the R process using | CPU resources but nothing happens at the terminal and I'm also unable to | stop the function with Ctrl-C. | | I did a little digging and simply calling the function `viridis` from | the `viridisLite` package causes the same problem, execution gets stuck | at the line: | | cols <- fn_cols(seq(begin, end, length.out = n)) / 255 | | which is line 177 here: | https://github.com/sjmgarnier/viridisLite/blob/master/R/viridis.R#L177 | | I'm dual booting Debian Buster on the same machine and no such issue | occurs with R 4.0.0 and the same versions of the `viridis` and | `viridisLite` packages. Also no such issue occurs on Windows 10 or on a | Mac both with R 4.0.0 and the latest versions of `viridis` and | `viridisLite`. | | I was not sure where should I report the bug, so I thought of asking for | advice here first. Can we make it reproducible, please? Can you provide a minimal script with values for begin, end, n, ... etc pp or a concrete call? I got lost in your description above between what version of R from where you ran with which package or function. Keep. It. Simple. And. Concise. And reproducible. For what it is worth, it _works for me with R 4.0.0 on Ubuntu 19.10_ with the binary .deb from my PPA (as blogged about, but should be identical to what Michael built and ships via CRAN). Log of a fresh Emacs session below. I double Ubuntu 20.04 is different but "one never knows". Thank you! Dirk Log below 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()' for distribution details. Natural language support but running in an English locale R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. There's an informal tradition that those announcements [about R releases] contain at least one mistake, but apparently I forgot this time, so users have to make up their own.... -- Peter Dalgaard (about an apparent non-bug report in his former R-announce message) R-help (December 2009) R> setwd('/home/edd/') R> R> library(viridisLite) R> example(viridis) viridsR> library(ggplot2) viridsR> library(hexbin) viridsR> dat <- data.frame(x = rnorm(10000), y = rnorm(10000)) viridsR> ggplot(dat, aes(x = x, y = y)) + virids+ geom_hex() + coord_fixed() + virids+ scale_fill_gradientn(colours = viridis(256, option = "D")) Hit <Return> to see next plot: viridsR> # using code from RColorBrewer to demo the palette viridsR> n = 200 viridsR> image( virids+ 1:n, 1, as.matrix(1:n), virids+ col = viridis(n, option = "D"), virids+ xlab = "viridis n", ylab = "", xaxt = "n", yaxt = "n", bty = "n" virids+ ) Hit <Return> to see next plot: R>
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
Il 30/04/20 01:39, Dirk Eddelbuettel ha scritto:
On 30 April 2020 at 01:24, Samuele Carcagno wrote: | I've hit a bug on Ubuntu 20.04. The issue occurred both with the R | version that shipped with Ubuntu last week, and it is occurring now with | the CRAN packages from one of the mirros (deb | http://cran.mirror.garr.it/mirrors/CRAN/bin/linux/ubuntu/ | focal-cran40/). The issue occurs whether I use the deb package for | viridis in the Ubuntu repos, or I install it with `install.packages()` in R. | | The issue is that when I call a function from the 'viridis' package | (e.g. running the first example in the `viridis` vignette: | https://cran.r-project.org/web/packages/viridis/vignettes/intro-to-viridis.html) | R gets stuck indefinitely; the system monitor shows the R process using | CPU resources but nothing happens at the terminal and I'm also unable to | stop the function with Ctrl-C. | | I did a little digging and simply calling the function `viridis` from | the `viridisLite` package causes the same problem, execution gets stuck | at the line: | | cols <- fn_cols(seq(begin, end, length.out = n)) / 255 | | which is line 177 here: | https://github.com/sjmgarnier/viridisLite/blob/master/R/viridis.R#L177 | | I'm dual booting Debian Buster on the same machine and no such issue | occurs with R 4.0.0 and the same versions of the `viridis` and | `viridisLite` packages. Also no such issue occurs on Windows 10 or on a | Mac both with R 4.0.0 and the latest versions of `viridis` and | `viridisLite`. | | I was not sure where should I report the bug, so I thought of asking for | advice here first. Can we make it reproducible, please? Can you provide a minimal script with values for begin, end, n, ... etc pp or a concrete call? I got lost in your description above between what version of R from where you ran with which package or function. 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. Best, Sam
For what it is worth, it _works for me with R 4.0.0 on Ubuntu 19.10_ with the
binary .deb from my PPA (as blogged about, but should be identical to what
Michael built and ships via CRAN). Log of a fresh Emacs session below. I
double Ubuntu 20.04 is different but "one never knows".
Thank you!
Dirk
Log below
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()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
There's an informal tradition that those announcements [about R releases] contain at least one mistake, but apparently I forgot this time, so users have to make up their own....
-- Peter Dalgaard (about an apparent non-bug report in his former R-announce message)
R-help (December 2009)
R> setwd('/home/edd/')
R>
R> library(viridisLite)
R> example(viridis)
viridsR> library(ggplot2)
viridsR> library(hexbin)
viridsR> dat <- data.frame(x = rnorm(10000), y = rnorm(10000))
viridsR> ggplot(dat, aes(x = x, y = y)) +
virids+ geom_hex() + coord_fixed() +
virids+ scale_fill_gradientn(colours = viridis(256, option = "D"))
Hit <Return> to see next plot:
viridsR> # using code from RColorBrewer to demo the palette
viridsR> n = 200
viridsR> image(
virids+ 1:n, 1, as.matrix(1:n),
virids+ col = viridis(n, option = "D"),
virids+ xlab = "viridis n", ylab = "", xaxt = "n", yaxt = "n", bty = "n"
virids+ )
Hit <Return> to see next plot:
R>
-------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: viridis_bug_example.R URL: <https://stat.ethz.ch/pipermail/r-sig-debian/attachments/20200430/76ca7904/attachment-0001.ksh> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sessionInfo.txt URL: <https://stat.ethz.ch/pipermail/r-sig-debian/attachments/20200430/76ca7904/attachment-0001.txt>
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 ?)
What does capabilities() say? Anything missing? On 19.10 I have
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
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
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 have
below 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
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
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
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
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 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.
That is most helpful! It could potentially affect lots of other users too.
And on the aforementioned rocker/r-ubuntu:20.04 image, if upgrade to
libopenblas-dev I get it too:
root at d9a07e9f0e5f:/work# apt install libopenblas-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
libopenblas-pthread-dev libopenblas0 libopenblas0-pthread
The following NEW packages will be installed:
libopenblas-dev libopenblas-pthread-dev libopenblas0 libopenblas0-pthread
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 13.7 MB of archives.
After this operation, 153 MB of additional disk space will be used.
Do you want to continue? [Y/n]
and then 'example(solve)' hangs at
sh8 <- solve(h8)
Not good at all.
Dirk
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
On 30 April 2020 at 10:01, Dirk Eddelbuettel wrote:
|
| 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 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. | | That is most helpful! It could potentially affect lots of other users too. | | And on the aforementioned rocker/r-ubuntu:20.04 image, if upgrade to | libopenblas-dev I get it too: | | root at d9a07e9f0e5f:/work# apt install libopenblas-dev | Reading package lists... Done | Building dependency tree | Reading state information... Done | The following additional packages will be installed: | libopenblas-pthread-dev libopenblas0 libopenblas0-pthread | The following NEW packages will be installed: | libopenblas-dev libopenblas-pthread-dev libopenblas0 libopenblas0-pthread | 0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded. | Need to get 13.7 MB of archives. | After this operation, 153 MB of additional disk space will be used. | Do you want to continue? [Y/n] | | and then 'example(solve)' hangs at | | sh8 <- solve(h8) | | Not good at all. Same on Debian. Dirk
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org