Hi all, I only just learned of the 1.11.0 release a couple of days ago, as I seem to have allowed my apollo mailing list subscription to expire. We're planning to run a workshop that uses Apollo in just over a week, so I was checking out the status of the 1.11.0 release. (I'm eager to use the latest release because I sorely missed the Types panel in 1.10.0!)
Anyway, to the point. There seem to be at least a couple of rather severe bugs in this release, for which I'm about to commit patches. I just wanted to give everyone a heads-up, because these issues are serious enough that you might want to reconsider upgrading to 1.11.0 until they're patched. (Although if I'm the only one who's noticed them, perhaps they're not so serious!) Also, I noticed a recent e-mail from Sandra Loevenich about a GFF3 import problem that sounds as though it could be caused by bug #3 on my list (see below.) So here's a quick rundown on the major issues: 1. Apollo crashes/hangs when displaying sequences that contain "Ns". It doesn't necessarily happen immediately, but as soon as you zoom far enough in on a region with Ns (e.g., by using the Ctrl-Z/zoom to feature shortcut) the main display will freeze and stop updating. I traced this to an apparently undocumented change in DNAUtils.java, which in version 1.10.0 was capable of reverse complementing sequences with Ns, but in 1.11.0 will throw an IllegalArgumentException if given an 'N' (see DNAUtils.complement) 2. After fixing bug #1 there's still a problem with zooming in too far in regions with Ns, this time an array out of bounds exception in ScaleView.drawGaps. I'm less sure of this one because I don't remember how coordinates are handled in Apollo, but comparing it to Sequence.getResiduesImpl I think it's fairly clear that the loop in drawGaps goes 1 base too far. I'm not sure how/when this change was introduced, but reducing the upper bound of the loop by 1 gets the gaps to render correctly in the example sequence I'm testing with. 3. (This may be the cause of Sandra's issue.) There's a logic error in GFF3Adapter, whereby the oboParser only gets initialized when getCurationSet() is called. This is fine if you load your original data from GFF and then attempt to layer additional GFF annotations (via addToCurationSet), but it's not so good if you load your original data from a different source (chado, chadoxml, etc.) and then try to layer GFF annotations on top. You'll get a NullPointerException on the oboParser, from what I remember. The fix is simply to move the oboParser initialization to a different method. 4. The NavigationBar is broken for the chado/JDBC adapter; whatever you tell it to do it just ends up reloading the same initial gene or region. There's a fix for this going into ChadoAdapter.java. 5. The chado/JDBC option searchHitsHaveFeatLocs cannot be set to false. It used to be supported, but appears to have been broken when the underlying SQL was modified. Set it to false and the adapter will generate invalid SQL. I started working on this but don't have a completed fix yet (mostly because I realized that I don't need it for our upcoming workshop.) That's all I've found so far. #1 and #2 are obviously the most serious, although the patches are extremely small. Let me know if you have trouble replicating any of these, or see any problems with the patches I'm about to commit. Jonathan
_______________________________________________ apollo mailing list [email protected] http://mail.fruitfly.org/mailman/listinfo/apollo
