Re: [Bioc-devel] DataFrameList to Wide Format DataFrame
Hello, Ah, yes, the sample names should of course be in the rows - Friday afternoon error. In the question, I specified "largely the same set of features", implying that the overlap is not complete. So, the example below will error. DFL <- DataFrameList(X = DataFrame(a = 1:3, b = 3:1, row.names = LETTERS[1:3]), Y = DataFrame(b = 4:6, c = 6:4, row.names = LETTERS[20:22])) unlist(DFL) Error in .aggregate_and_align_all_colnames(all_colnames, strict.colnames = strict.colnames) : the DFrame objects to combine must have the same column names This is long but works: allFeatures <- unique(unlist(lapply(DFL, colnames))) DFL <- lapply(DFL, function(DF) { missingFeatures <- setdiff(allFeatures, colnames(DF)) DF[missingFeatures] <- NA DF }) DFLflattened <- do.call(rbind, DFL) Is there a one-line function for it? -- Dario Strbenac University of Sydney Camperdown NSW 2050 Australia ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] DataFrameList to Wide Format DataFrame
A metadata column on a DataFrame runs along its 2nd dimension so is not a good place to put the list names. Have you tried unlist()? library(S4Vectors) DF <- DataFrame(id=letters[1:10], score=runif(10)) f <- sample(LETTERS[1:3], 10, replace=TRUE) DFL <- split(DF, f) DFL # SplitDataFrameList of length 3 # $A # DataFrame with 2 rows and 2 columns # id score # # 1 f 0.894709 # 2 h 0.801125 # # $B # DataFrame with 1 row and 2 columns # id score # # 1 d 0.538166 # # $C # DataFrame with 7 rows and 2 columns # id score # # 1 a 0.0145477 # 2 b 0.2507581 # 3 c 0.4388678 # 4 e 0.5219524 # 5 g 0.6377634 # 6 i 0.1892103 # 7 j 0.1829650 unlist(DFL) # DataFrame with 10 rows and 2 columns # id score # # A f 0.8947085 # A h 0.8011255 # B d 0.5381664 # C a 0.0145477 # C b 0.2507581 # C c 0.4388678 # C e 0.5219524 # C g 0.6377634 # C i 0.1892103 # C j 0.1829650 BTW this is a user question so is more appropriate for the support site. H. On 16/12/2021 22:00, Dario Strbenac via Bioc-devel wrote: Good day, Is there a function in the S4Vectors API which converts a DataFrameList into a DataFrame, automatically putting the list names into one of the metadata columns, analogous to MultiAssayExperiment's wideFormat function? The scenario is mutliple data sets from different organisations measuring the largely the same set of features and patient outcome, but on completely different sets of patients in each organisation. -- Dario Strbenac University of Sydney Camperdown NSW 2050 Australia ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] DataFrameList to Wide Format DataFrame
Good day, Is there a function in the S4Vectors API which converts a DataFrameList into a DataFrame, automatically putting the list names into one of the metadata columns, analogous to MultiAssayExperiment's wideFormat function? The scenario is mutliple data sets from different organisations measuring the largely the same set of features and patient outcome, but on completely different sets of patients in each organisation. -- Dario Strbenac University of Sydney Camperdown NSW 2050 Australia ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [R-pkg-devel] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts
Yes, it's my fault that I didn't consider the case when no fonts are available. I'll improve the code until the next submission to CRAN. Thanks for your advice! Best, Hiroaki Yutani 2021年12月17日(金) 1:40 Tomas Kalibera : > > > On 12/16/21 5:16 PM, Hiroaki Yutani wrote: > > Thanks for the details and the suggestions. My package uses > > systemfonts package for illustration purposes only in the examples, so > > I'm not that desperate to find the root cause this time. I'll try > > using winbuilder in case I need to. > > I see. Maybe best then making the example more robust when no fonts are > found, on different platforms. > > Best > Tomas > > > > > Best, > > Hiroaki Yutani > > > > 2021年12月17日(金) 0:52 Tomas Kalibera : > > > >> > >> On 12/16/21 4:17 PM, Hiroaki Yutani wrote: > This would be an empty character vector on my Alpine Linux server as > well. > >>> I see, thanks for the information. Sorry for my lack of consideration on > >>> this. > >>> > So there are 127 *.ttf files installed, but systemfonts::system_fonts() > does not find any of these. > >>> Thanks for investigating quickly! Then, it seems I should wait for the > >>> problem to be solved on systemfonts' side. I'm curious what's the > >>> difference between r-devel-windows-x86_64-new-TK, on which the check > >>> doesn't fail, by the way. > >> It is also Windows Server 2022 with GUI, a quite fresh installation. The > >> checks run in a docker container (also WS2022, > >> mcr.microsoft.com/windows/server:ltsc2022, without any manually > >> installed fonts). > >> > >> Actually there is no manually installed software there, all that is > >> installed is (in this order): > >> > >> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt/r/setup_miktex_standalone.ps1 > >> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r/setup.ps1 > >> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r_packages/setup_checks.ps1 > >> > >> plus R and R packages. > >> > >> I assume you can reproduce on Winbuilder, and so perhaps you could > >> create a version of your package with a lot of instrumentation/print > >> messages and submit there to find the cause? Possibly also an > >> instrumented variant of systemfonts. > >> > >> Best > >> Tomas > >> > >>> Best, > >>> Hiroaki Yutani > >>> > >>> 2021年12月16日(木) 23:57 Uwe Ligges : > > On 16.12.2021 15:34, Sebastian Meyer wrote: > > Am 16.12.21 um 15:06 schrieb Hiroaki Yutani: > >> Hi, > >> > >> My package is failing on CRAN check on r-devel-windows-x86_64-new-UL. > >> > >> https://cran.r-project.org/web/checks/check_results_string2path.html > >> > >> It seems the problem is that there is no available font that meets the > >> condition in the following code. Is it irrational to assume at least > >> one TrueType or OpenType font is installed in the system? > >> > >>available_fonts <- systemfonts::system_fonts()$path > >> > >># string2path supports only TrueType or OpenType formats > >>ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$", > >> available_fonts)] > >> > The machine that is running " r-devel-windows-x86_64-new-UL" is a > freshly installed Windows Server 2022 with GUI. The standard fonts are > available, but no extra fonts isntalled. > > To confirm: > > > table(gsub(".*\\.(.{3})$", "\\1", dir("c:/WIndows/fonts"))) > > dat fon ini ttc ttf xml > 1 192 1 16 127 1 > > > So there are 127 *.ttf files installed, but systemfonts::system_fonts() > does not find any of these. > > Best, > Uwe Ligges > > > > > > > This would be an empty character vector on my Alpine Linux server as > > well. The system_fonts() there only contain ".pcf.gz" files from > > "/usr/share/fonts/misc/". > > > > Note that the "systemfonts" package on which you rely currently also > > fails on that CRAN check flavour for a similar reason > > (https://cran.r-project.org/web/checks/check_results_systemfonts.html). > > On my Alpine Linux system, from example("register_font", > > package="systemfonts"): > > > > fonts <- system_fonts() > > plain <- sample(which(!fonts$italic & fonts$weight <= 'normal'), 1) > > bold <- sample(which(!fonts$italic & fonts$weight > 'normal'), 1) > > italic <- sample(which(fonts$italic & fonts$weight <= 'normal'), 1) > > ## Error in sample.int(length(x), size, replace, prob) : > > ## invalid first argument > > > > (as there are no italic fonts). > > > > HTH, > > > >Sebastian Meyer > > > >> I'm wondering if I need to release a new version to avoid this test > >> failure. Note that, the other Windows r-devel machine > >> (r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just > >> that something is wrong with
Re: [R-pkg-devel] pandoc missing on r-{release,oldrel}-macos-x86_64
On 17 December 2021 at 09:51, Simon Urbanek wrote: | Sure, installed pandoc 2.16.2. Perfect, thank you! Dirk | Cheers, | Simon | | | > On Dec 17, 2021, at 9:21 AM, Dirk Eddelbuettel wrote: | > | > | > CRAN results flag NOTEs on the two platforms | > r-release-macos-x86_64 | > r-oldrel-macos-x86_64 | > because `pandoc` is apparently missing. These platforms being somewhat | > common, could pandoc be installed? Or are they running such a jurassic | > version that no premade pandoc is available _anywhere_ ? | > | > Simon, can you advise? | > | > Thanks, Dirk | > | > -- | > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | > | -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] pandoc missing on r-{release,oldrel}-macos-x86_64
Sure, installed pandoc 2.16.2. Cheers, Simon > On Dec 17, 2021, at 9:21 AM, Dirk Eddelbuettel wrote: > > > CRAN results flag NOTEs on the two platforms > r-release-macos-x86_64 > r-oldrel-macos-x86_64 > because `pandoc` is apparently missing. These platforms being somewhat > common, could pandoc be installed? Or are they running such a jurassic > version that no premade pandoc is available _anywhere_ ? > > Simon, can you advise? > > Thanks, Dirk > > -- > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] pandoc missing on r-{release,oldrel}-macos-x86_64
CRAN results flag NOTEs on the two platforms r-release-macos-x86_64 r-oldrel-macos-x86_64 because `pandoc` is apparently missing. These platforms being somewhat common, could pandoc be installed? Or are they running such a jurassic version that no premade pandoc is available _anywhere_ ? Simon, can you advise? Thanks, Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts
Thanks for the details and the suggestions. My package uses systemfonts package for illustration purposes only in the examples, so I'm not that desperate to find the root cause this time. I'll try using winbuilder in case I need to. Best, Hiroaki Yutani 2021年12月17日(金) 0:52 Tomas Kalibera : > > > On 12/16/21 4:17 PM, Hiroaki Yutani wrote: > >> This would be an empty character vector on my Alpine Linux server as > >> well. > > I see, thanks for the information. Sorry for my lack of consideration on > > this. > > > >> So there are 127 *.ttf files installed, but systemfonts::system_fonts() > >> does not find any of these. > > Thanks for investigating quickly! Then, it seems I should wait for the > > problem to be solved on systemfonts' side. I'm curious what's the > > difference between r-devel-windows-x86_64-new-TK, on which the check > > doesn't fail, by the way. > > It is also Windows Server 2022 with GUI, a quite fresh installation. The > checks run in a docker container (also WS2022, > mcr.microsoft.com/windows/server:ltsc2022, without any manually > installed fonts). > > Actually there is no manually installed software there, all that is > installed is (in this order): > > https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt/r/setup_miktex_standalone.ps1 > https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r/setup.ps1 > https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r_packages/setup_checks.ps1 > > plus R and R packages. > > I assume you can reproduce on Winbuilder, and so perhaps you could > create a version of your package with a lot of instrumentation/print > messages and submit there to find the cause? Possibly also an > instrumented variant of systemfonts. > > Best > Tomas > > > > > Best, > > Hiroaki Yutani > > > > 2021年12月16日(木) 23:57 Uwe Ligges : > >> > >> > >> On 16.12.2021 15:34, Sebastian Meyer wrote: > >>> Am 16.12.21 um 15:06 schrieb Hiroaki Yutani: > Hi, > > My package is failing on CRAN check on r-devel-windows-x86_64-new-UL. > > https://cran.r-project.org/web/checks/check_results_string2path.html > > It seems the problem is that there is no available font that meets the > condition in the following code. Is it irrational to assume at least > one TrueType or OpenType font is installed in the system? > > available_fonts <- systemfonts::system_fonts()$path > > # string2path supports only TrueType or OpenType formats > ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$", > available_fonts)] > > >> The machine that is running " r-devel-windows-x86_64-new-UL" is a > >> freshly installed Windows Server 2022 with GUI. The standard fonts are > >> available, but no extra fonts isntalled. > >> > >> To confirm: > >> > >> > table(gsub(".*\\.(.{3})$", "\\1", dir("c:/WIndows/fonts"))) > >> > >> dat fon ini ttc ttf xml > >> 1 192 1 16 127 1 > >> > >> > >> So there are 127 *.ttf files installed, but systemfonts::system_fonts() > >> does not find any of these. > >> > >> Best, > >> Uwe Ligges > >> > >> > >> > >> > >> > >>> This would be an empty character vector on my Alpine Linux server as > >>> well. The system_fonts() there only contain ".pcf.gz" files from > >>> "/usr/share/fonts/misc/". > >>> > >>> Note that the "systemfonts" package on which you rely currently also > >>> fails on that CRAN check flavour for a similar reason > >>> (https://cran.r-project.org/web/checks/check_results_systemfonts.html). > >>> On my Alpine Linux system, from example("register_font", > >>> package="systemfonts"): > >>> > >>> fonts <- system_fonts() > >>> plain <- sample(which(!fonts$italic & fonts$weight <= 'normal'), 1) > >>> bold <- sample(which(!fonts$italic & fonts$weight > 'normal'), 1) > >>> italic <- sample(which(fonts$italic & fonts$weight <= 'normal'), 1) > >>> ## Error in sample.int(length(x), size, replace, prob) : > >>> ## invalid first argument > >>> > >>> (as there are no italic fonts). > >>> > >>> HTH, > >>> > >>> Sebastian Meyer > >>> > I'm wondering if I need to release a new version to avoid this test > failure. Note that, the other Windows r-devel machine > (r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just > that something is wrong with r-devel-windows-x86_64-new-UL. > > Any suggestions? > > Best, > Hiroaki Yutani > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > >>> __ > >>> R-package-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel __
Re: [R-pkg-devel] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts
On 12/16/21 4:17 PM, Hiroaki Yutani wrote: This would be an empty character vector on my Alpine Linux server as well. I see, thanks for the information. Sorry for my lack of consideration on this. So there are 127 *.ttf files installed, but systemfonts::system_fonts() does not find any of these. Thanks for investigating quickly! Then, it seems I should wait for the problem to be solved on systemfonts' side. I'm curious what's the difference between r-devel-windows-x86_64-new-TK, on which the check doesn't fail, by the way. It is also Windows Server 2022 with GUI, a quite fresh installation. The checks run in a docker container (also WS2022, mcr.microsoft.com/windows/server:ltsc2022, without any manually installed fonts). Actually there is no manually installed software there, all that is installed is (in this order): https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt/r/setup_miktex_standalone.ps1 https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r/setup.ps1 https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r_packages/setup_checks.ps1 plus R and R packages. I assume you can reproduce on Winbuilder, and so perhaps you could create a version of your package with a lot of instrumentation/print messages and submit there to find the cause? Possibly also an instrumented variant of systemfonts. Best Tomas Best, Hiroaki Yutani 2021年12月16日(木) 23:57 Uwe Ligges : On 16.12.2021 15:34, Sebastian Meyer wrote: Am 16.12.21 um 15:06 schrieb Hiroaki Yutani: Hi, My package is failing on CRAN check on r-devel-windows-x86_64-new-UL. https://cran.r-project.org/web/checks/check_results_string2path.html It seems the problem is that there is no available font that meets the condition in the following code. Is it irrational to assume at least one TrueType or OpenType font is installed in the system? available_fonts <- systemfonts::system_fonts()$path # string2path supports only TrueType or OpenType formats ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$", available_fonts)] The machine that is running " r-devel-windows-x86_64-new-UL" is a freshly installed Windows Server 2022 with GUI. The standard fonts are available, but no extra fonts isntalled. To confirm: > table(gsub(".*\\.(.{3})$", "\\1", dir("c:/WIndows/fonts"))) dat fon ini ttc ttf xml 1 192 1 16 127 1 So there are 127 *.ttf files installed, but systemfonts::system_fonts() does not find any of these. Best, Uwe Ligges This would be an empty character vector on my Alpine Linux server as well. The system_fonts() there only contain ".pcf.gz" files from "/usr/share/fonts/misc/". Note that the "systemfonts" package on which you rely currently also fails on that CRAN check flavour for a similar reason (https://cran.r-project.org/web/checks/check_results_systemfonts.html). On my Alpine Linux system, from example("register_font", package="systemfonts"): fonts <- system_fonts() plain <- sample(which(!fonts$italic & fonts$weight <= 'normal'), 1) bold <- sample(which(!fonts$italic & fonts$weight > 'normal'), 1) italic <- sample(which(fonts$italic & fonts$weight <= 'normal'), 1) ## Error in sample.int(length(x), size, replace, prob) : ## invalid first argument (as there are no italic fonts). HTH, Sebastian Meyer I'm wondering if I need to release a new version to avoid this test failure. Note that, the other Windows r-devel machine (r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just that something is wrong with r-devel-windows-x86_64-new-UL. Any suggestions? Best, Hiroaki Yutani __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts
> This would be an empty character vector on my Alpine Linux server as > well. I see, thanks for the information. Sorry for my lack of consideration on this. > So there are 127 *.ttf files installed, but systemfonts::system_fonts() > does not find any of these. Thanks for investigating quickly! Then, it seems I should wait for the problem to be solved on systemfonts' side. I'm curious what's the difference between r-devel-windows-x86_64-new-TK, on which the check doesn't fail, by the way. Best, Hiroaki Yutani 2021年12月16日(木) 23:57 Uwe Ligges : > > > > On 16.12.2021 15:34, Sebastian Meyer wrote: > > Am 16.12.21 um 15:06 schrieb Hiroaki Yutani: > >> Hi, > >> > >> My package is failing on CRAN check on r-devel-windows-x86_64-new-UL. > >> > >> https://cran.r-project.org/web/checks/check_results_string2path.html > >> > >> It seems the problem is that there is no available font that meets the > >> condition in the following code. Is it irrational to assume at least > >> one TrueType or OpenType font is installed in the system? > >> > >> available_fonts <- systemfonts::system_fonts()$path > >> > >> # string2path supports only TrueType or OpenType formats > >> ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$", > >> available_fonts)] > >> > > The machine that is running " r-devel-windows-x86_64-new-UL" is a > freshly installed Windows Server 2022 with GUI. The standard fonts are > available, but no extra fonts isntalled. > > To confirm: > > > table(gsub(".*\\.(.{3})$", "\\1", dir("c:/WIndows/fonts"))) > > dat fon ini ttc ttf xml >1 192 1 16 127 1 > > > So there are 127 *.ttf files installed, but systemfonts::system_fonts() > does not find any of these. > > Best, > Uwe Ligges > > > > > > > This would be an empty character vector on my Alpine Linux server as > > well. The system_fonts() there only contain ".pcf.gz" files from > > "/usr/share/fonts/misc/". > > > > Note that the "systemfonts" package on which you rely currently also > > fails on that CRAN check flavour for a similar reason > > (https://cran.r-project.org/web/checks/check_results_systemfonts.html). > > On my Alpine Linux system, from example("register_font", > > package="systemfonts"): > > > > fonts <- system_fonts() > > plain <- sample(which(!fonts$italic & fonts$weight <= 'normal'), 1) > > bold <- sample(which(!fonts$italic & fonts$weight > 'normal'), 1) > > italic <- sample(which(fonts$italic & fonts$weight <= 'normal'), 1) > > ## Error in sample.int(length(x), size, replace, prob) : > > ## invalid first argument > > > > (as there are no italic fonts). > > > > HTH, > > > > Sebastian Meyer > > > >> I'm wondering if I need to release a new version to avoid this test > >> failure. Note that, the other Windows r-devel machine > >> (r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just > >> that something is wrong with r-devel-windows-x86_64-new-UL. > >> > >> Any suggestions? > >> > >> Best, > >> Hiroaki Yutani > >> > >> __ > >> R-package-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-package-devel > >> > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts
On 16.12.2021 15:34, Sebastian Meyer wrote: Am 16.12.21 um 15:06 schrieb Hiroaki Yutani: Hi, My package is failing on CRAN check on r-devel-windows-x86_64-new-UL. https://cran.r-project.org/web/checks/check_results_string2path.html It seems the problem is that there is no available font that meets the condition in the following code. Is it irrational to assume at least one TrueType or OpenType font is installed in the system? available_fonts <- systemfonts::system_fonts()$path # string2path supports only TrueType or OpenType formats ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$", available_fonts)] The machine that is running " r-devel-windows-x86_64-new-UL" is a freshly installed Windows Server 2022 with GUI. The standard fonts are available, but no extra fonts isntalled. To confirm: > table(gsub(".*\\.(.{3})$", "\\1", dir("c:/WIndows/fonts"))) dat fon ini ttc ttf xml 1 192 1 16 127 1 So there are 127 *.ttf files installed, but systemfonts::system_fonts() does not find any of these. Best, Uwe Ligges This would be an empty character vector on my Alpine Linux server as well. The system_fonts() there only contain ".pcf.gz" files from "/usr/share/fonts/misc/". Note that the "systemfonts" package on which you rely currently also fails on that CRAN check flavour for a similar reason (https://cran.r-project.org/web/checks/check_results_systemfonts.html). On my Alpine Linux system, from example("register_font", package="systemfonts"): fonts <- system_fonts() plain <- sample(which(!fonts$italic & fonts$weight <= 'normal'), 1) bold <- sample(which(!fonts$italic & fonts$weight > 'normal'), 1) italic <- sample(which(fonts$italic & fonts$weight <= 'normal'), 1) ## Error in sample.int(length(x), size, replace, prob) : ## invalid first argument (as there are no italic fonts). HTH, Sebastian Meyer I'm wondering if I need to release a new version to avoid this test failure. Note that, the other Windows r-devel machine (r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just that something is wrong with r-devel-windows-x86_64-new-UL. Any suggestions? Best, Hiroaki Yutani __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts
Am 16.12.21 um 15:06 schrieb Hiroaki Yutani: Hi, My package is failing on CRAN check on r-devel-windows-x86_64-new-UL. https://cran.r-project.org/web/checks/check_results_string2path.html It seems the problem is that there is no available font that meets the condition in the following code. Is it irrational to assume at least one TrueType or OpenType font is installed in the system? available_fonts <- systemfonts::system_fonts()$path # string2path supports only TrueType or OpenType formats ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$", available_fonts)] This would be an empty character vector on my Alpine Linux server as well. The system_fonts() there only contain ".pcf.gz" files from "/usr/share/fonts/misc/". Note that the "systemfonts" package on which you rely currently also fails on that CRAN check flavour for a similar reason (https://cran.r-project.org/web/checks/check_results_systemfonts.html). On my Alpine Linux system, from example("register_font", package="systemfonts"): fonts <- system_fonts() plain <- sample(which(!fonts$italic & fonts$weight <= 'normal'), 1) bold <- sample(which(!fonts$italic & fonts$weight > 'normal'), 1) italic <- sample(which(fonts$italic & fonts$weight <= 'normal'), 1) ## Error in sample.int(length(x), size, replace, prob) : ## invalid first argument (as there are no italic fonts). HTH, Sebastian Meyer I'm wondering if I need to release a new version to avoid this test failure. Note that, the other Windows r-devel machine (r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just that something is wrong with r-devel-windows-x86_64-new-UL. Any suggestions? Best, Hiroaki Yutani __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts
Hi, My package is failing on CRAN check on r-devel-windows-x86_64-new-UL. https://cran.r-project.org/web/checks/check_results_string2path.html It seems the problem is that there is no available font that meets the condition in the following code. Is it irrational to assume at least one TrueType or OpenType font is installed in the system? available_fonts <- systemfonts::system_fonts()$path # string2path supports only TrueType or OpenType formats ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$", available_fonts)] I'm wondering if I need to release a new version to avoid this test failure. Note that, the other Windows r-devel machine (r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just that something is wrong with r-devel-windows-x86_64-new-UL. Any suggestions? Best, Hiroaki Yutani __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] build failure: 'hashtab' is not an exported object from 'namespace:utils'
On Thu, 16 Dec 2021 09:57:40 + Prof Brian Ripley wrote: > On 16/12/2021 09:13, Stephen Berman wrote: >> I just did `svn up' on the R development sources, switched to the build >> directory (I build R out of tree), ran make, and got this: > > Precisely which version of R-devel updating from which version? -- this is an > area that has changed frequently in the last several days. Yes, it's been more than a month since my last build: I updated from r81161 | maechler | 2021-11-08 14:30:50 +0100 (Mon, 08 Nov 2021) | 1 line to r81384 | pd | 2021-12-16 01:20:16 +0100 (Thu, 16 Dec 2021) | 1 line > I suspect 'make clean' is not enough -- use 'make distclean' for an ab initio > build. That certainly gave me a clean slate -- and the build then succeeded. Thanks. On Thu, 16 Dec 2021 12:58:55 +0300 Ivan Krylov wrote: > On Thu, 16 Dec 2021 10:13:11 +0100 > Stephen Berman wrote: > >> Is this a known issue and is there a fix? > > For me, the fix was to remove the already-installed > $SVNROOT/library/utils (which didn't yet contain hashtab) and re-run > make, letting the R build process re-install it from scratch. I guess that would have been $BUILD/library/utils for me? Perhaps that would have shortened the build time, but I had already done `make distclean' and a complete rebuild was quick enough. But thanks for the reply. Steve Berman __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] BioC2022 Seattle July 27-29 hybrid conference organizing committee
Correction, I'd like to invite any interested members of the **community** to get involved! Feel free to get in touch with me with any questions. This is a great way to get to know other passionate Bioconductor users and developers while providing a great service to the community. On Thu, Dec 16, 2021 at 1:53 PM Levi Waldron wrote: > I'd like to invite any interested members of the committee to get involved > in organizing BioC2022, planned to be in a hybrid format in Seattle > July 27-29, 2022. There is lots to be done, including sponsorship and > funding, outreach, website, workshop technical organization, program > development, code of conduct communication and enforcement, and local > organization. Please fill out this form if you'd like to get involved: > https://forms.gle/cbjHww7uHJFRzwVx5 > > [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] BioC2022 Seattle July 27-29 hybrid conference organizing committee
I'd like to invite any interested members of the committee to get involved in organizing BioC2022, planned to be in a hybrid format in Seattle July 27-29, 2022. There is lots to be done, including sponsorship and funding, outreach, website, workshop technical organization, program development, code of conduct communication and enforcement, and local organization. Please fill out this form if you'd like to get involved: https://forms.gle/cbjHww7uHJFRzwVx5 [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] build failure: 'hashtab' is not an exported object from 'namespace:utils'
On 16/12/2021 09:13, Stephen Berman wrote: I just did `svn up' on the R development sources, switched to the build directory (I build R out of tree), ran make, and got this: Precisely which version of R-devel updating from which version? -- this is an area that has changed frequently in the last several days. I suspect 'make clean' is not enough -- use 'make distclean' for an ab initio build. make[6]: Entering directory '/home/steve/build/r-devel/src/library/tools/src' ../../../../library/tools/libs/tools.so is unchanged make[6]: Leaving directory '/home/steve/build/r-devel/src/library/tools/src' make[5]: Leaving directory '/home/steve/build/r-devel/src/library/tools/src' make[4]: Leaving directory '/home/steve/build/r-devel/src/library/tools' make[4]: Entering directory '/home/steve/build/r-devel/src/library/tools' installing 'sysdata.rda' Error: 'hashtab' is not an exported object from 'namespace:utils' Execution halted make[4]: *** [/home/steve/src/R/r-devel/share/make/basepkg.mk:151: sysdata] Error 1 make[4]: Leaving directory '/home/steve/build/r-devel/src/library/tools' make[3]: *** [Makefile:36: all] Error 2 make[3]: Leaving directory '/home/steve/build/r-devel/src/library/tools' make[2]: *** [Makefile:37: R] Error 1 make[2]: Leaving directory '/home/steve/build/r-devel/src/library' make[1]: *** [Makefile:28: R] Error 1 make[1]: Leaving directory '/home/steve/build/r-devel/src' make: *** [Makefile:61: R] Error 1 I then did `make clean', ran configure and make again, and got the same failure. Is this a known issue and is there a fix? Steve Berman __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build failure: 'hashtab' is not an exported object from 'namespace:utils'
On Thu, 16 Dec 2021 10:13:11 +0100 Stephen Berman wrote: > Is this a known issue and is there a fix? For me, the fix was to remove the already-installed $SVNROOT/library/utils (which didn't yet contain hashtab) and re-run make, letting the R build process re-install it from scratch. -- Best regards, Ivan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] build failure: 'hashtab' is not an exported object from 'namespace:utils'
I just did `svn up' on the R development sources, switched to the build directory (I build R out of tree), ran make, and got this: make[6]: Entering directory '/home/steve/build/r-devel/src/library/tools/src' ../../../../library/tools/libs/tools.so is unchanged make[6]: Leaving directory '/home/steve/build/r-devel/src/library/tools/src' make[5]: Leaving directory '/home/steve/build/r-devel/src/library/tools/src' make[4]: Leaving directory '/home/steve/build/r-devel/src/library/tools' make[4]: Entering directory '/home/steve/build/r-devel/src/library/tools' installing 'sysdata.rda' Error: 'hashtab' is not an exported object from 'namespace:utils' Execution halted make[4]: *** [/home/steve/src/R/r-devel/share/make/basepkg.mk:151: sysdata] Error 1 make[4]: Leaving directory '/home/steve/build/r-devel/src/library/tools' make[3]: *** [Makefile:36: all] Error 2 make[3]: Leaving directory '/home/steve/build/r-devel/src/library/tools' make[2]: *** [Makefile:37: R] Error 1 make[2]: Leaving directory '/home/steve/build/r-devel/src/library' make[1]: *** [Makefile:28: R] Error 1 make[1]: Leaving directory '/home/steve/build/r-devel/src' make: *** [Makefile:61: R] Error 1 I then did `make clean', ran configure and make again, and got the same failure. Is this a known issue and is there a fix? Steve Berman __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Feature request: Change default library path on Windows
Thank you for the update. Really helpful! Between this and the unicode changes, the next version will have a very positive impact on Windows users. Best, Steve On Mon, Dec 13, 2021 at 1:02 PM Tomas Kalibera wrote: > The default was now changed in R-devel to the local application data > (e.g. C:\Users\username\AppData\Local), which should solve the issues > with synchronization/backup/etc services and seems to be more in line > with conventions for the OS. It is a hidden folder, to open in Windows > explorer one can use e.g. shell.exec() from R. > > Best > Tomas > > On 7/27/21 1:12 PM, Tomas Kalibera wrote: > > On 7/26/21 1:44 AM, Steve Haroz wrote: > >> Thanks Ben. I just sent a request for a bugzilla login. > >> Jeroen chimed in earlier in support. > > > > Please note this has been reported, discussed and considered already, > > last time in PR#17842 (though proposing a different replacement for > > the default). > > > > I think changing the default from user documents to something else > > would make sense to consider together with some other breaking change > > for users, not in isolation, if at all. While the change may help > > users with a quota on the documents directory (e.g. shared on a cloud, > > backup, etc), it will make it harder to find the library for others, > > who would not notice the change to the documented behavior, and I > > assume that would still be a much larger group. > > > > Of course it does not help that it is not clear what the correct > > location should be now, and certainly there is little hope it won't > > change again, soon. My understanding is that the choice was originally > > correct when made, following the Microsoft guidelines. > > > > As discussed here as well, users may choose their own library path > > (?.libPaths). > > > > The installation location for R itself can be changed e.g. via /DIR > > option of the installer (see /?). This is useful e.g. when installing > > R only for the current user (/CURRENTUSER) and it impacts also the > > location of the library - it is then inside the given tree. > > > > Best > > Tomas > > > > > > > >> > >> Cheers, > >> Steve > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] MS Windows: R does not escape quotes in CLI options the same way as Rterm and Rscript
On 12/15/21 10:48 PM, Henrik Bengtsson wrote: On MS Windows 10, the following works: Rscript --vanilla -e "\"abc\"" [1] "abc" and also: Rterm --vanilla --no-echo -e "\"abc.txt\"" [1] "abc.txt" whereas attempting the same with 'R' fails; R --vanilla --no-echo -e "\"abc.txt\"" Error: object 'abc' not found Execution halted I get this with R 4.1.2 and R Under development (unstable) (2021-12-14 r81376 ucrt). Is this a bug? Yes, R.exe does not properly handle quotes (and backslashes preceding a quote, and trailing backslashes). This is the same as PR#18139 for shQuote(). I will put that on my list Best Tomas /Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] meaning of browser(skipCalls=) [and multiple mouse buttons]
> Frederick Eaton > on Wed, 15 Dec 2021 20:09:46 -0800 writes: > Just following up to check if anyone has had time to look over these patches. > Frederick I strongly guess that nobody has. Let me give you my perception of what you have tried to propose/use, and why I hadn't thought I should put in time for it: You had started the thread by proposing "to override stopifnot()", something which I (even though principal author of the function) don't find a good idea at all: stopifnot() is just one important utility function that will call stop() under some circumstances. If you want to tweak error handling / debugging / browser, .. you need to work on the level of error conditions, their handlers, etc. Secondly, you've mixed this up with mouse button action/interrupt/.. handling which may be a cool and nice idea, but then your `xbindkey`-etc code is, I think, only/entirely for X11-based R interfaces, and I think this would only be a Linux console, possibly one from using ESS (Emacs Speaks Statistics), but most probably (but I'm guessing here) not even relevant when using Rstudio on Linux, and even less relevant for any of the other ways R is used interactively on non-Linux platforms. Maybe it would also apply to *some* uses of R on the Mac, but not even the default R-Mac GUI.. Sorry that this not as much encouraging as it probably should be, but I though you'd rather want *some* feedback than none... Best, Martin > On Wed, Dec 08, 2021 at 12:24:47AM -0800, Frederick Eaton wrote: >> Dear R Core Team, >> >> I'm attaching a proposed patch to hopefully address my confusions regarding the documentation of browser(). I'm not sure if all the material I added is correct, but I made experiments to confirm that the behavior is at least roughly as described. >> >> patch ./src/library/base/man/browser.Rd < browser.patch >> >> Also, here is a patch to support multiple mouse buttons in getGraphicsEvent(). This must be edited before it can be applied, I decided to keep the old code in an 'if(0)' to help make it clearer that my code is essentially doing the same thing. >> >> https://github.com/navarum/tweaks/blob/master/r/patches/0001-Add-support-for-multiple-mouse-buttons.patch >> wget -O - https://raw.githubusercontent.com/navarum/tweaks/master/r/patches/0001-Add-support-for-multiple-mouse-buttons.patch | patch -p1 >> >> It would be useful to have support in R for more than three mouse buttons because this enables the use of the mouse wheel (buttons 4 and 5), which can provide a more convenient interface when adjusting numbers and graphics and so on. I also have shift+wheel bound to buttons 6 and 7 via xbindkeys and xte, which I use for horizontal scrolling, via a trick from the web somewhere: >> >> $ cat .xbindkeysrc.scm | grep xte >> (xbindkey '(shift "b:4") "xte 'mouseclick 6'") >> (xbindkey '(shift "b:5") "xte 'mouseclick 7'") >> >> I hope that these contributions can be found acceptable. >> >> Thank you in advance, >> >> Frederick >> >> >> >> On Mon, Nov 22, 2021 at 09:13:58AM -0800, Frederick Eaton wrote: >>> Dear R Devel, >>> >>> I have been advised to use "options(error=recover)" to enable >>> debugging on errors. But sometimes it would seem more convenient to >>> override "stopifnot", for example: >>> >>> stopifnot = function(b) { if(!b) { browser(skipCalls=1); } } >>> >>> However, this doesn't do what I expected. On looking closer I find >>> that the "skipCalls" argument seems to be ignored except when printing >>> the "Called from: " message; it does not affect the evaluation context >>> or the output of 'where': >>> >>> > var=2; f=function(){var=1; browser(skipCalls=0)}; f() >>> Called from: f() >>> Browse[1]> var >>> [1] 1 >>> Browse[1]> where >>> where 1: f() >>> >>> Browse[1]> Q >>> > var=2; f=function(){var=1; browser(skipCalls=1)}; f() >>> Called from: top level Browse[1]> var >>> [1] 1 >>> Browse[1]> where >>> where 1: f() >>> >>> Browse[1]> Q >>> > var=2; f=function(){var=1; browser(skipCalls=2)}; f() >>> Called from: top level Browse[1]> var >>> [1] 1 >>> Browse[1]> where >>> where 1: f() >>> >>> Browse[1]> Q >>> >>> So it appears that the "browser()" API does not actually make it >>> possible to call this built-in function from within another R function >>> and thereby emulate the same behavior as calling browser() directly. >>> >>> If this is the case, it might be good to have it fixed or documented. >>> I am aware of "browser(expr=)", but this requires editing the >>> particular call that failed. The documentation for "browser()" led me >>> to hope that my use case would be supported, if only because it admits >>> that users might want to