Re: [Bioc-devel] Adding a lengths() method to List class

2015-10-15 Thread Hervé Pagès 

On 10/15/2015 11:24 AM, Michael Lawrence wrote:

Btw, a subtle issue here is that elementLengths currently calls NROW(),
not length(), and code might be relying on DataFrameList returning row
counts. That behavior has proven convenient, so it would be nice not to
lose it. I guess nrow() already does that, but anyway, lengths() is not
the equivalent of elementLengths() there.


There is actually a big note in ?BiocGenerics::lengths about this.
This means we will need to keep elementLengths() around but the plan
is to rename it elementNROWS() (consistent with extractROWS). The
current name is clearly a misnomer and a source of confusion.

H.



On Wed, Sep 30, 2015 at 9:37 PM, Hervé Pagès mailto:hpa...@fredhutch.org>> wrote:

On 09/30/2015 05:28 PM, Michael Lawrence wrote:

It wasn't a conscious choice, but it would slow things down a
bit. Not
by much though, since we're already attempting dispatch on
length(). I
can make the change.


That would be great. Thanks Michael!

H.


On Wed, Sep 30, 2015 at 1:33 PM, Hervé Pagès
mailto:hpa...@fredhutch.org>
>> wrote:

 Hi Michael,

 I was expecting this to just work:

base::lengths(IntegerList(1:4, 1:6))

 but it doesn't:

Error in base::lengths(IntegerList(1:4, 1:6)) :
  'x' must be a list or atomic vector

 The man page says:

   This function loops over ‘x’ and returns a compatible
vector
   containing the length of each element in ‘x’.
Effectively,
   ‘length(x[[i]])’ is called for all ‘i’, so any
methods on ‘length’
   are considered.

 If length(x[[i]]) is called for all i then it should work
