similar to: Rd parser throws error for user macros invoked with empty argument

While on the topic of Rd macro arguments, it seems that if a multiline argument is supplied, the lines after the first are silently ignored: f <- tempfile() mac6 <- "\\newcommand{\\mac6}{mac6: #1}" cat(mac6, "\\mac6{2*3 2+2 sin(pi) }\n", file = f) rd <- tools::parse_Rd(f) > rd mac6: 2*3 --- Georgi Boshnakov -----Original Message----- From: Tomas Kalibera

Thanks for the report, I am testing a patch that will allow multi-line arguments to user macros. Best Tomas On 05/25/2018 04:45 PM, Georgi Boshnakov wrote: > While on the topic of Rd macro arguments, it seems that if a multiline argument is supplied, the lines after the first are silently ignored: > > f <- tempfile() > mac6 <- "\\newcommand{\\mac6}{mac6: #1}" >

Thanks for the report and the examples - and they do not have to be that verbose, it is enough to just define and use a command, e.g. cat("\\newcommand{\\mac1}{MAC1:#1}\\mac1{}", file=f) rd <- tools::parse_Rd(f) Whenever you get an error message like "Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'", there is a bug (at least the error message

Dear friends, I have just gotten a strange error message back from Uwe saying that the most recent version of psych failed to pass R CMD check for Windows. The error message was less than helpful, in that it seems to have failed when trying to include the Rcpp library, which I do not directly call. (see below) "* using log directory

Hi, I wonder if the following (apparent) inconsistency is a bug or feature. Since scalars are simply vectors of length one I would think that a and a:a produce the same result. For example, > identical(4.01,4.01:4.01) [1] TRUE However, identical(4,4:4) [1] FALSE and > identical(4.0,4.0:4.0) [1] FALSE A closer look reveals that the colon operator produces objects

Have UI that simplifies running code from another (internal) package, allowing user to set values on fields I basically grabbed from results of calls to formals() for various functions. That works fine for the most part. But it was requested to investigate some type of popup help or something for each field. Since I already wrote the information in the dot-Rd files for what should be displayed,

> ... reports that the fortran names of all the registered fortran functions are ?undocumented objects?... Those symbols should not be exported. In quantreg v5.33, NAMESPACE has 'exportPattern(".")'. Maybe it is a good time to remove that and export explicitly the symbols that are meant for export. Georgi Boshnakov ------------------------------ Message: 6 Date: Fri, 28

Bringing up an old topic on a small technicality. In the help documentation on seq. Value: The result is of 'mode' '"integer"' if 'from' is (numerically equal to an) integer and 'by' is not specified. The arguement in seq specifying length also creates "double" which is not obvious in the wording, as "by" is not specified

Bringing up an old topic on a small technicality. In the help documentation on seq. Value: The result is of 'mode' '"integer"' if 'from' is (numerically equal to an) integer and 'by' is not specified. The arguement in seq specifying length also creates "double" which is not obvious in the wording, as "by" is not specified

Hi, The result of as,character() on 'srcref' objects doesn't have the closing ')' in some cases involving 'quote': > e4 <- quote({2+2}) > class(attr(e4, "wholeSrcref")) [1] "srcref" > as.character(attr(e4, "wholeSrcref")) [1] "e4 <- quote({2+2}" As a result printing the object also lacks it and gives an

On 28/06/2019 6:27 a.m., Koenker, Roger W wrote: > Thanks, I was just coming to that conclusion and beginning to look for a way to make a list of > exportable objects. After library(quantreg), ls("package:quantreg") will list all the names you currently export. So cat(ls("package:quantreg"), sep = ", ") will print the list in a form suitable for including

Windows XP. I have just updated to R 2.11.0 and then run update.packages. In the series of updates, a few will succeed, then I get a failure like package 'mvtnorm' successfully unpacked and MD5 sums checked package 'party' successfully unpacked and MD5 sums checked package 'PBSmodelling' successfully unpacked and MD5 sums checked Error in normalizePath(path) :

> > "These operators are also implicit S4 generics, but as > > primitives, S4 methods will be dispatched only on S4 > > objects ?x?." > Yes, exactly, very well found, Georgi! I'm sorry Martin, but I don't understand your point here. I'm assuming that you want the (S3) matrix, x, to be converted to an (S4) Matrix. However, this is not a

Full_Name: Georgi Boshnakov Version: 2.10.1pat OS: Windows XP Submission from: (NULL) (130.88.123.205) When calling programmatically function curve() from package:graphics I experienced some trouble since it reports stop("'expr' must be a function or an expression containing 'x'") even if expr is "expression". Naturally, the user message uses

Dear All, I have been trying to compile a package for windows that we have written. Since R version 3.0.0 the package doesn't compile any more. (On Linux the package compiles without errors). The error specifically says: gcc -m32 -I"C:/PROGRA~1/R/R-30~1.0/include" -DNDEBUG -I"d:/RCompile/CRANpkg/extralibs64/local/include" -O3 -Wall -std=gnu99 -mtune=core2 -c

Hi, Function Null from package MASS seems to return a matrix with zero columns and the expected number of rows when the null space of the argument contains only the zero vector, e.g. > library(MASS) > diag(nrow=3) [,1] [,2] [,3] [1,] 1 0 0 [2,] 0 1 0 [3,] 0 0 1 > Null(diag(nrow=3)) [1,] [2,] [3,] But the documentation of Null seems to imply that

Recent changes in R-devel seem to change the HTML rendering of text returned by Rd macros, in that now empty lines do not cause paragraphs to end (the empty lines are kept but <p> tags are not set). As a result, multiple paragraphs are output as a single one. A complete example Rd file is at: https://github.com/GeoBosh/reprexes/blob/master/disappearingParagraphs/a.Rd rendered (2018-10-28)

R's checks seem to be failing to notice a redundant '...' argument described in the documentation of a function. Consider a function: fun_3 <- function(arg1, arg2, arg3) { "I am fun_3" } If its documentation describes an argument, say 'dummy', R check reports something like: * checking Rd \usage sections ... WARNING Documented arguments not in \usage in

Oh, I completely missed that one. It's very neat as it seems to work both on Windows and Unix. Thanks! Xavier On 10/02/15 10:52, Martyn Plummer wrote: > The CRAN package snow is superseded by the parallel package which is > distributed with R since version 2.14.0. Here are the release notes > > \item There is a new package \pkg{parallel}. > > It incorporates (slightly

Hi, I am trying to compile C++ with R and I am coming up against - what I believe - is a linker configuration issue. For example, using has_develop() gives the following message... > has_devel() "C:/PROGRA~1/R/R-30~1.2/bin/i386/R" --vanilla CMD SHLIB foo.c gcc -m32 -I"C:/PROGRA~1/R/R-30~1.2/include" -DNDEBUG -I"d:/RCompile/CRANpkg/extralibs64/local/include"