Re: [Rd] dim<-() changed in R-devel; no longer removing "dimnames" when doing dim(x) <- dim(x)

Hi Martin, Henrik, I actually like this change. Makes a lot of sense IMO that dim(x) <- dim(x) be a no-op, or, more generally, that foo(x) <- foo(x) be a no-op for any setter/getter combo. FWIW S4Arrays::set_dim() does that too. It also preserves the dimnames if the right value is only adding

Re: [R-pkg-devel] Matrix and Mac OS

Paul, can you give us a bit more detail? Which package, which build and where you got the errors? Older builds may not have the latest Matrix. Cheers, Simon > On 31/10/2023, at 11:26 AM, Bailey, Paul via R-package-devel > wrote: > > Hi, > > I'm the maintainer for a few packages, one of

[R-pkg-devel] Matrix and Mac OS

Hi, I'm the maintainer for a few packages, one of which is currently failing CRAN checks on Mac OS because Matrix is not available in my required version (the latest). I had to fix a few things due to changes in the latest Matrix package because of how qr works and I thought, given the

Re: [R-pkg-devel] Recent dev version of R CMD check fails when a package function named X also has a parameter named X

Thank you, Deepayan. Commit r85440 appears to solve the problem in emuR. Markus __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] system()/system2() using short paths of commands on Windows?

I have read about "system() not using a shell on Windows" on the help page many times before but never understood what it means technically. Please forgive my ignorance. I still do not understand it, but thanks a lot for the explanation anyway! I'm just curious if the full path would work in

Re: [Rd] system()/system2() using short paths of commands on Windows?

On 30/10/2023 16:18, Yihui Xie wrote: Hi, It may have been so for 20+ years but I just discovered today that system() would always try to use the short path of a command on Windows: https://github.com/wch/r-source/blob/635a67/src/gnuwin32/run.c#L141 If that's true, I wonder if it could provide

Re: [R-pkg-devel] Recent dev version of R CMD check fails when a package function named X also has a parameter named X

On Mon, 30 Oct 2023 at 12:48, Markus Jochim wrote: > > Hi R people, > > I am the maintainer of the emuR package and I am having a problem with > recent versions of R CMD check. > > CRAN‘s r-devel test suites [1] have started to emit a NOTE about the > HTML version of the manual: > > > Version:

Re: [Rd] system()/system2() using short paths of commands on Windows?

Sure. I'm not sure if it's possible to make it easier to reproduce, but for now the example would require installing TinyTeX (via tinytex::install_tinytex(), which can be later uninstalled cleanly via tinytex::uninstall_tinytex() after you finish the investigation). Then run:

Re: [Rd] system()/system2() using short paths of commands on Windows?

On 10/30/23 17:18, Yihui Xie wrote: Hi, It may have been so for 20+ years but I just discovered today that system() would always try to use the short path of a command on Windows: https://github.com/wch/r-source/blob/635a67/src/gnuwin32/run.c#L141 If that's true, I wonder if it could provide

[R-pkg-devel] Recent dev version of R CMD check fails when a package function named X also has a parameter named X

Hi R people, I am the maintainer of the emuR package and I am having a problem with recent versions of R CMD check. CRAN‘s r-devel test suites [1] have started to emit a NOTE about the HTML version of the manual: Version: 2.4.1 Check: HTML version of manual Result: NOTE     Found the

[Rd] system()/system2() using short paths of commands on Windows?

Hi, It may have been so for 20+ years but I just discovered today that system() would always try to use the short path of a command on Windows: https://github.com/wch/r-source/blob/635a67/src/gnuwin32/run.c#L141 If that's true, I wonder if it could provide an option to disable this behavior,

Re: [R-pkg-devel] Issue with R Package on CRAN - OpenMP and clang17

В Mon, 30 Oct 2023 15:58:31 +0100 (CET) Romain Pierlot пишет: > I'm sorry to disturb, I hope I send a mail at the right place. This is exactly the right place to ask. Welcome to R-package-devel! > It appears that I have addressed the Fortran issues, but upon > resubmission to CRAN, the

Re: [Bioc-devel] No cairo device on merida1

This is a known issue that Cairo isn't enabled for the R 4.4 macos binaries that are installed on the macOS devel builders. Unfortunately this impacts a lot of packages. No action is needed. We appreciate your patience while waiting for the issue to be resolved upstream or until a suitable

