[Bioperl-l] Bug #2936

[Francisco J. Ossandón]

Ok,  I did the changes and added a pull request in the repository. All the
tests in "t/Seq/PrimarySeq.t" keeps passing (except the TODOs), including
the ones I added. Everything seems fine on my end.

About the Location/Split module, the lines that I don’t agree at all are the
ones that reverse the segment order in to_FTstring:
	# If the split type is join, the order is important;
	# otherwise must be 5'->3' regardless
	my @locs = ($stype eq 'join' && (!$guide && $strand == -1)) ?
	           reverse $self->sub_Location() : $self->sub_Location() ;

It don’t make sense to me to do that, because doing that you get coordinates
that will NOT give you the expected nucleotide sequence. Another thing that
is weird to me is that the sublocations are free to have different strands
values (like the first being positive strand and the second being negative
strand), since I can't think of one example where that can happen in real
genomes. In fact one of the tests in PrimarySeq.t is designed exactly to
have sublocations in opposite strands at the same time and then extract the
sequence, so I wonder if I'm wrong and there are real cases like that...

As you say, those things would have to wait until later, but at least this
particular bug should be closed. =)

Regards,

Francisco J. Ossandon

-----Mensaje original-----
De: bioperl-l-bounces at lists.open-bio.org
[mailto:bioperl-l-bounces at lists.open-bio.org] En nombre de Fields,
Christopher J
Enviado el: viernes, 15 de marzo de 2013 11:46
Para: Francisco J. Ossandón
CC: bioperl mailing list
Asunto: Re: [Bioperl-l] Bug #2936

Sure, a pull request would be good.  I suggest making sure you are in sync
with the 'master' branch first, but I don't think you'll run into conflicts
with that.  

My guess is we'll need to pull this into a branch and test rigorously first
if it is to go into a bioperl 1.6.  One of the (many?) problems with
Bio::Location is that it assumes all features are on linear chromosomes, so
there is quite a bit of logic/magic built-in with that assumption that tends
to be wrong (e.g. sort order of sublocations and so on, which breaks split
locations).  

Frankly, I think we could really simplify this logic so that it is less
magic, less fuzzy, and it would bite us in the ass a lot less, but of course
this breaks backcompat.  So, my feeling is such fixes would be handled
better in a BioPerl v2.

chris

On Mar 15, 2013, at 9:26 AM, Francisco J. Ossandón <fossandonc at hotmail.com>
wrote:

> Hello,
> 
> Around 2 weeks ago I posted comments and a fix for Bug #2936, but 
> haven't received any feedback yet.
> 
> https://redmine.open-bio.org/issues/2936
> 
> 
> 
> Probably everybody is busy, so I would like to ask only if the 
> proposed fix is acceptable. If the fix were fine, I could prepare 
> changes in my forked repo, add tests (in "t/Seq/PrimarySeq.t"???) and 
> make a pull request. What do you think?
> 
> 
> 
> Cheers,
> 
> 
> 
> --
> 
> Francisco J. Ossandon
> 
> Bioinformatician.
> 
> Ph.D. Candidate, University Andres Bello.
> 
> Center for Bioinformatics and Genome Biology,
> 
> Fundacion Ciencia para la Vida.
> 
> Santiago, Chile.
> 
> <http://www.cienciavida.cl/CBGB.htm> www.cienciavida.cl/CBGB.htm
> 
> 
> 
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l


_______________________________________________
Bioperl-l mailing list
Bioperl-l at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/bioperl-l