blaketech / project-ohdear Goto Github PK

Will be kept updated on known oddities.

#Noncritical Issues: (Issues that don't impact the script's functionality.)
Issue 1: Windows(GUI) don't close properly even after calling del window. Not sure why, but possibly, if moved to a separate thread, could force it to close before moving. Just a visual glitch though. (Win/Linux)

Issue 2: Asyncio spits out known ProactorBasePipeTransport errors, there is a workaround, but since again it doesn't actually affect this script beyond the funny error message, and is a bit hacky since you modify the library just for Windows(OS) to stop being angry, won't be fixed, and should probably be fixed in the main lib itself if possible(though, it seems to be more of a problem stemming from the way Windows(OS) handles it, rather than the lib itself) (Win) -Solved by simply merging the appending tag into the async 'd function, as it seems to trigger on the second session.

Issue 3: PySimpleGUIWx is not actively being updated, as such, functions based on the popup derivatives, i.e. popup_yes_no, popup_no_wait do not support the full( if any, not sure, didn't test other args.) gamut of options available to the original popup. While a workaround has been proposed, it also should be fixed by the main library itself. An alternative solution would be to create small windows that act like popups, though it would add a little extra bulk. (Win/Linux)

Issue 4: PySimpleGUIWx generates Gtk-CRITICAL errors, due to window size being 0 or something. And yet, it still makes a window. Waiting on developer to respond. Windows(OS) will not trigger this as it doesn't use Gtk. Again, not critical, but still interested in seeing if possible to silence by satisfying the request. (Linux)

#Critical Issues: (Issues that impact the script's functionality.)
Issue 1: Numpy is broken on Windows(OS) for version 1.19.4. backporting to 1.19.3 will fix the issue. (Win)
Issue 2: (Unconfirmable due to lack of excess hardware.) AIOhttp doesn't work all the time, at least on my hardware. i have workarounds, but if potential issues arise I may be unable to replicate it. (Win/Linux)

Testing with a theoretical number of "threads", i.e. if ran on an AMD EYPC cpu with 128 threads, it should still load results fine. Limitation exists somewhere in testing env, be that internet interaction (speed/bandwidth), server response rate, or even laptop cpu (Observed 102% usage...?). Tested using Kancolle sample file. Occasional list out of bounds. But 99.99% of users will likely not have this issue, unless they are Uber bored and rich and have a 256 threaded dual EPYC cpu system to run stuff. Classic "30% of the time, it works 100% of the time" logic here.

Glitches: (Left here as a list of observed oddities.)

1. Early versions after multiprocessing was set up indicated that threads were being used to summon windows, for no reason when no windows were put in. Only occurred in specific files, could either be number of executions or weird file format thing. RE: dos2unix-esque. Problems have since mysteriously disappeared.

2. For some reason, it may trip and glitch out, causing website response to be lost. Need to investigate reason on noreply on one instance. Fluke?