Re: [R-pkg-devel] Too many cores used in examples (not caused by data.table)

I have some better news. While we established that 'in theory' setting the environment variable OMP_NUM_THREADS would help (and I maintain that it is a great PITA that CRAN does not do so as a general fix for this issue) it does *not help* once R is started. OpenMP only considers the variable

Re: [Rd] Wayland Display Support in R Plot

El lun., 30 oct. 2023 12:26, Roger Bivand escribió: > I also noticed this: > > https://www.theregister.com/2023/10/13/gnome_proposes_dropping_x11/ > > which is concerning. Until now, I've retained X11 on Fedora because of > difficulties in screen sharing via zoom in Wayland sessions. > KDE

Re: [Rd] Wayland Display Support in R Plot

On 30 October 2023 at 13:17, Willem Ligtenberg via R-devel wrote: | I just tried it on Ubuntu 23.10. It seems to just work. | See screenshot here: https://nextcloud.wligtenberg.nl/s/jnbDT4ZiHw2JQ8H | I should be using wayland, and as far as I know I haven't done anything | special to make this

Re: [Rd] Wayland Display Support in R Plot

On 29-10-2023 22:29, Dirk Eddelbuettel wrote: > On 30 October 2023 at 09:20, Simon Urbanek wrote: > | > On 30/10/2023, at 8:38 AM, Dirk Eddelbuettel wrote: > | > On 30 October 2023 at 07:54, Paul Murrell wrote: > | > | I am unaware of any Wayland display support. > | > | > | > | One useful way

Re: [Rd] Wayland Display Support in R Plot

I also noticed this: https://www.theregister.com/2023/10/13/gnome_proposes_dropping_x11/ which is concerning. Until now, I've retained X11 on Fedora because of difficulties in screen sharing via zoom in Wayland sessions. Roger -- Roger Bivand Emeritus Professor Norwegian School of Economics

Re: [Bioc-devel] [ext] Re: RCAS build error on Nebbiolo2 - Missing BiocManager

Yes adding BiocManager to the suggest field of your DESCRIPTION will likely correct the ERROR Lori Shepherd - Kern Bioconductor Core Team Roswell Park Comprehensive Cancer Center Department of Biostatistics & Bioinformatics Elm & Carlton Streets Buffalo, New York 14263

Re: [Bioc-devel] Change package name

This is not an easy process and will involve manual intervention from the team. What is the package name? Is it already accepted into Bioconductor or is in still in the submission process? Lori Shepherd - Kern Bioconductor Core Team Roswell Park Comprehensive Cancer Center Department of

Re: [Bioc-devel] Maximum allowed cores on Bioconductor Build System?

I believe the recommendation is not to use more than 2 cores. Lori Shepherd - Kern Bioconductor Core Team Roswell Park Comprehensive Cancer Center Department of Biostatistics & Bioinformatics Elm & Carlton Streets Buffalo, New York 14263 From: Bioc-devel

Re: [Bioc-devel] [ext] Re: RCAS build error on Nebbiolo2 - Missing BiocManager

Dear Herve & Kasper, Thank you very much for your responses. The checkSeqDb(‘hg19’) function calls the BSgenome::available.genomes function which in turn calls “get_data_annotation_contrib_url“. The method tries to access

Re: [Rd] dim<-() changed in R-devel; no longer removing "dimnames" when doing dim(x) <- dim(x)

> Henrik Bengtsson > on Sun, 29 Oct 2023 10:42:19 -0700 writes: > Hello, > the fix of PR18612 > (https://bugs.r-project.org/show_bug.cgi?id=18612) in > r85380 > (https://github.com/wch/r-source/commit/2653cc6203fce4c48874111c75bbccac3ac4e803) > caused a

[Bioc-devel] Maximum allowed cores on Bioconductor Build System?

Hi all, I am wondering if there is a maximum allowed number of cores that can be used when building a vignette on the Bioconductor Build System? I make use of parallel computing in one of my vignettes, but if I don't use enough cores, it takes too long to build the vignette and I get a timeout

Re: [R-pkg-devel] Too many cores used in examples (not caused by data.table)

Hi Dirk, Looking more closely earlier failures, vignettes have always worked fine but the note on tests said that the CPU time was only 2.7 times over elapsed time, so maybe I was just lucky this time and got under 2.5. ;) Or testthat does something special... Jouni