Sounds good! > On Sep 24, 2018, at 10:45 AM, Leonard Mosescu <mose...@google.com> wrote: > > Thanks Greg, this is what I had in mind. > > I have some ideas which involve this kind of debugger console. We'll likely > start with a basic version built on top of evaluate `cmd and once we get > around to building a full console I'll ping you. > > On Sat, Sep 22, 2018 at 8:50 AM, Greg Clayton <clayb...@gmail.com > <mailto:clayb...@gmail.com>> wrote: > > >> On Sep 21, 2018, at 1:20 PM, Leonard Mosescu <mose...@google.com >> <mailto:mose...@google.com>> wrote: >> >> 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? > > Yeah, I forgot about remote. Maybe best to set it all up through DAP and just > tell the IDE that you have a command interpreter and maybe what its prompt > should be. > > The init packet would be sent: > > {"command":"initialize","type":"request","seq":1, "arguments":{...}} > > Then in the response we would say we have an interpreter: > > {"command":"initialize","type":"response", > "request_seq":1,"seq":0,"success":true,"body":{ > "supportsCommandInterpreter":true, > "interpreterPrompt":"(lldb)" > } > } > > > Then the IDE would need to support output going into (STDIN) that would go to > the command interpreter somehow, and accept output coming from the command > interpreter via the "output" event by adding support for a new output type > "interpreter": > > {"event":"output","seq":0,"type":"event", > "body":{"category":"interpreter","output":"output text here"}} > > Then the IDE would only need either have another window for the interpreter, > or allow the standard debugger console to be switched over into interpreter > mode and show both outputs there. > > >> >> On Fri, Sep 21, 2018 at 10:39 AM, Greg Clayton <clayb...@gmail.com >> <mailto:clayb...@gmail.com>> wrote: >> >> >>> On Sep 21, 2018, at 10:31 AM, Leonard Mosescu <mose...@google.com >>> <mailto: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 >>> <mailto:clayb...@gmail.com>> wrote: >>> >>> >>>> On Sep 20, 2018, at 3:05 PM, Leonard Mosescu <mose...@google.com >>>> <mailto: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 <mailto: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 >>>> <https://reviews.llvm.org/D50365?vs=161058&id=161067#toc> >>>> >>>> Repository: >>>> rL LLVM >>>> >>>> https://reviews.llvm.org/D50365 <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
