Comments (33)
@szabba I don't plan to do it specific to IDEA or other IDE. Think of it like the CLI version only over HTTP. The reasons I want it over HTTP are:
- everyone can make a nice interface for it in whatever they want (js+css)
- you can use it over remote machines in your deployment (if you want that) and have the UI on your machine
- it's cross-platform
- WebSockets are not the best thing just yet as they could be a very efficient vector for attack and I wouldn't want to have my name tied to a big security hole just yet :)
This being said, I'm going to draft it this weekend and when @derekparker and other will be happy about it, I'll send a PR to implement it.
from delve.
+1 for this. love the IDEA plugin (thanks @dlsniper !) and would love to see delve integrated!
from delve.
Hey - Thanks for checking it out!
I definitely would like to support editor integration with Delve, that's certainly on the roadmap.
As far as implementation goes, I imagine communication between Delve and the editor happening via a unix socket or websocket rather than exposing a full HTTP interface. This approach will satisfy editor integration as well as allowing web interface integration as well.
from delve.
+1 for this.
liteide integration would be awesome.
gdb debug support is broken since golang 1.3 :-(
from delve.
@derekparker well I'm very serious about making this happen so I'd like to have a chat with you on it before coming up with a PR. If you prefer something else that Gitter, please let me know (my e-mail address is in my Github profile and you can contact me via it or Hangouts).
Thanks.
from delve.
+1 this issue
from delve.
+1000 for Delve integration into Go plugin for Intellij IDEA! That would make IDEA the only real GO IDE. I'll be happy to test it extensively on MAC/PC/Linux too.
from delve.
Would hate to hijack the discussion, but how generic would this interface be? gocode, gorename etc are not IDE-specific, and thats a great boon for a lot of people.
from delve.
I think it might be nice to have the possibility of using the same data exchange format - be it JSON, XML or whatever - irrespective of the medium. HTTP sure would be useful too, but it seems that when debugging locally a popen to the debugger could be a little nicer. Just a thought.
from delve.
I really like the idea of having a browser connected to a remote debugging session. An HTTP server would be easy to implement without requiring any outside dependencies, however I feel that it would be overkill for local editor communication. Really, that's my main hesitation with an HTTP a service.
The more I think about it though, the more excited I get about a browser based debug session, as I think it could be very useful and powerful for a lot of different situations. I'm certainly open to suggestions on the interface, and I look forward to your draft @dlsniper and I'm all ears for anybody else who has written plugins for other editors (vim, emacs, sublime text).
from delve.
here is a http interface https://github.com/simon-whitehead/go-debug
http user interface may also offer a rich visual debugging
from delve.
there is also this one:
https://github.com/sirnewton01/godev
with the GDB interface:
https://github.com/sirnewton01/godbg
from delve.
@dlsniper "WebSockets are not the best thing just yet as they could be a very efficient vector for attack and I wouldn't want to have my name tied to a big security hole just yet".
Can I suggest you reconsider this? A websocket offers 2-way communication and will be more appropriate when the server needs to initiate messages. For example, you could always be running in debug mode while developing and the server would intercept errors and break at the line containing the error (like Visual Studio). That would be hard to implement without a 2-way socket.
As for security, we're talking about a debugging tool for developers, not a generic websocket library so it will be disabled most of the time in production. We could also make it only work over TLS for remote communications. What do you think?
from delve.
BTW, I met and spoke with Rob Pike in the Sydney Go Meetup last week and asked him about the status of an official Go debugger. He said it was very hard to create one properly but said they are looking into it. He also said he knew about this repo and said he was watching it... I couldn't actually remember the name of the project but he reminded me that it was "Delve" :)
from delve.
Completely agree with @NuriKevenoglu
99% of the cases you would run this tool on your local machine - web socket is the way to go if you are using a browser. And you can still use some form of authentication token (JWT for example). TLS should be mandatory for remote use. I cannot think of a case where I would debug remote code...
I have used extensively node-inspector
for debugging node.js apps in browser since its creation - it is very convenient and it uses web sockets.
from delve.
@NuriKevenoglu I agree, a socket based implementation is ideal, and what I had in mind when this issue was opened.
That's fantastic that it's on his radar! I have a lot planned for Delve, and a lot of improvements that I hope to have merged in soon. Also I really appreciate the input and work put in so far from the community.
from delve.
@derekparker I told you you had more fans than you know... ;)
from delve.
Unfortunately I haven't been able to do anything relevant this weekend due to some personal issues. However, it does seem that majority of people would like to use websockets (and I can see the benefits for that as well). As such, I'll update my proposal and come back with something based on those. Thanks for holding on and for the input on this one.
from delve.
@dlsniper Any progress on this? Can I perhaps help with input on the proposal?
from delve.
Sorry, I've been away with some personal issues. I'll have more time in the next weeks as I'll be off-duty from my job.
I'm cc-ing @ignatov here to keep an eye on this.
from delve.
Any more ideas on this?
I think it could be interesting and benefitial to modify the current architecture to be more client / server, with communication happening over channels. That way the backend "server" could remain unchanged, and different clients could potentially just be plugged in. I may work on some of this initial rearchitecting, which could simplify the proposals for IDE integration clients.
from delve.
+1 for websockets. It is easy way for send messages from each side and easy to integrate with browsers to build webUI. I more interested with integration with GNU Emacs, it has libs for websockets support.
from delve.
+1 for this feature, would be very useful for developers where I work.
from delve.
I just reviewed @dlsniper's websockets branch. Have you taken a look? What are the chances you'll eventually accept a PR based on the approach? It's not how I would have gone about the refactor, but it looks viable.
I ask because I was interested in starting to integrate delve with my own Sublime tooling, and am trying to decide where to most effectively spend my time (e.g. contributing to @dlsniper's branch, contributing to some other more acceptable branch you know of, starting my own client/server refactor, a stopgap interface to control the CLI directly, etc.)
Thanks for this tool!
from delve.
I'll do the promised rebase this weekend as I finally have time for it, sorry for disappearing for a while.
from delve.
I volunteer to help test the IDEA plugin, as I'm using it already and would love to help improve it. A working Go debugger in IDEA is nirvana.
from delve.
@ironcladlou I haven't taken a look recently, I've been polishing the OS X stuff and mucking around with the core. I'd like to take another look after the rebase has happened since there has been a lot of changes on master recently that may or may not affect this branch.
So to answer your question, I'm certainly open to more discussion around this, and if you were interested in working through a pure refactor I'd absolutely be open to that. There are no competing branches for this feature that I am aware of.
There are some high level refactors I would love to work on / accept PRs for, namely moving towards a client/server implementation with the existing cli, i.e. dogfood first with what exists and build out from there, essentially making the CLI a client of the server, preventing it from using proctl
directly, instead sending commands with arguments to a core server which actually handles process manipulation.
Then with that refactor done, this PR could be simply adding a new client to the core debug server, with a standard interface that has been defined via usage by the CLI. If you'd be interested in working on that ( @ironcladlou or anyone else) I'd happily help move it along and merge it, as currently I'm spending a majority of my time working on the guts of the thing.
@dlsniper thanks for your work on this and I will promptly take a look at the branch post-rebase.
from delve.
So, for discussion I thought it'd be faster to just start a POC of the client/server separation I had in mind. Here's my WIP branch:
https://github.com/derekparker/delve/compare/master...ironcladlou:http-api?expand=1
What I've done there is:
- Started a public API in
api/types.go
. For now, and for simplicity's sake, this is unstable. Later, you could subpackage public typesapi/v1beta1
or something, useapi/types.go
as the internal types, and convert to/from internal/external with registered API converters. This would allow IDE integrators to have stable versioned APIs on which to build tools, while allowing you the flexibility to advance the API internally and eventually mint new public versions while maintaining backwards compatibility.- For an example of this in practice, check out Google's Kubernetes or OpenShift Origin; I work on both and so I have this stuff on the brain lately.
- Built a
net/http
server inproctl/server
on top ofproctl/DebuggedProcess
. This abstracts access to the debugging session. It's not yet websocket based. - Defined a Go client interface in
client/client.go
which provides Go consumers with an interface to the server. The default implementation uses thenet/http
library to make server requests. - Changed the responsibility of the
dlv
command to be:- Start and attach to the process
- Spin up the server
- Instantiate a Go client to the server
- Create a CLI which uses the client to interface with the server (it also gets a pointer to the process for backwards compatibility to allow piecemeal replacement of commands)
- Decoupled the CLI (terminal) from the session bootstrapping; the CLI is now able to be incrementally converted to a pure Go client implementation
There's still a ton of work to do:
- Finish defining the API
- Finish implementing the server interface
- Convert the web server to a websockets implementation
- Abstract encoding/decoding
- Abstract server handling boilerplate
- Support public API versioning/conversion
- Godocs
- API documentation
Other random stuff that could be done:
- Take full advantage of websockets by implementing something like
syscall.Wait4
or something to allow client breakpoint notification subscriptions.
Have a look and let me know how you feel. If you like the direction, I'd be happy to work on it in my spare time.
from delve.
@ironcladlou I've looked at the changes you've done and it looks interesting. The ideas you have for how to approach the API are good. However, before you can do that, I believe a separate refactoring of the internals should be done as currently none of the internal commands are returning the output but rather use fmt.Print*
directly. I'd be happy to have a look every now and then over the progress but I can't do any sustainable effort to first to the internal changes then implement something on top of them.
from delve.
However, before you can do that, I believe a separate refactoring of the internals should be done as currently none of the internal commands are returning the output but rather use fmt.Print* directly.
We might be having a terminology mismatch here. I already changed the command interface and two command implementations (breakpoints and threads) to use the new API client. I think some confusion is coming from the mixed terms at play here.
I have other ideas for how the CLI should be refactored to draw better distinctions (e.g. daemonized server mode, interactive client mode, foreground server/interactive client), but I'd rather discuss those in a PR.
from delve.
Moving the discussion to #88 to keep this thread clean.
from delve.
+1, and I'd like to add Idea is the only real IDE... period.
from delve.
with #88 being closed, I think I can close this one as well. If not, please feel free to reopen this.
from delve.
Related Issues (20)
- polish go1.23 range-over-func UX HOT 1
- Does delve ignore // line instructions during debug HOT 1
- Breakpoints do not work in packages with a TestMain(*testing.M) function HOT 1
- Unable to print a package string const value during a breakpoint HOT 1
- Error clearing stack watchpoint HOT 2
- Add defer functions to follow-calls tracing option
- Breakpoint line numbers not matching HOT 1
- Hitting compile error when launching delve in devbox HOT 4
- `undefined behavior - version of Delve is too old for Go version 1.22.3 (maximum supported version 1.20)` HOT 2
- trace: allow tracing from (or skip tracing on) G-less threads
- panic when data length is greater than memCache size
- Unable to find escape variables when using Delve HOT 7
- Fail to set watchpoint after clearing one of four HOT 3
- Dwarf parsing infinite loop causes OOM HOT 1
- Feature request: restart the current function HOT 6
- Seeing a warning that delve is too old for the latest Go version 1.22.5 HOT 1
- align the output of vars with 'expresson' spec
- Delve Fails to Locate Source Files Across All Projects on Apple M1 Pro (macOS) with "no source available" Error HOT 1
- Improper string representation of Google uuid.UUID type HOT 1
- Inconsistent go and delve expression results
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from delve.