I’ve tried installing Julia 1.9 on my desktop machine (previously using 1.8 and older ones).
I use VScode as editor. It seems that VScode Julia language server cannot handle my new installation as it fails precompiling and keeps crashing (see below).
I’ve fully reinstalled VScode and Julia (even removed .julia and .vscode), I’ve also tried downgrading the server and flushed settings.json but non of this helped so far.
Similar issue was discussed some time ago but I’m not sure how this applies to the current situation.
Any hints would be welcome!
Cheers and thanks!
This is a result of my attempts to add precompilation to the LanguageServer.
To add precompilation to the LanguageServer, I ran the server during package initialization. However, this attempts to download some symbol caches. In your case, the LanguageServer could not reach the server hosting the symbol caches for some reason. That step failed which in turn caused precompilation to fail.
I detailed my initial attempt to do so here:
I was hoping someone would help me figure out how to make that initial attempt more robust, but we ended up merging it in directly.
To resolve this, first resolve the network issues.
Then in a Julia REPL, probably outside of VS Code, I would run the following.
using Pkg Pkg.activate(; temp = true) Pkg.add("LanguageServer")
That should force the language server to redo precompilation, this time hopefully with a functional connection to the server. Meanwhile, I will try to figure out how to make precompilation more robust.
@tim.holy Do you think there is something PrecompileTools.jl could do here to catch an error during precompilation but let precompilation continue?
We could have PrecompileTools do the following:
- Catch any errors that occuring during
- Store the error and backtrace in the package cache.
- Provide a way to retrieve any precompilation errors later, and perhaps provide a utility to display these during
__init__and recommend repeating precompilation.
Errors while downloading the symbol cache should never be fatal, neither during normal execution or precompilation, so I’m not sure what exactly is going on here.
Thanks for the reply. Unfortunately, this did not work. I’ll work on my lappy in the meanwhile. Feel free to reach me by PM if you want me to try some things out.
julia --pkgimages=no seems to have gotten around the initial issues. Gravlax is using macOS Mojave.
This seems to be another case of Can't install packages on v1.9 MacOS · Issue #49775 · JuliaLang/julia · GitHub
What would the advantage be to that over the programmer putting in a
try/catch into the
@compile_workload block? In general I’m a little reluctant to hide errors unless there’s a really good reason to do so. For example,
open(f, filename) definitely needs a try catch around
f in order to satisfy its promise to close the file after calling
f, but there’s no guarantee I know of that precompilation should succeed even for buggy workloads. (I’m sure you know that’s not an accusation about the quality of your LanguageServer workload. If I had a nickle for every buggy workload I’ve written…)
try/catch is needed, I’d rather it be explicit in the code that everyone can see when inspecting the package.
There are two separate issues. One is logging. The second is error handling.
The logging issue belongs to other layers such as the individual package or Pkg which orchestrates parallel precompilation. I’ll defer further discussion of that. The main helpful thing PrecompileTools.jl could do here is perhaps note thst the error occurred while using its macros since macros are not a very clear part of a stack trace.
The other issue is error handling.
Packages should not fail during precompilation or loading, especially if the failure is not critical to the function a package. The consequences for failing are severe since all packages which depend on the failing package will also fail to load. A package which does not load at all is also much more difficult to debug.
The work being done during PrecompileTools.jl’s
@compile_workload is not critical to module loading. This is only run when generating cached code to disk. If the workload had to run, it should not occur within those macros. Module compilation can be turned off by command line arguments to Julia. Thus, anything run within these macros is only for optimization. A failure during an optimization step should not cause a package to fail to load. An unexpected error here should still be reported, but not cause precompilation and module loading to fail. Because these macros should not fail, PrecompileTools.jl should help ensure that.
In the case of LanguageServer.jl, the current
@compile_workload always results in an error being reported. That specific error should be suppressed.
Catching errors during
@compile_workload, reporting them, and resolving them may require repetitive non-trivial code.
- PrecompileTools.jl may be better situated to address certain errors. Issues with Preferences.jl and global options come to mind. Another situation may be insufficient disk space.
- Reporting these errors should be well coordinated with the logging system, and we should build facilities to re-report these errors at a different time. For example, one may want to issue a warning that
@compile_workloadprecompilation was not successful on subsequent attempts to load the module.
- Resolving these issues require a specialized facility to invalidate the cache and force precompilation again. Some of this might be a
Pkg.precompile. However, PrecompileTools.jl might be able to uniquely detect non-critical
@compile_workloaderrors, and subsequently encourage those packages to be precompiled again.
What I’m discussing here may be getting confused with another issue that is particular to LanguageServer.jl. I’m not trying to hide errors. Rather, I would like to
- Make the
@compile_workloaderrors non-fatal to package loading and precompilation by default.
- Improve reporting of those errors and providing the ability to re-report them at a later time when parallel precompilation is not happening.
This error has nothing to do with the new precompile supported added to LanguageServer. The original error message shows that this is from the extension version v1.38, which was released in October, long bevor anything related to precompile was merged.
@Gravlax can you update your Julia extension to the latest version and see whether you still see that error?
Well said. I can’t reproduce this issue in an updated plugin
yes, thanks. I did downgrade the LanguageServer just to see if it could solve the issue.
That’s what I get with the latest version:
I think the error here is a precompilation problem due Julia 1.9 pkgimages. The pkgimages cannot created due to
lld missing some depedency on an old macOS.
@Gravlax , does Julia 1.8 work fine?
@davidanthoff , is there is an easy way to pass
--pkgimages=no to the Julia instance running the LanguageServer?
yes, 1.8 (and previous ones) works like a charm.
No, we tightly control how that instances is started
I think the error here is a precompilation problem due Julia 1.9 pkgimages.
That would suggest that precompile should also not work outside of VS Code, right?
Right, in my case, yes.