Recent and upcoming changes to R-devel
L.S.
On 07/05/2011 02:16 AM, Mark.Bravington at csiro.au wrote:
I may have misunderstood, but: Please could we have an optional installation that does not*not* byte-compile base and recommended? Reason: it's not possible to debug byte-compiled code-- at least not with the 'debug' package, which is quite widely used. I quite often end up using 'mtrace' on functions in base/recommended packages to figure out what they are doing. And sometimes I (and others) experiment with changing functions in base/recommended to improve functionality. That seems to be harder with BC versions, and might even be impossible, as best I can tell from hints in the documentation of 'compile'). Personally, if I had to choose only one, I'd rather live with the speed penalty from not byte-compiling. But of course, if both are available, I could install both.
I completely second this request. All speed improvements and the byte compiler in particular are leaps forward and I am very grateful and admiring towards the people that make this happen. That being said, 'moving away' from the sources (with the lazy loading files and byte-compilation) may be a step back for R package developers that (during development and maybe on separate development installations [as opposed to production installations of R]) require the sources of all packages to be efficient in their work. As many of you know there is an open source Eclipse/StatET visual debugger ready and for that application as well (similar to Mark's request) presence of non-compiled code is highly desirable. For the particular purpose of debugging R packages, I would even plead to go beyond the current options and support the addition of an R package install option that allows to include the sources (e.g. in a standard folder Rsrc/) in installed packages. I am fully aware that one can always fetch the source tarballs from CRAN for that purpose, but it would be much more easy if a simple installation option could put the R sources of a package in a separate folder [or archive inside an existing folder] such that R development tools (such as the Eclipse/StatET IDE) can offer inspection of sources or display them (e.g. during debugging) out of the box. If one has the srcref, one can always load the absolutely correct source code this way, even if one doesn't know the parent function with the source attribute. Any comments? Best, Tobias P.S. One could even consider a post-install option e.g. to add 'real' R sources (and source references) to Windows packages (which are by definition already 'installed' and for which such information is not by default included in the CRAN binaries of these packages).
Prof Brian Ripley wrote: There was an R-core meeting the week before last, and various planned changes will appear in R-devel over the next few weeks. These are changes planned for R 2.14.0 scheduled for Oct 31. As we are sick of people referring to R-devel as '2.14' or '2.14.0', that version number will not be used until we reach 2.14.0 alpha. You will be able to have a package depend on an svn version number when referring to R-devel rather than using R (>= 2.14.0). All packages are installed with lazy-loading (there were 72 CRAN packages and 8 BioC packages which opted out). This means that the code is always parsed at install time which inter alia simplifies the descriptions. R 2.13.1 RC warns on installation about packages which ask not to be lazy-loaded, and R-devel ignores such requests (with a warning). In the near future all packages will have a name space. If the sources do not contain one, a default NAMESPACE file will be added. This again will simplify the descriptions and also a lot of internal code. Maintainers of packages without name spaces (currently 42% of CRAN) are encouraged to add one themselves. R-devel is installed with the base and recommended packages byte-compiled (the equivalent of 'make bytecode' in R 2.13.x, but done less inefficiently). There is a new option R CMD INSTALL --byte-compile to byte-compile contributed packages, but that remains optional. Byte-compilation is quite expensive (so you definitely want to do it at install time, which requires lazy-loading), and relatively few packages benefit appreciably from byte-compilation. A larger number of packages benefit from byte-compilation of R itself: for example AER runs its checks 10% faster. The byte-compiler technology is thanks to Luke Tierney. There is support for figures in Rd files: currently with a first-pass implementation (thanks to Duncan Murdoch).
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel