similar to: environment question

As I understand https://stat.ethz.ch/R-manual/R-devel/library/base/html/sys.parent.html sys.function(n) returns the function associated with stack frame n. Since frame 0 is defined as .GlobalEnv which is not associated with a function, I would expect this to always return NULL. However, it does not: > sys.function() NULL > f <- function(x) sys.function(x) > f(0) function(x)

On 3/27/16 2:46 PM, peter dalgaard wrote: >> On 27 Mar 2016, at 22:05 , Mick Jordan <mick.jordan at oracle.com> wrote: >> >> As I understand >> https://stat.ethz.ch/R-manual/R-devel/library/base/html/sys.parent.html >> sys.function(n) returns the function associated with stack frame n. >> Since frame 0 is defined as .GlobalEnv which is not associated with

Dear list readers, Can someone of you explain this behavior. Here's a toy example: Start by constructing a function tmp >fix(tmp) In the default editor enter this one-liner: hist(rnorm(10)) close the editor and run environment on the function. > environment(tmp) <environment: R_GlobalEnv> Open the editor and remove the last parenthesis, this will make the editor choke.

> On 27 Mar 2016, at 22:05 , Mick Jordan <mick.jordan at oracle.com> wrote: > > As I understand > https://stat.ethz.ch/R-manual/R-devel/library/base/html/sys.parent.html > sys.function(n) returns the function associated with stack frame n. > Since frame 0 is defined as .GlobalEnv which is not associated with a > function, I would expect this to always return NULL.

Dear R-Devel, I was attempting an exercise in Hadley Wickam's book "Advanced R". The exercise is to find the generic with the greatest number of methods. I found that 'methods(`|`)' produces a list of length 2506, in R 3.3.1. Similar behavior is found in 3.4.0. It seems to include all functions and methods. I imagine something is being passed to "grep" without

On 1/4/17 1:26 AM, Martin Maechler wrote: >>>>>> Mick Jordan <mick.jordan at oracle.com> >>>>>> on Tue, 3 Jan 2017 07:57:15 -0800 writes: > > This is a message for someone familiar with the implementation. > > Superficially the R code for seq.default and the C code for seq.int > > appear to be semantically very

On 5/2/16 4:25 PM, David Winsemius wrote: >> On May 2, 2016, at 3:45 PM, Mick Jordan <mick.jordan at oracle.com> wrote: >> >> When is the R-3.2.5 binary for Mac OS X likely to show up? > Where did you look? I see both Mavericks and SnowLeopard fork binaries with or without r.app GUI at http://r.research.att.com/ > > I've been using the 3.3.0 RC for a while with

When is the R-3.2.5 binary for Mac OS X likely to show up? Mick Jordan

Is the mechanism by which packages are tested on CRAN described anywhere? Is it by any chance written in R? The FastR <https://bitbucket.org/allr/fastr/wiki/Home> team is interested in running a virtual CRAN where we can test all the CRAN packages on FastR. Thanks Mick Jordan [[alternative HTML version deleted]]

On 24/05/2016 00:54, Simon Urbanek wrote: > Um... any reason why you don't simply disable aqua? That file is only compiled if you enable aqua - it has really nothing to do with grDevices ... Also, you can specify a compiler for Objective-C separately and the manual advises you to do so (to specify Apple's clang). > On May 23, 2016, at 7:44 PM, Mick Jordan <mick.jordan at

I am curious if anyone knows of R code where the "{" function is redefined in a useful way. Or "(" for that matter. Thanks Mick

I came across this code in library.R package <- as.character(substitute(package)) where package is the first argument to the "library" function. I've been racking my brains to understand why this is not just an elaborate (and ineffcient) way to write: package <- "package" E.g. > package <- as.character(substitute(package)) > package [1]

Is it possible to configure and build an R without any graphics support. I..e no grDevices or graphics packages? I tried "--with-x=no --with-cairo=no --with-grDevices=no --with-graphics=no" but it is still building grDevices. My problem is that I am using experimenting with a compiler that cannot compile the Objective-C file, qdCocoa.m, and I don't need graphics for this

Specifically, the srcfile attribute of the srcref attribute of the two instances of the functions contain different environments, AFAICT. Environments are compared only by exact pointer, so this forces return FALSE. Snippets from .Internal(inspect(x)) and .Internal(inspect(y)): @cca008 03 CLOSXP g0c0 [MARK,NAM(2),ATT] FORMALS: @604b58 00 NILSXP g0c0 [MARK,NAM(2)] BODY: @cc9650 06 LANGSXP

On 4/9/16 10:54 AM, Dirk Eddelbuettel wrote: > On 9 April 2016 at 10:28, Mick Jordan wrote: > | Can someone explain a message of this form from an rscript execution: > | > | Note: no visible global function definition for 'foo' > | > | > | This happens right at the start of execution. 'foo' is only executed in > | a branch of an 'if' that is not

>>>>> peter dalgaard <pdalgd at gmail.com> >>>>> on Sat, 12 Mar 2016 19:11:40 +0100 writes: > OK, .Internal is not necessary to reproduce oddity in this area. I also see things like (notice 1980) >> strptime(paste0(sample(1900:1999,80,replace=TRUE),"/01/01"), "%Y/%m/%d", tz="CET") ............... >

I was surprised just now to find out that `topenv(emptyenv())` equals ? `.GlobalEnv`, not `emptyenv()`. From my understanding of the description of `topenv`, it should walk up the chain of enclosing environments (as if by calling `e = parent.env(e)` repeatedly; in fact, that is almost exactly its implementation in envir.c) until it hits a top level. However, `emptyenv()` has no enclosing

Linux: > x<-c("0","1");y<-c("a","-1"); x<y [1] TRUE TRUE Mac: x<-c("0","1");y<-c("a","-1"); x<y [1] TRUE FALSE On both systems, LC_COLLATE/LC_CTYPE/LANG are set to en_US.UTF-8 In Java,FWIW, I get the Mac answer if I use String.compareTo and the Linux answer if I use Collator.compareTo, but

I'm confused by this: > identical(function() {}, function() {}) [1] FALSE Yet, after loading the Matrix package (which redefines det), the following is checked (in library.checkConflicts): > identical(get("det", baseenv()), get("det", asNamespace("Matrix")), ignore.environment=T) [1] TRUE I've looked at the code in identical.c and for closures it

On 5/3/16 11:29 AM, Thierry Onkelinx wrote: > Dear Mick, > > Note that both knitr and rmarkdown are listed under Suggests: both are > required to compile the vignette. Installing rmarkdown should solve > the problem. If not, please provide more information. OS, R version, > digest version, ... > > This is occurring in the context of an automated testing environment that