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> wrote:
>
>
> On Sep 21, 2018, at 1:20 PM, Leonard Mosescu <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> 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
