src

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Merge branch 'merge/develop_JAL-3725' into develop

Conflicts:

src/jalview/gui/PopupMenu.java

  1. … 2 more files in changeset.
Merge branch 'develop' into JAL-3416_different_look_and_feel_on_linux

Merge branch 'bug/JAL-3633_read_proxy_settings_from_jalview_properties_in_getdown' into develop

Conflicts:

src/jalview/bin/MemorySetting.java

    • -73
    • +179
    ./jalview/bin/MemorySetting.java
    • -0
    • +323
    ./jalview/jbgui/GPreferences.java
  1. … 4 more files in changeset.
Merge branch 'task/JAL-3763_newDatasetForCds' into merge/develop_task/JAL-3763_newDatasetForCds

Conflicts:

src/jalview/analysis/AlignmentUtils.java

src/jalview/util/MapList.java

test/jalview/util/MapListTest.java

test/jalview/util/MappingUtilsTest.java

    • -55
    • +41
    ./jalview/analysis/AlignmentUtils.java
    • -2
    • +4
    ./jalview/datamodel/SearchResults.java
    • -53
    • +53
    ./jalview/util/MappingUtils.java
  1. … 2 more files in changeset.
I know the problems you had with close() - you mentioned in the comments on the issue. However, you might have noticed that FileParse.close() is not called from many places, so changing its behavio...

I know the problems you had with close() - you mentioned in the comments on the issue. However, you might have noticed that FileParse.close() is not called from many places, so changing its behaviour wouldn't have too many side effects.

The intended pattern for FileParse.close() was:

ParserThing pt;
try {
pt = new <? assignable to FileParse>(data spec..)
.. do whatever needed to trigger parsing
.. then check pt's error/warning status and report any problems.
} catch (IOException ..) {
.. handle read or parse errors 
}
finally {
if (pt!=null) {
pt.close();
} // catch and report any IOErrors if desired
}
I tried this first, but FileParse.close() deliberately leaves the FileParse in an error state, which caused problems later (I don't remember the specifics). I could not work out why the FileParse.c...

I tried this first, but FileParse.close() deliberately leaves the FileParse in an error state, which caused problems later (I don't remember the specifics). I could not work out why the FileParse.close() was designed to do this but suspect changing this methos so it's (in general) not left in an error state will cause bigger problems. Also, since Jalview is used to having dataIn for the lifetime of the alignment, I wasn't sure if nulling the object would cause unforeseen errors (in e.g. filename etc).

Maybe it would be best to overload FileParse.close() to pass in an error value/message, then it would essentially be calling FileParse.closeDataIn() instead of FileParse.dataIn.close()

Agree with the finally {} – forgot that (not been a java programmer for quite long enough!). Presumably that should go in FileParse and not AlignFile too.

Ideally, any low level file ops should happen in the base class (FileParse) rather than here. AlignFile should call the FileParse.close() method rather than directly manipulate dataIn, which is man...

Ideally, any low level file ops should happen in the base class (FileParse) rather than here. AlignFile should call the FileParse.close() method rather than directly manipulate dataIn, which is managed by FileParse. Note that FileParse.close() nulls the dataIn reference so the stream can be garbage collected properly.

It's also good practice to try to close() in a finally {} clause, catching and reporting exceptions if needed... this is actually what the FileParse.close() method's design was intended for, since the caller should have already checked 'error' and 'errormessage' for parsing problems. Exceptions/Errors on close are not fatal for file import.

file close error will trash import of project

file close error will trash import of project

close filehandles straight after parse, without setting an error
close filehandles straight after parse, without setting an error
JAL-3703 fix Gff3 shared InputStream with embedded FASTA data

JAL-3703 fix Gff3 shared InputStream with embedded FASTA data

close filehandles straight after parse, without setting an error

Conflicts:

src/jalview/project/Jalview2XML.java

(locale aware PDBID string compare)

close filehandles straight after parse, without setting an error

JAL-3937 enable AIA download of intermediate certificates when needed

JAL-3937 enable AIA download of intermediate certificates when needed

JAL-3933 remove obsolete Castor logging configuration

JAL-3933 remove obsolete Castor logging configuration

JAL-3933 configure root logger console appender to stderr (2.11.2 version)

JAL-3933 configure root logger console appender to stderr

JAL-3933 Updated log4j jars with log4j-2.16.0 and compatibility API log4j-1.2-api-2.16.0. Stripped...
JAL-3933 Updated log4j jars with log4j-2.16.0 and compatibility API log4j-1.2-api-2.16.0. Stripped...
JAL-3933 updated log4j and slf4j jars with log4j1.2 compatibility API jar. Removed log4j from jabaws-min-client and Jmol jars

    • -1
    • +1
    ./jalview/javascript/log4j/Layout.java
  1. … 26 more files in changeset.
JAL-3933 Updated log4j jars with log4j-2.16.0 and compatibility API log4j-1.2-api-2.16.0. Stripped log4j classes from jabaws-min-client jar. Updated sl4j jars in j8lib

  1. … 18 more files in changeset.
JAL-3829 isCanonical should by default be false - ensure JalviewJS offers 3d-beacons search for example project

JAL-3855 JAL-3829 don’t need to make up alphafold model retrieval URL when we’ve been given it

    • -1
    • +1
    ./jalview/gui/StructureViewerBase.java
    • -0
    • +9
    ./jalview/ws/dbsources/EBIAlfaFold.java
JAL-3929 preserve lowercase pdbid in group name for transferred features

JAL-3929 don’t use the url encoded pdbId in feature group when transferring features from associated structure to a sequence