similar to: Submitting packages with weak circular dependencies to CRAN.

This could be extended to sub and gsub as well which gsubfn in the gusbfn package already does: library(gsubfn) gsubfn("^..", toupper, c("abc", "xyz")) ## [1] "ABc" "XYz" On Fri, Mar 3, 2023 at 7:22?PM Pavel Krivitsky <p.krivitsky at unsw.edu.au> wrote: > > Dear All, > > Currently, list= in base::replace(x, list, value)

That's an interesting example, as it's conceptually similar to what Pavel is proposing, but structurally different. gsubfn() is more complicated than a simple switch in the body of the function, and wouldn't work well as an anonymous function. Multiple dispatch can nicely encompass both of these cases. For replace(), library(S7) replace <- new_generic("replace",

CCing r-devel. On Tue, 14 May 2019 at 02:11, Pavel Krivitsky <pavel at uow.edu.au> wrote: > > Dear All, > > I've run into this while updating a package with unfortunately named > legacy functions. It seems like something that might be worth changing > in R, and I want to get a sense of whether this is a problem before > submitting a report to the Bugzilla. > >

On Sat, 18 May 2019 at 23:34, Pavel Krivitsky <pavel at uow.edu.au> wrote: > > > The issue here is that you are registering a non-standard name > > (.gen.formula) for that generic and then defining what would be the > > standard name (gen.formula) for... what purpose? IMHO, this is a bad > > practice and should be avoided. > > The situation initially arose

On Tue, 14 May 2019 at 12:31, Pavel Krivitsky <pavel at uow.edu.au> wrote: > > > Note that disabling name-based dispatch implies two things: 1) the > > inability to override your method by defining gen.formula in the > > global environment, and 2) another package can break yours (i.e., > > internal calls to gen()) by registering an S3 method for gen() after >

Dear R-devel, While tracking down some hard-to-reproduce bugs in a package I maintain, I stumbled on a behavior change between R 2.15.0 and the current R-devel (or SVN trunk). In 2.15.0 and earlier, if you passed an 0-length vector of the right mode (e.g., double(0) or integer(0)) as one of the arguments in a .C() call with DUP=TRUE (the default), the C routine would be passed NULL (the C

Dear All, Since upgrading to 3.6.0, I've been getting a strange error messages from the child process when using mcparallel/mccollect. Before filing a report in the Bugzilla, I want to figure out whether I had been doing something wrong all this time and R 3.6.0 has exposed it, or whether something else is going on. # Background # Ultimately, what I want to do is to be able to set a time

Hi, I am working on an R package which includes some C routines. I would like to profile the C routines (built with GCC under Debian Linux). I tried running R with LD_PROFILE=/path/to/C/library.so R and executing functions that would invoke the code therein. The code takes about twice as long to run with LD_PROFILE set than without, so I am guessing that profiling is taking place. However,

I have an issue with a circular package dependence that prevents building/checking, and I seek advice on breaking the circle so the packages can pass the build-check tests that are required for CRAN submission. The package pair I'm working with is slow to build, but my tests suggest the issue may be general, and so I will explain it in general terms. Suppose there are two packages: 1. Foo,

Hi, An R package on which I am working makes a series of very computationally-intensive and complex .C() calls, that I would like to make interruptible. However, calling R_CheckUserInterrupt() causes a non-local exit, so the memory allocated by malloc() is never freed. The way the code is structured, it might not be practical to replace all the malloc() calls with R_alloc() calls. The question

On 5/28/25 04:15, Pavel Krivitsky via R-devel wrote: > Dear All, > > Perhaps this should go in r-package-devel, but I suspect that this is > going to turn into a feature request, and I want to run it by the list > before filing it in the Bugzilla. > > I would like to specify a long string literal without making the line > of code too long. In R, > > "abc >

Hello, I just subscribed to the list to join the discussion after being blindsided by the change and reading Dirk Eddelbuettel's reply to my bug report at https://bugs.debian.org/866768 . As far as I can tell the advantages of site library are: 1. Saves disk space and a little bit of user time spent installing and upgrading. 2. Other Debian package manages, like pip, default?to

Dear All, Currently, list= in base::replace(x, list, value) has to be an index vector. For me, at least, the most common use case is for list= to be some simple property of elements of x, e.g., x <- c(1,2,NA,3) replace(x, is.na(x), 0) Particularly when using R pipes, which don't allow multiple substitutions, it would simplify many of such cases if list= could be a function that returns

Tomas, Here is a good example of where this functionality would be useful: https://github.com/R-ArcGIS/arcgislayers/blob/2b29f4c254e7e5a1dadce8d4b0015a70dfae39d4/R/arc-open.R#L19-L56 In order to prevent R CMD check notes I have to use `paste0()` to concatenate long URLs. If we were able to use `\` to separate the string across multiple lines, it would make the solution much nicer! On Mon, Jun

On 6/2/25 17:37, Josiah Parry wrote: > Tomas, > > Here is a good example of where this functionality would be useful: > https://github.com/R-ArcGIS/arcgislayers/blob/2b29f4c254e7e5a1dadce8d4b0015a70dfae39d4/R/arc-open.R#L19-L56 > > In order to prevent R CMD check notes I have to use `paste0()` to > concatenate long URLs. If we were able to use `\` to > separate the string

Like Tomas, I find the paste0 readability to be **much** better, partly because it allows for better indentation (as Tomas pointed out). Perhaps a pointless email, but sometimes - for these subjective issues - it is worthwhile to point out a difference in opinion. Best, Kasper On Mon, Jun 2, 2025 at 12:27?PM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > On 6/2/25 17:37,

One could also argue that paste0("a", "b", "c") is a function call that needs to be evaluated at runtime, whereas "abc" is a string constant understood by the parser, and often also language agnostic. I'd assume compilers and code- and text-search tools do a better job with the latter. /Henrik On Mon, Jun 2, 2025 at 2:18?PM Josiah Parry

I suppose taste is learned as well. It does feel quite odd that the best way to define a long string without a note or text wrapping is by being creative with functions. This is valid in Python, Julia, and Rust (if you add `let` and a terminating semi-colon): my_str = "part1\ part2\ part2" I don't think it is abnormal to expect or desire this type of functionality in our favorite

Fine with me as long as eliminating the inconveniences associated with it can be put on the roadmap. The alias instability and the fact that the user has no way to know if s/he should do ?`foo,numeric-method` or ?`foo,numeric,ANY-method` to find the method has been a long-standing problem. H. On 3/21/19 21:29, Michael Lawrence wrote: If we started over, I'd try to avoid this sort of

Hi, Currently object.size() is not very useful on environments as it always returns 56 bytes, no matter how big the environment is: env1 <- new.env() object.size(env1) # 56 bytes env2 <- new.env(hash=TRUE, size=75000000L) object.size(env2) # 56 bytes env3 <- list2env(list(a=runif(25000000), L=LETTERS)) object.size(env3) # 56 bytes This makes it pretty useless on