Tree-views for large results

[nilshg]

Are other people seing this?

rand(1000) takes close to no time, rand(10000) takes substantially longer, while rand(100000) kills the editor for me (i.e. I get a couple of "Editor is not reacting, do you want to wait?" messages, but it doesn't recover).

When I evaluate e.g.

rand(100000)
1

so that the output being displayed is just 1, rather than the large vector, evaluation again happens instantaneously, suggesting that the large vector is causing the problem.

[malmaud]

I just came here to report this.

[pfitzseb]

That behavior makes sense -- we should probably truncate the displayed output after some sensible threshold (just like Julia's REPL). That shouldn't be much of a problem, since no one would really want to scroll through 100,000 elements, right? :-)

[MikeInnes]

Yup, the problem here is that Julia tries to display every element of the vector which crashes Atom (possibly just because it takes so long to transfer the result over TCP). In future I'd really like to have a tree-like display for large results, e.g. something like:

v Vector Int, 100
  v 1 - 10
    1
    4
    6
    ...
  > 11 - 20
  > 21 – 30
  ...

However, that needs lazy-loading to work really well. A reasonable stopgap would be to just cut out the middle elements, as Juno/LT and the repl do currently.

[nilshg]

I was actually going to do just this (the stopgap measure), but then I realised that my CoffeeScript knowledge is so woefully inadequate that I couldn't even locate the part of the code I'd have to change...

[MikeInnes]

Fortunately, you wouldn't have to touch CoffeeScript at all – the tree views are all created in Julia, here, and then sent to the frontend to be rendered. It's as simple as cutting out some of the children if there are too many.

In general, if you're interested in patching anything but not sure where to start, feel free to let me know and I'll try to give pointers. I should probably write up some more devdocs on how display works so that it's a bit easier to get into.

[nilshg]

Okay, I don't really understand what's going on here, which is why I won't submit a PR (where is render defined? And how does it differ from the macro @render? Where is the Inline type defined?), but a working version of what I'd like to see would be:

@render i::Inline xs::Vector begin
  if length(xs) <= 25
    Tree(span(strong("Vector"),
            fade(" $(eltype(xs)), $(length(xs))")),
       [render(i, x, options = options) for x in xs])
  else
    Tree(span(strong("Vector"),
            fade(" $(eltype(xs)), $(length(xs))")),
       [[render(i, x, options = options) for x in xs[1:10]];
        "...";
        [render(i, x, options = options) for x in xs[end-9:end]]])
  end
end

(actually I'll keep that around in my version of the Atom.jl package for now, given that it saves me a lot of grievances over accidentally eval'ing some expression that returns a 100000+ vector :))

[MikeInnes]

I'd be happy to take that as a PR, perhaps with just a little refactoring to avoid the repetition.

I'll also write up a bit more about how display is working and point you to it when I get the chance.

[nilshg]

Okay, not sure my refactoring is what you were looking for, but I've created a PR.

[MikeInnes]

The original issue is fixed so I'm re-purposing this for the tree views thing I mentioned above.