[Bioperl-l] Re: Bioperl-l digest, Vol 1 #200 - 15 msgs
Yuandan Zhang
ydzhang@iastate.edu
Tue, 30 Jan 2001 08:44:25 -0600
Hi,
I am new to bioperl, very patinate in it. Is there any tutorial materials
available or any collection of example scripts for beginners to make a start?
Yuandan
At 04:17 AM 1/30/01 -0500, you wrote:
>Send Bioperl-l mailing list submissions to
> bioperl-l@bioperl.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://bioperl.org/mailman/listinfo/bioperl-l
>or, via email, send a message with subject or body 'help' to
> bioperl-l-request@bioperl.org
>
>You can reach the person managing the list at
> bioperl-l-admin@bioperl.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Bioperl-l digest..."
>
>
>Today's Topics:
>
> 1. Genscan exon frame computation (Hilmar Lapp)
> 2. LiveSeq back working (Joseph Insana)
> 3. SeqFeature::Generic broken? no Location::Simple.pm (Mark Wilkinson)
> 4. Re: SeqFeature::Generic broken? no Location::Simple.pm (Jason Stajich)
> 5. Re: LiveSeq back working (Jason Stajich)
> 6. Re: SeqFeature::Generic broken? no Location::Simple.pm (Ewan Birney)
> 7. Bio Framework and XML (Iain Darroch)
> 8. Bio::SeqFeature::Generic add_sub_SeqFeature (Jason Stajich)
> 9. Re: Bio::SeqFeature::Generic add_sub_SeqFeature (Hilmar Lapp)
> 10. Re: Bio::SeqFeature::Generic add_sub_SeqFeature (Jason Stajich)
> 11. Re: RetrictionEnzyme.pm: a proposal (Hilmar Lapp)
> 12. Re: missing use statements (Hilmar Lapp)
> 13. Root::Object in bioxml.pm (Hilmar Lapp)
> 14. Re: [Bioperl-guts-l] Notification: incoming/888 (Hilmar Lapp)
> 15. Re: Bio::SeqFeature::Generic add_sub_SeqFeature (Ewan Birney)
>
>--__--__--
>
>Message: 1
>Date: Mon, 29 Jan 2001 09:24:03 -0800
>From: Hilmar Lapp <hlapp@gmx.net>
>Organization: Nereis 4
>To: Bioperl <bioperl-l@bioperl.org>
>Subject: [Bioperl-l] Genscan exon frame computation
>
>A revisit of this is on the task list. I had a discussion a while
>ago with Mark Dalphin, because he claimed that he managed to
>figured out the exon frame based on start coordinate and frame
>value.
>
>I still don't fully understand his code sample, as he was also
>using his own definition of frame. Still, the discussion let me
>see how one can figure out the frame. I've enclosed the relevant
>code section of my implementation below. Whoever feels in the
>position please review and double-check.
>
>This will add a frame attribute to each individual exon, which
>makes it possible to deliberately shuffle exons from one
>prediction (for those who aren't aware: Genscan with default
>parameters outputs only exons in the 'optimal path'; there may be
>other exons which also achieve very good scores and the output of
>which can be triggered by -subopt).
>
>Things still to do in this respect comprise of a rigorous test
>(take all exons of each prediction, translate them individually in
>the frame they've been assigned, and check that there are no
>intervening stops) and an adaptation of cds() in GeneStructure.pm
>(when concatenating exons, make sure that the frame of one and
>frame/phase of the previous match, and if not, fill with Ns).
>
>If anyone volunteers to add the test to Genpred.t I'd be really
>glad. This does not involve module design, just plain application
>coding, and anyone literate in Perl/Bioperl should be able to jump
>in here.
>
>Comments welcome, esp. regarding the cds() comment I made above.
>
> Hilmar
>--
>-----------------------------------------------------------------
>Hilmar Lapp email: hlapp@gmx.net
>GNF, San Diego, Ca. 92122 phone: +1 858 812 1757
>-----------------------------------------------------------------
>
># Figure out the frame of this exon. This is NOT the frame
># given by Genscan, which is the absolute frame of the base
># starting the first predicted complete codon. By comparing
># to the absolute frame of the first base we can compute the
># offset of the first complete codon to the first base of the
># exon, which determines the frame of the exon.
>my $cod_offset;
>if($predobj->strand() == 1) {
> $cod_offset = $flds[6] - (($predobj->start()-1) % 3);
> # Possible values are -2, -1, 0, 1, 2. -1 and -2 correspond
> # to offsets 2 and 1, resp. Offset 3 is the same as 0.
> $cod_offset += 3 if($cod_offset < 1);
>} else {
> # On the reverse strand the Genscan frame also refers to
> # the first base of the first complete codon, but viewed
> # from forward, which is the third base viewed from
> # reverse.
> # Note that end() is in fact start() here because we always
> # annotate in forward direction (otherwise we wouldn't need
> # strand()).
> $cod_offset = $flds[6] - (($predobj->end()-3) % 3);
> # Possible values are -2, -1, 0, 1, 2. Due to the reverse
> # situation, {2,-1} and {1,-2} correspond to offsets
> # 1 and 2, resp. Offset 3 is the same as 0.
> $cod_offset -= 3 if($cod_offset >= 0);
> $cod_offset = -$cod_offset;
>}
># Offsets 2 and 1 correspond to frame 1 and 2 (frame of exon
># is the frame of the first base relative to the exon, or the
># number of bases the first codon is missing).
>$predobj->frame(3 - $cod_offset);
>
>--__--__--
>
>Message: 2
>Date: Mon, 29 Jan 2001 17:48:19 +0000 (GMT)
>From: Joseph Insana <insana@ebi.ac.uk>
>Reply-To: insana@ebi.ac.uk
>To: bioperl-l@bioperl.org
>Subject: [Bioperl-l] LiveSeq back working
>
>LiveSeq is back working now.
>The BioPerl loader was not working anymore because of the SplitLocation
>change. It was using the subfeature method.
>
>Joseph Insana
>
>
>--__--__--
>
>Message: 3
>Date: Mon, 29 Jan 2001 11:38:24 -0600
>From: Mark Wilkinson <mwilkinson@gene.pbi.nrc.ca>
>Organization: PBI-NRC
>To: bioperl-l@bioperl.org
>Subject: [Bioperl-l] SeqFeature::Generic broken? no Location::Simple.pm
>
>Dear Group,
>
>I just cvs-updated and noticed that SeqFeature::Generic does not appear
>to be functional anymore. It is calling on Bio/Location/Simple.pm
>(line 122), which apparently does not exist. Is it just my installation
>which is wonky, or is this a genuine bug?
>
>any advice appreciated.
>
>cheers all!
>
>M
>
>
>--
>---
>Dr. Mark Wilkinson
>Bioinformatics Group
>National Research Council of Canada
>Plant Biotechnology Institute
>110 Gymnasium Place
>Saskatoon, SK
>Canada
>
>
>
>
>--__--__--
>
>Message: 4
>Date: Mon, 29 Jan 2001 13:05:34 -0500 (EST)
>From: Jason Stajich <jason@chg.mc.duke.edu>
>To: Mark Wilkinson <mwilkinson@gene.pbi.nrc.ca>
>cc: bioperl-l@bioperl.org
>Subject: Re: [Bioperl-l] SeqFeature::Generic broken? no Location::Simple.pm
>
>you need to do
>% cvs update -d
>to get newly created directories.
>
>On Mon, 29 Jan 2001, Mark Wilkinson wrote:
>
> > Dear Group,
> >
> > I just cvs-updated and noticed that SeqFeature::Generic does not appear
> > to be functional anymore. It is calling on Bio/Location/Simple.pm
> > (line 122), which apparently does not exist. Is it just my installation
> > which is wonky, or is this a genuine bug?
> >
> > any advice appreciated.
> >
> > cheers all!
> >
> > M
> >
> >
> > --
> > ---
> > Dr. Mark Wilkinson
> > Bioinformatics Group
> > National Research Council of Canada
> > Plant Biotechnology Institute
> > 110 Gymnasium Place
> > Saskatoon, SK
> > Canada
> >
> >
> >
> > _______________________________________________
> > Bioperl-l mailing list
> > Bioperl-l@bioperl.org
> > http://bioperl.org/mailman/listinfo/bioperl-l
> >
>
>Jason Stajich
>jason@chg.mc.duke.edu
>Center for Human Genetics
>Duke University Medical Center
>http://www.chg.duke.edu/
>
>
>
>--__--__--
>
>Message: 5
>Date: Mon, 29 Jan 2001 13:05:59 -0500 (EST)
>From: Jason Stajich <jason@chg.mc.duke.edu>
>To: Joseph Insana <insana@ebi.ac.uk>
>cc: bioperl-l@bioperl.org
>Subject: Re: [Bioperl-l] LiveSeq back working
>
>Thanks for fixing this, I wasn't sure where to go to look.
>
>On Mon, 29 Jan 2001, Joseph Insana wrote:
>
> > LiveSeq is back working now.
> > The BioPerl loader was not working anymore because of the SplitLocation
> > change. It was using the subfeature method.
> >
> > Joseph Insana
> >
> > _______________________________________________
> > Bioperl-l mailing list
> > Bioperl-l@bioperl.org
> > http://bioperl.org/mailman/listinfo/bioperl-l
> >
>
>Jason Stajich
>jason@chg.mc.duke.edu
>Center for Human Genetics
>Duke University Medical Center
>http://www.chg.duke.edu/
>
>
>
>--__--__--
>
>Message: 6
>Date: Mon, 29 Jan 2001 18:14:14 +0000 (GMT)
>From: Ewan Birney <birney@ebi.ac.uk>
>To: Mark Wilkinson <mwilkinson@gene.pbi.nrc.ca>
>cc: bioperl-l@bioperl.org
>Subject: Re: [Bioperl-l] SeqFeature::Generic broken? no Location::Simple.pm
>
>On Mon, 29 Jan 2001, Mark Wilkinson wrote:
>
> > Dear Group,
> >
> > I just cvs-updated and noticed that SeqFeature::Generic does not appear
> > to be functional anymore. It is calling on Bio/Location/Simple.pm
> > (line 122), which apparently does not exist. Is it just my installation
> > which is wonky, or is this a genuine bug?
>
>
>cvs update -d
>
>
> >
> > any advice appreciated.
> >
> > cheers all!
> >
> > M
> >
> >
> > --
> > ---
> > Dr. Mark Wilkinson
> > Bioinformatics Group
> > National Research Council of Canada
> > Plant Biotechnology Institute
> > 110 Gymnasium Place
> > Saskatoon, SK
> > Canada
> >
> >
> >
> > _______________________________________________
> > Bioperl-l mailing list
> > Bioperl-l@bioperl.org
> > http://bioperl.org/mailman/listinfo/bioperl-l
> >
>
>-----------------------------------------------------------------
>Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
><birney@ebi.ac.uk>.
>-----------------------------------------------------------------
>
>
>--__--__--
>
>Message: 7
>Date: Mon, 29 Jan 2001 18:40:07 +0000 (GMT)
>From: Iain Darroch <darrochi@dcs.gla.ac.uk>
>To: bioperl-l@bioperl.org
>Subject: [Bioperl-l] Bio Framework and XML
>
>Hi All,
>
>I am currently looking at ways of integrating biological systems. I saw
>mentioned in some of the documentation that a Bio-Object Framework was
>proposed. Also that XML could be used in meta data for describing
>bioinformatics objects.
>
>I was wondering what the current situation of both these were.
>
>Has anyone implemented parsers yet?
>
>Thanks in advance
>
>Iain
>
>
>
>
>--__--__--
>
>Message: 8
>Date: Mon, 29 Jan 2001 14:33:59 -0500 (EST)
>From: Jason Stajich <jason@chg.mc.duke.edu>
>To: Bioperl <bioperl-l@bioperl.org>
>Subject: [Bioperl-l] Bio::SeqFeature::Generic add_sub_SeqFeature
>
>What is the feeling here, we have this old way of doing things which
>included using the value 'EXPAND' to determine if we should expand the
>start/end space for a feature when adding a sub_SeqFeature to a feature?
>
>I think this should likely be better modeled through a SplitLocationI
>which is just a container of LocationObjects. So I propose to remove all
>references to 'EXPAND' which means removing the method _expand_region and
>updating add_sub_Feature to deal with adding the locations. Similarly the
>flush_sub_SeqFeature should flush the locations, but I'm not sure about
>what the start/end should be reset to...
>
>I also had to update FeaturePair to add the method location() which
>delegates to feature1()->location() otherwise things won't work correctly.
>start/end are defined by feature1 object so location should also reside
>in feature1.
>
>Jason
>
>Jason Stajich
>jason@chg.mc.duke.edu
>Center for Human Genetics
>Duke University Medical Center
>http://www.chg.duke.edu/
>
>
>
>
>--__--__--
>
>Message: 9
>Date: Mon, 29 Jan 2001 13:09:40 -0800
>From: Hilmar Lapp <lapp@gnf.org>
>Organization: GNF
>To: Jason Stajich <jason@chg.mc.duke.edu>
>Cc: Bioperl <bioperl-l@bioperl.org>
>Subject: Re: [Bioperl-l] Bio::SeqFeature::Generic add_sub_SeqFeature
>
>Jason Stajich wrote:
> >
> > What is the feeling here, we have this old way of doing things which
> > included using the value 'EXPAND' to determine if we should expand the
> > start/end space for a feature when adding a sub_SeqFeature to a feature?
> >
> > I think this should likely be better modeled through a SplitLocationI
> > which is just a container of LocationObjects. So I propose to remove all
> > references to 'EXPAND' which means removing the method _expand_region and
> > updating add_sub_Feature to deal with adding the locations. Similarly
>
>Can't we keep a separate method for coping with region extension due
>to a new subfeature, in whatever way the extension is done? As far as
>I can remember I had a good reason to put it into its own method, I
>needed it separately from add_sub_SeqFeature().
>
> Hilmar
>--
>-------------------------------------------------------------
>Hilmar Lapp email: lapp@gnf.org
>GNF, San Diego, Ca. 92121 phone: +1-858-812-1757
>-------------------------------------------------------------
>
>--__--__--
>
>Message: 10
>Date: Mon, 29 Jan 2001 16:26:21 -0500 (EST)
>From: Jason Stajich <jason@chg.mc.duke.edu>
>To: Hilmar Lapp <lapp@gnf.org>
>cc: Bioperl <bioperl-l@bioperl.org>
>Subject: Re: [Bioperl-l] Bio::SeqFeature::Generic add_sub_SeqFeature
>
>On Mon, 29 Jan 2001, Hilmar Lapp wrote:
>
> > Jason Stajich wrote:
> > >
> > > What is the feeling here, we have this old way of doing things which
> > > included using the value 'EXPAND' to determine if we should expand the
> > > start/end space for a feature when adding a sub_SeqFeature to a feature?
> > >
> > > I think this should likely be better modeled through a SplitLocationI
> > > which is just a container of LocationObjects. So I propose to remove all
> > > references to 'EXPAND' which means removing the method _expand_region and
> > > updating add_sub_Feature to deal with adding the locations. Similarly
> >
> > Can't we keep a separate method for coping with region extension due
> > to a new subfeature, in whatever way the extension is done? As far as
> > I can remember I had a good reason to put it into its own method, I
> > needed it separately from add_sub_SeqFeature().
>
>I guess it is more sane to let SeqFeature::Generic handle the common case
>and the split location case will need to be handled elsewhere.
>
>In the special case of a feature with multiple locations that feature (or
>object creating it) will take care of updating the location object to
>point to a splitlocation object. For example, if we choose to have CDS be
>represented as a SplitLocation with the exons being the parts in the
>join(...) statement. This will have to be negotiated by the object
>creating the Gene/CDS object.
>
>Okay so no changes to check in for Generic.
>
> >
> > Hilmar
> > --
> > -------------------------------------------------------------
> > Hilmar Lapp email: lapp@gnf.org
> > GNF, San Diego, Ca. 92121 phone: +1-858-812-1757
> > -------------------------------------------------------------
> > _______________________________________________
> > Bioperl-l mailing list
> > Bioperl-l@bioperl.org
> > http://bioperl.org/mailman/listinfo/bioperl-l
> >
>
>Jason Stajich
>jason@chg.mc.duke.edu
>Center for Human Genetics
>Duke University Medical Center
>http://www.chg.duke.edu/
>
>
>
>--__--__--
>
>Message: 11
>Date: Mon, 29 Jan 2001 13:57:13 -0800
>From: Hilmar Lapp <lapp@gnf.org>
>Organization: GNF
>To: Paul-Christophe Varoutas <paul-christophe.varoutas@curie.fr>
>Cc: bioperl-l@bioperl.org
>Subject: Re: [Bioperl-l] RetrictionEnzyme.pm: a proposal
>
>Paul-Christophe Varoutas wrote:
> >
> > Tell me what you think about it:
> > - First of all, is redesigning possible or are we obliged to maintain
> > compatibility ? In the latter case I will just add functionality,
> > maintaining the poor design of the module.
> > - If redesigning is possible, please make comments/suggestions.
> >
>
>First of all, keeping compatibility is a very good thing. Every user
>of your software will appreciate it if he/she knows that this is taken
>seriously.
>
>In general, my opinion is if there's no strong reason to break
>compatibility, then don't break it. On the other hand, if there is a
>good reason, then don't hesitate.
>
>This means, yes, redesigning is possible, but a nicer design by itself
>is not a good reason to break compatibility. If the existing design is
>sort of prohibitive for adding certain new functionality, this might
>justify breaking compatibility. An example is the new location model,
>but in fact Jason could manage to keep compatibility. I suggest that
>you carefully examine whether you indeed can't redesign and at the
>same time keep compatibility. Based on your proposal I don't see the
>prohibitive point yet.
>
>As for the release, this issue is not on the task list, which means
>that you are on your own. There's a deadline next week, and we don't
>want to lose focus. If you finish the code and submit an accompanying
>rigorous test in t/* on time, it can make it into the release though,
>provided that there are no objections should you introduce
>incompatibilities.
>
>As a last remark, a design that isn't prepared very well for an
>extension one has in mind is not necessarily poor. It may just have
>been perfect for its original scope. And: I really think that there is
>no such thing as a "correct" design. Design may be bad or may be good,
>generic or tailored, or whatever, it just depends on your viewpoint,
>that is, on the particular problem you want to solve.
>
> Hilmar
>--
>-------------------------------------------------------------
>Hilmar Lapp email: lapp@gnf.org
>GNF, San Diego, Ca. 92121 phone: +1-858-812-1757
>-------------------------------------------------------------
>
>--__--__--
>
>Message: 12
>Date: Mon, 29 Jan 2001 23:02:45 -0800
>From: Hilmar Lapp <hlapp@gmx.net>
>Organization: Nereis 4
>To: Bioperl <bioperl-l@bioperl.org>
>Subject: Re: [Bioperl-l] missing use statements
>
>Paul-Christophe Varoutas wrote:
> >
> > so I just added one line at the beginning of the module to load Bio::Seq:
> >
> > use Bio::Seq;
> >
>
>Thanks for pointing this out. The reason this became necessary all
>of a sudden was probably that I removed the respective lines from
>SeqIO.pm, because there was no obvious reason to keep them. Since
>I still think that the 'use' statements are better in those files
>where the modules are really used, I left it that way and added
>the necessary use statements to all other SeqIO modules (which
>probably would all have complained sooner or later).
>
> > and edited the @ISA array initialization line:
> >
> > @ISA = qw(Bio::SeqIO Bio::Seq);
> >
>
>We don't want SeqIO modules to inherit from Bio::Seq.
>
> Hilmar
>--
>-----------------------------------------------------------------
>Hilmar Lapp email: hlapp@gmx.net
>GNF, San Diego, Ca. 92122 phone: +1 858 812 1757
>-----------------------------------------------------------------
>
>--__--__--
>
>Message: 13
>Date: Mon, 29 Jan 2001 23:04:21 -0800
>From: Hilmar Lapp <hlapp@gmx.net>
>Organization: Nereis 4
>To: Bioperl <bioperl-l@bioperl.org>
>CC: Jason Stajich <jason@chg.mc.duke.edu>
>Subject: [Bioperl-l] Root::Object in bioxml.pm
>
>SeqIO::bioxml.pm still inherits from Root::Object. Is there a
>particular reason that this one's an exception?
>
> Hilmar
>--
>-----------------------------------------------------------------
>Hilmar Lapp email: hlapp@gmx.net
>GNF, San Diego, Ca. 92122 phone: +1 858 812 1757
>-----------------------------------------------------------------
>
>--__--__--
>
>Message: 14
>Date: Mon, 29 Jan 2001 23:10:26 -0800
>From: Hilmar Lapp <hlapp@gmx.net>
>Organization: Nereis 4
>To: Mark Wilkinson <mwilkinson@gene.pbi.nrc.ca>
>CC: bioperl-l@bioperl.org
>Subject: [Bioperl-l] Re: [Bioperl-guts-l] Notification: incoming/888
>
>bioperl-bugs@bioperl.org wrote:
> >
> > Generic Features created from a GFF string do not
> > record Frame information, and when dumping the feature
> > out as GFF it is invariably reported as frame = 0.
> >
> > The problem is multi-fold:
> >
> > (1) the _from_gff_string and _from_gff2_string
> > subroutines in Generic.pm do not contain any code to handle the
> > recording of Frame information in the feature object
> >
> > (2) GFF allows a "." as the frame (meaning info not available),
> > while $Feature only allows 0,1, or 2. Thus it isn't clear how a
> > GFF frame of "." should be recorded. My first thought was that a
> > value of undef might return "." in a call to SeqFeatureI::gff_string,
> > however...
> >
> > (3) ...it appears that even if there is no frame information
> > available in a Feature object, it nevertheless passes the
> > $Feature->can('frame') test in SeqFeatureI::gff_string
> > and returns a (default??) value of 0 for the $Feature->frame call
> > (though there *is* code there to assign the frame to
> > "." if it fails the ->can test...)
> >
> > I am willing to fix this problem myself, but I would appreciate having
> > a consensus from the group about which level of the problem needs to be
> > fixed to keep everyone else's code happy.
> >
>
>I think that frame information should be consistent between GFF
>representation and object representation. '.' is equivalent to
>undef, and otherwise the frame should be 0, 1, or 2, regardless of
>object or GFF string.
>
> Hilmar
>
>--
>-----------------------------------------------------------------
>Hilmar Lapp email: hlapp@gmx.net
>GNF, San Diego, Ca. 92122 phone: +1 858 812 1757
>-----------------------------------------------------------------
>
>--__--__--
>
>Message: 15
>Date: Tue, 30 Jan 2001 09:14:42 +0000 (GMT)
>From: Ewan Birney <birney@ebi.ac.uk>
>To: Jason Stajich <jason@chg.mc.duke.edu>
>cc: Bioperl <bioperl-l@bioperl.org>
>Subject: Re: [Bioperl-l] Bio::SeqFeature::Generic add_sub_SeqFeature
>
>On Mon, 29 Jan 2001, Jason Stajich wrote:
>
> > What is the feeling here, we have this old way of doing things which
> > included using the value 'EXPAND' to determine if we should expand the
> > start/end space for a feature when adding a sub_SeqFeature to a feature?
> >
> > I think this should likely be better modeled through a SplitLocationI
> > which is just a container of LocationObjects. So I propose to remove all
> > references to 'EXPAND' which means removing the method _expand_region and
> > updating add_sub_Feature to deal with adding the locations. Similarly the
> > flush_sub_SeqFeature should flush the locations, but I'm not sure about
> > what the start/end should be reset to...
>
>I guess agree (I am wincing at every one of these decisions you know. It
>just pains me to see us have to handle this object complexity in
>essentially simple objects. Bugger-it! I know there is no way out here,
>but .... it goes against the grain).
>
> >
> > I also had to update FeaturePair to add the method location() which
> > delegates to feature1()->location() otherwise things won't work correctly.
> > start/end are defined by feature1 object so location should also reside
> > in feature1.
> >
>
>That is the consistent route here...
>
>
> > Jason
> >
> > Jason Stajich
> > jason@chg.mc.duke.edu
> > Center for Human Genetics
> > Duke University Medical Center
> > http://www.chg.duke.edu/
> >
> >
> >
> > _______________________________________________
> > Bioperl-l mailing list
> > Bioperl-l@bioperl.org
> > http://bioperl.org/mailman/listinfo/bioperl-l
> >
>
>-----------------------------------------------------------------
>Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
><birney@ebi.ac.uk>.
>-----------------------------------------------------------------
>
>
>
>--__--__--
>
>_______________________________________________
>Bioperl-l mailing list
>Bioperl-l@bioperl.org
>http://bioperl.org/mailman/listinfo/bioperl-l
>
>
>End of Bioperl-l Digest
--
Yuandan Zhang