jingham added a comment. In D70883#1771686 <https://reviews.llvm.org/D70883#1771686>, @aadsm wrote:
> Fair enough, I haven't seen evidence of this (haven't searched for it) but I > imagine IDEs need to ignore this as well otherwise they just barf if they're > expecting `Content-Length` and a wild print appears. The notion of stdout of > SBDebugger is the SBCommandReturnObject which doesn't print right away (only > when the command finishes executing) and from my previous tests .flush() > doesn't help with this. I believe this is the reason why people opt to use > print instead in their custom commands. But I don't think it's a reasonable > assumption (or api contract) to tell people they can't use print or it breaks > lldb-vscode. > > I'm going to fix this in lldb-vscode itself to wrap all stdout in a proper > DAP console response. This is an aside, but, lldb knows how to immediately output command results. For instance, when stop hooks are run the output is sent to the command result's "Immediate output stream", since the stop hook might auto-continue and you don't want to wait till somebody's "next" or "continue" actually returns to see stop hook output. There are some other commands that produce lots of output that are also immediate. It should be possible to do this from Python as well, by inserting the debugger's Output file into the command's immediate output handle. That's the way it is supposed to work, though I didn't check to make sure this is all wired up. But it should not be necessary to use "print" to output command results just because you want to see them immediately output. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D70883/new/ https://reviews.llvm.org/D70883 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
