Basic API structure

[steelbrain]

I am thinking of creating an Xdebug provider for this package

[steelbrain]

@joefitzgerald I am interesting in working on this repo. Do you have anything in mind related to this? I mean about the UI or what the base API should look like.

[wfdctrl]

@steelbrain I did some research on the subject. I think that the best course of action is to create a common high level protocol that providers can then use directly in case the debugger is implemented in a form of a library or provide a translator to a different protocol.

To get the widest range of supported languages with minimal effort I suggest we focus on the following:

• GDB/MI: support for C, C++, D, Go, Objective-C, Fortran, Java, OpenCL C, Pascal, assembly, Modula-2, and Ada. We can use the work done in https://github.com/xndcn/atom-debugger/.
• DBGP: support for PHP, Python, Ruby, Perl, Tcl and NodeJS. Maybe we can create something similar that was done for vim in https://github.com/joonty/vdebug.
• Browser DevTools: I've seen https://developer.mozilla.org/en-US/docs/Tools/Valence mentioned somewhere, but I'm not sure how useful it is.

Thoughts?

[steelbrain]

@wfdctrl are you on atom slack? I would love to collaborate with you on this

[wfdctrl]

@steelbrain well I am now 😄

[steelbrain]

To everyone subscribed on this, I'll be updating this reply to reflect API updates as we work them through. I'll make sure to note every significant change at the bottom, here's the object that the debugger service providers will export

{
  name: 'ruby',
  scopes: ['source.ruby'],
  supportedFeatures: ['repl', 'breakpoints', 'stepping'],
  statusChanged: Function(bool)<void>,
  stepIn: Function()<void>,
  stepOut: Function()<void>,
  pause: Function()<void>,
  resume: Function()<void>,
  breakPointAdded: Function(TextEditor, int lineNumber)<void>
  breakPointRemoved: Function(TextEditor, int lineNumber)<void>,
  replHandle: Function(String)<void>
}

I'm also thinking that we should assign certain objects to the debugger, like the repl console for example,
They could do

replHandle: function(contents) {
  this.console.write(parseInt(contents) + 1) // this is a stream, so you can even pipe into it
}

Changelog

• Initial API proposed

[keplersj]

Hey! That looks like linter's api! ;)

On Mon, Dec 28, 2015, 12:06 PM Steel Brain notifications@github.com wrote:

To everyone subscribed on this, I'll be updating this reply to reflect API
updates as we work them through. I'll make sure to note every significant
change at the bottom, here's the object that the debugger service providers
will export

{
name: 'ruby',
scopes: ['source.ruby'],
supportedFeatures: ['repl', 'breakpoints', 'stepping'],
statusChanged: Function(bool),
stepIn: Function(),
stepOut: Function(),
pause: Function(),
resume: Function(),
breakPointAdded: Function(TextEditor, int lineNumber)
breakPointRemoved: Function(TextEditor, int lineNumber),
replHandle: Function(String)
}

I'm also thinking that we should assign certain objects to the debugger,
like the repl console for example,
They could do

replHandle: function(contents) {
this.console.write(parseInt(contents) + 1) // this is a stream, so you can even pipe into it
}

Changelog

• Initial API proposed

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[wfdctrl]

This is much better than my original idea, I should have looked at the linter API more closely. I guess it's best to leave the protocol choice to the providers and only define the API in terms of a contract. Things that are missing:

Crucial:

• stepOver (aka next)
• evaluate (evaluate an expression)
• refresh (get the current line number, stack trace, local variables, watched expressions etc.)

Nice to have:

• addWatch
• removeWatch
• different types of breakpoints: conditional, exception, watch...
• disableBreakpoint (must-have for huge files)
• enableBreakpoint
• goToCursor or temporary breakpoints

Most of these are pretty much self explanatory... I think I'm going to start working on a DBGP provider, that way we get support for most languages Atom is actually used for.

[wfdctrl]

I did some more research... I compiled a list of all protocols that should be supported:

• Chrome: https://developer.chrome.com/devtools/docs/protocol/1.1/debugger#type-Scope
• Firefox: https://wiki.mozilla.org/Remote_Debugging_Protocol
• DBGP: http://xdebug.org/docs-dbgp.php
• GDB/MI: https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html#GDB_002fMI

Only thing that is still missing are commands for Threads. @steelbrain I noticed you wanted to work on the Xdebug provider, which uses DBGP, maybe we should create a common repository and work on this together?

[steelbrain]

@wfdctrl Sure, We could create base packages on npm named like debugger-protocol-dbgp and debugger-protocol-chrome and then extend them in atom packages

[wfdctrl]

@steelbrain This sounds like a great plan. I guess somebody already created a similar package for the chrome debugger https://github.com/DickvdBrink/chrome-debug-protocol, it might be of some use to us.

[steelbrain]

@wfdctrl I think we have a confusion among ourselves. What I'm trying to achieve is that we use the debugger protocols and talk to languages or programs and debug them and provide our own UI completely instead of exporting it to chrome dev tools or firefox dev tools. What you have linked seems to be like a remote-control of the UI of Chrome Dev Tools.

I would really appreciate it if you would clarify what you have in mind

[wfdctrl]

@steelbrain there is no confusion here. The chrome remote debugging protocol allows debugging javascript that is running inside a browser. That means that we use our custom UI to drive a browser debugger directly out of the editor. I think eclipse supports something similar...

[wfdctrl]

@steelbrain and I had a discussion about the console input and output.

There are currently two ways to go about this:

• Start the program in an embedded terminal window.
  Pros: simple, the stdin and stdout can be handled in one place by the base class.
  Cons: console programs cannot be debugged remotely because the terminal window is not accessible in that case
• Use the commands provided by the protocol.
  Pros: remote access to stdin and stdout, therefore console programs can also be debugged remotely.
  Cons: each provider has to handle stdin and stdout.

Any thoughts on this?