Rename .Rraw to just .R?

[MichaelChirico]

Is there any reason not to use the "normal" R extension on these files? I don't see anything that distinguishes them from other .R files. The disadvantages of .Rraw are (1) syntax highlighting is disabled by most software that would usually understand the .R extension and (2) new contributors may be confused about what's so special about these files that they get an unknown extension. I don't see any advantages.

[jangorecki]

It may be not good idea considering how big Rraw files are. From the perspective of requiring a lot resources for an IDE. RStudio could possibly try to figure out what packages are being used in the script to suggest to install missing ones.

[MichaelChirico]

After renaming we could also remove the .gitattributes file:

data.table/.gitattributes

Line 2 in 34e02f2

*.Rraw linguist-language=R

[MichaelChirico]

It may be not good idea considering how big Rraw files are. From the perspective of requiring a lot resources for an IDE. RStudio could possibly try to figure out what packages are being used in the script to suggest to install missing ones.

FWIW:

f = "inst/tests/tests.Rraw"
system.time(getParseData(parse(f)))
#    user  system elapsed 
#   0.237   0.000   0.238

system.time(xmlparsedata::xml_parse_data(parse(f)))
#    user  system elapsed 
#   3.779   0.004   3.792

system.time(lintr::get_source_expressions(f))
#    user  system elapsed 
#  28.767   0.264  29.056 

system.time(lintr::lint(f, lintr::missing_package_linter()))
#    user  system elapsed 
#  29.535   0.627  30.234 

i.e. {lintr} takes quite a while to run missing_package_linter() on the file, but most of that is consumed just getting a normalized cache-optimized data structure. After that the actual lint logic runs in <1 second. Pure R parse data of the file also takes .25s. So presumably RStudio could run such script in <1 second total.

[jangorecki]

I would also look for the initial reason why Rraw was used rather than R.

[TysonStanley]

It was changed back in 2011 648ea23 for "Name change tests.R to tests.Rraw to pass R CMD check on 64bit R 2.14.0 (using Amazon EC2)"

Seems related to testthat

Here's the comment

# As from v1.7.2, testthat doesn't run the tests.Rraw (hence file name change to .Rraw).
# There were environment issues with system.time() (when run by test_package) that only
# showed up when CRAN maintainers tested on 64bit. Matthew spent a long time including
# testing on 64bit in Amazon EC2. Solution was simply to not run the tests.R from
# testthat, which probably makes sense anyway to speed it up a bit (was running twice
# before).

[MichaelChirico]

Interesting, I never knew we once used {testthat}:

data.table/DESCRIPTION

Line 8 in 648ea23

Suggests: chron, ggplot2, plyr, testthat (>= 0.4), hexbin

It looks like that reason is no longer relevant then -- definitely comfortable with renaming.

[Nj221102]

Hey there! i want to solve this issue, and it seems like a straightforward fix – just switching up the file extensions from ".Rraw" to ".R". Here's the lineup of all those ".Rraw" files:

froll.Rraw 
tests.Rraw
other.Rraw 
types.Rraw 
nafill.Rraw 
benchmark.Rraw 
programming.Rraw

is there anything else to be done for this?

[MichaelChirico]

Thanks again Nitish! Here is another issue that will create a lot of merge conflicts with existing PRs, so it's on the back burner for now. I'll try and add milestone 1.17.0 to issues that need to wait for the current PR queue to clear a bit before addressing.

[Nj221102]

Thanks again Nitish! Here is another issue that will create a lot of merge conflicts with existing PRs, so it's on the back burner for now. I'll try and add milestone 1.17.0 to issues that need to wait for the current PR queue to clear a bit before addressing.

Thanks for info, i will work on something else for now :) , and if you don't mind can you please suggest some issue i can work on as a beginner , because right now i am trying to get familiar with codebase by solving issues.

[mfansler]

Might also be worth noting that .Rraw files get compressed (see #3933, #3937), so name changing might need to keep this in mind.