Re: [Rd] Is using devtools::release no longer allowed?
On Tue, 19 Aug 2014, Duncan Murdoch wrote: If you use this, make sure you test it well enough to get it perfect the very first time you use it. If I were a CRAN administrator and received a series of bad submissions from someone who was working out the bugs, I would not find it difficult either technically or morally to permanently ban that user from ever submitting anything again. I think what Duncan is saying here is to make sure to log in as Dirk before testing your potentially buggy CRAN webform submitter. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question: Publishing R/S objects with WebServices (SOAP/WSDL)
So far I see many packages that allow R to consume WebServices, but I haven't seen anything that allows you to publish a package as a WebService. If you haven't already, look at the RWebServices package from Bioconductor. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.1.0: 'R CMD Sweave' deletes non tex files created upon batch mode exit
On Tue, 15 Apr 2014, peter dalgaard wrote: I'd say that that cat is out of the bag. There are probably umpteen documents around suggesting "R CMD Sweave". As people use Sweave only sporadically, it could take years before the old usage got stamped out. And anyways, the command format is the obvious way to generate documents in scripts and makefiles, isn't it? A majority of my Sweave building is done by R CMD Sweave, I just infrequently build Sweave documents. I've started transitioning to RStudio for this but only in certain situations. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The case for freezing CRAN
On Thu, 20 Mar 2014, Dirk Eddelbuettel wrote: o Roger correctly notes that R scripts and packages are just one issue. Compilers, libraries and the OS matter. To me, the natural approach these days would be to think of something based on Docker or Vagrant or (if you must, VirtualBox). The newer alternatives make snapshotting very cheap (eg by using Linux LXC). That approach reproduces a full environemnt as best as we can while still ignoring the hardware layer (and some readers may recall the infamous Pentium bug of two decades ago). At one of my previous jobs we did effectively this (albeit in a lower tech fashion). Every project had its own environment, complete with the exact snapshot of R & packages used, etc. All scripts/code was kept in that environment in a versioned fashion such that at any point one could go to any stage of development of that paper/project's analysis and reproduce it exactly. It was hugely inefficient in terms of storage, but it solved the problem we're discussing here. As you note, with the tools available today it'd be trivial to distribute that environment for people to reproduce results. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [RFC] A case for freezing CRAN
using the identical version of each CRAN package. The bioconductor project uses similar policies. While I agree that this can be an issue, I don't think it is fair to compare CRAN to BioC. Unless things have changed, the latter has a more rigorous barrier to entry which includes buy in of various ideals (e.g. interoperability w/ other BioC packages, making use of BioC constructs, the official release cycle). All of that requires extra management overhead (read: human effort) which considering that CRAN isn't exactly swimming in spare cycles seems unlikely to happen. It seems like one could set up a curated CRAN-a-like quite easily, advertise the heck out of it and let the "market" decide. That is, IMO, the beauty of open source. -J __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] libR.so: cannot open shared object file
Can you add some details? Suppose i have the package Model.tar.gz and my writable are is in user/area, what i have to do next to install the package? What I was picturing was something like this (forgive me if syntax isn't 100%): mkdir user/area/myRLib R CMD INSTALL --library=user/area/myRLib Model.tar.gz and then in R: library(Model, lib.loc="user/area/myRLib") Note though Brian Ripley's response to me where he indicates that this is handled automatically. -J __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] libR.so: cannot open shared object file
One problem is that i have not the privileges to install a package. If you have a writable area you can install to there with the --library=LIB argument and then load the package using the lib.loc command. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Minimum requirements for package submission
On Wed, 28 Aug 2013, Ben Bolker wrote: It may be suboptimal/there may be better ways, but what I would do in your situation would be to save the real twitteR results to a .Rdata file (e.g. put it in inst/vignetteData) and then 'fake' the twitter call: add a non-eval'd but echo'd chunk that appears to run the command, and an eval'd but non-echo'd chunk that loads the results of having run the command. Interesting, I'll look into doing that. Thanks -J __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Minimum requirements for package submission
On Wed, 28 Aug 2013, Dirk Eddelbuettel wrote: The change to preferring vignettes/ over inst/doc/ is just one of many; there is also an ongoing preference for vignettes that fully reproducible from source. Which may eventually put an end to non-Rnw / non-(la)tex vignettes. I'm currently stymied by this. I was one who did the stub-Rnw trick previously - it would be unwise for the vignette for twitteR to be run truly dynamically as it requires someone's real credentials to process. Not a problem, I run it by hand before submitting and then use the stub .Rnw for the vignette metadata to get picked up by CRAN. With the move to vignettes/ over inst/doc, that hasn't worked. doh! Aside: If someone knows of a way to get a non-autogenerated documentation file linked on a package's CRAN page (other than URL, which is a possibility) I'd love to hear ideas. -J __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extending suggestion for stopifnot
first, I think it would be more useful if it had an optional character string, so users could write stopifnot( is.matrix(m), "m is not a matrix" ) stop() allows for arbitrary strings __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [BioC] enabling reproducible research & R package management & install.package.version & BiocLite
On Tue, 5 Mar 2013, Cook, Malcolm wrote: Thus, I might rather consider an approach that at 'publish' time tarzips up a copy of the R package dependencies based on a config file defined from sessionInfo and caches it in the project directory. If you had a separate environment for every project, each with its own R installation and R installation lib.loc this becomes rather easy. For instance, something like this: myProject/ projectRInstallation/ bin/ R library/ Biobase annotate . projectData/ projectCode/ projectOutput/ The directory structure would likely be more complicated than that but something along those lines. This way all code, data *and* compute environment are always linked together. -J __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: 'igraph' package update and backward compatibility
On Thu, 20 Oct 2011, Hadley Wickham wrote: The optimal solution would be if R packages could depend on a specific version of a package, and a user could have multiple packages You used to be able to have a versioned install of a package, and then load a particular version. Not sure when it was removed. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readRDS and saveRDS
On Tue, 18 Oct 2011, Hadley Wickham wrote: * read.csv and write.csv * load and save * readRDS and saveRDS Even loadRDS/saveRDS or readRDS/writeRDS would be better than the current combo. You could change the CSV functions to readCSV and writeCSV :) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Reference Classes: Accessing methods via [[...]], bug?
On Sun, 1 May 2011, Martin Morgan wrote: On 05/01/2011 03:09 PM, John Chambers wrote: It would be interesting to get some experience and opinions on whether this is a good idea or not. It breaks encapsulation, in that the behavior of the class can no longer be inferred from the class definition alone. On the other hand, it is convenient and relates to "operator overloading" in some other languages. I have written 'show' methods for reference classes (is there another way to pretty-print them?) and S4 methods that dispatch to reference methods (in particular, yield(x) on connection-like classes dispatching to x$yield()). Most of my S4 method usage with reference classes has been the 'show' methods for the same reason that Martin states - I was unable to find another mechanism of pretty printing, and wanted something along those lines for situations such as a list of objects and how that gets rendered on the screen. I've also made use of S4 methods for reference classes to help maintain backwards compatibility for cases where I've changed the underlying implementation from S4 to using reference classes - in those cases the ability to use S4 methods was handy but not strictly necessary. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Conditional "Suggests"
On Tue, 12 Apr 2011, Friedrich Leisch wrote: That is not the case, the checks will only get a NOTE that PkgB doesn't exist. E.g., my package flexclust suggests multicore, which is not available for windows. Still both live happily on CRAN, and of course there is a windows version of flexclust available from CRAN. Right, there's a big mea culpa on my part here - Uwe managed to wake me up to my own idiocy. Obviously I had a case where PkgA Suggests PkgB and PkgB didn't exist for Windows. When I saw that PkgA failed to install on Windows, I always quickly assumed that was the case, but there was another goofy linkage between the two packages that I didn't intend to be there. PkgA fails to install in the absense of PkgB no matter what the platform. Considering that my use case for this has been debunked and it's the only valid one I can think of, I'll shut up now :) Thanks -J __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Conditional "Suggests"
On Mon, 11 Apr 2011, Hadley Wickham wrote: To me this reads as being in the wheelhouse of what 'Suggests' is supposed to imply, as per the R Extensions manual. The problem here is that if PkgB is put down as 'Suggests', it is required for R CMD check to pass which seems to defeat the purpose of this exercise a bit. No, because R CMD check is only run by the developer, not the user. It's not only run by the developer, it's also run by CRAN. The situation might happen where for a particular platform (e.g. Windows) that PkgB doesn't exist. It'd be nice to be able to avoid a situation where PkgA can't exist for that platform simply because PkgB - which isn't even necessarily required for PkgA to be used - doesn't exist for it. -J __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Conditional "Suggests"
Hi ... I came across an old post on R-devel that describes a situation very similar to one I find myself in: https://stat.ethz.ch/pipermail/r-devel/2006-December/043917.html As you can see in Gregor's example, the situation is that if I am writing Pkg A, I want to detect if Pkg B exists - if so use some functionality from there, otherwise do something else. To me this reads as being in the wheelhouse of what 'Suggests' is supposed to imply, as per the R Extensions manual. The problem here is that if PkgB is put down as 'Suggests', it is required for R CMD check to pass which seems to defeat the purpose of this exercise a bit. If one puts it as 'Enhances' one gets a NOTE earlier in check but then the WARNING described in this post due to the require() call. Is there a good way around this situation, such that the PkgA can pass a R CMD check if PkgB doesn't exist on the system, for instance a case where PkgB isn't available for a particular OS? If there are multiple methods around this problem, is one more blessed by the powers that be than others? Thanks -J __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Request: Suggestions for "good teaching" packages, esp. with C code
f1 <- function(){
a=5
}
The primary difference is that function 1 uses an incorrect assignment
operator in an attempt to cause confusion ;)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Request: Suggestions for "good teaching" packages, esp. with C code
On Wed, 16 Feb 2011, David Scott wrote: 4. We don't want gratuitous use of "return" at the end of functions. Why do people still do that? Well I for one (and Jeff as well it seems) think it is good programming practice. It makes explicit what is being returned eliminating the possibility of mistakes and provides clarity for anyone reading the code. You're unnecessarily adding the overhead of a function call by explicitly calling return(). Sure it seems odd for someone coming from the C/C++/Java/etc world, but anyone familiar with R should find code that doesn't have an explicit return() call to be fully readable & clear. -J __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
