> On Sep 12, 2019, at 4:45 PM, Rocky Bernstein <r...@dustyfeet.com> wrote: > > > > On Thu, Sep 12, 2019 at 5:51 PM Adrian Prantl <apra...@apple.com > <mailto:apra...@apple.com>> wrote: > > > > On Sep 12, 2019, at 2:24 PM, Rocky Bernstein <r...@dustyfeet.com > > <mailto:r...@dustyfeet.com>> wrote: > > > > > > > > On Thu, Sep 12, 2019 at 3:37 PM Adrian Prantl <apra...@apple.com > > <mailto:apra...@apple.com>> wrote: > >> > >> > On Sep 11, 2019, at 1:08 AM, Rocky Bernstein via lldb-dev > >> > <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: > >> > > >> > > >> > Hi - I just wanted to mention that if there are emacs users there is an > >> > interface to lldb via realgud. See > >> > https://github.com/realgud/realgud-lldb > >> > <https://github.com/realgud/realgud-lldb> > >> > > >> > A MELPA package and ELPA packageElpa package are available too > >> > >> Nice. It's always exciting to see wider adoption through better editor > >> integration. Out of curiosity, how does this compare to regular gud.el? > >> (https://opensource.apple.com/source/lldb/lldb-69/utils/emacs/gud.el.auto.html > >> > >> <https://opensource.apple.com/source/lldb/lldb-69/utils/emacs/gud.el.auto.html>) > > > > "Regular" gud? The most recent copyright on that link is 2008. I see a > > gud.el in 26.2 and in the GNU savannah git sources, but neither mentions > > lldb. Assuming that file is really from 2008, has lldb changed since then? > > (This is a rhetorical question). But the broader question is really who is > > maintaining that file you link, clearly it is not the GNU Emacs community. > > And how easy is it to do so? I see an "arch" tag on the file, so I guess > > this in version control somewhere. But if there is a bug in this file, what > > does one do? (This is not a rhetorical question; if you know the answer, I > > am interested.) > > I think this file is effectively abandoned as it is neither part of the LLDB > repository nor is it shipping with emacs in macOS any longer. > > > Adapted from https://github.com/realgud/realgud/blob/master/realgud.el > > <https://github.com/realgud/realgud/blob/master/realgud.el> > > > >> Here we make use of more modern programming practices, more numerous and > >> smaller files, unit tests, and better use of Emacs primitives, e.g. buffer > >> marks, buffer-local variables, structures, rings, hash tables. Although > >> there is still much to be desired, this code is more scalable and suitable > >> as a common base for an Emacs front-end to modern debuggers. > >> Oh, and because global variables are largely banned, we can support > >> several simultaneous debug sessions. > > > gdb-mi has a nicer multi-frame display, but you were linking to gud.el > > which doesn't have that as far as I know. realgud-lldb at this point > > probably knows more about lldb. But you guys can probably verify that, and > > if realgud-lldb is lacking, I'd be interested to learn what should be > > added. > > > > gud has always been a bit too monolithic - it contains every debugger > > (including some obsolete ones - does anyone really still use dbx, and if so > > inside Emacs?). All of this is in that one several-thousand-line file. I > > find this ironic because the principal author is wrote something about > > "Cathedral versus Bazaar" and this is clearly Cathedral style. > > > > It took me quite a while to be able to break realgud into several distinct > > files. In fact I had to write my own nodejs-like "require" package to be > > able to do internal or relative module linking. And then after that, more > > work was done to split off the debuggers from the core debugger module into > > separate github projects. > > Thanks for explaining the differences! > > Is realgud scraping lldb's console output like gud was or is it using the > LLDB scripting API? If it isn't already you might want to consider using the > scripting API since LLDB's console output is not necessarily stable, but the > scripting API is. > > Yes, it scrapes console output and that is a problem. A big problem. > > I looked at the LLDB API and that seems pretty extensive and seems to cover a > lot more of what interaction from Emacs would like and is currently missing. > > However as is in its current state, this isn't going to cut it because Emacs > uses its own Lisp, not Python. > > I have toyed with the idea of hooking into something more standard, and as I > said, there are so many to choose from. For example, the V8 debugger protcol > works over a websocket, and speaking over a websocket is something you can > expect IDEs to grok. Python LLDB's API to say Microsoft's Debug Adaptor > Protocol <https://microsoft.github.io/debug-adapter-protocol/> makes sense, > and https://github.com/vadimcn/vscode-lldb/blob/v1.3.0/MANUAL.md > <https://github.com/vadimcn/vscode-lldb/blob/v1.3.0/MANUAL.md> seems to get > pretty close to that. >
[Adding Greg to the conversation] What's the relation between that project and https://github.com/llvm/llvm-project/tree/master/lldb/tools/lldb-vscode? <https://github.com/llvm/llvm-project/tree/master/lldb/tools/lldb-vscode?> From the comments it looks like this is actually implementing the Debug Adaptor Protocol? -- adrian > > >> > > >> > A question: what ever became of the effort to port the Emacs gdb-mi to > >> > lldb? > >> > >> We recently removed lldb-mi from the LLDB repository because nobody in the > >> community was willing to maintain it. In particular the tests were so > >> unreliable that most bots disabled them wholesale because they were so > >> noisy. We had a GSoC student a year ago who was able to rewrite many of > >> the tests in a more reliable fashion, but there were still a lot of issues > >> outstanding after the project was completed. If you are interested in > >> picking this up, it may be worthwhile to think about implementing lldb-mi > >> 2.0 as thin python layer using the python SBAPI. Python may be a better > >> choice for the kind of text-heavy glue-code that lldb-mi is. Alternatively > >> it also shouldn't be hard at all to revive the existing C++ code. It's > >> written in a different style than most of LLDB or LLVM (and IMO it should > >> have never been accepted upstream in this form), but it shouldn't be hard > >> to get building since it (thanks to the GSoC project!) is using only the > >> stable public SBAPI. > > > > > > The great thing about standards is that there are so many to choose from! > > It sounds like you are very much invested in realgud, but if anyone else is > reading this and interested in taking up maintainership for lldb-mi, I think > we'd be happy to welcome it back in tree as long as it is 100% reliably(!) > tested and maintained. > > Or since we are soliciting help, I'd rather see something that goes to the > Microsoft Debug Adaptor Protocol if vscode-lldb doesn't fit that already. It > might even just be repackaging parts of that code so that it can present > itself that way. In the long term I don't see either gdb-mi and lldb-mi as > viable solution that is going to reduce effort across different IDE's like > the Microsoft Debug Adaptor Protocol could/does. > > > -- adrian
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
