Julia busy all the time

[barche]

Ever since upgrading to 0.7, Julia is indicated as busy forever after trying to get completion or hovering over e.g. a function. Function help or completions also never appear. It seems to work on the first few functions sometimes, but then it gets stuck with no errors in the language server log. Is there some cache or something I can reset? I've been going through quite a few versions of the vscode plugin.

[davidanthoff]

I'm not sure, at least I have not tested with julia 0.7 at all and I think we'll probably wait quite a bit longer before we start to work on 0.7 compat work.

[barche]

Aah, sorry, I meant julia-vscode 0.7, not Julia 0.7, I'm on Julia 0.6.

[davidanthoff]

Ah, ha, sorry :)

Here is one vague theory: we actually load all the packages that are used in any project into the LS process. That process is not reusing the precompile cash of the user, instead it has its own precompile cash. So everything gets newly precompiled, and during that time there is no output. I could imagine that this is happening, i.e. you might still be stuck on the initial pre-compile pass. One way to detect this is to look into the .vscode\extensions\julialang.language-julia-0.7.0\scripts\languageserver\julia_pkgdir\lib\v0.6 folder and see whether new ji files are added while you are waiting for completions.

The solution to this is not simple but very much on the roadmap for v0.8.0: we want the LS process to never load user code, but instead spawn new julia processes that do that, don't block anything and reuse the normal user pre-compile cache.

But, of course there might also be something else going on :)

[barche]

Thanks, deleting those .ji files got things working again when I was editing CxxWrap, but when I loaded another package that uses CxxWrap (Trilinos.jl in this case, unreleased but on my Github) it got stuck again. Is there a way to get the output of this loading process? I must admit I'm mostly editing packages that are not purely Julia, so maybe loading the used packages causes side effects or problems finding a library or something.

[davidanthoff]

If you edit CxxWrap, it will actually not try to load that into the LS process, instead it will statically analyze that. In general, it will only load those packages into the LS process that are loaded by the code in the current working folder. I don't think there is any way to get any output about that...

For me it mostly worked to just have on VS Code instance started and wait until it had everything precompiled... I'm not sure what happens if you have e.g. multiple VS Code instances running at the same time and they are all trying to pre-compile the same things.

I know, that is really not very helpful, but I can't think of any better strategy, short of just fixing this whole situation as outlined above. But that will be v0.8.0, I'm afraid...

[barche]

OK, it seems CxxWrap is at least one of the culprits, but this time disabling the loading of the dynamic library in the init function doesn't seem to help. Anyway, thanks for the very quick response, I'll see if I can find a workaround and I'm looking forward to the next version.

[tkoolen]

I'm experiencing this as well. I removed the .ji files in ~/.vscode/extensions/julialang.language-julia-0.7.0/scripts/languageserver/julia_pkgdir/lib/v0.6 and monitored the contents of the directory after starting VS code again and hovering over something in RigidBodyDynamics. After a while, no additional .ji files are created, and the contents are:

CSTParser.ji		DocStringExtensions.ji	LightXML.ji		Rotations.ji		Tokenize.ji
Compat.ji		JSON.ji			RigidBodyDynamics.ji	StaticArrays.ji		URIParser.ji

CPU usage for the julia process drops to near zero, but the "Julia: busy" message remains in VS code, and when I hover over anything in my code, it still results in a "Loading..." tooltip.

[mauro3]

Yep, same here: it seems to work for a bit (documentation and auto-completion) but then after a while it stops. If I "Reload Window" it works again for a while and then stops again.

[mauro3]

Here the output from the "OUTPUT" console with debug output turned on in main.jl:

INFO: 
INFO: SENT: {"method":"window/setStatusReady","jsonrpc":"2.0"}

##->  now I move cursor onto `deepcopy`

