Console Log as Table.[CPP-117][CPP-279] #103
Conversation
john-michaelburke
commented
Aug 10, 2021
john-michaelburke
commented
- Converted existing console log to table.
- Made log messages available outside of process_messages.
- Moved receive backend thread outside of Server.start function (seems logging does not work inside? possibly due to it being a pymethod)
- Threw the setup logging in Server.start into a function in log_panel.rs.
- Converted logging messages into json before sending over to frontend to be decoded into timestamp / log level / message for table.
- Fixed issue with table header not always being above table when scrolling up/down.
- Changed background color of console log / solution table to be white to blend better with app color scheme.
- Removed TODO for CPP-117 it looks like the MsgLog does not contain a remote timestamp and log level is correctly filtered now between device/console logs.
john-michaelburke
changed the title
|
|
||
| // Custom formatting of `log::Record` to account for SbpLog values | ||
| pub fn splitable_log_formatter(record: &Record) -> String { | ||
| // TODO (JV): CPP-117 Extract SbpLog timestamp and level from message |
There was a problem hiding this comment.
this hasnt been finished afaics. the timestamps are always the Local::now() below
There was a problem hiding this comment.
There is no timestamp in the MsgLog nor the python message log and it doesn't look like piksi tools adds any remote timestamp. Can you show me what you were referring to?
There was a problem hiding this comment.
ah, I was thinking that the timestamp should be determined in handle_log_msg rather than here, but that is because I wasnt sure if there was the possibility of delays between warn!(etc) capturing the logging arguments and the formatter here being asked to render it.
There was a problem hiding this comment.
That is a good point. So I did a little digging and I believe the formatting function may get called when a new log message is made instead of when the flush occurs although I may be wrong seems this async_logger is wrapped around another async logger crate so its not the easiest for me to follow. That being said our logs are formatted out to the seconds and these delays are running in milliseconds so probably not a huge deal.
3 participants
