Build: 20742
When performing a mall search with Maximizer, pressing escape will visually quit the mall search in CLI.
But if you look at the underlying code, the mall search is still silently going on. I'm not sure of the details that much as I didn't bother looking into that aspect.
So whether its hitting the mall or not is unknown, but it's still progressing at a speed that is identical to the pre-world peace search from the stack traces timings. So I can only assume it is still hitting KOL. Just not informing us about it.
So although that's one issue, there's another that if you start a new maximizer request, the previous maximizier request will decide its relevant again and become visual again and continue. Again, I believe it's because the request was never cancelled, just silently continuing.
Of course, looking at the code itself it appears that there's no actual way that the user interruption is seen without explicitly monitoring for it, especially as the offending code is nested in its own self contained loop without calling code that would be listening for that.
Inserting a KoLmafia.permitsContinue() check into CheckedItem.validate(int, int) to throw a maximizer interrupted exception seems to have fixed the issue for the most part. But its a dirty fix and doesn't actually look into anything, and doesn't warn the rest of maximizer about the issue.
Thus I don't think it's worth actually making a PR with what I did do, due to a lack of time on my part and how dirty the code itself is.
This report thus is mostly to bring up awareness of the issue.
When performing a mall search with Maximizer, pressing escape will visually quit the mall search in CLI.
But if you look at the underlying code, the mall search is still silently going on. I'm not sure of the details that much as I didn't bother looking into that aspect.
So whether its hitting the mall or not is unknown, but it's still progressing at a speed that is identical to the pre-world peace search from the stack traces timings. So I can only assume it is still hitting KOL. Just not informing us about it.
So although that's one issue, there's another that if you start a new maximizer request, the previous maximizier request will decide its relevant again and become visual again and continue. Again, I believe it's because the request was never cancelled, just silently continuing.
Code:
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1336)
at net.sourceforge.kolmafia.request.MallSearchRequest.run(MallSearchRequest.java:234)
at net.sourceforge.kolmafia.RequestThread.postRequest(RequestThread.java:295)
at net.sourceforge.kolmafia.RequestThread.postRequest(RequestThread.java:250)
at net.sourceforge.kolmafia.session.StoreManager.searchMall(StoreManager.java:753)
at net.sourceforge.kolmafia.session.StoreManager.searchMall(StoreManager.java:674)
at net.sourceforge.kolmafia.session.StoreManager.getMallPrice(StoreManager.java:859)
at net.sourceforge.kolmafia.maximizer.CheckedItem.validate(CheckedItem.java:257)
at net.sourceforge.kolmafia.maximizer.Evaluator.enumerateEquipment(Evaluator.java:2195)
at net.sourceforge.kolmafia.maximizer.Maximizer.maximize(Maximizer.java:188)
at net.sourceforge.kolmafia.swingui.MaximizerFrame.maximize(MaximizerFrame.java:213)
at net.sourceforge.kolmafia.swingui.MaximizerFrame$MaximizerPanel.actionConfirmed(MaximizerFrame.java:387)
at net.sourceforge.kolmafia.swingui.panel.GenericPanel$ConfirmedListener.execute(GenericPanel.java:626)
at net.sourceforge.kolmafia.swingui.listener.ThreadedListener.run(ThreadedListener.java:239)
at net.sourceforge.kolmafia.RequestThread$SequencedRunnable.run(RequestThread.java:428)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
at java.util.concurrent.FutureTask.run(FutureTask.java)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)Of course, looking at the code itself it appears that there's no actual way that the user interruption is seen without explicitly monitoring for it, especially as the offending code is nested in its own self contained loop without calling code that would be listening for that.
Inserting a KoLmafia.permitsContinue() check into CheckedItem.validate(int, int) to throw a maximizer interrupted exception seems to have fixed the issue for the most part. But its a dirty fix and doesn't actually look into anything, and doesn't warn the rest of maximizer about the issue.
Thus I don't think it's worth actually making a PR with what I did do, due to a lack of time on my part and how dirty the code itself is.
This report thus is mostly to bring up awareness of the issue.
