Atom client requires vhdl_ls.toml

[slaweksiluk]

I use rust_hdl from docker and after some update language server stopped working in Atom. I was using it without any vhdl_ls.tom for simple syntax checking. Now it seems toml project file is necessary?

[Xcodo]

This is because of the changes in #51.

I will see if I can patch the Atom extension.

To get you going you can download a pre-built version of the executable from https://github.com/kraigher/rust_hdl/releases/latest (on linux you may need to chmod the vhdl_ls executable).

[Xcodo]

Sorry, now I see that the build definition comes from the Dockerfile itself. I'll fix it here.

[slaweksiluk]

atom automatically downloaded new docker image with rust hdl, but I still receive similar error (but expected .toml path is different now):

Should I reinstall rust hdl somehow?

[kraigher]

It seems like the vhdl_ls binary is running from /app/ and not /app/bin because it wants to find /app/../vhdl_libraries/

I assumed this was fixed in the new docker file:
https://github.com/kraigher/rust_hdl/blob/master/Dockerfile

[kraigher]

@Xcodo it looks like the vhdl_ls binary itself is named /app/bin and not located in /app/bin/ which explains the problem. I will see if I can fix it.

[Xcodo]

Thanks. I thought I'd understood the documentation but clearly not.

Before my change the last line didn't have the binary name included

ENTRYPOINT ["/app"]

[kraigher]

I pushed a fix now which I am reasonably comfortable works. @slaweksiluk can you try it?

[kraigher]

@Xcodo Before your PR I believe the binary was named app. app was not a folder holding the binary.

[kraigher]

That fooled me when reviewing because I thought /app/bin/ was the parent folder of the binary but in fact is bin was the binary.

[Xcodo]

Ah right, I understand now. Thanks for fixing it.

[slaweksiluk]

Thank you all for efforts. I'm now receiving different error message:

logger.ts:19 VHDL (vhdl_ls) stderr docker: Error response from daemon: OCI runtime create failed: container_linux.go:346: starting container process caused "exec: \"/app/bin/$CRATE\": stat /app/bin/$CRATE: no such file or directory": unknown.
logger.ts:19 VHDL (vhdl_ls) rpc.onClose The RPC connection closed unexpectedly

Can I debug it somehow at my side?

[kraigher]

Looks like $CRATE variable was not expanded but taken verbatim. I pushed a fix to try to remedy it.

[slaweksiluk]

Still no luck:

logger.ts:19 VHDL (vhdl_ls) stderr docker: Error response from daemon: OCI runtime create failed: container_linux.go:346: starting container process caused "exec: \"/bin/sh\": stat /bin/sh: no such file or directory": unknown.

[kraigher]

Strange, @Xcodo @mbrobbel maybe one of you guys have an idea what the problem is? I have "dry-coded" my changes without being able to run the image and see if it works.

[mbrobbel]

@kraigher the problem is that this change c2c6356 modifies the entrypoint to use shell form, which won't work because there is no shell in this image. You can instead choose to hardcode the binary name with exec form.

diff --git a/Dockerfile b/Dockerfile
index 6acdd6e..4e39b95 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -7,6 +7,6 @@ RUN cargo build --manifest-path $CRATE/Cargo.toml --release --features "packaged

 FROM scratch
 ARG CRATE
-COPY --from=builder /volume/target/x86_64-unknown-linux-musl/release/$CRATE /app/bin/$CRATE
+COPY --from=builder /volume/target/x86_64-unknown-linux-musl/release/$CRATE /app/bin/x
 COPY --from=builder /volume/vhdl_libraries /app/vhdl_libraries
-ENTRYPOINT /app/bin/$CRATE
+ENTRYPOINT ["/app/bin/x"]

[kraigher]

@mbrobbel I will try that, I tried using $CRATE in the entry point but it was not expanded and just used verbatim.

[kraigher]

I pushed a commit now which hardcodes then binary name to avoid $CRATE not being expanded but still avoids using the shell which is not part of the container.

[slaweksiluk]

This is working now. Thanks