Re: [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 | e...@debian.org ___ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
Re: [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 have below is the output of `capabilities()` from my system: > capabilities() jpeg pngtiff tcltk X11aqua TRUETRUETRUETRUETRUE FALSE http/ftp sockets libxmlfifo cledit iconv TRUETRUETRUETRUETRUETRUE NLS profmem cairo ICU long.double libcurl TRUETRUETRUETRUETRUETRUE R> capabilities() jpeg pngtiff tcltk X11 TRUETRUETRUETRUETRUE aquahttp/ftp sockets libxmlfifo FALSETRUETRUETRUETRUE cledit iconv NLS profmem cairo FALSETRUETRUETRUETRUE ICU long.double libcurl TRUETRUETRUE R> Dirk ___ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
Re: [R-sig-Debian] problem with `viridis` on Ubuntu 20.04
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 pngtiff tcltk X11 TRUETRUETRUETRUETRUE aquahttp/ftp sockets libxmlfifo FALSETRUETRUETRUETRUE cledit iconv NLS profmem cairo FALSETRUETRUETRUETRUE ICU long.double libcurl TRUETRUETRUE R> Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org ___ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
Re: [R-sig-Debian] problem with `viridis` on Ubuntu 20.04
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(1), y = rnorm(1))
viridsR> ggplot(dat, aes(x = x, y = y)) +
virids+ geom_hex() + coord_fixed() +
virids+ scale_fill_gradientn(colours = viridis(256, option = "D"))
Hit 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 to see next plot:
R>
library(viridisLite)
viridis(3)
R version 4.0.0 (2020-04-24)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04 LTS
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
locale:
[1] LC_CTYPE=it_IT.UTF-8 LC_NUMERIC=C
[3] LC_TIME=it_IT.UTF-8LC_COLLATE=it_IT.UTF-8
[5] LC_MONETARY=it_IT.UTF-8LC_MESSAGES=it_IT.UTF-8
[7] LC_PAPER=it_IT.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=it_IT.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1]
Re: [R-sig-Debian] problem with `viridis` on Ubuntu 20.04
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(1), y = rnorm(1))
viridsR> ggplot(dat, aes(x = x, y = y)) +
virids+ geom_hex() + coord_fixed() +
virids+ scale_fill_gradientn(colours = viridis(256, option = "D"))
Hit 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 to see next plot:
R>
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
R-SIG-Debian mailing list
R-SIG-Debian@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-debian
[R-sig-Debian] problem with `viridis` on Ubuntu 20.04
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 ___ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
Re: [R-sig-Debian] R-4.0.0 and Texlive 2020 installed on EmmabuntusDE4 (Debian Bullseye)
Hi Patrice, Am Mittwoch, 29. April 2020, 11:03:56 CEST schrieb Patrice Kiener: > Hi Johannes, > > > Thank you for your comments. I run >sudo apt install -t bullseye-cran40 r-base > > and have now the current R-4.0.0 in /usr/lib/R with links in the menus > and R-devel R-4.1.0 in ~/patrice/svn/R/r-devel/build. Perfect. Great! > I used sid just to get the full Texlive 2020. I will probably not update > it for a while and have already removed (commented) the sid line in > sources.list as I do not want to break my system with too much fresh > libraries. Indeed, we want to be on the edge for a few software (R, > Texlive) and are conservative for all other parts of the OS. Thanks for > the tips on /etc/apt/preferences. You're welcome! > Regarding the key, you can probably move the section at the top of the > documentation as it is a necessary step. The key currently mentionned in > the instruction is: > sudo apt-key adv --keyserver keys.gnupg.net --recv-key > 'E19F5F87128899B192B1A2C2AD5F960A256A04AF' > > but the one that worked for me (found in one comment in > https://stackoverflow.com/questions/10255082/installing-r-from-cran-ubuntu-r > epository-no-public-key-error) is: > sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys > FCAE2A0E115C3D8A > > The length of digits is different. Maybe one is the shortest version of > the other? Using the full fingerprint prevents forging the repository by uploading a fake key to the keyservers with the same hash string. This is known to have happened to other people. Cheers, Johannes > > Patrice > > > > > Dear Patrice, > > > thanks for sharing your experience with Debian based distributions. It > is amazing how many distros you tested! > > In your situation I would recommend apt pinning for installing texlive > 2020 from Debian sid on Debian bullseye aka testing or related systems. > Simply adding sid sources as you did will make your system upgrade to > sid. It seems you partially upgraded some of your test systems to sid > and were left with broken systems. > > This will also apply to emmabuntü - if you just added the sid repository > without editing /etc/apt/preferences, you will always pull packages from > sid which may be ok for your use case, but you should be aware of it. > > You would need to edit /etc/apt/preferences in order to tell apt to just > use texlive from sid and the other packages from bullseye. > > Regarding the command to add my key, this is actually there, but I > believe it was too far down - I just moved the section on secure apt > before the section on the different distributions. Thanks for the hint! > > Regarding your attempt to use the backports for bullseye on CRAN for > your Emmabuntüs system, chances are it would have worked if you would > have used the command I am listing there (of course adding sudo): > >sudo apt install -t bullseye-cran40 r-base > > instead of simply > >sudo apt install r-base > > However, now you have the newest devel version compiled from sources for > checking your packages on Linux which is nice as well! > > > Kind regards, > > > Johannes > > ___ > R-SIG-Debian mailing list > R-SIG-Debian@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-debian ___ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
Re: [R-sig-Debian] R-4.0.0 and Texlive 2020 installed on EmmabuntusDE4 (Debian Bullseye)
Hi Johannes, Thank you for your comments. I run sudo apt install -t bullseye-cran40 r-base and have now the current R-4.0.0 in /usr/lib/R with links in the menus and R-devel R-4.1.0 in ~/patrice/svn/R/r-devel/build. Perfect. I used sid just to get the full Texlive 2020. I will probably not update it for a while and have already removed (commented) the sid line in sources.list as I do not want to break my system with too much fresh libraries. Indeed, we want to be on the edge for a few software (R, Texlive) and are conservative for all other parts of the OS. Thanks for the tips on /etc/apt/preferences. Regarding the key, you can probably move the section at the top of the documentation as it is a necessary step. The key currently mentionned in the instruction is: sudo apt-key adv --keyserver keys.gnupg.net --recv-key 'E19F5F87128899B192B1A2C2AD5F960A256A04AF' but the one that worked for me (found in one comment in https://stackoverflow.com/questions/10255082/installing-r-from-cran-ubuntu-repository-no-public-key-error) is: sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys FCAE2A0E115C3D8A The length of digits is different. Maybe one is the shortest version of the other? Patrice Dear Patrice, thanks for sharing your experience with Debian based distributions. It is amazing how many distros you tested! In your situation I would recommend apt pinning for installing texlive 2020 from Debian sid on Debian bullseye aka testing or related systems. Simply adding sid sources as you did will make your system upgrade to sid. It seems you partially upgraded some of your test systems to sid and were left with broken systems. This will also apply to emmabuntü - if you just added the sid repository without editing /etc/apt/preferences, you will always pull packages from sid which may be ok for your use case, but you should be aware of it. You would need to edit /etc/apt/preferences in order to tell apt to just use texlive from sid and the other packages from bullseye. Regarding the command to add my key, this is actually there, but I believe it was too far down - I just moved the section on secure apt before the section on the different distributions. Thanks for the hint! Regarding your attempt to use the backports for bullseye on CRAN for your Emmabuntüs system, chances are it would have worked if you would have used the command I am listing there (of course adding sudo): sudo apt install -t bullseye-cran40 r-base instead of simply sudo apt install r-base However, now you have the newest devel version compiled from sources for checking your packages on Linux which is nice as well! Kind regards, Johannes ___ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
