similar to: deparse with parentheses for SUBSET

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

I have rewritten the R parser in the new version of pqR that I recently released (pqR-2015-09-14, at pqR-project.org). The new version of the parser is much cleaner, is faster (sometimes quite substantially faster), has a better interface to the read-eval-print loop, and provides a better basis for future extensions. The deparser has also been substantially revised in pqR, and is better

This is probably best viewed in the context of other issue with displaying calls, such as issues arising from calls constructed in non-standard evaluation contexts. Might be good to move to a wishlist item in bugzilla. Best, luke On Sat, 13 Jul 2019, brodie gaslam via R-devel wrote: > When large calls cause errors R may stall for extended periods.? This > is particularly likely to happen

Better to add this to the wishlist item. This all needs to be looked at together, and nothing is likely to happen until after vacation/conference season. It will disappear from everyone's radar if it is just in R_devel. Best, luke On Sun, 14 Jul 2019, brodie gaslam wrote: > Luke, thanks for considering the issue.? I would like to > try to separate the problem into two parts, as I

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

When large calls cause errors R may stall for extended periods.? This is particularly likely to happen with `do.call`, as in this example with a 24 second stall: ??? x <- runif(1e7) ??? system.time(do.call(paste0, list(abs, x)))? # intentional error ??? ## Error in (function (..., collapse = NULL)? : ??? ##?? cannot coerce type 'builtin' to vector of type 'character' ??? ##

Luke, thanks for considering the issue.? I would like to try to separate the problem into two parts, as I _think_ your comments address primarily part 2 below: 1. How can we avoid significant and possibly crippling ?? stalls on error with these non-standard calls. 2. What is the best way to view these non-standard calls. I agree that issue 2. requires further thought and discussion under a

Full_Name: John Brzustowski Version: 2.8.1 OS: linux Submission from: (NULL) (67.71.250.146) When entering a debug()'ed function, the call printout is not limited by options()$deparse.max.lines as it is when one uses browser() or trace(). Should it be? If so, here's a patch: diff -cr R-2.8.1/src/library/base/man/options.Rd R-2.8.1-patched/src/library/base/man/options.Rd ***

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}}')),

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

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,

Hi all, I am experiencing the following quite strange (at least in my knowledge) problem in a simple function like the following: fn<-function(y,v=2){ n<-length(y) y<-y[(v+1):(n-v)] plot(y,type="l",lty=3,xlab="Time",ylab=deparse(substitute(y))) } fn(rnorm(50)) #look at the plot!!! The plot appears with numbers on the left side! If I delete the

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

Dear R-help Listers, I am curious if there is some (hopefully easy) way to change the number of characters that can be converted to a single string via any of deparse, as.character or toString. It seems that the limit is 500 for all of these. I saw a previous post where Prof. Ripley suggested that it was a "trivial" change in the R internals to change as.character's limit from 60

The deparse function has an argument "width.cutoff" which allows you to set the width at which line breaking is attempted. However, setting this argument _permanently_ changes the line break width. Looking at the source code ($RHOME/src/main/deparse.c), I see that the width.cutoff argument sets the static variable "cutoff". Although the function do_deparse behaves correctly

Dear List, I have the following function: coca <- function(x, ...) { if(is.null(class(x))) class(x) <- data.class(x) UseMethod("coca", x) } and a default method coca.default <- function(x, y, method = c("predictive", "symmetric"), reg.method = c("simpls", "eigen"), weights = NULL,

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]

On 07/05/2017 3:56 PM, Spencer Graves wrote: > In an implied call to an S3 print method, deparse(substitute(x)) returns > "x", regardless of the name of object in .GlobalEnv, as indicated in the > following: > > > > Xnamed <- 1 > > class(Xnamed) <- 'name.x' > > print.name.x <- function(x, ...){ > + namex <-

Dear R helpers, I want to know about the implications of changing the max..deparse.length parameter in tinn-R. I use tinn-R as my text editor. I had a problem recently in reading in a?statement that ran for many lines.. I was trying to recode some factors with long names into short ones. I got the following error message : >

Hi, I'm writing a function that needs the input names (as characterstrings) as part of the output. With deparse(substitute( ) ) that works fine, until I replace all zeros with 0.001 (log is calculated at some time): tf <- function(input) { input[input==0] <- 0.001 ; deparse(substitute(input)) } myguess <- 42 tf(myguess) # not "myguess", but "42" Now when