Google Summer of Code 2014

[Mike Innes]

Hey all,

I was wondering if you were planning on applying to GSoC this year - if not, it's a great opportunity to make some real progress on the non-core parts of the Julia ecosystem, and you'll have at least one enthusiastic student (me, that is).

I saw that Julia was rejected in 2012; it's worth noting that alongside Julia's increased impact as a project since then, Google are accepting an extra ten organisations this year - so I think we have a pretty good shot.

I've put some more-or-less thought out project ideas here:

https://docs.google.com/document/d/1G2Lm0dBsdu28PuD8vxR9AUFNRGPcU0QY5xtVHvfXQMA/edit#heading=h.ltd5a05at1xp

My experience with both Clojure and Julia puts me in a great position to work on the Light Table integration idea - and it's something I'm really excited to work on. I'm not averse to helping out with something more core, but given that I'm not as experienced with C or Julia's internals someone else may be a better fit for that kind of project.

One caveat for me: I must have strange term dates, because I'm only free for about half of the official 3 month working period. I can more than make up for lost time by working after the main programme has ended or even before it starts, so it would be a shame to let this get in the way; but I appreciate that it may not be possible to organise the flexibility I need. (Although since this problem must affect all UK students, I'd be surprised if there isn't standard approach to it)

Anyway, thanks for your consideration -

Mike

[Tom Short]

I can't speak to GSoC participation, but I like your list of ideas.
Here are comments on a couple of them:

* AOT Compiler

Handling duck-typed functions should be pretty easy. If you're making
a self-contained main(), Julia will compile all the needed code when
you run it. There are cases that may call different branches depending
on different inputs, but for many cases, it'll work fine. If you want
to implement a callable library, you could write a list of method
signatures to compile.

* JuliaJS

For this to work, you also basically need the static compiler. I've
played around with Emscripten a bit for this. I don't have anything to
show for it, but here are my experiences:

- The LLVM code in usr/lib/julia/sys.bc is suitable for linking with Emscripten.
- I managed to compile most of openlibm with Emscripten, getting
roughly 50% of the tests to pass. There were some conflicts with
Emscripten's built-in libm subset.
- With most of the libuv stuff bypassed, most of the Julia C code
compiled, including flisp. I didn't get far enough to make anything
run, though.
- When something does compile, asm.js is surprisingly fast.

[Jiahao Chen]

Symbolic algebra is a feature that has emerged in several different contexts. The JuliaStats and JuliaOpt communities use symbolic expressions as algebraic inputs for statistical and optimization models respectively. Calculus.jl provides symbolic differentiation. I've toyed also with a rudimentary interpreter for symbolic matrix-valued expressions to work out (symbolically) expectations over random matrices.

Differential equation solvers are a major category of numerical algorithms we want to improve upon; some sort of symbolic algebraic interface might be very useful for that.

[Jiahao Chen]

I should also mention that the MIT group hosted an unofficial "Summer of Julia" last year, which by all accounts was very successful. We intend to hold it again this year.

[Mike Innes]

@Tom: You're absolutely right, it would be easy to produce executables with access to all of Julia's features by bundling the runtime with code and JITing. The only problem with this is that the runtime is a big overhead, so that ideally, you'd want to compile the code completely ahead of time and only bundle a GC. This would currently be impossible for code using e.g. Array{Any}, but if you could solve that you could AOT 99% of Julia code without needing a runtime. That's the idea I'm getting at in the proposal, although admittedly it could be clearer, and as I said it needs some attention from someone who knows a lot more about the compiler.

Thanks for the info about JS compilation; I think that, as above, you could potentially do it without compiling the entire runtime, but that said it's amazing that it's possible to get as far as you did.

@Jiahao: Perhaps, especially as Julia has a built-in way of dealing with expressions, it's best to let symbolic routines crop up organically where they're needed rather than having a central library for them.

Summer of Julia sounds great - I'll definitely participate if I can, but I can't find any info, does this mean it's an MIT-only event?

[Isaiah Norton]

- I managed to compile most of openlibm with Emscripten, getting
roughly 50% of the tests to pass. There were some conflicts with
Emscripten's built-in libm subset.

That is interesting: is there fallback C-only code in openlibm that is

is compilable to JavaScript?

(I assume Emscripten cannot compile inline assembly. if it can then

um, wow). 

[Tom Short]

As you suspect, Emscripten cannot handle the inline assembly. I think
that most of the openlibm functions are C only. Some of the test
failures were for code that did have assembly (Emscripten got the code
compiled, but it failed at runtime). The most common failure from use
of assembly is probably the use of `weak_reference` to make a link to
a function.

[Stefan Karpinski]

We should definitely apply for GsoC again this year. I was the one who filled out the application two years ago and I started to last year, but their application process is so awful and broken that I didn't end up completing it (there were a number of other pressing things going on at the same time).

[Jiahao Chen]

Summer of Julia sounds great - I'll definitely participate if I can, but I can't find any info, does this mean it's an MIT-only event?

It's not an official event by any means. We hosted a fair number of non-MIT people. The only limitations are logistical, primarily finding funding for travel and housing.

[Francesco Bonazzi]

On Sunday, January 12, 2014 8:54:53 PM UTC+1, Jiahao Chen wrote:

Symbolic algebra is a feature that has emerged in several different contexts. The JuliaStats and JuliaOpt communities use symbolic expressions as algebraic inputs for statistical and optimization models respectively. Calculus.jl provides symbolic differentiation. I've toyed also with a rudimentary interpreter for symbolic matrix-valued expressions to work out (symbolically) expectations over random matrices.

Differential equation solvers are a major category of numerical algorithms we want to improve upon; some sort of symbolic algebraic interface might be very useful for that.

Symbolic algebra can be a very difficult task to achieve. If you just mean to handle polynomials, tree-expressions and derivatives, that can be easily done. If you would like to create an equation solver, integrator, ODEs and PDEs solvers, well, that's a very long work.

May I suggest to either continue the work on SymPy integration through PyCall, or to have a look at SymPy itself. There has been a discussion on SymPy's mailing list about introducing a multiple dispatch into SymPy to better handle the way mathematical functions work on different types (e.g. the exponential function of a real number, matrix, differential operator, etc...).

There is also an experimental SymPy core written in C++, have a look at it, maybe it could be a good solution to rewrite it in Julia or to connect to it at the ABI level: https://github.com/certik/csympy

Wolfram Mathematica manages symbolic algebra through pattern matching on expressions combined with a SAT solver. If you find a way to do it efficiently, I'd suggest to do it before starting the work on symbolic integrals and ODE solvers, as a pattern matching mechanism would allow you to just transcribe the tables of solutions from textbooks, without having to devise a logic dispatcher manually.

Another possible approach could be logic programming, that would be a nice experiment too. Data transformation and rewrite rules could also be very powerful.

[Avik Sengupta]

+1. Happy to help with the logistics if required. 

[Ben Vautier]

LightTable integration with Julia would be amazing. Especially if we could have IJulia/IPython working seamlessly within the IDE.

[Kevin Squire]

+1

[Elliot Saba]

+1

[Jacob Quinn]

I think GSoC sounds awesome. I'd be pumped to find some way to hack on Julia all summer. Maybe I'll have to find some way to MIT.

-Jacob

[Steven G. Johnson]

It would be good to refer to Julia issues, where various proposals for syntax, library, and compiler improvements have already been hashed out to some extent.  Some of my favorite SoC-scale projects:

https://github.com/JuliaLang/julia/issues/4470
https://github.com/JuliaLang/julia/issues/75
https://github.com/JuliaLang/julia/issues/2645
https://github.com/karbarcca/Datetime.jl/issues/12
https://github.com/JuliaLang/julia/issues/3988
https://github.com/JuliaLang/julia/issues/505

Interactive widgets will involve integration with https://github.com/ipython/ipython/pull/4195

Autocompletion of mu -> μ etcetera is something that we've discussed with fperez recently, and requires updates to the IPython tab-completion protocol (see also https://github.com/ipython/ipython/wiki/IPEP-11%3A-Tab-Completion-System-Refactor) to work in IJulia.

