Re: [Rd] Rscript -e EXPR fails to launch if stdin is closed

2022-10-10 Thread Henrik Bengtsson
Thank you Peter for the quick fix. Will this make it into R-patched to become R 4.2.2 soon? I can confirm that the fix resolved also the original problem report involving launching a parallel PSOCK cluster from within a 'processx' background process

Re: [Rd] Rscript -e EXPR fails to launch if stdin is closed

2022-10-10 Thread peter dalgaard
He! Yes, that looks like a blunder. mkstemp() returns -1 on failure, not 0, so the test on ifd (and I suppose also the one on ifp) is wrong. And of course, once you close file descriptor 0, mkstemp() chooses the 1st available fd, i.e. 0, for its return value. -pd > On 9 Oct 2022, at 20:25 ,

[Rd] Pre-allocating serialization memory buffers

2022-10-10 Thread Florian Rupprecht
Hi all, While investigating the performance of different hashing algorithms of the "digest" package, I found that serialization to memory buffers via serialize(obj, connection=NULL) was suspiciously slow for large objects. After looking into the R source I found that the memory buffer grows

Re: [Rd] Rscript -e EXPR fails to launch if stdin is closed

2022-10-10 Thread peter dalgaard
It seems to work simply to do "if (ifd >= 0)..." (the ifp test is fine since ifp is FILE* and initialized to NULL). Will commit (to r-devel for now). -pd > On 10 Oct 2022, at 11:07 , peter dalgaard wrote: > > He! > > Yes, that looks like a blunder. > > mkstemp() returns -1 on failure, not

[R-pkg-devel] Rd cross-references to Suggested package

2022-10-10 Thread Joshua Ulrich
Hi all, I'd like to link to a help page of a package in my package's Suggests. WRE, section 2.5 says, "Historically (before R version 4.1.0), links of the form \link[pkg]{foo} and \link[pkg:bar]{foo} used to be interpreted as links to files foo.html and bar.html in package pkg, respectively. For

Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

2022-10-10 Thread Jeff Newmiller
I have no idea how to get readxl::read_excel to import a timestamp column in a timezone. It is true that Excel has no concept of timezones, but the data one finds there usually came from a text file at some point. Importing as character is a feasible strategy, but trying to convince an

Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

2022-10-10 Thread Alexandre Courtiol
Hi Simon, Thanks for the clarification. >From a naive developer point of view, we were initially baffled that the generic as.POSIXlt() does very different things on a character and on a Date input: as.POSIXlt(as.character(foo), "Europe/Berlin") [1] "1992-09-27 CEST" as.POSIXlt(foo,

Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

2022-10-10 Thread Ben Bolker
Right now as.POSIXlt.Date() is just function (x, ...) .Internal(Date2POSIXlt(x)) How expensive would it be to throw a warning when '...' is provided by the user/discarded ?? Alternately, perhaps the documentation could be amended, although I'm not quite sure what to suggest. (The sentence

[R-pkg-devel] Best way forward on a CRAN archived package

2022-10-10 Thread Diego Hernangómez Herrero
Hi: I have some doubts on how to proceed in this case. I am the developer of tidyterra, and I received an email from CRAN on 23Sep2022 about an issue on the package, setting a deadline on 07Oct2022 to correct it. I sent a patch that was accepted on CRAN on 29Sep2022, that fixed the issue (or at

Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

2022-10-10 Thread Hadley Wickham
On Sun, Oct 9, 2022 at 9:31 PM Jeff Newmiller wrote: > > ... which is why tidyverse functions and Python datetime handling irk me so > much. > > Is tidyverse time handling intrinsically broken? They have a standard > practice of reading time as UTC and then using force_tz to fix the "mistake".

Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

2022-10-10 Thread Simon Urbanek
Liam, I think I have failed to convey my main point in the last e-mail - which was that you want to parse the date/time in the timezone that you care about so in your example that would be > foo <- as.Date(33874, origin = "1899-12-30") > foo [1] "1992-09-27" > as.POSIXlt(as.character(foo),

[R-pkg-devel] Identify Original Column Names of Model Matrix

2022-10-10 Thread Dario Strbenac
Good day, I am developing a wrapper around xgboost which does not (yet - I see that it is on the developer's version 2.0 task list) support factor variable type. It requires input data to be in one-hot encoding, which is created by Matrix::sparse.model.matrix. For further analysis, such as

Re: [Bioc-devel] Issue with a package dependent on rJava

2022-10-10 Thread Hervé Pagès
Thanks Anestis for your analysis and detailed feedback. @J. Aravind: I hope this is helpful. You should be able to reproduce the problem with a recent version of Java. Generally speaking you want to make sure that your package is compatible with reasonably recent versions of Java. FWIW here

Re: [Bioc-devel] Interpreting BiocCheck output

2022-10-10 Thread Sergio Oller
Hi Giulia, hi all I often run BiocCheck::BiocCheck() on my packages and end up with errors, warnings and notes that have not printed specific enough messages, just as you did. When that happens, on the same R terminal, I use: BiocCheck::.BiocCheck$error BiocCheck::.BiocCheck$warning

[Bioc-devel] Version number trouble

2022-10-10 Thread Brüggemann , Mirko
Hello, I’m having some troubles updating my package(BindingSiteFinder) on the devel branch. I’ve made some changes to the code and as always incremented the z part of the version number. Then I realized that the y part of the version number was already changed by the Bioconductor team (to

Re: [Bioc-devel] Version number trouble

2022-10-10 Thread Vincent Carey
Hi Mirko -- the devel branch has an odd y in x.y.z stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES$ cd BindingSiteFinder stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ grep Version DE* Version: 1.3.0 stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ git fetch --all Fetching origin The

Re: [Bioc-devel] Version number trouble

2022-10-10 Thread Brüggemann , Mirko
Hi Vincent, thanks for the clarification. I can now see where I went wrong. I’ve dumped the version number from 1.3.0 to 1.3.1 now. Thanks a lot Mirko Von: Vincent Carey Datum: Montag, 10. Oktober 2022 um 18:26 An: "Brüggemann, Mirko" Cc: "bioc-devel@r-project.org" Betreff: Re: