similar to: Return function from function with minimal environment

I've just committed some changes to R-devel which affect environments. Specifically: - using NULL as an environment is now deprecated: use baseenv() instead. (baseenv() is already available in R 2.2.0, where it returns NULL. For most purposes it retains the same meaning in R-devel.) If you do use NULL, it will be converted to baseenv(), and a warning printed. For example: > f

Thank you for your suggestion. I do know how to work around the issue. I usually build a fresh environment as a child of base-environment and then insurt the weights there. I was just trying to provide an example of the issue. emptyenv() can not be used, as it is needed for the eval (errors out even if weights are not used with "could not find function list"). For some applications

Dear R useRs, I have a problem with nls.lm function of minpackl.lm package. I need to fit the Van Genuchten Model to a set of data of Theta and hydraulic conductivity with nls.lm function of minpack.lm package. For the first fit, the parameter estimates keep changing even after 1000 iterations (Th) and I have a following error message for fit of hydraulic conductivity (k); Reason for

Dear R-Devel subscriber, first, let me express my thank to the R-Core team for the new release! I appreciate their efforts and time spent to enhance R. In accordance with the 'NEWS' file (see excerpt of it below), [... o Changed the environment tree to be rooted in an empty environment, available as emptyenv(). baseenv() has been modified to return an environment with emptyenv() as

Dear R-Devel subscriber, first, let me express my thank to the R-Core team for the new release! I appreciate their efforts and time spent to enhance R. In accordance with the 'NEWS' file (see excerpt of it below), [... o Changed the environment tree to be rooted in an empty environment, available as emptyenv(). baseenv() has been modified to return an environment with emptyenv() as

I understand why the following happens ($.proto delegates to get, which ascends the parent hierarchy up to globalenv()), but I still find it anti-intuitive: > z <- 1 > y <- proto(a=2) > y$z [1] 1 Although this is well-documented behavior; wouldn't it uphold the principle of least surprise to inherit instead from baseenv() or emptyenv()? (See attached patch.) Spurious

Hi, All I'm trying to save the workspace as a Check Point for possible future come back. The "save.image" function works if the whole coding is in a main function: rm(list=ls()) t = 1 t = t+1 print(paste("before",t)) # [1] "before 2" save.image("tt.RData") t = t+1 print(paste("after",t)) # [1] "after 3"

Thank you very much for your useful suggestions. These are exactly what I was looking for. foo <- list(foo1, foo2, foo3) lapply(foo, function(x) matrix(unlist(x), nrow = length(x), byrow = TRUE)) or lapply(foo, function(x) do.call('rbind', x)) Best, Muhammad Subianto On 4/11/06, Muhammad Subianto <msubianto at gmail.com> wrote: > Dear all, > I have a result my experiment

Dear all, I have a result my experiment like this below (here my toy example): foo1 <- list() foo1[[1]] <- c(10, 20, 30) foo1[[2]] <- c(11, 21, 31) foo2 <- list() foo2[[1]] <- c(100, 200, 300) foo2[[2]] <- c(110, 210, 310) foo3 <- list() foo3[[1]] <- c(1000, 2000, 3000) foo3[[2]] <- c(1100, 2100, 3100) list(foo1,foo2,foo3) The result: > list(foo1,foo2,foo3) [[1]]

I have a general style question about R coding. Suppose I'm writing a function (foo1) that calls other functions (foo2, foo3, ...) which have complicated argument lists (e.g. optim(), plot()), _and_ I may be calling several different functions in the body of foo1. Since foo2 and foo3 have different sets of arguments, I can't just use "..." ; I did write some code a while ago

Dear List: In short, I am writing a number of functions as building blocks for other functions and have some questions about scoping and passing arguments. Suppose I have functions foo1, foo2, and foo3 such that: foo1<-function(a=1,b=TRUE,c=FALSE){#do stuff}; foo2<-function(x=1,y=FALSE,z=c(1,2,3,4)){#do stuff}; foo3<-function(lambda,...){lambda*foo1()*foo2()}; I want to be able to

I wish I had started with "I am disappointed that lm() doesn't continue its search for weights into the calling environment" or "the fact that lm() looks only in the formula environment and data frame for weights doesn't seem consistent with how other values are treated." But I did not. So I do apologize for both that and for negative tone on my part. Simplified

Hi all, For some reason, I would like to use functions bellow (see example code bellow), but instead I get the following error message: *Error in foo2(...) : unused argument(s) (arg3 = 3)* #--------------------- # example code #--------------------- foo1 <- function(arg1,...) { print(arg1) foo2(...) foo3(...) } foo2 <- function(arg2) { print(arg2) } foo3 <- function(arg3) {

i believe the following is true but would appreciate confirmation that it is intended behavior and will continue: if a default argument is employed in the definition of a generic function, and the generic is called with the argument in question (call it 'ARG') missing, then the method for signature (..., ARG = "missing", ...) will be called by 'standardGeneric'

Hello LLVM Developers, I'm trying to replace a function defined in one module into another module (different files). The first issue I ran into was that llvm::Function does not have a method "moveBefore" or "moveAfter" as the llvm::BasicBlock or llvm::Instruction do, so I figured I would just move the BasicBlocks of the replacing function into the function that was being

Hello and thanks for the answer, I'm still facing issues, I'll do my best to explain my situation, as I explained, I have two modules, each one with its own main and functions, I would like to replace in the *oldModule* a function call that is calling *foo2* (defined in *oldModule*) to instead call *foo3*, which is defined in the *refModule. *So in summary, I have: 1. The original

Hi Ahmad, What does that tool does besides what LLVM linker already does? I don't think my problem is in linking both modules, I think LLVM linker does the job for me, the issue is when changing the called function to call another function (in the example previously provided, to change it from foo2 to foo3, and adjusting the function parameter's references). Regards, Daniel Moya El

Hi Philip, The error happens when the program finishes and it automatically calls the destructors, so it is not an error specifically inside my program. Here's the full code: #include "llvm/ExecutionEngine/ExecutionEngine.h" #include "llvm/ExecutionEngine/MCJIT.h" #include "llvm/IRReader/IRReader.h" #include "llvm/Support/TargetSelect.h" #include

Hi the list In the DESCRIPTION file of my package foo0, I have: Depends: foo1 Imports: foo2 Suggest: foo3 Enhence: foo4 If I understand correctly, to install foo0 on my computer, I need to already have foo1, foo2, foo3. foo4 is not necessary. I my R sesssion, when I will write: library(foo0), then the package foo1 will be attach. foo2, foo3 and foo4 will not. Is that correct? But what is

Thank you Ahmad, I figured out that, although the type of both p(oInst) and p(nInst) were the same, I had to: for (unsigned int i = 0; i < callOInst->getNumArgOperands(); i++) { callOInst->getArgOperand(i)->mutateType(callNInst->getArgOperand(i)->getType()); } that solves the issue at the calling instruction in the main function, but now I see that *linkModules* does not work