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!
Can a function know what other function called it?
9 messages · Robert Gentleman, Kynn Jones, Duncan Murdoch +1 more
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 at 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 rgentlem at fhcrc.org
On Sat, May 23, 2009 at 4:55 PM, Robert Gentleman <rgentlem at fhcrc.org> 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
On 23/05/2009 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.
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.
By default we don't store either a copy of the source or the references
to the source file for functions in a package, but those options can be
enabled, and are enabled by default for users working at the console.
For example, with this source in c:/temp/test.R:
g <- function(x) {
x <- 1
y <- 4
}
You can do the following:
> getOption("keep.source")
[1] TRUE
> source("c:/temp/test.R")
> as.list(g)[[2]]
{
x <- 1
y <- 4
}
attr(,"srcfile")
c:/temp/test.R
You can also find out which part of the file corresponds to each
statement of the function definition. For example,
> attributes(as.list(g)[[2]])
$srcref
$srcref[[1]]
{
$srcref[[2]]
x <- 1
$srcref[[3]]
y <- 4
$srcfile
c:/temp/test.R
> print(attr(as.list(g)[[2]], "srcref")[[2]])
x <- 1
> print(attr(as.list(g)[[2]], "srcref")[[2]], useSource=FALSE)
<srcref: file "c:/temp/test.R" chars 2:3 to 2:8>
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.
The evaluator doesn't pay any attention to srcref records, so this is still true, but it would be possible to keep the srcref on the stack as well as all the other info there. I've written code (and I think I sent it to you last year) that can do things like replacing the statement coming from a particular line of a file with whatever code you like; this could be used in writing a nice source-level debugger. Duncan Murdoch
best wishes Robert
function call? Thanks!
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Duncan Murdoch wrote:
On 23/05/2009 4:55 PM, Robert Gentleman wrote:
Kynn Jones wrote:
[snip]
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.
The evaluator doesn't pay any attention to srcref records, so this is still true, but it would be possible to keep the srcref on the stack as well as all the other info there.
Please
I've written code (and I think I sent it to you last year) that can do things like replacing the statement coming from a particular line of a file with whatever code you like; this could be used in writing a nice source-level debugger.
yes
Duncan Murdoch
best wishes Robert
Romain Francois Independent R Consultant +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr
2 days later
On 5/24/2009 10:23 AM, Romain Francois wrote:
Duncan Murdoch wrote:
On 23/05/2009 4:55 PM, Robert Gentleman wrote:
Kynn Jones wrote:
[snip]
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.
The evaluator doesn't pay any attention to srcref records, so this is still true, but it would be possible to keep the srcref on the stack as well as all the other info there.
Please
Here's a patch file that does this. (Will it make it through to the mailing list? We'll see.) It's still in progress, so I'm not even ready to put it into R-devel, but you're welcome to try it out. The basic idea is that it attaches srcref attributes to the values returned from sys.calls (which won't be displayed, but if you want to play with them you can) and to .Traceback (which traceback() will display). debug() will also show them. Not sure what bad side effects (e.g. on execution time) this has. Duncan Murdoch
I've written code (and I think I sent it to you last year) that can do things like replacing the statement coming from a particular line of a file with whatever code you like; this could be used in writing a nice source-level debugger.
yes
Duncan Murdoch
best wishes Robert
-------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: srcref.patch URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20090526/252500d2/attachment.pl>
Duncan Murdoch wrote:
On 5/24/2009 10:23 AM, Romain Francois wrote:
Duncan Murdoch wrote:
On 23/05/2009 4:55 PM, Robert Gentleman wrote:
Kynn Jones wrote:
[snip]
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.
The evaluator doesn't pay any attention to srcref records, so this is still true, but it would be possible to keep the srcref on the stack as well as all the other info there.
Please
Here's a patch file that does this. (Will it make it through to the mailing list? We'll see.) It's still in progress, so I'm not even ready to put it into R-devel, but you're welcome to try it out. The basic idea is that it attaches srcref attributes to the values returned from sys.calls (which won't be displayed, but if you want to play with them you can) and to .Traceback (which traceback() will display). debug() will also show them. Not sure what bad side effects (e.g. on execution time) this has. Duncan Murdoch
Many thanks. I'll play with this right now. My guess is that since these "srcref" records are calculated anyway by the parser, this won't affect too much the execution time.
I've written code (and I think I sent it to you last year) that can do things like replacing the statement coming from a particular line of a file with whatever code you like; this could be used in writing a nice source-level debugger.
yes
Duncan Murdoch
best wishes Robert
Romain Francois Independent R Consultant +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr
On 5/26/2009 12:57 PM, Romain Francois wrote:
Duncan Murdoch wrote:
On 5/24/2009 10:23 AM, Romain Francois wrote:
Duncan Murdoch wrote:
On 23/05/2009 4:55 PM, Robert Gentleman wrote:
Kynn Jones wrote:
[snip]
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.
The evaluator doesn't pay any attention to srcref records, so this is still true, but it would be possible to keep the srcref on the stack as well as all the other info there.
Please
Here's a patch file that does this. (Will it make it through to the mailing list? We'll see.) It's still in progress, so I'm not even ready to put it into R-devel, but you're welcome to try it out. The basic idea is that it attaches srcref attributes to the values returned from sys.calls (which won't be displayed, but if you want to play with them you can) and to .Traceback (which traceback() will display). debug() will also show them. Not sure what bad side effects (e.g. on execution time) this has. Duncan Murdoch
Many thanks. I'll play with this right now. My guess is that since these "srcref" records are calculated anyway by the parser, this won't affect too much the execution time.
It does add a little extra execution time to every statement, and more to lines that have source references. Whether enough to matter, I don't know. Duncan Murdoch
I've written code (and I think I sent it to you last year) that can do things like replacing the statement coming from a particular line of a file with whatever code you like; this could be used in writing a nice source-level debugger.
yes
Duncan Murdoch
best wishes Robert
On 5/26/2009 12:57 PM, Romain Francois wrote:
Duncan Murdoch wrote:
On 5/24/2009 10:23 AM, Romain Francois wrote:
Duncan Murdoch wrote:
On 23/05/2009 4:55 PM, Robert Gentleman wrote:
Kynn Jones wrote:
[snip]
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.
The evaluator doesn't pay any attention to srcref records, so this is still true, but it would be possible to keep the srcref on the stack as well as all the other info there.
Please
Here's a patch file that does this. (Will it make it through to the mailing list? We'll see.) It's still in progress, so I'm not even ready to put it into R-devel, but you're welcome to try it out. The basic idea is that it attaches srcref attributes to the values returned from sys.calls (which won't be displayed, but if you want to play with them you can) and to .Traceback (which traceback() will display). debug() will also show them. Not sure what bad side effects (e.g. on execution time) this has. Duncan Murdoch
Many thanks. I'll play with this right now. My guess is that since these "srcref" records are calculated anyway by the parser, this won't affect too much the execution time.
I have now committed a more complete version of the code to R-devel. It's still "experimental"; formats of the displays are likely to change, and the internal structures might. This is likely to disrupt front-ends that expect a particular format from tracebacks or the debugger; hopefully the added information will make up for the inconvenience. Duncan Murdoch
I've written code (and I think I sent it to you last year) that can do things like replacing the statement coming from a particular line of a file with whatever code you like; this could be used in writing a nice source-level debugger.
yes
Duncan Murdoch
best wishes Robert