@makeecat Thanks for the review, I have now used VecDeque and DashMap. I have also, migrated from using Mutex to Channel. I did this, as when using Mutex there are a lot of instances of long blocking, which makes the application feel laggy. Using Channel blocking has been prevented and thus also improves performance as now the single thread read and writes the log without attaining any lock.

Also, I think we should make this Debug pane behind feature gate as this library is using tracing set_global_default which is not meant to be used by libraries as if the main crate maybe wants to send these logs or store them somewhere else but then they will not be able to use monitor.

I thinking adding a default feature like debug-pane would be good and will introduce flexibility for the main crate user on log behaviour.

I agree with adding a debug-panel faeture gate. In the future we may want to use tokio async to handle all IO-related operations to avoid overhead, but we can start with this implementation at the current stage.

Thanks @AS1100K! My biggest question here is why do we want to introduce tracing in the middle of it. Also, I don't see where we keep the buffer from not growing indefinitely, we should have somewhere a constant or parameter saying: we keep the last 1000 lines of back buffer. Otherwise your robot will run out of memory at some point :)

Also, I don't see where we keep the buffer from not growing indefinitely

I also kept that in mind, and only keep the number of logs according to terminal height. here https://github.com/copper-project/copper-rs/pull/219/files#diff-77cbd66ea06743fe2a1e13a87d5525ab87330d6cc6d548f35068b256168b611cR352-R356

Also, I don't see where we keep the buffer from not growing indefinitely

I also kept that in mind, and only keep the number of logs according to terminal height. here https://github.com/copper-project/copper-rs/pull/219/files#diff-77cbd66ea06743fe2a1e13a87d5525ab87330d6cc6d548f35068b256168b611cR352-R356

aaaah... ok ... we need a back buffer :) people will need to scroll back up a little bit

@gbin Thanks for you review, I have now removed the support for tracing crate and now it supports cu29-log and log crate. Also, while doing so I introduced a new argument in LoggerRuntime::init function. I would love some feedback here as I am not sure if this is a right call here.

Also, I don't see where we keep the buffer from not growing indefinitely

I also kept that in mind, and only keep the number of logs according to terminal height. here https://github.com/copper-project/copper-rs/pull/219/files#diff-77cbd66ea06743fe2a1e13a87d5525ab87330d6cc6d548f35068b256168b611cR352-R356

aaaah... ok ... we need a back buffer :) people will need to scroll back up a little bit

Also, I would also implement it soon

Cool! Thank you for your patience!

cu-consolemon is not part of core, I don't think it should: for example in production robots should not have it and might use a different implementation behind the Monitoring API.

what about hooking that up either as a Log destination (that will be picked up when consolemon is in) or, another possible way is to add a logging API to the monitoring API (that consolemon relies on and decouples it from core)?

Thanks @AS1100K good work!