-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
master/gui: logging messages #45
Labels
Comments
I guess that for v1.0, we can just redirect the standard output from all experiments into the GUI. |
I have implemented this simple solution now. |
The discussed features should be there now:
|
Finer filtering would be on the cartesian product of level and some notion of "source" plus the "source" hierarchy hierarchy. Sounds hairy to me. |
I think the following comb will groom this beast. f = get_search_box_text()
if len(f)>0: # ignore all other filtering (e.g. by source)
for s in log:
if s.find(f):
show_s_in_log() |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
One dock within the GUI will be showing logging messages from the scheduler, the workers, the experiments, the controllers, the core device. Probably, the master will act as a hub rceiving aggregating messages and then save them to files and re-emit them to the GUI. The GUI can then filter on severity, source, or other metadata within the LogRecord (like experiment name). We need to decide whether python-logging fits the requirements (metadata with LogRecords, networking, interaction with asyncio, lazy formatting) or whether we need to roll our own.
The text was updated successfully, but these errors were encountered: