Re: [Rd] Getting hold of a package's environment from C code
On Sun, 22 Oct 2006, Seth Falcon wrote: > Seth Falcon <[EMAIL PROTECTED]> writes: >> Perhaps: >> >> R_FindNamespace(mkString(where)) > > Sorry, this won't help you for package-level code as this function is > part of the internal use only API. It would be nice to have access to > it or a similar function from C in package code. Hmm, it is declared in Rinternals.h, which is the public header for manipulating R objects at C level. As such it is available to packages, but as it is not documented in 'Writing R Extensions' it is subject to change. R_FindNamespace is essentially the same code as Duncan M provided, so it is a pretty simple function. (It still contains a test that namespaces are supported, and that seems long overdue for removal.) -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Getting hold of a package's environment from C code
As far as I can tell from the original post, Deepayan asked for a way
to find a package's namespace environment (rather than the package
environment, not ), so the subject line is
subject to misinterpretation.
On Mon, 23 Oct 2006, Prof Brian Ripley wrote:
> On Sun, 22 Oct 2006, Seth Falcon wrote:
>
>> Seth Falcon <[EMAIL PROTECTED]> writes:
>>> Perhaps:
>>>
>>> R_FindNamespace(mkString(where))
>>
>> Sorry, this won't help you for package-level code as this function is
>> part of the internal use only API. It would be nice to have access to
>> it or a similar function from C in package code.
>
> Hmm, it is declared in Rinternals.h, which is the public header for
> manipulating R objects at C level. As such it is available to packages, but
> as it is not documented in 'Writing R Extensions' it is subject to change.
>
> R_FindNamespace is essentially the same code as Duncan M provided, so it is a
> pretty simple function. (It still contains a test that namespaces are
> supported, and that seems long overdue for removal.)
I think Deepayan's original enquiry was about getting hold of a namespace
environment from within an already loaded namespace. That can be done
entirely at C level, as we don't have the complication of possibly loading
the namespace. Just
val = findVarInFrame(R_NamespaceRegistry, install("pkgname"));
does that job, with val == R_UnboundValue should the namespace not be
loaded. AFAICS, everything here is available to a package writer, and
this is equally undocumented.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Getting hold of a package's environment from C code
On Mon, 23 Oct 2006, Prof Brian Ripley wrote: > On Sun, 22 Oct 2006, Seth Falcon wrote: > >> Seth Falcon <[EMAIL PROTECTED]> writes: >>> Perhaps: >>> >>> R_FindNamespace(mkString(where)) >> >> Sorry, this won't help you for package-level code as this function is >> part of the internal use only API. It would be nice to have access to >> it or a similar function from C in package code. > > Hmm, it is declared in Rinternals.h, which is the public header for > manipulating R objects at C level. As such it is available to packages, > but as it is not documented in 'Writing R Extensions' it is subject to > change. > > R_FindNamespace is essentially the same code as Duncan M provided, so it > is a pretty simple function. (It still contains a test that namespaces > are supported, and that seems long overdue for removal.) Except for a small detail: the code in R_FindNamespace protects the expression before callign eval -- this is needed since eval does not. Best, luke -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Getting hold of a package's environment from C code
On Mon, 23 Oct 2006, Prof Brian Ripley wrote:
> As far as I can tell from the original post, Deepayan asked for a way
> to find a package's namespace environment (rather than the package
> environment, not ), so the subject line is
> subject to misinterpretation.
>
> On Mon, 23 Oct 2006, Prof Brian Ripley wrote:
>
>> On Sun, 22 Oct 2006, Seth Falcon wrote:
>>
>>> Seth Falcon <[EMAIL PROTECTED]> writes:
Perhaps:
R_FindNamespace(mkString(where))
>>>
>>> Sorry, this won't help you for package-level code as this function is
>>> part of the internal use only API. It would be nice to have access to
>>> it or a similar function from C in package code.
>>
>> Hmm, it is declared in Rinternals.h, which is the public header for
>> manipulating R objects at C level. As such it is available to packages, but
>> as it is not documented in 'Writing R Extensions' it is subject to change.
>>
>> R_FindNamespace is essentially the same code as Duncan M provided, so it is a
>> pretty simple function. (It still contains a test that namespaces are
>> supported, and that seems long overdue for removal.)
>
> I think Deepayan's original enquiry was about getting hold of a namespace
> environment from within an already loaded namespace. That can be done
> entirely at C level, as we don't have the complication of possibly loading
> the namespace. Just
>
> val = findVarInFrame(R_NamespaceRegistry, install("pkgname"));
>
> does that job, with val == R_UnboundValue should the namespace not be
> loaded. AFAICS, everything here is available to a package writer, and
> this is equally undocumented.
This level of detail should remain undocumented as it might be useful
to change the representation at some point. R_FindNamespace is a safer
bet, and we probably should document it as officially available..
Best,
luke
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [EMAIL PROTECTED]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changing function arguments
On Sun, 22 Oct 2006, McGehee, Robert wrote: > R-Developers, > I'm looking for some help computing on the R language. > > I'm hoping to write a function that parses a language or expression > object and returns another expression with all instances of certain > argument of a given function altered. For instance, say I would like my > function, myFun to take an expression and whenever the argument 'x' > appears within the function FUN inside that expression, return an > altered expression in which 'x' is incremented by one. > This sort of recursive parsing and modification is done by the bquote() function, so you could look there. -thomas Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Excessive network load
Dear all, I wonder, if anybody experiences similar problems and if there are any simple solutions to be suggested. We observe that R causes a lot of network traffic and thus slows down the performance of the whole network. When tracing the network traffic on the machine which serves the R installation via NFS, we see thousands of requests at initialization of R processes and regular calls, probably to shared libraries. Is there a way to compile or run R such that it causes less load on the network? Here is some information on our installation: - We use a single installation of R (version 2.3.1) loaded over NFS - there are approximately 1500 packages installed using ~8GB of disk - We use R on a queuing system running up to 50 processes in parallel The load on the machine which serves the R installation frequently rises up to 5 or so although it is a dedicated machine. Any hints towards measures against network load are highly appreciated. Thanks, Claudio -- Claudio Lottaz Computational Diagnostics Group Department for Computational Molecular Biology Max-Planck-Institute for Molecular Genetics Ihnestr. 73, D-14195 Berlin (Germany) office: 2.116, phone: +49 30 8413 1177, fax: +49 30 8413 1176 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changing function arguments
Thanks all. Combining your suggestions, and marking up Gabor's example,
below is the function 'chgArg', which recursively goes through an
expression or language object looking for all functions that contain
'arg', and then incrementing that argument by 'offset'.
The biggest improvement over the suggestions is that chgArg checks the
formals of the function such that if the user does not supply the
argument, but instead relies on the default, the function will still
increment. Also, 'match.call' is used to match the user's expression
with the function call in case one is relying on positional or partial
matching.
ex:
> FUN <- function(xx = 0, yy = 0, zz = 0) xx + yy + zz
> e <- substitute(FUN() + FUN(x = 5)/FUN(xx = 5) + FUN(1, 2, 3))
> chgArg(e, "xx", 1)
[1] FUN(xx = 1) + FUN(xx = 6)/FUN(xx = 6) + FUN(xx = 2, yy = 2, zz = 3)
The only surprise I came across was when I tried explicitly setting
name/value arguments for a call, the name did not "stick", as it would
with a list (though a call object is _clearly_ not a list).
> e <- substitute(FUN(2))
> e[["xx"]] <- 3
> names(e)
[1] NULL
Meaning, I had to explicitly build the call using 'call()'.
Thanks as always for the help,
Robert
chgArg <- function (e, arg, offset) {
if (is.expression(e)) return(as.expression(Recall(e[[1]], arg = arg,
offset = offset)))
if (is.symbol(e) || is.double(e)) return (e)
if (is.function(get(as.character(e[[1]]))) &&
arg %in% names(formals(as.character(e[[1]] {
mc <- match.call(get(as.character(e[[1]])), e)
curArg <- ifelse(is.null(mc[[arg]]),
formals(as.character(e[[1]]))[[arg]], mc[[arg]])
allArgs <- as.list(mc[-1])
allArgs[[arg]] <- curArg + offset
e <- do.call("call", c(as.character(mc[[1]]), allArgs))
}
for (i in 1:length(e)) e[[i]] <- Recall(e[[i]], arg = arg, offset =
offset)
return(e)
}
-Original Message-
From: Thomas Lumley [mailto:[EMAIL PROTECTED]
Sent: Monday, October 23, 2006 10:54 AM
To: McGehee, Robert
Cc: R Development Mailing List
Subject: Re: [Rd] Changing function arguments
On Sun, 22 Oct 2006, McGehee, Robert wrote:
> R-Developers,
> I'm looking for some help computing on the R language.
>
> I'm hoping to write a function that parses a language or expression
> object and returns another expression with all instances of certain
> argument of a given function altered. For instance, say I would like
my
> function, myFun to take an expression and whenever the argument 'x'
> appears within the function FUN inside that expression, return an
> altered expression in which 'x' is incremented by one.
>
This sort of recursive parsing and modification is done by the bquote()
function, so you could look there.
-thomas
Thomas Lumley Assoc. Professor, Biostatistics
[EMAIL PROTECTED] University of Washington, Seattle
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Getting hold of a package's environment from C code
On 10/23/06, Luke Tierney <[EMAIL PROTECTED]> wrote:
> On Mon, 23 Oct 2006, Prof Brian Ripley wrote:
>
> > As far as I can tell from the original post, Deepayan asked for a way
> > to find a package's namespace environment (rather than the package
> > environment, not ), so the subject line is
> > subject to misinterpretation.
> >
> > On Mon, 23 Oct 2006, Prof Brian Ripley wrote:
> >
> >> On Sun, 22 Oct 2006, Seth Falcon wrote:
> >>
> >>> Seth Falcon <[EMAIL PROTECTED]> writes:
> Perhaps:
>
> R_FindNamespace(mkString(where))
> >>>
> >>> Sorry, this won't help you for package-level code as this function is
> >>> part of the internal use only API. It would be nice to have access to
> >>> it or a similar function from C in package code.
> >>
> >> Hmm, it is declared in Rinternals.h, which is the public header for
> >> manipulating R objects at C level. As such it is available to packages,
> >> but
> >> as it is not documented in 'Writing R Extensions' it is subject to change.
> >>
> >> R_FindNamespace is essentially the same code as Duncan M provided, so it
> >> is a
> >> pretty simple function. (It still contains a test that namespaces are
> >> supported, and that seems long overdue for removal.)
> >
> > I think Deepayan's original enquiry was about getting hold of a namespace
> > environment from within an already loaded namespace. That can be done
> > entirely at C level, as we don't have the complication of possibly loading
> > the namespace. Just
> >
> > val = findVarInFrame(R_NamespaceRegistry, install("pkgname"));
> >
> > does that job, with val == R_UnboundValue should the namespace not be
> > loaded. AFAICS, everything here is available to a package writer, and
> > this is equally undocumented.
>
> This level of detail should remain undocumented as it might be useful
> to change the representation at some point. R_FindNamespace is a safer
> bet, and we probably should document it as officially available..
OK, so I'm now using
rho = PROTECT(R_FindNamespace(mkString("mypkg"))),
Thanks,
Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ANN/RFC: package providing TAB completion for readline-based R
Announcement: (For those every-once-in-a-while occasions when you run R from a terminal instead of Emacs, and then wish something would happen when you hit TAB...) Last week, I started looking at the GNU Readline documentation to see if I could figure out how to use it for command completion within R. It turned out to be easier than I had expected, and I now have a beta version of the 'rcompletion' package available at http://www.stat.wisc.edu/~deepayan/R/rcompletion_0.0-6.tar.gz >From the help page: Description: This package provides pseudo-intelligent TAB completion for a readline enabled instance of R when it is run from a terminal (or more specifically, an interface which uses readline to accept user input). It has no effect on the various GUI interfaces to R, including ESS and the standard Windows interface. For more details, install and load the package, then type package?rcompletion at the R prompt. Testing and feedback would be appreciated. Feature requests and patches are also welcome, of course. Questions: There are a couple of things about which I would like some advice: (1) The package currently contains a very rudimentary configure script which stops installation when readline is not found. I'm not sure if this is portable enough. .../src/unix/sys-std.c has more sophisticated conditional directives, but I don't know enough about this sort of thing to interpret those. Any thoughts or suggestions on this would be appreciated. (2) What's the recommended procedure to distribute this, given that (a) it's not relevant on Windows (i.e. won't do anything even if it could be installed) and (b) may or may not be relevant on Macs, some of which apparently have a fake readline that doesn't support completion? -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ANN/RFC: package providing TAB completion for readline-based R
On 23 October 2006 at 16:51, Deepayan Sarkar wrote: [... nice announcement trimmed ...] | There are a couple of things about which I would like some advice: | | (1) The package currently contains a very rudimentary configure script | which stops installation when readline is not found. I'm not sure if | this is portable enough. .../src/unix/sys-std.c has more sophisticated | conditional directives, but I don't know enough about this sort of | thing to interpret those. Any thoughts or suggestions on this would be | appreciated. littler has the same issue for getopt, R itself, R as a dynamic library, So far, we are going with 'just bark and stop'. For rcompletion, I hope you simply stick with configure. I don't like the trend of shipping everything again and again (Hi, Seth :) | (2) What's the recommended procedure to distribute this, given that | (a) it's not relevant on Windows (i.e. won't do anything even if it | could be installed) and (b) may or may not be relevant on Macs, some | of which apparently have a fake readline that doesn't support | completion? Again, I also wondered if littler should just pretend to be a CRAN package so that at least the update and compile mechanism works from R (given how we need re-runs of configure and make if something changes as we depend on compile-time 'hard' settings for littler as opposed to env. vars for R). The problem we are facing is that we're unsure how to get to /usr/(local/)/bin from update.packages() ... Given that you'll undoubtedly come up with something clever, Jeff and I will be sure to see if we can mimic it :) Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ANN/RFC: package providing TAB completion for readline-based R
On 10/23/06, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote: > > On 23 October 2006 at 16:51, Deepayan Sarkar wrote: > [... nice announcement trimmed ...] > | There are a couple of things about which I would like some advice: > | > | (1) The package currently contains a very rudimentary configure script > | which stops installation when readline is not found. I'm not sure if > | this is portable enough. .../src/unix/sys-std.c has more sophisticated > | conditional directives, but I don't know enough about this sort of > | thing to interpret those. Any thoughts or suggestions on this would be > | appreciated. > > littler has the same issue for getopt, R itself, R as a dynamic library, > So far, we are going with 'just bark and stop'. > > For rcompletion, I hope you simply stick with configure. I don't like the > trend of shipping everything again and again (Hi, Seth :) > > | (2) What's the recommended procedure to distribute this, given that > | (a) it's not relevant on Windows (i.e. won't do anything even if it > | could be installed) and (b) may or may not be relevant on Macs, some > | of which apparently have a fake readline that doesn't support > | completion? > > Again, I also wondered if littler should just pretend to be a CRAN package so > that at least the update and compile mechanism works from R (given how we > need re-runs of configure and make if something changes as we depend on > compile-time 'hard' settings for littler as opposed to env. vars for R). > > The problem we are facing is that we're unsure how to get to > /usr/(local/)/bin from update.packages() ... > > Given that you'll undoubtedly come up with something clever, Jeff and > I will be sure to see if we can mimic it :) Well, rcompletion is a proper package, the only issue is that it's platform / environment dependent. I know there are other such packages, I just don't know how they are dealt with. I don't see how you can get around the /usr/bin problem for littler, except by asking the user to manually do something like ln -s /path/to/library/littler/bin/r /usr/local/bin/ which at least wouldn't have to be repeated on further upgrades if you detect that the link exists. -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
