Great. Do you think that having an abstracted stream I/O tunneled through DAP would lose anything compared to the direct file handle? I can see a few problems using a native platform file handle:
1. It's specific to the platform (with subtle differences between platforms) 2. It assumes a local setup, where the consumer and DAP implementation are running on the same machine, likely in the context of the same user. If DAP had some basic read/write stream packets you can easily build a flexible remote setup. What do you think? On Fri, Sep 21, 2018 at 10:39 AM, Greg Clayton <clayb...@gmail.com> wrote: > > > On Sep 21, 2018, at 10:31 AM, Leonard Mosescu <mose...@google.com> wrote: > > The solution I would love to see is to have the initialize packet return >> something via the DAP that says "I have a command line interpreter, please >> send a packet with a file handle (slave path to slave side of pseudo >> terminal maybe)". VS Code and Nuclide both emulated tty already, so we >> could have a true command line that exposes the "(gdb)" prompt for GDB and >> "(lldb)" for lldb and all the power that comes with it. >> > > I agree, that's the main reason I asked. Having a per-DAP convention seems > unfortunate. Also, with the current DAP messages it doesn't seem we can do > things like auto-complete or passing control characters to the debugger > first (ex Ctrl-C). > > I like your idea to manage an extra file handle. What if DAP offered > "console stream" packets? Yet another option would be going around DAP > completely for the pseudo terminal functionality, although it would be nice > if everything can be built on top of DAP. > > > Yeah there are two solutions to get a command line: > 1 - have initialize packet return "I need a console named 'LLDB Commands'" > and then have the IDE be able to switch from "Debugger Console" (which > evaluates expressions over to "LLDB Commands" and it repurposes the > existing debugger console to just send LLDB commands. The user would be > able to switch between the two. > 2 - Use a file handle to the terminals that are supported in the IDEs. The > benefit here is the ability to due curses style output where you can > control the cursor position and emit color control codes to colorize output. > > > Not urgent but perhaps we can use LLDB to design and prototype such a DAP > extension, then propose it to the vscode team? Is this something you'd be > interested in? > > > I would be yes. I would love the ability to due approach #2 by adding > something to the reply to the initialize packet and if the IDE supports it, > they will send down a file handle that could be used. Right now their TTY > support seems to be centered around running a sub process only (like > /bin/sh or other command line executable), not around, just give me a > terminal and a file handle I can read and write to. > > Greg Clayton > > > > On Fri, Sep 21, 2018 at 9:56 AM, Greg Clayton <clayb...@gmail.com> wrote: > >> >> >> On Sep 20, 2018, at 3:05 PM, Leonard Mosescu <mose...@google.com> wrote: >> >> Hi Greg, looking at request_evaluate() I noticed that it will evaluate >> the string as a lldb command if prefixed by ` . >> >> This is a great feature (it allows building REPL consoles on top of DAP), >> but I'm curious how you picked up this convention? For example I believe >> that the gdb DAP uses -exec 'command' instead. >> >> >> ` is an illegal expression character so it won't stop you from evaluating >> any possible expression. The gdb prefix "-exec" stops you from being able >> to negate a local variable named "exec". Not a huge deal. So I just picked >> a good prefix character that wouldn't stop anyone from evaluating any valid >> expression (at least in C/C++/ObjC/Swift). >> >> The solution I would love to see is to have the initialize packet return >> something via the DAP that says "I have a command line interpreter, please >> send a packet with a file handle (slave path to slave side of pseudo >> terminal maybe)". VS Code and Nuclide both emulated tty already, so we >> could have a true command line that exposes the "(gdb)" prompt for GDB and >> "(lldb)" for lldb and all the power that comes with it. >> >> I needed something that could run LLDB commands when things go wrong to >> do trouble shooting (enable logging, run commands to dump vital >> information) so I hacked it in with ` >> >> Greg >> >> >> On Thu, Aug 16, 2018 at 11:01 AM, Phabricator via Phabricator < >> revi...@reviews.llvm.org> wrote: >> >>> This revision was automatically updated to reflect the committed changes. >>> Closed by commit rL339911: Add a new tool named "lldb-vscode" >>> that implements the Visual Studio Code Debug… (authored by gclayton, >>> committed by ). >>> Herald added a subscriber: llvm-commits. >>> >>> Changed prior to commit: >>> https://reviews.llvm.org/D50365?vs=161058&id=161067#toc >>> >>> Repository: >>> rL LLVM >>> >>> https://reviews.llvm.org/D50365 >>> >>> Files: >>> lldb/trunk/lldb.xcodeproj/project.pbxproj >>> lldb/trunk/packages/Python/lldbsuite/test/dotest.py >>> lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> .categories >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> attach/Makefile >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> attach/TestVSCode_attach.py >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> attach/main.c >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> breakpoint/Makefile >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> breakpoint/TestVSCode_setBreakpoints.py >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> breakpoint/TestVSCode_setExceptionBreakpoints.py >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> breakpoint/TestVSCode_setFunctionBreakpoints.py >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> breakpoint/main.cpp >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> launch/Makefile >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> launch/TestVSCode_launch.py >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> launch/main.c >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> lldbvscode_testcase.py >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> stackTrace/Makefile >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> stackTrace/TestVSCode_stackTrace.py >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> stackTrace/main.c >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> step/Makefile >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> step/TestVSCode_step.py >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> step/main.cpp >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> variables/Makefile >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> variables/TestVSCode_variables.py >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/ >>> variables/main.cpp >>> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py >>> lldb/trunk/tools/CMakeLists.txt >>> lldb/trunk/tools/lldb-vscode/BreakpointBase.cpp >>> lldb/trunk/tools/lldb-vscode/BreakpointBase.h >>> lldb/trunk/tools/lldb-vscode/CMakeLists.txt >>> lldb/trunk/tools/lldb-vscode/ExceptionBreakpoint.cpp >>> lldb/trunk/tools/lldb-vscode/ExceptionBreakpoint.h >>> lldb/trunk/tools/lldb-vscode/FunctionBreakpoint.cpp >>> lldb/trunk/tools/lldb-vscode/FunctionBreakpoint.h >>> lldb/trunk/tools/lldb-vscode/JSONUtils.cpp >>> lldb/trunk/tools/lldb-vscode/JSONUtils.h >>> lldb/trunk/tools/lldb-vscode/LLDBUtils.cpp >>> lldb/trunk/tools/lldb-vscode/LLDBUtils.h >>> lldb/trunk/tools/lldb-vscode/README.md >>> lldb/trunk/tools/lldb-vscode/SourceBreakpoint.cpp >>> lldb/trunk/tools/lldb-vscode/SourceBreakpoint.h >>> lldb/trunk/tools/lldb-vscode/SourceReference.h >>> lldb/trunk/tools/lldb-vscode/VSCode.cpp >>> lldb/trunk/tools/lldb-vscode/VSCode.h >>> lldb/trunk/tools/lldb-vscode/VSCodeForward.h >>> lldb/trunk/tools/lldb-vscode/lldb-vscode-Info.plist >>> lldb/trunk/tools/lldb-vscode/lldb-vscode.cpp >>> lldb/trunk/tools/lldb-vscode/package.json >>> >>> >> >> > >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
