Collaborating on a Docker recipe?

Development SourceKit-LSP
1

Hi Everyone,

I believe that we'd get instant cross-platform availability, and lower the support requests if we could iron out a guide for running the LSP on Docker or Docker Compose. We could even publish a new image as an addition to Docker Swift with the LSP ready to go.

I've been working on getting it running on the Swift:4.2.1 image, but I'm stuck on what looks like a lib version incompatibility: Concurrency-Mac.cpp:128:3: error: use of undeclared identifier 'dispatch_barrier_sync_f';

2

No, its a flags issue, you just have blocks disabled.

3

I don't quite understand - if it's an easy fix, can you give me an example swift build invocation that'd work?

4

Sorry, I don't have a swift build invocation for you, I've generally been using swift and CMake to accomplish the work :-). You need to figure out how to pass -Xcc -fblocks to swiftc through swift build.

5

Why would blocks being enabled or disabled cause the kinds of errors I'm seeing --- errors because function names are not found, for example.

6

There is a certain portion of the API that uses blocks and therefore must have blocks enabled. On XNU/Darwin, the blocks runtime is guaranteed to be available, and thus the driver always enables blocks support. On other targets, the functionality requires the blocks runtime be present so it is opt in. We build the blocks runtime as part of libdispatch for non-Darwin targets, so you should have the blocks runtime available.

7

Thanks - it didn't have an effect for me. I'm on Swift 4.2, though - the current latest Docker image. Looks like the 5.0 dev snapshot is required.

8

The Ubuntu-based docker image I use has all the dependencies for building the swift toolchain (GitHub - apple/swift: The Swift Programming Language), which is presumably why I don't see this issue. I'm assuming libblocksruntime-dev is the critical piece.

1 Like
9

Thank you - I'll give it a shot: which Docker image do you use?

10

@blangmuir, we actually build BlocksRuntime and have assumptions in the build now that we have libdispatch for the blocksruntime all over the place. libblocksruntime-dev should no longer be needed for swift on Linux.

11

I'm not an expert in swift, but I just put up a Dockerfile and published the image to Docker Hub which runs Sourcekit-LSP. Based on this conversation I'm not sure if I did it right, but feedback and PRs appreciated: GitHub - wylieconlon/sourcekit-lsp-docker: A Dockerfile for running the Sourcekit-LSP project on docker

2 Likes
12

Thanks! I'll give it a try.

13

How are you using it? I got an error with this test:

$ docker run -it wylieconlon/sourcekit-lsp bash
root@548678b621fb:/sourcekit-lsp# swift
error: failed to launch REPL process: process launch failed: 'A' packet returned an error: 8
root@548678b621fb:/sourcekit-lsp#
14

The image automatically runs the LSP, so I have it set up to use “docker run -i -v LOCAL:/mnt/directory wylieconlon/sourcekit-lsp”

Thanks for the question, I will add a README

15

Ah hah, yeah, it'd be great to know how you use it in your development / VS Code? workflow.

16

I'm not using it in VSCode, I am building a new LSP client that can run in a web browser: GitHub - wylieconlon/lsp-editor-adapter: Connects language servers with the CodeMirror editor

I believe you can still follow these steps to get sourcekit-lsp running in VSCode: Swift Development with Visual Studio Code - NSHipster