Mocking the VS side (in python or C++) sounds like the way to go. I don't know much smartness is in this code (as in, something other than "take this json, translate it to an appropriate SB call and serialize the results back"), but if there is some non-trivial logic in there (perhaps the code for handling the wire protocol itself), then this would be a good candidate for a unit test.
On 15 February 2018 at 01:10, Jim Ingham via lldb-dev <lldb-dev@lists.llvm.org> wrote: > The SB API's were designed to be binary stable API's when used either from > C++ or Python (the latter are just a SWIG-ified version of the former.) So > just like the Python wrapper, with the exception that you might call an API > that some older version of liblldb doesn't provide, Greg's adaptor wouldn't > be sensitive to lldb library version. > > Jim > > >> On Feb 14, 2018, at 4:43 PM, Vadim Chugunov via lldb-dev >> <lldb-dev@lists.llvm.org> wrote: >> >> My tests are here. I probably wouldn't move all that to Python for my >> extension, but feel free to draw ideas on things to test from it. >> >> What's going to be your deployment story? The nice thing about >> Python-based adapter is that it will run on a wide range on LLDB versions. >> For a native adapter you'll need to somehow make sure that you have the >> right liblldb installed, won't you? >> >> >> On Wed, Feb 14, 2018 at 3:54 PM, Greg Clayton <clayb...@gmail.com> wrote: >> >> >>> On Feb 14, 2018, at 3:45 PM, Vadim Chugunov <vadi...@gmail.com> wrote: >>> >>> FYI - I've been maintaining a similar VSCode extension, which does it all >>> through LLDB's Python interface. >> >> Indeed, I saw you plug-in and since it worked so well I wanted to make a >> native version of this plug-in to avoid taking over the python interpreter >> and get native performance. Very nice work on that plug-in as it inspired >> this one! I adopted many similar settings that you allow in the launch.json >> file and added some new ones. >> >>> >>> As for testing, the protocol is JSON with HTTP-like headers for framing, so >>> you could have a Python script emulating the VSCode side. >> >> That is what I was planning to do. Might be nice to work together on this >> and get the testing working as it could test both of our plug-ins. Would be >> great to have a debug session with a simple program that sets a breakpoint >> by name, by file and line and exception and run, hit the breakpoints, view >> variables, etc. >> >> Greg >> >>> >>> >>> On Wed, Feb 14, 2018 at 2:28 PM, Greg Clayton via lldb-dev >>> <lldb-dev@lists.llvm.org> wrote: >>> I have a patch I will be submitting soon that adds a tool called >>> "lldb-vscode" that is much like "lldb-mi" where it sits on top of >>> LLDB.framework on Darwin and liblldb.so on all other platforms, and it >>> speaks the Visual Studio Code Debug adaptor language and can be used to >>> create a VSCode extension that does native LLDB debugging. The plug-in >>> works really well to debug native apps and is very responsive and quick. >>> >>> One issue I am thinking about is how to test this. Some VS Code tests out >>> there use Javascript + npm to run a mock VSCode IDE and send/receive >>> packets. I am not sure we can require people to have this on all build >>> bots. So I am writing to get everyone's opinion on this so I can test this >>> and get a patch submitted. >>> >>> Any ideas would be appreciated. >>> >>> Greg Clayton >>> >>> _______________________________________________ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> >> >> >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
