Fix output that was produced before initial stop was not visible at first stop #57
Conversation
|
One thing we might, should consider: |
|
That's a good point! I know that vscode has their debug console as a separate pane than it's debugging pane, but that's not necessary the best solution. I like your idea better! We should send a toast notification to workspace with a url/button that opens the DAP logs editor that was recently merged. We could also add the ability to filter log breakpoint's to the log editor and set that behavior as the default when a user opens DAP logs from the toast notification. |
|
Yeah one more thing that came up, we have to support viewing deb logs from an adapter that has already exited/terminated. Right now we remove the debug log entries. |
|
What if we merge this in now then I could work on setting up a history for the DAP logs? |
| item.client_id() == *client_id | ||
| }); | ||
|
|
||
| if existing_item { |
There was a problem hiding this comment.
Can we pls just always send the event and push the message queue? And when the client has stopped (shutdown) we should remove the queue again. Because you could have multiple debug sessions and each debug session should show the same output log
There was a problem hiding this comment.
Yes! I'll make the change.
RemcoSmitsDev
force-pushed
the
log-breakpoints
branch
from
62d5417
to
d496f3e
Compare
We still want all the output in new threads
RemcoSmitsDev
changed the title
RemcoSmitsDev
changed the title
| cx.emit(DebugPanelEvent::Output((client_id, output))); | ||
| if let Some(message_queue) = this.message_queue.get(&client_id) { | ||
| while let Some(output) = message_queue.iter().next() { | ||
| cx.emit(DebugPanelEvent::Output((client_id, output.clone()))); |
There was a problem hiding this comment.
We need a way to filter messages by thread_id to stop log messages from one thread outputting to another thread.
I also think it could be worth looking into sharing the same View<Console> between thread's of the same client_id
There was a problem hiding this comment.
Yeah so that is not really possible because the output does not belong to a thread it belongs to a client. We could add some indicator so you can see the logs since the thread stopped.
Yeah wanted to do that as well.
This PR allows you to see the output of your program that was produced before the initial breakpoint stop.
Before this change, the output was not visible because we only stored the output for threads that have stopped once. Because we store the output inside the
debug_panel_itemthat is only created when the debug session has stopped.So by storing the output events and emitting the events when the thread stopped, allows you to see all the output that was produced before the stop.