similar to: Odd behavior of symbol objects with classes/attributes

I ran into this and found the result very surprising: identical( quote({ a }), quote({ a }) ) # FALSE It seems related to curly braces. For example, parens work fine: identical( quote(( a )), quote(( a )) ) # TRUE Is this expected behavior? I can't seem to find anything in the help for identical that relates to this. -Winston

I've been seeing warnings when unloading packages. They can be seen with the shiny and sp packages, among others (this is on R 3.0.2). For example: > library(sp) > unloadNamespace('sp') Warning messages: 1: In FUN(X[[2L]], ...) : Created a package name, ‘2013-12-19 12:14:24’, when none found 2: In FUN(X[[2L]], ...) : Created a package name, ‘2013-12-19 12:14:24’, when none

>>>>> Winston Chang <winstonchang1 at gmail.com> >>>>> on Fri, 23 Jan 2015 10:15:53 -0600 writes: > I think you can simplify a little by replacing this: > pkg %in% loadedNamespaces() > with this: > .getNamespace(pkg) almost: It would be !is.null(.getNamespace(pkg)) > Whereas getNamespace(pkg) will load the

On Wed, Apr 29, 2015 at 12:53 PM, Winston Chang <winstonchang1 at gmail.com> wrote: > On Tue, Apr 28, 2015 at 3:04 PM, G?bor Cs?rdi <csardi.gabor at gmail.com> > wrote: > > > > > > E.g. if package 'ggplot2' uses 'stats::density()', and package 'igraph' > > also defines 'density()', and 'igraph' is on the search

When a reference class method is accessed with .self$x, it has different behavior from .self[['x']]. The former copies the function to the object's environment (with some attributes attached), and the latter just return NULL (unless it has already been accessed once with .self$x). Is this how it's supposed to work? Here's an example that illustrates:

>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Mon, 26 Jan 2015 05:12:55 -0800 writes: > A isNamespaceLoaded() function would be a useful thing to > have in general if we are interested in readable code. An > efficient implementation would be just a bonus. Good point (readability), and thank you for the support! Note

It seems that the system() and system2() functions don't close file descriptors between the fork() and exec() (on Unix platforms, of course). This means that the child processes inherit open files and socket connections. Running this (from a terminal) will result in the child process writing to a file that was opened by R: R f <- file('foo.txt', 'w') system('echo

) On Wed, Apr 5, 2017 at 2:59 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote: > > >>>>> Winston Chang <winstonchang1 at gmail.com> > >>>>> on Tue, 4 Apr 2017 15:29:40 -0500 writes: > > > I've done some more investigation into the problem, and it is very > > difficult to pin down. What it looks like is

Thanks for looking into it. Is there a way to avoid the HEAD request in R 3.3.0? I'm asking because if there isn't, then I'll add a workaround in a package I'm working on. -Winston On Tue, Jun 21, 2016 at 9:45 PM, Martin Morgan <martin.morgan at roswellpark.org> wrote: > On 06/21/2016 09:35 PM, Winston Chang wrote: >> >> In R 3.2.4, if you ran

If an environment x contains a locked binding y which is also an environment, and then you try to assign a value to a binding inside of y, it can either succeed or fail, depending on how you refer to environment y. x <- new.env() x$y <- new.env() lockEnvironment(x, bindings = TRUE) # This assignment fails x$y$z <- 1 # Error in x$y$z <- 1 : cannot change value of locked binding for

Thanks Winston! I'm amazed that "[[" beats calling the .Internal directly. I guess the difference between .Primitive vs. .Internal is pretty significant for things on this time scale. NULL meaning NULL and NULL meaning undefined would lead to the same path for much of my code. I'll be swapping out many exists and get calls later today. Thanks! I do still think it would be

Hi, I initially opened an issue in the R6 repo because my issue was with an R6 object. But Winston (thanks!) further simplified my example, and it turns out that the issue (whether a feature or a bug is yet to be seen) had to do with S3 dispatching. The following example, by Winston, depicts the issue: print.foo <- function(x, ...) { cat("print.foo called\n") invisible(x) }

Just checking in to see whether it is intended or not that assigning new formals to a function/closure causes any attributes to be dropped: EXAMPLE: > fcn <- structure(function() {}, foo="foo", class=c("foo")) > str(fcn) function () - attr(*, "srcref")=Class 'srcref' atomic [1:8] 1 18 1 30 18 30 1 1 .. ..- attr(*, "srcfile")=Classes

On 05.04.2017 23:54, peter dalgaard wrote: > >> On 05 Apr 2017, at 20:40 , Winston Chang <winstonchang1 at gmail.com> wrote: >> >> I think there's a good chance that this is due to a bug in R. I have >> been trying to track down the cause of the problem but haven't been >> able find it. >> >> -Winston > > Apologies in advance if this

> > >> I've done some more investigation into the problem, and it is very difficult to pin down. What it looks like is happening is roughly like this: - `p` is an environment and `p$e` is also an environment. - There is a loop. In each iteration, it looks for one item in `p$e`, saves it in a variable `x`, then removes that item from `p$e`. Then it invokes `x()`. The loop runs

I'm getting an R CMD check warning with a package (call it package A) that defines an S3 method but not the generic. The generic is defined in another package (package B). Package A imports the S3 generic from B. And there's one additional detail: the generic overrides a function in the stats package. I've created a minimal test package which reproduces the problem:

I have committed a change to R-devel that addresses this. To be on the safe side I need to run some more extensive tests before deciding if this can be ported to the release branch for R 3.5.0. Should know in a day or two. Best, luke On Tue, 27 Mar 2018, luke-tierney at uiowa.edu wrote: > This has nothing to do with printing or dispatch per se. It is the > result of an internal register

Dear all, I have a zoo object that has following structure: > str(bldata) zoo [1:5219, 1:12] 91.9 91.8 91.7 91.8 91.7 ... - attr(*, "index")=Classes 'dates', 'times' atomic [1:5219] 7305 7306 7307 7308 7309 ... .. ..- attr(*, "format")= chr "m/d/y" .. ..- attr(*, "origin")= Named num [1:3] 1 1 1970 .. .. ..- attr(*,

My understanding is that R will not make copies of lists if there is only one reference to the object. However, I've encountered a case where R does make copies, even though (I think) there should be only one reference to the object. I hope that someone could shed some light on why this is happening. I'll start with a simple example. Below, x is a list with one element, and changing that

Dear R Helpers, I have a list that contains a number of objects, each of them financial statement data from quantmod (although I don't think that knowledge of quantmod is necessary to help with this problem). > str(listfinobj) chr [1:4815] "A.f" "AA.f" "AACC.f" "AAME.f" "AAN.f" "AAON.f" "AAP.f" "AAPL.f"