I'm currently pushing down the update_func into low level functions like execute_subprocess and various places in the GeometricAdapter. I also have multiple ways (wrappers) to capture stdout and log files covering three cases:
- The package uses the python logger
- The package writes to sys.stdout
- The package (like xtb) writes to system stdout outside of Python's access to sys.stdout (by writing directly with a C library, e.g.,)
I think I could create a single high level wrapper function that I put in BaseAdapter.compute to capture all these forms of stdout and then work with the update_func only at that level. Would be much easier and cleaner.
Something like this:
# Very lazy pseudocode
with capture_logs(...) as logs: # logs is some stream that gets written to
# Execute the program. results will be None if FileInput
tread = treading.Thread(update_loop, update_func, update_interval, logs ).start()
results, stdout = self.compute_results, args=(
inp_obj,
update_func,
update_interval,
propagate_wfn=propagate_wfn,
**kwargs,
)
)
# lazy pseudocode
thread.kill()
Then I would run the program in a background thread, capture the logs/stdout in the main thread and can run an update_func until the thread completes execution.
This would also fix #19 and maybe #18
Maybe hae the @capture_logs decorator be a master function that uses one of the three approaches to capture logs depending on a class variable on an Adapter that declares how this program writes logs (one of logger, stdout, or nonpython)?
I'm currently pushing down the
update_funcinto low level functions likeexecute_subprocessand various places in theGeometricAdapter. I also have multiple ways (wrappers) to capture stdout and log files covering three cases:I think I could create a single high level wrapper function that I put in
BaseAdapter.computeto capture all these forms of stdout and then work with theupdate_funconly at that level. Would be much easier and cleaner.Something like this:
Then I would run the program in a background thread, capture the logs/stdout in the main thread and can run an
update_funcuntil the thread completes execution.This would also fix #19 and maybe #18
Maybe hae the @capture_logs decorator be a master function that uses one of the three approaches to capture logs depending on a class variable on an Adapter that declares how this program writes logs (one of
logger,stdout, ornonpython)?