similar to: R-beta: Source code: grep(.) and objects(..., pattern):

> Date: Wed, 26 Nov 2003 13:52:44 +0100 > From: Martin Maechler <maechler@stat.math.ethz.ch> > To: <Kurt.Hornik@wu-wien.ac.at> > Cc: <r-devel@stat.math.ethz.ch> > Subject: Re: [Rd] Question about Unix file paths > > > > >>>>> " Kurt" == Kurt Hornik <Kurt.Hornik@wu-wien.ac.at> > >>>>> on Wed, 26

>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Fri, 9 Jan 2015 14:00:38 +0100 writes: >>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Thu, 8 Jan 2015 14:02:26 -0800 writes: >> On Thu, Jan 8, 2015 at 11:57 AM, <luke-tierney at uiowa.edu> wrote: >>> On Thu, 8

I don't have time now to investigate myself, and I'm not feeling like deciding myself if the following is a bug: myplot <- function(dat, cex = 1.2, ...) { if(!is.data.frame(dat <- as.data.frame(dat))) stop("`dat' must be a data.frame") if(any(is.na(match(c("x","y"), names(dat))))) stop("`dat' must have a `x' and a

According to the assign helpfile (0.90.1) the "assign" function is function (x, value, pos = -1, envir = sys.frame(sys.parent()), inherits = FALSE, immediate = TRUE) which is not quite the implementation, which is function (x, value, pos = -1, envir = pos.to.env(pos), inherits = FALSE, immediate = TRUE) This seems to have the following interesting effect. "short.fun"

Adding an optional argument to get (and mget) like val <- get(name, where, ..., value.if.not.found=NULL ) (*) would be useful for many. HOWEVER, it is possible that there could be some confusion here: (*) can give a NULL because either x exists and has value NULL, or because x doesn't exist. If that matters, the user would need to be careful about specifying a value.if.not.found

How is exact pattern matching achieved in GREP (and GREPlike) functions ? # Want: listing of all object names that end in *.lm > objects(pattern="*.lm",pos=1) # ... but get: all objects that partially match *.lm, e.g., *.lme [1] "j3.lm" "J3.lme" "j8.lm" "J8.lme" # Want: position of string "4jan2002" in vector >

Hi, is there away to assure that a package is detached when R quits? I know about .Last(), but that requires the user to setup that function. What I am looking for is a way for the package to do this itself, without asking the user to edit "their" .Last(). From ?setHook I know that: "...when an R is finished, packages are not detached and namespaces are not unloaded, so

On Thu, Jan 8, 2015 at 11:57 AM, <luke-tierney at uiowa.edu> wrote: > On Thu, 8 Jan 2015, Michael Lawrence wrote: > > If we do add an argument to get(), then it should be named consistently >> with the ifnotfound argument of mget(). As mentioned, the possibility of a >> NULL value is problematic. One solution is a sentinel value that indicates >> an unbound value

On 08/01/2015 9:03 AM, John Nolan wrote: > Adding an optional argument to get (and mget) like > > val <- get(name, where, ..., value.if.not.found=NULL ) (*) That would be a bad idea, as it would change behaviour of existing uses of get(). What I suggested would not give a default. If the arg was missing, we'd get the old behaviour, if the arg was present, we'd use it.

Dear group, Here is my function: #return the daily PL for day y PLDaily<-function(x,y) { #find elements in my directory with "LSCPos" in the name, keep the numeric part in the name and #create a list l<-gsub("\\D","",dir()[grep("LSCPos",dir())]) #select in the list the desired elements

Hello, I have the following problem when trying to use rm: In a top level script file I have a loop iterating over some index. The loop is not contained within a function, so the scope of variables declared in the loop is global. Within this loop I generate several variables which should be removed at the end of each iteration. To do this, I wrote a function to clean up the workspace. An example

Hello. What happens in the following is that I create two simple functions, f and g, on the workspace. Then I replace g. When I then call f, it uses the old version of g. Now clearly, the circumstances for this to happen must be quite special and rare. But I'd say they're not pathological. It seems to require two things: 1) masked versions of f and g on a search position lower down the

On Thu, 8 Jan 2015, Michael Lawrence wrote: > If we do add an argument to get(), then it should be named consistently > with the ifnotfound argument of mget(). As mentioned, the possibility of a > NULL value is problematic. One solution is a sentinel value that indicates > an unbound value (like R_UnboundValue). A null default is fine -- it's a default; if it isn't right for

All, So that suggests that .GlobalEnv[["X"]] is more efficient than get("X", pos=1L). What about .GlobalEnv[["X"]] <- value, compared to assign("X", value)? Dave On Wed, Dec 3, 2014 at 3:30 PM, Peter Haverty <haverty.peter at gene.com> wrote: > Thanks Winston! I'm amazed that "[[" beats calling the .Internal > directly. I

Hi, We are developing a package using S4 classes. The S4 classes are wrappers to C++ classes. So S4 classes contain an integer that is the memory address of one C++ object. If an user calls the rm() function, the C++ object must be deleted. But our generic rm() function apparently doesn't work. Here is the code: # The class setClass("component",

As an alternative to the use of multiple shortcus to gain entry to different R environments on WIndows platforms I would like to suggest the use of two R functions written by my colleague John Miyamoto. I have taken the liberty of attaching their definitions to this message. Their efficient use is based on adopting the following regimen or something like it: (1) at startup attach an .Rdata

Hi, On 03/07/2016 09:26 AM, Martin Maechler wrote: > I'm proposing to signal an error (from R >= 3.3.0) in such > examples -- which do "work" in R 3.2.x and earlier : > >> f <- NULL; body(f) <- quote(sin(a+1)); f > function () > sin(a + 1) > <environment: 0x48f9798> > This works because formals() (the getter) works on things that are not a

> Adding an optional argument to get (and mget) like > val <- get(name, where, ..., value.if.not.found=NULL ) (*) > would be useful for many. HOWEVER, it is possible that there could be > some confusion here: (*) can give a NULL because either x exists and > has value NULL, or because x doesn't exist. If that matters, the user > would need to be careful about

Object name completion doesn't work on linux. On S+6 the problem seems to be that ESS uses the argument `inherits' and S+6 is expecting `inherit' . ".Last.value <- get(\".ess.lvsave\",inherits=T)\n") ; envir=1 . "assign(\".ess.lvsave\",.Last.value,inherits=T)\n") ;envir=1 -rw-r--r-- 1 544 everyone 7170 Mar 1 13:55

I've just put up R-0.61.3.tgz and R-0.61.2-0.61.3.diff.gz for anonymous FTP on ftp.stat.auckland.ac.nz. As usual: Don't get it from there unless you are in a desperate hurry. It will migrate to the CRAN sites within a day or two. (See the FAQ for the list of CRAN sites. And see the footer for the FAQ location....) This release mainly fixes a couple of embarassing bugs in 0.61.2. It is