Keyboard Interrupt exceptions are handled smoothly in that no record is made of the exception ever occurring, allowing any workflow to be killed from the terminal, and then resumed without issue. In demo.py and main.py, I redirect stderr to a file so that the terminal has cleaner output. Although killing a workflow works fine, asyncio still spits out lots of errors related to the nasty destruction of the event loop.
main.py now runs with the WorkflowManager, which handles the interleaved advancement of several workflows.
demo.py provides an interactive way to run scripts that demonstrate the abilities of quest
merges edits from two small previous PRs that indicate a fuller path on the test files so that the utils module imports correctly, and updates the way historian.py accesses UTC timestamp values.
Notes on what I changed:
main.py is fairly self explanatory and goes through workflow advancement like Dr. Bean described.
demo.py is designed to be a starting point where you can choose what files you would like to run as part of a demonstration or something like that. It lets you pick the order and combination of running main.py, as well as entering an interactive session of flexible multi-guess.
flexible_multi_guess.py is a file where multi-guess is the game, and it includes the word flexible because you can use flags to run either on WorkflowManager or Historian, and indicate if the JSON files should be initially wiped or not.
The demos/ directory is a folder where I keep the example programs, except main.py, which could be run independent of demo.py. flexible_multi_guess.py is described in the previous bullet. The other files are the actual game code for multi-guess. multi_guess_terminal.py is the version that uses the terminal so the user can interact with it. mutli_guess_queue.py uses a queue as input instead so it can easily be tested.
Additionally, test_interrupt_handling.py is a test file that confirms that Quest correctly handles the raising of a KeyboardInterrupt. It runs a workflow designed to raise the exception at a given time after setting a certain number of events. It runs the workflow several times, with the exception coming at different times each run, and confirms that the correct events are set. This file is also set up to be run on its on, independent of pytest, if so desired.
Note that on this branch, all test files were passing before I updated from main, which had gained stream resources
This PR accomplishes the following:
demo.pyandmain.py, I redirectstderrto a file so that the terminal has cleaner output. Although killing a workflow works fine,asynciostill spits out lots of errors related to the nasty destruction of the event loop.main.pynow runs with theWorkflowManager, which handles the interleaved advancement of several workflows.demo.pyprovides an interactive way to run scripts that demonstrate the abilities of questutilsmodule imports correctly, and updates the wayhistorian.pyaccesses UTC timestamp values.Notes on what I changed:
main.pyis fairly self explanatory and goes through workflow advancement like Dr. Bean described.demo.pyis designed to be a starting point where you can choose what files you would like to run as part of a demonstration or something like that. It lets you pick the order and combination of runningmain.py, as well as entering an interactive session of flexible multi-guess.flexible_multi_guess.pyis a file where multi-guess is the game, and it includes the word flexible because you can use flags to run either onWorkflowManagerorHistorian, and indicate if the JSON files should be initially wiped or not.demos/directory is a folder where I keep the example programs, exceptmain.py, which could be run independent ofdemo.py.flexible_multi_guess.pyis described in the previous bullet. The other files are the actual game code for multi-guess.multi_guess_terminal.pyis the version that uses the terminal so the user can interact with it.mutli_guess_queue.pyuses a queue as input instead so it can easily be tested.test_interrupt_handling.pyis a test file that confirms that Quest correctly handles the raising of aKeyboardInterrupt. It runs a workflow designed to raise the exception at a given time after setting a certain number of events. It runs the workflow several times, with the exception coming at different times each run, and confirms that the correct events are set. This file is also set up to be run on its on, independent ofpytest, if so desired.Note that on this branch, all test files were passing before I updated from main, which had gained stream resources