r25747 - Upgrade swingx to 1.6.1. (fia/pull/79']#79) * Upgrade swingx to 1.6.1. * Force update for each

Github Bot · Oct 5, 2021

Upgrade swingx to 1.6.1. (#79)

* Upgrade swingx to 1.6.1.

* Force update for each change to LockableListModel.

AutoFilterTextField had some cases where it did not update this
properly.

* Remove param from LockableListModel.updateFilter.

This parameter is error-prone and can readily cause the ListModel to
get out of sync with anything that's watching it.

We may see a slight performance hit from propagating updates more
frequently.

* Remove remaining traces of toCopy source set.

We used this briefly for downloading jars for the Ant build.

Since the Ant build is no more, this is no longer necessary.

* Update AutoFilterTextField.java

Co-authored-by: jaadams5 <82782908+jaadams5@users.noreply.github.com>

View on Github

Veracity · Oct 5, 2021

This broke "gradlew jar".

The following section of build.gradle:

Code:

configurations {
    toCopy
    implementation.canBeResolved = true
}

Was removed. I assume that was part of "Remove remaining traces of toCopy source set."
However, without the other line, "gradlew jar" throws an exception at line 166.

Code:

    from { configurations.implementation.collect { it.isDirectory() ? it : zipTree(it) } } {

specifically complaining that implementation.canBeResolved is false.

I put back:

Code:

configurations {
    implementation.canBeResolved = true
}

at line 47 and "gradlew jar" works again.

heeheehee · Oct 5, 2021

Ah, my bad. I'll send a fix for that.

heeheehee · Oct 5, 2021

(In the meanwhile, you should be able to use the shadowJar target, which should still work.)

Veracity · Oct 5, 2021

What is the difference between "shadowJar" and "jar"?

I use "jar".

Code:

$ ./gradlew jar
...
BUILD SUCCESSFUL in 2s
6 actionable tasks: 1 executed, 5 up-to-date
bash-3.2$ ls -l dist
total 40968
-rw-r--r--  1 pld  admin  20395226 Oct  5 17:39 KoLmafia-25747-M.jar
bash-3.2$ java -jar dist/KoLmafia-25747-M.jar 

KoLmafia r25747-M
Build main 28affc903cf4c8469c09f824bbe27358adbbccd4 17 (Eclipse Adoptium 17+35) Mac OS X aarch64 11.6

Currently Running on Mac OS X
Local Directory is /Users/pld/Library/Application Support/KoLmafia
Using Java 17

Running that and opening a gCLI window:

Code:

> svn update

Checking all SVN projects...
clilinks is at HEAD (r6)
Ezandora-FantasyRealm-branches-Release is at HEAD (r27)
balefull-raidlog-parser-branches-master is at HEAD (r3)
Ezandora-Guide-branches-Release is at HEAD (r545)
bale-ns-tower-relay is at HEAD (r1)
...
Updating all SVN projects...
Validating repo...
Repo validated.
Updating Loathing-Associates-Scripting-Society-autoscend-branches-master-RELEASE...
/Users/pld/Library/Application Support/KoLmafia/svn/Loathing-Associates-Scripting-Society-autoscend-branches-master-RELEASE
svn: E170009: Repository UUID '0c147794-3640-6fa4-363d-ce57b7db7bff' doesn't match expected UUID 'fc03b040-7c33-4b10-e420-ce57b7db7bff'
Done.
...
Requests complete.

That's normal. Let's try "shadowJar".

Code:

$ ./gradlew shadowJar
...
BUILD SUCCESSFUL in 706ms
6 actionable tasks: 1 executed, 5 up-to-date
bash-3.2$ ls -l dist
total 40968
-rw-r--r--  1 pld  admin  20680041 Oct  5 17:34 KoLmafia-25747-M.jar
$ java -jar dist/KoLmafia-25747-M.jar 

KoLmafia r25747-M
Build main 28affc903cf4c8469c09f824bbe27358adbbccd4 17 (Eclipse Adoptium 17+35) Mac OS X aarch64 11.6

Currently Running on Mac OS X
Local Directory is /Users/pld/Library/Application Support/KoLmafia
Using Java 17

Running that and opening a gCLI window:

Code:

> svn update

Checking all SVN projects...
balefull-raidlog-parser-branches-master is at HEAD (r3)
bale-ns-tower-relay is at HEAD (r1)
bale-counterchecker is at HEAD (r23)
bale-dinsey is at HEAD (r3)
bale-relay-manor_unlockInfo is at HEAD (r139)
bale-spelunky is at HEAD (r4)
batbrain is at HEAD (r143)
bale-relay-Monster_Manuel_Improvement is at HEAD (r139)
bale-ltt is at HEAD (r6)
bale-new-life is at HEAD (r70)
Updating all SVN projects...
Checking for working copy modifications...
svn: E155007: '/Users/pld/Library/Application Support/KoLmafia/svn/veracity0-spacegate' is not a working copy
svn: E155007: '/Users/pld/Library/Application Support/KoLmafia/svn/veracity0-spacegate' is not a working copy
Requests complete.

That's broken.

Veracity · Oct 5, 2021

Actually:

Code:

> svn update

Checking all SVN projects...
...
Loathing-Associates-Scripting-Society-autoscend-branches-master-RELEASE needs updating from (r3573) to (r4388)
...
Updating Loathing-Associates-Scripting-Society-autoscend-branches-master-RELEASE...
/Users/pld/Library/Application Support/KoLmafia/svn/Loathing-Associates-Scripting-Society-autoscend-branches-master-RELEASE
svn: E170009: Repository UUID '0c147794-3640-6fa4-363d-ce57b7db7bff' doesn't match expected UUID 'fc03b040-7c33-4b10-e420-ce57b7db7bff'
...
Requests complete

doesn't look normal, does it? Well, I don't actually use autoscend,, but I have it so I can look at it if I want to.

heeheehee · Oct 5, 2021

Hm, fascinating. So it's a SVN issue? Nothing weird going on in that directory (spacegate), I suppose?

Veracity · Oct 5, 2021

No. VeracitySpacegate script works just fine.

Notice that with "shadowJar", "svn update" seems to check scripts alphabetically - and only looks at "bale" scripts - whereas with "jar", it looks at scripts in some random order and sees a whole bunch more of them. (I truncated the output).

fronobulax · Oct 5, 2021

There were some issues when GitHub deprecated master as a top level name. After a lot of finger pointing, IIRC, the only solution for KoLmafia users was to delete the script and reinstall it, making sure the .svn subdirectory was deleted, one way or another, before reinstall.

Repository checks are threaded. Perhaps there is something related to timing that makes the jars behave differently? I would try setting svnThreadPoolSize to 1, (if it isn't) to eliminate that as a possibility.

KoLmafia uses an old version of SVN. I once upgraded TorotiseSVN and used it to access .svn directories. It really wanted to upgrade the directories and when I let it do one, KoLmafia no longer considered it a valid local repository. Manually delete and reinstall

Obviously a red herring if your tools have not changed or you don't use them directly on .svn directories.

Veracity · Oct 5, 2021

The question is, why does “jar” work and “shadowJar” doesn’t? What is different?

MCroft · Oct 6, 2021

Veracity said:
The question is, why does “jar” work and “shadowJar” doesn’t? What is different?

ShadowJar builds a fat jar, so it may be bringing in a different SVNkit than you have locally.

If you look inside the fat Jar and the skinny jar, you might see difference in that include.

MCroft · Oct 6, 2021

If I convert my jar to a zip and unzip it, it has a file called svnkit.build.properties at the top level with the following text. For me both versions are identical, so that's not necessarily it.

Bash:

Michaels-MBP:KM mcroft$ cat svnkit.build.properties
svnkit.version=1.10.3
build.number=r10808

#properties for SVN runtime
svnkit.version.string=SVN/1.10.0 SVNKit/1.10.3 (http://svnkit.com/) r10808
svnkit.version.major=1
svnkit.version.minor=10
svnkit.version.micro=3
svnkit.version.revision=r10808

svnkit.svn.version=1.10.0

nothing special there.

I also note there there is a file size difference between the two jars, and I'm not sure why.

heeheehee · Oct 6, 2021

I'm actually seeing differences in the direction I wouldn't expect.

Code:

$ unzip -l skinny.jar | awk '{print $1"\t"$4;}' | sort -k 2 > skinny.txt
$ unzip -l fat.jar | awk '{print $1"\t"$4;}' | sort -k 2 > fat.txt
$ diff -u fat.txt skinny.txt > jar.diff

There are a number of classes with different sizes, but fat.jar is also missing various cross-platform classes.

heeheehee · Oct 6, 2021

(Note that while jar.diff seems to be cut off abruptly, that's because there are no diffs in file listings alphabetically after org/antlr, including for all of org/tmatesoft. Also note that this approach of comparing archive contents can have false negatives, since it only compares file sizes. But it's a useful proxy.)

MCroft · Oct 6, 2021

Veracity said:

Actually:

Code:

> svn update

Checking all SVN projects...
...
Loathing-Associates-Scripting-Society-autoscend-branches-master-RELEASE needs updating from (r3573) to (r4388)
...
Updating Loathing-Associates-Scripting-Society-autoscend-branches-master-RELEASE...
/Users/pld/Library/Application Support/KoLmafia/svn/Loathing-Associates-Scripting-Society-autoscend-branches-master-RELEASE
svn: E170009: Repository UUID '0c147794-3640-6fa4-363d-ce57b7db7bff' doesn't match expected UUID 'fc03b040-7c33-4b10-e420-ce57b7db7bff'
...
Requests complete

doesn't look normal, does it? Well, I don't actually use autoscend,, but I have it so I can look at it if I want to.

That is a lot of versions to jump. I assume your svnrepo.json is well-formed? there are people who are having trouble with it.

Here's my svn update output from shadowJar. It looks right to me.

Rich (BB code):

> svn update

Checking all SVN projects...
cdrock-TourGuide-branches-Release is at HEAD (r988)
Loathing-Associates-Scripting-Society-autoscend-branches-master-RELEASE is at HEAD (r4388)
zap-wand is at HEAD (r2)
Ezandora-Far-Future-branches-Release is at HEAD (r40)
Ezandora-Helix-Fossil-branches-Release is at HEAD (r23)
standard-rollover-bonus is at HEAD (r10)
veracity0-meat-farm is at HEAD (r294)
BadHorseMonkey-Mafia-Ashtest.git-trunk is at HEAD (r12)
zlib is at HEAD (r52)
Ezandora-Comb-Beach-trunk-Release is at HEAD (r10)
ccascend-snapshot is at HEAD (r1471)
Ezandora-Detective-Solver-branches-Release is at HEAD (r19)
veracity0-vcon is at HEAD (r294)
gausie-excavator-trunk-RELEASE is at HEAD (r182)
veracity0-vprops is at HEAD (r294)
Ezandora-Voting-Booth-trunk-Release is at HEAD (r8)
bale-ocd is at HEAD (r46)
bale-relay-desc_wikiLinks is at HEAD (r139)
therazekolmafia-canadv is at HEAD (r112)
veracity0-garden is at HEAD (r294)
winterbay-mafia-autobasement is at HEAD (r44)
guyymafia-tricktreat is at HEAD (r274)
Loathing-Associates-Scripting-Society-ChIT-branches-main-src is at HEAD (r1534)
docrostov-ScotchLog-branches-master-KoLmafia is at HEAD (r29)
Updating all SVN projects...
Checking for working copy modifications...
M /Users/mcroft/Library/Application Support/KoLmafia/svn/Loathing-Associates-Scripting-Society-autoscend-branches-master-RELEASE/scripts/autoscend.ash
Synchronizing with local copies...
Sync complete.
Requests complete.

fronobulax · Oct 6, 2021

I just built jar, ran and then shadowjar and ran. I set

_svnRepoFileFetched=false
_svnUpdated=false

before each run. The remote repositories appeared in the log in alphabetical order and the same order in both logs.

I then changed svnThreadPoolSize from 1 to 5 and reran. All the same directories were checked but they order they appeared in the log was different.

Java 17, Windows 10.

Not sure what the relevance is.

None of my installed scripts have had an update since 9/7 which could mean there is something broken, or maybe the authors are on a long vacation.

r25747 - Upgrade swingx to 1.6.1. (fia/pull/79']#79) * Upgrade swingx to 1.6.1. * Force update for each

Github Bot

Poster of Commits

Veracity

Developer

heeheehee

Developer

heeheehee

Developer

Veracity

Developer

Veracity

Developer

heeheehee

Developer

Veracity

Developer

fronobulax

Developer

Veracity

Developer

MCroft

Developer

MCroft

Developer

heeheehee

Developer

Attachments

heeheehee

Developer

MCroft

Developer

fronobulax

Developer