GSoC 2018 Summary

The aims of this year’s GSoC project were to a) get the Juno IDE running on Julia v1.0 and b) integrate performance linting into the Juno UI.

Most of the work went into updating the various Julia packages in the Juno stack, first for Julia 0.7 and then for Julia 1.0. There’s also a unfinished PR against @MikeInnes’ excellent package Traceur.jl, which provides performance linting in Julia.

Finding a nice user experience for getting performance tips in Juno was mostly a matter of updating the Atom packages Juno uses.

Juno on Julia v1.0

Updating Juno for Julia 1.0 actually took more time than I would have liked. Then again, Julia itself changed radically between 0.6 and 1.0, so I guess that was to be expected. Most of the progress was tracked in this meta-issue (thanks again to everyone who tried Juno with Julia 0.7 in that phase!), which culminated in PRs against basically every single package in the Juno stack.

Atom.jl

Atom.jl was not only updated to work on Julia 0.7, but also implements quite a few new features (see an earlier blog post for more information on that).

Juno is now fully compatible with the TreeViews.jl API, which means that package authors don’t have to depend on Juno.jl anymore to get custom pretty printing for their own types:

Juno’s Plot Pane is now fully integrated into Base’s display system. It is now sufficient to add the proper show method for a custom type and it will be properly displayed in Juno. Again, this cuts down the number of packages that need to depend on Juno.jl (or even Atom.jl) drastically.

Progress Bars now make use of the new logging infrastructure introduced in Julia 0.7, which means that there is hopefully no external package left that needs to depend on the Juno stack.

Juno.jl is now mostly a thin wrapper and as such was only updated to provide compatibility with the new version of Atom.jl. CodeTools.jl had to be updated to handle the new package loading properly. Hiccup.jl, Media.jl, and LNR.jl were also updated for Julia 1.0, but that mostly consisted of fixing deprecation warnings.

Performance Linting

Most of the UI work in regards to performance linting happened in a merged PR to ink and consists of a list of warnings (bottom of the screen), an inline popup which provides more information, and a new pane element for the results of @code_warntype etc:

There’s also an (as of yet unmerged) branch in julia-client and Atom.jl to enable this functionality and handle the communication with Traceur.jl, which provides the all the logic necessary for inspecting the IR and generating warnings when suspicious patterns are found (like type instabilities, use of global variables and many more).

Unfortunately Traceur.jl depends on ASTInterpreter2.jl and Vinyl.jl, both of which don’t work on Julia 1.0 yet. For that reason I have spent the last week of my GSoC project with transitioning Traceur.jl to use @jrevels awesome Cassette.jl, which was released during JuliaCon. The relevant PR is not merged yet, but that’ll hopefully be done soon. At that point we will be able to tag a new Juno release with performance linting enabled.

Various Improvements

While working on updating Juno to Julia 1.0 I also stumbled upon a few other areas to work on:

Redesign of junolab.org to better advertise the many of the features Juno provides but no one knows about.
Plot Pane UX is now much better with regards to multiple plots.
Juno’s Workspace now allows easy filtering of names in the workspace.
TreeViews.jl provides a mininmal API for defining a tree-like display for arbitrary types.
REPLTreeViews.jl (not registered yet) enables interactive rendering of those tree views in the REPL.
New autocompletion provider (WIP), which is much more powerful than what we have so far.

Upcoming Work

Of course this isn’t the end of my involvement with Juno, and we already have a few plans for the future.

During JuliaCon I was talking to David Anthoff, one of the two guys behind the Julia integration into VSCode, and we came up with a few ideas on how to share more code between the two backends (and come closer to feature parity). This will require a complete redesign of Juno’s internals, but in the end we’ll get quite a few features for free. I’ll write up my thoughts on this in a future post.

Another big thing a few people (like Mike Innes and Chris Rackauckas) have bugged me about is better support for remote work via ssh. This might need to be done in conjunction with the redesign mentioned above, but I’m not totally sure what the best way forward is here.

Continuing the TreeViews.jl work from during the summer I want to finish the REPLTreeViews.jl renderer (which definitely has a few big bugs right now) and implement a Jupyter renderer.

In my last blog post I mentioned a few improvements to Julia’s REPL that would be very good to have and would benefit everyone, not just Juno users. That’s still something I want to spend some time on, but is also a bit tedious due to the underdocumented (and definitely not self explanatory) REPL design.

Tim Holy’s Revise.jl works great on it’s own, but can also be used as a library which might make Juno’s current core functionality more robust and also enable things like method deletion which Juno can’t really handle right now (except for re-evaluating the whole module).

Acknowledgements