get_counter for ASH

heeheehee

Developer
Staff member
I've been trying out a crude get_counter() ASH function, that basically acts like the existing get_counters() function, except it returns when an arbitrary matching counter will expire (as opposed to checking if a counter will expire within a given range of turns).

Do others want this? It's almost entirely a copy-paste of existing functions, and it's not very robust. (For instance, if there are multiple matches, it'll just print out the first one it sees, which may or may not be the smallest value.)

Also, I'm open to suggestions re: behavior. (Should we throw away the case-insensitive string matching entirely? the zone-based exclusions? return the minimum value, rather than the first match?)
 

Attachments

  • get_counter.patch
    2.9 KB · Views: 1

heeheehee

Developer
Staff member
(This is now r20885. Comments / criticisms / questions still welcome. Also I suppose at some point I should add a wiki page for it.)
 

MCroft

Developer
Staff member
This is breaking my tests, because the output isn't matching:
[]Manual (10)

get_counter.txt output does not match: expected:<...Unexpired counters:
[]Manual (10)

Returne...> but was:<...Unexpired counters:
[Vote Monster (12)
]Manual (10)

Returne...>

So it's not clearing the Vote Monster counter and it's returning it.

I can fix it by adding a couple of lines to get_counter.txt
Rich (BB code):
ash get_counter("Vote Monster")
counters clear
and and extra Returned: -1 to the .out file,

but I'm not sure if that's the right solution or why I'm getting an extra counter.
 

heeheehee

Developer
Staff member
What's setting the vote monster counter?

I'd guess the underlying problem is that some test isn't clearing state appropriately, and your tests are polluting global shared state. I'd prefer to add `counters clear` to the start of get_counters.txt, or better yet, to the end of whatever test you have that's setting Vote Monster so this doesn't cause order-dependent problems.
 

MCroft

Developer
Staff member
Um, it's a vanilla install of KM from kolmafia/kolmafia in a fresh directory and rebased.
 

heeheehee

Developer
Staff member
Fascinating, I can't reproduce with the following:

Bash:
$ git clone git@github.com:kolmafia/kolmafia.git --depth=1 &&  cd kolmafia && ./gradlew test
(shallow clone so I don't have to fetch 25k commits)

(and similarly, it seems odd for this to manifest now, since nobody else apparently has run into this, including in the various CI setups.)

That suggests to me that there's something external leaking into your test environment. You sure you don't have any untracked files under test/root?
 

Rinn

Developer
I had this test fail happen a few times intermittently locally when I was editing StaticEntity.java and running tests over and over earlier today trying to fix my bad github action. All the CI does clean builds so maybe it has something to do with incremental tests.
 

heeheehee

Developer
Staff member
@Rinn was it this specific test case failing in this manner, or CustomScriptTest in general?

Our Gradle build mostly doesn't do incremental tests at this time. There's an option to turn on Clover Test Optimization, but it's off for... reasons I don't entirely remember. Something to do with identifying the test sources, I think? Might be moot now.
 

MCroft

Developer
Staff member
Well, I was definitely doing that, but KM4 and KM5 were new (although made inside IJ).
KM7 was after I fixed my ssh-agent, and it failed the same when running your exact command line.

JVMs and MacOS vs. Others is my only thought. IDK.

Tried JVMs from 8 to 16, same error.
Rich (BB code):
2021-09-26T22:30:41.430-0500 [DEBUG] [TestEventLogger] CustomScriptTest STARTED
2021-09-26T22:30:41.430-0500 [DEBUG] [TestEventLogger]
2021-09-26T22:30:41.430-0500 [DEBUG] [TestEventLogger] CustomScriptTest > testScripts STARTED
2021-09-26T22:30:41.501-0500 [DEBUG] [TestEventLogger]
2021-09-26T22:30:41.501-0500 [DEBUG] [TestEventLogger] CustomScriptTest > testScripts FAILED
2021-09-26T22:30:41.501-0500 [DEBUG] [TestEventLogger]     org.junit.ComparisonFailure: get_counter.txt output does not match:  expected:<...Unexpired counters:
2021-09-26T22:30:41.501-0500 [DEBUG] [TestEventLogger]     []Manual (10)
2021-09-26T22:30:41.501-0500 [DEBUG] [TestEventLogger]
2021-09-26T22:30:41.501-0500 [DEBUG] [TestEventLogger]     Returne...> but was:<...Unexpired counters:
2021-09-26T22:30:41.502-0500 [DEBUG] [TestEventLogger]     [Vote Monster (12)
2021-09-26T22:30:41.502-0500 [DEBUG] [TestEventLogger]     ]Manual (10)
2021-09-26T22:30:41.502-0500 [DEBUG] [TestEventLogger]
2021-09-26T22:30:41.502-0500 [DEBUG] [TestEventLogger]     Returne...>
2021-09-26T22:30:41.502-0500 [DEBUG] [TestEventLogger]         at org.junit.Assert.assertEquals(Assert.java:117)
 
Last edited:

heeheehee

Developer
Staff member
Thanks.

I'd still like to figure out why VoteMonsterManager.checkCounter (which creates that counter) is being called in the first place, since it's possible some other unexpected state is being set, but only in some cases (OS-dependent?). There are three call sites that I saw in the code: 1) KoLCharacter, when refreshing a session; 2) QuestManager, to reset the counter when encountering the vote monster; and 3) RecoveryManager, for any between-battle checks.

To me, there's absolutely no reason the second one should be invoked. I can't see why the first would be invoked, either. The third... maybe from test_evilometer.txt? But that didn't reproduce in tests for me.
 

MCroft

Developer
Staff member
I added about a half dozen System.out.println(TurnCounter.CountCounters()); to assorted tests and never saw it until the script test.

So I’m also at a loss. Gradle will re-use Daemons, but I did a gradlew stop to test if that was happening to no effect.
 
Top