[ANN] Blink.jl – Web-based GUIs for Julia

[Mike Innes]

Hello Julians,

I have a shiny late Christmas present for you, complete with Julia-themed wrapping.

Blink.jl wraps Chrome to enable web-based GUIs. It's very primitive at the moment, but as a proof of concept it includes BlinkDisplay, which will display graphics like Gadfly plots in a convenient popup window (matplotlib style).

Shashi has some great ideas for ways to control HTML from Julia, and hopefully in future we'll have more nice things like matrix/data frame explorers and other graphical tools.

(Incidentally, I'd also appreciate any feedback on the display system I've made to enable this, since I'm hoping to propose it to replace Base's current one in future)

Anyway, let me know if this is useful to you and/or there are any problems.

– Mike

[Rob J. Goedman]

Hi Mike,

Tried it a couple of times, but run into below error, in REPL.

Regards,

Rob J. Goedman
goe...@mac.com

julia> Pkg.add("Blink")

INFO: Upgrading Blink: v0.1.2 => v0.1.3

INFO: Building Blink

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed

100  100k  100  100k    0     0   280k      0 --:--:-- --:--:-- --:--:--  280k

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed

100 35.8M  100 35.8M    0     0  3217k      0  0:00:11  0:00:11 --:--:-- 4128k

=========================================================[ ERROR: Blink ]=========================================================

x not defined

while loading /Users/rob/.julia/v0.3/Blink/deps/build.jl, in expression starting on line 13

==================================================================================================================================

=========================================================[ BUILD ERRORS ]=========================================================

WARNING: Blink had build errors.

 - packages with build errors remain installed in /Users/rob/.julia/v0.3

 - build the package(s) and all dependencies with `Pkg.build("Blink")`

 - build a single package by running its `deps/build.jl` script

==================================================================================================================================

INFO: Package database updated

julia> versioninfo()

Julia Version 0.3.4

Commit 3392026* (2014-12-26 10:42 UTC)

Platform Info:

  System: Darwin (x86_64-apple-darwin13.4.0)

  CPU: Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz

  WORD_SIZE: 64

  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)

  LAPACK: libopenblas

  LIBM: libopenlibm

  LLVM: libLLVM-3.3

julia> 

[Mike Innes]

Whoops, slight bug in the build script. A Pkg.update() (possibly followed by Pkg.build("Blink"), if it doesn't happen automatically) should fix you up.

[Tracy Wadleigh]

Nice work!

I was just thinking about julia integration with atom-shell this morning. I'm excited to see where this goes.

[Rob J. Goedman]

Thanks Mike,

Pkg.update indeed fixed it. Wow, this works great!

Tabular example looks like 2nd attached window on OSX.

Thanks a lot!

Rob J. Goedman
goe...@mac.com

[Ivar Nesje]

Have you seen https://github.com/JuliaLang/julia/pull/8987?

[Mike Innes]

The writemime methods and the display system are largely orthogonal – the display system concerns itself with routing output to a suitable display device (terminal, Blink window, whatever) while writemime simply provides the implementation. In other words, I'm only really focused on the `display` function, and that work looks completely compatible with my proposed changes.

[Shashi Gowda]

I love the display system in Blink. This makes much more sense than the current display stack mechanism. First, it lets you show things on different (even multiple) displays. Second, classification of output as Tabular, Graphical and Textual (and finer classifications) is really useful, something the current display stack based mechanism lacks.

Very much for moving it into Base!

[Mike Innes]

Shashi, go ahead and say that here ;)

[Eric Forgy]

Hi Mike,

This is awesome!

Please forgive a question before doing my homework, but is there a way to access a javascript console in the window?

I think I can use this for something I'm working on. I almost have a basic javascript/d3 version of GUIDE working together with my own homegrown data visualizations for building GUIs in Chrome, so this is a very welcome gift :)

I was looking into node-webkit, but this looks maybe better :)

Happy New Year!

Best regards,

Eric

PS: Here is a screenshot. I usually run things in the console.

[Mike Innes]

Sure, if you have a window object you can call `tools(w)` from Julia to open the dev tools. If you end up using Blink.jl I'd love to hear about it!

[Jeff Waller]

Hmm Atom eh? I read that you're communicating via TCP, but I wonder If there is some sort of abstraction possible, and it need not be process to process.   Have not thought it through, but feel something is there.

[Mike Innes]

Well, the abstraction is already there – you can call JS pretty directly without worrying about how the connection is made. It would be great to have more direct (shared memory?) communication, but I don't know if that's possible.

[Jeff Waller]

Oh man, I think there might be a way!  

Inspired by this because you know Atom is essentially node + chromium, I tried

git clone node-julia

and then

bizarro% cd node-julia/

bizarro% HOME=~/.atom-shell-gyp node-gyp rebuild --target=0.19.5 --arch=x64 --dist-url=https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/dist

that 0.19.5 value is critical and I ended up just trying the versions at random....

linked node-julia in 

pwd

/Applications/Atom.app/Contents/Resources/app/node_modules
bizarro% ls -l node-julia
lrwxr-xr-x  1 jeffw  staff  32 Jan  6 18:10 node-julia -> /Users/jeffw/src/atom/node-julia

