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,

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

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,

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

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

Hi Michael, Thanks for looking into this. I suspect that truncation of ANY suffixes from method signatures is also the culprit behind the sudden breakage of aliases of the form \alias{foo,numeric-method} when a method without the ANY suffix in its signature gets added to the ecosystem. See my post about this to the Bioc-devel mailing list a couple of months ago:

by() does not always return a list. In Gabe's example, it returns an integer, thus it is coerced to a list. as.list() means that it should be a VECSXP, not necessarily with "list" in the class attribute. Michael On Tue, Jan 30, 2018 at 2:41 PM, Herv? Pag?s <hpages at fredhutch.org> wrote: > Hi Gabe, > > Interestingly the behavior of as.list() on by objects seem to

Hi Mehmet, On 11/29/2017 11:22 AM, Suzen, Mehmet wrote: > Hi Herve, > > I think you are confusing subclasses and classes. There is no > contradiction. `is` documentation > is very clear: > > `With one argument, returns all the super-classes of this object's class.` Yes that's indeed very clear. So if "list" is a super-class of "data.frame" (as

Dear All, Martin Maechler has asked me to send this to R-devel for discussion after I submitted it as an enhancement request ( https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17563). At this time, the update.formula() method always performs a number of transformations on the results, eliminating redundant variables and reordering interactions to be after the main effects. This is not always

On 03/19/2016 01:22 AM, Michael Lawrence wrote: > > > On Sat, Mar 19, 2016 at 12:10 AM, Herv? Pag?s <hpages at fredhutch.org > <mailto:hpages at fredhutch.org>> wrote: > > On 03/18/2016 03:28 PM, Michael Lawrence wrote: > > > On Fri, Mar 18, 2016 at 2:53 PM, Herv? Pag?s > <hpages at fredhutch.org <mailto:hpages at

Hi, The following error message misspells the name of the 'dim' argument: > array(integer(0), dim=integer(0)) Error in array(integer(0), dim = integer(0)) : 'dims' cannot be of length 0 The name of the argument is 'dim' not 'dims': > args(array) function (data = NA, dim = length(data), dimnames = NULL) NULL Cheers, H. -- Herv? Pag?s