on any object
 for which [[ is defined. Note that this is what happens with
 base::sapply(), base::mapply(), etc... they all use [[
internally.

 Do you know of any reason why lengths() doesn't do this?

 Thanks,
 H.


 On 09/28/2015 09:51 PM, Michael Lawrence wrote:

 That is the plan. Note that we already have
elementLengths()
 that serves
 the same purpose. It was the direct inspiration for
lengths().

 On Mon, Sep 28, 2015 at 9:41 PM, Peter Hickey
 mailto:peter.hic...@gmail.com>
>>
 wrote:

 The lengths() function was added in R 3.2 to "get
the length
 of each
 element of a list or atomic vector (is.atomic) as
an integer
 or numeric
 vector." It seems useful to me to have also a
similar method
 defined for
 the S4Vectors::List class (and subclasses). What do
others
 think?

   [[alternative HTML version deleted]]

 ___
Bioc-devel@r-project.org 
>
 mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


  [[alternative HTML version deleted]]

 ___
Bioc-devel@r-project.org 
>
 mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


 --
 Hervé Pagès

 Program in Computational Biology
 Division of Public Health Sciences
 Fred Hutchinson Cancer Research Center
 1100 Fairview Ave. N, M1-B514
 P.O. Box 19024
 Seattle, WA 98109-1024

 E-mail: hpa...@fredhutch.org 
>
 Phone: (206) 667-5791 

 Fax: (206) 667-1319 




--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org 
Phone: (206) 667-5791 
Fax: (206) 667-1319 




--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fa

Re: [Bioc-devel] SV4Vectors installation problem

2015-10-15 Thread Hervé Pagès 

Hi Michael,

On 10/15/2015 10:08 AM, Michael Lawrence wrote:

Tangentially related, it seems like nchar is worth defining in
BiocGenerics, with a signature of "x". I saw that Biostrings uses "type",
but I'm not sure why.


The 2 "nchar" methods that dispatch on the 'type' argument are from
the Biostrings 1 era (> 9 years old) and were kept in the 
Biostrings/Biostrings1/ folder for legacy only (this code doesn't

get evaluated, not even installed). That reminds me that it's probably
time to get rid of all that stuff.


But if we're just going to use the signature of 'x',
I can make nchar dispatch internally, so we don't need an R-level generic.
Will that work?


If by "make nchar dispatch internally" you mean "turn nchar() into a
primitive in R", like, say, length(), names(), dim(), dimnames(), `[`,
etc... then works for me.

Thanks,
H.



Michael

On Thu, Oct 15, 2015 at 5:19 AM, Morgan, Martin <
martin.mor...@roswellpark.org> wrote:





-Original Message-
From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
Marcin Cieslik
Sent: Thursday, October 15, 2015 7:46 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] SV4Vectors installation problem

Dear Bioconductors,

Somewhere in August S4Vectors stopped installing correctly resulting in

a:


Creating a generic function for ‘nchar’ from package ‘base’ in package
‘S4Vectors’

message (that cannot be suppressed) each time the package is loaded. The
issue is not fixed by a fresh reinstall of bioconductor. The first hint

of the

you're right that this is a message and that it cannot be suppressed, but
the package still functions correctly, right?

The problem was introduced by a change in R. The above is a work-around.
The permanent solution is now to use the current version of R (3.2.2) and
Bioc (3.2). The specific commit was


r106498 | mtmor...@fhcrc.org | 2015-07-16 15:10:40 -0400 (Thu, 16 Jul
2015) | 5 lines

define nchar,Rle-method in .onLoad

- work-around consequences of changed base::nchar signature for
   3.2.1 binary builds used in 3.2.0



some related / belated discussion is at

https://stat.ethz.ch/pipermail/r-devel/2015-October/071841.html

Martin



problem appears during installation

http://pastebin.com/UpKdeNTH

It appears I am not the only one affected a search reveals many

instances:


e.g.
https://rpubs.com/Pazz/advanced_annotation
http://bioc.ism.ac.jp/packages/checkResults/3.1/bioc-
LATEST/S4Vectors/petty-install.html
http://biocluster.ucr.edu/~rkaundal/R_sep2015/Rrnaseq/RNAseq.html

Thanks a lot for your work! If needed I can provide  a Docker image that
reproduces the problem.

Yours,
Marcin

   [[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



This email message may contain legally privileged and/or confidential
information.  If you are not the intended recipient(s), or the employee or
agent responsible for the delivery of this message to the intended
recipient(s), you are hereby notified that any disclosure, copying,
distribution, or use of this email message is prohibited.  If you have
received this message in error, please notify the sender immediately by
e-mail and delete this email message from your computer. Thank you.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Adding a lengths() method to List class

2015-10-15 Thread Michael Lawrence 
Btw, a subtle issue here is that elementLengths currently calls NROW(), not
length(), and code might be relying on DataFrameList returning row counts.
That behavior has proven convenient, so it would be nice not to lose it. I
guess nrow() already does that, but anyway, lengths() is not the equivalent
of elementLengths() there.

On Wed, Sep 30, 2015 at 9:37 PM, Hervé Pagès  wrote:

> On 09/30/2015 05:28 PM, Michael Lawrence wrote:
>
>> It wasn't a conscious choice, but it would slow things down a bit. Not
>> by much though, since we're already attempting dispatch on length(). I
>> can make the change.
>>
>
> That would be great. Thanks Michael!
>
> H.
>
>
>> On Wed, Sep 30, 2015 at 1:33 PM, Hervé Pagès > > wrote:
>>
>> Hi Michael,
>>
>> I was expecting this to just work:
>>
>>base::lengths(IntegerList(1:4, 1:6))
>>
>> but it doesn't:
>>
>>Error in base::lengths(IntegerList(1:4, 1:6)) :
>>  'x' must be a list or atomic vector
>>
>> The man page says:
>>
>>   This function loops over ‘x’ and returns a compatible vector
>>   containing the length of each element in ‘x’.  Effectively,
>>   ‘length(x[[i]])’ is called for all ‘i’, so any methods on
>> ‘length’
>>   are considered.
>>
>> If length(x[[i]]) is called for all i then it should work on any
>> object
>> for which [[ is defined. Note that this is what happens with
>> base::sapply(), base::mapply(), etc... they all use [[ internally.
>>
>> Do you know of any reason why lengths() doesn't do this?
>>
>> Thanks,
>> H.
>>
>>
>> On 09/28/2015 09:51 PM, Michael Lawrence wrote:
>>
>> That is the plan. Note that we already have elementLengths()
>> that serves
>> the same purpose. It was the direct inspiration for lengths().
>>
>> On Mon, Sep 28, 2015 at 9:41 PM, Peter Hickey
>> mailto:peter.hic...@gmail.com>>
>> wrote:
>>
>> The lengths() function was added in R 3.2 to "get the length
>> of each
>> element of a list or atomic vector (is.atomic) as an integer
>> or numeric
>> vector." It seems useful to me to have also a similar method
>> defined for
>> the S4Vectors::List class (and subclasses). What do others
>> think?
>>
>>   [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org 
>> mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>>
>>  [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org 
>> mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>>
>> --
>> Hervé Pagès
>>
>> Program in Computational Biology
>> Division of Public Health Sciences
>> Fred Hutchinson Cancer Research Center
>> 1100 Fairview Ave. N, M1-B514
>> P.O. Box 19024
>> Seattle, WA 98109-1024
>>
>> E-mail: hpa...@fredhutch.org 
>> Phone: (206) 667-5791 
>> Fax: (206) 667-1319 
>>
>>
>>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] A method for combining SummarizedExperiment objects

2015-10-15 Thread Morgan, Martin 
Hi Pete -- looks like a good idea. 

I think the generic could be adjusted to pass named (not x, y) args to methods, 
rather than trying (incorrectly) to combine them. I don't think the 
inefficiency of recursion is a particular concern, because it is not like 
hundreds (or even tens) of objects are typically being combined.

combine() takes the approach of implementing methods for each component -- so I 
guess DataFrame, GRanges, GRangesList, SimpleList (for the assays, which are 
matrix, which are already combine()-able). 

Any interest in re-implementing your code along these lines (as methods on the 
building blocks)? Some guidance might come from selectMethod("combine", 
c("data.frame", "data.frame")).

FWIW -- 

stop(paste0()) is just stop(), which accepts multiple arguments and pastes them 
together without a separator. 

x@NAMES is names(), as in names(GRanges("chr1", IRanges(1, 10, names="A")))

?elementMetadata says "Alternatives to 'mcols' functions. Their [i.e., 
elementMetadata] use is discouraged."


> -Original Message-
> From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> Peter Hickey
> Sent: Wednesday, October 14, 2015 9:52 PM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] A method for combining SummarizedExperiment
> objects
> 
> I often find myself with multiple `SE` objects (I'm using `SE` as a shorthand 
> for
> the `SummarizedExperiment0` and `RangedSummarizedExeriment` classes),
> each with different samples but possibly non-overlapping features/ranges.
> Currently, it is difficult to combine these objects;  `rbind()` can only 
> combine
> objects with the same samples but different features/ranges and `cbind()`
> can only combine objects with the same features/ranges but different
> samples. I think it would be useful to have a "combine" method for `SE`
> objects that handles the situation where each object has different samples
> but with possibly non-overlapping features/ranges.
> 
> I've written a first pass at a method to do this at
> https://gist.github.com/PeteHaitch/8993b096cfa7ccd08c13.
> Is this a method other people find themselves in need of and, if so, might we
> add something like this to the SummarizedExperiment package? As noted in
> the gist, there's a few things I'd like to address to make it more robust and
> complete (probably some optimisations too).
> 
> Cheers,
> Pete
> 
>   [[alternative HTML version deleted]]
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Git-svn: getting it to work while keeping your git history

2015-10-15 Thread Jim Hester 
Yes I will try and update the current documentation to address this
situation. When it was first written we (I?) was not aware of all the
issues with prior history, merging and how best to handle them.

On Thu, Oct 15, 2015 at 2:00 PM, Leonardo Collado Torres 
wrote:

> Jim,
>
> Thank you! This works perfectly!! It'd be great to have this
> information at http://bioconductor.org/developers/how-to/git-mirrors/
>
> I realize now that you already had mentioned using "git cherry-pick"
> at https://stat.ethz.ch/pipermail/bioc-devel/2015-September/008013.html
> and Siddhartha covered it in
> https://stat.ethz.ch/pipermail/bioc-devel/2015-July/007797.html I
> appreciate the detailed steps you outline in this thread! I'll also
> try to be careful to avoid the potential pitfall Sid mentioned.
>
> I'm guessing that for the first time you merge the git and svn
> histories, following Mike's steps would be the easiest. Then use "git
> cherry pick" from then on.
>
> Cheers,
> Leo
>
> On Thu, Oct 15, 2015 at 12:21 PM, Jim Hester 
> wrote:
> > Leo,
> >
> > You can use your current git repo, please don't delete it or your
> history!
> >
> > The most foolproof way of using git-svn with existing git history is to
> use
> > `git cherry-pick` to
> > pick commits to add to the `devel` branch rather than merging changes
> from
> > the master
> > branch. This will avoid including the old pre-bioconductor inclusion
> > commits so you won't have the rebase issues. You can use merges in your
> > master branch
> > (including from pull requests), but when you want to commit those
> changes to
> > SVN you need
> >  to cherry pick the individual commits to include.
> >
> > You can give `git cherry-pick` a commit range to include like `git
> > cherry-pick
> > 52a6636565..408659187` and it will include all commits within that range.
> >
> > So the workflow would be, do work and commit in master then,
> >
> > ```bash
> > git checkout devel
> > git svn rebase
> >
> > # figure out what commit range to use and cherry pick them
> > git log master
> > git cherry-pick 52a6636565..408659187
> >
> > git svn dcommit
> > ```
> >
> > In this way your devel branch remains completely linear (so no conflicts
> > from git-svn) and you can retain your
> > full git history in your master branch.
> >
> > I hope this makes sense, let me know if you have questions!
> >
> > Jim
> >
> > On Thu, Oct 15, 2015 at 12:04 PM, Leonardo Collado Torres <
> lcoll...@jhu.edu>
> > wrote:
> >>
> >> Hi,
> >>
> >> Now that BioC 3.2 is released, I need a little bit of guidance on
> git-svn.
> >>
> >> I know that the bridges won't work anymore and my past attempt at the
> >> new git-svn setup was kind of a mess (see
> >> https://stat.ethz.ch/pipermail/bioc-devel/2015-June/007726.html). But
> >> I'm ready to give it another go.
> >>
> >> My understanding is that the easiest thing to do right now would be to
> >> fork https://github.com/Bioconductor-mirror/REPO and continue from
> >> there as in scenario 2 from
> >> http://bioconductor.org/developers/how-to/git-mirrors/ Doing so would
> >> mean losing the git history, which would mean losing links between
> >> commit messages and issues: well, the issues would be gone too, etc.
> >> In this scenario, I guess that folks in my situation could keep their
> >> current git repo somewhere as an archive of what happened in case the
> >> info is needed.
> >>
> >> However, from Jim Hester's message at
> >> https://stat.ethz.ch/pipermail/bioc-devel/2015-September/008013.html
> >> I'm inferring that things would break again with a GitHub pull request
> >> that involved a git merge, which would be a bummer. Jim also mentions
> >> that there might be alternatives coming soon.
> >>
> >>
> >> Now, looking at other git-svn threads in bioc-devel I found that the
> >> steps Mike specified in
> >> https://stat.ethz.ch/pipermail/bioc-devel/2015-September/008018.html
> >> work well. I tested this yesterday with success. However, you have to
> >> keep following his steps every time you want to commit to svn because
> >> following the scenario 2 steps in
> >> http://bioconductor.org/developers/how-to/git-mirrors/ lead to a
> >> "unable to determine upstream SVN history" error.
> >>
> >> As of right now, Mike's steps are the best alternative for using
> >> git-svn and keeping your git history. I know that it would add
> >> spurious commits like
> >>
> >>
> https://github.com/leekgroup/derfinderHelper/commit/af2457bb07aad066773f010e203f5d4c8f6696bd
> >> (from "git merge -s ours git_svn_starting_point_commit_id" step in
> >> Mike's instructions) and
> >>
> >>
> https://github.com/leekgroup/derfinderHelper/commit/9916b1ef49e32107ed5bee501e49731a7b4f3434
> >> (from "git checkout master; git merge devel" to merge back the svn
> >> history to git). It's not super clean, but it works.
> >>
> >> Or is there another option that I'm missing? Is there any reason why I
> >> should not follow Mike's steps? I'm guessing that any alternatives to
> >> git-svn will take

Re: [Bioc-devel] Github Bioconductor-mirror not updating for repo's that still had bridges?

2015-10-15 Thread Leonardo Collado Torres 
Ahh, ok! Thanks!

On Thu, Oct 15, 2015 at 12:23 PM, Jim Hester  wrote:
> Leo,
>
> This issue is unrelated to having a git-svn bridge, the update script just
> failed during the version bump commit. The git mirrors should be updated to
> the current state soon.
>
> Jim
>
> On Thu, Oct 15, 2015 at 12:06 PM, Leonardo Collado Torres 
> wrote:
>>
>> I know that the git-svn bridge is deprecated as of the new release
>> yesterday. I'm migrating to using the git mirror, but they are not
>> updated for packages that had a bridge.
>>
>> Thanks for taking a look Dan!
>> Leo
>>
>> On Thu, Oct 15, 2015 at 11:52 AM, Dan Tenenbaum 
>> wrote:
>> > The git-svn bridge is deprecated and we recommend migrating to the git
>> > mirrors.
>> > At some point the git-svn bridge will no longer be supported.
>> > I will take a look at this.
>> > Dan
>> >
>> >
>> > - Original Message -
>> >> From: "Leonardo Collado Torres" 
>> >> To: bioc-devel@r-project.org
>> >> Sent: Thursday, October 15, 2015 8:47:40 AM
>> >> Subject: [Bioc-devel] Github Bioconductor-mirror not updating for
>> >> repo's  that still had bridges?
>> >>
>> >> Hi,
>> >>
>> >> I noticed that my repositories that had an active git-svn bridge seem
>> >> to not be updated in Bioconductor-mirror.
>> >>
>> >> For example, you can see that the bridge was still working for
>> >> derfinder with this commit:
>> >>
>> >> https://github.com/lcolladotor/derfinder/commit/a82112f777415414c234623af15e0c2088c2eea7
>> >> but that commit is not at
>> >> https://github.com/Bioconductor-mirror/derfinder/commits/master yet.
>> >> It's on svn though.
>> >>
>> >> Cheers,
>> >> Leo
>> >>
>> >> Leonardo Collado Torres, PhD Candidate
>> >> Department of Biostatistics
>> >> Johns Hopkins University
>> >> Bloomberg School of Public Health
>> >> Website: http://lcolladotor.github.io/about.html
>> >>
>> >> ___
>> >> Bioc-devel@r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >>
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Git-svn: getting it to work while keeping your git history

2015-10-15 Thread Leonardo Collado Torres 
Jim,

Thank you! This works perfectly!! It'd be great to have this
information at http://bioconductor.org/developers/how-to/git-mirrors/

I realize now that you already had mentioned using "git cherry-pick"
at https://stat.ethz.ch/pipermail/bioc-devel/2015-September/008013.html
and Siddhartha covered it in
https://stat.ethz.ch/pipermail/bioc-devel/2015-July/007797.html I
appreciate the detailed steps you outline in this thread! I'll also
try to be careful to avoid the potential pitfall Sid mentioned.

I'm guessing that for the first time you merge the git and svn
histories, following Mike's steps would be the easiest. Then use "git
cherry pick" from then on.

Cheers,
Leo

On Thu, Oct 15, 2015 at 12:21 PM, Jim Hester  wrote:
> Leo,
>
> You can use your current git repo, please don't delete it or your history!
>
> The most foolproof way of using git-svn with existing git history is to use
> `git cherry-pick` to
> pick commits to add to the `devel` branch rather than merging changes from
> the master
> branch. This will avoid including the old pre-bioconductor inclusion
> commits so you won't have the rebase issues. You can use merges in your
> master branch
> (including from pull requests), but when you want to commit those changes to
> SVN you need
>  to cherry pick the individual commits to include.
>
> You can give `git cherry-pick` a commit range to include like `git
> cherry-pick
> 52a6636565..408659187` and it will include all commits within that range.
>
> So the workflow would be, do work and commit in master then,
>
> ```bash
> git checkout devel
> git svn rebase
>
> # figure out what commit range to use and cherry pick them
> git log master
> git cherry-pick 52a6636565..408659187
>
> git svn dcommit
> ```
>
> In this way your devel branch remains completely linear (so no conflicts
> from git-svn) and you can retain your
> full git history in your master branch.
>
> I hope this makes sense, let me know if you have questions!
>
> Jim
>
> On Thu, Oct 15, 2015 at 12:04 PM, Leonardo Collado Torres 
> wrote:
>>
>> Hi,
>>
>> Now that BioC 3.2 is released, I need a little bit of guidance on git-svn.
>>
>> I know that the bridges won't work anymore and my past attempt at the
>> new git-svn setup was kind of a mess (see
>> https://stat.ethz.ch/pipermail/bioc-devel/2015-June/007726.html). But
>> I'm ready to give it another go.
>>
>> My understanding is that the easiest thing to do right now would be to
>> fork https://github.com/Bioconductor-mirror/REPO and continue from
>> there as in scenario 2 from
>> http://bioconductor.org/developers/how-to/git-mirrors/ Doing so would
>> mean losing the git history, which would mean losing links between
>> commit messages and issues: well, the issues would be gone too, etc.
>> In this scenario, I guess that folks in my situation could keep their
>> current git repo somewhere as an archive of what happened in case the
>> info is needed.
>>
>> However, from Jim Hester's message at
>> https://stat.ethz.ch/pipermail/bioc-devel/2015-September/008013.html
>> I'm inferring that things would break again with a GitHub pull request
>> that involved a git merge, which would be a bummer. Jim also mentions
>> that there might be alternatives coming soon.
>>
>>
>> Now, looking at other git-svn threads in bioc-devel I found that the
>> steps Mike specified in
>> https://stat.ethz.ch/pipermail/bioc-devel/2015-September/008018.html
>> work well. I tested this yesterday with success. However, you have to
>> keep following his steps every time you want to commit to svn because
>> following the scenario 2 steps in
>> http://bioconductor.org/developers/how-to/git-mirrors/ lead to a
>> "unable to determine upstream SVN history" error.
>>
>> As of right now, Mike's steps are the best alternative for using
>> git-svn and keeping your git history. I know that it would add
>> spurious commits like
>>
>> https://github.com/leekgroup/derfinderHelper/commit/af2457bb07aad066773f010e203f5d4c8f6696bd
>> (from "git merge -s ours git_svn_starting_point_commit_id" step in
>> Mike's instructions) and
>>
>> https://github.com/leekgroup/derfinderHelper/commit/9916b1ef49e32107ed5bee501e49731a7b4f3434
>> (from "git checkout master; git merge devel" to merge back the svn
>> history to git). It's not super clean, but it works.
>>
>> Or is there another option that I'm missing? Is there any reason why I
>> should not follow Mike's steps? I'm guessing that any alternatives to
>> git-svn will take a while to develop.
>>
>> Thanks,
>> Leo
>>
>> Leonardo Collado Torres, PhD Candidate
>> Department of Biostatistics
>> Johns Hopkins University
>> Bloomberg School of Public Health
>> Website: http://lcolladotor.github.io/about.html
>
>

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] SV4Vectors installation problem

2015-10-15 Thread Michael Lawrence 
Tangentially related, it seems like nchar is worth defining in
BiocGenerics, with a signature of "x". I saw that Biostrings uses "type",
but I'm not sure why. But if we're just going to use the signature of 'x',
I can make nchar dispatch internally, so we don't need an R-level generic.
Will that work?

Michael

On Thu, Oct 15, 2015 at 5:19 AM, Morgan, Martin <
martin.mor...@roswellpark.org> wrote:

>
>
> > -Original Message-
> > From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> > Marcin Cieslik
> > Sent: Thursday, October 15, 2015 7:46 AM
> > To: bioc-devel@r-project.org
> > Subject: [Bioc-devel] SV4Vectors installation problem
> >
> > Dear Bioconductors,
> >
> > Somewhere in August S4Vectors stopped installing correctly resulting in
> a:
> >
> > Creating a generic function for ‘nchar’ from package ‘base’ in package
> > ‘S4Vectors’
> >
> > message (that cannot be suppressed) each time the package is loaded. The
> > issue is not fixed by a fresh reinstall of bioconductor. The first hint
> of the
>
> you're right that this is a message and that it cannot be suppressed, but
> the package still functions correctly, right?
>
> The problem was introduced by a change in R. The above is a work-around.
> The permanent solution is now to use the current version of R (3.2.2) and
> Bioc (3.2). The specific commit was
>
> 
> r106498 | mtmor...@fhcrc.org | 2015-07-16 15:10:40 -0400 (Thu, 16 Jul
> 2015) | 5 lines
>
> define nchar,Rle-method in .onLoad
>
> - work-around consequences of changed base::nchar signature for
>   3.2.1 binary builds used in 3.2.0
>
> 
>
> some related / belated discussion is at
>
> https://stat.ethz.ch/pipermail/r-devel/2015-October/071841.html
>
> Martin
>
>
> > problem appears during installation
> >
> > http://pastebin.com/UpKdeNTH
> >
> > It appears I am not the only one affected a search reveals many
> instances:
> >
> > e.g.
> > https://rpubs.com/Pazz/advanced_annotation
> > http://bioc.ism.ac.jp/packages/checkResults/3.1/bioc-
> > LATEST/S4Vectors/petty-install.html
> > http://biocluster.ucr.edu/~rkaundal/R_sep2015/Rrnaseq/RNAseq.html
> >
> > Thanks a lot for your work! If needed I can provide  a Docker image that
> > reproduces the problem.
> >
> > Yours,
> > Marcin
> >
> >   [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
> This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Github Bioconductor-mirror not updating for repo's that still had bridges?

2015-10-15 Thread Jim Hester 
Leo,

This issue is unrelated to having a git-svn bridge, the update script just
failed during the version bump commit. The git mirrors should be updated to
the current state soon.

Jim

On Thu, Oct 15, 2015 at 12:06 PM, Leonardo Collado Torres 
wrote:

> I know that the git-svn bridge is deprecated as of the new release
> yesterday. I'm migrating to using the git mirror, but they are not
> updated for packages that had a bridge.
>
> Thanks for taking a look Dan!
> Leo
>
> On Thu, Oct 15, 2015 at 11:52 AM, Dan Tenenbaum 
> wrote:
> > The git-svn bridge is deprecated and we recommend migrating to the git
> mirrors.
> > At some point the git-svn bridge will no longer be supported.
> > I will take a look at this.
> > Dan
> >
> >
> > - Original Message -
> >> From: "Leonardo Collado Torres" 
> >> To: bioc-devel@r-project.org
> >> Sent: Thursday, October 15, 2015 8:47:40 AM
> >> Subject: [Bioc-devel] Github Bioconductor-mirror not updating for
> repo's  that still had bridges?
> >>
> >> Hi,
> >>
> >> I noticed that my repositories that had an active git-svn bridge seem
> >> to not be updated in Bioconductor-mirror.
> >>
> >> For example, you can see that the bridge was still working for
> >> derfinder with this commit:
> >>
> https://github.com/lcolladotor/derfinder/commit/a82112f777415414c234623af15e0c2088c2eea7
> >> but that commit is not at
> >> https://github.com/Bioconductor-mirror/derfinder/commits/master yet.
> >> It's on svn though.
> >>
> >> Cheers,
> >> Leo
> >>
> >> Leonardo Collado Torres, PhD Candidate
> >> Department of Biostatistics
> >> Johns Hopkins University
> >> Bloomberg School of Public Health
> >> Website: http://lcolladotor.github.io/about.html
> >>
> >> ___
> >> Bioc-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Git-svn: getting it to work while keeping your git history

2015-10-15 Thread Jim Hester 
Leo,

You can use your current git repo, please don't delete it or your history!

The most foolproof way of using git-svn with existing git history is to use
`git cherry-pick` to
pick commits to add to the `devel` branch rather than merging changes from
the master
branch. This will avoid including the old pre-bioconductor inclusion
commits so you won't have the rebase issues. You can use merges in your
master branch
(including from pull requests), but when you want to commit those changes
to SVN you need
 to cherry pick the individual commits to include.

You can give `git cherry-pick` a commit range to include like `git
cherry-pick
52a6636565..408659187` and it will include all commits within that range.

So the workflow would be, do work and commit in master then,

```bash
git checkout devel
git svn rebase

# figure out what commit range to use and cherry pick them
git log master
git cherry-pick 52a6636565..408659187

git svn dcommit
```

In this way your devel branch remains completely linear (so no conflicts
from git-svn) and you can retain your
full git history in your master branch.

I hope this makes sense, let me know if you have questions!

Jim

On Thu, Oct 15, 2015 at 12:04 PM, Leonardo Collado Torres 
wrote:

> Hi,
>
> Now that BioC 3.2 is released, I need a little bit of guidance on git-svn.
>
> I know that the bridges won't work anymore and my past attempt at the
> new git-svn setup was kind of a mess (see
> https://stat.ethz.ch/pipermail/bioc-devel/2015-June/007726.html). But
> I'm ready to give it another go.
>
> My understanding is that the easiest thing to do right now would be to
> fork https://github.com/Bioconductor-mirror/REPO and continue from
> there as in scenario 2 from
> http://bioconductor.org/developers/how-to/git-mirrors/ Doing so would
> mean losing the git history, which would mean losing links between
> commit messages and issues: well, the issues would be gone too, etc.
> In this scenario, I guess that folks in my situation could keep their
> current git repo somewhere as an archive of what happened in case the
> info is needed.
>
> However, from Jim Hester's message at
> https://stat.ethz.ch/pipermail/bioc-devel/2015-September/008013.html
> I'm inferring that things would break again with a GitHub pull request
> that involved a git merge, which would be a bummer. Jim also mentions
> that there might be alternatives coming soon.
>
>
> Now, looking at other git-svn threads in bioc-devel I found that the
> steps Mike specified in
> https://stat.ethz.ch/pipermail/bioc-devel/2015-September/008018.html
> work well. I tested this yesterday with success. However, you have to
> keep following his steps every time you want to commit to svn because
> following the scenario 2 steps in
> http://bioconductor.org/developers/how-to/git-mirrors/ lead to a
> "unable to determine upstream SVN history" error.
>
> As of right now, Mike's steps are the best alternative for using
> git-svn and keeping your git history. I know that it would add
> spurious commits like
>
> https://github.com/leekgroup/derfinderHelper/commit/af2457bb07aad066773f010e203f5d4c8f6696bd
> (from "git merge -s ours git_svn_starting_point_commit_id" step in
> Mike's instructions) and
>
> https://github.com/leekgroup/derfinderHelper/commit/9916b1ef49e32107ed5bee501e49731a7b4f3434
> (from "git checkout master; git merge devel" to merge back the svn
> history to git). It's not super clean, but it works.
>
> Or is there another option that I'm missing? Is there any reason why I
> should not follow Mike's steps? I'm guessing that any alternatives to
> git-svn will take a while to develop.
>
> Thanks,
> Leo
>
> Leonardo Collado Torres, PhD Candidate
> Department of Biostatistics
> Johns Hopkins University
> Bloomberg School of Public Health
> Website: http://lcolladotor.github.io/about.html
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Github Bioconductor-mirror not updating for repo's that still had bridges?

2015-10-15 Thread Leonardo Collado Torres 
I know that the git-svn bridge is deprecated as of the new release
yesterday. I'm migrating to using the git mirror, but they are not
updated for packages that had a bridge.

Thanks for taking a look Dan!
Leo

On Thu, Oct 15, 2015 at 11:52 AM, Dan Tenenbaum  wrote:
> The git-svn bridge is deprecated and we recommend migrating to the git 
> mirrors.
> At some point the git-svn bridge will no longer be supported.
> I will take a look at this.
> Dan
>
>
> - Original Message -
>> From: "Leonardo Collado Torres" 
>> To: bioc-devel@r-project.org
>> Sent: Thursday, October 15, 2015 8:47:40 AM
>> Subject: [Bioc-devel] Github Bioconductor-mirror not updating for repo's 
>>  that still had bridges?
>>
>> Hi,
>>
>> I noticed that my repositories that had an active git-svn bridge seem
>> to not be updated in Bioconductor-mirror.
>>
>> For example, you can see that the bridge was still working for
>> derfinder with this commit:
>> https://github.com/lcolladotor/derfinder/commit/a82112f777415414c234623af15e0c2088c2eea7
>> but that commit is not at
>> https://github.com/Bioconductor-mirror/derfinder/commits/master yet.
>> It's on svn though.
>>
>> Cheers,
>> Leo
>>
>> Leonardo Collado Torres, PhD Candidate
>> Department of Biostatistics
>> Johns Hopkins University
>> Bloomberg School of Public Health
>> Website: http://lcolladotor.github.io/about.html
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Git-svn: getting it to work while keeping your git history

2015-10-15 Thread Leonardo Collado Torres 
Hi,

Now that BioC 3.2 is released, I need a little bit of guidance on git-svn.

I know that the bridges won't work anymore and my past attempt at the
new git-svn setup was kind of a mess (see
https://stat.ethz.ch/pipermail/bioc-devel/2015-June/007726.html). But
I'm ready to give it another go.

My understanding is that the easiest thing to do right now would be to
fork https://github.com/Bioconductor-mirror/REPO and continue from
there as in scenario 2 from
http://bioconductor.org/developers/how-to/git-mirrors/ Doing so would
mean losing the git history, which would mean losing links between
commit messages and issues: well, the issues would be gone too, etc.
In this scenario, I guess that folks in my situation could keep their
current git repo somewhere as an archive of what happened in case the
info is needed.

However, from Jim Hester's message at
https://stat.ethz.ch/pipermail/bioc-devel/2015-September/008013.html
I'm inferring that things would break again with a GitHub pull request
that involved a git merge, which would be a bummer. Jim also mentions
that there might be alternatives coming soon.


Now, looking at other git-svn threads in bioc-devel I found that the
steps Mike specified in
https://stat.ethz.ch/pipermail/bioc-devel/2015-September/008018.html
work well. I tested this yesterday with success. However, you have to
keep following his steps every time you want to commit to svn because
following the scenario 2 steps in
http://bioconductor.org/developers/how-to/git-mirrors/ lead to a
"unable to determine upstream SVN history" error.

As of right now, Mike's steps are the best alternative for using
git-svn and keeping your git history. I know that it would add
spurious commits like
https://github.com/leekgroup/derfinderHelper/commit/af2457bb07aad066773f010e203f5d4c8f6696bd
(from "git merge -s ours git_svn_starting_point_commit_id" step in
Mike's instructions) and
https://github.com/leekgroup/derfinderHelper/commit/9916b1ef49e32107ed5bee501e49731a7b4f3434
(from "git checkout master; git merge devel" to merge back the svn
history to git). It's not super clean, but it works.

Or is there another option that I'm missing? Is there any reason why I
should not follow Mike's steps? I'm guessing that any alternatives to
git-svn will take a while to develop.

Thanks,
Leo

Leonardo Collado Torres, PhD Candidate
Department of Biostatistics
Johns Hopkins University
Bloomberg School of Public Health
Website: http://lcolladotor.github.io/about.html

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Github Bioconductor-mirror not updating for repo's that still had bridges?

2015-10-15 Thread Dan Tenenbaum 
The git-svn bridge is deprecated and we recommend migrating to the git mirrors.
At some point the git-svn bridge will no longer be supported.
I will take a look at this.
Dan


- Original Message -
> From: "Leonardo Collado Torres" 
> To: bioc-devel@r-project.org
> Sent: Thursday, October 15, 2015 8:47:40 AM
> Subject: [Bioc-devel] Github Bioconductor-mirror not updating for repo's  
> that still had bridges?
> 
> Hi,
> 
> I noticed that my repositories that had an active git-svn bridge seem
> to not be updated in Bioconductor-mirror.
> 
> For example, you can see that the bridge was still working for
> derfinder with this commit:
> https://github.com/lcolladotor/derfinder/commit/a82112f777415414c234623af15e0c2088c2eea7
> but that commit is not at
> https://github.com/Bioconductor-mirror/derfinder/commits/master yet.
> It's on svn though.
> 
> Cheers,
> Leo
> 
> Leonardo Collado Torres, PhD Candidate
> Department of Biostatistics
> Johns Hopkins University
> Bloomberg School of Public Health
> Website: http://lcolladotor.github.io/about.html
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Github Bioconductor-mirror not updating for repo's that still had bridges?

2015-10-15 Thread Leonardo Collado Torres 
Hi,

I noticed that my repositories that had an active git-svn bridge seem
to not be updated in Bioconductor-mirror.

For example, you can see that the bridge was still working for
derfinder with this commit:
https://github.com/lcolladotor/derfinder/commit/a82112f777415414c234623af15e0c2088c2eea7
but that commit is not at
https://github.com/Bioconductor-mirror/derfinder/commits/master yet.
It's on svn though.

Cheers,
Leo

Leonardo Collado Torres, PhD Candidate
Department of Biostatistics
Johns Hopkins University
Bloomberg School of Public Health
Website: http://lcolladotor.github.io/about.html

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] SV4Vectors installation problem

2015-10-15 Thread Morgan, Martin 


> -Original Message-
> From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> Marcin Cieslik
> Sent: Thursday, October 15, 2015 7:46 AM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] SV4Vectors installation problem
> 
> Dear Bioconductors,
> 
> Somewhere in August S4Vectors stopped installing correctly resulting in a:
> 
> Creating a generic function for ‘nchar’ from package ‘base’ in package
> ‘S4Vectors’
> 
> message (that cannot be suppressed) each time the package is loaded. The
> issue is not fixed by a fresh reinstall of bioconductor. The first hint of the

you're right that this is a message and that it cannot be suppressed, but the 
package still functions correctly, right?

The problem was introduced by a change in R. The above is a work-around. The 
permanent solution is now to use the current version of R (3.2.2) and Bioc 
(3.2). The specific commit was


r106498 | mtmor...@fhcrc.org | 2015-07-16 15:10:40 -0400 (Thu, 16 Jul 2015) | 5 
lines

define nchar,Rle-method in .onLoad

- work-around consequences of changed base::nchar signature for
  3.2.1 binary builds used in 3.2.0



some related / belated discussion is at

https://stat.ethz.ch/pipermail/r-devel/2015-October/071841.html

Martin


> problem appears during installation
> 
> http://pastebin.com/UpKdeNTH
> 
> It appears I am not the only one affected a search reveals many instances:
> 
> e.g.
> https://rpubs.com/Pazz/advanced_annotation
> http://bioc.ism.ac.jp/packages/checkResults/3.1/bioc-
> LATEST/S4Vectors/petty-install.html
> http://biocluster.ucr.edu/~rkaundal/R_sep2015/Rrnaseq/RNAseq.html
> 
> Thanks a lot for your work! If needed I can provide  a Docker image that
> reproduces the problem.
> 
> Yours,
> Marcin
> 
>   [[alternative HTML version deleted]]
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] SV4Vectors installation problem

2015-10-15 Thread Marcin Cieślik 
Dear Bioconductors,

Somewhere in August S4Vectors stopped installing correctly resulting in a:

Creating a generic function for ‘nchar’ from package ‘base’ in package
‘S4Vectors’

message (that cannot be suppressed) each time the package is loaded. The
issue is not fixed by a fresh reinstall of bioconductor. The first hint of
the problem appears during installation

http://pastebin.com/UpKdeNTH

It appears I am not the only one affected a search reveals many instances:

e.g.
https://rpubs.com/Pazz/advanced_annotation
http://bioc.ism.ac.jp/packages/checkResults/3.1/bioc-LATEST/S4Vectors/petty-install.html
http://biocluster.ucr.edu/~rkaundal/R_sep2015/Rrnaseq/RNAseq.html

Thanks a lot for your work! If needed I can provide  a Docker image that
reproduces the problem.

Yours,
Marcin

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] New package: MEAL - Methylation and Expression AnaLyzer

2015-10-15 Thread Ruiz Arenas, Carlos 
Dear Bioconductor developers,

I am happy to present my new package, available with the new version of 
Bioconductor. 

MEAL is a package designed to integrate methylation and expression and to 
analyze both separately. Integration of these data types can be univariate or 
multivariate. The univariate approach consists on two steps. First, cpgs and 
expression probes are paired depending on their genomic position. Afterwards, a 
linear regression is performed, considering the expression the outcome and the 
methylation the independent variable. On the other hand, the multivariate 
approach is designed to study the correlation between methylation and 
expression in a given genomic region.

MEAL also can analyze methylation and expression separately. To do so, it 
includes the most common algorithms to analyze methylation and expression, 
including several region analysis such as Bumphunter or DMRcate. MEAL can also 
analyse methylation or expression in a given region, which could be of interest 
when studying genomic structural variants. Finally, it should be noticed that 
it includes the most common plots used in methylation and expression analysing, 
easing the process of presenting the results.

The last feature to be mentioned, it is the development of a new class 
(MultiDataSet) designed to handle different omics sets of common samples. At 
the moment, it implements some methods to add MethylationSet (class of MEAL), 
ExpressionSet and SnpSet as well as a generic function to add any eSet derived 
object. This design will allow the reuse of the class to other integration 
tasks by other developpers. 

I hope this package will be very useful for people working with methylation and 
expression and that it could be a good starting point for other integration 
techniques.

Bests,

Carlos Ruiz, Center for Research in Environmental Epidemiology (CREAL)

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] New package: FindMyFriends - Comparative microbial genomics

2015-10-15 Thread Thomas Lin Pedersen 
With the release of the new version of Bioconductor I would like to present my 
new package.

FindMyFriends is an extensible framework for generating and working with 
comparative microbial genomics data or, as it is often referred to, pangenomes. 
On the algorithm side, FindMyFriends offers a new approach to grouping genes 
from microbial genomes using a heuristic that allows for linear scaling of the 
computational time, as opposed to the quadratic scaling that almost all current 
tools have. Furthermore it provides a new post processing step for refining 
gene groups based on the flanking genes of each member of the group. Completely 
novel is a set of algorithm that works on a graph representation of the 
pangenome to identify chromosomal areas of high plasticity, such as 
insertion/deletion sites, frameshift events etc.

On the infrastructure side FindMyFriends supply an extensible class hierarchy 
that support annotation of gene groups, secondary grouping of groups, 
transparent link between groups and underlying raw data, numerous plot 
functions etc. Currently classes exist to deal with in-memory sequence data as 
well as sequences stored in fasta files, but due to way the classes are defined 
it is possible to extent it with classes that support any backend e.g. 
different databases…

I hope those of you working within microbial genomics will find it useful.

Best

Thomas Lin Pedersen, Technical University of Denmark
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel