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

Excellent, thank you so much, it worked now! I had specified the package name but perhaps should have started another email thread. What was the issue though, was it the public key or was there something that needed to be changed on your end? (Trying to remember for the next time) Cheers, Simina

Re: [Bioc-devel] BiocParallel: windows vs. mac/linux behavior

On 01/31/2018 06:39 PM, Ludwig Geistlinger wrote: Hi, I am currently considering the following snippet: data.ids <- paste0("d", 1:5) f <- function(x) paste("dataset", x, sep=" = ") res <- BiocParallel::bplapply(data.ids, function(d) f(d)) Using a recent R-devel on both a Linux machine

[Bioc-devel] BiocParallel: windows vs. mac/linux behavior

Hi, I am currently considering the following snippet: > data.ids <- paste0("d", 1:5) > f <- function(x) paste("dataset", x, sep=" = ") > res <- BiocParallel::bplapply(data.ids, function(d) f(d)) Using a recent R-devel on both a Linux machine and a Mac machine, this works fine. However, on

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

On 31/01/2018 8:59 AM, Mark van der Loo wrote: I fully agree with Joris and Hadley on roxygen2. Additionally: I wrote and published my first package before roxygen (or roxygen2) was available. I found editing .Rd extremely terse (especially when code is updated). For example, the fact that

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

Dirk, yes, thanks, the edge server that serves the Mac binaries to CRAN has run out of disk space (due to size of CRAN itself) so the sync was incomplete. It is fixed now -- you can try by using the macos master server as mirror: https://r.research.att.com/ and it will propagate through other

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

Bumping this as we now have two more issue tickets filed and a fresh SO question. Is anybody looking at this? Simon? Dirk On 30 January 2018 at 15:19, Dirk Eddelbuettel wrote: | | I have received three distinct (non-)bug reports where someone claimed a | recent package of mine was broken ...

Re: [Bioc-devel] Duplicate Commits in ASSIGN Package

Should be all fixed now. Best, Nitesh > On Jan 31, 2018, at 12:31 PM, Jenkins, David wrote: > > Sorry about that, the RELEASE_3_6 branch on our github should be fixed now: > https://github.com/compbiomed/ASSIGN/commits/RELEASE_3_6 > > Thanks, > > David > > On 1/31/18, 12:00

Re: [Bioc-devel] Duplicate Commits in ASSIGN Package

Sorry about that, the RELEASE_3_6 branch on our github should be fixed now: https://github.com/compbiomed/ASSIGN/commits/RELEASE_3_6 Thanks, David On 1/31/18, 12:00 PM, "Turaga, Nitesh" wrote: Hi David, Your master branch is fine now. I have

Re: [Bioc-devel] Duplicate Commits in ASSIGN Package

Hi David, Your master branch is fine now. I have updated bioconductor to reflect your master branch. But you need to do the same thing to RELEASE_3_6 as well. There are duplicate commits on that branch. Please let me know once you have fixed your RELEASE_3_6. Best, Nitesh > On Jan 31,

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

Joris, With the large caveat that I am not Duncan, and thus am not speaking for him, I can see an argument for his claim that I think is, more or less, true. roxygen2 (as far as I know as someone who uses it at least some of the time) maps to only a subset of Rd. It is the most commonly used

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

On 31 January 2018 at 16:18, Barry Rowlingson wrote: >> > > Let the record also state that *gitlab* is an open source project and can be > downloaded and self-hosted, like gogs, but unlike github. Good to know. Nice one: https://github.com/gitlabhq/gitlabhq Best,

Re: [Bioc-devel] cannot fetch upstream git

Bruno, It looks like some content in your message did not come through - please re-send. We need to see the commands you are running, specifically what package you're trying to access. Valerie On 01/30/2018 09:56 AM, bruno contrino via Bioc-devel wrote: Hello, I am having some issues

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

Dear Dr. Pfaff, Thank you for this, creating a package out of single file was my oriingal question, but not only creating and also maintaining it that way so R package is an artifact of the development process rather than "manually maintained" structure. I will have look at your sources. Best,

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

I pretty much agree. I tried using roxygen when it was first released but couldn't stand putting documentation in comments, especially for complex, S4-based software. Rd is easy to read and write and lets me focus on the task of writing documentation (focus is the hardest part of any task for me).

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

Similarly, I created this example a couple of years ago: https://github.com/yihui/rlp which shows that you can create a package from R Markdown documents (or any documents that knitr supports). Basically you can start with an R Markdown document, and after clicking a button in RStudio, you will

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

On Tue, Jan 30, 2018 at 11:07 PM, Suzen, Mehmet wrote: > 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

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

Dear All: stepping in late, but @Joris, if you would like to take 'from a single file' literally, have a look at: https://github.com/bpfaff/lp4rp (lp4rp: literate programming for R packages); Cheers, Bernhard ps: incidentally, within the noweb-file roxygen is employed.

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

I fully agree with Joris and Hadley on roxygen2. Additionally: I wrote and published my first package before roxygen (or roxygen2) was available. I found editing .Rd extremely terse (especially when code is updated). For example, the fact that there are no spaces allowed between } and { in

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

Hi Simina, You should have access now. The missing information in all the previous communications was the name of the package you were trying to access. Nitesh > On Jan 30, 2018, at 10:51 PM, Simina Boca wrote: > > Sure! This is for the MultiMed package, not swfdr, so I

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

On Wed, Jan 31, 2018 at 1:41 PM, Duncan Murdoch wrote: > On 31/01/2018 6:33 AM, Joris Meys wrote: > > 3. given your criticism, I'd like your opinion on where I can improve the >> documentation of https://github.com/CenterForStatistics-UGent/pim. I'm >> currently busy

[Bioc-devel] Alpha release of the iSEE visualization tool

Dear list, At the European Bioconductor Meeting in December 2017, a group of us decided to develop a common interface for interactive visualization of single-cell ‘omics data. Two months (and over 500 commits) later, we are proud to present the alpha release of iSEE, a package for interactive

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

(Please do not quote without attribution) On 30 January 2018 at 20:44, Hadley Wickham wrote: | Personally, I think the biggest problem with package.skeleton() is | that it assumes that the source of truth is objects in an environment. | This seems the wrong way around to me. Basically

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

On 31/01/2018 6:33 AM, Joris Meys wrote: 3. given your criticism, I'd like your opinion on where I can improve the documentation of https://github.com/CenterForStatistics-UGent/pim. I'm currently busy updating the help files for a next release on CRAN, so your input is more than welcome.

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

On 31/01/2018 6:33 AM, Joris Meys wrote: Dear Duncan, With all respect, but I strongly disagree on your stance regarding roxygen2 for multiple reasons: 1. It is in my humble opinion not correct to evaluate a tool based on the abuse of some users. It's not because people write packages with

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

On 30/01/2018 11:39 PM, Hadley Wickham wrote: 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

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

Dear Duncan, With all respect, but I strongly disagree on your stance regarding roxygen2 for multiple reasons: 1. It is in my humble opinion not correct to evaluate a tool based on the abuse of some users. It's not because people write packages with bad documentation, that roxygen2 is to blame.