From gwaldon at geneinfinity.org Thu Nov 2 10:47:28 2006 From: gwaldon at geneinfinity.org (george waldon) Date: Thu, 02 Nov 2006 07:47:28 -0800 Subject: [Biojava-dev] Problems with RichLocations Message-ID: <200611021547.kA2FlS6E086701@mmm1924.dulles19-verio.com> Hello, I think I found some potential problems with RichLocation. In RichLocation.Tools.construct(Collection members) the merging is apparently missing. Biojavax always calls merging before construct but the javadoc indicates logically that merging should be done inside the body of the method. In CompoundRichLocation, blocIterator should return an iterator over contiguous blocs sorted in ascending order according to Location javadoc. It does not seem that the list of members is sorted. In RichLocation.Tools.flatten(Collection members), members are checked for being instance of SimpleRichLocation. This does not sound correct. First, SimpleRichLocation is not an interface and therefore there is no contract with it and it should not be here; secondly compound members are probably instance of CompoundRichLocation which extends SimpleRichLocation and therefore these compound members are not flattened. In RichLocation.Tools.modulateCircularLocation(int start, int end, int seqLength), end could be far up and we are probably missing something like while (locationLength>=seqLength) locationLength-=seqLength; Hope this helps. Thanks, George From holland at ebi.ac.uk Thu Nov 2 11:35:10 2006 From: holland at ebi.ac.uk (Richard Holland) Date: Thu, 02 Nov 2006 16:35:10 +0000 Subject: [Biojava-dev] Problems with RichLocations In-Reply-To: <200611021547.kA2FlS6E086701@mmm1924.dulles19-verio.com> References: <200611021547.kA2FlS6E086701@mmm1924.dulles19-verio.com> Message-ID: <454A1E3E.2040101@ebi.ac.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for pointing this out. > In RichLocation.Tools.construct(Collection members) the merging is apparently missing. Biojavax always calls merging before construct but the javadoc indicates logically that merging should be done inside the body of the method. The JavaDocs were wrong. There are instances (GenbankFormat etc.) where we need to construct without merging. Therefore, merging is always left to the caller. I have amended the JavaDocs to remove this ambiguity. > In CompoundRichLocation, blocIterator should return an iterator over contiguous blocs sorted in ascending order according to Location javadoc. It does not seem that the list of members is sorted. I've altered this now and it will return sorted blocks. > In RichLocation.Tools.flatten(Collection members), members are checked for being instance of SimpleRichLocation. This does not sound correct. First, SimpleRichLocation is not an interface and therefore there is no contract with it and it should not be here; secondly compound members are probably instance of CompoundRichLocation which extends SimpleRichLocation and therefore these compound members are not flattened. Oops! Fixed now. > In RichLocation.Tools.modulateCircularLocation(int start, int end, int seqLength), end could be far up and we are probably missing something like > while (locationLength>=seqLength) locationLength-=seqLength; This is deliberate, as circular locations are allowed to wrap round and cover the entire sequence as many times as they like. Therefore modulateCircularLocation is supposed to return a location of identical length, just translated so that start is before end and that start is as close to the actual start of the sequence as possible, in order to make it easier for the subsequence methods to work out how to extract circular sequence. (in the resulting coordinates, start will lie within the sequence but end could be far far beyond the actual end of the sequence, which will be interpreted as wrapping round and starting again from the beginning). > Hope this helps. It did! :) All above fixes are in CVS. cheers, Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFSh494C5LeMEKA/QRAixVAJ0a6rF+/sdG/8P+FfVBrF3i78OuagCePThK nVT3GCpLl4AeHBnobZD9zDE= =/CAn -----END PGP SIGNATURE----- From markjschreiber at gmail.com Thu Nov 2 21:40:13 2006 From: markjschreiber at gmail.com (Mark Schreiber) Date: Fri, 3 Nov 2006 10:40:13 +0800 Subject: [Biojava-dev] Problems with RichLocations In-Reply-To: <454A1E3E.2040101@ebi.ac.uk> References: <200611021547.kA2FlS6E086701@mmm1924.dulles19-verio.com> <454A1E3E.2040101@ebi.ac.uk> Message-ID: <93b45ca50611021840t1be692f9x1c2db0d3b657ca67@mail.gmail.com> This is one area where we don't have many unit tests: Volunteers??? On 11/3/06, Richard Holland wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thanks for pointing this out. > > > In RichLocation.Tools.construct(Collection members) the merging is apparently missing. Biojavax always calls merging before construct but the javadoc indicates logically that merging should be done inside the body of the method. > > The JavaDocs were wrong. There are instances (GenbankFormat etc.) where > we need to construct without merging. Therefore, merging is always left > to the caller. I have amended the JavaDocs to remove this ambiguity. > > > In CompoundRichLocation, blocIterator should return an iterator over contiguous blocs sorted in ascending order according to Location javadoc. It does not seem that the list of members is sorted. > > I've altered this now and it will return sorted blocks. > > > In RichLocation.Tools.flatten(Collection members), members are checked for being instance of SimpleRichLocation. This does not sound correct. First, SimpleRichLocation is not an interface and therefore there is no contract with it and it should not be here; secondly compound members are probably instance of CompoundRichLocation which extends SimpleRichLocation and therefore these compound members are not flattened. > > Oops! Fixed now. > > > In RichLocation.Tools.modulateCircularLocation(int start, int end, int seqLength), end could be far up and we are probably missing something like > > while (locationLength>=seqLength) locationLength-=seqLength; > > This is deliberate, as circular locations are allowed to wrap round and > cover the entire sequence as many times as they like. Therefore > modulateCircularLocation is supposed to return a location of identical > length, just translated so that start is before end and that start is as > close to the actual start of the sequence as possible, in order to make > it easier for the subsequence methods to work out how to extract > circular sequence. (in the resulting coordinates, start will lie within > the sequence but end could be far far beyond the actual end of the > sequence, which will be interpreted as wrapping round and starting again > from the beginning). > > > Hope this helps. > > It did! :) All above fixes are in CVS. > > cheers, > Richard > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFFSh494C5LeMEKA/QRAixVAJ0a6rF+/sdG/8P+FfVBrF3i78OuagCePThK > nVT3GCpLl4AeHBnobZD9zDE= > =/CAn > -----END PGP SIGNATURE----- > _______________________________________________ > biojava-dev mailing list > biojava-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biojava-dev > From Robin.Emig at pioneer.com Wed Nov 8 17:27:56 2006 From: Robin.Emig at pioneer.com (Emig, Robin) Date: Wed, 8 Nov 2006 14:27:56 -0800 Subject: [Biojava-dev] Alignment SmithWaterman and NW In-Reply-To: <93b45ca50611021840t1be692f9x1c2db0d3b657ca67@mail.gmail.com> Message-ID: I just test out the alignment procedure in biojava and found a possible issue. When aligning two sequences, I get an alignment which contains gaps at the same position in both sequences. This seems strange to me, can it be correct? -Robin This communication is for use by the intended recipient and contains information that may be Privileged, confidential or copyrighted under applicable law. If you are not the intended recipient, you are hereby formally notified that any use, copying or distribution of this e-mail, in whole or in part, is strictly prohibited. Please notify the sender by return e-mail and delete this e-mail from your system. Unless explicitly and conspicuously designated as "E-Contract Intended", this e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer. This e-mail does not constitute a consent to the use of sender's contact information for direct marketing purposes or for transfers of data to third parties. Francais Deutsch Italiano Espanol Portugues Japanese Chinese Korean http://www.DuPont.com/corp/email_disclaimer.html From mark.schreiber at novartis.com Wed Nov 8 20:55:37 2006 From: mark.schreiber at novartis.com (mark.schreiber at novartis.com) Date: Thu, 9 Nov 2006 09:55:37 +0800 Subject: [Biojava-dev] Alignment SmithWaterman and NW Message-ID: Hi Robin - >From my understanding of NW and SW this should not happen. Can you log this in Bugzilla (from the www.biojava.org page). - Mark Mark Schreiber Research Investigator (Bioinformatics) Novartis Institute for Tropical Diseases (NITD) 10 Biopolis Road #05-01 Chromos Singapore 138670 www.nitd.novartis.com www.dengueinfo.org phone +65 6722 2973 fax +65 6722 2910 "Emig, Robin" Sent by: biojava-dev-bounces at lists.open-bio.org 11/09/2006 06:27 AM To: cc: , (bcc: Mark Schreiber/GP/Novartis) Subject: [Biojava-dev] Alignment SmithWaterman and NW I just test out the alignment procedure in biojava and found a possible issue. When aligning two sequences, I get an alignment which contains gaps at the same position in both sequences. This seems strange to me, can it be correct? -Robin This communication is for use by the intended recipient and contains information that may be Privileged, confidential or copyrighted under applicable law. If you are not the intended recipient, you are hereby formally notified that any use, copying or distribution of this e-mail, in whole or in part, is strictly prohibited. Please notify the sender by return e-mail and delete this e-mail from your system. Unless explicitly and conspicuously designated as "E-Contract Intended", this e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer. This e-mail does not constitute a consent to the use of sender's contact information for direct marketing purposes or for transfers of data to third parties. Francais Deutsch Italiano Espanol Portugues Japanese Chinese Korean http://www.DuPont.com/corp/email_disclaimer.html _______________________________________________ biojava-dev mailing list biojava-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/biojava-dev From sylvain.foisy at diploide.net Wed Nov 8 20:03:03 2006 From: sylvain.foisy at diploide.net (Sylvain Foisy) Date: Wed, 08 Nov 2006 20:03:03 -0500 Subject: [Biojava-dev] Alignment SmithWaterman and NW In-Reply-To: Message-ID: Hi, This might be a stupid question but have you tried these same sequences using EMBOSS' water and needle with the same parameters? If you get the same output, it might be the sequences themselves. Best regards Sylvain On 08/11/06 17:27, "Emig, Robin" wrote: > I just test out the alignment procedure in biojava and found a > possible issue. When aligning two sequences, I get an alignment which > contains gaps at the same position in both sequences. This seems strange > to me, can it be correct? =================================================================== Sylvain Foisy, Ph. D. Consultant Diploide.net - TI pour la vie / IT for Life Courriel: sylvain.foisy at diploide.net =================================================================== From Robin.Emig at pioneer.com Fri Nov 10 21:00:43 2006 From: Robin.Emig at pioneer.com (Emig, Robin) Date: Fri, 10 Nov 2006 18:00:43 -0800 Subject: [Biojava-dev] Alignment SmithWaterman and NW In-Reply-To: Message-ID: After tracking this down farther, I found the problem to be that my sequences already had gaps in them before I did the alignment and the tools in biojava treat gap, basically, like another symbol. Running the same search on EMBOSS returns a correct result (water/needle) because it removes/ignores gaps before doing the alignment. Thanks, robin -----Original Message----- From: biojava-dev-bounces at lists.open-bio.org [mailto:biojava-dev-bounces at lists.open-bio.org] On Behalf Of Sylvain Foisy Sent: Wednesday, November 08, 2006 5:03 PM To: Emig, Robin Cc: biojava-dev at lists.open-bio.org Subject: Re: [Biojava-dev] Alignment SmithWaterman and NW Hi, This might be a stupid question but have you tried these same sequences using EMBOSS' water and needle with the same parameters? If you get the same output, it might be the sequences themselves. Best regards Sylvain On 08/11/06 17:27, "Emig, Robin" wrote: > I just test out the alignment procedure in biojava and found a > possible issue. When aligning two sequences, I get an alignment which > contains gaps at the same position in both sequences. This seems > strange to me, can it be correct? =================================================================== Sylvain Foisy, Ph. D. Consultant Diploide.net - TI pour la vie / IT for Life Courriel: sylvain.foisy at diploide.net =================================================================== _______________________________________________ biojava-dev mailing list biojava-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/biojava-dev This communication is for use by the intended recipient and contains information that may be Privileged, confidential or copyrighted under applicable law. If you are not the intended recipient, you are hereby formally notified that any use, copying or distribution of this e-mail, in whole or in part, is strictly prohibited. Please notify the sender by return e-mail and delete this e-mail from your system. Unless explicitly and conspicuously designated as "E-Contract Intended", this e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer. This e-mail does not constitute a consent to the use of sender's contact information for direct marketing purposes or for transfers of data to third parties. Francais Deutsch Italiano Espanol Portugues Japanese Chinese Korean http://www.DuPont.com/corp/email_disclaimer.html From bugzilla-daemon at portal.open-bio.org Wed Nov 15 15:58:52 2006 From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org) Date: Wed, 15 Nov 2006 15:58:52 -0500 Subject: [Biojava-dev] [Bug 2144] New: LayeredRenderer not handling OverlayMarkers Message-ID: http://bugzilla.open-bio.org/show_bug.cgi?id=2144 Summary: LayeredRenderer not handling OverlayMarkers Product: BioJava Version: 1.4 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: seq AssignedTo: biojava-dev at biojava.org ReportedBy: jbdamask at earthlink.net Adding OverlayRendererWrappers to SequenceRenderers which eventually are placed onto a MultiLineRenderer causes extra whitespace in the rendered depth. This is due to LayeredRenderer's getDepth method line: depth += sRend.getDepth(src); To fix, add a conditional as follows: if(sRend instanceof OverlayMarker){ depth += 0.0; // maybe just do nothing here }else { depth += sRend.getDepth(src); } -- Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at portal.open-bio.org Thu Nov 16 04:33:48 2006 From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org) Date: Thu, 16 Nov 2006 04:33:48 -0500 Subject: [Biojava-dev] [Bug 2144] LayeredRenderer not handling OverlayMarkers In-Reply-To: Message-ID: <200611160933.kAG9XmPo021443@portal.open-bio.org> http://bugzilla.open-bio.org/show_bug.cgi?id=2144 holland at ebi.ac.uk changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #1 from holland at ebi.ac.uk 2006-11-16 04:33 ------- Accepted proposed fix. Committed to HEAD. -- Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at portal.open-bio.org Sun Nov 26 02:19:35 2006 From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org) Date: Sun, 26 Nov 2006 02:19:35 -0500 Subject: [Biojava-dev] [Bug 2150] New: RichStreamReader.nextBioEntry() call this.nextBioEntry() Message-ID: show_bug.cgi?id=2150 Summary: RichStreamReader.nextBioEntry() call this.nextBioEntry() Product: BioJava Version: live (CVS source) Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: seq.io AssignedTo: biojava-dev at biojava.org ReportedBy: jdiminic at gmail.com My code in biojava 1.5 beta: String fasta = ... // same fasta string Namespace ns = RichObjectFactory.getDefaultNamespace(); StringReader r = new StringReader(fasta); BufferedReader re = new BufferedReader(r); RichSequenceIterator readFasta = IOTools.readFastaDNA(re, ns); I got Exception: exception in thread "main" java.lang.StackOverflowError at org.biojavax.bio.seq.io.RichStreamReader.nextBioEntry(RichStreamReader.java:98) i will see that in org.biojavax.bio.seq.io.RichStreamReader ili line 98 method call same own method and got StackOverflowError. /** * {@inheritDoc} */ public BioEntry nextBioEntry() throws NoSuchElementException, BioException { return this.nextBioEntry(); } -- Configure bugmail: userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at portal.open-bio.org Mon Nov 27 04:29:59 2006 From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org) Date: Mon, 27 Nov 2006 04:29:59 -0500 Subject: [Biojava-dev] [Bug 2150] RichStreamReader.nextBioEntry() call this.nextBioEntry() In-Reply-To: Message-ID: <200611270929.kAR9TxPC009133@portal.open-bio.org> show_bug.cgi?id=2150 holland at ebi.ac.uk changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #1 from holland at ebi.ac.uk 2006-11-27 04:29 ------- Fixed in CVS. -- Configure bugmail: userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From kingsulaman at hotmail.com Mon Nov 27 09:43:28 2006 From: kingsulaman at hotmail.com (Sulaman Nawaz) Date: Mon, 27 Nov 2006 14:43:28 +0000 Subject: [Biojava-dev] Willing to Contribute in BioJava In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://lists.open-bio.org/pipermail/biojava-dev/attachments/20061127/35803cd5/attachment.html From kingsulaman at hotmail.com Mon Nov 27 09:44:11 2006 From: kingsulaman at hotmail.com (Sulaman Nawaz) Date: Mon, 27 Nov 2006 14:44:11 +0000 Subject: [Biojava-dev] Willing to Contribute in BioJava In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://lists.open-bio.org/pipermail/biojava-dev/attachments/20061127/8b8e7277/attachment.html From gwaldon at geneinfinity.org Thu Nov 2 15:47:28 2006 From: gwaldon at geneinfinity.org (george waldon) Date: Thu, 02 Nov 2006 07:47:28 -0800 Subject: [Biojava-dev] Problems with RichLocations Message-ID: <200611021547.kA2FlS6E086701@mmm1924.dulles19-verio.com> Hello, I think I found some potential problems with RichLocation. In RichLocation.Tools.construct(Collection members) the merging is apparently missing. Biojavax always calls merging before construct but the javadoc indicates logically that merging should be done inside the body of the method. In CompoundRichLocation, blocIterator should return an iterator over contiguous blocs sorted in ascending order according to Location javadoc. It does not seem that the list of members is sorted. In RichLocation.Tools.flatten(Collection members), members are checked for being instance of SimpleRichLocation. This does not sound correct. First, SimpleRichLocation is not an interface and therefore there is no contract with it and it should not be here; secondly compound members are probably instance of CompoundRichLocation which extends SimpleRichLocation and therefore these compound members are not flattened. In RichLocation.Tools.modulateCircularLocation(int start, int end, int seqLength), end could be far up and we are probably missing something like while (locationLength>=seqLength) locationLength-=seqLength; Hope this helps. Thanks, George From holland at ebi.ac.uk Thu Nov 2 16:35:10 2006 From: holland at ebi.ac.uk (Richard Holland) Date: Thu, 02 Nov 2006 16:35:10 +0000 Subject: [Biojava-dev] Problems with RichLocations In-Reply-To: <200611021547.kA2FlS6E086701@mmm1924.dulles19-verio.com> References: <200611021547.kA2FlS6E086701@mmm1924.dulles19-verio.com> Message-ID: <454A1E3E.2040101@ebi.ac.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for pointing this out. > In RichLocation.Tools.construct(Collection members) the merging is apparently missing. Biojavax always calls merging before construct but the javadoc indicates logically that merging should be done inside the body of the method. The JavaDocs were wrong. There are instances (GenbankFormat etc.) where we need to construct without merging. Therefore, merging is always left to the caller. I have amended the JavaDocs to remove this ambiguity. > In CompoundRichLocation, blocIterator should return an iterator over contiguous blocs sorted in ascending order according to Location javadoc. It does not seem that the list of members is sorted. I've altered this now and it will return sorted blocks. > In RichLocation.Tools.flatten(Collection members), members are checked for being instance of SimpleRichLocation. This does not sound correct. First, SimpleRichLocation is not an interface and therefore there is no contract with it and it should not be here; secondly compound members are probably instance of CompoundRichLocation which extends SimpleRichLocation and therefore these compound members are not flattened. Oops! Fixed now. > In RichLocation.Tools.modulateCircularLocation(int start, int end, int seqLength), end could be far up and we are probably missing something like > while (locationLength>=seqLength) locationLength-=seqLength; This is deliberate, as circular locations are allowed to wrap round and cover the entire sequence as many times as they like. Therefore modulateCircularLocation is supposed to return a location of identical length, just translated so that start is before end and that start is as close to the actual start of the sequence as possible, in order to make it easier for the subsequence methods to work out how to extract circular sequence. (in the resulting coordinates, start will lie within the sequence but end could be far far beyond the actual end of the sequence, which will be interpreted as wrapping round and starting again from the beginning). > Hope this helps. It did! :) All above fixes are in CVS. cheers, Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFSh494C5LeMEKA/QRAixVAJ0a6rF+/sdG/8P+FfVBrF3i78OuagCePThK nVT3GCpLl4AeHBnobZD9zDE= =/CAn -----END PGP SIGNATURE----- From markjschreiber at gmail.com Fri Nov 3 02:40:13 2006 From: markjschreiber at gmail.com (Mark Schreiber) Date: Fri, 3 Nov 2006 10:40:13 +0800 Subject: [Biojava-dev] Problems with RichLocations In-Reply-To: <454A1E3E.2040101@ebi.ac.uk> References: <200611021547.kA2FlS6E086701@mmm1924.dulles19-verio.com> <454A1E3E.2040101@ebi.ac.uk> Message-ID: <93b45ca50611021840t1be692f9x1c2db0d3b657ca67@mail.gmail.com> This is one area where we don't have many unit tests: Volunteers??? On 11/3/06, Richard Holland wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thanks for pointing this out. > > > In RichLocation.Tools.construct(Collection members) the merging is apparently missing. Biojavax always calls merging before construct but the javadoc indicates logically that merging should be done inside the body of the method. > > The JavaDocs were wrong. There are instances (GenbankFormat etc.) where > we need to construct without merging. Therefore, merging is always left > to the caller. I have amended the JavaDocs to remove this ambiguity. > > > In CompoundRichLocation, blocIterator should return an iterator over contiguous blocs sorted in ascending order according to Location javadoc. It does not seem that the list of members is sorted. > > I've altered this now and it will return sorted blocks. > > > In RichLocation.Tools.flatten(Collection members), members are checked for being instance of SimpleRichLocation. This does not sound correct. First, SimpleRichLocation is not an interface and therefore there is no contract with it and it should not be here; secondly compound members are probably instance of CompoundRichLocation which extends SimpleRichLocation and therefore these compound members are not flattened. > > Oops! Fixed now. > > > In RichLocation.Tools.modulateCircularLocation(int start, int end, int seqLength), end could be far up and we are probably missing something like > > while (locationLength>=seqLength) locationLength-=seqLength; > > This is deliberate, as circular locations are allowed to wrap round and > cover the entire sequence as many times as they like. Therefore > modulateCircularLocation is supposed to return a location of identical > length, just translated so that start is before end and that start is as > close to the actual start of the sequence as possible, in order to make > it easier for the subsequence methods to work out how to extract > circular sequence. (in the resulting coordinates, start will lie within > the sequence but end could be far far beyond the actual end of the > sequence, which will be interpreted as wrapping round and starting again > from the beginning). > > > Hope this helps. > > It did! :) All above fixes are in CVS. > > cheers, > Richard > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFFSh494C5LeMEKA/QRAixVAJ0a6rF+/sdG/8P+FfVBrF3i78OuagCePThK > nVT3GCpLl4AeHBnobZD9zDE= > =/CAn > -----END PGP SIGNATURE----- > _______________________________________________ > biojava-dev mailing list > biojava-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biojava-dev > From Robin.Emig at pioneer.com Wed Nov 8 22:27:56 2006 From: Robin.Emig at pioneer.com (Emig, Robin) Date: Wed, 8 Nov 2006 14:27:56 -0800 Subject: [Biojava-dev] Alignment SmithWaterman and NW In-Reply-To: <93b45ca50611021840t1be692f9x1c2db0d3b657ca67@mail.gmail.com> Message-ID: I just test out the alignment procedure in biojava and found a possible issue. When aligning two sequences, I get an alignment which contains gaps at the same position in both sequences. This seems strange to me, can it be correct? -Robin This communication is for use by the intended recipient and contains information that may be Privileged, confidential or copyrighted under applicable law. If you are not the intended recipient, you are hereby formally notified that any use, copying or distribution of this e-mail, in whole or in part, is strictly prohibited. Please notify the sender by return e-mail and delete this e-mail from your system. Unless explicitly and conspicuously designated as "E-Contract Intended", this e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer. This e-mail does not constitute a consent to the use of sender's contact information for direct marketing purposes or for transfers of data to third parties. Francais Deutsch Italiano Espanol Portugues Japanese Chinese Korean http://www.DuPont.com/corp/email_disclaimer.html From mark.schreiber at novartis.com Thu Nov 9 01:55:37 2006 From: mark.schreiber at novartis.com (mark.schreiber at novartis.com) Date: Thu, 9 Nov 2006 09:55:37 +0800 Subject: [Biojava-dev] Alignment SmithWaterman and NW Message-ID: Hi Robin - >From my understanding of NW and SW this should not happen. Can you log this in Bugzilla (from the www.biojava.org page). - Mark Mark Schreiber Research Investigator (Bioinformatics) Novartis Institute for Tropical Diseases (NITD) 10 Biopolis Road #05-01 Chromos Singapore 138670 www.nitd.novartis.com www.dengueinfo.org phone +65 6722 2973 fax +65 6722 2910 "Emig, Robin" Sent by: biojava-dev-bounces at lists.open-bio.org 11/09/2006 06:27 AM To: cc: , (bcc: Mark Schreiber/GP/Novartis) Subject: [Biojava-dev] Alignment SmithWaterman and NW I just test out the alignment procedure in biojava and found a possible issue. When aligning two sequences, I get an alignment which contains gaps at the same position in both sequences. This seems strange to me, can it be correct? -Robin This communication is for use by the intended recipient and contains information that may be Privileged, confidential or copyrighted under applicable law. If you are not the intended recipient, you are hereby formally notified that any use, copying or distribution of this e-mail, in whole or in part, is strictly prohibited. Please notify the sender by return e-mail and delete this e-mail from your system. Unless explicitly and conspicuously designated as "E-Contract Intended", this e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer. This e-mail does not constitute a consent to the use of sender's contact information for direct marketing purposes or for transfers of data to third parties. Francais Deutsch Italiano Espanol Portugues Japanese Chinese Korean http://www.DuPont.com/corp/email_disclaimer.html _______________________________________________ biojava-dev mailing list biojava-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/biojava-dev From sylvain.foisy at diploide.net Thu Nov 9 01:03:03 2006 From: sylvain.foisy at diploide.net (Sylvain Foisy) Date: Wed, 08 Nov 2006 20:03:03 -0500 Subject: [Biojava-dev] Alignment SmithWaterman and NW In-Reply-To: Message-ID: Hi, This might be a stupid question but have you tried these same sequences using EMBOSS' water and needle with the same parameters? If you get the same output, it might be the sequences themselves. Best regards Sylvain On 08/11/06 17:27, "Emig, Robin" wrote: > I just test out the alignment procedure in biojava and found a > possible issue. When aligning two sequences, I get an alignment which > contains gaps at the same position in both sequences. This seems strange > to me, can it be correct? =================================================================== Sylvain Foisy, Ph. D. Consultant Diploide.net - TI pour la vie / IT for Life Courriel: sylvain.foisy at diploide.net =================================================================== From Robin.Emig at pioneer.com Sat Nov 11 02:00:43 2006 From: Robin.Emig at pioneer.com (Emig, Robin) Date: Fri, 10 Nov 2006 18:00:43 -0800 Subject: [Biojava-dev] Alignment SmithWaterman and NW In-Reply-To: Message-ID: After tracking this down farther, I found the problem to be that my sequences already had gaps in them before I did the alignment and the tools in biojava treat gap, basically, like another symbol. Running the same search on EMBOSS returns a correct result (water/needle) because it removes/ignores gaps before doing the alignment. Thanks, robin -----Original Message----- From: biojava-dev-bounces at lists.open-bio.org [mailto:biojava-dev-bounces at lists.open-bio.org] On Behalf Of Sylvain Foisy Sent: Wednesday, November 08, 2006 5:03 PM To: Emig, Robin Cc: biojava-dev at lists.open-bio.org Subject: Re: [Biojava-dev] Alignment SmithWaterman and NW Hi, This might be a stupid question but have you tried these same sequences using EMBOSS' water and needle with the same parameters? If you get the same output, it might be the sequences themselves. Best regards Sylvain On 08/11/06 17:27, "Emig, Robin" wrote: > I just test out the alignment procedure in biojava and found a > possible issue. When aligning two sequences, I get an alignment which > contains gaps at the same position in both sequences. This seems > strange to me, can it be correct? =================================================================== Sylvain Foisy, Ph. D. Consultant Diploide.net - TI pour la vie / IT for Life Courriel: sylvain.foisy at diploide.net =================================================================== _______________________________________________ biojava-dev mailing list biojava-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/biojava-dev This communication is for use by the intended recipient and contains information that may be Privileged, confidential or copyrighted under applicable law. If you are not the intended recipient, you are hereby formally notified that any use, copying or distribution of this e-mail, in whole or in part, is strictly prohibited. Please notify the sender by return e-mail and delete this e-mail from your system. Unless explicitly and conspicuously designated as "E-Contract Intended", this e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer. This e-mail does not constitute a consent to the use of sender's contact information for direct marketing purposes or for transfers of data to third parties. Francais Deutsch Italiano Espanol Portugues Japanese Chinese Korean http://www.DuPont.com/corp/email_disclaimer.html From bugzilla-daemon at portal.open-bio.org Wed Nov 15 20:58:52 2006 From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org) Date: Wed, 15 Nov 2006 15:58:52 -0500 Subject: [Biojava-dev] [Bug 2144] New: LayeredRenderer not handling OverlayMarkers Message-ID: http://bugzilla.open-bio.org/show_bug.cgi?id=2144 Summary: LayeredRenderer not handling OverlayMarkers Product: BioJava Version: 1.4 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: seq AssignedTo: biojava-dev at biojava.org ReportedBy: jbdamask at earthlink.net Adding OverlayRendererWrappers to SequenceRenderers which eventually are placed onto a MultiLineRenderer causes extra whitespace in the rendered depth. This is due to LayeredRenderer's getDepth method line: depth += sRend.getDepth(src); To fix, add a conditional as follows: if(sRend instanceof OverlayMarker){ depth += 0.0; // maybe just do nothing here }else { depth += sRend.getDepth(src); } -- Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at portal.open-bio.org Thu Nov 16 09:33:48 2006 From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org) Date: Thu, 16 Nov 2006 04:33:48 -0500 Subject: [Biojava-dev] [Bug 2144] LayeredRenderer not handling OverlayMarkers In-Reply-To: Message-ID: <200611160933.kAG9XmPo021443@portal.open-bio.org> http://bugzilla.open-bio.org/show_bug.cgi?id=2144 holland at ebi.ac.uk changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #1 from holland at ebi.ac.uk 2006-11-16 04:33 ------- Accepted proposed fix. Committed to HEAD. -- Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at portal.open-bio.org Sun Nov 26 07:19:35 2006 From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org) Date: Sun, 26 Nov 2006 02:19:35 -0500 Subject: [Biojava-dev] [Bug 2150] New: RichStreamReader.nextBioEntry() call this.nextBioEntry() Message-ID: show_bug.cgi?id=2150 Summary: RichStreamReader.nextBioEntry() call this.nextBioEntry() Product: BioJava Version: live (CVS source) Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: seq.io AssignedTo: biojava-dev at biojava.org ReportedBy: jdiminic at gmail.com My code in biojava 1.5 beta: String fasta = ... // same fasta string Namespace ns = RichObjectFactory.getDefaultNamespace(); StringReader r = new StringReader(fasta); BufferedReader re = new BufferedReader(r); RichSequenceIterator readFasta = IOTools.readFastaDNA(re, ns); I got Exception: exception in thread "main" java.lang.StackOverflowError at org.biojavax.bio.seq.io.RichStreamReader.nextBioEntry(RichStreamReader.java:98) i will see that in org.biojavax.bio.seq.io.RichStreamReader ili line 98 method call same own method and got StackOverflowError. /** * {@inheritDoc} */ public BioEntry nextBioEntry() throws NoSuchElementException, BioException { return this.nextBioEntry(); } -- Configure bugmail: userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at portal.open-bio.org Mon Nov 27 09:29:59 2006 From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org) Date: Mon, 27 Nov 2006 04:29:59 -0500 Subject: [Biojava-dev] [Bug 2150] RichStreamReader.nextBioEntry() call this.nextBioEntry() In-Reply-To: Message-ID: <200611270929.kAR9TxPC009133@portal.open-bio.org> show_bug.cgi?id=2150 holland at ebi.ac.uk changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #1 from holland at ebi.ac.uk 2006-11-27 04:29 ------- Fixed in CVS. -- Configure bugmail: userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From kingsulaman at hotmail.com Mon Nov 27 14:43:28 2006 From: kingsulaman at hotmail.com (Sulaman Nawaz) Date: Mon, 27 Nov 2006 14:43:28 +0000 Subject: [Biojava-dev] Willing to Contribute in BioJava In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: From kingsulaman at hotmail.com Mon Nov 27 14:44:11 2006 From: kingsulaman at hotmail.com (Sulaman Nawaz) Date: Mon, 27 Nov 2006 14:44:11 +0000 Subject: [Biojava-dev] Willing to Contribute in BioJava In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: