Re: [Rd] Best practices in developing package: From a single file

>> There is package.skeleton() in base R as you already mentioned. It drove >> me >> bonkers that it creates packages which then fail R CMD check, so I wrote a >> wrapper package (pkgKitten) with another helper function (kitten()) which >> calls the base R helper and then cleans up it---but

Re: [Rd] Best practices in developing package: From a single file

On Tue, Jan 30, 2018 at 4:55 PM, Duncan Murdoch wrote: > On 30/01/2018 4:30 PM, Kenny Bell wrote: >> >> In response to Duncan regarding the use of roxygen2 from the point of view >> of a current user, I believe the issue he brings up is one of correlation >> rather than

Re: [Bioc-devel] updating Bioconductor package that is already on Github

Sure! This is for the MultiMed package, not swfdr, so I made that change below: ~\Documents\GitHub\MultiMed [master ≡]> git remote -v origin https://github.com/SiminaB/MultiMed.git (fetch) origin https://github.com/SiminaB/MultiMed.git (push) upstream

Re: [Bioc-devel] updating Bioconductor package that is already on Github

Yes, that is the key we have. Please send me more information,( output of these commands) git remote -v ssh -T g...@git.bioconductor.org | grep swfdr You might want to make sure you are using correct private key by setting up a config file in your SSH.

Re: [Bioc-devel] updating Bioconductor package that is already on Github

Hi Nitesh, I submitted this key as well a couple of days ago: ssh-rsa B3NzaC1yc2EDAQABAAACAQDP91Ifm9VtF76jYs4gPwJQx0nU3LBV rsWwX4Eba1SOIHlHiXb45RHFZ0tvwV4yMNb9IXGAA3Kg0OnJs1YS1ddXTVkK zyXAk4nlyiwSSSBe8gxhS1wPX5c8Zv8n28T71/bn90z61RKwkZc+hAZjrK/2Xiw/

Re: [Rd] Best practices in developing package: From a single file

On 30/01/2018 4:12 PM, Dirk Eddelbuettel wrote: Mehmet, That is a loaded topic, not unlikely other topics preoccupying us these days. There is package.skeleton() in base R as you already mentioned. It drove me bonkers that it creates packages which then fail R CMD check, so I wrote a wrapper

Re: [Rd] Best practices in developing package: From a single file

On 30/01/2018 4:30 PM, Kenny Bell wrote: In response to Duncan regarding the use of roxygen2 from the point of view of a current user, I believe the issue he brings up is one of correlation rather than causation. Could be. However, I think editing comments in a .R file is a bit harder than

Re: [Rd] as.list method for by Objects

I just meant that the minimal contract for as.list() appears to be that it returns a VECSXP. To the user, we might say that is.list() will always return TRUE. I'm not sure we can expect consistency across methods beyond that, nor is it feasible at this point to match the semantics of the methods

Re: [Rd] Why R should never move to git

Gabor, I was just pointing out options. I think it is more of a policy decision than a technical one. For example, the very mailing list we are using is run by ETH Zurich with Martin Maechler. But it can well be run on google groups. Maybe this list should also move to google groups, it is

Re: [Rd] Why R should never move to git

While this is a very hypothetical argument, you could at least explain _why_ you would think so. If you were thinking about the unlikely event of GitHub / GitLab closing business, that is _not_ such a big to any active project that is hosted there. Gabor On Tue, Jan 30, 2018 at 11:07 PM, Suzen,

Re: [Rd] Why R should never move to git

This might be off topic, but if R-core development ever moves to git, I think it would make sense to have its own git service hosted by a university, rather than using github or gitlab. It is possible via https://gogs.io/ project. Just for the record. Best, -m

Re: [Rd] Best practices in developing package: From a single file

On 30 January 2018 at 21:31, Cook, Malcolm wrote: > > I think you want to see the approach to generating a skeleton from a single > .R file presented in: > > Simple and sustainable R packaging using inlinedocs > http://inlinedocs.r-forge.r-project.org/ > > I have not

Re: [Rd] as.list method for by Objects

by() does not always return a list. In Gabe's example, it returns an integer, thus it is coerced to a list. as.list() means that it should be a VECSXP, not necessarily with "list" in the class attribute. Michael On Tue, Jan 30, 2018 at 2:41 PM, Hervé Pagès wrote: > Hi

Re: [Rd] as.list method for by Objects

Hi Gabe, Interestingly the behavior of as.list() on by objects seem to depend on the object itself: > b1 <- by(1:2, 1:2, identity) > class(as.list(b1)) [1] "list" > b2 <- by(warpbreaks[, 1:2], warpbreaks[,"tension"], summary) > class(as.list(b2)) [1] "by" This is with R 3.4.3 and R devel

Re: [Rd] as.list method for by Objects

Dario, What version of R are you using. In my mildly old 3.4.0 installation and in the version of Revel I have lying around (also mildly old...) I don't see the behavior I think you are describing > b = by(1:2, 1:2, identity) > class(as.list(b)) [1] "list" > sessionInfo() R Under

Re: [Rd] Best practices in developing package: From a single file

Dear All, Thank you for all valuable input and sorry for the off-topic for the list. I will try R-pkg-devel for further related questions. I was actually after "one-go" auto-documentation in-line or out of comments from a single file/environment in a similar spirit to 'package.skeleton or an

Re: [Rd] as.list method for by Objects

On 01/30/2018 02:24 PM, Hervé Pagès wrote: I agree that it makes sense to expect as.list() to perform a "strict coercion" i.e. to return an object of class "list", *even* on a list derivative. That's what as( , "list") does by default:   # on a data.frame object   as(data.frame(), "list")  #

Re: [Rd] as.list method for by Objects

I agree that it makes sense to expect as.list() to perform a "strict coercion" i.e. to return an object of class "list", *even* on a list derivative. That's what as( , "list") does by default: # on a data.frame object as(data.frame(), "list") # object of class "list"

Re: [Rd] Best practices in developing package: From a single file

In response to Duncan regarding the use of roxygen2 from the point of view of a current user, I believe the issue he brings up is one of correlation rather than causation. Writing my first piece of R documentation was made much easier by using roxygen2, and it shallowed the learning curve

Re: [Rd] sum() returns NA on a long *logical* vector when nb of TRUE values exceeds 2^31

Hi Martin, Henrik, Thanks for the follow up. @Martin: I vote for 2) without *any* hesitation :-) (and uniformity could be restored at some point in the future by having prod(), rowSums(), colSums(), and others align with the behavior of length() and sum()) Cheers, H. On 01/27/2018 03:06 AM,

[Rd] CRAN indices out of whack (for at least macOS)

I have received three distinct (non-)bug reports where someone claimed a recent package of mine was broken ... simply because the macOS binary was not there. Is there something wrong with the cronjob providing the indices? Why is it pointing people to binaries that do not exist? Concretely,

Re: [Rd] Best practices in developing package: From a single file

Mehmet, That is a loaded topic, not unlikely other topics preoccupying us these days. There is package.skeleton() in base R as you already mentioned. It drove me bonkers that it creates packages which then fail R CMD check, so I wrote a wrapper package (pkgKitten) with another helper function

Re: [Rd] Best practices in developing package: From a single file

On 30/01/2018 11:29 AM, Brian G. Peterson wrote: On Tue, 2018-01-30 at 17:00 +0100, Suzen, Mehmet wrote: Dear R developers, I am wondering what are the best practices for developing an R package. I am aware of Hadley Wickham's best practice documentation/book (http://r-pkgs.had.co.nz/).  I

Re: [Bioc-devel] Should GenomicFeatures really depend pn RMySQL ? Is it time to migrate to RMariaDB ?

This is done in GenomicFeatures 1.31.6. Note that I also made a few changes to makeTxDbFromUCSC() to make it a little bit faster (about 2x). @Kasper: moving the makeTxDb* functions to a GenomicFeaturesBuildTools or GenomicFeaturesForge package is maybe an idea to explore... H. On 01/26/2018

Re: [Rd] as.list method for by Objects

I agree that it would make sense for the object to have c("by", "list") as its class attribute, since the object is known to behave as a list. However, it would may be too disruptive to make this change at this point. Hard to predict. Michael On Mon, Jan 29, 2018 at 5:00 PM, Dario Strbenac

[Bioc-devel] cannot fetch upstream git

Hello,  I am having some issues pushing some changes to my package. I am following the steps here:Bioconductor - Sync existing repositories | | | | || | | | | | Bioconductor - Sync existing repositories | | | | And at step 3 I get the following:

Re: [Rd] Best practices in developing package: From a single file

On Tue, 2018-01-30 at 17:00 +0100, Suzen, Mehmet wrote: > Dear R developers, > > I am wondering what are the best practices for developing an R > package. I am aware of Hadley Wickham's best practice > documentation/book (http://r-pkgs.had.co.nz/).  I recall a couple of > years ago there were

[Rd] Best practices in developing package: From a single file

Dear R developers, I am wondering what are the best practices for developing an R package. I am aware of Hadley Wickham's best practice documentation/book (http://r-pkgs.had.co.nz/). I recall a couple of years ago there were some tools for generating a package out of a single file, such as using

Re: [Rd] withTimeout bug, it does not work properly with nlme anymore

> Ramiro Barrantes > on Mon, 27 Nov 2017 21:02:52 + writes: > Hello, I was relying on withTimeout (from R.utils) to help > me stop nlme when it �hangs�. However, recently this > stopped working. I am pasting a reproducible example >

[Rd] LCONS undefined for R_NO_REMAP

Rinternals.h has: #define CONS(a, b) cons((a), (b)) #define LCONS(a, b) lcons((a), (b)) However these are undefined when we compile with -DR_NO_REMAP. Maybe it's safer to define these using Rf_cons() and Rf_lcons() instead? __ R-devel@r-project.org