Martin Maechler
2020-May-15 13:41 UTC
[Rd] edit() doubles backslashes when keep.source=TRUE
>>>>> 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 > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17800 Yes, indeed, I'm sure this is the same; an inadvertent bug indeed. > Best regards, > Sebastian ... and "just the usual" <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 report 17800 above), but also others could really help by starting to use the "next version" of R on a routine basis ... <whining/> Still: Thank you, of course, Bill Dunlap, and Sebastian and Jonathan (PR 17800) Martin > Am 15.05.20 um 03:50 schrieb William Dunlap via R-devel: >> 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) { cat("\\t", x, "\\n", sep="") } >> as does the return value of edit(). >> >> If I set options(keep.source=FALSE) before defining 'f' or remove t's >> 'srcref' attribute then the backslashes are left alone. >> >> Bill Dunlap >> TIBCO Software >> wdunlap tibco.com
Duncan Murdoch
2020-May-15 14:53 UTC
[Rd] Testing before release (was: edit() doubles backslashes when keep.source=TRUE)
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 staffed enterprise such as Rstudio (viz the bug > report 17800 above), but also others could really help by > starting to use the "next version" of R on a routine basis ... > > <whining/I understand the whining, bugs that get released are embarrassing. But when I read the NEWS, I can see that both the NEW FEATURES and BUG FIXES sections of x.y.0 releases tend to be much longer than the BUG FIXES sections in patch releases. That seems to indicate that things are working reasonably well. For a really rough measure, just counting bullet points: R 4.0.0: 65 new features, 55 bug fixes R 3.6.3: 1 new feature, 7 bug fixes R 3.6.2: 2 new features, 21 bug fixes R 3.6.1: 0 new features, 16 bug fixes R 3.6.0: 72 new features, 62 bug fixes You can get these numbers programmatically: R4 <- news() table(R4$Category) R3 <- news(package = "R-3") table(R3$Version, R3$Category) Duncan Murdoch
Dirk Eddelbuettel
2020-May-15 16:12 UTC
[Rd] edit() doubles backslashes when keep.source=TRUE
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 | report 17800 above), but also others could really help by | starting to use the "next version" of R on a routine basis ... | | <whining/> Seconded. Without testing we can never know. R Core does their part. I provided weekly Debian binaries. One each for the two alphas releases, for the beta release, for the release candidate. It is easy to use these, for example in a Docker container. It is also easy to use this on a normal machine as they are standard (Debian) packages: install, try some tests, uninstall, revert to previous version by installing that. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
> 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 for about one > |??? month before the final release? > | > |??? Notably a highly staffed enterprise such as Rstudio (viz the bug > |??? report 17800 above), but also others could really help by > |??? starting to use the "next version" of R on a routine basis ... > | > | <whining/> > > Seconded. Without testing we can never know. R Core does their part. > > I provided weekly Debian binaries. One each for the two alphas releases, for > the beta release, for the release candidate.? It is easy to use these, for > example in a Docker container. > > It is also easy to use this on a normal machine as they are standard (Debian) > packages: install, try some tests, uninstall, revert to previous version by > installing that. > > DirkThis is a very reasonably request, and all useRs who benefit from the tireless work of R-core should consider doing it.? I have considered it, but compiling R from sources on OS X has been my stumbling block. At least last time I tried I got stuck at the? Fortran step. It doesn't help I have very limited experience compiling? software of the complexity of R.? Really, I've only done it within the warm welcoming confines of the vagrant image Tomas Kalibera set up for `rchk`. I also use r-devel on docker, but that isn't very practical for day-to-day usage, which is what I think we need. What would it take to generate pre-release binaries for OS X (and Windows)?? I imagine if such were available the volume of testers would increase dramatically (at least, I haven't seen them if they exist).? Maybe something the R Consortium would consider funding? Best, B.
Abby Spurdle
2020-May-15 22:08 UTC
[Rd] Testing before release (was: edit() doubles backslashes when keep.source=TRUE)
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 Murdoch <murdoch.duncan at gmail.com> wrote:> > 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 staffed enterprise such as Rstudio (viz the bug > > report 17800 above), but also others could really help by > > starting to use the "next version" of R on a routine basis ... > > > > <whining/ > I understand the whining, bugs that get released are embarrassing. But > when I read the NEWS, I can see that both the NEW FEATURES and BUG FIXES > sections of x.y.0 releases tend to be much longer than the BUG FIXES > sections in patch releases. That seems to indicate that things are > working reasonably well. > > For a really rough measure, just counting bullet points: > > R 4.0.0: 65 new features, 55 bug fixes > > R 3.6.3: 1 new feature, 7 bug fixes > > R 3.6.2: 2 new features, 21 bug fixes > > R 3.6.1: 0 new features, 16 bug fixes > > R 3.6.0: 72 new features, 62 bug fixes > > You can get these numbers programmatically: > > R4 <- news() > table(R4$Category) > > R3 <- news(package = "R-3") > table(R3$Version, R3$Category) > > Duncan Murdoch > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
Possibly Parallel Threads
- edit() doubles backslashes when keep.source=TRUE
- Testing before release (was: edit() doubles backslashes when keep.source=TRUE)
- edit() doubles backslashes when keep.source=TRUE
- edit() doubles backslashes when keep.source=TRUE
- edit() doubles backslashes when keep.source=TRUE