Writing an Atom IDE debugger


#1

I’ve been noodling around with updating some old Swift integration packages, and had started working on expanding atom-swift-debugger - which uses lldb and swift’s package manager - when I discovered the atom-ide-ui stuff.

I’ve been trying to puzzle my way through the documentation and figure out what’s already there, and how I can integrate with it. I could really do with a few pointers.

For now, I’m leaving the LSP side of things to one side, and am just interested in providing a Swift debugger.

I have some code which has it’s own way of marking and tracking breakpoints, building a swift package, launching it in lldb, and providing UI to do some fairly crude interaction with the lldb repl.

What I’d like to figure out is how, and/or how much of this, can I replace with atom-ide-ui’s services.

From the nuclide source, it looks like there’s lldb support already - at least there are some tantalising references to it, but it seems to be missing. Is that the case? If so, how do I go about hooking into it?

If not, how would I go about implementing my own debugger.provider?

Or failing that, is there a way that I can start small and just get access to atom-ide’s list of breakpoints, so that I can adopt that part of the UI first?

I’ve taken a look at some of the debuggers listed here, but they are all quite intimately entangled with Nuclide and pretty hard to use as the basis for something new when you don’t have the context and the documentation is a bit sparse.

What would be ideal would be a really simple example which supplied a fake debugger - one that implemented all the relevant hooks but actually didn’t do anything, so that it was easier to understand where the Atom/Nuclide interfaces end and the actual debugger implementation begins… if you see what I mean!

Any help appreciated!


#2

To answer part of my own question, I found a way to do this, but I suspect that it’s an abuse of the system :slight_smile:

If you consume the remote.debugger service, you get passed something that you can extract the debugger model from:

consumeDebugger(d) {
    const service = d._service;
    const model = sevice.getModel();
    const breakpoints = model.getBreakpoints();
}

I imagine that you’re not really supposed to (need to) interact directly with the model in this way - there’s a clue in the fact that I’m having to rummage around in a private property.

However, I’ve found that it’s given me the ability to hook into the breakpoints UI whilst still temporarily driving the interaction with lldb from completely custom code.