Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[Tomas Kalibera]

Thanks for reporting this, it is a bug, now fixed in R-devel and 
R-patched (PR#17800).


Best
Tomas

On 5/15/20 3:50 AM, William Dunlap via R-devel wrote:

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

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[peter dalgaard]

To discuss this further, we should probably move over to R-sig-mac and change 
the subject header.

-pd

> On 15 May 2020, at 19:26 , peter dalgaard  wrote:
> 
> Actually, it's not that hard to set up for a source compile for MacOS.

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[peter dalgaard]

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 
this up considerably. It should now be possible simply to follow instructions 
on http://mac.r-project.org/tools/. I'm sure Simon will be receptive to 
information if something doesn't quite work.

-pd

> On 15 May 2020, at 18:48 , brodie gaslam via R-devel  
> wrote:
> 
>> 
>> On Friday, May 15, 2020, 12:13:04 PM EDT, Dirk Eddelbuettel 
>>  wrote:
>> On 15 May 2020 at 15:41, Martin Maechler wrote:
>> | 
>> |
>> |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 ...
>> |
>> | 
>> 
>> 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.
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[Avraham Adler]

I build windows binaries from source. As of now, the only choice is R-revel
unless I want to monkey around more with Jeroens’s PKGBUILD script (which
is On my to-do list).

It’s pretty straightforward, although I’m seeing a lot of issues with
packages which had explicit calls to LOCALSOFT in configure.win as that
doesn’t exist anymore.

The binaries have passed make check, though. Would it help if I built some
and forwarded it somewhere?

Avi

On Fri, May 15, 2020 at 12:48 PM brodie gaslam via R-devel <
r-devel@r-project.org> wrote:

>
> > On Friday, May 15, 2020, 12:13:04 PM EDT, Dirk Eddelbuettel <
> e...@debian.org> wrote:
> > On 15 May 2020 at 15:41, Martin Maechler wrote:
> > | 
> > |
> > |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 ...
> > |
> > | 
> >
> > 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.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[Bemis, Kylie]

Nightly binary builds of R-devel for macOS are available: 
http://mac.r-project.org

~~~
Kylie Ariel Bemis (she/her)
Khoury College of Computer Sciences
Northeastern University
kuwisdelu.github.io










On May 15, 2020, at 12:48 PM, brodie gaslam via R-devel 
mailto:r-devel@r-project.org>> wrote:


On Friday, May 15, 2020, 12:13:04 PM EDT, Dirk Eddelbuettel 
mailto:e...@debian.org>> wrote:
On 15 May 2020 at 15:41, Martin Maechler wrote:
| 
|
|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 ...
|
| 

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.

__
R-devel@r-project.org mailing list
https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-develdata=02%7C01%7Ck.bemis%40northeastern.edu%7C66883f8d39094f87847608d7f8efd23e%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637251581223782724sdata=cVYbvv%2B2fqwKpMUCM6iBGu4wLOLQvQUwv4SOapZf5mM%3Dreserved=0


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[brodie gaslam via R-devel]

> On Friday, May 15, 2020, 12:13:04 PM EDT, Dirk Eddelbuettel  
> wrote:
> On 15 May 2020 at 15:41, Martin Maechler wrote:
> | 
> |
> |    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 ...
> |
> | 
>
> 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.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[Dirk Eddelbuettel]

On 15 May 2020 at 15:41, Martin Maechler wrote:
| 
| 
| 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 ...
| 
| 

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 | e...@debian.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[Martin Maechler]

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



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



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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[Sebastian Meyer]

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 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
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] edit() doubles backslashes when keep.source=TRUE

[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

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel