General Projects – Summer of Code

Enhanced clipboard

Julia’s functions for getting and setting the clipboard are currently limited to text; it would be useful to extend them to allow the transfer of other data (for example, spreadsheet data or images).

Expected Results: Extensible clipboard() and clipboard(x) functions to get and set the richest possible representation of the system clipboard data, as well as methods for specific types.

Recommended skills: Interfacing with C from Julia, clipboard APIs for different platforms. Familiarity with FileIO.jl.

Mentors: Stefan Karpinski

Calling Julia from Python

Julia could be a great replacement for C in Python projects, where it can be used to speed up bottlenecks without sacrificing ease of use. However, while the basic functionality for communicating with Julia exists in PyCall.jl and pyjulia, it needs to be separated out and maintained as a real Python package.

Expected Results: An easy-to-use Python package which allows Julia functions to be imported and called, with transparent conversion of data.

Recommended skills: Familiarity with both Python and Julia, especially C interop.

Mentors: Steven Johnson

Middlewares for common web application chores in Mux.jl

Implementation of mid-level features - specifically routing, load-balancing, cookie/session handling, and authentication - in Mux.jl. The implementation should be extensible enough to allow easy interfacing with different kinds of caching, databases or authentication backends. (See Clojure/Ring for inspiration).

Expected Results: Improvements to the Mux.jl package.

Required Skills: Experience with web development.

Recommended Skills: Knowledge of various web frameworks, especially the design decisions and tradeoffs behind them.

Mentors: Mike Innes

QML.jl Improvements

The QML.jl package provides Julia bindings for Qt QML on Windows, OS X and Linux. In the current state, basic functionality is available, but there is room for improvement regarding integration with GLVisualize and plotting packages such as GR (see also issue 23) or Plots. Another area of work is supporting more elaborate data models.

Expected Results: Improvements to the QML.jl package along one of these lines.

Recommended Skills: Familiarity with both Julia and the QT framework.

Mentors: Bart Janssens

Data Structure Algorithm Improvements

While many common data structures are encouraged to be implemented in packages, to encourage more experimentation, some are so basic they need to be in Base. There are a number of projects that could be done to improve the quality, performance, or usability of these builtin structures. Some ideas include:

Recommended Skills: Ability to write type-stable Julia code. Ability to find performance issues. Knowledge about data structures and related algorithms.

Mentors: Jameson Nash

Expanding the reach of Interact.jl with WebIO.jl

Interact.jl, host of the popular @manipulate macro, is a package for interacting with Julia code using UI widgets. It currently has a couple of serious limitations:

  1. It only works inside IJulia.
  2. A third-party package cannot build interactive features for it (See #38 for example).

WebIO.jl is a new package for interactive HTML output in varied web-based front-ends to Julia, namely Jupyter/IJulia, the Juno IDE, Mux, and Blink. The idea is that these front-ends will support WebIO’s display and communication API, while graphics packages like Plotls.jl or Interact.jl can build on a common counterpart display and communication API to create UIs. This means that graphics package authors need to write a widget once and it will work on all these front-ends. It also means that widgets from different packages based on WebIO.jl can be composed seamlessly.

This project involves rewriting Interact.jl using WebIO.jl to make it available on more front-ends than just IJulia.

It is a great opportunity to rethink what a package for manipulating interactive output could do. For example: can one interactively play with output from a package like Compose.jl using @manipulate or a similar construct (e.g. move a circle or draw a rectangle)? What would Compose.jl minimally have to do to support such interactions? How can Interact.jl help? Another scenario: can PlotlyJS use Interact.jl/WebIO.jl to support drill down charts so that data can be loaded lazily from Julia as and when the user requests it? Can the state of the spreadsheet from DataFrames.jl be synced with a PlotlyJS plot?…

While these are all interesting questions to consider, the scope of this package is only to provide basic widgets (such as those in Interact.jl) and re-implement the @manipulate macro on top of them.

Expected Results: A package with basic UI widgets built on top of WebIO.jl, @manipulate macro with at least the same features as it does now.

Recommended Skills: writing generic Julia code and modular JavaScript code, writing asynchronous programs in Julia. Good aesthetic sense with UIs is a bonus!

Mentors: Shashi Gowda

WebAssembly

WebAssembly is a new standard for running compiled code in a web browser. If Julia can generate WebAssembly, it opens up many opportunities to embed Julia “apps” in web interfaces. Julia is well positioned here because Julia can already compile efficient LLVM bitcode. LLVM bitcode can be translated into WebAssembly by Emscripten or with a direct LLVM backend.

The two most promising approaches to generate WebAssembly are outlined as follows.

  1. Extended CUDAnative approach – The experimental ExportWebAssembly package uses code from the CUDAnative package to produce LLVM bitcode on the fly. It works great for simple code (type stable code with no use of libjulia or other C functions). Math code that uses immutable structs and/or StaticArrays works well with this approach. The main downside is that it is so limited–-no arrays, no strings, no IO, etc. The main work with this approach is to substitute out libjulia-type functions with equivalents that work in JavaScript/WebAssembly. For example, this crude example shows a custom array type that could work with WebAssembly. The main steps in this approach are: (1) write a package to create WebAssembly-friendly versions of basic Julia types and operations (Dicts, Strings, Arrays, and printing) and (2) use the Cassette package or another approach to replace standard Julia dispatches involving these basic types with the WebAssembly-friendly versions.

  2. CodeGen.jl approach – This package uses the LLVM package to directly generate bitcode based on code_typed Julia code. There is a branch of ExportWebAssembly that uses this. This can use libjulia functions (also compiled to LLVM bitcode), so a wider range of Julia code may work. Some decently complex code runs, including some simple array creation and manipulation. But, there are still many gaps that need to be filled in here to be able to run Julia code in general. The main work with this approach is in upgrading the CodeGen package to support more Julia code. This method offers the most control over code generation and may allow the widest Julia code coverage (including code that links to C and Fortran libraries).

Expected Results: An upgraded version of the ExportWebAssembly package that supports a wider range of Julia code.

Recommended skills: Familiarity with (or willingness to learn) LLVM IR helps when interpreting Julia output before it is converted to WebAssembly; for the CodeGen approach, familiarity with C++ helps to interpret the C++ code in Julia that does code generation

Mentors: Tom Short

Donate Now