jalview

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
JAL-3137 tests are for linux only

Merge branch 'merge/develop_JAL-3725' into develop

Conflicts:

src/jalview/gui/PopupMenu.java

  1. … 2 more files in changeset.
JAL-3763 (for whatever reason) need to increase timeout for command line ops to 10.5s (OSX Monterey, MBP late 2018)

JAL-3763 (for whatever reason) need to increase timeout for command line ops to 10.5s (OSX Monterey, MBP late 2018)

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

  1. … 5 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.

JAL-3703 patch Windows save file test for 2.11.1 codebase

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 Test that fails in Windows only, and only when the file handle isn't relinquished

    • -0
    • +93
    ./io/WindowsFileLoadAndSaveTest.java
JAL-3703 Test that fails in Windows only, and only when the file handle isn't relinquished

    • -0
    • +93
    ./io/WindowsFileLoadAndSaveTest.java
JAL-3066 Fix ambiguous assertEquals casting values to double.

    • -17
    • +17
    ./util/HMMProbabilityDistributionAnalyserTest.java
JAL-3855 verify pdb suffix is preserved when locally loaded file is saved in project and imported

JAL-3829 remove duplicate IDs in 3DBeacons generated PDBFTS query and update mocks

    • -329
    • +333
    ./fts/service/pdb/PDBFTSRestClientTest.java
    • -1016
    • +1012
    ./fts/threedbeacons/p01308_pdbfts_resp.txt
  1. … 1 more file in changeset.
JAL-3919 use model format field to ensure we get the file extension correct when creating temp files for structure viewers

    • -1
    • +1
    ./fts/threedbeacons/p01308_tdb_resp.txt
  1. … 3 more files in changeset.
JAL-3875 test case and patch to verify the query 3d beacons button is shown for proteins with uniprot ids but no canonical accessions

  1. … 1 more file in changeset.
JAL-3904 failing test

    • -2
    • +30
    ./ext/rbvi/chimera/JalviewChimeraView.java
  1. … 2 more files in changeset.
JAL-3878 Add getCalcName to AlignCalcWorkerI.

getCalcName() can be used to identify services that run the calculator.

when an alternative calculator (different host or parameters) is created

the old ones sharing the name can be stopped.

  1. … 8 more files in changeset.
JAL-3878 Add getCalcName to AlignCalcWorkerI.

getCalcName() can be used to identify services that run the calculator.

when an alternative calculator (different host or parameters) is created

the old ones sharing the name can be stopped.

  1. … 8 more files in changeset.
SequencesInfo which is an individual object is doable, but I feel like it would be just a wrapper around a Map. What additional functionality would SequencesInfo have over a traditional Map? I'm n...

SequencesInfo which is an individual object is doable, but I feel like it would be just a wrapper around a Map. What additional functionality would SequencesInfo have over a traditional Map?

I'm not very familiar with serialization in java, I know there are libraries that can serialize beans to json or xml, but what are your expectations in this case?

one class with a static factory method seems to be better than two classes and an external mutable object.

one class with a static factory method seems to be better than two classes and an external mutable object.

What's wrong with static classes? They are just like regular classes but within other class' namespace. That's non-static inner classes that are special. About factory pattern, I think it would be ...

What's wrong with static classes? They are just like regular classes but within other class' namespace. That's non-static inner classes that are special.
About factory pattern, I think it would be an overkill for a class that is only used by SeqsetUtils' methods.

yes, I see that, but do you really need a nested static class ? in line with my general comments re encapsulating the Map<String,SequenceInfo> further: perhaps it might make sense to simply apply a...

yes, I see that, but do you really need a nested static class ? in line with my general comments re encapsulating the Map<String,SequenceInfo> further: perhaps it might make sense to simply apply a factory pattern rather than have an internal bean that a generic map holds references to ?

(lets not get stuck on this though, the main thing is that the implementation works fine for now, though needs more work in order to save/restore sequenceInfo objects from Jalview project files)

Because it's instantiated in a static context e.g. uniquify and it does not need an instance of SeqsetUtils object to work.

Because it's instantiated in a static context e.g. uniquify and it does not need an instance of SeqsetUtils object to work.

we won't see this messages unless asserts are enabled. Cache.log.warn is perhaps better ?

we won't see this messages unless asserts are enabled. Cache.log.warn is perhaps better ?

it's a reasonable first pass, though stylistically all you've done is transformed a single concrete instance (Hashtable) to a more strongly typed verbose instance (Map<String,SequenceInfo>). Why no...

it's a reasonable first pass, though stylistically all you've done is transformed a single concrete instance (Hashtable) to a more strongly typed verbose instance (Map<String,SequenceInfo>). Why not go further and have a SequencesInfo object that records metadata for one or more sequences ?

There are also other requirements: SequenceInfo sets will need to be persisted for a web services job. You could expand JAL-3899 to incorporate this perhaps - JAL-1786 is the relevant epic for that.