similar to: options(keep.source = TRUE) -- also for "library(.)" ?

> Subject: Re: [Rd] options(keep.source = TRUE) -- also for "library(.)" ? > From: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> > Date: 27 Apr 2000 14:37:01 +0200 > > Martin Maechler <maechler@stat.math.ethz.ch> writes: > > > Can we [those of us who know how sys.source() works...] > > think of changing this? As it was possible for the base

>>>>> Sebastian Meyer >>>>> on Fri, 15 May 2020 10:47:55 +0200 writes: > I can confirm this changed behaviour. I just compared R-3.6.3 with > yesterday's R-devel. Using R-devel, the tempfile opened by the editor > (Emacs for me, but shouldn't matter) contains doubled backslashes. > This could be related to >

This perhaps diverges from the intent of the thread, but... I wanted to say I'm extremely grateful to the people who go the through the bug reports. It's an extremely important job (in the long run, particularly), but perhaps not quite as "sexy"-sounding as other roles, and probably under-valued. So, thank you to the bug-fixers... :) On Sat, May 16, 2020 at 2:54 AM Duncan

> On Friday, May 15, 2020, 12:13:04 PM EDT, Dirk Eddelbuettel <edd at debian.org> wrote: > On 15 May 2020 at 15:41, Martin Maechler wrote: > | <whining> > | > |??? Why does nobody anymore? help R development by working with > |??? "R-devel", or at least then the alpha, beta and the "RC" > |??? (Release Candidate) versions that we release daily

On 15 May 2020 at 15:41, Martin Maechler wrote: | <whining> | | Why does nobody anymore help R development by working with | "R-devel", or at least then the alpha, beta and the "RC" | (Release Candidate) versions that we release daily for about one | month before the final release? | | Notably a highly staffed enterprise such as Rstudio (viz the bug

On 15/05/2020 9:41 a.m., Martin Maechler wrote: [ deletions ] > <whining> > > Why does nobody anymore help R development by working with > "R-devel", or at least then the alpha, beta and the "RC" > (Release Candidate) versions that we release daily for about one > month before the final release? > > Notably a highly

Actually, it's not that hard to set up for a source compile for MacOS. The hard part is to do it precisely like the CRAN binaries so that you can run binary packages off CRAN, but in other setups you can just build packages from source. A stone in the shoe has been that the documentation on mac.r-project.org was littered with out-of-date information, but it seems that Simon has now cleaned

Dear all, When I use the cacheSweave package together with the Sweave option keep.source = TRUE, all the LaTeX code before the Sweave code chunk is included in the TeX file to be compiled. For example, with the following Sweave file \documentclass[12pt]{article} \usepackage[nogin]{Sweave} % Sweave options \SweaveOpts{keep.source=TRUE, strip.white=TRUE, eps=FALSE, pdf=TRUE} \begin{document}

Currently sub(perl=TRUE) allows you to specify \U and \L in the replacement argument so that the rest of the subpatterns in the line (the \\<digit> things) will be converted to upper or lower case, respectively. perl also also has a \E operator to end these case conversions for the rest of the subpatterns (so they retain whatever case they had in the original text). For symmetry's sake

In some contexts, I find the current behavior of rank() very `suboptimal'. We have the argument na.last = {TRUE | FALSE | NA } where the first two cases treating NAs (almost) as if they were == +Inf or == -Inf whereas the 3rd case just drops NAs. For the typical ``Rank Transformation'' that is recommended in EDA in several contexts, I would however want something else, namely keep

This is not only bug report, but also a RFC (request for comments): The basic problem is that there are (at least) two ways of easily getting non-factor character columns in data.frames. The first is read.table(*, as.is = TRUE) and the second is data.frame(.., I(...), ..) which differ in their result. Whereas the first produces `pure' character columns in the data.frame,

This could well be a package-specific issue, and so perhaps not for R-devel. The author of the relevant package is CC'd in any event. I'm seeing some odd behavior from Sweave with keep.source=TRUE when using driver=cacheSweaveDriver from the cacheSweave package. It would seem that code chunks with keep.source=TRUE aren't being parsed correctly; the corresponding Schunk starts at

I can confirm this changed behaviour. I just compared R-3.6.3 with yesterday's R-devel. Using R-devel, the tempfile opened by the editor (Emacs for me, but shouldn't matter) contains doubled backslashes. This could be related to https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17800 Best regards, Sebastian Am 15.05.20 um 03:50 schrieb William Dunlap via R-devel: > Is it just

Is it just my installation or does edit() (or fix(), etc.) in R-4.0.0 double all the backslashes when options(keep.source=TRUE)? E.g., > options(keep.source=TRUE) > f <- function(x) { cat("\t", x, "\n", sep="") } > edit(f) # exit the editor without making any changes The editor (vi or notepad) shows doubled backslashes function(x) {

I'd like to have this to be used in, e.g., demo() and example(). Currently, source() parse()s the entire file and then evaluates expression by expression. ``Of course'', parse() already loses the comments. An (much slower) alternative might be to the readLine() the file, echo what we read, and try to parse() ``the current chunk''. when parse() fails (when the current

I think Herv?'s idea was just that if switch can evaluate arguments selectively, so can stopifnot(). But switch() is .Primitive, so does it from C. I think it is almost a no-brainer to implement a sequential stopifnot if dropping to C code is allowed. In R it gets trickier, but how about this: Stopifnot <- function(...) { n <- length(match.call()) - 1 for (i in 1:n) { nm

Hello I am trying to wrap some C++ classes into R. (1) Comparing the OOP and methods packages, I have came to this conclusion that OOP works much better for this wrapper -- please correct me if I am wrong. One question is why this useful package (OOP) is not included in the official release of R? (2) Choosing the OOP package way, I have carried out the following steps to wrap the C++

The bottomline here is that one can always call a base method, inexpensively and without modifying the object, in, let's say, *formal* OOP languages. In R, this is not possible in general. It would be possible if there was always a foo.default, but primitives use internal dispatch. I was wondering whether it would be possible to provide a super(x, n) function which simply causes the

Dear all, I have trouble with R-beta sweaving files that include definitions with \SweaveInput in combination with keep.source = TRUE Symptom: SInput is taken from too far down the input file (the shift is the number of lines of the included file). Is that known? Searching didn't turn up anything, yet I think there are more people than just me using keep.source. Example: $

Martin Maechler wrote: > More generally, please, please, everyone : > > Replace > if (something == TRUE) > with if (something) > and > if (something.or.other == FALSE) > with if (!something.or.other) Amen! And right on! And you tell 'em! And a few other exclamations, several of which are not suitable for a family program. That sort of syntax,