Skip to content
This repository has been archived by the owner on Jul 15, 2023. It is now read-only.

Add Logpoints support #1751

Closed
lggomez opened this issue Jun 22, 2018 · 10 comments
Closed

Add Logpoints support #1751

lggomez opened this issue Jun 22, 2018 · 10 comments

Comments

@lggomez
Copy link
Contributor

lggomez commented Jun 22, 2018

Logpoints are a special kind of breakpoint provided by VS Code that just logs messages unpon being hit, instead of stopping and showing the current stack trace/frame information

The difference between a regular breakpoint and a logpoint seems to be in this property: https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/debug/common/debugProtocol.d.ts#L1413-L1414

We could support this although I'm still not sure on how to bypass the SetBreakPointsRequest delve apicalls and still be able to track the logpoints

This belongs to the SourceBreakpoint interface so I guess it is related to #1676

@ramya-rao-a
Copy link
Contributor

This would be a cool thing to explore. Am out on vacation next week, will get to this once am back.

@Nox-404
Copy link

Nox-404 commented Oct 13, 2019

Hello there,
I'll need that too, please implement this :)

@danj565
Copy link

danj565 commented Apr 2, 2020

This would be an amazing enhancement!

@hyangah
Copy link
Contributor

hyangah commented Apr 2, 2020

@quoctruong @polinasok Can you please take a look? Can this be implemented from Delve side?

@lggomez
Copy link
Contributor Author

lggomez commented Apr 3, 2020

I can give it a look, this shouldn't need any changes on the delve side, aside from the fact that CreateBreakpoint doesn't have anything explicit (that I know of) to enable us to build this feature: https://godoc.org/github.com/derekparker/delve/service/rpc2#RPCServer.CreateBreakpoint

This is the current spec, and the following is found about logpoints on the SourceBreakpoint interface:

  /**
   * If this attribute exists and is non-empty, the backend must not 'break' (stop)
   * but log the message instead. Expressions within {} are interpolated.
   * The attribute is only honored by a debug adapter if the capability 'supportsLogPoints' is true.
   */
  logMessage?: string;

If delve doesn't handle this, we can still hack it on our side, bu we´ll have to keep transient state about these breakpoints so we handle them differently (just log and return) upon debugger callbacks

@hyangah
Copy link
Contributor

hyangah commented Apr 3, 2020

@lggomez Another thing to consider is the new DAP support from delve side.
https://github.com/go-delve/delve/tree/master/service/dap The Go extension is not yet using the DAP but we will switch eventually. So, I'd first discuss this with delve dev whether it makes sense for delve to provide this feature.

@lggomez
Copy link
Contributor Author

lggomez commented Apr 3, 2020

@hyangah Nice, I wasn't aware of this work in progress, having a DAP compliant service will iron out most of the current frictions with the v2 API surface (and hopefully the performance issues)

When I commented that delve wouldn't require changes is for the most conservative and basic case which is logging text-only messages from the adapter. To provide full support for logpoints, delve should receive a message containing either:

  • A well defined pair of messages, the layout and the local variable parameters; i.e: "hello %s", foo
  • A complete function call which does this capturing said local variables: fmt.Sprintf("hello %s", foo)

Both both vary the implementation but on an API level I think the requirement is more or less the same, since we'll be constrained by the standard fmt placeholders for interpolation

@danj565
Copy link

danj565 commented May 8, 2020

Would you like me to open an issue with Delve? Has the go extension implemented the DAP service yet?

Thanks for the great extension. Having log points would make debugging our websocket apps a lot easier.

@activeshadow
Copy link

activeshadow commented May 18, 2020

Does anyone have a timeline for this feature? I will by no means pretend to even have the slightest clue about how the Go development extension works at the TypeScript code level, nor the complexity of the extension, nor the complexity of the interaction with Delve, but even as a MVP for this feature it would be awesome if a log point simply evaluated the configured expression and automatically continued on with program execution (as opposed to the user having to manually hit the "play" button). I know this would require tracking log points separate from breakpoints in the extension to know if program execution should be automatically continued, so again I'll reiterate my lack of a clue about whether or not this is currently even possible or how complex it would be.

Ultimately, I currently find myself adding log messages to my code, recompiling, redeploying to the cloud, etc. over and over again when debugging certain types of issues / code execution flow. The ability to deploy a debug version of my app, running via Delve, to the cloud one time and dynamically being able to add logging via log points would be, for lack of a better term, SWEET!!!

Regardless, I want to express my appreciation for the maintainers of the Go extension. 👏👏👏

@ramya-rao-a
Copy link
Contributor

Hello all,

We are in the midst of a repo move, see We are moving section in our readme for more details.

Closing this issue in favor of golang/vscode-go#123. Please subscribe to it for further updates and upvote it as well

Thanks for all the support & Happy Coding!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants