Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
JAL-4026 increase timeouts for command line ops

JAL-3746 apply copyright to tests

  1. … 73 more files in changeset.
JAL-3438 spotless for 2.11.2.0

  1. … 659 more files in changeset.
JAL-3438 - all src and test run through spotless..

  1. … 666 more files in changeset.
Merge branch 'update/JAL-3949_jalview_bin_Console_to_cure_sanity_even_more' into develop

Conflicts:

test/jalview/bin/CommandLineOperations.java

JAL-3949 fix testProps path and make line count more accurate

JAL-3949 increase command line ops test timeout

JAL-3949 ensure Jalview command line ops setup actually quits after SETUP_TIME milliseconds - seems there’s less stderr noise than before !

That looks good. I was almost going to do something similar (I was thinking jalview.log.Log, but jalview.bin.Console is just as good) so happy with this!

That looks good. I was almost going to do something similar (I was thinking jalview.log.Log, but jalview.bin.Console is just as good) so happy with this!

Added those in. I'm still converting to String with getCanonicalName in the getLogger(Class ...) method because, e.g. JLogger jlogger1 = JLogger.getLogger(Jalview.class); JLogger jlogger2 = JLogger...

Added those in. I'm still converting to String with getCanonicalName in the getLogger(Class ...) method because, e.g.
JLogger jlogger1 = JLogger.getLogger(Jalview.class);
JLogger jlogger2 = JLogger.getLogger("jalview.bin.Jalview");
should really return an existing logger in the registry if it exists, and the String name is the registry key.

I was thinking that JLogger did this comparison anyway, but I've followed it through and it didn't. So I've added if (loglevel.compareTo(this.level) < 0) { return false; } to JLogger.println so t...

I was thinking that JLogger did this comparison anyway, but I've followed it through and it didn't. So I've added

if (loglevel.compareTo(this.level) < 0) { return false; }

to JLogger.println so that a comparison is made between the (enums) of JLogger.level and the message LogLevel, and if it's not going to be logged then it doesn't call the actual logger at all (in this case Log4j, so the log4j object is never even touched [even with logger.isDebugEnabled() because the answer should be no]).
This now applies to all log calls.
The check whether Cache.log != null is equivalent to Cache.log.loggerExists() which already happens within JLoggerLog4j.
There is admittedly the wrapper of the JLogger getting brought to forefront of memory, but that's presumably smaller than the old Cache.log which was a Log4j.Logger object.

JAL-3949 fixed failing commandlinetests due to more output and line count limit

AWESOME JOB !!!! one tiny niggle I had was that Cache.debug/Cache.error doesn't read nicely, so I've abstracted the logging stuff even farther to a new jalview.bin.Console class: see https://source...

AWESOME JOB !!!! one tiny niggle I had was that Cache.debug/Cache.error doesn't read nicely, so I've abstracted the logging stuff even farther to a new jalview.bin.Console class: see https://source.jalview.org/crucible/changelog/~br=update%402fJAL-3949_jalview_bin_Console_to_cure_sanity_even_more/jalview/

the reason for conditionals is that Java won't perform the string append operation if logLevel>debug. It saves a minor amount of processing time which is important for code that is executed lots.

the reason for conditionals is that Java won't perform the string append operation if logLevel>debug. It saves a minor amount of processing time which is important for code that is executed lots.

You could have .getLogger(Class ..) rather than having to call getCanonicalName ?

You could have .getLogger(Class ..) rather than having to call getCanonicalName ?

JAL-3949 An attempt at converting to Log4j 2 -- no output achieved!
JAL-3949 An attempt at converting to Log4j 2 -- no output achieved!
JAL-3137 tests are for linux only

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)

JAL-2909 increase commandlinetests timeout

JAL-3775 added the Platform.isLinux() check for test HiDPISetting2

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-3609 JAL-3775 Tests for jalview.bin.HiDPISetting

    • -0
    • +116
    ./HiDPISettingTest1.java
    • -0
    • +223
    ./HiDPISettingTest2.java
    • -0
    • +15
    ./hidpiTestProps.jvprops
  1. … 1 more file in changeset.
JAL-3477 Added 10k leeway to amount of memory reserved for OS test for float rounding errors (needed to fix failing test)