For copy-and-paste of Excel spreadsheets (etc.), see also https://github.com/JuliaLang/julia/issues/4245

Regarding static compilation, there has been recent progress on this (see https://github.com/JuliaLang/julia/pull/4898)

Regarding syntax macros, a string macro in Julia can already do that, the only difference being that you have to delimit the macro arguments with quotes.   e.g.   html"""
     <b>blah blah</b>
"""

[Stefan Karpinski]

My favorite of these is the copy-and-paste with various applications. That would really be a killer feature. It should obviously not just be specific to Excel, but that would be the obvious first killer app. The whole infrastructure for negotiating the copy-and-paste exchange is the interesting part. Several of these issues have already been done (e.g. precompilation).

[Tim Holy]

On Thursday, January 30, 2014 11:50:22 AM Stefan Karpinski wrote:
> Several of these issues have already been done (e.g.
> precompilation).

Perhaps more desperately than precompilation of Julia, we need precompilation
of packages. If loading a plotting package takes ~10 seconds, plotting will
remain underutilized.

--Tim

[John Myles White]

Couldn't agree more. The biggest usability gain left for Julia in my mind is package precompilation.

-- John

[Tom Short]

I agree with John and Tim on package precompilation.

I've tried a few different ways to load packages in base/sysimg.jl but
couldn't get anything to work. Even that would only give me a
precompiled set of packages. It'd be nicer to have all packages
precompiled with a way to load them.

[Tim Holy]

On Thursday, January 30, 2014 11:10:53 AM John Myles White wrote:
> Couldn't agree more. The biggest usability gain left for Julia in my mind is
> package precompilation.

Unfortunately it's a bit intertwined with another biggie, the debugger.
Currently precompiling has the side-effect of decreasing the usefulness of our
backtraces, because functions end up being compiled C rather than Julia. If we
precompile packages, there could be some trouble. IIUC this problem should be
fixed once we have MCJIT emitting usable DWARF info (because the "source" of
the compiled code will be recorded).

Of course, we may want to go ahead and implement package precompilation
anyway; presumably people could always opt not to use it (delete the .so file).
And if you're developing code, you might not always be working from a
precompiled version, anyway.

Best,
--Tim

[Knud Sørensen]

On Monday, 13 January 2014 20:28:22 UTC+1, Francesco Bonazzi wrote:

Wolfram Mathematica manages symbolic algebra through pattern matching on expressions combined with a SAT solver. If you find a way to do it efficiently, I'd suggest to do it before starting the work on symbolic integrals and ODE solvers, as a pattern matching mechanism would allow you to just transcribe the tables of solutions from textbooks, without having to devise a logic dispatcher manually.

Another possible approach could be logic programming, that would be a nice experiment too. Data transformation and rewrite rules could also be very powerful.

Hi.

I am really interresed in the detail of how Mathematica manages symbolic algebra. Do you have some good references I can study ?

Knud

[Francesco Bonazzi]

On Saturday, February 1, 2014 8:10:54 PM UTC+1, Knud Sørensen wrote:

Hi.

I am really interresed in the detail of how Mathematica manages symbolic algebra. Do you have some good references I can study ?

Well, I'm not a good person to give you such kind of advice, because I have no experience in implementing pattern matching. I just know as a user that Mathematica works really fine with it, and having a pattern matching makes it really easier to handle symbolic algebra expressions.

I can suggest you some references, such as Mathematica's documentation:

http://reference.wolfram.com/mathematica/tutorial/SomeNotesOnInternalImplementation.html

http://reference.wolfram.com/mathematica/tutorial/TheInternalsOfMathematicaOverview.html

Also have a look at Mathics, which is a free and open source clone of Mathematica:

https://github.com/poeschko/mathics

There are open source projects like Maxima (unfortunately it's GPL) which are written in Lisp, I don't know , but I think they have a sort of lisp-macroing. Another project is Axiom (New BSD license), which is defined in its own programming language. I have no idea how they work internally, but they have the advantage over Mathematica of source code availability.