Re: [Rd] [R] step by step debugger in R?
[moving this to r-devel] Robert Gentleman wrote: Hi, Romain Francois wrote: Duncan Murdoch wrote: On 5/22/2009 10:59 AM, Michael wrote: Really I think if there is a Visual Studio strength debugger, our collective time spent in developing R code will be greatly reduced. If someone who knows how to write a debugger plugin for Eclipse wants to help, we could have that fairly easily. All the infrastructure is there; it's the UI part that's missing. Duncan Murdoch [I've copied Mark Bravington and Robert Gentleman to the list as they are likely to have views here, and I am not sure they monitor R-help] Hello, Making a front-end to debugging was one of the proposed google summer of code for this year [1], it was not retained eventually, but I am still motivated. Pretty much all infrastructure is there, and some work has been done __very recently__ in R's debugging internals (ability to step up). As I see it, the ability to call some sort of hook each time the debugger waits for input would make it much easier for someone to write I have still not come to an understanding of what this is supposed to do? When you have the browser prompt you can call any function or code you want to. There is no need for something special to allow you to do that. Sure. What I have in mind is something that gets __automatically__ called, similar to the task callback but happening right before the user is given the browser prompt. front-ends. A recent post of mine (patch included) [2] on R-devel suggested a custom prompt for browser which would do the trick, but I now think that a hook would be more appropriate. Without something similar to that, there is no way that I know of for making a front-end, unless maybe if you embed R ... (please let me know how I am wrong) I think you are wrong. I can't see why it is needed. The external debugger has lots of options for handling debugging. It can rewrite code (see examples in trace for how John Chambers has done this to support tracing at a location), which is AFAIK a pretty standard approach to writing debuggers. It can figure out where the break point is (made a bit easier by allowing it to put in pieces of text in the call to browser). These are things the internal debugger can't do. Thanks. I'll have another look into that. There is also the debug package [3,4] which does __not__ work with R internals but rather works with instrumenting tricks at the R level. debug provides a tcl/tk front-end. It is my understanding that it does not work using R internals (do_browser, ...) because it was not possible at the time, and I believe this is still not possible today, but I might be wrong. I'd prefer to be wrong actually. I don't understand this statement. It has always been possible to work with the internal version - but one can also take the approach of rewriting code. There are some difficulties supporting all the operations that one would like by rewriting code and I think a combination of external controls and the internal debugger will get most of the functionality that anyone wants. There are somethings that are hard and once I have a more complete list I will be adding this to the appropriate manual. I will also be documenting the changes that I have been making, but that project is in flux and won't be done until the end of August, so people who want to look at it are welcome (it is in R-devel), but it is in development and could change pretty much without notice. Romain noted that we now support stepping out from one place to another function. We also have a debugonce flag that lets you get close to step in, but step in is very hard in R. I am mostly interested in writing tools in R that can be used by anyone that wants to write an external debugger and am not that interested in any particular external debugger. I would be happy to listen to feature requests or issues that arise - but the discussion should probably be on R-devel mailing list. best wishes Robert Romain [1] : http://www.r-project.org/soc09/ideas.html#p5 [2] : https://stat.ethz.ch/pipermail/r-devel/2009-April/053128.html [3] : http://cran.r-project.org/web/packages/debug/index.html [4] : http://cran.r-project.org/doc/Rnews/Rnews_2003-3.pdf -- Romain Francois Independent R Consultant +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] as.numeric(levels(factor(x))) may be a decreasing sequence
Function factor() in the current development version (2009-05-22)
guarantees that levels are different character strings. However, they
may represent the same decimal number. The following example is derived
from a posting by Stavros Macrakis in thread "Match .3 in a sequence"
in March
nums <- 0.3 + 2e-16 * c(-2,-1,1,2)
f <- factor(nums)
levels(f)
# [1] "0.300" "0.3"
The levels differ in trailing zeros, but represent the same decimal number.
Besides that this is not really meaningful, it may cause a problem, when
using as.numeric(levels(f)).
In the above case, as.numeric() works fine and maps the two levels to the same
number. However, there are cases, where the difference in trailing zeros
implies different values in as.numeric(levels(f)) and these values may even
form a decreasing sequence although levels were constructed from an increasing
sequence of numbers.
Examples are platform dependent, but may be found by the following code.
Tested on Intel under Linux (both with and without SSE) and also under Windows
with an older version of R.
for (i in 1:10) {
x <- 10^(floor(runif(1, 61, 63)) + runif(1)/2)
x <- as.numeric(sprintf("%.14g", x))
eps <- 2^(floor(log2(x)) - 52)
k <- round(x * c(5e-16, 1e-15) / eps)
if (x > 1e62) { k <- rev( - k) }
y <- x + k[1]:k[2] * eps
ind <- which(diff(as.numeric(as.character(y))) < 0)
for (j in ind) {
u1 <- y[c(j, j+1)]
u2 <- factor(u1)
print(levels(u2))
print(diff(as.numeric(levels(u2
aux <- readline("next")
}
}
An example of the output is
[1] "1.2296427920313e+61" "1.22964279203130e+61"
[1] -1.427248e+45
next
[1] "1.82328862326830e+62" "1.8232886232683e+62"
[1] -2.283596e+46
next
The negative number in diff(as.numeric(levels(u2))) demonstrates cases,
when as.numeric(levels(u2)) is decreasing. We can also see that the reason
is that the two strings in levels(u2) differ in the trailing zeros.
I did quite intensive search for such examples for all possible exponents
(not only 61 and 62 and a week of CPU on three processors) and all the obtained
examples were caused by a difference in trailing zeros. So, i believe that
removing trailing zeros from the output of as.character(x) solves the problem
with the reversed order in as.numeric(levels(factor(x))) entirely.
A patch against R-devel_2009-05-22, which eliminates trailing zeros
from as.character(x), but makes no other changes to as.character(x),
is in an attachment. Using the patch, we obtain a better result also
in the following.
nums <- 0.3 + 2e-16 * c(-2,-1,1,2)
factor(nums)
# [1] 0.3 0.3 0.3 0.3
# Levels: 0.3
Petr.
--- R-devel/src/main/coerce.c 2009-04-17 17:53:35.0 +0200
+++ R-devel-elim-trailing/src/main/coerce.c 2009-05-23 08:39:03.914774176
+0200
@@ -294,12 +294,33 @@
else return mkChar(EncodeInteger(x, w));
}
+const char *elim_trailing(const char *s, char cdec)
+{
+const char *p;
+char *replace;
+for (p = s; *p; p++) {
+if (*p == cdec) {
+replace = (char *) p++;
+while ('0' <= *p & *p <= '9') {
+if (*(p++) != '0') {
+replace = (char *) p;
+}
+}
+while (*(replace++) = *(p++)) {
+;
+}
+break;
+}
+}
+return s;
+}
+
SEXP attribute_hidden StringFromReal(double x, int *warn)
{
int w, d, e;
formatReal(&x, 1, &w, &d, &e, 0);
if (ISNA(x)) return NA_STRING;
-else return mkChar(EncodeReal(x, w, d, e, OutDec));
+else return mkChar(elim_trailing(EncodeReal(x, w, d, e, OutDec), OutDec));
}
SEXP attribute_hidden StringFromComplex(Rcomplex x, int *warn)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange install key for R
Gabor Grothendieck wrote: One user of my batchfiles http://batchfiles.googlecode.com found they did not find the R registry key because it mysteriously was at hklm\software\wow6432Node. The system was a 64 bit system. I've always seen the key at hklm\software\R-core\R which is what the batchfiles assume. So you have not been on 64-bit Windows before - and you still you those batchfiles? Anyway, it does redirect the entries for (almost?) all 32-bit Software. You might want to read MS Documentation if you feel this is an important issue. Best, Uwe Ligges Has there been some change in where the installer puts the key or are there situations in which the location of the key in the registry is somehow changed? (Note that the batchfiles do have two workarounds in case the user cannot or wishes not to access the registry but it would be better not to have to rely on those.) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange install key for R
2009/5/23 Uwe Ligges : > > > Gabor Grothendieck wrote: >> >> One user of my batchfiles >> http://batchfiles.googlecode.com >> found they did not find the R registry key because it mysteriously >> was at hklm\software\wow6432Node. The system >> was a 64 bit system. I've always seen the key at >> hklm\software\R-core\R which is what the batchfiles assume. > > So you have not been on 64-bit Windows before - and you still you those > batchfiles? Anyway, it does redirect the entries for (almost?) all 32-bit > Software. You might want to read MS Documentation if you feel this is an > important issue. For architectures I don't have I rely on users to provide feedback. On 64 bit Windows, the key is not being redirected by Windows. I assume that this is dependent on how one accesses the key. Perhaps redirection is supported through certain APIs and not others. At any rate, I am assuming from your answer that R is not involved in such redirection and am adding code to handle both sets of keys. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] file descriptor leak in getSrcLines in R 2.10.0 svn 48590
On 22/05/2009 11:29 AM, Duncan Murdoch wrote: On 5/21/2009 2:17 PM, William Dunlap wrote: I noticed the following file descriptor leak when I couldn't remove a package unless I shut down the R session that had loaded and used it. The function that triggered the problem printed the output of a call to parse(). Each time one prints a srcref a connection is opened and not closed. It looks like it happens in as.character.srcref's call to getSrcLines, which has some logic I don't understand about closing 'srcfile' on exit only if !.is.Open(srcfile): I have a simpler recipe to reproduce the crash now: tf <- tempfile() con <- file(tf, open="w", encoding="unknown") This gives an error message about an unsupported conversion and leaves the con object only partially built. closeAllConnections() will then crash. Should be relatively easy to fix...I'll take a look. Fixed now in R-devel and R-patched. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problems building R-2.9.0 on solaris
Hi, I've successfully updated our linux version of R to 2.9.0 but am having trouble on our solaris machine. I had previously installed 2.8.1 and earlier versions without trouble. I'm using R-patched_2009-05-20.tar.gz (I had also tried the 2009-05-10 version). Here's some info on our machine (I'm not the sysadmin): [2] bedrock:/home/jayoung> uname -a SunOS bedrock 5.10 Generic_118833-36 sun4v sparc SUNW,Sun-Fire-T200 Here's how I have been successfully installing the last few versions of R: setenv LD_LIBRARY_PATH /home/jayoung/mysql/mysql-5.0.45-solaris10- sparc-64bit/lib:/opt/SUNWspro/lib:/usr/lib:/usr/openwin/lib setenv PATH /home/jayoung/mysql/mysql-5.0.45-solaris10-sparc-64bit/lib/ bin:/bin:/sbin:/usr/sbin:/etc:/opt/SUNWspro/bin:/usr/ccs/bin unsetenv R_HOME ./configure --enable-R-shlib R_PAPERSIZE='letter' --prefix='/home/ btrask/traskdata' make make install Now, when I do that, configure looks like it completes OK, but during "make" it fails. It also fails if I omit the "--enable-R-shlib" during configure. It fails in a different way if I use my regular environment (i.e. start a new terminal, and use the commands as above but omitting the two setenv lines) - but that has never worked, so I won't bother you with the details of that (unless it seems like useful information to someone?). The setenvs I'm using (PATH and LD_LIBRARY_PATH) were given to me by the syadmin people here as a suggestion to get R installation working. Below I have pasted the last part of the output from make: >>> Building/Updating help pages for package 'tcltk' Formats: text html latex example TclInterface texthtmllatex example TkCommandstexthtmllatex example TkWidgetcmds texthtmllatex example TkWidgets texthtmllatex example tclServiceModetexthtmllatex example tcltk-defunct texthtmllatex tcltk-package texthtmllatex tkProgressBar texthtmllatex example tkStartGUItexthtmllatex tk_choose.dir texthtmllatex example tk_choose.files texthtmllatex example tk_messageBox texthtmllatex tk_select.listtexthtmllatex tkpager texthtmllatex begin installing recommended package VR ERROR unable to create '/home/jayoung/source_codes/R/R-2.9.0/ unpack_solaris3/R-patched/library/MASS' *** Error code 1 The following command caused the error: MAKE="make" R_LIBS= ../../../bin/R CMD INSTALL --no-lock -l "../../../ library" VR.tgz > VR.ts.out 2>&1 || (cat VR.ts.out && exit 1) make: Fatal error: Command failed for target `VR.ts' Current working directory /home/jayoung/source_codes/R/R-2.9.0/ unpack_solaris3/R-patched/src/library/Recommended *** Error code 1 The following command caused the error: make stamp-recommended make: Fatal error: Command failed for target `recommended-packages' Current working directory /home/jayoung/source_codes/R/R-2.9.0/ unpack_solaris3/R-patched/src/library/Recommended *** Error code 1 The following command caused the error: (cd src/library/Recommended && make) make: Fatal error: Command failed for target `stamp-recommended' I'm not sure if this is a bug, or something screwy about the way our system is set up (I suspect the latter). I'd be grateful for any ideas you might have to help me figure this out. thanks in advance, Janet Young --- Dr. Janet Young (Trask lab) Fred Hutchinson Cancer Research Center 1100 Fairview Avenue N., C3-168, P.O. Box 19024, Seattle, WA 98109-1024, USA. tel: (206) 667 1471 fax: (206) 667 6524 email: jayoung ...at... fhcrc.org http://www.fhcrc.org/labs/trask/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] remez (signal) causes unhandled exception (PR#13713)
Full_Name: Attila Kocsis
Version: 2.9.0
OS: windows
Submission from: (NULL) (91.120.153.114)
I have installed R 2.9.0 on Windows.
Then installed signal package.
Then I issue the following commands in RGUI or rterm:
require("signal")
f1 = remez(17,c(0,0.1,0.0625,1),c(1,1,0.001,0.001))
and the R clashes.
The possible cause of the problem is that no solution with given parameters is
possible. Maybe it runs into infinite loop.
With the command
f1 = remez(17,c(0,0.1,0.2,1),c(1,1,0.001,0.001))
it is OK.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] remez (signal) causes unhandled exception (PR#13713)
atkoc...@iqrs.hu wrote:
Full_Name: Attila Kocsis
Version: 2.9.0
OS: windows
Submission from: (NULL) (91.120.153.114)
I have installed R 2.9.0 on Windows.
Then installed signal package.
Then I issue the following commands in RGUI or rterm:
Well, this happens in the remez() function that calls an entry point in
compiled code of the package signal. Please report bugs of contributed
packages to the package maintainer rather than to R-bugs.
Uwe Ligges
require("signal")
f1 = remez(17,c(0,0.1,0.0625,1),c(1,1,0.001,0.001))
and the R clashes.
The possible cause of the problem is that no solution with given parameters is
possible. Maybe it runs into infinite loop.
With the command
f1 = remez(17,c(0,0.1,0.2,1),c(1,1,0.001,0.001))
it is OK.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] qbinom (PR#13711)
On Wed, May 20, 2009 at 11:10:11PM +0200, wolfgang.re...@gmail.com wrote:
...
> Strange behavior of qbinom:
>
> > qbinom(0.01, 5016279, 1e-07)
> [1] 0
> > qbinom(0.01, 5016279, 2e-07)
> [1] 16
> > qbinom(0.01, 5016279, 3e-07)
> [1] 16
> > qbinom(0.01, 5016279, 4e-07)
> [1] 16
> > qbinom(0.01, 5016279, 5e-07)
> [1] 0
>
There is a bug in function do_search() in file src/nmath/qbinom.c. This
function contains a cycle
for(;;) {
if(y == 0 ||
(*z = pbinom(y - incr, n, pr, /*l._t.*/TRUE, /*log_p*/FALSE)) <
p)
return y;
y = fmax2(0, y - incr);
}
When this cycle stops, *z contains pbinom(y - incr, ...), but is used
as if it is pbinom(y, ...) for the resulting y.
In the example qbinom(p=0.01, size=5016279, prob=4e-07), we get at
some step y=15 as a result of a search left with incr=50, so we have
*z=pbinom(-35, ...)=0. Hence, y=15 is treated as too low and is increased
to 16. Since 16 is detected to be sufficient, the search stops with y=16,
which is wrong.
A possible correction is to replace the code above by
double newz;
for(;;) {
if(y == 0 ||
(newz = pbinom(y - incr, n, pr, /*l._t.*/TRUE, /*log_p*/FALSE))
< p)
return y;
y = fmax2(0, y - incr);
*z = newz;
}
Patch against R-devel_2009-05-22 is in an attachment.
Verification may be done using the following examples.
b1 <- qbinom(p=0.01, size=5016279, prob=(1:20)*1e-07)
b2 <- qbinom(p=0.01, size=5006279, prob=(1:20)*1e-07)
b3 <- qbinom(p=0.01, size=5000279, prob=(1:20)*1e-07)
p1 <- qpois(p=0.01, lambda=5016279*(1:20)*1e-07)
p2 <- qpois(p=0.01, lambda=5006279*(1:20)*1e-07)
p3 <- qpois(p=0.01, lambda=5000279*(1:20)*1e-07)
cbind(b1, b2, b3, p1, p2, p3)
Wrong
b1 b2 b3 p1 p2 p3
[1,] 0 0 0 0 0 0
[2,] 16 6 50 0 0 0
[3,] 16 6 50 0 0 0
[4,] 16 6 50 0 0 0
[5,] 0 0 0 0 0 0
[6,] 0 0 0 0 0 0
[7,] 0 0 0 0 0 0
[8,] 0 0 0 0 0 0
[9,] 0 0 0 0 0 0
[10,] 1 1 1 1 1 1
[11,] 1 1 1 1 1 1
[12,] 1 1 1 1 1 1
[13,] 1 1 1 1 1 1
[14,] 2 2 2 2 2 2
[15,] 2 2 2 2 2 2
[16,] 2 2 2 2 2 2
[17,] 19 9 53 3 3 3
[18,] 3 3 3 3 3 3
[19,] 3 3 3 3 3 3
[20,] 3 3 3 3 3 3
Correct
b1 b2 b3 p1 p2 p3
[1,] 0 0 0 0 0 0
[2,] 0 0 0 0 0 0
[3,] 0 0 0 0 0 0
[4,] 0 0 0 0 0 0
[5,] 0 0 0 0 0 0
[6,] 0 0 0 0 0 0
[7,] 0 0 0 0 0 0
[8,] 0 0 0 0 0 0
[9,] 0 0 0 0 0 0
[10,] 1 1 1 1 1 1
[11,] 1 1 1 1 1 1
[12,] 1 1 1 1 1 1
[13,] 1 1 1 1 1 1
[14,] 2 2 2 2 2 2
[15,] 2 2 2 2 2 2
[16,] 2 2 2 2 2 2
[17,] 3 3 3 3 3 3
[18,] 3 3 3 3 3 3
[19,] 3 3 3 3 3 3
[20,] 3 3 3 3 3 3
Petr.
--- R-devel/src/nmath/qbinom.c 2007-07-25 17:54:27.0 +0200
+++ R-devel-qbinom/src/nmath/qbinom.c 2009-05-23 17:22:43.538566976 +0200
@@ -36,6 +36,7 @@
static double
do_search(double y, double *z, double p, double n, double pr, double incr)
{
+double newz;
if(*z >= p) {
/* search to the left */
#ifdef DEBUG_qbinom
@@ -43,9 +44,10 @@
#endif
for(;;) {
if(y == 0 ||
- (*z = pbinom(y - incr, n, pr, /*l._t.*/TRUE, /*log_p*/FALSE)) <
p)
+ (newz = pbinom(y - incr, n, pr, /*l._t.*/TRUE, /*log_p*/FALSE))
< p)
return y;
y = fmax2(0, y - incr);
+ *z = newz;
}
}
else { /* search to the right */
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] step by step debugger in R?
Hi, I stripped the cc's as I believe that all read this list. Romain Francois wrote: > [moving this to r-devel] > > Robert Gentleman wrote: >> Hi, >> >> Romain Francois wrote: >> >>> Duncan Murdoch wrote: >>> On 5/22/2009 10:59 AM, Michael wrote: > Really I think if there is a Visual Studio strength debugger, our > collective time spent in developing R code will be greatly reduced. > If someone who knows how to write a debugger plugin for Eclipse wants to help, we could have that fairly easily. All the infrastructure is there; it's the UI part that's missing. Duncan Murdoch >>> [I've copied Mark Bravington and Robert Gentleman to the list as they >>> are likely to have views here, and I am not sure they monitor R-help] >>> >>> Hello, >>> >>> Making a front-end to debugging was one of the proposed google summer of >>> code for this year [1], it was not retained eventually, but I am still >>> motivated. >>> >>> Pretty much all infrastructure is there, and some work has been done >>> __very recently__ in R's debugging internals (ability to step up). As I >>> see it, the ability to call some sort of hook each time the debugger >>> waits for input would make it much easier for someone to write >>> >> >> I have still not come to an understanding of what this is supposed to >> do? When >> you have the browser prompt you can call any function or code you want >> to. There >> is no need for something special to allow you to do that. >> > Sure. What I have in mind is something that gets __automatically__ > called, similar to the task callback but happening right before the user > is given the browser prompt. I am trying to understand the scenario you have in mind. Is it that the user is running R directly and your debugger is essentially a helper function that gets updated etc as R runs? If so, then I don't think that works very well and given the constraints we have with R I don't think it will be able to solve many of the problems that an IDE should. The hook you want will give you some functionality, but no where near enough. Let me suggest instead that the IDE should be running the show. It should initialize an instance of R, but it controls all communication and hence controls what is rendered on the client side. If that is what you mean by embedding R, then yes that is what is needed. There is no way that I can see to support most of the things that IDE type debuggers support without the IDE controlling the communication with R. And if I am wrong about what your debugger will look like please let me know. best wishes Robert > >>> front-ends. A recent post of mine (patch included) [2] on R-devel >>> suggested a custom prompt for browser which would do the trick, but I >>> now think that a hook would be more appropriate. Without something >>> similar to that, there is no way that I know of for making a front-end, >>> unless maybe if you embed R ... (please let me know how I am wrong) >>> >> >> I think you are wrong. I can't see why it is needed. The external >> debugger has >> lots of options for handling debugging. It can rewrite code (see >> examples in >> trace for how John Chambers has done this to support tracing at a >> location), >> which is AFAIK a pretty standard approach to writing debuggers. It can >> figure >> out where the break point is (made a bit easier by allowing it to put >> in pieces >> of text in the call to browser). These are things the internal >> debugger can't do. >> >> > Thanks. I'll have another look into that. > >>> There is also the debug package [3,4] which does __not__ work with R >>> internals but rather works with instrumenting tricks at the R level. >>> debug provides a tcl/tk front-end. It is my understanding that it does >>> not work using R internals (do_browser, ...) because it was not possible >>> at the time, and I believe this is still not possible today, but I might >>> be wrong. I'd prefer to be wrong actually. >>> >> >> I don't understand this statement. It has always been possible to >> work with >> the internal version - but one can also take the approach of rewriting >> code. >> There are some difficulties supporting all the operations that one >> would like by >> rewriting code and I think a combination of external controls and the >> internal >> debugger will get most of the functionality that anyone wants. >> >> There are somethings that are hard and once I have a more complete >> list I will >> be adding this to the appropriate manual. I will also be documenting >> the changes >> that I have been making, but that project is in flux and won't be done >> until the >> end of August, so people who want to look at it are welcome (it is in >> R-devel), >> but it is in development and could change pretty much without notice. >> Romain noted that we now support stepping out from one place to another >> function. We also have a debugonce
[Rd] Can a function know what other function called it?
Suppose function foo calls function bar. Is there any way in which bar can find out the name of the function that called it, "foo"? There are two generalization to this question that interest me. First, can this query go farther up the call stack? I.e. if bar now calls baz, can baz find out the name of the function that called the function that called it, i.e. "foo"? Second, what other information, beside its name, can bar find about the environment where it was called? E.g. can it find out the file name and line number of the function call? Thanks! __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Can a function know what other function called it?
Hi Kynn,
Kynn Jones wrote:
> Suppose function foo calls function bar. Is there any way in which
> bar can find out the name of the function that called it, "foo"?
essentially yes. You can find out about the call stack by using sys.calls and
sys.parents etc. The man page plus additional manuals should be sufficient, but
let us know if there are things that are not clear.
>
> There are two generalization to this question that interest me.
> First, can this query go farther up the call stack? I.e. if bar now
> calls baz, can baz find out the name of the function that called the
> function that called it, i.e. "foo"? Second, what other information,
yes - you can (at least currently) get access to the entire calling stack and
some manipulations can be performed.
> beside its name, can bar find about the environment where it was
> called? E.g. can it find out the file name and line number of the
there is no real concept of file and line number associated with a function
definition (nor need their even be a name - functions can be anonymous).
If you want to map back to source files then I think that currently we do not
keep quite enough information when a function is sourced. Others may be able to
elaborate more (or correct my mistakes). I think we currently store the actual
text for the body of the function so that it can be used for printing, but we
don't store a file name/location/line number or anything of that sort. It could
probably be added, but would be a lot of work, so it would need someone who
really wanted it to do that.
However, you can find out lots of other things if you want. Do note that while
it is possible to determine which function initiated the call, it is not
necessarily possible to figure out which of the calls (if there is more than one
in the body of the function) is active. R does not keep track of things in that
way. To be clear if foo looks like:
foo <- function(x) {
bar(x)
x = sqrt(x)
bar(x)
}
and you have a breakpoint in bar, you could not (easily) distinguish which of
the two calls to bar was active. There is no line counter or anything of that
sort available.
best wishes
Robert
> function call?
>
> Thanks!
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
PO Box 19024
Seattle, Washington 98109-1024
206-667-7700
rgent...@fhcrc.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Can a function know what other function called it?
On Sat, May 23, 2009 at 4:55 PM, Robert Gentleman wrote:
> Hi Kynn,
>
>
> Kynn Jones wrote:
>> Suppose function foo calls function bar. Is there any way in which
>> bar can find out the name of the function that called it, "foo"?
>
> essentially yes. You can find out about the call stack by using sys.calls and
> sys.parents etc. The man page plus additional manuals should be sufficient,
> but
> let us know if there are things that are not clear.
Thanks a lot! That was very helpful.
This is the best I was able to come up with:
bar <- function() {
caller <- sub("\\(.*", "", rev(sys.calls())[[2]])
cat(sprintf("bar: i was called by \"%s\"\n", caller))
}
foo <- function() bar()
> foo()
bar: i was called by "foo"
>
So it works, but I'm a n00b with R. If there's a less labored way to
achieve this, please let me know.
And thanks again for your response. It was very instructive.
KJ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using a "third party" DLL in my package
On May 20, 2009, at 4:32 , Seija Sirkiä wrote: Hello again, thank you for the comments, especially this one: Prof Brian Ripley wrote: > My concern would be that there are different cases that fail under > Fortran compiler X and you are just sweeping the problem under the > carpet. It inspired us to go back to search the cause, and we've made some progress: it's not the compiler, it's the compiler options. Simple, but it took a while to figure that out since my experience in these things is limited. When I build the package with default options using INSTALL --build the dll is built with option -O3 as per R's Makeconfig file. If I build the dll by hand, using gfortran with no additional options and dyn.load it, everything works, and also with - O and -Os. (No, I don't fully understand what the differences between all these are, but that's another question). I'm looking at chapter 5.5 in Writing R Extensions and also 6.3.3 in R Installation and Administration but I can't figure out how to tell "inside" my package that it is not to be built -O3 but with, say, - O. I can see how to add flags in the package (and as far as I can tell, if there are several optimization level flags the last in line is used and that's the wrong one from my point of view), and also how to override flags but only on my computer. Am I blind or am I again attempting something I shouldn't? This is not trivial, and how you do it is compiler dependent. A quick fix was provided by Simon Urbanek a while back and it is _not_ portable, it assumes you are using GCC. It would be nice to have a configure file that detects the compiler and optimization setting and then re-sets the optimization level. I have thought about writing one, but have never got around to do it. Anyway, the fix is in the Makevars file from affxparser from Bioconductor. Essentially, you use a Makevars file placed in the src directory, containing MYCXXFLAGS=-O0 -Wall %.o: %.cpp $(CXX) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) $(MYCXXFLAGS) -c $< -o $@ Essentially this makes sure that -O0 (indicating no optimization) is placed at the _end_ of the call to the compiler (this is for C++ files btw), using the fact that if you have two -O* settings, the last one overrides the first. This ought to be easily adaptable to FORTRAN. Kasper __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using a "third party" DLL in my package
It is likely that this is related to using higher-precision FPU registers, in which case there is a portable solution: look up SAFE_FFLAGS in 'Writing R Extensions'. But if that is the cause, the real solution is to write the code using proper convergence tests. On Sat, 23 May 2009, Kasper Daniel Hansen wrote: On May 20, 2009, at 4:32 , Seija Sirkiä wrote: Hello again, thank you for the comments, especially this one: Prof Brian Ripley wrote: My concern would be that there are different cases that fail under Fortran compiler X and you are just sweeping the problem under the carpet. It inspired us to go back to search the cause, and we've made some progress: it's not the compiler, it's the compiler options. Simple, but it took a while to figure that out since my experience in these things is limited. When I build the package with default options using INSTALL --build the dll is built with option -O3 as per R's Makeconfig file. If I build the dll by hand, using gfortran with no additional options and dyn.load it, everything works, and also with -O and -Os. (No, I don't fully understand what the differences between all these are, but that's another question). I'm looking at chapter 5.5 in Writing R Extensions and also 6.3.3 in R Installation and Administration but I can't figure out how to tell "inside" my package that it is not to be built -O3 but with, say, -O. I can see how to add flags in the package (and as far as I can tell, if there are several optimization level flags the last in line is used and that's the wrong one from my point of view), and also how to override flags but only on my computer. Am I blind or am I again attempting something I shouldn't? This is not trivial, and how you do it is compiler dependent. A quick fix was provided by Simon Urbanek a while back and it is _not_ portable, it assumes you are using GCC. It would be nice to have a configure file that detects the compiler and optimization setting and then re-sets the optimization level. I have thought about writing one, but have never got around to do it. Anyway, the fix is in the Makevars file from affxparser from Bioconductor. Essentially, you use a Makevars file placed in the src directory, containing MYCXXFLAGS=-O0 -Wall %.o: %.cpp $(CXX) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) $(MYCXXFLAGS) -c $< -o $@ Essentially this makes sure that -O0 (indicating no optimization) is placed at the _end_ of the call to the compiler (this is for C++ files btw), using the fact that if you have two -O* settings, the last one overrides the first. This ought to be easily adaptable to FORTRAN. Kasper __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk 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
