search for: deparse

...deparsing seems odd to me: > > > substitute(a[1], list(a = quote(x * y))) > x * y[1] > > > substitute(a$b, list(a = quote(x * y))) > (x * y)$b > > The former is still executed in the right order (`*` first, then > `[`), which is not what you?d expect looking at the deparse result. This is one of a large number of bugs in the deparser and parser that are fixed in the latest version of pqR (of 2015-09-14), as a result of a complete rewrite of the parser and extensive revisions to the deparser. As I communicated to this list, it would be reasonably easy to incorporat...

Should the deparse.level=2 argument to cbind and rbind be abandoned? It is minimally documented, not used in any CRAN package, and causes some problems. E.g., (a) If a matrix input has row names but not column names cbind(deparse.level=2,...) stops. > m<-matrix(11:14,nrow=2,ncol=2,dimnames=list(Row=c(&quo...

...28154224809259, 0.292572240810841, " ... ??? ##? $ : chr "do.call(paste0, list(abs, x))" ??? ##? $ : chr "system.time(do.call(paste0, list(abs, x)))" The first time I noticed this I thought my session had frozen/crashed as the standard interrupt ^C does not work during the deparse.? The stall happens when on error the call stack is deparsed prior to being saved to `.Traceback`.? The deparsing is done by `deparse1m` in native code, with the value of `getOption('deparse.max.lines')` which defaults to all lines. Since there is little value to seeing millions of lines o...

There seems to be a bug arising when using multiple S4 generics with "..." as the signature. The following code works as expected: ############################################################## > setGeneric("rbind", function(..., deparse.level=1) standardGeneric("rbind"), + signature = "...") Creating a generic for "rbind" in package ".GlobalEnv" (the supplied definition differs from and overrides the implicit generic in package "base": Signatures differ: (...), (de...

...raise issue 2., the patch itself makes no attempt to resolve it. The proposed patch resolves issue 1., which is a big usability problem.? Right now if you have the misfortune of using `do.call` with a big object and trigger an error, you have the choice of waiting a possibly long time for the deparse to complete, or killing your entire R session externally. It seems a shame to allow a big usability issue for `do.call` to remain when there is a simple solution at hand, especially since the complete deparse of large objects likely serves no purpose in this case. Obviously, if storing the actua...

I have a question about "deparse" function in R What is the reason that "deparse" use an argument like "width.cutoff" ? Why the maximum cutoff is 500? I was manipulating an R formula and used "deparse". Since the length of user's formula was greater then 500, my code didnt work. thanks Joha...

...ase "u" and a 4 digit hex code. However when deparsing a character vector in R on Windows, the non-latin characters get escaped as "<U+" followed by their 4 digit hex code and ">": > x <- "I like \u5BFF\u53F8" > cat(x) I like ?? > src <- deparse(x) > cat(src) "I like <U+5BFF><U+53F8>" Same thing happens on linux when we disable UTF8: Sys.setlocale("LC_ALL", "C") x <- "I like \u5BFF\u53F8" nchar(x) #9, seems OK cat(deparse(x)) "I like <U+5BFF><U+53F8>" As a r...

...to resolve it. >> >> The proposed patch resolves issue 1., which is a big >> usability problem. Right now if you have the misfortune of >> using `do.call` with a big object and trigger an error, you >> have the choice of waiting a possibly long time for >> the deparse to complete, or killing your entire R session >> externally. >> >> It seems a shame to allow a big usability issue for `do.call` >> to remain when there is a simple solution at hand, especially >> since the complete deparse of large objects likely serves no >> p...

...pancy between the handling of `[` and `$` in deparsing seems odd to me: > substitute(a[1], list(a = quote(x * y))) x * y[1] > substitute(a$b, list(a = quote(x * y))) (x * y)$b The former is still executed in the right order (`*` first, then `[`), which is not what you?d expect looking at the deparse result. Some code that shows the execution order: x <- 1; y <- 1; class(y) <- "foo"; `*.foo` <- function(...) -1; expr <- substitute(a[1], list(a=quote(x * y))); list(expr=expr, eval=eval(expr), "x * y[1]"=x * y[1], "(x * y)[1]"=(x * y)[1]) The followin...

...240810841, " ... > ??? ##? $ : chr "do.call(paste0, list(abs, x))" > ??? ##? $ : chr "system.time(do.call(paste0, list(abs, x)))" > > The first time I noticed this I thought my session had frozen/crashed > as the standard interrupt ^C does not work during the deparse.? The > stall happens when on error the call stack is deparsed prior to being > saved to `.Traceback`.? The deparsing is done by `deparse1m` in native > code, with the value of `getOption('deparse.max.lines')` which > defaults to all lines. > > Since there is little value...

...elf makes no > attempt to resolve it. > > The proposed patch resolves issue 1., which is a big > usability problem.? Right now if you have the misfortune of > using `do.call` with a big object and trigger an error, you > have the choice of waiting a possibly long time for > the deparse to complete, or killing your entire R session > externally. > > It seems a shame to allow a big usability issue for `do.call` > to remain when there is a simple solution at hand, especially > since the complete deparse of large objects likely serves no > purpose in this case. Obvi...

Dear R helpers: I like to apply deparse(substitute()) on multiple arguments to collect the names of the arguments into a character vector. I used function test.fun as below. it works when there is only one input argument. but it does not work for multiple arguements. can someone kindly help? test.fun <- function(...){deparse(substitu...

...r (Inh and Ki are arguments to the function used in the formula for the object whose predictions were requested). It turns out that the problem is in getCovariateFormula(). The final line in getCovariateFormula() in the nlme package (version 3.1-16) is: eval(parse(text = paste("~", deparse(form)))) however, if deparse(form) exceeds 'width.cutoff (which defaults to 60)', this results in inappropriately placed "~" signs: For example, in my application with the error, form is UnCompetitive(MethoxyresorufinConc, InhibitorConc, Vmax, Km, Ki) the result of the paste()...

I see that plot.default uses deparse(substitute(x)) to extract the character name of an argument and put it on the vertical axis. Hence: foo <- 1:10 plot( foo ) will put the label "foo" on the vertical axis. However, for a function that takes a "..." list as an input, I can only extract the first argument nam...

Hi, I observed a slight problem in deparse(): it will add spaces around most operators except /. I wonder if this is easy to fix. I know this is quite trivial, but I will appreciate if / is not treated as an exception. Examples: > deparse(expression(1/1)) [1] "expression(1/1)" > deparse(expression(1+1)) [1] "expression...

I'm using: R 2.15.1 (beta), 2012-06-11, svn.rev 59557, x86_64-unknown-linux-gnu And I normally use: options("error"=recover) I recently ran into a problem where when my code called stop(), recover() was incredibly slow (hours) because it was trying to deparse an extremely large call. I worked around that by instead using my own recover function which avoids deparsing anything large. (Perhaps it would be better to instead make the deparsing much faster, but I don't know how to do that.) However, now I find that when I'm DONE debugging and exit...

...d from garbage collection - x and y are "not too small" (it was experienced as soon as they are longer than 17 elements). The error is Error in names(dimnames(x)) <- DNAME : 'names' attribute [4] must be the same length as the vector [2] and can be traced to the use of deparse(substitute(x)) and deparse(substitute(y)) in the R code. What seems to be happening is that the deparse(substitute(x)) call gives a character vector of length > 1 as soon as x is "not so small". To demonstrate this, I am using rpy2 (as the problem was found when using it http://sour...

Hi all, I don't understand why this does not what I expect : ## code start here ############## setClass("num",representation(x="numeric")) num<-function(x) new("num",x=x) add<-function(e1,e2) { cat("Computing ",deparse(substitute(e1)),"+",deparse(substitute(e2)),"\n") e1@x+e2@x } setMethod("+","num",function(e1,e2) { cat("Computing ",deparse(substitute(e1)),"+",deparse(substitute(e2)),"\n") e1@x+e2@x }) a<-num(3.2) b<-num(-...

If you set the "digits17" control option in deparse, you get a lot of unnecessary space in the representation of complex numbers. > deparse(0 + 0i) [1] "0+0i" > deparse(0 + 0i, control = "digits17") [1] "0 + 0i" As far as I can tell, the logic for this comes from this piece of /src/main/deparse.c...

Hi all, It is recommended in ?'if' that we use 'else' right after '}' instead of starting a new line, but I noticed deparse() will separate '}' and 'else' when the 'if...else' clause is used inside {...} (e.g. function body). Here is an example: ## if/else inside {} > cat(deparse(parse(text='function(){if (TRUE) {1} else {2}}')), sep='\n') structure(expression(function() {...