[Rd] Generalised piping into operators

I just checked out R-devel and noticed that the new "pipe extractor" capability coming in 4.3 only works for the 4 extractor operators, but no other standard operators like +, *, %*% etc, meaning that e.g. mtcars |> as.matrix() |> _ + 1 |> colMeans() is a syntax error. In addition, we are still

[Rd] Confusion about ks.test() handling of ties and exact vs approximate results

Hello, Today I was investigating ks.test() with two numerical arguments (x and y) and was left a bit confused about the policy behind handling ties. I might be missing something, so sorry in advance, but here is what confuses me: The documentation states: "The presence of ties always generates

Re: [Rd] Feature request: Limiting output of installed.packages()

Le 19/04/2023 à 16:04, Chris Woelkers - NOAA Federal via R-devel a écrit : I'm going to ask this here before submitting it to Bugzilla. Is this a good idea and worthy of being considered? I think it is but others may not feel the same. The installed.packages() function is very useful but can be

[Rd] Feature request: Limiting output of installed.packages()

I'm going to ask this here before submitting it to Bugzilla. Is this a good idea and worthy of being considered? I think it is but others may not feel the same. The installed.packages() function is very useful but can be more information than needed. While the function includes the argument

Re: [Rd] sum(), min(), max(), prod() vs. named arguments in ...

On 2023-04-15 6:00 am, r-devel-requ...@r-project.org wrote: Date: Fri, 14 Apr 2023 13:38:00 +0300 From: Ivan Krylov To:r-devel@r-project.org Subject: [Rd] sum(), min(), max(), prod() vs. named arguments in ... Message-ID: <20230414133800.75383dae-6792@arachnoid> Content-Type: text

Re: [Rd] sum(), min(), max(), prod() vs. named arguments in ...

В Sun, 16 Apr 2023 01:34:33 -0400 Mikael Jagan пишет: > Forbidding or warning against tagged arguments other than 'na.rm' > would be quite intrusive, since it is not uncommon to see > do.call(sum, ). Thank you for providing this counter-example! I did suspect this to be a non-starter, but

Re: [Rd] Unique ID for conditions to supress/rethrow selected conditions?

On 16/04/2023 10:49 a.m., nos...@altfeld-im.de wrote: On Sun, 2023-04-16 at 13:52 +0200, Iñaki Ucar wrote: I agree that something like this would be a nice addition. With the current condition system, it would be certainly easy (but quite a lot of work) to define a hierarchy of built-in

Re: [Rd] Unique ID for conditions to supress/rethrow selected conditions?

On Sun, 2023-04-16 at 13:52 +0200, Iñaki Ucar wrote: > I agree that something like this would be a nice addition. With the > current condition system, it would be certainly easy (but quite a lot > of work) to define a hierarchy of built-in conditions, and then use > them consistently throughout

Re: [Rd] Unique ID for conditions to supress/rethrow selected conditions?

