Search results

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)...

The simplest way to use ASH directly in the CLI is to prefix your command with `ash`: > ash chat_private("Buffy", "25 ode") Returned: void If you don't care about the return value of the command (or sequence of commands), then you can use `ashq` to suppress that line.

This isn't a typo -- this is a distinction between typing commands into the CLI, and running an ASH script. The former is intended as an interactive experience. Notably, all built-in ASH functions are available in the CLI as if via `using`, so you could type something like > mp_cost...

The only change to src/net/sourceforge/kolmafia/preferences in the past 2 months added some string constants to an array, so I'm skeptical that something changed in Mafia recently. Is Crimbo lag still a thing? I know sometimes the server responds with a timeout and then proceeds to finish...

If you feel comfortable with committing it (since you've apparently been using this patch for months without any observed ill effects), that's fine by me. If it breaks again, there's nothing wrong with reverting it again.

I believe r27711 should fix this, but let us know if you still experience the bug after that revision. Thanks!

This will be r27708 whenever that shows up.

Anyways, https://github.com/kolmafia/kolmafia/pull/2077 should address this (although KoL ought to fix the data quality on their end too...)

I loaded this file into a test. It seems that the issue is actually with Peppermint Rush, which has a leading space in the effect duration: "97bac5f12530c253303ed4fa944bec0d":["Peppermint Rush"," 10","ccsword",null,"2853"]

https://github.com/kolmafia/kolmafia/pull/2076 should fix the issue once it gets merged -- on a character with a special mood, I get "Error during session initialization" without the change, and can successfully log in with the change.

I would expect the trigger to be related to "incredibly well lit" as well as "offhand remarkable", since those are the two skills that show up in dailylimits.txt. I think the issue may actually be an initialization issue. DailyLimitDatabase.reset() is supposed to be called statically, but it...