Dead project, time for a fork?

[jshbrntt]

This project hasn't been updated in over a year, with many useful pull requests rotting.

Anyone want to work on a fork, where we can merge the stale pull requests and build a CI/CD pipeline to build and publish the extension packages?

[puremourning]

NGL, I have considered it. This is by far the best "native" debug adapter. I understand that the maintainer has significant other time commitments, and as maintainer of other projects I can totally relate. The challenge with forking this particular project is that there is a complex pipeline required to build it (in particular LLDB and portable python) which has not been made public. Getting this right is a helluvalot of work, and great respect to the maintainer for having done it. I personally don't have the appetite to replicate that.

In any case, "dead" I would not call it.

[vadimcn]

This is by far the best "native" debug adapter.

Thanks for the kind words, @puremourning! But is this still true? LLDB's own lldb-dap adapter isn't looking too bad these days.

That said, I've grown tired of constantly chasing breaking changes in LLDB's language service API, as well as Rust's evolving internal representation of std types. Now that there are alternatives, I'm not sure if continuing this effort is worth it.

...Though I've been considering releasing a version of CodeLLDB based on stock LLDB, with Rust language service stripped out. It could use the data formatters shipped with rustc, so there'd still be some support for Rust datatypes.

[vadimcn]

In fact, here's a new build based on lldb-19, with changes I've described above: https://github.com/vadimcn/codelldb/releases/tag/v1.11.0-dev.2410020000

[puremourning]

Thanks so much. Really appreciate it. I'm already taking advantage of the changes in my client.

But is this still true?

yes, very much so. lldb-dap is a successor to lldb-vscode which I've tested and even proposed a number of PRs for, but is weak compared to codelldb in a number of important ways:

• codelldb's implementation of runInTerminal is IMO the reference gold standard. IF all other server authors went to the trouble of launching and attaching a TTY, there would be much happier users
• no-external-dependencies packaging. this is not a universal truth and painful for lowly client maintainers-in-their-spare-time like me
• fast and capable.
• automatic switch to disassembly when no source info (this is a great, under appreciated feature)

In fact, just for kicks I tried out lldb-dap just now with Vimspector, and it doesn't work:

Failed to attach to the target process. Timed out trying to get messages from the runInTerminal launcher

.. it didn't even send a runInTerminal request, so...

it's possible that lldb-dap catches up to CodeLLDB (and perhaps gdb's built in dap support) at some point, but I've tried both and neither are as accomplished. And let's not talk about vscode-cpptools and MIEngine.

So I stand by it, this is the best adapter :)