Recent content by heeheehee

Github Actions compile that into JS on the `release` branch after each commit that's pushed to `main`. https://github.com/loathers/excavator/blob/main/.github/workflows/deploy_script.yml If you want to compile this yourself, you'll have to install one of the various TS -> JS transpilers...

> 503/429 messages, since that mechanism is designed to cover cases of scheduled maintenance with a known end-period Incidentally, that's not how I view either of those status codes. 429 ("Too many requests") serves a purpose directly related to Retry-After in terms of throttling, and it seems...

If "modtrace liver" does nothing, then that's a distinct problem (namely: unrelated to the modifier passive skill cache). From looking at the commit: visiting the wereprofessor research bench to look at your current upgrades should update your preferences appropriately. If that's not happening...

To clarify: previously both "feature" and "feature - implemented" were the same shade of light green. The current status is a strict improvement over that.

Closing with "Not a bug" since it was apparently a Chrome bug. Either way, it's unlikely we can do anything about it on Mafia's end if it comes back.

I think it makes sense to differentiate between Feature and "Feature - Implemented" / "Bug Fixed", at the very least. So no objections from me re: new colors.

r27837 fixes the debug log that Boesbert reported.

Hm. That last one is a different stack trace, where AscensionClass might never be initialized (and therefore is still null if there are no matches). It's an easy fix; I'll post a pull request in a bit.

I don't see any logical issues with adding `shadowJar.mustRunAfter cleanDist`, which is the other option that Gradle suggests -- it doesn't make sense IMO to clean after building the jar, after all.

Yeah. I think I understand the race condition now. I just haven't had time to put together a fix yet. (If anyone else wants to take a stab at it, be my guest.)

No, I think there are still possibilities of deadlock from multiple concurrent writes between the Swing event dispatch thread (e.g. clicking a checkbox to change some settings in Preferences) and main thread trying to affect the Swing UI.

Trying to push these two instances (setObject and removeProperty) onto the event dispatch thread naively causes many tests (which expect listeners to be executed synchronously in response to preference updates) to fail. IMO one reasonable way to do this is to update only the swingui elements...

Okay. So the problem is that the Swing UI can request preferences (e.g. wrapLongLines), thereby grabbing the Preferences lock, while setting a preference (which holds the Preferences lock) can fire listeners which can try to grab the Swing UI lock. In particular, the fix in Preferences.java...

(I am very happy I added the deadlock detector in that PR, since now we can know with certainty where the deadlock is.)

Today's debug log looks like a deadlock between net.sourceforge.kolmafia.swingui.widget.RequestPane$WrappedHtmlEditorKit$WrappedHtmlFactory$WrapInlineView.getMinimumSpan(RequestPane.java:83) and net.sourceforge.kolmafia.request.DeckOfEveryCardRequest.run(DeckOfEveryCardRequest.java:360)...