Closed Teg3z closed 3 weeks ago
@Teg3z Deleted comment and reported for presumed malicious link distribution.
@Teg3z As for the actual issue, I would have to assume that asyncio library is a severe overkill for what you are actually trying to do.
Application is nowhere near complex enough to warrant use of parallelism. Take note that I am not proficient in Python to give meaningful guidance here. But I am confident enough to conclude that generally speaking the direction undertaken here is not an optimal one - typical use case for multithreading / asynchronous processing is to save up processing times for computation intensive processes - in our usecase the longest "slowdown" of the aplication is the DB call, which cannot be fixed by offloading the process one way or another.
Lets meet somewhere in the week to look at this, it feels interesting.
EDIT: more importantly, get some sleep my friend, you cant code properly when you are sleepy. EDIT2: On second thought maybe its not an overkill, If what you are trying to do is to make sure that the program has a subroutine which awaits the message calls to process them without having to rely on main code loop then you might be onto something. Still suspect coroutines are a little bit of an overkill but from a learning perspective why not (alternative to consider - observer design pattern)
@Teg3z Introduction of asyncio borks the build on my machine.
Current state of feature/game-players-logic-change does not lead open the UI at all.
You can try to change (discord_bot.py , def start_bot
)
async def start_bot():
# Runs the bot asynchronously in the background since client.start is a blocking function
asyncio.create_task(client.start(DISCORD_BOT_TOKEN))
# Wait for the bot to login and then can continue the code with bot ready to operate
await bot_ready_event.wait()
to
async def start_bot():
# Runs the bot asynchronously in the background since client.start is a blocking function
await asyncio.create_task(client.start(DISCORD_BOT_TOKEN))
# Wait for the bot to login and then can continue the code with bot ready to operate
await bot_ready_event.wait()
As that allows for launching the code, but it gets stuck at this phase on my machine (also my static code control marks this as a warning of
Seems to me like there is a lot of problems with this approach tho.
Ok this issue seems to be resolved in this commit
There the discord bot is running in its separate thread with its own event loop and so it does listen for discord messages and also for commands from the wheel.
Introduction of asyncio borks the build on my machine.
To support the python code running on different machines than mine, I made requirements.txt file that can be installed in local Python virtual envronment, so there arent any differences in the packages at least. Although the compability of the code on different machines might receive its own issue.
I will also update README to provide the instructions for setting up the code in the Python virtual environment, how to run it etc as mentioned in #15.
For now I think this issue can be closed and if needed there can be a new issue created regarding the machine compatibility for the code.
The code logic of the Discord Bot and the Wheel UI are getting seperated in this new feature branch. Basically the bot should run as a separate task thats to asyncio library:
asyncio.create_task(client.start(DISCORD_BOT_TOKEN))
Now the UI runs smoothly and the bot is sending messages to the DC channel when told to do so in the UI, but doesnt react on the on_message events:
So no commands are answered to.
The possible problem might be in the task separation, maybe the asyncio.create_task doesnt really make a new task separately from the main task and its rather a "subtask" so the bot cant react on its own, just when asked to.
So research of the asyncio library might come in handy, or start using multiprocessing/multithreading.