I just made the following discovery:
It looks like there is about 1GB from julialang in the .config folder, including a .so file. That does not feel right (I am cloud-syncing my .config). Anyone else who sees this as problematic?
1 Like
That’s just your Julia installation? It looks like you’re using juliaup and that’s where it installed Julia 1.8.3.
It is inside de Code directory in .config. It seems to be from VS Code’s julia extension.
Does the julia extension installs its own julia?
Maybe only when it doesn’t find any julia binary?
1 Like
Inside your config there is a full Julia 1.8.3 install. That sys.so is the system image.
How did you install Julia?
Had a look and seems I also had a julia installation there, though an older one that I don’t use.
Pretty sure I haven’t manually installed anything there, though I have played around with different installations on the computer so could be I have been without a functioning one at some point and the extension installed it then?
Freed up some space at least.
Just juliaup from the command line. I am on 1.9 rc2 currently. I also have the stable release installed, but I am pretty sure that they are located inside the .julia folder.
It came back…
Deleted everything in ~/.config/Code/User/globalStorage/julialang.language-julia since it either seemed like it should not be there (lsdepot containing juliaup/julia-1.7.3xxx as well as a bunch of compiled code and some Manifest logs) or like it could be regenerated (symbolstorevX which seems to be different versions of cached symbol data for a bunch of packages).
Opening a new vscode window on a julia project, I notice that symbolserverv5 showed up again, reasonable, though the lsdepot folder also reappeared, now with juliaup/julia-1.8.5xxx installed…
Does the plugin automatically install a julia version for the language server? Why does it need that, and why does it keep separately compiled code in there?
Or have I just messed up some setting? I have told julia-vscode the executable path for the julia I have through juliaup, and works nicely with the REPL (opens the version I have through juliaup, not the version in lsdepot).
Also, why is this stored in the .config folder as OP stated? Does not seem like config, more like cache. But maybe this is controlled by vscode, seems like there is no Code folder in the .cache directory…
Edit:
Had a look at the running processes, and from a clean slate with no julia processes running I open a julia file in vscode and two julia processes spawn.
The first one (lower pid) is using my default julia installation at ~/.juliaup/bin/julia
~/.juliaup/bin/julia --startup-file=no --history-file=no --depwarn=no main.jl [workdir] --debug=no /tmp/vsc-jl-cr-78558247-bcfc-41c7-bbfe-d3788b36abb3 ~/.config/Code/User/globalStorage/julialang.language-julia download https://www.julia-vscode.org/symbolcache --detached=no
and the second one is identical except for using the julia executable from lsdepot
~/.config/Code/User/globalStorage/julialang.language-julia/lsdepot/v1/juliaup/julia-1.8.5+0.x64.linux.gnu/bin/julia --startup-file=no --history-file=no --depwarn=no main.jl [workdir] --debug=no /tmp/vsc-jl-cr-78558247-bcfc-41c7-bbfe-d3788b36abb3 ~/.config/Code/User/globalStorage/julialang.language-julia download https://www.julia-vscode.org/symbolcache --detached=no
I realise that I’m using 1.9 as my default julia, and that I’m running the pre-release version of julia-vscode, could it be related to that? That if the default julia is to new it downloads a compatible version or something?
I also have 1.8 installed in my default juliaup, so feels like it could be nice if I was able to tell vscode where to find that and avoid having duplicate installations, though couldn’t find any setting for this.
Edit2:
Found Do julia-vscode install a separate julia? · Issue #3264 · julia-vscode/julia-vscode · GitHub
Before I had set ~/.juliaup/bin/julia as the executable in the julia-vscode setting, but removing that made everything work like normal…
1 Like