|
|
 |
- last updated a few seconds ago
Monday 08 Jun 2020
-
-
… 15 more files in
changeset.
Wednesday 03 Jun 2020
I suggest we close this. It's all ancient history now.
I suggest we close this. It's all ancient history now.
Friday 29 May 2020
JAL-3626 issue #2 - Jmol not loading from JVP - just a versioning issue with core_jvjmol - updated jmol-app.zip - updated SwingJS-site.zip - buildcore.xml creates core_jvjmol.z.js
-
-
… 5 more files in
changeset.
Friday 20 Mar 2020
JAL-3560 additional _j2sclasslist.txt fix
JAL-3560 adds swingjs/api/JSUtilI.js interface to _j2sclasslist.txt
Thursday 19 Mar 2020
SwingJS runtime update 3.2.9-v1b - mostly fixes from recent SwingJS work involving -- expanded FileSystem and temp file management -- super-fast HashMap (faster than Java!), HashTable, StringBuilder, StringBuffer, NumberFormat, DecimalFormat -- improved ResourceBundle -- full Locale information -- additional BufferedImage/ColorModel/Raster support - fixes temp files not cached (JSTempFile, for Jmol) - fixes AbstractStringBuilder.replace() typo - reverts recent HashSet acceleration due to Jalview using String.hashCode() for display order of features
-
-
… 9 more files in
changeset.
Wednesday 18 Mar 2020
JAL-3560 fixes _j2sclasslist.txt transpiler 3.9.1 is NOT backward compatible. It corrects an earlier implementation of generic class method references. So everything does need rebuilding. Jmol isn't rebuilt yet.
Wednesday 30 Oct 2019
JAL-3210 Fixed jalviewjs dependencies. Changed linkCheck to tee output to .out file. Tidying jalviewjs paths.
-
-
… 3 more files in
changeset.
Sunday 06 Oct 2019
updated _j2sclasslist.txt and _j2sclasslist_jmol.txt
-
-
… 1 more file in
changeset.
Thursday 03 Oct 2019
Method only called from test code and lacks documentation to state what it returns. Replaced with use of PrivilegedAccessor in the tests.
Method only called from test code and lacks documentation to state what it returns. Replaced with use of PrivilegedAccessor in the tests.
No unit test for this method. As currently coded, if a single feature of type X is added, then deleted, hasFeatures(X) then returns true. Need to add a second test && !featureStore.get(type).isEmpt...
No unit test for this method. As currently coded, if a single feature of type X is added, then deleted, hasFeatures(X) then returns true. Need to add a second test && !featureStore.get(type).isEmpty() Could possibly also, in SequenceFeatures.delete(SequenceFeature), remove the FeatureStore from the map if it becomes empty. However this creates thread-safety dangers so is probably not worth doing.
Method throws NullPointerException if there is no FeatureStore (no features stored) for the given feature type, as easily shown with a unit test. It is not an answer to say "oh but this is checked ...
Method throws NullPointerException if there is no FeatureStore (no features stored) for the given feature type, as easily shown with a unit test. It is not an answer to say "oh but this is checked by Sequence.hasFeatures(type) before calling this method". Methods must be robust to any usage, current or future. Check for null, and unit tests, added.
Tuesday 01 Oct 2019
JAL-3437 issue with System.getProperty("javax.xml.datatype.DatatypeFactory") 1/2 ?
-
-
… 6 more files in
changeset.
Friday 27 Sep 2019
hidden colour is only used by OverviewRenderer but is passed around between OverviewCanvas and OverviewResColourFinder constructors. Just keep it in OverviewRendere only.
hidden colour is only used by OverviewRenderer but is passed around between OverviewCanvas and OverviewResColourFinder constructors. Just keep it in OverviewRendere only.
Thursday 26 Sep 2019
tldr but I've changed the code back to the way it was, since this was a functional change (could result in different colour drawn).
tldr but I've changed the code back to the way it was, since this was a functional change (could result in different colour drawn).
Friday 20 Sep 2019
I'm confused. You removed the Graphics2D field in SeqCanvas with the comment // Don't do this! Graphics handles are supposed to be transient so does that not also apply here?
I'm confused. You removed the Graphics2D field in SeqCanvas with the comment // Don't do this! Graphics handles are supposed to be transient so does that not also apply here?
Thursday 19 Sep 2019
In 2.11, scrollY is always zero in this method. Why the change?
In 2.11, scrollY is always zero in this method. Why the change?
Wednesday 18 Sep 2019
I see what you mean, sure. Probably ensureFinalized at least, and maybe others should be indicated as synchronized, as it does major fixing of the database. This ret[] could be created locally; it'...
I see what you mean, sure. Probably ensureFinalized at least, and maybe others should be indicated as synchronized, as it does major fixing of the database. This ret[] could be created locally; it's not a big deal to make a single array each findOverlaps call, probably, if this is a concern. This is now in IntervalStore0.
Tuesday 17 Sep 2019
method needs Javadoc - what does it do?
method needs Javadoc - what does it do?
Not convinced this is even needed. The box is resized when the font size is changed, so no need to repeat on OK (which just closes the dialog). OverviewDimensions.drawBox() is called from OverviewC...
Not convinced this is even needed. The box is resized when the font size is changed, so no need to repeat on OK (which just closes the dialog). OverviewDimensions.drawBox() is called from OverviewCanvas.paintComponent(). Not sure whether this is an unintended (but useful) repaint or explicitly scheduled.
Added Javadoc to clarify that the BitSet returned is valid at a point in time but doesn't update if columns are revealed or hidden.
Added Javadoc to clarify that the BitSet returned is valid at a point in time but doesn't update if columns are revealed or hidden.
Do we still need this class? Given that bin.Jalview can parse url query parameters.
Do we still need this class? Given that bin.Jalview can parse url query parameters.
That works. I have gone for the equivalent but simpler - just pass a flag for 'compareBegin' (true : use begin, false : use end) rather than a function. Comes to the same thing. No loss of generali...
That works. I have gone for the equivalent but simpler - just pass a flag for 'compareBegin' (true : use begin, false : use end) rather than a function. Comes to the same thing. No loss of generality as IntervalI has nothing else that could be extracted as a value. My original BinarySearcher(List<T>) could be generalised to any type, with a function extracting any value, and another applying any test, but a heck of a lot of object creation involved, so I ditched that idea.
It works fine as long as the methods only read instance fields and don't update them. No conflict arises. If two threads might update a field (such as IntervalStore0.ret) then conflict can arise.
It works fine as long as the methods only read instance fields and don't update them. No conflict arises. If two threads might update a field (such as IntervalStore0.ret) then conflict can arise.
Saturday 07 Sep 2019
Hmm. Wasn't that my point? I think we are in agreement. Probably should add a JavaDoc note to the effect that it WILL throw that exception despite the fact that it is optional. Object.equals() does...
Hmm. Wasn't that my point? I think we are in agreement. Probably should add a JavaDoc note to the effect that it WILL throw that exception despite the fact that it is optional. Object.equals() doesn't have any mention of throwing ClassCastException. Every such implementation I have ever seen first checks for not implementing the class for a false return.
AbstractCollection.contains() declares ClassCastException because it may be thrown by the calls to equals() in the loop. It is up to the implementation of equals() whether it checks instanceof, cat...
AbstractCollection.contains() declares ClassCastException because it may be thrown by the calls to equals() in the loop. It is up to the implementation of equals() whether it checks instanceof, catches and handles the exception, or lets it be thrown.
Friday 06 Sep 2019
Just make sure there is no type checking in anything that is done during normal processing. Actually, that's not quite true: Collection.contains: https://docs.oracle.com/javase/8/docs/api/java/ut...
Just make sure there is no type checking in anything that is done during normal processing. Actually, that's not quite true: Collection.contains: https://docs.oracle.com/javase/8/docs/api/java/util/Collection.html#contains-java.lang.Object- boolean contains(Object o) Returns true if this collection contains the specified element. More formally, returns true if and only if this collection contains at least one element e such that (o==null ? e==null : o.equals(e)). Parameters: o - element whose presence in this collection is to be tested Returns: true if this collection contains the specified element Throws: ClassCastException - if the type of the specified element is incompatible with this collection (optional) Also, despite the fact that AbstractCollection.contains() does not throw that exception (I agree there), it's JavaDoc says it does: /**
Unknown macro: {@inheritDoc} *
- <p>This implementation iterates over the elements in the collection,
- checking each element in turn for equality with the specified element.
*
- @throws ClassCastException
*/
Note remove(Object) fails with ClassCastException if passed an object of the wrong type. Compare AbstractCollection.remove() which tests every entry returned by iterator() for equals(). This would ...
Note remove(Object) fails with ClassCastException if passed an object of the wrong type. Compare AbstractCollection.remove() which tests every entry returned by iterator() for equals(). This would normally include the type check, so not throw an exception. Unlikely to cause any problem!
Note contains(Object) fails with ClassCastException if passed an object of the wrong type. Compare AbstractCollection.contains() which tests every entry returned by iterator() for equals(). This wo...
Note contains(Object) fails with ClassCastException if passed an object of the wrong type. Compare AbstractCollection.contains() which tests every entry returned by iterator() for equals(). This would normally include the type check, so not throw an exception. Unlikely to cause any problem!
|