search

atom-community-archive / debugger

A Debugging Package For The Atom Editor
Other
7 stars 2 forks source link

Basic API structure #2

Open steelbrain opened 9 years ago

steelbrain commented 9 years ago

I am thinking of creating an Xdebug provider for this package

steelbrain commented 8 years ago

@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 commented 8 years ago

@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:

Thoughts?

steelbrain commented 8 years ago

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

wfdctrl commented 8 years ago

@steelbrain well I am now :smile:

steelbrain commented 8 years ago

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
keplersj commented 8 years ago

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 https://github.com/atom-community/debugger/issues/2#issuecomment-167629957 .

wfdctrl commented 8 years ago

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:

Nice to have:

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 commented 8 years ago

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

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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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

There are currently two ways to go about this:

Any thoughts on this?