search for: deparsing

> maybe there?s a reason for it, but the discrepancy 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 r...

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("R1","R2"),Col=charact er())) > cbind(m, 101:102,

...$ : 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 of deparsed objects in `traceback()`, a simple work-around is to change the `deparse.max.lines` value: ??? options...

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

...e(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 of deparsed > objects in `traceback()`, a simple work-around is to change the > `deparse.m...

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 Johan johan Faux <johanfaux@yahoo.com> wrote: I have a

In both R and JSON (and many other languages), unicode characters can be escaped using a backslash followed by a lowercase "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&g...

We also have a few other suggestions and wishes about backtrace storage and display on the one hand, and display of constructed calls on the other hand. Perhaps it would be better to open a different wishlist item for traceback() to keep the discussions focused? FWIW I think deparsing backtraces lazily is a great idea. Displaying 1 line per call by default in interactive sessions, while being able to get a more exhaustive output by calling `traceback(max.lines = Inf)`, offers the best of both worlds. Understanding the structure of the backtrace quickly is often more helpful than...

Hi, maybe there?s a reason for it, but the discrepancy 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 ord...

...e(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 of deparsed > objects in `traceback()`, a simple work-around is to change the > `deparse.m...

...st(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 of deparsed >> objects in `traceback()`, a simple work-around is to change...

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(substitute(...))} test.fun(x) #this works test.fun(x,y,z) # I like

I found that predict.gnls failed with a wierd error message about a non-numeric argument to a binary vector in one of three nearly identical uses. Error in Inh/Ki : non-numeric argument to binary operator (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

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 name: x <- 1:10 y <- 10:20 foo <- function(...) {

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(1 + 1)" > deparse(expression(1%in%1)) [1]

...x-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 my recover function, R still sits there using 100% cpu for another 41 seconds before finishing and returning m...

Dear list, When calling R from C, what appears like a spurious error can be triggered during the execution of chisq.test(x, y). This is happening when the following conditions are met: - x and y are "anonymous" C-level R vectors (they do not have a symbol), but they are protected from garbage collection - x and y are "not too small" (it was experienced as soon as they are

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 }

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: if (TYPEOF(vector) == CPLXSXP

...2 } }), srcfile = <environment>) ## no {} > cat(deparse(parse(text='if (TRUE) {1} else {2}')), sep='\n') structure(expression(if (TRUE) { 1 } else { 2 }), srcfile = <environment>) I wonder if there is a way to let 'else' stay with '}' when deparsing the expression. Thanks! > sessionInfo() R version 2.10.0 (2009-10-26) i386-pc-mingw32 locale: [1] LC_COLLATE=Chinese_People's Republic of China.936 [2] LC_CTYPE=Chinese_People's Republic of China.936 [3] LC_MONETARY=Chinese_People's Republic of China.936 [4] LC_NUMERIC=C [5] LC_TIM...