Collaborating on a Docker recipe?

(Robb Shecter) #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';

(Saleem Abdulrasool) #2

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

(Robb Shecter) #3

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

(Saleem Abdulrasool) #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.

(Robb Shecter) #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.

(Saleem Abdulrasool) #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.

(Robb Shecter) #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.

(Ben Langmuir) #8

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

1 Like
(Robb Shecter) #9

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

(Saleem Abdulrasool) #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.

(Wylie Conlon) #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:

(Robb Shecter) #12

Thanks! I'll give it a try.

(Robb Shecter) #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
(Wylie Conlon) #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

(Robb Shecter) #15

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

(Wylie Conlon) #16

I'm not using it in VSCode, I am building a new LSP client that can run in a web browser:

I believe you can still follow these steps to get sourcekit-lsp running in VSCode: