From bubba.puryear at gmail.com  Mon Oct  2 10:44:11 2006
From: bubba.puryear at gmail.com (Bubba Puryear)
Date: Mon, 2 Oct 2006 10:44:11 -0400
Subject: [Biojava-dev] GenbankFormat (biojavax) and comments with
	leading whitespace
In-Reply-To: <93b45ca50609300529r8491cf0p22784589bea59618@mail.gmail.com>
References: <d2f7533b0609290922w6aee8e07ybae05536a8d634b6@mail.gmail.com>
	<93b45ca50609300529r8491cf0p22784589bea59618@mail.gmail.com>
Message-ID: <d2f7533b0610020744p69e2fb8ao14987010d9c2e4e@mail.gmail.com>

Seems I was a bit hasty in my assertions. Turns out I don't need to
muck with the comment blocks (at least not in biojava), but I did need
to fix the bug in SimpleRichFeature's compareTo method that wasn't
letting it play nicely with TreeSet. (I checked in tests, too)

I'll yell if I run into anything else. Thanks,
Bubba


On 9/30/06, Mark Schreiber <markjschreiber at gmail.com> wrote:
> I think this should be fine to commit as long as biojava can still
> read in the file again (and other files).
>
> You should probably also comment the code to say VNTI needs this and
> to be doubly certain put in a unit test.
>
> - Mark
>
> On 9/30/06, Bubba Puryear <bubba.puryear at gmail.com> wrote:
> > Hey all,
> >
> >   I've been using biojava for some time now on my project for reading
> > genbank flat files, but until reacently I haven't been writing any.
> > Our client makes extensive use of VectorNTI (version 9, I think) and I
> > was doing some edits to genbank files (via biojavax) and notice that
> > comment values get their whitespace trimmed.
> >
> >   Turns out VNTI splats a load of state that it needs in the comment
> > section is a fairly lispish looking syntax... but indentation appears
> > to be important. In particular, VNTI won't read the files I've edited
> > that have had their whitespace munged. I have some local changes to
> > the parser that preserve leading/trailing whitespace for section
> > values for top level sections.
> >
> >   I've run the tests locally (and added one for testing indented
> > comments) and run this against ~ 3000 files I have locally. I wanted
> > to get some feedback on this before I committed, though.
> >
> >   As an example of the kind of thing that currently gets munged:
> >
> > COMMENT     Vector_NTI_Display_Data_(Do_Not_Edit!)
> > COMMENT     (SXF
> > COMMENT      (CGexDoc "11460" 0 6359
> > COMMENT       (CDBMol 0 0 1 1 1 0 0 1633772385 0 "" "" 0 0 0 0
> > (CObList) (CObList)
> > COMMENT        (CObList) (CObList) -1)
> > COMMENT       (CDocSetData 1 0 0 0 0 0 "MAIN" 1 1 1 1 0 0 1 1 0 1 10 5
> > 40 50 0 1 0
> > ....
> >
> >    The level of indentation can get quite deep.
> >
> > Thanks,
> > Bubba
> > _______________________________________________
> > biojava-dev mailing list
> > biojava-dev at lists.open-bio.org
> > http://lists.open-bio.org/mailman/listinfo/biojava-dev
> >
>

From jolyon.holdstock at ogt.co.uk  Wed Oct  4 12:35:41 2006
From: jolyon.holdstock at ogt.co.uk (Jolyon Holdstock)
Date: Wed, 4 Oct 2006 17:35:41 +0100
Subject: [Biojava-dev] [Bug 2107] LabelledSequenceRenderer[Scanned]
Message-ID: <588D0DD225D05746B5D8CAE1BE971F3F01088130@EUCLID.internal.ogtip.com>


Hi,

The changes I have made to the TranslatedSequencePanel have resolved the
issue when using a LabelledSequenceRenderer in a TSP.

Is it worth fixing the VERTICAL rendering of the label? Before I try and
do so I would like opinions as to whether there is a need for rendering
in this dimension?

There is a problem when using the RulerRenderer with the adjusted LSR as
the the ruler line is rendered from before the point where the label
ends. As a result the line overlaps the label.

Also, as the line sometimes doesn't quite extend to the end of the panel
I add scale to maxX instead of halfscale.

I have edited the RulerRenderer to avoid this.

Following the if (tickDirection == TICKS_UP) conditional
I have replaced 
  line.setLine(minX - halfScale, 0.0, maxX + halfScale, 0.0);
with
  line.setLine(minX, 0.0, maxX + scale, 0.0);


I can pass on the changes or commit it myself if you want to give an
account.


cheers,


Jolyon


-----Original Message-----
From: biojava-dev-bounces at lists.open-bio.org
[mailto:biojava-dev-bounces at lists.open-bio.org] On Behalf Of
bugzilla-daemon at portal.open-bio.org
Sent: 28 September 2006 10:27
To: biojava-dev at biojava.org
Subject: [Biojava-dev] [Bug 2107] LabelledSequenceRenderer[Scanned]

http://bugzilla.open-bio.org/show_bug.cgi?id=2107


jolyon.holdstock at ogt.co.uk changed:

           What    |Removed                     |Added
------------------------------------------------------------------------
----
                 CC|
|jolyon.holdstock at ogt.co.uk




------- Comment #1 from jolyon.holdstock at ogt.co.uk  2006-09-28 05:27
-------
I've had a look at the TranslatedSequencePanel code and seem to have a
work
around. I say 'seem' as I'm not an expert on Graphics2D

When using the LabelledSequenceRenderer in the TSP the paint method in
the TSP
doesn't set the clip for the renderer correctly.

I have edited the following code in the TSP to change

clip.x
clip.width
The point for g2.translate

This sets the clip correctly, the label renders and the correct sequence
displayed. 

//OLD CODE ==========================================================
if (direction == HORIZONTAL) {
  // Clip x to edge of delegate renderer's leader
  clip.x = renderer.getMinimumLeader(this);
  clip.y = 0.0;
  // Set the width to visible symbols + the delegate
  // renderer's minimum trailer (which may have something in
  // it to render).
  clip.width = sequenceToGraphics(getVisibleSymbolCount() + 1) +
renderer.getMinimumTrailer(this);
  clip.height = renderer.getDepth(this);
  g2.translate(leadingBorder.getSize() + insets.left, insets.top); } 

//NEW CODE ============================================================
if (direction == HORIZONTAL) {
  // Clip x to edge of delegate renderer's leader
  //clip.x = renderer.getMinimumLeader(this);
  clip.x = 0 - renderer.getMinimumLeader(this);
  clip.y = 0.0;
  // Set the width to visible symbols + the delegate
  // renderer's minimum trailer (which may have something in
  // it to render).
  clip.width = sequenceToGraphics(getVisibleSymbolCount() + 1) +
renderer.getMinimumLeader(this) + renderer.getMinimumTrailer(this);
  clip.height = renderer.getDepth(this);
  g2.translate(leadingBorder.getSize() - clip.x + insets.left,
insets.top); }


I have used this code with the RulerRenderer via the MultiLineRenderer
and think that the ruler doesn't renderer numbers/ticks accurately for
the sequence in the TSP. It's marginal and only relevant at high
resolution but
I'll have a look at this.


-- 
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.
_______________________________________________
biojava-dev mailing list
biojava-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/biojava-dev











This email has been scanned by Oxford Gene Technology Security Systems.



From gwaldon at geneinfinity.org  Thu Oct  5 00:08:33 2006
From: gwaldon at geneinfinity.org (george waldon)
Date: Wed, 04 Oct 2006 21:08:33 -0700
Subject: [Biojava-dev] Changing location of RankedDocRef
Message-ID: <200610050408.k9548X55028272@mmm1924.dulles19-verio.com>

I am about to commit changeable for ranks in RankedDocRef. I'd like also to have a chantype for location and add the method setLocation(Location loc) throws ChangeVetoException to the interface. Is this ok to everyone?

- George

From mark.schreiber at novartis.com  Thu Oct  5 01:42:15 2006
From: mark.schreiber at novartis.com (mark.schreiber at novartis.com)
Date: Thu, 5 Oct 2006 13:42:15 +0800
Subject: [Biojava-dev] Changing location of RankedDocRef
Message-ID: <OFB98FA2C7.444E54FC-ON482571FE.001F02E7-482571FE.001F55CD@ah.novartis.com>

Hi George -

Sounds reasonable. If you do this make sure you add tests in JUnit to make 
sure that changeing the values actually fires the correct change event. 
Probably everything that has a rank should have the possibility of firing 
a change event when it is changed. If we do it now we are still in beta we 
can avoid having to add an exception to a released interface.

However, this reminds me of something I have been meaning to bring up for 
a while... see my next email.

- Mark

Mark Schreiber
Research Investigator (Bioinformatics)

Novartis Institute for Tropical Diseases (NITD)
10 Biopolis Road
#05-01 Chromos
Singapore 138670
www.nitd.novartis.com

phone +65 6722 2973
fax  +65 6722 2910





"george waldon" <gwaldon at geneinfinity.org>
Sent by: biojava-dev-bounces at lists.open-bio.org
10/05/2006 12:08 PM
Please respond to george waldon

 
        To:     biojava-dev at biojava.org
        cc:     (bcc: Mark Schreiber/GP/Novartis)
        Subject:        [Biojava-dev] Changing location of RankedDocRef


I am about to commit changeable for ranks in RankedDocRef. I'd like also 
to have a chantype for location and add the method setLocation(Location 
loc) throws ChangeVetoException to the interface. Is this ok to everyone?

- George
_______________________________________________
biojava-dev mailing list
biojava-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/biojava-dev




From mark.schreiber at novartis.com  Thu Oct  5 01:52:45 2006
From: mark.schreiber at novartis.com (mark.schreiber at novartis.com)
Date: Thu, 5 Oct 2006 13:52:45 +0800
Subject: [Biojava-dev] ChangeVetoException proposal for change
Message-ID: <OFC0859EDD.8228FA84-ON482571FE.001F5658-482571FE.00204BD9@ah.novartis.com>

Hello all -

I would like to propose that we modify the ChangeVetoException so that it 
extends RuntimeException thus making it an unchecked exception. The 
Changeable frame work in BioJava is very useful but probably not used all 
that often especially in simple programs. Therefore it is burdensome to 
have to include a try catch block around it. This is made especially true 
when most of the time the only things that will throw this kind of 
exception are listeners that you have set up to monitor and occasionally 
veto changes. Therefore a veto is highly unlikely unless you set up a 
situtation in which it can happen.

This reasoning has also been used in the recent EJB3 spec which made 
several EJB exceptions unchecked because 99% of the time they never happen 
and you only need to be mindful of them in specific situations.

My feeling is that this could remove a lot of un-needed try catch 
statements from a typical biojava project. If you are using Changeable you 
should put them in. If not don't worry about them as it is not likely to 
happen.

Your feedback on this issue is much appreciated. I would like to commit 
any change to this while biojava1.5 is still in beta.

- Mark

Mark Schreiber
Research Investigator (Bioinformatics)

Novartis Institute for Tropical Diseases (NITD)
10 Biopolis Road
#05-01 Chromos
Singapore 138670
www.nitd.novartis.com

phone +65 6722 2973
fax  +65 6722 2910


From bugzilla-daemon at portal.open-bio.org  Fri Oct  6 03:26:50 2006
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Fri, 6 Oct 2006 03:26:50 -0400
Subject: [Biojava-dev] [Bug 2046] Cannot read in more than one serialized
	ProfileHMM object, attempt crashes
In-Reply-To: <bug-2046-485@http.bugzilla.open-bio.org/>
Message-ID: <200610060726.k967QonV031793@portal.open-bio.org>

http://bugzilla.open-bio.org/show_bug.cgi?id=2046


mark.schreiber at novartis.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




-- 
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  Fri Oct  6 03:30:48 2006
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Fri, 6 Oct 2006 03:30:48 -0400
Subject: [Biojava-dev] [Bug 2107] LabelledSequenceRenderer
In-Reply-To: <bug-2107-485@http.bugzilla.open-bio.org/>
Message-ID: <200610060730.k967UmVW031994@portal.open-bio.org>

http://bugzilla.open-bio.org/show_bug.cgi?id=2107


mark.schreiber at novartis.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark.schreiber at novartis.com




------- Comment #2 from mark.schreiber at novartis.com  2006-10-06 03:30 -------
Problem was caused by state transition alphabets being registered with the
AlphabetManager as singletons after the first de-serialization even though they
were no previous to serialization.

This means on the second de-serialization that the model gets the transition
Alphabet from the AlphabetManager and then tries to find it's transitions in
that alphabet when they are not there.

This is one case where alphabets are not singletons.


-- 
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  Fri Oct  6 03:33:21 2006
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Fri, 6 Oct 2006 03:33:21 -0400
Subject: [Biojava-dev] [Bug 2107] LabelledSequenceRenderer
In-Reply-To: <bug-2107-485@http.bugzilla.open-bio.org/>
Message-ID: <200610060733.k967XLEL032088@portal.open-bio.org>

http://bugzilla.open-bio.org/show_bug.cgi?id=2107





------- Comment #3 from mark.schreiber at novartis.com  2006-10-06 03:33 -------
(In reply to comment #2)
> Problem was caused by state transition alphabets being registered with the
> AlphabetManager as singletons after the first de-serialization even though they
> were no previous to serialization.
> 
> This means on the second de-serialization that the model gets the transition
> Alphabet from the AlphabetManager and then tries to find it's transitions in
> that alphabet when they are not there.
> 
> This is one case where alphabets are not singletons.
> 



EEk, sorry those comments were for another bug not this one : (


-- 
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 jhg9 at duke.edu  Sat Oct 14 14:38:19 2006
From: jhg9 at duke.edu (Justin Guinney)
Date: Sat, 14 Oct 2006 14:38:19 -0400
Subject: [Biojava-dev] requesting cvs commit privledges
Message-ID: <7767c6360610141138h5170a934hef4d85cbba5995da@mail.gmail.com>

I'd like to request cvs commit privledges.

thanks,
-- 
Justin Guinney
919 357-4762 (c)

From gwaldon at geneinfinity.org  Wed Oct 25 20:41:24 2006
From: gwaldon at geneinfinity.org (george waldon)
Date: Wed, 25 Oct 2006 17:41:24 -0700
Subject: [Biojava-dev] Fine parsing of genbank files
Message-ID: <200610260041.k9Q0fOCY088084@mmm1924.dulles19-verio.com>

I still have problems with the rich parsing of genbank files. Currently, ordering of features is lost during parsing; e.g. AJ390283, which is an immunoglobulin heavy chain, has its exons and introns in separate groups after parsing and writing out instead of having them nicely ordered as they appear along the sequence in the original record. The problem comes from SimpleRichFeature compareTo and equals methods which do not compare using rank first but at the very last. I propose to give the rank of zero to Feature which are not instance to RichFeature and then to compare using rank first like with the other rich objects. RichFeature will be sorted like in the original genbank record; on the other hand if ranks are not used and are all to 0, then RichFeature and old Feature can me mixed without conflict.

Secondly, citing Richard in a previous post regarding ranks:
>> SimpleBioEntryRelationShip suggests that they start at 1 with 0 
>> reserved for absence of ranking.
>I tried to start them all from 1, and used 0 for no-rank where rank is compulsory, and null where rank is optional (see below). If you find anywhere where I've been inconsistent, please feel free to raise a Bugzilla bug to point out where I've gone wrong so I can fix them.

Yes, there are problems in SimpleRichSequenceBuilder:
- notes start at 0 (SeqPropCount = 0)
- features start at 0 (featurerank = 0)
- feature notes start at 0 (featPropCount = 0)

Finally, the equals method of SimpleBioEntryRelatonship should count a rank equals to zero for a null rank Integer to be consistent with the compareTo method (currently compareTo can return 0 while equals returns false for the same object).

If it sounds ok to everyone, I can make the changes.

- George

From holland at ebi.ac.uk  Thu Oct 26 03:40:40 2006
From: holland at ebi.ac.uk (Richard Holland)
Date: Thu, 26 Oct 2006 08:40:40 +0100
Subject: [Biojava-dev] Fine parsing of genbank files
In-Reply-To: <200610260041.k9Q0fOCY088084@mmm1924.dulles19-verio.com>
References: <200610260041.k9Q0fOCY088084@mmm1924.dulles19-verio.com>
Message-ID: <45406678.9030501@ebi.ac.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

That all sounds good to me. It's really helpful having someone check the
code in detail.

cheers,
Richard

george waldon wrote:
> I still have problems with the rich parsing of genbank files. Currently, ordering of features is lost during parsing; e.g. AJ390283, which is an immunoglobulin heavy chain, has its exons and introns in separate groups after parsing and writing out instead of having them nicely ordered as they appear along the sequence in the original record. The problem comes from SimpleRichFeature compareTo and equals methods which do not compare using rank first but at the very last. I propose to give the rank of zero to Feature which are not instance to RichFeature and then to compare using rank first like with the other rich objects. RichFeature will be sorted like in the original genbank record; on the other hand if ranks are not used and are all to 0, then RichFeature and old Feature can me mixed without conflict.
> 
> Secondly, citing Richard in a previous post regarding ranks:
>>> SimpleBioEntryRelationShip suggests that they start at 1 with 0 
>>> reserved for absence of ranking.
>> I tried to start them all from 1, and used 0 for no-rank where rank is compulsory, and null where rank is optional (see below). If you find anywhere where I've been inconsistent, please feel free to raise a Bugzilla bug to point out where I've gone wrong so I can fix them.
> 
> Yes, there are problems in SimpleRichSequenceBuilder:
> - notes start at 0 (SeqPropCount = 0)
> - features start at 0 (featurerank = 0)
> - feature notes start at 0 (featPropCount = 0)
> 
> Finally, the equals method of SimpleBioEntryRelatonship should count a rank equals to zero for a null rank Integer to be consistent with the compareTo method (currently compareTo can return 0 while equals returns false for the same object).
> 
> If it sounds ok to everyone, I can make the changes.
> 
> - George
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFQGZ34C5LeMEKA/QRAlsOAKCncZLNhByWqJ2BGuapcWyGRCpUSwCffb2p
Qvy6wvpXoNj6OG8hcM+jFoA=
=pr2w
-----END PGP SIGNATURE-----

From bubba.puryear at gmail.com  Mon Oct  2 14:44:11 2006
From: bubba.puryear at gmail.com (Bubba Puryear)
Date: Mon, 2 Oct 2006 10:44:11 -0400
Subject: [Biojava-dev] GenbankFormat (biojavax) and comments with
	leading whitespace
In-Reply-To: <93b45ca50609300529r8491cf0p22784589bea59618@mail.gmail.com>
References: <d2f7533b0609290922w6aee8e07ybae05536a8d634b6@mail.gmail.com>
	<93b45ca50609300529r8491cf0p22784589bea59618@mail.gmail.com>
Message-ID: <d2f7533b0610020744p69e2fb8ao14987010d9c2e4e@mail.gmail.com>

Seems I was a bit hasty in my assertions. Turns out I don't need to
muck with the comment blocks (at least not in biojava), but I did need
to fix the bug in SimpleRichFeature's compareTo method that wasn't
letting it play nicely with TreeSet. (I checked in tests, too)

I'll yell if I run into anything else. Thanks,
Bubba


On 9/30/06, Mark Schreiber <markjschreiber at gmail.com> wrote:
> I think this should be fine to commit as long as biojava can still
> read in the file again (and other files).
>
> You should probably also comment the code to say VNTI needs this and
> to be doubly certain put in a unit test.
>
> - Mark
>
> On 9/30/06, Bubba Puryear <bubba.puryear at gmail.com> wrote:
> > Hey all,
> >
> >   I've been using biojava for some time now on my project for reading
> > genbank flat files, but until reacently I haven't been writing any.
> > Our client makes extensive use of VectorNTI (version 9, I think) and I
> > was doing some edits to genbank files (via biojavax) and notice that
> > comment values get their whitespace trimmed.
> >
> >   Turns out VNTI splats a load of state that it needs in the comment
> > section is a fairly lispish looking syntax... but indentation appears
> > to be important. In particular, VNTI won't read the files I've edited
> > that have had their whitespace munged. I have some local changes to
> > the parser that preserve leading/trailing whitespace for section
> > values for top level sections.
> >
> >   I've run the tests locally (and added one for testing indented
> > comments) and run this against ~ 3000 files I have locally. I wanted
> > to get some feedback on this before I committed, though.
> >
> >   As an example of the kind of thing that currently gets munged:
> >
> > COMMENT     Vector_NTI_Display_Data_(Do_Not_Edit!)
> > COMMENT     (SXF
> > COMMENT      (CGexDoc "11460" 0 6359
> > COMMENT       (CDBMol 0 0 1 1 1 0 0 1633772385 0 "" "" 0 0 0 0
> > (CObList) (CObList)
> > COMMENT        (CObList) (CObList) -1)
> > COMMENT       (CDocSetData 1 0 0 0 0 0 "MAIN" 1 1 1 1 0 0 1 1 0 1 10 5
> > 40 50 0 1 0
> > ....
> >
> >    The level of indentation can get quite deep.
> >
> > Thanks,
> > Bubba
> > _______________________________________________
> > biojava-dev mailing list
> > biojava-dev at lists.open-bio.org
> > http://lists.open-bio.org/mailman/listinfo/biojava-dev
> >
>


From jolyon.holdstock at ogt.co.uk  Wed Oct  4 16:35:41 2006
From: jolyon.holdstock at ogt.co.uk (Jolyon Holdstock)
Date: Wed, 4 Oct 2006 17:35:41 +0100
Subject: [Biojava-dev] [Bug 2107] LabelledSequenceRenderer[Scanned]
Message-ID: <588D0DD225D05746B5D8CAE1BE971F3F01088130@EUCLID.internal.ogtip.com>


Hi,

The changes I have made to the TranslatedSequencePanel have resolved the
issue when using a LabelledSequenceRenderer in a TSP.

Is it worth fixing the VERTICAL rendering of the label? Before I try and
do so I would like opinions as to whether there is a need for rendering
in this dimension?

There is a problem when using the RulerRenderer with the adjusted LSR as
the the ruler line is rendered from before the point where the label
ends. As a result the line overlaps the label.

Also, as the line sometimes doesn't quite extend to the end of the panel
I add scale to maxX instead of halfscale.

I have edited the RulerRenderer to avoid this.

Following the if (tickDirection == TICKS_UP) conditional
I have replaced 
  line.setLine(minX - halfScale, 0.0, maxX + halfScale, 0.0);
with
  line.setLine(minX, 0.0, maxX + scale, 0.0);


I can pass on the changes or commit it myself if you want to give an
account.


cheers,


Jolyon


-----Original Message-----
From: biojava-dev-bounces at lists.open-bio.org
[mailto:biojava-dev-bounces at lists.open-bio.org] On Behalf Of
bugzilla-daemon at portal.open-bio.org
Sent: 28 September 2006 10:27
To: biojava-dev at biojava.org
Subject: [Biojava-dev] [Bug 2107] LabelledSequenceRenderer[Scanned]

http://bugzilla.open-bio.org/show_bug.cgi?id=2107


jolyon.holdstock at ogt.co.uk changed:

           What    |Removed                     |Added
------------------------------------------------------------------------
----
                 CC|
|jolyon.holdstock at ogt.co.uk




------- Comment #1 from jolyon.holdstock at ogt.co.uk  2006-09-28 05:27
-------
I've had a look at the TranslatedSequencePanel code and seem to have a
work
around. I say 'seem' as I'm not an expert on Graphics2D

When using the LabelledSequenceRenderer in the TSP the paint method in
the TSP
doesn't set the clip for the renderer correctly.

I have edited the following code in the TSP to change

clip.x
clip.width
The point for g2.translate

This sets the clip correctly, the label renders and the correct sequence
displayed. 

//OLD CODE ==========================================================
if (direction == HORIZONTAL) {
  // Clip x to edge of delegate renderer's leader
  clip.x = renderer.getMinimumLeader(this);
  clip.y = 0.0;
  // Set the width to visible symbols + the delegate
  // renderer's minimum trailer (which may have something in
  // it to render).
  clip.width = sequenceToGraphics(getVisibleSymbolCount() + 1) +
renderer.getMinimumTrailer(this);
  clip.height = renderer.getDepth(this);
  g2.translate(leadingBorder.getSize() + insets.left, insets.top); } 

//NEW CODE ============================================================
if (direction == HORIZONTAL) {
  // Clip x to edge of delegate renderer's leader
  //clip.x = renderer.getMinimumLeader(this);
  clip.x = 0 - renderer.getMinimumLeader(this);
  clip.y = 0.0;
  // Set the width to visible symbols + the delegate
  // renderer's minimum trailer (which may have something in
  // it to render).
  clip.width = sequenceToGraphics(getVisibleSymbolCount() + 1) +
renderer.getMinimumLeader(this) + renderer.getMinimumTrailer(this);
  clip.height = renderer.getDepth(this);
  g2.translate(leadingBorder.getSize() - clip.x + insets.left,
insets.top); }


I have used this code with the RulerRenderer via the MultiLineRenderer
and think that the ruler doesn't renderer numbers/ticks accurately for
the sequence in the TSP. It's marginal and only relevant at high
resolution but
I'll have a look at this.


-- 
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.
_______________________________________________
biojava-dev mailing list
biojava-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/biojava-dev











This email has been scanned by Oxford Gene Technology Security Systems.




From gwaldon at geneinfinity.org  Thu Oct  5 04:08:33 2006
From: gwaldon at geneinfinity.org (george waldon)
Date: Wed, 04 Oct 2006 21:08:33 -0700
Subject: [Biojava-dev] Changing location of RankedDocRef
Message-ID: <200610050408.k9548X55028272@mmm1924.dulles19-verio.com>

I am about to commit changeable for ranks in RankedDocRef. I'd like also to have a chantype for location and add the method setLocation(Location loc) throws ChangeVetoException to the interface. Is this ok to everyone?

- George


From mark.schreiber at novartis.com  Thu Oct  5 05:42:15 2006
From: mark.schreiber at novartis.com (mark.schreiber at novartis.com)
Date: Thu, 5 Oct 2006 13:42:15 +0800
Subject: [Biojava-dev] Changing location of RankedDocRef
Message-ID: <OFB98FA2C7.444E54FC-ON482571FE.001F02E7-482571FE.001F55CD@ah.novartis.com>

Hi George -

Sounds reasonable. If you do this make sure you add tests in JUnit to make 
sure that changeing the values actually fires the correct change event. 
Probably everything that has a rank should have the possibility of firing 
a change event when it is changed. If we do it now we are still in beta we 
can avoid having to add an exception to a released interface.

However, this reminds me of something I have been meaning to bring up for 
a while... see my next email.

- Mark

Mark Schreiber
Research Investigator (Bioinformatics)

Novartis Institute for Tropical Diseases (NITD)
10 Biopolis Road
#05-01 Chromos
Singapore 138670
www.nitd.novartis.com

phone +65 6722 2973
fax  +65 6722 2910





"george waldon" <gwaldon at geneinfinity.org>
Sent by: biojava-dev-bounces at lists.open-bio.org
10/05/2006 12:08 PM
Please respond to george waldon

 
        To:     biojava-dev at biojava.org
        cc:     (bcc: Mark Schreiber/GP/Novartis)
        Subject:        [Biojava-dev] Changing location of RankedDocRef


I am about to commit changeable for ranks in RankedDocRef. I'd like also 
to have a chantype for location and add the method setLocation(Location 
loc) throws ChangeVetoException to the interface. Is this ok to everyone?

- George
_______________________________________________
biojava-dev mailing list
biojava-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/biojava-dev





From mark.schreiber at novartis.com  Thu Oct  5 05:52:45 2006
From: mark.schreiber at novartis.com (mark.schreiber at novartis.com)
Date: Thu, 5 Oct 2006 13:52:45 +0800
Subject: [Biojava-dev] ChangeVetoException proposal for change
Message-ID: <OFC0859EDD.8228FA84-ON482571FE.001F5658-482571FE.00204BD9@ah.novartis.com>

Hello all -

I would like to propose that we modify the ChangeVetoException so that it 
extends RuntimeException thus making it an unchecked exception. The 
Changeable frame work in BioJava is very useful but probably not used all 
that often especially in simple programs. Therefore it is burdensome to 
have to include a try catch block around it. This is made especially true 
when most of the time the only things that will throw this kind of 
exception are listeners that you have set up to monitor and occasionally 
veto changes. Therefore a veto is highly unlikely unless you set up a 
situtation in which it can happen.

This reasoning has also been used in the recent EJB3 spec which made 
several EJB exceptions unchecked because 99% of the time they never happen 
and you only need to be mindful of them in specific situations.

My feeling is that this could remove a lot of un-needed try catch 
statements from a typical biojava project. If you are using Changeable you 
should put them in. If not don't worry about them as it is not likely to 
happen.

Your feedback on this issue is much appreciated. I would like to commit 
any change to this while biojava1.5 is still in beta.

- Mark

Mark Schreiber
Research Investigator (Bioinformatics)

Novartis Institute for Tropical Diseases (NITD)
10 Biopolis Road
#05-01 Chromos
Singapore 138670
www.nitd.novartis.com

phone +65 6722 2973
fax  +65 6722 2910



From bugzilla-daemon at portal.open-bio.org  Fri Oct  6 07:26:50 2006
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Fri, 6 Oct 2006 03:26:50 -0400
Subject: [Biojava-dev] [Bug 2046] Cannot read in more than one serialized
	ProfileHMM object, attempt crashes
In-Reply-To: <bug-2046-485@http.bugzilla.open-bio.org/>
Message-ID: <200610060726.k967QonV031793@portal.open-bio.org>

http://bugzilla.open-bio.org/show_bug.cgi?id=2046


mark.schreiber at novartis.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




-- 
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  Fri Oct  6 07:30:48 2006
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Fri, 6 Oct 2006 03:30:48 -0400
Subject: [Biojava-dev] [Bug 2107] LabelledSequenceRenderer
In-Reply-To: <bug-2107-485@http.bugzilla.open-bio.org/>
Message-ID: <200610060730.k967UmVW031994@portal.open-bio.org>

http://bugzilla.open-bio.org/show_bug.cgi?id=2107


mark.schreiber at novartis.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark.schreiber at novartis.com




------- Comment #2 from mark.schreiber at novartis.com  2006-10-06 03:30 -------
Problem was caused by state transition alphabets being registered with the
AlphabetManager as singletons after the first de-serialization even though they
were no previous to serialization.

This means on the second de-serialization that the model gets the transition
Alphabet from the AlphabetManager and then tries to find it's transitions in
that alphabet when they are not there.

This is one case where alphabets are not singletons.


-- 
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  Fri Oct  6 07:33:21 2006
From: bugzilla-daemon at portal.open-bio.org (bugzilla-daemon at portal.open-bio.org)
Date: Fri, 6 Oct 2006 03:33:21 -0400
Subject: [Biojava-dev] [Bug 2107] LabelledSequenceRenderer
In-Reply-To: <bug-2107-485@http.bugzilla.open-bio.org/>
Message-ID: <200610060733.k967XLEL032088@portal.open-bio.org>

http://bugzilla.open-bio.org/show_bug.cgi?id=2107





------- Comment #3 from mark.schreiber at novartis.com  2006-10-06 03:33 -------
(In reply to comment #2)
> Problem was caused by state transition alphabets being registered with the
> AlphabetManager as singletons after the first de-serialization even though they
> were no previous to serialization.
> 
> This means on the second de-serialization that the model gets the transition
> Alphabet from the AlphabetManager and then tries to find it's transitions in
> that alphabet when they are not there.
> 
> This is one case where alphabets are not singletons.
> 



EEk, sorry those comments were for another bug not this one : (


-- 
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 jhg9 at duke.edu  Sat Oct 14 18:38:19 2006
From: jhg9 at duke.edu (Justin Guinney)
Date: Sat, 14 Oct 2006 14:38:19 -0400
Subject: [Biojava-dev] requesting cvs commit privledges
Message-ID: <7767c6360610141138h5170a934hef4d85cbba5995da@mail.gmail.com>

I'd like to request cvs commit privledges.

thanks,
-- 
Justin Guinney
919 357-4762 (c)


From gwaldon at geneinfinity.org  Thu Oct 26 00:41:24 2006
From: gwaldon at geneinfinity.org (george waldon)
Date: Wed, 25 Oct 2006 17:41:24 -0700
Subject: [Biojava-dev] Fine parsing of genbank files
Message-ID: <200610260041.k9Q0fOCY088084@mmm1924.dulles19-verio.com>

I still have problems with the rich parsing of genbank files. Currently, ordering of features is lost during parsing; e.g. AJ390283, which is an immunoglobulin heavy chain, has its exons and introns in separate groups after parsing and writing out instead of having them nicely ordered as they appear along the sequence in the original record. The problem comes from SimpleRichFeature compareTo and equals methods which do not compare using rank first but at the very last. I propose to give the rank of zero to Feature which are not instance to RichFeature and then to compare using rank first like with the other rich objects. RichFeature will be sorted like in the original genbank record; on the other hand if ranks are not used and are all to 0, then RichFeature and old Feature can me mixed without conflict.

Secondly, citing Richard in a previous post regarding ranks:
>> SimpleBioEntryRelationShip suggests that they start at 1 with 0 
>> reserved for absence of ranking.
>I tried to start them all from 1, and used 0 for no-rank where rank is compulsory, and null where rank is optional (see below). If you find anywhere where I've been inconsistent, please feel free to raise a Bugzilla bug to point out where I've gone wrong so I can fix them.

Yes, there are problems in SimpleRichSequenceBuilder:
- notes start at 0 (SeqPropCount = 0)
- features start at 0 (featurerank = 0)
- feature notes start at 0 (featPropCount = 0)

Finally, the equals method of SimpleBioEntryRelatonship should count a rank equals to zero for a null rank Integer to be consistent with the compareTo method (currently compareTo can return 0 while equals returns false for the same object).

If it sounds ok to everyone, I can make the changes.

- George


From holland at ebi.ac.uk  Thu Oct 26 07:40:40 2006
From: holland at ebi.ac.uk (Richard Holland)
Date: Thu, 26 Oct 2006 08:40:40 +0100
Subject: [Biojava-dev] Fine parsing of genbank files
In-Reply-To: <200610260041.k9Q0fOCY088084@mmm1924.dulles19-verio.com>
References: <200610260041.k9Q0fOCY088084@mmm1924.dulles19-verio.com>
Message-ID: <45406678.9030501@ebi.ac.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

That all sounds good to me. It's really helpful having someone check the
code in detail.

cheers,
Richard

george waldon wrote:
> I still have problems with the rich parsing of genbank files. Currently, ordering of features is lost during parsing; e.g. AJ390283, which is an immunoglobulin heavy chain, has its exons and introns in separate groups after parsing and writing out instead of having them nicely ordered as they appear along the sequence in the original record. The problem comes from SimpleRichFeature compareTo and equals methods which do not compare using rank first but at the very last. I propose to give the rank of zero to Feature which are not instance to RichFeature and then to compare using rank first like with the other rich objects. RichFeature will be sorted like in the original genbank record; on the other hand if ranks are not used and are all to 0, then RichFeature and old Feature can me mixed without conflict.
> 
> Secondly, citing Richard in a previous post regarding ranks:
>>> SimpleBioEntryRelationShip suggests that they start at 1 with 0 
>>> reserved for absence of ranking.
>> I tried to start them all from 1, and used 0 for no-rank where rank is compulsory, and null where rank is optional (see below). If you find anywhere where I've been inconsistent, please feel free to raise a Bugzilla bug to point out where I've gone wrong so I can fix them.
> 
> Yes, there are problems in SimpleRichSequenceBuilder:
> - notes start at 0 (SeqPropCount = 0)
> - features start at 0 (featurerank = 0)
> - feature notes start at 0 (featPropCount = 0)
> 
> Finally, the equals method of SimpleBioEntryRelatonship should count a rank equals to zero for a null rank Integer to be consistent with the compareTo method (currently compareTo can return 0 while equals returns false for the same object).
> 
> If it sounds ok to everyone, I can make the changes.
> 
> - George
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFQGZ34C5LeMEKA/QRAlsOAKCncZLNhByWqJ2BGuapcWyGRCpUSwCffb2p
Qvy6wvpXoNj6OG8hcM+jFoA=
=pr2w
-----END PGP SIGNATURE-----