master/gui: logging messages

[jordens]

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.

[sbourdeauducq]

I guess that for v1.0, we can just redirect the standard output from all experiments into the GUI.

[sbourdeauducq]

I have implemented this simple solution now.

[sbourdeauducq]

The discussed features should be there now:

• log filter in GUI by level (there are no other filters, as I remember from last meeting you did not want them?)
• colors by level
• timestamps, source (master, worker, controller, etc.)
• log files saved on master, with rotation
• logs from workers, controllers and controller managers are sent to the master and integrated
• logging from the core device can be done by RPCing the Python log functions. I do not think it makes much sense to try to integrate the log printed on the device's serial port and also accessible via artiq_coretool log, as the latter is typically used to debug situations where low-level components (including the communication code) are broken. Its advantage, though, would be backgrounding/speed (if made accessible to the user) as RPC will wait for a reply.

[jordens]

Finer filtering would be on the cartesian product of level and some notion of "source" plus the "source" hierarchy hierarchy. Sounds hairy to me.

[ghost]

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()