[Rd] Programming Tools CTV

2015-01-23 Thread Willem Ligtenberg
Hi all, Sorry if this doesn't end up in the thread. Tobias Verbeke forwarded that e-mail to me, because he thought I would be interested in maintaining the Programming Tools CTV. I wasn't subscribed to R-devel yet, but I would indeed like to volunteer to maintain the Programming Tools CTV. It

Re: [Rd] Programming Tools CTV

2015-01-23 Thread Luca Braglia
Hi Willem thanks for volounteering. To the best of my knowledge (regarding the machinery side), if you're planning to use github (and maybe even if you don't) you can "stole" ideas from https://github.com/ropensci/webservices https://github.com/lbraglia/PackageDevelopmentTaskView (minor modifica

Re: [Rd] Programming Tools CTV

2015-01-23 Thread Luca Braglia
... BTW you should install the ctv package and read the vignette at first :) ... 2015-01-23 12:49 GMT+01:00 Luca Braglia : > Hi Willem > > thanks for volounteering. > > To the best of my knowledge (regarding the machinery side), if you're > planning to use github (and maybe even if you don't) you

Re: [Rd] Programming Tools CTV

2015-01-23 Thread Christophe Dutang
Dear Willem, Personally, I use the R-forge project for the distribution CTV : https://r-forge.r-project.org/projects/ctv/ It’s an alternative option to github. Regards, Christophe --- Christophe Dutang LMM, UdM, Le Mans, France web: http://dutangc.free.fr Le

Re: [Rd] Programming Tools CTV

2015-01-23 Thread Michael Dewey
Dear Willem I maintain the MetaAnalysis CTV. I have found it quite practicable to do this without special tools. I use an editor for the XML. I use CRANberries to catch updates and I usually email people to check I have understood a new package. People also kindly email me occasionally with n

Re: [Rd] Programming Tools CTV

2015-01-23 Thread Hadley Wickham
I'd strongly second the notion of using github. The biggest advantage is that others can easily contribute changes through pull requests which lifts much of the burden from your shoulders. Hadley On Fri, Jan 23, 2015 at 3:49 AM, Luca Braglia wrote: > Hi Willem > > thanks for volounteering. > > T

Re: [Rd] Programming Tools CTV

2015-01-23 Thread Achim Zeileis
Willem, thanks for volunteering! Sorry if this doesn't end up in the thread. Tobias Verbeke forwarded that e-mail to me, because he thought I would be interested in maintaining the Programming Tools CTV. I wasn't subscribed to R-devel yet, but I would indeed like to volunteer to maintain the

Re: [Rd] :: and ::: as .Primitives?

2015-01-23 Thread luke-tierney
On Thu, 22 Jan 2015, Henrik Bengtsson wrote: On Thu, Jan 22, 2015 at 11:44 AM, wrote: I'm not convinced that how to make :: faster is the right question. If you are finding foo::bar being called often enough to matter to your overall performance then to me the question is: why are you calling

Re: [Rd] :: and ::: as .Primitives?

2015-01-23 Thread luke-tierney
On Thu, 22 Jan 2015, Michael Lawrence wrote: On Thu, Jan 22, 2015 at 11:44 AM, wrote: For default methods there ought to be a way to create those so the default method is computed at creation or load time and stored in an environment. We had considered that, but we thought the definition o

Re: [Rd] speedbump in library

2015-01-23 Thread Winston Chang
I think you can simplify a little by replacing this: pkg %in% loadedNamespaces() with this: .getNamespace(pkg) Whereas getNamespace(pkg) will load the package if it's not already loaded, calling .getNamespace(pkg) (note the leading dot) won't load the package. I can't speak to whether there a

Re: [Rd] speedbump in library

2015-01-23 Thread Peter Haverty
Thanks Winston, Yes, your version of that part is more direct. I guess it would need a ! is.null() too. I think we should use .getNamespace. It It also occurred to me that this %in% check (which happens in a few places) is kind of roundabout. It equates to "foo" %in% ls(.Internal(getNamespaceReg

Re: [Rd] :: and ::: as .Primitives?

2015-01-23 Thread Philippe GROSJEAN
I tend to use this (in my own internal code *only*): exported <- function (pkg) { if (pkg == "base") { function (fun) { fun <- as.character(substitute(fun)) res <- .BaseNamespaceEnv[[fun]] if (is.null(r

Re: [Rd] Programming Tools CTV

2015-01-23 Thread Dirk Eddelbuettel
On 23 January 2015 at 05:55, Hadley Wickham wrote: | I'd strongly second the notion of using github. The biggest advantage | is that others can easily contribute changes through pull requests | which lifts much of the burden from your shoulders. That's "The Theory". "The Practice" for eight week

Re: [Rd] :: and ::: as .Primitives?

2015-01-23 Thread Hervé Pagès
Hi, On 01/23/2015 07:01 AM, luke-tier...@uiowa.edu wrote: On Thu, 22 Jan 2015, Michael Lawrence wrote: On Thu, Jan 22, 2015 at 11:44 AM, wrote: For default methods there ought to be a way to create those so the default method is computed at creation or load time and stored in an environmen

[Rd] issue with update.packages()

2015-01-23 Thread Dan Tenenbaum
Hello, I see the following issue in R-devel since 'both' has become the default pkgType for binary platforms. update.packages() fails when you set options(repos). Looks like it is trying to download a tgz file from the src/contrib section of a repository (on a mac). To reproduce this you need

Re: [Rd] :: and ::: as .Primitives?

2015-01-23 Thread Duncan Murdoch
On 22/01/2015 4:06 PM, Peter Haverty wrote: > Hi all, > > I use Luke's "::" hoisting trick often. I think it would be fantastic > if the JIT just did that for you. > > The main trouble, for me, is in code I don't own. When common > Bioconductor packages are loaded many, many base functions are s

Re: [Rd] :: and ::: as .Primitives?

2015-01-23 Thread Michael Lawrence
On Fri, Jan 23, 2015 at 10:11 AM, Hervé Pagès wrote: > Hi, > > On 01/23/2015 07:01 AM, luke-tier...@uiowa.edu wrote: >> >> On Thu, 22 Jan 2015, Michael Lawrence wrote: >> >>> On Thu, Jan 22, 2015 at 11:44 AM, wrote: For default methods there ought to be a way to create those so th