INFO: 
INFO: RECEIVED: {"jsonrpc":"2.0","id":2052,"method":"textDocument/hover","params":{"textDocument":{"uri":"file:/....jl"},"position":{"line":315,"character":26}}}
INFO: 
INFO: SENT: {"method":"window/setStatusBusy","jsonrpc":"2.0"}
INFO: 
INFO: SENT: {"id":2052,"jsonrpc":"2.0","result":{"contents":["```\ndeepcopy(x)\n```\n\nCreate a deep copy of `x`: everything is copied recursively, resulting in a fully independent object. For example, deep-copying an array produces a new array whose elements are deep copies of the original elements. Calling `deepcopy` on an object should generally have the same effect as serializing and then deserializing it.\n\nAs a special case, functions can only be actually deep-copied if they are anonymous, otherwise they are just copied. The difference is only relevant in the case of closures, i.e. functions which may contain hidden internal references.\n\nWhile it isn't normally necessary, user-defined types can override the default `deepcopy` behavior by defining a specialized version of the function `deepcopy_internal(x::T, dict::ObjectIdDict)` (which shouldn't otherwise be used), where `T` is the type to be specialized for, and `dict` keeps track of objects copied so far within the recursion. Within the definition, `deepcopy_internal` should be used in place of `deepcopy`, and the `dict` variable should be updated as appropriate before returning.\n"]}}
INFO: 
INFO: SENT: {"method":"window/setStatusReady","jsonrpc":"2.0"}
INFO: 
INFO: RECEIVED: {"jsonrpc":"2.0","method":"$/cancelRequest","params":{"id":2052}}
INFO: 
INFO: SENT: {"method":"window/setStatusBusy","jsonrpc":"2.0"}
INFO: 
INFO: SENT: {"method":"window/setStatusReady","jsonrpc":"2.0"}
INFO: 

As reported above: during all this time the status bar shows :Julia: busy" and the help text never shows but just "Loading..."

Also during typing, there is a lot of activity in the "OUTPUT" console, but no auto-completions show up. So it seems like the language server is running but somehow its output doesn't make it into the editor.

[ZacLN]

Eek, this is pretty bad this is somehow connected to the asyncrhonous loading of packages. I'll push the WIP for v0.8 that fixes this

[mauro3]

Mind linking that WIP?

[ZacLN]

julia-vscode/LanguageServer.jl#168 and you'll need to:

