similar to: R-alpha: deparse bug

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

Full_Name: Kamil Barto? Version: 2.8.0 OS: windows xp Submission from: (NULL) (212.33.92.187) According to the "deparse" function documentation "nlines" is the *maximum* number of lines to produce. But, when "nlines" argument is supplied, it produces exactly nlines of result, and the result contains empty elements at the end. Example: >

Dear R developers, while experimenting with repeated measures ANOVA, I found out that it is possible to construct a model specification that is syntactically valid, but causes aov() to abort with an error. A minimal reproducer and its output are attached to this mail. I was able to reproduce this problem with the latest SVN revision. The root cause is similar to that of bug 15377: aov()

Dear R-helpers, I would like to change the default value of a functions that is call by a package. The function deparse() is called by a set of functions from a library and because I don't think is appropriate to change the library, I am trying to change the default value in deparse(). At the moment the only solution I have come across is to place a function in my working environment 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

The R-1.2.1 builds have gone fairly smoothly on most of my UNIX architectures, but there were many warnings reported by the picky SGI compiler that could be eliminated in future releases. Generally, I have found the SGI compilers very helpful in ferreting out portability problems, unused and/or obsolete variables, unexpected datatype coercions, etc., and they compile faster than any other

Thierry, thanks for this, this is a bug in utils:::.format_person_as_R_code(). This calls deparse() on the elements of the person object with the default width.cutoff = 60. As your comment exceeds this width, the erroneous formatting is produced. The simplest reproducible example I could come up with was: p <- person(".", comment = c(foo = ".....................",

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

>>>>> Berry, Charles <ccberry at ucsd.edu> >>>>> on Tue, 1 May 2018 16:43:18 +0000 writes: >> On May 1, 2018, at 6:11 AM, Therneau, Terry M., Ph.D. via R-devel <r-devel at r-project.org> wrote: >> >> A user sent me an example where coxph fails, and the root of the failure is a case where names(mf) is not equal to the

>>>>> Daniel Chen >>>>> on Fri, 12 Jul 2019 13:53:21 -0500 writes: > Hi everyone: > I?m one of the interns at RStudio this summer working on a project that > helps teachers grade student code. I found an unexpected behaviour with > the |==| operator when comparing |quote|d expressions. > Example 1: > |u <-

My points: - The 'withCallingHandlers' construct that is used in current 'stopifnot' code has no effect. Without it, the warning message is the same. The overridden warning is not raised. The original warning stays. - Overriding call in error and warning to 'cl.i' doesn't always give better outcome. The original call may be "narrower" than 'cl.i'. I

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,

> 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

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

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,

A private reply by Martin made me realize that I was wrong about stopifnot(exprs=TRUE) . It actually works fine. I apologize. What I tried and was failed was stopifnot(exprs=T) . Error in exprs[[1]] : object of type 'symbol' is not subsettable The shortcut assert <- function(exprs) stopifnot(exprs = exprs) mentioned in "Warning" section of the documentation similarly fails

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, 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]

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

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 <-