not yet. Is it a very deeply nested structure?

or I guess the answer is, it depends

cartesian product. not nested, just very long.

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

hmm, that shouldn’t be a problem

can you maybe make a small repro?

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

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)) %))
)))

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)

Ill try this example tomorrow, will report back

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

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:

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

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…

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.

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

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

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