As far as I know there are no reliable unique identifiers. There appears to be a general drift towards classed conditions, but so far only a small subset of conditions are generated that way (and to tell you the truth, I forget how to detect one, even though I contributed some of them to the

Re: [Rd] Unique ID for conditions to supress/rethrow selected conditions?

On Sun, 16 Apr 2023 at 12:58, nos...@altfeld-im.de wrote: > > I am the author of the *tryCatchLog* package and want to > > - suppress selected conditions (warnings and messages) > - rethrow selected conditions (e.g a specific warning as a message or to > "rename" the condition text). > > I

[Rd] Unique ID for conditions to supress/rethrow selected conditions?

I am the author of the *tryCatchLog* package and want to - suppress selected conditions (warnings and messages) - rethrow selected conditions (e.g a specific warning as a message or to "rename" the condition text). I could not find any reliable unique identifier for each possible condition -

[Rd] Possible inconsistency between `as.complex(NA_real_)` and the docs

Hi all, Surprisingly (at least to me), `as.complex(NA_real_)` results in `complex(real = NA_real_, imaginary = 0)` rather than `NA_complex_`. It seems to me that this goes against the docs of `as.complex()`, which say this in the Details section: "Up to R versions 3.2.x, all forms of NA and NaN

[Rd] sum(), min(), max(), prod() vs. named arguments in ...

Hello R-devel, As mentioned on Fosstodon [1] and discussed during RCOH [2], named arguments to sum(), min(), max() and prod() are currently processed the same way as the un-named ones. Additionally, when specifying the na.rm argument more than once, the last specified value is silently taken

Re: [Rd] Archive policy and Rcpp?

Hi Dominick, While somebody from CRAN might eventually reply here, your query is actually OT for R-Devel, which has been, since circa 2015, focused on more technical code development (e.g. C/C++/FORTRAN, etc.) and core R development issues, rather than on CRAN and package development related

[Rd] Archive policy and Rcpp?

It appears that my archived packages Rcpp and RcppTemplate have been removed at CRAN, yet they appeared in the CRAN archives until recently. What is the CRAN policy on archives and removal? Thanks, Dominick [[alternative HTML version deleted]]

Re: [Rd] Error message for infinite probability parameters in rbinom() and rmultinom()

Thanks Duncan and Martin for your answer. > Le 9 avr. 2023 à 00:33, Duncan Murdoch a écrit : > > On 08/04/2023 5:53 p.m., Martin Maechler wrote: >>> Christophe Dutang >>> on Sat, 8 Apr 2023 14:21:53 +0200 writes: >> > Dear all, >> > Using rmultinom() in a stochastic model, I

Re: [Rd] Error message for infinite probability parameters in rbinom() and rmultinom()

On 08/04/2023 5:53 p.m., Martin Maechler wrote: Christophe Dutang on Sat, 8 Apr 2023 14:21:53 +0200 writes: > Dear all, > Using rmultinom() in a stochastic model, I found this function returns an error message 'NA in probability' for an infinite probability. > Maybe, a

Re: [Rd] Error message for infinite probability parameters in rbinom() and rmultinom()

> Christophe Dutang > on Sat, 8 Apr 2023 14:21:53 +0200 writes: > Dear all, > Using rmultinom() in a stochastic model, I found this function returns an error message 'NA in probability' for an infinite probability. > Maybe, a more precise message will be helpful when

[Rd] Error message for infinite probability parameters in rbinom() and rmultinom()

Dear all, Using rmultinom() in a stochastic model, I found this function returns an error message 'NA in probability' for an infinite probability. Maybe, a more precise message will be helpful when debugging. > rmultinom(1, 3:5, c(1/2, 1/3, Inf)) Error in rmultinom(1, 3:5, c(1/2, 1/3, Inf))

[Rd] Time to add is.formula() to 'stats'?

I know that it has been discussed in the past, but I wanted to ask to revisit the idea of exporting is.formula <- function(x) inherits(x, "formula") from 'stats', parallel to is.data.frame() in 'base', given how widely formulae are used these days in conjunction with data frames, even

Re: [Rd] Autocompletion for the new S3 generic @ method?

This should be enabled now in R-devel and R 4.3.0 by writing .AtNames() methods. findMatches() is also exported now; this is basically grep(), but will do fuzzy matching if it's activated. Best, -Deepayan On Mon, Apr 3, 2023 at 9:37 AM Deepayan Sarkar wrote: > > Thanks, we are discussing the

[Rd] An alternative algorithm for `which()`

Hi all, I've sent in a bugzilla patch for an alternative C algorithm for `which()` which uses less memory and is often faster in many real life scenarios. I've documented it in full on the bugzilla page, with many examples: https://bugs.r-project.org/show_bug.cgi?id=18495 The short version is

Re: [Rd] removeSource() vs. function literals

On Fri, 31 Mar 2023 08:49:53 +0200 Lionel Henry wrote: > If you can afford a dependency on rlang, `rlang::zap_srcref()` deals > with this. It's recursive over expression vectors, calls (including > calls to `function` and their hidden srcref arg), and function > objects. Thanks for the

Re: [Rd] removeSource() vs. function literals

Thanks for the comments and sorry I didn't reply sooner! On Thu, 30 Mar 2023 12:38:24 -0400 Duncan Murdoch wrote: > You'd need to recurse through all expressions in the object. Some of > those expressions might be environments, so your changes could leak > out of the function you're working

Re: [Rd] path to rtools not updated in R 4.2.3 - line 1: gcc: command not found

On 4/5/23 07:48, Patrick Giraudoux wrote: Dear listers, I have update to rtools43 and, using R 4.2.3 I have been surprised not to be able to compile packages needing compilation when updating. Looks like the path given in gcc  -I"C:/PROGRA~1/R/R-42~1.3/include" -DNDEBUG -DNTIMER

[Rd] path to rtools not updated in R 4.2.3 - line 1: gcc: command not found

Dear listers, I have update to rtools43 and, using R 4.2.3 I have been surprised not to be able to compile packages needing compilation when updating. Looks like the path given in gcc  -I"C:/PROGRA~1/R/R-42~1.3/include" -DNDEBUG -DNTIMER -I./SuiteSparse_config -DUSE_FC_LEN_T

Re: [Rd] Breaking Change in Rcomplex Layout?

On 4/4/23 11:27, Michael Milton wrote: > I don't think an auto-generated name (along the lines of u or u2) for > the anonymous structs would be helpful here. You can see that bindgen > is already generating a placeholder name ("__bindgen_anon_1"). A > meaningful name might be nice instead,

Re: [Rd] Breaking Change in Rcomplex Layout?

I don't think an auto-generated name (along the lines of u or u2) for the anonymous structs would be helpful here. You can see that bindgen is already generating a placeholder name ("__bindgen_anon_1"). A meaningful name might be nice instead, but I get the impression that isn't an option here

Re: [Rd] Breaking Change in Rcomplex Layout?

On Tue, 4 Apr 2023 09:31:33 +0200 Tomas Kalibera wrote: > it also matters how Rust can handle anonymous nested structures, or > what is the right mapping of the involved C types to Rust It's worth mentioning that Rust's RFC 2102 [1] defines unnamed structs and unions for the purpose of C

Re: [Rd] Breaking Change in Rcomplex Layout?

On 4/4/23 04:27, Michael Milton wrote: > Hi Tomas, > > Thanks for this explanation. As you can probably tell I'm not much of > a C person, so I didn't realise this change would be invisible to C > users. I suppose R's stability contract only applies to C, and > therefore changes that break

Re: [Rd] Breaking Change in Rcomplex Layout?

Hi Tomas, Thanks for this explanation. As you can probably tell I'm not much of a C person, so I didn't realise this change would be invisible to C users. I suppose R's stability contract only applies to C, and therefore changes that break other languages such as Rust are out of scope. You are

Re: [Rd] Let R compile for libcurl8 ?

Am Mon, 3 Apr 2023 15:46:52 +0100 schrieb Prof Brian Ripley : > Again, what exactly is 'R-patched'? R-4.2.3 with R-release.diff from Martin Maechler's machine applied. Downloaded via curl(!) and cron every morning :-) I'll take a look, what went wrong. Thank you Detlef -- "Wozu leben wir,

Re: [Rd] Let R compile for libcurl8 ?

On 03/04/2023 15:24, Detlef Steuer wrote: Am Mon, 3 Apr 2023 15:13:58 +0100 schrieb Prof Brian Ripley : On 03/04/2023 14:07, Detlef Steuer wrote: Hi! The same Inar reported for rawhide (https://stat.ethz.ch/pipermail/r-devel/2023-March/082482.html) is true for SuSE's distros. Right now R

Re: [Rd] Let R compile for libcurl8 ?

Am Mon, 3 Apr 2023 15:13:58 +0100 schrieb Prof Brian Ripley : > On 03/04/2023 14:07, Detlef Steuer wrote: > > Hi! > > > > The same Inar reported for rawhide > > (https://stat.ethz.ch/pipermail/r-devel/2023-March/082482.html) > > is true for SuSE's distros. > > > > Right now R does not compile

Re: [Rd] Breaking Change in Rcomplex Layout?

On 4/3/23 15:50, Michael Milton wrote: > Okay, but I'm afraid this will only mean something to Rust users. The > reason being that we encountered this issue in extendr: a Rust > extension library for R. The specific compiler errors we encounter > happen because bindgen (the Rust code

Re: [Rd] Let R compile for libcurl8 ?

On 03/04/2023 14:07, Detlef Steuer wrote: Hi! The same Inar reported for rawhide (https://stat.ethz.ch/pipermail/r-devel/2023-March/082482.html) is true for SuSE's distros. Right now R does not compile with libcurl8, but SuSE Tumbleweed/Factory switched to 8 a week ago. Would be great, if the

Re: [Rd] Breaking Change in Rcomplex Layout?

Okay, but I'm afraid this will only mean something to Rust users. The reason being that we encountered this issue in extendr: a Rust extension library for R. The specific compiler errors we encounter happen because bindgen (the Rust code generation library) read the changed R header files, and

Re: [Rd] Breaking Change in Rcomplex Layout?

On 4/3/23 14:07, Michael Milton wrote: Hi all, There seems to have been a breaking change in the R trunk caused by a fix to bug 18430 that relates to the layout of the Rcomplex typedef. Previously it was a struct, but now it's a union by

Re: [Rd] Let R compile for libcurl8 ?

On 3 April 2023 at 15:07, Detlef Steuer wrote: | The same Inar reported for rawhide | (https://stat.ethz.ch/pipermail/r-devel/2023-March/082482.html) | is true for SuSE's distros. | | Right now R does not compile with libcurl8, but SuSE Tumbleweed/Factory | switched to 8 a week ago. | | Would

[Rd] Breaking Change in Rcomplex Layout?

Hi all, There seems to have been a breaking change in the R trunk caused by a fix to bug 18430 that relates to the layout of the Rcomplex typedef. Previously it was a struct, but now it's a union by default

[Rd] Let R compile for libcurl8 ?

Hi! The same Inar reported for rawhide (https://stat.ethz.ch/pipermail/r-devel/2023-March/082482.html) is true for SuSE's distros. Right now R does not compile with libcurl8, but SuSE Tumbleweed/Factory switched to 8 a week ago. Would be great, if the patch Inar provided could be applied to

Re: [Rd] Autocompletion for the new S3 generic @ method?

Thanks, we are discussing the details, but we will definitely add something along those lines before 4.3.0 is released. Best, -Deepayan On Sun, Apr 2, 2023 at 6:39 PM Tomasz Kalinowski wrote: > > I agree, this is a good idea and would be very helpful in interactive > contexts. > > I have a

Re: [Rd] Autocompletion for the new S3 generic @ method?

Hi Tomasz, I haven't had a chance to look at your patch yet (also I can't accept it as I'm not on R-core), but patches for consideration should be submitted to bugzilla (https://bugs.r-project.org), not the unofficial github mirror of the the SVN repo. Best, ~G On Sun, Apr 2, 2023 at 6:09 AM

Re: [Rd] Autocompletion for the new S3 generic @ method?

I agree, this is a good idea and would be very helpful in interactive contexts. I have a draft patch implementing this feature here: https://github.com/r-devel/r-svn/pull/122 (Append “.patch” to the URL to get a raw patch.) Regards, Tomasz > On Mar 31, 2023, at 2:11 PM, Karolis K wrote: >

[Rd] setulb() from lbfgsb.c not exported

Hello, It appears that the file ./appl/lbfgsb.c defines setulb() as a static function, and it is included in optim.c, so setulb() is not exported by the R library. I have some sofware that uses setulb() directly, and I would prefer to avoid having to recompile this sofware to export that

[Rd] Autocompletion for the new S3 generic @ method?

Hello, In the current R-devel @ is S3 generic, so we can do things like - for example - use it to extract matrix rows by name: .S3method("@", "mm", function(object, name) object[name,]) m <- structure(matrix(rnorm(20), ncol=2), dimnames=list(paste0("row", 1:10), paste("col", 1:2)),

Re: [Rd] Query: Could documentation include modernized references?

Thanks Martin. Following Duncan's advice as well as some textual input, I have put a proposed Rd file for optim on a fork of the R code at https://github.com/nashjc/r/blob/master/src/library/stats/man/optim.Rd This has the diffs given below from the github master. The suggested changes

Re: [Rd] Query: Could documentation include modernized references?

ols in inappropriate >> circumstances. >> >> Given that it would break too many other packages and >> examples to drop the existing tools, should we at least >> add short notes in the man (.Rd) pages? I'm thinking of >> something like &g

Re: [Rd] removeSource() vs. function literals

On 3/31/23 08:49, Lionel Henry via R-devel wrote: If you can afford a dependency on rlang, `rlang::zap_srcref()` deals with this. It's recursive over expression vectors, calls (including calls to `function` and their hidden srcref arg), and function objects. It's implemented in C for

Re: [Rd] removeSource() vs. function literals

If you can afford a dependency on rlang, `rlang::zap_srcref()` deals with this. It's recursive over expression vectors, calls (including calls to `function` and their hidden srcref arg), and function objects. It's implemented in C for efficiency as we found it to be a bottleneck in some

Re: [Rd] write.csv performance improvements?

Hi Toby et al, On Wed, Mar 29, 2023 at 10:24 PM Toby Hocking wrote: > Dear R-devel, > I did a systematic comparison of write.csv with similar functions, and > observed two asymptotic inefficiencies that could be improved. > > 1. write.csv is quadratic time (N^2) in the number of columns N. >

Re: [Rd] removeSource() vs. function literals

On 30/03/2023 10:32 a.m., Ivan Krylov wrote: Dear R-devel, In a package of mine, I use removeSource on expression objects in order to make expressions that are semantically the same serialize to the same byte sequences: https://github.com/cran/depcache/blob/854d68a/R/fixup.R#L8-L34 Today I

[Rd] removeSource() vs. function literals

Dear R-devel, In a package of mine, I use removeSource on expression objects in order to make expressions that are semantically the same serialize to the same byte sequences: https://github.com/cran/depcache/blob/854d68a/R/fixup.R#L8-L34 Today I learned that expressions containing function

[Rd] write.csv performance improvements?

Dear R-devel, I did a systematic comparison of write.csv with similar functions, and observed two asymptotic inefficiencies that could be improved. 1. write.csv is quadratic time (N^2) in the number of columns N. Can write.csv be improved to use a linear time algorithm, so it can handle CSV files

[Rd] read.csv quadratic time in number of columns

Dear R-devel, A number of people have observed anecdotally that read.csv is slow for large number of columns, for example: https://stackoverflow.com/questions/7327851/read-csv-is-extremely-slow-in-reading-csv-files-with-large-numbers-of-columns I did a systematic comparison of read.csv with

Re: [Rd] Incorrect behavior of ks.test and psmirnov functions with exact=TRUE

> Alexey Sergushichev writes: Thanks. This is now fixed for the upcoming 4.3.0 release. Best -k > HI, > I've noticed what I think is an incorrect behavior of stats::psmirnov > function and consequently of ks.test when run in an exact mode. > For example: > psmirnov(1, sizes=c(50, 50),

Re: [Rd] [External] subfolders in the R folder

On 28/03/2023 2:00 p.m., Henrik Bengtsson wrote: A quick drive-by-comment: What if 'R CMD build' would have an option to flatten R/ subfolders when building the tarball, e.g. R/unix/a.R R/windows/a.R R/a.R becomes: R/00__unix__a.R R/00__windows__a.R R/a.R ? Maybe that would be sufficient

Re: [Rd] [External] subfolders in the R folder

A quick drive-by-comment: What if 'R CMD build' would have an option to flatten R/ subfolders when building the tarball, e.g. R/unix/a.R R/windows/a.R R/a.R becomes: R/00__unix__a.R R/00__windows__a.R R/a.R ? Maybe that would be sufficient for most use cases. The only thing I can imagine is

Re: [Rd] [External] subfolders in the R folder

The "good reason" is all the tooling in R doesn't work with subfolders and would have to be rewritten. All the package check and build stuff. And that's assuming you don't want to change the basic flat package structure - for example to allow something like `library(foo)` to attach a package and

Re: [Rd] subfolders in the R folder

I just found this other discussion, with some more snark (who would have thought this subject would be so slippery!) : https://bugs.r-project.org/show_bug.cgi?id=17258 Duncan makes the argument that R's history shows the feature is not absolutely necessary, but that's what make it a feature

[Rd] subfolders in the R folder

Dear R-devel, Packages don't allow for subfolders in R with a couple exceptions. We find in "Writing R extensions" : > The R and man subdirectories may contain OS-specific subdirectories named unix or windows. This is something I've seen discussed outside of the mailing list numerous times, and

Re: [Rd] Inconsistency in grid::grid.polyline

Hi The general "evolution" of grid.*() functions (that I have written) have tended towards the grid.polyline() style ... grid.*(...) { grid.draw(*Grob(...)) } With my thinking at least heading towards: if you are calling grid.*(), then you want to actually draw something; if you want

Re: [Rd] Query: Could documentation include modernized references?

op the existing tools, should we at least add short notes in the man (.Rd) pages? I'm thinking of something like optim() has methods that are dated. Users are urged to consider suggestions from ... and point to references and/or an appropriate Task View, which could, of course, be i

Re: [Rd] Query: Could documentation include modernized references?

. Given that it would break too many other packages and examples to drop the existing tools, should we at least add short notes in the man (.Rd) pages? I'm thinking of something like optim() has methods that are dated. Users are urged to consider suggestions from ... and point to references

[Rd] Query: Could documentation include modernized references?

packages and examples to drop the existing tools, should we at least add short notes in the man (.Rd) pages? I'm thinking of something like optim() has methods that are dated. Users are urged to consider suggestions from ... and point to references and/or an appropriate Task View, which could

Re: [Rd] Request: better default R_LIBS_USER

On Thu, Mar 23, 2023 at 4:57 PM Gabriel Becker wrote: > Thanks for being interested in making R better. Its great to see engagement > from a new "virtual face", so to speak. That said, without speaking for > R-core, my experience is that the R-project and R-core team place a very high >

Re: [Rd] make file.rename return invisible

> Dipterix Wang > on Fri, 24 Mar 2023 01:12:29 -0400 writes: > Dear R Core devs, > I wonder if it makes sense to make function file.rename return invisible? This is not a big issue, but when running in RMarkdown or knitr, this function will print results. I have to

[Rd] make file.rename return invisible

Dear R Core devs, I wonder if it makes sense to make function file.rename return invisible? This is not a big issue, but when running in RMarkdown or knitr, this function will print results. I have to manually call invisible to hide the output from showing in the final document: ```r

Re: [Rd] Request: better default R_LIBS_USER

Small but crucial typo correction: Perhaps this could be put on the list of possible changes for R 5.0, to be > bundled with other as-yet undecided breaking changes, members of R-core > feel the same way. > *if* members of R-core feel the same way. ~G > > Best, > ~G > > >> Cheers. >> >> --

Re: [Rd] Request: better default R_LIBS_USER

Felipe, Thanks for being interested in making R better. Its great to see engagement from a new "virtual face", so to speak. That said, without speaking for R-core, my experience is that the R-project and R-core team place a very high premium on backwards compatibility. They will make breaking

Re: [Rd] Request: better default R_LIBS_USER

Hi, Pinging. On Thu, Mar 16, 2023 at 7:17 PM Felipe Contreras wrote: > On Thu, Mar 16, 2023 at 4:08 PM Dirk Eddelbuettel wrote: > > On 16 March 2023 at 13:39, Felipe Contreras wrote: > > | R should do the same: it should install packages to somewhere inside > > | ~/.local by default. > >

Re: [Rd] `dendrapply` Enhancements

dicine Department of Biomedical Informatics ah...@pitt.edu (724) 612-9940 From: Ivan Krylov Sent: Thursday, March 23, 2023 6:05:37 AM To: Lakshman, Aidan H Cc: R-devel@r-project.org Subject: Re: [Rd] `dendrapply` Enhancements Hello Aidan, Sorry for droppin

[Rd] Edge case in rm() now failing in R-devel

This is new in R-devel: > rm(list = NULL) Error in rm(list = NULL) : invalid first argument It still works in r84020, but does not in r84023, possibly because of r84022 [1]. Gabor [1] https://github.com/wch/r-source/commit/4dc057f5d49d3c0590488100e418e39b68682c95

Re: [Rd] `dendrapply` Enhancements

Hello Aidan, Sorry for dropping this for a while. В Thu, 2 Mar 2023 21:03:59 + "Lakshman, Aidan H" пишет: > //after > curnode = eval(lang3(R_Bracket2Symbol, parent->node, DEND_IND), env); lang3() always constructs a new language object. If you do end up using eval(), it may make sense to

[Rd] Enable curl 8

Hi, Just a heads-up that curl 8 landed in Fedora Rawhide a couple of days ago. Note that R does **not** compile without a small fix [1] that allows the configuration to continue if the major version is > 7. [1] https://src.fedoraproject.org/rpms/R/blob/rawhide/f/R-4.2.3-curl-v8.patch Best, --

Re: [Rd] Versioning Rtools ARP entries

On 3/13/23 17:57, Tomas Kalibera wrote: On 3/13/23 17:31, Daniel Possenriede wrote: Hi, If I am not mistaken, all Rtools 4.2 (and 4.3) revisions have the same ARP [1] entries, i.e. all report version 4.2.0.1 (or 4.3.0.1). This makes it difficult to determine the installed version (is it

Re: [R-pkg-devel] Check: Rd \usage sections, Result: The \usage entries for S3 methods should use the \method markup and not their full name.

On Tue, 21 Mar 2023 23:08:43 +0100 Yohann Foucher wrote: > Check: Rd \usage sections, Result: NOTE > S3 methods shown with full name in documentation object 'nnet.time': >'nnet.time' > > The \usage entries for S3 methods should use the \method markup and > not their

[R-pkg-devel] Check: Rd \usage sections, Result: The \usage entries for S3 methods should use the \method markup and not their full name.

Maintainer: 'Yohann Foucher mailto:yohann.fouc...@univ-poitiers.fr>>' Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64 Check: Rd \usage sections, Result: NOTE S3 methods shown with full name in documentation object 'nnet.time': 'nnet.time' The \usage entries for S3 methods

[Rd] Floating-point-related surprising behaviour in boot:::norm.inter

Dear all, I have been implementing some bootstrap-related methods, and came across this theoretically undesirable behaviour in the computation of bootstrap quantiles. The manual says: ‘Interpolation on the normal quantile scale is used when a non-integer order statistic is required.’

[Rd] R 4.3.0 scheduled for April 21

Full schedule is available on developer.r-project.org (pending update from SVN). -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com

Re: [Rd] WISH: Optional mechanism preventing var <<- value from assigning non-existing variable

On 19/03/2023 2:43 p.m., Gabriel Becker wrote: I have to say <<- is a core debugging tool when assigning into the global environment. I suppose I could use assign but that would be somewhat annoying. That said I'm still for this change, the vast overwhelming number of times that <<- is in my

Re: [Rd] WISH: Optional mechanism preventing var <<- value from assigning non-existing variable

I have to say <<- is a core debugging tool when assigning into the global environment. I suppose I could use assign but that would be somewhat annoying. That said I'm still for this change, the vast overwhelming number of times that <<- is in my package code - already rare but it does happen - it

Re: [Rd] WISH: Optional mechanism preventing var <<- value from assigning non-existing variable

On 19/03/2023 2:15 p.m., Bill Dunlap wrote: Why should it make an exception for cases where the about-to-be-assigned-to name is present in the global environment?  I think it should warn or give an error if the altered variable is in any environment on the search list. I'd say code like this

[Rd] CRAN 'R Sources' page: Provide link to https://svn.r-project.org/R/

Not sure who is the webadmin for https://cran.r-project.org/sources.html, so posting it here: I just noticed it's not straightforward to find the Subversion URL for the R source code. A natural search would be to go to https://cran.r-project.org/, then click 'Source code' to get to

Re: [Rd] WISH: Optional mechanism preventing var <<- value from assigning non-existing variable

Why should it make an exception for cases where the about-to-be-assigned-to name is present in the global environment? I think it should warn or give an error if the altered variable is in any environment on the search list. -Bill On Sun, Mar 19, 2023 at 10:54 AM Duncan Murdoch wrote: > I

Re: [Rd] WISH: Optional mechanism preventing var <<- value from assigning non-existing variable

I think that should be the default behaviour. It's pretty late to get that into R 4.3.0, but I think your proposal (with check.superassignment = FALSE being the default) could make it in, and 4.4.0 could change the default to TRUE. Duncan On 19/03/2023 12:08 p.m., Henrik Bengtsson wrote:

[Rd] WISH: Optional mechanism preventing var <<- value from assigning non-existing variable

I'd like to be able to prevent the <<- assignment operator ("super assignment") from assigning to the global environment unless the variable already exists and is not locked. If it does not exist or is locked, I'd like an error to be produced. This would allow me to evaluate expressions with

Re: [Rd] [WARNING: POTENTIAL FORGED EMAIL] Augment base::replace(x, list, value) to allow list= to be a predicate?

Dear All, Following up on this, I was wondering whether it might be possible to get a disposition from R developers. I did find a way to produce a similar effect reasonably concisely using call alchemy and lazy evaluation. The following function grabs the specified arguments in the function

Re: [Rd] use Ctrl-W to close View() window?

  It does work, although it's very awkward with my current keyboard setup (I need to use Alt-Fn-F4).  However, knowing that there was *a* keyboard shortcut for it led me to figuring out how to add Ctrl-W as a synonym.  Thanks!  ("Super"-Q is also a synonym, where "Super" is the same as the

Re: [Rd] use Ctrl-W to close View() window?

Hi, am I missing something or could you just use Alt-F4? This is pretty standard for closing focussed windows on Windows and Linux at least. It just closed a Window opened with View() on Debian Linux FWIW. Cheers, Johannes Am Freitag, 17. März 2023, 23:16:49 CET schrieb Ben Bolker: >I

[Rd] use Ctrl-W to close View() window?

  I might be the last person in the world who's using View() outside of RStudio, but does anyone have a sense of how hard it would be to enable closing such a window (when in focus) with a standard keyboard shortcut (e.g. Ctrl-W on Linux) ... ?  Where would I start looking in the code base?  

Re: [Rd] La_library() always returns "" on R-devel?

On 3/17/23 11:53, Gábor Csárdi wrote: Seems like this in 83986 [1] needs a fix in Lapack.c: if (dladdr((void *) F77_NAME(ilaver), _info)) { char buf[PATH_MAX+1]; char *res = realpath(dl_info.dli_fname, buf); if (res) { SEXP nfo

[Rd] La_library() always returns "" on R-devel?

Seems like this in 83986 [1] needs a fix in Lapack.c: if (dladdr((void *) F77_NAME(ilaver), _info)) { char buf[PATH_MAX+1]; char *res = realpath(dl_info.dli_fname, buf); if (res) { SEXP nfo = R_NilValue; if (strstr(res,

Re: [Rd] Request: better default R_LIBS_USER

On Thu, Mar 16, 2023 at 6:39 PM Dirk Eddelbuettel wrote: > > > On 16 March 2023 at 17:15, Henrik Bengtsson wrote: > | We're all starting out with a fresh R_LIBS_USER once a year when a new > | minor version of R is released, > > Maybe not "we all". I don't, and I know other Linux users who don't

Re: [Rd] det(diag(c(NaN, 1))) should be NaN, not 0

Hmm ... I can no longer reproduce this under r83996 when configuring --without-lapack and --without-blas {the default}. Now det(A), det(B), det(C), and det(D) are all NaN. I assume that the reason is the recent update to use LAPACK 3.11.0? But I don't see any related NEWS here:

Re: [Rd] Request: better default R_LIBS_USER

On Thu, Mar 16, 2023 at 4:08 PM Dirk Eddelbuettel wrote: > > > On 16 March 2023 at 13:39, Felipe Contreras wrote: > | I see R by default installs packages in ~/R. I know I can change the > | default directory with R_LIBS_USER, but software shouldn't be > | polluting the home directory. > | > |

Re: [Rd] Request: better default R_LIBS_USER

On 16 March 2023 at 17:15, Henrik Bengtsson wrote: | We're all starting out with a fresh R_LIBS_USER once a year when a new | minor version of R is released, Maybe not "we all". I don't, and I know other Linux users who don't force a rebuild unless needed (as with R 3.6.* -> R 4.0.0). R

Re: [Rd] Request: better default R_LIBS_USER

> Your best bet really to govern your .libPaths from your Rprofile.site and Renviron.site ... To do this for any version of R, one can add: R_LIBS_USER=~/.local/share/R/%p-library/%v to ~/.Renviron or the Renviron.site file. This automatically expands to the platform and R x.y version early on

Re: [Rd] Request: better default R_LIBS_USER

On 16 March 2023 at 13:39, Felipe Contreras wrote: | I see R by default installs packages in ~/R. I know I can change the | default directory with R_LIBS_USER, but software shouldn't be | polluting the home directory. | | For example both python and node install packages to ~/.local/lib, | ruby

[Rd] Request: better default R_LIBS_USER

Hi, I see R by default installs packages in ~/R. I know I can change the default directory with R_LIBS_USER, but software shouldn't be polluting the home directory. For example both python and node install packages to ~/.local/lib, ruby to ~/.local/share. They don't install to for example

<    5   6   7   8   9   10   11   12   13   14   >