In the REPL, I added https://github.com/SciML/SciMLTutorials.jl. Next, I started conda and in the conda base started the jupyter server.
According to the docs for SciMLTutorials.jl, one is supposed to open the provided notebooks in jupyter by using the commands:
using IJulia, SciMLTutorials
SciMLTutorials.open_notebooks()
But this causes error:
ERROR: jupyter not found is not installed, cannot run notebook
Stacktrace:
[1] error(s::String)
@ Base ./error.jl:33
[2] find_jupyter_subcommand(subcommand::String)
@ IJulia ~/.julia/packages/IJulia/e8kqU/src/jupyter.jl:25
[3] notebook(; dir::String, detached::Bool)
@ IJulia ~/.julia/packages/IJulia/e8kqU/src/jupyter.jl:96
[4] open_notebooks()
@ SciMLTutorials ~/.julia/packages/SciMLTutorials/lVdkw/src/SciMLTutorials.jl:128
[5] top-level scope
@ REPL[22]:1
(Yes, I do have IJulia installed.)
What is wrong?
The trouble does not seem to be with jupyter per se, because once the jupyter server is started and I open, say, a Sage notebook in the browser, I can connect that to the sage kerneo.
Open an issue. Though, we’ve basically been moving away from Jupyter notebooks towards things that promote reproducibility.
Moving away from Jupyter notebooks?? Most unfortunate and, unless there’s some equally good or better front-end substitute, a potential death-threat to Julia!
A proliferation of front-ends, unless one that’s clearly superior to Jupyter, would be disconcerting. Already one can use Jupyter notebooks with the Wolfram Language, Python, and Sage.
The beauty of Jupyter notebooks — and similar front-ends such as that for Mathematica — is the way one can mix text cells, input cells, output cells, and graphics all within a single document.
Such front-ends are extremely useful, e.g., for applications in teaching, at least at the college level.
Jupyter for tutorials is just impossible to maintain since the file format is not made to be maintained, and the result of Jupyter notebooks isn’t made to be correct. Weave is a much saner format for generating websites. You can always automatically translate Weave to Jupyter though, which is all that it was doing before.
I’m not sure about SciML but https://github.com/fonsp/Pluto.jl goes a long way into fixing Jupyter’s issues.
1 Like
Pluto definitely could’ve been used, though it didn’t exist when we setup the repo. Weave.jl is a fairly good standard though for generating websites (though I do like Pluto’s HTML output). As Jupyter is a WYSIWYG on a JSON file, building bots to automatically update websites built on Jupyter notebooks is very similar to building bots to automatically Microsoft Word - based websites. We did it for years, but it’s prone to so many bugs. What we should instead do is just give people a function so that Weave converts some .jmds to notebooks when they ask (if you use Weave.jl, you can already do this by doing cd(@__DIR__) into the package and then call https://github.com/SciML/SciMLBenchmarks.jl/blob/master/src/SciMLBenchmarks.jl#L51). We can probably change https://github.com/SciML/SciMLBenchmarks.jl/blob/master/src/SciMLBenchmarks.jl#L123-L127 so that way it calls the conversion before trying to open the notebooks, now that the outputs have moved to a separate repo (https://github.com/SciML/SciMLBenchmarksOutput)
Note that I was not looking for a website generator but simply a good notebook interface to Julia, where on the local machine one can create and open documents that mix text exposition, code input, and output including graphical output. In other words, something like the Mathematica front-end (which, in my experience, is absolutely state-of-the-art).
Yes, but the SciMLTutorials are a website generator.
I think with https://github.com/fonsp/Pluto.jl/pull/1032 (cell dependency determination supporting macros) Pluto should be able to support most of the SciML functionality.
Packages using GPU or Multiprocessing may require starting Pluto in single processing mode (Pluto.run(workspace_use_distributed=false)).