jupyter
jupyter copied to clipboard
Julia and Revise.jl make Kernel unresponsive
Hey there! Great work and its been a pleasure using it :)
When running a Julia kernel together with the Revise.jl package the kernel gets unresponsive upon the first hook from revise.
Revise detects changes in functions from a module and injects them into the running Julia session.
To use Revise.jl I added two startup files with the following content:
~/.julia/config/startup.jl
atreplinit() do repl
try
@eval using Pkg
haskey(Pkg.installed(), "Revise") || @eval Pkg.add("Revise")
catch
end
try
@eval using Revise
@async Revise.wait_steal_repl_backend()
catch
end
end
and
~/.julia/config/startup_ijulia.jl
try
@eval using Revise
catch
end
With this setup, running julia or jupyter console --kernel julia-1.3 results in correctly reloading Julia sessions.
To test the setup, I generated a new package from the Julia package REPL.
using Pkg
Pkg.generate("TestPackage")
This generates a directory TestPackage which contains a simple TestPackage.jl file.
We start a session in the directory and evaluate the following snippet:
using Pkg
Pkg.activate(".")
using TestPackage
TestPackage.greet()
We can then go and add a function to the TestPackage.jl file.
function f()
π
end
And Revise.jl will inject that code into the running session, and we can use it.
TestPackage.f()
Using the kernel from emacs-jupyter results in a busy kernel as soon as we save the source file.
Any ideas why that might happen?
emacs-jupyter 20191019.1519
julia version 1.3.0
jupyter core : 4.6.1
jupyter-notebook : 6.0.1
qtconsole : 4.3.1
ipython : 7.9.0
ipykernel : 5.1.3
jupyter client : 5.3.4
jupyter lab : not installed
nbconvert : 5.6.1
ipywidgets : 7.4.0
nbformat : 4.4.0
traitlets : 4.3.3
Cheers
A current workaround is starting a kernel outside of emacs and connecting to it via:
jupyter-connect-repl
I think the problem is somehow related to loading Revise.jl in your startup_ijulia.jl file.
I can using Revise without a problem in a source block (and then use the functionality of it in the following executed blocks).
Great work and its been a pleasure using it :)
Thanks, and sorry for the late reply.
Any ideas why that might happen?
I'm not sure, but I will use your test case to see if I can find out why. In the meantime, you may be able to find out something if you evaluate (setq jupyter--debug t) and try again. You should see the flow of messages between Emacs and the kernel in the *Messages* buffer.