Repository navigation
Rename .Rraw to just .R? #5830
Description
Activity
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.
After renaming we could also remove the .gitattributes file:
Line 2 in 34e02f2
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.234i.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.I would also look for the initial reason why Rraw was used rather than R.
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).Interesting, I never knew we once used {testthat}:
Line 8 in 648ea23
It looks like that reason is no longer relevant then -- definitely comfortable with renaming.
Reacted by Jan Gorecki, Toby Dylan Hocking, Tyson Barrett and James LambHey 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.Rrawis there anything else to be done for this?
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 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.
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.