Clojurians Log v2

I noticed that Clerk does not play nicely yet with "certain very dynamic data structures based on reify macro".

In the tech.ml.dataset world a lot of data structures get realised vi reify of interfaces

So a vector-of-maps, which looks like:

[{:dan-sleep 4.0, :dan-grump 90.20926835578194}
 {:dan-sleep 4.1, :dan-grump 89.31559277383866}
 {:dan-sleep 4.2, :dan-grump 88.42191719189539}] 

Might have a Clojure type of: tech.v3.dataset.readers$mapseq_reader$reify__25236

It is sequential? and implements all interface to work exactly like a sequence

Showing in in Clerk gives:

#object[Error Error: No reader function for tag array-buffer<object>]

Converting into a real

clojure.lang.LazySeq

make its then work:

(seq predictions)

(seq predictions)

This issues we don't see in a repl, neither in other notebooks, like notespace

@carsten.behring thanks a lot for the report, I’ll see that I fix that for the next release.

I will do a quick reproducible example

also noticed a few last minute regressions in the viewers, like false and fns not showing up that I’ve fixed

I guess (Object.) the minimum reproducible example 😼

It comes from classes / types om the dtype-next library:

(tech.v3.datatype/->array-buffer [1 2])

perfect, thanks

https://github.com/cnuernber/dtype-next by @chris441

One other type with issues:

(byte-array (repeat 1000 2))

#object[Error Error: No reader function for tag object]

Could I fix this by registering additional viewers ?

Or is it "deeper down" ?

the reader is not yet open, so this can't yet be fixed in userland

@carsten.behring I have a fix for (Object.) which also fixes the byte array. Later we’ll probably want a hex viewer for binary. Looking into the array buffer next.

@carsten.behring how does the array buffer get displayed in notespace? Like a vector?

is there anything I need to do to make this readable or is this expected?

(tech.v3.datatype/->array-buffer [1 2])
(read-string "#array-buffer<object>[2] [1, 2]")

We don't do anything special with it.

So it implements ".toString()" in some form, I belive.

So something like: "#array-buffer<object>[2]\n[1, 2]"

would be "expected"

not pretty, I agree....

I think that notespace has a fallback, to "str" or similar.

So it prints any Java Object in some form.

yeah, printing isn’t the problem, reading it back is

as in the repl: user> (def x (tech.v3.datatype/->array-buffer [1 2])) ;; => #'user/x user> x ;; => #array-buffer<object>[2] [1, 2]

yes, but that can’t be read again

indeed.

Notespace does not need this.

Notespace does nothing with the clojure reader, I think.

if I define the reader I get this, but it doesn’t really represent the underlying data meaningfully

I think I need a small patch to edamame to make this work, see https://clojurians.slack.com/archives/C015LCR9MHD/p1633809296061200

I would expect that str is called on anything unknown:

so that the last output is te output of the expression before as well

This "error" in rendering prevents as well other rendering which is using the data:

yeah, that's a reasonable fallback and it's actually possible with edamame today

will try to get a release with these fixes out tomorrow or early next week

An interesting case that @jsa-aerial pointed out at our study session today. Somehow, a nested map structure is transformed on rendering.

@daslu oh, that's a bug I thought I had fixed before the release, I guess not completely

it's great to get all those error reports, thanks so much!