search

RLovelett / langserver-swift

A Swift implementation of the open Language Server Protocol.
Apache License 2.0
177 stars 16 forks source link

enhancement - log tracking / reconn #21

Closed johndpope closed 6 years ago

johndpope commented 7 years ago

I was reviewing the official golang project and some log tracking caught my eye. You may consider cherry picking to catch bugs.

Go Language Server (Experimental)

screen shot 2017-05-15 at 21 19 51

To collect traces, set "go.languageServerFlags": ["-trace"] To collect errors from language server in a logfile, set "go.languageServerFlags": ["-trace", "-logfile", "path to a text file that exists" ]

screen shot 2017-05-15 at 21 24 18

Pretty nice - it exposes the ability to execute methods of go code.

screen shot 2017-05-15 at 21 25 38
RLovelett commented 6 years ago

This project does not make use of the go language server. So I'm not sure how this is applicable. I'm going to close this as I'm not really sure what to do with this.

johndpope commented 6 years ago

consider that langserver-swift should log stuff - and if it does already - there should be a debug flag to turn on and configure.

johndpope commented 6 years ago

the intention being - if (and when) the langserver breaks - people can help report back the errors with logs and community can help - as opposed to it being a black box and it being a - fix it yourself scenario.

RLovelett commented 6 years ago

Ah. Well there absolutely is logging and it is on by default. You just have to know where to look. I think a section in the Wiki or README to explain how to read the logs is probably in order as it is not easily discoverable.

In lieu of that though I can provide you with these one liner gems that I use.

For instance, this will show you all the communications between the language server and SourceKit.

$ log stream --info --debug --predicate '(subsystem == "me.lovelett.langserver-swift") && (category == "SourceKit")'

If you wanted to communications between the language server and client you could do the following with a category of "Request", "Response", "Workspace" or "RequestBuffer".

$ log stream --info --debug --predicate '(subsystem == "me.lovelett.langserver-swift") && (category == <category>)'

If you wanted to see information SwiftPM is outputting as it interacts with the workspace:

$ log stream --info --debug --predicate '(subsystem == "me.lovelett.langserver-swift") && (category == "ToolWorkspaceDelegate")'

On macOS the logging is implemented on Apple's unified logging. There are some pretty good articles and videos out there on how to interact with the logging system. This is a recent one that I've found enlightening: macOS Unified log: 1 why, what and how. There is even a 2016 WWDC video Unified Logging and Activity Tracing on the topic.

I should note that there is no off and it will remain that way for the for seeable future (pull requests are welcome though). I get that there could be performance implications of always having the logging on but the for now the cost (in developing a on/off switch) does not out-weight the benefit of the marginal increase in performance.

Additionally, @felix91gr is doing some great work with tracelog to provide a unified logging solution for macOS and Linux. This will hopefully enable systemd logging on linux with equal or greater support to that on macOS.