nextjournal

respatialized 2021-12-16T21:49:51.259300Z

can I set the paging limit for seqs in clerk manually? I've got a rather large lazy sequence in a notebook that clerk seems to be a little too eager to print.

mkvlr 2021-12-17T15:30:00.264400Z

this works fine for me. Do you run into any issues?

mkvlr 2021-12-17T15:42:00.265600Z

if you want to affect the counting, binding doesn’t work because after we eval the binding is reset to it’s root value, but alter-var-root works:

mkvlr 2021-12-17T15:42:36.266Z

or you can set the JVM prop: (System/getProperty "clerk.bounded-count-limit")

mkvlr 2021-12-17T15:43:55.266200Z

but in your case the bounded-count with 1_000_000 seems fine? Clerk isn’t trying to print the whole thing, only does a bounded count…

respatialized 2021-12-17T16:40:55.266700Z

my real case has a more expensive map fn than the repro, so a 1M bounded count is pretty slow for me (perhaps that means I should be trying to speed up my function instead of trying to curtail the clerk printer 😉). thanks for following up.

mkvlr 2021-12-17T17:01:02.267500Z

ok, hope the alter var root thing works for you then

2021-12-17T19:20:04.267900Z

maybe also consider just using (take) to bound how much of the seq gets realized 🙂 one of the nice things about Clerk is that you have all your usual Clojure techniques with you, so they just transfer to these situations

respatialized 2021-12-17T20:55:14.268100Z

the issue is that it tries to print a def'd var that points to the sequence, forcing (some) realization at the point of definition when I would prefer to defer evaluation

mkvlr 2021-12-16T21:57:57.259400Z

not yet. Is it a very deeply nested structure?

mkvlr 2021-12-16T21:58:15.259600Z

or I guess the answer is, it depends

respatialized 2021-12-16T21:58:45.259800Z

cartesian product. not nested, just very long.

mkvlr 2021-12-16T21:58:49.260Z

if the sequence is lazy and uncounted, https://github.com/nextjournal/clerk/blob/main/src/nextjournal/clerk/config.clj#L13 should help you

mkvlr 2021-12-16T21:59:13.260300Z

hmm, that shouldn’t be a problem

mkvlr 2021-12-16T21:59:22.260500Z

can you maybe make a small repro?

mkvlr 2021-12-16T21:59:35.260700Z

and it’s the latest version of Clerk? 0.4.305?

respatialized 2021-12-16T22:17:36.260900Z

correct - v`0.4.305`. this approximation isn't quite as slow as the actual dataset I'm encountering problems with, but it does demonstrate that rebinding *bounded-count-limit* doesn't appear to limit the number of results it says are there (I'm still seeing "10M+ more..."). My expectation is that rebinding that var gives the printer a lower estimate of how much of the value to consume, but would the binding affect what happens on the "client side" (e.g. SCI/the browser context)?

(require '[clojure.math.combinatorics :as combo])

(binding [nextjournal.clerk.config/*bounded-count-limit* 500]
(def long-sequence
 (->> (range 2 18)
      (map #(range 1 %))
      (apply combo/cartesian-product)
      (map #(map (fn [v] (if (odd? v) (inc v) v)) %))
)))

mkvlr 2021-12-16T22:19:59.262900Z

this value will only affect caching, but not what gets send the to browser. The browser will only receive a tiny preview (first 20 elements)

mkvlr 2021-12-16T22:21:10.264Z

Ill try this example tomorrow, will report back