project

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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
close filehandles straight after parse, without setting an error

Conflicts:

src/jalview/project/Jalview2XML.java

(locale aware PDBID string compare)

  1. … 1 more file in changeset.
close filehandles straight after parse, without setting an error

  1. … 1 more file in changeset.
JAL-3691 automatic insertion of Locale.ROOT to toUpperCase() and toLowerCase() and added import java.util.Locale appropriately

  1. … 102 more files in changeset.
JAL-3863 add canonical DBRefEntry flag to Jalview project

  1. … 26 more files in changeset.
JAL-3863 add canonical DBRefEntry flag to Jalview project

  1. … 26 more files in changeset.
JAL-1713 restore project with no Overview, regardless of Preferences

  1. … 1 more file in changeset.
JAL-1713 close and replace auto-opened Overview with restored Overview

  1. … 3 more files in changeset.
Merge branch 'Jalview-JS/develop' into merge_js_develop also patched new code from JAL-3690 refactorings

  1. … 56 more files in changeset.
JAL-1713 renamed method to OverviewPanel.get/setFrameBounds()

  1. … 1 more file in changeset.
JAL-1713 JAL-3119 JAL-3785 refactored get/set Overview bounds and title

  1. … 5 more files in changeset.
JAL-1713 read/set OverviewPanel geometry on parent JInternalFrame

JAL-1713 save Overview title in project, don't save Overview on New View

  1. … 3 more files in changeset.
JAL-1713 save/restore Overview in project (todo: restore geometry)

Agreed. I seem to remember (this was a while ago now) that I found isAMacAndNotJS() and thought it might be an important distinction. Sounds like it's just redundant? Can tidy this another time then.

Agreed. I seem to remember (this was a while ago now) that I found isAMacAndNotJS() and thought it might be an important distinction. Sounds like it's just redundant? Can tidy this another time then.

Agree this is just touching on a much bigger task. However... The reason I /needed/ to do this rather than just /wanted/ to do this is that several of the classes I've been working on (e.g. jalview...

Agree this is just touching on a much bigger task.
However...
The reason I /needed/ to do this rather than just /wanted/ to do this is that several of the classes I've been working on (e.g. jalview.bin.Launcher, jalview.bin.HiDPISetting, jalview.bin.MemorySetting) run very early on (especially jalview.bin.Launcher!). This means Cache.log has perhaps not yet been initialised, so a Cache.log.debug doesn't log (unless you count reams of NullPointerExceptions as logging!).

In the case of HiDPISetting and MemorySetting that also get used in Getdown, where there is no jalview.bin.Cache, they currently have to use System.out and System.err [or maybe I could stub jalview.bin.Cache too]. I'd prefer them to use Cache.log when they can so this is an attempt at starting to decouple jalview.bin.Cache from other jalview things so it can be used standalone within Getdown. The main reason for wanting to do that is to have shared code to read the preferences between Jalview and Getdown.

I think there are lots of things that could be tidied up (particularly the overloading and additional logging functions via Cache which don't really reduce code at point of use, but are certainly u...

I think there are lots of things that could be tidied up (particularly the overloading and additional logging functions via Cache which don't really reduce code at point of use, but are certainly useful in spirit), but now is most definitely not the time to optimise and beautify code.

Ben Soares as far as I can see the only thing missing after this branch is merged to develop is this logic. I just did a quick test and it appears 'Platform.isAMac()' returns false under JalviewJS,...

Ben Soares as far as I can see the only thing missing after this branch is merged to develop is this logic. I just did a quick test and it appears 'Platform.isAMac()' returns false under JalviewJS, so probably not a dealbreaker. Do you agree ?

JAL-3608 cherry pick of 92cb745e7
JAL-3608 cherry pick of 92cb745e7
JAL-3775 Eclipse re-formatting commit

  1. … 5 more files in changeset.
JAL-3705 JAL-3251 unused attribute repurposed/renamed to mappedFromId

  1. … 2 more files in changeset.
JAL-3705 unit test and "fix" borrowing unused schema attribute

  1. … 1 more file in changeset.
JAL-3633 ensure check both http:// or https:// for urls

  1. … 3 more files in changeset.
JAL-3633 ensure check both http:// or https:// for urls

  1. … 3 more files in changeset.
JAL-3633 ensure check both http:// or https:// for urls

  1. … 3 more files in changeset.