Limit output for large sequences

[erickpintor]

I've been using gorrila-repl when I have some database or a rest service to consume and extract data / graphs.

It happens quite often to have a large sequence or map as a response for a query and when we print it the repl stays stuck for a long time going through the sequence to printing all the values.

It would be nice to have the option to limit the amount of elements to show when printing out a sequence so we can quickly see some but not all the results. We would need a way to print all the results as well, if needed.

Here's what I was thinking:

• [ ] Always show the first X elements of the sequence or map when printing
• [ ] If there is more elements to show, display a button to process the rest of the elements

What do you guys think?

[ghost]

Ich normally save everything in a var and sample ist afterwards with take and sample.

cheers Jan

On 07 Apr 2015, at 15:55, Erick Pintor [email protected] wrote:

I've been using gorrila-repl when I have some database or a rest service to consume and extract data / graphs.

It happens quite often to have a large sequence or map as a response for a query and when we print it the repl stays stuck for a long time going through the sequence to printing all the values.

It would be nice to have the option to limit the amount of elements to show when printing out a sequence so we can quickly see some but not all the results. We would need a way to print all the results as well, if needed.

Here's what I was thinking:

Always show the first X elements of the sequence or map when printing If there is more elements to show, display a button to process the rest of the elements What do you guys think?


Reply to this email directly or view it on GitHub.

[erickpintor]

Yep. Today we need to approach every result with precaution.

(def result
  (my-query-that-i-dont-know-the-result-size))

(take 10 result)

But it's very easy to forget or just disconsider the possibility of a large output and end up stuck waiting for thousands of items to be shown. It would be very handy if gorilla could prevent people to face this.

[wiseman]

I tend to think that REPLs that expect to be used by people should strongly consider setting *print-length* to something other than nil.

[JonyEpsilon]

I think it would be very nice to have something like this.

It's a little different from the command-line based REPLs as there are effectively two stages of rendering. First the render protocol method is called recursively on all parts of the result on the Clojure side. Then the client assembles all of these parts into HTML and inserts it into the worksheet DOM.

Doing a good job of coordinating both sides of this process with limited output will be quite tricky I'd imagine. There is a half-way solution though of fully rendering the content on the back-end, and just partially displaying and rendering on the client. My experience is that it is the client-side part that takes the majority of the time, although obviously for big enough results the server-side part will also be a problem.

Maybe the right thing to do is to try implementing the client-side limit and see how it works?