Re: [Rd] Recursively parsing srcrefs
Le 12/05/11 21:59, Hadley Wickham a écrit :
Is it possible to recursively parse srcrefs to match the recursive
structure of the underlying code? I'm interested in this because it's
I don't understand what you mean by that. It is certainly possible to walk
through nested srcrefs, to zoom in on a particular location; that's what
findLineNum() does.
Does the example below not help? Given the whole function, I want to
be able to walk down the call tree, finding the matching src refs as I
go. i.e. given f, how do I get f_inside?
f- function(x = T) {
# This is a comment
if (x) return(4)
if (emergency_status()) return(T)
}
f_inside- parse(text =
# This is a comment
if (x) return(4)
if (emergency_status()) return(T)
)
findLineNum doesn't quite do what I want - it works on the text of the
srcref, not on the parse tree.
Here's another go at explaining what I want:
h- quote(
1 # one
+ # plus
2 # two
)
h[[1]] extracts +. What can I do to extract + # plus (on an object
created in the appropriate manner to keep the srcref)? Is that even
possible?
Maybe the parser package can help you.
x - parser( /tmp/test.R )
attr( x, data )
line1 col1 byte1 line2 col2 byte2 token id parent top_level
token.desc terminal text
1 10 0 11 1 263 1 3 0
SYMBOL TRUE h
2 11 1 13 3 265 2 32 0
LEFT_ASSIGN TRUE -
3 10 0 11 177 3 32 0
exprFALSE
4 14 4 19 9 296 5 7 0
SYMBOL_FUNCTION_CALL TRUE quote
5 19 9 1 101040 6 30 0
'(' TRUE (
6 14 4 19 977 7 30 0
exprFALSE
7 23 3 24 4 261 10 11 0
NUM_CONST TRUE 1
8 23 3 24 477 11 27 0
exprFALSE
9 25 5 2 1010 289 13 27 0
COMMENT TRUE # one
10 33 3 34 443 16 27 0
'+' TRUE +
11 35 5 3 1111 289 18 27 0
COMMENT TRUE # plus
12 43 3 44 4 261 21 22 0
NUM_CONST TRUE 2
13 43 3 44 477 22 27 0
exprFALSE
14 45 5 4 1010 289 24 30 0
COMMENT TRUE # two
15 50 0 51 141 26 30 0
')' TRUE )
16 23 3 44 477 27 30 0
exprFALSE
17 14 4 51 177 30 32 0
exprFALSE
18 10 0 51 177 32 0 0
exprFALSE
Romain
My eventual goal is something like
f- function(x) {
# This is my function
T
}
g- fix_logical_abbreviations(f)
which would be equivalent to
g- function(x) {
# This is my function
TRUE
}
That last display looks like a bug indeed. I'll take a look.
The key seems to be a leading newline:
parse(text = \nx)
parse(text = x)
Hadley
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/hdKhCy : Rcpp article in JSS
|- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
`- http://bit.ly/fhqbRC : Rcpp workshop in Chicago on April 28th
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Generic Function for dffits?
Dear All, help(influence.measures) shows that there are generic functions for dfbetas(), covratio(), cooks.distance(), hatvalues(), and a few others, but apparently not for dffits(). Wouldn't it be more consistent to have a generic function for this in stats as well? Best, -- Wolfgang Viechtbauer Department of Psychiatry and Neuropsychology School for Mental Health and Neuroscience Maastricht University, P.O. Box 616 6200 MD Maastricht, The Netherlands Tel: +31 (43) 368-5248 Fax: +31 (43) 368-8689 Web: http://www.wvbauer.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Create and access several instances of a C++ class from R
On 07.05.2011, at 11:15, Romain Francois wrote: Try having do_bar with this signature: void do_bar(NumericVector data); And my advice would probably also to have your C field either as a NumericVector. NumericVector is just a thin wrapper around the internal R data structure. Having data members as direct pointers is dangerous and not a very C++ way of doing things. If you want to learn about the STL, there are many books that cover it and plenty of online resources. I use this : http://cplusplus.com/reference/stl/. Using the STL is easier than dealing with pointers and stuff. If your game is to pass down a double* to some api you use, you can use the begin method of NumericVector, this will give you the array pointer (as would REAL do on the underlying SEXP): [...] For the files: the discussion continues here: http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2011-May/002261.html Regards Sören __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RProfmem output format
Hi all, When I run the example in RProfmem, I get: Rprofmem(Rprofmem.out, threshold=1000) example(glm) Rprofmem(NULL) noquote(readLines(Rprofmem.out, n=5)) ... [1] 1384 :5416 :5416 :1064 :1064 :readRDS index.search example [2] 1064 :readRDS index.search example [3] 4712 :readRDS index.search example [4] 4712 :readRDS index.search example [5] 1064 :readRDS index.search example What do 5 the numbers in the first line mean? In the subsequence lines I'm assuming the structure is bytes allocated : call. Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Reproducible use case for R crash after updating R
A simple version of a fix is now in R-devel: if the .RData file can't be loaded during startup, an error message is printed, and R starts with an empty workspace. The name of the .RData file is printed. It's usually just .RData, because that's what R tries to load; the file will be in the current directory if you want to delete it. If it contains objects that you want to recover, you can try to deal with the error message (e.g. by installing fortunes in your example), exiting without saving, and then the next restart may succeed. Duncan Murdoch On 11-05-12 2:26 PM, Henrik Bengtsson wrote: On Thu, May 12, 2011 at 10:55 AM, Henrik Bengtssonh...@biostat.ucsf.edu wrote: This might have been discussed before, but below is a not-so-unlikely use case where the user follows normal procedures, updates R to a major release version, and then R crashes: 1. Use runs R stable (e.g. v2.13.0). 2. User installs a package with a namespace, e.g. install.packages(fortunes). 3. User uses the package and one of the package's objects are assigned to the global env, e.g. foo- fortune. 4. The user quits R and stores the session data, e.g. q(yes). The session is stored in users home directory. 5. User update to new major release of R (e.g. 2.14.0). 6. User starts R. R crashes with Fatal error: unable to restore saved object in .RData because 'fortunes' is not installed for this new version of R. There is also an error message before that reporting Error in loadNamespace(name) : there is no package called 'fortunes'. This can also be reproduced using a single R version as follows: 1. Start R and do: install.packages(fortunes) library(fortunes) foo- fortune remove.packages(fortunes) q(yes) 2. Restart R. R crashes. For a GUI-only user this is complicated, because although the users sees the informative error message that Error in loadNamespace(name) : there is no package called 'fortunes', s/he cannot get to the point where it is possible to install that missing package. The key for the user is to understand to remove the .RData. In order to do this, s/he has to locate that file first. To simplify this, a few alternatives exists: 1. R reports the full path to the problematic .RData file. 2. R renames the problematic .RData file to erroneous_20110512-123404UTC.RData and reports the new full pathname. In both cases there could be the option for R to either exit, or ignore the problematic .RData file and give the user access to the prompt. One could also imaging a fancy recovery feature where R detects erroneous .RData files and asks the user if s/he wish to try to load them (maybe the packages has been installed since). On Windows, the easiest way to give a GUI-only user access to the R prompt is to also install an R (vanilla mode) shortcut/icon on the Startup menu and Desktop (with target ...\Rgui.exe --vanilla) in addition to the default one. /Henrik I'm sure there are complications to implement the above, because .RData is loaded during startup, but that's my $.02 to this problem /Henrik __ 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] Recursively parsing srcrefs
On 11-05-12 2:37 PM, Duncan Murdoch wrote:
On 12/05/2011 1:02 PM, Hadley Wickham wrote:
Hi all,
Is it possible to recursively parse srcrefs to match the recursive
structure of the underlying code? I'm interested in this because it's
I don't understand what you mean by that. It is certainly possible to
walk through nested srcrefs, to zoom in on a particular location; that's
what findLineNum() does.
the final step in allowing functions to modify other functions while
preserving the original source. I've tried to make a bit of demo of
what I want to do below, and I think I may uncovered a bug in parse.
f- function(x = T) {
# This is a comment
if (x) return(4)
if (emergency_status()) return(T)
}
parsed_src- parse(text = attr(f, source))
src_ref- attr(parsed_src, srcref)[[1]]
f_one- parse(text = {
# This is a comment
if (x) return(4)
if (emergency_status()) return(T)
})
attr(f_one, srcref)[[1]]
f_inside- parse(text =
# This is a comment
if (x) return(4)
if (emergency_status()) return(T)
)
f_inside # Displays incorrectly?
attr(f_inside, srcref)[[1]]
# Should be:
# # This is a comment
# if (x) return(4)
That last display looks like a bug indeed. I'll take a look.
The bug is now fixed in R-devel and R-patched.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R html help system [Was: How to document man/*.Rd pages with images?]
On 5/12/11 9:13 AM, Simon Urbanek simon.urba...@r-project.org wrote:
I just want to clarify the mechanics of the help system when using html.
R has a built-in HTTP server (aka Rhttpd) which transforms HTTP requests to
function calls. It is not your usual web server, because it doesn't map URL
paths to files, it just allows R functions to do anything with it -- something
like CGI except that we are talking about functions and not files. Therefore
you won't find any files and there is no file structure involved.
For the help system, the function handling the requests is tools:::httpd() -
you can look at what it does.
Awesome, will do!
Basically, it generates pages according to the
various paths it supports. As part of its path handling it allows certain
paths to reference files, e.g.
/library/myPackage/doc/randomStuffInPackagesDocDirectory.html will read the
file doc/randomStuffInPackagesDocDirectory.html in myPackage.
Note that the whole point of the dynamic help *is* to generate content on the
fly, because the content depends on the state of your current workspace --
packages loaded, classes defined, etc. so you cannot pre-generate pages as
they won't have correct links - that's why we shifted from static html pages
to the dynamic ones.
This is interesting. It actually speaks to a constructive criticism I have
of R. As a user of R, I don't want to have conditional dynamic help. I want
to always get the same answer to a question so to say. If there is a way to
do something that works and is reproducible, then I don't want to maybe or
maybe not get that answer. Thus, I guess what I'm thinking is that there
should maybe be selection within help that has organization based on
packages loaded and classes defined, but I would hope that the state of my
system doesn't change the help that is displayed. At least I as one user
would prefer to see all of my options will all packages and not have any of
it emphasized or excluded by how my system is currently set up.
In the satus quo, I can see how the choice of which pages to look at is
dynamic if more than one comes up on a search, but it seems inefficient to
me to have the page itself be dynamic. I think it would be a good idea if
package authors could at least have an option to have their help pages
produced as files either way. I mean, when my package will be loaded, I
certainly won't want options and do want to be able to point my users to an
unconditional file location to point their browser to.
I'm curious about If it¹s a large picture this process nearly crashes my
machine when trying to access the file via help - do you have an example
package that would illustrate the problem?
I¹ve tried to recreate the problem with a small fake package, and although
it passes the check it doesn¹t seem to work quite right on my system. I
might have some compiler issues or configuration issues though, so it might
work as is on your system. If not, I think you could quickly find the
relevant parts though and add them to a package of your own to see the bug
if this doesn¹t work as is on your machine. I¹m not really sure why this
doesn¹t work on my machine. I did almost exactly the same thing as in the
huge package that I can¹t fit on my file transfer site. However, it is set
up to only install in 64-bit and I couldn't remember how I set that up. So
it might be the 32-bit part that is messing things up on my system. I think
there should be a simple way to declare an architecture in a package
DESCRIPTION or something. I can't remember. Anyway, that's beside the point.
Here is an example of a syntax and image file that makes my help go
extremely slow and not show images:
http://ftsext.mskcc.org/FileExchange/FileList.aspx?id=9afb4fe1-ce1c-406d-b1a
1-c9360493137c
Please let me know if you see why this isn¹t working for me--both as to if
this works as is on your system and as to if this causes the bug. At the
moment this tells me Error in gzfile(file, rb) : cannot open the
connection even though it passes all the build check install tests on my
machine.
Thanks,
Simon
On May 11, 2011, at 7:14 PM, Sean Robert McGuffee wrote:
Thanks everyone for your help,
To summarize a resolution to my issue, it turns out that an image can be
include in a documentation file via html by putting an image file in the
inst/doc directory, for example inst/doc/myPic.png, and then pointing to it
in the man/myHelpPage.Rd file, for example as follows:
\if{html}{
\out{img src=../doc/myPic.png alt=image ../doc/myPic.png should be
here/}
}\ifelse{latex}{}{}
Note, this doesn¹t mean that R¹s help browser will view those images inside
the properly generated html help files.
Also, note that without the \out{} part, the text of the img .../ line
would show up instead of the html commands.
I have some concerns incase anyone on the list is interested. If it¹s a large
picture this process nearly crashes my machine when trying to access the file
Re: [Rd] R html help system [Was: How to document man/*.Rd pages with images?]
On May 13, 2011, at 7:08 PM, Sean Robert McGuffee wrote: On 5/12/11 9:13 AM, Simon Urbanek simon.urba...@r-project.org wrote: I just want to clarify the mechanics of the help system when using html. R has a built-in HTTP server (aka Rhttpd) which transforms HTTP requests to function calls. It is not your usual web server, because it doesn't map URL paths to files, it just allows R functions to do anything with it -- something like CGI except that we are talking about functions and not files. Therefore you won't find any files and there is no file structure involved. For the help system, the function handling the requests is tools:::httpd() - you can look at what it does. Awesome, will do! Basically, it generates pages according to the various paths it supports. As part of its path handling it allows certain paths to reference files, e.g. /library/myPackage/doc/randomStuffInPackagesDocDirectory.html will read the file doc/randomStuffInPackagesDocDirectory.html in myPackage. Note that the whole point of the dynamic help *is* to generate content on the fly, because the content depends on the state of your current workspace -- packages loaded, classes defined, etc. so you cannot pre-generate pages as they won't have correct links - that's why we shifted from static html pages to the dynamic ones. This is interesting. It actually speaks to a constructive criticism I have of R. As a user of R, I don't want to have conditional dynamic help. I want to always get the same answer to a question so to say. If there is a way to do something that works and is reproducible, then I don't want to maybe or maybe not get that answer. Thus, I guess what I'm thinking is that there should maybe be selection within help that has organization based on packages loaded and classes defined, but I would hope that the state of my system doesn't change the help that is displayed. At least I as one user would prefer to see all of my options will all packages and not have any of it emphasized or excluded by how my system is currently set up. I don't think I follow you. Your options will be different, by definition, depending on which packages you have installed and loaded. As one obvious example, you can't refer to documentation of packages that you did not install. As another example (more future-directed I suspect), the generics and methods depend on your currently defined classes, methods etc. That is true in R itself, so I don't see why you would prefer documentation that doesn't match your R. In the satus quo, I can see how the choice of which pages to look at is dynamic if more than one comes up on a search, but it seems inefficient to me to have the page itself be dynamic. I think it would be a good idea if package authors could at least have an option to have their help pages produced as files either way. That decision is left to the user - you can use --html to generate html pages. I mean, when my package will be loaded, I certainly won't want options and do want to be able to point my users to an unconditional file location to point their browser to. You can do that with dynamically generated pages (you can't do that with static pages in fact) - the paths are well defined (unlike in your file system). Even better is fact, because the dynamic help is smart enough to find packages in different libraries, for example. I'm curious about If it’s a large picture this process nearly crashes my machine when trying to access the file via help - do you have an example package that would illustrate the problem? I’ve tried to recreate the problem with a small fake package, and although it passes the check it doesn’t seem to work quite right on my system. I might have some compiler issues or configuration issues though, so it might work as is on your system. If not, I think you could quickly find the relevant parts though and add them to a package of your own to see the bug if this doesn’t work as is on your machine. I’m not really sure why this doesn’t work on my machine. I did almost exactly the same thing as in the huge package that I can’t fit on my file transfer site. However, it is set up to only install in 64-bit and I couldn't remember how I set that up. So it might be the 32-bit part that is messing things up on my system. I think there should be a simple way to declare an architecture in a package DESCRIPTION or something. I can't remember. Anyway, that's beside the point. Here is an example of a syntax and image file that makes my help go extremely slow and not show images: http://ftsext.mskcc.org/FileExchange/FileList.aspx?id=9afb4fe1-ce1c-406d-b1a 1-c9360493137c Please let me know if you see why this isn’t working for me--both as to if this works as is on your system and as to if this causes the bug. At the moment this tells me Error in gzfile(file, rb) : cannot open the connection even though it passes
