Prince781
commented
2 years ago Hi, can you share the full output log?
Open elsiehupp opened 2 years ago
Prince781
commented
2 years ago Hi, can you share the full output log?
elsiehupp
commented
2 years ago Here's the output from the "Vala Language Server" drop-down in "output" tab. (Note that the errors here are consistent with the errors that I should be getting inline.)
And here's the output from a few other drop-down items under "output". (Note that this is on a macOS host device.)
And here's the output from ninja -C Build. (Note that the errors are, for the most part, expected; they're just not inline.)
Colin has since told me that when he reproduced the issue in Sublime Text, he did so not in a Docker container but rather on a regular elementary OS device.
Nonetheless, here are some other possible causes:
Please do let me know if there's anything else you need. Thanks!
Prince781
commented
2 years ago @elsiehupp you need to enable debug mode. You would get much more informative output, then.
To do this, go into the extension settings and enable "Debug Mode." Then rerun VLS and give me the log.
Prince781
commented
2 years ago I will say it looks from your build log that your project can't compile, which could be the root cause, but we'll have to see what the log says.
elsiehupp
commented
2 years ago Hi @Prince781—thanky you for your response!
I will say it looks from your build log that your project can't compile, which could be the root cause, but we'll have to see what the log says.
I ran into an issue with Meson not properly cloning a wrap-git subproject. Commenting that subproject out means that Meson configuration succeeds, but obviously the project still doesn't compile.
Note: The project not compiling is completely unsurprising, as there are tens of thousands of errors, and indeed I had been depending on Vala code intelligence to help me stamp them out up until code intelligence stopped working.
EDIT: Note: I switched from using a macOS Docker host back to using an elementary OS Docker host in part because my elementary OS PC is more powerful but more importantly because I couldn't get GPG Git signing to work inside Docker on a Mac.
Anyway, with the Meson changes and with debug enabled on the Vala extension—see this commit I just pushed—the output is as follows:
The other logs are as follows:
And ninja -C Build:
Prince781
commented
2 years ago The problem here is that you're using a version of VLS that's over a year old:
This might be fixed in the latest stable release, which is the only version of VLS that we support. What you can do is have your container build and install VLS 0.48.5, then see if you still have this issue.
elsiehupp
commented
2 years ago Okay! So I removed the elementary OS version of vala-language-server, then cloned, built, and installed it from this repository, and it is now reporting version 0.48.5.
As an aside...
(Regarding the Dockerfile)
`README.md` still suggests [installing the outdated version from elementary's `apt` repository](https://github.com/vala-lang/vala-language-server/blob/4773fbb7256ce783d0e502449821ca2462465cf0/README.md?plain=1#L14), and [the version for Ubuntu](https://github.com/vala-lang/vala-language-server/blob/4773fbb7256ce783d0e502449821ca2462465cf0/README.md?plain=1#L12) only goes back to Ubuntu 21.04, while the current stable version of elementary is still on Ubuntu 20.04 LTS. Obviously elementary moving to Ubuntu 22.04 LTS with their next release will help with compatibility, but it would still be nice if there were a way to install the current version of `vala-language-server` via `apt` on elementary 6.1. If it's simply not possible to get the current version of `vala-language-server` on the current version of elementary OS, I'm personally okay using a different distro for the development container, especially if it would help with dependencies. ***Do you have a recommendation for what distro to use with `vala-language-server`?*** It sounds like Guix supports everything and makes dependency management a lot easier? Anyway, if it's any help, once I get the development container situation figured out (i.e. with Guix or whichever other distro you recommend), I'd be happy to make a pull request for a Vala Dockerfile to make it easier for other people to do the same. > ***Edit:*** I found [a Dockerfile for Alpine Guix](https://github.com/bmpvieira/Dockerfiles/tree/master/guix) that seems like it could be a good starting place.
Here is the same set of outputs after I switched to vala-language-server 0.48.5 and relaunched the VS Code workspace (though without rebuilding the container). No, code intelligence is still not working. I haven't added the shell scripting to the Dockerfile for installing vala-language-server 0.48.5, but I'm thinking it might be more productive to create a new Dockerfile based on your distro of choice instead. (See the above.)
Prince781
commented
2 years ago The root cause here may be that because at least one of your subprojects fails to build, the main project might be without a .vapi it expects. I'm not immediately sure how this should be handled.
Prince781
commented
2 years ago However, if you said this only fails inside a container, that's even stranger...
elsiehupp
commented
2 years ago However, if you said this only fails inside a container, that's even stranger...
@colinkiama was apparently able to reproduce the issue outside the sandbox (also on elementary OS). He talked about it on the Vala Discord but hasn't had a chance to drop by this issue thread, yet.
Way back in my original comment, I did say this:
There is also a non-zero possibility that the issue doesn't actually have anything to do with the Dev Container but rather arose from other changes I made around the same time, but it's difficult to test this hypothesis either way.
Basically I did the switch to Meson subprojects at roughly the same time that I did the switch to a Docker container, which made it difficult to tell which of the two was the likely culprit. Oops!
The root cause here may be that because at least one of your subprojects fails to build, the main project might be without a .vapi it expects. I'm not immediately sure how this should be handled.
I mean, the odd (or frustrating) thing here is that code intelligence just silently fails, without prince781.vala popping up a notification about it.
Note: Similarly, when
prince781.valaruns into a Meson configuration error, it just gives the error number, e.g. "Error 256", without any apparent way to view the full error message without manually running Meson or Ninja in the command line. Though idk this might have been addressed in the past year, since I haven't used the newer version ofvala-language-serverfor more than like five minutes, so I haven't been able to see what a Meson error notification looks like in the new version.
I guess the issue then is that there's an error in the build process that causes code intelligence to fail to launch, but neither prince781.vala nor vala-language-server provides any particularly straightforward error message explaining what is wrong so that it could be fixed. Does that sound correct?
Another side note: I was running into issues with the
[wrap-git]for Gpseq not cloning the repository like it was supposed to, so on @colinkiama's suggestion I just commented it out from the dependencies. The weird thing is that the[wrap-git]was working before but stopped working for no apparent reason, though it may be due to the same underlying cause that is breaking Vala code intelligence.I mean, I could try gradually commenting out more and more of the
meson.buildfiles until code intelligence starts working again, in order to see if there's any particular change that seems to be messing it up. Something in the Meson or Ninja output probably points to whatever the problem is, but the formatting and annotations are a bit opaque.Note within a note: Regarding Meson configuration issues: I very much have no idea what I'm doing! 😅 I'm gradually learning through experience, though, so it's inevitable that I will be constantly making mistakes. The frustration for me is when the output from my coding mistakes doesn't immediately point to anything I can google in order to learn what I did wrong and fix the problem.
Another 'nother aside: apologies for kind of thinking out loud (though I am indeed carefully editing what I'm writing). I hope the slightly excessive Markdown formatting is helpful, though! 🤓
elsiehupp
commented
2 years ago I changed the title because the issue doesn't seem to be specific to the container.
I did comment out literally everything except the class names, so that compilation would work (though with no actual code), and code intelligence started working again, so the container doesn't seem to be the problem. I'll follow up if I have any further information down the line.
Vysp3r
commented
2 years ago Personally mine is failing to start when I add dependencies other then the one provided by the GNOME Builder template for Vala applications. Here's a snippet of my meson.build. The libsoup-3.0 is the dependencies troubling the language server for me.
redacted_sources = [
'main.vala',
'application.vala',
]
redacted_deps = [
dependency('libadwaita-1', version: '>= 1.0'),
dependency('json-glib-1.0'),
dependency('libsoup-3.0'),
]
gnome = import('gnome')
redacted_sources += gnome.compile_resources('redacted-resources',
'redacted.gresource.xml',
c_name: 'redacted'
)
executable('redacted', redacted_sources,
vala_args: '--target-glib=2.50', dependencies: redacted_deps,
install: true,
)edit: I was just dumb and installed the wrong dev package on my system. It works fine now.
Describe the Bug
I'm having trouble with getting
vala-language-serverto do VS Code code intelligence in a Docker Dev Container (based on the elementary OS Odin Dockerfile; customized version here). Vala Language Server does show up in the drop-down menu under "Output", but none of the output appears with inline code intelligence (i.e. under "Problems").I was, in fact, able to use Vala Language Server VS Code code intelligence in a regular elementary OS setup, but I haven't gotten it to work since I set up a Docker Dev Container. There is also a non-zero possibility that the issue doesn't actually have anything to do with the Dev Container but rather arose from other changes I made around the same time, but it's difficult to test this hypothesis either way.
I should also mention that, yes, both
vala-language-serverand theprince781.valaVS Code extension are installed and set up in the Dev Container: I do have syntax highlighting and output, just not inline code intelligence, so it seems like the two maybe just can't see or talk to each other? The container settings do manually specify the install path, though.Software
aptrepository (installed by the Dockerfile during the container setup)valac --version): Vala 0.48.24To Reproduce
Source code repo: https://github.com/elsiehupp/sync/
To open the repository in a VS Code Dev Container: