[Bioc-devel] Bioc_since shield broken for packages accepted <6 months ago

Hi All, I noticed that all packages accepted in Bioc 3.9 have their Bioc_since (year-in-bioc) broken. Following the svg link indicates a code error. Here is an example from our package https://bioconductor.org/shields/years-in-bioc/lipidr.svg. Hope this can be easily fixed. Cheers. Ahmed.

[Bioc-devel] Organizing committee for BioC2020

Dear Bioconductor Developer Community, The organizing committee for BioC2020, to be held in Boston on July 29-31, needs organizers to help in planning the event. Participation involves attending approximately monthly remote meetings plus taking on responsibilities in one or more of the areas

Re: [Bioc-devel] read_bed()

I'd suggest separating the operations on the data from the interface. You can have both, one layer for programming and another for interactive analysis. On Wed, Sep 18, 2019 at 5:05 AM Bhagwat, Aditya wrote: > > In the end I endeavour to end up with a handful of verbs, with which I can do > all

Re: [Bioc-devel] read_bed()

In the end I endeavour to end up with a handful of verbs, with which I can do all tasks in a project. Regarding the BED files: they're basic bed files, with additional metadata columns to allow traceback. But for the purpose of multicrispr, non need to restrict to those files only. You extraCol

Re: [Bioc-devel] read_bed()

Hi Michael, That's a software design dilemma I've encountered a few times. One approach is to keep the "verb" functions bare. E.g. read_bed would only read a bedfile, and plot_bed would somehow plot it. Advantage: if read_bed doesn't depend on anything else, other functions can depend on it, w

Re: [Bioc-devel] read_bed()

I'm not sure if a function called read_bed() should be plotting or printing. Is your BED file a known BED variant, i.e., maybe there is a better name for the file type than "bed"? On Wed, Sep 18, 2019 at 3:17 AM Bhagwat, Aditya wrote: > > Actually, > > I will keep multicrispr::read_bed(), but wr

Re: [Bioc-devel] read_bed()

Actually, I will keep multicrispr::read_bed(), but wrap it around rtracklayer::import.bed, and additionally plot and print range summaries. Aditya From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Bhagwat, Aditya [aditya.bhag...@mpi-bn.mp

Re: [Bioc-devel] read_bed()

(Typo corrected to avoid confusion) Michael, rtracklayer::import.bed() indeed works perfectly for me, so I am dropping multicrispr::read_bed(). In order to avoid the overkill of `require(tracklayer)` for multicrispr users, does it make se

Re: [Bioc-devel] read_bed()

Michael, rtracklayer::import.bed() indeed works perfectly for me, so I am dropping multicrispr::read_bed. In order to avoid the overkill of `require(tracklayer` for multicrispr users, does it make sense to import/re-export read.bed in mult