Search results

Okay, fighting what?

What are you having your script button do, exactly? Post your CCS.

If I still did more than a trivial amount of ASH scripting, I would be using sublimetext to do it. It's become my go-to "IDE-lite" for lots of tasks, and I imagine one could whip up a syntax markup file for it rather quickly.

oookay. Should have gotten the last one now.

Guess I should have looked at the original traceback. r14744

r14739, untested

Alrighty, r14732. Let's see how good my local testing was. One thing to note. My commit says relay scripts "... should not be able to interact with the main KoLMafia display, other than to print things to the gCLI." This isn't *quite* true - relay threads have the ability to submit things to...

Well the "contract" it's talking about is if a.equals(b) then a.compareTo(b) == 0 and if !a.equals(b) then a.compareTo(b) != 0 Also I'm guessing it should be invertible; a.compareTo(b) == -b.compareTo(a) Looking at .equals() and .compareTo() in Concoction I wonder how this bug doesn't come...

Ah, missed one place that interacted with the sidebar display. This seems pretty guide-proof right now, so that's a good sign. I've also tested some bogus relay scripts and they fail properly. So... I'll probably give this a few days of random testing before committing. What's the worst that...

I added the preference "fixedThreadPoolSize" in r14729. You could try setting that to something low but nonzero (like, 1) and see how that works for you. (requires restart after setting)

The new thread pooling should be friendlier on old systems. The old paradigm was to rapidly create/tear down threads, now we reuse them. Also, sitting in chat does not involve firing off a single thread through the thread pool, so I remain dubious that it's responsible.

Just instrumented r14722 with chat GUI open for 30 minutes, everything looks normal. Going to need more info.

So... I think this is working? This is too scary of a feature to just recklessly push upstream; haven't tested it nearly enough. Might be prudent to gate it behind an opt-in preference while it's new. Pretty happy with it, though. It's unobtrusive.

Actually, never mind, r14715

It was more likely r14708 itself that broke it, which I reverted in r14710. Can you still reproduce in the latest build?

Hm, right. FightRequest definitely needs to respond to continuationState. And since yeah, you'd only better be in one combat at a time, it actually makes sense to have a singleton thread to do combats in. It wasn't necessary *before*, but it actually is now if I'm moving forward with this...

roippi's log, supplemental I've cleaned up a number of the random Thread subclasses scattered around mafia; the majority of the ones left are long-running threads that don't need to be put through the new ThreadPoolExecutor that RequestThread is sporting. After going through our codebase (not...

Salud!

roippi's log, developerdate one forty three point seven I've ventured into RequestThread (and beyond) to see how threaded mafia really is. While you can consider that the majority of things do eventually happen in one thread, there are plenty of other threads that get fired off: RelayAgents...

Hm, interesting idea! I like the idea of just making the points that update continuationState (mostly KoLMafia.updateDisplay) handle making the value thread-local and leaving the rest of the codebase that checks for permitsContinue() naive of the difference. I'll look into it.