• get the master version of CSTParser in `(julia-vscode)/scripts/languageserver/packages
• Pull https://github.com/ZacLN/DocumentFormat.jl into the above dir.

[mauro3]

Thanks! BTW, it would be good to document somewhere how all those packages play together. Otherwise it's hard to find things and file issues in the right place.

[ZacLN]

No problem, I'll be adding things to that PR today to get it up to date with where we were.

I'm just in the process of splitting things out into different packages at the moment but we're happy with all issues to be reported here

[tkoolen]

Thank you!

[mauro3]

Without having it tested thoroughly, it seems having this extension https://github.com/bartosz-antosik/vscode-spellright enabled for Julia files makes the busy-problem appear much quicker.

[davidanthoff]

Hm, that is very strange, I would have thought that these extensions can't even mess with each other...

[ZacLN]

This should be sorted now, in the main. I'll leave it open so that people can report back on whether the new release fixed it

[mauro3]

Are there instructions somewhere on how to try this before there is a release?

[ZacLN]

Download https://github.com/JuliaEditorSupport/julia-vscode/releases/download/v0.8.0-beta.1/language-julia-0.8.0-beta.1.vsix and use the 'Extensions: Install from VSIX'. I'm going to post an announcement w/ further details onto Discourse tonight

[poroale]

I installed the 0.8.0-beta.1.vsix to VSCode (1.16.1) and I'm afraid I'm still having similar issues with Julia being busy all the time.

[KristofferC]

I haven't had the busy problem with 0.8-beta.

[poroale]

I reinstalled VSCode + 0.8-beta and now I don't seem to have the busy problem either, at least during 20 minutes of testing.

[mauro3]

Off-topic: With the 0.8-beta, the "Julia starting up" does not disappear even when Julia has started up and things like tool-tips work.

On-topic: not sure about the "busy" bug yet.

[tkoolen]

I'm experiencing the same issue as @mauro3 regarding "Julia starting up". But ctrl+click navigation and tooltips work fine now.

[ZacLN]

the incorrect 'starting up' message is fixed here

[barche]

Appears to work here, I'll keep testing the beta(s).

[barche]

Testing the 0.8 beta 1 on Linux gave me this error:

ERROR: LoadError: type UnarySyntaxOpCall has no field val
Stacktrace:
 [1] _anon_func_scope(::CSTParser.BinarySyntaxOpCall, ::LanguageServer.TopLevelScope, ::LanguageServer.LanguageServerInstance, ::Set{String}) at /home/username/.vscode/extensions/julialang.language-julia-0.8.0-beta.1/scripts/languageserver/packages/LanguageServer/src/trav/local.jl:192
 [2] lint(::CSTParser.BinarySyntaxOpCall, ::LanguageServer.TopLevelScope, ::LanguageServer.LintState, ::LanguageServer.LanguageServerInstance, ::Bool) at /home/username/.vscode/extensions/julialang.language-julia-0.8.0-beta.1/scripts/languageserver/packages/LanguageServer/src/trav/lint.jl:160
 [3] lint(::CSTParser.EXPR{CSTParser.InvisBrackets}, ::LanguageServer.TopLevelScope, ::LanguageServer.LintState, ::LanguageServer.LanguageServerInstance, ::Bool) at /home/username/.vscode/extensions/julialang.language-julia-0.8.0-beta.1/scripts/languageserver/packages/LanguageServer/src/trav/lint.jl:112
 [4] lint(::CSTParser.EXPR{CSTParser.Kw}, ::LanguageServer.TopLevelScope, ::LanguageServer.LintState, ::LanguageServer.LanguageServerInstance, ::Bool) at /home/username/.vscode/extensions/julialang.language-julia-0.8.0-beta.1/scripts/languageserver/packages/LanguageServer/src/trav/lint.jl:377
 [5] lint(::CSTParser.EXPR{CSTParser.Call}, ::LanguageServer.TopLevelScope, ::LanguageServer.LintState, ::LanguageServer.LanguageServerInstance, ::Bool) at /home/username/.vscode/extensions/julialang.language-julia-0.8.0-beta.1/scripts/languageserver/packages/LanguageServer/src/trav/lint.jl:112
 [6] lint(::CSTParser.EXPR{CSTParser.Call}, ::LanguageServer.TopLevelScope, ::LanguageServer.LintState, ::LanguageServer.LanguageServerInstance, ::Bool) at /home/username/.vscode/extensions/julialang.language-julia-0.8.0-beta.1/scripts/languageserver/packages/LanguageServer/src/trav/lint.jl:283
 [7] lint(::CSTParser.EXPR{CSTParser.FunctionDef}, ::LanguageServer.TopLevelScope, ::LanguageServer.LintState, ::LanguageServer.LanguageServerInstance, ::Bool) at /home/username/.vscode/extensions/julialang.language-julia-0.8.0-beta.1/scripts/languageserver/packages/LanguageServer/src/trav/lint.jl:112
 [8] lint(::CSTParser.EXPR{CSTParser.FunctionDef}, ::LanguageServer.TopLevelScope, ::LanguageServer.LintState, ::LanguageServer.LanguageServerInstance, ::Bool) at /home/username/.vscode/extensions/julialang.language-julia-0.8.0-beta.1/scripts/languageserver/packages/LanguageServer/src/trav/lint.jl:339
 [9] lint(::CSTParser.EXPR{CSTParser.Block}, ::LanguageServer.TopLevelScope, ::LanguageServer.LintState, ::LanguageServer.LanguageServerInstance, ::Bool) at /home/username/.vscode/extensions/julialang.language-julia-0.8.0-beta.1/scripts/languageserver/packages/LanguageServer/src/trav/lint.jl:112
 [10] lint(::CSTParser.EXPR{CSTParser.ModuleH}, ::LanguageServer.TopLevelScope, ::LanguageServer.LintState, ::LanguageServer.LanguageServerInstance, ::Bool) at /home/username/.vscode/extensions/julialang.language-julia-0.8.0-beta.1/scripts/languageserver/packages/LanguageServer/src/trav/lint.jl:288
 [11] lint(::CSTParser.EXPR{CSTParser.FileH}, ::LanguageServer.TopLevelScope, ::LanguageServer.LintState, ::LanguageServer.LanguageServerInstance, ::Bool) at /home/username/.vscode/extensions/julialang.language-julia-0.8.0-beta.1/scripts/languageserver/packages/LanguageServer/src/trav/lint.jl:112
 [12] lint(::LanguageServer.Document, ::LanguageServer.LanguageServerInstance) at /home/username/.vscode/extensions/julialang.language-julia-0.8.0-beta.1/scripts/languageserver/packages/LanguageServer/src/trav/lint.jl:47
 [13] process(::LanguageServer.JSONRPC.Request{Val{Symbol("workspace/didChangeConfiguration")},Dict{String,Any}}, ::LanguageServer.LanguageServerInstance) at /home/username/.vscode/extensions/julialang.language-julia-0.8.0-beta.1/scripts/languageserver/packages/LanguageServer/src/provider_misc.jl:203
 [14] run(::LanguageServer.LanguageServerInstance) at /home/username/.vscode/extensions/julialang.language-julia-0.8.0-beta.1/scripts/languageserver/packages/LanguageServer/src/languageserverinstance.jl:35
 [15] include_from_node1(::String) at ./loading.jl:569
 [16] include(::String) at ./sysimg.jl:14
 [17] process_options(::Base.JLOptions) at ./client.jl:305
 [18] _start() at ./client.jl:371
while loading /home/username/.vscode/extensions/julialang.language-julia-0.8.0-beta.1/scripts/languageserver/main.jl, in expression starting on line 27
[Info  - 9:44:23 AM] Connection to server got closed. Server will restart.
[Error - 9:44:23 AM] Request textDocument/codeAction failed.

[davidanthoff]

@barche That seems like an unrelated, new bug, right?

[ZacLN]

Yep, I'm pushing a fix but I can't work out in my head what sort of anonymous function declaration would cause this

[barche]

Yes, seeing this on my Mac too now, always when editing Luxor.jl or a package that depends on it. Want me to open a new issue?

[davidanthoff]

Yeah, lets track that in a new issue, that would be great!

[ssfrr]

I'm seeing this issue (Loading... tooltip and julia:busy in the lower toolbar) on version 0.8.0-beta.4. I don't see a lib folder with .ji files to delete, as mentioned as a solution above. Anything else I should check?

edit, more info: when I launch vscode I see things settle down to Julia: ready, but then as soon as I hover over an identifier and the Loading... tooltip pops up, after that it seems to be stuck in Julia: busy.

[ssfrr]

oh, hah, I still had the .vscode/extensions/julialang.language-julia-0.7.0 present, and perhaps it was loading things from there. I deleted that whole folder and it seems the issue has gone away.

[KristofferC]

Yep, that will make it load 0.7.

[shang-zd]

I also have this problem...
My Julia extension is v0.10.3
Julia version installed is v1.0.0
vs code version is v1.26.0

When I start vs code, everything seems fine. But I cannot start Julia terminal!!!
when I tried to start Julia terminal, this status occurred. Also, there are two errors:

1. Could not start the julia language server. Make sure the configuration setting julia.executablePath points to the julia binary.
   2.The terminal process terminated with exit code: 1

For the first error, I configured the julia binary path by adding
"julia.executablePath": "C:\Users\zd\AppData\Local\Julia-1.0.0\bin\julia.exe",
in both user setting and workspace setting... I am not sure whether this is the problem.

I am a newbie, please do not laugh at me if you found something stupid.
Thank you.

[shang-zd]

I may find the reason...
Julia v1.0.0 has not been supported by Julia extension...
This problem disappears in 0.6.4 version Julia...

[Tonysmark]

Why this happend