This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-06-05
Channels
- # announcements (11)
- # architecture (22)
- # babashka (33)
- # beginners (15)
- # biff (8)
- # calva (7)
- # clj-otel (1)
- # cljs-dev (3)
- # cljsrn (5)
- # clojure (76)
- # clojure-art (1)
- # clojure-europe (36)
- # clojure-hamburg (3)
- # clojure-nl (1)
- # clojure-norway (7)
- # clojure-poland (12)
- # clojure-spec (2)
- # clojure-uk (7)
- # clojurescript (9)
- # cursive (22)
- # data-science (6)
- # datomic (7)
- # fulcro (9)
- # hoplon (14)
- # instaparse (2)
- # jobs-discuss (14)
- # london-clojurians (1)
- # matrix (32)
- # music (1)
- # nbb (8)
- # off-topic (18)
- # pathom (29)
- # pedestal (6)
- # portal (34)
- # reagent (2)
- # reitit (4)
- # releases (1)
- # sci (10)
- # shadow-cljs (7)
- # tools-deps (4)
- # vim (6)
@chris441 Are there plans for a .cljc
version of https://github.com/cnuernber/tmdjs? My organization’s work would benefit a data frame library that is cross-platform, even if it has to be more limited than what’s available on the JVM.
I hadn’t considered it - tmdjs has some of the same interfaces as TMD- what may work would be just sticking to a subset of TMD like you said.
In both cases the dataset works like a map, nth works fine on columns, etc. Building a dataset on pure clojure persistent vectors doesn't seem like a good use of time - the tmdjs system uses the js buffers such so it has js-specific bindings which are wrapped using a tech.v3.datatype interface similarly to how the jvm system wraps jvm arrays. So both systems have bindings to basically OS-specific and type-specific storage.