[Rd] introspective capabilities

[Christophe Rhodes]

Hi,

Is there any way, from R code, to perform introspection as to where
certain names acquired their values?  The specific functionality I'm
looking for in this case is to be able to request my editor to view the
definition corresponding to a name in its original source location
(presuming for the moment that that location exists).  Other
functionality that I'm looking for is to identify where in the current
image a particular name is used -- "what functions use the value bound
to a particular name?"

The context for these questions, in case anyone is interested, is that I
am usually a Common Lisp programmer, and my programming environment for
that (SLIME) is what I'm used to.  R is sufficiently close to CL (the
discovery of withCallingHandlers/withRestarts was a pleasant surprise)
that I decided to experiment with implementing a SLIME backend for R --
and enough of it seems to work that I'm motivated to make it more
complete.  (The current state of the project is summarised at
).

Thanks,

Christophe

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] introspective capabilities

[Christophe Rhodes]

Duncan Murdoch  writes:

> On 27/08/2010 7:52 AM, Christophe Rhodes wrote:
>> Hi,
>>
>> Is there any way, from R code, to perform introspection as to where
>> certain names acquired their values?
>
> There's the "keep.source" option to source() and the optional
> "srcfile" argument to parse() that tell R to keep this information.
> If you haven't changed the default
> getOption("keep.source") from TRUE, then source will default to
> keeping it, and you can find the original location of a function
> definition for function f by looking in attr(body(f), "srcref").  See
> ?srcref for the format; there aren't a lot of user-level utility
> functions for working with this.

Thanks.  This is enough for my immediate purposes: supporting
single-keystroke (M-.) jumping to source locations of functions.

> For packages, the relevant option is "keep.source.pkgs" at the time
> the package is installed.

Thank you.

Is there anything like a cross-referencing database within R?  The
functionality I'm looking for here is to be able to name a function, and
come back with a list of functions (or srcrefs) where that name is
used.  (I realise that this is not in general possible; just the
lexically-apparent cases would be enough).

Cheers,

Christophe

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] --max-vsize

[Christophe Rhodes]

Hi,

In both R 2.13 and the SVN trunk, I observe odd behaviour with the
--max-vsize command-line argument:

1. passing a largeish value (about 260M or greater) makes mem.limits()
   report NA for the vsize limit; gc() continues to report a value...

2. ...but that value (and the actual limit) is wrong by a factor of 8.

I attach a patch for issue 2, lightly tested.  I believe that fixing
issue 1 involves changing the return convention of do_memlimits -- not
returning a specialized integer vector, but a more general numeric; I
wasn't confident to do that.

>From 933ab0cfca4657eba217edc99094fd509223e657 Mon Sep 17 00:00:00 2001
From: Christophe Rhodes 
Date: Thu, 21 Jul 2011 14:40:34 +0100
Subject: [PATCH] src/main/memory.c: set R_MaxVSize when assigning to vsfac

Fixes --max-vsize command-line option (previously generated a
limit too great by a factor of 8 on my machines)
---
 src/main/memory.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/main/memory.c b/src/main/memory.c
index f514ffd..46b5d44 100644
--- a/src/main/memory.c
+++ b/src/main/memory.c
@@ -1877,7 +1877,7 @@ void attribute_hidden InitMemory()
 #endif
 vsfac = sizeof(VECREC);
 R_VSize = (((R_VSize + 1)/ vsfac));
-
+R_SetMaxVSize(R_MaxVSize);
 UNMARK_NODE(&UnmarkedNodeTemplate);
 
 for (i = 0; i < NUM_NODE_CLASSES; i++) {
-- 
1.7.5.4


Please let me know if there's anything else I can do.

Best,

Christophe
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] --max-vsize

[Christophe Rhodes]

Prof Brian Ripley  writes:

> Point 1 is as documented: you have exceeded the maximum integer and it
> does say that it gives NA.  So the only 'odd' is reporting that you
> did not read the documentation.

I'm sorry; I thought that my message made it clear that I was aware that
the NA came from exceeding the maximum representable integer.  To
belatedly address the other information I failed to provide, I use R on
Linux, both 32-bit and 64-bit (with 64-bit R).

> Point 2 is R not using the correct units for --max-vsize (it used the
> number of Vcells, as was once documented), and I have fixed.

Thank you; I've read the changes and I think they meet my needs.  (I
will try to explain how/why I want to use larger-than-integer
mem.limits() below.  If there's a better or more supported way to
achieve what I want, that'd be fine too)

> But I do wonder why you are using --max-vsize: the documentation says
> it is very rarely needed, and I suspect that there are better ways to
> do this.

Here's the basic idea: I would like to be able to restrict R to a large
amount of memory (say 4GB, for the sake of argument), but in a way such
that I can increase that limit temporarily if it turns out to be
necessary for some reason.

The desire for a restriction is that I have found it fairly difficult to
predict in advance how much memory a given calculation or analysis is
going to take.  Part of that is my inexperience with R, leading to
hilarious thinkos, but I think that part of that difficulty to predict
is going to remain even as I gain experience.  I use R both on
multi-user systems and on single-user-multiple-use systems, and in both
cases it is usually bad if my R session causes the machine to swap;
usually that swapping is not the result of a desired computation -- most
often, it's from a straightforward mistake -- but it can take
substantial amounts of time for the machine to respond to aborts or kill
requests, and usually if the process grows enough to touch swap it will
continue growing beyond the swap limit too.

So, why not simply slap on an address-space ulimit instead (that being
the kind of ulimit in Linux that actually works...)?  Well, one reason
is that it then becomes necessary to estimate at the start of an R
session how much memory will be needed over the lifetime of that
session; guess too low, and at some point later (maybe days or even
weeks later) I might get a failure to allocate.  My options at that
stage would be to save the workspace and restart the session with a
higher limit, or attempt to delete enough things from the existing
workspace to allow the allocation to succeed.  (Have I missed anything?)
Saving and restarting will take substantial time (from writing ~4GB to
disk) while deleting things from the existing session involves cognitive
overhead that is irrelevant to my current investigation and may in any
case not succeed to free enough.

So, being able to raise the limit to something generally large for a
short time to perform a computation, get the results, and then lower the
limit again allows me to protect myself in general from overwhelming the
machine with mistaken computations, while also allowing in specific
cases the ability to dedicate more resources to a particular
computation.

> I don't find reporting values of several GB as bytes very useful, but
> then mem.limits() is not useful to me either 

Ah, I'm not particularly interested in the reporting side of
mem.limits() :-); the setting side, on the other hand, very much so.

Thank you again for the fixes.

Best,

Christophe

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel