make it possible to actually use the Julia jupyter kernel in CoCalc to draw a plot.

[williamstein]

I tried everything I could from Plotting in Julia and as far as I can tell everything is broken in CoCalc. Instead, everything (or at least something) should actually work, and there should be a nice tested Jupyter notebook and Sage worksheet illustrating this.

[DrXyzzy]

Some simple plots work, but

• the first run can take several minutes
• some messages appear with raw ANSI control codes (see ansi codes in warnings not correctly rendered in modern Jupyter with Julia kernel #2889)

Here's a sample of CoCalc Jupyter notebook with Julia kernel. Note execution time at upper right of nearly 6 minutes.

[haraldschilly]

I can only add that in the past when setting this up, I really tried to understand what's going on ... but my conclusion was that this is either "by design" or not really supported. What we have right now is the default setup. There is definitely a lot of one-time overhead as you can see in the output messages, because julia starts to setup it's own local repository. AFAIK this is sort of the intended way, especially when we want users to allow to install their own julia packages (without having to fiddle around with paths, etc.). I can only hope they figure out a better way for future releases, and also explain these settings and the setup process better for us administrators.

If you really want to dive into this, there is a compile flag for julia we can set. I.e. compare these two scenarios:

$ rm -rf ~/.julia   # to clear this local repo if it is there
$ julia
> using Combinatorics     # look what happens upon import
> bellnum(100)
475853912767648336     # result

and on the other hand, without that cache again but telling it to use the globally precompiled ones:

$ rm -rf ~/.julia   # to clear this local repo again
$ julia --precompiled=yes
> using Combinatorics   # look what happens upon import
> bellnum(100)
475853912767648336     # result

Plotting amplifies this because a whole set of package dependencies are precompiled.

Maybe it is ok to add --precompiled=yes to the julia kernel definition. I don't know. It's not there by default... There is also --compilecache=no which disables this local cache completely. But I guess this is not a good idea.

[williamstein]

I propose that somebody try the plotting, etc., with juliabox and report back here what happens.

[williamstein]

One other remark, is that with our k8s switch, we at least have the option of making it appear as if the local user has already pre-compiled a lot "locally" -- we can mount anything anywhere, in theory.

[DrXyzzy]

The short plot took about 35 seconds on juliabox (with v0.6.0 kernel) the first time and a fraction of a second after that.

[haraldschilly]

small update here: this was broken again, and this time it's caused by an upstream bug here JuliaPy/PyPlot.jl#151

The stub for the example document is here: https://github.com/sagemathinc/cocalc-example-files/blob/master/julia/julia-first-steps.ipynb

[DrXyzzy]

Note also that in JuliaBox, the example plot is displayed inline as soon as it is available. In CoCalc Julia Jupyter, a button appears saying 'Fetch additional output'. Clicking that button displays the plot, but the plot appears in a pane that is shorter than the entire plot and must be scrolled vertically to see it all; you have to click in the left part of gutter (gutter turns gray) to show the entire plot.

Also if you run the compute cell to create a plot, then click in the text part of the cell after 'Fetch additional output' appears, clicking on the fetch button has no effect. (Chrome on macOS).

[williamstein]

Note also that [...]

Note that this is as intended, sort of:

(1) Fetch additional output happens if the output is very large and not available as an image properly (so gets served directly by backend over separate HTTP request).

(2) Output is not fully expanded since it's expected to be large.

-- William

[williamstein]

That said... it would be nice if Julia generated more normal image display tags, so the image can be served properly!... or we improve our heuristics for removing images and serving them from the backend. Why, oh why, did Jupyter ever design things to not do this (i.e., only serve images separately). It's is so annoying.

[DrXyzzy]

Agreed. Better metadata and state transition docs in the Jupyter message protocol would have eliminated a lot of guessing by the front end and gratuitous variations in the kernels.