and then finally within the javascript REPL in Atom 

var julia = require('node-julia');
undefined

julia.exec('rand',200);

Array[200]

and then (bonus)

julia.eval('using Gadfly')
JRef {getHIndex:function}__proto__: JRef

julia.eval('plot(rand(10)');

that last part didn't work of course but it didn't crash though and maybe with a little more...  A julia engine within Atom.  Would that be useful?  I'm not sure what you guys are wanting to do, but maybe some collaboration?

-Jeff

[Tracy Wadleigh]

You mention in the readme about in the future possibly using Cxx.jl to wrap libchromiumcontent. Might you be able to avoid the need for Cxx.jl by using the C API of the Chromium Embedded Framework?

[Eric Forgy]

Hi Jeff,

I'd be interested in getting a Julia engine in Atom, but I would not be so interested in Julia for visualization when, unless I'm mistaken, at that point you can use d3 directly. That would be cool if true. Is it? Can we get the Julia.eval to return a javascript array? Getting Julia and javascript working side by side in the same console would be pretty awesome.

Best regards,

Eric

Sent from my iPad

[Mike Innes]

That's very cool. You should definitely package this up if you can. The JS-on-top approach might actually make it easier to package up a Julia app, at least in the short term. (Also, if you don't want to call julia.eval every time, it should be easy to hook up the Julia instance to Juno and use it as a repl).

The Blink.jl model turns out to work quite well for us – since it's basically a thin layer over a Julia server + browser window, it should be easy to serve Blink.jl apps both locally and over the internet, which will open up some interesting possibilities. It does hurt ease-of-use a little though, so I'd be happy to see alternative approaches crop up.

[Mike Innes]

Sure, I mainly mentioned libc'c' because it's what atom-shell uses, but CEF looks good too. I actually had a go with CEF myself but with my limited C experience it was way too fiddly – getting it working well on all platforms would've taken me years.

Thinking about it more, Chromium uses a multi-process model anyway, so it's possible the native api wouldn't even give us much performance benefit. Node-webkit does some magic to make node run in the same process as the DOM, but from what I hear it's a huge maintenance effort to keep up to date with the latest Chrome (which is part of the reason Light Table has switched to atom-shell as well).

[Jeff Waller]

I'd be interested in getting a Julia engine in Atom, but I would not be so interested in Julia for visualization when, unless I'm mistaken, at that point you can use d3 directly. That would be cool if true. Is it? Can we get the Julia.eval to return a javascript array? Getting Julia and javascript working side by side in the same console would be pretty awesome.

Hi Eric,

I haven't done much with D3 myself, but I work with a number that do, I'll ask what of any limitations there are.  If all else fails, there's always https://www.npmjs.com/package/d3 so long the javascript engine can be fed.

Now as for JavaScript arrays; yea, that's what Julia arrays and tuples are mapped to.  There are some subtleties, that are documented here.  For arrays of primitive "unboxed" types, I'm planning in the next version on changing the datatype mapping to using JavaScript typed arrays as they are faster by at least an order of magnitude.  The syntax and use would be essentially the same though.

Yea, pretty awesome!

[Jeff Waller]

On Tuesday, January 6, 2015 8:24:23 PM UTC-5, Mike Innes wrote:

That's very cool. You should definitely package this up if you can. The JS-on-top approach might actually make it easier to package up a Julia app, at least in the short term. (Also, if you don't want to call julia.eval every time, it should be easy to hook up the Julia instance to Juno and use it as a repl).

julia.eval(<string>) is essentially what happens someone types string, and easy you say?  yes definitely!  I read that Atom has an app database and a package manager (apm), but low level nodejs stuff needs to interact more directly with Atom-shell and it might be difficult to use the Atom supplied extension framework.  I'll certainly follow up.

 

The Blink.jl model turns out to work quite well for us – since it's basically a thin layer over a Julia server + browser window, it should be easy to serve Blink.jl apps both locally and over the internet, which will open up some interesting possibilities. It does hurt ease-of-use a little though, so I'd be happy to see alternative approaches crop up.

Cool!  I read the src and it seems to boil down to the @js macro which printlns a JSON object over a socket, would it be as simple as instead sending to some sort of IO buffer?

 

-Jeff

[Eric Forgy]

Oh man. I was drafting a note and lost it. Oh well. Maybe best. I can be long winded :)

I can see lots of cool apps built with either Julia on top (Blink.jl) or JS on top (node-julia) for hybrid apps.

My idea is a bit unorthodox (although not entirely original). I want to effectively turn the browser into a desktop. Whereas in the Blink Gadfly example, the plot gets launched into a new pop-up window, I'd like to launch the plot into an SVG-based figure window in the browser like the screenshot I sent earlier.

Here is a demo video:

http://youtu.be/IriE1ZP-uOM

I've made a lot of progress since then and hope to have a new demo soon.

The Blink.jl sample on the Readme page has got me imagining a situation where you expand the window to full screen (making it like a desktop), open the console, which acts like a REPL and then launch d3-based visualizations into figure windows all within the browser all driven by Julia. This would give me everything I like about Matlab, but better.