R devel - May 2020 - Testing before release (was: 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

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

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.
>
> Dirk
This 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.

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