I haven’t but not using TableCloth heavily. Can you share your tablecloth viewer? In previous implementations I’ve seen all Clerk did was convert it to a seq of seqs so not much going on.

I’m converting it to maps using tc/rows and then passing it to either clerk/table or clerk/vl.

so something along these lines?

(ns tablecloth-viewer
  (:require [tablecloth.api :as tc]
            [nextjournal.clerk :as clerk]))

(comment
  (clojure.repl.deps/add-lib 'scicloj/tablecloth {:mvn/version "4.04"}))

(def tablecloth-table-viewer
  {:pred tc/dataset?
   :transform-fn (clerk/update-val (fn [dataset]
                                     (clerk/table {:head (into [] (tc/column-names  dataset))
                                                   :rows (into [] (tc/rows dataset))})))})

(clerk/add-viewers! [tablecloth-table-viewer])

(def dataset
  (tc/dataset "" {:key-fn keyword}))

I’m not using a custom viewer at all.

so having the conversion happen inline? Are you using tc/rows :as-maps ?

Yes, and yes.

I’d recommend using seqs of seqs as in my example as there’s no normalization work for clerk to do and the order of the cols is kept

Well, among other things I need to pass it to Vega-Lite which expects objects.

unsure if that fixes your original issue however

can you share the stacktrace for your issue?

Yes, sure. Next time it happens.

(It appears to be intermittent.)

if nextjournal.clerk.viewer/normalize-table-data shows up in the stacktrace what I wrote above might be worth a try

There’s part of the stacktrace.

It’s showing up in the browser.

huh, interesting, seems to be related to the editscript diff

unfortunately I don’t know anything about to underlying ham-fisted.ImmutList datascructure to know what’s going on

is there a channel for tech-ml-dataset?

I don’t think so.

Probably #C0BQDEJ8M is best?

Longer stack trace:

Hi. I'm not sure whether this is related, but in the past, some tech.ml.dataset/Clerk incompatibilities were caused by tech.ml.dataset's overriding of https://github.com/taoensso/nippy serializations (which were used in Clerk's cache). We recorded one such behaviour https://github.com/scicloj/visual-tools-experiments/tree/main/clerk-cache-tmd-columns-tc-1 (but I think it has been fixed later). I'm mentioning it here since this kind of situation might be difficult to debug without knowing of such relationship (and is tricky to reproduce because it may depend on the cache state).

thanks @U066L8B18. The stacktrace makes me believe it’s unrelated to Clerk’s caching however as it happens when Clerk is doing a editscript diff to figure out the diff to send to the browser to update the display.

The file evaluates just fine in the REPL.

Might this be an issue with tagged literals, which we use?

can you share a repro for this one?

That would be challenging, but I can try.

do you have code of the failing cell?

ah wait, so this is code with a custom reader?

clerk uses edamame to read, but it should respect *data-readers*

The code doesn’t use custom readers.

But the code reads an EDN file that uses tagged literals.

Can’t really say what goes wrong here. Would be great to have a repro.